Subsystems

advertisement
Subsystems
CS 4311
Wirfs Brock et al., Designing Object-Oriented Software,
Prentice Hall, 1990. (Chapter 7)
1
Outline
Subsystems: what and why?
 Subsystem documentation

 Subsystems
cards
 Collaboration graphs

Guidelines for defining subsystems
2
Steps for Producing Initial Designs

Identify
 Classes
 Responsibilities
 Collaborations

Analyze
 Class
hierarchies
 Contracts
 Collaboration graphs
3
Motivation: Collaboration Graph
Account
1
Balance
Transaction
Display Device
2
Deposit
Withdrawal
Transfer
8
3
4
Input Device
6
5
Form
Menu
BCR
9
Output Device
7
ATM
User
Message
User Interaction
4
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?
5
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.
6
What Are Subsystems?


Groups of classes that collaborate among
themselves to support a set of contracts
Goal: To simplify patterns of communications
7
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.
8
Subsystem Contracts
1
Printing
Subsystem

1
 by
things inside a
subsystem
 for things outside the
subsystem.
Print Server
2
InkJet
Printer
Printer
Laser
Printer
All contracts
supported

Delegation of
contracts
9
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
10
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
11
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.
12
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.
13
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.
14
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.
15
G-1: Minimize Number of
Collaborations


Class should collaborate with as few other
classes and subsystems as possible. (Why?)
Heuristic: Centralize communications
16
Example
File
3
File
1
Printing
Subsystem
1
1
1
Print
Server
Print
Server
2
3
Color
Printer
2
Printer
Laser
Printer
3
Color
Printer
Printing
Subsystem
Printer
Laser
Printer
17
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
18
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
19
Example
Cash
Register
Warehouse
1
2
3
Inventory
Item
Transaction
Log
Accounting
Subsystem
20
Example
Cash
Register
Warehouse
1
2
3
Inventory
Item
Transaction
Log
Accounting
Subsystem
21
Example Refined
Cash
Register
Warehouse
1
2
3
1
2
3
Inventory
Item
Transaction
Log
Accounting
Subsystem
Inventory
Subsystem
22
Example Refined Again
Cash
Register
Inventory
Subsystem
Warehouse
4
5
6
4
5
6
Inventory
Manager
1
2
3
Inventory
Item
Transaction
Log
Accounting
Subsystem
23
Example Refined Further
Cash
Register
Warehouse
4
Inventory
Subsystem
4
Inventory
Manager
1
2
3
Inventory
Item
Transaction
Log
Accounting
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
1.
2.
3.
4.
5.
6.
7.
8.
9.
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
Balance
Transaction
Display Device
2
Deposit
Withdrawal
Transfer
8
3
4
Input Device
6
5
Form
Menu
BCR
9
Output Device
7
ATM
User
Message
User Interaction
27
Refining
Account
1
Balance
Transaction
Display Device
2
Deposit
Withdrawal
Transfer
8
3
4
Input Device
6
5
Form
Menu
BCR
9
Output Device
7
ATM
User
Message
User Interaction
28
Simplified Graph 1
Financial
Subsystem
8
Display Device
3
4
Input Device
6
5
Form
Menu
BCR
9 User
Message
Output Device
7
User Interaction
ATM
29
Refining
Financial
Subsystem
8
Display Device
3
4
Input Device
6
5
Form
Menu
BCR
9 User
Message
Output Device
7
User Interaction
ATM
30
Simplified Graph 2
Financial
Subsystem
8
3
4
6
I/O
5
Subsystem
User
Interaction
Subsystem
9
7
ATM
31
Even More Simplified Graph
Financial
Subsystem
8
ATM
3
4
5
6
7
9
User Interface
Subsystem
32
Even More Simplified Graph
Any critique?
Financial
Subsystem
8
ATM
3
4
5
6
7
9
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. ?, 2015
 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
35
Download