UML DeploymentDiagramsReference
UML DeploymentDiagramsReference
Notation Description
Artifact
An artifact is a classifier that represents some physical entity, a piece of information that is used or is
produced by a software development process, or by deployment and operation of a system. A particular
instance (or "copy") of an artifact is deployed to a node instance.
Artifact is presented using an ordinary class rectangle with the keyword «artifact». Examples in UML
Artifact web-app.war specification also show document icon in upper right corner.
The UML Standard Profile defines several standard stereotypes that apply to artifacts:
Associations of Artifacts
Artifacts can be involved in associations to other artifacts, e.g. composition associations. For
instance, a deployment descriptor artifact for a component may be contained within the artifact that
manifests that component. In that way, the component and its descriptor are deployed to a node
instance as one artifact instance.
Manifestation
Manifestation is an abstraction relationship which represents the concrete physical rendering of one
or more model elements by an artifact or utilization of the model elements in the construction or
generation of the artifact. Since UML 2.0 artifacts can manifest any packageable elements, not just
components.
Manifestation between artifact and packageable element is notated in the same way as an
abstraction dependency, i.e. as a general dashed line with an open arrow head directed from artifact
to packageable element (e.g. component or package) and labeled with the keyword «manifest».
In UML 1.x, the concept of manifestation was referred to as implementation and was annotated as
«implement».
Node
Node is a deployment target which represents computational resource upon which artifacts may be
deployed for execution.
Hierarchical Node
Nodes may have an internal structure defined in terms of parts and connectors associated with them
for advanced modeling applications. Parts of node could be only of type node.
Hierarchical nodes (i.e., nodes within nodes) can be modeled using composite associations, or by
defining an internal structure for advanced modeling applications.
Execution environments can be nested (e.g., a database execution environment may be nested in an
operating system execution environment).
Device
A device is a subclass of node which represents a physical computational resource with processing
capability upon which artifacts may be deployed for execution.
Device is rendered as a node (perspective, 3-dimensional view of a cube) annotated with keyword
«device».
UML provides no standard stereotypes for devices. Examples of non-normative stereotypes for devices
are:
«application server»
«client workstation»
«mobile device»
«embedded device»
Profiles, stereotypes, and tagged values could be used to provide custom icons and properties for
the devices.
Computer stereotype with tags applied to Device
class.
Execution Environment
An execution environment is a (software) node that offers an execution environment for specific types
of components that are deployed on it in the form of executable artifacts.
UML provides no other standard stereotypes for execution environments. Examples of reasonable non-
normative stereotypes are:
«OS»
«workflow engine»
«database system»
«J2EE container»
Linux Operating System Execution Environment «web server»
«web browser»
Communication Path
A communication path is association between two deployment targets, through which they are able
to exchange signals and messages.
When deployment targets are some physical devices, communication path will typically represent a
physical connection or media between the nodes.
Gigabit Ethernet as communication path between
application and database servers.
When deployment targets are execution environments, communication path will typically represent
some protocol.
Deployment
Deployment could be shown as a dependency that is drawn from the artifact (supplier) to the
deployment target (client) and is labeled with «deploy». Note, that dependency usually points from the
client to the supplier, i.e. in the direction opposite to what is recommended by UML 2.4 for deployment.
J2EE web application archive portfolio.war deployed On the other hand, UML specification allows to change direction for a dependency based on user's
on Apache Tomcat JSP server. stipulations.
At the "instance level" instances of artifacts could be deployed to specific instances of the deployment
target. The underlining of the name of artifact instance may be omitted.
Deployment could also be shown using textual list of deployed artifacts within a deployment target.
Deployment could be shown in a rectangular frame around the diagram with deployment name in a
compartment in the upper left corner. The long form name for the diagram heading is deployment and
abbreviated form is dep.
Deployment Specification
A deployment specification at specification level is graphically displayed as a classifier rectangle
with optional deployment properties in a compartment.
The ejb-jar.xml deployment specification
Deployment descriptor is rendered as a classifier rectangle with the name underlined and with
deployment properties having specific values in a compartment.
Dependency
A deployment specification could be displayed as a classifier rectangle attached to a component
artifact using a regular dependency arrow pointing to deployed artifact.
Association
Note, UML 2.4 specification shows this association as a dashed line (while association is normally
displayed as solid line.)
The ejb-jar.xml deployment specification attached to
deployment.
Noticed a spelling error? Select the text using the mouse and press Ctrl + Enter.
Follow @uml_diagrams
Like 2.4K Share by Kirill Fakhroutdinov
This document describes UML versions up to UML 2.5 and is based on the corresponding OMG™ Unified Modeling Language™ (OMG UML®)
specifications. UML diagrams were created in Microsoft® Visio® 2007-2016 using UML 2.x Visio Stencils. Lucidchart is a nice, free UML tool that
I recommend for students.
You can send your comments and suggestions to webmaster at [email protected].
Copyright © 2009-2018 uml-diagrams.org. All rights reserved.