**Sources:** http://www.omg.org/spec/UML/2.5 (Starting at PDF page 693)
# Introduction / Usage Scenarios
The **deployment diagram** is used to describe deployment relationships (often only called deployments) between _DeploymentArtifacts_ and _DeploymentTargets_, i.e. which _Target_ deploys which _Artifact_. We distinguish _instance_ and _type_ level deployment relationships (p. 694, first paragraph).
At instance level, the deployment is shown for actual instances of _Targets_ and _Artifacts_. Thus one uses the common notation _"instance : type"_ (analogous to the notation of the [sequence diagram](https://git.informatik.uni-kiel.de/ag-se/teaching-public/-/wikis/uml/sequence-diagram)) for _Targets_.
The type level deployment illustrates relationships between "kinds" or types of _Targets_ and _Artifacts_. Naming of _Targets_ and _Artifacts_ is done by using the type as name.
<br/>
The introduced (abstract) classes _DeploymentArtifact_ and _DeploymentTarget_ (elements of the meta model) are extended by _Node_ and _Artifact_ respectively. In terms of modeling particular deployment diagrams (as shown below), we are mostly talking about _Nodes_, _Artifacts_ and _CommunicationPaths_ (associations between _Nodes_ for exchanging signals and messages). The _Node_ class is once more extended by _Devices_ and _ExecutionEnvironments_. The _Device_ stereotype is used for physical machines such as a server upon which _Artifacts_ may be deployed. An _ExecutionEnvironment_ is as its name implies an execution (typically software) environment for deploying _Components_ in the form of the previously mentioned _Artifacts_ (p. 698, second paragraph).
# Obligations for the lectures / exercises and the final exam in "Softwaretechnik" (Tips for Modeling)
- Only use type level deployment diagrams, thereby we define a common ground and reduce the revision effort.
- Sometimes you will see greatly nested _ExecutionEnvironments_. The nesting itself is UML-conform, but may introduce more complexity, which might be redundant in many cases (such as operating systems). Thus, we ask you to stay close to the tasks. Furthermore, every _Artifact_ must be deployed inside of at least one _ExecutionEnvironment_.
- _Artifacts_ manifest [_Components_](https://git.informatik.uni-kiel.de/ag-se/teaching-public/-/wikis/uml/component-diagram). Use similar names for _Artifacts_ and _Components_, such that one can see the Manifestation relationships.
- _CommunicationPaths_ illustrate the connection between _Nodes_, i.e. _Devices_ and _ExecutionEnvironments_. Use a high-layer OSI model protocol (preferably layer seven) for this association and add detailed information in brackets (as shown below). Don't forget multiplicities / cardinalities.
# Deployments
Below, you can find an approach for modelling a deployment of the previously defined [component diagram](https://git.informatik.uni-kiel.de/ag-se/teaching-public/-/wikis/uml/component-diagram).
**Sources:** http://www.omg.org/spec/UML/2.5 (Starting at PDF page 693)
# Introduction / Usage Scenarios
The **deployment diagram** is used to describe deployment relationships (often only called deployments) between _DeploymentArtifacts_ and _DeploymentTargets_, i.e. which _Target_ deploys which _Artifact_. We distinguish _instance_ and _type_ level deployment relationships (p. 694, first paragraph).
At instance level, the deployment is shown for actual instances of _Targets_ and _Artifacts_. Thus one uses the common notation _"instance : type"_ (analogous to the notation of the [sequence diagram](https://git.informatik.uni-kiel.de/ag-se/teaching-public/-/wikis/uml/sequence-diagram)) for _Targets_.
The type level deployment illustrates relationships between "kinds" or types of _Targets_ and _Artifacts_. Naming of _Targets_ and _Artifacts_ is done by using the type as name.
<br/>
The introduced (abstract) classes _DeploymentArtifact_ and _DeploymentTarget_ (elements of the meta model) are extended by _Node_ and _Artifact_ respectively. In terms of modeling particular deployment diagrams (as shown below), we are mostly talking about _Nodes_, _Artifacts_ and _CommunicationPaths_ (associations between _Nodes_ for exchanging signals and messages). The _Node_ class is once more extended by _Devices_ and _ExecutionEnvironments_. The _Device_ stereotype is used for physical machines such as a server upon which _Artifacts_ may be deployed. An _ExecutionEnvironment_ is as its name implies an execution (typically software) environment for deploying _Components_ in the form of the previously mentioned _Artifacts_ (p. 698, second paragraph).
# Obligations for the lectures / exercises and the final exam in "Softwaretechnik" (Tips for Modeling)
- Only use type level deployment diagrams, thereby we define a common ground and reduce the revision effort.
- Sometimes you will see greatly nested _ExecutionEnvironments_. The nesting itself is UML-conform, but may introduce more complexity, which might be redundant in many cases (such as operating systems). Thus, we ask you to stay close to the tasks. Furthermore, every _Artifact_ must be deployed inside of at least one _ExecutionEnvironment_.
- _Artifacts_ manifest [_Components_](https://git.informatik.uni-kiel.de/ag-se/teaching-public/-/wikis/uml/component-diagram). Use similar names for _Artifacts_ and _Components_, such that one can see the Manifestation relationships.
- _CommunicationPaths_ illustrate the connection between _Nodes_, i.e. _Devices_ and _ExecutionEnvironments_. Use a high-layer OSI model protocol (preferably layer seven) for this association and add detailed information in brackets (as shown below). Don't forget multiplicities / cardinalities.
# Deployments
Below, you can find an approach for modelling a deployment of the previously defined [component diagram](https://git.informatik.uni-kiel.de/ag-se/teaching-public/-/wikis/uml/component-diagram).
