Abstracting formal specifications to generate software tests via model checking

This report gives an overview of the current status and plans to construct a prototype environment of advanced tools for software and hardware development based on the use of wide-spectrum languages. The wide-spectrum languages include Anna (ANNotated Ada), and TSL (Task Sequencing Language). The tools described here provide interactive aid at all stages in the system development process. Special emphasis is placed on distributed computing, both in providing tools for handling parallelism in the subject system, and in designing tools that utilize parallelism in the programming environment. Applications of these tools include requirements analysis, formal specification, rapid prototyping, testing, formal verfication and construction of self-testing Ada software for multi-processor systems.The report describes an existing environment of prototype tools supporting applications of Anna and TSL to formal specification and testing of Ada software. The new environment tools will be based on component tools already developed at Stanford and proven to be portable to various Ada environments. All tools are implemented in Ada and are intended to interface with standard components of Ada programming environments.

The domain of transformation systems has been introduced to provide a general integration framework for formal specifications. In this chapter an application of the integration approach to less formal software specifications is discussed. For that purpose models given in the Unified Modeling Language (UML) are considered: class diagrams for the specification of the structure and architecture of the system, and statechart and sequence diagrams for the specification of its behaviour. Analogous to the applications to specification formalisms presented in the previous chapters, the basic idea here is to interpret specifications semantically by sets of transformation systems, exhibit their correspondences, and thereby to check whether a common interpretation of all considered specifications is possible. As opposed to the former examples, however, the investigation cannot be completely formal, since the semantics of the given UML languages is not formally defined. That means the correctness of the transformation system semantics cannot be formally proved. To cope with this situation the interpretation will be open w.r.t. certain semantic decisions, which is then treated as parameters of possible admissible interpretations. On the other hand, the interpretation in the transformation system reference model provides the means for the formalisation and thus precision of the considered software specification languages.KeywordsState MachineUnify Modeling LanguageClass DiagramSequence DiagramClass GraphThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

An alternative scheme to formal software specification is explicitly proposed. In our approach, a formal software specification is formally defined as a set of decision rules performed by a software system. We propose a set of graphical notations called Requirements Particle Network (RPN), to describe the essential preconditions and operations needed by a software system according to the decision rules. A RPN consists of a set of particles and edges to construct a visual model of a decision rule during the software analysis phase. In addition, a number of transformation rules are proposed to perform the formal specification synthesis. A set of predefined formal requirements particle definitions is written in prior and reused during the transformation steps. A developer is provided a practical mean to write a formal specification with a brief experience in mathematical background. In this research, we demonstrate the Z formal specification synthesis using RPN. The usability of the RPN approach is investigated by conducting a workshop. The result indicates that a developer with experience in writing data flow diagram is capable to produce a complete and consistent RPN. Moreover, we show a case study of applying RPN to construct a composite operation to be used in database applications

Although model checking has proven remarkably effective in detecting errors in hardware designs, its success in the analysis of software specifications has been limited. Model checking algorithms for hardware verification commonly use Binary Decision Diagrams (BDDs) to represent predicates involving the many Boolean variables commonly found in hardware descriptions. Unfortunately, BDD representations may be less effective for analyzing software specifications, which usually contain not only Booleans but variables spanning a wide range of data types. Further, software specifications typically have huge, sometimes infinite, state spaces that cannot be model checked directly using conventional symbolic methods. One promising but largely unexplored approach to model checking software specifications is to apply mathematically sound abstraction methods. Such methods extract a reduced model from the specification, thus making model checking feasible. Currently, users of model checkers routinely analyze reduced models but often generate the models in ad hoc ways. As a result, the reduced models may be incorrect. This paper, an expanded version of (Bharadwaj and Heitmeyer, 1997), describes how one can model check a complete requirements specification expressed in the SCR (Software Cost Reduction) tabular notation. Unlike previous approaches which applied model checking to mode transition tables with Boolean variables, we use model checking to analyze properties of a complete SCR specification with variables ranging over many data types. The paper also describes two sound and, under certain conditions, complete methods for producing abstractions from requirements specifications. These abstractions are derived from the specification and the property to be analyzed. Finally, the paper describes how SCR requirements specifications can be translated into the languages of Spin, an explicit state model checker, and SMV, a symbolic model checker, and presents the results of model checking two sample SCR specifications using our abstraction methods and the two model checkers.

Formal Software Specification with Refinements and Modules of Typed Graph Transformation Systems

PurposeThe purpose of this paper is to present the ability of Z‐notation to formulate formal requirements specification of huge application software based on an example of the Manufacturing Resource Planning (MRP II) Standard System. Z‐notation is using formal transformation approach to obtain operating software instead of traditional programming. The original MRP II software requirement specification possesses descriptive form extended by list of control questions. To make formal requirements specification, the original specification must be extending by some definition taken after APICS Dictionary. The definitions respect such concept as: item, item code, location, and order.Design/methodology/approachWriting schemas based on subsystem order of MRP II Standard System and treating the system as three level structures (user interface, business logic, and database), the schemas described business logic level only. As a conclusion was necessity to extend descriptive requirements specification by definitions. The limited size of the presentation contains few examples of formalization process only mainly limited to the main schemas as: item system (full definition), inventory system, bill of material, work centers and routings, generic order system, master production schedule, and material requirement planning.FindingsAs a result of the research, it can be said that Z‐notation apparatus is sufficient to build requirements specifications of big application systems like MRP II, enterprise resource planning, or customer relationship management.Originality/valueLibraries of typical algorithms like MRP II designed through formal approach could replace traditional programming and open new prospects in the future development of broad computerization.

High quality software components require a representation that allows the implementation-independent description of the structure and behavior of software components. Hence, the static as well as the dynamic structure of the system has to be represented in a structured way. Graph transformation systems support static and dynamic modeling through a single computational framework for the sake of correctness, maintainability, and integrity. The framework introduced along with the corresponding tool, UPGraDE (Universal Programmed Graph Grammar Development Environment), which is based on the universal graph language GRASP (GRAph grammar with Set Productions). Any type of system can be specified through a minimal set of operations (syntax) and rules to specify the behavior of any type of software (semantics). The UPGraDE Environment, consisting of several totally transparent interconnected modules, performing well defined tasks, is a highly modular and extensible environment suited for nearly every GRASP development purpose.

Software quality enhancement can be achieved in the near term through use of a systematic program testing methodology. The methodology attempts to relate functional software testcases with formal software specifications as a means to achieve correspondence between the software and its specifications. To do this requires generation of appropriate testcase data. Automatic testcase generation is based on a priori knowledge of two forms of internal structure information: a representation of the tree of subschema automatically identified from within each program text, and a representation of the iteration structure of each subschema. This partition of a large program allows for efficient and effective automatic testcase generation using straightforward backtracking techniques. During backtracking a number of simplifying, consolidating, and consistency analyses are applied. The result is either (1) early recognition of the impossibility of a particular program flow, or (2) efficient generation of input variable specifications which cause the testcase to traverse each portion of the required program flow. A number of machine output examples of the backtracking facility are given, and the general effectiveness of the entire process is discussed.

On Formal Specification of Software Components and Systems

Complexity of hardware/software systems is continuously increasing. Formal specification is a methodology to ensure better quality of system specifications and to allow automated verification with tools like model checkers. Many formal specification approaches are known - ranging from programming languages to graphical specification tools. Each approach has its specific benefits. Usually, for abstract system and software specifications either table based or graphical notations are used. This paper presents a concept that leverages the advantages of both approaches by combining them in a single front-end. Both the table based and the graphical representation may be used for editing the specification. An automatic synchronization mechanism ensures that both representations are kept consistent. The implementation of the concept uses the table based formal language ADeVA and the Graphviz graph layout programs

The problem of formal software specification has been addressed and discussed since the infancy of software engineering. However, among all the proposed solutions, none is universally accepted yet. Many different formal descriptions can in fact be given for the same software component; thus, the problem of determining the consistency relation among those descriptions becomes relevant and potentially critical. In this work, we propose a method for comparing two specific kinds of formal specifications of containers. In particular, we check the consistency of intensional behavior models with algebraic specifications. The consistency check is performed by generating a behavioral equivalence model from the intensional model, converting the algebraic axioms into temporal logic formulae, and then checking them against the model by using the NuSMV model checker. An automated software tool which encodes the problem as model checking has been implemented to check the consistency of recovered specifications of relevant Java classes.

We present an automated framework for solidifying the cohesion between software specifications, their dependently typed models, and implementation at compile time. Model Checking and type checking are currently separate techniques for automatically verifying the correctness of programs. Using Property Based Testing (PBT), Indexed State Monads (ISMs), and dependent types, we are able to model several interesting systems and network protocols, have the type checker verify that our implementation behaves as specified, and test that our model matches the specification's semantics; a step towards combining model and type checking.

A software specification is often the result of an iterative process that transforms an initial incomplete model through refinement decisions. A model is incomplete because the implementation of certain functionalities is postponed to a later development step or is delegated to third parties. An unspecified functionality may be later replaced by alternative solutions, which may be evaluated to analyze tradeoffs. Model checking has been proposed as a technique to verify that a model of the system under development is compliant with a formal specification of its requirements. However, most classical model checking approaches assume that a complete model of the system is given: they do not support incompleteness. A verification-driven design process would instead benefit from the ability to apply formal verification at any stage, hence also to incomplete models. After any change, it is desirable that only the portion affected by the change, called replacement, is analyzed. To achieve this goal, this paper extends the classical automata-based model checking procedure to deal with incompleteness. The proposed model checking approach is able not only to evaluate whether a property definitely holds, possibly holds or does not hold in an incomplete model but, when the satisfaction of the specification depends on the incomplete parts, to compute the constraints that must be satisfied by their future replacements. Constraints are properties on the unspecified components that, if satisfied by the replacement, guarantee the satisfaction of the original specification in the refined model. Each constraint is verified in isolation on the corresponding replacement.

This paper introduces B, a mathematically based method and a computer based tool-kit for software engineering. The B-Method provides a notation and a method for the formal specification and design of software. Incremental construction of layered software as well as incremental mathematical verification have been guiding principles in its development. The method uses a ‘pseudo’ programming language Abstract Machine Notation as the language for design as well as for specification within the software process. AMN is based on an extension of Dijkstra’s guarded command language, with built-in structuring mechanisms for the construction of larger systems. The B-Method is explained in The B-Book [Abrial, 1997].The B-Toolkit supports the method over the spectrum of activities from specification through design and implementation into maintenance. The B-Toolkit comprises automatic and interactive theorem-proving assistants, and a set of software development tools: an AMN syntax & type checker, a specification animator and code generators, and promotes an object oriented approach at all stages of development. All tools are integrated into a window-based development environment. The B-Toolkit is developed and sold by B-Core.KeywordsGeneralise SubstitutionProof ObligationAbstract MachineSoftware Development ToolRefinement RelationThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

The translation of temporal logic specifications constitutes an essential step in model checking and a major influence on the efficiency of formal verification via model checking. We devise a new explicit-state translation of Linear Temporal Logic to automata for the class of LTL specifications that describe safety properties, arguably the most used formal specifications in real-world systems. By exploiting the inherent determinism in safety specifications, we can build deterministic Promela never claims that accept only the bad prefixes of the safety specification. In contrast to previous works, we focus on compilation to never claims rather than simply automata and measure Spin model-checking time separately from compilation time and automata size. An extensive experimental evaluation over a space of configurations demonstrates that our new translation consistently results in better model-checking performance, for a large array of benchmarks, over the best current translation.