Scribd
Upload
27 views25 pages

Use Case Diagrams

Uploaded by

wwwpts.1
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
27 views25 pages

Use Case Diagrams

Uploaded by

wwwpts.1
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 25

Use case diagrams

• Have you ever had a brilliant project idea that makes a lot of sense to
you but you are failing to put it across to another person, e.g.
Supervisor, client etc. ?

• Or that person is failing to understand how the system will be


operating?

• UML Use case diagram can assist in clarifying the high level operations
of a system without finer details of how the system will be
implemented.
What is a Use Case Diagram?

• A UML use case diagram is the primary form of system/software


requirements for a new software program under developed.

• Use cases specify the expected behaviour (what), and not the exact
method of making it happen (how).

• Use cases once specified can be denoted by both textual and visual
representation (such as UML).
Cont.…

• A key concept of use case modeling is that it helps us design a


system from end user's perspective.

• It is an effective technique for communicating system behavior in the


user's terms by specifying all externally visible system behavior.
Cont.…

• A use case diagram is usually simple. It does not show the detail of the use
cases:
• It only summarizes some of the relationships between use cases, actors,
and systems.
• It does not show the order in which steps are performed to achieve the
goals of each use case.
Origin of Use Case

• These days use case modeling is often associated with UML, although it
has been introduced before UML existed.

• In 1986, Ivar Jacobson first formulated textual and visual modeling


techniques for specifying use cases.
Purpose of Use Case Diagram

• Use case diagrams are typically developed in early stage of development


and people often apply use case modeling for the following purposes:
• Specify the context of a system
• Capture the requirements of a system
• Drive implementation and generate test cases
Notation Description and their Visual
Representation

• Actor
• Anything that interacts with the system.
• Can be a user (different types of users), or another system, or external
device.
• A system can have two types of actors, primary and secondary actors
• Primary actor can initiate use cases.
• Secondary actors are more of reactionary actors.
Notation Description and their Visual
Representation

Use Case

• Functionality or services provided by the system

• Each actor must be linked to at least one use case, while some use
cases may not be linked to actors. e.g. (included use cases)
Notation Description and their Visual
Representation

Communication link

• The participation of an actor in a use case is shown by connecting an


actor to a use case by a solid link.
Notation Description and their Visual
Representation

Boundary of system
• The system boundary is potentially the entire system as
defined in the requirements document.
• For large and complex systems, each module may be the
system boundary.
• For example, for an ERP system for an organization, each of
the modules such as personnel, payroll, accounting, etc.
• Can form a system boundary for use cases specific to each
of these business functions.
• Is a data store part of the system?
Structuring Use Case Diagram with
Relationships
• Use cases share different kinds of relationships.

• A relationship between two use cases is basically modeling


the dependency between the two use cases.

• Reuse of an existing use case by using different types of


relationships reduces the overall effort required in
developing a system.

• One use case can be connected to another use case by an


Relationships
Extend
• Represents an optional behaviour / use case
• Base use case is complete on its own
• Extended use case is optional
• The tip of arrowhead points to the base use case and
the child use case is connected at the base of the arrow.
Examples of extend relationship

• It is optional for a user to get help while filling a form

• It is also not mandatory for a user to give feedback


while booking a ticket.
• But the two child use cases (Get Help and Feedback)
are functionalities that the system can provide to the
user during filling form and Ticket booking if the user
chooses to.
Another extend example
• You need to specify extension points in the base use case that specify the
functionality extended to it.
• e.g. "search".
Relationships
Include

• Represents mandatory behaviour / or functionality that


should be present in the base use case

• Base use case is incomplete on its own so it has to include


the functionality of another use case which is usually
common to a number of other base use cases.
Examples of include relationship

• To place an order, the system has to provide a login functionality also

• To transfer funds, the system will have to verify sufficient funds first
• Similarly, to make a payment, the system will have to verify sufficient
funds first
• NB. The included use cases are not necessarily initiated by the user
but the system will provide the use cases when their base cases
are initiated by the user.
Relationships.
Generalization

• A base use case is an abstract use case

• Specialized use cases are required for specific behaviour

• A generalization relationship means that a child use case inherits the


behaviour and meaning of the parent use case.

• The child may add or override the behaviour of the parent.


• Generalization is shown as a directed arrow with a triangle
arrowhead.

• The child use case is connected at the base of the arrow.

• The tip of the arrow is connected to the parent use case.


Use Case Example - Generalization Relationship

• The search use case is an abstract use case

• When a user wants to search, the system will have to provide


the option to either Search by Call number or Search by
Author
ATM example
Someone can
• Make a withdrawal
• Check balance
• Reset pin
• Conduct maintenance work
How to Identify Actor
• Who uses the system?
• Who installs the system?
• Who starts up the system?
• Who maintains the system?
• What other systems use this system?
• Who gets information from this system?
• Who provides information to the system?
• Does anything happen automatically at a present time?
How to Identify Use Cases?
• The following questions can be asked to identify use cases, once
your actors have been identified

• What functions will the actor want from the system?

• What actors will create, read, update or delete this information?

• Does the system need to notify an actor about changes in the


internal state?

• Are there any external events the system must know about?

• What actor inform the system of those events?


Use Case Diagram Tips

• Always structure and organize the use case diagram from the perspective
of actors.

• Use case diagrams are based upon functionality and thus should focus on
the "what" and not the "how".
THE END!!!

You might also like