constructing component-based software engineering environments: issues and experiences

Constructing component-based software engineering environments: issuesand experiences

J. Grundya,* , W. Mugridgeb,1, J. Hoskingb,1

aDepartment of Computer Science, University of Waikato, Private Bag 3105, Hamilton, New ZealandbDepartment of Computer Science, University of Auckland, Auckland, New Zealand

Abstract

Developing software engineering tools is a difficult task, and the environments in which these tools are deployed continually evolve assoftware developers’ processes, tools and tool sets evolve. To more effectively develop such evolvable environments, we have been usingcomponent-based approaches to build and integrate a range of software development tools, including CASE and workflow tools, file serversand versioning systems, and a variety of reusable software agents. We describe the rationale for a component-based approach to developingsuch tools, the architecture and support tools we have used some resultant tools and tool facilities we have developed, and summarise thepossible future research directions in this area.q 2000 Elsevier Science B.V. All rights reserved.

Keywords: Component-based software architectures; Multiple views; Consistency management; Tool integration; Task automation

1. Introduction

Software engineering tools are usually complex applica-tions. Many require multiple view support with appropriateconsistency management techniques, most need to supportmultiple user facilities, and all need to support appropriatedegrees of integration with other, often third party, tools.Software developers often want to reuse existing tools aswell as enhance these tools or develop new tools as appro-priate. Integrating a development team’s tool set is oftenessential in order for the team members to use the differenttools effectively on a project. It is a challenging task toprovide these capabilities while ensuring that any resultingdevelopment environment is effective [1–3].

Many approaches to developing software tools exist,including the use of class frameworks [4], databases [5,6],file-based integration [7], message-based integration [8],and canonical representations [3,9]. We have been using acomponent-based approach to develop, enhance and inte-grate software tools [10,11]. Our component-based softwarearchitecture includes abstractions useful for software tooldevelopment. Meta-CASE tools assist in designing andgenerating tools that use this architecture. We have devel-oped a variety of useful software engineering tools using ourtool set. Our experiences to date have shown that software

tools developed with component-based architectures aregenerally easier to enhance and extend, integrate withother tools and deploy than tools developed using otherapproaches.

In the following section we review a variety ofapproaches to software tool construction, identifying theirrespective strengths and weaknesses. We then brieflycharacterise component-based software engineering tools,and provide an overview of our approach to developingsuch tools. Following this, we focus on how ourapproaches provide useful abstractions for buildingtools with support for multiple views, multiple users, toolintegration, and task automation. We conclude by summar-ising our experiences in building and using component-based software engineering tools and outline possible futuredirections for research.

2. Related work

Many approaches exist for building and integrating soft-ware-engineering tools. In the following discussion we useMeyers’ taxonomy to loosely group a variety of tools andtheir architectures, including file-based, message-passing(both local and distributed), database and canonical repre-sentation approaches [2]. We briefly identify the advantagesand disadvantages of each for building tools and forsupporting Wasserman’s taxonomy of types of integration(data, control, presentation and process) [12].

Many Unix-based software tools use a file system-based

Information and Software Technology 42 (2000) 103–114

INFSOF 4069

0950-5849/00/$ - see front matterq 2000 Elsevier Science B.V. All rights reserved.PII: S0950-5849(99)00084-1

www.elsevier.nl/locate/infsof

* Corresponding author. Tel.:164-9-3737599; fax:164-9-3737453.E-mail addresses:[email protected] (J. Grundy); [email protected]

land.ac.nz (W. Mugridge); [email protected] (J. Hosking).1 Tel.: 164-9-3737599; fax:164-9-3737453.

approach for integrating tools into an environment [7]. Thisallows tools to be very loosely integrated, so that buildingand adding new tools is straightforward. However, suchtools generally provide limited data, control and presenta-tion integration mechanisms.

The appearance of tight user interface and control inte-gration of file-based tools can be achieved with message-passing approaches, as used by FIELD, HP Softbench andDEC FUSE [7,8,13]. These approaches allow the existingtools to be wrapped and integrated into an environment veryeffectively. Data and process integration is generally not aswell supported.

Many software tools are built using object-orientedframeworks, and use file or database-based persistency.These are often combined with version control and config-uration management tools to support team development.Examples of such tools include VisualAge [14], EiffelCASE[15], PECAN [16], and Smalltalk-80 [4]. Such tools oftenprovide very polished user interfaces and software develop-ment facilities, but are notoriously difficult to extend andintegrate with third-party tools.

Tools using a database and database views to support datamanagement and data viewing and editing include PCTE-based systems [17], SPADE [1] and EPOS [18]. The data-base provides a unifying data integration mechanism, butmessage passing is often employed to facilitate control inte-gration. Process-centred environments, such as SPADE,EPOS and ProcessWEAVER [19], support process integra-tion by providing software process codification and execu-tion facilities. The control of third-party tools is, however,difficult, as control integration with such tools is often verylimited [20].

A variety of tool generation approaches have been devel-oped. These typically produce database-integrated tools,such as KOGGE [6] and that of Backlund et al. [21], ortools, which use a canonical program representation, suchas MultiView [22], Escalante [23] and Vampire [24]. Gener-ated tools typically have good data, control and presentationintegration, and can provide good process integration via theuse of process-centred environments [1,3]. However, inte-grating generated environments and tools produced usingdifferent architectures or generated by different systemshas proved very difficult, resulting in limited presentation,

data and control integration [1,3,25]. If collaborative workfacilities are needed in such environments, they usuallyhave to be built into the architecture and generator[1,20,26].

Some environments are designed to allow the addition ofother tools. Examples include TeamWAVE [27], wOrlds[28], Oz [29], and Xanth [30]. The architectures of theseenvironments usually focus on supporting control integra-tion with other tools, and to a lesser extent presentation, dataand process integration. Integration is typically limited totools built with the same architecture, though Xanth and Ozprovide quite flexible integration mechanisms for a widerange of tools. Systems using component-based integrationtechniques, such as Xanth and TeamWAVE, have tended tobe more readily extensible and support tighter integrationthan other approaches [27,30].

3. Component-based SEEs

Software components are typically designed with a mini-mal knowledge of and dependency on other components, tofacilitate reuse and deployment by plug-and-play [16,31].Components, like objects, embody data and functionality,and have a well-defined interface. Components extend theobject model by also providing a set of events subscribed toby other components to monitor their state, and somecomponent models also support multiple interfaces for acomponent. Events embody component state change orother “interesting” component behaviour. Components typi-cally publicise information about their data, methods andevents which enables third-party components to query,understand and interact with components for which theyhave no explicitly hard-coded knowledge.

As a result, software tools built using this model aretypically highly reusable and externally controllable byother components. If carefully designed, these component-based tools thus tend to be more readily extended and inte-grated than tools developed using other approaches. Such acomponent-based architectural approach used by some soft-ware tools loosely corresponds to a combination of message,database and canonical representation approaches. Compo-nents communicate via event propagation and/or messageinvocation, but often use other components to managedistributed data. Examples of environments using thisapproach include TeamWAVE [27], COAST [32], CoCo-Doc [33], and SPE-Serendipity [25]. The use of softwarecomponents to model tools and parts of tools typicallyallows more effective data and control integration thanwith other approaches. Presentation and process integrationare also effectively supported if components are welldesigned for extension. Bridges between different compo-nent architectures and the use of Oz-style enveloping tech-niques allow component-based architectures to provide veryeffective third-party tool integration.

Component-based software engineering environments

J. Grundy et al. / Information and Software Technology 42 (2000) 103–114104

Editor

AST

Code Generator

Workflow Tool

Shared File Server

Debugger

Code Module

Fig. 1. A simple component-based SEE.

use a set of integrated components, with each componentproviding a tool or part of a tool used in the environment.Many of these tool components are reusable in other envir-onments and possibly in other domains.

Fig. 1 illustrates the concept of component-based soft-ware tools. This example environment consists of severalcomponents, which implement different software engineer-ing tools and facilities. The editor, code generator anddebugger share an abstract syntax tree (AST) and compiledcode representation. The workflow tool co-ordinates use ofthese tools by monitoring events generated by them and bysending them messages. The workflow tool and data repre-sentation components use a distributed file server to manageshared data.

Any of these tools or data representation componentscould replace another that satisfies the replaced interface(and required semantics). New tools or components can beadded, and may interact with existing components bymonitoring events they generate or by sending themmessages. Some of these tools could usefully be deployedin other domains. For example, the workflow tool andshared file server could be used in an Office Automationenvironment.

The choice of component granularity is made by the tooland component designers, with both large, coarse-grainedcomponents with much functionality and smaller, morelimited component functionality possible. Often largercomponents tend to be less flexible and reusable, but theeffort of tailoring and integrating smaller components ismore considerable.

When designing and building component-based softwareengineering tools, a variety of issues must be addressed,including:

• Appropriate identification of components, allocation ofdata and behaviour to components and design of compo-nent interfaces.

• Design of common components for software tool abstrac-tions such as repository management, multiple view, andcollaborative work support.

• Appropriate design of components to permit externalmonitoring, control and user interface extension, thussupporting component reuse, enhancement and integra-tion.

• Provision of appropriate architectures and tools so thattool developers can effectively design, build and deploycomponent-based tools.

• Provision of appropriate support to tool end users fordeploying and integrating tools and enhancing environ-ment behaviour via task automation agents.

Fig. 2 shows the Serendipity-II software process model-ling and enactment environment, a component-based soft-ware-engineering tool that we have developed [34].Serendipity-II illustrates how components can be designed,built and combined to build a sophisticated software engi-neering environment. Visual process modelling viewsprovide editors and multiple views of process models,using components with extensible user interfaces and eventsthat can be monitored. The graphical representation compo-nents are separated from the process model data representa-tion components so that these can be developedindependently. Task automation agents are specifiedvisually with components in the model reused by endusers. Reusable components are used to implement reposi-tory management, multiple user editing and versioningsupport, event history management, and communication

J. Grundy et al. / Information and Software Technology 42 (2000) 103–114 105

Componentswith userinterfaces…

User-defined agentsbuilt from reuseablecomponents

Persistency,collaborative worksupported bycomponents

Fig. 2. Serendipity-II: an example of component-based software engineering tool.

facilities. In the following sections we outline our compo-nent-based approach to environment development, anddemonstrate how that approach can be used to constructtools such as Serendipity-II, and describe our experiencesin developing such tools.

4. Overview of our approach

JViews is a component-based software architecture andJava class framework which we have developed for imple-menting complex CASE tools, design environments andInformation Systems like Serendipity-II [10]. JComposeris a metaCASE tool used to design and generate JViews-based environments. JComposer is used in conjunction withthe BuildByWire iconic editor design tool [35], and theJVisualise run-time component visualisation and configura-tion tool [10].

4.1. JViews component-based architecture

JViews provides a set of abstractions for modelling andimplementing software components. The JViews frame-work is implemented using JavaBeans [16], chosen becauseof its simple, extensible architecture and ability to bridge toother component-based frameworks. JViews componentsembody data, functions and events, with a novel event

subscription and notification scheme employed. JViewscomponent events include component data modificationevents, but also may include other “interesting” eventssuch as view display, other users joining/leaving a session,tool invocation and/or external tool events, etc. A JViewscomponent may represent a small piece of software toolinformation, such as a view element (icon) or repositoryelement, or may embody a large piece of information(e.g. source code file), or the interface to a complex externaltool.

JViews explicitly supports the design and implementationof applications with multiple, editable views of information,and multiple, distributed users. A variety of persistency,component distribution and collaborative editing andcommunication facilities are provided by reusable JViewscomponents. Many abstractions relating to these capabilitiesare lacking in other component-based toolkits. The JViewsclass framework includes components supporting:

• Repository and view component, relationship and viewlayer abstractions. These allow designers to representboth fine and coarse-grained repository and viewinformation.

• View consistency management relationships, used tokeep multiple views consistent.

• Local, high performance persistency management for


component

relationship

link

Stage iconStage icon

Enactment glue

View layer

View comps

Editing history

Collaborativeediting

to other users…

View relView rel

View rel

Base Stage

Base link

Base Stage

repository

Base stages

…

…

…

Send/receivechanges

Ensure unique names

event propagation

semantics/agent

versioning

persistncy

3rd party tool

RepresentationLayer

Repository ("Base")Layer

ViewLayer

Edit e.g. renamestage…

Fig. 3. Some JViews components from Serendipity-II.

repository and view components using files and apersistent store.

• Distributed version management and data and eventinterchange components.

• Inter-environment event broadcasting components,supporting both asynchronous and synchronous editingvia event and data exchange.

• Interfaces to external tools, providing a component-basedwrapper to external tool functionality.

• Software “agents”, built from small event filtering andactioning components, that encapsulate commonly usedevent processing functionality.

• These also permit JViews-based environments to bedynamically extended.

These reusable components make building new environ-ments much easier, and also allow tools added to an existingenvironment to find and use components providing suchfacilities.

Fig. 3 shows the modelling of part of Serendipity-IIin JViews. Components represent units of data andfunctionality that can be statically or dynamicallylinked to other components via relationships. A flexibleevent propagation and response model allows compo-nents to monitor other components and respond to statechange or other events. Events from other componentscan be acted on, but can also be modified, vetoed orprevented from reaching other components. Events canbe stored to support modification histories, undo/redo andversioning.

4.2. JComposer metaCASE tool

It is difficult to implement complex, component-basedsystems without good CASE tool support. We have devel-oped JComposer to provide such support for systems devel-oped with the JViews architecture. JComposer providesmultiple views of JViews component specifications. Itgenerates JViews classes to implement component models,and can be used to reverse engineer JViews classes into ahigh-level, visual architecture description language, similarto that used in Fig. 3.

Windows (1) and (2) in Fig. 4 show JComposer beingused to model various Serendipity-II repository and viewcomponents. The component designer can specify informa-tion about components in various views, including func-tional and non-functional requirements, attributes,methods, relationships and events supported by the compo-nent, view mappings, and detailed code generated informa-tion. A novel event filter and action language allows staticand dynamic event handling behaviour for components to becaptured at a high level. This language was adapted inSerendipity-II to provide an agent specification and deploy-ment language for end users. Various validation tests can beperformed on a component model in JComposer to ensuregenerated JViews components are correct.

Windows (3) and (4) in Fig. 4 show the BuildByWireiconic editor design and generation tool. BuildByWireallows software tool builders to design complex iconicrepresentations and generate JavaBean implementations ofthese and their editors. JComposer then allows tool


(2)

(3) (4)

(1)

Fig. 4. JComposer and BBW metaCASE tools in use.

J.G

run

dy

et

al.

/In

form

atio

na

nd

So

ftwa

reT

ech

no

log

y4

2(2

00

0)

10

3–

11

4108

View Layer Component

Process Stage Icon Process Stage Icon

Process Stage Link…

View Relationship

Base Process Stage

View Layer Component

…

Event History

1. user edits icon; viewcomponent changed

2. event sent to view layer& view relationship

3. event stored

4. base stageupdated

5. event sentto view rels

6. view iconsupdated

7. iconic representationredisplayed

2. A StageTeam

1. A StageTeam

(a) (b)

Fig. 5. Multiple view support in JComposer. (a) Example of multiple views in Serendipity-II. (b) JViews architecture supporting multiple views.


Stage Icon

Base Stage

Stage Icon

Link Glue

Serendipity-II Repository

View

…

Base Event

Base Stage…

Version Record

Other views…

"Collaborative Menu"

Collaboration“sender”

Other user'sCollaboration

receivers

Collaboration"receiver"

Other user'sCollaboration

senders

(a)

(b)

Fig. 6. Collaborative view editing and versioning support. (a) Example of asynchronous collaborative editing. (b) Software components supportingcolla-borative editing.

developers to link JViews view components to these Java-Bean components. The separation of presentation and viewdata has proved very effective in allowing tool developers toeasily reuse iconic forms and replace view componenticonic representations.

5. Multiple view support

JViews represents a tool repository’s data structure, ordata dictionary, using components. Semantics are oftenembodied in these repository-level components, or may bespecified by additional components that monitor structuralcomponent state-change events, enforcing repositoryconstraints.

Multiple views are supported by relationship componentsthat link repository components representing tool datadictionary information to view components. Events gener-ated due to modifications of the data dictionary componentsare monitored by the relationship and forwarded to the viewcomponents and vice versa. Thus when view componentsthat represent repository structures are modified, iconicrepresentations are updated and redisplayed. Editinghistories are maintained for views and repository compo-nents, using a common reused history component.

Fig. 5 shows how multiple views are modelled for parts ofSerendipity-II using JViews. In Fig. 5(a) two process stageviews contain reference to the same stage. An editinghistory for one view is also shown. Fig. 5(b) shows theJViews components corresponding to each view, and theshared repository, together with event flows when one ofthe process stage icons is modified. The event representingthe change is recorded in the view’s history component, andis also propagated via the view relationship to the repositorycomponent representing the process stage: this causes therepository component to update its state, thus generatingevents that are propagated to the corresponding processstage icon components in other views. The latter modifytheir state accordingly to maintain consistency with theinitial view.

This is one example of a range of sophisticated inconsis-tency management facilities provided by JViews viewcomponents. These provide tool users with a range of tech-niques for keeping information consistent and for managinginconsistencies [19].

JViews view components also support extensible userinterfaces; other components may modify their interfacesappropriately to support seamless user interface extension[19].

We have found the software component-based approacheffective for supporting multiple views. New views andview components can be plugged into an environment with-out altering existing components. Our JViews componentsgenerate event objects that can be stored, undone andredone. Hence undo/redo and version control facilities canbe achieved by adding components to manage these stored

events. These event history components can be replaced, atrun-time, with others, providing different facilities as neces-sary. Effective inconsistency management in large, multipleview software engineering environments is typically one ofthe most difficult features to provide. JView’s componentbased approach provides many useful abstractions that canbe combined together simply to produce inconsistencymanagement solutions that are much more difficult toprovide with more conventional approaches [19].

6. Collaborative work and tool integration support

Nearly all multi-user software-engineering tools buildmultiple user support into the tool as it is developed. Incontrast, our component-based approach allows collabora-tive work-supporting facilities to be added as needed to atool. This may even be done at run-time. JViews compo-nents broadcast state change events which can be monitoredby other components, both before and after the stage changeoccurs (the former permitting veto of an operation before ittakes effect).

Synchronous and asynchronous editing facilities (includ-ing locking) can thus be added to existing JViews-basedenvironments through the addition of extra collaborationcomponents monitoring existing event sources and forward-ing them to other environments. This can be done with nomodification to the existing environment or to the addedgeneric collaboration component [19].

Fig. 6(a) shows a “collaboration” menu in use in Seren-dipity-II to configure the “level” of collaborative editingwith a colleague: asynchronous, synchronous and “presen-tation” (i.e. show editing changes to others as they occur butdo not action them). The “change history” dialogue on thebottom, right hand side shows a history of editing events forthe user’s process model. Some changes were made by theuser (“John”), and others by a collaborator (“Mark”).

The illustration in Fig. 6(b) shows how these collabora-tive editing components were added to Serendipity-II. Suchcomponents may be added to any JViews-based environ-ment, with no change to the components or the componentsthat make up the environment.

A “collaboration menu” component is created when theuser specifies that they want a view to be collaborativelyedited. This component listens to editing changes in theview, and records them in a version record component. Ifthe user is in presentation or synchronous editing mode withanother user, the changes are propagated to that user’s envir-onment. This is achieved via a decentralised, point-to-pointmessage exchanging system comprising of a “changesender” component and a “change receiver” component ineach user’s environment. A sender propagates view editingchanges to each other users’ environment who is interestedin such a change, i.e. all those who are collaboratively edit-ing the view.

A user’s environment receives view-editing changes and


passes them to the appropriate view collaborative editingcomponent. This then stores and presents the receivedchange in a dialogue (presentation mode editing) or actionsit on the view (synchronous mode editing). In asynchronousediting mode, users request a list of changes made to anotheruser’s view and select, via a dialogue, those they wish tohave applied to their own version of the view.

To support the replication of components (via objectversioning), JViews has abstractions that are used to main-tain copies of collaboratively edited views. When eventsthat describe changes generated in one view are propagatedto another user’s environment any component references aretranslated appropriately.

Tool integration is supported in JViews-based environ-ments in a similar manner to multiple views. Componentswhich are part of one tool can request notification of eventsfrom components which are part of another tool, or can sendthese other tool components messages, facilitating controlintegration. Data integration is facilitated by a JViewscomponent providing an interface for components in oneenvironment to access data in another environment withno knowledge of the other environment’s implementation.JViews provides abstractions for identifying and communi-cating between components that are running in differentvirtual machine environments or that are resident on differ-ent physical machines.

Fig. 7 shows a Serendipity-II component monitoring anevent history component associated with a JComposer view.When the Serendipity-II component is sent a modificationevent from the JComposer component, it passes this on to acomponent that determines if the event is of interest. If so, athird Serendipity-II component notifies the user of Seren-dipity-II.

Component-based software tools facilitate integrationmore readily than most other architectures for buildingtools, as components have well-defined interfaces withevent monitoring mechanisms built in. Component-basedtools also tend to be engineered for reuse and extension,allowing other components to externally control them andextend their user interfaces as necessary.

The success of this approach can be seen with Serendip-ity-II. Its component-based construction allows it to beseamlessly “bolted on” to any other JViews-based tool,providing that tool with integrated process modelling andenactment capabilities, without modification to the originaltool [34].

7. Environment extension and task automation

Software engineering environments need to support enduser configuration of tools, extension of the environment,and automation of various tasks. For example, the user maywish to be notified of specific changes or to have additionalconstraints enforced. These capabilities allow environmentsto be adapted to changing work processes and tool sets ofsoftware developers.

Serendipity-II allows for user enhancement via its visualevent filtering and actioning language. This allows users toadd, configure and link components into the environment.These event filtering and actioning models can then bedeployed as “software agents” which modify an environ-ment’s composition and behaviour.

Fig. 8 shows two examples of such agents: a simple taskautomation agent that also illustrates tool integration, and adistributed notification agent. The icons in these modelsrepresent Serendipity-II processes (ovals with label androle name), event filters (square icons with question markon left-hand side), event actions (shaded icons with singlelabel) and JViews components (square icons). Adding theseicons to a Serendipity-II agent specification view createsappropriate JViews components that handle events ormessages sent to the component. The example on the leftinstructs Serendipity to download or upload files to/from ashared file server when a particular process stage is enacted(started) or finished.

The example on the right has two parts. The agent on theleft runs in user John’s environment. The one on the rightruns in Bill’s environment, and gathers changes made byBill to the “Shape” and DrawingPanel2” classes while doing


JComposer Event History Serendipity-II "Event Receiver"

Serendipity-II "Filter"

Serendipity-II "Action"

1. request notificationof events

3. receive event4. is event one we'relooking for?

5. yes - notify user

Serendipity-II ToolJComposer Tool

JComposer Component

2. store change

Edit comp. icon

(data/event exchange viaJViews middleware

abstractions)

Fig. 7. A simple tool integration example.


(a)

(b)

Fig. 8. Specifying simple task automation agents. (a) Simple, local software agent for tool integration. (b) Distributed software agent for notification.

the “modify code” process activity. These changes areforwarded by the “send to john’s receiver” action to the“receive bill’s code changes” action in the agent runningin John’s environment. John’s agent stores the changes ina JViews history component “Bill’s code changes” (leftbranch). It also notifies John by message if any change ismade to the Shape class (right branch). The component-based architecture of JViews-based environments allowstask automation and tool integration facilities to be straight-forwardly built using our event filtering and actioningmodel.

JViews components generate events which can be filteredor used to produce a wide variety of “actions” (notify user,abort operation, communicate with another tool/component,open/close views, store change event, etc). We have built avariety of reusable JViews components to help facilitate theconstruction of software agents like those in Fig. 7. Theseinclude components to: perform parameterised filtering ofevents; inter-machine event passing and operation invoca-tion; store events; notify users of events and support usercommunication; and provide interfaces to various thirdparty tools (e.g. MS Worde and Excele, Eudorae, Nets-capee and WinEdite).

8. Future research opportunities

Our experiences with component-based software engi-neering tools have so far been very positive. Environmentslike JComposer and Serendipity-II were easier to build thancomparable earlier systems we developed without usingcomponents [36]. This has been due to the high degree ofreusability of our JViews components, the useful set ofmiddleware and user interface abstractions embodied byJViews components, and the use of the JComposer andBuildByWire metaCASE tools. We have been able toextend environments like Serendipity-II using our visualevent filtering and actioning facility. This has allowed usto easily develop and deploy new reusable components fortool integration and environment extension, without havingto substantially modify existing structures and behaviour.

As more software tools begin to utilise component-basedarchitectures, like JavaBeans [16] and COM [37], anddistributed object management facilities like CORBA[38], it becomes easier to effectively integrate such toolswith JViews-based environments. Better middlewarecomponents supporting collaborative work, persistency,distribution, parallel processing and remote notificationwill allow better performing software tools to be built. Ifappropriate component interface designs have been used forsuch middleware capabilities, upgrading environment infra-structures also becomes easier and more successful.

A problem we encountered with some JViews and Build-ByWire components was poor extensibility of their userinterfaces. Components need to be designed so that theiruser interfaces can be appropriately extended by other

components, to ensure a consistent look-and-feel and totailor the user interface to suits the needs of subsets ofusers. This becomes more difficult as highly reusablecomponents are developed whose application domains arenot fully known during their design, and when third-partycomponent-based tools are reused. Similar issues arise withmiddleware component interface and capability design,requiring the development of better component-basedsystem interface and design standards.

Multiple view and tool integration support necessarilyinvolves mapping operations and/or events from compo-nents in one view/tool into another. Support for complexinter-component event and operation mapping is lackingin most component-based systems, making developmentof multiple views and tools more difficult. This is an areawe have attempted to address in our work, but additionalwork is needed. We have developed basic version controltools using JViews, but are investigating the use of third-party versioning and configuration management tools.

Software developers are tending to require more controlover the configuration of their tools, composition of theirenvironments and behaviour of their tools. Appropriate end-user configuration facilities for component-based systemsare thus essential to ensure they are effective. Similarly,the use of software agents to automate tasks and the effec-tive cataloguing and retrieval of reusable componentsremain issues requiring further research.

9. Conclusions

Our experience in the development of complex compo-nent-based software engineering tools has convinced us ofthe value of a component-based approach. The modularityprovided by component interfaces and the flexibilityprovided by the “plug and play” event-based compositionof components have proven to be of considerable value inthe both the development of such environments, and theprovision of end users with the capability to tailor andextend the environments. Several issues remain to be solvedto enable software components in general to be used on alarge scale and these also impact on our work on the genera-tion of software engineering tools.

Acknowledgements

The many helpful comments of the anonymous reviewerson earlier drafts of this paper and the support for parts of thiswork from the New Zealand Public Good Science Fund aregratefully acknowledged.

References

[1] S. Bandinelli, E. DiNitto, A. Fuggetta, Supporting cooperation in theSPADE-1 environment, IEEE Transactions on Software Engineering22 (12) (1996) 841–865.


[2] S. Meyers, Difficulties in integrating multiview editing environments,IEEE Software 8 (1) (1991) 49–57.

[3] C. Marlin, B. Peuschel, M. McCarthy, J. Harvey, MultiView-Merlin:an experiment in tool integration, Proceedings of the Sixth Confer-ence on Software Engineering Environments, IEEE CS Press, 1993.

[4] A. Goldberg, D. Robson, Smalltalk-80: The Language and its Envir-onment, Addision-Wesley, Reading, MA, 1984.

[5] D. Daberitz, U. Kelter, Rapid prototyping of graphical editors in anopen SDE, Proceedings of the Seventh Conference on Software Engi-neering Environments, Noordwijkerhout, Netherlands, 5–7 April,IEEE CS Press, 1995 pp. 61–73.

[6] J. Ebert, R. Suttenbach, I. Uhe, Meta-CASE in practice: a case forKOGGE, Proceedings of CaiSE’97, Barcelona, Spain, 10–12 June,LNCS 1250, Springer, Berlin, 1997 pp. 203–216.

[7] M.A. Champine, A visual user interface for the HP-UX and domainoperating systems, Hewlett-Packard Journal 42 (1) (1991) 88–99.

[8] S.P. Reiss, Connecting tools using message passing in the field envir-onment, IEEE Software 7 (7) (1990) 57–66.

[9] B. Magnusson, U. Asklund, S. Mino¨r, Fine-grained revision controlfor collaborative software development, Proceedings of the 1993ACM SIGSOFT Conference on Foundations of Software Engineer-ing, LA, 1993, pp. 7–10.

[10] J.C. Grundy, J.G. Hosking, W.B. Mugridge, Static and dynamicvisualisation of software architectures for component-based systems,Proceedings of SEKE’98, San Francisco, 18–20 June, KSI Press,1998.

[11] J.C. Grundy, J.G. Hosking, W.B. Mugridge, Coordinating distributedsoftware development projects with integrated process modelling andenactment environments, Proceedings of the Seventh IEEE Work-shops on Enabling Technologies: Infrastructure for CollaborativeEnterprises, Palo Alto, 17–19 June, IEEE CS Press, 1998.

[12] A. Wasserman, Tool integration in software engineering environ-ments, Software Engineering Environments: International Workshopon Environments, Springer, Berlin, 1990.

[13] R.O. Hart, G. Lupton, DECFUSE. Building a graphical softwaredevelopment environment from Unix tools, Digital Technology Jour-nal 7 (2) (1995) 5–19.

[14] IBM Corporation, IBM Visual Age for Javae, http://www.softwar-e.ibm.com.ad.vajava, 1997.

[15] Interactive Software Engineering Inc., Eiffel CASEe, http://www.eiffel.com/products/case.html, 1998.

[16] J. O’Neil, H. Schildt, Java Beans Programming from the Ground Up,McGraw-Hill, New York, 1998.

[17] B. Bird, An open systems SEE query language, Proceedings of theSeventh Conference on Software Engineering Environments, Noord-wijkerhout, Netherlands, 5–7 April, IEEE CS Press, 1995.

[18] R. Conradi, M. Hagaseth, J. Larsen, M.N. Nguyen, B.P. Munch, P.H.Westby, W. Zhu, M.L. Jaccheri, EPOS: Object oriented cooperativeprocess modeling, in: A. Finkelstein, J. Kramer, B. Nuseibeh (Eds.),Software Process Modeling & Technology, Research Studies Press,1994.

[19] C. Fernsto¨m, ProcessWEAVER: Adding process support to UNIX,Second International Conference on the Software Process: Continu-ous Software Process Improvement, Berlin, Germany, February,IEEE CS Press, 1993 pp. 12–26.

[20] E. Di Nitto, A. Fuggetta, Integrating process technology andCSCW, Proceedings of IV European Workshop on Software

Process Technology, Leiden, Netherlands, April, LNCS, Springer,Berlin, 1995.

[21] B. Backlund, O. Hagsand, B. Pherson, Generation of visual language-oriented design environments, Journal of Visual Languages andComputing 1 (4) (1990) 333–354.

[22] R.A. Altmann, A.N. Hawke, C.D. Marlin, An Integrated program-ming environment based on multiple concurrent views, AustralianComputer Journal 20 (2) (1988) 65–72.

[23] J.D. McWhirter, G.J. Nutt, Proceedings of the IEEE Symposium onVisual Languages, IEEE CS Press, 1994, pp. 1994.

[24] D.W. McIntyre, Design and implementation with vampire, in: M.Burnett, A. Golberg, T. Lewis (Eds.), Visual Object-OrientedProgramming, Manning Publications, Greenwich, CT, 1995.

[25] J.C. Grundy, J.G. Hosking, Serendipity: integrated environmentsupport for process modelling, enactment and work coordination,Automated Software Engineering 5 (1) (1998) 25–60.

[26] J.C. Grundy, Human interaction issues for user-configurable colla-borative editing systems, Proceedings of APCHI’98, Tokyo, Japan,15–17 July, IEEE CS Press, 1998 pp. 145–150.

[27] M. Roseman, S. Greenberg, Simplifying Component development inan integrated groupware environment, Proceedings of the ACMUIST’97, ACM Press, 1997.

[28] D.P. Bogia, S.M. Kaplan, Flexibility and control for dynamic work-flows in the wOrlds environment, Proceedings of the ACM Confer-ence on Organisational Computing Systems, Milpitas, CA, November1995.

[29] G. Valetto, G.E. Kaiser, Enveloping sophisticated tools into process-centred environments, Automated Software Engineering 3 (1996)309–345.

[30] G.E. Kaiser, S. Dossick, Workgroup middleware for distributedprojects, IEEE WETICE’98, Stanford, 17–19 June, IEEE CS Press,1998 pp. 63–68.

[31] C.A. Szyperski, Component Software: Beyond Object-OrientedProgramming, Addison-Wesley, Reading, MA, 1997.

[32] C. Shuckman, L. Kirchner, J. Schummer, J.M. Haake, Designingobject-oriented synchronous groupware with COAST, Proceedingsof ACM CSCW’98, November, ACM Press, 1996 pp. 21–29.

[33] G.H. Ter Hofte, H.J. van der Lugt, CoCoDoC: a framework for colla-borative compound document editing based on OpenDoc andCORBA, Proceedings of the IFFIP/IEEE International Conferenceon Open Distributed Processing and Distributed Platforms, 26–30May 1997, Toronto, Canada, pp. 15–33.

[34] J.C. Grundy, M.D. Apperley, W.B. Mugridge, J.G. Hosking, Anarchitecture for decentralized process modelling, IEEE InternetComputing September/October (1998) 53–62.

[35] W.B. Mugridge, J.G. Hosking, J.C. Grundy, Vixels, CreateThroughs,DragThroughs and AttachmentRegions in BuildByWire, Proceedingsof OZCHI98, Adelaide, Australia, 30 November–4 December, IEEECS Press, 1998 pp. 320–327.

[36] J.C. Grundy, J.G. Hosking, S. Fenwick, W.B. Mugridge, Connectingthe pieces, in: M. Burnett, A. Goldberg, T. Lewis (Eds.), VisualObject-Oriented Programming, Prentice-Hall, Englewoods, NJ,1995 chap. 11.

[37] R. Sessions, COM and DCOM: Microsoft’s Vision for DistributedObjects, Wiley, New York, 1998.

[38] Object Management Group, OMG CORBA, http://www.omg.org/,1998.


constructing component-based software engineering environments: issues and experiences

Documents