Decomposing the System Requirements Specifications Use cases Design

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

Design Simplification Bank Statistics Customer Bank Application Arrival Departure Event. Queue Event Bank Statistics

Design process (figure 6 -2): We are here Analysis *: these include * --use

Subsystem design: Important (measurable) properties of a set of subsystems: --coupling—how dependent are two

Software architecture: defines, for example, system components global control flow how boundary conditions are

System design: adding nonfunctional requirements, making tradeoffs Identifying subsystems Add design goals: --performance --dependability

Adding nonfunctional design goals: 1. Performance criteria --response time (e. g. , is system

Adding nonfunctional design goals (continued): 3. Cost criteria --development --deployment --upgrades --maintenance --administration 4.

Adding nonfunctional design goals (continued): 5. End-user criteria utility—how well does system support user’s

After design goals are identified and prioritized, tradeoffs can be studied Examples: Space versus

Must also identify subsystems Some heuristics: --group objects in one use case into same

Slides: 12

Download presentation

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

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

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

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

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 5

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 6

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

Adding nonfunctional design goals: 1. Performance criteria --response time (e. g. , is system real-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 8

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 9

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? 10

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) 11

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 12