| - Marsh Chechik and John Gannon, Automatic Analysis of Consistency between Requirements and Designs, IEEE Transactions on Software Engineering, July 2001 (Vol. 27, No. 7). They describe formal method of verification. This requires that both the requirements and the design are defined very formally. |
....service Figure 5: Whitebox Specification 2.3.3 Informal specifications are not good enough Pure informal specifications might be clear enough in very simple cases, but they also have their share of disadvantages. They cannot be used as input to any tool, such as automatic test case generation [13], automatic pre and postcondition checking [35, 18] or formal theorem provers [1] Informal sentences are subject to interpretation, which in turn depends on the particular context of the reader. Often, these contexts vary, resulting in mismatches of interpretations by independent vendors and ....
Marsha Chechik and John Gannon. Automatic analysis of consistency between requirements and designs. In Proceedings of COMPASS'95, pages 123--132, 1995. http://www.cs.utoronto.ca/chechik/.
....of SCR requirements specification. 2.1 Four Variable Model The initial use of SCR approach lacked an underlying formal semantics. In [29] the Four Variable Model is proposed by Parnas and Madey who provide a formal framework for SCR method. The Four Variable Model illustrated in Figure 2. 1 [11] describes a system requirements with a set of mathematical relations on four set of variables: monitored and controlled variables, and input and output data items. A monitored variable is an environmental quantity that affects the system behavior, and a controlled variable 5 2. SCR Requirements ....
....using input and output data items, keeps the specification in the problem domain and make the specification simpler. 2. 2 SCR requirements specification Generally, a complete SCR requirements specification consists of three parts: behavior requirements, environmental assumptions and system goals [11]. 2.2.1 Behavior requirements SCR requirements model a system as an event driven state transition machine. The system s environment is abstracted as a set of monitored and controlled variables. Changes of monitored variables may cause the system to change its state or alter the values of its ....
[Article contains additional citation context not shown here]
Marsha Chechik, Automatic Analysis of Consistency between Requirements and Designs, Ph.D. Thesis, University of Maryland, College Park, Maryland, 1996
.... test data generation from the specification, approximate reasoning with upper and lower bounds, finite state analysis with binary decision diagrams based on equivalence classes, and relative debugging can be employed to gain confidence in the correctness and to isolate parts meriting formal proofs [7, 12, 9]. In relative debugging, an alternative to a full refinement proof stemming from the field of scientific computing [21] the specification and the implementation are executed in lockstep and their states are compared after each statement according to a mapping relation. If we want to better a ....
Marsha Chechik and John Gannon. Automatic analysis of consistency between requirements and designs. In Tech. Rep. CS-TR-3394.1, University of Maryland, College Park, 1995. http://www.cs.utoronto.ca/chechik/.
.... test data generation from the specification, approximate reasoning with upper and lower bounds, finite state analysis with binary decision diagrams based on equivalence classes, and relative debugging can be employed to gain confidence in the correctness and to isolate parts meriting formal proofs [9, 12, 11]. In relative debugging, an alternative to a full refinement proof stemming from the field of scientific computing [1] the specification and the implementation are executed in lockstep and their states are compared after each statement according to a mapping relation. If we want to better a ....
Marsha Chechik and John Gannon. Automatic analysis of consistency between requirements and designs. In Technical Report CS-TR-3394.1, University of Maryland, College Park, 1995. http://www.cs.utoronto.ca/chechik/.
....for safety as well as a potential pitfall in automated synchronization. source and do partial analysis. STeP [ZM 94] tries to prove the given assertions automatically and when that fails it lets the designer guide the proof by choosing the assertions that are to be proved. Analyzer [CG94, Che96] requires additional information related to the abstract component description to be inserted in the source code, and combines it with the program reachability graph to check the consistency of the program and SCR [Hen80] style specifications. Due to the undecidability of the program behavior, ....
M. Chechik. "Automatic Analysis of Consistency Between Requirements and Designs ". PhD thesis, University of Maryland, College Park, 1996.
.... meet requirements of their customers [22] Specifying the system precisely, i.e. using formal description techniques (FDTs) has been advocated as a viable approach to improving both the productivity and the quality of software products [40] In particular, it can lead to the following benefits [11, 29]: The process of formalizing specifications provides a more detailed understanding of the systems by encouraging software engineers to analyze requirements in depth, raising issues that may not otherwise manifest themselves until later in the development; Applying FDTs exposes omissions, ....
M. Chechik. Automatic Analysis of Consistency between Requirements and Designs. PhD thesis, University of Maryland, College Park, Maryland, December 1996.
....more behaviors than are present in the concrete one. This approach is weak property preserving for universally quantifiedproperties, e.g. properties expressed in 8CTL and LTL. If more behaviors are added and a universally quantified property is true, then it will still be true on a concrete system [5]. This method works well with safety properties but often leads to false negatives with reasoning about liveness properties. Spurious errors can be removed by constraining the over approximation, but it is hard to do; this problem is similar to making static analysis more precise [33] 2.2 ....
....is its variables and their types. Another abstraction constitutes going from a set of values that a variable may have at a certain point of the program to an interval by taking the minimum (maximum) value from the set as the left (right) bound of the interval. For example, ff(f 1, 5, 3g) [ 1, 5] ff(f0.5, 1.3, 23g) 0.5, 23] Here, the vocabulary of M is the same as M . Both refer to concrete variables and their values. Techniques have been developed [13] to enable finite representations of infinite sets of values and to ensure convergence of the computation of the abstract model ....
M. Chechik. Automatic Analysis of Consistency between Requirements and Designs. PhD thesis, University of Maryland, College Park, Maryland, December 1996.
....of realistic size and complexity (such as [2] however, contain global properties which cannot be expressed using only these assertions. Allowing the user to specify a richer set of properties is relatively easy, although not every CTL expressible formula can be verified during our analysis (see [12]) 5.2 Design Language To create a design, programmers use a mixture of control flow constructs, comments and annotations special statements which record mode transitions and changes to the values of controlled and monitored variables. These changes are local (rather than invariant) and ....
....PumpFail; 44: Update Error PumpOn; 45: 46: 47: 48: 49: 50: Figure 6: Initial SWLMS design. We interpret annotations in the design to create a set based approximation of attainable values for each requirements variable[16, 17] The details of building a DFG are given in [12]. The DFG that we create contains nodes which do not reflect state changes (e.g. decision nodes, joins and 18 1: 2: Initial Off SwitchOn PumpFail TooHigh TooLow PumpOn; 3: while (1) 4: Assert PumpFail; assume no device failures 5: READSWITCH( read ....
[Article contains additional citation context not shown here]
M. Chechik and J. Gannon. "Automatic Analysis of Consistency Between Requirements and Designs". Technical report CS-TR-3394.1, Dept. of CS, University of Maryland, College Park, October 1995.
....flow constructs since they do not reflect changes of values of requirements variables. To differentiate between 3 This is checked automatically by cord. 9 statements and annotations, our verification tool cord assumes that the latter start with . For the complete syntax of our PDL, see [10]. Consider the following design fragment: READDEVICE( Read PumpFail; if (PUMPFAIL( Assert PumpFail=true; break; Assert PumpFail=false; In this fragment, the function READ DEVICE( is called to determine the status of a pump. The Read annotation reflects this action for ....
.... Assert TooLow=true, resulting in known = f(TooLow, ftrueg) TooHigh, ffalseg)g Environmental assumptions can also be used to make sure that contradictory variable values are not asserted. Errors are considered violations of the ENV property. Details of this processing are presented in [10]. The system state for each DFG node is the value we compute for its out set. We initialize in and out sets of every node to EMPTY, and propagate information throughout the DFG until a least fixed point is reached. A join operator for combining information coming into the node is t, so in(n) t ....
[Article contains additional citation context not shown here]
M. Chechik. "Automatic Analysis of Consistency between Requirements and Designs". PhD thesis, University of Maryland, College Park, Maryland, December 1996. 39
No context found.
- Marsh Chechik and John Gannon, Automatic Analysis of Consistency between Requirements and Designs, IEEE Transactions on Software Engineering, July 2001 (Vol. 27, No. 7). They describe formal method of verification. This requires that both the requirements and the design are defined very formally.
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC