Science and Technology:

Software engineering, Agile,

UML, MODELING and more . . .

Monday, May 3, 2010

Modeling a Network protocol with UML / SysML




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:
  1. There are two communicating entities: Client and Server
  2. Client sends one “Hello” message to Server and Server answers with a “Hello_ACK” message
  3. 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:
  1. That all the states have been visited. This way, we can ensure that the is no ‘unexpected’ behavior.
  2. That all the transitions have been fired. This way we can verify that there are no problems such as: Starvation or Dead locks.
  3. 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.

Further reading in protocols modeling and simulation

You can see some of my works on protocols modeling in French version, in English version, or as a Slideshow .

David GARDUNO

Monday, April 5, 2010

Is TDR suitable for a highly layered process?



I’m currently working on “Product assistance” for an aircraft constructor and my usual tasks are Requirements writing or update.

However, the specifications that I write are not used directly by the developers’ team. On the contrary, these high level specifications are translated into a technical requirement specification which is used by the developers’ team.

For any system, the process might be divided into multiple layers and each layer might write its own specification.


The business team writes a very high level specification. The Product team writes a high level specification with some details about the final system, but without any specificity about the implementation. While the Project team writes a detailed technical specification.
Of course, all these specifications are inter-related.



In a usual "Test Driven Requirement" (TDR) approach we should create the tests at the same time that we write the specification. Moreover, the tests are used to better understand and to better explain the requirements.

In this TDR approach we might use a tabular form in order to describe the tests. Then, it should be possible to write a fixture (code) that would execute the test on the System Under Test (SUT). This is the process described by Fitnesse or GreenPepper, for example.

The problem here is that a specification created by the Business team is very far from the SUT; then it is not possible to write any fixture.

The fixture is suitable for specifications that are going to be developed directly, without any other intermediary level.

If we consider TDR as only writing tests to clarify, improve and complete the requirement specification; then it is possible to use it at any level of abstraction. However, we loose all the advantages about test reusability, non-regression, continuous validation, completion measurement, etc. that a tool such as Fitnesse or GreePepper would provide.

Indeed, TDR shows all its power when working on a specification that is going to be used directly by the development team.

D. GARDUNO

Wednesday, March 3, 2010

Installing Richnesse on Fitnesse



RichNesse is a WYSIWYG text editor for Fitnesse. It is based on FCKEditor. The last version of Richnesse was released on 2008-06-03; while the current version of Fitnesse was released on 2010-01-03. Richnesse is no more compatible with Fitnesse since version 2009-03-21 (more or less).
Nevertheless, it is possible to make them Work together. The instructions are as follow:


  1. Download and install the Fitnesse .JAR (I'm currently using the 20100103 version) file
    • You should have a folder with the fitnesse.jar file and a FitNesseRoot folder
    • The server should now be up at the end of the installation process. If so, then stop it by going to the following url: http://localhost/?responder=shutdown
  1. Download the Richnesse Zip file (I'm currently using the 0.804 version from 2008-06-03) and unzip it into the same folder as Fitnesse
    • You should obtain the following files beside the fitnesse.jar one:
      • RichNesse.jar
      • RichNesse.plugins.properties
  1. The next step is to set the properties file
    • Rename the RichNesse.plugins.properties file as plugins.properties
  1. At this point I got a problem: It was impossible to configure the classpath in order to point to the RichNesse.jar file. Then, I had to relocate the Richnesse files inside the Fitnesse jar file.
    • Open the RichNesse.jar file (try using winzip, for example)
    • extract the RichNesse folder
    • Open the fitnesse.jar file (try using winzip, for example)
    • Add the RichNesse folder that you have just extracted into the fitnesse.jar file
  1. Richnesse requires a 'responder' class which is not available any more in the recent versions of fitnesse (since 2009). It also requires an old version of a 'recorder' class. Lets get them:
    • Download the fitnesse zip folder version 2009-03-21
    • unzip this file into a temporal folder
    • Open the old fitnesse.jar file (try using winzip, for example)
    • Extract the SecureResponder.class file from fitnesse\responders\
    • Extract the SaveRecorder.class file from fitnesse\components\
  1. Lets integrate the old files into the new version of FitNesse
    • Open the recent fitnesse.jar file (try using winzip, for example)
    • Take the SecureResponder.class file you have extracted from the old fitnesse version and add it into fitnesse\responders\
    • Take the SaveRecorder.class file you have extracted from the old fitnesse version and add it into fitnesse\components\
    • Close the fitnesse.jar file

You can now launch the fitnesse server and access it in http://localhost/. The RichNesse button should now be available on the left panel.

The problem is that, when you install Richnesse this way, the standard 'Edit' button doesn't work any more. Moreover, if you click on this 'Edit' button, there will be a call to the server, the server will not respond to this call and the client will remain waiting for the answer. I think that the server is then altered and the following request will not longer succeed. The solution is then to shut-down and then up the Fitnesse server.

One more comment. I think that, when the Richnesse plugin is installed, then the reports created when there's a problem with the fixtures are less accurate.

Do you have another solution for installing a WYSIWYG editor for Fitnesse?

D. GARDUNO