Oose 3

Activity # 3: Diagrams in the UML
Structural Diagrams
Behavioral Diagrams
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
Engineering
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.
Engineering
– 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.
• In this activity, we describe UML diagrams for representing these
models.
• It is necessary to understand the notation before describing the
activities
Engineering
• 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
Engineering
• 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
Engineering
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 different symbol has a special meaning in the context of
the UML. The user can use text to describe the concepts from
the system under development.
• 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.
Engineering
•In general, we have two major types of the UML diagrams: structural
diagrams and behavioral diagrams. The behavioral diagrams also include the
interaction diagrams.
Engineering
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, a subset of behavior
diagrams, emphasize the flow of control and data
among the things in the system being modeled:
Engineering
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.
Engineering
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
Engineering
Engineering
• 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)
Engineering
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
Engineering
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
Engineering
Actors
• An actor models an external entity which
communicates with the system:
– User
– External system
– Physical environment
• An actor has a unique name and an optional
Passenger
description.
• Examples:
– Passenger: A person in the train
– GPS satellite: Provides the system with GPS
coordinates
Engineering
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
Engineering
• 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
Engineering
Textual Use Case Description Example
PurchaseTicket
Passenger
1. Use case Name: Purchase ticket 5. Flow of events:

1. Passenger selects the number of
2. Participating actor: Passenger zones to be traveled
2. Ticket Distributor displays the
amount due
3. Entry condition:
3. Passenger inserts money, at least
• Passenger stands in front of the amount due
ticket distributor 4. Ticket Distributor returns change
• Passenger has sufficient money 5. Ticket Distributor issues ticket
to purchase ticket 6. Special requirements: None.
4. Exit condition:
• Passenger has ticket
Engineering
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.
Engineering
Engineering
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>>
Engineering 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 because it is an
PurchaseMultiCard exception.
PurchaseSingleTicket • The direction of a <<includes>>
<<includes>> relationship is to the using use
<<includes>> case (unlike <<extends>>
relationships).
CollectMoney
<<extends>> <<extends>>
NoChange Cancel
Engineering
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
Engineering
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
case.
PurchaseTicket
• The direction of a <<extends>>
<<extends>>
relationship is to the extended use case
<<extends>>
<<extends>>
OutOfOrder <<extends>> TimeOut
BIT-Faculty of Computing--- Cancel NoChange

Engineering
The generalization relationship
• Shows inheritance and specialization

• One use case is simply a special kind of another
Engineering
Engineering
• 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)
Engineering
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.
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.
Engineering
UML class diagram: classes that participate in the ReportEmergency use case.
Engineering
• 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.
Engineering
UML class Diagram for Ordering System
Engineering
• 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.
Engineering
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.)
Engineering
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 :
BIT-Faculty of Computing--- : Student
Engineering
An example of a UML object diagram: objects that participate in
EmergencyReport Scenario
Engineering
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 .
Engineering
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.
Engineering
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
Engineering
State Diagrams
(Traffic light example)
Traffic Light Start

State
Transition Red
Yellow
Green
Event
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.
Engineering
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.
Engineering
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.
Engineering
•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.
Engineering
• 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.
Engineering
A decision node appears as a diamond, as shown in diagram
below
• A merge node brings together multiple alternate control

flows.
SE- Analysis Modeling 47

– A fork node splits a flow into multiple concurrent flows.
• A join node synchronizes multiple control flows.
48
SE- Analysis Modeling
[lowPriority]
Open Allocate
Incident Resources
[fire & highPriority]
[not fire & highPriority]

Notify
Fire Chief
Notify
Police Chief
Engineering
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
Engineering
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.
• 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.
Engineering
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.
Engineering
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

Engineering
• 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.
Engineering
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.
• Rectangle also denotes when object is

deactivated.
Activation bar X
Return
• Deletion Deletion
– Placing an ‘X’ on lifeline
– Object’s life ends at that point Lifeline
Engineering
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
with a valid password.
2: request processing
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
Engineering
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!
Engineering
• 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)
Engineering
Implementation diagrams
– Component diagrams
– Deployment diagrams
Engineering
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.
Engineering
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.
Engineering
• 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.
Engineering
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.
Engineering
Engineering
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.
Engineering
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
Engineering
Engineering
• The FieldOfficer and EmergencyReport classes are located in
the FieldStation package, and the Dispatcher and
Incidentclasses are located on the DispatcherStationpackage.
Engineering

Oose 3

Uploaded by

Copyright:

Available Formats

Oose 3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oose 3

Uploaded by

Copyright:

Available Formats

Activity # 3: Diagrams in the UML

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

– Application Domain (Requirements Analysis)

• The Rift Valley University wants to computerize its registration

Use case diagrams represent the functionality of the system

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

• Include relationships are used when two or more use cases

Register for <<includes>>

OutOfOrder <<extends>> TimeOut

BIT-Faculty of Computing--- Cancel NoChange

• Shows inheritance and specialization

• Both Make Appointment and Request Medication

• The extension point is written inside the base case

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

– write only the object name oneStudent:

Traffic Light Start

• Activity diagrams model the workflow of a business

• A decision node offers a choice among two or more

• A merge node brings together multiple alternate control

SE- Analysis Modeling 47

• A join node synchronizes multiple control flows.

[fire & highPriority]

[not fire & highPriority]

Then, how about the inside view of the system?

• Interaction diagrams describe how use cases are realized in

• types of interaction diagrams

:Watch :LCDDisplay :Time

Message pressButton2() incrementMinutes()

Sequence diagrams represent the behavior as interactions

• Rectangle also denotes when object is

course form : theManager :

This use case begins after

1: set course info

: Student registration registration math 101 math 101

• Component diagrams illustrate the pieces of software, embedded

• Depicts the components that compose an application, system, or

• A component diagram displays the structural relationship of components of

• They are the building blocks so a component can

• Deployment diagrams have several valuable applications.

• Shows how model elements are organized into packages as well

You might also like