Computer Science Technical Reports Technical Report No. 1996/02 Environments for Group-Oriented Software Design The Groupie Experience Wolfgang Emmeri

Computer Science Technical Reports Technical Report No. 1996/02 Environments for Group-Oriented Software Design The Groupie Experience Wolfgang Emmerich and Wilhelm Schafer July 1996 ISSN 1364-4009 City University Dept. of Computer Science Northampton Square London EC1V 0HB United Kingdom

Environments for Group-Oriented Software Design The Groupie Experience Wolfgang Emmerich The City University Dept. of Computer Science Northampton Square London, EC1V 0HB, UK Phone:+44 171 477 8322 Fax: +44 171 477 8587 we@city.ac.uk Wilhelm Schafer Universitat-GH Paderborn Fachbereich 17 33095 Paderborn Germany Phone:+49 5251 60 3312 Fax: +49 5251 60 3530 wilhelm@uni-paderborn.de Abstract Designing and implementing a large-scale software product is usually a team-oriented activity, which concerns in particular the concurrent development of parts of the design and of the implementation. In general, current design methods and the corresponding tools do not adequately support such a team-oriented activity. On the basis of our experiences in constructing and using the Groupie environment we have drawn a number of conclusions. We suggest the notion of subsystems as an extension of a fairly standard design language based on abstract data types. We describe how environments can support cooperation between engineers. We discuss work assignment based on subsystems, automated protocols for the negotiation of subsystem changes, automated notications of interface changes to other team members and automated change propagation. We suggest an implementation of environments exploiting the features of an object database management system (ODBMS). An examination of a tight integration between design and implementation is a further specic contribution of this paper. We reveal that design languages have to be adapted to the use of particular programming languages. We underpin this hypothesis with experience gained from mapping the design notation to C, Modula-2 and ML. In summary, the paper presents principles for design languages and their implementation in CASE environments that provide sophisticated multi-user support. A substantial subset of the functionality described here has been turned into a commercially available environment. 1 Introduction Among the most important documents in a software system's life cycle is the system design. It should capture the system structure in terms of well-dened parts called modules encapsulating This work was done while both authors were aliated with the Dept. of Computer Science, University of Dortmund, Germany 1

the main design decisions. The design serves as an important basis for maintaining a system, for reusing parts of a system in the same or other projects, for systematically testing and debugging parts of a system and for coordinating integration testing. As we shall see, the design can even be used as a basis for project scheduling and work assignment. Anumber of approaches to design are based on the idea of object-orientation [Boo91, JCJO92, RBP + 91] or, in more general terms, on data abstraction. Those approaches include either languages that are a combination of a design and implementation language like Ada, Modula-2 or Eiel, or they are independent of particular programming languages. The latter are frequently called module interconnection languages, for example WRIGHT [AG94], [CFGGR91], HOOD [HOO89], Instress [Per89] and CONIC [KMS89]. All these languages allow engineers to dene the static properties of modules; WRIGHT and even enable the dynamic semantics of modules to be dened. We agree that this is important, but set the problem aside in favour of a detailed treatment of how to support the cooperation of multiple developers. As in these approaches, we provide primitives for dening modules and module dependencies. In addition, we suggest the distinguishing of dierent types of modules so as to capture the dierent roles that modules play in a design. Furthermore, we reason about mappings from a design to existing programming languages, such as C, ML, and Modula-2. These mappings have not been examined to any level of detail in the literature. Moreover, the application of most of the above approaches is in practice inhibited; they do not provide the required support for concurrent and cooperative design and for implementation by teams of engineers. Our experience, which is based on advising a number of software houses on the design of their industrial projects, suggests that design and implementation of almost any software project of non-trivial size occurs in a distributed and concurrent fashion. This should be reected in the language used for software design as well as in the environment that is used during design. To date only very limited support is available in this respect. Inscape [Per89], the environment supporting Instress, and an environment called STILE [SW91] address the issue of support for concurrent development by multiple engineers. Both, however, incorporated a rather general strategy in their environment, but without giving details of the environment's functionality resulting from this strategy and, more importantly, without showing how strategy can be implemented. In more detail, STILE proposes a strategy for exploiting knowledge about the semantics of software documents in order to improve the number of concurrent accesses to the same document. This is exactly what we do in our approach, but we also combine this idea with the use of real languages and with tools that implement them. This makes the approach really practical applicable, especially during design. Our approach has aspects: negotiations through automatic composition of mails, automatic mailing, selective change propagations and the description of our implementation. In summary, the main new features of our approach are: 1. use of design languages not only for structuring complex design documents but also for dening team structure and negotiation rules for managing software projects, 2. detailed analysis of mapping designs to programming languages, 3. discussion of group-oriented support environments on the basis of the Groupie environment, which supports all the above sketched concepts and supports the areas programming in the small, programming in the large and, to some extent, project management in 2

a tightly integrated way,and which also supports incremental, intertwined development of all areas concerned, 4. support of team coordination and cooperation based on the dened team structures through a built-in but adaptable message communication facility, 5. automatic Makele composition by exploiting the dependencies dened between modules in the design, and, 6. use of an object database management system [Cat93] as the underlying platform to implement cooperation of multiple engineers. The paper is structured as follows: The next section describes our experiences in dening a design language and mapping it to various programming languages. Section 3 highlights the language features that enable multiple engineers to design and maintain software systems cooperatively and concurrently. Section 4 derives functional requirements of a support environment from language concepts developed in Section 3. Section 5 sketches the implementation of support environments on the basis of object database management systems. Finally, Section 6 concludes by sketching ongoing and further work. 2 Dening a Software Design Language In this section we will discuss our experiences in dening software design languages. To illustrate the discussion, we will use examples from the Groupie language, an extension of the language suggested in [Lew88a] incorporating concepts supporting large-scale development. 2.1 Module Types and Import Relationships Any language for software design should support the principles of data abstraction and information hiding suggested in [Par72]. The language should enforce these principles so that systems are decomposed into fairly independent modules. Logically, a module represents a set of related design decisions. To enforce the information hiding principle, a module should have an export interface, which denes exported resources. Resources can, for instance, be operations or types. Resources that are not exported must not be accessible from outside the module. Modules may use resources exported by other modules. The use of these exported resources should be made explicit in so called import relationships so as to highlight module dependencies. These dependencies are important for change impact analysis, for scheduling the development of modules and for determining an order for independent module compilation. Dierent modules play dierent roles. In our experience, design understanding can be considerably simplied if these roles are made explicit. Any design will contain modules, for instance, that play the role of factories, which are used to create instances of certain types. If this information is passed to a reader of a design, he or she will nd it much easier to understand the purpose of these modules. We, therefore, suggest the identication of dierent module types in the design language. To distinguish module types dierent icon representations should be used in graphical representations and dierent keywords in textual representations to distinguish module types. The Groupie language includes the following module types: 3

Abstract data types (ADT) are those which encapsulate one type and its operations; they correspond to an abstract data type or to a class in the object-oriented terminology. An ADT may be used in other modules to create instances of its type. Abstract data objects (ADO) encapsulate a type and its operations, but only export operations and not the type denition itself. They thus specify that only one instance of this type exists during runtime because no other module can create an object of this particular type. Function modules (FM) encapsulate a group of functions without any related type. Such a module itself has no internal memory the invocation of any export operation behaves deterministically. Type collections (TC) provide a construct to dene system-wide basic types, for example boolean, integer (or subtypes thereof), which are derived by renaming or combining predened types and are used especially to specify parameter types of exported operations in other modules. The reason for not dening them in separate ADT-modules is that, being geared towards later implementation of the system, they unnecessarily expand the size of a system architecture. In our experience, software designs should be considered at dierent levels of abstraction. Architectural design provides the high-level abstraction that is required for early development stages or for a reader to obtain an overview. It will also be used to identify the main building blocks of a system, to showhow it is decomposed into modules and to visualise import relationships among them. Icons and arrows can eciently represent modules and import relationships respectively. While development continues, engineers will have to rene individual modules during interface design. The engineers should dene the exported resources and enumerate the particular resources imported from other modules. We nd textual representations of this more appropriate than graphical ones. The example in Figure 1 illustrates two dierent levels of abstraction provided by the Groupie language. The gure presents a small excerpt of the design of Groupie itself. 1 Modules and their import relationships are shown in a graphical notation on the left-hand side. A module is depicted as a rectangle and an arrow leading from A to B denotes that module A imports from module B. The textual description on the right-hand side is an example of the description of a module interface denition, namely of module CMControl. Note how the import interface in the textual denition renes the arrows representing import relationships in the graphical notation. 2.2 Mapping Designs to Programming Languages Our experience with software design in industry strongly suggests that engineers are reluctant to spent eort on a software design, if it cannot be automatically translated into code frames for the implementation of modules in the programming language that they use. Therefore, the mapping of a design language to various programming languages also has to be addressed. Moreover, engineers will set the design aside and allow it to be inconsistent with an implementation if design changes cannot be incrementally reected in the source code. An integrated 1 Groupie's design has been fully dened by using Groupie as the support environment. 4

Figure 1: Module types and relationships (graphical and textual notation) environment must implement the mappings between design and source code in a way that allows for incremental and intertwined development of design and implementation. It has often been claimed that design languages should be independent of any particular programming language [Lew88b]. If this is the case, it should be possible to dene reasonable mappings from the design language into any programming language. In the rst edition of his book [Boo91] Grady Booch is less ambitious, but still argues that a Booch design can be implemented with any object-oriented programming language. We agree that this is a very desirable objective and we set out to provide evidence that the Groupie design language could be mapped to dierent programming languages in dierent paradigms. We dened three mappings: to C, which had to bridge a gap to a programming language with very limited modularisation concepts, to standard ML [MTH90], which had to bridge a gap to a functional programming language, and to Modula-2. The mapping to Modula-2 was simple, mostly because Modula-2 is centred around the concept of a module, which can hide a subset of its resources and which requires explicit import relationships to use exported resources from other modules. We, therefore, focus now on the lessons that we learned from the mappings that were less straightforward. Figure 2 displays the results of mapping the module CMControl (already used in Figure 1) to SML and C. The C mapping maps each module interface specication to a header document, 5

Figure 2: Function Module mapping to SML and C an example of which is displayed on the right-hand side of Figure 2. Each of these header documents contains a typedef declaration for each exported type and function prototype, declared using the extern linker directive for each exported operation. Any import statement of the module interface denition is mapped to a preprocessor directive, which textually includes the header document of the respective imported modules. The #include directives inserting CMDescriptor.h and BasicTypes.h are examples of this. Thus, the preprocessor compiles a header document of a module into a le that textually contains all headers of all imported modules. To ensure that each header is only included once, a header document is guarded by a preprocessor switch, which only declares the types and operations if the document has not been included before; the #ifndef directive takes care of this. Due to the absence of dedicated import statements in C the mapping inserts a comment after each #include directive that enumerates all imported types and operations. A number of properties of the design language, however, cannot be mapped to C. As an example consider the visibility of resources. In the design language only those resources from other modules are visible that have been explicitly imported. The #include statement is not so selective and declares all resources that have been dened in the included header document. Moreover, only those resources are visible in a module that are either declared in the module itself or that have been imported by the module. The approach of mapping imports to C- preprocessor #include directives, however, results in the declaration of all the resources that are dened in the transitive closure of included header documents. This means that there is a mismatch between the visibility of resources in design and the actual implementation. If this is undesirable, either the use of resources in C has to be restricted to conform to the visibility rules dened in the design language, or the design language has to be adapted to the visibility rules of C. We are very much in favour of the rst solution, but this requires that non-standard tools for checking the restricted use of C should be integrated into the support environment. For the SML mapping, we exploit SML signatures as implementations of module interfaces. The left-hand side of Figure 2 displays such a signature. Signature names are derived from the corresponding module name by translating them into upper-case letters. Structures are the 6

implementation of body specications. Their names are given in lower-case letters. Complete signatures are derived from interface specications whereas a structure is generated as a code frame which needs to be completed manually. The signature derived from a module is attached to the corresponding structure. Therefore the structure denition loads its corresponding signature. Consistency checks between design and implementation can be done by the SML interpreter by checking for a signature match against the signatures that have been derived from the current interface specications. Import relationships between structures are implemented by the use interpreter directive, which loads the corresponding structure into the interpreter. In Figure 2 the structures stored in the CMDescriptor.sml and BasicTypes.sml are loaded. An imported name includes the imported structure's name as a prex. For the SML mapping we were faced with two dierent kinds of problem. Firstly, not all concepts of the design language are available in SML and secondly, there are powerful concepts in SML that cannot be used since they have no counterpart in the design language. An example of the rst problem is parameter passing. Being a functional language, SML only supports call-by-value parameter passing. Consequently functions only have a return value, but no in-out parameters. We addressed this by providing a language variant and also a Groupie variant that only oers IN parameters; in eect we had to adjust our own design language to the use of SML. Examples of the second kind of problem are the function parameters of functions, generic data types and inheritance. These powerful language concepts of SML are not generated by the mapping because the design language does not incorporate them. We have not extended the Groupie language with these concepts since they are not available in C and would have caused problems in the industrial use of the system. We have learned the lesson that design languages, which are completely independent from programming languages, are inappropriate for practical use. There should always be a mutual inuence as language constructs are dened. In practice it will be necessary to provide a dedicated design language for each dierent programming language. Further evidence for this observation is provided by [Boo94]; the newer version of Booch's notation contains languagespecic adornments, geared towards implementation of object-oriented architectures in C++. 2.3 Subsystems It is an important observation that designs of non-trivial software systems tend to become rather complex if described in terms of modules and their relationships. To cope with this complexity, we suggest extending the idea of information hiding from programming to architectural design. We suggest subsystems as a language concept in support of such an extension. Subsystems will allow engineers to generate abstractions, which hide unnecessary levels of detail within their denitions. A subsystem groups modules, and possibly other subsystems, so that an architectural design is constructed as a hierarchy of subsystems. The denition should also declare an export interface for the subsystem. Only those modules included in the export interface should then be visible from outside the subsystem and any other should be hidden. The principle idea of subsystems is very similar to the notion of systems in [HP81]. The way we use the subsystem construct eectively, as a vehicle to support concurrent development of multiple engineers is, however, unique to our approach. Typical examples of subsystems would be a set of application specic window types (where, in turn, each window type may be represented by a module), a specic I/O device driver, a database system, or the applicationspecic access interface to a database system. 7

Figure 3: Example of a subsystem (graphical and textual notation) Using a specic example, we now discuss by means of an example how subsystems are incorporated into the Groupie language. The modules depicted on the left-hand side of Figure 1 form the denition of a subsystem that we refer to as ComMgr. A square in the upper left corner of a module icon denotes that the module is exported. The modules exported by ComMgr are CMControl, CMDescriptor and BasicTypes. The left-hand side of Figure 3 shows ComMgr is part of the enclosing subsystem denition, Groupie dened at the next higher level of abstraction. On that higher level ComMgr is represented as an icon with an underlying shadow and import relationships represent the use of resources in one subsystem that are exported by other subsystems. A more detailed description of the subsystem's export and import interfaces is provided by the textual representation on the right-hand side of Figure 3. The export interface of the subsystem is the union of all types and operations exported by the subsystem's exported modules. In this example it is the union of types and operations exported by CMControl, CMDescriptor and BasicTypes. The import interface of the subsystem is the union of all import interfaces of all modules that are included in the denition of ComMgr. In summary, a subsystem has four dierent representations (containing various degrees of details). These are the graphical and textual representation of the subsystem interface, as shown in Figure 3, and the graphical and textual representation of modules or nested subsystems in its denition, as shown in Figure 1. The visibility of these components is restricted by scoping rules of the language. One direct route to eective cooperative design is via minimisation of engineers' need for cooperation. The scoping rules of the design language can be dened in a way that they contribute to this goal. A need for communication and cooperation between teams or individual engineers arises whenever exported resources dened by one engineer can be, or are actually, 8

used by another engineer. If the design language restricts the visibility of resources in a sensible way, it will guide engineers towards designs that require less communication and cooperation eort and are thus easier to deal with. A subset of the scoping rules that we have dened for that purpose in the Groupie language are: 1. A hierarchy of subsystems builds a hierarchy of nested name scopes (similar to namespaces in C++). 2. A resource imported from a module or subsystem must be dened in the export interface of the imported module or subsystem. 3. A subsystem B contained in another subsystem A can only import from modules or subsystems which are either (1) also contained in A, i.e. they are siblings of B in the contains-hierarchy of subsystems, or (2) they are already imported by A. Rule 1 requires that names in dierent modules or subsystems are made unambiguous by adding (conceptually) the name of the enclosing module or subsystem as a prex. This rule gives an engineer the freedom to choose the name of a module independently of other engineers giving names to modules contained in other subsystems. Cooperation that would be required in case of name clashes is avoided. Rule 2 unambiguously identies the partner for negotiations about a particular resource. This will be the individual or team in charge of the module or subsystem the resource is imported from. Requests for particular changes can then be explicitly directed to this (team of) engineer(s). Other engineers need not be involved. Rule 3 guarantees the aforementioned information-hiding principle of the architectural design. In particular, it restricts the set of engineers that can actually use a resource. Communication, for instance the announcement of a change, is then only needed among restricted set rather than the whole development team. M A0 A MB 0 B MC 0 C MD 0 D ME 0 E MC MC 1 2 M D1 M D2 M E M 1 E 2 MF 0 F M B1 MF M 1 F 2 Figure 4: A Hierarchy of Subsystems As an example of the last constraint consider Figure 4, which describes a hierarchy of six subsystems (and a few modules) and in particular indicates their internal structure. The full range of a subsystem is indicated by a dashed rectangle, i.e. the denition of subsystem A contains two subsystems B and C respectively as siblings in the subsystem hierarchy. Subsystem B, in 9

turn, contains subsystems D and E and modules M B0, M B1, whereas subsystem C contains a few modules (M C0, M C1 and M C2 ) and subsystem F, which contains only modules. For the sake of simplicity import relationships have not (yet) been dened in this example. Under the constraint dened above, module M B0 is only allowed to import from subsystems D and E and from module M B1, but never directly from subsystem C or its subsystems or modules. If we nowintroduce an import relationship so that B imports from C, then this expands the scope of possible imports for all modules and subsystems contained in B. Then M B0 could import M C0 as it is the export of subsystem C. This is an example of the second part of Rule 3 above. M B0, however, cannot import from M C1, since this module is not exported from subsystem C (as indicated graphically by the absence of a square from the upper-left corner of the icon). Modules may be exported from a subsystem unless they are nested. If we were to allow exports of nested subsystems, this might possibly result in an import relationship between one fairly high-level subsystem and another fairly low-level subsystem, if that low-level subsystem was exported a number of times along the subsystem hierarchy. As a consequence communication activities, i.e. possible negotiations between responsible engineers, could signicantly increase. Logically, subsystems should be considered as separate abstract machines in a layered architectural design. Therefore, export of a subsystem interface passing through various levels of the hierarchy does not make sense. Instead, new access modules must be introduced in the export interface of a subsystem, which will then import from nested subsystems and thus facilitate export from those nested subsystems. In this way, layering is preserved, because access modules are tted into the right architectural layer. 3 Process Model Given that multiple engineers work on the denition and implementation of a software design, they have to agree to and then follow a particular development process. This section discusses our experiences in the denition of a model for such a process. The model denes how the responsibilities of the engineers involved are dened, determines access rights to design components and the implementation of each, and identies communication and cooperation patterns between engineers. The central idea is to determine all these issues according to the decomposition of a design into subsystems. To develop a subsystem means both to design that subsystem and to implement the bodies of all its modules in a programming language. Delegating the programming task for a module to the engineer who has designed it rather, than identifying dierent engineers for designing and programming as is often proposed, is based on the fact that interface designs in our language already include types and operations; thus a separation between designer and groups would be rather articial. A consequence of separation would be the signicant communication overhead required to explain the implementation strategy for types and operations that has already partly to be planned during interface design. This decision is underpinned by a lot of practical experiences with Groupie, a major part of Groupie having been commercialised and now in daily industrial use (see also Section 6). The responsibility for a subsystem is assigned to a group of engineers, who will then be in charge of developing that subsystem. Any group consists of its group members and a group leader who is the owner of the subsystem. The leader controls the design of the interface of the 10

subsystem assigned to that group and he or she is the negotiator with other group leaders who are owners of other subsystems on the same level of the subsystem hierarchy within the same enclosing subsystem. Thus, group leaders themselves form a group, responsible for the next higher level in the subsystem hierarchy. In summary, the nesting of group structure mirrors the nesting of subsystem hierarchy. Consequently, the overall responsibility for system design lies with the owner of the top-level subsystem. M A0 A/G /O 0 0 MB 0 B/G 1/O1 MC 0 C/G 2/O2 MD 0 D/G 3 /O3 ME 0 E/G 4/O4 MC MC 1 2 M D1 M D2 M E M 1 E 2 MF 0 F/G 5/O5 M B1 MF M 1 F 2 Figure 5: Sample Task Assignment As an example consider Figure 5, which is a variant of Figure 4 in the last section annotated with the names of groups and owners. The annotation in the upper right corner of each rectangle gives the name of the subsystem, group, and group leader in the form subsystem/group/group leader. Group G 0 consists of the group leader O 0 (who thus has overall responsibility) and its members O 1 and O 2. Members O 1 and O 2 in turn are group leaders (and members) of groups G 1 and G 2 and owners of subsystems B and C. As B is rened into subsystems D and E with groups G 3 and G 4 being assigned to them, group leaders O 3 and O 4 of those groups G 3 and G 4 form group G 1 together with their group leader O 1 and so on. The dashed rectangles bound the areas of responsibilities, i.e. the ownership partition of the overall software design. The advantage of such a nested group structure is that necessary communication to achieve a consistent design is minimised and that even for large projects (we have examples containing a few hundred modules and subsystems) the structure of the development team and the corresponding software is still easy to manage. Minimisation of communication is also the reason for not dening ownerships for single modules. Ownership dened by subsystems forces engineers to construct systems from subsystems and not to spoil the design by basically not using subsystems. The more responsibility has to be shared (in usually large projects), the more subsystems have to be dened, whereas small single engineer (sub-)projects can be conducted without using subsystems. The read and write access rights for the dierent groups can now be derived from the group structure by adhering to the scoping rules dened above. A group leader has write access to every module of the assigned subsystem. The whole group has read access to every component interface from which a type or operation can be imported according to the static semantics constraints as given in Section 2. This right enables them to review the way the resources that they export are being used. Group leaders, in addition, get read access to each subsystem (transitively) included in their subsystem, because as negotiators in discussions within their 11

groups they can thus better overview the whole subsystem and decide on rearrangements of the design. In summary, the strict policy on write access rights ensures a highly consistent design without the possibility of a group introducing bad side eects into the design of another group. Read access rights are granted more freely to ensure as much overview about (parts of) the design as required without diluting this overview by too many details. So far, our approach structures and minimises communication in building a consistent design. A need for communication and cooperation between dierent groups, however, arises whenever inconsistencies have been introduced. We intentionally allow those inconsistencies to arise in order not to hamper concurrent development of dierent subsystem. They can happen in three cases that deserve our particular attention; we address them explicitly in the support environment in outlined Section 4. In the rst case, a engineer can import a type or operation, although that type or operation has not (yet) been dened. If we were not to tolerate this inconsistency, we would be enforcing bottom-up design. Exports would have to be dened always, before they could be imported, pragmatically an unacceptable approach. The resolution of such an inconsistency, however, is nicely supported by the well-dened group structure. If a non-existing import is requested, a note (requesting such an import) will be sent to the owner of the subsystem from where the import comes. In the second case, a consistent import would become inconsistent if the name of the corresponding exported resource were to be changed. Such a change should be done consistently in all the importing modules. The communication pattern that engineers should obey is the following: A note should be sent to every owner of a subsystem that imports the resource to be changed. The concerned group leaders can then agree or disagree to the change. If all agree, then the change can be performed system-wide. If some owners disagree or do not respond the change must be performed selectively only in those subsystems whose owners have agreed. Note that inconsistencies will be introduced into those subsystems whose owners have not agreed the change. In the last case, a consistent import will become inconsistent if the corresponding exported resource is to be deleted. The communication pattern to cope with an eventuality is even more dicult. The engineer who wants to delete a resource should propose the deletion to all engineers who have imported the resource. To convince the owners of aected subsystems it is often appropriate to suggest a replacement. If all owners agree to the proposal the engineer responsible can go ahead and delete the resource. Even if a single owner has good reason to reject the proposal, the resource should not be deleted. If some owners ignores the opportunity to respond within a certain period of time, the engineer may delete the resource and then inconsistencies will be introduced in the aected subsystems. 4 Environment Functionality We shall now discuss an integrated environment supporting both design and implementation. We focus on the engineer's point of view and discuss the functionality that is required for developing dierent descriptions. We shall see how access can be controlled and how, in detail, communication and cooperation between engineers can be supported. 12

4.1 Overview A tool has to be provided for each notation that was identied during the design language denition. Each tool should support engineers in editing, browsing and analysing the respective design documents. Groupie, therefore, provides two syntax-directed tools to support architectural and interface designs, the user interfaces of which are displayed in Figure 6: a tool to develop a graphical layout of a software system (based on the notations introduced in Section 2 and a tool which enables module interface denitions to be designed. Figure 6: User Interface of Groupie's Architecture and Interface Tools As usual in syntax-directed editing, any syntactic construct can be selected using a pointing device. The tools deduce commands applicable to the selected construct and oer them in a context-sensitive menu. The engineer can select a command, and Groupie responds after having executed the command by updating the display. The environment should support browsing commands to examine the various relationships. To review the decomposition relationship induced by the subsystem hierarchy, for instance, Groupie oers a zoom-in command which is oered in the menu when a subsystem is selected (see menus in Figure 7). A zoom-out command is oered in order to browse to the enclosing subsystem. Likewise, browsing commands are oered that move the environment's focus from a resource declaration to imports where the resource is used. Support environments should maintain consistency between the dierent design notations as far as possible. If, for instance, an import relationship is created in the architectural design 13

between the modules CMDisplay and CMMessage, not only an arrow will be displayed in the graphical depiction between the two respective modules, but also a new import list will be inserted in the textual interface representation of CMDisplay. Support environments should also guide engineers towards achieving correct static semantics. As an example, consider the expansion of an import list in our design notation. All exports of the respective module, which have not been imported so far, are displayed in a selection box and the engineer can select those that are to be added to the import list. Similarly, all types declared within a module are displayed in a selector box, as soon as a engineer wants to expand a parameter type or a result type of an exported operation. Engineers will nd it convenient if static semantic errors are tolerated. Therefore, imports of resources that have not yet been exported or the use of types that are not yet declared should temporarily permitted. Groupie temporarily tolerates these inconsistencies, but marks them distinctively so as to bring them to the engineer's attention [Erroneous increments are displayed in square brackets]. Consistency is reanalysed incrementally and transparently and analysis commands are available to visit all the erroneous increments. 4.2 Access Rights We have introduced the notion of group-oriented access rights in Section 3. Access rights are useless unless they are are enforced by the support environment. Apart from the enforcement of access rights itself, the environment also must, as a pre-requisite, manage ownership information. Ownership management in Groupie is supported in the following way. If a new design is created by an engineer, the engineer is the leader and the only member of the group which, by default, works on the root subsystem of that design. He or she becomes the owner of the new system. Subsequently, if a new subsystem is created, it will be contained in an already existing subsystem. The owner of the existing subsystem is initially the owner of the new subsystem as well. He or she can change the ownership of the subsystem via a tool command applicable to any subsystem which is accessed by the owner. Using this command, a group leader can include a new member in his or her group and transfer the ownership for a subsystem to the new member. When doing so, a new subgroup of the group leader's group is created and the newly introduced member becomes the group leader of this subgroup. When starting up Groupie, engineers have to identify themselves with their Groupie account. Groupie checks whether a person is a Groupie engineer by requesting a password. Access rights are enforced in the environment by only oering those commands that respect the rights dened. Hence, ownership information is also included in the context that denes how any menu is constructed. If, for instance, a module interface is opened by a engineer who has only read access to the module, the tool works like a browser and any commands that change the interface are not available. As an example consider Figure 7, which illustrates the way access rights are enforced for the architectural design tool. The gure depicts two instances of the architectural design tool, which display the same subsystem. One instance is used by engineer Wilhelm and the other is used by engineer Wolfgang. Wilhelm is the group leader of the subsystem displayed. As the displayed menus suggest, Wilhelm can not change Wolfgang's subsystem (ComMgr). Wolfgang can change ComMgr but only read the other components displayed. 14

Figure 7: Enforcement of Access Rights in the Architecture Tool 4.3 Programming Support We have argued in Section 3 that subsystem owners should not only design the subsystem, but also implement the identied module bodies. Groupie provides programming language tools to support this implementation. They implement the programming language bindings discussed above. Figure 8 shows the user interface of the C programming language tool. It displays the implementation of the function KMCreateMessage whose interface denition is included in Figure 6. The tool displays all operations that have been dened for export in the interface denition of a module. Hidden operations that are not exported can be added. The programming language tool is hybrid in the sense that it supports not only structureoriented editing, but also supports free textual input with a text editor. During structureoriented editing and after parsing freely input text, the tool checks the static semantics of the C programming language as dened in the ANSI specication. Additional functionality of the programming language tool, which goes beyond that of an editor, is concerned with static semantic analysis. The tool has the capability to nd obsolete variable declarations or statically unreachable statements. The interface and programming tools can be used in an intertwined fashion. The eect of a change that an engineer performs to an interface is immediately propagated via the programming tool. If an engineer, for instance, denes a new exported operation, this operation will automatically be included as a function body in the implementation. We have decided not 15

Figure 8: Groupie Programming Tool to support the reverse. This is because we want to force designers to separate the concerns of interface design and implementation. We, therefore, want them to use the interface tool exclusively for interface design and the programming tool only for implementation. The programming tools do not contain any object code generators, as we will rely on standard compilers for that purpose. Programming tools, therefore, have to be capable of dumping source code into a le system. Again this should be done in an incremental way so that only those implementations are written that have been modied since the last dump. The tool can exploit the subsystem hierarchy to arrange for a dump in dierent subdirectories. Derivation of executable les from a set of source les is most often controlled by make [Fel79]. The input for make is a Makele, which denes the dependencies between the dierent source modules and the build rules. The tedious task of manually writing and maintaining Makeles can be fully automated if a design language has been used that includes a concept for dependencies, like the import statements in our notation. In the Groupie example, Makele generation uses the import relationships dened in the design to generate module dependencies. 4.4 Concurrent Development Groupie supports concurrent development in a way that allows multiple engineers to work on the same software design at the same time. Two problems must be resolved to support concurrent development adequately. The rst problem is that change negotiations between engineers may be required. The second problem is that despite the dened access rights, a concurrency control protocol is required. 16

Change Negotiations become necessary whenever an engineer imports types or operations from some other engineer's subsystem or module. Sometimes, he or she may then not be able to stick to the static semantics dened for import relationships. An environment can support the required negotiations based on its knowledge of ownership information and the import relationships between subsystems and the denition of ownership. Groupie incorporates a tool for passing messages between engineers. Groupie oers a command, for instance, to post a request to an owner of a subsystem. When selected, this command provides a text editor to write the request and then sends the request to the engineer who is currently in charge of the respective subsystem. Please note, that Groupie enables the denition of an import although it is not exported and hence the engineer can continue specifying the respective module while the other engineer is handling the change request. As an example consider Figure 9, which shows how this functionality is oered at Groupie's user interface. It depicts a situation in which Wolfgang, who is in charge of designing ComMgr, requests a function from the owner of subsystem ViewMgr. Wolfgang selects the subsystem ViewMgr; the pop-up menu that displays the available command, a Mail command appears, providing a new window in which the request can be written. After the window is closed, the request is automatically sent to the engineer responsible for ViewMgr. Figure 9: Requesting a Change in Groupie To support the negotiations between engineers that are necessary due to a change or a deletion of an already used exported resource, a two-phase message protocol seems appropriate. When an engineer changes or deletes an exported resource, Groupie will warn the engineer that the resource is in use. If the engineer changes it anyway, Groupie will request the provision of a rationale for the change. In the rst phase it sends a change request with the given rationale to all owners of subsystems in which the export is used. Each of these owners have to conrm that they have no objections to the requested change. In the second phase, Groupie awaits conrmation from all these owners of their agreement. Only after having received all 17

conrmations, does Groupie perform the change automatically, either changing all applied occurrences of the declaration consistently or marking them as inconsistent. An engineer who has requested a change can curtail the wait for conrmations; the change is then done selectively only to subsystems whose owners have agreed to the change; other subsystems, the respective imports are marked as inconsistent. If Groupie has performed a change propagation, it will redisplay the eect not only on the workstation of the engineer who actually made the change, but also on the workstations of all engineers who work on subsystems where the change propagation has resulted in changes. Section 5 will suggest an architecture that achieves this. Finally, an automatically composed mail is sent by Groupie to all owners who were involved in the change negotiation saying that change has been completed. Concurrency Control is required to prevent inconsistent analysis or lost update problems [Dat86]. A problem of inconsistent analysis may occur if an engineer imports a resource that some other engineer is concurrently introducing. Subject to timing, it may happen that the import is marked erroneous although the corresponding export exists. A lost update may occur if a new import corresponds to a resource that is about to be changed concurrently. Then it may happen that the import is neither considered erroneous nor is the engineer accepted to participate in the upcoming negotiation and that change propagations are missed. The environment must detect these concurrency control conicts with a concurrency control protocol and handle them appropriately. However, the concurrency control protocol must not hamper cooperative development by locking module interfaces, subsystems or even complete designs during complete editing sessions as it is suggested by various long transaction models or design transaction models [Mos85, KSUW85, BK90]. These models solve the problem by version management and require merger of dierent versions that cannot be automated. Instead, we suggest a concurrency control scheme that uses a ner level of granularity. Instead of locking les we propose locking objects that represent types, operations or even single identiers. We also suggest minimising the period during which transactions hold locks. Transactions should be used to execute single short commands rather than complete editing sessions. The chance of a concurrency control conict is then fairly limited, because the accessed objects are of very ne granularity and the execution of a tool command only needs a few hundred milliseconds. Moreover, only a single command is involved in such a conict and engineers therefore can tolerate a small delay or even an abort of the command execution. Hence, the concurrency control conict between creating an export and changing an import is resolved by Groupie as follows. If the change export command is executed earlier, the engineer will get an error message that the import is wrong. If the import command is executed earlier the engineer will participate in the negotiation procedure. 5 Environment Architecture We now explain the main features of the Groupie implementation. In particular we elaborate the use of ODBMSs [Cat93]. The suitability of ODBMSs as a basis for environment construction is discussed in [EKS93]. Exploiting their conventional transaction mechanism and their client/server architecture, was an excellent basis for implementing the negotiation and concurrency control strategies discussed above. Object databases, however, lack facilities for 18

control integration, which therefore had to be added. 5.1 An object-oriented Schema for Abstract Syntax Graphs Groupie's internal data structure is an abstract syntax graph. 2 Figure 10 displays a fragment of such an abstract syntax graph. It sketches the part of the graph that represents subsystem ComMgr, displayed previously in Figure 6. Archi tecture Name Group Modules Sub systems Groupie...... Wilhelm Leader Sub system Name Group Modules ComMgr... Wolfgang Leader FMod FMod ADOMod TCMod ADTMod CMControl Mod... Name CMDisplay Mod... Name CMComPort Mod... Name BasicTypes Mod... Name CMMessage Mod... Name... DeclaredIn Comment DeclaredIn Sub systems... ADT ExpInt Type Name Op List Function Function...... KMCreateMessage OpName KMAddActivity OpName... Import Interface Import List Imported Module Import Import DeclaredIn DeclaredIn...... Figure 10: Excerpt of Abstract Syntax Graph used by Groupie We want to store these abstract syntax graphs in a database without changing their representation because 1. the graphs are so huge that they do not t into main memory; 2. engineers must not loose the results of signicant eort in case of hardware or software failures; 3. the eciency required at the user interface will not be achieved if complex transformations between external and internal representation are necessary, and, 4. the same graph must be accessible by dierent engineers concurrently. To dene an ODBMS schema for Groupie's abstract syntax graphs, the graph structure and the applicable operations have to be dened in ODL, the standardised ODBMS schema denition language. Therefore, common properties of nodes such as out-going edges or attributes are 2 A rationale why this is the appropriate data structure for environments like Groupie may be found in [ELN + 92] and [ESW93]. 19