SDL Tutorial
Introduction
This SDL tutorial provides a number of different approaches to learning SDL:
-
Overview of SDL
- follow this if you would like an overview of the language elements of SDL, with an example as illustration; this is organised according to what instances an SDL system consists of, how they are defined, how SDL systems are structured, how processes communicate, how subtypes can be defined and how data types may be defined. -
SDL by example
- follow this if you would rather see a complete example right away and have the language explained through this; this is organised as a top-down introduction where you start from a system diagram, through block diagrams, to process, service and procedure diagrams. -
SDL as an object oriented language
- follow this if you would like to learn how SDL elements correspond to the various elements of object orientation; this requires a minimal knowledge of object orientation, and you will learn what corresponds to objects, attributes, classes, subclasses, etc.
Behind all these perspectives on SDL lies a number of definitions of the various language concepts and most of the figures in the electronic form of this chapter will be sensitive for mouse clicks and provide the definitions of the language element you click at at in the diagrams.
In addition the Chapter provides you with a subset of the more formal definition of SDL. Whenever you in the electronic form encounter a text like this " Z.100 ", clicking on this will bring you part of the Z.100 correspondence to the topic you are reading.
Overview of SDL
SDL is used for specification of systems. This is done by making SDL systems that are models of existing or potential systems. SDL systems are specified by SDL system specifications.
As part of the modeling process, components of systems are identified and modeled by instances as parts of the corresponding SDL system. Categories and subcategories of components are in SDL represented by types and subtypes of instances.
An SDL system consists of a set of instances . Instances may be of different kinds:
- blocks containing other blocks (which in turn may contain other blocks) or processes;
- processes characterised by attributes in terms of variables and procedures and which exhibit behaviour in terms of Extended Finite State Machines;
- services being parts of processes, with the same properties as processes, but being executed as part of the containing process execution.
SDL system can be structured by various means. A system consists of a number of blocks connected by channels, each block may contain a substructure of blocks (to any depth) or it may contain process sets connected by signal routes .
Processes execute concurrently with other processes and communicate by exchanging signals ; or by remote procedure calls. Reception of signals and requests for remote procedures are the events that t rigger state transitions in the behaviour of processes. Services as part of processes execute one at a time like co-routines.
Variables are defined by means of data types :
- abstract data types that may be both predefined and user defined
- ASN.1 data types (according to a separate standard Z.105).
SDL specifications can be modularised by means of packages . A package is a collection of type definitions. Packages can be used in the definition of new packages and the definition of systems.
The primary instances of an SDL system are processes . A process may have attributes in terms of variables, it may have procedures, and it may have a certain behaviour.
A process type defines the properties of a category of process instances.
The process type diagram in Figure 1 is an example of a definition of a process type. Each Controller process will have:
a behaviour defined by states and transitions.
The process type is the central controlling part of an access control system, based on card codes and PIN codes. The behaviour of the Controller takes care of the communication with the user (via a panel), with the central unit (that does the actual validation), and it eventually opens the door (by means of the OpenDoor procedure).
Specifying behaviour: states and transitions
The behaviour of a process is described as an Extended Finite State Machine: When started, a process executes its start transition and enters the first state . The reception of a signal triggers a transition from one state to a next state . In transitions, a process may execute actions . Actions can assign values to variable attributes of the process, branch on values of expressions, call procedures , create new process instances and send signals to other processes.
Communication by means of sending signals is asynchronous: the sending process does not wait until the signal is handled by the receiver, and the receiving process will keep signals in a queue until it reaches a state in which it is prepared to handle it.
Figure 1 is an example on behaviour specification.
In a state (e.g. Idle) the process takes from the queue the first signal that is of one of the types indicated in the input symbols (here Code, containing information about the card id and PIN from the Panel). The Idle state is followed by one input symbol which describes the consumption of the signal Code. In the transition following the reception of the Code signal, it will use the variable cur_panel to remember from which panel the signal came from and then send the Code to the central unit for validation. The next state is Validation. In state Validation the Controller will only accept OK or NOK. If it gets OK it will open the door by calling the procedure OpenDoor.
P, D and U on the frame are gates : they define possible connection points for signal routes (see below) that connect specific process sets of this type. The signals (e.g Code) and signal lists (e.g. validity) define which signals may enter/exit through the connection point.
For more details on the constituents of a process type diagram see Virtual process type Controller .
Variables are declared according to data types. Each variable has a name and a data type. Controller processes as defined in Figure 1 have a variable cur_panel of type PId and two Integer variables cid and PIN.
The data type defines possible values, behaviour and operators that can be applied to values of the type. It is possible to define data types.
Predefined types include Character, Boolean, Integer, Natural, PId (Process Instance Identifier), and Real. Templates for defining arrays, strings and powersets are also provided.
Variables of type PId denote process instances, so cur_panel is a variable that denotes a process instance representing the panel that sent the Code signal.
Procedures as part of processes define patterns of behaviour that the process may execute at several places or several times during its life-time. The behaviour of a procedure is defined in the same way as for processes (that is by means of states and transitions), a process may have (local) variables, and in addition it may have IN, OUT, IN/OUT parameters.
Procedures are defined by procedure diagrams. The unlockDoor in Figure 1 is thus only a reference to a separate diagram defining the properties of unlockDoor.
For an example on a procedure diagram see Procedure diagram, GetPIN .
Communication by means of signal exchange
Processes execute concurrently and communicate asynchronously by sending signals. Each process has a queue of signals. The reception of a signal is the event that may get a processes to perform a transition from one state to another state.
In addition to signals, processes may also communicate by means of remote procedures. On the server side they are treated like signals (e.g. only accepted in states with an input of the procedure), while the client side will be blocked until the remote procedure has been executed.
Grouping of process sets by means of blocks
Types and instances of types correspond to the notion of classes and objects of class in object oriented languages. In addition SDL supports the what would correspond to the grouping of objects into larger units.
A block is a container for either sets of processes connected by signal routes, or for a substructure of blocks connected by channels. Each of these blocks may in turn consist of either process sets or a substructure of blocks. This decomposition may be applied to any depth.
There is no specific behaviour associated with a block, and blocks cannot have attributes in terms of variables or procedures. Therefore, the behaviour of a block is simply the combined behaviour of its processes.
A block type defines the common properties for a category of blocks. In Figure 2 a block type AccessPoint is defined by means of the process type Controller (and two other processes: Panel and Door, taking care of the communication with the actual physical panel and door).
Panel and DOOR are defined directly (there will be process diagrams for each of them and the process symbols with Panel and DOOR in Figure 2 are just references to these), while lsc is defined by the process type Controller. The symbol in Figure 2 with the name Controller is a reference to the corresponding process type diagram.
Processes are parts of process sets
Process instances are part of process sets. The specification of a process set includes the name of the set, the number of instances ( initial number and the maximum number of instances), and possibly the name of a process type . If no process type name is used, then the properties of the processes in the set are defined directly (in the corresponding process diagram). Omitting the number of instances implies that initially there is 1 element, and that the number of instances is unbounded. In Figure 2 there are three process sets of the special kind that initially has just one member:
Panel and Door are defined directly (that is the Panel and Door are references to separate process diagrams), while lsc is the name of a process set according to the Controller process type defined in Figure 1 .
Process sets are connected by signal routes
In order for processes to interact by means of signals, their sets have to be connected by signal routes. The signal routes and the associated signals (e.g. Code) and signal lists (e.g. validity) only specify possible signal exchanges.
When signal routes connect process sets according to process types, they connect to the gates defined in the types. In Figure 2 the gates P,D,U are the gates defined in Figure 1 .
The interaction between processes is specified on the signal routes connecting them, whereas a process type defines gates as connection points for signal routes. The process type Controller defines e.g. a gate P for the connection to Panels, with ingoing signal Code and outgoing signals defined by the signal list validity (OK, NOK). The constraints on the gates (in terms of ingoing and outgoing signals) allows the specification of the behaviour of process types without knowing in which context the instances of the type will be and how they are connected. Gates can only be connected by signal routes that carry the signals of the constraint, in the right directions.
The signal lists are defined below, see Figure 4 .
In addition to containing process sets or blocks, a block may have data type definitions and signal definitions. Signals being used in the interaction between processes in a block may therefore be defined locally to this block (providing a local name space) - here exemplified by opened, closed, open, close.
As described in Figure 2 an AccessPoint will have three concurrent processes, each taking care of different roles of the access point. If each of these roles would require more than one process, then they would be represented by blocks which in turn would contain the necessary processes. This is illustrated in Figure 3 , but is not used in the following.
The symbols with the names Panel, Door and Controller are block symbols, specifying that each AccessPoint block has three blocks as part of it, connected by channels.
As for signal routes, channels have associated signals (e.g. Code) and signal lists (e.g. validity) in order to specify possible signal exchanges in the corresponding direction.
Note the distinction between process types , process sets and process instances . Process types only define the common properties of instances, while process sets have a number of instances. Signal routes connect process sets and not process instances. Process instances are denoted by values of type PId. Process instances have variable attributes and behaviour.
Systems: set of blocks connected by channels
In order to provide a complete specification of a given access control system with a single central unit and a number (100) of access points according to the block type AccessPoint, a system diagram as in Figure 4 is specified.
A system consists of a set of blocks connected with each other and with the environment by channels . Note that channels connected to a block set according to a block type connect to the gates (e and C) defined in the block type.
The system specified in Figure 4 has interaction with its environment. The signals used for this purpose can be defined as part of the system (as in Figure 4 ) or as part of a package used in the system. The system assumes that the environment has processes which may receive signals from the system and send signals to the system.
For more details on constituents of system diagrams see System diagram, Access Control System .
Packages: collections of related types and definitions
Sets of related types may come as a result of a domain analysis (the types representing application specific concepts) or as a result of a specific system specification where the types are needed.
A package is a set of types. Types that are only used in one system will normally be defined as part of the system specification, but for convenience they may be collected and defined in a package and then used by the system. If a set of related types are to be used in many systems within a specific application domain, then a package is the right place to define the types.
In Figure 5 the signal types for the access control domain has been collected in the package SignalLib. Signals can be defined with parameters, as e.g. Code with two Integer parameters. This means that each Code signal carries two values of type Integer. The package also defines the signal list validity, inp and outp.
In Figure 6 the signal definition of SignalLib are made available by a use clause as part of a system diagram.
In a similar way, the block type AccessPoint in Figure 6 may defined in a package, possibly together with other types, instead of being defined in the system diagram.
For more details on constituents of packages see Package diagram, SignalLib .
In general a type in SDL can be defined as a subtype of another type (the supertype ) and thereby inherit the properties specified for the supertype. This holds for system, block process and service types, and for signals and procedures.
A general type intended to act as a supertype will often have some properties that should be defined differently in different subtypes, while other properties should remain the same for all subtypes. This is supported by virtual types and virtual transitions: these types and transitions can be redefined in subtypes. The behaviour of an instance of a subtype will follow the pattern given by redefinitions.
- inherits all definitions of the supertype and can add own definitions; these include definitions of variables, procedures, signals and type definitions;
- redefine virtual types and procedures defined as virtual types and procedures in the supertype;
- inherits states and transitions (for those types where this applies) and may redefine virtual transitions;
As an example on this, we define two new block types (BlockingAccessPoint and LoggingAccessPoint) as subtypes of the block type AccessPoint, as illustrated below.
They will inherit all properties of AccessPoint, but it is essential that they can redefine the Controller part:
- BlockingAccessPoint so that it can be blocked even for people with validated card and PIN codes, and
- LoggingAccessPoint so that these access points will log what is going on at the point.
Therefore the Controller process type in AccessPoint is specified as a virtual (process) type in Figure 7 and defined in the process type diagram in Figure 8 . Some of the input transitions are also defined to be virtual so that they can be redefined in redefinitions of the virtual process type.
For more details on constituents of block types see Block type diagram, AccessPoint .
For BlockingAccessPoint the virtual process type is redefined as indicated in Figure 9 and for LoggingAccessPoint as indicated in Figure 10 .
For more details on constituents of process type diagrams see Process type diagram, Controller .
The redefined virtual process type Controller in Figure 9 is given in Figure 11 . This also illustrates inheritance for process types and thereby inheritance of behaviour: the redefined process type inherits the properties specified in the virtual process type ( Figure 8 ) and the redefined process type adds the state "blocked" (with the corresponding input transition) and the input of "Disable" is added to all states (the * in the state symbol means all states).
The redefinition of the virtual process type Controller in Figure 10 is given in Figure 12 . The redefinition is finalised, so that it can not be further redefined. The two virtual transitions are also given finalised redefinitions.
Composing behaviour of processes by means of services
If it is known that a component of the system has separate activities, each with their behaviour and possibly with local variables like processes, and if they should not execute concurrently, then the component may in SDL by represented by a process that consists of services representing the activities.
As an example consider the Panel process, with CardReader, Keyboard, Display, and PanelControl as separate activities but not executed concurrently. This is specified in Figure 13 .
In addition to services, the combined process may have variables. Services in one process instance do not execute concurrently with each other; only one executes at a time. The next service to execute is determined by the incoming signal or by signals sent from one service to another. Services share the input queue and the variables of the enclosing process.
Note that the connection points CE and P1 on the frame in Figure 13 are not gates (the service diagram does not define a type of processes), but simply the names of the signal routes that connect Panel with the environment (CE) and with the Controller (P1), see Figure 2 .
The PanelControl service referenced in Figure 13 is defined by the service diagram in Figure 14 .
Specifying properties of variables: data types
As mentioned already processes and services have attributes in terms of variables , and procedures may have local variables. Variables are declared according to data types. Signals may carry values of data types.
SDL supports data types by means of abstract data type . A data type defines possible values, behaviour and operators that can be applied to values of the type. The properties of data types are defined by means of axioms. SDL supports predefined types including Character, Boolean, Integer, Natural, PId (Process Instance Identifier), and Real.
It is possible to define data types. This is done by defining the literals and the operators of the type. Abstract data types defines these by means of axioms. Operators may instead be defined constructively, that is more or less as a procedures.
As an example of a simple user-defined data type, consider the Code signal that contains a card identification and a personal identification number. Suppose that we find it desirable to collect those two pieces of data in one structured type. This is done by the STRUCT concept:
If AC is a variable of sort AccessCode then we may have the following assignments:
Templates for defining arrays, strings and powersets are also provided.
