Estratégias e Perfis de Programadores Iniciantes na Identificação de Anomalias de Modularidade de Software

Estratégias e Perfis de Programadores Iniciantes na Identificação de Anomalias de Modularidade de Software João Marcelo Moraes Fernandes, Glauco de Figueiredo Carneiro Universidade Salvador (UNIFACS), Bahia, Brasil Rua Ponciano de Oliveira, 126 Salvador, BA 41950-275, Brasil joao.moraes@unifacs.edu.br;gluaco.carneiro@unifacs.br Abstract. The way novice programmers perform software comprehension tasks in multiple view interactive environments (MVIE) is still an open question. The lack of experience can increase the dependency of these environments and it may even hinder its use. For this reason, there is room for empirical studies to characterize behavior profiles and strategies adopted by novice programmers during software comprehension tasks. This paper presents an observational study that aims at characterizing how visual resources can support novice programmers in code smells identification. The results uncover strategies and behavior profiles of novice programmers performing the asked tasks. Resumo. Uma questão de pesquisa ainda a ser investigada é como programadores iniciantes utilizam recursos dos ambientes interativos baseados em múltiplas visões (AIMVs) para a execução de atividades de compreensão de software. O fato de terem pouca experiência pode implicar na maior dependência do apoio ferramental e até dificultar o seu uso. Daí a necessidade de caracterização dos perfis e das estratégias utilizadas por estes programadores durante a execução de atividades de compreensão de software. Este artigo apresenta um estudo observacional com o objetivo de caracterizar como recursos de visualização de software apóiam programadores iniciantes na identificação de anomalias de modularidade de software. Os resultados revelaram estratégias e perfis de comportamento dos programadores iniciantes para a execução das atividades solicitadas. 1 Introdução A identificação de estratégias adotadas por programadores iniciantes na execução de atividades de compreensão de software pode revelar situações nas quais eles enfrentam maior dificuldade e também aquelas nas quais eles têm maior facilidade de atuação. O conhecimento deste cenário pode contribuir para o compartilhamento destas estratégias bem sucedidas e também para envidar esforços na busca de alternativas factíveis em atenuar as dificuldades encontradas. Ainda é reduzido o número de estudos que analisam estratégias utilizadas para a identificação de anomalias de modularidade de software, também conhecidas como bad smells (Fowler, 1999). Um exemplo de estudo nesta direção foi o conduzido por (Carneiro et al., 2010). Entretanto, não foram identificados estudos com foco na estratégia adotada especificamente por

programadores iniciantes com o apoio de ambientes integrados baseados em múltiplas visões (AIMVs). Como motivação para o tema deste artigo tem-se que programadores iniciantes podem se beneficiar do conhecimento prévio de estratégias bem sucedidas para identificação e correção de anomalias de modularidade de software em Ambientes Integrados Baseado em Múltiplas Visões (AIMV). Além disso, o conhecimento destas estratégias pode servir de referência para a customização de estruturas visuais integradas aos ADSs de acordo com o perfil do programador e também da atividade a ser executada. Isso pode servir de ponto de partida para a criação de perfis de uso do ADS de acordo com as atividades a serem realizadas combinadas com o nível de experiência do programador. Outra motivação para a identificação das estratégias adotadas por programadores iniciantes é que a partir de um perfil específico pode-se delegar atividades de forma mais adequada no contexto de um determinado projeto de software. Este artigo está organizado da seguinte forma. A seção 2 aborda a compreensão de software na perspectiva dos programadores iniciantes. A seção 3 apresenta o estudo exploratório com o objetivo de identificar as estratégias e os perfis de programadores iniciantes na identificação das anomalias de modularidade de software. A seção 4 apresenta as considerações finais. 2 Compreensão de Software na Perspectiva dos Programadores Iniciantes A compreensão de software consiste na obtenção de conhecimento das funcionalidades, estrutura e comportamento de um sistema de software (Mayrhauser e Vans, 1995). É um requisito fundamental nas atividades de desenvolvimento e manutenção de software (Carneiro, 2011). Para a maioria dos programadores iniciantes, a compreensão de software representa um desafio, pois a sua execução é muitas vezes complexa, árdua e cercada de dificuldades. Isto contribui para que o desempenho de suas atividades seja diferente daquele dos programadores considerados experientes. Uma evidência disto é a diferença significativa de tempo existente para a execução de uma mesma atividade por um programador experiente e por um programador iniciante (Riaz, et al., 2010). Dentre os fatores que podem dificultar a compreensão do software por programadores iniciantes podem ser citados, entre outros, o processo de aprendizagem de programação, a complexidade inerente tanto dos conceitos quanto do paradigma de programação, e a forma como são disponibilizadas as funcionalidades pelos próprios ambientes de desenvolvimento de software (ADSs). Estes últimos ainda precisam melhorar para apoiar de forma efetiva estes programadores. A literatura dispõe de estudos que relatam possibilidades de configuração e enriquecimento dos ADSs para melhor se ajustar aos perfis de tipos de programadores (Carneiro, et al., 2010) (Sillito et al., 2005) (Alwis e Murphy, 2006). Seguindo esta tendência, tem-se que os AIMVs também podem ser configurados e ajustados para melhor apoiar os programadores iniciantes. 3 O Estudo Exploratório Os resultados obtidos no estudo publicado em (Carneiro, Fernandes e Mendonça, 2011) permitiram constatar a viabilidade do AIMV SourceMiner para apoiar os programadores iniciantes na identificação de anomalias de modularidade de software.

As questões de pesquisa e as observações apresentadas naquele estudo serviram para o planejamento do estudo relatado neste artigo com o objetivo de caracterizar como programadores iniciantes identificam anomalias de modularidade de software. O objetivo deste estudo seguindo a abordagem GQM (Basili e Rombach, 1988) é analisar o uso do AIMV SourceMiner com o propósito de caracterizá-lo em relação à efetividade das estratégias adotadas para a identificação de anomalias de modularidade de software do ponto de vista dos programadores iniciantes no contexto de atividades de compreensão de software. As seguintes perguntas de pesquisa (PP) foram abordadas. PP1: Quais as principais estratégias adotadas por programadores iniciantes durante a identificação de anomalias de modularidade de software? PP2: Quais os perfis de comportamento dos programadores iniciantes durante a identificação de anomalias de modularidade de software? Quinze estudantes recém-egressos do curso de Tecnologia da Informação do IFBA (campus Dias D'Ávila/BA) foram selecionados como participantes do estudo. Estes estudantes foram considerados como programadores iniciantes. A justificativa para isto foi o fato de não terem qualquer tipo de experiência profissional com programação orientada a objeto nem com atividades de manutenção de software. O protocolo adotado foi adaptado de (Carneiro et al., 2010). Deste estudo foram selecionadas a lista de referência das anomalias de modularidade de software, a aplicação e as atividades solicitadas aos participantes. O local escolhido para a execução das atividades foi o laboratório do Instituto Federal da Bahia - IFBA (campus Dias D'Ávila/BA). O objeto de estudo selecionado foi o aplicativo MobileMedia. A maior versão deste aplicativo tem aproximadamente quatro mil linhas de código e está organizada em 18 pacotes, 50 classes e 200 métodos. A razão da sua escolha foi o fato do seu código fonte estar disponível publicamente e de ter servido de objeto de estudo de outros trabalhos como o realizado por (Carneiro et al., 2010) e também por (Figueiredo et al., 2008) e (Conejero et al., 2009). Foram selecionadas as versões de 3 a 7 do MobileMedia para a execução das atividades. Os quinze estudantes participaram de um tutorial realizado pelo primeiro autor deste artigo em um intervalo de cinco horas. No tutorial foram apresentadas as funcionalidades do SourceMiner, incluindo suas visões e recursos de interatividade. Também no escopo do tutorial foram apresentadas as definições das anomalias de modularidade de software, também conhecidas como code smells, God Class, Feature Envy e Divergent Change. As atividades do estudo foram descritas no questionário de atividades com as seguintes seções (i) descrição resumida das funcionalidades do objeto de estudo; (ii) descrição e exemplo com trechos em código Java das anomalias God Class, Feature Envy; (iii) instruções para registrar as classes e ou métodos afetados pelas duas anomalias de modularidade selecionadas para este estudo, assim como solicitação de registro de data e horário da sua identificação; (iv) solicitação de descrição das estratégias utilizadas incluindo o uso das visões e recursos de interatividade disponibilizados pelo SourceMiner.

3.1 Execução do Estudo O tempo disponível para a execução das atividades foi de quatro horas. A distribuição do tempo utilizado por cada participante é apresentada a seguir: PA1 (02:51 h); PA2 (02:59 h); PA3 (01:31 h); PA4 (03:33 h); PA5 (03:10 h); PA6 (04:00 h); PA7 (02:33 h); PA8 (02:52 h); PA9 (01:25 h); PA10 (01:30 h); PA11 (03:09 h); PA12 (02:23 h); PA13 (03:15 h); PA14 (02:00 h); PA15 (02:12 h). Não foi permitido o acesso ao código fonte para a execução das atividades. Todas as respostas foram baseadas nas representações visuais do SourceMiner configuradas e ajustadas por cada participante para a execução das atividades solicitadas. 3.2 Análise dos Resultados As métricas de precisão (p) e cobertura (c) adaptadas de (Moha et al., 2010) foram utilizadas para investigar as perguntas de pesquisa PP1 e PP2. A precisão quantifica a taxa de anomalias de modularidade corretamente identificadas pelo número de anomalias de modularidade detectadas. A cobertura quantifica a taxa de anomalias de modularidade corretamente identificadas pelo número de anomalia de modularidade da lista de referência. A Tabela 1 apresenta os valores médios de p e c para cada participante do estudo. O objetivo do uso de valores médios foi de descrever o desempenho de cada participante na execução das atividades solicitadas para cada anomalia. Os resultados de precisão e cobertura para a identificação do GC são os primeiros a serem analisados na Tabela 1. P9 utilizou o menor tempo disponível (85 minutos) e identificou 100% (c = 1) das ocorrências de GC nas versões de 3 a 7 do MobileMedia. Além disso, suas indicações para GC tiveram precisão de 100% (p = 1), ou seja, todas as suas indicações para esta anomalia foram corretas, P9 utilizou a visão mapa em árvores juntamente com a representação de interesses para a identificação das ocorrências de GC. Analisando-se os recursos verificou-se que todos os participantes deste estudo também utilizaram a visão de mapa em árvores para a identificação de GC. A diferença foi que nem todos tiveram o mesmo bom desempenho que P9. Seguindo a análise da eficiência com base no tempo, esse participante teve o melhor resultado da amostra. Por exemplo, P2 com p = 0,6 e c = 0,3, foi o participante com menor número de anomalias identificadas no estudo, por isto o valor relativamente baixo de c = 0,3. Já P8, com p = 0,5 e c = 0,8, foi o participante com maior número de indicações incorretas de GC, daí o valor de p = 0,5. Esse participante finalizou a atividade em aproximadamente três horas. Sete dos participantes conseguiram detectar pelo menos 80% (c >= 0,8) das ocorrências desta anomalia. Enquanto que para a anomalia FE, somente um dos participantes conseguiu identificar acima de 40% (c >= 0,4) das ocorrências, com uma precisão menor que 40% (p <= 0,4). A média de tempo desses participantes ficou entre duas e três horas para realização da atividade. Através dos registros de log coletados pelo SourceMiner verificou-se que diversas classes, principalmente a classe BaseController, foram identificadas como GC. A razão principal para que os participantes pudessem identificá-las como tal foi o fato de terem valores acima da média de tamanho em número de linhas e do número de interesses por elas implementados. Isto contribuiu para destacar estas classes na visão de mapa em árvores decoradas com interesses. Considerando a média de precisão e cobertura de todos os participantes, verifica-se que a identificação de GC foi a que mais

se destacou em relação aos demais. Por outro lado, a identificação da anomalia FE apresentou o pior resultado. O participante P9, por exemplo, não fez nenhuma indicação de candidatos para FE, daí os valores nulos para precisão e cobertura. De acordo com a informação fornecida pelo participante no questionário, ele declarou que não foi possível associar a definição de FE com as visões do SourceMiner. Por este motivo não indiquei nada para FE. Através da Tabela 1 pode-se constatar que apenas o participante P5 conseguiu acertar acima de 50% (c = 0,6) das identificações do FE. Mas obteve p = 0,4, demonstrando que não teve boas indicações para FE. Os participantes P2, P3, P6, P7, P8, P10, P11, P12, P13 e P15 não obtiveram nenhuma representatividade com os seus resultados. Os valores destes participantes variam entre 10% (c >=0,1) e 40% (c <= 0,4), sendo que apenas o participante P8 obteve uma precisão igual a 50% (p = 0,5). Os participantes P1, P4, P9 e P14 tiveram os piores resultados da amostra, ou seja, obtiveram valores nulos para p e c. Com base nestes dados, podem ser apresentadas as seguintes observações. Tabela 1 Precisão e Cobertura por Participante Participante Média de Feature Envy (FE) (V3-V7) Média de God Class (GC) (V3-V7) Média de Divergent Change (DC) (V3-V7) p c p c p c P1 0,1 0,1 0,6 0,4 0,3 0,3 P2 0,4 0,4 0,6 0,3 0,3 0,1 P3 0,1 0,2 0,9 0,9 0,9 0,4 P4 0,1 0,1 0,8 0,5 0,8 0,3 P5 0,4 0,6 0,9 0,8 0,5 0,3 P6 0,3 0,2 0,9 0,8 0,4 0,2 P7 0,2 0,2 1,0 0,7 0,4 0,1 P8 0,5 0,3 0,5 0,8 0,4 0,2 P9 0,0 0,0 1,0 1,0 1,0 0,6 P10 0,2 0,4 0,7 0,7 0,4 0,2 P11 0,3 0,2 0,8 0,6 0,0 0,0 P12 0,2 0,4 0,7 0,5 0,9 0,3 P13 0,2 0,2 0,8 0,7 0,8 0,3 P14 0,0 0,0 0,8 0,8 0,8 0,3 P15 0,4 0,2 0,8 1 0,2 0,0 Observação 1: Os valores de precisão e cobertura indicam que os programadores iniciantes alcançaram melhores resultados na identificação da anomalia de modularidade de software God Class (GC). Observação 2: Os resultados do estudo apresentam evidências de que a visão de mapa em árvores juntamente com a representação de interesses é uma estratégia efetiva para identificação da anomalia God Class pelos programadores iniciantes. Esta visão é efetiva para representar entidades de software que se destacam pelo elevado número de linhas de código e também pelo número de interesses que afetam estas entidades. Observação 3: Os valores de precisão e cobertura indicam que os programadores iniciantes não alcançaram bons resultados na identificação da anomalia de modularidade de software Feature Envy (FE).

Os valores médios de precisão e cobertura para DC (p = 0,5 e c = 0,2) indicam que esta anomalia teve melhores resultados na identificação que a FE, mas teve menor desempenho na identificação se comparada a GC. Analisando-se a Tabela 1, verifica-se que o maior valor de cobertura foi c = 0,6. Este valor é consideravelmente menor do que aqueles obtidos para GC. Já para a precisão, o maior resultado foi de p = 1,0. Já para a anomalia DC, os resultados de precisão e cobertura apresentam maior diferenciação. Analisando ainda os resultados da Tabela 1, percebe-se que o participante P11 não fez indicações para a identificação de DC. Os participantes P2, P7 e P15 obtiveram valores baixos de acertos com taxas menores de 20% para cobertura (c < 0,2) e precisão abaixo de 40% (p <= 0,4). O melhor resultado da amostra foi do participante P9 que conseguiu acertar 60% (c = 0,6) das anomalias com 100% (p = 1) de precisão. Importante salientar que este participante também obteve o resultado mais significativo para identificação do GC. Esse participante também foi o que realizou a atividade no menor tempo. Os outros participantes tiveram resultados que variam de 20% (c >= 0,2) a 40% (c < = 0,4), sendo que cinco desses participantes P3, P4, P12, P13 e P14 obtiveram taxas de precisão maiores ou iguais que 80% (p = 0,8). Os outros participantes obtiveram taxas de precisão que não ultrapassaram os 40% (p = 0,4). A partir dos valores obtidos e discutidos de precisão e cobertura podem ser feitas considerações a respeito dos perfis dos participantes do estudo. Para precisão acima de 50% ( ) e cobertura abaixo de 50% ( ) o perfil é conservador (C). Para precisão e cobertura acima de 50% ( ) o perfil é seguro (S). Para precisão e cobertura abaixo de 50% ( ) o perfil é inseguro (I). E, finalmente, para precisão abaixo de 50% ( ) e cobertura acima de 50% ( ) o perfil é otimista (O). A justificativa para estes perfis considerando precisão e cobertura é apresentada a seguir. Para os casos onde o programador obteve c < 0,5 ( ) e p >= 0,5 ( ), pode-se concluir que apesar de ter indicado poucas anomalias, este buscou errar pouco nas suas indicações. Daí o termo conservador. Por outro lado, se o programador obteve valores de c >=0,5 ( ) e p < 0,5 ( ), pode-se concluir que, diferentemente do perfil conservador, este buscou indicar e alcançar na aplicação mais anomalias sem necessariamente se preocupar com possíveis erros nas indicações. Daí o termo otimista. Já os programadores com bons resultados de cobertura (c >= 0,5) ( ) e de precisão (p >= 0,5) ( ) são programadores considerados mais equilibrados. Isto porque estes buscam indicar e alcançar mais anomalias com a preocupação de minimizar os erros nas indicações. Daí o termo seguro. Por último, aqueles programadores que não obtiveram bons resultados de cobertura (c < 0,5) ( ) e de precisão (p < 0,5) ( ) buscaram indicar e alcançar poucas anomalias sem a preocupação de minimizar os erros nas indicações. Daí o termo inseguro. A partir dos resultados registrados na Tabela 1 e considerando os perfis descritos anteriormente, buscou-se classificar o perfil de cada um dos quinze participantes do segundo estudo. Com base nesta classificação, treze dos quinze participantes demonstraram perfil inseguro (I) na identificação da anomalia FE. As estratégias desses participantes oscilaram entre as visões grafo de dependência, visão polimétrica e mapa em árvores. As exceções ficaram por conta dos participantes P5 que demonstrou perfil otimista (O) e de P8 que demonstrou perfil conservador (C). O participante P5 informou ter usado grafo de dependência e P8 informou ter usado grafo de dependência juntamente com mapa em árvores. Já na identificação do GC, treze dos quinze participantes, de P3 até P15, demonstraram perfil seguro (S). Somente dois

participantes, P1 e P2, demonstraram perfil conservador (C). Todos os participantes informaram ter usado a visão mapa em árvores para essa anomalia. Na identificação de DC, seis participantes demonstraram perfil conservador (C). Apenas o participante P9 demonstrou perfil seguro (S) na identificação de DC. Para essa anomalia a maioria dos participantes informou ter usado interesses juntamente com mapa em árvores. Com base nestes dados, podem ser apresentadas as seguintes observações. Observação 4: este estudo forneceu evidências iniciais de que os programadores iniciantes assumiram perfil inseguro (I) para identificar a anomalia Feature Envy. Já para a identificação de God Class apresentaram perfil seguro (S). No caso da anomalia Divergent Change não houve uma predominância significativa de perfil que pudesse caracterizá-lo como representativo para a execução da atividade solicitada. Observação 5: foram obtidas evidências iniciais de que os programadores iniciantes podem assumir diferentes perfis a depender da atividade. Por exemplo, o participante P9 apresentou um perfil inseguro (I) para identificação do FE, mas apresentou perfil seguro(s) para identificar as anomalias GC e DC. 3.3 Ameaças à Validade do Estudo As ameaças potenciais que podem ter afetado a validade deste estudo exploratório são apresentadas a seguir acompanhadas das respectivas justificativas. A primeira delas é relacionada ao número de participantes que pode ser considerado baixo e com a mesma formação. O fato de terem a mesma formação pode indicar que o conhecimento dos conceitos e as experiências podem ser parecidos. Com isso pode existir uma homogeneidade dos resultados. A literatura relata estudos realizados com quantidade de participantes na mesma ordem de grandeza do conduzido neste trabalho (Alwis e Murphy, 2006) (Sillito et al, 2005). Esta quantidade de participantes não tem o objetivo de testar a causalidades das hipóteses através de estatística inferencial obtendo dados quantitativos concretos para análise. A segunda ameaça está relacionada ao conhecimento em orientação a objetos que os programadores iniciantes deveriam ter. Estas informações foram constatadas por meio de formulário elaborado para tal finalidade. A terceira ameaça está relacionada ao entendimento do conceito de cada anomalia de modularidade de software utilizada nas atividades do estudo. Exemplos utilizando trechos de código de outras aplicações foram disponibilizados nos questionários para cada anomalia. Estas mesmas anomalias foram usadas nos estudos (Marinescu, 2004). A quarta ameaça está relacionada à possibilidade de acesso ao código fonte do objeto do estudo, uma vez que esta prática não fora permitida neste experimento. As ações registradas pelos registros de log do SourceMiner confirmaram que não foi feito nenhum acesso ao código fonte pelos participantes. 4 Conclusão Através deste estudo foi possível constatar que ambientes interativos baseados em múltiplas visões como o SourceMiner podem apoiar a adoção de estratégias efetivas para a identificação de anomalias de software para programadores iniciantes. Conforme discutido neste artigo, os participantes do estudo, mesmo sendo considerados iniciantes, conseguiram obter resultados satisfatórios para a identificação das anomalias God Class e Divergent Change. Além disso, pôde-se verificar que para a anomalia GC aproximadamente 87% dos participantes apresentaram perfil de programador seguro (S). Por outro lado, a maioria dos participantes, aproximadamente 87%, demonstrou

perfil inseguro (I) para a identificação da anomalia Feature Envy. Um percentual pequeno de participantes apresentou perfil conservador (C), sendo 7% para o FE, 13% para o GC e 40% para o DC. Já o perfil otimista (O) foi manifestado por somente um participante para a anomalia FE. Isto sinaliza a possibilidade de investigação futura em relação às condições em que o programador iniciante poderia assumir perfil otimista e também possibilidade de disponibilizar as estratégias efetivas para os programadores através do próprio AIMV. 5 Bibliografia Alwis, B. d., Murphy, G. Using Visual Momentum to Explain Disorientation in the Eclipse IDE. (pp. 51-54). IEEE Computer Society. 2006. Carneiro, G. F. Sourceminer: um ambiente integrado para Visualização multi-perspectiva de software. 2011. 230 f. Tese (doutorado) Universidade Federal da Bahia, Instituto de Matemática, Doutorado Multiinstitucional em Ciência da Computação. Carneiro, G.F., Fernandes, J., Mendonça, M. Caracterizando Programadores Iniciantes na Identificação de Anomalias de Modularidade: Um Estudo Inicial. Publicado no Workshop de Manutenção Moderna de Software WMSWM 2011. Carneiro, G.; Silva, M.; Mara, L.; Figueiredo, E.; Sant anna, C.; Garcia, A.; Mendonça, M. Identifying Code Smells with Multiple Concern Views. Proceedings of the CBSOFT-SBES. 2010. p. 128-137. Clarke, Steven. Why do programmer personality types matter. Psychology of Programming. Journal of Visual Languages & Computing, 2009. Fowler, M. Refactoring: Improving the Design of Existing Code. 1. ed. Addison-Wesley Professional, 1999. Mayrhauser, A. V.; Vans, A. M. Program Comprehension During Software Maintenance and Evolution. Journal of Computer, v. 28, p. 44-55, 1995. Marinescu, R. Detection Strategies: Metrics-Based Rules for Detecting Design Flaws. Proceedings of the 20th IEEE International Conference on Software Maintenance. IEEE Computer Society. 2004. p. 350-359. Moha, N.; Gueheneuc, Y.; Leduc, P. Automatic Generation of Detection Algorithms for Design Defects. Proceedings of the 21st IEEE/ACM International Conference on Automated Software Engineering. 2006. p. 297-300. Riaz, M., Sulayman, M., Salleh, N. Mendes, E. Experiences Conducting Systematic Reviews from Novices' Perspective. Proc. of the Evaluation and Assessment in Software Engineering (EASE 2010) Keele University, UK, British Computer Society. Sillito, J., Volder, K., Fisher, B., Murphy, G. Managing software change tasks: an exploratory study. International Symposium on Empirical Software Engineering. 2005. SourceMiner. Um Ambiente Interativo baseado em Múltiplas Visões. Disponível em www.sourceminer.org. Acesso em Maio de 2012.