1 / 34

Subsystems

Subsystems. CS 4311 Wirfs Brock et al., Designing Object-Oriented Software, Prentice Hall, 1990. (Chapter 7). 1. 1. Outline. Subsystems: what and why? Subsystem documentation Subsystems cards Collaboration graphs Guidelines for defining subsystems. 2. 2.

miriam
Download Presentation

Subsystems

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. Subsystems CS 4311 Wirfs Brock et al., Designing Object-Oriented Software, Prentice Hall, 1990. (Chapter 7) 1 1

  2. Outline • Subsystems: what and why? • Subsystem documentation • Subsystems cards • Collaboration graphs • Guidelines for defining subsystems 2 2

  3. Steps for Producing Initial Designs • Identify • Classes • Responsibilities • Collaborations • Analyze • Class hierarchies • Contracts • Collaboration graphs 3 3

  4. Motivation: Collaboration Graph Account 1 2 Balance Deposit Withdrawal Transfer Transaction 8 3 Display Device 4 Form Input Device 6 Menu 5 BCR User Message 9 7 Output Device ATM User Interaction 4

  5. Problem • Collaboration graphs get very complicated. • Too many lines (i.e., interactions or communications) • Designs become incomprehensible. • How to simply the design, esp. patterns of communications?

  6. Solution • Need an abstraction tool to provide macro views • Collect classes together to form subsystems that • Behave like a class. • Support services to outside via contracts.

  7. What Are Subsystems? • Groups of classes that collaborate among themselves to support a set of contracts • Goal: To simplify patterns of communications

  8. What Are Subsystems? (Cont.) • Subsystems are not super classes. • Subsystems are not “just a bunch of classes.” • Subsystems should provide a good abstraction. • Subsystems should provide a clearly defined interface, called subsystem contracts.

  9. Subsystem Contracts • All contracts supported • by things inside a subsystem • for things outside the subsystem. • Delegation of contracts 1 Printing Subsystem 1 Print Server 2 Printer Laser Printer InkJet Printer

  10. Subsystem Cards for Documenting Subsystems • Write the subsystem name at the top • List all classes in the subsystem • Include ref. to the subsystem’s position in the collaborations graphs • Describe the purpose of the subsystem • List contracts for which it is a server • For each contract, identify the class or subsystem to which the contract is delegated

  11. Subsystem Cards (Cont.) Subsystem: Drawing Subsystem Classes: Control Point, Drawing, Drawing Element, … Collaborations Graphs: see Figure 4-6 Description: Responsible for displaying and maintaining the contents of the drawing… Contracts 1. Display itself Server: Drawing 2. Access and modify the contents of a drawing Server: Drawing 3. Modify the attributes of a Drawing Element Server: Control Point

  12. How to Identify Subsystems? • Bottom-up and top-down approaches • Bottom up • Start with classes and responsibilities • Identify collaborations • Partition the classes based on patterns of collaborations • This approach is useful when managing the complexity as a system grows.

  13. Subsystem Identification • Draw collaboration graph (use white board). • Look for strongly coupled classes. • Look for ways to simplify your description of the system. • Look for clean separations. • Look for good abstractions.

  14. How to Identify Subsystems? • Top down • Look at high level functions of system • Look at data sources and uses • Look at supporting technologies • Partition to manage complexity and reduce coupling • This approach may be useful when managing the complexity imposed by initial specification.

  15. Guidelines for Simplifying Interactions • Minimize number of collaborations a class has with other classes or subsystems. • Minimize number of classes and subsystems to which a subsystem delegates. • Minimize number of contracts supported by a class or subsystem.

  16. G-1: Minimize Number of Collaborations • Class should collaborate with as few other classes and subsystems as possible. (Why?) • Heuristic: Centralize communications

  17. Example File File 3 1 Printing Subsystem 1 Printing Subsystem 1 1 Print Server Print Server 2 2 Printer Printer 3 3 Laser Printer Laser Printer Color Printer Color Printer

  18. G-2: Minimize Delegations of Subsystem Contracts • Keep the number of classes inside the subsystem that support subsystem contracts to a minimum • Again, centralize communications into and out of the subsystem

  19. G-3: Minimize Number of Contracts • Too many contracts in one place indicate too much intelligence concentrated in one place: split the functionality between two or more classes. • Re-examine the collaboration patterns

  20. Warehouse Accounting Subsystem Transaction Log Inventory Item Cash Register 2 1 3 Example

  21. Example Warehouse Accounting Subsystem Transaction Log Inventory Item Cash Register 2 1 3

  22. Example Refined Warehouse Accounting Subsystem Transaction Log Inventory Item Cash Register 2 1 3 1 2 3 Inventory Subsystem

  23. Example Refined Further Warehouse Accounting Subsystem Transaction Log Inventory Manager Inventory Item Cash Register 2 1 3 4 4 Inventory Subsystem

  24. If You Have to Redesign ... • Redraw the graphs • Re-examine the collaboration patterns • Walk through scenarios (all of them) • Verify that things are simpler, have improved cohesion and reduced coupling

  25. ATM Example: Contracts • Account: Access and modify balance • Account: commit result to database • Display: Display information • Form: Get numeric value from user • Input Device: accept user input • Menu: Get user selection • Output Device: output to the user • Transaction: execute financial transaction • User Message: display message and wait

  26. Collaboration Graph Account 1 2 Balance Deposit Withdrawal Transfer Transaction 8 3 Display Device 4 Form Input Device 6 Menu 5 BCR User Message 9 7 Output Device ATM User Interaction 26

  27. Refining Account 1 2 Balance Deposit Withdrawal Transfer Transaction 8 3 Display Device 4 Form Input Device 6 Menu 5 BCR User Message 9 7 Output Device ATM User Interaction

  28. Simplified Graph 1 Financial Subsystem 8 3 Display Device 4 Form Input Device 6 Menu 5 BCR User Message 9 7 Output Device User Interaction ATM

  29. Refining Financial Subsystem 8 3 Display Device 4 Form Input Device 6 Menu 5 BCR User Message 9 7 Output Device User Interaction ATM

  30. Simplified Graph 2 Financial Subsystem 8 3 4 User Interaction Subsystem 6 I/O Subsystem 5 9 7 ATM

  31. 3 5 6 4 7 9 Even More Simplified Graph Financial Subsystem 8 ATM User Interface Subsystem

  32. 3 5 6 4 7 9 Even More Simplified Graph Any critique? Financial Subsystem 8 ATM User Interface Subsystem

  33. Rework • Rework your design. If it isn’t changing, you’re not working. • Do not change just to change, but change based on recognition of better design. • Take pride in your work.

  34. Group Work and Assignment Group work (see handout) Subsystems for the project Due: Mar. ?, 2014 Leader: Architect Contents Class diagram showing all classes and their relationships (inheritance and associations) Contracts by refining your CRC cards Subsystems by grouping classes and identifying subsystem contracts (subsystem cards) Collaboration graphs 34

More Related