<?xml version="1.0" standalone="yes"?>
<Paper uid="E87-1039">
  <Title>Acquisition of Conceptual Data Models from Natural Language Descriptions</Title>
  <Section position="2" start_page="0" end_page="241" type="intro">
    <SectionTitle>
1 Introduction
</SectionTitle>
    <Paragraph position="0"> This section introduces the application of computer-based tools for information systems requirements analysis, design.</Paragraph>
    <Paragraph position="1"> and implementation, and outlines a motivation for endowing such tools with natural language interfaces. It concludes with the structure of the remainder of the paper.</Paragraph>
    <Paragraph position="2"> Information systems development suffers from two widely acknowledged problems: * an applications backlog, whereby demand for applications exceeds resources available for its satisfaction.</Paragraph>
    <Paragraph position="3"> * a requirements analysis problem. This is often manifested as a maintenance problem, whereby resources that could be put into reducing the applications backlog are instead devoted to correcting faults in delivered systems. Most such faults are traceable to erroneous specifications, resulting from a failure to establish user requirements correctly.</Paragraph>
    <Paragraph position="4"> The industry has provided solutions to each of these problems: The problem of productivity has been addressed by the provision of more powerful higher-level languages known as 'application generators' or 'fourth generation languages ' (4GLs), in which the same functionality can be achieved in a tenth or less of the instructions needed in a conventional procedural computer language.</Paragraph>
    <Paragraph position="5"> A general feature of such software tools is that they do away with the need for much procedural programming by employing declarative notations in which requirements can be expressed in sufficient detail for the software to provide procedures to meet them. (Naturally, the sophistication of these declarative notations varies according to the breadth of their application coverage.) The requirements analysis problem has been addressed since the mid nineteen-seventies by a range of prescriptive development methods providing working procedures and graphical representation languages, in place of traditional approaches which rely heavily on natural language narrative to specify prooessing requirements. A typical representation or conceptual modelling language is described in section 2.</Paragraph>
    <Paragraph position="6"> A problem with both the high-level application generators and the development methods is that they have been established independently by a variety of manufacturers, software houses, consultants and academics, resulting in a multitude of competing products and methods, with no standard accepted by the industry. Suppliers and users therefore face considerable training and consultancy costs due to staff mobility.</Paragraph>
    <Paragraph position="7"> A more recent trend is to combine the two approaches to produce a more powerful software tool environment or analyst's workbench which enables the analyst to edit diagrams that formally represent the requirements, and using these specifications to automatically generate computer programs. Such tools represent an improvement on previous practice in two ways: firstly by bringing forward the use of precise formal languages from the coding to the specification phase in the software life-cycle, and secondly by automating the coding phase. However, they do not similarly automate the analysis phase that must precede the formal expression of requirements in a specification, although they may mechanize the process of recording and revising a specification.</Paragraph>
    <Paragraph position="8"> The nature of such tools is described in section 3.</Paragraph>
    <Paragraph position="9"> It is proposed that a natural language interface to tools provided to mechanize such methods would provide several benefits: It is possible to develop a specification using a representation language with which the analyst is not  familiar, by hiding the representation language from the analyst.</Paragraph>
    <Paragraph position="10"> It can alternatively help the analyst learn the specification language by displaying the graphical representation of a given description.</Paragraph>
    <Paragraph position="11"> With a natural language generation facility it is possible for an analyst to informally verify that a graphical representation of some aspect of a system expresses the desired meaning.</Paragraph>
    <Paragraph position="12"> A natural language generator can be used to translate a specification developed by someone else using a representation that the reader is not familiar with. In addition to facilitating communication between analysts ~ained on different methods, this technique could facilitate communication between analysts and their users or expert informants.</Paragraph>
    <Paragraph position="13"> A further motivation is that increasingly, the 4GLs described above are in the hands of end users who develop applications directly. 4GLs typically make straightforward applications easy to develop, often prompting the users for the parameters that specialize the application as an instance of the stereotype systems that lie within the tool's application bandwidth. However, they are often poor at enabling more elaborate requirements to be met where there are interdependencies between data Ides and complex integrity and validation rules. A tool built on the lines described below cart help end users inexpert in analysis to articulate their own requirements and then to convert those requirements into executable code.</Paragraph>
    <Paragraph position="14"> The architecture of an information systems development workbench with an integrated natural language and graphics interface is described in section 4. An approach to knowledge representation within this system is discussed in section 5. Approaches to natural language analysis and generation and the results of some prototyping work are discussed in section 6.</Paragraph>
  </Section>
class="xml-element"></Paper>