Use-Case Diagrams

---

---

An important part of the Unified Modeling Language (UML) is the facilities for drawing usecase diagrams. Use-cases are used during the analysis phase of a project to identify and partition system functionality. They separate the system into actors and use-cases. Actors represent roles that can are played by users of the system.

Those users can be humans, other computers, pieces of hardware, or even other software systems. The only criterion is that they must be external to the part of the system being partitioned into use-cases. They must supply stimuli to that part of the system, and the must receive outputs from it.

Use-cases represents the activities that actors perform with the help of your system in the pursuit of a goal. We need to define what those users (actors) need from the system. Use-case should reflect user needs and goals, and should be initiated by an actor. Business, actors, Customers participating in the business use-case should be connected to the use-case by association.

Drawing Use-Case Diagrams

The Figure below shows, what a use-case might look like UML schematic form. The usecase itself looks like an oval. The actors are drawn as little stick figures. The actors are connected to the use-case with lines.

Use-case 1 − Sales Clerk checks out an item

• Customer sets item on counter.
• «uses» Swipe UPC Reader.
• System looks up UPC code in database procuring item description and price
• System emits audible beep.
• System announces item description and price over voice output.
• System adds price and item type to current invoice.
• System adds price to correct tax subtotal

So, the «uses» relationship is very much like a function call or a subroutine.

The use-case being used in this fashion is called an abstract use-case because it cannot exist on its own but must be used by other uses cases.

Example ─ Withdrawal Use-Case

The goal of a customer in relation to our money vending machine (ATM) is to withdraw money. So, we are adding Withdrawal use-case. Withdrawing money from the vending machine might involve a bank for the transactions to be made. So, we are also adding another actor – Bank. Both actors participating in the use-case should be connected to the use-case by association.

Money vending machine provides Withdrawal use-case for the customer and Bank actors.

Relationships between Actors and Use-Cases

Use-cases could be organized using following relationships −

• Generalization
• Association
• Extend
• Include

Generalization between Use-Cases

There may be instances where actors are associated with similar use-cases. In such case a Child use-case inherits the properties and behavior of the parent use. Hence we need to generalize the actor to show the inheritance of functions. They are represented by a solid line with a large hollow triangle arrowhead.

Association between Use-Cases

Associations between actors and use-cases are indicated in use-case diagrams by solid lines. An association exists whenever an actor is involved with an interaction described by a use-case.

Extend

There are some functions that are triggered optionally. In such cases the extend relationship is used and the extension rule is attached to it. Thing to remember is that the base use-case should be able to perform a function on its own even if the extending usecase is not called.

Extend relationship is shown as a dashed line with an open arrowhead directed from the extending use-case to the extended (base) use-case. The arrow is labeled with the keyword «extend».

Include

It is used to extract use-case fragments that are duplicated in multiple use-cases. It is also used to simplify large use-case by splitting it into several use-cases and to extract common parts of the behaviors of two or more use-cases.

Include relationship between use-cases which is shown by a dashed arrow with an open arrowhead from the base use-case to the included use-case. The arrow is labeled with the keyword «include».

Use-cases deal only in the functional requirements for a system. Other requirements such as business rules, quality of service requirements, and implementation constraints must be represented separately.

The diagram shown below is an example of a simple use-case diagram with all the elements marked.

Basic Principles for Successful Application of Use-cases

• Keep it simple by telling stories
• Be productive without perfection
• Understand the big picture
• Identify reuse opportunity for use-cases
• Focus on value
• Build the system in slices
• Deliver the system in increments
• Adapt to meet the team’s needs

Use-Case Template

Here, we have shown a sample template of a Use-Case which a Business Analyst can fill so that the information can be useful for the technical team to ascertain information about the project.