RAGHU ENGINEERING COLLEGE

(Autonomous)

UNIFIED MODELLING LANGUAGE

UNIT-6

By
Mr. V.TATA RAO
Assistant Professor,
Dept of CSE
 CONTENTS:
 Architectural Modeling
 Component
 Deployment
 Component diagrams
 Deployment diagrams.

References:
 https://www.geeksforgeeks.org/unified-modeling-language-uml-introduction/.
 https://www.tutorialspoint.com/uml/uml_modeling_types.htm
 Purpose of Component Diagrams
 Component diagram is a special kind of diagram in UML. The purpose
is also different from all other diagrams discussed so far.
 It does not describe the functionality of the system but it describes the
components used to make those functionalities.
 Thus from that point of view, component diagrams are used to
visualize the physical components in a system.
 These components are libraries, packages, files, etc.
 Component diagrams can also be described as a static implementation
view of a system.
 Static implementation represents the organization of the components
at a particular moment.
 A single component diagram cannot represent the entire system but a
collection of diagrams is used to represent the whole.
 The purpose of the component diagram can be summarized as −
• Visualize the components of a system.
• Construct executables by using forward and reverse engineering.
• Describe the organization and relationships of the components.
 How to Draw a Component Diagram?
 Component diagrams are used to describe the physical artifacts of a
system. This artifact includes files, executables, libraries, etc
 The purpose of this diagram is different. Component diagrams are
used during the implementation phase of an application.
 However, it is prepared well in advance to visualize the
implementation details.
 Initially, the system is designed using different UML diagrams and
then when the artifacts are ready, component diagrams are used to get
an idea of the implementation.
 How to Draw a Component Diagram?
 This diagram is very important as without it the application cannot be
implemented efficiently.
 A well-prepared component diagram is also important for other
aspects such as application performance, maintenance, etc.
 Before drawing a component diagram, the following artifacts are to be
identified clearly −
• Files used in the system.
• Libraries and other artifacts relevant to the application.
• Relationships among the artifacts.
 How to Draw a Component Diagram?
After identifying the artifacts, the following points need to be kept
in mind.
•Use a meaningful name to identify the component for which the
diagram is to be drawn.
•Prepare a mental layout before producing the using tools.
•Use notes for clarifying important points.
Following is a component diagram for order management system.
Here, the artifacts are files. The diagram shows the files in the
application and their relationships. In actual, the component
diagram also contains dlls, libraries, folders, etc.
In the following diagram, four files are identified and their
relationships are produced. Component diagram cannot be
matched directly with other UML diagrams discussed so far as it is
drawn for completely different purpose.
How to Draw a Component Diagram?
 Where to Use Component Diagrams?
We have already described that component diagrams are used to visualize the static
implementation view of a system. Component diagrams are special type of UML
diagrams used for different purposes.
These diagrams show the physical components of a system. To clarify it, we can say
that component diagrams describe the organization of the components in a system.
Organization can be further described as the location of the components in a system.
These components are organized in a special way to meet the system requirements.
As we have already discussed, those components are libraries, files, executables, etc.
Before implementing the application, these components are to be organized. This
component organization is also designed separately as a part of project execution.
Component diagrams are very important from implementation perspective. Thus, the
implementation team of an application should have a proper knowledge of the
component details
Component diagrams can be used to −
•Model the components of a system.
•Model the database schema.
•Model the executables of an application.
•Model the system's source code.
 Component Diagrams
 Component diagrams are used in modeling the physical aspects of
object-oriented systems.
A component diagram shows the organization and dependencies among
a set of components.
Component diagrams are used to model the static implementation view
of a system.
Component diagrams are essentially class diagrams that focus on a
system’s components.
Graphically, a Component diagram is a collection of vertices and arcs.
Component diagrams are used for visualizing, specifying, and
documenting component- based systems and also for constructing
executable systems through forward and reverse engineering.
 Component diagrams commonly contain Components, Interfaces and
Dependency, generalization, association, and realization relationships. It
may also contain notes and constraints.
 THINGS REQUIRED TO DRAW COMPONENT DIAGRAM
Symbol Name Description

An entity required to execute a stereotype

function. A component provides and consumes
behavior through interfaces, as well as through
Component other components. Think of components as a
type of class. In UML 1.0, a component is
Component symbol
modeled as a rectangular block with two smaller
rectangles protruding from the side. In UML 2.0,
a component is modeled as a rectangular block
with a small image of the old component
diagram shape.

Node symbol Represents hardware or software objects, which

are of a higher level than components.
Node
Interface symbol Shows input or materials that a component
either receives or provides. Interfaces can be
represented with textual notes or symbols, such
as the lollipop, socket, and ball-and-socket
shapes.
 THINGS REQUIRED TO DRAW COMPONENT DIAGRAM
Symbol Name Description
Port symbol Specifies a separate interaction point
between the component and the
environment. Ports are symbolized with a
small square.
Package symbol Groups together multiple elements of the
system and is represented by file folders in
Lucidchart. Just as file folders group
Package together multiple sheets, packages can be
drawn around several components.
Note symbol Allows developers to affix a meta-analysis to
the component diagram.
Note Dependency Shows that one part of your system
symbol depends on another. Dependencies are
represented by dashed lines linking one
component (or element) to another.
 Component Diagram
• Structural Diagram
• Component is a physical and
replaceable part of system and
models physical things
• Used to describe the
dependencies between various
software components
 Components in UML could represent

 Logical components (e.g., business components,

process components)

 Physical components (e.g., CORBA components, EJB

components, COM+ and .NET components, WSDL
components, etc.).
 Basic Concepts of Component Diagram

 A component is drawn as a rectangle with optional compartments

stacked vertically. A high-level, abstracted view of a component in
UML can be modeled as:
 A rectangle with the component's name
 A rectangle with the component icon
 A rectangle with the stereotype text and/or icon
 The purpose of the component diagram can be
summarized as
Visualize the components of a system.
Construct executables by using forward and reverse
engineering.
Describe the organization and relationships of the
components.
 Benefits of component diagrams

Component diagrams can help your team:

 Imagine the system’s physical structure.
 Pay attention to the system’s components and how they relate.
 Emphasize the service behavior as it relates to the interface.
 Before drawing a component diagram, the
following artifacts are to be identified clearly −
 Files used in the system.
 Libraries and other artifacts relevant to the application.
 Relationships among the artifacts.
 After identifying the artifacts, the following points need to be
kept in mind.
 Use a meaningful name to identify the component for which
the diagram is to be drawn.
 Prepare a mental layout before producing the using tools.
 Use notes for clarifying important points.
 Component diagrams can be used to

• To model source code.

• To model executable releases.
• To model physical databases.
• To model adaptable systems
 Modeling source code:
• Either by forward or reverse engineering, identify the set of source code files of
interest and model them as components stéréotypes as files.
• For larger systems, use packages to show groups of source code files.
• Consider using tagged values indicating such information as the version number
of the source code file, its author, and the date it was last changed.
• Model the compilation dependencies among these files using dependencies .
 Modeling an executable release:
•Identify the set of components you’d like to model.
•Consider the stereotype of each component in this set.
•For each component in this set, consider its relationship to its neighbors.
Most, often this will involve interfaces that are realized by certain
components and then imported by others.
 Modeling a physical database:
•Identify the classes in your model that represent your logical database
schema.
• Select a strategy for mapping these classes to tables. You have to
consider the physical distribution of your databases.
•To visualize, specify, construct and document your mapping, create a
component diagram that contains components stereotyped as tables.
•Where possible, use tools to help you transform your logical design into
a physical
 Modeling adaptable systems
 Consider the physical distribution of the components that may migrate
from node to node. We can specify the location of a component
instance by marking it with a location tagged value.
 If you want to model the actions that cause a component to migrate,
create a corresponding interaction diagram that contains component
instances. We can illustrate a change of location by drawing the same
instance more than once, but with different values for its location
tagged value.
COMPONENT DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM
 DEPLOYMENT
 The UML provides a graphical representation of node.This
canonical notation permits you to visualize a node apart from any
specific hardware.
 Using stereotype one of the UML’s extensibility mechanisms you
can tailor this notation to represent specific kinds of processors and
devices.
 A node is a physical element that exists at run time and represents a
computational resource,generally having at least some memory and
often processing capability.Graphically a node is rendered as a cube
 Deployment Diagrams
 A deployment diagram is a diagram that shows the configuration of
run time processing nodes and the components that live on them.
 Deployment diagrams are one of the two kinds of diagrams used in
modeling the physical aspects of an object-oriented system.
 used to model the static deployment view of a system (topology of the
hardware)
 A deployment diagram is just a special kind of class diagram, which
focuses on a system’s nodes.
 Graphically, a deployment diagram is a collection of vertices and arcs.
 Deployment diagrams commonly contain Nodes and Dependency &
association relationships. It may also contain notes and constraints.
 Deployment diagrams are important for visualizing, specifying, and
documenting embedded, client/server, and distributed systems and
also for managing executable systems through forward and reverse
engineering.
 Deployment diagrams are used to visualize the topology of the
physical components of a system, where the software components are
deployed.
 Deployment diagrams are used to describe the static deployment view
of a system. Deployment diagrams consist of nodes and their
relationships
The purpose of deployment diagrams can be described as
Visualize the hardware topology of a system.
Describe the hardware components used to deploy software
components.
Describe the runtime processing nodes.
 Deployment diagrams are useful for system engineers. An
efficient deployment diagram is very important as it controls the
following parameters
 Performance
 Scalability
 Maintainability
 Portability
 Before drawing a deployment diagram, the following artifacts
should be identified
 Nodes
 Relationships among nodes
• Following is a sample deployment diagram to provide an idea of the
deployment view of order management system. Here, we have shown
nodes as −
• Monitor
• Modem
• Caching server
• Server
• The application is assumed to be a web-based application, which is
deployed in a clustered environment using server 1, server 2, and
server 3. The user connects to the application using the Internet. The
control flows from the caching server to the clustered environment.
• The following deployment diagram has been drawn considering all
the points mentioned above.
DEPLOYMENT DIAGRAM FOR ORDER MANAGEMENT SYSTEM
 Deployment diagrams can be used
To model the hardware topology of a system.
To model the embedded system.
To model the hardware details for a client/server system.
To model the hardware details of a distributed application.
For Forward and Reverse engineering.
 MODELING AN EMBEDDED SYSTEM
 Identify the devices and nodes that are unique to your system.
 Provide visual clues, especially for unusual devices, by using stereotypes.
 Model the relationships among these processors and devices in a
deployment diagram. Similarly, specify the relationship between
components and nodes.
 As necessary, expand on the intelligent devices by modeling their structure
with a more detailed deployment diagram.
 MODELING A CLIENT/SERVER SYSTEM
 Identify the nodes that represent your system’s client and server processors.
 Highlight those devices that are relevant to the behavior of your system.
 Provide visual cues for these processors and devices via stereotyping.
 Model the topology of these nodes in a deployment diagram.
MODELING A FULLY DISTRIBUTED SYSTEM:
 Identify the system’s devices and processors as for simpler client/server systems.
 If you need to reason about the performance of the system’s network or the impact of
changes to the network, be sure to model these communication devices to the level of detail
sufficient to make assessments.
 Pay close attention to logical groupings of nodes, which you can specify by using packages.
 Model these devices and processors using deployment diagrams.
 If you need to focus on the dynamics of the system, introduce use case diagrams to specify
the kind of behavior you are interested in, and expand on these use cases with interaction
diagrams.
 DEPLOYMENT DIAGRAM ELEMENTS:

A variety of shapes make up deployment diagrams. This list offers an overview of the
basic elements you may encounter, and you can see most of these items illustrated in
the image below.
Artifact: A product developed by the software, symbolized by a rectangle with the
name and the word “artifact” enclosed by double arrows.
Association: A line that indicates a message or other type of communication between
nodes.
Component: A rectangle with two tabs that indicates a software element.
Dependency: A dashed line that ends in an arrow, which indicates that one node or
component is dependent on another.
Interface: A circle that indicates a contractual relationship. Those objects that realize
the interface must complete some sort of obligation.
Node: A hardware or software object, shown by a three-dimensional box.
Node as container: A node that contains another node inside of it—such as in the
example below, where the nodes contain components.
Stereotype: A device contained within the node, presented at the top of the node,
with the name bracketed by double arrows.
DEPLOYMENT DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM
DEPLOYMENT DIAGRAM FOR ATM