A History Concept for Design Recovery Tools

Transcription

1 A History Concept for Design Recovery ools Jens H. Jahnke Department of Computer Science University of Victoria PO Box 3055, Victoria B.C. Canada V8W3P6 Jörg P. Wadsack Dept. of Mathematics and Computer Science University of Paderborn Warburger Str Paderborn, ermany Albert Zündorf Dept. of Mathematics and Computer Science University of Braunschweig Post box Braunschweig, ermany ABSRAC Many tools have been developed for recoverg the design of legacy software. Interactively voked abstraction operations and re-design transformations play a central role these tools. A limitation of most existg approaches is, however, that they assume a mostly lear transformation process. hey provide little support for iteration, recursion and cremental changes durg the recovery process. Nevertheless, empirical results suggest that real-world abstraction and reengeerg processes are fact highly iterative. A history mechanism that explicitly matas dependencies of all performed transformations can overcome this mismatch. Based on our experience with a specialized implementation of such a mechanism, we present a generalized history concept as an add-on to existg tools that support design recovery. Keywords: Software matenance, design recovery, reengeerg, reverse engeerg, history concept, software transformation. Introduction Over two thirds of today s expenditures formation technology are spent on the matenance of existg software systems. Re-documentation and reengeerg activities account for largest part of this budget. Many reengeerg tools have been developed dustry and academia order to support this task, e.g., [-7]. Such tools provide mechanisms for creatg conceptual abstractions of the analyzed software system. ypically, these abstractions are created semi-automatic, humancentered processes. Interactively voked abstraction and re-design transformations play a central role these tools. However, case studies with dustrial applications have shown that the applicability of current tools for human-centered design recovery is limited [8]. his is because they assume a relatively lear process with little support for process iteration, recursion and cremental changes durg the reengeerg process. he left-hand side of Figure illustrates that reengeers typically loose large parts of the transformations performed manually when process iterations occur, i.e., when new analysis knowledge ab the legacy system becomes available. Unfortunately, such iterations occur frequently real-world abstraction and recovery processes [8]. A history mechanism that explicitly matas dependencies among all performed transformations can tackle this problem. Such a history mechanism provides the tracability necessary for iterative reengeerg processes. he right-hand side of Figure illustrates this idea of an explicit dependency relation among all performed transformations. Let us assume that the black box represents knowledge ab a software artifact that has been updated durg the iteration. hen, the dependency formation stored the proposed history mechanism enables the selective removal of only those transformation operations that (transitively) depend on the changed formation. In [9], we presented a dedicated implementation of such a mechanism our database reverse engeerg environment. Based on our experience with this prototype, we now suggest a generalized history concept as an add-on to various kds of existg design recovery tools. Of course, different tools have different application domas (e.g., object-oriented design, database schema design) but the vast majority of tools have common that they are graph-based, i.e., they store model data abstract syntax graphs (AS). herefore, our approach makes use of the theoretical concept of graphtransformation systems [0] as a suitable abstraction for all of these tools. his theoretical basis allows us to uniformly describe various kds of design recovery processes terms of graph processes []. Furthermore, the tegration of our history mechanism with existg tools is facilitated by the current itiative for adoptg a common graph-based data terchange format [2]. he rest of this paper is structured as follows. In the next section, we give an overview on related work the area of document consistency preservation and history

2 Layer QOCA Resultg abstraction Layer QOCA Work package 3 (2 pers.) Work package 3 (2 pers.) lear (time-based) dependency actual (structural) dependency (History raph) ranformations Iterations Legacy Code model artifact Legacy Code Figure. Iteration support with and with a History Mechanism for matag transformation dependencies management. Section 3 troduces concepts that are fundamental for our approach, namely the concept of a graph and a graph grammar. Based on this defition, Section 4 les the proposed History Management mechanism. An application of this mechanism and its tegration with an existg design tool is presented Section 5. Fally, Section 6 closes with concludg remarks and future research directions. 2. Related work he described research is related to various existg approaches to matag ter-document consistency the software (forward) engeerg process. Perhaps the most proment technology this regard is mechanisms for version and configuration management like e.g., the concurrent versions system (CVS) [3]. In prciple, mechanisms like CVS can be used to create version histories of recovered design documents. However, such version histories do not consider the actual structural dependencies among the transformations performed the abstraction process. Instead, the version history merely reflects a time-oriented view on termediate stages reached the (last iteration of the) recovery process. Consequently, traditional version management systems can only provide limited support for iteration as illustrated on the left-hand side of Figure. Leferg and Schurr suggest a dedicated formalism called riple raph rammars for specifyg structure dependencies among Abstract Syntax raphs (ASs) [4]. his formalism is used the IPSEN project for generatg tegration tools that mata consistency and propagate changes from software design documents to the implementation code and vice versa [5]. Nowadays most commercially available development environments provide (limited) support for propagatg changes between software documents on different levels of abstraction. Unfortunately, very few reverse engeerg tools provide similar support for propagatg changes of the knowledge ab a legacy system to its reverse engeered abstraction. Current reverse engeerg tools assume a similar waterfall-like process that was imposed by forward engeerg tools two decades ago. ypical human-centered reverse engeerg tools (e.g., [, 2, 6, 7]) provide extractor programs for populatg the tool repository. he contents of the repository can then be visualized and transformed with various kds of viewers and editors. With most current tools, these two steps () legacy system analysis and formation extraction, and (2) formation transformation and abstraction cannot be iterated with losg the teractive work performed on abstractg and transformg the formation on the legacy system. One notable exception is the DB-MAIN database reverse engeerg environment developed by the University of Namur, Belgium [8]. DB-MAIN logs the history of all teractions durg teractive abstraction and refactorg sessions order to better support contuous evolution relational databases. his allows the reuse of the operational knowledge accumulated durg the different phases of a reengeerg process. he DB- MAIN history mechanism addresses issues of

3 consistency matenance durg evolution of the persistent data (schemas) durg the life cycle of a database application. Hick et al. have developed different evolution strategies dependg on whether the evolution takes place the physical, logical or conceptual schema. Each performed transformation is recorded precisely and completely to make its version possible. he history has to be monotone and lear, which implies no iteration and no branches. Concurrent work is not supported, i.e., only one person can modify the schema at the same time. he DB-MAIN consistency management strategies depend on the reversibility property of the transformations applied. his property makes it possible that changes can be propagated from one schema level to another. In case that a transformation recorded the history becomes valid, i.e., its precondition fails, the reengeer has to resolve the consistencies manually. In contrast to the History Mechanism proposed this paper, DB-MAIN does not allow the reengeer to get back (and modify) the itial state of the legacy system. he Varlet database-reengeerg environment is another tool that supports iterative analysis and abstraction processes [9]. In this approach, Varlet logs all database schema transformations voked by the user an automated logbook (cludg their pre- and postconditions and terdependencies). Moreover, the itial, low-level representation of the legacy schema remas available for the user. his enables the user to revisit the startg pot of his/her teractive modification at a later pot the reverse engeerg process order to modify existg or add new low-level formation on the legacy system. he new formation might stem from applyg additional extractor programs or from terviews conducted with developers or other human experts. Whenever the itial representation of the legacy system is changed, Varlet uses the logged transformation dependencies to determe which teractive operations are affected by the modifications. he pre-conditions of these transformations are then re-evaluated and only those transformations that fail this test are undone. After this propagation step, the consistency of the extracted formation on the legacy system and its teractively created abstraction has been reestablished. his paper describes a generalization of the Varlet consistency management mechanism as a reusable component to be tegrated with existg transformationbased reverse engeerg tool. Compared to the origal mechanism implemented Varlet, the functionality of the consistency management component described this paper is limited to determg and undog all teractive operations that are affected by a change of the legacy system. his means that the preconditions of operations are not re-evaluated. he rationale behd this limitation is to mimize the requirements on tools that can terface with our component. he re-evaluation of the performed operations would require tools to explicitly disclose all checks (preconditions) performed prior to the execution of each operation. his formation is normally not available. 3. raph ransformation Systems raphs are commonly used by reverse engeerg tools for ternal representation of software artifacts, e.g., [, 2, 6, 7]. Of course, the specific graph models used different tools might comprise variations with respect to their expressiveness. Nevertheless, most graph models have common that they support different node- and edge types, attributes and directed edges. Recently, the reverse engeerg research community has developed a standard graph model (called XL) to promote tool teroperability [2]. Sce the start of this itiative 998, an creasg number of tools have been extended with XL import / export functionality. In the followg, we will use the XL graph model as a basis for presentg our approach. Still, the reader should note that our technique does not depend on usg this particular model. he XL raph Model In the followg, we will use the UML for givg a brief, semi-formal troduction to the XL graph model. We refer to [0] for a complete formalization of attributed graph models. A more -depth discussion of XL can be found [2]. Figure 2 shows a UML specification of the XL graph model. refersdocument 0.. ype raph -directed XLDocument refers_type hasype N Node Default cardalities source of composition source of association 0..n ypedelement AttributedElement -id to 0..N raphelement Edge from Relation Figure 2. XL graph model Lk A graph can be directed or undirected. It contas graph elements form of nodes, edges, and relations. Relations conta a set of lks potg to one graph element each. All graph elements have unique identifiers. 0..n

4 XL also cludes the notion of hypergraphs, i.e., graph elements can themselves conta sub-graphs. Furthermore, XL supports typed graph elements (where the type of a graph element is itself a graph element of a type graph). We omit a more detailed discussion of the XL typg concept sce it is not a required this paper. Note that the actual exchange of XL graph stances is performed a canonical textual format based on XML [2]. raph productions raph transformation systems (or graph grammars) are typically defed as a start graph and a set of graph transformation rules (or graph productions). enerally, graph productions can be defed as a pair of graphs, a set of application conditions, and a set of attribute transfer clauses. he two graphs are called the left-hand side and the right-hand side of the production, respectively. raph elements of the left-hand side might also appear on the right-hand side. raph productions and their application semantics have been formalized based on algebra theory. A complete formalization of these concepts is of the scope of this paper and can be found [0]. he tuitive understandg provided by the followg semi-formal defitions is sufficient for the purpose of this paper. Deftion. raph production A graph production is a tuple r:(p, Q, C, ), where P(r)=P and Q(r)=Q are two graphs over the same sets of node and edge type labels; P(r) is called the left-hand side and Q(r) is called the right-hand side of r. C is a set of application conditions. is a set of attribute transfer clauses. Deftion 2. Application of a graph production A production r:(p,q,c,) is applied to a host graph the followg five steps: choose an occurrence of the left-hand side P. P has an occurrence graph if there is a morphism m:p which preserves source and target and labellg mappgs. check the application conditions C. If they hold the occurrence of P is called a match for P. remove all elements that have been matched to elements P that do not occur Q, addg all elements to that are new Q. he occurrence of Q the modified host graph is called comatch. transferg attribute values to nodes that match nodes Q(r) accordg to the attribute transfer clauses specified. We denote (r,m) for the graph that is produced by the application of a production r to a graph ( a match m). Note that graph productions are typically represented graphically, e.g., usg the notation proposed by Schurr et al. [9]. In the followg, we will discuss the sample graph production shown Figure 3. Operations viewed as graph productions In prciple, any tool for software design recovery can be viewed as specific graph transformation systems, where each modifyg operation offered to the user is represented by a graph production. For example, consider a refactorg operation generalize that creates an abstract super class for a selected class c and generalizes some members of c. Figure 3 shows a representation of this refactorg operation form of a graph production. Production generalize(c:class, a:members [0..n], name: strg); left-hand side 4 :Class c:class 2 contas contas 3 :Member a:member transfer 5.abstract=true; 5.name=name; 4 :Class :Member c:class contas 2 3 right-hand side 5 contas a:member Figure 3. raph production generalize :Class he unique identification number the upper left corner of each node allows identifyg identical nodes on both sides of the production. Node represents the class to be generalized. Node 3 represents the set of members that will move to the new abstract super class (Node 5). Node 2 represents the set of all remag class members. Node 4 considers the case that the class to be generalized might already have a super class 2. In this case, Node 4 will become the super class of the new generalization Note, that both nodes (2 and 3) are determed by the user s selection, parameter a. 2 he dashed border of Node 4 specifies that a match for this node is optional. We adopted this notation from [9]. his notation is merely an abbreviation sce productions with optional graph elements can always be presented by a set of productions with optional graph elements.

5 (Node 5). he transfer clause at the bottom of Figure 3 specifies that the new class is abstract by assigng the true value to the correspondg attribute of Node 5. Creatg Reengeerg Histories with raph Processes he overall goal of our research is the development of mechanisms that facilitate cremental and iterative reverse engeerg processes. racability is the most important prerequisite for such a mechanism, i.e., case of process iterations, we have to be able to trace and propagate modifications of the itial representation of the legacy system to its transformed representation, order to re-establish consistency. he requirement for tracability implies some sort of logbook ab the terdependencies of all operations voked by the user. We will now propose the realization of such a logbook based on the formal concept of graph processes []. Analogously to the treatment of operations as graph productions, we can view operation applications as applications of graph productions. In the previous section, we poted that the application of a graph production could be defed by its match and comatch. More precisely, the application of a production r:(p,q,c,) to a host graph is defed as a tuple of morphisms (m:p, m :Q (r,m) ) where m denotes the match and m denotes the comatch. As an example Figure 5 shows an application of production generalize to the sample host graph Figure 4. he left-hand side of Figure 5 shows the match while the right-hand side shows the comatch. Person:Class source worksfor:reference target mame:member contas operation application (called transformation for short). he bottom part of Figure 6 illustrates this representation for our example Figure 5. 3 generalize(:programmer, {:p_plan}, Employee ); 4 Person:Class programmer:class contas contas 2 3 log:member p_plan:member 4 Person:Class 5 programmer:class Employee:Class contas contas 2 3 log:member p_plan:member Figure 5. Application of production generalize raph Element raph Element ransfor mation raph Element Person: Class programmer: Class log: Member p_plan: Member (general form) generalize (example) raph Element Person: Class programmer: Class log: Member p_plan: Member Employee: Class programmer:class contas contas Company:Class contas Figure 6. raph representation of operation applications log:member pension_plan:member Figure 4. Sample host graph address:member Real-world reverse engeerg processes volve numerous such operation applications voked by the user, which might partly depend on results created by previous operation applications. A history mechanism has to keep track of these operation applications and their terdependencies. Aga, we propose a graph structure for this purpose. he top part of Figure 6 shows the general form of such a graph-based representation of an We call the graph that stores the dependencies among transformations the History raph. Figure 7 illustrates the structure of this graph, where -nodes represent transformations and -nodes represent elements of the Abstract Syntax raph (AS). Each transformation consumes certa AS elements and replaces them by other AS elements. In graph grammar terms, the consumed elements represent the match of the 3 For readability reasons, we only listed graph nodes as put and put of transformation generalize. However, the ternal representation of the History raph matas nodes and edges as put or put of transformations.

6 correspondg graph production, while the produced AS elements represent its comatch. From the above discussion follows that the History raph, which represents a particular software refactorg history, contas the current AS of the refactored SW systems as a subgraph. his subgraph can easily be determed by filterg all graph elements that have not been consumed by transformations, i.e., that are not sourced by an edge that pots to a transformation node (bold -nodes Figure 7). Figure 7. History raph Likewise, the History raph also subsumes all previous states of the AS durg the teractive refactorg process. hus, it is possible to trace back to any past state the editg history. he History raph is a specific implementation of the general concept of a graph process as troduced by Corradi et al. []. Corradi defes a graph process as a partially ordered structure, plus suitable mappgs which relate the elements of this structure to those of a given typed graph grammar. 4. Usg History raphs for consistency management reengeerg tools We have employed the concept of History raphs for consistency management durg iterations design recovery processes. For example, assume that midway durg a reverse engeerg process the reengeer learns ab additional dependencies the legacy system. Ideally, (s)he would like to add this new formation to the itially extracted representation of the legacy system and validate those refactorg transformations which might have to be undone due to the new knowledge. he History raph concept serves exactly this purpose. With its help the user can get back to the itial representation of the legacy system, make all desired changes, and determe which transformations might have lost their validity. In the Varlet project, we developed a prototype reverse engeerg tool that uses History raphs for this purpose [9]. In addition to their put/put dependencies, transformations the Varlet History raph also log their pre- and post-conditions. his enabled us to perform the validation of transformations fully automatically. On the downside, the History raph mechanism built Varlet requires tight tegration with the rest of the tool and cannot be reused other existg tools. herefore, we have developed a lightweight History raph mechanism that can loosely be tegrated with existg reverse engeerg tools. 4. ool tegration prerequisites A tool has to meet certa requirements to be able to terface with our History raph component. We have mimized these requirements as much as possible to enable the tegration with many different environments. Basically, a tool has to be able to. import and export its ternal AS structure (preferably XL format), and 2. for each design recovery transformation on the AS o report the graph elements that represent the put of the transformation 4 o report the graph elements that represent the put of the transformation XL format. An creasg number of current reengeerg tools fulfill Requirement, e.g., Rigi [2]. Others can easily be extended because they are end-user programmable. For example, we have extended UMLStudio 5 our sample application described the next section. Requirement 2 is easy to achieve if Requirement is satisfied because the put and put of a transformation can be represented as two XL graphs (i.e., the match and the comatch accordg to Defition 2). he sequence diagram Figure 8 illustrates a typical teraction scenario between a design recovery tool and the History Management component. Note that the diagram covers a sgle iteration the recovery process only. he process starts with the creation of the start graph by passg it to the XLHistory component, (addraph(s)). hen, a sequence of transformations is performed by the user. hese transformations (t to 4 Includg all graph elements that are checked checks of preconditions of the operation. 5

7 tn) are logged the History raph. his is done by callg function addransformation(l,r,t), where l and r denote - and put of transformation t, respectively. At any pot time, the user can spect the editg history. his is done by vokg the createhistory() operation. As result (s)he obtas the list of the transformation t to tn with the respective time stamps. ool addraph (s) XLHistory operation (s)he gets the current graph ((new)) with the undone transformation. 4.2 History Management algorithm Internally, we use an extended version of the XL graph model for matag the History raph: we have troduced transformation nodes that carry a timestamp and a name attribute (cf. Figure 9). ransformation nodes are created automatically by the History component for each call to addransformation. he timestamp is used to log the time when a transformation has occurred and the name logs the name of the correspondg operation. refers_type addransformation (l, r, t)... addransformation (ln, rn, tn) createhistory () (trafos) getraph (t) (cur) ype hasype 0.. raph refersdocument -directed 0.. XLDocument ypedelement AttributedElement -id from raphelement Edge 0..N 0..n to Node ransformation -name -timestamp Figure 9. raph model for History raphs addchanges (c) propagatechanges () (new) Figure 8. Interaction with History Component When an iteration of the reverse engeerg process is required, the tool restores the start graph by passg the transformation t to the XLHistory component (cf. getraph(t)). Subsequently, the user can perform all necessary additions and/or modifications to the itial representation of the legacy systems and submit the changes to the XLHistory (cf. addchanges(c)). Likewise, the user may restore any other situation by callg getraph (tx) with an termediate transformation tx and by editg that situation. Now the User can use the logged history formation to re-establish consistency through an cremental undo of all transformations that depend on the changes to the start graph (propagatechange()). As result of this he algorithm Figure 0 describes the work performed by our History Management component. At the begng, it receives the start graph from the reengeerg tool. his start graph (S) becomes the itial history graph (H). hen, the History Management component logs all voked transformations the history graph. If process iterations occur the History Management component recovers the itial start graph and sends it to the tool. Le 8 specifies that the start graph can be recovered by takg all graph elements from H that do not represent transformations and do not comprise comg -edges. Once the reengeer has completed the modifications to the itial start graph, it is sent back to the History Management component, which computes the changed graph elements (les 9 and 0). Subsequently, all transformations affected by the changes are determed by transitively traversg - and -edges the History raph. Note that we use regular path expressions to represent graph traversals, as proposed [9]. Fally, all affected transformations are removed from the History raph (Le 2) and the updated tool graph is computed and sent to the tool (les 3 and 4). his is illustrated Figure where the star represents a changed graph element the start graph and the circle

8 marks dependent graph elements that are to be removed from the History raph. In this figure, the bold -nodes represent the updated tool graph that is sent back to the tool. Algorithm History Management Beg. Receive Start raph from tool (addraph(s)) 2. H := S; // S becomes the itial History raph 3. Repeat 4. Repeat 5. Log tool transformation H (addransformation) 6. Until Start raph requested (getraph) 7. Recover Start raph and send it to tool 8. S := {e H type(e) rafo e.(<-out-)= } 9. Receive changed Start raph (addchanges(c)) 0. Receive progagate command (propagatechanges) // determe all affected transformations. Affectedrafos:= c.(-->).(-->&-->)* // undo affected transformations 2. H:= H (Affectedrafos.--> Affectedrafos) 3. Compute updated tool graph and send to tool 4. := {e H type(e) rafo e.(-in->)= } 5. Display Undo Report (Affectedrafos) 6.Loop End. Figure 0. Algorithm History Management patterns has been troduced by amma et al. as a way of communicatg design solutions for frequently recurrg problems [20]. Usg design patterns adds a level of abstraction that facilitates description and understandg of software systems. Recently, researchers have begun to use the notion of patterns the design recovery and documentation of legacy software systems, e.g., [2]. In our study, we have used UMLStudio 6, a commercial UML design tool, for recoverg design patterns from the Abstract Wdow oolkit (AW) 7. We have chosen UMLStudio because it has advanced mechanisms for end-user programmability: UMLStudio provides a scriptg language called PragScript. PragScript is a LISP dialect and facilitates traversal of the entire ternal data structure of the tool. UMLStudio is shipped with a collection of sample scripts and complete onle documentation. It took us approximately four days of work to develop the required XL export/import functionality by customizg these scripts. UMLStudio provides (limited) functionality for reverse engeerg UML class diagrams from Java source code. However, it does not provide automated means for detectg the existence of design patterns. hey have to be detected teractively by addg pattern annotations to the constitutg design elements. For this purpose, we added a pattern annotation function to UMLStudio. he screen shot Figure 2 illustrates this approach for an excerpt of six sample classes of the AW 8. When the reengeer has discovered an stance of a design pattern, (s)he can select its constituents and voke the pattern annotation function. In our screenshot, the reengeer has recovered three stances of design patterns, namely Association, Composite, and Delegation. Some design patterns depend on the existence of others, e.g., the Composite depends on Delegation and Association. We were unable to visualize the direction of such dependencies UMLStudio. Nevertheless, we believe that this does not cause a real problem for users who know the design patterns they are tryg to detect. Figure. Updated and pruned History raph 5. Application example: Design Pattern Recovery he first application of our History Mechanism has been the doma of database design recovery. We reported on this case study a previous paper [9]. Sce then, we have worked on a generalization of our approach to extend existg tools various other domas. In the followg, we describe an application example the doma of design pattern recovery. he notion of design For simplicity reasons, we compressed the diagram by hidg operations and attributes that are not required for the discussion of our example.

9 Figure 2. Design pattern detection with UMLStudio In our theoretical model, we can treat the implemented pattern annotation function as a graph production. If we use our History concept to log transformations necessary for recoverg and annotatg the three design patterns Figure 2, we obta the History raph Figure 3: the first annotation transformation makes the formation explicit that the two references parent and component between Component and Contaer constitute a sgle association. he second transformation annotates the existence of a delegation between the two pat methods both classes. Of course, the recovery of this pattern requires additional knowledge, which dicates that a delegation deed happens between the two operations. One possibility to retrieve this formation is to vestigate the implementation of these operations. Another frequently used heuristic takes equally named operations as an dication for a delegation. his heuristic was used our example Figure 2. Fally, the third design pattern (Composite) is based on the existence of the delegation, an association and an heritance relationship. Let us assume that the reengeer discovered at a later pot that the namg heuristic did not apply this case and the name equality between both operations is just cocident. hen, the Delegation annotation (and all other dependent transformations) have to be undone to avoid consistency. Usg the History component, the reengeer can go back to the itial version of the class model and enter the formation that the knowledge ab the pat operations has changed. hen, the propagation algorithm would automatically undo all dependent operations while the other manual recovery work is consistently preserved. Attr Attr Op Op Attr Attr Assoc Ass oc Op Op Inherit Compos. Delegat. Delegat. Inherit Assoc Figure 3. History raph for design pattern detection 6. Conclusions and future work Mechanisms that allow for iterative and explorative refactorg processes human-centered reengeerg tools are crucial for the usability of these tools. Only few currently existg tools provide such mechanisms [9, 8]. Moreover, these mechanisms are usually tightly tegrated with the rest of the tool and cannot be reused other tool environments. he approach presented this paper is based on our practical experiences with one of these mechanisms [9] and attempts to generalize the volved concepts to make them reusable. he recent

10 movement of the reengeerg community towards toolteroperability based on a common graph exchange format (XL) opens up an opportunity to develop reusable backbone components like the History Manager described this paper. In a previous paper, we have shown that our approach is feasible and scalable [9]. his application was the doma of data reverse engeerg. his paper demonstrates that the History concept can be generalized for other application domas (recovery of objectoriented design patterns) and tegrated with existg reengeerg tools. Our future work will be on improvg the terfacability and usability of our History component. We tend to implement a user terface with a history browser. Acknowledgements he described research has been supported part by the National Science and Research Counsel of Canada (NSERC). Many thanks to Vladislav Krasnyanskiy for his support implementg the current History Management component. References [] Muller, H., S. illey, and K. Wong. Understandg Software Systems usg Reverse Engeerg echnology: Perspectives from the Rigi Project. CASCON ' oronto Ontario, Canada: IBM. [2] Storey, M.A. and H. Muller. Manipulatg and Documentg Software Structures usg SHriMP Views. International Conference Software Matenance. 995: IEEE CS Press. [3] Henrard, J., et al. Program Understandg Database Reverse Engeerg. DEXA' Vienna, Austria. [4] Ebert, J., B. Kullbach, and A. Panse, he Extract- ransform-rewrite Cycle - A Step towards MetaCARE. 997, Fachberichte Informatik, Universität Koblenz-Landau: Koblenz. [5] Cremer, K. A ool Supportg the Re-Design of Legacy Applications. 2nd Euromicro Conference on Software Matenance and Reengeerg. 998: IEEE-CS Press. [6] risworld, W.., et al., ool Support for Planng the Restructurg of Data Abstractions Large Systems. IEEE ransactions on Software Engeerg, (7): p [7] Jahnke, J.H. and A. Zundorf. Usg raph rammars for Buildg the Varlet Database Reverse Engeerg Environment. heory and Application of raph ransformations Paderborn, ermany: University of Paderborn, ermany. [8] Jahnke, J.H. and A. Walenste. Reverse Engeerg ools as Media for Imperfect Knowledge. Workg Conference on Reverse Engeerg (WCRE 2000) Brisbane, Australia: IEEE Computer Society. [9] Jahnke, J.H. and J.P. Wadsack. Integration of analysis and redesign activities formation system reengeerg. 3rd European Conference on Software Matenance and Reengeerg (CSMR'99) Amsterdam, NL: IEEE Computer Society. [0] Rozenberg,., ed. Handbook of raph rammars and Computg by raph ransformation. Vol.. 999, World Scientific. [] Corradi, A., U. Montanari, and F. Rossi, raph processes. Fundamenta Informaticae, IOS Press, (3): p [2] Holt, R., et al. XL: owards a Standard Exchange Format. Workg Conference on Reverse Engeerg (WCRE) Brisbane, Australia: IEEE-CS Press. [3] Simpson, M., CVS Version Control and Branch Management. Dr. Dobb's Journal of Software ools, (25): p. 08,0-4. [4] Leferg, C. and A. Schurr, Specification of Integration ools, Buildg tightly tegrated software development environments - he IPSEN Project, M. Nagl, Editor. 996, Sprger Verlag: Berl. [5] Nagl, M., ed. Buildg tightly tegrated software development environments - he IPSEN Project. LNCS. Vol , Sprger: Berl. [6] Rajala, N., D. Campara, and N. Mansurov. Insight - Reverse Engeer Case ool. Intl. Software Engeerg Conference (ICSE-'99). 999: ACM Press. [7] Kullbach, B., et al. Program Comprehension Multi-Language Systems. Workg Conference on Reverse Engeerg (WCRE) Hawaii, USA: IEEE-CS Press. [8] Hick, J.-M., et al. Strategies pour l'evolution des applications de bases de donnees relationnelles : l'approche DB-MAIN. XVIIe congress INFORSID, La arde, France [9] Schurr, A., A. Wter, and A. Zundorf. raph rammar Engeerg with PRORES. European Software Engeerg Conference (ESEC). 995: Sprger Verlag. [20] amma, E., et al., Design patterns : elements of reusable object-oriented software. Addison-Wesley professional computg series. 995, Readg, Mass.: Addison-Wesley. xv, 395. [2] Keller, R.K., et al., eds. he SPOOL Approach to Pattern-Based Recovery of Design Components. Advances Software Engeerg. opics Evolution, Comprehension, and Evaluation, ed. E. H. and O. anir. 200, Sprger-Verlag.