With so many changes in the UML 2.0 specification, where do I start? Perhaps the best place to start is the top. The top of the software development lifecycle is requirements or the use case diagram. It just so happens that, relative to other diagrams in the UML 2.0 specification, the use case diagram was left pretty much unchanged. Now, there is the addition of multiplicities and conditions on extends relationships. However, these changes are pretty minor compared to what we see in the activity diagrams. The relationship between use cases and state diagrams is now explicit as well but that is the topic of another column.

Figure 1: Class diagram multiplicities

Use Case Multiplicities

Use case multiplicities behave like those you would find on class diagrams. Instead of being on the associations between classes, use case multiplicities lie on the association between actors and use cases. The definition of multiplicities in the use case diagram is exactly the same as they are in a class diagram.

Figure 2: Table of multiplicities

So what does it mean to have a multiplicity on the associations between an actor and a use case? An actor will usually have up to one interaction with a given use case at any time. For example, we will usually have only one session when we are renting videos from an internet video store (see figure 3). There are cases where we have multiple interactions simultaneously. Now we can show that case explicitly.

Likewise, a use case instantiation usually only interacts with one and only one of a given role (human actor). However, we might interact with multiple credit card systems when we are charging for a video. We might want to build the system to be able to interact with optionally many of these systems. Therefore, we would reflect this in the use case multiplicity for the system actor.

Figure 3: The use case diagram for an internet video store with multiplicities

When modeling collaborative or team environments, the number of human interactions may increase. This, too, could be reflected in an increase from the standard one role per use case to many more. An ideal use of these multiplicities would be peer-to-peer systems, the use of which, continues to increase.

Conditions on extends relationships

We often want to show how one use case extends another use case. To that end, we added extensions points in UML 1.3. Conditions from UML 2.0 take extension points one step further. They show the actual logic necessary for one use case to extend another. They also show the exact extension point that is used between the two use cases.

For example, consider how we conference another party in on a phone call. First we create a two party or basic call. On a primitive phone, we press the hang up button lightly (called a flash) and dial the feature activation code. Now we get dial tone and can dial the second party. We are clearly extending the basic call scenario.

To show this condition, we add a note to the extend relationship indicating the condition under which we extend the basic call use case. We also call out the extension point used by the extension. This removes the ambiguity of the extension points utilized by an extending use case.

Figure 4: A condition on an extends relationship

Conclusion

We began this series with a relatively easy set of changes. There are only a few changes to the use case diagram in UML 2.0. These changes add detail to this model while keeping the existing semantics. Conditions and multiplicities are additive features that are perhaps more of interest to the use case expert initially. However, as use case modeling continues to become more popular, these changes will become part of the normal way of building use case models.