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
Cs 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
 •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 8
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 9
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 10
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 11
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 12
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 13
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 14
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 15
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 16
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 17
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 18
Engineering ,Samuel
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 19
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 20
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 21
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 22
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 23
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 24
Engineering ,Samuel
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 25
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 26
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 27
Engineering ,Samuel
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
 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 30
Engineering ,Samuel
 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 31
Engineering ,Samuel
UML class diagram: classes that participate in the ReportEmergency use case.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 32
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 33
Engineering ,Samuel
 UML class Diagram for Ordering System
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 34
Engineering ,Samuel
• 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 35
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 36
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 37
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 38
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 39
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 40
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 41
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 42
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 43
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 44
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 45
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 46
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 47
Engineering ,Samuel
BIT-Faculty of Computing---
Object Oriented Software 48
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 49
Engineering ,Samuel
 – A fork node splits a flow into multiple concurrent flows.

• A join node synchronizes multiple control flows.

BIT-Faculty of Computing---
Object Oriented Software 50
Diagrams in UML
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 51
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 52
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 53
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 54
Engineering ,Samuel
 Sequence Diagram Notations
• Messages – Communication between objects is
depicted using messages. We represent messages using
arrows. Lifelines and messages form the core of a
sequence diagram.Messages can be broadly classified
into the following categories :
• 1. 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 55
Engineering ,Samuel
 Sequence Diagram Notations

• 2. 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.

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

• 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 57
Engineering ,Samuel
 Sequence Diagram Notations

• 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 58
Engineering ,Samuel
 Sequence Diagram Notations

• 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 59
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 60
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 61
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 62
Engineering ,Samuel
• 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.

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 63
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 64
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
B
• Activation bar
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 65
Engineering ,Samuel
Cont’d
• 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 66
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 67
Engineering ,Samuel
 Cont’d

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 68
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 69
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 70
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 71
Engineering ,Samuel
Implementation diagrams
– Component diagrams
– Deployment diagrams

BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 72
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 73
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 74
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 75
Engineering ,Samuel
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 76
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 77
Engineering ,Samuel
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 78
Engineering ,Samuel
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 79
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 80
Engineering ,Samuel
BIT-Faculty of Computing---
Object Oriented Software Diagrams in UML 81
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 82
Engineering ,Samuel