Realizing Use Cases in the Design Model

Further, the UML contains specific modeling constructs that support realizing the use case in the implementation. Specifically, use cases are realized via collaborations , which are societies of classes, interfaces, subsystems, or other elements that cooperate to achieve some behavior. A common UML stereotype, the use-case realization , 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- parts behavior" through the activities of participating classes and other logical elements. The graphical symbol for a collaboration is a simple dotted -line ellipse with a name inside, as shown in Figure 25-3. (The UML authors have commented that the similarity to use-case notation is intentional.)

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 expressed in the use-case model into the design (Figure 25-4).

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.

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 chasm ”the gap between the statement of requirements and the design of a system that fulfills the requirements. We applied use cases to demonstrate 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 group our itemized requirements to accomplish a similar objective. With this slight extension, we have a meaningful way to use requirements of all types to drive design and implementation.

Design elements that support nonfunctional requirements such as safety, performance, and so on can be modeled 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.