Overview:

Deployment diagrams are used to visualize the topology of the physical components of a system where the
software components are deployed.
So deployment diagrams are used to describe the static deployment view of a system. Deployment diagrams
consist of nodes and their relationships.

Purpose:
The name Deployment itself describes the purpose of the diagram. Deployment diagrams are used for
describing the hardware components where software components are deployed. Component diagrams and
deployment diagrams are closely related.
Component diagrams are used to describe the components and deployment diagrams shows how they are
deployed in hardware.
UML is mainly designed to focus on software artifacts of a system. But these two diagrams are special
diagrams used to focus on software components and hardware components.
So most of the UML diagrams are used to handle logical components but deployment diagrams are made to
focus on hardware topology of a system. Deployment diagrams are used by the system engineers.
The purpose of deployment diagrams can be described as:

Visualize hardware topology of a system.

Describe the hardware components used to deploy software components.

Describe runtime processing nodes.

How to draw Deployment Diagram?

Deployment diagram represents the deployment view of a system. It is related to the component diagram.
Because the components are deployed using the deployment diagrams. A deployment diagram consists of
nodes. Nodes are nothing but physical hardwares used to deploy the application.
Deployment diagrams are useful for system engineers. An efficient deployment diagram is very important
because it controls the following parameters

Performance

Scalability

Maintainability

Portability

So before drawing a deployment diagram the following artifacts should be identified:

Nodes

Relationships among nodes

The following deployment diagram is a sample to give 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 is connecting to the application using internet. The control is
flowing from the caching server to the clustered environment.
So the following deployment diagram has been drawn considering all the points mentioned above:

Where to use Deployment Diagrams?

Deployment diagrams are mainly used by system engineers. These diagrams are used to describe the
physical components (hardwares), their distribution and association.

To clarify it in details we can visualize deployment diagrams as the hardware components/nodes on which
software components reside.
Software applications are developed to model complex business processes. Only efficient software
applications are not sufficient to meet business requirements. Business requirements can be described as to
support increasing number of users, quick response time etc.
To meet these types of requirements hardware components should be designed efficiently and in a cost
effective way.
Now a day's software applications are very complex in nature. Software applications can be stand alone,
web based, distributed, mainframe based and many more. So it is very important to design the hardware
components efficiently.
So the usage of deployment diagrams can be described as follows:
To model the hardware topology of a system.
To model embedded system.
To model hardware details for a client/server system.
To model hardware details of a distributed application.
Forward and reverse engineering.

Overview:
Deployment diagrams are used to visualize the topology of the physical components of a system where the
software components are deployed.
So deployment diagrams are used to describe the static deployment view of a system. Deployment diagrams
consist of nodes and their relationships.

Purpose:
The name Deployment itself describes the purpose of the diagram. Deployment diagrams are used for
describing the hardware components where software components are deployed. Component diagrams and
deployment diagrams are closely related.
Component diagrams are used to describe the components and deployment diagrams shows how they are
deployed in hardware.
UML is mainly designed to focus on software artifacts of a system. But these two diagrams are special
diagrams used to focus on software components and hardware components.
So most of the UML diagrams are used to handle logical components but deployment diagrams are made to
focus on hardware topology of a system. Deployment diagrams are used by the system engineers.
The purpose of deployment diagrams can be described as:

Visualize hardware topology of a system.

Describe the hardware components used to deploy software components.

Describe runtime processing nodes.

How to draw Deployment Diagram?

Deployment diagram represents the deployment view of a system. It is related to the component diagram.
Because the components are deployed using the deployment diagrams. A deployment diagram consists of
nodes. Nodes are nothing but physical hardwares used to deploy the application.
Deployment diagrams are useful for system engineers. An efficient deployment diagram is very important
because it controls the following parameters

Performance

Scalability

Maintainability

Portability

So before drawing a deployment diagram the following artifacts should be identified:

Nodes

Relationships among nodes

The following deployment diagram is a sample to give 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 is connecting to the application using internet. The control is
flowing from the caching server to the clustered environment.
So the following deployment diagram has been drawn considering all the points mentioned above:

Where to use Deployment Diagrams?

Deployment diagrams are mainly used by system engineers. These diagrams are used to describe the
physical components (hardwares), their distribution and association.
To clarify it in details we can visualize deployment diagrams as the hardware components/nodes on which
software components reside.
Software applications are developed to model complex business processes. Only efficient software
applications are not sufficient to meet business requirements. Business requirements can be described as to
support increasing number of users, quick response time etc.
To meet these types of requirements hardware components should be designed efficiently and in a cost
effective way.
Now a day's software applications are very complex in nature. Software applications can be stand alone,
web based, distributed, mainframe based and many more. So it is very important to design the hardware
components efficiently.
So the usage of deployment diagrams can be described as follows:

To model the hardware topology of a system.

To model embedded system.

To model hardware details for a client/server system.

To model hardware details of a distributed application.

Forward and reverse engineering.

UML Deployment
Diagrams
Deployment diagram shows execution architecture of systems that represent the assignment
(deployment) of software artifacts to deployment targets (usually nodes).
Nodes represent either hardware devices or software execution environments. They could be
connected through communication paths to create network systems of arbitrary
complexity. Artifacts represent concrete elements in the physical world that are the result of a
development process and are deployed on nodes.
Note, that components were directly deployed to nodes in UML 1.x deployment diagrams. In UML
2.x artifacts are deployed to nodes, and artifacts couldmanifest (implement) components. So
components are now deployed to nodes indirectly through artifacts.
The following nodes and edges are typically drawn in a UML deployment
diagram: deployment, artifact, association between artifacts, dependencybetween
artifacts, component, manifestation, node, device, execution
environment, composition of nodes, communication path, deployment specification,
deployment specification dependency, deployment specification association.
You can find some deployment diagrams examples here:

Web application deployment

Web application manifestation
Multilayered load balancing
Clustered deployment of J2EE web application
Apple iTunes deployment
Android application deployment

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.

Artifact is a source of a deployment to a node. A particular instance (or "copy") of an artifact is

deployed to a node instance.

UML 2.4 definition of Artifact

Note, that in UML 2.4 artifact is also a subclass of deployed artifact. It is a weird, upside down
relationship, which is most likely a mistake. Deployed artifact is described by UML 2.4 as
an artifact or artifact instance that has been deployed to a deployment target. Common sense
assumes that deployed artifact should be a subclass of artifact and it should be allowed for some
artifacts not to be deployed.
Artifacts may have properties that represent features of the artifact, and operations that can be
performed on its instances. Artifacts have fileNameattribute - a concrete name that is used to refer
to the artifact in a physical context - e.g. file name or URI. Artifact could have nested artifacts.
Some real life examples of artifacts are:

text document
source file
script
binary executable file
archive file
table in a database

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

A physical file in the context of the system developed.

Standard stereotypes - subclasses of file:

document A generic file that is not a source file or executable.
source

A source file that can be compiled into an executable file.

library

A static or dynamic library file.

executable

A program file that can be executed on a computer system.

script

A script file that can be interpreted by a computer system.

Standard UML 1.x stereotype that is now obsolete:

table

Table in database.

Standard stereotypes can be further specialized into implementation and platform specific
stereotypes in profiles. For example, Java profile might define jar as a subclass of executable
for executable Java archives. Specific profiles are expected to provide some stereotype for artifact
representing sets of files.
Artifacts are deployed to a deployment target. Instance specification was extended in UML to
allow instances of artifacts to be deployed artifacts in adeployment relationship.
An artifact is presented using an ordinary class rectangle with the keyword artifact. Examples
in UML specification also show document icon in upper right corner.

Artifact web-app.war

C# source file artifact UserServices.cs

Library commons.dll

Alternatively, artifact may be depicted by an icon.

Artifact web-tools-lib.jar

Optionally, the underlining of the name of an artifact instance may be omitted, as the context is
assumed to be known to users.

Associations between 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.

Application book-club.ear artifact contains EJB user-service.jar artifact and deployment descriptor.

Dependency between Artifacts

Artifacts can be involved in dependency relationship with other artifacts.

Dependency between artifacts is notated in the same way as general dependency, i.e. as a general
dashed line with an open arrow head directed from client artifact to supplier artifact.

The book-club.war artifact depends on web-tools-lib.jar artifact.

Manifestation
Manifestation is an abstraction relationship which represents concrete physical rendering
(implementation) of one or more model elements by an artifactor utilization of the model elements
in the construction or generation of the artifact. An artifact manifests one or more model elements.
Note, that since UML 2.0 artifacts can manifest any packageable elements, not
just components as it was in previous versions of UML.
The artifact owns the manifestations, each representing the utilization of a packageable element.
Specific profiles are expected to stereotype the manifestation relationship to indicate particular
forms of manifestation. For example, tool generated and custom code might be two
manifestations for different classes embodied in an artifact.
A manifestation is notated in the same way as abstraction, i.e. as a dashed line with an open arrow
head directed from artifact to packageable element, (e.g. to component or package) and is
labeled with the keyword manifest.

EJB component UserService and skeleton of web services

are manifested (implemented) by EJB module user-service.jar artifact

In UML 1.x, the concept of manifestation was referred to as implementation and annotated as
implement. Since this was one of the many uses of the word "implementation" this has been
replaced in UML 2.x by manifest.

Deployment Target
Artifacts are deployed to deployment targets. Deployment target is the location for a
deployed artifact.

UML 2.4 definition of deployment target

Instance specification was extended in UML 2.0 to allow instance of a node to be deployment
target in a deployment relationship.
Property was also extended in UML 2.0 with the capability of being a deployment target in a
deployment relationship. This enables modeling the deployment to hierarchical nodes that have
properties functioning as internal parts.
Deployment target owns the set of deployments that target it.

Deployment target has no specific notation by itself, see notations for subclasses.

Node
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.

Application Server Node

Node is associated with deployments of artifacts and indirectly with packageable elements that
are involved in the manifestations by the artifact that is deployed on the node.
Nodes can be interconnected with communication paths. Communication paths can be defined
between nodes such as application server and database server to define the possible
communication paths between the nodes. Specific network topologies can then be defined
through links between node instances.
Node is specialized by:

device
execution environment

Hierarchical Node
Hierarchical nodes can be modeled using composition or by defining an internal structure.
Internal structure of the node is defined in terms of parts andconnectors. Parts of the node could
be only nodes.

Application server box runs several web servers and J2EE servers

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).

Several execution environments nested into server device

Execution environment instances are assigned to node instances by using composite

associations between nodes and execution environments, where the execution environment plays
the role of the part.

Device
A device is a node which represents a physical computational resource with processing capability
upon which artifacts may be deployed for execution.

A device is rendered as a node (perspective, 3-dimensional view of a cube) annotated with keyword
device.

Application Server device

UML provides no standard stereotypes for devices. Examples of non-normative stereotypes for
devices are:

application server
client workstation
mobile device
embedded device
Device may be depicted using custom icon. Profiles, stereotypes, and tagged values could be
used to provide custom icons and properties for the devices.

Application Server device depicted using custom icon

Computer stereotype with tags applied to Device class.

Database Server device depicted using custom icon

Mobile smartphone device depicted using custom icon

Devices may be complex (i.e., they may consist of other devices) where a physical machine is
decomposed into its elements, either through namespace ownership or through attributes that are
typed by devices.

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. Components of
the appropriate type are deployed to specific execution environments.
Execution environment implements a standard set of services that components require at
execution time (at the modeling level these services are usually implicit). For each deployment of
component, aspects of these services may be determined by properties in a deployment
specification for a particular kind of execution environment.
Execution environment is notated the same way as a node (perspective, 3-dimensional view of a
cube), annotated with the standard UML stereotype executionEnvironment.

Execution environment - J2EE Container

This executionEnvironment is pesky sesquipedalian to use. 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

Linux Operating System Execution Environment

Oracle 10g DBMS Execution Environment

An execution environment can optionally have an explicit interface of system level services that
can be used by the deployed elements, in those cases where the modeler wants to make the execution
environment software execution environment services explicit.

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

Communication path is notated as association, and it has no additional notation compared to

association.

Communication path between several application servers and database servers.

Note, that when deployment targets are some physical devices, communication path will typically
represent a physical connection 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.

TCP/IP protocol as communication path between J2EE server and database system.

Deployment
A deployment is a dependency relationship which describes allocation (deployment) of
an artifact to a deployment target. Deployment could be also defined at instance level - as
allocation of specific artifact instance to the specific instance of deployment target.
A component deployment is deployment of one or more artifacts or artifact instances, optionally
parameterized by a deployment specification.

It is not very clear why UML defines deployment as a dependency, and not as an association or
just a directed relationship. The major contradiction is that dependency in UML does not have
any runtime implications, and is defined in terms of the model elements, not in terms of their
instances. At the same time UML 2.4 allows and shows examples of instances of artifacts deployed to
instances of nodes.
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.

J2EE web application archive portfolio.war

deployed on Apache Tomcat JSP server.

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.

J2EE web application archive portfolio.war deployed

on two instances of Apache Tomcat JSP server - psrv_023 and psrv_037.

For modeling complex deployment target models consisting of nodes with a composite structure
defined through "parts," a property (that functions as a part) may also be the target of a deployment.
Deployment could be shown with deployed artifacts contained by a deployment target.

The portfolio.ear artifact deployed on application server.

Deployment could be shown using textual list of deployed artifacts within a deployment target.

The portfolio.ear, stocks.ear, weather.ear artifacts deployed in J2EE 1.4 container.

Deployment could be shown within a rectangular frame 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.

User Services deployment shown in the diagram frame.

Deployment Specification
A deployment specification is an artifact that specifies a set of deployment properties that
determine execution parameters of a component artifact that is deployed on a node. A
deployment specification can be aimed at a specific type of container for components.

A deployment specification is a general mechanism to parameterize a deployment relationship,

as is common in various hardware and software technologies. The deployment
specification element is expected to be extended in specific component profiles. Non-normative
examples of the standard stereotypes that a profile might add to deployment specification are, for
example, concurrencyMode with tagged values {thread, process, none}, or
transactionMode with tagged values {transaction, nestedTransaction, none}.
A deployment specification at specification level is rendered as a classifier rectangle with
optional deployment properties in a compartment.

The ejb-jar.xml deployment specification

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

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

The ejb-jar.xml deployment descriptor

An instance of a deployment specification with specific values for deployment properties may be
contained in a complex artifact.

Deployment Specification
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.

The ejb-jar.xml deployment specification for user-service.ejb artifact.

Deployment Specification
Association
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, that 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.

Deployment diagram

Notation

Definition

Aggregation
(Shared
association)

Artifact

Association
(Without
aggregation)

Component

Composition
(Composite
association)

Constraint

Dependency

Deployment

The Deployment Diagram also helps to model the physical aspect of an

Object-Oriented software system. It models the run-time configuration in
a static view and visualizes the distribution of components in an
application. In most cases, it involves modeling the hardware
configurations together with the software components that lived on.

Deployment
Specification

Device Node

Execution
Environment
Node

Generalizatio
n

Instance
Specification

Interface

Link

Manifestation

Node

Note

Port

Realization

Usage

Aggregation (Shared association)

Definition
A kind of association that has one of its end marked shared as
kind of aggregation, meaning that it has a shared aggregation.

Properties
Name

The name of aggregation.

Visibility

Determines where the aggregation

appears within different namespaces
within the overall model, and its
accessibility.

Association End
From

The source of aggregation.

Association End ToThe target of aggregation.

Documentation

Description of aggregation.

Abstract

If true, the aggregation does not provide a

complete declaration and can typically not
be instantiated. An abstract aggregation is
intended to be used by other

aggregations.
Leaf

Indicates whether it is possible to further

specialize an aggregation. If the value is
true, then it is not possible to further
specialize the aggregation.

Derived

Specifies whether the aggregation is

derived from other model elements such
as other aggregations or constraints.

Artifact

Definition
An artifact is the specification of a physical piece of information
that is used or produced by a software development process, or
by deployment and operation of a system. Examples of artifacts
include model files, source files, scripts, and binary executable
files, a table in a database system, a development deliverable,
or a word-processing document, a mail message.

Properties
Name

The name of artifact.

Visibility

Determines where the aggregation

appears within different namespaces
within the overall model, and its
accessibility.

File name

A concrete name that is used to refer to

the Artifact in a physical context.
Example: file system name, universal
resource locator.

Documentation

Description of artifact.

Abstract

If true, the artifact does not provide a

complete declaration and can typically not
be instantiated. An abstract artifact is
intended to be used by other artifacts.

Leaf

Indicates whether it is possible to further

specialize an artifact. If the value is true,

then it is not possible to further specialize

the artifact.
Nested Arifacts

The Artifacts that are defined (nested)

within the artifact.

Attributes

Refers to all of the Properties that are

direct (i.e., not inherited or imported)
attributes of the artifact.

Operations

An operation is a behavioral feature of an

artifact that specifies the name, type,
parameters, and constraints for invoking
an associated behavior. Operations here
refers to the operations owned by the
artifact.

Association (Without aggregation)

Definition
An association specifies a semantic relationship that can occur
between typed instances. It has at least two ends represented
by properties, each of which is connected to the type of the end.
More than one end of the association may have the same type.
An end property of an association that is owned by an end class
or that is a navigable owned end of the association indicates that
the association is navigable from the opposite ends; otherwise,
the association is not navigable from the opposite ends.

Properties
Name

The name of association.

Visibility

Determines where the association

appears within different namespaces
within the overall model, and its
accessibility.

Association End
From

The source of association.

Association End ToThe target of association.

Documentation

Description of association.

Abstract

If true, the association does not provide a

complete declaration and can typically not
be instantiated. An abstract association is
intended to be used by other
associations.

Leaf

Indicates whether it is possible to further

specialize an association. If the value is
true, then it is not possible to further
specialize the association.

Derived

Specifies whether the association is

derived from other model elements such
as other associations or constraints.

Component

Definition
A component represents a modular part of a system that
encapsulates its contents and whose manifestation is
replaceable within its environment.
A component defines its behavior in terms of provided and
required interfaces. As such, a component serves as a type
whose conformance is defined by these provided and required
interfaces (encompassing both their static as well as dynamic
semantics). One component may therefore be substituted by
another only if the two are type conformant. Larger pieces of a
system?s functionality may be assembled by reusing
components as parts in an encompassing component or
assembly of components, and wiring together their required and
provided interfaces.
A component is modeled throughout the development life cycle
and successively refined into deployment and run-time. A
component may be manifest by one or more artifacts, and in
turn, that artifact may be deployed to its execution environment.
A deployment specification may define values that parameterize
the component?s execution.

Properties
Name

The name of component.

Visibility

Determines where the component

appears within different namespaces
within the overall model, and its
accessibility.

Documentation

Description of component.

Abstract

If true, the component does not provide a

complete declaration and can typically not
be instantiated. An abstract component is
intended to be used by other components.

Leaf

Indicates whether it is possible to further

specialize an component. If the value is
true, then it is not possible to further
specialize the component.

Root

Indicates whether the component has no

ancestors. (true for no ancestors)

Active

Determines whether an object specified

by this component is active or not. If true,
then the owning component is referred to
as an active component. If false, then
such a component is referred to as a
passive component.

Indirectly
instantiated

The kind of instantiation that applies to a

Component. If false, the component is
instantiated as an addressable object. If
true, the Component is defined at designtime, but at run-time (or execution-time)
an object specified by the Component
does not exist, that is, the component is
instantiated indirectly, through the
instantiation of its realizing classifiers or
parts.

Composition (Composite association)

Definition
An association may represent a composite aggregation (i.e., a
whole/part relationship). Only binary associations can be
aggregations. Composite aggregation is a strong form of
aggregation that requires a part instance be included in at most
one composite at a time. If a composite is deleted, all of its parts
are normally deleted with it. Note that a part can (where allowed)
be removed from a composite before the composite is deleted,
and thus not be deleted as part of the composite. Compositions

may be linked in a directed acyclic graph with transitive deletion

characteristics; that is, deleting an element in one part of the
graph will also result in the deletion of all elements of the
subgraph below that element. Composition is represented by the
isComposite attribute on the part end of the association being
set to true.

Properties
Name

The name of composition.

Visibility

Determines where the association

appears within different namespaces
within the overall model, and its
accessibility.

Association End
From

The source of association.

Association End ToThe target of association.

Documentation

Description of association.

Abstract

If true, the composition does not provide a

complete declaration and can typically not
be instantiated. An abstract composition is
intended to be used by other
compositions.

Leaf

Indicates whether it is possible to further

specialize a composition. If the value is
true, then it is not possible to further
specialize the composition.

Derived

Specifies whether the composition is

derived from other model elements such
as other compositions or constraints.

Constraint

Definition
A condition or restriction expressed in natural language text or in
a machine readable language for the purpose of declaring some
of the semantics of an element.

Dependency

Definition
A dependency is a relationship that signifies that a single or a set
of model elements requires other model elements for their
specification or implementation. This means that the complete
semantics of the depending elements is either semantically or
structurally dependent on the definition of the supplier
element(s).

Properties
Name

The name of dependency.

Supplier

The element(s) independent of the client

element(s), in the same respect and the
same dependency relationship. In some
directed dependency relationships (such
as Refinement Abstractions), a common
convention in the domain of class-based
OO software is to put the more abstract
element in this role. Despite this
convention, users of UML may stipulate a
sense of dependency suitable for their
domain, which makes a more abstract
element dependent on that which is more
specific.

Client

The element(s) dependent on the supplier

element(s). In some cases (such as a
Trace Abstraction) the assignment of
direction (that is, the designation of the
client element) is at the discretion of the
modeler, and is a stipulation.

Visibility

Determines where the dependency

appears within different namespaces
within the overall model, and its
accessibility.

Documentation

Description of dependency.

Deployment

Definition
A deployment is the allocation of an artifact or artifact instance to
a deployment target.

Properties
Name

The name of deployment.

Deployed Artifact The Artifacts that are deployed onto a

Node. This association specializes the
supplier association.
Location

The DeploymentTarget that is the target of

a Deployment. This association
specializes the client association.

Visibility

Determines where the deployment

appears within different namespaces
within the overall model, and its
accessibility.

Documentation

Description of deployment.

Deployment Specification

Definition
A deployment specification specifies a set of properties that
determine execution parameters of a component artifact that is
deployed on a node. A deployment specification can be aimed at
a specific type of container. An artifact that reifies or implements
deployment specification properties is a deployment descriptor.

Properties
Name

The name of deployment specification.

Visibility

Determines where the deployment

specification appears within different
namespaces within the overall model, and
its accessibility.

File name

A concrete name that is used to refer to

the deployment specification in a physical
context. Example: file system name,
universal resource locator.

Deployment
location

The location where an artifact is deployed

onto a Node. This is typically a 'directory'
or 'memory address.'

Execution location The location where a component artifact

executes. This may be a local or remote
location.
Documentation

Description of deployment specification.

Abstract

If true, the deployment specification does

not provide a complete declaration and
can typically not be instantiated. An
abstract deployment specification is
intended to be used by other deployment
specifications.

Leaf

Indicates whether it is possible to further

specialize a deployment specification. If
the value is true, then it is not possible to
further specialize the deployment
specification.

Nested Arifacts

The deployment specifications that are

defined (nested) within the deployment
specification.

Attributes

Refers to all of the Properties that are

direct (i.e., not inherited or imported)
attributes of the deployment specification.

Operations

An operation is a behavioral feature of a

deployment specification that specifies
the name, type, parameters, and
constraints for invoking an associated
behavior. Operations here refers to the
operations owned by the deployment

specification.

Device Node

Definition
A Device is a physical computational resource with processing
capability upon which artifacts may be deployed for execution.
Devices may be complex (i.e., they may consist of other
devices).

Properties
Name

The name of node.

Visibility

Determines where the node appears

within different namespaces within the
overall model, and its accessibility.

Documentation

Description of node.

Abstract

If true, the node does not provide a

complete declaration and can typically not
be instantiated. An abstract node is
intended to be used by other nodes.

Leaf

Indicates whether it is possible to further

specialize a node. If the value is true, then
it is not possible to further specialize the
node.

Root

Indicates whether the node has no

ancestors. (true for no ancestors)

Active

Determines whether an object specified

by this node is active or not. If true, then
the owning node is referred to as an
active node. If false, then such a node is
referred to as a passive node.

Nested Nodes

The nodes that are defined (nested)

within the node.

Resident
Components

The components contained by node

Attributes

Refers to all of the Properties that are

direct (i.e., not inherited or imported)
attributes of the node.

Operations

An operation is a behavioral feature of an

artifact that specifies the name, type,
parameters, and constraints for invoking
an associated behavior. Operations here
refers to the operations owned by the
node.

Template
Parameters

A TemplateableElement that has a

template signature is a specification of a
template. A template is a parameterized
element that can be used to generate
other model elements using
TemplateBinding relationships. The
template parameters for the template
signature specify the formal parameters
that will be substituted by actual
parameters (or the default) in a binding.
A template parameter is defined in the
namespace of the template, but the
template parameter represents a model
element that is defined in the context of
the binding.
A templateable element can be bound to
other templates. This is represented by
the bound element having bindings to the
template signatures of the target
templates. In a canonical model a bound
element does not explicitly contain the
model elements implied by expanding the
templates it binds to, since those
expansions are regarded as derived. The
semantics and well-formedness rules for
the bound element must be evaluated as
if the bindings were expanded with the
substitutions of actual elements for formal
parameters

Class Code
Details

Properties of node in implementation

(code) level. Settings in this page is
programming language specific, and will
affect the code being generated.

Execution Environment Node

Definition
An ExecutionEnvironment is a node that offers an execution
environment for specific types of components that are deployed
on it in the form of executable artifacts.

Properties
Name

The name of node.

Visibility

Determines where the node appears

within different namespaces within the
overall model, and its accessibility.

Documentation

Description of node.

Abstract

If true, the node does not provide a

complete declaration and can typically not
be instantiated. An abstract node is
intended to be used by other nodes.

Leaf

Indicates whether it is possible to further

specialize a node. If the value is true, then
it is not possible to further specialize the
node.

Root

Indicates whether the node has no

ancestors. (true for no ancestors)

Active

Determines whether an object specified

by this node is active or not. If true, then
the owning node is referred to as an
active node. If false, then such a node is
referred to as a passive node.

Nested Nodes

The nodes that are defined (nested)

within the node.

Resident
Components

The components contained by node

Attributes

Refers to all of the Properties that are

direct (i.e., not inherited or imported)
attributes of the node.

Operations

An operation is a behavioral feature of an

artifact that specifies the name, type,
parameters, and constraints for invoking
an associated behavior. Operations here
refers to the operations owned by the
node.

Template
Parameters

A TemplateableElement that has a

template signature is a specification of a
template. A template is a parameterized
element that can be used to generate
other model elements using
TemplateBinding relationships. The
template parameters for the template
signature specify the formal parameters
that will be substituted by actual
parameters (or the default) in a binding.
A template parameter is defined in the
namespace of the template, but the
template parameter represents a model
element that is defined in the context of
the binding.
A templateable element can be bound to
other templates. This is represented by
the bound element having bindings to the
template signatures of the target
templates. In a canonical model a bound
element does not explicitly contain the
model elements implied by expanding the
templates it binds to, since those
expansions are regarded as derived. The
semantics and well-formedness rules for
the bound element must be evaluated as
if the bindings were expanded with the
substitutions of actual elements for formal
parameters

Class Code
Details

Properties of node in implementation

(code) level. Settings in this page is
programming language specific, and will
affect the code being generated.

Generalization

Definition
A generalization is a taxonomic relationship between a more
general classifier and a more specific classifier. Each instance of
the specific classifier is also an indirect instance of the general
classifier. Thus, the specific classifier inherits the features of the
more general classifier.

Instance Specification

Definition
An instance specification is extended with the capability of being
a deployment target in a deployment relationship, in the case
that it is an instance of a node. It is also extended with the
capability of being a deployed artifact, if it is an instance of an
artifact.

Properties
Name

The name of instance specification.

Specification

A specification of how to compute, derive,

or construct the instance.

Documentation

Description of instance specification.

Classifier

The classifier or classifiers of the

represented instance. If multiple
classifiers are specified, the instance is
classified by all of them.

Slots

A slot giving the value or values of a

structural feature of the instance. An
instance specification can have one slot
per structural feature of its classifiers,
including inherited features. It is not
necessary to model a slot for each
structural feature, in which case the
instance specification is a partial
description.

Interface

Definition
An interface is a kind of classifier that represents a declaration of
a set of coherent public features and obligations. An interface
specifies a contract; any instance of a classifier that realizes the
interface must fulfill that contract. The obligations that may be
associated with an interface are in the form of various kinds of

constraints (such as pre- and postconditions) or protocol

specifications, which may impose ordering restrictions on
interactions through the interface.
Since interfaces are declarations, they are not instantiable.
Instead, an interface specification is implemented by an instance
of an instantiable classifier, which means that the instantiable
classifier presents a public facade that conforms to the interface
specification. Note that a given classifier may implement more
than one interface and that an interface may be implemented by
a number of different classifiers.

Properties
Name

The name of interface.

Parent

The model element that owns the

interface.

Visibility

Determines where the interface appears

within different namespaces within the
overall model, and its accessibility.

Documentation

Description of interface.

Abstract

If true, the class does not provide a

complete declaration and can typically not
be instantiated. An abstract class is
intended to be used by other classes.

Leaf

Indicates whether it is possible to further

specialize a class. If the value is true,
then it is not possible to further specialize
the class.

Root

Indicates whether the class has no

ancestors. (true for no ancestors)

Active

Determines whether an object specified

by this class is active or not. If true, then
the owning class is referred to as an
active class. If false, then such a class is
referred to as a passive class.

Business model

Set it to make the class become a

"business class"

Attributes

Refers to all of the Properties that are

direct (i.e., not inherited or imported)

attributes of the class.

Operations

An operation is a behavioral feature of a

class that specifies the name, type,
parameters, and constraints for invoking
an associated behavior. Operations here
refers to the operations owned by the
class.

Template
Parameters

A TemplateableElement that has a

template signature is a specification of a
template. A template is a parameterized
element that can be used to generate
other model elements using
TemplateBinding relationships. The
template parameters for the template
signature specify the formal parameters
that will be substituted by actual
parameters (or the default) in a binding.
A template parameter is defined in the
namespace of the template, but the
template parameter represents a model
element that is defined in the context of
the binding.
A templateable element can be bound to
other templates. This is represented by
the bound element having bindings to the
template signatures of the target
templates. In a canonical model a bound
element does not explicitly contain the
model elements implied by expanding the
templates it binds to, since those
expansions are regarded as derived. The
semantics and well-formedness rules for
the bound element must be evaluated as
if the bindings were expanded with the
substitutions of actual elements for formal
parameters

Class Code
Details

Properties of class in implementation

(code) level. Settings in this page is
programming language specific, and will
affect the code being generated.

Java Annotations A Java annotation is a metadata that can

be added to Java source code for
annotation purposes.
ORM Query

Available only to ORM Persistable class,

ORM Query lets you define the ORM
Qualifiers and named queries of the class.

Link

Definition
An association declares that there can be links between
instances of the associated types. A link is a tuple with one value
for each end of the association, where each value is an instance
of the type of the end.

Properties
Name

The name of link.

From

The source of link.

To

The target of link.

Specification

A specification of how to compute, derive,

or construct the instance.

Classifiers

The classifier or classifiers of the

represented instance. If multiple
classifiers are specified, the instance is
classified by all of them.

Slots

A slot giving the value or values of a

structural feature of the instance. An
instance specification can have one slot
per structural feature of its classifiers,
including inherited features. It is not
necessary to model a slot for each
structural feature, in which case the link is
a partial description.

Documentation

Description of link.

Manifestation

Definition
A manifestation is the concrete physical rendering of one or
more model elements by an artifact.

Node

Definition
A node is computational resource upon which artifacts may be
deployed for execution. Node is a subclass of Class. It is
associated with a Deployment of an Artifact. It is also associated
with a set of Elements that are deployed on it. This

Properties
Name

The name of node.

Visibility

Determines where the node appears

within different namespaces within the
overall model, and its accessibility.

Documentation

Description of node.

Abstract

If true, the node does not provide a

complete declaration and can typically not
be instantiated. An abstract node is
intended to be used by other nodes.

Leaf

Indicates whether it is possible to further

specialize a node. If the value is true, then
it is not possible to further specialize the
node.

Root

Indicates whether the node has no

ancestors. (true for no ancestors)

Active

Determines whether an object specified

by this node is active or not. If true, then
the owning node is referred to as an
active node. If false, then such a node is
referred to as a passive node.

Nested Nodes

The nodes that are defined (nested)

within the node.

Resident
Components

The components contained by node

Attributes

Refers to all of the Properties that are

direct (i.e., not inherited or imported)

attributes of the node.
Operations

An operation is a behavioral feature of an

artifact that specifies the name, type,
parameters, and constraints for invoking
an associated behavior. Operations here
refers to the operations owned by the
node.

Template
Parameters

A TemplateableElement that has a

template signature is a specification of a
template. A template is a parameterized
element that can be used to generate
other model elements using
TemplateBinding relationships. The
template parameters for the template
signature specify the formal parameters
that will be substituted by actual
parameters (or the default) in a binding.
A template parameter is defined in the
namespace of the template, but the
template parameter represents a model
element that is defined in the context of
the binding.
A templateable element can be bound to
other templates. This is represented by
the bound element having bindings to the
template signatures of the target
templates. In a canonical model a bound
element does not explicitly contain the
model elements implied by expanding the
templates it binds to, since those
expansions are regarded as derived. The
semantics and well-formedness rules for
the bound element must be evaluated as
if the bindings were expanded with the
substitutions of actual elements for formal
parameters

Class Code
Details

Properties of node in implementation

(code) level. Settings in this page is
programming language specific, and will
affect the code being generated.

Note

Definition
A note (comment) gives the ability to attach various remarks to
elements. A comment carries no semantic force, but may contain
information that is useful to a modeler.

Port

Definition
A port is a property of a classifier that specifies a distinct
interaction point between that classifier and its environment or
between the (behavior of the) classifier and its internal parts.
Ports are connected to properties of the classifier by connectors
through which requests can be made to invoke the behavioral
features of a classifier. A Port may specify the services a
classifier provides (offers) to its environment as well as the
services that a classifier expects (requires) of its environment.

Properties
Name

The name of port.

Multiplicity

Specifies the allowable cardinalities for an

instantiation of this port.

Visibility

Determines where the port appears within

different namespaces within the overall
model, and its accessibility.

Type

The DataType that owns this port

Type Modifier

Indicates a modifier that applies to the

port.

Aggregation

Specifies the kind of aggregation that

applies to the part.

Default Value

A String that is evaluated to give a default

value for the Property when an object of
the owning Classifier is instantiated.

Redefined Port

A port may be redefined when its

containing classifier is specialized. The
redefining port may have additional
interfaces to those that are associated
with the redefined port or it may replace
an interface by one of its subtypes.

Documentation

Description of port.

Leaf

Indicates whether it is possible to further

specialize a class. If the value is true,
then it is not possible to further specialize
the class.

Static

Specifies whether this feature

characterizes individual instances
classified by the classifier (false) or the
classifier itself (true).

Read Only

If true, the attribute may only be read, and

not written.

Derive

Specifies whether the port is derived, i.e.,

whether its value or values can be
computed from other information.

Derived Union

Specifies whether the port is derived as

the union of all of the ports that are
constrained to subset it.

Service

If true, indicates that this port is used to

provide the published functionality of a
classifier. If false, this port is used to
implement the classifier but is not part of
the essential externally-visible
functionality of the classifier and can,
therefore, be altered or deleted along with
the internal implementation of the
classifier and other properties that are
considered part of its implementation.

Behavior

Specifies whether requests arriving at this

port are sent to the classifier behavior of
this classifier. Such ports are referred to
as behavior port. Any invocation of a
behavioral feature targeted at a behavior
port will be handled by the instance of the
owning classifier itself, rather than by any
instances that this classifier may contain.

Realization

Definition
Realization is a specialized abstraction relationship between two
sets of model elements, one representing a specification (the
supplier) and the other represents an implementation of the
latter (the client). Realization can be used to model stepwise
refinement, optimizations, transformations, templates, model
synthesis, framework composition, etc.

Usage

Definition
A usage is a relationship in which one element requires another
element (or set of elements) for its full implementation or
operation. In the metamodel, a Usage is a Dependency in which
the client requires the presence of the supplier.

Properties
Name

The name of usage relationship.

Supplier

The element(s) independent of the client

element(s), in the same respect and the
same dependency relationship. In some
directed dependency relationships (such
as Refinement Abstractions), a common
convention in the domain of class-based
OO software is to put the more abstract
element in this role. Despite this
convention, users of UML may stipulate a
sense of dependency suitable for their
domain, which makes a more abstract
element dependent on that which is more
specific.

Client

The element(s) dependent on the supplier

element(s). In some cases (such as a
Trace Abstraction) the assignment of
direction (that is, the designation of the
client element) is at the discretion of the
modeler, and is a stipulation.

Visibility

Determines where the usage relationship

appears within different namespaces
within the overall model, and its
accessibility.

Documentation

Description of usage relationship.