Software Engineering Deployment Diagram.
Software Engineering Deployment Diagram.
EXPERIMENT NO. 8
A.1 AIM: - To draw Deployment Diagram
A.2 Outcome
After successful completion of this experiment students will be able to -
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 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.
2. Nodes
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.
Figure 3 shows various nodes associated with the project management system,
including a desktop client, business-processing server, database server, and printer
node.
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 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.
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 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.
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.
Figure 8 shows how the various components of the project management system
are related:
Figure 9 shows that the User Interface component is deployed on the Desktop
Client node.
Grade:
Package diagram
B.4 Conclusion
Learned the concept of deployment diagram and how to draw one using Star UML