IBM
Contents Index Previous Next



Object Oriented Design of the Access Control System


System Design

The system design activity aims at producing a design architecture and to refine the use cases into use cases that could give a better help during the detailed design. Another purpose for refining the use cases is to make them suitable for verifying the design by means of the SDL Explorer functionality Verify MSC.

Since the goal of this methodology handbook is to describe the object oriented features of SDL during the design, the description of a complete system design has been left out.

Object Design

We will now introduce the new SDL concepts step by step.

Version 1: Block Types and Process Types

According to the analysis object model, the top class of the aggregation hierarchy has been mapped to an SDL system. The leaf nodes of the aggregation hierarchy have been mapped to processes and the classes between the top and the leave nodes have been SDL blocks. Note that even if there are no classes between the top class and a leave class in an aggregation chain, an SDL process still has to be contained in an SDL block.

Six processes (CardReader, Controller, Display, Door, KeyPad and RegisteredCard) have been identified from the analysis object model and three blocks (LocalPanel, Doors and RegisteredCard) have been created in order to preserve the structure described by the aggregation hierarchy of the analysis object model (see Figure 7).

Figure 7 : System diagram AccessControlOOA

Block Types and Process Types

A type definition can be placed anywhere in a system. For this example, the choice was to place them on the system level so that they will have maximum visibility. Normally, they would have been placed in separate packages to support parallel editing and analysis of the separate subsystems (block types).

To place a type at a high level (in a system or package) means that they can be instantiated anywhere where they are visible, and also be used for specialization anywhere in the system.

Block Type LocalPanel

Even if the types are placed on the same level, the structure is kept by instantiating the types according to the analysis object model. This means that the instantiation of the process types CardReader, Display, KeyPad and Controller is made inside the block type LocalPanel (see Figure 8).

Figure 8 : The block type LocalPanel

Block Type RegisteredCard

The block type RegisteredCard will only contain an instance of the process type RegisteredCard. 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 9).

Figure 9 : The block type RegisteredCard

The Classes CardDBType and CardType

As previously mentioned there are classes that will mainly contain data and data manipulation operations. The classes CardDBType and CardType are of this type and they are implemented in the design as abstract data types. The data type CardDbType has a number of operators defined to validate a card and a code, and to register a new card and a new code. These operators are implemented in-line, as "C" functions (see Figure 10).

Figure 10 : The data types CardType and CardDbType

An instance of the type CardDbType is declared in the process type RegisteredCard. The operations ValidateCard, ValidateCode and RegisterCardAndCode for the class RegisteredCard are now implemented as operators for the data type CardDbType (see Figure 11).

Figure 11 : Call of operators inside the Process RegisteredCard

Block Type Doors and Process Type Door

A requirement for the Access Control system is that it should be able to control up to four doors. In our object oriented SDL design, this can be accomplished by creating a block set of the block type Doors. The Synonym NOOFDOORS is by default 1 but can be assigned any value between 1 and 4. Block type Doors consists of an instance of the process type Door. To follow the OO analysis, the process type Door will control how long a door should be opened (attribute DoorTimeOut) and also the opening and closing of a door (operations OpenDoor and CloseDoor).

Version 2: Procedures, Specialization and Packages

A general rule when designing an SDL process is to keep the transitions as short as possible. Using procedures is often the solution.

The Use of Procedures in Version 1

In the first version procedures are frequently used and we shall now take a look at two of them, namely RegisterCard and ReadCode. Both are declared and called by the Controller process.

Procedure RegisterCard

This procedure is called when a new card should be registered (user cards or the supervisor's credit card). The function of this procedure is as follows:

Figure 12 : Procedure RegisterCard

Procedure ReadCode

This is a procedure to read four digits from the keypad. The digits read will be stored in an array named CodeData. If four digits are successfully received, the ReadCodeResult is assigned "Successful", and a return to the calling process or procedure will take place.

This procedure is called both by the procedure RegisterCard and by the process Controller in the sequence of validating card and code (see Figure 13).

Figure 13 : Procedure ReadCode

Remote Procedures and Value Returning Procedures

The idea in version 2 is to move the procedure RegisterCard from the process Controller to the process RegisterCard. There are two reasons for doing this:

  1. This is the most natural place for it, because this procedure is called whenever a card is to be registered.
  2. No signals have to be exchanged between process Controller and process RegisterCard to announce when to start and stop the registration procedure.

The procedure ReadCode must also be moved, because there will be a deadlock situation when the RegisterCard procedure calls the ReadCode procedure.

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.

Remote Procedures in SDL

Normally a procedure can only be called from the declaring process (or procedure) but by declaring it as EXPORTED it can be called from any process or procedure in the system. The remote procedure concept is modeled with an exchange of signals.

The Save Concept

The service process (the process with the EXPORTED procedure) can only handle a remote procedure call when it is in a state. If it is essential that a process is not interrupted with a remote procedure call in certain states, it is possible to use the SAVE symbol to save the call and handle it in a later state. This will mean that you cannot be sure that a remote procedure call will be handled directly. The model for the calling process is also that a new implicit state is introduced for each remote procedure call. The process will remain in this state until the remote procedure call is handled and executed.

How to Declare an Exported Procedure
  1. Declare it as EXPORTED in the procedure heading.
  2. Make an import procedure specification in each process/procedure that wants to call the remote procedure.
  3. Introduce the name and signature (FPAR) of exported and imported procedures by making a remote procedure definition. This could be done in the system diagram, in a block diagram or inside a package. This declaration determines the visibility of the remote procedure by placing it in a certain scope.

Figure 14 : Declaration of a remote procedure

Value Returning Procedures in SDL

Any procedure can be called as a value returning procedure provided the last parameter is of IN/OUT type. The recommended way is to declare it as value returning if it is intended to be used as such. A call to a value returning procedure can be used directly in an expression, e.g. in an assignment (see Figure 15).

Figure 15 : Use of value returning procedures

In version 2 we have declared the procedure ReadCode as a value returning procedure, and it will return a ReadCodeResultType value. We want to return this result from the procedure RegisterCard also, so we save it in a variable. (See Figure 15.)

Global Procedures in SDL

A procedure can also be defined globally in SDL. The conceptual model is that a local copy of the procedure is created in each process where it is called.

A Global Procedure for Sending a Signal

It is mostly the process Controller that displays messages. But the procedure RegisterCard (in process RegisteredCard) and the process Door also send messages.

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.

When to Use the Different Kinds of Procedures

Local Procedures
Remote and Value Returning Procedures
Global Procedures

Specialization: Adding/Redefining Properties

One of the major benefits of using an object oriented language is the possibility to, in a very simple and intuitive way, create new objects by adding new properties to existing objects, or to redefine properties of existing objects. This is what is commonly referred to as specialization.

In SDL, specialization of types can be accomplished in two ways:

Behavior (i.e. transitions) can be added to a process type using the adding mechanism. For example, the process type TimeDisplay (Figure 16) is a subtype of Display with the addition of a new transition. The keyword INHERITS defines the new type DisplayTime as a subtype of Display, stating that all definitions inside the process type Display is inherited by DisplayTime.

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 16 : The process type TimeDisplay

In some cases it may be necessary not only to add properties, but also to redefine properties of a supertype. In Figure 16, the process type Door has to be redefined in order to send the signals OpenDoor and CloseDoor respectively to the new process DoorOpener. Therefore, the corresponding transitions of Door have to be defined as virtual transitions, as depicted in Figure 17.

Figure 17 : The process type Door with virtual transitions

Then, in the definition of the new block type SpecialDoor, the corresponding transitions of the process type Door are redefined as shown in Figure 18.

Figure 18 : The redefined process type Door

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. All of the above concepts have in common that they define how a transition should be initiated or if it should be initiated (Save). Furthermore, a virtual save can be redefined into an input transition or vice versa.

Example: Adding a Clock to the Access Control System

The Access Control system described in the previous sections can be extended to contain a clock which holds the current time. The time is displayed on the display in the format "HH:MM", and the time can be set from the panel by first entering a "#" followed by the time in the format "HHMM".

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 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 Access Control system is defined as a system type (named BaseAccessControl), as depicted in Figure 19.

Figure 19 : The system type BaseAccessControl

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 20.

Figure 20 : The system type TimeAccessControl

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 21.

Figure 21 : The redefined block type LocalPanel

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 22, a new transition for the signal DisplayTime is added.

Figure 22 : The redefined process type Display

The redefinition of Controller (Figure 23) 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 23 : The redefined process type Controller

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 24.

Figure 24 : The process Clock

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 Charstring to Time. 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(r
esult,xMkString_SDL_Charstring(`:')));
xAss_SDL_Charstring(&result,xConcat_SDL_Charstring(r
esult,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;

Packages

The concept of packages enables a mechanism to handle a collection of different types. The different type definitions that are possible to define in a package are:

The definitions in a package are included into the system (or into another package) by a USE clause.

The SDL Analyzer supports semantic analysis for packages. This means that large systems can be divided into several packages to enable a more easy handling of large projects.

An important thing to remember is that it must be possible to analyze a type where it is defined. This means that if a process type is placed in a package, the data types and signals that the process type uses must also be visible in the package. In Figure 25, the use of packages are exemplified.

Figure 25 : The use of packages in the Access Control system

1

SDL differs from most other object oriented languages in the sense that SDL offers possibilities to specialize behavior specifications. In most other languages this is accomplished by redefining virtual methods in subclasses; in SDL this is easily accomplished by adding new transitions to a process type.


http://www.ibm.com/rational
Contents Index Previous Next