Further, the UML contains specific modeling constructs that support
the use case in the implementation. Specifically, use cases are realized via
, which are
of classes, interfaces, subsystems, or other elements that cooperate to achieve some behavior. A common UML stereotype, the
, is used for this purpose and is simply a special form of collaboration, one that shows how the functionality of a specific use case is achieved in the design model.
Collaborations, then, are key modeling constructs within our area of concern, for it is within the collaborations that you see the systematic and aggregate behavioral aspects of the system, or how the system achieves its overall goals. These key constructs deliver some of the "bigger-than-the-sum-of-its-
behavior" through the activities of participating classes and other logical elements. The graphical symbol for a collaboration is a simple
-line ellipse with a
inside, as shown in Figure 25-3. (The UML authors have commented that the similarity to use-case notation is intentional.)
Figure 25-3. Symbolic representation of a collaboration
Collaborations have another useful aspect. Since the collaboration represents the way in which the use case is implemented in the design model, we now have a method we can use to trace from the requirements
in the use-case model into the design (Figure 25-4).
Figure 25-4. A use-case realization in the design model
Structural and Behavioral Aspects of Collaborations
Collaborations have two aspects: a structural part that specifies the static structure of the system (the classes, elements, interfaces, and subsystems on which the implementation is structured) and a behavioral part that specifies the dynamics of how the elements interact to accomplish the result. However, a collaboration is not a physical thing; it is just a description of how cooperating elements of the system work together. To know more about how the collaboration is affected, you must look inside.
Inside the collaboration, a class diagram can represent the structural aspects. Figure 25-5 shows a class diagram for the HOLIS Emergency Message Sequence collaboration. For behavioral aspects, you might choose to model its behavior by using an interaction diagram such as the one shown in Figure 25-6.
Figure 25-5. Class diagram for the HOLIS Emergency Message Sequence collaboration
Figure 25-6. Behavioral aspects of the HOLIS Emergency Message Sequence collaboration
Using Collaborations to Realize Sets of Individual Requirements
We've used the mechanism of the use case and the use-case realization to help us cross a very difficult
”the gap between the statement of requirements and the design of a system that fulfills the requirements. We applied use cases to
this technique. Note that it is also true that we can model the implementation of any individual requirement, or any set of requirements, as a collaboration and apply that technique to achieve requirements-to-design traceability for those requirements as well (Figure 25-7). Although the use case does have some special properties, namely, the sequence of events, we can often
our itemized requirements to accomplish a similar objective. With this
extension, we have a meaningful way to use requirements of all types to drive design and implementation.
Figure 25-7. Model of requirements implementation as a collaboration
Design elements that support nonfunctional requirements such as safety, performance, and so on can be
this way as well. Indeed, we already knew that many nonfunctional requirements require a coordinated effort on the part of many classes, subsystems, or systems to achieve the desired result; now we have a way to express that directly.