IBM
Contents Index Previous Next



Mapping Object Models to SDL Design Models


In SOMT object design, an important step is the transformation of (parts of) the analysis object model to an SDL system. This section describes this transformation.

There are several aspects important in the transformation:

The mapping to ASN.1 will also be discussed briefly.

Mapping an Active Object

Consider an object in the analysis model that has been found to be an active object. How should this be mapped into the design model? The default choice is to map this object as an SDL process type. The attributes of the object will then be mapped to variables and the operations will correspond either to remote procedures defined in the type or signals handled by the process type. As an example consider the DisplayInterface object in the Access control system. This object is responsible for interfacing a display that is capable of showing a line of text to a user. In the analysis object model this object may look like Figure 665. It has one attribute, Text, and one operation, Display.

Figure 665 : The DisplayInterface object

When mapped to an SDL diagram as a process type the result will be a process type reference, as shown in Figure 666.

Figure 666 : The DisplayInterface process type

Now consider the case where the Display operation was defined to be an asynchronous operation which is the default. If we now take a look at the DisplayInterface process type definition we can see that it has a variable called Text and a gate with the signal Display. This process type definition is shown in Figure 667.

Figure 667 : The DisplayInterface process type definition

If, on the other hand, the Display operation was defined to be synchronous (by giving the keyword sync after the operation name), then the definition of the DisplayInterface process type would now also be different. It would contain a definition of the Display remote procedure instead of a gate with a signal. See Figure 668.

Figure 668 : The DisplayInterface process type when mapped
to a process type with RPCs

When mapping an object like the DisplayInterface, the design issue of reuse shows up as a question of where to define the SDL object. If the DisplayInterface class is considered to be a general class that is to be reused in different projects or by different development teams, the most natural choice is to put the process type in a package that includes this type definition and other related types that are to be reused in different contexts. The design choice of what packages to use in a project was one of the issues of system design.

If the DisplayInterface only is intended to be used in this project but it is used in several of the blocks representing subsystems then there is also a possibility to put the process type on the system level. This would allow the type to be used in the entire system but it would not be convenient to use it in other projects.

If the DisplayInterface is only to be used within the local block it can be defined anywhere in the scope in question, even if it probably is a good idea to keep all process type references on one page in the block diagram.

Finally, if the DisplayInterface object is only to be used in one particular place in the system, it is possible to define it as a process directly where it will be used instead of as a process type. This would be done the same way that it was mapped to a process type except that a process would be generated instead of a process type. Sometimes this strategy is a good idea since it slightly reduces the complexity of the system, however it is only possible if the object is only used in one place in the system.

Mapping Active Objects with Inheritance

Inheritance among active objects is common in object models and is mapped directly to inheritance between the corresponding process types. For example, when mapping the EnglishDisplay object from Figure 669 to a process type, the result is as shown in Figure 670.

Figure 669 : Object model with inheritance

Figure 670 : Process type with inheritance

Mapping Aggregations of Active Objects

A fairly common structure is an aggregation with one assembly class that contains a number of other object classes, the part classes1. This is common for example when using container classes as abstract interfaces to a certain functionality. One example is given in a description of the software in one part of the access control system: the part that controls the access to one particular door in the building.

Figure 671 : An example of an aggregation of active objects

The most common mapping for this type of structure is to map the assembly class to a block or a block type, depending on the strategy for reuse that has been decided upon for the object.

One special, but fairly common, case is when the assembly object class contains attributes. In this case there are two possibilities: either the aggregation is considered as a "subsystem", in which case the attributes should be implemented by one of the parts classes, or the object should in addition to the mapping to a block (type) also be mapped to a process within the block that acts as a data server. This mapping follows the same principles as was discussed in section Mapping an Active Object.

Another possibility is that the assembly object class contains operations. This implies that these operations should be included in the interface of the block/block type. In the same way as when pasting as process types there is a design choice involved here. Are the operations intended to be synchronous remote procedures or are they asynchronous signals? In this case it is also important to define where the operations are to be implemented. Also in this case there are two choices: either the operations are implemented in one of the parts classes or a process is introduced in the block that handles the operations the same way a data server process handles the attributes.

As an example consider the analysis model in Figure 671. The block type DoorModule has both an attribute and an operation. A design counterpart for this is shown in Figure 672 and Figure 673. The process DoorModuleCtrl is the server process that handles the data and operations defined in the DoorModule analysis object.

The choice where to implement the operations and the attributes of the aggregate class is depending on the intended meaning with the aggregation. In SOMT the recommended practise is to use aggregation in object model that describes the architecture of a system as a "subsystem" or "parts vs. whole" relation, meaning the aggregate class is completely determined by its parts classes. In this case the operators and attributes of the aggregate class should be implemented by the parts classes.

Note that this is an example where the attributes and operations of the aggregate class DoorModule have been implemented by one of the part classes, the DoorModuleCtrl class.

Figure 672 : A block type reference for the DoorModule object

Figure 673 : A block type with a data/operations server process

If the object that is mapped to a block type is a subtype of another object in the object model, then the resulting block type will be defined as a subtype that inherits a block type that corresponds to the supertype in the object model.

Mapping State Charts to SDL Process Graphs

The principle of reusing as much information as possible of the information gained during the analysis activities when working in the design activities implies that an effort should be made to translate state chart descriptions into SDL process graphs. For a thorough description of the mapping rules please refer to: Converting State Charts to SDL.

State charts may be converted into SDL. Converting state charts without any hierarchical states is very straight forward, but converting a state chart containing hierarchical states requires flattening since the concept of hierarchical states does not exist in SDL.

The state chart LocalStation Figure 674 contain a hierarchical state with sub states and need to be flattened when converted to SDL.

Figure 674 : The State Chart Local Station

The behavior of the SDL process LocalStation Figure 675 is the behavior defined in the state chart LocalStation. The process is flattened and gives a straight forward view of the behavior. To increase traceability between the state chart and the SDL process the converter functionality provides comments on states and transitions which are related to any hierarchical state.

Figure 675 : The SDL process LocalStation

Mapping a Passive Object

A passive object is an object that does not have any thread of control or spontaneous behavior of its own. A passive object is often used to encapsulate a certain amount of information that is needed in the system. In the context of distributed systems it is often useful to classify the passive data descriptions into two broad classes depending on the way the data is used: external data and internal data

As will be seen in the next sections the mapping of passive objects to SDL data types is slightly biased towards the external data view of passive objects, the mapping to ASN.1 data types is very biased to external data view, and the mapping to C data types is slightly biased towards the internal data view of passive objects.

Mapping Objects to SDL Structs

In general, the SDL construct that can be used as the design representation for a class is an SDL STRUCT. This is exemplified in Figure 676 below.

Figure 676 : Mapping a passive object to a STRUCT type

In this mapping all attributes of the class are mapped to fields of the STRUCT.

Attribute Data Types

The attributes of a class may have data types associated with them. In general there are three ways to handle these data types:

As usual the choice is a matter of personal taste but should be directed by the general idea that the analysis model must be complete enough to be understandable by itself, but as small as possible to facilitate overview and ease of use.

The default mapping in SOMT is a simple literal mapping of whatever exists in the analysis model to the design model in SDL. See Figure 677.

Figure 677 : A data type mapping example

A special case which might be of interest in the analysis is when more complex data types like lists or sets are used. SOMT treats this type of data in the same way as elementary types are treated.

Mapping Operations

When a class is mapped to a data type in SDL there exists several ways to map the operations of the class. Operations could be mapped to:

The default mapping used by SOMT is to map operations to SDL operators with operator diagrams.

Operators Described by Operator Definitions

Operators described by operator definitions is the simplest choice. Consider the PersonInfo class as defined in Figure 678.

Figure 678 : A class with operations

This object has two operations: IncreaseAge and Retired which are intended to increase the age of the person with one, and to check if the person has reached the age where he/she has retired from his job.

Figure 679 shows how a mapping of operations to operator definitions can be done.

Figure 679 : Data type with operator diagrams implementing the class operations

Operators Described by Operator Diagrams

Operators described by operator diagrams is another alternative.

If a mapping to SDL is done using operators with operator diagrams, the SDL will look like in Figure 680.

Figure 680 : Data type with operator diagrams implementing the class operations

SDL Operators in General

Some things worth noting about SDL operators are:

A consequence of this is that an operator cannot both modify an object and return a result. The operators can thus be divided into two classes:

The modifiers are defined as:

ModOp: ObjType, P1type, P2type -> ObjType;

and used as

MyObj := ModOp( MyObj, p1, p2 )

An extractor would be defined as:

ExtrOp: ObjType, P1type, P2type -> ResultType;

and used as

Result := ExtrOp( MyObj, p1, p2 )

However, SOMT allows a way to overcome the third aspect above. If a C implementation is used as discussed below, the restriction that operators cannot modify the parameters is somewhat relaxed, since the data type itself can be defined using a pointer and then whatever is pointed at can of course be modified by the operator.

Operators Described Using C Code

The second mapping possibility for object model operations is to map them to SDL operators with C implementation. See Figure 681.

Figure 681 : Data type with C implemented operators

Procedures Described in SDL

The third way to implement operations of a class is to use SDL procedures. In this case the definition of the PersonInfo class would be like in Figure 682.

Figure 682 : Data type with procedure implementation of operations

Some differences when procedures are used compared to when operators are used:

Figure 683 : Procedure call symbol

External Procedures

The fourth way is to implement the operations as normal C functions. These functions correspond in SDL to external procedures. For example, to implement the IncreaseAge operation, one could have the following C function (the PersonInfo data type would have to be specified as a C type):

void IncreaseAge (PersonInfo *p)
{
  (p->age)++;
}

External procedures can be declared in text symbols, and they are called as if they were normal SDL procedures, as shown in Figure 684. Mapping Passive Objects to C gives more details about mapping operations to C.

Figure 684 : External procedures in SDL

Mapping Aggregations

A common situation is that the information used by a system has to be structured into some kind of tree structure. In the analysis this will appear as an aggregation hierarchy of passive objects. An example is shown in Figure 685.

Figure 685 : An aggregation of passive objects

If the PersonInfo object is mapped to a struct the aggregation would be visible in the design model as fields in the struct the same way attributes would be mapped. The mapping of the PersonInfo object from Figure 685 into an SDL diagram is shown in Figure 686.

Figure 686 : The SDL mapping of a passive object with aggregation

A common special case is when there is a multiplicity associated with the aggregation as in where one person can have more than one card.

Figure 687 : An aggregation with associated multiplicity

In general the multiplicity implies that there is a list or set of elements associated with the aggregation. There are several mappings to SDL possible, for example based on:

The default mapping in SOMT is a mapping to a type called "xxxList", where "xxx" is the name of the class. In Figure 688 the mapping of the PersonInfo type is illustrated.

Figure 688 : An SDL mapping an aggregation with multiplicity other than one

The "xxxList" type will then have to be designed separately. One simple way is to use an SDL string as in Figure 689 for the CardInfoList type.

Figure 689 : An SDL implementation of a list using the string generator

Another special case is given by recursive data structures that are used to describe tree structures. In Figure 690 a simple recursive tree is illustrated. In general this type of tree can of course also include a multiplicity other than one.

Figure 690 : A recursive object model

Due to the lack of pointers in SDL, this type of structure can normally not be defined in standard SDL-92. However, SDL tools may offer tool-specific pointer generators that can be used to represent the above tree. Figure 690 shows how the recursive data structure can be represented with help of the Ref pointer generator of the SDL Suite.

Inheritance

Inheritance in an object model is used to model "is-a" relationships. In practise the inheritance shows how attributes, operations and associations are inherited from a superclass to the subclasses. An example is shown in Figure 691 which models the fact that both the users and operators are persons.

Figure 691 : Inheritance relations

When mapping classes that inherit other classes to SDL data types there are three mechanisms that can be used:

Flattening means essentially that all operators, attributes and associations are copied from the superclass to the subclasses. In the example above this strategy would imply that the SDL representation of the User class might look like in Figure 692.

Figure 692 : Representing inheritance using flattening

Using delegation to represent inheritance is essentially to replace the inheritance hierarchy with aggregation hierarchies. When using this strategy the SDL representation of the classes in Figure 691 will be as illustrated in Figure 693.

Figure 693 : Using delegation to represent inheritance

When using the data types defined as in Figure 693, note that the syntax for accessing the attributes will of course show the delegation strategy used. For example, in order to access the name attribute of a User a construction like "uservar!person!name"" will have to be used.

SDL includes an inheritance concept for inheritance between data types. Unfortunately the inheritance between data types is an inheritance of operators only which limits the usefulness of the SDL inheritance. For more information about inheritance between SDL data types see Inherits.

Multiple inheritance implies that attributes, operations and association are inherited from more than one superclass as illustrated in Figure 694, that models the fact that a user is both a person and a card holder.

Figure 694 : Multiple inheritance example

When mapping classes with multiple inheritance to SDL both the flattening and delegation strategy works fine (except for name clashes when using the flattening strategy) but the SDL inheritance does not include multiple inheritance so it can not be used. In Figure 695 the delegation strategy is used to map the User class from the previous example to SDL.

Figure 695 : Mapping multiple inheritance using delegation

Delegation is the default mapping of inheritance used in SOMT.

Mapping Passive Objects to Signals

A special kind of passive objects in the analysis object model are the objects that are used only for communication, either between the system and its environment or between modules within the system. For example, when defining the use cases it is useful to show the relations among the events using an object model. It is especially useful if there are inheritance relations among the events as shown in Figure 696. The corresponding SDL signal definitions are shown in Figure 697.

Figure 696 : Object model describing communication events

There is often a choice of whether to map a passive object used for communication to a struct data type or to a signal. This is one of the design decisions that has to be taken during the object design.

Figure 697 : SDL signal definitions corresponding to the object model in Figure 696

Mapping Passive Objects to C

Passive objects can also be mapped to C data types and functions. In C, classes correspond to types, attributes of a class to fields in struct types, and operations to functions.

Figure 698 Mapping a passive object to C

Figure 698 shows a possible mapping of class PersonInfo to C. Note that in the mapping of the operations, a parameter is present to identify the PersonInfo object.

To represent aggregations in C, the same mechanisms as described in Mapping Aggregations can be used. When mapping inheritance to C, the flattening and delegation mechanisms described in Inheritance can be used.

When mapping associations to C, pointers are very powerful. Figure 699 shows an example of a one-to many association that is mapped to a linked list in C. Note how the role name has been used in the mapping.

Figure 699 Mapping an association to C

The SDL Suite has facilities to instantiate classes that have been mapped to C, and access their attributes and operations from SDL. This is described more detailed in Data Types.

Note:

Try to avoid pointers to data in other SDL processes! Data inconsistency will occur if the same data can be read/written by more than one SDL process at the same time. This can be achieved by avoiding pointers in parameters of signals and remote procedures.

Figure 700 shows an SDL fragment that uses the C types for PersonInfo of Figure 698. The CString2CStar operator converts an SDL Charstring to C's char *. Operations are called by means of SDL procedure calls. Note also the address operator `&' in the call to IncreaseAge.

Figure 700 Using C type PersonInfo in SDL

The choice between the SDL struct representation of classes and the C code representation is to some extent a matter of taste. There is a trade-off between simplicity and expressiveness. The SDL struct definition is very simple and all SDL based tools can completely analyze and manipulate this type of data. When using a C implementation, you take over some of the responsibilities from the tools. This means more work for you, but also a possibility to define in detail what you want.

Mapping Passive Objects to ASN.1 Data Types

An analysis object can also be mapped to an ASN.1 data type. The ASN.1 SEQUENCE construct corresponds best to a passive object with attributes. The most basic example is illustrated in Figure 701 below.

Figure 701 : Passive object mapped to ASN.1

The ASN.1 SEQUENCE can be compared with the SDL STRUCT, so most of chapter Mapping a Passive Object on mapping classes to STRUCTs is also valid for ASN.1. The few differences are treated here.

The largest difference is that ASN.1 has no possibility to specify operators. Therefore the operations of a passive object should be inserted in some dummy SDL type, while the attributes are mapped to a different ASN.1 type, as illustrated below.

Figure 702 : Passive object with operators mapped to ASN.1

The second difference is that ASN.1 has no concepts for inheritance. Therefore only flattening and delegation can be used to represent inheritance. ASN.1 has a special construct, COMPONENTS OF, that is useful to represent flattening. An example of this is given in Figure 703 below.

Figure 703 : The use of COMPONENTS OF to represent inheritance

The SDL Suite only allows use of ASN.1 in separate ASN.1 modules, that have to be included into SDL with the IMPORTS construct.

Mapping Associations

Associations are in object models used to represent relationships between objects of different classes. The instances of associations are called links. An example is given in Figure 704. In this example the association is a relationship between Cards and Codes that describes that a card must have exactly one valid code. In the object model this is represented by an association called Valid between the classes Card and Code.

Figure 704 : An example of an object model with associations

In the mapping to SDL, the information about the association is kept in one or both of the involved classes, in the example in Card, in Code, or in both.

There are several aspects of associations that are important to consider when mapping an association to SDL:

The rest of this section will discuss these issues and how they influence the mapping to SDL.

In general, associations form a graph structure among the objects where each object may have associations to a number of the other objects. Mapping associations to SDL implies in most cases that some kind of object references or pointers must be used.

In general, associations between active objects indicates that there is a possibility for the objects to communicate. In SDL this means that there must exist a communication path (signal routes and channels) between the corresponding SDL concepts (usually processes). In addition, an association between two active objects may also need to be represented by a PId variable in one (or both) of the processes.

There are however cases when PIds should not be used: as PId is a concept that only exists in the SDL world, associations with objects outside the SDL system cannot be represented with PIds. Instead, data types defined in protocols define how to refer to external objects. For example in the TCP/IP protocol, TCP services are addressed by a host address (for example 3.1.29.1) and a local port number. In an SDL implementation of a TCP service it would be impossible to refer to a service outside the SDL system by means of a PId; the host number and the port number must be used instead.

Since strict SDL does not include a pointer concept, associations with passive objects must be represented by other data types. Alternatively a C representation can be used when mapping the objects to SDL as discussed in Mapping Objects to SDL Structs.

There is one special case where there is no need for special data types. This is the case when the associations form a pure tree structure and furthermore all associations are one-way one-to-one associations with a traversal direction from the root to the leaves. In this case a strategy based on mapping classes to SDL structs can be used, i.e. a reference to an object is in SDL represented by the object itself.

Sometimes an association is implicitly represented in the class definitions themselves, which is called an intrusive representation. In this case the association does not have a representation of its own in the SDL model. For example, if the classes are represented by SDL structs then the association can be represented by a field in one (or both) of the structs. As an example the Valid association from Figure 704 is mapped in Figure 705 to a field in the struct that represents the Card.

Figure 705 : Mapping an association to a field in a struct

A non-intrusive representation of the association, on the other hand, does not rely on fields in structs that represent classes or any similar strategy. Instead the association is explicitly represented in SDL. A convenient way to accomplish this is to use the SDL array generator as exemplified in Figure 706.

Figure 706 : A non-intrusive mapping of an association using an SDL array

The design choice to make when choosing a mapping to SDL depends on the way it will be traversed in the application: is the traversal of the association always in one direction or is it traversed in both directions. This is usually not relevant in the analysis model but influences the SDL representation. For example if the Valid association in Figure 704 is a one-way association only traversed from the Card to the Code then the SDL representation in Figure 705 is all that is needed. If, on the other hand, the association is also traversed from the Code to the Card then the Code representation will also have to contain an element corresponding to the association (note that this requires a C implementation due to the lack of pointers in SDL) or alternatively a non-intrusive representation can be used.

The multiplicity of the association defines how many instances of one class can be associated with an instance of the other class. A one-to many association requires a list or set representation. This is essentially the same as an aggregation with a multiplicity greater than one, which is described in Mapping Aggregations.

Role names are an alternative that can be used instead of or in combination with association names. A role is one end of an association, and the role name uniquely identifies the object from the perspective of the object at the other end. An example is given in Figure 707 where the association is identified using role names instead of an association name.

Figure 707 : An association that uses role names instead of an association name

In many cases the role names are more convenient and less confusing than an association name. In a mapping to SDL it is preferred to use the role name as e.g. the name of a field in a struct rather than the association name. As an example consider Figure 708 where the Person object from Figure 707 is mapped to a struct in SDL and the role name is used as the field name.

Figure 708 : SDL mapping of a an association using the role
name instead of the association name

An association may have an associated class as illustrated in Figure 709.

Figure 709 : An example of an association class

The implication of this is that there are some attribute values and/or operations associated with each link of this association class that exists between the two objects. When mapping this construct to SDL there are two strategies: an intrusive representation and an explicit representation of the association class. If an intrusive strategy is used there is no explicit representation of the association so the attributes/operations must instead be associated to one of the objects involved in the relation. This strategy is possible only if at least one of the end points involved has the multiplicity "1". In the example in Figure 709 it would be possible to incorporate the association class into the Person object since there is only one company for each person in this model. A structured way to represent this in SDL is illustrated in Figure 710.

Figure 710 : The association class from Figure 709 mapped into
the Person object with an intrusive strategy

The second alternative is essentially to view the association class as a regular class and map it to SDL using any of the strategies that can be used to map regular classes to SDL. This is necessary for many-to-many associations.

The default mapping of associations between passive objects in SOMT is to use the intrusive strategy where classes are mapped to SDL structs and thus associations are mapped to fields in these structs. The name of the field in the struct is the corresponding role name if a role name exists, otherwise it is the association name. If there is no name specified for one of the roles and furthermore no name for the association, then no field is generated in the corresponding struct, and the association is considered to be a one-way association.

Summary of Mappings from Object Models to SDL

There are a number of possible SDL target concepts that an analysis object can be mapped to. The choice of target depends mainly on properties of the object:

1

Terminology (assembly and parts classes) after [21] the "Object Model Notation Basic Concepts"


http://www.ibm.com/rational
Contents Index Previous Next