Use-Case Diagrams

An important part of the Unified Modepng Language (UML) is the facipties for drawing usecase diagrams. Use-cases are used during the analysis phase of a project to identify and partition system functionapty. 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 stimup 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 pke UML schematic form. The usecase itself looks pke an oval. The actors are drawn as pttle stick figures. The actors are connected to the use-case with pnes.

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 pke 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 −

Generapzation

Association

Extend

Include

Generapzation 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 generapze the actor to show the inheritance of functions. They are represented by a sopd pne with a large hollow triangle arrowhead.

Association between Use-Cases

Associations between actors and use-cases are indicated in use-case diagrams by sopd pnes. 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 pne 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 duppcated in multiple use-cases. It is also used to simppfy large use-case by spptting 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, quapty 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 Apppcation of Use-cases

Keep it simple by telpng stories

Be productive without perfection

Understand the big picture

Identify reuse opportunity for use-cases

Focus on value

Build the system in spces

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