Realizing Use Cases in the Design Model

Realizing Use Cases in the Design Model

This strategy of " use-case-driven design" is a key theme in a variety of software processes based on the UML and the associated book, The Unified Software Development Process [Jacobson, Booch, and Rumbaugh 1999]. The technique we describe here is the means by which the designers of the UML and the affiliated process help the design team transition from an understanding of the requirements to the design and implementation of the solution.

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.)

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 expressed 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 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.

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 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.