Class Descriptions


Artifact

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.

Description

Artifacts

In the metamodel, an Artifact is a Classifier that represents a physical entity. Artifacts may have Properties that represent features of the Artifact, and Operations that can be performed on its instances. Artifacts can be involved in Associations to other Artifacts, e.g. composition associations. Artifacts can be instantiated to represent detailed copy semantics, where different instances of the same Artifact may be deployed to various Node instances (and each may have separate property values, e.g. for a `time-stamp' property.

Node

As part of the Nodes package, an Artifact is extended to become the source of a deployment to a Node. This is achieved by specializing the abstract superclass DeployedArtifact defined in the Nodes package.

Attributes

Artifacts
Associations

Artifacts

  • nestedArtifact: Artifact [*]
The Artifacts that are defined (nested) within the Artifact.The association is a specialization of the nestedClassifier association from Class to Classifier.
  • ownedProperty : Property [*]
The attributes or association ends defined for the Artifact.The association is a specialization of the ownedMember association.
  • ownedOperation : Operation [*]
The Operations defined for the Artifact.The association is a specialization of the ownedMember association.
  • manifestation : Manifestation [*]
The set of model elements that are manifested in the Artifact. That is, these model elements are utilized in the construction (or generation) or the artifact.This association is a specialization of the clientDependency association.

Constraints

No additional constraints.

Semantics

An Artifact defined by the user represents a concrete element in the physical world. A particular instance (or `copy') of an artifact is deployed to a node instance. Artifacts may have composition associations to other artifacts that are nested within it.

For instance, a deployment descriptor artifact for a component may be contained within the artifact that implements that component. In that way, the component and its descriptor are deployed to a node instance as one artifact instance.

Specific profiles are expected to stereotype artifact to model sets of files (e.g. as characterized by a `file extension' on a file system). The UML Standard Profile defines several standard stereotypes that apply to Artifacts, e.g. «source», or «executable» (See the Appendix). These stereotypes can be further specialized into implementation and platform specific stereotypes in profiles. For example, an EJB profile might define «jar» as a subclass of «executable» for executable Java archives.

Notation

An artifact is presented using an ordinary class rectangle with the key-word «artifact». Alternatively, it may be depicted by a icon.

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



Changes from previous UML

The following changes from UML 1.x have been made: Artifacts can now manifest any PackageableElement (not just Components, as in UML 1.x). In UML 1.x,

CommunicationPath


A communication path is an association between two Nodes, through which Nodes are able to exchange signals and messages.

Description

In the metamodel, CommunicationPath is a subclass of Association.

Attributes

No additional attributes.

Associations

No additional associations.

Constraints
Semantics

A communication path is an association that can only be defined between nodes, to model the exchange of signals and messages between them.

Notation

No additional notation.

Changes from previous UML

The following changes from UML 1.x have been made: CommunicationPath was implicit in UML 1.x. It has been made explicit to formalize the modeling of networks of complex Nodes.

DeployedArtifact


A deployed artifact is an artifact or artifact instance that has been deployed to a deployment target.

Description

In the metamodel, DeployedArtifact is an abstract metaclass that is a specialization of NamedElement. A DeployedArtifact is involved in one or more Deployments to a DeploymentTarget.

Attributes

No additional attributes.

Associations

No additional associations.

Constraints

No additional constraints.

Semantics

Deployed artifacts are deployed to a deployment target.

Notation

No additional notation.

Changes from previous UML

The following changes from UML 1.x have been made: the capability to deploy artifacts and artifact instances to nodes has been made explicit based on UML 2.0 instance modeling through the addition of this abstract metaclass.

Deployment

Nodes

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

ComponentDeployments

A component deployment is the deployment of one or more executable artifacts or artifact instances to a deployment target, optionally parameterized by a deployment specification.

Description

In the metamodel, Deployment is a subtype of Dependency.

Attribute

No additional attributes.

Associations

Nodes

  • deployedArtifact : Artifact [*]
The Artifacts that are deployed onto a Node.This association specializes the supplier association.
  • location : Node [1]
The Node which is the target of a Deployment.This association specializes the client association.

ComponentDeployments

  • configuration : deploymentSpecification [*]
The specification of properties that parameterize the deployment and execution of one or more Artifacts.This association is specialized from the ownedMember association.

Constraints

No additional constraints.

Semantics

The deployment relationship between a DeployedArtifact and a DeploymentTarget can be defined at the "type" level and at the "instance level". For example, a `type level' deployment relationship can be defined between an "application server" Node and a "order entry request handler" executable Artifact. At the `instance level', 3 specific instances "app-server1" ... "appserver3" may be the deployment target for six "request handler*" instances. Finally, for modeling complex deployment target
models consisting of nodes with an composite structure defined through `parts', a Property (that functions as a part) may also be the target of a deployment.

Notation

Deployment diagrams show the allocation of Artifacts to Nodes according to the Deployments defined between them.





Changes from previous UML

The following changes from UML 1.x have been made: An association to DeploymentSpecification has been added.

DeploymentTarget


A deployment target is the location for a deployed artifact.

Description

In the metamodel, DeploymentTarget is an abstract metaclass that is a specialization of NamedElement. A DeploymentTarget owns a set of Deployments.

Attributes

No additional attributes.

Associations

Nodes

  • deployment : Deployment [*]
The set of Deployments for a DeploymentTarget.This association specializes the clientDependency association.
  • / deployedElement : PackageableElement [*]
The set of elements that are manifested in an Artifact that is involved in Deployment to a DeploymentTarget.The association is a derived association (OCL for informal derivation above to be provided).

Constraints

No additional constraints.

Semantics

Artifacts are deployed to a deployment target. The deployment target owns the a set of deployments that target it.

Notation

No additional notation.

Changes from previous UML

The following changes from UML 1.x have been made: the capability to deploy artifacts and artifact instances to nodes has been made explicit based on UML 2.0 instance modeling.

DeploymentSpecification

A deployment specification specifies a set of properties which 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.

Description

In the metamodel, a DeploymentSpecification is a subtype of Artifact. It defines a set of deployment properties that are specific to a certain Container type. An instance of a DeploymentSpecification with specific values for these properties may be contained in a complex Artifact.

Attributes

ComponentDeployments

Associations

ComponentDeployments

Constraints

[1] The DeploymentTarget of a DeploymentSpecification is a kind of ExecutionEnvironment.

[2] The deployedElements of a DeploymentTarget that are involved in a Deployment that has an associated DeploymentSpecification is a kind of Component (i.e. the configured components).

Semantics

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 standard tagged values that a profile might add to deployment specification are e.g. «concurrencyMode» with tagged values {thread, process, none}, or «transactionMode» with tagged values {transaction,
nestedTransaction, none}.

Notation

A DeploymentSpecification is graphically displayed as a classifier rectangle that is attached to a component artifact that is deployed on a container using a regular dependency notation is used. If the deployment relationship is made explicit (as in Figure 132), the Dependency may be attached to that relationship.


Changes from previous UML

The following changes from UML 1.x have been made: DeploymentSpecification does not exist in UML 1.x.

 Device

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.

Description

In the metamodel, a Device is a subclass of Node.

Attributes

No additional attributes.

Associations

No additional associations.

Constraints

No additional constraints.

Semantics

A device may be a nested element, where a physical machine is decomposed into its elements, either through namespace ownership or through attributes that are typed by Devices.

Notation

A Device is notated by a Node annotated with the stereotype «device».



Changes from previous UML

The following changes from UML 1.x have been made: Device is not defined in UML 1.x.

ExecutionEnvironment


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

Description

In the metamodel, a ExecutionEnvironment is a subclass of Node. It is usually part of a general Node, representing the physical hardware environment on which the ExecutionEnvironment resides. In that environment, the ExecutionEnvironment implements a standard set of services that Components require at execution time (at the modeling level these services are usually implicit). For each component Deployment, aspects of these services may be determined by properties in a
DeploymentSpecification for a particular kind of ExecutionEnvironment.

Attributes

No additional attributes.

Associations

No additional associations.

Constraints

No additional constraints.

Semantics

ExecutionEnvironment instances are assigned to node instances by using composite associations between nodes and ExecutionEnvironments, where the ExecutionEnvironment plays the role of the part. ExecutionEnvironments can be nested, e.g. a database ExecutionEnvironment may be nested in an operating system ExecutionEnvironment. Components of the appropriate type are then deployed to specific ExecutionEnvironment nodes.

Typical examples of standard ExecutionEnvironments that specific profiles might define stereotypes for are «OS», «workflow engine», «database system»and «J2EE container.

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

Notation

A ExecutionEnvironment is notated by a Node annotated with the stereotype «ExecutionEnvironment».


Changes from previous UML

The following changes from UML 1.x have been made: ExecutionEnvironment is not defined in UML 1.x.

InstanceSpecification (from Kernel, as specialized)

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.

Description

In the metamodel, InstanceSpecification is a specialization of DeploymentTarget and DeployedArtifact.

Attributes

No additional attributes.

Associations

No additional associations.

Constraints

[1] An InstanceSpecification can be a DeploymentTarget if it is the instance specification of a Node and functions as a part in the internal structure of an encompassing Node.

[2] An InstanceSpecification can be a DeployedArtifact if it is the instance specification of an Artifact.

Semantics

No additional semantics.

Notation

An instance can be attached to a node using a deployment dependency, or it may be visually nested inside the node.

Changes from previous UML

The following changes from UML 1.x have been made: the capability to deploy artifact instances to node instances existed in UML 1.x, and has been made explicit based on UML 2.0 instance modeling.

 Manifestation

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

Description

In the metamodel, a Manifestation is a subtype of Abstraction. A Manifestation is owned by an Artifact.

Attributes

No additional attributes.

Associations

Artifacts

Constraints

No additional associations.

Semantics

An artifact embodies or manifests a number of model elements. 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, e.g. <<tool generated>> and <<custom code>> might be two manifestations for different classes embodied in an artifact.

Notation

A manifestation is notated in the same way as an abstraction dependency, i.e. as a general dashed line with an open arrow-head labeled with the keyword <<manifest>>.

Changes from previous UML

The following changes from UML 1.x have been made: Manifestation is defined as a meta association in UML 1.x, prohibiting stereotyping of manifestations. In UML 1.x, the concept of Manifestation was referred to as `implementation' and annotated in the notation as <<implement>>. Since this was one of the many uses of the word `implementation' this has been replaced by <<manifest>>.

  Node

A node is computational resource upon which artifacts may be deployed for execution.

Nodes can be interconnected through communication paths to define network structures.

Description

In the metamodel, a 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 is a derived association in that these PackageableElements are involved in a Manifestation of an Artifact that is deployed on the Node. Nodes may have an internal structure defined in terms of parts and connectors associated with them for advanced modeling applications.

Attributes

No additional attributes.

Associations

Nodes

Constraints

[1] The internal structure of a Node (if defined) consists solely of parts of type Node.

Semantics

Nodes can be connected to represent a network topology by using communication paths. Communication paths can be defined between nodes such as "application server" and "client workstation" to define the possible communication paths between nodes. Specific network topologies can then be defined through links between node instances.

Hierarchical nodes (i.e. nodes within nodes) can be modeled using composition associations, or by defining an internal structure for advanced modeling applications.

Non-normative examples of nodes are «application server», «client workstation», «mobile device», «embedded device».

Notation

A node is shown as a figure that looks like a 3-dimensional view of a cube.



Dashed arrows with the keyword «deploy» show the capability of a node type to support a component type. Alternatively, this may be shown by nesting component symbols inside the node symbol.

Nodes may be connected by associations to other nodes. A link between node instances indicates a communication path between the nodes.


Artifacts may be contained within node instance symbols. This indicates that the items are deployed on the node instances.



Examples

Changes from previous UML

The following changes from UML 1.x have been made: to be written.

Property (from InternalStructures, as specialized)


A Property is extended with the capability of being a DeploymentTarget in a Deployment relationship. This enables modeling the deployment to hierarchical Nodes that have Properties functioning as internal parts.

Description

In the metamodel, Property is a specialization of DeploymentTarget.

Attributes

No additional attributes.

Associations

No additional associations.

Constraints

[1] A Property can be a DeploymentTarget if it is a kind of Node and functions as a part in the internal structure of an encompassing Node.

Semantics

No additional semantics.

Notation

No additional notation.

Changes from previous UML

The following changes from UML 1.x have been made: the capability to deploy to Nodes with an internal structure has been added to UML 2.0.