Use Case Diagram Video Lecture | Embedded Systems (Web) - Computer Science Engineering (CSE)

One of the
nine diagrams of
UMLs
are the Use Case Diagrams
basically these are
not important but very important
and I will rather say
compulsory diagrams
needed
for software projects
First will try to understand where basically these diagrams are needed
in the software life cycle
As we all know these phases but I will just iterate through it
The requirement phase
where we basically take the requirement from the customer
the design phase
which
actually defines the technical road map of how our
execution or coding should take place
The build phase where exactly the coding is done or execution is done
testing either its a
acceptance level testing by the customer or probably its a internal tetsing
but all kind of testing will be fall in the testing
And then finally delivery and then
we move towards the maintenance phase
Use Case
Diagrams or Use Cases are used in the requirement phase
They are used basically to collect requirements
from the customer
and then these Use cases are then fed into the design phase to define the technical road map
Use Case Diagrams answer what will the system do?
It will tell my system has
invoicing system and it does
printing of invoices
Probably updates my invoices adds new invoices
whatever it is
That means the Use Case
Diagrams
can be red by the business user
Because they only define what will the system do?
They are used mainly in the requirement documents to depict clarity regarding a system
they are used in the requirement phase of the software life cycle
There are three important parts of a Use Case
The first very important part is a Actor
The actor is the who of the system, in other words he is the end user
Then we have the Use case the
task or the goal for example here
the actor will be actually login to the chats system
The simple chat user is our actor and login is a Use Case
One important part about Use Cases is
they represent actions
in strong verbs
On your slide
login is a verb
its a action performed by the chat user
The whole thing is called as the scenario
These are the three aspects or the three important things when we write any Use Case
In actors we have two types of actors one is the primary actor and other is a secondary actor
Primary actors are the users who are active participants they initiates the Use Case
For instance
this is a simple requirement
where the accountant
logs in to the invoicing system
and prints the invoice
The runner boy or rather
the office boy he takes up the invoice and goes to the end customer
to actually deliver the invoice and take money
We have three actors in this one is the accountant
one is the runner boy or I'll say the office boy
and the customer
But the primary actor is
the accountant because
he or she has actually printed the invoice
they have initiate the actions
And later on the other actors followed it
Depending on what the Use Case is
The actors can be primary and secondary
For example
if we say
The office boy basically
goes and delivers
the
goods or delivers the invoice
If you say from that prospective
then the office boy becomes a primary actor
Depending on what the use case is or what the action is, the actors can change from primary to secondary and secondary to primary
The actor who is a primary actor one of the use cases can be a secondary actor in the other Use Case
The primary and secondary actors are important aspects
or important things which we should note when we write Use Cases or when we draw the Use Case diagrams
Use Case can have two views of presentation
and its very important to have these two views of presentation in requirement document because one shows the higher level view while other shows the detail and netegrity
One is the Use Case diagram for example this is a diagram where you have a simple user then you have a admin user then simple user can add a simple customer while the admin user can add a discounted customer
and whenever the simple customer is added you need to send a email
From the overall point of view you have come to know
the various use cases and the various actors
You also want to know what is the detailed steps involved in completing this use case
That is done by the use case tables
In the use case tables
we take up a use case for example login
we give a description to it we define who are the primary actors, we define pre condition , we define the trigger how the use case will be initiated, we defined the assumption
Failed conditions
We define our action
and when we define any detailed steps about how this action will take place. For example here a login action. The user types the url on the browser
He enters a user name
he selects a rooms
You can have a two level view requirement in your document
The diagram
and then
the table
In this way
anybody who is actually use actually reading your requirement document
can really understand
the overall picture and also he can get the
detail view
If he is not convince but the overall picture he can probably go into the detail and try to read more about the use case
The other very important thing
about use cases are
they define relationships
they depict the relationships during requirement gathering
In the previous slides or int he previous things which we have
derived from Use Cases are
we have identified the actors
we have identified what kind of use cases or actions are
but now
in the real world there are relationships between the use cases and the actors
These are depicted by include and extend
Basically include
defines invocation
It defines using factor
Shiv
is a
father
of
Sanjana
and Shiv
has a titan watch
There are two important keywords to be noted in both of this sentences
The first sentence is
Shiv is a father of Sanjana
is a relationship
parent child relationship
that is depicted by extend in use cases
For example
Admin
is a type of simple user
So this is called as is a relationship
or we can say generalization specialization relationship. We will come into the class diagram to understand what is generalization specialization
Over here this is extend
or this
relationship in real world is defining using extend
The second statement
Shiv has a Titan watch
I have no Parent child relationship with the Titan watch
I am using and then probably
keeping it in the evening on the
sofa or on the table
In the sense it is not something that the Titan watch has properties of my hair but I am using it because I need to see the time
my relationship is of a has relationship
Add simple customer
has a
relationship with a send email use case
This more of invocation relationship
And that is depicted by using include
Has a relationship
is
depicted by using include while is a relationship is depicted by using extend
When we do requirement gathering
two important things should definitely come out of any requirement. First
what are the nouns and verbs?
Which we have already done
in the previous section where we said
the nouns are nothing but your
actors
and the verbs are nothing but your use cases
Again these nouns and these actors
have a
relationship between them