The kernel of a generic software development environment

syntax tree is not needed. Moreover, our ES acts as a two-way communication link. The unparser produces ES attribute values; the Abstract Workstation communicates the holophrasting level [Kah83] and the size of window frames where the produced ES have to be logged into. Sometimes, unparsing will start from a node in the abstract tree which is not the one communicated to the unparser. The idea is to give a perception of the output text which is the least tree-oriented as possible by restoring the line notion. The rule is to start from the leftmost node such that the unparsing of this node implies the unparsing of the communicated node on the first line of the result. The editor is structured from layered sets of primitives or toolkits; the highest level ones appear as options in menus which may drive the editing process. Navigation primitives are from two kinds. Visual primitives allow navigation from the current syntactical structure in terms of visible structures, e.g., access to the inner/ outer/ left/ right visual structure. Tree-oriented primitives allow navigation in terms of abstract syntax structures, e.g., access to the son/ father/ leftbrother/ rightbrother abstract structure. Another set of primitives allows refinement of a meta-node, insertion before/after the current structure, copy of the current structure on a tree stack, deletion of the current structure and pushing it on the stack, substitution of the current structure by the top of the stack, shift to an external line-oriented text editor for manipulation of the current structure, tree pattern matching, and so on. Another set of primitives allows a number of static informations about a formalism to be obtained, e.g., the name, code, or category of a node, the list of possible sons at ith position, the possibility of a path between two nodes, and so on. Many of the primitives from these various sets ‘use’[Par79] more elementary tree manipulation primitives from a lower level set. 4. Support for the management of lifecycle objects AS we suggested in Section 2, our Software Engineering Data Base [Soft811 is made of two components: the Model Database and the Project Database. This allows two environment levels, viz. a meta-environment level and an instantiated environment level. The first lifecycle management systems like CADES [Sno80] or ISDOS [Tei77] were dedicated to a specific lifecycle model. The ISDOS system was generalized into a generic version afterwards [Tei80], [Yam81]. Since then, a number of variants have been proposed around that pioneering work; see, e.g., [Dem82],[Ded85] for comparative analyses. The main variants concern the extensions made to the underlying ERA meta-model, the degree of sophistication of the consistency constraints which can be checked automatically, and the underlying DBMS used. Most of them provide a rather poor user interface , and extensions to the perticular lifecycle model meta-defined are difficult to handle. Also, they have primarily been focused on requirements database management. None of them allows formal texts to be attached to entities as special properties which can be manipulated syntatically. Let us have a look at some of the specific features of ALMA with these respects. 4.1. The instantiated environment level Three generic tools are provided at this level: the Project Database Updater, the Reporting system, and the Query system. The Reporting system provides various types of summaries about the Project Database. We skip it here since it is rather similar to those discussed in [Ded851 although the implementation technology is quite different. For instance, ’ some reports are produced by simple unparsing of annotated syntax trees, obtained from the corresponding Project Database fragments by means of toolkit primitives mentioned in Section 1. The Query system relies on an ERA query language dedicated to the specific lifecycle model which has been meta-defined; sophisticated checks and analysis of software objects and relationships are thereby supported. We skip it as well since its design is currently still in progress. The inputs to the Project Datubase Updater are statements in a formal documentation language dedicated to a specific lifecycle model. The FDL definition of the syntax of this language is generated by the meta-system from the model meta-definition and from a generic definition of the language structure. This allows documentation statements to be converted into abstract syntax trees and to be manipulated syntactically by means of the visual editor instantiated to that language. The documentation language is an ERA language. A documentation is organized into entity sections. An entity section refers to a software object instance; it contains an implicit declaration of the name of the object instance, one documentation statement per value of a property associated with the object in the model meta-definition, and one documentation statement per relation instance similarly associated with the object. Actually, different statements on a same property or on a same relation within a section can be merged into a single one if desired In general, a n-ary relation will be documented by n semantically (but not syntactically) equivalent statements found in n different sections. The language is typed, in that each object instance must belong to the appropriate object type and satisfy the semantic properties which have been meta-defined in the Model Database for that type; the Updater checks this. The language is also non-procedural, in that the order between sections and between statements within a section is irrelevant The example in Fig.1 should suggest how an entity section does look like. Remember that documentation statements about properties may consist in annotations i.e. texts written in other formal languages the FDL definition of which is known to the environment. Documentation entry and update is achieved via the syntax-directed editor instantiated to the documentation language. Perhaps we find one of the best situations here where menu-driven editing on the basis of the abstract syntax is a very powerful and convenient feature. This is because the user may wish the documentation language to ‘resemble’ a natural language subset; in such a case, the concrete syntax of DOC MODULE FTsubstit ; ASSIGNED TO (programmer) Buyse ON BUDGET kbar/soft/OJ WITH DEADLINE 01106/86 ; DERIVED FROM (function) tree-substitution ; ACCEPTS AS INPUTS (data) given-tree, (data) subtreel, (data) subtree WITH PRECONDITION . . .(formal specification). . . ; OUTPUTS (data) newtree WTTH POSTCONDITION . ..(formal specification)...; DESIGN-DECISIONS = . ..(informal or formal explanation)...; USES (module) FTcopy , (module) FCnson , (module) FTabstr-synt-verif ; C-CODE = . ..(formal C text)... ; IS A VERSION OF (module) . . . WITH DELTA . ..(formal text)... ; Fig.1 An entity section. the language may contain a lot of lengthy keywords. Thanks to the visual editor, the user may introduce its documentation without having to type any keyword. (