|
|
**Sources:** http://www.omg.org/spec/UML/2.5 (Starting at PDF page 693)
|
|
**Sources:** http://www.omg.org/spec/UML/2.5 (Starting at PDF page 693)
|
|
|
|
|
|
|
|
# Introduction / Usage Scenarios
|
|
# 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 **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).
|
|
|
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 />
|
|
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.
|
|
|
|
|
|
|
|
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).
|
|
<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)
|
|
# 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*.
|
|
- Only use type level deployment diagrams, thereby we define a common ground and reduce the revision effort.
|
|
|
|
|
|
|
|
- *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.
|
|
- 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_.
|
|
|
|
|
|
|
|
- *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.
|
|
- _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
|
|
# 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).
|
|
|
|
|
|
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).
|
|
|
|
|
|
|
|
## Single server (black box) deployment
|
|
## Single server (black box) deployment
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<!-- ## Multi server (detailed) deployment
|
|
<!-- ## Multi server (detailed) deployment
|
|
|
 --> |
|
 --> |
|
\ No newline at end of file |
|
|
