o Standard language for writing software

blueprints (i.e. for modelling).

o UML is standardized graphical notation
for specifying, visualizing, constructing,
& documenting artifacts of software
systems.
o Emerged in mid 1990s from the works of
Grady Booch, Jim Rumbaugh, & Ivar
Jacobson.

2
 o Has rules (syntax) designed primarily for
describing software-based systems.
o Has been used to describe non-software
systems (e.g. business processes).
o UML is purely descriptive, not
prescriptive i.e. describes a system, not
how to create a system.

3
 o Maintained by Object Management
Group (OMG) – www.omg.org
o UML specifications are found at
www.uml.org

4
 o Origins traceable to OO movement of
1980s.
o Methodologies (& notations) for OOSD
increased to more than 50 by 1994.
o 1994 – two of “Three amigos of OOSD”,
Grady Booch & Jim Rambaugh,
combined their notations for OOA/D –
Booch & OMT methodologies.

5
 o 1995 – Third amigo, Ivar Jacobson
joined them at Rational Software Corp,
bringing on-board OOSE methodology
(use case approach).
o 1996 – first release of UML; version 1.0
in 1997; version 2.0 in 2004.
o Current version – 2.5.1 of 2017.

6
 o UML models both static and dynamic
aspects of a system.
o It consists of 13 different diagram types,
grouped as:
 Structural (static) diagrams; &
 Behavioural (dynamic) diagrams.
o Each type/group has specific purpose
and application.

7
 o The 13 diagrams are:
Class diagram; Activity diagram;
Object diagram; Communication diagram;
Component diagram; State machine diagram;
Composite structure Package diagram;
diagram; Timing diagram; &
Deployment diagram; Interaction overview
Use case diagram; diagram.
Sequence diagram;
Sommerville: Research as shown that
8 five shown above are commonly used.
9
 o Show static (time-independent) nature
of a system.
o Major diagrams in this category are:
o Class diagram;
o Object diagram;
o Component diagram; &
o Deployment diagram.
o Last 2 are used to model the physical
implementation of software.

10
 o Depicts the static (time-independent)
structure of a system, showing all
classes (attributes, operations) &
relationships they have with each other.
o Symbol – is a rectangle with three parts
Person Name of class
IDNo
LastName Attributes of class
FirstName
Main element: MiddleName
- box setLastName()
getIDNo() Operations of class
11
12
 o Each attribute has a name, type, &
visibility (private (-) or public(+)).
Person

- IDNo: int
- LastName: string
- FirstName: string
- MiddleName: string
- YearOfBirth: date

+ setLastName()
+getIDNo()
+getAge(CurrentYr)

13
 o In practice, we simplify classes by
drawing rectangular boxes with class
names only; omit attributes and
operations e.g.
Person
Person Employee
- IDNo: int
- LastName: string
- FirstName: string
- MiddleName: Student CarRental
string
- YearOfBirth: date
+ setLastName()
+getIDNo()
Fuel Course
+getAge(CurrentYr)

14
 o In textual description of requirements,
classes correspond to nouns:
The development of a computer system is required by a
community bank. The community bank is a new venture to
introduce banking services to a local community that do not
normally use the facilities of the national banks. A system is
required whereby customers may open accounts and perform
the usual transactions on these accounts (credit the account,
debit the account, and obtain the current balance). The bank is
also required to provide to government the value for its total
assets.

15
 o On abstraction, very few classes stand
alone, there are connections/links –
showing how the things relate.
o They have various relationships, namely:
 Dependencies;
 Generalizations; &
 Associations.
o Graphically, relationships between
classes are denoted by lines with/without
special endpoints.
16
 (a) Dependencies (uses):
o Are “uses” relationships – one thing uses
information/services of another thing, but
not necessarily the reverse.
o For example:
A car uses fuel.
o Graphically, this is rendered as a dashed
directed line

17
 … (a) Dependencies (uses):
o The line is directed at the thing that is
depended on e.g.
A car uses fuel

Car Fuel

- use dependencies to show that “one

thing uses another”.
18
 (b) Generalization:
o Is a relationship between a general thing
(superclass/parent) and a more specific
kind of thing (subclass/child).
o Also called “is-a” relationship, for
example:
A car is a vehicle.
Bay window is a window.

19
 … (b) Generalization:
o A child inherits the properties and
methods/operations of a parent.
o A child may have other attributes and
operations in addition to those inherited
from the parent.
o Operations in a child can override an
implementation of the same operation of
the parent (polymorphism).

20
 … (b) Generalization:
o Graphically, generalization is rendered as
a solid directed line with unfilled
triangular arrowhead.

The arrowhead
points to the parent

21
 Superclass/Parent

Subclass/
Child

22
 … (b) Generalization:
o A class may have 0, 1 or more parents.
o A class with no parent but has one or
more children is called root/base class.
o A class with no children is called a leaf
class.

<diagram below>

23
24
 (c) Associations:
o Is a relationship showing that objects of
one thing (class) are connected to
objects of another class e.g. a person
and a company, a student and a course.
o This relationship makes it possible to
relate objects of one class to objects of
another class

<diagram below>
25
26
 … (c) Associations:
o An association can be unary, binary or n-
ary relationship (relating to one class,
two classes, or more than 2 classes).

0..1 *
Person Employee

0..1 0..1
Married_to Manages

27
 … (c) Associations:
o Relating two classes:
isAssignedTo
Employee Parking slot
0..1 0..1

Registers_for
Student Course
* *

28
 … (c) Associations:
o Graphically, an association is rendered
as a solid line connecting the same or
different classes.
Registers_for
Student Course
* *
works_for
Person Company
1..* *

association
29
 … (c) Associations:
o An association may have:
(i) Name and name direction – describing the
nature of the relationship e.g. works_for,
registers_for, is_assigned, etc.
- Direction , shown by triangle, reduces
ambiguity e.g.
works_for
Person Company
1..* *

Name direction
name
30 association
 … (c) Associations:

(ii) Role – also called end name – showing the

role that a class plays in the relationship e.g.
employee, employer, etc.
works_for
Person Company
employee employer

End name (role)

association
31
 … (c) Associations:

(iii) Multiplicity – showing “how many”objects

may be connected across an instance of an
association. The “how many” is called
multiplicity.
multiplicity

1..* works_for *
Person Company
employee employer
association
End name (role)
32
 … Multiplicity
– usually written as an expression of minimum
and maximum values (integers):
o 1 – exactly one; 0..1 – zero or one;
o 0..* - many; 1..* - one or more

multiplicity

1..* works_for *
Person Company
employee employer
association
End name (role)
33
 (d) Aggregation (a kind of association):
o Plain associations between 2 classes
represent links between peers – classes
at conceptually the same level.
o However, some classes in the
association may not be exactly peers –
one may be part or whole of the other
e.g. a school and its departments, a
building and its rooms, etc.

34
 … (d) Aggregation (part_of, has_a):
o Aggregation is therefore a relationship in
which one class represents a larger thing
(whole) that consists of smaller things
(parts) – also part_of or has_a.
o An object of the whole has objects of the
part (the solid line is modified, next slide)
1 Has_a *
School Department
whole part
aggregation
35
 … (d) Aggregation (part_of, has_a):
o Graphically, aggregation is shown by
adorning a plain association, like the one
shown on the previous slide, with an
unfilled diamond at the whole end e.g.
1
Has_a *
Department Course

aggregation
whole
part

36
 … (d) Aggregation
- Other examples of aggregation include: a
vehicle has an engine, a car has axles,
etc.
1
Has_a *
Company Department
Part _ of

whole aggregation part

1 Has_a *
car axle
Part _ of
37
38
 (e) Composition:
o This is an aggregation in which a part
object belongs to only one whole object
e.g. a room is part of only one building:
Has_a *
Building Room
Part _ of

whole composition part

1 Has_a *
School Department
Part _ of
39
 Read the following scenario and develop a
class diagram showing appropriate
relationships:
In an institution, there are departments with instructors
and courses. Students attend courses, every student
may attend any number of courses and every course
may have any number of students. Instructors teach
courses, for every course there is at least one
instructor and every instructor may teach zero or more
courses. Each course belongs to exactly one
department. The school has zero or more students,
one or more departments, and each department
belongs
40 to exactly one school.
In an institution, there are departments with
instructors and courses. Students attend courses,
every student may attend any number of courses
and every course may have any number of
students. Instructors teach courses, for every
course there is at least one instructor and every
instructor may teach zero or more courses. Each
course belongs to exactly one department. The
school has zero or more students, one or more
departments, and each department belongs to
exactly one school.

41
 Has_a 0..1
School Department
Part _ of 1..*
1 1..*
1..* 1
chairs
member Assigned_to
* 1..* * 0..1
Student Course Instructor
attends teaches

* * 1..*
*

42
 A university has persons, faculty and
students. The university maintains
addresses of these people. Each person
has at most two addresses. The
students and faculty have schedules
(timetable) that indicate which courses
are offered. The schedule has one or
more courses.

43
 A university has persons, faculty and
students. The university maintains
addresses of these people. Each person
has at most two addresses. The
students and faculty have schedules
(timetable) that indicate which courses
are offered. The schedule has one or
more courses.

44
45
 o This is similar to a class diagram but
portrays state of class instances and their
relationships at a point in time.
o Recall car rental class diagram:
Agent

Customer

Rental

Vehicle

46
47
Class diagrams are static snapshots
of instances of the things found in a
class diagram – rendering a set of
objects, their state, and their
relationships.
48
 Note:
o Also represented by a rectangle; &
o Name is shown underlined and written as
objectname: classname

49
 o Objects are connected to each other
using straight lines.
o The links are instances of associations
between the classes.

50
51
A university has persons, faculty and
students. The university maintains
addresses of these people. Each person
has at most two addresses. The
students and faculty have schedules
(timetable) that indicate which courses
are offered. The schedule has one or
more courses.

52
53
54
After gathering data in a certain domain, you
have established the occurrence of three
classes: Course, Student, and Lecturer.
Lecturers teach courses and students attend
courses. Students and lecturers have common
properties as they are both members of the
class Person.

For the above scenario, develop a(n):

(i) Class diagram
(ii) Object diagram
55
 o A component is simply any part of a
system.
o It is a logical, independent, and
executable part of the system.
o It provides other components with
services or uses the services of other
components:

56
 Provided interface
Component
Required interface

57
58
 o Portray the dynamic (time-dependent)
nature of the system.
o Major diagrams in this category are:
o Use case diagram;
o Sequence diagram;
o Activity diagram;
o Communication diagram; &
o State machine diagram.

59
 o A use case diagram (UCD) describes a
system from the users’ point of view.
o By so doing, it shows the relationship
between a system and the outside
world.
o It shows the various actors (users) and
how they interact with the functionality
(use cases) of the system.

60
 o Booch, Rumbaugh & Jacobson (2006):

“a use case is a description of a set of

sequences of actions that a system
performs to yield an observable result of
value to an actor”. [p.228]

o Graphically, a use case is rendered as

an ellipse Place order
61
 o From above description, each use case
represents a slice of the functionality of
a system:
Place order

Track
order

o Similarly, an actor is one of the objects

that the system serves.
62
 o Every use case has a name that
distinguishes it from other use cases
e.g.
Place order
Use case name

Validate
user

o It takes the form of a verb-object phrase

e.g. place order, withdraw cash, show
balance, etc. (verb-noun)
63
 o A use case defines the requirements of
the system – i.e. features of software
that users would want the system to
support e.g.

Print report
Use case name

Show
balance

64
 o It has an actor - a coherent set of roles
that users (human, hardware, other)
play when interacting with the system:

65
 o Actors are rendered as stick figures,
specific or generalized:

66
 o Actors initiate some events that in turn
trigger the activities in the organization

Place order

Track
order

67
 o It also shows the boundary of the
system.

Actors are always outside the

boundary of a system
68
o Relationships
between actors
and the use cases
are shown by lines.

69
 o There are relationships between use
cases:
o Associations (also Communicates);
o Dependencies; and
o Generalization.

<we model them below>

70
 Associations:
o These show the communication of
actors with use cases.

Shown by straight lines

between actors and use
cases
71
 Dependencies:
o Are used to show relationships among
use cases; represented by a dashed line
with an arrowhead.
o There are 2 types of dependencies
among use cases:
o <<include>>
o <<extend>>

72
 o <<include>> dependency shows that
the execution of one use includes the
working of another use case always e.g.

Return <<include>> Update

Book book record

Reserve
book Return book will
member always call Update
book record
73
 o Note: In <<include>> dependency, the
arrow direction is from the main use
case to the one which is being required
by it.
Return <<include>> Update
Book book record

Reserve
book
member

74
 o <<extend>> dependency shows that
one use may or may not use other use
case e.g.

Return <<include>> Update

Book book record
<<extend>>
Reserve Compute
book fine
member

75
 o Note: The direction of the arrow in
<<extend>> dependency is from the
extension use case to the one which is
calling it.
Return <<include>> Update
Book book record
<<extend>>
Reserve Compute
book fine
member

76
 Generalization:
o This implements the concept of
inheritance among use cases and
actors.
o A solid line with hollow arrowhead is
used to show generalization

77
 … Generalization:
o For example

78
 o Generalization may also exist between
actors, e.g.

79
 A library has members, staff members and users.
Members enroll to qualify to use informational
materials such as books and journals which may be
borrowed by (issued to) the members. These
materials are returned after use and if they are
overdue, a fine is computed and paid by the user.
Whenever an item is returned, the user's record of
loan materials is updated. A librarian prepares
orders for information materials and prints various
reports, including inventory and member reports,
periodically.

80
 Sabharwal (2020: 174-175):
oSet the boundary of the system.
oIdentify actors.
oIdentify use cases.
oEstablish associations between actors and
use cases.
o Identify <<include>> and <<extend>>
dependencies among the use cases.
o Identify generalizations among actors and use
cases.
o Refine the diagram by reviewing it more than
81 once.
 o Set the boundary of the system.

82
 o Identify actors:

Staff member
member
or user

Librarian

83
 o Identify use cases:

Enrol member

Staff Issue book member

member
…

Print report
Insert all key
Librarian use cases
Prepare order here

84
 o Establish associations between actors and
use cases:

Enrol member

Staff Issue book member

member
…

Print report
Do the same
Librarian for all key
Prepare order use cases

85
 o Identify <<include>> and <<extend>>
dependencies among the use cases:

Enrol member
… user
Staff Compute fine
Return book
member <<extend>>

<<include>>
Update record

Print report

Librarian
Prepare order

86
 o Identify generalizations among actors and use
cases:

Enrol member
… user
Staff Compute fine
Return book
member <<extend>>

<<include>>
Update record
Print report
Print member
report
Librarian
Prepare Print inventory
order report

87
 o Refine the diagram by reviewing it more than
once :

Enrol member
… user
Staff Compute fine
Return book
member <<extend>>

<<include>>
Update record
Print report
Print member
report
Librarian
Prepare Print inventory
order report

88
89
 o Refinement of use cases yields a use case
scenario – a textual or tabular description of
systems requirements:
o It shows the flow of events, in detail.
o Preconditions – what should obtain before the use
case e.g. Having account & logging in.
o Postconditions – the state after the use case, for
example successful enrolment, book successfully
issued/returned, etc.

90
 o To be given.

91
 o Shows succession of interactions
between actors and objects & between
objects themselves, over time.
o Often used to show the processing
described in use case scenarios.
o In practice, they are derived from use
case analysis.
o NB: most popular means of portraying
the dynamic nature of a system.
92
 o It basically shows how actors “talk” to
objects and how objects talk to each
other.
o They show how operations are carried
out according to time and how objects
are created and manipulated.
o Example: A manager interacting with
objects – customer and address

93
94
 o From the example above, we can note:
o Actors and objects participating in a
given scenario are placed at the top
using symbols already seen;
o Life of an object/actor, shown by
vertical dotted line (lifeline); &
o Messages shown by arrowed lines
(order of messages – top to bottom –
ordered in increasing time).
95
 objects

message Execution
lifeline specification

96
97
 o Three amigos guide:
o Place the objects or roles that participate
in the interaction at the top (across the
horizontal axis);
o The object/role that initiates the interaction
is placed at the left and subordinate ones
to the right;
o Arrange messages that objects send and
receive along the vertical axis in order of
increasing time from top to bottom;

98
 o Where there are options, conditionals and
loops, show them using structured control
operators;

Options or
alternatives

99
10
0
Control structure for Loop:

10
1
 o Another example:
o From the "view patient information"
use case, a medical receptionist may
want to see some patient information.
o Ian Sommerville (2016: 147) presents
the following sequence diagram:

10
2
10
3
 o After interacting with a client, the
following details of a “withdraw cash”
from an ATM event came out:
o Insert bank card into ATM;
o Enter PIN at ATM;
o Select withdrawal transaction from ATM menu;
o Enter amount to withdraw;
o Remove bank card from ATM.
Required: model these activities using a
sequence diagram. Other objects are the
Bank server and account

104
Place actors and objects horizontally, at the top:

10
5
Arrange messages that the roles/objects send, along the
vertical axis, from top to bottom:

10
6
107
 Assume that we have extracted the following
summarised facts from a systems functional
requirements:
o Register personal details of a doctor;
o Register personal details of a patient;
o Schedule appointment;
o Cancel appointment;
o Update patient visit records;
o Print report;
o Compute doctor payment;

108
 o Update patient payment records;
o Retrieve patient information; &
o Add new services.
The key actors in this case are health facility
administrator, patient, and doctor.

From this scenario:

 Draw a use case diagram;
 For each use case, write use case
scenario; &
 Draw a sequence diagram
109
 o Shows the flow of activities within a
process or flow of control in an
operation.
o It is essentially a UML equivalent of a
basic flowchart or DFD.
o It can be used to document workflows in
an entire business process or to model
the logic of a use case e.g.

110
Suppose we wanted to building a house? …
11
1
Example:
Building a house:
• Select site;
• Get architect to design;
• Settle on a plan;
• Ask for bids to price house;
• Construct …

112
 o As seen above, it is a “flowchart” that
emphasizes activities that take place
over time; showing the flow of control
from activity to activity.
o Unlike traditional flowchart, it shows
concurrency and branches of control.
o Graphically, it is rendered as a collection
of nodes linked by edges/arcs
representing transition from one node to
another.
113
114
115
116
 o Actions indicated in activity node
(rounded box) are atomic, they cannot
be decomposed any further.

117
 o Actions cannot be decomposed any
further:
action

activity

118
 o Flow of control passes from one action
or activity node to another; shown by
arrows.

119
 o Branching is allowed – alternate paths
may be taken based on some Boolean
expression.
o This is shown by a diamond shaped
symbol:

Two paths of control

can merge back through
a diamond

120
 o Forking and joining – are used where
there are concurrent processes.
o Synchronization bar specifies the
forking and joining: Fork

Sync bar

join

121
Fork and join in
context

122
Fork and join in
context

123
 o Swimlanes – are used to partition
activity states into groups, showing
objects responsible for the activities:

124
Three swimlanes
in context

125
Each activity
belongs to only
one swimlane

126
 To create activity diagrams, Kendall and
Kendall (2020) guide that:
o Start by asking what happens first, what
happens second, and so on;
o Determine whether activities are done in
a sequence or in parallel;
o Look for places where decisions are
made, and ask what happens for each
of the decision outcomes;

127
 o Examine all the scenarios developed for
the use cases; &
o It is also advisable to examine all other
documentation if they already exist/if
they have been adopted for use e.g.
DFDs.

128
Mara Supermarket, a small chain of grocery stores, is
building a website to allow customers to place online
orders for groceries and other items. The customer places
a Web order, the customer master is updated, and an
order record is created. The order prints at a local store,
and store employees pick the goods from the shelves. The
customer is then sent an email notification that his or her
order is ready. When the customer picks up the order,
frozen goods, chilled products, and other items are
assembled.

Draw an activity diagram showing the customer

using the website to place an order, verification
of the order, order confirmation, order details
sent to the local store, and a customer email
129
 o This diagram also models the dynamic
view of a system.
o It shows the possible states in an object’s
lifetime, events/stimuli that trigger the
change (transition) in states, and the
object’s response(s) to the events e.g.
incidentHandling

130
 o When an event occurs, it has an effect
that leads to execution of behaviour that
changes the state of objects.

131
 o As seen above, a state is rendered as a
rectangle with rounded corners, with a
name: State name

Idle Waiting

state
132
 o A state of an object is a period of time
during which it satisfies some condition,
performs some activity or waits for some
event.
o A state diagram therefore shows the
flow of control from state to state within
a single object: e.g. Incident handling

133
 o Examples of states in account
application object:

134
13
5
 Self transition,
no change of
state

136
 o Graphically, a state diagram is rendered
as a collection of nodes and arcs:

137
 o A number of suggestions are made,
including:
 Determine possible state an object might
be in;
 Describe the states – add more details;
 Show transitions from one state to another;
 Determine events that trigger transitions; &
 Specify constraints (guard conditions) on
transitions.

138
 Suppose we wanted to model the states
of a bank account.

o Determine possible states:

o When the account has funds; &
o When it has no funds.

139
 Describe the states – add more details:
o When the account has funds;
o When it has no funds;
o Start and end.

With Funds With No

Funds

140
 Specify transitions from one state to
another:

With Funds With No

Funds

141
 Determine events that trigger transitions:

Open account
withdraw

With Funds With No

Funds

deposit
Withdraw

142
 Specify constraints [guard conditions] on
transitions:

Open account
Withdraw [bal = = 0]

With Funds With No

Funds

deposit
Withdraw [bal > 0]

143
 o Sommerville, exercises in chap 7.
o Kendall and Kendall, exercises at end of
chap 10 (10th ed).
o Richard Johnson (Handout, chap 13)

144
 “A University offers a number of degree
programmes. Students register for a number of
courses which are taught by lecturers who are
employees of the university. Each semester,
each lecturer sets and administers an
examination to students who register for his or
her course.”
Using the following UML diagrams, model the
above scenario:
 class diagram.
 use case diagram.
145  activity diagram.
 Consider an online banking system. A customer
uses the internet to access his/her checking
account and make payments to various payees
(such as phone company or credit card
company) with which the bank customer does
business. Although the bank customer has a
checking account with the bank (with a certain
checking account number), this bank customer
also has payee accounts with the phone
company or the credit card company, each with
14 its own distinct account number.
6
 Once the bank customer signs up for online banking with
a particular bank, the bank maintains or administers the
customer’s checking account. The bank also stores
account information for all payees to which the bank
sends payments at the online request of a bank
customer (the bank customer provides this payee
information to the bank). This information includes the
account number that the payee uses for the customer
and the payee’s mailing address. There is no need to be
concerned about checking account deposits – i.e.
assume account deposits are made in person at the
bank.
14 REQUIRED: identify classes and model this situation.
7
  Johnson RA (2007) An Introduction to
Java Programming and OO Application
Development Cap 13
 Kendall KE & Kendall JE (2020)
Systems Analysis and Design. 10th ed
Chap 2 & 10
 Booch, Rumbaugh & Jacobson (2006)

14 The UML User Guide. All chapters.

8
14
9