Activity # 3: Diagrams in the UML

Structural Diagrams
Behavioral Diagrams

By Samuel Ashagrre
Learning Outcomes

• Upon completion of this activity you will be able to:

– Understand various types of UML diagrams and Explain
their usage

Target Group
SE 3rd year

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 2
Engineering ,Samuel
Overview of UML Diagrams
• UML has been designed for a broad range of applications.
• Hence, it provides constructs for a broad range of systems
and activities (e.g., real-time systems, distributed systems,
analysis, system design, deployment).
• System development focuses on three different models of the
system:
– The functional model, represented in UML with use case
diagrams, describes the functionality of the system from
the user’s point of view.
– The object model, represented in UML with class
diagrams, describes the structure of a system in terms of
objects, attributes, associations, and operations.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 3
Engineering ,Samuel
 – The dynamic model, represented in UML with sequence
diagrams, statechart diagrams, and activity diagrams,
describes the intern al behavior of the system.
• Sequence diagrams describe behavior as a sequence of
messages exchanged among a set of objects
• State chart diagrams describe behavior in terms of
states of an individual object and the possible transitions
between states.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 4
Engineering ,Samuel
• What is Systems, Models and Views
– A model is an abstraction describing a subset of a system
– A view depicts selected aspects of a model
– A notation is a set of graphical or textual rules for
depicting views
– Views and models of a single system may overlap each
other
• Examples:
– System: Aircraft
– Models: Flight simulator, scale model
– Views: All blueprints, electrical wiring, fuel system

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 5
Engineering ,Samuel
• What is Application and Solution Domain

– Application Domain (Requirements Analysis)

• The environment in which the system is operating
– Solution Domain (System Design, Object Design)
• The available technologies to build the system

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 6
Engineering ,Samuel
Diagrams in the UML
• A diagram is the graphical representation of a set of elements
rendered as a connected graph of vertices (things) and arcs
(relationships)
– The diagrams are graphical representation of the models which uses
various symbols and text.
• Each diagram has its own set of symbols. Each diagram
captures a different dimension, view, perspective of the
system.
• UML have several different types of diagrams that can be used
to describe a model from different point of views.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 7
Engineering ,Samuel
 evolution of UML

UML as a Standard
 The evolution of UML:
 UML 0.9 (Jacobson/1992 & Rumbaugh /1991)
 UML 1.0 proposal to the OMG in January 1997.
 UML 1.1 was submitted later that year.
 OMG maintains UML as a standard.
 First adoption was UML 1.3
 Minor revision with UML 1.4 and 1.5
 A major revision was made in 2003 with UML 2.0.

4/10/2025 8
Model-Driven Architecture with UML
 A UML model can be either:
 Platform-independent model (PIM) or
 Platform –specific model (PSM).
 PIM is useful b/c the same PIM can be mapped to different
middleware platform such as:
 CORBA (Common Object Request Broker Architecture)
 .NET,
 J2EE,
 Web Services etc…
4/10/2025 9
Evolution of SW modeling and Design Methods
 In 1960s, programs were little (no systematic analysis and
design)
 Structured programming in the early seventies (top-down
design).
 In the mid to late 1970s, data flow-oriented and data
structured design.
 Parnas (1972) information hiding.

4/10/2025 10
Evolution of SW modeling and Design Methods

 In 1960s, programs were little (no systematic analysis and

design)
 Late 1970s, the design of concurrent and real-time systems.
 Late 1980s, Jackson System Development (JSP).
 JSP was a precursor of object interaction modeling (OOD)

4/10/2025 11
 •In general, we have two major types of the UML diagrams: structural
diagrams and behavioral diagrams. The behavioral diagrams also include the
interaction diagrams.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 12
Engineering ,Samuel
 a) Structural Diagrams emphasize what things must be in the
system being modeled:
b) Behavior Diagrams emphasize what must happen in the
system being modeled:
• Activity diagram
• State Machine diagram
• Use case diagram
• Interaction Diagrams

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 13
Engineering ,Samuel
UML : Use case diagrams
• Use cases are used during requirements elicitation and analysis to
represent the functionality of the system.
• Use cases focus on the behavior of the system from an external point
of view.
• A use case describes a function provided by the system that yields a
visible result for an actor.
• An actor describes any entity that interacts with the system (e.g., a
user, another system, the system’s physical environment).
• The identification of actors and use cases results in the definition of
the boundary of the system, that is, in differentiating the tasks
accomplished by the system and the tasks accomplished by its
environment.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 14
Engineering ,Samuel
• The following figure, depicts a use case diagram for a
simple watch.
– The WatchUser actor may either consult the time on their watch
(with the ReadTime use case) or set the time (with the SetTimeuse
case).

• However, only the WatchRepairPerson actor may change

the battery of the watch (with the ChangeBattery use case)

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 15
Engineering ,Samuel
 Package Use case
Watch

Actor
ReadTime

SetTime
WatchUser WatchRepairPerson

ChangeBattery

Use case diagrams represent the functionality of the system

from user’s point of view
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 16
Engineering ,Samuel
Cont’d • Actors represent roles, that is, a
type of user of the system
• Use cases represent a sequence of
interaction for a type of
functionality
• The use case model is the set of all
Passenger use cases. It is a complete
description of the functionality of
the system and its environment

PurchaseTicket

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 17
Engineering ,Samuel
Actors
• An actor models an external entity which
communicates with the system:
– User
– External system
– Physical environment

Passenger • An actor has a unique name and an optional

description.
• Examples:
– Passenger: A person in the train
– GPS satellite: Provides the system with GPS
coordinates

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 18
Engineering ,Samuel
 Use Case
• A use case represents a class of
functionality provided by the system as an
event flow.
• A use case consists of:
PurchaseTicket – Unique name
– Participating actors
– Entry conditions
– Flow of events
– Exit conditions
– Special requirements

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 19
Engineering ,Samuel
• To describe a use case, we use a template composed of six fields:
– The name of the use case is unique across the system so that developers
(and project participants) can unambiguously refer to the use case.
– Participating actors are actors interacting with the use case.
– Entry conditions describe the conditions that need to be satisfied before
the use case is initiated.
– The flow of events describes the sequence of actions of the use case,
which are be numbered for reference. The common case (i.e., cases that
occur frequently) and the exceptional cases (i.e., cases that seldom occur,
such as errors and unusual conditions) are described separately in
different use cases for clarity.
– Exit conditions describe the conditions that are satisfied after the
completion of the use case.
– Special requirements are requirements that are not related to the
functionality of the system. These include constraints on the performance
of the system, its implementation, the hardware platforms it runs on, and
so on
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 20
Engineering ,Samuel
Textual Use Case Description Example
PurchaseTicket
Passenger

1. Use case Name: Purchase 5. Flow of events:

ticket 1. Passenger selects the
number of zones to be traveled
2. Participating actor: Passenger 2. Ticket Distributor displays the
amount due
3. Passenger inserts money, at
3. Entry condition: least the amount due
• Passenger stands in front of 4. Ticket Distributor returns change
ticket distributor 5. Ticket Distributor issues ticket
• Passenger has sufficient 6. Special requirements: None.
money to purchase ticket

4. Exit condition:
• Passenger has ticket
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 21
Engineering ,Samuel
The <<includes>> Relationship

• Include relationships are used when two or more use cases

share some common portion in a flow of events.
• This common portion is then grouped and extracted to
form an inclusion use case for sharing among two or more
use cases.
• Most use cases in the ATM system example, such as
Withdraw Money, Deposit Money or Check Balance, share
the inclusion use case Login Account.
• Include relationship: Allows reuse of functionality by
multiple use cases
• Two use cases are related by an include relationship if one
of them includes the second one in its flow of events.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 22
Engineering ,Samuel
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 23
Engineering ,Samuel
A <include> relationship shows behavior common to one or more
use cases
An <extends>relationship shows optional/exceptional behavior

<<extends>> <<includes>>
Register for courses

Register for <<includes>>

Logon validation
Distance Learning courses
<<includes>>
Maintain curriculum
Create course
<<includes>>
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 24
Engineering ,Samuel Maintain Schedule
 Cont’d
•
<<includes>> relationship
represents behavior that is
Passenger factored out of the use case.
• <<includes>> behavior is
factored out for reuse, not
PurchaseMultiCard
because it is an exception.
PurchaseSingleTicket • The direction of a
<<includes>> <<includes>> relationship is
<<includes>> to the using use case (unlike
<<extends>> relationships).

CollectMoney
<<extends>> <<extends>>

NoChange Cancel
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 25
Engineering ,Samuel
The <<extends>> Relationship
• Extend relationships are used when two use cases are similar,
but one does a bit more than the other.
• For example, you may have a use case that captures the typical
case (the base use case) and use extensions to describe
variations.
• A base use case may therefore conditionally invoke an
alternative use case.
• Extending use case adds behavior
• To represent seldom invoked use cases or exceptional
functionality

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 26
Engineering ,Samuel
 The <<extends>> Relationship
• <<extends>> relationships represent
exceptional or seldom invoked cases.
• The exceptional event flows are factored
Passenger
out of the main event flow for clarity.
• Use cases representing exceptional
flows can extend more than one use
PurchaseTicket case.
• The direction of a <<extends>>
<<extends>> relationship is to the extended use case

<<extends>>
<<extends>>

OutOfOrder <<extends>> TimeOut

Cancel
BIT-Faculty of Computing--- NoChange
Object Oriented Software Diagrams in UML 27
Engineering ,Samuel
The generalization relationship

• Shows inheritance and specialization

• One use case is simply a special kind of another

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 28
Engineering ,Samuel
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 29
Engineering ,Samuel
• Pay Bill is a parent use case and Bill Insurance is the
child use case. (generalization)

• Both Make Appointment and Request Medication

include Check Patient Record as a subtask.(include)

• The extension point is written inside the base case

• Pay bill; the extending class Defer payment adds the
behavior of this extension point. (extend)

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 30
Engineering ,Samuel
 Use Case Example 2
Consider the following scenarios to depict Use case diagram

• The Rift Valley University wants to computerize its registration

system. The Registrar sets up the curriculum for a semester.
Students select 3 core courses and 2 electives. Once a student
registers for a semester, the billing system is notified so the
student may be billed for the semester. Students may use the
system to add/drop courses for a period of time after
registration. Professors use the system to set their preferred
course offerings and receive their course offering rosters after
students register. Users of the registration system are assigned
passwords which are used at logon validation

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 31
Engineering ,Samuel
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 32
Engineering ,Samuel
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 33
Engineering ,Samuel
 UML: Class Diagram
• Class diagrams describe the structure of the system by showing its
classes and the relationships among them
• The class diagram is a static model that shows the classes and the
relationships among classes in the system.
• Class diagrams illustrates classes, interfaces, and their associations.
They are used for static object modeling.
• Classes are abstractions that specify the attributes and behavior of a
set of objects.
• Objects are entities that encapsulate state and behavior. Each object
has an identity: It can be referred individually and is distinguishable
from other objects.
• Objects are instances of classes that are created, modified, and
destroyed during the execution of the system.
• Class diagrams describe the system in terms of objects, classes,
attributes, operations, and their associations.
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 34
Engineering ,Samuel
Use Case Diagram Relationships Explained with Examples
 There can be 5 relationship types in a use case diagram.
 Association between actor and use case
 Generalization of an actor
 Extend between two use cases
 Include between two use cases
 Generalization of a use case

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML
Engineering
 Use Case Diagram Relationships Explained with Examples

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML
Engineering
 Cont’d

• In UML, classes and objects are depicted by boxes including three

compartments. The top compartment displays the name of the
class or object. The center compartment displays its attributes,
and the bottom compartment displays its operations.
• The attribute and operation compartment can be omitted for
clarity. Object names are underlined to indicate that they are
instances.
• By convention, class names start with an uppercase letter.
Objects in object diagrams may be given names (followed by
their class) for ease of reference. In that case, their name starts
with a lowercase letter.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 37
Engineering ,Samuel
E LEMENTS OF A CLASS
DIAGRAM
 C L ASS D IA GR AMS
E LEMENTS OF A CLASS DIAGRAM - C LASSES

C L ASS D IA G R AM

E L E ME N T S
OF A
CL ASS D IAGR AM

M AKING CL ASS
D IAGR AMS
E XAMPLE # 1

R E L AT ION SHIPS
B E T W E E N CL ASSE S
V ISIBILITY
A G G R E G AT I O N A N D
C OMPOSITION
A B STR AC T CLASSES
E LEMENTS OF A CLASS DIAGRAM - C L ASS D IA GR AMS

STRUCTURE OF A CLASS

C L ASS D IA G R AM

E L E ME N T S
OF A
CL ASS D IAGR AM

M AKING CL ASS
D IAGR AMS
E XAMPLE # 1

R E L AT ION SHIPS
B E T W E E N CL ASSE S
V ISIBILITY
A G G R E G AT I O N A N D
C OMPOSITION
A B STR AC T CLASSES
E LEMENTS OF A CLASS DIAGRAM - C L ASS D IA GR AMS

STRUCTURE OF A CLASS

C L ASS D IA G R AM

E L E ME N T S
OF A
CL ASS D IAGR AM

M AKING CL ASS
D IAGR AMS
E XAMPLE # 1

R E L AT ION SHIPS
B E T W E E N CL ASSE S
V ISIBILITY
A G G R E G AT I O N A N D
C OMPOSITION
A B STR AC T CLASSES
E LEMENTS OF A CLASS DIAGRAM - C L ASS D IA GR AMS

STRUCTURE OF A CLASS

C L ASS D IA G R AM

E L E ME N T S
OF A
CL ASS D IAGR AM

M AKING CL ASS
D IAGR AMS
E XAMPLE # 1

R E L AT ION SHIPS
B E T W E E N CL ASSE S
V ISIBILITY
A G G R E G AT I O N A N D
C OMPOSITION
A B STR AC T CLASSES
E LEMENTS OF A CLASS DIAGRAM - C L ASS D IA GR AMS

STRUCTURE OF A CLASS

C L ASS D IA G R AM

E L E ME N T S
OF A
CL ASS D IAGR AM

M AKING CL ASS
D IAGR AMS
E XAMPLE # 1

R E L AT ION SHIPS
B E T W E E N CL ASSE S
V ISIBILITY
A G G R E G AT I O N A N D
C OMPOSITION
A B STR AC T CLASSES
E LEMENTS OF A CLASS DIAGRAM - ROLES C L ASS D IA GR AMS

A N D AT T R I B U T E S

C L ASS D IA G R AM

E L E ME N T S
OF A
CL ASS D IAGR AM

M AKING CL ASS
D IAGR AMS
E XAMPLE # 1

R E L AT ION SHIPS
B E T W E E N CL ASSE S
V ISIBILITY
A G G R E G AT I O N A N D
C OMPOSITION
A B STR AC T CLASSES
E LEMENTS OF A CLASS DIAGRAM - C L ASS D IA GR AMS

O P E R AT I O N S
C L ASS D IA G R AM

E L E ME N T S
OF A
CL ASS D IAGR AM

M AKING CL ASS
D IAGR AMS
E XAMPLE # 1

R E L AT ION SHIPS
B E T W E E N CL ASSE S
V ISIBILITY
A G G R E G AT I O N A N D
C OMPOSITION
A B STR AC T CLASSES
E LEMENTS OF A CLASS DIAGRAM - C L ASS D IA GR AMS

O P E R AT I O N S & A T T R I B U T E S
C L ASS D IA G R AM

E L E ME N T S
OF A
CL ASS D IAGR AM

M AKING CL ASS
D IAGR AMS
E XAMPLE # 1

R E L AT ION SHIPS
B E T W E E N CL ASSE S
V ISIBILITY
A G G R E G AT I O N A N D
C OMPOSITION
A B STR AC T CLASSES
E LEMENTS OF A CLASS DIAGRAM - C L ASS D IA GR AMS

P R I VAT E / P U B L I C

C L ASS D IA G R AM

E L E ME N T S
OF A
CL ASS D IAGR AM

M AKING CL ASS
D IAGR AMS
E XAMPLE # 1

R E L AT ION SHIPS
B E T W E E N CL ASSE S
V ISIBILITY
A G G R E G AT I O N A N D
C OMPOSITION
A B STR AC T CLASSES
E LEMENTS OF A CLASS DIAGRAM - C L ASS D IA GR AMS

R E L AT I O N S H I P S
C L ASS D IA G R AM

E L E ME N T S
OF A
CL ASS D IAGR AM

M AKING CL ASS
D IAGR AMS
E XAMPLE # 1

R E L AT ION SHIPS
B E T W E E N CL ASSE S
V ISIBILITY
A G G R E G AT I O N A N D
C OMPOSITION
A B STR AC T CLASSES
E LEMENTS OF A CLASS DIAGRAM - C L ASS D IA GR AMS

A S S O C I AT I O N S
C L ASS D IA G R AM

E L E ME N T S
OF A
CL ASS D IAGR AM

M AKING CL ASS
D IAGR AMS
E XAMPLE # 1

R E L AT ION SHIPS
B E T W E E N CL ASSE S
V ISIBILITY
A G G R E G AT I O N A N D
C OMPOSITION
A B STR AC T CLASSES
E LEMENTS OF A CLASS DIAGRAM - A R R OW S C L ASS D IA GR AMS

ON A S S O C I AT I O N S
C L ASS D IA G R AM

E L E ME N T S
OF A
CL ASS D IAGR AM

M AKING CL ASS
D IAGR AMS
E XAMPLE # 1

R E L AT ION SHIPS
B E T W E E N CL ASSE S
V ISIBILITY
A G G R E G AT I O N A N D
C OMPOSITION
A B STR AC T CLASSES
E LEMENTS OF A CLASS DIAGRAM - C L ASS D IA GR AMS

M U LT I P L I C I T I E S
C L ASS D IA G R AM

E L E ME N T S
OF A
CL ASS D IAGR AM

M AKING CL ASS
D IAGR AMS
E XAMPLE # 1

R E L AT ION SHIPS
B E T W E E N CL ASSE S
V ISIBILITY
A G G R E G AT I O N A N D
C OMPOSITION
A B STR AC T CLASSES
E LEMENTS OF A CLASS DIAGRAM - C L ASS D IA GR AMS

M U LT I P L I C I T I E S
C L ASS D IA G R AM

E L E ME N T S
OF A
CL ASS D IAGR AM

M AKING CL ASS
D IAGR AMS
E XAMPLE # 1

R E L AT ION SHIPS
B E T W E E N CL ASSE S
V ISIBILITY
A G G R E G AT I O N A N D
C OMPOSITION
A B STR AC T CLASSES
E LEMENTS OF A CLASS DIAGRAM - C L ASS D IA GR AMS

M U LT I P L I C I T I E S
C L ASS D IA G R AM

E L E ME N T S
OF A
CL ASS D IAGR AM

M AKING CL ASS
D IAGR AMS
E XAMPLE # 1

R E L AT ION SHIPS
B E T W E E N CL ASSE S
V ISIBILITY
A G G R E G AT I O N A N D
C OMPOSITION
A B STR AC T CLASSES
E LEMENTS OF A CLASS DIAGRAM - C L ASS D IA GR AMS

G E N E R A L I S AT I O N
C L ASS D IA G R AM

E L E ME N T S
OF A
CL ASS D IAGR AM

M AKING CL ASS
D IAGR AMS
E XAMPLE # 1

R E L AT ION SHIPS
B E T W E E N CL ASSE S
V ISIBILITY
A G G R E G AT I O N A N D
C OMPOSITION
A B STR AC T CLASSES
E LEMENTS OF A CLASS DIAGRAM - C L ASS D IA GR AMS

C ONSTRAINTS
C L ASS D IA G R AM

E L E ME N T S
OF A
CL ASS D IAGR AM

M AKING CL ASS
D IAGR AMS
E XAMPLE # 1

R E L AT ION SHIPS
B E T W E E N CL ASSE S
V ISIBILITY
A G G R E G AT I O N A N D
C OMPOSITION
A B STR AC T CLASSES
 How to make a class diagram
1.Identify all the classes participating in the software
solution (from the sequence diagrams).
2.Draw them in a class diagram.
3.Identify the attributes.
4.Identify the methods (from the sequence diagram).
5.Add associations, generalisations, aggregations and
dependencies.
6.Add other stuff (roles, constraints, . . . )

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 56
Engineering ,Samuel
C LASS DIAGRAMS AND I NTERACTION
DIAGRAMS

C L ASS D IA G R AM

► In practice class diagrams and interaction diagrams

E
L E ME N T S OF A
CL ASS D IAGR AM

are usually created in parallel.

► Many classes, methods, etc. may be sketched out in
a class diagram prior to drawing a sequence
diagram.
► A “light” version of a class diagram containing
only attributes but no messages is also known as a
conceptual model.
► Sometimes a conceptual model is used instead of
an analysis model in the system engineering
process.
1. I D E N T I F Y CLASSES

C L ASS D IA G R AM

E L E ME N T S
OF A

► We investigate the “return item”

CL ASS D IAGR AM

Use Case of the Recycling

M A K I N G CL ASS
D IAGR AMS

machine.
) From the sequence diagram we
find the following classes:
) Customer Panel
) Deposit item receiver
) Receipt basis
) Deposit item
) Receipt printer
) Can, Bottle, Crate
2. D R AW T H E M I N A C L A S S D IA G R A M
3. I D E N T I F Y AT T R I B U T E S

► Classes which contain data are in the Deposit item C L ASS D IA G R AM

hierarchy. E L E ME N T S OF A
CL ASS D IAGR AM
) For checking & classifying an item we need the
weight and size of a Can, Bottle, and Crate.
) For collecting the data at the Receipt basis each
Deposit Item gets a number and a value.
4. I D E N T I F Y METHODS

C L ASS D IA G R AM

► The return item use case suggests the following two E L E ME N T S OF A

methods for the Customer Panel:

CL ASS D IAGR AM

) itemReceived(slot : Integer)
) printReceipt()
► Following the sequence of events in the sequence
diagram we obtain then:
) Deposit item receiver: classifyItem(),
createReceiptBasis(), printReceipt()
) Receipt basis: addItem(), computeSum(),
) Receipt printer: print().
► We don’t show accessor and modifier methods in order
to keep the diagram simple.
5. A D D A S S O C I AT I O N S

C L ASS D IA G R AM

► Associations show navigability between classes E L E ME N T S OF A

CL ASS D IAGR AM
 C L ASS D IA G R AM

E L E ME N T S
OF A
CL ASS D IAGR AM

R E L AT I O N S H I P S BETWEEN
CLASSES
R E L AT I O N S H I P S BETWEEN CLASSES

C L ASS D IA G R AM

E L E ME N T S
OF A
CL ASS D IAGR AM

► There are four possible relationships between classes.

) Association
) Dependency
) Generalisation
) Aggregation
 Association Class

 A class that models an association between two or more

classes.
 The attributes of the association class are the attributes of
the association

Example of association class

4/10/2025 65
 Composition and Aggregation

 Identify a class that is made up of other class (whole/part).

 A composition is a stronger relationship than an aggregation
 An aggregation is a stronger relationship than an
association

Example of composition hierarchy (physical class)

4/10/2025 66
 Composition and Aggregation

 In aggregation parts can be added and removed from the

aggregate whole. (conceptual classes)

Example of aggregation hierarchy

4/10/2025 67
 Generalization and Specialization

 A discriminator is an attribute that indicates which

property of the object is being abstracted by the
generalization relationship.

Generalization / Specialization hierarchy

4/10/2025 68
 Example 1

UML class diagram: classes that participate in the ReportEmergency use case.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 69
Engineering ,Samuel
• Each end of an association can be labeled by a string called
role.
• the roles of the association between the EmergencyReport
and FieldOfficer classes are author and reportsGenerated .
• Labeling the end of associations with roles allows us to
distinguish multiple associations originating from a class.
• Moreover, roles clarify the purpose of the association.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 70
Engineering ,Samuel
 Example 2

UML class Diagram for Ordering System

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 71
Engineering ,Samuel
 Example 3

Example of association on class diagram (bank application)

4/10/2025 72
• Class diagrams represent the structure of the system.
• Used
– during requirements analysis to model problem
domain concepts
– during system design to model subsystems and
interfaces
– during object design to model classes.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 73
Engineering ,Samuel
 Cont’d
• Class diagrams are great for:
– discovering related data and attributes
– getting a quick picture of the important entities in a system
– seeing whether you have too few/many classes
– seeing whether the relationships between objects are too
complex, too many in number, simple enough, etc.
– spotting dependencies between one class/object and another
• Not so great for:
– discovering algorithmic (not data-driven) behavior
– finding the flow of steps for objects to solve a given problem
– understanding the app's overall control flow (event-driven? Web
based? sequential? etc.)
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 74
Engineering ,Samuel
 Object Diagrams
• object diagrams, sometimes referred to as instance
diagrams, are useful for exploring "real world“ examples
of objects and the relationships between them.
• Although UML class diagrams are very good at
describing this very information some people find them
too abstract - a UML object diagram can be a good
option for explaining complex relationships between
classes.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 75
Engineering ,Samuel
 UML: Object Diagram
• Objects are also represented in rectangles, their names
underlined & written with first letter in small case.
• Names of objects can be written in 4 ways:
– write only the class name preceded by a colon and underlined
: Student

– write the name of specific object with it’s class

oneStudent : Student

– write only the object name oneStudent:

– multiple objects :
: Student
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 76
Engineering ,Samuel
 How to Draw an Object Diagram?
• We have already discussed that an object diagram
is an instance of a class diagram. It implies that an
object diagram consists of instances of things used
in a class diagram.
• To capture a particular system, numbers of class
diagrams are limited. However, if we consider
object diagrams then we can have unlimited
number of instances, which are unique in nature.
Only those instances are considered, which have an
impact on the system.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 77
Engineering ,Samuel
 How to Draw an Object Diagram?cont..
• From the above discussion, it is clear that a single
object diagram cannot capture all the necessary
instances or rather cannot specify all the objects of
a system. Hence, the solution is −
1. First, analyze the system and decide which
instances have important data and association.
2. Second, consider only those instances, which will
cover the functionality.
3. Third, make some optimization as the number of
instances are unlimited.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 78
Engineering ,Samuel
 An example of a UML object diagram: objects that participate in
EmergencyReport Scenario

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 79
Engineering ,Samuel
 Cont’d
• Bob and Alice are field officers, represented in the system as
FieldOfficer objects called bob:FieldOfficer and
alice:FieldOfficer .
• FieldOfficer is a class describing all FieldOfficer objects,
whereas Bob and Alice are represented by two individual
FieldOfficer objects.
• The line between the alice:FieldOfficer object and the
report_1291:EmergencyReport object is a link. This link
represents state that is kept in the system to denote that
alice:FieldOfficer generated report_1291:EmergencyReport .

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 80
Engineering ,Samuel
Cont’d

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 81
Engineering ,Samuel
Cont’d

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 82
Engineering ,Samuel
Cont’d

What is the Difference Between Class Diagram and Object

Diagram?
• A class diagram is a type of static structural diagram that
describes the structure of the system by showing the
classes, their attributes, methods and the relationship
among the classes. An object diagram is also a type of
static structural diagram that shows a complete or partial
view of the structure of a modeled system at a specific
time.
• Furthermore, class diagrams define classes and show
how they relate to each other. Object diagrams show the
objects and their relationships. Classes are the blueprints
and objects are the instances of classes.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 83
Engineering ,Samuel
UML: State Machine Diagram
• Describes the states an object or interaction may be in, as well
as the transitions between states.
• State machine diagrams describe the behavior of an individual
object as a number of states and transitions between these
states.
– State Diagrams show the sequences of states an object goes
through during its life cycle in response to stimuli, together with
its responses and actions; an abstraction of all possible behaviors.
• A state represents a particular set of values for an object.
• Given a state, a transition represents a future state the object
can move to and the conditions associated with the change of
state.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 84
Engineering ,Samuel
Cont’d
• Formerly referred to as:
 a state diagram,
 state chart diagram,
 or a state-transition diagram.
• The state machine diagram focuses on the transitions between
states as a result of external events for an individual object
• Actions that result from a state change
• They are very useful to describe the behavior of objects that act
different according to the state they are at the moment.
• A Transition is the movement from one state to another state

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 85
Engineering ,Samuel
 State Diagrams
(Traffic light example)

Traffic Light Start

State
Transition Red

Yellow

Green

Event
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 86
Engineering ,Samuel
Basic components
Final state –
• Initial state
• Transition – We use a solid arrow to represent the transition or
change of control from one state to another.

• State – We use a rounded rectangle to represent a state. A state

represents the conditions or circumstances of an object of a
class at an instant of time.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 87
Engineering ,Samuel
Basic components

• Fork –We use the fork notation to represent a state splitting

into two or more concurrent states.

• Join –We use the join notation when two or more states
concurrently converge into one on the occurrence of an event
or events.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 88
Engineering ,Samuel
Basic components

• Self transition – We use a solid arrow pointing back to the state

itself to represent a self transition. There might be scenarios
when the state of the object does not change upon the
occurrence of an event.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 89
Engineering ,Samuel
Example

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 90
Engineering ,Samuel
Cont’d

• Represent behavior of single objects with interesting

dynamic behavior in terms of states and transitions
• The behavior of the single object Watch, for example,
has several different interesting states, BlinkHours,
BlinkMinutes, BlinkSeconds, Because in each state
pressing a button or two yields a different result.
• A UML state machine diagram for SetTime use case
of the SimpleWatch.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 91
Engineering ,Samuel
 Event Initial state

button1&2Pressed button2Pressed
Blink Increment
Hours Hours

Transition button1Pressed

button1&2Pressed button2Pressed
Blink Increment
Minutes Minutes
State

button1Pressed

button2Pressed
Stop Blink Increment
Blinking Seconds Seconds

Final state

Represent
BIT-Faculty behavior
of Computing--- of a single object with interesting dynamic behavior.
Object Oriented Software Diagrams in UML 92
Engineering ,Samuel
UML: Activity Diagram
• Activity Diagram shows the flow from activity
to activity (not from state to state).
• UML activity diagram supplements the use case by
providing a graphical representation of the flow of
interaction within a specific scenario.

• Activity diagrams model the workflow of a business

process and the sequence of activities in a process.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 93
Engineering ,Samuel
• Activity diagrams typically are used to illustrate the following:
--The flow of a complicated use case.
--A workflow across use cases.
--The logic of an algorithm.
• Activity diagrams have activity nodes and activity edges
• activity nodes, which are placeholders for one or more
steps within an activity.
• activity edges, which are connections between activity
nodes.
• Activity nodes has different control nodes
• Control nodes coordinate flows among other activity
nodes
• Different Control nodes are described below;
• An initial node is where the flow of control starts when
an activity is invoked.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 94
Engineering ,Samuel
 • A final node is a control node at which one or
more flows within the given activity stop.
» There are two types of final nodes:
• flow final nodes
• activity final nodes.
» A flow final node terminates a particular flow.

» An activity final node terminates all flows within the activity and
thus terminates the activity itself.

• A decision node offers a choice among two or more

outgoing activity edges, each of which has a guard,
which is a Boolean expression that must resolve to True
before the associated path can be taken.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 95
Engineering ,Samuel
 A decision node appears as a diamond, as shown in diagram
below

• A merge node brings together multiple alternate control

flows.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 96
Engineering ,Samuel
 – A fork node
• splits a flow into multiple concurrent flows.
• Fork nodes are used to support concurrent activities. When
we use a fork node when both the activities get executed
concurrently i.e. no decision is made before splitting the
activity into two parts.

BIT-Faculty of Computing---
Object Oriented Software 97
Diagrams in UML
Engineering ,Samuel
• A join node
• A join node synchronizes multiple control flows.
•join nodes are used to support concurrent activities
converging into one. For join notations we have two or
more incoming edges and one outgoing edge.

BIT-Faculty of Computing---
Object Oriented Software 98
Diagrams in UML
Engineering ,Samuel
Guards
• A Guard refers to a statement written next to a
decision node on an arrow sometimes within
square brackets.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 99
Engineering ,Samuel
Time Event
• time event notation We can have a scenario
where an event takes some time to complete.
We use an hourglass to represent a time event.
• For example – Let us assume that the processing
of an image takes a lot of time. Then it can be
represented as shown below.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 100
Engineering ,Samuel
 [lowPriority]
Open Allocate
Incident Resources

[fire & highPriority]

[not fire & highPriority]

Notify
Fire Chief

Notify
Police Chief

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 101
Engineering ,Samuel
UML – Interaction Diagrams
A use case diagram presents an outside view of the
system.

Then, how about the inside view of the system?

• Interaction diagrams describe how use cases are
realized in terms of interacting objects.

• types of interaction diagrams

– Sequence diagrams
– Collaboration (Communication) diagrams

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 102
Engineering ,Samuel
 UML: Sequence Diagram
• Sequence diagrams are used to formalize the behavior
of the system and to visualize the communication
among objects.
• They are useful for identifying additional objects that
participate in the use cases.
• We call objects involved in a use case participating
objects.
• A sequence diagram represents the interactions that
take place among these objects.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 103
Engineering ,Samuel
 Sequence Diagram Notations
• Actors – An actor in a UML diagram represents a type of role
where it interacts with the system and its objects.

• Lifelines – A lifeline is a named element which depicts an

individual participant in a sequence diagram. So basically each
instance in a sequence diagram is represented by a lifeline.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 104
Engineering ,Samuel
 Sequence Diagram Notations..cont
• Messages – Communication between objects is
depicted using messages. We represent messages using
arrows. Messages can be broadly classified into the
following categories :
• Synchronous messages – A synchronous message waits
for a reply before the interaction can move forward. A
large number of calls in object oriented programming
are synchronous. We use a solid arrow head to
represent a synchronous message.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 105
Engineering ,Samuel
 Sequence Diagram Notations..cont

• Pros: Easier to reason about (sequential flow)Synchronous code is

usually simpler to implement and debug
• Cons: Can cause performance bottlenecks due to waiting for a
response. Slower if there are network requests or I/O operations

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 106
Engineering ,Samuel
 Sequence Diagram Notations..cont
• Asynchronous Messages – An asynchronous message
does not wait for a reply from the receiver. The
interaction moves forward irrespective of the receiver
processing the previous message or not. We use a lined
arrow head to represent an asynchronous message.
• Pros:Better performance and responsiveness, especially in I/O-
bound operations or concurrent tasks (e.g., file reading, web API
calls)Allows for parallelism and multitasking
• Cons:Harder to reason about due to non-sequential
behaviorMore complex to manage error handling and state
synchronization between operations

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 107
Engineering ,Samuel
 Sequence Diagram Notations..cont

• Real-World Example in Code (Synchronous vs Asynchronous)

• 1. Synchronous Example (e.g., Python):

def synchronous_method():
result = long_computation() # Blocks here until completed return result
response = synchronous_method() # The program waits for result before continuing

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 108
Engineering ,Samuel
 Sequence Diagram Notations..cont

• Real-World Example in Code (Synchronous vs Asynchronous)

• 2. Asynchronous Example (e.g., Python with asyncio):
import asyncio
async def asynchronous_method():
result = await long_computation() # Does not block, continues with other tasks
return result
async def main():
response = await asynchronous_method() # The program can do other tasks while waiting for result

asyncio.run(main())

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 109
Engineering ,Samuel
 Sequence Diagram Notations..cont

• Create message – We use a Create message to

instantiate a new object in the sequence diagram.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 110
Engineering ,Samuel
 Sequence Diagram Notations..cont

• Delete Message – We use a Delete Message to delete

an object. When an object is deallocated memory or is
destroyed within the system we use the Delete Message
symbol.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 111
Engineering ,Samuel
 Sequence Diagram Notations..cont

• Self Message – Certain scenarios might arise where the

object needs to send a message to itself. Such messages
are called Self Messages and are represented with a U
shaped arrow.

• Reply Message – Reply messages are used to show the

message being sent from the receiver to the sender. We
represent a return/reply message using an open
arrowhead with a dotted line.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 112
Engineering ,Samuel
 Sequence Diagram Notations

• Found Message – A Found message is used to represent

a scenario where an unknown source sends the
message. It can be due to multiple reasons and we are not
certain as to what caused the hardware failure.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 113
Engineering ,Samuel
 Sequence Diagram Notations

• Lost Message – A Lost message is used to represent a

scenario where the recipient is not known to the
system.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 114
Engineering ,Samuel
 Sequence Diagram Notations

The warning might be generated for the user or other

software/object that the lifeline is interacting with. Since
the destination is not known before hand, we use the Lost
Message symbol.
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 115
Engineering ,Samuel
• To elaborate it in detail Sequence diagrams have the
following types of elements:
– Classes and objects,
– A lifeline, represents the existence of the element over
time.
– A communication, (a horizontal solid line) represents that
the sender sends a message or stimulus to the receiver.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 116
Engineering ,Samuel
 Cont’d
• Lifelines
The dotted line that extends down the vertical
axis from the base of each object.

• Messages A
Labeled as arrows, with the arrowhead
indicating the direction of the call.
Create
• Activation bar B
The long, thin boxes on the lifelines are
method-invocation boxes indicting that
indicate processing is being performed by the
target object/class to fulfill a message.

• Deletion
– Placing an ‘X’ on lifeline Activation bar X
– Object’s life ends at that point Return
Deletion
Lifeline

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 117
Engineering ,Samuel
Cont’d

• The following figure, is a sequence diagram for the

SetTime use case of our simple watch.
• The leftmost column represents the WatchUser actor
who initiates the use case.
• Labeled arrows represent stimuli that an actor or an object
sends to other objects.
• In this case, the WatchUser presses button 1 twice and
button 2 once to set her watch a minute ahead. The
SetTime use case terminates when the WatchUser presses
both buttons simultaneously.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 118
Engineering ,Samuel
 Actor Object

:Watch :LCDDisplay :Time

:WatchUser

pressButton1() blinkHours()
pressButton1() blinkMinutes()

Message pressButton2() incrementMinutes()

refresh()
pressButtons1And2()
commitNewTime()
stopBlinking()

Activation
Lifeline

Sequence diagrams represent the behavior as interactions

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 119
Engineering ,Samuel
 Cont’d

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 120
Engineering ,Samuel
 Cont’d
• A sequence diagram displays object interactions arranged in a
time sequence

course form : theManager :

Registrar Create Course
: Registrar CourseForm CurriculumManager

This use case begins after

the Registrar logs onto
1: set course info
the Registration System 2: request processing
with a valid password.
The registrar fills in the 3: add course
course form with the
appropriate semester
and course related info. 4: <<create>> aCourse :
The Registrar requests the Course
system to process the
course form.
The system creates a new
course, and this use
case ends

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 121
Engineering ,Samuel
 UML – Collaboration (Communication)
• Displays object interactions organized around objects and their direct links
to one another.
• Emphasizes the structural organization of objects that send and receive
messages.

course form:
course form : theManager : 1: set course info CourseForm
: Registrar CourseForm CurriculumManager 2: request processing

1: set course info

2: request processing
: Registrar 3: add course
3: add course

4: <<create>> aCourse:
Course
theManager :
aCourse: CurriculumManager
Course
4: <<create>>

Traceability!
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 122
Engineering ,Samuel
• What would be the corresponding collaboration diagram?

: Student registration registration math 101 math 101

form manager section 1
1: fill in info
2: submit
3: add course(Sue, math 01)
4: are you open?
5: are you open?
6: add (Sue)
7: add (Sue)

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 123
Engineering ,Samuel
Implementation diagrams
– Component diagrams
– Deployment diagrams

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 124
Engineering ,Samuel
UML – Component Diagram
• Component diagrams illustrate the pieces of software,
embedded controllers, etc., that will make up a system.
• It does not describe the functionality of the system but it
describes the components used to make those
functionalities.
• Depicts the components that compose an application,
system, or enterprise.
• The components, their interrelationships, interactions, and
their public interfaces are depicted.
• A component diagram displays the structural relationship
of components of a software system.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 125
Engineering ,Samuel
Cont’d

• They are the building blocks so a component can

eventually encompass a large portion of a system.
• shows the organizations and dependencies among a set of
components
• These are mostly used when working with complex
systems that have many components.
• Components communicate with each other using
interfaces.
• The interfaces are linked using connectors.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 126
Engineering ,Samuel
 • A provided interface is modeled using the lollipop notation
• A port is a feature of a classifier that specifies a distinct interaction
point between the classifier and its environment.
• Ports are depicted as small squares on the sides of classifiers.
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 127
Engineering ,Samuel
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 128
Engineering ,Samuel
UML: Deployment Diagram
• Represents the static deployment view of an architecture.
• A deployment diagram models the run-time architecture of
a system. It shows the configuration of the hardware
elements (nodes) and shows how software elements and
artifacts are mapped onto those nodes.
• This includes nodes, either hardware or software execution
environments, as well as the middleware connecting them.
• Deployment diagrams are useful when your software solution is
deployed across multiple machines with each having a unique
configuration.
• shows the configuration of run-time processing elements and the
software processes living on them.
• visualizes the distribution of components across the enterprise.
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 129
Engineering ,Samuel
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 130
Engineering ,Samuel
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML
Engineering
Cont’d

• Deployment diagrams have several valuable applications.

You can use them to:
– Show which software elements are deployed by which
hardware elements.
– Illustrate the runtime processing for hardware.
– Provide a view of the hardware system’s topology.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 132
Engineering ,Samuel
UML: Package Diagram

• Shows how model elements are organized into packages as well

as the dependencies between packages.
• As the name suggests a package diagram shows the
dependencies between different packages in a system.
• The complexity of models can be dealt with by grouping related
elements into packages.
• A package is a grouping of model elements, such as use cases,
classes, or activities, defining scopes of understanding.
• Use cases dealing with incident management (e.g., creating,
resource allocation, documentation) are grouped in the Incident
Management package

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 133
Engineering ,Samuel
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 134
Engineering ,Samuel
• The FieldOfficer and EmergencyReport classes are located in
the FieldStation package, and the Dispatcher and
Incidentclasses are located on the DispatcherStationpackage.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 135
Engineering ,Samuel
 Question & Answer

4/10/2025 136