The development of most large and complex systems necessarily involves many people - each with their own perspectives on the system defined by their knowledge, responsibilities, and commitments. To address this we have advocated distributed development of specifications from multiple perspectives. However, this leads to problems of identifying and handling inconsistencies between such perspectives. Maintaining absolute consistency is not always possible. Often this is not even desirable since this can unnecessarily constrain the development process, and can lead to the loss of important information. Indeed since the real-world forces us to work with inconsistencies, we should formalise some of the usually informal or extra-logical ways of responding to them. This is not necessarily done by eradicating inconsistencies but rather by supplying logical rules specifying how we should act on them. To achieve this, we combine two lines of existing research: the ViewPoints framew...

Large-scale software development is an evolutionary process. In an evolving specification, multiple development participants often hold multiple, inconsistent views on the system being developed, and considerable effort is spent handling recurrent inconsistencies. Detecting and resolving inconsistencies is only part of the problem: a resolved inconsistency might not stay resolved as a specification evolves. Frameworks in which inconsistency is tolerated help by allowing resolution to be delayed. However, the evolution of a specification may affect both resolved and unresolved inconsistencies. We present and elaborate a framework in which software development knowledge is partitioned into multiple views called "ViewPoints". Inconsistencies between ViewPoints are managed by explicitly representing relationships between them, and recording both resolved and unresolved inconsistencies. We assume that ViewPoints will often be inconsistent with one another, and we ensure that a complete wor...

This article is a revised and extended version of our earlier work which appeared in Proceedings of the 3rd International Symposium on Requirements Engineering (1997), pages 78 -- 86; Authors' addresses: A. Hunter, Department of Computer Science, University College London, Gower Street, London WC1E 6BT, UK; email: A.Hunter@cs.ucl.ac.uk; B. Nuseibeh, Department of Computing, Imperial College, 180 Queen's Gate, London, SW7 2BZ, UK; email: ban@doc.ic.ac.uk.

In requirements elicitation, different stakeholders often hold different views of how a proposed system should behave, resulting in inconsistencies between their descriptions. Consensus may not be needed for every detail, but it can be hard to determine whether a particular disagreement affects the critical properties of the system. In this paper, we describe the # bel framework for merging and reasoning about multiple, inconsistent state machine models. # bel permits the analyst to choose how to combine information from the multiple viewpoints, where each viewpoint is described using an underlying multi-valued logic. The different values of our logics typically represent different levels of agreement. Our multi-valued model checker, # chek, allows us to check the merged model against properties expressed in a temporal logic. The resulting framework can be used as an exploration tool to support requirements negotiation, by determining what properties are preserved for various combinations of inconsistent viewpoints.

In an evolving specification, considerable development time and effort is spent handling recurrent inconsistencies. Tools and techniques for detecting and resolving inconsistencies only address part of the problem: they do not ensure that a resolution generated at a particular stage will apply at all subsequent stages of the specification process. Previously, we have advocated tolerance and management of inconsistency, rather than strict enforcement of consistency. The advantages of this approach include the ability to delay resolution, facilitation of concurrent development, and greater flexibility in development strategies. However, this approach does not prevent inconsistencies themselves from evolving, and it does not ensure that resolved inconsistencies remain resolved throughout subsequent developments. We address these problems by explicitly recording relationships between partial specifications (ViewPoints), representing both resolved and unresolved inconsistencies. ...

In previous work we advocated continued development of specifications in the presence of inconsistency. To support this we presented quasi-classical (QC) logic for reasoning with inconsistent specifications. The logic allows the derivation of non-trivial classical inferences from inconsistent information. In this paper we present a development called labelled QC logic, and some associated analysis tools, that allows the tracking and diagnosis of inconsistent information. The results of analysis are then used to guide further development in the presence of inconsistency. We illustrate the logic and our tools by specifying and analysing parts of the London Ambulance Service. We argue that the scalability of our approach is made possible by deploying the ViewPoints framework for multi-perspective development, such that our analysis tools are only used on partial specifications of a manageable size. 1. Motivation and Background Inconsistent specifications are an inevitable intermediate p...

The development of software systems inevitably involves the detection and handling of inconsistencies. These inconsistencies can arise in system requirements, design specifications and, quite often, in the descriptions that form the final implemented software product. A large proportion of software engineering research has been devoted to consistency maintenance, or geared towards eradicating inconsistencies as soon as they are detected. Software practitioners, on the other hand, live with inconsistency as a matter of course. Depending on the nature of an inconsistency, its causes and its impact, they sometimes choose to tolerate its presence, rather than resolve it immediately, if at all.

We present a new approach to the control of versions of software and other hierarchically structured entities. Any part of a system, from the smallest component to a complete system, may exist in different versions. The set of all possible versions under the refinement relation forms a partial order (in fact, a lattice). The fact that version V approximates version V in this order means that V is relevant to V in this sense: when constructing version V of a system, we can sometimes use version V of a component if nothing more appropriate is available. More precisely, a particular version of an entire system is formed by combining the most relevant existing versions of the various components of the system. We call this the variant structure principle; it makes precise the idea that components of a given version of the system can be inherited by more refined versions of the system.

The development of software systems involves the detection and handling of inconsistencies. These inconsistencies arise in system requirements, design specifications and, quite often, in the descriptions that form the final implemented software product. This paper presents a critical review of approaches that explicitly tolerate and manage inconsistencies, and explores different kinds of inconsistencies that arise during different stages of software development. Managing inconsistency refers not only to the detection and removal of inconsistencies, but also to activities that facilitate continued development in their presence. Such activities include procedures for controlled amelioration or avoidance of inconsistency, which in turn may require analysis and reasoning in the presence of inconsistency.

: The problem statement and scope of SISYPHUS III does not draw attention to one of the major problems faced in knowledge engineering (KE), which is building systems based on multiple sources of expertise. In this circumstance, the KE task becomes a requirements engineering (RE) task. A problem with many RE approaches is that the cost of use is prohibitive, and therefore such approaches are rarely applied. We present an RE strategy designed to handle conflicting perspectives that is an extension to current KE techniques. We implement this approach in the context of formal concept analysis (FCA) and ripple-down-rules (RDR) and describe an instantiation using the SISYPHUS III data. Our evaluation technique shows that the resolution operators have reduced the degree of conflict between viewpoints. 1. Introduction The SISYPHUS III experiment offers an excellent example of the similarity between the needs of knowledge engineering (KE) using multiple sources of expertise and those of require...