In terms of database technology, an information model abstracts from the fine-grained detail of an actual implementation. To be of any value, the information model must be based on some well-defined formalism.

Early attempts to define data models stem from the area of database design. The first data models (hierarchical and network data models) directly described the physical data organization supported by a database management system (DBMS) and provided only low-level operations for data manipulations. The relational model is based on the formally defined relational theory and effectively insulates the user of a DBMS from the physical data organization. It provides, however, only scalar datatypes (boolean, integer, real, string) and flat relations as datatypes and therefore is not well suited to model technical domains.

A data model that allows to capture more semantics is the entity-relationship (ER) model by Chen [Chen 76]. This model represents information in terms of entities and the relationships between them. A major advantage of the ER model is that a graphical notation is defined for it which is the usual technique to capture ER models. Since its introduction, many extensions have been proposed to make it more suitable for the modelling of technical systems like electronic circuits. Of these, especially aggregation and generalization are of importance ([Smith 77], [Batory 85]).

With the more widely spread acceptance of the object-oriented concepts and the quest for a richer type system the EXPRESS language, now an ISO proposed standard [Spiby 93], has gained wider acceptance. EXPRESS is an object-oriented language used for information modelling. It comes with a graphical notation (EXPRESS-G) that provides graphical idioms for a subset of the textual EXPRESS language. EXPRESS-G diagrams share a major disadvantage with ER diagrams in that they are unordered. No natural entry point into the diagram can guide the reader in understanding such a diagram. More important, depending on the entry point chosen by a reader, an ER or EXPRESS-G diagram can mean different things.

We have chosen the Xplain semantic data model [terBekke 92] over the other approaches for its few and well-defined concepts and clear graphical notation (Figure 6).

---

Figure 6.

Xplain modelling concepts, graphical notation, and textual schema language. The graphical notation is ordered, i.e. an aggregate is always drawn above its attributes. This way, the edges in a diagram are associated with cardinalities. In the example, there is exactly one element of B for each element of A, while one element of B is related to zero, one, or many elements of A. Furthermore, A is a specialization of C: While C has the attributes D and E, A has the attributes B, D, E.

The key concept in Xplain is a type:

In addition, Xplain allows to specialize an aggregate type by adding new attributes to an existing type. For example, Table 7 shows the type extents of the types shown in Figure 6.

Xplain defines two inherent integrity rules for the types in an information model [terBekke 93]:

• Relatability
  Each attribute in a textual type definition is related to exactly one type with the same name as the attribute. Every type may correspond to a number of attributes.
  
• Convertibility
  Each type definition is unique; there are no two type definitions carrying the same name or the same set of attributes.
  

3.2 Syntax specification

The syntax specification language allows to define both lexical properties and syntax in a single specification file. While at this point this is merely a matter of convenience, it will become essential when using the language to capture input and output syntaxes in a single specification. Simple keywords can be directly placed into the grammar as symbols. Token classes have to be defined before their use by means of regular expressions.

3.2.1 Lexical properties

The following keywords are defined:

-export, -ignore, -left, -nonassoc, -pattern, -prec, -right,
-separator, -syntax, -type, list, opt, prec, range, repeat,
rule, syntax, token

token LINE_COMMENT -ignore <"//" .* $>
token BRACKETED_COMMENT -ignore <"/*" .* "*/">
token ID -pattern <[_A-Za-z] [_A-Za-z0-9]*>
token PATTERN -pattern <"<" [^>]+ ">">
token LITERAL -pattern <\" ( [^"\\] | \\[nt\\"] )* \">

3.2.2 Constructs for Extended Backus-Naur Form

rule word {
  | "opt" alternatives
  | "list" separator alternatives
  | "repeat" separator alternatives
}
rule separator {
    opt { "-separator" LITERAL }
}

• Optional parts are enclosed in curly braces and prefixed with the keyword opt. The replacement is:
  

rule opt { /**/ | alternatives }

• Optional lists are enclosed in curly braces and prefixed with the keyword list. The replacement for lists without separator is:
  

rule list { /**/ | list alternatives }

Lists with separators are resolved as follows:

rule sep_list { /**/ | tmp }
rule tmp { alternatives | tmp separator:LITERAL alternatives }

• Lists with one or more elements are enclosed in curly braces and prefixed with the keyword repeat. The replacement for lists without separator is:
  

rule repeat { alternatives | repeat alternatives }

Lists with separators are resolved as follows:

rule sep_repeat {
  alternatives | sep_repeat separator:LITERAL alternatives 
}

3.2.3 Structure of a language specification

syntax meta_spec {
  rule modules {
      repeat { "syntax" ID "{" list { token | prec } repeat { rule } "}" }
  }
} // syntax meta_spec

3.2.4 Declarations

rule token {
    "token" ID opt { "-ignore" } "-pattern" PATTERN
}

rule prec {
    "prec" prec_property list { ID | LITERAL }
}
rule prec_property {
    "-left" | "-right" | "-nonassoc" | /**/
}

3.2.5 Grammar rules

rule rule {
    "rule" ID alternatives
}
rule alternatives {
    "{" list -separator "|" { words } "}"
}

• a literal or a pattern,
  
• an identifier that denotes a token or a rule,
  
• an optional list of alternative words,
  
• a list (with either zero or one as the lower element count) of alternatives,
  
• or a subordinate set of alternatives.
  
  

rule words {
    list { opt { ID ":" } word } opt { "-prec" ID }
}
rule word {
    PATTERN 
  | ID | LITERAL
  | "opt" alternatives
  | "list" separator alternatives
  | "repeat" separator alternatives
  | alternatives
}
rule separator {
    opt { "-separator" LITERAL }
}

Footnotes

(1)

When presenting bits of syntax specification, we will frequently only use single modules or even only a few rules and will then omit the module header for simplicity.

[Table of Contents]

[2. Integration]

[Top of Chapter]

[4. Tool encapsulation architecture]