1. 1 Decomposing the System Requirements  Specifications (Use cases)  Design --classes **entity **boundary **control --sequence diagrams --CRC cards **responsibilites **collaborators --state diagrams **conditional **iteration **(sequential)

2. 2 Example—bank simulation (Horstmann) Teller 1 Teller 2 Teller 3 Teller 4 Customer 1Customer 3Customer 2 Horstmann, Mastering Object- Oriented Design in C++, Wiley, 1995

3. 3 Design Simplification Event Departure Arrival Customer Bank EventQueue Application Bank Statistics Event Departure Arrival Customer Bank EventQueue Simulation Bank Statistics How do we simplify The design? --rule of thumb— no crossings --what else can we do?

4. 4 Analysis Design process (figure 6-2): System design Object design Nonfunctional requirements Dynamic model Analysis object model Design goals— guide trade-offs Subsystem decomposition— teams of developers Object design model * * *: these include --use cases and scenarios --class (ER) diagrams --sequence diagrams --CRC cards --state diagrams We are here

5. 5 Subsystem design: Important (measurable) properties of a set of subsystems: --coupling—how dependent are two subsystems on each other goal: as loose coupling as is reasonable --cohesion—how well do components of a subsystem fit together Basic subsystem relationships: --layered (hierarchical) --partitioned (peer-to-peer) Component types: --physical --logical

6. 6 Software architecture: defines, for example, system components global control flow how boundary conditions are handled how subsystems communicate with one another Several common architectures are widely used: --repository—central data structure example: database --model / view / controller model—domain knowledge; static view / controller—interface; modifiable example: interactive system --client / server example: information system + central database --peer-to-peer—generalized client / server deadlocks can occur, synchronization must be handled example: music sharing --three-tier—interface, application, data storage --four-tier—interface contains client and server --pipe and filter—subsystems process inputs, send results to other subsystems works well if there is no user intervention example: Unix shell

7. 7 System design: adding nonfunctional requirements, making tradeoffs Identifying subsystems Add design goals: --performance --dependability --cost --maintenance --end user criteria Make tradeoffs

8. 8 Adding nonfunctional design goals: 1. Performance criteria --response time --throughput --memory 2.Dependability criteria --robustness--ability to survive invalid user input --reliability--difference between specified, observed behavior --availability--% of time system can be used for normal work --fault tolerance--how well it operates under error conditions --security--ability to withstand malicious attacks --safety--ability to avoid endangering human lives even if there are errors and failures

9. 9 Adding nonfunctional design goals (continued): 3.Cost criteria --development --deployment --upgrades --maintenance --administration 4.Maintenance criteria --extensibility--ease of adding functionality, classes --modifiability--ease of changing functionality --adaptability--ease of porting to new application domains --portability--ease of porting to different platforms --readability--ease of understanding system by reading code --traceability of requirements—ease of mapping code to specific requirements

10. 10 Adding nonfunctional design goals (continued): 5.End-user criteria utility—how well does system support user’s work? usability—how easy is it for user to use the system?

11. 11 After design goals are identified and prioritized, tradeoffs can be studied Examples: Space versus speed Delivery time versus functionality Delivery time versus quality Delivery time versus staffing Speed versus cost (hardware versus software)

12. 12 Must also identify subsystems Some heuristics: --group objects in one use case into same subsystem --have a dedicated subsystem to move data between other subsystems --minimize the associations crossing system boundaries --make sure all objects in a given subsystem are functionally related