Results 11 - 20
of
313
Managing conflicts in goal-driven requirements engineering
- IEEE Transactions on Software Engineering
, 1998
"... Abstract- A wide range of inconsistencies can arise during requirements engineering as goals and requirements are elicited from multiple stakeholders. Resolving such inconsistencies sooner or later in the process is a necessary condition for successful development of the software implementing those ..."
Abstract
-
Cited by 109 (20 self)
- Add to MetaCart
Abstract- A wide range of inconsistencies can arise during requirements engineering as goals and requirements are elicited from multiple stakeholders. Resolving such inconsistencies sooner or later in the process is a necessary condition for successful development of the software implementing those requirements. The paper first reviews the main types of inconsistency that can arise during requirements elaboration, defining them in an integrated framework and exploring their interrelationships. It then concentrates on the specific case of conflicting formulations of goals and requirements among different stakeholder viewpoints or within a single viewpoint. A frequent, weaker form of conflict called divergence is introduced and studied in depth. Formal techniques and heuristics are proposed for detecting conflicts and divergences from specifications of goals / requirements and of domain properties. Various techniques are then discussed for resolving conflicts and divergences systematically by introduction of new goals or by transformation of specifications of goals/objects towards conflict-free versions. Numerous examples are given throughout the paper to illustrate the practical relevance of the concepts and techniques presented. The latter are discussed in the framework of the KAOS methodology for goal-driven requirements engineering.
Quickly Detecting Relevant Program Invariants
, 1999
"... Explicitly stated program invariants can help programmers by characterizing certain aspects of program execution and identifying program properties that must be preserved when modifying code. Unfortunately, these invariants are usually absent from code. Previous work showed how to dynamically detect ..."
Abstract
-
Cited by 106 (22 self)
- Add to MetaCart
Explicitly stated program invariants can help programmers by characterizing certain aspects of program execution and identifying program properties that must be preserved when modifying code. Unfortunately, these invariants are usually absent from code. Previous work showed how to dynamically detect invariants from program traces by looking for patterns in and relationships among variable values. A prototype implementation, Daikon, accurately recovered invariants from formally-specified programs, and the invariants it detected in other programs assisted programmers in a software evolution task. However, Daikon suffered from reporting too many invariants, many of which were not useful, and also failed to report some desired invariants. This paper presents, and gives experimental evidence of the efficacy of, four approaches for increasing the relevance of invariants reported by a dynamic invariant detector. One of them --- exploiting unused polymorphism --- adds desired invariants to th...
Closure and Convergence: A Foundation of Fault-Tolerant Computing
- IEEE Transactions on Software Engineering
, 1993
"... We give a formal definition of what it means for a system to "tolerate" a class of "faults". The definition consists of two conditions: One, if a fault occurs when the system state is within a set of "legal" states, the resulting state is within some larger set and, if faults continue occurring, the ..."
Abstract
-
Cited by 103 (28 self)
- Add to MetaCart
We give a formal definition of what it means for a system to "tolerate" a class of "faults". The definition consists of two conditions: One, if a fault occurs when the system state is within a set of "legal" states, the resulting state is within some larger set and, if faults continue occurring, the system state remains within that larger set (Closure). And two, if faults stop occurring, the system eventually reaches a state within the legal set (Convergence). We demonstrate the applicability of our definition for specifying and verifying the fault-tolerance properties of a variety of digital and computer systems. Further, using the definition, we obtain a simple classification of fault-tolerant systems and discuss methods for their systematic design. as traditionally been studied in the context of specifi...
Putting static analysis to work for verification: A case study
- In Int. Symp. on Softw. Testing and Analysis
, 2000
"... Abstract We study how program analysis can be used to:* Automatically prove partial correctness of correct programs.* Discover, locate, and diagnose bugs in incorrect programs. Specifically, we present an algorithm that analyzes sorting programs that manipulate linked lists. A prototype of the algor ..."
Abstract
-
Cited by 77 (17 self)
- Add to MetaCart
Abstract We study how program analysis can be used to:* Automatically prove partial correctness of correct programs.* Discover, locate, and diagnose bugs in incorrect programs. Specifically, we present an algorithm that analyzes sorting programs that manipulate linked lists. A prototype of the algorithm has been implemented. We show that the algorithm is sufficiently precise to discover that (correct versions) of bubble-sort and insertion-sort procedures do, in fact, produce correctly sorted lists as outputs, and that the invariant "is-sorted " is maintained by listmanipulation operations such as element-insertion, elementdeletion, and even destructive list reversal and merging of two sorted lists. When we run the algorithm on erroneous versions of bubble-sort and insertion-sort procedures, it is able to discover and sometimes even locate and diagnose the error. 1 Introduction This paper shows that static analysis can be employed to* Automatically prove partial correctness of correct programs.*
Inferring declarative requirements specifications from operational scenarios
- IEEE Transactions on Software Engineering
, 1998
"... Abstract—Scenarios are increasingly recognized as an effective means for eliciting, validating, and documenting software requirements. This paper concentrates on the use of scenarios for requirements elicitation and explores the process of inferring formal specifications of goals and requirements fr ..."
Abstract
-
Cited by 69 (11 self)
- Add to MetaCart
Abstract—Scenarios are increasingly recognized as an effective means for eliciting, validating, and documenting software requirements. This paper concentrates on the use of scenarios for requirements elicitation and explores the process of inferring formal specifications of goals and requirements from scenario descriptions. Scenarios are considered here as typical examples of system usage; they are provided in terms of sequences of interaction steps between the intended software and its environment. Such scenarios are in general partial, procedural, and leave required properties about the intended system implicit. In the end such properties need to be stated in explicit, declarative terms for consistency/completeness analysis to be carried out. A formal method is proposed for supporting the process of inferring specifications of system goals and requirements inductively from interaction scenarios provided by stakeholders. The method is based on a learning algorithm that takes scenarios as examples/counterexamples and generates a set of goal specifications in temporal logic that covers all positive scenarios while excluding all negative ones. The output language in which goals and requirements are specified is the KAOS goal-based specification language. The paper also discusses how the scenario-based inference of goal specifications is integrated in the KAOS methodology for goal-based requirements engineering. In particular, the benefits of inferring declarative specifications of goals from operational scenarios are demonstrated by examples of formal analysis at the goal level, including conflict analysis, obstacle analysis, the inference of higherlevel goals, and the derivation of alternative scenarios that better achieve the underlying goals. Index Terms—Scenario-based requirements elicitation, inductive inference of specifications, goal-oriented requirements engineering, specification refinement and analysis, lightweight formal methods. 1
Modularity and Reusability in Attribute Grammars
- Acta Informatica
, 1992
"... An attribute grammar is a declarative specification of dependence among computations carried out at the nodes of a tree. Attribute grammars have proven remarkably difficult to decompose into logical fragments. As a result, they have not yet been accepted as a viable specification technique. By combi ..."
Abstract
-
Cited by 63 (5 self)
- Add to MetaCart
An attribute grammar is a declarative specification of dependence among computations carried out at the nodes of a tree. Attribute grammars have proven remarkably difficult to decompose into logical fragments. As a result, they have not yet been accepted as a viable specification technique. By combining the ideas of remote attribute access and inheritance, we have been able to define "attribution modules" that can be reused in a variety of applications. As an example, we show how to define reusable modules for name analysis that embody different scope rules. 1 Introduction A fairly standard decomposition of the compiler construction task has evolved over the past twenty years, and most compilers have very similar structures. Many of the subproblems defined by the standard decomposition can be described as computations over trees, in which information is attached to individual tree nodes and used to control various decisions. 22 For example, consider the subproblem of determining t...
Java Program Verification via a Hoare Logic with Abrupt Termination
- Fundamental Approaches to Software Engineering (FASE 2000), number 1783 in LNCS
, 2000
"... This paper formalises a semantics for statements and expressions (in sequential imperative languages) which includes non-termination, normal termination and abrupt termination (e.g. because of an exception, break, return or continue). This extends the traditional semantics underlying e.g. Hoare logi ..."
Abstract
-
Cited by 58 (6 self)
- Add to MetaCart
This paper formalises a semantics for statements and expressions (in sequential imperative languages) which includes non-termination, normal termination and abrupt termination (e.g. because of an exception, break, return or continue). This extends the traditional semantics underlying e.g. Hoare logic, which only distinguishes termination and non-termination. An extension of Hoare logic is elaborated that includes means for reasoning about abrupt termination (and side-effects). It prominently involves rules for reasoning about while loops, which may contain exceptions, breaks, continues and returns. This extension applies in particular to Java. As an example, a standard pattern search algorithm in Java (involving a while loop with returns) is proven correct using the proof-tool PVS.
Mechanizing Programming Logics in Higher Order Logic
- in Current Trends in Hardware Verification and Automated Theorem Proving, ed. P.A. Subrahmanyam and Graham Birtwistle
, 1989
"... Formal reasoning about computer programs can be based directly on the semantics of the programming language, or done in a special purpose logic like Hoare logic. The advantage of the first approach is that it guarantees that the formal reasoning applies to the language being used (it is well known, ..."
Abstract
-
Cited by 57 (3 self)
- Add to MetaCart
Formal reasoning about computer programs can be based directly on the semantics of the programming language, or done in a special purpose logic like Hoare logic. The advantage of the first approach is that it guarantees that the formal reasoning applies to the language being used (it is well known, for example, that Hoare’s assignment axiom fails to hold for most programming languages). The advantage of the second approach is that the proofs can be more direct and natural. In this paper, an attempt to get the advantages of both approaches is described. The rules of Hoare logic are mechanically derived from the semantics of a simple imperative programming language (using the HOL system). These rules form the basis for a simple program verifier in which verification conditions are generated by LCF-style tactics whose validations use the derived Hoare rules. Because Hoare logic is derived, rather than postulated, it is straightforward to mix semantic and axiomatic reasoning. It is also straightforward to combine the constructs of Hoare logic with other application-specific notations. This is briefly illustrated for various logical constructs, including termination statements, VDM-style ‘relational’ correctness specifications, weakest precondition statements and dynamic logic formulae. The theory underlying the work presented here is well known. Our contribution is to propose a way of mechanizing this theory in a way that makes certain practical details work out smoothly.
Refinement Calculus, Part I: Sequential Nondeterministic Programs
- STEPWISE REFINEMENT OF DISTRIBUTED SYSTEMS: MODELS, FORMALISMS, CORRECTNESS. PROCEEDINGS. 1989, VOLUME 430 OF LECTURE NOTES IN COMPUTER SCIENCE
, 1989
"... A lattice theoretic framework for the calculus of program refinement is presented. Specifications and program statements are combined into a single (infinitary) language of commands which permits miraculous, angelic and demonic statements to be used in the description of program behavior. The weakes ..."
Abstract
-
Cited by 54 (3 self)
- Add to MetaCart
A lattice theoretic framework for the calculus of program refinement is presented. Specifications and program statements are combined into a single (infinitary) language of commands which permits miraculous, angelic and demonic statements to be used in the description of program behavior. The weakest precondition calculus is extended to cover this larger class of statements and a game-theoretic interpretation is given for these constructs. The language is complete, in the sense that every monotonic predicate transformer can be expressed in it. The usual program constructs can be defined as derived notions in this language. The notion of inverse statements is defined and its use in formalizing the notion of data refinement is shown.

