In this chapter you can read about compatibility issues between the Telelogic Tau 3.4 release and the 3.5 release, as well as between the 2.3 release and the 3.X releases. It also describes the compatibility issues for the supported languages in ORCA1 and SDT.
This chapter concentrates on issues of storage formats and language support. For ITEX, this chapter describes how to upgrade an old ITEX database, and how to open an ITEX database with an old version of ITEX.
The FLEXlm Product License Keys that come with the Telelogic Tau products in version 3.5, 3.4, 3.3, 3.2, 3.1X and 3.02 are not compatible with license keys used in versions earlier than 3.02 of ITEX and SDT.
This means that you cannot run earlier versions of ITEX and SDT (i.e. 3.0 and 3.01) using the FLEXlm FEATURES in the license.dat file in the Telelogic Tau 3.5 distribution.
If you want to be able to switch between versions 3.0/3.01 of ITEX and SDT and version 3.5 of Telelogic Tau, you must do as follows:
license.dat file before updating it with the new FEATURES that come in the 3.5 Product License Key from Telelogic Customer Support.LM_LICENSE_FILE a value that designates the appropriate license.dat file before starting the tool set.Telelogic Tau 3.2 and later versions use the same license feature names both on UNIX and in Windows. This was not true for SDT and ITEX of versions 3.1X and earlier.
You may experience some problems trying to get the Windows version 3.1X of ITEX and SDT to run together with later versions. If so, please contact Customer Support for help (see How to Contact Customer Support in this volume).
Telelogic Tau 3.5 comes with version 6.1 of the FLEXlm license daemon (lmgrd). If you are using FLEXlm licensing for other products than Telelogic Tau, or if you plan to use two different versions of Telelogic Tau in parallel, you must use the latest version of the FLEXlm license daemon that you have received (version 6.1 or later).
For more information, see the FLEXlm FAQ at
http://www.globetrotter.com/flxlmfaq/chap3.htm
The following text concerns file name compatibility between UNIX and Windows using the Organizer in Telelogic Tau 3.3, 3.4 and 3.5, as compared to earlier versions. Therefore, it does not apply to ITEX tools in Windows.
The preference SDT*MixedPlatform (used in Telelogic Tau 3.2 and earlier versions) is no longer read by the Organizer. For systems using only relative paths, the Organizer now automatically converts file names between UNIX and Windows syntax, i.e. exchanging slashes and backslashes. The system file is always written in the format native to the platform used. Before version 3.3, the system file was always written in UNIX format.
For file names using absolute paths, the functionality of the Organizer's PC Drives dialog was extended in 3.3 to support general Windows paths instead of only drive letters, UNC paths (\\hostname\path), and quoted paths containing spaces. Files with absolute paths not found in the PC Drives dialog are presented in the Organizer as invalid diagram icons.
The special feature of always converting files to lowercase that the MixedPlatform preference used to provide must now be enabled separately, using the preference SDT* UseLowerCaseFileNames. This means that it is now possible to share systems between UNIX and Windows without forcing file names to lower case.
It is now possible to make Telelogic Tau handle file names containing spaces. This feature has to be explicitly turned on as the possibility of using this feature may depend on the support for spaces in file names in other tools and executables integrated with Telelogic Tau. Support for spaces in file names is controlled by the preference SDT* AllowSpaceInFileNames.
If you are sharing systems between UNIX and Windows, and want to manipulate system files without using the Organizer, do not assume that paths are always written in UNIX format.
The file format for system files (.sdt) has changed in Telelogic Tau 3.5 as compared to 3.4. Telelogic Tau 3.5 can read older system files (3.0X/3.1X/3.2/3.3/3.4), but previous versions of Telelogic Tau cannot read the new 3.5 system files.
When saving older system files with the 3.5 Organizer, a conversion to the new 3.5 format is performed.
The storage format for SDL and MSC diagrams did change in SDT 3.1X as compared to SDT 3.0X (and SDT 2.X). SDT 3.1X and later versions of SDT can read older files, but previous versions of SDT cannot read the new format introduced in the 3.1X version.
In addition, the storage format for MSC diagrams has changed in version 3.5. Version 3.5 of the MSC Editor can handle the same formats as version 3.4 of the editor, but version 3.4 and earlier of the MSC Editor cannot read the new 3.5 MSC format.
SDL and MSC diagrams stored in SDT 2.X and SDT 3.0X format may be opened as is into SDT 3.1X and later versions of the editors (using commands such as the SDL Editor's Open). To preserve the original diagram structure, you must however import them into the Organizer, by using the command Import SDL to build a diagram structure that may be stored on a system file.
When saving the opened SDT 2.X or 3.0X diagrams on file with SDT 3.1X and later versions of the editors, a conversion to the 3.1X format is performed. Conversion to the 3.1X format may also be performed automatically when importing the diagrams into the Organizer. The option Save imported diagrams in SDT3 format is used for this purpose.
Simulators and validators should be generated with the same version of SDT as they are supposed to be executed in. They might not execute as expected when executed under a SDT Simulator Graphical User Interface of a different version. To re-generate, use the Full Make facility to make sure all C files are re-generated properly.
The SDL-GR trace in the SDL Editor requires the SDL diagrams to be saved in order to function properly. (The reference mechanism in SDT 3.X assumes the existence of information that is not stored in SDT 2.X files.)
Existing applications that you have built using any of the Postmaster libraries from version 3.4 or earlier must be recompiled using the libraries supplied with version 3.5.
The storage format and syntax of Autolink test cases, constraints and configurations has changed in version 3.5 compared to version 3.4:
This section describes the different versions of the ITEX database formats and how they are converted to each other. The following table shows the what formats are used in each ITEX version:
When ITEX opens an old database, it checks if it is possible to convert the database to the current version via ITEX TTCN-MP format. A conversion program for this old database version must be available. The name of this program has a suffix which indicates the version number of the database. For example the program which is used to convert a database of version 2 is called mp-output-old2.
This program is installed in the ITEX 3.5 release. It is used to convert databases of version 2 to MP format. The resulting MP file is then converted to GR format as usual. This mechanism solves the problem of backward compatibility. A newer ITEX version can open an old version of the ITEX database.
A special problem occurs when an old ITEX version needs to open a new version of the ITEX database (forward compatibility). This problem is not relevant between database versions 0, 1 and 2 since the transfer format (MP) is the same. But the MP format which is used in 3.1 and later releases have extensions. Another problem occurs because the 3.1 and later databases are stored in a single file (compound format) with extension .itex instead of the .itex/.itex-tables combo of previous versions.
In ITEX 3.5, the database contains documents of one of these types:
Conversion of a new database of types Module or Package to an old 3.0x or earlier database is not possible. The only forward compatibility which is supported is for the databases of type Test Suite or Modular Test Suite.
This conversion mechanism is possible to retrofit into an older existing 3.X installation by copying the programs mp-output-old4 and
convert-to-old4 from the 3.5 installation's binary directory for the architecture(s) installed and put these copied files into the corresponding directory in the old 3.X installation tree (these files are present in the current release for primarily this reason).
To make a 3.0x version able to convert from 3.5 databases it also need the companion file with the extension .itex-tables to exist beside the 3.5 database file. Fortunately this file may be a dummy file containing nothing at all.
The SDL language support in SDT includes nearly all of SDL'92, as defined in the ITU-T Z.100 recommendation.
The main divergencies between the SDL supported in SDT and the Z.100 recommendation are:
More detailed limitations can be found in SDL Restrictions and SDL Editor.
The SDL Editor supports a few extensions to the SDL-GR notation:
SDT supports several new SDL concepts, some of which are defined in an addendum to the latest Z.100 Recommendation, known as SDL-96, and some others which are Telelogic-specific extensions to SDL. The extensions are supported in all relevant tools.
Other SDL-96 features are not supported in SDT.
The following extensions to SDL are Telelogic-specific. A detailed description of these extensions can be found in Data Types in SDT and Using SDL Extensions.
#UNION code generator directive (although #UNION is still supported for backward compatibility reasons).ctypes should be used.The MSC language support in ORCA includes full support for basic MSCs (MSC'93), and also parts of MSC'96, as defined in the ITU-T Z.120 recommendation.
The key points for the MSC'96 support in ORCA are:
Limitations to the MSC support can be found in UML and MSC Restrictions and MSC Editor.
The MSC Editor also supports a few extensions to Z.120:
The following words are reserved in MSC'96:
The reserved words may not be used as names/identifiers even if the MSC Editor does not support the corresponding language construct; this to avoid compatibility problems either when the editors support more of the MSC'96 language or if the MSC-PR is to be exported to other tools with a different subset of the language supported.
The following words are also treated as reserved words in the (H)MSC Editors but are mapped to (corresponding) MSC'96 reserved words.
| MCS'93 | MSC'96 |
|---|---|
|
instancehead |
instance |
This mapping is done to give old scripts and MSC-PR generators a chance to work.
The following reserved words are not supported by the (H)MSC Editors (i.e. they are treated as reserved words with respect to names/identifiers but the Editors have no support for the constructs that can be created with these words).
In addition, the Validator does not support the following reserved words:
Note that MSC-PR import in Telelogic Tau allows empty parameter lists and an empty duration name when setting a timer, due to backward compatibility. This is not in accordance with either MSC'93 or MSC'96.
The UML language support in ORCA is according to UML version 1.1 from September 1997, as defined in the OMG specification documents UML Notation Guide (ad/97-08-05) and UML Semantics (ad/97-08-04).
The following UML diagram types are not supported in ORCA (with references to sections in the UML 1.1 Notation Guide):
Static Structure (Class) diagrams and Statechart diagrams are supported in the OM Editor and the SC Editor, respectively. Limitations to these notations can be found in UML and MSC Restrictions.
The SC Editor also supports a feature from UML version 1.0 that is no longer defined in version 1.1:
One reason for SDL compatibility problems in SDT is that SDT 2.3 supports SDL-88, while SDT 3.X supports SDL-92. SDL-92 is almost a superset of SDL-88. However, there are some areas where the language has been changed, that make a valid SDL-88 system non-valid in SDL-92, or that change the behavior of the system.
The sections below indicate the important differences between SDL-88 and SDL-92. The purpose of these sections is to express how you 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 the sections below 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."
The following new reserved words are introduced in SDL-92:
Do not use these words for any purpose.
The predefined data types and generators are the following:
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.
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.
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;
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 has 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.
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 with 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.
Try not to have the same import specification in several services in the same process.
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.
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.
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.
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:
|
|
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:
SDL-88: Output is in error SDT2.3: Error message, Signal is lost SDL-92: Signal is lost SDT3.X: Warning, Signal is lost
SDL-88: Output is in error
SDT2.3: Error message, Signal sent to receiver
SDL-92: Signal is lost
SDT3.X: Warning, Signal is lost OR
Signal sent to receiver anyhow.
See discussion after this list.All : Signal sent to receiver
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.X: =0 Warning, Signal is lost
>0 Signal sent to one of the instances.
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.X: =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.X. There are two conflicting requirements here:
It is possible for a user of SDT 3.X to select behavior for the output discussed here.
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.
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.