![]() |
![]() |
![]() |
![]() |
![]() |
The Deployment Diagram
In this section, the deployment diagram is described. The view and the symbols as well as drawing rules for the different integration models are explained.
In the Deployment Editor, it is only possible to use one page per diagram. This differs from the OM Editor, where an arbitrary number of pages can be used. See OM Editor Specific Information.
The View
The deployment diagram uses a view that is similar to the UML component view. The most important similarities are:
- Both views are type-based, i.e. no instance-specific information can be modeled. This implicates that the thread and object symbols in the Deployment Editor diagram can be regarded as stereotyped UML class symbols.
- Both views are static, i.e. partitioning at compile-time is modeled.
There are some important differences between the Deployment Editor view and the component view:
- The Deployment Editor view uses the node symbol, which is not used in the UML component view. In UML, the node symbol is only used in the deployment view.
- The Deployment Editor view does not support the interface notion, which is used for modeling communication between components in the UML component view.
The Deployment Editor diagram shows a static view of the partitioning, i.e. you can deploy SDL systems by how they look at compile-time.
The Symbols
The deployment diagram contains four symbols that can be used for modeling partitioning: Node, Component, Thread and Object. Each symbol is described in the following subsections. See About Symbols and Lines.
.
All symbols, except the thread symbol, contain information that can be edited in the Symbol Details dialog box. Properties and stereotype information are graphically visible on the symbols.
Node
A node symbolizes a computational resource, i.e. something with processing power and possibly some memory and other peripherals. A node should be seen as a platform on which software execute. Only components can be attached to nodes.
A typical stereotype for a node is a description of the processor and a common property is the operating system that is being used. Figure 324 shows a node called My_Computer with the stereotype PC and the property Windows NT 4.0.
For a node, you can set the stereotype to external, indicating that the node does not execute any code from your SDL system(s). This makes it possible to model external non-SDL parts that communicate with your SDL system(s). Setting the stereotype to external implicates that the node is ignored when building a Partitioning Diagram Model from the deployment diagram.
.
Stereotype and property information for a node is ignored when generating partitioning diagram data. The only exception is when stereotype is set to external.
Component
A component symbolizes an executable file, i.e. a sort of container for software entities. Components contain objects, i.e. SDL systems, blocks or processes, that are organized in threads of execution. You can attach either objects or threads to a component.
As for nodes, you can set external as stereotype on a component, which means that the component does not contain any SDL object from the system(s) that are deployed.
.
Stereotype and property information for a component is ignored when generating partitioning diagram data. The only exception is when stereotype is set to external.
For a component, you can select an integration model in the Symbol Details dialog box. The integration model reflects how the code that is generated is integrated with your target operating system. Three integration models are available:
See Integration Models for more information.
Thread
The thread symbol symbolizes a static thread of execution at compile-time. Threads can only be attached to components. Only objects, i.e. SDL entities, can be attached to a thread.
The thread symbol can only be used for modeling threaded integrations, i.e. for a Deployment Diagram with threads. Partitioning Diagram Data can only be generated if the component has "Threaded" as integration model.
You can make four settings for a thread through the "Symbol Details" dialog box. These are:
The settings are available to the Targeting Expert through the Partitioning Diagram Model. The settings are common among real-time operating systems.
The values that are entered are platform-specific and are used when compiling the system for your target environment. You are free to enter any value, e.g. a number or a macro, that makes sense in your target environment.
You can choose to either explicitly set a value, or leave it empty. Any setting that is not filled in is considered undefined. In that case, a default value is used.
Object
The object symbol is a general notion of an SDL system, block or process. The stereotype field is used to state the type of SDL symbol. This information is mandatory and has three possible values:
The stereotype value is shown within the object symbol. Figure 327 shows an object with process as stereotype.
For an object, it is mandatory to enter information in the Qualifier field in the Symbol Details dialog box. The qualifier consists of the path for an SDL object in the Organizer tree structure. `/' is used as a separator. The path must include the object name itself.
Some examples of object qualifiers for the AccessControl system are shown in the table below. You can verify the qualifiers by opening the AccessControl system in the Organizer (< SDL Suite installation directory>/examples/AccessControl/Accesscontrol.sdt) and comparing them with the entries in the table.
An example of an object with all mandatory information entered is given in Example 316.
Example 316 : Object Name, Qualifier and Stereotype
In the AccessControl system, the process Central in block CentralUnit has AccessControl/CentralUnit/Central as qualifier. For readability, the object is given the name Central. The stereotype is set to process.
Associations and Aggregations
The Deployment Editor diagram uses associations for modeling relations between nodes. Composite aggregation is used for the following relations:
There is a Line Details dialog box, which is common for all sorts of relations. For an association, you can model protocol, encoding and direction data. For a composite aggregation, only multiplicity data can be edited. For a more detailed description of the dialog box, see DP Editor Specific Information.
.
Associations between nodes are ignored when partitioning diagram data is generated.
Integration Models
The Deployment Editor supports three different integration models. The choice of integration model is set at component level.
Light Integration
In the light integration model, one or many SDL objects execute within one single task. The integration model is called Light in the Symbol Details dialog box.
The thread symbol is not used when modeling a light integration. All objects that should execute in a component with a light integration should be attached directly to the component. See Example 317 for an example of a light integration.
Example 317 : A Light Integration
This example (see Figure 328) shows a light integration containing two objects from the AccessControl system. All process instances run in one single task in one executable file. The objects are connected directly to the component, which has Light as integration model. The Control block has AccessControl/LocalStation/Control as qualifier and the DoorControl block has AccessControl/LocalStation/DoorControl as qualifier. Both objects have block as stereotype.
Tight Integration
In a tight integration, each SDL process instance is put in a task of its own. The number of tasks varies at run-time, as process instances are created and terminated dynamically.
As described in The View, the deployment diagram shows a static view of SDL systems at compile-time. The thread symbol symbolizes one static thread of execution, which makes it inappropriate for modeling tight integrations. Therefore, the thread symbol is not used for modeling tight integrations. Always attach objects directly to a component when you model a tight integration.
An example of a typical tight integration is shown in Example 318.
Example 318 : A Tight Integration
This example (see Figure 329) shows a tight integration where two processes from the AccessControl system are executing in one component. The component is deployed on a node.
Each process instance of the two SDL processes will execute in an OS task of its own on the target operating system.
The component has Tight as integration model (not visible in the figure). DoorController has AccessControl/LocalStation/DoorControl/DoorController as qualifier and process as stereotype. Controller has AccessControl/LocalStation/Control/Controller as qualifier and block as stereotype.
Threaded Integration
Using the threaded integration model, you can map an arbitrary number of SDL objects to an arbitrary number of threads. Each thread symbolizes a light-weight process in the executable file that is generated.
All objects that are connected directly to a component, having a threaded integration, are considered executing together in one implicit thread. Only default values for thread priority, stack size, etc. are available for an implicit thread.
The most common deployment case is that the smallest, indivisible entity is the process instance set. This is the smallest entity that can be graphically represented in a Deployment Diagram. However, it is possible to make each single instance of an object execute in a separate thread in the threaded integration model. This is modeled using multiplicity on the aggregation between a component and the thread that contains the SDL object. Set the multiplicity of the aggregation between the component and the thread to `*' to model this scenario. For a thread with `*' as multiplicity, the values of thread priority, stack size and queue size, etc. will apply to all threads that are created in the target environment.
A complete example of a threaded integration that illustrates the concepts is shown in Example 319.
Example 319 : A Threaded Integration
Figure 330 shows a component with many threads attached. The thread T has two objects (CentralUnit and PanelControl) attached to it. All process instances in these two blocks will execute within one thread. The component should execute on Windows 2000. Thus, Windows-specific thread settings are given. The following values are set: Thread Priority: THREAD_PRIORITY_ABOVE_NORMAL, Stack Size: 2048. The other fields are left empty, as default values should be used.
The Controller object is attached directly to the component and will thus execute in an implicit thread. If there were more objects attached directly to the component, they would execute in the same thread as Controller. As the thread is implicit, default values are used in the thread settings.
The thread T1 has `*' as multiplicity in the aggregation between itself and the component. This indicates that all process instances in objects attached to T1 will execute in a thread of its own. The thread settings for T1 are: Priority: THREAD_PRIORITY_BELOW_NORMAL, Stack Size: 1024. These settings will apply to all threads that are created.
All objects have stereotype and qualifier values set as shown in the previous examples.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |