When to use UML?

Classical system development tool: Flowcharts

Problems:
- Complex programs flowchart too complex, non-planar graph
- Does not provide a good state-machine view
- Procedural; cannot provide good view of objects and their interaction

Universal Modeling Language
- Provides tools to describe system, components, and their interactions
- Useful in design
- Useful in documentation and system updates/modifications/debugs
- Natural tool for Objet Oriented Programming
UML overview
Graphical description of all information about a system
-- Static information : diagrams to document the structure of the system
-- dynamic information: diagrams that describe how the system behaves
Class
Component
Object
Composite structure
Deployment
Package
Structure
Use case
State machine
Activity
Interaction overview
Sequence
Communication
Timing
Interaction
Behavior
how each diagram leads to the development of
other UML diagrams
Commonly Used UML Diagrams
1. Use case diagram:
describing how the system is used.
Describes what the system does,
without describing how the system does it
The starting point for UML modeling.
2. Activity diagram.
Illustrates the overall flow of activities
Each use case may create one activity diagram.
3. Sequence diagram
showing the sequence of activities and class
relationships.
Each use case may create one or more
sequence diagrams.
4. A collaboration diagram is an alternative
to a sequence diagram.


5. Class diagram
showing classes and relationships.
Sequence diagrams and CRC cards are used to
determine classes.
6. Statechart diagram.
Each class may create a statechart diagram, useful
for determining class methods.


Example URS (university registration system)
The system should be able to handle the following
commands.
Add and remove university members (students, and
academic staff)
Add and Delete subjects
Assign and Un-assign subjects to students
Assign and Un-assign subjects to academic staff.
UML Use Case Diagram Symbols
Use Case
Actor
Boundary
Connection
Include relationship
Extend relationship
<<include>>
<<extend>>
Actors
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 or Web 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
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.
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.
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.
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
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
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.
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
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.
Generalizes
One thing is more general than another
thing.
Arrow points to the general thing.
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

Use Case Relationships
Example URS (university registration system)
Suppliers
Steps for Creating a
Use Case Model
The steps required to create a use case
model are:
Review the business specifications and
identify the actors within the problem
domain.
Identify the high-level events and develop
the primary use cases that describe the
events and how actors initiate them.
Steps for Creating a
Use Case Model
The steps required to create a use case
model are (continued):
Review each primary use case to determine
possible variations of flow through the use
case.
Develop the use case documents for all
primary use cases and all important use case
scenarios.
Rational Rose
Example URS (university registration system)
The system should be able to handle the following
commands.
Add and remove university members (students, and
academic staff)
Add and Delete subjects
Assign and Un-assign subjects to students
Assign and Un-assign subjects to academic staff.
(URS)
A University record system should keep information about its
students and academic staff.
Records for all university members are to include their id number,
surname, given name, email, address, date of birth, and telephone
number.
Students and academic staff each have their own unique ID number:
studN (students), acadN (academic employee), where N is an integer
(N>0). craw
In addition to the attributes mentioned above:
Students will also have a list of subjects they are enrolled in. A
student cannot be enrolled in any more than 10 subjects.
Academic employees will have a salary, and a list of subjects they
teach. An academic can teach no more than 3 subjects.
Use Case Diagram - URS System
system
user
academic
student
URS
del member
add member
add subject
del subject
assg subject
unass subject
enrol subject
unenrol subject
A set of ACTORS :
A set of USE CASES:
A number of
RELATIONSHIPS
Use Case Diagram (Library)
A Library System.
client employee
supervisor
library system
borrow
reserve
Order title
Fine payment
Student Assessment Management System
Teacher
Student
Printing administrator
Grade system
Record
grades
View grades
Distribute
Report cards
Create report
cards
Use Case Vs. Scenarios
Each use case is one or more scenarios.
Add Subject Use Case :
Scenario 1 : Subject gets added successfully.
Scenario 2 : Adding the subject fails since the subject is
already in the database.
Enroll Subject Use Case:
Scenario 1 : Student is enrolled for the subject.
Scenario 2 : Enrollment fails since the student is already
enrolled in the subject.
Each scenario has a sequence of steps.
Scenarios
Each scenario has a sequence of steps.
Scenario 1 : Student is enrolled for the subject.
Student chooses the enroll subject action.
Check the student has enrolled in less than 10
subjects.
Check if the subject is valid.
Assign the subject to the student.

Scenarios
Each scenario has a sequence of steps.
Scenario 2 : Enrolling fails since the student
is already enrolled in 10 subjects.
Student chooses the enroll subject action.
Check the student has enrolled in less than 10
subjects.
Return an error message to the student.
How to describe a single use case
A. Name: Give a short, descriptive name to the use
case.
B. Actors: List the actors who can perform this use
case.
C. Goals: Explain what the actor or actors are trying
to achieve.
D. Preconditions: State of the system before the
use case.
E. Description: Give a short informal description.
F. Related use cases.
G. Steps: Describe each step using a 2-column
format.
H. Postconditions: State of the system in following
completion.
How to write a use case (Summary)
Name of Use Case
Actors
Description of Actors involved in use case
Entry condition
This use case starts when
Flow of Events
Free form, informal natural language
Exit condition
This use cases terminates when
Exceptions
Describe what happens if things go wrong
Special Requirements
Nonfunctional Requirements, Constraints
Scenarios
A scenario is an instance of a use case
It expresses a specific occurrence of the use case
a specific actor ...
at a specific time ...
with specific data.

Use case diagrams
Register in Course
Add Course
Add Course Offering
Student
Find information about course
Professor Actor
Registrar Actor
Enter Grade
for Course
Extensions
Used to make optional interactions explicit or to handle
exceptional cases.
By creating separate use case extensions, the
description of the basic use case remains simple.
A use case extension must list all the steps from the
beginning of the use case to the end.
Including the handling of the unusual situation.
Generalizations
Much like superclasses in a class diagram.
A generalized use case represents several similar use
cases.
One or more specializations provides details of the
similar use cases.
Inclusions
Allow one to express commonality between several
different use cases.

Are included in other use cases
Even very different use cases can share sequence
of actions.
Enable you to avoid repeating details in multiple
use cases.

Represent the performing of a lower-level task with a
lower-level goal.

Example of generalization, extension and inclusion
Open file by
typing name
Open file by
browsing
Open file
System
Administrator
Browse for file
Ordinary User
Attempt to open file
that does not exist
extend
include
Example description of a use case
Use case: Open file

Related use cases:
Generalization of:
Open file by typing name
Open file by browsing

Steps:
Actor actions System responses
1. Choose Open command 2. File open dialog appears
3. Specify filename
4. Confirm selection 5. Dialog disappears

Use case: Open file by typing name

Related use cases:
Specialization of: Open file

Steps:
Actor actions System responses
1. Choose Open command 2. File open dialog appears
3a. Select text field
3b. Type file name
4. Click Open 5. Dialog disappears

Example (continued)
Use case: Open file by browsing

Related use cases:
Specialization of: Open file
Includes: Browse for file

Steps:
Actor actions System responses
1. Choose Open command 2. File open dialog appears
3. Browse for file
4. Confirm selection 5. Dialog disappears

Example (continued)
Use case: Attempt to open file that does not exist

Related use cases:
Extension of: Open file by typing name

Actor actions System responses
1. Choose Open command 2. File open dialog appears
3a. Select text field
3b. Type file name
4. Click Open 5. System indicates that file
does not exist
6. Correct the file name
7. Click Open 8 Dialog disappears

Example (continued)
Use case: Open file by browsing (inclusion)

Steps:
Actor actions System responses
1. If the desired file is not displayed,
select a directory
2. Contents of directory is
displayed
3. Repeat step 1 until the desired file
is displayed

4. Select a file

Example (continued)
Structure of a Use Case Specification
Name
Actors
Preconditions
Post conditions
Success Scenario
Alternatives flows
Trigger
Triggers
What starts the use-case?
Examples:
Customer reports a claim
Customer inserts card
System clock is 10:00pm

Preconditions
What the system needs to be true before
running the use-case.
Examples
User account exists
User has enough money in her account
There is enough disk space
Post-Conditions
A post-condition is the outcome of the use-case.
Examples
Money was transferred to the user account
User is logged in
The file is saved to the hard-disk

Success Scenario
The success scenario is the main story-line of the
use-case
It is written under the assumption that everything
is okay, no errors or problems occur, and it leads
directly to the desired outcome of the use-case
It is composed of a sequence of action steps
Example:
1. Administrator enters course name, code and description
2. System validates course code
3. System adds the course to the db and shows a confirmation message
Interaction
step
Validation
Step
Internal Change
Step
(plus) Interaction
Step
Use-Cases Common Mistakes
Complex diagram
No system
No actor
Too many user interface details
User types ID and password, clicks OK or
hits Enter
Very low goal details
User provides name
User provides address
User provides telephone number

Alternative Flows
Success
Scenario
Shortcuts
Exceptions
Endpoints
Used to describe
exceptional
functionality
Examples:
Errors
Unusual or rare
cases
Failures
Starting points
Endpoints
Shortcuts
Starting points
Alternative Flows - Example
Errors:
Case did not eject properly
Any network error occurred during steps 4-7
Any type of error occurred
Unusual or rare cases
Credit card is defined as stolen
User selects to add a new word to the dictionary
Endpoints
The system detects no more open issues
Shortcuts:
The user can leave the use-case by clicking on the
esc key

Exercise
I am the manager of a theatre.
I want to create an automated movie ticket machine.
You are analysts who need to describe
what the customer wants as a set of use cases
Simplifying assumptions:
One movie showing at a time
Movie time is same every day, only one time, same price
Only manager can change/add movie
Customer can only buy tickets
Who or what are the actors?
What are the use cases (goals of actors)?


Use case diagram
for Movie Ticket Machine
Use cases
for Manager
Use case: Set title
Actors: Manager, Machine
1. Manager requests a change of movie title
2. Machine asks manager for new movie title
3. Manager enters movie title
Use case: Set price
Actors: Manager, Machine
1. Manager requests a change of ticket price
2. Machine asks manager for new price for movie title
3. Manager enters ticket price
Alternatives: Invalid price
If manager enters price below $1 or greater than $10
3a. Machine asks manager to reenter price
Use case: Set seats
Actors: Manager, Machine
1. Manager requests a change in number of seats
2. Machine asks manager for number of seats in theatre
3. Manager enters number of seats
Alternatives: Invalid number of seats
If manager enters number less than 20 or greater than 999
3a. Machine asks manager to reenter number of seats

Use cases for Customer
Use case: # of tickets
Actors: Customer, Machine
1. Customer enters number of tickets
2. Machine displays total balance due
Alternative: Customer wants zero tickets
At step 1, customer enters zero tickets
1a. Display thank you message
1b. Set balance to $0.0
Use case: Return change to customer
Actors: Customer, Machine
1. Customer requests change
2. Machine dispenses money
3. Machine updates customer balance

Use cases for Customer
Use case: Buy tickets
Actors: Customer, Machine
1. Customer requests tickets
2. Machine tells customer to put
balance due in money slot
3. Customer enters money in money slot
4. Machine updates customer balance
5. Customer requests tickets
6. Machine prints tickets
7. Machine updates number of seats
Alternative: Insufficient seats
At step 1, if number of tickets requested
is less than available seats,
1a. Display message and end use case
Alternative: Insufficient funds
At step 5, if money entered < total cost,
5a. Display insufficient amount entered
5b. Go to step 3