Architecting Applications for the Enterprise : UML Diagrams (part 1) - Use-Case Diagrams

UML 2.0 has 13 different types of diagrams, articulated in two groups: structural and behavioral. Structural diagrams define classes as well as their attributes, operations, and relationships. Behavioral diagrams show collaborations among objects as required by the system. Table 1 lists all UML diagrams available.

Table 1. Diagrams in UML 2.0

Diagram	Category	Purpose
Activity	Behavior	Shows the flow of operations in an activity
Class	Structure	Shows classes, interfaces, and relationships within a system
Communication	Behavior	Shows the interaction between objects
Component	Structure	Shows components and their dependencies
Composite structure	Structure	Shows the internal structure of a class
Deployment	Structure	Shows how components are mapped to hardware resources
Interaction overview	Behavior	Shows sequences and activities
Object	Structure	Shows a view of the system at a particular time
Package	Structure	Shows how classes are split into logically related groups
Sequence	Behavior	Shows the interaction between objects
State machine	Behavior	Shows how the state of objects changes after events
Timing	Behavior	Shows the behavior of objects in a period of time
Use case	Behavior	Shows what actors perform which action in the system

Figure 1, on the other hand, offers a hierarchical view of the UML diagrams.

Figure 1. Hierarchy of UML diagrams

Note that a UML document can contain multiple instances of the same diagram type—for example, multiple use-case diagrams. At the same time, the same element (that is, the same use case or the same actor) can appear in multiple instances of the same diagram. This is normally done to augment clarity and readability.

As an example, imagine a scenario where you have 10 use cases (essentially, interactions with the system) and 4 actors (essentially, people or objects that interact with the system). Putting everything in a single use-case diagram will likely make the diagram overly complex and hard to read. For this reason, you might want to create three distinct use-case diagrams. In doing so, though, it might happen that one actor or two use cases appear in different diagrams.

Let’s learn more about the three most commonly used diagrams: use-case diagrams, class diagrams, and sequence diagrams.

1. Use-Case Diagrams

A use-case diagram provides a graphical representation of use cases. A use case is an interaction between the system and one of its actors. A use case shows which actors do what. An actor can be a user or any other external system (for example, a database) that interacts with the system being described. An actor cannot be controlled by the system; an actor is defined outside the system itself. Let’s start getting familiar with the notation.

1.1. A Look at the Notation

The main elements of a use-case diagram are the following:

• The system

• The actors

• The use cases

• The relationships

As you can see, the diagram employs a small number of graphical elements. This means that a use-case diagram is often readable and understandable at first sight. Have a look at Figure 2.

Figure 2. A sample use-case diagram

The diagram in Figure 2-3 contains a couple of use cases. A use case is graphically represented with an oval that contains a sufficiently evocative name for the action and actors that participate in the action. An actor is commonly represented using a basic stick man with a name depicted nearby.

Note

Alternative representations exist for the actor. Sometimes the actor is rendered as a rectangle with the word "actor" inside; other times, it is an icon that transmits the idea of someone or something executing an action. However, these notations are extremely rare.

Sometimes the system, or a part of it, might be represented using a rectangle. Within the rectangle, you find use cases, while actors are placed outside of it. The rectangle represents the boundary of the system. (See Figure 3.)

Figure 3. The system’s boundary in a use-case diagram

Actors and use cases can be connected using lines. The connecting line indicates a relationship. A relationship can exist in the following forms:

• Between an actor and a use case

• Between two actors

• Between two use cases

As you can imagine, UML allows you to specify in a more precise manner the semantics of relationships. Relationships can be of three types: inclusion, extension, and generalization. Plus, a fourth type exists that is not formally listed in the specification that indicates a form of interaction. We’ll call this fourth type a generic relationship. Let’s just start with this type.

1.2. Generic Relationships

A generic relationship is established between an actor and a use case. It is rendered with a solid line not ending in any arrow. Figure 2 demonstrates a generic relationship between the actor Customer and the use case Retrieve Orders.

A generic relationship merely indicates that some sort of interaction is expected between the connected parts. Of course, there’s always an active part and a passive part that you normally figure out based on the context.

In the UML standard, there’s no notation to indicate essentially whether the actor has an active or passive role, whether it triggers the use case or it incurs the use case. As mentioned, this is normally clear from the use case itself. For example, in Figure 2, the actor Customer is active as it triggers the use case Retrieve Orders. The actor Database is passive as it incurs the effect of retrieving orders.

1.3. Inclusion

An include relationship is rendered through a directed line that connects two use cases. It indicates that the use case where the line starts contains the behavior defined in the use case where the line ends.

The line is dashed and ends with an open arrow. The line is also labeled with the word include. Figure 4 shows an example.

Figure 4. An include relationship between two use cases

In the preceding example, the use case Cart Checkout incorporates the behavior associated with the Verify User Credentials use case. The message for the developer is clear: when it comes to implementing the checkout process, ask the user to provide credentials and verify them against the membership system.

1.4. Extension

The extend relationship indicates that one use case extends the behavior of the target use case. The notation employed is very similar to the include relationship—a connecting dashed line ending with an open arrow. In this case, though, the arrow is labeled with the word "extend."

What’s the real difference between inclusion and extension? Could you just reverse the arrow in Figure 4 and change the label? What’s the point of having both forms of relationships? Formally, the key difference is that an extension relationship indicates an optional dependency. Hence, the message is this: there’s a use case that optionally might be used to decorate and extend another use case.

The developer should include the behavior of the extender use case in the implementation of the extended use case. However, it should also provide for some triggers because the extension relationship is triggered only under certain specific run-time conditions. (See Figure 5.)

Figure 5. An extend relationship between two use cases

In the diagram in Figure 5, the Cart Checkout use case is extended by the Online Help use case. This additional behavior is optional, and the inclusion happens whenever, say, the user hits F1 during the execution of the Cart Checkout use case. Note that the extender and extended use cases (Cart Checkout and Online Help, in this case) are defined independent of one another.

1.5. Generalization

The generalization relationship can exist between homogeneous pairs of actors and use cases. It indicates that a specialized form of a use case (or actor) exists. The generalization relationship identifies a child and a parent in a sort of inheritance mechanism.

The notation is a solid line ending with a hollow triangle. The triangle touches on the parent element and the lines originates in the child element. The child actor or use case inherits the functionality of the parent and extends it through more specific and specialized features. (See Figure 6.)

Figure 6. Generalization between two actors: a Customer is a special type of Registered User

The diagram in Figure 6 indicates that the actor Registered User triggers the Retrieve Product Details use case. The Retrieve Orders use case can be triggered only by a Customer actor. In the end, the Customer actor is a special type of a registered user. This diagram can be further extended by defining a new actor—say, the Backoffice User—who inherits Registered User to represent all users within the company.