Lecture 6

1. Lecture 6 Design Concepts and Principles

2. Analysis to Design Data Object Description component (procedural) design PSPEC ERD DFD i n t e r f a c e Data Dictionary d e s i g n a r c h i t e c t u r a l d e s i g n STD d a t a d e s i g n CSPEC THE DESIGN MODEL THE ANALYSIS MODEL

3. modelling Prototype Spec Design Where Do We Begin?

4. Design Principles [Dav95] • The design process should not suffer from ‘tunnel vision.’ • The design should be traceable to the analysis model. • The design should not reinvent the wheel. • The design should “minimize the intellectual distance” between the software and the problem as it exists in the real world. • The design should exhibit uniformity and integration.

5. Design Principles [Dav95] • The design should be structured to accommodate change. • The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered. • Design is not coding, coding is not design. • The design should be assessed for quality as it is being created, not after the fact. • The design should be reviewed to minimize conceptual (semantic) errors.

6. Fundamental Concepts • abstraction—data, procedure, control • refinement—elaboration of detail for all abstractions • modularity—compartmentalization of data and function • architecture—overall structure of the software • Structural properties • Extra-structural properties • Styles and patterns • procedure—the algorithms that achieve function • hiding—controlled interfaces

7. Data Abstraction door manufacturer model number type swing direction inserts lights type number weight opening mechanism implemented as a data structure

8. Procedural Abstraction open details of enter algorithm implemented with a "knowledge" of the object that is associated with enter

9. Stepwise Refinement open walk to door; reach for knob; open door; repeat until door opens turn knob clockwise; walk through; if knob doesn't turn, then close door. take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat

10. Modularity: Trade-offs What is the "right" number of modules for a specific software design? module development cost cost of software module integration cost optimal number number of modules of modules

11. Functional Independence COHESION - the degree to which amodule performs one and only one function. COUPLING - the degree to which amodule is “connected” to other modules in the system. HIGH • Independent • Communication, Procedural • Coincidentally, logically, temporal • Compiler/OS • Content • External, Common • Control • Data, Stamp LOW

12. Architecture “The overall structure of the software and the ways in which that structure provides conceptual integrity for a system.” [SHA95a] Structural properties: defines the components of a system (e.g., modules, objects, filters) and the manner in which those components are packaged and interact with one another. Extra-functional properties:address how the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other system characteristics. Families of related systems:draw upon repeatable patterns that are commonly encountered in the design of families of similar systems.

13. Information Hiding module • algorithm controlled • data structure interface • details of external interface • resource allocation policy clients "secret" a specific design decision

14. Architectural Design

15. Why Architecture? • The architecture is not the operational software. Rather, it is a representation that enables a software engineer to: • analyze the effectiveness of the design in meeting its stated requirements, • consider architectural alternatives at a stage when making design changes is still relatively easy, and • reduce the risks associated with the construction of the software.

16. Data Design • refine data objects and develop a set of data abstractions • implement data object attributes as one or more data structures • review data structures to ensure that appropriate relationships have been established • simplify data structures as required

17. Component Level Data Design • Apply systematic analysis principles to function and behavior to data. • Identify all data structures and the operations to be performed on them • Establish a data dictionary. • Defer low level data design decisions. • Reveal data structure representation only to those modules that must make direct use of its content. • Develop a library of useful data structures and the operations that may be applied to them • Abstract data types should be supported.

18. Data-centered architectures Data flow architectures Call and return architectures Object-oriented architectures Layered architectures Architectural Styles Each style describes a system category that encompasses: (1) a set of components (e.g., a database, computational modules) that perform a function required by a system, (2) a set of connectors that enable “communication, coordination and cooperation” among components, (3) constraints that define how components can be integrated to form the system, and (4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.

19. Data-Centered Architecture Client software Client software Client software Client software Data store (repository or blackboard) Client software Client software Client software Client software

20. pipes filter filter filter filter filter filter filter filter filter filter (a) pipes and filters filter filter filter filter (b) batch sequential Data Flow Architecture

21. Call and Return Architecture • main program/subprogram • remote procedure call

22. components user interface layer application layer utility layer core layer Layered Architecture

23. Analyzing Architectural Design • Collect scenarios. • Elicit requirements, constraints, and environment description. • Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements: module, process and data flow views • Evaluate quality attributes by considered each attribute in isolation. • Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style. • Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5.

24. An Architectural Design Method customer requirements "four bedrooms, three baths, lots of glass ..." architectural design

25. Deriving Program Architecture Program Architecture

26. Partitioning the Architecture • “horizontal” and “vertical” partitioning are required

27. function 3 function 1 function 2 Horizontal Partitioning • define separate branches of the module hierarchy for each major function • use control modules to coordinate communication between functions

28. decision-makers workers Vertical Partitioning: Factoring • design so that decision making and work are stratified • decision making modules should reside at the top of the architecture

29. Why Partitioned Architecture? • results in software that is easier to test • leads to software that is easier to maintain • results in propagation of fewer side effects • results in software that is easier to extend

30. Structured Design • objective: to derive a program architecture that is partitioned • approach: • the DFD is mapped into a program architecture • the PSPEC and STD are used to indicate the content of each module • notation: structure chart

31. Transform flow transaction action paths transaction centre Transaction flow Flow Characteristics

32. General Mapping Approach isolate incoming and outgoing flow boundaries; for transaction flows, isolate the transaction center working from the boundary outward, map DFD transforms into corresponding modules add control modules as required refine the resultant program structure using effective modularity concepts

33. Transform Mapping

34. Factoring

35. First Level Factoring main program controller output input processing controller controller controller

36. Second Level Mapping

37. incoming flow action path T Transaction Flow

38. fixture fixture setting servos commands operator process report display operator screen commands robot control robot control software assembly record in reality, other commands would also be shown Transaction Example

39. Refining the Analysis Model write an English language processing narrative 1. for the level 01 flow model apply noun/verb parse to isolate processes, data 2. items, store and entities develop level 02 and 03 flow models 3. create corresponding data dictionary entries 4. refine flow models as appropriate 5. ... now, we're ready to begin design!

40. Deriving Level 1 narrative for " process operator commands“ after noun-verb parse Process operator command software reads operator commands from the cell operator. An error message is displayed for invalid commands. The command type is determined for valid commands and appropriate action is taken. When fixture commands are encountered, fixture status is analysed and a fixture setting is output to the fixture servos. When a report is selected, the assembly record file is read and a report is generated and displayed on the operator display screen. When robot control switches are selected, control values are sent to the robot control system.

41. Level 1 Data Flow Diagram operator commands Error msg fixture status servos read operator commands fixture setting analyse valid command fixture fixture status determine command select report type report generate control display report robot screen send control assembly value robot record control system robot control

42. command error msg produce error msg format status read setting fixture setting command determine command invalid command setting raw setting read validate fixture command combined status status determine type read robot control record record calculate output send values values control report format value report assembly record start /stop Level 2 Data Flow Diagram

43. Transaction Mapping Principles isolate the incoming flow path define each of the action paths by looking for the "spokes of the wheel" assess the flow on each action path define the dispatch and control structure map each action path flow individually

44. Transaction Mapping

45. command error msg produce error msg format status read setting fixture setting command invalid command determine command setting raw setting read validate fixture command combined status status determine type robot control read record record calculate output send values values control report format value report assembly record start /stop Isolate Flow Paths

46. process operator commands command determine input type controller produce report read send validate fixture error generation command control command status message controller value controller each of the action paths must be expanded further Map the Flow Model

47. Refining the Structure Chart

48. Interface Design • Inter-modular interface design • driven by data flow between modules • External interface design • driven by interface between applications • driven by interface between software and non-human producers and/or consumers of information • Human-computer interface design • driven by the communication between human and machine

49. User Interface Design

50. Interface Design Easy to learn? Easy to use? Easy to understand?