Design Phase

1. Design Phase • What’s design? • the process of applying various techniques and principles for the purpose of defining a device, a process, or a system in sufficient detail to permit its physical realization • Design Issues: Modularity (Refinement, Abstraction) • Design Model: Classical vs. Object-Oriented Model • Design Process: Classical vs. Object-Oriented Model *Software Engineering: a Practitioner’s Approach (chap 13, 14, 21) [Pressman, 1997]

2. Design Principles • not suffer from tunnel vision • be traceable to the analysis model • not reinvent the wheel • minimize the intellectual distance between software and the problems in the real world. • exhibit uniformity and integration

3. Design Issues • What’s design quality? Are there uniform criteria that define the technical quality of a software design? • What criteria can be used to partition software into individual components? • How is function or data structure detail separated from a conceptual representation of the software?

4. Implement all of the explicit requirements contained in the analysis model A readable, understandable guide for developers Provide a complete picture of the software Makes intelligent use of control among elements of software Contain both data and procedural abstractions Lead to interfaces to reduce complexity Design Quality

5. Modularity (Abstraction & Refinement) • Each step in the software engineering process is a refinement in the level of abstraction of the software solution. • Refinement causes the designer to elaborate on the solution statement, providing more and more detail as each successive refinement occurs. • Software is divided into separately named and addressable components that are integrated to satisfy problem requirements.

6. How to defineModule?[Meyer, 88] • Decomposability: decompose a large problem into subproblems • Composability: enables existing design components to be assembled into a new system • Understandability • Continuity & Protection: make small change and reduce the propagation of side effects of an error.

7. EffectiveModular Design • Functional independence: a direct outgrowth of modularity and the concepts of abstraction and information hiding • Cohesion: a measure of the relative functional strength of a module. • Coupling: a measure of the relative interdependence among modules

8. Evaluate the first iteration of the program structure to reduce coupling and improve cohesion. Keep scope of effect of a module within the scope of control of that module Evaluate module interfaces to reduce complexity and redundancy and improve consistency Define modules whose function is predictable, but not overly restrictive. Design Heuristics for Effective Modularity

9. Software Architecture • The architecture of a software system • defines the system in terms of components and interactions among components • shows correspondence between requirements and elements of the constructed system • addresses system-level properties (scale, capacity, throughput, consistency, compatibility) • An architectural definition identifies • components: define the locus of computation • e.g., filters, database, objects, clients, servers • connectors: mediate interactions of components • e.g., procedure call, pipes, event broadcast • properties: specify info for construction & analysis • e.g., signatures, pre/post conditions

10. Control Hierarchy (View) • A module controls another module or is controlled by (superordinate vs. subordinate) • Visibility: components are invoked or used as data by a given component (directly or indirectly) • Connectivity: set of components are directly invoked or used as data by a given component.

11. Structural Partitioning • Horizontal partitioning: separate branches of the modular hierarchy for each major program function (input/computation/output) • Vertical partitioning: control and work should be distributed top-down (controller-at-top, worker-at-bottom) • Benefits:easier to test and maintain, fewer side effects, easier to extend

12. Data Structure • A representation of the logical relationship among individual elements • organization • methods of access • degree of associativity • processing alternatives for information

13. Classical Design Model • Data design: transform the information domain model created during analysis into the data structure • Architectural design: define the relationship among major structural elements of the program. • Interface design: describe how the software communicates within itself, to systems that interoperate with it, and with humans who use it. • Procedural design: transforms structural elements of the program architecture into a procedural description of software components.

14. Object-Oriented Design Model • The subsystem layer: a representation of each of the subsystems to achieve its customer defined requirements and to implement the technical infrastructure that supports customer requirements. • The class and object layer: the class hierarchies that enable the system to be created using generalizations and increasingly more targeted specializations; design representations of each object. • The message layer: the details that enable each object to communicate with its collaborators (the external and internal interfaces). • The responsibility layer: the data structure and algorithmic design for all attributes and operations for each other.

15. Object-Oriented Design Model • What’s Subsystem? A subset of all classes collaborate among themselves to accomplish a set of cohesive responsibilities. [Wirfs-Brock et al, 1990].

16. Classical Design Process (Data Design) • Identify all data structures and the operations to be performed on each. • Establish a data dictionary (data library) to be used both data and program design • Defer low-level data design decisions. • A software design and programming language should support the specification and realization of abstract data type.

17. Classical Design Process (Architecture Design) • Data flow-oriented design: • Information flow type/ boundary are established • The DFD is mapped into program structure • Mapping individual transforms of a DFD into appropriate modules within the program structure. • Control hierarchy is defined by factoring (a top-down distribution of controls) • The resultant structure is refined using design measures and heuristics

18. Classical Design Process (Data flow-oriented design) • Figure 12.3 Data flow diagram • Figure 12.4 & 12.5 Structure charts • Figure 12.6 Detailed design • Figure 12.7 PDL (pseudocode) representation • Figure 12.8 Data flow diagram with multiple input & output streams • to find the point of highest abstraction of input/output for each input/output stream • use these points to decompose the given data flow diagram into modules with fewer input/output streams. Continue in this way until each module has high cohesion.

19. Classical Design Process (Interface Design) • The design of interface b/w software modules • The design of interface b/w the software and other external entities • The design of the interface b/w a human and a computer • User model: novices, knowledgeable, intermittent users, knowledgeable, frequent users • General interaction, Information display, Data input

20. Classical Design Process (Procedural Design) • Structured programming • Graphical design notation • Program description language (PDL)

21. Classical Design Process (Post Processing) • Processing narrative must be developed for each module • An interface description is provided for each module • Local and global data structures are defined • All design restrictions/limitations are noted. • A design review is conducted: Optimization (time, space, etc) is considered.

22. Object-Oriented Design Process (Partitioning OOA) • The classes within a subsystem should collaborate only with other classes within the subsystem. • The number of subsystems should be kept small. • Subsystems can be partitioned internally to help reduce complexity. • A well-defined interface through which all communication with the rest of the system occurs.

23. OO Design Process (Process & Task Management) • Allocate each subsystem to an independent processor • Allocate the subsystems to the same processor and provide concurrency support through operating system features • The characteristics of the task, coordinator task and associated objects are defined • The coordinator and other tasks are integrated (task name, description, priority, services, coordinates by, communicates via)

24. OO Design Process (UML) • Construct interaction diagrams • Figure 12.12 Sequential diagram: emphasize the explicit chronological sequence of message, useful in situations where the order in which event occur is important. • Figure 12.13 Collaboration diagram: emphasize the relationship between objects and are a powerful tool for understanding the structure of the software product.

25. OO Design Process (UML) • Construct the detailed class diagram • Figure 12.14 Detailed Class Diagram: determine which actions (method) should be associated with each class or client that sends a message to an object of that class (responsibility-driven design), information hiding, inheritance • Design the product: clients of objects • Figure 12.15 Client-object relations: clients of each object; missing (requests, log-request, update-request) in Elevator-controller • Proceed to the detailed design • Figure 12.16 Detailed design

26. OO Design Process (Data & Resource Management) • The design of the attributes and operations required to manage objects. • External entities (disk drive, processor, communication channel, etc) and abstractions (database, objects) • Human and computer interface

27. OO Design Process (Intersubsystem Commun.) • List each request that can be made by collaborators of the subsystems. • For each contract, note the operations that are required to implement the responsibilities implied by the contract (contract is the specification of the service provided by a subsystem to its clients) • For each contract, define type, collaborator, class, operation • A subsystem collaboration graph or table can be constructed for complex system.

28. Object Design Process (protocol & implementation description) • Establish the interface of an object by defining each message, the related operations. • Implementation details for each operation implied by a message that is passed to an object. • A specification of the object’s name and reference to class • Specification of private data structures with indication of data items and types • A procedural description of each operation

29. Object Design Processalgorithm & data structure • A specification for all operations and attributes. • Algorithm is created to implement the specification for each operation. • Since operations invariably manipulate the attributes of a class, the design of the data structures that best reflect the attributes will have a strong bearingon the algorithm design of the corresponding operations.

30. Object Design Process components & interfaces • Modularity- specification of component • Modules are combined to form a complete program (defines the object as a program component that is linked to other components) • The interface that exist between objects and the overall structure of the objects must be identified (stepwise refinement)