Immaturity and Potential of Formal Methods: A Personal View

After some remarks on the use of different formal methods in the area of feature interaction detection, the question of the use of these methods in telecommunications systems development is addressed. Nowadays there does not seem to be (yet) a compelling or general need for formal methods. Also these methods are hindered by their fragmentation and discontinuity. Still, it is concluded that the success of formal methods is inevitable in the long run, although the time frame for this success and which methods will prevail remain open questions. 1. Formal methods and the IN conceptual model I start with some remarks on the need for different formal methods in the area of feature interaction detection. In the next section, I will claim that different methods are needed at the various stages of development of new systems. It will be seen that these needs lead to discontinuity and fragmentation in this area. Throughout, the point of view will be the one of off-line methods, which are the main area of application of formal methods. The Intelligent Network conceptual model identifies four planes, corresponding to different abstract views of the IN capabilities. These views can be thought to correspond to four different stages in the design of a system. Feature interactions can manifest themselves in each plane or stage. In IN’s Service Plane, potential interactions may show up as plain contradictions in the conjunction of the descriptions of the features. Here is a very elementary example: • Call Number Delivery stipulates that the number of the calling party be displayed at the called end • Unlisted Number stipulates that certain numbers cannot be displayed Hence an unlisted number should be displayed according to CND and not displayed according to UN, a contradiction that implies feature interaction. This can be detected by a simple theorem prover, but may elude some other methods mentioned below. It appears therefore that the theorem-proving approach should be exploited for finding feature interactions in this plane, and at the corresponding stage of design. In IN’s Global Functional Plane, we encounter feature descriptions in the full-call model. This was the model used in 1998’s FI contest. Techniques such as Chisel [1], Use Case Maps [7][13], ANISE [12], Tussilago [4], relational methods [12], are appropriate to describe in various ways this model. It is interesting to note how different these approaches are. Some (such as Chisel and Use Case Maps) are graphical in nature and some detection may be done directly by following graphical clues. Others are related to theorem-proving approaches. Others yet are related to state exploration models. Each has its own strengths and weaknesses. In IN’s Distributed Functional Plane and Physical Plane, we find the half-call model that is the basis of numerous state-oriented detection methods. This is the model that was used in this year’s FI contest. Testing methods are useful throughout, since tests can show concrete situations where a feature interaction occurs, or can show that there is no feature interaction in certain important cases. Testing, in many forms and at many levels, is turning out to be an interesting minimum common denominator [8]. We can conclude that feature interactions (potential or actual) can manifest themselves in many different ways and that detection methods should make it possible to catch them in just as many ways. 2. Formal methods and the development stages of new telecommunications systems In our experiences with industry concerning methods for feature design and feature interaction detection, we have encountered different attitudes, that at first might appear to be contradictory, but which in fact are more likely complementary. We use here the threestage model adopted by ITU-T and by other telecommunications standard bodies. According to this model, the development of a standard is done in the following sequence of stages: 1) service descriptions, 2) definition of functional entities and message sequences, and 3) protocol and procedure specification. In collaboration with industrial partners, we have tried to match these three phases to the description techniques that were best known to us [2]. Our conclusions are summarized in Fig. 1. Use Case Maps, a graphical notation that describes partial orders among abstract responsibilities, is proving to be successful at many levels and for many types of users. Message Sequence Charts are a less abstract technique, since they define specific message sequences between specific components. We found LOTOS to be useful for the specification and validation of Use Case Maps, which can be translated directly into it [3]. SDL is useful afterwards because it is at a level close to implementation. And TTCN is useful as a test specification language.