UML
Basic Behavioral Modeling
Part I
Use Cases 1
UML Bird’s Eye View
Building Blocks:
Things: abstractions, main concepts in a model
Relationships: tie the things together
Diagrams: group interesting collections of things
Use Cases 2
Things in the UML
Structural Things (7)
static part of a model, conceptual or physical elements
nouns of UML Models
Behavioral Things (2)
dynamic parts of models
verb, representing behavior over time and space
Grouping Things (1)
Organizational parts of models, decomposition element
Annotational Things (1)
explanatory parts of models, comments about other elements
Use Cases 3
Relationships in the UML
Dependency
semantic relationship, a change in one element may affect the
other element
Association
structural relationship that describes a set of links among
objects
Generalization/Specialization
relationship in which objects of the specialized element (child)
are substitutable for objects of the generalized element (parent)
Realization
semantic relationship between classifiers (class realizes an
interface or collaboration realizes a use case)
Use Cases 4
Diagrams in the UML
• Class diagram
• Object diagram
• Use case diagram
• Sequence diagram
• Collaboration diagram
• Statechart diagram
• Activity diagram
• Component diagram
• Deployment diagram
Use Cases 5
Rules of the UML
UML defines Rules for
Names
Scope
Visibility
Integrity
Execution
Use Cases 6
Common Mehanism in the UML
Specifications
Adornments
Common Division
Extensibility Mechanisms
Use Cases 7
Behavioral Modeling
Use Cases / Use Cases Diagrams
Interactions / Interaction Diagrams
State Diagrams
Activity Diagrams
Use Cases 8
Use Cases
Description of a set of sequences of actions, that a system
performs to yield an observable result to an end-user
Categories of interactions between the system to be built and
external actors
Identify high-level services provided by the system
Specify the behavior of a system
Popularized by Ivar Jacobson with Objectory
Have been adopted by or have influenced many methods (eg.
OMT, Fusion, Booch)
Use Cases 9
Use Cases (cont.)
Can be applied to whole system as well as part of system such as
a subsystem or a class
Sources of integration tests and system tests
May have variants: specialized use cases or extension of use
cases.
Do not specify any implementation detail
Main communication tool with end-user
Each use case must have a name (simple or path name)
Use Cases 10
Actors
Objects outside the system which play a particular role
Represent the user(s) of the system
Interact with the system through use cases
May participate in more than one use case
May or may not be represented as a class or object in the object
model
Also known as agents (Jacobson)
Use Cases 11
UML Use Case
Graphical Representation
Storage depot system
Delivery
Collection
Clerk Status Storage
Use case
Actor
Manager
Use Cases 12
Why Modeling Use Cases
Use Case model describes WHAT the system will do at a high-level
User focus
- Capture requirements from user's perspective.
- Users are involved.
Goal is to scope the project and give the application some structure
- Use Cases are the unit of estimation
- Uses Cases are smallest unit of delivery
- One way of estimating the percentage of requirements captured.
- Prioritizing use cases for "phased delivery" according to user's
immediate needs.
- Better way of estimating the percentage of requirements
completed during development
Use Cases 13
Benefits of use cases
Good way to start identifying objects from scenarios.
Test plan can be immediately generated based on use cases.
Easier user validation.
Helps technical writers in structuring the overall work on the
users manuals at an early stage.
Better traceability throughout the system development process.
Quality of the software is improved by identifying the exception
scenarios earlier in the development process.
Use Cases 14
Problems with use cases
What is the right granularity
What is a correct Use Case
Explosion of different scenarios
Focus on functions, with potential for functional decomposition
Too often too informal
Use Cases 15
Use Cases and Scenarios
Scenario is a specific sequence of actions
Scenario is one instance of a Use Case
Typically many scenarios correspond to one Use Case
Example:
Use Case = Hire Employee
Scenarios
- Hire at Job Fair
- Hire through newspaper ad
- Hire from internal promotion
- Hire Temp
Use Cases 16
Use Cases and Collaborations
Use Case captures WHAT the system does
Use Cases do not specifies HOW the System does it
Development effort is aimed at implementing the use cases by
creating a society of classes working together
These interacting classes are modeled using Collaborations
A Collaboration is the realization of a Use Case
A Collaboration represents how responsibilities are distributed
across objects
A Collaboration has a Static and a Dynamic aspect
Use Cases 17
Organizing Use Cases
Relationships: Generalization, Include (Use) and Extend
Generalization:
– Like for Classes
Include:
- Use: Contains another complete use-case
Extend:
- Extends another use-case
- used for optional separate flow (exception)
Beware:
- Over-use of extends = functional decomposition
- Rumbaugh says Use = aggregation and Extend = inheritance
Use Cases 18
Hints and Tips
• Each Use Case should represent a single, identifiable and
reasonably atomic part of the behavior of the system
• Factors Common Behavior by pulling such behavior from other use
cases that it includes
• Factors variants by pushing such behavior into other use cases that
extend it
• Describe flow of vents clearly enough for anyone to easily
understand it
• Each Use Case is described by a number of scenarios that specify
the normal and variants
Use Cases 19
Use Case Diagrams
system is represented by a large rectangle
uses cases are represented as ellipses within the system
rectangle
actors are represented as stick figure outside the system
an arrow connects the initiating actor to the use case (ending
at the use case)
other participating actors are joined by arrows terminating at
the actor
Use Cases 20
Banking System Use Case Diagram
open_account Cash
Dispenser
withdraw_cash
Customer
clear_checks Clerk
loan_application
Manager get_report Loan Officer
Use Cases 21
Use Case Identification Steps
• Determine the boundary of the system
- consider system as a single “black box” object
• Identify who is going to be using the system directly - e.g. hitting
keys on the keyboard. These are the Actors
- start by considering physical object
- an individual object may play several roles
• Choose One of these Actors and determine the fundamental ways
in which each actor uses the system
- each of these is a use case
- must be enumerable
- for each of those Use Cases decide on the most usual course when that
Actor is using the system. What normally happens. This is the basic
course
Use Cases 22
Use Case Identification Steps (2)
• Describe it as "Actor does something, system does something. Actor
does something, system does something." but keep it at a high level.
do not mention any GUI specifics
only describe things that the system does that the actor would be aware
of and conversely you only describe what the actor does that the system
would be aware of.
do not worry about the alternate paths (extends) or common courses
(uses) - Yet -
• Review each Use Case descriptions against the descriptions of the
other Use Cases.
• Once basic course is OK, consider the alternates and add those as
extending use cases.
Use Cases 23
Use Case Identification Steps (3)
• Good way of getting started with Use Case modelling.
• Once started and comfortable with this process, next step:
understand the trade-offs that can be made
simplicity versus "completeness"
putting too much in is the most common mistake.
Use Cases 24
Use Case Textual Descriptions
OPEN_ACCOUNT - a clerk requests the system to create a new account
WITHDRAW_CASH - a customer requests the system to withdraw a
specified amount of money from a specified account
CLEAR_CHECKS - a clerk instructs the system to update all accounts
according to specified transactions including checks
LOAN_APPLICATION - a customer files a loan application
GET_REPORT - a manager or loan officer requests a report of the days
transactions from the system
Use Cases 25
Use Cases Diagram Hint and Tips
• Put all the Use Cases that describe one aspect of the system
together
• Contains only those use cases and actors essential to
understanding that aspect
• Diagram should be named to communicate its purpose
• Minimize crossing lines
• Don’t draw too many use cases or too many relationships in one
diagram
Use Cases 26
Modeling Exercices:
• Develop the Use Cases for a Telephone Catalog System
• Develop the Use Cases for a Point Of Sales System
grocery store requires a computer system to control the checkout
points at which customers pay for the items they have selected.
Using the bar code the checkout controller determine the price,
name, number in stocks, sell-by-date (if applicable)
• Develop the Use Cases for a Access Control System
System maintains the security and access t a number of doors
inside or into a building. Doors are linked to keypads and card
reader. All doors are connected to a central controlling unit
• Develop the Use Cases for a Course Scheduling System
Use Cases 27
Modeling Exercices:
• Develop the Use Cases for a Library System
supports library
library lends books and magazines to borrowers who are
registered in the system, as are books and magazines
library buys new titles, eventually in multiple copies
old books and magazines are removed when out of date.
borrower can reserve a book or magazine not currently
available
Use Cases 28
Detail Use Cases
• Start with a short, step-by-step description of the use-case flow
of events, and gradually make it more detailed.
• Describe how the use case start and what is the signal that
activates the use case.
• Describe how the use case terminate
• Describe what will reside inside the system, and what will
reside outside the system.
• Describe the interaction between use case and actors.
• Describe how the use case exchange data with an actor.
Use Cases 29
Use Case Details
Name
The name of the use case.
Brief Description
A brief description of the role and purpose of the use case.
Flow of Events
A textual description of what the system does in regard to the use
case. Understandable by the customer. Include the main flow of
events as well as the alternate flow of events
Special Requirements
A textual description that collects all requirements, such as non-
functional requirements, on the use case, that are not considered in
the use-case model, but that need to be taken care of during design
or implementation.
Use Cases 30
Use Case Details
Preconditions
A textual description that defines the state of the system prior to the
use case may being performed.
Postconditions
A textual description that defines a list of possible states the system
can be in immediately after a use case has finished.
Extension points
A list of locations within the flow of events of the use case at which
additional behavior can be inserted using the extend-relationship.
Relationships
The relationships, such as communicates-associations, include-,
generalization-, and extend-relationships, in which the use case
participates.
Use Cases 31
Use Case Details - Example
Name :
Register for Courses
Description:
This use case is started by the actor student. It provides the capability for the
student to manage his registration to a course for a semester, and to have the
billing information sent to the Billing Office.
Main Flow of Events:
The student enters his Id.
The system verifies the student Id, and prompt the student to select the current or a
future semester.
The student selects the semester.
The system prompts the student to select the desired activity (create a registration,
review a registration, change a registration).
Once completed the student indicates that the activity is completed.
The system acknowledge and displays the result of the activity.
The system sends the billing information to the billing system for processing.
Use Cases 32
Use Case Details – Example (cont.)
Alternative Flow of Events:
1- If an invalid Id is entered, the system will not allow access to the registration
system and displays an error message to the student.
Special Requirements:
The student should be able to access the system through the web. It should take less
than 30 seconds to display the web page. A student can register to a maximum of 5
courses per semester.
Pre-Conditions:
The system is operational.
Post-Conditions:
The student information has been updated. His bill is sent.
Extension Points:
None
Relationships:
None
Use Cases 33
