UML:Use Cases

A Use case is a case or situation where your system is used to fulfill one or more of user’s requirements. A use case captures a piece of functionality that the system provides.

Use cases are a starting point for just about every facet of object-oriented system development,design,testing and documentation. They describe a system’s requirements from outside looking in. They specify the value that the system delivers to users.

Pros of use cases:

• Use cases are system’s requirements.
• Use cases specify only what your system is supposed to do. They do not specify what the system can’t do.
• Use cases help construct test for system. Use cases provide an excellent starting point for building your test cases and procedures because they precisely capture a user’s requirements and success criteria.

Capturing a System Requirement

We will create here use cases for CMS (Content Management System).
Requirement A.1
The CMS shall allow an administrator to create a new blog account,provided the personal details of new blogger are verified using the author credentials database

Actor

An actor is drawn in UML notation using either a “stick man”or stereotyped box and is labeled with an appropriate name.

Figure 2 captures the Administrator role as it is described in Requirement A.1. The requirement’s description indicates that the Administrator interacts with the system to create a new blogger’s account.
Note:the Administrator interacts with the system and is not part of the system,that’s why the Administrator is defined as an actor.
Actors don’t have to be actual people. While an actor can be a person,it could also be a third party’s system,such as in a business-to-business (B2B) application.

Type of actors

There are two types of actors:

• Tricky actors – not all actors are external systems or people that interact with your system. An example of a common tricky actor is the system clock.
• Refining actors – When going through process of capturing all of the actors that interact with your system,you will find that some actors are related to each other. The Administrator actor is really a special kind of system user. To show that an administrator can do whatever a regular user can do plus some extra additions,a generalization arrow is used. Figure 3

Use Cases

When you captured an initial set of actors that interact with your system,you can assemble the exact model of those interactions. The next step is to find cases where the system is being used to complete a specific job for an actor use cases. Use cases can be identified from your user’s requirements.

How to show use case on diagram?

It is very easy:

What does it mean a good Use Case?

A use case is something that provides some measurable result to the user or an external system.

Communication Lines

A communication line connects an actor and a use case to show the actor participating in the use case. In this example,the Administrator actor is involved in the “Create a new Blog Account” use case.

Example shows a communication line between only one actor and only one use case. There is no limit to the number of actors that can participate in a use case.

Main goal of a communication line is to show that an actor is simply involved in a use case,not to imply an information exchange in any particular direction or that the actor starts the use case.

System boundaries

There is an implicit separation between actors and use cases that marks system’s boundary,UML does provide another small piece of notation for that.

Use Case description

A diagram showing your use cases and actors may be a nice starting point,but it does not provide enough detail for your system designers to actually understand exactly how the system’s concerns will be met. The best way to express this information is in the form of text-based description.
Example of information which should be in description:

Table 1. Some types of information that you can include in your use case descriptions

Example use case description for the “Create a new Blog Account” use case and provides a handy template for your own descriptions.
Table 2. A complete use case description for the “Create a new Blog Account”use case

The description in Table 2 was reasonably straightforward,but something’s not quite right when you compare the description to the original use case diagram.
The use case description has identified a new actor,the “Author Credential Database”.

How many Use Cases should your model have?

There is no set of rule for the number of use cases that your use case model should contain for a given system. The number of use cases depends of the jobs that system has to do according to the requirements.

Use Case Relationships

A use case describes the way your system behaves to meet a requirement. When filling out your use case descriptions,you will notice that there is some similarity between steps in different use cases. You may also find that some use cases with work in several different modes or special cases,or you may also find a use case with multiple flows throughout its execution,and it would be good to show important optional cases on your use case diagrams.
You can show reusable,optional and even specialized use case behavior between use cases.

The <<include>>relationship

The goal of use case relationships is to provide your system’s designers with some architectural guidance so they can efficiently break down the system’s concerns into manageable pieces within the detailed system design.
Requirement A.2
The CMS shall allow an administrator to create a new personal Wiki,provided the personal details of the applying author are verified using the Author Credentials Database.
To capture new requirements a new use case needs to be added to the CMS

Description of the Create a new Personal Wiki use case

Table 3. The detailed description for the “Create a new Personal Wiki”use case

The first thing to notice is that we have some redundancy between the two use case descriptions (Table 2 and Table 3). Both “Create a new Blog Account” and “Create a new Personal Wiki” need to check the applicant’s credentials. Now,this behavior is simply repeated between the two use case descriptions.

The repetitive behavior shared between two use cases is best separated and captured within a totally new use case. This new use case can then be reused by the “Create a new Blog Account” and “Create a new Personal Wiki” use cases using the <<include>>relationship
The <<include>>relationship declares that the use case at the head of the dotted arrow completely reuse all of the steps from the use cases being included.
To show the <<include>>relationship in your use case descriptions,you need to remove the redundant steps from the “Create a new Blog Account” and “Create a new Personal Wiki” use case descriptions and instead use the Included Cases field and include::<use_case_name>syntax to indicate the use case where the reused steps reside,as shown in Table 4 and Table 5

Table 4. Showing <<include>>in a use case description using Included Cases and include::<use_case_name>

Table 5. The Create a new Personal Wiki use case description also gets a makeover

It’s okay. Now need to create a use case description for the reusable steps within the “Check Identity” use case,as shown in Table 6

Table 6. The Check Identity use case description contains the reusable steps

This reuse has two important benefits:

• Reuse using <<include>> removes the need for tedious cut-and-paste operation between use case descriptions
• The <<include>>relationships gives you a good indication at system design time that the implementation of “Check Identity” will need to be a reusable part of your system

Special Cases

Sometimes you will come across a use case whose behavior,when you start to analyze it more carefully,can be applied to several different cases,but with small changes. Unlike the <<include>>relationship,which allow you to reuse a small subset if behavior,this is applying a use case with small changes for a collection of specific situations.
Let’s take a look at our example. Now,the CMS contains a single “Create a new Blog Account” use case that describes the steps required to create an account. But what if the CMS supports several different types of blog accounts and the steps required to create each of these accounts differs ever so slightly from the original use case? You want to describe the general behavior for creating a blog account captured in the “Create a new Blog Account” use case and then define specialized use case in which the account that can make changes to entries in a set of blogs.

This is where use case generalization comes in. A more common way of referring to generalization is using the term inheritance. Use case inheritance is useful when you want to show that one use case is a special type of another use case.

Look at the “Create a new Editorial Blog Account”. Only the details that are specific to creating a new editorial account need to be added.

Table 7. You can show that a use case is a special case of a more general use case within the detailed description using the Base Use Cases field

Use case inheritance is powerful way of reusing a use case so that you only have to specify the extra steps that are needed in the more specific use cases.

The <<extend>>relationship

<<extend>> means that a use case might completely reuse another use case’s behavior,similar to the <<include>>relationship,but that this reuse was optional and dependent either on a runtime or system implementation decision.
Let’s look to our example. The “Create a new Blog Account” use case might want to record that a new author applied for an account and was rejected,adding this information to the author’s application history.

Table 8. Behavior that is a candidate for <<extend>>relationship reuse can usually be found in the Extensions section of a use case description

The same behavior captured in Step 4.3 would also be useful if the customer was refused an account for some reason during the “Create a new Personal Wiki” use case’s execution. According to the requirements,this reusable behavior is optional in both cases;you don’t want to record a rejection if the application for a blog account or personal Wiki was accepted. The <<extend>>relationship is ideal in this sort of reuse situation.

Using the <<extend>>relationship,the “Record Application Failure” use case’s behavior is optionally reused by the “Create a new Blog Account” and “Create a new Personal Wiki” use cases if an application is rejected.

Use Case Overview Diagrams

UML provides the Use Case Overview diagram. This diagram gives an opportunity to paint a broad picture of your system’s context or domain

Use Case Overviews are a useful place to show any extra snippets of information when understanding your system’s place within the world.

Summary

In this article was described what does it mean Use Cases and how to use them in your own model.
Use Cases are very important for successful developing stage.