What is a use case? Definition of usecase .. Define use case..importance of use case diagram
Understanding use case is very easy, but to practice on how to draw use case diagrams may take little to no time. Use cases (use case diagram), as the name indicates they are really very useful cases in understanding the flow of the software application and the interaction between end user and the system.
Every step of use case defines the interaction between the two(user and system/application/product/etc..).
Do not get confused with different terminologies for almost similar meaning. In software industry the final software product is called in different ways, i.e. software product, software application, end product, system etc..
Well, come back to our use cases now. Use cases are very brilliant idea of representing the nature of the existing/future application in a pictorial way so that even a common man can understand the system and how it responds to the user interaction.
To speak in a very lay-man language, if a user clicks on a button, what happens next? Which screen will come, est.’s represented in use case diagram.
Every use case diagram consists of several use cases. Each use case indicates an individual functionality with in a system. I.e. a single use case indicates probably a step in the entire application.
Use cases are very near (conceptually) to requirements documents. Gathering software/system requirements, writing functional specification and drawing use case diagram are very dependable documents. One needs the help of other..
Relation between Requirements gathering, Use cases, FRS(functional requirements specification), TRS(technical requirements specification)
The order goes like this..
n Gathering system requirements from the business users or SMEs (subject matter experts.
n Prepare a FRS (functionally requirements specification) from requirements..
n Prepare a use case diagram from the FRS
n Prepare technical requirements specification (TRS) from FRS.
n While testing the application, test cases are written based on use cases, FRS & TRS.
In a nut shell, we can describe a use case as a set of scenarios of the entire application.
There are particularly two elements that are used in drawing a use case diagram.
One is ‘ACTOR’ and other one is ‘Use case’.
Here Actor will represent an user and ‘use case’ will represent a single unit of process of the entire system. Actor will do something to the use case. And use case will respond for the actor’s action.
The simplest way to draw a use case diagram. An easy example of usecase diagram. Learn how to draw an use case.
The below simple use case diagram is also called as a UML diagram also. UML stands for Unified modeling language.
Here we go. How to draw a simple use case diagram step by step procedure.
For example, a Customer wants to open a bank account in a bank, bofa.(bank of America).
This is an activity, a process, of the entire banking application. So, we will discuss how we can write steps to write a use case diagram for the above activity.
1) Customer calls the bank information center (customer service) to know the procedure of opening an account.
2) Bank customer service people will explain him the process that includes the required documents to submit in order to open an account in their bank.
3) The Customer will contact the accounting department along with the required documents and does all the things that are told by accounts dept.
4) Bank accounts dept will review the Customer’s documents and if he qualifies, an account is granted on his name.
5) Bank personnel will send the new account details like atm card etc. to the customer’s address.
In this way, a simple use case diagram can be drawn. From the above use case diagrams, the requirements can be easily derived.
For any business analyst it is very important to know the differences between, use case diagrams and class diagrams. Also learn how to draw class diagrams and what is the use of class diagram..
State transitions diagram
We use state transition diagrams for object classes that have lot of dynamic behavior.
The button is on..The button is off. Generally to see the state of the object.
Mostly used ehn the objects are dynamic.
Component diagram:
Every system will be made considering the physical world. That’s where this diagram comes into the picture. These diagrams illustrate organizations and dependencies among software components. Includes source code, runtime components etc..
Deployment diagrams:
When it comes to deploying the product then these diagrams come into picture. They show the process on the system and connections between them. It is a visual way of knowing what executables running in my system.