page 1  (13 pages)
2to next section

CLAW 96, The First International Workshop on Controlled Language Applications, Katholieke Universiteit Leuven, 26-27 March 1996

Attempto Controlled English (ACE)

Norbert E. Fuchs, Rolf Schwitter

Department of Computer Science, University of Zurich

CH-8057 Zurich, Switzerland

{fuchs, schwitter}@ifi.unizh.ch

Attempto Controlled English (ACE) allows domain specialists to interactively formulate requirements specifications in domain concepts. ACE can be accurately and efficiently processed by a computer, but is expressive enough to allow natural usage. The Attempto system translates specification texts in ACE into discourse representation structures and optionally into Prolog. Translated specification texts are incrementally added to a knowledge base. This knowledge base can be queried in ACE for verification, and it can be executed for simulation, prototyping and validation of the specification.

1 Motivation

Somewhere between ridiculous pedantry and erroneous formulation there presumably exists a reasonably precise way of specifying a problem in English [Dodd 90].

Creating reliable software is hard. One of the worst obstacles to build a good software product grows out of shortcomings in writing a complete, consistent and unambiguous requirements specification. Managers and domain specialists often find it extraordinarily difficult to formulate specifications since at the beginning of the requirements engineering process the knowledge is usually informal, incomplete and opaque, and many ? possibly conflicting ? personal views of the system exists. Nobody knows what exactly the program should do until there exists a first version to run.

Requirements specifications are mostly written in natural language because they need to be understood by all participants. This involves a risk since the expressive power of unrestricted natural language can tempt people to write ambiguous or even incomprehensible statements. Apart from natural language people use arbitrary graphics, or semi-formal representations like structured analysis or entity-relationship diagrams that often have no formal semantics, or a poorly defined one, thus making formal reasoning impossible [Pohl 93].

Even when the software development team gets an acceptable requirements specification there can be problems because different people may understand the same document differently. To avoid disparate interpretations of a document, people have suggested to use formal methods [Hall 90]. However, formal languages are not easily understood by untrained users. Moreover, it is far from trivial to derive a formal specification from informal requirements since this derivation process cannot be formalised and cannot be formally validated [Hoare 87]. In the end, natural language comes back in through the back door when the formal specification must be accompanied by a natural language description that paraphrases 'what the specification means in real-world terms and why the specification says what is does' [Hall 90]. It seems that introducing formal methods into the predominantly creative process of software development runs into immense difficulties.

But there is a way out. The specification language Attempto Controlled English (ACE) combines the familiarity of natural language with the rigor of formal languages. ACE enforces writing standards that restrict the grammar and the vocabulary, thus leading to documents containing more predictable and less ambiguous language. ACE helps people to find an agreement about the correct interpretation of a requirement specification. When domain specialists and software developers are guided to use the