|
|
**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 between *DeploymentArtifacts* and *DeploymentTargets*, i.e. which target deploys which artifact. The abstract types *DeploymentArtifact* and *DeploymentTarget* are extended by the classes *Node* and *Artifact*. In terms of deployment diagrams, we are mostly using *Nodes*, *Artifacts* and *CommunicationPaths* and don't consider those superclasses of the so-called meta model (this holds for every other diagram type as well).
|
|
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).
|
|
|
|
|
|
|
|
We distinguish *instance* and *type* level deployment relationships (l-d-r) (p. 694, first paragraph). Instance l-d-r show the deployment for actual instances of nodes, hence one shall use the common notation *"instance : type"* for all targets and artifacts. e.g. the server called *node1* uses the instance *tomcat
|
|
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.
|
|
|
|
|
|
|
|
<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
|
|
|
|
|
|
|
|
|
|
|
|
# Obligations for the lectures and the final exam in "Softwaretechnik" (Tips for Modeling)
|
|
|
|
- Nur type level
|
|
|
|
- Wann Kommunikationspfad zwischen Env - Device, Device - Device, Env - Env?
|
|
|
|
- Komponenten werden als manifestierende Artefakte umgesetzt - Namenskonvention für Komponente -> Artefakt
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
# Deployments
|
|
# Deployments
|
|
|
Below you can find two different approaches 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 two different approaches for modelling a deployment of the previously defined [component diagram](https://git.informatik.uni-kiel.de/ag-se/teaching-public/wikis/uml/component-diagram).
|
| ... | @@ -15,10 +25,3 @@ Below you can find two different approaches for modelling a deployment of the pr |
... | @@ -15,10 +25,3 @@ Below you can find two different approaches for modelling a deployment of the pr |
|
|
|
|
|
|
|
## Multi server (detailed) deployment
|
|
## Multi server (detailed) deployment
|
|
|
 |
|
 |
|
\ No newline at end of file |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
TODO (Besprechen):
|
|
|
|
|
- Specification- vs. Instance Level Deployment Diagram?
|
|
|
|
|
- Best practice: Wann Kommunikationspfad zwischen Env - Device, Device - Device, Env - Env (oder selbst definierten Stereotypen, die auf Nodes basieren)?
|
|
|
|
|
- Best practice: Komponenten werden als manifestierende Artefakte umgesetzt - Namenskonvention für Komponente -> Artefakt
|
|
|
|
|
|
|
|
