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 you are in possession of a system developed using SDL-88 (and SDT 2.3), and now want this system to be maintained or further developed using SDT 3.X 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.
This chapter supplies a short a guide to how an existing SDL-88 system is maintained and evolved in an SDT 3.X 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 conceptswill 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.
|
Note: 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.X using SDL-92 concepts directly. This topic is discussed in Object Oriented Design Using SDL. |
All SDL-88 systems should adhere to the prerequisites described in Compatibility between SDL-88 and SDL-92, if they are to be managed using SDT 3.X, 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.X in the future).
In the rest of this chapter it is assumed that you are familiar with SDL-88 and have a basic knowledge about the building blocks in SDL-92. It is also useful to have some knowledge about object orientation in general.
It is possible to include an SDL-88 system evolved by an earlier version of SDT in SDT 3.X 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.X, 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.X, 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.X is used. This way, the benefits of the new tools in SDT 3.X may be appreciated, while the specification language is not necessarily changed.
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 42.
The Access Control 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:
Figure 42 : The Access Control system
|
|
All parts of the Access Control system shown in Figure 42 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.
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.
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.
In SDL-92, several concepts are considered to be types:
The word type is used in the following sense: a type is a definition that can be instantiated and does not necessarily imply object oriented features like inheritance and specialization.
Some of the most frequently used types in SDL will be explained and exemplified in the following parts of this chapter.
The Access Control system is shown in Figure 42, 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 43.
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 43 : Block PanelControl using a process
|
|
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.
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 44.
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.
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 44 : Process to process type
|
|
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 44 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 45 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 44.
Figure 45 : Gate definition in process type
|
|
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 46, 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 46 : Signal route vs. gate
|
|
The new version of the block PanelControl is shown in Figure 47, 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 47 : Block PanelControl using a process type
|
|
Note that the block PanelControl in Figure 43 behaves exactly as the block PanelControl in Figure 47, since what has been done so far has only increased the generality of the PanelController process without changing any of its intended behavior.
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.
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.
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 48.
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 48
: Inheritance of process type
In the left part of the figure, it is schematically shown how the process type PanelController is inherited by the process type PanelBlocker. In the right part of the figure it is shown how the inheritance is actually performed in SDL-92.
|
|
In section Types, 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 49.
Figure 49 : Adding signals to a gate
|
|
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 50.
Figure 50 : An added transition in PanelBlocker
|
|
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 51.
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 51 : A new state in PanelBlocker
|
|
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 52.
Figure 52 : A virtual transition in PanelBlocker
|
|
The process type PanelPartialBlocker is shown in Figure 53, 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 53 : Redefinition of virtual transition
|
|
At this stage several process types have been defined, and together they form a process type hierarchy as is shown in Figure 54.
Figure 54 : A simple process type hierarchy
|
|
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 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.
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 53) 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.
As is seen in Figure 53, 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 procedures, 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.
Regarding transitions, it is transitions or the lack of a transition that can be redefined. This means that the SDL symbols that can be marked as virtual, redefined or finalized are:
Furthermore, a virtual save can be redefined into an input transition or vice versa.
If a redefinition of a part of a transition is wanted, this can be achieved by a call of a procedure and a redefinition of the procedure.
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.
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 55.
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 55
: Different blocks
The block PanelControl contains one instance of the process type PanelController, while the block PanelBlock contains one instance of the process type PanelBlocker (which inherits the process type PanelController).
|
|
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.
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.
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 56.
This figure is almost identical with Figure 44, 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 56 : Block to block type
|
|
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, and the definitions are shown in Figure 57.
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.
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 57. 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 47 corresponds closely with Figure 57. 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):
The block PanelBlock was created in section Different Blocks, 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 58 the resulting block type is shown.
Figure 58 : Inheriting a block type
|
|
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 49), 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.
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.
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.
Another structural concept that can be defined as a type is the service. Services can be used to define partial behavior of a process. For certain situations this can reduce the complexity and increase the readability of a process specification.
Service types use the same OO concepts as block types and process types: Gates, inherits, virtual, redefined, finalized.
Figure 59 : Service to service type
|
|
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.
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 60, where two block types are defined, together with some signals and some signal lists that are used by the block types.
|
|
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 60 from the Access Control 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 61.
Figure 61 : The use of a package
|
|
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 62.
Figure 62 : Including a part of a package
|
|
A procedure is also 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.
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.
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 63 an example of a remote procedure call is shown (this example is not from the Access Control 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.
Figure 63 : Remote procedure call
|
|
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.X 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.