CHAPTER TWO
1
MODELLING WITH UML
UML
Outline
2
Introduction
A Conceptual Model of the UML
An overview of UML Diagrams
 Use
case diagram
 Class diagram
 Sequence diagram
 Activity diagram
 Deployment diagram
UML
Introduction
3
UML
It stands for Unified Modelling Language
It is a language for specifying, constructing,
visualizing, and documenting the software
system and its components.
UML
Cont…
4
UML is a model which has a
collection of
graphical notation.
A model is a simplification of reality and it helps
to visualize requirements, permit specifications,
and document decision.
It is a language of visualizing, constructing and
documenting the arti-facts of software system.
UML
Cont…
5
A model is an abstract representation of
a system, constructed to understand the
system prior to building or modifying it.
 Most of the modeling techniques involve
graphical languages.
UML
Cont…
6
Why Modeling?
 Models
make it easier to express complex ideas.
For example, an architect builds a model to
communicate ideas more easily to clients.
 Models
reduce complexity by separating those
aspects that are unimportant from those that are
important.
UML
Cont…
7
Advantages of Modeling
 Models
 The
enhance learning.
cost of the modeling analysis is much lower
than the cost of similar experimentation conducted
with a real system.

UML
Manipulation of the model (changing variables) is
much easier than manipulating a real system.
Cont…
8
Primary goals in the design of the UML
 Provide users a ready-to-use, expressive visual modeling
language to develop and exchange meaningful models.
 Provide extensibility and specialization mechanisms to
extend the core concepts.
 Be independent of particular programming languages
 Provide a formal basis for understanding the modeling
language.
 Encourage the growth of the OO tools market.
UML
Cont.…
9
System development focuses on three different
models of the system: The
functional model
 The
object model
 The
dynamic model
UML
Cont.…
10
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 static structure of a system in terms of objects, attributes,
associations, and operations.
The dynamic model


UML
Represented in UML with sequence diagrams, state chart diagrams, and
activity diagrams.
Describes the internal behaviour of the system.
A Conceptual Model of the UML
11
The three major elements that comprise the UML
(conceptual model of the UML) are:
The UML’s basic building blocks
The rules that dictate how those building
blocks may be put together, and
Some
common mechanisms that apply
throughout the UML
UML
Building Blocks of the UML
12
 The
vocabulary of the UML encompasses three kinds of
building blocks: you need to form a conceptual model of
the language,
I.
Elements (things): Main “citizens” of the model
II.
Relationships: tie elements together
III.
Diagrams: mechanisms to group interesting
collections of elements and relationships
UML
Building Blocks of the UML
13
UML
Building Blocks of the UML
14
 Things are the abstractions that are first-class citizens in a
model.
 There are four kinds of things in the UML, which are used to
write well-formed models.
Structural things
Behavioral things
Grouping
things
Annotation things
UML
Elements of UML
15
UML
Elements of UML
16
Structural things
 Structural
things are the nouns of the UML models. These
are the mostly static parts of a model, representing elements
that are either conceptual or physical.
 In all, there are seven kinds of structural things:
Class
 Interface,
 Collaboration,
 Use Case,
 Active Classes,
 Components, and Nodes.

UML
Elements of UML
17
Structural things
 What
A
is a Class?
class is a description of objects that share the same
attributes, operations, relationships, and semantics.
A class is represented using a rectangle with
compartments showing its name, attributes, and
operations.
A class is an abstraction in that it emphasizes relevant
characteristics and suppresses other characteristics.
UML
Elements of UML
18
UML
Elements of UML
19
What is an Interface?
An interface is a collection of operations that specify a service of
a class or component.
 It defines a set of operation specifications (that is their
signatures) but never a set of operation implementations.
 Graphically an interface is rendered as a circle with its name.

UML
Elements of UML
20
What is an Active Class?
 An
active class is a class whose objects own one or more
processes or threads and therefore can initiate control
activity.
 An
active class is just like a class except that its objects
represent elements whose behavior is concurrent with
other elements.
UML
Elements of UML
21
Behavioral things
Behavioral things are the dynamic parts of UML models. These
are the verbs of a model, representing behavior over time and
space. In all, there are two primary kinds of behavioral things:
Interaction and State Machine.
 What is an Interaction?
 An interaction is a behavior that comprises a set of messages
exchanged among a set of objects within a particular context
to accomplish a specific purpose. Graphically, a message is
rendered as a directed line, almost always including the name
of its operation.
display

UML
Elements of UML
22
 What is a State Machine?

A state machine is a behavior that specifies the sequence of states an object in
response to events, together with its responses to those events.

A state represents a particular set of values for an object

It involves a number of other elements in addition to states:


UML
Transitions (the flow from state to state)

Events (things that trigger a transition)

Activities (the response to a transition)
Waits
Graphically, a state is rendered as a rounded rectangle, including its name.
Elements of UML
23
Grouping things
Grouping things are the organizational parts of UML models.
These are the boxes into which a model can be decomposed.
 Example; Packages.
 What is a Package?
 A package is a general-purpose mechanism for organizing
elements into groups. Structural things, behavioral things, and
even other grouping things may be placed in a package.

UML
Relationships in the UML
24
 All
the elements in any software system are
connected to each other either physically or
logically.
 There are four kinds of relationships in the UML:
Dependency
Association
Generalization
Realization
UML
Relationships in the UML
25
Dependency Relationship
 A dependency relationship is a semantic relationship between
two model elements where a change in one may cause a change
in the other.
 Graphically, a dependency is rendered as a dashed line, possibly
directed, and occasionally including a label.
Dependency relationship
UML
Relationships in the UML
26
Association Relationship
 An association is a structural relationship that specifies
that objects (instances of classes) are connected to other
objects.
 Graphically, an association is rendered as a solid line,
possibly directed, occasionally including a label, and
often containing other adornments, such as multiplicity
and role names.
Association relationship
UML
Relationships in the UML
27
Multiplicity is the number of instances of one class that
relate to one instance of another class.
For each association, there are two multiplicity decisions to
make, one for each end of the association.
 For example, a Course Offering object may have either
zero or one Professor object related to it, and conversely a
Professor object may have zero or more Course Offering
objects related to it.
UML
Relationships in the UML
28
 Multiplicity is indicated by a text expression on the role.
 The expression is a comma-separated list of integer
ranges. A range is indicated by an integer (the lower
value), two dots, followed by another integer (the upper
value).
 Example-2:
UML
Relationships in the UML
29
Aggregation is a special kind of association, representing a
structural relationship between an aggregate (the whole) and
its parts. An aggregation “Is-a-part-of” relationship.
 There are many examples of aggregation relationships: a
Library contains Books, Departments are made up of
Employees, a Computer is composed of a number of
Devices.
 Graphically, a hollow diamond is attached to the end of an
association path on the side of the aggregate (the whole) to
indicate aggregation.
UML
Relationships in the UML
30
A generalization is a specialization relationship, in which
objects of the specialized element (the child) are
substitutable for objects of the generalized element (the
parent).
 Generalization is an “Is-a-kind-of” relationship. You
should always be able to say that your specialized class
“Is-a-kind-of” the parent class.
 Graphically, a generalization relationship is rendered as
a solid line with a hollow arrowhead pointing to the
parent as shown below.
UML
Relationships in the UML
31
Generalization relationship
UML
Relationships in the UML
32
 Example of relationships:
UML
Modeling views
33
UML is a multi-diagrammatic language.
 Each diagram is a view into a model
Diagram presented from the aspect of a
particular stakeholder
 Provides a partial representation of the system
 Is semantically consistent with other views

UML
Modeling views
34
Example Views
UML
Model views
35
 In UML, a system is represented using five
different “views” that describe the system from
distinctly different perspectives.
 Each views is defined by a set of diagrams

User model view: it represents the system (product)
from user’s (called actors in UML) perspective.

Structural model view: the data and functionality are
viewed from inside the system. That is, static structure
(classes, objects, and relationships) is modeled.
UML
Model views
36

Behavioural model view: it represent
dynamic or
behavioural aspects of the system. It depicts the interactions or
collaboration between various structural elements.

Implementation model view: Structural and behavioural
aspect of the system as they are to be built.

Environmental model view: The structural and behavioural
aspects of the environment
implemented.
UML
in which the system to be
MODELING
37
UML DIAGRAM
UML
USE CASE DIAGRAM
38
What is a Use Case?
 Use
case is a description of a set of sequence of actions that
a system performs that yields an observable result of value to
a particular actor.
A
use case describes what a system does, but it does not
specify how it does it.
 An
actor represents anything that interacts with the system.
 A use
UML
case is realized by a collaboration.
USE CASE DIAGRAM
39
Use-case Diagram:
 Use
case diagrams represent the
functionality of the system from a user’s
point of view.

UML
A UML use case diagram shows the
relationships among actors and use cases
within a system.
Use case Diagram
40
Use cases describe the system, its environment,
and the relationship between the system and
its environment.
 They define the boundaries of the system
 “It is a graphic representation of the key
features of the written use case reports that
comprise
a
system.”
(McLeod, Jordan)

UML
Use case Diagram
41
What Is a Use-Case Model?
A model that describes a system’s functional
requirements in terms of use cases
It represents system’s intended functionality (use
cases) and its environment (actors)
UML
Use case Diagram
42
Components of use case diagrams
Actor
Use case
System Boundary
Relationship
Actor Relationship
UML
Use case Diagram
43
An Actor :
A
person, organization, local process, external system
that plays a role in one or more interactions with a
system.
 Something with a behavior or role, e.g., a
person, another system, organization.
UML
Use case Diagram
44
An Actor :
 Actors are
not part of the system.
 Actors represent anything that interacts with the system
 a human, a machine, or system.
 Carry out use cases and a single actor may perform
more than one use cases.
 UML notation for actor is stickman
Actor
UML
Use case Diagram
45
What Is an Actor?
Actors
are EXTERNAL.
They can actively interchange information
with the system.
They can be a giver of information.
An actor may input information to the system
and receive information from the system.
UML
Use case Diagram
46
 How do we find an actor?
 Ask the following questions
Who uses the system?
Who installs the system?
Who Starts up the system?
What other systems use this system?
Who gets the information from the system?
Who provides information to the system?
Note: Actor is always external to the system. They are
never part of the system to be developed.
UML
Use case Diagram
47
 4-Categories of an actor:
Primary actor (user):
 Initiates the use case to realize a goal
 Who uses the main system functions.
 Secondary Actor
 Who takes care of administration and maintenance.

participates in the use case but does not initiate it:
External hardware
 devices which are part of application domain
Other system:
 The other system with which the system must interact.
UML
Use case Diagram
48
Case
study-1:
List the actors of
Ambo University Student recoding
system?
Student
Instructor
Registrar
Department
System
UML
(Estudent )
Use case Diagram
49
Use cases:
 A requirements analysis concept
 A case of a use of the system/product
 Describes the system's actions from the user point of view
 Dialogue between an actor and a system.
 Describes a sequence of action that provide a measureable
value to an actor.
 Each use case is a sequence of related transactions
performed by an actor and a system in dialogue.
UML
Use case Diagram
50
Use cases:
 Use case models should be developed from the project
stakeholders point of view, not from the developers (often
technical) point of view.
 It is a collection of related success and failure scenarios,
describing
actors
using
the
system
to
support a goal.
 Represents a major piece of functionality that is complete from
beginning to end.
 A use case is drawn as a horizontal ellipse on a UML use case
diagram.
Use case
UML
Use case Diagram
51
Use Cases and Actors
 Must deliver something of value to an actor.
 A use case models a dialog between actors and the
system.
 A use case is initiated by an actor to invoke a certain
functionality in the system.
UML
Use case Diagram
52
How do we find use cases?

Ask following questions.
What are the
functions that the actor want
from the system?
Does the system store information?
Who will create, read, update or delete that
information.
Does the system need to notify an actor about
changes in its internal states?
UML
Cont…
53
Write at least four
use cases of
Ambo University
Student recoding system?
Case
study-2:
 Register
 View
grade
 Submit grade
 Approve grade
 Add course materials
 Take attendance
 Add/drop course
UML
Use case Diagram
54
System Boundary Box Guidelines:




UML
As the name suggests, it indicates the scope of
your system.
The use cases inside the rectangle represent the
functionality that you intend to implement.
Indicate Release Scope with a System Boundary
Box
Avoid Meaningless System Boundary Boxes
Use case Diagram
55
System Boundary:
The rectangle around the use cases is called the
system boundary box.
It represents the boundaries between the physical
system and the actor who interact with the physical
system.
UML notation for System Boundary is rectangle
System Boundary
UML
Use case Diagram
56
Use case diagram-Example one
UML
Use case Diagram
57
Guidelines for use case diagram
 Use case diagrams should not reflect timing considerations.
 The name of a use case should immediately convey meaning to
the project stakeholders.
 Increase the readability of the use case diagrams by arranging
use cases to imply timing.
 Define preconditions in the use cases to describe timing
considerations.
UML
Use case Diagram
58
Use case diagram-Example two
UML
Use case Diagram
59
Relationships
 There are several types of relationships that may appear
on a use case diagram
 An association between an actor and a use case
 An association between two use cases,
 A generalization between two actors
 A generalization between two use cases
UML
Use case Diagram
60
Relationship between use-case
 Associations are depicted as lines connecting two
modeling elements
 Generalizations are depicted as close-headed arrow with
the arrow pointing toward the more general modeling
element .
UML
Use case Diagram
61
Relationship between use-case
<<include>> relationship
i.
 One use case (base) includes the functionality of
another (inclusion case)
 Supports re-use of functionality
 It shows that the behavior of one use case is wholly
and unconditionally used in another use case.
UML
Use case Diagram
62
Relationship between use-case
<<include>> relationship
 The base use case explicitly incorporates the behavior of
another use case at a location specified in the base.
 The included use case never stands alone.
 It only occurs as a part of some larger base that includes it.
UML
Use case Diagram
63
Relationship between use-case
<<include>> relationship - example
UML
Use case Diagram
64
Relationship between use-case
ii. <<extend>> relationship
 The base use case implicitly incorporates the behavior of another
use case at certain points called extension points.
 The base use case may stand alone, but under certain conditions its
behavior may be extended by the behavior of another use case.
UML
Use case Diagram
65
Relationship between use-case
<<extend>> relationship
It is a generalization relationship where the extending use
case continues the behavior of the base use case by
conceptually inserting additional action sequences into the
base use case.
One use case (extension) extends the behavior of another
(base)
new use case conditionally augment (or extend) the behavior
of another use.
Apply <<extend>> When a Use Case May Be invoked
Across Several Use Case steps
UML
Use case Diagram
66
Example- Relationship
UML
Use case Diagram
67
Case
study-3: Draw the use case
diagram
of
Ambo University
Student recoding system?
UML
Use case Diagram
68
Scenario
it is a set of actions performed to achieve a goal under
some conditions፤ Actions specified as a sequence of steps
 A step is a logically complete action performed either by
the actor or the system
 Two types of Scenarios

 Main
success Scenario: when things go normally and the goal
is achieved.
 Alternatives Scenario: When things go wrong and goals
cannot be achieved.
UML
Use case Diagram
69
Generally, Each use case may include all or part of the following
UML
Use case Diagram
70

Example: The following use case describes the process
of opening a new account
 Use case:
Open new Account .
 Actors:
Customer, Cashier, Manager
 Purpose:
Like to have a new saving account
 Overview: A Customer arrives in the bank to open the
new account. Customer
requests for the new
account form, fill the same and submits, along with the
minimal deposit. At the end of complete successful
process customer receives the passbook
 Type: primary use case
UML
Use case Diagram
71
 Normal Flow of Events
 For withdrawal of cash:
1.
2.
3.
4.
5.
6.
7.
8.
UML
(SR) The ATM asks the user to insert a card.
(AA) The user inserts a cash card.
(SR) The ATM accepts the card and reads its serial number.
(SR) The ATM requests the password.
(AA) The user enters 1234.
(SR) The ATM verifies the serial number and password with
the bank and gets the notification accordingly.
(SA)The ATM asks the user to select the kind of transaction.
(AA)User selects the withdrawal
Use case Diagram)
72
9. (SR)The ATM asks for the amount of cash; user enters Birr 200
10. (SR)The ATM verifies that the amount of cash is within
11.
12.
13.
14.
15.
16.
17.
UML
predefined policy limits and asks the bank, to process the
transaction which eventually confirms success and returns the new
account balance.
(SR) The ATM dispenses cash and asks the user to take it.
(AA) The user takes the cash.
(SR) The ATM asks whether the user wants to continue.
(AA) The user indicates no.
(SR) The ATM prints a receipt, ejects the card and asks the user to
take them
(AA) The user takes the receipt and the card.
(SR) The ATM asks a user to insert a card.
Use case Diagram
73
Alternative Flow of Events
For withdrawal of cash use case:
 9. The ATM asks for the amount of cash; the user has
change of mind and hits the “cancel”.
Exceptional Flow of Events
For withdrawal of cash use case:
 3. Suspicious pattern of usage on the card.
 10. The machine is out of cash.
 11. Money gets stuck in the machine.
UML
Use case Diagram
74
Case
study-4: Show the use case
documentation of Ambo University
Student recoding system?
UML
UML Diagram
75
Class Diagram
UML
Class Diagram
76
 Class diagrams capture the static structure of Object-Oriented
systems, or how they are structured rather than how they
behave.
 The Class defines what an object can do. It is a template to
create various objects and implement their behavior in the
system.
 It describes classes and their interrelationships.
 Used for describing structure and behavior in the use cases.
UML
Class Diagram
77
Class Diagram describes the structure of a system that gives
an overview of a software system by displaying
 Classes
 Attributes
 operations
 Their
UML
(or methods),
relationships among each other.
Class Diagram
78
 A class is a description of a set of
objects that share the same
attributes, operations, relationships, and semantics.
 Graphically, a class is rendered as a rectangle, usually including its
name,
attributes,
and
operations
compartments.
Basic Class Compartments



UML
Class Name
Attributes
Operations
in
separate,
designated
Class Name
attributes
operations
Class Diagram
79
Class Name
 The name of the class is the only required tag in the graphical
representation of a class.
 It always appears in the top-most compartment.
ClassName
attributes
operations
UML
Class Diagram
80
Class Attributes
 Represent the state of an object of the class.
 Are descriptions of the structural or static features of a class
Person the object
 An attribute is a named property of a class that describes
being modeled.
name
: String
address : Address
 In the class diagram, attributes appear in the second compartment
birthdate : Date
just below the name-compartment.
ssn
: Id
UML
Class Diagram
81
Class Attributes
 Attributes (fields, instance variables)

visibility name : type [count] = default value
 Visibility of Attributes can be:
+ public
# protected
- private
/ derived
UML
Class Diagram
82
 Visibility is an important design issue. On detailed design
models, you should always indicate the visibility of attributes
and operations.
UML
Class Diagram
83
Class Operations
 Operations describe the class behavior and appear in the third
Person
compartment.
name
: String
 Type is the data type of the attribute or the data returned by the
address : Address
birthdate : Date
operation.
ssn
: Id
 Define the way in which objects may interact.
eat
 Operations are descriptions of behavioral or dynamic features of a
sleep
class.
work
play
UML
Class Diagram
84
Class Diagram- Example
Account_Name
- Customer_Name
- Balance
+addFunds( )
+withDraw( )
+transfer( )
UML
Name
Attributes
Operations
Class Diagram
85
Class relationship
 In UML, object interconnections (logical or physical), are modeled
as relationships.
 There are three kinds of relationships in UML:

Dependencies

Generalizations

Associations
UML
Class Diagram
86
Generalization relationship
 A generalization connects a subclass to its superclass.
 It denotes an inheritance of attributes and behavior from the
superclass to the subclass and,
 It indicates a specialization in the subclass of the more general
superclass.
UML
Class Diagram
87
Generalization relationship
 Place Subclasses Below Super classes

Inheritance goes up
 A Subclass Should Inherit Everything

Subclass should inherit all of the attributes and operations of its super
class, a concept called pure inheritance

The advantage of pure inheritance is that you only have to understand
what a subclass inherits, and not what it does not inherit.
UML
Class Diagram
88
Dependency relationship
 A dependency indicates a semantic relationship between two or more
elements.
 In a dependency relationship, two or more elements are dependent
on each other.
 The dependency from CourseSchedule to Course exists because
Course is used in both the add and remove operations of
CourseSchedule.
UML
Class Diagram
89
Association relationship
 If two classes need to communicate with each other, there must be link
between them. This is an association denotes that link.
 We can indicate the multiplicity of an association by adding multiplicity.
 The example indicates that a Student has one or more Instructors and
every Instructor has one or more Students:
 We can also indicate the behavior of an object in an association (i.e., the
role of an object) using rolenames.
UML
Class Diagram
90
UML
Class Diagram - Example 1
91
UML
Class Diagram - Example 2
92
UML
Interaction Diagram
93
 A series of diagrams describing the
dynamic behavior of
an object-oriented system.
A
set of messages exchanged among a set of objects
within a context to accomplish a purpose.
 Often used to model the way a use case is realized through
a sequence of messages between objects.
UML
Interaction Diagram
94
The purpose of Interaction diagrams is to:

Model interactions between objects

Assist in understanding how a system (a use case) actually works

Verify that a use case description can be supported by the existing classes

Identify responsibilities/operations and assign them to classes

There are two types of interaction diagrams :
 Collaboration
 Sequence
UML
Diagrams
Diagram
Sequence Diagram
95
Sequence diagrams describe behaviour as a
sequence of messages
exchanged among a set of objects.

It describe patterns of communication among a set of
interacting objects.

An object interacts with another object by sending messages.

It show sequence of messages among the objects.

The reception of a message by an object triggers the execution
of an operation.
UML
Sequence Diagram
96
Typically, we use a sequence diagram to:
 Describe the event flow of a use case.
 Identify the objects that participate in the use case
 Assign pieces of the use case behaviour to the objects in the form
of services.
 This process often leads to refinements in the use case (e.g.,
correcting ambiguous descriptions, adding missing behaviour)
and consequently, the discovery of more objects and more
UML
services.
Sequence Diagram
97

Shows object interaction arranged in time sequence.

It has two dimensions, vertical represents time & horizontal
represents objects

detect bottlenecks within an object-oriented design. By looking at
what messages are being sent to an object, and by looking at roughly
how long it takes to run the invoked method.
UML
Sequence Diagram
98

Components of sequence diagram:

Objects

Object lifeline

Message

Activation Bar

pre/post conditions.
Name:Class

Object are represented by rectangles and name of the objects are underlined

Object life line are denoted as dashed lines. They are used to model the existence
of objects overtime.
UML
Sequence Diagram
99
Messages
 An interaction between two objects is performed as a message sent
from one object to another (simple operation call, Signaling, RPC)
 If object obj1 sends a message to another object obj2 some link must
exist between those two objects (dependency, same objects)

Messages are used to model the content of communication between
objects.
UML
Sequence Diagram
100

The message instance has a sender, receiver, and possible other
information according to the characteristics of the request

Messages are denoted as labelled horizontal arrows between life
lines.

The sender will send the message and receiver will receive the
message.

Object life line are denoted as dashed lines. They are used to
model the existence of objects overtime.
UML
Sequence Diagram
101
Activation Bar:

Activation or Execution Occurrence

Activation boxes represent the time an object needs to complete a
task.

When an object is busy executing a process or waiting for a reply
message, use a thin gray rectangle placed vertically on its lifeline.
UML
Sequence Diagram
102
General Guidelines of sequence diagram

Strive for Left-to-Right Ordering of Messages

Strive to arrange the classifiers (actors, classes, objects, and use cases)
across the top of your diagram in such a way as to depict message flow
from left to right.

Give an Actor the Same Name as a Class, if Necessary

Example: an actor named Student and a class named Student. This is
perfectly fine because the two classifiers represent two different concepts.

The actor represents the student in the real world whereas the class represents
the student within the business application that you are building.
UML
Sequence Diagram
103
member:
LibraryMember
book:Book
:Book
Copy
borrow(book)
ok = mayBorrow()
[ok] borrow(member)
Sequence Diagrams
setTaken(member)
Sequence Diagram
104
X-Axis (objects)
member:
LibraryMember
borrow(book)
Y-Axis (time)
ok = mayBorrow()
message
Sequence Diagrams
[ok] borrow(member)
condition
:Book
Copy
book:Book
Life
Line
setTaken(member)
Object
Activation
box
Sequence Diagram
105
Example- Login Use case
UML
Sequence Diagram
106
Example: For withdrawal of cash using ATM
UML
Sequence Diagram
107
Sequence diagram for reservation
UML
Sequence Diagram
108
Sequence diagram for Money Withdrawal
UML
Collaboration Diagram
109
UML Collaboration Diagram

Like UML sequence diagrams, it used to explore the dynamic nature
of a software.

Collaboration diagrams show the message flow between objects in an
object-oriented application, and also imply the basic associations
(relationships) between classes

Unlike sequence diagram the time is not explicitly represented in
these diagram

UML
The sequence of messages is indicated by numbering the messages.
Collaboration Diagram
110

Components of collaboration diagram

Named objects

Links: by a continuous line between objects, and indicates the
exchange of messages

UML
Messages has following attributes

Synchronization --thread name, step within thread.

Sequence number

Message labels : Message names may have the arguments and return values.

*[iteration]. It uses decimal notation.

Message direction.
Collaboration Diagram
111

Semantics of components:

Object names identify which objects are participating and the links
show which objects collaborate

A link between two objects must exist for one object to send message
to another and vice a versa.

Messages in the collaboration diagram get transformed to more
detailed signature.

They use the decimal notation system for numbering the messages.

The direction of the message defines the sender and receiver of
the message
UML
Collaboration Diagram
112
1. Insert card
3. Enter password,
7. Enter kind
10. Enter amount,
15. Take cash, Take card
17. cancel, Terminate
CUSTOMER
8. Create Transaction
12. Transaction complete
ATM
2. request password,
6. request kind,
9. request amount,
14. dispense cash, request take cash
16. request continuation,
18. print receipt, request take card
4. Verify account,
19. Display main screen
11. process transaction
BANK
Collaboration Diagram
UML
TRANSACTION
13. Transaction succeed
5. account ok.
Activity Diagrams
113
 It is the UML for modeling the dynamic aspects of systems.
 An activity diagrams is essentially a flowchart, showing flow of
control from activity to activity.
 Activities are states that represent the execution of a set of
operations.
 The completion of these operations triggers a transition to
another activity.
UML
Activity Diagrams
114
Example:
UML
Activity Diagrams
115
Example:
UML
Deployment Diagrams
 UML deployment diagrams
 UML
116
deployment diagram is used to describe the relationship
among run-time components and hardware nodes.
 It
show the configuration of run-time processing elements and the
software components, processes, and objects that execute on them.
 It
provides the necessary environment for the components to
execute in.
A
UML deployment diagram representing the allocation of
components to different nodes and the dependencies among
components
UML
Deployment Diagrams
117
Example: Web browsers on PCs and Macs can access a
Web Server that provides information from a Database.
UML
Deployment Diagrams
118
UML
119
End!
UML