using Use Case Diagrams
• Unified Modelling Language
• Developed by Jacobson (1994)
• Set of diagrams and techniques to model object
oriented analysis and design.
– Use Case diagrams
– Activity diagrams
– Communication diagrams
– Sequence diagrams
– Class diagrams
– State diagrams
Use Case Modelling
• Used to document the scope of the
system and the developer’s
understanding of what the users require.
• good for modelling the functional
requirements of a system.
• A separate list of systems requirements
both functional and non-functional should
also be maintained.
• Each use case represents one system activity or task- a
well-defined part of the system functionality as seen from
a specific user(actor)’s point of view.
• They are backed up by behaviour specifications which
specify the behaviour of each case using either UML
diagrams or sequence diagrams, or in text form as use
• Calculate stock requirements
• Create film programme
• Create new member
• Update member details
• Print season report
Requirements Gathering: Use
Case Diagram shows SCOPE
Source: IBM Rational
What is the aim of Use Case
• Elicit enough requirements information to
prepare a model that communicates what
is required from a user perspective.
• If user’s requirements change through the life
cycle, then the change is initiated in the use
• These changes then dictate what changes need
to be made to other models.
Use Case Diagrams
• Business requirements – essential use
cases Hotel self
Order food/ Check valid
drink room number
Guest alarm call
Use Case Diagrams
Use case 1
Use case 2 shows
Use case 3
Each Use Case
• Describes a system function from a user’s perspective
• Details business events and users interaction with the
system during that event
• Represents a system activity, a well-defined part of the
• Has a goal
• Is initiated by an actor, but can interact with other actors.
• Has a more detailed description, possibly specifying a
number of scenarios or alternate courses of action ( e.g.
documented in a use case template)
Types of Use Case
• Use cases are initially defined at a high level
and successively refined and detailed as the
analysis and software development process
• Essential use case – key business
requirements – brief scenario descriptions
• Real Use Case – more detail about what
actually happens – use case template
What are the users trying to accomplish and why?
Business Requirements use case
• Quickly document business events to
define and validate requirements
• Focus on strategic vision and stakeholder
System use case
• Document use case narratives to more
reflect implementation details and detailed
• Association – communication with use case.
• Extends – extract more complex steps into their
own use case. An extension use case is used
when it extends the functionality of a single use
• Used to model optional extras, additional
functionality in a use case
• to model an extension to or variation of a use
Example : Extends…
Used to specify optional extras, additional
student Process late
Relationships : Include
• Include – shows shared processes
• Used if the intent is to factor common
behaviour into its own use case.
• – abstract use case – find 2 or more use
cases that have identical functionality
Example : Includes…
Examine account subsystem
student Search ebrary
• Conditions can be shown as UML
• Arrows always point at the use case that
is being included or extended.
Relationships : dependency,
• Dependency – depends on – shows
• Who provide inputs to system
• Who receive outputs from system
• Who trigger events in the system
• Who maintain the information in the
Actors are outside the system
Relationships between Actors
Generalisation and specialisation
• Campaign manager can do anything a
staff contact can do and more – means
that his role is a specialisation of a staff
Abstracting functionality into super use case
• Assign staff team
• Assign staff member
becomes : Assign staff.
This helps define the functionality and helps
cut excessive repetition.
• Primary business actor benefits from
• System actor – triggers system event
• External server actor responds to a
• External receiver actor receives
Identifying use cases…
• What are the main tasks of each actor?
• What information does the actor need from
the system or provide to the system?
• Does the system/actor need to inform the
system/actor of any changes?