Sessão de Ferramentas XVII Sessão de Ferramentas

Tamanho: px
Começar a partir da página:

Download "Sessão de Ferramentas XVII Sessão de Ferramentas"

Transcrição

1 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

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

3 XVII Sessão de Ferramentas Kon, Sérgio Soares, Joe Yoder, Eric Tanter, e Mauro Pezzè, por virem à Salvador para o CBSOFT 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 Manoel Mendonça Coordenador Geral do CBSOFT 2010 iii

4 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 24 th edition, since its creation in 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 iv

5 XVII Sessão de Ferramentas 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 Manoel Mendonça CBSOFT General Chair v

6 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 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ósgraduaçã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 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

7 XVII Sessão de Ferramentas 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 1 st 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 Salvador, September 2010 Uirá Kulesza CBSoft Tools Session - Program Chair vii

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

9 XVII Sessão de Ferramentas 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

10 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

11 XVII Sessão de Ferramentas 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) Antonio Oliveira (DMCC/UFBA) Bruno Carreiro (DMCC/UFBA) Glauco Carneiro (DMCC/UFBA) Ivan Machado (DMCC/UFBA) Leandro Andrade (CC/UFBA) Apoio Executivo Execution DAGAZ Eventos Paulo Anselmo Silveira (Cin/UFPE) Raphael Oliveira (DMCC/UFBA) Renato Novais (DMCC/UFBA e IFBA) Rodrigo Rocha (DMCC/UFBA) Yguaratã Cavalcanti (CIn/UFPE) xi

12 Í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

13 XVII Sessão de Ferramentas 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) ModelT 2 : 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

14 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 Campos dos Goytacazes RJ Brasil 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

15 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 , 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

16 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 s 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 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

17 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ãofuncionais 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

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

19 Tabela 1. Comparação entre ferramentas Ferramentas Critérios Enterprise Jude Architect Professional Fermine 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êmse 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 MPS.Br - Melhoria de Processo do Software Brasileiro, acessado em 01/06/2010. QUALI-EPT - Projeto de Qualidade de Software Aplicada à Educação Profissional e Tecnológica, acessado em 01/06/2010. RENAPI - Portal da Rede Nacional de Pesquisa e Inovação em Tecnologias Digitais, acessado em 01/06/2010. Redmine, acessado em 01/06/2010. Enterprise Architect, acessado em 01/06/2010. Jude Professional Design & Modeling, acessado em 01/06/

20 FIR-Diagram: Uma Ferramenta para apoiar a Análise de Impacto de Mudanças baseada em Interesses de Negócio Antônio Oliveira Filho 1, Fabrício de Freitas Cardim 2, Tiano Oliveira Dórea 2, Christina von Flach G. Chavez 1 1 Universidade Federal da Bahia (UFBA) - Salvador, BA, Brasil 2 Faculdade Ruy Barbosa (FRB) - Salvador, BA, Brasil (aoliveiraf, ffcardim, Abstract. Change impact analysis supports the identification of potential consequences of a change. However, the techniques and tools used for impact analysis are dependent on existing software and business requirements that express the business rules of the organization. In this paper, we present the FIR-Diagram, a tool to support impact analysis based on business concerns, which arise from changes in business rules, independently of the existence of software artifacts that implement them. 1. Introdução Atualmente, software e negócio caminham juntos. Organizações estão inseridas em cenários sujeitos a mudanças constantes em seus negócios, nos quais os sistemas de software e as informações produzidas por eles têm importância crescente. Mudanças podem afetar regras de negócio (externas ao software) declarações utilizadas para restringir ou definir algum aspecto do negócio [Group 2010], podem ou não se manifestar em requisitos de negócio [Leite and Leonardi 1998] (no caso de existir software associado) e são potencialmente fontes de uma série de mudanças em regras e requisitos de negócio relacionados bem como em artefatos utilizados ao longo do ciclo de vida do software em questão. A análise de impacto de mudanças é a identificação das potenciais consequências de uma mudança, ou a estimativa do que precisa ser modificado para realizar uma mudança [Arnold 1996]. Em teoria, a análise de impacto precisa identificar todas as regras e requisitos de negócio afetados pela solicitação de mudança, porém, na prática, as técnicas e ferramentas atuais [Raja and Kamran 2008] dependem da existência de software que implemente as regras de negócio da organização. Não foram identificadas ferramentas que dêem suporte ao relacionamento entre regras de negócio, com ou sem a presença de software que as implemente. O modelo FIR (Funcionalidade-Informação-Regra) é um modelo de rastreabilidade que apóia a análise de impacto baseada em interesses de negócio [Oliveira Filho 2010, Oliveira Filho et al. 2008], ou seja, a análise de impacto que pode ser realizada a partir de mudanças solicitadas sobre regras de negócio. Interesses de negócio são definidos como agrupamentos de regras de negócio que compartilham os mesmos propósitos, de modo que, quando uma mudança é solicitada para uma regra de negócio de um determinado agrupamento, isso significa que existem interessados da 7

21 organização em descobrir os impactos relacionados a essa mudança que se manifestam em outro(s) agrupamento(s). Propósitos podem ser vistos como elos que relacionam regras de negócio de interesses de negócio distintos entre si através do compartilhamento de informaçõ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 à descoberta de impactos a partir de modelos FIR. A Seção 2 apresenta uma visão geral dos requisitos e características da ferramenta, a Seção 3 descreve suas principais funcionalidades e as ilustra por meio de um exemplo simples e a Seção 4 apresenta as considerações finais. 2. Visão Geral São requisitos de FIR-Diagram: Q 1 : A ferramenta deve permitir a criação de instâncias de FIR em modo gráfico; Q 2 : A ferramenta deve permitir a validação de instâncias de elementos a partir das restrições definidas para FIR; Q 3 : A ferramenta deve permitir a realização da atividade de descoberta de impactos sobre uma instância de FIR; Q 4 : A ferramenta deve permitir que instâncias de FIR possam estar disponíveis para integração com outras ferramentas; Q 5 : A tecnologia utilizada no desenvolvimento da ferramenta deve ser relevante tanto na indústria quanto na academia, de modo a motivar futuros interessados na evolução da ferramenta. A ferramenta foi implementada como um plugin para o ambiente Eclipse 1. A grande popularidade e relevância desse ambiente, tanto na indústria quanto na academia, satisfaz o requisito Q 5. Utilizamos o Graphical Modeling Framework (GMF), um framework que apóia o desenvolvimento de editores gráficos e atende os requisitos Q 1, Q 4 e Q 5. O GMF integra outros dois frameworks, o Eclipse Modeling Framework (EMF) e o Graphical Editing Framework (GEF). O EMF é uma implementação do MOF (Meta Object Facility) que predispõe os modelos criados à integração e responsável pelas transformações entre modelos criados em UML ou em linguagem de programação Java. O GEF permite criar um rico editor gráfico a partir de modelos construídos através do EMF. O GMF suporta a inclusão de restrições (constraints) durante a definição do modelo e, portanto, atende o requisito Q 2. No FIR-Diagram, as restrições foram implementadas usando duas das linguagens suportadas pelo GMF: Java e OCL. 3. Funcionalidades de FIR-Diagram Nesta Seção apresentamos as principais funcionalidades de FIR-Diagram, incluindo Criação de Instâncias de FIR (Seção 3.1), Aplicação das Restrições de FIR (Seção 3.2) e Descoberta de Impactos (Seção 3.3). O exemplo a seguir é utilizado para ilustrar cada uma das seções. Venda e emissão de ingressos. Empresas responsáveis pela venda de ingressos utilizam um software que tem como funcionalidade a emissão de ingressos, dentre outras. 1 8

22 Em um ingresso válido, devem constar as informações data e nome do evento, para conferência durante o acesso ao estádio. Recentemente, uma mudança na lei obrigou que no ingresso constasse o CPF do torcedor, além das informações já citadas. A partir do próximo campeonato, para ter acesso ao estádio, o torcedor deve carregar consigo um documento onde conste o CPF para conferência. Para tanto, cada torcedor deve ser cadastrado através de um serviço web que estará disponível para todas as empresas de venda de ingressos Criação de instâncias de FIR O plugin FIR-Diagram permite que instâncias de tipo de regras de negócio descritas pelo FIR [Oliveira Filho 2010] sejam criadas e relacionadas entre si. Por exemplo, as seguintes instâncias de regras de negócio de venda e emissão de ingressos podem ser criadas, onde F i, R k e I j, com i, k e j inteiros positivos, são utilizados para facilitar a identificação dos tipos de regras de negócio suportadas pelo FIR, e indicam os tipos Funcionalidade, Regra e Informação, respectivamente: Regra de negócio do tipo Funcionalidade F 1 : Cadastrar Torcedor; F 2 : Emitir Ingresso; F 3 : Liberar Acesso; Regra de negócio do tipo Regra R 1 : Se o CPF informado for válido, então o Torcedor-CPF é igual ao CPF informado; R 2 : Se Nome do Evento informado for válido, então o Ingresso-Nome-do-Evento é igual ao Nome do Evento informado; R 3 : Se a Data do Evento informada for válida, então o Ingresso-Data-do-Evento é igual à Data do Evento informada; R 4 : Se Torcedor-CPF for válido, então o Ingresso-Torcedor-CPF é igual a Torcedor-CPF informado; R 5 : O Ingresso-CPF deve ser igual ao CPF-do-Torcedor para que o acesso seja liberado; R 6 : O Ingresso-Nome-do-Evento deve ser igual ao nome do evento para que o acesso seja liberado; R 7 : O Ingresso-Data-do-Evento deve ser igual a Data do Evento para que o acesso seja liberado; Regras de negócio do tipo Informação I 1 : Torcedor-CPF; I 2 : Ingresso-Nome-do-Evento; I 3 : Ingresso-Data-do-Evento; I 4 : Ingresso-CPF; A Figura 1 é uma representação gráfica do exemplo de venda e emissão de ingressos construída com o FIR-Diagram. Os elementos Funcionalidade, Informação e Regra são representados através de círculos coloridos de acordo com cada tipo. Os elos de dependência entre esses elementos são representados por ligações entre os círculos. As ligações direcionadas representam os conceitos de produção, quando a origem está em uma regra e o destino está em uma informação, e consumo, 9

23 Figura 1. Diagrama de instâncias do FIR quando ocorre o oposto. A ligação não direcionada representa o conceito de execução, onde uma ou mais regras são executadas por uma funcionalidade. Na Figura 1, a regra R 3 produz a informação I 3 quando a funcionalidade F 2 é executada, e essa informação será consumida pela regra R 7 quando a funcionalidade F 3 for executada. As regras de negócio no FIR podem ser separadas em dois grupos: as que fazem parte do software (representam requisitos de negócio) e as que estão fora do software. Os requisitos de negócio são identificados em tons de verde, que vão do verde mais escuro (instâncias do tipo Funcionaldiade) para o verde mais claro (instâncias do tipo Informação). As regras de negócio que estão fora do software são identificadas em tons de cinza, que vão do cinza mais escuro (instâncias do tipo Funcionaldiade) ao cinza mais claro (instâncias do tipo Informação) Aplicação das Restrições de FIR No FIR-Diagram, a validação do diagrama está disponível a partir de um item de menu validate de Diagram, adicionado ao Eclipse quando o plugin FIR-Diagram é instalado. Durante a validação, se algum elemento do modelo está violando umas das restrições, ele é marcado com o x destacado em vermelho, indicando um erro no diagrama. A lista de erros encontrados na validação é exibida na aba Problems do Eclipse (Figura 2 (d)). A Figura 2 (a) apresenta uma restrição imposta ao modelo. De acordo com o exemplo proposto, a regra R1 é executada pela funcionalidade F1, logo, deveriam estar associadas. Isso implica em dizer que: a funcionalidade de cadastrar torcedor só poderá ser executada se existir um CPF válido. Após a execução da regra R1, uma informação deve ser produzida (Torcedor-CPF). Na Figura 2 (b), esse elo de produção foi retirado propositalmente para a demonstração de outra restrição: um informação sempre é proveniente de uma regra (Produção). As regras R 5,R 6 e R 7 não fazem parte do 10

24 (a) Funcionalidade inválida (b) Regra inválida (c) Informação inválida (d) Aba Problems Figura 2. Validações do FIR-Diagram software de emissão de ingressos, mas precisam ser representadas no diagrama pois são regras do negócio. Elas são representadas com uma coloração diferente das regras que fazem parte do software. Para ter acesso ao jogo, o CPF que consta no documento de identificação do torcedor deve ser igual ao CPF impresso no ingresso (I 4 ). Essa regra (R 5 ) não está implementada no software e consome a informação (I 4 ) produzida dentro do software. Para violar essa restrição, retiramos a relação de consumo, como ilustra a Figura 2 (c). Se nenhuma das restrições for violada, pode-se afirmar que o diagrama com instâncias do FIR é válido (Figura 1) Descoberta de Impactos Para a descoberta de impactos foram considerados os elos de dependência entre os elementos do modelo. O algoritmo determina as regras que serão impactadas para mudanças que ocorrem em regras do modelo. A descoberta de impactos é realizada em termos de operações sobre um grafo que o diagrama representa. O algoritmo de descoberta de impactos é executado quando uma regra é selecionada no modelo. Através da informação produzida pela regra selecionada, o algoritmo percorre a lista das regras que dependem da informação produzida e adiciona a regra dependente na lista de impactos da regra selecionada. O algoritmo é executado recursivamente para cada regra dependente. Ao final, as regras impactadas são exibidas com um círculo vermelho. A Figura 3 mostra a descoberta de impactos para a regra R 1. A regra R 1 produz uma informação (Torcedor-CPF) que é consumida pela regra R 4, que, por sua vez, produz uma informação (Ingresso-CPF) que é consumida pela regra R 5. Caso uma mudança ocorra na regra R 1, a informação produzida poderá ser alterada e as regras R 4 e R 5 devem ser manualmente avaliadas com o objetivo de descobrir impactos. 11

25 Figura 3. Impactos de Mudança na regra R1 4. Conclusão Este artigo apresentou uma ferramenta baseada no modelo de rastreabilidade FIR (Funcionalidade-Informação-Regra) para análise de impacto de mudanças baseada em interesses de negócio. A ferramenta FIR-Diagram permite manipular instâncias dos tipos de regras de negócio suportados pelo modelo FIR ao implementar dois requisitoschave: os conceitos e as definições do FIR, como, por exemplo, Q 2 : A ferramenta deve permitir a validação de instâncias de elementos a partir das restrições definidas para FIR e Q 3 : A ferramenta deve permitir a realização da atividade de descoberta de impactos sobre uma instância de FIR. A ferramenta é compatível com a distribuição Eclipse Modeling Tools e o código fonte do projeto está disponível a partir do endereço https://firplugin.googlecode.com/svn/trunk/, sob a licença Eclipse Public License 1.0. Como trabalhos futuros, destacamos: (1) Controle de Granularidade: O modelo FIR apresenta uma granularidade muito fina das regras de negócio e a ferramenta FIR-Diagram pode implementar alguma estratégia para que o usuário tenha controle sobre essa granularidade, e (2) Rastreabilidade Horizontal: O modelo FIR deve ser aprimorado para suportar uma rastreabilidade horizontal com o código fonte e a ferramenta FIR-Diagram também deve ser estendida para este fim. Referências Arnold, R. S. (1996). Software Change Impact Analysis. IEEE Computer Society Press. Group, B. R. (2010). Definition of business rules - 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 técnica de rastreabilidade para análise de impacto de mudanças em interesses de negócio. Master s thesis, Universidade Salvador (UNIFACS). Oliveira Filho, A., de Mendonça Neto, M. G., and von Flach G. Chavez, C. (2008). Em busca de agilidade na análise de impacto: O artefato fir. Latin America Transactions, IEEE, 6(3): 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

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

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

28 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 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 Server WebAPSEE Manager Console WARM Client Protocolo RMI «interface» Inteface WARM Porta RMI WARM Server 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

29 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. A B C 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). 4. Trabalhos Relacionados 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

30 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 Requisitos Sim Não Sim Sim Cascateamento/Herança de Elos Não Não Não Sim Registro de Histórico de Mudança em Requisitos Não Não Sim Sim Baseline de Requisitos Não Não Sim Sim Versionamento de Requisitos e Baseline de Requisitos Não Não Não Sim Árvore de Impacto Parcialmente Não Não Sim Integração com PSEE Não Sim Não Sim Relacionamento entre Requisitos e Atividades Semântica dos Elos de Rastreabilidade 5. Considerações Finais Não Não Não Sim Não Sim Não Sim 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 sendo a mesma aderente à licença GNU-GPL (General Public License). 17

31 Referências Borland. Borland CaliberRM. Disponível em: Acesso em: jun 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 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 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 Pressman, Roger. S. (2005) Software Engineering: A practitioner s approach, McGraw Hill, 6th edition. Rational. Rational RequisitePro. Disponível em: 01.ibm.com/software/awdtools/reqpro/. Acesso em: jun 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: Itemid=120. Acesso em: jun

32 Analizo: an Extensible Multi-Language Source Code Analysis and Visualization Toolkit Antonio Terceiro 1, Joenio Costa 2, João Miranda 3, Paulo Meirelles 3, Luiz Romário Rios 1, Lucianna Almeida 3, Christina Chavez 1, Fabio Kon 3 1 Universidade Federal da Bahia (UFBA) 2 Universidade Católica do Salvador (UCSAL) 3 Universidade de São Paulo (USP) Abstract. This paper describes Analizo, a free, multi-language, extensible source code analysis and visualization toolkit. It supports the extraction and calculation of a fair number of source code metrics, generation of dependency graphs, and software evolution analysis. 1. Introduction Software engineers need to analyze and visualize the software they create or maintain in order to better understand it. Software Engineering researchers need to analyze software products in order to draw conclusions in their research activities. However analyzing and visualizing large individual software products or a large number of individual software products is only cost-effective with the assistance of automated tools. Our research group have been working with empirical studies that require largescale source code analysis, and consequently we resort to source code analysis tools in order to support some of our tasks. We have 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 software 1, available without restrictions, in order to promote the replicability of our studies by other researchers. Extensibility. The tool should provide clear interfaces for adding new types of analyzes, metrics, or output formats, in order to promote the continuous support to our studies as the research progresses. In this paper, we present Analizo, a toolkit for source code analysis and visualization, developed with the goal of fulfilling these requirements. Section 2 describes related work. Section 3 describes Analizo architecture. Section 4 presents Analizo features. Section 5 presents Analizo use cases. Finally, Section 6 concludes the paper and discusses future work. 1 In our work, we consider the terms free software and open source software equivalent. 19

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

34 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 Doxygen 3, a multi-language source code documentation system that contains a robust parser. Analizo::Extractors::Sloccount is an interface for David A. Wheeler s Sloccount 4, 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 interface for both users and higher-level applications. These tools use services provided by the other layers: they instantiate the core data structures, one or more extractors, optionally the metrics processors, an output format module, and orchestrate them in order to provide the desired result. Most of the features described in Section 4 are implemented as Analizo tools. Those tools are designed to adhere to the UNIX philosophy: they accomplish specialized tasks and generate output that is suitable to be fed as input to other tools, either from Analizo itself or other external tools. Some of the tools are implemented on top of others instead of explicitly manipulating Analizo internals, and some are designed to provide output for external applications such as graph drawing programs or data analysis and visualization applications. 4. Features 4.1. Multi-language source code analysis Currently, Analizo supports source analysis of code written in C, C++ and Java. However, it can be extended to support other languages since it uses Doxyparse, which is based on Doxygen and thus also supports several different languages 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

35 project-level, Analizo also provides basic descriptive statistics for each of the modulelevel metrics: sum, mean, median, mode, standard deviation, variance, skewness and kurtosis of the distribution, minimum, and maximum value. The following metrics are supported at the time of writing 5 : 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 modules/classes with at least one defined method, Total Number of Methods. Module-level metrics: Afferent Connections per Class, Average Cyclomatic Complexity per Method, Average Method LOC, Average Number of Parameters per Method, Coupling Between Objects, Depth of Inheritance Tree, Lack of Cohesion of Methods, Lines of Code, Max Method LOC, Number of Attributes, Number of Children, Number of Methods, Number of Public Attributes, Number of Public Methods, Response For a Class Metrics batch processing In most quantitative studies on Software Engineering involving the acquisition of source code metrics on a large number of projects, processing each project individually is impractical, error-prone and 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 analysis. This can also be used to analyze several releases of the same project, in software evolution studies Metrics history Sometimes researchers need to process the history of software projects on a more finegrained 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 Dependency Graph output Analizo can output module dependency information extracted from a source code tree in a format suitable for processing with the Graphviz 6 graph drawing tools. Figure 2(a) presents a sample dependency graph obtained by feeding Graphviz dot tool with Analizo graph output Evolution matrix Another useful Analizo feature is generating evolution matrices [Lanza 2001]. After processing each release of the project (see Section 4.3), the user can request the creation of an evolution matrix from the individual data 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

36 main_window.c 5 25 thumbnail_bar.c ewer.c 6 thumbnail.c 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 evolution matrix for a case study on the evolution of the VLC project. Later on, an evolution matrix tool was incorporated in Analizo itself. [Costa 2009] did a comparison between different strategies for extracting module dependency information from source code, leading to the development of Doxyparse the Analizo Doxygen-based extractor. [Terceiro and Chavez 2009] used the metrics output on an exploratory study on the evolution of structural complexity in a free software project written in C. [Morais et al. 2009] used the Analizo metrics tool as a backend for Kalibro 7, a software metrics evaluation tool. Later on, Kalibro Web Service 8 was developed, providing an integration with Spago4Q 9 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

37 Future work includes the development of a web-based platform for source code analysis and visualization based on Analizo. This project is current under development. Analizo is free software, licensed under the GNU General Public License version 3. Its source code, as well as pre-made binary packages, manuals and tutorials can be obtained from softwarelivre.org/mezuro/analizo. All tools are selfdocumented and provide an accompanying UNIX manual page. Analizo is mostly written in Perl, with some of its tools written in Ruby and Shell Script. This work is supported by CNPQ, FAPESB, the National Institute of Science and Technology for Software Engineering (INES), Qualipso project, and USP FLOSS Competence Center (CCSL-USP). References Amaral, V. (2009). Análise de evolucao de projetos de software livre através de matrizes de 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). Extração de informações de dependência entre módulos de programas c/c++. Undergraduation course conclusion project, Universidade Cató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 visualization 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 sourceforge.net/. Last access on June 3rd, 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 configuração e interpretação de métricas de código-fonte. Undergraduation course conclusion project, Universidade de São Paulo. Steffen, J., Hans-Bernhard, and Horman, B. N. (2009). Cscope. Terceiro, A. and Chavez, C. (2009). Structural Complexity Evolution in Free Software Projects: A Case Study. In Ali Babar, M., Lundell, B., and van der Linden, F., editors, QACOS-OSSPL 2009: Proceedings of the Joint Workshop on Quality and Architectural Concerns in Open Source Software (QACOS) and Open Source Software and Product Lines (OSSPL). Terceiro, A., Rios, L. R., and Chavez, C. (2010). An Empirical Study on the Structural Complexity introduced by Core and Peripheral Developers in Free Software projects. Submitted. 24

38 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, Salvador BA Brazil {glauco.carneiro, paulor062, arleson061, 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

39 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 Code Abstract Syntax Tree provided and used by Eclipse Model Scenario Visual Scenarios View(s) Information Extraction Model Mapping Mapping the Model to Each View + Software Maintenance Activity Control Filters Software Maintenance Activity Treemaps View Polymetric View Graph View Matrix View (A) (B) (C) Perspective 1 Perspective 2 Perspective 3 Grid View Egocentric Graph View TXT Log File for Data Acquisition of Primitive Operations Figure 1: An overview of the Multiple View Software Visualization Environment 26

40 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

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

42 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

43 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 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, Lanza, M.; Ducasse, S. Polymetric Views - A Lightweight Visual Approach to Reverse Engineering. In IEEE Transactions on Software Engineering (TSE), M.-A. Storey. Theories, tools and research methods in program comprehension: past, present and future. Software Quality Control, 14(3): , Wu, J., and M.-A. Storey. A multi-perspective software visualization environment. In Proceedings of CASCON'2000, November 2000, pp Shneirderman, B. Tree Visualization with Tree-Maps: A 2-D Space-Filling Approach. ACM Transactions on Graphics (ToG) 11, 1 (1992), 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 Singapore, Eick, S.; Steffen, J.; Eric S. SeeSoft A Tool for Visualizing Line Oriented Software Statistics. IEEE Transactions on Software Engineering, 18(11): , November 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,

44 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 Abstract. Only a few studies have investigated the influence of considering historic properties of evolving code in the detection of modularity flaws. A key reason is the lack of adequate tooling support for history-sensitive anomaly detection. 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 conventional 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 modularidade 1 [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. Sabese, 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ódulos para detectar possíveis anomalias. Dessa forma, elas perdem informações importantes como instabilidade dos módulos, aumento contínuo de complexidade, dentre outras. Apesar 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 individuais 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 sensí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

45 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ódulos. 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 complicado 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 configuraçã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 m 1 /m 2 ou a expressão m 1 > m 2, onde m 1 e m 2 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-Inspect 2 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

46 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. Portanto, 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 pesquisa 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 JFreeChart 4. 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 evoluçã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 quatidade 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 especificação é uma DSL Interna [8], nomeada DSSL 5. 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 lsilva 4 5 Do inglês, Detection Strategy Specification Language (Linguagem de Especificação de Estratégias de Detecção) 33

47 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 3.2. Arquitetura e Funcionamento (b) Relatório HTML de Detecções Figura 1. Funcionalidades Básicas da Hist-Inspect 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 separados 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 plataforma 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.mtbl 6 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

48 Entrada Oráculo de Anomalias Hist-Inspect (Módulo de Estratégias de Detecção) Saída Métricas (V.1) Parser Gerador do Modelo SH Modelo SH Avaliador de Regras DSSL Gerador de Relatórios Métricas (V.2) Relatório de Detecção... Métricas (V.n) Lista de arquivos de métricas Especificação de Métricas SH Catálogo Catálogo de Regras de em DSSL Anomalias Templates Figura 2. Funcionamento e Elementos Principais da Arquitetura da Hist-Inspect gerado utilizando o framework XMLBeans 7, 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 outro 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 representam 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 Regras 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 informações produzidas pelo Avaliador de Regras com um Template HTML, gerando o Relatório que será apresentado ao usuário. O Gerador de Relatórios processa templates de relatórios utilizando a linguagem de templates Velocity 8. Opcionalmente, também é possível inserir nesse relatório de detecções informações sobre falsos positivos e negativos,

49 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. 4. Conclusões e Trabalhos Futuros Este artigo apresentou uma visão geral da Hist-Inspect, uma ferramenta que como característica principal suporta a especificação e execução de estratégias de detecção. Atualmente, 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], observouse que em 7 versões de um sistema, estratégias sensíveis à história se apresentaram eficazes 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 anomalias 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 classes Java. Entretanto, no futuro elas poderiam ser implementadas utilizando uma linguagem de Script (como Java Script, Rubby ou Lua) ou uma nova DSL. Tal fato, possibilitaria a criação e obtenção de resultados de novas métricas SHs sem a necessidade de recompilar 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. Secaucus, NJ, USA: Springer-Verlag New York, Inc., [2] M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts, Refactoring: Improving the Design of Existing Code. Addison-Wesley, Reading, MA, USA, [3] D. Ratiu, S. Ducasse, T. Girba, and R. Marinescu, Evolution-enriched detection of god classes, in CAVIS 04, 2004, pp [4] Together. Website. [Online]. Available: [5] incode. Website. [Online]. Available: [6] iplasma. Website. [Online]. Available: [7] infusion. Website. [Online]. Available: [8] A. van Deursen, P. Klint, and J. Visser, Domain-specific languages: an annotated bibliography, SIGPLAN Not., vol. 35, no. 6, pp , [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,

50 AssistME uma Ferramenta para Auxiliar a Refatoração para Aspectos de Tratamento de Exceções Cristiane Queiroz 1, Fernando Castor 2, élio Cacho 3 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 Abstract. One of the potential application areas of Aspect Oriented Programming (AOP) is to modularize exception handling code, localizing handlers within concern-specific units. Existing systems can also leverage the benefits of AOP if their exception handlers are moved to aspects by means of refactoring. otwithstanding, such refactoring requires knowledge about a number of scenarios and conditions that make it a time-consuming and errorprone activity. This paper presents AssistME, a tool that assists developers in refactoring Java exception handlers to aspects. 1. 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

51 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 Eclipse 1, 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

52 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

53 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

54 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

55 Fernando é parcialmente financiado pelo CNPq/Brasil, /2008-7, e pelo Instituto Nacional de Ciência a Tecnologia para Engenharia de Software, financiado por CNPq e FACEPE, / e APQ /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 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 4 th international conference on AOSD. Pages: 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): Diego Cavalcanti (2009) "Improving safety when refactoring aspect-oriented programs". In OOPSLA'2009 Companion, pages L. Cole and P. Borba. (2005) Deriving refactorings for aspect. In Proceedings of the 4th ACM Conference on AOSD, pages 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, Lippert, M e Lopes,C. V. (2000). A study on exception detection and handling using aspect oriented programming. In Proceedings of the 22nd ICSE, , Ireland. M. P. Monteiro e. M. Fernandes (2005). Towards a catalog of aspect-oriented refactorings. In Proceedings of the 4th AOSD, pages Sérgio Soares, Eduardo Laureano, Paulo Borba (2002) "Implementing distribution and persistence aspects with aspectj". In Proceedings of OOPSLA 2002:

56 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únior 1, Heitor Augustus Xavier Costa 2, Valter Vieira de Camargo 3µ, Rosângela Aparecida Dellosso Penteado 4 1, 3, 4 Departamento de Computação Universidade Federal de São Carlos Caixa Postal 676 CEP São Carlos SP Brasil 2 Departamento de Ciência da Computação Universidade Federal de Lavras Caixa Postal 3037 CEP Lavras MG Brasil { 1 paulo_junior, 3 valter, 4 2 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 / µ Apoio Financeiro CNPq pelo Proc no /

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

58 Figura 3. Tela para Cadastramento das Classes Associadas ao Pacote java.sql Figura 4. Tela para Cadastramento das 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

59 (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

60 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*/Community 1. 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. 4. Trabalhos Relacionados 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

61 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: Referências Bibliográficas Janzen, D., and Volder, K. D. Navigating and querying code without getting lost. In: Aspect-Oriented Software Engineering, pages 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 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, 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 ,

62 FERRARE GT: Automação de Testes de Desempenho e Estresse via Testes Funcionais Ismayle de Sousa Santos 1, Alcemir Rodrigues Santos 1, Pedro de Alcântara dos Santos Neto 1 1 Departamento de Informática e Estatística Universidade Federal do Piauí (UFPI) Campos Ininga Teresina PI Brasil 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

63 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 scripts 1 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

64 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 IDE 2, e o CanooExtractor, ao Canoo Web Test 3. 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

65 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êmse 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

66 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

67 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. 5. Conclusões e Trabalhos Futuros 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 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 , 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 , 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 , Los Alamitos, CA, USA. 54

68 ModelT 2 : 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 Rio de Janeiro RJ Brasil. 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 ModelT 2 that uses the concept of model-to-model transformation is described. It aims to support the semiautomatic derivation of Test-cases and Test-procedures for system testing from its functional specification with Use Cases. 1. 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 ModelT 2 (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

69 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. ModelT 2 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 ModelT 2. 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 ModelT 2 A proposta de concepção de ModelT 2 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 ModelT 2 e o seu contexto de atuação podem ser visualizados na Figura 1. Nessa figura podemos notar que ModelT 2 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 ModelT 2 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 ModelT 2 56

70 ModelT 2 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 ModelT 2, 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 ModelT 2 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 ModelT 2 (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

71 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 ModelT 2 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

72 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 ( adm1$ ) e valores inválidos ( @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. Tabela 1. Exemplo de caso/procedimento de testes gerados por ModelT 2 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 3 Sistema informa login/senha incorretos 6 adm1$ 4 Apresenta menu Proc 2 5 Sistema solicita login e senha 2 adm1$ 6 Internauta informa login e senha 6 adm1$ 7 Sistema apresenta menu de opções Proc 3 6 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 ModelT 2, 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 ModelT 2 O uso de ModelT 2 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 ModelT 2 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 ModelT 2. 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

73 do desenvolvedor, a percepção de esforço e dificuldade na geração dos casos de teste usando ModelT 2 e entender a diferença na cobertura dos casos de teste gerados pela ModelT 2 em relação a outros casos de teste gerados sem apoio ferramental. 7. Conclusões e Trabalhos Futuros Neste artigo foram descritos o projeto e as características de uma ferramenta, chamada ModelT 2, para geração de casos e procedimentos de teste funcionais a partir de modelos de Casos de Uso. ModelT 2 apóia-se no uso intensivo de transformações semiautomá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, ModelT 2 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 ModelT 2, 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 ModelT 2, assim como alguns modelos exemplificando seu uso, pode ser encontrada em 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 , Vila Velha, ES. France R., Rumpe, B., (2007) Model-driven development of complex software: A research roadmap, Future of Software Engineering (FoSE), pp 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 , 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, 2 nd ed., John Wiley & Sons, New Jersey. 60

74 Fiesta Toolkit: Model-Driven Software Product Lines in Practice Hugo Arboleda 1, Andrés Romero 2, Rubby Casallas 2, Jean-Claude Royer 3 1 Universidad Icesi DRISO Group, Cali-Colombia 2 Universidad de Los Andes Software Construction Group, Bogotá-Colombia 3 Mines de Nantes - INRIA ASCOLA Group, Nantes, France 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 finegrained configurations of products, i.e. configurations at the level of each element in models that will be transformed into product line members. For that, the toolkit includes a set of tools for the creation of MD-SPL projects, feature models, constraint models, binding models, OCL-type expressions to validate binding models against constraint models, and decision models. 1. Introduction Software Product Lines (SPL) are sets of software systems that have a similar purpose and share common features. In SPL Engineering, product development is separated into (1) domain engineering, which involves creating and maintaining a set of reusable artifacts; and (2) application engineering, where these reusable artifacts are used to build the products [Pohl et al. 2005]. Model-Driven Engineering (MDE) claims to improve software construction using models as 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 developed from models which conform to metamodels, and that are derived from a set of model transformations. As part of our earlier work, we presented an MD-SPL approach including mechanisms to extend the scope of more traditional MD-SPLs approaches [Arboleda et al. 2009b, Arboleda et al. 2009a]. In this paper we present the Fiesta toolkit, which is our framework for creation of MD-SPLs. Fiesta is acronym for FInE-grained Scope definition, configuration and derivation of model driven and software product lines. The Fiesta toolkit implements facilities to (1) capture fine-grained variations 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

75 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 application metamodels, feature models and constraint models to capture the variability and commonalities of MD-SPLs. Constraint models make it possible for product line architects to capture and express the valid 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 transformations which consist of sets of transformation rules. Each transformation rule is responsible 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 designers create (1) domain application models that conform to domain application metamodels, and (2) binding models, which are sets of bindings between model elements and features. After a binding model is created, we validate this against a set of OCL-Type sentences derived from its respective constraint model. To derive a complete product according to a binding model, we dynamically adapt the parameters of model transformation executions. We achieve it using model transformation rules which are selected from the binding model and the pre-created decision models. 62

76 3. The Fiesta Toolkit Along with Fiesta we provide Eclipse plug-ins to create MD-SPL projects, feature models [Kang et al. 1990, Czarnecki et al. 2004], constraint models, binding models, OCLtype expressions to validate binding models against constraint models, and decision models. We also provide openarchitectureware (oaw) components to facilitate the processing of binding models and decision models to derive products. The entire Fiesta toolkit, the instructions for installing it and two case studies, can be found in the web-site of our research group [DRISO Group 2010]. Figure 2 presents a high level architecture of Fiesta from a static viewpoint. For the implementation of our tool support we chose the Eclipse platform as general framework and EMF as modeling framework, which means we express all our metamodels based on the Ecore meta-metamodel. We opted to use oaw 1 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 Topcased 2. Figure 2. High Level Fiesta Architecture 3.1. Domain Engineering MD-SPL Project Creation. We built an Eclipse plug-in that allows product line architects to create a particular type of Eclipse projects. This type of projects includes the required oaw and EMF dependencies to create MD-SPLs and predefine a hierarchical folders structure to manage and centralize the core assets associated to an MD-SPL project. We named this plug-in the (MD-SPL) Project Creator. Metamodels and Feature Models Creation. Once an MD-SPL project has been created product line architects create metamodels and feature models. Metamodels are created by using MagicDraw 3, 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

77 Figure 3. Binding Models Creator as pure::variants 4 or tools which are under development and do not provide mature APIs such as fmp 5. Constraint Models Creation. We built an Eclipse plug-in to create constraint models, the Constraint Models Creator. Using our Constraint Models Creator product line architects can load a metamodel and a feature model, and then to create and delete constraints. The Constraint Models Creator allows for capturing the properties associated to our constraints and a description associated to it. When a product line architect selects to save a constraint model, the plug-in performs two activities. First, it saves a 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 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 selects 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 5 gsd.uwaterloo.ca/projects/fmp-plugin/ 64

78 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 uncoupled (1) the information of features, (2) the transformation rules, and (3) the possible execution s conditions of transformation rules that particular feature configurations imply. Furthermore, our Decision Models Editor allows product line architects to capture as independent Aspects [Filman et al. 2005]the information of how transformation rules must be composed to derive 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 execute 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

79 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 mechanisms 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 mechanisms include the use of constraint models which include the cardinality and structural properties, binding models and more expressive decision models. We discussed our general strategy for validating binding models against constraint models and for generating executable model transformation workflows from decision models, which allow us to derive 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 configurations 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 LNCS DRISO Group (last visited in June 2010). Model-Driven Software Product Line Engineering: Tool Support and Case Studies. In Filman, R. E., Elrad, T., Clarke, S., and Sit, M. A., editors (2005). Software Development. Addison-Wesley, Boston. Aspect-Oriented Kang, K., Cohen, S., Hess, J., Nowak, W., and Peterson, S. (1990). Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90-TR-21. Pohl, K., Böckle, G., and van der Linden, F. (2005). Software Product Line Engineering: 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

80 TaRGeT: a Model Based Product Line Testing Tool Felype Ferreira 1, Laís Neves 1, Michelle Silva 1 and Paulo Borba 1 1 Informatics Center Federal University of Pernambuco (UFPE) Recife PE Brazil Abstract. To assure software quality and reliability, software testing is a technique that has grown in importance over the years. However, testing can increment development costs in about 50% of the 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 quality and reliability. Despite the fact that it is an important software development activity, testing software systems can be expensive. Studies suggest that testing often takes approximately 50% of the total software development cost [Ramler and Wolfmaier 2006]. So it is important to 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 approach for dealing with requirements and test artifacts in an integrated way, in which test cases can be automatically generated from use cases scenarios written in natural language, which are used to automatically derive the system model that is transparent to the users. For this, TaRGeT 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, instead of having people to maintain and create a large number of test cases, with TaRGeT 67

81 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 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 English. 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 system 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

82 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 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 generate 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 purposes. A test purpose is an abstract description of a subset of the specification, allowing choosing behaviors to test and, consequently, allowing reducing the specification 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 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

83 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 corresponding 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 customers particular needs with a significant reduction of the effort and cost required to implement product variations. Figure 3 shows how the dependences between the implemented plug-ins are organized. The main responsibilities of the application are distributed in four distinct basic plug-ins. 70

84 Figure 3. Dependencies between plugins TaRGeT Core plug-in: responsible for system starting up and setting up the workspace and perspective of the RCP application. Common plug-in: implements basic entities to represent use cases documents and test case suites. Beside that, it contains parsers for different input formats and provides support to new implementations for new input formats. Project Manager plug-in: contains operations and exceptions to handling projects, test case generation algorithm, basic GUI components to be extended in the implantation and support for implementing variabilities to make TaRGeT compatible with different formats of input use case documents. Test Case Generation plug-in: generates test case suites in different formats and provides support to extend TaRGeT with new implementations for different output formats. 4. Brief Comparison with Other Related Tools There are many model based testing tools like TaRGeT. In this section we chose two tools to make a brief comparison with TaRGeT: AsmL Test Tool and Conformiq. The Table 1 summarizes the main differences among the tools. AsmL Test Tool it was developed by Microsoft and uses AsmL (Abstract State Machine Language) that is an executable modeling language which is fully integrated in the.net framework and Microsoft development tools [Barnett et al. 2004]. Conformiq [Conformiq 2010] is a tool for automatically designing and creating test cases. It uses as input system models in Java and UML compatible notation, mathematically calculates sets of test cases and exports the test cases in the format chosen by the user that can be TCL, TTCN-3, Visual Basic, HTML, XML or Python. 5. License TaRGeT is an open source software whose code and documentation are covered by the MIT license [MIT 2010]. The complete license text and the tool can be found at [TestProductLines 2010]. 71

85 Table 1. Comparison among tools. 6. Acknowledgements We would like to thank National Institute of Science and Technology for Software Engineering (INES) [INES 2010] and Motorola Brazil in a cooperation project for partially supporting this work, CNPq and FACEPE for partially funding it, grants / and APQ /08. In addition, we thank all research team members, especially Sidney Nogueira, Emanuela Gadelha, Dante Torres and Gustavo Cabral, who collaborated with this project. References Barnett, M., Grieskamp, W., Nachmanson, L., Schulte, W., Tillmann, N., and Veanes, M. (2004). Towards a tool environment for model-based testing with asml. Microsoft Research. Clements, P. and Northrop, L. (2002). Software Product Lines: Practices and Patterns, page 563. Addison-Wesley. Conformiq (2010). Conformiq test generator. 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. Levenshtein, V. I. (1966). Binary codes capable of correcting deletions, insertions, and reversals. Soviet Physics Doklady. MIT (2010). MIT License. Ramler, R. and Wolfmaier, K. (2006). Economic perspectives in test automation - balancing automated and manual testing with opportunity cost. Workshop on Automation of Software Test ICSE. RCP (2010). RCP FAQ. FAQ. TestProductLines (2010). Tests generation, selection, prioritization and processing product line. 72

86 CIDE+: Uma Ferramenta para Extração Semi-automática de Linhas de Produtos de Software Usando Coloração de Código Virgílio Borges de Oliveira 1, Rógel Garcia 2, Marco Túlio Valente 2 1 Instituto de Informática, PUC Minas 2 Departamento de Ciência da Computação, UFMG Resumo. The extraction of real-world software product lines is a complex and time-consuming task. In order to accelerate this task, this paper presents a tool called CIDE+ that automates the annotation of optional features of existing systems. For this purpose, CIDE+ supports the semi-automatic association of background colors to the lines of code that implement an optional feature. CIDE+ has been successfully applied in extracting features of three non-trivial systems: Prevayler (an in-memory database), JFreeChart (a chart library) and ArgoUML (an editor for UML diagrams). 1 Introdução A extração de linhas de produtos de software a partir de sistemas existentes é uma tarefa complexa e custosa [4]. Em primeiro lugar, desenvolvedores precisam identificar os componentes responsáveis pela implementação de cada feature da linha de produtos. Em seguida, eles devem identificar aqueles trechos de código que referenciam os componentes descobertos no passo anterior. Por último, deve-se anotar esses trechos de alguma forma ou movê-los para novas unidades de modularização. Assim, a fim de acelerar a extração de linhas de produtos, descreve-se neste artigo uma ferramenta desenvolvida com o objetivo de automatizar de forma parcial a anotação de features opcionais de sistemas existentes. A ferramenta proposta é baseada em uma extensã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 código que implementam features. Portanto, em vez de anotações textuais, tais como #ifdef e #endif, desenvolvedores podem usar anotações visuais para delimitar as linhas de código que pertencem a uma determinada feature. Além disso, o ambiente CIDE permite a geração de projeções de um sistema nas quais todo código anotado com uma determinada cor é removido. Essa forma de projeção permite a geraçã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 anotação semi-automática de có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 código responsáveis pela implementação de uma feature que desejam incluir na linha de produtos. Normalmente, essa tarefa é custosa, tediosa e sujeita a erros. Por outro lado, usando CIDE+, tais tarefas são automatizadas. Para isso, inicialmente a ferramenta requer que engenheiros de linhas de produtos forneçam como entrada um conjunto de elementos sintáticos incluindo, por exemplo, pacotes, classes, métodos e campos responsáveis pela implementação de uma feature. Esses elementos 73

87 sã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 está organizado conforme descrito a seguir. A Seção 2 descreve o processo de extração de features automatizado pela ferramenta CIDE+. Na Seção 3, apresenta-se um pequeno exemplo de uso da ferramenta. A Seção 4 sumariza os resultados obtidos na aplicação da ferramenta em três sistemas não-triviais. Por fim, a Seção 5 discute ferramentas relacionadas e a Seção 6 conclui o artigo. 2 Extração de Features com CIDE+ CIDE+ agrega ao ambiente CIDE a capacidade de anotação automática de trechos de código usando cores de fundo. A Figura 1 apresenta o processo iterativo e semi-automático para anotação visual de features pressuposto pela ferramenta. Os passos desse processo são discutidos nos parágrafos seguintes. Figura 1. Processo iterativo e semi-automático para extração de features Definição das Sementes: Inicialmente, desenvolvedores devem informar as sementes da feature a ser extraída. Sementes podem incluir os seguintes elementos sintáticos: campos, métodos, classes ou interfaces e pacotes. Portanto, a ferramenta pressupõe que os engenheiros tenham um conhecimento básico da arquitetura e do projeto do sistema alvo da extração. Mais especificamente, eles devem ser capazes de informar os elementos do programa que são integralmente responsáveis pela implementação da feature que desejam extrair do sistema. Algoritmo de Anotação: Tendo como entrada as sementes definidas, esse algoritmo trata de colorir todas as partes do código que referenciam de forma direta ou indireta os elementos classificados como sementes. Basicamente, o algoritmo proposto é um algoritmo de ponto-fixo, com duas fases. Na primeira fase, chamada de propagação de cores, os elementos do programa que referenciam as sementes são visualmente anotados com uma cor informada pelo engenheiro da linha de produtos. Por exemplo, suponha que o método 74

88 m 1 tenha sido classificado como uma semente. Portanto, nessa primeira fase, qualquer chamada de m 1 será visualmente anotada com a cor fornecida. Na segunda fase, chamada de expansão de cores, o algoritmo verifica se o contexto léxico dos elementos anotados na primeira fase também pode ser colorido. Suponha, por exemplo, que a implementação de um método m 2 apenas inclui uma chamada a m 1, a qual foi anotada na primeira fase do algoritmo. Nesse caso, a implementação de m 2 também será colorida (assim como todas as suas chamadas). Como o foco do presente artigo é apresentar a ferramenta CIDE+, não são fornecidos mais detalhes sobre o algoritmo de anotação. O leitor interessado em tais detalhes deve se dirigir a um outro trabalho de nosso grupo [2]. Expansões Semi-automáticas: Em situações especiais, o algoritmo proposto pode gerar código com erros sintáticos ou de tipo. Suponha, por exemplo, a expressão opcao == algumaconstante, onde opcao foi anotada mas algumaconstante não foi. Dessa forma, a projeção incluindo apenas == algumaconstante não irá compilar por apresentar erros de sintaxe. Em outro exemplo, suponha que todos os comandos return de um determinado método foram anotados, mas os demais comandos não. Após a remoção do código anotado, um erro de tipo será reportado (comando return ausente). Em tais situações, a aplicação de qualquer tipo de expansão corretiva é uma tarefa desafiadora e complexa. Quando uma anotação leva a erros de sintaxe ou de tipo e nenhuma expansão pode ser seguramente aplicada, o algoritmo proposto gera uma mensagem explicando o erro. Posteriormente, é sugerida uma expansão padrão para tratar o erro detectado, como descrito na Tabela 1. Por exemplo, a ferramenta pode sugerir a anotação de toda uma expressão (caso ela tenha sido parcialmente anotada) ou de todo um método (caso todos os seus comandos return tenham sido anotados). Se o desenvolvedor aceitar as sugestões, a ferramenta automaticamente aplica tais expansões ao código, a fim de eliminar os erros. SE1 SE2 SE3 SE4 Definição Apenas partes de uma expressão foram anotadas Os comandos return de um método foram anotados, mas o método tem outros comandos que não foram anotados Um parâmetro de chamada foi anotado, mas o parâmetro formal associado a ele não foi anotado O lado direito de uma expressão foi anotado mas o lado esquerdo não anotado Expansão Padrão Anotar toda a expressão Anotar todo o corpo do método Anotar toda a chamada Anotar o lado esquerdo e suas referências Tabela 1. Expansões Semi-automáticas Avaliação dos Resultados: Finalizada a execução do algoritmo de anotação, resta ao engenheiro responsável pela extração duas tarefas. Primeiro, ele deve detectar e corrigir eventuais erros de sintaxe que tiverem sido inseridos no código. Em geral, esses erros são inseridos quando o engenheiro optou por não aceitar uma das expansões padrão sugeridas pela ferramenta durante a execução do algoritmo de anotação. Em seguida, o engenheiro 75

89 deve avaliar a cobertura das anotações visuais inseridas no código, isto é, se todas as linhas de código dedicadas à implementação da feature foram de fato coloridas. Para isso, recomenda-se que ele gere uma projeção do sistema sem a feature em questão e que execute o produto gerado, de forma a se certificar de que a feature realmente não se encontra mais presente no sistema. Nessa execuçã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 extração. Em resumo, o processo proposto possui as seguintes características: (a) semiautomático, pois requer a definição das sementes das features extraídas e a aprovação de determinadas expansões de cores; (b) iterativo, pois pode requerer mais de um ciclo de execução, até obter uma cobertura de todo o código responsável pela feature. O grau de cobertura obtido e o número de iterações requeridas depende basicamente de sementes que incluam todas os elementos do programa que respondem pela implementação da feature sob extração. 3 Exemplo de Uso Suponha uma classe hipotética Stack com um método push. Suponha que essa classe faça parte de um sistema maior com as features descritas na Tabela 2. Além do nome das features e de uma breve descrição do papel das mesmas na classe Stack, essa tabela mostra também as sementes escolhidas como entrada para a ferramenta CIDE+. Feature Descrição Sementes Logging Log de eventos internos da pilha Classe Log Snapshot Salva elementos em meio persistente Método snapshot Multithreading Versão thread-safe da pilha Classe Lock Tabela 2. Features da classe Stack e suas respectivas sementes A Figura 2 apresenta o código da pilha colorido pela ferramenta CIDE+. Nesse exemplo, chama a atenção a chamada de log realizada no interior do primeiro if do método push. Como essa chamada está aninhada em um bloco de código relativo à feature Multithreading, ela recebeu duas cores: a cor de Logging (verde) e a cor de Multithreading (vermelho). Quando isso ocorre, a ferramenta usa a cor resultante da mistura física das duas cores entrelaçadas (isto é, vermelho+verde = amarelo). Na parte inferior da Figura 2 mostra-se uma representação da AST do programa gerada pela ferramenta CIDE+. Veja que os nodos responsáveis pelos blocos de código coloridos no editor são também mostrados coloridos. 4 Estudos de Caso CIDE+ foi usada com sucesso para extrair features de três sistemas: Prevayler (um banco de dados em memória principal), JFreeChart (uma biblioteca gráfica) e ArgoUML (um editor de diagramas UML). A Tabela 3 sumariza a experiência de uso de CIDE+ nesses três sistemas. Para cada sistema, a tabela informa o tamanho de seu código fonte (em megabytes), uma breve descrição das features extraídas, o percentual do código fonte anotado para extração de cada uma das features, o número de expansões semi-automáticas (SE) requeridas durante a extração e o número de iterações que foram requeridas até se obter uma cobertura completa do código de cada feature extraída. 76

90 Figura 2. Método push com features anotadas pela ferramenta proposta Sistema Tam. (MB) Feature % Tam. # SE # Iter. Monitor Prevayler 0.16 Replication Censoring JFreeChart 7.5 Pie Charts D charts StateDiagrams ArgoUML 8.95 ActivityDiagrams Design Critics Logging Tabela 3. Resultados sumarizados dos estudos de caso 5 Ferramentas Relacionadas Pelo menos que seja de nosso conhecimento, não existem outras ferramentas para extração automática de features em linhas de produtos usando anotações (sejam elas textuais, como diretivas de pré-processamento, ou visuais, como cores de fundo). Sendo assim, as ferramentas mais próximas são aquelas projetadas para apoiar a extração física de features para unidades de modularização, normalmente para aspectos. Como exemplo, podemos citar as ferramentas AOP-Migrator [1] e FOR [4]. No entanto, essas ferramentas requerem uma participação e envolvimento muito maior dos engenheiros responsáveis pelo processo de extração. O principal motivo é que linguagens como AspectJ se baseiam em um modelo de granularidade grossa para extensão de progra- 77

91 mas [3]. Em outras palavras, essas linguagens pressupõem que o código responsável pelas features esteja presente em determinadas localizações estáticas do código fonte. Como nem sempre isso ocorre, essas ferramentas requerem um passo preliminar de preparação do código fonte visando a sua extração para unidades próprias de modularização. Em geral, esse processo de preparação requer um conhecimento detalhado do código, que impede a sua automatização [6, 5]. 6 Comentários Finais Neste artigo, foi apresentada a ferramenta CIDE+, a qual estende o ambiente CIDE com a coloração automática de código responsável pela implementação de features em linhas de produtos de software. Mais informações sobre a ferramenta podem ser obtidas em: mtov/cideplus. Agradecimentos: Este trabalho foi apoiado pela FAPEMIG, CAPES e CNPq. Referê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 Engineering, 32(9): , [2] Virgilio Borges and Marco Tulio Valente. Coloração automática de variabilidades em linhas de produtos de software. In III Simpósio Brasileiro de Componentes, Arquiteturas e Reutilização de Software (SBCARS), pages 67 80, [3] Christian Kästner, Sven Apel, and Martin Kuhlemann. Granularity in software product lines. In 30th International Conference on Software Engineering (ICSE), pages , [4] Jia Liu, Don Batory, and Christian Lengauer. Feature oriented refactoring of legacy applications. In 28th International Conference on Software Engineering (ICSE), pages , [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, [6] Marcelo Nassau and Marco Tulio Valente. Object-oriented transformations for extracting aspects. Information and Software Technology, 51(1): ,

92 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 Belém PA Brasil 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

93 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

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

Uma Análise da História do VEM, WBVS e WMSWM VEM Uma Análise da História do VEM, WBVS e WMSWM Renato Novais, Thiago S. Mendes, Fernando Teles Instituto Federal da Bahia (IFBA) Salvador Bahia Brasil {renato,thiagosouto,fernandoteles}@ifba.edu.br Abstract.

Leia mais

WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML

WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML Carlos Henrique Pereira WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML Florianópolis - SC 2007 / 2 Resumo O objetivo deste trabalho é especificar

Leia mais

Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum

Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum Diego R. Marins 1,2, José A. Rodrigues Nt. 1, Geraldo B. Xexéo 2, Jano M. de Sousa 1 1 Programa de Engenharia de Sistemas e Computação - COPPE/UFRJ 2 Departamento

Leia mais

Table 1. Dados do trabalho

Table 1. Dados do trabalho Título: Desenvolvimento de geradores de aplicação configuráveis por linguagens de padrões Aluno: Edison Kicho Shimabukuro Junior Orientador: Prof. Dr. Paulo Cesar Masiero Co-Orientadora: Prof a. Dr. Rosana

Leia mais

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS Lilian R. M. Paiva, Luciene C. Oliveira, Mariana D. Justino, Mateus S. Silva, Mylene L. Rodrigues Engenharia de Computação - Universidade de Uberaba (UNIUBE)

Leia mais

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS RESUMO Este artigo apresenta a especificação de um sistema gerenciador de workflow, o ExPSEE, de acordo com a abordagem de desenvolvimento baseado

Leia mais

Spider-PM: Uma Ferramenta de Apoio à Modelagem de Processos de Software

Spider-PM: Uma Ferramenta de Apoio à Modelagem de Processos de Software Spider-PM: Uma Ferramenta de Apoio à Modelagem de Processos de Software Renan Sales Barros 1, Sandro Ronaldo Bezerra Oliveira 1 1 Faculdade de Computação Instituto de Ciências Exatas e Naturais (ICEN)

Leia mais

Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum

Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum Audrey B. Vasconcelos, Iuri Santos Souza, Ivonei F. da Silva, Keldjan Alves Centro de Informática Universidade

Leia mais

Um processo para construção de software mais transparente

Um processo para construção de software mais transparente Um processo para construção de software mais transparente Eduardo Almentero 1, and Julio Cesar Sampaio do Prado Leite 1 1 Pontifícia Universidade Católica do Rio de Janeiro, PUC - Rio, Brasil {ealmentero,

Leia mais

Marcelo Novaes Coutinho. Um Processo de Gerência de Estratégia de Rastreabilidade: Um Caso em Ambiente Oracle. Dissertação de Mestrado

Marcelo Novaes Coutinho. Um Processo de Gerência de Estratégia de Rastreabilidade: Um Caso em Ambiente Oracle. Dissertação de Mestrado Marcelo Novaes Coutinho Um Processo de Gerência de Estratégia de Rastreabilidade: Um Caso em Ambiente Oracle Dissertação de Mestrado Dissertação apresentada como requisito parcial para obtenção do grau

Leia mais

VI Congresso Brasileiro de Software: Teoria e Prática

VI Congresso Brasileiro de Software: Teoria e Prática Carta de Apresentação VI Congresso Brasileiro de Software: Teoria e Prática 21 a 26 de Setembro de 2015 Belo Horizonte Minas Gerais Local: PUC-Minas - Campus Coração Eucarístico Realização Promoção Conteúdo

Leia mais

desenvolvimento de software em indústria, comunidades acadêmicas e científicas uma fábrica de software?... joa@ufrpe.br silvio@cesar.org.

desenvolvimento de software em indústria, comunidades acadêmicas e científicas uma fábrica de software?... joa@ufrpe.br silvio@cesar.org. desenvolvimento de software em indústria, comunidades acadêmicas e científicas uma fábrica de software?... joa@ufrpe.br silvio@cesar.org.br laboratórios de desenvolvimento... Produção de Software: histórico

Leia mais

Transforms: Um Ambiente de Apoio a Modelagem e Execução de Processos de Software Dirigido por Modelos

Transforms: Um Ambiente de Apoio a Modelagem e Execução de Processos de Software Dirigido por Modelos Transforms: Um Ambiente de Apoio a Modelagem e Execução de Processos de Software Dirigido por Modelos Bruno C. da Silva 1,2, Ana Patrícia F. Magalhães 2, Rita Suzana P. Maciel 3, Narciso Martins 2, Leandro

Leia mais

PROGRAMAÇÃO MVC E ZEND FRAMEWORK

PROGRAMAÇÃO MVC E ZEND FRAMEWORK PROGRAMAÇÃO MVC E ZEND FRAMEWORK MVC PROGRAMMING AND ZEND FRAMEWORK Rodolfo Vinícius Moimas Dias Centro Universitário Filadélfia de Londrina UniFil Rafael Francovig Cavicchioli Centro Universitário Filadélfia

Leia mais

Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow

Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow Itana M. S. Gimenes 1 itana@din.uem.br Fabrício R. Lazilha 2 fabricio@cesumar.br Edson A. O. Junior

Leia mais

Manual de Implementação de Processo do MPS.BR com Apoio Ferramental

Manual de Implementação de Processo do MPS.BR com Apoio Ferramental Manual de Implementação de Processo do MPS.BR com Apoio Ferramental Processo: Gerência de Requisitos Versão: 1.7 www.ufpa.br/spider Histórico de Revisões Data Versão Descrição Autor 1.0 Definição dos itens

Leia mais

3 Estudo de Ferramentas

3 Estudo de Ferramentas 3 Estudo de Ferramentas Existem diferentes abordagens para automatizar um processo de desenvolvimento. Um conjunto de ferramentas pode ser utilizado para aperfeiçoar o trabalho, mantendo os desenvolvedores

Leia mais

Andrew Diniz da Costa. Automação do Processo de Gerência do Teste de Software. Tese de Doutorado

Andrew Diniz da Costa. Automação do Processo de Gerência do Teste de Software. Tese de Doutorado Andrew Diniz da Costa Automação do Processo de Gerência do Teste de Software Tese de Doutorado Tese apresentada como requisito parcial para obtenção do grau de Doutor pelo Programa de Pós-graduação em

Leia mais

Instituto de Computação, Universidade Federal do Amazonas (UFAM) Manaus-AM, Brasil

Instituto de Computação, Universidade Federal do Amazonas (UFAM) Manaus-AM, Brasil Elicitação de Requisitos a partir de Modelos de Processos de Negócio e Modelos Organizacionais: Uma pesquisa para definição de técnicas baseadas em heurísticas Marcos A. B. de Oliveira 1, Sérgio R. C.

Leia mais

EXPSEE: UM AMBIENTE EXPERIMENTAL DE ENGENHARIA DE SOFTWARE ORIENTADO A PROCESSOS

EXPSEE: UM AMBIENTE EXPERIMENTAL DE ENGENHARIA DE SOFTWARE ORIENTADO A PROCESSOS EXPSEE: UM AMBIENTE EXPERIMENTAL DE ENGENHARIA DE SOFTWARE ORIENTADO A PROCESSOS Edson Alves de Oliveira Junior (1) Igor Fábio Steinmacher (2) eaojunio@bol.com.br ifsteinm@din.uem.br Edna Tomie Takano

Leia mais

INF 2125 PROJETO DE SISTEMAS DE SOFTWARE Prof. Carlos J. P. de Lucena

INF 2125 PROJETO DE SISTEMAS DE SOFTWARE Prof. Carlos J. P. de Lucena INF 2125 PROJETO DE SISTEMAS DE SOFTWARE Prof. Carlos J. P. de Lucena Trabalho Experimental Sistema de Biblioteca 1. Objetivo Este trabalho tem o objetivo de consolidar o conhecimento sobre UML e garantir

Leia mais

ENSINET/NAV: UMA FERRAMENTA PARA ESTRUTURAÇÃO DE CURSOS BASEADOS EM OBJETOS DE APRENDIZAGEM *

ENSINET/NAV: UMA FERRAMENTA PARA ESTRUTURAÇÃO DE CURSOS BASEADOS EM OBJETOS DE APRENDIZAGEM * ENSINET/NAV: UMA FERRAMENTA PARA ESTRUTURAÇÃO DE CURSOS BASEADOS EM OBJETOS DE APRENDIZAGEM * Diego Lemos de Souza ** Graçaliz Pereira Dimuro *** Antônio Carlos da Rocha Costa **** Raquel Mello de Miranda

Leia mais

REQUIREMENTS TRACEABILITY MATRIX: AUTOMATIC GENERATION AND VISUALIZATION

REQUIREMENTS TRACEABILITY MATRIX: AUTOMATIC GENERATION AND VISUALIZATION REQUIREMENTS TRACEABILITY MATRIX: AUTOMATIC GENERATION AND VISUALIZATION Seminário da disciplina Engenharia de Requisitos Aluno: Eliaquim Lima Sá Neto (elsn@cin.ufpe.br) Autores 2 Sandra Fabbri Professora

Leia mais

Requisitos de Ferramentas Especializadas de Gestão de Configuração de Software

Requisitos de Ferramentas Especializadas de Gestão de Configuração de Software Requisitos de Ferramentas Especializadas de Gestão de Configuração de Software Ricardo Terra 1 1 Departamento de Ciência da Computação Universidade Federal de Minas Gerais (UFMG) Campus da Pampulha 31.270-010

Leia mais

Se observarmos nos diferentes livros. Planejamento de Testes a partir de Casos de Uso

Se observarmos nos diferentes livros. Planejamento de Testes a partir de Casos de Uso Planejamento de Testes a partir de Casos de Uso Arilo Cláudio Dias Neto ariloclaudio@gmail.com É Bacharel em Ciência da Computação formado na Universidade Federal do Amazonas, Mestre em Engenharia de Sistemas

Leia mais

Desenvolvimento de uma Plataforma Gráfica para a Descrição de Modelos de Sistemas Ambientais

Desenvolvimento de uma Plataforma Gráfica para a Descrição de Modelos de Sistemas Ambientais Desenvolvimento de uma Plataforma Gráfica para a Descrição de Modelos de Sistemas Ambientais Tiago F. M. Lima 1,2, Tiago G. S. Carneiro 2, Sérgio D. Faria 3 1 Programa de Pós-Graduação em Análise e Modelagem

Leia mais

Uma Abordagem para a Avaliação de Processos de Desenvolvimento de Software Baseada em Risco e Conformidade

Uma Abordagem para a Avaliação de Processos de Desenvolvimento de Software Baseada em Risco e Conformidade Rafael de Souza Lima Espinha Uma Abordagem para a Avaliação de Processos de Desenvolvimento de Software Baseada em Risco e Conformidade Dissertação de Mestrado Dissertação apresentada como requisito parcial

Leia mais

Uma Implementação do Processo de Garantia da Qualidade usando a Spider-QA, a Spider-CL e o Mantis

Uma Implementação do Processo de Garantia da Qualidade usando a Spider-QA, a Spider-CL e o Mantis Uma Implementação do Processo de Garantia da Qualidade usando a Spider-QA, a Spider-CL e o Mantis Rodrigo Araujo Barbalho 1, Marília Paulo Teles 2, Sandro Ronaldo Bezerra Oliveira 1,2 1 Faculdade de Computação

Leia mais

Geração automática de suíte de teste para GUI a partir de Rede de Petri

Geração automática de suíte de teste para GUI a partir de Rede de Petri Raquel Jauffret Guilhon Geração automática de suíte de teste para GUI a partir de Rede de Petri Dissertação de Mestrado Dissertação apresentada como requisito parcial para obtenção do grau de Mestre pelo

Leia mais

Geração do Portal CPCX - UFMS pelo UNION: Um Estudo de Caso

Geração do Portal CPCX - UFMS pelo UNION: Um Estudo de Caso Geração do Portal CPCX - UFMS pelo UNION: Um Estudo de Caso Lourival dos Santos Pires Júnior, Tony Carlos Bignardi dos Santos, Amaury Antônio de Castro Junior, Carlos Alberto da Silva, Leila Lisiane Rossi

Leia mais

JAVA ON ROAD: Um Framework para Desenvolvimento WEB

JAVA ON ROAD: Um Framework para Desenvolvimento WEB Revista Rios Eletrônica - Revista Científica da Fasete ano 2 n. 2 dezembro de 2008 JAVA ON ROAD: Um Framework para Desenvolvimento WEB Professor da Faculdade Sete de Setembro (FASETE), Doutorando em Ciência

Leia mais

Uma Abordagem para Condução de Iniciativas de Melhoria de Processos de Software

Uma Abordagem para Condução de Iniciativas de Melhoria de Processos de Software Uma Abordagem para Condução de Iniciativas de Melhoria de Processos de Software Mariano Montoni, Cristina Cerdeiral, David Zanetti, Ana Regina Rocha COPPE/UFRJ - Universidade Federal do Rio de Janeiro

Leia mais

Uma proposta de um processo prático para apoiar o reuso de software

Uma proposta de um processo prático para apoiar o reuso de software Uma proposta de um processo prático para apoiar o reuso de software Rosangela Kronig (UNIP) rkronig.mes.engprod@unip.br Ivanir Costa (UNIP) icosta@unip.br Mauro Spínola (UNIP) mspinola@unip.br Resumo A

Leia mais

UNIVERSIDADE DE SÃO PAULO FACULDADE DE EDUCAÇÃO JOÃO FÁBIO PORTO. Diálogo e interatividade em videoaulas de matemática

UNIVERSIDADE DE SÃO PAULO FACULDADE DE EDUCAÇÃO JOÃO FÁBIO PORTO. Diálogo e interatividade em videoaulas de matemática UNIVERSIDADE DE SÃO PAULO FACULDADE DE EDUCAÇÃO JOÃO FÁBIO PORTO Diálogo e interatividade em videoaulas de matemática São Paulo 2010 JOÃO FÁBIO PORTO Diálogo e interatividade em videoaulas de matemática

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

Uma Integração entre Ferramentas de Gerência de Projetos Utilizando XML

Uma Integração entre Ferramentas de Gerência de Projetos Utilizando XML Uma Integração entre Ferramentas de Gerência de Projetos Utilizando XML Edson Leandro de Araújo Silva 2, Adailton Magalhães Lima 1,2, Ernani de Oliveira Sales 1, Anderson Jorge Serra da Costa 2 1 Laboratório

Leia mais

Transformação de um Modelo de Empresa em Requisitos de Software

Transformação de um Modelo de Empresa em Requisitos de Software Transformação de um Modelo de Empresa em Requisitos de Software Fábio Levy Siqueira 1 and Paulo Sérgio Muniz Silva 2 1 Programa de Educação Continuada da Poli-USP, São Paulo, Brazil 2 Escola Politécnica

Leia mais

Ferramentas Gratuitas para Gerência de Requisitos

Ferramentas Gratuitas para Gerência de Requisitos Ferramentas Gratuitas para Gerência de Requisitos Aline Antunes Dias, graduanda em Sistemas de Informação UFLA. aline_antunes@bsi.ufla.br Abstract The increase of economic activities over the years created

Leia mais

Especificação de um Sistema Gerenciador de Workflow de Acordo com a Abordagem de Desenvolvimento Baseado em Componentes

Especificação de um Sistema Gerenciador de Workflow de Acordo com a Abordagem de Desenvolvimento Baseado em Componentes Especificação de um Sistema Gerenciador de Workflow de Acordo com a Abordagem de Desenvolvimento Baseado em Componentes Edson Alves de Oliveira Junior 1, Itana Maria de Souza Gimenes 1 1 Departamento de

Leia mais

Avaliação de Modelos i* com o Processo AIRDoc-i*

Avaliação de Modelos i* com o Processo AIRDoc-i* Avaliação de Modelos i* com o Processo AIRDoc-i* Cleice Souza 1, Cláudia Souza 1, Fernanda Alencar 2, Jaelson Castro 1, Paulo Cavalcanti 1, Monique Soares 1, Gabriela Guedes 1, Eduardo Figueiredo 3 1 Centro

Leia mais

Conformação Arquitetural. com DCLcheck. Defina as dependências aceitáveis e inaceitáveis de acordo com a arquitetura planejada de seu sistema

Conformação Arquitetural. com DCLcheck. Defina as dependências aceitáveis e inaceitáveis de acordo com a arquitetura planejada de seu sistema dclcheck_ Conformação Arquitetural com DCLcheck Defina as dependências aceitáveis e inaceitáveis de acordo com a arquitetura planejada de seu sistema Arquitetura de software é geralmente definida como

Leia mais

Verificação e Validação de Requisitos

Verificação e Validação de Requisitos Verificação e Validação de Requisitos Verificação e Validação dos Requisitos Casos de Uso e Esp. Suplementar Plano e Casos de Teste Requisitos p/ Inspeção Verificar conflitos de requisitos Verificar consistência

Leia mais

Reuso de Software. Caixa Postal 10.011 CEP 86057-970 Londrina PR Brasil. cezbastos@gmail.com, jgpalma@uel.br

Reuso de Software. Caixa Postal 10.011 CEP 86057-970 Londrina PR Brasil. cezbastos@gmail.com, jgpalma@uel.br Reuso de Software Cezar Bastos Filho 1, Jandira Guenka Palma 1 1 Departamento de Computação Universidade Estadual de Londrina (UEL) Caixa Postal 10.011 CEP 86057-970 Londrina PR Brasil cezbastos@gmail.com,

Leia mais

CASE Orientada a Objetos com Múltiplas Visões e Implementação Automática de Sistemas - MVCASE

CASE Orientada a Objetos com Múltiplas Visões e Implementação Automática de Sistemas - MVCASE CASE Orientada a Objetos com Múltiplas Visões e Implementação Automática de Sistemas - MVCASE Tathiana da Silva Barrére Antonio Francisco do Prado Vitor César Bonafe E-mail: (tathiana,prado,bonafe)@dc.ufscar.br

Leia mais

Engenharia Reversa para Recuperação de Modelos de Sistemas Desenvolvidos em PL/SQL

Engenharia Reversa para Recuperação de Modelos de Sistemas Desenvolvidos em PL/SQL Engenharia Reversa para Recuperação de Modelos de Sistemas Desenvolvidos em PL/SQL Rodnei Couto 1, Luana Lachtermacher 1, Soeli Fiorini 1, Akeo Tanabe 1, Gustavo Carvalho 1, Arndt von Staa 1, Ricardo Choren

Leia mais

Odyssey-WI: Uma Ferramenta para Mineração de Rastros de Modificação em Modelos UML Versionados

Odyssey-WI: Uma Ferramenta para Mineração de Rastros de Modificação em Modelos UML Versionados Odyssey-WI: Uma Ferramenta para Mineração de Rastros de Modificação em Modelos UML Versionados Cristine Dantas, Leonardo Murta, Cláudia Werner COPPE/UFRJ Programa de Engenharia de Sistemas e Computação

Leia mais

Requisitos para ferramentas de registro de defeitos de software

Requisitos para ferramentas de registro de defeitos de software Requisitos para ferramentas de registro de defeitos de software Alessandro Liebmam Departamento de Ciência da Computação Instituto de Ciências Exatas Universidade Federal de Minas Gerais (UFMG) CEP: 31270-010

Leia mais

Requisitos de Ferramentas de Gestão de Projetos de Desenvolvimento de Software

Requisitos de Ferramentas de Gestão de Projetos de Desenvolvimento de Software Requisitos de Ferramentas de Gestão de Projetos de Desenvolvimento de Software Keyla Guimarães Macharet Brasil 1 1 Departamento de Ciência da Computação Universidade Federal de Minas Gerais (UFMG) CEP

Leia mais

MODELAGEM VISUAL DE UM SOFTWARE PARA O GERENCIAMENTO DAS COMUNICAÇÕES EM GESTÃO DE PROJETOS

MODELAGEM VISUAL DE UM SOFTWARE PARA O GERENCIAMENTO DAS COMUNICAÇÕES EM GESTÃO DE PROJETOS 127 MODELAGEM VISUAL DE UM SOFTWARE PARA O GERENCIAMENTO DAS COMUNICAÇÕES EM GESTÃO DE PROJETOS VISUAL MODELING OF SOFTWARE FOR COMMUNICATION MANAGEMENT IN PROJECT MANAGEMENT Ricardo Rall 1 Arilson José

Leia mais

Um Framework de Engenharia de Requisitos para Desenvolvimento de Produtos de Software

Um Framework de Engenharia de Requisitos para Desenvolvimento de Produtos de Software Um Framework de Engenharia de Requisitos para Desenvolvimento de Produtos de Software Carina Alves Centro de Informática Universidade Federal de Pernambuco (UFPE) Caixa Postal 50732-970 Recife PE Brazil

Leia mais

1. Introdução. João Victor Cunha Oliveira Gomes 1, Bruno Souto Borges 1. CEP 75500-000 Itumbiara GO Brasil

1. Introdução. João Victor Cunha Oliveira Gomes 1, Bruno Souto Borges 1. CEP 75500-000 Itumbiara GO Brasil 88 Estudo de Caso Aplicado na Gestão da Cadeia de Suprimentos de uma Indústria de Cereais Matinais Modelagem e Desenvolvimento de um Sistema de Informação para a Gestão da Cadeia de Suprimentos João Victor

Leia mais

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Evandro Polese Alves Ricardo de Almeida Falbo Departamento de Informática - UFES Av. Fernando Ferrari, s/n, Vitória - ES - Brasil

Leia mais

Software product lines. Paulo Borba Informatics Center Federal University of Pernambuco

Software product lines. Paulo Borba Informatics Center Federal University of Pernambuco Software product lines Paulo Borba Informatics Center Federal University of Pernambuco Software product lines basic concepts Paulo Borba Informatics Center Federal University of Pernambuco Um produto www.usm.maine.edu

Leia mais

Tese / Thesis Work Análise de desempenho de sistemas distribuídos de grande porte na plataforma Java

Tese / Thesis Work Análise de desempenho de sistemas distribuídos de grande porte na plataforma Java Licenciatura em Engenharia Informática Degree in Computer Science Engineering Análise de desempenho de sistemas distribuídos de grande porte na plataforma Java Performance analysis of large distributed

Leia mais

Uma arquitetura baseada em agentes de software para a automação de processos de gerênciadefalhasemredesde telecomunicações

Uma arquitetura baseada em agentes de software para a automação de processos de gerênciadefalhasemredesde telecomunicações Adolfo Guilherme Silva Correia Uma arquitetura baseada em agentes de software para a automação de processos de gerênciadefalhasemredesde telecomunicações Dissertação de Mestrado Dissertação apresentada

Leia mais

Requisitos de Ferramentas de Apoio aos Processos de Medição de Software. Marco Aurélio Vilaça de Melo

Requisitos de Ferramentas de Apoio aos Processos de Medição de Software. Marco Aurélio Vilaça de Melo Requisitos de Ferramentas de Apoio aos Processos de Medição de Software Marco Aurélio Vilaça de Melo Departamento de Ciência da Computação Universidade Federal de Minas Gerais (UFMG) Belo Horizonte MG

Leia mais

Reuso. Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior

Reuso. Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Reuso Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Reutilização de Software Na maioria das áreas de engenharia de software, sistemas são desenvolvidos

Leia mais

I Workhop Brasileiro de Tecnologias para Colaboração WCSCW

I Workhop Brasileiro de Tecnologias para Colaboração WCSCW I Workhop Brasileiro de Tecnologias para Colaboração WCSCW Realização: 13 e 14 de outubro em conjunto com o WebMídia-LA Web 2004 Ribeirão Preto - SP Organização do Workshop: Alberto Raposo PUC-Rio Flávia

Leia mais

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA CAMPUS AVANÇADO DE ARACATI PROJETO DE PESQUISA

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA CAMPUS AVANÇADO DE ARACATI PROJETO DE PESQUISA INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA CAMPUS AVANÇADO DE ARACATI PROJETO DE PESQUISA IMPLEMENTAÇÃO DE SOLUÇÃO PARA AUTOMATIZAR O DESENVOLVIMENTO DE SOFTWARE UTILIZANDO A LINGUAGEM C#.NET

Leia mais

Accessing the contents of the Moodle Acessando o conteúdo do Moodle

Accessing the contents of the Moodle Acessando o conteúdo do Moodle Accessing the contents of the Moodle Acessando o conteúdo do Moodle So that all the available files in the Moodle can be opened without problems, we recommend some software that will have to be installed

Leia mais

FAPS: Ferramenta para apoiar Avaliações Integradas de Processos de Software

FAPS: Ferramenta para apoiar Avaliações Integradas de Processos de Software FAPS: Ferramenta para apoiar Avaliações Integradas de Processos de Software Marcello Thiry 1 2, Christiane Gresse von Wangenheim 1 2, Alessandra Zoucas 12, Leonardo Reis Tristão 1 1 (II-MPS.BR) Incremental

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Requisitos de Software Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br Requisito O que é um REQUISITO? Em software: É a CARACTERIZAÇÃO do que o

Leia mais

Essencial ao Desenvolvimento de Software

Essencial ao Desenvolvimento de Software Documento de Requisitos Essencial ao Desenvolvimento de Software De que se trata o artigo? Apresenta o documento de requisitos de software, destacando-o como um dos principais documentos pertinentes ao

Leia mais

Indicações de Abordagens para Rastreabilidade de Requisitos no contexto do MR-MPS-SW por meio de uma Revisão Sistemática da Literatura

Indicações de Abordagens para Rastreabilidade de Requisitos no contexto do MR-MPS-SW por meio de uma Revisão Sistemática da Literatura X Workshop Anual do MPS (WAMPS 2014) Indicações de Abordagens para Rastreabilidade de Requisitos no contexto do MR-MPS-SW por meio de uma Revisão Sistemática da Literatura Apresentador: Paulo Malcher Autores:

Leia mais

Projeto SIAC 2.0: Uma aplicação do framework Demoiselle para o desenvolvimento de Sistema de Informações Acadêmicas da UFBA (SIAC)

Projeto SIAC 2.0: Uma aplicação do framework Demoiselle para o desenvolvimento de Sistema de Informações Acadêmicas da UFBA (SIAC) Projeto SIAC 2.0: Uma aplicação do framework Demoiselle para o desenvolvimento de Sistema de Informações Acadêmicas da UFBA (SIAC) André Luís Monteiro P. dos Santos 1, Fernando Cezar Borges 1, Leandro

Leia mais

Uma Abordagem de Engenharia de Requisitos Para Linhas de Produtos de Software

Uma Abordagem de Engenharia de Requisitos Para Linhas de Produtos de Software Uma Abordagem de Engenharia de Requisitos Para Linhas de Produtos de Software Gabriela Guedes de Souza, Jaelson Castro e Carla Silva ggs@cin.ufpe.br, jbc@cin.ufpe.br, carla@dce.ufpb.br DEPARTAMENTO DE

Leia mais

Usando Modelos Para Apoiar a Especificação e Verificação de Requisitos de Ubiquidade

Usando Modelos Para Apoiar a Especificação e Verificação de Requisitos de Ubiquidade Usando Modelos Para Apoiar a Especificação e Verificação de Requisitos de Ubiquidade Leonardo Mota, Jobson Massollar, Guilherme Horta Travassos Federal University of Rio de Janeiro/COPPE/PESC Caixa Postal

Leia mais

Especificação de Uma Abordagem para Desenvolvimento Distribuído de Software Utilizando SPEM

Especificação de Uma Abordagem para Desenvolvimento Distribuído de Software Utilizando SPEM Especificação de Uma Abordagem para Desenvolvimento Distribuído de Software Utilizando SPEM Gislaine Camila Lapasini Leal, Elisa Hatsue Moriya Huzita Tania Fatima Calvi Tait e César Alberto da Silva Universidade

Leia mais

DISSERTAÇÃO DE MESTRADO

DISSERTAÇÃO DE MESTRADO Otavio Rezende da Silva Uma Arquitetura para Sistemas Multi- Agentes Baseada em Espaços de Tuplas Reflexivos DISSERTAÇÃO DE MESTRADO Programa de Pós-Graduação em Informática Rio de Janeiro, dezembro de

Leia mais

Um Sistema Web para apoio ao Gerenciamento de atividades de Teste de Software em Pequenas Empresas

Um Sistema Web para apoio ao Gerenciamento de atividades de Teste de Software em Pequenas Empresas Um Sistema Web para apoio ao Gerenciamento de atividades de Teste de Software em Pequenas Empresas Luciano Gomes Helvinger, Rodrigo Prestes Machado Curso de Análise e Desenvolvimento de Sistemas Faculdade

Leia mais

Documentação do Sistema de Reserva de Salas da Intranet do ICMC-USP

Documentação do Sistema de Reserva de Salas da Intranet do ICMC-USP UNIVERSIDADE DE SÃO PAULO Instituto de Ciências Matemáticas e de Computação Departamento de Ciências da Computação e Estatística Documentação do Sistema de Reserva de Salas da Intranet do ICMC-USP André

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO Santa Maria, 10 de Outubro de 2013. Revisão aula anterior Documento de Requisitos Estrutura Padrões Template Descoberta

Leia mais

e-vent-br: Proposta de um Sistema Web de Gerenciamento de Eventos Acadêmicos

e-vent-br: Proposta de um Sistema Web de Gerenciamento de Eventos Acadêmicos e-vent-br: Proposta de um Sistema Web de Gerenciamento de Eventos Acadêmicos Luis Paulo da Silva Carvalho, Moara Sousa Brito, Pablo Freire Matos, Lucas Amparo Barbosa, Cremildo Lima Gomes, Ivick Roberta

Leia mais

Metodologia para Planejamento, Execução e Controle de Teste de Software. Roteiro

Metodologia para Planejamento, Execução e Controle de Teste de Software. Roteiro Metodologia para Planejamento, Execução e Controle de Teste de Software Arilo Claudio Dias Neto - acdn@cos.ufrj.br Gladys Machado P. S. Lima - gladysmp@cos.ufrj.br Guilherme Horta Travassos - ght@cos.ufrj.br

Leia mais

Uma Implementação do Processo de Medição usando a Spider-MPlan

Uma Implementação do Processo de Medição usando a Spider-MPlan Uma Implementação do Processo de Medição usando a Spider-MPlan Simone Nayara Costa Carneiro 1, Sandro Ronaldo Bezerra Oliveira 1 1 Faculdade de Computação Instituto de Ciências Exatas e Naturais Universidade

Leia mais

Em Busca de uma Arquitetura de Referência para Frameworks de Aplicação Dirigidos por Modelos para Sistemas de Informação

Em Busca de uma Arquitetura de Referência para Frameworks de Aplicação Dirigidos por Modelos para Sistemas de Informação Em Busca de uma Arquitetura de Referência para Frameworks de Aplicação Dirigidos por Modelos para Sistemas de Informação Valdemar Vicente GRACIANO NETO 1 ; Juliano Lopes DE OLIVEIRA 1 1 Instituto de Informática

Leia mais

Engenharia de Software Aplicada ao Projeto, Desenvolvimento e Manutenção de Sistemas para Gestão de Comunidades e de Conteúdos Educacionais na Web

Engenharia de Software Aplicada ao Projeto, Desenvolvimento e Manutenção de Sistemas para Gestão de Comunidades e de Conteúdos Educacionais na Web Engenharia de Software Aplicada ao Projeto, Desenvolvimento e Manutenção de Sistemas para Gestão de Comunidades e de Conteúdos Educacionais na Web Cláudia Maria Lima Werner, Rodrigo Pereira dos Santos,

Leia mais

Relato de experiência da implantação de boas práticas de Engenharia de Software em um ambiente heterogêneo

Relato de experiência da implantação de boas práticas de Engenharia de Software em um ambiente heterogêneo Kelly Azevedo Borges Leal Relato de experiência da implantação de boas práticas de Engenharia de Software em um ambiente heterogêneo Dissertação de Mestrado Dissertação apresentada ao Programa de Pós-

Leia mais

INTEGRANDO MÉTRICA DE SOFTWARES AO GERENCIAMENTO DE PROJETOS

INTEGRANDO MÉTRICA DE SOFTWARES AO GERENCIAMENTO DE PROJETOS I Congresso Brasileiro de Computação CBComp 2001 109 INTEGRANDO MÉTRICA DE SOFTWARES AO GERENCIAMENTO DE PROJETOS Fabiane Barreto Vavassori 1,2 Everton Wilson de Souza 1 Julio César Fiamoncini 1 fabiane@inf.univali.br

Leia mais

Integrando Requisitos Ágeis com Modelos i*

Integrando Requisitos Ágeis com Modelos i* Integrando Requisitos Ágeis com Modelos i* Aline Jaqueira, Bernardo Gurgel, Márcia Lucena Departamento de Informática e Matemática Aplicada UFRN alinejaqueira@ppgsc.ufrn.br, bernardogfilho@gmail.com, marciaj@dimap.ufrn.br

Leia mais

Ambiente de workflow para controle de métricas no processo de desenvolvimento de software

Ambiente de workflow para controle de métricas no processo de desenvolvimento de software Ambiente de workflow para controle de métricas no processo de desenvolvimento de software Gustavo Zanini Kantorski, Marcelo Lopes Kroth Universidade Federal de Santa Maria (UFSM) 97100-000 Santa Maria

Leia mais

Definição de Processos de Workflow

Definição de Processos de Workflow Definição de Processos de Tiago Telecken Universidade Federal do Rio Grande do Sul telecken@inf.ufrgs.br Resumo Este artigo apresenta uma introdução a tecnologia de workflow informando noções básicas sobre

Leia mais

Monitoramento de Métricas de Segurança da Informação

Monitoramento de Métricas de Segurança da Informação Monitoramento de Métricas de Segurança da Informação Rafael Seidi Shigueoka¹, Bruno Bogaz Zarpelão¹ 1 Departamento de Computação Universidade Estadual de Londrina (UEL) Caixa Postal 10.011 CEP 86057-970

Leia mais

LockED: Uma Ferramenta para o Controle de Alterações no Desenvolvimento Distribuído de Artefatos de Software

LockED: Uma Ferramenta para o Controle de Alterações no Desenvolvimento Distribuído de Artefatos de Software LockED: Uma Ferramenta para o Controle de Alterações no Desenvolvimento Distribuído de Artefatos de Software Hugo Vidal Teixeira Leonardo Gresta Paulino Murta Cláudia Maria Lima Werner {hvidal, murta,

Leia mais

WXDC: Uma Ferramenta para Imposição e Validação de Restrições de Integridade baseadas na Linguagem XDCL

WXDC: Uma Ferramenta para Imposição e Validação de Restrições de Integridade baseadas na Linguagem XDCL 232 - Encontro Anual de Tecnologia da Informação WXDC: Uma Ferramenta para Imposição e Validação de Restrições de Integridade baseadas na Linguagem XDCL Stevan D. Costa1, Alexandre T. Lazzaretti1, Anubis

Leia mais

Criando Aplicações PHP com. Zend e Dojo. Flávio Gomes da Silva Lisboa. Novatec

Criando Aplicações PHP com. Zend e Dojo. Flávio Gomes da Silva Lisboa. Novatec Criando Aplicações PHP com Zend e Dojo Flávio Gomes da Silva Lisboa Novatec Copyright 2013 da Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a

Leia mais

UM PROTÓTIPO DO SISTEMA PARA CONTROLE DE BIBLIOTECAS POR MEIO DE PÁGINAS WEB DINÂMICAS 1

UM PROTÓTIPO DO SISTEMA PARA CONTROLE DE BIBLIOTECAS POR MEIO DE PÁGINAS WEB DINÂMICAS 1 UM PROTÓTIPO DO SISTEMA PARA CONTROLE DE BIBLIOTECAS POR MEIO DE PÁGINAS WEB DINÂMICAS 1 Daniel de Faveri HONORATO 2, Renato Bobsin MACHADO 3, Huei Diana LEE 4, Feng Chung WU 5 Escrito para apresentação

Leia mais

Assembléia da Comissão Especial de Arquitetura de. Computadores e Processamento de Alto Desempenho da SBC

Assembléia da Comissão Especial de Arquitetura de. Computadores e Processamento de Alto Desempenho da SBC Assembléia da Comissão Especial de Arquitetura de Computadores e Processamento de Alto Desempenho da SBC Data: 29/10/2010 Horário início: 19:12 h Local de realização: SBAC-PAD 2011, Petrópolis, RJ, Brasil

Leia mais

O GERENCIAMENTO DE REQUISITOS E A SUA IMPORTÂNCIA EM PROJETOS DE DESENVOLVIMENTO DE SOFTWARE

O GERENCIAMENTO DE REQUISITOS E A SUA IMPORTÂNCIA EM PROJETOS DE DESENVOLVIMENTO DE SOFTWARE O GERENCIAMENTO DE REQUISITOS E A SUA IMPORTÂNCIA EM PROJETOS DE DESENVOLVIMENTO DE SOFTWARE Leonardo Manoel Mendes¹, Rogério Homem da Costa², Reinaldo Lorenso³ 1. Especializando do Curso de Pós-Graduação

Leia mais

PROGRAMA NACIONAL DE COOPERAÇÃO ACADÊMICA-PROCAD NOVAS FRONTEIRAS EDITAL PROCAD NF 21/2009 FORMULÁRIO DE INSCRIÇÃO DE PROJETO

PROGRAMA NACIONAL DE COOPERAÇÃO ACADÊMICA-PROCAD NOVAS FRONTEIRAS EDITAL PROCAD NF 21/2009 FORMULÁRIO DE INSCRIÇÃO DE PROJETO 1/20 FUNDAÇÃO CAPES DIRETORIA DE PROGRAMAS E BOLSAS NO PAÍS COORDENAÇÃO GERAL DE PROGRAMAS ESTRATÉGICOS/CGPE COORDENAÇÃO DE PROGRAMAS ESPECIAIS/CPE PROGRAMA NACIONAL DE COOPERAÇÃO ACADÊMICA-PROCAD NOVAS

Leia mais

Partial View: Um padrão para reutilização de views na arquitetura MVC

Partial View: Um padrão para reutilização de views na arquitetura MVC Partial View: Um padrão para reutilização de views na arquitetura MVC RICARDO VIANA, Universidade Federal do Ceará THALISSON OLIVEIRA, Universidade Federal do Ceará FERNANDO TRINTA, Universidade Federal

Leia mais

Gerenciamento de Requisitos em Scrum baseado em Test Driven Development

Gerenciamento de Requisitos em Scrum baseado em Test Driven Development Gerenciamento de Requisitos em Scrum baseado em Test Driven Development Rafael Soares 1, Thiago Cabral 1, Fernanda Alencar 1,2 1 Programa de Pós Graduação em Engenharia da Computação, Universidade de Pernambuco,

Leia mais

Introdução à Plataforma Eclipse. Leandro Daflon daflon@les.inf.puc-rio.br

Introdução à Plataforma Eclipse. Leandro Daflon daflon@les.inf.puc-rio.br Introdução à Plataforma Eclipse Leandro Daflon daflon@les.inf.puc-rio.br Agenda Introdução Arquitetura da Plataforma Componentes da Plataforma JDT PDE Visão Geral do Projeto Eclipse.org 2 Introdução O

Leia mais

Modelagem Flexível para Processos de Negócio. Resultados de um Estudo Experimental

Modelagem Flexível para Processos de Negócio. Resultados de um Estudo Experimental Modelagem Flexível para Processos de Negócio Resultados de um Estudo Experimental Fabiane Albino Aluna Mestrado Prof. Ricardo Massa Orientador Cenário Atual Modelagem de Processos de Negócio de maneira

Leia mais

A Cloud Computing Architecture for Large Scale Video Data Processing

A Cloud Computing Architecture for Large Scale Video Data Processing Marcello de Lima Azambuja A Cloud Computing Architecture for Large Scale Video Data Processing Dissertação de Mestrado Dissertation presented to the Postgraduate Program in Informatics of the Departamento

Leia mais

CURRICULUM - VITAE FERNANDO WAGNER SERPA VIEIRA DA SILVA

CURRICULUM - VITAE FERNANDO WAGNER SERPA VIEIRA DA SILVA CURRICULUM - VITAE FERNANDO WAGNER SERPA VIEIRA DA SILVA DADOS PESSOAIS Fernando Wagner Serpa Vieira da Silva Nascimento: 1 de novembro de 1972 Filiação: Luiz Fernando Coda Vieira da Silva e Leila Maria

Leia mais

AVALIAÇÃO DE INTERFACES DE FERRAMENTAS CASE PARA ELABORAÇÃO DE DIAGRAMAS DA UML RESUMO

AVALIAÇÃO DE INTERFACES DE FERRAMENTAS CASE PARA ELABORAÇÃO DE DIAGRAMAS DA UML RESUMO AVALIAÇÃO DE INTERFACES DE FERRAMENTAS CASE PARA ELABORAÇÃO DE DIAGRAMAS DA UML Fábio Junior Alves Ernani Vinícius Damasceno Leandro Pinheiro Bevenuto RESUMO Um dos benefícios oferecidos pelas ferramentas

Leia mais

Palavras-chave: Biotério. Software livre. BioterC. 1 INTRODUÇÃO. Situação atual do gerenciamento dos biotérios brasileiros

Palavras-chave: Biotério. Software livre. BioterC. 1 INTRODUÇÃO. Situação atual do gerenciamento dos biotérios brasileiros BREVE COMUNICAÇÃO ISSN 2238-1589 DESENVOLVIMENTO E IMPLEMENTAÇÃO DE UM SOFTWARE LIVRE PARA O GERENCIAMENTO DE UM BIOTÉRIO BRASILEIRO Giovanny Augusto Camacho Antevere Mazzarotto 1,2 Guilherme Ferreira

Leia mais

Uma abordagem para gerência de requisitos integrada com práticas ágeis de gerência de projetos

Uma abordagem para gerência de requisitos integrada com práticas ágeis de gerência de projetos Uma abordagem para gerência de requisitos integrada com práticas ágeis de gerência de projetos Rudiney Altair Franceschi 1, Ana Marcia Debiasi Duarte 2 1 SGI Sistemas Ltda 2 Universidade do Oeste de Santa

Leia mais

Rafael Jessen Werneck de Almeida Martins. Recomendação de pessoas em redes sociais com base em conexões entre usuários

Rafael Jessen Werneck de Almeida Martins. Recomendação de pessoas em redes sociais com base em conexões entre usuários Rafael Jessen Werneck de Almeida Martins Recomendação de pessoas em redes sociais com base em conexões entre usuários Dissertação de Mestrado Dissertação apresentada como requisito parcial para a obtenção

Leia mais