Congresso Brasileiro de Software: Teoria e Prática 28 de setembro a 03 de outubro de 2014 Maceió/AL

Transcrição

1 Congresso Brasileiro de Software: Teoria e Prática 28 de setembro a 03 de outubro de 2014 Maceió/AL II Workshop Brasileiro de Visualização, Evolução e Manutenção de Software VEM 2014 Anais

2 Anais Volume 02 ISSN VEM 2014 II Workshop Brasileiro de Visualização, Evolução e Manutenção de Software COORDENADORES DO COMITÊ DE PROGRAMA Eduardo Figueiredo - Universidade Federal de Minas Gerais (UFMG) Renato Novais - Instituto Federal da Bahia (IFBA) COORDENAÇÃO DO CBSOFT 2014 Baldoino Fonseca - Universidade Federal de Alagoas (UFAL) Leandro Dias da Silva - Universidade Federal de Alagoas (UFAL) Márcio Ribeiro - Universidade Federal de Alagoas (UFAL) REALIZAÇÃO Universidade Federal de Alagoas (UFAL) Instituto de Computação (IC/UFAL) PROMOÇÃO Sociedade Brasileira de Computação (SBC) PATROCÍNIO CAPES, CNPq, INES, Google APOIO Instituto Federal de Alagoas, Aloo Telecom, Springer, Secretaria de Estado do Turismo AL, Maceió Convention & Visitors Bureau, Centro Universitário CESMAC e Mix Cópia 2

3 PROCEEDINGS Volume 02 ISSN VEM nd Workshop on Software Visualization, Evolution and Maintenance PROGRAM CHAIRS Eduardo Figueiredo - Universidade Federal de Minas Gerais (UFMG) Renato Novais - Instituto Federal da Bahia (IFBA) CBSOFT 2014 GENERAL CHAIRS Baldoino Fonseca - Universidade Federal de Alagoas (UFAL) Leandro Dias da Silva - Universidade Federal de Alagoas (UFAL) Márcio Ribeiro - Universidade Federal de Alagoas (UFAL) ORGANIZATION Universidade Federal de Alagoas (UFAL) Instituto de Computação (IC/UFAL) PROMOTION Sociedade Brasileira de Computação (SBC) SPONSORS CAPES, CNPq, INES, Google SUPPORT Instituto Federal de Alagoas, Aloo Telecom, Springer, Secretaria de Estado do Turismo - AL, Maceió Convention & Visitors Bureau, Centro Universitário CESMAC and Mix Cópia 3

4 Autorizo a reprodução parcial ou total desta obra, para fins acadêmicos, desde que citada a fonte 4

5 Apresentação O II Workshop Visualização, Evolução e Manutenção de Software (VEM 2014) é um dos eventos integrantes do V Congresso Brasileiro de Software: Teoria e Prática (CBSoft 2014), realizado em Maceió AL, no período de 28 de Setembro a 3 de Outubro de O VEM tem como objetivo integrar as comunidades das áreas de visualização, manutenção e evolução de software, oferecendo um fórum em território brasileiro onde pesquisadores, estudantes e profissionais podem apresentar seus trabalhos e trocar ideias a respeito dos princípios, práticas e inovações recentes em suas respectivas áreas de interesse. O VEM surgiu a partir da junção de dois outros workshops brasileiros focados em temas relacionados que até então vinham sendo realizados de forma separada, a saber: Workshop de Manutenção de Software Moderna (WMSWM) e Workshop Brasileiro de Visualização de Software (WBVS). O Comitê de Programa (CP) do VEM 2014 é formado por 34 pesquisadores atuantes nas áreas de visualização, manutenção e evolução de software, provenientes de diversas regiões do Brasil e de outros países da América Latina. Os membros do CP foram responsáveis pela seleção de 14 artigos completos para serem apresentados no VEM 2014, de um total de 23 artigos submetidos. Cada artigo submetido foi avaliado por pelo menos três membros do CP, com base nos critérios de originalidade, qualidade técnica e adequação ao escopo do workshop. Os artigos selecionadas abrangem diversos temas de interesse do evento, como gerência de configuração, métricas, análise arquitetural, e ferramentas de apoio à visualização, reutilização, manutenção, reengenharia e migração de software. Além da apresentação dos quatorze artigos selecionados pelo CP, o programa técnico do VEM 2014 inclui ainda um palestra convidada onde os participantes do evento puderam discutir os problemas e soluções mais relevantes atualmente nas áreas de visualização, manutenção e evolução de software, bem como novas oportunidades de pesquisa e desenvolvimento tecnológico nessas áreas. Para finalizar, gostaríamos de agradecer a todos os autores que submeteram artigos ao VEM 2014, pelo seu interesse, aos membros do CP, pelo esforço e valiosa colaboração durante o processo de seleção dos artigos, e aos organizadores e patrocinadores do CBSoft 2014, pelo apoio na realização do evento. Maceió, 28 de Setembro de 2014 Eduardo Figueiredo e Renato L. Novais Coordenadores do Comitê de Programa do VEM 2014CBSoft

6 Foreword The 2nd Workshop on Software Visualization, Evolution and Maintenance (VEM 2014) is part of the 5th Brazilian Congress on Software: Theory and Practice (CBSoft 2014), held in Maceió AL, from September 28 to October 3, Its main goal is to foster the integration of the software visualization, evolution and maintenance communities, providing a Brazilian forum where researchers, students and professionals can present their work and exchange ideas on the principles, practices and innovations related to their respective areas of interest. VEM was created from the fusion of two previous Brazilian workshops on related themes, namely Workshop on Modern Software Maintenance (WMSWM) and Brazilian Workshop on Software Visualization (WBVS). The VEM 2014 Program Committee (PC) is composed of 34 active researchers in the areas of software visualization, evolution and maintenance, who come from several regions of Brazil as well as from other Latin American countries. The PC members selected 14 full papers to be presented at VEM 2014, from a total of 23 submissions. Each submission was evaluated by at least three PC members, based on their originality, technical quality and adequacy to the event's scope. The selected papers cover several themes of interest to the workshop, such as configuration management, metrics, architectural analysis, and tool support for software visualization, reuse, maintenance, reengineering and migration. In addition to the fourteen full papers selected by the PC, the VEM 2014 technical program also includes an invited keynote talk where the event participants could discuss the main problems and solutions related to software visualization, evolution and maintenance, as well as new research and technological development opportunities in these areas. Finally, we would like to express our deepest gratitude to all authors who submitted their work to VEM 2014, for their interest, to the PC members, for their effort and invaluable collaboration during the paper selection process, and to the CBSoft 2014 organizers and sponsors, for their support and contribution. Maceió, September 28, 2014 Eduardo Figueiredo and Renato L. Novais VEM 2014 Program Committee Co-chairs 6

7 Biografia dos Coordenadores Eduardo Figueiredo Eduardo Figueiredo é professor adjunto do Departamento de Ciência da Computação e coordenador do Laboratório de Engenharia de Software (LabSoft) da Universidade Federal de Minas Gerais (UFMG). Doutor em Engenharia de Software pela Universidade de Lancaster no Reino Unido (2009). Eduardo possui ainda mestrado em Informática pela Pontifícia Universidade Católica do Rio de Janeiro (2006) e bacharelado em Ciência da Computação pela Universidade Federal de Ouro Preto (2003). Tem experiência na área de Ciência da Computação, com ênfase em Engenharia de Software, atuando principalmente nos seguintes temas: medição de software, padrões de projeto e implementação, reutilização de software, estudos empíricos e desenvolvimento de software orientado a aspectos. Renato Lima Novais Renato Novais é professor efetivo do Instituto Federal de Educação, Ciência e Tecnologia da Bahia (IFBA). Obteve o titulo de Doutor em Ciência da Computação pela Universidade Federal da Bahia, em 2013, com período sanduíche no Fraunhofer Center for Experimental Software Engineering, MD, EUA. Suas principais áreas de pesquisa são visualização de software, evolução de software, engenharia de software experimental, manutenção e reengenharia de software, e compreensão de software. 7

8 Chairs Short Biographies Eduardo Figueiredo Eduardo Figueiredo is a associate professor at Federal University of Minas Gerais (UFMG) and coordinator of the Laboratory of Software Engineering (LabSoft). He holds a Ph.D. degree in Software Engineering from Lancaster University, United Kingdom (2009). Eduardo also has master's degree in Computer Science from the Pontifical Catholic University of Rio de Janeiro (2006) and a BA in Computer Science from the Federal University of Ouro Preto (2003). He has experience in Computer Science with emphasis on Software Engineering, mainly in the following topics: software measurement, design patterns and implementation, software reuse, empirical studies and aspect-oriented software development. Renato Lima Novais Renato Novais is an effective professor at Instituto Federal de Educação, Ciência e Tecnologia da Bahia (IFBA). He holds a D.Sc. degree in Computer Science from Universidade Federal da Bahia. During his Doctorate, he spent a period as a visiting scientist in Fraunhofer Center for Experimental Software Engineering, MD, USA. His main research areas are software visualization, software evolution, experimental software engineering, software maintenance and reengineering, and software comprehension. 8

9 Comitês Técnicos / Program Committee Comitê Diretivo / Steering Committee Claudia Werner - Universidade Federal do Rio de Janeiro (COPPE/UFRJ) Eduardo Figueiredo - Universidade Federal de Minas Gerais (UFMG) Heitor Costa - Universidade Federal de Lavras (UFLA) Leonardo Murta - Universidade Federal Fluminense (UFF) Nabor Mendonça - Universidade de Fortaleza (UNIFOR) Renato Novais - Instituto Federal da Bahia (IFBA) Comitê do programa / Program Committee Alexandre Bergel - University of Chile, Chile Aline Vasconcelos - Instituto Federal de Educação, Ciência e Tecnologia Fluminense (IFF) Claudia Werner - Universidade Federal do Rio de Janeiro (COPPE/UFRJ) Claudio Sant'Anna - Universidade Federal da Bahia (UFBA) Delano Beder - Universidade Federal de São Carlos (UFSCar) Eduardo Figueiredo - Universidade Federal de Minas Gerais (UFMG) Elder Cirilo - Universidade Federal de São João del-rei (UFSJ) Elisa Huzita - Universidade Estadual de Maringá (UEM) Glauco Carneiro - Universidade Salvador (UNIFACS) Gustavo Rossi - Universidad Nacional de La Plata, Argetina Heitor Costa - Universidade Federal de Lavras (UFLA) Humberto Marques - Pontifícia Universidade Católica de Minas Gerais (PUC Minas) Joberto Martins - Universidade Salvador (UNIFACS) Jorge César Abrantes de Figueiredo - Federal University of Campina Grande (UFCG) Kécia Ferreira - Centro Federal de Educação Tecnológica de Minas Gerais (CEFET-MG) Leonardo Murta - Universidade Federal Fluminense (UFF) Lincoln Rocha - Universidade Federal do Ceará (UFC) Manoel Mendonca - Universidade Federal da Bahia (UFBA) Marcelo Maia - Universidade Federal de Uberlândia (UFU) Marcelo Pimenta - Universidade Federal do Rio Grande do Sul (UFRGS) Marco Antônio Pereira Araujo - Instituto Federal do Sudeste de Minas Gerais (IF Sudeste MG) Marcos Chaim - Universidade de São Paulo (USP) Maria Istela Cagnin - Universidade Federal de Mato Grosso do Sul (UFMS) Nabor Mendonça - Universidade de Fortaleza (UNIFOR) Paulo Henrique Maia - Universidade Estadual do Ceará (UECE) Pedro Santos Neto - Universidade Federal do Piauí (UFPI) Renato Lima Novais - Instituto Federal da Bahia (IFBA) Ricardo Ramos - Universidade Federal do Vale do São Francisco (UNIVASF) Ricardo Terra - Universidade Federal de Lavras (UFLA) Rodrigo Spinola - Universidade Salvador (UNIFACS) Rosana Braga - Universidade de São Paulo (ICMC/USP) 9

10 Rosângela Penteado - Universidade Federal de São Carlos (UFSCar) Sandra Fabbri - Universidade Federal de São Carlos (UFSCar) Valter Camargo - Universidade Federal de São Carlos (UFSCar) Revisores Adicionais / Additinal Reviewers Anderson Belgamo - Instituto Federal de São Paulo - Campus Piracicaba (IFSP-PRC) Andre Freire - Universidade Federal de Lavras (UFLA) Juliana Padilha - Universidade Federal de Minas Gerais (UFMG) Marcelo Ramos - Universidade de São Paulo (USP) 10

11 Comitê organizador / Organizing Committee COORDENAÇÃO GERAL Baldoino Fonseca - Universidade Federal de Alagoas (UFAL) Leandro Dias da Silva - Universidade Federal de Alagoas (UFAL) Márcio Ribeiro - Universidade Federal de Alagoas (UFAL) COMITÊ LOCAL Adilson Santos - Centro Universitário Cesmac (CESMAC) Elvys Soares - Instituto Federal de Alagoas (IFAL) Francisco Dalton Barbosa Dias - Universidade Federal de Alagoas (UFAL) COORDENADORES DO VEM 2014 Eduardo Figueiredo - Universidade Federal de Minas Gerais (UFMG) Renato Novais - Instituto Federal da Bahia (IFBA) 11

12 Índice / Table of Contents Artigos Completos / Full Papers TS1 Visualization, Evolution, Maintenance and Experimental Studie What Questions Developers Ask During Software Evolution? An Academic Perspective Renato Novais, Creidiane Brito, Manoel Mendonça Um Estudo Empírico do Uso da Comunicação para Caracterizar a Ocorrência de Dependências de Mudança no Projeto Ruby on Rails Igor Wiese, Reginaldo Re, Rodrigo Takashi Kuroda, Gustavo Oliva, and Marco Aurelio Gerosa Análise de Métricas Estáticas para Sistemas JavaScript Miguel Ramos and Marco Tulio Valente Migração Parcial de um Banco de Dados Relacional para um Banco de Dados NoSQL na Nuvem Através de Adaptações Não-intrusivas: Um Relato de Experiência Caio Costa, Lincoln Rocha, Nabor Mendonca, and Paulo Maia TS2 - Software Visualization, Education And Reenginering Polimorphic View: Visualizando o Uso de Polimorfismo em Projetos de Software Fábio Petrillo, Guilherme Lacerda, Marcelo Pimenta, and Carla Freitas On the Use of Context Information for Supporting Software Visualizations Renan Vasconcelos, Marcelo Schots, and Claudia Werner ArchGraph: Modularização Automática de Sistemas Usando Clusterização de Grafos de Dependência Guilherme Avelino and Marco Tulio Valente SimMS - Um Jogo Educacional de apoio ao Ensino de Manutenção de Software Diógenes Dias Simão, Dyeimys Franco Correa, and Paulo Afonso Parreira Júnior ProFap-R: Um Processo de Reengenharia de Código Orientada pela 78 12

13 Reengenharia de Dados Eduardo Fernandes, Ygo Brito, Inara Ortiz, Nathalia Borine, and Maria Istela Cagnin TS3 - Bad Smells and Refactoring Influencing Factors on Code Smells and Software Maintainability: A Cross-Case Study Tassio Vale, Iuri Souza, and Claudio Sant'Anna How Developers Deal with Code Smells: the Case of the SourceMiner Evolution Team Alcemir Santos, Mário André Farias, Eduardo Santana de Almeida, Manoel Mendonca, and Cláudio Sant'Anna Um Método para Identificação de Bad Smells a partir de Diagramas de Classes Henrique Nunes Gomes, Mariza Bigonha, Kecia Ferreira, and Flávio Madureira KDM-RE: A Model-Driven Refactoring Tool for KDM Rafael Durelli, Bruno Santos, Raphael Honda, Marcio Delamaro, and Valter Camargo TS4 VEM history Uma Análise da História do VEM, WBVS e WMSWM Renato Novais, Thiago Mendes, and Fernando Teles

14 What Questions Developers Ask During Software Evolution? An Academic Perspective Renato Novais 1, Creidiane Brito 1, Manoel Mendonça 2 1 Federal Institute of Bahia, Salvador BA Brazil 2 Fraunhofer Project Center for Software and Systems Engineering at UFBA Salvador BA Brazil {renato,creidianebrito}@ifba.edu.br, manoel.mendonca@ufba.br Abstract. Many studies on software evolution propose new approaches. One needs to validate the approaches. For that, it is common to conduct experimental studies where participants have to answer questionnaires with questions related to the research topic. Those questions must be relevant, otherwise the validation may be invalid. In this context, this study investigates which questions (and so the tasks) developers really answer (and perform) during software evolution. To this end, a survey comprised of 11 questions was applied to 42 participants from academia. This study allowed to derive an initial model on questions developers ask during software evolution, and to understand how the participants agreed with the relevance of the questions. 1. Introduction Several studies on software evolution and maintenance propose new methods, techniques, and tools. To validate their approach, it is common to conduct experimental evaluation, where they try to answer questions or to perform maintenance tasks. For example, in [Wettel et al. 2011], the authors used a set of ten program comprehension and design quality assessment questions to investigated the efficiency and correctness using software visualization. In [Bavota et al. 2012], the authors analyzed the impact of test smells on program comprehension during maintenance activities. For that, they applied a questionnaire with 16 questions related to software test. In [Hattori et al. 2013], the authors also evaluated their tool based on a set of six evolution tasks. And in [Novais et al. 2012b] and [Novais et al. 2012a], the authors evolved a software evolution visualization tool motivated by the need to answer two feature evolution comprehension questions. The relevance of the questions or tasks used is, in general, based on literature reports. However, if those tasks are not really used on the state of the practice, the approaches and therefore, their evaluation, may not guarantee their applicability. Based on this assumption, we decided to investigate which questions (and so the tasks) developers really answer (and perform) during software evolution. The study presented in [Sillito et al. 2006] already investigated this topic. In our study, we decided to go further to see if the questions reported in that study, and in others found in the literature, are really relevant for developers and practitioners. [Sillito et al. 2006] conducted two qualitative studies of programmers (newcomers and industrial programmers) performing change tasks to medium to large sized programs. Based on those studies, they cataloged and categorized 44 different kinds of questions asked by their participants. [de Alwis and Murphy 2008] highlighted the difficulty 14

15 of programmers have to answer questions as they investigate the functioning of a software system. They must piece together results from different tools to determine an answer to the initial query. To overcome this issue, they proposed a model that supports the integration of different sources of information about a program and a tool that implements this model. On the same token, [Fritz and Murphy 2010] also pointed out the challenges on answering a variety of questions that require the integration of different kinds of project information. To investigate this topic they interviewed 11 professional developers. From this step, they identified 78 questions developers want to ask, but for which support is lacking. The general goal of this work is to investigate how academics and practitioners see those questions, and discover if they are following the same directions. If the answers are no, we may have a big issue on the directions of the research on the academic context that should be always well aligned with real industrial problems. In this paper, we present the results of the investigation with the academic researchers. To this end, we performed a survey with 11 questions and with 42 people from academia. This paper contributes with the results of this survey on the academic perspective and also presents an initial model for questions developers ask. This paper is organized as follows. Section 2 presents the experimental evaluation. Section 3 shows the results of the study. Section 4 discusses some threats to validity. Finally, Section 5 concludes this paper, presenting directions for future works. 2. Experimental Evaluation 2.1. Goal Definition This study is part of a larger study that aims to investigate what questions are relevant during software evolution. The goal is to collect the academic and practice perspective and compare the results. In this paper, we present the first part: the academic perspective Planning Selection of suitable set of questions. The first step on this study was to identify a set of questions that could be used on the survey. Therefore, we conducted a literature review on the study context.we selected eight papers that report questions developers ask while performing software evolution tasks [Sillito et al. 2006] [de Alwis and Murphy 2008] [Fritz and Murphy 2010] [D Ambros and Lanza 2007] [Tu and Godfrey 2002] [German et al. 2004] [Ackermann and Zazworka 2010] [D Ambros and Lanza 2009]. The first three papers are the main reference points since they are focused on the same topic: investigate questions programmers ask during software evolution tasks. This step generated a list of 212 questions. This set of questions is very large, which is fairly impossible to apply a survey with all of them. To overcome this issue, we decided to group the questions. We observed that the questions had intersections and could be grouped in what we called Representative Questions. Each representative question grouped similar questions we found in the papers. For example, a representative question What module has been recently modified? may refers to similar questions as What classes have been changed?, Which API has changed (check on web site)?, or What methods or functions were changed?, etc. 15

16 Regarding the grouping step, we rely on the three most qualified experts to ensure the soundness of our clustering. In short, the experts validated the mapping of 212 questions to the 11 questions reported in Table 1. Table 1. List of Questions. Question Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q11 Description What is the impact of a change in the source code? Which module has been recently modified? Which module has undergone more changes? When a change occurred in the source code? Who has changed a module? Who has more impact in a given module? How much work has someone performed in some module? Where particular person has worked? For a given module, what are the changes that affected it? What was the reason behind the changes made in a given module? How was the process of changing a module? Response options for each question. The participants had to answer the questions according to two perspectives. First, the level of relevance for each question. The options were: i) Completely Irrelevant (CI); ii) Little Relevant (LR); iii) Relevant (R); and iv) Very Relevant (VR). Second, whom the information that the question addresses is related to. The options were: i) Software Developer; Software Manager; iii) Both; and iv) None. Participants. The survey had 42 participants. We selected master and PhD students from an experimental software engineering class at Federal University of Bahia, and students from a specialization from a scientific seminar class at Federal Institute of Bahia. We asked the participants to answer five questions about themselves. They were: c1) How many software deployed for the client have you developed any software maintenance activity?; c2) How many years have you worked with software development activities?; c3) How do you consider yourself regarding to someone else that most know about the related topics? (I am fair below, I am little below, I am at the same level, I am above); c4) What is your position on the current company (if working)?; and c5) Do you consider yourself more academic or practitioner? Figure 1 shows the participant characterization. Question c4 had very different answers so we omitted it Execution The execution process was conducted during master and PhD class sections at Federal University of Bahia and during a specialization class section at Federal Institute of Bahia. The participants took no more than 30 minutes to answer the survey. They had to answer the survey, and then fill a form characterizing them. 16

17 Figure 1. Characterization of the survey s participants. 3. Results 3.1. An Initial model for questions developers ask Figure 2 presents an initial model derived from the grouping questions step. Most of the questions had a relationship among them. We observed that there are three important entities of interest when asking question related to software evolution: change (modification report), source code (module), author (user, developer). The questions may be only related to the specific entity (e.g. what are the authors?, what are the modules of the software?), but generally they relate two entities of interest (e.g. which author modified this module?). Figure 2 depicts six questions relating two by two of these entities. The arrows link the two entities, and the direction of the arrow means the main entity on the question. The arrows highlight the historical information of interest. The color of the arrow portrays the stakeholder (developer, manager, both) that can use the information provided by the task that answers the question. We observed that the question is important to the manager, the manager and the developer, but never only for the developer. This is acceptable since the manager should understand every think about the project. There are still two important dimensions that can be added to these questions: time and effort. It is common to find question like: what changes have recently affected this module? and which authors have mostly worked on this module? We believe that developers of software evolution may benefit from this initial model. They can use it as a initial guide of questions that their tool should try to answer Questionnaire s answers Figure 3 shows the total of answers per each question of the survey. It presents the big picture of the survey answers. For each question there are at most four bars. From left to right side, the bars mean: Completely Irrelevant, Little Relevant, Relevant, and Very Relevant. 1 The first insight one may have from this picture is that most questions had the Relevant as the main response. Only questions Q1, Q4, and Q9 had the Relevant option response less than 50%. The others overlay this mark. Even more, only question Q1 the Relevant option was not the highest option. 1 View it on the computer screen, or in a color printed version for best results 17

18 Figure 2. An Initial Model for questions developers ask As can be observed, few questions had Completely Irrelevant answer (Q1: 2; Q6: 4; Q8: 1; and Q10: 2). The question with highest value for this category was the Q6, with 4 respondents. This question is related to who has more impact in a given module. In other words, who has changed more the given module? On the other hand, 50% of the respondents agreed that this question is Relevant. The category Little Relevant is presented in all of the questions. The highest values are for the questions Q5 and Q7 with 14 respondents. In all of the questions, it was higher or equal to the category Completely Irrelevant. On the same token, the category Relevant is also presented in all of the questions. The highest values were for the questions Q2, Q3, and Q8 with 29, 26 and 27 respondents, respectively. It is also important to notice that, for all the questions, this category had higher value than the category Little Relevant. All questions have at least four respondents on the category Very Relevant. For the question Q1, 71.43% of the respondents selected this category. This is also the highest agreement of the participants. Figure 4 shows how the participants evaluated each question considering whom the information that the question addresses is related to. Again, for each question there are at most four bars. From left to right side, the bar means: Software Developer, Software Manager, Both, None. The category Software Developer was presented in all of the questions. Question Q7 had the lowest value for this category: 1, while question Q2 had the highest. The category Software Manager was in almost all questions. Only question Q1 had no respondents for this category. The three highest score for this category were on questions Q7, Q8 and Q7, with 31, 29, and 22, respectively. Moreover, question Q7 had the highest value among all questions and categories. 18

19 Figure 3. Participants answers per question. The category Both considered Software Developer and Software Manager. It was also presented in all of the question. The highlights were for the question Q1, Q10 and Q9, with 30, 23 and 22 scores, respectively. Finally, the category None is presented in 7 questions, with no more than 5 answers (question Q6). Analyzing both Figures 3 and 4, it is possible to observe that question Q11 has two respondents for None category, and zero respondents for Completely Irrelevant. This may mean that the participants believed this question was Little Relevant, Relevant, or Very Relevant, for someone else not the Software Developer or Software Manager. Questions Q2, Q4, Q6, and Q7 present the same pattern Discussion The results showed that most participants aggreed with the relevance of those selected questions. To support this affirmation, let s considers grouping the results between the categories, as follows: negative category (Completely Irrelevant and Little Relevant) and positive category (Relevant and Very relevant). In this case, it is possible to observe that all questions had positive answers with more than 50%. The questions Q5, Q6 and Q7 had the lowest level, with 28, 25 and 28 respondents, respectively. The others were higher than 30 respondents. Questions Q3, Q1, and Q10 had the highest values, with 40, 39 and 38, respectively. As a general conclusion, according to these results, the questions/tasks are important on the state of the practice, when one needs to evolve his/her software. This guide us to conduct the second part of the larger study, that will investigate how expert (and real practical) people agree with the relevance of those questions/tasks. 4. Threats to Validity This study has some threats to validity. The first one we identified is the way we used to select the first set of questions. We started by the most referenced papers on the topic we know [Sillito et al. 2006] [de Alwis and Murphy 2008] [Fritz and Murphy 2010]. As 19

20 Figure 4. Relevance of the questions for stakeholders. they are from the same research group, we decide to add other papers we found that also had questions/tasks that developers ask/perform. Other threat may be related to the first group of task. We needed to reduce the number of questions. Therefore, we requested experience people to help us on this step. Even we based on expert opinions, this may be biased. One could for example, conduct a larger survey with independent expert people. The lower statistical power is a threat to the conclusion validity since we did not used strong statistical techniques to analyse the results. Finally, but not lastly, we point to the participants we selected. They may not be representative, however we tried to select the most heterogeneous we could count on. 5. Final Remarks This paper presents an academic perspective survey on questions developers ask during software evolution. It was motivated by repeatability that researchers use such question on the validation of their studies. The survey was composed of 11 questions and was applied to 42 respondents. The studies allowed us: i) to derive an initial model on questions developers ask during software evolution, and ii) to understand how the participants agreed with the relevance of the questions. The work presented here is part of a larger study, which intends to investigate and compare how academic and practitioners envision those questions on the state of practice. Thus, as a future work, we aim to apply the same survey with industrial participants and compare the results with the academic participants. Other direction is to analyze the produced information per participant level. This may guide us to a further understanding about the produced data. References Ackermann, C. and Zazworka, N. (2010). Codevizard: Combining abstraction and detail for reasoning about software evolution. Thecnical Report - University of Mariland. 20

21 Bavota, G., Qusef, A., Oliveto, R., De Lucia, A., and Binkley, D. (2012). An empirical analysis of the distribution of unit test smells and their impact on software maintenance. In Proceedings of the 28th IEEE International Conference on Software Maintenance, ICSM 12, pages D Ambros, M. and Lanza, M. (2007). Bugcrawler: Visualizing evolving software systems. In Proceedings of the 11st European Conference on Software Maintenance and Reengineering, CSMR 07, pages , Washington, DC, USA. IEEE Computer Society. D Ambros, M. and Lanza, M. (2009). Visual software evolution reconstruction. J. Softw. Maint. Evol., 21(3): de Alwis, B. and Murphy, G. (2008). Answering conceptual queries with ferret. In Proceedings of the 30th ACM/IEEE International Conference on Software Engineering, ICSE 08, pages Fritz, T. and Murphy, G. C. (2010). Using information fragments to answer the questions developers ask. In Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering, ICSE 10, pages , New York, NY, USA. ACM. German, D., Hindle, A., and Jordan, N. (2004). Visualizing the evolution of software using softchange. In Proc. Int. Conf. on Software Engineering & Knowledge Engineering, SEKE 04, pages , New York NY. ACM Press. Hattori, L., D Ambros, M., Lanza, M., and Lungu, M. (2013). Answering software evolution questions: An empirical evaluation. Inf. Softw. Technol., 55(4): Novais, R., Lima, Paulo, R., and Mendonça, M. (2012a). Timeline matrix: an on demand view for software evolution analysis. In Proc. of the 2nd Brazilian Workshop on Software Visualization, WBVS 12, pages 1 8. Novais, R., Nunes, C., Lima, C., Cirilo, E., Dantas, F., Garcia, A., and Mendonca, M. (2012b). On the proactive and interactive visualization for feature evolution comprehension: An industrial investigation. In Proc. of the 34th International Conference on Software Engineering, ICSE 12, pages Sillito, J., Murphy, G. C., and De Volder, K. (2006). Questions programmers ask during software evolution tasks. In Proceedings of the 14th ACM SIGSOFT International Symposium on Foundations of Software Engineering, SIGSOFT 06/FSE-14, pages 23 34, New York, NY, USA. ACM. Tu, Q. and Godfrey, M. W. (2002). An integrated approach for studying architectural evolution. In Proceedings of the 10th International Workshop on Program Comprehension, IWPC 02, pages 127, Washington, DC, USA. IEEE Computer Society. Wettel, R., Lanza, M., and Robbes, R. (2011). Software systems as cities: a controlled experiment. In Proceedings of the 33rd International Conference on Software Engineering, ICSE 11, pages , New York, NY, USA. ACM. 21

22 Um estudo empírico do uso da comunicação para caracterizar a ocorrência de dependências de mudança no projeto Ruby on Rails Igor S. Wiese 1, Rodrigo T. Kuroda 2, Reginaldo Ré 1, Gustavo A. Oliva 3, Marco A. Gerosa 3 1 Programa de Pós Graduação em Informática Universidade Tecnológica Federal do Paraná Campus Cornélio Procópio 2 Departamento de Ciência da Computação Universidade Tecnológica Federal do Paraná Campus Campo Mourão PR Brasil 3 IME/USP Departamento de Ciência da Computação Universidade de São Paulo (USP) - São Paulo SP Brasil {igor,reginaldo}@utfpr.edu.br, rodrigokuroda@gmail.com, {goliva,gerosa}@ime.usp.br Abstract. This paper studies the communication to characterize the occurrence of change dependencies. First, we propose separate change dependencies into strong and weak ones, according to the distribution of their occurrence in a release. Then, using classification algorithms and metrics from the social network extracted from traces of developers communication, we found that it is possible to characterize strong and weak change dependencies. The percentage of correctly classified pair of files stood in the range of 72-98%. We also used feature selection algorithms to identify the best metrics. Resumo. Este trabalho estuda a comunicação para caracterizar a ocorrência de dependências de mudança. Primeiro, nós realizamos a separação das dependências de mudança em fortes e fracas, de acordo com a distribuição da sua ocorrência por release. Depois, utilizando algoritmos de classificação e métricas da rede social extraída a partir de rastros de comunicação de desenvolvedores, nós descobrimos que é possível caracterizar os tipos de dependências de mudanças fortes e fracas. Nós obtivemos um percentual de 72-98% de pares de arquivos corretamente classificados. Nós também utilizamos algoritmos de seleção de atributos para identificar as melhores métricas. 1. Introdução Sistemas de software são compostos de artefatos que dependem uns dos outros. Como resultado, alguns artefatos evoluem conjuntamente durante o desenvolvimento do software [Canfora et al. 2014]. Ball et al. (1997) foram os primeiros pesquisadores a observar esse fenômeno de forma empírica ao minerar logs do sistema de controle de versão de um compilador. No ano seguinte, Gall et al. (1998) chamaram essa relação de coevolução de dependência lógica (do inglês, logical dependency). Ao passar do tempo, outros nomes passaram a ser mais utilizados na literatura, incluindo dependências de mudança (change dependencies), dependências evolucionárias (evolutionary dependencies), e comudanças históricas (historical co-changes). Neste artigo, utilizaremos o termo dependências de mudança. 22

23 Há uma série de estudos referentes à identificação de dependências de mudança [Canfora et al. 2010; Ying et al. 2004; Zimmermann et al. 2005], dos quais destacam-se a proposta de Zimmermann et al. (2005). Tal estudo foi amplamente utilizado pelos trabalhos que aplicam dependências de mudança para melhorar a qualidade do software. Entretanto, poucos estudos têm direcionado esforços para caracterizar a ocorrência de dependências de mudança, isto é, as razões por detrás da formação de tais dependências [Oliva et al. 2011]. Zhou et al. (2008) predizem a existência ou ausência de dependência de mudança entre dois arquivos usando métricas como a existência de dependência estática de código, ocorrência de dependência de mudança entre dois arquivos no passado, a idade da mudança e quem realizou a mudança. Oliva e Gerosa, mostraram que a existência de um acoplamento estrutural nem sempre leva a formação de dependências de mudanças [Oliva and Gerosa 2011]. Embora trabalhos anteriores tenham desconsiderado aspectos sociais, o desenvolvimento de software é inerentemente uma atividade sociotécnica, especialmente dada a necessidade de colaboração e comunicação entre os envolvidos no projeto [Cataldo et al. 2009]. De fato, no começo de 1968, Conway formulou a hipótese de que organizações que projetam sistemas são restringidas a produzir projetos que são cópias de suas próprias estruturas de comunicação [Conway 1968]. Então, a Lei de Conway assume, de certa forma, uma associação entre a arquitetura do software e as relações sociais. Influenciados pela Lei de Conway, alguns pesquisadores defendem que a interação entre os desenvolvedores pode impactar diretamente na qualidade da arquitetura do software, e por meio desta, transitivamente, influenciar na formação das dependências de mudança [Sebastiano Panichella 2014]. Este trabalho contribui de duas formas. Primeiro, nós dividimos as dependências de mudança em dois grupos: fortes e fracas. Nós propomos esta divisão porque entendemos que algumas dependências podem precisar ser priorizadas em relação a outras. Neste sentido, entender as origens da formação de dependências fortes e fracas é mais importante do ponto de vista prático, que prever ausência ou ocorrência de dependências de mudanças. Segundo, nós investigamos se métricas obtidas a partir da comunicação dos desenvolvedores em torno das suas contribuições (pull requests) podem caracterizar a formação destes dois grupos de dependências de mudança. Desta forma, inspirados na lei de Conway, nós utilizamos métricas de análise de redes sociais para caracterizar as origens das dependências fortes e fracas entre pares de arquivos em uma mesma release. Nós utilizamos o termo caracterizar ao invés de predizer, uma vez que não estamos coletando as métricas em uma release para prever a ocorrência em outra release. Nós estamos usando os algoritmos de classificação para determinar métricas relevantes para cada um dos grupos de dependência de mudança propostos. Duas questões de pesquisa foram investigadas neste trabalho: QP1) É possível caracterizar dependências de mudança fortes e fracas utilizando métricas obtidas a partir da comunicação dos desenvolvedores? QP2) Quais métricas utilizadas foram mais relevantes para esta caracterização? Entender as origens da formação destas dependências é importante, pois pode ajudar na elaboração de métodos mais robustos para a identificação destas. Além disto, já se sabe que dependências de mudanças podem ser utilizadas, por exemplo, para 23

24 prever defeitos [D Ambros et al. 2009] e realizar análise de impacto de mudança [Zimmermann et al. 2005] 2. Metodologia Nas Subseções abaixo, nós descrevemos os passos para coletar e identificar as dependências fortes e fracas a partir das submissões de pull-requests, como as métricas de redes sociais são obtidas da comunicação dos desenvolvedores nos pull-requests e como usamos os algoritmos de classificação para caracterizar dependências de mudanças fortes e fracas Coleta de dados e identificação das dependências de mudanças fortes e fracas O projeto Ruby on Rails 1 foi utilizado como objeto de estudo neste trabalho. Este projeto foi escolhido baseado no nível de interesse da comunidade de desenvolvedores que contribui no repositório Github. Ao todo, o projeto Rails possui mais de estrelas e forks do seu código. Nós usamos a API do GitHub 2 para coletar os dados do histórico de quatro releases. Releases anteriores foram descartadas por não terem todo seu histórico de commits ou pull requests completos no Gitub. Desta forma, foram coletados dados sobre as modificações dos arquivos e as discussões realizadas pelos desenvolvedores em cada pull request. Para encontrar as dependências de mudança e separá-las em dependências de mudança fortes e fracas, nós seguimos os seguintes passos: 1. Agrupar todos os pull requests e commits por relase 2. Remover cada pull request sem commit ou com commits que não foram integrados (merged) no projeto; 3. Se em um pull request existir mais de um commit, juntá-los em uma única transação; 4. Combinar todos os arquivos modificados em um pull request em pares de arquivos, excluindo arquivos que tem extensão de imagens e textos; 5. Aplicar o algoritmo de regra de associação APRIORI, utilizado por Zimmermman (2005) para encontrar as dependências de mudança definindo um valor limiar para suporte e outro para confiança. Para este trabalho nós utilizamos suporte igual a 2 e confiança igual a 30%; 6. Analisar a distribuição das dependências de mudança encontradas após o algoritmo de regra de associação para atribuir as dependências de mudanças a um grupo (forte ou fraco). Assim, pares de arquivos que formam dependências acima ou iguais ao valor de limiar do terceiro quartil serão atribuídos ao grupo forte. As demais dependências de mudança estarão no grupo fraca. Desta forma, as dependências fortes representam pelo menos 25% das dependências mais recorrentes após a aplicação do algoritmo de regra de associação. Estas dependências, são as que devem receber mais atenção dos desenvolvedores, por exemplo, se houver a necessidade de priorização de revisão de código ou cobertura de testes. 1 Detalhes do projeto podem ser encontrados na página oficial: e no Github: 2 Para mais detalhes acessar: 24

25 2.2. Redes Sociais e Métricas de Análise de Redes Sociais (SNA) Em nossa rede de comunicação, cada desenvolvedor que comentou em um pull request incluído no nosso estudo representa um nó. Arestas direcionadas representam a troca de mensagens entre os desenvolvedores. Nós adicionamos peso nas arestas contando a quantidade de vezes que um desenvolvedor interagiu com outro sobre a sequência de comentários. Depois da rede criada, nós utilizamos a API Jung 3 para calcular as métricas de análise de redes sociais. Nós calculamos 18 métricas que correspondem a métricas de centralidade da rede (degree, betweenness, closeness, e eigenvector), medidas de ego network (ego Betweenness, ego size, ego ties e ego density), medidas de structural hole (efficiency, effective size, constraint e hierarchy) e medidas globais (size, ties, density, diameter, número de mensagens e número distintos de desenvolvedores que comentaram). Mais detalhes sobre as métricas pode ser encontrados em [Wasserman and Faust 1994]. Além das métricas de rede social, nós também adicionamos três métricas obtidas do histórico de modificações. Nós adicionamos as medidas de code churn do arquivo um (codechurn), code churn do arquivo dois (codechurn2) e a média do code churn entre os dois arquivos que formavam o par para todo o histórico da release (codechurnavg). Code churn é uma métrica frequentemente utilizada como medida de controle, por ser um bom preditor em outros contextos [Hall et al. 2012]. Desta forma, nosso conjunto de dados final possui 21 métricas Classificação Os algoritmos de classificação leem um conjunto de treinamento e constroem um modelo de aprendizado a partir das métricas que são mais úteis para diferenciar cada uma das classes. Portanto, neste estudo, nós usamos as métricas descritas na Subseção 2.2 como entrada para os algoritmos de classificação. As classes, por sua vez, são as de dependências de mudança fracas e fortes. Desta forma, nós executamos cinco classificadores frequentemente encontrados na literatura, a saber: Naïve Bayes (Bayes), J48 (árvore de decisão), JRip (regras), KNN - K-nearest neighbours (preguiçoso ou IBk lazy) and Bagging (alvo ou target). Entre parênteses estão descritos sob quais critérios os algoritmos criam seus modelos de aprendizagem. Nós selecionamos estes algoritmos para retirar um possível viés nos resultados, por exemplo, se selecionássemos um único algoritmo de classificação os resultados poderiam refletir o sucesso ou fracasso daquele algoritmo em particular com o conjunto de dados utilizado no estudo. Tipicamente, estudos de classificação são avaliados utilizando medidas de sensibilidade (recall), precisão (precision) e área abaixo da curva ROC (AUC) [Demšar 2006]. A sensibilidade identifica a proporção das instâncias de uma determinada classe que o modelo pode recuperar com sucesso. A precisão pode medir a porcentagem correta de identificação de uma classe. A AUC é um bom indicativo para comparar modelos de classificação. Todas as medidas variam de 0 até 1, com o valor 1 representando a perfeita classificação. Para avaliar estas medidas, nós utilizamos a validação cruzada estratificada, que divide o conjunto de dados em n subconjuntos de tamanho aproximadamente igual mantendo a proporção das classes em cada 3 Para mais detalhes acessar: 25

26 subconjunto. Os objetos de n 1 partições são utilizados no treinamento do modelo. O subconjunto restante é usado como teste. A vantagem desta técnica é que todo o conjunto de dados é utilizado para treinamento e teste [Demšar 2006]. 3. Resultados 3.1. QP1) É possível caracterizar dependências de mudança fortes e fracas utilizando métricas obtidas a partir da comunicação dos desenvolvedores? Para verificar se é possível caracterizar dependências de mudança fortes e fracas utilizando as métricas de comunicação, nós primeiro coletamos os dados e definimos quais pares de arquivos representavam uma dependência de mudança forte e fraca para o nosso estudo. Para isto, nós utilizamos os seis passos descritos na Subseção 2.1. A Tabela 1 apresenta a sumarização da coleta de dados de cada uma das quatro releases estudadas. A coluna máximo suporte indica a quantidade de dependências de mudança encontradas entre os pares de arquivos. Além desta coluna, a mediana e o terceiro quartil do limiar de suporte são apresentados. A quantidade (#) de pares identificados como fortes e fracos, indica o balanceamento das classes formadas utilizando o algoritmo de regra de associação e a distribuição dos quartis. O percentual de cada classe é apresentado entre parênteses nas colunas #instâncias fortes e fracas. Por fim, são apresentadas a quantidade de pull requests e o total de instâncias (pares de arquivos) identificados em cada release. Desta forma, baseados na divisão do terceiro quartil, nós definimos o rótulo de forte ou fraca para cada dependência de mudança. Por exemplo, na release 3.1, para uma dependência de mudança ser classificada como forte, o valor do suporte dela deveria estar entre 4 e 14 mudanças. Isto significa que dois arquivos, A e B, deveriam ser modificados juntos em pelo menos 4 pull requests. Release Máximo Suporte Tabela 1. Sumarização das quatro releases estudadas. Mediana Suporte Limiar de Suporte (3º Quartil) Mediana Confiança # inst. Fortes # inst. Fracos # Pull requests Total de Instâncias >= 4 60,00% 873 (45,17%) 1060 (54,83%) >=2 100,00% 216 (46,87%) 215 (53,13%) >=3 70,17% 513 (39,70%) 778 (60,30%) >=2 66,66% 339 (16,12%) 1764 (83,88%) Para executar os algoritmos de classificação nós utilizamos a ferramenta Weka 4, que oferece implementações para os cinco algoritmos mencionados na Subseção 2.3. Utilizando o Weka, nós selecionamos os arquivos de entrada de dados armazenados em CSV, que continham nas linhas, cada uma das instâncias que representavam as dependências de mudança, e nas colunas cada uma das 21 métricas. A última coluna do CSV representava o valor da classe ao qual aquela dependência de mudança pertencia (forte ou fraca). Para cada um dos algoritmos e releases, nós executamos a tarefa de classificação. A Tabela 2 apresenta os resultados da caracterização das dependências de mudança fortes e fracas por meio do uso das métricas sociais e do code churn. Esses resultados foram obtidos com as melhores métricas já selecionadas (discussão na 4 Para acessar mais informações sobre a ferramenta: 26

27 Subseção 3.2). Observando os valores da AUC, que é a métrica para comparação de modelos, nós observamos que os algoritmos Bagging e KNN tiveram os melhores resultados nas releases 3.1 e 3.2. O algoritmo Bagging teve o melhor desempenho para as release 4.0 e 4.1. Apesar do Bagging ser o melhor algoritmo em todas as releases, somente na release 4.0 é possível perceber uma diferença maior entre os algoritmos. Nesta release, a diferença do Bagging (maior AUC) para o Naïve Bayes (menor AUC) foi de A diferença do Bagging para o segundo melhor algoritmo foi somente Na Release 4.1 a diferença entre Bagging (maior AUC) para Naïve Bayes (menor AUC) foi de Todos os algoritmos, com exceção do Naïve Bayes, tiveram desempenho similar ao Bagging, o que significa dizer que a escolha de um algoritmo, não influencia em diferença de acertos na classificação de dependências de mudança fortes ou fracas. Release Tabela 2. Resultados da classificação de dependências de mudança forte e fracas Algoritmos % Instâncias corretamente Classificadas Precisão (forte) Precisão (fraca) Sensibilidade (forte) Sensibilidade (fraca) AUC J48 0,977 0,983 0,974 0,968 0,986 0,977 Bagging 0,981 0,975 0,973 0,967 0,979 0,995 KNN 0,980 0,979 0,977 0,971 0,983 0,995 Naïve Bayes 0,904 0,921 0,892 0,863 0,905 0,943 JRip 0,967 0,967 0,968 0,961 0,973 0,964 J48 0,951 0,953 0,949 0,949 0,953 0,951 Bagging 0,948 0,929 0,971 0,972 0,926 0,986 KNN 0,974 0,977 0,972 0,972 0,977 0,986 Naïve Bayes 0,798 0,911 0,734 0,662 0,822 0,875 JRip 0,951 0,930 0,975 0,977 0,926 0,963 J48 0,869 0,857 0,876 0,805 0,911 0,875 Bagging 0,888 0,898 0,883 0,811 0,940 0,947 KNN 0,874 0,856 0,886 0,823 0,909 0,904 Naïve Bayes 0,721 0,719 0,723 0,493 0,873 0,713 JRip 0,793 0,833 0,778 0,602 0,920 0,789 J48 0,981 0,969 0,984 0,917 0,994 0,976 Bagging 98, KNN 97, Naïve Bayes 97, JRip 98, Assim, podemos concluir que é possível caracterizar dependências de mudança fortes e fracas utilizando métricas obtidas a partir da comunicação dos desenvolvedores. Esta conclusão é obtida verificando os valores de AUC obtidos nas quatro releases do projeto Rails. Utilizando diferentes algoritmos, nós obtivemos mais de 0.9 de AUC para cada uma das releases. Este resultado mostra que os valores de sensibilidade e precisão foram maiores que 90% em 14 dos 20 testes realizados (5 algoritmos X 4 releases). Somente a release 4.0 não apresentou este índice nas métricas de avaliação medidas. Obviamente, os resultados obtidos não podem ser generalizados para outros projetos, e novos testes devem ser realizados em maior escala para verificar se as métricas de comunicação podem ser úteis em outros projetos. No entanto, os resultados 27

28 indicam consistência, uma vez que as métricas foram úteis em quatro diferentes releases com mais de um algoritmo de classificação QP2) Quais métricas utilizadas foram mais relevantes para esta caracterização? Para responder a segunda questão de pesquisa, nós utilizamos um algoritmo de seleção de atributos. Para realizar a seleção de atributos (métricas) relevantes, nós usamos um método chamado Wrapper, disponível na ferramenta Weka. Este método, pesquisa no espaço de subconjuntos de métricas e calcula a precisão estimada de um algoritmo de aprendizagem para cada métrica quando ela é adicionada ou removida do subconjunto. Usamos o algoritmo WrapperSubSetEval como avaliador da relevância de cada métrica e o algoritmo BestFirst como o método de pesquisa. O algoritmo Best First foi configurado com o parâmetro backward, que começa construindo o modelo com todas as variáveis e vai removendo-as conforme a performance do modelo melhora ou piora. Na média, 8,3 métricas foram selecionados pelos 5 algoritmos através das 4 releases. Para obter este resultado, o algoritmo de seleção de atributos testou na média, 281 modelos diferentes. A release 3.1 teve média de 9,4 métricas e 342,6 modelos. A release 3.2 teve média de 9,6 métricas com 242,8 modelos. As últimas duas releases (4.0 e 4.1) tiveram 9 e 5,2 métricas com 250,4 e 186,6 modelos respectivamente. As métricas mais relevantes foram a densidade da rede (density medidas globais) e o número de comentários (propriedades globais) com 17 seleções em 20 possíveis. Logo após estas duas métricas, ego Betweenness (ego network) e número de desenvolvedores distintos que participaram da discussão (propriedades globais) foram selecionadas 11 vezes. Constraint, hierarchy (ambos structural hole) e diameter (propriedade global) foram as próximas métricas selecionadas com 10 vezes. As métricas code churn do primeiro arquivo e do segundo arquivo apareceram 8 vezes. Como estas métricas foram usadas como controle, todas as métricas abaixo delas foram consideradas menos relevantes para caracterizar as dependências de mudança fortes e fracas. É importante observar que as métricas referentes a medidas globais da rede (3 métricas) e as métricas de structural holes (2 métricas) foram mais relevantes que as métricas de ego network (uma métrica) e centrality (nenhuma seleção). Assim, encontramos evidências que indicam que o papel e a importância de um nó (desenvolvedor) são menos importantes do que a estrutura (organização) da rede. As métricas de structural hole indicam a inexistência de ligações entre dois nós na rede, o que pode indicar falhas e ausência de comunicação. 4. Conclusão e Trabalhos Futuros Dada a importância que o gerenciamento de dependências tem para a evolução do desenvolvimento do software, nós propusemos o estudo de dependências de mudança separadas em dois grupos: fortes e fracas. Durante este trabalho mostramos que é possível caracterizar a ocorrência destes dois grupos de dependência de mudança utilizando métricas extraídas da comunicação dos desenvolvedores e algoritmos de classificação. Utilizando a seleção de atributos encontramos evidências de que medidas globais da rede e métricas de structural hole são mais relevantes para a caracterização. No entanto, novos estudos são necessários para avaliar a importância das métricas de comunicação para a caracterização de dependências de mudança fortes e fracas em novos projetos. Atualmente nós estamos investigando o uso de métricas de 28

29 código fonte e métricas do histórico de modificações de arquivos e realizando testes em novos projetos. Agradecimentos Nós gostaríamos de agradecer a Fundação Araucária, NAWEB e NAPSOL pelo suporte financeiro a esta pesquisa. Marco G. recebe apoio individual do CNPq e FAPESP. Igor W. e Gustavo Oliva recebem apoio da CAPES (Processo BEX e /2013-4). Referências Ball, T., Adam, J.-M. K., Harvey, A. P. and Siy, P. (mar 1997). If Your Version Control System Could Talk... In ICSE Workshop on Process Modeling and Empirical Studies of Software Engineering. Canfora, G., Ceccarelli, M., Cerulo, L. and Di Penta, M. (2010). Using multivariate time series and association rules to detect logical change coupling: An empirical study. In Software Maintenance (ICSM), 2010 IEEE International Conference on. Canfora, G., Cerulo, L., Cimitile, M. and Penta, M. D. (2014). How changes affect software entropy: an empirical study. Empirical Software Engineering, v. 19, n. 1, p Cataldo, M., Mockus, A., Roberts, J. A. and Herbsleb, J. D. (2009). Software Dependencies, Work Dependencies, and Their Impact on Failures. IEEE Transactions on Software Engineering, v. 35, n. 6, p Conway, M. E. (1968). How do Committees Invent? Datamation, D Ambros, M., Lanza, M. and Robbes, R. (oct 2009). On the Relationship Between Change Coupling and Software Defects. In Reverse Engineering, WCRE th Working Conference on. Demšar, J. (2006). Statistical Comparisons of Classifiers over Multiple Data Sets. J. Mach. Learn. Res., v. 7, p Gall, H., Hajek, K. and Jazayeri, M. (1998). Detection of Logical Coupling Based on Product Release History. In Proceedings of the International Conference on Software Maintenance., ICSM 98. IEEE Computer Society. Hall, T., Beecham, S., Bowes, D., Gray, D. and Counsell, S. (2012). A Systematic Literature Review on Fault Prediction Performance in Software Engineering. IEEE Transactions on Software Engineering, v. 38, n. 6, p Oliva, G. A. and Gerosa, M. A. (2011). On the Interplay between Structural and Logical Dependencies in Open-Source Software. In SBES. Oliva, G. A., Santana, F. W., Gerosa, M. A. and Souza, C. R. B. De (2011). Towards a classification of logical dependencies origins: a case study. In EVOL/IWPSE. Sebastiano Panichella, R. O. Gerardo Canfora Massimiliano Di Penta (2014). How the Evolution of Emerging Collaborations Relates to Code Changes: An Empirical. In IEEE International Conference on Program Comprehension (ICPC 2014). Wasserman, S. and Faust, K. (1994). Social network analysis: Methods and applications. Cambridge university press. v. 8 Ying, A. T. T., Murphy, G. C., Ng, R. and Chu-Carroll, M. C. (sep 2004). Predicting Source Code Changes by Mining Change History. IEEE Trans. Softw. Eng., v. 30, n. 9, p Zhou, Y., Wurch, M., Giger, E., Gall, H. and Lu, J. (2008). A Bayesian Network Based approach for change coupling prediction. In Reverse Engineering, 2008 WCRE. Zimmermann, T., Zeller, A., Weissgerber, P. and Diehl, S. (jun 2005). Mining version histories to guide software changes. Software Engineering, IEEE Transactions on, v. 31, n. 6, p

30 Análise de Métricas Estáticas para Sistemas JavaScript Miguel Esteban Ramos 1, Marco Tulio Valente 1 1 Departamento de Ciência da Computação Universidade Federal de Minas Gerais (UFMG) Belo Horizonte, MG Brazil {miguel.ramos, mtov}@dcc.ufmg.br Abstract. JavaScript is a dynamic and prototype-based programming language that is being increasingly used in software development. Thanks to initiatives like Node.js, JavaScript is not anymore just a client-side language used to make DOM manipulations but turned itself into a language with all the features to implement full systems on both client and server side. Nevertheless, it is still hard to find tools and resources to analyze and verify the quality of JavaScript systems. This paper presents the results of the collection and analysis of 15 software metrics for a set of 50 JavaScript systems. Resumo. JavaScript é uma linguagem dinâmica e baseada em protótipos que cada dia é mais utilizada para o desenvolvimento de software. Graças a iniciativas como Node.js, JavaScript deixou de ser uma linguagem que só é utilizada no lado do cliente para fazer manipulações do DOM, para se tornar uma linguagem com todas as funcionalidades para implementar sistemas completos tanto do lado do cliente quanto do lado do servidor. Mesmo assim, ainda é difícil encontrar ferramentas e recursos que permitam analisar e verificar a qualidade de sistemas JavaScript. Neste trabalho, apresentam-se os resultados da coleta e análise de 15 métricas de software para um conjunto de 50 sistemas JavaScript. 1. Introdução JavaScript é uma linguagem de programação que atualmente está ganhando grande popularidade já que, graças à evolução que apresentou nos últimos anos e a melhorias no seu desempenho, tornou-se peça fundamental no desenvolvimento de aplicações web modernas, ricas em conteúdo, interativas e funcionais [Cantelon et al. 2014]. Além disso, a fim de levar todas as características de JavaScript para outros ambientes, surgiram plataformas como Node.js que permitiram expandir o escopo de JavaScript para escrever aplicações que fazem uso intensivo de dados do lado do servidor, contribuindo para popularidade crescente da linguagem. Dado o grande número de sistemas atualmente desenvolvidos em JavaScript, é natural investigar técnicas e métodos para escrever código de qualidade nessa linguagem, fazendo uso de todos os princípios da Engenharia de Software. JavaScript possui um conjunto de características como sua natureza dinâmica e assíncrona, sua orientação a protótipos, sua flexibilidade, entre outras. Essas características geram novos desafios no desenvolvimento desses sistemas e fazem com que alguns conceitos tenham que ser reconsiderados ou adaptados. Finalmente, JavaScript é uma linguagem relativamente nova, sendo que ainda existem poucos estudos que procuram avaliar e aprimorar as práticas de Engenharia de Software adotadas em projetos nessa linguagem. 30

31 Particularmente, um dos recursos mais importantes em Engenharia de Software para a análise de sistemas são métricas de software. Métricas fornecem uma grande variedade de informações, incluindo aspectos de qualidade, complexidade, manutenibilidade, tamanho, etc. Logo, métricas podem ser muito úteis no estudo das tendências e do estado da arte de sistemas JavaScript. Este trabalho analisa um conjunto de métricas calculadas para uma coleção de 50 sistemas JavaScript cujo código-fonte foi pesquisado no sistema de controle de versões GitHub. O objetivo principal é que a análise desse conjunto de dados permita-nos obter informações sobre a forma, o tamanho e a complexidade dos sistemas JavaScript, bem como analisar quais tipos de métricas estão disponíveis para esses sistemas. O restante deste artigo está organizado conforme descrito a seguir. Na Seção 2, apresenta-se a metodologia utilizada para realizar a coleta de métricas, incluindo uma descrição da ferramenta utilizada. Na Seção 3, é apresentada a análise de resultados para três grupos de métricas. Na Seção 4, descreve-se brevemente alguns trabalhos relacionados. Na Seção 5, são apresentadas as conclusões finais do artigo. 2. Metodologia As métricas consideradas neste trabalho foram obtidas para um conjunto de 50 sistemas JavaScript escolhidos manualmente desde o sistema de controle de versão GitHub. A ferramenta utilizada para efetuar as medidas foi escomplex 1. Essa ferramenta foi escolhida depois de realizar uma busca das ferramentas atualmente disponíveis para esse propósito e perceber que escomplex era a melhor opção por oferecer o maior número de métricas e ser a base de medição utilizada por outras ferramentas semelhantes Escomplex Escomplex é uma ferramenta cujo objetivo é calcular métricas de software relacionadas principalmente com a complexidade de sistemas JavaScript. Escomplex faz a medição para cada função de um arquivo JS e também oferece um conjunto de medidas para o arquivo inteiro. A fim de obter essas medidas, escomplex gera uma Árvore Sintática Abstrata (AST) do código por meio de esprima (conhecido parser JavaScript) e posteriormente caminha nessa árvore para calcular as medidas estaticamente. As métricas oferecidas por escomplex são as seguintes: Número de módulos: Cada arquivo JS do sistema é considerado um módulo. Linhas de código: Contagem das linhas de código físicas (número de linhas en um módulo ou função) e lógicas (número de declarações imperativas). Número de parâmetros: É o número de parâmetros obtido da assinatura de cada função. É uma medida estática e, por isso, não são levadas em consideração as funções que dependem do parâmetro arguments. Complexidade ciclomática (CC): É a contagem do número de caminhos linearmente independentes no grafo de fluxo de controle do programa. [McCabe 1976] Densidade de complexidade ciclomática: Proposta como uma modificação para a complexidade ciclomática, esta métrica expressa a CC como uma porcentagem do número de linhas de código lógicas [Gill and Kemerer 1991]

32 Métricas de complexidade de Halstead: Conjunto de métricas que são calculadas com base no número de operadores distintos, o número de operandos distintos, o número total de operadores e o número total de operandos em cada função. Estas métricas são utilizadas para avaliar a complexidade do sistema. Índice de manutenção: Métrica de complexidade medida numa escala logarítmica, calculada a partir das linhas lógicas de código, a complexidade ciclomática e o esforço Halstead [Kuipers and Visser 2007] Coleta de Métricas Para obter os dados de medição apresentados neste trabalho foi necessário baixar o código de 50 sistemas JavaScript e desenvolver um programa encarregado de percorrer cada um desses sistemas, realizar as medidas por meio da ferramenta escomplex e construir uma tabela onde foram registradas todas essas medidas. GitHub, o sistema de controle de versões, foi usado para pesquisar os sistemas utilizados neste trabalho e para baixar o código-fonte de cada um deles. Esse procedimento foi feito manualmente já que ainda é difícil encontrar um padrão utilizado globalmente nos sistemas JavaScript para a organização do código e, portanto, existe um alto risco de incluir código indesejado se o procedimento for feito automaticamente. Além disso, escolheram-se sistemas com uma alta popularidade no GitHub (maior número de stars), um número representativo de commits (pelo menos 150) e que não são uma cópia (fork) de outros projetos existentes. A Figura 1 descreve os passos que foram seguidos a fim de obter as medições para cada sistema. Figura 1. Procedimentos para coleta de métricas O primeiro passo foi criar manualmente um arquivo JSON onde se encontra um vetor cujos elementos são objetos que representam cada sistema JS e armazenam informações como o nome, a versão e a localização da pasta onde fica o código principal do projeto. Esse arquivo é então usado como um parâmetro de entrada para o bloco en- 32

33 carregado do processamento de cada sistema JS e da geração da tabela com as medidas para cada um deles. O programa desenvolvido a fim de explorar cada sistema e gerar o conjunto final de dados, foi escrito em JavaScript, utilizando Node.js. Inicialmente, o programa extrai recursivamente todos os arquivos.js que compõem o sistema descartando apenas os arquivos e as pastas que não atendem às condições de um filtro proposto para evitar o processamento dos arquivos que contêm código que não pertence ao núcleo dos sistemas. Nesse último passo são excluídos os arquivos de produção (.min.js), arquivos de direitos autorais (copyright.js), pastas de documentação (doc, docs), pastas de testes (test), pastas de exemplos (example, examples) e pastas que incluem dependências de terceiros (thirdparty ou node modules). Posteriormente, fazendo uso da ferramenta escomplex, foram realizadas as medidas para cada arquivo JavaScript que atendeu ao filtro e contaram-se o número de arquivos que geraram erros durante esse processo (esses erros geralmente são devido a problemas de sintaxe no arquivo que está sendo processado). Por fim, nos casos de algumas métricas, calcula-se uma medida para o sistema inteiro. Por exemplo, o número de linhas de código do sistema é calculado como a soma do número de linhas de código de cada módulo; por outro lado, a complexidade ciclomática do sistema é calculada como a média desta medida para cada módulo com seu respectivo desvio padrão. Por fim, o último módulo se encarrega de percorrer o vetor onde se encontram todos os sistemas e da geração de uma tabela no formato HTML, onde são sumarizadas as medidas para cada sistema. 3. Resultados A tabela com os resultados de todas as medições realizadas para cada sistema JS, além do seu nome e a versão utilizada para a medição, estão disponíveis no seguinte link: A fim de analisar os resultados obtidos, usou-se o programa R Métricas de Tamanho A Figura 2 permite visualizar a distribuição da medida do tamanho (linhas de código) dos sistemas JS medidos. Figura 2. Linhas de cógido lógicas 33

34 Essa distribuição mostra que a maioria dos sistemas de JS considerados neste trabalho possui um tamanho relativamente pequeno. Depois de verificar os quartis calculados para esse conjunto de dados, pode-se concluir que 75% dos sistemas têm um número de linhas de código menor ou igual a 4,85 KLOC e que o tamanho de 50% das amostras não excede a 1,3 KLOC. No boxplot da Figura 2, também pode-se notar que algumas medidas têm valores muito discrepantes correspondentes a seis amostras com número de linhas de código que vão desde 11,82 KLOC até 170,58 KLOC. Resumo dos Resultados: Embora a maior parte dos sistemas medidos neste trabalho tenha um tamanho pequeno, é possível afirmar que existem também sistemas JS cujo tamanho é comparável ao de sistemas desenvolvidos em outras linguagens de programação (Java, C + +, etc) e que, portanto, JavaScript está sendo usado para desenvolver programas que vão além da manipulação do DOM do lado do cliente para aspectos de apresentação Métricas de Organização Modular Usando os dados coletados neste trabalho, é possível vislumbrar algumas tendências existentes na organização e separação do código dos sistemas JavaScript. Hoje em dia existem vários padrões que descrevem como o código escrito em JavaScript pode ser organizado. Entre eles, o padrão de módulos é um dos mais populares. Os gráficos da Figura 3 apresentam a distribuição do número de módulos e o número de funções por módulo dos sistemas considerados no presente trabalho. Figura 3. Módulos e funções por módulos Um dos aspectos que chama atenção nos gráficos da Figura 3 é que o primeiro quartil da medida é igual a 1. Isso significa que pelo menos 25% dos sistemas são implementados em um único arquivo (módulo). No entanto, também é possível observar que metade dos sistemas apresentam mais de 13 módulos. Além disso, os três maiores sistemas possuem 403, 539 e 574 módulos. Ao realizar uma análise isolada do número de linhas de código dos sistemas que foram implementados em um único módulo, encontrou-se que 75% desses sistemas têm menos de 0.93 KLOC e que nenhum deles possui mais de 1.47 KLOC. No que se refere àqueles sistemas com mais de 13 módulos, 75% desses sistemas têm mais de 2.28 KLOC. Após o cálculo do coeficiente de Spearman, cujo resultado foi de 0.84, determinou-se que existe uma correlação forte entre o número de módulos e o número de linhas de código de cada sistema. 34

35 Além disso, no que diz respeito ao número de funções por módulo, os resultados mostram que 50% dos sistemas têm uma média menor do que 14,4 funções por módulo. Por outro lado, 25% dos sistemas têm mais do que 36,6 funções por módulo, o que a princípio é um número alto. Após a realização de uma verificação manual na tabela de resultados, foi possível confirmar que a maioria dos sistemas incluídos nesse 25% corresponde a sistemas que foram implementados em um único módulo. Resumo dos Resultados: Os resultados mostram que, quando se trata de sistemas pequenos, é muito provável que esses sejam implementados em um único arquivo JavaScript. No entanto, à medida que aumenta o tamanho dos sistemas, o código tende a ter uma melhor modularização Métricas de Complexidade Os gráficos da Figura 4 mostram as distribuições das medidas de complexidade ciclomática e índice de manutenibilidade. Figura 4. Complexidade ciclomática e Índice de manutenção O terceiro quartil da medida de complexidade mostra que 75% dos sistemas considerados neste trabalho apresentam uma complexidade ciclomática menor que 66,69. Levando em consideração que, segundo Alves et al. [Alves et al. 2010], apenas métodos com medidas de complexidade acima de 14 deveriam ser considerados de alto risco para sistemas Java, e que uma classe típica em Java possui cerca de 10 métodos (o que deixa esse limite em 140 por classe), podemos concluir que complexidades ciclomáticas médias menores que 66,69 não representam uma medida alta. Somente três dos sistemas avaliados apresentaram medidas maiores do que 200. Por outro lado, no que se refere a medida de índice de manutenibilidade, todos os sistemas apresentam um valor maior que 90 para essa medida. Assim, considerando os limites apresentados em [Coleman et al. 1994], todos os sistemas medidos apresentaram uma alta manutenibilidade ( 85 ). Isso não faz muito sentido já que índices de manutenibilidade mais baixos deveriam ter sido obtidos pelo menos para aqueles sistemas que apresentam uma altíssima complexidade ciclomática ou uma grande quantidade de funções por módulo. Uma crítica semelhante ao índice de manutenibilidade é feita em [Fard and Mesbah 2013], dado que não se encontrou uma relação entre a má qualidade de código (code smells) e o índice de manutenibilidade de cada sistema. Outra discussão sobre problemas com esta métrica é apresentada em [Kuipers and Visser 2007]. 35

36 Resumo dos Resultados: Para a grande maioria dos sistemas JavaScript analisados, as medidas de complexidade ciclomática são adequadas, pelo menos quando contrastadas com aquelas normalmente aceitas em sistemas Java. Por outro lado, no caso do índice de manutenibilidade, os resultados são menos conclusivos, reforçando as críticas a essa métrica encontradas na literatura. 4. Trabalhos Relacionados Atualmente, existe um pequeno grupo de ferramentas usadas para medições de software em sistemas JavaScript. A maioria dessas ferramentas, como escomplex, estão focadas na análise de complexidade. Plato 2 é uma das ferramentas mais populares, pois faz uso de complexityreport.js 3 e JShint 4 para calcular métricas e gerar um relatório completo via gráficos interativos, que permitem comparações entre as medidas de cada módulo. JSNose [Fard and Mesbah 2013] apresenta uma técnica para detecção de code smells que combina análise estática e dinâmica, a fim de encontrar padrões no código que possam resultar em problemas de compreensão e manutenção. Adicionalmente, são propostas algumas métricas alternativas para sistemas JavaScript, mas apenas é mostrado o resultado de cinco medidas feitas para 11 sistemas, fazendo uso da ferramenta complexityreport.js. Finalmente, uma análise da correlação entre o número de code smells detectados e as medições efetuadas em todos os sistemas é realizada. 5. Conclusão Estudos similares aos reportados neste artigo existem para outras linguagens, notadamente Java [Baxter et al. 2006] e [Terra et al. 2013]. No entanto, no melhor de nosso conhecimento, este artigo reporta o mais extenso estudo realizado até o momento com o objetivo de caracterizar o comportamento estático de sistemas JavaScript, uma das linguagens mais populares atualmente. Como uma segunda contribuição, temos a disponibilização pública de um dataset de sistemas nessa linguagem, inspirado em datasets largamente utilizados em estudos empíricos envolvendo linguagens estáticas, como Java [Terra et al. 2013] e [Tempero et al. 2010]. Após a análise dos dados foram encontrados os seguintes resultados principais: (a) apesar de existirem ainda pequenos sistemas JavaScript, já existem também sistemas cujo grande tamanho sugere que são programas que vão além de pequenos scripts utilizados para manipulação do DOM; (b) no que se refere a modularidade, encontrou-se que aqueles sistemas pequenos são implementados inteiramente em um só módulo (arquivo) e que, somente aqueles de maior tamanho apresentam uma melhor distribuição do código fazendo uso de um maior número de módulos; (c) com relação às medidas de complexidade ciclomática, mostrou-se que a grande maioria dos sistemas JavaScript possuem valores adequados para essa medida quando comparados com valores comumente aceitos e praticados em sistemas Java. Trabalhos futuros podem incluir um número maior de sistemas, adição de mais métricas utilizando ferramentas de medição de software alternativas, incluindo métricas que considerem também o comportamento dinâmico de sistemas JavaScript. Pretendemos

37 também investigar valores de referência (thresholds) para essas métricas, usando a técnica proposta por Oliveira et al. [Oliveira et al. 2014]. Por fim, pretendemos trabalhar em uma versão histórica do dataset proposto, com dados de evolução dos sistemas JavaScript, a exemplo do que ocorre com datasets já disponibilizados para Java [Couto et al. 2013]. Agradecimentos Esta pesquisa foi apoiada pelo PEC-PG - CNPq e FAPEMIG Referências Alves, T. L., Ypma, C., and Visser, J. (2010). Deriving metric thresholds from benchmark data. In 2010 IEEE International Conference on Software Maintenance (ICSM), pages IEEE. Baxter, G., Frean, M., Noble, J., Rickerby, M., Smith, H., Visser, M., Melton, H., and Tempero, E. (2006). Understanding the shape of Java software. In 21th Conference on Object Oriented Programming, Systems, Languages and Applications (OOPSLA), pages Cantelon, M., Holowaychuk, T., Rajlich, N., and Harter, M. (2014). Node. js in Action. Manning Publications. Coleman, D., Ash, D., Lowther, B., and Oman, P. (1994). software system maintainability. Computer, 27(8): Using metrics to evaluate Couto, C., Maffort, C., Garcia, R., and Valente, M. T. (2013). COMETS: A dataset for empirical research on software evolution using source code metrics and time series analysis. ACM SIGSOFT Software Engineering Notes, pages 1 3. Fard, A. M. and Mesbah, A. (2013). Jsnose: Detecting javascript code smells. In IEEE 13th International Working Conference on Source Code Analysis and Manipulation (SCAM), pages IEEE. Gill, G. K. and Kemerer, C. F. (1991). Cyclomatic complexity density and software maintenance productivity. IEEE Transactions on Software Engineering, 17(12): Kuipers, T. and Visser, J. (2007). Maintainability index revisited position paper. In Special Session on System Quality and Maintainability (SQM 2007) of the 11th European Conference on Software Maintenance and Reengineering (CSMR 2007). McCabe, T. J. (1976). A complexity measure. IEEE Transactions on Software Engineering, SE-2(4): Oliveira, P., Valente, M. T., and Lima, F. (2014). Extracting relative thresholds for source code metrics. In IEEE Conference on Software Maintenance, Reengineering and Reverse Engineering (CSMR-WCRE), pages Tempero, E., Anslow, C., Dietrich, J., Han, T., Li, J., Lumpe, M., Melton, H., and Noble, J. (2010). The Qualitas corpus: A curated collection of Java code for empirical studies. In Asia-Pacific Software Engineering Conference (APSEC), pages Terra, R., Miranda, L. F., Valente, M. T., and Bigonha, R. S. (2013). Qualitas.class Corpus: A compiled version of the Qualitas Corpus. Software Engineering Notes, pages

38 Migração Parcial de um Banco de Dados Relacional para um Banco de Dados NoSQL na Nuvem Através de Adaptações Não-intrusivas: Um Relato de Experiência Caio H. Costa 1, Lincoln S. Rocha 2, Nabor C. Mendonça 3, Paulo Henrique. M. Maia 1 1 Mestrado Acadêmico em Ciências da Computação (MACC) Universidade Estadual do Ceará (UECE) Campus do Itaperi, Av. Paranjana, 1700, CEP Fortaleza - CE 2 Universidade Federal do Ceará (UFC) Campus de Quixadá, Av. José de Freitas Queiroz, 5002, CEP Quixadá - CE 3 Programa de Pós-Graduação em Informática Aplicada (PPGIA) Universidade de Fortaleza (UNIFOR) Av. Washington Soares, 1321, Edson Queiroz, CEP Fortaleza - CE caiohc@gmail.com, lincolnrocha@ufc.br, nabor@unifor.br, pauloh.maia@uece.br Abstract. This paper reports the experience of partially migrating the relational database of a legacy system to a NoSQL database in the cloud in order to resolve performance issues. Part of the relational database data was adapted and migrated to the NoSQL database. The adaptations of the two applications that make up the system were performed using a non-intrusive approach based on aspect-oriented programming and dynamic features of the Groovy programming language. After the necessary adjustments, the system became able to simultaneously access the relational database and the new DynamoDB database on Amazon cloud. Resumo. Este trabalho relata a experiência de migração parcial do banco de dados relacional de um sistema legado para um banco de dados NoSQL na nuvem, a fim de solucionar problemas relacionados a desempenho. Parte dos dados do banco de dados relacional foi adaptada e migrada para o banco de dados NoSQL. As adaptações das duas aplicações que compõem o sistema foram realizadas por meio de uma abordagem não-intrusiva baseada em programação orientada a aspectos e funcionalidades dinâmicas da linguagem de programação Groovy. Após as adaptações necessárias, as duas aplicações passaram a acessar simultaneamente a base de dados relacional e a nova base de dados DynamoDB, na nuvem da Amazon. 1. Introdução Este trabalho relata a migração parcial da base de dados relacional de uma aplicação legada para um banco de dados NoSQL na nuvem, a fim de solucionar problemas de desempenho oriundos do crescimento exponencial da sua maior, e mais importante, tabela. Trata-se de um sistema de monitoramento veicular composto de duas aplicações: uma web, chamada RastroBR, e outra standalone, chamada RBRDriver. 38

39 Ambas as aplicações compartilham o conceito de posição na descrição dos seus domínios. Uma posição caracteriza a localização georeferenciada de um veículo monitorado pelo sistema. Os dados relativos à posição do veículo são enviados a uma base de dados em intervalos fixos de um minuto. Como consequência do contínuo aumento no número de veículos monitorados, o volume de dados armazenados na tabela posicao passou a crescer em uma taxa exponencial. Desse modo, em conseqüência do tamanho 1 e do rápido crescimento da tabela posicao, operações de consulta e de inserção de registros nessa tabela tonaram-se cada vez mais lentas. Para amenizar esse problema, um escalonamento vertical no servidor de banco de dados foi realizado algumas vezes. Porém, além dessa ser uma solução cara, ela apresenta limites práticos de implementação. De acordo com [Sadalage and Fowler 2013], bancos de dados relacionais não foram projetados para serem escalonados horizontalmente. Já os bancos de dados NoSQL orientados a agregados, por outro lado, foram projetados para lidar com grandes volumes de dados por meio do escalonamento horizontal. Desse modo, uma alternativa baseada em um banco de dados NoSQL tornou-se a mais viável para o problema descrito. Uma vez que o banco de dados NoSQL DynamoDB [Sivasubramanian 2012], na nuvem da Amazon, foi escolhido, era necessário adequar e migrar os dados da tabela posicao para uma coleção do DynamoDB e adaptar as duas aplicações que compõem o sistema para que ambas passassem a trabalhar com o DynamoDB. Porém, essa solução deveria ser utilizada apenas para a entidade posição. Todas as outras entidades deveriam continuar na base de dados relacional por causa das restrições de integridade que não são oferecidas em bases de dados NoSQL, além das mesmas não darem suporte a relacionamentos entre coleções. Além disso, a adaptação das aplicações deveria ser realizada da forma menos intrusiva possível a fim de evitar a inserção de erros e facilitar o trabalho dos desenvolvedores que não conheciam bem a arquitetura do sistema. O restante do artigo está dividido da seguinte forma: a Seção 2 discute os principais trabalhos relacionados; a Seção 3 apresenta a arquitetura das duas aplicações que compõem o sistema; a Seção 4 descreve a migração dos dados da tabela posicao para uma coleção no DynamoDB; a adaptação das duas aplicações é relatada na Seção 5; por fim, a Seção 6 traz as conclusões e sugestões de trabalhos futuros. 2. Trabalhos Relacionados Em [Jamshidi et al. 2013], uma revisão sistemática identifica 23 pesquisas focadas em migrações de aplicações legadas para a nuvem. Os autores classificam as migrações em: substituição, parcial, pilha completa, e cloudificação. De acordo com essa classificação, a migração que o relato de experiência deste trabalho aborda é caracterizada como uma migração por substituição. Nenhuma das pesquisas que fizeram parte da revisão sistemática em [Jamshidi et al. 2013] é caracterizada como tal. Lições aprendidas durante a transição de uma grande base de dados relacional para um modelo híbrido, que combina um banco de dados relacional e um banco de dados NoSQL, são relatadas em [Schram and Anderson 2012]. O sistema abordado nesse trabalho é composto de serviços e foi adaptado de forma pouco intrusiva, pois a composição 1 Durante o período de escrita deste artigo, o tamanho da tabela posicao era, aproximadamente, 110GB. 39

40 dos serviços era realizada por meio da injeção de dependência do framework Spring, injetando em tempo de execução implementações concretas em referências de tipos abstratos. A aplicação RastroBR realiza injeção de dependência por meio do framework Spring, porém sua adaptação foi realizada utilizando aspectos para que a modificação fosse mais granular e pontual. Em [Vu and Asal 2012] é realizada uma análise das principais plataformas de nuvem do mercado. Três exemplos de migração de aplicações são apresentados. A diferença entre os exemplos apresentados em [Vu and Asal 2012] para o relato deste trabalho é que em [Vu and Asal 2012] todas as modificações foram realizadas de forma intrusiva, uma vez que não se tratava de uma aplicação comercial em produção. O trabalho [Chauhan and Babar 2011] relata a migração por pilha completa [Jamshidi et al. 2013] da ferramenta Hackystat para a nuvem. Os serviços que compõem a ferramenta foram implantados separadamente em instâncias da nuvem Amazon EC2 que utilizam o recurso de elasticidade. Os autores concluem que sistemas que dividem a lógica do negócio entre aplicação e base de dados, por meio de gatilhos e outras funcionalidades, são mais difíceis de migrar porque a nuvem deve oferecer um banco de dados que possibilite que as mesmas estruturas possam ser executadas. Essa é uma das razões que fez com que a migração da base de dados das aplicações RBRDriver e RastroBR fosse parcial, pois a mesma contém gatilhos que fazem parte da lógica do negócio. Os autores em [Vasconcelos et al. 2013] propõem uma abordagem não-intrusiva baseada em eventos para adaptar o código de uma aplicação legada para o ambiente de nuvem levando em conta as restrições dessa nova plataforma. Nessa abordagem, o código fonte da aplicação é interceptado usando, por exemplo, programação orientada a aspectos, e seu fluxo de execução é direcionado para um serviço similar na nuvem através da utilização de um middleware baseado em eventos. Como prova de conceito, os autores sugerem a utilização de aspectos para interceptar a persistência de arquivos em disco e armazená-los na nuvem sem modificar o código legado da aplicação. A adaptação relatada neste trabalhou foi baseada nessa idéia, porém os aspectos foram utilizando para desviar a persistência de dados de uma base de dados relacional para uma base de dados NoSQL na nuvem. 3. Arquitetura do Sistema O RBRDriver é uma aplicação standalone, escrita em Groovy [König et al. 2007], cuja principal função é decodificar os pacotes enviados pelos veículos monitorados e persistir suas posições na base de dados, além de enviar comandos e configurações para os equipamentos instalados nos veículos. Cada posição decodificada é inserida como um registro na tabela posicao no SGBD relacional PostgreSQL. O RBRDriver utiliza o padrão DAO, em combinação com o padrão Abstract Factory, para interagir com a base de dados. A classe PositionCodec é responsável por decodificar e persistir os dados recebidos. Essa classe possui uma referência do tipo DaoFactory, uma interface, e requisita a ela objetos DAO para consultar dados e persistir as posições dos veículos na tabela posicao. O tipo concreto da fábrica de objetos DAO, a referência do tipo DaoFactory, é definido em um arquivo de configuração. Nesse arquivo é definida a classe SqlFactory 40

41 como fábrica de objetos DAO. Portanto, todo objeto DAO retornado por objetos DaoFactory são DAOs específicos para interagir com bancos de dados relacionais. Não é possível alterar essa configuração para que uma implementação de fábrica especifica para uma base de dados NoSQL em particular seja utilizada. Dessa maneira, toda a família de objetos DAO seria alterada. Isso não é interessante porque, além de persistir as localizações dos veículos, a aplicação também executa outras funções, como envio de comandos e configurações, e os dados necessários para a execução dessas funções necessitam dos relacionamento e integridade oferecidos pela base de dados relacional. O RastroBR é uma aplicação web que permite que os usuários acompanhem o deslocamento dos veículos, mantenham os cadastros de clientes, usuários e veículos, e obtenham relatórios de deslocamento e estatísticas. Assim como o RBRDriver, o RastroBR utiliza o padrão DAO em conjunto com o padrão Abstract Factory para implementar a camada de acesso ao banco de dados. No RastroBR as classes DAO utilizam o framework GORM [Fischer 2009], sendo esse, por sua vez, implementado sobre os frameworks Spring e Hibernate. Figura 1. posições. Interfaces e classes DAO, do RastroBR, relacionadas à consulta de Os relatórios oferecidos pelo RastroBR aplicam regras de negócio sobre registros da tabela posicao, tendo seus desempenhos afetados por ela. As classes de serviço dos relatórios possuem uma referência cujo tipo é a interface DaoFactory, por meio da qual obtêm as classes DAO para interagir com a base de dados. Através da capacidade de injeção de dependência do framework Spring, a classe concreta que implementa a interface DaoFactory pode ser facilmente trocada por meio de um script de configuração. Em tempo de execução, a referência do tipo PosicaoDao obtida é um objeto do tipo GormPosicaoDao que consulta as posições da tabela posicao para criar os relatórios requisitados (Figura 1). 4. Migração dos dados O banco de dados escolhido, o DynamoDB, é um banco de dados NoSQL orientado a agregados [Sadalage and Fowler 2013]. O conceito de agregado é bastante apropriado para a arquitetura escalonada horizontalmente. Um agregado informa ao banco de dados quais dados devem ser tratados como uma única unidade indivisível, e, por isso, os mesmos devem ser mantidos em um mesmo servidor. No entanto, dois agregados diferentes, mesmo sendo de uma mesma coleção, não precisam ser mantidos em um mesmo servidor. 41

42 A ausência de relacionamentos entre agregados, como aqueles mantidos por meio de chaves estrangeiras em bancos de dados relacionais, propicia a divisão dos dados entre vários nós. Porém, por causa dessa característica, não é possível, em uma única consulta, realizar junções entre agregados de coleções diferentes. A persistência dos dados do sistema dependia do relacionamento entre entidades oferecido pelo modelo relacional. Figura 2. Adaptação dos dados da tabela posicao para uma coleção NoSQL. Apesar de sua importância, a tabela posicao armazena apenas dados históricos que não são editados. Essa particularidade permitiu adaptar seus dados para uma coleção NoSQL. A adequação dos dados foi realizada unindo em um único agregado cada registro da tabela posicao com os registros de outras tabelas referenciados pelas chaves estrangeiras dela 2. Assim, os agregados da coleção resultante fornecem, em apenas uma consulta, todos os dados necessários para a emissão dos relatórios do sistema. A Figura 2 mostra, de forma simplificada 3, a tabela posicao referenciando outras tabelas, e como seus dados foram adaptados para uma coleção trazendo os dados dos registros referenciados para junto dos registros da própria tabela, criando um agregado. 5. Adaptação do Sistema Para utilizar técnicas de programação orientada a aspectos na adaptação da aplicação RastroBR, foi utilizado o framework Spring AOP (Aspect Oriented Programming). No Spring AOP, os aspectos são implementados utilizando classes Java comuns. É possível indicar ao framework quais classes implementam aspectos utilizando XML em um arquivo de configuração, e nas classes, especificar os joint points e advices por meio de annotations. A estratégia adotada foi criar um aspecto contendo um advice do tipo around, que intercepta o método getposicaodao da interface DaoFactory e retorna uma implementação DAO apropriada para o DynamoDB, ao invés de uma implementação para um banco de dados relacional, como em todo o resto da aplicação. No RastroBR, uma implementação da interface DaoFactory é injetada nos serviços utilizando a injeção de dependência do Spring e, quando esses requisitam um DAO, obtêm DAOs de uma mesma família, no caso, implementações para um banco de dados relacional. 2 O escopo deste trabalho não aborda as consequências referentes à perda de normalização dos dados. 3 Os demais campos das tabelas não são exibidos por serem dispensáveis para o entendimento da solução. 42

43 Para modificar esse comportamento foi implementado um advice apenas para as classes de serviços relacionadas aos relatórios que dependem da tabela posicao. Esse advice intercepta o pointcut correspondente à chamada de método que retorna um DAO da entidade posicao, e, ao invés de retornar uma classe que faça parte da família de classes definida pela injeção de dependência, retorna uma implementação própria para interagir com a coleção posicao no banco DynamoDB, mas que também implementa a interface PosicaoDao. Um trecho de código do aspecto que contém esse advice é exibido na Figura 3. A linha 13 exibe o pointcut que intercepta a chamado ao método getposicaodao da interface DaoFactory, e a linha 15 retorna uma implementação DAO para o DynamoDB. Figura 3. Advice retorna um DAO DynamoDB ao invés de uma DAO relacional. Com a implementação do aspecto contendo o advice exibido na Figura 3, um objeto da classe RelatorioService chama o método getposicaodao da interface DaoFactory para consultar a a tabela posicao. Nesse momento, um advice da classe DaoFactoryAspect intercepta essa chamada e, ao invés do fluxo normal acontecer, que seria a classe Factory (que implementa a interface DaoFactory) retornar uma instância de acordo com sua família, por exemplo um GormPosicaoDao, o aspecto retorna para a classe cliente uma instância do tipo DynamoDbPosicaoDao. A classe DynamoDbPosicaoDao também implementa a interface PosicaoDao e é com essa interface que a classe cliente, RelatorioService, interage. Portanto, não houve nenhuma incompatibilidade e o código da classe RelatorioService não necessitou de alterações. Para que o aspecto seja ativado, passando a interceptar os pointcuts que foram especificados em seus advices, é necessário indicar para Spring AOP quais classes são aspectos. Isso é feito através da definição do bean no script de configuração dos Spring beans da aplicação. Semelhantemente ao RastroBR, no RBRDriver foi implementado um aspecto, utilizando AspectJ [Kiselev 2002], contendo um advice do tipo around, para capturar as chamadas ao método getposicaodao da interface DaoFactory. No entanto, o advice do aspecto estava sendo executado diversas vezes ao invés de ser executado apenas uma vez para cada chamada ao método getposicaodao da interface DaoFactory. As funcionalidades dinâmicas da linguagem Groovy não permitiam o funcionamento correto do aspecto. O artigo [McClean 2006] 4 apontou uma solução. Em uma aplicação Groovy, para cada classe carregada na memória existe uma metaclasse correspondente que possui todas 4 MCCLEAN, J. Painless AOP with Groovy. InfoQueue, 2 October Disponivel em: Acesso em: 27 Janeiro

44 as propriedades e métodos da classe à qual ela está relacionada. De acordo com o protocolo que rege as chamadas de método em aplicações Groovy, uma chamada de método para um objeto é direcionada para uma instância da metaclasse deste objeto, ao invés do objeto propriamente dito. Groovy permite trocar a metaclasse de uma classe em tempo de execução, alterando dinamicamente o comportamento de todas as instâncias dessa classe. Dessa maneira, é possível alterar dinamicamente o comportamento de uma classe sem modificar seu código fonte. Uma das maneiras de fazer isso é pôr a metaclasse substituta, nomeada de forma adequada, em um pacote específico, cujo nome e posição na hierarquia de pacotes depende da classe cuja metaclasse será substituída. Como qualquer classe Groovy, a classe SqlPosicaoDao, responsável por salvar as posições dos veículos na tabela posicao, possui uma metaclasse com cópias de todos os seus métodos e propriedades. Para cada método chamado na classe SqlPosicaoDao, na realidade, o método equivalente é chamado na metaclasse. Ou seja, quando o método save é chamado na classe SqlPosicaoDao, o que realmente acontece é uma chamada ao método invokemethod na metaclasse de SqlPosicaoDao, que por sua vez chama o método save da metaclasse. Portanto, era necessário substituir a metaclasse padrão fornecida pelo compilador por uma metaclasse com uma implementação adequada para o DynamoDB. Isso foi realizado através do método citado anteriormente, a substituição da metaclasse padrão da classe SqlPosicaoDao por meio da adição de uma nova metaclasse, no pacote apropriado, no classpath da aplicação. A nova metaclasse foi nomeada SqlPosicaoDaoMetaClass e foi colocada no pacote groovy.runtime.metaclass.com.azultecnologia.dao.sql seguindo o padrão necessário para que a substituição da metaclasse padrão ocorra. Na metaclasse substituta foi implementado um código que utilizasse o DAO DynamoDbPosicaoDao para armazenar a posição no banco de dados DynamoDB e retornar o mesmo valor que seria retornado pelo método save da classe SqlPosicaoDao. Depois da alteração, ao chamar o método save da classe SqlPosicaoDao, o método invokemethod da nova metaclasse é executado e a classe DynamoDbPosicaoDao é utilizada para armazenar a posição. Por fim, o número de posições armazenadas é retornado. Assim, um efeito semelhante a um advice do tipo around é obtido. 6. Conclusões A utilização de aspectos para adaptar a aplicação RastroBR, como sugerido em [Vasconcelos et al. 2013], para modificar aplicações de forma não intrusiva, se mostrou valiosa. A AOP foi utilizada não para tratar um interesse que permeia toda a aplicação, mas apenas a persistência de um domínio em uma base de dados alternativa. Essa abordagem pode ser utilizada para tratar diversos outros casos onde seja necessário adaptar código de aplicações de forma não intrusiva. É difícil adaptar uma aplicação para que toda a sua base de dados relacional seja migrada para um banco de dados NoSQL. De acordo com [Sadalage and Fowler 2013], quando uma aplicação utiliza um banco de dados NoSQL, seu domínio deve ser projetado desde o início tendo em mente as características desse tipo de banco de dados. Bases de dados NoSQL não possuem muitos dos recursos de relacionamento entre entidades e inte- 44

45 gridade que os arquitetos já possuem em mente no momento em que projetam o domínio de uma aplicação. Porém, como visto neste relato de experiência, em alguns casos, é possível migrar parte dos dados quando estes apresentam características que permitam uma adaptação. As metaclasses Groovy foram utilizadas de forma muito semelhante a aspectos, a fim de alcançar o objetivo de modificar a aplicação de forma não-intrusiva. As funcionalidades dinâmicas da linguagem Groovy podem ser utilizadas como aspectos em aplicações Groovy, evitando a adição de mais um framework na aplicação. Pretendemos, como trabalho futuro, aplicar as técnicas utilizadas na migração relatada neste artigo com outras soluções de bancos de dados NoSQL e realizar um comparativo relacionado a desempenho, facilidade de implementação, gerenciamento oferecido pela nuvem, entre outros. Outro trabalho interessante é utilizar apenas as funcionalidades da linguagem Groovy para capturar os pontos de interesse das aplicações e comparar essa abordagem com a que utiliza programação orientada a aspectos. Referências Chauhan, M. A. and Babar, M. A. (2011). Migrating service-oriented system to cloud computing: An experience report. In 2011 IEEE 4th International Conference on Cloud Computing, pages IEEE. Fischer, R. (2009). Grails Persistence with GORM and GSQL. Apress, 1st edition. Jamshidi, P., Ahmad, A., and Pahl, C. (2013). Cloud migration research: A systematic review. IEEE Transactions on Cloud Computing, 1(2): Kiselev, I. (2002). Aspect-Oriented Programming with AspectJ. Sams, 1st edition. König, D., Laforge, G., King, P., Champeau, C., D Arcy, H., Pragt, E., and Skeet, J. (2007). Groovy In Action. Manning Publications Co., 1st edition. Sadalage, P. J. and Fowler, M. (2013). NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence. Pearson Education, 1st edition. Schram, A. and Anderson, K. M. (2012). Mysql to nosql: data modeling challenges in supporting scalability. In SPLASH 12 Proceedings of the 3rd annual conference on Systems, programming, and applications: software for humanity, pages ACM. Sivasubramanian, S. (2012). Amazon dynamodb: a seamlessly scalable non-relational database service. In SIGMOD 12 Proceedings of the 2012 ACM SIGMOD International Conference on Management of Data, pages ACM. Vasconcelos, M. A., Barbosa, D. M., Maia, P. H. M., and Mendonça, N. C. (2013). Uma abordagem baseada em eventos para adaptação automática de aplicações para a nuvem. In VEM 2013: I Workshop Brasileiro de Visualização, Evolução e Manutenção de Software. Vu, Q. H. and Asal, R. (2012). Legacy application migration to the cloud: Practicability and methodology. In 2012 IEEE Eighth World Congress on Services, pages IEEE. 45

46 Polimorphic View: visualizando o uso de polimorfismo em projetos de software Fabio Petrillo 1, Guilherme Lacerda 12, Marcelo Pimenta 1 e Carla Freitas 1 1 Instituto de Informática Universidade Federal do Rio Grande do Sul (UFRGS) Caixa Postal Porto Alegre RS Brazil 2 Faculdade de Informática - Centro Universitário Ritter dos Reis (Uniritter) Rua Orfanotrófio, Porto Alegre RS Brazil {fspetrillo,gslacerda,mpimenta,carla}@inf.ufrgs.br Abstract. Polymorphism is a powerful and flexible programming mechanism, being one of the key concepts for object-oriented software design and development. Nevertheless, polymorphism has a dark side: if it is used improperly, it can ruin application understandability. Despite its importance, very little attention has been paid to how it is used in software projects, especially because it is very difficult to find and visualize where - in source code or specifications - polymorphism is adopted. In this paper, we discuss how polymorphism is used and propose an approach to explicit the polymorphism usage by representing the software as a static call graph. 1. Introdução O processo de manutenção de software é uma atividade complexa [Lange and Nakamura 1997] e a maior parte do tempo gasto neste processo é dedicado à compreensão do sistema a ser modificado [Caserta and Zendra 2010]. Compreender as dependências entre os diferentes componentes de um software é uma das tarefas mais importantes e desafiadoras em engenharia de software [Hoogendorp 2010]. Consequentemente, a criação de um projeto claro e compreensível, a fim de apoiar a manutenção de sistemas orientados a objetos (OO) é uma preocupação vital para a indústria de software [Mihancea 2009]. Neste contexto, o polimorfismo é um conceito chave na programação OO[Mihancea 2009] [Ponder and Bush 1994], sendo, provavelmente, o seu mecanismo mais poderoso e flexível[ambler 1995] [Booch et al. 2007]. Polimorfismo oferece benefícios como maior extensibilidade e reutilização [Benlarbi and Melo 1999]. Por consequência, a caracterização dos projetos de software com respeito à maneira como eles usam o polimorfismo é importante tanto para a compreensão de software quanto na avaliação da sua qualidade [Mihancea 2009]. Entretanto, apesar de importante, pouco se sabe sobre como polimorfismo é usado em projetos de software, especialmente porque é difícil de encontrar e visualizar sua adoção. Este trabalho tem como objetivo apresentar uma abordagem para a investigação do uso de polimorfismo em projetos de software. Em particular, este artigo aborda os efeitos na invocação de métodos, destacando chamadas polimórficas através da análise estática de software, mostrando a maneira pelo qual os clientes de uma classe com métodos abstratos fazem uso de polimorfismo. Para alcançar este objetivo, foram analisados dois 46

47 projetos desenvolvidos em Java, utilizando uma visualização que torna explícito o uso de polimorfismo através de um grafo de chamadas estáticas, denominado Polymorphic View. Este artigo está organizado da seguinte forma: inicialmente, a seção 2 faz-se uma breve contextualização do problema e a apresenta a visualização proposta. A seção 3 descreve a análise de dois projetos desenvolvidos em Java e a seção 4 apresenta os trabalhos relacionados. Finalmente, a seção5 sumariza as contribuições e descreve algumas possibilidades de trabalhos futuros. 2. Visualizando o Polimorfismo Esta seção apresenta uma abordagem para visualização do uso de polimorfismo. Inicialmente, contextualizamos o problema, com a descrição de um exemplo, com diagramas da UML. Em seguida, descrevemos a representação proposta. Figure 1. Um exemplo de polimorfismo 2.1. Contextualizando o problema Um exemplo típico de polimorfismo é ilustrado no diagrama de classes da Figura 1. Esse diagrama é uma adaptação do modelo apresentado por Booch et al. [Booch et al. 2007]. Nesse exemplo, a interface Drawable é implementada pela classe abstrata Shape e pela classe concreta Line. Shape tem duas subclasses: Circle e Rectangle. Consequentemente, em um programa Java, Line, Circle e Rectangle implementam um método chamado draw(). A classe Plotter é um cliente das implementações de Drawable, instanciando objetos do tipo Drawable e fazendo uma invocação polimórfica, chamando o método draw(). Figure 2. Diagrama de sequência para o exemplo de polimorfismo Em UML, o diagrama de sequência é usado para descrever um conjunto de interações entre objetos [Dutoit and Bruegge 2010]. No diagrama de sequência, para explicitar o polimorfismo, é necessário usar vários diagramas, sendo um para apresentar a mensagem polimórfica para as classes abstratas e outros diagramas para 47

48 detalhar o uso do polimorfismo, iniciando com a mensagem polimórfica [Larman 2004]. Outra possibilidade é o uso comentários ou anotações no diagrama, como pode ser visto na Figura 2. Nesse exemplo, as instâncias de Drawable não são explicitamente representadas e a invocação polimórfica do método draw() pode não ser claramente observada, necessitando de comentários para esclarecer o uso do polimorfismo. Portanto, mesmo em um exemplo simples, não é trivial visualizar invocações polimórficas utilizando diagramas da UML. Finalmente, três artefatos (código, diagramas de classe e de sequência) são necessários para visualizar e compreender o uso de polimorfismo. Com o objetivo de tratar essas questões, propomos uma abordagem para explicitar o uso de polimorfismo em um só diagrama através de uma representação em grafo de chamadas estáticas Polymorphic View O Polymorphic View é uma representação para modelagem de software baseado em grafo orientado de chamadas [Grove et al. 1997] para explicitar o uso de polimorfismo. Ele consiste nos seguintes elementos básicos: Tipos: representado por um retângulo com bordas arredondadas (Figura 3), usado para representar classes e tipos. Tipos concretos (ou instanciáveis) são representados Figure 3. Tipos Concreto, Abstrato e Interface como retângulos com linhas sólidas, enquanto tipos abstratos e interfaces (não instanciáveis) são representados com linhas tracejadas. Como na UML, os tipos abstratos tem seu rótulo em itálico. Somente tipos que tem código fonte disponível são representados, pertencentes ao domínio da aplicação. Invocações: são representadas por linhas sólidas com setas. Já as invocações polimórficas são representados por linhas tracejadas. Os dois tipos de invocações são ilustrados na Figura4. Namespace: namespace é um conteîner para tipos organizados em diretórios. Um namespace é representado por um retângulo com bordas arredondadas e linhas pontilhadas. Em Java, namespaces correspondem aos packages. Figure 4. Invocações 48

49 Usando esta notação, o Polymorphic View é elaborado a partir da análise estática do código. Como pode ser observado pela Figura 5, a interface Drawable é explicitamente representada como um tipo abstrato (borda tracejada) e as invocações polimórficas (chamadas pelo método draw) são representadas por linhas tracejadas para cada implementação de Drawable (tipos Rectangle, Circle e Line). Através dessa visulização, é possível observar que a invocação do método draw pela classe Plotter é representada por uma linha sólida, uma vez que é, de fato, uma invocação do método implementado nos tipos concretos Rectangle, Circle e Line. Neste sentido, o Polymorphic View permite com apenas um diagrama observar o relacionamento entre tipos polimórficos e seus clientes (Plotter, por exemplo), bem como o relacionamento entre os tipos polimórficos e outras classes que implementam seus métodos. Nossa abordagem permite também a análise do uso de polimorfismo a partir de uma perspectiva arquitetural, destacando relacionamentos que estão tipicamente escondidos. Para gerar o Polimorphic View, usamos uma ferramenta chamada Software Pathfinder, desenvolvida pelo nosso grupo de pesquisa. Na próxima seção, é demonstrado o uso do Polymorphic View em dois projetos Java. 3. Entendendo o Polimorfismo Figure 5. Polymorfic View para a Fig. 1 Nesta seção, apresentamos como o Polymorphic View pode auxiliar na compreensão do uso de polimorfismo. Para este propósito, foram analisados dois projetos de código aberto: JUnit e FindBugs. A análise foi desenvolvida através dos seguintes passos: 1. Extrair os dados dos projetos, através da análise estática feita pelo Software Pathfinder; 2. Pesquisar todas as classes abstratas e interfaces; 3. Filtrar os tipos usando seguintes as regras: Profundidade da hierarquia (P H) >= 1; Número de filhos (NDF ) >= 1; Número de métodos abstratos (N M A) >= 1; ter pelo menos um cliente; 4. Construir o Polymorfic View para cada tipo filtrado; 5. Analisar o uso do polimorfismo através da visualização; 6. Complementar a análise com o código fonte. 49

50 Nas próximas seções iremos apresentar alguns exemplos do uso de polimorfismo encontrados nos projetos JUnit e FindBugs. Como critério para selecionar os exemplos, focamos essencialmente em padrões de projeto GOF [Gamma et al. 1995] JUnit JUnit 1 é um framework escrito em Java, seguindo a arquitetura xunit para frameworks de teste unitário. Após construírmos os Polymorphic Views para o código do JUnit, encontrou-se um caso do padrão Composite, apenas observando a invocação polimórfica de TestSuite para Test, realizada pelo método run(), ilustrado na Figura 6. Test é uma interface implementada por DoubleTestCase, RepeatedTest, JUnit4TestCaseFacade e JUnit4TestAdapter, mas especialmente por TestSuite, caracterizando uma composição. Finalmente, analisando o código, foi confirmado a presença do padrão Composite. Um outro bom exemplo de uso do polimorfismo pode ser observado na Figura 8, no qual um tipo abstrato (BaseTestRunner) é usado para evitar uma dependência cíclica. O tipo ResultPrinter usa TestListener, que é uma classe abstrata e TestRunner estende BaseTestRunner, retornando valores para ResultPrinter FindBugs O FindBugs 2 é um programa que usa análise estática para encontrar problemas conhecidos como bug patterns: instâncias de código que provavelmente são erros em projetos Java. Figure 6. Polymorphic View para interface Test Analisando o Polymorphic Views para este projeto, foi encontrado um exemplo de injeção de dependência que pode ser observado na Figura 7. A classe SourceFile define uma estrutura de cache para arquivos que podem ser manipulados. Para isto, é usado invocações polimórficas para ZipSourceFileDataSource e FileSourceDataSource através da interface SourceFileData- Source Discussão A análise desses dois projetos de código aberto mostrou que o Polymorphic View auxilia na localização de estruturas polimórficas, que geralmente são escondidas em outras visualizações. Usando esta abordagem, inferências complexas sobre os projetos podem ser feitas, ajudando a entender e encontrar padrões, que provavelmente exigiriam uma busca exaustiva no código. O Polymorphic View fornece uma perspectiva estrutural (estática - namespaces e tipos) e comportamental (dinâmica - invocações) em um único diagrama, com a exibição das invocações polimórficas. 1 Mais informações em 2 Mais informações em 50

51 Ao destacar os tipos polimórficos e suas chamadas em uma única representação, o Polymorphic View ajuda na compreensão de padrões arquiteturais. Para que o mesmo estudo fosse feito somente utilizando diagramas da UML, seria necessário, pelo menos, usar um diagrama de classe e vários diagramas de sequência, um para cada caso de polimorfismo, conforme discutido na seção Trabalhos Relacionados Este trabalho encontra-se dentro do campo da análise de polimorfismo e reconstrução da arquitetura. Está relacionado também com os estudos empíricos que investigam a capacidade de uma visualização em apoiar a análise arquitetural polimórfica. Vários autores realizaram trabalhos sobre sobe polimorfismo e esta seção apresenta algumas das suas principais contribuições. Benlarbi e Melo [Benlarbi and Melo 1999] investigaram o impacto do polimorfismo sobre a qualidade do design OO, propondo um conjunto de métricas para projetos. Inicialmente, eles concluíram que o polimorfismo pode aumentar a probabilidade de falhas em software OO e indicaram que ele deve ser usado com precaução pelos projetistas e desenvolvedores. Eles sugeriram que o polimorfismo tende a ocorrer mais em projetos com elevado número de métodos e árvores de herança profundas. Denier e Gueheneuc Figure 7. Polymorphic View para a [Denier and Gueheneuc 2008] propuseram um modelo de herança para tos classe SourceFile e relacionamen- ajudar a compreensão da hierarquia de classes com foco em métodos das classes. Eles também definiram métricas e regras para destacar classes e comportamentos interessantes no que diz respeito à herança. Além disso, o modelo fornece como herança é utilizada em um programa. Denier e Sahraoui [Denier and Sahraoui 2009] propuseram uma visão única e compacta de todas as hierarquias de classe usando um layout personalizado, chamado Sunburst. Nos últimos anos, os estudos mais importantes sobre a herança e análise polimórficas foram desenvolvidos por Mihancea e Marinescu. Mihancea [Mihancea 2006] introduziu uma abordagem baseada em métricas relacionadas ao grau em que uma classe base foi destinada para reutilização da interface. Através da análise de como os clientes usam a interface da classe base, essas métricas quantificam o grau em que os clientes tratam uniformemente as instâncias dos descendentes da classe base, ao invocar métodos que pertencem a esta interface comum. Em trabalhos subsequentes [Mihancea 2008] [Mihancea 2009], Mihancea introduziu uma abordagem visual baseada em métricas para capturar a medida em que os clientes de uma hierarquia polimórfica manipulam essa hierarquia. Um vocabulário de padrão visual também foi apresentado de modo a facilitar a comunicação entre analistas. 51

52 Todas as abordagens acima descritas, embora valiosas, não são adequadas quando o interesse é fornecer uma visão detalhada de polimorfismo. Este trabalho complementa os estudos com foco em uma visualização que destaca tipos abstratos e seus clientes, permitindo assim que o usuário possa capturar a maneira pela qual os clientes de uma hierarquia de classes fazem uso de polimorfismo. 5. Conclusões e Trabalhos Futuros Neste trabalho, foi a apresentado uma abordagem de explicitar o uso do polimorfismo, utilizando uma visualização baseada em grafo de chamadas estáticas, denominada Polymorphic View. Polymorphic View é composta por tipos, invocações e namespaces, permitindo o entendimento dos relacionamentos tipicamente escondidos em outras visualizações. Destina-se a ajudar na análise do uso de polimorfismo sobre uma perspectiva arquitetônica. Apesar das vantagens promissoras, algumas limitações surgiram durante a sua utilização nas análises apresentadas na seção 3. Em primeiro lugar, existe uma dificuldade em analisar todos os níveis da hierarquia de tipos, escondidas na representação de tipos. Além disso, em alguns casos, a fim de confirmar as hipóteses sobre os padrões de projeto, foi necessário analisar o código fonte. Os resultados obtidos até o momento abrem perspectivas para novas investigações sobre o polimorfismo. Em particular, temos algumas questões em aberto para serem respondidas: a) como os tipos polimórficos se relacionam com seus clientes? b) quais padrões de projeto que adotam polimorfismo são encontrados? c) quais anti-padrões são encontrados? d) há diferenças entre o uso de polimorfismo em Java e em outras linguagens? Figure 8. Polymorphic View para classe abstrata ResultPrinter e) uso do polimorfismo é uma opção deste as primeiras versões de um tipo ou é o resultado de um processo de evolução do software, através de refatorações, por exemplo? Como parte de trabalhos futuros, pretendemos desenvolver uma visualização interativa, além de acrescentar detalhes como a hierarquia de herança e estruturas internas dos tipos (métodos e atributos). Em outra direção, iremos avaliar o uso do Polymorphic View através de experimentos controlados. Finalmente, iremos investigar porque os arquitetos de software usam polimorfismo em seus projetos, pesquisando as intenções por trás da adoção de estruturas polimórficas. References Ambler, A. (1995). Invocation polymorphism. In Proceedings of Symposium on Visual Languages, pages IEEE Comput. Soc. Press. 52

53 Benlarbi, S. and Melo, W. L. (1999). Polymorphism measures for early risk prediction. In Proceedings of the 21st international conference on Software engineering - ICSE 99, pages , New York, New York, USA. ACM Press. Booch, G., Maksimchuk, R. A., Engle, M. W., Young, B. J., Conallen, J., and Houston, K. A. (2007). Object Oriented Analysis & Design with Application. Pearson Education, Boston, MA, 3rd ed edition. Caserta, P. and Zendra, O. (2010). Visualization of the Static Aspects of Software: A Survey. IEEE transactions on visualization and computer graphics, 17(7): Denier, S. and Gueheneuc, Y.-G. (2008). Mendel: A Model, Metrics, and Rules to Understand Class Hierarchies. In th IEEE International Conference on Program Comprehension, number 2, pages IEEE. Denier, S. and Sahraoui, H. (2009). Understanding the use of inheritance with visual patterns. In rd International Symposium on Empirical Software Engineering and Measurement, pages IEEE. Dutoit, A. H. and Bruegge, B. (2010). Object-Oriented Software Engineering Using UML, Patterns, and Java. Prentice Hall. Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, New York, New York, USA. Grove, D., DeFouw, G., Dean, J., and Chambers, C. (1997). Call graph construction in object-oriented languages. Proceedings of the 12th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications - OOPSLA 97, pages Hoogendorp, H. (2010). Extraction and Visual Exploration of Call Graphs for Large Softeware Systems. PhD thesis, Groningen University. Lange, D. and Nakamura, Y. (1997). Object-oriented program tracing and visualization. Computer, 30(5): Larman, C. (2004). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3/e. Prentice Hall, Upper Saddle River, NJ, USA, 3 edition edition. Mihancea, P. (2006). Towards a Client Driven Characterization of Class Hierarchies. In 14th IEEE International Conference on Program Comprehension (ICPC 06), pages IEEE. Mihancea, P. F. (2008). Type Highlighting: A Client-Driven Visual Approach for Class Hierarchies Reengineering Eighth IEEE International Working Conference on Source Code Analysis and Manipulation, pages Mihancea, P.-f. (2009). A Novel Client-Driven Perspective on Class Hierarchy Understanding and Quality Assessment. PhD thesis, University of Timisoara. Ponder, C. and Bush, B. (1994). Polymorphism considered harmful. ACM SIGSOFT Software Engineering Notes, 19(2):

54 On the Use of Context Information for Supporting Software Visualizations Renan Vasconcelos, Marcelo Schots, Cláudia Werner Programa de Engenharia de Sistemas e Computação (PESC) COPPE/UFRJ Caixa Postal Rio de Janeiro, RJ Brasil {renanrv,schots,werner}@cos.ufrj.br Abstract. Software visualization helps to identify issues and speed up the indications of solution. The efficiency of visualization interpretation varies according to the elements that compose the representations. The choice of such elements must comply with the context that comprises their use, possibly requiring or promoting visualization changes. This work analyzes some information that is part of this context, highlighting the importance and influence of each one in a visualization. Examples of use of this context information are presented in order to illustrate the influence on the choice of visualization techniques in different scenarios. 1. Introduction Interpreting the vast amount of information available becomes complicated in environments with varied types of information and tasks. Visualization may represent a suitable alternative in this type of situation, since abstractions of data can reveal patterns, clusters, gaps, or outliers [Shneiderman 1996]. However, some aspects that are closely related to how the graphical representation is displayed must be taken into account, such as the task at hand, the interactions performed by users, and the characteristics of data. The purpose of using a given visualization is usually related to some task that will be fulfilled or aided by it. Indeed, tasks relate to visualizations design and evaluation [Schulz et al. 2013]. The former combines data and tasks in order to seek the most appropriate representation. Visualization evaluation, in turn, combines data and visualization in order to investigate how appropriate is the visual result in supporting a task. Thus, tasks can be considered as input for visualizations, representing external context information concerning the visualization and the data, seeking to make a graphical representation meaningful. Because of the intrinsic relation with the visualization field, interaction can also be considered one of visualization s main components. Although separated from the graphical result, these components are strongly related, since interactions may lead to changes in representations [Yi et al. 2007]. The process of information visualization is based on the data transformed into images that are more easily interpretable by humans [Spence 2000]. Thus, it is possible to note the importance of data for such domain. The data to be represented by a visualization should be a vital aspect to be considered. Accordingly, the viewed data can also be analyzed as contextual information. 54

55 This article aims at exploring the use of context information in order to support information visualization, indicating its use for software visualization as well. Particularly, three types of information are discussed: data, interaction and task. In order to illustrate these key elements on the visualization context, some motivating examples are also presented. The remaining of the paper is organized as follows: Section 2 introduces the concept of context awareness; the elements that may influence the visualization context are discussed in Section 3; Section 4 presents a practical example of use of context information in visualizations; related works are listed in Section 5; and the final remarks are presented in Section Context-Aware Applications Context-aware applications are characterized by capturing information from the environment, including users and their behavior, in order to provide customized answers according to each context state [Chen & Kotz 2000]. In order to derive actions from the current state, this context must be well-defined. In this sense, context models help to standardize the representation of information. A context model should support different levels of elements, such as: (i) entities, related to the context dimensions; (ii) context information, showing how each item collaborates to the description of a particular entity; (iii) context situations, which are composed by entities and their information with defined values; and (iv) rules, which allow associating actions to be performed on the occurrence of a given situation. A notation that follows this structure is UbiFEX [Fernandes et al. 2011]. With a defined notation, it is necessary to evaluate the aspects that should be included in the model, i.e., to examine the appropriateness and relevance of the information to compose the desired context model. In the context of this work, some information that is relevant for visualizations is discussed. This relevance is interpreted in terms of how modifications in the contextual information can lead to or require changes in visualizations. 3. The Role of Context Information in Visualizations The most important aspect of using visualizations is that some meaning must be transmitted, regardless of the medium where they are displayed or the chosen data source. The featured representations should enable users to interpret the results and to obtain useful information. In this sense, besides the values of the selected data, techniques aimed at expressing the visualization context are also required to provide an interpretive meaning through data representation. It is important to relate data values with the phenomenon that they represent [Keller & Keller 1993]. With such characteristic, visualizations can make their users aware of different situations. Some aspects can be considered as contextual information in order to define the state of a view, given their relevance. In other words, changes in these information values may result in adaptations in the view. These aspects are discussed as follows Interactions Interactions allow a direct communication between users and systems [Dix et al. 2004]. When a system is represented through visualizations, interactions have an explicit 55

56 relationship with the change on a view, since interaction techniques may enable different actions on this view. The variety of existing interaction elements is demonstrated in [Vasconcelos et al. 2014], where each interaction technique is identified as an information visualization domain feature. In order to identify what changes might occur in a view based on the applied interactions, it is necessary to check the user intentions on performing an action in a view. In this sense, Yi et al. (2007) present seven categories of interaction that indicate possible changes in visualizations, namely: Select, Explore, Reconfigure, Encode, Abstract/Elaborate, Filter and Connect. It is worth noting that the context extraction involves registering past user interactions. The user interaction on a view denotes his/her behavior on the representation of a data set. This behavior can be considered a useful aspect for context analysis, since it allows performing changes in the visualization representation. Interactions may reveal user preferences that can be useful to a recommended visualization change. For instance, a view is set to represent the most searched keywords in a software repository. Each element displayed in a view has its representation based on the number of each keyword s occurrences, so that the size of an element is proportional to the number of searches for that keyword. If only keywords with a number of occurrences above a certain threshold are selected, meaning that the user only selects the larger elements, the view can be updated to display just those keywords elements. In this case, removing such non-interesting records would be more suitable. Appropriate context information for this case is summed up as the minimum occurrence of selected items Data The importance of data in visualizations is recognized by the number of information visualization taxonomies that depend on the data type [Müller & Schumann 2003] [Chi & Riedl 1998]. Thus, it is necessary to assess how changes in the data may impact in visualizations. With this goal, it is important to check the data types and the transformations that occur in existing visualizations in the literature. The study of Chi (2000) uses the Data State Model [Chi & Riedl 1998] to evaluate views with different techniques. This evaluation includes (i) a survey of data values, (ii) data transformations for composing an analytical abstraction), (iii) visualization transformations, turning an analytical abstraction into a visual abstraction, and (iv) visual mapping transformations, generating a graphical representation. A survey of various visualizations allows observing similarities between techniques and assessing the necessary steps for representing the data. In this sense, it is worth noting that changes in data values should promote a number of specific transformations for each visualization technique until the graphical result. It is worth emphasizing that often the change in the data set cannot be predicted. In this sense, event-based visualizations [Müller & Schumann 2003] must have special precaution mechanisms, treating possible restrictions on the application of certain visualization techniques, such as interpolation values. 56

57 Since changes in the data set usually influence the graphical result, an example can be seen in the selection of a very large data group. When one needs to represent many visual elements (e.g., in the case of the searched keywords on a software repository), behaviors that can be adopted in a view are: (i) the adjustment of scale, providing more space for a larger number of simultaneous records, and (ii) filtering mechanisms, in order to show only the (most) relevant items [Shneiderman 1996]. It is also important to check the data type in order to evaluate how the information can be displayed in a view. Examples of appropriate context information to address these constraints are the number of records and the data type. For instance, when a certain number of records can impact negatively on the representation understanding, one can apply appropriate visualization features for updating the scale and filtering, such as geometric zooming and removal. This will help to avoid the overload of elements to be displayed on a small screen Tasks In addition to the user interactions and data, the view focus can be assigned by the task to be supported by the visualization. In this case, the so-called visualization tasks allow for analyses in order to obtain a set of recurring tasks whose accumulated knowledge would optimize the visualization design and evaluation [Schulz et al. 2013]. An appropriate visualization for a task must consider elements that characterize such task. Schulz et al. (2013) identify dimensions that describe a task relating to its context, aiming to extract information about the user, such as the moment when a task is performed, the ordering in a sequence of tasks, and who will carry it out. Aiming at defining a set of views that would be important for a domain, it is necessary to define which tasks cover the main issues that should be represented. For example, an important task in the software development domain concerns the possibility of reusing existing reusable assets (development with reuse), and some information can be visually represented for providing awareness on this possibility [Schots 2014], such as the number of reusable assets available in the organization for the current project domain. The number of finished projects in the domain of a current project also indicates if such domain has a significant number of projects, showing if there should be more reusable assets available. The number of searches in the reuse repository by the same keyword without results helps verifying if a particular feature is commonly expected/requested (and possibly present in several projects) in the organization. This would indicate interest in the existence of a reusable asset that meets this demand. A group of related context information can be comprised by the number of available assets to the current domain, the number of legacy projects in the current domain and the number of keywords searches in the repository without results Context Rules From the aspects considered relevant for the context, which shall be treated as context information, it is necessary to directly relate the use of certain visualization techniques to the momentary state of the context. Context rules are responsible for this association. 57

58 With a defined context situation, through a set of information with certain assigned values, it is possible to define the configuration of a view. The occurrence of a specific context implies the domain feature selection [Fernandes et al. 2011] in this case, the selection of visualization elements. Figure 1 displays the composition logic of a context rule using the UbiFEX notation [Fernandes et al. 2011]. Figure 1. Context rule model The information visualization domain features and the constraints between them (defined by composition rules) are described in [Vasconcelos et al. 2014]. These rules take into account a set of identified recommendations for the application of visualization techniques listed in [Vasconcelos et al. 2013], among others. 4. Example of Use Aiming at recognizing how context information can influence visualizations in practice, we present a unified example comprising the aforementioned aspects. A context rule is proposed to illustrate the use of context for the selection of visualization elements Context Situation <RULE> ::= <CONTEXT-SITUATION> implies <FEATURES> In order to map a context to the selection of visualization features, it is necessary to define context situations, which may provide a wider reach for the visualizations. Because such visualizations are intended to be context-aware, the occurrence of a situation should bring, through changes in a view, the necessary attention to a task. With the occurrence of some values for the context information, the task of identifying the necessity of reusable assets may rise as the focus for the final view. A related context situation for this purpose is presented in Figure 2. It is noteworthy that the thresholds of each kind of information should be customizable by the organizations. Develop a new reusable asset Number of records > 30 Data type = String Number of available assets to the current domain < 10 Number of legacy projects in the current domain > 5 Number of keywords searches in the repository without results > 7 Figure 2. Context situation Another context situation can encompass changes that can be promoted through interactions in a view. Since the user behavior upon such view should be recognized as context information, an appropriate context situation holds the same information of the previous situation and incorporates the interaction information, as shown in Figure 3. Filter reusable asset development candidates Minimum occurrence of selected items > 20 Number of records > 30 Data type = String Number of available assets to the current domain < 10 Number of legacy projects in the current domain > 5 Number of keywords searches in the repository without results > 7 Figure 3. Context situation with an interaction behavior 58

59 4.2. Context-Aware Visualization After the appropriate context situations have been defined, the context rules will map the features that a visualization should have in order to better support the user carrying out the task of identifying the necessity of new reusable assets. A visualization that matches the task goal can organize the keywords (searched in the repository without results) in a bubble structure (pack layout), representing each item as an overview. With a large data set (e.g., comprising more than 30 items), a geometric zooming mechanism can be helpful to adjust the scale. Colors can be used to highlight different domains, and sizes can represent the number/frequency of searches. Finally, the items names and metadata can be shown as tooltips within each bubble, after a simple selection. A context rule that corresponds to these observations is illustrated in Figure 4. A visualization that matches this rule is shown in Figure 5. Context Rule 1 (CR_1) Develop a new reusable asset implies (Pack Layout AND Geometric Zooming AND Highlighting AND Tooltip AND Overview AND Selection) Figure 4. Context rule for the necessity of reusable asset Figure 5. Visualization of search terms without corresponding assets Another rule can be proposed to comprise the interaction aspect, in order to remove items with less than 20 occurrences based on the user selection. Such context rule is presented in Figure 6. Context Rule 2 (CR_2) Filter reusable asset development candidates implies (Pack Layout AND Geometric Zooming AND Highlighting AND Tooltip AND Overview AND Selection AND Removal) Figure 6. Context rule for updating view for the necessity of new reusable asset 5. Related Work Some existing approaches in the literature also discuss the role of data, interactions and tasks in selecting the most appropriate visualizations. Beck et al. (2013) propose a methodology for choosing a graph-based visualization according to application profiles. 59

60 The application characterization is accomplished through a classification of data and the tasks involved for their representation. This study supports experts during the selection of visualization techniques for a given application. In a task-focused approach related to visualizations, Schulz et al. (2013) present a visualization tasks design space, with shared taxonomy and models. This study allows the evaluation of the suitability of a task to a specific case, and its selection to compose views for end users. The design space assists in the orientation and differentiation between tasks, having as output the recommendation of views to meet a selected task. Also seeking to organize a taxonomy, Chi (2000) examines characteristics of visualization techniques at different levels. By checking the similarities and differences between techniques in various data domains, it was possible to check requirements of interest for a proper application of each technique. From the presented studies, it is worth noting the focus on elements related to tasks and data for the use of visualization techniques. Although the work of Beck et al. (2013) considers data and tasks, it gears its analysis to graph-based visualization layouts. The other works focus on proposing taxonomies for common visualization applications, considering aspects of data [Chi 2000] and tasks [Schulz et al. 2013]. The current study aims at analyzing the context in a broader way, considering data, interactions and tasks. 6. Final Remarks The proper use of visualizations, with a careful choice of techniques, can contribute to a more efficient interpretation of results. Such proper use can accelerate the decision making and allow carrying out different activities with a higher level of awareness. In scenarios with a complex information flow, such as software development, visualizations that meet the needs of different tasks can ease the information processing. In this sense, an analysis of the most relevant aspects of a context can provide indications about what should be graphically represented. Also, in order to treat the whole data as a context, the data values should be periodically checked, so that a visualization can be adapted/updated or completely changed. The context information analyzed in this study integrates to the APPRAiSER approach [Schots 2014] through CAVE, a tool under development that seeks to provide context-aware visualizations for the software reuse scenario. Data, interactions and reuse tasks will serve as input in order to recognize the context and select the appropriate visualization elements for the current state. An experiment will be carried out for evaluating the pros and cons that context-driven visualization may provide. References Beck, F., Burch, M., & Diehl, S. (2013). Matching application requirements with dynamic graph visualization profiles. In 17th International Conference on Information Visualisation, London, UK, pp Chen, G., Kotz, D. (2000). A Survey of Context-Aware Mobile Computing Research. Dartmouth College Technical Report TR

61 Chi, E. H. H., & Riedl, J. T. (1998). An operator interaction framework for visualization systems. In IEEE Symposium on Information Visualization, Durham, USA, pp Chi, E. H. (2000). A taxonomy of visualization techniques using the data state reference model. In IEEE Symposium on Information Visualization (InfoVis), Salt Lake City, USA, pp Dix, A., Finlay, J., Abowd, G. D. and Beale, R. (2004). Human-computer interaction, 3rd ed: Pearson Prentice Hall. Fernandes, P., Teixeira, E. N., Werner, C. (2011). An Approach for Feature Modeling of Context-Aware Software Product Line. J. Univers. Comput. Sci., v. 17, n. 5, pp Keller, P. R., & Keller, M. M. (1993). Visual cues: practical data visualization (p. 6). Los Alamitos, CA: IEEE Computer Society Press. Müller, W., & Schumann, H. (2003). Visualization methods for time-dependent data-an overview. In Proceedings of the 35th Winter Simulation Conference, New Orleans, USA, Vol. 1, pp Schots, M. (2014). On the Use of Visualization for Supporting Software Reuse. Ph.D. Qualifying Exame, Federal University of Rio de Janeiro, Brazil. Schulz, H. J., Nocke, T., Heitzler, M., & Schumann, H. (2013). A design space of visualization tasks. In IEEE Trans. Visual. Comput. Graphics, 19(12), Shneiderman, B. (1996). The Eyes Have It: A Task by Data Type Taxonomy for Information Visualizations. In IEEE Conference on Visual Languages, Columbus, USA, pp Spence, B. (2000). Information Visualization. Pearson Education Higher Education Publishers. Vasconcelos, R. R., Schots, M., & Werner, C. (2013). Recommendations for Context- Aware Visualizations in Software Development. In 10th Workshop on Modern Software Maintenance, Salvador, Brazil, pp Vasconcelos, R., Schots, M., & Werner, C. (2014). An information visualization feature model for supporting the selection of software visualizations. In 22nd International Conference on Program Comprehension, Early Research Achievements track, Hyderabad, India, pp Yi, J. S., ah Kang, Y., Stasko, J. T., & Jacko, J. A. (2007). Toward a deeper understanding of the role of interaction in information visualization. In IEEE Trans. Visual. Comput. Graphics, 13(6),

62 ArchGraph: Modularização Automática de Sistemas Usando Clusterização de Grafos de Dependência Guilherme A. Avelino 1, Marco Tulio Valente 1 1 Departamento de Ciência da Computação, UFMG, Brasil {gaa,mtov}@dcc.ufmg.br Abstract. A proper modularization is very important to aid in the maintenance and evolution of a system. In order to help to modularize an existing software, this paper presents a strategy for automatic modularization based on data extracted from source code. In our approach, dependencies between software entities are modeled using graphs and, by relying on clustering algorithms, we construct logical groupings of such entities. Resumo. Uma adequada modularização é de grande importância para auxilio na manutenção e evolução de um sistema. Buscando auxiliar a atividade de modularizar um sistema já existente, esse artigo apresenta uma estratégia para geração automática da modularização baseada em dados extraídos de seu código fonte. Em nossa abordagem, dependências entre entidades de um software são modeladas utilizando grafos e, aplicando algoritmos de clusterização, construímos agrupamentos lógicos de tais entidades. 1. Introdução Uma boa modularização é essencial para o adequado desenvolvimento e evolução de um software. Um bom projeto modular facilita o gerenciamento do software, permitindo a divisão de atividades, além de limitar o escopo de alterações e melhorar o entendimento do sistema [Parnas 1972]. Entretanto, existem diversos sistemas que não foram desenvolvidos de forma modular, ou ainda sua modularização pode ter sofrido uma degradação durante sua evolução [Lehman et al. 1997]. Para tornar a manutenção de tais sistemas novamente gerenciável é preciso remodularizá-los, agrupando as entidades de software baseados em suas semelhanças e dependências. Nesse trabalho, apresentamos uma técnica e uma ferramenta de apoio, denominada ArchGraph, que extrai as dependências entre classes a partir do código fonte de um sistema Java e representa tais dependências utilizando grafos. Com base no grafo gerado, são usados dois diferentes algoritmos de clusterização, objetivando identificar possíveis agrupamentos lógicos desses artefatos baseados em suas dependências. Os algoritmos utilizados, representam duas diferentes estratégias de clusterização: algoritmos de otimização e algoritmos baseados na teoria dos grafos [Wiggerts 1997], permitindo assim avaliar duas diferentes estratégias, as quais são comparadas no final. O restante deste artigo está organizado da seguinte forma. A Seção 2 apresenta a solução proposta no artigo, explicando como essa foi construída e detalhando os algoritmos utilizados. A Seção 3 apresenta um estudo de caso desenvolvido com objetivo de avaliar a qualidade da modularização gerada. Trabalhos relacionados são apresentados na Seção 4. Por fim, a Seção 5 conclui este trabalho e levanta alguns trabalhos futuros. 62

63 2. Solução Proposta O ArchGraph foi desenvolvido como um plug-in para o ambiente de desenvolvimento Eclipse. Essa abordagem, além de facilitar a utilização da ferramenta ao integrá-la em um ambiente de desenvolvimento largamente utilizado, ajuda na extração das informações de dependências entre entidades de projetos em desenvolvimento. As subseções seguintes apresentam detalhes de como a solução foi construída Arquitetura Conforme mostra a Figura 1, o plug-in ArchGraph é formado por três componentes principais: Extrator de Dependências, Motor de Clusterização e Gerador da Visualização, cada um responsável por uma etapa do processo de geração dos módulos. Figura 1. Arquitetura proposta Na primeira etapa, o Extrator de Dependências faz o parsing de uma árvore sintática abstrata extraída de um projeto Java e constrói seu grafo de dependências. Nesse grafo, cada classe é representada através de um nó e a dependência entre classes é sinalizada através de uma aresta. Na segunda etapa, o grafo é repassado ao Motor de Clusterização, o qual aplica um dos algoritmos detalhados na Seção 2.2, gerando um conjunto de conjuntos de classes, que representam a nova modularização proposta por nossa solução. A última etapa, realizada pelo Gerador da Visualização, consiste na apresentação gráfica da modularização proposta. Para auxiliar não só o entendimento, como também na avaliação da modularização produzida, são geradas duas representações diferentes: uma utilizando grafos, onde os agrupamentos são sinalizados através de cores e outra utilizando um Mapa de Distribuição [Ducasse et al. 2006], que apresenta os módulos gerados mapeados nos pacotes reais do sistema. A Seção 3 fornece mais detalhes de como os resultados são apresentados Algoritmos de Clusterização Após a geração do grafo de dependências das classes do sistema alvo, é preciso identificar quais classes estão relacionados e assim inferir como essas podem ser agrupadas. Para realizar tais atividades, o ArchGraph implementa os dois algoritmos detalhados a seguir. 63

64 Hill Climbing Para avaliar a qualidade da modularização de um sistema dois critérios largamente utilizados são coesão e acoplamento [Anquetil et al. 1999]. Coesão avalia o grau de similaridade entre classes agrupadas (intra-cluster) e acoplamento define a similaridade entre classes de diferentes agrupamentos (inter-clusters). Utilizando tais características como critério de qualidade, uma boa modularização deve maximizar a coesão e diminuir o acoplamento. Adotando tais critérios, podemos definir uma função, que dado um grafo e um conjunto de agrupamentos de classes, retorne um valor baseado no numero de arestas intra-cluster e inter-clusters, sendo retornado valores maiores para agrupamentos com mais arestas intra-cluster do que inter-clusters. Com tal função, nosso problema de modularizar um software poderia ser resolvido com uma busca pelo agrupamento ideal, ou seja aquele com maior valor para tal função. O problema dessa abordagem é que mesmo para sistemas pequenos a quantidade de agrupamentos possíveis é muito grande. Como exemplo, para um sistema com 15 classes, teríamos agrupamentos possíveis. Como a maioria dos sistemas possui bem mais classes, normalmente centenas ou milhares delas, tal abordagem é inviável computacionalmente. Quando a solução ótima não é viável devemos buscar soluções aproximadas, que embora não garantam o resultado ótimo, retornam resultados suficientemente adequados. O algoritmo Hill Climbing [Russell and Norvig 2009] se encaixa nesse cenário. Ele inicia com uma solução arbitrária do problema e tenta achar um resultado melhor, incrementalmente, mudando um único elemento da solução obtida até aquele momento. Se a mudança produzir um melhor resultado, uma nova mudança é feita nessa nova solução, sendo esse passo repetido até que não seja possível encontrar mais melhorias no resultado. Nossa implementação para o algoritmo Hill Climbing se baseia no trabalho de Mancoridis e Mitchell [Mancoridis et al. 1998], o qual utiliza a função de qualidade da modularização (MQ) apresentada abaixo. A fórmula define a qualidade em termos da soma do grau de dependências entre classes do mesmo cluster (A i ) e de dependências entre classes de clusters diferentes (E ij ), sendo k o número total de clusters. MQ = { 1 k k i=1 A i 1 k(k 1) k i,j=1 E i,j, se k > 1 2 A 1, se k=1 (1) Betweenness O segundo algoritmo tem como base o trabalho de Girvan e Newman [Girvan and Newman 2002], que propõe uma variação do algoritmo tradicional de Betwenness, realizando o cálculo da centralidade das arestas ao invés da centralidade dos vértices. A centralidade das arestas de um grafo é calculada tendo como base o número de caminhos mais curtos entre todos vértices do grafo. Se o grafo possui conjuntos de vértices fortemente conectados e esses são fracamente conectados a outro grupos, por meio de uma ou poucas arestas, então todos os caminhos mais curtos entre grupos passarão por essas poucas arestas, fazendo com que elas possuam alto valor de centralidade. Assim, o algoritmo calcula a centralidade das arestas e, ao remover as de 64

65 maior valor, expõe as comunidades existentes no grafo. Em nossa solução utilizamos uma implementação do algoritmo Betwenness disponibilizada pela biblioteca de modelagem de grafos JUNG 1. Esse algoritmo requer que seja informado o número de arestas a serem removidas. 3. Estudo de Caso Para avaliar a qualidade da modularização gerada, foram realizados experimentos com dois diferentes sistemas de código aberto: ArtOfIllusion 2 e JHotDraw 3. Os experimentos realizados têm como objetivo dar respostas aos seguintes questionamentos: Q1: Qual dos algoritmos de clusterização implementado produz melhores resultados? Mais do que eleger um vencedor, esse questionamento busca identificar direcionamentos para futuras pesquisas e indícios de oportunidades de aprimoramento da solução. Q2: A modularização gerada representa uma adequada divisão lógica do sistema? A resposta a esse questionamento é de fundamental importância para o uso prático da ferramenta. O fato de ser gerada uma modularização com ótimos valores de acoplamento e coesão pode não necessariamente representar o agrupamento adequado em termos da estrutura lógica do sistema. Q3: A modularização gerada é capaz de apontar falhas e/ou oportunidades de melhoria da modularização do sistema? Com essa pergunta buscamos identificar se mesmo o sistema tendo sido desenvolvido de forma modular nossa solução gera informações que auxiliem a aprimorar essa modularização Análise dos Algoritmos de Clusterização (Q1) Os dois algoritmos foram aplicados a cada um dos sistemas selecionados. Os resultados apresentados focam em dependências do tipo herança, ou seja, as arestas ligam classes que possuem uma herança direta do tipo pai e filha. A Tabela 1 apresenta um resumo dos experimentos. O algoritmo Betweenness foi configurado para remover 10% das arestas existentes (32 para ArtOfIllusion e 48 para o JHotDraw). Foram realizadas 10 execuções do Hill Climbing, sendo os valores apresentados uma média dos resultados obtidos. Tabela 1. Resultados dos testes. *média, com desvio padrão inferior a 0,01 Sistema Hill Climbing* Betweenness MQ N o de Clusters MQ N o de Clusters ArtOfIllusion 0, , JHotDraw 0, , Analisando os clusters gerados pelos dois algoritmos, mostrados na Figura 2, é possível observar que o algoritmo de Hill Climbing tende a agrupar uma grande quantidade de classes em um único cluster e o restante das classes são divididas em pequenos 1 Java Universal Network/Graph

66 VEM clusters. Essa forma de agrupamentos e descrita como uma divisa o na o adequada de um sistema em [Anquetil et al. 1999], sendo denominada black hole, pois um cluster atua como um buraco negro absorvendo praticamente todas as classes. Ja a modularizac a o sugerida pelo algoritmo Betweenness, mesmo sem uma ana lise individual dos clusters, e mais pro xima de uma modularizac a o esperada, onde temos diversos mo dulos de tamanhos similares e poucas classes na o agrupadas. (a) ArtOfIllusion com Betweenness (b) ArtOfIllusion com Hill Climbing (c) JHotDraw com Betweenness (d) JHotDraw com Hill Climbing Figura 2. Resultado da clusterizac a o com os dois diferentes algoritmos Tendo em vista que o algoritmo Betweenness apresentou sugesto es de modularizac a o mais pro ximas de uma divisa o lo gica do sistema, os questionamentos Q2 e Q3 sera o analisados com foco nos resultados obtidos com esse algoritmo Ana lise da Qualidade da Modularizac a o Gerada (Q2 e Q3) Para avaliar a qualidade da modularizac a o utilizaremos a visualizac a o do resultado como um Mapa de Distribuic a o. Um Mapa de Distribuic a o e uma visualizac a o na qual os pacotes sa o mostrados como caixas, sendo essas preenchidas com quadrados coloridos que representam as classes do pacote. Em nossa visualizac a o a cor/nu mero do quadrado representa o mo dulo sugerido pela ferramenta para aquela dada classe. Dessa forma, utilizando o Mapa de Distribuic a o e possı vel comparar a modularizac a o sugerida pela ferramenta (cor das classes) com a modularizac a o real (caixas representando os pacotes do sistema). Os Mapas de Distribuic a o, obtidos com o algoritmo Betweenness na configurac a o descrita anteriormente, sa o apresentado na Figura 3. Para evitar uma poluic a o excessiva da figura, removemos clusters com menos de tre s classes e apresentamos apenas os 20 pacotes com maior nu mero de classes. Para ana lise da qualidade da modularizac a o destacamos algumas observac o es: 66

67 (a) ArtOfIllusion (b) JHotDraw Figura 3. Mapa de Distribuição para os dois sistemas analisados. Cada número/cor corresponde a um dos agrupamentos gerados pela ferramenta A sugestão de modularização para o pacote artofillusion.image.filter foi exatamente implementada. Esse pacote contem todas as classes do cluster 18. O mesmo acontece com os pacotes org.jhotdraw.draw.connector e artofillusion.test. Dentre as 45 classes do pacote artofillusion.procedural, 43 classes pertencem ao módulo 16, sugerido pelo ArchGraph, e as duas outras foram colocadas no módulo 6. Ao analisar as classes detalhadamente é possível observar que todas as 43 classes do pacote estão relacionadas com a classe denominada Module e que o padrão de nome dessas 43 classes tem como subnome Module. A mesma análise leva a crer que as outras duas classes estariam melhor agrupadas no pacote artofillusion.ui, pois elas estão relacionadas a criação de interface gráfica e menus. O pacote artofillusion.raytracer possui 12 classes, sendo que nesse caso foi sugerida a distribuição dessas classes em dois módulos diferentes, 13 e 14. Uma análise, utilizando apenas o padrão de nomenclatura das classes, valida a sugestão da ferramenta, pois as classes do módulo 13 possuem em sua nomenclatura o subnome Light (RTLight, RTSphericalLight e RTDirectionalLight), enquanto que as demais possuem outro padrão de nomenclatura. Análise semelhante pode ser estendida a pacotes como animation.distorcion e org.jhotdraw.app.action.edit. O pacote artofillusion é um dos pacotes que apresentou maior variedade de módulos. Foi sugerido que muitas das classes desse pacote fossem agrupadas com classes de outros pacotes. Um fato a ser observado nesse caso é que o pacote artofillusion é a raiz do projeto. A raiz do projeto é normalmente o local onde as classes são criadas quando não se sabe ou se está em dúvida sobre qual pacote uma classe deve pertencer. Dessa forma, o fato de a ferramenta ter sugerido uma 67

68 modularização bem diferente da implementada nesse pacote pode ser entendido como indício de que não há uma adequada modularização de suas classes. As quatro observações destacadas contribuem para mostrar que a modularização gerada pela ferramenta faz sentido do ponto de vista lógico do sistema (Q2), pois representa em muitos casos a implementação observada na prática para os sistemas analisados. Além disso as três últimas observações sugerem que a ferramenta é capaz de gerar indícios de erros de modularização, bem como oportunidades para aprimoramento dessa (Q3). 4. Trabalhos Relacionados Dois trabalhos importantes na área são [Anquetil et al. 1999] e [Wiggerts 1997], pois realizam uma explanação ampla sobre o tema, sendo bastante úteis para conhecimento das principais técnicas de clusterização utilizadas para engenharia reversa de sistemas. A ferramenta BUNCH [Mancoridis et al. 1998, Mitchell and Mancoridis 2006] representa um dos principais trabalhos relacionadas a clusterização de sistemas baseado em informações extraídas do código fonte. BUNCH realiza a clusterização com base na busca por agrupamentos de entidades que apresentem maior valor para uma função de qualidade da modularização, utilizando para isso um algoritmo baseado na técnica de Hill Climbing e heurísticas para geração do agrupamento inicial e dos agrupamentos vizinhos. Outros trabalhos que seguem abordagem semelhantes são [Praditwong et al. 2011] e [Annervaz et al. 2013]. Nosso trabalho difere desses trabalhos mencionados, pois não se restringe ao uso de algoritmos baseado em busca heurística. Como abordagem alternativa, adaptamos um algoritmo de identificação de comunidades em grafo, baseado na centralidade de arestas, para o problema de modularização de sistemas. No melhor do nosso conhecimento, não existem trabalhos que empreguem tal abordagem. 5. Conclusões e Trabalhos Futuros Esse trabalho apresentou uma solução para modularização automática de sistemas baseada no uso de técnicas de clusterização. Os resultados obtidos mostram que embora a modularização proposta pela ferramenta não seja necessariamente a ideal é uma boa indicação do caminho a ser seguido, sendo útil como um modelo inicial, a ser refinado por um engenheiro de software. Foi possível observar que mesmo com valores inferiores de MQ os resultados apresentados pelo algoritmo Betweenness são mais próximos de uma modularização adequada. Tais resultados indicam que essa é uma abordagem promissora, sendo uma alternativa ao tradicional uso do algoritmo Hill Climbing (usado, por exemplo, pela conhecida ferramenta Bunch). Em trabalhos futuros deseja-se realizar testes com outros algoritmos de clusterização, bem como a combinação de diferentes tipos de dependências entre classes. Pretende-se também investigar modificações na fórmula de cálculo da qualidade da modularização, pois acreditamos que é possível aprimorá-la de forma que ela gere melhores resultados. Por fim, pretende-se investigar o uso dos clusters propostos para detectar violações arquiteturais [Passos et al. 2010, Terra and Valente 2009] e também para comparar e analisar remodularizações de sistemas [Santos et al. 2014, Silva et al. 2014]. 68

69 Agradecimentos Gostaríamos de agradecer o auxílio da FAPEMIG e CNPQ. Referências Annervaz, K. M., Kaulgud, V. S., Misra, J., Sengupta, S., Titus, G., and Munshi, A. (2013). Code clustering workbench. In 13th IEEE International Working Conference on Source Code Analysis and Manipulation (SCAM), pages Anquetil, N., Fourrier, C., and Lethbridge, T. C. (1999). Experiments with clustering as a software remodularization method. In 6th Working Conference on Reverse Engineering (WCRE), pages Ducasse, S., Girba, T., and Kuhn, A. (2006). Distribution Map. 22nd IEEE International Conference on Software Maintenance (ICSM), 0: Girvan, M. and Newman, M. E. J. (2002). Community structure in social and biological networks. National Academy of Sciences, 99(12): Lehman, M., Ramil, J., Wernick, P., Perry, D., and Turski, W. (1997). Metrics and laws of software evolution-the nineties view. In 4th International Software Metrics Symposium, pages Mancoridis, S., Mitchell, B. S., Rorres, C., Chen, Y.-F., and Gansner, E. R. (1998). Using automatic clustering to produce high-level system organizations of source code. In 6th International Workshop on Program Comprehension (IWPC), pages Mitchell, B. and Mancoridis, S. (2006). On the automatic modularization of software systems using the Bunch tool. IEEE Transactions on Software Engineering, 32(3): Parnas, D. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12): Passos, L., Terra, R., Diniz, R., Valente, M. T., and Mendonca, N. C. (2010). Static architecture conformance checking an illustrative overview. IEEE Software, 27(5): Praditwong, K., Harman, M., and Yao, X. (2011). Software module clustering as a multiobjective search problem. IEEE Transactions on Software Engineering, 37: Russell, S. and Norvig, P. (2009). Artificial Intelligence: A Modern Approach, 3rd edition. Pearson Higher Education. Santos, G., Valente, M. T., and Anquetil, N. (2014). Remodularization analysis using semantic clustering. In IEEE Conference on Software Maintenance, Reengineering and Reverse Engineering (CSMR-WCRE), pages Silva, L., Valente, M. T., and Maia, M. (2014). Assessing modularity using co-change clusters. In 13th International Conference on Modularity, pages Terra, R. and Valente, M. T. (2009). A dependency constraint language to manage objectoriented software architectures. Software: Practice and Experience, 32(12): Wiggerts, T. (1997). Using clustering algorithms in legacy systems remodularization. 4th Working Conference on Reverse Engineering (WCRE), pages

70 SimMS - Um Jogo Educacional de apoio ao Ensino de Manutenção de Software Diógenes Dias Simão, Dyeimys Franco Correa, Paulo Afonso Parreira Júnior Universidade Federal de Goiás (UFG) Regional Jataí Jataí/GO Brasil dio.ds@outlook.com, dyeimys@hotmail.com, paulojunior@jatai.ufg.br Abstract. This paper presents a DEG, SimMS, for teaching Software Engineering, with emphasis on the IEEE 1219 standard for Software Maintenance. Its aim is to provide a different approach for teaching this subject in order to attract the attention of the students to the concepts of this area. In an evaluation conducted with twelve students of Computer Science, it was possible to notice that SimMS has obtained good marks regarding to its usefulness and easiness of use, respectively. 1. Introdução Engenharia de Software (ES) é uma área que se preocupa com os aspectos da produção de um software, desde o levantamento de seus requisitos junto aos stakeholders até a fase de manutenção deste software [Sommerville 2011]. No contexto acadêmico, ES é uma disciplina que contempla grande variedade de termos e conceitos e, por isso, segundo Von Vangenheim e Von Vangenheim (2012), a metodologia mais utilizada para ensino desta disciplina é a ministração de aulas expositivas. Entretanto, pesquisas recentes têm apontado que aulas expositivas raramente satisfazem os desafios relacionados à aprendizagem [Biggs e Tang 2011]. Segundo os autores, quando presentes em aulas apenas expositivas, geralmente, os alunos perdem a concentração em cerca de 15 minutos e a absorção do conteúdo reduz drasticamente. Neste sentido, alguns pesquisadores têm proposto a utilização de Jogos Educacionais Digitais (JEDs), como material de apoio ao processo de ensinoaprendizado [Fernandes e Werner 2009; Savi e Ulbricht 2009; Thiry et al. 2010; Navarro e Hoek 2009; Prikladnicki et al. 2007; Benitti e Molléri 2008]. JEDs podem ser vistos como ferramentas computacionais utilizadas como material didático complementar no aprendizado de alguma área ou de um conjunto de habilidades específicas [Annetta 2010]. A utilização de JEDs tem se mostrado eficiente, pois permite a simulação de ambientes que expõem os alunos a cenários reais, que são difíceis de se reproduzir em sala de aula [Lima et al. 2011]. Na área de ES, os JEDs possuem enfoque em simulações, explorando abstrações, trabalho cooperativo, tomadas de decisão, entre outros [Fernandes e Werner 2009]. Na literatura, há propostas de JEDs para diferentes áreas da ES, tais como Engenharia de Requisitos [Thiry et al. 2010], Medição de Software [Von Wangenheim et al. 2008] e Gerência de Projeto [Navarro e Hoek 2009; Prikladnicki et al. 2007; Benitti e Molléri 2008]. Entretanto, há escassez de trabalhos com enfoque em Manutenção de Software (MS). MS é uma das principais subáreas da ES e tem sido considerada, muitas vezes, como um gargalo no processo de desenvolvimento de um software; segundo Pressman (2011), dados da indústria indicam que entre 50% e 70% de todo esforço gasto em um software são despendidos após ele ter sido entregue ao cliente, ou seja, durante a fase de manutenção. 70

71 Considerando a escassez de trabalhos relacionados ao ensino de MS e a importância dessa fase para o ciclo de vida de um software, este trabalho tem como objetivo apresentar um JED de apoio ao ensino de MS, denominado SimMS (Simulador de Manutenção de Software). Mais especificamente, o jogo proposto visa a auxiliar alunos quanto ao entendimento dos conceitos relacionados ao processo de Manutenção de Software proposto pela norma IEEE 1219 [IEEE 1998]. Este trabalho está organizado da seguinte forma: na Seção 2 é apresentada uma breve contextualização sobre o processo de MS descrito na norma da IEEE 1219, bem como sobre JEDs. Na Seção 3 são apresentados alguns trabalhos relacionados, juntamente com uma análise comparativa dos mesmos. Nas Seções 4 e 5 são apresentados, respectivamente, o JED SimMS e a avaliação realizada sobre o mesmo. Por fim, na Seção 6 estão as considerações finais e as propostas de trabalhos futuros. 2. Manutenção de Software e Jogos Educacionais Digitais (JEDs) Na Figura 1 são apresentadas as descrições das sete fases do processo para Manutenção de Software descrito na norma IEEE 1219 [IEEE 1998]. Figura 1. Processo para Manutenção de Software segundo a norma IEEE De acordo com esta norma, observa-se que várias fases devem ser seguidas e documentadas durante o processo de MS. Segundo Paduelli (2007), uma proposta interessante para que conteúdos como este sejam melhor explorados em sala de aula é fundamentá-los por meio da simulação de situações do mundo real. Uma abordagem que tem sido bastante utilizada para se atingir esse objetivo é a utilização de Jogos Educacionais Digitais (JEDs). A norma IEEE 1219 foi escolhida para ser contemplada neste trabalho, pois se trata de um padrão internacional, definido por uma instituição amplamente reconhecida e que tem sido abordada em alguns livros-textos recentes para a disciplina Engenharia de Software [Wazlawick 2013]. Os Jogos Digitais fazem parte de um dos ramos de entretenimento que mais cresce na indústria de software. Com o intuito de atrair a atenção e o comprometimento dedicados aos jogos por seus usuários para as salas de aulas, o número de pesquisas sobre a junção entre entretenimento e ensino com jogos educacionais tem crescido bastante [Savi e Ulbricht 2009; Fernandes e Werner 2009; Mitchell e Savill-Smith 2004]. Porém, realizar esta junção de forma adequada não é uma tarefa trivial. Para que os jogos possam atingir seus objetivos pedagógicos, alguns elementos devem estar presentes nos mesmos, tais como [Annetta 2010]: i) identidade: é importante que o jogador tenha uma identidade dentro do jogo, sendo representado por um personagem (avatar); ii) interatividade: é o elemento que permite a interação do jogador com outros personagens em ambientes de múltiplos jogadores ou com personagens non-player (NPC Non-Player Character); iii) complexidade crescente: o jogo deve apresentar diferentes níveis de dificuldades, que aumentam conforme o jogador vai desempenhando corretamente o seu papel dentro do jogo; e iv) análise de atuação: é 71

72 necessário que o jogador receba um feedback sobre o seu desempenho durante e após a finalização do jogo. Na Seção 3 são apresentados sucintamente alguns JEDs de apoio ao ensino de ES existentes na literatura e, ao final, uma análise comparativa destes jogos é apresentada, com base nos elementos descritos anteriormente. 3. Trabalhos Relacionados O primeiro trabalho relacionado a ser destacado consiste no JED Ilha dos Requisitos [Gros 2003], cuja história se baseia em um personagem, denominado Jack Reqs, que sofre um acidente de avião e cai em uma ilha isolada. Na ilha, há uma tribo de canibais e Jack Reqs precisa concluir uma série de tarefas relacionadas à área de Engenharia de Requisitos (ER) para que não seja devorado por estes canibais. Um exemplo de tarefa que deve ser realizada no jogo é colocar na ordem correta as principais atividades de um processo de ER. Planager [Prikladnicki et al. 2007] é um jogo que apoia o ensino dos conceitos de gerência de projeto com enfoque no PMBOK (Project Management Body of Knowledge). Durante o jogo, o aluno pode interagir com diversos cenários de Projetos de Software pré-cadastrados. Em cada cenário, existe uma descrição de um projeto de software e o jogador deve passar pelos cinco processos de planejamento do PMBOK (definição do escopo, criação da estrutura analítica do projeto, definição das atividades, sequenciamento de atividades e desenvolvimento do cronograma). O jogo oferece dois módulos, um voltado para o aluno e outro para o professor. No módulo do professor, é possível cadastrar diferentes tipos de cenários de gerenciamento de projetos. SE-RPG [Benitti e Molléri 2008] é um jogo desenvolvido no formato RPG (Role-Playing Game) que simula um ambiente de desenvolvimento de software. No SE-RPG, é possível que o jogador escolha um avatar, o projeto a ser desenvolvido, o modelo de processo de desenvolvimento (cascata, iterativo ou prototipação), a linguagem de programação a ser utilizada e a equipe de desenvolvimento. Após isso, o jogador deverá atribuir tarefas aos membros da sua equipe, de acordo com o modelo de processo escolhido, com o intuito de finalizar o projeto no menor tempo e com o menor custo possível. Nesta mesma linha, SimSE [Navarro e Hoek 2009] é um jogo no qual o jogador assume o papel de um gerente de projeto. No SimSE, é permitido ao jogador demitir ou admitir novos empregados, bem como atribuir diferentes tarefas a eles. O jogo permite ainda a comunicação dos membros da equipe para com o jogador, uma vez que eles podem demonstrar sua satisfação ou insatisfação, informar que estão doentes ou cansados; exigindo assim, que jogador tome decisões para manter o gerenciamento do projeto em ordem. Por fim, X-Med [Von Wangenheim et al. 2008] é um jogo no qual o jogador assume o papel de um analista de medição, sendo é responsável por realizar a simulação de um programa de medição de software, com base na abordagem GQM (Goal- Question-Metric). O objetivo do jogo é apoiar o ensino da competência de aplicação do conhecimento de medição de software. No Quadro 1 apresenta-se uma análise comparativa dos JEDs descritos anteriormente, com base nos elementos que devem estar presentes em um jogo educacional [Annetta 2010] (Seção 2), bem como nos seguintes critérios adicionais: i) Tópico de Ensino: quais são os assuntos da ES tratados pelo JED?; ii) Plataforma de Execução: em quais tipos de ambientes o JED proposto pode ser executado (por exemplo, web, desktop ou mobile)?; e iii) Tecnologia de Desenvolvimento: em qual plataforma de desenvolvimento o JED foi construído? 72

73 Quadro 1. Análise comparativa dos trabalhos relacionados. Critérios/JEDs Ilha dos Requisitos Planager SE-RPG X-Med SimSE Identidade - X + X X Interatividade X X + X + Complexidade Crescente X + + X + Análise de Atuação X + X + X Tópico de Ensino Engenharia Gerência de Gerência de Medição de Gerência de Requisitos projeto projeto Software projeto Plataforma do JED Web Desktop Web Desktop Desktop Tecnologia de Desenvolvimento Flash Java Flash Java Java Legenda: Elemento Identificado (+), Elemento parcialmente identificado (-), Elemento não identificado (X). Como pode ser observado no Quadro 1, nenhum dos jogos analisados contempla o ensino de Manutenção de Software, nem contempla, por completo, os critérios apresentados por Annetta (2010) Seção 2. Outro ponto a ser destacado é que apenas dois jogos foram desenvolvidos para serem executados via web ( Ilha dos Requisitos e SE-RPG ) e que a tecnologia utilizada para desenvolvê-los é proprietária (Macromedia Flash). O JED que contemplou mais elementos educacionais foi o SE-RPG e o que contemplou menos elementos, foi o JED Ilha dos Requisitos. No caso do jogo Ilha dos Requisitos, o elemento Identidade foi dado como parcialmente contemplado, pois apesar de o jogo fornecer um personagem que identifica o jogador (Jack Reqs), não há representação de identidade para usuários do gênero feminino. Os elementos menos contemplados pelos JEDs analisados foram Identidade, Interatividade e Análise de Atuação, elementos estes fundamentais para que o jogo atinja seus objetivos educacionais. 4. SimMS Simulador de Manutenção de Software SimMS é um JED single-player cujo objetivo é apoiar o ensino de Manutenção de Software, com ênfase no processo descrito pela norma IEEE 1219 (IEEE, 1998). O jogo simula o ambiente de uma empresa de software, que implementa requisições de manutenção solicitadas por um cliente em um software específico. A meta do jogo é atender às requisições de manutenção previamente cadastradas, de acordo com a norma. SimMS foi desenvolvido sobre a plataforma Java, que foi escolhida por: i) apresentar alta portabilidade; ii) permitir que produtos desenvolvidos nesta linguagem possam ser disponibilizados para serem executados via web (por meio da tecnologia de Applets); e iii) ser constantemente atualizada. Cabe ressaltar ainda que SimMS é software livre e encontra-se disponível para download via web Apresentação do Jogo Antes de começar a jogar, o jogador tem a opção de abrir um tutorial, no qual são apresentadas as regras do jogo, bem como os principais conceitos sobre MS e sobre a norma IEEE Após iniciar o jogo, como primeiro passo, o jogador deve informar seu nome e escolher um avatar (do gênero masculino ou feminino) para representá-lo. O(A) jogador(a) assume então o papel de um(a) gerente de equipe de manutenção, responsável por selecionar as tarefas a serem realizadas, a ordem em que elas devem ocorrer e os funcionários que as cumprirão. Após se identificar, o jogador deverá escolher os membros da sua equipe de manutenção, que deve ser composta por quatro funcionários (Figura 2). Cada

74 funcionário possui experiências (em anos) distintas para os diferentes tipos de atividades relacionadas ao desenvolvimento de software, tais como análise, projeto, implementação e teste. Feita a escolha da equipe, o jogo entra em sua tela principal, apresentada na Figura 3. De tempos em tempos, requisições de manutenção irão chegar e o jogador deverá tratá-las corretamente, conforme explicado mais a frente nesta seção. Há um conjunto de requisições pré-cadastradas no jogo e a cada partida, no máximo cinco requisições deverão ser tratadas pelo jogador. Essa decisão foi tomada para que o jogo não se prolongasse muito e para que o jogador pudesse entender com mais clareza os resultados de suas decisões sobre cada requisição de manutenção recebida. B C A D Figura 2. Escolha da equipe de manutenção. Figura 3. Escolha do avatar. Como pode ser observado na Figura 3 - A, a primeira requisição de manutenção do cliente foi: Olá. Preciso de uma tela para cadastrar os veículos dos médicos que podem usar o estacionamento. Obrigado!. A descrição da requisição do cliente é bastante limitada, porém seu objetivo é apenas permitir que o jogador reconheça o tipo de manutenção (perfectiva, corretiva ou adaptativa) com o qual se refere esta requisição. O software que está sob manutenção é o MedPro, um sistema de informação hipotético relacionado à área da saúde. O jogador pode ter acesso a uma descrição mais detalhada deste sistema por meio do ícone MedPro (Figura 3 B). Além desta descrição, o jogo apresenta também uma representação fictícia da qualidade da documentação e da taxa de erros do software em manutenção, que podem variar de 0 à 100% (Figura 3 - C). Essas informações são importantes, pois podem direcionar a tomada de decisão do jogador ao longo da partida. Por exemplo, se a legibilidade do código fonte do software é baixa, o jogador pode decidir por realizar uma manutenção preventiva antes de atender a qualquer tipo de requisição do cliente. Uma vez que o jogador leu a requisição do cliente, ele deverá selecionar a tarefa a ser executada e um funcionário para realizá-la. Cada atividade do processo da norma IEEE 1219 possui uma tarefa relacionada no sistema. Além disso, há uma atividade extra, denominada manutenção preventiva, que permite aprimorar a qualidade da documentação do software. De acordo com a norma IEEE 1219 [IEEE 1998], o primeiro passo do processo de MS é a identificação da modificação solicitada, que consiste em saber se a requisição é do tipo corretiva, adaptativa ou perfectiva. O exemplo da Figura 3 (A) trata de uma requisição do tipo perfectiva, uma vez que ela se refere à inclusão de uma nova função no software. A cada atividade realizada pelo jogador, como ranqueamento, análise da viabilidade, entre outras, dois eventos irão ocorrer: i) atualização da qualidade da documentação e da taxa de erros do software em 74

75 manutenção; e ii) atualização da quantidade de dias em que o software está sob manutenção (Figura 3 D). A atualização a ser realizada na qualidade da documentação do projeto, na sua taxa de erros e o tempo para execução de uma atividade dependem da experiência do funcionário que está realizando a tarefa e da qualidade atual da documentação do software legado. Por exemplo, se o usuário selecionar um funcionário com pouca experiência em testes para executar a atividade de testes de aceitação, a taxa de erros do software irá aumentar e o tempo para execução desta tarefa será maior do que se um funcionário mais experiente tivesse sido escolhido. Outro aspecto importante a ser observado pelo jogador é que a ordem em que as atividades são realizadas deve estar em conformidade com o que é especificado na norma IEEE Um exemplo de como a não realização de uma atividade, ou a realização de uma atividade na ordem incorreta, pode prejudicar o desempenho do jogador é quando o mesmo entrega o software sem ter realizado a atividade de teste de aceitação. Caso isso ocorra, a taxa de erros do software poderá aumentar após a entrega do software ao cliente. Devido à limitação de espaço, outras características do jogo não puderam ser apresentadas. Mais detalhes sobre o SimMS podem ser encontrados em [Simão 2013]. 4.2 Análise Comparativa do SimMS Com relação aos elementos educacionais da Seção 2, tem-se que: quanto ao elemento identidade, no SimMS, o(a) jogador(a) é representado(a) por um(a) gerente de uma equipe de MS, cujo gênero é escolhido pelo próprio usuário. Apesar de o SimMS não fornecer interatividade com outros jogadores, o elemento interatividade é contemplado por permitir que o jogador interaja com os personagens non-players, representados pelos membros da equipe de manutenção. Quanto ao elemento complexidade crescente, o grau de dificuldade do jogo varia de acordo com os níveis de qualidade da documentação e da taxa de erros do software; quanto pior a qualidade do software, mais tarefas o jogador terá que realizar para completar as requisições com êxito. Quanto ao elemento análise de atuação, ao final de cada requisição entregue ao cliente, é fornecido um feedback informando as atividades do processo que foram executadas corretamente ou não pelo jogador. Além disso, ao longo do jogo, o usuário pode observar diretamente o reflexo de suas ações sobre o tempo gasto para realização de cada tarefa e sobre a qualidade da documentação e taxa de erros do software. 5. Avaliação do SimMS Para avaliação do SimMS, o modelo de aceitação de tecnologia TAM (Technology Acceptance Model) [Davis et al. 1989] foi utilizado. Esse modelo possui como objetivo explicar o comportamento das pessoas no que diz respeito à aceitação de uma tecnologia. O modelo TAM define dois constructos básicos: i) utilidade percebida, que mede o quanto uma pessoa acredita que utilizar determinada tecnologia aumenta seu desempenho no trabalho ou estudo; e ii) facilidade de uso percebida, que mede o quanto uma pessoa acredita que o uso de determinada tecnologia é simples. Além disso, o modelo TAM sugere a criação de questionários, para os quais são atribuídas afirmações relacionadas à facilidade de uso e utilidade percebidas da tecnologia em análise. Para cada afirmação, o respondente poderá escolher uma opção na seguinte escala do tipo Likert: DT - Discordo Totalmente, DT - Discordo Parcialmente, N - Neutro, CP - Concordo Parcialmente e CT - Concordo Totalmente. 75

76 O questionário desenvolvido para avaliação do SimMS foi respondido por doze alunos de graduação em Ciência da Computação da Universidade Federal de Goiás (Regional Jataí), que passaram pela disciplina Engenharia de Software. Os resultados obtidos quanto à facilidade de uso e utilidade percebidas são sumarizados nos gráficos das Figuras 4 e 5, respectivamente. Com relação à facilidade uso percebida (Figura 4), pode-se destacar que 100% dos participantes da avaliação concordaram totalmente que o acesso ao jogo SimMS é fácil. Acredita-se que isso seja devido à escolha da plataforma de desenvolvimento (Java), por meio da qual, pode-se desenvolver um jogo que não requer instalação na máquina do usuário, facilitando assim, o acesso ao mesmo. Além disso, a grande maioria (92%) concordou que utilizar o SimMS é uma boa ideia. Outro ponto importante a ser destacado é que 41% dos avaliadores escolheram a opção neutro ou discordo parcialmente, quando questionados se mesmo antes de clicarem em um botão, eles sabiam a ação que iria ocorrer. Isso pode indicar que é preciso melhorar a interface do jogo, para que o jogador fique mais seguro de suas ações. Figura 4. Resultados obtidos para o constructo Facilidade de uso percebida. Figura 5. Resultados obtidos para o constructo Utilidade percebida. Quanto à utilidade percebida, a maioria dos avaliadores (83%) concordaram totalmente que o SimMS pode ser útil no processo de ensino-aprendizagem dos conceitos de MS e pode adicionar valor ao seu estudo. Porém, 16% dos avaliadores discordaram total ou parcialmente, quando lhes foi questionado sobre a utilização do SimMS em sua rotina de trabalho. Isso é compreensível, pois o SimMS foi desenvolvido com a finalidade de fornecer apoio aos alunos das disciplinas envolvidas com MS. Por fim, quando perguntado se os avaliadores recomendariam o SimMS a outras pessoas, 92% responderam positivamente (concordo totalmente). 6. Considerações Finais e Trabalhos Futuros Jogos Educacionais Digitais (JEDs) podem ser uma alternativa promissora como ferramenta de apoio ao processo de ensino-aprendizagem de várias disciplinas, dentre elas, a Engenharia de Software. O JED apresentado neste trabalho, SimMS, pode ser 76

77 utilizado como ferramenta de apoio ao ensino de Engenharia de Software, bem como outras disciplinas que abordem o tema Manutenção de Software. Como propostas de trabalhos futuros, tem-se: i) adaptação do SimMS para tornálo flexível a ponto de permitir que professores possam adicionar novas requisições e novas regras ao jogo; ii) implementação de novos tipos de estratégias de manutenção, como por exemplo, as utilizadas pelos métodos ágeis, como Scrum, XP, entre outros; e iii) implementação de técnicas de Inteligência Artificial para realização dos cálculos de duração dos eventos e pontuação dos usuários. Acredita-se que o jogo pode tornar-se mais realístico com essa melhoria, além disso, espera-se um aumento na complexidade do jogo com a inclusão de novas requisições e novas estratégias de execução da MS. Referências ANNETTA, L. The I s Have It: A Framework For Serious Educational Game Design. Review Of General Psychology BENITTI, F. B. V.; MOLLÉRI, J. S. Utilização de um RPG no Ensino de Gerenciamento e Processo de Desenvolvimento de Software. XXVIII Congresso da SBC BIGGS, J.; TANG, C. Teaching For Quality Learning At University. 4ª Edição. 480p. McGraw-Hill DAVIS, F.D.; Bagozzi, R. P.; Warshaw P.R., User Acceptance of Computer Technology: A Comparison of two Theoretical Models. In: Manag. Science. v. 35, n. 8, p , FERNANDES, L.; WERNER, C. Sobre o uso de Jogos Digitais para o Ensino de Engenharia de Software. II Fórum de Educação em Engenharia de Software GROS, B. The Impact of Digital Games in Education. First Monday: Peer-reviewed Journal on the Internet IEEE Std IEEE Standard for Software Maintenance. Junho/1998. LIMA, T.; CAMPOS, B.; SANTOS, R.; WERNER, C.; Limoeiro, F. Desenvolvimento de Jogos Educacionais para o Ensino de Engenharia de Software. X SBGames, MITCHELL, A.; SAVILL-SMITH, C. The Use of Computer and Video Games For Learning: A review of the literature. 84p. Learning and Skills Development Agency NAVARRO, E.; HOEK, A. Multi-Site Evaluation of SIMSE. 40th ACM Technical Symposium On Computer Science Education PADUELLI, M. M. Manutenção de Software: problemas típicos e diretrizes para uma disciplina específica. Dissertação de Mestado. Universidade de São Paulo PRIKLADNICKI, R.; ROSA, R.; KIELING, E. Ensino de Gerência de Projetos de Software com o Planager. XVIII Simpósio Brasileiro de Informática na Educação SAVI, R.; ULBRICHT, V. R. Jogos Educacionais: Benefícios e Desafios. RENOTE - Revista Novas Tecnologias na Educação SIMÃO, D. D. SimMS Um Jogo Educacional Digital de Apoio ao Ensino de Manutenção de Software. Monografia de Graduação. UFG/Regional Jataí. Jataí/GO SOMMERVILLE, I. Engenharia De Software. 9ª Edição. 568p. Pearson Education THIRY, M.; ZOUCAS, A.; GONÇALVES, R. Promovendo a Aprendizagem de Engenharia de Requisitos de Software através de um Jogo Educativo. XXI Simpósio Brasileiro de Informática na Educação VON WANGENHEIM, C. G.; VON WANGENHEIM, A. Ensinando Computação com Jogos. Bookess VON WANGENHEIM, C. G.; THIRY, M.; KOCHANSKI, D. Empirical Evaluation of an Educational Game on Software Measurement. Empirical Softw. Eng. 14, 4, WAZLAWICK, R. S. Engenharia de Software: conceitos e práticas. 368p. Campus

78 ProFap-R: Um Processo de Reengenharia de Código Orientada pela Reengenharia de Dados Eduardo Moreira Fernandes, Ygo Aquino Brito, Inara Santana Ortiz, Nathalia Leite B. de M. Borine, Maria Istela Cagnin 1 Faculdade de Computação Universidade Federal de Mato Grosso do Sul (UFMS) Caixa Postal Campo Grande MS {eduardomorfernandes, ygo1992, inara.ortiz, nathaliaborine}@gmail.com, istela@facom.ufms.br Abstract. Legacy systems are computational systems that offer relevant services for organizations, but are considered obsolete because of their older technologies. Furthermore, they use to have high complexity and cost of maintenance. Aiming to evolve legacy systems, different techniques are used as the software reengineering. This work presents a process of code reengineering oriented by data reengineering for midrange systems. This process was successfully applied in the reengineering of a specific Web system of the domain of social management. Resumo. Sistemas legados são sistemas computacionais que oferecem serviços de alta relevância para as organizações, porém considerados obsoletos por suas tecnologias ultrapassadas. Além disso, possuem geralmente alto grau de complexidade e elevado custo de manutenção. Com o intuito de evoluir sistemas legados são empregadas técnicas como a reengenharia de software. O presente trabalho apresenta um processo de reengenharia de código orientada pela reengenharia de dados para sistemas legados de médio porte. Esse processo foi aplicado com sucesso na reengenharia de um sistema Web específico do domínio de gestão social. 1. Introdução Sistemas legados são sistemas computacionais que oferecem serviços de alta relevância para organizações, mas são considerados obsoletos por conta de suas tecnologias ultrapassadas. Também são caracterizados por seu alto grau de complexidade e elevado custo de manutenção, devido a fatores como a falta de documentação disponível e a dificuldade de atualização das tecnologias empregadas no desenvolvimento do sistema original [Pressman 2011; Sommerville 2011]. Com intuito de modernizar sistemas legados e garantir manutenibilidade, são empregadas técnicas como a reengenharia de software [Chikofsky e Cross 1990], composta basicamente pelas etapas de engenharia reversa e engenharia avante. Na primeira, o sistema legado é representado por artefatos de alto nível de abstração. Na segunda, é feita a engenharia avante do sistema tomando como base os artefatos da etapa anterior. Além disso, a reengenharia de software provê documentação atualizada, renovação das tecnologias empregadas e reestruturação do sistema. 1 Apoio financeiro da Fundect (Fundação de Apoio ao Desenvolvimento do Ensino, Ciência e Tecnologia do Estado de Mato Grosso do Sul) - T.O. nº 0072/12. 78

79 A principal motivação deste trabalho foi a reengenharia do Sistema de Informação em Gestão Social (SIGS), o qual é um sistema Web de médio porte com desenvolvimento iniciado no ano 2000 pelo Instituto de Estudos Especiais (IEE) da Pontifícia Universidade Católica de São Paulo (PUC-SP). Esse sistema é considerado obsoleto principalmente pelas tecnologias ultrapassadas com as quais foi implementado. A reengenharia do SIGS foi motivada durante a execução de um projeto de pesquisa voltado ao Sistema Único de Saúde (SUS) [Cagnin et al. 2012], e está sendo realizada no Laboratório de Engenharia de Software (LEDES) da Universidade Federal de Mato Grosso do Sul (UFMS). Inicialmente se propôs a adição de novas funcionalidades ao SIGS, relacionadas a área da saúde, para obtenção de relatórios com informações sociais e de saúde para apoiar tomadas de decisão de gestores de ambas as áreas. No entanto, observou-se a inviabilidade disso devido à baixa qualidade do código do SIGS (código replicado e inutilizado, falta de padronização, design deteriorado por manutenções, etc.) e das tecnologias obsoletas empregadas. Então, optou-se pela reengenharia desse sistema. Considerando-se a complexidade de portar o código legado do SIGS para uma linguagem moderna, foi conduzida uma pesquisa por processos de reengenharia para sistemas de médio porte cuja reengenharia do código fosse baseada na reengenharia de dados. Isto pois, segundo Pérez-Castillo et al. (2013), bancos de dados existentes não devem ser descartados durante a modernização de software, pois contêm valioso conhecimento do negócio não presente em outro lugar. No entanto, processos desse tipo não foram encontrados. Assim, o processo colaborativo de manutenção de software ProFap [Cagnin et al. 2013], definido e utilizado no LEDES, foi adaptado para o contexto de reengenharia e é apresentado neste artigo. O processo resultante dessa adaptação, nomeado como ProFap-R, propicia a reengenharia de código baseada na reengenharia de dados com o intuito de viabilizar a reengenharia de sistemas de médio porte, como é o caso do SIGS. A escrita deste artigo está organizada em mais sete seções. Na Seção 2 são apresentados alguns trabalhos relacionados a processos de reengenharia. Na Seção 3 é apresentado o sistema SIGS legado. Nas Seções 4 e 5 são apresentados, respectivamente, o ProFap e o ProFap-R. Na Seção 6 é descrita a condução da reengenharia do SIGS com o apoio do ProFap-R. Por fim, na Seção 7, é feita uma conclusão acerca do presente trabalho. 2. Trabalhos Relacionados Processos de reengenharia de software têm sido definidos nos últimos anos para modernizar sistemas legados desenvolvidos em plataforma desktop ou Web para a plataforma web baseada ou não em serviços, utilizando tecnologias atuais. Ruiz et al. (2012) apresentam um arcabouço de reengenharia que a partir do sistema legado (as-is system) obtém modelos em um nível mais alto de abstração (as-is models), caracterizando a engenharia reversa. Em seguida, melhorias podem ser incorporadas nesses modelos para adequá-los às necessidades atuais da organização (tobe models). Após isso, a engenharia avante do sistema é realizada com base nos modelos to-be e em um modelo de processo de desenvolvimento de software (por exemplo, cascata, espiral, incremental, etc.), obtendo-se o sistema pós-reengenharia (tobe system). Rodríguez-Echeverría et al. (2011) apresentam um arcabouço para a 79

80 modernização sistemática de aplicações Web para aplicações RIAs 2 (Rich Internet Applications). Basicamente, o principal objetivo do arcabouço proposto é gerar uma aplicação cliente RIA a partir das camadas de navegação e de apresentação da aplicação Web legada e permitir a comunicação entre a sua camada de conexão orientada a serviço com a camada da lógica do negócio do lado do servidor. Por outro lado, Pérez- Castillo et al. (2013) propõem um processo de reengenharia que, em linhas gerais, recupera serviços Web a partir de bases de dados legadas. Os serviços Web identificados gerenciam acesso às bases de dados legadas sem descartá-las. Com isso, bases de dados legadas podem então ser usadas por sistemas de informação modernizados em ambientes orientados a serviços. No entanto, pelas buscas realizadas não foram encontrados trabalhos direcionados à reengenharia de sistemas de médio porte nos quais a reengenharia de dados conduz a reengenharia de código, que é o foco deste trabalho. 3. SIGS Legado O SIGS é um sistema de informação de âmbito social que oferece um controle de dados eficaz, visando o auxílio do monitoramento, da sistematização e da avaliação de programas sociais. Em plataforma Web, oferece às prefeituras e às instituições sociais um conjunto de serviços como o cadastro e o acompanhamento das famílias incluídas nos programas. O SIGS é somente acessado pelos profissionais das instituições que o utilizam, e não pela população em geral, havendo rigoroso controle de acesso por permissões de usuários. Inicialmente, o SIGS foi orientado à gestão de programas sociais estaduais de complementação de renda pela Secretaria de Assistência Social da Prefeitura de São Paulo, de 2002 a Em seguida, passou a ser utilizado em vários programas no Estado de MS a partir de uma parceria realizada entre a PUC e a UFMS: Vale Universidade, Vale Universidade Indígena, Unidades Socioeducativas, dentre outros. No contexto do uso do SIGS, agentes sociais são responsáveis pela coleta de dados obtidos junto à população, e os dados são cadastrados no SIGS por técnicos responsáveis. Depois do registro dos dados, relatórios gerenciais são fornecidos pelo sistema. O SIGS foi desenvolvido utilizando as tecnologias ASP e SGBD (Sistema de Gerenciamento de Banco de Dados) SQL Server 2000, que são proprietárias e atualmente obsoletas. Esse sistema pode ser considerado de médio porte pois possui LOC e 383 tabelas. 4. Processo ProFap O ProFap, proposto por Cagnin et al. (2013), consiste de um processo colaborativo de manutenção com integração de ferramentas de apoio a diversas atividades e foco no desenvolvimento colaborativo de software. Ele tem sido amplamente utilizado por diversos projetos do LEDES, em especial, o projeto do SIGFAP (Sistema de Informação de Gestão de Fundações de Amparo à Pesquisa), que atualmente está sendo utilizado por Fundações de Amparo à Pesquisa de doze estados do país. O ProFap é 2 RIAs possuem plataforma baseada na Web 2.0 e oferecem principalmente interfaces de usuário com alto nível de usabilidade e interação, e processamento e armazenamento de dados no lado do cliente. 80

81 dividido em etapas, cada uma com procedimentos específicos e possui um fluxo conforme ilustrado na Figura 1. Após a implantação da versão inicial do ProFap, diversas propostas de melhorias foram identificadas pelos membros do LEDES. Uma dessas melhorias consiste na adição da etapa Projetar Solução, explicada mais à frente. Assim, o ProFap após as melhorias é composto de seis etapas, conforme apresentadas na Figura 1. Para apoiar as etapas do ProFap, faz-se uso de ferramentas de desenvolvimento de software integradas, tais com o Redmine (para gerenciamento de projetos e bugs) e o Git (sistema de versionamento de código e artefatos). Na etapa Solicitar Manutenção, é feita a solicitação via Redmine de novas funcionalidades do sistema ou o reporte de bugs. Se a solicitação for relativa a manutenção corretiva, então será atribuída a um desenvolvedor. Se referente ao desenvolvimento de módulo ou funcionalidade inédita, então será avaliada por comitês na etapa Aprovar Solicitação de Manutenção. Nessa etapa, uma solicitação pode ser aprovada ou cancelada. Na etapa Projetar Solução, após aprovação de uma solicitação, esta é atribuída a um desenvolvedor. Nela, desenvolvedores com tarefas atribuídas relacionadas entre si discutem a melhor forma de projetar a solução para atender tais tarefas, com auxílio dos líderes de equipe que possuem conhecimento detalhado do domínio do sistema. Em paralelo à etapa Projetar Solução, ocorre a etapa Implementar Solução e Efetuar Testes de Unidade. Nessa etapa, a solução projetada na etapa anterior é implementada com auxílio da ferramenta Git. Testes funcionais e unitários devem ser feitos pelo desenvolvedor, em seu Ambiente Local, durante a implementação da solicitação. Nessas etapas, pode ocorrer via Redmine comunicação entre cliente e desenvolvedor. Na etapa Efetuar Testes de Integração e de Aceitação é feita atualização do ambiente de testes, via Git integrado ao Redmine, com o resultado do trabalho. Após isso, são feitos testes de integração no ambiente de testes. O desenvolvedor poderá solicitar apoio de outras equipes de desenvolvimento para os testes de aceitação. Esse tipo de teste é sempre feito pelo cliente. Por fim, na etapa Finalizar Tarefa de Manutenção, ocorre o encerramento da solicitação de manutenção via Redmine e uma nova versão do sistema é atualizada no ambiente de produção utilizando o Git. Figura 1. ProFap: Processo Colaborativo de Manutenção (adaptado de Cagnin et al. (2013)) 81

82 5. Processo ProFap-R O processo proposto neste artigo, ProFap-R, é uma adaptação do ProFap para apoiar a reengenharia de código orientada pela reengenharia de dados. Para sua elaboração, foram concebidas novas etapas em relação ao ProFap, e outras foram adaptadas de acordo com as necessidades da reengenharia, conforme a Figura 2. As mesmas ferramentas de apoio utilizadas no ProFap (Figura 1) podem ser utilizadas no ProFap-R. Figura 2. ProFap-R: Processo de Reengenharia de Código Orientada pela Reengenharia de Dados Na etapa Obter entendimento geral do sistema legado, é obtido um amplo entendimento do domínio do sistema e são decididas as tecnologias que serão utilizadas na reengenharia. A etapa Solicitar Manutenção do ProFap foi desdobrada em três etapas: i) Estudar as tabelas do banco de dados legado : a equipe de desenvolvimento realiza um entendimento do sistema legado e documenta as suas tabelas; ii) Priorizar as tabelas do banco de dados legado : as tabelas documentadas são priorizadas das menos às mais dependentes. Essa priorização determinará a ordem de submissão à reengenharia das tabelas e funcionalidades associadas a elas, a fim de facilitar a migração do sistema com menos esforço; iii) Atribuir tarefas de manutenção : tarefas de manutenção são atribuídas aos desenvolvedores de acordo com a priorização realizada. O entendimento de cada funcionalidade e das regras de negócio associadas é baseado na execução do sistema legado e descrito na própria tarefa. Na etapa Aprovar Solicitação de Manutenção, é necessário que as funcionalidades submetidas à reengenharia sejam aprovadas pelo cliente, para que funcionalidades não representativas dos processos de negócio atuais não sejam encaminhadas à reengenharia. Caso o cliente não esteja presente e/ou disponível, essa etapa é desconsiderada. Na etapa Projetar Solução, são avaliadas as tabelas do sistema legado relacionadas à solicitação de manutenção, a fim de definir as tabelas do sistema pós-reengenharia. Para isso, são: eliminadas redundâncias das tabelas do sistema legado seguindo regras de normalização de bancos de dados; padronizados os nomes dos campos; definidos os tipos de dados correspondentes ao novo SGBD adotado, se for o caso, entre outros. Caso algum framework de aplicação [Fayad e Johnson 2000] no domínio do sistema legado tenha sido selecionado para apoiar a reengenharia, o projeto das funcionalidades deve ser baseado no projeto do mesmo. Na etapa Implementar Solução e Efetuar Testes de Unidade, as tabelas associadas à manutenção são migradas para o novo SGBD. Em alguns casos o script de criação do banco de dados legado pode ser reutilizado totalmente ou parcialmente. Porém, nos casos em que o banco de dados não está normalizado e sem padronização nos nomes de tabelas, campos, chaves primárias e estrangeiras, sugere-se escrever um novo script. As funcionalidades são implementadas de acordo com o projeto definido na etapa anterior e com base na descrição das regras de negócio realizada na etapa 82

83 Atribuir tarefas de manutenção. Caso algum framework de aplicação no domínio do sistema legado tenha sido selecionado, o mesmo é utilizado para apoiar a implementação. Na etapa Implementar Solução e Efetuar Testes de Unidade dados de tabelas do sistema legado podem ser reaproveitados para povoar tabelas do sistema pósreengenharia. As etapas Efetuar Teste de Integração e Aceitação e Finalizar Tarefa de Manutenção do ProFap-R são similares ao processo ProFap. 6. Reengenharia do SIGS O processo ProFap-R foi utilizado na reengenharia do SIGS, a qual foi realizada por bolsistas (assumindo o papel de equipe de desenvolvimento do processo) do projeto de pesquisa mencionado na Seção 1, com o auxílio de um dos clientes envolvido no desenvolvimento do SIGS (assumindo o papel de cliente do processo). No início, foi executada uma análise das funcionalidades básicas do SIGS legado e a quantidade de tabelas no banco de dados, visando definir as tecnologias a serem empregadas na reengenharia. Na Figura 3 são ilustradas as arquiteturas do SIGS legado e do SIGS pósreengenharia. A arquitetura do SIGS legado (Figura 3 (a)) não seguiu padrões de projeto e há vários trechos de código não utilizados. Além disso, o SIGS legado possui base de dados única, acessada por várias instituições que oferecem recursos e programas sociais. Dependendo da quantidade de acessos simultâneos ao sistema e à sua base de dados, pode ocorrer queda do servidor ou aumento do tempo de resposta às consultas, além da possibilidade de colocar em risco a segurança das informações, caso as regras de segurança sejam violadas. Na reengenharia do SIGS, foi estabelecido o uso de tecnologias multiplataformas e livres, bem como mudanças na arquitetura, como mostrado na Figura 3 (b). Considerando a facilidade que frameworks de aplicação oferecem à engenharia avante de sistemas legados [Cagnin et al. 2003], foi utilizado neste trabalho o Titan Framework, que utiliza linguagens PHP e XML, para apoiar a reengenharia do SIGS. Esse pertence ao domínio e-gov [Carromeu et al. 2010] e utiliza o padrão de projeto MVC (Model-View-Controller). Basicamente, o Titan recebe como entrada arquivos de configuração (XML e SQL) da instância. Com isso, ele possibilita configurar as regras de negócio da nova aplicação editando o arquivo XML e, se isso não for suficiente, é possível programar novos componentes de software que podem ficar disponíveis ou não no repositório do framework, dependendo da sua generalização. O uso do Titan ofereceu diversas vantagens como maior controle de permissões dos usuários, organização do projeto em camadas MVC (explicitadas na Figura 3 (b) por retângulos com diferentes cores de cinza) e boa usabilidade da interface com o usuário. Com a arquitetura estabelecida para a reengenharia, cada instituição possui uma instância do SIGS, consequentemente, o banco de dados é exclusivo para cada uma delas, dirimindo os problemas do SIGS legado. As atribuições de tarefas aos desenvolvedores e a documentação delas foram realizadas por meio da ferramenta Redmine na etapa Solicitar Manutenção e começaram após a primeira análise do sistema (etapa Obter entendimento geral do sistema legado ). Essas atribuições foram definidas em reuniões semanais e de acordo com o grau de dependência das tabelas da base de dados legada, iniciando pelas tabelas 83

84 menos dependentes e finalizando pelas mais dependentes. Todas as atas das reuniões também foram adicionadas ao Redmine como tarefas do tipo reunião. (a) Legado (b) Pós-Reengenharia Figura 3. Arquiteturas do SIGS Após as atribuições das tarefas, o cliente aprovou a realização das mesmas, como descrito na etapa Aprovar Solicitação de Manutenção. Nessa etapa, algumas funcionalidades do SIGS legado foram rejeitadas para a reengenharia, pois não correspondiam mais às necessidades do cliente. Durante a etapa Projetar Solução, os desenvolvedores tomavam as decisões nas reuniões semanais onde as atribuições das tarefas eram realizadas. Soluções eram traçadas com base na descrição da tarefa e no projeto do Titan. Na fase Implementar Solução e Testes de Unidade, a equipe de desenvolvimento criou os scripts das tabelas associadas a cada tarefa de manutenção e informou os parâmetros necessários no arquivo de configuração em XML do Titan. Logo após a implementação, foram realizados os testes unitários. Na etapa Efetuar Testes de Integração e de Aceitação foram conduzidos testes de integração pela equipe de desenvolvimento e testes de aceitação em conjunto com o cliente, a fim de avaliar e garantir consistência e qualidade do produto. Após concluir cada tarefa, uma nova versão do produto era disponibilizada no ambiente de produção, de acordo com a etapa Finalizar Tarefa de Manutenção. Foram contabilizadas linhas de código (LOC) e 134 tabelas implementadas no SIGS pós-reengenharia, o que dá uma redução de 94% em LOC e 65% na quantidade de tabelas. Essa redução deve-se à reestruturação do banco de dados após uma análise refinada (anteriormente, o banco de dados atendia cada instituição onde o SIGS era implantado), mudança da linguagem de programação utilizada e adoção de um framework com reaproveitamento de componentes, além da remoção de funcionalidades não mais necessárias. Em todas as etapas do ProFap-R foi elaborada documentação relacionada diretamente à reengenharia do SIGS e também à condução do processo em si, como tomadas de decisão, feedbacks do cliente e atas de reuniões. Toda documentação produzida foi registrada e versionada no Git via Redmine. 7. Conclusão Este artigo apresentou o processo ProFap-R, que é um processo de reengenharia de código baseado na reengenharia de dados, podendo ser apoiado por frameworks do domínio do sistema legado. Esse processo permitiu com sucesso a condução da 84