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 the class identification process form the knowledgeable about the design of the system, basis of the UML class diagram. Events have long since left the organization. Often these identified during the event identification systems have been left in light maintenance transformation process are modeled as events in mode for many years; consequently, current the UML activity diagram. The identification of maintainers and end-users have a minimal independent tasks during the determination of knowledge of the system. Because the source independent tasks transformation step is utilized code, along with the associated data files, are the when modeling parallel or sequential control only available system artefacts, any UML flows in UML activity diagrams. diagrams that are generated to model this system must be based primarily on source code. 2.1 Rationale Behind Tool Design Decisions 2.3 Advantages of TAGDUR UML diagrams were selected as the method to document the transformed system for several Some existing tools, such as RIGI, are capable of reasons. UML provides documentation of the transforming a system and then generating visual system from multiple perspectives; UML documentation of the static structure of this provides use-case diagrams, which address the system. RIGI was developed by Hausi Muller modeling needs of end-users, but also provides and his team at the University of Victoria, statecharts and class diagrams, which are most Canada. While RIGI documents the static view useful to developers. The diagrams that form of the system, it does not have a corresponding UML, diagrams such as statecharts, have been capability of documenting the dynamic view of used by the software community for years to the system. [6] model and to understand software systems. UML is an accepted worldwide standard with Other existing tools, such as Argo UML, provide significant tool support. Furthermore, UML is a dynamic view of the system through UML independent of any programming language and sequence diagrams. Sequence diagrams are platform. Although use case diagram generation useful in depicting the messages passed between is not a current feature of TAGDUR, TAGDUR interacting objects; however, sequence diagrams embraces class and activity, which are similar to do not properly model the internal control logic statechart, diagrams in its UML modeling. and data manipulation within objects. Activity diagrams, on the other hand, can model the internal activities, control logic, and data modules, in this case COBOL copybooks, manipulation of objects. Consequently, our tool according to some logical criteria. This logical generates activity diagrams in addition to modularization of the system is preserved in the sequence diagrams. form of packages in UML diagrams.

TAGDUR, our tool, has additional features as Our tool models accesses between classes of well. The tool has the capability of generating other’s attributes or methods as static code for a C++ equivalent program of the associations between classes. Each end of an transformed system. Future additions to this tool association contains a multiplicity; the will include the ability to data reengineer the multiplicity of an association end is the number underlying databases or file systems of the of possible instances of the class associated with system. Another future addition will be the a single instance of the other end. Depending on ability to generate test scripts and cases from the ratio of classes accessing the activity diagrams; these test cases provide a attributes/method to the classes accessed, the means of regression testing the various iterations multiplicity of these association ends may be of the transformed system as it is being modeled as many-to-one, one-to-one, etc. [5] An redeveloped in order to integrate this system example, if Class A accesses multiple methods with other related systems. and attributes of Class B, this association end would be modeled as many-to-one. If Class A 3. Generation of UML Diagrams access only one attribute of Class B, then this association end would be modeled as one-to-one TAGDUR generates several types of UML multiplicity. diagrams of the transformed system, including class, sequence, deployment, and activity The information gained during the diagrams. This paper focuses on the generation transformation process of this system is used in of class and activity diagrams, representing the modelling these multiplicities. During the object static and dynamic views of the system identification process, TAGDUR constructs two respectively. This paper indicates how matrices: one matrix is a procedural usage grid TAGDUR utilizes information gained during the which records the number of times procedure A transformation process to generate class and is called by procedure B and the other matrix is a activity diagrams. variable usage grid which records the number of times variable A is accessed within procedure B. 3.1 Class Diagrams These matrixes are used during the object identification process where highly coupled Class diagrams represent the static structure of procedures and variables are grouped into classes. the system. Class diagrams convey information These matrices are also used when modeling about classes used in the system such as their UML diagrams. Variables or procedures that properties, their interfaces, and how these classes form attributes/operations of one class, class A, interact with one another. [2] Associations are but are accessed by procedures that form relationships between two classes. operations of another class, class B, are modelled as an association between classes A and B. These After our reverse engineering process transforms two usage matrices are used when modeled the the legacy system from its procedural structure multiplicity of these associations. Using both to that of an object-oriented one, our tool procedural and variable usage matrices, the extracts the class diagram from the transformed number of times that all variables and procedures system. Class definitions from the system are of object A are accessed by procedures of object modeled as classes in the UML class diagram; B form the type of multiplicity relationship variables encapsulated within a class become between classes A and B. An example, if the class attributes and procedures associated with a procedures of object B access the variables and class become methods in the UML class diagram. procedures of object A ten times, the association between object A and B is modeled as an Classes in this system are grouped into UML association of 1:n multiplicity. packages. A package, in this legacy system example, corresponds to the original COBOL 3.2 Activity Diagrams copybook. The assumption is that the original programmers divided up the system into Activity diagrams describe the internal behaviour One might question why TAGDUR chooses to of a class method as a sequence of steps. These generate activity diagrams from WSL code sequence of steps model the dynamic, or rather than simply allow the developers to view behavioural, view of a system in contrast to class the WSL or generated C++ code of the diagrams, which model the static, or structural, transformed system. Activity diagrams were view of the system. chosen for many reasons. UML is widely understood by many developers while WSL and, An activity in UML represents a step in the to a much lesser extent, C++ has less of a execution of a business process. Activities are universal understanding. Furthermore, activity linked by connections, called transitions, which diagrams clearly represent the interaction among connect an activity to its next activity. The objects and the occurrences of events among transitions between activities may be guarded by activities; this representation would be much less mutually exclusive Boolean conditions. These apparent than if the developer were simply conditions determine which control flow(s) and perusing the code of the transformed system. activities are selected. [5] Although our activity diagram is based on WSL code and individual WSL code lines are used to Activity diagrams may contain action states. distinguish action states in the activity diagram, Action states are states that model atomic actions this lack of understanding is mitigated by or operations. Activity diagrams may also attached comments which describe the WSL contain events. [1] code line being modeled. An example, a file I/O event is described in terms of its type (File I/O), Activity diagrams can be partitioned into object sub-type (Read), and destination, source, and swimlanes that determine where an activity is index variables. The decision to base our activity placed in the swimlane of the object where the diagram on WSL, rather than C++, was due to activity occurs. [1] several reasons, including the fact that WSL is programming and platform independent. An Tasks that have been determined to be able to example, a file I/O operation is represented execute in parallel by the independent task through one type of WSL statement while evaluation step of the transformation process are representing the same operation in C++ may take modelled as parallel activities and flows in the several C++ statements depending on the type of activity diagram while tasks that have been file being accessed. Consequently, many determined to be able to execute sequentially implementation-specific details that would only are modeled as sequential activities and clutter an activity diagram based on C++ code flows. In activity diagrams, synchronization bars are avoided if this same activity diagram is based are used to synchronise the divergence of on WSL code instead. sequential activities into parallel tasks or the merging of parallel tasks to a sequential task. A small sample of WSL code is presented with a These enable the control flow to transition to corresponding UML activity diagram based on several parallel activities simultaneously and to this code. ensure that all parallel tasks complete before proceeding to execute the next sequential task. [5] Fig 2 : WSL Code Sample: Our activity diagrams are code-based. Each X : = Y + 1 activity represents an atomic WSL statement. If X > 4 Then Because the WSL code lines of a procedure form Fetch D1, Y2, Z2 steps in the execution of this procedure and Else because individual WSL code lines form an Call B.UpdateRec(X) atomic unit of execution, basing activities on Fi individual WSL code lines is a logical basis for J := D1 + X the nodes of an activity diagram. Conditions M := N + 2 /* potentially parallel within WSL control constructs, such as WSL’s operation */ if-then statements, form conditions within the K := 3 /* potentially parallel guards that govern the flow of control to operation */ activities enclosed by the condition blocks of this WSL control construct. The following diagram models the following WSL code sample as action states in an activity diagram. Each action state is labeled by the WSL construct is modeled in the activity diagram as a statement whose entry action the state represents. branch, with mutually exclusive guard conditions, Each action state is placed in the object to two action states. Using these guard swimlane whose object produces the action. An conditions, the control flow in the activity example, the invocation of Class B’s UpdateRec diagram is governed in a similar manner to the method is represented as an action state in the system that it represents. Potentially parallel Object B swimlane. Potential parallel operations, executing WSL code lines are modeled as such as “M := N + 2” and “K:= 3”, are modeled parallel control flows in the activity diagram. as parallel flows emanating from a fork synchronization bar. An if-then-else WSL

ObjectA ObjectB ObjectFile

Event: File I/O Sub-Type: [X > 4] X := Y + 1 Read [Not (X > 4) ] Destination Variable: D1 Event: Method Source Invokation Variable: Procedure: Y2 UpdateRec Index J := D1 + X Parameter(s): X Variable: SourceCode: Z2 UpdateRec(X) SourceCod e: Fetch D1, Y2, Z2

M := N + 2 K := 3

Fig. 3 : Activity Diagram Representation of the WSL Code Sample

4. Conclusion to meet new business needs such as system integration. TAGDUR is a reengineering tool designed to overcome two of the most daring problems of References legacy systems; obsolete architecture and lack of documentation. TAGDUR addresses these two 1) Alhir, Sinan Si UML in a Nutshell problems by first transforming the original O’Reilly:Sebastapol, CA, USA, 1998 procedural legacy architecture to an object 2) Bjorklund, Dag “The SMDL Statechart Description oriented one and then TAGDUR models and Language: Design, Semantics, and documents this transformed system through a Implementation” Diploma Thesis, Abo Akademi series of UML diagrams. University, Finland, 2001

Once the transformation process completes, 3) Millham, Richard “An Investigation: Reengineering Sequential Procedure-Driven Software into Object-Oriented Event-Driven TAGDUR generates a representation of this Software through UML Diagrams”. Published in the Proceedings of transformed system as a C++ program. With the International Computer Software and Applications Conference, documentation of this system being provided by Oxford, 2002 TAGDUR as UML diagrams, developers can fully understand the system. With this 4) Millham, Richard “Determining Granularity of Independent Tasks for understanding, developers can adapt this Reengineering a Legacy System into an OO System” To be published transformed system, now available as a C++ in the Proceedings of the International Computer Software and program automatically generated by TAGDUR, Applications Conference, Dallas, Texas, 2003

5)Muller, Pierre-Alain Instant UML Wrox: 8) Ward, M., “The Syntax and Semantics of the Wide Birmingham, UK, 2000 Spectrum Language”, Technical Report, Durham University, England, 1992. 6) Storey, Margaret-Anne D., Hausi A. Müller, Kenny Wong “Manipulating And Documenting 9) Ward, Martin “Specifications from Source Code -- Software Structures “ Proceedings of the 1995 Alchemists' Dream or Practical Reality?” 4th International Conference on Software Reengineering Forum, September 19-21, 1994, Maintenance (ICSM '95) (Nice, France, October Victoria, Canada 16-20, 1995)

7) Suzuki, Junichi and Yoshikazu Yamamoto “Making UML models interoperable with UXF”. Lecture Notes in Computer Science 1618, Springer-Verlag, Heidelberg, Germany