Ferramenta de Apoio À Engenharia de Requisitos

Volume 4
Sessão de Ferramentas
XVII Sessão de Ferramentas
Setembro de 2010
Salvador • Bahia • Brasil
ANAIS
Coordenador do Comitê de Programa
Uirá Kulesza
Coordenadores Locais do SBES

Christina von Flach Garcia Chavez
Cláudio Nogueira Sant’Anna
Coordenador Geral do CBSOFT

Manoel Gomes de Mendonça Neto
Realização
LES • Laboratório de Engenharia de Software
DCC • Departamento de Ciência da Computação
UFBA • Universidade Federal da Bahia
Promoção
SBC • Sociedade Brasileira de Computação
Apresentação do CBSOFT
A Sociedade Brasileira de Computação (SBC) tem um longo histórico de eventos de
sucesso nas áreas de engenharia de software e linguagens de programação. O Simpósio
Brasileiro de Engenharia de Software é talvez o melhor exemplo disto. Este evento
alcança agora sua 24ª edição desde a sua criação em 1987. Neste caminho, ele ajudou a
criar os Simpósios Brasileiros de Linguagens de Programação (SBLP), Métodos
Formais (SBMF), Qualidade de Software (SBQS) e Componentes, Arquitetura e
Reutilização de Software (SBCARS), além de pelo menos uma dúzia de outros eventos
de menor porte. A despeito de todos os seus efeitos positivos, esta expansão criou ao
menos um problema. Hoje é muito difícil para um pesquisador participar de todos os
eventos importantes da SBC na área de software.
Ano passado, membros da comunidade brasileira de software decidiram atacar este

problema com a criação do Congresso Brasileiro de Software: Teoria e Prática, ou
simplesmente CBSOFT. O objetivo do congresso não é ser um novo evento, mas uma
federação de eventos que já existem. Um congresso que reúna vários eventos
importantes sob um mesmo teto. Sua meta é ser, uma vez ao ano, o ponto focal da
comunidade brasileira de pesquisa em sistemas de software.
Neste ano de estréia, o CBSOFT reúne o SBES, o SBCARS, o SBLP, mais 12 eventos
satélites e um evento associado. Os eventos satélites são a Sessão de Ferramentas do
CBSOFT, o Fórum de Educação em Engenharia de Software (FEES), o Workshop de
Teses e Dissertações em Engenharia de Software (WTES), o Workshop de Diretrizes
para Jovens Pesquisadores em Engenharia de Software (WDJPS), a Trilha da Indústria
do CBSOFT (CIT), e os seguintes workshops técnicos: Desenvolvimento de Software
Dirigido por Modelos (WB-DSDM), Desenvolvimento de Software Orientado a
Aspectos (LA-WASP), Sistemas de Software Autônomos (AUTOSOFT),
Desenvolvimento Distribuído de Software (WDDS), Otimização em Engenharia de
Software (WOES), e Linguagens e Ferramentas para Programação Multi-thread,
Paralela e Distribuída (LTPD).
O evento associado é a Conferência Latino-Americana em Linguagens de Padrões para

Programação (SugarLoafPLoP). Ela ocorrerá antes das outras atividades do CBSOFT e
terá seus anais editados em separado. Ano que vem, o SBMF se juntará ao grupo para o
CBSOFT 2011 que acontecerá em São Paulo, capital.
Mais que o seu tamanho, muito me orgulha a qualidade do CBSOFT. Todas as suas
trilhas técnicas foram muito competitivas e produziram artigos muito bons. Nossos 12
mini-cursos e 6 tutoriais serão ministrados por pesquisadores e profissionais, do Brasil e
do exterior, com grande experiência na área. Eu agradeço a cada um deles por
disponibilizarem-se a transmitir seus conhecimentos para a nossa comunidade.
Mais que tudo, eu estou muito feliz por nossos palestrantes convidados. O congresso
terá 13 palestrantes de reconhecida capacidade, líderes em seus campos de atuação no
Brasil e no mundo. Eu agradeço profundamente a Alex Wolf, Jonathan Aldrich, Arndt
von Staa, Rebecca Wirfs-Brock, Daltro Nunes, Jon Whittle, Flavio Oquendo, Fábio
ii
Kon, Sérgio Soares, Joe Yoder, Eric Tanter, e Mauro Pezzè, por virem à Salvador para
o CBSOFT 2010.
O material de alta qualidade da Sessão de Ferramentas que você tem agora em suas
mãos é um dos Treze Volumes dos Anais do CBSOFT. Os Volumes do SBCARS e do
SBES são publicados na Biblioteca Digital do IEEE. Os outros onze contêm os anais
dos eventos listados anteriormente e podem ser obtidos através do sítio da Sociedade
Brasileira de Computação (www.sbc.org.br).
Eu concluo esta mensagem agradecendo a todos os envolvidos no planejamento e na

execução do CBSOFT. Primeiramente, eu agradeço aos membros dos comitês técnicos
de todos os eventos federados pela pontualidade e qualidade do seu trabalho. Obrigado
a Thais Batista (Coordenadora do Comitê de Programa do SBES), Ricardo Lima e
Jonathan Aldrich (Coordenadores do Comitê de Programa do SBLP), Paulo Pires
(Coordenador do Comitê de Programa do SBCARS), Uirá Kulesza (Coordenador da
Sessão de Ferramentas e do SugarLoafPLoP), Rebecca Wirfs-Brock (também
Coordenadora do SugarLoafPLoP), Márcio Delamaro (Coordenador Geral dos
Workshops), Alessandro Garcia (Coordenador dos Tutoriais e do WB-DSDM), Leo
Murta (Coordenador do WTES e do WDDS), Heitor Costa (também Coordenador do
WDDS), Márcio Barros (Coordenador do FEES e do WOES); Jerffeson de Souza
(também Coordenador do WOES); Rafael Prikladnicki (Coordenador da Trilha com a
Indústria), Fernando Castor e Roberta Coelho (Coordenadores do LA-WASP), Anarosa
Brandão (Coordenadora do AutoSoft), Eduardo Almeida (Coordenador do SBCARS e
do WDJPS) e Paulo César Masiero (também Coordenador do WDJPS).
Por fim, eu agradeço a todos os envolvidos na organização do evento pela sua dedicação
e eficiência. Sem vocês o evento não teria ocorrido! Agradecimentos muito especiais
para Vaninha Vieira (Coordenadora de Organização do CBSOFT), Christina Chavez e
Cláudio Sant'Anna (Coordenadores de Organização do SBES e do SugarLoafPLoP),
Adolfo Duran (Coordenador de Organização SBCARS e das atividades sociais do
CBSOFT), Lais Salvador e Rita Suzana Maciel (Coordenadoras de Organização do
SBLP), todo o corpo de funcionários da SBC e da DAGAZ Eventos, e os estudantes do
LES-UFBA.
Tenho certeza que o CBSOFT produzirá muitas discussões interessantes e trará

excelentes oportunidades de interação para todos os seus participantes. Aproveitem o
congresso e a cidade!
Salvador, Setembro de 2010.
Manoel Mendonça
Coordenador Geral do CBSOFT 2010
iii
Message from the General Chair
The Brazilian Computer Society (SBC) has been a long time sponsor of many
successful software engineering and programming language events. The Brazilian
Symposium on Software Engineering (SBES) is perhaps the best example of this
success. The event has now reached its 24th edition, since its creation in 1987. On its
path, it helped to spin-off the Brazilian Symposia on: Programming Languages (SBLP),
Formal Methods (SBMF), Software Quality (SBQS), and Components, Architecture
and Software Reuse (SBCARS), plus at least a dozen other smaller events. This growth
reflects the expansion of the Brazilian scientific base in the field. In spite of all its
positive effects, it has had at least one drawback. It is now difficult for a researcher to
attend all important events sponsored by SBC.
Last year, members of the Brazilian software community decided to counter this effect
by creating the Brazilian Conference on Software: Theory and Practice, or simply
CBSOFT. Thus, CBSOFT aims not to be a new event, but rather a federation of events
that already exists. One that brings together several important events to the same
location. Its goal is to be a once a year focal point for the Brazilian software research
community.
In this debut year, CBSOFT brings together SBES, SBCARS, SBLP, plus 12 satellite
events and one associated event. This year satellite events are the CBSOFT Tools
Session, the Software Engineering Education Forum (FEES), the Workshop on Thesis
and Dissertations on SE (WTES), the Workshop on Guidelines for Young Software
Engineering Researchers (WDJPS), the CBSOFT Industry Track (CIT), and the
following technical workshops: Model-driven Development (WB-DSDM), Aspect-
Oriented Software Development (LA-WASP), Autonomous Software Systems
(AUTOSOFT), Distributed Software Development (WDDS), Optimization on Software
Engineering (WOES), and Languages and Tools for Multithreaded, Parallel and
Distributed Programming (LTPD).
The associated event is the Latin-American Conference on Pattern Languages of

Programming (SugarLoafPLoP). It will be held prior to the other CBSOFT activities
and has separated proceedings. Next year, SBMF will join the party at CBSOFT 2011,
to be held at the city of São Paulo.
More than its size, I am very proud about the quality of CBSOFT. All its technical
tracks were very competitive and yielded very good papers. Our 12 short courses and 6
tutorials are lectured by very experienced researchers and professionals, from Brazil and
abroad. I thank each one of them for taking their time to transmit their knowledge to our
community.
I am particularly proud of our 13 invited speakers, all recognized to be at the forefront

of their research fields, in Brazil and abroad. I deeply thank Alex Wolf, Jonathan
Aldrich, Arndt von Staa, Rebecca Wirfs-Brock, Daltro Nunes, Jon Whittle, Flavio
Oquendo, Fábio Kon, Sérgio Soares, Joe Yoder, Eric Tanter, and Mauro Pezzè, for
coming to Salvador for CBSOFT 2010.
iv
The high quality material on the CBSoft Tools Session you now hold on your hands is
the Fourth of CBSOFT’s Thirteen Volume Proceedings. The SBCARS and SBES
Volumes are published by the IEEE Digital Library. The remaining eleven volumes
contain the proceedings of other previously mentioned events and can be ordered
directly through the Brazilian Computer Society site (www.sbc.org.br).
I conclude by thanking all those involved with the event. First, the members of the
Technical Committees for the timeliness and quality of their work. Thanks to Thais
Batista (SBES Program Chair), Ricardo Lima and Jonathan Aldrich (SBLP Program
Co-Chairs), Paulo Pires (SBCARS Program Chair), Uirá Kulesza (Tools Chair and
SugarLoafPLoP Co-chair), Rebecca Wirfs-Brock (SugarLoafPLoP Co-chair), Márcio
Delamaro (Workshops Chair), Alessandro Garcia (Tutorials and WB-DSDM Chair),
Leo Murta (WTES Chair and WDDS Co-Chair), Heitor Costa (WDDS Co-Chair),
Márcio Barros (FEES and WOES Co-Chair); Jerffeson de Souza (WOES Co-chair);
Rafael Prikladnicki (Industry Track Chair), Fernando Castor and Roberta Coelho (LA-
WASP Co-Chairs), Anarosa Brandão (AutoSoft Chair), Eduardo Almeida (SBCARS
Organizing Co-Chair and WDJPS Co-chair), Paulo César Masiero (WDJPS Co-chair).
Lastly, I thank all involved in the organization of the event for their hard work and
dedication. Very special thanks to Vaninha Vieira (CBSOFT Organizing Chair),
Christina Chavez and Cláudio Sant'Anna (SBES and SugarLoafPLoP Organizing Co-
Chairs), Adolfo Duran (SBCARS Organizing Co-Chair), Lais Salvador and Rita Suzana
Maciel (SBLP Organizing Co-Chairs), all the staff at SBC and DAGAZ, and the
students at LES-UFBA.
I am sure CBSOFT will produce many exciting discussions and bring forth excellent
interaction opportunities for all. Enjoy the conference and the city!
Salvador, September 2010.
Manoel Mendonça
CBSOFT General Chair
v
Apresentação da Sessão de Ferramentas do CBSoft
A Sessão de Ferramentas é um dos eventos satélites do Congresso Brasileiro de
Software: Teoria e Prática (CBSoft 2010), realizado em Salvador, em Setembro de
2010. Ela passa a integrar as já tradicionais sessões de ferramentas do Simpósio
Brasileiro de Engenharia de Software (SBES) e do Simpósio Brasileiro de Arquitetura,
Componentes e Reutilização de Software (SBCARS) realizadas ao longo dos últimos
anos. Os comitês diretivos de ambos os simpósios, juntamente com a comunidade de
engenharia de software brasileira, decidiram integrar tais sessões em uma única,
dedicada a apresentação técnica e demonstração de ferramentas e ambientes de suporte
à engenharia de software. Ela é nomeada “XVII Sessão de Ferramentas”, porque dá
prosseguimento as 16 sessões de ferramentas realizadas anteriormente no SBES.
O comitê de programa da Sessão 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 submissões de artigos de diferentes programas de pós-
graduação do Brasil e 1 submissão proveniente da Colômbia. Cada artigo foi revisto por
3 membros do comitê de programa. Um total de 120 excelentes revisões foram
realizadas, contribuindo imensamente no processo de seleção dos artigos. Como
resultado, 16 artigos técnicos foram selecionados para serem incluídos nos anais e
apresentados na conferência (taxa de aceitação = 40%). Os artigos abordam diferentes
áreas da engenharia de software: engenharia de requisitos, análise e visualização de
código, refatoração e reengenharia, testes de software, linhas de produto de software,
processos de software e engenharia de software empírica.
O sucesso da Sessão de Ferramentas do CBSoft 2010 é apenas possível por causa da

dedicação e entusiasmo de muitas pessoas. Primeiramente, gostaria de agradecer aos
autores que submeteram seus trabalhos. Gostaria de agradecer também aos membros do
comitê de programa e revisores externos, pelo excelente trabalho de revisão e
participação ativa nas discussões; o professor Glêdson Elias (UFPB) por gentilmente
compartilhar sua experiência como coordenador da sessão de ferramentas do
SBES’2009; a organização do CBSoft, representada por Manoel Gomes Mendonça
Neto; a organização local do SBES, representada por Christina von Flach Garcia
Chavez e Cláudio Nogueira Sant’Anna; assim como Glauco Carneiro (UFBA) e Paulo
Anselmo Silveira (UFPE) pela ajuda na atualização do site e produção dos anais,
respectivamente. Finalmente, gostaria de gentilmente agradecer a Manoel Mendonça
(UFBA) e Thaís Batista (UFRN) pelo convite para coordenação da Sessão de
Ferramentas do CBSoft 2010.
Esperamos que você aprecie o programa técnico da Sessão de Ferramentas do CBSoft.
Salvador, Setembro de 2010
Uirá Kulesza
Coordenador da Sessão de Ferramentas do CBSoft 2010
vi
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 Glêdson Elias (UFPB) for kindly sharing his experience as
program chair of the SBES’2009 Tools Session; the CBSoft organization, represented
by Manoel Gomes de Mendonça Neto; the SBES local organization, represented by
Christina von Flach Garcia Chavez and Cláudio Nogueira Sant’Anna; 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 Mendonça (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
vii
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.
viii
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)
Cláudio 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 Mendonça (UFBA)
Marcelo d'Amorim (UFPE)
Marcelo Turine (UFMS)
Marcelo de Almeida Maia (UFU)
Marcilio Mendonça (University of Waterloo)
Marcos Chaim (USP)
Maria Istela Cagnin (UFMS)
Nabor Mendonca (UNIFOR)
Nélio 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)
Rosângela Penteado (UFSCar)
Sandra Fabbri (UFSCar)
Sérgio Soares (UFPE)
Silvia Vergilio (UFPR)
Valter Camargo (UFSCar)
Vander Alves (UnB)
ix
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)
x
Comitê Organizador – Organizing Committee
Coordenação Local SBES – SBES Local Co-Chairs

Christina von Flach Garcia Chavez (DCC/IM/UFBA)
Cláudio Nogueira Sant’Anna (DCC/IM/UFBA)
Coordenador Geral do CBSOFT – CBSOFT General Chair

Manoel Mendonça (DCC/IM/UFBA)
Coordenadora de Organização do CBSOFT – CBSOFT Organizing

Chair
Vaninha Vieira (DCC/IM/UFBA)
Coordenação Local SBES – SBES Local Co-Chairs

Christina Chavez (DCC/IM/UFBA)
Claudio Sant'Anna (DCC/IM/UFBA)
Coordenação Local SBCARS – SBCARS Local Co-Chairs

Eduardo Almeida (DCC/IM/UFBA)
Adolfo Almeida Duran (CPD/UFBA)
Coordenação Local SBLP – SBLP Local Co-Chairs

Lais N. Salvador (DCC/IM/UFBA)
Rita Suzana P. Maciel (DCC/IM/UFBA)
Time de Organização – Organizing Team

Antonio Terceiro (DMCC/UFBA) Paulo Anselmo Silveira (Cin/UFPE)
Antonio Oliveira (DMCC/UFBA) Raphael Oliveira (DMCC/UFBA)
Bruno Carreiro (DMCC/UFBA) Renato Novais (DMCC/UFBA e IFBA)
Glauco Carneiro (DMCC/UFBA) Rodrigo Rocha (DMCC/UFBA)
Ivan Machado (DMCC/UFBA) Yguaratã Cavalcanti (CIn/UFPE)
Leandro Andrade (CC/UFBA)
Apoio Executivo – Execution

DAGAZ Eventos
xi
Índice – Table of Contents
Engenharia de Requisitos / Requirements Engineering
Ferramenta de Apoio à Engenharia de Requisitos Integrada a um Ambiente

Colaborativo de Código 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 Análise de Impacto de Mudanças baseada

em Interesses de Negócio ...............................................................................................7
Antonio Oliveira Filho (UFBA), Fabrício de Freitas Cardim (Faculdade Ruy Barbosa)
Tiano Oliveira Dórea (Faculdade Ruy Barbosa), Christina von Flach Chavez (UFBA)
Uma Ferramenta de Apoio à Gerência 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)
Análise e Visualização de Código / Code Analysis and Visualization
Analizo: an Extensible Multi-Language Source Code Analysis and Visualization

Toolkit ............................................................................................................................19
Antonio Terceiro (UFBA), Joenio Costa (UCSAL), João Miranda (IME-USP),
Paulo Meirelles (IME-USP), Luiz Romário 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 Júnior (UFBA)
Arleson Nunes (UFBA), Manoel Mendonça (UFBA)
Hist-Inspect: Uma Ferramenta de Apóio à Avaliação Sensível à História de Código ...31

Leandra Mara (PUC-Rio), Gustavo Honorato (PUC-Rio), Francisco Neto (PUC-Rio)
Alessandro Garcia (PUC-Rio), Carlos Lucena (PUC-Rio)
Refatoração e Reengenharia / Refactoring and Reengineering
AssistME – uma Ferramenta para Auxiliar a Refatoração para Aspectos de Tratamento

de Exceções ....................................................................................................................37
Cristiane Queiroz (UPE), Fernando Castor (UFPE), Nélio Cacho (UFRN)
ComSCId & DMAsp: Identificação de Interesses Transversais e Recuperação de

Modelos de Classes Anotados a partir Aplicações OO Java ..........................................43
Paulo Afonso Parreira Júnior (UFSCar), Heitor Costa (UFLA)
Valter Camargo (UFSCar), Rosângela Penteado (UFSCar)
xii
Testes de Software / Software Testing
FERRARE GT: Automação de Testes de Desempenho e Estresse via Testes Funcionais

........................................................................................................................................49
Ismayle Santos (UFPI), Alcemir Santos (UFPI), Pedro Santos Neto (UFPI)
ModelT2: Apoio Ferramental à Geração 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), Andrés 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), Laís Neves (UFPE)
Michelle Silva (UFPE), Paulo Borba (UFPE)
CIDE+: Uma Ferramenta para Extração Semi-automática de Linhas de Produtos de

Software Usando Coloração de Código .........................................................................73
Virgilio Borges (PUC Minas), Rógel Garcia (UFMG), Marco Tulio Valente (UFMG)
Processos de Software / Software Processes
Uma Ferramenta de Apoio à Gerência 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 à Revisão Sistemática ...................91

Augusto Zamboni (UFScar), André Di Thommazo (CEFET-SP)
Elis Cristina Hernandes (UFSCar), Sandra Fabbri (UFSCar)
xiii
Ferramenta de Apoio à Engenharia de Requisitos
Integrada a um Ambiente Colaborativo de Código 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 código aberto. O seu uso
possibilita a manutenção de requisitos, regras de negócio, glossário, casos de
uso e a definição da rastreabilidade entre estes produtos de trabalho. Os
principais objetivos são: a padronização dos documentos, a avaliação do
impacto de mudanças no desenvolvimento de software e o aumento da
produtividade, uma vez que os artefatos estão disponíveis em um único
ambiente. É implementada em um ambiente de gerenciamento de projetos
colaborativo que apóia o trabalho com equipes distribuídas.
1. Introdução
O constante crescimento da demanda por software e sua inegável importância dentro das
organizações, aliados ao seu grau de complexidade cada vez maior, apontam para um
cenário onde é fundamental o desenvolvimento de produtos de qualidade. Dessa forma,
preocupar-se com o processo de desenvolvimento de software e buscar sua melhoria
contínua constitui um fator crítico de sucesso.
De acordo com Pressman (2007), “uma compreensão completa dos requisitos de
software é fundamental para um bem-sucedido desenvolvimento de software”. Dentro
desse contexto, a Engenharia de Requisitos (ER) visa buscar técnicas bem definidas
para elicitar, especificar, validar e documentar requisitos.
O MPS.Br (2010), objetiva a melhoria de processo do software brasileiro, sendo
implementado através de sete níveis de maturidade. Cada nível possui seus processos
com objetivos definidos e resultados esperados que, se obtidos, caracterizam o seu
cumprimento. Se todos os resultados dos processos de um nível são atingidos, pode-se
1
dizer que o processo de desenvolvimento de software da organização atingiu a
maturidade deste nível. O Projeto de Qualidade de Software Aplicada à Educação
Profissional e Tecnológica - QUALI-EPT (2010) visa a implantação da qualidade de
software nos projetos da Rede Nacional de Pesquisa e Inovação 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 à
Gerência de Requisitos (GR).
Os projetos de desenvolvimento de software da Renapi envolvem equipes
distribuídas em todo o Brasil, gerando a necessidade de um ambiente colaborativo de
desenvolvimento. Dessa forma, o QUALI-EPT buscou a integração da Gerência de
Requisitos, dada a sua importância, a uma plataforma flexível, de código aberto e
colaborativa de desenvolvimento, para apoiar a implementação deste processo nos
projetos da Renapi. A partir de uma análise 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 QUALI-
EPT desenvolveu uma ferramenta denominada Fermine com intuito de facilitar a
manutenção de produtos como requisitos, casos de uso, atores, regras de negócio e
glossário, além de permitir a associação entre estes elementos apoiando a definição da
rastreabilidade, que é um dos resultados esperados no MPS.Br.
A ferramenta Fermine foi desenvolvida como extensão 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 gerência de tarefas e de
projeto, e, portanto, o desenvolvimento de uma ferramenta integrada a este ambiente
possibilitaria um ganho de produtividade em função 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 eletrônicos. Além disso, a integração com o Redmine facilita o trabalho
colaborativo, uma vez que o ambiente disponibiliza recursos como wiki e fórum por
projeto, repositório de acesso compartilhado (SVN – subversion), notificações por
email, dentre outras facilidades. Uma equipe distribuída, ao utilizar a Fermine, pode
fazer a manutenção de vários itens que contemplam a ER como, por exemplo: requisitos
(funcionais e não-funcionais), regras de negócio, glossário, casos de uso etc. Permite
também relacionar artefatos da ER, definindo rastreabilidade entre casos de uso e
requisitos, por exemplo, além de rastros para regras de negócio, glossário, etc.
O restante do artigo está organizado da seguinte forma: a Seção 2 apresenta a
ferramenta de apoio à ER e suas funcionalidades; a Seção 3 apresenta os trabalhos
relacionados; e a Seção 4 apresenta as conclusões 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 aplicações Rails, um plugin possui a mesma arquitetura da aplicação principal, porém
caracteriza-se como uma extensão devido a sua dependência desta.
As aplicações criadas com Rails são desenvolvidas com base no padrão de projeto
2
Model-View-Controller – MVC. A Figura 1 caracteriza os elementos presentes na
arquitetura do plugin Fermine. O Action Mailer e Action WebServices atuam no envio
de e-mails e comunicação com serviços web, respectivamente. A junção do Action View,
responsável pela renderização de templates, com o Controller, responsável pela lógica
da aplicação, compõe o Action Pack que, por sua vez, é o centro do framework Rails. O
mapeamento objeto-relacional e a camada de persistência são providos pelo Active
Record. O Dispatcher é responsável pelas requisições ao Controller apropriado e por
recarregar a aplicação se houver dependências 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 manutenção de artefatos da
Engenharia de Requisitos e de permitir a definição de rastreabilidade entre estes
elementos. A Fermine disponibiliza um conjunto de templates eletrônicos que permitem
o registro e a manutenção de diversos produtos de trabalho da ER, a saber: regras de
negócio, requisitos funcionais e não-funcionais, termos do glossário, casos de uso e
atores. Permite, então, a padronização dos documentos nos projetos da RENAPI.
As atividades de registro e manutenção da especificação dos casos de uso são
facilitadas com o uso da ferramenta. Artefatos como atores, regras de negócio e
requisitos são associados ao caso de uso através de links. Esta forma de associação
permite um ganho de produtividade no preenchimento dos documentos, uma vez que o
responsável pela especificação do caso de uso pode consultar e associar rapidamente os
artefatos, considerando que estes estão inseridos num único ambiente. A Figura 2
mostra o registro e a especificação completa de um caso de uso utilizando a ferramenta.
Outro aspecto a ser destacado é a forma de preenchimento dos fluxos
alternativos e das exceções. Ao incluir um fluxo alternativo ou uma exceção, a
ferramenta já orienta o especificador do caso de uso a selecionar o passo de origem de
acordo com o fluxo principal previamente inserido. Além disso, todos os passos dos
fluxos são numerados automaticamente, mantendo-se um padrão. Da mesma forma, os
casos de uso incluídos (includes) podem ser facilmente associados. O link para
associação de includes permite ao especificador selecionar o passo do fluxo principal
que dá origem à inclusão e escolher o caso de uso que será incluído. O mesmo vale para
3
a associação de casos de uso estendidos (extends), acrescentando-se, neste caso, um
campo para especificação da condição necessária à ocorrência da extensão. O template
do caso de uso também traz um recurso para facilitar o entendimento da especificação
por usuários ou outros membros do projeto. Na descrição resumida, os termos
encontrados glossário são exibidos como links, permitindo consultar suas definições.
Figura 2. Manutenção e especificação de casos de uso na Fermine
A Figura 3 mostra como é feito o registro de requisitos funcionais e não-

funcionais na ferramenta. Por último, a ferramenta permite definir a rastreabilidade entre
os artefatos da ER que mantém. O registro da rastreabilidade é importante porque
fornece informações úteis para avaliação dos impactos que mudanças nos requisitos
podem ocasionar, além de possibilitar a identificação de inconsistências entre os
requisitos e demais artefatos. A Figura 4 ilustra a rastreabilidade na ferramenta.
4
Figura 3. Manutenção de requisitos na Fermine
Figura 4. Rastreabilidade entre casos de uso e demais artefatos na Fermine
A ferramenta está acessível em http://redmine.iff.edu.br:8000/, onde também é

possível experimentá-la por meio da seguinte sequência 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
proprietária da Sparx System que permite a criação de diversos diagramas da UML, a
manutenção de requisitos e regras de negócio. Além disso, gera a rastreabilidade entre
os requisitos e demais artefatos. Contudo, não possibilita a especificação de casos de
uso através de um template e é pago. O Jude Professional (2010) é uma ferramenta de
modelagem bastante utilizada, embora não seja uma solução gratuita. Nela, é possível a
criação de diversos diagramas da UML, bem como a especificação de casos de uso.
Porém, não faz a geração da rastreabilidade entre requisitos, casos de uso e demais
produtos de trabalho. A Tabela 1 mostra uma comparação entre as ferramentas.
5
Tabela 1. Comparação entre ferramentas
Ferramentas
Critérios Enterprise Jude
Fermine
Architect Professional
Solução Livre Não Não Sim
Apoio à Definição de Rastreabilidade Sim Não Sim
Geração da Matriz de Rastreabilidade Sim Não Não
Especificação de Caso de Uso Não Sim Sim
Suporte ao Desenvolvimento Colaborativo Sim Não Sim
Modelagem Sim Sim Não
4. Conclusões e Trabalhos Futuros

Este artigo apresentou uma ferramenta de apoio à ER integrada a um ambiente
colaborativo de código aberto. O uso da ferramenta promove a padronização de
documentos, trabalho colaborativo, redução do tempo gasto na documentação requerida
pela ER e, flexibilidade na personalização (solução de código aberto). Além disso, têm-
se como contribuições: a manutenção e integração dos diversos artefatos da ER;
descrição e especificação completa de casos de uso; definição 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: geração da
matriz de rastreabilidade em HTML e PDF; associação dos casos de uso com artefatos
de modelo como classes por meio da leitura de arquivos XMI; integração da GR com a
Gerência de Projetos, uma vez que o Redmine suporta cadastro de tarefas e cronograma
de trabalho; disponibilização no portal de software público brasileiro.
5. Referências
Pressman, Roger S. (2007), Engenharia de Software, Makron Books, 6ª edição. São
Paulo.
Souza, Daline G. M. de; Siqueira, Karolyne A.; Freitas, Rafael L. de. Integração da
Gerência 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 à Educação Profissional e
Tecnológica, http://www.renapi.org/qualidade/conheca-o-projeto/apresentacao,
acessado em 01/06/2010.
RENAPI - Portal da Rede Nacional de Pesquisa e Inovação em Tecnologias Digitais,
http://www.renapi.org, acessado em 01/06/2010.
Redmine, http://www.redmine.org, acessado em 01/06/2010.
Enterprise Architect, http://www.sparxsystems.com/products/ea/, acessado em
01/06/2010.
Jude Professional Design & Modeling, http://jude.change-vision.com/jude-
web/product/professional.html, acessado em 01/06/2010.
6
FIR-Diagram: Uma Ferramenta para apoiar a Análise de
Impacto de Mudanças baseada em Interesses de Negócio
Antônio Oliveira Filho1 , Fabrı́cio de Freitas Cardim2 ,
Tiano Oliveira Dórea2 , Christina von Flach G. Chavez1
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 identification of potential conse-

quences 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. Introdução
Atualmente, software e negócio caminham juntos. Organizações estão inseridas em
cenários sujeitos a mudanças constantes em seus negócios, nos quais os sistemas de soft-
ware e as informações produzidas por eles têm importância crescente. Mudanças podem
afetar regras de negócio (externas ao software) – declarações utilizadas para restringir
ou definir algum aspecto do negócio [Group 2010] , podem ou não se manifestar em re-
quisitos de negócio [Leite and Leonardi 1998] (no caso de existir software associado) e
são potencialmente fontes de uma série de mudanças em regras e requisitos de negócio
relacionados bem como em artefatos utilizados ao longo do ciclo de vida do software
em questão. A análise de impacto de mudanças é a identificação das potenciais con-
sequências de uma mudança, ou a estimativa do que precisa ser modificado para realizar
uma mudança [Arnold 1996]. Em teoria, a análise de impacto precisa identificar todas as
regras e requisitos de negócio afetados pela solicitação de mudança, porém, na prática,
as técnicas e ferramentas atuais [Raja and Kamran 2008] dependem da existência de soft-
ware que implemente as regras de negócio da organização. Não foram identificadas fer-
ramentas que dêem suporte ao relacionamento entre regras de negócio, com ou sem a
presença de software que as implemente.
O modelo FIR (Funcionalidade-Informação-Regra) é um modelo de ras-
treabilidade que apóia a análise de impacto baseada em interesses de negócio
[Oliveira Filho 2010, Oliveira Filho et al. 2008] , ou seja, a análise de impacto que pode
ser realizada a partir de mudanças solicitadas sobre regras de negócio. Interesses de
negócio são definidos como agrupamentos de regras de negócio que compartilham os
mesmos propósitos, de modo que, quando uma mudança é solicitada para uma regra
de negócio de um determinado agrupamento, isso significa que existem interessados da
7
organização em descobrir os impactos relacionados a essa mudança que se manifestam
em outro(s) agrupamento(s). Propósitos podem ser vistos como elos que relacionam re-
gras de negócio de interesses de negócio distintos entre si através do compartilhamento
de informações [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 Seção 2 apresenta uma visão geral dos requisitos
e caracterı́sticas da ferramenta, a Seção 3 descreve suas principais funcionalidades e as
ilustra por meio de um exemplo simples e a Seção 4 apresenta as considerações finais.
2. Visão Geral
São requisitos de FIR-Diagram:
Q1 : A ferramenta deve permitir a criação de instâncias de FIR em modo gráfico;
Q2 : A ferramenta deve permitir a validação de instâncias de elementos a partir das
restrições definidas para FIR;
Q3 : A ferramenta deve permitir a realização da atividade de descoberta de impactos sobre
uma instância de FIR;
Q4 : A ferramenta deve permitir que instâncias de FIR possam estar disponı́veis para
integração com outras ferramentas;
Q5 : A tecnologia utilizada no desenvolvimento da ferramenta deve ser relevante tanto na
indústria quanto na academia, de modo a motivar futuros interessados na evolução
da ferramenta.
A ferramenta foi implementada como um plugin para o ambiente Eclipse1 . A
grande popularidade e relevância desse ambiente, tanto na indústria quanto na acade-
mia, satisfaz o requisito Q5 . Utilizamos o Graphical Modeling Framework (GMF), um
framework que apóia o desenvolvimento de editores gráficos e atende os requisitos Q1 ,
Q4 e Q5 . O GMF integra outros dois frameworks, o Eclipse Modeling Framework
(EMF) e o Graphical Editing Framework (GEF). O EMF é uma implementação do MOF
(Meta Object Facility) que predispõe os modelos criados à integração e responsável pelas
transformações entre modelos criados em UML ou em linguagem de programação Java.
O GEF permite criar um rico editor gráfico a partir de modelos construı́dos através do
EMF. O GMF suporta a inclusão de restrições (constraints) durante a definição do modelo
e, portanto, atende o requisito Q2 . No FIR-Diagram, as restrições foram implementa-
das usando duas das linguagens suportadas pelo GMF: Java e OCL.
3. Funcionalidades de FIR-Diagram
Nesta Seção apresentamos as principais funcionalidades de FIR-Diagram, incluindo
Criação de Instâncias de FIR (Seção 3.1), Aplicação das Restrições de FIR (Seção 3.2)
e Descoberta de Impactos (Seção 3.3). O exemplo a seguir é utilizado para ilustrar cada
uma das seções.
Venda e emissão de ingressos. Empresas responsáveis pela venda de ingressos utilizam

um software que tem como funcionalidade a emissão de ingressos, dentre outras.
1
www.eclipse.org
8
Em um ingresso válido, devem constar as informações data e nome do evento, para
conferência durante o acesso ao estádio. Recentemente, uma mudança na lei obrigou
que no ingresso constasse o CPF do torcedor, além das informações já citadas. A partir
do próximo campeonato, para ter acesso ao estádio, o torcedor deve carregar consigo
um documento onde conste o CPF para conferência. Para tanto, cada torcedor deve
ser cadastrado através de um serviço web que estará disponı́vel para todas as empresas
de venda de ingressos.
3.1. Criação de instâncias de FIR

O plugin FIR-Diagram permite que instâncias de tipo de regras de negócio descritas
pelo FIR [Oliveira Filho 2010] sejam criadas e relacionadas entre si. Por exemplo, as
seguintes instâncias de regras de negócio de venda e emissão de ingressos podem ser
criadas, onde Fi , Rk e Ij , com i, k e j inteiros positivos, são utilizados para facilitar
a identificação dos tipos de regras de negócio suportadas pelo FIR, e indicam os tipos
Funcionalidade, Regra e Informação, respectivamente:
• Regra de negócio do tipo Funcionalidade
– F1 : Cadastrar Torcedor;
– F2 : Emitir Ingresso;
– F3 : Liberar Acesso;
• Regra de negócio do tipo Regra
– R1 : Se o CPF informado for válido, então o Torcedor-CPF é igual ao
CPF informado;
– R2 : Se Nome do Evento informado for válido, então o
Ingresso-Nome-do-Evento é igual ao Nome do Evento infor-
mado;
– R3 : Se a Data do Evento informada for válida, então o
Ingresso-Data-do-Evento é igual à Data do Evento informada;
– R4 : Se Torcedor-CPF for válido, então 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 negócio do tipo Informação
– I1 : Torcedor-CPF;
– I2 : Ingresso-Nome-do-Evento;
– I3 : Ingresso-Data-do-Evento;
– I4 : Ingresso-CPF;
A Figura 1 é uma representação gráfica do exemplo de venda e emissão
de ingressos construı́da com o FIR-Diagram. Os elementos Funcionalidade,
Informação e Regra são representados através de cı́rculos coloridos de acordo com
cada tipo. Os elos de dependência entre esses elementos são representados por ligações
entre os cı́rculos. As ligações direcionadas representam os conceitos de produção,
quando a origem está em uma regra e o destino está em uma informação, e consumo,
9
Figura 1. Diagrama de instâncias do FIR
quando ocorre o oposto. A ligação não direcionada representa o conceito de execução,

onde uma ou mais regras são executadas por uma funcionalidade. Na Figura 1, a regra
R3 produz a informação I3 quando a funcionalidade F2 é executada, e essa informação
será consumida pela regra R7 quando a funcionalidade F3 for executada. As regras de
negócio no FIR podem ser separadas em dois grupos: as que fazem parte do software
(representam requisitos de negócio) e as que estão fora do software. Os requisitos de
negócio são identificados em tons de verde, que vão do verde mais escuro (instâncias do
tipo Funcionaldiade) para o verde mais claro (instâncias do tipo Informação).
As regras de negócio que estão fora do software são identificadas em tons de cinza, que
vão do cinza mais escuro (instâncias do tipo Funcionaldiade) ao cinza mais claro
(instâncias do tipo Informação).
3.2. Aplicação das Restrições de FIR
No FIR-Diagram, a validação do diagrama está disponı́vel a partir de um item de menu
validate de Diagram, adicionado ao Eclipse quando o plugin FIR-Diagram é
instalado. Durante a validação, se algum elemento do modelo está violando umas das
restrições, ele é marcado com o ”x”destacado em vermelho, indicando um erro no dia-
grama. A lista de erros encontrados na validação é exibida na aba Problems do Eclipse
(Figura 2 (d)).
A Figura 2 (a) apresenta uma restrição 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
só poderá ser executada se existir um CPF válido. Após a execução da regra R1, uma
informação deve ser produzida (Torcedor-CPF). Na Figura 2 (b), esse elo de produção
foi retirado propositalmente para a demonstração de outra restrição: um informação sem-
pre é proveniente de uma regra (Produção). As regras R5 ,R6 e R7 não fazem parte do
10
(a) Funcionalidade inválida (b) Regra inválida
(c) Informação inválida (d) Aba Problems
Figura 2. Validações do FIR-Diagram
software de emissão de ingressos, mas precisam ser representadas no diagrama pois são
regras do negócio. Elas são representadas com uma coloração diferente das regras que
fazem parte do software. Para ter acesso ao jogo, o CPF que consta no documento de
identificação do torcedor deve ser igual ao CPF impresso no ingresso (I4 ). Essa regra
(R5 ) não está implementada no software e consome a informação (I4 ) produzida dentro
do software. Para violar essa restrição, retiramos a relação de consumo, como ilustra a
Figura 2 (c). Se nenhuma das restrições for violada, pode-se afirmar que o diagrama com
instâncias do FIR é válido (Figura 1).
3.3. Descoberta de Impactos
Para a descoberta de impactos foram considerados os elos de dependência entre os ele-

mentos do modelo. O algoritmo determina as regras que serão impactadas para mudanças
que ocorrem em regras do modelo. A descoberta de impactos é realizada em termos de
operações sobre um grafo que o diagrama representa.
O algoritmo de descoberta de impactos é executado quando uma regra é selecio-
nada no modelo. Através da informação produzida pela regra selecionada, o algoritmo
percorre a lista das regras que dependem da informação produzida e adiciona a regra
dependente na lista de impactos da regra selecionada. O algoritmo é executado recursiva-
mente para cada regra dependente. Ao final, as regras impactadas são exibidas com um
cı́rculo vermelho.
A Figura 3 mostra a descoberta de impactos para a regra R1 . A regra R1 produz
uma informação (Torcedor-CPF) que é consumida pela regra R4 , que, por sua vez,
produz uma informação (Ingresso-CPF) que é consumida pela regra R5 . Caso uma
mudança ocorra na regra R1 , a informação produzida poderá ser alterada e as regras R4 e
R5 devem ser manualmente avaliadas com o objetivo de descobrir impactos.
11
Figura 3. Impactos de Mudança na regra R1
4. Conclusão
Este artigo apresentou uma ferramenta baseada no modelo de rastreabilidade FIR
(Funcionalidade-Informação-Regra) para análise de impacto de mudanças baseada em
interesses de negócio. A ferramenta FIR-Diagram permite manipular instâncias dos
tipos de regras de negócio suportados pelo modelo FIR ao implementar dois requisitos-
chave: os conceitos e as definições do FIR, como, por exemplo, Q2 : A ferramenta deve
permitir a validação de instâncias de elementos a partir das restrições definidas para FIR
e Q3 : A ferramenta deve permitir a realização da atividade de descoberta de impactos
sobre uma instância de FIR.
A ferramenta é compatı́vel com a distribuição Eclipse Modeling
Tools e o código fonte do projeto está disponı́vel a partir do endereço
https://firplugin.googlecode.com/svn/trunk/, sob a licença Eclipse Public License
1.0.
Como trabalhos futuros, destacamos: (1) Controle de Granularidade: O mo-
delo FIR apresenta uma granularidade muito fina das regras de negócio e a ferramenta
FIR-Diagram pode implementar alguma estratégia para que o usuário tenha controle
sobre essa granularidade, e (2) Rastreabilidade Horizontal: O modelo FIR deve ser apri-
morado para suportar uma rastreabilidade horizontal com o código fonte e a ferramenta
FIR-Diagram também deve ser estendida para este fim.
Referências
Arnold, R. S. (1996). Software Change Impact Analysis. IEEE Computer Society Press.
Group, B. R. (2010). Definition of business rules - http://www.businessrulesgroup.org.
Leite, J. and Leonardi, M. C. (1998). Business rules as organizational policies. In IWSSD’98: Proc.
9th Intl Workshop on Software Specification and Design, page 68, Washington, DC, USA. IEEE
Computer Society.
Oliveira Filho, A. (2010). Uma técnica de rastreabilidade para análise de impacto de mudanças em
interesses de negócio. Master’s thesis, Universidade Salvador (UNIFACS).
Oliveira Filho, A., de Mendonça Neto, M. G., and von Flach G. Chavez, C. (2008). Em busca de
agilidade na análise de impacto: O artefato fir. Latin America Transactions, IEEE, 6(3):275–281.
Raja, U. A. and Kamran, K. (2008). Framework for requirements traceability - tlfrt supporting pre-rs
& post-rs traceability. Master’s thesis, Blekinge Institute of Technology, School of Engineering.
12
Uma Ferramenta de Apoio à Gerência 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
Laboratório de Engenharia de Software (LABES) – Universidade Federal do Pará

(UFPA) – Belém – 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. Introdução
Requisitos constituem a base para o desenvolvimento de software bem como para a sua
validação e aceitação junto ao cliente. Contudo, apesar de inúmeros trabalhos
desenvolvidos na área de Engenharia de Requisitos, a instabilidade dos requisitos
durante, e até mesmo após, o processo de desenvolvimento é constante [Pressman
2005]. Tais mudanças geram custos adicionais e mudanças no planejamento que devem
ser gerenciadas e controladas.
Nesse sentido, Sommerville (2006) define uma divisão da Engenharia de
Requisitos em quatro fases: (1) Levantamento dos Requisitos, cujo objetivo é
determinar o que o sistema deve fazer; (2) Especificação de Requisitos, em que é
elaborada a documentação dos requisitos coletados na fase anterior, gerando como
produto de trabalho o Documento de Requisitos; (3) Validação dos Requisitos, cujo
objetivo é eliminar possíveis inconsistências, falhas ou ambigüidades no documento de
requisitos e torná-lo completo; e (4) Gerência de Requisitos, que é o processo de
compreender e controlar as mudanças nos requisitos, desenvolvido por todo o ciclo de
vida do processo de desenvolvimento de software.
Para apoiar o processo de mudança 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 relação de predecessor sucessor ou de mestre
subordinado com outro [IEEE 1990]. Dessa forma, a rastreabilidade é essencial para a
realização da análise de impacto de mudança de requisitos. Um exemplo disso seria
utilizar os rastros de um requisito para identificar de que forma uma mudança impacta
nos planos do projeto que contêm as estimativas aprovadas de esforço e custo para os
produtos de trabalho e tarefas, bem como os códigos de unidade ou módulos do
software que necessitam ser modificados.
13
Entretanto, apesar de ser imprescindível o apoio de ferramentas específicas
dentro do processo de desenvolvimento de software nas atividades de Gerência de
Requisitos, as ferramentas atuais normalmente tratam os requisitos de forma isolada das
demais informações inerentes ao contexto do processo de software [Jacobs 2007] ou
fornecem apenas parte do apoio necessário para o gerenciamento dos requisitos.
Além disso, o uso do ambiente WebAPSEE em iniciativas de melhoria de
processo de software vêm ressaltando a necessidade de associar uma ferramenta de
apoio à Gerência de Requisitos integrada a definição 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, manutenção e controle
de mudança de requisitos e é integrada ao ambiente WebAPSEE [Lima Reis e Reis
2007], permitindo, de maneira facilitada, a associação 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 seção 2, a ferramenta WebAPSEE
Requirement Manager é descrita em termos de funcionalidades e arquitetura
implementada. Na seção 3, um exemplo de utilização da ferramenta é apresentado. Na
seção 4, uma comparação com trabalhos relacionados é feita. Por fim, na seção 5 são
discorridas as considerações 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 definição e
execução de processos de software de maneira flexível, além de manter um conjunto de
informações organizacionais.
O ambiente WebAPSEE implementa uma arquitetura cliente/servidor, que
contém três clientes: (a) Manager Console, direcionado aos gerentes, que permite a
definição, planejamento e acompanhamento da execução de processos de software, além
do gerenciamento dos dados organizacionais, coleta de métricas, geração de relatórios,
etc.; (b) Task Agenda Desktop, que provê aos agentes alocados em um processo todas as
informações necessárias para execução da suas atividades (prazos, artefatos de entrada,
artefatos de saída, pessoas envolvidas, estimativa de horas, etc.), além de permitir o
feedback desses agentes sobre o andamento de suas tarefas a partir da interação (ações
de iniciar, pausar, delegar, finalizar) com a máquina de execução 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 são apresentadas as principais funcionalidades da
WARM e uma visão geral da arquitetura implementada.
2.2. Funcionalidades
Do ponto de vista do usuário, as principais funcionalidades fornecidas pela ferramenta
WARM são: Gerenciar Requisitos: criação, recuperação, edição e remoção de
requisitos; Gerenciar Casos de Uso: criação, recuperação, edição e remoção de casos
14
de uso; Gerenciar Rastreabilidade de Requisitos: criação, edição e remoção 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 Mudanças de Requisitos: registro de mudança de um
requisito e versionamento de requisitos; Gerenciar Baselines de Requisitos: criação de
baseline de requisitos e controle de versões sobre baselines; Visualizar Árvore de
Impacto: visualização da árvore de impacto de um requisito (contemplando todos os
seus rastros existentes); Visualizar Matriz de Rastreabilidade: visualização de matriz
de rastreabilidade (sendo uma para cada par de componentes relacionados) e Emitir
Relatórios: geração de uma Lista de Requisitos com os requisitos associados com um
determinado sistema dentro do ambiente e geração de um Relatório de Impacto de
Mudança para um dado requisito.
2.5. Arquitetura
Uma visão geral da arquitetura da ferramenta WARM é mostrada na Figura 1. Esse
projeto arquitetural foi desenvolvido visando a integração com o ambiente WebAPSEE
do ponto de vista de três aspectos principais: dados, controle e apresentação.
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 integração dos dados (componente WARM Server) foi tratada a partir da
reutilização 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, Mudança, Rastros, etc. A integração de controle
(Interface WARM) foi implementado através da criação de um interface de serviços
RMI específica para a ferramenta, que permite a interação com outros componentes
internos, tais como: o de Modelagem de Processos, que gerencia o acesso as entidades
que compõem um processo dentro do ambiente. A integração de apresentação
(Componente WARM Client), por sua vez, foi realizada a partir do uso da mesma
tecnologia de desenho para interface gráfica utilizada pelo WebAPSEE, o pacote Swing
e suas extensões da linguagem Java, além da reutilização dos padrões de interface pré-
existentes no ambiente, como o layout de apresentação dos formulários de cadastro e de
geração de relatórios. Por fim, vale ressaltar que todos os componentes da ferramenta
WARM estão contidos internamente em componentes maiores do ambiente WebAPSEE
(Componente WebAPSEE Manager Console e Componente WebAPSEE Server).
3. Exemplo de Utilização
Nesta seção é apresentado um exemplo de utilização da ferramenta para mostrar a
aplicabilidade da mesma em termos práticos. Para tanto a ferramenta foi utilizada em
15
um projeto real de desenvolvimento de software em execução no Laboratório 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 questão, foi possível extrair os seguintes dados para utilização no apoio à
gerência de requisitos: requisitos, casos de uso, artefatos, atividades e colaboradores.
Os requisitos e casos de uso descritos no documento de Especificação de
Requisitos do projeto SIGAP [Lemos et al. 2009] foram cadastrados na ferramenta e as
demais informações foram obtidas a partir do ambiente WebAPSEE, onde o processo
foi modelado e executado.
Para efeito de exemplo será apresentada apenas a visualização da rastreabilidade
de dois requisitos funcionais: RF 01, “Autenticação de Usuário”; RF 02, “Acesso a
Usuário Não Cadastrado”.
Figura 2 - Rastreabilidade Vertical (requisito x artefato, requisito x atividade e

requisito x agente)
Na Figura 2-A são mostrados os elos criados entre os dois requisitos
selecionados com o artefato “SIGAP COLETA - Especificação de Requisitos”. Após a
criação manual desses elos, a ferramenta gera automaticamente os elos de
rastreabilidade entre requisitos e atividades (somente para aquelas que têm o artefato
“SIGAP COLETA - Especificação de Requisitos” como artefato de entrada, portanto,
sendo impactada pelos requisitos) (Figura 2-B). E também são criados automaticamente
os elos entre requisitos e agentes (aqueles envolvidos nas atividades que são impactadas
pelos requisitos em questão) (Figura 2-C).
Nesta seção será apresentada uma tabela comparativa entre a ferramenta WARM e
outras ferramentas de propósito semelhante. O objetivo desta comparação é mostrar o
atendimento ao espectro de funcionalidades relativas à Gerência 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], módulo de gestão de requisitos da Estação Taba; e o CaliberRM [Borland
2010], ferramenta comercial da Borland.
16
A Tabela 1 apresenta uma comparação entre as ferramentas que apóiam o
processo de gerência de requisitos, com base em um conjunto de funcionalidades úteis
para a realização desse processo. Nessa tabela evidencia-se a completude da ferramenta
WARM no atendimento de tais funcionalidades.
Critérios/Ferramentas RequisitePro ReqManager CaliberRM WARM

Matriz de Rastreabilidade Sim Sim Sim Sim
Geração Automatizada de Elos Sim Não Parcialmente Sim
Sinalização de Mudança de Sim Não Sim Sim
Requisitos
Cascateamento/Herança de Elos Não Não Não Sim
Registro de Histórico de Não Não Sim Sim
Mudança em Requisitos
Baseline de Requisitos Não Não Sim Sim
Versionamento de Requisitos e Não Não Não Sim
Baseline de Requisitos
Árvore de Impacto Parcialmente Não Não Sim
Integração com PSEE Não Sim Não Sim
Relacionamento entre Não Não Não Sim
Requisitos e Atividades
Semântica dos Elos de Não Sim Não Sim
Rastreabilidade
5. Considerações Finais
A WARM é uma ferramenta que tem como propósito apoiar as atividades do
processo de Gerência de Requisitos, fornecendo apoio desde a criação de requisitos até
a análise de impacto decorrente de mudanças em requisitos, além de permitir o
acompanhamento do histórico de mudanças em requisitos.
As principais contribuições da ferramenta WARM são: a integração com um
ambiente de desenvolvimento de software centrado em processo, que minimiza a
replicação de informações com o uso de ferramentas separadas e otimiza o tempo de
trabalho do gerente de requisitos a partir da geração de rastros automáticos; o controle
sobre a evolução dos requisitos de um sistema, através das funcionalidades de controle
de versões de baselines de requisitos e versionamento de requisitos a partir de registro
de solicitações de mudanças.
Em trabalhos futuros, pretende-se trabalhar outros componentes relativos à
rastreabilidade de requisitos, tais como: pacotes de código, casos de teste, entre outros;
além 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 documentação e uma base de
exemplos podem ser encontrados em http://www.labes.ufpa.br/warm, sendo a mesma
aderente à licença GNU-GPL (General Public License).
17
Referências
Borland. Borland CaliberRM. Disponível em:
http://www.borland.com/br/products/caliber/rm.html. Acesso em: jun. 2010.
Falbo, R.; Martins, A.; Nardi, J. C. (2006) “ReqODE: Uma Ferramenta de Apoio à
Engenharia de Requisitos Integrada ao Ambiente ODE”. In: Sessão de Ferramentas
do XX Simpósio Brasileiro de Engenharia de Software. Florianópolis, 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 Don’t 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 práticas 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) “Laboratório de Engenharia de Software e Inteligência
Artificial: Construção do ambiente WebAPSEE”. In: ProQuality, v. 3, p. 43-48.
Pressman, Roger. S. (2005) Software Engineering: A practitioner’s approach, McGraw
Hill, 6th edition.
Rational. Rational RequisitePro. Disponível em: http://www-
01.ibm.com/software/awdtools/reqpro/. Acesso em: jun. 2010.
Sales, E. O.; França, B.; Lima Reis, C. A.; Reis, R. Q. (2009) “Utilização do Ambiente
WebAPSEE na Implantação do nível G do MPS.BR no CTIC-UFPA”. In: VIII
Simpósio Brasileiro de Qualidade de Software. Ouro Preto, Minas Gerais, Junho.
Sommerville, I. (2006) Software Engineering, Addison-Wesley, 8th edition.
TABA. Estação TABA, versão de demonstração. Disponível 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 , João Miranda3 , Paulo Meirelles3 ,
Luiz Romário Rios1, Lucianna Almeida3 , Christina Chavez1 , Fabio Kon3
1
Universidade Federal da Bahia (UFBA)
{terceiro,luizromario,flach}@dcc.ufba.br
2
Universidade Católica do Salvador (UCSAL)
joenio@perl.org.br
3
Universidade de São Paulo (USP)
{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 calcula-
tion 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 large-
scale source code analysis, and consequently we resort to source code analysis tools in
order to support some of our tasks. We have defined 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 visualiza-
tion, developed with the goal of fulfilling these requirements. Section 2 describes related
work. Section 3 describes Analizo architecture. Section 4 presents Analizo features. Sec-
tion 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 re-
quirements 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 CCCC Cscope LDX CTAGX CPPX

Language support C++, Java C C, C++ C C, C++
Extensibility No No No No No
Maintained Yes Yes No No No
Handles non-compiling code Yes No 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 fulfills 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 Output
Core
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,
2
we used the “module” concept as a general term for the different types of structures used in software
development, as classes and C source files
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. Wheeler’s 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 file 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 in-
terface 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, option-
ally 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
doxygen.org/
4
dwheeler.com/sloccount/
21
project-level, Analizo also provides basic descriptive statistics for each of the module-
level 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 defined attributes, Total number of mod-
ules/classes with at least one defined method, Total Number of Methods.
• Module-level metrics: Afferent Connections per Class, Average Cyclomatic Com-
plexity 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 im-
practical, error-prone and difficult to repeat. Analizo can process multiple projects in
batch and produce one comma-separated values (CSV) metrics data file for each project,
as well as a summary CSV data file with project-level metrics for all projects. These data
files can be easily imported in statistical tools or in spreadsheet software for further anal-
ysis. 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 fine-
grained scale. Analizo can process a version control repository and provide a CSV data
file 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 pro-
cessing each release of the project (see Section 4.3), the user can request the creation of an
evolution matrix from the individual data files. Figure 2(b) shows an excerpt of a sample
evolution matrix produced by Analizo.
5
References to literature on each metric were omitted because of space constraints.
6
graphviz.org/
22
main_window.c
25 thumbnail_bar.c
47 11
ewer.c 6 thumbnail.c
28 4 2
1 navigator.c 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 evo-
lution 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 Doxy-
parse – 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
softwarelivre.org/mezuro/kalibro/
8
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 ver-
sion 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 self-
documented 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 Com-
petence Center (CCSL-USP).
References
Amaral, V. (2009). Análise de evolucao de projetos de software livre através de matrizes de
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). Extração de informações de dependência entre módulos de programas c/c++.
Undergraduation course conclusion project, Universidade Católica do Salvador.
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 (WCRE’05).
Lanza, M. (2001). The evolution matrix: recovering software evolution using software vi-
sualization techniques. In IWPSE ’01: Proceedings of the 4th International Workshop on
Principles of Software Evolution, pages 37–42, 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 configuração
e interpretação de métricas de código-fonte. Undergraduation course conclusion project,
Universidade de São Paulo.
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 Com-
plexity 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 Mendonça
Departamento de Ciência da Computação – 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 Eclipse´s 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
Resulted Scenario
Java Source Abstract Syntax Visual

Code Tree provided and Scenario Scenarios
Model
used by Eclipse
View(s)
Model Mapping the Model
Information Mapping
Extraction to Each View
+
Control Software
Software
Maintenance
Maintenance Filters
Activity
Activity
TXT Log File
for Data
Egocentric
Treemaps Polymetric Graph Matrix Acquisition
Grid View Graph
View View View View of Primitive
View
Operations
(A) (B) (C)
Perspective 1 Perspective 2 Perspective 3
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). Node-
link-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. The SourceMiner plug-in, tutorial, screenshots and preliminary empirical study data are
available at http://www.sourceminer.org.
2. 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.
3. Lanza, M.; Ducasse, S. Polymetric Views - A Lightweight Visual Approach to Reverse
Engineering. In IEEE Transactions on Software Engineering (TSE), 2003.
4. M.-A. Storey. Theories, tools and research methods in program comprehension: past, present
and future. Software Quality Control, 14(3):187–208, 2006.
5. Wu, J., and M.-A. Storey. A multi-perspective software visualization environment. In
Proceedings of CASCON'2000, November 2000, pp. 41-50.
6. Shneirderman, B. Tree Visualization with Tree-Maps: A 2-D Space-Filling Approach. ACM
Transactions on Graphics (ToG) 11, 1 (1992), 92–99.
7. R. Lintern, J. Michaud, M.-A. Storey, and X. Wu. Plugging-in visualization: experiences
integrating a visualization tool with eclipse. In SoftVis 2003, USA.
8. 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.
9. 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. 80–86. Singapore, 1998.
10. Eick, S.; Steffen, J.; Eric S. SeeSoft—A Tool for Visualizing Line Oriented Software Statistics.
IEEE Transactions on Software Engineering, 18(11):957–968, November 1992.
11. Carneiro, G. F; Magnavita, R.; Spínola. E.; Spínola, F.; Mendonça Neto, M. G. . An Eclipse-
Based Visualization Tool for Software Comprehension. SBES Tools Session, 2008.
30
Hist-Inspect: Uma Ferramenta de Apóio à Avaliação Sensível
à História de Código
Leandra Mara, Gustavo Honorato, Francisco Dantas,
Alessandro Garcia, Carlos Lucena
1
Departamento de Informática – Pontifícia Universidade Católica 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 influence of considering his-
toric properties of evolving code in the detection of modularity flaws. A key
reason is the lack of adequate tooling support for history-sensitive anomaly de-
tection. This paper presents a tool that allows the specification and evaluation
of different configurations of detection strategies by means of a domain-specific
language (DSL). The proposed tool enables empirical assessments of both con-
ventional and history-sensitive strategies and also offers developers a flexible
environment for defining and applying these strategies. Evolution charts and
history-sensitive metrics are also made available.
1. Introdução
Uma estratégia de detecção [1] é uma condição lógica composta por métricas e respectivos
valores limites que detecta elementos com anomalias de modularidade1 [2]. Seu grande
benefício é que o desenvolvedor pode localizar diretamente classes e métodos afetados
por uma dada anomalia, em vez de ter que inferir o problema a partir de um extenso
conjunto de valores anormais de métricas. Um problema central de estratégias de detecção
convencionais é que elas ainda resultam em um considerável número de falsos positivos
e negativos [3]. Dessa forma, há a necessidade de pesquisas que explorem melhor a
composição de estratégias de detecção visando aumentar a eficácia das detecções. Sabe-
se, contuto, que um requisito fundamental para tais pesquisas é o suporte adequado de
ferramentas que automatizem tais estratégias.
Alguns pesquisadores [3] acreditam que uma possível limitação das estratégias
convencionais [1] é que, apesar de atualmente o desenvolvimento de sistemas ser cada
vez mais incremental, elas não levam em consideração a história de evolução dos módu-
los para detectar possíveis anomalias. Dessa forma, elas perdem informações importantes
como instabilidade dos módulos, aumento contínuo de complexidade, dentre outras. Ape-
sar dessas suspeitas, poucos trabalhos na literatura têm investigado como informações bá-
sicas sobre a evolução dos módulos podem: (i) auxiliar na detecção eficaz de anomalias
de modularidade, e (ii) contornar limitações das estratégias baseadas em análises indi-
viduais de versões de programas. Um dos fatores que limitam tais pesquisas é que as
ferramentas de detecção existentes [4, 5, 6, 7] não dão suporte ao cálculo de métricas sen-
síveis à história e, dessa forma, não disponibilizam estratégias que permitam considerar
o histórico evolutivo das propriedades do código. Além disso, a maioria disponibiliza ao
1
Neste artigo, usaremos o termo anomalias de modularidade (ou, simplesmente, anomalias) como sinô-
nimo ao termo em inglês code smells [2].
31
usuário pouca ou nenhuma liberdade para a criação de novas combinações de métricas e
valores limites que integram uma estratégia (Seção 2).
Este trabalho apresenta a ferramenta Hist-Inspect (Seção 3) que, além de suportar
a apresentação de gráficos de evolução e de métricas sensíveis à história, como principal
contribuição possibilita a especificação de diferentes estratégias de detecção através de
uma linguagem específica de domínio (DSL) [8]. Tal flexibilidade atende necessidades
de dois grupos de usuários: desenvolvedores interessados em ajustar valores limites ou
combinações de métricas para a detecção de anomalias; e pesquisadores interessados na
avaliação e comparação da eficácia de diferentes estratégias, sejam elas convencionais ou
sensíveis à história. A última seção do artigo (Seção 4) apresenta conclusões e direções
de pesquisas futuras utilizando os recursos desta ferramenta.
2. Limitações de Ferramentas Relacionadas

Algumas ferramentas de detecção têm sido propostas como a Together [4], inCode [5],
iPlasma [6] e inFusion [7]. Todas fornecem ao usuário informações sobre entidades com
certas anomalias de modularidade. Porém, nenhuma delas apresenta flexibilidade quanto
à criação e alteração de estratégias utilizadas. Elas também não dão suporte a métricas
e estratégias de detecção que levem em consideração a história de evolução dos módu-
los. Nesse caso, podemos citar algumas limitações relacionadas à criação de estratégias
convencionais.
Por exemplo, em ferramentas clássicas como o Together [4] ou mesmo a inCode
[5], os algoritmos de detecção são definidos em âmbito de código por desenvolvedores, ao
invés de poderem ser especificados em alto nível por especialistas no domínio de detecção
e avaliação de código. A falta de possibilidade de incluir ou alterar estratégias torna com-
plicado adaptá-las a diferentes contextos ou necessidades de usuários, ou ainda, comparar
os resultados de diferentes estratégias. A rigidez dessas ferramentas limita as decisões
sobre anomalias, métricas e valores limites considerados, ao grupo de desenvolvedores
que as desenvolveu. Sendo assim, nenhuma customização é disponibilizada ao usuário e
qualquer necessidade de alteração remete à necessidade de alterações a serem realizadas
exclusivamente no código pelos desenvolvedores dessas aplicações.
Outras ferramentas como a iPlasma [6] e a inFusion [7] até disponibilizam a con-
figuração de estratégias em nível mais elevado, ou seja, em nível de usuário. Porém, (i)
as customizações são limitadas pelo uso de elementos e operações disponíveis em uma
interface de configuração e (ii) as novas estratégias não podem ser salvas para inspeções
futuras. Nessas interfaces de configuração, não se consegue, por exemplo, especificar
uma estratégia que contenha a expressão m1 /m2 ou a expressão m1 > m2 , onde m1 e m2
são métricas. A falta de suporte a avaliações que levem em consideração a evolução do
código associada à inflexibilidade quanto à adição e alteração de estratégias de detecção,
são algumas das limitações deixadas pelas ferramentas existentes.
3. A Ferramenta Hist-Inspect
O ambiente Hist-Inspect2 tem como objetivo principal apoiar a aplicação de estratégias
de detecção sensíveis à história. Contudo outros recursos sensíveis à história também são
disponibilizados como gráficos de evolução das propriedades do código e métricas. Mais
de 40 métricas sensíveis à história foram criadas para que pudessem ser utilizadas em
2
Do inglês, History Sensitive Inspection
32
estratégias de detecção. A versão atual da ferramenta não efetua os cálculos de métricas
convencionais, pois muitas são as ferramentas que já disponibilizam tais cálculos. Por-
tanto, optou-se por priorizar o desenvolvimento de funcionalidades que não existiam em
ferramentas clássicas de detecção. Apesar dessa seção apresentar duas telas da ferramenta
(Figuras 3.a e 3.b), outras telas e artefatos, bem como o endereço para obtenção do código
fonte são disponibilizados no sítio dessa pesquisa3 .
3.1. Funcionalidades Principais

Suporte a Gráficos de Evolução. Ao se pensar em análise sensível à história, faz-se
necessário a observação de dados históricos que revelam o comportamento evolutivo do
sistema durante seu ciclo de vida. Por meio de gráficos (Figura 1.a), o avaliador pode
perceber a estabilidade, o crescimento ou decrescimento de uma dada propriedade (por
exemplo, linhas de código), sem ter que exatamente recuperar o valor dessa propriedade
em cada versão do módulo avaliado. Além disso, torna-se interessante poder visualizar o
comportamento de mais de uma métrica ao longo da história de um módulo, possiblitando,
inclusive, a descoberta de padrões de influência que uma propriedade teve sobre a outra.
A ferramenta proposta disponibiliza tal funcionalidade e para implementá-la foi utilizada
a biblioteca gráfica JFreeChart4 .
Suporte a Métricas Sensíveis à História. Métricas sensíveis à história (SHs) [3]
consideram a avaliação das características dos módulos ao longo do seu histórico de evo-
lução. Em sua grande maioria elas medem a evolução de métricas convencionais como as
de complexidade, coesão, dentre outras. A implementação dessas métricas foi motivada
pela necessidade de viabilizar a criação e aplicação de estratégias de detecção sensíveis à
história. Através do cálculo dessas métricas é possível obter informações como: a qua-
tidade de vezes que um dado módulo sofreu aumento de linhas de código ao longo de
sua história (rniLOC), a variação média de linhas de código em cada versão (rdocLOC),
o aumento percentual da complexidade de um módulo em relação a sua versão anterior
(rpiWMC), e assim por diante. Todas foram originalmente propostas no contexto dessa
pesquisa [9].
Suporte a Estratégias de Detecção. Para possibilitar a especificação declarativa
de diferentes configurações de estratégias a ferramenta utilizou uma Linguagem Especí-
fica de Domínio (DSL). O objetivo ao utilizar uma DSL foi proporcionar um alto nível
de flexibilidade na especificação dessas estratégias, provendo assim uma funcionalidade
que não é encontrada em nenhuma das ferramentas relacionadas. A linguagem de es-
pecificação é uma DSL Interna [8], nomeada DSSL5 . Reutilizamos um interpretador de
JavaScript para construir a linguagem. Portanto, os mesmos mecanismos sintáticos da
linguagem base (neste caso o JavaScript) são disponibilizados no vocabulário de nossa
DSL. A Equação 1 mostra um exemplo de criação de uma estratégia de detecção sensível
à história utilizando DSSL.
rdocLOC > 10 && rniWMPC1 >= 0.4 (1)
É possível observar através da Equação 1 que a criação de novas estratégias com
DSSL é uma tarefa com alto nível de abstação. Dessa forma, exclui-se a necessidade de
3
http://www.inf.puc-rio.br/ lsilva
4
http://www.jfree.org/jfreechart/
5
Do inglês, Detection Strategy Specification Language (Linguagem de Especificação de Estratégias de
Detecção)
33
se utilizar recursos de programação como a criação de classes e algoritmos, o que seria
necessário em ferramentas como a Together, por exemplo. Na Equação 1, os elementos
rdocLOC e rniWMPC1 são métricas sensíveis à história [9]. A Figura 1.b apresenta um
relatório de detecção com os resultados da detecção de uma estratégia SH.
(a) Apresentação de Gráfico de Evolução (b) Relatório HTML de Detecções

Figura 1. Funcionalidades Básicas da Hist-Inspect
3.2. Arquitetura e Funcionamento

Essa seção apresenta o fluxo de funcionamento e alguns aspectos técnicos da ferramenta
proposta. As funcionalidades da Hist-Inspect foram implementadas em dois módulos se-
parados utilizando a linguagem Java. O primeiro é um módulo de geração de gráficos de
evolução implementado através da plataforma Eclipse. O segundo é um módulo de gera-
ção de relatórios de detecções, resultantes da aplicação de estratégias de detecção. Esse
segundo módulo, por enquanto, é disponibilizado através de uma interface de linha de
comando. Entretanto, existe a intenção de migrá-lo para que também esteja sobre a plata-
forma do Eclipse. Por limitações de espaço, iremos apresentar apenas o segundo módulo,
pois possui as funcionalidades que julgamos mais relevantes ao contexto de estratégias de
detecção. Os elementos integrantes desse módulo são apresentados pela Figura 2.
Como mostra a Figura 2, o módulo toma como entrada um arquivo chamado Lista
de Arquivos de Métricas. Essa lista, por sua vez, possui a localização de outros arquivos
que possuem os valores de métricas convencionais calculados em cada uma das versões
do sistema. Já o Oráculo de Anomalias é uma entrada opcional e apenas é fornecida se
o usuário desejar calcular medidas de precisão e revocação dos resultados gerados por
uma estratégias de detecção. Ambas as entradas são implementadas através de arquivos
XML. Os n arquivos com as métricas convencionais das n versões do sistema são arquivos
.mtbl6 que são gerados através da ferramenta Together. Conforme justificado na Seção
3, optou-se por não efetuar o cálculo de métricas convencionais, uma vez que muitas
ferramentas já disponibilizam tais resultados. Nesse caso, são utilizados os resultados de
métricas convencionais geradas pela Together [4], escolhida, principalmente, por ser uma
ferramenta de medição bem conhecida e aceita.
O elemento Parser, na Figura 2, transforma a representação textual do XML de
entrada em um modelo de domínio a ser utilizado pela aplicação. Entretanto, o modelo
gerado pelo Parser armazena apenas informações de métricas convencionais. O Gerador
do Modelo SH é quem lê as Especificações das Métricas Sensíveis a História e transforma
o modelo convencional em um Modelo Senvível à História. Grande parte do Parser foi
6
Extenção do arquivo gerado pelo Together com os resultados de métricas convencionais solicitadas.
34
Entrada Hist-Inspect Saída
(Módulo de Estratégias de Detecção)
Oráculo de
Anomalias
Avaliador
Gerador do de Regras Gerador de
Métricas (V.1) Parser Modelo SH Modelo SH DSSL Relatórios
Relatório
Métricas (V.2)
de Detecção
Lista de
...
arquivos de
métricas
Especiﬁcação Catálogo Catálogo Templates
de de Regras de
Métricas (V.n) Métricas SH em DSSL Anomalias
Figura 2. Funcionamento e Elementos Principais da Arquitetura da Hist-Inspect
gerado utilizando o framework XMLBeans7 , enquanto a Especificação de Métricas SH

foi feita através de classes que implementam uma interface Java específica para tais mé-
tricas. A partir do Modelo com Métricas SH de cada entidade é transferida ao Avaliador
de Regras a responsabilidade de realizar as detecções. Nesse caso, tal elemento carrega
dois catálogos, um contendo as especificações das regras ou estratégias de detecção e ou-
tro contendo as anomalias de modularidade a serem consideradas. Esses dois catálogos
são implementados através de arquivos XML, como ilustra a Figura 3. O Avaliador de
Regras gerencia o contexto de execução do JavaScript, criando as variáveis que represen-
tam as métricas e atribuindo os seus respectivos valores dependendo do entidade que está
sendo avaliada no momento (pacote, classe ou método). Finalmente, as regras indicadas
pelo atributo expression (Figura 3a) são aplicadas aos módulos do sistema. Caso a
expressão de detecção seja verdadeira para uma determinado módulo, o Avaliador de Re-
gras destaca a ocorrência da anomalia. A anomalia avaliada pela regra é indicada pelo
elemento anomaly.
(a) Catálogo XML de Estratégias (b) Catálogo XML de Anomalias
Figura 3. Exemplos de Especificação de Estratégias e Respectivas Anomalias
Finalmente, como mostra a Figura 2, o Gerador de Relatórios combina as infor-

mações produzidas pelo Avaliador de Regras com um Template HTML, gerando o Rela-
tório que será apresentado ao usuário. O Gerador de Relatórios processa templates de
relatórios utilizando a linguagem de templates Velocity8 . Opcionalmente, também é pos-
sível inserir nesse relatório de detecções informações sobre falsos positivos e negativos,
7
http://xmlbeans.apache.org/
8
http://velocity.apache.org/
35
precisão e revocação das estratégias aplicadas. Esses são calculados a partir do elemento
Oráculo de Anomalias. A Figura 1 apresenta um exemplo de relatório HTML de detecção
gerado pela ferramenta.

Este artigo apresentou uma visão geral da Hist-Inspect, uma ferramenta que como carac-
terística principal suporta a especificação e execução de estratégias de detecção. Atual-
mente, através da Hist-Inspect, algumas evidências iniciais já puderam ser geradas sobre
a eficácia de estratégias de detecção sensíveis à história [9]. Comparações com estratégias
convencionais também foram facilitadas. Por exemplo, em estudo recente [9], observou-
se que em 7 versões de um sistema, estratégias sensíveis à história se apresentaram efi-
cazes na detecção de anomalias clássicas de modularidade como God Class, Divergent
Change e Shotgun Surgery [2]. Novos estudos experimentais sobre detecção de anoma-
lias já estão sendo realizados e outros planejados.
Algumas melhorias técnicas para a Hist-Inspect também podem ser sugeridas. Por
exemplo, a especificação das métricas sensíveis à história atualmente é feita usando clas-
ses Java. Entretanto, no futuro elas poderiam ser implementadas utilizando uma lingua-
gem de Script (como Java Script, Rubby ou Lua) ou uma nova DSL. Tal fato, possibilitaria
a criação e obtenção de resultados de novas métricas SHs sem a necessidade de recom-
pilar todo o código. Como melhoria funcional relacionada aos gráficos, no futuro eles
poderiam fornecer uma visão panorâmica do número de anomalias presentes ao longo
das versões do sistema. Tal informação poderia fornecer uma idéia sobre a depreciação
do código relativa ao crescimento ou decrescimento de anomalias ao longo do histórico
do sistema.
Referências
[1] M. Lanza, R. Marinescu, and S. Ducasse, Object-Oriented Metrics in Practice. Secau-
cus, NJ, USA: Springer-Verlag New York, Inc., 2006.
[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. 3–7.
[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-specific languages: an annotated biblio-
graphy,” SIGPLAN Not., vol. 35, no. 6, pp. 26–36, 2000.
[9] L. Mara, F. Dantas, G. Honorato, A. Garcia, and C. Lucena, “Detectando anomalias de
código em evolução: O que a história pode revelar?” in SBCARS ’10 (submetido),
Salvador, BA, Brasil, 2010.
36
AssistME – uma Ferramenta para Auxiliar a Refatoração
para Aspectos de Tratamento de Exceções
Cristiane Queiroz1, Fernando Castor2, "élio Cacho3
1
Departamento de Sistemas e Computação – Universidade de Pernambuco
(UPE) – Recife, PE - Brasil
2
Centro de Informatica – Universidade Federal de Pernambuco
(UFPE) – Recife, PE - Brasil
3
Escola de Ciência 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 error-
prone activity. This paper presents AssistME, a tool that assists developers in
refactoring Java exception handlers to aspects.
1. Introdução
A técnica de tratamento de exceções é utilizada no desenvolvimento de sistemas com a
finalidade de aumentar a robustez dos mesmos, pois esta técnica torna possível a
detecção, a sinalização e o tratamento de erros. Porém, nos mecanismos tradicionais,
como o de Java, os tratadores são implementados em vários componentes, ficando
espalhados por todos eles, o que pode dificultar o entendimento, a manutenção e
principalmente o reuso destes componentes.
Para reduzir tais problemas, vários trabalhos [Lippert e Lopes 2000, Laddad
2003, Castor et al. 2009] sugerem utilizar a Programação Orientaada a Aspectos (POA)
para localizar os tratadores de exceções em aspectos, de modo a reduzir esse
espalhamento. Essa técnica pode, inclusive, ser empregada para melhorar a estrutura de
sistemas pré-existentes. Basta, para isso, que os tratadores de exceções desses sistemas
sejam extraídos para aspectos por meio de refatorações.
Infelizmente, a refatoração de tratamento de exceções para aspectos em sistemas
de software é dispendiosa e sensível a erros, uma vez que existem vários fatores[Castor
et al. 2009] que precisam ser levados em consideração. Tais fatores, quando
combinados, podem resultar em: (i) tratadores muito difíceis de extrair; e (ii) problemas
sutis que fazem com que a extração dos tratadores para aspectos deixe de ser benéfica
para a qualidade do sistema, quando leva-se em conta robustez e modularidade. Nestes
casos, o programador deve analisar cada característica e decidir entre refatorar ou não.
Este artigo apresenta a AssistME (Assistance for the Modularization of
Exceptions), uma ferramenta que auxilia no processo de refatoração de tratamento de
exceções de Java para AspectJ. AssistME funciona como um plugin para o Eclipse e
identifica os fatores importantes para a extração do tratamento de exceções para
aspectos, indicando-os para o desenvolvedor. Os principais diferenciais desta
37
ferramenta são dois: (i) é totalmente focada no tratamento de exceções e (ii) lida com
uma grande quantidade de cenários documentados na literatura [Castor et al. 2009].
2. Motivação
Nos últimos anos, muitos trabalhos têm focado no desenvolvimento de catálogos de
refatorações, técnicas 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 refatorações específicas para a extração de tratamento de exceção
para aspectos. Em alguns casos [Laddad 2003] nem as pré-condições nem a mecânica
dessas refatorações são explicadas, o que torna difícil utilizá-las na prática. Em outros
[Cole e Borba 2005], em consequencia da ênfase no rigor da preservação do
comportamento dos programas-alvo de refatorações, as pré-condições destas são
bastante restritivas.
Binkley et al. [Binkley et al. 2006] descrevem uma ferramenta chamada
AOPMigrator que automatiza a aplicação dessa refatoração. Porém, esta ferramenta
permite tal refatoração apenas em um conjunto restrito de situações. Tais situações são
justamente as mais simples, aquelas onde o auxílio de uma ferramenta é menos
importante. O único cenário de tratamento de exceções que a AOPmigrator cobre é
quando temos um bloco try-catch englobando todo o método, porém existem vários
outros cenários que a refatoração não poderia ser feita usando-se o AOPMigrator. Um
exemplo comum disso se encontra na Figura 1, onde existe um laço e, dentro do laço,
um tratador de exceção que usa o comando break. Ferramentas e refatorações
existentes ou não permitiriam a extração desse tratador (melhor) ou realizariam a
refatoração de forma errônea (pior), alterando o comportamento do programa. Situações
similares ocorrem quando há um return dentro do bloco catch e em algumas
situações onde o bloco try-catch está emaranhado, ou seja, misturado com o
restante do código do método.
Figura 1 –Exemplo de tratamento de exceções não coberto pelas ferramentas existentes.
3. AssistME
AssistME é um plugin para a IDE Eclipse1, de código aberto, cujo objetivo é fornecer
suporte à atividade de refatoração de tratamento de exceções. Esta ferramenta permite
que o desenvolvedor visualize mais rapidamente os fatores relevantes para a extração de
tratamento de exceções de Java para AspectJ. Por meio destes fatores o desenvolvedor
pode realizar a refatoração de modo a melhorar a qualidade do código e evitar que o
comportamento do programa seja modificado. Vale ressaltar que há refatorações
largamente automatizadas por ferramentas que, quando aplicadas sem cuidado, podem
introduzir bugs em um programa.
1 http://www.eclipse.org
38
Para realizar refatorações, os desenvolvedores devem observar atentamente
fatores como os descritos nesta seção. Alguns destes fatores são difíceis de perceber e,
se não levados em conta, podem causar erros sutis. Por causa disso, AssistME enfatiza a
realização dessas análises em detrimento da transformação propriamente dita do código.
Essa abordagem é consistente com a visão de trabalhos recentes que afirmam que a
transformação do código é a parte mais fácil da aplicação de uma refatoração [Ekman,
et al. 2008]. Além disso, ferramentas de refatoração em geral não indicam para usários
de forma explícita que elementos precisam ser levados em conta para que a refatoração
possa ser realizada. No caso da extração de tratadores de exceções para aspectos, essa
informação é fundamental porque muitas vezes o usuário pode decidir não realizar a
refatoração em certas situações, já que não traria benefícios para a qualidade do
programa [Castor et al. 2009].
AssistME é desenvolvida partindo do pressuposto de que, quando possível, o
ideal é fazer com que o advice tratador englobe todo o corpo do método onde aparecia,
já que esta é a solução mais simples possível (exige poucas modificações no código
original). Entretanto, há vários casos onde isso não é possível 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
código, e fora dele o comando throwException() lança uma exceção que se o
bloco try-catch englobasse todo o método iria ser capturado erroneamente pelo
bloco catch. AssistME indica as causas para esse tipo de situação, evitando que
programadores cometam erros durante o processo de refatoração. Exemplos de fatores
apontados pela ferramenta incluem: (i) emaranhamento de blocos try-catch, pois os
comandos que vêm antes e depois de tais blocos podem lançar exceções capturadas
acidentalmente por um advice que englobe todo o método; (ii) aninhamento de blocos
try-catch – quando um bloco try-catch se encontra dentro de um bloco try;
(iii) escrita e leitura de variáveis locais, atributos de classes e parâmetros de métodos,
além de invocações de métodos; e (iv) informações sobre as exceções, inclusive as não
verificadas, lançadas 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 método.

Um exemplo de como a AssistME mostra essas informações está na Figura 3.
Neste exemplo o bloco catch contém chamadas a métodos, realiza leitura e escrita de
variáveis locais e exceções são levantadas, tanto no bloco catch como antes do bloco
try. Essas exceções são propagadas, o que as tornam informações que um
programador não obteria simplesmente olhando para o código, principalmente as não
checadas. É importante enfatizar que não está fora de nossos planos ampliar o escopo do
AssistME para que, além de fornecer informações úteis para desenvolvedores, também
aplique as refatorações de forma automática.
39
Figura 3. Exemplo de como a AssistME mostra as informações.
Na Figura 4 é mostrado a ferramenta AssistME em execução. Nesta Figura estão
destacados alguns itens. No número 1 estão localizadas as pastas do projeto. O número
2 indica a view que é mostrada para o usuário com as informações coletadas do projeto
alvo. Os números 3 e 4 mostram bookmarks que foram criados com a finalidade de
facilitar a visualização do programador em relação aos tratadores que são relevantes
para a extração. Finalmente, o número 5 mostra um botão de “refresh”, para atualizar as
informações da view do AssistME quando o código mudar. Nesta Figura, com a
finalidade de exemplificar um resultado real, é mostrado os resultados da ferramenta
utilizando como exemplo um sistema de informação baseado em Web, o HealthWatcher
[Soares et al. 2002].
Figura 4. A ferramenta AssistME em execução.

Na Figura 5 é apresentado um exemplo que contém 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 contém leitura de variável
local e atributos da classe, e escrita a parâmetro do método. Além disso, como a
exceção capturada é do tipo java.lang.Exception, a ferramenta emite um alerta
informando que esta exceção é muito genérica. Este alerta aparece quando a exceção
capturada pelo catch é do tipo java.lang.Exception ou
java.lang.Throwable. O finally contém uma chamada a método que propaga
uma exceção. Para facilitar a visualização do programador, existem bookmarks nos
tratadores relevantes. Assim, se houvesse um catch dentro de um bloco tratador, ele não
apareceria na view, já que não é relevante para a refatoração, pois faz parte do interesse
de tratamento de exceções.
40
Figura 5. Um exemplo dos resultados produzidos pela AssistME.
4. Visão Geral da Arquitetura

A arquitetura estática da ferramenta AssistME é mostrada na Figura 6. No pacote
ControlPlugin se encontra o código responsável por manipular todo o sistema. Este
pacote recebe as entradas do usuário para a execução da ferramenta e as passa para a
classe ProjectProcessor que inicializa o compilador abc [Avgustinov, P. et al.
(2005)]. Este último é um compilador extensível para a linguagem AspectJ. Extensões
do abc são 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 cenários com tratadores de exceções
utilizando a AST do Polyglot, um dos frontends do abc. O Exception Flow analyzer
procura comandos que podem levantar exceções, utilizando para tanto o framework de
análise de bytecode Soot. As informações obtidas são 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 viável para o desenvolvedor utilizar a ferramenta. As características identificadas
são mostradas ao usuário por meio de uma view do Eclipse. Uma alternativa à utilização
do abc seria desenvolver a ferramenta como uma extensão do AJDT, um plugin para o
Eclipse que visa dar suporte a POA. Esta opção foi preterida, por dois motivos: (i) o abc
é mais extensível e (ii) porque o backend (Soot) do abc simplifica muito a realização
das análises de código (fluxo de exceções, em particular) exigidas pela ferramenta. A
principal consequência negativa desta decisão de projeto é que é caro, em termos
computacionais, atualizar as informações mostradas pela view do AssistME. Além
disso, nem todas as características da linguagem Java (por exemplo, generics) são
implementadas na última versão do abc. Da mesma forma, AssistME não trabalha com
programas que apresentam tais características.
5. Agradecimentos
Os autores gostariam de agradecer aos revisores anônimos pelos vários comentários
ú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 Ciência a Tecnologia para Engenharia de Software, financiado por CNPq e
FACEPE, 573964/2008-4 e APQ-1037-1.03/08. Nélio é parcialmente financiado pela
FAPERN, 013/2009- PPP III.
6. Conclusão e Trabalhos Futuros

Visando facilitar a tarefa de refatoração de tratamento de exceções, este trabalho
apresentou a AssistME, uma ferramenta que foi implementada com o intuito de auxiliar
o desenvolvedor na obtenção das pré-condições necessárias para extrair para aspectos o
tratamento de exceções de programas em Java. Pretendemos realizar uma avaliação
quantitativa da ferramenta por meio de um experimento controlado, comparando os
resultados obtidos por programadores usando e não usando a ferramenta, em termos de
tempo total e número de enganos cometidos. Além disso, pretendemos continuar a
implementação da mesma para que esta possa fazer as refatorações automaticamente,
não apenas para os casos simples de tratamento de exceções, mas para todos os casos
que possam ser extraídos para aspectos.
No endereço http://www.cin.ufpe.br/~fjclf/assistme está disponível a ferramenta,
tanto o jar para a execução da ferramenta, quanto seu código fonte.
Referências
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 123–134.
Torbjörn 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, 418–427, Ireland.
M. P. Monteiro e. M. Fernandes (2005). “Towards a catalog of aspect-oriented
refactorings”. In Proceedings of the 4th AOSD, pages 111–122.
Sérgio Soares, Eduardo Laureano, Paulo Borba (2002) "Implementing distribution and
persistence aspects with aspectJ". In Proceedings of OOPSLA 2002: 174-190.
42
ComSCId & DMAsp: Identificação de Interesses Transversais
e Recuperação de Modelos de Classes Anotados a partir
Aplicações OO Java
Paulo Afonso Parreira Júnior1¥, Heitor Augustus Xavier Costa2, Valter Vieira de
Camargo3µ , Rosângela Aparecida Dellosso Penteado4
1, 3, 4
Departamento de Computação – Universidade Federal de São Carlos
Caixa Postal 676 – CEP 13565-905 – São Carlos – SP – Brasil
2
Departamento de Ciência da Computação – Universidade Federal de Lavras
Caixa Postal 3037 – CEP 37200-000 – Lavras – MG – Brasil
1 3 4 2
{ 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. Introdução
A programação orientada a aspectos (POA) (Kiczales et al., 1997) é uma tecnologia que
tem como objetivo encapsular, em unidades específicas chamadas aspectos, interesses
(concerns) cuja implementação produz representações entrelaçadas (tangled) e
espalhadas (scattered) nos módulos funcionais do software. Tais interesses são
conhecidos como Interesses Transversais e sua identificação e modularização podem
melhorar a qualidade do código fonte produzido e facilitar sua manutenção.
Um processo de reengenharia que possui como objetivo a conversão de um
sistema Orientado a Objetos (OO) para um sistema Orientado a Aspectos (OA) não é
trivial. Na maioria das vezes, somente o código fonte do software legado está
disponível, fazendo com que o nível de qualidade das tarefas de manutenção seja
prejudicado (Pressman, 2006). É importante que seja recuperada a documentação por
meio de mecanismos de engenharia reversa o que permite que sejam tomadas decisões
quanto às modificações que podem ser realizadas tanto no nível de modelos quanto,
posteriormente, de linguagem de programação.
Neste artigo é apresentada uma solução para engenharia reversa de software OO
Java que permite recuperar modelos OO anotados com indícios de interesses
transversais a partir do código 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
elaboração de um modelo OO intermediário antes da obtenção de um modelo OA,
visando a melhorar a qualidade do processo de reengenharia de software OO para OA.
Para isso, são utilizados dois apoios computacionais denominados ComSCId
(Computational Support for Concerns Identification) - auxilia na identificação de
indícios de interesses transversais em softwares implementados em Java e DMAsp
(Design Model for Aspect) - gera modelos de classes OO anotados com indícios de
interesses transversais.
Este artigo encontra-se organizado da seguinte forma. Os apoios computacionais
ComSCId e DMAsp são apresentados nas Seções 2 e 3, respectivamente. Alguns
trabalhos relacionados são comentados na Seção 4 e as considerações finais estão na
Seção 5.
2. ComSCId (Computational Support for Concern Identification)
O apoio computacional ComSCId foi desenvolvido como um plug-in do Eclipse e
possibilita a identificação de indícios de interesses transversais em um software legado
OO implementado em Java. ComSCId emprega duas técnicas distintas para
identificação de interesses: (i) a baseada em texto, que trata do reconhecimento de
convenções de nomenclaturas de atributos, métodos, variáveis e classes; e (ii) a baseada
em tipo, que trata da identificação de declarações e usos de determinados tipos e seus
objetos.
O ComSCId possui a funcionalidade de (i) gerenciar regras para detectar
indícios de interesses transversais e (ii) indicar no código fonte do software os trechos
que são afetados por esses indícios.
2.1 Gerenciamento de Regras para Identificação de Interesses Transversais
A gerência dos indícios de interesses transversais é feita por meio dos seguintes passos:
(i) Selecionar a opção “Indication” da barra de menu principal (Figura 1); (ii) Selecionar
a opção “Manage...”; e (iii) Escolher uma das opções “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
Indícios de Interesses Transversais
Para melhor ilustrar os passos descritos anteriormente, algumas telas do plug-in

ComSCId utilizadas para cadastramento do interesse transversal de persistência são
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 Identificação de Convenções
de Nomenclatura no Código Fonte
Na Figura 3, as classes Date, DriveManager, DriverPropertyInfo,

SQLPermission, Time, Timestamp e Types que pertencem ao pacote java.sql são
cadastradas como indícios de interesses de persistência. Na Figura 4 é apresentado o
cadastramento de regras para capturar strings existente no código fonte quem
contenham os conjuntos de caracteres “insert into”, “select”, “update” ou “delete from”.
Essas regras foram criadas, pois a existência do interesse de persistência pode ser
indicada por meio do uso de comandos em linguagem SQL (Structured Query
Language) para inserção, atualização, remoção e consulta a dados. Os passos
necessários 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 indícios de interesses transversais originalmente contemplados pelo
ComSCId são: i) persistência em banco de dados (database persistence); ii) controle
registro de informações (logging); e iii) persistência em memória temporária
(buffering). Para cada projeto Eclipse, um diretório indications é criado contendo
um arquivo chamado indications.xml. Esse arquivo armazena os indícios de
interesses e suas regras para identificação cadastradas pelo engenheiro de software.
Assim, cada aplicação tem seu conjunto específico de regras para detecção de indícios
de interesse. Há também a possibilidade de importar um conjunto de regras de outra
aplicação. 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 Indicação de Indícios de Interesse Transversal no Código Fonte
A detecção dos indícios de um determinado interesse transversal é realizada quando a
aba “Indications” (Figura 1) é selecionada. Na Figura 5 são apresentadas as diferentes
visões dos indícios de interesse de persistência identificados pelo ComSCId em uma
classe denominada Conta.
Essa classe permite a realização de operações bancárias básicas como depósito,
saque e transferência e é entrecortada pelo interesse de persistência. Os resultados da
identificação de indícios são mostrados na visão de árvore de indícios (Figura 5 - a) ou
por meio dos pequenos símbolos em forma de prancheta localizados ao lado da linha de
código que possui o indício (Figura 5 - b).
45
(a) (b)
Figura 5. Diferentes visões dos Indícios de Interesses identificados pelo

ComSCId (a) árvore de indícios; (b) código fonte.
Durante a identificação de interesses transversais em um software, alguns
enganos podem ocorrer, como a identificação de falsos positivos e/ou falsos negativos.
Devido a restrição de espaço, esse assunto não será detalhado neste artigo. Mais
informações 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 indícios de interesses transversais em modelos de classe da UML. Os
indícios de interesses transversais são representados por meio de estereótipos associados
às classes, atributos e métodos.
A obtenção do modelo de classes anotado com indícios de interesses transversais
é feita por meio dos seguintes passos: (i) Selecionar a opção “Reverse Engineering” da
barra de menu principal do plug-in DMasp (Figura 6); (ii) Selecionar a opção
“Generating Annotated OO Class Model”. Na Figura 7 é apresentado o modelo de
classe recuperado a partir do código fonte da classe Conta (Figura 5).
Figura 6. Menu principal do plug-in DMasp

Figura 7. Classe Conta afetada pelo
interesse de persistência.
É possível observar que o atributo connection e os métodos sacar() e

depositar() apresentam estereótipos do tipo <<DatabasePersistence>>
indicando que eles são afetados pelo interesse de persistência. A existência de pelo
menos um elemento de classe (método ou atributo) com estereótipo
<<DatabasePersistence>> implica que essa classe também receberá esse
estereótipo. Salienta-se que atributos, métodos e classes/interfaces podem receber mais
de um estereótipo, por exemplo, <<DatabasePersistence>> e <<Logging>>.
As informações necessárias para gerar o modelo de classes são armazenadas em
um arquivo XML (XMLModel.xml). Esse arquivo é obtido após a execução do
46
ComSCId e é independente de qualquer ferramenta CASE. Além do arquivo XML, um
arquivo XMI é criado usando as informações presentes no arquivo XMLModel.xml. No
arquivo XMI as informações 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 reorganização das informações 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 versão 2.1 da UML. Além disso, Astah* possui uma
distribuição 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 informações existentes no arquivo XMLModel.xml segundo o
formato exigido pela ferramenta CASE desejada.
JQuery (Janzen and Volder, 2003) permite a busca de subconjuntos específicos de
elementos do código fonte e pode ser utilizada na identificação de indícios de interesses.
Garcia et al., (2004) propuseram uma abordagem para Reengenharia de Sistemas OO
para OA baseada em transformações e mineração de aspectos.
Com o enfoque diferente das demais ferramentas apresentadas, AOP Migrator
(Binkley et al., 2006) faz a refatoração de softwares em Java de modo iterativo. Sua
instalação depende de versões 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. Além disso, foi desenvolvida uma ferramenta
(FEAT – Feature Exploration and Analysis Tool) que permite identificar de forma
semi-automática os interesses do software e criar uma instância correspondente do grafo
de interesses.
A principal desvantagem dessas abordagens refere-se à customização das regras
para identificação de indícios de interesses. Por exemplo, para definir novas regras, o
engenheiro de software precisa conhecer a linguagem utilizada para reconhecimento de
padrões do FEAT ou do JQuery, o que torna o processo de identificação desses
interesses mais custoso e mais propenso a erros. Nesse sentido, a árvore de indícios e os
assistentes existentes em ComSCId apresentam maior facilidade de uso e maior enfoque
nas atividades de identificação de indícios. Outra vantagem do ComSCid em relação às
abordagens apresentadas é que ele pode ser integrado às versões mais atuais do
ambiente de desenvolvimento Eclipse.
Em relação ao DMasp, há poucos trabalhos que realizam a engenharia reversa
para obtenção de Modelos de Classes OA a partir dos códigos de softwares OO. Yang et
al., (2008) propuseram um framework de engenharia reversa orientado a aspectos para
ser acoplado na ferramenta XDRE, criada pelos próprios autores, que recupera
parcialmente diagramas UML de código C++. Este framework usa estereótipo e gera
modelos para a ferramenta CASE Rational Rose. O foco dessa abordagem está na
análise de requisitos, usa software legado escrito em C++ e não apresenta a construção
de um Diagrama/Modelo de Classes.
1
http://astah.change-vision.com/en/product/astah-community.html
47
5. Considerações Finais
Neste artigo foram apresentados dois apoios computacionais denominados ComSCId e
DMAsp, que auxiliam desenvolvedores/mantenedores na tarefa identificação de indícios
de interesses transversais e na recuperação de modelos de classes OO anotados com
esses indícios a partir de um software OO implementado em Java.
A geração de um Modelo de Classes OO Anotado pode trazer benefícios para o
processo de reengenharia de software, como (i) facilita a visualização dos interesses
transversais existentes no software e de seu nível de espalhamento/entrelaçamento com
os demais módulos do software; (ii) permite ao engenheiro de software responsável pela
reengenharia de software OO para OA articular e raciocinar como projetar os interesses
transversais identificados; e (ii) minimiza o gap semântico existente entre o código
fonte de um software OO e um modelo OA.
DMasp gera apenas diagramas de classes, porém, como trabalho futuro,
pretende-se estender esse apoio computacional para permitir a obtenção de outros
diagramas, por exemplo o de sequência. Salienta-se que os apoios computacionais
apresentados nesse artigo são software livre e estão disponíveis para download
juntamente as instruções para sua instalação por meio do link:
http://www.dc.ufscar.br/~paulo_junior.
Referências Bibliográficas
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., Lucrédio, D., Prado, A. F. do, Piveta, E. K., Zancanella, L. C., Almeida,
E. S. de, and Alvaro, A. “Reengenharia de sistemas orientados a objetos através de
transformações e mineração de aspectos”. Portuguese/Spanish Tracks In the Third
International Information and Telecommunication Technologies Symposium
(I2TS'2004), São 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 Júnior, P. A.; Costa, H. A. X.; Camargo, V. V.; Penteado, R. A. D. “Uma
Abordagem Iterativa para Identificação de Interesses Transversais com o Apoio de
Modelos de Classes Anotados”. In: IV Latin American Workshop on Aspect-
Oriented Software Development (LA-WASP 2010), 2010, Salvador/BA. I Congresso
Brasileiro de Software: Teoria e Prática, CBSoft, 2010.
Pressman, R. S. (2006) “Engenharia de Software”. 6ª edição. 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: Automação de Testes de Desempenho e
Estresse via Testes Funcionais
Ismayle de Sousa Santos1, Alcemir Rodrigues Santos1, Pedro de Alcântara dos
Santos Neto1
1
Departamento de Informática e Estatística – 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 validação de requisitos não-funcionais ainda são

pouco executados na maioria das organizações. Muitas são as causas, dentre
elas, a falta de pessoal especializado, alto custo e dificuldade no cumprimento
dos prazos. Por outro lado, com a predominância de sistemas Web, cada vez
mais são necessários a realização de tais testes. Neste trabalho é apresentada
uma ferramenta para a geração automática de testes de desempenho e
estresse. Além de gerar testes para requisitos não funcionais, a ferramenta,
denominada FERRARE GT, gera os registros no banco de dados a serem
utilizados na execução dos testes, a partir de informações relacionadas aos
testes funcionais.
1. Introdução
Com os usuários 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 aplicação. Dessa forma, o Teste é fator chave para o sucesso de
um projeto de software, seja qual for o processo utilizado.
Apesar de necessária, em geral, a realização de testes de software não tem sido
executada da forma ideal. Nem todos os requisitos de um software são corretamente
validados. Um fator de peso que contribui para essa situação 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 realização de testes
contribuem para reduzir os custos possibilitando a execução apropriada dos mesmos.
Uma categoria de teste comum em muitas organizações é 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 usuários em rede local.
49
O teste de estresse é similar ao teste de desempenho, no entanto, o contexto de execução
é elevado para níveis acima do normal. Os testes de desempenho e estresse ainda são
pouco executados, ainda que grande parte das aplicações atuais seja desenvolvida para
Web, onde tal tipo de avaliação seria de grande importância.
A partir desse cenário, observou-se que a criação de um mecanismo que
auxiliasse o desenvolvimento de testes de desempenho e estresse a partir de algum
artefato comum aos desenvolvedores, poderia resultar na redução dos custos associados
à criação dos mesmos. Por serem difundidos e possuírem boa parte das informações
necessárias, escolheu-se os testes funcionais como sendo este artefato e desenvolveu-se
a FERRARE [Santos et al. 2008]. Este protótipo inicial possibilitava a geração de
scripts1 de teste de desempenho a partir de scripts de testes funcionais.
Entretanto, apesar de auxiliar a implementação dos testes de desempenho e
estresse, a FERRARE não continha mecanismos de apoio a execução dos mesmos
quando esses exigiam uma preparação do ambiente de teste. Se o script gerado, por
exemplo, tivesse como objetivo a realização de 100 empréstimos de livros, poderia ser
preciso 100 exemplares e 100 usuários cadastrados no banco de dados da aplicação.
Desenvolveu-se então um algoritmo para replicação dos dados utilizados em um
teste funcional, possibilitando sua execução em diversas instâncias diferentes [Fé et. al.
2010]. Este algoritmo foi incorporado à ferramenta, doravante denominada FERRARE
GT, que é descrita neste trabalho. O nome FERRARE é acrônimo de FERRamenta para
Automação de testes de Requisitos de desempenho e Estresse, enquanto que “GT”
(Genesis Turbo) referencia o módulo responsável pela geração de dados.
Existem trabalhos que propõem a geração de testes de desempenho através de
modelos [Shams et. al. 2006]. Por outro lado, Bertolini et. al. (2009) propuseram quatro
técnicas de testes de caixa preta cujo objetivo é derrubar o sistema com a geração e
execução automática de testes de GUI (Graphical User-Interface). O trabalho
apresentado neste artigo se diferencia por não utilizar modelos e por utilizar scripts de
testes funcionais para gerar scripts de teste de desempenho, os quais serão executados
na ferramenta de teste de desempenho para a qual ele foi gerado.
2. Detalhes da arquitetura
A FERRARE GT é uma aplicação desktop desenvolvida em Java e cuja arquitetura é
apresentada na Figura 1.Ela é composta pelos módulos: Extractor, Generator e Genesis.
O módulo Extractor é responsável por receber como entrada um script de teste
funcional, desenvolvido em alguma ferramenta de teste funcional, e gerar, a partir desse
script, uma representação abstrata do mesmo independente da tecnologia associada à
sua criação. As principais classes associadas a essa representação são: TestCase,
representando um caso de teste; TestProcedure, representando um procedimento de
teste; Input e Output, para descrever as entradas e saídas. A criação dessa representação
é feita via análise sintática do script, observando os comandos utilizados e interpretando
suas ações.
1
Neste caso, se refere a um arquivo gerado por uma ferramenta de apoio ao teste funcional contendo a
sequência 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
módulo Extractor de forma que ele trabalhe com o que foi denominado Cartuchos de
Extração. Esses elementos contêm a implementação sobre como deve ser feita a
extração de informações do script de teste funcional para a representação abstrata
utilizada pela FERRARE. Com isso, é possível 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 estão implementados dois Cartuchos de Extração: o

SeleniumExtractor, referente a ferramenta Selenium IDE2 , e o CanooExtractor, ao
Canoo Web Test3. Eles foram implementados porque essas ferramentas são gratuitas e,
conforme pesquisas na Web, são bem difundidas dentre a comunidade de teste. No
entanto, a inserção de novos cartuchos à ferramenta é simples, bastando estender a
classe “BaseExtractor” e implementar os métodos de extração. Feito isso, o arquivo .jar
referente ao cartucho deve estar em uma pasta pré-definida para que seja identificado.
Após a criação da representação abstrata de um teste funcional são especificados
alguns parâmetros para a geração do teste de desempenho e estresse, tais como o tempo
de resposta esperado e quantidade de usuários simultâneos. Em seguida, a geração 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 restrições relacionadas ao modelo de dados e à lógica de
negócio da aplicação. Como os dados são replicados a partir das entradas existentes em
um teste funcional e cuja instância do banco de dados deve estar apta a executar,
réplicas geradas a partir desses dados também deverão 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
Usuário (IU), utilizados em um teste funcional, com as respectivas colunas do banco de
dados. Essa ligação permite identificar quais dados precisam ser replicados. Assim, se
2
http://seleniumhq.org/
3
http://webtest.canoo.com/
51
um teste funcional para um empréstimo em um sistema de uma biblioteca utiliza como
dados de entrada a matrícula de um usuário e o código de um livro, o Mapper requer
que o testador indique com quais colunas das tabelas do banco de dados tais entradas
estão associadas, conforme ilustrado na Figura 2. Com isso, é possível 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 módulo DataReplicator pode ser

iniciado. Para cada registro do banco associado ao teste funcional é gerada uma réplica.
Se houver associação de outros registros ao registro replicado, esses também são
replicados de forma que todos os dados sejam corretamente gerados e, assim, mantêm-
se a consistência para uso no teste de desempenho e estresse.
Um exemplo para ilustrar o processo de geração seria a réplica dos dados de um
exemplar associado a um livro. Para que sua réplica seja considerada correta, a
ferramenta deve replicar não somente os dados do Exemplar, como também os dados do
Livro associado ao Exemplar, gerando assim dois novos registros (exemplar e livro), ao
invés de gerar apenas um novo Exemplar. Esse processo é repetido até que sejam
gerados dados suficientes para o contexto do teste, que depende diretamente do número
de instâncias desejadas para execução (por exemplo, 100 usuários simultâneos).
Ressalta-se que o algoritmo de replicação desenvolvido (descrito com mais
detalhes em [Fé et al. 2010]), faz o tratamento de relacionamentos entre tabelas, bem
como segue as restrições especificadas no schema do banco, como por exemplo, a
unicidade de valores ou formatos específicos. Ao final da geração dos dados, estes são
disponibilizados para a módulo Generator, de forma que os testes de desempenho e
estresse possam ser gerados levando-os em consideração.
O Generator tem por objetivo gerar os scripts de testes de desempenho e
estresse para alguma ferramenta específica. Vale ressaltar que a FERRARE GT não
executa tais testes, ela gera os scripts de testes para execução na ferramenta desejada.
Dessa forma, questões como a restauração do banco ao estado inicial antes da execução
dos testes não são contempladas pela ferramenta. Antes de criar o script, os testes de
desempenho e estresse são gerados em uma representação interna da FERRARE GT,
independente de ferramentas de teste de desempenho e estresse. Tal representação é
52
composta com um conjunto de classes utilizadas para descrever um script de teste de
desempenho independentemente de comandos específicos.
O Generator utiliza o mesmo conceito de Cartuchos utilizados pelo Extractor.
Para a geração de scripts de teste de desempenho e estresse o testador deve indicar qual
o Cartucho de Geração a ser utilizado. Os Cartuchos de Geração são classes Java que
devem seguir convenções da FERRARE GT e devem implementar alguns métodos
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 fácil extensão 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 Extração adequado, para que
uma representação abstrata seja criada; iii) o Mapper solicita ao testador que faça o
mapeamento das entradas existentes no teste funcional e as respectivas colunas no banco
de dados da aplicação; iv) o testador informa os dados relacionados ao contexto da
execução dos testes de desempenho ou estresse e o cartucho de geração a ser utilizado;
v) o DataGenerator é acionado para gerar a quantidade de dados necessária, 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 implementação e execução de testes de desempenho e estresse. Verificou-se
com o experimento e através do teste t de student que os tempos gastos para realização
destes testes com e sem a FERRARE GT são diferentes e que a ferramenta de fato reduz
o tempo gasto nessa atividade.
53
4. Limitações
A FERRARE GT ainda possui limitações: i) seu funcionamento se restringe a
aplicações que utilizem o sistema de gerenciamento de banco de dados MySQL; ii) a
replicação de certos tipos de dados como dados criptografados e dados geográficos não
é suportada; iii) existem restrições para a geração de dados com formatos específicos
(tais como CPF, CNPJ); iv) os scripts de testes de desempenho não são gerados
corretamente caso o script de teste funcional não possua uma indicação das URLs
acessadas; v) a geração do teste baseia-se em um único teste funcional, não
representando de forma apropriada alguns cenários de execução interessantes; vi) o
mapeamento ainda depende muito da intervenção humana. Boa parte destas limitações
estão sendo resolvidas nas extensões da ferramenta.

Neste trabalho foi apresentada uma ferramenta para a geração de testes de desempenho e
estresse a partir de testes funcionais, denominada FERRARE GT. A ideia básica da
ferramenta é reaproveitar as informações existentes nos testes funcionais, de forma que
tanto os testes de desempenho e estresse, como os dados necessários para sua execução,
sejam automaticamente gerados.
A ferramenta já foi submetida a uso por diversos usuários, tendo sido inclusive
objeto de um estudo experimental. Nesse estudo ficou caracterizado que seu uso em
uma organização que já realize o teste funcional pode trazer redução de esforço a partir
da automação dos testes de desempenho e estresse. A ferramenta está disponível para
testes no sítio http://www.ufpi.br/pasn, sob a licença GNU LGPL (Lesser General
Public License). Como trabalhos futuros tem-se a resolução das limitações mencionadas
na Seção 4, bem como a implementação de novos extratores e geradores.
Referências
Pressman, R. (2006). Engenharia de Software. McGraw-Hill, 6th edição.
Santos, I. S. ; Araujo, F. F. B. ; Bezerra, R. S. ; Santos Neto, P. (2008). FERRARE -
FERRamenta de Automação dos testes de Requisitos de desempenho e Estresse. In:
Anais do II Escola Regional De Computação Ceará Maranhão Piauí, São Luiz, MA.
Fé, I. S. et al. (2010). Geração de Dados para Testes de Desempenho e Estresse a Partir
de Testes Funcionais. In: Anais do IX Simpósio Brasileiro de Qualidade de Software,
p. 89-101, Belém, 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. 54–61, 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. 21-
30, Los Alamitos, CA, USA.
54
ModelT2: Apoio Ferramental à Geração 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 Computação – 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 semi-
automatic derivation of Test-cases and Test-procedures for system testing from its
functional specification with Use Cases.
1. Introdução
O Teste de Software tem por objetivo identificar defeitos presentes em determinado
produto através da sua análise dinâmica, ou seja, através da sua execução. Essa
execução tem como meta revelar falhas no produto, permitindo, assim, que as devidas
correções tornem o produto mais confiável e garantindo sua qualidade [Dias Neto e
Travassos 2006]. Técnicas de Teste de Software podem ser aplicadas em diferentes
níveis de abstração. Mais especificamente, o Teste de Sistema ou Teste Funcional tem
por objetivo executar o software do ponto de vista dos seus usuários finais,
intencionando revelar falhas em relação aos requisitos previamente estabelecidos.
Nesse caso, a estrutura ou o comportamento interno do sistema não representam o foco
principal de avaliação, mas sim os resultados obtidos através da execução das suas
funcionalidades.
Levando-se em consideração que as atividades relacionadas aos testes do
software estão entre as mais custosas do processo de desenvolvimento [Juristo et al.
2004], uma das condições necessárias 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
condições 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 execução efetiva dos testes [Myers 2004].
No contexto de Teste Baseado em Modelos (MBT – Model Based Testing)
[Apfelbaum 1997], modelos são usados para descrever os vários elementos relacionados
ao Teste de Software, dentre eles os casos e procedimentos de teste. Em relação ao
Teste de Sistema, esses modelos são obtidos a partir das especificações funcionais do
sistema. A partir da aplicação dos conceitos de Desenvolvimento Dirigido por Modelos
(MDD - Model Driven Development) [France et. al. 2007] para a geração 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 derivação semi-automática dos modelos de teste a partir de
modelos funcionais e, a partir destes, a derivação dos casos e procedimentos de teste.
55
Algumas abordagens na literatura exploram a geração dos procedimentos de
teste a partir de casos de uso e modelos de teste [Hartmann 2005; Góis et. al. 2010].
Nestes casos, porém, o Analista de Teste possui a inteira responsabilidade de criar os
modelos de testes, pois estas abordagens não definem como construir estes modelos a
partir da especificação dos requisitos. Esta tarefa normalmente é apoiada por alguma
ferramenta para a definição 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-automática o modelo de testes funcionais.
Esse artigo está organizado em 7 seções, incluindo esta introdução. Na seção 2
são descritos o projeto e a arquitetura de ModelT2. Nas seções 3, 4 e 5 são apresentados
os detalhes de cada fase do processo de derivação. A seção 6 apresenta a avaliação da
ferramenta e, por fim, a seção 7 descreve as conclusões e trabalhos futuros.
2. Projeto e Arquitetura de ModelT2
A proposta de concepção de ModelT2 surgiu a partir de pesquisas sobre um metamodelo
UML para descrição de Casos de Uso, denominado UCModel, conduzidas pelo grupo
de Engenharia de Software Experimental da COPPE/UFRJ. Esse metamodelo explora,
principalmente, extensões do Diagrama de Atividades da UML 2
(www.omg.org/spec/UML/2.3/) para descrever os aspectos dinâmicos dos Casos de Uso.
O Modelo de Testes, por sua vez, foi descrito segundo o metamodelo de TDE
(Test Development Environment) [Hartmann 2005] que também 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 conveniência, devido ao
conhecimento prévio dos pesquisadores sobre esse modelo e a facilidade de acesso
devido à colaboração existente entre o grupo ESE e a Siemens Corporation
Research/USA, proprietária da ferramenta TDE/UML, capaz de manipulá-lo.
A partir dos metamodelos comentados anteriormente, a arquitetura de ModelT2 e
o seu contexto de atuação 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 são gerados, então,
os Casos e Procedimentos de Teste (CPT). Com o objetivo de aumentar a
independência de ModelT2 de uma ferramenta UML específica, foi adotado o padrão
XMI 2.1 (www.omg.org/spec/XMI/2.1.1/) como formato para descrição do MCU e do MT.
Figura 1. Arquitetura e contexto de atuação de ModelT2
56
ModelT2 possui quatro elementos principais: 1) módulo de transformação
MCUMT: aplica as regras definidas para derivação do Modelo de Testes a partir do
Modelo de Casos de Uso; 2) módulo de transformação MTCPT: aplica as regras para
derivação dos Casos e Procedimentos de teste a partir do Modelo de Testes; 3) regras
para transformação MCUMT, e; 4) regras para transformação MTCPT.
É importante notar que a criação do MCU não faz parte da arquitetura de
ModelT2, mas sim do contexto onde ela atua. A infra-estrutura para criação 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 geração do MCU. A ferramenta BOUML foi escolhida por se tratar de
uma ferramenta de uso livre, código aberto, compatível com a especificação UML 2 da
OMG e que permite tanto a definição de profiles UML bem como o desenvolvimento de
plug-ins em C++ ou Java para extensão das suas funcionalidades. O detalhamento dessa
infra-estrutura está fora do escopo deste artigo.
A utilização de ModelT2 se dá em três fases bem distintas que serão detalhadas
nas seções a seguir.
3. Derivação do Modelo de Testes
Nessa fase o Analista de Testes utiliza o Módulo de Transformação MCUMT. Esse
módulo permite que o usuário 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
padrão do MT a ser gerado (padrão XMI 2.1 ou padrão TDE, conforme Figura 1).
As regras para derivação MCUMT foram formalizadas usando o padrão QVT
(Query-View-Transformation) (www.omg.org/spec/QVT/1.1/Beta2/). Entretanto, a
transformação propriamente dita foi implementada com a linguagem XSLT
(www.w3.org/TR/xslt). XSLT foi escolhida pelo conhecimento prévio dos pesquisadores e
por atender aos requisitos estabelecidos e relacionados à transformação dos modelos.
A utilização 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 derivação do CPT pela própria ModelT2 (passo 3b da Figura 1), facilitando assim a
utilização de outras ferramentas por aqueles que não tenham acesso a TDE/UML.
Figura 2. Exemplo de uma descrição 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 seqüências de passos do caso de uso (principal,
alternativos e de exceção) e o fluxo de dados para descrever os tipos abstratos que são
produtos ou insumos dos diversos passos. Cada passo do caso de uso pode ser definido
como uma ação do ator, uma ação do sistema ou uma resposta do sistema. É importante
destacar que o modelo da Figura 2 não foi criado visando unicamente a geração de
testes funcionais, pois ele não representa um modelo de testes. Esse modelo representa
a dinâmica 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,
também podem ser derivados. Uma vantagem dessa abordagem é que os casos de uso
podem ser descritos usando qualquer ferramenta aderente à especificação 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 ações do sistema presentes no modelo da Figura 2 (destacadas em cinza)
não são representadas no MT, pois o metamodelo do TDE retrata apenas as ações do
ator e as respostas do sistema, não importando as ações internas do mesmo.
Figura 3. Exemplo de um Modelo de Testes derivado por ModelT2

4. Complementação do Modelo de Testes
Nessa fase o Analista de Testes complementa o MT acrescentando informações
necessárias para a derivação do CPT a partir deste. Em um cenário ideal, o MCU
deveria ser suficientemente completo para apoiar a geração do MT de forma automática,
ou seja, sem a necessidade de nenhum tipo de intervenção do Analista de Testes para
obtenção do MT. No entanto, existem limitações para essa derivação automática, uma
vez que há diferenças significativas relacionadas ao próprio objetivo de cada um desses
modelos e ao tipo da informação que deve ser capturada em cada caso. Um exemplo
dessa diferença está na existência, no MT, de categorias e seus respectivos valores a
partir dos quais são definidos os casos de teste. Esse tipo de informação existe no
MCU, mas não está necessariamente explícita e formalizada a ponto de permitir uma
transformação automática. Nesse caso o MT deve ser complementado com as
respectivas categorias e seus valores, antes da geração do CPT.
58
Para auxiliar na complementação do MT, o processo de derivação extrai
algumas informações do MCU e, baseado em algumas heurísticas, cria candidatos a
categorias e dicas para geração de valores, da seguinte forma: 1) gera candidatos a
categorias baseando-se nos fluxos de dados gerados/consumidos pelas ações descritas
no MCU; 2) gera comentários associados aos pontos de decisão baseando-se nas
condições que definem os possíveis desvios no fluxo de controle; 3) gera comentários
associados às ações baseando-se nas regras de validação que devem ser respeitadas
nesse ponto, e; 4) gera comentários associados às ações baseando-se nas regras a serem
observadas nesse ponto.
Um exemplo da aplicação dessas heurísticas pode ser observado nas categorias e
comentários 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 ação “Internauta informa login e senha” para gerar valores
válidos (“adm@1”, “adm1$”) e valores inválidos (“1abc@1”, “adm@”, “@123”) para
login e senha.
5. Derivação dos Casos e Procedimentos de Teste
Nesta fase, o Analista de Testes gera o CPT a partir do MT devidamente
complementado. Na versão atual essa transformação é realizada pela ferramenta
TDE/UML, que já implementa diversas estratégias para percorrer os fluxos de controle
presentes no diagrama da Figura 2 e permite a geração dos casos e procedimentos de
teste em vários 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.
2
Tabela 1. Exemplo de caso/procedimento de testes gerados por ModelT
Roteiro Login Senha
Descrição Passo válido inválido válida inválida
1 Sistema solicita login e senha Proc 1
2 Internauta informa login e senha 2 1abc@1 @123
3 Sistema informa login/senha incorretos 6 adm@1 adm1$
4 Apresenta menu Proc 2
5 Sistema solicita login e senha 2 adm@ adm1$
6 Internauta informa login e senha 6 adm@1 adm1$
7 Sistema apresenta menu de opções Proc 3
2 adm@1 @123
6 adm@1 adm1$
Apesar de sua adequação, o uso de TDE/UML pode representar uma restrição
para os testadores que não tem acesso a essa ferramenta em particular. Por isso, visando
garantir abrangência de uso, está sendo construído, na própria ModelT2, um módulo de
transformação MTCPT (vide 3b da Figura 1). As regras utilizadas nessa
transformação são bastante simples, pois os conceitos e os dados usados na geração do
CPT estão explicitamente representados no MT.
6. Avaliação de ModelT2
O uso de ModelT2 vem sendo avaliado no contexto do projeto de um sistema de
informação de larga escala. Nessa prova de conceito, os próprios pesquisadores têm
usado ModelT2 para gerar os casos de teste e os resultados indicam a viabilidade de uso
da mesma no projeto. Entretanto, esses resultados não podem ser generalizados, pois
apenas os próprios pesquisadores têm feito uso sistemático da ModelT2. Por isso, está
prevista, para o 2º semestre de 2010 no contexto de uma disciplina de pós graduação da
UFRJ, uma avaliação complementar com o objetivo de caracterizar, do ponto de vista
59
do desenvolvedor, a percepção de esforço e dificuldade na geração dos casos de teste
usando ModelT2 e entender a diferença na cobertura dos casos de teste gerados pela
ModelT2 em relação a outros casos de teste gerados sem apoio ferramental.
Neste artigo foram descritos o projeto e as características de uma ferramenta, chamada
ModelT2, para geração de casos e procedimentos de teste funcionais a partir de modelos
de Casos de Uso. ModelT2 apóia-se no uso intensivo de transformações semi-
automáticas modelo-modelo e modelo-texto, tendo como base dois metamodelos UML:
um para descrição de Casos de Uso (UCModel) e outro para descrição de Casos e
Procedimentos de Testes Funcionais baseados em casos de uso (TDE). Assim, ModelT2
visa fornecer, em última análise, um apoio efetivo para a elaboração de parte do Plano
de Testes, através da redução do esforço e custo envolvidos na geração desse artefato
essencial para garantia da qualidade do software.
Como melhorias futuras podemos destacar:
1. Derivação dos Casos e Procedimentos de Testes Funcionais pela própria
ModelT2, sem a necessidade de uso da ferramenta TDE/UML (em andamento);
2. Geração 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. Integração 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.
Referências Bibliográficas
Apfelbaum, L., Doyle, J. (1997), "Model Based Testing", Software Quality Week
Conference (QWE), Bruxelas, Bélgica.
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.
Góis, F., Farias, P., Oliveira, R. (2010), “Test Script Diagram – Um modelo para
geração de scripts de testes”, IX SBQS, pp. 73-87, Belém, 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, número 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,
Março.
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 , Andrés Romero2 , Rubby Casallas2 , Jean-Claude Royer3
1
Universidad Icesi – DRISO Group, Cali-Colombia
2
Universidad de Los Andes – Software Construction Group, Bogotá-Colombia
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
first-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 fine-
grained configurations of products, i.e. configurations at the level of each el-
ement 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 prod-
ucts [Pohl et al. 2005].
Model-Driven Engineering (MDE) claims to improve software construction using
models as first-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 defined as a set of products de-
veloped 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 in-
cluding mechanisms to extend the scope of more traditional MD-SPLs ap-
proaches [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 definition, configuration and derivation of model driven and software
product lines. The Fiesta toolkit implements facilities to (1) capture fine-grained varia-
tions between members of product lines, (2) configure new and more detailed products,
and (3) derive fine-grained configured 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 configuring product
line members. On the other hand, there is the process of deriving products reusing and
composing model transformations based on product configurations. 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 ap-
plication 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 fine-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 trans-
formations which consist of sets of transformation rules. Each transformation rule is re-
sponsible for producing a part of a final product. Model transformation rules implement
algorithms to transform domain application models into refined 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 configure a product during the application engineering process, product design-
ers 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 execu-
tions. 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 mod-
els [Kang et al. 1990, Czarnecki et al. 2004], constraint models, binding models, OCL-
type expressions to validate binding models against constraint models, and decision mod-
els. We also provide openArchitectureWare (oAW) components to facilitate the process-
ing 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 ar-
chitects to create a particular type of Eclipse projects. This type of projects includes
the required oAW and EMF dependencies to create MD-SPLs and predefine a hierarchi-
cal 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 files. 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
www.openarchitectureware.org
2
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 se-
lects to save a constraint model, the plug-in performs two activities. First, it saves a file
with extension .constraintmetamodel containing the constraint model. Second, it saves a
file 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 configurations are required. When a product designer se-
lects to save a binding model, the plug-in performs two activities. First, it saves a file with
extension .configurationmetamodel 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
www.pure-systems.com
5
gsd.uwaterloo.ca/projects/fmp-plugin/
64
create our transformation rules. These languages create files 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 Topcased’s 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 uncou-
pled (1) the information of features, (2) the transformation rules, and (3) the possible
execution’s conditions of transformation rules that particular feature configurations im-
ply. 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 configured products. This is a high-level mechanism which is
independent of the technology used to implement our approach. Finally, our plug-in can
capture execution’s conditions of transformation rules in order to derive products based
on binding models, which represent fine-grained configurations.
Generation and Execution of Model Transformation Workflows. To exe-

cute our decision models we transform them into executable oAW workflows 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 workflows on the model transformation engine of oAW. Thus, we
derive any (fine-grained) configured product.
65
4. Conclusions and Future Work
We presented the base mechanisms and tools we use in the processes of (1) expressing
variability and configuring products, and (2) deriving configured products. These mech-
anisms included the use of metamodels and feature models for expressing variability and
configuring products, and decision models to derive product line members. We presented
the MDD mechanisms we propose to improve the creation of MD-SPLs. These mech-
anisms include the use of constraint models which include the cardinality and structural
properties, binding models and more expressive decision models. We discussed our gen-
eral strategy for validating binding models against constraint models and for generating
executable model transformation workflows from decision models, which allow us to de-
rive product line members. Our future work includes facilities to check on configuration
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 fine-grained configu-
rations in model-driven spls. In Proc. of the 13th SPLC’09, 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
IDEAS’09, pages 59–72, Medellin, Colombia.
Czarnecki, K., Helsen, S., and Eisenecker, U. (2004). Staged Configuration Using Feature
Models. In Proc. of the 3th SPLC, pages 266–282. LNCS 3154.
DRISO Group (last visited in June 2010). Model-Driven Software Product Line Engi-
neering: Tool Support and Case Studies. In http://www.icesi.edu.co/driso/fiesta.
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., Böckle, G., and van der Linden, F. (2005). Software Product Line Engineering:
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 233–242.
66
TaRGeT: a Model Based Product Line Testing Tool
Felype Ferreira1 , Laı́s 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 tech-

nique that has grown in importance over the years. However, testing can in-
crement development costs in about 50% of the project’s 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
specifications. TaRGeT has been used in different contexts and can be extended
by other clients to be customized according to their specific needs.
1. Context and Motivation

Software testing has been one of the most used techniques for achieving software qual-
ity 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 ap-
proximately 50% of the total software development cost [Ramler and Wolfmaier 2006].
So it is important to figure 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
SUT’s formal model, which requires engineers to have formal modeling expertise.
TaRGeT was designed to minimize this bottleneck by automating a systematic ap-
proach 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 defines 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
flows.
The tool also provides a GUI for guiding the user to generate test cases. TaRGeT’s
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.
TaRGeT’s main benefit is a significant increase on productivity, for example, in-
stead 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 tool’s important features are
listened in the following subsections.
2.1. Controlled Natural Language Verification

The use case specifications used as input in TaRGeT’s test generation process are written
in natural language (NL), in order to facilitate the tool’s 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. TaRGeT’s Controlled
Natural Language (CNL) was created as an optional feature to improve the process of
text verification 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 defines some
writing rules and a restricted vocabulary in order to avoid authors to introduce ambiguities
into their texts and also to define a standard to be followed throughout an organization.
TaRGeT’s 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 En-
glish. However, this can be extended to other languages because the CNL’s parser receives
as input XML files containing the lexicon and the grammar rules. So it is only necessary
to provide new versions of these files according to a specific language. TaRGeT’s CNL
recognizes and processes the sentences from the user action, system conditions and sys-
tem response fields in the use case document template.
Figure 1. CNL Advisor
There are two categories of errors in TaRGeT’s 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.
TaRGeT’s 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 specifications. However, due to time or budget
restrictions, it is often not possible to execute all generated tests. TaRGeT provides some
filters 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 filters combination. If no option is chosen, the tool generates test
cases for all possible scenarios. The following items describe the test selection filters:
• Requirements and Use Cases Filter: through this filter, the user is able to gener-
ate test cases that cover specific requirements and/or use cases.
• Similarity Filter: with this filter, 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 filter allows the user to select test cases using test pur-
poses. A test purpose is an abstract description of a subset of the specification, al-
lowing choosing behaviors to test and, consequently, allowing reducing the spec-
ification 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 defined as [*;4M], it means that the tool shall select all test cases
finished 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 test’s description and objective, and the selection of tests that have been
performed before are lost. In addition, these modifications performed in the use cases can
generate new tests with id’s 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 modifications made
in the use cases is compared with an old one in order to find a relationship between new
69
and old test cases. This functionality is implemented by comparing the steps of the test
cases using the Levenshtein’s 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 configure the percentage of
automatic association. Tests that have been added to the suite are marked as new because
they don’t 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 correspond-
ing new and old tests, keeping any information that the user has added in the suite and
preserving the tests selection. Besides, TaRGeT assigns id’s 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 cus-
tomers particular needs with a significant reduction of the effort and cost required to
implement product variations. Figure 3 shows how the dependences between the imple-
mented 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 im-
plantation 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, mathe-
matically 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 En-
gineering (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 Sid-
ney 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, Verification 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 - balanc-
ing 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, selec-
tion, prioritization and processing product line.
http://twiki.cin.ufpe.br/twiki/bin/view/TestProductLines/TaRGeTProductLine.
72
CIDE+: Uma Ferramenta para Extração Semi-automática de
Linhas de Produtos de Software Usando Coloração de Código
Virgı́lio Borges de Oliveira1 , Rógel Garcia2 , Marco Túlio Valente2
1
Instituto de Informática, PUC Minas
2
Departamento de Ciência da Computação, UFMG
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 exist-
ing 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 Introdução
A extração de linhas de produtos de software a partir de sistemas existentes é uma tarefa
complexa e custosa [4]. Em primeiro lugar, desenvolvedores precisam identificar os com-
ponentes responsáveis pela implementação de cada feature da linha de produtos. Em
seguida, eles devem identificar aqueles trechos de código que referenciam os compo-
nentes descobertos no passo anterior. Por último, deve-se anotar esses trechos de alguma
forma ou movê-los para novas unidades de modularização. Assim, a fim de acelerar a
extração de linhas de produtos, descreve-se neste artigo uma ferramenta desenvolvida
com o objetivo de automatizar – de forma parcial – a anotação de features opcionais de
sistemas existentes.
A ferramenta proposta é baseada em uma extensão da plataforma Eclipse, chamada
CIDE (Colored IDE) [3]. CIDE estende o ambiente Eclipse com a possibilidade de se
associar cores de fundo a trechos de código que implementam features. Portanto, em
vez de anotações textuais, tais como #ifdef e #endif, desenvolvedores podem usar
anotações visuais para delimitar as linhas de código que pertencem a uma determinada
feature. Além disso, o ambiente CIDE permite a geração de projeções de um sistema nas
quais todo código anotado com uma determinada cor é removido. Essa forma de projeção
permite a geração 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 anotação semi-automática de código relativo a features. Ou seja,
usando apenas o CIDE, desenvolvedores devem manualmente localizar e mudar a cor de
fundo de todos os trechos de código responsáveis pela implementação de uma feature
que desejam incluir na linha de produtos. Normalmente, essa tarefa é custosa, tediosa e
sujeita a erros. Por outro lado, usando CIDE+, tais tarefas são automatizadas. Para isso,
inicialmente a ferramenta requer que engenheiros de linhas de produtos forneçam como
entrada um conjunto de elementos sintáticos – incluindo, por exemplo, pacotes, classes,
métodos e campos – responsáveis pela implementação de uma feature. Esses elementos
73
são chamados de sementes da feature. Em seguida, a ferramenta CIDE+ trata de colorir
todos os elementos do programa que referenciam direta ou indiretamente os elementos
definidos como sementes.
O restante deste resumo estendido está organizado conforme descrito a seguir.
A Seção 2 descreve o processo de extração de features automatizado pela ferramenta
CIDE+. Na Seção 3, apresenta-se um pequeno exemplo de uso da ferramenta. A Seção 4
sumariza os resultados obtidos na aplicação da ferramenta em três sistemas não-triviais.
Por fim, a Seção 5 discute ferramentas relacionadas e a Seção 6 conclui o artigo.
2 Extração de Features com CIDE+

CIDE+ agrega ao ambiente CIDE a capacidade de anotação automática de trechos de
código usando cores de fundo. A Figura 1 apresenta o processo iterativo e semi-automático
para anotação visual de features pressuposto pela ferramenta. Os passos desse processo
são discutidos nos parágrafos seguintes.
Figura 1. Processo iterativo e semi-automático para extração de features
Definição das Sementes: Inicialmente, desenvolvedores devem informar as sementes da

feature a ser extraı́da. Sementes podem incluir os seguintes elementos sintáticos: cam-
pos, métodos, classes ou interfaces e pacotes. Portanto, a ferramenta pressupõe que os
engenheiros tenham um conhecimento básico da arquitetura e do projeto do sistema alvo
da extração. Mais especificamente, eles devem ser capazes de informar os elementos do
programa que são integralmente responsáveis pela implementação da feature que desejam
extrair do sistema.
Algoritmo de Anotação: Tendo como entrada as sementes definidas, esse algoritmo trata
de colorir todas as partes do código que referenciam de forma direta ou indireta os ele-
mentos classificados como sementes. Basicamente, o algoritmo proposto é um algoritmo
de ponto-fixo, com duas fases. Na primeira fase, chamada de propagação de cores, os
elementos do programa que referenciam as sementes são visualmente anotados com uma
cor informada pelo engenheiro da linha de produtos. Por exemplo, suponha que o método
74
m1 tenha sido classificado como uma semente. Portanto, nessa primeira fase, qualquer
chamada de m1 será visualmente anotada com a cor fornecida. Na segunda fase, chamada
de expansão de cores, o algoritmo verifica se o contexto léxico dos elementos anotados na
primeira fase também pode ser colorido. Suponha, por exemplo, que a implementação de
um método m2 apenas inclui uma chamada a m1 , a qual foi anotada na primeira fase do
algoritmo. Nesse caso, a implementação de m2 também será colorida (assim como todas
as suas chamadas). Como o foco do presente artigo é apresentar a ferramenta CIDE+, não
são fornecidos mais detalhes sobre o algoritmo de anotação. O leitor interessado em tais
detalhes deve se dirigir a um outro trabalho de nosso grupo [2].
Expansões Semi-automáticas: Em situações especiais, o algoritmo proposto pode gerar

código com erros sintáticos ou de tipo. Suponha, por exemplo, a expressão opcao
== algumaConstante, onde opcao foi anotada mas algumaConstante não foi.
Dessa forma, a projeção incluindo apenas == algumaConstante não irá compilar
por apresentar erros de sintaxe. Em outro exemplo, suponha que todos os comandos
return de um determinado método foram anotados, mas os demais comandos não.
Após a remoção do código anotado, um erro de tipo será reportado (comando return
ausente). Em tais situações, a aplicação de qualquer tipo de “expansão corretiva” é uma
tarefa desafiadora e complexa.
Quando uma anotação leva a erros de sintaxe ou de tipo e nenhuma expansão
pode ser seguramente aplicada, o algoritmo proposto gera uma mensagem explicando o
erro. Posteriormente, é sugerida uma expansão padrão para tratar o erro detectado, como
descrito na Tabela 1. Por exemplo, a ferramenta pode sugerir a anotação de toda uma ex-
pressão (caso ela tenha sido parcialmente anotada) ou de todo um método (caso todos os
seus comandos return tenham sido anotados). Se o desenvolvedor aceitar as sugestões,
a ferramenta automaticamente aplica tais expansões ao código, a fim de eliminar os erros.
Definição Expansão Padrão

SE1 Apenas partes de uma expressão foram ano- Anotar toda a expressão
tadas
SE2 Os comandos return de um método foram Anotar todo o corpo do
anotados, mas o método tem outros coman- método
dos que não foram anotados
SE3 Um parâmetro de chamada foi anotado, mas Anotar toda a chamada
o parâmetro formal associado a ele não foi
anotado
SE4 O lado direito de uma expressão foi anotado Anotar o lado esquerdo e
mas o lado esquerdo não anotado suas referências
Tabela 1. Expansões Semi-automáticas
Avaliação dos Resultados: Finalizada a execução do algoritmo de anotação, resta ao

engenheiro responsável pela extração duas tarefas. Primeiro, ele deve detectar e corrigir
eventuais erros de sintaxe que tiverem sido inseridos no código. Em geral, esses erros são
inseridos quando o engenheiro optou por não aceitar uma das expansões padrão sugeridas
pela ferramenta durante a execução do algoritmo de anotação. Em seguida, o engenheiro
75
deve avaliar a cobertura das anotações visuais inseridas no código, isto é, se todas as lin-
has de código dedicadas à implementação da feature foram de fato coloridas. Para isso,
recomenda-se que ele gere uma projeção do sistema sem a feature em questão e que exe-
cute o produto gerado, de forma a se certificar de que a feature realmente não se encontra
mais presente no sistema. Nessa execução, ele pode perceber que ainda existe parte da
funcionalidade provida pela feature no produto gerado. Nesse caso, ele deve refinar as
sementes inicialmente escolhidas e iniciar um novo ciclo do processo de extração.
Em resumo, o processo proposto possui as seguintes caracterı́sticas: (a) semi-
automático, pois requer a definição das sementes das features extraı́das e a aprovação de
determinadas expansões de cores; (b) iterativo, pois pode requerer mais de um ciclo de
execução, até obter uma cobertura de todo o código responsável pela feature. O grau
de cobertura obtido – e o número de iterações requeridas – depende basicamente de se-
mentes que incluam todas os elementos do programa que respondem pela implementação
da feature sob extração.
3 Exemplo de Uso
Suponha uma classe hipotética Stack com um método push. Suponha que essa classe
faça parte de um sistema maior com as features descritas na Tabela 2. Além do nome
das features e de uma breve descrição do papel das mesmas na classe Stack, essa tabela
mostra também as sementes escolhidas como entrada para a ferramenta CIDE+.
Feature Descrição Sementes

Logging Log de eventos internos da pilha Classe Log
Snapshot Salva elementos em meio persistente Método snapshot
Multithreading Versão thread-safe da pilha Classe Lock
Tabela 2. Features da classe Stack e suas respectivas sementes
A Figura 2 apresenta o código da pilha colorido pela ferramenta CIDE+. Nesse

exemplo, chama a atenção a chamada de log realizada no interior do primeiro if do
método push. Como essa chamada está aninhada em um bloco de código relativo à
feature Multithreading, ela recebeu duas cores: a cor de Logging (verde) e a cor de Mul-
tithreading (vermelho). Quando isso ocorre, a ferramenta usa a cor resultante da mistura
fı́sica das duas cores entrelaçadas (isto é, vermelho+verde = amarelo). Na parte inferior
da Figura 2 mostra-se uma representação da AST do programa gerada pela ferramenta
CIDE+. Veja que os nodos responsáveis pelos blocos de código coloridos no editor são
também mostrados coloridos.
4 Estudos de Caso
CIDE+ foi usada com sucesso para extrair features de três sistemas: Prevayler (um banco
de dados em memória principal), JFreeChart (uma biblioteca gráfica) e ArgoUML (um
editor de diagramas UML). A Tabela 3 sumariza a experiência de uso de CIDE+ nesses
três sistemas. Para cada sistema, a tabela informa o tamanho de seu código fonte (em
megabytes), uma breve descrição das features extraı́das, o percentual do código fonte
anotado para extração de cada uma das features, o número de expansões semi-automáticas
(SE) requeridas durante a extração e o número de iterações que foram requeridas até se
obter uma cobertura completa do código de cada feature extraı́da.
76
Figura 2. Método push com features anotadas pela ferramenta proposta
Sistema Tam. (MB) Feature % Tam. # SE # Iter.

Monitor 4.0 3 1
Prevayler 0.16 Replication 6.7 0 1
Censoring 2.7 1 1
Pie Charts 5.0 21 1
JFreeChart 7.5
3D charts 2.3 7 1
StateDiagrams 3.7 100 2
ActivityDiagrams 1.7 40 1
ArgoUML 8.95
Design Critics 14.9 136 2
Logging 1.8 19 2
Tabela 3. Resultados sumarizados dos estudos de caso
5 Ferramentas Relacionadas
Pelo menos que seja de nosso conhecimento, não existem outras ferramentas para extração
automática de features em linhas de produtos usando anotações (sejam elas textuais, como
diretivas de pré-processamento, ou visuais, como cores de fundo).
Sendo assim, as ferramentas mais próximas são aquelas projetadas para apoiar
a extração fı́sica de features para unidades de modularização, normalmente para aspec-
tos. Como exemplo, podemos citar as ferramentas AOP-Migrator [1] e FOR [4]. No
entanto, essas ferramentas requerem uma participação e envolvimento muito maior dos
engenheiros responsáveis pelo processo de extração. O principal motivo é que linguagens
como AspectJ se baseiam em um modelo de granularidade grossa para extensão de progra-
77
mas [3]. Em outras palavras, essas linguagens pressupõem que o código responsável pelas
features esteja presente em determinadas localizações estáticas do código fonte. Como
nem sempre isso ocorre, essas ferramentas requerem um passo preliminar de preparação
do código fonte visando a sua extração para unidades próprias de modularização. Em
geral, esse processo de preparação requer um conhecimento detalhado do código, que
impede a sua automatização [6, 5].
6 Comentários Finais
Neste artigo, foi apresentada a ferramenta CIDE+, a qual estende o ambiente CIDE com
a coloração automática de código responsável pela implementação de features em linhas
de produtos de software. Mais informações sobre a ferramenta podem ser obtidas em:
http://www.dcc.ufmg.br/∼mtov/cideplus.
Agradecimentos: Este trabalho foi apoiado pela FAPEMIG, CAPES e CNPq.
Referências
[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 Engi-
neering, 32(9):698–717, 2006.
[2] Virgilio Borges and Marco Tulio Valente. Coloração automática de variabilidades em linhas de
produtos de software. In III Simpósio Brasileiro de Componentes, Arquiteturas e Reutilização
de Software (SBCARS), pages 67–80, 2009.
[3] Christian Kästner, Sven Apel, and Martin Kuhlemann. Granularity in software product lines. In
30th International Conference on Software Engineering (ICSE), pages 311–320, 2008.
[4] Jia Liu, Don Batory, and Christian Lengauer. Feature oriented refactoring of legacy applications.
In 28th International Conference on Software Engineering (ICSE), pages 112–121, 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):1–19, 2009.
[6] Marcelo Nassau and Marco Tulio Valente. Object-oriented transformations for extracting aspects.
Information and Software Technology, 51(1):138–149, 2009.
78
Uma Ferramenta de Apoio à Gerência 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
Laboratório de Engenharia de Software – Universidade Federal do Pará (UFPA)

Caixa Postal 479 – 660.75 -110 – Belém – 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 Introdução
Uma das premissas para que uma organização seja competitiva no mercado atual é ter
know-how para identificar, gerenciar, proteger e explorar os seus recursos de forma
eficiente. Em muitas dessas organizações, o conhecimento é o mais importante, valioso,
e crítico dos recursos [Basili et al. 2001]. Assim, a perda do conhecimento, seja com a
saída de membros, esquecimento de soluções ou avanços tecnológicos, gera problemas
significativos para as organizações
Na tentativa de minimizar os problemas gerados pela falta de gestão do
conhecimento, as organizações passaram a investir em tecnologias, métodos e
estratégias que facilitem a transferência de conhecimento.
Especificamente no desenvolvimento de software, o conhecimento é gerado e
utilizado em grande escala, tornando necessário o uso de ferramentas para minimizar o
esforço em compartilhar esse conhecimento. Dessa forma, inúmeros sistemas [Montoni
2003] [Natali 2003] [Holz 2003] foram desenvolvidos para apoiar as atividades de
Gerência de Conhecimento (GC), sobretudo, integrados a Ambientes de
Desenvolvimento de Software (ADS). Entretanto, tais ferramentas não atendem todo o
espectro de funcionalidades de GC. Além 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, execução e o
acompanhamento de processos, além de facilitar a reutilização de boas práticas
gerenciais por diferentes projetos. As principais funcionalidades da WKM são:
definição e manutenção do Plano de GC, gerência dos itens de conhecimento e a
geração de relatórios relacionados à GC. Um ponto a ser destacado é o fato de que
durante a definição/manutenção do plano de GC, o gerente do projeto pode estabelecer
marcos no processo para a coleta de conhecimento de acordo com a execução do
79
processo. A ferramenta WKM descrita neste artigo é resultado da evolução dos
trabalhos [Oliveira et al. 2009] e [Oliveira e Reis 2009].
O restante do texto está estruturado da seguinte forma: a seção 2 apresenta a
arquitetura e as principais funcionalidades da WKM; a seção 3 apresenta uma breve
comparação com outras ferramentas com foco em gerência de conhecimento em
ambientes de desenvolvimento de software; e, por fim, a seção 4 apresenta as
considerações finais do trabalho.
2 WebAPSEE Knowledge Manager

A WKM foi desenvolvida como uma extensão do WebAPSEE, ambiente este que possui
como principal objetivo permitir a definição e execução de processos de software de
maneira flexível, além de manter um conjunto de informações organizacionais.
O ambiente WebAPSEE implementa uma arquitetura cliente/servidor, que
contém três clientes: (a) Manager Console, direcionado aos gerentes, que permite a
definição, planejamento e acompanhamento da execução de processos de software, além
do gerenciamento dos dados organizacionais, coleta de métricas, geração de relatórios,
etc.; (b) Task Agenda Desktop, que provê aos agentes alocados em um processo todas as
informações necessárias para execução da suas atividades (prazos, artefatos de entrada,
artefatos de saída, pessoas envolvidas, estimativa de horas, etc.), além de permitir o
feedback desses agentes sobre o andamento de suas tarefas a partir da interação (ações
de iniciar, pausar, delegar, finalizar) com a máquina de execução 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, além de,
definir novos componentes no servidor, associados aos componentes existentes, como a
máquina de execução de processos e a gerência organizacional. A seguir será
apresentada uma visão 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 comunicação entre servidor e clientes. Deste
modo, foi definida uma interface abstrata (interface WKM) contendo os serviços
encapsulados no componente WKM, o qual é um sub-componente do WebAPSEE
Server. Tais serviços, por sua vez, são acessados a partir dos clientes do WebAPSEE:
Manager Console e Task Agenda Web. A Figura 1 ilustra um diagrama de componentes
que representa a integração da WKM à arquitetura do ambiente WebAPSEE.
Figura 1 - Visão Geral da integração de componentes
80
O WebAPSEE Server, implementado utilizando Java, disponibiliza as interfaces
de acesso aos serviços através da tecnologia de invocação de procedimento remoto RMI,
permitindo assim que o Manager Console, desenvolvimento em Java e interface gráfica
Swing, e a Task Agenda Web, desenvolvido em Adobe Flex e Java para fornecer a
interface gráfica Web, se comuniquem com o servidor do WebAPSEE.
2.2 Principais funcionalidades

As principais funcionalidades do WKM são: (a) definição/manutenção do Plano de GC
(definição de planos para coleta e disseminação de conhecimento, definição das
estruturas de conhecimento a serem coletadas, etc.), (b) gerência dos itens de
conhecimento (aquisição, busca, avaliação, homologação, disseminação, manutenção do
conhecimento, etc.) e a (c) geração de relatórios de acompanhamento relacionados à
GC.
Através do Manager Console, o gerente pode definir e manter Planos de GC
estabelecendo quais estruturas de conhecimento (por exemplo, lições aprendidas, padrão
arquitetura, etc.) devem ser coletadas e disseminadas em um projeto. Além disso, é
possível definir marcos no processo para a realização 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 através da seleção de um evento
associado a uma atividade (início, término ou delegação da atividade), o que é possível
devido a integração com a máquina de execução do WebAPSEE. As Figuras 2.B e 2.C
apresentam a visão do usuário da agenda ao receber uma notificação (sugestão) para
cadastrar um novo item de conhecimento quando um marco foi alcançado.
Figura 2 - Coleta de Conhecimento nos Marcos definidos no plano de GC.

Além da coleta de conhecimento através dos marcos definidos pelo gerente, o
usuário da Task Agenda Web pode, através do menu “Conhecimento”, inserir novos
81
itens, buscar os itens cadastrados, além de listar todos os itens de conhecimento
cadastrados por si próprio, para acompanhar o andamento dos registros.
Ao ser inserido, o conhecimento recebe o estado de salvo (estado “rascunho)”,
permitindo que este seja enviado para homologação (estado “em homologação”). O
homologador, ao receber o conhecimento pode: disponibilizar o conhecimento (estado
“disponível”), mandar para avaliação (estado “em avaliação”), enviar para o autor
realizar uma revisão (estado “revisão”) ou desabilitar o conhecimento (estado
“desabilitado”), caso em que o item se torna inútil. A visão do homologador é
apresentada na Figura 3.
Figura 3 – Homologação dos Itens de Conhecimento

Com base nos itens de conhecimento cadastrados, o gerente pode, através do
Manager Console, gerar um relatório contendo todos os itens de conhecimento inseridos
pelos colaboradores da organização em um determinado intervalo de tempo, indicando
além do identificador do conhecimento, a data de criação e o estado atual do item de
conhecimento (rascunho, em homologação, em avaliação, disponível ou removido).
Figura 4 - Relatório de Itens de Conhecimento Registrados por Desenvolvedor
82
3 Ferramentas Relacionadas
Na literatura são encontradas algumas ferramentas que tem como objetivo auxiliar a
gerência de conhecimento no contexto de processos de desenvolvimento de software, tal
como a ferramenta WKM. Dentre tais ferramentas estão: (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) apóia compartilhamento e
reuso de conhecimento através de um conjunto extenso de atividades.
O ambiente CORE-KM (Customizable Organizational Resources Environment
with Knowledge Management), integrado ao ADS Estação TABA, é um ambiente
customizável para gerência de conhecimento em diferentes organizações, com o
objetivo de apoiar processos organizacionais.
A ferramenta PRIME (Process-oriented Information resource Management
Environment), integrada a um PSEE com execução distribuída de processos, chamado
MILOS, tem como objetivo adquirir conhecimento de processos de desenvolvimento em
um ADS através da estruturação de conhecimento no processo.
A Tabela 1 apresenta uma comparação entre as ferramentas que apóiam a
gerência de conhecimento, com base em um conjunto de funcionalidades úteis para a
realização de GC. Dentre as funcionalidades ressaltam-se, o suporte à gerência de
configuração de ativos e à geração de relatórios que são características exclusivamente
atendidas pela WKM. Os demais critérios como flexibilidade na categorização do
conhecimento, apoio aos aspectos colaborativos, especialistas e integração com uma
máquina de execução, são atendidos por apenas uma ferramenta, além da WKM.
Tabela 1 - Comparação com outras ferramentas.
Ferramentas
ODE COREKM PRIME WKM
Funcionalidades /TABA /MILOS
Flexibilidade na categorização do X X
conhecimento
Planejamento da gerência de conhecimento X
Aquisição de conhecimento X X X X
Avaliação de conhecimento X X X X
Busca de conhecimento X X X X
Disseminação de conhecimento X X X
Valoração de conhecimento X X X
Manutenção de conhecimento X X X X
Integração com uma máquina de execução X X
Apoio a colaboração X X
Rede de Especialistas X X
Gerência de Configuração de ativos X
Relatórios X
4 Considerações Finais
Este artigo apresentou a ferramenta WebAPSEE Knowledge Manager, que é voltada
para apoiar a implantação e execução de estratégias de Gerência de Conhecimento. A
integração da WKM ao ambiente WebAPSEE permite utilizar a máquina de execução
de processos do ambiente para definir marcos para coleta de conhecimento, além de
83
consultar os dados organizacionais do ambiente para possibilitar a definição de uma
rede de especialistas para avaliação dos conhecimentos cadastrados.
Algumas das principais contribuições da ferramenta, além de apoiar a GC de
forma integrada a uma máquina de execução, são: (a) possibilitar o planejamento de
gerência de conhecimento, incluindo a capacidade de realizar coleta e disseminação do
conhecimento; e (b) geração de relatórios sobre os conhecimentos cadastrados;
Atualmente, a ferramenta está sendo implantada no Centro de Tecnologia da
Informação e Comunicação da Universidade Federal do Pará (CTIC-UFPA), avaliado no
nível G do MPS.BR, para auxiliar na implantação do processo de Gerência de
Conhecimento.
Futuramente, pretende-se evoluir a ferramenta para uma nova versão com
melhor usabilidade, e utilizar os recursos da Web 2.0 (como Tagging, por exemplo) para
distribuição de conhecimento. Além disso, pretende-se finalizar a implementação das
funcionalidades pendentes, em relação à rede de especialistas e a Gerência de
Configuração de itens de conhecimento.
A ferramenta WKM, o manual de instalação e de uso podem ser encontrados no
link “http://labes.ufpa.br/liken/wkm” e a mesma encontra-se sob a licença BSD
(Berkeley Software Distribution).
Referências
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 à Interação entre Processos
de Negócio e de Software através de Gerência do Conhecimento”. Simpósio
Brasileiro de Qualidade de Software – SBQS 2004. Brasília, 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) “Laboratório de Engenharia de Software e
Inteligência Artificial: Construção do Ambiente WebAPSEE”. ProQualiti –
Qualidade na Produção de Software. v. 3, n. 1, junho de 2007. p. 43-48.
Montoni, M. A.; (2003) “Aquisição de Conhecimento: Uma Aplicação no Processo de
Desenvolvimento de Software”. Dissertação de Mestrado COPPE/UFRJ.
Natali, A. C., (2003) “Uma Infra-Estrutura para Gerência de Conhecimento em um
Ambiente de Desenvolvimento de Software”. Dissertação de Mestrado.UFES.
Oliveira, J. F. ; Andrade, G. F. ; Tavares, L. C. ; Reis, C. A. L. (2009). Planejamento e
Execução de Gerência do Conhecimento em um Ambiente de Desenvolvimento de
Software. In: VIII Simpósio Brasileiro de Qualidade de Software, Ouro Preto. Anais
do VIII Simpósio Brasileiro de Qualidade de Software.
Oliveira, J. F. ; Reis, C. A. L. (2009) . Apoio Automatizado à Elaboração de Planos de
Gerência de Conhecimento para Processos de Software. In: XII Conferência
Iberoamericana de Ingenieria de Requisitos y Ambientes de Software, 2009, Medelín.
Proceedings of the XII Conferência 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. Xexéo 2, Jano M. de Sousa1
1
Programa de Engenharia de Sistemas e Computação - COPPE/UFRJ
2
Departamento de Ciência da Computação - 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. Introdução
Com o objetivo de apoiar o Scrum (Schwaber 2004), foi desenvolvida uma ferramenta
web, o Scrum-Half, cujo nome teve origem em uma das posições de jogo do Rugby. A
motivação para esse trabalho foi facilitar a organização de uma equipe de
desenvolvimento de software e auxiliá-la nas tomadas de decisão, de modo que o uso do
Scrum se torne ainda mais eficiente. A ferramenta armazena informações sobre as
Sprints, registrando a velocidade da equipe e estatísticas sobre a quantidade de tarefas
concluídas em cada iteração e quais tarefas ficaram pendentes. Isso permite uma visão
rápida sobre o desempenho da equipe, auxiliando sua evolução.
Além disso, na construção da ferramenta, houve a preocupação em se fazer um
estudo detalhado sobre o Scrum, de modo que ela fosse desenvolvida com a maior
proximidade possível 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 Introdução ao Scrum

O Scrum é uma metodologia de desenvolvimento ágil que possui características
importantes como os períodos curtos de trabalho onde são desenvolvidos alguns itens de
uma lista priorizada pelo cliente. Cada período é chamado de Sprint e quando sua
duração chega ao final, uma nova funcionalidade é apresentada. Durante toda a Sprint a
equipe se reúne diariamente para discutir o que foi feito, os obstáculos encontrados e o
que será feito até a próxima reunião (Pressman 2006). As Sprints ocorrem uma após a
outra e consistem no Planejamento de Sprint, no trabalho de desenvolvimento, na
Revisão 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 início 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, construído na
reunião 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 término dela (Schwaber 2004).
No Scrum, a responsabilidade de avaliar e aceitar o produto construído pela
equipe cabe ao Product Owner. Ele também é o responsável por definir as
características do produto e gerenciar o Product Backlog, priorizando seus itens de
acordo com o valor de negócio (Srinivasan & Lundqvist 2009). Outro papel, o Scrum
Master, tem a função de facilitar o desenvolvimento de software, removendo obstáculos
e acompanhando o progresso da equipe Scrum. Uma equipe Scrum pode ser constituída
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 serviço web pago mensalmente, com preço calculado de
acordo com o plano escolhido, na maioria dos casos levando em consideração o número
de usuários que usará o serviço. 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 também oferece um quadro de tarefas para ser usado durante a
Sprint e permite a organização do Product Backlog e do Sprint Backlog. Além disso, o
Scrum-Half possui o diferencial de acompanhar o fluxo Scrum, seguindo as etapas
necessárias para o desenvolvimento de um projeto de software, auxiliando as reuniões
para elaboração e encerramento da Sprint e também no dia a dia do trabalho de
desenvolvimento. Atualmente, é possível 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
aplicação JBoss (Red Hat 2010). O lado servidor foi desenvolvido com uma arquitetura
com as seguintes camadas: apresentação, controle, serviços, domínio de negócio e
persistência.
A camada de apresentação, responsável pela comunicação com o cliente, foi
feita utilizando o framework JavaServer Faces (JSF) (Oracle Corporation 2010a). Além
disso, foram utilizados componentes Enterprise JavaBeans (EJB) e a Java Persistence
API (JPA) (Oracle Corporation 2010a), utilizada na camada de persistência. As classes
de domínio de negócio foram modeladas com base nos conceitos do Scrum, seus
artefatos e as relações entre eles.
5. Descrição da Ferramenta
5.1. Características Gerais
O Scrum-Half permite que um usuário participe de mais de um projeto, possuindo papel
diferente em cada um deles. É possível atribuir um ou mais papéis do Scrum a um
86
membro do projeto. Essa escolha implica em privilégios no sistema, de acordo com as
características de cada papel. Além disso, o sistema permite a atribuição do papel
Gerente, caso necessário, para um membro da equipe que estiver utilizando o sistema.
5.2. O Product Backlog do Scrum-Half

Ao acessar o Product Backlog o usuário visualiza a lista de requisitos do projeto,
chamados de itens de Backlog. Além dele, o usuário também pode visualizar a lista de
itens de Backlog pendentes, que é formada pelos itens de Backlog criados, mas ainda
não aprovados pelo Product Owner.
De acordo com o Guia do Scrum (Schwaber & Sutherland 2008), os itens do
Product Backlog possuem os atributos de descrição, prioridade e estimativa. A
prioridade é determinada por risco, valor e necessidade e é o atributo responsável pela
ordenação dos itens. Os itens do Product Backlog podem ser atualizados a qualquer
momento. Enquanto o Product Owner é o responsável pela prioridade dos itens, a
equipe fica responsável por todas as estimativas.
Os itens de Backlog do Scrum-Half possuem esses três atributos. No momento
da criação de um item, qualquer usuário, independente do papel que exerce na equipe,
pode informar os dados, a prioridade e a estimativa. Porém, um item criado precisa ser
aceito pelo Product Owner para poder fazer parte do Product Backlog.
Na atualização 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 numérico. 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 difícil de ser desenvolvido.
Figura 1. Criação de Item de Backlog
87
Figura 2. Product Backlog
5.3. Planejamento, Andamento e Encerramento da Sprint no Scrum-Half

Uma Sprint é uma iteração de duração fixa. Sua data final não muda mesmo que a
equipe precise reduzir a funcionalidade entregue para poder concluir na data
especificada (Rising & Janoff 2000).
A reunião de planejamento da Sprint é o momento no qual a iteração é
planejada. Nela são decididos os itens do Product Backlog que serão desenvolvidos na
próxima Sprint. A equipe define como transformará os itens selecionados em um
incremento pronto. O trabalho necessário 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
usuário primeiramente define o nome, o objetivo, a data de início e a data de término.
Concluída essa etapa o sistema apresenta o Product Backlog para seleção dos itens que
farão parte da iteração. Para auxiliar na escolha dos itens, o sistema informa a
velocidade mínima, média e máxima da equipe, que correspondem respectivamente à
quantidade mínima, média e máxima de pontos de estimativa que a equipe concluiu nas
Sprints anteriores. Um diferencial do Scrum-Half no planejamento da Sprint é a
recomendação de um conjunto de itens de Backlog que podem ser desenvolvidos na
próxima iteração, de acordo com a velocidade da equipe.
A criação 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. Além disso, permite a atualização do Sprint Backlog a qualquer
momento, acrescentando tarefas novas, atualizando dados ou removendo as que foram
mal planejadas.
O quadro possui três colunas, na seguinte ordem: “TAREFAS PENDENTES”,
“TAREFAS EM ANDAMENTO” e “TAREFAS CONCLUÍDAS”. As tarefas são
criadas na primeira coluna e são movidas por drag and drop para as outras colunas no
decorrer da Sprint. Em todas as colunas as tarefas são ordenadas de acordo com a
88
prioridade do item de Backlog correspondente. Com o quadro de tarefas é possível ter
uma visão rápida do número de tarefas concluídas e de quantas ainda estão por fazer.
Figura 3. Quadro de Tarefas

Outro artefato que permite acompanhar o progresso da Sprint, também presente
no Scrum-Half, é o gráfico de Burndown. Ele mostra o trabalho restante ao longo do
tempo e o progresso da equipe na redução desse trabalho. O trabalho restante é
monitorado no eixo vertical e os períodos de tempo da Sprint são 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 Reunião de Revisão da Sprint (Schwaber 2004). Na Reunião de Retrospectiva
da Sprint, por sua vez é feita a revisão do processo de desenvolvimento, de forma a
torná-lo mais eficaz e gratificante para a próxima iteração. (Schwaber & Sutherland
2008). O Scrum-Half oferece apoio às duas reuniões 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 também registre os pontos positivos e negativos da
Sprint, para que possam ser avaliados a qualquer momento, visando auxiliar a evolução
da equipe.
6. Conclusão
Esse artigo apresentou o Scrum-Half, uma ferramenta que possui as funcionalidades
básicas para o uso do Scrum, tais como o registro do Product Backlog e a manipulação
do quadro de tarefas durante a Sprint. Além disso, o Scrum-Half possui também o
diferencial de auxiliar nas reuniões de Scrum, fornecendo informações úteis para o
planejamento da Sprint e permitindo o registro do que é aprendido nas reuniões de
revisão e retrospectiva.
Armazenar o que ocorre na construção de um software é importante para a
equipe evoluir com a própria experiência. O registro do que foi desenvolvido em cada
89
Sprint auxilia o planejamento das Sprints futuras, obtendo uma estimativa para término
do projeto mais próxima da realidade.
O Scrum-Half tem como objetivo apoiar o uso do Scrum, mas não propõe
substituir as reuniões do Scrum ou qualquer forma de integração da equipe, pois o
contato pessoal é muito importante para o sucesso de um projeto. No entanto, em
projetos que possuem equipes distribuídas, 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. Referências
Atlantic Dominion Solutions, 2010. Scrum`d. Scrum`d. Disponível em:
http://www.scrumd.com/ [Acessado Maio 23, 2010].
Carvalho, R. & Lowenfels, D., 2009. ScrumNinja. ScrumNinja. Disponível 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. Disponível em: http://www.skinnyboard.com
[Acessado Outubro 12, 2009].
iMeta, 2009. iMeta Agility. iMeta Agility Scrum Software Management Software.
Disponível em: http://agility.imeta.co.uk/ [Acessado Outubro 12, 2009].
Oracle Corporation, 2010a. Java.sun.com. Disponível em: http://java.sun.com/
[Acessado Junho 20, 2010].
Oracle Corporation, 2010b. MySQL. Disponível 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 à
Revisão Sistemática
Augusto Zamboni, André Di Thommazo, Elis Hernandes, Sandra Fabbri
Departamento de Computação
Universidade Federal de São Carlos (UFSCar) – São 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. Introdução
O processo de Revisão Sistemática (RS) tem sua origem na área médica e tem como
objetivo, segundo [Pai et al., 2004] a criação de uma síntese completa e imparcial de um
tópico de pesquisa, seguindo-se um procedimento bem definido e aberto. Mais
recentemente, esse processo tem sido adaptado para a área de computação,
particularmente para a engenharia de software, com o mesmo objetivo de identificar,
avaliar e interpretar todas as pesquisas relevantes disponíveis relacionadas com algum
tópico de pesquisa [Kitchenham, 2004]. Como vantagens para o uso da RS em relação
às técnicas tradicionais de revisão da literatura, destacam-se a abrangência, a
repetibilidade e a confiabilidade do processo aplicado. Além de sistematizar a busca por
pesquisas relevantes, a RS prevê a organização e análise dos resultados encontrados.
Contudo, o processo da RS é bem mais trabalhoso que a pesquisa realizada de
forma ad hoc [Kitchenham, 2004]. São muitos os passos a serem executados e vários
documentos a serem gerenciados. Com o objetivo de facilitar esse procedimento, foi
desenvolvida a ferramenta StArt (State of the Art through Systematic Review), que apóia
as etapas de uma RS, dando suporte desde a elaboração do protocolo até a sumarização
dos resultados. Um protótipo da interface da ferramenta foi apresentado no ESELAW
2007 [Montebelo et al., 2007], e a partir dele a versão atual foi especificada e
desenvolvida.
Na Figura 1 são apresentadas as etapas de uma RS, de acordo com [Biolchini et
al.,2005]. A principal diferença 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 são apoiadas pela ferramenta StArt como
será descrito na Seção 2.
91
Figura 1 - Processo de Condução de Revisão Sistemática adaptada de [Biolchini
et al.,2005].
Assim, o objetivo deste artigo é apresentar a ferramenta StArt, sendo que na

Seção 2 serão apresentadas as principais funcionalidades, na Seção 3 são descritos os
aspectos de implementação, na Seção 4 relacionam-se outras ferramentas de apoio ao
levantamento bibliográfico e na Seção 5 apresentam-se as conclusões e os trabalhos em
andamento e futuros.
2. Aspectos Funcionais
A ferramenta StArt dá suporte ao processo da RS por meio de funcionalidades que
apóiam cada uma de suas fases. A Figura 2 mostra os principais passos que devem ser
realizados durante a condução da RS por meio da ferramenta, de acordo com as etapas
apresentadas na Figura 1. Os passos marcados com asterisco são realizados
externamente à ferramenta, nas próprias máquinas 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 hierárquica com as fases da RS e as opções que a

StArt disponibiliza para dar suporte a elas. Estão presentes na ferramenta: (i) a fase de
Planejamento, que é composta da criação do protocolo; (ii) a fase de Execução, que permite
a condução, seleção e extração das informações pelos passos que vão desde a aplicação das
strings de busca até a leitura e resumo dos artigos aceitos; e (iii) a fase de Sumarização, que
corresponde à analise dos dados e que na ferramenta é apoiada pela apresentação de alguns
gráficos que fornecem um panorama da situação dos artigos e permite que o pesquisador
elabore um relatório final sobre a revisão realizada. A seguir, cada uma das fases será
comentada fornecendo-se alguns detalhes sobre o apoio dado pela StArt.
2.1. Planejamento
Dá apoio à elaboração do Protocolo de acordo com os atributos sugeridos por Biolchini
(2005), como por exemplo, as palavras-chave que serão utilizadas na busca; as máquinas
de busca; os critérios para aceitação ou rejeição dos artigos encontrados, etc. Cada
atributo do protocolo possui um help para ajudar o usuário quanto ao seu
preenchimento. Esse protocolo fica armazenado na ferramenta, podendo ser consultado
92
e mesmo alterado, caso necessário na fase de planejamento.
Figura 3 - Etapas da Revisão Sistemática apoiadas pela StArt.
2.2. Execução
Essa fase da RS é composta de alguns passos, que são 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 máquinas de busca
definidas no protocolo. Essa busca deve ser realizada externamente à ferramenta, pois as
bases não permitem atividades de captura automática de informações. Assim, como as
bases comumente utilizadas como IEEE, Scopus, ACM e Springer, permitem a
exportação da busca no formato BibTex, essa foi a alternativa usada para contornar o
problema. Durante a importação dos dados, a ferramenta atribui a cada artigo uma
pontuação de acordo com o número de ocorrências que as palavras-chave definidas no
protocolo aparecem em seu título, resumo e lista de palavras-chave. Tal pontuação pode
ser usada para estabelecer uma ordem de leitura, visto que, provavelmente, os artigos
com maior pontuação serão mais relevantes à RS. Essas funções estão relacionadas ao
passo de “Condução”. Ressalta-se que o arquivo BibTex contém apenas o resumo e
outras informações dos artigos que foram encontrados na busca. Vale ressaltar que se o
usuário repetir a RS futuramente, ele poderá adicionar às sessões de busca previamente
criadas, novos arquivos Bibtex. Essa possibilidade permite que sejam atualizadas as
referências associadas a uma determinada string de busca.
93
(ii) o pesquisador também pode classificar o artigo segundo dois critérios: Status
(Accepted, Rejected, Duplicated e Unclassified), que depende dos critérios de aceitação
e Concept (Excelent, Good, Medium e Bad), que depende da percepção da relevância do
artigo para a RS. Para a classificação do Status, a ferramenta provê recurso para que o
pesquisador justifique o status atribuído e represente graficamente a situação dessa
classificação (Figura 3(a)). Essas funções estão relacionadas ao passo de “Seleção”.
A Figura 4 ilustra as alternativas mencionadas em (i) e (ii).
Figura 4 - Exemplo de alternativas para avaliação dos artigos.

(iii) Após a classificação 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 funções estão relacionadas ao passo
“Extração”.
2.3. Análise dos Resultados

Para essa fase, a ferramenta dá suporte gerando os gráficos relativos à classificação dos
artigos, no que diz respeito às fontes pesquisadas, e aos critérios utilizados para
aceitação ou rejeição (Figura 3(b)). Além disso, a StArt possibilita a edição do texto que
deve representar a compilação conclusiva sobre o tema pesquisado, considerando os
objetivos iniciais determinados no protocolo e os resultados obtidos com a leitura dos
artigos.
3. Aspectos de implementação
A versão atual da StArt foi implementada para ambiente desktop. A persistência de
dados é feita em arquivos e não em bases de dados, provendo à StArt um ambiente
portátil, no qual as RS realizadas por um pesquisador podem ser enviadas e abertas por
94
outros pesquisadores sem a necessidade de instalação de Gerenciadores de Banco de
Dados específicos. A ferramenta está implementada na linguagem Java, dada sua
popularidade e portabilidade entre diversas plataformas de Sistemas Operacionais,
desde que exista uma Máquina Virtual Java instalada. Além disso, existem várias
bibliotecas prontas que auxiliam, principalmente, na construção de componentes
visuais. No caso da StArt, foi utilizado o Swing [SWING], bem como as bibliotecas
JFreeChart [JFREECHART] e JWizard [JWIZARD] que auxiliam na construção de
gráficos e janelas de wizard, respectivamente. Atualmente a ferramenta é um software
proprietário e pretende-se no futuro colocá-la sob as regras de alguma licença de
software livre. Um vídeo demonstrativo da StArt está disponível no endereço
http://lapes.dc.ufscar.br/ferramentas/start.
4. Ferramentas Relacionadas
Existem algumas ferramentas que dão suporte ao gerenciamento de referências
bibliográficas, mas não ao processo de RS, como é o propósito 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 criação de atributos para avaliar os artigos, ela não trabalha, por
exemplo, com os conceitos de Protocolo e de Critérios para aceitação ou rejeição de
artigos como a StArt, que foi definida e implementada com esse propósito específico.
5. Conclusão
Este artigo apresentou a ferramenta StArt, que tem por objetivo apoiar o processo de
Revisão Sistemática em todas as suas etapas: Planejamento, Execução e Sumarização.
Considerando a importância de fazer o empacotamento da RS de forma a torná-la
repetível, o grande volume de informação que deve ser registrado e armazenado e
considerando também que o processo é caracterizado por atividades iterativas, o apoio
de uma ferramenta é fundamental para dar maior qualidade e facilitar a sua aplicação.
A ferramenta continua em constante aprimoramento de forma a atender cada vez
melhor a condução de uma RS. No momento estão sendo finalizadas algumas
funcionalidades que darão melhor suporte à fase de sumarização dos resultados da
revisão bem como a geração de relatórios que permitam extrair as informações
armazenadas na ferramenta. Assim que essas funcionalidades forem concluídas, uma
versão executável será disponibilizada para a comunidade. Como trabalho futuro, já em
fase de especificação e implementação, serão também disponibilizadas outras versões
da ferramenta com possibilidade de acesso via web, da geração das referências
bibliográficas de acordo com padrões como o ABNT e do apoio para a elaboração do
mapeamento sistemático [Peterson et al., 2008]. Embora a StArt não 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 vários alunos de pós-
graduação na condução de suas revisões bibliográficas. 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
Referências
BEdt. BibEdt. Disponível em: <http://bibedt.sourceforge.net>. Acesso em: Jun./2010.
BEnds. Bookends. Disponível em: <http://www.sonnysoftware.com>. Acesso em:
Jun./2010.
BI. Biblioscape. Disponível em: <http://www.biblioscape.com>. Acesso em:
Jun./2010.
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. Disponível em: <http://www.endnote.com>. Acesso em: Jun./2010.
JFREECHART. JFreeChart. Disponível em: <http://www.jfree.org/jfreechart>. Acesso
em: Jun./2010.
JR. JabRef. Disponível em: <http://jabref.sourceforge.net>. Acesso em: Jun./2010.
JWIZARD. JWizard. Disponível 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. Disponível 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 à Revisão Sistemática”. In: ESELAW - Experimental Software Engineering
Latin American Workshop, São Paulo. Proceedings IV Experimental Software
Engineering Latin American Workshop. Marília : Fundação de Ensino Eurípedes
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. Disponível 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, Itália.
RM. Reference Manager. Disponível em: <http://www.refman.com>. Acesso em:
Jun./2010.
RW. RefWorks. Disponível em: <http://www.refworks.com>. Acesso em: Jun./2010.
SWING. Swing. Disponível em: <http://java.sun.com/javase/6/docs/technotes/guides/swing>.
Acesso em: Jun./2010.
ZO. Zotero. Disponível em: <http://www.zotero.org>. Acesso em: Jun./2010.
96

Ferramenta de Apoio À Engenharia de Requisitos

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Ferramenta de Apoio À Engenharia de Requisitos

Enviado por

Direitos autorais:

Formatos disponíveis

Volume 4

Coordenadores Locais do SBES

Coordenador Geral do CBSOFT

Ano passado, membros da comunidade brasileira de software decidiram atacar este

O evento associado é a Conferência Latino-Americana em Linguagens de Padrões para

Eu concluo esta mensagem agradecendo a todos os envolvidos no planejamento e na

Tenho certeza que o CBSOFT produzirá muitas discussões interessantes e trará

Salvador, Setembro de 2010.

The associated event is the Latin-American Conference on Pattern Languages of

I am particularly proud of our 13 invited speakers, all recognized to be at the forefront

Salvador, September 2010.

O comitê de programa da Sessão de Ferramentas do CBSoft 2010 foi composto por 37

O sucesso da Sessão de Ferramentas do CBSoft 2010 é apenas possível por causa da

Esperamos que você aprecie o programa técnico da Sessão de Ferramentas do CBSoft.

Salvador, Setembro de 2010

Message from the Program Chair – CBSoft Tools Session

Salvador, September 2010

Uirá Kulesza is an Associate Professor at the Department of

Coordenador do Comitê de Programa – Chair

Comitê de Programa – Program Committee

Comitê Organizador – Organizing Committee

Coordenação Local SBES – SBES Local Co-Chairs

Coordenador Geral do CBSOFT – CBSOFT General Chair

Coordenadora de Organização do CBSOFT – CBSOFT Organizing

Coordenação Local SBES – SBES Local Co-Chairs

Coordenação Local SBCARS – SBCARS Local Co-Chairs

Coordenação Local SBLP – SBLP Local Co-Chairs

Time de Organização – Organizing Team

Apoio Executivo – Execution

Ferramenta de Apoio à Engenharia de Requisitos Integrada a um Ambiente

FIR-Diagram: Uma Ferramenta para apoiar a Análise de Impacto de Mudanças baseada

Uma Ferramenta de Apoio à Gerência de Requisitos Integrada a um Ambiente de

Análise e Visualização de Código / Code Analysis and Visualization

Analizo: an Extensible Multi-Language Source Code Analysis and Visualization

An Eclipse-Based Multiple View Environment to Visualize Software Coupling .........25

Hist-Inspect: Uma Ferramenta de Apóio à Avaliação Sensível à História de Código ...31

Refatoração e Reengenharia / Refactoring and Reengineering

AssistME – uma Ferramenta para Auxiliar a Refatoração para Aspectos de Tratamento

ComSCId & DMAsp: Identificação de Interesses Transversais e Recuperação de

Testes de Software / Software Testing

FERRARE GT: Automação de Testes de Desempenho e Estresse via Testes Funcionais

ModelT2: Apoio Ferramental à Geração de Casos de Testes Funcionais a partir de Casos

Linhas de Produto de Software / Software Product Lines

Fiesta Toolkit: Model-Driven Software Product Lines in Practice ................................61

TaRGeT: a Model Based Product Line Testing Tool.....................................................67

CIDE+: Uma Ferramenta para Extração Semi-automática de Linhas de Produtos de

Processos de Software / Software Processes

Uma Ferramenta de Apoio à Gerência de Conhecimento Integrada a um Ambiente de

Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum................................................85

Engenharia de Software Experimental / Experimental Software Engineering

StArt – Uma Ferramenta Computacional de Apoio à Revisão Sistemática ...................91

Projeto QUALI-EPT – Instituto Federal Fluminense (IFF)

Abstract. This paper presents a tool to support Requirements Engineering in

Resumo. Este artigo apresenta uma ferramenta para apoiar a Engenharia de

2. Fermine: ferramenta de apoio à ER integrada ao Redmine

Figura 1. Estrutura da ferramenta Fermine integrada ao Redmine (Fonte:

2.1. Principais Funcionalidades da Ferramenta Fermine

Figura 2. Manutenção e especificação de casos de uso na Fermine

A Figura 3 mostra como é feito o registro de requisitos funcionais e não-

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

A ferramenta está acessível em http://redmine.iff.edu.br:8000/, onde também é

4. Conclusões e Trabalhos Futuros

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