UML diagrams

2. REQUIREMENTS ENGINEERING
PRESENTATION TOPIC
“USE CASE MODELING”
Presentation
Wajahat Hasnain

3. Commonly Used UML Diagrams
The most commonly used UML diagrams are:
• Use case diagram, describing how the system is used.
• The starting point for UML modeling.
• Use case (not a diagram).
• Activity Diagram
• Class Diagram
• Sequence Diagram
• Collaboration Diagram

4. Overview of UML Diagrams

5. Use-Case Model
• The Use Case Model describes the proposed functionality of the new system. A Use Case
represents a discrete unit
• of interaction between a user (human or machine) and the system.
• Writing use cases – stories of using a system – is an excellent technique to understand and describe
requirements.
• The UP defines the Use-Case Model within the Requirements discipline.
• It is a model of the system’s functionality and environment.
• UMLUML formally includes the notion offormally includes the notion of Use casesUse cases andand use case diagramuse case diagram..
5

6. Use Cases
• Depiction of a system’s behavior or functionality under various
conditions as the system responds to requests from users
• descriptions ofdescriptions of domain processesdomain processes..
• UMLUML formally includes the notion offormally includes the notion of Use casesUse cases andand use case diagramuse case diagram..
• requiresrequires at least partial understandingat least partial understanding of the requirements of theof the requirements of the
system.system.
• Full functioning for a specific business purpose
• IdeallyIdeally expressed in the requirement specification document (expressed in the requirement specification document (RSDRSD).).

7. A use case is a specific way of using the system by performing some
part of the functionality. Each use case constitutes a complete course
of events initiated by an actor, and it specifies the interaction that
takes place between an actor and the system…...
The collected use cases specify all the existing ways of using the
system.”
Grady Booch et al.:Grady Booch et al.:
If you design a new house and you are reasoning about how you and
your family will use it, this is use case-based analysis.
You consider the various ways in which you‘ll use the house, and
these use cases drive the design.

8. Detailed Use Case Description/Modeling

9. Goals and Stories
9
 The user has goals (needs in UP) in the form of business processes.
 There are many ways to capture these goals and system requirements.
Use cases are a mechanism to help keep it simple and
understandable for all stakeholders.
 Informally, they are stories of using a system to meet goals.
 Example brief format use case:
Process Sale: A customer arrives at a checkout with items to
purchase. The cashier uses the POS system to record each
purchased item. The system presents a running total and line-
item details. The customer enters payment information, which
the system validates and records. The system updates
inventory. The customer receives a receipt from the system and
then leaves with the items.
 A more elaborated format is needed, but the essence is discovering
and recording functional requirements by writing stories of using a
system to help fulfill various stakeholder goals (i.e., cases of use).

10. Types of Use cases
(1)Levels of Abstraction: EssentialVs Real (Concrete)
According to the level of detail required at analysis and
design stages.
(2)Amount of Details: High Level and Expanded
High Level Usecases : Brief but structured
Expanded Usecases: Fully dressed and structured
(3)Business Importance: Primary, Secondary, and Optional)
• Primary use cases represent major common processes, such as
Buy Items.
• Secondary Use cases represent minor or rare processes, such as
Request for Stocking New Product.
• Optional use cases represents processes that may not be
tackled, like: Payment type analysis

11. 11
Essential Versus Real Use Cases
Actor Action System Response
1. The customer identifies themselves 2. Presents options
3. and so on 4. and so on
Actor Action System Response
1. The Customer inserts their card 2. Prompts for PIN.
3. Enters PIN on key pad 4. Display options menu.
5.and so on. 6. and so on.
Real Use Cases
Concretely describes the process in terms of its real current design, committed to specific I/O
technology etc.
Essential Use Cases
• Are expanded use cases, remain relatively free of technology and implementation details
• design decisions are deferred and abstracted. That is, only essential activities and motivations
• High level use cases are always essential in nature due to their brevity and abstraction.
Degree of design commitment
Essential very abstract Real very concrete
<exist on continuum>

12. 12
UML and Use Case Format:
 Header and structure of the use case are typical.
 UML does not specify a rigid format; may be altered to meet the needs
and spirit of documentation – clarity of communication
 Useful to start with high level use cases for a quick start and
understanding of overall major processes.
Example: High-Level Use Case: Buy Items
Use case: Buy Items
Actors: Customers?, Cashiers
Type: Primary
Description: A Customer arrives at a checkout with items
to purchase. The cashier records the purchase
items and collects payment. On completion, the
Customer leaves with the items.

13. 13
High-Level Use Cases
UC01: Use case: Buy Items
Actors: Customer (initiator), Cashier
Type: primary
Description: A Customer arrives at a checkout with items to
purchase. The Cashier records the purchase items
and collects a payment. On completion, the
Customer leaves with the items.
UC02:Use case: Start Up
Actors: Manager
Type: primary
Description: A Manager powers on a POST in order to prepare
it for use by Cashiers. The Manager validates
that the date and time are correct, after which
the system is ready for Cashier use.

14. Use Case Diagram
• A use (yoos) case describes what the system does, not
how it does the work.
• The use case model reflects the view of the system of the
user outside of the system.
• Symbols are:
• Actor, a stick figure.
• Use case, an oval.
• Connecting lines.
Use Case
Actor
Use case/System Boundaries
System

16. Buy Item
Cashier
Use case Diagram (Partial)
Login
Refund Item
Customer
POST

17. UML Use Case Diagram Symbols
Use Case
Actor
Boundary
Connection
Include relationship
Extend relationship
<<include>>
<<extend>>

18. 18
Some Definitions
Buy Items
UML icon for a use case
 AA scenarioscenario is ais a specificspecific sequence of actionssequence of actions andand interactionsinteractions
betweenbetween actorsactors and theand the system under discussionsystem under discussion (SuD); it is(SuD); it is
also called aalso called a use case instanceuse case instance. It is. It is one particular storyone particular story ofof
using a systemusing a system (similar defi in RUP).(similar defi in RUP).

19. Actors
• Actor:Actor: is something with behavior, such as a person (identified byis something with behavior, such as a person (identified by
role; a cashier), computer system, or organization.role; a cashier), computer system, or organization.
• Represent role played by one or more users
• Exist outside of the system
• May be a person, another system, a device, such as a keyboard
orWeb connection
• Can initiate an instance of a use case
• May interact with one or more use cases and a use case may
involve one or more actors
Actor

20. Actors (Continued)
• Actors may be divided into two groups:
• Primary actors supply data or receive information from
the system
• Secondary actors help to keep the system running or
provide help
• Help desk, analysts, programmers, etc.

21. What is a Boundary?
• A boundary is the dividing line between the system and
its environment.
• Use cases are within the boundary.
• Actors are outside of the boundary.

22. Use Case
• Consists of three things:
• An actor (user) that initiates an event.
• An event that triggers a use case.
• The use case that performs the actions triggered by the event.

23. Use Case (Continued)
• Better to create fewer use cases
• 20 use cases for a large system
• 50 use cases would be the maximum for a large system
• Can nest use cases, if needed

24. What is a Connection?
• A connection is an association between an actor and a
use case.
• Depicts a usage relationship
• Connection does not indicate data flow

25. Use Case Relationships
• Communicates
• Connect an actor to a use case
• Includes
• Use case contains a behavior that is common to more than one
use case.
• The common use case is included in other use cases.
• Dotted arrow points toward common use case.

26. What is an <<include>>
Relationship?
• A connection between two use cases
• Indicates a use case that is used (invoked) by another use
case
• Links to general purpose functions, used by many other
use cases base included<<include>>

27. Use Case Relationships (Continued)
• Extends
• A different use case handles variations or exceptions from the
basic use case.
• Arrow goes from extended to basic use case.

28. Generalize Relationship
• Generalizes
• The child use case inherits the
behavior and meaning of the
parent use case.
• The child may add to or
override the behavior of its parent.
• One thing is more general than another thing.
• Arrow points to the general thing
parent
child

29. What is an <<extend>>
Relationship?
• A connection between two use cases
• Extends a use case by adding new behavior or actions
• Specialized use case extends the general use case

30. Use Case Relationships