Developing Use Case & Use Case Diagram

INTRODUCTION

Use case diagram is a behavioral UML diagram type and frequently used to analyze various systems.

Use case diagrams are used to gather a usage requirement of a system. Depending on your requirement you can use that data to identify functions and interaction of roles, for a high level view of the system, to identify internal and external factors.

USE CASE DIAGRAM OBJECT

There are four types of objects in use case developing:

1. Actor
2. Use case
3. System
4. Package

ACTOR

Actor in a use case diagram is any entity that performs a role in a given system. This could be a person, organization or an external system and usually drawn like a skeleton shown below.

USE CASE

A use case represents a function or an action within the system. It’s drawn as an oval and named with the function.

SYSTEM

The system is used to define the scope of the use case and drawn as a rectangle. This is needed when you want to visualize a large system. It is an optional element.

PACKAGE

The package is another optional element that is extremely useful in complex diagrams. Similar to class diagrams, packages are used to group together use cases. They are also like a rectangle but it have the package name at up-left corner of the package.

CREATE A USE CASE DIAGRAM

Identifying Actors

Actors are external entities that interact with your system. It can be a person, another system or an organization. In a banking system, the most obvious actor is the customer. Other actors can be bank employee or cashier depending on the role you’re trying to show in the use case.

Identifying Use Cases

A good way to identify the use cases is to identify what the actors need from the system. In a banking system, a customer will need to open accounts, deposit and withdraw funds, request check books and similar functions. So all of these can be considered as use cases.

Look for Common Functionality to use Include

Look for common functionality that can be reused across the system. If you find two or more use cases that share common functionality you can extract the common functions and add it to a separate use case. Then you can connect it via the include relationship to show that it’s always called when the original use case is executed.

Is it Possible to Generalize Actors and Use Cases

There may be instances where actors are associated with similar use cases while triggering a few use cases unique only to them. In such instances, you can generalize the actor to show the inheritance of functions. One of the best examples of this is “Make Payment” use case in a payment system. You can further generalize it to “Pay by Credit Card”, “Pay by Cash”, “Pay by Check” etc. All of them have the attributes and the functionality of payment with special scenarios unique to them.

Optional Functions

There are some functions that are triggered optionally. In such cases, you can use the extend relationship and attach an extension rule to it.

RELATIONSHIP IN USE CASE DIAGRAM

There are five types of relationships in a use case diagram:

1. Association between an actor and a use case
2. Generalization of an actor
3. Extend relationship between two use cases
4. Include relationship between two use cases
5. Generalization of a use case

Association Between Actor and Use Case

This one is straightforward and present in every use case diagram. In this relationship:

• An actor must be associated with at least one use case.
• An actor can be associated with multiple use cases.
• Multiple actors can be associated with a single use case.

Generalization of an Actor

Generalization of an actor means that one actor can inherit the role of the other actor. The descendant inherits all the use cases of the ancestor. The descendant has one or more use cases that are specific to that role.

Extend Relationship Between Two Use Cases

It extends the base use case and adds more functionality to the system. Following criteria should be followed while creating a extend relationship:

• The extending use case is dependent on the extended use case
• The extending use case is usually optional
• The extended use case must be independent.

Include Relationship Between Two Use Cases

Include relationship show that the behavior of the included use case is part of the including use case.

• The base use case is incomplete without the included use case.
• The included use case is mandatory.

Generalization of a Use Case

This is similar to the generalization of an actor. The behavior of the ancestor is inherited by the descendant. This is used when there is common behavior between two use cases and also specialized behavior specific to each use case.

USE CASE DIAGRAM GUIDELINES

Actors

• Give meaningful business relevant names for actors.
• Primary actors should be to the left side of the diagram.
• Actors model roles (not positions).
• External systems are actors.
• Actors don’t interact with other actors.
• Place inheriting actors below the parent actor.

Use Cases

• Names begin with a verb.
• Make the name descriptive.
• Highlight the logical order.
• Place inheriting use case below parent use case.

Relationships

• Arrow points to the base use case when using <<extend>>.
• <<extend>> can have optional extension conditions.
• Arrow points to the included use case when using <<include>>.
• Both <<extend>> and <<include>> are shown as dashed arrows.
• Actor and use case relationship don’t show arrows.

Package

• Use them sparingly and only when necessary
• Give meaningful and descriptive names to these objects