An Extensible Language-Independent Environment for Reengineering Object-Oriented Systems
Total Page:16
File Type:pdf, Size:1020Kb
MOOSE: an Extensible Language-Independent Environment for Reengineering Object-Oriented Systems St´ephane Ducasse, Michele Lanza, Sander Tichelaar Software Composition Group, University of Berne Neubr¨uckstrasse 12, CH – 3012 Berne, Switzerland g fducasse,lanza,tichel @iam.unibe.ch — http://www.iam.unibe.ch/ scg / Submitted to COSET’2000 (International Symposium on Constructing Software Engineering Tools) Abstract ¯ It supports reengineering of applications developed in different object-oriented languages, as its core model Surprising as it may seem, many of the early adopters is language independent which, if needed, can be cus- of the object-oriented paradigm already face a number tomized to incorporate language specific features. of problems typically encountered in large-scale legacy systems. The reengineering of those systems often poses problems because of the considerable size and complexity ¯ It is extensible. New entities like measurements or of such systems. In the context of the FAMOOS project we special-purpose relationships can be added to the en- have developed a language independent environment called vironment. Moose which can deal with that complexity. This paper describes the architecture of Moose, the tools which have ¯ It supports reengineering by providing facilities for an- been developed around it and the industrial experiences we alyzing and storing multiple models, for refactoring have obtained. and by providing support for analysis methods such as metrics and the inference of properties of source code Keywords: Reengineering, Reverse Engineering, Refac- entities. toring, Software Metrics, Object-Oriented Programming ¯ Its implementation being fully object-oriented, 1 Introduction MOOSE provides a complete description of the meta-model entities in terms of objects that are easily parameterized and/or extended. Legacy systems are not limited to the procedural paradigm or languages such as COBOL. Although the object-oriented paradigm promised increased flexibility of These properties make MOOSE an ideal foundation for systems and the ease in their evolution, even these systems reengineering tools [3]. get hard to maintain over time and need to be adapted to The outline of this paper is the following: Before pre- new requirements. The goal of the FAMOOS Esprit project senting the specific aspects of MOOSE, we list the main was to support the evolution of such object-oriented legacy characteristics that we expect from a reengineering environ- systems towards frameworks [4]. ment. After presenting the architecture of MOOSE,wegive During the FAMOOS project we built a tool environ- an overview of its underlying meta-model and interchange ment called MOOSE to reverse engineer and reengineer format. We present how a modelled system can be navi- object-oriented systems. It consists of a repository to store gated and queried. Then we show how MOOSE supports models of software systems, and provides query and naviga- code refactorings. To give a more dynamic perception of tion facilities. Models consist of entities representing soft- MOOSE we show a typical use in the form of a short sce- ware artifacts such as classes, methods, etc. MOOSE has the nario. Finally we evaluate the environment regarding the following characteristics: requirements we previously listed and conclude. 1 2 Requirements for a Reengineering Envi- Tools Tools Level ronment Navigation and Querying Engine Refactoring Engine Based on our experiences and on the requirements re- CORE ported in the literature [10, 6, 7], these are our main require- MOOSE ments for a reengineering environment: Entities Operators Extensible. An environment for reverse engineering and Models reengineering should be extensible in many aspects: CDIF Interface Interface Level ¯ The meta-model should be able to represent and manipulate entities other than the ones directly SmalltalkC++ Java Other Source Code Level extracted from the source code (e.g. measure- ments, associations, relationships, etc.). Figure 1. Architecture of Moose. ¯ To support reengineering in the context of soft- ware evolution the environment should be able be possible to handle a legacy system of any size with- to handle several source code models simultane- out incurring long latency times. ously. In addition to these general requirements, the context of ¯ It should be able to use and combine information our work [4] forces us to have an environment that is able from various sources, for instance the inclusion to support multiple languages. of tool-specific information such as run-time in- formation, metric information, graph layout in- formation, etc. 3 Architecture ¯ The environment should be able to operate with MOOSE uses a layered architecture (see Figure 1). Infor- external tools like graph drawing tools, diagram- mation is transformed from source code into a source code mers (e.g. Rational Rose) and parsers. model. The models are based on the FAMIX meta-model Exploratory. The exploratory nature of reverse engineer- which is described in section 4. The information in this ing and reengineering demands that a reengineering model, in the form of entities representing the software arti- environment does not impose rigid sequences of ac- facts of the target system, can be analyzed, manipulated and tivities. The environment should be able to present the used to trigger code transformations by means of refactor- source code entities in many views, both textual and ings. We will describe the architecture of MOOSE starting graphical, in little time. It should be possible to per- from the bottom. form several types of actions on the views the tools ¯ Extraction/Import. MOOSE supports multiple lan- provide such as zooming, switching between different guages. Source code can be imported into the meta- abstraction levels, deleting entities from views, group- model in two different ways: ing entities into logical clusters, etc. The environment should as well provide a way to easily access and query 1. In the case of VisualWorks Smalltalk – the the entities contained in a model. To minimize the dis- language in which MOOSE is implemented – tance between the representation of an entity and the sources can be directly extracted via the meta- actual entity in the source code, an environment should model of the Smalltalk language. provide every entity with a direct linkage to its source 2. For other source languages MOOSE provides code. A secondary requirement in this context is the an import interface for CDIF files based on possibility to maintain a history of all steps performed our FAMIX meta-model. CDIF is an industry- by the reengineer and preferably allow him to return to standard interchange format which enables ex- earlier states in the reengineering process. changing models via files or streams. Over this interface MOOSE uses external parsers for source Scalable. As legacy systems tend to be huge, an environ- languages other than Smalltalk. Currently C++, ment should be scalable in terms of the number of en- JAVA,ADA and other Smalltalk dialects are sup- tities being represented, i.e. at any level of granularity ported. the environment should provide meaningful informa- tion. An additional requirement in this context is the ¯ Storage and Tools. Themodelsarestoredinmem- actual performance of such an environment. It should ory. Every model contains entities representing the 2 software artifacts of the target system. Every entity is analysing the different languages and exchanging informa- represented by an object, which allows direct interac- tion with each other via FAMIX, possibly extended with tion and querying of entities, and consequently an easy language and tool plug-ins. way to query and navigate a whole model. MOOSE can maintain and access several models in memory at the same time. Additionally the core of MOOSE contains the follow- ing functionality: – Operators. Operators can be run on a model to compute additional information regarding the software entities. For example, metrics can be computed and associated with the software enti- ties, or entities can be annotated with additional information such as inferred type information, Figure 2. Concept of the FAMIX model. analysis of the polymorphic calls, etc. Basically any kind of information can be added to an entity. Information exchange with CDIF – Navigation facilities. On top of the MOOSE core we have included querying and navigation sup- To exchange FAMIX-based information between different port. This support is discussed in section 5. tools we have adopted CDIF [2] . CDIF is an industrial stan- – Refactoring Engine. The MOOSE REFAC- dard for transferring models created with different tools. TORING ENGINE defines language-independent The main reasons for adopting CDIF are, that firstly it is refactorings. The analysis for a code refactoring an industry standard, and secondly it has a standard plain is based on model information. The code manip- text encoding which tackles the requirements of convenient ulation which a refactoring entails, is being han- querying and human readability. Next to that the CDIF dled by language-specific front-ends. Section 6 framework supports the extensibility we need to define our describes the engine in more detail. model and plug-ins. As shown in Figure 1 we use CDIF to import FAMIX-based information about systems written in JAVA, C++ and other languages. The information is pro- ¯ Tools Layer. The functionality which is provided by duced by external parsers such as SNiFF+ [13, 14]. Next MOOSE can be used by