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. Design Quality
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

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 define Module? [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. Effective Modular 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. Design Heuristics for Effective Modularity
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.

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 Sequential diagram: emphasize the explicit chronological sequence of message, useful in situations where the order in which event occur is important.
Figure 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 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 Client-object relations: clients of each object; missing (requests, log-request, update-request) in Elevator-controller
Proceed to the detailed design
Figure 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 Process algorithm & 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 bearing on 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)