http://cbsoft.dcc.ufba.

br

XVII Sesso de Ferramentas A N A I S

Foto: MaW

Volume 4

ISSN 2178-6097

Sesso de Ferramentas
XVII Sesso de Ferramentas
Setembro de 2010 Salvador Bahia Brasil

ANAIS
Coordenador 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 CBSoft

A 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 Session

The 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 Biography

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

Coordenador do Comit de Programa Chair

Uir Kulesza, DIMAp/UFRN

Comit de Programa Program Committee

Adenilso 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 Reviewers

Adailton 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 Committee

Coordenao Local SBES SBES Local Co-Chairs
Christina von Flach Garcia Chavez (DCC/IM/UFBA) Cludio Nogueira SantAnna (DCC/IM/UFBA)

Coordenador Geral do CBSOFT CBSOFT General Chair

Manoel Mendona (DCC/IM/UFBA)

Coordenadora de Organizao do CBSOFT CBSOFT Organizing Chair

Vaninha Vieira (DCC/IM/UFBA)

Coordenao Local SBES SBES Local Co-Chairs

Christina Chavez (DCC/IM/UFBA) Claudio Sant'Anna (DCC/IM/UFBA)

Coordenao Local SBCARS SBCARS Local Co-Chairs

Eduardo Almeida (DCC/IM/UFBA) Adolfo Almeida Duran (CPD/UFBA)

Coordenao Local SBLP SBLP Local Co-Chairs

Lais N. Salvador (DCC/IM/UFBA) Rita Suzana P. Maciel (DCC/IM/UFBA)

Time de Organizao Organizing Team

Antonio 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 Execution

DAGAZ Eventos

viii

XVII Sesso de Ferramentas

ndice Table of Contents

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

Ferramenta de Apoio Engenharia de Requisitos Integrada a um Ambiente Colaborativo de Cdigo Aberto

Giselle 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. Introduo
O 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

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 Redmine

Conforme 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

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

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.

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 Relacionados
Dentre 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.

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 Futuros

Este 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. Referncias
Pressman, 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.

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

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

2

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

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 a
S 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-Diagram
Nesta 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. a
1

www.eclipse.org

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

 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 a
Este 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 e
Arnold, 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 Processos
Murilo 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. Introduo
Requisitos 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 Manager

A 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 Utilizao
Nesta 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.

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 Relacionados
Nesta 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/Ferramentas
Matriz 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 CaliberRM

Sim 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

WARM
Sim Sim Sim Sim Sim Sim Sim Sim Sim Sim Sim

5. Consideraes Finais
A 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

Referncias
Borland. 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 Toolkit

Antonio Terceiro1 , Joenio Costa2 , Jo o Miranda3 , Paulo Meirelles3 , a 1 Luiz Rom rio Rios , Lucianna Almeida3 , Christina Chavez1 , Fabio Kon3 a
1

Universidade Federal da Bahia (UFBA)

{terceiro,luizromario,flach}@dcc.ufba.br
2

Universidade Cat lica do Salvador (UCSAL) o

joenio@perl.org.br
3

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. Introduction
Software 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 work
While 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. Architecture
Analizo 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 les
2

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. Features
4.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 the
3 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 work

Analizo 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 remarks
This 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).

References
Amaral, 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 Coupling

Glauco 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 available
ResultedScenario JavaSource Code AbstractSyntax Treeprovidedand usedbyEclipse Model Scenario
View(s) Information Extraction Model Mapping

Visual Scenarios

MappingtheModel toEachView

Software Maintenance Activity

Control Filters

Software Maintenance Activity

TXTLogFile 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

Packages
Package 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.

References
1. 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. Best, J. Michaud, D. Rayside, M. Litoiu, and M. Musen. SHriMP views: an interactive environment for information visualization and navigation. In CHI 2002, USA. Muller H.A. and Klashinsky K. Rigi: A system for programming-in-the-large. In Proceedings of the 10th International Conference on Software Engineering, pp. 8086. Singapore, 1998.

10. Eick, S.; Steffen, J.; Eric S. SeeSoftA Tool for Visualizing Line Oriented Software Statistics. IEEE Transactions on Software Engineering, 18(11):957968, November 1992. 11. Carneiro, G. F; Magnavita, R.; Spnola. E.; Spnola, F.; Mendona Neto, M. G. . An EclipseBased Visualization Tool for Software Comprehension. SBES Tools Session, 2008.

30

Hist-Inspect: Uma Ferramenta de Apio Avaliao Sensvel Histria de Cdigo

Leandra Mara, Gustavo Honorato, Francisco Dantas, Alessandro Garcia, Carlos Lucena
1

Departamento de Informtica Pontifcia Universidade Catlica do Rio de Janeiro (PUC-Rio) - Rio de Janeiro RJ Brazil
{lsilva,ghonorato,fneto,afgarcia,lucena}@inf.puc-rio.br

Abstract. Only a few studies have investigated the inuence of considering historic properties of evolving code in the detection of modularity aws. A key reason is the lack of adequate tooling support for history-sensitive anomaly detection. This paper presents a tool that allows the specication and evaluation of different congurations of detection strategies by means of a domain-specic language (DSL). The proposed tool enables empirical assessments of both conventional and history-sensitive strategies and also offers developers a exible environment for dening and applying these strategies. Evolution charts and history-sensitive metrics are also made available.

1. Introduo
Uma estratgia de deteco [1] uma condio lgica composta por mtricas e respectivos valores limites que detecta elementos com anomalias de modularidade1 [2]. Seu grande benefcio que o desenvolvedor pode localizar diretamente classes e mtodos afetados por uma dada anomalia, em vez de ter que inferir o problema a partir de um extenso conjunto de valores anormais de mtricas. Um problema central de estratgias de deteco convencionais que elas ainda resultam em um considervel nmero de falsos positivos e negativos [3]. Dessa forma, h a necessidade de pesquisas que explorem melhor a composio de estratgias de deteco visando aumentar a eccia das deteces. Sabese, contuto, que um requisito fundamental para tais pesquisas o suporte adequado de ferramentas que automatizem tais estratgias. Alguns pesquisadores [3] acreditam que uma possvel limitao das estratgias convencionais [1] que, apesar de atualmente o desenvolvimento de sistemas ser cada vez mais incremental, elas no levam em considerao a histria de evoluo dos mdulos para detectar possveis anomalias. Dessa forma, elas perdem informaes importantes como instabilidade dos mdulos, aumento contnuo de complexidade, dentre outras. Apesar dessas suspeitas, poucos trabalhos na literatura tm investigado como informaes bsicas sobre a evoluo dos mdulos podem: (i) auxiliar na deteco ecaz de anomalias de modularidade, e (ii) contornar limitaes das estratgias baseadas em anlises individuais de verses de programas. Um dos fatores que limitam tais pesquisas que as ferramentas de deteco existentes [4, 5, 6, 7] no do suporte ao clculo de mtricas sensveis histria e, dessa forma, no disponibilizam estratgias que permitam considerar o histrico evolutivo das propriedades do cdigo. Alm disso, a maioria disponibiliza ao
Neste artigo, usaremos o termo anomalias de modularidade (ou, simplesmente, anomalias) como sinnimo ao termo em ingls code smells [2].
1

31

usurio pouca ou nenhuma liberdade para a criao de novas combinaes de mtricas e valores limites que integram uma estratgia (Seo 2). Este trabalho apresenta a ferramenta Hist-Inspect (Seo 3) que, alm de suportar a apresentao de grcos de evoluo e de mtricas sensveis histria, como principal contribuio possibilita a especicao de diferentes estratgias de deteco atravs de uma linguagem especca de domnio (DSL) [8]. Tal exibilidade atende necessidades de dois grupos de usurios: desenvolvedores interessados em ajustar valores limites ou combinaes de mtricas para a deteco de anomalias; e pesquisadores interessados na avaliao e comparao da eccia de diferentes estratgias, sejam elas convencionais ou sensveis histria. A ltima seo do artigo (Seo 4) apresenta concluses e direes de pesquisas futuras utilizando os recursos desta ferramenta.

2. Limitaes de Ferramentas Relacionadas

Algumas ferramentas de deteco tm sido propostas como a Together [4], inCode [5], iPlasma [6] e inFusion [7]. Todas fornecem ao usurio informaes sobre entidades com certas anomalias de modularidade. Porm, nenhuma delas apresenta exibilidade quanto criao e alterao de estratgias utilizadas. Elas tambm no do suporte a mtricas e estratgias de deteco que levem em considerao a histria de evoluo dos mdulos. Nesse caso, podemos citar algumas limitaes relacionadas criao de estratgias convencionais. Por exemplo, em ferramentas clssicas como o Together [4] ou mesmo a inCode [5], os algoritmos de deteco so denidos em mbito de cdigo por desenvolvedores, ao invs de poderem ser especicados em alto nvel por especialistas no domnio de deteco e avaliao de cdigo. A falta de possibilidade de incluir ou alterar estratgias torna complicado adapt-las a diferentes contextos ou necessidades de usurios, ou ainda, comparar os resultados de diferentes estratgias. A rigidez dessas ferramentas limita as decises sobre anomalias, mtricas e valores limites considerados, ao grupo de desenvolvedores que as desenvolveu. Sendo assim, nenhuma customizao disponibilizada ao usurio e qualquer necessidade de alterao remete necessidade de alteraes a serem realizadas exclusivamente no cdigo pelos desenvolvedores dessas aplicaes. Outras ferramentas como a iPlasma [6] e a inFusion [7] at disponibilizam a congurao de estratgias em nvel mais elevado, ou seja, em nvel de usurio. Porm, (i) as customizaes so limitadas pelo uso de elementos e operaes disponveis em uma interface de congurao e (ii) as novas estratgias no podem ser salvas para inspees futuras. Nessas interfaces de congurao, no se consegue, por exemplo, especicar uma estratgia que contenha a expresso m1 /m2 ou a expresso m1 > m2 , onde m1 e m2 so mtricas. A falta de suporte a avaliaes que levem em considerao a evoluo do cdigo associada inexibilidade quanto adio e alterao de estratgias de deteco, so algumas das limitaes deixadas pelas ferramentas existentes.

3. A Ferramenta Hist-Inspect
O ambiente Hist-Inspect2 tem como objetivo principal apoiar a aplicao de estratgias de deteco sensveis histria. Contudo outros recursos sensveis histria tambm so disponibilizados como grcos de evoluo das propriedades do cdigo e mtricas. Mais de 40 mtricas sensveis histria foram criadas para que pudessem ser utilizadas em
2

Do ingls, History Sensitive Inspection

32

estratgias de deteco. A verso atual da ferramenta no efetua os clculos de mtricas convencionais, pois muitas so as ferramentas que j disponibilizam tais clculos. Portanto, optou-se por priorizar o desenvolvimento de funcionalidades que no existiam em ferramentas clssicas de deteco. Apesar dessa seo apresentar duas telas da ferramenta (Figuras 3.a e 3.b), outras telas e artefatos, bem como o endereo para obteno do cdigo fonte so disponibilizados no stio dessa pesquisa3 . 3.1. Funcionalidades Principais Suporte a Grcos de Evoluo. Ao se pensar em anlise sensvel histria, faz-se necessrio a observao de dados histricos que revelam o comportamento evolutivo do sistema durante seu ciclo de vida. Por meio de grcos (Figura 1.a), o avaliador pode perceber a estabilidade, o crescimento ou decrescimento de uma dada propriedade (por exemplo, linhas de cdigo), sem ter que exatamente recuperar o valor dessa propriedade em cada verso do mdulo avaliado. Alm disso, torna-se interessante poder visualizar o comportamento de mais de uma mtrica ao longo da histria de um mdulo, possiblitando, inclusive, a descoberta de padres de inuncia que uma propriedade teve sobre a outra. A ferramenta proposta disponibiliza tal funcionalidade e para implement-la foi utilizada a biblioteca grca JFreeChart4 . Suporte a Mtricas Sensveis Histria. Mtricas sensveis histria (SHs) [3] consideram a avaliao das caractersticas dos mdulos ao longo do seu histrico de evoluo. Em sua grande maioria elas medem a evoluo de mtricas convencionais como as de complexidade, coeso, dentre outras. A implementao dessas mtricas foi motivada pela necessidade de viabilizar a criao e aplicao de estratgias de deteco sensveis histria. Atravs do clculo dessas mtricas possvel obter informaes como: a quatidade de vezes que um dado mdulo sofreu aumento de linhas de cdigo ao longo de sua histria (rniLOC), a variao mdia de linhas de cdigo em cada verso (rdocLOC), o aumento percentual da complexidade de um mdulo em relao a sua verso anterior (rpiWMC), e assim por diante. Todas foram originalmente propostas no contexto dessa pesquisa [9]. Suporte a Estratgias de Deteco. Para possibilitar a especicao declarativa de diferentes conguraes de estratgias a ferramenta utilizou uma Linguagem Especca de Domnio (DSL). O objetivo ao utilizar uma DSL foi proporcionar um alto nvel de exibilidade na especicao dessas estratgias, provendo assim uma funcionalidade que no encontrada em nenhuma das ferramentas relacionadas. A linguagem de especicao uma DSL Interna [8], nomeada DSSL5 . Reutilizamos um interpretador de JavaScript para construir a linguagem. Portanto, os mesmos mecanismos sintticos da linguagem base (neste caso o JavaScript) so disponibilizados no vocabulrio de nossa DSL. A Equao 1 mostra um exemplo de criao de uma estratgia de deteco sensvel histria utilizando DSSL. rdocLOC > 10 && rniWMPC1 >= 0.4 (1)

possvel observar atravs da Equao 1 que a criao de novas estratgias com DSSL uma tarefa com alto nvel de abstao. Dessa forma, exclui-se a necessidade de
http://www.inf.puc-rio.br/ lsilva http://www.jfree.org/jfreechart/ 5 Do ingls, Detection Strategy Specication Language (Linguagem de Especicao de Estratgias de Deteco)
4 3

33

se utilizar recursos de programao como a criao de classes e algoritmos, o que seria necessrio em ferramentas como a Together, por exemplo. Na Equao 1, os elementos rdocLOC e rniWMPC1 so mtricas sensveis histria [9]. A Figura 1.b apresenta um relatrio de deteco com os resultados da deteco de uma estratgia SH.

(a) Apresentao de Grco de Evoluo

(b) Relatrio HTML de Deteces

Figura 1. Funcionalidades Bsicas da Hist-Inspect

3.2. Arquitetura e Funcionamento Essa seo apresenta o uxo de funcionamento e alguns aspectos tcnicos da ferramenta proposta. As funcionalidades da Hist-Inspect foram implementadas em dois mdulos separados utilizando a linguagem Java. O primeiro um mdulo de gerao de grcos de evoluo implementado atravs da plataforma Eclipse. O segundo um mdulo de gerao de relatrios de deteces, resultantes da aplicao de estratgias de deteco. Esse segundo mdulo, por enquanto, disponibilizado atravs de uma interface de linha de comando. Entretanto, existe a inteno de migr-lo para que tambm esteja sobre a plataforma do Eclipse. Por limitaes de espao, iremos apresentar apenas o segundo mdulo, pois possui as funcionalidades que julgamos mais relevantes ao contexto de estratgias de deteco. Os elementos integrantes desse mdulo so apresentados pela Figura 2. Como mostra a Figura 2, o mdulo toma como entrada um arquivo chamado Lista de Arquivos de Mtricas. Essa lista, por sua vez, possui a localizao de outros arquivos que possuem os valores de mtricas convencionais calculados em cada uma das verses do sistema. J o Orculo de Anomalias uma entrada opcional e apenas fornecida se o usurio desejar calcular medidas de preciso e revocao dos resultados gerados por uma estratgias de deteco. Ambas as entradas so implementadas atravs de arquivos XML. Os n arquivos com as mtricas convencionais das n verses do sistema so arquivos .mtbl6 que so gerados atravs da ferramenta Together. Conforme justicado na Seo 3, optou-se por no efetuar o clculo de mtricas convencionais, uma vez que muitas ferramentas j disponibilizam tais resultados. Nesse caso, so utilizados os resultados de mtricas convencionais geradas pela Together [4], escolhida, principalmente, por ser uma ferramenta de medio bem conhecida e aceita. O elemento Parser, na Figura 2, transforma a representao textual do XML de entrada em um modelo de domnio a ser utilizado pela aplicao. Entretanto, o modelo gerado pelo Parser armazena apenas informaes de mtricas convencionais. O Gerador do Modelo SH quem l as Especicaes das Mtricas Sensveis a Histria e transforma o modelo convencional em um Modelo Senvvel Histria. Grande parte do Parser foi
6

Exteno do arquivo gerado pelo Together com os resultados de mtricas convencionais solicitadas.

34

Entrada
Orculo de Anomalias

Hist-Inspect
(Mdulo de Estratgias de Deteco)

Sada

Mtricas (V.1)

Parser

Gerador do Modelo SH Modelo SH

Avaliador de Regras Gerador de Relatrios DSSL

Mtricas (V.2)

Relatrio de Deteco

Lista de arquivos de mtricas Especicao Catlogo Catlogo de de de Regras Mtricas SH em DSSL Anomalias Templates

Mtricas (V.n)

Figura 2. Funcionamento e Elementos Principais da Arquitetura da Hist-Inspect

gerado utilizando o framework XMLBeans7 , enquanto a Especicao de Mtricas SH foi feita atravs de classes que implementam uma interface Java especca para tais mtricas. A partir do Modelo com Mtricas SH de cada entidade transferida ao Avaliador de Regras a responsabilidade de realizar as deteces. Nesse caso, tal elemento carrega dois catlogos, um contendo as especicaes das regras ou estratgias de deteco e outro contendo as anomalias de modularidade a serem consideradas. Esses dois catlogos so implementados atravs de arquivos XML, como ilustra a Figura 3. O Avaliador de Regras gerencia o contexto de execuo do JavaScript, criando as variveis que representam as mtricas e atribuindo os seus respectivos valores dependendo do entidade que est sendo avaliada no momento (pacote, classe ou mtodo). Finalmente, as regras indicadas pelo atributo expression (Figura 3a) so aplicadas aos mdulos do sistema. Caso a expresso de deteco seja verdadeira para uma determinado mdulo, o Avaliador de Regras destaca a ocorrncia da anomalia. A anomalia avaliada pela regra indicada pelo elemento anomaly.

(a) Catlogo XML de Estratgias

...

(b) Catlogo XML de Anomalias

Figura 3. Exemplos de Especicao de Estratgias e Respectivas Anomalias

Finalmente, como mostra a Figura 2, o Gerador de Relatrios combina as informaes produzidas pelo Avaliador de Regras com um Template HTML, gerando o Relatrio que ser apresentado ao usurio. O Gerador de Relatrios processa templates de relatrios utilizando a linguagem de templates Velocity8 . Opcionalmente, tambm possvel inserir nesse relatrio de deteces informaes sobre falsos positivos e negativos,
7 8

http://xmlbeans.apache.org/ http://velocity.apache.org/

35

preciso e revocao das estratgias aplicadas. Esses so calculados a partir do elemento Orculo de Anomalias. A Figura 1 apresenta um exemplo de relatrio HTML de deteco gerado pela ferramenta.

4. Concluses e Trabalhos Futuros

Este artigo apresentou uma viso geral da Hist-Inspect, uma ferramenta que como caracterstica principal suporta a especicao e execuo de estratgias de deteco. Atualmente, atravs da Hist-Inspect, algumas evidncias iniciais j puderam ser geradas sobre a eccia de estratgias de deteco sensveis histria [9]. Comparaes com estratgias convencionais tambm foram facilitadas. Por exemplo, em estudo recente [9], observouse que em 7 verses de um sistema, estratgias sensveis histria se apresentaram ecazes na deteco de anomalias clssicas de modularidade como God Class, Divergent Change e Shotgun Surgery [2]. Novos estudos experimentais sobre deteco de anomalias j esto sendo realizados e outros planejados. Algumas melhorias tcnicas para a Hist-Inspect tambm podem ser sugeridas. Por exemplo, a especicao das mtricas sensveis histria atualmente feita usando classes Java. Entretanto, no futuro elas poderiam ser implementadas utilizando uma linguagem de Script (como Java Script, Rubby ou Lua) ou uma nova DSL. Tal fato, possibilitaria a criao e obteno de resultados de novas mtricas SHs sem a necessidade de recompilar todo o cdigo. Como melhoria funcional relacionada aos grcos, no futuro eles poderiam fornecer uma viso panormica do nmero de anomalias presentes ao longo das verses do sistema. Tal informao poderia fornecer uma idia sobre a depreciao do cdigo relativa ao crescimento ou decrescimento de anomalias ao longo do histrico do sistema.

Referncias
[1] M. Lanza, R. Marinescu, and S. Ducasse, Object-Oriented Metrics in Practice. cus, NJ, USA: Springer-Verlag New York, Inc., 2006. Secau-

[2] M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts, Refactoring: Improving the Design of Existing Code. Addison-Wesley, Reading, MA, USA, 1999. [3] D. Ratiu, S. Ducasse, T. Girba, and R. Marinescu, Evolution-enriched detection of god classes, in CAVIS 04, 2004, pp. 37. [4] Together. Website. [Online]. Available: http://www.borland.com/br/products/together/ [5] incode. Website. [Online]. Available: http://loose.upt.ro/incode/pmwiki.php/ [6] iplasma. Website. [Online]. Available: http://loose.upt.ro/iplasma/ [7] infusion. Website. [Online]. Available: http://www.intooitus.com/inFusion.html [8] A. van Deursen, P. Klint, and J. Visser, Domain-specic languages: an annotated bibliography, SIGPLAN Not., vol. 35, no. 6, pp. 2636, 2000. [9] L. Mara, F. Dantas, G. Honorato, A. Garcia, and C. Lucena, Detectando anomalias de cdigo em evoluo: O que a histria pode revelar? in SBCARS 10 (submetido), Salvador, BA, Brasil, 2010.

36

AssistME uma Ferramenta para Auxiliar a Refatorao para Aspectos de Tratamento de Excees
Cristiane Queiroz1, Fernando Castor2, lio Cacho3 Departamento de Sistemas e Computao Universidade de Pernambuco (UPE) Recife, PE - Brasil 2 Centro de Informatica Universidade Federal de Pernambuco (UFPE) Recife, PE - Brasil 3 Escola de Cincia e Tecnologia Universidade Federal do Rio Grande do Norte (UFRN) Natal, RN Brasil ccq@dsc.upe.br, castor@cin.ufpe.br, neliocacho@ect.ufrn.br Abstract. One of the potential application areas of Aspect Oriented Programming (AOP) is to modularize exception handling code, localizing handlers within concern-specific units. Existing systems can also leverage the benefits of AOP if their exception handlers are moved to aspects by means of refactoring. otwithstanding, such refactoring requires knowledge about a number of scenarios and conditions that make it a time-consuming and errorprone activity. This paper presents AssistME, a tool that assists developers in refactoring Java exception handlers to aspects.
1

1. Introduo
A tcnica de tratamento de excees utilizada no desenvolvimento de sistemas com a finalidade de aumentar a robustez dos mesmos, pois esta tcnica torna possvel a deteco, a sinalizao e o tratamento de erros. Porm, nos mecanismos tradicionais, como o de Java, os tratadores so implementados em vrios componentes, ficando espalhados por todos eles, o que pode dificultar o entendimento, a manuteno e principalmente o reuso destes componentes. Para reduzir tais problemas, vrios trabalhos [Lippert e Lopes 2000, Laddad 2003, Castor et al. 2009] sugerem utilizar a Programao Orientaada a Aspectos (POA) para localizar os tratadores de excees em aspectos, de modo a reduzir esse espalhamento. Essa tcnica pode, inclusive, ser empregada para melhorar a estrutura de sistemas pr-existentes. Basta, para isso, que os tratadores de excees desses sistemas sejam extrados para aspectos por meio de refatoraes. Infelizmente, a refatorao de tratamento de excees para aspectos em sistemas de software dispendiosa e sensvel a erros, uma vez que existem vrios fatores[Castor et al. 2009] que precisam ser levados em considerao. Tais fatores, quando combinados, podem resultar em: (i) tratadores muito difceis de extrair; e (ii) problemas sutis que fazem com que a extrao dos tratadores para aspectos deixe de ser benfica para a qualidade do sistema, quando leva-se em conta robustez e modularidade. Nestes casos, o programador deve analisar cada caracterstica e decidir entre refatorar ou no. Este artigo apresenta a AssistME (Assistance for the Modularization of Exceptions), uma ferramenta que auxilia no processo de refatorao de tratamento de excees de Java para AspectJ. AssistME funciona como um plugin para o Eclipse e identifica os fatores importantes para a extrao do tratamento de excees para aspectos, indicando-os para o desenvolvedor. Os principais diferenciais desta

37

ferramenta so dois: (i) totalmente focada no tratamento de excees e (ii) lida com uma grande quantidade de cenrios documentados na literatura [Castor et al. 2009].

2. Motivao
Nos ltimos anos, muitos trabalhos tm focado no desenvolvimento de catlogos de refatoraes, tcnicas e ferramentas voltados para POA [Binkley et al. 2006, Cavalcanti 2009, Cole e Borba 2005, Laddad 2003, Monteiro e Fernandes 2005]. Alguns desses trabalhos incluem refatoraes especficas para a extrao de tratamento de exceo para aspectos. Em alguns casos [Laddad 2003] nem as pr-condies nem a mecnica dessas refatoraes so explicadas, o que torna difcil utiliz-las na prtica. Em outros [Cole e Borba 2005], em consequencia da nfase no rigor da preservao do comportamento dos programas-alvo de refatoraes, as pr-condies destas so bastante restritivas. Binkley et al. [Binkley et al. 2006] descrevem uma ferramenta chamada AOPMigrator que automatiza a aplicao dessa refatorao. Porm, esta ferramenta permite tal refatorao apenas em um conjunto restrito de situaes. Tais situaes so justamente as mais simples, aquelas onde o auxlio de uma ferramenta menos importante. O nico cenrio de tratamento de excees que a AOPmigrator cobre quando temos um bloco try-catch englobando todo o mtodo, porm existem vrios outros cenrios que a refatorao no poderia ser feita usando-se o AOPMigrator. Um exemplo comum disso se encontra na Figura 1, onde existe um lao e, dentro do lao, um tratador de exceo que usa o comando break. Ferramentas e refatoraes existentes ou no permitiriam a extrao desse tratador (melhor) ou realizariam a refatorao de forma errnea (pior), alterando o comportamento do programa. Situaes similares ocorrem quando h um return dentro do bloco catch e em algumas situaes onde o bloco try-catch est emaranhado, ou seja, misturado com o restante do cdigo do mtodo.

Figura 1 Exemplo de tratamento de excees no coberto pelas ferramentas existentes.

3. AssistME
AssistME um plugin para a IDE Eclipse1, de cdigo aberto, cujo objetivo fornecer suporte atividade de refatorao de tratamento de excees. Esta ferramenta permite que o desenvolvedor visualize mais rapidamente os fatores relevantes para a extrao de tratamento de excees de Java para AspectJ. Por meio destes fatores o desenvolvedor pode realizar a refatorao de modo a melhorar a qualidade do cdigo e evitar que o comportamento do programa seja modificado. Vale ressaltar que h refatoraes largamente automatizadas por ferramentas que, quando aplicadas sem cuidado, podem introduzir bugs em um programa.
1 http://www.eclipse.org

38

Para realizar refatoraes, os desenvolvedores devem observar atentamente fatores como os descritos nesta seo. Alguns destes fatores so difceis de perceber e, se no levados em conta, podem causar erros sutis. Por causa disso, AssistME enfatiza a realizao dessas anlises em detrimento da transformao propriamente dita do cdigo. Essa abordagem consistente com a viso de trabalhos recentes que afirmam que a transformao do cdigo a parte mais fcil da aplicao de uma refatorao [Ekman, et al. 2008]. Alm disso, ferramentas de refatorao em geral no indicam para usrios de forma explcita que elementos precisam ser levados em conta para que a refatorao possa ser realizada. No caso da extrao de tratadores de excees para aspectos, essa informao fundamental porque muitas vezes o usurio pode decidir no realizar a refatorao em certas situaes, j que no traria benefcios para a qualidade do programa [Castor et al. 2009]. AssistME desenvolvida partindo do pressuposto de que, quando possvel, o ideal fazer com que o advice tratador englobe todo o corpo do mtodo onde aparecia, j que esta a soluo mais simples possvel (exige poucas modificaes no cdigo original). Entretanto, h vrios casos onde isso no possvel pois resultaria em um programa com comportamento diferente do original. Um exemplo deste caso encontrado na Figura 2, onde temos um bloco try-catch que est misturado com o cdigo, e fora dele o comando throwException() lana uma exceo que se o bloco try-catch englobasse todo o mtodo iria ser capturado erroneamente pelo bloco catch. AssistME indica as causas para esse tipo de situao, evitando que programadores cometam erros durante o processo de refatorao. Exemplos de fatores apontados pela ferramenta incluem: (i) emaranhamento de blocos try-catch, pois os comandos que vm antes e depois de tais blocos podem lanar excees capturadas acidentalmente por um advice que englobe todo o mtodo; (ii) aninhamento de blocos try-catch quando um bloco try-catch se encontra dentro de um bloco try; (iii) escrita e leitura de variveis locais, atributos de classes e parmetros de mtodos, alm de invocaes de mtodos; e (iv) informaes sobre as excees, inclusive as no verificadas, lanadas por cada comando. Castor et al. [Castor et al. 2009] apresentam uma lista de fatores relevantes. Esta lista foi usada como base no projeto de AssistME.

Figura 2. Exemplo de bloco try-catch englobando todo o mtodo.

Um exemplo de como a AssistME mostra essas informaes est na Figura 3. Neste exemplo o bloco catch contm chamadas a mtodos, realiza leitura e escrita de variveis locais e excees so levantadas, tanto no bloco catch como antes do bloco try. Essas excees so propagadas, o que as tornam informaes que um programador no obteria simplesmente olhando para o cdigo, principalmente as no checadas. importante enfatizar que no est fora de nossos planos ampliar o escopo do AssistME para que, alm de fornecer informaes teis para desenvolvedores, tambm aplique as refatoraes de forma automtica.

39

Figura 3. Exemplo de como a AssistME mostra as informaes.

Na Figura 4 mostrado a ferramenta AssistME em execuo. Nesta Figura esto destacados alguns itens. No nmero 1 esto localizadas as pastas do projeto. O nmero 2 indica a view que mostrada para o usurio com as informaes coletadas do projeto alvo. Os nmeros 3 e 4 mostram bookmarks que foram criados com a finalidade de facilitar a visualizao do programador em relao aos tratadores que so relevantes para a extrao. Finalmente, o nmero 5 mostra um boto de refresh, para atualizar as informaes da view do AssistME quando o cdigo mudar. Nesta Figura, com a finalidade de exemplificar um resultado real, mostrado os resultados da ferramenta utilizando como exemplo um sistema de informao baseado em Web, o HealthWatcher [Soares et al. 2002].

Figura 4. A ferramenta AssistME em execuo.

Na Figura 5 apresentado um exemplo que contm dois blocos tratadores, um bloco catch e um bloco finally. Todo o bloco try-catch-finally est emaranhado, pois precedido por um comando. O catch contm leitura de varivel local e atributos da classe, e escrita a parmetro do mtodo. Alm disso, como a exceo capturada do tipo java.lang.Exception, a ferramenta emite um alerta informando que esta exceo muito genrica. Este alerta aparece quando a exceo capturada pelo catch do tipo java.lang.Exception ou java.lang.Throwable. O finally contm uma chamada a mtodo que propaga uma exceo. Para facilitar a visualizao do programador, existem bookmarks nos tratadores relevantes. Assim, se houvesse um catch dentro de um bloco tratador, ele no apareceria na view, j que no relevante para a refatorao, pois faz parte do interesse de tratamento de excees.

40

Figura 5. Um exemplo dos resultados produzidos pela AssistME.

4. Viso Geral da Arquitetura

A arquitetura esttica da ferramenta AssistME mostrada na Figura 6. No pacote ControlPlugin se encontra o cdigo responsvel por manipular todo o sistema. Este pacote recebe as entradas do usurio para a execuo da ferramenta e as passa para a classe ProjectProcessor que inicializa o compilador abc [Avgustinov, P. et al. (2005)]. Este ltimo um compilador extensvel para a linguagem AspectJ. Extenses do abc so implementadas por meio das classes ExtensionInfo e AbcExtension. A busca pelos fatores relativos aos blocos try-catch feita na classe FindInformation, que busca todos os cenrios com tratadores de excees utilizando a AST do Polyglot, um dos frontends do abc. O Exception Flow analyzer procura comandos que podem levantar excees, utilizando para tanto o framework de anlise de bytecode Soot. As informaes obtidas so devolvidas para o pacote ControlPlugin e retornadas para o desenvolvedor por meio de uma view.

Figura 6. Arquitetura da ferramenta AssistME

AssistME foi desenvolvida como um plugin para a IDE Eclipse, assim ficando mais vivel para o desenvolvedor utilizar a ferramenta. As caractersticas identificadas so mostradas ao usurio por meio de uma view do Eclipse. Uma alternativa utilizao do abc seria desenvolver a ferramenta como uma extenso do AJDT, um plugin para o Eclipse que visa dar suporte a POA. Esta opo foi preterida, por dois motivos: (i) o abc mais extensvel e (ii) porque o backend (Soot) do abc simplifica muito a realizao das anlises de cdigo (fluxo de excees, em particular) exigidas pela ferramenta. A principal consequncia negativa desta deciso de projeto que caro, em termos computacionais, atualizar as informaes mostradas pela view do AssistME. Alm disso, nem todas as caractersticas da linguagem Java (por exemplo, generics) so implementadas na ltima verso do abc. Da mesma forma, AssistME no trabalha com programas que apresentam tais caractersticas.

5. Agradecimentos
Os autores gostariam de agradecer aos revisores annimos pelos vrios comentrios teis. Cristiane realizou parte deste trabalho com apoio financeiro da FACEPE/Brasil.

41

Fernando parcialmente financiado pelo CNPq/Brasil, 308383/2008-7, e pelo Instituto Nacional de Cincia a Tecnologia para Engenharia de Software, financiado por CNPq e FACEPE, 573964/2008-4 e APQ-1037-1.03/08. Nlio parcialmente financiado pela FAPERN, 013/2009- PPP III.

6. Concluso e Trabalhos Futuros

Visando facilitar a tarefa de refatorao de tratamento de excees, este trabalho apresentou a AssistME, uma ferramenta que foi implementada com o intuito de auxiliar o desenvolvedor na obteno das pr-condies necessrias para extrair para aspectos o tratamento de excees de programas em Java. Pretendemos realizar uma avaliao quantitativa da ferramenta por meio de um experimento controlado, comparando os resultados obtidos por programadores usando e no usando a ferramenta, em termos de tempo total e nmero de enganos cometidos. Alm disso, pretendemos continuar a implementao da mesma para que esta possa fazer as refatoraes automaticamente, no apenas para os casos simples de tratamento de excees, mas para todos os casos que possam ser extrados para aspectos. No endereo http://www.cin.ufpe.br/~fjclf/assistme est disponvel a ferramenta, tanto o jar para a execuo da ferramenta, quanto seu cdigo fonte.

Referncias
Avgustinov, P. et al. (2005). abc : An extensible AspectJ compiler. In proceedings of the 4th international conference on AOSD. Pages: 87 98. D. Binkley et al. (2006). Tool-supported refactoring of existing object-oriented code into aspects. IEEE Transactions on Software Engineering, 32(9). F. Castor et al. (2009) On the modularization and reuse of exception handling with aspects. Softw., Pract. Exper. 39(17): 1377-1417. Diego Cavalcanti (2009) "Improving safety when refactoring aspect-oriented programs". In OOPSLA'2009 Companion, pages 741-742. L. Cole and P. Borba. (2005) Deriving refactorings for aspect. In Proceedings of the 4th ACM Conference on AOSD, pages 123134. Torbjrn Ekman, et al. (2008). Refactoring is not (yet) about transformation. In Proceedings of the 2nd Workshop on Refactoring Tools. R. Laddad. (2003) Aspect-oriented refactoring, parts 1 and 2. The Server Side, www.theserverside.com. Lippert, M e Lopes,C. V. (2000). A study on exception detection and handling using aspect oriented programming. In Proceedings of the 22nd ICSE, 418427, Ireland. M. P. Monteiro e. M. Fernandes (2005). Towards a catalog of aspect-oriented refactorings. In Proceedings of the 4th AOSD, pages 111122. Srgio Soares, Eduardo Laureano, Paulo Borba (2002) "Implementing distribution and persistence aspects with aspectJ". In Proceedings of OOPSLA 2002: 174-190.

42

ComSCId & DMAsp: Identificao de Interesses Transversais e Recuperao de Modelos de Classes Anotados a partir Aplicaes OO Java
Paulo Afonso Parreira Jnior1, Heitor Augustus Xavier Costa2, Valter Vieira de Camargo3 , Rosngela Aparecida Dellosso Penteado4
1, 3, 4

Departamento de Computao Universidade Federal de So Carlos Caixa Postal 676 CEP 13565-905 So Carlos SP Brasil

Departamento de Cincia da Computao Universidade Federal de Lavras Caixa Postal 3037 CEP 37200-000 Lavras MG Brasil
3 4

{ paulo_junior, valter,

rosangela}@dc.ufcar.br,

heitor@ufla.br

Abstract. In this paper is presented two computational supports, called ComSCId and DMAsp, which support, respectively, the automatic identification of crosscutting concerns in OO Java software and the generation of annotated class models with indications of crosscutting concerns. ComSCId provides a rule manager component with a set of previously stored rules for identification of some specific concerns. This component can be customized by adding new rules in order to make this tool works with other kinds of concerns. By using these computational supports, crosscutting concerns can be identified in source code of OO systems in a easier way, making both evolutionary and preventive maintenance more systematic and controlled tasks.

1. Introduo
A programao orientada a aspectos (POA) (Kiczales et al., 1997) uma tecnologia que tem como objetivo encapsular, em unidades especficas chamadas aspectos, interesses (concerns) cuja implementao produz representaes entrelaadas (tangled) e espalhadas (scattered) nos mdulos funcionais do software. Tais interesses so conhecidos como Interesses Transversais e sua identificao e modularizao podem melhorar a qualidade do cdigo fonte produzido e facilitar sua manuteno. Um processo de reengenharia que possui como objetivo a converso de um sistema Orientado a Objetos (OO) para um sistema Orientado a Aspectos (OA) no trivial. Na maioria das vezes, somente o cdigo fonte do software legado est disponvel, fazendo com que o nvel de qualidade das tarefas de manuteno seja prejudicado (Pressman, 2006). importante que seja recuperada a documentao por meio de mecanismos de engenharia reversa o que permite que sejam tomadas decises quanto s modificaes que podem ser realizadas tanto no nvel de modelos quanto, posteriormente, de linguagem de programao. Neste artigo apresentada uma soluo para engenharia reversa de software OO Java que permite recuperar modelos OO anotados com indcios de interesses transversais a partir do cdigo fonte do software. Seu principal objetivo permitir a

Apoio Financeiro CNPq pelo Proc no. 133140/2009-1 Apoio Financeiro CNPq pelo Proc no. 483106/2009-7

43

elaborao de um modelo OO intermedirio antes da obteno de um modelo OA, visando a melhorar a qualidade do processo de reengenharia de software OO para OA. Para isso, so utilizados dois apoios computacionais denominados ComSCId (Computational Support for Concerns Identification) - auxilia na identificao de indcios de interesses transversais em softwares implementados em Java e DMAsp (Design Model for Aspect) - gera modelos de classes OO anotados com indcios de interesses transversais. Este artigo encontra-se organizado da seguinte forma. Os apoios computacionais ComSCId e DMAsp so apresentados nas Sees 2 e 3, respectivamente. Alguns trabalhos relacionados so comentados na Seo 4 e as consideraes finais esto na Seo 5.

2. ComSCId (Computational Support for Concern Identification)

O apoio computacional ComSCId foi desenvolvido como um plug-in do Eclipse e possibilita a identificao de indcios de interesses transversais em um software legado OO implementado em Java. ComSCId emprega duas tcnicas distintas para identificao de interesses: (i) a baseada em texto, que trata do reconhecimento de convenes de nomenclaturas de atributos, mtodos, variveis e classes; e (ii) a baseada em tipo, que trata da identificao de declaraes e usos de determinados tipos e seus objetos. O ComSCId possui a funcionalidade de (i) gerenciar regras para detectar indcios de interesses transversais e (ii) indicar no cdigo fonte do software os trechos que so afetados por esses indcios. 2.1 Gerenciamento de Regras para Identificao de Interesses Transversais A gerncia dos indcios de interesses transversais feita por meio dos seguintes passos: (i) Selecionar a opo Indication da barra de menu principal (Figura 1); (ii) Selecionar a opo Manage...; e (iii) Escolher uma das opes Definir um Interesse Transversal ou Atualizar um Interesse Transversal j Existente ou Excluir um Interesse Transversal j Existente (Figura 2).

Figura 1. Menu principal do plug-in ComSCId Figura 2. Tela para Gerenciamento de Indcios de Interesses Transversais Para melhor ilustrar os passos descritos anteriormente, algumas telas do plug-in ComSCId utilizadas para cadastramento do interesse transversal de persistncia so apresentadas nas Figuras 3 e 4.

44

Figura 3. Tela para Cadastramento das Figura 4. Tela para Cadastramento das Classes Associadas ao Pacote java.sql Regras para Identificao de Convenes de Nomenclatura no Cdigo Fonte Na Figura 3, as classes Date, DriveManager, DriverPropertyInfo, SQLPermission, Time, Timestamp e Types que pertencem ao pacote java.sql so cadastradas como indcios de interesses de persistncia. Na Figura 4 apresentado o cadastramento de regras para capturar strings existente no cdigo fonte quem contenham os conjuntos de caracteres insert into, select, update ou delete from. Essas regras foram criadas, pois a existncia do interesse de persistncia pode ser indicada por meio do uso de comandos em linguagem SQL (Structured Query Language) para insero, atualizao, remoo e consulta a dados. Os passos necessrios para Atualizar um Interesse Transversal j Existente e Excluir um Interesse Transversal j Existente foram omitidos por terem similaridade ao formato apresentado para Definir um Interesse Transversal. Os indcios de interesses transversais originalmente contemplados pelo ComSCId so: i) persistncia em banco de dados (database persistence); ii) controle registro de informaes (logging); e iii) persistncia em memria temporria (buffering). Para cada projeto Eclipse, um diretrio indications criado contendo um arquivo chamado indications.xml. Esse arquivo armazena os indcios de interesses e suas regras para identificao cadastradas pelo engenheiro de software. Assim, cada aplicao tem seu conjunto especfico de regras para deteco de indcios de interesse. H tambm a possibilidade de importar um conjunto de regras de outra aplicao. Isso pode ser feito copiando o arquivo indications.xml do software fornecedor do conjunto de regras para a pasta do software que utilizar essas regras. 2.2 Indicao de Indcios de Interesse Transversal no Cdigo Fonte A deteco dos indcios de um determinado interesse transversal realizada quando a aba Indications (Figura 1) selecionada. Na Figura 5 so apresentadas as diferentes vises dos indcios de interesse de persistncia identificados pelo ComSCId em uma classe denominada Conta. Essa classe permite a realizao de operaes bancrias bsicas como depsito, saque e transferncia e entrecortada pelo interesse de persistncia. Os resultados da identificao de indcios so mostrados na viso de rvore de indcios (Figura 5 - a) ou por meio dos pequenos smbolos em forma de prancheta localizados ao lado da linha de cdigo que possui o indcio (Figura 5 - b).

45

(a)

(b)

Figura 5. Diferentes vises dos Indcios de Interesses identificados pelo ComSCId (a) rvore de indcios; (b) cdigo fonte. Durante a identificao de interesses transversais em um software, alguns enganos podem ocorrer, como a identificao de falsos positivos e/ou falsos negativos. Devido a restrio de espao, esse assunto no ser detalhado neste artigo. Mais informaes podem ser encontradas em (Parreira Junior, 2010).

3. DMAsp (Design Model to Aspect)

DMAsp consiste de um plug-in para Eclipse que estende a funcionalidade do ComSCId, representando os indcios de interesses transversais em modelos de classe da UML. Os indcios de interesses transversais so representados por meio de esteretipos associados s classes, atributos e mtodos. A obteno do modelo de classes anotado com indcios de interesses transversais feita por meio dos seguintes passos: (i) Selecionar a opo Reverse Engineering da barra de menu principal do plug-in DMasp (Figura 6); (ii) Selecionar a opo Generating Annotated OO Class Model. Na Figura 7 apresentado o modelo de classe recuperado a partir do cdigo fonte da classe Conta (Figura 5).

Figura 6. Menu principal do plug-in DMasp

Figura 7. Classe Conta afetada pelo interesse de persistncia.

possvel observar que o atributo connection e os mtodos sacar() e depositar() apresentam esteretipos do tipo <<DatabasePersistence>> indicando que eles so afetados pelo interesse de persistncia. A existncia de pelo menos um elemento de classe (mtodo ou atributo) com esteretipo <<DatabasePersistence>> implica que essa classe tambm receber esse esteretipo. Salienta-se que atributos, mtodos e classes/interfaces podem receber mais de um esteretipo, por exemplo, <<DatabasePersistence>> e <<Logging>>. As informaes necessrias para gerar o modelo de classes so armazenadas em um arquivo XML (XMLModel.xml). Esse arquivo obtido aps a execuo do

46

ComSCId e independente de qualquer ferramenta CASE. Alm do arquivo XML, um arquivo XMI criado usando as informaes presentes no arquivo XMLModel.xml. No arquivo XMI as informaes encontram-se organizadas de modo que esse arquivo possa ser importado na ferramenta CASE Astah*/Community1. Para transformar o arquivo XMLModel.xml no arquivo XMI foi utilizado um arquivo XSL (eXtensible Stylesheet Language for Transformation). Esse arquivo permite a reorganizao das informaes existentes no arquivo XML para atender as especificidades do formato reconhecido pela ferramenta Astah*. A ferramenta CASE Astah* foi escolhida, pois ela tem-se apresentado robusta e bem completa. Astah* apresenta compatibilidade com a verso 2.1 da UML. Alm disso, Astah* possui uma distribuio gratuita chamada Astah*/Community. Para gerar modelos de classes que possam ser lidos por outras ferramentas, deve-se criar apenas o arquivo XSL que possibilite reorganizar as informaes existentes no arquivo XMLModel.xml segundo o formato exigido pela ferramenta CASE desejada.

4. Trabalhos Relacionados
JQuery (Janzen and Volder, 2003) permite a busca de subconjuntos especficos de elementos do cdigo fonte e pode ser utilizada na identificao de indcios de interesses. Garcia et al., (2004) propuseram uma abordagem para Reengenharia de Sistemas OO para OA baseada em transformaes e minerao de aspectos. Com o enfoque diferente das demais ferramentas apresentadas, AOP Migrator (Binkley et al., 2006) faz a refatorao de softwares em Java de modo iterativo. Sua instalao depende de verses antigas do IDE Eclipse e do plug-in AJDT. Robillard and Murphy (2007) apresentaram um modelo de grafo de interesses para representar os interesses existentes em um software OO. Alm disso, foi desenvolvida uma ferramenta (FEAT Feature Exploration and Analysis Tool) que permite identificar de forma semi-automtica os interesses do software e criar uma instncia correspondente do grafo de interesses. A principal desvantagem dessas abordagens refere-se customizao das regras para identificao de indcios de interesses. Por exemplo, para definir novas regras, o engenheiro de software precisa conhecer a linguagem utilizada para reconhecimento de padres do FEAT ou do JQuery, o que torna o processo de identificao desses interesses mais custoso e mais propenso a erros. Nesse sentido, a rvore de indcios e os assistentes existentes em ComSCId apresentam maior facilidade de uso e maior enfoque nas atividades de identificao de indcios. Outra vantagem do ComSCid em relao s abordagens apresentadas que ele pode ser integrado s verses mais atuais do ambiente de desenvolvimento Eclipse. Em relao ao DMasp, h poucos trabalhos que realizam a engenharia reversa para obteno de Modelos de Classes OA a partir dos cdigos de softwares OO. Yang et al., (2008) propuseram um framework de engenharia reversa orientado a aspectos para ser acoplado na ferramenta XDRE, criada pelos prprios autores, que recupera parcialmente diagramas UML de cdigo C++. Este framework usa esteretipo e gera modelos para a ferramenta CASE Rational Rose. O foco dessa abordagem est na anlise de requisitos, usa software legado escrito em C++ e no apresenta a construo de um Diagrama/Modelo de Classes.
1

http://astah.change-vision.com/en/product/astah-community.html

47

5. Consideraes Finais
Neste artigo foram apresentados dois apoios computacionais denominados ComSCId e DMAsp, que auxiliam desenvolvedores/mantenedores na tarefa identificao de indcios de interesses transversais e na recuperao de modelos de classes OO anotados com esses indcios a partir de um software OO implementado em Java. A gerao de um Modelo de Classes OO Anotado pode trazer benefcios para o processo de reengenharia de software, como (i) facilita a visualizao dos interesses transversais existentes no software e de seu nvel de espalhamento/entrelaamento com os demais mdulos do software; (ii) permite ao engenheiro de software responsvel pela reengenharia de software OO para OA articular e raciocinar como projetar os interesses transversais identificados; e (ii) minimiza o gap semntico existente entre o cdigo fonte de um software OO e um modelo OA. DMasp gera apenas diagramas de classes, porm, como trabalho futuro, pretende-se estender esse apoio computacional para permitir a obteno de outros diagramas, por exemplo o de sequncia. Salienta-se que os apoios computacionais apresentados nesse artigo so software livre e esto disponveis para download juntamente as instrues para sua instalao por meio do link: http://www.dc.ufscar.br/~paulo_junior.

Referncias Bibliogrficas
Janzen, D., and Volder, K. D. Navigating and querying code without getting lost. In: Aspect-Oriented Software Engineering, pages 178-187. ACM (2003). Garcia, V. C., Lucrdio, D., Prado, A. F. do, Piveta, E. K., Zancanella, L. C., Almeida, E. S. de, and Alvaro, A. Reengenharia de sistemas orientados a objetos atravs de transformaes e minerao de aspectos. Portuguese/Spanish Tracks In the Third International Information and Telecommunication Technologies Symposium (I2TS'2004), So Carlos, SP Brazil (2004). Binkley, D., Ceccato, M., Harman, M., Ricca, F., and Tonella, P. Tool- Supported Refactoring of Existing Object-Oriented Code into Aspects. In: IEEE Transactions on Software Engineering, vol. 32, n. 9 (2006). Robillard, M. P.; Murphy, G. C. Representing Concerns in Source Code. ACM Transactions on Software Engineering and Methodology, 16(1):1-38 (2007). Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C., Loingtier, J., Irwin, J. Aspect-Oriented Programming. 11th European Conference on Object-Oriented Programming. v. 241 de LNCS, p. 220-242. Springer-Verlag (1997). Parreira Jnior, P. A.; Costa, H. A. X.; Camargo, V. V.; Penteado, R. A. D. Uma Abordagem Iterativa para Identificao de Interesses Transversais com o Apoio de Modelos de Classes Anotados. In: IV Latin American Workshop on AspectOriented Software Development (LA-WASP 2010), 2010, Salvador/BA. I Congresso Brasileiro de Software: Teoria e Prtica, CBSoft, 2010. Pressman, R. S. (2006) Engenharia de Software. 6 edio. McGraw-Hill, 752 p. Yang, S.; Xuan-wu, Z.; Min-qing, Z. Approach on Aspect-Oriented Software Reverse Engineering at Requirements Level. In: International Conference on Computer Science and Software Engineering, p 321-324, 2008.

48

FERRARE GT: Automao de Testes de Desempenho e Estresse via Testes Funcionais

Ismayle de Sousa Santos1, Alcemir Rodrigues Santos1, Pedro de Alcntara dos Santos Neto1
1

Departamento de Informtica e Estatstica Universidade Federal do Piau (UFPI) Campos Ininga Teresina PI Brasil
{ismayle,alcemir,pasn}@ufpi.edu.br

Abstract. Non-functional requirements validation tests are still poorly run. Some causes of this are lack of skilled personnel, high cost and difficulty in meeting deadlines. On the other hand, with the Web systems predominance is increasingly needed this testing. This paper presents an automatic generation of performance and stress testing tool. The tool named FERRARE GT generates both tests and data reusing the information related to the functional testing once performed. Resumo. Os testes para validao de requisitos no-funcionais ainda so pouco executados na maioria das organizaes. Muitas so as causas, dentre elas, a falta de pessoal especializado, alto custo e dificuldade no cumprimento dos prazos. Por outro lado, com a predominncia de sistemas Web, cada vez mais so necessrios a realizao de tais testes. Neste trabalho apresentada uma ferramenta para a gerao automtica de testes de desempenho e estresse. Alm de gerar testes para requisitos no funcionais, a ferramenta, denominada FERRARE GT, gera os registros no banco de dados a serem utilizados na execuo dos testes, a partir de informaes relacionadas aos testes funcionais.

1. Introduo
Com os usurios cada vez mais exigentes e o mundo cada vez mais globalizado, a qualidade de um software deixou de ser um diferencial para se tornar um requisito essencial de qualquer aplicao. Dessa forma, o Teste fator chave para o sucesso de um projeto de software, seja qual for o processo utilizado. Apesar de necessria, em geral, a realizao de testes de software no tem sido executada da forma ideal. Nem todos os requisitos de um software so corretamente validados. Um fator de peso que contribui para essa situao diz respeito aos custos dessa atividade, os quais podem chegar a mais de 50% do custo total de um projeto [Pressman 2006]. Assim, ferramentas que automatizem a realizao de testes contribuem para reduzir os custos possibilitando a execuo apropriada dos mesmos. Uma categoria de teste comum em muitas organizaes o teste funcional. Ele tem como objetivo verificar o comportamento de um software. Outra categoria de testes, a de desempenho, tem como objetivo validar requisitos de desempenho, como por exemplo, o tempo de resposta dentro de um contexto de 100 usurios em rede local.

49

O teste de estresse similar ao teste de desempenho, no entanto, o contexto de execuo elevado para nveis acima do normal. Os testes de desempenho e estresse ainda so pouco executados, ainda que grande parte das aplicaes atuais seja desenvolvida para Web, onde tal tipo de avaliao seria de grande importncia. A partir desse cenrio, observou-se que a criao de um mecanismo que auxiliasse o desenvolvimento de testes de desempenho e estresse a partir de algum artefato comum aos desenvolvedores, poderia resultar na reduo dos custos associados criao dos mesmos. Por serem difundidos e possurem boa parte das informaes necessrias, escolheu-se os testes funcionais como sendo este artefato e desenvolveu-se a FERRARE [Santos et al. 2008]. Este prottipo inicial possibilitava a gerao de scripts1 de teste de desempenho a partir de scripts de testes funcionais. Entretanto, apesar de auxiliar a implementao dos testes de desempenho e estresse, a FERRARE no continha mecanismos de apoio a execuo dos mesmos quando esses exigiam uma preparao do ambiente de teste. Se o script gerado, por exemplo, tivesse como objetivo a realizao de 100 emprstimos de livros, poderia ser preciso 100 exemplares e 100 usurios cadastrados no banco de dados da aplicao. Desenvolveu-se ento um algoritmo para replicao dos dados utilizados em um teste funcional, possibilitando sua execuo em diversas instncias diferentes [F et. al. 2010]. Este algoritmo foi incorporado ferramenta, doravante denominada FERRARE GT, que descrita neste trabalho. O nome FERRARE acrnimo de FERRamenta para Automao de testes de Requisitos de desempenho e Estresse, enquanto que GT (Genesis Turbo) referencia o mdulo responsvel pela gerao de dados. Existem trabalhos que propem a gerao de testes de desempenho atravs de modelos [Shams et. al. 2006]. Por outro lado, Bertolini et. al. (2009) propuseram quatro tcnicas de testes de caixa preta cujo objetivo derrubar o sistema com a gerao e execuo automtica de testes de GUI (Graphical User-Interface). O trabalho apresentado neste artigo se diferencia por no utilizar modelos e por utilizar scripts de testes funcionais para gerar scripts de teste de desempenho, os quais sero executados na ferramenta de teste de desempenho para a qual ele foi gerado.

2. Detalhes da arquitetura
A FERRARE GT uma aplicao desktop desenvolvida em Java e cuja arquitetura apresentada na Figura 1.Ela composta pelos mdulos: Extractor, Generator e Genesis. O mdulo Extractor responsvel por receber como entrada um script de teste funcional, desenvolvido em alguma ferramenta de teste funcional, e gerar, a partir desse script, uma representao abstrata do mesmo independente da tecnologia associada sua criao. As principais classes associadas a essa representao so: TestCase, representando um caso de teste; TestProcedure, representando um procedimento de teste; Input e Output, para descrever as entradas e sadas. A criao dessa representao feita via anlise sinttica do script, observando os comandos utilizados e interpretando suas aes.

Neste caso, se refere a um arquivo gerado por uma ferramenta de apoio ao teste funcional contendo a sequncia de comandos a serem executados durante o teste.

50

Como cada ferramenta de teste funcional possui um conjunto de comandos diferentes, os scripts gerados por tais ferramentas devem ser analisados levando em conta as particularidades inerentes da ferramenta utilizada. Por isso, desenvolveu-se o mdulo Extractor de forma que ele trabalhe com o que foi denominado Cartuchos de Extrao. Esses elementos contm a implementao sobre como deve ser feita a extrao de informaes do script de teste funcional para a representao abstrata utilizada pela FERRARE. Com isso, possvel estender a ferramenta para utilizar scripts de teste feitos em qualquer ferramenta, bastando criar o cartucho associado.

Figura 1: Arquitetura da FERRARE GT.

At o momento esto implementados dois Cartuchos de Extrao: o SeleniumExtractor, referente a ferramenta Selenium IDE2 , e o CanooExtractor, ao Canoo Web Test3. Eles foram implementados porque essas ferramentas so gratuitas e, conforme pesquisas na Web, so bem difundidas dentre a comunidade de teste. No entanto, a insero de novos cartuchos ferramenta simples, bastando estender a classe BaseExtractor e implementar os mtodos de extrao. Feito isso, o arquivo .jar referente ao cartucho deve estar em uma pasta pr-definida para que seja identificado. Aps a criao da representao abstrata de um teste funcional so especificados alguns parmetros para a gerao do teste de desempenho e estresse, tais como o tempo de resposta esperado e quantidade de usurios simultneos. Em seguida, a gerao dos dados pode ser iniciada baseada nos dados utilizados no teste funcional. importante frisar que essa abordagem elimina a necessidade de se ter conhecimento sobre todas as restries relacionadas ao modelo de dados e lgica de negcio da aplicao. Como os dados so replicados a partir das entradas existentes em um teste funcional e cuja instncia do banco de dados deve estar apta a executar, rplicas geradas a partir desses dados tambm devero manter a mesma propriedade. A Genesis subdividida em: Mapper e DataReplicator. O Mapper tem por objetivo auxiliar o testador a indicar o mapeamento entre os campos de uma Interface de Usurio (IU), utilizados em um teste funcional, com as respectivas colunas do banco de dados. Essa ligao permite identificar quais dados precisam ser replicados. Assim, se
2 3

http://seleniumhq.org/ http://webtest.canoo.com/

51

um teste funcional para um emprstimo em um sistema de uma biblioteca utiliza como dados de entrada a matrcula de um usurio e o cdigo de um livro, o Mapper requer que o testador indique com quais colunas das tabelas do banco de dados tais entradas esto associadas, conforme ilustrado na Figura 2. Com isso, possvel iniciar uma varredura no banco, replicando os dados a partir dos registros associados ao teste.

Figura 2: Mapeamento entre campos da IU e atributos do banco.

Ao final do processo de mapeamento, o mdulo DataReplicator pode ser iniciado. Para cada registro do banco associado ao teste funcional gerada uma rplica. Se houver associao de outros registros ao registro replicado, esses tambm so replicados de forma que todos os dados sejam corretamente gerados e, assim, mantmse a consistncia para uso no teste de desempenho e estresse. Um exemplo para ilustrar o processo de gerao seria a rplica dos dados de um exemplar associado a um livro. Para que sua rplica seja considerada correta, a ferramenta deve replicar no somente os dados do Exemplar, como tambm os dados do Livro associado ao Exemplar, gerando assim dois novos registros (exemplar e livro), ao invs de gerar apenas um novo Exemplar. Esse processo repetido at que sejam gerados dados suficientes para o contexto do teste, que depende diretamente do nmero de instncias desejadas para execuo (por exemplo, 100 usurios simultneos). Ressalta-se que o algoritmo de replicao desenvolvido (descrito com mais detalhes em [F et al. 2010]), faz o tratamento de relacionamentos entre tabelas, bem como segue as restries especificadas no schema do banco, como por exemplo, a unicidade de valores ou formatos especficos. Ao final da gerao dos dados, estes so disponibilizados para a mdulo Generator, de forma que os testes de desempenho e estresse possam ser gerados levando-os em considerao. O Generator tem por objetivo gerar os scripts de testes de desempenho e estresse para alguma ferramenta especfica. Vale ressaltar que a FERRARE GT no executa tais testes, ela gera os scripts de testes para execuo na ferramenta desejada. Dessa forma, questes como a restaurao do banco ao estado inicial antes da execuo dos testes no so contempladas pela ferramenta. Antes de criar o script, os testes de desempenho e estresse so gerados em uma representao interna da FERRARE GT, independente de ferramentas de teste de desempenho e estresse. Tal representao

52

composta com um conjunto de classes utilizadas para descrever um script de teste de desempenho independentemente de comandos especficos. O Generator utiliza o mesmo conceito de Cartuchos utilizados pelo Extractor. Para a gerao de scripts de teste de desempenho e estresse o testador deve indicar qual o Cartucho de Gerao a ser utilizado. Os Cartuchos de Gerao so classes Java que devem seguir convenes da FERRARE GT e devem implementar alguns mtodos inerentes. Dessa forma, o Generator pode gerar um teste de desempenho e estresse para qualquer ferramenta, desde que seja implementado o cartucho adequado. Isso permite uma fcil extenso da ferramenta.

3. Funcionamento
O funcionamento da FERRARE GT pode ser resumido conforme apresentado na Figura 3: i) inicialmente, o testador cria um script de teste funcional; ii) em seguida, o testador submete o teste ao Extractor, indicando o Cartucho de Extrao adequado, para que uma representao abstrata seja criada; iii) o Mapper solicita ao testador que faa o mapeamento das entradas existentes no teste funcional e as respectivas colunas no banco de dados da aplicao; iv) o testador informa os dados relacionados ao contexto da execuo dos testes de desempenho ou estresse e o cartucho de gerao a ser utilizado; v) o DataGenerator acionado para gerar a quantidade de dados necessria, replicando os registros existentes no banco relacionados ao teste funcional submetido como entrada; vi) o Generator acionado para gerar os scripts de testes de desempenho e estresse; vii) com os scripts gerados, o testador pode executar os testes com a ferramenta apropriada.

Figura 3: Esquema geral do Funcionamento da FERRARE GT.

Foi realizado um experimento para verificar se o uso da FERRARE GT reduz o tempo de implementao e execuo de testes de desempenho e estresse. Verificou-se com o experimento e atravs do teste t de student que os tempos gastos para realizao destes testes com e sem a FERRARE GT so diferentes e que a ferramenta de fato reduz o tempo gasto nessa atividade.

53

4. Limitaes
A FERRARE GT ainda possui limitaes: i) seu funcionamento se restringe a aplicaes que utilizem o sistema de gerenciamento de banco de dados MySQL; ii) a replicao de certos tipos de dados como dados criptografados e dados geogrficos no suportada; iii) existem restries para a gerao de dados com formatos especficos (tais como CPF, CNPJ); iv) os scripts de testes de desempenho no so gerados corretamente caso o script de teste funcional no possua uma indicao das URLs acessadas; v) a gerao do teste baseia-se em um nico teste funcional, no representando de forma apropriada alguns cenrios de execuo interessantes; vi) o mapeamento ainda depende muito da interveno humana. Boa parte destas limitaes esto sendo resolvidas nas extenses da ferramenta.

5. Concluses e Trabalhos Futuros

Neste trabalho foi apresentada uma ferramenta para a gerao de testes de desempenho e estresse a partir de testes funcionais, denominada FERRARE GT. A ideia bsica da ferramenta reaproveitar as informaes existentes nos testes funcionais, de forma que tanto os testes de desempenho e estresse, como os dados necessrios para sua execuo, sejam automaticamente gerados. A ferramenta j foi submetida a uso por diversos usurios, tendo sido inclusive objeto de um estudo experimental. Nesse estudo ficou caracterizado que seu uso em uma organizao que j realize o teste funcional pode trazer reduo de esforo a partir da automao dos testes de desempenho e estresse. A ferramenta est disponvel para testes no stio http://www.ufpi.br/pasn, sob a licena GNU LGPL (Lesser General Public License). Como trabalhos futuros tem-se a resoluo das limitaes mencionadas na Seo 4, bem como a implementao de novos extratores e geradores.

Referncias
Pressman, R. (2006). Engenharia de Software. McGraw-Hill, 6th edio. Santos, I. S. ; Araujo, F. F. B. ; Bezerra, R. S. ; Santos Neto, P. (2008). FERRARE FERRamenta de Automao dos testes de Requisitos de desempenho e Estresse. In: Anais do II Escola Regional De Computao Cear Maranho Piau, So Luiz, MA. F, I. S. et al. (2010). Gerao de Dados para Testes de Desempenho e Estresse a Partir de Testes Funcionais. In: Anais do IX Simpsio Brasileiro de Qualidade de Software, p. 89-101, Belm, PA. Shams, M.; Krishnamurthy, D.; e Far, Behrouz (2006). A Model-Based Approach for Testing the Performance of Web Applications. In: Proceedings of the 3rd International Workshop on Software Quality Assurance, p. 5461, Portland, Oregon. Bertolini, C.; Peres, G.; d'Amorim, M.; Mota, A. (2009). An Empirical Evaluation of Automated Black Box Testing Techniques for Crashing GUIs. In Proceedings of the 2nd International Conference on Software Testing Verification and Validation, p. 2130, Los Alamitos, CA, USA.

54

ModelT2: Apoio Ferramental Gerao de Casos de Testes Funcionais a partir de Casos de Uso
Priscila P. B. Albuquerque, Jobson L. Massollar, Guilherme H. Travassos Programa de Engenharia de Sistemas e Computao COPPE/UFRJ Caixa Postal 68511 21.941-972 Rio de Janeiro RJ Brasil.
{priscila,jobson,ght}@cos.ufrj.br

Abstract. The increase in effort and cost required for the development of contemporary software systems has motivated the pursuit for alternatives that could reduce these factors without compromising the final product quality. In this scenario, the combination of testing and development models with tools integrating these models emerges as an opportunity to achieve such reduction goals. Therefore, in this paper a tool called ModelT2 that uses the concept of model-to-model transformation is described. It aims to support the semiautomatic derivation of Test-cases and Test-procedures for system testing from its functional specification with Use Cases.

1. Introduo
O Teste de Software tem por objetivo identificar defeitos presentes em determinado produto atravs da sua anlise dinmica, ou seja, atravs da sua execuo. Essa execuo tem como meta revelar falhas no produto, permitindo, assim, que as devidas correes tornem o produto mais confivel e garantindo sua qualidade [Dias Neto e Travassos 2006]. Tcnicas de Teste de Software podem ser aplicadas em diferentes nveis de abstrao. Mais especificamente, o Teste de Sistema ou Teste Funcional tem por objetivo executar o software do ponto de vista dos seus usurios finais, intencionando revelar falhas em relao aos requisitos previamente estabelecidos. Nesse caso, a estrutura ou o comportamento interno do sistema no representam o foco principal de avaliao, mas sim os resultados obtidos atravs da execuo das suas funcionalidades. Levando-se em considerao que as atividades relacionadas aos testes do software esto entre as mais custosas do processo de desenvolvimento [Juristo et al. 2004], uma das condies necessrias para sucesso reside no planejamento cuidadoso dos testes. Esse planejamento vital para que, dentre outros fatores, as funcionalidades identificadas nos documentos de requisitos do software sejam executadas sob todas as condies e regras definidas pelos requisitos, evitando-se assim parcialidade nos testes. Dentro do Plano de Testes, os Casos de Teste definem o conjunto de dados a serem aplicados e os resultados esperados, enquanto os Procedimentos de Testes referenciam os Casos de Teste e definem os passos para a execuo efetiva dos testes [Myers 2004]. No contexto de Teste Baseado em Modelos (MBT Model Based Testing) [Apfelbaum 1997], modelos so usados para descrever os vrios elementos relacionados ao Teste de Software, dentre eles os casos e procedimentos de teste. Em relao ao Teste de Sistema, esses modelos so obtidos a partir das especificaes funcionais do sistema. A partir da aplicao dos conceitos de Desenvolvimento Dirigido por Modelos (MDD - Model Driven Development) [France et. al. 2007] para a gerao de modelos que descrevem os aspectos funcionais do sistema com base em Casos de Uso, surgiu a oportunidade de definir uma ferramenta, denominada ModelT2 (Model Transformation for Testing), para apoiar a derivao semi-automtica dos modelos de teste a partir de modelos funcionais e, a partir destes, a derivao dos casos e procedimentos de teste.

55

Algumas abordagens na literatura exploram a gerao dos procedimentos de teste a partir de casos de uso e modelos de teste [Hartmann 2005; Gis et. al. 2010]. Nestes casos, porm, o Analista de Teste possui a inteira responsabilidade de criar os modelos de testes, pois estas abordagens no definem como construir estes modelos a partir da especificao dos requisitos. Esta tarefa normalmente apoiada por alguma ferramenta para a definio dos modelos de teste. A proposta aqui apresentada difere dessas abordagens por definir um conjunto de regras que permite derivar o modelo de testes a partir do modelo de caso de uso. ModelT2 implementa este conjunto de regras, e produz de forma semi-automtica o modelo de testes funcionais. Esse artigo est organizado em 7 sees, incluindo esta introduo. Na seo 2 so descritos o projeto e a arquitetura de ModelT2. Nas sees 3, 4 e 5 so apresentados os detalhes de cada fase do processo de derivao. A seo 6 apresenta a avaliao da ferramenta e, por fim, a seo 7 descreve as concluses e trabalhos futuros.

2. Projeto e Arquitetura de ModelT2

A proposta de concepo de ModelT2 surgiu a partir de pesquisas sobre um metamodelo UML para descrio de Casos de Uso, denominado UCModel, conduzidas pelo grupo de Engenharia de Software Experimental da COPPE/UFRJ. Esse metamodelo explora, principalmente, extenses do Diagrama de Atividades da UML 2 (www.omg.org/spec/UML/2.3/) para descrever os aspectos dinmicos dos Casos de Uso. O Modelo de Testes, por sua vez, foi descrito segundo o metamodelo de TDE (Test Development Environment) [Hartmann 2005] que tambm usa o Diagrama de Atividades da UML para descrever casos e procedimentos de testes funcionais com base em Casos de Uso. A escolha do TDE se deu por oportunidade e convenincia, devido ao conhecimento prvio dos pesquisadores sobre esse modelo e a facilidade de acesso devido colaborao existente entre o grupo ESE e a Siemens Corporation Research/USA, proprietria da ferramenta TDE/UML, capaz de manipul-lo. A partir dos metamodelos comentados anteriormente, a arquitetura de ModelT2 e o seu contexto de atuao podem ser visualizados na Figura 1. Nessa figura podemos notar que ModelT2 atua, inicialmente, sobre o Modelo de Casos de Uso (MCU) derivando a partir deste o Modelo de Testes (MT). A partir do MT so gerados, ento, os Casos e Procedimentos de Teste (CPT). Com o objetivo de aumentar a independncia de ModelT2 de uma ferramenta UML especfica, foi adotado o padro XMI 2.1 (www.omg.org/spec/XMI/2.1.1/) como formato para descrio do MCU e do MT.

Figura 1. Arquitetura e contexto de atuao de ModelT2

56

ModelT2 possui quatro elementos principais: 1) mdulo de transformao MCUMT: aplica as regras definidas para derivao do Modelo de Testes a partir do Modelo de Casos de Uso; 2) mdulo de transformao MTCPT: aplica as regras para derivao dos Casos e Procedimentos de teste a partir do Modelo de Testes; 3) regras para transformao MCUMT, e; 4) regras para transformao MTCPT. importante notar que a criao do MCU no faz parte da arquitetura de ModelT2, mas sim do contexto onde ela atua. A infra-estrutura para criao do MCU est baseada na ferramenta BOUML (http://bouml.free.fr), sobre a qual foi definido um profile UML para o metamodelo UCModel e um plug-in, denominado Use Case Agent, para apoiar a gerao do MCU. A ferramenta BOUML foi escolhida por se tratar de uma ferramenta de uso livre, cdigo aberto, compatvel com a especificao UML 2 da OMG e que permite tanto a definio de profiles UML bem como o desenvolvimento de plug-ins em C++ ou Java para extenso das suas funcionalidades. O detalhamento dessa infra-estrutura est fora do escopo deste artigo. A utilizao de ModelT2 se d em trs fases bem distintas que sero detalhadas nas sees a seguir.

3. Derivao do Modelo de Testes

Nessa fase o Analista de Testes utiliza o Mdulo de Transformao MCUMT. Esse mdulo permite que o usurio defina: 1) o MCU de entrada; 2) os Casos de Uso dentro do MCU para os quais ele deseja gerar os casos e procedimentos de testes, e; 3) o padro do MT a ser gerado (padro XMI 2.1 ou padro TDE, conforme Figura 1). As regras para derivao MCUMT foram formalizadas usando o padro QVT (Query-View-Transformation) (www.omg.org/spec/QVT/1.1/Beta2/). Entretanto, a transformao propriamente dita foi implementada com a linguagem XSLT (www.w3.org/TR/xslt). XSLT foi escolhida pelo conhecimento prvio dos pesquisadores e por atender aos requisitos estabelecidos e relacionados transformao dos modelos. A utilizao de TDE/UML permite executar o passo 3a da Figura 1. Entretanto, de forma a tornar mais geral o uso desta tecnologia, j se encontra em desenvolvimento a derivao do CPT pela prpria ModelT2 (passo 3b da Figura 1), facilitando assim a utilizao de outras ferramentas por aqueles que no tenham acesso a TDE/UML.

Figura 2. Exemplo de uma descrio de Caso de Uso

57

A Figura 2 apresenta um exemplo de um caso de uso descrito com o metamodelo UCModel. Essa abordagem explora os fluxos de controle do Diagrama de Atividades da UML 2 para descrever as seqncias de passos do caso de uso (principal, alternativos e de exceo) e o fluxo de dados para descrever os tipos abstratos que so produtos ou insumos dos diversos passos. Cada passo do caso de uso pode ser definido como uma ao do ator, uma ao do sistema ou uma resposta do sistema. importante destacar que o modelo da Figura 2 no foi criado visando unicamente a gerao de testes funcionais, pois ele no representa um modelo de testes. Esse modelo representa a dinmica do caso de uso e ser usado para derivar o modelo de testes. Da mesma forma, outros modelos, destinados a outras fases do desenvolvimento do produto, tambm podem ser derivados. Uma vantagem dessa abordagem que os casos de uso podem ser descritos usando qualquer ferramenta aderente especificao UML 2 e que trabalhe com profiles UML. A Figura 3 representa o MT derivado a partir do MCU apresentado na Figura 2. Repare que as aes do sistema presentes no modelo da Figura 2 (destacadas em cinza) no so representadas no MT, pois o metamodelo do TDE retrata apenas as aes do ator e as respostas do sistema, no importando as aes internas do mesmo.

Figura 3. Exemplo de um Modelo de Testes derivado por ModelT2

4. Complementao do Modelo de Testes

Nessa fase o Analista de Testes complementa o MT acrescentando informaes necessrias para a derivao do CPT a partir deste. Em um cenrio ideal, o MCU deveria ser suficientemente completo para apoiar a gerao do MT de forma automtica, ou seja, sem a necessidade de nenhum tipo de interveno do Analista de Testes para obteno do MT. No entanto, existem limitaes para essa derivao automtica, uma vez que h diferenas significativas relacionadas ao prprio objetivo de cada um desses modelos e ao tipo da informao que deve ser capturada em cada caso. Um exemplo dessa diferena est na existncia, no MT, de categorias e seus respectivos valores a partir dos quais so definidos os casos de teste. Esse tipo de informao existe no MCU, mas no est necessariamente explcita e formalizada a ponto de permitir uma transformao automtica. Nesse caso o MT deve ser complementado com as respectivas categorias e seus valores, antes da gerao do CPT.

58

Para auxiliar na complementao do MT, o processo de derivao extrai algumas informaes do MCU e, baseado em algumas heursticas, cria candidatos a categorias e dicas para gerao de valores, da seguinte forma: 1) gera candidatos a categorias baseando-se nos fluxos de dados gerados/consumidos pelas aes descritas no MCU; 2) gera comentrios associados aos pontos de deciso baseando-se nas condies que definem os possveis desvios no fluxo de controle; 3) gera comentrios associados s aes baseando-se nas regras de validao que devem ser respeitadas nesse ponto, e; 4) gera comentrios associados s aes baseando-se nas regras a serem observadas nesse ponto. Um exemplo da aplicao dessas heursticas pode ser observado nas categorias e comentrios do MT da Figura 3 (destacados em cinza). Nesse caso, o Analista de Testes complementa o modelo, gerando valores para as categorias login e senha. Nessa tarefa ele poder usar a regra R1 da ao Internauta informa login e senha para gerar valores vlidos (adm@1, adm1$) e valores invlidos (1abc@1, adm@, @123) para login e senha.

5. Derivao dos Casos e Procedimentos de Teste

Nesta fase, o Analista de Testes gera o CPT a partir do MT devidamente complementado. Na verso atual essa transformao realizada pela ferramenta TDE/UML, que j implementa diversas estratgias para percorrer os fluxos de controle presentes no diagrama da Figura 2 e permite a gerao dos casos e procedimentos de teste em vrios formatos. A Tabela 1 ilustra procedimentos e casos de teste, gerados pelo TDE/UML, relativo ao fluxo principal do caso de uso da Figura 2.
Tabela 1. Exemplo de caso/procedimento de testes gerados por ModelT
2

1 2 3 4 5 6 7

Roteiro Descrio Sistema solicita login e senha Internauta informa login e senha Sistema informa login/senha incorretos Apresenta menu Sistema solicita login e senha Internauta informa login e senha Sistema apresenta menu de opes

Passo Proc 1 2 6 Proc 2 2 6 Proc 3 2 6

Login vlido invlido 1abc@1 adm@1 adm@ adm@1 adm@1 adm@1

Senha vlida invlida @123 adm1$ adm1$ adm1$ @123 adm1$

Apesar de sua adequao, o uso de TDE/UML pode representar uma restrio para os testadores que no tem acesso a essa ferramenta em particular. Por isso, visando garantir abrangncia de uso, est sendo construdo, na prpria ModelT2, um mdulo de transformao MTCPT (vide 3b da Figura 1). As regras utilizadas nessa transformao so bastante simples, pois os conceitos e os dados usados na gerao do CPT esto explicitamente representados no MT.

6. Avaliao de ModelT2
O uso de ModelT2 vem sendo avaliado no contexto do projeto de um sistema de informao de larga escala. Nessa prova de conceito, os prprios pesquisadores tm usado ModelT2 para gerar os casos de teste e os resultados indicam a viabilidade de uso da mesma no projeto. Entretanto, esses resultados no podem ser generalizados, pois apenas os prprios pesquisadores tm feito uso sistemtico da ModelT2. Por isso, est prevista, para o 2 semestre de 2010 no contexto de uma disciplina de ps graduao da UFRJ, uma avaliao complementar com o objetivo de caracterizar, do ponto de vista

59

do desenvolvedor, a percepo de esforo e dificuldade na gerao dos casos de teste usando ModelT2 e entender a diferena na cobertura dos casos de teste gerados pela ModelT2 em relao a outros casos de teste gerados sem apoio ferramental.

7. Concluses e Trabalhos Futuros

Neste artigo foram descritos o projeto e as caractersticas de uma ferramenta, chamada ModelT2, para gerao de casos e procedimentos de teste funcionais a partir de modelos de Casos de Uso. ModelT2 apia-se no uso intensivo de transformaes semiautomticas modelo-modelo e modelo-texto, tendo como base dois metamodelos UML: um para descrio de Casos de Uso (UCModel) e outro para descrio de Casos e Procedimentos de Testes Funcionais baseados em casos de uso (TDE). Assim, ModelT2 visa fornecer, em ltima anlise, um apoio efetivo para a elaborao de parte do Plano de Testes, atravs da reduo do esforo e custo envolvidos na gerao desse artefato essencial para garantia da qualidade do software. Como melhorias futuras podemos destacar: 1. Derivao dos Casos e Procedimentos de Testes Funcionais pela prpria ModelT2, sem a necessidade de uso da ferramenta TDE/UML (em andamento); 2. Gerao dos Casos e Procedimentos de Testes Funcionais em formatos alternativos, como RTF (Rich Text Format), para que possam ser integrados a outros documentos, e; 3. Integrao dos Casos e Procedimentos de Testes Funcionais gerados com a abordagem de Planejamento e Controle de Testes de Software fornecida pela ferramenta Marak [Dias Neto e Travassos 2006]. A ferramenta ModelT2, assim como alguns modelos exemplificando seu uso, pode ser encontrada em http://ese.cos.ufrj.br/arquivos/ModelT2.zip.

Referncias Bibliogrficas
Apfelbaum, L., Doyle, J. (1997), "Model Based Testing", Software Quality Week Conference (QWE), Bruxelas, Blgica. Dias Neto, A. C., Travassos, G. H. (2006), Marak: Uma Infra-estrutura Computacional para Apoiar o Planejamento e Controle de Testes de Software, V SBQS, pp. 250-264, Vila Velha, ES. France R., Rumpe, B., (2007) Model-driven development of complex software: A research roadmap, Future of Software Engineering (FoSE), pp. 37-54. Minneapolis, MN. Gis, F., Farias, P., Oliveira, R. (2010), Test Script Diagram Um modelo para gerao de scripts de testes, IX SBQS, pp. 73-87, Belm, PA. Hartmann, J., Vieira, M., Foster, H. e Ruder, A. (2005), A UML-based approach to system testing, Journal of Innovations in Systems and Software Engineering, Springer, vol. 1, nmero 1, p.12-24, Abril. Juristo, N., Moreno, A. M., Vegas, S. (2004), Reviewing 25 years of testing technique experiments, Empirical Software Engineering: An International Journal, 9, p.7-44, Maro. Myers, Glenford J. (2004), The Art of Software Testing, 2nd ed., John Wiley & Sons, New Jersey.

60

Fiesta Toolkit: Model-Driven Software Product Lines in Practice

Hugo Arboleda1 , Andr s Romero2 , Rubby Casallas2 , Jean-Claude Royer3 e
1 2

Universidad Icesi DRISO Group, Cali-Colombia

Universidad de Los Andes Software Construction Group, Bogot -Colombia a

3

Mines de Nantes - INRIA ASCOLA Group, Nantes, France

hfarboleda@icesi.edu.co, {aa.romero354,rcasalla}@uniandes.edu.co Jean-Claude.Royer@mines-nantes.fr

Abstract. Model-Driven Software Product Lines (MD-SPLs) are those product lines whose members are created by using models and model transformations as rst-class artifacts. In this paper we present the Fiesta toolkit, a set of tools to assist product line architects and products designers when creating MD-SPLs. The main characteristic of our toolkit is that it facilitates the creation of negrained congurations of products, i.e. congurations at the level of each element in models that will be transformed into product line members. For that, the toolkit includes a set of tools for the creation of MD-SPL projects, feature models, constraint models, binding models, OCL-type expressions to validate binding models against constraint models, and decision models.

1. Introduction
Software Product Lines (SPL) are sets of software systems that have a similar purpose and share common features. In SPL Engineering, product development is separated into (1) domain engineering, which involves creating and maintaining a set of reusable artifacts; and (2) application engineering, where these reusable artifacts are used to build the products [Pohl et al. 2005]. Model-Driven Engineering (MDE) claims to improve software construction using models as rst-class entities during the whole development process. Many approaches to create SPLs have emerged that are based on MDE (e.g. [Voelter and Groher 2007]). These are called MD-SPL approaches. An MD-SPL is dened as a set of products developed from models which conform to metamodels, and that are derived from a set of model transformations. As part of our earlier work, we presented an MD-SPL approach including mechanisms to extend the scope of more traditional MD-SPLs approaches [Arboleda et al. 2009b, Arboleda et al. 2009a]. In this paper we present the Fiesta toolkit, which is our framework for creation of MD-SPLs. Fiesta is acronym for FInE-grained Scope denition, conguration and derivation of model driven and software product lines. The Fiesta toolkit implements facilities to (1) capture ne-grained variations between members of product lines, (2) congure new and more detailed products, and (3) derive ne-grained congured products. For that, the toolkit includes a set of tools for the creation of MD-SPL projects, feature models, constraint models, binding models,

61

OCL-type expressions to validate binding models against constraint models, and decision models.

2. Overall Approach
Fiesta covers most of the creation life cycle of MD-SPLs. There are two major processes on which Fiesta focuses its attention. On the one hand, there is the process of capturing and expressing variability, which impacts consequently the process of conguring product line members. On the other hand, there is the process of deriving products reusing and composing model transformations based on product congurations. Figure 1 presents an activity diagram summarizing the processes involved in Fiesta.

Figure 1. Overall Process

During the domain engineering process, product line architects create domain application metamodels, feature models and constraint models to capture the variability and commonalities of MD-SPLs. Constraint models make it possible for product line architects to capture and express the valid ne-grained variations between product line members using the concepts of constraint, cardinality property and structural dependency property (see [Arboleda et al. 2009a] for details). During the domain engineering process, product line architects create model transformations which consist of sets of transformation rules. Each transformation rule is responsible for producing a part of a nal product. Model transformation rules implement algorithms to transform domain application models into rened models (or source code). Product line architects also create decision models, which are the base of our mechanism to derive products including variability (see [Arboleda et al. 2009b] for details). To congure a product during the application engineering process, product designers create (1) domain application models that conform to domain application metamodels, and (2) binding models, which are sets of bindings between model elements and features. After a binding model is created, we validate this against a set of OCL-Type sentences derived from its respective constraint model. To derive a complete product according to a binding model, we dynamically adapt the parameters of model transformation executions. We achieve it using model transformation rules which are selected from the binding model and the pre-created decision models.

62

3. The Fiesta Toolkit

Along with Fiesta we provide Eclipse plug-ins to create MD-SPL projects, feature models [Kang et al. 1990, Czarnecki et al. 2004], constraint models, binding models, OCLtype expressions to validate binding models against constraint models, and decision models. We also provide openArchitectureWare (oAW) components to facilitate the processing of binding models and decision models to derive products. The entire Fiesta toolkit, the instructions for installing it and two case studies, can be found in the web-site of our research group [DRISO Group 2010]. Figure 2 presents a high level architecture of Fiesta from a static viewpoint. For the implementation of our tool support we chose the Eclipse platform as general framework and EMF as modeling framework, which means we express all our metamodels based on the Ecore meta-metamodel. We opted to use oAW1 as our model transformation engine. We selected oAW because this is a complete MDD framework integrated with Eclipse that makes the reading, instantiation, checking, and transformation of models possible. oAW has been used successfully to create SPLs, and there is an active community of SPL and MDD developers using and improving it. We create model editors by using Topcased2 .

Figure 2. High Level Fiesta Architecture

3.1. Domain Engineering MD-SPL Project Creation. We built an Eclipse plug-in that allows product line architects to create a particular type of Eclipse projects. This type of projects includes the required oAW and EMF dependencies to create MD-SPLs and predene a hierarchical folders structure to manage and centralize the core assets associated to an MD-SPL project. We named this plug-in the (MD-SPL) Project Creator. Metamodels and Feature Models Creation. Once an MD-SPL project has been created product line architects create metamodels and feature models. Metamodels are created by using MagicDraw3 , which is a UML2 modeling tool that allows us for creating UML Class Models and exporting them into UML2 XMI les. The MD-SPL projects we create include facilities to allow product line architects when creating metamodels from a classic UML perspective, which facilitates the creation of domain metamodels. To create feature models we provide the Feature Models Creator, which is an Eclipse plug-in. We decided to create our own Feature Models Creator instead of using commercial tools such
1 2

www.openarchitectureware.org www.topcased.org 3 www.magicdraw.com

63

Figure 3. Binding Models Creator

as pure::variants4 or tools which are under development and do not provide mature APIs such as fmp5 . Constraint Models Creation. We built an Eclipse plug-in to create constraint models, the Constraint Models Creator. Using our Constraint Models Creator product line architects can load a metamodel and a feature model, and then to create and delete constraints. The Constraint Models Creator allows for capturing the properties associated to our constraints and a description associated to it. When a product line architect selects to save a constraint model, the plug-in performs two activities. First, it saves a le with extension .constraintmetamodel containing the constraint model. Second, it saves a le with extension .chk which contains the Check expressions, OCL-type expressions, to validate binding models against the constraint model. 3.2. Application Engineering Domain Models and Binding Models Creation. By using Fiesta, product line architects build Eclipse plug-ins to create domain models using the facility provided by Eclipse to generate model editors from Ecore models. We developed an Eclipse plug-in named the Binding Models Creator to create binding models. Figure 3 presents the view associated to the Binding Models Creator. Using the Binding Models Creator, product designers can load a feature model, a domain model, and a constraint model, which will be used to validate the created binding model. Designers can create and delete bindings, or select a feature. The facility to select features is useful when coarse-grained congurations are required. When a product designer selects to save a binding model, the plug-in performs two activities. First, it saves a le with extension .congurationmetamodel containing the binding model. Second, the binding model is validated against the constraint model loaded before. Transformation Rules Creation. We use the Xpand and Xtend languages to
4 5

www.pure-systems.com gsd.uwaterloo.ca/projects/fmp-plugin/

64

create our transformation rules. These languages create les with extensions .xpt and .ext respectively. Our transformation rules are organized in folders created for each transformation step. Decision Models Creation. We built an Eclipse plug-in to create decision models, the Decision Models Editor. This editor was developed by using Topcaseds facility to create model editors. Figure 4 presents the GUI of our Decision Models Editor. On the left, we present the palette of options to create Model-to-Model and Model-to-Text transformations, Aspects, Execution Conditions, CoarseConditions and FineConditions. On the right, we present an example of how a decision model looks.

Figure 4. Decision Models Editor

Our Decision Models Editor allows product line architects to maintain uncoupled (1) the information of features, (2) the transformation rules, and (3) the possible executions conditions of transformation rules that particular feature congurations imply. Furthermore, our Decision Models Editor allows product line architects to capture as independent Aspects [Filman et al. 2005]the information of how transformation rules must be composed to derive congured products. This is a high-level mechanism which is independent of the technology used to implement our approach. Finally, our plug-in can capture executions conditions of transformation rules in order to derive products based on binding models, which represent ne-grained congurations. Generation and Execution of Model Transformation Workows. To execute our decision models we transform them into executable oAW workows by using a model-to-text transformation that is provided with the toolkit. This transformation is achieved using a model-to-text transformation. As a result, we can execute the generated model transformation workows on the model transformation engine of oAW. Thus, we derive any (ne-grained) congured product.

65

4. Conclusions and Future Work

We presented the base mechanisms and tools we use in the processes of (1) expressing variability and conguring products, and (2) deriving congured products. These mechanisms included the use of metamodels and feature models for expressing variability and conguring products, and decision models to derive product line members. We presented the MDD mechanisms we propose to improve the creation of MD-SPLs. These mechanisms include the use of constraint models which include the cardinality and structural properties, binding models and more expressive decision models. We discussed our general strategy for validating binding models against constraint models and for generating executable model transformation workows from decision models, which allow us to derive product line members. Our future work includes facilities to check on conguration time the created binding models, which currently is a sequential process. We also plan to work on integration of alternative variability models to our toolkit.

References
Arboleda, H., Casallas, R., and Royer, J.-C. (2009a). Dealing with ne-grained congurations in model-driven spls. In Proc. of the 13th SPLC09, San Francisco, US. Arboleda, H., Romero, A., Casallas, R., and Royer, J.-C. (2009b). Product derivation in a model-driven software product line using decision models. In Proc. of the 12th IDEAS09, pages 5972, Medellin, Colombia. Czarnecki, K., Helsen, S., and Eisenecker, U. (2004). Staged Conguration Using Feature Models. In Proc. of the 3th SPLC, pages 266282. LNCS 3154. DRISO Group (last visited in June 2010). Model-Driven Software Product Line Engineering: Tool Support and Case Studies. In http://www.icesi.edu.co/driso/esta. Filman, R. E., Elrad, T., Clarke, S., and Sit, M. A., editors (2005). Aspect-Oriented Software Development. Addison-Wesley, Boston. Kang, K., Cohen, S., Hess, J., Nowak, W., and Peterson, S. (1990). Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90-TR-21. Pohl, K., B ckle, G., and van der Linden, F. (2005). Software Product Line Engineering: o Foundations, Principles, and Techniques. Springer, Berlin. Voelter, M. and Groher, I. (2007). Product line implementation using aspect-oriented and model-driven software development. In Proc. of the 11th SPLC, pages 233242.

66

TaRGeT: a Model Based Product Line Testing Tool

Felype Ferreira1 , Las Neves1 , Michelle Silva1 and Paulo Borba1
1

Informatics Center Federal University of Pernambuco (UFPE) Recife PE Brazil

{fsf2,lmn3,mcms,phmb}@cin.ufpe.br

Abstract. To assure software quality and reliability, software testing is a technique that has grown in importance over the years. However, testing can increment development costs in about 50% of the projects total cost. TaRGeT was created as an alternative to reduce these costs by proposing a systematic approach in which test suites can be automatically generated from use case specications. TaRGeT has been used in different contexts and can be extended by other clients to be customized according to their specic needs.

1. Context and Motivation

Software testing has been one of the most used techniques for achieving software quality and reliability. Despite the fact that it is an important software development activity, testing software systems can be expensive. Studies suggest that testing often takes approximately 50% of the total software development cost [Ramler and Wolfmaier 2006]. So it is important to gure out a way to automate and improve the productivity of testing activities, ranging from test design to execution. One of the approaches for automatic test generation is Model-Based Testing (MBT). In order to automatically generate test cases, MBT accepts two main inputs: a formal model of the System Under Test (SUT) and a set of test generation directives, which guide the generation process. The bottleneck of MBT is often the creation of the SUTs formal model, which requires engineers to have formal modeling expertise. TaRGeT was designed to minimize this bottleneck by automating a systematic approach for dealing with requirements and test artifacts in an integrated way, in which test cases can be automatically generated from use cases scenarios written in natural language, which are used to automatically derive the system model that is transparent to the users. For this, TaRGeT denes a template for the use cases in which it is necessary to provide information about the user action, the system state and the system response for each step of the use case. It is possible to reuse the steps when creating alternative and exception ows. The tool also provides a GUI for guiding the user to generate test cases. TaRGeTs test case format contains information about the use cases and requirements related to the test, as well as the steps and its expected results and the test initial conditions. The user can describe the system inputs in the text of the test. It is important to highlight that automatic execution is not part of the scope of TaRGeT and the test cases that it generates are designed for manual execution. TaRGeTs main benet is a signicant increase on productivity, for example, instead of having people to maintain and create a large number of test cases, with TaRGeT

67

it is possible to concentrate efforts on properly describing a much smaller number of use cases and then have the tool generate several test cases from each use case.

2. Main Features
The main functionality of TaRGeT is the automatic generation of test suites from use case scenarios written in natural language. In addition, other tools important features are listened in the following subsections. 2.1. Controlled Natural Language Verication The use case specications used as input in TaRGeTs test generation process are written in natural language (NL), in order to facilitate the tools usage. However, NL descriptions may be ambiguous and inconsistent. As a consequence, the interpretation of software requirements and test cases will depend on readers experience. TaRGeTs Controlled Natural Language (CNL) was created as an optional feature to improve the process of text verication and to minimize possible mistakes into the code and in the testing phase. A CNL is a subset of an existing natural language. Basically, a CNL denes some writing rules and a restricted vocabulary in order to avoid authors to introduce ambiguities into their texts and also to dene a standard to be followed throughout an organization. TaRGeTs CNL is implemented by the CNL Advisor view at the workbench, as showed in Figure 1. The CNL contains a vocabulary, the CNL Lexicon, where the words are stored in different grammatical categories and a CNL Grammar that recognizes the use case documents sentences. The current implementation only supports documents written in American English. However, this can be extended to other languages because the CNLs parser receives as input XML les containing the lexicon and the grammar rules. So it is only necessary to provide new versions of these les according to a specic language. TaRGeTs CNL recognizes and processes the sentences from the user action, system conditions and system response elds in the use case document template.

Figure 1. CNL Advisor

There are two categories of errors in TaRGeTs CNL implementation: lexicon and grammar faults. The CNL Advisor displays both types of errors and additional information about the sentence, use case step and imported document where the error was found, as showed in Figure 1. Lexicon faults are displayed when a word present in a sentence from the use case document is not found in the lexicon. To correct this type of error the user can add unknown words in the lexicon or replace it by a synonym present in the lexicon. Words

68

like features and application names and acronyms should be written between quotation marks to not be considered by the parser, like in the following: Start the Microsoft Word application, The GPS is turned on. Grammar faults will be displayed when all words in a sentence are recognized by the lexicon and the sentences is not grammatically correct. To correct this type of fault the user should try to re-write the sentence in accordance to the CNL grammar. TaRGeTs CNL helps to avoid spelling errors like Scrol down the page and grammatical errors as Go to the Inbox folder and selects a message. In addition, it restricts the vocabulary and avoid ambiguities in the generated tests. 2.2. Test Case Selection One advantage of the usage of TaRGeT is the possibility to generate a great number of test cases only writing few use cases specications. However, due to time or budget restrictions, it is often not possible to execute all generated tests. TaRGeT provides some lters that allow the user to select the test cases according to different criteria, such as requirements, use cases, test purpose and similarity of test cases. The generated test suite is the result of these lters combination. If no option is chosen, the tool generates test cases for all possible scenarios. The following items describe the test selection lters: Requirements and Use Cases Filter: through this lter, the user is able to generate test cases that cover specic requirements and/or use cases. Similarity Filter: with this lter, the user can select test cases based on similarity [Gadelha et al. 2009]. The tool discards the most similar test cases based on the percentage informed by the user. For instance, it is possible to restrict the test suite by removing the 30% most similar test cases. For this, the user must set the scale to 70%, indicating that the generated test suite will contain the 70% most distinctive test cases. Test Purpose Filter: this lter allows the user to select test cases using test purposes. A test purpose is an abstract description of a subset of the specication, allowing choosing behaviors to test and, consequently, allowing reducing the specication exploration. A test purpose is composed of a sequence of steps. The operator * can also be used and means any sequence of steps. For example, if the test purpose is dened as [*;4M], it means that the tool shall select all test cases nished on 4M. 2.3. Test Suite Consistency Management When requirements evolve and it is necessary to regenerate the tests, information added in the test suite, like tests description and objective, and the selection of tests that have been performed before are lost. In addition, these modications performed in the use cases can generate new tests with ids that were already in use by other tests in an old suite. TaRGeT Consistency Management (CM) was conceived to solve this problem and to maintain the consistency of different test suites generated over the time. The algorithm has two main steps: comparison and merging. In the comparison step, the new test suite generated after the modications made in the use cases is compared with an old one in order to nd a relationship between new

69

and old test cases. This functionality is implemented by comparing the steps of the test cases using the Levenshteins word distance algorithm [Levenshtein 1966]. When the comparison is done, the system returns to the user a list of new and old test cases and the percentage of similarity between then. By selecting two tests, the user can visualize the steps that are different in each one, as show in Figure 2. The system automatically associates tests that have a similarity percentage grater than 95%. However, it is possible to change these associations manually and to congure the percentage of automatic association. Tests that have been added to the suite are marked as new because they dont match any old tests. The second step occurs when the associations between tests are done and it is time to generate the test suite. In this stage the system performs a merge between corresponding new and old tests, keeping any information that the user has added in the suite and preserving the tests selection. Besides, TaRGeT assigns ids that are not in use to the tests marked as new, assuring the consistency of the resulting test suite.

Figure 2. Test Comparison in Consitency Management

3. Architecture
The TaRGeT implementation is based on the Eclipse RCP architecture [RCP 2010] and it is developed as a software product line [Clements and Northrop 2002] to answer customers particular needs with a signicant reduction of the effort and cost required to implement product variations. Figure 3 shows how the dependences between the implemented plug-ins are organized. The main responsibilities of the application are distributed in four distinct basic plug-ins.

70

Figure 3. Dependencies between plugins

TaRGeT Core plug-in: responsible for system starting up and setting up the workspace and perspective of the RCP application. Common plug-in: implements basic entities to represent use cases documents and test case suites. Beside that, it contains parsers for different input formats and provides support to new implementations for new input formats. Project Manager plug-in: contains operations and exceptions to handling projects, test case generation algorithm, basic GUI components to be extended in the implantation and support for implementing variabilities to make TaRGeT compatible with different formats of input use case documents. Test Case Generation plug-in: generates test case suites in different formats and provides support to extend TaRGeT with new implementations for different output formats.

4. Brief Comparison with Other Related Tools

There are many model based testing tools like TaRGeT. In this section we chose two tools to make a brief comparison with TaRGeT: AsmL Test Tool and Conformiq. The Table 1 summarizes the main differences among the tools. AsmL Test Tool it was developed by Microsoft and uses AsmL (Abstract State Machine Language) that is an executable modeling language which is fully integrated in the .NET framework and Microsoft development tools [Barnett et al. 2004]. Conformiq [Conformiq 2010] is a tool for automatically designing and creating test cases. It uses as input system models in Java and UML compatible notation, mathematically calculates sets of test cases and exports the test cases in the format chosen by the user that can be TCL, TTCN-3, Visual Basic, HTML, XML or Python.

5. License
TaRGeT is an open source software whose code and documentation are covered by the MIT license [MIT 2010]. The complete license text and the tool can be found at [TestProductLines 2010].

71

Table 1. Comparison among tools.

6. Acknowledgements
We would like to thank National Institute of Science and Technology for Software Engineering (INES) [INES 2010] and Motorola Brazil in a cooperation project for partially supporting this work, CNPq and FACEPE for partially funding it, grants 573964/2008-4 and APQ-1037-1.03/08. In addition, we thank all research team members, especially Sidney Nogueira, Emanuela Gadelha, Dante Torres and Gustavo Cabral, who collaborated with this project.

References
Barnett, M., Grieskamp, W., Nachmanson, L., Schulte, W., Tillmann, N., and Veanes, M. (2004). Towards a tool environment for model-based testing with asml. Microsoft Research. Clements, P. and Northrop, L. (2002). Software Product Lines: Practices and Patterns, page 563. Addison-Wesley. Conformiq (2010). Conformiq test generator. http://www.conformiq.com/products.php. Gadelha, E., Machado, P., and Neto, F. (2009). On the use of a similarity function for test case selection in the context of model-based testing. Software Testing, Verication and Reliability Journal. Wiley. INES (2010). National institute of science and technology for software engineering. http://www.ines.org.br. Levenshtein, V. I. (1966). Binary codes capable of correcting deletions, insertions, and reversals. Soviet Physics Doklady. MIT (2010). MIT License. http://www.opensource.org/licenses/mit-license.php. Ramler, R. and Wolfmaier, K. (2006). Economic perspectives in test automation - balancing automated and manual testing with opportunity cost. Workshop on Automation of Software Test ICSE. RCP (2010). RCP FAQ. http://wiki.eclipse.org/RCP FAQ. TestProductLines (2010). Tests generation, selection, prioritization and processing product line. http://twiki.cin.ufpe.br/twiki/bin/view/TestProductLines/TaRGeTProductLine.

72

CIDE+: Uma Ferramenta para Extracao Semi-autom tica de a Linhas de Produtos de Software Usando Coloracao de C digo o
Virglio Borges de Oliveira1 , R gel Garcia2 , Marco Tulio Valente2 o
2

Instituto de Inform tica, PUC Minas a Departamento de Ci ncia da Computacao, UFMG e

virgilio@cotemig.com.br, idrogelgarcia@gmail.com, mtov@dcc.ufmg.br

Resumo. The extraction of real-world software product lines is a complex and time-consuming task. In order to accelerate this task, this paper presents a tool called CIDE+ that automates the annotation of optional features of existing systems. For this purpose, CIDE+ supports the semi-automatic association of background colors to the lines of code that implement an optional feature. CIDE+ has been successfully applied in extracting features of three non-trivial systems: Prevayler (an in-memory database), JFreeChart (a chart library) and ArgoUML (an editor for UML diagrams).

1 Introducao
A extracao de linhas de produtos de software a partir de sistemas existentes e uma tarefa complexa e custosa [4]. Em primeiro lugar, desenvolvedores precisam identicar os componentes respons veis pela implementacao de cada feature da linha de produtos. Em a seguida, eles devem identicar aqueles trechos de c digo que referenciam os compoo nentes descobertos no passo anterior. Por ultimo, deve-se anotar esses trechos de alguma forma ou mov -los para novas unidades de modularizacao. Assim, a m de acelerar a e extracao de linhas de produtos, descreve-se neste artigo uma ferramenta desenvolvida com o objetivo de automatizar de forma parcial a anotacao de features opcionais de sistemas existentes. A ferramenta proposta e baseada em uma extens o da plataforma Eclipse, chamada a CIDE (Colored IDE) [3]. CIDE estende o ambiente Eclipse com a possibilidade de se associar cores de fundo a trechos de c digo que implementam features. Portanto, em o vez de anotacoes textuais, tais como #ifdef e #endif, desenvolvedores podem usar anotacoes visuais para delimitar as linhas de c digo que pertencem a uma determinada o feature. Al m disso, o ambiente CIDE permite a geracao de projecoes de um sistema nas e quais todo c digo anotado com uma determinada cor e removido. Essa forma de projecao o permite a geracao de produtos da linha de software sem uma determinada feature. A ferramenta descrita no artigo chamada CIDE+ estende o ambiente CIDE com a capacidade de anotacao semi-autom tica de c digo relativo a features. Ou seja, a o usando apenas o CIDE, desenvolvedores devem manualmente localizar e mudar a cor de fundo de todos os trechos de c digo respons veis pela implementacao de uma feature o a que desejam incluir na linha de produtos. Normalmente, essa tarefa e custosa, tediosa e sujeita a erros. Por outro lado, usando CIDE+, tais tarefas s o automatizadas. Para isso, a inicialmente a ferramenta requer que engenheiros de linhas de produtos fornecam como entrada um conjunto de elementos sint ticos incluindo, por exemplo, pacotes, classes, a m todos e campos respons veis pela implementacao de uma feature. Esses elementos e a

73

s o chamados de sementes da feature. Em seguida, a ferramenta CIDE+ trata de colorir a todos os elementos do programa que referenciam direta ou indiretamente os elementos denidos como sementes. O restante deste resumo estendido est organizado conforme descrito a seguir. a A Secao 2 descreve o processo de extracao de features automatizado pela ferramenta CIDE+. Na Secao 3, apresenta-se um pequeno exemplo de uso da ferramenta. A Secao 4 sumariza os resultados obtidos na aplicacao da ferramenta em tr s sistemas n o-triviais. e a Por m, a Secao 5 discute ferramentas relacionadas e a Secao 6 conclui o artigo.

2 Extracao de Features com CIDE+

CIDE+ agrega ao ambiente CIDE a capacidade de anotacao autom tica de trechos de a c digo usando cores de fundo. A Figura 1 apresenta o processo iterativo e semi-autom tico o a para anotacao visual de features pressuposto pela ferramenta. Os passos desse processo s o discutidos nos par grafos seguintes. a a

Figura 1. Processo iterativo e semi-automatico para extracao de features

Denicao das Sementes: Inicialmente, desenvolvedores devem informar as sementes da feature a ser extrada. Sementes podem incluir os seguintes elementos sint ticos: cam a pos, m todos, classes ou interfaces e pacotes. Portanto, a ferramenta pressup e que os e o engenheiros tenham um conhecimento b sico da arquitetura e do projeto do sistema alvo a da extracao. Mais especicamente, eles devem ser capazes de informar os elementos do programa que s o integralmente respons veis pela implementacao da feature que desejam a a extrair do sistema. Algoritmo de Anotacao: Tendo como entrada as sementes denidas, esse algoritmo trata de colorir todas as partes do c digo que referenciam de forma direta ou indireta os eleo mentos classicados como sementes. Basicamente, o algoritmo proposto e um algoritmo de ponto-xo, com duas fases. Na primeira fase, chamada de propagacao de cores, os elementos do programa que referenciam as sementes s o visualmente anotados com uma a cor informada pelo engenheiro da linha de produtos. Por exemplo, suponha que o m todo e

74

m1 tenha sido classicado como uma semente. Portanto, nessa primeira fase, qualquer chamada de m1 ser visualmente anotada com a cor fornecida. Na segunda fase, chamada a de expans o de cores, o algoritmo verica se o contexto l xico dos elementos anotados na a e primeira fase tamb m pode ser colorido. Suponha, por exemplo, que a implementacao de e um m todo m2 apenas inclui uma chamada a m1 , a qual foi anotada na primeira fase do e algoritmo. Nesse caso, a implementacao de m2 tamb m ser colorida (assim como todas e a as suas chamadas). Como o foco do presente artigo e apresentar a ferramenta CIDE+, n o a s o fornecidos mais detalhes sobre o algoritmo de anotacao. O leitor interessado em tais a detalhes deve se dirigir a um outro trabalho de nosso grupo [2]. Expans es Semi-autom ticas: Em situacoes especiais, o algoritmo proposto pode gerar o a c digo com erros sint ticos ou de tipo. Suponha, por exemplo, a express o opcao o a a == algumaConstante, onde opcao foi anotada mas algumaConstante n o foi. a Dessa forma, a projecao incluindo apenas == algumaConstante n o ir compilar a a por apresentar erros de sintaxe. Em outro exemplo, suponha que todos os comandos return de um determinado m todo foram anotados, mas os demais comandos n o. e a Ap s a remocao do c digo anotado, um erro de tipo ser reportado (comando return o o a ausente). Em tais situacoes, a aplicacao de qualquer tipo de expans o corretiva e uma a tarefa desaadora e complexa. Quando uma anotacao leva a erros de sintaxe ou de tipo e nenhuma expans o a pode ser seguramente aplicada, o algoritmo proposto gera uma mensagem explicando o erro. Posteriormente, e sugerida uma expans o padr o para tratar o erro detectado, como a a descrito na Tabela 1. Por exemplo, a ferramenta pode sugerir a anotacao de toda uma ex press o (caso ela tenha sido parcialmente anotada) ou de todo um m todo (caso todos os a e seus comandos return tenham sido anotados). Se o desenvolvedor aceitar as sugest es, o a ferramenta automaticamente aplica tais expans es ao c digo, a m de eliminar os erros. o o Denicao Apenas partes de uma express o foram anoa tadas Os comandos return de um m todo foram e anotados, mas o m todo tem outros comane dos que n o foram anotados a Um par metro de chamada foi anotado, mas a o par metro formal associado a ele n o foi a a anotado O lado direito de uma express o foi anotado a mas o lado esquerdo n o anotado a Expans o Padr o a a Anotar toda a express o a Anotar todo o corpo do m todo e Anotar toda a chamada

SE1 SE2

SE3

SE4

Anotar o lado esquerdo e suas refer ncias e

Tabela 1. Expansoes Semi-automaticas

Avaliacao dos Resultados: Finalizada a execucao do algoritmo de anotacao, resta ao engenheiro respons vel pela extracao duas tarefas. Primeiro, ele deve detectar e corrigir a eventuais erros de sintaxe que tiverem sido inseridos no c digo. Em geral, esses erros s o o a inseridos quando o engenheiro optou por n o aceitar uma das expans es padr o sugeridas a o a pela ferramenta durante a execucao do algoritmo de anotacao. Em seguida, o engenheiro

75

 deve avaliar a cobertura das anotacoes visuais inseridas no c digo, isto e, se todas as lin o ` has de c digo dedicadas a implementacao da feature foram de fato coloridas. Para isso, o recomenda-se que ele gere uma projecao do sistema sem a feature em quest o e que exe a cute o produto gerado, de forma a se certicar de que a feature realmente n o se encontra a mais presente no sistema. Nessa execucao, ele pode perceber que ainda existe parte da funcionalidade provida pela feature no produto gerado. Nesse caso, ele deve renar as sementes inicialmente escolhidas e iniciar um novo ciclo do processo de extracao. Em resumo, o processo proposto possui as seguintes caractersticas: (a) semi autom tico, pois requer a denicao das sementes das features extradas e a aprovacao de a determinadas expans es de cores; (b) iterativo, pois pode requerer mais de um ciclo de o execucao, at obter uma cobertura de todo o c digo respons vel pela feature. O grau e o a de cobertura obtido e o n mero de iteracoes requeridas depende basicamente de seu mentes que incluam todas os elementos do programa que respondem pela implementacao da feature sob extracao.

3 Exemplo de Uso
Suponha uma classe hipot tica Stack com um m todo push. Suponha que essa classe e e faca parte de um sistema maior com as features descritas na Tabela 2. Al m do nome e das features e de uma breve descricao do papel das mesmas na classe Stack, essa tabela mostra tamb m as sementes escolhidas como entrada para a ferramenta CIDE+. e Feature Logging Snapshot Multithreading Descricao Log de eventos internos da pilha Salva elementos em meio persistente Vers o thread-safe da pilha a Sementes Classe Log M todo snapshot e Classe Lock

Tabela 2. Features da classe Stack e suas respectivas sementes

A Figura 2 apresenta o c digo da pilha colorido pela ferramenta CIDE+. Nesse o exemplo, chama a atencao a chamada de log realizada no interior do primeiro if do ` m todo push. Como essa chamada est aninhada em um bloco de c digo relativo a e a o feature Multithreading, ela recebeu duas cores: a cor de Logging (verde) e a cor de Multithreading (vermelho). Quando isso ocorre, a ferramenta usa a cor resultante da mistura fsica das duas cores entrelacadas (isto e, vermelho+verde = amarelo). Na parte inferior da Figura 2 mostra-se uma representacao da AST do programa gerada pela ferramenta CIDE+. Veja que os nodos respons veis pelos blocos de c digo coloridos no editor s o a o a tamb m mostrados coloridos. e

4 Estudos de Caso
CIDE+ foi usada com sucesso para extrair features de tr s sistemas: Prevayler (um banco e de dados em mem ria principal), JFreeChart (uma biblioteca gr ca) e ArgoUML (um o a editor de diagramas UML). A Tabela 3 sumariza a experi ncia de uso de CIDE+ nesses e tr s sistemas. Para cada sistema, a tabela informa o tamanho de seu c digo fonte (em e o megabytes), uma breve descricao das features extradas, o percentual do c digo fonte o anotado para extracao de cada uma das features, o n mero de expans es semi-autom ticas u o a (SE) requeridas durante a extracao e o n mero de iteracoes que foram requeridas at se u e obter uma cobertura completa do c digo de cada feature extrada. o

76

 Figura 2. Metodo push com features anotadas pela ferramenta proposta

Sistema Prevayler JFreeChart

Tam. (MB) 0.16 7.5

ArgoUML

8.95

Feature Monitor Replication Censoring Pie Charts 3D charts StateDiagrams ActivityDiagrams Design Critics Logging

% Tam. 4.0 6.7 2.7 5.0 2.3 3.7 1.7 14.9 1.8

# SE 3 0 1 21 7 100 40 136 19

# Iter. 1 1 1 1 1 2 1 2 2

Tabela 3. Resultados sumarizados dos estudos de caso

5 Ferramentas Relacionadas
Pelo menos que seja de nosso conhecimento, n o existem outras ferramentas para extracao a autom tica de features em linhas de produtos usando anotacoes (sejam elas textuais, como a diretivas de pr -processamento, ou visuais, como cores de fundo). e Sendo assim, as ferramentas mais pr ximas s o aquelas projetadas para apoiar o a a extracao fsica de features para unidades de modularizacao, normalmente para aspec tos. Como exemplo, podemos citar as ferramentas AOP-Migrator [1] e FOR [4]. No entanto, essas ferramentas requerem uma participacao e envolvimento muito maior dos engenheiros respons veis pelo processo de extracao. O principal motivo e que linguagens a como AspectJ se baseiam em um modelo de granularidade grossa para extens o de prograa

77

mas [3]. Em outras palavras, essas linguagens pressup em que o c digo respons vel pelas o o a features esteja presente em determinadas localizacoes est ticas do c digo fonte. Como a o nem sempre isso ocorre, essas ferramentas requerem um passo preliminar de preparacao do c digo fonte visando a sua extracao para unidades pr prias de modularizacao. Em o o geral, esse processo de preparacao requer um conhecimento detalhado do c digo, que o impede a sua automatizacao [6, 5].

6 Coment rios Finais a

Neste artigo, foi apresentada a ferramenta CIDE+, a qual estende o ambiente CIDE com a coloracao autom tica de c digo respons vel pela implementacao de features em linhas a o a de produtos de software. Mais informacoes sobre a ferramenta podem ser obtidas em: http://www.dcc.ufmg.br/mtov/cideplus. Agradecimentos: Este trabalho foi apoiado pela FAPEMIG, CAPES e CNPq.

Refer ncias e
[1] David Binkley, Mariano Ceccato, Mark Harman, Filippo Ricca, and Paolo Tonella. Tool-supported refactoring of existing object-oriented code into aspects. IEEE Transactions Software Engineering, 32(9):698717, 2006. [2] Virgilio Borges and Marco Tulio Valente. Coloracao autom tica de variabilidades em linhas de a produtos de software. In III Simp sio Brasileiro de Componentes, Arquiteturas e Reutilizacao o de Software (SBCARS), pages 6780, 2009. [3] Christian K stner, Sven Apel, and Martin Kuhlemann. Granularity in software product lines. In a 30th International Conference on Software Engineering (ICSE), pages 311320, 2008. [4] Jia Liu, Don Batory, and Christian Lengauer. Feature oriented refactoring of legacy applications. In 28th International Conference on Software Engineering (ICSE), pages 112121, 2006. [5] Marcelo Nassau, Samuel Oliveira, and Marco Tulio Valente. Guidelines for enabling the extraction of aspects from existing object-oriented code. Journal of Object Technology, 8(3):119, 2009. [6] Marcelo Nassau and Marco Tulio Valente. Object-oriented transformations for extracting aspects. Information and Software Technology, 51(1):138149, 2009.

78

Uma Ferramenta de Apoio Gerncia de Conhecimento Integrada a um Ambiente de Desenvolvimento de Software Centrado em Processos
Liken Lima, Silvia Nunes das Dores, Jadielly Oliveira, Ernani Sales, Gabriela Andrade, Carla Lima Reis Laboratrio de Engenharia de Software Universidade Federal do Par (UFPA) Caixa Postal 479 660.75 -110 Belm PA Brasil
{liken,jadielly,ernani,gabriela}@webapsee.com,silvia.cnd@gmail.com, clima@ufpa.br

Abstract. This paper presents the WebAPSEE Knowledge Manager tool (WKM), which provides support for planning and execution of Knowledge Management (KM) strategies and that's integrated with software development environment WebAPSEE. The WKM allows, among other features, that managers can establish milestones for gathering of knowledge according to the process execution.

1 Introduo
Uma das premissas para que uma organizao seja competitiva no mercado atual ter know-how para identificar, gerenciar, proteger e explorar os seus recursos de forma eficiente. Em muitas dessas organizaes, o conhecimento o mais importante, valioso, e crtico dos recursos [Basili et al. 2001]. Assim, a perda do conhecimento, seja com a sada de membros, esquecimento de solues ou avanos tecnolgicos, gera problemas significativos para as organizaes Na tentativa de minimizar os problemas gerados pela falta de gesto do conhecimento, as organizaes passaram a investir em tecnologias, mtodos e estratgias que facilitem a transferncia de conhecimento. Especificamente no desenvolvimento de software, o conhecimento gerado e utilizado em grande escala, tornando necessrio o uso de ferramentas para minimizar o esforo em compartilhar esse conhecimento. Dessa forma, inmeros sistemas [Montoni 2003] [Natali 2003] [Holz 2003] foram desenvolvidos para apoiar as atividades de Gerncia de Conhecimento (GC), sobretudo, integrados a Ambientes de Desenvolvimento de Software (ADS). Entretanto, tais ferramentas no atendem todo o espectro de funcionalidades de GC. Alm disso, existe a necessidade de fornecer apoio a GC no ambiente WebAPSEE. Nesse sentido, este artigo apresenta a ferramenta WebAPSEE Knowledge Manager (WKM), que integrada ao ADS Centrado em Processos WebAPSEE [Lima Reis e Reis 2007]. O WebAPSEE um PSEE que permite a modelagem, execuo e o acompanhamento de processos, alm de facilitar a reutilizao de boas prticas gerenciais por diferentes projetos. As principais funcionalidades da WKM so: definio e manuteno do Plano de GC, gerncia dos itens de conhecimento e a gerao de relatrios relacionados GC. Um ponto a ser destacado o fato de que durante a definio/manuteno do plano de GC, o gerente do projeto pode estabelecer marcos no processo para a coleta de conhecimento de acordo com a execuo do

79

processo. A ferramenta WKM descrita neste artigo resultado da evoluo dos trabalhos [Oliveira et al. 2009] e [Oliveira e Reis 2009]. O restante do texto est estruturado da seguinte forma: a seo 2 apresenta a arquitetura e as principais funcionalidades da WKM; a seo 3 apresenta uma breve comparao com outras ferramentas com foco em gerncia de conhecimento em ambientes de desenvolvimento de software; e, por fim, a seo 4 apresenta as consideraes finais do trabalho.

2 WebAPSEE Knowledge Manager

A WKM foi desenvolvida como uma extenso do WebAPSEE, ambiente este que possui como principal objetivo 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 WKM integrada ao Manager Console e a Task Agenda Web, alm de, definir novos componentes no servidor, associados aos componentes existentes, como a mquina de execuo de processos e a gerncia organizacional. A seguir ser apresentada uma viso geral da arquitetura e, posteriormente, as principais funcionalidades da WKM. 2.1 Arquitetura A arquitetura da WKM baseada na arquitetura do WebAPSEE, onde cada conjunto de funcionalidades possui uma interface de comunicao entre servidor e clientes. Deste modo, foi definida uma interface abstrata (interface WKM) contendo os servios encapsulados no componente WKM, o qual um sub-componente do WebAPSEE Server. Tais servios, por sua vez, so acessados a partir dos clientes do WebAPSEE: Manager Console e Task Agenda Web. A Figura 1 ilustra um diagrama de componentes que representa a integrao da WKM arquitetura do ambiente WebAPSEE.

Figura 1 - Viso Geral da integrao de componentes

80

O WebAPSEE Server, implementado utilizando Java, disponibiliza as interfaces de acesso aos servios atravs da tecnologia de invocao de procedimento remoto RMI, permitindo assim que o Manager Console, desenvolvimento em Java e interface grfica Swing, e a Task Agenda Web, desenvolvido em Adobe Flex e Java para fornecer a interface grfica Web, se comuniquem com o servidor do WebAPSEE. 2.2 Principais funcionalidades As principais funcionalidades do WKM so: (a) definio/manuteno do Plano de GC (definio de planos para coleta e disseminao de conhecimento, definio das estruturas de conhecimento a serem coletadas, etc.), (b) gerncia dos itens de conhecimento (aquisio, busca, avaliao, homologao, disseminao, manuteno do conhecimento, etc.) e a (c) gerao de relatrios de acompanhamento relacionados GC. Atravs do Manager Console, o gerente pode definir e manter Planos de GC estabelecendo quais estruturas de conhecimento (por exemplo, lies aprendidas, padro arquitetura, etc.) devem ser coletadas e disseminadas em um projeto. Alm disso, possvel definir marcos no processo para a realizao de coleta de conhecimento indicando qual o tipo de conhecimento deve ser coletado em determinado momento do processo (Figura 2.A). Um marco para coleta definido atravs da seleo de um evento associado a uma atividade (incio, trmino ou delegao da atividade), o que possvel devido a integrao com a mquina de execuo do WebAPSEE. As Figuras 2.B e 2.C apresentam a viso do usurio da agenda ao receber uma notificao (sugesto) para cadastrar um novo item de conhecimento quando um marco foi alcanado.

Figura 2 - Coleta de Conhecimento nos Marcos definidos no plano de GC.

Alm da coleta de conhecimento atravs dos marcos definidos pelo gerente, o usurio da Task Agenda Web pode, atravs do menu Conhecimento, inserir novos

81

itens, buscar os itens cadastrados, alm de listar todos os itens de conhecimento cadastrados por si prprio, para acompanhar o andamento dos registros. Ao ser inserido, o conhecimento recebe o estado de salvo (estado rascunho), permitindo que este seja enviado para homologao (estado em homologao). O homologador, ao receber o conhecimento pode: disponibilizar o conhecimento (estado disponvel), mandar para avaliao (estado em avaliao), enviar para o autor realizar uma reviso (estado reviso) ou desabilitar o conhecimento (estado desabilitado), caso em que o item se torna intil. A viso do homologador apresentada na Figura 3.

Figura 3 Homologao dos Itens de Conhecimento

Com base nos itens de conhecimento cadastrados, o gerente pode, atravs do Manager Console, gerar um relatrio contendo todos os itens de conhecimento inseridos pelos colaboradores da organizao em um determinado intervalo de tempo, indicando alm do identificador do conhecimento, a data de criao e o estado atual do item de conhecimento (rascunho, em homologao, em avaliao, disponvel ou removido).

Figura 4 - Relatrio de Itens de Conhecimento Registrados por Desenvolvedor

82

3 Ferramentas Relacionadas
Na literatura so encontradas algumas ferramentas que tem como objetivo auxiliar a gerncia de conhecimento no contexto de processos de desenvolvimento de software, tal como a ferramenta WKM. Dentre tais ferramentas esto: (a) ODE [Natali 2003]; (b) CORE-KM [Galotta, Oliveira e Rocha 2004] e o (c) PRIME [Holz 2003]. A ferramenta para GC integrada ao Ambiente de Desenvolvimento de Software ODE (Ontology-based software Development Environments) apia compartilhamento e reuso de conhecimento atravs de um conjunto extenso de atividades. O ambiente CORE-KM (Customizable Organizational Resources Environment with Knowledge Management), integrado ao ADS Estao TABA, um ambiente customizvel para gerncia de conhecimento em diferentes organizaes, com o objetivo de apoiar processos organizacionais. A ferramenta PRIME (Process-oriented Information resource Management Environment), integrada a um PSEE com execuo distribuda de processos, chamado MILOS, tem como objetivo adquirir conhecimento de processos de desenvolvimento em um ADS atravs da estruturao de conhecimento no processo. A Tabela 1 apresenta uma comparao entre as ferramentas que apiam a gerncia de conhecimento, com base em um conjunto de funcionalidades teis para a realizao de GC. Dentre as funcionalidades ressaltam-se, o suporte gerncia de configurao de ativos e gerao de relatrios que so caractersticas exclusivamente atendidas pela WKM. Os demais critrios como flexibilidade na categorizao do conhecimento, apoio aos aspectos colaborativos, especialistas e integrao com uma mquina de execuo, so atendidos por apenas uma ferramenta, alm da WKM.
Tabela 1 - Comparao com outras ferramentas.

Ferramentas ODE Funcionalidades Flexibilidade na categorizao do conhecimento Planejamento da gerncia de conhecimento Aquisio de conhecimento Avaliao de conhecimento Busca de conhecimento Disseminao de conhecimento Valorao de conhecimento Manuteno de conhecimento Integrao com uma mquina de execuo Apoio a colaborao Rede de Especialistas Gerncia de Configurao de ativos Relatrios COREKM /TABA X PRIME /MILOS WKM X X X X X X X X X X X X X

X X X X X X X

X X X X X

X X X X X X

4 Consideraes Finais
Este artigo apresentou a ferramenta WebAPSEE Knowledge Manager, que voltada para apoiar a implantao e execuo de estratgias de Gerncia de Conhecimento. A integrao da WKM ao ambiente WebAPSEE permite utilizar a mquina de execuo de processos do ambiente para definir marcos para coleta de conhecimento, alm de

83

consultar os dados organizacionais do ambiente para possibilitar a definio de uma rede de especialistas para avaliao dos conhecimentos cadastrados. Algumas das principais contribuies da ferramenta, alm de apoiar a GC de forma integrada a uma mquina de execuo, so: (a) possibilitar o planejamento de gerncia de conhecimento, incluindo a capacidade de realizar coleta e disseminao do conhecimento; e (b) gerao de relatrios sobre os conhecimentos cadastrados; Atualmente, a ferramenta est sendo implantada no Centro de Tecnologia da Informao e Comunicao da Universidade Federal do Par (CTIC-UFPA), avaliado no nvel G do MPS.BR, para auxiliar na implantao do processo de Gerncia de Conhecimento. Futuramente, pretende-se evoluir a ferramenta para uma nova verso com melhor usabilidade, e utilizar os recursos da Web 2.0 (como Tagging, por exemplo) para distribuio de conhecimento. Alm disso, pretende-se finalizar a implementao das funcionalidades pendentes, em relao rede de especialistas e a Gerncia de Configurao de itens de conhecimento. A ferramenta WKM, o manual de instalao e de uso podem ser encontrados no link http://labes.ufpa.br/liken/wkm e a mesma encontra-se sob a licena BSD (Berkeley Software Distribution).

Referncias
Basili V., Costa P., Lindvall M., Mendonca M., Seaman C., Tesoriero R., Zelkowitz M.,(2001). "An Experience Management System for a Software Engineering Research Organization," sew, pp.29, 26th Annual NASA Goddard Software Engineering Workshop. Galotta, C.; Oliveira, K. M.; Rocha, A. R. C. (2004), Apoio Interao entre Processos de Negcio e de Software atravs de Gerncia do Conhecimento. Simpsio Brasileiro de Qualidade de Software SBQS 2004. Braslia, DF, Brasil. Holz, H., (2003) Process-Based Knowledge Management Support for Software Engineering, Doctoral Dissertation, University of Kaiserslautern, dissertation.de Online-Press. Lima Reis, C. A.; Reis, R. Q. (2007) Laboratrio de Engenharia de Software e Inteligncia Artificial: Construo do Ambiente WebAPSEE. ProQualiti Qualidade na Produo de Software. v. 3, n. 1, junho de 2007. p. 43-48. Montoni, M. A.; (2003) Aquisio de Conhecimento: Uma Aplicao no Processo de Desenvolvimento de Software. Dissertao de Mestrado COPPE/UFRJ. Natali, A. C., (2003) Uma Infra-Estrutura para Gerncia de Conhecimento em um Ambiente de Desenvolvimento de Software. Dissertao de Mestrado.UFES. Oliveira, J. F. ; Andrade, G. F. ; Tavares, L. C. ; Reis, C. A. L. (2009). Planejamento e Execuo de Gerncia do Conhecimento em um Ambiente de Desenvolvimento de Software. In: VIII Simpsio Brasileiro de Qualidade de Software, Ouro Preto. Anais do VIII Simpsio Brasileiro de Qualidade de Software. Oliveira, J. F. ; Reis, C. A. L. (2009) . Apoio Automatizado Elaborao de Planos de Gerncia de Conhecimento para Processos de Software. In: XII Conferncia Iberoamericana de Ingenieria de Requisitos y Ambientes de Software, 2009, Medeln. Proceedings of the XII Conferncia Iberoamericana de Ingenieria de Requisitos y Ambientes de Software, 2009.

84

Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum

Diego R. Marins1,2, Jos A. Rodrigues Nt.1, Geraldo B. Xexo 2, Jano M. de Sousa1
1

Programa de Engenharia de Sistemas e Computao - COPPE/UFRJ

2

Departamento de Cincia da Computao - IM/UFRJ

{diegomarins,rneto,xexeo,jano}@cos.ufrj.br

Abstract. This paper presents the Scrum-Half, which was developed with the purpose of supporting the use of Scrum in project management. The motivation is to facilitate the organization and coordination of a software development team and assist them in making decisions, so that the use of Scrum becomes more efficient. The Scrum-Half allows the user to track the Scrum flow, since the preparation and maintenance of the Product Backlog to the planning, development and end of each Sprint.

1. Introduo
Com o objetivo de apoiar o Scrum (Schwaber 2004), foi desenvolvida uma ferramenta web, o Scrum-Half, cujo nome teve origem em uma das posies de jogo do Rugby. A motivao para esse trabalho foi facilitar a organizao de uma equipe de desenvolvimento de software e auxili-la nas tomadas de deciso, de modo que o uso do Scrum se torne ainda mais eficiente. A ferramenta armazena informaes sobre as Sprints, registrando a velocidade da equipe e estatsticas sobre a quantidade de tarefas concludas em cada iterao e quais tarefas ficaram pendentes. Isso permite uma viso rpida sobre o desempenho da equipe, auxiliando sua evoluo. Alm disso, na construo da ferramenta, houve a preocupao em se fazer um estudo detalhado sobre o Scrum, de modo que ela fosse desenvolvida com a maior proximidade possvel aos conceitos da metodologia. Com isso, espera-se que a ferramenta auxilie as equipes que adotaram o modelo gil a obter sucesso com o uso do Scrum nos projetos de desenvolvimento de software.

2. Breve Introduo ao Scrum

O Scrum uma metodologia de desenvolvimento gil que possui caractersticas importantes como os perodos curtos de trabalho onde so desenvolvidos alguns itens de uma lista priorizada pelo cliente. Cada perodo chamado de Sprint e quando sua durao chega ao final, uma nova funcionalidade apresentada. Durante toda a Sprint a equipe se rene diariamente para discutir o que foi feito, os obstculos encontrados e o que ser feito at a prxima reunio (Pressman 2006). As Sprints ocorrem uma aps a outra e consistem no Planejamento de Sprint, no trabalho de desenvolvimento, na Reviso da Sprint e na Retrospectiva da Sprint (Schwaber & Sutherland 2008). A lista de itens possui os requisitos do produto em desenvolvimento e chamada de Product Backlog. Ela criada no incio do projeto e modificada constantemente para identificar o que o produto necessita para ser apropriado, competitivo e til (Schwaber 2004). Outro artefato importante do Scrum o Sprint Backlog, construdo na reunio de planejamento da Sprint. O Sprint Backlog define as tarefas que a equipe ter

85

que desenvolver para transformar os itens do Product Backlog selecionados para a Sprint em um incremento de funcionalidade ao trmino dela (Schwaber 2004). No Scrum, a responsabilidade de avaliar e aceitar o produto construdo pela equipe cabe ao Product Owner. Ele tambm o responsvel por definir as caractersticas do produto e gerenciar o Product Backlog, priorizando seus itens de acordo com o valor de negcio (Srinivasan & Lundqvist 2009). Outro papel, o Scrum Master, tem a funo de facilitar o desenvolvimento de software, removendo obstculos e acompanhando o progresso da equipe Scrum. Uma equipe Scrum pode ser constituda de desenvolvedores, analistas de banco de dados, administradores de sistema, entre outros, dependendo do trabalho que ser feito no projeto (Cohn et al. 2009).

3. Ferramentas Relacionadas
Outras ferramentas j foram desenvolvidas com o mesmo objetivo, como o ScrumNinja (Carvalho & Lowenfels 2009), o iMeta Agility (iMeta 2009), o Scrum`d (Atlantic Dominion Solutions 2010) e o SkinnyBoard (Fluid Media Inc 2009). Essas quatro ferramentas oferecem um servio web pago mensalmente, com preo calculado de acordo com o plano escolhido, na maioria dos casos levando em considerao o nmero de usurios que usar o servio. Elas diferem principalmente na forma de organizar o Product Backlog e o Sprint Backlog. Exceto o Scrum`d, as ferramentas citadas oferecem o quadro de tarefas para definir o estado da tarefa na Sprint em andamento. O Scrum-Half tambm oferece um quadro de tarefas para ser usado durante a Sprint e permite a organizao do Product Backlog e do Sprint Backlog. Alm disso, o Scrum-Half possui o diferencial de acompanhar o fluxo Scrum, seguindo as etapas necessrias para o desenvolvimento de um projeto de software, auxiliando as reunies para elaborao e encerramento da Sprint e tambm no dia a dia do trabalho de desenvolvimento. Atualmente, possvel utilizar o sistema gratuitamente em http://carambola.cos.ufrj.br/scrum-half.

4. Arquitetura
O Scrum-Half utiliza uma arquitetura web. A ferramenta foi implementada em Java utilizando o banco de dados MySql (Oracle Corporation 2010b) e o servidor de aplicao JBoss (Red Hat 2010). O lado servidor foi desenvolvido com uma arquitetura com as seguintes camadas: apresentao, controle, servios, domnio de negcio e persistncia. A camada de apresentao, responsvel pela comunicao com o cliente, foi feita utilizando o framework JavaServer Faces (JSF) (Oracle Corporation 2010a). Alm disso, foram utilizados componentes Enterprise JavaBeans (EJB) e a Java Persistence API (JPA) (Oracle Corporation 2010a), utilizada na camada de persistncia. As classes de domnio de negcio foram modeladas com base nos conceitos do Scrum, seus artefatos e as relaes entre eles.

5. Descrio da Ferramenta
5.1. Caractersticas Gerais O Scrum-Half permite que um usurio participe de mais de um projeto, possuindo papel diferente em cada um deles. possvel atribuir um ou mais papis do Scrum a um

86

membro do projeto. Essa escolha implica em privilgios no sistema, de acordo com as caractersticas de cada papel. Alm disso, o sistema permite a atribuio do papel Gerente, caso necessrio, para um membro da equipe que estiver utilizando o sistema. 5.2. O Product Backlog do Scrum-Half Ao acessar o Product Backlog o usurio visualiza a lista de requisitos do projeto, chamados de itens de Backlog. Alm dele, o usurio tambm pode visualizar a lista de itens de Backlog pendentes, que formada pelos itens de Backlog criados, mas ainda no aprovados pelo Product Owner. De acordo com o Guia do Scrum (Schwaber & Sutherland 2008), os itens do Product Backlog possuem os atributos de descrio, prioridade e estimativa. A prioridade determinada por risco, valor e necessidade e o atributo responsvel pela ordenao dos itens. Os itens do Product Backlog podem ser atualizados a qualquer momento. Enquanto o Product Owner o responsvel pela prioridade dos itens, a equipe fica responsvel por todas as estimativas. Os itens de Backlog do Scrum-Half possuem esses trs atributos. No momento da criao de um item, qualquer usurio, independente do papel que exerce na equipe, pode informar os dados, a prioridade e a estimativa. Porm, um item criado precisa ser aceito pelo Product Owner para poder fazer parte do Product Backlog. Na atualizao dos itens pertencentes ao Product Backlog, o Product Owner pode alterar os dados e a prioridade de um item, enquanto o Scrum Master, a Equipe Scrum e o Gerente podem alterar a estimativa. Os atributos de prioridade e de estimativa possuem valor numrico. No caso da prioridade, quanto maior o valor de um item, mais importante para o cliente ele . J para o caso da estimativa, um valor maior corresponde a um item mais difcil de ser desenvolvido.

Figura 1. Criao de Item de Backlog

87

Figura 2. Product Backlog

5.3. Planejamento, Andamento e Encerramento da Sprint no Scrum-Half Uma Sprint uma iterao de durao fixa. Sua data final no muda mesmo que a equipe precise reduzir a funcionalidade entregue para poder concluir na data especificada (Rising & Janoff 2000). A reunio de planejamento da Sprint o momento no qual a iterao planejada. Nela so decididos os itens do Product Backlog que sero desenvolvidos na prxima Sprint. A equipe define como transformar os itens selecionados em um incremento pronto. O trabalho necessrio para isso definido numa lista de tarefas chamada de Sprint Backlog (Schwaber & Sutherland 2008). O Scrum-Half possui uma funcionalidade para o planejamento da Sprint. Nela o usurio primeiramente define o nome, o objetivo, a data de incio e a data de trmino. Concluda essa etapa o sistema apresenta o Product Backlog para seleo dos itens que faro parte da iterao. Para auxiliar na escolha dos itens, o sistema informa a velocidade mnima, mdia e mxima da equipe, que correspondem respectivamente quantidade mnima, mdia e mxima de pontos de estimativa que a equipe concluiu nas Sprints anteriores. Um diferencial do Scrum-Half no planejamento da Sprint a recomendao de um conjunto de itens de Backlog que podem ser desenvolvidos na prxima iterao, de acordo com a velocidade da equipe. A criao de tarefas do Sprint Backlog feita no quadro de tarefas. O quadro apresenta todas as tarefas criadas para a Sprint correspondente e o estado em que cada uma se encontra. Alm disso, permite a atualizao do Sprint Backlog a qualquer momento, acrescentando tarefas novas, atualizando dados ou removendo as que foram mal planejadas. O quadro possui trs colunas, na seguinte ordem: TAREFAS PENDENTES, TAREFAS EM ANDAMENTO e TAREFAS CONCLUDAS. As tarefas so criadas na primeira coluna e so movidas por drag and drop para as outras colunas no decorrer da Sprint. Em todas as colunas as tarefas so ordenadas de acordo com a

88

prioridade do item de Backlog correspondente. Com o quadro de tarefas possvel ter uma viso rpida do nmero de tarefas concludas e de quantas ainda esto por fazer.

Figura 3. Quadro de Tarefas

Outro artefato que permite acompanhar o progresso da Sprint, tambm presente no Scrum-Half, o grfico de Burndown. Ele mostra o trabalho restante ao longo do tempo e o progresso da equipe na reduo desse trabalho. O trabalho restante monitorado no eixo vertical e os perodos de tempo da Sprint so monitorados no eixo horizontal (Schwaber 2004). A quantidade de trabalho restante para a Sprint determinada pela soma das estimativas dos itens de Backlog restantes (Schwaber & Sutherland 2008). A funcionalidade desenvolvida na Sprint apresentada ao Product Owner durante a Reunio de Reviso da Sprint (Schwaber 2004). Na Reunio de Retrospectiva da Sprint, por sua vez feita a reviso do processo de desenvolvimento, de forma a torn-lo mais eficaz e gratificante para a prxima iterao. (Schwaber & Sutherland 2008). O Scrum-Half oferece apoio s duas reunies na funcionalidade de encerramento da Sprint, permitindo que o Scrum Master ou o Gerente informe os itens de Backlog que foram aceitos pelo Product Owner e tambm registre os pontos positivos e negativos da Sprint, para que possam ser avaliados a qualquer momento, visando auxiliar a evoluo da equipe.

6. Concluso
Esse artigo apresentou o Scrum-Half, uma ferramenta que possui as funcionalidades bsicas para o uso do Scrum, tais como o registro do Product Backlog e a manipulao do quadro de tarefas durante a Sprint. Alm disso, o Scrum-Half possui tambm o diferencial de auxiliar nas reunies de Scrum, fornecendo informaes teis para o planejamento da Sprint e permitindo o registro do que aprendido nas reunies de reviso e retrospectiva. Armazenar o que ocorre na construo de um software importante para a equipe evoluir com a prpria experincia. O registro do que foi desenvolvido em cada

89

Sprint auxilia o planejamento das Sprints futuras, obtendo uma estimativa para trmino do projeto mais prxima da realidade. O Scrum-Half tem como objetivo apoiar o uso do Scrum, mas no prope substituir as reunies do Scrum ou qualquer forma de integrao da equipe, pois o contato pessoal muito importante para o sucesso de um projeto. No entanto, em projetos que possuem equipes distribudas, o Scrum-Half auxilia a unir a equipe e manter a sincronia dos dados do projeto, como os itens de Backlog e as tarefas em andamento na Sprint.

7. Referncias
Atlantic Dominion Solutions, 2010. Scrum`d. http://www.scrumd.com/ [Acessado Maio 23, 2010]. Scrum`d. Disponvel em:

Carvalho, R. & Lowenfels, D., 2009. ScrumNinja. ScrumNinja. Disponvel em: http://scrumninja.com [Acessado Outubro 12, 2009]. Cohn, M.L., Sim, S.E. & Lee, C.P., 2009. What counts as software process? Negotiating the boundary of software work through artifacts and conversation. Computer Supported Cooperative Work, 401-443. Fluid Media Inc, 2009. SkinnyBoard. Disponvel em: http://www.skinnyboard.com [Acessado Outubro 12, 2009]. iMeta, 2009. iMeta Agility. iMeta Agility Scrum Software Management Software. Disponvel em: http://agility.imeta.co.uk/ [Acessado Outubro 12, 2009]. Oracle Corporation, 2010a. Java.sun.com. Disponvel em: http://java.sun.com/ [Acessado Junho 20, 2010]. Oracle Corporation, 2010b. MySQL. Disponvel em: http://www.mysql.com [Acessado Junho 20, 2010]. Pressman, R.S., 2006. Engenharia de Software 6 ed., McGraw-Hill. Red Hat, 2010. JBoss Community. Available at: 20/06/2010. Rising, L. & Janoff, N.S., 2000. The Scrum Software Development Process for Small Teams. IEEE Software, 26-32. Schwaber, K., 2004. Agile Project Management With Scrum 1 ed., Microsoft Press. Schwaber, K. & Sutherland, J., 2008. Scrum Guide, Srinivasan, J. & Lundqvist, K., 2009. Using agile methods in software product development: A case study. 6th International Conference on Information Technology: New Generations, 1415-1420.

90

StArt Uma Ferramenta Computacional de Apoio Reviso Sistemtica

Augusto Zamboni, Andr Di Thommazo, Elis Hernandes, Sandra Fabbri Departamento de Computao Universidade Federal de So Carlos (UFSCar) So Carlos, SP Brasil
augusto_zamboni@comp.ufscar.br, andredt@cefetsp.br, {elis_hernandes, sfabbri}@dc.ufscar.br

Abstract. Systematic Review (SR) is a technique used to search for evidence in scientific literature that is conducted in a formal manner, applying well-defined steps, according to a previously elaborated protocol. As the SR has many steps and activities, its execution is laborious and repetitive. Therefore, the support of a computational tool is essential to improve the quality of its application. This paper presents the tool called StArt (State of the Art through Systematic Review), which aims to help the researcher, giving support to the application of this technique. The StArt tool has being used by graduate students who have declared its positive support and its advantages in relation to other tools.

1. Introduo
O processo de Reviso Sistemtica (RS) tem sua origem na rea mdica e tem como objetivo, segundo [Pai et al., 2004] a criao de uma sntese completa e imparcial de um tpico de pesquisa, seguindo-se um procedimento bem definido e aberto. Mais recentemente, esse processo tem sido adaptado para a rea de computao, particularmente para a engenharia de software, com o mesmo objetivo de identificar, avaliar e interpretar todas as pesquisas relevantes disponveis relacionadas com algum tpico de pesquisa [Kitchenham, 2004]. Como vantagens para o uso da RS em relao s tcnicas tradicionais de reviso da literatura, destacam-se a abrangncia, a repetibilidade e a confiabilidade do processo aplicado. Alm de sistematizar a busca por pesquisas relevantes, a RS prev a organizao e anlise dos resultados encontrados. Contudo, o processo da RS bem mais trabalhoso que a pesquisa realizada de forma ad hoc [Kitchenham, 2004]. So muitos os passos a serem executados e vrios documentos a serem gerenciados. Com o objetivo de facilitar esse procedimento, foi desenvolvida a ferramenta StArt (State of the Art through Systematic Review), que apia as etapas de uma RS, dando suporte desde a elaborao do protocolo at a sumarizao dos resultados. Um prottipo da interface da ferramenta foi apresentado no ESELAW 2007 [Montebelo et al., 2007], e a partir dele a verso atual foi especificada e desenvolvida. Na Figura 1 so apresentadas as etapas de uma RS, de acordo com [Biolchini et al.,2005]. A principal diferena que existe entre as etapas propostas em [Kitchenham, 2004] e [Biolchini et al., 2005] quanto ao empacotamento, que para Kitchenham ocorre apenas ao final do processo. Todas elas so apoiadas pela ferramenta StArt como ser descrito na Seo 2.

91

Figura 1 - Processo de Conduo de Reviso Sistemtica adaptada de [Biolchini et al.,2005].

Assim, o objetivo deste artigo apresentar a ferramenta StArt, sendo que na Seo 2 sero apresentadas as principais funcionalidades, na Seo 3 so descritos os aspectos de implementao, na Seo 4 relacionam-se outras ferramentas de apoio ao levantamento bibliogrfico e na Seo 5 apresentam-se as concluses e os trabalhos em andamento e futuros.

2. Aspectos Funcionais
A ferramenta StArt d suporte ao processo da RS por meio de funcionalidades que apiam cada uma de suas fases. A Figura 2 mostra os principais passos que devem ser realizados durante a conduo da RS por meio da ferramenta, de acordo com as etapas apresentadas na Figura 1. Os passos marcados com asterisco so realizados externamente ferramenta, nas prprias mquinas de busca, sendo que apenas o resultado importado na StArt para dar continuidade ao processo.

Figura 2 - Principais passos da StArt relacionados s fases da Figura 1.

Na Figura 3 pode-se ver a rvore hierrquica com as fases da RS e as opes que a StArt disponibiliza para dar suporte a elas. Esto presentes na ferramenta: (i) a fase de Planejamento, que composta da criao do protocolo; (ii) a fase de Execuo, que permite a conduo, seleo e extrao das informaes pelos passos que vo desde a aplicao das strings de busca at a leitura e resumo dos artigos aceitos; e (iii) a fase de Sumarizao, que corresponde analise dos dados e que na ferramenta apoiada pela apresentao de alguns grficos que fornecem um panorama da situao dos artigos e permite que o pesquisador elabore um relatrio final sobre a reviso realizada. A seguir, cada uma das fases ser comentada fornecendo-se alguns detalhes sobre o apoio dado pela StArt. 2.1. Planejamento D apoio elaborao do Protocolo de acordo com os atributos sugeridos por Biolchini (2005), como por exemplo, as palavras-chave que sero utilizadas na busca; as mquinas de busca; os critrios para aceitao ou rejeio dos artigos encontrados, etc. Cada atributo do protocolo possui um help para ajudar o usurio quanto ao seu preenchimento. Esse protocolo fica armazenado na ferramenta, podendo ser consultado

92

e mesmo alterado, caso necessrio na fase de planejamento.

Figura 3 - Etapas da Reviso Sistemtica apoiadas pela StArt.

2.2. Execuo Essa fase da RS composta de alguns passos, que so apoiados pela StArt da seguinte forma: (i) a ferramenta permite importar o arquivo BibTex que deve ser gerado pelo pesquisador, depois dele ter aplicado uma busca em uma das mquinas de busca definidas no protocolo. Essa busca deve ser realizada externamente ferramenta, pois as bases no permitem atividades de captura automtica de informaes. Assim, como as bases comumente utilizadas como IEEE, Scopus, ACM e Springer, permitem a exportao da busca no formato BibTex, essa foi a alternativa usada para contornar o problema. Durante a importao dos dados, a ferramenta atribui a cada artigo uma pontuao de acordo com o nmero de ocorrncias que as palavras-chave definidas no protocolo aparecem em seu ttulo, resumo e lista de palavras-chave. Tal pontuao pode ser usada para estabelecer uma ordem de leitura, visto que, provavelmente, os artigos com maior pontuao sero mais relevantes RS. Essas funes esto relacionadas ao passo de Conduo. Ressalta-se que o arquivo BibTex contm apenas o resumo e outras informaes dos artigos que foram encontrados na busca. Vale ressaltar que se o usurio repetir a RS futuramente, ele poder adicionar s sesses de busca previamente criadas, novos arquivos Bibtex. Essa possibilidade permite que sejam atualizadas as referncias associadas a uma determinada string de busca.

93

(ii) o pesquisador tambm pode classificar o artigo segundo dois critrios: Status (Accepted, Rejected, Duplicated e Unclassified), que depende dos critrios de aceitao e Concept (Excelent, Good, Medium e Bad), que depende da percepo da relevncia do artigo para a RS. Para a classificao do Status, a ferramenta prov recurso para que o pesquisador justifique o status atribudo e represente graficamente a situao dessa classificao (Figura 3(a)). Essas funes esto relacionadas ao passo de Seleo. A Figura 4 ilustra as alternativas mencionadas em (i) e (ii).

Figura 4 - Exemplo de alternativas para avaliao dos artigos.

(iii) Aps a classificao de todos os artigos o pesquisador deve ler na ntegra e fazer um resumo daqueles classificados como Aceito. Para tanto, a ferramenta permite ao pesquisador vincular o texto completo de cada artigo aceito. Com isso o pesquisador pode dar andamento s atividades da RS, uma vez que ao final dessa etapa todos os artigos aceitos devem estar lidos e resumidos. Essas funes esto relacionadas ao passo Extrao. 2.3. Anlise dos Resultados Para essa fase, a ferramenta d suporte gerando os grficos relativos classificao dos artigos, no que diz respeito s fontes pesquisadas, e aos critrios utilizados para aceitao ou rejeio (Figura 3(b)). Alm disso, a StArt possibilita a edio do texto que deve representar a compilao conclusiva sobre o tema pesquisado, considerando os objetivos iniciais determinados no protocolo e os resultados obtidos com a leitura dos artigos.

3. Aspectos de implementao
A verso atual da StArt foi implementada para ambiente desktop. A persistncia de dados feita em arquivos e no em bases de dados, provendo StArt um ambiente porttil, no qual as RS realizadas por um pesquisador podem ser enviadas e abertas por

94

outros pesquisadores sem a necessidade de instalao de Gerenciadores de Banco de Dados especficos. A ferramenta est implementada na linguagem Java, dada sua popularidade e portabilidade entre diversas plataformas de Sistemas Operacionais, desde que exista uma Mquina Virtual Java instalada. Alm disso, existem vrias bibliotecas prontas que auxiliam, principalmente, na construo de componentes visuais. No caso da StArt, foi utilizado o Swing [SWING], bem como as bibliotecas JFreeChart [JFREECHART] e JWizard [JWIZARD] que auxiliam na construo de grficos e janelas de wizard, respectivamente. Atualmente a ferramenta um software proprietrio e pretende-se no futuro coloc-la sob as regras de alguma licena de software livre. Um vdeo demonstrativo da StArt est disponvel no endereo http://lapes.dc.ufscar.br/ferramentas/start.

4. Ferramentas Relacionadas
Existem algumas ferramentas que do suporte ao gerenciamento de referncias bibliogrficas, mas no ao processo de RS, como o propsito da StArt. Dentre elas citam-se JabRef [JR], EndNote [EN], ProCite [PC], Reference Manager [RM], RefWorks [RW], BibEdt [BEdt], Zotero [ZO], Biblioscape [BI], Bookends [BEnds] e Library Master [LM]. Dentre elas a que mais se aproxima no suporte RS a JabRef. Apesar de permitir a criao de atributos para avaliar os artigos, ela no trabalha, por exemplo, com os conceitos de Protocolo e de Critrios para aceitao ou rejeio de artigos como a StArt, que foi definida e implementada com esse propsito especfico.

5. Concluso
Este artigo apresentou a ferramenta StArt, que tem por objetivo apoiar o processo de Reviso Sistemtica em todas as suas etapas: Planejamento, Execuo e Sumarizao. Considerando a importncia de fazer o empacotamento da RS de forma a torn-la repetvel, o grande volume de informao que deve ser registrado e armazenado e considerando tambm que o processo caracterizado por atividades iterativas, o apoio de uma ferramenta fundamental para dar maior qualidade e facilitar a sua aplicao. A ferramenta continua em constante aprimoramento de forma a atender cada vez melhor a conduo de uma RS. No momento esto sendo finalizadas algumas funcionalidades que daro melhor suporte fase de sumarizao dos resultados da reviso bem como a gerao de relatrios que permitam extrair as informaes armazenadas na ferramenta. Assim que essas funcionalidades forem concludas, uma verso executvel ser disponibilizada para a comunidade. Como trabalho futuro, j em fase de especificao e implementao, sero tambm disponibilizadas outras verses da ferramenta com possibilidade de acesso via web, da gerao das referncias bibliogrficas de acordo com padres como o ABNT e do apoio para a elaborao do mapeamento sistemtico [Peterson et al., 2008]. Embora a StArt no tenha passado ainda por uma atividade de teste mais formal ou tenha sido submetida a um estudo experimental planejado, ela tem sido sistematicamente usada por vrios alunos de psgraduao na conduo de suas revises bibliogrficas. Um estudo experimental est sendo planejado e ser aplicado ainda no segundo semestre deste ano.

Agradecimentos
Agradecemos ao CNPq e a CAPES pelo apoio financeiro.

95

Referncias
BEdt. BibEdt. Disponvel em: <http://bibedt.sourceforge.net>. Acesso em: Jun./2010. BEnds. Bookends. Disponvel em: <http://www.sonnysoftware.com>. Acesso em: Jun./2010. BI. Biblioscape. Jun./2010. Disponvel em: <http://www.biblioscape.com>. Acesso em:

Biolchini, J.; Mian, P. G.; Natali, A. C. C.; Travassos, G. H. (2005) Systematic Review in Software Engineering. Technical Report RT-ES 679 / 05, Rio de Janeiro, Brazil. EN. EndNote. Disponvel em: <http://www.endnote.com>. Acesso em: Jun./2010. JFREECHART. JFreeChart. Disponvel em: <http://www.jfree.org/jfreechart>. Acesso em: Jun./2010. JR. JabRef. Disponvel em: <http://jabref.sourceforge.net>. Acesso em: Jun./2010. JWIZARD. JWizard. Disponvel em: <http://flib.sourceforge.net/JWizard/doc/index.html>. Acesso em: Jun./2010. Kitchenham, B. (2004) Procedures for Performing Systematic Reviews, Joint Technical Report Software Engineering Group, Department of Computer Science Keele University, United King and Empirical Software Engineering, National ICT Australia Ltd, Australia. LM. Library Master. Disponvel em: <http://www.balboa-software.com>. Acesso em: Jun./2010. Montebelo, R. P., Orlando, A., Porto, D. P., Zaniro, D., Fabbri, S. C. P. F. (2007) SRAT (Systematic Review Automatic Tool) Uma Ferramenta Computacional de Apoio Reviso Sistemtica. In: ESELAW - Experimental Software Engineering Latin American Workshop, So Paulo. Proceedings IV Experimental Software Engineering Latin American Workshop. Marlia : Fundao de Ensino Eurpedes Soares da Rocha. v. 1. p. 13-22. Pai, M., McCulloch, M., Gorman, J. D., Pai, N., Enanoria, W., Kennedy, G., Tharyan, P., Colford Jr., J. M. (2004) Clinical Research Methods - Systematic reviews and meta-analyses: An illustrated, step-by-step guide. The National Medical Journal of India, v.17, n. 2, p.86-94. PC. ProCite. Disponvel em: <http://www.procite.com>. Acesso em: Jun./2010. Peterson, Kai., Feldt, R.,Mujtaba, S.,Mattsson, M. (2008) "Systematic MApping Studies in Software Engineering". In: "12th International conference on Evaluation and Assessment in Software Engineering (EASE)". University of Bari, Itlia. RM. Reference Manager. Disponvel em: <http://www.refman.com>. Acesso em: Jun./2010. RW. RefWorks. Disponvel em: <http://www.refworks.com>. Acesso em: Jun./2010. SWING. Swing. Disponvel em: <http://java.sun.com/javase/6/docs/technotes/guides/swing>. Acesso em: Jun./2010. ZO. Zotero. Disponvel em: <http://www.zotero.org>. Acesso em: Jun./2010.

96

SBES
XXIV Simpsio Brasileiro de Engenharia de Software

EVENTOS SATLITES XVII Sesso de Ferramentas III FEES Frum de Educao em Engenharia de Software XV WTES Workshop de Teses e Dissertaes em Engenharia de Software IV LTPD Workshop on Languages and Tools for Parallel and Distributed Programming I WB-DSDM Workshop Brasileiro de Desenvolvimento de Software Dirigido por Modelos IV LA-WASP Latin American Workshop on Aspect-Oriented Software Development AutoSoft 2010 First Workshop on Autonomous Software Systems IV WDDS Workshop de Desenvolvimento Distribudo de Software I WOES Workshop Brasileiro de Otimizao em Engenharia de Software I WJP Workshop sobre Diretrizes para Jovens Pesquisadores em Engenharia de Software

SBLP
XIV Simpsio Brasileiro de Linguagens de Programao

SBCARS
IV Simpsio Brasileiro de Componentes, Arquitetura e Reutilizao de Software

ORGANIZAO

REALIZAO

Sociedade Brasileira de Computao

UFBA

PATROCNIO

FAPESB
Secretaria da Indstria, Comrcio e Minerao
Fundao de Amparo Pesquisa do Estado da Bahia