Supporting flexible collaborative software development with SPE ...

5 downloads 333 Views 276KB Size Report
SPE provides integrated tools for object- oriented software development. Enacted Serendipity process stages define a work context for SPE, and process model ...
Supporting flexible collaborative software development with SPE–Serendipity John C. Grundy Department of Computer Science University of Waikato Private Bag 3105, Hamilton, New Zealand email: [email protected]

Abstract Collaborative software development environments are large cooperative work systems. To effectively support collaborative development, such environments should support software process modelling and enactment, work coordination, and fully integrated software development tools. We describe the facilitation of collaborative software development using the Serendipity process modelling environment and SPE integrated software development environment. Serendipity provides flexible, graphical process modelling tools which are used to describe, enact and improve work processes. A graphical event processing language is used to specify event handling and rules for process models. SPE provides integrated tools for objectoriented software development. Enacted Serendipity process stages define a work context for SPE, and process model views are animated to keep multiple developers aware of others’ work. Enacted process stages record each software artefact modification in SPE, forming a history of work. Shared notes added to process stages and software artefacts facilitate asynchronous communication, and messages and talk-style dialogues facilitate synchronous communication. Process models can be modified and improved during or after use, and be abstracted to form reusable templates. We describe how our approach to integrating Serendipity and SPE addresses many of the foundational issues of process-centred software engineering environments. Key words: collaborative software development, integrated software development environments, processcentred software engineering environments, environment integration

1. Introduction Integrated Software Development Environments (ISDEs) support software development using a collection of integrated development tools. ISDEs require data (i.e. integrated repository), control (i.e. event passing between tools), presentation (i.e. consistent tool user interfaces), and process (i.e. coordination of tool use) integration to effectively support complex software development [38]. Most ISDEs do not adequately support process integration nor facilitate cooperative work among multiple developers. Some ISDEs attempt to support collaborative software development, usually by providing low-level collaborative editing [18, 27, 21], but this is not sufficient for large-scale development. Process-centred Software Engineering Environments (PCSEEs) attempt to formally describe the processes used when developing software [30], with process models used to guide or enforce development. Models may be reused for multiple projects, with improvements made as developers become more familiar with their work processes. Unfortunately most existing PCSEEs use complex, low-level descriptions of process models, which are often difficult for developers to understand and modify, and process models can not be easily incrementally evolved while in use. Work coordination facilities of PCSEEs, and the level of development tool support they provide are usually very rudimentary [26]. Integration of ISDEs and PCSEEs would seem to be a logical step in enhancing software development with these tools [28], and some attempts have been at achieving a synergy between ISDE, PCSEE and Computer-Supported Cooperative Work (CSCW) systems [26, 28, 22]. To date, the level of integration of the tools developed in these related research fields has not been sufficient to produce environments which adequately support large-scale, collaborative software development [26]. This is due to several reasons, including continuing difficulties with the integration of disparate tools, providing solutions to only some of the above issues, and supporting only limited parts of the software development process. We describe our approach to the integration of ISDEs, PCSEEs and CSCW systems. The following section discusses some of the foundational issues of ISDEs and PCSEEs, and highlights where developments in the two research fields may complement each other. Section 3 describes SPE, an ISDE for object-oriented Page 1

software development, which provides sophisticated, integrated tools for software development. SPE supports basic CSCW editing capabilities but not process modelling and enactment. Section 4 describes the Serendipity process modelling, work planning and work coordination environment, which provides highlevel, graphical process modelling, work planning, and event handling views. Serendipity views are animated to support high-level work context awareness, and process stage enactment and modification histories support process model history and evolution tracking. Serendipity provides synchronous dialogue and messaging, and asynchronous notes facilities, but no tools for software development. We have integrated SPE and Serendipity, with no modifications made to either independently developed environment, to produce a true collaborative software development environment. SPE–Serendipity supports the integrated SPE development tools whose use is coordinated by enacted Serendipity process models.

2. Some Foundational Issues of ISDEs and PCSEEs ISDEs are intended to be powerful software development tools, usually comprised of smaller tools which support aspects of the software development lifecycle [10]. Various ISDE models exist, ranging from tightly-integrated, custom-built and integrated tools [31], to rather more loosely integrated, but generally more extensible, tool sets [6, 33]. A key issue in ISDEs is in managing the trade-off between tool integration and environment extensibility. Four kinds of environment integration are usually addressed [25, 38]: data integration, where tools share an integrated repository or their repositories are linked; control integration, where tools can communicate, usually via event passing or direct/indirect invocation; presentation integration, where the tool user interfaces are consistent; and process integration, where the use of tools is coordinated. The degree of environment integration usually characterises how effectively these tools support software development. High integration usually means more effective use, but highly integrated environments are usually less extensible, and more difficult to add new or modify existing tools [25]. Tools can be generated, built by reusing ISDE tool frameworks, or custom coded in a general-purpose language. Integrating disparate development tools is a continuing problem for ISDE developers, with custom-built tools being generally difficult to integrate, while generated tools and those designed for easier integration are usually less functionally developed [25, 33, 38]. A key problem with most ISDEs is lack adequate process integration, so multiple tools, even if integrated in other ways, can not always be effectively used together on large projects. PCSEEs aim to support modelling and enactment of complex software processes, and aim to either guide or enforce software development. Models must adequately describe the software processes being used, should be flexible and easy to modify/evolve, and need to be readily abstracted and reused on new problems. Most existing PCSEEs adopt low-level, textual descriptions of process models, which are often difficult for developers to understand and evolve [20, 30]. While some PCSEEs are intended to assist collaborative development, most do not provide high-level coordination mechanisms to assist developers in coordinating work. The tools provided by many PCSEEs are seldom as powerful as ISDE, CASE and CSCW tools. To alleviate this, work has been done on integrating PCSEEs and existing development tools, but this has seldom succeeded well, as the tool, the PCSEE or both are often not amenable to tool integration [28]. Our approach to addressing these foundational requirements and existing problems with ISDEs and PCSEEs has been to tightly integrate a purpose-built, extensible ISDE, SPE, and a purpose-built process modelling environment, Serendipity. SPE provides powerful, multiple view development tools, which have fully integrated data, control and presentation aspects. SPE is, however, built using a flexible, reusable architecture which allows tools to be evolved, new tools to be developed, and existing, third-party tools to be integrated. Serendipity provides high-level, graphical process modelling and event handling notations, used to define software process models for SPE. An enacted Serendipity model is used to guide or enforce development with SPE and acts as a high-level work context and context awareness tool. This approach of integrating an extensible ISDE with a general-purpose work process modelling environment has proved successful in addressing most of the issues raised above.

3. SPE: An Integrated Software Development Environment SPE (the Snart Programming Environment) is an ISDE for Snart, an object-oriented extension to Prolog. SPE provides object-oriented analysis and design, implementation, debugging and documentation views of software development [10]. Figure 1 shows a screen dump from SPE during the development of a simple invoicing system. The ‘root class’ graphical view shows an analysis-level diagram; the ‘customer & invoice’ view shows a design-level diagram; and the ‘Customer-Class Definition View’ textual view shows Page 2

a class interface. Textual method implementation, graphical and textual debugging views, and textual documentation views, are also provided. Graphical views use an icon and connector representation, and include a tool palette for interactive editing. Textual views are free-edited and parsed. Inter-view navigation is via menus or hyper-links. There is no restriction on the number of views able to be constructed and displayed, with view contents and layout under user control.

Fig. 1

A screen dump from the Snart Programming Environment (SPE).

Change descriptions expanded into view header region

Figure 2. Consistency management between SPE views.

Page 3

SPE requires all view data to be kept consistent under change. A flexible view consistency mechanism is used to achieve this, which displays intractable descriptions (“change descriptions”) of inconsistencies [12]. Some change descriptions can be automatically applied by SPE, such as renaming and adding features. Others, such as adding or modifying client/supplier relationships and compilation errors, need manual resolution by users. Figure 2 shows an example of this. Low-level collaborative software development is supported by synchronous, semi-synchronous and asynchronous view editing, together with version management and merging [13]. These facilities are not, however, sufficient to support effective multi-user collaborative software development.

4. Serendipity: A Process Modelling and Enactment Environment

Figure 3. Software process model views and dialogs in Serendipity.

Serendipity is a process modelling, enactment and work planning environment, which also supports flexible event handling mechanisms, group communication, and group awareness facilities [16]. Fig. 3 Page 4

shows a Serendipity process model for updating a software system (“m1:modify system-process”). The notation is an adaptation and extension of Swenson’s Visual Planning Language [36], which does not support artefact, tool or role modelling, nor arbitrary event handling mechanisms. Stages describe steps in the process of modifying a software system, with each stage containing a unique id, the role which will carry out the stage, and the name of the stage. Enactment event flows link stages. If labelled, the label is the finishing state of the stage the flow is from (e.g. “finished design”). The shadowing of the “m1.2:implement changes” stage indicates that multiple implementers can work on this stage (i.e. the stage has multiple subprocess enactments). Other items include start stages, finish stages, AND stages, and OR stages (empty round circle). Underlined stage IDs/roles mark presence of a subprocess model, for example “m1.1:plan changes-subprocess” is a subprocess for “m1.1:design changes”. The italicised “check out design” stages in this subprocess model indicate stages reused from a template process model. Serendipity supports artefact, tool and role modelling for processes, as in “m1:model1-roles”, which shows a different perspective of “m1:model1-process”. Usage connections indicate how stages, artefacts, tools and roles are used. Optional annotations indicate: whether data is created (C), accessed (A), updated (U), or deleted (D); whether a stage must use only the tools, artefacts or roles defined (√); and whether a stage cannot use a particular tool, artefact or role (¬). If a stage is linked to another stage by a usage flow, “√” specifies the stage may be enacted when the other stage is enacted, while “¬” specifies the stages can not be enacted at the same time. In addition to specifying the static usages and enactment event flows between process model stages, Serendipity supports filters and actions, which process arbitrary enactment and work artefact modification events. View “m1.3:done testing” shows an example of enactment event filtering. The filters “Made Current” and “finished testing” determine if “m1.3:check changes” has been made the current enacted stage or has been finished. If so, then if the “m1.2:implement changes” process has not completed (determined by filter “Not Complete”), the role associated with this stage is notified of testing being started or completed. Stages are enacted for a project, highlighted by colour and shading, as shown in Figure 3. The shaded stage with a bold border (“m1.1.8:fix design”) is the current enacted stage for the user i.e. their current work context. As a stage completes in a given finishing state, event flows with this state name (or no name) activate to enact linked stages. Enactments of stages are recorded, as are process model changes, and all enacted stages for a user can be shown in a “to-do” list dialog.

5. SPE and Serendipity Integration Serendipity has no built-in tools for software development. and so must be combined with development tools, such as SPE. With SPE and Serendipity providing complementary facilities, we attempted to integrate these environments, as described in this section. 5.1. MViews SPE and Serendipity were developed by reusing the MViews framework for constructing ISDEs [9, 11]. MViews provides a general model for defining software system data structures and tool views, with a flexible mechanism for propagating changes between software components, views and tools. ISDE data is described by components with attributes, linked by a variety of relationships. Multiple views are supported by representing each view as a graph linked to the base software system graph. Each view is rendered and edited in either a graphical or textual form. Tools can be interfaced at the view level (as editors), via external view translators, or multiple base layers may be connected via inter-repository relationships [14]. Figure 4 shows an example of the SPE architecture built using MViews. When a software or view component is updated, a change description is generated. This is of the form an attribute update on Comp1 of All basic graph editing operations generate change descriptions and pass them to the propagation system. Change descriptions are propagated to all related components that are dependent upon the updated component’s state. Dependents interpret these change descriptions and possibly modify their own state, producing further change descriptions. Figure 4 shows an example of this change propagation process when renaming a feature in SPE. This change description propagation mechanism supports a diverse range of software development environment

UpdateKind(UpdatedComponent, ...UpdateKind-specific Values...). For example, attribute Name is represented as: update(Comp1,Name,OldValue,NewValue).

Page 5

facilities, including attribute recalculation, multiple views with flexible, bi-directional textual and graphical view consistency, a generic undo/redo mechanism, component versioning, and collaborative view editing [12].

6.

1.

Renderings/ Editors for Views

6. update affected views (rerender, expand text headers, etc.)

1. Edit view component

1.

6.

class_icon class1

2. propagate change description e.g. "update(Comp,name,Old,new)"

gen_glue

5. propagate to affected views

2.

Multiple Views of Repository

class_text

5.

class2

class_icon

5. view rel.

view rel.

view rel. 4. class1

3. update base component

4. gen

other base view(s) (Collaborative Edits)

3. class

4.

4. update affected components

Key:

features 5. propagate to affected views

relationship

...

class class2

attribute component

5.

...

...

...

Repository (Base View)

Figure 4. The SPE architecture as represented in MViews.

New software components and editing tools are constructed by reusing abstractions provided by an objectoriented framework. ISDE developers specialise MViews classes to define software components, views and editing tools to produce the new environment. A persistent object store is used to store component and view data. We have built many environments with MViews, including SPE [10], MViewsER [14], MViewsDP [12], MViewsNIAM [39], CernoII [8], EPE [2], and ViTABaL [15]. We have integrated SPE and MViewsER to produce OOEER [14], with OOA/D and EER modelling views kept fully consistent, and MViewsER and MViewsNIAM to produce NIAMER [39], with ER and NIAM modelling views kept fully consistent. 5.2. SPE and Serendipity Environments SPE defines base and view components to represent classes, attributes, methods, and inter-class relationships (association, aggregation, generalisation and client-supplier). Textual and graphical views provide editors for view component renderings. SPE uses the existing Snart compiler to compile textual class interface and method views, and uses the CernoII debugger [8] to provide graphical and textual views of running programs. Serendipity defines base and view components to represent process stages, artefacts, roles, tools, filters and actions, and usage and event connections. MViews change descriptions represent enactment events, and propagation and response to these enacts process models. Filters and actions provide Prolog-based pattern-matching and simple action implementation, with an API interface to Snart, allowing access to MViews data and complex action implementation. 5.3. Integration There are three main approaches we could have used to integrate SPE and Serendipity: 1. Modify the SPE and Serendipity environment implementations to have direct knowledge of each other’s structure and directly invoke component operations.

Page 6

2. Modify MViews so that it sends change descriptions generated by tools to Serendipity, and modify Serendipity to handle these general “artefact update” events. 3. Add relationships between the Serendipity base view and SPE base view to translate events from one environment into appropriate events in the other, similar to OOEER and NIAMER interrepository relationships. The first approach, similar to that of MultiView-Merlin [28], has the obvious flaw that it is very specific to these two ISDEs. If we wanted to integrate a different ISDE with Serendipity, we would need to further modify it and Serendipity. The third approach is the most general, as no existing code need be modified. Unfortunately, a major problem we encountered with the OOEER and NIAMER integrations using this approach is that insufficient presentation integration results i.e. we can not extend the user interfaces of the integrated tools. We adopted a combination of the second and third approaches. The base views of Serendipity and SPE were linked via an inter-repository relationship which forwards all SPE change descriptions to Serendipity, with SPE not modified in any way. The MViews base view component class was then specialised to have some knowledge about Serendipity, so some MViews dialog and menu definitions could be specialised to add extra commands to be sent to Serendipity. The Serendipity base view was specialised so that it receives change descriptions from other ISDEs via the inter-repository link relationship, stores them in the current enacted stage artefact history, and augments them for the ISDE with work context information. It also fires any filter/actions which are connected to the current enacted stage by artefact update event flows. Other Serendipity artefact change handling facilities described in the following section were defined as Serendipity filter/actions, not necessitating further change of Serendipity classes. Figure 5 shows how the SPE and Serendipity integration was achieved. Serendipity View

SPE View 1. SPE view updated

stage icon

class icon 1. 10. Other SPE views affected by base comp. update sent augmented change descriptions view rel

6. Stage augments change descriptions & stores them

2. SPE base comp. updated 2. 10.

tool mod. history

base class 8.

view rel

6. artefact mod. history

9. base component stores augmented change descriptions

base stage

9. 3. Base comp forwards change descriptions to base view

3. SPE Base View

8. SPE base view returns augmented change descriptions to base component

4.

4. SPE base view forwards change descriiptions to Serendipity

7.

5.

Serendipity Base View

4.

7.

5. Serendipity base view forwards SPE change descriptions to current enacted stage

7. inter-repository rel

7. Augmented change descriptions sent back to SPE base view

Figure 5. Integrating SPE and Serendipity environments.

This solution to SPE–Serendipity integration works for any other MViews ISDE. We have integrated OOEER and NIAMER with Serendipity, and have also integrated office automation programs, such as Microsoft Word, MS Excel, Global/Fax and Eudora [16]. The office automation programs are launched and sent instructions via Apple Events, generated by Serendipity actions.

6. Collaborative Software Development with SPE–Serendipity 6.1. ISPW6 Example Software Process Model We illustrate SPE–Serendipity supporting collaborative software development with the ISPW6 software process model. Part of the ISPW6 software process example is shown in Figure 6. This focuses on the designing, coding, unit testing and management of a localised change to a software system [24]. The exploded subprocess for “ispw6.2:Design, Code & Test” describes the subprocess for modification of the design and code, and the unit testing of these modifications. The coordination of the process model via the “ispw6.3:Monitor Progress” stage is defined by the “ispw6.3:Monitor Progress-coord” view, which Page 7

utilises filters and actions to carry out this coordination. The ISPW6 example describes the artefacts (documents) which are used by the process stages, and basic inter-stage coordination (via email), which we have modelled in Serendipity. It does not specify the tools used to modify the design, code or test plans. We use SPE for designing and coding, the Serendipity messaging facility instead of e-mail, and the MS Word word processor program for editing and viewing system documentation and test plans.

Figure 6. Part of the ISPW6 software process example modelled in Serendipity.

This process model was created as a Serendipity template i.e. a reusable but non-enactable model. To use this model for a particular project, a new process model must be copied, done by simply adding a process stage icon derived from the root “ispw6” stage to a view. Serendipity copies all template substages, filter/actions and views, giving them new unique IDs. An example of this is shown in Figure 7. In this example, the copied process model is for extending a video library software system developed in SPE to incorporate automatic fining for late returns. The root copied process is named “Add Fines Facility” and stages prefixed with “aff” . To use this copied model, role assignments and work plans need to be defined. This can be done by creating a project plan document as part of “ispw6.1:Schedule & Assign Tasks”, as described by the ISPW6 example. An alternative is to use Serendipity itself to make work assignments and plans. This is done as part of the “ispw6.1:Schedule & Assign Tasks” stage, but instead of creating a document to describe assignments and plans, the project manager extends the copied process model views, as shown in Figure 7, to assign roles (for example, “judy” is the designer, “rick” the QA Engineer, “john” the coder, Page 8

etc.). Extra information can be supplied in the detailed textual views associated with each process stage [16]. The project manager can also explode leaf process stages “ispw6.2.1.1:modify design”, “ispw6.2.2:modify code”, etc. to define “work plans” for the work which needs doing for this particular system modification for the project. This illustrates the versatility of Serendipity’s process modelling/work planning notation.

Figure 7. A reused template and expanded work plan for a particular project.

The model is ready for enactment, and then work can begin for enacted stages using SPE. Before work begins, however, some developers may further refine their work plans, define extra filters/actions to coordinate their work with other people, and so on. This may be done while the model is enacted, as Serendipity allows process models and plans to be modified at any time. For example, in Figure 8 coder “john” has defined a new view and added filter/actions to keep him aware of modifications done by “judy” on the artefact “video class” (via storing the artefact changes in a “change list” artefact), and to inform him when “rick” starts work on “test_unit”.

Page 9

The ISPW6 template currently allows designing, coding and testing to be concurrently enacted. We could stop this for the copied model, if desired, by specifying an inherited action on “aff.2:Design, Code & Test” which does not allow users to start stages while others are enacted (shown in window “aff.2:Design, Code & Test-waterfall”).

Figure 8. Extra actions specified to keep people aware of other’s work and enforce non-concurrent enaction.

6.2. Enacting Models and Work Context Awareness

Figure 9. Enacted Serendipity process models, viewed from within SPE.

Page 10

When “aff:Add Fines Facility” is enacted, the “aff.1:Schedule & Assign Tasks” subprocess is enacted. When this is finished, the “aff.2:Design, Code & Test” subprocess is enacted, enacting “aff.2.1:Design Changes”, and so on. Figure 9 shows the enacted “aff:Add Fines Facility” model and its enacted “aff.2:Design, Code & Test” subprocess model. Also shown is a stage enactment history. All of these Serendipity views may be open while a developer uses SPE views (as shown), although usually the developer will have only 1 process model view open, or even only their “to-do” list dialog (showing their enacted stages) open. When making modifications in SPE, change descriptions generated, presented and stored by SPE are augmented with the current enacted context by Serendipity. These change descriptions are also stored by Serendipity in artefact change histories for each process stage. An example is shown in Figure 10 for designer “judy”’s work modifying the video and customer tables. Dialog and textual view header contents are refreshed each time a new change description is received.

Figure 10. An example of work context capture and presentation in SPE–Serendipity.

Collaborating users need to remain aware of other’s work and be informed of tool events and changes to artefacts they are interested in. Figure 11 shows how SPE–Serendipity keeps users aware of collaborators’ work. Enacted stages for all users are highlighted, and the users who have enacted the stage can be viewed in a dialog. The current enacted stages for collaborators are shown with coloured borders, with different colours assigned to each collaborator. Template actions can be used which highlight the tool(s) and artefact(s) being used by collaborators (for example, designer “judy” is being informed that the SPE OOA/D view editor is being used by coder “john” to edit the “video system OOA/D” artefact). Collaborative notes, messages and talk-style dialogues, based on the MVNotes system [3], are provided by Serendipity to facilitate collaborative dialogue. These are context-sensitive, recording the artefact(s) and stage(s) they are associated with, unlike traditional context-independent email and talk systems. Messages and dialogue contents are recorded as notes associated with the appropriate stage/artefact to retain a permanent, shared history of communication for a project.

Page 11

Figure 11. Examples of work context awareness and communication support.

Serendipity stages record the “state” i.e. the open windows and artefacts in use by SPE. When making a stage the current enacted stage, SPE and Serendipity views can be reopened. Hyperlinks between SPE and Serendipity change descriptions and artefacts can be traversed on user-request. These facilities add to the user’s perception that SPE and Serendipity form a tightly-integrated PCSEE. 6.3. Process Metrics and Improvement Process model analysis and metrics facilities enable users to analyse process models and work histories, thereby assisting in the improvement of these processes. The complexity of subprocess models, number of work artefacts stored by a stage, time spent by a stage as the current enacted stage, and so on may be analysed and graphed. Serendipity calculates these values for selected stages on user request, exports this raw information to a file, and launches the Microsoft Excel™ spread sheet package to graph the data. The user may, within Excel, perform other analyses on the data, if desired. An example of this process model analysis is shown in Figure 12. Serendipity stages support “user-defined attributes”, allowing users to specify attribute/value pairs via a forms interface. This is often used to specify project management information, such as estimated number of changes still to make for stage, estimated time to completion of stage, and stage and artefact ownership. Actions can traverse these values, exporting the results to MS Excel™ for graphing and enforcing access and update rights. Process models need to be modified to take account of exceptions which occur while the model is in use (i.e. cases not handled by the model), to improve the software process used, and to extend the model. Serendipity allows these changes to be made before, during or after process model use. An example model Page 12

improvement is shown in Figure 13. It was determined that: i) an exception to coder “john”’s work plan occurred, with an addition stage “aff.2.3.5:Modify rentals class” needing to be added, necessitated by design changes “judy” made; ii) an improvement to the process model was made, splitting “aff.2.1:Design Changes” into a subprocess with separate analysis, design and documentation modification stages. This was found to be better when the ISPW6 model is used with SPE, as SPE provides separate OOA, OOD and documentation facilities.

Figure 12. Analysis of Serendipity process models using MS Excel™ graphing.

As a further example of Serendipity’s usefulness in conjunction with SPE, the view “app2.3:Modify Coderestriction” is restricting the video class to not allow multiple inheritance, determined by the designer to be necessary. This can be viewed as extending the semantics of SPE itself by using Serendipity filters and actions on artefact events. SPE–Serendipity supports this kind of Method Engineering [17], where SPE tools are restricted by actions for a particular software process model defined in Serendipity. Developers can collaboratively make these modifications to Serendipity views using synchronous, semisynchronous and asynchronous editing [16]. Synchronous, where all developers share the same model version, is most useful for high-level changes. Semi-synchronous, where each developer has an alternative model version, propagates changes to other developers, but the change is not immediately actioned. We have found this most appropriate for lower-level process models which are shared but may need to evolve separately for a time. Asynchronous editing, where developers have alternative model versions, edit these separately and then merge changes, is most appropriate for personal process models or for controlling large-scale model evolution. Template models may be changed, and developers want these changes reflected in template copies, or viceversa. For example, we might want to merge the improvements to “app.2.1:design changes” back into the ISPW6 template. Figure 14 shows an example of the merging process, which uses the modification history for Serendipity views (automatically constructed by MViews) to achieve this. Note that merge conflicts might occur, as the template could have been independently modified since the copy took place. Merge errors are presented to the merging developer in a “Merge Conflicts” dialog. To merge, the merger translates stage IDs (if the subprocess model has been copied from the template), or, as in this example, substitutes unique ID prefixes (“ispw6.1.4” for “aff.2.1”) for the “aff2.1:Design Chasnges-subprocess” view change descriptions. The merger then tries to apply the translated change descriptions to the “ispw6.1.4:Design Changes-subprocess” view. It detects that the user name of “ispw6.1.4.3:Find Errors” would be changed, however, and because of this doesn’t merge changes relating to “aff.2.1.3:Modify Documentation”, instead flagging them as possible merge conflicts for the user to manually resolve.

Page 13

Figure 13. Handling exceptions and improving the process model.

7. Discussion SPE-Serendipity addresses many of the foundational issues of PCSEEs and ISDEs discussed in Section 2. SPE provides similar facilities to most other ISDEs, such as Dora [31], FIELD [33], MultiView [1], and PECAN [32], although has more flexible view consistency mechanisms. These existing environments have poor or non-existent process modelling and integration, however, and are generally very difficult to integrate with existing PCSEEs [28]. SPE-Serendipity provides sophisticated, multiview software development tools and, via Serendipity, fully integrated, high-level process modelling and enactment capabilities. Most CSCW systems, such as GroupKit [34], most groupware [7], Mjølner [27], and Rendezvous [18], do not provide high-level work coordination support. Some provide synchronous dialogue, telepointers and basic group awareness capabilities, but this is insufficient for large, complex collaborative software development environments. SPE–Serendipity provides low-level collaborative editing, a range of collaborative communication facilities, and high-level work context awareness. Serendipity process stages define the work context for SPE, and SPE supplies artefact change descriptions for Serendipity to build work histories. ConversationBuilder [23] and Worlds [5] are recent attempts at providing integrated CSCW and process-modelling tools, but they do not provide the level of integration of SPE-Serendipity for collaborative software development. Page 14

Figure 14. Merging changes from a copy back into a (changed) template.

The majority of PCSEEs, such as Merlin [30], Marvel [4], and EPOS [19], provide low-level, complex approaches to defining software process models, as do most Computer-Aided Method Engineering (CAME) tools, such as Decamerone [17] and MethodBase [35]. SPE-Serendipity provides much higherlevel process and event handling models, which when animated support high-level work coordination and context awareness. It also allows developers to easily define work plans using the same process modelling notation, add extra information against stages (such as progress towards completion), and quickly and easily define custom enactment and artefact event processing. Most PCSEEs provide poor development tools, or are incompletely integrated with ISDE tools [28]. SPE–Serendipity provides fully integrated process modelling and software development tools, and allows process models to be abstracted and restructured and improved while in use. The close integration of SPE and Serendipity means work artefact changes from SPE are easily stored and handled by Serendipity filter/actions, and Serendipity process stage information augments the change descriptions stored and presented by SPE. Many workflow systems, such as Regatta [37] and Action Workflow [29], provide graphical workflow or planning languages. These are insufficient for general software process modelling as they either do not adequately model roles, artefacts and tools, or they use a document flow approach which has proved inadequate for real-world work processes [36]. In addition, these workflow-based tools often are poorly integrated with development or work tools, and do not handle exceptions or restructuring of the models while in use as well as SPE-Serendipity. While our approach would seem to be restricted to only supporting the integration of MViews-based environments with Serendipity, this is not the case. We have also used Serendipity to facilitate the “integrated” use of several office automation applications, including MS Word™, MS Excel™, Global Fax/OCR™, and the Eudora™ email tool [16]. This was achieved by sending Apple Events to these applications, via actions, to coordinate their use. Serendipity, and other MViews environments, can be integrated with other software engineering tools, provided those tools provide some message-based external interfaces for MViews to interact with (via translating MViews change descriptions to/from external tool events [11]). As suggested by Verrart and Wright [40], this message-based integration allows existing tools Page 15

to be integrated, to varying degrees, without modifying them. SPE–Serendipity illustrates how effectively an ISDE and PCE can be tightly integrated in this way. We have used SPE–Serendipity to facilitate collaborative software development on several small-to-medium problems. The performance of the environment is generally good, although if many filter/actions are specified on a stage, response time becomes slow (as these are currently interpreted). Preliminary results of using this integrated environment on these example process modelling, improvement and software development problems indicates it addresses many of the foundational issues of integrating PCSEEs and ISDEs more readily than existing approaches.

8. Summary We have integrated the SPE Integrated Software Development Environment (ISDE), which supports multiple, integrated views of object-oriented software development, and the Serendipity Process-Centred Environment (PCE). SPE provides more flexible view consistency and environment integration mechanisms than most existing ISDE approaches, while Serendipity provides higher-level, more flexible process modelling, enactment and improvement facilities than most existing PCEs. SPE–Serendipity forms a versatile Process-Centred Software Engineering Environment (PCSEE), which provides higher-level work coordination and context awareness facilities than most existing PCSEEs and Computer-Supported Cooperative Work (CSCW) systems. Experience to date with SPE–Serendipity indicates that the approach used to integrate the environments and their performance in supporting large-scale collaborative software development provide new solutions to some of the foundational issues of PCSEEs. We are currently extending Serendipity to support a Visual Query Language (VQL), both for querying ISDE repositories (such as SPE), and for use with filter/actions. More comprehensive rules and filtering mechanisms will be supported by this VQL, and by using the language over MViews components, a generic repository querying and visualisation tool will result. Optimisations to SPE–Serendipity include the ability to compile filter/actions, support for extending the SPE user interface without modifying existing code to access Serendipity commands, and porting MViews and SPE–Serendipity to C++ to improve performance, accessibility and the ability to integrate third-party ISDE tools into the environment.

References 1.

Altmann, R.A., A.N., H., and Marlin, C.D. An Integrated Programming Environment Based on Multiple Concurrent Views. Australian Computer Journal 20, 2 (May 1988), 65-72.

2.

Amor, R., Augenbroe, G., Hosking, J.G., Rombouts, W., and Grundy, J.C. Directions in modelling environments. Automation in Construction , 4 (1995), 173-187.

3.

Apperley, M.D., Gianoutsos, S., Grundy, J.C., Paynter, G., Reeves, S., and Venable, J.R.“A generic, light-weight collaborative notes and messaging facility for groupware applications,” , no. Working Paper, 1996.

4.

Barghouti, N.S. Supporting Cooperation in the Marvel Process-Centred SDE. In Proceedings of the 1992 ACM Symposium on Software Development Environments, ACM Press, 1992, pp. 21-31.

5.

Bogia, D.P. and Kaplan, S.M. Flexibility and Control for Dynamic Workflows in the wOrlds Environment. In Proceedings of the Conference on Organisational Computing Systems, ACM Press, Milpitas, CA, November 1995.

6.

Bounab, M. and Godart, C. A Federated Approach to Tool Integration. In Proceedings of CAiSE'95, Finland, June 13-16 1995, LNCS 932, Springer-Verlag, pp. 269-282.

7.

Ellis, C.A., Gibbs, S.J., and Rein, G.L. Groupware: Some Issues and Experiences. Communications of the ACM 34, 1 (January 1991), 38-58.

8.

Fenwick, S., Hosking, J.G., and Mugridge, W.B. Visual debugging of object-oriented systems. In Proceedings of TOOLS Pacific 94, Melbourne, Australia, November 1994, Prentice-Hall.

9.

Grundy, J.C. and Hosking, J.G. A framework for building visusal programming environments. In Proceedings of the 1993 IEEE Symposium on Visual Languages, IEEE CS Press, 1993, pp. 220-224.

10.

Grundy, J.C., Hosking, J.G., Fenwick, S., and Mugridge, W.B. Connecting the pieces, Chapter 11 in Visual ObjectOriented Programming, Manning/Prentice-Hall (1995).

Page 16

11.

Grundy, J.C. and Hosking, J.G., “Constructing Integrated Software Development Environments with MViews” Working Paper, Department of Computer Science, University of Waikato, 1994.

12.

Grundy, J.C., Hosking, J.G., and Mugridge, W.B. Supporting flexible consistency management via discrete change description propagation. to appear in Software - Practice and Experience.

13.

Grundy, J.C., Mugridge, W.B., Hosking, J.G., and Amor, R. Support for Collaborative, Integrated Software Development. In Proceeding of the 7th Conference on Software Engineering Environments, IEEE CS Press, Netherlands, April 5-7 1995, pp. 84-94.

14.

Grundy, J.C. and Venable, J.R. Providing Integrated Support for Multiple Development Notations. In Proceedings of CAiSE'95, Finland, June 1995, LNCS 932, Springer-Verlag, pp. 255-268.

15.

Grundy, J.C. and Hosking, J.G. ViTABaL: A Visual Language Supporting Design By Tool Abstraction. In Proceedings of the 1995 IEEE Symposium on Visual Languages, IEEE CS Press, Darmsdart, Germany, September 1995, pp. 53-60.

16.

Grundy, J.C., “Serendipity: integrated environment support for process modelling, enactment and improvement,” Working Paper, Department of Computer Science, University of Waikato, 1996.

17.

Harmsen, F., and Brinkkemper, S. Design and Implementation of a Method Base Management System for a Situational CASE Environment. In Proceedings of the 2nd Asia-Pacific Software Engineering Conference (APSEC'95), IEEE CS Press, Brisbane, December 1995, pp. 430-438.

18.

Hill, R.D., Brinck, T., Rohall, S.L., Patterson, J.F., and Wilner, W. The Rendezvous Architecture and Language for Constructing Multi-User Applications. ACM Transactions on Computer-Human Interaction (June 1994).

19.

Jaccheri, L., Larsen, J.O., and Conradi, R. Software Process Modeling and Evolution in EPOS. In Proc. Fourth International Conference on Software Engineering and Knowledge Engineering (SEKE), Capri, Italy, 17--19 June 1992., pp. 17-29.

20.

Jacobs, D.A. and Marlin, C.D. Software process representation to support multiple views. International Journal of Software Engineering and Knowledge Engineering 5, 4 (December 1995).

21.

Kaiser, G.E., Kaplan, S.M., and Micallef, J., Multiuser, Distributed Language-Based Environments. IEEE Software 4, 11 (November 1987), 58-67.

22.

Kaplan, S.M., Tolone, W.J., Bogia, D.P., and Bignoli, C. Flexible, Active Support for Collaborative Work with ConversationBuilder. In 1992 ACM Conference on Computer-Supported Cooperative Work, ACM Press, 1992, pp. 378-385.

23.

Kaplan, S.M., Tolone, W.J., Carroll, A.M., Bogia, D.P., and Bignoli, C. Supporting Collaborative Software Development with ConversationBuilder. In Proceedings of the 1992 ACM Symposium on Software Development Environments, ACM Press, 1992, pp. 11-20.

24.

Kellner, M.I., Feiler, P.H., Finkelstein, A., Katayama, T., Osterweil, L.J., Penedo, M.H., and Rombach, H.D. Software Process Modelling Example Problem. In Proceedings of the 6th International Software Process Workshop, IEEE CS Press, Hokkaido, Japan, 28-31 October 1990.

25.

Kiper, J.D. A framework for characterisation of the degree of integration of software tools. Journal of Systems Integration 4(1994), 5-32.

26.

Krishnamurthy, B. and Hill, M. CSCW'94 Workshop to Explore Relationships between Research in Computer Supported Cooperative Work & Software Process. In Proceedings of CSCW'94, ACM Press, April 1995, pp. 34-35.

27.

Magnusson, B., Asklund, U., and Minör, S. Fine-grained Revision Control for Collaborative Software Development. In Proceedings of the 1993 ACM SIGSOFT Conference on Foundations of Software Engineering, Los Angeles CA, December 1993, pp. 7-10.

28.

Marlin, C., Peuschel, B., McCarthy, M., and Harvey, J. MultiView-Merlin: An Experiment in Tool Integration. In Proceedings of the 6th Conference on Software Engineering Environments, IEEE CS Press, 1993.

29.

Medina-Mora, R., Winograd, T., Flores, R., and F., F. The Action Workflow Approach to Workflow Management Technology. In Proceedings of CSCW'92, ACM Press, 1992, pp. 281-288.

30.

Peuschel, B., Schäfer, W., and Wolf, S. A knowledge-based software development environment supporting cooperative work. International Journal of Software Engineering and Knowledge Engineering 2, 1 (1992), 76-106.

Page 17

31.

Ratcliffe, M., Wang, C., Gautier, R.J., and Whittle, B.R. Dora - a structure oriented environment generator. IEE Software Engineering Journal 7, 3 (1992), 184-190.

32.

Reiss, S.P. PECAN: Program Development Systems that Support Multiple Views. IEEE Transactions on Software Engineering 11, 3 (1985), 276-285.

33.

Reiss, S.P. Connecting Tools Using Message Passing in the Field Environment. IEEE Software 7, 7 (July 1990), 57-66.

34.

Roseman, M. and Greenberg, S. Building Real Time Groupware with GroupKit, A Groupware Toolkit. ACM Transactions on Computer-Human Interaction (March 1996).

35.

Saeki, M., Iguchi, K., and Wen-yin, K. A Meta-model for representing software specification and design methods. In Proceedings of the IFIP WG8.1 Conference on Information Systems Development, Prakash, N., Rolland, C., and Pernici, B., Como, 1993.

36.

Swenson, K.D. A Visual Language to Describe Collaborative Work. In Proceedings of the 1993 IEEE Symposium on Visual Languages, IEEE CS Press, 1993, pp. 298-303.

37.

Swenson, K.D., Maxwell, R.J., Matsumoto, T., Saghari, B., and Irwin, K. A Business Process Environment Supporting Collaborative Planning. Journal of Collaborative Computing 1, 1 (1994).

38.

Thomas, I. and Nejmeh, B. Definitions of tool integration for environments. IEEE Software (March 1992), 29-35.

39.

Venable, J.R. and Grundy, J.C. Integrating and Supporting Entity Relationship and Object Role Models. In Proceedings of the 14th Object-Oriented and Entity Relationship Modelling Conferece (OO-ER'95), Gold Coast, Australia, 1995, LNCS 1021, Springer-Verlag.

40.

Veraart, V.E. and Wright, S.L. Software Development Environments to Support Model Consistency, In Proceedings of the First IFIP/SQI International Conference on Software Quality and Productivity (ICSQP 94), Hong Kong, December 1994.

Page 18