Use Cases Diagram

By | October 1, 2018

Use Case is a behavioral diagramming system. By Use Case diagram we describe “how external entities will use the system”. Here external entities can be human or any other system that will use the newly developing system. In use case description we emphasize

  • The users view of the system i.e. from users perspective how the system look like
  • How user will interact with the system

 Purpose of using Use Case Diagram

  • We identify functions and how external entities will interact with them.
  • Useful when presenting the high level overview to managers or stakeholders. We can highlight the external entities that interact with the system and the functionality of the system without going deep into inner workings of the system.

We define use case as diagram format. We can also use textual description of how the interaction will happen between user and the system.

Use cases are developed from the SRS document.

 Use Case Diagram objects

Use case diagrams consist of 4 objects.

  • Actor
  • Use case
  • System
  • Package

The objects are further explained below.

Actor

The actor is any outside entity that interacts with the system. An actor can be

  • A human user (for instance, a rental agent) or
  • Another software system (for instance, a Accounts systems software) or
  • An interface device (for instance, a POS machine).

In use case we model the interactions between users and the developing software system. In use case actor skeleton shown below-

Use Case

A use case represents a function or an action of 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 an optional element but useful when we’re visualizing large systems. For example, we can create all the use cases and then use the system object to define the scope covered by your project. Or we can even use it to show the different areas covered in different releases.

Package

The package is another optional element that is extremely useful in complex diagrams. Packages are used to group together use cases. They are drawn like the image shown below.

Use Case Diagram Best practices

There are some common guidelines we need to follow when drawing use cases. These include naming standards, directions of arrows, the placing of use cases, usage of system boxes and also proper usage of relationships. Following are given common guideline of Use Case Diagramming-

1. Actors diagramming best practices

  • Give meaningful business relevant names for actors

Example:

For instance our use case interacts with an Airline Company e.g. US-Bangla Airline. In this case we will use the business relevant name instead of company name i.e. we will use Airline Company instead of US-Bangla Airline.

  • Primary actors should be placed to the left side of the diagram

This enables us to quickly highlight the important roles in the system.

  • Actors should be modeled according to their job roles instead of their designation/position.

Example:

In a hotel both the front office executive and shift manager can make reservations. So something like “Reservation Agent” should be used for actor name to highlight the role.

  • External systems are actors

If any other external system interacts with the developing system then the external system will considered as actor.

Example

For sending email if our system needs to interact with an email management system software then the email management system software will be the actor in that particular case.

  • Place inheriting actors below the parent actor

This is to make it more readable and to quickly highlight the use cases specific for that actor.

2. Use Cases diagramming guidelines

  • Names begin with a verb

A use case models an action so the name should begin with a verb.

  • Make the name descriptive

This is to give more information for others who are looking at the diagram.

For example “Print Invoice” is better than “Print”.

  • Highlight the logical order

For example, if we’re analyzing a bank customer typical use cases include open account, deposit and withdraw. Showing them in the logical order makes more sense.

  • Place Included use cases to the right of the invoking use case

This is done to improve readability and add clarity.

  • Place Inheriting use case below parent use case

Again this is done to improve the readability of the diagram.

3. Relationships Best Practices

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

4. Systems / Packages Best Practices

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

Relationships in Use Case Diagrams

There are five types of relationships in a use case diagram. They are

  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

1. Association between Actor and Use Case

This one is straightforward and present in every use case diagram. Few things are noted below-

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

2. 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. Let’s expand the previous use case diagram to show the generalization of an actor.

3. Extend Relationship between Two Use Cases

Many people confuse the extend relationship in use cases. As the name implies it extends the base use case and adds more functionality to the system. Here are few things to consider when using the <<extend>> relationship.

  • The extending use case is dependent on the extended (base) use case. In the below diagram the “Calculate Bonus” use case doesn’t make much sense without the “Deposit Funds” use case.
  • The extending use case is usually optional and can be triggered conditionally. In the diagram, you can see that the extending use case is triggered only for deposits over 10,000 or when the age is over 55.
  • The extended (base) use case must be meaningful on its own. This means it should be independent and must not rely on the behavior of the extending use case.

Lets expand our current example to show the <<extend>> relationship.

Although extending use case is optional most of the time it is not a must. An extending use case can have non-optional behavior as well. This mostly happens when your modeling complex behaviors.

For example, in an accounting system, one use case might be “Add Account Ledger Entry”. This might have extending use cases “Add Tax Ledger Entry” and “Add Payment Ledger Entry”. These are not optional but depend on the account ledger entry. Also, they have their own specific behavior to be modeled as a separate use case.

4. Include Relationship between Two Use Cases

Include relationship show that the behavior of the included use case is part of the including (base) use case. The main reason for this is to reuse the common actions across multiple use cases. In some situations, this is done to simplify complex behaviors. Few things to consider when using the <<include>> relationship.

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

Lest expand our banking system use case diagram to show include relationships as well.

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

For example, in the previous banking example, there might be a use case called “Pay Bills”. This can be generalized to “Pay by Credit Card”, “Pay by Bank Balance” etc.

How to Create a Use Case Diagram

We already learned about objects, relationships and guidelines that are critical when drawing use case diagrams. Now we’ll see the various processes using a banking system as an example.

1. Identifying Actors

Actors are external entities that interact with our 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 we’re trying to show in the use case.
  • External organization can be the tax authority or the central bank.
  • The loan processor is also an external system associated as an actor.
2. Identifying Use Cases

Now it’s time to identify the use cases. A good way to do this is to identify what the actors need from the system.

In banking system a customer will need to

  • Open accounts,
  • Deposit and withdraw funds,
  • Request check books and similar functions.

So all above can be considered as use cases.

Top level use cases should always provide a complete function required by an actor. We can extend or include use cases depending on the complexity of the system.

Once we identify the actors and the top level use case we have a basic idea of the system. Now we can fine tune it and add extra layers of detail to it.

3. Look for Common Functionality to use Include

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

4. Is it Possible to Generalize Actors and Use Cases

There may be instances where actors are associated with similar use cases while triggering few use cases unique only to them. In such instances, we can generalize the actor to show the inheritance of functions. We  can do a similar thing for use case as well.

One of the best examples of this is “Make Payment” use case in a payment system. We 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 a payment with special scenarios unique to them.

5. Optional Functions or Additional Functions

There are some functions that are triggered optionally. In such cases, we can use the extend relationship and attach an extension rule to it. In the below banking system example “Calculate Bonus” is optional and only triggers when a certain condition is matched.

Extend doesn’t always mean it’s optional. Sometimes the use case connected by extend can supplement the base use case. The thing to remember is that the base use case should be able to perform a function on its own even if the extending use case is not called.

Example of Use Case

Following figure shows a simple use-case diagram where we show the interaction between client and system for the requirement Customers can search for flights based on destination and departure times.”

Here Customer is an actor and View Flight Info is our system.

We can also use textual description along with the graphical representation of our use case. The textual description will be

  • Succinct
  • Focused on what is happening
  • Also must not concentrate in “how it is occurring”.

Sometimes any pre-condition and post-condition also associate with use-case. Following textual description describes our above use case diagram-

 Description:

  • A customer will browse the flight information page.
  • Then customer will enter desired the flight search information.
  • After submitting the search request the customer will view a list of flight(s) those are matching the search condition.

 Pre-conditions:

None

Post-conditions

The customer will log in for proceed the flight-booking page.

Example of Relationship between use-case

 1. Include relationship between two use cases

As we discussed previous use case can is depends on another use case. In this case dependent use case is call base use case and other use case (on which the dependent use case is depend) is call include use case. In this case base use case is incomplete without include use case because include use case represented interaction must need to happen before happening the interaction of base use case.

The best practice is one way dependency which means the base use case will know about the include use case but the include use case should not know the base use case.

Consider following “Reserve Seat” use-case-

In above case Reserve Seat use case includes the View Flight Info use-case. Here the base use case is Reserve Seat Use Case and View Flight Info use-case is the include use case.  Here means that before happening the interaction for reserve seat must need the interaction of view flight info. This relationship is useful it provide us complete information. In this case above diagram indicates customer will first view the flight info then will reserve the seat.

Textual description of above use case is-

Description:

  • The customer enters the flight number and request for seat.
  • After the customer submits the request, some confirmation information is displayed.

Pre-conditions:

  • A customer will browse the flight information page.
  • Then customer will enter desired the flight search information.
  • After submitting the search request the customer will view a list of flight(s) those are matching the search condition.
  • Then customer will logged in and enter into flight booking screen for request for a booking.

 Post-conditions:

The customer is sent a confirmation e-mail outlining the flight details and the cancellation policy.

2. Extend relationship between two use cases

In this case we will have a base use case. All extending use cases will extend the behavior of base use case. The base use case should be fully functional and will not dependent on its extended use cases functionality i.e. base use case will as much as functional without it’s extending use case’s additional functionality. All extending use cases are dependent on base use case but base use case doesn’t depends on it extensions.

Consider following example-

We have a Register Customer use case that describes the core process of registering of customer. Then we extend the Register Customer use case and create Register Corporate Customer and Register Retail Customer use cases. Both Register Corporate Customer and Register Retail Customer use cases are dependent on Register Customer use case.

The difference between extension and inclusion is that, in extension, the base use case being extended but not used but in inclusion the Include use case also uses.

Common mistakes in Use-Case

  • Include actions initiated by the system itself. Use case is uses to define the interaction between external entities and the system. So if we include the actions that’s are initiated by the system then it will not serve the purpose of use case.
  • Include a description of the technical requirements of the system. Use cases do not focus on how the system will perform the functions. It will focus on what functions need to be incorporated in the system from the user’s point of view.
20 Total Views 1 Views Today
Md. Mojammel Haque

CSM, CSPO, CSD, CSP-SM, CSP-PO (ScrumAlliance.org)
Certification Profile Link-
https://www.scrumalliance.org/community/profile/mhaque13

Currently working as Lead Team (Application Architecture) at Raven Systems Ltd. Passion for software development especially agile practices such as TDD with in depth knowledge of Object Oriented Programming, SOLID Principles, Gang of Four Design Patterns, Some Enterprise Application Architectural Patterns. Over 8 years of software development experience ASP.NET. Has the ability to understand and transform complex business requirements into software ensuring applications are delivered on time. Also experience in non Microsoft .NET technologies such as Dapper.Net, Git, Structure Map & Angular, Bootstrap, HTML-5, CSS-3 etc.

Category: 1.09-Object Oriented Analysis & Design
Md. Mojammel Haque

About Md. Mojammel Haque

CSM, CSPO, CSD, CSP-SM, CSP-PO (ScrumAlliance.org) Certification Profile Link- https://www.scrumalliance.org/community/profile/mhaque13 Currently working as Lead Team (Application Architecture) at Raven Systems Ltd. Passion for software development especially agile practices such as TDD with in depth knowledge of Object Oriented Programming, SOLID Principles, Gang of Four Design Patterns, Some Enterprise Application Architectural Patterns. Over 8 years of software development experience ASP.NET. Has the ability to understand and transform complex business requirements into software ensuring applications are delivered on time. Also experience in non Microsoft .NET technologies such as Dapper.Net, Git, Structure Map & Angular, Bootstrap, HTML-5, CSS-3 etc.

Leave a Reply

Your email address will not be published. Required fields are marked *