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

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

Anais

Volume 02 ISSN 2178-6097

VEM

2

VEM 2014 2nd 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

PROCEEDINGS

Volume 02 ISSN 2178-6097

VEM

3

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

VEM

4

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 2014. 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 2014

VEM

5

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, 2014. 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

VEM

6

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.

VEM

7

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.

VEM

8

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)

VEM

9

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)

VEM

10

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)

VEM

11

Í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

14

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

22

Análise de Métricas Estáticas para Sistemas JavaScript

Miguel Ramos and Marco Tulio Valente

30

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

38

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

46

On the Use of Context Information for Supporting Software Visualizations

Renan Vasconcelos, Marcelo Schots, and Claudia Werner

54

ArchGraph: Modularização Automática de Sistemas Usando Clusterização de Grafos de Dependência

Guilherme Avelino and Marco Tulio Valente

62

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

70

ProFap-R: Um Processo de Reengenharia de Código Orientada pela 78

VEM

12

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

86

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

94

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

102

KDM-RE: A Model-Driven Refactoring Tool for KDM

Rafael Durelli, Bruno Santos, Raphael Honda, Marcio Delamaro, and Valter Camargo

110

TS4 – VEM history

Uma Análise da História do VEM, WBVS e WMSWM

Renato Novais, Thiago Mendes, and Fernando Teles 118

VEM

13

What Questions Developers Ask During Software Evolution?An Academic Perspective

Renato Novais1, Creidiane Brito1, Manoel Mendonca2

1Federal Institute of Bahia, Salvador – BA – Brazil

2Fraunhofer Project Center for Software and Systems Engineering at UFBASalvador – BA – Brazil

{renato,creidianebrito}@ifba.edu.br, manoel.mendonca@ufba.br

Abstract. Many studies on software evolution propose new approaches. Oneneeds to validate the approaches. For that, it is common to conduct experimentalstudies where participants have to answer questionnaires with questions relatedto the research topic. Those questions must be relevant, otherwise the validationmay be invalid. In this context, this study investigates which questions (and sothe tasks) developers really answer (and perform) during software evolution. Tothis end, a survey comprised of 11 questions was applied to 42 participants fromacademia. This study allowed to derive an initial model on questions developersask during software evolution, and to understand how the participants agreedwith the relevance of the questions.

1. IntroductionSeveral 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 designquality assessment questions to investigated the efficiency and correctness using softwarevisualization. In [Bavota et al. 2012], the authors analyzed the impact of test smells onprogram comprehension during maintenance activities. For that, they applied a question-naire with 16 questions related to software test. In [Hattori et al. 2013], the authors alsoevaluated 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 mo-tivated by the need to answer two feature evolution comprehension questions.

The relevance of the questions or tasks used is, in general, based on literaturereports. However, if those tasks are not really used on the state of the practice, the ap-proaches and therefore, their evaluation, may not guarantee their applicability.

Based on this assumption, we decided to investigate which questions (and so thetasks) developers really answer (and perform) during software evolution. The study pre-sented in [Sillito et al. 2006] already investigated this topic. In our study, we decided togo 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 (newcom-ers and industrial programmers) performing change tasks to medium to large sized pro-grams. Based on those studies, they cataloged and categorized 44 different kinds of ques-tions asked by their participants. [de Alwis and Murphy 2008] highlighted the difficulty

VEM

14

of programmers have to answer questions as they investigate the functioning of a softwaresystem. They must piece together results from different tools to determine an answer tothe initial query. To overcome this issue, they proposed a model that supports the integra-tion of different sources of information about a program and a tool that implements thismodel. On the same token, [Fritz and Murphy 2010] also pointed out the challenges onanswering a variety of questions that require the integration of different kinds of projectinformation. To investigate this topic they interviewed 11 professional developers. Fromthis step, they identified 78 questions developers want to ask, but for which support islacking.

The general goal of this work is to investigate how academics and practitionerssee those questions, and discover if they are following the same directions. If the answersare no, we may have a big issue on the directions of the research on the academic contextthat should be always well aligned with real industrial problems.

In this paper, we present the results of the investigation with the academic re-searchers. To this end, we performed a survey with 11 questions and with 42 peoplefrom academia. This paper contributes with the results of this survey on the academicperspective 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 Evaluation2.1. Goal DefinitionThis study is part of a larger study that aims to investigate what questions are relevantduring software evolution. The goal is to collect the academic and practice perspectiveand compare the results. In this paper, we present the first part: the academic perspective.

2.2. PlanningSelection of suitable set of questions. The first step on this study was to identifya set of questions that could be used on the survey. Therefore, we conducted aliterature review on the study context.We selected eight papers that report ques-tions 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 pointssince they are focused on the same topic: investigate questions programmers ask duringsoftware 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 intersectionsand could be grouped in what we called Representative Questions. Each representativequestion grouped similar questions we found in the papers. For example, a representativequestion ’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.

VEM

15

Regarding the grouping step, we rely on the three most qualified experts to en-sure the soundness of our clustering. In short, the experts validated the mapping of 212questions to the 11 questions reported in Table 1.

Table 1. List of Questions.

Question Description

Q1 What is the impact of a change in the source code?

Q2 Which module has been recently modified?

Q3 Which module has undergone more changes?

Q4 When a change occurred in the source code?

Q5 Who has changed a module?

Q6 Who has more impact in a given module?

Q7 How much work has someone performed in some module?

Q8 Where particular person has worked?

Q9 For a given module, what are the changes that affected it?

Q10 What was the reason behind the changes made in a given module?

Q11 How was the process of changing a module?

Response options for each question. The participants had to answer the questions accord-ing 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 Rel-evant (VR). Second, whom the information that the question addresses is related to. Theoptions were: i) Software Developer; Software Manager; iii) Both; and iv) None.

Participants. The survey had 42 participants. We selected master and PhD students froman experimental software engineering class at Federal University of Bahia, and studentsfrom 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 mainte-nance activity?; c2) How many years have you worked with software development activi-ties?; c3) How do you consider yourself regarding to someone else that most know aboutthe 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 consideryourself more academic or practitioner?

Figure 1 shows the participant characterization. Question c4 had very differentanswers so we omitted it.

2.3. ExecutionThe execution process was conducted during master and PhD class sections at FederalUniversity 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 answerthe survey, and then fill a form characterizing them.

VEM

16

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 thequestions had a relationship among them. We observed that there are three importantentities of interest when asking question related to software evolution: change (modifica-tion report), source code (module), author (user, developer). The questions may be onlyrelated to the specific entity (e.g. what are the authors?, what are the modules of the soft-ware?), but generally they relate two entities of interest (e.g. which author modified thismodule?).

Figure 2 depicts six questions relating two by two of these entities. The arrowslink 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 portraysthe stakeholder (developer, manager, both) that can use the information provided by thetask 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 sincethe 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 affectedthis module? and which authors have mostly worked on this module ?

We believe that developers of software evolution may benefit from this initialmodel. They can use it as a initial guide of questions that their tool should try to an-swer.

3.2. Questionnaire’s answers

Figure 3 shows the total of answers per each question of the survey. It presents the bigpicture of the survey answers. For each question there are at most four bars. From leftto right side, the bars mean: Completely Irrelevant, Little Relevant, Relevant, and VeryRelevant.1

The first insight one may have from this picture is that most questions had theRelevant as the main response. Only questions Q1, Q4, and Q9 had the Relevant optionresponse less than 50%. The others overlay this mark. Even more, only question Q1 theRelevant option was not the highest option.

1View it on the computer screen, or in a color printed version for best results

VEM

17

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 therespondents agreed that this question is Relevant.

The category Little Relevant is presented in all of the questions. The highest valuesare for the questions Q5 and Q7 with 14 respondents. In all of the questions, it was higheror 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 hadhigher value than the category Little Relevant.

All questions have at least four respondents on the category Very Relevant. For thequestion Q1, 71.43% of the respondents selected this category. This is also the highestagreement of the participants.

Figure 4 shows how the participants evaluated each question considering whomthe information that the question addresses is related to. Again, for each question thereare at most four bars. From left to right side, the bar means: Software Developer, SoftwareManager, Both, None.

The category Software Developer was presented in all of the questions. QuestionQ7 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 Q1had no respondents for this category. The three highest score for this category were onquestions Q7, Q8 and Q7, with 31, 29, and 22, respectively. Moreover, question Q7 hadthe highest value among all questions and categories.

VEM

18

Figure 3. Participants’ answers per question.

The category Both considered Software Developer and Software Manager. It wasalso presented in all of the question. The highlights were for the question Q1, Q10 andQ9, 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 Q11has 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.

3.3. DiscussionThe results showed that most participants aggreed with the relevance of those selectedquestions. To support this affirmation, let’s considers grouping the results between thecategories, as follows: negative category (Completely Irrelevant and Little Relevant) andpositive category (Relevant and Very relevant). In this case, it is possible to observe thatall questions had positive answers with more than 50%. The questions Q5, Q6 and Q7had the lowest level, with 28, 25 and 28 respondents, respectively. The others were higherthan 30 respondents. Questions Q3, Q1, and Q10 had the highest values, with 40, 39 and38, respectively.

As a general conclusion, according to these results, the questions/tasks are impor-tant on the state of the practice, when one needs to evolve his/her software. This guide usto conduct the second part of the larger study, that will investigate how expert (and realpractical) people agree with the relevance of those questions/tasks.

4. Threats to ValidityThis study has some threats to validity. The first one we identified is the way we usedto select the first set of questions. We started by the most referenced papers on the topicwe know [Sillito et al. 2006] [de Alwis and Murphy 2008] [Fritz and Murphy 2010]. As

VEM

19

Figure 4. Relevance of the questions for stakeholders.

they are from the same research group, we decide to add other papers we found that alsohad questions/tasks that developers ask/perform.

Other threat may be related to the first group of task. We needed to reduce thenumber 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 alarger survey with independent expert people.

The lower statistical power is a threat to the conclusion validity since we did notused strong statistical techniques to analyse the results. Finally, but not lastly, we point tothe participants we selected. They may not be representative, however we tried to selectthe most heterogeneous we could count on.

5. Final RemarksThis paper presents an academic perspective survey on questions developers ask duringsoftware evolution. It was motivated by repeatability that researchers use such questionon the validation of their studies. The survey was composed of 11 questions and wasapplied to 42 respondents. The studies allowed us: i) to derive an initial model on ques-tions developers ask during software evolution, and ii) to understand how the participantsagreed with the relevance of the questions.

The work presented here is part of a larger study, which intends to investigate andcompare 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 participantsand compare the results with the academic participants. Other direction is to analyze theproduced information per participant level. This may guide us to a further understandingabout the produced data.

ReferencesAckermann, C. and Zazworka, N. (2010). Codevizard: Combining abstraction and detail

for reasoning about software evolution. Thecnical Report - University of Mariland.

VEM

20

Bavota, G., Qusef, A., Oliveto, R., De Lucia, A., and Binkley, D. (2012). An empiricalanalysis 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 56–65.

D’Ambros, M. and Lanza, M. (2007). Bugcrawler: Visualizing evolving software sys-tems. In Proceedings of the 11st European Conference on Software Maintenance andReengineering, CSMR’07, pages 333–334, Washington, DC, USA. IEEE ComputerSociety.

D’Ambros, M. and Lanza, M. (2009). Visual software evolution reconstruction. J. Softw.Maint. Evol., 21(3):217–232.

de Alwis, B. and Murphy, G. (2008). Answering conceptual queries with ferret. In Pro-ceedings of the 30th ACM/IEEE International Conference on Software Engineering,ICSE’08, pages 21–30.

Fritz, T. and Murphy, G. C. (2010). Using information fragments to answer the questionsdevelopers ask. In Proceedings of the 32nd ACM/IEEE International Conference onSoftware Engineering, ICSE’10, pages 175–184, New York, NY, USA. ACM.

German, D., Hindle, A., and Jordan, N. (2004). Visualizing the evolution of softwareusing softChange. In Proc. Int. Conf. on Software Engineering & Knowledge Engi-neering, SEKE’04, pages 336–341, New York NY. ACM Press.

Hattori, L., D’Ambros, M., Lanza, M., and Lungu, M. (2013). Answering software evo-lution questions: An empirical evaluation. Inf. Softw. Technol., 55(4):755–775.

Novais, R., Lima, Paulo, R., and Mendonca, M. (2012a). Timeline matrix: an on de-mand view for software evolution analysis. In Proc. of the 2nd Brazilian Workshop onSoftware 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 compre-hension: An industrial investigation. In Proc. of the 34th International Conference onSoftware Engineering, ICSE’12, pages 1044–1053.

Sillito, J., Murphy, G. C., and De Volder, K. (2006). Questions programmers ask duringsoftware evolution tasks. In Proceedings of the 14th ACM SIGSOFT InternationalSymposium 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 architecturalevolution. In Proceedings of the 10th International Workshop on Program Compre-hension, IWPC’02, pages 127–, Washington, DC, USA. IEEE Computer Society.

Wettel, R., Lanza, M., and Robbes, R. (2011). Software systems as cities: a controlledexperiment. In Proceedings of the 33rd International Conference on Software Engi-neering, ICSE’11, pages 551–560, New York, NY, USA. ACM.

VEM

21

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. Wiese1, Rodrigo T. Kuroda2, Reginaldo Ré1,

Gustavo A. Oliva3, Marco A. Gerosa3

1Programa de Pós Graduação em Informática – Universidade Tecnológica Federal do Paraná –

Campus Cornélio Procópio

2Departamento de Ciência da Computação

Universidade Tecnológica Federal do Paraná – Campus Campo Mourão – PR – Brasil

3IME/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.

VEM

22

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

VEM

23

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.

2.1. Coleta de dados e identificação das dependências de mudanças fortes e fracas

O projeto Ruby on Rails1 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 22.200

“estrelas” e 8.300 forks do seu código.

Nós usamos a API do GitHub2 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: http://rubyonrails.org e no Github:

https://github.com/rails/rails. 2 Para mais detalhes acessar: https://developer.github.com/v3/

VEM

24

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 Jung3 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.

2.3. 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: http://jung.sourceforge.net/doc/api/

VEM

25

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.

Tabela 1. Sumarização das quatro releases estudadas.

Release Máximo

Suporte

Mediana

Suporte

Limiar de

Suporte

(3º Quartil)

Mediana

Confiança # inst. Fortes # inst. Fracos # Pull

requests

Total de

Instâncias

3.1 14 6 >= 4 60,00% 873 (45,17%) 1060 (54,83%) 303 1933

3.2 7 2 >=2 100,00% 216 (46,87%) 215 (53,13%) 229 431

4.0 14 8 >=3 70,17% 513 (39,70%) 778 (60,30%) 1452 1291

4.1 7 2.27 >=2 66,66% 339 (16,12%) 1764 (83,88%) 769 339

Para executar os algoritmos de classificação nós utilizamos a ferramenta Weka4,

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: http://www.cs.waikato.ac.nz/ml/weka/

VEM

26

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 0.234. A diferença do Bagging para o segundo melhor algoritmo foi somente

0.043. Na Release 4.1 a diferença entre Bagging (maior AUC) para Naïve Bayes (menor

AUC) foi de 0.175. 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.

Tabela 2. Resultados da classificação de dependências de mudança forte e fracas

Release Algoritmos

% Instâncias

corretamente

Classificadas

Precisão

(forte)

Precisão

(fraca)

Sensibilidade

(forte)

Sensibilidade

(fraca) AUC

3.1

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

3.2

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

4.0

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

4.1

J48 0,981 0,969 0,984 0,917 0,994 0,976

Bagging 98,24 0.978 0.983 0.912 0.996 0.986

KNN 97,86 0.945 0.985 0.92 0.99 0.984

Naïve Bayes 97,77 0.876 0.911 0.499 0.986 0.805

JRip 98,11 0.943 0.975 0.920 0.935 0.970

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

VEM

27

indicam consistência, uma vez que as métricas foram úteis em quatro diferentes releases

com mais de um algoritmo de classificação.

3.2. 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

VEM

28

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 2039-13-3 e 250071/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. 1–38.

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. 864–878.

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, 2009. WCRE ’09. 16th Working

Conference on.

Demšar, J. (2006). Statistical Comparisons of Classifiers over Multiple Data Sets. J. Mach.

Learn. Res., v. 7, p. 1–30.

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. 1276–1304.

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. 574–586.

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. 429–

445.

VEM

29

Analise de Metricas Estaticas para Sistemas JavaScript

Miguel Esteban Ramos1, Marco Tulio Valente1

1Departamento de Ciencia da ComputacaoUniversidade Federal de Minas Gerais (UFMG) – Belo Horizonte, MG – Brazil

{miguel.ramos, mtov}@dcc.ufmg.br

Abstract. JavaScript is a dynamic and prototype-based programming languagethat is being increasingly used in software development. Thanks to initiativeslike Node.js, JavaScript is not anymore just a client-side language used to makeDOM manipulations but turned itself into a language with all the features toimplement full systems on both client and server side. Nevertheless, it is stillhard to find tools and resources to analyze and verify the quality of JavaScriptsystems. This paper presents the results of the collection and analysis of 15software metrics for a set of 50 JavaScript systems.

Resumo. JavaScript e uma linguagem dinamica e baseada em prototipos quecada dia e mais utilizada para o desenvolvimento de software. Gracas a iniciati-vas como Node.js, JavaScript deixou de ser uma linguagem que so e utilizada nolado do cliente para fazer manipulacoes do DOM, para se tornar uma lingua-gem com todas as funcionalidades para implementar sistemas completos tantodo lado do cliente quanto do lado do servidor. Mesmo assim, ainda e difıcilencontrar ferramentas e recursos que permitam analisar e verificar a qualidadede sistemas JavaScript. Neste trabalho, apresentam-se os resultados da coleta eanalise de 15 metricas de software para um conjunto de 50 sistemas JavaScript.

1. IntroducaoJavaScript e uma linguagem de programacao que atualmente esta ganhando grande popu-laridade ja que, gracas a evolucao que apresentou nos ultimos anos e a melhorias no seudesempenho, tornou-se peca fundamental no desenvolvimento de aplicacoes web moder-nas, ricas em conteudo, interativas e funcionais [Cantelon et al. 2014]. Alem disso, a fimde levar todas as caracterısticas de JavaScript para outros ambientes, surgiram plataformascomo Node.js que permitiram expandir o escopo de JavaScript para escrever aplicacoesque fazem uso intensivo de dados do lado do servidor, contribuindo para popularidadecrescente da linguagem.

Dado o grande numero de sistemas atualmente desenvolvidos em JavaScript, enatural investigar tecnicas e metodos para escrever codigo de qualidade nessa linguagem,fazendo uso de todos os princıpios da Engenharia de Software. JavaScript possui umconjunto de caracterısticas como sua natureza dinamica e assıncrona, sua orientacao aprototipos, sua flexibilidade, entre outras. Essas caracterısticas geram novos desafios nodesenvolvimento desses sistemas e fazem com que alguns conceitos tenham que ser re-considerados ou adaptados. Finalmente, JavaScript e uma linguagem relativamente nova,sendo que ainda existem poucos estudos que procuram avaliar e aprimorar as praticas deEngenharia de Software adotadas em projetos nessa linguagem.

VEM

30

Particularmente, um dos recursos mais importantes em Engenharia de Softwarepara a analise de sistemas sao metricas de software. Metricas fornecem uma grande vari-edade de informacoes, incluindo aspectos de qualidade, complexidade, manutenibilidade,tamanho, etc. Logo, metricas podem ser muito uteis no estudo das tendencias e do estadoda arte de sistemas JavaScript.

Este trabalho analisa um conjunto de metricas calculadas para uma colecao de 50sistemas JavaScript cujo codigo-fonte foi pesquisado no sistema de controle de versoesGitHub. O objetivo principal e que a analise desse conjunto de dados permita-nos obterinformacoes sobre a forma, o tamanho e a complexidade dos sistemas JavaScript, bemcomo analisar quais tipos de metricas estao disponıveis para esses sistemas.

O restante deste artigo esta organizado conforme descrito a seguir. Na Secao 2,apresenta-se a metodologia utilizada para realizar a coleta de metricas, incluindo umadescricao da ferramenta utilizada. Na Secao 3, e apresentada a analise de resultados paratres grupos de metricas. Na Secao 4, descreve-se brevemente alguns trabalhos relaciona-dos. Na Secao 5, sao apresentadas as conclusoes finais do artigo.

2. MetodologiaAs metricas consideradas neste trabalho foram obtidas para um conjunto de 50 sistemasJavaScript escolhidos manualmente desde o sistema de controle de versao GitHub. Aferramenta utilizada para efetuar as medidas foi escomplex1. Essa ferramenta foi escolhidadepois de realizar uma busca das ferramentas atualmente disponıveis para esse propositoe perceber que escomplex era a melhor opcao por oferecer o maior numero de metricas eser a base de medicao utilizada por outras ferramentas semelhantes.

2.1. Escomplex

Escomplex e uma ferramenta cujo objetivo e calcular metricas de software relacionadasprincipalmente com a complexidade de sistemas JavaScript. Escomplex faz a medicaopara cada funcao de um arquivo JS e tambem oferece um conjunto de medidas para oarquivo inteiro. A fim de obter essas medidas, escomplex gera uma Arvore SintaticaAbstrata (AST) do codigo por meio de esprima (conhecido parser JavaScript) e pos-teriormente caminha nessa arvore para calcular as medidas estaticamente. As metricasoferecidas por escomplex sao as seguintes:

• Numero de modulos: Cada arquivo JS do sistema e considerado um modulo.• Linhas de codigo: Contagem das linhas de codigo fısicas (numero de linhas en

um modulo ou funcao) e logicas (numero de declaracoes imperativas).• Numero de parametros: E o numero de parametros obtido da assinatura de cada

funcao. E uma medida estatica e, por isso, nao sao levadas em consideracao asfuncoes que dependem do parametro arguments.• Complexidade ciclomatica (CC): E a contagem do numero de caminhos linear-

mente independentes no grafo de fluxo de controle do programa. [McCabe 1976]• Densidade de complexidade ciclomatica: Proposta como uma modificacao para

a complexidade ciclomatica, esta metrica expressa a CC como uma porcentagemdo numero de linhas de codigo logicas [Gill and Kemerer 1991].

1https://github.com/philbooth/escomplex

VEM

31

• Metricas de complexidade de Halstead: Conjunto de metricas que sao calcula-das com base no numero de operadores distintos, o numero de operandos distintos,o numero total de operadores e o numero total de operandos em cada funcao. Estasmetricas sao utilizadas para avaliar a complexidade do sistema.• Indice de manutencao: Metrica de complexidade medida numa escala lo-

garıtmica, calculada a partir das linhas logicas de codigo, a complexidade ci-clomatica e o esforco Halstead [Kuipers and Visser 2007].

2.2. Coleta de Metricas

Para obter os dados de medicao apresentados neste trabalho foi necessario baixar o codigode 50 sistemas JavaScript e desenvolver um programa encarregado de percorrer cada umdesses sistemas, realizar as medidas por meio da ferramenta escomplex e construir umatabela onde foram registradas todas essas medidas.

GitHub, o sistema de controle de versoes, foi usado para pesquisar os sistemas uti-lizados neste trabalho e para baixar o codigo-fonte de cada um deles. Esse procedimentofoi feito manualmente ja que ainda e difıcil encontrar um padrao utilizado globalmentenos sistemas JavaScript para a organizacao do codigo e, portanto, existe um alto riscode incluir codigo indesejado se o procedimento for feito automaticamente. Alem disso,escolheram-se sistemas com uma alta popularidade no GitHub (maior numero de stars),um numero representativo de commits (pelo menos 150) e que nao sao uma copia (fork)de outros projetos existentes.

A Figura 1 descreve os passos que foram seguidos a fim de obter as medicoes paracada sistema.

Figura 1. Procedimentos para coleta de metricas

O primeiro passo foi criar manualmente um arquivo JSON onde se encontraum vetor cujos elementos sao objetos que representam cada sistema JS e armazenaminformacoes como o nome, a versao e a localizacao da pasta onde fica o codigo principaldo projeto. Esse arquivo e entao usado como um parametro de entrada para o bloco en-

VEM

32

carregado do processamento de cada sistema JS e da geracao da tabela com as medidaspara cada um deles.

O programa desenvolvido a fim de explorar cada sistema e gerar o conjunto finalde dados, foi escrito em JavaScript, utilizando Node.js. Inicialmente, o programa ex-trai recursivamente todos os arquivos .js que compoem o sistema descartando apenas osarquivos e as pastas que nao atendem as condicoes de um filtro proposto para evitar oprocessamento dos arquivos que contem codigo que nao pertence ao nucleo dos sistemas.Nesse ultimo passo sao excluıdos os arquivos de producao (.min.js), arquivos de direi-tos autorais (copyright.js), pastas de documentacao (doc, docs), pastas de testes (test),pastas de exemplos (example, examples) e pastas que incluem dependencias de terceiros(thirdparty ou node modules).

Posteriormente, fazendo uso da ferramenta escomplex, foram realizadas as medi-das para cada arquivo JavaScript que atendeu ao filtro e contaram-se o numero de arquivosque geraram erros durante esse processo (esses erros geralmente sao devido a problemasde sintaxe no arquivo que esta sendo processado). Por fim, nos casos de algumas metricas,calcula-se uma medida para o sistema inteiro. Por exemplo, o numero de linhas de codigodo sistema e calculado como a soma do numero de linhas de codigo de cada modulo;por outro lado, a complexidade ciclomatica do sistema e calculada como a media destamedida para cada modulo com seu respectivo desvio padrao.

Por fim, o ultimo modulo se encarrega de percorrer o vetor onde se encontramtodos os sistemas e da geracao de uma tabela no formato HTML, onde sao sumarizadasas medidas para cada sistema.

3. ResultadosA tabela com os resultados de todas as medicoes realizadas para cada sistema JS, alemdo seu nome e a versao utilizada para a medicao, estao disponıveis no seguinte link:http://aserg.labsoft.dcc.ufmg.br/qualitas.js. A fim de analisar osresultados obtidos, usou-se o programa R.

3.1. Metricas de Tamanho

A Figura 2 permite visualizar a distribuicao da medida do tamanho (linhas de codigo) dossistemas JS medidos.

Figura 2. Linhas de cogido logicas

VEM

33

Essa distribuicao mostra que a maioria dos sistemas de JS considerados neste tra-balho possui um tamanho relativamente pequeno. Depois de verificar os quartis calcula-dos para esse conjunto de dados, pode-se concluir que 75% dos sistemas tem um numerode linhas de codigo menor ou igual a 4,85 KLOC e que o tamanho de 50% das amostrasnao excede a 1,3 KLOC. No boxplot da Figura 2, tambem pode-se notar que algumasmedidas tem valores muito discrepantes correspondentes a seis amostras com numero delinhas de codigo que vao desde 11,82 KLOC ate 170,58 KLOC.

Resumo dos Resultados: Embora a maior parte dos sistemas medidos neste trabalho tenhaum tamanho pequeno, e possıvel afirmar que existem tambem sistemas JS cujo tamanhoe comparavel ao de sistemas desenvolvidos em outras linguagens de programacao (Java,C + +, etc) e que, portanto, JavaScript esta sendo usado para desenvolver programas quevao alem da manipulacao do DOM do lado do cliente para aspectos de apresentacao.

3.2. Metricas de Organizacao Modular

Usando os dados coletados neste trabalho, e possıvel vislumbrar algumas tendencias exis-tentes na organizacao e separacao do codigo dos sistemas JavaScript. Hoje em dia existemvarios padroes que descrevem como o codigo escrito em JavaScript pode ser organizado.Entre eles, o padrao de modulos e um dos mais populares. Os graficos da Figura 3 apre-sentam a distribuicao do numero de modulos e o numero de funcoes por modulo dossistemas considerados no presente trabalho.

Figura 3. Modulos e funcoes por modulos

Um dos aspectos que chama atencao nos graficos da Figura 3 e que o primeiroquartil da medida e igual a 1. Isso significa que pelo menos 25% dos sistemas sao im-plementados em um unico arquivo (modulo). No entanto, tambem e possıvel observarque metade dos sistemas apresentam mais de 13 modulos. Alem disso, os tres maioressistemas possuem 403, 539 e 574 modulos.

Ao realizar uma analise isolada do numero de linhas de codigo dos sistemas queforam implementados em um unico modulo, encontrou-se que 75% desses sistemas temmenos de 0.93 KLOC e que nenhum deles possui mais de 1.47 KLOC. No que se refereaqueles sistemas com mais de 13 modulos, 75% desses sistemas tem mais de 2.28 KLOC.Apos o calculo do coeficiente de Spearman, cujo resultado foi de 0.84, determinou-se queexiste uma correlacao forte entre o numero de modulos e o numero de linhas de codigode cada sistema.

VEM

34

Alem disso, no que diz respeito ao numero de funcoes por modulo, os resultadosmostram que 50% dos sistemas tem uma media menor do que 14,4 funcoes por modulo.Por outro lado, 25% dos sistemas tem mais do que 36,6 funcoes por modulo, o que aprincıpio e um numero alto. Apos a realizacao de uma verificacao manual na tabelade resultados, foi possıvel confirmar que a maioria dos sistemas incluıdos nesse 25%corresponde a sistemas que foram implementados em um unico modulo.

Resumo dos Resultados: Os resultados mostram que, quando se trata de sistemas peque-nos, e muito provavel que esses sejam implementados em um unico arquivo JavaScript.No entanto, a medida que aumenta o tamanho dos sistemas, o codigo tende a ter umamelhor modularizacao.

3.3. Metricas de Complexidade

Os graficos da Figura 4 mostram as distribuicoes das medidas de complexidade ci-clomatica e ındice de manutenibilidade.

Figura 4. Complexidade ciclomatica e Indice de manutencao

O terceiro quartil da medida de complexidade mostra que 75% dos sistemas con-siderados neste trabalho apresentam uma complexidade ciclomatica menor que 66,69.Levando em consideracao que, segundo Alves et al. [Alves et al. 2010], apenas metodoscom medidas de complexidade acima de 14 deveriam ser considerados de alto risco parasistemas Java, e que uma classe tıpica em Java possui cerca de 10 metodos (o que deixaesse limite em 140 por classe), podemos concluir que complexidades ciclomaticas mediasmenores que 66,69 nao representam uma medida alta. Somente tres dos sistemas avalia-dos apresentaram medidas maiores do que 200.

Por outro lado, no que se refere a medida de ındice de manutenibilidade, todos ossistemas apresentam um valor maior que 90 para essa medida. Assim, considerando oslimites apresentados em [Coleman et al. 1994], todos os sistemas medidos apresentaramuma alta manutenibilidade ( ≥ 85 ). Isso nao faz muito sentido ja que ındices de ma-nutenibilidade mais baixos deveriam ter sido obtidos pelo menos para aqueles sistemasque apresentam uma altıssima complexidade ciclomatica ou uma grande quantidade defuncoes por modulo. Uma crıtica semelhante ao ındice de manutenibilidade e feita em[Fard and Mesbah 2013], dado que nao se encontrou uma relacao entre a ma qualidadede codigo (code smells) e o ındice de manutenibilidade de cada sistema. Outra discussaosobre problemas com esta metrica e apresentada em [Kuipers and Visser 2007].

VEM

35

Resumo dos Resultados: Para a grande maioria dos sistemas JavaScript analisados, asmedidas de complexidade ciclomatica sao adequadas, pelo menos quando contrastadascom aquelas normalmente aceitas em sistemas Java. Por outro lado, no caso do ındicede manutenibilidade, os resultados sao menos conclusivos, reforcando as crıticas a essametrica encontradas na literatura.

4. Trabalhos RelacionadosAtualmente, existe um pequeno grupo de ferramentas usadas para medicoes de softwareem sistemas JavaScript. A maioria dessas ferramentas, como escomplex, estao focadas naanalise de complexidade. Plato2 e uma das ferramentas mais populares, pois faz uso decomplexityReport.js3 e JShint4 para calcular metricas e gerar um relatorio completo viagraficos interativos, que permitem comparacoes entre as medidas de cada modulo.

JSNose [Fard and Mesbah 2013] apresenta uma tecnica para deteccao de codesmells que combina analise estatica e dinamica, a fim de encontrar padroes no codigoque possam resultar em problemas de compreensao e manutencao. Adicionalmente, saopropostas algumas metricas alternativas para sistemas JavaScript, mas apenas e mostradoo resultado de cinco medidas feitas para 11 sistemas, fazendo uso da ferramenta com-plexityReport.js. Finalmente, uma analise da correlacao entre o numero de code smellsdetectados e as medicoes efetuadas em todos os sistemas e realizada.

5. ConclusaoEstudos similares aos reportados neste artigo existem para outras linguagens, notada-mente Java [Baxter et al. 2006] e [Terra et al. 2013]. No entanto, no melhor de nossoconhecimento, este artigo reporta o mais extenso estudo realizado ate o momento como objetivo de caracterizar o comportamento estatico de sistemas JavaScript, uma daslinguagens mais populares atualmente. Como uma segunda contribuicao, temos adisponibilizacao publica de um dataset de sistemas nessa linguagem, inspirado em da-tasets largamente utilizados em estudos empıricos envolvendo linguagens estaticas, comoJava [Terra et al. 2013] e [Tempero et al. 2010].

Apos a analise dos dados foram encontrados os seguintes resultados principais:(a) apesar de existirem ainda pequenos sistemas JavaScript, ja existem tambem sistemascujo grande tamanho sugere que sao programas que vao alem de pequenos scripts utili-zados para manipulacao do DOM; (b) no que se refere a modularidade, encontrou-se queaqueles sistemas pequenos sao implementados inteiramente em um so modulo (arquivo)e que, somente aqueles de maior tamanho apresentam uma melhor distribuicao do codigofazendo uso de um maior numero de modulos; (c) com relacao as medidas de comple-xidade ciclomatica, mostrou-se que a grande maioria dos sistemas JavaScript possuemvalores adequados para essa medida quando comparados com valores comumente aceitose praticados em sistemas Java.

Trabalhos futuros podem incluir um numero maior de sistemas, adicao de maismetricas utilizando ferramentas de medicao de software alternativas, incluindo metricasque considerem tambem o comportamento dinamico de sistemas JavaScript. Pretendemos

2https://www.npmjs.org/package/plato3https://www.npmjs.org/package/complexity-report4http://jshint.com/

VEM

36

tambem investigar valores de referencia (thresholds) para essas metricas, usando a tecnicaproposta por Oliveira et al. [Oliveira et al. 2014]. Por fim, pretendemos trabalhar em umaversao historica do dataset proposto, com dados de evolucao dos sistemas JavaScript, aexemplo do que ocorre com datasets ja disponibilizados para Java [Couto et al. 2013].

AgradecimentosEsta pesquisa foi apoiada pelo PEC-PG - CNPq e FAPEMIG

ReferenciasAlves, T. L., Ypma, C., and Visser, J. (2010). Deriving metric thresholds from benchmark

data. In 2010 IEEE International Conference on Software Maintenance (ICSM), pages1–10. IEEE.

Baxter, G., Frean, M., Noble, J., Rickerby, M., Smith, H., Visser, M., Melton, H., andTempero, E. (2006). Understanding the shape of Java software. In 21th Conferenceon Object Oriented Programming, Systems, Languages and Applications (OOPSLA),pages 397–412.

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). Using metrics to evaluatesoftware system maintainability. Computer, 27(8):44–49.

Couto, C., Maffort, C., Garcia, R., and Valente, M. T. (2013). COMETS: A dataset forempirical research on software evolution using source code metrics and time seriesanalysis. ACM SIGSOFT Software Engineering Notes, pages 1–3.

Fard, A. M. and Mesbah, A. (2013). Jsnose: Detecting javascript code smells. In IEEE13th International Working Conference on Source Code Analysis and Manipulation(SCAM), pages 116–125. IEEE.

Gill, G. K. and Kemerer, C. F. (1991). Cyclomatic complexity density and softwaremaintenance productivity. IEEE Transactions on Software Engineering, 17(12):1284–1288.

Kuipers, T. and Visser, J. (2007). Maintainability index revisited–position paper. In Spe-cial Session on System Quality and Maintainability (SQM 2007) of the 11th EuropeanConference on Software Maintenance and Reengineering (CSMR 2007).

McCabe, T. J. (1976). A complexity measure. IEEE Transactions on Software Enginee-ring, SE-2(4):308–320.

Oliveira, P., Valente, M. T., and Lima, F. (2014). Extracting relative thresholds for sourcecode metrics. In IEEE Conference on Software Maintenance, Reengineering and Re-verse Engineering (CSMR-WCRE), pages 254–263.

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 336–345.

Terra, R., Miranda, L. F., Valente, M. T., and Bigonha, R. S. (2013). Qualitas.classCorpus: A compiled version of the Qualitas Corpus. Software Engineering Notes,pages 1–4.

VEM

37

Migracao Parcial de um Banco de Dados Relacional para umBanco de Dados NoSQL na Nuvem Atraves de Adaptacoes

Nao-intrusivas: Um Relato de Experiencia

Caio H. Costa1, Lincoln S. Rocha2, Nabor C. Mendonca3, Paulo Henrique. M. Maia1

1Mestrado Academico em Ciencias da Computacao (MACC)Universidade Estadual do Ceara (UECE)

Campus do Itaperi, Av. Paranjana, 1700, CEP 60740-903 Fortaleza - CE

2Universidade Federal do Ceara (UFC)Campus de Quixada, Av. Jose de Freitas Queiroz, 5002, CEP 63900-00 Quixada - CE

3Programa de Pos-Graduacao em Informatica Aplicada (PPGIA)Universidade de Fortaleza (UNIFOR)

Av. Washington Soares, 1321, Edson Queiroz, CEP 60811-905 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 relatio-nal database of a legacy system to a NoSQL database in the cloud in order toresolve performance issues. Part of the relational database data was adaptedand migrated to the NoSQL database. The adaptations of the two applicationsthat make up the system were performed using a non-intrusive approach basedon aspect-oriented programming and dynamic features of the Groovy program-ming language. After the necessary adjustments, the system became able to si-multaneously access the relational database and the new DynamoDB databaseon Amazon cloud.

Resumo. Este trabalho relata a experiencia de migracao parcial do banco dedados relacional de um sistema legado para um banco de dados NoSQL na nu-vem, a fim de solucionar problemas relacionados a desempenho. Parte dos da-dos do banco de dados relacional foi adaptada e migrada para o banco de dadosNoSQL. As adaptacoes das duas aplicacoes que compoem o sistema foram reali-zadas por meio de uma abordagem nao-intrusiva baseada em programacao ori-entada a aspectos e funcionalidades dinamicas da linguagem de programacaoGroovy. Apos as adaptacoes necessarias, as duas aplicacoes passaram a aces-sar simultaneamente a base de dados relacional e a nova base de dados Dyna-moDB, na nuvem da Amazon.

1. Introducao

Este trabalho relata a migracao parcial da base de dados relacional de uma aplicacaolegada para um banco de dados NoSQL na nuvem, a fim de solucionar problemas de de-sempenho oriundos do crescimento exponencial da sua maior, e mais importante, tabela.Trata-se de um sistema de monitoramento veicular composto de duas aplicacoes: umaweb, chamada RastroBR, e outra standalone, chamada RBRDriver.

VEM

38

Ambas as aplicacoes compartilham o conceito de posicao na descricao dos seusdomınios. Uma posicao caracteriza a localizacao georeferenciada de um veıculo monito-rado pelo sistema. Os dados relativos a posicao do veıculo sao enviados a uma base dedados em intervalos fixos de um minuto. Como consequencia do contınuo aumento nonumero de veıculos monitorados, o volume de dados armazenados na tabela posicaopassou a crescer em uma taxa exponencial. Desse modo, em consequencia do tamanho1 edo rapido crescimento da tabela posicao, operacoes de consulta e de insercao de regis-tros nessa tabela tonaram-se cada vez mais lentas. Para amenizar esse problema, um es-calonamento vertical no servidor de banco de dados foi realizado algumas vezes. Porem,alem dessa ser uma solucao cara, ela apresenta limites praticos de implementacao.

De acordo com [Sadalage and Fowler 2013], bancos de dados relacionais nao fo-ram projetados para serem escalonados horizontalmente. Ja os bancos de dados NoSQLorientados a agregados, por outro lado, foram projetados para lidar com grandes volumesde dados por meio do escalonamento horizontal. Desse modo, uma alternativa baseadaem um banco de dados NoSQL tornou-se a mais viavel para o problema descrito.

Uma vez que o banco de dados NoSQL DynamoDB [Sivasubramanian 2012], nanuvem da Amazon, foi escolhido, era necessario adequar e migrar os dados da tabelaposicao para uma colecao do DynamoDB e adaptar as duas aplicacoes que compoemo sistema para que ambas passassem a trabalhar com o DynamoDB. Porem, essa solucaodeveria ser utilizada apenas para a entidade posicao. Todas as outras entidades deveriamcontinuar na base de dados relacional por causa das restricoes de integridade que nao saooferecidas em bases de dados NoSQL, alem das mesmas nao darem suporte a relaciona-mentos entre colecoes. Alem disso, a adaptacao das aplicacoes deveria ser realizada daforma menos intrusiva possıvel a fim de evitar a insercao de erros e facilitar o trabalhodos desenvolvedores que nao conheciam bem a arquitetura do sistema.

O restante do artigo esta dividido da seguinte forma: a Secao 2 discute os prin-cipais trabalhos relacionados; a Secao 3 apresenta a arquitetura das duas aplicacoes quecompoem o sistema; a Secao 4 descreve a migracao dos dados da tabela posicao parauma colecao no DynamoDB; a adaptacao das duas aplicacoes e relatada na Secao 5; porfim, a Secao 6 traz as conclusoes e sugestoes de trabalhos futuros.

2. Trabalhos Relacionados

Em [Jamshidi et al. 2013], uma revisao sistematica identifica 23 pesquisas focadas emmigracoes de aplicacoes legadas para a nuvem. Os autores classificam as migracoes em:substituicao, parcial, pilha completa, e “cloudificacao”. De acordo com essa classificacao,a migracao que o relato de experiencia deste trabalho aborda e caracterizada como umamigracao por substituicao. Nenhuma das pesquisas que fizeram parte da revisao sis-tematica em [Jamshidi et al. 2013] e caracterizada como tal.

Licoes aprendidas durante a transicao de uma grande base de dados relacionalpara um modelo hıbrido, que combina um banco de dados relacional e um banco de dadosNoSQL, sao relatadas em [Schram and Anderson 2012]. O sistema abordado nesse traba-lho e composto de servicos e foi adaptado de forma pouco intrusiva, pois a composicao

1Durante o perıodo de escrita deste artigo, o tamanho da tabela posicao era, aproximadamente,110GB.

VEM

39

dos servicos era realizada por meio da injecao de dependencia do framework Spring, in-jetando em tempo de execucao implementacoes concretas em referencias de tipos abstra-tos. A aplicacao RastroBR realiza injecao de dependencia por meio do framework Spring,porem sua adaptacao foi realizada utilizando aspectos para que a modificacao fosse maisgranular e pontual.

Em [Vu and Asal 2012] e realizada uma analise das principais plataformas de nu-vem do mercado. Tres exemplos de migracao de aplicacoes sao apresentados. A diferencaentre os exemplos apresentados em [Vu and Asal 2012] para o relato deste trabalho e queem [Vu and Asal 2012] todas as modificacoes foram realizadas de forma intrusiva, umavez que nao se tratava de uma aplicacao comercial em producao.

O trabalho [Chauhan and Babar 2011] relata a migracao por pilha com-pleta [Jamshidi et al. 2013] da ferramenta Hackystat para a nuvem. Os servicos quecompoem a ferramenta foram implantados separadamente em instancias da nuvem Ama-zon EC2 que utilizam o recurso de elasticidade. Os autores concluem que sistemas quedividem a logica do negocio entre aplicacao e base de dados, por meio de gatilhos e outrasfuncionalidades, sao mais difıceis de migrar porque a nuvem deve oferecer um banco dedados que possibilite que as mesmas estruturas possam ser executadas. Essa e uma dasrazoes que fez com que a migracao da base de dados das aplicacoes RBRDriver e Ras-troBR fosse parcial, pois a mesma contem gatilhos que fazem parte da logica do negocio.

Os autores em [Vasconcelos et al. 2013] propoem uma abordagem nao-intrusivabaseada em eventos para adaptar o codigo de uma aplicacao legada para o ambiente denuvem levando em conta as restricoes dessa nova plataforma. Nessa abordagem, o codigofonte da aplicacao e interceptado usando, por exemplo, programacao orientada a aspec-tos, e seu fluxo de execucao e direcionado para um servico similar na nuvem atraves dautilizacao de um middleware baseado em eventos. Como prova de conceito, os autoressugerem a utilizacao de aspectos para interceptar a persistencia de arquivos em disco e ar-mazena-los na nuvem sem modificar o codigo legado da aplicacao. A adaptacao relatadaneste trabalhou foi baseada nessa ideia, porem os aspectos foram utilizando para desviara persistencia de dados de uma base de dados relacional para uma base de dados NoSQLna nuvem.

3. Arquitetura do Sistema

O RBRDriver e uma aplicacao standalone, escrita em Groovy [Konig et al. 2007], cujaprincipal funcao e decodificar os pacotes enviados pelos veıculos monitorados e persistirsuas posicoes na base de dados, alem de enviar comandos e configuracoes para os equipa-mentos instalados nos veıculos. Cada posicao decodificada e inserida como um registrona tabela posicao no SGBD relacional PostgreSQL.

O RBRDriver utiliza o padrao DAO, em combinacao com o padrao Abstract Fac-tory, para interagir com a base de dados. A classe PositionCodec e responsavelpor decodificar e persistir os dados recebidos. Essa classe possui uma referencia do tipoDaoFactory, uma interface, e requisita a ela objetos DAO para consultar dados e per-sistir as posicoes dos veıculos na tabela posicao.

O tipo concreto da fabrica de objetos DAO, a referencia do tipo DaoFactory, edefinido em um arquivo de configuracao. Nesse arquivo e definida a classe SqlFactory

VEM

40

como fabrica de objetos DAO. Portanto, todo objeto DAO retornado por objetosDaoFactory sao DAOs especıficos para interagir com bancos de dados relacionais.Nao e possıvel alterar essa configuracao para que uma implementacao de fabrica especi-fica para uma base de dados NoSQL em particular seja utilizada. Dessa maneira, toda afamılia de objetos DAO seria alterada. Isso nao e interessante porque, alem de persistiras localizacoes dos veıculos, a aplicacao tambem executa outras funcoes, como envio decomandos e configuracoes, e os dados necessarios para a execucao dessas funcoes neces-sitam dos relacionamento e integridade oferecidos pela base de dados relacional.

O RastroBR e uma aplicacao web que permite que os usuarios acompanhem odeslocamento dos veıculos, mantenham os cadastros de clientes, usuarios e veıculos, eobtenham relatorios de deslocamento e estatısticas. Assim como o RBRDriver, o Ras-troBR utiliza o padrao DAO em conjunto com o padrao Abstract Factory para imple-mentar a camada de acesso ao banco de dados. No RastroBR as classes DAO utilizamo framework GORM [Fischer 2009], sendo esse, por sua vez, implementado sobre osframeworks Spring e Hibernate.

Figura 1. Interfaces e classes DAO, do RastroBR, relacionadas a consulta deposicoes.

Os relatorios oferecidos pelo RastroBR aplicam regras de negocio sobre registrosda tabela posicao, tendo seus desempenhos afetados por ela. As classes de servicodos relatorios possuem uma referencia cujo tipo e a interface DaoFactory, por meio daqual obtem as classes DAO para interagir com a base de dados. Atraves da capacidade deinjecao de dependencia do framework Spring, a classe concreta que implementa a inter-face DaoFactory pode ser facilmente trocada por meio de um script de configuracao.Em tempo de execucao, a referencia do tipo PosicaoDao obtida e um objeto do tipoGormPosicaoDao que consulta as posicoes da tabela posicao para criar os relatoriosrequisitados (Figura 1).

4. Migracao dos dadosO banco de dados escolhido, o DynamoDB, e um banco de dados NoSQL orientado aagregados [Sadalage and Fowler 2013]. O conceito de agregado e bastante apropriadopara a arquitetura escalonada horizontalmente. Um agregado informa ao banco de dadosquais dados devem ser tratados como uma unica unidade indivisıvel, e, por isso, os mes-mos devem ser mantidos em um mesmo servidor. No entanto, dois agregados diferentes,mesmo sendo de uma mesma colecao, nao precisam ser mantidos em um mesmo servidor.

VEM

41

A ausencia de relacionamentos entre agregados, como aqueles mantidos por meiode chaves estrangeiras em bancos de dados relacionais, propicia a divisao dos dados entrevarios nos. Porem, por causa dessa caracterıstica, nao e possıvel, em uma unica consulta,realizar juncoes entre agregados de colecoes diferentes. A persistencia dos dados dosistema dependia do relacionamento entre entidades oferecido pelo modelo relacional.

Figura 2. Adaptacao dos dados da tabela posicao para uma colecao NoSQL.

Apesar de sua importancia, a tabela posicao armazena apenas dados historicosque nao sao editados. Essa particularidade permitiu adaptar seus dados para uma colecaoNoSQL. A adequacao dos dados foi realizada unindo em um unico agregado cada re-gistro da tabela posicao com os registros de outras tabelas referenciados pelas chavesestrangeiras dela2. Assim, os agregados da colecao resultante fornecem, em apenas umaconsulta, todos os dados necessarios para a emissao dos relatorios do sistema. A Figura 2mostra, de forma simplificada3, a tabela posicao referenciando outras tabelas, e comoseus dados foram adaptados para uma colecao trazendo os dados dos registros referenci-ados para junto dos registros da propria tabela, criando um agregado.

5. Adaptacao do Sistema

Para utilizar tecnicas de programacao orientada a aspectos na adaptacao da aplicacao Ras-troBR, foi utilizado o framework Spring AOP (Aspect Oriented Programming). No SpringAOP, os aspectos sao implementados utilizando classes Java comuns. E possıvel indicarao framework quais classes implementam aspectos utilizando XML em um arquivo deconfiguracao, e nas classes, especificar os joint points e advices por meio de annotations.

A estrategia adotada foi criar um aspecto contendo um advice do tipo around,que intercepta o metodo getPosicaoDao da interface DaoFactory e retorna umaimplementacao DAO apropriada para o DynamoDB, ao inves de uma implementacao paraum banco de dados relacional, como em todo o resto da aplicacao. No RastroBR, umaimplementacao da interface DaoFactory e injetada nos servicos utilizando a injecao dedependencia do Spring e, quando esses requisitam um DAO, obtem DAOs de uma mesmafamılia, no caso, implementacoes para um banco de dados relacional.

2O escopo deste trabalho nao aborda as consequencias referentes a perda de normalizacao dos dados.3Os demais campos das tabelas nao sao exibidos por serem dispensaveis para o entendimento da solucao.

VEM

42

Para modificar esse comportamento foi implementado um advice apenas para asclasses de servicos relacionadas aos relatorios que dependem da tabela posicao. Esseadvice intercepta o pointcut correspondente a chamada de metodo que retorna um DAOda entidade posicao, e, ao inves de retornar uma classe que faca parte da famılia declasses definida pela injecao de dependencia, retorna uma implementacao propria parainteragir com a colecao posicao no banco DynamoDB, mas que tambem implementaa interface PosicaoDao. Um trecho de codigo do aspecto que contem esse advice eexibido na Figura 3. A linha 13 exibe o pointcut que intercepta a chamado ao metodogetPosicaoDao da interface DaoFactory, e a linha 15 retorna uma implementacaoDAO para o DynamoDB.

Figura 3. Advice retorna um DAO DynamoDB ao inves de uma DAO relacional.

Com a implementacao do aspecto contendo o advice exibido na Figura 3, umobjeto da classe RelatorioService chama o metodo getPosicaoDao da inter-face DaoFactory para consultar a a tabela posicao. Nesse momento, um adviceda classe DaoFactoryAspect intercepta essa chamada e, ao inves do fluxo normalacontecer, que seria a classe Factory (que implementa a interface DaoFactory) retor-nar uma instancia de acordo com sua famılia, por exemplo um GormPosicaoDao, oaspecto retorna para a classe cliente uma instancia do tipo DynamoDbPosicaoDao. Aclasse DynamoDbPosicaoDao tambem implementa a interface PosicaoDao e e comessa interface que a classe cliente, RelatorioService, interage. Portanto, nao houvenenhuma incompatibilidade e o codigo da classe RelatorioService nao necessitoude alteracoes.

Para que o aspecto seja ativado, passando a interceptar os pointcuts que foramespecificados em seus advices, e necessario indicar para Spring AOP quais classes saoaspectos. Isso e feito atraves da definicao do bean no script de configuracao dos Springbeans da aplicacao.

Semelhantemente ao RastroBR, no RBRDriver foi implementado um aspecto, uti-lizando AspectJ [Kiselev 2002], contendo um advice do tipo around, para capturar as cha-madas ao metodo getPosicaoDao da interface DaoFactory. No entanto, o advicedo aspecto estava sendo executado diversas vezes ao inves de ser executado apenas umavez para cada chamada ao metodo getPosicaoDao da interface DaoFactory. Asfuncionalidades dinamicas da linguagem Groovy nao permitiam o funcionamento corretodo aspecto.

O artigo [McClean 2006]4 apontou uma solucao. Em uma aplicacao Groovy, paracada classe carregada na memoria existe uma metaclasse correspondente que possui todas

4MCCLEAN, J. Painless AOP with Groovy. InfoQueue, 2 October 2006. Disponivel em:¡http://www.infoq.com/articles/aop-with-groovy¿. Acesso em: 27 Janeiro 2014..

VEM

43

as propriedades e metodos da classe a qual ela esta relacionada. De acordo com o pro-tocolo que rege as chamadas de metodo em aplicacoes Groovy, uma chamada de metodopara um objeto e direcionada para uma instancia da metaclasse deste objeto, ao inves doobjeto propriamente dito. Groovy permite trocar a metaclasse de uma classe em tempo deexecucao, alterando dinamicamente o comportamento de todas as instancias dessa classe.Dessa maneira, e possıvel alterar dinamicamente o comportamento de uma classe semmodificar seu codigo fonte. Uma das maneiras de fazer isso e por a metaclasse substituta,nomeada de forma adequada, em um pacote especıfico, cujo nome e posicao na hierarquiade pacotes depende da classe cuja metaclasse sera substituıda.

Como qualquer classe Groovy, a classe SqlPosicaoDao, responsavel porsalvar as posicoes dos veıculos na tabela posicao, possui uma metaclasse comcopias de todos os seus metodos e propriedades. Para cada metodo chamado naclasse SqlPosicaoDao, na realidade, o metodo equivalente e chamado na meta-classe. Ou seja, quando o metodo save e chamado na classe SqlPosicaoDao, oque realmente acontece e uma chamada ao metodo invokeMethod na metaclasse deSqlPosicaoDao, que por sua vez chama o metodo save da metaclasse. Portanto, eranecessario substituir a metaclasse padrao fornecida pelo compilador por uma metaclassecom uma implementacao adequada para o DynamoDB.

Isso foi realizado atraves do metodo citado anteriormente, a substituicaoda metaclasse padrao da classe SqlPosicaoDao por meio da adicao de umanova metaclasse, no pacote apropriado, no classpath da aplicacao. A nova me-taclasse foi nomeada SqlPosicaoDaoMetaClass e foi colocada no pacotegroovy.runtime.metaclass.com.azultecnologia.dao.sql seguindo opadrao necessario para que a substituicao da metaclasse padrao ocorra. Na metaclassesubstituta foi implementado um codigo que utilizasse o DAO DynamoDbPosicaoDaopara armazenar a posicao no banco de dados DynamoDB e retornar o mesmo valor queseria retornado pelo metodo save da classe SqlPosicaoDao.

Depois da alteracao, ao chamar o metodo save da classe SqlPosicaoDao,o metodo invokeMethod da nova metaclasse e executado e a classeDynamoDbPosicaoDao e utilizada para armazenar a posicao. Por fim, o numero deposicoes armazenadas e retornado. Assim, um efeito semelhante a um advice do tipoaround e obtido.

6. ConclusoesA utilizacao de aspectos para adaptar a aplicacao RastroBR, como sugerido em[Vasconcelos et al. 2013], para modificar aplicacoes de forma nao intrusiva, se mostrouvaliosa. A AOP foi utilizada nao para tratar um interesse que permeia toda a aplicacao,mas apenas a persistencia de um domınio em uma base de dados alternativa. Essa abor-dagem pode ser utilizada para tratar diversos outros casos onde seja necessario adaptarcodigo de aplicacoes de forma nao intrusiva.

E difıcil adaptar uma aplicacao para que toda a sua base de dados relacional sejamigrada para um banco de dados NoSQL. De acordo com [Sadalage and Fowler 2013],quando uma aplicacao utiliza um banco de dados NoSQL, seu domınio deve ser projetadodesde o inıcio tendo em mente as caracterısticas desse tipo de banco de dados. Bases dedados NoSQL nao possuem muitos dos recursos de relacionamento entre entidades e inte-

VEM

44

gridade que os arquitetos ja possuem em mente no momento em que projetam o domıniode uma aplicacao. Porem, como visto neste relato de experiencia, em alguns casos, epossıvel migrar parte dos dados quando estes apresentam caracterısticas que permitamuma adaptacao.

As metaclasses Groovy foram utilizadas de forma muito semelhante a aspectos, afim de alcancar o objetivo de modificar a aplicacao de forma nao-intrusiva. As funcionali-dades dinamicas da linguagem Groovy podem ser utilizadas como aspectos em aplicacoesGroovy, evitando a adicao de mais um framework na aplicacao.

Pretendemos, como trabalho futuro, aplicar as tecnicas utilizadas na migracao re-latada neste artigo com outras solucoes de bancos de dados NoSQL e realizar um compa-rativo relacionado a desempenho, facilidade de implementacao, gerenciamento oferecidopela nuvem, entre outros. Outro trabalho interessante e utilizar apenas as funcionalidadesda linguagem Groovy para capturar os pontos de interesse das aplicacoes e comparar essaabordagem com a que utiliza programacao orientada a aspectos.

ReferenciasChauhan, M. A. and Babar, M. A. (2011). Migrating service-oriented system to cloud

computing: An experience report. In 2011 IEEE 4th International Conference onCloud Computing, pages 404–411. 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 systematicreview. IEEE Transactions on Cloud Computing, 1(2):142–157.

Kiselev, I. (2002). Aspect-Oriented Programming with AspectJ. Sams, 1st edition.

Konig, 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 EmergingWorld of Polyglot Persistence. Pearson Education, 1st edition.

Schram, A. and Anderson, K. M. (2012). Mysql to nosql: data modeling challengesin supporting scalability. In SPLASH 12 Proceedings of the 3rd annual conferenceon Systems, programming, and applications: software for humanity, pages 191–202.ACM.

Sivasubramanian, S. (2012). Amazon dynamodb: a seamlessly scalable non-relational da-tabase service. In SIGMOD ’12 Proceedings of the 2012 ACM SIGMOD InternationalConference on Management of Data, pages 729–730. ACM.

Vasconcelos, M. A., Barbosa, D. M., Maia, P. H. M., and Mendonca, N. C. (2013). Umaabordagem baseada em eventos para adaptacao automatica de aplicacoes para a nuvem.In VEM 2013: I Workshop Brasileiro de Visualizacao, Evolucao e Manutencao deSoftware.

Vu, Q. H. and Asal, R. (2012). Legacy application migration to the cloud: Practicabilityand methodology. In 2012 IEEE Eighth World Congress on Services, pages 270–277.IEEE.

VEM

45

Polimorphic View: visualizando o uso de polimorfismo emprojetos de software

Fabio Petrillo1, Guilherme Lacerda12, Marcelo Pimenta1 e Carla Freitas1

1Instituto de Informatica – Universidade Federal do Rio Grande do Sul (UFRGS)Caixa Postal 15.064 – 91.501-970 – Porto Alegre – RS – Brazil

2Faculdade de Informatica - Centro Universitario Ritter dos Reis (Uniritter)Rua Orfanotrofio, 555 – 90840-440 – 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 develop-ment. Nevertheless, polymorphism has a dark side: if it is used improperly, itcan ruin application understandability. Despite its importance, very little atten-tion has been paid to how it is used in software projects, especially because itis very difficult to find and visualize where - in source code or specifications -polymorphism is adopted. In this paper, we discuss how polymorphism is usedand propose an approach to explicit the polymorphism usage by representingthe software as a static call graph.

1. IntroducaoO processo de manutencao de software e uma atividade complexa[Lange and Nakamura 1997] e a maior parte do tempo gasto neste processo e dedicado acompreensao do sistema a ser modificado [Caserta and Zendra 2010]. Compreender asdependencias entre os diferentes componentes de um software e uma das tarefas maisimportantes e desafiadoras em engenharia de software [Hoogendorp 2010]. Consequente-mente, a criacao de um projeto claro e compreensıvel, a fim de apoiar a manutencao desistemas orientados a objetos (OO) e uma preocupacao vital para a industria de software[Mihancea 2009].

Neste contexto, o polimorfismo e um conceito chave na programacaoOO[Mihancea 2009] [Ponder and Bush 1994], sendo, provavelmente, o seu mecanismomais poderoso e flexıvel[Ambler 1995] [Booch et al. 2007]. Polimorfismo oferecebenefıcios como maior extensibilidade e reutilizacao [Benlarbi and Melo 1999]. Por con-sequencia, a caracterizacao dos projetos de software com respeito a maneira como elesusam o polimorfismo e importante tanto para a compreensao de software quanto naavaliacao da sua qualidade [Mihancea 2009]. Entretanto, apesar de importante, poucose sabe sobre como polimorfismo e usado em projetos de software, especialmente porquee difıcil de encontrar e visualizar sua adocao.

Este trabalho tem como objetivo apresentar uma abordagem para a investigacao douso de polimorfismo em projetos de software. Em particular, este artigo aborda os efeitosna invocacao de metodos, destacando chamadas polimorficas atraves da analise estaticade software, mostrando a maneira pelo qual os clientes de uma classe com metodos ab-stratos fazem uso de polimorfismo. Para alcancar este objetivo, foram analisados dois

VEM

46

projetos desenvolvidos em Java, utilizando uma visualizacao que torna explıcito o usode polimorfismo atraves de um grafo de chamadas estaticas, denominado PolymorphicView.

Figure 1. Um exemplo de polimor-fismo

Este artigo esta organizado daseguinte forma: inicialmente, a secao2 faz-se uma breve contextualizacao doproblema e a apresenta a visualizacao pro-posta. A secao 3 descreve a analise de doisprojetos desenvolvidos em Java e a secao 4apresenta os trabalhos relacionados. Final-mente, a secao5 sumariza as contribuicoese descreve algumas possibilidades de tra-balhos futuros.

2. Visualizando o PolimorfismoEsta secao apresenta uma abordagem paravisualizacao do uso de polimorfismo. Ini-cialmente, contextualizamos o problema,com a descricao de um exemplo, com di-agramas da UML. Em seguida, descreve-mos a representacao proposta.

2.1. Contextualizando o problemaUm exemplo tıpico de polimorfismo e ilustrado no diagrama de classes da Figura 1. Essediagrama e uma adaptacao do modelo apresentado por Booch et al. [Booch et al. 2007].

Figure 2. Diagrama de sequencia para o ex-emplo de polimorfismo

Nesse exemplo, a inter-face Drawable e implementadapela classe abstrata Shape e pelaclasse concreta Line. Shape temduas subclasses: Circle e Rect-angle. Consequentemente, emum programa Java, Line, Cir-cle e Rectangle implementam ummetodo chamado draw().

A classe Plotter e umcliente das implementacoes deDrawable, instanciando objetosdo tipo Drawable e fazendouma invocacao polimorfica,chamando o metodo draw().

Em UML, o diagrama desequencia e usado para descreverum conjunto de interacoes entre objetos [Dutoit and Bruegge 2010]. No diagrama desequencia, para explicitar o polimorfismo, e necessario usar varios diagramas, sendo umpara apresentar a mensagem polimorfica para as classes abstratas e outros diagramas para

VEM

47

detalhar o uso do polimorfismo, iniciando com a mensagem polimorfica [Larman 2004].Outra possibilidade e o uso comentarios ou anotacoes no diagrama, como pode ser vistona Figura 2. Nesse exemplo, as instancias de Drawable nao sao explicitamente represen-tadas e a invocacao polimorfica do metodo draw() pode nao ser claramente observada,necessitando de comentarios para esclarecer o uso do polimorfismo.

Portanto, mesmo em um exemplo simples, nao e trivial visualizar invocacoespolimorficas utilizando diagramas da UML. Finalmente, tres artefatos (codigo, diagra-mas de classe e de sequencia) sao necessarios para visualizar e compreender o uso depolimorfismo. Com o objetivo de tratar essas questoes, propomos uma abordagem paraexplicitar o uso de polimorfismo em um so diagrama atraves de uma representacao emgrafo de chamadas estaticas.

2.2. Polymorphic ViewO Polymorphic View e uma representacao para modelagem de software baseado em grafoorientado de chamadas [Grove et al. 1997] para explicitar o uso de polimorfismo. Eleconsiste nos seguintes elementos basicos:

Figure 3. Tipos Concreto, Abstrato e Interface

Tipos: representado porum retangulo com bordasarredondadas (Figura 3), usadopara representar classes etipos. Tipos concretos (ouinstanciaveis) sao representadoscomo retangulos com linhassolidas, enquanto tipos abstratos e interfaces (nao instanciaveis) sao representados comlinhas tracejadas. Como na UML, os tipos abstratos tem seu rotulo em italico. Somentetipos que tem codigo fonte disponıvel sao representados, pertencentes ao domınio daaplicacao.

Figure 4. Invocacoes

Invocacoes: sao representadaspor linhas solidas com setas.Ja as invocacoes polimorficassao representados por linhastracejadas. Os dois tipos deinvocacoes sao ilustrados naFigura4.

Namespace: namespace e umconteıner para tipos organizadosem diretorios. Um namespacee representado por um retangulocom bordas arredondadas e lin-has pontilhadas. Em Java,namespaces correspondem aospackages.

VEM

48

Usando esta notacao, o Polymorphic View e elaborado a partir da analise estaticado codigo. Como pode ser observado pela Figura 5, a interface Drawable e ex-plicitamente representada como um tipo abstrato (borda tracejada) e as invocacoespolimorficas (chamadas pelo metodo draw) sao representadas por linhas tracejadas paracada implementacao de Drawable (tipos Rectangle, Circle e Line). Atraves dessavisulizacao, e possıvel observar que a invocacao do metodo draw pela classe Plotter erepresentada por uma linha solida, uma vez que e, de fato, uma invocacao do metodoimplementado nos tipos concretos Rectangle, Circle e Line.

Figure 5. Polymorfic View para a Fig. 1

Neste sentido, o Polymor-phic View permite com apenasum diagrama observar o relaciona-mento entre tipos polimorficos e seusclientes (Plotter, por exemplo), bemcomo o relacionamento entre os tipospolimorficos e outras classes que im-plementam seus metodos. Nossa abor-dagem permite tambem a analise douso de polimorfismo a partir de umaperspectiva arquitetural, destacandorelacionamentos que estao tipicamenteescondidos.

Para gerar o Polimorphic View,usamos uma ferramenta chamada Soft-ware Pathfinder, desenvolvida pelonosso grupo de pesquisa. Na proximasecao, e demonstrado o uso do Poly-morphic View em dois projetos Java.

3. Entendendo o Polimorfismo

Nesta secao, apresentamos como oPolymorphic View pode auxiliar na compreensao do uso de polimorfismo. Para esteproposito, foram analisados dois projetos de codigo aberto: JUnit e FindBugs. A analisefoi desenvolvida atraves dos seguintes passos:

1. Extrair os dados dos projetos, atraves da analise estatica feita pelo SoftwarePathfinder;

2. Pesquisar todas as classes abstratas e interfaces;3. Filtrar os tipos usando seguintes as regras:

• Profundidade da hierarquia (PH) >= 1;• Numero de filhos (NDF ) >= 1;• Numero de metodos abstratos (NMA) >= 1;• ter pelo menos um cliente;

4. Construir o Polymorfic View para cada tipo filtrado;5. Analisar o uso do polimorfismo atraves da visualizacao;6. Complementar a analise com o codigo fonte.

VEM

49

Nas proximas secoes iremos apresentar alguns exemplos do uso de polimorfismoencontrados nos projetos JUnit e FindBugs. Como criterio para selecionar os exemplos,focamos essencialmente em padroes de projeto GOF [Gamma et al. 1995].

3.1. JUnit

JUnit1 e um framework escrito em Java, seguindo a arquitetura xUnit para frameworksde teste unitario. Apos construırmos os Polymorphic Views para o codigo do JUnit,encontrou-se um caso do padrao Composite, apenas observando a invocacao polimorficade TestSuite para Test, realizada pelo metodo run(), ilustrado na Figura 6. Test e umainterface implementada por DoubleTestCase, RepeatedTest, JUnit4TestCaseFacade e JU-nit4TestAdapter, mas especialmente por TestSuite, caracterizando uma composicao. Fi-nalmente, analisando o codigo, foi confirmado a presenca do padrao Composite.

Figure 6. Polymorphic View para in-terface Test

Um outro bom exemplo de usodo polimorfismo pode ser observado naFigura 8, no qual um tipo abstrato(BaseTestRunner) e usado para evitar umadependencia cıclica. O tipo ResultPrinterusa TestListener, que e uma classe abstratae TestRunner estende BaseTestRunner, re-tornando valores para ResultPrinter.

3.2. FindBugs

O FindBugs2 e um programa que usaanalise estatica para encontrar problemasconhecidos como bug patterns: instanciasde codigo que provavelmente sao erros emprojetos Java.

Analisando o Polymorphic Viewspara este projeto, foi encontrado um exem-plo de injecao de dependencia que podeser observado na Figura 7. A classe SourceFile define uma estrutura de cache para ar-quivos que podem ser manipulados. Para isto, e usado invocacoes polimorficas paraZipSourceFileDataSource e FileSourceDataSource atraves da interface SourceFileData-Source.

3.3. Discussao

A analise desses dois projetos de codigo aberto mostrou que o Polymorphic View aux-ilia na localizacao de estruturas polimorficas, que geralmente sao escondidas em out-ras visualizacoes. Usando esta abordagem, inferencias complexas sobre os projetos po-dem ser feitas, ajudando a entender e encontrar padroes, que provavelmente exigiriamuma busca exaustiva no codigo. O Polymorphic View fornece uma perspectiva estrutural(estatica - namespaces e tipos) e comportamental (dinamica - invocacoes) em um unicodiagrama, com a exibicao das invocacoes polimorficas.

1Mais informacoes em http://www.junit.org2Mais informacoes em http://findbugs.sourceforge.net

VEM

50

Ao destacar os tipos polimorficos e suas chamadas em uma unica representacao, oPolymorphic View ajuda na compreensao de padroes arquiteturais. Para que o mesmo es-tudo fosse feito somente utilizando diagramas da UML, seria necessario, pelo menos, usarum diagrama de classe e varios diagramas de sequencia, um para cada caso de polimor-fismo, conforme discutido na secao 2.

4. Trabalhos RelacionadosEste trabalho encontra-se dentro do campo da analise de polimorfismo e reconstrucao daarquitetura. Esta relacionado tambem com os estudos empıricos que investigam a capaci-dade de uma visualizacao em apoiar a analise arquitetural polimorfica. Varios autoresrealizaram trabalhos sobre sobe polimorfismo e esta secao apresenta algumas das suasprincipais contribuicoes.

Figure 7. Polymorphic View para aclasse SourceFile e relacionamen-tos

Benlarbi e Melo[Benlarbi and Melo 1999] investigaram oimpacto do polimorfismo sobre a quali-dade do design OO, propondo um conjuntode metricas para projetos. Inicialmente,eles concluıram que o polimorfismo podeaumentar a probabilidade de falhas emsoftware OO e indicaram que ele deveser usado com precaucao pelos projetistase desenvolvedores. Eles sugeriram queo polimorfismo tende a ocorrer mais emprojetos com elevado numero de metodose arvores de heranca profundas.

Denier e Gueheneuc[Denier and Gueheneuc 2008] pro-puseram um modelo de heranca paraajudar a compreensao da hierarquia declasses com foco em metodos das classes. Eles tambem definiram metricas e regraspara destacar classes e comportamentos interessantes no que diz respeito a heranca.Alem disso, o modelo fornece como heranca e utilizada em um programa. Denier eSahraoui [Denier and Sahraoui 2009] propuseram uma visao unica e compacta de todasas hierarquias de classe usando um layout personalizado, chamado Sunburst.

Nos ultimos anos, os estudos mais importantes sobre a heranca eanalise polimorficas foram desenvolvidos por Mihancea e Marinescu. Mihancea[Mihancea 2006] introduziu uma abordagem baseada em metricas relacionadas ao grauem que uma classe base foi destinada para reutilizacao da interface. Atraves da analisede como os clientes usam a interface da classe base, essas metricas quantificam o grauem que os clientes tratam uniformemente as instancias dos descendentes da classe base,ao invocar metodos que pertencem a esta interface comum.

Em trabalhos subsequentes [Mihancea 2008] [Mihancea 2009], Mihancea intro-duziu uma abordagem visual baseada em metricas para capturar a medida em que osclientes de uma hierarquia polimorfica manipulam essa hierarquia. Um vocabulario depadrao visual tambem foi apresentado de modo a facilitar a comunicacao entre analistas.

VEM

51

Todas as abordagens acima descritas, embora valiosas, nao sao adequadas quandoo interesse e fornecer uma visao detalhada de polimorfismo. Este trabalho complementaos estudos com foco em uma visualizacao que destaca tipos abstratos e seus clientes,permitindo assim que o usuario possa capturar a maneira pela qual os clientes de umahierarquia de classes fazem uso de polimorfismo.

5. Conclusoes e Trabalhos FuturosNeste trabalho, foi a apresentado uma abordagem de explicitar o uso do polimor-fismo, utilizando uma visualizacao baseada em grafo de chamadas estaticas, denomi-nada Polymorphic View. Polymorphic View e composta por tipos, invocacoes e names-paces, permitindo o entendimento dos relacionamentos tipicamente escondidos em outrasvisualizacoes. Destina-se a ajudar na analise do uso de polimorfismo sobre uma perspec-tiva arquitetonica.

Figure 8. Polymorphic View paraclasse abstrata ResultPrinter

Apesar das vantagens promisso-ras, algumas limitacoes surgiram durantea sua utilizacao nas analises apresentadasna secao 3. Em primeiro lugar, ex-iste uma dificuldade em analisar todos osnıveis da hierarquia de tipos, escondidasna representacao de tipos. Alem disso,em alguns casos, a fim de confirmar ashipoteses sobre os padroes de projeto, foinecessario analisar o codigo fonte.

Os resultados obtidos ate o mo-mento abrem perspectivas para novasinvestigacoes sobre o polimorfismo. Emparticular, temos algumas questoes emaberto para serem respondidas: a) como ostipos polimorficos se relacionam com seusclientes? b) quais padroes de projeto queadotam polimorfismo sao encontrados? c)quais anti-padroes sao encontrados? d) hadiferencas entre o uso de polimorfismo em Java e em outras linguagens? e) uso dopolimorfismo e uma opcao deste as primeiras versoes de um tipo ou e o resultado deum processo de evolucao do software, atraves de refatoracoes, por exemplo?

Como parte de trabalhos futuros, pretendemos desenvolver uma visualizacao in-terativa, alem de acrescentar detalhes como a hierarquia de heranca e estruturas internasdos tipos (metodos e atributos). Em outra direcao, iremos avaliar o uso do PolymorphicView atraves de experimentos controlados. Finalmente, iremos investigar porque os ar-quitetos de software usam polimorfismo em seus projetos, pesquisando as intencoes portras da adocao de estruturas polimorficas.

ReferencesAmbler, A. (1995). Invocation polymorphism. In Proceedings of Symposium on Visual

Languages, pages 83–90. IEEE Comput. Soc. Press.

VEM

52

Benlarbi, S. and Melo, W. L. (1999). Polymorphism measures for early risk prediction. InProceedings of the 21st international conference on Software engineering - ICSE ’99,pages 334–344, 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: ASurvey. IEEE transactions on visualization and computer graphics, 17(7):913–933.

Denier, S. and Gueheneuc, Y.-G. (2008). Mendel: A Model, Metrics, and Rules to Un-derstand Class Hierarchies. In 2008 16th IEEE International Conference on ProgramComprehension, number 2, pages 143–152. IEEE.

Denier, S. and Sahraoui, H. (2009). Understanding the use of inheritance with visualpatterns. In 2009 3rd International Symposium on Empirical Software Engineeringand Measurement, pages 79–88. IEEE.

Dutoit, A. H. and Bruegge, B. (2010). Object-Oriented Software Engineering UsingUML, Patterns, and Java. Prentice Hall.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1995). Design Patterns: Elementsof Reusable Object-Oriented Software. Addison-Wesley, New York, New York, USA.

Grove, D., DeFouw, G., Dean, J., and Chambers, C. (1997). Call graph constructionin object-oriented languages. Proceedings of the 12th ACM SIGPLAN conference onObject-oriented programming, systems, languages, and applications - OOPSLA ’97,pages 108–124.

Hoogendorp, H. (2010). Extraction and Visual Exploration of Call Graphs for LargeSofteware Systems. PhD thesis, Groningen University.

Lange, D. and Nakamura, Y. (1997). Object-oriented program tracing and visualization.Computer, 30(5):63–70.

Larman, C. (2004). Applying UML and Patterns: An Introduction to Object-OrientedAnalysis and Design and Iterative Development, 3/e. Prentice Hall, Upper SaddleRiver, NJ, USA, 3 edition edition.

Mihancea, P. (2006). Towards a Client Driven Characterization of Class Hierarchies. In14th IEEE International Conference on Program Comprehension (ICPC’06), pages285–294. IEEE.

Mihancea, P. F. (2008). Type Highlighting: A Client-Driven Visual Approach for ClassHierarchies Reengineering. 2008 Eighth IEEE International Working Conference onSource Code Analysis and Manipulation, pages 207–216.

Mihancea, P.-f. (2009). A Novel Client-Driven Perspective on Class Hierarchy Under-standing and Quality Assessment. PhD thesis, University of Timisoara.

Ponder, C. and Bush, B. (1994). Polymorphism considered harmful. ACM SIGSOFTSoftware Engineering Notes, 19(2):35–37.

VEM

53

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 68.511 – 21945-970 – 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.

VEM

54

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 6.

2. 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.

3.1. 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

VEM

55

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.

3.2. 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.

VEM

56

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.

3.3. 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.

3.4. 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.

VEM

57

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.

4.1. Context Situation

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.

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.

Figure 3. Context situation with an interaction behavior

<RULE> ::= <CONTEXT-SITUATION> implies <FEATURES>

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

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

VEM

58

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.

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.

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.

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)

Context Rule 1 (CR_1) Develop a new reusable asset implies (Pack Layout AND Geometric Zooming AND Highlighting AND

Tooltip AND Overview AND Selection)

VEM

59

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. 11-18.

Chen, G., Kotz, D. (2000). A Survey of Context-Aware Mobile Computing Research.

Dartmouth College Technical Report TR2000-381.

VEM

60

Chi, E. H. H., & Riedl, J. T. (1998). An operator interaction framework for visualization

systems. In IEEE Symposium on Information Visualization, Durham, USA, pp. 63-

70.

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. 69-75.

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. 807-

829.

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. 737-745.

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), 2366-2375.

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. 336-343.

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. 41-48.

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. 122-125.

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), 1224-1231.

VEM

61

ArchGraph: Modularizacao Automatica de Sistemas UsandoClusterizacao de Grafos de Dependencia

Guilherme A. Avelino1, Marco Tulio Valente1

1Departamento de Ciencia da Computacao, UFMG, Brasil

{gaa,mtov}@dcc.ufmg.br

Abstract. A proper modularization is very important to aid in the maintenanceand evolution of a system. In order to help to modularize an existing software,this paper presents a strategy for automatic modularization based on data ex-tracted from source code. In our approach, dependencies between software en-tities are modeled using graphs and, by relying on clustering algorithms, weconstruct logical groupings of such entities.

Resumo. Uma adequada modularizacao e de grande importancia para auxi-lio na manutencao e evolucao de um sistema. Buscando auxiliar a atividadede modularizar um sistema ja existente, esse artigo apresenta uma estrategiapara geracao automatica da modularizacao baseada em dados extraıdos de seucodigo fonte. Em nossa abordagem, dependencias entre entidades de um soft-ware sao modeladas utilizando grafos e, aplicando algoritmos de clusterizacao,construımos agrupamentos logicos de tais entidades.

1. IntroducaoUma boa modularizacao e essencial para o adequado desenvolvimento e evolucao de umsoftware. Um bom projeto modular facilita o gerenciamento do software, permitindo adivisao de atividades, alem de limitar o escopo de alteracoes e melhorar o entendimentodo sistema [Parnas 1972]. Entretanto, existem diversos sistemas que nao foram desenvol-vidos de forma modular, ou ainda sua modularizacao pode ter sofrido uma degradacaodurante sua evolucao [Lehman et al. 1997]. Para tornar a manutencao de tais sistemasnovamente gerenciavel e preciso remodulariza-los, agrupando as entidades de softwarebaseados em suas semelhancas e dependencias.

Nesse trabalho, apresentamos uma tecnica e uma ferramenta de apoio, denomi-nada ArchGraph, que extrai as dependencias entre classes a partir do codigo fonte deum sistema Java e representa tais dependencias utilizando grafos. Com base no grafogerado, sao usados dois diferentes algoritmos de clusterizacao, objetivando identificarpossıveis agrupamentos logicos desses artefatos baseados em suas dependencias. Os al-goritmos utilizados, representam duas diferentes estrategias de clusterizacao: algoritmosde otimizacao e algoritmos baseados na teoria dos grafos [Wiggerts 1997], permitindoassim avaliar duas diferentes estrategias, as quais sao comparadas no final.

O restante deste artigo esta organizado da seguinte forma. A Secao 2 apresentaa solucao proposta no artigo, explicando como essa foi construıda e detalhando os algo-ritmos utilizados. A Secao 3 apresenta um estudo de caso desenvolvido com objetivo deavaliar a qualidade da modularizacao gerada. Trabalhos relacionados sao apresentados naSecao 4. Por fim, a Secao 5 conclui este trabalho e levanta alguns trabalhos futuros.

VEM

62

2. Solucao Proposta

O ArchGraph foi desenvolvido como um plug-in para o ambiente de desenvolvimentoEclipse. Essa abordagem, alem de facilitar a utilizacao da ferramenta ao integra-la em umambiente de desenvolvimento largamente utilizado, ajuda na extracao das informacoes dedependencias entre entidades de projetos em desenvolvimento. As subsecoes seguintesapresentam detalhes de como a solucao foi construıda.

2.1. Arquitetura

Conforme mostra a Figura 1, o plug-in ArchGraph e formado por tres componentes prin-cipais: Extrator de Dependencias, Motor de Clusterizacao e Gerador da Visualizacao,cada um responsavel por uma etapa do processo de geracao dos modulos.

Figura 1. Arquitetura proposta

Na primeira etapa, o Extrator de Dependencias faz o parsing de uma arvoresintatica abstrata extraıda de um projeto Java e constroi seu grafo de dependencias. Nessegrafo, cada classe e representada atraves de um no e a dependencia entre classes e sinali-zada atraves de uma aresta.

Na segunda etapa, o grafo e repassado ao Motor de Clusterizacao, o qual aplicaum dos algoritmos detalhados na Secao 2.2, gerando um conjunto de conjuntos de classes,que representam a nova modularizacao proposta por nossa solucao.

A ultima etapa, realizada pelo Gerador da Visualizacao, consiste na apresentacaografica da modularizacao proposta. Para auxiliar nao so o entendimento, como tambem naavaliacao da modularizacao produzida, sao geradas duas representacoes diferentes: umautilizando grafos, onde os agrupamentos sao sinalizados atraves de cores e outra utili-zando um Mapa de Distribuicao [Ducasse et al. 2006], que apresenta os modulos geradosmapeados nos pacotes reais do sistema. A Secao 3 fornece mais detalhes de como osresultados sao apresentados.

2.2. Algoritmos de Clusterizacao

Apos a geracao do grafo de dependencias das classes do sistema alvo, e preciso identificarquais classes estao relacionados e assim inferir como essas podem ser agrupadas. Pararealizar tais atividades, o ArchGraph implementa os dois algoritmos detalhados a seguir.

VEM

63

2.2.1. Hill Climbing

Para avaliar a qualidade da modularizacao de um sistema dois criterios largamente utiliza-dos sao coesao e acoplamento [Anquetil et al. 1999]. Coesao avalia o grau de similaridadeentre classes agrupadas (intra-cluster) e acoplamento define a similaridade entre classesde diferentes agrupamentos (inter-clusters). Utilizando tais caracterısticas como criteriode qualidade, uma boa modularizacao deve maximizar a coesao e diminuir o acoplamento.

Adotando tais criterios, podemos definir uma funcao, que dado um grafo e umconjunto de agrupamentos de classes, retorne um valor baseado no numero de arestasintra-cluster e inter-clusters, sendo retornado valores maiores para agrupamentos commais arestas intra-cluster do que inter-clusters. Com tal funcao, nosso problema de modu-larizar um software poderia ser resolvido com uma busca pelo agrupamento ideal, ou sejaaquele com maior valor para tal funcao. O problema dessa abordagem e que mesmo parasistemas pequenos a quantidade de agrupamentos possıveis e muito grande. Como exem-plo, para um sistema com 15 classes, terıamos 1.382.958.545 agrupamentos possıveis.Como a maioria dos sistemas possui bem mais classes, normalmente centenas ou milha-res delas, tal abordagem e inviavel computacionalmente.

Quando a solucao otima nao e viavel devemos buscar solucoes aproximadas, queembora nao garantam o resultado otimo, retornam resultados suficientemente adequados.O algoritmo Hill Climbing [Russell and Norvig 2009] se encaixa nesse cenario. Ele iniciacom uma solucao arbitraria do problema e tenta achar um resultado melhor, incremental-mente, mudando um unico elemento da solucao obtida ate aquele momento. Se a mudancaproduzir um melhor resultado, uma nova mudanca e feita nessa nova solucao, sendo essepasso repetido ate que nao seja possıvel encontrar mais melhorias no resultado.

Nossa implementacao para o algoritmo Hill Climbing se baseia no trabalho deMancoridis e Mitchell [Mancoridis et al. 1998], o qual utiliza a funcao de qualidade damodularizacao (MQ) apresentada abaixo. A formula define a qualidade em termos dasoma do grau de dependencias entre classes do mesmo cluster (Ai) e de dependenciasentre classes de clusters diferentes (Eij), sendo k o numero total de clusters.

MQ =

{1k

∑ki=1Ai − 1

k(k−1)2

∑ki,j=1Ei,j , se k > 1

A1 , se k=1(1)

2.2.2. Betweenness

O segundo algoritmo tem como base o trabalho de Girvan e Newman[Girvan and Newman 2002], que propoe uma variacao do algoritmo tradicional deBetwenness, realizando o calculo da centralidade das arestas ao inves da centralidadedos vertices. A centralidade das arestas de um grafo e calculada tendo como baseo numero de caminhos mais curtos entre todos vertices do grafo. Se o grafo possuiconjuntos de vertices fortemente conectados e esses sao fracamente conectados a outrogrupos, por meio de uma ou poucas arestas, entao todos os caminhos mais curtos entregrupos passarao por essas poucas arestas, fazendo com que elas possuam alto valor decentralidade. Assim, o algoritmo calcula a centralidade das arestas e, ao remover as de

VEM

64

maior valor, expoe as comunidades existentes no grafo.

Em nossa solucao utilizamos uma implementacao do algoritmo Betwenness dis-ponibilizada pela biblioteca de modelagem de grafos JUNG1. Esse algoritmo requer queseja informado o numero de arestas a serem removidas.

3. Estudo de CasoPara avaliar a qualidade da modularizacao gerada, foram realizados experimentos comdois diferentes sistemas de codigo aberto: ArtOfIllusion2 e JHotDraw3. Os experimentosrealizados tem como objetivo dar respostas aos seguintes questionamentos:

• Q1: Qual dos algoritmos de clusterizacao implementado produz melhoresresultados? Mais do que eleger um vencedor, esse questionamento buscaidentificar direcionamentos para futuras pesquisas e indıcios de oportunidades deaprimoramento da solucao.

• Q2: A modularizacao gerada representa uma adequada divisao logica dosistema? A resposta a esse questionamento e de fundamental importancia parao uso pratico da ferramenta. O fato de ser gerada uma modularizacao comotimos valores de acoplamento e coesao pode nao necessariamente representar oagrupamento adequado em termos da estrutura logica do sistema.

• Q3: A modularizacao gerada e capaz de apontar falhas e/ou oportunidades demelhoria da modularizacao do sistema? Com essa pergunta buscamos identificarse mesmo o sistema tendo sido desenvolvido de forma modular nossa solucao gerainformacoes que auxiliem a aprimorar essa modularizacao.

3.1. Analise dos Algoritmos de Clusterizacao (Q1)Os dois algoritmos foram aplicados a cada um dos sistemas selecionados. Os resultadosapresentados focam em dependencias do tipo heranca, ou seja, as arestas ligam classesque possuem uma heranca direta do tipo pai e filha.

A Tabela 1 apresenta um resumo dos experimentos. O algoritmo Betweenness foiconfigurado para remover 10% das arestas existentes (32 para ArtOfIllusion e 48 para oJHotDraw). Foram realizadas 10 execucoes do Hill Climbing, sendo os valores apresen-tados uma media dos resultados obtidos.

Tabela 1. Resultados dos testes. *media, com desvio padrao inferior a 0,01

Sistema Hill Climbing* BetweennessMQ No de Clusters MQ No de Clusters

ArtOfIllusion 0,5280 49 0,2728 57JHotDraw 0,5928 104 0,4236 120

Analisando os clusters gerados pelos dois algoritmos, mostrados na Figura 2, epossıvel observar que o algoritmo de Hill Climbing tende a agrupar uma grande quanti-dade de classes em um unico cluster e o restante das classes sao divididas em pequenos

1Java Universal Network/Graph. http://jung.sourceforge.net2http://www.artofillusion.org3http://www.jhotdraw.org

VEM

65

clusters. Essa forma de agrupamentos e descrita como uma divisao nao adequada de umsistema em [Anquetil et al. 1999], sendo denominada black hole, pois um cluster atuacomo um buraco negro absorvendo praticamente todas as classes. Ja a modularizacaosugerida pelo algoritmo Betweenness, mesmo sem uma analise individual dos clusters, emais proxima de uma modularizacao esperada, onde temos diversos modulos de tamanhossimilares e poucas classes nao agrupadas.

(a) ArtOfIllusion com Betweenness (b) ArtOfIllusion com Hill Climbing

(c) JHotDraw com Betweenness (d) JHotDraw com Hill Climbing

Figura 2. Resultado da clusterizacao com os dois diferentes algoritmos

Tendo em vista que o algoritmo Betweenness apresentou sugestoes demodularizacao mais proximas de uma divisao logica do sistema, os questionamentos Q2e Q3 serao analisados com foco nos resultados obtidos com esse algoritmo.

3.2. Analise da Qualidade da Modularizacao Gerada (Q2 e Q3)Para avaliar a qualidade da modularizacao utilizaremos a visualizacao do resultado comoum Mapa de Distribuicao. Um Mapa de Distribuicao e uma visualizacao na qual os pa-cotes sao mostrados como caixas, sendo essas preenchidas com quadrados coloridos querepresentam as classes do pacote. Em nossa visualizacao a cor/numero do quadrado repre-senta o modulo sugerido pela ferramenta para aquela dada classe. Dessa forma, utilizandoo Mapa de Distribuicao e possıvel comparar a modularizacao sugerida pela ferramenta(cor das classes) com a modularizacao real (caixas representando os pacotes do sistema).

Os Mapas de Distribuicao, obtidos com o algoritmo Betweenness na configuracaodescrita anteriormente, sao apresentado na Figura 3. Para evitar uma poluicao excessivada figura, removemos clusters com menos de tres classes e apresentamos apenas os 20pacotes com maior numero de classes.

Para analise da qualidade da modularizacao destacamos algumas observacoes:

VEM

66

(a) ArtOfIllusion

(b) JHotDraw

Figura 3. Mapa de Distribuicao para os dois sistemas analisados. Cadanumero/cor corresponde a um dos agrupamentos gerados pela ferramenta

• A sugestao de modularizacao para o pacote artofillusion.image.filter foi exa-tamente implementada. Esse pacote contem todas as classes do cluster 18. Omesmo acontece com os pacotes org.jhotdraw.draw.connector e artofillusion.test.

• Dentre as 45 classes do pacote artofillusion.procedural, 43 classes pertencemao modulo 16, sugerido pelo ArchGraph, e as duas outras foram colocadas nomodulo 6. Ao analisar as classes detalhadamente e possıvel observar que todasas 43 classes do pacote estao relacionadas com a classe denominada Module eque o padrao de nome dessas 43 classes tem como subnome “Module”. A mesmaanalise leva a crer que as outras duas classes estariam melhor agrupadas no pacoteartofillusion.ui, pois elas estao relacionadas a criacao de interface grafica e menus.

• O pacote artofillusion.raytracer possui 12 classes, sendo que nesse caso foisugerida a distribuicao dessas classes em dois modulos diferentes, 13 e 14. Umaanalise, utilizando apenas o padrao de nomenclatura das classes, valida a sugestaoda ferramenta, pois as classes do modulo 13 possuem em sua nomenclatura osubnome “Light”(RTLight, RTSphericalLight e RTDirectionalLight), enquantoque as demais possuem outro padrao de nomenclatura. Analise semelhante podeser estendida a pacotes como animation.distorcion e org.jhotdraw.app.action.edit.

• O pacote artofillusion e um dos pacotes que apresentou maior variedade demodulos. Foi sugerido que muitas das classes desse pacote fossem agrupadascom classes de outros pacotes. Um fato a ser observado nesse caso e que o pacoteartofillusion e a raiz do projeto. A raiz do projeto e normalmente o local ondeas classes sao criadas quando nao se sabe ou se esta em duvida sobre qual pacoteuma classe deve pertencer. Dessa forma, o fato de a ferramenta ter sugerido uma

VEM

67

modularizacao bem diferente da implementada nesse pacote pode ser entendidocomo indıcio de que nao ha uma adequada modularizacao de suas classes.As quatro observacoes destacadas contribuem para mostrar que a modularizacao

gerada pela ferramenta faz sentido do ponto de vista logico do sistema (Q2), pois repre-senta em muitos casos a implementacao observada na pratica para os sistemas analisados.Alem disso as tres ultimas observacoes sugerem que a ferramenta e capaz de gerar indıciosde erros de modularizacao, bem como oportunidades para aprimoramento dessa (Q3).

4. Trabalhos RelacionadosDois trabalhos importantes na area sao [Anquetil et al. 1999] e [Wiggerts 1997], pois re-alizam uma explanacao ampla sobre o tema, sendo bastante uteis para conhecimento dasprincipais tecnicas de clusterizacao utilizadas para engenharia reversa de sistemas.

A ferramenta BUNCH [Mancoridis et al. 1998, Mitchell and Mancoridis 2006]representa um dos principais trabalhos relacionadas a clusterizacao de sistemas baseadoem informacoes extraıdas do codigo fonte. BUNCH realiza a clusterizacao com basena busca por agrupamentos de entidades que apresentem maior valor para uma funcaode qualidade da modularizacao, utilizando para isso um algoritmo baseado na tecnica deHill Climbing e heurısticas para geracao do agrupamento inicial e dos agrupamentos vizi-nhos. Outros trabalhos que seguem abordagem semelhantes sao [Praditwong et al. 2011]e [Annervaz et al. 2013].

Nosso trabalho difere desses trabalhos mencionados, pois nao se restringe ao usode algoritmos baseado em busca heurıstica. Como abordagem alternativa, adaptamos umalgoritmo de identificacao de comunidades em grafo, baseado na centralidade de arestas,para o problema de modularizacao de sistemas. No melhor do nosso conhecimento, naoexistem trabalhos que empreguem tal abordagem.

5. Conclusoes e Trabalhos FuturosEsse trabalho apresentou uma solucao para modularizacao automatica de sistemas ba-seada no uso de tecnicas de clusterizacao. Os resultados obtidos mostram que emboraa modularizacao proposta pela ferramenta nao seja necessariamente a ideal e uma boaindicacao do caminho a ser seguido, sendo util como um modelo inicial, a ser refinadopor um engenheiro de software.

Foi possıvel observar que mesmo com valores inferiores de MQ os resultadosapresentados pelo algoritmo Betweenness sao mais proximos de uma modularizacao ade-quada. Tais resultados indicam que essa e uma abordagem promissora, sendo uma alter-nativa ao tradicional uso do algoritmo Hill Climbing (usado, por exemplo, pela conhecidaferramenta Bunch).

Em trabalhos futuros deseja-se realizar testes com outros algoritmos declusterizacao, bem como a combinacao de diferentes tipos de dependencias entre clas-ses. Pretende-se tambem investigar modificacoes na formula de calculo da qualidade damodularizacao, pois acreditamos que e possıvel aprimora-la de forma que ela gere me-lhores resultados.

Por fim, pretende-se investigar o uso dos clusters propostos para detectar violacoesarquiteturais [Passos et al. 2010, Terra and Valente 2009] e tambem para comparar e ana-lisar remodularizacoes de sistemas [Santos et al. 2014, Silva et al. 2014].

VEM

68

AgradecimentosGostarıamos de agradecer o auxılio da FAPEMIG e CNPQ.

ReferenciasAnnervaz, K. M., Kaulgud, V. S., Misra, J., Sengupta, S., Titus, G., and Munshi, A.

(2013). Code clustering workbench. In 13th IEEE International Working Conferenceon Source Code Analysis and Manipulation (SCAM), pages 31–36.

Anquetil, N., Fourrier, C., and Lethbridge, T. C. (1999). Experiments with clustering as asoftware remodularization method. In 6th Working Conference on Reverse Engineering(WCRE), pages 235–255.

Ducasse, S., Girba, T., and Kuhn, A. (2006). Distribution Map. 22nd IEEE InternationalConference on Software Maintenance (ICSM), 0:203–212.

Girvan, M. and Newman, M. E. J. (2002). Community structure in social and biologicalnetworks. National Academy of Sciences, 99(12):7821–7826.

Lehman, M., Ramil, J., Wernick, P., Perry, D., and Turski, W. (1997). Metrics and lawsof software evolution-the nineties view. In 4th International Software Metrics Sympo-sium, pages 20 –32.

Mancoridis, S., Mitchell, B. S., Rorres, C., Chen, Y.-F., and Gansner, E. R. (1998). Usingautomatic clustering to produce high-level system organizations of source code. In 6thInternational Workshop on Program Comprehension (IWPC), pages 45–52.

Mitchell, B. and Mancoridis, S. (2006). On the automatic modularization of softwaresystems using the Bunch tool. IEEE Transactions on Software Engineering, 32(3):193–208.

Parnas, D. (1972). On the criteria to be used in decomposing systems into modules.Communications of the ACM, 15(12):1053–1058.

Passos, L., Terra, R., Diniz, R., Valente, M. T., and Mendonca, N. C. (2010). Static archi-tecture conformance checking – an illustrative overview. IEEE Software, 27(5):82–89.

Praditwong, K., Harman, M., and Yao, X. (2011). Software module clustering as a multi-objective search problem. IEEE Transactions on Software Engineering, 37:264–282.

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 usingsemantic clustering. In IEEE Conference on Software Maintenance, Reengineeringand Reverse Engineering (CSMR-WCRE), pages 224–233.

Silva, L., Valente, M. T., and Maia, M. (2014). Assessing modularity using co-changeclusters. In 13th International Conference on Modularity, pages 49–60.

Terra, R. and Valente, M. T. (2009). A dependency constraint language to manage object-oriented software architectures. Software: Practice and Experience, 32(12):1073–1094.

Wiggerts, T. (1997). Using clustering algorithms in legacy systems remodularization. 4thWorking Conference on Reverse Engineering (WCRE), pages 33–43.

VEM

69

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 ensino-

aprendizado [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.

VEM

70

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 1219.

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: é

VEM

71

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?

VEM

72

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

Requisitos

Gerência de

projeto

Gerência de

projeto

Medição de

Software

Gerência de

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 web1.

4.1. 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 1219. 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

1 http://paulojunior.jatai.ufg.br/pages/49922-trabalho-de-conclusao-de-curso

VEM

73

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.

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

A

B C

D

VEM

74

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 1219. 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”.

VEM

75

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

VEM

76

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. 2010.

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. 2008.

BIGGS, J.; TANG, C. “Teaching For Quality Learning At University”. 4ª Edição. 480p.

McGraw-Hill. 2011.

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. 982-1003, 1989.

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. 2009.

GROS, B. “The Impact of Digital Games in Education”. First Monday: Peer-reviewed Journal

on the Internet. 2003.

IEEE Std. 1219-1998. “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, 2011.

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. 2004.

NAVARRO, E.; HOEK, A. “Multi-Site Evaluation of SIMSE”. 40th ACM Technical

Symposium On Computer Science Education. 2009.

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. 2007.

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. 2007.

SAVI, R.; ULBRICHT, V. R. “Jogos Educacionais: Benefícios e Desafios”. RENOTE - Revista

Novas Tecnologias na Educação. 2009.

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. 2013.

SOMMERVILLE, I. “Engenharia De Software”. 9ª Edição. 568p. Pearson Education. 2011.

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. 2010.

VON WANGENHEIM, C. G.; VON WANGENHEIM, A. “Ensinando Computação com

Jogos”. Bookess. 2012.

VON WANGENHEIM, C. G.; THIRY, M.; KOCHANSKI, D. “Empirical Evaluation of an

Educational Game on Software Measurement”. Empirical Softw. Eng. 14, 4, 418-452. 2008.

WAZLAWICK, R. S. “Engenharia de Software: conceitos e práticas”. 368p. Campus. 2013.

VEM

77

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 Cagnin1

Faculdade de Computação – Universidade Federal de Mato Grosso do Sul (UFMS)

Caixa Postal 549 – 79.070-900 – 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.

VEM

78

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 (to-be 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 (to-be system). Rodríguez-Echeverría et al. (2011) apresentam um arcabouço para a

VEM

79

modernização sistemática de aplicações Web para aplicações RIAs2 (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 2004. 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

498.769 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.

VEM

80

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))

VEM

81

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

VEM

82

“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ós-reengenharia. 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ós-reengenharia.

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

VEM

83

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 29.074

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

VEM

84

reengenharia de um sistema de médio porte, com o apoio do Titan Framework por

alunos de graduação não especialistas em reengenharia. Isso foi possível devido à simplicidade e flexibilidade tanto do processo proposto quanto das ferramentas a ele

associadas. Acredita-se que o ProFap-R possa também ser aplicado na reengenharia de sistemas de grande porte. Para a obtenção de melhores resultados com o uso do ProFap-R recomenda-se utilizar um framework no domínio do sistema legado cuja arquitetura

seja adequada para a reengenharia. São sugeridos os seguintes trabalhos futuros: i) descrever estratégias de teste de regressão e associá-las à etapa “Efetuar Teste de

Integração e Aceitação”; ii) explicitar no processo ProFap-R outras ferramentas computacionais que podem ser utilizadas para apoiar cada etapa; e iii) conduzir estudos de casos de reengenharia com sistemas de grande porte para averiguar a eficiência do

ProFap-R nesses casos.

Referências

Cagnin, M. I., Maldonado, J., Germano, F., Penteado, R. (2003). PARFAIT: Towards a

Framework-based Agile Reeng. Process. In: Agile Develop. Conf., Salt Lake City, Utha.

Cagnin, M. I., Acosta, A., Gonçalves, C., Vieira, C., Blanes, D., Smaka, E., Sandim, H.,

Luna, J., Costa, K., Alvarenga, M., Silva, M., Oliveira, M. (2012). Gestão de Inf. das Famílias Beneficiadas no Prog. da Saúde da Família no Município de Campo Grande-

MS. Proj. Pesq. Aprovado no Edital FUNDECT/DECIT-MS/CNPq/SES N° 04/2012.

Cagnin, M. I., Turine, M., Silva, M., Landre, G., Oliveira, L., Lima, V., Santos, M., Paiva, D., Carromeu, C. (2013). ProFap: Processo Colaborativo de Manutenção de Software.

In: X Workshop de Manutenção de Softw. Moderna (WMSWM'2013), Salvador, Bahia.

Carromeu, C., Paiva, D. M. B., Cagnin, M. I., Rubinsztejn, H. K. S., Turine, M. A. S.,

Breitman, K. (2010). Component-Based Architecture for e-Gov Web Systems Development. In: 17th IEEE International Conf. and Workshops on Eng. of Computer-

Based Systems, Oxford, UK.

Chikofsky, J. E., Cross, J. H. (1990). Reverse engineering and design recovery: A

taxonomy. IEEE Software, v. 7, n. 1, p. 13-17.

Fayad, M. E.; Johnson, R. E. (2000). Domain-specific application frameworks: Frameworks

experience by industry. John Wiley & Sons, 1ª ed.

Guido, A.L., Paiano, R., Pandurino, A., Mainetti, L. Transforming legacy systems into user-

centred web applications (2010). Management of the Interconnected World - ItAIS: The Italian Association for Information Systems, p. 395-401.

Pérez-Castillo, R., de Guzmán, I., Caballero, I., Piattini, M. (2013). Software modernization

by recovering Web services from legacy databases. Journal of Software: Evolution and

Process, v. 25, n. 5, p. 507-533.

Pressman, R. S. (2011). Engenharia de Software: Uma Abordagem Profissional. McGraw

Hill, 7ª ed.

Rodríguez-Echeverría, R., Conejero, J., Clemente, P., Preciado, J., Sánchez-Figueroa, F.

(2011). Modernization of legacy web applications into rich internet applications. In: 7th Model-Driven Web Engineering Workshop, 7059 LNCS, 236-250, Paphos, Cyprus.

Ruiz, M., Espanã, S., Gonzalez, A. (2012). Model-driven organisational reengineering: A

framework to support organisational improvement. In: 38th Latin America Conference on

Informatics, Medellín-Colômbia.

Sommerville, I. (2011). Engenharia de Software. Pearson Education Brasil, 9ª ed.

VEM

85

Influencing Factors on Code Smellsand Software Maintainability: A Cross-Case Study

Tassio Vale1, Iuri Santos Souza2, Claudio Sant’Anna2

1Centro de Ciencias Exatas e Tecnologicas - CETECUniversidade Federal do Reconcavo da Bahia (UFRB) - Cruz das Almas, BA - Brazil

2Departamento de Ciencia da Computacao - DCCUniversidade Federal da Bahia (UFBA) - Salvador, BA - Brazil

tassio.vale@ufrb.edu.br, iuri.souza@ufba.br, santanna@dcc.ufba.br

Abstract. Code smell is a concept referring to code that needs refactoring andcan degrade aspects such as understandability and changeability. To the bestof our knowledge, there is a lack of qualitative studies investigating influencingfactors and mitigation strategies for code smells, that play an important roleto improve software evolution, quality and productivity. As consequence, thispaper investigates, in real-world scenarios, influencing factors for code smellsbased on a software developer point-of-view. We performed three case studiesby interviewing software developers from three different real-world systems, bycollecting both qualitative and quantitative data to generate reliable researchevidence.

1. Introduction

Code smell is a concept referring to code that needs refactoring and can degrade aspectssuch as understandability and changeability [Fowler et al. 1999]. In addition, it can be re-lated to software faults. Code smell detection approaches [Yamashita and Counsell 2013]and tools [Fontana et al. 2011] are suitable indicators of the need for maintenance in away that other purely metric-based approaches lack.

In the literature, there are proposals investigating the relationship among codesmells and maintainability. Evidence point software with bad smells are more change-prone than others [Khomh et al. 2009], and components infected by code smells exhibita different change behavior [Olbrich et al. 2009]. In particular, architecture is influencedby code smells, since they often entail modularity problems in the evaluated systems[Macia et al. 2011].

[Zhang et al. 2011] performed a literature review, analyzing the most relevant pa-pers in this area. The evidence indicate there is a higher research attention for specificsmells such as Duplicated Code, and little attention on other ones (e.g. Message Chains).In addition, their findings show very few studies report on the impact of code smells insoftware development.

There is a lack of qualitative studies investigating influencing factors and miti-gation strategies for code smells, that play an important role to improve software evolu-tion, quality and productivity. In order to mitigate code smells in a given software, it isimportant to identify and manage factors that influences the emergence of them. Such

VEM

86

influencing factors might be since time pressure for releasing a software until lack of in-formation about code smells and their associated risks. Consequently, a causality analysisin real-world scenario from both qualitative and quantitative perspectives is essential.

This paper investigates factors that influence the emergence of code smells andpossible mitigation strategies based on a software developer point-of-view. We applied across-case analysis to investigate multiple case studies seeking for empirical evidence ona specific context. Three cases provided qualitative and quantitative data from differentreal software development projects, with different developers. These results can indicatewhich factors should be managed, in order to decrease the emergence of smells in sourcecode and consequently decreasing maintainability issues.

The remainder of this paper is structured as follows: first, we present related work.Section 3 describes the activities of the proposed the research design. Section 4 presentsfindings from our analysis, and Section 5 synthesizes the gathered evidence. Section 6argues on threats to validity of this research. Finally, Section 7 summarizes findings andpresents future work.

2. Related Work[Katzmarski and Koschke 2012] investigate whether metrics agree with complexity asperceived by programmers. Their findings point programmers’ opinions are quite sim-ilar and only few metrics and in only few cases reproduce complexity rankings similar tohuman raters. Our work focus on the influencing factors instead of analyzing the metricsassociated to code smells.

[Yamashita and Moonen 2012] reports on an empirical study that investigates theextent to which code smells reflect factors affecting maintainability that have been identi-fied as important by programmers. Furthermore, [Sjoberg et al. 2013] reported an empir-ical study that investigated the relationship between code smells and maintenance effortusing the same study object from [Katzmarski and Koschke 2012].

According to [Zhang et al. 2011], the research attention is turned to code smellsand related maintainability issues. We investigate influencing factors, what makes a soft-ware development environment proper for these code anomalies. Our assumption is dis-covering those factors, we can mitigate code smells and improve maintainability.

3. Research DesignThis work takes a constructivist or interpretive philosophical perspective, assuming thereare multiple interpretations of a single event [Merriam 2009]. We performed three casestudies by interviewing software developers as well as gathering quantitative data fromthree different real-world systems. The case studies are instrumental, since we intend tounderstand the construct and build theories. After, a cross-case analysis [Eisenhardt 1989]synthesize evidence and present findings.

The main research question reflects the goal of this work, and it is derived in threespecific questions, described as following:

• Main question: Which factors influence the emergence of code smellsaccording to the software developer point-of-view?

VEM

87

– RQ1: What do software developers know about code smells?Rationale: our hypothesis is knowledge about code smells might influencedevelopers opinions, since they cannot see the impact of code smells onsoftware maintainability. Additionally, the absence of knowledge can bean influencing factor.

– RQ2: Which factors influence which code smells?Rationale: in this question, we investigate the relationship of each codesmell with the respective influencing factor(s). The developers shouldalso explain why a given factor is related to a specific code smell.

– RQ3: How to manage these influencing factors?Rationale: considering developers’ experience, besides indicating factorsthat influence the emergence of code smells, they are also able to proposemitigation strategies for this context. These evidence can be evaluated infuture research.

3.1. Data Collection

The first source of evidence for data collection is the set of metrics associated to codesmells. Code smell detection tools provide results for such metrics. In this study,we adopted the inCode tool1. A brief definition of each code smell [Lanza et al. 2005,Fowler et al. 1999] analyzed by inCode is described as follows:

Code smells related to class analysis:

Data class is the manifestation of a lacking data encapsulation, and of a poor data-functionality proximity. By allowing other modules or classes to access theirinternal data, data classes contribute to a brittle, and harder to maintain design.

Tradition breaker when a derived class breaks the inherited “tradition” and provide a large set ofservices which are unrelated to those provided by its base class

Schizophrenic class is a class that captures two or more key abstractions. It negatively affects theability to understand and change in isolation the individual abstractions that itcaptures.

God class is a design flaw refers to classes that tend to centralize the intelligence of thesystem. A God Class performs too much work on its own, delegating only minordetails to a set of trivial classes and using the data from other classes.

Code smells related to method analysis:

Feature envy refers to methods that seem more interested in the data of other classes than thatof their own class. These methods access directly or via accessor methods a lot ofdata of other classes.

Data clumps They represent groups of data that appear together over and over again, as param-eters that are passed to operations throughout the system. They represent cases ofbad/lacking encapsulation and have a negative contribution on the ease of main-taining those parts of the system that use the data clumps (by Fowler).

1inCode tool - Available at http://www.intooitus.com/products/incode/

VEM

88

Sibling duplication means duplication between siblings in an inheritance hierarchy. Two or moresiblings that define a similar functionality make it much harder to locate errorsbecause the assumption ‘only class X implements this, therefore the error can befound there”does not hold anymore.

Internal duplication means duplication between portions of the same class or module. For example, anoperation that offers a certain functionality should be solely responsible for thatfunctionality.

External duplication means duplication between unrelated capsules of the system.Message chains corresponds to the situation in which a method calls many data exposer methods

that belong to other classes (i.e. including also accessor methods, but not limitedto these, as data exposers can be also static methods, that return an object that ispart of that class).

The second source of evidence is the opinion of software developers concerningthe research questions. As data collection instrument, we applied interviews with softwaredevelopers, our unit of analysis. Interviews are effective to elicit information about thingsthat cannot be observed, such as feelings, thoughts, and intentions [Merriam 2009].

The interviews are semi-structured, considering open questions to guide the inter-viewer. It gives freedom on the sequence of the questions and exact wording, allowingthe extraction of useful and rich information. Two researchers conduct the interviews:the interviewer, asking questions and talking directly with interviewees, and the anotherresearcher taking notes of expressions, behavior and gestures of the interviewees.

The researchers conduct interviews by initially running the inCode tool and col-lecting the results. After, they start the interview asking a set of five questions to obtainthe developer background and a description of the analyzed software. Then, the inter-viewer shows the code smell quantitative results and, for each detected code smell, asksthe next five questions concerning whether he consider it as a code smell, influencing fac-tors and mitigation strategies. Finally, the interviewer try to get an overall opinion fromthe interviewee through the last two questions.

3.2. Data Analysis

The qualitative data analysis aims to interpret data obtained from different sources. Thisactivity follows incremental and iterative steps. This work performed several iterationsfor data collection and analysis. Furthermore, the techniques used for data analysis comefrom basic qualitative research. In this sense, coding, categorization and synthesis arebased on [Corbin and Strauss 2008].

The analysis activities aim to build categories, that can be themes, patterns orfindings. We adopted the coding technique for categories construction. Coding consistsof making notations in parts of the data that leads to potentially relevant informationfor answering the research questions [Merriam 2009]. The codes identified from eachinterview were compared to codes in other interviews. The constant comparison is a wayto group codes into specific categories that represent the influencing factors of code smellsas well as mitigation strategies for them.

As the process of data analysis progressed, relationships among categories werebuilt, leading to explanatory propositions. Finally, core categories were chosen according

VEM

89

to their general explanatory power, propositions emerged and a narrative was createdto describe the central story of the case. We then interrogated this narrative to build aproposal of strategy to increase motivation in the organization.

3.3. Cross-Case Analysis

The cross-case method analyzes multiples cases studies seeking for empirical evidenceon a specific fact [Yin 2008], synthesizing data, drawing inferences, and providing rec-ommendations [Eisenhardt 1989]. It enables researchers to take a look beyond the initialinsights, developing concrete findings based on them. [Yin 2008] emphasize that if simi-lar results are found in both analyzed studies, the findings can be considered robust.

The benefits of adopting a cross-case approach [Glaser and Strauss 1967] are: en-suring evidence accuracy, establishing the generality of a fact, clarifying the relevant par-ticulars of a case, testing some theory, and generating a theory (or establishing somedefinitions that should be followed).

The procedure adopted in this study is to select pairs of cases to the analysis,looking for similarities and differences among each pair [Eisenhardt 1989]. As result,we could identify new categories and concepts about the fields under study, which theinvestigators had not foreseen so far in the individual settings of each case study.

4. Results and FindingsFollowing the previously described research protocol, we present as follows the results ofthree investigated cases.

4.1. Case #1: National Transplant System

The National Transplant System (SNT) is a federal system responsible for managing thedistribution of grafts for organ donation over the country. The software developmentteam comprises five developers, and the system has implemented around nine thousandmethods. The inCode quantitative results pointed the following code smels for SNT: DataClass, Schizophrenic Class, God Class, Feature Envy, Data Clumps, Sibling Duplication,Internal Duplication, External Duplication and Message Chain. Such results were usedto interview two developers (with eight and six years of experience) of this team.

Considering Data Class, the developers consider this is not a code smell. Ac-cording to them, classes present this characteristic due to architectural decisions, and ev-ery system has classes representing business domain data. Additionally, they state DataClumps is not a code smell, since separate groups of data in specific classes does not makesense. For Sibling Duplication, the developers pointed the tool results as an error becauseit does not analyze classes semantically, and the presented duplications are semanticallyappropriate.

However, there are different opinions between the developers for Feature Envy.One developer states Feature Envy needs to be solved, and it was resulting from a baddesign decision. The other developer understand this smell as a good design decision.

For the next five code smells, the developers agree they are relevant problems inthe source code. Schizophrenic Class, God Class and Message Chain emerge due to ar-chitectural and design decisions, and specific refactoring can mitigate it. The influencing

VEM

90

factors for Internal Duplication are certain technologies to support the system develop-ment and the lack of experience of some developers in the team. Training can help tomitigate this issue. External Duplication present different factors: lack of understandingon business processes and rules as well as low priority to perform refactoring and mitigateit.

4.2. Case #2: Dental Information SystemRadioWeb is a software to support dentists during cephalometry and radiograph by ap-plying specific annotations in such exams. This software has around seven hundred meth-ods and built by a freelancer (the interviewee, with eight years of experience). The in-Code quantitative results pointed the following code smells for RadioWeb: Data Class,Schizophrenic Class, God Class, Feature Envy, Internal Duplication, External Duplica-tion and Message Chain.

Data Class and Feature Envy are not a code smells, according to the interviewee,since they comprise correct design decisions.

According to the developer, Schizophrenic Class, God Class and Message Chainemerge due to design decisions, and specific refactoring can mitigate it. Internal Duplica-tion is caused by lack of understanding on business processes and rules, and influencingfactor for External Duplication is the adopted technology to implement the system.

4.3. Case #3: UML Sequence Diagram GeneratorLirio is an academic project that consists of a compiler to generate UML sequence di-agrams using information from the source code of a given software. This project wasdeveloped by two undergraduate students in one year. The inCode quantitative resultspointed the following code smells for Lirio: Data Class, God Class, Feature Envy, DataClumps, Internal Duplication and External Duplication. One of the developers, with tenyears of experience, was interviewed.

The developer stated Data Class is not a code smell, since it is a good design deci-sion concentrating data representation in specific classes. Furthermore, he does not agreewith tool results for Internal Duplication, since it does not perform semantic analysis inthe methods.

On the other hand, God Class is a code smell emerging due to short deadlines andlack of business understanding. Lack of communication among team members influencesthe emergence of Feature Envy. In addition, Data Clumps and External Duplication areresult of bad design decisions. According to the developer, specific refactoring and longerdeadlines are essential to mitigate these code smells.

5. Cross-Case SynthesisThe first question (RQ1) investigates the understanding of code smells by the participants.The results point different levels of understanding considering the list of smells addressedin this paper. However, such a difference did not influence their opinion about the impor-tance of code smells and the respective quantitative results for software maintainability.According to them, the results guide stakeholders to seek solutions for common issues(code smells) in a given system, and it consolidated the existence of problems they al-ready knew.

VEM

91

The second question, RQ2, aimed to identify the influencing factors on codesmells. Considering the factors previously described in the respective cases, the partici-pants also identified general aspects that can influence the emergence of any code smell.A consolidated list of factors is presented next:

• Short deadlines and time pressure to deliver software;• Bad architectural decisions, that represent implementation decisions in a higher

level of granularity (e.g. at a component level, adopted technology);• Bad design decisions, that represent implementation decisions in a lower level of

granularity (e.g. concentration of business rules into specific methods or classes);• Lack of understanding of the business;• Lack of experienced developers;• Lack of refactoring effort after achieving a specific requirement;• Low priority to software quality;

The last question (RQ3) focused on identifying how to mitigate the code smellsand the respective influence factors. Most of the mitigation strategies concerned specificrefactoring that we could not generalize. The participants also proposed the followingstrategies: additional time for refactoring in the development schedules, higher priorityfor software quality, better understanding of the adopted technologies and training forinexperienced developers.

6. Threats to Validity

We discuss four threats to validity in this study [Yin 2008]: construct validity, internalvalidity, external validity, and reliability. For construct validity, our cross-case designconsiders multiples sources of evidence in the data collection (quantitative data, inter-view and field notes) as a way of encouraging convergent lines of inquiry. Consideringinternal validity, our strategy consisted of using data analysis results to make possible in-ferences by using strategies such as coding-causal loop diagram on the evidence, textualexplanation-building and discussion-validation. Despite the generalization of the findingsis not possible, we applied the case study protocol in three different real-world scenariosto address external validity. Reliability was addressed by developing a detailed researchprotocol, in order to clarify all activities of this cross-case analysis.

7. Conclusions

This paper presented a qualitative and quantitative approach to investigate influencingfactors of code smells based on a software developer point-of-view. Participants opinionspoint code smells and the quantitative information around them are important to improvesoftware maintainability. Furthermore, we identified a set of factors that influence theemergence of code smells and possible strategies to mitigate them.

As future work, we intend to have a better understanding on mitigation strategiesfor code smells. In addition, despite of applying the research protocol in different scenar-ios, it needs to be applied in other different contexts to improve external validity, since weconsidered only systems implemented in the Java language.

VEM

92

ReferencesCorbin, J. M. and Strauss, A. L. (2008). Basics of qualitative research. Sage Publ., 3. ed.

edition.

Eisenhardt, K. M. (1989). Building Theories from Case Study Research. The Academyof Management Review, 14(4):532–550.

Fontana, F., Mariani, E., Morniroli, A., Sormani, R., and Tonello, A. (2011). An experi-ence report on using code smells detection tools. pages 450–457.

Fowler, M., Beck, K., Brant, J., Opdyke, W., and Roberts, D. (1999). Refactoring: Im-proving the Design of Existing Code. Addison-Wesley Longman Publishing Co., Inc.,Boston, MA, USA.

Glaser, B. G. and Strauss, A. L. (1967). The Discovery of Grounded Theory: Strategiesfor Qualitative Research. Aldine Transaction, 8th printing edition.

Katzmarski, B. and Koschke, R. (2012). Program complexity metrics and programmeropinions. In Program Comprehension (ICPC), 2012 IEEE 20th International Confer-ence on, pages 17–26.

Khomh, F., Di Penta, M., and Gueheneuc, Y.-G. (2009). An exploratory study of theimpact of code smells on software change-proneness. In Proceedings of the 200916th Working Conference on Reverse Engineering, WCRE ’09, pages 75–84. IEEEComputer Society.

Lanza, M., Marinescu, R., and Ducasse, S. (2005). Object-Oriented Metrics in Practice.Springer-Verlag New York, Inc., Secaucus, NJ, USA.

Macia, I., Garcia, A., Von Staa, A., Garcia, J., and Medvidovic, N. (2011). On the impactof aspect-oriented code smells on architecture modularity: An exploratory study. InSoftware Components, Architectures and Reuse (SBCARS), 2011 Fifth Brazilian Sym-posium on, pages 41–50.

Merriam, S. B. (2009). Qualitative research: a guide to design and implementation.Jossey-Bass higher and adult education series. Jossey-Bass.

Olbrich, S., Cruzes, D., Basili, V., and Zazworka, N. (2009). The evolution and impact ofcode smells: A case study of two open source systems. pages 390–400.

Sjoberg, D., Yamashita, A., Anda, B., Mockus, A., and Dyba, T. (2013). Quantifying theeffect of code smells on maintenance effort. Software Engineering, IEEE Transactionson, 39(8):1144–1156.

Yamashita, A. and Counsell, S. (2013). Code smells as system-level indicators of main-tainability: An empirical study. Journal of Systems and Software, 86(10):2639–2653.

Yamashita, A. and Moonen, L. (2012). Do code smells reflect important maintainabil-ity aspects? In Proceedings of the 28th IEEE International Conference on SoftwareMaintenance (ICSM), ICSM ’12, pages 306–315. IEEE Computer Society.

Yin, R. K. (2008). Case Study Research: Design and Methods (Applied Social ResearchMethods). Sage Publications, fourth edition. edition.

Zhang, M., Hall, T., and Baddoo, N. (2011). Code bad smells: A review of currentknowledge. Journal of Software Maintenance and Evolution, 23(3):179–202.

VEM

93

How developers deal with Code Smells: the case of theSourceMiner Evolution team

Alcemir Rodrigues Santos1, Mário André de Freitas Farias1,3,Eduardo Santana de Almeida1,2, Manoel Mendonça1,2, Claudio Sant’Anna1,2

1Federal University of Bahia (UFBA)Software Engineering Laboratory (LES)

2Fraunhofer Project Center (FPC)

3Federal Institute of Sergipe (IFS)

{alcemirsantos, marioandre, esa, mendonca, santanna}@dcc.ufba.br

Abstract. Context. Identify code smells has occupied researcher mind all overthe world. Goal. In this paper we tackled this problem aiming to gather evi-dence on software metrics use and the developers refactoring intention due thepresence of code smells. Method. We performed a controlled experiment withthe team of developers of a medium sized software system. Results. Our resultsshowed that although metrics can help developers, which metric is most use-ful seems to be a personal choice. In addition, code smells may only affect therefactoring decision of less experienced developers.

1. IntroductionA challenge for software engineers and programmers is to assure quality and main-tainability for complex and large software systems [Sjoberg et al. 2013]. Such task of-ten implies problems regarding communication, compatibility, and complexity issues[Lanza et al. 2005]. Therefore, ensuring the maintainability of software systems is nota trivial task, and improving this process is a continuous work of research in the softwaremaintainability area.

In general, while software evolves with a complex design, developers may intro-duce design problems (e.g., code smells). Sometimes, these code smells can cause main-tainability obstacles to be transposed on the pursuit of code quality goals, such as under-standability and changeability [Fowler 1999]. In this sense, researchers had been tacklingsuch problems from different perspectives, either through (i) defining automatic strategyfor detecting code smells [Lanza et al. 2005, Marinescu 2004], (ii) trying to understandhow developers identify code smells [Santos et al. 2013], (iii) understanding software toimprove the maintainability based on code smells evaluations [Sjoberg et al. 2013], or(iv) pursuing better ways to identify smells with metrics supporting develepers evaluation[Guo et al. 2010].

In this context, we performed an empirical study to investigate how developersidentify code smells and to discuss the effectiveness of automatic code smells detectiontools, such as inCode and inFusion1. Section 2 describes the study settings. In this sense,we enumerate the research questions guiding our study as follows.

1Both inCode and inFusion are available at: www.intooitus.com. We use InCode (v3.8). It takesthe source code and rely on Lanza et al. [Lanza et al. 2005] strategies of smells detection.

VEM

94

RQ1 Do developers converge with the automatic code smells identification?RQ2 What strategies do developers use to find code smells in their software?RQ3 Does the code smells identification imply in the developers intention of refactoring?

In summary, we used these questions to build the contributions (see Section 3)of this paper as follows. We fostered the discussion (i) on the factors affecting the codesmell identification, (ii) on the developers reliance of software metrics in this process;and (iii) on the drivers of the developers refactoring intention. We concluded the paperby discussing the threats to validity (Section 4) and by answering the research questions(Section 6).

2. Study SettingsIn this section, we present the setting of our study. More specifically, we discuss (i)the target system analyzed; (ii) the characterization of the subjects; (iii) the controlledexperiment design; and (iv) the code smells we addressed in the investigation.

2.1. SourceMiner Evolution

SourceMiner Evolution2 (SME) [Novais et al. 2013] is a software visualization tool thatprovides support to software evolution tasks, aiming to ease software maintenance. It wasprimarily implemented in Java as an Eclipse plugin in more than 20 KLOC. We chooseSME because of convenience, since we could easily access the developers and mainlybecause it is not a trivial system and represent wide range of software systems.

Table 1 characterizes the SME tool by presenting software metrics values ad-dressing different quality attributes, such as complexity, coupling and inheritance.We chose these metrics because they are well known [Chidamber and Kemerer 1994,Lanza et al. 2005], easy to understand and depict a wide view of our target system.

Table 1. Essential metrics values of SourceMiner Evolution.Quality Attribute Metric Acronym Metric Name Value

Size

NOP Number of Packages 36LOC Number of Lines of Code 23.878NOC Number of Classes 296NOM Number of Methods 1.730

2.2. Subjects Characterization

We called the seven SME developers to participate voluntarily. One developer did notanswer the call and another could not attend due to lack of schedule, all others attended.Each developer worked on different parts of SME with eventual intersections. Those whoattended the call have different formal education: a Ph.D. student (Dev2); a M.Sc. student(Dev1); and three undergraduate students (Devs 3, 4, and 5). Dev2 leads the project andadvised the three undergraduate students during their work. We refer to them as DevX(X = [1..5]) for now on.

2.3. Experimental Design

We designed our (quasi-)experiment following Wohlin [Wohlin et al. 2012] guidelines.First, we carried out a pilot study and then the experiment itself. The pilot study was

2Software developed at Software Engineering Lab (LES): www.les.dcc.ufba.br

VEM

95

carried out with two master students which did not know the SME source code in ad-vance. They had different performances leading the pilot study to inconclusive results.The pilot study took too long so that we calibrate the experiment task by reducing thenumber of code smells instances analyzed by the participants. The study included twocode smells: God Class (when a class tends to concentrate functionality from severalunrelated classes, while at the same time increasing coupling in the system) and DataClass (when the class is a "dumb" data holders, without complex functionality, butwhich are usually heavily relied upon by other classes in the system) [Lanza et al. 2005].These smells are easy to understand and wide used in the literature.

In the experiment itself, we split the subjects into ”trained” and ”under-training”developers relying on the characterization form data. We considered trained those devel-opers with a long-term training in code smells and with a large software industry experi-ence working on projects performing different roles, such as Quality Assurance Analyst,Project Manager, Requirements Analyst (Devs 1 and 2). The under-training developersare still looking forward to achieve their Computer Science degree and started to programback in high school (Devs 3, 4 and 5). These developers reported fewer than two years onaverage of experience with development and differently from the trained developers, theyreported few knowledge about code smells and refactoring.

For the experiment we used inCode to provide classes with smells. We chose thistool because it provide better support among the tools analyzed. Next, we elaborated thelist of classes (10 classes) submitted to the developers analysis by putting together classeswith and without code smells. We randomly selected the classes whithout any smell.The task assigned to the developers was the inspection of SME and the fulfillment of thequestionnaire (discussed in details in the next Section) accordingly.

Additionally, we provided printed support material to all of them before the ex-ecution of the experiment: the definition of the code smells addressed and the metricsavailable to their use. We allowed them to keep the material during the experiment.During the experiment, we provided the metrics values calculated by inCode and makeclear that its use were optional. We did not performed a formal training to avoid bias[Santos et al. 2013]. The experiment itself consists of accomplish the assigned task offulfill an questionnaire about code smells in SME, which we describe next.

2.4. Applied Questionnaire

We considered different aspects to build the questionnaire used in our experiment aimingto gather useful information to answer our research questions. More specifically, wetake into consideration: (i) the agreement with the inCode smells identification for eachclass; (ii) the agreement between the developers groups regarding their own identificationof code smells; (iii) their intention to refactor the classes they pinpointed as containingcode smells; (iv) the grading of the severity of the code smells, accordingly with their owncriteria to match with the inCode values; (v) the developers opinion if metrics helped themto perform the smells identification. To support replication, we provide the questionnairein http://goo.gl/TkDPUd.

The applied questionnaire consists of nine questions. We enumerated the ques-tions as follows. (Q1) Does this class contain this smell? (Q2) How much does this classseem a smell to you? (Q3) Would you refactor these classes? (Q4) If answered Yes in Q3,

VEM

96

grade this class according to the emergency of refactoring (order as you would refactor).(Q5) Did you work in this class? (Q6) What drove you to your answer in Q1? (Q7) Didmetrics help you to judge the classification of each class? (Q7.a) Which metrics set wasuseful to judge “Data Class”? (Q7.b) Which metrics set was useful to judge “God Class”?

3. ResultsIn this section we (i) describe the collected data and (ii) analyze the gathered informationthrough different viewpoints.

3.1. Collected DataTable 2 shows developers judgement about the presence or absence of the code smellsaddressed in our controlled experiment. For each developer there is three columns relatingdevelopers and the classes analyzed: GC, DC and W. The GC and DC columns showwhether the developer identified the God Class and Data Class code smells foreach given class or not. The severity of the code smell setted by the developer fulfillseach cell. The W column shows whether the developer worked in that class during theSME development or not. For example, Dev2 indicated the presence of God Class andData Class in the ProjectStatistic class with severities equals to one and ten,respectively, and did not worked in the class. Dev5 and Dev4 did not point out the severityof some code smells they identified during the experiment, which we represent with ahyphen (-). The column O presents an oracle regarding the automatic analysis providedby the inCode tool.

Additionally, Table 2 presents precision (p), recall (r) and f1-score of the devel-opers’ judgements. Such metrics rely on the values of ”true positives (tp)” — when thecode smell assigned by the participant was also pointed out by inCode —, ”false positives(fp)” — when the code smell assigned by the participant was not pointed out by inCode—, and “false negative (fn)” — when inCode pointed out the code smell to the class butthe participant did not. In fact, while precision indicates the fraction of code smells cor-rectly identified (tp/(tp + fp)), recall indicates the fraction of the existing occurrencesidentified (tp/(tp+ fn)). Moreover, the f1-score is an harmonic mean between precisionand recall (2 ∗ p ∗ r/(p+ r)), i.e., as much as they get higher, the F1-score increases itself.

Table 2. Developers judgement on the code smells addressed and its respectivevalues of precision, recall and accuracy.

Classes O Dev1 Dev2 Dev3 Dev4 Dev5GC DC W GC DC W GC DC W GC DC W GC DC W

TreeMapView GC (10) 4 (7) 4 (10) 4 (8) 4 (-) 4PackagesFilter DC 4 (7) (9) (-) (-)TreeMapModel GC 4 (10) 4 (8) 4 (9) 4 (-) 4

ConcernDiffModel (2) 4CouplingLayoutView 4 (5) 4 4

ConcernFilterView GC (10) (7) (5) 4CouplingModel GC (7) 4 (10) 4 (-) 4 (10) 4ProjectStatistic DC (1) (10) (10) (10) (10)

PolimetricLayoutView (2) 4 4 4 4InterfacesFilter DC (7) (9) (10)

Precision 1 # .57 1 .80 1 1 1 .75 1Recall .50 0 1 .33 1 1 .75 1 .75 1

F1-score .67 # .73 .50 .89 1 .86 1 .75 1

O: inCode oracle; GC: God Class; DC: Data Class; W: Worked?

Table 3(a) shows another excerpt of the collected data: the developers intentionto refactor the classes analyzed in the experiment. The checked cells indicate that the

VEM

97

developer intends to refactor the class. The numbers inside the parentheses depict theordering of refactoring assigned by the developer. The (-) means that the Dev2 did notinform the refactoring sequence. The questionnaire results for all questions is available inhttp://goo.gl/TkDPUd.

Table 3. (a): Developers refactoring intention and (b): Metrics use ocurrences.(a)

Classes Dev1 Dev2 Dev3 Dev4 Dev5

TreeMapView 4(1) 4(-) 4(1) 4(4) 4(1)PackagesFilter 4(1) 4(4)TreeMapModel 4(-) 4(3) 4(3) 4(2)

ConcernDiffModel 4(-)CouplingLayoutView

ConcernFilterView 4(2) 4(-) 4(4)CouplingModel 4(-) 4(2) 4(5) 4(3)ProjectStatistic 4(5) 4(6) 4(5)

PolimetricLayoutViewInterfacesFilter 4(2) 4(6)

(b)GC DC

LOC 3 -WOC 2 1CW 1 2NOACCM - 4NOPUBA - 1CPFD 2 -TCC 3 1

GC: God Class; DC: Data Class.

3.2. Data Analysis

The collected data built a rich set of information, from which we present a rationalethrough this section. For instance, we discuss the data taking into consideration (i) theprofile and previous experience of the developers, (ii) the developers self-evaluation, and(iii) the developers refactoring intention.

3.2.1. Developers Profile and Experience

The values of F1-score (Table 2) show that the under-training developers achieved closerresults to the oracle than the other group. In other words, developers with lower formal ed-ucation level and less industry experience obtained more correct answers according to theoracle (inCode). Similar experience produced similar beliefs [Passos et al. 2013], whichmight influenced on the similar judgement. Thus, both groups might have developeddifferent beliefs from their work and academic environment, which may have positivelyinfluenced the judgement of the under-training developers. We also believe that, in con-trast with the developers of the under-training group, the trained developers have differentindustry and academia experiences and such difference contributed to different beliefs,which might have increased the disagreement inside the latter group.

Such different beliefs contributed to the heterogeneous strategies used by the de-velopers to identify the code smells. While, some rely on the use of metrics, others prefercode inspection, and there were also those who to mix both approaches. We found thatmost developers resort on metrics, Dev1 was the exception. He is the most experient andused source code inspection and his experience to assess code smells. In contrast, all theothers perform an intensive use of metrics. Developers 3, 4 and 5 pointed out the metricsLOC and TCC as important to identifying God Class and developers 3 e 4 pointed out CWas important to identify Data Class. Such metrics were the most cited among the develop-ers. Despite developers reliance on the software metrics, Table 3(b) shows that the choiceof the metrics is personal, since developers reported different sets of metrics to assesseach code smell. The metrics reported were ”Lines of Code (LOC)”, ”Weighted Opera-tion Count (WOC)”, ”Class Weight (CW)”, ”Number of Accessor Methods (NOACCM)”,”Number of Public Attributes (NOPUBA)”, Capsules Providing Foreign Data (CPFD),and ”Tight Capsule Cohesion (TCC)”.

VEM

98

3.2.2. Developers Self-Evaluation

Another finding in the experiment was about the self-evaluation. We identified that eventhough the trained developers said they had a good level of knowledge about smells, theunder-training developers – whose claim otherwise – achieved better results. One possibleexplanation to their lack of confidence is their low level of formal education.

By investigating the developers characterization data collected we reached a con-sensus that under-training developers resort to the use of metrics to reinforce his judge-ment about the code smells. The fact of the under-training developers lack of confidencein their knowledge in code smells might have lead them to rely his judgement on metrics.Moreover, such behavior guide them to higher agreement with the tool.

3.2.3. Refactoring Intention

Regarding the refactoring intention, we proceeded with individual analysis for each de-veloper as follows. Dev1 intended to refactor only the classes pointed out as containingcode smells, which might imply that he only considered code smell an anomaly that maybe harmful to the system. Differently from Dev1, Dev2 intended to refactor mainly theclasses he identified a code smell which he attributed high severity. The only exceptionwas the ConcernDiffModel class, which he justifies its refactoring because he knowsthe class presented too many problems in its evolution history.

Dev3 only intended to refactor the Data Classes with higher severity and all Godclasses, excepting CouplingLayoutView. Although he assigned the same severityfor the god classes CouplingLayoutView and ConcernFilterView, he gave noexplanation why he would refactor only one of them. In fact, none of the developersintend to refactor CouplingLayoutView. Dev4 decided to refactor all the classesidentified either with “God Class” or “Data Class”. Dev5 also intended to refactor allclasses that contain code smells.

It seems that code smells do not drive developers with higher experience to refac-toring. Instead, they would apply refactoring in the pieces of code with defect reincidencewhether it contain a code smell or not. On the other hand, less experienced developersseem clearly guided by the code smells identification. In fact, their lack of experiencemight lead them to hold their judgement based on the existence of code smells instead ofactual defects or flaws.

4. Threats to Validity

Despite all the caution in controlled (quasi-)experiments, they still present threats to va-lidity [Wohlin et al. 2012]. In this section we discuss those we identified during our studyas follows.

Conclusion validity. We believe the questionnaire was properly built to achievethe expected answers to our research questions. For instance, it allow us to detect thereliance of the unexperienced developers on the use of software metrics as support forthe classes assessment. Therefore, we tried to bypass such threat to conclusion validityrelying our analysis only in the information gathered with the subject’s answers.

VEM

99

Construct validity. Regarding the experiment planning we made an effort to min-imize communication among the subjects aiming to reduce the interference among theiranswers. In addition, we tried to include all the developers of the system analysed in orderto get a wide analysis of the system regarding the code smells from different perspectives.Moreover, we clearly explained the process and introduced the support material – avail-able during the experiment execution – to avoid misguidance of the subjects. In fact, weelaborated a simple and direct questionnaire to ease the understanding of the assignedtask.

Internal validity. We only discuss data gathered with the questionnaire to assurea causal relationship between the treatment and the result. Otherwise, other factors – un-controlled and unmeasured – may influence in the analysis. Therefore, to avoid influencefrom external factors (e.g. participants comunication) we choose to carry the question-naire as a controlled (quasi-)experiment. Such decision allows us to draw more confidentconclusions, despite the fact we interviewed a small sample of developers.

External validity. Our study interviewed a small sample of developers what is thebiggest threat to the external validity. Therefore, we can not generalize our conclusions.However, in the same time, the reinforced internal validity allows us to draw insights toguide further investigations.

5. Related WorkDifferent work have already tackled the problem of code smells identification at sourcecode level [Lanza et al. 2005, Katzmarski and Koschke 2012, Santos et al. 2013]. Forinstance, Lanza et al. [Lanza et al. 2005] proposed strategies to help the automa-tion of such identification. Their strategies were implemented into the inCode tool,which performs automatic identification of code smells. Katzmarski and Koschke[Katzmarski and Koschke 2012] try to measure the agreement between developers anddifferent metrics. More specifically, the question addressed is whether program aspectsmeasured by software metrics can be used to determine program complexity from theperspective of programmers. Santos et.al. [Santos et al. 2013] carried a controlled exper-iment study on detection of the God Class code smell. They concluded that subjectstake different drivers to judge a whether a class is a God Class or not. Differently ourstudy focus on the agreement between the developers and the automatic detection with atool support.

6. Final Remarks and Future WorkWe are aware of the threats to validity and we answer the research questions to foster thediscussion on the topic rather than make a generalizable claim. With regard to RQ1 wefound by the values of precision and recall that ”under-trainning” developers judgementseems more likely to agree with the inCode automatic judgement. Instead of adopt asystematic approach, it was the “experience” and “knowledge confidence on softwaredesign and code harmfulness” that guided the “trained” developers. Such different factorsproduce different strategies of inspection for each developer. Therefore, we prefer tosuggest further investigation concerning RQ2 since our study lack of evidence on thismatter, and whichever claim would be only researchers opinions. In addition, we noticedthat the presence of code smells only affect the less experienced developers refactoringintention (RQ3).

VEM

100

By taking into consideration the evidence gathered we can draw some researchopportunities on the topic: (i) what factors influence the beliefs of developers? (ii) whatfactors drive developers to refactoring? (iii) how much the developers’ previous knowl-edge in the source code and their experience can help them to identify smells? (iv) howresearcher can discuss in-depth about developers’ beliefs on whether a code smell existsor not; (v) replicate the experiment with a larger sample and other systems. Besides that,there is also a need to discuss whether code smells reported are really a design problemin the developers’ point of view.

Acknowledgemnts: This work was partially supported by the National Institute of Sci-ence and Technology for Software Engineering (INES), funded by CNPq, grants 573964/2008-4,Universal Project (grants 486662/2013-6) and is made possible by the Cooperation Agreement#1/2012 between the Science, Technology and Innovation Secretariat of the State of Bahia, theFraunhofer-Gesellschaft and the State of Bahia.

References[Chidamber and Kemerer 1994] Chidamber, S. R. and Kemerer, C. F. (1994). A metrics

suite for object oriented design. Transactions of Software Engineering, pages 476–493.[Fowler 1999] Fowler, M. (1999). Refactoring: improving the design of existing code.

Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.[Guo et al. 2010] Guo, Y., Seaman, C., Zazworka, N., and Shull, F. (2010). Domain-

specific tailoring of code smells: An empirical study. In Proc. of the 32nd Int’l. Conf.on Software Engineering - Vol.2. ACM.

[Katzmarski and Koschke 2012] Katzmarski, B. and Koschke, R. (2012). Program com-plexity metrics and programmer opinions. In Proc. of the 20th Int’l. Conf. on ProgramComprehension, pages 17–26.

[Lanza et al. 2005] Lanza, M., Marinescu, R., and Ducasse, S. (2005). Object-OrientedMetrics in Practice. Springer-Verlag New York, Inc., Secaucus, NJ, USA.

[Marinescu 2004] Marinescu, R. (2004). Detection strategies: metrics-based rules fordetecting design flaws. In Proc. of 20th IEEE Int’l. Conf. on Software Maintenance,pages 350–359.

[Novais et al. 2013] Novais, R., Nunes, C., Garcia, A., and Mendonça, M. G. (2013).Sourceminer evolution: A tool for supporting feature evolution comprehension. InProc. of 29th IEEE Int’l. Conf. on Software Maintenance, pages 1–4.

[Passos et al. 2013] Passos, M. C. M., Cruzes, D. S., Hayne, A., and Mendonça, M. G.(2013). Recommendations to the adoption of new software practices: A case study ofteam intention and behavior in three software companies. In Proc. of the Int’l. Symp.on Empirical Software Engineering and Measurement, pages 1–10, Baltimore, USA.

[Santos et al. 2013] Santos, J. A. M., de Mendonça, M. G., and Silva, C. V. A. (2013). Anexploratory study to investigate the impact of conceptualization in god class detection.In Proc. of the 17th Int’l. Conf. on Evaluation and Assessment in Software Engineering,pages 48–59.

[Sjoberg et al. 2013] Sjoberg, D., Yamashita, A., Anda, B., Mockus, A., and Dyba, T.(2013). Quantifying the effect of code smells on maintenance effort. Transactions onSoftware Engineering, 39(8):1144–1156.

[Wohlin et al. 2012] Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B.,and Wesslén, A. (2012). Experimentation in Software Engineering. Springer BerlinHeidelberg.

VEM

101

Um Método para Identificação de Bad Smells a partir deDiagramas de Classes

Henrique Gomes Nunes1, Mariza A. S. Bigonha1,Kecia A. M. Ferreira2, Flávio Airjan Madureira1

1Departamento de Ciência da Computação – Universidade Federal de Minas Gerais

2Departamento de Computação – Centro Federal de Educação Tecnológica de Minas Gerais

{henrique.mg.bh,airjanmadureira}@gmail.com, mariza@dcc.ufmg.br

kecia@decom.cefetmg.br

Abstract. Este trabalho propõe um método para a identificação de bad smells,via métricas de software e seus respectivos valores referência, em sistemas ori-entados por objetos a partir de diagramas de classes. O método proposto foiavaliado em dois estudos: um com o objetivo de analisar os resultados dométodo aplicado a versões antigas e versões refatoradas de um conjunto de seissistemas de software abertos; e outro para comparar os resultados do métodocom a análise manual. Os resultados sugerem que o método proposto mostra-seútil para a identificação dos bad smells considerados neste trabalho.

Resumo. This work defines a method and a tool to identify bad smells, usingsoftware metrics, in class diagrams. We carried out two studies to evaluatethe proposed method: the first one aimed to evaluate the results of our methodwhen applied to old versions as well as to refactored versions of six open sourceprojects; in the second study, we compared the results of our method with theresults of manual inspections. The results suggest that our method is able toidentify the bad smells analyzed in this work.

1. IntroduçãoPara Fowler [Fowler 1999], bad smell é um indicador de um possível problema estruturalem código-fonte, que pode ser melhorado via refatoração. Com o objetivo de contribuirpara aprimorar a qualidade dos sistemas de software, alguns trabalhos têm sido desen-volvidos para identificar bad smells em software com o uso de métricas a partir de códigofonte [Marinescu 2002, Lanza et al. 2006]. Todavia, é importante que problemas sejamidentificados o mais cedo possível no ciclo de vida de um software como por exemplo nafase de modelagem, para que os problemas nas fases posteriores do desenvolvimento desoftware sejam reduzidos. Para isso, ser capaz de obter métricas a partir de modelos daUML é essencial [Soliman et al. 2010].

Dentre os diagramas definidos na UML, destaca-se o diagrama de classes, querepresenta classes de objetos e suas relações. A análise desse diagrama pode fornecermétricas relacionadas à manutenibilidade e complexidade do software logo no início doprojeto. Porém, um projeto real necessita de uma ferramenta para automatizar este pro-cesso, pois é inviável calcular tais métricas manualmente.

VEM

102

O presente trabalho visa contribuir com a solução para o problema de identificarproblemas estruturais em software a partir de modelos UML, em particular, a partir dosdiagramas de classes. Para atingir esse objetivo, neste trabalho (1) foi definido um métodode identificação de bad smells em sistemas de software a partir de diagrama de classes,aplicando métricas de software e seus valores referência e, (2) foi desenvolvida uma ferra-menta denominada UMLsmell para permitir automatizar a coleta de métricas e a aplicaçãodelas na identificação dos bad smells a partir de diagramas de classes. O método e a fer-ramenta propostos foram avaliados por meio de experimentos com sistemas de softwareabertos.

2. Método PropostoPara a definição do método proposto, inicialmente foram identificados, dentre os badsmells descritos na literatura, aqueles que podem ser aplicados a modelos de classe daUML. Foram selecionados três deles:

• God Class: corresponde a classes com alta responsabilidade no sistema. Esse badsmell está associado às métricas que permitem avaliar se uma classe possui muitosmétodos e se muitas classes dependem da classe avaliada.

• Indecent Exposure: ocorre quando uma classe está mal encapsulada. Esse badsmell está associado às métricas de atributos públicos que permitem avaliar o en-capsulamento das classes.

• Shotgun Surgery: refere-se a classes que ao serem alteradas causam impacto emoutras classes. Este bad smell está associado às métricas de relacionamentos dotipo aferentes que permitem avaliar se a alteração em uma classe implicará emalterações em outras classes.

2.1. Valores Referência

Neste trabalho foram utilizadas as seguintes métricas: Número de Conexões Aferentes(NCA), Número de Métodos Públicos (NMP) e Número de Atributos Públicos (NAP). Arazão para a escolha dessas métricas é que elas são aplicáveis a diagramas de classes epossuem valores de referência previamente definidos na literatura (Tabela 1). As métricasNCA, NMP e NAP permitem identificar os bad smells God Class, Shotgun Surgery eIndecent Exposure.

Os valores referência usados foram definidos por Ferreira et al.[Ferreira et al. 2012]. A principal razão da escolha desses valores referência é queeles foram avaliados empiricamente anteriormente. Ferreira et al. [Ferreira et al. 2012]definiram valores referência para estas métricas e os classificaram como: bom, represen-tando os valores mais frequentes para métricas em sistemas de software de boa qualidade;regular, correspondendo a valores pouco frequentes para métricas em sistemas de soft-ware de boa qualidade; ruim, correspondendo a valores raros para métricas em sistemasde software de boa qualidade. A idéia das faixas sugeridas como valores referência porFerreira et al. é que uma vez que os valores são frequentes em sistemas de software,isso indica que eles correspondem à prática comum no desenvolvimento de software dealta qualidade, o que serve como um parâmetro de comparação de um software com osdemais. Da mesma forma, os valores pouco frequentes indicam situações não usuais naprática, portanto, pontos a serem considerados como críticos.

VEM

103

Métrica Bom Regular RuimNCA até 1 2 a 20 superior a 20NAP 0 1 a 10 superior a 10NMP até 10 11 a 40 superior a 40

Table 1. Valores referência definidos por Ferreira et al. [Ferreira et al. 2012].

(a) (b)

(c)

Figure 1. Estratégia de detecção para: (a) God Class, (b) Shotgun Surgery e (c)Indecent Exposure.

Neste trabalho, optou-se por considerar as faixas regular e ruim dos valores refe-rência propostos por Ferreira et al. [Ferreira et al. 2012] na identificação de bad smellsporque tais faixas correspondem a situações não usuais na prática de desenvolvimento desoftware.

2.2. Estratégias de Detecção

As estratégias de detecção propostas são apresentadas na Figura 1. As métricas que de-finem a estratégia de detecção do bad smell God Class consideram seus relacionamentoscom outras classes e o tamanho da classe avaliada. O God Class é identificado via métri-cas NCA e NMP. A métrica NCA verifica a influência da classe avaliada sobre as outrasclasses do software, ou seja, a quantidade de classes que usam os serviços da classe avali-ada. A métrica NMP permite avaliar o tamanho de uma classe e a quantidade de serviçosa oferecer pela quantidade de métodos. Caso as duas métricas avaliadas estejam dentroda faixa regular ou ruim de acordo com os valores referência, o God Class é consideradocomo crítico. Caso contrário, a classe não é considerada como problemática.

O Shotgun Surgery é identificado via métrica NCA, que define quantas classesdependem da classe avaliada, uma vez que quando uma classe é alterada, todas as outrasclasses que dependem dela estão sujeitas a mudanças. O Indecent Exposure é um badsmell referente à falta de encapsulamento de classes. Um bom encapsulamento acontecequando os dados, atributos, de uma classe são ocultos e seus serviços, métodos, úteispara as demais classes, são públicos [Sommerville 2007]. Ele pode ser identificado viamétrica NAP, que define quantos atributos de uma classe são públicos. A identificaçãodo Indecent Exposure em uma classe e em qual faixa se encontra, regular ou ruim, éequivalente à métrica avaliada.

VEM

104

Figure 2. Estrutura da UMLsmell.

2.3. Ferramenta

A estrutura da ferramenta UMLsmell é mostrada na Figura 2. A ferramenta recebe comoentrada um arquivo XMI, no qual é realizada a análise sintática com o objetivo de ex-trair as seguintes informações: classes, atributos, métodos, parâmetros e relacionamen-tos. Esses dados são armazenados internamente nas estruturas de dados definidas peloprograma para consultas posteriores, tal que, a partir desses dados é possível forneceras informações de métricas das classes do software ao usuário. Essas métricas são, en-tão, aplicadas para identificar bad smells conforme o método proposto neste trabalho. Aferramenta foi desenvolvida na linguagem Java e possui 3205 linhas de código.

3. AvaliaçãoEsta seção relata os experimentos realizados para avaliar o método proposto e os seusrespectivos resultados. O objetivo desses experimentos foi avaliar o método para identifi-cação de bad smells a partir de diagramas de classes.

3.1. Metodologia

Os experimentos investigaram as seguintes questões de pesquisa:

RQ1: as métricas de software e seus respectivos valores referência auxiliam aidentificar bad smells em um software?

RQ2: os bad smells identificados pelo método em um diagrama de classes deum software são correspondentes àqueles identificados por avaliadores com formação emEngenharia de Software?

Para responder essas questões foram realizados dois conjuntos de experimentos:

• Análise de diagramas de classes de sistemas de software reestruturados: esse ex-perimento avalia a identificação automática de bad smells em duas versões de cadadiagrama, tal que uma versão é a refatoração da outra. Tendo em vista que umarefatoração é uma modificação realizada no software para melhorar sua estrutura,

VEM

105

espera-se encontrar mais bad smells na versão não refatorada, indicando que ométodo proposto é eficaz no reconhecimento de bad smells automaticamente.

• Avaliação Manual: este experimento avalia manualmente a identificação de badsmells e os compara com os resultados da UMLsmell a fim de avaliar a eficácia daestratégia de detecção proposta.

3.2. Diagramas de Classes dos ExperimentosForam realizados experimentos a partir dos diagramas de classes dos seguintes sistemasde software abertos desenvolvidos em Java: JHotdraw, Struts, HSqlDB, JSLP, Log4J eSweethome 3D. A seleção desses sistemas de software se deu por eles serem consideradoscomo refatorados, conforme relatado pelos autores Dig et al. [Dig and Johnson 2005] eSoares et al. [Soares et al. 2011]. Isso significa que os desenvolvedores do software, acada versão lançada, se preocuparam em melhorar a arquitetura desses sistemas de soft-ware. Para a escolha dos sistemas de software da avaliação manual, um conjunto de sis-temas de software pequenos foram escolhidos no repositório Github e foram analisadospor UMLsmell, para determinar quais deles possuiam mais bad smells. Nesse processoforam escolhidos o Picasso e JSLP, pois o fato desses sistemas de software serem pe-quenos viabilizou a inspeção manual pelos avaliadores.

Devido à carência de diagramas de classes para realizar os experimentos, os dia-gramas dos sistemas de software utilizados para esta avaliação foram obtidos a partir deengenharia reversa usando a ferramenta Enterprise Architect1 para ler os códigos fonte egerar os diagramas de classes.

Como a ferramenta Enterprise Architect não é capaz de criar todos os relaciona-mentos existentes no código fonte, utilizou-se o software Dependency Finder2 que a partirdo bytecode de um software é capaz de gerar um arquivo XML contendo os relaciona-mentos de dependência para cada classe do software. Para gerar o diagrama de classescompleto automaticamente, a partir das informações obtidas na engenharia reversa doEnterprise Architect e do resultado reportado pelo Dependency Finder, neste trabalho foidesenvolvida uma ferramenta para criar automaticamente todos os relacionamentos de de-pendência existentes no código fonte. Essa ferramenta intermediária foi desenvolvida nalinguagem Java e recebe como entrada o arquivo XMI do Enterprise Architect e o arquivoXML do Dependency Finder. A ferramenta realiza uma análise sintática do arquivo XMLe os relacionamentos são criados no arquivo XMI da engenharia reversa feita pelo Enter-prise Architect. Com isso, obteve-se um arquivo XMI resultante que contém os dados detodas as classes do software e dos relacionamentos existentes entre elas.

4. ResultadosEm praticamente todos os sistemas de software foram identificadas ao menos uma me-lhoria de bad smells de uma versão para outra refatorada. Esse resultado indica a eficá-cia do método proposto, visto que foram encontrados mais falhas na versão não refa-torada dos sistemas de software avaliados. Essas melhorias ficaram evidentes nos sis-temas de software Jhotdraw e Sweethome 3D. Nesses dois sistemas de software, a quan-tidade de bad smells foi muito superior na versão não refatorada do que na versão refa-torada, concordando com os estudos de Dig et al. [Dig and Johnson 2005] e Soares et al.

1www.sparxsystems.com.au2depfind.sourceforge.net

VEM

106

[Soares et al. 2011]. Nesses sistemas de software foram constatados que principalmentenos bad smells Shotgun Surgery e God Class a quantidade de classes que apresentavamesses problemas diminuiu, apontando que a estrutura do sistema realmente passou pormelhorias. No entanto, nesses três casos, não se pode dizer o mesmo em relação ao Inde-cent Exposure, que em alguns casos a quantidade de classes que apresentavam esse badsmell foi mantida ou aumentou da versão não refatorada para versão refatorada. Tal fatopode ter ocorrido porque esse bad smell pode não ter sido alvo de atenções durante asrefatorações.

Também foram observadas melhorias mais discretas nos sistemas de softwareStruts, Log4j, HSqlDB e JSLP. Neles, nos três bad smells avaliados, ocorreram menosmelhorias da versão não refatorada para a versão refatorada, sendo que em alguns casosocorreu aumento da quantidade de bad smells. Mas, ainda assim, foi possível detectar quea refatoração ocorreu em alguns casos nos quais os bad smells reduziram, por exemplo, oIndecent Exposure no software Struts.

A avaliação manual foi realizada por 15 especialistas com conhecimento em En-genharia de Software que não tinham informações da metodologia utilizada no estudorealizado. Foram entregues dois diagramas de classes aos especialistas e a descrição tex-tual de cada bad smell, afim de que os especialistas identificassem quais classes possuiamquais problemas. O experimento identificou resultados muito próximos dos apresenta-dos pela UMLsmell. Para os bad smells Shotgun Surgery e Indecent Exposure, as classesidentificadas como problemáticas pela UMLsmell foram as classes com maior frequên-cia de identificação pelos avaliadores. Das classes em que UMLsmell acusou a presençado bad smell God Class a maioria também foi identificada com esses bad smells pe-los avaliadores. Quatro classes identificadas como problemática pelos avaliadores, nãoforam identificadas como problemáticas pela UMLsmell. Esses resultados indicam que asestratégias de detecção definidas neste estudo, estão próximas dos resultados dos avali-adores. No caso de God Class, houve uma diferença maior entre os resultados do métodoproposto e a análise manual. Uma explicação possível para isso é que os avaliadoresprovavelmente consideraram apenas o tamanho das classes, enquanto a estratégia de de-tecção do método proposto considera também a quantidade de classes que utilizam aclasse avaliada, porém tal afirmação só poderia ser comprovada entrevistando os espe-cialistas após o experimento manual.

Os resultados dos experimentos realizados em sistemas de software tidos comorefatorados mostram que em todos os sistemas de software foram identificadas ao menosuma melhoria de bad smells de uma versão para outra refatorada. Esse resultado indicaque o método proposto é capaz de detectar automaticamente os bad smells consideradosneste trabalho, visto que foram encontradas mais falhas na versão não refatorada dos sis-temas de software avaliados. Com isso, conclui-se que a resposta para RQ1 é positiva. Damesma forma, os resultados da avaliação manual se mostraram muito próximos daquelesproduzidos por UMLsmell, o que indica que a resposta para a RQ2 também é positiva.

5. Trabalhos Relacionados

Os trabalhos de Marinescu [Marinescu 2002, Marinescu 2004] são os mais próximos dopresente trabalho. Eles apresentam uma solução para transformar métricas em infor-mações relevantes para detectar bad smells e avaliam a proposta a partir de um estudo de

VEM

107

caso com um software proprietário de pequeno porte. Bertrán [Bertrán 2009] define es-tratégias de detecção a serem aplicadas a diagramas de classe, mas evidencia a importân-cia de redefinir os valores referência utilizados em seus estudos experimentais, definidospor Marinescu [Marinescu 2002], pois considera que a técnica utilizada por Marinescu[Marinescu 2002] não seja a melhor forma de definí-los.

As principais contribuições do presente trabalho em relação aos trabalhos préviosé que ele: utiliza valores referência definidos e avaliados na literatura para as estratégiasde detecção; desenvolveu as ferramentas adequadas para a aplicação do método; avalioua estratégia proposta com uma quantidade maior de programas, de maior porte e livres, oque faculta a replicação do estudo.

6. Limitações

A principal limitação deste trabalho é a pouca quantidade de métricas que têm valoresreferência definidos na literatura. Isso limita a quantidade de bad-smells que puderam seravaliados neste trabalho. Outra limitação importante é que o ideal seria a utilização dediagramas de classes para a realização dos estudos de avaliação do método proposto. To-davia, é difícil obter esse tipo de diagrama em projetos abertos e, em geral, há restriçõespor parte das organizações em fornecer qualquer dado sobre seus sistemas de softwareproprietários. Devido a isso, os diagramas foram obtidos via engenharia reversa a par-tir do código fonte de sistemas de software abertos. A utilização de valores referênciaobtidos a partir de código fonte e não de diagramas de classes também pode influenciarna ocorrência de mais resultados do tipo falso positivo, pois diagramas de classes sãomais abstratos que códigos fonte. Apesar dessas limitações, os resultados da avaliaçãodo método proposto indicam que ele é capaz de auxiliar, de forma automática, a identi-ficação de bad smells em software orientado por objetos a partir de diagrama de classes,utilizando, para isso, métricas de software e seus respectivos valores referência.

7. Conclusão

Neste trabalho foi proposto um método para permitir identificar desvios de projeto desoftware nas fases iniciais do ciclo de vida do sistema. O método proposto se baseia emextrair métricas de diagramas de classes e usar os valores referência propostos na litera-tura para tais métricas para identificar bad smells. Foram identificados os bad smell quepodem ser extraídos de diagramas de classes e, então, foram identificadas na literaturaas principais métricas que podem ser extraídas de diagramas de classes. Em relação àsmétricas, duas características foram levadas em consideração: primeiro, as métricas de-veriam possuir valores referência propostos na literatura e segundo, as métricas deveriamrepresentar melhor os bad smells que podem ser identificados em diagramas de classes.Os valores referência usados para relacionar as métricas aos bad smells Shotgun Surgery,God Class e Indecent Exposure foram definidos por Ferreira et al. [Ferreira et al. 2012].Também foi projetada e implementada uma ferramenta, denominada UMLsmell, que per-mite aplicar o método proposto. A ferramenta identifica automaticamente bad smells emdiagramas de classes.

Para avaliar o método, foram conduzidos dois estudos. O primeiro foi realizadocom o objetivo de verificar se o método proposto identifica os bad smells consideradosneste trabalho, a partir da comparação entre versões de sistemas de software que, de

VEM

108

acordo com relatos na literatura, passaram por refatorações. O segundo estudo teve porobjetivo comparar os resultados reportados pelo método e a avaliação manual. Os resul-tados dos estudos sugerem que o método proposto auxilia a identificar automaticamentea presença de bad smells em diagramas de classes.

Os seguintes trabalhos futuros são identificados a partir dos resultados do presentetrabalho: a identificação de valores referência para outras métricas, que será importantepara viabilizar a detecção de outros bad smells com o método proposto; avaliar o usode outras métricas para avaliar os bad smells considerados neste trabalho a fim de refi-nar as estratégias de detecção sugeridas; estender a ferramenta proposta para viabilizar aidentificação de outros bad smells.

ReferencesBertrán, I. M. (2009). Avaliação da qualidade de software com base em modelos uml.

Dissertação da PUC-RJ. Rio de Janeiro, RJ, Brasil. Pontifícia Universidade Catolicado Rio de Janeiro.

Dig, D. and Johnson, R. (2005). The role of refactorings in api evolution. In SoftwareMaintenance, 2005. ICSM’05. Proceedings of the 21st IEEE International Conferenceon, pages 389–398. IEEE.

Ferreira, K. A., Bigonha, M. A., Bigonha, R. S., Mendes, L. F., and Almeida, H. C.(2012). Identifying thresholds for object-oriented software metrics. Journal of Systemsand Software, 85(2):244–257.

Fowler, M. (1999). Refactoring: improving the design of existing code. Addison-WesleyLongman Publishing Co., Inc., Boston, MA, USA.

Lanza, M., Marinescu, R., and Ducasse, S. (2006). Object-Oriented Metrics in Practice.Springer-Verlag New York, Inc., Secaucus, NJ, USA.

Marinescu, R. (2002). In Measurement and Quality in Object-Oriented Design, Tese deDoutorado. Timisoara, Romênia. University of Timisoara.

Marinescu, R. (2004). Detection strategies: metrics-based rules for detecting design flaws.In Software Maintenance, 2004. Proceedings. 20th IEEE International Conference on,pages 350 – 359.

Soares, G., Catao, B., Varjao, C., Aguiar, S., Gheyi, R., and Massoni, T. (2011). Analyz-ing refactorings on software repositories. In Software Engineering (SBES), 2011 25thBrazilian Symposium on, pages 164–173. IEEE.

Soliman, T., El-Swesy, A., and Ahmed, S. (2010). Utilizing ck metrics suite to uml mod-els: A case study of microarray midas software. In Informatics and Systems (INFOS),2010 The 7th International Conference on, pages 1 –6.

Sommerville, I. (2007). Engenharia de Software 8a ed. São Paulo: Pearson AddisonWesley.

VEM

109

KDM-RE: A Model-Driven Refactoring Tool for KDMRafael S. Durelli1, Bruno M. Santos2, Raphael R. Honda2,

Márcio E. Delamaro1 and Valter V. de Camargo2

1Computer Systems Department University of São Paulo - ICMCSão Carlos, SP, Brazil.

2Computing DepartamentFederal University of São Carlos - UFSCAR

São Carlos, SP, Brazil.

{rdurelli, delamaro}@icmc.usp.br1,

{valter, bruno.santos, raphael.honda}@dc.ufscar.br2

Abstract. Architecture-Driven Modernization (ADM) advocates the use of mod-els as the main artifacts during modernization of legacy systems. KnowledgeDiscovery Metamodel (KDM) is the main ADM metamodel and its two mostoutstanding characteristics are the capacity of representing both i) all systemdetails, ranging from lower level to higher level elements, and ii) the dependen-cies along this spectrum. Although there exist tools, which allow the applicationof refactorings in class diagrams, none of them uses KDM as their underlyingmetamodel. As UML is not so complete as KDM in terms of abstraction lev-els and its main focus is on representing diagrams, it is not the best metamodelfor modernizations, since modifications in lower levels cannot be propagated tohigher levels. To fulfill this lack, in this paper we present a tool that allows theapplication of seventeen fine-grained refactorings in class diagrams. The maindifference from other tools is that the class diagrams uses KDM as their under-lying metamodel and all refactorings are applied on this metamodel. Therefore,the modernizer engineer can detect "model smells" in these diagrams and applythe refactorings.

1. IntroductionArchitecture-Driven Modernization (ADM) is an initiative which advocates for the appli-cation of Model Driven Architecture (MDA) principles to formalize the software reengi-neering process. According to the OMG the most important artifact provided by ADM isthe Knowledge Discovery Metamodel (KDM). KDM is an OMG specification adopted asISO/IEC 19506 by the International Standards Organization for representing informationrelated to existing software systems. KDM is structured in a hierarchy of four layers; In-frastructure Layer, Program Elements Layer, Runtime Resource Layer, and AbstractionsLayer. We are specially interested in the Program Elements Layer because it defines theCode and Action packages which are widely used by our tool. The Code package definesa set of meta-classes that represents the common elements in the source-code supportedby different programming languages such as: (i) ClassUnit and InterfaceUnitwhich represent classes and interface, respectively, (ii) StorableUnit which illus-trates attributes and (iii) MethodUnit to represent methods, etc. The Action packagerepresents behavior descriptions and control-and-data-flow relationships between code

VEM

110

elements. Refactoring has been known and highly used both industrially and academi-cally. It is a form of transformation that was initially defined by Opdyke [Opdyke 1992]as “a change made to the internal structure of the software while preserving its externalbehavior at the same level of abstraction”. In the area of object-oriented programming,refactorings are the technique of choice for improving the structure of existing code with-out changing its external behavior [Fowler et al. 2000]. Refactorings have been proved tobe useful to improve the quality attributes of source code, and thus, to increase its main-tainability. It is possible to identify several catalogs of refactoring for different languagesand the most complete and influential was published by Fowler in [Fowler et al. 2000].Nowadays, there are researches been carried out about apply refactoring in model insteadof source code[Ulrich and Newcomb 2010]. Nevertheless, although ADM provides theprocess for refactoring legacy systems by means of KDM, there is a lack of an IntegratedDevelopment Environment (IDE) to lead engineers to apply refactorings as such existin others object-oriented languages. In the same direction, Model-Driven Modernization(MDM) is a special kind of model transformation that allows us to improve the structureof the model while preserving its internal quality characteristics. MDM is a considerablynew area of research which still needs to reach the level of maturity attained by sourcecode refactoring [Misbhauddin and Alshayeb 2012].

In order to enable MDM in the context of ADM, refactorings for the KDM meta-model are required. In this context, in a parallel research line of the same group, wedeveloped a catalogue of refactorings for the KDM [Durelli et al. 2014]. We argue thatdevising a refactoring catalogue for KDM makes this catalogue language-independentand standardized. However, the KDM metamodel was not created with the goal of beingthe basis for diagrams, as is the case of UML metamodel. Thereby, in order to make pos-sible to apply fine-grained refactoring in the KDM metamodel, it is necessary to devisea way to view the KDM instance graphically. Furthermore, although there exist tools,which allow the application of refactorings in class diagrams, none of them uses KDM astheir underlying metamodel. As UML is not so complete as KDM in terms of abstractionlevels and its main focus is on representing diagrams, it is not the best metamodel formodernizations, since modifications in lower levels cannot be propagated to higher levels

Hence, the main contribution of this paper is the provision of a plug-in on the topof the Eclipse Platform named Knowledge Discovery Model-Refactoring Environment(KDM-RE). This plug-in can be used to lead engineers to apply refactorings in KDM,which are based on seventeen well known refactorings[Fowler et al. 2000]. The IDE aswell as the adapted catalogue are based on our experience as model-driven engineering.Also, by using this plug-in the modernizer engineer can visualize the Code package asan UML class diagram, allowing engineers to detect model smells in that diagram. Onehypothetical case study was developed in order to exemplify the use of the plug-in. Thispaper is organized as followed: Section 2 provides the background to fully understandour plug-in - Section 3 depicts information upon the plug-in KDM-RE and an case study- in Section 4 there are related works and in Section 5 we conclude the paper with someremarks and future directions.

2. ADM and KDMOMG defined ADM initiative [Perez-Castillo et al. 2009] which advocates carrying outthe reengineering process considering MDA principles. ADM is the concept of modern-

VEM

111

Conceptual

Build

Structure

PlatformEvent

UIData

Core, KDM,

source

Code

Action

Abstraction Layer

Resource Layer

Program Elements

Layer

Infrastructure Layer

Figure 1. Layers, packages, and separation of concerns in KDM (Adaptedfrom [OMG 2012])

izing existing systems with a focus on all aspects of the current systems architecture. Italso provides the ability to transform current architectures to target architectures by usingall principles of MDA [Ulrich and Newcomb 2010].

To perform a system modernization, ADM introduces Knowledge Discoverymeta-model (KDM). KDM is an OMG specification adopted as ISO/IEC 19506 by theInternational Standards Organization for representing information related to existing soft-ware systems. According to [Perez-Castillo et al. 2009] the goal of the KDM is to define ameta-model to represent all the different legacy software artifacts involved in a legacy in-formation system (e.g. source code, user interfaces, databases, etc.). The KDM providesa comprehensive high-level view of the behavior, structure and data of legacy informationsystems by means of a set of meta-models. The main purpose of the KDM specification isnot the representation of models related strictly to the source code nature such as UnifiedModeling Language (UML). While UML can be used to mainly to visualize the system“as-is”, an ADM-based process using KDM starts from the different legacy software ar-tifacts and builds higher-abstraction level models in a bottom-up manner through reverseengineering techniques. As outlined before, the KDM consists of four abstraction layers:(i) Infrastructure Layer, (ii) Program Elements Layer, (iii) Runtime Resource Layer, and(iv) Abstractions Layer. Each layer is further organized into packages, as can be seen inFigure 1. Each package defines a set of meta-model elements whose purpose is to repre-sent a certain independent facet of knowledge related to existing software systems. Weare specially interested in the Program Elements Layer because it defines the Code andAction packages which are widely used by our catalogue. The Code package defines a setof meta-classes that represents the common elements in the source code supported by dif-ferent programming languages. In Table 1 is depicted some of them. This table identifiesKDM meta-classes possessing similar characteristics to the static structure of the sourcecode. Some meta-classes can be direct mapped, such as Class from object-oriented lan-guage, which can be easily mapped to the ClassUnit meta-class from KDM.

3. Refactoring for KDM by means of KDM-REThis sections describes KDM-RE. In Figure 2 we depicted the main window of our plug-in. For explanation purpose, we highlight two main regions, i.e., a©, and b©. It supports 17

VEM

112

Table 1. Meta-classes for Modeling the Static Structure of the Source-codeSource'Code*Element* KDM*Meta'Classes*

Class* ClassUnit*Interface* InterfaceUnit*Method* MethodUnit*Field* StorableUnit*

Local*Variable* Member*Parameter* ParameterUnit*Association* KdmRelationShip*

*

refactorings adapted to KDM. These refactorings are based on some fine-grained refactor-ings proposed by Fowler [Fowler et al. 2000]. All the refactorings are shown in Table 2.We chose the Fowler’s refactorings because they are well known, basic and fine-grainedrefactorings. Please, not that KDM-RE uses MoDisco1 once it provides an extensibleframework to transform an specific source-code to KDM models. In Figure 2 is presented

Table 2. Refactorings Adapted to KDMRename Feature Moving Features Between Objects Organing Data Dealing with Generalization Rename ClassUnit Move MethodUnit Replace data value with Object Push Down MethodUnit

Rename StorableUnit Move StorableUnit Encapsulate StorableUnit Push Down StorableUnit

Rename MethodUnit

Extract ClassUnit Replace Type Code with ClassUnit Pull Up StorableUnit

Inline ClassUnit Replace Type Code with SubClass Pull Up MethodUnit

Replace Type Code with State/Strategy

Extract SubClass Extract SuperClass Collapse Hierarchy

!

Figure 2. Snippets KDM-RE’s Interface

just a snippet of KDM-RE. Starting from the popup menu named “Refactoring KDM”, inthis model browser, see Figure 2 a©, either the software developer or software modernizercan interact with the KDM model and choose which refactoring must be carried out inthe KDM. In the region a© can be seen all 17 refactorings that have been implemented inKDM-RE. For illustration purposes only we drew rectangles to separate the refactorings

1http://www.eclipse.org/MoDisco/

VEM

113

into three groups. The black rectangle represents refactorings that deal with generaliza-tion, the blue rectangle stand for refactorings to organize data and the red one symbolizerefactoring to assist the moving features between objects.

The region b© on Figure 2 shows an UML class diagram. This diagram can beused before to apply some refactorings to assist the modernizer to decide where/when toapply the refactorings. This UML class diagram also can be useful as the modernizer per-forms the refactorings in KDM model. For instance, changes are reproduced on the fly ina class diagram. We claim that the latter use of this diagram is important once it providesan abstract view of the system, hence, the modernizer can visually check the system’schanges after applying a set of refactorings. Furthermore, in the context of modernizationusually the source-code is the only available artifact of a legacy system. Therefore, creat-ing an UML class diagram makes, both the legacy system and the generated software tohave a new type of artifact (i.e., UML class models), improving their documentation.

3.1. Case Study

In this section, we motivate KDM-RE by analyzing one hypothetical case study. Thiscase study is a small part of the university domain. Figure 2 b© (left side) shows a classdiagram used for modeling a small part of the university domain. In an university thereare several Persons, more specifically Professors, their Assistants, and Students. EachPerson has RG, CPF, and address (of type String). Moreover, classes Professor, Assistant,and Student have an attribute name of type String each. The software modernizer or thesoftware developer found out by looking at the UML class diagram (see Figure 2 b© leftside) this redundantly, i.e., equal attributes in sibling classes. Therefore, he/she mustapply the refactoring “Pull Up Field’. Similarly, he/she also found out by looking at theUML class diagram that one class is doing work that should be done by two or more.For example, he/she found that the attributes RG and CPF should be modularized to aclass. Similarly, it is necessary to provide more information about they address, such asnumber, city, country, etc. Therefore, he/she must apply the refactoring “Extract Class”to the attributes “RG”, “CPF” and “rua”. Due space limitation it is depicted just theextraction of the attributes “RG” and “CPF”. The first step is to select the meta-class thathe/she identified as a bad smell, i.e., the meta-class to be extracted into a separate one.This step is illustrated in Figure 3(a).

After selecting the meta-class, a right-click opens the context menu where therefactoring is accessible. After the click, the system displays the “RefactoringWizard”to the engineer, Figure 3(b) depicts the Extract Class Wizard. In this wizard, the nameof the new meta-class can be set. Also a preview of all detected StorableUnits andMethodUnits that can be chosen to put into the new meta-class. Further, the engineercan select if either the new meta-class will be a top level meta-class or a nested meta-class.The engineer also can select if the KDM-RE must create instances of MethodUnits torepresent accessors methods (gets and sets). Finally, the engineer can set the name of theStorableUnit that represent the link between the two meta-classes (the old meta-classand the new one). After all of the required inputs have been made, the engineer can clickon the button “Finish” and the refactoring “Extract Class” is performed by KDM-RE.

As can be seen in Figure 3(c) a new instance of ClassUnit named “Document”was created - two StorableUnit from “Pessoa”, i.e., “rg” and “CPF” were moved

VEM

114

(a) (b)

(c)

Figure 3. Extract Class Wizard

to the new ClassUnit - instances of MethodUnits were also created to representthe gets and sets. In addition, the instance of ClassUnit named “Pessoa” owns a newinstance of StorableUnit that represent the link between both ClassUnits. Duespace limitation the other StorableUnits of ClassUnit named “Pessoa” are notshown in Figure 3(c). After the engineer realize the refactorings, an UML class diagramis created on the fly to mirror graphically all changes performed in the KDM model, seeFigure 2 b© right side.

4. Related Work

Van Gorp et al. [Gorp et al. 2003] proposed a UML profile to express pre and post con-ditions of source code refactorings using Object Constraint Language (OCL) constraints.The proposed profile allows that a CASE tool: (i) verify pre and post conditions for thecomposition of sequences of refactorings; and (ii) use the OCL consulting mechanismto detect bad smells such as crosscutting concerns. Reimann et al. [Reimann et al. 2010]present an approach for EMF model refactoring. They propose the definition of EMF-based refactoring in a generic way. Another approach for EMF model refactoring is pre-sented in [Thorsten Arendt 2013]. They propose EMF Refactor 2, which is a new Eclipseincubation project in the Eclipse Modeling Project consisting of three main components.Besides a code generation module and a refactoring application module, it comes alongwith a suite of predefined EMF model refactorings for UML and Ecore models.

2http://www.eclipse.org/emf-refactor/

VEM

115

5. Concluding RemarksIn this paper is presented the KDM-RE which is a plug-in on the top of the EclipsePlatform to provide support to model-driven refactoring based on ADM and uses theKDM standard. More specifically, this plug-in supports 17 refactorings adapted toKDM. These refactorings are based on some fine-grained refactorings proposed byFowler [Fowler et al. 2000]. As stated in the case study the engineer/modernizer by usingKDM-RE can apply a set refactorings in a KDM. Also, on the fly the engineer can checkall changes realized in this KDM replicated into a class diagram - the engineer can visu-ally verify the system’s changes after applying a set of refactorings. In addition, usuallythe source code is the only available artifact of the legacy software. Therefore, creating anUML class diagram makes, both the legacy software and the generated software to havea new type of artifact (i.e., UML class models), improving their documentation. Also, weclaim that as we have defined all refactoring based on the KDM, they can be easily reusedby others researchers.

It is important to notice that the application of refactorings in UML class diagramsis not a new research as stated before. However, all of the works we found on literatureperform the refactoring directly on the UML metamodel. Although UML is also an ISOstandard, its primary intention is just to represent diagrams and not all the characteristicsof a system. As KDM has been created to represent all artifacts and all characteristicsof a system, refactorings performed on its finer-grained elements can be propagated tohigher level elements. This propitiates a more complete and manageable model-drivenmodernization process because all information is concentrated in just one metamodel.In terms of the the users who uses modernization tools like ours, the difference is notnoticeable; that is, whether the refactorings are performed over UML or KDM. However,there are two main benefits of developing a refactoring catalogue for KDM. The first oneis in terms of reusability. Other modernizer engineers can take advantage of our catalogueto conduct modernizations in their systems. The second benefit is that, unlikely UML, acatalogue for KDM can be extended to higher abstractions levels, such as architecture andconceptual, propitiating a good traceability among these layers.

We believe that KDM-RE makes a contribution to the challenges of SoftwareEngineering which focuses on mechanisms to support the automation of model-drivenrefactoring. Future work involves implementing more refactorings and conducting exper-iments to evaluate all refactorings provided by KDM-RE. Doing so, we hope to address abroader audience with respect to using, maintaining, and evaluating our tools. Currently,KDM-RE generates only class diagrams to assist the modernization engineer to performrefactorings, however, as future work, we intend to: (i) extend this computational sup-port to enable the achievement of other diagrams, e.g., the sequence diagram, (ii) performstructural check of the software after the application of refactorings; and (iii) carry out theassessment tool, as well as refactorings proposed by controlled experiments. A work thatis already underway is to check how other parts of the highest level of KDM are affectedafter the application of certain refactorings. For example, assume that there are two pack-ages P1 and P2. Suppose there is a class in P1, named C1, and within the P2 there is aclass named C2. Assume that C1 owns an attribute A1 of the type C2., i.e., there is anassociation relationship between these classes of different packages. P1 and P2 representarchitectural layers, i.e., P1 = Model and P2 = View. Thus, the relationship that exists isundesirable. When we make a fine-grained refactoring such as moving the attribute A1

VEM

116

of the class C1, it should be reflected to the architectural level, eliminating the existingrelationship between the two architectural layers.

6. AcknowledgementsRafael S. Durelli would like to thank the financial support provided by FAPESP, process

number 2012/05168-4. Bruno Santos and Raphael Honda also would like to thank CNPqfor sponsoring our research.

ReferencesDurelli, R. S., Santibáñez, D. S. M., Delamaro, M. E., and Camargo, V. V. (2014). To-

wards a refactoring catalogue for knowledge discovery metamodel. In IEEE 15th In-ternational Conference on Information Reuse and Integration (IRI).

Fowler, M., Beck, K., Brant, J., Opdyke, W., and Roberts, D. (2000). Refactoring: Im-proving the Design of Existing Code. Addison-Wesley.

Gorp, P. V., Stenten, H., Mens, T., and Demeyer, S. (2003). Towards automating source-consistent uml refactorings. In International Conference on UML - The Unified Mod-eling Language, pages 144–158. Springer.

Misbhauddin, M. and Alshayeb, M. (2012). Model-driven refactoring approaches: Acomparison criteria. In Sofware Engineering and Applied Computing (ACSEAC), 2012African Conference on.

OMG (2012). Object Management Group (OMG) Architecture-Driven Modernisation.Disponível em: http://www.omgwiki.org/admtf/doku.php?id=start. (Acessado 2 deAgosto de 2012).

Opdyke, W. F. (1992). Refactoring Object-Oriented Frameworks. Ph.D. Thesis, Univer-sity of Illinois.

Perez-Castillo, R., de Guzman, I. G.-R., Avila-Garcia, O., and Piattini, M. (2009). On theuse of adm to contextualize data on legacy source code for software modernization.In Proceedings of the 2009 16th Working Conference on Reverse Engineering, WCRE’09, pages 128–132, Washington, DC, USA. IEEE Computer Society.

Reimann, J., Seifert, M., and Abmann, U. (2010). Role-based generic model refactor-ing. In In ACM/IEEE 13th International Conference on Model Driven EngineeringLanguages and Systems (MoDELS 2013). Springer.

Thorsten Arendt, Timo Kehrer, G. T. (2013). Understanding complex changes and im-proving the quality of uml and domain-specific models. In In ACM/IEEE 16th Inter-national Conference on Model Driven Engineering Languages and Systems (MoDELS2013).

Ulrich, W. M. and Newcomb, P. (2010). Information Systems Transformation:Architecture-Driven Modernization Case Studies. Morgan Kaufmann Publishers Inc.,San Francisco, CA, USA.

VEM

117

Uma Análise da História do VEM, WBVS e WMSWM Renato Novais, Thiago S. Mendes, Fernando Teles

Instituto Federal da Bahia (IFBA) – Salvador – Bahia – Brasil {renato,thiagosouto,fernandoteles}@ifba.edu.br

Abstract. The historical analysis of the publications of workshops on Software Visualization, Maintenance, and Evolution is of great importance to understand the evolution of the works that have been published and to have an overview of the research being conducted in these areas. This work presents an analysis and classification of publications in the past editions of the event VEM, WBVS and WMSWM. The method used was a process based on a systematic mapping of the publications in the proceedings of the three events from 2004 to 2013. We analyzed 88 papers from WMSWM, 13 from WBVS, and 7 from VEM. We recorded the history of events in BDBComp, as well as conducted an analysis of the h-index using Google Scholar. In addition, we quantitative classified the papers to have an understanding of the evolution of these events, which may contribute to the decision-making for future research.

Resumo. A análise histórica das publicações dos workshops de Manutenção, Evolução e Visualização de Software é de grande relevância para compreender a evolução dos trabalhos que já foram apresentados e para ter um panorama das pesquisas que estão sendo realizadas nessas áreas. Este trabalho apresenta uma análise das publicações ocorridas nas últimas edições dos eventos VEM, WBVS e WMSWM. O método utilizado foi um processo baseado em um mapeamento sistemático das publicações nos anais dos três eventos de 2004 até 2013. Foram analisados 88 artigos do WMSWM, 13 do WBVS, e 7 do VEM. Foi realizado o registro da história dos eventos na BDBComp, assim como uma análise do h-index a partir do Google Scholar. Além disso, foi feita uma classificação dos trabalhos para ter um entendimento da evolução destes eventos, o que pode contribuir para as tomadas de decisões de pesquisas futuras.

1. Introdução O Workshop de Visualização, Evolução e Manutenção de Software (VEM) está, neste ano de 2014, em sua II edição. Porém, apesar do pouco tempo, este workshop vem sendo construído a partir da junção de dois outros workshops, a saber: Workshop de Manutenção de Software Moderna (WMSWM), com 10 edições, e Workshop Brasileiro de Visualização de Software (WBVS), com duas edições. Esta junção aconteceu a partir de uma ação das comunidades científicas envolvidas com os dois workshops citados, no sentido de fortalecer tal evento. Isto é justificado uma vez que as áreas de atuação do VEM tem uma grande interseção. Isto pode ser evidenciado, por exemplo, no artigo [Novais et. al 2013], que mostra que os principais eventos onde os artigos de visualização de software são publicados têm uma ligação relevante com manutenção e evolução de software.

VEM

118

Neste ano, há um esforço específico para fortalecimento do evento, através do registro da história dos eventos correlatos na Biblioteca Digital Brasileira de Computação1 (BDBComp), bem como na busca do registro de um possível Qualis CAPES2 para o evento, através da análise do h-index a partir do Google Scholar3.

O objetivo do artigo é mostrar o trabalho realizado para cadastro dos artigos na biblioteca BDBComp, apresentar dados quantitativos dos eventos passados e incentivar a participação de novos pesquisadores no evento. O artigo apresenta uma análise histórica desses três eventos. Para essa análise histórica, foram considerados 88 artigos do WMSWM, 13 do WBVS, e 7 do VEM, em suas edições passadas. A taxonomia utilizada para classificar os artigos é apresentada na Seção 4. A taxonomia envolve essencialmente a análise dos metadados do artigo. Com essa classificação, é possível ter um panorama da evolução deste evento, o que pode contribuir para tomada de decisões futuras. Essa ação permitiu também uma análise dos dados do h-index, feito através das referências do próprio evento. Os dados produzidos neste trabalho estão disponíveis no website do estudo4.

Além desta introdução, este artigo está organizado como se segue. A Seção 2 descreve o esforço inicial para a obtenção do Qualis do evento. A Seção 3 descreve o planejamento do estudo, destacando o protocolo utilizado para classificar os artigos. A Seção 4 mostra os resultados coletados a partir da análise dos artigos. Por fim, a Seção 5 conclui o artigo.

2. Esforço inicial para obtenção do Qualis do VEM Como primeiro esforço para fortalecer o VEM, foi decidido abrir uma frente de trabalho para buscar o registro do Qualis CAPES para este evento. Inicialmente, cadastramos todos os artigos dos três eventos na BDBComp (WMSWM5, WBVS6 e VEM7). Foram cadastrados 108 artigos referentes aos três eventos. Além do grande esforço manual associado à realização do cadastro, outro grande desafio dessa atividade foi conseguir os artigos de todas as edições dos eventos. A dificuldade esteve relacionada principalmente aos primeiros anos do WMSWM. Muitos dos sites dos eventos estavam fora do ar e os artigos não estavam disponíveis na Internet. Para obter grande parte dos artigos, foi necessário contactar as pessoas envolvidas com a realização desses eventos ao longo do tempo. A edição do ano 2005 teve uma dificuldade extra para cadastro na BDBComp, uma vez que os artigos foram salvos no formato “.pdf” como imagens. Posteriormente, foi feita uma investigação da quantidade de citações de cada artigo através do Google Scholar. Isto permitiu a identificação do h-index do VEM (considerando a história dos outros eventos). No momento da escrita deste artigo, havia: 1 artigo com 6 citações; 1 com 5 citações; 1 com 4 citações; 8 com 3 citações; 9 com

1 Biblioteca Digital Brasileira - http://www.lbd.dcc.ufmg.br/bdbcomp/ 2 Sistema WebQualis - http://qualis.capes.gov.br/ 3 Google Scholar - http://scholar.google.com 4 Website do estudo - http://www.wiki.ifba.edu.br/vem2014 5 WMSWM - http://www.lbd.dcc.ufmg.br/bdbcomp/servlet/PesquisaEvento?evento=wmswm

6 WBVS - http://www.lbd.dcc.ufmg.br/bdbcomp/servlet/PesquisaEvento?evento=WBVS

7 VEM - http://www.lbd.dcc.ufmg.br/bdbcomp/servlet/Evento?id=691

VEM

119

duas citações; 13 com 1 citação; 75 com nenhuma citação. Isto implica em um h-index igual a 3. Consequentemente, o workshop deveria ter um Qualis B5.

3. Planejamento do estudo Apesar deste estudo não seguir o rigor metodológico de uma revisão ou mapeamento sistemático, ele foi realizado seguindo algumas das boas práticas do protocolo proposto por Kitchenham e Charters (2007). A seguir são mostrados os itens importantes para o planejamento do mesmo. 1) Questão de Pesquisa: Como ocorreu a evolução histórica dos artigos publicados nos eventos WMSWM, WBVS e VEM? 2) Critérios de Inclusão/Exclusão: foram incluídos todos (e apenas) os artigos de todas as edições dos três eventos: WMSWM (2004-2013), WBVS (2011/2012) e VEM (2013). 3) Esquema de Classificação: no intuito de entender como se deu a publicação dos artigos nestes eventos, foram realizados dois tipos de classificações, que culminaram no conjunto de facetas utilizadas no estudo, a saber: i) baseada nos metadados, o que inclui autor, instituição, ano e idioma; e iii) foi feito uma análise das referências de cada artigo, no sentido de identificar quais artigos referenciam artigos dos próprios eventos sendo analisados. 4) Extração de dados: para esta atividade foi utilizado um formulário de extração de dados projetado para reunir a informação desejada com as facetas descritas acima. Pelo menos dois pesquisadores classificaram cada artigo. Quando não houve um acordo sobre alguma classificação, ou na coleta da informação, um terceiro pesquisador analisou as diferenças e decidiu as questões para chegar em um consenso.

4. Resultados Esta seção apresenta os principais resultados das atividades de extração de dados. Cada subseção a seguir foca nas facetas levantadas para este estudo.

4.1. Quantidade de artigos aceitos ao longo dos anos A Figura 1 apresenta a distribuição de artigos por ano e por evento. Em 2009, o WMSWM teve seu número máximo de artigos aceitos em uma única edição do evento: 13. Durante três anos (2011, 2012, 2013) houve a coexistência do WMSWM com um dos outros dois eventos. A soma dos artigos dos dois eventos conjuntos também deu um total de 13 artigos.

VEM

120

Figura 1. Número de artigos por ano.

4.2. Idioma dos Artigos A Figura 2 destaca o número de artigos por ano e por idioma (português - pt, inglês - en). Os anos de maior destaque foram 2004 e 2012 para o WMSWM, e 2011 para o WBVS, todos com 4 artigos em português e 3 em inglês. É possível observar que a quantidade de artigos escritos em inglês ainda é muito baixa. É necessário a realização de ações para incentivar os pesquisadores da comunidade do VEM a escreverem os trabalhos na língua inglesa. Da mesma forma, é importante também convidar pesquisadores de outros países para que submetam seus trabalhos para o VEM, com o objetivo de divulgar e fortalecer o evento em outras regiões do mundo.

Figura 2. Número de artigos por idioma e por ano.

4.3. Regiões de origem dos autores dos artigos A Figura 3 apresenta os artigos por região de origem dos autores. Houve 15 estados brasileiros e 3 países estrangeiros. Note, por exemplo, os quatro estados com maior destaque (SP, RJ, MG, BA) com mais de 20 artigos publicados cada. O artigo dos EUA, foi de um autor com afiliação à IBM Almaden Research Center [Cortés et. al 2007]. Esse artigo foi em conjunto com autores do Ceará e Rio de Janeiro. O artigo [Maña et. al 2009] foi o mais essencialmente estrangeiro, com um autor com afiliação à University of Malaga, na Espanha, e um com afiliação à City University of London, na Inglaterra.

VEM

121

Figura 3. Número de artigos por região.

4.4. Principais instituições Foi feito um levantamento das instituições de afiliações dos autores dos artigos. Há 63 instituições diferentes. A Figura 4 apresenta o número de artigos por instituição (com pelo menos dois artigos). A COPPE/UFRJ aparece na liderança com 18 artigos publicados, seguido imediatamente por USP, com 15 artigos, e UFSCar, com 11 artigos.

Figura 4. Número de artigos por instituição (# artigos >= 2).

4.5. Principais Autores Outro levantamento realizado neste estudo foi relacionado aos autores dos artigos. 240 autores diferentes publicaram nesses anos, considerando os três eventos. Para fazer esse levantamento foi necessário realizar uma limpeza dos dados uma vez que muitos autores usaram grafias diferentes de seus nomes (e.g. Rosângela Penteado apareceu como Rosângela A. D. Penteado, Rosangela Ap. D. Penteado, Rosângela Aparecida Dellosso Penteado, Rosângela Dellosso Penteado, e Rosângela Penteado). A Figura 5 apresenta os 15 autores com maior número de artigos publicados nos eventos. Destaca-se Cláudia Werner com 14 artigos, seguida por Rosângela Penteado com 10 e Manoel Mendonça com 9. Vale destacar também a presença de Marcelo Schots nessa lista, o único não doutor até o momento da escrita deste artigo.

VEM

122

Figura 5. Os 15 autores com maior número de artigos nos eventos.

4.6. Nuvem de palavras dos artigos do VEM

Foi criada uma nuvem de palavras a partir dos textos dos artigos para verificar as palavras com maior destaque nos trabalhos que já foram apresentados. Para isso, foi utilizada uma extração automática dos textos do formato “.pdf”, convertendo-os para um único arquivo o formato “.txt”. Entretanto, houve uma dificuldade de extração dos textos do WMSWM do ano de 2005, cujos arquivos encontravam-se no formato “.pdf” como imagens. Por este motivo, foi realizado um esforço manual de extração dos resumos/abstracts dos artigos a partir do BDBComp. Depois, foram removidas as stopwords, em português e inglês. Foi utilizada a ferramenta Wordle8 para gerar a nuvem de palavras. O resultado é mostrado na Figura 6.

Figura 6. Nuvem de palavras gerada a partir dos abstracts dos artigos.

Esta nuvem pode servir como ponto de partida para se criar uma taxonomia de classificação dos artigos. Poderia, posteriormente, se realizar uma classificação dos artigos e discussão de acordo com os assuntos que são abordadas nos mesmos (ex., técnicas, ferramentas, estudos de caso, visualização, evolução, etc.) indicando numericamente quantos artigos tratam de cada assunto.

8 Wordle - http://www.wordle.net/create

VEM

123

4.7. Uma análise das referências dos eventos Uma das principais motivações deste estudo foi à geração do h-index para o evento. Para isso, foi necessário fazer um levantamento das referências de cada artigo. A Seção 2 discute essa ação através do uso do Google Scholar. Aqui nesta seção, é feita uma análise de como cada artigo referencia outro artigo dentro do próprio evento.

A Figura 7 mostra, para cada ano, a quantidade de referências para artigos do próprio evento. É possível observar a baixa citação feita nesses anos. O ano com maior número é o de 2007, com 5 referências, sendo 3 feitas pelo mesmo artigo [de Souza et. al 2007]. Esses dados traz à tona um dos pontos mais críticos desse evento. Para uma obtenção de um bom h-index, e consequente um bom Qualis, é importante a referência para artigos do evento. Entretanto, isso não está acontecendo como deveria nem pelos artigos publicados nos próprios eventos em questão.

Figura 7. Referências para o próprio evento.

Esse conjunto de referências foi feito a partir de 13 artigos diferentes. Dos quais, apenas 4 deles fazem referências para artigos de outros autores que não do próprio artigo. Tem-se um total de 19 referências para artigos do próprio evento, sendo apenas 7 para outros autores. Ou seja, são 12 referências para artigos dos próprios autores. O evento/ano com maior número de referências foi o WMSWM 2004, onde: o artigo [Souza 2004] teve 3 referências, o [Dias 2004] com 2, [Silva 2004] e [Vasconcelos 2004] tiveram 1 cada. Considerando apenas as citações dentro do próprio evento, há 2 artigos com 2 referências cada. Da mesma forma, tem-se também um h-index igual a 2, e Qualis B5.

5. Conclusão O Workshop de Visualização, Evolução e Manutenção de Software (VEM) tem como objetivo integrar as comunidades das áreas de Visualização, Manutenção e Evolução de Software. Este evento vem sendo construído a partir de dois outros workshops: WMSWM e WBVS.

Neste ano de 2014, esforços continuam sendo empregados no sentido de fortalecer o evento. Houve, por exemplo, o registro da história dos eventos na BDBComp, assim como uma análise do h-index a partir do Google Scholar, para tentar o registro de um possível Qualis CAPES para o evento.

Este artigo reportou esses esforços realizados. Além disso, apresentou uma análise da história dos três eventos em questão, a partir de uma classificação de um total

VEM

124

de 108 artigos. Foi possível observar como se deu as publicações ao longo dos anos, o que pode ser levado em consideração para projetar as ações de fortalecimento para os próximos anos do evento, como por exemplo, melhorar o processo de divulgação do evento e incentivar a participação de novos pesquisadores. Como trabalhos futuros pretende-se: realizar uma análise qualitativa dos artigos e criar estratégias para aumentar a formação de parcerias entre pesquisadores e grupos de pesquisa da área.

Referências Cortés, M.; Fontoura, M.; Lucena; C. (2007), “Integrated Approach for Framework-

Based System Redesign”, In: IV Workshop de Manutenção de Software Moderna (WMSWM), Porto de Galinhas – PE.

de Souza, K. M.; Scalet, D.; Belchior, A. (2007), “Documentação Essencial para Manutenção de Software II”, In: IV Workshop de Manutenção de Software Moderna (WMSWM), Porto de Galinhas, PE.

Dias, M. (2004), “Uma experiência no ensino de manutenção de software”, In: I Workshop de Manutenção de Software Moderna (WMSWM), Brasília, DF.

Ghezzi, C. (2009), “Reflections on 40+ years of software engineering research and beyond an insiders view”, In: 31st International Conference on Software Engineering, (ICSE), pp. 1-58.

Gomes, J.; da Mota Silveira Neto, P. A.; Cruzes, D.; Santana de Almeida, E. (2011), “25 Years of Software Engineering in Brazil: An Analysis of SBES History”, in: Software Engineering (SBES) 25th Brazilian Symposium on, pp. 4-13.

Kitchenham, B.; Charters, S. (2007), “Guidelines for performing Systematic Literature Reviews in Software Engineering (EBSE 2007-2001)”, Technical report, Keele University and Durham University Joint Report.

Maña, A.; Spanoudakis, G.; Harjani, R.; Ruiz, J. F. (2009), “An Infrastructure for Maintenance and Evolution of Security and Dependability in Dynamic Computing Scenarios”, In: VI Workshop de Manutenção de Software Moderna (WMSWM), Ouro Preto, MG.

Novais, R. L.; Torres, A.; Mendes, T. S.; Mendonça, M.; Zazworka, N. (2013), “Software evolution visualization: A systematic mapping study”, Information and Software Technology 55(11), 1860 - 1883.

Silva, M.; Braga, R.; Masiero, P. (2004), “Evolução Orientada a Aspectos de um Framework OO”, In: I Workshop de Manutenção de Software Moderna (WMSWM), Brasília, DF.

Souza, S.; Neves, W.; Anquetil, N.; Oliveira, K. (2004), “Documentação Essencial para Manutenção de Software II”, In: I Workshop de Manutenção de Software Moderna (WMSWM), Brasília, DF.

Vasconcelos, A.; Werner, C. (2004), “Software Architecture Recovery based on Dynamic Analysis”, In: I Workshop de Manutenção de Software Moderna (WMSWM), Brasília, DF.

VEM

125