Design: HOW to implement a system

1. Design: HOW to implement a system • Goals: • Satisfy the requirements • Satisfy the customer • Reduce development costs • Provide reliability • Support maintainability • Plan for future modifications

2. Architecture User Interface Data Types Operations Data Representations Algorithms Design Issues

3. Design • System design (high level design) • Focus on architecture • Identification of subsystems • Object design (lower level design) • Modules and their implementations • Focus on data representations and algorithms

4. System Design • Choose high-level strategy for solving problem and building solution • Decide how to organize the system into subsystems • Identify concurrency / tasks • Allocate subsystems to HW and SW components

5. System Design • Major conceptual and policy decisions • Approach for management of data stores • Access mechanism for global resources • Software control mechanism • Handle boundary conditions • Prioritize trade-offs

6. Design Principles • Consider alternative approaches • Do pro and con analysis • Delay decisions until superior choice is clear • Isolate decisions so alternative implementations can be evaluated later • Avoid unnecessary embellishments • But don’t oversimplify

7. Design Principles (cont.) • Make design traceable to requirements • Use uniform documentation style • Reuse existing designs when possible • Keep design simple unless performance, maintainability, etc. DEMAND otherwise

8. Design Principles (cont.) • Define interfaces between modules carefully • Consider how to handle the unexpected • Don’t code!! • Document decisions • Review, review, review . . .

9. System Architecture • Overall organization of system into subsystems • Decide basic interaction patterns • Numerous architectural styles for different applications • Architecture provides context for detailed design decisions

10. Subsystem Identification • Divide system into a manageable number of components • Each major component is a subsystem • Subsystem groups components with common properties/function

11. Collection of Classes Associations Operations Events Constraints Interrelated Good cohesion Well-defined, small interface with other subsystems Low coupling Identified by the service it provides Subsystem

12. Subsystem Discussion • Provide services for other sub-systems • Group of related functions • Share a common purpose • Divide system into components (>20) • Subsystems are decomposed . . . • Module is the lowest level of subsystem

13. Subsystem Relationships • Client-Server relationship • Client subsystems actively drive the system by requesting services provided by a server subsystem • Peer-to-peer relationship • Subsystems interact and communicate to accomplish a common goal

14. Client-Server Relationship • Server supplies services for clients • Need not know identity of clients • Need not know interface of clients • Client calls server • Client knows interface of server • Server performs some service and returns a result

15. Peer-to-Peer Relationship • Subsystems call one another • The results of/responses to calls may not be immediately visible • Subsystems must know the interfaces of other subsystems • More likely to have communication dependencies

16. Strategies for Decompositions • Layers: Horizontal decomposition • Open • Closed • Partitions: Vertical decomposition • System topology: • General decompositions

17. Layered Subsystems • Set of “virtual” worlds • Each layer is defined in terms of the layer(s) below it • Knowledge is one way: Layer knows about layer(s) below it • Objects within layer can be independent • Lower layer (server) supplies services for objects (clients) in upper layer(s)

18. Example: Layered architecture Interactive Graphics Application Windows Operations Screen Operations Pixel Operations Device I/O Operations

19. Closed Architectures • Each layer is built only in terms of the immediate lower layer • Reduces dependencies between layers • Facilitates change

20. Open Architectures • Layer can use any lower layer • Reduces the need to redefine operations at each level • More efficient /compact code • System is less robust/harder to change

21. Properties of Layered Architectures • Top and bottom layers specified by the problem statement • Top layer is the desired system • Bottom layer is defined by available resources (e.g. HW, OS, libraries) • Easier to port to other HW/SW platforms

22. Partitioned Architectures • Divide system into weakly-coupled subsystems • Each provides specific services • Vertical decomposition of problem

23. Ex: Partitioned Architecture Operating System Virtual Memory Manage- ment File System Process Control Device Control

24. Typical Application Architecture Application package Window graphics Screen graphics Pixel graphics Operating system Computer hardware User dialogue control Simulation package

25. System Topology • Describe information flow • Can use DFD to model flow • Some common topologies • Pipeline (batch) • Star topology

26. Ex: Pipeline Topology Compiler: source program Lexical analyzer Semantic analyzer token stream abstract syntax tree code sequence object code Code generator Code optimizer

27. Ex: Star Toplogy Monitoring system: Alarm Sensors sensor status On/Off signals, alarm type SafeHome software commands, data Telephone line number tones Control panel display information

28. Modularity • Organize modules according to resources/objects/data types • Provide cleanly defined interfaces • operations, methods, procedures, ... • Hide implementation details • Simplify program understanding • Simplify program maintainance

29. Abstraction • Control abstraction • structured control statements • exception handling • concurrency constructs • Procedural abstraction • procedures and functions • Data abstraction • user defined types

30. Abstraction (cont.) • Abstract data types • encapsulation of data • Abstract objects • subtyping • generalization/inheritance

31. Cohesion • Contents of a module should be cohesive • Improves maintainability • Easier to understand • Reduces complexity of design • Supports reuse

32. (Weak) Types of cohesiveness • Coincidentally cohesive • contiguous lines of code not exceeding a maximum size • Logically cohesive • all output routines • Temporally cohesive • all initialization routines

33. (Better) Types of cohesiveness • Procedurally cohesive • routines called in sequence • Communicationally cohesive • work on same chunk of data • Functionally cohesive • work on same data abstraction at a consistent level of abstraction

34. Example: Poor Cohesion package Output is procedure DisplayDice( . . .); procedure DisplayBoard( . . .); Dice I/O device Output Board

35. Example: Good Cohesion package Dice is procedure Display ( . . .); procedure Roll( . . .); Dice I/O device Board

36. Coupling • Connections between modules • Bad coupling • Global variables • Flag parameters • Direct manipulation of data structures by multiple classes

37. Coupling (cont.) • Good coupling • Procedure calls • Short argument lists • Objects as parameters • Good coupling improves maintain-ability • Easier to localize errors, modify implementations of an objects, ...

38. Information Hiding • Hide decisions likely to change • Data representations, algorithmic details, system dependencies • Black box • Input is known • Output is predictable • Mechanism is unknown • Improves maintainability

39. Information Hiding

40. Abstract data types • Modules (Classes, packages) • Encapsulate data structures and their operations • Good cohesion • implement a single abstraction • Good coupling • pass abstract objects as parameters • Black boxes • hide data representations and algorithms

41. Identifying Concurrency • Inherent concurrency • May involve synchronization • Multiple objects receive events at the same time with out interacting • Example: • User may issue commands through control panel at same time that the sensor is sending status information to the SafeHome system

42. Determining Concurrent Tasks • Thread of control • Path through state diagram with only one active object at any time • Threads of control are implemented as tasks • Interdependent objects • Examine state diagram to identify objects that can be implemented in a task

43. Management of Data Stores • Data stores permit separations between subsystems • Internal or external • Common types of data stores • Files • Databases

44. File Data Stores • When to use a database • Require access to voluminous data at fine levels of detail by multiple users • Access can be efficiently managed with DBMS commands • Application must port across many HW and OS platforms • Store is to be accessed by multiple application programs

45. Database Data Stores • Advantages • Infrastructure support • Common interface • Standard access language (SQL) • Disadvantages • Performance penalty • Awkward programming language

46. File Data Stores • When to use file data stores • Data does not fit structure of DBMS • Voluminous data that is low in information density • “Raw” data • Volatile data • only retained for a short time

47. Global Resources • Identify global resources and determine access patterns • Examples • physical units (processors, tape drives) • available space (disk, screen, buttons) • logical names (object IDs, filenames) • access to shared data (database, file)

48. Software Control Mechanism • How SW will control interactions between objects • Internal control • flow of control within a process • External control • flow of externally-visible events among objects • Uniform control style for objects

49. Internal Control • Under control of programmer • Structured for convenience • efficiency, clarity, reliability, . . . • Common types of control flow • Procedure calls • Quasi-concurrent inter-task calls • Concurrent inter-task calls

50. External Control • Procedure-driven systems • Event-driven systems • Concurrent systems