1 / 13

Automatic Analysis of Consistency between Requirements and Designs

Automatic Analysis of Consistency between Requirements and Designs. Article by Chechik and Gannon. Jon Davis Andy Kant. Introduction. Removing inconsistencies is an effective way to improve software quality.

richelle-lucas
Download Presentation

Automatic Analysis of Consistency between Requirements and Designs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Automatic Analysis of Consistency between Requirements and Designs Article by Chechik and Gannon Jon Davis Andy Kant

  2. Introduction • Removing inconsistencies is an effective way to improve software quality. • Current techniques are effective, however, they require considerable amounts of skills and lots of time and investments. However, this only proves true on smaller designs. • Researchers suggest a method which checks abstractions of programs. • The method discussed in the article formalize specifications for making abstractions so that they can be used to check the consistency of a requirement.

  3. Background • Current methods for checking inconsistencies are theorem-proving and model-checking. • The theorem-proving method requires considerable skill and time investments. • The model-checking method is limited to finite-state systems. Although fully automated, an increased amount of variables makes it too large to analyze. • The method suggested in this article is a “light-weight” formal method which achieves fully automatic verification by checking abstraction of the system for certain properties.

  4. Requirements Notation • The light-weight method requires a formal specification and language syntax. • This method makes use of a language that is easily understood by engineers. • The models for this method are used to specify reactive systems. • The input language of each machine is a set of conditioned events. A condition is a Boolean variable.

  5. Detailed Design • A Program Design Language (PDL) is used to specify design. This method uses a custom-defined PDL to reason about designs and Software Cost Reduction (SCR) requirements. • Designs should look like real programs – they should specify control flow using standard programming constructs. • Designs should capture the essence of what the code is doing rather than details. • Designs should be able to deal with specific conditional statements.

  6. Design Code Example

  7. Analysis of Design • Five properties are checked • 1. START (If the starting state is correct) • 2. OLT (Only legal transitions) • 3. ALT (All legal transitions) • 4. ENV (Environmental assumptions are preserved) • 5. REACH (All nodes are reachable)

  8. General Process

  9. Design Flow Graph

  10. Finite-State Machine

  11. Results • After completing the process of creating the DGM… • Creating the FSM… • And checking for all 5 properties… • Results will finally list which properties were inconsistent in the design and the requirements. • Here is an example result table…

  12. Results Example

  13. Overview/Conclusion • Using the defined notation, SCR specifications are written and checked for completeness. • A design is then made with the PDL and automatically verified for consistency with the requirements. • A real implementation is made around the PDL statements and checked for consistency with the design. • This process helps assure that the code implements the behavior specified in the requirements.

More Related