Deployment diagram

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.
Use case diagram | Class diagram | Sequence diagram | Communication diagram | State machine diagram | Activity diagram | Component diagram | Deployment diagram | Package diagram | Object diagram | Composite structure diagram | Timing diagram | Interaction overview diagram

Deployment diagram

Notation

 Aggregation (Shared association) Artifact
 Association (Without aggregation) Component
 Composition (Composite association) Constraint
 Dependency Deployment
 Deployment Specification Device Node
 Execution Environment Node Generalization
 Instance Specification Interface
 Link Manifestation
 Node Note
 Port Realization
 Usage

Definition

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.
 

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

NameThe name of aggregation.
VisibilityDetermines where the aggregation appears within different namespaces within the overall model, and its accessibility.
Association End FromThe source of aggregation.
Association End ToThe target of aggregation.
DocumentationDescription of aggregation.
AbstractIf 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.
LeafIndicates whether it is possible to further specialize an aggregation. If the value is true, then it is not possible to further specialize the aggregation.
DerivedSpecifies 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

NameThe name of artifact.
VisibilityDetermines where the aggregation appears within different namespaces within the overall model, and its accessibility.
File nameA concrete name that is used to refer to the Artifact in a physical context. Example: file system name, universal resource locator.
DocumentationDescription of artifact.
AbstractIf 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.
LeafIndicates 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 ArifactsThe Artifacts that are defined (nested) within the artifact.
AttributesRefers to all of the Properties that are direct (i.e., not inherited or imported) attributes of the artifact.
OperationsAn 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

NameThe name of association.
VisibilityDetermines where the association appears within different namespaces within the overall model, and its accessibility.
Association End FromThe source of association.
Association End ToThe target of association.
DocumentationDescription of association.
AbstractIf 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.
LeafIndicates whether it is possible to further specialize an association. If the value is true, then it is not possible to further specialize the association.
DerivedSpecifies 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

NameThe name of component.
VisibilityDetermines where the component appears within different namespaces within the overall model, and its accessibility.
DocumentationDescription of component.
AbstractIf 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.
LeafIndicates whether it is possible to further specialize an component. If the value is true, then it is not possible to further specialize the component.
RootIndicates whether the component has no ancestors. (true for no ancestors)
ActiveDetermines 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 instantiatedThe 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 design-time, 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

NameThe name of composition.
VisibilityDetermines where the association appears within different namespaces within the overall model, and its accessibility.
Association End FromThe source of association.
Association End ToThe target of association.
DocumentationDescription of association.
AbstractIf 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.
LeafIndicates whether it is possible to further specialize a composition. If the value is true, then it is not possible to further specialize the composition.
DerivedSpecifies 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.

Properties

NameThe name of constraint. It is optional and is commonly omitted.
ExpressionThe condition that must be true when evaluated in order for the constraint to be satisfied.
DocumentationDescription of constraint.
 

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

NameThe name of dependency.
SupplierThe 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.
ClientThe 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.
VisibilityDetermines where the dependency appears within different namespaces within the overall model, and its accessibility.
DocumentationDescription of dependency.
 

Deployment

Definition

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

Properties

NameThe name of deployment.
Deployed ArtifactThe Artifacts that are deployed onto a Node. This association specializes the supplier association.
LocationThe DeploymentTarget that is the target of a Deployment. This association specializes the client association.
VisibilityDetermines where the deployment appears within different namespaces within the overall model, and its accessibility.
DocumentationDescription 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

NameThe name of deployment specification.
VisibilityDetermines where the deployment specification appears within different namespaces within the overall model, and its accessibility.
File nameA concrete name that is used to refer to the deployment specification in a physical context. Example: file system name, universal resource locator.
Deployment locationThe location where an artifact is deployed onto a Node. This is typically a 'directory' or 'memory address.'
Execution locationThe location where a component artifact executes. This may be a local or remote location.
DocumentationDescription of deployment specification.
AbstractIf 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.
LeafIndicates 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 ArifactsThe deployment specifications that are defined (nested) within the deployment specification.
AttributesRefers to all of the Properties that are direct (i.e., not inherited or imported) attributes of the deployment specification.
OperationsAn 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

NameThe name of node.
VisibilityDetermines where the node appears within different namespaces within the overall model, and its accessibility.
DocumentationDescription of node.
AbstractIf 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.
LeafIndicates whether it is possible to further specialize a node. If the value is true, then it is not possible to further specialize the node.
RootIndicates whether the node has no ancestors. (true for no ancestors)
ActiveDetermines 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 NodesThe nodes that are defined (nested) within the node.
Resident ComponentsThe components contained by node
AttributesRefers to all of the Properties that are direct (i.e., not inherited or imported) attributes of the node.
OperationsAn 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 ParametersA 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 DetailsProperties 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

NameThe name of node.
VisibilityDetermines where the node appears within different namespaces within the overall model, and its accessibility.
DocumentationDescription of node.
AbstractIf 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.
LeafIndicates whether it is possible to further specialize a node. If the value is true, then it is not possible to further specialize the node.
RootIndicates whether the node has no ancestors. (true for no ancestors)
ActiveDetermines 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 NodesThe nodes that are defined (nested) within the node.
Resident ComponentsThe components contained by node
AttributesRefers to all of the Properties that are direct (i.e., not inherited or imported) attributes of the node.
OperationsAn 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 ParametersA 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 DetailsProperties 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.

Properties

NameThe name of generalization.
GeneralReferences the general classifier in the Generalization relationship.
SpecificReferences the specializing classifier in the Generalization relationship.
VisibilityDetermines where the generalization relationship appears within different namespaces within the overall model, and its accessibility.
DocumentationDescription of generalization relationship.
SubstitutableIndicates whether the specific classifier can be used wherever the general classifier can be used. If true, the execution traces of the specific classifier will be a superset of the execution traces of the 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

NameThe name of instance specification.
SpecificationA specification of how to compute, derive, or construct the instance.
DocumentationDescription of instance specification.
ClassifierThe classifier or classifiers of the represented instance. If multiple classifiers are specified, the instance is classified by all of them.
SlotsA 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

NameThe name of interface.
ParentThe model element that owns the interface.
VisibilityDetermines where the interface appears within different namespaces within the overall model, and its accessibility.
DocumentationDescription of interface.
AbstractIf 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.
LeafIndicates whether it is possible to further specialize a class. If the value is true, then it is not possible to further specialize the class.
RootIndicates whether the class has no ancestors. (true for no ancestors)
ActiveDetermines 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 modelSet it to make the class become a "business class"
AttributesRefers to all of the Properties that are direct (i.e., not inherited or imported) attributes of the class.
OperationsAn 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 ParametersA 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 DetailsProperties of class in implementation (code) level. Settings in this page is programming language specific, and will affect the code being generated.
Java AnnotationsA Java annotation is a metadata that can be added to Java source code for annotation purposes.
ORM QueryAvailable 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

NameThe name of link.
FromThe source of link.
ToThe target of link.
SpecificationA specification of how to compute, derive, or construct the instance.
ClassifiersThe classifier or classifiers of the represented instance. If multiple classifiers are specified, the instance is classified by all of them.
SlotsA 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.
DocumentationDescription of link.
 

Manifestation

Definition

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

Properties

NameThe name of manifestation.
SupplierThe element(s) independent of the client element(s), in the same respect and the same manifestation relationship.
ClientThe element(s) dependent on the supplier element(s).
VisibilityDetermines where the manifestation appears within different namespaces within the overall model, and its accessibility.
DocumentationDescription of manifestation.
 

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

NameThe name of node.
VisibilityDetermines where the node appears within different namespaces within the overall model, and its accessibility.
DocumentationDescription of node.
AbstractIf 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.
LeafIndicates whether it is possible to further specialize a node. If the value is true, then it is not possible to further specialize the node.
RootIndicates whether the node has no ancestors. (true for no ancestors)
ActiveDetermines 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 NodesThe nodes that are defined (nested) within the node.
Resident ComponentsThe components contained by node
AttributesRefers to all of the Properties that are direct (i.e., not inherited or imported) attributes of the node.
OperationsAn 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 ParametersA 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 DetailsProperties 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.

Properties

NameThe name of note.
DocumentationSpecifies a string that is the comment.
 

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

NameThe name of port.
MultiplicitySpecifies the allowable cardinalities for an instantiation of this port.
VisibilityDetermines where the port appears within different namespaces within the overall model, and its accessibility.
TypeThe DataType that owns this port
Type ModifierIndicates a modifier that applies to the port.
AggregationSpecifies the kind of aggregation that applies to the part.
Default ValueA String that is evaluated to give a default value for the Property when an object of the owning Classifier is instantiated.
Redefined PortA 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.
DocumentationDescription of port.
LeafIndicates whether it is possible to further specialize a class. If the value is true, then it is not possible to further specialize the class.
StaticSpecifies whether this feature characterizes individual instances classified by the classifier (false) or the classifier itself (true).
Read OnlyIf true, the attribute may only be read, and not written.
DeriveSpecifies whether the port is derived, i.e., whether its value or values can be computed from other information.
Derived UnionSpecifies whether the port is derived as the union of all of the ports that are constrained to subset it.
ServiceIf 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.
BehaviorSpecifies 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.

Properties

NameThe name of realization relationship.
SupplierThe 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.
ClientThe 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.
VisibilityDetermines where the realization relationship appears within different namespaces within the overall model, and its accessibility.
MappingA composition of an Expression that states the abstraction relationship between the supplier and the client. In some cases, such as Derivation, it is usually formal and unidirectional. In other cases, such as Trace, it is usually informal and bidirectional. The mapping expression is optional and may be omitted if the precise relationship between the elements is not specified.
DocumentationDescription of realization relationship.
 

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

NameThe name of usage relationship.
SupplierThe 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.
ClientThe 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.
VisibilityDetermines where the usage relationship appears within different namespaces within the overall model, and its accessibility.
DocumentationDescription of usage relationship.
 
Definition of notations is quoted from Object Management Group Unified Modeling Language (OMG UML) Superstructure Version 2.2 and former versions (for notations that do not exist anymore in latest specification).
 
Use case diagram | Class diagram | Sequence diagram | Communication diagram | State machine diagram | Activity diagram | Component diagram | Deployment diagram | Package diagram | Object diagram | Composite structure diagram | Timing diagram | Interaction overview diagram
Gallery Home
Visual Modeling
UML Modeling
Use Case Modeling
Requirements Capturing
Data Modeling
Business Process Modeling
Object Relational Mapping
Documentation Generation
Code Engineering
Interoperability
User Interface
Cross-Platform
Visual Studio Integration
Eclipse Integration
NetBeans Integration