This paper states that many of the problems which arise when features combine (i.e. feature interactions) are due to badly developed requirements models for individual features. With sufficiently good requirements models, in which each feature is formally modelled and validated against customer understanding, the feature interaction problem is much more tractable. We analyse some of the standard feature interactions and show that, in most cases, the notion of interaction is used to signify that the requirements are not fully understood, properly recorded or rigorously validated. In contrast, we then show how good requirements models could resolve the problems that arise when combining features. An interaction is said to occur if and only if requirements are contradictory. The problem which this paper addresses is how to avoid, detect and resolve such contradictions during requirements development. 1 Introduction The feature interaction problem is stated simply, and informally, as foll...

The feature interaction problem is prominent in telephone service development. Through a number of case studies, we have discovered that no one semantic framework is suitable for the synthesis and analysis of formal feature requirements models. We illustrate our mixed-model approach, where we use OO LOTOS, B and TLA+ in a complementary fashion. A simple combination of call forwarding and call screening features emphasises the need for different semantics during the analysis, synthesis, validation, refinement and verification stages of formal development. 1 Introduction The feature interaction problem is stated simply, and informally, as follows: A feature interaction is a situation in which system behaviour (specified as some set of features 1 ) does not as a whole satisfy each of its component features individually. We concentrate on the domain of telephone features [8, 5]. Figure 1 illustrates this definition within the formal framework which we adopt throughout this paper. Three...

The temporal logic of actions (TLA) provides operators to express liveness requirements in an abstract specification model. TLA does not, however, provide high level composition mechanisms which are essential for synthesising and analysing complex behaviour. The object oriented paradigm has proven itself in the development of structured specifications. However, most, if not all, of the object oriented formalisms are based on the specification of safety properties and, as such, they do not provide an adequate means of expressing liveness conditions. This paper examines how we combine temporal semantics and object oriented concepts in a complementary fashion. High level re-usable concepts are formalised as different kinds of fair objects. The object oriented semantics aid validation and customer communication, whilst the TLA semantics provide a means of formally verifying liveness requirements. The fairness concepts are founded on the notion of objects as servers which may hav...

The composition (and configuration) of requirements is particularly important in feature specification because the units of incrementation in system development are themselves features. Thus we have requirements models made up of a large number of components, each of which is easy to specify and validate individually, but whose complexity resides in the semantics of composition, and configuration. We approach the definition of feature composition from the point of view of the client. Through our study of CS-1, we identify different ways in which the client would wish to compose their features with the plain old telephone service (POTS). From this we motivate the development of a feature composition algebra, the foundation of a feature interaction algebra. Quite simply, we hope to be able to perform a meta-analysis of the feature interaction problem using the feature classes rather than the features themselves. In this paper we show the type of meta-analysis that can lead to an algeb...

This paper reports on the research that arose in response to a need for more formal means of verifying telecom feature systems. We believe that TLA

A profiler can provide valuable information to a developer to facilitate program optimization, debugging or testing. In this paper, we describe the use of the Decorator pattern for non-intrusive profiling of object-oriented applications. We provide a formal specification of the Decorator pattern, and show that the pattern can be used as a program transformation without altering the external, observable behavior of the system. We refer to such a transformation as a correctness preserving transformation, or CPT. As a CPT, the Decorator pattern can be used to non-intrusively profile object-oriented applications and we illustrate this application with an invariant validator for enforcement of Design by Contract, and for profiling memory. We provide a case study to compare the cost tradeoffs of validating invariants at different points in a program.

ware engineering. We believe that discrete mathematics is the foundation upon which software development can be lifted up to the heights of a true engineering discipline. The transfer of for-mal methods to industry cannot be expected to occur without first transferring, from academia to industry, graduates who are well grounded in such mathematical techniques. These graduates must bring a positive, yet realistic, view on the application of formal methods. Our goal is to produce software engineers who will go out into industry understanding the principles of spec-ification, design and implementation. As these graduates develop their engineering skills, in an industrial setting, they should have the means, and the motivation, to integrate formality and rigour into any environment in which they are found. In this way, the formal methods should start to ‘sell themselves’. This paper reports on our first attempt to teach a formal methods course as part of a degree in software engineering. Rather than concentrating on one particular method, we worked on a set of small case studies, using the mathematics in a flexible and intuitive manner, where the students could appreciate the need for formality. Each case study was intended to illustrate, in turn, the need for some fundamental formalism. An unexpected result was that we also identified weaknesses in our understanding of formal methods: students ’ naive questioning helped us to identify how the methods, and the teaching of these methods, could be improved. In brief, it was not just the students who were learning! 1

The application of formal languages in the software development process is becoming more and more evident. Providing formal semantics and tools for the synthesis, analysis and transformation of behavioural models is usually the first step in the process of formal methods development. Many formal methods exist but, as yet, there is an absence of a meta-theory of formal methods. Such a meta-theory is the subject of this paper: we call it a unifying framework. We present a generalisation of the software development model which reflects the standard approach of using different languages at different stages of development. A unifying model will give a better understanding of why and how this happens; together with strengthening the rigour of such standard multi-semantic approaches to software development. 1

Requirements models have three distinct roles - they are the principle media of communication between clients and requirements engineers, they are the only model upon which rigorous and automated analysis can be carried out before development begins, and they are the structural foundation upon which design and implementation depend. A major part of building requirements is the modelling of the system to be developed (or updated) together with the system environment. These models are, of course, abstractions of the real world and their operational semantics can be executed to provide a simulation model for validation: to show that the behaviour specied actually corresponds to what exists or what is required. The models also have to be veried to show their logical consistency. A formal object oriented method facilitates incremental development, where the integration of simulation (through animation) , theorem proving and model checking increases condence in model correctness. Formal requirements models: simulation, validation and verication Abstract Requirements models have three distinct roles they are the principle media of communication between clients and requirements engineers, they are the only model upon which rigorous and automated analysis can be carried out before development begins, and they are the structural foundation upon which design and implementation depend. A major part of building requirements is the modelling of the system to be developed (or updated) together with the system environment. These models are, of course, abstractions of the real world and their operational semantics can be executed to provide a simulation model for validation: to show that the behaviour specied actually corresponds to what exists or what is req...

Formal methods are becoming increasingly important in many areas of software development and should be incorporated in the teaching of software engineering. Requirements capture is, in our opinion, the hardest stage of development for students to learn and for lecturers to teach. This paper reports on our experience in teaching requirements engineering using formal methods, where we advocate a multiple methods approach in which students get to evaluate a large range of specification languages: students are more likely to learn the principles of good requirements engineering rather than become experts in one particular (formal) method. The need for formality is introduced stepby -step, where new concepts are identified by the students through the use of case studies. These concepts are then formalised in the most appropriate language or notation. Students are encouraged to question the need for formality --- each requirements engineering method is a compromise and the use of formal models needs to be placed within the context of the choices that a requirements engineer has to make.