IBM
Contents Index Previous Next



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:

Figure 351 : A class with the stereotype « process »

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.

Figure 352 : The notation for a process

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.

Figure 353 : An inheritance relationship in the UML model will result in an inheritance relationship in the SDL model

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:

Figure 354 : Aggregation expressed in UML and the generated
SDL diagrams in the Organizer view

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.

Figure 355 : Communicating classes

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
Contents Index Previous Next