Presentation on theme: "Design Phase What’s design?"— Presentation transcript:
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 realizationDesign Issues: Modularity (Refinement, Abstraction)Design Model: Classical vs. Object-Oriented ModelDesign 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 modelnot reinvent the wheelminimize the intellectual distance between software and the problems in the real world.exhibit uniformity and integration
3 Design IssuesWhat’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 QualityImplement all of the explicit requirements contained in the analysis modelA readable, understandable guide for developersProvide a complete picture of the softwareMakes intelligent use of control among elements of softwareContain both data and procedural abstractionsLead 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 subproblemsComposability: enables existing design components to be assembled into a new systemUnderstandabilityContinuity & 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 hidingCohesion: 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 moduleEvaluate module interfaces to reduce complexity and redundancy and improve consistencyDefine modules whose function is predictable, but not overly restrictive.
9 Software Architecture The architecture of a software systemdefines the system in terms of components and interactions among componentsshows correspondence between requirements and elements of the constructed systemaddresses system-level properties (scale, capacity, throughput, consistency, compatibility)An architectural definition identifiescomponents: define the locus of computatione.g., filters, database, objects, clients, serversconnectors: mediate interactions of componentse.g., procedure call, pipes, event broadcastproperties: specify info for construction & analysise.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 StructureA representation of the logical relationship among individual elementsorganizationmethods of accessdegree of associativityprocessing alternatives for information
13 Classical Design Model Data design: transform the information domain model created during analysis into the data structureArchitectural 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 designDefer 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 establishedThe DFD is mapped into program structureMapping 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 diagramFigure 12.4 & 12.5 Structure chartsFigure 12.6 Detailed designFigure 12.7 PDL (pseudocode) representationFigure 12.8 Data flow diagram with multiple input & output streamsto find the point of highest abstraction of input/output for each input/output streamuse 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 modulesThe design of interface b/w the software and other external entitiesThe design of the interface b/w a human and a computerUser model: novices, knowledgeable, intermittent users, knowledgeable, frequent usersGeneral interaction, Information display, Data input
20 Classical Design Process (Procedural Design) Structured programmingGraphical design notationProgram description language (PDL)
21 Classical Design Process (Post Processing) Processing narrative must be developed for each moduleAn interface description is provided for each moduleLocal and global data structures are definedAll 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 processorAllocate the subsystems to the same processor and provide concurrency support through operating system featuresThe characteristics of the task, coordinator task and associated objects are definedThe coordinator and other tasks are integrated (task name, description, priority, services, coordinates by, communicates via)
24 OO Design Process (UML) Construct interaction diagramsFigure 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 diagramFigure 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, inheritanceDesign the product: clients of objectsFigure Client-object relations: clients of each object; missing (requests, log-request, update-request) in Elevator-controllerProceed to the detailed designFigure 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, operationA 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 classSpecification of private data structures with indication of data items and typesA 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 componentModules 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)