High-tech systems have numerous components that serve various purposes, and they are often old or custom-made. Maintaining these legacy components can be a significant burden on developers [1]. Modern software engineering practices offer alternatives to rudimentary coding methods for complex systems like supervisory control software. These alternative approaches include Domain Specific Languages (DSLs) that allow intuitive expression of state machines, improving the overall quality and maintainability of high-tech systems [2].

Working with both a legacy and a new framework for components can make maintaining a large code base more difficult. Replacing an old framework with a newer one enhances maintenance efficiency. The majority of effort is in refactoring existing components to use the new framework instead of the obsolete one, but ensuring behavior preservation after changes requires additional effort.

The challenge lies in replacing only outdated framework calls without altering other components' code. Regression test suites usually do not provide sufficient confidence that behavior has been preserved because of limited code coverage. Hence, the challenge is to ensure that changes have been implemented correctly and preserve the original behavior.

Static techniques like metaprogramming can analyze software internals but cannot extract meaning; dynamic techniques observe semantics but lose internal information. The Rascal metaprogramming language [3] is an example of a static technique that considers source code as data, allowing it to identify, for instance, the names of internal functions. It achieves this by parsing the source code into an Abstract Syntax Tree (AST), which can be used to construct a model like a Finite State Machine (FSM) representing the behavior of a piece of source code. Static techniques, however, cannot extract the execution semantics from the source code [4]. Hence, the use of metaprogramming for transformations faces challenges in determining the precise FSM semantics [5].

Dynamic techniques can execute the source code and generate a behavioral model that can be used to check if a new implementation has the same behavior as the legacy implementation. Active Model Learning (AML) [6] is an example of a dynamic technique that can be applied to construct behavioral models from existing software. Figure 1 shows how a learner application interacts with the software for which a model has to be made, the so-called System Under Learning (SUL). The learner is provided with the set of possible input events that it can send to the SUL. When learning starts, the learner calls sequences of input events called Membership Queries (MQ) to the SUL. For every sequence of input events, the SUL replies with a sequence of output events. Before a new input events sequence is called, the learner resets the SUL to its initial state. After a number of MQs, the learner constructs a hypothesis which is a state machine model of the SUL behavior. This hypothesis is tested for conformance with the SUL by means of Equivalence Queries (EQ). EQs can either confirm the hypothesis -in this case the hypothesis is the final model-or otherwise it will return a counterexample. The learner uses the counterexample to continue learning and create a new hypothesis. The resulting model is a deterministic finite state machine [7]. There are different learning algorithms available such as L* [7], TTT [8] and L# [9] for MQs and, i.e., Wp [10] and I-ADS [11] for EQs.

In Table 1, we compare static and dynamic techniques. It indicates that a combination of both techniques offers additional benefits over the use of each of them individually. Cannot inspect the internals of software.

Comparing static and dynamic techniques Figure 2 shows how we integrate the two approaches to acquire models of legacy code. We use the mCRL2 model checker to check the equivalence of the two models [12]. Note that when two finite state machines do not contain any unobservable internal transitions, trace equivalence and branch bisimulation equivalence coincide, and there is no difference between weak and strong equivalences [13].

Our approach is suitable for applications that meet the restrictions of AML which can be applied on data-independent control components, i.e., components where control decisions do not depend on input data. For a successful application of metaprogramming, the legacy code should contain a pattern that can be captured in a metaprogram. To justify the effort in creating such a metaprogram and have a good return of investment, there should be sufficient instances of the pattern.

Our refactoring approach has been applied to an industrial case that has the characteristics described above. It addresses a part of the code of an interventional X-ray system at Philips Image Guided Therapy (IGT). A legacy CppFSM framework is replaced with a new model-based FSM framework called Dezyne [14]. Observe that static and dynamic techniques cover different aspects when refactoring state machines:

• With metaprogramming, we can preserve state names, but ensuring a semantics-preserving behavior is impossible. • With AML, we can extract the execution semantics, but we lose the state names. We applied our approach, which combines both techniques, to replace more than a dozen CppFSMs. The combination and an equivalence check increase the confidence that the behavior is preserved after refactoring.

To our knowledge, this paper presents the first instance of combining static and dynamic techniques to refactor industrial C++ code

The paper is organized as follows. Background on the used technologies is described in Section 2. In Section 3, we introduce the industrial application. Our approach is highlighted in Section 4. In Section 5, the results of applying our approach to the industrial case are presented. Concluding remarks can be found in Section 6.

Related to our work is the book of Fowler on domain-specific languages [15]. Fowler defines refactoring as changing the internals of source code without changing its usage while preserving its behavior. The manual creation of test cases is advocated before the start of the refactoring when the current test cases provide insufficient code coverage. After an improvement of the tests to get better code coverage, the source code can be manually refactored.

As an alternative to manually refactoring code, metaprogramming is a static technique used to analyze and transform source code. A metaprogram accesses source code as whitebox; all internals of the source code can be inspected. Such a static technique cannot acquire the behavior of the source when it is executed [4]. Ivers et al. [16] have also identified that preserving the semantics is a challenge. Especially when dealing with, for instance, function pointers it is difficult to extract the operational semantics [17].

Examples of metaprogramming languages are Rascal [3], Algebraic Specification Formalism + Syntax Definition Formalism (ASF+SDF) [18], Stratego [19] and Turing eXtender Language (TXL) [20]. The following metaprogramming languages are specialized for C++: CodeBoost [21], Design Maintenance System (DMS) [22] and Proteus [23].

These metaprogramming languages have been applied in industry. At Google, the ClangMR [24] has been used to refactor large C++ codebases. They refactored callers of deprecated APIs. The tool is based on the Clang compiler in combination with the MapReduce parallel processor. Mooij et al. [25] refactored C++ code using small iterative steps. After the small code refactoring steps, a model was extracted from the source code before generating a new implementation. Schuts et al. [26] [27]. The conversions written in this paper were all implemented in Rascal. For some we also used ClaiR.

Active Model Learning (AML) has been applied in several non-trivial cases. For instance, to learn models of network protocol implementations, such as SSH, SIP, TCP, TLS, and models of smart cards for banking and bio-metric passports [28]. Model learning is also used in industry, e.g., at Canon to learn a controller of a high-end printing copier of 410 states and 77 stimuli was learned [29].

AML has also been applied in the context of manual refactoring. In [30], we describe a case at Philips where we learned a legacy implementation and a manually refactored implementation. Next we applied an equivalence checker to test if both implementations were equivalent. With this approach, we found issues in both implementations. After solving the issues, the models were equivalent. We also applied model learning and equivalence checking to test a model-to-model transformation from IBM Rhapsody to Dezyne [31].

Because of confidentiality we cannot share models from the interventional X-ray system and instead we explain the techniques using a vending machine example which is introduced in Section 3.1. Section 3.2 presents the CppFSM framework which is the legacy framework we want to remove from the code base. The target Dezyne framework of our transformation is described in Section 3.3.

Table 2 provides the state machine of the vending machine. The initial state is idle. From this state, a two Euro coin can be inserted. When this happens, the vending machine displays select beverage and transitions to the paid state. In the paid state there are two transitions: one for choosing coffee and yet another self transition for inserting a two Euro coin. On the other hand, coffee can be made black, or with sugar, milk or both. In all states -except from the idle state-a cancel event shall return the two Euro coin and go back to the idle state. For the readability of Table 2, we omitted the cancel event transitions.

For creating finite state machines in C++, Philips IGT used the CppFSM framework. Listing 1 shows how to create a FSM in the CppFSM framework. It is a fragment of the state machine in Table 2. The "addTransition" method adds transitions to the FSM in the following way:

1. First parameter is the current state. A state enumeration is used, but not shown in the listing.

2. Second parameter is the next state. The same state enumeration is used.

3. Third parameter is the input event. An input enumeration is used, but not shown in the listing. 4. Fourth parameter is the output event. This is a reference to a method.

Observe that a transition can only trigger one output event. The resulting state machine is input enabled which means that any event is accepted in any state; when no transition specified for a certain input event in a certain state, then there will be no output event, but also no assert will be called. Note that a CppFSM program can be seen as a component which has a provided interface with the input events and a required interface with the output events.

Listing Listing 2 shows how the FSM is used. Transitions can be triggered by calling the "makeTransition" method. The current state can be queried for with the "getState" method. It returns the state enumeration value. An example of an output event is "displaySelectBeverage". This method is registered as a function pointer in Listing 1. On a transition, the CppFSM framework can invoke this method.

Dezyne1 takes a component-based perspective on software. Every component typically has a provided interface and one or more required interfaces. There are two types of models:

• Interface model containing the signature and a behavioral protocol. The behavior protocol is written as a FSM which describes the allowed sequences of method calls. • Component model describing component behavior, including usage of interface models. This behavior is also written as a FSM which describes what needs to be done when method calls happen on the provided and required interfaces.

Dezyne implements a run-to-completion semantics. This means that a component does not accept new method calls on its provided interface until the current method call has returned. In addition a component that uses the provided interface is blocked until the method call on the required interface returns [32].

With the Dezyne tool, interface and component models can be formally verified. This verification uses the mCRL2 model checker [12] which checks:

• Whether deadlock and livelock states are absent in interface and component models.

• Whether component models are deterministic. For interface models it is allowed to describe non-deterministic behavior. • Whether a component is a refinement -using the failures divergence relation [33]-of its provided interface. • Whether a component does not violate the behavioral protocol of its required interfaces.

From a Dezyne model, a mCRL2 model and C++ code can be generated [34]. Verum2 , the company that implements the Dezyne tooling, guarantees that then the C++ code and the mCRL2 model are semantically equivalent [14].

Typically, one first verifies a Dezyne model and if all checks pass, C++ code can be generated. With bindings the generated C++ code can easily be integrated into handwritten C++ code.

mCRL2 is used in the background and is hidden from the typical user. However, the tool can also store the mCRL2 model for the user to allow inspection or advanced checks.

In this section, we describe how we refine our general approach to a number of steps that transform CppFSM code to Dezyne. This also include a refactoring of the manually written code that interfaces with CppFSM to code that interfaces with Dezyne generated code.

Figure 3 depicts our detailed transformation approach for the Philips IGT case. The left code file depicts the original situation before transformation. We distinguish three types of code in a single code file:

• At the bottom, CppFSM code that implements a finite state machine. • In the middle, code interfacing with the CppFSM code; it either calls FSM code or is called by the CppFSM code. • At the top, all other code. This code interacts with the interfacing code.

On the right, we depict the situation after the transformation where the CppFSM code is removed. There is a new code file which includes the code that is generated from a Dezyne model.

We have automated the refactoring using the following eight steps:

1. We use a static technique to parse the code file and extract the Abstract Syntax Tree (AST).

2. From the AST, the CppFSM part is used to generate a Dezyne model.

3. Generate a mCRL2 model from the Dezyne model. 4. Use a dynamic technique to learn the behavior of the CppFSM code. The output is a Dot file. Dot is a language to describe nodes, edges and graphs3 . 5. Convert the Dot file to a mCRL2 model. 6. Compare both mCRL2 models using an equivalence checker.

When both models are different, fix the issue. Otherwise, continue with:

7. The Dezyne model is used to generate a new code file that contains the FSM. 8. We use the AST to refactor the code that interface with CppFSM to interface with the newly Dezyne generated code. The steps of our approach are explained in more detail in the subsequent sections. Section 4.1 describes the transformation from CppFSM to Dezyne. The learning setup of Steps 4 & 5 is described in Section 4.2. The conversion of a learned model to a model that we can compare for equivalence is described in Section 4.3. Given two mCRL2 models, we describe Step 6 in which we compare the two models in Section 4.4. The last step to refactor the code that interfaces with CppFSM to make it use of the newly generated Dezyne C++ code is explained in Section 4.5. Listing 1 from the case description in Section 3 is the input for the Rascal script. The output is Listing 3 which shows the resulting Dezyne model of the vending machine's state machine. As explained in Section 2, the component model imports two interface models: one is the provided interface and the other one the required interface. The states are defined in the "State" enumeration. The "state" variable of type "State" is initialized to the "idle" state. Next we see blocks between curly brackets with a state guard. The model should be read as follows:

• If in the "idle" state "insertTwoEuroCoin" is called, then "displaySelectBeverage" is shown and the next state is "paid". • If in the "idle" state "cancel" is called, then it is accepted and the state remains "idle".

Note that the method "getState" returns the current state, but the method is not always needed. For this reason, we made the generation of this method optional. For this transformation, we used the Rascal code from Appendix A.

Model learning results in a model in the Dot language. To allow equivalence checking -as described in Section 2-we need an mCRL2 model. Hence, we need to convert the Dot model to an mCRL2 model, according to Figure 3 Step 5. Listing 4 is an example of a Dot model as produced by the learner when learning the vending machine. Observe that the states are numbered from "s0" to "s7". For example, line 5 of Listing 4 is a transition from state "s0" to state "s1". In the learning process, the state names are lost because they are not externally visible.

In Figure 3 Step 6, there are two mCRL2 models; one acquired by a dynamic technique (AML) and one generated by a static technique (metaprogramming). In this step, we compare the behavior of the two models using mCRL2. If the equivalence check fails, the checker provides a counter example that leads to a discrepancy in the models. To resolve the issue, several aspects have to be investigated. One possibility is that the dynamic technique learned an incomplete model; then the counter example can be used to continue the learning process. An alternative is that one of the generators in the static approach is incorrect, for instance, because of a mismatch in the understanding of the semantics of the programming language. After resolving the discrepancy, the equivalence checker needs to be rerun on the updated model because there can be more than one discrepancy to resolve. If the equivalence check passes, the Dezyne tool can be utilized to generate new C++ code (Step 7).

Figure 3 Step 8 depicts the workflow for refactoring a code file. The code that interfaces with the CppFSM framework needs to be replaced by code that interfaces with Dezyne generated C++ code. Calls to the CppFSM framework need to be replaced by calls to Dezyne generated C++ code. Moreover, we have to create the bindings such that Dezyne generated code can invoke the manually written output event methods. In addition, the CppFSM itself is no longer needed, because we use Dezyne generated code, and needs to be removed from the code file.

Section 3 explained how CppFSM code needs to be used. In Listing 1 a vending machine FSM is shown. This code is no longer required. We replace it with bindings to output events (i.e. actions) which is required for connecting Dezyne generated code to manually written action methods. The new bindings are shown in Listing 5. In Listing 2, the "makeTransition" method and "insertTwoEuroCoin" input event is used to initiate a transition. This is replaced by "insertTwoEuroCoin" on the "iProvided" interface, see Listing 6. The Rascal script for the described refactoring is provided in Appendix E Listing 16.

Listing 6: Usage of Dezyne generated code in C++ 1 mDezyneComposition.iProvided.in.insertTwoEuroCoin();

We applied the described approach to CppFSM code from Philips IGT. To our surprise, we observed that in Step 6 the mCRL2 models were not equivalent. When inspecting the learned model with a Dot viewer, we immediately realized that there was a semantic difference between the learned model and the generated Dezyne model. The learned model was input enabled, i.e., in all states all input events are allowed while the generated Dezyne model was not input enabled. We discovered that there were two versions of CppFSM: one for testing and one for in-product code. The testing flavor asserts on input events in states that do not have an explicit transition defined by "makeTransition". The product flavor, which was used in the Philips code, is input-enabled and accepts all inputs in all states. Hence, we had to make the generated Dezyne model also input enabled. We did this by creating the "makeStateMachineInputEnabled" method, see Listing 8 in Appendix A. After adding this method in the Dezyne model generator, the equivalence check holds.

After resolving this issue, we have applied the described approach to 14 Philips IGT cases. Table 3 depicts per case the number of states and transitions in both Dezyne generated and model learned mCRL2 models. In the table, we compare the mCRL2 models as introduced in Section 4. Using other models than the mCRL2 models, i.e., the Dezyne or Dot models would give different numbers for states and transitions. For comparison, we transform the mCRL2 models to Labelled Transition Systems (LTSs). In this way, the comparison only checks input/output relations. For all the refactored CppFSMs, the equivalence check holds which gave us a lot of confidence that refactoring was successful. Intuitively, one would expect that the equivalence check only holds when the number of states and transitions of the two models are equal. But in cases 3 and 4, we observed that the number of states and transitions is much lower in the dynamically learned model than in the statically obtained Dezyne model while the equivalence check holds. The reason is that the CppFSM did not have output events in these cases. This raises the question whether the Dezyne model can be simplified to fewer states and some transitions. When we investigated this further, we found out that in these two cases other code polls the "getState" method from Listing 2 to check the state of the FSM and makes different choices based on the returned state. To not break the manually written code, we added the possibility to generate a "getState" in the Dezyne model and we manually refactored the usage of the "getState" from CppFSM to the new Dezyne model variant in the interfacing code.

In some cases, "makeTransition" from Listing 2 was embedded in another method. This method got the event enumeration as a parameter value. Our automated refactoring presented in Section 4.5 did not work in this case. Also in this case, we manually made the required changes.

In this paper, we propose an approach to refactor Finite State Machines (FSMs) using a combination of static and dynamic techniques. This involves utilizing metaprogramming to generate a new FSM implementation from a source file containing a legacy FSM implementation. To increase confidence in the preserved semantics, we employ learning methods and equivalence checking. In this section, we describe limitations of our approach such as pitfalls and scalability in Section 6.1. Next we discuss alternative approaches in Section 6.2. Finally, in Section 6.3 we describe some ideas for future work.

We refactored the C++ code that interfaces with CppFSM to interface with the code generated by Dezyne, but it is not included in the learned model. Consequently, this weakness requires reliance on existing regression test suites for verification of correctness. However, since we have automated the refactoring process for the interfacing code, our confidence in its correctness is higher than with manual alternatives.

The main pitfalls concern the application of AML in an industrial setting. For instance, Omar et al. [35] have identified pitfalls while performing AML at Philips. Aslam [36] applied AML at ASML. In their setup, the adapter and the SUL are placed in separate executables and the adapter connects to the SUL using a TCP/IP socket connection. This setup is suboptimal because it is very slow to send and receive messages over a TCP/IP stack, to let the Operating System (OS) stop and start an executable for a reset, and to reestablish the TCP/IP connection. To mitigate this performance issue, we run the adapter and SUL in a single process, as shown in Appendix B Listing 10.

Omar et al. have identified that adapters could be generated. By generating the adapter, there are fewer opportunities to learn faulty models due to issues with the learning setup compared to the manual creation of adapters. Aslam et al. created a generator for the learning setup and we have also automated this process as described in Section 4.2.

Both identified issues with scalability, which we address in the next section.

State space explosion is a valid concern for both model learning and model checking [37]. Because of the time required to query and reset the SUL, AML will suffer from state space explosion before equivalence checking runs into the state space explosion problem. Hence, as shown by Aslam, it might be the case that complex models cannot be learned in a reasonable amount of time due to the limited ability to capture far-output-distinction behavior. To find far-output-distinction behavior, long EQs are required that distinguish the hypothesized model from the SUL's behavior. For instance, if "input1" produces an "output1". However, after calling "input1" one hundred times it no longer produces "output1", but "output2" [36]. By manual inspections of our CppFSMs before refactoring we know that such a pattern was not present in our industrial case.

In addition, we do not expect scalability issues with metaprogramming because creating an AST and perform functions using the AST is done in just a few seconds.

In this paper, we employed metaprogramming as a static technique and AML as a dynamic technique. However, other alternatives are possible.

Instead of using metaprogramming, we could have utilized a Language WorkBench (LWB) to create a Domain Specific Language (DSL) [2]. The DSL should be capable of parsing the "addTransition" method lines of Listing 1. The DSL can be employed to generate mCRL2 models. In fact, for this approach and the one used in the paper, the same mCRL2 model code generator could be reused. The only difference is in Step 8, as a DSL cannot refactor the C++ code file to use the generated C++ code with the Dezyne tool. Alternatively, manual refactoring can be performed.

An alternative dynamic approach is to execute the code using test cases. Typically, testing such FSMs will be done using unit testing. However, legacy code is characterized by limited code coverage of the tests [38]. To mitigate this issue, techniques can be employed to improve existing unit test suites by applying, e.g., mutation testing [39] or test amplification [40]. Downside of these techniques is that most implementations only support Java and not C++ which is our target language. The benefit of using AML is that it is programming language agnostic.

For this case, we manually checked that far-output-distinction behavior did not occur. Alternatively, we could have automated this check using a small metaprogram with, i.e., Rascal. Or we could have used a code coverage tool to check if all code is executed by AML.

There is a limitation where the refactored interfacing code is not learned due to its separation from the FSM implementation. For the correctness of this refactoring, we relied on the existing regression test suites. In the future, we want to investigate if we could include this code in the learned model.