INFSOF 4065

Information and Software Technology 42 (2000) 73–77 www.elsevier.nl/locate/infsof

Issues in software engineering tool construction J.P. Gray a,*, A. Liu b,1, L. Scott c,2 a

School of Information Technology and Computer Science, University of Wollongong, Wollongong, NSW 2522, Australia b CSIRO Mathematical and Information Sciences, Locked Bag 17, N. Ryde, NSW 1670, Australia c Fraunhofer Institute for Experimental Software Engineering (IESE), Sauerwiesen 6, 67661 Kaiserslautern, Germany

Abstract A brief introduction to software engineering tools is presented, and issues involved in the construction of these tools are discussed. Some of the current issues concerning tool developers are highlighted, which include: metaCASE technology, cognitive support, evaluation and validation of tools, and data interchange. Some recent developments in tool construction techniques are examined, and opportunities for further research and development in tool building are identified. q 2000 Elsevier Science B.V. All rights reserved. Keywords: MetaCASE; Cognitive support; Data interchange; Components; Process modelling; Tool architectures

1. Introduction This paper provides an overview of current issues in software engineering tool construction. This is potentially a very large and open-ended topic, so we will start by explaining what we mean by software engineering tool and constructional issues. By software engineering tool we mean any software tool that provides some automated support for the software engineering process [1]. This is quite an encompassing definition that covers a number of levels of automated tool support, including: • support for development activities, including specification, design, implementation, testing and maintenance; • support for process modelling and management; • meta-tool technology, such as metaCASE products, used for the generation of custom tools to support particular activities or processes. Within each level of support, we can find differing breadths of support [2]: • individual tools that support one particular task; • workbenches, or toolsets, that support a number of related tasks; • environments that support the whole, or at least a large part, of the development process. * Corresponding author. Tel: 1 61-2-4221-3606; fax: 1 61-2-42214170;. E-mail addresses: [email protected] (J.P. Gray); anna.liu@cmis. csiro.au (A. Liu); [email protected] (L. Scott). 1 Tel.: 1 61-2-9325-3237; fax: 1 61-2-9325-3280. 2 Tel.: 1 49-6301-707-212; fax: 1 49-6301-707-200.

These definitions include many different kinds of software engineering tools variously known as CASE (Computer Aided Software Engineering), CAME (Computer Aided Method Engineering), IPSE (Integrated Project Support Environment), SEE (Software Engineering Environment), metaCASE, CSCW (Computer Supported Cooperative Work), and Workflow Management Systems. These tools differ considerably in purpose and scale. However, our interest lies not in the application of these different kinds of tools, but in the engineering of the tools themselves. Developers of these tools often face similar constructional issues, such as: selection of host computing platform and implementation language, conformance with standards and reference models, choice of repository, integration and interoperability mechanisms, and user interface style. What we present in this paper, is a brief report of the constructional issues that we have found tool developers are currently concerned about. Clearly, these issues are not of universal concern to all tool developers, and this is not an exhaustive list of all issues that might be of concern to developers. However, we believe many tool developers will find this report informative, and a useful reference point in their tool construction activities.

2. MetaCASE Software engineering tools are complex pieces of software, often involving database, user interface, and analysis components. Many are also distributed, often multi-user, and possibly multi-platform environments. The aim of metaCASE technology [3] is to provide meta-tools that

0950-5849/00/$ - see front matter q 2000 Elsevier Science B.V. All rights reserved. PII: S0950-584 9(99)00080-4

74

J.P. Gray et al. / Information and Software Technology 42 (2000) 73–77

make building quality CASE tools quicker and easier. Usually, metaCASE tools work on the philosophy that all CASE tools have certain standard characteristics (such as the need for a graphical user interface and a data repository), but individual CASE tools differ in the methods they support, the data they manipulate, and the functionality they provide. Therefore, metaCASE tools provide mechanisms to configure a graphical user interface, a data repository, and perhaps some extra functionality, such as analysis tools and code generators. Development of this metaCASE technology is in itself an important area of software engineering research, and a significant enabling technology for the practice of method engineering [4]. From the origins of metaCASE in the 1980s [5–7] a number of commercial metaCASE products have emerged [8,9]. There are two principal approaches to tool generation used by metaCASE products. 1. Specify and generate. In this approach [8–10], the metaCASE tool provides the framework for the CASE tool, and the metaCASE user specifies the details of the tool they want in a specification language (usually specific to the metaCASE tool). Typically, these specification languages allow the user to configure the data structures in the tool, the user interface and specific notations, and to specify standard functionality such as code generation tools. 2. Assemble from components. Using this approach [11,12], a standard set of components is provided in an object-oriented programming language, and the metaCASE user is able to specialise these components and combine them together into a CASE tool. The user works in the language of the programming environment, but is protected from the complex details of the CASE tool implementation by the abstraction techniques provided by object-oriented languages (in particular, generalisation). It is not clear whether one approach is better than the other. The first approach has the advantage of providing high-level, tailored languages for CASE tool construction, whereas the second approach has the advantage that the CASE tool builder does not need to learn new languages. Using an object-oriented, component-based approach, the designers of MetaMOOSE [11] demonstrate how their system is flexible enough to allow the metaCASE user to code functionality for which the component set was not originally designed. With the specify and generate approach, this would be hard, because the CASE tool builder does not have access to any specification languages other then the ones provided by the metaCASE tool, which by their nature are restricted to specifying what the metaCASE tool was designed for. For the user of a metaCASE product, the benefits of power, flexibility, and rapid tool development time provided by metaCASE technology have to be offset against the considerable investment of learning time needed to operate the metaCASE tool

satisfactorily. Whichever approach to tool generation is followed, it is a challenge for developers of metaCASE products to make their products easier to use and quicker to learn, yet retain flexibility and expressive power.

3. Methods, tools and UML The emergence of the Unified Modeling Language (UML) [13] raises some interesting issues for tool constructors. UML incorporates a number of object oriented analysis and design techniques into a single modelling language, and there are many CASE tools, such as the Rose product [14], designed to support UML. Although strictly a modelling language rather than a development method, a software development process based around UML has been devised [15]. Given the apparent popularity of object-oriented methods and notations, tool developers may wish to consider utilising technologies such as UML in some way. Apart from the obvious usage of building a tool to support UML modelling techniques, UML could itself be used for the design and implementation phases in the construction of a software engineering tool. Alternatively, for tools which neither support UML nor have used UML in their construction, some form of compatibility or integration with UML models and tools might be considered. There are situations where the principal motivation for constructing a tool is not the usual one of providing automated support for some new method or technique. The motivation for constructing a tool may be to investigate certain aspects of tool development or usage, such as cognitive support [16], tool generation techniques, or tool interoperability mechanisms. In such cases, the choice of a wellknown and well-documented standard method to support, allows the tool developer to focus on their primary goal rather than become concerned with issues of method development. For the developers of metaCASE products, the possibility of something like UML becoming the dominant objectoriented development technology does not diminish the need for metaCASE built tools. There will always be a need for methods and tools that are specifically not objectoriented, and no matter how sophisticated and comprehensive a standard method becomes, software engineers will always want to customise and improve a standard method. In situations like these, where either unique tools or customised tools are required, the metaCASE approach to tool construction is clearly an option worth considering.

4. Evaluation and validation There is not a lot of hard evidence as to the “pay-off” users get for using a particular tool. Generally, it is hard to provide evidence of productivity gains, or increases in the quality of the product, derived from the automated support provided by the tool. We have anecdotal evidence, but relatively little

J.P. Gray et al. / Information and Software Technology 42 (2000) 73–77

empirical data. Poor usability could be a major factor as to why some software engineering tools have not gained as much acceptance as they perhaps deserve. Sometimes the complexity of a tool deters users from learning to operate and adopt it, and perhaps people would rather have simple tools that they can apply quickly and effectively. When considering the quality of a tool, usability is better assessed first and usefulness (as in, does the tool provide some useful functionality to the user?), second. This approach recognises that it is impossible for a tool to be useful if it is not usable. Still, today, most companies do not undertake proper usability evaluation. Some people mistake conformation to an interface standard (e.g. a Windowing standard) as a test of usability, whereas this is just a test of conformance to a standard, not true usability. Usability should reflect user tasks and cognitive processes. The problem here may be due to a lack of education in the topic of usability in software engineering courses. In order to build quality, usable tools to support software design activities, a better understanding about how software engineers work is needed. However, research efforts that involve interviews, observation, videotaping and tool instrumentation can result in large amounts of data that are difficult to analyse. Research into automated assessment of CASE tool users’ activities and automated quality assessment of tool users’ work could provide the knowledge needed to make tools more usable.

5. Cognitive support CASE tools should provide support that complements, rather than inhibits, the creative problem solving processes of the tool user. Some recent research in this area has categorised tools as restrictive, flexible or guiding. In the restrictive case, the tool restricts the user to a particular way of working with the tool. While this enforces a strictly correct model, the approach can cause resentment in users if the tool enforced way of working does not suit the way they work. In the flexible case, the tool allows the user to work in any way they like, but provides no mechanisms for assessing the quality of the work or helping the user to produce a quality model. In the guiding case, however, the tools provide mechanisms that guide the user towards good solutions while allowing them to work in a way that suits their particular approach. Argo/UML [16] is an example of a tool designed to guide designers through their design tasks by continually checking and reporting errors, omissions, and inconsistencies in the design. The tool then reports any problems, but it does not force the designer to make immediate corrections to the design, instead, it allows the user to work on and make corrections or enhancements when they are ready. The hope is that this type of tool can provide the kind of support that users need, without creating the resentment of being forced to work within a particular framework. This work, like a lot of CASE tool research,

75

would benefit from further empirical studies of tool users to test the validity and effectiveness of the cognitive support. 6. Integration and interoperability Software engineering tools collect and store valuable amounts of information of various types including software designs, process management information, and meta-model data. To assist engineers in collaborative development work, these tools need to interoperate and exchange information. Various classification schemes [17], reference models [18], and standards [19–21] have been proposed to tackle the problems of interoperability and data interchange. Among the academic community, the idea of information exchange between tools sounds very attractive. This would enable tools to focus on providing specific functionality rather than trying to fulfil all user needs. Tools could then exchange information and a complete toolset consisting of highly specialised tools could be more easily assembled. Interchange formats for achieving this exist, and the new XMI format [22] seems a promising format for achieving this. In reality, however, there are good commercial reasons as to why vendors will not support such common formats, mainly because, for small vendors, it erodes their market share and encourages customers to look at using other tools. Rational has tried to implement a scheme where smaller companies can use their interchange format to integrate with Rational Rose. They have over 70 vendors registered for this scheme, but few have provided useful tools. This kind of framework causes problems for the user because, instead of dealing with just one company, they have to deal with many companies. This can be especially problematic when users require, for example, maintenance and support for their tools. Often an organization’s approach to tool integration and interoperation is influenced by how the tools are purchased. If tool purchase is a top management decision, then it is more likely that they will buy one integrated suite of tools at a high cost in the interests of (perceived) quality and security. If the purchasing is done bottom-up, often a hodgepodge of non-integrated tools results from many separate purchases. Open-source software encourages data sharing, and is a good way of sharing work. However, large commercial organizations need the support infrastructure provided by vendors, albeit committing to proprietary technologies. An open-source approach is, however, a good way for academics to share ideas and tools. 7. Process modelling Process technologies and process modelling techniques are of fundamental importance to software engineering tool developers. The representation and manipulation of

76

J.P. Gray et al. / Information and Software Technology 42 (2000) 73–77

process concepts pervades all types of software engineering tool. Whether implicitly or explicitly recognised, these concepts are inherent in descriptions of software systems, software development projects, and development methodologies. The graphical representation of process descriptions, the formal manipulations of these descriptions, and issues of complexity and scalability when dealing with real-world software processes, are important and relevant aspects of process technology addressed by tool constructors. 8. Tool architectures Software engineering tools can be quite large and complex pieces of software. As with any large software system, issues of architectural design [23] are an important concern for tool developers. An increasing number of software tools utilise component-based architectures [24] and distributed object programming languages such as Java. Many software engineering tools employ Windows-based user interfaces based on MVC (Model-View-Controller) concepts. The MVC paradigm [25], or architectural framework, is used to separate information presentation from the underlying information model. There are many variants of this MVC paradigm, and the basic MVC architecture can be extended to multiple layers of Model-View-Controller [26]. Such an architecture allows tools to support not just multiple views of one model, but multiple views of multiple models. This kind of multi-layer MVC architecture can be used to support a process modelling tool that provides multiple perspectives of the software process (e.g. from both a manager’s perspective and a tester’s perspective) and then multiple views of each perspective.

11. Summary and conclusions It is interesting to note how quickly new implementation technologies have been adopted by members of the tool building community. Many tool developers report that Java is now their preferred implementation language, and component based development technologies such as JavaBeans [28] are increasingly popular. Software engineering tool constructors often need to address issues of distributed and heterogeneous computing both in their tool development environments and in the execution environment of the built tools. The platform independence afforded by the Java language looks very promising. Interoperability issues, and particularly data interchange, is a concern to virtually all tool developers. Recent developments in interchange technologies and standards such as the OMG MOF [29] and XML [30] standards, and the XMI [21] proposal appear to offer solutions to some of these concerns. XMI is also expected to ease the integration of CORBA, XML, Java, and COM based development environments which are evolving towards similar extensible repository architectures based on standard information models, repository interfaces and interchange formats [21, p. 12].

XMI eases the problem of tool interoperability by providing a flexible and easily parsed information exchange format [21, p. 45]. The alignment of these implementation, integration, and interchange technologies may herald the arrival of more powerful, flexible, and (re)usable constructional techniques for software engineering tool developers.

9. Distribution and configuration With the increasing popularity of distributed systems, there is demand for software engineering tools that support software engineering in a distributed manner, across a wide area, and possibly over heterogeneous networks [27]. There are also more component based software being constructed, such systems often exhibit dynamic features, and the maintenance and change configuration management of these complex systems need tool support [24]. 10. Other areas These are not the only issues of concern to tool constructors. For example, HCI and GUI are important aspects of tool development. The presentation and manipulation of graphical representations of software design and process information is a common theme in many tool development projects. There are also many issues related to persistent storage and repository organisation, such as performance concerns and schema evolution.

References [1] I. Sommerville, Software Engineering, Addison-Wesley, Reading, MA, 1995. [2] A. Fuggetta, A classification of CASE technology, IEEE Computer 26 (12) (1993) 25–38. [3] S. Kelly, K. Smolander, Evolution and issues in metaCASE, Information and Software Technology 38 (4) (1996) 261–266. [4] S. Brinkkemper, Method engineering: engineering of information systems development methods and tools, Information and Software Technology 38 (4) (1996) 275–280. ˚ . Johansson, [5] P. Bergsten, J. Bubenko Jr., R. Dahl, M. Gustafsson, L.-A RAMATIC-A CASE shell for implementation of specific CASE tools, SISU, Gothenburg Tempora T6.1 Report, 1989. [6] J.E. Kottemann, B.R. Konsynski, Dynamic metasystems for information systems development, Presented at Fifth International Conference on Information Systems, 1984. [7] P.G. Sorenson, J.-P. Tremblay, A.J. McAllister, The metaview system for many specification environments, IEEE Software 14 (1988) 30– 38. [8] Toolbuilder, available from Lincoln Software Ltd, Macclesfield, UK. http://www.lincolnsoftware.com. [9] MetaEdit1, available from MetaCASE Consulting, Jyva¨skyla¨, Finland. http://www.metacase.com.

J.P. Gray et al. / Information and Software Technology 42 (2000) 73–77 [10] D. Jaeger, Also available in this Special Issue, Generating tools from graph-based grammmars, Proceedings of CoSET’99 the First International Symposium on Constructing Software Engineering Tools, Los Angeles, USA, 17–18 May 1999. [11] R.I. Ferguson, N.F. Parrington, P. Dunne, C. Hardy, J.M. Archibald, J.B. Thompson, Also available in their Special Issue, MetaMOOSE— an object-oriented framework for the construction of CASE tools, Proceedings of CoSET’99 The First International Symposium on Constructing Software Engineering Tools, Los Angles, USA, 17–18 May 1999. [12] J. Grundy, W. Mugridge, J. Hosking, Also available in this Special Issue, Constructing component-based software engineering environments: issues and experiences, Proceedings of CoSET’99 The First International Symposium on Constructing Software Engineering Tools, Los Angeles, USA, 17–18 May 1999. [13] G. Booch, J. Rambaugh, I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, Reading, MA, 1999. [14] Rational Rose, available from Rational Corporation. http:www.rational.com. [15] I. Jacobson, G. Booch, J. Rumbaugh, The Unified Software Development Process, Addison-Wesley, Reading, MA, 1999. [16] J.E. Robbins, D. Redmiles, Also available in this Special Issue, Cognitive support, UML adherence, and XMI interchange in Argo/ UML, Proceedings of CoSET’99 The First International Symposium on Constructing Software Engineering Tools, Los Angeles, USA, 17– 18 May 1999. [17] I. Thomas, B. Nejmah, Definitions of tool integration for environments, IEEE Software 9 (3) (1992) 29–35. [18] L. Wakeman, J. Jowett, PCTE: the Standard for Open Repositories, Prentice–Hall, Englewood Cliffs, NJ, 1993. [19] Electronic Industries Associates. CDIF: CASE Data Interchange Format Technical Reports, CDIF Technical Committee, Electronic Industries Associates, Engineering Department, 2500 Wilson Blvd, Arlington, VA 22201, USA, 1994.

77

[20] ISO 10303-11. Part 11: EXPRESS Language Reference Manual, 1994. [21] ISO 10303-21. Part 21: Clear Text Encoding of the Exchange Structure, 1994. [22] XML Metadata Interchange (XMI). Object Management Group Document ad/98-10-05, October 1998, Available from http:// www.omg.org/docs/ad98-10-05.pdf. [23] D. Garlan, D.E. Perry, Introduction to the special issue on software architectures, IEEE Transactions on Software Engineering 2 (4) (1995) 269–274. [24] W. Kozaczynski, G. Booch, Component-based software engineering, IEEE Software 15 (5) (1998) 34–36 Special issue on “Working with Components”. [25] Y.P. Shan, An event-driven Model-View-Controller framework for Smalltalk, New Orleans, USA, October 1989, Proceedings of OOPSLA’89, 1989, pp. 347–352. [26] R. Kempkens, P. Roesch, L. Scott, J. Zettel, Also available in this Special Issue, A multi-layer Multi-View architecture for SEEs, Proceedings of CoSET’99 The First International Symposium on Constructing Software Engineering Tools, Los Angeles, USA, 17– 18 May, 1999. [27] G.A. Agha, The emerging tapestry of software engineering, IEEE Concurrency, Parallel, Distributed & Mobile Computing 5 (3) (1997) 2–4 Special Issue on Better Tools for Software Engineering. [28] JavaBeans Specification 1.01. Available from http://java.sun.com/ beans/. [29] Meta Object Facility (MOF) Specification. Object Management Group Document ad/97-08-14, September 1997, Available from http://www.omg.org/docs/ad98-08-14.pdf. [30] Extensible Markup Language (XML). A technical recommendation standard of the World Wide Web Consortium (W3C). Available from http://www.w3.org/TR/REC-xml.