Table of Contents Previous Chapter 2 Compatibility Notes

2 Compatibility Notes

In this chapter you can read about compatibility issues between the SDT 2.3 release and the SDT 3.0X release. The reason that there might be problems is that SDT 2.3 supports SDL-88, while SDT 3.0X supports SDL-92. SDL-92 is almost a superset of SDL-88. However, there are some areas where the language has been changed, which might make a valid SDL-88 system non-valid in SDL-92, or might change the behavior of the system. By just knowing some of the differences between SDL-88 and SDL-92, and avoiding some specific usage of SDL-88, it is fairly easy to work in the common subset of SDL-88 and SDL-92. In this way a user can obtain a very smooth transition from SDT 2.3 to SDT 3.0X. This chapter contains all the information currently known to us that is of any importance in this matter. The information concerns mainly the SDT Analyzer and the SDT C Code Generator, and is therefore of interest for systems that should be analyzed, simulated, validated, or used to generate an application.

Compatibility with respect to SDL

General Remarks

The sections below indicate differences between SDL-88 and SDL-92 that make a valid SDL-88 system non-valid in SDL-92, or that change the behavior of the system. The purpose of these sections is to express how a user can avoid problems in the transition between SDL-88 and SDL-92, by using a common subset of SDL-88 and SDL-92. None of the proposed restrictions are of any importance to express system behavior in SDL-88, rather they are very reasonable restrictions in the way of using SDL-88. The most important areas where the language have been changed are the semantics of output, import, and view.

---------------------------------------------------------------
Note:                                                            
This document is not an overview of differences between SDL-88   
and SDL-92. It only treats the compatibility aspects.            
---------------------------------------------------------------
The terminology used in this document is SDL-88. This means, for example, that the term "process type" should be interpreted according to SDL-88. The corresponding term in SDL-92 would be "process instance set."

Reserved Words

The following new reserved words are introduced in SDL-92:

any, at, atleast, connection, endconnection,
endoperator, endpackage, finalized, gate, interface,
nodelay, noequality, none, package, redefined,
remote, returns, this, use, virtual

To Avoid Problems

Do not use these words for any purpose.

Qualifiers for Predefined Data Types and Generators

The predefined data types and generators are the following:

boolean, character, charstring, duration, integer,
natural, pid, real, time, array, powerset, string
These types and generators are in SDL-88 implicitly defined among the declarations in the system. In SDL-92 these objects are defined in the package Predefined, which is implicitly "used" by all systems. This means that qualifiers used to select a predefined sort or generator have to be changed.

To Avoid Problems

Avoid qualifiers to indicate the usage of a predefined sort or generator. Such qualifiers are only needed if you introduce user-defined types or generators with the same name as one of the predefined sorts or generators.

New Operators in Predefined Sorts

The following new operators are introduced in the predefined sorts:

"mod"  : Integer, Integer -> Integer;
"rem"  : Integer, Integer -> Integer;
Chr    : Integer -> Character;
Num    : Character -> Integer;
"+"    : Duration, Time -> Time;
"*"    : Real, Duration -> Duration;
">="   : Duration, Duration -> Boolean;
"<="   : Duration, Duration -> Boolean;
"<"    : Duration, Duration -> Boolean;

To Avoid Problems

Try not to introduce operators with the same name and the same type algebra as any of the predefined operators, including the new operators above.

If you have an operator with the same name and the same type algebra as any of the operators given above you have two options when going to SDL-92. If your operator have exactly the same behavior as the new standard operator, you can just remove your operator. Otherwise, you have to introduce qualifiers at each place where you use the operator.

Service

Services have become a primitive concept in SDL-92 and a number of restrictions have thereby been possible to remove. However, there is one major language change that will make many services non-valid. The concept priority output has been removed from the language. The easiest way to handle this problem is to replace a priority output by an ordinary output to self.

In SDL-88 several services, in the same process, can have the same import specification. This is not allowed in SDL-92.

To Avoid Problems

Try not to have the same import specification in several services in the same process.

View

The view mechanism has been slightly changed in such a way that the viewed declaration only defines a local object in the viewing process. The PId value in a view expression is fully used to determine what revealed variable is intended. This means that qualifiers are no longer allowed in the viewed declarations.

To Avoid Problems

The best way to avoid problems is never to introduce more that one revealed variable with the same name within a block. In that case qualifiers are not necessary and should not be used.

If you for some reason need more that one revealed variable with the same name within a block, it will be necessary to remove the qualifiers in the viewed declarations when going to SDL-92. Note that you can have as many revealed variables with different names as you want.

Output

The most important difference between SDL-88 and SDL-92 is the improved semantics of outputs. However, this means that signals in some circumstances are send to different process types according to SDL-88 and SDL-92. This might occur if a signal is sent without TO and there are several possible process types that can be reached taking channels, signal routes, and a possible via list into account.

To Avoid Problems

Do not use OUTPUT without TO, if several process types can be reached from the sender, taking the possible via list and the channels and signal routes into account. Consider this example:

Figure\x11 1 : Example of Output. 
-----
(fig)  
       
-----
Assuming that process P outputs a signal S and that S can be conveyed by the paths in the diagram above (SR1, C1, SR2, and SR3), the following behavior can be expected:

This difference is not as bad as it first might look like, as the behavior defined in SDL-88 is really not possible to utilize. It is in general impossible to design some protocol involving Q1 and Q2, that can guarantee that exactly one instance of Q1 or Q2 is active at each time. There is thus a large risk of erroneous outputs in such situations. The potential problems that might arise when these kind of outputs are used are large enough to issue a recommendation not to use them, even for a user only interested in SDL-88.

There are other changes in the semantics of outputs as well. These changes are of lesser importance and conforms fairly well with the implementation of outputs in SDT 2.3. The list below gives all details:

  1. Output TO null, Output TO stopped process instances.
SDL-88: Output is in error
SDT2.3: Error message, Signal is lost
SDL-92: Signal is lost
SDT3.0: Warning, Signal is lost
  1. Output TO active process instance, but no path from sender to receiver according to via list, channels, and signal routes.
SDL-88: Output is in error
SDT2.3: Error message, Signal sent to receiver
SDL-92: Signal is lost
SDT3.0: Warning, Signal is lost          OR
        Signal sent to receiver anyhow.
See discussion after this list.
  1. Output TO active process instance, path from sender to receiver exists.
All   : Signal sent to receiver
  1. Output without TO, path exists from sender to one process type. Depending on the number of active process instances of this type:
SDL-88: =0  Output is in error
        =1  Signal sent to this instance
        >1  Output is in error
SDT2.3: =0  Error message, Signal is lost
        =1  Signal sent to this instance
        >1  Error message, Signal sent to one
            of the instances.
SDL-92: =0  Signal is lost
        >0  Signal sent to one of the instances
SDT3.0: =0  Warning, Signal is lost
        >0  Signal sent to one of the instances.
  1. Output without TO, path exists from sender to more than one process type.
SDL-88: Count the number of active process
        instances in all reachable process
        types. If this number is:
        =0  Output is in error
        =1  Signal sent to this instance
        >1  Output is in error
SDT2.3: =0  Error message, Signal is lost
        =1  Signal sent to this instance
        >1  Error message, Signal sent to one
            of the instances.
SDL-92: Select (at random) one of the reachable
        process types. If the number of active
        process instances in this type is:
        =0  Signal is lost
        >0  Signal sent to one of the
            possible instances
SDT3.0: =0  Warning, Signal is lost
        >0  Signal sent to one of the
            possible instances.
The case with an output TO an active process instance, where no path from the sender to the receiver according to via list, channels, and signal routes exists (case 2. above), will be handled with some care in SDT 3.0X. There are two conflicting requirements here:

It is possible for a user of SDT 3.0X to select behavior for the output discussed here.

Import

Import and export are in SDL a short-hand notation that is defined using signal sending. As the semantics for outputs have been changed, these changes, of course, also affect import and export.

To Avoid Problems

Do not introduce more than one exported variable with the same name, within the system. If you do not violate this rule, your imports and exports will still be valid in SDL-92.

If you have several exported variables with the same name in different process types, and all these variables are of the same type, you can avoid major problems if you always use a PId value in the import expressions to import these variables. You then only have to introduce a remote definition at, for example, the system level:

remote ExportedVariableName TypeName;
If you have several exported variables with the same name in different process types and these variables are of different types, you will have problems. You might have to insert qualifiers in each import expression, or you have to rename your exported variable to make the system valid in SDL-92.

Compatibility with Respect to Code Generation

The incompatibilities that affect the generation of C Code in SDT are described in chapter 34, The C Code Generator, section "Incompatibilities with SDT 2.3" on page 1965, in the volume SDT 3.01 Reference Manual.

Storage Format Compatibility

SDL-GR and MSC-GR

SDL diagrams and Message Sequence Charts stored in SDT 2.X format may be opened as is into the SDT 3.0X editors (using commands such as the SDL Editor's Open). To preserve the original diagram structure, they must however be imported into the Organizer tool, using the command Import Diagrams to build a diagram structure that may be stored on a System File.

When saving the SDT 2.X diagrams on file with the SDT 3.0X editors, a conversion to the SDT 3.0X format is performed.

Automatic conversion to SDT 3.0X storage format may also be performed automatically when importing the diagrams into the Organizer. The option Convert Diagrams is used for this purpose.

--------------------------------------------------------------------
Caution!                                                              
It is not possible to open the SDT 3.0X format in previous versions   
of SDT, e.g. SDT 2.3.                                                 
Make sure you have backup copies of your diagrams.                    
--------------------------------------------------------------------

Generated Simulators and Validators

Simulators and validators generated with SDT 2.3 will not execute as expected when executed under the SDT 3.0X Simulator Graphical User Interface.

Simulators and Validators should be re-generated. Use the Full Make facility to make sure all C files are re-generated properly.

Graphical Trace in SDL Editor

The SDL-GR trace in SDL Editors requires the SDL diagrams to be saved in order to function properly. (The reference mechanism in SDT-3 assumes the existence of information that is not stored on SDT 2.X files.)

 
Table of Contents Next Chapter