This part of the tutorial provides you with a presentation of SDL as seen from an object orientation perspective. The idea is that you have some kind of understanding of what object orientation is and want to know what the correspondence is in SDL.
The entry to the material is made by means of terms that are more or less well-established as terms within object orientation. Popup menus will lead you to the corresponding elements in SDL. In case there are several alternatives, you either know what you are looking for, or you consult the "in general" entry, which will give you our understanding of the object orientation term and then the mapping to SDL.
The different concepts are illustrated by SDL examples. When reading this interactively, it is recommended, when looking up the example for the first time, to open it in a separate window (shift click) - subsequent references to examples will then simply show the examples in this second window. You will have two windows: one with this text and one with the example.
This part of the tutorial may also be used in cases where you have made an object oriented analysis in some other language or notation and now want to make the more formal specification or design in SDL.
If you want some background information on the object oriented approach behind SDL, look at "Object oriented approach behind SDL" .
As part of object modeling, components of the real world systems (or anticipated such) are identified and selected properties are described. These components are modeled by objects. Objects may be classified into categories of objects (modelled by classes) and into subcategories (modelled by subclasses).
The corresponding is done in SDL, just in other terms: SDL systems consist of instances. The classification of components into categories and subcategories is in the SDL system represented by types and subtypes of instances (see "Subclass/inheritance" ).
If you are interested in the approach to object orientation behind SDL, have a look at "Object oriented approach behind SDL" .
An SDL system consists of a set of instances. Instances may be of different kinds, and their properties may either be directly defined or they may be defined by means of a type. If it is important to express that a system has only one instance with a given set of properties, then the instance is specified directly, without introducing any type in addition. If the system has several instances with the same set of properties, then a type is defined, and instances are created according to this type.
If you have objects that each contain several concurrent activities, then represent these activities by processes, and each container object by a Block . If you have classes of these define a Block type .
Processes are objects that perform concurrently with other processes and communicate by sending signals or by remote procedure calls. Processes are the main objects of SDL. Classes correspond to process types .
A process instance is part of a process set , which in turn is part of a block . The fact that a process set is part of block is described by a process reference . Properties of processes are either described directly by a process diagram, defining a set a processes, or by means of process type diagra m, defining a type of processes, see Process type .
A service object is an instance that is an integral part of a process. Services alternate executing, depending on incoming signals to the container process.
The properties of a service are either described directly in a service diagram, describing on single service as part of a process, or they are defined by a service type diagram, defining a Service type .
A block is an object that contains other blocks or processes; in addition it may contain local definitions of types, e.g. signal types, data types, procedures, process types and block types. A block does not have variables, so it is not possible to represent state-carrying objects by means of blocks.
A system object is the outermost object containing the blocks of the system connected by channels. In addition the system may have definitions of types, but it may not have instance variables - global, shared variables have to be global variables of shared processes.
A system is either described directly in a system diagram or a type of systems is described by a system type diagram, System type .
A variable is the association of a name and a value of some data type. Variables are only part of processes and services, and as local variables of procedure instances, but they are not part of blocks and systems.
In addition to methods, objects have data item attributes. These are often just variables of some predefined types (having values, that represent part of the state of the object) and object references, that is variables that denote other objects. Some languages also provides variables of user-defined classes.
Most object oriented languages follow the approach that instance variables should not be accessed directly from other objects, but only via methods. Variables used in this way thereby become part of the implementation of the class, while the interface of the object is represented by the methods.
In SDL process and service instances may have variables , while systems and blocks can not have variables. It is possible to access variables of processes from other processes, but it is recommended to access them either through Exchanging signals or through Calling remote procedures . Shared variables must therefore be variables of some shared processes.
Types may be user-defined, see "Specifying properties of variables: data types" for a short introduction.
In addition SDL has predefined types which are quite similar to those we are used to from programming languages. The common predefined types are: Boolean, Character, Charstring, Integer, Natural and Real.
The main kind of SDL entity corresponding to an object is a process. A process may have procedures and functions (that is value returning procedures) defined as part of its definition. Such procedures may be executed by the process itself, and if exported they may be requested by other processes (see Calling remote procedures ).
Procedures may also be defined in block and in systems (see Globally defined procedures ) ; they may then be executed by those processes that are defined within these blocks/systems. Procedures may also be defined in a service; they may only be executed by the service itself.
Procedures defined locally to a process or service or globally in a block, system or package are intended for decomposition of the behaviour specification into partial action sequences. In order for a procedure to represent a property of a process, so that other processes may request its execution, the procedure must be exported by the process, see Remote procedures .
Procedures work much the same way procedures in programming languages. They have value parameters (in, out, in/out) and a procedure defined locally to a process or service may manipulate variables of the enclosing process/service. and thereby have side-effects.
Procedures defined in types and inherited in subtypes can only be redefined if they are defined as virtual procedures (see Virtual procedures/functions ), while ordinary procedures are guarantied to have the same effect for all subtypes.
A procedure is a type in itself, and as such can be based on another more general procedure by specialization. This holds for procedures in general, that is for both ordinary procedures, exported, virtual, and value returning procedures. See Inheritance of behaviour for the details on how this works.
Value returning procedures are procedures that can be called as integral parts of expressions. Value returning procedures can be used very much like an operator, but they may contain states just like an ordinary procedure (while operator diagrams cannot).
Most object-oriented languages have virtuals in terms of virtual procedures. BETA has in addition virtual classes. Some languages, e.g Smalltalk, do not distinguish between virtual and non-virtual procedures (all methods are virtual and may be redefined in subclasses), while e.g. BETA, C++, Eiffel, and SIMULA distinguish. SDL dis.fmtinguishes between virtual and non-virtual procedures (and types in general - see Virtual classes/types ). The rationale for the distinction is that the designer of a general (super)class may want to ensure (in order for it to work) that some of its procedure attributes should not be redefined in subclasses. Distinguishing between virtuals and non-virtuals is the most general approach, as a special case of this is simply to specify all to be virtual.
A virtual procedure is defined by a procedure diagram, where the procedure heading starts with the keyword virtual and optionally has a virtuality constraint specified. A virtuality constraint for a procedure is the name of another procedure. The procedure diagram is otherwise as an ordinary procedure diagram.
A virtual procedure is redefined in a subtype of the type containing the virtual procedure by a procedure diagram with a procedure heading starting with the keyword redefined or finalized and with the same name as the virtual procedure. If the virtual procedure has a virtuality constraint, then then the redefinition must be a procedure that is specialisation of the constraint procedure.
Remote procedures are supported by server processes exporting a procedures, client processes importing procedures (their signatures) and calling remote procedures .. In addition the procedures are specified in a context enclosing both client and server.
For details on remote procedures, see remote procedures .
Most object oriented languages assume that behaviour is only associated with methods of objects and that a method of an object may be executed whenever some client object needs the effect of the method. In cases where this is not really the case, the methods are described in order to take this into account. Special methods are executed as part of the construction/deletion of objects, but apart from this the object itself has no specified behaviour.
A few languages support objects with individual behaviour. This is especially languages that also supports concurrency and where e.g. the synchronisation between objects are described as part of the behaviour of the objects and not of the methods.
Some object oriented analysis methods recommend that the behaviour of important objects are described by state/transitions diagrams, where important states are identified and events that cause transitions between states and corresponding method execution are described.
Process behaviour is described in the so-called process graph, with state s and transition s. In a given state a process may input a number of signal s, and the consumption of a signal leads to the execution of the following transition and entering the next state.
Sometimes it can be useful to describe the behaviour of a process as a number of partial behaviours. Instead of specifying the complete behaviour of a process type, it is possible to define partial behaviours by means of service types. A process type can then be defined as a composition of service instances according to these service types . 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.
Most object oriented languages support only one thread of action and have method call and direct instance variable access as the only kinds of object interaction. Some languages provide mechanisms for concurrent objects (with several threads) and corresponding mechanisms for either non-synchronised message passing or synchronised (remote) procedure call.
SDL belongs to the second class of language. Processes execute concurrently. The behaviour of each process is represented by a Finite State Machine (see "Behavior" ). Processes interact either by Exchanging signals or by Calling remote procedures .
The essential information one wants to convey in SDL models, is not the independence, however, but the dependency between systems. It is mutual dependencies that give systems purpose and meaning. Hence, a precise and unambiguous definition of mutual dependency is the prime concern. For this reason, all dependencies are modelled explicitly as signals interchange between the processes and their environments. There is basically no way a process and its environment may influence each other apart from sending signals through the signalroutes/channels that link the process and its environment together.
Processes in the system and the environment communicate with each other by sending signal s through the signalroutes and channels . There are no shared data to be found outside the processes, so signals are the only means for processes to communicate. There is no way for one process to directly manipulate another process.
There is no priority among signals; signals arriving at a process will be merged into one single queue in the order in which they arrive. There is one and only one signal input queue associated with each process. This queue is called the .i.input port;. If two signals arrive at the same time, the conflict is resolved by selecting an arbitrary sequential order. Signals from independent sources may arrive in any order.
In addition to the sending of signals, processes can interact by means of remote procedure calls. Such procedures must be defined as remote procedures: the server processes must export the procedures, the client must import them. In addition the procedures are specified in a context enclosing both client and server. This makes the signatures of the procedures known to both server and client.
For details on remote procedures, see remote procedures .
The corresponding mechanism in SDL is the gate . In order for processes in process sets to exchange signals, the process sets must be connected by signal routes, and the enclosing blocks and block sets must be connected by channels. Services as part of processes are also connected by signal routes.
When defining types of blocks, processes and services, the possible connection points for channels/signal routes are defined as gates. A gate can be specified to be one-way or two-way gates, and for each of the directions it can be specified which signals may be accepted/sent.
The classification of system components into categories of components is in object orientation modelled by classes. The corresponding notion in SDL is a type (of instances). A type defines the common properties of a category of instances. Each instance has its own identity and its own set of properties, e.g variables with different values. A type is not a set of instances: SDL has separate constructs for defining sets of instances (see process sets, block sets).
Most object oriented languages (and also analysis methods) provide only one kind of object, and correspondingly only one kind of class. This is not the case n SDL. Look at Objects to get a description of which kinds of objects that are supported by SDL. Depending upon the kind of the category of component you are supposed to model by a corresponding kind of SDL type of instance.
A class of concurrent, message passing objects is in SDL represented by a process type .
A class of container objects is in SDL represented by a block type .
A class of whole application-objects is in SDL represented by a system type .
Classes or types defining the properties of attributes/instance variables are in SDL represented by Abstract Data Types. This mechanism allows you to define types by means of values (literals), operation signature and behaviour by means of axioms. For a short introduction see "Specifying properties of variables: data types" .
Classes allow to model concepts from the application domain and to represent the classification of similar objects. Specialisation of general concepts into new more specialised concepts is in most object oriented languages represented by subclasses. Subclasses are said to inherit the properties specified in the superclass.
A (sub)type may be defined as a specialisation of another (super)type. A subtype inherits all the properties defined in the supertype definition, it may add properties and it may redefine virtual types and virtual transitions. Added properties must not define entities with the same name as defined in the supertype (within the same entity class).
A parameterised type can also be specialised. All properties of the super type, including formal parameters and context parameters,are inherited. A subtype definition may add formal parameters, context parameters, and other properties.
Only types and parameterised types can be used as supertypes, including procedures. It is not possible to inherit from a single block definition, from a process set definition, or from a service definition.
When adding block sets, process sets or services, these must be connected to block sets, process sets or services that are inherited. In order to distinguish between these in the graphical representation, the inherited elements are dashed. The same holds for dashed gates: it is not only possible to connect new elements to them, but is it is also possible to add to the constraint of the inherited gate.
A virtual type (that is block-, process-, service- type or a procedure) in an enclosing type can be redefined in a subtype of the enclosing type. As part of the virtual type definition, a virtuality constraint can be defined: any redefinition must then be a subtype of this constraint. This allows for analysis of type with virtual types, even though the virtual types can be redefined in subtypes.
A subtype of kind process, service or procedure inherits all the transitions of the supertype, except the virtual transitions that are redefined.
As part of analysis and specification, sets of application specific concepts will often be identified, and the corresponding classes defined. A common strategy is to collect related classes in class libraries.
The corresponding element in SDL is a package of type definitions. Types that are only used in one system will normally be defined as part of the system specification. If a set of related types are to be used in many systems within a specific application area, then this set can be represented by a package.
Most object oriented languages only provide flat name spaces, with one large set of class definitions, with locally defined methods. Only few languages provides class definitions within class definitions, and few languages provides any other mechanism for enclosing a set of related object and class definitions.
SDL def.fminitions may be nested and thereby support localisation. Type definitions may, be located where it is most convenient, as long as they are visible from they are supposed to be used. If identified types in an early stage should be specified as part of the system specification (and not yet as part of a package), they may simply be defined at the system level, without considering where they in fact belong. General types of e.g processes and procedures can be defined at system level, in order to be used in several blocks of the system. More special types should be defined where they are used.
A package of types is the ultimate example on non-localised type definitions, while exported procedures will most often be defined locally to the process (type) that exports it. Signals are often defined in the nearest enclosing block in which they are used between processes. Context parameters (see "Parameterised classes" )provide the mechanism to make a type definition independent on the enclosing scope.
System structure in terms of instances implies relations between instances, while localisation implies a relation (is-local-to) between definitions. Localisation is in SDL supported by nesting of definitions, and it forms the basis for scope-rules and visibility rules.
An SDL specification consists of definitions of entities of the different entity kinds (for a list of entity kinds, see entity kinds ).
Some definitions may contain definitions of other entities (nesting) and will therefore form the scope units for these entities. (for a list of scope units, see scope units ).
As part of the definition of an entity, the name of the entity is defined. Entities defined in the same scope unit and belonging to the same entity kind must have different names, while entities of different kinds may have the same name. As an example a procedure and signal defined in the same scope unit may have the same name. While it is sometimes convenient to be able to reuse a name in this way, it should not be done too much---readers may otherwise easily be confused.
Entities defined in a scope unit are visible in this scope unit and in all nested scope units. A signal defined in a block is e.g. visible in the block definition itself (where it can be used in the specification of channels), and it is visible in an enclosed process type definition (where it can be used in outputs).
When several definitions in nested scope units have the same name, the name will refer to the definition in the innermost scope unit (starting with the one containing the use of the name). In order to refer to one of the other definitions with the same name, a qualified identifier must be used.
Some object oriented languages support classes/types as parameters to classes. The class/type parameter may be used almost as an ordinary class/type. Depending upon the language it is possible to perform independent analysis of such a parameterised class.
The notion of context parameters provide one kind of parameterisation of types in SDL, but it does not cover block- and process types as type parameters to block types. This, is however, covered by a special application of virtual block- and process types.
A block type BT that has to have a process type PT as parameter is defined so that PT is a virtual process type in BT, with a constraint C that matches the use of PT in BT. When an actual process type APT should be provided to BT, this is done by defining a subtype SBT of BT and redefining the virtual process type PT to a subtype of APT. If just the parameter binding is desired, then this subtype adds nothing to APT, but in general it is possible to add properties in the subtype of APT. The requirement on APT is that it is a subtype of C.
Most languages only support virtual procedures, or methods that may be redefined in subclasses. If a class shall be parameterised by a type or class, then a separate notion of type parameters is introduced.
SDL provides the notion of virtual types in general, and not just virtual procedures.
A virtual type has in addition to the definition (e.g. in terms of behaviour in terms of a process graph) also a virtuality constraint . This will be a type of the same kind as the virtual type, and the simple rule is that any redefinition shall be a subtype of the constraint.
The constraint of a virtual type is used in the analysis of the use of the virtual type in the enclosing definition, and the idea is that a virtual type can only be used according to its constraint. In general a constraint type is a general type and can as such contain whatever a type may contain, but the normal cases are
For details on the the redefinition of virtual types, see "Redefining virtuals" .
The benefits of object orientation range from the underlying philosophy of modelling the phenomena in the form of objects, to the compactness of descriptions achieved by the use of the inheritance and specialisation mechanisms. Hence, there are two separate ideas that go under the name of object orientation and both are part of the object orientation presented here:
1. The notion of objects. It conceives each object as being characterised by data items carrying state information, by local patterns of action sequences (procedures, methods) that the object may apply to these data items and by an individual sequence of actions that the object may execute on its own.
2. The objects are active objects and not just passive data structures with associated operations. In order to directly model the different kinds of action sequencing found in a large class of application areas, the approach includes the execution of objects as part of other objects (as is the case for procedures and methods), as alternating (one at a time) with other objects and as concurrent with other objects. An essential property is that objects have a well-defined interface that hides the internal structure of data items and action sequences from the environment.
3. The notion of hierarchical types. The approach makes a sharp distinction between classes and objects. (Other words commonly used are types and instances.) Objects are carriers of state information and behaviour, while classes are patterns defining common structure and properties of objects. A class is not regarded as a set of objects, but as a definition of a category of objects. Classes do not contribute to the total state of a system, but help in organizing objects in type hierarchies. Objects model the phenomena of the application area, while classes model the types. The importance of this aspect is that it provides effective support to reuse.
Reuse of components requires language mechanisms to support composition and adaptation of reusable components. Object-oriented concepts give answers to both of these: composition by clean interfaces between classes of objects and adaptation by inheritance and specialisation. The notion of objects and type hierarchies also promotes the definition of general classes that may be reused in many different applications.