Specification and Description Language (SDL) was initially devised in the early 1970s with a specific task in mind — to describe systems that switched state rapidly and often. The need for this language was in direct retaliation to the types of system that were rising to prominence during this time, possibly telecommunication systems that had become highly complex, with heavy traffic loads and real time demands. This exposed the more rigid programming languages and hardware description languages, that were unable to represent switching systems that required standardization on an international scale.
As telecommunication systems developed, so did SDL, moving from focusing strictly on sequential behavior to later adding notation for architectural composition, and finally introducing concepts such as types and inheritances. By this time, SDL was a full-time object oriented language, capable to be used when modeling a system graphically (SDL / GR) or textually (SDL / PR).
The basic form of an SDL diagram will involve some or all of the following components:
- Structure — the hierarchy of the system, its blocks, processes and procedures
- Communication — signals with optional parameters and channels
- Behavior — processes
- Data — abstract data types
- Inheritance — describing relationships and specialization
Different systems require a different approaches to diagram composition. Here are the three main forms of SDL diagram, and a brief description of their intent:
System architecture / structure
SDL uses a hierarchical structure comprried of 4 levels.
Every SDL diagram is taken as a view of system, be it a simple, single process, or more complex behavior derived from the relationship between a number of blocks. The hierarchy is nested; a system can be decomposed into blocks, each block can be describes as a process, until finally you can see the procedures that make up each process.
The advantages of this style are that a system that can be seen at any level — information can be shown or hidden, viewed in manageable portions, and paths can be followed individually through all their sub-divisions.
When we are describing system behavior using an SDL diagram, we are regarding blocks as finite state machines (FSM). An FSM is ideal form of component for such a diagram, as it is capable of taking on multiple forms, dependent on the type of signal input.
The states an FSM can switch to are clearly and unambiguously shown by the process diagram that is inherent within it. This process diagram describes every input and output of an FSM, the states that they change to and from, and the actions that perform depending on which state transition takes place.
There is rarely direct human contact with a system interface as described by SDL. Transistions and interactions within the system, and with the environment, are governed by signals, which already have a pre-determined cause and effect.
This keeps the blocks, or FSMs, in their finite state and as separate entities to each other — it is not possible for a signal to fundamentally disrupt or change the process within an FSM, only challenge it to make a state transition.
SDL diagrams are ideal candidates for reactive and distributive systems for a number of reasons:
- Formal and standard language, established internationally and through many fields of industry
- Highly testable due to formalism of structure and interface
- Graphical and symbol based, allowing for full interpretation of detail
- Portable, scalable and open, acting independently of operating systems, processors and distribution methods
- Recyclable, able to apply the same processes to many different scenarios
Specification and Description Language began life a tool for telecommunication software engineers, and it remains highly tested in that field today. Indeed, Nokia have developed their own variant named TNSDL to be used exclusively with their systems. At the same time, the user base has widened, and you can find examples of their use in automotive, aviation, and medical industries.