3.7 Moving to component design
As we refine our specification into the design of a system and the set of components that constitute that system, we need to add more detail to any state, sequence and collaboration diagrams we have produced - focusing on the use cases at the system boundary. Typically, we will add timing constraints, guards, inter-object dependencies (such as «uses») and specify whether messages are sequential or asynchronous, and if the former, balking or subject to timeout.
Figure 26 A Catalysis specification = type model + effects of use cases.
The types contained in the specification of Figure 26 represent a model rather than a mandate for the implementer. Any design is acceptable if it produces the behaviour implied by the use case specifications; the model supplies the vocabulary for expressing them. Only the use cases in the bottom section are required. Operations can be assigned to contained types but they are interpreted as 'factored' specifications. If we assign the operation reallocateRoom to Guest, this means that the system provides a facility with that name, one of whose parameters is Guest. It says nothing about how that facility is implemented.
The specification is like the label on the box the system comes in. It says how the system will behave: the responsibilities specified by the uses cases and their goals. It also declares the vocabulary that can be used to describe these responsibilities: the type model. However, it is not making any statements about the responsibilities of the individual types within the model other than their associations. Catalysis illustrates such specifications in the manner shown in Figure 26. A component module may have several such interfaces corresponding to different sets of use cases and actors. In the figure, the front label shows part of the interface concerned with a guest checking in. There may be other labels concerning, say, room service, room allocation or staff payment.
The specification doesn't really say what is inside the box. The objects on the label could be a mere illusion created by some façade. However, to describe the interface at all we usually need a conceptual model of the internal state, which makes it permissible to draw state and sequence diagrams.
Catalysis introduced the important idea, borrowed from formal specification languages, of retrievals. A retrieval is a function that determines the value of an abstract attribute from the actual implementation. It shows how the attributes map to the abstraction, providing that the two models are in conformance with each other; i.e. there is a mapping from the specification to the design with a justification for the design decisions taken. Thus, while models need not be real they must be retrievable. For an example, suppose that we have a specification of a queue that reads: