Automatic generation of formal requirements specification models from informal and semi-formal requirements specification models Dr. Naoufel Boulila (
[email protected]) Siemens Corporate Technology
Abstract Nowadays, embedded systems are used in many crucial and critical systems and devices upon which many real-world physical processes depend such as aircrafts and monitoring systems for nuclear power plants. Therefore, embedded and safety-critical systems must achieve a higher level of reliability and robustness before they can be deployed in real-world systems. To ensure the reliability and the robustness required for such systems, high-quality requirements must be specified and developed. For such a purpose rigorous formal methods are used to model, simulate, and test the requirements. However, most of the formal methods are difficult and hard for non-experts to deal with. It is much easier to handle informal and semi-formal specifications and models such UML models than logic, predicates, and proofs. We describe a technical solution to enable the automatic generations of formal requirements models from informal and semi-formal models. So that developers and engineers who are not familiar with formal methods can specify the requirement informally or semi-formally, then the formal models are automatically generated and integrated into the development process for purposes such as the automatic modelchecking, flaws detection, and mitigation.
Introduction In order to reduce the cost of constructing computer systems and to improve their quality many formal methods have been proposed. Formal methods have played a significantly increased role in hardware design and especially in embedded and safety critical systems. More and more companies that sell microprocessors and hardware chips, such as Intel, IBM, and Motorola, are using formally-based tools such as model checkers and theorem proves to detect flaws in their designs While formal methods are applied less frequently in software development, there have been a few recent cases in which they have detected previously unknown defects in real-world software. As an interesting example is the result of research in Microsoft’s SLAM project in which Ball and Rajamani designed several formal techniques to automatically detect flaws in device drivers [Ball et al. (2006)]. In 2006, Microsoft released the Static Driver Verifier (SDV) [Beckert et al. (2006)] as part of Windows Vista, the latest Microsoft operating system — SDV uses the SLAM software-model-checking engine to detect cases in which device drivers violate one of
a set of interface rules. Therefore, SDV helps uncover defects in device drivers, a primary source of software bugs in Microsoft applications. A critical step in developing high-quality software and hardware is to understand and document the underlined requirements. Studies have shown that many software defects can be traced to ambiguous, incomplete, and inconsistent requirements specifications and that fixing the resulting defects can be very costly, especially when the defects are detected late during the development. A promising approach to constructing precise, complete, and consistent requirements specifications is to represent the requirements in a formal specification language and to check the specification for properties, such as completeness and consistency, with formal analysis techniques. Formal specification languages can be described using conceptual models. Most of the uses of conceptual models have involved early phases of software development, such as requirements analysis and design for software, information systems and databases. Informally, a formal method is a mathematically-based technique or tool useful in developing either hardware or software.
Problem Description A typical process for employing model-based requirement development methods is illustrated in figure 1. Formal methods are not integrated in the process since they introduce various difficulties and are also weak with respect to structuring; their structuring techniques, encapsulation, parameterization, is motivated primarily by programming languages rather than knowledge representation and conceptual models.
Figure 1. Typical methods in the requirements process
Most of the formal methods are difficult and hard for non-experts to deal with. It is much easier to handle informal and semi-formal specifications and models such UML models than logic, predicates, and proofs. We describe a technical solution to enable the automatic generations of formal requirements models from informal and semi-formal models. So that developers and
engineers who are not familiar with formal methods can specify the requirements informally or semi-formally, then the formal models are automatically generated and integrated into the development process for purposes such as the automatic checking for flaws detection and mitigation.
Proposed solution In a first step, we propose the integration of formal methods in the requirement process as shown in the figure 2. The conduction of the formal method can be done automatically according to the method we describe below.
Figure 2. Integrating formal method in the requirements process
The proposed solution consists in a framework called iFOG (see Figure 3, 4) that provides a mechanism to transform a requirement specification using informal or semi-formal models such as UML models into conceptual model in a first step then into a formal model which takes various forms according to the rules provided initially.
Figure 3. IFOG example input and output models
Figure 4. The iFOG Framework
IFOG Framework components The various components are described as follows (see figure 4): ·
Input The input component provides a mechanism to define the target formal model language, the input model which is either the semi-formal model or the
informal model. Figure 6 illustrates the various model types in a UML diagram. ·
Configuration (configuration engine) The configuration component defines the formal model language rules such as the syntax and the semantics, the rules and constraints for the semi-formal and informal models.
·
Transformation (transformation engine) The transformation component provides a transformation engine which transforms the provided models into the corresponding target formal model iteratively. An informal model as an input will lead to the generation of a semi-formal model in a first step,. Then into a conceptual model in a second step, then finally into a forma model (see figure 4, 5 for details)
·
Output Describes the output formal model as expected and defined in the input.
Figure 5. iFOG components
Figure 6. The successive iterations needed for model transformation of the Transformation engine
Figure 7. Model taxonomy of the iFOG framework
Formal languages and models and examples are described in the next section.
Definitions 1. Conceptual model: according to (Gary F. 1997) a conceptual model is a formal model in which every entity being modeled in the real world has a transparent and one-to-one correspondence to an object in the model. Formally it represents information using semantic terms, such as entity, relationship, event, goal, etc., and semantic relationships, such as generalization, aggregation and classification. Conceptual models serve as a bridge between requirements stemming from real world and their representation using formal requirement language. 2. Conceptual modelling: is the activity of formally describing some aspects of the physical and social world around us for purposes of understanding and communication (Mylopoulos, 1992).
3. Conceptual-modelling grammar is the language used to generate conceptual models. It provides a set of constructs and rules that show how to combine the constructs to model real-world domains (Wand & Weber, 2002). A conceptual modelling grammar should be based on a theory of ontology, a theory that articulates those constructs needed to describe the structure and behaviour of the world in general (Wand & Weber, 1993; Weber, 2003) 4. Concept modelling: refers to a number of formal or informal techniques for capturing and manipulating concepts, using a vocabulary that provides more structure than simple narrative text such as Diagrammatic Reasoning (J. Glasgow et al. 1995). 5. Formal: A formally defined (requirements specification) language, is one where there exists a precisely defined syntax and semantics i.e. the language has an admissible alphabet, grammar, vocabulary. In addition, there exists a definition of how statements made using the vocabulary are to be interpreted. Precision of the syntax and semantics is provided by using mathematics. 6. Formal notations: with an ontology, syntax, and semantics (e.g., EER, parts of UML). A notation is formal if it comes with a formal set of rules which define its syntax and semantics. These rules can be used to determine if an expression is syntactically or semantically well-formed. Usually for formal notations the following ingredients must be present: a. Ontology: a set of assumptions about the nature of the applications being modelled. b. Terminology: terms for talking about the application e.g., entities and relationships for the E-R model, or time points and before, same, after relationships among them. c. Language: statements one can write in the notation e.g., well-formed formulas for First Order Logic d. Abstraction mechanisms: structuring mechanisms used to organize and conceptualize a large model e.g., generalization, aggregation, classification. Often, first order logic (FOL) or set theory are used for formalizing mathematical theories such as Number Theory, so they focus on aspects such as infinity and deduction. For real world modelling, common sense reasoning may be more appropriate than deduction. Moreover, these notations don’t support suitable abstractions for structuring large Formal Specification Languages They are developed largely for specifying programs, rather than models, which represent abstractions of real world artefacts. There are three types of specification languages: · Operational: specification is executable abstraction of the implementation, e.g., Lisp, Prolog, Smalltalk · State-based: view a software system in terms of states and procedures, e.g., VDM, Z
·
Algebraic: view a program as a set of abstract data structures together with a set of operations; operations are defined in terms of algebraic axioms, e.g., Larch, CLEAR, OBJ
Formal Requirements Modelling Language In the following we define general and high-level requirements for the requirement modelling language, where we need to focus on how to represent knowledge in the first place: Constructs. shall include a logical sublanguage for integrity constraints and deductive rules Formal notation. shall a formal notation as described above, including an ontology, language, abstraction mechanisms Abstractions. Shall have mechanisms for generalization, attribution, classification. Time. requirements models as histories of the application domain Meta-classes. which define the Requirement Modelling Language domain model Requirement specification The stage preceding software design has been often called specification, and this term is often used as an abbreviation for functional specifications. A specification describes desired properties for a system to be built. However, it is crucial to achieve an understanding of the application domain, including the environment within which the proposed system will eventually function. Hence, it is important for the requirement model to capture explicitly the understanding of the “environment” of the proposed system. Develop and present requirements as models Real world artefacts have to be modelled through a systematic identification of relevant aspects of the domain, and provide direct representations of them in the requirements. Models are the basis of understanding the world as well as for communicating among all involved parties. Requirements engineering activities are defined as model construction, management and analysis tasks. Formal requirements modelling Formal language would be used to express requirements models. The advantage of such formalism is that descriptions can have well-defined semantics, using methods imported from mathematical logic. The advantages of having clear semantics are multi-fold, including avoiding different interpretations of a given model, and offer a basis for various ways of reasoning with models, either through consistency checking or simulation and prototyping. It is important to note that the use of a formal requirements modelling language does not exclude the use of informal notations. It maybe built on top of an informal notation and in a later stage, defines a transformation process from an informal model into a formal one. Object-Centred Modelling The formal requirements modelling language shall be built on top of model consisting of objects of various grouped into classes, which are in turn instances of meta-classes.
Classes and meta-classes can have properties, which specify what kinds of information can be associated to their instances through factual properties.
References [Ball et al. (2006)] T. Ball, E. Bounimova, B. Cook, V. Levin, J. Lichtenberg, C. McGarvey, B. Ondrusek, S. Rajamani, and A. Ustuner. Thorough static analysis of device drivers. In European Systems Conference, 2006. [Beckert et al. (2006)] B. Beckert, T. Hoare, R. Hahnle, D. R. Smith, C C. Green, S. Ranise, C. Tinelli, T. Ball, and S. K. Rajamani. Intelligent systems and formal methods in software engineering. IEEE Intelligent Systems, 21(6):73–85, 2006.
