![[Use Case] What?, Why? And How? - All You Need To Know](https://cdn.blogarama.com/images/posts_thumbs_site_id/3766/376577-698967717.jpg "[Use Case] What?, Why? And How? - All You Need To Know")
What is Use Case Diagram?
Use case analysis is a commonly used technique to identify the business goals to be accomplished by a software system. It’s nothing but the system functionalities written in an organized manner. Use case analysis provides an overview of business goals without knowing the system requirements in detail, hence easy to understand. It’s always a best practice to create use case to gather and track the business requirement.
User Stories helps to identify the real business requirement.
“A user story is a brief statement that describe a particular user problem or concern whereas use case represents a goal.”
Usually User stories created under use cases to record and track the problems associated with different business goals. The separation of use cases and user stories provides a clear division of what is the business need and what the system has to support.
Where and Why Use Case Diagram?
Use case diagram aims to capture the dynamic aspect of a system. The objective of Use Case diagram is to gather the usage requirements from external usage point of view as it’s a very high level diagram.
The primary purpose of use case diagrams is to identify functions and how end users interact with them
Use Case diagram required to understand the dynamic view of the system and also to describe the functions and to find the stake holders.
Use Case diagrams are very high level diagrams and this could to be refined further to get the clear and detailed picture of the system. A well-structured use case also describes the pre-condition, post condition, exceptions and these extra elements are used to make test cases when performing the testing.
It’s good to present to managers or the clients as it show high level view of the system and it represents role which interacts with the system and what functionality system will provide without going much deeper.
Elements of Use Cases?
There are mainly three elements used for User case diagram
- Actors
- Use Case
- Relationship
- System (Optional)
- Package (Optional)
Actors:
Actors are nothing but the entity which will be interacting with the functions, it could be a person, organization, an internal or an external applications. It is usually drawn like skeleton shown below.
Actors are nothing but the entity which will be interacting with the functions, it could be a person, organization, an internal or an external applications. It is usually drawn like skeleton shown below.
There are two kinds of actor:
- Primary actor is anyone or thing that interacts with the system to gain direct benefit.
- Secondary actor is anyone or thing that involve in achieving a use case yet, they do not gain direct benefit from the system. Very often, secondary actor is someone who assist the primary actor to achieve a use case.
Use Case:
Use Cases are the functions or an action within the system. This is nothing but the business goal which will be performed by Actors. It’s usually drawn as an oval with fiction name.
Use Cases are the functions or an action within the system. This is nothing but the business goal which will be performed by Actors. It’s usually drawn as an oval with fiction name.
E.g. consider an order management system where the goal is to collect the order, “Place Order" would be a business goal, hence a use case.
Relationship:
Relationship connect the use cases with Actors and represents the relationship between them. It shows, how actors interact with the functions to achieve the business goal.
Relationship connect the use cases with Actors and represents the relationship between them. It shows, how actors interact with the functions to achieve the business goal.
Don't worry, this article has detailed explanation of Relationship in Use Case Diagram. Just scroll this page a little if you don't see below. :)
System (Optional):
System is nothing but the scope which defines the boundary for the use case, however it’s not mandatory but it’s very useful when drawing a Use case for a large system. You can define the scope/boundary of each use case using system or to show different areas covered in different releases. Note that the actors in the system are outside the system.
System is nothing but the scope which defines the boundary for the use case, however it’s not mandatory but it’s very useful when drawing a Use case for a large system. You can define the scope/boundary of each use case using system or to show different areas covered in different releases. Note that the actors in the system are outside the system.
Package (Optional):
Package is another optional element which is very useful for the better readability of Use Cases in complex diagrams. A package object in a UML Class and Use Case Diagram provides the ability to group together classes and/or interfaces that are either similar in nature or related.
Package is another optional element which is very useful for the better readability of Use Cases in complex diagrams. A package object in a UML Class and Use Case Diagram provides the ability to group together classes and/or interfaces that are either similar in nature or related.
Relationship Type in Use Cases:
It always confusion with relationship type in use case. You may get confused with their uses i.e. where to use what? Let’s go through with relationship type in Use Case Diagram without wasting any more time.
There are total 5 relationship types in a use case diagram.
- Association between actor and use case
- Generalization of an actor
- Extend between two use cases
- Include between two use cases
- Generalization of a use case
1. Association Between Actor and Use Case:
This is a direct association of actor with Use case.
Note:
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
In Generalization of an Actor, One actor inherits the role of another actor. If user has use cases which are related to other actor then Actor can inherit the use cases from the Ancestor.
3. Extend Relationship - Between Two Use Cases
It extends the base use case and adds more functionality to the system.
The extending use case is dependent on the extended (base) use case. In the below diagram the “Calculate interest” depends on “Deposit Funds” use case.
The extended (base) use case must be meaningful on its own. This means it should be independent and must not rely on the behaviour of the extending use case.
Although extending use case is optional in some of the cases where as it could be must have in some of the scenarios especially in modelling complex behaviours.
4. Include Relationship Between Two Use Cases
Include relationship show that the behaviour 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 behaviours. Few things to consider
While using the > relationship.
- The base use case is incomplete without the included use case.
- The included use case is mandatory and not optional.
5. Generalization of a Use Case
This is similar to the generalization of an actor. The behaviour of the ancestor is inherited by the descendant. This is used when there are common behaviour between two use cases and also specialized behaviour specific to each use case.
In above example, Customer can pay the bill by Credit Card or Pay By Cash, hence This can be generalized as above. I'm sure you got it. :)
How to create Use Case diagram?
Now we have understand the basics of Use Case Diagram and now it's time to understand, how to proceed in order to create Use Case;
Step 1: Identifying Actors:
This would be the first task. As explained earlier, an Actor could be end user, Organization or internal or external application/system who will be interacting with functions. This helps to explore the and find all possible Use Cases.
This would be the first task. As explained earlier, an Actor could be end user, Organization or internal or external application/system who will be interacting with functions. This helps to explore the and find all possible Use Cases.
Step 2: Identifying Use Cases
Once you got the Actors, now it's time to find the functions of those actors, a good way to do this is to identify what the actor’s needs from the application/system. In ATM system customer will need to withdraw money, check transaction, update contact, request check books etc. and all of these can be considered as use cases.
To get the basic idea about the system and to get started with project, you should always identify the complete actors. Top level use cases should always provide a complete functions required by an actor and you can extend or include use cases depending on the complexity of the system.
Step 3: Look for Common Functionality to use Include
Look for common functionality in order to reuse 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.
If you notices in Include Example, Update Balance was the common function for Withdraw and Deposit fund, hence Include relationship was used. Focus on this area to make your use case more clean and self-explanatory.
If you notices in Include Example, Update Balance was the common function for Withdraw and Deposit fund, hence Include relationship was used. Focus on this area to make your use case more clean and self-explanatory.
Step 4: Possibility of Generalizing Actors / 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 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 is - “Make Payment” use case in a payment system can be further generalized 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 unique scenarios.
Step 5: Optional 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.
Sometime it's mandatory to use the Extend relationship between use case, it describes and gives better picture of project. Hence try to focus on these things before starting with diagram.
Above is the basic Use Case Diagram for reference the reference, however there are more detailed and complex use cases are required in projects.
Guidelines / Instructions
Below guidelines need to be considered while drawing impressive use and self-explanatory use case diagram. guideline for to improve the readability of the diagram.
Actors
- Give meaningful business relevant names for actors
- Primary actors should be to the left side of the diagram – This helps to quickly highlight the important roles in the system.
- Actors don’t interact with other actors (no association) – In case actors interact within a system you need to create a new use case diagram with the system in the previous diagram represented as an actor.
- Place inheriting actors below the parent actor
Use Cases
- Make the Use Case name descriptive and should begin with a Verb – (Name of the use case should clearly represent functionality performed.)
- Place the Use case in the logical order
- Place included use cases to the right of the invoking use case
- Place inheriting use case below parent use case
Relationships
- Arrow points to the base use case when using >
- Arrow points to the included use case when using >
- Both > and > should be shown as dashed arrows.
- Actor and use case relationship doesn’t show arrows.
- Avoid including all types of relationships because the main purpose of the diagram is to identify requirements.
- Use note whenever required to clarify some important points.
Hope you liked this article, Do let me know in comment section if I missed anything in order to complete this article and make more useful for other readers.
If you found this article helpful then don't forget to like our Facebook page as a Token of Appreciation. It will help to reach you with latest post on www.Buzzanalysis.com ..
Don't forget to share with your friends and colleagues via Twitter, Facebook, LinkedIn, Google+ or any other medium, because Sharing is Caring ... :)
