Figure 3 - uploaded by J. Paul Gibson
Content may be subject to copyright.
Call Waiting state transition model assumption. 3.2 Call Waiting and Three Way Calling This, again, is commonly used to illustrate feature interaction. It is a classic case which frequently appears in the literature. We believe that, with good requirements models, there is no interaction at all. The interaction arises only when invalid assumptions are made about the triggering of the Call Waiting (CW) and Three Way Calling (TWC) features. CW Requirements When I activate CW its functionality is enabled only when I am talking to someone else. If I am talking to someone and a third person tries to call me then I can chose to hold them. Now I am talking to one person and holding another. I now have the ability to switch the talking and held persons. I can hang up on both calls at once and become on and silent in the normal POTS state. Similarly, either of the two other parties can hang up and I return to the POTS state oo and talking. The state-transition based requirements model is shown in gure 3. TWC Requirements If I subscribe to TWC then the feature is enabled only when I am talking to someone and I receive a call from a third party. I then have a new service (connect) which permits me to talk with both callers at the same time. In this new state I can also disconnect either one of the two callers. This is illustrated in the partial state transition diagram in gure 4. CW and TWC: No interaction now Traditionally, the argument for these two features interacting is as follows: What happens if both features are activated and we are talking to someone when we recieve an incoming call? There is an ambiguity because the system doesn't know which feature to execute. The problem is then further complicated by the fact that a ash-hook is used as the concrete event for three diierent abstract events (namely, hold, switch and connect). In this case the mapping between abstract and concrete events is not well deened since the ambiguity cannot be resolved by context alone.
Source publication
Similar publications
Citations
... The behaviour of features that interact with one another needs particular attention. This is known as feature interaction: "a feature interaction occurs in a system whose complete behavior does not satisfy the separate specifications of all its features" [5]. For example, in the feature model in Fig. 1, so far we have assumed that the features PLANET and EARTH do not interact, so that when they are combined we get the variants 'HELLO BEAUTIFUL PLANET EARTH' and 'HELLO WONDERFUL PLANET EARTH'. ...
In Software Product Line Engineering (SPLE), in the problem space, variability in a product family is specified in an enumerative manner (by a feature model), i.e. all valid variants are enumerated. However, in the solution space, current SPLE approaches use parametric variability (variability parameterised on features occurring in a single product variant) instead. In this paper, we take a closer look at enumerative variability, show how it can also be used in the solution space, and briefly discuss why it may be advantageous to do so.
... When a voter presses (for the second time) another candidate button then this is taken to represent their second preference, etc.. .. If they press a candidate's button that already has a preference associated with it then that press is ignored. When a voter is happy that they have recorded all their preferences, they press a validate vote 9 The use of the word 'safety' here does not mean that the property is "safety critical" in the classic sense that lives may be at risk, for example. The term is taken from the formal methods community where it is used to refer to an invariant property of the system that must be true all the time otherwise system behaviour cannot guaranteed to be correct. ...
... We note that making parallel changes to requirements and design models can lead to feature interactions similar to those well documented for telephone services [9]. Consider the interaction between two features that by themselves do not break the safety property of the system but when combined lead to invalid votes being recorded: ...
... Re-count: under certain well-defined circumstances, the count process has to be re-executed. Adding such optional features to the existing core architecture is a non-trivial problem and gives rise to the type of interactions that typically occur when composing requirements[21]. Infigure 3, we illustrate how a high-level object-oriented view of the requirements of a particular voting system, including optional features , can aid the process of identifying how features can be implemented using re-usable components, and how these features can be composed in order for a voting system to meet its requirements. ...
A significant number of failures in e-voting systems have arisen because of poorly specified requirements, combined with an ad-hoc approach to engineering multiple variations of similar machines. We demonstrate that e-voting is a suitable domain for leveraging state-of- the-art in software product line (SPL) engineering techniques and tools. We propose, based on examples of typical requirements, that a feature- oriented approach to e-voting domain analysis is a good foundation upon which to carry out commonality and variablity analysis. Simple anal- ysis of our core and optional features (and their variants) leads us to believe that feature interactions are a major problem in voting systems. We conclude that a formal software product line would help to man- age the composition of features in such a way as to eliminate interac- tions in the requirements models, before particular e-voting systems are instantiated.
... Fourthly, invite colleagues to participate in the PBL teaching in your own formal methods module(s). We note that this integration should probably be done in an incremental fashion as we may end up replicating the feature interaction problem[27] at the level of the requirements (learning objectives). To extend our analogy of a problem as being a service, with additional learning objectives as features, we can consider the curriculum to be a system of collaborating services. ...
The idea of weaving formal methods through computing (or software engineering) degrees is not a new one. However, there has been little success in developing and implementing such a curriculum. Formal methods continue to be taught as stand-alone modules and students, in general, fail to see how fundamental these methods are to the engineering of software. A major problem is one of motivation --- how can the students be expected to enthusiastically embrace a challenging subject when the learning benefits, beyond passing an exam and achieving curriculum credits, are not clear? Problem-based learning has gradually moved from being an innovative pedagogique technique, commonly used to better-motivate students, to being widely adopted in the teaching of many different disciplines, including computer science and software engineering. Our experience shows that a good problem can be re-used throughout a student's academic life. In fact, the best computing problems can be used with children (young and old), undergraduates and postgraduates. In this paper we present a process for weaving formal methods through a University curriculum that is founded on the application of problem-based learning and a library of good software engineering problems, where students learn about formal methods without sitting a traditional formal methods module. The process of constructing good problems and integrating them into the curriculum is shown to be analagous to the process of engineering software. This approach is not intended to replace more traditional formal methods modules: it will better prepare students for such specialised modules and ensure that all students have an understanding and appreciation for formal methods even if they do not go on to specialise in them.
... The main issues are whether being able to vote multiple times at different polling stations is functionally possible and, if so, can we continue to offer an acceptable quality of service to the vot- ers? The interdependency, in this case, is not bad in the classic sense of a requirements feature interaction[9]: analysis will show that the Revote feature can help in the process of designing a solution to the VoteAnywhere non-functional requirement that a denial of service attack on the network cannot compromise the voting system in meeting a minimum quality of service. ...
In this paper we propose that formal modelling techniques are necessary in establishing the trustworthiness of e-voting systems and the software within. We illustrate how a distributed e-voting system architecture can be analysed against quality of service requirements, through simulation of formal models. A concrete example of a novel e-voting system prototype (for use in french elections) is used to justify the utility of our approach. The quality of service that we consider is the total time it takes for a voter to record their vote (including voting time)/ The innovative aspects of the e-voting system that required further research were new requirements for voting anywhere and re-voting; and the potential for undesirable interactions between them.
... We can distinguish three groups of approaches: those specifying behaviour of features as formal models, using automata or transition systems, those specifying properties formally, using a logic, and those using a combination of both. Combining models of behaviour with specified properties is used in several approaches [SL95,Gib97,Tho97,PR98,KL98,dORZ98]. All these approaches use the same definition of feature interaction: if feature F 1 φ 1 and F 2 φ 2 but F 1 ⊕ F 2 φ 1 ∧ φ 2 , then an interaction exists (φ 1 and φ 2 are properties). ...
Feature interactions in telecommunications is an active research area. Many approaches to solve the so-called feature interaction problem have been proposed. However, all these approaches consider feature interaction as a somewhat isolated problem, in particular it is not seen in the context of evolving legacy systems and third party features in a deregulated market environment. An exception is the approach by Marples and Magill [MM98, Mar00], which presents an interaction detection mechanism and an essentially manual resolution approach. We develop an automatic resolution approach that can be integrated with Marples and Magill's detection mechanism. We distinguish two key concepts, namely solutions and resolutions. The former are essentially possible behaviours of the system, they are not qualified as desirable or undesirable, the latter are the desirable solutions. Our approach allows for automatic removal of undesired behaviour and selection of the "best" desired behaviour.
... Technology could open up new possibilities to the users/voters resulting in pressure for new features to be incorporated in future versions of the system. However, this is not without serious risk: the addition of new features is a major problem in software engineering as there can be complex interactions that lead to incorrect behaviour that is difficult to find before systems are updated and deployed (Gibson, 1997). ...
E-voting systems should be verified to be fit-for-purpose before being deployed, but there is a serious lack of provision for verification and maintenance in existing standards and recommendations for e-voting. A change to requirements, or to the system, usually results in the previously established fitness-for-purpose being compromised. Therefore change must be managed, and standards documents must make provision for their own maintenance. Verification is a process of establishing a relationship between what is required of the system and properties of the actual system. It is good practice that an independent authority be responsible for verification of systems against requirements. It must be possible to determine whether a given authority can be trusted to fulfil this task competently. Thus, requirements documents must not only say what standards are to be met, but must also state the minimum capabilities expected of any testing authority. The whole e-voting system development process is prone to human-error. This applies to the requirements, standards and the systems they describe. We must introduce suitable procedures for dealing with these errors, including the identification of responsible parties. We must also ensure that there is adequate incentive for the correction of errors. If maintenance of systems requires expensive recertification, there is a risk that vendors will not make necessary changes to their systems (to avoid recertification) or will make changes without having the systems recertified. Error discovery is not the only agent of change for requirements and systems. For example, the introduction of new legislation, new election types, or new technology will have direct consequences. This requires careful co-ordination between all concerned parties. Whenever a system changes, whatever the surrounding circumstances, it must be tested and re-certified. However, if the system under evaluation has been well-engineered, it may not be necessary to begin again with every modification. In this paper we examine what it means for a system to be well-engineered and propose maintenance procedures specific to the problem of e-voting.
... We note that making parallel changes to requirements and design models can lead to feature interactions similar to those well documented for telephone services [9]. Consider the interaction between two features that by themselves do not break the safety property of the system but when combined lead to invalid votes being recorded: @BULLET The lastPrefs method was optimized by adding a counter value so that an iteration through the candidate list was not required each time a new preference was input. ...
Electronic voting machines have complex requirements. These machines should be developed following best practice with regards to the engineering of critical systems. The correctness and security of these systems is critical because an insecure system could be open to attack, potentially leading to an election returning an incorrect result or an election not being able to return any result. In the worst case scenario an incorrect result is returned — perhaps due to malicious intent — and this is not detected. We demonstrate that an incorrect interface is a major security threat and show the use of the formal method B in guaranteeing simple safety properties of the voting interface of a voting machine implementing a common variation of the single transferable vote (STV) election process. The interface properties we examine are concerned with the collection of only valid votes. Using the B-method, we apply an incremental refinement approach to verifying a sequence of designs of the interface for the collection and storage of votes, which we prove to be correct with respect to the simple requirement that only valid votes can be collected.
... Besides, while derivation affects the whole product line artifacts, from requirements to code, the derivation issues are mainly addressed in terms of design and implementation [4] [6]. At the requirement engineering level, how to create the right requirements assets of the PL and dependencies among them to develop the right products have been extensively studied [7] [21] [22] [23] [24] [25], but understanding the derivation process itself has received little attention. In existing approaches, the derivation of the product architecture, code or test artifacts from the product and the PL specifications is performed using the following techniques: @BULLET Model transformation: static and dynamic models are instantiated for products from the PL models, using a model transformation language [ ...
Software product lines (SPL) modeling has proven to be an effective approach to reuse in software development. Several variability approaches were developed to plan requirements reuse, but only little of them actually address the issue of deriving product requirements. Indeed, while the modeling approaches sell on requirements reuse, the associated derivation techniques actually focus on deriving and reusing technical product data.
This paper presents a method that intends to support requirements derivation.
Its underlying principle is to take advantage of approaches made for reuse PL requirements and to complete them by a requirements development process by reuse for single products. The proposed approach matches users' product requirements with PL requirements models and derives a collection of
requirements that is (i) consistent, and (ii) optimal with respect to users' priorities and company's constraints. The proposed methodological process was validated in an industrial setting by considering the requirement engineering phase of a product line of blood analyzers.
... @BULLET When the base system (or system family) is conceived, features are " units of evolution " (or change) that adapt it to an optional user requirement [11]. A recurrent problem is the one of feature interaction: adding new features may modify the operation of already implemented ones. ...
Feature Diagrams (FDs) are a family of popular modelling languages used to address the feature interaction problem, particularly in software product lines, FDs were first introduced by Kang as part of the FODA (Feature-Oriented Domain Analysis) method back in 1990. Afterwards, various extensions of FODA FDs were introduced to compensate for a purported ambiguity and lack of precision and expressiveness. However, they never received a formal semantics, which is the hallmark of precision and unambiguity and a prerequisite for efficient and safe tool automation.The reported work is intended to contribute a more rigorous approach to the definition, understanding, evaluation, selection and implementation of FD languages. First, we provide a survey of FD variants. Then, we give them a formal semantics, thanks to a generic construction that we call Free Feature Diagrams (FFDs). This demonstrates that FDs can be precise and unambiguous. This also defines their expressiveness. Many variants are expressively complete, and thus the endless quest for extensions actually cannot be justified by expressiveness. A finer notion is thus needed to compare these expressively complete languages. Two solutions are well-established: succinctness and embeddability, that express the naturalness of a language. We show that the expressively complete FDs fall into two succinctness classes, of which we of course recommend the most succinct. Among the succinct expressively complete languages, we suggest a new, simple one that is not harmfully redundant: Varied FD (VFD). Finally, we study the execution time that tools will need to solve useful problems in these languages.
