In Software Reengineering, one of the central artifacts is the source code of
the legacy system in question. In fact, in most cases it is the only definitive
artifact, because over the time the code has diverged from the original
architecture and design documents. The first task of any reengineering project
is to gather an understanding of the system's architecture. Therefore, a common
approach is to use parsers to translate the source code into a model conforming
to the abstract syntax of the programming language the system is implemented in
which can then be subject to querying. Despite querying, transformations can be
used to generate more abstract views on the system's architecture. This
transformation case deals with the creation of a state machine model out of a
Java syntax graph. It is derived from a task that originates from a real
reengineering project.Comment: In Proceedings TTC 2011, arXiv:1111.440

Erich Gamma

Florian Heidenreich

Louis Rose

Pieter Van Gorp

Steffen Mazanek

Tassilo Horn

Electronic Proceedings in Theoretical Computer Science

English

arXiv

Crossref

Program Understanding: A Reengineering Case for the Transformation Tool Contest

In Software Reengineering, one of the central artifacts is the source code of the legacy system in question. In fact, in most cases it is the only definitive artifact, because over the time the code has diverged from the original architecture and design documents. The first task of any reengineering project is to gather an understanding of the system's architecture. Therefore, a common approach is to use parsers to translate the source code into a model conforming to the abstract syntax of the programming language the system is implemented in which can then be subject to querying. Despite querying, transformations can be used to generate more abstract views on the system's architecture. This transformation case deals with the creation of a state machine model out of a Java syntax graph. It is derived from a task that originates from a real reengineering project

Directory of Open Access Journals

Van Gorp, Mazanek and Rose (Eds.):Fifth Transformation Tool Contest (TTC 2011)EPTCS 74, 2011, pp. 17–21, doi:10.4204/EPTCS.74.3Program Understanding: A Reengineering Case for theTransformation Tool ContestDipl.-Inform. Tassilo Hornhorn@uni-koblenz.deInstitute for Software TechnologyUniversity Koblenz-Landau, Campus KoblenzIn Software Reengineering, one of the central artifacts is the source code of the legacy system inquestion. In fact, in most cases it is the only definitive artifact, because over the time the code hasdiverged from the original architecture and design documents. The first task of any reengineeringproject is to gather an understanding of the system’s architecture. Therefore, a common approachis to use parsers to translate the source code into a model conforming to the abstract syntax of theprogramming language the system is implemented in which can then be subject to querying. Despitequerying, transformations can be used to generate more abstract views on the system’s architecture.This transformation case deals with the creation of a state machine model out of a Java syntaxgraph. It is derived from a task that originates from a real reengineering project.1 Objective and ContextThe objective of the reengineering case presented here is to transform an abstract Java syntax graph intoa simple state machine. There are two major challenges involved. The first challenge is an issue ofperformance and scalability, because the input models are naturally large.The second and more important challenge is that the transformation task involves complex, non-localmatching of elements. For example, the core task, demands that the transformation should create onestate for each Java class that derives directly or indirectly from an abstract Java class named “State.”There are no restrictions on the depth of the inheritance hierarchy, so the “State” class and its subclassesmay be located arbitrarily far in the input model. However, the structure of the path from subclass tosuperclass is clearly specified by the input metamodel and must be utilized by transformations.The SOAMIG1 project dealt with the migration of legacy systems to Service-Oriented Architecturesby means of model-driven techniques. One legacy system on which the approach has been evaluated isa monolithic Java system, which is operated with a graphical user interface. This user interface consistsof around 30 different masks, which often relate to conceptually self-contained functionalities that mightbe implemented as services in the reengineered target system. The order in which masks are activatedand which successor masks can be activated from a given mask gives good hints about the orchestrationof the target system services.The masks are implemented as plain Java classes using the Swing toolkit. Many masks are verycomplex with many user interface elements and even more input validation code, which complicatestracking down the relationships between the individual masks. However, the user interface is based on astate machine concept and uses strict coding conventions in the implementation. As such, any masks canbe seen as states, and when another mask is activated, it can be seen as a transition. The trigger of this1http://www.soamig.de18 Program Understanding: A Reengineering Case for the Transformation Tool Contesttransition is usually a click on some button, and possibly additional actions are performed just before thetransition, e.g., validating user input.A GReTL [4] transformation has been developed which creates a simple state machine model con-sisting of states and transitions with triggers and actions out of the syntax graph of the legacy systemconsisting of more than 2.5 million nodes and edges. The transformation exploits the coding conven-tions taken as a basis for the implementation of the graphical user interface. The resulting state machinemodel contains all information about the possible sequences in which masks can be activated, whattriggers are responsible for a transition, and what additional actions are performed when transitioning.However, it consists of less than 100 nodes and edges, it can be visualized and printed. Therefore, it isof great value for the understanding of the legacy system.The transformation case proposed here is derived form this reengineering project’s task. Insteadof using the syntax graph of the proprietary system, a toy example implementing the well-known TCPprotocol state machine using very similar coding conventions is used. The next section describes thetasks including the relevant metamodels and models. The evaluation criteria used to judge the solutionsare discussed in Section 3.2 Detailed Task DescriptionIn this section, the transformation task is explained in details. The overall goal of this task is to create avery simple state machine model for a Java syntax graph model encoding a state machine with a set ofcoding conventions a transformation has to exploit.The task is divided into one mandatory core task and two optional extension tasks with slightlyincreased complexity. The conventions used to implement the state machine in Java that should beexploited by transformations are explained in terms of concrete Java syntax, i.e., by using source codeexamples. However, the most relevant metamodel elements are named, too. In the following, sourcemetamodel elements are written underlined (e.g., MethodCall), and target metamodel elements arewritten with a typewriter font (e.g., Transition).Source Metamodel and Models. The primary source model of the transformation is a Java abstractsyntax graph conforming to the JaMoPP Ecore metamodel [2, 3]. The input model contains any infor-mation present in the source code. It consists of about 6,500 elements. A second input model is slightlylarger and more complex, e.g., the specialization hierarchy is deeper and so is the nesting of statementsin method bodies. Lastly, a third industry-size input model is provided, which was generated by parsingthe source code of a Java project containing about 900 classes and 220,000 lines of code resulting in amodel constisting of nearly one million elements.All provided input models implement the TCP state machine according to the conventions specifiedin the task description below, so the target state machine model is always the same (not accounting forthe order of elements).Target Metamodel. As target metamodel, the very basic state machine metamodel shown in Fig-ure 1 is used. A StateMachine consists of an arbitrary number of States and Transitions. AnyTransition starts at exactly one src-State, and it ends at exactly one dst-State. Every State hasa name, and any Transition may be caused by a trigger, and as a result of its activation an actionmight be performed.Tassilo Horn 19Figure 1: The target Ecore metamodelCore Task. The core task should create a state machine model that contains all entities, i.e., all Statesand all Transitions with the appropriate references set. Additionally, the name attribute defined forthe State class must be set. The initialization of the trigger and action attributes are left for theextension tasks.Below, the coding conventions used to implement the TCP state machine in plain-java are discussedin terms of concrete Java syntax and by using the SynSent class contained in the src directory, which isshown in Listing 1.1 pub l i c c l a s s SynSent extends L i s t e n i n g S t a t e {2 p r i v a t e s t a t i c Sta t e i n s t a n c e = new SynSent ( ) ;3 pub l i c s t a t i c Sta t e I n s t a n c e ( ) { re tu rn i n s t a n c e ; }4 pub l i c vo id c l o s e ( ) { Closed . I n s t a n c e ( ) . a c t i v a t e ( ) ; }5 protected vo id run ( ) {6 switch ( g e tRe c e i v e dF l a g ( ) ) {7 case SYN: send ( F lag . SYN ACK ) ;8 SynRece ived . I n s t a n c e ( ) . a c t i v a t e ( ) ;9 re tu rn ;10 case SYN ACK : send ( F lag .ACK) ;11 E s t a b l i s h e d . I n s t a n c e ( ) . a c t i v a t e ( ) ;12 re tu rn ;13 } } }Listing 1: The SynSent classThe coding conventions relevant for the core task are as follows:1. A State is a non-abstract Java class (classifiers.Class) that extends the abstract class named“State” directly or indirectly. All concrete state classes are implemented as singletons [1]. InListing 1, SynSent extends the abstract ListeningState state class, and that in turn extends theabstract State class.2. A Transition is encoded by a method call (references.MethodCall), which invokes the nextstate’s Instance () method (members.Method) returning the singleton instance of that state onwhich the activate () method is called in turn. This activation may be contained in any of theclasses’ methods with an arbitrary deep nesting. It may be assumed that a transition always hasthe form NewState.Instance(). activate (). In the example, there are three transitions. In theclose () method, there is one transition from the current state (SynSent) into the Closed state (line7). In the run() method, there are another two transitions. In line 11, there is a transition into theSynReceived state, and in line 14, there is a transition into the Established state.The target model state names should be set according to the Java classes they were created for. Theoutcome of the core task is a state machine with 11 states and 21 transitions between the states.20 Program Understanding: A Reengineering Case for the Transformation Tool ContestExtension 1: Triggers. This extension task deals with the trigger attribute of transitions. There arethree different coding conventions that a transformation has to exploit to set the correct trigger value.These three conventions and one fallback rule are specified as follows.1. If the transition occurs in any method except run(), then that method’s name (members.Method.name)shall be used as the trigger. For example, the activation of Closed in line 7 of Listing 1 occurs inthe close () method, so the trigger is close .2. If the transition occurs inside a non-default case block (statements.NormalSwitchCase) ofa switch statement (statements.Switch) in the run() method, then the enumeration constant(members.EnumConstant) used as condition of the corresponding case is the trigger. For exam-ple, when activating SynReceived in line 11 of Listing 1, the trigger is SYN.3. If the transition occurs inside a catch block (statements.CatchBlock) inside the run() method,then the trigger is the name of the caught exception’s class.4. If none of the three cases above apply, i.e., the activation call is inside the run() method but withouta surrounding switch or catch, the corresponding transition is triggered unconditionally. In thatcase, the trigger attribute shall be set to −−.Transformations may assume that the four different cases can be matched without ambiguity, e.g., thereis no catch block activating some state inside a surrounding switch, or vice versa.Extension 2: Actions. The task of the second extension is to set the action attributes of transitions.The action of a transition is specified as follows.1. If the block (statements.StatementListContainer) containing the transition to the next statecontains a method call to the send() method, then that call’s enumeration constant parameter’sname is the action. For example, the action attribute of the transition in line 11 of Listing 1 has tobe set to SYN ACK.2. If there is no call to send() in the activation call’s block, the action of the corresponding transitionshall be set to −−. For example, the transition in line 7 of Listing 1 performs no action, and thusthe action has to be set to −−.A visualization of the target state machine produced by the reference solution is shown in Figure 2.3 Evaluation CriteriaAs motivated in Section 1, the goal of this transformation case is supporting program understanding.By facilitating a set of coding conventions, model transformations can be used to accomplish the taskof extracting the implicitly encoded state machine, in contrast to modeling it manually by thoroughlyinspecting all relevant classes of the system in question. In order to have a feasible solution, the timeneeded for writing and executing the transformation must be comparable to the time that would be neededfor a code inspection and manually modelling the state machine. However, if we assume that the setof coding conventions derived from the initial brief inspection is correct, it can be assumed that thetransformation produces a correct output without human mistakes.Since the speed of writing a solution cannot be judged directly, understandability and concisenessare used as objectively ascertainable measures relating to the implementation effort, weighted with 30%.Ideally, each coding convention described in Section 2 results in a transformation rule in which thestatement of the convention is clearly visible.The correctness of the solution is also important. If the model created by the transformation isthe foundation of weighty decisions, it would be fatal if it didn’t reflect the reality. The completenessTassilo Horn 21v1 Statename = "Closed"v4 Statename = "SynSent"e2 : Transitionaction = "SYN"trigger = "connect"v5 Statename = "Listen"e1 : Transitionaction = "--"trigger = "listen"v2 Statename = "TimeWait"e18 : Transitionaction = "--"trigger = "TimeoutException"v3 Statename = "CloseWait"v10 Statename = "LastAck"e3 : Transitionaction = "FIN"trigger = "close"e15 : Transitionaction = "--"trigger = "close"v6 Statename = "Established"e17 : Transitionaction = "ACK"trigger = "SYN_ACK"v9 Statename = "SynReceived"e16 : Transitionaction = "SYN_ACK"trigger = "SYN"e10 : Transitionaction = "--"trigger = "close"e11 : Transitionaction = "SYN"trigger = "send"e12 : Transitionaction = "SYN_ACK"trigger = "SYN"e9 : Transitionaction = "ACK"trigger = "FIN"v7 Statename = "FinWait1"e8 : Transitionaction = "FIN"trigger = "close"e21 : Transitionaction = "ACK"trigger = "FIN_ACK"v8 Statename = "Closing"e20 : Transitionaction = "ACK"trigger = "FIN"v11 Statename = "FinWait2"e19 : Transitionaction = "--"trigger = "ACK"e13 : Transitionaction = "--"trigger = "ACK"e7 : Transitionaction = "--"trigger = "RST"e6 : Transitionaction = "--"trigger = "ACK"e5 : Transitionaction = "FIN"trigger = "close"e14 : Transitionaction = "--"trigger = "ACK"e4 : Transitionaction = "ACK"trigger = "FIN"Figure 2: The final state machine after performing the core and both extension tasksof a solution is closely entangled to correctness, because an incomplete model may also lead to falsedecisions. Both correctness and completeness are weighted with 17.5%.The last property that will be judged is the performance, weighted with 5%. It is much less importantthan the other criteria, but of course such a transformation should be applicable on common hardware inacceptable time.References[1] Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides (1995): Design Patterns. Addison-Wesley.[2] Florian Heidenreich, Jendrik Johannes, Mirko Seifert & Christian Wende (2010): Closing the Gap betweenModelling and Java. In M. van den Brand, D. Gasevic & J. Gray, editors: Software Language Engineering,Lecture Notes in Computer Science 5969, Springer, pp. 374–383, doi:10.1007/978-3-642-12107-4 25.[3] Florian Heidenreich et al. (2009): JaMoPP: The Java Model Parser and Printer. Technical Report TUD-FI09-10, Technische Universität Dresden, Fakultät Informatik.[4] Tassilo Horn & Jürgen Ebert (2011): The GReTL Transformation Language. In Jordi Cabot & Eelco Visser,editors: Theory and Practice of Model Transformations, Fourth International Conference, ICMT 2011, Zurich,Switzerland, June 27-28, 2011. Proceedings, Lecture Notes in Computer Science 6707, Springer, pp. 183–197,doi:10.1007/978-3-642-21732-6 13.

Program Understanding: A Reengineering Case for the Transformation Tool
  Contest

Program Understanding: A Reengineering Case for the Transformation Tool Contest

Abstract

Similar works

Full text

Available Versions

Crossref

Directory of Open Access Journals