0% found this document useful (0 votes)
61 views11 pages

Software Engineering Deployment Diagram.

Uploaded by

shubhamjtanna
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
61 views11 pages

Software Engineering Deployment Diagram.

Uploaded by

shubhamjtanna
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 11

PART A

EXPERIMENT NO. 8
A.1 AIM: - To draw Deployment Diagram

A.2 Outcome
After successful completion of this experiment students will be able to -

1. Practice drawing the deployment diagram using StarUML

A.3 Theroy
This exercise focuses on component diagram, which depict the implementation of a
system.
Component modeling is a specialized type of structural modeling concerned with
modeling the implementation of a system. Using the UML, you can communicate the
implementation of a system using component diagrams. You usually apply
component modeling during design activities to determine how implementation
activities will build the system; that is, to determine the elements of the system on
which implementation activities will focus. Component modeling typically starts after
the design of the system is fairly complete, as determined by your system
development process.
1. Component

A component is a part of the system that exists when the system is executing. For
example, the project management system may be decomposed into the following
components:

A user interface component


Responsible for providing a user interface through which users may interact with
the system
A business-processing component
Responsible for implementing business functionality, including all the project
management functionality provided by the project management system

A data component
For implementing data storage functionality
A security component
Provides various forms of security functionality to the business-processing and
data components, including user authentication and verifying user privileges when
accessing data

You can use the UML to talk about classes of components as well as specific
components of a class. When speaking of a class of components, it's customary to
use the terms component or component class. Thus, while you might think of a
component as a specific thing, in the UML, a component really represents a class
of things. When speaking of a specific component of a class, use the
term component instance.

A component exists during execution time and requires a resource on which to


execute,. In the UML, a component is shown as a rectangle with two small
rectangles protruding from its side. The rectangle is labelled with the name of the
component class.

Figure 1 shows various components associated with the project management


system, including user interface, business-processing, data, and security
components.

Figure 1- Components of the project management system

A component instance is a specific component. For example, specific components


of the project management system include:

A web user interface component instance


Allows users to access the project management system via the Web

A client/server user interface component instance


Allows users to access the project management system in a client/server
environment
A local data component instance
Stores project management data for a specific user or group of users

An enterprise data component instance


Stores project management data for a complete organization

A component instance is shown similar to a component class, but is labelled with


the component instance name followed by a colon followed by the component
class name, with all parts of the name fully underlined. Both names are optional,
and the colon is present only if the component class name is specified.

Figure 2 shows various component instances of the component classes in Figure 1,


including two user interface component instances, named Web and Client Server,
two data component instances, named Local Data and Enterprise Data, a nameless
business processing component instance, and a nameless security component
instance.

Figure 2- Component instances in the project management system

2. Nodes

A node is a resource that is available during execution time. Traditionally, nodes


refer to computers on a network, but in the UML a node may be a computer,
printer, server, Internet, or any other kind of resource available to components.
For example, the project management system may be deployed on the following
nodes:
A desktop client
On which the user interface component executes
A printer
Which the project management system uses to print reports

A business-processing server
On which the business-processing component executes

A database server
On which the data component executes and where project-related information is
stored.

Nodes follow the type-instance dichotomy and applied to classes and objects. You
can use the UML to talk about classes of nodes, as well as specific nodes of a
class. When speaking of a class of nodes, it's customary to use the terms node
or node class. Thus, while you might think of a node as a specific thing, in the
UML, a node really represents a class of nodes. When speaking of a specific
component of a class, use the term node instance.

A node is available during execution time and is a resource on which components


may execute. In the UML, a node is shown as a three-dimensional rectangle
labelled with the node's name.

Figure 3 shows various nodes associated with the project management system,
including a desktop client, business-processing server, database server, and printer
node.

Figure 3- Nodes used by the project management system


A node instance is a specific node. For example, specific nodes used by the
project management system include:

A desktop client node instance


Used by Jonathan to access the project management system

A desktop client node instance


Used by Andy to access the project management system

A group business-processing server node instance


Used by a group of users to manage projects

An enterprise business-processing server node instance


Used by a complete organization to manage projects
A node instance is shown similarly to a node class but labelled with the node
instance name followed by a colon followed by the node class name, all fully
underlined. Both names are optional, and the colon is present only if the node
class name is specified.

Figure 4 shows various node instances of the node classes in Figure 3, including
two desktop client node instances, named Jonathan's Computer and Andy's
Computer, two business-processing node instances, named Group Server
and Enterprise Server, a printer node instance, named Group Printer, and a
database server node instance.

Figure 4- Node instances


3. Dependencies

Figure 1 shows components associated with the project management system, and
Figure 3 shows nodes associated with the project management system, but how
are components related to undifferentiated and differentiated classes, packages,
subsystems, and to other components and nodes? Specialized types of
dependencies called reside, use, and deploy dependencies address these questions.
The next few sections discuss these specialized types of dependencies.

3.1 Reside Dependencies


A reside dependency from a component to any UML element indicates that the
component is a client of the element, which is itself considered a supplier, and that
the element resides in the component. The element may be an undifferentiated or
differentiated class, package, or subsystem. An element may reside in any number
of components, and a component may have any number of elements that reside in
it.

A reside dependency is shown as a dashed arrow from a client component to a


supplier element marked with the reside keyword.

Figure 5 shows that the User Interface and Utility packages reside in
the User Interface component. Because the User Interface package depends on
the Utility package, the User Interface and Utility packages must reside in the
same component; otherwise, the User Interface package would not be able to use
the Utility package.

Figure 5. Reside dependencies for packages

Figure 6 shows that the Business Processing subsystem and Utility package reside
in the Business Processing component. Because the Business
Processing subsystem provides the IBusiness Processing interface, the
Business Processing component also provides the interface. Again, because
the Business Processing subsystem depends on the Utility package,
the Business Processing subsystem and Utility package must reside in the same
component; otherwise, the Business Processing subsystem would not be able to
use the Utility package. Remember, it's perfectly fine for an element to reside in
more than one component. For example, the Utility package resides in both
the User Interface and Business Processing components, and, as you will soon see,
in the Data component.

Figure 6. Reside dependencies for subsystems

Alternatively, an element that resides inside a component may be shown nested


inside the component. Figure 7 shows that the Data subsystem and Utility package
reside in the Data component. The Data subsystem is drawn inside the
Data component, while thereside dependency to Utility is still drawn in the same
manner as in Figures Figure 5 and Figure 6.

Figure 7. Reside dependencies using nesting

Notice that the Utility package resides in all the components in Figures Figure 5,
Figure 6, and Figure 7, because each component described in those figures has a
package that uses the Utility package.

3.2 Use Dependencies


A use dependency from a client component to a supplier component indicates that
the client component uses or depends on the supplier component. A use
dependency from a client component to a supplier component's interface indicates
that the client component uses or depends on the interface provided by the
supplier component. A use dependency is shown as a dashed arrow from a client
component to a supplier component or a supplier component's interface. The
dependency may be marked with the use keyword; however, the keyword is often
omitted because this is the default, and the meaning is evident from how the
dependency is used.

Figure 8 shows how the various components of the project management system
are related:

The User Interface component-


Uses the Security component and the IBusinessProcessing interface provided by
the Business Processing component

The Business Processing component-


Uses the Security component and the IProducible and IConsumable interfaces
provided by the Data component

The Data component-


Uses the Security component

Figure 8- Use dependencies


3.3 Deploy Dependencies
A deploy dependency from a client component to a supplier node indicates that
the client component is deployed on the supplier node.
A deploy dependency is shown as a dashed arrow from a client component to a
supplier node marked with the deploy keyword.

Figure 9 shows that the User Interface component is deployed on the Desktop
Client node.

Figure 9- Deploy dependencies

Figure 10 shows that the Business Processing component is deployed on


the Business-Processing Server node.

Figure 10- Deploy dependencies for a subsystem

Alternatively, a component that is deployed on a node may be shown nested inside


the node. Figure 11 shows that the Data component is deployed on the Database
Server node.

Figure 11- Deploy dependencies using nesting


A.4 Procedure/Algorithm
A.4.1 Task:
1> 1> For the case study given on black board complete deployment model.
PART B
(PART B: TO BE COMPLETED BY STUDENTS)
(Students must submit the soft copy as per the following segments within two hours of the
practicals. The soft copy must be uploaded on Blackboard LMS or emailed to the concerned
Lab in charge Faculties at the end of practical; in case Blackboard is not accessible)

Roll No: E026 Name: Shubham Tanna

Class: Btech CSBS Batch:1

Date of Experiment: Date of Submission:

Grade:
Package diagram

B.4 Conclusion
Learned the concept of deployment diagram and how to draw one using Star UML

You might also like