PDF of this tutorialTheoretical Model
The basic theoretical model of an SDL system consists of a set of extended finite state machines (FSMs) that run in parallel. These machines are independent of each other and communicate with discrete signals.
An SDL system consists of the following components:
- structure—system, block, process, and procedure hierarchy
- communication—signals with optional signal parameters and channels (or signal routes)
- behavior—processes
- data—abstract data types (ADT)
- inheritance—describing relations and specialization
The following subsections introduce the basic concepts.
Structure
SDL comprises four main hierarchical levels:
- system
- blocks
- processes
- procedures
Figure 2. The Structural View of an SDL System
Dividing a system into a system, block, and process hierarchy is called partitioning a system. The objectives of partitioning include the following:
- hiding information (move details not important in an overview to lower levels)
- following natural functional subdivisions
- creating modules of intellectually manageable sizes
- creating a correspondence with actual software or hardware
- reusing already-existing specifications
Each SDL process type is defined as a nested hierarchical state machine. Each substate machine is implemented in a procedure. Procedures can be recursive; they are local to a process or they can be globally available depending on their scope. SDL also supports the remote procedures paradigm, which allows one to make a procedure call that executes in the context of another process.
SDL processes have separate memory spaces (i.e., data is local to a process or procedure). This is a highly important aspect that dramatically reduces the number of deficiencies and increases robustness.
A set of processes can be logically grouped into a block (that is, subsystem). Blocks can be nested inside each other to recursively break down a system into smaller and maintainable encapsulated subsystems. These break-down mechanisms are important for large team development efforts, and SDL simplifies this by also providing clear interfaces between subsystems.
Static and Dynamic Structure
The static structure of a system is defined in terms of blocks and channels. A block is perceived as a module with the well-known black box model.
The dynamic structure is defined with the help of the process and the signal route concepts. A process is an independent device that reacts to stimuli in the form of signals (the process concept is described more fully in the Behavior subsection).
Communication
SDL does not use any global data. SDL has two basic communication mechanisms: asynchronous signals (and optional signal parameters) and synchronous remote procedure calls. Both mechanisms can carry parameters to interchange and synchronize information between SDL processes and with an SDL system and its environment (e.g., non–SDL applications or other SDL systems).
SDL defines clear interfaces between blocks and processes by means of a combined channel and signal route architecture. This communication architecture with formally clear signal interfaces simplifies large team development and ensures consistency between different parts of a system.
SDL defines time and timers in a clever and abstract manner. Time is an important aspect in all real-time systems but also in most distributed systems. An SDL process can set timers that expire within certain time periods to implement time-outs when exceptions occur but also to measure and control response times from other processes and systems.
When an SDL timer expires, the process that started the timer receives a notification (signal) in the same way as it receives any other signal. Actually an expired timer is treated in exactly the same way as a signal. SDL time is abstract in the sense that it can be efficiently mapped to the time of the target system, be it an operating system timer or hardware timer. This makes it possible to simulate time in SDL models before the target system is available.
Other aspects of the signaling concept in SDL are as follows:
- Signal and process priorities are not within the scope of SDL. These issues are left instead to the implementation phase where the user with special directives can assign signal and process priorities.
- An SDL signal can only be sent to one specific process instance at a time. To enable broadcasting the user can include a package with some general-purpose functions that will provide a broadcasting mechanism in the implementation.
Figure 3. Signals between Two Processes Travel through Channels between Blocks and from One Process to Another via Signal Routes
Behavior
The dynamic behavior in an SDL system is described in the processes. The system/block hierarchy is only a static description of the system structure. Processes in SDL can be created at system start or created and terminated at run time. More than one instance of a process can exist. Each instance has a unique process identifier (PId). This makes it possible to send signals to individual instances of a process. The concept of processes and process instances that work autonomously and concurrently makes SDL a true real-time language.
Figure 4. Creation of a New Process Instance at Runtime
Data
SDL accepts two ways of describing data, abstract data type (ADT) and ASN.1. The integration of ASN.1 enables sharing of data between languages, as well as the reuse of existing data structures.
The ADT concept used within SDL is very well suited to a specification language. An abstract data type is a data type with no specified data structure. Instead, it specifies a set of values, a set of operations allowed, and a set of equations that the operations must fulfill. This approach makes it simple to map an SDL data type to data types used in other high-level languages.
Figure 5. Abstract Data Type Example
The set of predefined sorts in SDL makes it possible to work with data in SDL in a traditional way. Variables of standard sorts, such as the following, can be declared:
- integer
- real
- natural
- boolean
- character
- duration
- time
- charstring
- PId
- complex data sorts (these can be created with Array and Struct as depicted in Figure 6)
A description of a more advanced use of ADT follows, where the operator concept is used for hiding data manipulation.
How to Use Advanced ADTs
ADTs in SDL can be used for much more than representing data, such as for the following:
- hiding data manipulation
- hiding algorithmic parts of a specification
- creating an interface to external routines
Figure 6. Advanced Use of ADTs
As Figure 6 depicts, data manipulation is hidden in operators. The function of the operator update is to update the complete result database and recalculate place for all participants after new results. This is an example of a sorting-and-seeking algorithm that is much better to hide in operators than to express in ordinary graphical SDL. Still, the operator should be described using SDL diagrams.
Inheritance
The OO concepts of SDL give the user powerful tools for structuring and reuse. The concept is based on type declarations. Type declarations can be placed anywhere, either inside the system close to their context, or at system level. Figure 7 shows an access control system with block and process types at system level. Type declarations can also be placed in packages outside the system, for sharing with other systems.
Figure 7. System with Type Declarations
One of the major benefits of using an object-oriented language is the simple and intuitive way new objects can be created by adding new properties to existing objects or by redefining 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 might add properties not defined in the supertype. One can, for example, add new transitions to a process type, add new processes to a block type, etc. (see Figure 8).
- A subtype can redefine virtual types and virtual transitions defined in the supertype. It is possible to redefine the contents of a transition in a process type, to redefine the contents/structure of a block type, etc.
Figure 8. Specialized Block Type
