|
|
|
**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).
|
|
|
|
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 nodes and for example a .jar file for artifacts.
|
|
|
|
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.
|
|
|
|
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 the classes *Node* and *Artifact*. In terms of modeling particular deployment diagrams (as shown below), we are mostly talking about *Nodes*, *Artifacts* and *CommunicationPaths* (associations between nodes and artifacts for exchanging signals and messages). The node class is once more extended by *devices* and *executionEnvironments*. The device stereotype is used ... TODO
|
|
|
|
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* and *Artifacts* 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 and the final exam in "Softwaretechnik" (Tips for Modeling)
|
|
|
|
- Nur type level
|
|
|
|
- ExecutionEnvironment kann sehr fein granular geschachtelt werden indem neue Stereotypen dafür genutzt werden. In unserem Kontext nicht weiter notwendig.
|
|
|
|
- Wann Kommunikationspfad zwischen Env - Device, Device - Device, Env - Env?
|
|
|
|
- Komponenten werden als manifestierende Artefakte umgesetzt - Namenskonvention für Komponente -> Artefakt
|
|
|
|
|
| ... | ... | |
