TAGDUR: A Tool for Producing UML Diagrams Through Reengineering of Legacy Systems Richard Millham, Hongji Yang De Montfort University, England [email protected] & [email protected] Abstract: Introducing TAGDUR, a reengineering tool that first transforms a procedural legacy system into an object-oriented, event-driven system and then models and documents this transformed system through a series of UML diagrams. Keywords: TAGDUR, Reengineering, Program Transformation, UML In this paper, we introduce TAGDUR (Transformation from a sequential-driven, procedural structured to an and Automatic Generation of Documentation in UML event-driven, component-based architecture requires a through Reengineering). TAGDUR is a reengineering tool transformation of the original system to an object-oriented, designed to address the problems frequently found in event-driven system. Object orientation, because it many legacy systems such as lack of documentation and encapsulates methods and their variables into modules, is the need to transform the present structure to a more well-suited to a multi-tiered Web-based architecture modern architecture. TAGDUR first transforms a where pieces of software must be defined in encapsulated procedurally-structured system to an object-oriented, modules with cleanly-defined interfaces. This particular event-driven architecture. Then TAGDUR generates legacy system is procedural-driven and is batch-oriented; documentation of the structure and behavior of this a move to a Web-based architecture requires a real-time, transformed system through a series of UML (Unified event-driven response rather than a procedural invocation. Modeling Language) diagrams. These diagrams include class, deployment, sequence, and activity diagrams. Object orientation promises other advantages as well. Because object orientation has encapsulated modules of This paper gives a brief overview of the problems posed software with cleanly-defined interfaces, software, and by many legacy systems, a description of TAGDUR’s hence their objects, from different systems can be more overall design and workings, and an overview of how easily integrated than if this software was structured into TAGDUR generates two types of its diagrams: class and procedures with global variables. Furthermore, object activity. orientation has lower maintenance costs than procedural software. 1. Overview of Problem Developing systems to address these business needs and During the early days of computing, computer systems replace these legacy systems is prevented by the high cost were designed to fit a particular platform and were of development. One solution is to reengineer the existing designed to address the hardware limitations of that legacy system by transforming the legacy system to an particular platform. As an example, most legacy computer object-oriented, event-driven architecture. Once this platforms were single processor and had severe memory transformation is completed, the transformed system can constraints. As a result, the legacy systems built for these be adapted to meet new business needs such as system systems were designed to operate in a strictly sequential integration. manner and were procedural-driven. However in order to integrate disparate systems, These legacy systems, in many cases, were designed in an developers must fully understand the systems being ad-hoc manner and were designed as stand-alone systems. integrated, whether they have been reengineered or not. As time passed and business needs changed, the need They must not only understand the software structure of became apparent to integrate these disparate systems the system but be able to follow the data and control flow together and remodel them to accommodate a multi-tiered, and the execution of events. Documentation detailing this Web-based platform. This remodeling of legacy systems information for most legacy systems is either missing or out-of-date. Consequently, any reengineering efforts must lack of documentation problem. By utilizing information first have some facility to generate documentation acquired during the transformational process and by regarding the structure and dynamics of this system. parsing the code of the transformed system, this tool generates UML diagrams of the transformed system. Our tool, TAGDUR (Transformation and Automatic Generation of Documentation in UML through Reengineering), was designed to try and overcome this 2. Tool Design COBOL COBOL to Ex: variable data types source code COBOL source code WSL COBOL-specific program information conversion WSL representation of COBOL program WSL-specific program information Database WSL program transformation and analysis Ex: classes, events, messages Generation of UML between classes representation of Results of WSL analysis C++ code Data typing of variables, etc transformed WSL Results of transformation and analysis generation system C++ code UML diagrams C++ program equivalent to UML COBOL representation program Fig. 1: Overview of TAGDUR Tool Design We first convert the COBOL legacy system into unit of work; tasks can be defined at several WSL using a set of COBOL to WSL conversion different levels of granularity such as program, rules. These rules were formulated using Martin procedure, and individual code line. Our task Ward’s [10] paper, The Syntax and Semantics of evaluation technique involves analyzing two the Wide Spectrum Language, which defined the normally sequential tasks for data and control basis of the Wide Spectrum Language. Because dependencies between them; if a dependency WSL is a type less language, programming exists, these tasks are deemed to be sequential; if language-specific information, such as variable no dependency exists, these tasks are deemed to data types of the original legacy system, can not be able to execute in parallel. The final be represented in WSL but are stored in the transformation step is to identify possible events database for future use, such as during the C++ from source code. This event identification step code generation process. is accomplished by constructing a control graph of procedure calls, I/O calls, system interrupts, After the conversion from COBOL to WSL has and error invocations by parsing the source code. finished, TAGDUR transform the original The nodes of this control graph that represent procedural-structured and sequential legacy interaction with other objects are modeled as system to an object-oriented, event-driven events. An example, an interrupt is modeled as system. This transformation occurs using a series an event occurrence between the object where of transformation steps. The first step is to the interrupt occurred and the System object, identify potential classes, including their which handles interrupts. Once the events are attributes and operations through our own identified, each event is evaluated in terms of its clustering technique. This technique groups synchronicity. This evaluation is accomplished highly inter-related procedures and variables into by evaluating, at the individual code line level of classes. [3] The next transformation step is to granularity, the task where the event occurred evaluate tasks, at both the procedure and and the task immediately successive to this task individual code line level of granularity, for their in order to determine if any control or data degree of task independence. This evaluation is dependencies exist among them. If a dependency accomplished using several different algorithms exists, the event is deemed to be synchronous; as outlined in [4]. A task is defined as an atomic otherwise, if no dependency exists, the event is WSL was chosen for an intermediate language deemed to be asynchronous. for several reasons. WSL is programming and platform independent. Consequently, the Once the transformation process is complete, transformations and modelling that TAGDUR TAGDUR generates documentation of the performs on a WSL-represented system could be transformed system by representing it through a performed regardless of whether the original series of UML diagrams. These UML diagrams legacy system was in COBOL or C. The original are represented in UXF textual format. A legacy systems need only to be converted into developer can import these UML diagrams into a WSL first. UXF-compatible graphical tool for viewing. UXF (UML eXchange Format) is a XML-based WSL has other advantages as well. WSL has model interchange for UML models developed excellent tool support, in the FermaT by Junichi Suzuki and Yoshikazu Yamamoto. [7] transformation system [9] which allows transformations and code simplification to be After the transformation process completes, the carried out automatically. It has the capability of WSL intermediate representation is restructured enabling proof-of-correctness testing. WSL is into classes. Each procedure associated with a programming and platform independent. WSL class is modeled as an operation of the class, was also specifically designed to be easy to each variable associated with a class is modelled analyse and transform. as an attribute of the class. In this legacy system, finding system artefacts to The information that was obtained during the use as a basis for modelling UML diagrams of transformation process is utilized during the the system is difficult. Any documentation of the automatic generation of documentation through system often does not exist. The original UML diagrams. An example, classes identified developers and end-users, who would be most during