On the Conquences of Acting in the Prence of Inconsistency
Bashar Nuibeh Alessandra Russo
Department of Computing, Imperial College
180 Queen’s Gate, London SW7 2BZ, UK
Email: (ban, ar3}@doc.ic.ac.uk
Abstract
Managing inconsistency in specifications covers a range of activities from consistency checking and inconsistency analysis to inconsistency handling through action. In this paper we argue that inconsistency analysis is insufficient to determine the choice of actions to take in the prence of inconsistency. Rather, we propo that some form of ‘hypothetical reasoning’ is needed in order to determine the conquences of different actions and thereby facilitate the decision-making process. We suggest some logic-bad techniques and associated heuristics for analysing the conquences of acting in the prence of inconsistency.
1.Inconsistencies in specifications
Deciding what action to take in the prence of inconsistency is difficult. Most rearchers agree that eradicating inconsistency in specifications is a desirable and worthy goal, but there is an emerging view that it may also be acceptable to live with inconsistency in certain circumstances or for transient periods of time [4]. Whichever strategy one decides to adopt in dealing with inconsistency in specifications, the choice of what action to take and the conquences of taking such an action are, we believe, crucial.
Previously, we focud on analysing inconsistent specifications with a view that the results of such analysis will shed some light on what action to take to remove the inconsistency or to ameliorate the inconsistent specification [2; 6]. While this has indeed been helpful in suggesting possible actions to take in the prence of inconsistency, we have also found that the analysis does not always suggest which action to take, given a choice between alternatives. In this paper, we propo the study of the conquences of taking alternative actions by studying their impact on the inconsistent specification, thereby facilitating the inconsistency handling decision process. We believe that a contribution in this area provides a way of managing changes in evolving specifications, by providing means of analysing the conquences of making the changes.2.Inconsistency implies action
Figure-1 is a schematic illustration of our framework for managing inconsistency in software specific
ations. It is an elaboration of the inconsistency handling framework propod in [5], bad on the notion of ‘inconsistency implies action’. The idea is that a specification, S, may contain a number, n, of inconsistencies (which can be detected in various ways; e.g., using logic-bad consistency checking). A number, m, of alternative actions can then be identified to deal with each inconsistency. The actions are normally determined by analysing the inconsistency. The choice of which action to perform is determined by analysing the conquences that each alternative action has on the original specification (including any human factors that may complement or override formal analysis).
Figure-1 also suggests a particular kind of impact analysis bad on so-called ‘derivable information’. Informally, a specification’s derivable information is any piece of information that can be obtained through some inference process from that specification. By examining the relationship, R, between the derivable information, D(S), from the original specification S, and the derivable information, D(S’m), from each of the possible conquent specifications, a ‘measure’ of impact of different actions may be obtained. Note that each conquent specification, S’m, is simply the specification that would be obtained by performing one of the alternative actions, A m.
In the remainder of this paper, we will focus on actions and their conquences. Clearly, consistency checking and inconsistency analysis are still active and important rearch areas, however, the focu
s of this paper is on activities that take place after an analysis has been performed. While there is a body of related work on impact analysis (e.g., [1]) and decision-making (e.g., [8]), we attempt to provide in this paper some formal foundations to underpin further work in both the areas.
3.Conquences of action
One of our main aims is to provide guidance to developers faced with inconsistent specifications and alternative cours of action. The provision of guidance
of alternative development actions, so our suggested approach has a logical flavour - although we do not commit ourlves to any particular logic.
Actions. We u the term action to mean any update to a given specification. Actions may be ‘atomic’ or ‘composite’. Atomic actions either add or delete a single piece of information (well-formed formula) to or from a specification, respectively. Composite actions are actions that can be reduced to a quence of atomic actions. For example, the action of ‘replacing a fact X by Y’ in a specification is a composite action that is equivalent to ‘delete X, then add Y’. In this paper, we focus on atomic actions to illustrate our framework, but we believe that our approach can be extended to deal with composite actions as well.
Atomic actions can be ud to implement different strategies for acting in the prence of inconsistency, such as tho we identified in earlier work [7]. For example, ignoring an inconsistency is equivalent to taking no action, while ameliorating an inconsistent specification involves adding or deleting one or more pieces of information to/from the specification without necessarily removing all the inconsistencies. Of cour, taking no action means leaving a specification unchanged, and this may indeed be a desirable cour of action to take. However, the kind of analysis we are considering in this paper assumes that actions will change a specification in some way, and it is the nature (cons
equence) of this change that we are focusing on. In the end, it is the ur who will decide whether to perform particular actions or to take no action at all. Moreover, it is often the ca that more than one atomic action is needed to eliminate an inconsistency, and that a specification may contain more then one inconsistency. The aim of our approach, however, is to ensure that each atomic action generates a
leave the specification inconsistent, ‘improves’ it in some way. Derivable Information.In general, the actions we are dealing with are not arbitrary updates [3] to a specification. Rather, they are focusd actions that specifically address inconsistencies identified by previous analysis. Our intention in this work, is to determine a cour of actions bad on analysis of, and reasoning about, the conquences of possible alternative actions. For this purpo, we introduce the notion of ‘derivable information’ which can be inferred from a specification. Intuitively, derivable information from a specification is information that is either already in the specification, or that may be inferred through some reasoning process from that specification. As we said earlier, while we do not commit to any particular kind of logic, we do assume that our logic does not allow trivialisation1. In this way, we can continue reasoning in the prence of inconsistency [6] to capture information that is still derivable from the (changed) specification.
whatdayistoday
It is worth noting at this point that an inconsistency is itlf a particular kind of derivable information. A specification is said to be inconsistent if a contradiction (α∧¬α) can be inferred from it. We denote the t of all inconsistencies derivable from a specification S by DI(S), where DI(S) is a subt of the t of information derivable from S, D(S).
Conquences. Performing an action on a specification S produces a new specification S’, which we call a conquent specification (Figure-1). We define the notion of conquences of an action in terms of both S and S’. For example, in some cas the conquence of an action 1Trivialisation is the derivation of any arbitrary information from an inconsistency.
is more derivable information from S’ than S, while in other cas less information is derivable. We define this more precily as follows .
Let S be a formal specification, let A m be an action on S, and let S’m be the specification resulting from performing the action A m on S. We define the positive conquences of A m as the t D(S’m )- D(S) of new derivable information from S’m , and we define the negative conquences of A m as the t D(S) - D(S’m ) of derivable information from S that are no longer derivable from the new specification S’m .
tj什么意思
3.Choosing the right action
There may be a number of different ways for choosing what action to take in order to handle inconsistencies in specifications. One option is to perform a comparative analysis of the positive and negative conquences of each individual action, and then make a choice bad on some ‘desirable’ conquences. Since the reality of requirements specification means that, inevitably, changes to partial specifications lead to the introduction of further inconsistencies and the loss of information, we may, for example, want to minimi additional inconsistency (that is, minimi inconsistent positive conquences) and/or minimi loss of information (that is, minimi negative conquences).
One way to achieve this is to define an ordering relation between alternative actions in terms of their positive and negative conquences. This ordering provides us with a ‘measure’ of inconsistency in a specification, which in turn provides us with further guidance in deciding what action(s) to take. Thus, for example, we could prescribe that maintaining or reducing the number of additional inconsistencies is preferable to minimising loss of information. Therefore, one action would be preferable to another if it introduces fewer new inconsistencies to a specification, or if, given the same number of new inconsistencies, it caus less loss of information. Within this scenario, two diff
erent actions may well be equally preferable. This is the ca if a pair of different actions have the same conquences (i.e. they introduce the same number of additional inconsistencies, and result in the same loss of information). In such cas, human intervention is necessary.
enjoy的用法
Of cour, there may be other heuristics for choosing between alternative actions, such as choosing actions that remove more than one inconsistency at the expen of losing information from the specification.
4.On the conquences of living with
inconsistency
We aim to develop a general (logic-bad) approach to inconsistency handling in specifications, and to apply the results to the management of evolving requirements specifications. Thus, generating alternative inconsistency handling actions remains an open issue. We intend to address this by considering abductive (‘hypothetical’)
reasoning. Abduction can help identify, for each inconsistency, which facts to add and/or delete in order to resolve the inconsistency.
Moreover, we intend to develop techniques for analysing the conquences of quences of atomic actions (that is, the conquences of composite actions).For example, we would like to examine the notion of ‘equivalent’ quences of actions, and asss the ‘costs’ of following different alternative quences, even if they generate the same conquent specifications.
We believe that the scope of this work is wider than inconsistency handling alone. It address the problems of analysing and handling change in evolving specifications.What we have propod in this paper is a preliminary impact analysis of inconsistent specifications. An important next step is to develop tractable tools that can guide developers engaged in this activity. We believe that restructuring large specifications into more modular ‘viewpoints’ [9] can help us address some issues of scale.
Acknowledgements
艾夫尔We would like to thank Jeff Kramer for his feedback, and to acknowledge financial support from the UK EPSRC (GR J15483 & GR/L 55964), the British Council and the EU.
References
[1] D. Duffy, C. MacNish, J. McDermid and P. Morris, “Asincere是什么意思
Framework for Requirements Analysis Using Automated
Reasoning”, Proc. of 7th
International Conference on CaiSE’95, LNCS 932, Springer-Verlag, 68-81, 1995.
[2]S. Easterbrook and B. Nuibeh, “Managing
Inconsistencies in an Evolving Specification”, Proc. of 2nd
IEEE Int. Symp. in Req. Eng. (RE ’95), York, 48-55, 1995.[3] R. Fagi, J.D. Ullman and M.Y. Vardi, “On the mantics of
updates in databas”, Proc. of 2nd
ACM SIGACT-SIGMOD Symposium on Principles of Databa Systems , Atlanta,352-265, 1983.
[4] S. Fickas, M. Feather and J. Kramer (Eds.), Proc. of ICSE-97 Workshop on ‘Living with Inconsistency’, Boston, USA,May 1997.
[5] A. Finkelstein, D. Gabbay, A. Hunter, J. Kramer, and B.
extranet>好莱坞电影推荐
Nuibeh, “Inconsistency Handling in Multi-perspective Specifications”, IEEE TSE , 20(8): 569-578, 1994.
[6] A. Hunter and B. Nuibeh, “Analysing Inconsistent
Specifications”, Proc. of 3rd Int. Symp. on Requirements Engineering , 78-86, Annapolis, MD, USA, January 1997.[7] B. Nuibeh, “To be and not to be: On managing
archer什么意思inconsistency in software development”, Proc. of the 8th
什么是blog
IEEE International Workshop on Software Specification and Desig n (IWSSD-8), 164-169, Germany, 1996.
[8] W.N. Robinson, “Interpreting Multiple Specifications
Using Domain Goals”, Proc. of 5th
IEEE Int. Workshop on Soft. Spec. and Design (IWSSD-5), 219-225, 1989.
about me[9] A. Russo, B. Nuibeh and J Kramer, “Restructuring
requirements Specifications for Managing Inconsistency
and Change: A Ca Study”, (to appear in) Proc. of 3rd
International Conference on Requirements Engineering (ICRE ‘98), Colorado Springs, USA, April 1998.
