Deployment Diagrams Reference

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 specification also show document icon in upper right corner.

The UML Standard Profile defines several standard stereotypes that apply to artifacts:

Standard stereotypes - subclasses of «file»:

Standard UML 1.x stereotypes that is now obsolete:

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 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 is a deployment target which represents computational resource upon which artifacts may be deployed for execution.

Node is shown as a perspective, 3-dimensional view of a cube.

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 environment is usually part of a general node or «device» which represents the physical hardware environment on which this execution environment resides.

Execution environments can be nested (e.g., a database execution environment may be nested in an operating system execution environment).

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.

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.

Execution environment is notated as a node (perspective, 3-dimensional view of a cube) annotated with the standard stereotype «executionEnvironment».

UML provides no other standard stereotypes for execution environments. Examples of reasonable non-normative stereotypes are:

• «OS»
• «workflow engine»
• «database system»
• «J2EE container»
• «web server»
• «web browser»

A communication path is association between two deployment targets, through which they are able to exchange signals and messages.

Communication path is shown as association, it has no additional notation.

When deployment targets are some physical devices, communication path will typically represent a physical connection or media between the nodes.

When deployment targets are execution environments, communication path will typically represent some protocol.

A deployment is a dependency relationship which describes allocation (deployment) of an artifact to a deployment target.

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. On the other hand, UML specification allows to change direction for a dependency based on user's 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.

Deployed artifacts could be shown contained within a deployment target.

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.

An artifact that reifies or implements deployment specification properties at instance level is a deployment descriptor.

Deployment descriptor is rendered as a classifier rectangle with the name underlined and with deployment properties having specific values in a compartment.

Deployment specification could be associated with the deployment of a component artifact on a node. In this case deployment specification could be shown as a classifier rectangle attached to the deployment.

Note, UML 2.4 specification shows this association as a dashed line (while association is normally displayed as solid line.)