From English to formal specifications

Formal methods provide an approach in which design steps can be shown to satisfy a specification. However, if a formal specification is wrong, then although the design steps may satisfy the formal specification, they are unlikely to satisfy the requirements of the system. Since most users are unfamiliar with formal methods, requirements specifications are often written in English. Such requirements, expressed in English, are then somehow translated to formal specifications. This transition has some potential for introducing errors and inconsistencies. In this paper we propose an interactive approach to proceeding from an informal specification to a formal specification in a systematic manner. The approach uses research in the area of natural language understanding to analyse English specifications in order to detect ambiguities and to generate an entity relationship model. The entity relationship model is then used as a basis for producing VDM data types and the specifications of some common operations. We illustrate the effectiveness of our approach by applying it to the specification of part of a route planning database system

Requirements specification using concrete scenarios

The precision of formal specifications allows us to prove program correctness. Even if formal methods are not used throughout the software project, formalisation improves our understanding of the problem. Formal specifications are amenable to automated analysis and consistency checking. However using them is challenging. Customers do not understand formal notations. Specifiers have difficulty tackling large problems. Once systems are built, formal specifications quickly become outdated during software maintenance. A method of developing formal specifications using concrete scenarios is proposed to tackle the disadvantages just mentioned. A concrete scenario describes system behaviour with successive steps. The pre- and post-states of scenario steps are expressed with actual data rather than variables. Concrete scenarios are expressed in a natural language or formal notation. They increase customer involvement in the creation of formal specifications. Scenarios may be ranked by priorities allowing specifiers to focus on a small part of the system. Formal specifications are constructed incrementally. New requirements are also captured in concrete scenarios which guide the modification of formal specifications. On one hand, concrete scenarios assist the creation and maintenance of formal specifications. On the other hand, they facilitate program correctness proofs without using conventional formal specifications. This is achieved by adding implementation details to customer scenarios. The resulting developer scenarios, encapsulating decisions of data structures and algorithms, are generalised to operation schemas. With the implementation details, the schemas written in formal notations are programs rather than specifications.EThOS - Electronic Theses Online ServiceGBUnited Kingdo

Tools for producing formal specifications : a view of current architectures and future directions

During the last decade, one important contribution towards requirements engineering has been the advent of formal specification languages. They offer a well-defined notation that can improve consistency and avoid ambiguity in specifications. However, the process of obtaining formal specifications that are consistent with the requirements is itself a difficult activity. Hence various researchers are developing systems that aid the transition from informal to formal specifications. The kind of problems tackled and the contributions made by these proposed systems are very diverse. This paper brings these studies together to provide a vision for future architectures that aim to aid the transition from informal to formal specifications. The new architecture, which is based on the strengths of existing studies, tackles a number of key issues in requirements engineering such as identifying ambiguities, incompleteness, and reusability. The paper concludes with a discussion of the research problems that need to be addressed in order to realise the proposed architecture

Generating natural language specifications from UML class diagrams

Early phases of software development are known to be problematic, difficult to manage and errors occurring during these phases are expensive to correct. Many systems have been developed to aid the transition from informal Natural Language requirements to semistructured or formal specifications. Furthermore, consistency checking is seen by many software engineers as the solution to reduce the number of errors occurring during the software development life cycle and allow early verification and validation of software systems. However, this is confined to the models developed during analysis and design and fails to include the early Natural Language requirements. This excludes proper user involvement and creates a gap between the original requirements and the updated and modified models and implementations of the system. To improve this process, we propose a system that generates Natural Language specifications from UML class diagrams. We first investigate the variation of the input language used in naming the components of a class diagram based on the study of a large number of examples from the literature and then develop rules for removing ambiguities in the subset of Natural Language used within UML. We use WordNet,a linguistic ontology, to disambiguate the lexical structures of the UML string names and generate semantically sound sentences. Our system is developed in Java and is tested on an independent though academic case study

Designing and Documenting the Behavior of Software

The development and maintenance of today's software systems is an increasingly effort-consuming and error-prone task. A major cause of this problem is the lack of formal and human-readable documentation of software design. In practice, software design is often informally documented (e.g. texts in a natural language, `boxes-and-arrows' diagrams without well-defined syntax and semantics, etc.), or not documented at all. Therefore, the design cannot be properly communicated between software engineers, it cannot be formally analyzed, and the conformance of an implementation to the design cannot be formally verified.\ud \ud In this chapter, we address this problem for the design and documentation of the behavior implemented in procedural programs. We introduce a solution that consists of three components: The first component is a graphical language called VisuaL, which enables engineers to specify constraints on the possible sequences of function calls from a given program. Since the specifications may be inconsistent with each other, the second component of our solution is a tool called CheckDesign, which automatically\ud verifies the consistency between multiple specifications written in VisuaL. The third component is a tool called CheckSource, which automatically verifies that a given implementation conforms to the corresponding specifications written in VisuaL.\ud \ud This solution has been evaluated empirically through controlled experiments with 71 participants: 23 professional developers of ASML, and 49 Computer Science M.Sc. students. These experiments showed that, with statistical significance of 0.01, the solution reduced the effort of typical maintenance tasks by 75% and\ud prevented one error per 140 lines of source code

The REVERE project:Experiments with the application of probabilistic NLP to systems engineering

Despite natural language’s well-documented shortcomings as a medium for precise technical description, its use in software-intensive systems engineering remains inescapable. This poses many problems for engineers who must derive problem understanding and synthesise precise solution descriptions from free text. This is true both for the largely unstructured textual descriptions from which system requirements are derived, and for more formal documents, such as standards, which impose requirements on system development processes. This paper describes experiments that we have carried out in the REVERE1 project to investigate the use of probabilistic natural language processing techniques to provide systems engineering support