Collaboration Diagram, Component, Deployment Diagram
Collaboration Diagram, Component, Deployment Diagram
Collaboration diagrams are also known as communication diagrams. They can demonstrate how
objects communicate to execute a specific use case's actions or an aspect of a use case. Designers
can use collaboration diagrams to explain and identify the roles of objects performing a specific
flow of events in a use case. They are the main information source used to establish class roles
and interfaces.
Sequence diagrams and collaboration diagrams display the same details, but simply present it
differently. Within UML the collaboration and sequence diagrams are the two forms of
interaction diagrams. While both styles use relevant and similar data, they present the
information in different ways.
Collaboration diagrams have been used to envision the structural organization and interactions
between objects. At the other hand, sequence diagrams concentrate on the order of messages
moving in between objects. Nonetheless, a single figure is not enough in most situations to
explain a system 's behavior, so both diagrams are necessary.
A component diagram is used to break down a large object-oriented system into the smaller
components, so as to make them more manageable. It models the physical view of a system such
as executables, files, libraries, etc. that resides within the node.
It visualizes the relationships as well as the organization between the components present in the
system. It helps in forming an executable system. A component is a single unit of the system,
which is replaceable and executable. The implementation details of a component are hidden, and
it necessitates an interface to execute a function. It is like a black box whose behavior is
explained by the provided and required interfaces.
a) A component
b) A node
The component diagrams have remarkable importance. It is used to depict the functionality and
behavior of all the components present in the system, unlike other diagrams that are used to
represent the architecture of the system, working of a system, or simply the system itself.
In UML, the component diagram portrays the behavior and organization of components at any
instant of time. The system cannot be visualized by any individual component, but it can be by
the collection of components.
Following are some reasons for the requirement of the component diagram:
The deployment diagram visualizes the physical hardware on which the software will be
deployed. It portrays the static deployment view of a system. It involves the nodes and their
relationships.
It ascertains how software is deployed on the hardware. It maps the software architecture created
in design to the physical system architecture, where the software will be executed as a node.
Since it involves many nodes, the relationship is shown by utilizing communication paths.
They help developers visualize how their software interacts with hardware and other software.
1. A component
2. An artifact
3. An interface
4. A node
Notations in Deployment Diagram
Refers to the symbols, shapes, and conventions used to represent different elements within the
diagram, like:
1. Component
A component represents a modular and reusable part of a system, typically implemented as a
software module, class, or package. It encapsulates its behavior and data and can be deployed
independently.
Typically represented as a rectangle with two smaller rectangles protruding from its sides,
indicating ports for connections. The component’s name is written inside the rectangle.
2
. Artifact
An artifact represents a physical piece of information or data that is used or produced in the
software development process. It can include source code files, executables, documents,
libraries, configuration files, or any other tangible item.
Typically represented as a rectangle with a folded corner, labeled with the artifact’s name.
Artifacts may also include additional information, such as file extensions or versions.
3. Interface
An interface defines a contract specifying the methods or operations that a component must
implement. It represents a point of interaction between different components or subsystems.
Represented as a circle or ellipse labeled with the interface’s name. Interfaces can also
include provided and required interfaces, denoted by “+” and “-” symbols, respectively.
4. Node
A node represents a physical or computational resource, such as a hardware device, server,
workstation, or computing resource, on which software components can be deployed or
executed.
Represented as a box with rounded corners, usually labeled with the node’s name. Nodes can
also include nested nodes to represent hierarchical structures.
5. Communication path
A straight line that represents communication between two device nodes. Dashed lines in
deployment diagrams often signify relationships or dependencies between elements, indicating
that one element is related to or dependent on another.
In this diagram, a node represents the client’s device, which is an Android system. A component
represents the banking application in the device. The user goes through the web to interact with
the banking server and perform the required task.