UML is a general purpose modeling language, however there are some areas which are not well explored with this language. Network protocols are a very good example as explained in my book
"Communicating Systems With UML 2"
The main tools for network protocol modeling are: Finite State Machines and Petri Networks. A Petri Network for a medium-sized protocol might reach many hundred of states and transitions. These kind of models allow to represent at the same time the communication algorithm and the non deterministic aspect of the subjacent network; however the model might rise incrementally when testing distributed network nodes or when simulating an entire network. Such a model is very hard to create, to analyze, to maintain and to evolve.
UML and SysML are a simple way to model each algorithm, each node and the subjacent network as a different machine.
The following example shows how to use the common diagrams existing in UML and in SysML to represent a very simple network protocol.
The ECHO protocol has the following characteristics:
- There are two communicating entities: Client and Server
- Client sends one “Hello” message to Server and Server answers with a “Hello_ACK” message
- System ends
Communication Diagram
We can better explain this behavior by using a UML
Communication Diagram (this diagram is not available on SysML).
Class diagram / Block Definition Diagram
Then the first step sill be represent each node as a simple class. We can use a
Class Diagram (UML) or a
Block Definition Diagram (SysML).
Class Diagram: interfaces definition
In a protocol context, we can group the communication messages into groups representing the Sender-Receiver direction. Each set can be represented by an Interface. In this case, we can create two interfaces: Client_2_Server and Server_2_Client. The first interface contains the message Hello_req while the the second interface contains Hello_res.
Class Diagram: ports
The next step is to add a communication port to each node: let’s say
P_C (Port_Client) and
P_S (Port_Server).
Ports are not very used in the regular software models with
UML; however,
SysML uses this concept in a more extended way since it defines
Standard Ports,
Flow Ports and
Item Ports..
Required and Provided interfaces
Now, let us associate the previously created interfaces to the Client and the Server classes.
From the point of view of the Client, the Server_2_Client interface is “provided” since it represents the messages that the Client can receive. In the protocols context, the “provided” interface is seen as the input messages set.
In the same way, from the point of view of the Client, the Client_2_Server interface is “required” since it represents the set of messages that the Client asks its communication partners to provide. In the protocols context, the “required” interfaces are seen as the output messages set.
Note that this is the port which is linked to the interfaces. Indeed, in the protocols context, the nodes receive and send messages through the ports, then these are the ports which should be linked to the interfaces:
* Realization = required interface
* Dependency = provided interface
It is also possible to represent the interfaces in a different way:
Composite Structure Diagram / Internal Block Diagram
Finally, we can connect the nodes through a Channel or Connector by using a Composite Structure Diagram (UML) or an Internal Block Diagram (SysML)
At this point, we have performed the structural modeling of the ECHO protocol. Now, let’s create the behavioral modeling.
First, let’s represent the expected exchange of message between the Client and the Server in a chronological order. For this, we can use a Sequence Diagram (UML and SysML).
State Machine Diagram
The next step consist in representing the behavior of each node in order to reproduce the expected exchange of messages. For this, we can use an Activity Diagram (UML and SysML) or a State Machine Diagram (UML and SysML). Lets see the Activity Diagram for the Client node:
Activity Diagram
And now the
Activity Diagram for the Server node:
Validating and Simulating the model
At this point we have all the elements allowing to represent a simple communication protocol.
The next step, which is, in my opinion, the most important of all, consist in validating and simulating the model. Indeed, in a simple example, as the one that I have represented here, it is not necessary to simulate since it is easy to verify that the proposed Activity Diagrams will effectively produce the expected sequence of messages. On the contrary, for a complex diagram, the validation and simulation of the model will allow to verify:
- That all the states have been visited. This way, we can ensure that the is no ‘unexpected’ behavior.
- That all the transitions have been fired. This way we can verify that there are no problems such as: Starvation or Dead locks.
- That the combined behaviors effectively produce the expected exchange of messages in a chronological order
However, at this moment, I have no license of any of the software programs allowing this kind of simulation.
If somebody know a free program for simulating an Activity Diagram or a State machine, I’ll be glad to know it and to taste it.
David GARDUNO
Posts
