Abstract— Software systems evolve through the composition of their modules. However, the complexity associated with the composition properties emerges as an extremely favorable factor for unwanted code changes. In a parallel context, several studies indicate that the occurrence of code anomalies also generates unwanted changes in the source code. Code anomaly is associated with undesirable symptoms that affect negatively the program structure. Apparently, composition properties and code anomalies share similar characteristics. However, there are no studies that analyze if and how composition properties are related to code anomalies occurrence. This paper presents a preliminary investigation about the impact of composition properties on code anomalies. Our investigation was developed across 6 versions of an evolving software system. Our preliminary findings indicate that variations on composition properties reflect directly on code anomalies occurrence.
Keywords— Code Anomalies, Composition Properties, Software Evolution.
I. INTRODUÇÃO
CÓDIGO fonte de sistemas de software em evolução
tendem a sofrer sucessivas e constantes modificações [1]. De acordo com Fowler [1], programadores modificam o código sem possuir, na grande maioria dos casos, a compreensão completa do projeto. Esta falta de compreensão associada a um mau planejamento contribui para que tais modificações se tornem portas de entrada para problemas estruturais de código em evolução, promovendo a sua instabilidade [2].Modificações não planejadas possuem um efeito acumulativo ao longo da evolução do código e emergem como uma consequência direta da falta de gerenciamento da complexidade associada à composição de seus elementos [2]. O termo composição refere-se à união de dois ou mais elementos de código, tais como atributos, métodos ou qualquer outra forma de declaração [2]. 1
Na verdade, a complexidade das composições de código está associada, principalmente, às suas propriedades, as quais nem sempre estão explícitas ao programador [2]. O escopo e a volatilidade das composições são exemplos de tais propriedades. O escopo de uma composição delimita os elementos de código afetados pela mesma. Enquanto que a volatilidade de uma composição representa as dependências quebradas durante a preparação de código para que a composição funcione apropriadamente.
Assim como as propriedades de composição, anomalias de
________________________
F. Torres, Universidade do Estado do Rio Grande do Norte, Mossoró, Rio Grande do Norte, Brasil, felipetorres@uern.br.
código, que nada mais são do que sintomas indesejados na estruturação do código, também têm sido responsáveis por mudanças não planejadas no código fonte das aplicações [3]. Neste contexto, vários trabalhos realizados propõem ou estudam estratégias de detecção de anomalias [4], [5], [6] e [7]. Porém, nenhum desses estudos investiga se as propriedades estão relacionadas com a ocorrência de anomalias e como esta relação se concretiza. Por exemplo, o aumento das responsabilidades de um módulo aumenta o seu escopo e ao mesmo tempo evidencia a ocorrência de uma das anomalias mais conhecidas na literatura, chamada God Class [1]. No entanto, não há estudos que analisem se e como as propriedades da composição impactam sobre o surgimento de anomalias de código.
Neste sentido, através da análise das propriedades de composição buscamos mapear a ocorrência de anomalias de código. Consideramos que um completo entendimento sobre a correlação existente entre as propriedades de composição e anomalias pode fornecer informações para que programadores possam evoluir sistemas de software de maneira mais estável (i.e, sem muitas modificações indesejadas), monitorando as propriedades da composição e, consequentemente, minimizando o surgimento de anomalias de código.
Este artigo investiga de forma pioneira a relação existente entre propriedades de composição e anomalias de código. Para tanto, realizou-se uma investigação utilizando um sistema de software em evolução, denominado MobileMedia [8] (Seção III). O trabalho foi desenvolvido tomando por base a literatura existente sobre o tema (Seção III) e um planejamento criterioso dos procedimentos (Seção III). Os nossos resultados indicaram a existência de uma relação direta entre as propriedades de composição e a ocorrência de anomalias (Seção IV). Os trabalhos relacionados, as ameaças à validação e as conclusões do estudo são apresentados nas Seções V, VI e VII.
II. REVISÃOLITERÁRIA A. Propriedades de Composição
Elementos de código podem se relacionar direta ou indiretamente entre si. Quando dois ou mais módulos de um programa estão ligados, eles formam uma composição de código [2]. Esta ligação ocorre através de dependências entre os seus elementos de código, nem sempre explícitas, e que envolve diferentes quantidades e tipos de elementos, tais como, classes,
F. Dantas, Universidade do Estado do Rio Grande do Norte, Natal, Rio Grande do Norte, Brasil, franciscodantas@uern.br.
Corresponding author: F. Torres
A Preliminary Investigation Towards the Impact
of Composition Properties on Code Anomalies
F. Torres and F. Dantas
classes abstratas, interfaces e métodos [2] (ver Fig. 1).
Neste cenário, à medida que o código é composto e evolui, surge a necessidade de monitorar as propriedades associadas às composições. Em nosso estudo, as propriedades de composição estudadas foram: o escopo e a volatilidade das composições [2]. De acordo com [2], o escopo das composições refere-se ao mapeamento dos elementos envolvidos na composição. Já a volatilidade quantifica as dependências que foram quebradas como forma de preparação para receber uma nova composição de código.
Figura 1. Cenário de Composição.
Na Fig. 1, o escopo da composição destacado pela área tracejada compreende as classes sombreadas. Isto significa que para tal composição acontecer, elementos de código das classes sombreadas foram afetados. Por outro lado, a volatilidade da mesma composição quantifica o número de alterações realizadas nas classes sombreadas para que a composição fosse realizada.
O impacto das propriedades do código de composição sobre a estabilidade (i.e., número de mudanças) do código foi estudado de forma pioneira por [2]. De acordo com uma análise feita por [2], alguns fatores de instabilidade tem uma forte correlação com o escopo e a alta volatilidade das composições. Isso acontece principalmente porque a propagação de mudanças nos elementos da composição é delimitada pela própria composição de código e é medida pelo escopo. Em outras palavras, temos o seguinte: modificações realizadas em um determinado módulo tendem a ser propagadas para toda a composição e, eventualmente, serão quantificadas pelo escopo. Por outro lado, a volatilidade também é extremamente significativa para se referir à estabilidade, uma vez que quantifica a necessidade de manipulação de código para que uma composição seja adicionada. Sendo assim, estas propriedades foram utilizadas para analisar a ocorrência de problemas estruturais quando são realizadas mudanças em composições de código.
B. Anomalias de Código
Sintomas que indicam possível aparecimento de problemas estruturais são chamados de bad smells [1], ou anomalias de código [9]. Durante a evolução de um sistema de software, problemas estruturais criados em uma versão anterior poderão ser maiores e mais prejudiciais ao longo do processo evolutivo. De acordo com Fowler [1], o efeito acumulativo causado pela ocorrência destes sintomas torna mais árdua a leitura do código fonte, o que dificulta a sua compreensão, preservação e o torna mais complexo de ser modificado. Por consequência disso, mais rapidamente ele irá apresentar problemas estruturais e isso poderá interferir na estabilidade do sistema, uma vez que quanto mais necessária for a realização de mudanças no código fonte, maior será a probabilidade de que o programa se torne instável [10].
Divergent Change (DC), God Class (GC) e Shotgun Surgery (SS) são exemplos de anomalias de código [1]. A anomalia conhecida por Divergent Change [1] ocorre quando uma classe precisa ser modificada de diferentes formas para entrar em conformidade com alterações de naturezas distintas. Isto significa dizer que haverá muitas modificações em uma mesma classe e, portanto, tenderá a ser mais instável e mais propensa a erros, uma vez que estabilidade está associada à quantidade de mudanças [10]. Já a anomalia God Class tende a ser uma classe grande que centraliza muitas funcionalidades (responsabilidades) de um sistema ao mesmo tempo, o que leva a ser uma classe complexa [4]. Finalmente, a anomalia Shotgun Surgery [1] corresponde a uma classe cuja modificação poderá implicar muitas pequenas modificações em muitas outras classes do sistema, em forma de cascata.
Na Fig. 1, a classe MediaAccessor possui indicadores das três anomalias citadas. Conforme a Fig. 1, é possível notar que a classe MediaAccessor possui uma alta relevância para a composição de código apresentada. Sendo assim, possui uma alta interconexão de classes e qualquer alteração em seu código potencialmente afetará as outras classes com as quais está conectada. Logo, existe a possibilidade desta classe ter uma alta volatilidade também. Diante disto, resta saber se tais taxas de interconexão (escopo) e volatilidade são altas o suficiente para que a classe MediaAccessor apresente as anomalias dos tipos Divergent Change, God Class e Shotgun Surgery.
III. CONFIGURAÇÕESDEESTUDO A. Estudo de Caso: MobileMedia
Para o nosso estudo pioneiro selecionamos as versões Java da aplicação de software denominada MobileMedia [8]. O MobileMedia é uma linha de produto de software que fornece suporte para gerenciar (criar, apagar, visualizar, reproduzir, enviar) diferentes mídias (foto, música e vídeo) em dispositivos móveis. Durante sua evolução, a arquitetura inicial do núcleo foi sistematicamente enriquecida com recursos obrigatórios, opcionais e alternativos. As características principais são: criar/excluir mídia (foto, música ou vídeo), visualizar/tocar mídia e rotular mídia. Alguns recursos opcionais, entre outros, são: transferência de foto via SMS, contar e ordenar mídia, copiar mídia e definir favoritos.
Por ser um software com vários estágios de evolução conhecido na literatura e amplamente utilizado como uma ferramenta para estudos envolvendo anomalias de código e propriedades da composição, como visto em [11], [12], [13], [14] e [15], o MobileMedia foi escolhido como artefato de código para a análise de uma possível relação entre anomalias de código e propriedades da composição.
B. Procedimentos
O estudo foi dividido em três fases principais: (1) quantificação das propriedades de composição, (2) quantificação das anomalias e (3) análise da correlação existente entre elas. Na primeira fase, quantificamos as propriedades de composição (Seção II.A), através da aplicação das métricas propostas por [2] e apresentadas na Seção III.C, sobre as 6 versões do MobileMedia (Seção III.A), desenvolvidas em Java. A detecção de anomalias, sobre as mesmas versões, foi realizada através da ferramenta proposta por [16]. Para tanto, foram utilizadas as estratégias apresentadas na Seção III.C. Finalmente, analisamos a possível correlação existente entre as propriedades de composição e a ocorrência de anomalias (Seção IV).
C. Quantificação
Para iniciar a análise, foi necessária a construção de informações a partir de duas perspectivas: o mapeamento das propriedades de composições e das anomalias de código em todas as versões do MobileMedia (Seção III.A).
Para o mapeamento das composições foram utilizadas quatro métricas para quantificar tais informações: LoI (Local Impact) [2], GoI (Global Impact) [2] e CoV (Composition Volatility) [2], adaptadas para o contexto do paradigma orientado a objetos. As métricas LoI, GoI e CoV são descritas na Tabela I. O valor de LoI para a composição em destaque na Fig. 1 é igual a 7%. Este valor equivale ao número de elementos afetados pela composição, que é igual a 1 (MediaAcessor), sobre o total de elementos (módulos) do exemplo, que é igual a 13. O valor para GoI, neste exemplo, seria o mesmo valor de LoI, já que o GoI é igual ao somatório de LoI para cada composição e neste exemplo, temos apenas uma composição. A volatilidade associada à composição contabilizaria todas as dependências existentes entre os elementos que foram quebradas para promover a robustez da composição.
TABELA I
MÉTRICAS PARA PROPRIEDADES DE COMPOSIÇÃO
Métrica Propriedade de Composição
Definição da Métrica
LoI Escopo
A relação existente entre o número de elementos de programa afetados por uma composição divididos pelo total de elementos de programas.
GoI Escopo
Quantifica o escopo da composição através da relação existente entre o
número de todos os elementos afetados pelas composições existentes sobre o número total de elementos da composição.
CoV Volatilidade
Quantifica o número de dependências quebradas em uma composição enquanto o código está sendo preparado para que a composição em questão funcione apropriadamente. Para o segundo mapeamento, foram utilizadas as estratégias propostas por Silva [17]. O objetivo dessas estratégias é realizar a detecção de elementos do código considerando o comportamento evolutivo do mesmo. A Tabela II apresenta as estratégias propostas por Silva [17].
TABELA II
ESTRATÉGIAS DE DETECÇÃO DE ELEMENTOS DE CÓDIGO
Anomalia Estratégia de Detecção
Divergent Change
Se a classe depende de muitas outras classes de muitos distintos pacotes, é grande e, ao longo da história, a dependência a outros pacotes foi crescente, então, é uma possível anomalia Divergent Change.
God Class
Se a complexidade é grande ou tamanho e complexidade já eram grandes em passado recente e tais propriedades continuam crescendo, então, é uma possível anomalia God Class.
Shotgun Surgery
Se alterações na classe potencialmente afetam muitos métodos e muitas outras classes e muitas são as classes que herdam direta ou indiretamente desta classe, então, é uma possível anomalia Shotgun Surgery.
A partir das informações levantadas pela análise da quantificação das propriedades da composição (Tabela I) e da quantificação das anomalias (Tabela II), podemos avaliar a possibilidade de existência de uma correlação entre propriedades da composição e anomalias de código.
IV. DISCUSSÃO
A evolução de programas é guiada por atualizações regulares em seus módulos com o objetivo de atender a demanda por novos requisitos. Este processo é facilitado quando a evolução acontece de forma estável e livre de anomalias. Neste contexto, sendo o gerenciamento das propriedades de composição um fator determinante para o gerenciamento da estabilidade, a evolução do MobileMedia foi analisada e discutida sob a perspectiva da influência das propriedades de composição na
ocorrência de anomalias. A discussão é guiada pelas métricas definidas na Seção III.C.
Escopo global vs. Anomalias. Como podemos observar na Fig. 2, o escopo global das composições tende a se manter constante; enquanto que o número de ocorrências de anomalias tende a variar. Apenas as versões V2 e V3 apresentam o mesmo número de anomalias. Nas demais versões, há uma variação significativa. Enquanto GoI não variou de forma expressiva, o número de anomalias entre as versões cresceu em quase 10%. Esta falta de correlação se explica pelo fato do cálculo do escopo global considerar todas as composições existentes em cada uma das versões. Isto significa que os valores de GoI também consideram o escopo das composições dos módulos não infectados por anomalias.
Figura 2. Escopo Global vs. Anomalias.
Escopo dos módulos é um bom indicador da ocorrência de anomalias. Analisando isoladamente o escopo dos módulos anômalos, percebemos claramente a relação existente entre o escopo do módulo e a ocorrência de anomalias, através dos valores de LoI. A Fig. 3 ilustra este comportamento. Em particular, o módulo MediaAccessor (V6), apresenta-se infectado pelas anomalias do tipo Divergent Change, God Class e Shotgun Surgery, o que certamente explica o maior valor de escopo para V6.
Figura 3. Escopo Local vs. Anomalias.
De forma complementar, a análise isolada dos módulos de V6 indica que o módulo MediaAccessor se encontra entre os módulos de maiores escopos da versão. Os módulos MediaController e MediaListController também aparecem entre os módulos com maiores escopos, sendo o
primeiro também infectado pelas anomalias Divergent Change e God Class, e o segundo pela anomalia Divergent Change. Esta concentração dos módulos anômalos no maior nível do escopo é um indicador forte da relação existente entre as propriedades de composição e a ocorrência de anomalias.
Módulos voláteis tendem a ser anômalos. A Fig. 4 ilustra a variação da volatilidade dos módulos anômalos versão a versão. De acordo com os valores de CoV, os módulos com o maior número de anomalias instaladas foram também os que apresentaram o maior número de quebra de dependências ao longo do processo de evolução. Analisando os valores de CoV, podemos identificar que a volatilidade também se relaciona com a ocorrência de anomalias. Em particular, o módulo MediaAccessor foi ao mesmo tempo o módulo que sofreu mais quebras de dependências e o que possui as três anomalias da análise instaladas (DC, GC e SS).
Figura 4. Volatilidade vs. Anomalias.
V. TRABALHOS RELACIONADOS
Dantas et al. [2], conduziu um estudo pioneiro sobre o impacto das propriedades de composição código na estabilidade de sistemas de software em evolução, usando técnicas de programação avançadas. Segundo os autores, a estabilidade de sistemas é afetada negativamente pelos efeitos das propriedades de composição.
No campo das anomalias, Padilha [7] identificou que ainda falta conhecimento empírico quanto à eficácia de métricas de interesse na identificação de anomalias de código, apesar de já terem sido utilizadas em estudos experimentais. Em [7] foram investigadas se métricas de interesse podem fornecer indicadores úteis para a detecção de algumas anomalias de código, dentre elas, Divergent Change, God Class e Shotgun Surgery.
O estudo feito em [5] apresenta um sistema para detectar anomalias código arquitetonicamente relevantes e que ajuda os desenvolvedores a priorizarem a remoção de anomalias de acordo com uma classificação de anomalias. Já em [3] foi apresentado um estudo empírico sobre a influência de anomalias de código sobre os sintomas de degradação arquiteturais, analisando a relação entre anomalias de código e problemas arquiteturais.
Por fim, um estudo feito em [4] estava incluído a detecção de anomalias nas versões em evolução do MobileMedia, onde a utilização de estratégias de detecção formadas por métricas que consideram características do histórico de evolução foi proposta
0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1 1,1 0 1 2 3 4 5 6 7 8 9 10 V1 V2 V3 V4 V5 V6 GoI To ta l de Ano ma lia s Versões do MobileMedia Anomalias Escopo 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1 0 1 2 3 4 5 6 7 8 9 10 V1 V2 V3 V4 V5 V6 Lo I To ta l de Ano ma lia s Versões do MobileMedia Anomalias Escopo Local 0 1 2 3 4 5 6 7 8 9 10 11 12 0 1 2 3 4 5 6 7 8 9 10 V1 V2 V3 V4 V5 V6 CoV To ta l de Ano ma lia s Versões do MobileMedia Anomalias Volatilidade
e avaliada. Entretanto, a estratégia utilizada por Silva em [4] não obteve um resultado com 100% de acerto para a detecção, deixando margem para melhorias.
Neste contexto, muitos pesquisadores tem investigado o comportamento anômalo dos elementos de código [3], [4], [5], [6] e [7]. Em paralelo, trabalhos que analisam as propriedades da composição, como em [2], [12] e [18], têm sido reportados. Contudo, nenhum trabalho relaciona as propriedades da composição de código com a ocorrência de anomalias de código.
VI. AMEAÇASÀVALIDAÇÃO
Uma das ameaças mais relevantes do nosso estudo diz respeito à validade externa. Ameaças à validação externas são condições que não permitem a generalização dos resultados. A fim de minimizar esta ameaça, escolhemos uma aplicação já utilizada em outros estudos empíricos [8]. Esta aplicação é representativa de projetos do mundo real e possui um tamanho significativo. Além disso, ela contém ocorrências de anomalias e também possui cenários ricos para analisar as propriedades de composição sobre diferentes aspectos em um cenário evolutivo. Desta forma, através dela foi possível observar as diferenças entre os resultados. No entanto, ainda é necessário realizar outras avaliações com outras aplicações similares de modo a fornecer maiores evidências sobre as nossas conclusões.
VII. CONSIDERAÇÕESFINAIS
Este trabalho relatou uma investigação exploratória sobre a relação existente entre as propriedades de composição e as anomalias de código. Através deste estudo preliminar, foi possível adquirir conhecimento sobre a relação existente entre as propriedades de composição e a ocorrência de anomalias de código. Torna-se evidente que os programadores devem ter ciência do impacto que as propriedades de composição geram sobre o código e como gerenciá-lo de modo a minimizar a ocorrência de anomalias. Neste contexto, as propriedades de composição, escopo local e volatilidade, mostraram-se mais relacionados com ocorrência de anomalias. O escopo global, por considerar todas as composições de uma versão do software, afasta-se muito no que diz respeito a indicar a ocorrência de anomalias. Como trabalho futuro, vislumbramos a inclusão de novas aplicações para validar os resultados aqui apresentados, bem como a sugestão de heurísticas expressem o relacionamento existente entre as propriedades de composição com a ocorrência de anomalias de código.
AGRADECIMENTOS
Agradecimento à Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES) pelo financiamento de concessão de bolsa de estudos de pós-graduação, em nível de mestrado, ao autor correspondente Felipe Torres.
REFERÊNCIAS
[1] M. Fowler, K. Beck, J. Brant, W. Opdyke and D. Roberts, “Refactoring: Improving the Design of Existing Code”. 1. ed. [S.l.]: Addison-Wesley Professional, 1999.
[2] F. Dantas, A. Garcia and J. Whittle, “On the role of composition code properties on evolving programs”. In: ACM. Proceedings of the ACM-IEEE international symposium on Empirical software engineering and measurement. [S.l.], p. 291–300. 2012.
[3] I. Macía, R. Arcoverde, A. Garcia, C. Chavez and A. v. Staa, “On the relevance of code anomalies for identifying architecture degradation symptoms”. In: 16th European Conference on Software Maintenance and Reengineering. [S.l.], p. 277–286. IEEE Computer Society Washington, DC, USA, 2012.
[4] L. M. d. Silva, F. Dantas, G. Honorato, A. Garcia and C. Lucena, “Detecting modularity flaws of evolving code: What the history can reveal?”. Fourth Brazilian Symposium. In: IEEE. Software Components, Architectures and Reuse (SBCARS) [S.l.], p. 1–10. 2010.
[5] R. Arcoverde, I. Macía, A. Garcia and A. v. Staa, “Automatically detecting architecturally-relevant code anomalies”. In: IEEE PRESS. Proceedings of the Third International Workshop on Recommendation Systems for Software Engineering. [S.l.], p. 90–91. 2012.
[6] A. L. Silva, “Reuso de Estratégias Sensíveis a Domínio para Detecção de Anomalias de Código - Um Estudo de Múltiplos Casos”. Dissertação (Mestrado) - Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio). Disponível em: <http://www.dbd.puc-rio.br/pergamum/tesesabertas/1112618_2013_completo.pdf>. Agosto, 2013.
[7] J. Padilha, “Detecção de Anomalias de Código Usando Métricas de Software”. Dissertação (Mestrado) - UFMG, 2013.
[8] E. Figueiredo, N. Cacho, C. Sant’Anna, M. Monteiro, U. Kulesza, A. Garcia, S. Soares, F. Ferrari, S. Khan, F. Filho and F. Dantas, “Evolving software product lines with aspects”. In: IEEE. Software Engineering, p. 261–270. On 30th International Conference ACM/IEEE. ICSE’08. [S.l.], 2008.
[9] D. Albuquerque, A. Garcia, R. Oliveira, and W. Oizumi, “Detecção interativa de anomalias de código: Um estudo experimental”. In: Proceedings of Workshop on Software Modularity, WMOD2014. [S.l.: s.n.], 2014.
[10] D. Kelly, “A study of design characteristics in evolving software using stability as a criterion”. IEEE Transactions on Software Engineering, v. 32, n. 5, p. 315–329. 2006.
[11] K. Sethi, Y. Cai, S. Wong, A. Garcia and C. Sant'Anna, “From retrospect to prospect: Assessing modularity and stability from software architecture”. In: WICSA/ECSA 2009. Joint Working IEEE/IFIP Conference on Software Architecture, 2009 & European Conference on Software Architecture. [S.l.], p. 269–272. 2009.
[12] F. Dantas and A. Garcia, “Stability of product lines with composition filters: An exploratory study”. AOSD/ESCOT, v. 1, p. 32-40. Disponível em:
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.232.8623&re p=rep1&type=pdf>. 2010.
[13] D. d. L. Albuquerque, “Automatic detection of architectural violations in evolutionary systems”. Dissertação (Mestrado) - Universidade do Minho, Disponível em: <http://repositorium.sdum.uminho.pt/bitstream/1822/36779/1/eeum_di_di ssertacao_pg19789.pdf>. Maio, 2014.
[14] M. Kaur and P. Kumar, “Spotting the phenomenon of bad smells in mobilemedia product line architecture”. In: IEEE. Seventh International Conference on Contemporary Computing (IC3). [S.l.], p. 357–363. 2014. [15] W. N. Oizumi, A. F. Garcia, T. E. Colanzi, M. Ferreira and A. v. Staa, “On the relationship of code-anomaly agglomerations and architectural problems”. Journal of Software Engineering Research and Development, Springer, v. 3, n. 1, p. 1–22. 2015.
[16] I. Macía, C. Sant'Anna and A. v. Staa, “Detectando problemas de design em diagramas de classes: Um estudo experimental”. In: V Experimental Software Engineering Latin American Workshop (ESELAW). [s.n.]. 2008.
[17] L. M. d. Silva, “Uma Abordagem Sensível à História para Detecção de Anomalias de Código”. Dissertação (Mestrado) - Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio). Disponível em:
<http://www.maxwell.vrac.puc-rio.br/Busca_etds.php?strSecao=resultado&nrSeq=17163@1>. Agosto, 2010.
[18] F. Dantas, “Reuse vs. maintainability: Revealing the impact of composition code properties”. In: Proceedings of the 33rd International Conference on Software Engineering (ICSE), p. 1082–1085. Disponível em: <http://doi.acm.org/10.1145/1985793.1986001>. ACM. ISBN 978-1-4503-0445-0. New York, NY, USA, 2011.
Felipe Torres, Mestre em Ciência da Computação pelo
Programa de Pós-Graduação em Ciência da Computação (PPgCC) pela parceria entre Universidade do Estado do Rio Grande do Norte (UERN) e Universidade Federal Rural do Semi-Árido (UFERSA). Bacharel em Ciência da Computação pela UFERSA e ex-professor substituto da UFERSA. Atualmente é professor substituto da UERN. Suas pesquisas se concentram na grande Área de Engenharia de Software e desde 2011 trabalha com projetos de Startups de TI.
Francisco Dantas, Doutor em Informática pela Pontifícia
Universidade Católica do Rio de Janeiro, Rio de Janeiro/RJ, em colaboração com a Universidade de Lancaster, Lancaster/UK. É professor da Universidade do Estado do Rio Grande do Norte. Tem experiência na área de Ciência da Computação, com ênfase em Engenharia de Software, atuando principalmente nos seguintes temas: Técnicas Avançadas para Programação Modular, Linhas de Produto, Métricas de Software, Arquitetura de Software e Engenharia de Software Empírica.
