Constructing Component-based Software Engineering Environments:Issues and ExperiencesJohn Grundy 1, Warwick Mugridge 2, John Hosking 21 Department of Computer Science, University of Waikato, Private Bag 3105, Hamilton, NewZealand, Ph: +64-7-838-4452, Fax: +64-7-838-4155, [email protected] Department of Computer Science, University of Auckland, Private Bag, Auckland, New Zealand,Ph: +64 9 3737599, Fax: +64 9 3737453, {john,rick}@cs.auckland.ac.nzAbstractDeveloping software engineering tools is a difficult task, and the environments in which these tools are deployedcontinually evolve as software developers’ processes, tools and tool sets evolve. To more effectively develop suchevolvable environments, we have been using component-based approaches to build and integrate a range of softwaredevelopment tools, including CASE and workflow tools, file servers and versioning systems, and a variety of reusablesoftware agents. We describe the rationale for a component-based approach to developing such tools, the architectureand support tools we have used, some resultant tools and tool facilities we have developed, and summarise possiblefuture research directions in this area.Keywords: component-based software architectures, multiple views, consistency management, tool integration, taskautomation1. IntroductionSoftware engineering tools are usually complexapplications. Many require multiple view support withappropriate consistency management techniques, mostneed to support multiple user facilities, and all need tosupport appropriate degrees of integration with other,often third party, tools. Software developers often want toreuse existing tools as well as enhance these tools ordevelop new tools as appropriate. Integrating adevelopment team’s tool set is often essential in order forthe team members to use the different tools effectively ona project. It is a challenging task to provide thesecapabilities while ensuring that any resultingdevelopment environment is effective [3, 29, 26]. Many approaches to developing software tools exist,including the use of class frameworks [12], databases [8,10], file-based integration [6], message-based integration[34], and canonical representations [25, 26]. We havebeen using a component-based approach to develop,enhance and integrate software tools [16, 17]. Ourcomponent-based software architecture includesabstractions useful for software tool development. Meta-CASE tools assist in designing and generating tools thatuse this architecture. We have developed a variety ofuseful software engineering tools using our tool set. Ourexperiences to date have shown that software toolsdeveloped 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 building toolswith support for multiple views, multiple users, toolintegration, and task automation. We conclude bysummarising our experiences in building and usingcomponent-based software engineering tools and outlinepossible future directions for research.2. Related WorkMany approaches exist for building and integratingsoftware engineering tools. In the following discussionwe use Meyers’ taxonomy to loosely group a variety oftools and their architectures, including file-based,message-passing (both local and distributed), databaseand canonical representation approaches [29]. We brieflyidentify the advantages and disadvantages of each forbuilding tools and for supporting Tomas’ taxonomy oftypes of integration (data, control, presentation andprocess) [39].Many Unix-based software tools use a file system-based approach for integrating tools into an environment[6]. This allows tools to be very loosely integrated, sothat building and adding new tools is straightforward.However, such tools generally provide limited data,control and presentation integration mechanisms.The appearance of tight user interface and controlintegration of file-based tools can be achieved withmessage-passing approaches, as used by FIELD, HPSoftbench and DEC FUSE [6, 21, 34]. These approachesallow existing tools to be wrapped and integrated into anenvironment very effectively. Data and processintegration is generally not as well supported.Many software tools are built using object-orientedframeworks, and use file or database-based persistency.These are often combined with version control andconfiguration management tools to support teamdevelopment. Examples of such tools include VisualAge[23], EiffelCASE [24], PECAN [32], and Smalltalk-80[12]. Such tools often provide very polished userinterfaces and software development facilities, but arenotoriously difficult to extend and integrate with third-party tools.Tools using a database and database views to supportdata management and data viewing and editing includePCTE-based systems [4], SPADE [3] and EPOS [7]. Thedatabase provides a unifying data integration mechanism,but message-passing is often employed to facilitatecontrol integration. Process-centred environments, suchas SPADE, EPOS and ProcessWEAVER [11], supportprocess integration by providing software processcodification and execution facilities. The control of third-party tools is, however, difficult, as control integrationwith such tools is often very limited [9].A variety of tool generation approaches have beendeveloped. These typically produce database-integratedtools, such as KOGGE [10] and that of Backlund et al [2],or tools which use a canonical program representation,such as MultiView [1], Escalante [28] and Vampire [27].Generated tools typically have good data, control andpresentation integration, and can provide good processintegration via the use of process-centered environments[3, 26]. However, integrating