Table of ContentsTable of Contents 
Previous Chapter This application is chosen because it is a good example of an embedded system, with features that make it very suitable to be specified using SDL-92, and the new object oriented extensions.
The main characteristics of the system are:
Figure\x11 1 : X Window Interface to the AccessControl system. ----- (fig) -----
-------------------------------------------- Note: Only one code is allowed for each user card. --------------------------------------------
---------------------------------------------------- Note: Only one supervisor card is allowed for each system. ----------------------------------------------------
Figure\x11 2 : Class Symbol in OOA. ----- (fig) -----As seen in Figure 2, there are two different class symbols:
Figure\x11 3 : "is a"notation in OOA. ----- (fig) -----The whole/part of-structure is a notation to show how classes/instances are related to each other. The numbers indicates how many instances there can be of each class. The numbers in the example indicates that the class Whole can have 1 or many (1, m) instances of class Part2, but class Part2 can only be related to one instance of the class Whole (see Figure 4).
Figure\x11 4 : "Whole/Part of"notation in OOA. ----- (fig) -----
Figure\x11 5 : Instance Connections. ----- (fig) -----
Figure\x11 6 : Calling Services from other Services. ----- (fig) -----
We have used the later notation because it is very similar to the MSC (Message Sequence Chart) concept supported by SDT (see Figure 7).
Figure\x11 7 : A Scenario Described using an MSC. ----- (fig) -----
Figure\x11 8 : The OOA model of the AccessControl system
(Basic Version). ----- (fig) -----
Figure\x11 9 : Scenario OpenDoor. ----- (fig) -----
----------------------------------------------------------------- Note: The messages are OOA messages and cannot be mapped directly to SDL signals in the forthcoming SDL implementation. The SDL sig nal ValidateCode will be followed by a return signal (OK or NOK) from the RegisteredCard process. -----------------------------------------------------------------
Figure\x11 10 : System AccessControl with Time. ----- (fig) -----
-------------------------------------------------------------------
OOA SDL-92
-------------------------------------------------------------------
Class (no outer frame around Process type (alternatively ADT).
the object)
Class and object Process type (alternatively ADT)
and instances of this class in the
system.
Attributes Process variables.
Services Signals.
NOTE! The SDL-92 signal con
cept does not cover the whole ser
vice concept: most services returns
a value; a service can even contain
states!
External input/output Signals to the environment.
Create Formal parameters and start transi
tions in processes.
Connect (an implicit service) Signalling between processes to be
introduced to themselves.
Access (an implicit service) Can be implemented with
Export/import-view/revealed for
the reading of variables in other
objects, or ordinary assignments if
they are internal variables.
Groups Block types/block set.
Scenarios MSC diagrams.
Generalization/specialization Inheritance using specialization.
Whole/part of structure Block types/block sets to some
extent. Cardinality can be shown
both for blocks and processes.
Object relation Cardinality can be shown both for
blocks and processes.
Service charts Informal process descriptions to
describe a service.
-------------------------------------------------------------------
We have identified three blocks: LocalPanel, Doors and RegisteredCard (see Figure 11).
Figure\x11 11 : System Diagram AccessControlOOA. ----- (fig) -----
Figure\x11 12 : The Block Type LocalPanel. ----- (fig) -----
----------------------------------------------------------------------- Note: It is perfectly legal in SDL to use the same name for a block type and a process type because they are of different Entity classes (see Figure 13). -----------------------------------------------------------------------
Figure\x11 13 : The Block Type RegisteredCard. ----- (fig) -----
Figure\x11 14 : Data Type CardType and CardDbType. ----- (fig) -----An instance of the type CardDbType is declared in the process type RegisteredCard. The services ValidateCard, ValidateCode and RegisterCardAndCode for the class RegisteredCard are now implemented as operators for the data type CardDbType (see Figure 15).
Figure\x11 15 : Call of Operators inside the Process RegisteredCard. ----- (fig) -----
Figure\x11 16 : Procedure RegisterCard. ----- (fig) -----
This procedure is called both by the procedure RegisterCard and by the process Controller in the sequence of validating card and code (see Figure 17).
Figure\x11 17 : Procedure ReadCode. ----- (fig) -----
------------------------------------------------------------------------- Note: When a process calls a remote procedure, it enters a new implicit state where it will wait for an (implicit) return signal indicating that the procedure call has been executed. Any new signals, including calls to remote procedures, will be saved. This can easily lead to deadlock situations!!! -------------------------------------------------------------------------The ReadCode procedure can be placed in the KeyPad process and FlashMessage (another procedure also called by the RegisterCard) can be placed in the Display process.
Figure\x11 18 : Declaration of a Remote Procedure. ----- (fig) -----
Figure\x11 19 : Use of Value Returning Procedures. ----- (fig) -----In version 2 we have declared the procedure ReadCode as a value returning procedure, and it will return ReadCodeResult. We want to return this result from the procedure RegisterCard also, so we save it in a variable. (See Figure 18 on page 40 and Figure 19.)
The process Controller acts as an intermediate conveyer of the signal Display to the process Display in version 1. It is tempting to declare a global procedure that can send any message on the signal Display, and to call this procedure from process Display, process Door and the procedure RegisterCard. Unfortunately, this will not work. The reason is the above mentioned model with the creation of an implicit local model of the procedure. Calling the procedure from, for example, the process Door will in fact result in sending the signal from the calling process. Besides obscuring the signal sending, nothing will be gained by this; the signal must still be declared on the outgoing channel, etc. An alternative is of course to declare the procedure as an EXPORTED procedure and call it as a Remote procedure, but the remote procedure concept should be used with moderation and definitely not in this case, with the sole purpose of hiding signal sending.
In SDL-92, specialization of types can be accomplished in two ways:
Figure\x11 20 : The Block Type SpecialDoor. ----- (fig) -----The keyword INHERITS defines the new type SpecialDoor as a subtype of Doors. Except for that the process DoorOpener and the signal route DrLkDrOp are added, the contents of SpecialDoor are the same as the contents of Doors. The process DrLk is dashed in order to indicate that it refers to the DrLk defined in Doors.
Behavior (i.e. transitions) can be added to a process type using the same principle. For example, the process type TimeDisplay (Figure 21) is a subtype of Display with the addition of a new transition. The gates A and B are dashed in order to indicate that they refer to the gate definitions in the process type Display, with the addition of the signal DisplayTime.
Figure\x11 21 : The Process Type TimeDisplay. ----- (fig) -----In some cases it may be necessary not only to add properties, but also to redefine properties of a supertype. In Figure 20, the process type DoorLock has to be redefined in order to send the signals OpenDoor and CloseDoor respectively to the new process DoorOpener. Therefore, the corresponding transitions of DoorLock have to be defined as virtual transitions, as depicted in Figure 22.
Figure\x11 22 : The Process Type DoorLock with Virtual Transitions. ----- (fig) -----Then, in the definition of the new block type SpecialDoor, the corresponding transitions of the process type DoorLock are redefined as shown in Figure 23.
Figure\x11 23 : The Redefined Process Type DoorLock. ----- (fig) -----In addition to virtual transitions, it is also possible to specify start transitions, saves, continuous signals, spontaneous transitions, priority inputs, remote procedure inputs and remote procedure saves as virtual. Furthermore, a virtual save can be redefined into an input transition.
After an analysis of the problem, e.g. using OOA as described earlier, it is decided that the clock functionality is easiest realized by adding a clock to the local panel. Each minute the clock sends the current time to the controller, which displays the time on the display. Furthermore, the controller is extended to cope with the setting of the time from the key pad.
In order to apply the SDL-92 concepts of specialization to this problem, the original access control specification has to be slightly modified. Since an access control system containing a clock can be regarded as a specialization of the original access control specification, it must be possible to inherit the properties of the original access control system when defining the new system. Therefore, it is necessary that the original AccessControl system is defined as a system type (named BaseAccessControl), as depicted in Figure 24.
Figure\x11 24 : The System Type BaseAccessControl. ----- (fig) -----Since the specialization of BaseAccessControl requires changes to the block type LocalPanel, it is defined as virtual. For the same reason, the process types used in the block type LocalPanel (i.e. CardReader, Display, KeyPad and Controller) are all defined as virtual. Finally, for reasons of clarity, the definitions of process types that previously where made on the system level are now made in the block types where they are used.
Now, a definition of the access control system containing a clock (named TimeAccessControl) can be based on the system type BaseAccessControl, as depicted in Figure 25.
Figure\x11 25 : The System Type TimeAccessControl. ----- (fig) -----The system type TimeAccessControl inherits BaseAccessControl with the addition of a new signal DisplayTime, which is sent from the block Lp (of type LocalPanel) to the environment. Furthermore, the block type LocalPanel is redefined in TimeAccessControl; as depicted in Figure 26.
Figure\x11 26 : The Redefined Block Type LocalPanel. ----- (fig) -----LocalPanel is redefined to contain a process Clock which sends the signal DisplayTime to Cl (of type Controller) and receives the signal SetTime from Cl. Furthermore, Cl is extended to send the signal DisplayTime to Dl (of type Display), which in turn sends it on to the environment via gate C.
The redefinition of Display is straightforward. As depicted in Figure 27, a new transition for the signal DisplayTime is added.
Figure\x11 27 : The Redefined Process Type Display. ----- (fig) -----The redefinition of Controller (Figure 28 on page 53) involves two issues: the addition of functionality to treat the signal DisplayTime, and the addition of functionality to read a new time from the KeyPad and correspondingly set the clock.
Figure\x11 28 : The Redefined Process Type Controller. ----- (fig) -----To cope with the signal DisplayTime, a transition is added to every state that, upon receipt of DisplayTime, sends it on to the process Dl (via gate E). Furthermore, a transition for the signal ReadCode is also added to state Idle in order to realize the setting of the clock. If the key pressed on the key pad is "#" then the new time is read (in the procedure ReadTime). If the new time was read successfully, then the signal SetTime is sent to the process Clock.
Finally, the process Clock is defined as depicted in Figure 29.
Figure\x11 29 : The Process Clock. ----- (fig) -----The variable CurrentTime of type Time, holds the current time in minutes. Every minute (duration 60), a timer expires which causes the variable CurrentTime to be incremented by 1, and the signal DisplayTime to be sent to process Cl. Receipt of the signal SetTime causes the variable CurrentTime to be updated with the new value. Since the time outside process Clock (i.e. the parameter of the signals DisplayTime and SetTime) is represented as a charstring, there is a need for functions converting Time to Charstring and vice versa. These functions can be defined in the following way:
NEWTYPE TimeOperators
LITERALS Dummy;
OPERATORS
TimeToString : Time -> Charstring;
/* Converts time to Charstring. The result
is on the form 'HH:MM' */
/*#OP (B) */
StringToTime : Charstring -> Time;
/* Converts Time to Charstring. Assumes that
the Charstring is on the form 'HHMM'. */
/*#OP (B) */
/*#ADT (B)
#BODY
SDL_Charstring #(TimeToString)(T)
SDL_Time T;
{
SDL_Charstring result:=NULL;
int Hours, Minutes;
char tmp1[4], tmp2[4];
Hours = (T.s/60/60)%24;
Minutes = (T.s/60)%60;
tmp1[0]='V';
tmp2[0]='V';
sprintf(&(tmp1[1]),"%2ld",Hours);
sprintf(&(tmp2[1]), "%2ld",Minutes);
xAss_SDL_Charstring(&result,tmp1,XASS);
xAss_SDL_Charstring(&result,xConcat_SDL_Charstring
(result,xMkString_SDL_Charstring(`:')));
xAss_SDL_Charstring(&result,xConcat_SDL_Charstring
(result,tmp2));
result[0]='V';
if(Hours<10)
result[1]='0';
if(Minutes<10)
result[4]='0';
return result;
}
SDL_Time #(StringToTime)(C)
SDL_Charstring C;
{
SDL_Time T;
SDL_Charstring tmpstr;
tmpstr=xSubString_SDL_Charstring(C,1,2);
T.s = atoi(++tmpstr)*60*60;
tmpstr=xSubString_SDL_Charstring(C,3,2);
T.s = T.s + atoi(++tmpstr)*60;
return T;
}
*/
ENDNEWTYPE;
This page intentionally left blank
Table of Contents 
Next Chapter