Moving Towards Specifications

• What functions will the new system

provide?
Picturing Programs – How will people interact with it?
– Describe functions from a user’s perspective

Jennifer Campbell • UML Use Cases

– Used to show:
(slightly edited by Greg Wilson) • the functions to be provided by the system
CSC301 – Fall 2007 • which actors will use which functions

CSC301 University of Toronto 2

UML Use Case Diagrams Notation for Use Case Diagrams

Communication
Capture the relationships between actors association Use case

and use cases.

Change a
client contact Place book order
Add a Staff contact
Campaign
new client
Manager Customer
Actor
Record
client payment
Accountant System
boundary

CSC340 University of Toronto [BMF99] 3 CSC301 University of Toronto [BMF99] 4

1
 Use cases and Actors Example: Staff Management
Add new Staff
staff member Management
• Use case: System
– a pattern of behavior that the new system is required Add new
to exhibit staff category
– a sequence of related actions performed by an actor
and the system via a dialogue. Change rate
for staff category
• Actor:
Accountant
– anything that needs to interact with the system: Change category
• a person for staff member

• a role that different people may play

• another (external) system. Calculate staff
bonuses

CSC340 University of Toronto 5 CSC340 University of Toronto 6

<<extends>>
When one use case adds behaviour to a base case
– used to model a part of a use case that the user may see as
optional system behavior;
– also models a separate sub-case which is executed conditionally.
<<uses>>
One use case invokes another (like a procedure call);
– used to avoid describing the same flow of events several times
– puts the common behavior in a use case of its own.

Check out item

Distribute info
to students Cashier <<uses>>
Registrar <<extends>>

Swipe UPC
Distribute schedule code
info to students
CSC340 University of Toronto 7 CSC340 University of Toronto 8

2
 Example: Car Example: Meeting Scheduler
Driver GasAttendant Mechanic
Initiator Participant

<<uses>> <<uses>>
Fill Up Check Oil Fix Car Edit <<extends>> Provide
Generate Withdraw constraints
Drive Schedule Constraints
Schedule

< < us
<<uses>> meeing

>>
<<uses>> <<extends>>

es
us
<<

es>>
<<uses>> Turn On

<<
us
Fix car on
Engine >>

es
the road ses
<<u

>>
Validate
User

CSC301 University of Toronto 9 CSC301 University of Toronto 10

Identifying Actors Finding Use Cases

• Look for:
– the users who directly use the system
– also others who need services from the system
• To find actors that are people/roles ask:
– Who will be a primary user of the system? (primary actor)
– Who will need support from the system to do her daily tasks?
– Who will maintain, administrate, keep the system working?
(secondary actor)
– Who or what has an interest in the results that the system
produces ?
• To find actors that are external systems ask:
– Which hardware devices does the system need?
– With which other systems does the system need to interact with?
CSC340 University of Toronto
• For each actor, ask the following questions:
– Which functions does the actor require from the system?
– What does the actor need to do ?
– Does the actor need to read, create, destroy, modify, or store
some kinds of information in the system ?
– Does the actor have to be notified about events in the system?
– Does the actor need to notify the system about something?
– What do those events require in terms of system functionality?
– Could the actor’s daily work be simplified or made more efficient
through new functions provided by the system?
11 CSC301 University of Toronto 12

3
 Generalizations
Generalization relations: “is a” • Actor classes
– It’s sometimes useful to identify
classes of actor
• E.g. where several actors belong
to a single class
• Some use cases are needed by
all members in the class
• Other use cases are only needed
by some members of the class
– Actors inherit use cases from
the class
• Use Case classes
– Sometimes useful to identify a
generalization of several use
cases
UML Sequence Diagrams
• Describe a Use Case using Sequence Diagrams
– Sequence diagrams show step-by-step what’s
involved in a use case
• Which objects are relevant to the use case
• How those objects participate in the function
– You may need several sequence diagrams to
describe a single use case.
• Each sequence diagram describes one possible scenario for
the use case
– Sequence diagrams…
• …should remain easy to read and understand.
• …do not include complex control logic

CSC301 University of Toronto 13 CSC301 University of Toronto 14

Example: Place
book order Example: Calculate staff bonuses
Place book order Customer
Customer Customer Invokes
initiates the the search method iteration
sequence in OnlineStore
:Accountant :PayrollSystem :Staff :Bank

:Customer :OnlineStore :OrderDepartment :Bank

list payroll
[for each staff] *get account

search for book

Activation
[for each staff] *calculate bonus

Time [book exists] order book

update payroll
submit order request
*[for each staff] update account

debit account *[for each staff] schedule direct deposit

CSC301 University of Toronto 15 CSC301 University of Toronto 16

4
 Example: Add an advertisement
• Objects “own” information and behaviour
Modelling Sequences of Events
– Objects don’t “know” about other objects’
information, but can ask for it.
– To carry out business processes, objects
have to collaborate.
• …by sending messages to one another to invoke
each others’ operations
– Objects can only send messages to one
another if they “know” each other
• I.e. if there is an association between them.

CSC301 University of Toronto 17 CSC340 University of Toronto 18

UML Activity Diagrams: Example 1:

Legend Credit Card Activation
Activity
The customer receives the card, and then
activates the card.
Initial State
Initial state Activities Final state
Final State
Receive Credit Card Activate Credit Card
Fork/Join

Decision
CSC301 University of Toronto 19 CSC301 University of Toronto 20

5
 Example 3: Order System
Example 2: Order System
(with loop)
Receive Guard Receive
[failed] [failed]
Order Cancel Order Order Cancel Order
Authorize Authorize
Payment Decision Payment

[succeeded] [succeeded]
Assign Items Dispatch Order Assign Item Dispatch Order
to Order * [for each to Order
Fork item in order]
Join

CSC301 University of Toronto 21 CSC301 University of Toronto 22

A few style guidelines Swimlanes

• The diagram should have start and end state(s). • Swimlanes can be used to group activities
• Diagrams are read from top-left to bottom-right based on the actor (person, business unit,
– put the initial and final states in those locations
• Each activity should have at least one transition etc) who performs them.
into it and at least one transition out of it. • If an activity diagram is partitioned into
• The diagram should be decidable swimlanes, than each activity must appear
– transitions out of a decision points should have
mutually exclusive guards in exactly one swimlane.
– the set of guards should be complete
• Transitions may cross swimlanes.
• Each fork should have a corresponding join.
[Amb03]
CSC301 University of Toronto 23 CSC301 University of Toronto 24

6
Example 3: Diagram with Swimlanes Classes
Customer Sales Warehouse
• A class describes a group of objects with
– similar properties (attributes),
Request – common behaviour (operations),
Product – common relationships to other objects,
– and common meaning (“semantics”).
Process Line Item Pull Materials • Example:
– Employee: has a name, employee number and department;
Ship Order an employee is hired, and fired; an employee works on one
or more projects
:Employee
name Name (mandatory)
Receive Order Attributes
Bill Customer (optional) employee number
department
hire
Add Remainder fire Operations
Pay Bill Close Order
to Stock
[BRJ99] works on projects (optional)
CSC301 University of Toronto 25 CSC301 University of Toronto 26

Objects vs. Classes UML Class Diagrams

• The instances of a class are called objects.
• UML Class Diagrams show classes and their
Fred_Bloggs:Employee
relationships
name: Fred Bloggs
employee number: 234609234 • Relationships: connections between classes
department: Marketing – Objects do not exist in isolation from one another
– Types of UML relationships:
– Two different objects may have identical attribute values (like two
people with identical name and address) • Association
• Objects have associations with other objects • Aggregation and Composition
– E.g. Fred_Bloggs:employee is associated with the KillerApp:project
object • Generalization
– But we will capture these relationships at the class level (why?) • Dependency
– Note: Make sure attributes are associated with the right class • Realization } not useful for analysis
• E.g. you don’t want both managerName and manager# as attributes of
Project! (…Why??)

CSC301 University of Toronto 27 CSC301 University of Toronto 28

7
 Class Associations Association Multiplicity
Multiplicity Multiplicity
A Client has A StaffMember is
Name assigned zero or
exactly one StaffMember of the more Clients • Multiplicity: the minimum and maximum
as a contact person
association
times an object can be associated with the
:Client related object
:StaffMember
company name
name 1 assigned to 0..* mailing address • Examples:
id number email
start date contact fax – Optional (0 or 1) 0..1
person phone
– Exactly one 1 = 1..1
Direction – Zero or more 0..*
The “assigned to”
association should be – One or more 1..*
Role read in this direction – A range of values 1..6
The StaffMember’s
role in this association
– A set of ranges 1..3,7..10,15,19..*
is as a contact person
CSC301 University of Toronto 29 CSC301 University of Toronto 30

Exercise: Multiplicities Association Classes

:Appointment
:Patient :Doctor Sometimes the association is itself a class
schedules time attends
insurance carrier • …because we need to retain information about the association
1
1..? 0..* date
0..? 0..?
0..* 1..* primary office
1..? • …and that information doesn’t naturally live in the classes at the
reason specialization
book appointment ends of the association
explain symptoms assess patient • E.g. a “title” is an object that represents information about the relationship
cancel without between an owner and her car
notice
• Does an appointment need be • Does a doctor need to attend
scheduled by a patient? appointments? :Car :Person
– Yes! An appointment is – No.
scheduled by at least one patient.
• Can a doctor attend multiple
VIN(vehicle Id Number) 0..* owns 1 name
address
• Can the same appointment be year made
appointments? mileage owner drivers licence number
schedule by multiple patients? – Yes.
– If not, then exactly one Patient
schedules each appointment. • Does an appointment need to be
attended by at least one doctor? :Title
• Does a patient have to schedule year bought
an appointment? – Yes. initial mileage
– No. • Can an appointment be attended price paid
• Can a patient schedule more than by multiple doctors? licence plate number
one appointment? – If yes, then the multiplicity is
– If yes, then the multiplicity is 0..* 1..*.
CSC301 University of Toronto
[DWT05]31 CSC301 University of Toronto 32

8
 Aggregation Composition
The “is part of” or “whole-part” relationship • Strong form of aggregation that implies ownership:
– if the whole is removed from the model, so is the part
– the whole is responsible for the disposition of its parts
An employee is part of a team.
:Team :Employee
:Car :Engine
0..* 1..*
1 1

Note: The multiplicity should be 1 when the

association is compostion (i.e., a car should always
[Amb03] have (at least) one engine).
CSC301 University of Toronto 33 CSC301 University of Toronto 34

Generalization More on Generalization

Subclasses inherit attributes, associations, & operations from • Usefulness
the superclass :Address
– Can easily add new subclasses if the organization
:Person
0..* lives at 1 street changes
name city
SIN province • Look for generalizations in two ways:
postal code
– Top Down
• Subdivide an existing class
• Or you have an association that expresses a “kind of”
relationship
:Student :Professor • E.g. “Most of our work is on advertising for the press, that’s
newspapers and magazines.”
student id employee id
major department – Bottom Up
salary • You notice similarities between classes you have identified
add course • E.g. “We have books and we have CDs in the collection, but
drop course teach course they are all filed using the Dewey system, and they can all be
[Amb03] lent out and reserved”
CSC301 University of Toronto 35 CSC301 University of Toronto 36

9
 More on Generalization [2] Finding Classes
• Don’t generalize just for the sake of it • Look for nouns and noun phrases in
– Be sure that everything about the superclass stakeholders’ descriptions of the problem
applies to the subclasses – include in the model if they explain the nature
or structure of information in the application.
– Be sure that the superclass is useful as a
class in its own right • It’s better to include many candidate
– Don’t add subclasses or superclasses that are
classes at first
not relevant to your analysis – You can always eliminate them later if they
turn out not to be useful
– Explicitly deciding to discard classes is better
than just not thinking about them
CSC301 University of Toronto 37 CSC301 University of Toronto 38

Possible Classes Possible Classes [2]

:PrimeMinister
• External Entities :PayrollSystem • Roles
– …that interact with the system – played by people who interact
being modeled with the system
• E.g. people, devices, other • Organizational Units
systems – that are relevant to the :HumanResources
application
• Things :Invoice • E.g. division, group, team,
– …that are part of the domain etc.
being modeled • Places
• E.g. reports, displays, signals, – …that establish the context of
etc. :Warehouse
the problem being modeled
• Occurrences or Events • E.g. manufacturing floor,
loading dock, etc.
:LandTransfer
– …that occur in the context of • Structures
the system
– that define a class or
• E.g. transfer of resources, a assembly of objects :Sensor
control action, etc. • E.g. sensors, four-wheeled
vehicles, computers, etc.
[Pre97] [Pre97]
CSC301 University of Toronto 39 CSC301 University of Toronto 40

10
 Coad & Yourdon’s Criteria
Selecting Classes
for Selecting Classes
• Discard classes for concepts which: • Retained information: Will the system need to
remember information about this class of objects?
– Are beyond the scope of the analysis • Needed Services: Do objects in this class have
– Refer to the system as a whole identifiable operations that change the values of their
– Duplicate other classes attributes?
• Multiple Attributes: Does the class have multiple
– Are too vague or too specific attributes?
• e.g. have too many or too few instances • Common Attributes: Does the class have attributes that
• Include external entities as classes if they: are shared with all instances of its objects?
– Produce or consume information essential to • Common Operations: Does the class have operations
that are shared with all instances of its objects?
the system
[Pre97]
CSC301 University of Toronto 41 CSC301 University of Toronto 42

Object Behaviour Statecharts

• There are a finite number of states (all attributes have finite ranges)
• All objects have “state” initial state partialPayment()
– An object has a value for each of its attributes
partialPayment()
– Each possible assignment of values to attributes is a state unpaid partially paid transition
• (and non-existence is a state, although we normally ignore it)
finalPayment() event
• Example: Invoice object: state
finalPayment()
partialPayment() fully paid
final state
:Invoice partialPayment()
• The model specifies a set of traces
unpaid partially paid – E.g. partialPayment();partialPayment;finalPayment()
initialBalance – E.g. partialPayment();finalPayment()
currentBalance finalPayment() – There may be an infinite number of traces (and traces may be of infinite length)
partialPayment() • The model excludes some behaviours
finalPayment() finalPayment() – E.g. no trace may have a finalPayment() followed by a partialPayment()
fully paid

[Mac01]
CSC301 University of Toronto 43 CSC301 University of Toronto 44

11
 Abstraction Exercise: Abstraction
For each state, what are the properties or value ranges of
• The state space of most objects is enormous
initialBalance and currentBalance that interest us?
– State space size is the product of the range of each attribute
5
• E.g. object with five boolean attributes: 2 +1 states
5
• E.g. object with five integer attributes: (maxint) +1 states initialBalance > currentBalance
• E.g. object with five real-valued attributes: …?
:Invoice partialPayment()
– If we ignore computer representation limits, the state space is
infinite initialBalance
partialPayment()
• Only part of that state space is “interesting” currentBalance unpaid partially paid
– Some states are not reachable partialPayment()
– Integer and real values usually only vary within some relevant finalPayment() finalPayment()

range finalPayment()
– Often not interested in the actual values, just certain ranges: fully paid
• Example for Age: age<18, 18≤age≤65, age>65
• Example for Cost: cost ≤ budget, cost==0, cost > budget, initialBalance == currentBalance
cost > (budget+10%)
currentBalance == 0

CSC301 University of Toronto 45 CSC301 University of Toronto [Mac01]46

Transitions : CourseRegistration
maxCapacity
Transitions [2]
currCapacity
A transition consists of three parts: enrollmentStatus event [guard] / action
classList • A guard is a Boolean condition that must be
event [guard] / action addStudent()
true in order for a transition to “fire”.
removeStudent()
openEnrollment() – When an event occurs the guard conditions
closeEnrollment() are checked, and if they are met, then the
• A transition is the movement from one state to another. printClassList() transition fires.
• States are either “on” or “off” at a given point in time. • The action is a procedural expression to be
performed when the transition fires.
• If a state is on, then transitions from it are enabled. addStudent() [currCapacity < = maxCapacity]
action
• Transitions are triggered by events. closeEnrollment()/ printClassList
space available
partialPayment()

partialPayment() closeEnrollment()/ printClassList

unpaid partially paid removeStudent() closed to enrollment

finalPayment() addStudent()[ currCapacity = = maxCapacity]

full
finalPayment()
fully paid guard
CSC301 University of Toronto [SJB05]47 CSC301 University of Toronto 48
[Amb03]

12
 Events Events [2]
• Call events occur when an object receives a call for one • Change events occur when a condition becomes true
of its operations to be performed – denoted by the keyword ‘when’
– Example: Bill class
– Example: Invoice class
payBalance()
when: [ currentBalance == 0]
unpaid paid
unpaid paid

• Signal events occur when an object receives an explicit • Time events mark the passage of a designated period of
(real-time) signal time
– Example signal: Mouse click
– Example: Exam class
– More useful in design after: [3 hours]
– Syntax is the same as call events in progress complete

CSC301 University of Toronto [BMF99] 49 CSC301 University of Toronto [BMF99] 50

Superstates Example: Person

States can be nested, to make diagrams simpler child
– A superstate consists of one or more states.
– Superstates make it possible to view a state diagram at
adult
different levels of abstraction.
OR superstates AND superstates
– when the superstate is “on”, only working age senior
(concurrent substates)
one of its substates is “on” – When the superstate is “on”, all of
its states are also “on”
employed – Usually, the AND substates will be single coupled
nested further as OR superstates
employed married
widowed
unmarried
probationary
after [6 months] on payroll divorced separated deceased
full
assigned
to project
CSC301 University of Toronto 51 CSC301 University of Toronto 52

13
 Class Diagrams and Statecharts
• Consistency Checks between diagrams
– Each statechart should correspond to one
class on the Class diagram.
– All events in a statechart should appear as:
• operations (methods) of an appropriate class in the
class diagram
– All actions in a statechart should appear as:
• operations (methods) of an appropriate class in the
class diagram
Style Tips
• The diagram should have start and end state(s).
• Diagrams are usually read from top-left to bottom-right,
so put the start and end states in those locations.
• Each state should have at least one transition into it and
at least one transition out of it.
• The diagram should be deterministic.
• Use a superstate when multiple states have a common
entry or exit condition.
• It is fine for guards on transitions from a state to not form
a complete set.
[Amb03]

CSC301 University of Toronto 53 CSC301 University of Toronto 54

Entity Relationship (ER) Schema Entities

• Comparable to UML class diagrams
– Not equivalent
• Good for describing data requirements for a new
information system.
• Direct, easy-to-understand graphical notation
• Translates readily to relational schema for
database design
– more abstract than relational schema
– e.g. can represent an entity without knowing its
properties
• Classes of objects with properties in
common and an autonomous existence
– E.g. City, Department, Employee, and Sale
• An instance of an entity is an object in the
class represented by the entity
• E.g. Stockholm, Helsinki, are examples of
instances of the entity City
• Usually described using nouns.
City Department Employee Sale

CSC301 University of Toronto 55 CSC301 University of Toronto 56

14
 Relationships Examples
• Logical links between two or more entities. Student Writes Exam
– E.g. Resides is a relationship that can exist between
a City entity and a Person entity
• An instance of a relationship is an n-tuple of
instances of entities
Manages
– E.g. the pair (Johanssen,Stockholm), is an instance
in the relationship Resides.
• Usually described using verbs (sometimes Employee Department
nouns)
WorksIn
Meets Resides Owns

CSC301 University of Toronto 57 CSC301 University of Toronto [RG00] 58

Attributes Internal Identifiers

• Associate a value belong to a set (domain) with each • Identifiers are also known as keys.
instance of an entity or relationship. • An identifier may be formed by one or more attributes of the entity
y ea r
itself
p ro gra m c o u rs e
• A relationship is identified using identifiers for all the entities it
s tu d e n tID relates
– E.g. the identifier for the relationship Person-Owns-Car is a tuple of
the Person and Car identifiers
S tu d en t
Student W rite s
Writes E xa m
Exam

internal, multi-attribute internal, single-attribute

s in ce
Manages
M a n a g es nam e firstName lastName model
nam e Employee Department registration
E m p lo y e e D e p a rtm en t dateOfBirth
address colour
WorksIn
W o rks In b u d ge t
S IN
Person Owns Car
s in ce

CSC301 University of Toronto [RG00] 59 CSC301 University of Toronto 60

15
 Example: Instances for Owns Meaning of ER Diagrams
Course Meets Room
o1
P1 • Course and Room are entities.
o2 C1 – Their instances are particular courses (eg CSC340S) and rooms
o3 (eg BA1130)
P2 • Meets is a relationship.
P3 C2 – Its instances describe particular meetings.
o4 – Each meeting has exactly one associated course and room
P4
o5 C3
P5 o6

Person Owns Car

• The unique identifiers for Person and Car clearly identify
each entity.
• Instances of the Owns relationship are tuples of (Person,
Meets instances
Car). Course instances Room instances
CSC301 University of Toronto 61 CSC301 University of Toronto 62

Exercise: Selecting Identifiers Cardinalities

Course Meets Room
• Cardinalities constrain participation in relationships
– minimum and maximum number of relationship instances in which an
• What attributes should we use to describe Meets? entity instance can participate.
– <coursename,day,hour> – E.g.
• Only one section of a course can meet at a time (day and
hour) (1,5) (0,50)
Employee Assigned Task
– <coursename>
• Only one meeting per given course name Employee is assigned 1 to 5 tasks. Tasks are assigned to 0 to 50
employees.
– <courseinstructor,room> • Cardinality is any pair of non-negative integers (min,max), where
• Only one meeting for a given instructor and room min <= max
– An instructor must have all her meetings in different rooms! – (1,1) - One-to-One
– (1,N) - One-to-Many
– <courseinstructor> – (N,1) - Many-to-One
• An instructor participates in at most one meeting – (M,N) - Many-to-Many

CSC301 University of Toronto 63 CSC301 University of Toronto 64

16
 Cardinalities of Attributes Cardinalities of Attributes [2]
• Attributes can also have cardinalities • Multi-valued attribute surname LicenceNumber
– To describe the minimum and maximum number of values of the cardinalities are
attribute associated with each instance of an entity or a problematic
relationship. – Usually better Person
– The default is (1,1) modelled with
additional entities (0,N)
– Optional attributes have cardinality (0,1) linked by one-to-many
(or many-to-many) Owns
CarRegistration relationships
(0,N) (1,1)
CarRegistration

(0,1) (0,N) Car

LicenceNumber Person
(0,1)
surname LicenceNumber Person

surname
Registration

CSC301 University of Toronto 65 CSC301 University of Toronto 66

Weak Entities Recursive Relationships

studentID
studentID name
name • An entity can have
year
year
relationships with
(1,1)
(1,1) (1,N) city
city
Student
Student Enrolls
Enrols University
University
itself…
surname
surname
address
address

• Student is a weak entity.

– Cannot be uniquely identified using only the studentID. • If the relationship is not
– Need to know which university she is enrolled in.
symmetric…
• A weak entity can only be identified using the attributes
of another entity. – …need to indicate the
– It must be in a (1,1) relation with the relationship used to two roles that the entity
uniquely identify it.
• Also called an external identifier plays in the relationship.

CSC301 University of Toronto 67 CSC301 University of Toronto 68

17
 Ternary Relationships Generalizations
• Show “is-a” relationships between entities
age
surname taxCode address taxCode

Person Professional

Man Woman Lawyer Engineer Doctor

maternityStatus specialization
• Inheritance:
– Every instance of a child entity is also an instance of the parent entity
– Every property of the parent entity (attribute, identifier, relationship or
other generalization) is also a property of a child entity

CSC301 University of Toronto 69 CSC301 University of Toronto 70

Types of Generalizations In My Opinion

Total generalization surname
age taxCode Partial
• every instance of Person
generalization • Models are only as useful as the tools
the parent entity is used to work with them
an instance of one salary

of its children • The act of modeling is more useful than

Woman Man Employee Student the models themselves
• But: the more concurrency there is in a
maternityStatus
system, the more important modeling and
Manager Programmer Analyst
proofs become
language
Programmer
CSC301 University of Toronto 71 CSC301 University of Toronto 72

18