UML - USE CASE DIAGRAMS

• Use case diagrams are used to depict the context of the system to be built
and the functionality provided by that system.(DFD LEVEL 0 IN SAD)
• They depict who (or what) interacts with the system. They show what the
outside world wants the system to do.(USER REQUIREMENTS)-ACTORS
• A use case is a methodology used in system analysis to identify, clarify,
and organize system requirements.
• It allows you to very quickly scope the system – what is included and what
is not – and give the team a comprehensive picture of what the system will
do.
• Use case diagrams will specify the events in a system and how those
events flow, however, use case diagram does not describe how those
events are implemented.
• Its high level and doesn’t show any details (DFDLEVEL 0)
 UML-USE CASE DIAGRAM

COMPONENTS OF A USE CASE DIAGRAM

• Actors
• Use Case
• System Boundary
• Relationship
 COMPONENTS OF A USE CASE DIAGRAM
ACTORS
• Actors are entities that interface with the system. They can be people,
organizations or other systems. E.g. ATM interacts with the user and a
Database system. They must be external objects that produce or consume
data.
• Actors should be named by the role they play in relation to the
system(user roles). E.g. Supplier, Customer, passenger, patient,
receptionist, student etc.
• Actors, which are external to the system they are using, are depicted as
stylized stick figures.
• Actor is someone interacting with use case (system functionality) named
by a noun
• Actor has responsibility towards the system(inputs) actor have
responsibility towards the system(outputs)
 FINDING ACTORS
• An Actor requires some services from the system.(e.g. a
customer seeks to withdraw money from an ATM)
• An actor is an external entity which could be a human user, or
some other system or device using the system. E.g. a
customer placing an order
• These are external objects that produce / consume data. E.g.
pay for goods. A customer will provide payment details and
get a receipt.
• Must serve as sources and destinations for data
• Must be external to the system e.g. humans, machines,
external systems, organizational units etc.
• Play business roles in the system
Ask the following questions:
• Who are the system’s primary users? That stimulate system to read.
E.g. when a customer places an order the system reads order
details.
• Who requires system support for daily tasks? E.g. an order system
will require customers to place orders.
• Who are system’s secondary users? respond to system requirements?
• What does the system handle?then for who? e.g. a system that
handles booking. For customers.
• Which other system interact with the system in question?
• Do any entities interacting with the system perform multiple roles
as actors?
• Which other entities (human or otherwise) might have an interest in
the system’s output?
• Primary actors, such as users, always initiate conversations.
Secondary actors, such as servers, always respond to an initiating
use case.
 UML –USE CASE DIAGRAM
USE CASES
• Use cases represent what the actors want your system to do for them. What users
need from the system.
• Each use case defines a complete and useful functionality that the system provides
to the Actor E.g. Make reservation, Place order, Schedule Appointment.
• A use case must be a complete flow of activity, from the actor’s point of view, that
provides value to the actor.
• A use case is a specific way of using the system by using some part of the
functionality.
• To show which actors use which use cases, we can create a use case diagram by
connecting them via basic associations, shown by lines.
• System functions (process automated or manual)
• Named by verb + Noun (or Noun Phrase).
• i.e. Do something
• Each actor must be linked to a use case, while some use-cases may not be linked to
actors.
 SYSTEM BOUNDARY: DEFINE THE SUBJECT
• SUBJECT : it a business, software system, subsystem, component, device
etc. e.g. online travel reservation system, An ordering system, Ticket
vending machine, ATM.
• The system boundary defines the system of interest in relation to the world
around it. A box that sets the system scope to use cases.
• 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.
• The entire system can span all of these modules depicting the overall
system boundary
 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.
• Actors may be connected to use cases by associations, indicating that the actor
and the use case communicate with one another using messages.
 USE CASE EXAMPLE
A business wishes to automate some of its sales procedures. Preliminary
interviews reveal that there are a number of staff roles in the Sales
department. A salesperson can place orders on behalf of customers and
check the status of these orders. A technical salesperson has the same
duties, but additionally is able to provide customers with detailed technical
advice (which we would not expect an ordinary salesperson to be able to do).
A sales supervisor is a salesperson, with the additional responsibility of
creating new customer accounts and checking their credit-worthiness. It is
reasonable to assume that Salesperson is a Generalization of Technical
Salesperson and Sales Supervisor, because the technical salesperson and sales
supervisor have all the properties of a salesperson, and some extra.
We can construct an outline use case model to show these relationships. We
will assume for the sake of simplicity that the use cases are “Place
Order”, “Check Order”, “Create Account”, “Check Credit”, and “Provide
Technical Advice”.
A use case example, without generalization
Figure 3.8. Use case example, with generalization
 BANK ATM
Customers use a bank ATM to check balances if his/her Bank Account, Deposit funds,
withdraw cash and transfer funds. ATM Technicians provide maintenance and repairs
to ATM.
Draw a use case diagram
 RELATIONSHIP IN USECASE DIAGRAMS

• Generalization of a use case

• Generalization of an actor
• Include between two use cases
• Extend between two use cases
• Association between actor and use case
 GENERALIZATION OF A USE CASE
For example, Figure shows the use cases for purchasing various tickets.
Purchase Ticket contains the basic steps necessary for purchasing any tickets,
while the child use cases specialize Purchase Ticket for the specific kinds of
tickets being purchased.

For example, in the previous banking example, there might be a use case called “Pay Bills”. This can be
generalized to “Pay by Credit Card”, “Pay by Bank Balance” etc.

Another Example is “Place order”. This can be generalized as “special Order” and “Normal Order”
 Generalization of an Actor
• Generalization of an actor means that one actor can inherit the role of the other
actor.
• The descendant inherits all the use cases of the ancestor. The descendant has one
or more use cases that are specific to that role. Let’s expand the previous use case
diagram to show the generalization of an actor.
 «include» Relationships:
Include relationship show that the behavior of the included use case is part of
the including (base) use case. The main reason for this is to reuse common
actions across multiple use cases. In some situations, this is done to simplify
complex behaviors. Few things to consider when using the <<include>>
relationship.
• The base use case is incomplete without the included use case.
• The included use case is mandatory and not optional.
• Includes is usually used to model common behavior
 <<extends>> Relationship
While developing your use cases, you may find that certain activities might be
performed as part of the use case but are not mandatory for that use case to run.
• The extending use case is usually optional and can be triggered
conditionally(HAPPENS ONLY WHEN CONDITION IS MET) . In the diagram, you can
see that the extending use case is triggered only for deposits over 10,000 or when
the age is over 55.
• The extended (base) use case must be meaningful on its own. This means it
should be independent and must not rely on the behavior of the extending use case.
Example: one can get help on registration before registration(read guidelines)
• The extension is conditional, which means its execution is dependent on what has
happened while executing the base use case. The base use case does not control the
conditions for the execution of the extension – the conditions are described within
the extend-relationship.
 ASSOCIATION BETWEEN A USECASE AND AN ACTOR
This one is straightforward and present in every use case diagram. Few things to 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.
• E.g. a students borrowing a book from a librarian
A COMPLETE USE CASE DIARAM –ORDER PROCESSING
SYSTEM
HOTEL RESERVATION SYSTEM
CLASS EXERCISE

TO BE EMAILED