Component-based diagrams are essential tools in software engineering, providing a visual

representation of a system’s structure by showcasing its various components and their

interactions.
These diagrams simplify complex systems, making it easier for developers to design,
understand, and communicate the architecture.
The components of a system are arranged and relate to one another is termed a component-
based diagram, or simply a component diagram.
 System components are modular units that offer a set of interfaces and encapsulate
implementation.
 These diagrams illustrate how components are wired together to form larger systems,
detailing their dependencies and interactions.
Component-Based Diagrams are widely used in system design to promote modularity,
enhance understanding of system architecture.

Components of Component-Based Diagram

Component-Based Diagrams in UML comprise several key elements, each serving a distinct
role in illustrating the system’s architecture. Here are the main components and their roles:
1. Component
Represent modular parts of the system that encapsulate functionalities. Components can be
software classes, collections of classes, or subsystems.
 Symbol: Rectangles with the component stereotype («component»).
 Function: Define and encapsulate functionality, ensuring modularity and reusability.
Component
2. Interfaces
Specify a set of operations that a component offers or requires, serving as a contract between
the component and its environment.
 Symbol: Circles (lollipops) for provided interfaces and half-circles (sockets) for
required interfaces.
 Function: Define how components communicate with each other, ensuring that
components can be developed and maintained independently.

Interfaces
3. Relationships
Depict the connections and dependencies between components and interfaces.
 Symbol: Lines and arrows.
o Dependency (dashed arrow): Indicates that one component relies on another.
o Association (solid line): Shows a more permanent relationship between
components.
o Assembly connector: Connects a required interface of one component to a
provided interface of another.
 Function: Visualize how components interact and depend on each other, highlighting
communication paths and potential points of failure.
Relationships
4. Ports
Role: Represent specific interaction points on the boundary of a component where interfaces
are provided or required.
 Symbol: Small squares on the component boundary.
 Function: Allow for more precise specification of interaction points, facilitating
detailed design and implementation.
Ports
5. Artifacts
Represent physical files or data that are deployed on nodes.
 Symbol: Rectangles with the artifact stereotype («artifact»).
 Function: Show how software artifacts, like executables or data files, relate to the
components.

Artifacts
6. Nodes
Represent physical or virtual execution environments where components are deployed.
 Symbol: 3D boxes.
 Function: Provide context for deployment, showing where components reside and
execute within the system’s infrastructure.

Nodes
Steps to Create Component-Based Diagrams
From understanding the system requirements to creating the final design, there are multiple
processes involved in creating a component-based diagram. These steps will assist you in
creating the ideal component-based diagram:
 Step 1: Identify the System Scope and Requirements:
o Understand the system: Get as much information as you can on the
requirements, limitations, and functionality of the system.
o Define the boundaries: Determine what parts of the system will be included
in the diagram.
 Step 2: Identify and Define Components:
o List components: Identify all the major components that make up the system.
o Detail functionality: Define the responsibilities and functionalities of each
component.
o Encapsulation: Ensure each component encapsulates a specific set of
functionalities.
 Step 3: Identify Provided and Required Interfaces:
o Provided Interfaces: Determine what services or functionalities each
component provides to other components.
o Required Interfaces: Identify what services or functionalities each
component requires from other components.
o Define Interfaces: Clearly define the operations included in each interface.
 Step 4: Identify Relationships and Dependencies:
o Determine connections: Identify how components are connected and interact
with each other.
o Specify dependencies: Outline the dependencies between components,
including which components rely on others to function.
 Step 5: Identify Artifacts:
o List artifacts: Identify the physical pieces of information (files, documents,
executables) associated with each component.
o Map artifacts: Determine how these artifacts are deployed and used by the
components.
 Step 6: Identify Nodes:
o Execution environments: Identify the physical or virtual nodes where
components will be deployed.
 o Define nodes: Detail the hardware or infrastructure specifications for each
node.
 Step 7: Draw the Diagram:
o Use a UML tool: Make use of any UML software, such as Lucidchart,
Microsoft Visio, or another UML diagramming tool.
o Draw components: Represent each component as a rectangle with the
«component» stereotype.
o Draw interfaces: Use lollipop symbols for provided interfaces and socket
symbols for required interfaces.
o Connect components: Use assembly connectors to link provided interfaces to
required interfaces.
o Add artifacts: Represent artifacts as rectangles with the «artifact» stereotype
and associate them with the appropriate components.
o Draw nodes: Represent nodes as 3D boxes and place the components and
artifacts within these nodes to show deployment.
 Step 8: Review and Refine the Diagram:
o Validate accuracy: Ensure all components, interfaces, and relationships are
accurately represented.
o Seek feedback: Review the diagram with stakeholders or team members to
ensure it meets the system requirements.
o Refine as needed: Make necessary adjustments based on feedback to improve
clarity and accuracy.
Best practices for creating Component Based Diagrams
Several best practices are used while creating component-based diagrams to guarantee that
the system’s architecture is communicated accurately, clearly, and effectively. Here are some
guidelines for best practices:
1. Understand the System:
 Before drawing the design, make sure you fully understand the needs, features,
and limitations of the system.
 Work closely with stakeholders to gather requirements and clarify any
ambiguities.
2. Keep it Simple:
 Aim for simplicity and clarity in the diagram. Avoid unnecessary complexity
that may confuse readers.
 Break down the system into manageable components and focus on
representing the most important aspects of the architecture.
 3. Use Consistent Naming Conventions:
 Use consistent and meaningful names for components, interfaces, artifacts,
and nodes.
 Follow a naming convention that reflects the system’s domain and is
understandable to all stakeholders.
4. Define Clear Interfaces:
 Clearly define the interfaces provided and required by each component.
 Specify the operations and functionalities exposed by each interface in a
concise and understandable manner.
5. Use Stereotypes and Annotations:
 Use UML stereotypes and annotations to provide additional information about
components, interfaces, and relationships.
 For example, use stereotypes like «component», «interface», «artifact», etc., to
denote different elements in the diagram.
Example of Component Based Diagram
This component diagram represents an Online Store system, breaking it down into various
functional components and showing how they interact. Here’s a breakdown of each part:

Example of Component Based Diagram

1. OnlineStore Component: This is the main component encapsulating the entire
system. It includes three internal components: Order, Customer, and Product.
2. Order Component: This component handles order-related operations within the
Online Store. It is connected to:
  The Product component (which likely manages details of products in each
order).
 The Customer component (for associating orders with customers).
 External access points via delegates (marked by <<delegate>> notation),
which indicate that certain internal actions can be routed or passed on to other
parts.
3. Customer Component: This component manages customer-related data and
activities.
 It’s connected to the Order component to handle customer orders.
 The Account component (outside of OnlineStore) is connected
to Customer through a delegate, suggesting that customer-related actions
in OnlineStore might involve account information from another system.
4. Product Component: This component manages product-related functions within the
Online Store.
 It’s linked to the Order component, allowing orders to reference available
products.
5. Account Component: This component is located outside the OnlineStore boundary,
indicating it may be a separate system or module. It connects to Customer through a
dotted line with a delegate, showing that OnlineStore can delegate certain account-
related functions to this external Account component.

Deployment Diagram in Unified Modeling Language(UML)

A Deployment Diagram is a type of Structural UML Diagram that shows the physical
deployment of software components on hardware nodes. It illustrates the mapping of
software components onto the physical resources of a system, such as servers, processors,
storage devices, and network infrastructure.

What is a Deployment Diagram?

A Deployment Diagram shows how the software design turns into the actual physical system
where the software will run. They show where software components are placed on hardware
devices and shows how they connect with each other. This diagram helps visualize how the
software will operate across different devices
Key elements of a Deployment Diagram
Below are the key elements of deployment diagram:
 Nodes: These represent the physical hardware entities where software components are
deployed, such as servers, workstations, routers, etc.
  Components: Represent software modules or artifacts that are deployed onto nodes,
including executable files, libraries, databases, and configuration files.
 Artifacts: Physical files that are placed on nodes represent the actual implementation
of software components. These can include executable files, scripts, databases, and
more.
 Dependencies: These show the relationships or connections between nodes and
components, highlighting communication paths, deployment constraints, and other
dependencies.
 Associations: Show relationships between nodes and components, signifying that a
component is deployed on a particular node, thus mapping software components to
physical nodes.
 Deployment Specification: This outlines the setup and characteristics of nodes and
components, including hardware specifications, software settings, and communication
protocols.
 Communication Paths: Represent channels or connections facilitating
communication between nodes and components and includes network connections,
communication protocols, etc.
Components and Notations in Deployment Diagram
Below are the components and their notations in deployment diagram:
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 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 represents relationships or dependencies between elements, indicating
that one element is related to or dependent on another.
Use Cases of Deployment Diagrams
Below are the use cases of deployment diagrams:
 Deployment diagrams help plan how software systems will be set up on different
devices.
 They help design the hardware needed to support the software. By showing which
software parts go where, they help decide what devices and networks are needed.
  Deployment diagrams make sure each part of the software has enough resources, like
memory or processing power, to run well.
 They show how different parts of the software depend on each other and on the
hardware.
 By seeing how everything is set up, teams can find ways to make the software run
faster and smoother.
Steps for creating a Deployment Diagram
Below are the main steps for creating a deployment diagram:
 Step1: Identify Components: List all software parts and hardware devices that will
be in the deployment diagram.
 Step 2: Understand Relationships: Figure out how these parts connect and work
together.
 Step 3: Gather Requirements: Collect details about hardware, network setups, and
any special rules for deployment.
 Step 4: Draw Nodes and Components: Start by drawing the hardware devices
(nodes) and software parts (components) using standard symbols roughly at first
improvise it and draw the final one.
 Step 5: Connect Nodes and Components: Use lines or arrows to show how nodes
and components are linked.
 Step 6: Add Details: Label everything clearly and include any extra info, like
hardware specs or communication protocols.
 Step 7: Documentation: Write down any important decisions or assumptions made
while creating the diagram.
Deployment Patterns
Deployment patterns are standardized methods for efficiently installing software on hardware
infrastructure. They offer guidance for organizing and deploying software components,
addressing challenges like scalability, reliability and performance.
 Client-Server Deployment: Illustrates the connection between client applications and
server nodes in a client-server architecture.
 Three-Tier Architecture: Shows the distribution of presentation, application logic,
and data storage components across different nodes.
 Microservices Architecture: Depicts how individual microservices are deployed on
separate nodes or containers.
 Containerization: Displays the deployment of different containers on host machines
using technologies like Docker.
 Cloud Deployment: Illustrates the distribution of components across various cloud
services or regions in a cloud environment.
Real-World Examples For Deployment Diagram
Below are the real-world examples for deployment diagram:
Example 1:
Deployement Diagram For Mobile Banking Andorid Services.
In this example, one node represents the client’s Android device. The components represent
the software installed on these devices, with the banking application being the specific
component on the Android device.
 The diagram also shows how the user connects to the banking server through the web.
 This means the user opens the banking app on their Android device, which then talks
to the application server online to carry out tasks like checking account balances or
transferring money.
Overall, the deployment diagram visually illustrates how software components are set up on
hardware nodes and how they interact to provide the necessary functions to the user.