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 | | 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 | | | | | | DefinitionThe 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 | | 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 To | The 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 To | The 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 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 | | 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 To | The 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. | | | Properties | | Name | The name of constraint. It is optional and is commonly omitted. | Expression | The condition that must be true when evaluated in order for the constraint to be satisfied. | Documentation | Description 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 | | 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. | | | Properties | | Name | The name of generalization. | General | References the general classifier in the Generalization relationship. | Specific | References the specializing classifier in the Generalization relationship. | Visibility | Determines where the generalization relationship appears within different namespaces within the overall model, and its accessibility. | Documentation | Description of generalization relationship. | Substitutable | Indicates 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 | | 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. | | | Properties | | Name | The name of manifestation. | Supplier | The element(s) independent of the client element(s), in the same respect and the same manifestation relationship. | Client | The element(s) dependent on the supplier element(s). | Visibility | Determines where the manifestation appears within different namespaces within the overall model, and its accessibility. | Documentation | Description 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 | | 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. | | | Properties | | Name | The name of note. | Documentation | Specifies 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 | | 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. | | | Properties | | Name | The name of realization 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 realization relationship appears within different namespaces within the overall model, and its accessibility. | Mapping | A 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. | Documentation | Description 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 | | 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. | | | | |