may be abstracted as
Part 11 - Implementation Diagrams
3.96 Deployment Diagram
3.96.1 Semantics
Deployment diagrams show the configuration of run-time processing elements and the software components, processes, and objects that execute on them. Software
component instances represent run-time manifestations of software code units.
Components that do not exist as run-time entities (because they have been compiled away) do not appear on these diagrams, they should be shown on component diagrams.
<<ejb Entity>>
C atalo g
<<auxiliary>>
C atalo gIn fo
<<focu s>>
C atalo g
< < re s id e > > < < re s id e > >
<<auxiliary>>
C atalo gPK
< < re s id e > >
<<file>>
C atalo gJAR
< < im p le m e n t> >
September 2001 OMG-UML , v1.4 Deployment Diagram 3-173 For business modeling, the run-time processing elements include workers and
organizational units, and the software components include procedures and documents used by the workers and organizational units.
3.96.2 Notation
A deployment diagram is a graph of nodes connected by communication associations.
Nodes may contain component instances. This indicates that the component runs or executes on the node. Components may contain instances of classifiers, which indicates that the instance resides on the component. Components are connected to other components by dashed-arrow dependencies (possibly through interfaces). This indicates that one component uses the services of another component. A stereotype may be used to indicate the precise dependency, if needed.
The deployment type diagram may also be used to show which components may reside on which nodes, by using dashed arrows with the stereotype «deploy» from the component symbol to the node symbol or by graphically nesting the component symbol within the node symbol.
Migration of component instances from node instance to node instance or objects from component instance to component instance may be shown using the «become»
stereotype of the dependency relationship. In this case the component instance or object is resident on its node instance or component instance only part of the entire time.
Note that a process is just a special kind of object (see Section 3.71, “Active object,”
on page 3-129).
3.96.3 Example
Figure 3-96 Deployment Diagram
3.96.4 Mapping
A deployment diagram maps to a static model whose elements include Nodes. It is not particularly distinguished in the model.
3.97 Node
3.97.1 Semantics
A node is a physical object that represents a processing resource, generally, having at least a memory and often processing capability as well. Nodes include computing devices but also human resources or mechanical processing resources. Nodes may be represented as types and as instances. Run time computational instances, both objects and component instances, may reside on node instances.
3.97.2 Notation
A node is shown as a figure that looks like a 3-dimensional view of a cube. A node type has a type name:
:D B Server
videoStoreServer:App Server
<<C o ntaine r>>
Vi d e o St or eAp plic atio n
:C lien t
<<b ro w s er >>
: Op e nS o u rc eB ro w s er
<<S e ss io n >>
S h op p in g Se ss io n
<<F o cu s >>
S h op p in g Se ss io n
<<E n tity>>
C at alog
<<F o cu s >>
C at alog
<<E n tity>>
S h op p in g Ca rt
<<F o cu s >>
S h op p in g Ca rt
<<d a tab a se >>
: Vid eo S to re D B
September 2001 OMG-UML , v1.4 Node 3-175 node-type
A node instance has a name and a type name. The node may have an underlined name string in it or below it. The name string has the syntax:
name ‘:’ node-type
The name is the name of the individual node (if any). The node-type says what kind of a node it is. Either or both elements are optional; if the node-type is omitted, then so is the colon.
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.
Component instances and objects may be contained within node instance symbols.
This indicates that the items reside on the node instances.
Nodes may be connected by associations to other nodes. An association between nodes indicates a communication path between the nodes. The association may have a stereotype to indicate the nature of the communication path (for example, the kind of channel or network).
3.97.3 Example
This example shows two nodes containing components, where a «become» flow shows the backupBroker migrating from the backupServer to the primaryServer while the other components remain in place.
Figure 3-97 Node and Component Instances
3.97.4 Mapping
A node maps to a Node.
A «deploy» arrow or the nesting of a component symbol within a node symbol maps into a residence metassociation between Component and Node. The nesting of a component-instance symbol within a node-instance symbol maps to a residence metaassociation between the ComponentInstance and the NodeInstance.
3.98 Component
3.98.1 Semantics
A component represents a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.
backupServer:AppServer
backupBroker :BondBroker
:QuoteService <<database>>
:AccountsDB primaryServer:AppServer
primaryBroker :BondBroker :QuoteService
<<database>>
:AccountsDB
< < becom e> >
September 2001 OMG-UML , v1.4 Component 3-177 A component is typically specified by one or more classifiers that reside on the component. A subset of these classifiers explicitly define the component’s external interfaces. A component conforms to the interfaces that it exposes, where the interfaces represent services provided by elements that reside on the component. A component may be implemented by one or more artifacts, such as binary, executable, or script files. A component may be deployed on a node.
3.98.2 Notation
A component is shown as a rectangle with two small rectangles protruding from its side. A component type has a type name:
component-type
A component instance has a name and a type. The name of the component and its type may be shown as an underlined string either within the component symbol or above or below it, with the syntax:
component-name ‘:’ component-type
Either or both elements are optional. If the component-type is omitted, then so is the colon.
Objects that reside on a component instance are shown as nested inside the component instance symbol. By analogy, classes that are implemented by a component may be shown as nested within it; this indicates residence and not ownership.
Elements that reside on a component are shown nested inside the component symbol.
The visibility of a resident element to other components may be shown using the same notation as for the visibility of the contents of a package (prepending a visibility symbol to the name of the package). The meaning of the visibility depends on the nature of the component. For a source-language component (such as program text), it would control the accessibility of source-language constructs. For a run-time code component (such as executable code), it would control the ability of code in other components to call or otherwise access code in the component.
3.98.3 Example
The example shows a component with interfaces and also a component that contains objects at run time.
Figure 3-98 Components
3.98.4 Mapping
A component symbol maps to a Component.
The graphical nesting of an element (other than a component symbol) in a component symbol maps to an ElementResidence metaassociation class between ModelElement and the Component. Graphical nesting of a component symbol in another component symbol maps to a composition association. The graphical nesting of an instance symbol in a component instance symbol maps to a residence metaassociation between Instance and ComponentInstance.
<<Entity>>
030303zak:Order
OrderHome
Order
OrderPK
<<Session>>
ShoppingSession ShoppingSessionHome
ShoppingSession
OrderInfo
<<focus>>
:Order
<<auxiliary>>
:OrderPK
<<auxiliary>>
:OrderInfo OrderHome
Order