CET 2030B- Software Design with UML

• Requirements Analysis Using Case Modeling - Analysis of system

requirements. Actor definitions. Writing a case goal. Use Case Diagrams.
Use Case Relationships. Transfer from Analysis to Design in the
Characterization Stage: Interaction Diagrams. Description of goal. Defining
UML Method, Operation, Object Interface, Class. Sequence Diagram.
Finding objects from Flow of Events. Describing the process of finding
objects using a Sequence Diagram. Describing the process of finding objects
using a Collaboration Diagram.
4+1 Architecture
4+1 Architecture
• There are many different stakeholders related to a software system,
which all have different perspectives. Project/Project Managers,
Developers, System Engineers, End Users all view a system in
completely different ways. They view the system based on their own
context.
• The four views of the model are logical, development, process and
physical view. In addition, selected use cases or scenarios are used to
illustrate the architecture serving as the 'plus one' view.
4+1 View Architecture
• Logical view: The logical view is concerned with the functionality that the system provides to end-users. UML
diagram are used to represent the logical view, and include class diagrams , and state diagrams.
• Process view: The process view deals with the dynamic aspects of the system, explains the system processes and
how they communicate, and focuses on the run time behavior of the system. The process view addresses
concurrency, distribution, integrator, performance, and scalability, etc. UML diagrams to represent process view
include the sequence diagram, communication diagram and activity diagram.
• Development view: The development view (aka the implementation view) illustrates a system from a programmer's
perspective and is concerned with software management. UML Diagrams used to represent the development view
include the package diagram and component diagram.
• Physical view: The physical view (aka the deployment view) depicts the system from a system engineer's point of
view. It is concerned with the topology of software components on the physical layer as well as the physical
connections between these components. UML diagrams used to represent the physical view include the
deployment diagram.
• Scenarios: The description of an architecture is illustrated using a small set of use cases , or scenarios, which
become a fifth view. The scenarios describe sequences of interactions between objects and between processes.
They are used to identify architectural elements and to illustrate and validate the architecture design. They also
serve as a starting point for tests of an architecture prototype. This view is also known as the use case view.
Why use UML
• Open Standard, Graphical notation for
• Specifying, visualizing, constructing, and documenting software systems
• Language can be used from general initial design to very specific
detailed design across the entire software development lifecycle
• Increase understanding/communication of product to customers and
developers
• Support for diverse application areas
• Support for UML in many software packages today (e.g. Rational,
plugins for popular IDE’s like NetBeans, Eclipse)
• Based upon experience and needs of the user community
UML
• UML diagrams
– Static modeling
(Structure Diagrams)
– Dynamic modeling
(Behavior Diagrams)

Software Engineering and Project Management- UNIT II 7

3/3/2025
Structural Modeling Diagram
• Class Diagram
• Object Diagram
• Component Diagram
• Package Diagram
• Composite Structure
• Deployment Diagram
Behavioral Modeling Diagram
• Use Case Diagram
• Activity Diagram
• State Machine Diagram
• Communication Diagram
• Sequence Diagram
• Timing Diagram
• Interaction Overview Diagram
Dynamic Modeling ( Behavioral Diagrams)
● Use case diagram
● Activity diagram
● State machine diagram
● Interaction : Interaction overview diagram, sequence diagram, Timing
diagram
● Communication diagram

3/3/2025 Software Engineering and Project Management- UNIT II 10

Use Case Diagram
• A use case diagram describes how a system interacts with outside actors
• It is a graphical representation of the interaction among the elements and system
• Each use case represents a piece of functionality that a system provides
• The use case diagram allows for the specification of higher level user goals
• A use case diagram contains four components
– The boundary
– The actor
– The use case
– The relationship between and among the actors and the use cases

3/3/2025 Software Engineering and Project Management- UNIT II 11

Use Case Diagram
• Use case is one way of representing system functionality.

• Use case refers to

• A system’s behavior (functionality)
• A set of activities that produce some output.
• Think in terms of main processes happening in the system.
In the simplest form, use case is a list of functions for a user;

• Use verbs for naming use cases.

3/3/2025 Software Engineering and Project Management- UNIT II 12

Use Case Diagram
S.No Name Description Notation
1 System Boundary The scope of a system can be represented by a
system boundary

2 Use case A sequences of actions (it must be a verb)

PurchaseTicket

3 Actor User (or) someone / something outside the

system that interacts with the system (it must
be a noun)

4 Association It corresponds to a sequence of actions

between the actor and use case

5 Generalization Inheritance relationship between model

elements of same type
3/3/2025 Software Engineering and Project Management- UNIT II 13
Use Case Diagram
S.No Name Description Notation
6 Include It specifies how the behavior of the inclusion <<include>>
use case is inserted into the behavior defined
for the base use case

7 Extend How the behavior of the extension use case <<extend>>

can be inserted into the behavior defined for
the base use case
9 Note Note is generally used to write comment in use
case diagram

3/3/2025 Software Engineering and Project Management- UNIT II 14

Actors

3/3/2025 Software Engineering and Project Management- UNIT II 15

Example 2: Use case Diagram for a dictionary system

• In this system, the user first login to the system with user name and password. user
name of every user is unique.
• The user enters the word to the system for finding meaning of the word.
• The system searches the meaning for the given word.
• If the word is available on the database then the system retrieve and display the
meaning for the word otherwise it show the message box that contains please enter
correct word.

3/3/2025 Software Engineering and Project Management- UNIT II 16

3/3/2025 Software Engineering and Project Management- UNIT II 17
Use of Extend stereotype between Use Cases
• Extend –

• linking an optional use case to a standard use case.

• Example: Register Course (standard use case) may have

• Register for Special Class (extend use case).

• Standard use case can execute without the extend case.

• 🡪 loose coupling

3/3/2025 Software Engineering and Project Management- UNIT II 18

• University Registration System

3/3/2025 Careful: Arrows between Use and

Software Engineering Cases
Projectare NOT data
Management- UNIT II flows! 19
Use of Include stereotype between Use Cases
• Include stereotype –
a standard case linked to an mandatory use case.
Example: to Authorize Car Loan (standard use case), a clerk must
run Check Client’s Credit History (include use case).

🡪 tight coupling

• Standard use case can NOT execute without the include case.

3/3/2025 Software Engineering and Project Management- UNIT II 20

Extend Relation between Use Cases
• Credit Card Processing

3/3/2025 Careful: Arrows between Use and

Software Engineering Cases
Projectare NOT data
Management- UNIT II flows! 21
Extend and Include(Stereotype)

3/3/2025 Software Engineering and Project Management- UNIT II 22

Use Case Example
• Login:
– Captcha
– Password
– Answer Secret Questions
• Log out

3/3/2025 Software Engineering and Project Management- UNIT II 23

Example : Login

3/3/2025 Software Engineering and Project Management- UNIT II 24

Use Case Diagram for Website Use Case
• Consider the User and Webmaster
• User can login, browse and search document.
– Download is also possible
– User can view event only if he is logged in
• Webmaster is responsible for adding user, uploading documents and
posting events .
– Uploaded documents have to be put in folders
– When a User is added , the Company is also added

3/3/2025 Software Engineering and Project Management- UNIT II 25

Use Case Diagram for Website Use Case

3/3/2025 Software Engineering and Project Management- UNIT II 26

Dynamic Modeling ( Behavioral Diagrams)
● Use case diagram
● Activity diagram
● State machine diagram
● Interaction : Interaction overview diagram, sequence diagram, Timing
diagram
● Communication diagram

3/3/2025 Software Engineering and Project Management- UNIT II 27

Use Case Diagram
• A use case diagram describes how a system interacts with outside actors
• It is a graphical representation of the interaction among the elements and system
• Each use case represents a piece of functionality that a system provides
• The use case diagram allows for the specification of higher level user goals
• A use case diagram contains four components
– The boundary
– The actor
– The use case
– The relationship between and among the actors and the use cases

3/3/2025 Software Engineering and Project Management- UNIT II 28

Use Case Diagram
• Use case is one way of representing system functionality.

• Use case refers to

• A system’s behavior (functionality)
• A set of activities that produce some output.
• Think in terms of main processes happening in the system.
In the simplest form, use case is a list of functions for a user;

• Use verbs for naming use cases.

3/3/2025 Software Engineering and Project Management- UNIT II 29

Use Case Diagram
S.No Name Description Notation
1 System Boundary The scope of a system can be represented by a
system boundary

2 Use case A sequences of actions (it must be a verb)

PurchaseTicket

3 Actor User (or) someone / something outside the

system that interacts with the system (it must
be a noun)

4 Association It corresponds to a sequence of actions

between the actor and use case

5 Generalization Inheritance relationship between model

elements of same type
3/3/2025 Software Engineering and Project Management- UNIT II 30
Use Case Diagram
S.No Name Description Notation
6 Include It specifies how the behavior of the inclusion <<include>>
use case is inserted into the behavior defined
for the base use case

7 Extend How the behavior of the extension use case <<extend>>

can be inserted into the behavior defined for
the base use case
9 Note Note is generally used to write comment in use
case diagram

3/3/2025 Software Engineering and Project Management- UNIT II 31

Actors

3/3/2025 Software Engineering and Project Management- UNIT II 32

Example 2: Use case Diagram for a dictionary system

• In this system, the user first login to the system with user name and password. user
name of every user is unique.
• The user enters the word to the system for finding meaning of the word.
• The system searches the meaning for the given word.
• If the word is available on the database then the system retrieve and display the
meaning for the word otherwise it show the message box that contains please enter
correct word.

3/3/2025 Software Engineering and Project Management- UNIT II 33

3/3/2025 Software Engineering and Project Management- UNIT II 34
Use of Extend stereotype between Use Cases
• Extend –

• linking an optional use case to a standard use case.

• Example: Register Course (standard use case) may have

• Register for Special Class (extend use case).

• Standard use case can execute without the extend case.

• 🡪 loose coupling

3/3/2025 Software Engineering and Project Management- UNIT II 35

• University Registration System

3/3/2025 Careful: Arrows between Use and

Software Engineering Cases
Projectare NOT data
Management- UNIT II flows! 36
Use of Include stereotype between Use Cases
• Include stereotype –
a standard case linked to an mandatory use case.
Example: to Authorize Car Loan (standard use case), a clerk must
run Check Client’s Credit History (include use case).

🡪 tight coupling

• Standard use case can NOT execute without the include case.

3/3/2025 Software Engineering and Project Management- UNIT II 37

Extend Relation between Use Cases
• Credit Card Processing

3/3/2025 Careful: Arrows between Use and

Software Engineering Cases
Projectare NOT data
Management- UNIT II flows! 38
Extend and Include(Stereotype)

3/3/2025 Software Engineering and Project Management- UNIT II 39

Use Case Example
• Login:
– Captcha
– Password
– Answer Secret Questions
• Log out

3/3/2025 Software Engineering and Project Management- UNIT II 40

Example : Login

3/3/2025 Software Engineering and Project Management- UNIT II 41

Use Case Diagram for Website Use Case
• Consider the User and Webmaster
• User can login, browse and search document.
– Download is also possible
– User can view event only if he is logged in
• Webmaster is responsible for adding user, uploading documents and
posting events .
– Uploaded documents have to be put in folders
– When a User is added , the Company is also added

3/3/2025 Software Engineering and Project Management- UNIT II 42

Use Case Diagram for Website Use Case

3/3/2025 Software Engineering and Project Management- UNIT II 43

Interaction diagram
• Interaction diagrams
• Sequence Diagram:
• Dynamic behavior of a set of objects arranged in time sequence, new objects added to
the right
• Good for real-time specifications and complex scenarios
• Derived from use case scenario
• Collaboration/Communication Diagram :
• Shows the relationship among objects. Does not show time
• Objects are arranged in a graph or network format

3/3/2025 44
UML Sequence Diagrams
• Used during requirements analysis
– To refine use case descriptions
– to find additional objects (“participating objects”)
• Used during system design
– to refine subsystem interfaces
• Classes are represented by columns
• Messages are represented by arrows
• Activations are represented by narrow rectangles
• Lifelines are represented by dashed lines

3/3/2025 Software Engineering and Project Management- UNIT II 45

UML Sequence Diagrams
• Sequence diagrams model the dynamic aspects of a software system
• The emphasis is on the “sequence” of messages rather than relationship
between objects
• Sequence diagrams provide more detail and show the messages
exchanged among a set of objects over time.
• The main purpose of this diagram is to represent how different
business object interacts

3/3/2025 Software Engineering and Project Management- UNIT II 46

• Func: Issue a book(use case diagram)
• Student get the book
• Librarian gives the book
• Student Logs in
• Request for book
• Librarian will check availabilty
• Librarian will chk autheniticity of student
• Constraint(how many books he has already issued)

3/3/2025 47
Importance of Sequence Diagrams
• Depict object interactions in a given scenario identified for a given
Use Case
• Specify the messages passed between objects using horizontal
arrows including messages to/from external actors
• Time increases from Top to bottom
• Sequence diagrams are good at showing which objects communicate
with which other objects and what messages trigger those
communications.
• Sequence diagrams are not intended for showing complex procedural
logic..

3/3/2025 48
Sequence Diagram of sale scenario

P r o c e s s S a le S c e n a r io
: C a s h ie r :S y s te m

m a k e N e w S a le
S im p le c a s h - o n ly P r o c e s s S a le s c e n a r io :
lo o p [ m o r e it e m s ]
1 . C u s t o m e r a r r iv e s a t a P O S c h e c k o u t e n t e r I t e m ( it e m I D , q u a n t it y )
w it h g o o d s a n d / o r s e r v ic e s t o p u r c h a s e .
2 . C a s h ie r s t a r t s a n e w s a le .
3 . C a s h ie r e n t e r s it e m id e n t if ie r . d e s c r ip t io n , t o t a l
4 . S y s t e m r e c o r d s s a le lin e it e m a n d
p r e s e n t s it e m d e s c r ip t io n , p r ic e , a n d
r u n n in g t o t a l.
C a s h ie r r e p e a t s s t e p s 3 - 4 u n t il in d ic a t e s
done. e n d S a le
5 . S y s t e m p r e s e n t s t o t a l w it h t a x e s
c a lc u la t e d .
6 . C a s h ie r t e lls C u s t o m e r t h e t o t a l, a n d t o t a l w it h t a x e s
a s k s fo r p a y m e n t.
7 . C u s t o m e r p a y s a n d S y s t e m h a n d le s
p a y m e n t. m a k e P a y m e n t(a m o u n t)
...

c h a n g e d u e , r e c e ip t

3/3/2025 49
UML Sequence Diagrams
S.No Name Description Notation

1 Class Roles or Class roles describe the way an

Participants object will behave in context

2 Activation or Activation boxes represent the

Execution time an object needs to
Occurrence/ complete a task.
Scope

3 Diagram Boundry

3/3/2025 Software Engineering and Project Management- UNIT II 50

S.No Name Description Notation

3 Messages Messages are arrows that

represent communication
between objects.

4 Lifelines Lifelines represent either

roles or object instances that
participate in the sequence
being modeled.

3/3/2025 Software Engineering and Project Management- UNIT II 51

UML Sequence Diagrams- Types of Messages in Sequence Diagrams
S.No Name Description Notation
1 Synchronous Message A synchronous message requires a
response before the interaction can
continue.
2 Asynchronous Message Asynchronous messages don't need a
reply for interaction to continue.

3 Reply or Return Message A reply message is drawn with a dotted

line and an open arrowhead pointing
back to the original lifeline.

4 Self Message A message an object sends to itself,

usually shown as a U shaped arrow
pointing back to itself.

3/3/2025 Software Engineering and Project Management- UNIT II 52

Drawing a Sequence Diagram

3/3/2025 Software Engineering and Project Management- UNIT II 53

3/3/2025 Software Engineering and Project Management- UNIT II 54
Sequence Diagram Lifelines
• A lifeline represents an individual participant in a sequence diagram. A
lifeline will usually have a rectangle containing its object name.
• If its name is self then that indicates
that the lifeline represents the
classifier which owns the
Sequence diagram..

3/3/2025 Software Engineering and Project Management- UNIT II 55

Sequence Diagram Messages
• Messages are displayed as arrows. Messages can be complete, lost or found;
synchronous or asynchronous; call or signal.
• In the following diagram, the first message is a synchronous message (denoted by
the solid arrowhead) complete with an implicit
return message; the
• second message is asynchronous
(denoted by line arrowhead) and the
• third is the asynchronous return message
(denoted by the dashed line).

3/3/2025 Software Engineering and Project Management- UNIT II 56

Sequence Diagram Execution Occurrence
• A thin rectangle running down the lifeline denotes the execution
occurrence or activation of a focus of control.
• In the previous diagram, there are three execution occurrences. The
first is the source object sending two messages and receiving two
replies;
• The second is the target object receiving a synchronous message and
returning a reply; and the third is the target object receiving an
asynchronous message and returning a reply.

3/3/2025 Software Engineering and Project Management- UNIT II 57

Sequence Diagram Self Message
• A self message can represent a recursive call of an operation, or one
method calling another method belonging to the same object.
• It is shown as creating a
nested focus of control in
the lifeline’s execution
occurrence.

3/3/2025 Software Engineering and Project Management- UNIT II 58

Sequence Diagram Lost and Found Messages

• Lost messages are those that are either sent but do not arrive at the
intended recipient, or which go to a recipient not shown on the current
diagram. Found messages are those that arrive from an unknown
sender, or from a sender not shown on the current diagram.
• They are denoted going
to or coming from an
endpoint element.

3/3/2025 Software Engineering and Project Management- UNIT II 59

Diff types of messages in Sequence diagram
• Synchronous msg
• Asynchronous msg
• Lost
• Found msg
• Return
• Self msg
• Create msg
• Destroy msg

3/3/2025 Software Engineering and Project Management- UNIT II 60

Creation of instances :

Typically we use the language independent create

message:

3/3/2025 Software Engineering and Project Management- UNIT II 61

Object Lifelines and Object Destruction

We may show the explicit destruction of an

object

3/3/2025 Software Engineering and Project Management- UNIT II 62

Sequence Diagram Combined Fragments
• A combined fragment is one or more processing sequence enclosed in a
frame and executed under specific named circumstances.
• They are also known as Frames in UML Sequence Diagrams
• It allows the visualization of complex algorithms, sequence diagrams
support the notion of frames

3/3/2025 Software Engineering and Project Management- UNIT II 63

Sequence Diagram Example

3/3/2025 Software Engineering and Project Management- UNIT II 64

Typical frame operators are:

Interaction Semantics
Operator
alt Alternative fragment for mutual exclusion conditional logic
expressed in the guards.
loop Loop fragment while guard is true. Can also write loop(n) to
indicate looping n times.
opt Optional fragment that executes if guard is true.

par Parallel fragments that execute in parallel.

region Critical region within which only one thread can run.

3/3/2025 Software Engineering and Project Management- UNIT II 65

Interaction operators
• Alternative (denoted “alt”) models if…then…else constructs.
• Option (denoted “opt”) models switch constructs.
• Break models an alternative sequence of events that is processed
instead of the whole of the rest of the diagram.
• Parallel (denoted “par”) models concurrent processing.
• Negative (denoted “neg”) encloses an invalid series of messages.
• Critical encloses a critical section.
• Consider fragment is in effect the opposite of the ignore fragment: any
message not included in the consider fragment can be ignored

3/3/2025 Software Engineering and Project Management- UNIT II 66

• An interaction constraint is a constraint used in
interactions - a Boolean expression that guards an
operand in a combined fragment.
• An interaction constraint is shown in square brackets
covering the lifeline where the first event occurrence
will occur, positioned above that event, in the
containing interaction or interaction operand.
• UML 2.4 often refers to interaction constraint as
a guard.

3/3/2025 Software Engineering and Project Management- UNIT II 67

Alternative
• The interaction operator alt means that the combined
fragment represents a choice or alternatives of behavior.
• At most one of the operands will be chosen.
• The chosen operand must have an explicit or implicit
guard expression that evaluates to true at this point in the
interaction.
• An implicit true guard is implied if the operand has no
guard.
• An operand guarded by else means a guard that is the
negation of the disjunction of all other guards.
3/3/2025 Software Engineering and Project Management- UNIT II 68
Call accept() if balance > 0, call reject() otherwise.

3/3/2025 Software Engineering and Project Management- UNIT II 69

Option
• The interaction operator opt means that the combined fragment
represents a choice of behaviour where either the (sole) operand
happens or nothing happens.
• An option is semantically equivalent to an alternative combined
fragment where there is one operand with non-empty content and the
second operand is empty.

3/3/2025 Software Engineering and Project Management- UNIT II 70

Post comments if there were no errors.

3/3/2025 Software Engineering and Project Management- UNIT II 71

Loop
• The interaction operator loop means that the combined fragment
represents a loop.
• The loop operand will be repeated a number of times. The loop
construct represents a recursive application of the seq operator where
the loop operand is sequenced after the result of earlier iterations.
• Loop could be controlled by either or both iteration bounds and a
guard.
• Loop operand could have iteration bounds which may include a lower
and an upper number of iterations of the loop.
• If loop has no bounds specified, it means potentially infinite loop with
zero as lower bound and infinite upper bound.

3/3/2025 Software Engineering and Project Management- UNIT II 72

3/3/2025 Software Engineering and Project Management- UNIT II
73
Sequence Diagram Example

3/3/2025 Software Engineering and Project Management- UNIT II 74

Break
• The interaction operator break represents
a breaking or exceptional scenario that is
performed instead of the remainder of the
enclosing interaction fragment.
• A break operator with a guard is chosen
when the guard is true.
• When the guard of the break operand is
false, the break operand is ignored and
the rest of the enclosing interaction
fragment proceeds.
3/3/2025 Software Engineering and Project Management- UNIT II 75
Parallel
• The interaction operator par defines
potentially parallel execution of
behaviour of the operands of the
combined fragment.
• Different operands can be interleaved
in any way as long as the ordering
imposed by each operand is
preserved.

3/3/2025 Software Engineering and Project Management- UNIT II 76

Strict sequencing
• The interaction operator strict requires a
strict sequencing (order) of the operands
on the first level within the combined
fragment.
• Operands of lower levels within the
contained combined fragment will not
directly be compared with other
occurrence specifications of the enclosing
combined fragment.
Search Google, Bing and Yahoo in the strict
sequential order.

3/3/2025 Software Engineering and Project Management- UNIT II 77

Weak Sequencing
• The interaction operator seq means that the combined
fragment represents a weak sequencing between the
behaviors of the operands.
• The ordering of occurrence specifications within each
of the operands is maintained.
• Occurrence specifications on different lifelines from
different operands may come in any order.
• Occurrence specifications on the same lifeline from
different operands are ordered such that an occurrence
specification of the first operand comes before that of
the second operand. Search Google possibly parallel with
Bing and Yahoo, but search Bing
before Yahoo.
3/3/2025 Software Engineering and Project Management- UNIT II 78
Critical
The interaction operator critical defines
that the combined fragment represents
a critical region.

Add() or remove() could be called in parallel,

but each one should run as a critical region.

3/3/2025 Software Engineering and Project Management- UNIT II 79

Rules of Sequence Diagrams

3/3/2025 Software Engineering and Project Management- UNIT II 80

3/3/2025 Software Engineering and Project Management- UNIT II 81
3/3/2025 Software Engineering and Project Management- UNIT II 82
Specifying Timing Requirements

3/3/2025 Software Engineering and Project Management- UNIT II 83

Vending Machine System Sequence Diagram for
Deposit Money Use Case

3/3/2025 Software Engineering and Project Management- UNIT II 84

System Sequence Diagram
for Make Selection Use Case

3/3/2025 Software Engineering and Project Management- UNIT II 85

Order System

3/3/2025 Software Engineering and Project Management- UNIT II 86

Timing
diagrams
• UML 2 Timing diagrams shows the behavior of the objects in a given period of time.
Timing diagram is a special form of a sequence diagram.

• The differences between timing diagram and sequence diagram are that the axes are
reversed so that the time are increase from left to right and the lifelines are shown in
separate compartments arranged vertically.

• Timing diagrams focus on conditions changing within and among lifelines along a
linear time axis.

3/3/20
87
25
Software Engineering and Project Management- UNIT II
Timing diagram
• The timing diagram
focusing attention
on time of occurrence of
events causing changes in
the modeled conditions
of the Lifelines.

3/3/2025 Software Engineering and Project Management- UNIT II 88

Timing
diagrams

3/3/20
89
25
Software Engineering and Project Management- UNIT II
Interaction overview diagram
• Interaction overview diagrams focuses on the overview of the flow of
control of the interactions.
• It is a variant of the Activity Diagram where the nodes are the
interactions or interaction occurrences.
• It describes the interactions where messages and lifelines are hidden.

3/3/2025 Software Engineering and Project Management- UNIT II 90

Interaction overview diagram
• The Interaction EstablishAccess
occurs first with argument"Illegal PIN"
followed by an interaction with the
message CardOut which is shown in an
inline Interaction.
• Then there is an alternative as we
find a decision node with an
InteractionConstraint on one of the
branches.
• Along that control flow we find
another inline Interaction and an
InteractionUse in the sequence.

3/3/2025 Software Engineering and Project Management- UNIT II 91

Interaction overview diagram- Scheduling
System

3/3/2025 Software Engineering and Project Management- UNIT II 92

Interaction overview diagram

3/3/2025 93
Software Engineering and Project Management- UNIT II
Interaction overview diagram

3/3/2025 Software Engineering and Project Management- UNIT II 94

Collaboration diagrams
• UML Collaboration diagrams used to model the dynamic.
• When compare to Sequence Diagram, the Collaboration Diagram is more
focused on showing the collaboration of objects rather than the time
sequence.
• Components of the collaboration process include a sender, encoding of a
message, selecting of a channel of collaboration, receipt of the message by
the receiver and decoding of the message.
• It show the network and sequence of messages or Collaboration between
objects at run-time during a collaboration instance

3/3/2025 Software Engineering and Project Management- UNIT II 95

Collaboration Diagrams
• Collaboration diagrams contain
– Classes
– Associations
– Message exchanges within a collaboration

3/3/2025 Software Engineering and Project Management- UNIT II 96

Collaboration Diagrams
• Link : A link is a connection path between two objects, it indicates
some form of navigation and visibility between the objects. A link is an
instance of an association.
• Note that multiple messages, and messages both ways can be
exchanged along the same link.

3/3/2025 Software Engineering and Project Management- UNIT II 97

Collaboration Diagrams
• Messages : each message between objects is represented with a
message expression and a small arrow indicating the direction of the
message. A sequence number is added to show the sequential order of
messages.

3/3/2025 Software Engineering and Project Management- UNIT II 98

Process Order Control Collaboration diagram

3/3/2025 Software Engineering and Project Management- UNIT II 99

Sequence Diagrams vs Collaboration
Diagrams

3/3/2025 Software Engineering and Project Management- UNIT II 100

Sequence Diagrams vs Collaboration
Diagrams

3/3/2025 Software Engineering and Project Management- UNIT II 101

Sequence Diagrams vs Collaboration Diagrams
• Sequence diagrams :
– Strength: clearly show sequence or time ordering of events, simple notation
– Weakness: forced to extend to the right when adding new objects
• Collaboration diagrams :
– Strength: space economical flexibility to add new objects in two dimensions,
better to illustrate complex branching, iteration and concurrent behavior
– Weakness: difficult to see sequence of messages, more complex notation

3/3/2025 Software Engineering and Project Management- UNIT II 102

Collaboration vs. Sequence Diagrams

3/3/2025 Software Engineering and Project Management- UNIT II 103

UML
• UML diagrams
– Static modeling
(Structure Diagrams)
– Dynamic modeling
(Behavior Diagrams)

Software Engineering and Project Management- UNIT II 104

3/3/2025