Subsystems are another form of abstraction, using collaboration graphs and subsytem cards
collaborations represent the flow of information in a system statically along all possible paths of flow
collaboration graphs include: classes and their inheritances, contracts and collaborations
class hierarchies are represented as nested boxes
contracts are represented by numbers in circles and collaborations are lines from one class (client) edge to another (server)
groups of classes (subsystems) can collaborate to support a set of contracts to provide a clearly defined unit of functionality, despite having complex interrelationships inside
collaborations can come from the outside, where they are redefined to be a collaboration the whole subsytem, which is then delegated to an appropriate class
subsystems help simplify a design near the end of the process, or to identify the major subsystems and how to split them early on
subsystems only exist as a design entity - ie there is no direct implementable equivalent, though java interfaces can be used fore the subsystem to interact with the outside world
subsystem cards are like CRCs but show the tasks and the classes carrying them out instead
subsystems can be identified by: classes that heavily depend on each other, frequently used collaborations, a web of many collaborations among a certain group of classes
full graph example
full card example
when contracts appear to be almost identical, they could be sharing a responisibility (eg. 3 and 5)
subsystem eg.
edit subsystem UML equivalent
can also 'zoom out' with subsystems, adding more abstraction
to simplify collaboration patterns: minimise collaborations with other classes and subsystems, minimise number of delegations, minimise number of contracts supported per subsystem
subsystem interface - receives all the inputs/contracts and then redistributes them. gives better encapsulation
too many contracts can = too much intelligence, should break down into internal subsystems