1. Use case diagram is a behavioral UML diagram type and frequently used to analyze various systems. They enable you to visualize the different types of roles in a system and how those roles interact with the system.

2. Importance of Use Case Diagrams

   As mentioned before use case diagram are used to gather a usage requirement of a system. Depending on your requirement you can use that data in different ways. Below are few ways to use them.

3. To identify functions and how roles interact with them – The primary purpose of use case diagrams.
4. For a high level view of the system – Especially useful when presenting to managers or stakeholders. You can highlight the roles that interact with the system and the functionality provided by the system without going deep into inner workings of the system.

5. To identify internal and external factors – This might sound simple but in large complex projects a system can be identified as an external role in another use case.

6. Use Case Diagram objects

   Use case diagrams consist of 4 objects.

   • Actor
   • Use case
   • System
   • Package

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

• Use Case:- A use case represents a function or an action within the system. Its drawn as an oval and named with the function.

• System:- System is used to define the scope of the use case and drawn as a rectangle. This an optional element but useful when your visualizing large systems. For example you can create all the use cases and then use the system object to define the scope covered by your project. Or you can even use it to show the different areas covered in different releases.

• Package:- 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 drawn like the image shown below.

Term and Definition	Symbol
An actor 1) Is a person or system that derives benefit from and is external to the system. 2) Is labeled with its role. 3) Can be associated with other actors by a specialization/superclass association, denoted by an arrow with a hollow arrowhead. 4) Is placed outside the system boundary.
A use case 1) Represents a major piece of system functionality. 2) Can extend another use case. 3) Can use another use case. 4) Is placed inside the system boundary 5) Is labeled with a descriptive verb-noun phrase.
A system boundary 1) Includes the name of the system inside or on top. 2) Represents the scope of the system.
An association relationship 1) Links an actor with the use case(s) with which it interacts.

1. Steps of Create a Use Case Diagram:

   The various processes using a banking systems as an example.

   • 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 your trying to show in the use case.

   An example of an external organization can be the tax authority or the central bank. Loan processor is a good example of external system associated as an actor.

   • Identifying Use Cases

   Now it’s time to identify the use cases. A good way to do this is to identify what the actors needs 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.

   Top level use cases should always provide a complete functions required by an actor. You can extend or include use cases depending on the complexity of the system. Once you identify the actors and the top level use case you have basic idea of the system. Now you can fine tune it and add extra layers of detail to it.

   • 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 its always called when the original use case is executed. (see the diagram for an example).

   • Is it Possible to Generalize Actors and Use Cases

   There maybe instances where actors are associated with similar use cases while triggering few use cases unique only to them. In such instances you can generalize the actor to show the inheritance of functions. You 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. 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 a payment with special scenarios unique to them.

   • Optional Functions or Additional Functions

   There are some functions that are triggered optionally. In such cases you can use the extend relationship and attach and 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 its optional. Sometimes the use case connected by extend can supplement the base use case. 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.

A use case with most of scenarios found in use case diagrams

Use Case Diagram Templates

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 a payment with special scenarios unique to them.

Optional Functions or Additional Functions

There are some functions that are triggered optionally. In such cases you can use the extend relationship and attach and 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 its optional. Sometimes the use case connected by extend can supplement the base use case. 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.