In the last chapter we identied the architecture components that are tool-specic. They are tool-specic because they depend on the syntax and static semantics of the language supported by the tool, the consistency constraints to other documents and the particular editing, analysing and browsing commands that are to be oered by the tool. Although a signicant amount of code for architecture components can be reused, the implementation of the tool-specic components is still far too time consuming. We thus suggest a number of domain-specic graphical and textual languages that a tool builder can use to systematically and eectively engineer the tool-specic components. We call these languages GOODSTEP Tool Specication Languages (GTSL)1.
These specication languages must be able to express the dierent concerns that vary from tool to tool. They should provide dierent levels of abstraction in order to support a tool builder in the step-wise renement of a tool specication. The highest-level language should provide a concise overview of the tool specication components. This overview will aid the tool builder in getting a specication development started. We are going to dene an extended and normalised BNF that serves this purpose. The productions of the BNF will then be used to identify increment classes. A lower-level language will allow a tool builder to dene the structure of increment classes, such as semantic attributes and relationships with other increment classes. We will customise OMT entity relationship diagrams for that purpose. At the lowest level of abstraction, we will then provide a language for the denition of increment class behaviour. This language will enable increment layout and increment-specic commands as well as static semantics and inter-document consistency constraints of increment classes to be dened.
The specication languages will provide primitives for reusing and customising predened increment class specications2. Customised specications will, in turn, be reusable in the
same way as predened specications. The specication languages that we suggest will follow the object-oriented paradigm in order to achieve this. The structural and behavioural concerns dened in increment classes are inherited by subclasses and are thus reused there. Classes can
1The languages that we present here have been developed and evaluated within the ESPRIT-III Project 6115
(GOODSTEP) [GOO94]. We dedicate the name of the languages to this project to acknowledge the benets that we gained from working in its stimulating scientic atmosphere.
2These are, in fact, the specications of the classes that are contained in the predened schema.
be customised to address more specic problems by redening concerns. The eort required for the specication of a tool will then merely depend on the degree to which the required properties dier from predened properties.
In the next section we will discuss the requirements that the dierent languages must meet. In Section 6.2, we will suggest a language for dening extended and normalised BNFs (ENBNFs) so as to dene the concrete syntax of a language that is supported by a tool. Section 6.3 sug- gests customisations to the OMT entity relationship model to make it particularly suitable for the structure denition of increment classes. An entity relationship model then appropriately visualises navigation paths between increments that are required for dening static semantics and inter-document consistency. The detailed behavioural increment class denition is struc- tured into an external class interface denition and an internal class specication. Section 6.4 discusses class interface denition, while we present the language primitives for class speci- cations in Section 6.5. We conclude this chapter with a comparison with related work where we indicate the contributions of this thesis to state-of-the-art tool specication.
In the next chapter, we will discuss a tool builder's requirements for an integrated develop- ment environment for tool specication. This environment will contain a tool for each of the languages that are discussed in this chapter. Moreover, the environment will check and even preserve inter-document consistency constraints that exist between the dierent languages. We cannot reasonably discuss these inter-document consistency constraints in this chapter, since their denition can only be understood after all the dierent languages have been introduced.
6.1 Requirements of Tool Specication Languages
In order to set the scene for this chapter, we have to discuss language design issues, i.e. we must dene the requirements that the dierent specication languages must meet. The languages should be specic to the domain of tool specication in order to support tool builders as much as possible. This implies that the languages can express all the information required to generate the tool-specic components of the tool architecture as identied in the last chapter. Only then will it be feasible to build a compiler that generates executable tools from the specication without having to code further components manually. The languages should, therefore, provide dedicated language constructs for the following concerns.