1. What are the object oriented concepts used in SDL explain?
Objects: As part of object modeling, components of the real world systems 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: 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. 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.
Process: 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 diagram, defining a type of processes.
Block: 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.
System: 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.
Variable: 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.
Attributes: 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. Methods may also have local variables that are used as auxiliary variables. In SDL process and service instances may have variables, while systems and blocks cannot 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. Procedures may also define local variables. Variables are declared in text symbols.
Predefined types: 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.
PId: Object references are in SDL supported by variables of the predefined type PId. PId variables may denote processes of any process type, so object references in SDL are not typed.
Methods: Methods of objects are properties that define possible behavior patterns that the object may apply to the data item attributes and thereby change the state information of these. 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. Procedures may also be defined in block and in systems, 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: Procedures defined locally to a process or service or globally in a block, system or package are intended for decomposition of the behavior 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.
Behavior: Most object oriented languages assume that behavior 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 behavior.SDL (by objects of kind process and service) belongs to the class of languages where objects have individual behavior.
Process behavior by Finite State Machine
Process behavior in SDL is defined by means of Extended Finite State Machines (EFSM). As such it fits with analysis methods that recommend the state/transition diagrams for important objects. Process behavior 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.
Process behavior by service composition
Sometimes it can be useful to describe the behavior of a process as a number of partial behaviors. Instead of specifying the complete behavior of a process type, it is possible to define partial behaviors 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-synchronized message passing or synchronized (remote) procedure call.
SDL belongs to the second class of language. Processes execute concurrently. The behavior of each process is represented by a Finite State Machine. 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 signal routes/channels that link the process and its environment together.
Object interaction is often based on objects having an interface or a set of interface in terms of signatures of methods.
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 class of concurrent, message passing objects is in SDL represented by a process type .
A class of alternating components within a concurrent object (process) is in SDL represented by a service 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 .
Abstract Data 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 behavior by means of axioms.
Classes allow to model concepts from the application domain and to represent the classification of similar objects. Specialization of general concepts into new more specialized concepts is in most object oriented languages represented by subclasses. Subclasses are said to inherit the properties specified in the superclass. The language mechanisms for this in SDL are specialization of types by means of inheritance, virtual types and virtual transitions. A (sub) type may be defined as a specialization of another (super) type. A subtype inherits all the properties defined in the super type 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 super type (within the same entity class).
A parameterized type can also be specialized. 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 parameterized types can be used as super types, including procedures. It is not possible to inherit from a single block definition, from a process set definition, or from a service definition.
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.
Some object oriented languages support the notion of objects being contained in other objects. Words being used are also aggregation, part-objects.
Two major approaches to this are:
1. Contained objects are constituent parts of the containing object, that is they are created as part of the containing object. A given object can only be part of one object.
2. Containment is rather a special relation between two separate objects and a given object can be part of more than one object. This is e.g. the approach followed in OMT.
SDL has support for (a slight modification of) the first approach, and relations in general are not supported:
â€¢ Blocks are constituent parts of a system or a block. Block are created as part of the creation of the system and con not be created dynamically
â€¢ Processes can only be part of one process set that is part of a block - processes in the set can, however, be created dynamically.
â€¢ Services are constituent parts of processes.
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.
This is not covered in this version, since it is not supported by tools. 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 parameterized 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. The general rule is that if a type of a certain kind can have definitions of types of different kinds, then it can have definitions of virtual types of the same kinds. This means that you can define
â€¢ system types with virtual block, process, service types and virtual procedures,
â€¢ block types with virtual block, process, service types and virtual procedures,
â€¢ process types with virtual service types and virtual procedures,
â€¢ service types with virtual procedures, and
â€¢ Procedures with virtual procedures.
Object oriented approach behind SDL
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 specialization 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 characterized 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 behavior, 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 specialization. The notion of objects and type hierarchies also promotes the definition of general classes that may be reused in many different applications.
2. How do you declare a constant range values in SDL? Give examples.
Example1: Syntype definition
syntype example =integer
The syntype example is an integer type, but a variable of this type is only allowed to contain values in the specified range 0 to 10. Such a constant is called a range condition. The range check is performed when the SDL system is interpreted.
Example 2: Syntype definition
syntype strangeint = integer
constants <-5, 0:3, 5, 8, >=13
In this example all values <-5, 0, 1, 2, 3, 5, 8, >=13 are allowed.
3. What are difference between the channels and signal routes?
In SDL, the state machines communicate together or with the environment by transmitting and receiving signals through channels and signals routes.
Firstly, a signal must be declared. A signal may carry one more parameters. Once declared a signal can be inserted into â€œwiresâ€ (channels and routes). The signal name can be directly inserted into symbols of channel or signal route, or the signal name can be inserted into a signal list if â€œwireâ€ is connected to a process, it is a signal route, otherwise it is a channel. A channel can carry signals either in one or in both directions. The main difference between channels and signal routes is that signal routes do not delay signals.
4. Differences between types and instances with an example wrt SDL.
In SDL it is possible to identify instances, and show the architectural structure of a system in terms of its instances. This feature of the language enables us to model structural distribution and interconnection aspects of a system. The language makes a clear distinction between types and instances.
â€¢ A type may be defined separately, and instances can be generated in the context of many systems.
â€¢ Reusable component types may be defined separately as types, allowing instances to be instantiated many places with little effort.
Instances may be of different kinds:
â€¢ blocks containing other blocks (which in turn may contain other blocks) or processes.
â€¢ processes characterized by attributes in terms of variables and procedures and which exhibit behavior 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.
6. What is protocol validation?
Protocol validation is a method of checking whether the interactions of protocol entities are according to the protocol specification, do indeed satisfy certain properties or conditions which may be either general or specific to the particular protocol system directly derived from the specifications. Validation sometimes refers to check the protocol specification such that it will not get into protocol design errors like deadlock, unspecified receptions, and livelock errors.
7. Describe protocol design errors.
Fig: Two process communication system
ïƒ˜ When the states of a stable pair have no alternatives other than remaining indefinitely in their current states, a state deadlock occurs.
ïƒ˜ This occurs when process A transmits a -1 and at the same time process B transmits a -3. As a result both process A and process B enter state 2.
â€¢ Unspecified Receptions
ïƒ˜ These occur when feasible receptions are not specified, in other words, positive reception arcs that can be traversed are missing.
ïƒ˜ In figure, if process B transmits an arc -3,then state 0 of process A should be able to receive the reception arc +3.
ïƒ˜ Unspecified receptions are harmful in protocol designs. Unknown states are entered and thus the interactions and behavior caused by the reception arcs are predictable.
â€¢ State Ambiguities
ïƒ˜ State Ambiguity occurs when there are two or more pairs of stable states.
ïƒ˜ In the figure ,as process A transmits a -1, it enters state 1; while in process B, it can receive the reception arc +1 and remain in state 0. Thus we have the stable state pairs(0,0) and (1,0) which produce state ambiguity.
â€¢ Non-executable interactions
ïƒ˜ Non-executable interactions are over specifications of either transmission arcs or reception arcs.
ïƒ˜ In the figure , no interaction sequences can cause state 3 of process B to receive event +2. hence the reception arc +2 from state 3 to state 1 in process B will be a non -executable interaction.
ïƒ˜ The reception arc will be executable only if process A can transmit two -2 events without a -1 event in between.
8. Describe the behaviour aspects of a protocol.
Behaviour aspects of a protocol need to be described better way during SDL development because
â€¢ behaviour is vital to the purpose and quality of this kind of systems;
â€¢ behaviour is difficult to describe clearly due to its dynamic, invisible and often infinite nature;
â€¢ Behaviour is often very complex and hard to overview.
Better ways to describe behaviour are still considered to be indispensable from any serious attempt to improve in systems and software engineering. â€œBetterâ€ is here relative to traditional programs and hardware descriptions in supporting:
â€¢ human communication and understanding;
â€¢ formal analysis and comparison of behaviours;
â€¢ Alternative implementations and design optimization.
SDL is intended to be used in several ways:
â€¢ for international standards in the communication area: to define unambiguous and consistent standards;
â€¢ for use in tendering: to specify the required behaviour and to compare provided behavior from different vendors;
â€¢ for use in systems development: to specify the required system behaviour, to design and generate an optimal implementation and to document the provided behaviour;
â€¢ For verification and validation of behaviour.
Consequently, SDL should be suitable for implementation-independent specification of behaviour as well as for description of the behaviour actually implemented.
9. Differentiate between the following terms.
Lossy and Lossless channels
A lossy channel system (LCS) is a computational model where nondeterministic finite automata communicate over a faulty network. An LCS has a finite message alphabet MM , set of mm channels, a finite number of states, and a transition table. Each channel is a string containing characters from MM. Each character in the channel should be thought of as the value of a message. The transition table contains a number of productions, which consist of the following:
â€¢ The initial state.
â€¢ The channel c to read or write from.
â€¢ An opcode, which can be either ? (read) or ! (write).
â€¢ The message a to be written or read.
â€¢ The successive state.
The transition table can be thought of as a directed multigraph where the nodes are states and the productions are edges, placed according to their initial and successive states.
â€¢ The lossless channel is described by a channel matrix.
â€¢ It is described with only one non-zero element in each column.
â€¢ During transmission, no source information is lost.
10. Explain the following using protocol layering structure.
a. Multiplexing and Demultiplexing operation of a protocol.
Most communication in TCP/IP takes the form of exchanges of information between a program running on one device, and a matching program on another device. Each instance of an application represents a copy of that application software that needs to send and receive information. These application instances are commonly called processes. A TCP/IP application process is any piece of networking software that sends and receives information using the TCP/IP protocol suite. This includes both â€œclassicâ€ end-user applications such as the ones described above, as well as support protocols that behave as applications when they send messages. Examples of the latter would include a network management protocol like SNMP, or even the routing protocol BGP (which sends messages using TCP like an application does).
So, a typical TCP/IP host has multiple processes each needing to send and receive datagrams. All of them, however, must be sent using the same interface to the internetwork, using the IP layer. This means that the data from all applications (with some possible exceptions) is â€œfunneled downâ€, initially to the transport layer, where it is handled by either TCP or UDP. From there, messages pass to the device's IP layer, where they are packaged in IP datagrams and sent out over the internetwork to different destinations. The technical term for this is multiplexing. This term simply means combining, and its use here is a software analog to the way it is done with signals.
A complementary mechanism is responsible for receipt of datagrams. At the same time that the IP layer multiplexes datagrams from many application processes to be sent out, it receives many datagrams that are intended for different processes. The IP layer must take this stream of unrelated datagrams, and eventually pass them to the correct process (through the transport layer protocol above it). This is the reverse of multiplexing: demultiplexing. In a typical machine running TCP/IP there are many different protocols and applications running simultaneously. This example shows four different applications communicating between a client and server machine. All four are multiplexed for transmission using the same IP software and physical connection; received data is demultiplexed and passed to the appropriate application. IP, TCP and UDP provide the means of keeping distinct the data from each application.
b. Segmentation and Reassembly operation of a protocol.
Segmentation and Reassembly is the process used to fragment and reassemble variable length packets into fixed length cells so as to allow them to be transported across Asynchronous Transfer Mode networks or other cell based infrastructures. Since ATM's payload is only 48 bytes, nearly every packet from any other protocol has to be processed in this way. Thus, it is an essential process for any ATM node. It is usually handled by a dedicated chip, called the SAR. The process is conceptually simple: an incoming packet from another protocol to be transmitted across the ATM network is chopped up into segments that fit into 48-byte chunks carried as ATM cell payloads. At the far end, these chunks are fitted back together to reconstitute the original packet. The process is analogous to the fragmentation of IP packets on reaching an interface with a Maximum Transmit Unit (MTU) size less than the packet size and the subsequent reassembly of the original packet once the fragments have reached the original packet's destination. Since different types of data are encapsulated in different ways, the details of the segmentation process vary according to the type of data being handled. There are several different schemes, referred to as ATM Adaptation Layers (AAL). The schemes are:
â€¢ AAL0 â€“ Raw cells with no special format
â€¢ AAL1 â€“ Constant bitrate, circuit emulation (T1, E1, etc.)
â€¢ AAL2 â€“ Variable bitrate synchronous traffic, eous traffic, e.g. Frame Relay transport
â€¢ AAL5 â€“ Used for most data traffic, such as IP
...(download the rest of the essay above)