![](https://csdnimg.cn/release/download_crawler_static/12417244/bgc.jpg)
2. METHODOLOGY
2 Methodology
In this chapter, we propose a method to refactor software in a safe manner. The different com-
ponents of this method are explained in more detail in their own chapters. Figure 17 shows an
overview of the steps for refactoring the system as explained below.
Figure 3: Proposed refactoring method
1.) Model learning is a technique to learn the
behavior of a system from a black-box perspective.
The piece (slice) of software you want to learn the
behavior of, depends strongly on the type of refac-
toring you want to apply (Section 1.2) and the way
the legacy software is structured. If, for example,
the components of the software are strongly con-
nected but contain little logic it might prove more
effective to learn bigger chunks of, or even the en-
tire, software at once. If the software contains a lot
of logic, like in our industrial case, it might prove
more effective to isolate a smaller module of the
software and learn its behavior first. Thus refactor-
ing the software step by step.
To learn the behavior of a software module us-
ing automated learning tools, these tools need to
be able to communicate with the software mod-
ule. This means an adapter to replace the system
that normally calls the module by the learning tool
needs to be created. To properly learn the behavior
of this single software module and not that of its
dependencies, the dependencies should be replaced
using so-called stubs. The chosen module may also
contain cyclic dependencies with other modules. In
order to isolate the desired component these cyclic
dependencies need to be resolved. By generating
a graph of all dependencies and distinguishing all
strongly connected components in this graph, it is
possible to see how strong or loose the different
modules of a system are coupled. This helps in iden-
tifying the specific functions that need to be refac-
tored to uncouple a specific component. In Chapter
4, we describe the method we applied for isolating
the module in our industrial case.
2.) To learn the behavior of the legacy module
as precisely as possible, we used a combination of
model learning and analysis of system traces from our industrial case (trace analysis). Model
learning is a black box method to learn the behavior of a system, but because it is black box it is
not guaranteed to learn the complete behavior of the system. If, for example, a system responds
identically the first 100 times a button is pressed but responds differently the 101st time, most
model learning algorithms will already have stopped ‘exploring’ that button and not discover this
change in behavior. On the other hand, model learning tries to learn all possible combinations
of actions on the system. This means it might also learn behavior that should not occur during
a normal run of the system. This might be because of defensive programming (the software just
ignores illegal moves) or because the original developer never expected someone to use the module
in this way.
6