A model-based approach for comparing the behaviour of software systems.

Sqills has created the TIP framework, the software system which serves as the basis for the SelfService website on which customers can book international traintickets. There are two other frameworks which support the sale of international traintickets, namely DirectMode and @tlantis. Sqills hopes that TIP can replace both of these systems, but because DirectMode is believed to contain some functionality which is not in TIP yet, some improvements to TIP may be necessary.

This thesis provides a methodology for comparing the behaviour of two software systems, which can be used to see if one system can replace the other. It consists of a modelling phase and a comparison phase. The modelling phase involves modelling the two systems which are being compared (and the external systems on which they depend) on three levels of abstraction: the structural level, the behavioural level and the interaction level.
The comparison phase of the methodology compares the behavioural models of the systems based on two different constraints contained within them: Execution path constraints and interaction constraints. The first constraint-based comparison compares all interactions (and the possible sequences in which they are executed) of one system with the other. The second constraint based comparison checks if interactions with a similar function can replace each other based on the constraints the systems involved place on them.

After comparing the behavioural models of TIP and DirectMode the conclusion could be drawn that TIP indeed lacks some functionality compared with DirectMode, but that there are several advantages to TIP as well. If the advantages DirectMode has over TIP will be overcome (by adding that functionality to TIP), then TIP might indeed be used as a basis for the generic browser based interface which the NS desires.

The methodology which this thesis has presented can accurately compare the behaviour of two software systems. This is very valuable when a system is being replaced with another, especially in an environment that demands that all services offered before the replacement need to still be supported after the replacement. By using this methodology it can be discovered what the advantages are that one system has over the other and this can steer further development of the system that will replace the old one.

It should be kept in mind that this methodology does not make statements with regard to quality factors (e.g. speed, user friendliness, costs, etc.) or physical design decisions (e.g. class structure, technologies by which the messages are exchanged). These two factors still need to be looked at after the methodology has been applied, before a definite decision can be made to replace the old system.