![](bg3.png)
Among the interactions with the user, it is expected to
extract data inputs from the user and present some in-
formation from the architecture core (patterns eligible
for insertion and metrics analysis result).
There are two main interactions available for the
user: start process and apply patterns:
Start Process: This interaction is triggered by the
user and it causes the CA to request two operations
provided by the IS. First the CA is responsible for col-
lecting project data from the Project Description, after
that, the CA requests the IS to register the project at
hand. The source code is compressed and sent with
all the other data collected initially.
After registering the project, the CA executes a
new request, this time it actually starts the refactoring
process. Now the CA has the id of the registered pro-
ject and uses it to make this start refactoring request.
At the end of this call, the CA receives all patterns eli-
gible for applying in the source code along with their
improvements in quality attributes terms.
Apply Patterns: Once the CA has all patterns eligi-
ble for applying in the source code, it displays them
to the user, along with their quality attributes evalua-
tion (detailed in the MS flow), so that s/he may choose
which to apply in his/her source code.
The CA retrieves the user’s choices and is in
charge of sending this data to the IS, this data is pro-
cessed to alter the source code. Once the refactored
source code is created, the CA displays a last mes-
sage, confirming the refactoring with the user.
If the user decides not to apply the chosen pat-
terns, either because s/he has given up or because s/he
decided that the refactorings do not worth to be exe-
cuted, then the refactoring process is cancelled. If
the user agrees that the refactorings should be made
the activities of the user are frozen and the old source
code is replaced by the new one (the refactored one).
3.3 Intermediary Service
All modules of the architecture do not communicate
with each other directly, the requests/responses are
sent to the the IS which in turn has the responsibi-
lity to manage these interactions between the modu-
les. This Service has to deal with the source code
inputs arriving from the CA as well.
In order to manage the active modules of the ar-
chitecture (Figure 1), these are grouped by their type,
that is, DMSs with DMSs, MSs with MSs and ASs with
ASs; in such a way, that for every type, there is a queue
related to it.
As already mentioned, a member is taken as active
if it frequently sends alive messages to the IS. This
kind of control is useful when a new request is re-
ceived and to distinguish what architecture member
should be executed, the IS searches in its queues by
type, the Service to be called.
For every kind of request received by the IS, the
due Service is retrieved from its own queue and called
through an HTTP request for processing.The functio-
nalities of this module, as well as the Services called
in the requests are presented as follows:
Register Project Request: It inserts the source code
(along with the other data provided) in the database.
The project will have its unique id once it is inserted,
after that, the id is sent as a response.
Start Refactoring Request: It retrieves the first DMS
in the queue and requests a pattern insertion spots
evaluation (with the id of the project). At the end of
the execution, the DMS receives as a reply all patterns
eligible for application, it forwards it to the IS along
with the id of the project.
Source Code Evaluation Request: it retrieves the
first MS available in the queue and forwards the evalu-
ation request to it (along with the id of the project and
the patterns eligible for application). After receiving
the response of the module, the IS sends a response
message to the CA with the eligible patterns and their
quality evaluations.
Pattern Insertion Request: This insertion is only
ment to refactor the source code based on one pattern
alone. As expected, the first DMS is retrieved from
the queue and, the application of a given pattern P1,
of a refactoring method M2, in the source code with
id XYZ is requested.
The response of this call is the id of the refactored
source code, this is because after the refactoring of
DMS, the refactored code is compressed and inserted
in the database of the architecture.
Source Code Refactoring Request: In this stage, the
patterns for the final refactoring were already chosen
by the user. The AS from the queue is retrieved and
is responsible for managing the application of all se-
lected patterns. The source code containing all the
patterns selected by the user is send to the CA. At last,
the project source code is removed from the database.
3.4 Detection Methods Service
One of the functions executed by this Service is to
check which patterns can be applied in the source
code. This module receives the request and submits
the source code to the evaluation of refactoring met-
hods present in the literature.
The refactoring methods of the literature have dis-
tinct approaches as to how to detect patterns insertion
spots in a certain source code. Gaitani et al. (Gaitani
et al., 2015) converts the source to Abstract Syntax
ICSOFT 2018 - 13th International Conference on Software Technologies
634