CHAPTER TWO

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 enhance learning.
 The cost of the modeling analysis is much lower
than the cost of similar experimentation conducted
with a real system.
 Manipulation of the model (changing variables) is
much easier than manipulating a real system.

UML
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
 Represented in UML with sequence diagrams, state chart diagrams, and
activity diagrams.
 Describes the internal behaviour of the system.

UML
 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 is a Class?
A 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:

 Transitions (the flow from state to state)

Waits
 Events (things that trigger a transition)

 Activities (the response to a transition)

 Graphically, a state is rendered as a rounded rectangle, including its name.

UML
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 in which the system to be
implemented.
UML
 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 case is realized by a collaboration.

UML
USE CASE DIAGRAM
39

Use-case Diagram:
 Use case diagrams represent the
functionality of the system from a user’s
point of view.
 A UML use case diagram shows the
relationships among actors and use cases
within a system.

UML
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 (Estudent )
UML
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

Case study-2:
Write at least four
use cases of Ambo University
Student recoding system?
 Register
 View grade
 Submit grade
 Approve grade
 Add course materials
 Take attendance
 Add/drop course

UML
Use case Diagram
54

System Boundary Box Guidelines:

 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

UML
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

i. <<include>> relationship
 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. (SR) The ATM asks the user to insert a card.
2. (AA) The user inserts a cash card.
3. (SR) The ATM accepts the card and reads its serial number.
4. (SR) The ATM requests the password.
5. (AA) The user enters 1234.
6. (SR) The ATM verifies the serial number and password with
the bank and gets the notification accordingly.
7. (SA)The ATM asks the user to select the kind of transaction.
8. (AA)User selects the withdrawal
UML
 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
predefined policy limits and asks the bank, to process the
transaction which eventually confirms success and returns the new
account balance.
11. (SR) The ATM dispenses cash and asks the user to take it.
12. (AA) The user takes the cash.
13. (SR) The ATM asks whether the user wants to continue.
14. (AA) The user indicates no.
15. (SR) The ATM prints a receipt, ejects the card and asks the user to
take them
16. (AA) The user takes the receipt and the card.
17. (SR) The ATM asks a user to insert a card.

UML
 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 (or methods),

 Their relationships among each other.

UML
 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 in separate, designated

compartments. Class Name
Basic Class Compartments
attributes
 Class Name
 Attributes
 Operations operations
UML
 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
operation. birthdate : Date
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

Name
Account_Name
- Customer_Name
- Balance Attributes

+addFunds( ) Operations
+withDraw( )
+transfer( )

UML
 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 Diagrams

 Sequence Diagram

UML
 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: Name:Class

 Objects
 Object lifeline
 Message
 Activation Bar
 pre/post conditions.
 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: :Book
book:Book
LibraryMember Copy

borrow(book)
ok = mayBorrow()

[ok] borrow(member)
setTaken(member)

Sequence Diagrams
Sequence Diagram
104

X-Axis (objects)

member: :Book
book:Book
LibraryMember Copy

borrow(book)
Life Object
ok = mayBorrow()
Y-Axis (time)

Line
message
Activation
[ok] borrow(member)
setTaken(member) box
condition

Sequence Diagrams
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

 The sequence of messages is indicated by numbering the messages.

UML
Collaboration Diagram
110

 Components of collaboration diagram

 Named objects
 Links: by a continuous line between objects, and indicates the
exchange of messages
 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.
UML
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
8. Create Transaction
10. Enter amount,
12. Transaction complete
15. Take cash, Take card
17. cancel, Terminate

CUST- TRANSA-
ATM CTION
OMER
2. request password,
6. request kind,
9. request amount,
13. Transaction succeed
14. dispense cash, request take cash
5. account ok.
16. request continuation,
18. print receipt, request take card
4. Verify account,
19. Display main screen
11. process transaction

BANK
Collaboration Diagram
UML
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
116
 UML deployment diagrams
 UML 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