Table of Contents Previous Chapter 2 Transition from SDL-88 to SDL-92

2 Transition from SDL-88 to SDL-92

This chapter describes how a transition from an SDL-88 based system to an SDL-92 based system may be achieved. The viewpoint that has been taken is that a user is in possession of a system developed using SDL-88 (and SDT 2.3), and now wants this system to be maintained or further developed using SDT 3.0X in which SDL-92 is the supported language. SDL-88 and SDL-92 are not completely compatible, but if the points given in this chapter are followed there should not be any problems. Another intention of this chapter is to show that it is possible to gradually introduce SDL-92 concepts in a system that previously only contained SDL-88 concepts, and how this may be done. This is elaborated in section "Introducing SDL-92 in SDL-88 Based Systems" on page 63.

Introduction

This chapter supplies a short a guide to how an existing SDL-88 system is maintained and evolved in an SDT 3.0X environment in which SDL-92 has to be used.

The emphasis of this chapter is to show how to gradually introduce the object oriented concepts of SDL-92 in an existing SDL-88 system instead of rewriting the entire system from scratch.

Of course, the latter approach would most probably yield a better structured system, making full use of the advantages of SDL-92, whereas the first approach may be more cost effective, especially if the system is large.

It should not be expected, however, that a system in which object oriented concepts are merely added will turn out as it would have if the system had been developed according to some object oriented analysis method from the very beginning.

SDL-92 includes most language constructs of SDL-88, and the term SDL-92 concepts will be used to denote the parts that differ between the two languages. Many of these parts are object oriented, but there are also other important additions, the use of which will be exemplified in this chapter.

Prerequisites on SDL-88 Systems

All SDL-88 systems should adhere to the prerequisites described in "Compatibility with respect to SDL" on page 35 in chapter 2, Compatibility Notes, in the volume SDT 3.02 Release and Documentation, if they are to be managed using SDT 3.0X, since there are some incompatibilities between SDL-88 and SDL-92.

Existing SDL-88 systems should be modified to provide compatibility with SDL-92, while new SDL-88 systems being designed should be specified as to avoid incompatibility features already at the specification level (at least if it is possible that the system will be managed using SDT 3.0X in the future).

Assumed Reader Knowledge

In the rest of this chapter it is assumed that the reader is familiar with SDL-88 and possesses a basic knowledge about the building blocks in SDL-92. It is also useful to have some knowledge about object orientation in general.

Managing SDL-88 Systems in SDT 3.0X

It is possible to include an SDL-88 system evolved by an earlier version of SDT in SDT 3.0X without making any large modifications. The one thing that has to be stressed, though, is that the prerequisites mentioned in the previous section have to be abided by to avoid incompatibilities.

If the specified requirements are followed, there should be no problems to maintain the existing system in SDT 3.0X, or even evolving it, regardless of whether it makes use of SDL-88 only, or if SDL-92 concepts are also introduced.

Note that the system will automatically be considered an SDL-92 system when it is included in SDT 3.0X, but that it is still possible to treat it as an SDL-88 system, i.e., it is not necessary to make use of SDL-92 concepts just because SDT 3.0X is used. This way, the benefits of the new tools in SDT 3.0X may be appreciated, while the specification language is not necessarily changed.

Introduction to the Example

The AccessControl System

The examples in the following sections are mostly based on an Access Control system which has been defined in SDL-88 using SDT 2.3. This system has been chosen only to give a common basis for the examples, and all diagrams that are needed to understand the examples will be given in figures. A brief overview of this system is shown in Figure 30.

The AccessControl system controls the access rights for different users to a building or such by means of codes that are entered on a panel. The different parts of the system are as follows:

SDL-88 Entities

All parts of the AccessControl system shown in Figure 30 have a corresponding SDL-88 definition, except the doors and the panel containing the display, all of which are parts of the environment and not of the system itself.

The entities shown are all represented by blocks in SDL-88, and as such they must at least contain a process, but the contents will not be shown unless it is necessary to explain some concept or another.

Introducing SDL-92 in SDL-88 Based Systems

Introduction

The main intention of SDL-92 has been to include some mechanisms to allow for object oriented specification using SDL.

In most object oriented languages the term class is used to represent the classification of objects, while the objects themselves are instances of a class. Furthermore, it is possible to create new subclasses through specialization of already existing classes.

In SDL-92, however, the corresponding term is type, and objects are thus considered to be instances of types.

Types

One of the major differences between SDL-88 and SDL-92 is that services, processes, blocks, and systems are defined directly in SDL-88, whereas they may be defined using types that may later be instantiated in SDL-92.

One of the advantages of being able to use types is that it is possible to instantiate as many instances that are needed, but the greatest advantage is that types makes inheritance and specialization possible, which is a necessary feature when object orientation is to be achieved.

A type may be defined as a specialization of another type, in case of which the latter type is called the supertype, and the first type is called the subtype. A subtype inherits all properties defined by the supertype, and it is possible to add properties to the subtype, or to redefine properties of the supertype (all of which have been inherited by the subtype). Examples of this will be shown in later examples.

Not all types are intended to be instantiated. In fact, some types are created solely with the purpose of being supertypes to other types, encompassing common properties of the subtypes. This way entire type hierarchies are often created, especially if the objects are complicated or if there are several objects that are similar, but not quite identical.

Process Type

The AccessControl system is shown in Figure 30, and one of the blocks that is shown in that figure is the block PanelControl. This block manages the communication between the system and a user, and the structure of it is shown in Figure 31.

In some cases this block should be able to do more than what has currently been specified by the process PanelController, e.g., it should also be able to block all attempts to open the doors after closing hours. Even if such a task is added, the overall behavior of the process should not be altered.

There are several options when a new task is to be added to the process PanelController. It is, for example, possible to make the changes directly in the process, or a new process may be created by copying the old process and then adding the changes in the new process.

Figure\x11 31 : Block PanelControl Using a Process. 
-----
(fig)  
       
-----
Another way to add a task is to make use of the type concept of SDL-92, where the two previous methods are combined, sort of. The first thing that has to be done in that case is to transform the process PanelController to the process type PanelController.

In SDL-92 it is possible for one type to inherit another type, i.e., if a new process type is created and it is allowed to inherit the process type PanelController, it would be possible to simply add the changes to the new process type while the old one remains unchanged. Inheritance will be further discussed in "Specialization" on page 69.

Process to Process Type

The first step that is necessary is to transform the process PanelController to the process type PanelController. The previous process PanelController is then replaced by one instance of the process type, which is schematically shown in Figure 32.

These two ways of defining a process are equivalent, at least when the behavior is compared. The process type approach is more general, though, since all advantages of object orientation becomes available.

Instances

While the process type PanelController contains the definition of PanelController, Basic is an instance of the process type.

The name field of the instance contains three objects:

If more than one instance is created, the instances are referred to as a process set, but otherwise it is common enough to refer to the single instance as a process only.

Figure\x11 32 : Process to Process Type. 
-----
(fig)  
       
-----

Gates

There are two other symbols in the instance of the process type that have not been mentioned yet. These are E and C, and they signify gates.

A gate is defined as part of a type definition and is used to connect instances, or to connect an instance with the enclosing super structure, which in the case of an instance of a process type is a block, and in the case of an instance of a block is either another block or the environment to the system. The gate determines which signals the type is allowed to send or receive.

A gate for a block is a connection point for channels, while a gate for a process is a connection point for signal routes. It is also possible to connect an instance of a type to its SDL-88 counterpart, i.e., an instance of a process type may very well be connected to a process as it is defined in SDL-88.

In Figure 32 one gate has been created for each of the signal routes that lead to the process PanelController, all of which now lead to the instance of the process type PanelController. The gate E is used for all signals to and from the environment, and the gate C for all signals to and from the block Control.

A gate must thus be defined in the process type, and in Figure 33 the two different gates E and C are defined. When a connection is made to the instance of the type it is then necessary to state which gate that is intended, which is the reason the gate names appeared in Figure 32.

Figure\x11 33 : Gate Definition in Process Type. 
-----
(fig)  
       
-----

Via Signal Route vs. Via Gate

The transformation is now completed but for one tiny detail. In the process type Controller, some signals are sent via a signal route. This is no longer acceptable, since the process type itself knows nothing about the signal route, which means that the signals has to be sent via some gate instead (since the gate is aware of the signal routes it is connected to once an instance has been created).

The differences are highlighted in Figure 34, in which it can be seen that all that is actually needed is to replace the name of the signal route with the name of the gate to which the signal route is connected.

Figure\x11 34 : Signal Route vs. Gate. 
-----
(fig)  
       
-----

The Process Type Completed

The new version of the block PanelControl is shown in Figure 35, in which the process type PanelController has been created, and the process PanelController has been replaced by an instance of the process type PanelController, which is called Basic.

Figure\x11 35 : Block PanelControl Using a Process Type. 
-----
(fig)  
       
-----
Note that the block PanelControl in Figure 31 behaves exactly as the block PanelControl in Figure 35, since what has been done so far has only increased the generality of the PanelController process without changing any of its intended behavior.

Specialization

Assume that no one should be allowed to open any doors after closing hours, i.e., that the doors should be blocked at certain times. This is one of the tasks suggested above that would make the use of a process type useful, and in this section it will be shown how one process type may be inherited by another process type and then be specialized.

New Version of the Process Type

When a user inserts his card in the panel after closing hours, his card should be ejected immediately, followed by a message stating that the doors are closed.

A new version of the PanelController is thus needed, and two new signals are also needed, i.e. the signals Enable and Disable, both of which are issued by the CentralUnit at some predetermined time to achieve the blocking or unblocking of the doors. When the signal Disable is received by the PanelController the doors should be blocked, not to be accessible again until the signal Enable is received.

These signals are sent to the PanelController via the Control but none of these tasks will be shown since they only contain standard SDL-88 operations.

The new version of the process type PanelController is called the process type PanelBlocker.

Inheritance

The process type PanelBlocker should be able to perform all duties of the process type PanelController, but it should also be able to perform the new tasks. One way to achieve this is to simply let the process type PanelBlocker inherit the process type PanelController, and then add the new tasks to the new process type. How the inheritance is performed is shown in Figure 36.

All properties of a supertype (e.g. the process type PanelController) are inherited by the subtype (e.g. the process type PanelBlocker), including the gate definitions, which means that it is not necessary to make any new definitions of these parts.

Figure\x11 36 : Inheritance of Process Type.Figure legend: In the left part of the 
		figure,it is schematically shown how the process type PanelController is inherited by 
		theprocess type PanelBlocker. In the right part of the figure it is shown how the 
		inheritanceis actually performed in SDL-92. 
-----
(fig)  
       
       
       
       
       
-----

Adding Properties

In section "Types" on page 63, two different kinds of specialization were mentioned, adding and redefinition. The changes that have been discussed so far are all of the adding kind, while it will not be necessary to redefine any properties as yet. The adding of properties will be shown below.

First of all, there are two new signals to receive from CentralUnit via Control, i.e. the signals Enable and Disable. It is necessary to add these new signals to gate C, which is done according to Figure 37.

Figure\x11 37 : Adding Signals to a Gate. 
-----
(fig)  
       
-----
The arrow symbolizing a signal route is dashed to mark that the gate has already been defined somewhere else, which in this case is in the supertype PanelController, and the signals that are listed are to be added to the other signals that have already been defined.

The signal Disable may only be received in the state Idle (when there are no cards inserted in the panel), which means that it is necessary to add a new transition to this already existing state, where the state Blocked (see below) is entered when the signal is received. At all other states (except Blocked), the signal Disable should merely be saved, not to be acted upon until the state Idle occurs again. The new transition is shown in Figure 38.

Figure\x11 38 : An Added Transition in PanelBlocker. 
-----
(fig)  
       
-----
To manage the blocking aspects it is necessary to add an entirely new state, the state Blocked. Until the signal Enable is received it should not be possible to access the doors, and if a card is inserted while in this state it should be ejected immediately, and a message should be printed on the display that the doors are blocked. The new state is shown in Figure 39.

So far there have been three different kinds of additions of properties:

This list could easily be made longer by, for example, adding a new gate to an existing or a new entity in the system, or by adding a procedure to the process type.

.

Figure\x11 39 : A New State in PanelBlocker. 
-----
(fig)  
       
-----

Redefining Properties

For some reason or another it is perhaps not sufficient to just return the card to the owner when the panel is blocked. One might want to register the access attempt, or one may want to have some kind of partial access rights for the security staff even after closing hours. Any of these tasks would require a redefinition of some kind.

This is a different kind of specialization than the adding of properties that was discussed above, and it is called redefinition. Under certain circumstances it is possible to redefine an inherited property, and this is when the property has initially been defined as virtual. In that case the inherited property may be used as it has been defined, or it is possible to make the definition redefined.

Assume that the process type PanelBlocker is inherited by yet another new process type, the process type PanelPartialBlocker, in which it is possible for someone with the correct card to override the blocking mechanism. This a typical case of redefinition since the transition triggered by the input signal Card should behave differently in the two process types, while all other properties are identical.

The need for the new process type PanelPartialBlocker should ideally have been recognized at an earlier stage, so that no changes would have to be made in the process type PanelBlocker, but sometimes such precognition is not possible.

A property may not be redefined unless it is marked with the keyword virtual, and a redefined property in turn must be marked with the keyword redefined.

If a property is recognized as one which is liable to be changed in the future, it may as well be marked as virtual from the beginning so that the enclosing structure will not have to be changed. This resembles the methodology used when, for example, a virtual function is defined in a class in C++.

According to the above the process type PanelBlocker should be changed according to Figure 40.

Figure\x11 40 : A Virtual Transition in PanelBlocker. 
-----
(fig)  
       
-----
The process type PanelPartialBlocker is shown in Figure 41, in which it is seen how the virtual transition from the process type PanelBlocker is redefined to meet the new requirements.

The procedure OverrideBlocking only checks the card number to determine if the blocking should be overridden. How this is actually done is not relevant for this section, but the procedure itself has been defined as virtual to allow for other versions to be implemented if it is needed.

Figure\x11 41 : Redefinition of Virtual Transition. 
-----
(fig)  
       
-----

Process Type Hierarchy

At this stage several process types have been defined, and together they form a process type hierarchy as is shown in Figure 42.

Figure\x11 42 : A Simple Process Type Hierarchy. 
-----
(fig)  
       
-----
In this case each supertype only have one subtype, but it would not be difficult to find cases where a supertype is inherited by two or more subtypes. In fact, in the section "Redefining Properties" on page 72 it was hinted at other possible specializations - which would have been subtypes of the process type PanelBlocker - than the one that was actually implemented.

In this particular case, all process types may be instantiated and still be meaningful. Often a supertype in a type hierarchy is defined only to cover common aspects of several subtypes, and is not intended to be made an instance of.

Type hierarchies are formed to group together several objects or phenomena that have similar properties. Instead of making a new definition of a property for each type it is much more convenient to be able to define it only once and let it be inherited by those types that need it.

Finalized Redefinition

It is possible for a subtype to become a supertype of another subtype, which is exemplified by the process type PanelBlocker. This process type is a subtype of the process type PanelController, and at the same time it is a supertype of the process type PanelPartialBlocker.

There is no limit to how long an inheritance chain may be, and as long as a property is defined as virtual it is possible to redefine it. For this reason, a redefined property of a type is considered to be virtual in subtypes of this type, and may thus be redefined over and over again if needed. However, it is the original virtual property that is redefined and not the redefined property.

If a property should not be allowed to be redefined in a subtype there is another keyword that should be used instead of redefined, namely
finalized.

If the process type PanelPartialBlocker (see Figure 41) were to be inherited by another process type, it would be possible to make yet another redefinition of the transition which is triggered by the input signal Card.

However, had the transition been marked as finalized instead of redefined in the process type PanelBlocker, this would no longer be possible, since it has been explicitly stated that the transition should not be allowed to be changed in any subtypes.

Other Redefinitions

As is seen in Figure 41, it is not only input transitions that may be defined as virtual. The procedure OverrideBlocking has also been defined virtual, since it may be expected that the conditions for allowing the blocking to be overridden is going to be changed in the future.

Basically, there are two kind of properties that may be redefined:

The types that may be redefined in a system are service types, process types, and block types. It is, however, not possible to define a system type as virtual, and thus it is not possible to redefine it either. A procedure may also be defined as virtual, as has been seen above.

Among transitions it is not only input transitions that are allowed to be redefined, but also transitions such as start transitions and save transitions.

It is important to note that properties that are defined at the same level may not be redefined, which, for example, means that it is not allowed to redefine a virtual process type unless it is done in a subtype of an enclosing block type. It is, however, allowed to inherit it from another type defined at the same level.

Different Blocks

It is not a very good idea to have several process types that have a meaning of their own in the same block, since, for example, if a normal version of the block PanelControl is needed at the same time a blocking version of it is needed, there will be trouble. This is easily solved by introducing a new block, the block PanelBlock, in which the process type PanelBlocker is instantiated, while the process type PanelController is instantiated in the block PanelControl.

This approach will allow both variants to be used at the same time, but it requires that the process types are defined at the same levels as the blocks for the inheritance to work correctly. An outline of this situation is depicted in Figure 43.

Ideally, each of these process types should be placed inside their respective blocks, but then they would be invisible to each other, and inheritance would thus be made impossible.

It is also possible to create further blocks, such as a block in which the process type PanelPartialBlocker may be instantiated.

Figure\x11 43 : Different Blocks.Figure legend: The block PanelControl contains 
		oneinstance of the process type PanelController, while the block PanelBlock 
		containsone instance of the process type PanelBlocker (which inherits the process type 
		PanelController).
-----
(fig)  
       
       
       
       
       
-----
Note that this structure is not very good, since the different blocks will be almost identical. In the next section, a better structure will be shown which does approximately the same thing, but in a better way.

Block Type and Virtual Process Type

By now, the problem of having several similar processes has been solved by introducing process types and specialization, but instead several similar blocks have been created. It seems reasonable to assume that the same approach should work on blocks as well, i.e., the blocks that have been defined should be possible to express by using block types and specialization instead.

Block Type

If a simple example is chosen to begin with, the block PanelControl should be transformed to the block type PanelControl, as is shown in Figure 44.

This figure is almost identical with Figure 32, except that it is blocks instead of processes that are shown.

The transformation itself does not differ very much either, and is rather straightforward. Nothing will have to be changed in the block type but for the definition of the new gates, which will be shown in the section "Gates Revisited" below.

Figure\x11 44 : Block to Block Type. 
-----
(fig)  
       
-----

Gates Revisited

In the block type PanelControl it is necessary to define two new gates, EP and PC. These gates are defined in the same way as the previous gates were defined in section "Gates" on page 66, and the definitions are shown in Figure 45.

Previously, connect statements were used to connect the signal routes inside the block with the channels outside the block. This is now managed by the gates, which means that when gates are used, the connect statements have become obsolete.

However, if gates are not used (as for ordinary SDL-88 types) it is still necessary to use connect statements, since a gate only has meaning for a type or an instance of the type.

Virtual Process Type

Currently, several process types are defined through inheritance and used in blocks (or in the new block type) that instantiates the proper process types.

It would of course be possible to continue to use the process types that have been created so far, but another approach seems viable.

Suppose the process type PanelController is made virtual and defined inside the block type PanelControl, as has been done in Figure 45. If the block type PanelControl is then inherited by another block type, it will be possible to redefine the process type PanelController in that block type. This also means that it is no longer necessary to place the process type in the block LocalStation, but it may be placed where it is intended to be used, i.e. in the block type itself.

Figure\x11 45 : Block Type. 
-----
(fig)  
       
-----

Block vs. Block Type

Figure 35 corresponds closely with Figure 45. A block is shown in the first figure, while its block type is shown in the latter. The differences are (aside from the fact that one is type and the other is not):

  1. Two gates are defined in the block type.
  2. The signals have been placed in signal lists in the second version to reduce the text in the figure.
  3. The connect statements have been removed (since gates are used).
  4. The process type is defined as virtual.

Other Block Types

The block PanelBlock was created in section "Different Blocks" on page 76, but had the drawback that it was mainly a copy of the block PanelControl, except that it instantiated another process type.

If PanelBlock is defined as a block type instead, it is possible to let it inherit the block type PanelControl. As such it also inherits the process type PanelController, which has been defined as virtual and which is thus possible to redefine.

Before, a new process type (PanelBlocker), had to be created to supply the blocking mechanisms. This process type explicitly inherited the process type PanelController.

Now the old process type will no longer be needed since it is better to use the redefined process type PanelController instead. The redefined process type PanelController is defined exactly as the old process type PanelBlocker, though, since the virtual process type PanelController is implicitly inherited by its redefined counterpart.

In Figure 46 the resulting block type is shown.

Figure\x11 46 : Inheriting a Block Type. 
-----
(fig)  
       
-----
The dashed process symbol represents an instance of the redefined process type PanelController. It would not be needed, however, if the redefinition had not required new signals. As it is, the signals Enable and Disable will have to be added to the process type as they were for the process type PanelBlocker before (see Figure 37), but now they have also been placed in a signal list.

The new signal route is needed so that it is possible to send the signals between the gates PC and C. Note that it is not named like the signal route in the supertype because that would cause a name conflict.

The new signals also have to be added to the definition of the gate PC, and since this gate is inherited, the gate is dashed (the signals were added to the process type gate in a similar manner).

With that the new, inherited block type is ready. It is of course possible to continue to create new block types, e.g., a third block type may be defined to handle the case when only partial blocking was desired.

Block Types Revisited

Just like the process types were defined at a level higher than where they were instantiated, it would be desirable if the block types could be defined at one level higher than where they are instantiated, i.e., at the system level in this case.

Unfortunately, the block types depend on signals and signal lists that are defined in the block LocalStation, and it is therefore necessary to keep the block types where they are, unless these signals and signal lists are also moved to the higher level.

Virtual Block Types

It is also possible to create virtual block types, which are then redefined to other block types. This requires that the enclosing structure is either a block type or a system type. The latter case does not occur very frequently and will not be covered by this document.

The first case, however, may occur a bit more often, but is not very different from the cases of specialization that have been discussed above.

Packages

One of the most important new concepts in SDL-92 is that of packages. A package allows for a type definition to be used in several different systems, which is similar to the purpose of class libraries in C++.

Definitions as parts of a package define types, signal lists, synonyms, etc. It is possible to include either an entire package or specific definitions in a system, and once included these definitions appear as if actually defined in the system itself.

A package is included in a system through a use clause, and it may only be used in the definition of a system or of another package. This latter property of a package implies that it is possible to create a hierarchy of packages where the dependencies may be more or less intricate.

When a type is instantiated it is important that the channels or the signal
routes that are connected to the instance carry the correct signals according to the gates of the type.

Example of a Package

A package is a self-contained entity in which the definitions are made as in an ordinary system. An example of a package definition is shown in Figure 47, where two block types are defined, together with some signals and some signal lists that are used by the block types.

Figure\x11 47 : A Package. 
-----
(fig)  
       
-----
To create this package it is easiest to simply extract the definitions that is wanted from an existing system and then place them in the package. To create the package that is shown in Figure 47 from the AccessControl system it is appropriate to cut the definitions of interest from the system and then paste them into the package.

When all items of interest have been moved to the package the entire package is included in the system through a use clause as in Figure 48.

Figure\x11 48 : The Use of a Package. 
-----
(fig)  
       
-----
It is then possible to make use of the definitions in the package as if they were defined at the system level in the system itself. It is also possible to include only specific parts of a package by using the construction in Figure 49.

Figure\x11 49 : Including a Part of a Package. 
-----
(fig)  
       
-----

Procedures

A procedure may be considered a type, but contrary to all other types it does not have to be instantiated in order to be used. Procedures are possible to use in SDL-88, but they have to be defined at the same level at which they are called, i.e. global procedures are not allowed.

Global Procedures

In SDL-92, however, this restriction has been removed, and a procedure may be defined at any level in the system as long as it is only used at the same level it is defined or below, unless it has been defined as remote, which is also a new concept in SDL-92.

Remote Procedure Call

The primary use of a remote procedure call is when some information
is required from another process than the current and that information is confined in a limited scope. The remote procedure call is then a shortcut for sending a requesting signal to the process where the procedure is defined, calculating the response, and finally returning an answer with another signal.

The remote procedure call makes use of implicit signaling between the involved parties - which are often called client and server - which means that it is not necessary to define any channels or signals between the client and the server. The server is the entity in which the process is defined and the client is the entity in which the procedure is called.

The following things are necessary to realize a remote procedure call:

In Figure 50 an example of a remote procedure call is shown (this example is not from the AccessControl system). The procedure P is defined in block C, and is ordinarily not accessible from outside this block. By defining it as exported, it becomes possible to call the procedure P from block B, since it also declared as remote at a high enough level.

It would of course also be possible to define a channel between the client and the server, and then create a query signal which is sent from the client to the server. When a result is available a reply signal must then be sent to the client from the server. But, since the remote procedure call is a more convenient way to implicitly do all this, it may be preferred.

One drawback with the remote procedure call is that it is not possible to trace the implicit signals in a simulation or an MSC trace.

Figure\x11 50 : Remote Procedure Call. 
-----
(fig)  
       
-----

Discussion

This chapter has described some of the concepts that may be of use when SDL-92 concepts are to be gradually introduced in SDL-88 based systems.

The examples that have been presented are often based on a bottom-up method, which seems to be the natural way to change existing systems to include object oriented concepts.

The advantages of introducing SDL-92 gradually are that working parts does not have to be changed. It is possible to keep the SDL-88 structures that have been defined, and to add new structures defined in SDL-92. This is particularly valuable for already working larger systems, where it is too expensive to create a new version when some changes or additions have to be made.

When SDT 3.0X is used, it is of course possible to continue specifying systems in SDL-88 without ever using an SDL-92 concept, but then several benefits will be lost.

An elegant way to introduce additions in an SDL-88 system is to use packages, which may be defined using SDL-92 concepts. The packages are then included in the old system and used where they are needed.

Note that this chapter is not very useful when an entirely new system is to be created. In that case an OOA method (Object Oriented Analysis method) should first be used to determine the types (compare with classes in C++) that are needed, after which the design should be made in SDT 3.0X using SDL-92 concepts directly. This topic is discussed in chapter 1, Object-Oriented Design Using SDL-92.

This page intentionally left blank

 
Table of Contents Next Chapter