Avaliando Decises Subjetivas para Refatorao de Cdigo na Indstria

Paulo Srgio Medeiros dos Santos e Guilherme Horta Travassos,

COPPE/UFRJ, Universidade Federal do Rio de Janeiro, Brasil Caixa Postal 68511 CEP 21945-970 Rio de Janeiro, RJ {pasemes, ght}@cos.ufrj.br

Abstract. Refactoring plays a key role in maintaining the software product quality . However, refactoring decisions heavily rely on human factors because it depends on the examination of different characteristics present in the code structure. Aiming at investigating the characteristics which could affect developers refactoring decisions, an action-research based study was conducted. Contradicting previous findings, the regression models based on the system`s code metrics were able to explain from 64% to 89% of the refactoring decisions, and also provided evidence about the characteristics influencing the developer`s decision making. We believe the combination of obtained results by using regression models can be used as motivation for the construction of more effective tools to support refactoring decisions by software engineers. Keywords: refactoring; regression models; action research, experimental software engineering; field study in vivo study.

1 Introduo
Em um ambiente de desenvolvimento real, a necessidade de modificao e evoluo do software inerente ao processo de desenvolvimento e particularmente mais presente no processo incremental. Isto ocorre devido a melhorias aplicadas ao software, evoluo de requisitos ou construo de novos mdulos. Muitas vezes, estas necessidades podem levar ao decaimento da qualidade do software na medida em que o desviam do seu projeto inicial. A facilidade para a evoluo do software , neste contexto, um elemento central. Para Bennet e Rajlich [3], o que torna possvel a evoluo do software so a sua arquitetura e o conhecimento da equipe de desenvolvimento sobre o software, pois permitem que a equipe evolua o software sem atingir a sua integridade arquitetural. Tendncias recentes, como mtodos geis, apontam a refatorao de cdigo fonte como um mecanismo importante para garantir a possibilidade de evoluo do software. Segundo Fowler et al. [6], a idia central da refatorao redistribuir ou reescrever classes, variveis e mtodos na hierarquia de classes a fim de facilitar futuras adaptaes ou extenses. Em outras palavras, o objetivo da refatorao melhorar a estrutura interna do software mantendo o seu comportamento externo inalterado.

Neste sentido, a definio do momento correto da refatorao do cdigo decisiva, j que a escolha incorreta pode representar um retrabalho desnecessrio e pode trazer mais prejuzos do que benefcios. Esta definio normalmente subjetiva e baseada na intuio humana [6]. O presente trabalho estuda esta avaliao subjetiva da necessidade de evoluo do software, i.e. a refatorao de cdigo fonte. Dada a importncia do fator humano na deciso pela refatorao de cdigo fonte, a maior parte dos esforos de pesquisa tm se concentrado em ferramentas e mtricas de cdigo para apoiar este tipo de deciso [9]. Ainda assim, as motivaes subjetivas da deciso pela refatorao de cdigo fonte tm sido pouco estudadas, e existe um nmero limitado de estudos experimentais que tenha realizado anlise deste tema [7]. Particularmente no contexto industrial, os autores no tm conhecimento de nenhum trabalho que tenha investigado esta questo. Neste contexto, o principal objetivo deste estudo investigar quais caractersticas (fatores) durante a avaliao de um cdigo influenciam a deciso pela refatorao dos desenvolvedores. Para isto, uma avaliao do efeito da refatorao sobre as mtricas analisando-se as mtricas antes e depois da refatorao foi realizada e comparada com os fatores que influenciaram as decises dos desenvolvedores identificados a partir de modelos de regresso. Esta anlise foi feita no nvel de mtodos de classe em um cdigo orientado a objetos. Alm desta introduo, este trabalho possui mais duas sees introdutrias descrevendo a metodologia e o contexto de pesquisa. Aps, apresenta-se o planejamento do estudo e as suas intervenes. As duas sees seguintes trazem uma anlise dos resultados. Por fim, as consideraes finais destacando as contribuies, os resultados alcanados e as suas limitaes.

2 Metodologia de Pesquisa
O mtodo de pesquisa utilizado neste trabalho a pesquisa-ao. A pesquisa-ao tem a sua origem associada s primeiras prticas realizadas por Kurt Lewin na dcada de 1940 em psicoterapia. Atualmente, utilizada em diversas outras reas como, educao e negcios, mas tem sido pouco aproveitada em Engenharia de Software [13] ainda que possua caractersticas que so adequadas para a rea [12]. A pesquisa-ao definida como um tipo de pesquisa social com enfoque pragmtico a qual concebida e realizada em estreita associao com uma ao ou com a resoluo de um problema coletivo e no qual os pesquisadores e os participantes, representativos da situao ou do problema, esto envolvidos de modo cooperativo [15]. Embora no seja compatvel com a vertente de estudos controlados e com os pressupostos do experimentalismo (neutralidade do observador, isolamento de variveis, etc), a pesquisa-ao no deixa de ser uma forma de experimentao em situao real (in vivo) na qual pesquisadores intervm conscientemente [4]. Nela, os envolvidos no so reduzidos a meros participantes e desempenham um papel ativo. E a partir da observao e avaliao das transformaes realizadas, e tambm pela evidenciao dos obstculos encontrados durante o processo, h um ganho de informao a ser captado e restitudo como elemento de conhecimento. Para o estudo

descrito neste trabalho optou-se pela pesquisa-ao, pois se tratava de um projeto real onde os pesquisadores participavam da equipe de desenvolvimento. Em termos de processo, a pesquisa-ao normalmente contempla as seguintes etapas [2] (que sero descritas nas prximas sees): (1) Diagnstico: consiste em descobrir o campo de pesquisa, os interessados e suas expectativas sob uma perspectiva sistmica. Nesta etapa, existe ainda a definio do tema de pesquisa o qual representado atravs da designao do problema prtico e da rea do conhecimento a ser abordada (seo 3). (2) Planejamento: onde so definidas aes para o quadro diagnosticado (seo 5). (3) Tomada da ao: corresponde a implantao das aes planejadas (seo 6). (4) Avaliao: etapa onde se realiza a anlise dos efeitos das aes frente ao apoio terico utilizado como ponto de partida para a definio das aes (sees 7 e 8). (5) Aprendizagem: envolve a circulao da avaliao dos resultados entre os participantes e setores da organizao. Esta etapa no est contemplada no escopo deste artigo.

3 Contexto da Pesquisa
O projeto no qual esta pesquisa foi conduzida visa o desenvolvimento de um novo sistema de informao Web para gerenciamento das atividades de uma Fundao de Apoio a projetos de Cincia e Tecnologia. Trata-se de um projeto de grande porte que envolve diferentes setores da organizao, como: recursos humanos, financeiro, contabilidade, gerenciamento de projetos e protocolo. O projeto pde ser modularizado e desenvolvido seguindo um ciclo de vida incremental utilizando tecnologia Java e JavaServer Faces (JSF). Alm disto, a Fundao possui um modelo de referncia de processo baseado nos nveis G a C do MPS.br [14]. No momento deste estudo (novembro, 2008), a equipe do projeto era distribuda e possua trs projetistas e dois desenvolvedores no local da Fundao (equipe L) e mais seis desenvolvedores remotos em uma cidade distante 200km (equipe R). A experincia mdia com desenvolvimento da equipe L era de cerca de 7 anos (variando entre 3 e 15 anos), e da equipe R cerca 2,5 anos (variando entre 1,5 e 4 anos). A documentao detalhada referente aos estilos de arquitetura e padres de codificao utilizados no era um artefato previsto no processo de desenvolvimento. A maior parte da definio destes estilos e padres foi trazida da documentao oficial da Sun, mas houve algumas adaptaes e modificaes realizadas pela equipe de desenvolvimento. Como exemplo deste tipo de modificao, pode-se citar a criao de um mecanismo prprio para a validao de formulrios de entrada de dados no utilizando, neste caso, os recursos oferecidos pela tecnologia JSF. Em maro de 2008, poca do incio de um novo mdulo do projeto, foi integrada ao projeto a equipe R. Isto representou um aumento de cinco para onze profissionais. Estes novos integrantes da equipe R receberam treinamento durante dois dias. Durante o treinamento a tecnologia utilizada foi apresentada e aspectos relacionados a procedimentos de construo discutidos. Os seguintes assuntos foram abordados: A tecnologia Java e JavaServer Faces;

 Padro arquitetural Modelo-Viso-Controle, incluindo discusses sobre orientao a objetos, como encapsulamento e reutilizao atravs de herana; Regras de nomenclatura e organizao do cdigo fonte apresentados durante a (re)construo de um caso de uso anterior que foi utilizado como exemplo. Ainda que estas atividades de acompanhamento e treinamento tenham sido conduzidas, ao final da primeira iterao de construo do novo mdulo, membros mais experientes da equipe L identificaram problemas relacionados qualidade do cdigo fonte construdo pelos novos membros da equipe. Embora no desejado, este um comportamento que geralmente se observa nos projetos de software e ocorre, dentre outros motivos, devido inexperincia dos novos desenvolvedores no projeto [3]. Estes problemas estavam relacionados principalmente a no organizao do cdigo fonte de acordo com os padres de codificao e estilos arquiteturais tcitos esperados (j que no estavam documentados) pelos membros mais experientes. Diante deste cenrio, o tema de pesquisa pde ser definido como: estratgias para deteco de desvios em cdigo fonte relacionados falta de conhecimento sobre padres de codificao e estilos arquiteturais. A idia tentar utilizar tcnicas de refatorao como forma de identificar desvios de cdigo frente ao conhecimento tcito dos desenvolvedores experientes.

4 Trabalhos Relacionados
Em um estudo de pesquisa-ao, os trabalhos relacionados devem ser teis pesquisa no sentido de indicarem como o estudo deve ser conduzido. O trabalho de Mntyl [7] est diretamente relacionado e possui objetivo semelhante. Por isto, caso este trabalho fosse tambm um estudo controlado poderia ser considerado uma repetio dele. Assim, ser utilizado como base para comparao e anlise dos resultados. Outros dois trabalhos [5,8] so utilizados para compor o procedimento elaborado para a leitura do cdigo fonte pelos participantes (formulrio da seo 5.2). O trabalho de Dunsmore et al. [5] descreve uma tcnica de inspeo baseada em casos de uso a qual permite a leitura de cdigo orientado a objetos a partir do ponto de vista do seu modelo dinmico. Os passos da tcnica envolvem (1) a seleo de um caso de uso, (2) derivao de cenrios de uso a partir do caso de uso (ex., "salvar" e "cancelar" protocolo) e (3) a leitura dos mtodos das classes responsveis pela execuo do cenrio. Para categorizar as sugestes de refatorao foi utilizado Mntyl e Lassenius [8] (um trabalho posterior Mntyl [7]). Nele, os autores descrevem um estudo onde o objetivo foi entender o porqu os desenvolvedores entendem ser necessria a refatorao de cdigo. Trata-se de um estudo qualitativo onde foi requisitado aos participantes que registrassem o motivo para a necessidade de refatorao. Atravs da anlise dos registros feitos pelos participantes foi elaborada uma taxonomia de defeitos. Para permitir a utilizao da taxonomia dos desvios o seguinte passo foi includo na tcnica descrita anteriormente: (4) para cada mtodo, necessidades de refatorao devem registradas de acordo com o conhecimento prvio do desenvolvedor.

5 Planejamento do Estudo
O planejamento da pesquisa-ao passa por trs etapas. A primeira consiste em uma reviso da literatura onde trabalhos relacionados ao tema de pesquisa so estudados etapa descrita na seo anterior. A partir disto, o enfoque da ao da pesquisa fixado por meio da abordagem GQM [1] e os instrumentos utilizados definidos. 5.1 Enfoque da Ao Objetivo O objetivo analisar se caractersticas mensurveis de cdigo fonte podem explicar a avaliao subjetiva da necessidade de refatorao de cdigo com o propsito de caracterizar com respeito qualidade da predio1 das medidas do ponto de vista do engenheiro de software no contexto de sistemas de informao Web. Questes de Pesquisa O objetivo ser alcanado quando uma resposta for apresentada seguinte questo: Q.1. Quais so os fatores ou caractersticas do cdigo fonte que um desenvolvedor utiliza como base para identificar necessidades de refatorao e qual o seu efeito sobre mtricas de cdigo? Resultados Esperados A questo Q.1 possui as seguintes questes prticas associadas: Q.1.1 Qual o efeito da refatorao sobre as mtricas de cdigo? Q.1.2 Quais caractersticas do cdigo afetam a deciso dos desenvolvedores? Q.1.3 possvel categorizar as necessidades de refatorao de forma que reflita as caractersticas de qualidade do cdigo esperadas? As mtricas de cdigo sugeridas em Mntyl [7] (linhas de cdigo, nmero de parmetros, complexidade ciclomtica, nmero de mtodos remotos invocados, fanout e fan-in) sero utilizadas para a questo Q.1.1. As mtricas tambm sero utilizadas para a Q1.2 na medida em que representam diferentes aspectos estruturais do cdigo. As mtricas foram escolhidas baseadas no seu reconhecimento na literatura tcnica e no propsito de caracterizar os mtodos sob diferentes perspectivas. Para a Q.1.3 foi realizada uma atividade de categorizao junto aos desenvolvedores utilizando a taxonomia de Mntyl e Lassenius [8] (seo 7.1). 5.2 Instrumentos A Tabela 1 apresenta as informaes contidas no formulrio de discrepncias (sugestes de refatorao) utilizado pelos desenvolvedores para descrever as necessidades de refatorao do cdigo. Alm dos campos preenchidos pelos desenvolvedores, o formulrio contm ainda as etapas da tcnica que deveriam ser observadas no intuito de facilitar a leitura e entendimento do cdigo para Dunsmore et al. [5], a compre1

Qualidade da predio foi usada para o termo ingls predictability.

enso do cdigo facilitada pois a tcnica auxilia a manter o foco da leitura em um caso de uso por vez. Os passos 1, 2 e 3 foram retirados diretamente de [5] enquanto o campo 5 trazido de [8]. Os outros campos e passos criados no contexto deste trabalho.
Tabela 1. Contedo do formulrio de discrepncias (sugestes de refatorao) Passos da Tcnica 1. Selecione um caso de uso do projeto; 2. Derive cenrios de uso a partir do caso de uso (ex., "salvar" e "cancelar" protocolo); 3. Percorra os mtodos das classes responsveis pela execuo do cenrio. Verifique se os mtodos corretos esto sendo invocados e se o estado do cenrio est sendo mantido e manipulado da forma adequada e consistente pelo sistema; 4. Para cada mtodo, registre oportunidades de refatorao de acordo com o seu conhecimento prvio (ex., aninhamento excessivo, nomenclatura de variveis, organizao "visual" do cdigo, localizao, dentre outros). Campos do Formulrio 1. Caso de uso 2. Descrio do cenrio 3. Nome da classe 4. Nome do mtodo 5. Voc refatoraria este mtodo? (responda de 1 a 5 - 1 - No; 2 - Dificilmente; 3 - Talvez; 4 - Sim, mas apenas depois que o mtodo for evoludo; 5 - Sim, agora mesmo) Explique sua deciso na questo acima. Se a refatorao necessria, explique o qu deve ser mudado, como e o porqu. Se o mtodo estiver OK, explicite as qualidades desejveis que esto sendo atendidas incluindo padres de projeto. Se sua resposta talvez, tambm explique seu raciocnio. Se apropriado, mencione as linhas de cdigo envolvidas na sua explicao.

6 Aes
Inicialmente, a equipe R foi informada que problemas haviam sido observados no cdigo fonte, ressaltando que isto se devia a falhas de comunicao e aprendizado com o desenvolvimento distribudo. E, devido a isto, uma refatorao no cdigo seria realizada com intuito de mostrar a equipe como o cdigo deveria ser estruturado. Dois desenvolvedores da equipe L foram selecionados para realizar esta reviso e identificar necessidades de refatorao, ficando responsveis por diferentes casos de uso. O formulrio de discrepncias da Tabela 1 foi apresentado aos desenvolvedores que, ento, receberam instrues sobre como preench-lo. As instrues incluram tambm o foco da reviso que em linhas gerais se deveria buscar por desvios de cdigo segundo o que os desenvolvedores consideravam como padro de codificao ou estilo arquitetural utilizado no projeto. A descrio de desvio foi mantida genrica para manter a subjetividade da deciso pela refatorao e tentar capturar descries mais ricas em detalhes. Alguns exemplos foram discutidos utilizando o conhecimento prvio dos desenvolvedores sobre refatorao e conceitos sobre abstraes em orientao a objetos e linguagens de programao (herana, complexidade, legibilidade, manutenibilidade, dentre outros). Aps as instrues, a atividade foi iniciada e, ao seu trmino, os formulrios preenchidos foram enviados queles que construram os casos de uso.

Com base nas necessidades de refatorao identificadas e registradas nos formulrios, a equipe R foi instruda a refatorar o cdigo. Foi requisitado, ainda, que fosse feito o registro das verses (do sistema de controle de verso) dos arquivos fonte que estavam sendo refatorados e o tempo gasto com a refatorao de cada mtodo. Os responsveis pela construo dos casos de uso refatoraram o seu prprio cdigo, mas poderiam discordar com as necessidades de refatorao apontadas. Por fim, aps a refatorao do cdigo pela equipe R, foi solicitado aos desenvolvedores da equipe L que classificassem as diferentes necessidades de refatorao apontadas por eles, utilizando como base a classificao definida na taxonomia de defeitos.

7 Anlise dos Resultados

Nesta seo, a anlise dos efeitos da refatorao apresentada. Primeiro, sero analisados os valores das mtricas de cdigo antes e depois da refatorao. A idia verificar quais caractersticas do cdigo foram afetadas devido sua refatorao. Depois, uma anlise de regresso sobre as mtricas de cdigo empregada para estudar como as suas caractersticas afetaram as decises dos desenvolvedores. 7.1 Analisando as Mtricas de Cdigo Como mencionado anteriormente, cada desenvolvedor descreveu o porqu de cada necessidade de refatorao que sugeriu. A partir dessa descrio, a taxonomia de defeitos foi aplicada e adaptada em cima das descries relatadas pelos desenvolvedores. As categorias, assim como um resumo do efeito da refatorao sobre as mtricas de cdigo considerando cada categoria, so apresentadas na Tabela 2. Duas categorias novas surgiram no contexto deste estudo baixa coeso e cdigo no utilizado (sublinhadas na Tabela 2). Ao todo foram revisados 47 mtodos. Em 37 destes acorreu alguma indicao de refatorao. O tamanho mdio dos mtodos foi de 32 linhas de cdigo (com grande variao, = 34). Para analisar o efeito sobre as mtricas interessante dividir as sugestes em dois tipos: defeitos e melhorias os dois tipos esto separados na Tabela 2 por uma linha vazia. Em cada linha da Tabela 2, os valores foram calculados subtraindo-se o valor da mtrica antes e aps a refatorao e somados por categoria. Desta forma, valores negativos representam decrscimo do valor da mtrica. Apesar de no ter sido requisitado aos desenvolvedores, ambos detectaram defeitos no cdigo fonte durante a sua reviso. Grande parte destes defeitos, observando os comentrios feitos pelos desenvolvedores, estava relacionada a funcionalidades incompletas, ou seja, defeito do tipo omisso. Como conseqncia, possvel notar, por meio das mtricas na Tabela 2, que a correo dos defeitos aumentou o tamanho do cdigo e sua complexidade. Observando, agora, o efeito das sugestes de refatorao do tipo melhoria, percebe-se (totalizao da Tabela 2) que o resultado foi inverso ao dos ajustes dos defeitos. Nesse caso, a refatorao representou uma reduo do tamanho do cdigo, de sua complexidade e acoplamento (considerando as mtricas fan-in, mtodos remotos invocados e fan-out).

Tabela 2. Diferena das mtricas de cdigo antes e depois da refatorao

Categoria Defeito Algoritmo ruim Organizao interna ruim Pequenos problemas de estrutura Baixa Coeso Cdigo duplicado Excesso de variveis temporrias Cdigo no utilizado Legibilidade ruim Nome de mtodo ruim Identao inadequada Poucos comentrios Organizao de parmetros ruim Mtodo longo ou extrair mtodo TOTAIS (exceto categoria Defeito): Refatoraes Sugeridas 6 7 (17,9%) 7 (17,9%) 7 (17,9%) 6 (15,4%) 3 (7,7%) 2 (5,1%) 1 (2,5%) 1 (2,5%) 1 (2,5%) 1 (2,5%) 1 (2,5%) 1 (2,5%) 1 (2,5%) 39 (100%) Complexidade Ciclomtica 5 -3 -1 -4 -1 -8 0 0 0 0 0 0 0 -21 -38 Mtodos Fan- Fan- Linhas de Remotos In Out Cdigo Invocados 5 7 60 7 -1 -11 -1 1 -3 0 0 0 0 0 0 0 -3 -18 -3 -5 -5 6 -23 1 0 0 0 -1 0 0 -57 -87 -14 -1 -9 -4 -39 -2 0 1 0 18 7 2 -157 -198 1 2 0 6 -21 0 0 0 0 0 0 0 -57 -69

Para analisar este resultado da Tabela 2 com um nvel de detalhe maior, o efeito sobre as mtricas de cdigo foi normalizado e a sua variao descrita atravs de percentuais. Os percentuais foram calculados da seguinte forma: o valor da variao da mtrica dividido pelo valor da mtrica antes da refatorao (ex: para uma reduo de 4 linhas de cdigo em um mtodo com 20 linhas teramos uma variao de -20%). Ento, para cada categoria, os dados foram explorados atravs de boxplots criadas para cada mtrica. Apenas as categorias mais freqentes foram analisadas. Em cada boxplot, os possveis casos atpicos (outliers) foram mantidos para enriquecer a anlise j que no se tm muitos pontos para compor o boxplot.

Fig. 1. Anlise da Variao das Mtricas para Categoria Algoritmo Ruim

Comeando pela Figura 1, correspondente a categoria algoritmo ruim, observa-se que as mtricas, que mais sofreram efeito nesta categoria, foram complexidade ciclomtica e linhas de cdigo. Isto sugere que a viso de algoritmo ruim por parte dos desenvolvedores esteve associada questo do uso incorreto ou desnecessrio de comandos de controle, o que coerente com a concepo de um algoritmo que pode ser melhorado. Ilustrando de maneira expressiva esta viso um dos desenvolvedores descreveu sua sugesto da seguinte forma: Somente o primeiro if necessrio, pois caso a busca no se d pelo CPF, o else do segundo if cria a lista adequadamente.

Fig. 2. Anlise da Variao das Mtricas para Categoria Organizao Interna Ruim

A Figura 2 mostra que a mtrica mais afetada pela refatorao na categoria organizao interna ruim foi a fan-in. De fato, mais da metade das sugestes nessa categoria envolveu a recomendao do uso correto do escopo de variveis onde, por exemplo, um desenvolvedor comentou: a varivel de referncia formBuscar tem escopo pertinente apenas a este mtodo, logo poderia ser declarada dentro deste mtodo. Outras sugestes incluram inicializao de variveis no construtor e o uso indevido de texto esttico no corpo do mtodo existe um arquivo especial no projeto que deve ser utilizado para qualquer texto.

Fig. 3. Anlise da variao das mtricas para categoria baixa coeso

A maior parte das sugestes de refatorao da categoria baixa coeso girou em torno de violaes do estilo arquitetural MVC. O seguinte comentrio de um desenvolvedor ilustra este cenrio: o valor total das parcelas no deve ser somado pela classe de formulrio. Isto deve ser de responsabilidade da classe ParcelaList.

A classe de formulrio, referida pelo desenvolvedor, uma classe da camada viso, responsvel por manter em memria os valores preenchidos nos formulrios. A Figura 3 ainda mostra um acrscimo nas mtricas fan-out e mtodos remotos invocados. Praticamente nenhuma alterao no nmero de linhas de cdigo foi registrada. A categoria pequenos problemas de estrutura incluiu questes gerais com a organizao do cdigo como, por exemplo, atribuio desnecessria de valor a variveis, nas palavras do desenvolvedor: a atribuio a nulo desnecessria neste caso ou no adequado instanciar uma (classe) parcela sem qualquer informao e depois invocar seguidamente vrios mtodos set, o correto criar um construtor que receba os parmetros necessrios. Por ter um carter mais genrico, esta categoria praticamente no teve nenhuma variao de mtrica significativa, alm de possuir um grande nmero de casos atpicos. Por esta razo, sua anlise boxplot foi suprimida. 7.2 Fatores que Explicam as Sugestes de Refatorao A anlise da variao das mtricas apresentada acima detalha o efeito sobre as mtricas aps a refatorao. Nesta seo, caractersticas da estrutura do cdigo fonte antes da refatorao, representadas pelas mtricas de cdigo, sero exploradas para tentar explicar quais delas podem ter influenciado a deciso do desenvolvedor ao sugerir uma refatorao. Anlise de regresso foi utilizada para estudar como estas caractersticas afetaram as decises. O mtodo de regresso categrica foi empregado nesta anlise, pois possui vantagens sobre os mtodos tradicionais como a habilidade de criar modelos de regresso combinados nos quais diferentes tipos de variveis independentes podem existir simultaneamente e ainda a varivel dependente pode estar em qualquer uma das trs escalas nominal, ordinal ou razo. Alm disto, a regresso categrica tem melhor desempenho em uma massa de dados que possui um nmero limitado de observaes, vrias variveis e muitos valores diferentes por varivel. Devido a estas caractersticas, a regresso categrica foi utilizada para conduzir esta anlise. O nvel de erro (alpha) utilizado para a anlise de dados ser de 5%. Para cada categoria analisada na seo anterior, um modelo de regresso foi criado. As mtricas de cdigo foram utilizadas como variveis independentes e a deciso pela refatorao de cada mtodo considerada como varivel dependente (em escala nominal, sim ou no). Os mtodos que no receberam nenhuma sugesto de refatorao foram considerados como no (total de 10 mtodos) e aqueles que receberam foram considerados como sim (o total depende de cada categoria, ficando na faixa de 6-7 mtodos). Alm disto, mtodos classificados exclusivamente como defeito foram utilizados para criao dos modelos de regresso como no na varivel dependente. Isto porque o foco da refatorao no era a identificao de defeitos e, caso os defeitos no estivessem presentes, estes mtodos no teriam nenhuma sugesto de refatorao de melhoria.

Tabela 3. Modelo de regresso para categoria algoritmo ruim 0,888 p-value: Preditores do Modelo Preditores Standardized Beta p-value Complexidade Ciclomtica -5,909 0,037 Fan-In -4,239 0,026 Fan-Out 4,324 0,078 Linhas de Cdigo 7,576 0,022 Mtodos Remotos Invocados -4,154 0,058 Adjusted R Square: 0,018 Coeficiente de Correlao -0,847 -0,828 0,904 0,855 0,910

A Tabela 3 mostra que o modelo de regresso da categoria Algoritmo Ruim explica 88,8% das sugestes de refatorao. A partir da tabela possvel verificar que o preditor mais importante deste modelo Linhas de Cdigo seguido de Complexidade Ciclomtica (estamos considerando o mdulo do valor standardized beta, pois existem variveis com escala nominal no modelo; alm disto, o mdulo do coeficiente de correlao define a proporo de variao da varivel dependente desconsiderando a influncia entre as variveis preditoras). Ainda que o modelo aponte tambm uma influncia da mtrica fan-in, ele est coerente com a Figura 1 a qual mostra que as mesmas mtricas foram as mais afetadas na anlise da variao aps a refatorao.
Tabela 4. Modelo de regresso para categoria organizao interna ruim 0,636 p-value: Preditores do Modelo Preditores Standardized Beta p-value Complexidade Ciclomtica -0,998 0,783 Fan-In 0,190 0,831 Fan-Out 3,160 0,091 Linhas de Cdigo 2,666 0,337 Mtodos Remotos Invocados -5,115 0,012 Adjusted R Square: 0,047 Coeficiente de Correlao -0,641 0,171 0,603 0,727 -0,752

O modelo da Tabela 4 compreende 63,6% das sugestes de refatorao. O preditor mais importante Mtodos Remotos Invocados. Apesar do modelo apontar esta mtrica como a mais influente nas sugestes dos desenvolvedores, a mtrica mais afetada pela refatorao, segundo a anlise da variao das mtricas na Figura 2, foi a Fan-In. Para tentar identificar a origem desta diferena, o primeiro passo foi verificar que o fato do preditor Fan-In no influenciar no modelo da Tabela 4 seria um indcio de que os mtodos no refatorados e aqueles, que foram refatorados, deveriam possuir as mesmas caractersticas em termos dos valores da mtrica Fan-In. Feito isto, na busca do porqu os valores desta mtrica eram semelhantes, verificou-se que um dos desenvolvedores, em alguns casos, no identificou como problema mtodos que faziam uso de variveis com escopo maior do que o necessrio no caso, maiores que o escopo do mtodo avaliado. Isto parece ter sido a origem da diferena entre o modelo da Tabela 4 e a anlise da Figura 2. Ainda assim, o modelo conseguiu capturar a influncia da mtrica Mtodos Remotos Invocados tambm identificado na Figura 2 ainda que em maior intensidade.

Tabela 5. Modelo de regresso para categoria baixa coeso 0,676 p-value: Preditores do Modelo Preditores Standardized Beta p-value Complexidade Ciclomtica 0,581 0,916 Fan-In -0,213 0,941 Fan-Out -4,401 0,033 Linhas de Cdigo -1,417 0,605 Mtodos Remotos Invocados 5,215 0,020 Adjusted R Square: 0,021 Coeficiente de Correlao 0,421 -0,191 -0,538 -0,729 0,596

As mtricas mais importantes para as sugestes dos desenvolvedores relativas categoria Baixa Coeso foram Mtodos Remotos Invocados e Fan-Out (Tabela 5). O modelo capaz de responder por 67,6% das necessidades de refatorao da categoria e est de acordo com a anlise da variao das mtricas da Figura 3. No foi possvel criar um modelo estatisticamente significativo para a categoria Pequenos Problemas de Estrutura. De fato, isto no chega a ser surpresa, j que esta categoria contabilizou o maior nmero de casos atpicos na anlise de variao das mtricas devido a motivos j mencionados na seo anterior. Ento, de certa forma, este fato est coerente com a anlise da seo anterior na medida em que no possvel extrair concluses precisas em nenhum dos dois casos. Como comentrio final anlise, foi possvel perceber diante da anlise de mtricas de antes da refatorao (anlise de regresso) que as decises dos desenvolvedores pela refatorao ou no de um determinado mtodo foram, de maneira geral, consistentes com as mtricas afetadas aps as modificaes terem sido feitas. Desta forma, como as mtricas de cdigo esto representando caractersticas estruturais do cdigo, possvel observar que as mesmas caractersticas que influenciaram as decises dos desenvolvedores foram aquelas que de fato foram afetadas aps a realizao das refatoraes.

8 Discusso
As principais bases para a conduo deste estudo foram [7,8], pois mostraram como o estudo poderia ser planejado e organizado para capturar e analisar os dados quantitativos (mtricas de cdigo) e qualitativos (descrio das sugestes de refatorao). Desta forma, cabe comparar, ou ao menos interpretar comparativamente os resultados obtidos j que este estudo no estritamente uma repetio. Os modelos de regresso elaborados nos dois estudos diferem em alguns aspectos e merecem ser detalhados. O modelo de regresso baseado nas mtricas de cdigo criado por Mntyl [7] para identificar as caractersticas do cdigo que influenciaram as decises de refatorao explicou apenas 30% das decises e, na mesma direo, uma primeira tentativa em se criar o mesmo modelo no presente trabalho no gerou nenhum modelo estatisticamente significativo. No entanto, para um grupo dos participantes em Mntyl [7] foi dada uma lista pr-determinada de code smells (ex: mtodo longo) onde questionou-se sobre a existncia de cada code smell no cdigo. Agrupando os modelos por code smell obteve-se desempenho significativamente melhor chegando a explicar mais de 70% das decises para dois

dos trs code smells. De forma anloga, aps a categorizao das decises de refatorao, foi criado um modelo de regresso para algumas das categorias e, tambm, foi possvel obter resultados significativamente melhores com modelos explicando desde 63,6% at 88,8% de trs das quatro categorias. No entanto, existe um resultado conflitante com Mntyl [7]. Neste estudo, mtricas de cdigo foram utilizadas com sucesso em um modelo de regresso como preditoras da deciso pela refatorao de cdigo, enquanto que em Mntyl o modelo baseado em mtricas s foi estatisticamente significativo para a presena ou no de code smells (e no para a deciso pela refatorao de cdigo). Um motivo para esta diferena pode residir no fato de que foi definido que os desenvolvedores deveriam ter experincia no contexto do projeto, j que existia uma expectativa de que este conhecimento prtico seria til identificao de defeitos relacionados desvios dos padres de codificao e estilos arquiteturais. Desta forma, houve uma consistncia nos tipos de desvios de cdigo identificados o que possivelmente resultou em modelos de regresso significativamente melhores para as decises de refatoro.

9 Consideraes Finais
Este trabalho buscou caracterizar a influncia da estrutura do cdigo, representada por mtricas de cdigo, nas decises de refatorao de cdigo utilizando a metodologia pesquisa-ao. Um dos resultados mais importantes foi a constatao da viabilidade em se predizer decises de refatorao tomando como base mtricas de cdigo em um contexto real conflitando com resultados anteriores. Este resultado abre espao para a construo de ferramentas que apiem esta tomada de deciso, mas para que isto ocorra os resultados indicam que as ferramentas precisariam ser calibradas com dados do projeto onde elas so utilizadas dados estes que incluam algum histrico de avaliaes subjetivas conforme os modelos de regresso foram criados neste trabalho. Com isto, a sugesto de Fowler et al. [6] de manter a avaliao humana na deteco de necessidades de refatorao seria mantida, ainda que indiretamente. Existe um nmero expressivo de trabalhos que usam mtricas para detectar a necessidade de refatorao [9], mas estas tecnologias tendem a gerar muitos falsopositivos e, por isso, necessitam de uma avaliao humana em grande parte dos casos [10]. Desta forma, espera-se que a abordagem utilizando modelos de regresso e os resultados aqui encontrados contribuam para a criao de ferramentas mais eficazes. De fato, o uso de modelos de regresso para diminuir o nmero de falso-positivos trazidos com anlises baseadas em mtricas de cdigo mostrou-se til em uma rea relativamente prxima estudada neste trabalho, deteco de defeitos. Em Ruthruff et al.[11] descrito como defeitos reportados automaticamente por ferramentas que analisam o cdigo estaticamente (incluindo mtricas de cdigo) passam por uma triagem executada por meio de modelos de regresso os quais identificam aqueles que tm mais chances de representar um defeito real. Estes modelos de regresso foram criados com bases histricas de triagens manuais. Todavia, existem limitaes que precisam ser apontadas. A primeira delas est relacionada com a validade externa j que os resultados so localizados e relacionados diretamente ao escopo do projeto. Novos estudos precisam ser conduzidos nesta

direo para que seja possvel a generalizao dos resultados, at porque os resultados aqui encontrados conflitam com obtidos em Mntyl [7]. Com relao a validade interna e de concluso os pesquisadores sentem-se bastante seguros dos efeitos estudados, pois as verses do cdigo refatorado e as sugestes de refatorao foram registradas e a qualidade do cdigo melhorada. Entretanto, existe a possibilidade de que a utilizao de um outro conjunto de mtricas apontasse outro resultado.

Agradecimentos
Os autores agradecem a CAPES, CNPq e FAPERJ pelo apoio financeiro e Prof. Michel Thiollent pelas indicaes sobre a aplicao da metodologia pesquisa-ao.

Referncias
1. Basili, V.R., Caldiera, G., Rombach, H.D.: The Goal Question Metric approach. In the Encyclopedia of Software Engineering, vol. 2, pp. 528-532, John Wiley & Sons, Inc (1994) 2. Baskerville, R. L.: Investigating information systems with action research. In: Communications of the Association for Information Systems, volume 2 (1999) 3. Bennet, K. H. and Rajlich, V. T.: Software maintenance and evolution: A roadmap. In: The Future of Software Engineering, Ed. ACM Press, 7387 (2000) 4. Checkland, P., Holwell, S.: Action Research: Its Nature and Validity. In: Systemic Practice and Action Research 11(1): 9-21 (1998) 5. Dunsmore, A., Roper, M., and Wood, M.: Practical code inspection techniques for objectoriented systems: an experimental comparison. In: IEEE Software, 21-29 (2003) 6. Fowler, M., Beck, K., Brant, J., Opdyke, W. and D. Roberts.: Refactoring: Improving the Design of Existing Code. Addison Wesley, 1st edition (1999) 7. Mntyl, M.V.: An experiment on subjective evolvability evaluation of object-oriented software: explaining factors and interrater agreement. In: International Symposium on Empirical Software Engineering, pp. 277-286 (2005) 8. Mntyl , M. V. and Lassenius, C.: Drivers for software refactoring decisions. In: Proceedings of the 2006 ACM/IEEE International Symposium on Empirical Software Engineering (ISESE06), pages 297-306, New York, NY, USA (2006) 9. Mens, T. and Tourwe, T.: A survey of software refactoring. In: IEEE Transactions on Software Engineering, 30(2):126139 (2004) 10.Parnin, C. and Grg, C.: A catalogue of lightweight visualizations to support code smell inspection. In: Proc. of the ACM Symposium on Software Visualization, pp. 77-86 (2008) 11.Ruthruff, J. R., Penix, J., Morgenthaler, J. D., Elbaum, S., Rothermel, G.: Predicting accurate and actionable static analysis warnings: an experimental approach. In: Proc. of the 30th International Conference on Software Engineering, pp. 341350 (2008) 12.Santos, P. S. M. e Travassos, G. H.: Colaborao entre Academia e Indstria: Oportunidades para Utilizao da Pesquisa-Ao em Engenharia de Software. In: 5th Experimental Software Engineering Latin American Workshop, v. 1, p. 1-10 (2008) 13.Santos, P.S.M., Travassos, G. H.: Action Research Use in Software Engineering: an Initial Survey. In: 3nd International Symposium on Empirical Software Engineering and Measurement, Orlando, USA, to appear (2009) 14.SOFTEX: MPS.BR: Melhoria de Processo do Software Brasileiro. Guia Geral Verso 1.2, Campinas, SP (2007) 15.Susman, G.L., Evered, R.D. (1978) An assessment of the scientific merits of action research. In: Administrative Sciences Quarterly, 23, pp. 582603.