![]() |
![]() |
![]() |
![]() |
![]() |
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.
- In the first version of the Access Control system we will only use the new type concept for blocks and processes.
- In Version 2 we will make use of the new procedure concepts, such as remote procedures, value returning procedures and global procedures. We will also introduce the package concept, the specialization concept and the virtual concept.
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).
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).
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).
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).
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).
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:
- First it calls the procedure ReadCode to read the four user digits in the user's code.
- In the case of a successful return from the ReadCode (ReadCodeResult=Successful), send a request for the registration of a new card (signal RegisterCardAndCode) to the process RegisteredCard.
- Wait for the result of the Registration (return signals Registered or NotRegistered) and return (see Figure 12).
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).
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:
- This is the most natural place for it, because this procedure is called whenever a card is to be registered.
- 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.
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
- Declare it as EXPORTED in the procedure heading.
- Make an import procedure specification in each process/procedure that wants to call the remote procedure.
- 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.
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).
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
- To keep the transitions short in order to highlight the signal interactions.
- To describe local routines.
Remote and Value Returning Procedures
- To make a local routine globally accessible.
- Use value returning procedures to simplify expressions.
- Use remote procedure calls instead of signals to access and manipulate data.
Global Procedures
- An alternative to macros.
- An alternative to a remote procedure if there is no natural "owner" of the procedure.
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:
- A subtype may add properties not defined in the supertype. One may, for example, add new transitions to a process type1, add new processes to a block type, etc.
- A subtype may redefine virtual types and virtual transitions defined in the supertype. One may, for example, redefine the contents of a transition in a process type, redefine the contents/structure of a block type, etc.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 TimeOperatorsLITERALS Dummy;OPERATORSTimeToString : Time -> Charstring;/* Converts time to Charstring. The resultis on the form 'HH:MM' *//*#OP (B) */StringToTime : Charstring -> Time;/* Converts Charstring to Time. Assumes thatthe Charstring is on the form 'HHMM'. *//*#OP (B) *//*#ADT (B)#BODYSDL_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:
- Diagram types (system type, block type, process type, service type and procedure)
- Abstract data types and synonyms
- Signals and signal lists
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.
1SDL 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 |
![]() |
![]() |
![]() |
![]() |