Table of ContentsTable of Contents 
Previous Chapter 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.
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).
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.
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:
Figure\x11 30 : The AccessControl System. ----- (fig) -----
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.
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 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 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.
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.
The name field of the instance contains three objects:
Figure\x11 32 : Process to Process Type. ----- (fig) -----
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) -----
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) -----
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.
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.
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) -----
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:
.
Figure\x11 39 : A New State in PanelBlocker. ----- (fig) -----
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) -----
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.
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.
Basically, there are two kind of properties that may be redefined:
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.
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.
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) -----
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.
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) -----
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.
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.
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.
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.
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) -----
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:
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) -----
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
Next Chapter
