UNIT -2

Collaboration Diagrams:
A collaboration diagram is a behavioral UML diagram which is also referred to
as a communication diagram. It illustrates how objects or components interact
with each other to achieve specific tasks or scenarios within a system.
Importance of Collaboration Diagrams
Collaboration diagrams is important for understanding communication, design,
analysis, and documentation of the system's architecture and behavior.
• Visualizing Interactions:
o These diagrams offer a clear visual representation of how objects
or components interact within a system.
o This visualization helps stakeholders in understanding the flow of
data and control for easier understanding.
• Understanding System Behavior:
o By showing interactions, collaboration diagrams provide insights
into the system's dynamic behavior during operation.
o Understanding this behavior is important for identifying potential
issues, optimizing performance, and ensuring the system functions
smoothly.
• Facilitating Communication:
o Collaboration diagrams provide an effective communication tools
among team members.
o They facilitate discussions, enabling refinement of the system's
design, architecture, and functionality.
1. Objects/Participants

Objects are represented by rectangles with the object's name at the top.
Each object participating in the interaction is shown as a separate
rectangle in the diagram. Objects are connected by lines to indicate
messages being passed between them.
2. Multiple Objects
Multiple objects are represented by rectangles,each with the object's name
inside, and interactions between them are shown using arrows to indicate
message flows.

3. Actors
They are usually shown at the top or side of the diagram. Actors indicate their
involvement in the interactions with the system's objects or components. They
are connected to objects through messages, showing the communication with
the system.

4. Messages
Messages represent communication between objects. Messages are shown as
arrows between objects, indicating the flow of communication. Each message
may include a label indicating the type of message (e.g., method call, signal).
Messages can be asynchronous (indicated by a dashed arrow)
or synchronous (solid arrow).

5. Self Message
This is a message that an object sends to itself. It represents an action or
behavior that the object performs internally without involving any other objects.
Self-messages are useful for modeling scenarios where an object triggers its
own methods or processes.

6. Links
Links represent associations or relationships between objects. Links are shown
as lines connecting objects, with optional labels to indicate the nature of the
relationship. Links can be uni-directional or bi-directional, depending on the
nature of the association.

7. Return Messages
Return messages represent the return value of a message. They are shown as
dashed arrows with a label indicating the return value. Return messages are
used to indicate that a message has been processed and a response is being sent
back to the calling object.

Sequence Diagram:
A Sequence Diagram in UML (Unified Modeling Language) is used to model
the interactions between objects in a particular sequence. It shows how objects
communicate with each other in a specific order to carry out a process or
functionality.
Key Elements of a Sequence Diagram:
1. Actors: These are external entities interacting with the system (e.g., users
or other systems).
2. Objects/Instances: Represent the entities (typically classes or
components) involved in the interaction.
 3. Lifelines: Vertical dashed lines representing the lifespan of an object
during the interaction.
4. Messages: Arrows showing communication between objects. They
represent method calls or events triggered by other objects.
o Synchronous messages: Represented by a solid arrowhead and
imply that the sender waits for a response.
o Asynchronous messages: Represented by an open arrowhead and
imply the sender does not wait for a response.
5. Activation Bars: Rectangles placed on the lifeline to represent when an
object is active or performing a process.
6. Return Messages: Dotted arrows that show the return of data or control
from a method call.
7. Destruction: A cross at the end of a lifeline indicates that an object is
destroyed (optional).

The above sequence diagram depicts the sequence diagram for an emotion
based music player:
• Firstly the application is opened by the user.
• The device then gets access to the web cam.
• The webcam captures the image of the user.
 • The device uses algorithms to detect the face and predict the mood.
• It then requests database for dictionary of possible moods.
• The mood is retrieved from the database.
• The mood is displayed to the user.
• The music is requested from the database.
• The playlist is generated and finally shown to the user.

Asynchronous Messages (Without Priority & With Priority)

In a sequence diagram, asynchronous messages represent communication
between objects where the sender does not wait for an immediate response
before continuing its execution. Asynchronous messages are typically depicted
with a solid arrow and a dashed line return, which indicates that the sender
continues its execution without waiting for the receiver's reply.
1. Asynchronous Messages (Without Priority)
In this case, the sender sends an asynchronous message to the receiver, and the
sender does not wait for a response. The diagram below shows a simple case
where Object A sends an asynchronous message to Object B:
Object A Object B
| |
|-----> | (Asynchronous Message)
| |
| |<---- (Response or continuation not shown)
| |
• The arrow (----->) represents the asynchronous message sent from
Object A to Object B.
• Object A continues its processing without waiting for Object B’s reply.
If Object B responds, the response would typically be shown later in the
diagram (but in an asynchronous call, the sender doesn't wait for it).
2. Asynchronous Messages (With Priority)
If an asynchronous message has priority, it indicates that the receiver might
need to handle the message more urgently or in some ordered manner. To
indicate priority, you could use annotations or color codes in tools that support
these visual cues, or explicitly mark the priority in the message’s description.
For example:
Object A Object B
| |
|-----> | (High-Priority Asynchronous Message)
| |
| |<---- (Response or continuation not shown)
| |
In a more detailed scenario where priority is explicitly noted, you could mark
the message with a "Priority: High" label.

Callback Mechanism in UML Sequence Diagram

A callback mechanism occurs when a method is called on an object, and that
object then passes control back to the calling object once it has finished
performing its task. This pattern is often used in asynchronous communication
or event-driven programming, where the original caller doesn’t block its
execution and continues doing other tasks.
Key Steps in Callback:
1. Initiating Call: The calling object sends a request or message to the
callee object.
2. Processing: The callee performs its task (often asynchronously or in the
background).
3. Callback: Once the callee finishes processing, it sends a message back to
the calling object, usually in the form of a result or an event.
Example Scenario:
Consider an example of an Order Processing System, where the system sends
an order request to a Payment Gateway, and after processing the payment
asynchronously, the Payment Gateway calls back to inform the system whether
the payment was successful or failed.
UML Representation:
• Objects involved:
o User (Actor)
o Order System (Object)
o Payment Gateway (Object)
• The Order System initiates the payment request to the Payment
Gateway.
• The Payment Gateway processes the payment and calls the Order
System back with a result (success or failure).
Sequence Diagram:
+------------+ +------------------+ +--------------------+
| User | | Order System | | Payment Gateway |
+------------+ +------------------+ +--------------------+
| | |
|----(1) Place Order----->| |
| |----(2) Send Payment------->|
| | |
| | |----(3) Process Payment----->|
| | |<----(4) Payment Result------|
| |<----(5) Process Result-----|
|<----(6) Show Confirmation--| |
+------------+ +------------------+ +--------------------+
• (1): User places an order in the Order System.
 • (2): Order System sends a payment request to the Payment Gateway.
• (3): Payment Gateway processes the payment asynchronously.
• (4): Once processing is complete, Payment Gateway sends a callback
message to the Order System.
• (5): Order System processes the callback result.
• (6): Finally, the Order System sends a confirmation to the User.

Broadcast Messages in UML Sequence Diagram

Broadcast messages are used to represent situations where a message is sent to
multiple recipients simultaneously (or multiple objects respond to a single
message). In the context of sequence diagrams, broadcasting is typically
depicted as sending a message to multiple objects or instances that listen for that
message.
In a broadcast mechanism:
• A single object (the broadcasting object) sends the same message to
multiple receivers (other objects).
• Each receiver processes the message individually.
Example Scenario:
Consider a Notification System, where the system sends a broadcast message
to multiple Subscribers (objects) informing them of a new update.
UML Representation:
• Objects involved:
o Notification System (Object)
o Subscriber 1, Subscriber 2, Subscriber 3 (Objects)
Sequence Diagram:
+--------------------+ +---------------------+ +---------------------+ +----
-----------------+
| Notification System| | Subscriber 1 | | Subscriber 2 | |
Subscriber 3 |
+--------------------+ +---------------------+ +---------------------+ +----
-----------------+
| | | |
|----(1) Broadcast Update----->| | |
| | | |
| |<---(2) Receive Update------| |
| | | |
| | |<---(3) Receive Update------|
| | | |
| | | |<---(4) Receive
Update------|
+--------------------+ +---------------------+ +---------------------+ +----
-----------------+
• (1): The Notification System broadcasts a message (e.g., a new update)
to all subscribers.
• (2), (3), (4): Each Subscriber receives the broadcast message and
processes it individually.
In this diagram, the broadcast message is typically represented by a dashed line
or a line with multiple target objects, indicating that the same message is being
sent to multiple recipients.

BEHAVIORAL MODELING-
In UML (Unified Modeling Language), behavioral modeling focuses on how a
system behaves in response to events, user actions, or interactions between
objects. These models help in understanding the dynamic aspects of the system
and represent how various parts of the system cooperate and respond over time.

1. Use Cases and Use Case Diagrams

Use Cases:
A use case represents a system's behavior as seen by an actor (a user or another
system). Use cases define the interaction between the actor and the system to
achieve a specific goal. Each use case describes a functional requirement or a
distinct service that the system provides to the actor.
A Use Case typically includes:
• Actor: An entity (usually a user or another system) that interacts with the
system.
• System: The boundary or scope that represents the functionality being
described.
• Scenario: A specific sequence of steps describing how the actor and the
system interact.
• Preconditions: Conditions that must be true before the use case can
begin.
• Postconditions: The conditions that will be true after the use case
completes.

Use Case Diagram:

A Use Case Diagram shows the relationship between actors and use cases
within the system. It is a high-level view that helps visualize the system’s
functional requirements.
• Actors are drawn outside the system boundary (a rectangle representing
the system).
• Use cases are drawn inside the system boundary as ovals.
• Associations (lines) connect actors to use cases, representing interactions.
Example: Online Shopping System
• Actor: Customer, Admin
• Use Cases:
o Customer: Browse Products, Add to Cart, Checkout, Make
Payment
o Admin: Manage Products, View Orders
Use Case Diagram for Online Shopping System:
+-----------------------------------+
| Online Shopping |
| +---------------------------+ |
| | Browse Products | |
| | Add to Cart | |
| | Checkout | |
| | Make Payment | |
| +---------------------------+ |
+-----------------------------------+
^ ^
| |
Customer Admin
• Customer interacts with use cases like Browse Products and Make
Payment.
• Admin manages the product catalog and views orders.

2. Activity Diagram
An Activity Diagram is used to model the workflow or flow of control
between actions in a system. It shows how an activity (task) progresses from
one step to the next, typically based on some conditions or inputs.
Key Elements:
• Action: Represents a task or operation.
• Activity: A collection of actions.
• Decision Node: A point where control diverges based on conditions (like
an if-else).
• Fork/Join: Used to represent parallel processing (fork splits, join
synchronizes).
• Start and End Nodes: Represent the initiation and termination of the
workflow.
 • Control Flow: Arrows indicating the direction of activity or decision.
Example: Online Payment Process
• Start: User decides to make a payment.
• Decision: Is the payment valid?
o If valid, process payment.
o If invalid, ask the user to correct the information.
• End: Successful or failed payment.
Activity Diagram for Payment Processing:
+-------------------------+
| Start |
+-------------------------+
|
v
+-------------------------+
| User Enters Payment Info |
+-------------------------+
|
v
+-------------------------+
| Validate Payment Info |
+-------------------------+
| |
Valid Invalid
| |
v v
+---------------------+ +-----------------------+
| Process Payment | | Ask for Correct Info |
+---------------------+ +-----------------------+
| |
v v
+---------------------+ +-----------------------+
| Payment Successful | | User Corrects Info |
+---------------------+ +-----------------------+
|
v
+-------------+
| End |
+-------------+

3. State Machine Diagram

A State Machine Diagram (or Statechart Diagram) describes the states that
an object can be in and the transitions between these states based on events or
conditions. This is especially useful for modeling the lifecycle of an object or
system.
Key Elements:
• State: A specific condition during the lifetime of an object.
• Transition: The movement from one state to another, triggered by an
event.
• Event: An occurrence that triggers a transition (e.g., user input, system
action).
• Initial State: The state an object starts in.
• Final State: The state when an object stops or is destroyed.
Example: Order Lifecycle
• States: Pending, Shipped, Delivered
 • Events: Order placed, Order shipped, Order delivered
State Machine Diagram for an Order:
+---------------------+
| [Initial] |
| Order Pending |
+---------------------+
|
v
+---------------------+
| Order Placed |
| (Order Pending) |
+---------------------+
|
v
+---------------------+
| Order Shipped |
+---------------------+
|
v
+---------------------+
| Order Delivered |
+---------------------+
|
v
+---------------------+
| [Final] |
| End of Order |
+---------------------+

• States: The order starts in the Order Pending state, then transitions
through various states (e.g., Order Shipped) based on events.
• Event Triggered Transitions: A "Shipped" event transitions the order to
Shipped, and a "Delivered" event transitions it to the Delivered state.

4. Process and Thread

In the context of UML, processes and threads typically describe the execution
model of the system, especially in concurrent or multi-threaded environments.
• Process: A process is a program in execution that has its own memory
space. It can consist of one or more threads.
• Thread: A thread is the smallest unit of execution within a process. It
shares the same memory space as other threads in the same process.
While UML does not have specific diagrams for processes and threads, these
concepts can be modeled in Activity Diagrams to represent parallel activities
or multiple threads running simultaneously.
Example: Online Chat System with Threads
• Process: The chat server process handles multiple user requests.
• Threads: Each user interaction is handled by a separate thread to manage
multiple concurrent conversations.

5. Event and Signals

In UML, Events and Signals are used to represent asynchronous
communication between objects.
• Event: An occurrence that can trigger actions, transitions, or messages.
• Signal: A type of event that is sent from one object to another, often
asynchronously, to indicate that something has happened.
Example**: Message Event Trigger
• A Signal (like a message) is sent to an object, which may transition to a
different state or perform an action in response.
Example: State Transition Triggered by Signal:
+----------------------+
| Waiting for Payment |
+----------------------+
|
[Signal: PaymentReceived]
v
+----------------------+
| Process Payment |
+----------------------+

6. Time Diagram
A Timing Diagram represents the behavior of an object over time, particularly
useful for real-time systems or time-sensitive interactions. It shows how objects
change their states or how signals are exchanged over time.
Key Elements:
• Lifeline: Represents the object whose state is being modeled.
• State/Value: Changes that occur on the object over time.
• Time Axis: Horizontal axis representing time.
Example**: Timer Triggered Event
+------------------+ +-------------------+ +------------------+
| Object A | | Object B | | Object C |
+------------------+ +-------------------+ +------------------+
| | | | |
---|---|--------------|--------|--------------------|------------------|---
[Event Triggered]

7. Interaction Diagrams
Interaction Diagrams model how objects interact with each other over time.
There are two main types:
• Sequence Diagrams: Focus on the time sequence of messages exchanged
between objects.
• Communication Diagrams: Focus on the relationships between objects
and the messages exchanged.
Sequence Diagram:
Sequence diagrams emphasize the time order of messages between objects. It
represents the interactions by focusing on the sequence of events.
Example: Customer Order Flow
+------------+ +-------------+ +-----------+
| Customer | | OrderSystem | | Database |
+------------+ +-------------+ +-----------+
| | |
|----(1) Order------>| |
| |----(2) Query DB------>|
| | |
| |<---(3) Return Data---|
|<---(4) Confirmation-|

8. Package Diagram
A Package Diagram is used to organize the system into packages or modules.
It helps show dependencies between different parts of the system and their
relationships.
Key Elements:
• Package: A group of related classes or components.
• Dependency: Represents a relationship between two packages.
Example: Library System
+----------------+ +---------------------+
| User Interface | | Business Logic |
| Package | | Package |
+----------------+ +---------------------+
| |
<<depends on>> <<depends on>>
| |
+------------------+ +---------------------+
| Database Package | | Payment Processing |
+------------------+ +---------------------+

User Interface depends on the Business Logic package for core functionality,
while Business Logic depends on the Database and Payment packages.

Architectural Modeling:
Architectural modeling in UML (Unified Modeling Language) focuses on the
structure and organization of a system's components, as well as how these
components are deployed onto hardware. This type of modeling is essential for
understanding how a system is built, how its parts interact, and how the system
is distributed across physical infrastructure.
Key UML diagrams used in architectural modeling are:
1. Component Diagram
 2. Deployment Diagram

Components in Architectural Modeling

A. Definition of a Component:
In the context of UML, a component is a modular part of a system that
encapsulates a set of related functionalities or services. Components can be
considered as software building blocks, designed to interact with other
components via well-defined interfaces. A component typically represents a
physical or logical entity within a system that performs a specific role, such as a
software module, library, or service.
Key Characteristics of Components:
• Encapsulation: A component encapsulates internal functionality and
exposes a defined interface through which it interacts with other
components.
• Interchangeability: Components are often designed to be replaceable,
meaning one component can be substituted by another that offers the
same interface without affecting other components.
• Independence: Components are typically independent and can be
developed, tested, and deployed separately.
• Interface: A component exposes its behavior to other components via
interfaces. These interfaces define the operations and services that a
component can provide.
• Realization: Components "realize" one or more interfaces, meaning they
provide the functionality defined by the interface.
Examples of Components:
• Software components: Modules in a program, web services, APIs,
libraries, etc.
• Hardware components: Servers, databases, network devices, etc.
Types of Components:
 • External Components: Components that interact with external systems or
users.
• Internal Components: Components that provide internal system
functionalities, such as databases, business logic modules, and application
servers.

B. Deployment in Architectural Modeling

Definition of Deployment:
In the context of UML, deployment refers to the physical aspect of the system
architecture. It involves the mapping of software components onto hardware
nodes (physical devices such as computers or servers) and the specification of
runtime relationships between the system's physical and logical parts.
Deployment Modeling:
Deployment models are concerned with how the system’s components are
distributed across the physical infrastructure and how they communicate with
each other. This aspect is crucial for understanding the scalability, performance,
and reliability of the system.
Key Elements of Deployment Modeling:
1. Nodes: Physical or virtual machines (computers, servers, containers)
where software components are deployed.
o A node represents a computing resource with the capability to
execute components.
o Nodes can be physical (e.g., a web server, database server) or
logical (e.g., a virtual machine or container in cloud computing).
2. Artifacts: Actual files, executables, or packages (e.g., .jar files, web
applications, databases) that are deployed onto nodes.
o An artifact is a tangible piece of software that is deployed to and
executed on a node.
3. Communication Paths: The physical or logical connections between
nodes, typically representing network connections or inter-process
communication channels.
 4. Deployment Specifications: Constraints or configurations that affect how
software components are deployed (e.g., performance requirements,
resource limitations).

C. Component Diagram
A Component Diagram is used to model the logical architecture of a system,
showing how different components interact and depend on each other. It focuses
on the software structure, particularly the decomposition of the system into
reusable and interchangeable components.
Key Elements in a Component Diagram:
1. Component: Represents a modular unit of software that encapsulates
specific functionality.
o Example: A "Database Component" that interacts with the
database.
2. Interface: Defines a set of services or operations that a component
provides or requires.
o Example: A "Payment Gateway Interface" that defines how
payment transactions are processed.
3. Port: A specific point through which a component interacts with other
components, typically representing an interaction point for services.
o Example: A "Web Service Port" that allows other components to
interact with a web service.
4. Dependency: Represents how one component relies on another. It is
shown with a dashed arrow indicating that a component depends on the
functionality of another.
o Example: A "Shopping Cart" component that depends on a
"Payment" component to complete purchases.
5. Realization: A relationship where a component provides the behavior
defined by an interface. This is typically denoted with a solid line with a
hollow triangle at the end.
 6. Ports and Connectors: Used to model the interaction between components
and interfaces.
Purpose of Component Diagrams:
• Visualizing modularity: Component diagrams help to break down the
system into smaller, manageable units of functionality, showing the
system’s modular structure.
• Defining components and interfaces: It helps define the components, their
interfaces, and the dependencies between them.
• Understanding interactions: Component diagrams help understand how
various components interact with each other to provide the system’s
overall functionality.
Example of a Component Diagram:
For an Online Banking System:
+-----------------------+
| User Interface |
| (UI Component) |
+-----------------------+
|
v
+-----------------------+ +------------------------+
| Authentication Service |<------>| Database Component |
| (Component) | | (Artifact) |
+-----------------------+ +------------------------+
|
v
+-----------------------+
| Payment Processing |
| (Component) |
+-----------------------+

Components: User Interface, Authentication Service, Payment Processing, and

Database Component.
Dependencies:
• User Interface depends on Authentication Service and Payment
Processing components.
• Authentication Service depends on the Database Component to validate
credentials.

D.Deployment Diagram
A Deployment Diagram is used to model the physical deployment of software
components onto hardware nodes. It shows how software is distributed across
hardware devices and how the components communicate with each other in a
runtime environment.
Key Elements in a Deployment Diagram:
1. Node: A physical or virtual machine that executes software components.
Nodes can represent physical devices (like servers or workstations) or
virtual resources (like cloud instances or containers).
o Example: A "Web Server" node or a "Database Server" node.
2. Component: A software artifact (e.g., an executable file, a web
application) deployed on a node.
o Example: A "Web Application" component that is deployed on a
"Web Server".
3. Artifact: A tangible software package or file that is deployed on a node.
o Example: A .war file (web application archive) deployed on a web
server node.
4. Communication Path: Represents the network or communication
channels between nodes. It shows how nodes exchange data or messages.
 o Example: A communication link between a "Web Server" node and
a "Database Server" node for querying data.
5. Deployment Specification: Constraints or configurations that influence
how software components are deployed onto nodes (e.g., operating
system requirements, load balancing, resource limitations).
Purpose of Deployment Diagrams:
• Visualizing the physical structure: Deployment diagrams illustrate how
software components are physically distributed across hardware, making
it easier to understand system architecture at the deployment level.
• Mapping logical components to physical infrastructure: It helps relate
software components to physical resources, providing insights into the
hardware requirements and resource utilization.
• Understanding performance and scalability: Helps in planning how the
system will scale across multiple machines and how components will
communicate over a network.
Example of a Deployment Diagram:
For an E-commerce Application:
+-------------------+ +---------------------+ +--------------------+
| Web Server | | Application Server | | Database Server |
| (Node) | | (Node) | | (Node) |
|-------------------| |---------------------| |--------------------|
| [Web App] | | [Order Processing] | | [MySQL Database] |
+-------------------+ +---------------------+ +--------------------+
| | |
+-------------------------+-----------------------------+
|
+-----------------------+
| Payment Gateway |
| (Artifact) |
 +-----------------------+

Nodes:
• Web Server node: Hosts the Web App.
• Application Server node: Hosts the Order Processing component.
• Database Server node: Hosts the MySQL Database.
• Payment Gateway is deployed on a different physical or virtual node.
Communication Paths:
• Web Server communicates with the Application Server to handle user
requests and process orders.
• Application Server communicates with the Database Server to retrieve
order data and update inventory.