http://cbsoft.dcc.ufba.br

XVII Sesso de Ferramentas A N A I S

Foto: MaW

Volume 4

ISSN 2178-6097

Sesso de FerramentasXVII Sesso de FerramentasSetembro de 2010 Salvador Bahia Brasil

ANAISCoordenador do Comit de Programa e Editor Uir Kulesza Coordenadores Locais do SBES Christina von Flach Garcia Chavez Cludio Nogueira SantAnna Coordenador Geral do CBSOFT Manoel Gomes de Mendona Neto Realizao LES Laboratrio de Engenharia de Software DCC Departamento de Cincia da Computao UFBA Universidade Federal da Bahia Promoo SBC Sociedade Brasileira de Computao

Sistema de Bibliotecas - UFBA Congresso Brasileiro de Software: Teoria e Prtica (2010 : Salvador, BA).

Anais [do] Congresso Brasileiro de Software : Teoria e Prtica, Salvador, BA, 27 de setembro a 01 de outubro de 2010 / organizao UFBA, LES, DCC ; coordenador geral Manoel Gomes de Mendona Neto. - Salvador : SBC, 2010. 12 v.Inclui 10 eventos satlites. Contedo: v. 4 - Sesso de Ferramentas (17. : 2010 : Salvador, BA).

1.Software - Brasil - Congressos. I. Sesso de Ferramentas (17. : 2010 : Salvador, BA). II. Universidade Federal da Bahia. Instituto de Matemtica. Departamento de Cincia da Computao. III. Laboratrio de Engenharia de Software. IV. Mendona Neto, Manoel Gomes de. V. Sociedade Brasileira de Computao. VI. Ttulo.

CDD - 005

ii

XVII Sesso de Ferramentas

Apresentao da Sesso de Ferramentas do CBSoftA Sesso de Ferramentas um dos eventos satlites do Congresso Brasileiro de Software: Teoria e Prtica (CBSoft 2010), realizado em Salvador, em Setembro de 2010. Ela passa a integrar as j tradicionais sesses de ferramentas do Simpsio Brasileiro de Engenharia de Software (SBES) e do Simpsio Brasileiro de Arquitetura, Componentes e Reutilizao de Software (SBCARS) realizadas ao longo dos ltimos anos. Os comits diretivos de ambos os simpsios, juntamente com a comunidade de engenharia de software brasileira, decidiram integrar tais sesses em uma nica, dedicada a apresentao tcnica e demonstrao de ferramentas e ambientes de suporte engenharia de software. Ela nomeada XVII Sesso de Ferramentas, porque d prosseguimento as 16 sesses de ferramentas realizadas anteriormente no SBES. O comit de programa da Sesso de Ferramentas do CBSoft 2010 foi composto por 37 membros que cobrem as diferentes reas de pesquisa da engenharia de software. Este ano foram recebidas 39 submisses de artigos de diferentes programas de psgraduao do Brasil e 1 submisso proveniente da Colmbia. Cada artigo foi revisto por 3 membros do comit de programa. Um total de 120 excelentes revises foram realizadas, contribuindo imensamente no processo de seleo dos artigos. Como resultado, 16 artigos tcnicos foram selecionados para serem includos nos anais e apresentados na conferncia (taxa de aceitao = 40%). Os artigos abordam diferentes reas da engenharia de software: engenharia de requisitos, anlise e visualizao de cdigo, refatorao e reengenharia, testes de software, linhas de produto de software, processos de software e engenharia de software emprica. O sucesso da Sesso de Ferramentas do CBSoft 2010 apenas possvel por causa da dedicao e entusiasmo de muitas pessoas. Primeiramente, gostaria de agradecer aos autores que submeteram seus trabalhos. Gostaria de agradecer tambm aos membros do comit de programa e revisores externos, pelo excelente trabalho de reviso e participao ativa nas discusses; o professor Gldson Elias (UFPB) por gentilmente compartilhar sua experincia como coordenador da sesso de ferramentas do SBES2009; a organizao do CBSoft, representada por Manoel Gomes Mendona Neto; a organizao local do SBES, representada por Christina von Flach Garcia Chavez e Cludio Nogueira SantAnna; assim como Glauco Carneiro (UFBA) e Paulo Anselmo Silveira (UFPE) pela ajuda na atualizao do site e produo dos anais, respectivamente. Finalmente, gostaria de gentilmente agradecer a Manoel Mendona (UFBA) e Thas Batista (UFRN) pelo convite para coordenao da Sesso de Ferramentas do CBSoft 2010. Esperamos que voc aprecie o programa tcnico da Sesso de Ferramentas do CBSoft.

Salvador, Setembro de 2010 Uir Kulesza Coordenador da Sesso de Ferramentas do CBSoft 2010

iii

Message from the Program Chair CBSoft Tools SessionThe Tools Session is held in Salvador, Bahia, Brazil, on September 2010, as a satellite event of the 1st Brazilian Conference on Software: Theory and Practice (CBSoft 2010). It follows the steps of the successful tools sessions that were part of the Brazilian Symposium on Software Engineering (SBES) and the Brazilian Symposium on Software Components, Architectures and Reuse (SBCARS) over the last years. The steering committee of these symposiums have decided to integrate the tools sessions of both events in an unique track dedicated to the presentation and demonstration of software engineering tools. It is named XVII CBSoft Tools Session because it follows the previous and traditional sixteen SBES Tools Sessions. The program committee of CBSoft Tools Session 2010 was composed of 37 members covering the software engineering main research areas. We received 39 submissions from different graduate programs in Brazil and 1 submission from Colombia this year. Each paper was reviewed by 3 (three) members of the program committee. There were a total of 120 excellent reviews that contributed to the selection process of the papers. As a result, 16 technical papers were selected to be included in this proceedings and presented in the conference (acceptance rate = 40%). The papers encompass a variety of software engineering areas: requirements engineering, code analysis and visualization, refactoring and reengineering, software testing, software product lines, software processes and empirical software engineering. The success of CBSoft Tools Session 2010 was only possible because of the dedication and enthusiasm of many people. First of all, I would like to thank the authors for submitting their papers. I would also like to thank the Program Committee members and external reviewers, for the excellent reviewing work and the active participation on the discussions; professor Gldson Elias (UFPB) for kindly sharing his experience as program chair of the SBES2009 Tools Session; the CBSoft organization, represented by Manoel Gomes de Mendona Neto; the SBES local organization, represented by Christina von Flach Garcia Chavez and Cludio Nogueira SantAnna; the additional support given by Glauco Carneiro (UFBA) and Paulo Anselmo Silveira (UFPE) to update the web site and to help in the production of this proceedings, respectively. Finally, I would like to thank Manoel Mendona (UFBA) and Thais Batista (UFRN) for the invitation to coordinate the Tools Session this year. We hope you enjoy the technical program of the CBSoft Tools Session 2010.

Salvador, September 2010 Uir Kulesza CBSoft Tools Session - Program Chair

iv

XVII Sesso de Ferramentas

Biografia do Chair - Chair BiographyUir Kulesza is an Associate Professor at the Department of Informatics and Applied Mathematics (DIMAp), Federal University of Rio Grande do Norte (UFRN), Brazil. He obtained his PhD in Computer Science at PUC-Rio Brazil (2007), in cooperation with University of Waterloo and Lancaster University. His main research interests include: aspect-oriented development, software product lines, and design/implementation of model-driven generative tools. He has co-authored over 90 referred papers in journals, conferences, and books. He worked as a post-doc researcher member of the AMPLE project (2007-2009) Aspect-Oriented Model-Driven Product Line Engineering (www.ample-project.net) at the New University of Lisbon, Portugal. He is currently a CNPq research fellow level 2.

v

Coordenador do Comit de Programa ChairUir Kulesza, DIMAp/UFRN

Comit de Programa Program CommitteeAdenilso Simao (ICMC-USP) Aline Vasconcelos, (CEFET Campos) Arilo Dias Neto, (UFAM) Carla Lima Reis (UFPA) Cludio Sant`Anna (UFBA) Daltro Nunes (UFRGS) Eduardo Almeida (UFBA) Eduardo Aranha (UFRN) Eduardo Figueiredo (UFMG) Eduardo Piveta (UFSM) Elisa Huzita (UEM) Frank Siqueira (UFSC) Franklin Ramalho (UFCG) Gledson Elias (UFPB) Leila Silva (UFS) Leonardo Murta (UFF) Manoel Mendona (UFBA) Marcelo d'Amorim (UFPE) Marcelo Turine (UFMS) Marcelo de Almeida Maia (UFU) Marcilio Mendona (University of Waterloo) Marcos Chaim (USP) Maria Istela Cagnin (UFMS) Nabor Mendonca (UNIFOR) Nlio Cacho (UFRN) Paulo Pires (UFRN) Pedro Santos Neto (UFPI) Raphael Camargo (Universidade Federal do ABC) Rodrigo Reis (UFPA) Rohit Gheyi (UFCG) Rosana Braga (ICMC-USP) Rosngela Penteado (UFSCar) Sandra Fabbri (UFSCar) Srgio Soares (UFPE) Silvia Vergilio (UFPR) Valter Camargo (UFSCar) Vander Alves (UnB)

vi

XVII Sesso de Ferramentas

Avaliadores Externos Additional ReviewersAdailton Lima (UFPA) Edson Murakami (UESC) Ernani Sales (UFPA) Gabriel Ferreira (UFU) Ismayle Santos (UFPI) Juliana Saraiva (UFPE) Luanna Lopes Lobato (UFPE) Luiz Carlos Ribeiro Junior (UnB) Paulo Queiroz (USP) Thelma Colanzi (UEM)

vii

Comit Organizador Organizing CommitteeCoordenao Local SBES SBES Local Co-ChairsChristina von Flach Garcia Chavez (DCC/IM/UFBA) Cludio Nogueira SantAnna (DCC/IM/UFBA)

Coordenador Geral do CBSOFT CBSOFT General ChairManoel Mendona (DCC/IM/UFBA)

Coordenadora de Organizao do CBSOFT CBSOFT Organizing ChairVaninha Vieira (DCC/IM/UFBA)

Coordenao Local SBES SBES Local Co-ChairsChristina Chavez (DCC/IM/UFBA) Claudio Sant'Anna (DCC/IM/UFBA)

Coordenao Local SBCARS SBCARS Local Co-ChairsEduardo Almeida (DCC/IM/UFBA) Adolfo Almeida Duran (CPD/UFBA)

Coordenao Local SBLP SBLP Local Co-ChairsLais N. Salvador (DCC/IM/UFBA) Rita Suzana P. Maciel (DCC/IM/UFBA)

Time de Organizao Organizing TeamAntonio Terceiro (DMCC/UFBA) Antonio Oliveira (DMCC/UFBA) Bruno Carreiro (DMCC/UFBA) Glauco Carneiro (DMCC/UFBA) Ivan Machado (DMCC/UFBA) Leandro Andrade (CC/UFBA) Paulo Anselmo Silveira (Cin/UFPE) Raphael Oliveira (DMCC/UFBA) Renato Novais (DMCC/UFBA e IFBA) Rodrigo Rocha (DMCC/UFBA) Yguarat Cavalcanti (CIn/UFPE)

Apoio Executivo ExecutionDAGAZ Eventos

viii

XVII Sesso de Ferramentas

ndice Table of ContentsEngenharia de Requisitos / Requirements Engineering Ferramenta de Apoio Engenharia de Requisitos Integrada a um Ambiente Colaborativo de Cdigo Aberto...................................................................................... 1 Giselle Almeida (IFF), Bruno Ramos (IFF), Michelle Neto (IFF), Marianna Reis (IFF) Mara Barcelos (IFF), Aline Vasconcelos(CEFET Campos) FIR-Diagram: Uma Ferramenta para apoiar a Anlise de Impacto de Mudanas baseada em Interesses de Negcio ............................................................................................... 7 Antonio Oliveira Filho (UFBA), Fabrcio de Freitas Cardim (Faculdade Ruy Barbosa) Tiano Oliveira Drea (Faculdade Ruy Barbosa), Christina von Flach Chavez (UFBA) Uma Ferramenta de Apoio Gerncia de Requisitos Integrada a um Ambiente de Desenvolvimento de Software Centrado em Processos ................................................. 13 Murilo Sales (UFPA), Ernani Sales (UFPA), Carla Lima Reis (UFPA), Rodrigo Reis (UFPA) Anlise e Visualizao de Cdigo / Code Analysis and Visualization Analizo: an Extensible Multi-Language Source Code Analysis and Visualization Toolkit ............................................................................................................................ 19 Antonio Terceiro (UFBA), Joenio Costa (UCSAL), Joo Miranda (IME-USP), Paulo Meirelles (IME-USP), Luiz Romrio Rios (UFBA), Lucianna Almeida (USP) Christina Chavez (UFBA), Fabio Kon (USP) An Eclipse-Based Multiple View Environment to Visualize Software Coupling ......... 25 Glauco Carneiro (UFBA), Paulo Roberto Jnior (UFBA) Arleson Nunes (UFBA), Manoel Mendona (UFBA) Hist-Inspect: Uma Ferramenta de Apio Avaliao Sensvel Histria de Cdigo ... 31 Leandra Mara (PUC-Rio), Gustavo Honorato (PUC-Rio), Francisco Neto (PUC-Rio) Alessandro Garcia (PUC-Rio), Carlos Lucena (PUC-Rio) Refatorao e Reengenharia / Refactoring and Reengineering AssistME uma Ferramenta para Auxiliar a Refatorao para Aspectos de Tratamento de Excees .................................................................................................................... 37 Cristiane Queiroz (UPE), Fernando Castor (UFPE), Nlio Cacho (UFRN) ComSCId & DMAsp: Identificao de Interesses Transversais e Recuperao de Modelos de Classes Anotados a partir Aplicaes OO Java .......................................... 43 Paulo Afonso Parreira Jnior (UFSCar), Heitor Costa (UFLA) Valter Camargo (UFSCar), Rosngela Penteado (UFSCar)

ix

Testes de Software / Software Testing FERRARE GT: Automao de Testes de Desempenho e Estresse via Testes Funcionais ........................................................................................................................................ 49 Ismayle Santos (UFPI), Alcemir Santos (UFPI), Pedro Santos Neto (UFPI) ModelT2: Apoio Ferramental Gerao de Casos de Testes Funcionais a partir de Casos de Uso ............................................................................................................................. 55 Priscila Pecchio (COPPE/UFRJ), Jobson Massollar (COPPE/UFRJ) Guilherme Travassos (COPPE/UFRJ) Linhas de Produto de Software / Software Product Lines Fiesta Toolkit: Model-Driven Software Product Lines in Practice ................................ 61 Hugo Arboleda (Universidad Icesi), Andrs Romero (Universidad de Los Andes) Rubby Casallas (Universidad de Los Andes), Jean-Claude Royer (Mines de Nantes, INRIA) TaRGeT: a Model Based Product Line Testing Tool..................................................... 67 Felype Ferreira (UFPE), Las Neves (UFPE) Michelle Silva (UFPE), Paulo Borba (UFPE) CIDE+: Uma Ferramenta para Extrao Semi-automtica de Linhas de Produtos de Software Usando Colorao de Cdigo ......................................................................... 73 Virgilio Borges (PUC Minas), Rgel Garcia (UFMG), Marco Tulio Valente (UFMG) Processos de Software / Software Processes Uma Ferramenta de Apoio Gerncia de Conhecimento Integrada a um Ambiente de Desenvolvimento de Software Centrado em Processos ................................................. 79 Liken Lima (UFPA), Silvia Nunes das Dores (UFPA), Jadielly Oliveira (UFPA) Ernani Sales (UFPA), Gabriela Andrade (UFPA), Carla Lima Reis (UFPA) Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum................................................ 85 Diego Marins (COPPE/UFRJ), Jos Rodrigues (IM/UFRJ) Geraldo Xexeo (COPPE/UFRJ), Jano Souza (IM/UFRJ) Engenharia de Software Experimental / Experimental Software Engineering StArt Uma Ferramenta Computacional de Apoio Reviso Sistemtica ................... 91 Augusto Zamboni (UFScar), Andr Di Thommazo (CEFET-SP) Elis Cristina Hernandes (UFSCar), Sandra Fabbri (UFSCar)

x

Ferramenta de Apoio Engenharia de Requisitos Integrada a um Ambiente Colaborativo de Cdigo AbertoGiselle T. de Almeida, Bruno A. Ramos, Michelle M. F. Neto, Marianna S. Reis, Mara R. dos S. Barcelos, Aline P. V. de Vasconcelos Projeto QUALI-EPT Instituto Federal Fluminense (IFF) Rua Dr. Siqueira, 273 Parque Dom Bosco CEP 28030-130 Campos dos Goytacazes RJ Brasil{galmeida,bazevedo,mneto,mreis,mrbarcelos,apires}@iff.edu.br

Abstract. This paper presents a tool to support Requirements Engineering in an open-source collaborative environment. From its use, it is possible to maintain requirements, business rules, glossary, use cases, and to define traceability between these work products. The main goals are: documents standardization, evaluation of the impact of changes in software development, and productivity increase, since the artifacts are available in a single environment. It is implemented in a collaborative project management environment that supports development in work distributed teams. Resumo. Este artigo apresenta uma ferramenta para apoiar a Engenharia de Requisitos em um ambiente colaborativo de cdigo aberto. O seu uso possibilita a manuteno de requisitos, regras de negcio, glossrio, casos de uso e a definio da rastreabilidade entre estes produtos de trabalho. Os principais objetivos so: a padronizao dos documentos, a avaliao do impacto de mudanas no desenvolvimento de software e o aumento da produtividade, uma vez que os artefatos esto disponveis em um nico ambiente. implementada em um ambiente de gerenciamento de projetos colaborativo que apia o trabalho com equipes distribudas.

1. IntroduoO constante crescimento da demanda por software e sua inegvel importncia dentro das organizaes, aliados ao seu grau de complexidade cada vez maior, apontam para um cenrio onde fundamental o desenvolvimento de produtos de qualidade. Dessa forma, preocupar-se com o processo de desenvolvimento de software e buscar sua melhoria contnua constitui um fator crtico de sucesso. De acordo com Pressman (2007), uma compreenso completa dos requisitos de software fundamental para um bem-sucedido desenvolvimento de software. Dentro desse contexto, a Engenharia de Requisitos (ER) visa buscar tcnicas bem definidas para elicitar, especificar, validar e documentar requisitos. O MPS.Br (2010), objetiva a melhoria de processo do software brasileiro, sendo implementado atravs de sete nveis de maturidade. Cada nvel possui seus processos com objetivos definidos e resultados esperados que, se obtidos, caracterizam o seu cumprimento. Se todos os resultados dos processos de um nvel so atingidos, pode-se

1

dizer que o processo de desenvolvimento de software da organizao atingiu a maturidade deste nvel. O Projeto de Qualidade de Software Aplicada Educao Profissional e Tecnolgica - QUALI-EPT (2010) visa a implantao da qualidade de software nos projetos da Rede Nacional de Pesquisa e Inovao em Tecnologias Digitais RENAPI (2010), segundo as diretrizes do MPS.Br. Para isto, o QUALI-EPT interage e atua junto a cada projeto e vem obtendo xito, principalmente no que diz respeito Gerncia de Requisitos (GR). Os projetos de desenvolvimento de software da Renapi envolvem equipes distribudas em todo o Brasil, gerando a necessidade de um ambiente colaborativo de desenvolvimento. Dessa forma, o QUALI-EPT buscou a integrao da Gerncia de Requisitos, dada a sua importncia, a uma plataforma flexvel, de cdigo aberto e colaborativa de desenvolvimento, para apoiar a implementao deste processo nos projetos da Renapi. A partir de uma anlise de ambientes e ferramentas existentes, foi verificada a dificuldade em manter artefatos da ER, especialmente em um ambiente de desenvolvimento colaborativo, de forma integrada e completa. Diante disto, o QUALIEPT desenvolveu uma ferramenta denominada Fermine com intuito de facilitar a manuteno de produtos como requisitos, casos de uso, atores, regras de negcio e glossrio, alm de permitir a associao entre estes elementos apoiando a definio da rastreabilidade, que um dos resultados esperados no MPS.Br. A ferramenta Fermine foi desenvolvida como extenso do trabalho apresentado em [Souza et. al. 2010]. Trata-se de um plugin do Redmine (2010) que um ambiente web open-source e colaborativo para gerenciamento de projetos, desenvolvida em Ruby on Rails. Os projetos da RENAPI j utilizavam o Redmine para gerncia de tarefas e de projeto, e, portanto, o desenvolvimento de uma ferramenta integrada a este ambiente possibilitaria um ganho de produtividade em funo do trabalho padronizado. A Fermine visa aumentar a produtividade dos desenvolvedores no preenchimento de grande volume de documentos da ER, uma vez que disponibiliza um conjunto de templates eletrnicos. Alm disso, a integrao com o Redmine facilita o trabalho colaborativo, uma vez que o ambiente disponibiliza recursos como wiki e frum por projeto, repositrio de acesso compartilhado (SVN subversion), notificaes por email, dentre outras facilidades. Uma equipe distribuda, ao utilizar a Fermine, pode fazer a manuteno de vrios itens que contemplam a ER como, por exemplo: requisitos (funcionais e no-funcionais), regras de negcio, glossrio, casos de uso etc. Permite tambm relacionar artefatos da ER, definindo rastreabilidade entre casos de uso e requisitos, por exemplo, alm de rastros para regras de negcio, glossrio, etc. O restante do artigo est organizado da seguinte forma: a Seo 2 apresenta a ferramenta de apoio ER e suas funcionalidades; a Seo 3 apresenta os trabalhos relacionados; e a Seo 4 apresenta as concluses e os trabalhos futuros.

2. Fermine: ferramenta de apoio ER integrada ao RedmineConforme mencionado, a ferramenta Fermine foi desenvolvida como um plugin do Redmine pelo fato dos projetos da RENAPI j utilizarem este ambiente. Em se tratando de aplicaes Rails, um plugin possui a mesma arquitetura da aplicao principal, porm caracteriza-se como uma extenso devido a sua dependncia desta. As aplicaes criadas com Rails so desenvolvidas com base no padro de projeto

2

Model-View-Controller MVC. A Figura 1 caracteriza os elementos presentes na arquitetura do plugin Fermine. O Action Mailer e Action WebServices atuam no envio de e-mails e comunicao com servios web, respectivamente. A juno do Action View, responsvel pela renderizao de templates, com o Controller, responsvel pela lgica da aplicao, compe o Action Pack que, por sua vez, o centro do framework Rails. O mapeamento objeto-relacional e a camada de persistncia so providos pelo Active Record. O Dispatcher responsvel pelas requisies ao Controller apropriado e por recarregar a aplicao se houver dependncias que necessitam de carregamento.

Figura 1. Estrutura da ferramenta Fermine integrada ao Redmine (Fonte: adaptada de http://vvn.net/wp/tag/ruby/)

2.1. Principais Funcionalidades da Ferramenta Fermine De modo geral, a ferramenta proposta capaz de realizar a manuteno de artefatos da Engenharia de Requisitos e de permitir a definio de rastreabilidade entre estes elementos. A Fermine disponibiliza um conjunto de templates eletrnicos que permitem o registro e a manuteno de diversos produtos de trabalho da ER, a saber: regras de negcio, requisitos funcionais e no-funcionais, termos do glossrio, casos de uso e atores. Permite, ento, a padronizao dos documentos nos projetos da RENAPI. As atividades de registro e manuteno da especificao dos casos de uso so facilitadas com o uso da ferramenta. Artefatos como atores, regras de negcio e requisitos so associados ao caso de uso atravs de links. Esta forma de associao permite um ganho de produtividade no preenchimento dos documentos, uma vez que o responsvel pela especificao do caso de uso pode consultar e associar rapidamente os artefatos, considerando que estes esto inseridos num nico ambiente. A Figura 2 mostra o registro e a especificao completa de um caso de uso utilizando a ferramenta. Outro aspecto a ser destacado a forma de preenchimento dos fluxos alternativos e das excees. Ao incluir um fluxo alternativo ou uma exceo, a ferramenta j orienta o especificador do caso de uso a selecionar o passo de origem de acordo com o fluxo principal previamente inserido. Alm disso, todos os passos dos fluxos so numerados automaticamente, mantendo-se um padro. Da mesma forma, os casos de uso includos (includes) podem ser facilmente associados. O link para associao de includes permite ao especificador selecionar o passo do fluxo principal que d origem incluso e escolher o caso de uso que ser includo. O mesmo vale para

3

a associao de casos de uso estendidos (extends), acrescentando-se, neste caso, um campo para especificao da condio necessria ocorrncia da extenso. O template do caso de uso tambm traz um recurso para facilitar o entendimento da especificao por usurios ou outros membros do projeto. Na descrio resumida, os termos encontrados glossrio so exibidos como links, permitindo consultar suas definies.

Figura 2. Manuteno e especificao de casos de uso na Fermine

A Figura 3 mostra como feito o registro de requisitos funcionais e nofuncionais na ferramenta. Por ltimo, a ferramenta permite definir a rastreabilidade entre os artefatos da ER que mantm. O registro da rastreabilidade importante porque fornece informaes teis para avaliao dos impactos que mudanas nos requisitos podem ocasionar, alm de possibilitar a identificao de inconsistncias entre os requisitos e demais artefatos. A Figura 4 ilustra a rastreabilidade na ferramenta.

4

Figura 3. Manuteno de requisitos na Fermine

Figura 4. Rastreabilidade entre casos de uso e demais artefatos na Fermine

A ferramenta est acessvel em http://redmine.iff.edu.br:8000/, onde tambm possvel experiment-la por meio da seguinte sequncia de passos: clique em Projeto Teste Artigo SBES, clique na aba Fermine, login com username SBES e password sbes.

3. Trabalhos RelacionadosDentre as ferramentas pesquisadas neste trabalho, destacam-se o Enterprise Architect e o Jude Professional. O Enterprise Architect (2010) uma ferramenta de modelagem proprietria da Sparx System que permite a criao de diversos diagramas da UML, a manuteno de requisitos e regras de negcio. Alm disso, gera a rastreabilidade entre os requisitos e demais artefatos. Contudo, no possibilita a especificao de casos de uso atravs de um template e pago. O Jude Professional (2010) uma ferramenta de modelagem bastante utilizada, embora no seja uma soluo gratuita. Nela, possvel a criao de diversos diagramas da UML, bem como a especificao de casos de uso. Porm, no faz a gerao da rastreabilidade entre requisitos, casos de uso e demais produtos de trabalho. A Tabela 1 mostra uma comparao entre as ferramentas.

5

Tabela 1. Comparao entre ferramentas

Ferramentas Enterprise Jude Architect Professional Soluo Livre No No Apoio Definio de Rastreabilidade Sim No Gerao da Matriz de Rastreabilidade Sim No Especificao de Caso de Uso No Sim Suporte ao Desenvolvimento Colaborativo Sim No Modelagem Sim Sim Critrios

Fermine Sim Sim No Sim Sim No

4. Concluses e Trabalhos FuturosEste artigo apresentou uma ferramenta de apoio ER integrada a um ambiente colaborativo de cdigo aberto. O uso da ferramenta promove a padronizao de documentos, trabalho colaborativo, reduo do tempo gasto na documentao requerida pela ER e, flexibilidade na personalizao (soluo de cdigo aberto). Alm disso, tmse como contribuies: a manuteno e integrao dos diversos artefatos da ER; descrio e especificao completa de casos de uso; definio de rastreabilidade entre eles; apoio ao trabalho colaborativo. A Fermine est em fase de testes e, em breve, ser utilizada pelos projetos da RENAPI. Como trabalhos futuros, encontram-se: gerao da matriz de rastreabilidade em HTML e PDF; associao dos casos de uso com artefatos de modelo como classes por meio da leitura de arquivos XMI; integrao da GR com a Gerncia de Projetos, uma vez que o Redmine suporta cadastro de tarefas e cronograma de trabalho; disponibilizao no portal de software pblico brasileiro.

5. RefernciasPressman, Roger S. (2007), Engenharia de Software, Makron Books, 6 edio. So Paulo. Souza, Daline G. M. de; Siqueira, Karolyne A.; Freitas, Rafael L. de. Integrao da Gerncia de Requisitos com a Plataforma Redmine, projeto final do IFF defendido em janeiro de 2010. MPS.Br Melhoria de Processo do Software Brasileiro, http://www.softex.br/mpsbr/_home/default.asp, acessado em 01/06/2010. QUALI-EPT - Projeto de Qualidade de Software Aplicada Educao Profissional e Tecnolgica, http://www.renapi.org/qualidade/conheca-o-projeto/apresentacao, acessado em 01/06/2010. RENAPI - Portal da Rede Nacional de Pesquisa e Inovao em Tecnologias Digitais, http://www.renapi.org, acessado em 01/06/2010. Redmine, http://www.redmine.org, acessado em 01/06/2010. Enterprise Architect, 01/06/2010. http://www.sparxsystems.com/products/ea/, acessado em

Jude Professional Design & Modeling, http://jude.change-vision.com/judeweb/product/professional.html, acessado em 01/06/2010.

6

FIR-Diagram: Uma Ferramenta para apoiar a An lise de a Impacto de Mudancas baseada em Interesses de Neg cio oAnt nio Oliveira Filho1 , Fabrcio de Freitas Cardim2 , o 2 Tiano Oliveira D rea , Christina von Flach G. Chavez1 o1

Universidade Federal da Bahia (UFBA) - Salvador, BA, Brasil2

Faculdade Ruy Barbosa (FRB) - Salvador, BA, Brasil

(aoliveiraf, ffcardim, tianodorea)@gmail.com, flach@ufba.br

Abstract. Change impact analysis supports the identication of potential consequences of a change. However, the techniques and tools used for impact analysis are dependent on existing software and business requirements that express the business rules of the organization. In this paper, we present the FIR-Diagram, a tool to support impact analysis based on business concerns, which arise from changes in business rules, independently of the existence of software artifacts that implement them.

1. Introducao Atualmente, software e neg cio caminham juntos. Organizacoes est o inseridas em o a cen rios sujeitos a mudancas constantes em seus neg cios, nos quais os sistemas de softa o ware e as informacoes produzidas por eles t m import ncia crescente. Mudancas podem e a afetar regras de neg cio (externas ao software) declaracoes utilizadas para restringir o ou denir algum aspecto do neg cio [Group 2010] , podem ou n o se manifestar em reo a quisitos de neg cio [Leite and Leonardi 1998] (no caso de existir software associado) e o s o potencialmente fontes de uma s rie de mudancas em regras e requisitos de neg cio a e o relacionados bem como em artefatos utilizados ao longo do ciclo de vida do software em quest o. A an lise de impacto de mudancas e a identicacao das potenciais cona a sequ ncias de uma mudanca, ou a estimativa do que precisa ser modicado para realizar e uma mudanca [Arnold 1996]. Em teoria, a an lise de impacto precisa identicar todas as a regras e requisitos de neg cio afetados pela solicitacao de mudanca, por m, na pr tica, o e a as t cnicas e ferramentas atuais [Raja and Kamran 2008] dependem da exist ncia de softe e ware que implemente as regras de neg cio da organizacao. N o foram identicadas fero a ramentas que d em suporte ao relacionamento entre regras de neg cio, com ou sem a e o presenca de software que as implemente. O modelo FIR (Funcionalidade-Informacao-Regra) e um modelo de ras treabilidade que ap ia a an lise de impacto baseada em interesses de neg cio o a o [Oliveira Filho 2010, Oliveira Filho et al. 2008] , ou seja, a an lise de impacto que pode a ser realizada a partir de mudancas solicitadas sobre regras de neg cio. Interesses de o neg cio s o denidos como agrupamentos de regras de neg cio que compartilham os o a o mesmos prop sitos, de modo que, quando uma mudanca e solicitada para uma regra o de neg cio de um determinado agrupamento, isso signica que existem interessados da o

7

organizacao em descobrir os impactos relacionados a essa mudanca que se manifestam em outro(s) agrupamento(s). Prop sitos podem ser vistos como elos que relacionam reo gras de neg cio de interesses de neg cio distintos entre si atrav s do compartilhamento o o e de informacoes [Oliveira Filho 2010]. Neste artigo, apresentamos a ferramenta FIR-Diagram, desenvolvida como ` prova de conceito para dar suporte ao modelo de rastreabilidade FIR e a descoberta de impactos a partir de modelos FIR. A Secao 2 apresenta uma vis o geral dos requisitos a e caractersticas da ferramenta, a Secao 3 descreve suas principais funcionalidades e as ilustra por meio de um exemplo simples e a Secao 4 apresenta as consideracoes nais.

2. Vis o Geral aS o requisitos de FIR-Diagram: a Q1 : A ferramenta deve permitir a criacao de inst ncias de FIR em modo gr co; a a Q2 : A ferramenta deve permitir a validacao de inst ncias de elementos a partir das a restricoes denidas para FIR; Q3 : A ferramenta deve permitir a realizacao da atividade de descoberta de impactos sobre uma inst ncia de FIR; a Q4 : A ferramenta deve permitir que inst ncias de FIR possam estar disponveis para a integracao com outras ferramentas; Q5 : A tecnologia utilizada no desenvolvimento da ferramenta deve ser relevante tanto na ind stria quanto na academia, de modo a motivar futuros interessados na evolucao u da ferramenta. A ferramenta foi implementada como um plugin para o ambiente Eclipse1 . A grande popularidade e relev ncia desse ambiente, tanto na ind stria quanto na acadea u mia, satisfaz o requisito Q5 . Utilizamos o Graphical Modeling Framework (GMF), um framework que ap ia o desenvolvimento de editores gr cos e atende os requisitos Q1 , o a Q4 e Q5 . O GMF integra outros dois frameworks, o Eclipse Modeling Framework (EMF) e o Graphical Editing Framework (GEF). O EMF e uma implementacao do MOF ` (Meta Object Facility) que predisp e os modelos criados a integracao e respons vel pelas o a transformacoes entre modelos criados em UML ou em linguagem de programacao Java. O GEF permite criar um rico editor gr co a partir de modelos construdos atrav s do a e EMF. O GMF suporta a inclus o de restricoes (constraints) durante a denicao do modelo a e, portanto, atende o requisito Q2 . No FIR-Diagram, as restricoes foram implementa das usando duas das linguagens suportadas pelo GMF: Java e OCL.

3. Funcionalidades de FIR-DiagramNesta Secao apresentamos as principais funcionalidades de FIR-Diagram, incluindo Criacao de Inst ncias de FIR (Secao 3.1), Aplicacao das Restricoes de FIR (Secao 3.2) a e Descoberta de Impactos (Secao 3.3). O exemplo a seguir e utilizado para ilustrar cada uma das secoes. Venda e emiss o de ingressos. Empresas respons veis pela venda de ingressos utilizam a a um software que tem como funcionalidade a emisso de ingressos, dentre outras. a1

www.eclipse.org

8

Em um ingresso v lido, devem constar as informacoes data e nome do evento, para a confer ncia durante o acesso ao est dio. Recentemente, uma mudanca na lei obrigou e a que no ingresso constasse o CPF do torcedor, al m das informacoes j citadas. A partir e a do pr ximo campeonato, para ter acesso ao est dio, o torcedor deve carregar consigo o a um documento onde conste o CPF para confer ncia. Para tanto, cada torcedor deve e ser cadastrado atrav s de um servico web que estar disponvel para todas as empresas e a de venda de ingressos. 3.1. Criacao de inst ncias de FIR a O plugin FIR-Diagram permite que inst ncias de tipo de regras de neg cio descritas a o pelo FIR [Oliveira Filho 2010] sejam criadas e relacionadas entre si. Por exemplo, as seguintes inst ncias de regras de neg cio de venda e emiss o de ingressos podem ser a o a criadas, onde Fi , Rk e Ij , com i, k e j inteiros positivos, s o utilizados para facilitar a a identicacao dos tipos de regras de neg cio suportadas pelo FIR, e indicam os tipos o Funcionalidade, Regra e Informaco, respectivamente: a Regra de neg cio do tipo Funcionalidade o F1 : Cadastrar Torcedor; F2 : Emitir Ingresso; F3 : Liberar Acesso; Regra de neg cio do tipo Regra o R1 : Se o CPF informado for v lido, ent o o Torcedor-CPF e igual ao a a CPF informado; R2 : Se Nome do Evento informado for v lido, ent o o a a Ingresso-Nome-do-Evento e igual ao Nome do Evento informado; R3 : Se a Data do Evento informada for v lida, ent o o a a ` Ingresso-Data-do-Evento e igual a Data do Evento informada; R4 : Se Torcedor-CPF for v lido, a ent o a o Ingresso-Torcedor-CPF e igual a Torcedor-CPF informado; R5 : O Ingresso-CPF deve ser igual ao CPF-do-Torcedor para que o acesso seja liberado; R6 : O Ingresso-Nome-do-Evento deve ser igual ao nome do evento para que o acesso seja liberado; R7 : O Ingresso-Data-do-Evento deve ser igual a Data do Evento para que o acesso seja liberado; Regras de neg cio do tipo Informaco o a I1 : Torcedor-CPF; I2 : Ingresso-Nome-do-Evento; I3 : Ingresso-Data-do-Evento; I4 : Ingresso-CPF; A Figura 1 e uma representacao gr ca do exemplo de venda e emiss o a a de ingressos construda com o FIR-Diagram. Os elementos Funcionalidade, Informaco e Regra s o representados atrav s de crculos coloridos de acordo com a a e cada tipo. Os elos de depend ncia entre esses elementos s o representados por ligacoes e a entre os crculos. As ligacoes direcionadas representam os conceitos de produco, a quando a origem est em uma regra e o destino est em uma informacao, e consumo, a a

9

Figura 1. Diagrama de instancias do FIR

quando ocorre o oposto. A ligacao n o direcionada representa o conceito de execuco, a a onde uma ou mais regras s o executadas por uma funcionalidade. Na Figura 1, a regra a R3 produz a informacao I3 quando a funcionalidade F2 e executada, e essa informacao ser consumida pela regra R7 quando a funcionalidade F3 for executada. As regras de a neg cio no FIR podem ser separadas em dois grupos: as que fazem parte do software o (representam requisitos de neg cio) e as que est o fora do software. Os requisitos de o a neg cio s o identicados em tons de verde, que v o do verde mais escuro (inst ncias do o a a a tipo Funcionaldiade) para o verde mais claro (inst ncias do tipo Informaco). a a As regras de neg cio que est o fora do software s o identicadas em tons de cinza, que o a a v o do cinza mais escuro (inst ncias do tipo Funcionaldiade) ao cinza mais claro a a (inst ncias do tipo Informaco). a a 3.2. Aplicacao das Restricoes de FIR No FIR-Diagram, a validacao do diagrama est disponvel a partir de um item de menu a validate de Diagram, adicionado ao Eclipse quando o plugin FIR-Diagram e instalado. Durante a validacao, se algum elemento do modelo est violando umas das a restricoes, ele e marcado com o xdestacado em vermelho, indicando um erro no dia grama. A lista de erros encontrados na validacao e exibida na aba Problems do Eclipse (Figura 2 (d)). A Figura 2 (a) apresenta uma restricao imposta ao modelo. De acordo com o exemplo proposto, a regra R1 e executada pela funcionalidade F1, logo, deveriam estar associadas. Isso implica em dizer que: a funcionalidade de cadastrar torcedor s poder ser executada se existir um CPF v lido. Ap s a execucao da regra R1, uma o a a o informacao deve ser produzida (Torcedor-CPF). Na Figura 2 (b), esse elo de producao foi retirado propositalmente para a demonstracao de outra restricao: um informacao sem pre e proveniente de uma regra (Producao). As regras R5 ,R6 e R7 n o fazem parte do a

10

(a) Funcionalidade inv lida a

(b) Regra inv lida a

(c) Informacao inv lida a

(d) Aba Problems

Figura 2. Validacoes do FIR-Diagram

software de emiss o de ingressos, mas precisam ser representadas no diagrama pois s o a a regras do neg cio. Elas s o representadas com uma coloracao diferente das regras que o a fazem parte do software. Para ter acesso ao jogo, o CPF que consta no documento de identicacao do torcedor deve ser igual ao CPF impresso no ingresso (I4 ). Essa regra (R5 ) n o est implementada no software e consome a informacao (I4 ) produzida dentro a a do software. Para violar essa restricao, retiramos a relacao de consumo, como ilustra a Figura 2 (c). Se nenhuma das restricoes for violada, pode-se armar que o diagrama com a inst ncias do FIR e v lido (Figura 1). a 3.3. Descoberta de Impactos Para a descoberta de impactos foram considerados os elos de depend ncia entre os elee mentos do modelo. O algoritmo determina as regras que ser o impactadas para mudancas a que ocorrem em regras do modelo. A descoberta de impactos e realizada em termos de operacoes sobre um grafo que o diagrama representa. O algoritmo de descoberta de impactos e executado quando uma regra e selecionada no modelo. Atrav s da informacao produzida pela regra selecionada, o algoritmo e percorre a lista das regras que dependem da informacao produzida e adiciona a regra dependente na lista de impactos da regra selecionada. O algoritmo e executado recursivamente para cada regra dependente. Ao nal, as regras impactadas s o exibidas com um a crculo vermelho. A Figura 3 mostra a descoberta de impactos para a regra R1 . A regra R1 produz uma informacao (Torcedor-CPF) que e consumida pela regra R4 , que, por sua vez, produz uma informacao (Ingresso-CPF) que e consumida pela regra R5 . Caso uma mudanca ocorra na regra R1 , a informacao produzida poder ser alterada e as regras R4 e a R5 devem ser manualmente avaliadas com o objetivo de descobrir impactos.

11

Figura 3. Impactos de Mudanca na regra R1

4. Conclus o aEste artigo apresentou uma ferramenta baseada no modelo de rastreabilidade FIR (Funcionalidade-Informacao-Regra) para an lise de impacto de mudancas baseada em a interesses de neg cio. A ferramenta FIR-Diagram permite manipular inst ncias dos o a tipos de regras de neg cio suportados pelo modelo FIR ao implementar dois requisitoso chave: os conceitos e as denicoes do FIR, como, por exemplo, Q2 : A ferramenta deve permitir a validacao de inst ncias de elementos a partir das restricoes denidas para FIR a e Q3 : A ferramenta deve permitir a realizacao da atividade de descoberta de impactos sobre uma inst ncia de FIR. a A ferramenta e compatvel com a distribuicao Eclipse Modeling Tools e o c digo fonte do projeto est disponvel a partir do endereco o a https://rplugin.googlecode.com/svn/trunk/, sob a licenca Eclipse Public License 1.0. Como trabalhos futuros, destacamos: (1) Controle de Granularidade: O modelo FIR apresenta uma granularidade muito na das regras de neg cio e a ferramenta o FIR-Diagram pode implementar alguma estrat gia para que o usu rio tenha controle e a sobre essa granularidade, e (2) Rastreabilidade Horizontal: O modelo FIR deve ser aprimorado para suportar uma rastreabilidade horizontal com o c digo fonte e a ferramenta o FIR-Diagram tamb m deve ser estendida para este m. e

Refer ncias eArnold, R. S. (1996). Software Change Impact Analysis. IEEE Computer Society Press. Group, B. R. (2010). Denition of business rules - http://www.businessrulesgroup.org. Leite, J. and Leonardi, M. C. (1998). Business rules as organizational policies. In IWSSD98: Proc. 9th Intl Workshop on Software Specication and Design, page 68, Washington, DC, USA. IEEE Computer Society. Oliveira Filho, A. (2010). Uma t cnica de rastreabilidade para an lise de impacto de mudancas em e a interesses de neg cio. Masters thesis, Universidade Salvador (UNIFACS). o Oliveira Filho, A., de Mendonca Neto, M. G., and von Flach G. Chavez, C. (2008). Em busca de agilidade na an lise de impacto: O artefato r. Latin America Transactions, IEEE, 6(3):275281. a Raja, U. A. and Kamran, K. (2008). Framework for requirements traceability - tlfrt supporting pre-rs & post-rs traceability. Masters thesis, Blekinge Institute of Technology, School of Engineering.

12

Uma Ferramenta de Apoio Gerncia de Requisitos Integrada a um Ambiente de Desenvolvimento de Software Centrado em ProcessosMurilo F. Sales, Ernani de O. Sales, Carla A. Lima Reis, Rodrigo Q. Reis Laboratrio de Engenharia de Software (LABES) Universidade Federal do Par (UFPA) Belm PA Brasil{murilo,ernani}@webapsee.com, {clima,quites}@ufpa.br

Abstract. This paper presents a tool named WebAPSEE Requirement Management (WARM), which implements features related to Requirement Registration, Maintenance, Traceability and Change Control. This tool is part of the WebAPSEE environment and this enables the automatic generation of traces between requirements and the software process components managed by this environment, like activities and work products. Furthermore, it supports the requirements baselines management through requirements versioning and approved requirements configurations.

1. IntroduoRequisitos constituem a base para o desenvolvimento de software bem como para a sua validao e aceitao junto ao cliente. Contudo, apesar de inmeros trabalhos desenvolvidos na rea de Engenharia de Requisitos, a instabilidade dos requisitos durante, e at mesmo aps, o processo de desenvolvimento constante [Pressman 2005]. Tais mudanas geram custos adicionais e mudanas no planejamento que devem ser gerenciadas e controladas. Nesse sentido, Sommerville (2006) define uma diviso da Engenharia de Requisitos em quatro fases: (1) Levantamento dos Requisitos, cujo objetivo determinar o que o sistema deve fazer; (2) Especificao de Requisitos, em que elaborada a documentao dos requisitos coletados na fase anterior, gerando como produto de trabalho o Documento de Requisitos; (3) Validao dos Requisitos, cujo objetivo eliminar possveis inconsistncias, falhas ou ambigidades no documento de requisitos e torn-lo completo; e (4) Gerncia de Requisitos, que o processo de compreender e controlar as mudanas nos requisitos, desenvolvido por todo o ciclo de vida do processo de desenvolvimento de software. Para apoiar o processo de mudana de requisitos, fundamental definir e manter sua rastreabilidade. Rastreabilidade o grau em que o relacionamento pode ser estabelecido entre dois ou mais produtos de desenvolvimento de software, especialmente produtos que tenham uma relao de predecessor sucessor ou de mestre subordinado com outro [IEEE 1990]. Dessa forma, a rastreabilidade essencial para a realizao da anlise de impacto de mudana de requisitos. Um exemplo disso seria utilizar os rastros de um requisito para identificar de que forma uma mudana impacta nos planos do projeto que contm as estimativas aprovadas de esforo e custo para os produtos de trabalho e tarefas, bem como os cdigos de unidade ou mdulos do software que necessitam ser modificados.

13

Entretanto, apesar de ser imprescindvel o apoio de ferramentas especficas dentro do processo de desenvolvimento de software nas atividades de Gerncia de Requisitos, as ferramentas atuais normalmente tratam os requisitos de forma isolada das demais informaes inerentes ao contexto do processo de software [Jacobs 2007] ou fornecem apenas parte do apoio necessrio para o gerenciamento dos requisitos. Alm disso, o uso do ambiente WebAPSEE em iniciativas de melhoria de processo de software vm ressaltando a necessidade de associar uma ferramenta de apoio Gerncia de Requisitos integrada a definio dos processos dentro do ambiente [Sales et al. 2009]. Dessa forma, este trabalho apresenta a ferramenta WebAPSEE Requirement Manager (WARM), que contempla funcionalidades de cadastro, manuteno e controle de mudana de requisitos e integrada ao ambiente WebAPSEE [Lima Reis e Reis 2007], permitindo, de maneira facilitada, a associao de requisitos e componentes presentes nos modelos de processo de software, tais como: atividades, artefatos (documentos) produzidos/consumidos e pessoas envolvidas. O texto est organizado como segue. Na seo 2, a ferramenta WebAPSEE Requirement Manager descrita em termos de funcionalidades e arquitetura implementada. Na seo 3, um exemplo de utilizao da ferramenta apresentado. Na seo 4, uma comparao com trabalhos relacionados feita. Por fim, na seo 5 so discorridas as consideraes finais do trabalho.

2. WebAPSEE Requirement ManagerA WARM, como citado anteriormente, uma ferramenta integrada ao ambiente WebAPSEE, o qual possui como um dos objetivos principais permitir a definio e execuo de processos de software de maneira flexvel, alm de manter um conjunto de informaes organizacionais. O ambiente WebAPSEE implementa uma arquitetura cliente/servidor, que contm trs clientes: (a) Manager Console, direcionado aos gerentes, que permite a definio, planejamento e acompanhamento da execuo de processos de software, alm do gerenciamento dos dados organizacionais, coleta de mtricas, gerao de relatrios, etc.; (b) Task Agenda Desktop, que prov aos agentes alocados em um processo todas as informaes necessrias para execuo da suas atividades (prazos, artefatos de entrada, artefatos de sada, pessoas envolvidas, estimativa de horas, etc.), alm de permitir o feedback desses agentes sobre o andamento de suas tarefas a partir da interao (aes de iniciar, pausar, delegar, finalizar) com a mquina de execuo do ambiente; e (c) Task Agenda Web, similar a Task Agenda Desktop, entretanto desenvolvida utilizando tecnologias e conceitos voltadas para a web 2.0. A WARM integrada ao Manager Console e ao componente servidor do ambiente WebAPSEE. A seguir so apresentadas as principais funcionalidades da WARM e uma viso geral da arquitetura implementada. 2.2. Funcionalidades Do ponto de vista do usurio, as principais funcionalidades fornecidas pela ferramenta WARM so: Gerenciar Requisitos: criao, recuperao, edio e remoo de requisitos; Gerenciar Casos de Uso: criao, recuperao, edio e remoo de casos

14

de uso; Gerenciar Rastreabilidade de Requisitos: criao, edio e remoo de elos de rastreabilidade horizontal (rastros entre requisitos) e de rastreabilidade vertical (rastros entre requisitos e casos de uso, requisitos e artefatos, requisitos e atividades, e requisitos e agentes); Gerenciar Mudanas de Requisitos: registro de mudana de um requisito e versionamento de requisitos; Gerenciar Baselines de Requisitos: criao de baseline de requisitos e controle de verses sobre baselines; Visualizar rvore de Impacto: visualizao da rvore de impacto de um requisito (contemplando todos os seus rastros existentes); Visualizar Matriz de Rastreabilidade: visualizao de matriz de rastreabilidade (sendo uma para cada par de componentes relacionados) e Emitir Relatrios: gerao de uma Lista de Requisitos com os requisitos associados com um determinado sistema dentro do ambiente e gerao de um Relatrio de Impacto de Mudana para um dado requisito. 2.5. Arquitetura Uma viso geral da arquitetura da ferramenta WARM mostrada na Figura 1. Esse projeto arquitetural foi desenvolvido visando a integrao com o ambiente WebAPSEE do ponto de vista de trs aspectos principais: dados, controle e apresentao.cmp Diagrama de Componentes

WebAPSEE Serv er WebAPSEE Manager Console interface Inteface WARM WARM Serv er WARM Client Protocolo RMI Porta RMI

Figura 1 - Arquitetura da Ferramenta WARM

A integrao dos dados (componente WARM Server) foi tratada a partir da reutilizao de parte do modelo de dados pr-existente no ambiente WebAPSEE, o qual foi modificado para incorporar novas entidades e relacionamentos inerentes a ferramenta, tais como: Requisitos, Mudana, Rastros, etc. A integrao de controle (Interface WARM) foi implementado atravs da criao de um interface de servios RMI especfica para a ferramenta, que permite a interao com outros componentes internos, tais como: o de Modelagem de Processos, que gerencia o acesso as entidades que compem um processo dentro do ambiente. A integrao de apresentao (Componente WARM Client), por sua vez, foi realizada a partir do uso da mesma tecnologia de desenho para interface grfica utilizada pelo WebAPSEE, o pacote Swing e suas extenses da linguagem Java, alm da reutilizao dos padres de interface prexistentes no ambiente, como o layout de apresentao dos formulrios de cadastro e de gerao de relatrios. Por fim, vale ressaltar que todos os componentes da ferramenta WARM esto contidos internamente em componentes maiores do ambiente WebAPSEE (Componente WebAPSEE Manager Console e Componente WebAPSEE Server).

3. Exemplo de UtilizaoNesta seo apresentado um exemplo de utilizao da ferramenta para mostrar a aplicabilidade da mesma em termos prticos. Para tanto a ferramenta foi utilizada em

15

um projeto real de desenvolvimento de software em execuo no Laboratrio de Engenharia de Software (LABES) da UFPA. A partir do modelo de processo de software descrito no ambiente WebAPSEE e dos produtos de trabalho inerentes ao projeto em questo, foi possvel extrair os seguintes dados para utilizao no apoio gerncia de requisitos: requisitos, casos de uso, artefatos, atividades e colaboradores. Os requisitos e casos de uso descritos no documento de Especificao de Requisitos do projeto SIGAP [Lemos et al. 2009] foram cadastrados na ferramenta e as demais informaes foram obtidas a partir do ambiente WebAPSEE, onde o processo foi modelado e executado. Para efeito de exemplo ser apresentada apenas a visualizao da rastreabilidade de dois requisitos funcionais: RF 01, Autenticao de Usurio; RF 02, Acesso a Usurio No Cadastrado.

A

B

C

Figura 2 - Rastreabilidade Vertical (requisito x artefato, requisito x atividade e requisito x agente)

Na Figura 2-A so mostrados os elos criados entre os dois requisitos selecionados com o artefato SIGAP COLETA - Especificao de Requisitos. Aps a criao manual desses elos, a ferramenta gera automaticamente os elos de rastreabilidade entre requisitos e atividades (somente para aquelas que tm o artefato SIGAP COLETA - Especificao de Requisitos como artefato de entrada, portanto, sendo impactada pelos requisitos) (Figura 2-B). E tambm so criados automaticamente os elos entre requisitos e agentes (aqueles envolvidos nas atividades que so impactadas pelos requisitos em questo) (Figura 2-C).

4. Trabalhos RelacionadosNesta seo ser apresentada uma tabela comparativa entre a ferramenta WARM e outras ferramentas de propsito semelhante. O objetivo desta comparao mostrar o atendimento ao espectro de funcionalidades relativas Gerncia de Requisitos por essas ferramentas. As ferramentas selecionadas para compor o quadro comparativo foram: o Rational RequisitePro [Rational 2010], ferramenta comercial da IBM; o ReqManager [Taba 2010], mdulo de gesto de requisitos da Estao Taba; e o CaliberRM [Borland 2010], ferramenta comercial da Borland.

16

A Tabela 1 apresenta uma comparao entre as ferramentas que apiam o processo de gerncia de requisitos, com base em um conjunto de funcionalidades teis para a realizao desse processo. Nessa tabela evidencia-se a completude da ferramenta WARM no atendimento de tais funcionalidades. Critrios/FerramentasMatriz de Rastreabilidade Gerao Automatizada de Elos Sinalizao de Mudana de Requisitos Cascateamento/Herana de Elos Registro de Histrico de Mudana em Requisitos Baseline de Requisitos Versionamento de Requisitos e Baseline de Requisitos rvore de Impacto Integrao com PSEE Relacionamento entre Requisitos e Atividades Semntica dos Elos de Rastreabilidade

RequisitePro ReqManager CaliberRMSim Sim Sim No No No No Parcialmente No No No Sim No No No No No No No Sim No Sim Sim Parcialmente Sim No Sim Sim No No No No No

WARMSim Sim Sim Sim Sim Sim Sim Sim Sim Sim Sim

5. Consideraes FinaisA WARM uma ferramenta que tem como propsito apoiar as atividades do processo de Gerncia de Requisitos, fornecendo apoio desde a criao de requisitos at a anlise de impacto decorrente de mudanas em requisitos, alm de permitir o acompanhamento do histrico de mudanas em requisitos. As principais contribuies da ferramenta WARM so: a integrao com um ambiente de desenvolvimento de software centrado em processo, que minimiza a replicao de informaes com o uso de ferramentas separadas e otimiza o tempo de trabalho do gerente de requisitos a partir da gerao de rastros automticos; o controle sobre a evoluo dos requisitos de um sistema, atravs das funcionalidades de controle de verses de baselines de requisitos e versionamento de requisitos a partir de registro de solicitaes de mudanas. Em trabalhos futuros, pretende-se trabalhar outros componentes relativos rastreabilidade de requisitos, tais como: pacotes de cdigo, casos de teste, entre outros; alm de realizar um estudo de caso formal para avaliar o impacto do uso da ferramenta em projetos reais de desenvolvimento de software. Por fim, a ferramenta WARM, seus arquivos de documentao e uma base de exemplos podem ser encontrados em http://www.labes.ufpa.br/warm, sendo a mesma aderente licena GNU-GPL (General Public License).

17

RefernciasBorland. Borland CaliberRM. Disponvel http://www.borland.com/br/products/caliber/rm.html. Acesso em: jun. 2010. em:

Falbo, R.; Martins, A.; Nardi, J. C. (2006) ReqODE: Uma Ferramenta de Apoio Engenharia de Requisitos Integrada ao Ambiente ODE. In: Sesso de Ferramentas do XX Simpsio Brasileiro de Engenharia de Software. Florianpolis, Santa Catarina, Outubro. IEEE (1990) Std 610.12 - IEEE Standard Glossary of Software Engineering Terminology, Institute of Electrical and Electronics Engineers. Jacobs, D. (2007) Requirements Engineering So Things Dont Get Ugly. In: International Conference on Software Engineering. Companion to the proceedings of the 29th International Conference on Software Engineering. Pages 159-160. Lemos, A.; Sales, E.; Nascimento, L.; Lima Reis, C. (2009) Uso de prticas de gerenciamento de projetos no desenvolvimento de um sistema de apoio a redes de pesquisa no Estado do Par. In: II Workshop de Gerenciamento de Projetos de Software. Ouro Preto, Minas Gerais, Junho. Lima Reis, C.; Reis, R. (2007) Laboratrio de Engenharia de Software e Inteligncia Artificial: Construo do ambiente WebAPSEE. In: ProQuality, v. 3, p. 43-48. Pressman, Roger. S. (2005) Software Engineering: A practitioners approach, McGraw Hill, 6th edition. Rational. Rational RequisitePro. Disponvel em: 01.ibm.com/software/awdtools/reqpro/. Acesso em: jun. 2010. http://www-

Sales, E. O.; Frana, B.; Lima Reis, C. A.; Reis, R. Q. (2009) Utilizao do Ambiente WebAPSEE na Implantao do nvel G do MPS.BR no CTIC-UFPA. In: VIII Simpsio Brasileiro de Qualidade de Software. Ouro Preto, Minas Gerais, Junho. Sommerville, I. (2006) Software Engineering, Addison-Wesley, 8th edition. TABA. Estao TABA, verso de demonstrao. Disponvel em: http://ramses.cos.ufrj.br/taba/index.php?option=com_content&view=article&id=31& Itemid=120. Acesso em: jun. 2010.

18

Analizo: an Extensible Multi-Language Source Code Analysis and Visualization ToolkitAntonio Terceiro1 , Joenio Costa2 , Jo o Miranda3 , Paulo Meirelles3 , a 1 Luiz Rom rio Rios , Lucianna Almeida3 , Christina Chavez1 , Fabio Kon3 a1

Universidade Federal da Bahia (UFBA)

{terceiro,luizromario,flach}@dcc.ufba.br2

Universidade Cat lica do Salvador (UCSAL) ojoenio@perl.org.br3

Universidade de S o Paulo (USP) a

{joaomm,paulormm,lucianna,fabio.kon}@ime.usp.br

Abstract. This paper describes Analizo, a free, multi-language, extensible source code analysis and visualization toolkit. It supports the extraction and calculation of a fair number of source code metrics, generation of dependency graphs, and software evolution analysis.

1. IntroductionSoftware engineers need to analyze and visualize the software they create or maintain in order to better understand it. Software Engineering researchers need to analyze software products in order to draw conclusions in their research activities. However analyzing and visualizing large individual software products or a large number of individual software products is only cost-effective with the assistance of automated tools. Our research group have been working with empirical studies that require largescale source code analysis, and consequently we resort to source code analysis tools in order to support some of our tasks. We have dened the following requirements for the tool support we needed: Multi-language. The tool should support the analysis of different programming languages (in particular, at least C, C++ and Java), since this can enhance the validity of our studies. Free software. The tool should be free software1 , available without restrictions, in order to promote the replicability of our studies by other researchers. Extensibility. The tool should provide clear interfaces for adding new types of analyzes, metrics, or output formats, in order to promote the continuous support to our studies as the research progresses. In this paper, we present Analizo, a toolkit for source code analysis and visualization, developed with the goal of fullling these requirements. Section 2 describes related work. Section 3 describes Analizo architecture. Section 4 presents Analizo features. Section 5 presents Analizo use cases. Finally, Section 6 concludes the paper and discusses future work.1

In our work, we consider the terms free software and open source software equivalent.

19

2. Related workWhile evaluating the existing tools to use in our research, we analyzed the following ones: CCCC [Littlefair 2010], Cscope [Steffen et al. 2009], LDX [Hassan et al. 2005], CTAGX [Hassan et al. 2005], and CPPX [Hassan et al. 2005]. Besides the research requirements described, we have included two practical requirements: The tool must be actively maintained. This involves having active developers who know the tool architecture and can provide updates and defect corrections. The tool must handle source code that cannot be compiled anymore. For example, the code may have syntax errors, the libraries it references may be not available anymore, or the used libraries changed API. This is important in order to be able to analyze legacy source code in software evolution studies. The requirements evaluation for the tools are presented in Table 1. Since we only looked at tools that were free software, the table does not have a line for that requirement.Requirement Language support Extensibility Maintained Handles non-compiling code CCCC C++, Java No Yes Yes Cscope C No Yes No LDX C, C++ No No No CTAGX C No No No CPPX C, C++ No No No

Table 1. Found tools versus posed requirements

As it can be seen in Table 1, none of the existing tools we found fullls all of our requirements. In special, none of the tools were able to analyze source code in all three needed languages, and none of them had documented extension interfaces that could be used to develop new analysis types or output formats.

3. ArchitectureAnalizo architecture is presented in Figure 1, using a Layered style [Clements et al. 2002]. Each layer in the diagram uses only the services provided by the layers directly below it.Tools Extractor Metrics Core Output

Figure 1. Analizo architecture, using the Layered Style [Clements et al. 2002]

The Core layer contains the data structures used to store information concerning the source code being analyzed, such as the list of existing modules2, elements inside each module (attributes/variables, or methods/functions), dependency information (call,we used the module concept as a general term for the different types of structures used in software development, as classes and C source les2

20

inheritance, etc). This layer implements most of Analizo business logic, and it does not depend on any other layer. The Extractors layer comprises the different source code information extraction strategies built in Analizo. Extractors get information from source code and store them in the Core layer data structures. It requires only the creation of a new subclass to add a new type of extractor that interfaces with another external tool or provides its own analysis directly. Currently, there are two extractors. Both are interfaces for external source code parsing tools: Analizo::Extractors::Doxyparse is an interface for Doxyparse, a source code parser for C, C++ and Java developed by our group [Costa 2009]. Doxyparse is based on Doxygen3 , a multi-language source code documentation system that contains a robust parser. Analizo::Extractors::Sloccount is an interface for David A. Wheelers Sloccount4 , a tool that calculates the number of effective lines of code. The other intermediate layers are Metrics and Output. The Metrics layer processes Core data structures in order to calculate metrics. At the moment, Analizo supports a fair set of metrics (listed in Section 4). The Output layer is responsible for handling different le formats. Currently, the only output format implemented is the DOT format for dependency graphs, but adding new formats is simply a matter of adding new output handler classes. The Tools layer comprises a set of command-line tools that constitute Analizo interface for both users and higher-level applications. These tools use services provided by the other layers: they instantiate the core data structures, one or more extractors, optionally the metrics processors, an output format module, and orchestrate them in order to provide the desired result. Most of the features described in Section 4 are implemented as Analizo tools. Those tools are designed to adhere to the UNIX philosophy: they accomplish specialized tasks and generate output that is suitable to be fed as input to other tools, either from Analizo itself or other external tools. Some of the tools are implemented on top of others instead of explicitly manipulating Analizo internals, and some are designed to provide output for external applications such as graph drawing programs or data analysis and visualization applications.

4. Features4.1. Multi-language source code analysis Currently, Analizo supports source analysis of code written in C, C++ and Java. However, it can be extended to support other languages since it uses Doxyparse, which is based on Doxygen and thus also supports several different languages. 4.2. Metrics Analizo reports both project-level metrics, which are calculated for the entire project, and module-level metrics, which are calculated individually for each module. On the3 4

doxygen.org/ dwheeler.com/sloccount/

21

project-level, Analizo also provides basic descriptive statistics for each of the modulelevel metrics: sum, mean, median, mode, standard deviation, variance, skewness and kurtosis of the distribution, minimum, and maximum value. The following metrics are supported at the time of writing5: Project-level metrics: Total Coupling Factor, Total Lines of Code, Total number of methods per abstract class, Total Number of Modules/Classes, Total number of modules/classes with at least one dened attributes, Total number of modules/classes with at least one dened method, Total Number of Methods. Module-level metrics: Afferent Connections per Class, Average Cyclomatic Complexity per Method, Average Method LOC, Average Number of Parameters per Method, Coupling Between Objects, Depth of Inheritance Tree, Lack of Cohesion of Methods, Lines of Code, Max Method LOC, Number of Attributes, Number of Children, Number of Methods, Number of Public Attributes, Number of Public Methods, Response For a Class. 4.3. Metrics batch processing In most quantitative studies on Software Engineering involving the acquisition of source code metrics on a large number of projects, processing each project individually is impractical, error-prone and difcult to repeat. Analizo can process multiple projects in batch and produce one comma-separated values (CSV) metrics data le for each project, as well as a summary CSV data le with project-level metrics for all projects. These data les can be easily imported in statistical tools or in spreadsheet software for further analysis. This can also be used to analyze several releases of the same project, in software evolution studies. 4.4. Metrics history Sometimes researchers need to process the history of software projects on a more negrained scale. Analizo can process a version control repository and provide a CSV data le with the metrics values for each revision in which source code was changed in the project. Git and Subversion repositories are supported directly, and CVS repositories must be converted into Git ones beforehand. 4.5. Dependency Graph output Analizo can output module dependency information extracted from a source code tree in a format suitable for processing with the Graphviz6 graph drawing tools. Figure 2(a) presents a sample dependency graph obtained by feeding Graphviz dot tool with Analizo graph output. 4.6. Evolution matrix Another useful Analizo feature is generating evolution matrices [Lanza 2001]. After processing each release of the project (see Section 4.3), the user can request the creation of an evolution matrix from the individual data les. Figure 2(b) shows an excerpt of a sample evolution matrix produced by Analizo.5 6

References to literature on each metric were omitted because of space constraints. graphviz.org/

22

main_window.c 5 25 47 ewer.c 28 1 navigator.c 6 thumbnail_bar.c 11 thumbnail.c 4 2 2

(a) Sample module dependency graph

(b) Sample evolution matrix

Figure 2. Examples of Analizo features.

5. Usage in research workAnalizo has been extensively used by our group to support research projects: [Amaral 2009] used Analizo module dependency graph output to produce an evolution matrix for a case study on the evolution of the VLC project. Later on, an evolution matrix tool was incorporated in Analizo itself. [Costa 2009] did a comparison between different strategies for extracting module dependency information from source code, leading to the development of Doxyparse the Analizo Doxygen-based extractor. [Terceiro and Chavez 2009] used the metrics output on an exploratory study on the evolution of structural complexity in a free software project written in C. [Morais et al. 2009] used the Analizo metrics tool as a backend for Kalibro7 , a software metrics evaluation tool. Later on, Kalibro Web Service8 was developed, providing an integration with Spago4Q9 a free platform to measure, analyze and monitor quality of products, processes and services. [Terceiro et al. 2010] used the metrics history processing feature to analyze the complete history of changes in 7 web server projects of varying sizes. [Meirelles et al. 2010] used Analizo metrics batch feature to process the source code of more than 6000 free software projects from the Sourceforge.net repository. Most of the work cited above contributed to improvements in Analizo, making it even more appropriate for research involving source code analysis.

6. Final remarksThis paper presented Analizo, a toolkit for source code analysis and visualization that currently supports C, C++ and Java. Analizo has useful features for both researchers working with source code analysis and professionals who want to analyze their source code in order to identify potential problems or possible enhancements.7 8

softwarelivre.org/mezuro/kalibro/ ccsl.ime.usp.br/kalibro-service 9 spago4q.org

23

Future work includes the development of a web-based platform for source code analysis and visualization based on Analizo. This project is current under development. Analizo is free software, licensed under the GNU General Public License version 3. Its source code, as well as pre-made binary packages, manuals and tutorials can be obtained from softwarelivre.org/mezuro/analizo. All tools are selfdocumented and provide an accompanying UNIX manual page. Analizo is mostly written in Perl, with some of its tools written in Ruby and Shell Script. This work is supported by CNPQ, FAPESB, the National Institute of Science and Technology for Software Engineering (INES), Qualipso project, and USP FLOSS Competence Center (CCSL-USP).

ReferencesAmaral, V. (2009). An lise de evolucao de projetos de software livre atrav s de matrizes de a e evolucao. Undergraduation course conclusion project, Universidade Federal da Bahia. Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Nord, R., and Stafford, J. (2002). Documenting Software Architecture : Views and Beyond. The SEI series in software engineering. Addison-Wesley, Boston. Costa, J. (2009). Extracao de informacoes de depend ncia entre m dulos de programas c/c++. e o Undergraduation course conclusion project, Universidade Cat lica do Salvador. o Hassan, A. E., Jiang, Z. M., and Holt, R. C. (2005). Source versus object code extraction for recovering software architecture. In Proceedings of the 12th Working Conference on Reverse Engineering (WCRE05). Lanza, M. (2001). The evolution matrix: recovering software evolution using software visualization techniques. In IWPSE 01: Proceedings of the 4th International Workshop on Principles of Software Evolution, pages 3742, New York, NY, USA. ACM. Littlefair, T. (2010). CCCC - C and C++ Code Counter. Available at http://cccc. sourceforge.net/. Last access on June 3rd, 2010. Meirelles, P., Jr., C. S., Miranda, J., Kon, F., Terceiro, A., and Chavez, C. (2010). A Study of the Relationship between Source Code Metrics and Attractiveness in Free Software Projects. Submitted. Morais, C., Meirelles, P., and Kon, F. (2009). Kalibro: Uma ferramenta de conguracao e interpretacao de m tricas de c digo-fonte. Undergraduation course conclusion project, e o Universidade de S o Paulo. a Steffen, J., Hans-Bernhard, and Horman, B. N. (2009). Cscope. http://cscope.sourceforge.net/. Terceiro, A. and Chavez, C. (2009). Structural Complexity Evolution in Free Software Projects: A Case Study. In Ali Babar, M., Lundell, B., and van der Linden, F., editors, QACOS-OSSPL 2009: Proceedings of the Joint Workshop on Quality and Architectural Concerns in Open Source Software (QACOS) and Open Source Software and Product Lines (OSSPL). Terceiro, A., Rios, L. R., and Chavez, C. (2010). An Empirical Study on the Structural Complexity introduced by Core and Peripheral Developers in Free Software projects. Submitted.

24

An Eclipse-Based Multiple View Environment to Visualize Software CouplingGlauco de Figueiredo Carneiro, Paulo Roberto, Arleson Nunes and Manoel Mendona Departamento de Cincia da Computao Universidade Federal da Bahia (UFBA) Av. Adhemar de Barros, S/N, Campus de Ondina, 40170110 - Salvador BA Brazil{glauco.carneiro, paulor062, arleson061, mgmendonca}@dcc.ufba.br

Abstract. In spite of all views available in Modern Integrated Development Environments (IDE), programmers still struggle to obtain all the information they need from the source code. Software visualization tools have been proposed to solve this problem. However, most of them focus on a single visual metaphor that represents the software from a specific perspective and therefore addresses only part of a software comprehension issue. Real problems frequently require looking at the software from many different perspectives to undertake a maintenance task. It is thus desirable that an IDE provides several resources to explore the software according to the software comprehension goal at hand. In this context, the software coupling perspective plays an important role. Four new views presenting different coupling information about a software system were included in this new version of SourceMiner. They aim at complementing previous views of SourceMiner that represent inheritance hierarchy and the package-class-method. Now, the environment comprised of three perspectives arranged in six views provides a fairly broad set of software visualization mechanisms for programmers to understand source code.

1.

Introduction

This paper presents a new version of SourceMiner, an Eclipse plug-in to enhance software comprehension activities through the use of software visualization techniques. While the previous version [11] provided only two views, treemaps to present information of package-class-method (part A of Figure 1) and polymetric to present information of the inheritance-hierarchy of a software system (part B of Figure 1), the current version provides four new views to deal with coupling related information (part C of Figure 1). The goal of these new views is to broaden the support for programmers in characterizing (exploring and investigating) source code. This paper is organized as follows. Section 2 presents the motivation for a multiple view environment. Section 3 describes the main functionalities of this environment. Section 4 presents related work and section 5 the conclusions.

2.

The Motivation for a Multiple View Environment

In spite of the available resources in current integrated development environments (IDEs), program understanding remains a very difficult task, especially on large and complex software systems. Depending on the case, different types of information are required for achieving the user objectives, such as fixing errors, changing or adding new features, or improving the code and design. For example, the information about the code structure presented by the Eclipses package explorer (package-file-class-methods and attributes hierarchy) is useful but limited. The package explorer itself used together with other IDE available views is insufficient to present a big picture about important

25

software properties such as inheritance hierarchy. Moreover, it does not also appropriately convey the coupling among software modules that comprise the whole system. In fact, most of the modern IDEs represent these properties only for a selected class (or even method or attribute). The Motivation for a Multiple View Environment Most of software comprehension activities require the identification of different properties manifested in the source code. For this reason, it cannot be based on only one view, but usually on two or more views that portray simultaneously different software properties. Many initiatives have been done to implement and propose the use of visualization to represent these properties. The problem is that most of them are not integrated with the IDE and not integrated among themselves. In order to address this issue, this paper presents SourceMiner, an Eclipse plug-in that provide multiple views integrated with the well known IDE resources. To tackle the occlusion problem, filtering resources are provided to present only information that satisfies a criterion and therefore reducing the amount of software elements conveyed. Interaction and navigation mechanisms from the information visualization domain such as range sliders and semantic/geometric zooming are also provided.

3.

The Multiple View Software Visualization Environment

According to [2], many of the characterization activities related to object-oriented systems include at least the following properties: (i) size and complexity, (ii) inheritance and (iii) coupling. These properties provide useful information for designing and implementing views that represent the package-class-method structure, the inheritance hierarchy and coupling relationships among modules in a software system (parts A, B and C from Figure 1 respectively). Parts A and B were presented in [11] while the views from part C are the contribution of this paper. The use of these views together has the goal to facilitate comprehension, especially if effectively combined and cross-referenced. In addition to the four new views, new interactive resources such as those to filter in/out software elements in the visual presentation were also implemented. Now programmers can easily spot software elements using the filtering resource by typing the information (e.g. name of the software element) or by adjusting each of the availableResultedScenario JavaSource Code AbstractSyntax Treeprovidedand usedbyEclipse Model ScenarioView(s) Information Extraction Model Mapping

Visual Scenarios

MappingtheModel toEachView

+

Software Maintenance Activity

Control Filters

Software Maintenance ActivityTXTLogFile forData Acquisition ofPrimitive Operations

Treemaps View

Polymetric View

Graph View

Matrix View

GridView

Egocentric Graph View

(A)

(B)

(C)Perspective3

Perspective1 Perspective2

Figure 1: An overview of the Multiple View Software Visualization Environment

26

range slider filters to the values of interest. The response time to render the visualizations is instantaneous by all practical purposes. With just a few clicks, one can select the modules that fulfill certain search criteria. By selecting a module directly over the visual interface, it is possible to use geometric or semantic zooms available in each view or to access its corresponding source code in editor. A complete list of filtering functionalities is available at [1]. All these features help programmers to visualize the software elements that satisfy a set of criteria, reducing visual occlusion in the views. SourceMiner is an Eclipse plug-in configured for Java. As depicted by Figure 1, the environment gets information provided by the Abstract Syntax Tree (AST) in Eclipse. The result is a complete model of the source code under analysis that provides input to each view. Due to the information provided by the Model (Figure 1), new views are easily included to the environment. The first perspective addresses how packages, classes and methods are organized. Treemaps [6] was the view implemented previously in this perspective [11]. The second perspective is the software inheritance-wise. Its goal is to provide information to characterize the software in terms of inheritance hierarchy and to identify opportunities to better redistribute functionalities to other classes. The polymetric [3] was the view implemented previously in this perspective [11]. It is particularly efficient to represent inheritance trees that comprise the software system. The third perspective (part C of Figure 1) is the software dependency. It aims at addressing module coupling issues, helping programmers to identify occurrences of highly coupled modules as well as providing information to understand the reasons that motivated them. Four views were specially designed and implemented in this perspective: Graph, Matrix, Grid and Spiral Egocentric Graph. They represent the main contributions of this paper in this new version of SourceMiner. The Graph (Figure 2) and Matrix (Figure 3) views represent the relationships among modules and its overall structure. The Grid and Spiral Egocentric Graph (Figure 4) views focus on the degree of coupling relationships.

Classes of Package X that Depend on the Central Package

PackagesPackage X

Package with the Highest Afferent Coupling

Figure 2: The Graph View

27

Figure 3: The Matrix View

The excessive inter-module dependencies have long been recognized as an indicator of poor software design. Moreover, highly coupled systems, those in which modules have unnecessary dependencies, are hard to work with because they are not easy to understand, change and extend in isolation. The Graph view provides two modes of representations: the relationship of packages (mode 1- Figure 2) and classes (mode 2). Graphs are composed of objects (nodes) and relations (links). As software visualization mostly deals with software modules and their interrelations, graph-based representations play a major role in this context. They can be used to configure appropriated visual scenarios to spot coupling relationships that otherwise may remain hidden. For this reason, it is a suitable structure to represent dependency among software modules. However, as soon as the size of the graph and the link density increases, node-link graphs face occlusion problems due to link overlapping. Thus, it becomes difficult for programmers to visually explore the graph and interact with its elements. To tackle this problem, the implemented version of this view provides interactive resources and filters to portray the relationships in accordance with the criteria (e.g. afferent or efferent coupling value) configured by the programmer. This will filter in/out the number of nodes and links to be visualized, thus reducing the occlusion occurrences. Programmers may optionally choose to configure the graph according to the type of dependency (object, method, field, inheritance, interface implementation, interface inheritance). Another possibility is the selection of specific nodes to visualize their coupling based on the dependency directions such as afferent and efferent coupling of selected nodes. The Matrix view (Figure 3) provides three modes of representation: the relationship among packages (mode 1), classes (mode 2) and methods (mode 3). Nodelink-based graphs are prone to exhibit a high amount of visual clutter as a result of edge congestion, whereas the matrix visualization shows a stable and clean layout. Depending on the selected mode packages, classes or methods are displayed along the axes of the matrix and the relationship among them is shown within the matrix as shaded cells. A geometric zoom is available via range slider to allow programmers to specify the scale of magnification by increasing or decreasing the matrix. Programmers may use both graph of node-link diagrams and matrices to show the global structure. One view can complement the other to better visualize dense sub graphs.

28

Classes from the same Package Dependency Strength between Modules

Figure 4: The Spiral Egocentric Graph

The Grid view portrays an overview about the coupling degree of all modules (classes and interfaces) that comprise the software system. A grid layout was adopted. Cells represent the modules whereas their position and label represent the coupling degree with other system modules. Each module is represented by a cell in decreasing order, i.e., the module with the highest dependency value is in the upper left corner of the canvas whereas the lowest dependency value is in the bottom right corner. Depending on the coupling option selected in the menu by the programmer, the value of the dependency strength can refer to the afferent coupling value (how many nodes depend on the presented node), efferent coupling of selected nodes (how many nodes the presented node depends on) or both. This view and the Spiral Egocentric Graph (Figure 4) presented in the next paragraph were defined, designed and implemented especially for our plug-in. We did not find in the literature suitable visualizations to effectively portray the dependency strength among software modules. The Spiral Egocentric Graph (Figure 4) view presents the coupling degree of a specific node with other modules from the software under analysis. This is portrayed as a Spiral Egocentric Graph where the central node is the module under analysis while the other peripheral nodes are positioned in accordance to its dependency strength to the central node. This information is useful to identify classes that are more demanded or that demand more from others. This is the central point of important code smells such as God Class (GC) that is characterized by non-cohesiveness of behavior and the tendency of a class to attract more and more features [2]. Currently, all the views present the name of the project, the number of packages, classes and methods of the project under analysis. Programmers may use a combination of filters to select the software entity attributes to be presented in the canvas to easy their understanding. All the views are integrated to the same filtering engine in order to maintain consistent visual scenarios. Colors represent module features so that visual elements can be filled with colors representing size, complexity and element types (abstract class, external class, and interfaces). It is up to programmers to decide what information will be represented by the color that fills the visual elements.

29

4.

Related Works

A large number of software visualization tools and techniques have been developed to support comprehension activities. Seesoft [10], Rigi [9], SHriMP [8], CodeCrawler [3] are examples of these tools. However, only a few of them deals with the construction of extensible multi-perspective software visualization resources and the mechanisms to interact with them [7][8][9]. For this reason, there is still room to explore the use of new non-traditional software visualization paradigms to enhance software comprehension activities arranged in multiple perspectives integrated to the IDE. SourceMiner is an extensible environment that allows the inclusion of new views. The information of the source code already available in the model (as depicted in Figure 1) easies the design and implementation of new views.

5.

Conclusions and Future Work

This paper presented a new version of SourceMiner, an Eclipse plug-in that provides a multi-perspective environment aimed at enhancing software comprehension activities. Studies have been carried out to analyze the use of the plug-in in real software comprehension activities. One of them is a characterization study that investigates how programmers use the plug-in to identify code smells. Another is a case study conducted in the industry to analyze to which extent the environment is useful to support programmers in a set of typical preventive maintenance activities. We are currently working on the implementation of new resources to support software evolution visualization and collaborative programming.

References1. 2. 3. 4. 5. 6. 7. 8. 9. The SourceMiner plug-in, tutorial, screenshots and preliminary empirical study data are available at http://www.sourceminer.org. Lanza, M.; Radu Marinescu. Object-Oriented Metrics in Practice Using Software Metrics to Characterize, Evaluate, and Improve the Design of Object- Oriented Systems. Springer, 2006. Lanza, M.; Ducasse, S. Polymetric Views - A Lightweight Visual Approach to Reverse Engineering. In IEEE Transactions on Software Engineering (TSE), 2003. M.-A. Storey. Theories, tools and research methods in program comprehension: past, present and future. Software Quality Control, 14(3):187208, 2006. Wu, J., and M.-A. Storey. A multi-perspective software visualization environment. In Proceedings of CASCON'2000, November 2000, pp. 41-50. Shneirderman, B. Tree Visualization with Tree-Maps: A 2-D Space-Filling Approach. ACM Transactions on Graphics (ToG) 11, 1 (1992), 9299. R. Lintern, J. Michaud, M.-A. Storey, and X. Wu. Plugging-in visualization: experiences integrating a visualization tool with eclipse. In SoftVis 2003, USA. Storey, M.-A., C.