1 / 12

Decomposing the System Requirements  Specifications (Use cases)  Design --classes

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

vware
Télécharger la présentation

Decomposing the System Requirements  Specifications (Use cases)  Design --classes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. Example—bank simulation (Horstmann) Horstmann, Mastering Object-Oriented Design in C++, Wiley, 1995 Teller 1 Teller 2 Customer 3 Customer 2 Customer 1 Teller 3 Teller 4

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

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

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

  8. Adding nonfunctional design goals: • 1. Performance criteria • --response time (e.g., is system real-time?) • --throughput • --memory • 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. Adding nonfunctional design goals (continued): • Cost criteria • --development • --deployment • --upgrades • --maintenance • --administration • 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. Adding nonfunctional design goals (continued): • End-user criteria • utility—how well does system support user’s work? • usability—how easy is it for user to use the system?

  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. 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

More Related