Communicating Systems with UML 2

Modeling and Analysis of Network Protocols

David Garduno Barrera, Michel Diaz

• Publisher: Wiley-ISTE
• Year: 2013
• Print ISBN: 9781848212992
• eBook ISBN: 9781118602171
• Edition: 1
• Topic: Technology & Engineering
• Subtopic: Electrical Engineering & Telecommunications
• Index: Technology & Engineering

This book gives a practical approach to modeling and analyzing communication protocols using UML 2. Network protocols are always presented with a point of view focusing on partial mechanisms and starting models. This book aims at giving the basis needed for anybody to model and validate their own protocols. It follows a practical approach and gives many examples for the description and analysis of well known basic network mechanisms for protocols.
The book firstly shows how to describe and validate the main protocol issues (such as synchronization problems, client-server interactions, layer organization and behavior, etc.) in an easy and understandable way. To do so, the book considers and presents the main traditional network examples (e.g. unidirectional flows, full-duplex com-munication, error recovering, alternating bit). Finally, it presents the outputs resulting from a few simulations of these UML models.
Other books usually only focus either on teaching UML or on analyzing network protocols, however this book will allow readers to model network protocols using a new perspective and integrating these two views, so facilitating their comprehension and development.
Any university student studying in the field of computing science, or those working in telecommunications, embedded systems or networking will find this book a very useful addition.

Chapter 1

Why Use UML to Model Network Protocols?

1.1. Modeling network protocols

1.1.1. The complexity of communication protocols

In the future, as advanced architectures such as multimedia systems, control systems, distributed embedded systems, etc, become increasingly complex, they will still need to fulfill a set of well-defined requirements regarding their global quality. Meeting these requirements needs a deep understanding of the full distributed system, i.e. of all its local entities and all the communications between those local entities, in order to be able to represent and anticipate their resulting global behavior.

As a consequence, a system’s (global) behavior will depend on:

– local activities and their local data; and also on

– the messages that are sent, received and processed by the various interconnected entities.

A communication system with all its communication capabilities and configurations is often the basic and most difficult sub-system to correctly understand and build. The reason why this particular problem can be very complex, and lead to many design problems and implementation bugs, needs to be emphasized. To understand it, consider N processors that are connected: they can communicate, at a given instant, 2 by 2, 3 by 3, etc, or use full communication between them all, in which the N processors interact. The sum of the resulting combinations, which may need to be fully analyzed in order to understand the globally interconnected behavior, is then of the order of two to the power N.

From this number, it is easy to understand the potential complexity of the resulting conceptual problems, and in particular the increased difficulty which arises when going from interconnecting a few processors to interconnecting a large number of them: when N increases from 2 to 10, the number of potential interactions grows from 4 to more than 1,000.

It should therefore be clear that designing such distributed architectures can lead to a very complex conceptual design task, which, as a consequence, has to be based on a well-defined methodology in order to manage all the potential difficulties arising when building the system.

To manage such complex computer systems, a designer will usually at least go through the four following steps:

– specification: defining the system requirements, i.e. expressing the required functions and properties in a clear, complete and unambiguous manner;

– architecture: proposing the conceptual organization of the selected elements, composing the system in order to fulfill the requirements requested with the best performance possible;

– implementation: realizing the functions in the real and fully deployed architecture;

– validation: checking that the system fulfills its requirements, i.e. that the implementation satisfies the required properties.

Of course, designers, whenever possible, should use appropriate support tools to make their tasks more efficient. For instance, a designer can use support tools to capture requirements, to structure a design, to derive the implementation and to conduct the validation, either by verification, by simulation or by testing.

More precisely, when a system is complex, after defining the required properties, the various processes and entities, and defining the way they communicate, it is necessary to analyze the accuracy of the design. Of course, such validation has to be done as soon as possible, since correcting errors is simpler when the system is in an early stage of development, i.e. before it is fully implemented.

In any case, at whatever stage the validation is conducted, an adequate approach has to be used in order to represent global system behavior. Thus, the approach has to be defined to allow the designer to check and validate the appropriateness of the proposed behavior with respect to the system specification.

Then, precise specifications, i.e. a precise definition of the behavior expected, and a clear validation approach, i.e. one that is able to control the design process, are essential, or at the least, very valuable.

The first approach used to express the system specifications and validate the design is based on the use of a precise model of the involved mechanisms, functions and sub-systems, etc. Furthermore, the obtained semantic representation of the system must allow the designer to correctly express both the required properties and the required behavior of the designed system.

As a consequence, validating a proposed design becomes simple, since it entails checking the behavior of the designed system model against the required properties.

Note that, after a successful design validation phase based on such models, a system is considered “well designed”, and can be implemented. Normally, one or more validation phases can be conducted if needed, at different stages of the design.

1.1.2. Traditional modeling

Specification approaches have been used for many years for the verification of communication systems and protocols.

Although they had no precise specification in the early years, the complexity of protocols and the reliability of ISDN1 telecommunications systems have led to the development of formal specifications using formal descriptions. Two principal approaches were first proposed in order to write these specifications:

– basic formal models, such as finite automata, Petri Nets, process algebras, etc.; and

– formal description techniques, such as Estelle, LOTOS, and SDL.

Later, semi-formal models were developed and used to represent more complex systems, and to express many different specification and design perspectives.

The basic reasons for using these models are:

– to represent, if possible in a non-ambiguous way, the requirements and specifications of the system to be designed;

– to translate the specification, using given rules and model simplification when needed, into a mathematical or executable model;

– to verify or analyze the mathematical or executable model, which might be highly complex, in order to validate the resulting model of the system and so the underlying designed system.

1.1.2.1. Basic models and formal description techniques

Basic models which do not include language-specific operators are the simplest solutions for representing mechanisms in a very abstract way. However, it should be noted that, as a consequence of their simplicity, such basic models may not describe all the details involved in the systems. Moreover, if these details are of importance for any resulting behavior, other more complete and complex models are needed.

It follows that each model has its own particular characteristics, which are more or less relevant for any specific design. Consequently, the choice of the model depends on the system under study and on the properties to be analyzed, as the model must be at the same time able to describe the properties and the design to be checked.

Two principal basic formal models are now presented: state automata and Petri Nets.

1.1.2.2. Automata and state machine models

The first models proposed for numerical systems led to the definition of finite automata, or state machines [BOO 67]. These automata or state machines are based on three fundamental assumptions, often given implicitly. The first two of these are:

– Assumption 1: The system has inputs and outputs, and there exist, for the systems under consideration, a concept of a “global state” and a set of these global states, and, furthermore, an explicit representation of these states that can be precisely defined, usually using the set of system variables.

– Assumption 2: The global behavior (an operational behavior) of the system can be expressed, starting with an initial (global) state, by a set of transitions that go from this initial state, the present state, to a set of other states, the next states. Note that there is potentially one next state per transition. Each transition goes from one state, the present state, to another (by definition) reachable state, the next sta...

Table of contents

• Cover
• Title Page
• Copyright
• Preface
• Chapter 1: Why Use UML to Model Network Protocols?
• Chapter 2: Simple Transmission
• Chapter 3: Simple Chat Application
• Chapter 4: Non-reliable Transmission Mediums
• Chapter 5: Simple Transport Protocol
• Appendix: Detailed Diagrams of the Simple Transport Protocol
• Index