Felipe Lima Cunha Vieira

Uma Aplicação Web para a predição de qualidade de

código de funções.

São José dos Campos, SP

 Felipe Lima Cunha Vieira

Uma Aplicação Web para a predição de qualidade de

código de funções.

Trabalho de conclusão de curso apresentado ao

Instituto de Ciência e Tecnologia – UNIFESP,
como parte das atividades para obtenção do tí-
tulo de Bacharel em Ciência da Computação.

Universidade Federal de São Paulo – UNIFESP

Instituto de Ciência de Tecnologia
Bacharelado em Ciência da Computação

Orientador: Prof.Dr.Otavio Augusto Lazzarini Lemos

São José dos Campos, SP

Agosto 2021
Elaborado por sistema de geração automática com os dados fornecidos pelo(a) autor(a).

Lima Cunha Vieira, Felipe

Uma Aplicação Web para a predição de qualidade de código de funções/ Felipe Lima
Cunha Vieira
Orientador(a) Otavio Augusto Lazzarini Lemos-São José dos Campos, 2021.
43 p.

Trabalho de Conclusão de Curso-Bacharelado em Ciência da Computação-

Universidade Federal de São Paulo-Instituto de Ciência e Tecnologia, 2021.

1. Engenharia de Software . 2. Inteligência artificial. 3. Desenvolvimento WEB.

I. Augusto Lazzarini Lemos, Otavio, orientador(a). II. Título.
 Felipe Lima Cunha Vieira

Uma Aplicação Web para a predição de qualidade de

código de funções.

Trabalho de conclusão de curso apresentado ao

Instituto de Ciência e Tecnologia – UNIFESP,
como parte das atividades para obtenção do tí-
tulo de Bacharel em Ciência da Computação.

Prof.Dr.Otavio Augusto Lazzarini Lemos

Orientador

Professor
Convidado 1

Professor
Convidado 2

São José dos Campos, SP

Agosto 2021
Este trabalho é dedicado aos meus pais, avós, meus familiares, esposa e todos aqueles que me
apoiaram na realização desse sonho.
 Agradecimentos

Gostaria de agradecer especialmente aos meus pais, avôs e irmã, pois foi através deles
que aprendi a dar o melhor em tudo aquilo que faço.
Deixo também, meus agradecimentos a minha esposa, familiares e amigos. Sempre me
apoiaram e se colocaram a disposição, auxiliando em todos os momentos de dificuldade. Acre-
ditem que parte dessa conquista são de vocês, estarei sempre disposto a retribuir e conquistar
novos sonhos com cada um.
Agradeço ao Prof.Dr.Otavio Augusto Lazzarini Lemos, por aceitar ser meu orientador,
me guiar compartilhando seu conhecimento ao longo da realização desse trabalho de TCC.
“O analfabeto do século XXI não será aquele que não consegue ler e escrever,
mas aquele que não consegue aprender,
desaprender e reaprender."
(Alvin Toffler)
 Resumo
Recentemente pesquisadores implementaram uma ferramenta nomeada como rea-
per, que possibilita os usuários selecionar projetos que possuem indícios de que são proje-
tos sólidos, segundo dimensões de engenharia de software. No trabalho em questão, foram
utilizados dois métodos de classificação, o random forest e um classificador baseado em
pontuação, o trabalho classifica o projeto, e não trechos de código individuais.
Em seguida, outra pesquisa investigou se algoritmos de Machine Learning (ML)
são capazes de identificar diferenças entre códigos. Assim sendo, classificar se determinado
trecho de código segue ou não boas práticas. Os resultados indicam a existência de padrões
que distinguem trechos de códigos engineered (funções que seguem boas práticas) e non-
engineered (funções que não seguem boas práticas).
A pesquisa citada anteriormente apresentou bons resultados na classificação de
códigos de funções, porém o processo para classificar o código possui etapas manuais e
não possui uma interface que possibilita o usuário realizar a classificação do seu código.
Portanto, para este trabalho é proposto um complemento às pesquisas realizadas,
implementando uma ferramenta que permite o usuário usufruir do modelo de classificação
de forma fácil, automatizada e através de interfaces web. A aplicação recebe um trecho de
código, em seguida retorna sua classificação (segue ou não boas práticas), retorna também
o valor das métricas de software que foram analisadas.

Palavras-chaves: machine learning. métricas. sistema web. qualidade.

 Abstract
Recently, researchers have implemented a tool named reaper, which allows users
to select projects that have evidence that they are solid projects, according to software
engineering dimensions. In the present work, two classification methods were used, the
random forest and a score-based classifier, the work classifies the project, and not individual
code snippets.
Then, another research that investigates whether Machine Learning (ML) algo-
rithms are able to identify differences between codes. Therefore, classifying whether a
given piece of code follows good practices or not. The results indicate the existence of pat-
terns that distinguish code snippets engineered (functions that follow good practices) and
non-engineered (functions that do not follow good practices).
The research mentioned above showed good results in the classification of function
codes, but the process to classify the code has manual steps and does not have an interface
to allow the user to evaluate his code.
Therefore, for this work, a complement to the researches carried out is proposed,
implementing a tool that allows the user to take advantage of the classification model in an
easy, automated way and through web interfaces. The application receives a code snippet,
then returns its rating (whether it follows good practices or not), it also returns the value of
the software metrics that were analyzed.

Key-words: machine learning. metrics. web system. code quality.

 Lista de ilustrações

Figura 1 – Hierarquia do aprendizado . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Figura 2 – Representação de um neurônio artificial . . . . . . . . . . . . . . . . . . . 18
Figura 3 – Arquitetura de uma MLP com duas camadas ocultas . . . . . . . . . . . . . 19
Figura 4 – Representação da relação entre variáveis dependente e independentes. . . . 20
Figura 5 – Algoritmo k-NN, k=3 e k=5. . . . . . . . . . . . . . . . . . . . . . . . . . 21

Figura 6 – Diagrama Arquitetura limpa. . . . . . . . . . . . . . . . . . . . . . . . . . 25

Figura 7 – Diretório de pastas do projeto do extrator e do executável (.jar) . . . . . . . 30

Figura 8 – Script Python que carrega o modelo de classificação . . . . . . . . . . . . . 31
Figura 9 – Diagrama Arquitetura limpa ao do diagrama do back-end da aplicação . . . 31
Figura 10 – Organização dos diretórios da aplicação . . . . . . . . . . . . . . . . . . . 32
Figura 11 – Listando por camadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figura 12 – Arquitetura do back-end . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figura 13 – Fluxo até a classificação do código . . . . . . . . . . . . . . . . . . . . . . 35
Figura 14 – Não segue boas práticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figura 15 – Segue boas práticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figura 16 – Retorno do sistema - função projetada e não projetada . . . . . . . . . . . . 37
 Lista de tabelas

Tabela 1 – Métricas adotadas para o estudo com respectiva descrição. . . . . . . . . . . 23

Tabela 2 – Informações dos artigos citados nesta seção . . . . . . . . . . . . . . . . . 27

Tabela 3 – Dimensões consideradas por (MUNAIAH et al., 2017) . . . . . . . . . . . 28
 Lista de abreviaturas e siglas

IA Inteligência Artificial

ML Aprendizado de Máquina

MLP Multilayer Perceptron

LR Regressão Logística

CHD Doença Cardíaca Coronária

TS TypeScript

JSON JavaScript Object Notation

HTML Hyper Text Markup Language

JSON Extensible Markup Language

 Sumário

1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1 Contextualização e Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2 Definição do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3 Justificativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.6 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 Aprendizado de máquina . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1 Aprendizado Supervisionado . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Pré-processamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Algoritmos de Machine Learning (ML) . . . . . . . . . . . . . . . . . . . . . 17
2.3.1 Redes Neurais Artificiais . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2 Logistic Regression (LR) . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.3 k-Nearest Neighbours (k-NN) . . . . . . . . . . . . . . . . . . . . . . 20

3 Engenharia de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1 Métricas de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Arquitetura de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 A Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Predição de qualidade de código . . . . . . . . . . . . . . . . . . . . . . . . 27

5 Aplicação Web para a predição de qualidade de código de funções . . . 29

5.1 Módulo de extração de métricas . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 Modelo de classificação de código de funções . . . . . . . . . . . . . . . . . . 30
5.3 Back-end da aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4 Front-end da aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.5 Teste e retorno da aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
1 Introdução

1.1 Contextualização e Motivação

A sociedade é composta por padrões e convenções. É possível notar nas diversas áreas
uma unificação na forma em que os indivíduos se comunicam. Estabelecer uma comunicação
unificada, parte da ideia de facilitar a compreensão das pessoas sobre algo comum entre elas.
O sistema de trânsito pode ser considerado como um exemplo de abstrações de padrões, que se
tornou uma forma organizada e unificada de regras entre seus usuários (motoristas e pedestres).
Assim como nas diversas áreas, a computação também é composta por convenções e
padronizações. No desenvolvimento de software, análogo ao sistema de trânsito, também pos-
sui diversos padrões como: formas de definir a qualidade do código, arquitetura, mensagens de
commits, comentários, etc. Considere uma empresa que possui suas próprias normas, totalmente
distintas das demais empresas ou até mesmo vários projetos cada um com padrões individuais.
Qual seria a mobilidade de profissionais entre os projetos? Qual o tempo gasto para treinar os
profissionais até se adequarem com as especificações únicas da empresa? São alguns questiona-
mentos que devem ser levados em consideração, ao se definir uma forma de comunicação entre
as empresas e projetos.
Considerando o contexto de desenvolvimento de software é notório a implementação
de convenções e padrões como base para o desenvolvimento de soluções. A definição de nor-
mas visa facilitar a comunicação entre os desenvolvedores, compreensão de código e manter a
qualidade do sistema.
Segundo a pesquisa realizada por (MINELLI; MOCCI; LANZA, 2015), os desenvolve-
dores passam maior parte do tempo refatorando código. Em média 70% do tempo de um de-
senvolvedor é gasto para compressão de códigos já existentes. A qualidade do código impacta
o processo de manutenção. Boas práticas de programação, definições de padrões proporcionam
aos programadores ganhos e facilitação no entendimento de algo comum (nesse caso, os códi-
gos já desenvolvidos). Portanto o uso dos padrões podem ser revertidos em melhores resultados
no processo de desenvolvimento.
Assim sendo, os sistemas podem ser classificados como aqueles que seguem padrões
sólidos de software e os que não seguem. É possível mensurar quanto um código segue deter-
minado padrão. As métricas de softwares são uma forma de mensurar se um trecho de código
segue um determinado molde pré-definido.
Ao considerar o contexto geral de desenvolvimento, a qualidade de código e boas práti-
cas é algo que todo programador deveria se atentar, pois a forma que o código foi desenvolvido,
pode ser considerada como a forma de comunicação com outros desenvolvedores que possam
1.2. Definição do Problema 13

ter contato com o código. Este trabalho tem como objetivo desenvolver um sistema web capaz
de classificar, se um trecho de código segue ou não boas práticas. Por fim, a ferramenta que de-
senvolvida pode servir como uma base de análise de código, fornecendo indícios de qualidade.

1.2 Definição do Problema

O trabalho desenvolvido por (LEMOS, 2019) apresentou bons resultados na classifica-
ção de códigos de funções, porém o processo para classificar um código possui etapas manuais,
além de não possuir uma interface que possibilita ao usuário comum realizar a classificação do
seu código. O sistema visa otimizar as etapas manuais:

• Fornecer o código de um função ao módulo que realiza a extração das métricas.

• Obter as métricas extraídas e fornecer como entrada ao modelo de classificação.

Por fim, fornecer uma interface web para facilitar a experiência do usuário. Foi desen-
volvido o front-end e o back-end que faz a integração do extrator de métricas e o modelo de
classificação.

1.3 Justificativas
Neste trabalho é proposto um complemento às pesquisas já realizadas, implementando
uma ferramenta que permite ao usuário usufruir do modelo de classificação desenvolvido por
(LEMOS, 2019) de forma fácil e automatizada através de interfaces do sistema.
Além de fomentar os desenvolvedores a considerarem a qualidade de seus códigos, a
aplicação também gera mais visibilidade para o estudo.

1.4 Objetivos
1.4.1 Objetivo Geral
Esse trabalho tem como objetivo desenvolver uma aplicação Web para predição da qua-
lidade de código de funções, assim contribuir com a comunidade de desenvolvedores.
A proposta é reunir conhecimentos de Engenharia de Software e Aprendizado de Má-
quina para a criação de um sistema Web que utiliza um modelo de classificação desenvolvido
por (LEMOS, 2019) que seja capaz de classificar se um trecho de código (função) segue ou não
boas práticas de programação.
É previsto também que o sistema forneça as métricas utilizadas no modelo de classifi-
cação, esse retorno pode ser servir como base para possíveis melhorias no código submetido.
14 Capítulo 1. Introdução

1.4.2 Objetivos Específicos

Idealizando alcançar o objetivo geral desse trabalho, é possível listar objetivos específi-
cos. Sendo a conclusão destes, o caminho para o desenvolvimento final do projeto.

• Planejamento do processo de pesquisa e implementação da aplicação.

• Estudo e pesquisa das tecnologias definidas para o desenvolvimento da ferramenta.

• Implementação do Back-End da aplicação.

• Implementação do Front-End da aplicação.

• Realização dos testes no sistema.

• Analise dos testes e resultados do sistema.

1.5 Metodologia
Serão descritas as etapas seguidas para que o objetivo deste trabalho seja alcançado, as
ferramentas computacionais que serão utilizadas e a divisão das tarefas.
O projeto consiste na implementação de um sistema de predição de qualidade de código,
o modelo classifica um trecho de código como engineered ou non-engineered.
É utilizado como base o algoritmo desenvolvido por (LEMOS, 2019), ele é capaz de
classificar códigos de funções. O modelo recebe como entrada um conjunto de métricas de soft-
ware e foi desenvolvido em linguagem Python. O algoritmo que realiza a extração das métricas
foi desenvolvido em linguagem Java.
Neste trabalho será desenvolvido um sistema que integre as etapas manuais no processo
de classificação do trabalho desenvolvido por (LEMOS, 2019). Extrair as métricas para que
possam ser fornecidas ao modelo. Além do gerenciamento de ambas as etapas (extração de
métricas e classificação), o sistema fornece uma interface de entrada para código de função,
facilitando a interação com os usuários.
A implementação foi realizada em quatro etapas: Estudo dos algoritmos já desenvol-
vidos (extrator e classificador), desenvolvimento do back-end, desenvolvimento do front-end e
testes de verificação dos resultados obtidos.
A seguir é descrito em tópicos algumas ferramentas utilizadas. Estão descritos alguns
termos, etapas do desenvolvimento e as tecnologias juntamente as estratégias aplicadas.

• Git e Github: O Git é um sistema open-source de controle de versão, já o Github é

um serviço online de hospedagem de repositórios, ou seja o Github é um serviço que
1.6. Estrutura do Trabalho 15

possibilita ter uma cópia do seu versionamento local na nuvem. Neste trabalho Git/Github
é utilizado para fazer o versionamento do código e manter esse histórico na nuvem.

• Modelo de Classificação: No modelo é utilizada a linguagem Python que é responsável

pela classificação dos códigos de função.

• Back-End da aplicação: O back-end é uma parte que compõe o sistema, nesta etapa
de implementação é utilizado TypeScript como linguagem e estruturado com a Clean
Architecture.

• Front-End da aplicação: O front-end é uma parte do sistema, nesta etapa de implemen-

tação é utilizado JavaScript.

• Extrator: O extrator das métricas, é um código desenvolvido na linguagem Java, ele é

responsável por extrair as métricas de qualidade de código das funções, o sistema por fim
utiliza esses dados que foram extraídos para etapa de classificação.

• Reactjs: O Reactjs é um framework de desenvolvimento web que é utilizado para desen-

volver o front-end da aplicação.

1.6 Estrutura do Trabalho

O trabalho foi dividido em subcategorias, para facilitar o entendimento e organização
das ideias.
O texto foi desmembrado em seis capítulos, um deles foi definido para a introdução do
trabalho. A introdução está definida da seguinte forma: Contextualização do problema, defini-
ção, objetivos e seguindo com a metodologia.
No capítulo 2 será apresentado conceitos, assuntos e questões discutidas no trabalho
que envolvem aprendizado de máquina. A intenção é fornecer um embasamento teórico para
facilitar o entendimento do projeto.
O capítulo 3 se assemelha ao capitulo 2, porém abortando tópicos de engenharia de
software.
O capítulo 4 é o de revisão da literatura que mostra o estado da arte, basicamente con-
siste em um estudo de trabalhos relacionados a temática de qualidade de código e estratégias de
aprendizado de máquina para classificação da qualidade do código.
O capítulo 5 descreve as atividades desenvolvidas, como foi modelada e implementada
a aplicação.
Por fim, o capítulo 6 é a conclusão do trabalho. Neste capítulo é retomado os principais
pontos discutidos, junto com a conclusão e trabalhos futuros.
2 Aprendizado de máquina

O aprendizado de máquina é uma sub-área de pesquisa da inteligência artificial (IA) que

por sua vez tem como objetivo abstrair conhecimentos a partir de estratégias computacionais.
A ideia é basicamente extrair conhecimento e informações por meios automáticos, o avanço
da computação contribui diretamente, viabilizando a execução de modelos matemáticos em
computadores.
Um sistema de aprendizado pode ser considerado então, um programa de computador
capaz de tomar decisões assertivas a partir de uma base de dados que contêm experiências se-
melhantes e bem sucedidas sobre determinado assunto. O sistema deve classificar partindo de
conhecimentos e experiências prévias, tomando decisões corretas, sendo assim possível consi-
derar que o sistema exerce conhecimento (MONARD; BARANAUSKAS, 2003).
Descrito por (BATISTA et al., 2003), o conceito de aprendizado indutivo é conside-
rado como o ato de induzir por inferência lógica, permitindo que os algoritmos de aprendizado
façam conclusões reconhecendo padrões identificados em um conjunto de exemplos pré defi-
nidos. Portanto é importante que os dados fornecidos ao sistema estejam corretos, visto que o
aprendizado se baseia por inferência.
Como mencionado, um sistema de aprendizado se trata de um programa que pode to-
mar decisões baseado em experiências passadas e bem sucedidas, sendo que esse exercício é
possível por meio de aprendizado indutivo que por sua vez pode ser dividido em aprendizado
supervisionado e não supervisionado (MONARD; BARANAUSKAS, 2003). Vale ressaltar que
neste trabalho é utilizado um algoritmo de aprendizado supervisionado de classificação, esses
conceitos serão abordados a seguir.

2.1 Aprendizado Supervisionado

O Aprendizado Supervisionado é composto por um conjunto de algoritmos que estão
divididos em dois conjuntos distintos, algoritmos de Classificação e de Regressão, apresentados
na figura 1. Neste trabalho foi utilizado um classificador baseado em algoritmos de classifica-
ção supervisionado com o intuito de identificar código de funções que seguem boas práticas
e aqueles que não seguem. É apresentado por (CARUANA; NICULESCU-MIZIL, 2006) uma
comparação e avaliação empírica entre alguns métodos de aprendizado supervisionado, rela-
tando progresso dos métodos estudados nas últimas décadas.
Aprendizado Supervisionado também chamado de modelo preditivo é uma função que
através de um conjunto de exemplos pré rotulados, gera um estimador. Considerando o conjunto
de dados de exemplo, cada exemplo individualmente assume um rótulo pertencente a um do-
2.2. Pré-processamento 17

Figura 1 – Hierarquia do aprendizado

Fonte: o autor.

mínio. Então o algoritmo de classificação se dá quando o domínio for um conjunto que assume
valores discretos (FACELI et al., 2011).

2.2 Pré-processamento
O pré-processamento é uma etapa que realiza a preparação dos dados para a classifica-
ção. Basicamente esta fase consiste em um conjunto de transformações que são realizadas no
conjunto de exemplo fornecidos para o preditor com o intuito de transformar em uma repre-
sentação adequada, ou seja uma representação de vetor de dados que pode ser consumido pelos
algoritmos de classificação. No livro de (FACELI et al., 2011) é abordado algumas técnicas
como amostragem, tratamento para dados desbalanceados, modificações para adequação dos
tipos de atributo, limpeza dos dados, transformação dos dados e redução de dimensionalidade.

2.3 Algoritmos de Machine Learning (ML)

2.3.1 Redes Neurais Artificiais

As redes neurais são sistemas computacionais, compostas por unidades de processa-
mento simples que por sua vez são interconectados geralmente unidirecionais, essa unidade de
18 Capítulo 2. Aprendizado de máquina

processamento é conhecida como neurônio artificial. Os neurônios são responsáveis por com-
putarem funções matemáticas, eles são distribuídos em camadas.
As conexões na maioria das arquiteturas fazem analogia com as sinapses biológicas
possuindo pesos associados, sendo que esses pesos podem assumir valores positivos ou negati-
vos dependendo da conexão. Os pesos têm seus valores ajustados no processo de aprendizado
que ao final representam o conhecimento adquirido. Conhecimento descrito em (FACELI et al.,
2011).

Figura 2 – Representação de um neurônio artificial

Fonte: o autor.

Multilayer Perceptron (MLP)

Na figura 3 é apresentada a arquitetura de uma MLP (Multilayer Perceptron), com três

camadas sendo uma delas a camada de saída, é possível observar que a rede está totalmente
conectada, isso significa que qualquer neurônio está conectado a todos os neurônios da camada
anterior. O sinal é transmitido de camada a camada da esquerda à direita, em direção a camada
de saída.
Para o entendimento da MLP é importante estar claro dois conceitos que são a ideia de
Sinais funcionais e Sinais de Erro, a seguir é esclarecido o que cada um se refere.

• Sinais funcionais: São os estímulos que chegam como entrada para um neurônio, estes
são chamados de sinais funcionais pois passam por uma função dentro de cada nó, a saída
dessa função é então passada como entrada ao nó da próxima camada, se propagando
neurônio a neurônio através da rede até a camada de saída (HAMILTON ONTARIO, ).
2.3. Algoritmos de Machine Learning (ML) 19

Figura 3 – Arquitetura de uma MLP com duas camadas ocultas

Fonte: (HAMILTON ONTARIO, )

• Sinais de Erro: O sinal de erro surge em um neurônio da camada de saída e se propaga

da direita para a esquerda, esse estímulo é chamado de sinal de erro devido ao seu cál-
culo ser resultado de um erro local implícito ao gradiente local de cada nó (HAMILTON
ONTARIO, ).

O algoritmo de MLP consiste em aprendizado supervisionado, backpropagation ou re-

tropropagação, considerado também como um algoritmo de aprendizado por correção de erro.
Cada neurônio executa sua função propagando os dois tipos de sinais citados anteriormente.
20 Capítulo 2. Aprendizado de máquina

2.3.2 Logistic Regression (LR)

A regressão logística assim como os demais métodos de regressão utilizados em esta-
tísticas é uma análise preditiva, que por sua vez é usada para encontrar modelos que melhor
descrevem e interpretam a relação entre uma variável de resultado e um conjunto de variáveis
independentes. Esta análise justamente busca modelar a relação da variável de resultado com o
conjunto de variáveis independentes (JR; LEMESHOW; STURDIVANT, 2013).
A seguir será apresentada uma explicação e um exemplo prático de uso da LR (re-
gressão logística) baseada no livro (KLEINBAUM et al., 2002). Considerando o contexto de
doenças cardíacas, qual seria a relação entre o conjunto de variáveis de exposições ‘E’ a uma
determinada doença ‘D’?
Para este exemplo, indivíduos com doença cardíaca coronária (CHD) são classificados
com status ‘1’ e os que não possuem CHD com ‘0’, como variável de exposição única é consi-
derado o tabagismo, classificado com status ‘sim’ e ‘não’.
Então a questão de pesquisa para esta análise seria qual é a relação entre fumar e indi-
víduos que se enquadram com o status de CHD igual a ‘1’.
Esta avaliação pode contar com múltiplos fatores associados a esta doença. Na figura 4
são considerados um conjunto de fatores (variáveis) independentes, uma seta que representa a
relação com com a variável de resultado (citada anteriormente) que é dependente.

Figura 4 – Representação da relação entre variáveis dependente e independentes.

Fonte: (KLEINBAUM et al., 2002)

2.3.3 k-Nearest Neighbours (k-NN)

O K-NN (k-Nearest Neighbours) se enquadra nos algoritmos de classificação e regres-
são. O algoritmo dos K vizinhos mais próximos se baseia na técnica de analisar os k vizinhos
mais próximos, então com base neles classifica o nó em questão.
Como mencionado, o K-NN pode ser utilizado em problemas de regressão e de clas-
sificação, a forma de interação dos vizinhos nestes dois casos são diferentes (FACELI et al.,
2011).
2.3. Algoritmos de Machine Learning (ML) 21

Cada vizinho antes do teste já pertence a uma classe conhecida, então cada vizinho
selecionado, vota em sua classe, os retornos dos k vizinhos são agregados contribuindo para
a classificação. Nos problemas de classificação o nó de teste recebe a classe que teve mais
retornos (FACELI et al., 2011).
A seguir na figura 5 é apresentada uma ilustração do algoritmo k-Nearest Neighbours,
é possível observar duas classes (vermelha e azul), considerando a bolinha preta como objeto
que será classificado. No caso de k = 3 ele seria classificado como vermelho, porém com k = 5
ele seria considerado como azul.

Figura 5 – Algoritmo k-NN, k=3 e k=5.

Fonte: O autor.

Quanto a escolha do valor k, pode ser definido pelo usuário e deve sempre ser ímpar
para evitar empates. Evidente que os resultados podem ser diferentes dependendo do k, existem
outras duas formas consideradas na literatura para definir esse valor. Estimar o k por validação
cruzada ou associar um peso para cada vizinho, nessa opção o peso atribuído consiste em um
valor inversamente proporcional à distância do objeto em teste (FACELI et al., 2011).
3 Engenharia de Software

A Engenharia de Software é uma área dentro da computação, composta de processos

que envolvem desenvolvimento de software, (CARUANA; NICULESCU-MIZIL, 2006) cita
duas abordagens que considera que a Engenharia de Software basicamente estuda e é dedicada a
projetar, implementar e modificar software levando em consideração variáveis como qualidade,
custo, tempo de desenvolvimento, etc.
O autor considera que não existe um processo único global, mas que esse processo deve
ser adaptado para cada projeto devido a particularidade do escopo de cada sistema. Porém, é
possível identificar características semelhantes e a partir delas modelar processos adequados de
acordo com que o software se encaixe. Dessa forma, do ponto de vista da Engenharia de Soft-
ware é possível classificar os sistemas como: software básicos (compiladores, drivers e compo-
nentes do SO), de tempo real (sistemas que monitoram, analisam e controlam eventos do mundo
real), comercial (sistemas aplicados nas empresas, como controle de estoque, vendas etc), ci-
entífico e de engenharia (sistemas que utilizam intenso processamento de números), embutido
ou embarcado (sistemas de software presentes em celulares, eletrodomésticos, automóveis etc),
pessoais (sistemas usados por pessoas no dia a dia, como processadores de texto, planilhas etc),
jogos e inteligência artificial considerados como sistemas capazes de obter alguma forma de
aprendizado.

3.1 Métricas de software

Métrica é considerada como um sistema de medição. A prática de medição exige que
seja capaz identificar de forma intuitiva atributos, aspectos ou entidades e também a atribuição
de números ou símbolos. Em outras palavras, a definição de medir é o estabelecimento de
relações entre algo e um sistema numérico (FENTON; BIEMAN, 2014).
As métricas de software são então definidas como um sistema de medição de software,
dentro deste contexto existem diversas atividades como:

• Medida de estimativas de custo e esforços.

• Avaliações estruturais

• Medição de qualidade

• Métricas de segurança

• Avaliação da complexidade
3.1. Métricas de software 23

Todas essas possibilidades envolvem algum grau de medição de software. No presente

trabalho essas métricas são utilizadas para extrair dados referentes a trechos de códigos (fun-
ções), após a extração, elas serão fornecidas como dado de entrada para o aprendizado do mo-
delo de classificação. Na Tabela 1 é possível observar a categoria, nome e descrição respectivos
à cada métrica utilizada.

Tabela 1 – Métricas adotadas para o estudo com respectiva descrição.

Categoria Nome Descrição

COMP Métrica de complexidade de McCabe
NIF Número de declarações if
NOA Número de argumentos
VDEC Número de variáveis declaradas
VREF Número de variáveis referenciadas
Tamanho do código NOS Número de declarações
& NEXP Número de expressões
complexidade MDN Profundidade máxima de aninhamento
CAST Número de elencos de classe
LOOP Número de loops (for, while)
NOPR Número total de operadores
NAND Número total de operandos
SLOC Número de linhas de código-fonte
NTOKENS Número de tokens
HVOC Vocabulário Halstead
Halstead HLTH Comprimento médio do método
HDIF Dificuldade do método Halstead
NBLTRL Número de literais booleanos
NCLTRL Número de literais de caracteres
Literais NSLTRL Número de literais de string
NNLTRL Número de literais numéricos
NNULLTRL Número de literais nulos
CREF Número de classes referenciadas
Comunicação XMET Métodos externos chamados
LMET Métodos locais chamados
Exceção EXCR Número de exceções referenciadas
EXCT Número de exceções lançadas
Documentação NOCL Número de linhas de comentário
Fonte: O autor
24 Capítulo 3. Engenharia de Software

3.2 Arquitetura de Software

Arquitetura de Software pode ser um conceito incomum para alguns, mas a ideia se ba-
seia, de fato, na junção do sentido literal de ’Arquitetura’ e ’Software’ individualmente. A seguir
é apresentado o significado de cada uma delas, posteriormente uma abstração da Arquitetura de
Software em si.
A arquitetura é considerada como a arte de construir, que deve considerar, elementos,
componentes que se relacionam com o objetivo que se deseja alcançar. Ela também possui
o propósito de ordenar e organizar, a fim de formar estruturas. Construir é algo consciente
incorporando reflexões e avaliações (ROTH, 2018).
Software pode ser compreendido como um conjunto de instruções compostas por estru-
turas de dados, funções ou comandos, que juntos possibilitam aos desenvolvedores manipular
informações. Então, software é basicamente um conjunto de instruções, sendo elas executadas
por hardware, computador ou por dispositivo eletrônico (PRESSMAN; MAXIM, 2016).
Portanto, arquitetura de software de um sistema, consiste na forma de organização e
divisão das partes do sistema, uma abstração sistemática de como os conjuntos de estruturas
são dispostos. A arquitetura de um sistema computacional também diz respeito a forma que
as estruturas interagem entre si e como elas se relacionam (BASS; CLEMENTS; KAZMAN,
2003).
A arquitetura compreende elementos e as relações entre esses elementos, a forma que
eles são implementados internamente não interessa em termos arquiteturais, somente como eles
interagem uns com os outros (BASS; CLEMENTS; KAZMAN, 2003).

Arquitetura Limpa
Nesta seção será apresentado o conceito de Arquitetura Limpa baseado no livro “Clean
Architecture: A Craftsman’s Guide to Software Structure and Design.”, escrito por Robert Mar-
tin (MARTIN, 2018).
A Clean Architecture é um padrão de arquitetura que define uma forma de organização
estrutural que mantém os elementos do sistema como citado na seção anterior dispostos em uma
determinada organização.
Na figura 6 é possível observar um diagrama que representa a ideia da arquitetura limpa,
que na verdade é uma tentativa de integrar conceitos de diversas arquiteturas (MARTIN, 2018),
como por exemplo:

• Independente de frameworks: A arquitetura não fica amarrada, dependente a nenhuma

ferramenta como por exemplo frameworks ou bibliotecas. Isso deixa o sistema livre, sem
restrições e suscetível a mudanças.
3.2. Arquitetura de Software 25

• Testável: Significa que as regras de negócios do sistema possam ser testadas sem interfe-
rência de qualquer elemento externo (Ex: Banco de Dados, servidor web).

• Independente de qualquer agente externo: A aplicação não deve saber/conhecer agen-

tes do mundo externo.

• Independente de UI (User Interface): A arquitetura deve ser independente da UI pois

dessa forma caso ela mude não existe a necessidade de alterar o resto do sistema.

• Independente do banco de dados: As regras de negócios devem estar desvinculadas a

regra de negócio, pois assim permite a possível troca de banco de dados.

Figura 6 – Diagrama Arquitetura limpa.

Fonte: (MARTIN, 2018)

Como mostra a figura 6 a Clean Architecture é dividida em camadas, a seguir é descrito

brevemente o que cada uma delas significa.

• Camada de Entidades: Contêm as regras de negócios de domínio do sistema, onde é

armazenado a lógica da aplicação, classes etc. É a camada com menos propensão a mudar
quando algum elemento externo é alterado (MARTIN, 2018).

• Camada de Casos de Uso: Contêm as regras de negócios da aplicação, sendo que os

casos de uso são como links direcionando o tráfego de dados para as entidades (MARTIN,
2018).
26 Capítulo 3. Engenharia de Software

• Camada de Adaptadores de Interface: São responsáveis por fazer a conexão/comunicação

entre as entidades externas do sistema, nesta camada se encontram os elementos de cone-
xão com os banco de dados, MVC (Model-View-Controller) da aplicação, etc (MARTIN,
2018).

• Camada de Estruturas e Drivers: É a camada mais externa, que pode ser composta por
estruturas da web, banco de dados, UI, entre outros.

No canto inferior direito é mostrado um exemplo de como funciona a comunicação dos

controladores e apresentadores com os casos de uso. Na hipótese de um caso de uso precisar
chamar um apresentador é utilizada a técnica de inversão de dependência para não violar a
regra de dependência, essa regra diz que as dependências devem somente acontecer de fora
para dentro, sentido mostrado na figura 6.

3.3 A Web
A palavra web significa rede, no contexto de computação a web é basicamente uma rede
que conecta computadores. A web fornece diversos dados, informações, análises, blogs, tudo
isso poderia ser instalado pelo usuário e ter um programa para cada coisa em específico. Em
vez de instalar vários programas no computador, é utilizado um navegador web para acessar
esses serviços (RICHARDSON; RUBY, 2007). O navegador recebe códigos HTML enviados
pelo servidor e os interpreta de forma gráfica. A web se baseia no protocolo HTTP, XML e mais
recentemente JSON.
Segundo (WEBBER; PARASTATIDIS; ROBINSON, 2010) REST é um estilo de arqui-
tetura utilizado na Web. Essa arquitetura foca em construir aplicações distribuídas que podem
ser escaladas, com baixo acoplamento e que podem fornecer serviços que podem ser compostos
por outros serviços.
 27

4 Predição de qualidade de código

Nesta seção são apresentados trabalhos relacionados a temática desenvolvida neste tra-
balho, na tabela a seguir é apresentada a lista de artigos contidos neste capítulo de revisão da
literatura, a tabela referência o artigo e o ano de publicação.

Tabela 2 – Informações dos artigos citados nesta seção

Artigo Ano de Publicação

(LEMOS, 2019) 2009
(MUNAIAH et al., 2017) 2017
(AL-JAMIMI; AHMED, 2013) 2013
Fonte: O autor

O trabalho de (LEMOS, 2019) propõe uma investigação, para verificar se algoritmos

de classificação são capazes de encontrar diferenças entre códigos que seguem boas práticas,
e aqueles que não seguem. No estudo foram utilizadas métricas de software para avaliar se
um trecho de código segue ou não, boas práticas. Os algoritmos de ML realizam a etapa de
aprendizado com base no conjunto de métricas citado anteriormente.
Para realização da pesquisa o autor reuniu uma quantidade considerável de métodos
classificados e pré rotulados como engineered (métodos que seguem boas práticas) e non-
engineered (que não seguem boas práticas). A partir da base de dados foi possível extrair mé-
tricas específicas de cada trecho para serem usadas no modelo de classificação, para que em
seguida fosse possível verificar possíveis diferenças entre as duas classes de código.
O estudo mostra que o classificador atingiu boa precisão (acima de 80%), o que indica
que existem padrões entre códigos engineered que distinguem do padrões de código encontra-
dos em métodos non-engineered.
(MUNAIAH et al., 2017) propõe uma ferramenta capaz de classificar projetos contidos
no GitHub, evidenciar projetos sólidos -seguem boas práticas de engenharia de software-, da-
queles que não seguem boas práticas. Como citados pelos autores, o GitHub hospeda milhões de
repositórios, que por sua vez podem ser muito úteis para pesquisadores, porém ainda é limitado
a forma de separar bons repositórios. A pesquisa de (MUNAIAH et al., 2017) visa justamente
suprir essa necessidade com sua ferramenta.
Os pesquisadores consideram, na classificação, o projeto como um todo, levando em
conta as dimensões da tabela 3. As dimensões são como métricas, utilizadas para classificar se
um projeto é sólido ou não.
No trabalho de (MUNAIAH et al., 2017) foram utilizados dois métodos de classificação
28 Capítulo 4. Predição de qualidade de código

Tabela 3 – Dimensões consideradas por (MUNAIAH et al., 2017)

dimensão Descrição
D1 Arquitetura, como evidência da organização do código.
D2 Comunidade, como evidência de colaboração.
D3 Integração contínua, como evidência de qualidade.
D4 Documentação, como evidência de sustentabilidade.
D5 História, como evidência de evolução sustentada.
D6 Problemas, como evidência de gerenciamento de projetos.
D7 Licença, como prova de responsabilidade.
D8 Teste de unidade, como evidência de qualidade.
Fonte: O autor

o random forest e um classificador baseado em pontuação. O modelo random forest obteve um

melhor desempenho apresentando precisão de 82% e recall de 83%, rodando com a base de
dados Utility (repositórios com propósito geral).

Considerações
Como exposto no trabalho de (AL-JAMIMI; AHMED, 2013) e citado por (LEMOS,
2019) existem muitas possibilidades de estudos na área de engenharia de software que podem
ser abordadas com algoritmos de IA e ML, e isso se dá pois apenas mais recentemente surgiram
trabalhos utilizando IA no contexto de Engenharia de Software.
Neste trabalho de pesquisa será então usado como base o trabalho desenvolvido por
(LEMOS, 2019). A ideia é utilizar o modelo implementado pelo autor, para construir uma fer-
ramenta (sistema web) que possibilite os usuários usufruírem dos resultados obtidos por (LE-
MOS, 2019) para classificação de código de funções através do sistema web.
 29

5 Aplicação Web para a predição de

qualidade de código de funções

O desenvolvimento das atividades foram divididas em cinco etapas, abaixo está listado
as etapas executadas para a conclusão do trabalho.
• Etapa 1: Módulo de extração de métricas - Rodar o código que extrai as métricas de
funções e encontrar um meio de executar esse código através do TS.
• Etapa 2: Modelo de classificação de código de funções - Rodar o código que treina o
modelo de classificação e implementar uma função em Python que carrega o modelo de classi-
ficação e executa o mesmo.
• Etapa 3: Desenvolvimento do Back-end em TS utilizando clean architecture.
• Etapa 4: Implementação do Front-end da aplicação.
• Etapa 5: Teste da aplicação web.
Os códigos desenvolvidos nas etapas mencionadas anteriormente, podem ser acessados
em https://github.com/cunhafelipe098/web-application-for-classifying-methods-in-java-language.git.

5.1 Módulo de extração de métricas

Nesta etapa do projeto foi realizada uma análise do código do extrator de métricas para
verificar as possibilidades de utilizá-lo para extrair as métricas de código.
A ideia foi utilizar este código pois já estava desenvolvido. Após a análise de viabilidade
de utilização foi concluído que seria gerado um arquivo executável do código (arquivo .jar).
Foi utilizada a IDE Eclipse para gerar o executável do extrator de métricas. O arquivo
.jar é executado via chamada de sistema ao Linux pelo back-end que foi escrito em TS. Na
chamada ao extrator é passada a referência de uma função e após a execução são retornados os
valores das métricas juntamente com seus nomes.
No back-end é utilizado o comando ’exec’ do nodeJs para fazer a chamada de sistema.
Foi utilizada a seguinte linha de código:
• await exec(‘java -jar dir/MetricExtractor.jar dir/FunctionSamples.txt dir‘)
Na figura 7 é possível observar a simplificação ao gerar o executável do projeto (extrator
de métricas de código), dessa forma basta executar o arquivo ’MetricExtractor.jar’.
30 Capítulo 5. Aplicação Web para a predição de qualidade de código de funções

Figura 7 – Diretório de pastas do projeto do extrator e do executável (.jar)

Fonte: O autor

5.2 Modelo de classificação de código de funções

O código utilizado para gerar o modelo de classificação foi refatorado a partir do código
desenvolvido por (LEMOS, 2019), no trabalho em questão, era feito a iteração entre um con-
junto de diferentes classificadores, a alteração realizada foi remover a iteração entre as diferen-
tes técnicas de classificação e passar a executar apenas o método que teve melhor desempenho
no trabalho de (LEMOS, 2019), nesse caso o algoritmo Random Forest.
Também foi adicionado no código o ’pickle’, biblioteca python utilizada para serializar
o modelo já treinado.
O ’pickle’ salva o modelo de classificação em um arquivo com extensão ’.sav’, esse
arquivo pode ser carregado em memória pelo pickle e assim retira a necessidade de ter que
treinar o modelo toda vez que for utilizado, pois ele é salvo no formato .sav já treinado.
Na figura 8 é possível observar o script que compõe o módulo de classificação, esse
script é executado pelo back-end de forma semelhante ao extrato de métricas citado no tópico
anterior (chamada ao sistema com o comando ’exec’). O script da figura 8 basicamente recebe
as métricas de software, transforma a entrada em array e então carrega o modelo de classi-
ficação com o auxílio do ’pickle’. O array criado é então submetido ao modelo para obter a
classificação, a saída é escrita em um arquivo de output.
5.3. Back-end da aplicação 31

Figura 8 – Script Python que carrega o modelo de classificação

Fonte: O autor

5.3 Back-end da aplicação

O back-end foi implementado na linguagem TS utilizando Clean Architecture. A seguir
na imagem 9 é apresentado o diagrama da arquitetura limpa, ao lado direito se encontra o
diagrama da implementação baseada na Clean Architecture. É possível observar a disposição
das camadas do diagrama da aplicação, em comparação a abstração genérica da arquitetura.
As camadas da aplicação desenvolvida equivalem com as da Clean Architecture, a ca-
mada em azul seria a de frameworks and Drivers, em verde a de Interface Adapters, em verme-
lho a implementação da camada de Use Cases contida no domínio da aplicação. Por se tratar
de uma ferramenta simples que apenas visa fornecer a classificação do código de funções, não
é necessário a camada de entities. A Clean Architecture foi implementada para desacoplar os
módulos de extração e classificação. A figura 11 apresenta com mais detalhes as camadas e suas
divisões em nível de diretórios.

Figura 9 – Diagrama Arquitetura limpa ao do diagrama do back-end da aplicação

Fonte: O autor

A nível de organização de diretórios a aplicação ficou organizada da seguinte forma 10.

Na raiz do projeto possuem duas pastas, sendo a pasta ’web’ destinada para o desenvolvimento
32 Capítulo 5. Aplicação Web para a predição de qualidade de código de funções

da interface web, já a pasta ’server’ para o desenvolvimento do back-end da aplicação.

Descendo um nível, dentro da pasta ’server’ se encontram os módulos de extração e
classificação. A implementação do back-end está localizada dentro da pasta ’src’, essa pasta
foi organizada de acordo com as camadas da Clean Architecture. A seguir é descrito cada uma
delas com mais detalhes.

Figura 10 – Organização dos diretórios da aplicação

Fonte: O autor

A pasta useCase compõe a camada de domínio, contendo as implementações dos casos

de uso e as definições das interfaces do domínio. Na imagem 11 é apresentado como cada
camada está organizada. Em useCase é definida as interfaces de conexão que são implementadas
pela camada de Interface Adapters.
As camadas Presentation e a Infra compõem a camada de Interface Adapters, a comu-
nicação com os módulo de extração de métricas e de classificação estão definidos na pasta
’Infra’. Tanto o classificador quanto o extrator, implementam contratos definidos em ’use-
Case/contracts’. Em presentation é implementado o fluxo entre o Express (framework web,
fornece serviços http) e os casos de uso da aplicação.
5.3. Back-end da aplicação 33

Figura 11 – Listando por camadas

Fonte: O autor

Na imagem 12 é possível perceber como a aplicação fica desacoplada de framework ou

tecnologias fora do domínio da aplicação. O extrato e classificador, assim como o express estão
desacoplados do sistema, tornando a substituição ou remoção desses componentes facilitada.
É utilizado a inversão de dependência para que o fluxo da Clean Architecture seja res-
peitado e uma camada mais interna desconheça as camadas mais externas. Os balões em pon-
tilhados representam as interfaces, já os de linha cheia são as implementações. Em vermelho
estão os casos de uso da aplicação, neste caso, responsáveis por extrair as métricas de software
e classificar. Perceba que os casos de usos estão desacoplados dos módulos de classificação e
extração.
A camada ’main’ em cinza é a camada que possui acoplamento, isso é para que todas
as demais camadas sejam implementadas sem acoplamento. É utilizado nessa camada o design
pattern ’Factories’ que instância os módulos do sistema e os injeta nos respectivos módulos
subsequentes fazendo a composição.
34 Capítulo 5. Aplicação Web para a predição de qualidade de código de funções

Figura 12 – Arquitetura do back-end

Fonte: O autor

5.4 Front-end da aplicação

Nesta etapa foi desenvolvido a interface da aplicação, foi utilizado o framework ReactJS
para o desenvolvimento do front-end e um cliente http (axios) para conectar ao back-end.
A interface foi implementada para facilitar a utilização da ferramenta. O usuário sub-
mete o código de função em um input de texto e recebe como retorno a classificação e a lista
das métricas de software com os respectivos valores.
A seguir é possível observar um print da interface web. O front-end é composto por
apenas uma pagina, que por sua vez é composta por vários componentes menores.
O front-end é a interface direta com o usuário, a seguir na imagem 13 é apresentado o
fluxo que o código da função é submetido até sua classificação.
O usuário submete sua função pelo front-end através de um input de texto, esse dado
é enviado ao back-end pelo cliente http. No back-end a requisição é tratada e então submetida
5.4. Front-end da aplicação 35

ao módulo de extração de métricas que retorna uma coleção de métricas com seus respectivos
valores. Em seguida, as métricas de software são fornecidas ao classificador que retorna a clas-
sificação da função. Após a classificação, a requisição é respondida contendo a classificação da
função e as métricas. Por fim essas informações são apresentadas na tela para o usuário.

Figura 13 – Fluxo até a classificação do código

Fonte: O autor
36 Capítulo 5. Aplicação Web para a predição de qualidade de código de funções

5.5 Teste e retorno da aplicação

Nesta seção, são apresentadas duas funções que foram submetidas ao sistema, sendo que
uma delas foi implementada seguindo boas práticas e a outra não. Ambas as funções executam a
mesma funcionalidade, o que muda é a forma que foram implementadas. Este exemplo também
foi utilizado no trabalho de (LEMOS, 2019), é evidente a diferença entre as implementações.
A primeira função 14 é a que não segue boas práticas, ela implementa o método re-
place, já a outra função faz a chamada ao método replace do Java. A função que não segue
boas práticas possui algumas verificações que podem dificultar os testes de unidade, apresenta
maior complexidade, possui responsabilidades que poderiam ser implementadas em mais de
uma função com responsabilidades únicas. A outra função faz uma chamada no método replace
da linguagem, o que é boa prática por já ser um método validado (MARTIN; COPLIEN, 2009).

Figura 14 – Não segue boas práticas

Fonte: O autor
5.5. Teste e retorno da aplicação 37

Figura 15 – Segue boas práticas

Fonte: O autor

A imagem 16 apresenta o retorno do sistema, como já foi mencionado, é retornado a

classificação e a lista de métricas com seu respectivo valores. Também contém a descrição para
facilitar a leitura.
Como esperado, a função da figura 14 foi classificada pelo sistema em não projetada, o
retorno está à esquerda da imagem 16. A função da imagem 15 foi classificada como projetada,
seu retorno é o da direita da figura 16.

Figura 16 – Retorno do sistema - função projetada e não projetada

Fonte: O autor
6 Conclusão

A tecnologia se encontra em uma crescente expansão como é exposto por (ROSER;

RITCHIE, 2019), apresenta dados de avanços na computação e em outras áreas. No contexto
de computação, também é observado um grande avanço na inteligência artificial. Na área aca-
dêmica um crescente número de novas publicações e ganhando espaço na indústria através de
chatbots, análises de sentimentos, e muitas outras aplicações.
Os avanços na IA gera um novo campo de pesquisa nas diversas áreas. Os estudos e
possibilidades em engenharia de software utilizando IA é como um terreno fértil, possuindo
tarefas que podem ser abstraídas e formuladas como problemas de ML (LEMOS, 2019). Isso se
dá, pois apenas mais recentemente surgiram trabalhos utilizando IA no contexto de Engenharia
de Software.
Este trabalho contribui com os avanços citados e com a pesquisa realizada por (LEMOS,
2019). Desenvolvendo uma aplicação web que possibilita classificar códigos de funções como
projetados ou não. A aplicação fornece uma estimativa da qualidade do código, através das
métricas de software. Estimativa que pode servir como base para os desenvolvedores e um
indicativo de possíveis refatorações.
No tocante a implementação da ferramenta web, foi proposto uma arquitetura bem defi-
nida, boas práticas de programação e clean code. As considerações anteriores foram colocadas
como requisitos da aplicação, pensando em um projeto que possibilita o surgimento de novas
funcionalidades e seja resistente à evolução das tecnologias.
Na intenção de alcançar os requisitos propostos, foi adotado a Clean Architecture como
arquitetura do back-end da aplicação. Tendo em vista as vantagens fornecidas e os aspectos
semelhantes aos objetivos do trabalho. Neste caso, desenvolver uma interface web que fosse
desacoplada dos modelos de classificação de código de funções, pois esses podem sofrer evo-
luções de acordo com o crescimento da IA.
Com base nos resultados apresentados pela aplicação, pode ser listado alguns trabalhos
futuros, a fim de dar sequência no desenvolvimento da ferramenta e fornecer novas possibilida-
des.
Um dos incrementos interessante para a ferramenta, seria a pesquisa e implementação de
novos modelos de classificação. Sendo estes mais rápidos ou que apresentem resultados ainda
melhores que o modelo utilizado. Outra melhoria pode ser o desenvolvimento de modelos que
classifiquem código de funções escritos em outras linguagens além do Java.
Ainda em trabalhos futuros, pode ser citado a melhoria na parte de análise do retorno
do sistema ao usuário. Caso um código seja classificado como não projetado, a ferramenta pode
 39

fornecer indícios mais concretos do motivo dessa classificação e dar sugestões do que refatorar
no código submetido. As análises podem ser baseadas no cruzamento das métricas de software
ou na definição de um range para que as métricas respeitem respectivamente.
Apesar de apresentar bons resultados, a ferramenta é apenas a ponta do Iceberg no
universo de possibilidades. Tanto em aspectos do crescimento da ferramenta, quanto em integrar
avanços de pesquisas em ferramentas acessíveis à comunidade.
Por fim, o objetivo deste trabalho foi contemplado, fornecendo uma interface e inte-
grando as etapas da classificação da pesquisa realizada por (LEMOS, 2019). Também contribui
como uma interface entre avanços da área de pesquisa em IA, através de um aplicação web
guiada por conceitos de Engenharia de Software.
 Referências

AL-JAMIMI, H. A.; AHMED, M. Machine learning-based software quality prediction

models: state of the art. In: IEEE. 2013 International Conference on Information Science and
Applications (ICISA). [S.l.], 2013. p. 1–4. Citado 2 vezes nas páginas 27 e 28.

BASS, L.; CLEMENTS, P.; KAZMAN, R. Software architecture in practice. [S.l.]:

Addison-Wesley Professional, 2003. Citado na página 24.

BATISTA, G. E. d. A. P. et al. Pré-processamento de dados em aprendizado de máquina

supervisionado. Tese (Doutorado) — Universidade de São Paulo, 2003. Citado na página 16.

CARUANA, R.; NICULESCU-MIZIL, A. An empirical comparison of supervised learning

algorithms. In: Proceedings of the 23rd international conference on Machine learning. [S.l.:
s.n.], 2006. p. 161–168. Citado 2 vezes nas páginas 16 e 22.

FACELI, K. et al. Inteligência artificial: uma abordagem de aprendizado de máquina. [S.l.]:

LTC, 2011. Citado 4 vezes nas páginas 17, 18, 20 e 21.

FENTON, N.; BIEMAN, J. Software metrics: a rigorous and practical approach. [S.l.]: CRC
press, 2014. Citado na página 22.

HAMILTON ONTARIO, C. S. H. M. U. Neural networks and learning machines. In: Neural

networks and learning machines / Simon Haykin.—3rd ed. [S.l.: s.n.]. Citado 2 vezes nas
páginas 18 e 19.

JR, D. W. H.; LEMESHOW, S.; STURDIVANT, R. X. Applied logistic regression. [S.l.]: John
Wiley & Sons, 2013. Citado na página 20.

KLEINBAUM, D. G. et al. Logistic regression. [S.l.]: Springer, 2002. Citado na página 20.

LEMOS, O. A. L. Learning engineered code from software quality metrics. 2019. Citado 8
vezes nas páginas 13, 14, 27, 28, 30, 36, 38 e 39.

MARTIN, R. C. Clean architecture: a craftsman’s guide to software structure and design.

[S.l.]: Prentice Hall, 2018. Citado 3 vezes nas páginas 24, 25 e 26.

MARTIN, R. C.; COPLIEN, J. O. Clean code: a handbook of agile software craftsmanship.

Upper Saddle River, NJ [etc.]: Prentice Hall, 2009. ISBN 9780132350884 0132350882. Dis-
ponível em: <https://www.amazon.de/gp/product/0132350882/ref=oh details o00 s00 i00>.
Citado na página 36.

MINELLI, R.; MOCCI, A.; LANZA, M. I know what you did last summer-an investigation
of how developers spend their time. In: IEEE. 2015 IEEE 23rd International Conference on
Program Comprehension. [S.l.], 2015. p. 25–35. Citado na página 12.

MONARD, M. C.; BARANAUSKAS, J. A. Conceitos sobre aprendizado de máquina. Sistemas

inteligentes-Fundamentos e aplicações, Manole Ltda, v. 1, n. 1, p. 32, 2003. Citado na página
16.
Referências 41

MUNAIAH, N. et al. Curating github for engineered software projects. Empirical Software
Engineering, Springer, v. 22, n. 6, p. 3219–3253, 2017. Citado 3 vezes nas páginas 9, 27 e 28.

PRESSMAN, R.; MAXIM, B. Engenharia de Software-8ª Edição. [S.l.]: McGraw Hill Brasil,
2016. Citado na página 24.

RICHARDSON, L.; RUBY, S. RESTful Web Services. Beijing: O’Reilly, 2007. ISBN
978-0-596-52926-0. Disponível em: <https://www.safaribooksonline.com/library/view-
/restful-web-services/9780596529260/>. Citado na página 26.

ROSER, M.; RITCHIE, H. Technological progress. Our World in Data, 2019.

Https://ourworldindata.org/technological-progress. Citado na página 38.

ROTH, L. M. Understanding architecture: Its elements, history, and meaning. [S.l.]: Routledge,
2018. Citado na página 24.

WEBBER, J.; PARASTATIDIS, S.; ROBINSON, I. REST in practice: Hypermedia and

systems architecture. [S.l.]: "O’Reilly Media, Inc.", 2010. Citado na página 26.