<?xml version="1.0" standalone="yes"?>
<Paper uid="P92-1042">
  <Title>DOCUMENTATION PARSER TO EXTRACT SOFTWARE TEST CONDITIONS</Title>
  <Section position="4" start_page="294" end_page="294" type="metho">
    <SectionTitle>
SYSTEM ARCHITECTURE
</SectionTitle>
    <Paragraph position="0"> The overall structure of the system is given in Figure 1. The input to the parser is a set of system documents and the output is testcase information. The parser has two main domain-independent components, one a testing knowledge module and one a general purpose parser.</Paragraph>
    <Paragraph position="1"> It also has two domain-specific components: a domain model and a sublanguage grammar of expressions for representing testable information in the domain.</Paragraph>
    <Paragraph position="2"> Figure 1</Paragraph>
    <Section position="1" start_page="294" end_page="294" type="sub_section">
      <SectionTitle>
Document Parser System
</SectionTitle>
      <Paragraph position="0"> XCS database dictionary which concern these test conditions.</Paragraph>
      <Paragraph position="1"> Input .................................. ~. Output ! Domain Independent !</Paragraph>
      <Paragraph position="3"> , , 1 i! Subfanguage grammar I i\] Domain Model 1 i L. ................................. I  For this to be a successful architecture, the domain-independent part must be robust enough to work for multiple domains. A person working in a new domain should be given the framework and have only to fill in the appropriate domain model and sublanguage grammar. The grammar developed does not need to parse the attribute descriptions of the input text exhaustively. Instead, it extracts the specific concepts which can be used to test the database. It looks at the appropriate sections of the document on a sentence-by-sentence basis. If it is able to parse a sentence and derive a semantic interpretation for it, it returns the corresponding semantic expression. If not, it simply ignores it and moves on to the next sentence. This type of partial parsing is well suited to this job because any information parsed and extracted will usefully augment the test system. Missed testcases will not adversely impact the test system.</Paragraph>
    </Section>
  </Section>
  <Section position="5" start_page="294" end_page="295" type="metho">
    <SectionTitle>
COMBINATION CONDITIONS
</SectionTitle>
    <Paragraph position="0"> In order to evaluate the effectiveness of the document parser, a particular type of testable condition for database tests was chosen: legal combinations of attributes and classes. These conditions include two or more attributes that must or must not be used together, or an attribute that must or must not be used for a class.</Paragraph>
    <Paragraph position="1"> The following are example sentences from the  1. If BUS-DATA is defined, then BUS must also be defined.</Paragraph>
    <Paragraph position="2"> 2. Must be used if values exist for START-ADDRESS or ADDRESS-PRIORITY attributes. 3. This attribute is appropriate only for class SYNC-COMM.</Paragraph>
    <Paragraph position="3"> 4. The attribute ABSOLUTE-MAX-PER-BUS must also be defined.</Paragraph>
    <Paragraph position="4">  Canonical forms for the sentences were developed and are listed in Figure 2. Examples of sentences and their canonical forms are given in Figure 3. The canonical form can be used to generate a logical formula or a representation appropriate for input to the test system.  Canonical forms of example sentences Sentence: If BUS-DATA is defined then BUS must also be defined.</Paragraph>
    <Paragraph position="5"> Canonical form: BUS must be defined if BUS-DATA is defined.</Paragraph>
    <Paragraph position="6"> Sentence: This attribute is appropriate only for class SYNC-COMM.</Paragraph>
    <Paragraph position="7"> Canonical form: BAUD-RATE can only be defined for class SYNC-COMM.</Paragraph>
    <Paragraph position="8"> THE GRAMMAR Since we are only interested in retrieving specific types of information from the documentation, the sublanguage grammar only has to  cover the specific ways of expressing that information which are found in the documents. As can be seen in the list of example sentences, the information is expressed either in the form of modal, conditional, or generic sentences. In the XCS database dictionary, sentences describing legal combinations of attributes and classes use only certain syntactic constructs, all expressible within context-free grammar. The grammar is able to parse these specific types of sentence structure.</Paragraph>
    <Paragraph position="9"> These sentences also use only a restricted set of semantic concepts, and the grammar specifically covers only these, which include negation, value phrases Ca value of,&amp;quot;) and verbs of definition or usage (&amp;quot;is defined,&amp;quot; &amp;quot;is used&amp;quot;). They also use the concepts of attribute and class as found in the domain model. Two specific lexical concepts which were relevant were those for &amp;quot;only,&amp;quot; which implies that other things are excluded from the relation, and &amp;quot;also,&amp;quot; which presupposes that something is added to an already established relation. The semantic processing module uses the testing knowledge, the sublanguage semantic constructs, and the domain model to derive the appropriate canonical form for a sentence.</Paragraph>
    <Paragraph position="10"> The database dictionary is written in an informal style and contains many incomplete sentences. The partially structured nature of the text assists in anaphora resolution and ellipses expansion for these sentences. For example, &amp;quot;Only relevant for software&amp;quot; in a sanity check for the BACKWARD-COMPATIBLE attribute is equivalent to the sentence &amp;quot;The BACKWARD-COMPATIBLE attribute is only relevant for software.&amp;quot; The parsing system keeps track of the name of the attribute being described and it uses it to fill in missing sentence components.</Paragraph>
  </Section>
class="xml-element"></Paper>