![]() |
![]() |
![]() |
![]() |
![]() |
Transformation Rules
The transformation rules for UML static structure diagrams are described below. For information about the transformation rules applied when converting state charts, please refer to Converting State Charts to SDL.
General
To ensure traceability between the UML model and the SDL model, all mapped entities keep their name throughout the models.
An Organizer module is considered to represent a UML package. A module may contain several UML static structure diagrams. The module, including all UML static structure diagrams, is transformed into an SDL package or system.
Each SDL system or package will also contain a block type representing the architecture of the UML model.
Classes
The UML2SDL utility makes some basic assumptions about how a class should be interpreted in the SDL context. The basic approach is however to instruct the tool by using stereotypes. A stereotype is a meta classification of a class. The tool relies on the following stereotypes:
- A class with the stereotype «newtype» becomes an SDL newtype.
- A class with the stereotype «process» becomes an SDL process.
- A class with the stereotype «block» becomes an SDL block.
A class may have attributes and operations. Depending on how the class is interpreted, attributes become variables in a process, or fields in a struct. An attribute have a name and a type; the type may be omitted. The notation for the attribute is:
< name > [ `:' < type >]An operation has a name. It may also contain parameters and return values. An operation with a return value is translated to a remote procedure; otherwise it is translated to a signal. The notation of an operation is:
< name > [`(` { < parameter > [`:' < type > ] }* `)' ] [`:' < return value >]A UML static structure diagram may contain references to classes defined in other packages. Such classes are given the name according to the following notation:
< Name of external package > `::' < class name >Each externally defined class will generate a use clause, referring to the external package, in the generated SDL system or package.
Relations
Inheritance
Two classes connected with an inheritance relationship will generate an inheritance clause in the subtype. If two «process» classes are related by the inheritance relationship, there will be an inheritance clause in the process type representing the subclass.
Inheritance relationships between two «newtype» classes are not allowed due to limitations in SDL.
Aggregation
Two classes may be related by an aggregation. Depending on the context the following translations will be made:
An aggregation between a «block» class and a «process» class will place the process inside the generated block type:
An aggregation between a «process» class and a «newtype» class will place a variable of the newtype in the process. The newtype definition will be placed in the block containing the process.
Association
Two classes connected with an association will be transformed as two classes and connected with a signal-route and/or a channel depending on the context.
In Figure 355 above, two classes "Partner" and "otherProc" are connected by an association. In the generated SDL the two processes "otherProc" and "Partner" will exist in two separate blocks and they will be able to communicate through a channel and two signal routes.
State Charts
State Charts placed inside the module will be converted together with the other diagrams inside that module. The converter assumes that if a state chart has the same name as a process then the converter will try to merge the resulting SDL process behavior into the diagram of that process.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |