XVIII SIMPÓSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE XI SESSÃO DE FERRAMENTAS

Transcrição

1 XVIII SIMPÓSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE XI SESSÃO DE FERRAMENTAS 21 a 22 de Outubro de 2003 Brasília Distrito Federal Brasil Promoção SBC Sociedade Brasileira de Computação Comissão Especial de Engenharia de Software ACM Association for Computing Machinery SIGSOFT Special Interest Group on Software Engineering Edição Rodrigo Quites Reis (Universidade Federal do Pará - UFPA) Organização Universidade de Brasília Realização Universidade de Brasília Departamento de Informática - Universidade Federal do Pará i

2 CIP CATALOGAÇÃO NA PUBLICAÇÃO Sessão de Ferramentas do Simpósio Brasileiro de Engenharia de Software (18.:2004 out : Brasília). Anais/Edição Rodrigo Quites Reis Belém: Departamento de Informática da Universidade Federal do Pará, p.: il. ISBN Conhecido também como Sessão de Ferramentas SBES Engenharia de Software. I. Reis, Rodrigo Quites. II. SBES (18.: 2004: Brasília). Esta obra foi impressa a partir de originais entregues, já compostos pelos autores Capa: Fernando Ribeiro Editoração: Diogo Rispoli, Hugo Lousa, Wantuil Firmiano Jr. ii

3 18th BRAZILIAN SYMPOSIUM ON SOFTWARE ENGINEERING 11th TOOLS SESSION October, 21-22, 2004 Brasília - DF, Brazil Promotion Editor SBC Brazilian Computing Society Special Committee on Software Engineering ACM Association for Computing Machinery SIGSOFT Special Interest Group on Software Engineering Rodrigo Quites Reis (UFPA - Universidade Federal do Pará) Organization Universidade de Brasília Realization Universidade de Brasília Departamento de Informática - Universidade Federal do Pará iii

4 APRESENTAÇÃO A Sessão de Ferramentas é um dos mais tradicionais eventos integrantes do Simpósio Brasileiro de Engenharia de Software (SBES), promovido anualmente pela Comissão Especial de Engenharia de Software da SBC - Sociedade Brasileira de Computação. O principal objetivo da Sessão é permitir a disseminação de ferramentas que apóiem as mais diversas atividades do processo de Engenharia de Software. Em sua 11 a edição, a Sessão de Ferramentas 2004 inclui a apresentação e demonstração prática de 15 ferramentas selecionadas pelo Comitê de Programa, de um total de 35 ferramentas submetidas. Cada ferramenta foi avaliada por três examinadores e, após a divulgação dos trabalhos aceitos, uma nova revisão foi realizada para verificar o atendimento das questões levantadas pelos examinadores no início do processo. Portanto, é com satisfação que registramos aqui artigos técnicos de indiscutível qualidade com a esperança de ampliar conhecimentos dos participantes e que, a partir destes conhecimentos, novos trabalhos venham a surgir. A coordenação da Sessão de Ferramentas do SBES 2004 foi facilitada pelo comprometimento do Comitê de Programa, formado por pesquisadores e professores da área que atuam em reconhecidas instituições do Brasil e exterior. A organização da Sessão de Ferramentas 2004 contou ainda com a dedicação e o apoio do Departamento de Informática da Universidade Federal do Pará. Gostaria de agradecer a todos que contribuíram para a Sessão de Ferramentas de Em especial, agradeço o apoio do coordenador do SBES 2004, Jaelson Freire Brelaz de Castro, e do coordenador geral do SBES-SBBD 2004, Murilo S. de Camargo. Por fim, agradeço todo o apoio dado pelo coordenador da Sessão de Ferramentas do ano passado, Nabor das Chagas Mendonça. Brasília (DF), outubro de Rodrigo Quites Reis Coordenador da Sessão de Ferramentas 2004 iv

5 XVIII Simpósio Brasileiro de Engenharia de Software 18th Brazilian Symposium on Software Engineering Coordenador do Comitê de Programa Program Committee Chair Jaelson Freire Brelaz de Castro (UFPE) Comitê Diretivo Steering Committee Arndt von Staa (PUC-Rio) Leila Ribeiro (UFRGS) Jaelson Castro (UFPE) Claudia Maria Lima Werner (COPPE-UFRJ) Coordenador do Comitê de Organização Organizing Committee Chair Murilo S. de Camargo (UnB) Membros do Comitê de Programa Programa Committee Members Alexandre Vasconcelos, CIn-UFPE/BR Ana Cavalcanti, University of Kent at Canterbury/UK Ana Cristina Vieira de Melo, IME-USP/BR Ana Moreira, Universidade Nova de Lisboa/PT Ana Regina C. da Rocha, COPPE-UFRJ/BR Anamaria Martins Moreira, DIMAP-UFRN/BR Andrea Zisman, City University/UK Antônio Francisco do Prado, DC-UFSCar/BR Arnaldo Dias Belchior, UNIFOR/BR Arnaldo V. Moura, IC-UNICAMP/BR Arndt von Staa, PUC-Rio/BR Augusto Sampaio, CIn-UFPE/BR Cecilia Mary Fischer Rubira, IC-UNICAMP/BR Claudia Maria Lima Werner, COPPE-UFRJ/BR Daltro José Nunes, II-UFRGS/BR Daniel M. Berry, University of Waterloo/CA David Déharbe, DIMAP-UFRN/BR Douglas Renaux, CEFET-PR/BR Eric Wong, University of Texas at Dallas/US Fernanda Alencar, DES-UFPE/BR Forrest Shull, Fraunhofer-Maryland/USA George Justo, Cap Gemini Ernst Young/UK Guilhermo Travassos, COPPE-UFRJ/BR Itana M. de Souza Gimenes, UEM-PR/BR Jaelson Castro, CIn-UFPE/BR (Program Committee Chair) João Araújo, Universidade Nova de Lisboa/PT João Falcão e Cunha, Universidade do Porto/PT José Carlos Maldonado, ICMC-USP-SC/BR Julio Cesar Leite, PUC-Rio/BR Káthia Oliveira, UCB/BR Leila Ribeiro, II-UFRGS/BR Leila Silva, UFS/BR Leonor Barroca, The Open University/UK Luis Antonio Olsina, U. Nacional de La Pampa/AR Manoel Mendonça, UNIFACS/BR Mario Jino, FEEC-UNICAMP/BR Mauro Pezzè, Universita' degli Studi di Milano - Bicocca/IT Murilo S. de Camargo, UNB/BR Nabor das Chagas Mendonça, UNIFOR/BR Oscar Pastor, Universidad Politécnica de Valencia /ES Paolo Giorgini, University of Trento/IT Paulo César Masiero, ICMC-USP-SC/BR Regina Braga, CTU-UFJF/BR Reiko Heckel, University of Paderborn/DE Ricardo de Almeida Falbo, UFES/BR Roberto da Silva Bigonha, DCC-UFMG/BR Rosângela Penteado, DC-UFSCar/BR Sandra Fabbri, DC-UFSCar/BR Steve Fickas, University of Oregon/US Xavier Franch, Universitat Politècnica de Catalunia /ES v

6 Comitê de Tutoriais Tutorials Committee Arndt Von Staa (PUC-Rio) - Coordenador Ana Regina Rocha (COPPE-UFRJ) Carlos Alberto Heuser (UFRGS) Carlos A. Marques Pietrobon (PUC-MG e UFOP) José Carlos Maldonado (ICMC-USP) Roberto da Silva Bigonha (UFMG) Roberto Souto Maior de Barros (UFPE) Toacy Cavalcante de Oliveira (PUC-Rio) Sessão de Ferramentas Tools Session Rodrigo Quites Reis (UFPA) - Coordenador Alexandre Cabral Mota (UFPE) Alexandre Marcos Lins de Vasconcelos (UFPE) Ana Cavalcanti (University of Kent) Arndt von Staa (PUC-Rio) Claudia Maria Lima Werner (COPPE/UFRJ) Daltro José Nunes (UFRGS) Itana Gimenes (UEM) João Marcos Bastos Cavalcanti (UFAM) Leila Ribeiro (UFRGS) Marcelo Soares Pimenta (UFRGS) Márcio Eduardo Delamaro (UNIVEM) Mario Jino (UNICAMP) Nabor das Chagas Mendonça (UNIFOR) Renata Pontin M. Fortes (ICMC-USP) Workshop de Teses e Dissertações em Engenharia de Software Software Engineering Thesis Workshop Patrícia Machado (UFCG) - Coordenadora Alexandre Marcos Lins de Vasconcelos (UFPE) Ana Cavalcanti (University of Kent) Ana Cristina Vieira de Melo (IME-USP) Anamaria Martins Moreira (UFRN) Ana Regina Rocha (COPPE/UFRJ) Cecilia Mary Fischer Rubira (UNICAMP) Daltro Nunes (UFRGS) Eliane Martins (UNICAMP) Guilherme Horta Travassos (COPPE/UFRJ) Itana Gimenes (UEM) Jorge Figueiredo (UFCG) José Carlos Maldonado (ICMC-USP) Júlio Leite (PUC-RIO) Káthia Marçal de Oliveira (UCB) Leila Ribeiro (UFRGS) Nabor das Chagas Mendonça (UNIFOR) Paulo Borba (UFPE) Paulo Cesar Masiero (ICMC-USP) Regina Braga (UFJF) Ricardo de Almeida Falbo (UFES) Rosângela Penteado (UFSCAR) Vera Werneck (UERJ) Membros do Comitê de Organização Organizing Committee Members Murilo S. de Camargo ( UnB) - Coordenador Alba Cristina M. A. de Mello (UnB) Célia Ghedini Ralha (UnB) Daniel Arruda Santos Anjos (UnB) Diogo de Carvalho Rispoli (UnB) Hugo A. de Azevedo Lousa ( UnB) João José Costa Gondim (UnB) José Carlos Ralha (UnB) Maria Emília (UnB) Rafael de Timóteo de Souza (UnB) Ricardo P. Jacobi (UnB) Ricardo Puttini (UnB) Robson de O. Albuquerque (UnB) Soemes Castilho Dias (UnB) Wantuil Firmiano Júnior (UnB) vi

7 Avaliadores (Sessão de Ferramentas) Reviewers (Tools Session) Adenilso Simão (UNIVEM) Auri Marcelo Rizzo Vincenzi (UNIVEM) Carla Alessandra Lima Reis (UFPA) Christian Reis (Async) Daniel G. Sante (ICMC-USP) Debora M. Barroso Paiva (ICMC-USP) Edmundo S. Spoto (UNIVEM) Marco A.G. Silva (ICMC-USP) vii

8 SBC - Sociedade Brasileira de Computação Diretoria Presidente: Cláudia Maria Bauzer Medeiros (UNICAMP) Vice-Presidente: José Carlos Maldonado (ICMC - USP) Administrativa e Finanças: Carla Maria Dal Sasso Freitas (UFRGS) Eventos e Comissões Especiais: Karin Breitmann (PUC-Rio) Educação: Marcos José Santana (USP - São Carlos) Publicações: Ana Carolina Salgado (UFPE) Planejamento e Programas Especiais: Robert Carlisle Burnett (PUC-PR) Secretarias Regionais: Edson Norberto Cáceres (UFMS) Divulgação e Marketing: Sérgio Cavalcante (UFPE) Regulamentação da Profissão: Roberto da Silva Bigonha (UFMG) Eventos Especiais: Ricardo de Oliveira Anido (UNICAMP) Conselho Membros Titulares Mandato Paulo Cesar Masiero (USP/São Carlos) Rosa Maria Vicari (UFRGS) Sergio de Mello Schneider (UFU) Tomasz Kowaltowski (UNICAMP) Ricardo Augusto da Luz Reis (UFRGS) Mandato Flávio Rech Wagner (UFRGS) Luiz Fernando Gomes Soares (PUC-Rio) Siang Wun Song (USP) Ariadne Carvalho (UNICAMP) Taisy Silva Weber (UFRGS) Membros Suplentes Daniel Schwabe (PUC-Rio) Marcelo Walter (UNISINOS) André Carvalho (ICMC - USP) Raul Sidnei Wazlawicki (UFSC) Coordenação da Comissão Especial de Engenharia de Software Leila Ribeiro (UFRGS) viii

9 Sumário Contents Ferramentas Tools FireWeb: Uma Ferramenta de Suporte aos Testes de Regressão de Aplicações Web 01 Wennder Indalécio Oliveira Fidelis, Eliane Martins OConGra - Ferramenta Para Geração de Grafos de Fluxo de Controle de Objetos 07 Paulo Roberto de A. F. Nunes, Ana C.V. de Melo enactpro: Automatizando Processos de Software 13 Sômulo N. Mafra, Márcio Barros, Guilherme H. Travassos Methodology Explorer - Uma Ferramenta para Definição e Reuso de Metodologias de Desenvolvimento de Software 19 Carlos Roberto da S. Junior, Hermano Perrelli de Moura, Suzana M. de Borba Maranhão GAW: uma ferramenta de percepção de grupo aplicada no desenvolvimento de software 25 Marco A. S. Mangan, Isabella A. da Silva, Cláudia M. L. Werner Uma ferramenta CASE para o Desenvolvimento de Software Orientado a Aspectos 31 Vinicius Cardoso Garcia, Daniel Lucrédio, Luíza Frota de Paula Pinto, Alexandre Alvaro, Eduardo Santana de Almeida, Antonio Francisco do Prado ProTool: Uma Ferramenta de Prototipação de Software para o Ambiente PROSOFT 37 Guilherme S. Rangel, Heribert Schlebbe, Daltro J. Nunes C&L: Um Ambiente para Edição e Visualização de Cenários e Léxicos 43 Carolina Howard Felicíssimo, Julio César Sampaio do Prado Leite, Karin Koogan Breitman, Lyrene Fernandes da Silva C-CORE - Component Construction and Reuse - Ferramenta para Desenvolvimento de Software Baseado em Componentes 49 Raphael Marcilio de Souza Neto, João Ronaldo Del Ducca Cunha, Antonio Francisco do Prado, Adriano A. Bossonaro, Alexandre Marcilio Souza, Joao Marcilio Souza Junior, Iolanda C. S. Catarino SPACES - Uma Ferramenta para Teste Funcional de Componentes 55 D. L. Barbosa, W. L. Andrade, P. D. L. Machado, J. C. A. Figueiredo MAIS: uma ferramenta de percepção para apoiar a edição concorrente de modelos de análise e projeto 61 Marco A. de M. Lopes, Marco A. S. Mangan, Cláudia M. L. Werner Run-time Variability through Component Dynamic Loading 67 Leonardo Murta, Aline Vasconcelos, Ana Paula Blois, Marco Lopes, Carlos Junior, Marco Mangan, Cláudia M. L. Werner GREN-WizardVersionControl: Uma Ferramenta de Apoio ao Controle de Versão das Aplicações Criadas pelo Framework GREN 73 Maria Istela Cagnin, José Carlos Maldonado, Rosângela Penteado, Rosana T. V. Braga, Fernão Germano RPOO Model Checker 79 Cássio L. Rodrigues, Paulo E. S. Barbosa, Jorge C. A. de Figueiredo, Dalton D. S. Guerrero Odyssey-VCS: Um Sistema de Controle de Versões Para Modelos Baseados no MOF 85 Hamilton Oliveira, Leonardo Murta, Cláudia M. L. Werner ix

10 FireWeb: Uma Ferramenta de Suporte aos Testes de Regressão de Aplicações Web Wennder Indalécio Oliveira Fidelis, Eliane Martins Instituto de Computação Universidade Estadual de Campinas (UNICAMP) Caixa Postal Campinas SP Brasil Resumo Este artigo apresenta a ferramenta FireWeb, a qual visa auxiliar os testadores de aplicações Web na tarefa de selecionar dentre os casos de testes existentes, aqueles que deverão ser reexecutados após as modificações realizadas na fase de manutenção. Também são apresentadas brevemente as principais técnicas de testes de regressão existentes, uma avaliação das mesmas, e a justificativa pela qual a ferramenta FireWeb é baseada na técnica de Retestar Dentro do Firewall. Abstract This article presents the FireWeb tool, which intends to help the Web applications testers in the task of selecting among the existing tests cases, those which will have to be re-run after the modifications done in the maintenance phase. There is also a brief presentation of the main regression testing techniques, an evaluation of them, followed by the justification why the FireWeb tool is based on the Retest inside the firewall technique. 1. Introdução Do ciclo de vida total de um sistema, estudos apontam que cerca de 90% corresponde à fase de manutenção. Durante essa fase, um software sofre modificações por várias razões, tais como: correções de problemas não encontrados durante o desenvolvimento, mudanças da especificação, adaptação a um novo ambiente, etc [5]. Essas modificações podem fazer com que partes do software que antes funcionavam parem de funcionar. Os testes de regressão visam minimizar ao máximo o número de falhas incorporadas ao software após as modificações sofridas na manutenção [6]. Atualmente, a rápida difusão da Internet e as novas tecnologias estão produzindo um significante crescimento da demanda de aplicações Web, sendo que, cada vez mais, são exigidos requisitos de usabilidade, confiança, interoperabilidade e segurança [3]. Além disso, a relevância econômica das aplicações Web aumenta a importância de controlar e de melhorar a sua qualidade. Como conseqüência, uma alta demanda está emergindo para metodologias e ferramentas para garantia da qualidade de sistemas baseados em Web [2]. Associado a isso, este artigo apresenta a ferramenta FireWeb que visa auxiliar os testadores de aplicações Web na tarefa de selecionar dentre os casos de testes existentes, aqueles que deverão ser reexecutados durante os testes de regressão. Nas seções seguintes, são apresentadas as principais técnicas de testes de regressão hoje existentes, e as particularidades da ferramenta FireWeb. 1

11 2. Técnicas Seletivas de Testes de Regressão Quando falamos em aplicar testes de regressão, as seguintes técnicas podem ser selecionadas [1]: Retestar tudo: todos os casos de testes existentes são reexecutados; Retestar casos de uso de maior risco: são selecionados para reexecução apenas aqueles casos de testes relacionados às aplicações consideradas mais críticas; Retestar por perfil: são selecionados para reexecução apenas aqueles casos de testes relacionados às aplicações que possuem maior freqüência de uso; Retestar código modificado: consiste na seleção apenas dos casos de testes que executam os trechos de código modificados; Retestar dentro do Firewall: através da dependência de código entre os componentes do software, é definido um Firewall, o qual consiste em uma fronteira imaginável que delimita a parte do software que pode vir a falhar devido às modificações efetuadas, e portanto deve ser retestada. Dentre essas técnicas, são consideradas seguras, ou seja, levam em consideração a análise de dependência entre os componentes [1], apenas duas delas, Retestar código modificado e Retestar Dentro do Firewall. Além, é claro, da técnica Retestar Tudo por não omitir nenhum caso de teste durante os testes de regressão. Quanto à técnica Retestar Dentro do Firewall, percebeu-se os seguintes fatores favoráveis ao seu uso: é segura; não exige armazenamento da associação entre os trechos de código dos componentes e os casos de testes que os exercitam. dispensa a análise de código fonte das versões atual e anterior dos componentes modificados, visando associar os trechos de código aos respectivos casos de testes que os exercitam. O que para aplicações Web é fundamental, devido à dificuldade na análise do código em virtude da grande heterogeneidade de tecnologias envolvidas na sua implementação. Por essas vantagens, as quais implicam diretamente na redução do trabalho e custo envolvidos, associado ao pouco tempo disponível para os testes de aplicações Web, em virtude da sua constante evolução [4], é que a ferramenta FireWeb é fundamentada na técnica Retestar dentro do Firewall. 3. Particularidades da Ferramenta FireWeb A ferramenta procura auxiliar não somente os testes de regressão, mas também a manutenção de sistemas. Para isso, ela propõe algumas rastreabilidades (associações), que permitem caminhar entre os diferentes níveis de abstração do sistema, como por exemplo, a partir dos casos de uso, chegar aos componentes que os implementam, o que torna mais fácil o entendimento do sistema. 2

12 3.1 Rastreabilidade entre casos de uso e componentes Um dos grandes problemas da manutenção de sistemas é a falta de documentação [5]. Associado a isso, existe a dificuldade em responder à seguinte pergunta: Dada uma funcionalidade, quais os componentes que a implementam? Um mecanismo que auxilie na obtenção dessa resposta irá, dado uma solicitação de manutenção em uma funcionalidade, agilizar a localização dos componentes a serem modificados e, também, facilitar a análise de impacto das manutenções. 3.2 Rastreabilidade entre casos de uso e casos de testes O número de componentes em um sistema Web tende a ser muito grande, podendo uma única página Web ser formada por vários componentes, entre frames 1, forms (formulários) e arquivos include 2, com isso, o trabalho de manter a associação entre casos de testes e componentes pode ser muito complicado e trabalhoso. É proposto então, que os testes sejam aplicados ao nível de casos de uso, o que não impede que os componentes sejam também testados, pois são eles os responsáveis pelas implementações dos casos de uso. A ferramenta não gera casos de testes, apenas localiza os casos de testes já existentes e que deverão ser reexecutados. 4. Obtenção do Firewall utilizando a FireWeb Para conseguirmos selecionar os casos de testes que farão parte dos testes de regressão utilizando a ferramenta, três fases deverão ser executadas, que são Preparação da infra-estrutura, Obtenção do firewall e Refinamento dos casos de testes, descritas a seguir: 4.1 Preparação da infra-estrutura Consiste na criação de uma base de dados constituída pelos casos de uso que compõem o software sob teste, seus componentes, casos de testes e os relacionamentos entre eles. É através dessa infra-estrutura que são montadas as associações descritas nas seções 3.1 e 3.2. Para facilitar o trabalho da equipe de testes, a ferramenta FireWeb disponibiliza a importação dos casos de uso, a partir da integração com a ferramenta Rational Rose, a importação dos componentes a partir do endereço do servidor de aplicações, e a importação da descrição e endereços físicos dos casos de testes. Para conclusão da fase de Preparação da infra-estrutura, ficam restando as associações entre os casos de usos, casos de testes e componentes, a qual é realizada de forma manual através das aplicações de associações constantes na ferramenta. 1 Um frame é uma área retangular disposta dentro da página, onde a navegação pode acontecer independentemente das outras áreas das páginas Web. 2 Funções que são reutilizadas como, rotinas de validação de CPF, datas, CNPJ, etc. 3

13 4.2 Obtenção do Firewall O Firewall, composto pelos componentes cujos casos de testes deverão ser reexecutados, é obtido através da execução dos seguintes passos: a) Identificação dos componentes que usam e são usados pelos componentes modificados. Essa identificação é realizada pela ferramenta através da análise do código fonte dos componentes que compõem o sistema. A figura 1 exibe a execução desse passo. b) Identificação dos casos de uso que são implementados pelos componentes localizados no passo anterior. Essa identificação é realizada pela associação entre casos de uso e componentes, efetuada na fase de Preparação da Infra-Estrutura. c) Identificação dos casos de testes que exercitam os casos de uso localizados. Essa identificação é realizada pela associação entre casos de uso e casos de testes, efetuada na fase de Preparação da Infra-Estrutura. A figura 2 exibe a execução completa dos passos b e c. 4.3 Refinamento dos casos de testes Uma vez encontrados os casos de testes relacionados ao firewall, os mesmos poderão precisar sofrer atualizações. Nesse ponto deverão ser observados, por exemplo, se os valores de entrada expressos nos casos de testes ainda são compatíveis com os respectivos componentes. Este passo deverá ser efetuado manualmente. 5. Limitações e avaliações da Ferramenta Atualmente a ferramenta está preparada para analisar dependências de código apenas entre: páginas Web desenvolvidas em ASP (Active Server Pages), programas COBOL e arquivos include. Isso devido ao fato do ambiente onde a mesma ter sido testada (Área de Desenvolvimento de Sistemas da CAIXA ECONÔMICA FEDERAL), tal tecnologia, no presente, ser a predominante entre as aplicações Web. Para os testes da ferramenta foi utilizado o sistema SIGEL Sistema de Gestão de Loterias, sistema hoje responsável pelo controle de toda a rede de loterias da CAIXA. Quanto à performance da ferramenta para a Obtenção do Firewall, em específico para o SIGEL, que hoje possui cerca de 1223 páginas Web, cujos códigos-fonte somam um total aproximado de 7,0 MB (média de 6 KB por página), a ferramenta obteve um tempo médio de dois minutos para conclusão da tarefa. Como o SIGEL trata-se de um sistema que está em produção há mais de 04 anos, e que não foi, durante o seu desenvolvimento, amparado por um processo de desenvolvimento de software que zelasse pela qualidade dos testes, os componentes dentro do Firewall eram encontrados pela FireWeb, mas não existiam as correlações dos mesmos com os casos de uso e casos de testes. Portanto, percebeu-se que para o total aproveitamento dos benefícios que a ferramenta Fireweb pode trazer à condução dos testes de regressão, a fase de Preparação da infra-estrutura deve ser bem atendida. 6. Acesso à FireWeb pela Internet Para acessar os arquivos de instalação da ferramenta FireWeb, é necessário acessar o endereço com o ID unicamp_fireweb e senha 4

14 SBES2004. Uma vez efetuado o logon, abrir a pasta de arquivos FIREWEB, onde estão disponíveis os arquivos de instalação e um arquivo (leia-me), contendo as instruções para instalação e uso da ferramenta. 7. Trabalhos correlatos Figura 1. Obtenção do Firewall Harrold propõe a técnica de Reteste do Código Modificado, onde os casos de testes a serem re-executados durante os testes de regressão são selecionados a partir da associação entre casos de testes e trechos de código dos programas. Através da comparação das versões original e modificada dos programas, são selecionados então, os casos de testes que exercitam os trechos de código que sofreram modificações [7]. A técnica de Reteste dentro do Firewall é proposta para sistemas orientados a objetos, onde o Firewall é estabelecido através dos relacionamentos de herança, agregação e associação entre as classes ou nas dependências entre os módulos. A partir daí, são selecionados os casos de testes que exercitam ao menos um dos módulos que se encontram dentro do Firewall [8]. 8. Conclusão O presente trabalho procurou contribuir para o campo dos testes realizados na fase de manutenção de sistemas, fase esta, que hoje corresponde à cerca de 90% do ciclo de vida de um sistema. Para isso, foi apresentada a ferramenta FireWeb, a qual procura auxiliar os testadores de aplicações Web na tarefa de selecionar os casos de testes a serem 5

15 reexecutados durante a manutenção, e com isso, melhor direcionar os esforços gastos com aatividadedetestes. 9. Referências Figura 2. Casos de testes associados aos componentes dentro do Firewall 1. Binder, Robert; Testing OO Systems: Models, Patterns and Tools; Addison-Wesley, 1999, cap. 08, 14, Filippo Ricca and Paolo Tonella; Analysis and Testing of Web Applications; Proceedings of the 23 rd International Conference on Software Engineering (ICSE 01) 3. Giuseppe Antonio Di Lucca, Anna Rita Fasolino, Francesco Faralli, Ugo De Carlini; Testing Web Applications; Proceedings of the International Conference on Software Maintenance (ICSM 02). 4. Hung Q. Nguyen; Testing Applications on the Web; Wiley Computer Publishing; Pigoski, Thomas M; Practical Software Maintenance: Best Practices for Managing Your Software Investiment. Wiley Computer Publishing, Pressman, Roger S.; Engenharia de Software, 5. Edição. McGraw-Hill, Inc., M.J Harrold and Gregg Hothermel; A Safe, Efficient Regression Test Selection Technique; ACM Transactions on Software Engineering and Methodology, V.6. no. 2, April 1997, pages L. White and H.K.N. Leung. A firewall concept for both control-flow and data-flow in regression integration testing. In Proceedings of International Conference on Software Maintenance, pages ,

16 Ocongra - Uma ferramenta para geração de Grafos de Fluxo de Controle de Objetos Paulo Roberto de A. F. Nunes, Ana C. V. de Melo Dep. de Ciência da Computação Instituto de Matemática e Estatística - Universidade de São Paulo Rua do Matão, Cidade Universitária São Paulo, SP prnunes@linux.ime.usp.br, acvm@ime.usp.br Resumo Para realizar testes em programas orientados a objetos, uma série de técnicas e critérios foram desenvolvidos. Uma das técnicas é a análise de fluxo de objetos, onde a maior dificuldade está na elaboração do grafo de fluxo de controle de objetos. Neste artigo será apresentada uma ferramenta que constrói este grafo com o objetivo de facilitar a análise e geração de testes. Abstract Software testing is still a difficulty and costly software development task. Nowadays, a reasonable amount of effort has been employed to develop techniques for object oriented testing paradigm. In this context, one of the promising aproaches is the object-flow testing strategy. The effective application of such strategy relies on buinding obgect control flow graph (OCFG). This paper presents a tool to generate the OCFG from Java programs in order to support system analysis and testing cases. 1. Introdução 1.1. Os problemas de teste O teste de programas é uma fase complexa no desenvolvimento de software. Em sistemas que envolvem diversas atividades de produção, a probabilidade de encontrarmos falhas na programação é muito alta [5]. A atividade de testes [3] consiste de uma análise dinâmica do produto, sendo relevante para a identificação e eliminação de erros que persistem. Assim, exige-se muita cautela por parte do testador, pois qualquer alteração no sistema pode acarretar mudanças em outras partes, o que pode causar falhas. O principal objetivo do teste é encontrar casos que descubram de maneira sistemática diferentes classes de erros e que tenham custos de tempo e de esforços mínimos. Com isso, técnicas e critérios de testes passam a ter papéis fundamentais na tarefa de teste O problema no teste Orientado a Objetos Para diferentes paradigmas de desenvolvimento com diferentes características, são necessárias técnicas de testes que abordem essas características para que erros sejam descobertos. O paradigma de Orientação a Objetos (OO) apresenta diferenças em relação ao de programação procedural. Requisitos de teste aplicáveis a sistemas procedurais tornam-se inadequados para os testes de sistemas Orientados a Objetos - os requisitos mudam de acordo com o paradigma. Embora o teste OO apresente vantagens em relação ao teste procedimental, a realização de teste é ainda um dos maiores problemas encontrados na produção de códigos OO. As técnicas tradicionais, em geral, são insuficientes para detectar falhas. Em virtude dessas dificuldades, adaptações de técnicas tradicionais para testes de programas OO e novas estratégias de teste têm sido bastante discutidas. 7

17 1.3. As técnicas existentes Alguns critérios de teste existentes para o paradigma prodedural foram adaptados para o OO. Existem atualmente diversas técnicas para testes OO, como por exemplo, baseado em estado [2], teste incremental [4], todos os caminhos [1], baseado no fluxo de objetos [6]. O teste baseado em estados observa os valores armazenados na representação dos objetos. A técnica de teste enfatiza a parte hierárquica dos objetos a fim de testar grupos de classes relacionadas, reutilizando informações de testes das superclasses para direcionar os testes das subclasses. Já o critério de todos os caminhos faz diversas verificações nas alterações dos valores dos objetos. O teste baseado no fluxo de objetos será detalhado na Seção A ferramenta Na Seção 2 será apresentada a técnica de fluxo de objetos (estratégia abordada pela ferramenta para criação do grafo). A Seção 3 apresenta a ferramenta e suas características principais, onde são abordados os passos executados para geração do grafo. A Seção 4 detalha um exemplo de funcionamento da ferramenta, onde é lido um sistema e em seguida apresentado o resultado obtido. Finalmente, a Seção 5 conclui apresentando outras utilizações para a ferramenta e propostas de trabalhos futuros. 2. Uma técnica de teste OO Estudos demonstram que é necessária uma avaliação global do sistema ao invés de análises e testes em pequenas partes do software [7]. A análise de fluxo de objetos segue uma estratégia de validação que se baseia na cobertura total de estados de transformação de cada objeto do sistema. Tais transformações são denotadas pela redefinição de valores para os atributos dos objetos através da passagem de mensagens entre eles. Para monitorar o comportamento de cada um dos objetos são analisados todos os pares de definição e uso, ou seja, os locais onde cada objeto é definido ou usado. Objeto definido: um objeto é dito definido quando o seu estado é iniciado ou alterado, ou seja, se pelo menos uma das seguintes condições for válida: 1. O construtor do objeto é invocado; 2. Um atributo é definido (tem seu valor alterado); 3. Um método que inicializa ou modifica o(s) atributo(s) é invocado. Objeto usado: um objeto é dito usado quando pelo menos uma das seguintes condições for válida: 1. Um de seus atributos tem seu valor utilizado; 2. Um método que utiliza o valor de um de seus atributos é invocado; 3. O objeto é passado como parâmetro. Em [6], Chen e Kao definem cinco passos para a construção de um grafo de fluxo de controle de objetos (GFCO) e identificação dos pares de definição-uso (du). O GFCO consiste basicamente na ligação entre as classes do sistema e seus métodos. Os cinco passos são os seguintes: 1. Criar o conjunto de definição e uso para cada método em cada classe. O conjunto de definição de um método M contém todos os atributos definidos por M e o conjunto de uso de M contém todos os atributos cujos valores são referenciados em M; 2. Construir o GFCO inicial. Este grafo contém um conjunto de super nós sn (representando cada método do sistema) e um conjunto de arestas. Cada sn é um conjunto de nós n (representando cada instrução - de definição ou uso - do método) e um conjunto de arestas de controle. Uma aresta de controle ac = (n i,n j ) indica que o nó n i chega ao n j por algum caminho de execução. Há dois tipos de arestas que descrevem o relacionamento entre super nós: passa-mensagem (a aresta (n i, sn j ) indica que sn j é invocado na linha i) e du-método (a aresta (sn i, sn j ) indica que sn i define algum atributo que é usado em sn j ). A criação do GFCO inicial consiste na construção de super nós e arestas de controle; 8

18 3. Adicionar ao grafo as arestas intra-métodos. Baseado no conjunto de definição e no conjunto de uso criados no passo 1, identificam-se as ligações dentro de um mesmo método. 4. Adicionar ao grafo as arestas inter-métodos. Ainda baseado no conjunto de definição e no conjunto de uso criados no passo 1, identifica-se as ligações referenciadas em outros métodos; 5. Selecionar os pares du. A cobertura de todos os pares du aumenta a probabilidade de se encontrar falhas no programa. Por isso, é necessário identificar dois tipos de pares de objetos: intra-métodos (referenciados dentro de um mesmo método) e inter-métodos (usados ou definidos fora do método). Para identificar esses pares é utilizado o grafo de fluxo de controle de objetos. Assim torna-se muito mais fácil a visualização do sistema e também a identificação dos pares du. Porém, a criação manual dos grafos está sujeita a falhas. Assim, há uma desestimulação para a aplicação da técnica devido às dificuldades. Como vimos anteriormente, um dos objetivos dos testes é encontrar falhas com o mínimo de esforço e o mínimo de custo possível. Diante da necessidade de automatização dessa tarefa foi criada a ferramenta Ocongra (Object Control Graph): Uma ferramenta para geração de Grafos de Fluxo de Controle de Objetos. Isso faz com que os responsáveis pelos testes se concentrem na criação de casos de testes, ao invés de gerarem os grafos manualmente, tornando assim a tarefa de testes menos demorada e trabalhosa. 3. Características da Ferramenta A Ocongra recebe como entrada um sistema (escrito em Java) e tem como saída o grafo de controle de seus objetos. O usuário, através de interface gráfica, designa o local onde estão localizados os arquivos fonte do sistema. Após a análise de cada classe do sistema, a ferramenta produz o grafo e o conjunto de pares du Geração do Grafo A construção do GFCO de um dado sistema obedece aos mesmos passos sugeridos em [6]. Dessa forma, a ferramenta foi desenvolvida com base nesses passos. A seguir serão descritas as fases executadas pela Ocongra para a geração do GFCO e o conjunto de pares de definição e uso. 1. Leitura e Identificação do Projeto: o usuário especifica o local do projeto. O software então lê as classes e organiza internamente as informações; 2. Construção do GFCO com as classes-mãe: baseado nos resultados da fase anterior, será construído o grafo contendo a relação entre cada classe do sistema lido na entrada. Assim, essas classes terão suas chamadas de métodos denotadas; 3. Identificação das definições-usos através do GFCO: com o grafo definido, as mudanças de estado dos objetos poderão ser analisadas com maior precisão. Analisando o grafo, o software identificará cada definição-uso utilizada pelas classes do sistema; 4. Atualização do GFCO baseada nas definições-usos: a identificação das definições e usos (passo anterior) possibilita a implementação de alterações no grafo obtido no passo 2, criando assim um novo grafo; 5. Geração gráfica dos resultados obtidos: o grafo encontrado após as análises do sistema é desenhado e exibido de forma gráfica ao usuário Arquitetura da Ferramenta O sistema está sendo desenvolvido em Java com a utilização da ferramenta Eclipse [8]. Possui aproximandamente 3500 linhas de código. Pressupõe-se que a entrada da ferramenta seja um conjunto de arquivos.java que compõem um sistema livre de erros de sintaxe ou compilação. 9

19 A arquitetura da Ocongra (Figura 1) consiste de uma interface gráfica, um Parser Java e um Gerador de Grafo. O usuário informa a localização de todos os arquivos do sistema. A ferramenta então aciona o Parser Java e com o resultado obtido aciona o Gerador do Grafo que devolve o GFCO do sistema lido. O Parser Java processa os arquivos.java e armazena uma estrutuda de dados organizada de forma a facilitar a geração do GFCO. O Gerador do Grafo percorre a estrutura criada pelo parser e, seguindo os passos citados anteriormente, constrói o GFCO. Figura 1: Arquitetura de desenvolvimento da ferramenta. 4. Um Exemplo de Uso Para exemplificar o funcionamento da ferramenta foi criada uma aplicação simples que instancia uma classe para conversão de unidades de temperaturas: kelvin <-> fahrenheit, celsius <-> kelvin, fahrenheit <-> celsius. A classe principal contém um objeto t Temperatura - como pode ser visto na Figura 2 - que é utilizado para conversões e para exibir os valores de unidades específicas. Figura 2: Um programa Java para conversão de unidades de temperatura. Inicialmente, após ter informado a localização do projeto, o software exibe a estrutura dos arquivos lidos: nome das classes e suas heranças, seus respectivos métodos e quais números de linhas eles aparecem (Figura 3). 10

20 Figura 3: Projeto Java lido e visualização de informações das classes. A Figura 4 mostra as definições e os usos presentes no método main da classe App, conforme enunciado anteriormente. Cada linha que possui um objeto é verificada a ocorrência de uma definição ou de um uso. Figura 4: Definições e Usos do método main da classe App. Já a Figura 5 mostra o grafo correspondente ao exemplo. Após identificar a estrutura do sistema o programa constrói esta saída gráfica. Após identificar as definições-uso e o grafo, é necessário exercitar os pares pelo menos uma vez. Para isso são criados os seguintes testes: (0,0) - exercita o par (10, 13) da classe App - e (1,0) - exercita o par (10,15) da classe App. Os dois testes acima exercitam todas as intanciações do objeto t. 5. Conclusões Esse artigo apresentou a ferramenta Ocongra utilizada na geração de grafos de fluxo de controle de objetos em testes de programas OO. Além da geração do grafo, a ferramenta auxilia a geração de dados para testes: a cobertura total dos casos de definição e uso de objetos (segundo a técnica [6]). Além da sua utilização prioritária no apoio ao teste, podemos utilizar os grafos resultantes no entendimento e análise de programas. Como o grafo das classes são gerados e a definição e uso dos objetos são identificados, a análise sobre a relação de dependência entre objetos é facilitada assim como a redefinição dos objetos. Pretendemos ainda estender a ferramenta para auxiliar a geração de casos de teste. Segundo os estudos nos mostram até o momento, temos a expectativa de obter uma geração semi-automática de casos de teste. Finalmente, pretendemos ainda desenvolver uma extensão da ferramenta que permita a análise e geração do GFCO para outras linguagens OO. Agradecimentos: Ao CNPq e à Microsoft pelo apoio financeiro. Agradecemos também a todos aqueles que participaram de alguma forma deste projeto. 11

21 Figura 5: Grafo de fluxo de controle da aplicação. Referências [1] CHAIM, M. L.. Depuração de Programas Baseada em Informação de Teste Estrutural. PhD thesis, Faculdade de Engenharia Elétrica e de Computação da Universidade de Campinas, Novembro/2001. [2] PINTO, I. M. and PRICE, A. M. A.. Um sistema de apoio ao teste de programas orientados a objetos com uma abordagem reflexiva. In XII Simpósio Brasileiro de Engenharia de Software, pages , [3] BARBOSA, Ellen F., VINCENZI, Auri M. R. and MALDONADO, José C.. Uma contribuição para a determinação de um conjunto essencial de operadores de mutação no teste de programas C. In XII Simpósio Brasileiro de Engenharia de Software, pages , [4] HARROLD, M. J., MCGREGOR, J. D. and FITZPATRICK, K. J.. Incremental testing of objectoriented class structures. In international Conference on Software Engineering, pages IEEE Computer Society Press, [5] PRESSMAN, R. S.. Software Engineering. McGraw-Hill, [6] CHEN, M. and KAO, H. M. Testing Object-Oriented Programs - An integral aproach. In Proccedings of the Tenth International Symposium on Software Reliability Engineering. IEEE Computer Society Press, [7] ALEXANDER, Roger T. and OFFUTT Jefferson A.. Criteria for Testing Polymorphic Relationships. In 11th International Symposium on Software Reliability Engineering. pages 15-23, [8] PROJETO ECLIPSE. Disponível no site Eclipse, URL: Consultado em 15/08/

22 enactpro: Automatizando Processos de Software Sômulo N. Mafra 1, Márcio Barros 1,2, Guilherme H. Travassos 1 1 COPPE/UFRJ Programa de Engenharia de Sistemas e Computação, Cx. Postal , CEP , Rio de Janeiro RJ Brasil 2 UNIRIOTEC Escola de Informática Aplicada, Av. Pasteur, 458 Urca Rio de Janeiro RJ Brasil [somulo, ght]@cos.ufrj.br, marcio.barros@uniriotec.br Resumo Processos de desenvolvimento de software tendem a envolver um grande número de pessoas com tarefas especializadas, equipes multidisciplinares e cronogramas de curto prazo. Gerenciar esses recursos de forma eficiente torna-se uma tarefa quase impossível de ser realizada se o processo não estiver automatizado ou parcialmente automatizado. Neste artigo, apresentamos um conjunto de facilidades visando automatizar a execução de processos de software. O uso dessas facilidades visa apoiar, através do acompanhamento e do controle de execução, a gerência efetiva dos fluxos de dados e controle desses processos. Abstract Software development processes are complex models that involve a large number of specialized people, organized in multidisciplinary teams, usually challenged by tight schedules and budgets. To efficiently manage these resources has become an almost impossible task if the software process is not at least partially automated. In this paper, we present a set of facilities to support software process enactment and automation. These facilities provide the effective management of data- and control-flows for these processes, by allowing project managers to monitor and control their processes execution. 1. Introdução As questões mais comuns direcionando organizações à automatização de processos são as necessidades de permanecerem competitivas, melhorarem a qualidade de seus produtos e reduzirem custos. Além disso, há a questão de manter a capacidade do processo, particularmente em organizações que vivenciam uma alta rotatividade de pessoal. Outro benefício identificado é o treinamento. Em certas organizações, o tempo gasto até uma pessoa começar a produzir código de qualidade foi reduzido de dois anos para seis meses com a adoção da tecnologia de automatização de processos [1]. A automatização pode ainda permitir simulações no processo de software como uma forma de avaliar possíveis problemas, gargalos e oportunidades para melhoria, uma vez que serve como um meio de ter controle das atividades executadas durante o projeto. A automatização de processos de software pode garantir que o processo esteja realmente sendo seguido ao prover o acompanhamento, o controle e a execução do processo, permitindo sua gerência. Os principais benefícios da utilização dessa tecnologia são [2]: Monitoração: permitindo acompanhar, avaliar e determinar eventuais problemas no cumprimento do cronograma de um projeto; 13

23 Orientação na execução: possibilitando meios que auxiliem o usuário a selecionar o próximo passo a ser seguido e executá-lo de forma correta; Obrigatoriedade de execução: mantendo o usuário dentro de um espaço restrito, direcionando-o em suas tarefas e evitando a perda de tempo em tarefas não relevantes; Integração de pessoas ao processo de software: permitindo que as pessoas participantes se comuniquem e compartilhem tarefas com menos esforço [3]. O objetivo deste trabalho é apresentar uma ferramenta que oferece um conjunto de facilidades visando automatizar a execução de processos de software, permitindo o acompanhamento e o controle dessa execução [4]. A arquitetura da ferramenta foi projetada de forma a mantê-la desacoplada de um ambiente de desenvolvimento de software, porém permitindo que esta troque informações com o ambiente. Essa troca de informações é possível através do mecanismo de integração de dados adotado [5]. O artigo encontra-se organizado em 3 seções, além dessa introdução que descreve a motivação e o objetivo do trabalho. Na seção 2 é descrita a proposta técnica da ferramenta, apresentando a arquitetura de componentes, o meta-modelo de processos utilizado e a solução adotada para a integração de dados. Na seção 3 é apresentada a ferramenta enactpro, através de descrições e ilustrações detalhando seu funcionamento. Finalmente, na seção 4 são apresentadas as conclusões e ressaltadas as perspectivas futuras deste trabalho. 2. A Máquina de Processos Em um processo de software é comum ocorrerem diversas iterações que implicam na reativação de atividades e seus artefatos associados. Essas iterações devem ser propagadas nas atividades e artefatos dependentes. A máquina de processos surge como um mecanismo especializado nessa função, ao proporcionar o controle de ativação de atividades, verificação de insumos e disponibilidade de recursos. A Figura 1 exibe uma visão geral dos componentes adotados neste trabalho. Figura 1 - Arquitetura de componentes. O gerente de projeto interage com o processo sendo executado ao utilizar o componente de acompanhamento. Ao mesmo tempo em que pode visualizar o processo sob diferentes perspectivas, ele também pode alterar os estados das atividades e artefatos. A cada operação executada pelo gerente de projeto no componente de acompanhamento é invocado o componente de execução (máquina de processos) que é responsável pelo controle da execução do processo de software, que se encontra mapeado nos objetos instanciados. Por sua vez, o componente de execução também recebe estímulos dos objetos instanciados, como o aviso de término de atividades. Finalmente, o componente 14

24 gerenciador de XML funciona como a interface de mapeamento entre as tags XML do arquivo contendo a descrição do processo e os objetos que representam o processo em memória. A definição do processo de software não está no escopo da ferramenta Meta-Modelo de Processos Como passo inicial do trabalho foi necessária a definição de um meta-modelo de processos que capturasse os principais conceitos relacionados em um processo de software [6]. O meta-modelo de processos resultante é exibido na Figura 2. Figura 2 Modelo de Classes. Nesse meta-modelo, a Máquina de Processo é responsável pelo controle dos processos de software. Cada processo é composto por atividades. Atividades podem ser decompostas em sub-atividades e depender da finalização de pré-atividades. As atividades de um processo são realizadas por pessoas, que podem desempenhar diferentes papéis. Cada atividade pode consumir artefatos (insumos), gerar um conjunto de artefatos (produtos) e utilizar ferramentas durante a sua execução A Máquina de Estados Na abordagem adotada, com respeito à automatização de processos, foi escolhida a máquina de estados [3]. O diagrama de estado das atividades é exibido na Figura 3. Figura 3 Diagrama de Estados Integração de Dados e Reflexão Computacional em C++ O uso da reflexão computacional no contexto desse trabalho tem como objetivo fornecer informações em tempo de execução das propriedades dos objetos, que representam processos de software, durante as sessões de importação e exportação de dados em XML. Entretanto, como a linguagem C++ padrão não possui mecanismos de reflexão computacional, foi necessária a adaptação da solução proposta em [7]. 15

25 2.4. Componentes Gráficos Para permitir o acompanhamento da execução dos processos de software, foi necessário o desenvolvimento de componentes que representassem um grafo de descrição da interação entre as atividades de um processo. Nesse workflow [8], as atividades são representadas por nós e as relações de dependência entre elas são representadas por ligações. A notação utilizada foi baseada na linguagem para modelagem de processos organizacionais desenvolvida na linha de pesquisa em Engenharia de Software da COPPE/UFRJ [6]. Essa linguagem está sendo avaliada por estudantes e pesquisadores, que a tem utilizado para modelar os processos apoiados pelas ferramentas desenvolvidas pelo mesmo grupo. 3. A Ferramenta enactpro A ferramenta enactpro foi implementado na forma de uma dll (dynamic-link library). Para a sua implementação foi escolhida a plataforma Microsoft Visual C e utilizado o parser MSXML 4.0. A escolha da plataforma deveu-se ao acordo estabelecido entre a UFRJ e a Microsoft para a utilização com fins acadêmicos de ferramentas Microsoft. A ferramenta pode ser executada em plataforma Windows 98 ou superior. Para a utilização da enactpro, é necessária apenas a descrição dos processos armazenada em um arquivo no formato XML. Entretanto, a definição de processos de software não é requisito da ferramenta. Para o exemplo ilustrado nesta seção, foi utilizada a ferramenta AdaptPro [9], que apóia a instanciação de processos de software. Durante a sessão de importação de dados, a descrição dos processos é mapeada em objetos em memória. Através desse mapeamento, é possível a visualização gráfica dos elementos contidos nos processos, permitindo assim o controle da execução dos mesmos. Agindo de forma contrária, o módulo de exportação de dados é o responsável pela geração da representação em XML do processo, contendo as informações atualizadas sobre a sua execução, informadas durante a execução da ferramenta. Uma vez que os processos encontram-se mapeados em objetos instanciados, seus elementos são exibidos sob a perspectiva de atividades a serem realizadas (Figura 4), de artefatos a serem produzidos e de pessoas participantes desses processos. Figura 4 Visualização do Processo sob Perspectiva de Atividades Cada atividade é representada por um pentágono com a porcentagem de conclusão da atividade expressa em seu interior. Cada pentágono possui uma cor indicando o estado da 16

26 atividade. Setas representam o encadeamento das atividades, explicitando as relações de dependência entre elas. O usuário pode escolher ações como explorar uma atividade composta, visualizando suas sub-atividades, ou subir, de uma atividade selecionada para um elemento do processo imediatamente acima na hierarquia, que pode ser uma superatividade ou um processo que contenha as atividades exibidas. Esse elemento pai é representado por um ícone na parte superior da tela. Para cada atividade selecionada são apresentadas informações relativas a estado, datas estimadas de início e fim, datas efetivas de início e fim, número de dias executados, descrição da atividade, pessoas alocadas à atividade, responsabilidades e papéis desempenhados pelas pessoas, artefatos consumidos, artefatos produzidos e ferramentas utilizadas. A interação entre o usuário e a máquina de processos se dá através da manipulação dos estados das atividades, que é possível pelas opções do menu Atividade. O usuário pode ainda notificar enactpro sobre mudanças no tempo de projeto, através do item Incrementar Data do menu Máquina de Processos. Figura 5 Visualização do Processo sob Perspectiva de Artefatos Cada vez que essa opção é acionada, as atividades em execução têm seus números de dias executados incrementados, provocando alterações em suas porcentagens de execução. Cada operação executada pelo usuário irá corresponder a estímulos provocados na máquina de processos, que irá responder com ações sobre os objetos que representam os processos. Essas ações serão descriminadas na guia Log de execução. Cada ação desempenhada pelo usuário que acarrete mudanças nos estados das atividades e dos artefatos ou nas datas de conclusão das atividades gera um registro de alteração. Assim, a máquina de processos mantém um histórico de alterações realizadas sobre os objetos, permitindo a recuperação desses valores através dos mecanismos de refazer e desfazer, disponibilizados no menu Máquina de Processo. O uso em conjunto dessas facilidades permite que simulações sejam executadas nos processos, facilitando a identificação de eventuais mudanças que sejam necessárias durante a sua execução. A Figura 5 ilustra a visualização dos processos de software sob a perspectiva de artefatos produzidos durante o processo. Cada artefato é exibido como um ícone, que é associado a um rótulo contendo o nome e o estado do artefato. Cada artefato é representado por uma cor que indica o seu estado. Além disso, são apresentadas ainda informações relativas à sua descrição, sua atividade produtora, suas atividades consumidoras e às pessoas responsáveis pela sua produção. O processo pode ser representado ainda sob a perspectiva de pessoas participantes. Cada pessoa é representada por um ícone associado a um rótulo contendo seu nome. Para cada pessoa são apresentadas informações indicando seu nome, , número de dias trabalhados e período de alocação no processo. Além disso, são apresentadas 17

27 informações relativas às atividades para as quais a pessoa está alocada, indicando sua responsabilidade e papel desempenhado e os artefatos sob sua responsabilidade. 4. Conclusão Como principais contribuições do trabalho, são ressaltados: A simplicidade de uso da ferramenta, que requer apenas a descrição de um processo de software como configuração inicial; O mecanismo de reversibilidade, possibilitando treinamento e simulação; Diferentes formas de visualização dos processos, permitindo a visualização dos mesmos sob a perspectiva de atividades a serem realizadas, de artefatos produzidos e de pessoas participantes; Interação com a execução do processo modelado, permitindo a manipulação dos estados das atividades e dos artefatos envolvidos, propagando essas alterações nos elementos dependentes. Entretanto algumas limitações foram identificadas nesse trabalho [4], que motivam a elaboração de trabalhos futuros, como a evolução do meta-modelo de processos utilizado, com o propósito de incorporar novos elementos de processo conforme descrito em [6]. A ferramenta enactpro foi desenvolvida como projeto final do curso de Bacharelado em Informática da UFRJ [4]. Ela está sendo utilizada, para fins acadêmicos, nos projetos de pesquisa da linha de Engenharia de Software Experimental da COPPE/UFRJ [10]. A ferramenta também está sendo integrada à Estação TABA [6], abrindo portas para sua utilização na indústria e em futuros estudos experimentais. Neste momento (abril de 2004), 18 pequenas e médias empresas de software brasileiras estão utilizando a Estação TABA, além de outras 10, que se encontram em processo de seleção. Agradecimentos O Prof. Travassos reconhece e agradece o apoio fornecido pelo CNPq para o desenvolvimento deste trabalho. Agradecemos em especial à equipe ESE e ao Projeto NSF-CNPq READERS II pelos comentários fornecidos. Referências 1. CHRISTIE, A., et al., 1997, Software Process Automation: Interviews, Survey, and Workshop Results. Technical Report, Software Engineering Institute, Carnegie Mellon University, Pennsylvania, US. 2. KOBIALKA, H., 1998, Implementing Support for Software Processes in a Process-centered Software Engineering Environment. Doctoral Thesis, Fraunhofer Institut Autonome Intelligente Systeme, Germany. 3. ARAÚJO, M., 1998, Automatização do Processo de Desenvolvimento de Software nos Ambientes Instanciados pela Estação TABA. Dissertação de M.Sc., PESC, COPPE/UFRJ, Rio de Janeiro, Brasil. 4. MAFRA, S. N., 2004, Infra-Estrutura para Automatização de Processos de Software. Monografia de Projeto Final de Curso, DCC/IM, UFRJ, Rio de Janeiro, RJ, Brasil. 5. SPÍNOLA, R., 2004, Uma Infra-estrutura para Integração de Ferramentas CASE Baseada em XML, Esquemas e Ontologias. Dissertação de M.Sc., PESC, COPPE/UFRJ, Rio de Janeiro, RJ, Brasil. 6. VILLELA, K., 2004, Ambientes de Desenvolvimento de Software Orientados à Organização. Tese de D.Sc., PESC, COPPE/UFRJ, Rio de Janeiro, RJ, Brasil. 7. SANTOS, G., et al., 2002, Uma Abordagem para o Mapeamento Objeto-Relacional em C++. PESC, COPPE/UFRJ, Rio de Janeiro, RJ, Brasil. 8. MURTA, L. G. P., 2002, Charon: Uma Máquina de Processos Extensível Baseada em Agentes Inteligentes. Dissertação de M.Sc., PESC, COPPE/UFRJ, Rio de Janeiro, RJ, Brasil. 9. BERGER, P., 2003, Instanciação de Processos de Software em Ambientes Configurados na Estação Taba, Dissertação de M.Sc., PESC, COPPE/UFRJ, Rio de Janeiro, RJ, Brasil. 10. ESE, Grupo de Engenharia de Software Experimental, PESC, COPPE/UFRJ In: acessado em 24/03/

28 Methodology Explorer uma Ferramenta para Definição e Reuso de Metodologias de Desenvolvimento de Software Carlos Roberto da S. Júnior 1, Hermano Perrelli de Moura 1, Suzana M. de Borba Maranhão 2 1 Centro de Informática, Universidade Federal de Pernambuco, Av. Prof. Luiz Freire S/N, Recife PE, Brazil , Departamento de Informática, Pontifícia Universidade Católica (PUC-Rio), Rua Marquês de São Vicente, 225, Rio de Janeiro RJ, Brazil, , [crsj, hermano]@cin.ufpe.br, suzana@inf.puc-rio.br Resumo O Methodology Explorer foi idealizado como uma ferramenta voltada para definição e manutenção de metodologias de desenvolvimento de software. A ferramenta possibilita melhorar a produtividade dos engenheiros de processos através de recursos para definição, armazenamento, reutilização e busca de componentes de uma metodologia, incluindo funcionalidades adicionais como publicação das metodologias na web. Abstract Methodology Explorer is a tool designed to help the process of creation and maintenance of software development methodologies. The tool increases processes engineers productivity making available useful functionalities for definition, storing, and reuse of methodology components and others advanced functionalities like methodology publication and verification. 1. Introdução Existe uma grande carência de ferramentas direcionadas às atividades de definição de metodologias para o processo de desenvolvimento de software. Isso dificulta o trabalho de engenheiros de processos, pois diversos elementos de documentação (como artefatos, sites, figuras, planilhas) precisam ser refeitos quando uma nova metodologia é definida. Adicionalmente, os engenheiros de processos também precisam localizar documentos já produzidos em projetos anteriores e analisá-los a fim de saber se esses podem ser reutilizados em novas metodologias [3]. Esse exemplo demonstra dificuldades presentes no cotidiano de um engenheiro de processos, pois algumas de suas atividades técnicas (como definir artefatos reusáveis, definir processos, elaborar documentos, entre outras) acabam dividindo espaços com atividades puramente burocráticas. A ferramenta Methodology Explorer foi criada no intuito de automatizar grande parte dessas atividades burocráticas e manuais e permitir que o engenheiro de processos possa se concentrar cada vez mais nas atividades técnicas, aumentando a produtividade e qualidade do seu trabalho. O Methodology Explorer oferece um ambiente para definir metodologias baseadas na definição, localização e reuso de componentes. Um componente é uma unidade de informação que compõe uma metodologia e pode ser manipulado isoladamente. Uma metodologia é composta por conjuntos de componentes e estes também são compostos por outros componentes. Por exemplo, atividades, artefatos, papéis e disciplinas são exemplos de componentes do Rational Unified Process RUP [6]. 19

29 Essa ferramenta possui ainda funcionalidades que permitem comparação de componentes e publicação das metodologias. É muito comum que a metodologia seja entregue aos usuários como um site HTML e/ou documentos textos. Por esse motivo, o recurso de publicação de metodologias do Methodology Explorer permite gerar um site HTML da metodologia englobando também todos os artefatos criados. O programa Methodology Explorer e arquivos de documentação podem ser encontrados em [5]. O restante do artigo apresenta uma visão geral da ferramenta, detalha algumas funcionalidades específicas e destaca as conclusões do trabalho. 2. Visão geral do Methodology Explorer Existem vários trabalhos relacionados ao apresentado. A Estação TABA [4] é uma ferramenta repleta de funcionalidades para criar ambientes para desenvolvimento de software. Um ponto forte do Methodology Explorer em relação a Estação TABA é a publicação (ver seção 3.2) de um site mais estruturado e a visão hierárquica dos componentes cadastrados. O APSEE Prosoft [2] possui o objetivo de auxiliar as diferentes etapas do ciclo de vida de processos. Em relação ao APSEE, o Methodology Explorer possui como ponto forte a possibilidade de definir metodologias a partir da instanciação de outras previamente cadastradas (ver seção 3.3). O Rational Unified Process Builder [7] é uma ferramenta que permite instanciar somente a metodologia Rational Unified Process. O Methodology Explorer foi desenvolvido procurando-se reunir e adaptar as melhores funcionalidades de tais ferramentas considerando os objetivos para o qual foi definida. A Figura 1 ilustra que a metodologia chamada Abrav é um componente composto por dois outros componentes: Gestão de Ambiente e Requisitos. O componente Gestão de Ambiente é composto pelos componentes Definir ferramenta e Estudar ambiente. Já o componente Requisitos é composto pelos componentes Esboço, Maturação e Fechamento. Figura 1. Estrutura hierárquica da metodologia Abrav. Na Figura 1, cada componente está associada a um tipo, que é apresentado entre os caracteres < e >. O tipo é um nome que qualifica o componente. Sua semântica é dada pelo engenheiro de processos na elaboração da metodologia. No exemplo acima, Gestão de Ambiente e Requisitos são do tipo FLUXO. E os componentes Esboço, Maturação e Fechamento. são do tipo FASE. A Figura 2 apresenta a tela principal do Methodology Explorer. O painel do lado esquerdo da tela, chamado Working Methodology, contém a representação da Figura 1. Cada componente armazena um conjunto de informações próprias. Um simples clique em um 20

30 componente possibilita visualizar seu conteúdo. Na Figura 2, podemos ver que o componente Requisitos está selecionado na árvore do painel Working Methodology e suas informações estão visíveis no painel direito, chamado Component Details. Figura 2. Estrutura hierárquica da metodologia e dos detalhes de um componente. As informações do componente, assim como a estrutura da árvore, podem ser alteradas pelo usuário a qualquer momento. Para que tais modificações tenham efeito sobre os dados efetivamente armazenados é necessário que o usuário execute a operação salvar. É possível também armazenar arquivos de qualquer formato como um atributo de um componente. A Figura 2 mostra que ferramenta é capaz de exibir parte do texto de um arquivo anexado. Os nós da árvore que representam tipos de componentes possuem, além de nome e descrição, um conjunto de regras associadas. A regra de cardinalidade indica quantos componentes o tipo de componente pode possuir e a regra de ordem indica se os componentes devem ser sempre apresentados na ordem em que eles forem criados. Novas regras, como, por exemplo, se a entrada de uma atividade da metodologia é produzida por alguma outra atividade, podem ser acrescentadas em futuras versões da ferramenta. Do mesmo modo que nas interfaces de programas Windows, a barra branca da Figura 2, que contém os nomes Methodology, Edit, Components, Wizards e Help agrupam funcionalidades da ferramenta em menus e é chamada de Barra de Menus. Utilizando a Barra de Menus é possível acessar todas as funcionalidades da ferramenta. A barra que contém ícones, logo abaixo da Barra de Menus, disponibiliza atalhos para algumas funcionalidades da ferramenta e é chamada de Barra de Tarefas. Ao salvar uma metodologia, todos os seus componentes são armazenados ou modificados no repositório do Methodology Explorer, alterando a biblioteca de componentes da ferramenta. Isso possibilita o desenvolvimento incremental de uma metodologia, pois o engenheiro de processos pode abrir uma metodologia previamente criada e alterá-la conforme se altere o processo de desenvolvimento de software. O repositório de dados da ferramenta é implementado através de um banco de dados capaz de armazenar todas as metodologias criadas. O banco de dados utilizado é Microsoft 21

31 Access 1, uma vez que já se encontra disponível em máquinas contendo Microsoft Office no sistema operacional Windows. No entanto, a mudança do banco de dados foi um requisito considerado na implementação da ferramenta, sendo fácil adicionar suporte a um novo banco de dados. A Figura 3 demonstra a biblioteca de componentes no painel direito da tela, chamado Methodology Base. Este painel é composto pelas abas Detailed View e o Methodology View. Figura 3. Estrutura hierárquica da metodologia e biblioteca de componentes. Através da biblioteca de componentes também é possível obter componentes já criados e reutilizá-los na composição de outras metodologias. Isso possibilita que o engenheiro de processos possa definir uma nova metodologia sem ter que criar todos os seus componentes. Para reutilizar um componente, basta que o usuário selecione e copie um componente do repositório e o cole na sua metodologia. O componente será colado exatamente abaixo do nó indicado pelo usuário. Os comandos de copiar e colar são disponíveis no menu Edit da Barra de Menus. 3. Outros Recursos da Ferramenta Além das funcionalidades primordiais de criação e reutilização de componentes, o Methodology Explorer também oferece outros recursos para aumentar a produtividade do usuário no uso da ferramenta. Essa seção descreve alguns desses recursos. Todos os wizards citados podem ser acessados através do menu Wizards da Barra de Menus Importação e Exportação de Metodologias A funcionalidade de exportação permite que uma metodologia inteira seja transportada da ferramenta para o diretório do sistema de arquivos escolhido pelo usuário. Na importação, 1 Informações sobre o Microsoft Acess podem ser encontradas em 22

32 dados do sistema de arquivos podem ser importados para o Methodology Explorer. Tais funcionalidades podem ser acessadas no menu Methodology da Barra de Menus. Tanto na importação quanto na exportação, são trafegados todos os dados da metodologia escolhida no formato XML [1], inclusive os arquivos anexados aos componentes. O XML gerado pela exportação pode ser utilizado para finalidades diversas, com construção de um site diferente do gerado pela publicação do Methodology Explorer ou para transporte de dados para outra ferramenta computacional Publicação de Metodologias O recurso de publicação permite gerar a versão produto da metodologia pertencentes à biblioteca de componentes. A versão produto é composta pelos arquivos que serão efetivamente utilizados pelos usuários da metodologia. Na versão atual da ferramenta, a publicação é feita em arquivos HTML. No entanto, outros formatos podem ser futuramente adicionados. Para proceder a publicação da metodologia, o usuário deve utilizar o wizard, chamado Methodology Explorer Web Publisher. O usuário precisa indicar o local em que será gerado o site, o nome do arquivo inicial do site e se deseja ou não publicar os arquivos anexados aos componentes da metodologia. O site HTML gerado possui todas as informações existentes nos nós da árvore de componentes. As informações definidas nos componentes são mapeadas em templates prédefinidos da ferramenta e as relações de hierarquia entre os componentes são expressas em através de links de navegação Instanciação de Metodologias Já foi afirmado que, para definir uma nova metodologia, o usuário pode criar todos os componentes necessários e/ou reutilizar alguns existentes no repositório de componentes. Existe também a possibilidade de instanciar uma metodologia, que consiste em criar uma nova metodologia, baseada nos componentes de uma outra metodologia já existente. Para tal utiliza-se o wizard chamado Methodology Explorer Instance Creator. O usuário precisa selecionar a metodologia e escolher quais os seus componentes deseja instanciar. Um último passo, opcional, permite que o usuário escolha um nome para a nova metodologia diferente do sugerido pelo wizard. O resultado da utilização do wizard é a geração de uma nova metodologia com os componentes selecionados da metodologia original. Uma vez criada a instanciação, ela pode ser alterada livremente pelo usuário. A disciplina Ambiente do RUP, por exemplo, indica que uma empresa possua uma metodologia organizacional e derive, a partir desta, metodologias específicas para cada projeto. A funcionalidade de instanciação é essencial para atender a derivação de novas metodologias a partir de uma outra mais abstrata e genérica Análise Comparativa de Metodologias É possível comparar semelhanças entre metodologias distintas no Methodology Explorer utilizando o wizard chamado Methodology Explorer Analyser. O critério utilizado pelo Analyser para comparar metodologias é comparar somente seus tipos de componentes. Para verificar se dois tipos de componentes são iguais, deve-se considerar apenas suas 23

33 regras, como cardinalidade e ordenação dos seus componentes. Os nomes dos componentes e dos tipos são irrelevantes. Uma metodologia A é uma instância de outra B quando os tipos de seus componentes formam um subconjunto dos tipos presentes na metodologia B. Uma metodologia A é dita variante de B se e somente se B é uma instância de A. Sendo assim, os seguintes resultados são possíveis na comparação de duas metodologias A e B: A é instância de B, A é variante de B, A é instância e variante de B e A e B não estão relacionadas. Para utilizar tal funcionalidade, o usuário só precisa indicar as duas metodologias que deseja comparar. A ferramenta apresenta um texto que expressa o resultado da comparação. Sem esse recurso, o usuário precisaria analisar visualmente as metodologias para descobrir semelhanças entre seus componentes. 4. Conclusões O Methodology Explorer é uma ferramenta voltada para definição de metodologias e é baseada em componentes, permitindo reuso de componentes e publicação de metodologias. Sua utilização estimula a criação de componentes padronizados, facilita o trabalho dos engenheiros de processos, além de melhorar a produtividade desses profissionais e a qualidade dos processos de software definidos. O principal diferencial do Methodology Explorer em relação a ferramentas similares é a instanciação de metodologias e a interface gráfica, que permite visualizar hierarquicamente os componentes cadastrados. É importante ressaltar que a ferramenta pode ser usada para desenvolver e representar metodologias genéricas de desenvolvimento de software, sem se prender às características de nenhuma metodologia específica como, por exemplo, o RUP. Referências 1. Apache XML Project, fevereiro APSEE Prosoft Projeto de Ambiente de Desenvolvimento de Software. Universidade Federal do Rio Grande do Sul, janeiro Coelho, C. MAPS: Um Modelo para Adaptação de Processos de Software, Dissertação de Mestrado. Centro de Informática, Universidade Federal de Pernambuco, Estação TABA Meta-Ambiente para instanciação de Ambientes de Desenvolvimento de Software convencionais e Orientados a Domínios, Universidade Federal do Rio de Janeiro, janeiro Junior, C.R.S., Methodology Explorer 1.0, maio Kruchten, P., The Rational Unified Process: An Introduction, Addison-Wesley, 2 nd Edition, Rational Unified Process Builder Process Manager s Guide, janeiro

34 GAW: uma Ferramenta de Percepção de Grupo Aplicada no Desenvolvimento de Software Marco A. S. Mangan 1,2, Isabella A. da Silva 1, Cláudia M. L. Werner 1 1 Programa de Engenharia de Sistemas e Computação COPPE Universidade Federal do Rio de Janeiro Caixa Postal CEP Rio de Janeiro RJ Brasil 2 Faculdade de Informática Pontifícia Universidade Católica do Rio Grande do Sul Porto Alegre RS Brasil [mangan,isabella,werner]@cos.ufrj.br, mangan@inf.pucrs.br Resumo A percepção é um dos aspectos fundamentais da colaboração, pois permite que cada participante do grupo entenda e antecipe ações dos demais participantes. No contexto de desenvolvimento de software, a percepção pode ser aplicada de forma a potencializar o trabalho em equipe, reduzindo a sobreposição e perda de trabalho. Neste texto, apresentamos uma ferramenta de percepção adaptada a dois ambientes de desenvolvimento. O primeiro ambiente oferece suporte à programação em código fonte enquanto o segundo oferece suporte ao desenvolvimento de modelos. Abstract Awareness is a fundamental aspect of collaboration since it allows that a group participant understands and anticipates other participants actions. In the context of software development, awareness can be applied to increase teamwork effectiveness, reducing work loss and overlap. In this paper, we present an awareness tool adapted to two software development environments. The former environment supports source code programming and the latter supports model-based development. 1. Introdução Um sistema de computador é um artefato construído de forma coletiva. A maior parte das equipes compartilha código fonte e modelos com o uso de repositórios. Na maioria dos casos, o conhecimento necessário para projetar e realizar o sistema ultrapassa as capacidades individuais dos desenvolvedores, não obstante, o sistema é construído por meio da coordenação de seus esforços individuais. Entretanto, à medida que o tempo passa e o sistema evolui, a coordenação desses esforços se torna cada vez mais trabalhosa, posto que os elementos que constituem o sistema se multiplicam e as contribuições individuais se sucedem. As informações desejadas encontram-se, em grande parte, no registro de atividades dos repositórios compartilhados e das ferramentas que apoiam o desenvolvimento de sistemas de computador. Entretanto, poucos usuários estão dispostos a aprender a sintaxe das ferramentas de consulta e a organizar e interpretar os dados disponíveis. Daí surge a necessidade de suporte, de preferência automatizado, para a coleta, organização e apresentação desse tipo de informação. Neste contexto, se insere a pesquisa em percepção de grupo. Este termo é 25

35 empregado para designar o sentimento ou estado mental de um participante em relação à constituição e atividades do grupo. Neste trabalho, adotamos um dos mecanismos de percepção propostos na literatura e construímos uma ferramenta que oferece informações de percepção de grupo integrada a dois ambientes de desenvolvimento de software: Eclipse IDE e Odyssey SDE. A ferramenta cumpre o papel de organizar a informação de percepção de grupo disponível no ambiente de trabalho do desenvolvedor e, ao mesmo tempo, oferece apoio ao pesquisador de trabalho cooperativo que deseje estudar o uso e o impacto desse tipo de informação sobre o trabalho da equipe de desenvolvimento. O restante deste trabalho está organizado da seguinte forma. Primeiro, é apresenta alguns dos conceitos básicos de percepção, que servem de base para a proposta da ferramenta (Seção 2). Em seguida, é introduzida a ferramenta GAW, detalhando sua estrutura interna e funcionamento (Seção 3). A seguir é apresentada uma adaptação voltada para ambientes de programação (Seção 4) e outra para ambientes de modelagem (Seção 5). Finalmente, a última seção relata as conclusões deste texto e as perspectivas de trabalhos futuros. 2. Percepção em Engenharia de Software A percepção é a compreensão das atividades dos demais, a qual provê um contexto para nossa própria atividade [2]. Na literatura específica de trabalho colaborativo, a percepção é um tema de grande importância. A percepção é um dos aspectos básicos da colaboração, a qual influencia e é influenciada pelos demais aspectos: comunicação, cooperação e coordenação. Existem estudos sobre o impacto da percepção sobre o trabalho e de como apresentar a informação correta ao usuário de forma a ampliar a sua percepção. Em engenharia de software, a percepção recebe maior atenção nos trabalhos que tratam de desenvolvimento de software distribuído e globalizado [4]. Nessas condições de isolamento no tempo e no espaço, a falta de percepção é uma das maiores dificuldades encontradas. O isolamento pode gerar impactos negativos tanto na comunicação quanto na coordenação de ações. A percepção é abordada em ambientes de desenvolvimento, ex. Tukan [7], e ferramentas, ex. Palantír [6]. Existem diversos tipos de informação de percepção. A informação de percepção de grupo apresenta os participantes do grupo e um indicador de sua atividade ao longo do tempo. Algumas aplicações da informação de percepção de grupo são: (a) localizar ajuda: encontrar desenvolvedores que trabalharam sobre um artefato, cuja opinião e conhecimento pode ser relevante para manter a coerência e a intenção do projeto original; (b) indicar competências: escolher entre os desenvolvedores, aquele que apresenta a maior aptidão para trabalhar com um artefato; (c) colaborar de forma oportunística: aproveitar a presença de outro desenvolvedor para solicitar uma interação síncrona; (d) coordenar esforços: detectar quando dois ou mais desenvolvedores trabalham sobre o mesmo artefato. O termo Group Awareness Widget (GAW) define uma família de componentes de percepção proposta por Kreijns e Kirshner [3]. Existem diversas implementações possíveis para componentes desta categoria (ex. componentes de visualização de ritmo de trabalho propostos por Begole, Tang e Hill [1]). 3. A Ferramenta GAW Um componente de percepção de grupo (GAW) [3] é um programa de computador que oferece em sua interface de usuário informações que podem ser úteis para que o usuário amplie seu estado de percepção sobre as atividades de outros elementos do grupo. 26

36 A ferramenta Gaw contém em sua interface gráfica uma visualização dos dados sobre o status de presença de determinados usuários em um dado período de tempo. Cada usuário é representado em uma linha e o eixo do tempo é representado em colunas. As sessões dos usuários são representadas através de barras coloridas de tamanho proporcional à duração das sessões. As barras são mostradas a partir do tempo presente para o passado, mostrando o histórico de presença de todos os usuários. Estação Local Estação Remota Visão I3 Modelo I2 Coletor Fonte I4 I1 Figura 1. Diagrama de componentes para a ferramenta Gaw. A estrutura interna da ferramenta pode ser resumida em um diagrama de componentes da UML em quatro componentes e quatro interfaces (Figura 1). Dois componentes encontram-se instalados na estação local, onde está o usuário da ferramenta Gaw. Os outros dois componentes estão instalados nas estações remotas, onde ocorrem os eventos que devem ser monitorados. A estação remota poderia ser um servidor, ex. servidor CVS. A informação encontra-se disponível em um elemento chamado fonte. A fonte de dados deve ser capaz de fornecer informações básicas sobre cada ação, tais como identificação do artefato, do usuário e data de ocorrência. Novas fontes de dados podem ser adicionadas com a construção de novos coletores. O coletor é o elemento responsável pela consulta à fonte de dados apropriada (I1). O coletor consulta a fonte em intervalos de tempo regulares e atualiza o modelo (I2). Em alguns casos, o coletor pode atuar sob demanda do modelo ou ser notificado pela fonte quando dados estão disponíveis (estas interfaces opcionais não foram desenhadas na Figura 1). O modelo mantém uma cópia dos dados coletados em memória local para facilitar a implementação e aumentar o desempenho do elemento que fornece a visão. A visão é notificada de alterações no modelo (I3) e os dados alterados são obtidos pela fonte através de interface apropriada (I4). A visão fornece uma interface de usuário adequada ao tipo de informação e à ferramenta utilizada pelo desenvolvedor. A interface de usuário é composta por uma tabela com duas colunas. Em cada linha é representada a informação sobre as atividades de um usuário. Na coluna da esquerda, é apresentado o nome do usuário. Na coluna da direita, uma barra horizontal que utiliza retângulos coloridos para representar as sessões de trabalho do usuário. Os retângulos localizados mais à esquerda representam atividades recentes. Cada usuário é representado por uma cor diferente. A escala de tempo pode assumir os valores de segundo, dia, semana, mês e ano. A representação enfatiza a periodicidade das atividades no artefato, a participação de cada usuário e a composição do grupo de interesse sobre o artefato. Por exemplo, considere um artefato alterado por dois desenvolvedores (Figura 2). O Gaw apresenta quatro sessões de trabalho, duas para cada usuário. A largura de cada retângulo colorido representa o tempo que durou a sessão de trabalho. A posição do retângulo, indica o momento em que a sessão ocorreu. O retângulo maior da segunda linha corresponde à sessão mais antiga. Podemos perceber que o segundo desenvolvedor foi o criador do artefato, mas que, ao longo do tempo, a responsabilidade passou para o primeiro desenvolvedor. A representação das barras de atividades considera a capacidade inata que o usuário apresenta para avaliar e reconhecer padrões de cores e formas. Por exemplo, a 27

37 sobreposição de dois retângulos coloridos em que uma mesma posição horizontal denota uma certa concorrência entre os dois desenvolvedores, momento em havia a possibilidade de interação síncrona. Na figura 2, a primeira sessão do primeiro usuário tem uma intersecção, no tempo, com a segunda sessão do segundo usuário. Figura 2. A atividade de dois desenvolvedores apresentada com um Gaw. O artefato considerado varia de acordo com a ferramenta utilizada. O desenvolvimento com base em modelos UML considera como principais abstrações os classificadores: classe, interface e tipo de dados. Por outro lado, o desenvolvimento com base em código fonte considera como principal abstração o arquivo. A seguir apresentamos uma implementação que trabalha sobre a abstração arquivo (CVS Watch) e outra sobre a abstração classificador (Work Rhythm). As duas adaptações aproveitam boa parte da implementação da ferramenta Gaw original. A ferramenta Gaw é utilizada durante o desenvolvimento para realização de testes com dados fictícios. 4. CVS Watch - Implementação com o Eclipse O Eclipse IDE é um ambiente de desenvolvimento gratuito e de código aberto com suporte para programas em Java ( A área de trabalho do ambiente (workbench) é composta por painéis independentes (views). Novas ferramentas podem ser adicionadas ao ambiente através de módulos (plug-ins). Um dos módulos disponíveis realiza a integração do ambiente com um repositório compatível com o Concurrent Versioning System (CVS). A adaptação do Gaw para o Eclipse utiliza funções desse módulo de integração com o CVS e um painel adicional na área de trabalho da ferramenta. O CVS trabalha com a abstração de arquivo. Figura 3. O CVS Watch integrado com a área de trabalho do Eclipse. A implementação do módulo, a partir da implementação da ferramenta Gaw, segue as recomendações da plataforma Eclipse [5]. A maior dificuldade na implementação do módulo foi a reescrita da interface de usuário usando a biblioteca SWT. A plataforma Eclipse utiliza a SWT em substituição à biblioteca Swing, distribuída com a plataforma Java. A SWT é desenvolvida pela IBM com o objetivo de oferecer um maior desempenho 28

38 de execução. A SWT apresenta um número menor de classes e métodos e exige a escrita de um maior número de linhas de código para realizar a mesma funcionalidade disponível na versão Swing do componente. Foram encontrados problemas de atualização de interface na plataforma Windows. A interface do CVS Watch é apresentada na Figura 3. Ao se selecionar um arquivo em um projeto um novo painel será apresentado na área de trabalho. A instalação e atualização do módulo são realizadas na própria ferramenta Eclipse, por meio do Update Manager, configurando um novo Site Bookmark para o endereço 5. Work Rhythm Implementação no Odyssey SDE O Odyssey SDE é um ambiente para desenvolvimento de software baseado em modelos de domínio ( São suportadas pelo ambiente as atividades de Engenharia de Domínio e Engenharia de Aplicação. O ambiente utiliza extensões de diagramas UML para representar o conhecimento de um domínio e permite que esses diagramas sejam reutilizados para facilitar a construção de aplicações. Figura 4. O Work Rhythm integrado com o ambiente Odyssey. Novas ferramentas podem ser incluídas no ambiente por meio da descrição de módulos de carga dinâmica. Um dos módulos disponíveis realiza a persistência de dados do ambiente com o uso de um mapeamento objeto-relacional: o Java Data Objects (JDO). O JDO permite que o Odyssey SDE armazene dados em um banco de dados relacional ou objetorelacional. Sobre o módulo de persistência JDO, foi desenvolvido o servidor de percepção Ariane [8], também integrado ao Odyssey SDE no contexto do projeto Odyssey Share. O módulo Work Rhythm, adaptação do Gaw para o ambiente Odyssey, realiza uma das formas de apresentação de informação previstas na proposta do Ariane. O Ariane oferece um número maior de eventos (criação, consulta, atualização e remoção de artefato) do que os disponíveis no CVS. Os eventos se referem a classificadores UML, o que oferece um maior volume de detalhes sobre a atividade dos usuários. Os eventos estão disponíveis em tempo real, o que ajuda a romper o isolamento entre os participantes. Na Figura 4, o Work Rhythm apresenta as barras de atividades para os desenvolvedores que trabalham com a classe A. 29

39 6. Conclusão Este texto caracteriza o problema do isolamento e da percepção de grupo no desenvolvimento de software. A proposta da ferramenta Gaw é organizar e apresentar ao desenvolvedor informações que estão presentes no ambiente de desenvolvimento, mas que nem sempre são exploradas. O Gaw complementa o suporte oferecido pelas demais ferramentas do ambiente colaborativo Odyssey Share [9]. A ferramenta Gaw reduz o tempo necessário para a localizar e organizar a informação sobre a atividade dos desenvolvedores sobre um determinado artefato. Duas adaptações da ferramenta permitem a sua integração com o ambiente de trabalho do desenvolvedor. A implementação do Gaw encontra-se estável, mas ainda precisa de melhorias. A análise da quantidade de operações em um arquivo não é suficiente para saber quais os responsáveis pelas maiores ou mais importantes modificações no arquivo. Em trabalhos futuros, pretendemos elaborar métricas para avaliar melhor a contribuição de cada operação. Outra melhoria seria alterar a escala de apresentação dos dados. Kreijns e Kirshner [3] adotam uma escala logarítmica para aumentar a compressão das informações mais antigas. Na escala utilizada atualmente, os dados mais antigos se perdem, pois as barras de atividade são deslocadas para fora da área visível com o passar do tempo. Atualmente está em implementação a alternativa de visualização "olho de peixe", na qual é possível ampliar trechos específicos do histórico. Referências 1. Begole, J., Tang, J. C., Smith, R. B., Yankelovich, N. (2002), Work rhythms: analyzing visualizations of awareness histories of distributed groups, Proc. of the 2002 ACM Conf. on CSCW, November, New Orleans, EUA. 2. Dourish, P., Bellotti, V. (1992), Awareness and Coordination in Shared Workspaces, Proc. of the Conf. on Computer Supported Cooperative Work, Toronto, Kreijns, K., Kirshner, P. A. (2001), The Social Affordances of Computer-Supported Collaborative Learning Environments, In: Proc. of the 31th ASEE/IEEE Frontiers in Education Conference, October 10-13, Reno. 6 p. 4. Kobylinski, R., Creighton, O., Dutoit, A., Bruegge, B. (2002), Building awareness in distributed software Engineering: Using issues as context. In: Int. Workshop on Distributed Software Development, Int. Conf. on Soft. Engineering, Orlando, EUA. 5. Melhen, W., Glozic, D. (2003), PDE does Plug-ins. Disponível em (04/2004). 6. Sarma, A., Noroozi, Z., van der Hoek, A. (2003), Palantír: Raising Awareness among Configuration Management Workspaces. In: Proc. of the 25th Int. Conf. on Software Engineering (ICSE 2003), pp , May, Portland, EUA. 7. Schümmer, T.; Schümmer, J. (2000), "Support for Distributed Teams in extremme Programming". In: Proceedings of extremme Programming and Flexible Processes Software Engineering - XP2000, Addison Wesley. 8. Santos, V. V. dos (2003), Ariane: um Mecanismo de Apoio à Percepção em Bases de Dados Compartilhadas, Tese de M.Sc., COPPE/UFRJ, Brasil. 9. Werner, C.M.L., Mangan, M. A. S., Murta, L. G. P., Souza, R. P. et alli (2003), "OdysseyShare: an Environment for Collaborative Component-Based Development", In: Information Reuse and Integration, October, Las Vegas, EUA. 30

40 Uma ferramenta CASE para o Desenvolvimento de Software Orientado a Aspectos Vinicius Cardoso Garcia 1, Daniel Lucrédio 1,Luíza Frota de Paula Pinto 1, Alexandre Alvaro 2, Eduardo Santana de Almeida 2, Antonio Francisco do Prado 1 1 GOES Grupo de Engenharia de Software Departamento de Computação Universidade Federal de São Carlos Caixa Postal 676 São Carlos, SP vinicius@dc.ufscar.br, lucredio@dc.ufscar.br, luiza@comp.ufscar.br, prado@dc.ufscar.br 2 Centro de Informática Universidade Federal de Pernambuco C.E.S.A.R. Centro de Estudos e Sistemas Avançados do Recife Caixa Postal 7851 Recife, PE aa2@cin.ufpe.br, esa2@cin.ufpe.br Abstract. This paper presents a tool to aid the Aspect-Oriented Software Development at the first process phases. For this task, a notation was defined, through the UML extension for the aspect-oriented paradigm, which enables the aspect identification in a high-level abstraction. An aspect-oriented implementation of the Observer design pattern is used to present how the tool supports this process. Resumo. Este artigo apresenta uma ferramenta para apoiar o Desenvolvimento de Software Orientado a Aspectos nas primeiras fases do processo. Para isto, foi definida uma notação, por meio da extensão da UML, para o paradigma orientado a aspectos, que permite a identificação de aspectos em um alto nível de abstração. Uma implementação orientada a aspectos do padrão de projeto Observer é utilizada para apresentar como a ferramenta dá suporte a esse processo. 1. Introdução A Programação Orientada a Aspectos (POA) [3] é um novo paradigma para o desenvolvimento de software que procura aumentar a modularidade reduzindo os problemas com entrelaçamento e espalhamento de código, tornando a estrutura do software mais clara e de mais fácil manutenção [3]. A POA pode ser aplicada para a implementação de vários interesses multi-dimensionais (crosscutting concerns) como, por exemplo, interação entre objetos, segurança, persistência, distribuição e tratamento de exceções, por meio de uma unidade modular chamada de aspecto. AspectJ 1 é uma linguagem de programação de apoio à POA por meio de novas construções para implementar os interesses multi-dimensionais. Enquanto AspectJ é uma Financiado pela Fundação de Amparo à Pesquisa do Estado da Bahia (FAPESB) - Brazil Financiado pela Fundação de Amparo à Pesquisa do Estado de São Paulo (FAPESP) - Brazil Financiado pelo Programa Institucional de Bolsas de Iniciação Científica - PIBIC/CNPq

41 poderosa linguagem para a POA, não existe ainda uma linguagem de modelagem orientada a aspectos que apóie o projeto orientado a aspectos, em um nível mais alto de abstração. Alguns projetos vêm sendo desenvolvidos para modelar aspectos em um alto nível de abstração, na fase de projeto. As pesquisas que estão em andamento ainda não propuseram uma padronização e não estão maduras o suficiente, entretanto, ainda sim, algumas vêm destacando-se, como, por exemplo [6] e [4]. Sendo assim, este artigo apresenta uma ferramenta CASE para apoiar o Desenvolvimento de Software Orientado Aspectos (DSOA) por meio de uma notação estendida da UML com os conceitos da POA e da semântica da linguagem AspectJ. Nas demais seções deste artigo são feitas considerações sobre o projeto orientado a aspectos e sua implementação em uma ferramenta CASE. 2. Projeto de Software Orientado a Aspectos O projeto orientado a aspectos organiza o processo de DSOA e possibilita a identificação de aspectos em um alto nível de abstração nas primeiras fases do processo, favorecendo assim a aprendizagem e a documentação do projeto de aspectos de uma forma mais intuitiva. A partir de então, esta documentação e o conhecimento adquirido no processo, facilitam e estimulam o reuso de aspectos [6]. Os conceitos básicos do paradigma orientado a aspectos, como pontos de combinação (join points), pontos de interseção (pointcuts), entrelaçamento (crosscutt), sugestões (advices) e aspectos, são fundamentos que devem estar presentes em todo o processo de desenvolvimento de software desde a especificação até a implementação. Porém, sabe-se que estes conceitos foram originalmente propostos considerando-se apenas a sua implementação, por meio de uma linguagem de programação [2]. Contudo, a definição de um padrão para o projeto de software orientado a aspectos, a partir de modelos e técnicas de modelagem orientadas a aspectos independentes da linguagem de programação, vem despertando o interesse de pesquisadores. Todavia, ainda é uma área onde a pesquisa foi pouco desenvolvida. 3. A notação UAE A partir do estudo das diferentes propostas para a modelagem orientada a aspectos, alguns pontos em comum foram identificados, indicando uma conformidade na representação de alguns conceitos da POA. Esta seção apresenta a notação UAE (UML-based Aspect Engineering) para a modelagem de sistemas orientados a aspectos, por meio da extensão da UML. Para dar suporte a esta notação, a ferramenta de modelagem MVCASE 2 [1] foi estendida para apoiar o projeto orientado a aspectos através da notação UAE. Primeiramente o engenheiro de software deve, a partir do projeto já criado, inserir um novo diagrama na visão lógica (Logical View), por meio da seqüencia de menus: New -> Aspect Diagram. A seguir, um novo diagrama é criado, permitindo ao engenheiro de software utilizar os estereótipos criados para representar as construções da POA, são eles: <<aspect>>, <<crosscuts>> e <<introduces>>, conforme mostra a Figura 1. A principal construção em AspectJ é o aspecto. Um aspecto define uma funcionalidade específica que pode afetar diferentes partes de um sistema, como, por exemplo, persistência em banco de dados. Além disso, os aspectos podem alterar a estrutura 2 Disponível para download em: 32

42 Figura 1: Extensão da MVCASE para o Projeto Orientado a Aspectos dinâmica de um sistema por meio dos pontos de combinação (join points) ou, ainda, alterar a estrutura estática por meio da declaração de introduções (introductions). Um aspecto normalmente define um ponto de interseção (pointcut) que identifica os pontos de combinação e adiciona comportamentos a eles por meio de sugestões (advices). Para facilitar a apresentação da notação, será utilizado como exemplo a modelagem orientada a aspectos do padrão de projeto Observer [5] aplicado para um problema envolvendo a visualização de temperaturas. Considere-se um conjunto de termômetros que colhem informação de uma fonte de temperatura. A todo momento que a temperatura mudar, o display do termômetro deve ser atualizado. A Figura 2 mostra esta modelagem, onde os elementos sombreados são específicos da notação UAE. Nesta notação, um aspecto possui uma representação diferente da classe, o que permite diferenciar mais facilmente os elementos, resultando em uma melhor qualidade visual do modelo. Uma interface do tipo Observer é definida para descrever a regra Observer. Todos os observadores devem implementar esta interface. O objetivo é permitir a cada observer ter um subject correspondente. Este exemplo não trata múltiplos subjects para um observer. Do mesmo modo, tem-se uma interface Subject, onde todos os subjects devem implementá-la. Figura 2: Notação UAE Na Figura 2 tem-se a classe Celsius que é uma fonte de dados de temperatura. Esta classe armazena as informações sobre a temperatura corrente em graus centígrados, que podem ser acessadas pelos métodos setdegrees e getdegrees. Outra classe importante é a classe Thermometer, que é a classe base para o conjunto de termômetros no exemplo, que vão implementar o Observer, as classes CelsiusThermometer e 33

43 FahrenheitThermometer. Estas classes estendem a classe Thermometer. Usando as técnicas de POA, é possível separar os elementos relacionados ao padrão Observer dos demais elementos. Para isso são utilizadas as seguintes construções: 3.1. Aspecto Um aspecto abstrato chamado ObserverPattern é definido para implementar a funcionalidade do padrão de projeto. O aspecto ConcreteObserverPattern estende o aspecto abstrato ObserverPattern e indica quais classes são observers, quais são subjects e em que casos os observers serão notificados Pontos de interseção O aspecto abstrato ObserverPattern cria um ponto de interseção abstrato, especificado pela etiqueta valorada com o nome +statechanges. Este ponto de interseção é estendido e implementado no aspecto concreto para informar em quais situações os observers serão notificados. Ele implementa ainda uma sugestão do tipo after, especificada pela etiqueta valorada +after, que irá notificar todos os observers quando estes pontos de interseção foram alcançados. O ponto de interseção abstrato definido no aspecto ObserverPattern (linha 1, Figura 2) também é estendido no aspecto concreto e define que os observers irão ser notificados toda vez que o método setdegrees() for chamado (linha 2, Figura 2) Introduções É possível também especificar introduções, por meio do estereótipo <<intruduced>> e do relacionamento <<introduces>>. No caso so aspecto abstrato ObserverPattern, os seguintes atributos e métodos são criados dinamicamente na interface Subject: observers, add(..), remove(..) e getobservers(), e na interface Observer: subject, setsubject(..) e getsubject. Por meio de introduções também é possível mudar a estrutura das classes, conforme ocorreu com a classe Celsius, que passou a implementar a interface Subject, especificado por um relacionamento do tipo realize com o estereótipo <<introduced>>. Ainda sobre a classe Celsius, o método getdata() é introduzido, e tem sua implementação de acordo com a interface Subject. O mesmo ocorreu com a classe Thermometer, que passa a implementar a interface Observer e tem o método update() definido de acordo com a interface Observer. Após o engenheiro de software ter o modelo orientado a aspecto especificado, é possível gerar o código automaticamente em uma linguagem orientada a aspectos, no caso AspectJ. Ocódigo gerado é testado e caso erros sejam encontrados, ou novos requisitos sejam identificados, o engenheiro de software pode trabalhar no modelo, especificado na ferramenta CASE, e novamente gerar o código em AspectJ. Na Figura 3 é apresentada a geração do código do aspecto abstrato ObserverPattern, na MVCASE. 4. Trabalhos Correlatos A necessidade de uma notação satisfatória para o projeto de software orientado a aspectos foi reconhecida anos após o paradigma ter sido criado. Dentre as diferentes propostas para estender a UML destaca-se a proposta de Suzuki e Yammamoto [6] e a de Pawlak et al.[4]. 34

44 Figura 3: Geração de código em AspectJ na MVCASE 4.1. Suzuki e Yammamoto A primeira proposta de extensão da UML com conceitos para o projeto de software orientado a aspectos foi apresentada por Suzuki e Yammamoto [6]. Nesta abordagem, uma nova meta-classe UML chamada aspect é introduzida. Esta meta-classe está relacionada à classe base por meio de um relacionamento de realização. Esta proposta tem dois problemas. Primeiro, os autores apresentam somente uma notação que pode ser usada para representar o conceito de introduções. Não está claro como os pontos de interseção e as sugestões podem ser especificados na UML e como será representada a forma que os relacionamentos de entrelaçamento (crosscutts) afetam o comportamento das classes. Segundo, o uso de um relacionamento de realização para modelar a relação entre um aspecto e as classes que ele entrecorta não está totalmente de acordo com a semântica da AspectJ.Na UML uma realização é um relacionamento entre um elemento de modelo específico e o elemento de modelo que o implementa [7]. Em AspectJ, entretanto, uma sugestão não é uma pura declaração de um entrelaçamento. Em AspectJ, uma sugestão declara e implementa as características de um entrelaçamento Pawlak et al. A proposta de Pawlak et al. [4] para o Projeto de Software Orientado a Aspectos por meio da extensão da UML é a que se apresenta mais interessante. São definidos três novos conceitos na UML: (1) grupos (groups), que provêm meios de classificação para entidades distribuídas e heterogêneas, (2) relações de ponto de interseção (pointcut relations) que permitem ao engenheiro de software definir entrelaçamentos (crosscutts) dentro do programa funcional, e (3) a metaclasse aspecto (aspect-classes) que implementa a extensão do programa nos pontos de entrelaçamento (crosscutting points) especificados pelas relações de ponto de interseção. Porém, alguns pontos sobre o trabalho de Pawlak et al. apresentam problemas: a utilização do papel de um relacionamento para representar os pontos de combinação acaba poluindo visualmente o modelo, visto que a definição de pontos de combinação normalmente envolve um grande número de caracteres. Outro ponto é a utilização de caracteres especiais como, por exemplo, sinal de exclamação (! ) que pode possuir outro significado em um linguagens de programação, resultando em confusão. A notação UAE busca solucionar estes problemas, oferecendo uma notação simples, onde a representação de aspectos é diferenciada em relação à de classes, com pouca 35

45 poluição visual e voltada à linguagem AspectJ. 5. Conclusões e Trabalhos Futuros Neste artigo foi apresentada uma ferramenta CASE para apoiar o DSOA e uma nova abordagem para representar os conceitos da POA e a semântica da AspectJ na UML. Na ferramenta é possível especificar as construções disponíveis pela linguagem para implementar os interesses multi-dimensionais em aspectos. São utilizados estereótipos específicos, e em alguns casos etiquetas valoradas, que estendem os conceitos da UML. Deste modo os interesses multi-dimensionais podem ser especificados em um alto nível de abstração, proporcionando em nível de modelo as vantagens que a POA já provê em nível de código (melhora na manutenibilidade, legibilidade do código, adaptabilidade e reuso, entre outras). A MVCASE foi modificada e agora possui uma interface específica para a criação de modelos orientados a aspectos. Além disto, também é possível gerar o código automaticamente em AspectJ, acelerando o DSOA. Na maioria das ferramentas de modelagem existentes não existe suporte para a geração de código nem para a modelagem de aspectos, sendo necessário utilizar os próprios mecanismos de extensão da UML, o que além de mais trabalhoso não resulta em boa legibilidade do modelo. Atualmente mais testes estão sendo realizados, para verificar a validade tanto da extensão da MVCASE como da notação UAE. Como trabalhos futuros, têm-se a adição de técnicas de modelagem para representar também o processo de weaving, que consiste na combinação, em tempo de compilação dos diferentes interesses multi-dimensionais. Isso facilitará o trabalho do engenheiro de software, possibilitando a geração automática de scripts de compilação, acelerando o processo de DSOA. Referências [1] E. Almeida, C. Bianchini, A. Prado, and L. Trevelin. MVCASE: An integrating technologies tool for distributed component-based software development. In Proceedings of the 6th Asia-Pacific Network Operations and Management Symposium. (APNOMS 2002) Poster Session. IEEE Computer Society Press, [2] G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, and W. G. Griswold. An overview of AspectJ. In J. L. Knudsen, editor, Proceedings of 15th European Conference on Object-Oriented Programming (ECOOP 2001), Lecture Notes in Computer Science (LNCS) 2072, pages , Berlin, jun 2001b. Springer-Verlag. [3] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.-M. Loingtier, and J. Irwin. Aspect- Oriented Programming. In Proceedings of the 11st European Conference Object-Oriented Programming (ECOOP 97), volume 1241 of LNCS, pages Springer Verlag, [4] R. Pawlak, L. Duchien, G. Florin, F. Legond-Aubry, L. Seinturier, and L. Martelli. A UML notation for aspect-oriented software design. In Proceedings of the 1st International Conference on Aspect-Oriented Software Development (AOSD 2002). ACM Press, April [5] E. K. Piveta and L. C. Zancanella. Observer pattern using aspect-oriented programming. In The Third Latin American Conference on Pattern Languages of Programming (SugarLoafPLOP 2003), [6] J. Suzuki and Y. Yamamoto. Extending UML with aspects: Aspect support in the design phase. In Proceedings of 13rd the European Conference Object-Oriented Programming (ECOOP 99). International Workshop on Aspect-Oriented Programming, June [7] UML. Unified Modeling Language (UML) - version 1.5. Object Management Group, May

46 ProTool: Uma Ferramenta de Prototipação de Software para o Ambiente PROSOFT Guilherme S. Rangel 1, Heribert Schlebbe 2, Daltro J. Nunes 1 1 Instituto de Informática, Universidade Federal do Rio Grande do Sul (UFRGS) {rangel,daltro}@inf.ufrgs.br 2 Fakultät Informatik, Universität Stuttgart, Germany schlebbe@informatik.uni-stuttgart.de Abstract. The current formal specification environments reported in the literature provide resources for specification and often for rapid prototyping. One of their limitations is the complex formal notation. This forces the software engineer to focus not only on the problem to be solved, but also on the complex notation to solve the problem. This paper presents the main aspects of ProTool to specify and prototype abstract data types through a simpler and more intuitive notation, called algebraic PROSOFT. Resumo. Os ambientes de especificação formal de software existentes na literatura fornecem recursos para especificação e muitas vezes para prototipação rápida. Uma das limitações das ferramentas atuais baseia-se na alta complexidade da notação formal empregada, o que força o engenheiro de software a preocupar-se não somente com o problema a ser solucionado, mas também com a complexidade da notação para resolver o problema. Este artigo apresenta os aspectos da ferramenta ProTool para especificação e prototipação formal de tipos abstratos de dados através de uma notação mais simples e intuitiva, chamada PROSOFT-algébrico. 1. Introdução No desenvolvimento de software, a fase de especificação dos requisitos é uma das mais importantes, visto que erros não detectados nesta são propagados para as fases posteriores. Quanto mais avançado estiver o desenvolvimento, maior o custo para reparar um erro introduzido nas fases iniciais, pois isto envolve reconsiderar vários estágios do desenvolvimento [3, 4]. A prototipação permite a validação dos requisitos do software logo no início do desenvolvimento, evitando a propagação de erros. Paralelamente, a utilização de métodos formais visa revelar inconsistências, ambigüidades e falhas na especificação do software, que podem caso contrário, não serem detectadas. Unindo especificação formal e prototipação os benefícios de ambas abordagens são combinados e uma descrição de software bem estruturada, executável e sem ambiguidade pode ser desenvolvida. Na literatura existem vários ambientes que combinam especificação formal com algum tipo de prototipação. Quando o domínio do problema abrange a especificação de tipos abstratos de dados (TADs), os mais utilizados são: Larch Prover [7], RAISE Financiado por CNPq e Deutsches Zentrum für Luft- und Raumfahrt (DLR). 37

47 Tools [5], CASL Tool Set (CATS) [1] e OBJ3 [6]. Entretanto, identificou-se que nestas ferramentas o engenheiro de software muitas vezes preocupa-se não somente com o problema que está sendo solucionado, mas também com a alta complexidade da notação formal adotada [10]. Motivado por estas idéias, este artigo apresenta a ferramenta ProTool (Prototyping Tool), que suporta especificação de TADs em PROSOFT-algébrico [9] e a prototipação rápida em OBJ3 1. A principal contribuição do ProTool está no aumento da facilidade de criar TADs através de uma linguagem visual e na prototipação automática destes. O ProTool foi desenvolvido no contexto do projeto PROSOFT, realizado no Instituto de Informática da UFRGS em cooperação com a Universidade de Stuttgart (Alemanha), sob coordenação do Prof. Dr. Daltro José Nunes. O objetivo principal deste projeto é construir um ambiente integrado de desenvolvimento de software. 2. PROSOFT O PROSOFT divide-se em: notação formal PROSOFT-algébrico para especificar software e ambiente PROSOFT-Java para implementar especificações Notação PROSOFT-Algébrico O PROSOFT, como método de especificação formal, apóia a modularização e a reutilização das especificações de TADs. No PROSOFT-algébrico cada ATO (Ambiente de Tratamento de Objetos) especifica um TAD. A construção de um ou mais ATOs representa uma solução do problema (software). Segundo o paradigma PROSOFT [8] (Figura 1) diferentes ATOs são integrados através da Interface de Comunicação de Sistema (ICS), que também serve como meio de comunicação entre eles. ATO1 ATO2 ATO3 ATO name Class sort ICS Operations Formal Variables ATO4... ATOn Axioms Figura 1: Estrutura do PROSOFT De acordo com a Figura 1, um ATO é composto de cinco partes. A classe define o TAD do ATO através da instanciação de especificações parametrizadas. As partes seguintes especificam a funcionalidade (assinatura) das novas operações algébricas sobre o tipo de dado, as variáveis formais e a semântica das novas operações (axiomas). Enquanto outras notações formais fornecem recursos somente textuais para especificação, a notação PROSOFT-algébrico provê uma representação gráfica 2 para facilitar a criação de tipos de dados complexos através da instanciação de tipos de dados mais simples. O PROSOFT-algébrico possui o mesmo poder de expressão da notação algébrica clássica. A diferença está na representação gráfica, que torna os TADs mais fáceis de serem construídos, analisados e entendidos do que a correspondente textual. 1 Optou-se pela prototipação no ambiente OBJ3 com intuito de reutilizar a eficiente implementação do sistema de reescrita de termos para OBJ. 2 A definição de operações e axiomas não têm representação gráfica. 38

48 2.2. Ambiente PROSOFT-Java e ProTool PROSOFT-Java é a implementação do paradigma PROSOFT em Java, na forma de um ambiente homogêneo e integrado para desenvolvimento de software. O núcleo do ambiente consiste de um conjunto de classes e interfaces Java que cooperam entre si para fornecer a funcionalidade requerida pelo paradigma PROSOFT. O ProTool foi implementado dentro do PROSOFT-Java com recursos para editar ATOs algébricos e prototipá-los em OBJ. O desenvolvimento do ProTool ocorreu com a especificação formal, em PROSOFT algébrico, do editor de ATOs algébricos e da correspondente prototipação em OBJ3. Estas especificações foram validadas no ambiente OBJ3 e logo implementadas no ambiente PROSOFT. Em [10] encontra-se toda especificação formal e sua correspondente validação. As implementações estão disponíveis em prosoft. 3. Ferramenta ProTool Na fase de análise do desenvolvimento de software, o problema a ser solucionado é dividido em partes menores para facilitar sua resolução. No PROSOFT, o desenvolvedor é incentivado a modularizar a formalização, ou seja, a especificação do software pode conter diversos ATOs, cada qual solucionando um problema específico. algebraic PROSOFT Software requirements create classes 1 classes specifier ProTool Java create operations 2 algebraic ATOs translation rules specifier ProTool Java translate to OBJ 3 objects PROSOFT types in OBJ terms to be reduced ProTool Java reduce terms in OBJ3 4 resulting terms OBJ3 Specification (ProTool) Prototyping (OBJ3) Figura 2: Utilização do ProTool no desenvolvimento de ATOs algébricos O diagrama SADT da Figura 2 ilustra o caso geral de utilização do ProTool na construção de ATOs algébricos. A entrada da Atividade 1 consiste nos requisitos do software em desenvolvimento. Tais requisitos são utilizados somente para guiar o especificador na tarefa de criação das classes dos ATOs que formalizam o software, pois este processo não é automatizado pelo ProTool. Seguindo a estratégia data-driven 3 do PROSOFT, na Atividade 2 são definidas as operações que atuam sobre as classes. Logo, como saída se tem os ATOs algébricos que formalizam o software. Na Atividade 3, os ATOs construídos podem ser prototipados em OBJ, para fins de validação. A Atividade 4 ilustra o processo de redução de termos no ambiente OBJ3, onde com os resultados 3 A estratégia data-driven determina que para encontrar a solução do problema, as estruturas de dados devem ser definidas antes das operações [8]. 39

49 das formas normais, o desenvolvedor tem recursos para verificar se o que ele especificou atende realmente aos requisitos do software. Em [10] foi proposto um exemplo completo que abrange toda especificação, prototipação e validação de um sistema de vídeo locadora. A seguir são mostradas as principais funcionalidades da ferramenta ProTool de acordo com a Figura 2 e o exemplo da vídeo locadora Criação de Classes A Figura 3 mostra uma classe onde o TAD principal é um registro nomeado Media. A Figura 4 ilustra o mesmo TAD Media segundo a notação textual do OBJ. A notação visual do PROSOFT possibilita construir TADs através de um procedimento muito mais simples que o da notação textual. Em [10] são mostrados vários exemplos reais de TADs complexos em notação textual, que na notação visual do PROSOFT são muito mais fáceis de serem criados, entendidos e mantidos. Figura 3: Edição da classe Media Figura 4: Classe Media em notação textual 3.2. Edição de Interfaces de Operações sobre a Classe Para acrescentar as operações algébricas que atuam sobre a classe do ATO optou-se por definir uma estratégia de montagem de operações. Esta restringe o usuário a montar o ATO usando somente o que já foi definido anteriormente. Como ganho imediato, a probabilidade do usuário cometer erros sintáticos nesta estratégia é reduzida em relação aos editores de texto fornecidos por muitas ferramentas de especificação formal. A parte superior da Figura 5 mostra a lista atual de interfaces de operações, enquanto que a parte inferior mostra a edição da operação include-track, onde os sorts dos argumentos (Media e Track) e o sort resultante (Media) da operação são inseridos. 40

50 Figura 5: Edição de interfaces 3.3. Edição de Axiomas A edição de axiomas também utiliza a estratégia de montagem através da seleção de termos sobre os sorts especificados anteriormente nas classes, como ilustrado na Figura 6. Para definir a semântica de uma operação, seleciona-se a operação desejada entre as declaradas previamente na interface (parte superior da Figura 6). Os passos seguintes consistem em definir os termos do lado esquerdo e direito do axioma através de uma estrutura de árvore (parte inferior da Figura 6) Representações Textuais Figura 6: Edição dos axiomas A qualquer momento, o usuário pode visualizar a especificação textual dos ATOs algébricos e salvá-los em arquivo texto formatado. A prototipação em OBJ também pode ser solicitada a qualquer momento, visto que o processo é automático. Os arquivos OBJ podem ser tanto visualizados quanto salvos em arquivo Uso do Ambiente OBJ3 para Validação dos ATOs Algébricos A execução dos protótipos dos ATOs algébricos segue conforme a Atividade 4 da Figura 2, onde os objetos OBJ, criados a partir dos ATOs algébricos, devem ser carregados no ambiente OBJ3. Na seqüência, o desenvolvedor pode realizar reduções de termos algébricos sobre estes objetos. O termo de entrada é reduzido até o ponto que todas operações foram completamente computadas. Logo, o usuário tem a possibilidade de validar se o que ele especificou é realmente uma solução para o problema que está sendo resolvido. Maiores detalhes de como proceder estas reduções, assim como vários exemplos, podem ser encontrados em [10]. Por meio deste recurso de prototipação o usuário do ProTool é capaz de experimentar e validar seus TADs por execução. 41

51 4. Conclusões e Trabalhos Futuros Os estudos de caso realizados em [10] serviram para mostrar que um TAD complexo é construído com menos esforço e mais rapidez através da notação gráfica. Muitos TADs complexos foram propostos e especificados em PROSOFT algébrico e OBJ (somente texto). Para criar o mesmo TAD notou-se que no PROSOFT o processo era muito mais intuitivo, pois o especificador ficava livre da complexa notação e podia focar-se mais no problema a ser solucionado. Constatou-se também que o ProTool facilita muito tanto o entendimento real do problema a ser solucionado quanto a descoberta de erros na especificação. Além disto, em especificações grandes, módulos podem ser combinados e melhor interpretados através da notação gráfica fornecida pela ferramenta. A prototipação é relevante pois uma especificação pode capturar erroneamente os requisitos dos usuários. Logo, através da execução é mais fácil detectar tais falhas e corrigí-las logo no início do desenvolvimento. Com auxílio do ProTool, TADs complexos foram criados e prototipados em OBJ com mais rapidez e facilidade que somente em OBJ. A estratégia de montagem dos axiomas também mostrou-se muito útil para melhor entender termos algébricos muito grandes. Como trabalho futuro propõe-se integrar ao ProTool o conceito de termos visuais, como o proposto em [2]. Com isto os benefícios da classe gráfica dos ATOs algébricos são combinandos com termos visuais, tornando a especificação algébrica mais fácil de ser construída e interpretada. Referências [1] E. Astesiano, M. Bidoit, H. Kirchner, B. Krieg-Brückner, P. Mosses, D. Sannella, and A. Tarlecki. Casl: The common algebraic specification language. Theoretical Computer Science, 286(2): , September [2] R. Bardohl and I. Clasen. Graphical support for prototyping of algebraic specifications. In Proc. GI Jahrestagung, pages 19 26, Hamburg, [S.l.]: Springer-Verlag. [3] B. Boehm. Software Engineering Economics. Prentice Hall, Englewood Cliffs, [4] A. M. Davis. Software Requirements: Objects, Functions and States. Prentice Hall, Englewood Cliffs, [5] C. George. The raise specification language: A tutorial. In Springer-Verlag, editor, Proceedings of VDM, volume 551 of Lecture Notes in Computer Science, pages , [6] J. Goguen et al. Introducing OBJ. In J. Goguen, editor, Applications of Algebraic Specification using OBJ. Kluwer, [7] J.V. Guttag and J.J Horning. Larch: Languages and Tools for Formal Specification. Springer-Verlag, New York, [8] D. J. Nunes. Estratégia data-driven no desenvolvimento de software. In SIMPÓSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE, 6., volume 1, pages 81 85, Gramado, Porto Alegre: Instituto de Informática da UFRGS. [9] D. J. Nunes. Prosoft: Descrição do ambiente, Relatório de Pesquisa. PPGC- UFRGS, Porto Alegre. [10] G.S. Rangel. Protool: uma ferramenta de prototipação de software para o ambiente prosoft. Master s thesis, Instituto de Informática, UFRGS, Porto Alegre,

52 C&L: Um Ambiente para Edição e Visualização de Cenários e Léxicos Carolina Howard Felicíssimo, Julio Cesar Sampaio do Prado Leite, Karin Koogan Breitman, Lyrene Fernandes da Silva Departamento de Informática Pontifícia Universidade Católica do Rio de Janeiro, PUC-RIO Rua Marquês de São Vicente, 225, CEP: , Rio de Janeiro RJ Brasil {cfelicissimo, karin, lyrene}@inf.puc-rio.br, Abstract. Scenario is a description technique that has been used for some time. This technique helps the understanding of a specific situation of a software application, with focus in its behavior. The process of scenario construction is related with the Language Extended Lexicon (LEL) existence, where your terms give the denotation and connotation of the terms of the application. Many approaches for the scenario representation are known, including informal and formals approaches. The C&L tool is presented in this paper. It is based on one representation that helps the comprehension with the use of natural language and forces the organization of the information with a well defined structure. The tool is created using the ideas from the development of open source community and its target public is the software engineering students and people interested in requirements engineering area. Resumo. Cenário é uma técnica de descrição que vem sendo utilizado por algum tempo. Esta técnica auxilia o entendimento de uma situação específica de uma aplicação de software, priorizando o seu comportamento. O processo de construção de cenários está relacionado à existência do Léxico Ampliado da Linguagem (LAL), onde seus termos expressam a denotação e a conotação dos conceitos da aplicação. Existem várias propostas para a representação de cenários, desde a mais informal até representações formais. A ferramenta C&L, apresentada neste artigo, baseia-se em uma representação que, ao mesmo tempo em que facilita a compreensão através da utilização de linguagem natural, força a organização da informação através de uma estrutura bem definida. A ferramenta foi criada nos moldes da filosofia de desenvolvimento de software livre e tem como público alvo o engenheiro de software, estudantes e interessados na área de requisitos. 1. Introdução Para cenários e léxicos serem efetivamente utilizados, faz-se necessário o uso de boas ferramentas de edição, visualização, gerenciamento e integração com outros softwares, para ganho de produtividade. O C&L (Cenários e Léxicos) é um ambiente colaborativo que auxilia a edição de cenários e léxicos descritos em linguagem natural semi-estruturada. Seu público alvo é principalmente o engenheiro de software; estudantes e interessados na área de requisitos 43

53 também terão ganho de produtividade nas tarefas de edição e visualização de informações. Mesmo aqueles que não são familiarizados com as técnicas de Cenários e Léxico Ampliado da Linguagem podem utilizar, facilmente, o ambiente com seus formulários intuitivos que recebem e estruturam suas informações automaticamente. O desenvolvimento do C&L é baseado na filosofia de software livre. Desta maneira, todo seu código-fonte é disponibilizado livremente para quem se interessar e esperam-se contribuições e sugestões construtivas com seu uso. Apenas softwares gratuitos são utilizados em sua implementação. A versão atual é a evolução da versão desenvolvida por graduandos do curso de Engenharia de Computação da PUC-Rio como trabalho final de uma disciplina. Neste trabalho, o sistema C&L é apresentado na visão da engenharia de requisitos. A Seção 2 explica, brevemente, os conceitos de léxicos e cenários que fundamentam a implementação do C&L. O C&L é apresentado na Seção 3. Na Seção 4, seu funcionamento é descrito em linhas gerais. Na Seção 5, a filosofia de desenvolvimento é ilustrada. Os trabalhos em andamento são citados na Seção 6 e, por fim, a conclusão do trabalho é dada na Seção Cenários e Léxico Entende-se por cenários a descrição de situações comuns ao cotidiano [12]. Os cenários devem levar em conta aspectos de usabilidade e permitir o aprofundamento do conhecimento do problema, a unificação de critérios, a obtenção do compromisso de clientes e/ou usuários, a organização de detalhes e o treinamento de pessoas [2]. Cada cenário descreve, através de linguagem natural semi-estruturada, uma situação específica de uma aplicação de software, priorizando seu comportamento. Cenários podem ser detalhados e utilizados como desenho de maneira a auxiliar a programação. Existem várias propostas para a representação de cenários, desde a mais informal em texto livre [2] até representações formais [4]. O processo de construção de cenários está relacionado à existência do Léxico Ampliado da Linguagem (LAL). O LAL é a implementação de conceitos de semiótica num hipergrafo [5], onde tanto a denotação quanto a conotação são expressas para cada símbolo do léxico. Estas descrições seguem o princípio da circularidade e o princípio do vocabulário mínimo. O princípio da circularidade faz com que cada descrição de denotação ou conotação faça referência a outros símbolos da linguagem. As partes da descrição que não são símbolos devem ser de um subconjunto reduzido de palavras com significado bem definido seguindo, assim, o princípio do vocabulário mínimo. Os termos utilizados no LAL são descritos de maneira a retratar dois aspectos: a noção, i.e., denotação e o impacto, i.e., conotação. A noção representa o significado do termo e o impacto representa como o termo exerce influência no contexto onde está inserido. O LAL também permite que cada termo do vocabulário mínimo tenha um ou mais sinônimos. Cada sinônimo de um termo tem sua noção e seus impactos iguais, respectivamente, à noção e aos impactos de seu termo sinônimo, mas são nomeados diferentemente. 44

54 3. O C&L O C&L é um sistema de software que utiliza uma representação intermediária de cenários. Esta representação tanto facilita a compreensão, através da utilização de linguagem natural, quanto obriga a organização de sua informação através de uma estrutura bem definida. Esta estrutura é composta por elementos descritivos que expressam: o objetivo, o contexto, os recursos, os atores, os episódios, i.e., as ações, e as exceções que ocorrem nestas atividades. O conjunto destas características representa uma situação. Além destas características, a representação também reserva um atributo, restrições que podem ser utilizadas em seu contexto, recursos e episódios para refletir aspectos não-funcionais. O sistema tem como objetivo criar um ambiente colaborativo para criação, edição, manutenção, evolução e gerência dos léxicos e cenários do domínio de aplicação. As informações são disponibilizadas em linguagem natural semi-estruturada e organizadas de forma simples e rápida para seu acesso. A seguir, apresentamos o funcionamento do C&L. 4. Funcionamento O C&L é um sistema Web gratuito que encontra-se disponível no seguinte endereço eletrônico: Para acessá-lo, basta visitar este endereço com um navegador padrão e criar um cadastro. Após a validação de usuário e senha, pode-se adicionar um novo projeto ou continuar a edição de um já existente. Ao criar um novo projeto, o usuário será automaticamente o administrador deste e, com isto, poderá incluir novos usuários no projeto. A ferramenta implementa os seguintes dois níveis de acesso ao sistema: nível de usuário e de administrador. Somente o administrador e os usuários participantes de um projeto podem visualizar, criar, alterar e remover termos do léxico e dos cenários de um projeto. No entanto, as operações de edição em um projeto por seus usuários precisam ser aprovadas por seu administrador antes de serem disponibilizadas no sistema, i.e., efetivadas. As seguintes funcionalidades exclusivas do administrador de projeto são citadas: remover o projeto, verificar os pedidos de alteração de seus cenários e de seus termos do léxico, adicionar seus novos usuários e gerar e recuperar a versão do projeto escrita tanto na linguagem XML [13] quanto na linguagem DAML+OIL [14]. A ferramenta implementa a natureza de hipergrafo do léxico através da criação de links, i.e., atalhos, entre os termos tanto descritos no léxico quanto os descritos nos cenários. Esses links são criados automaticamente quando os termos já cadastrados no projeto são referenciados. Assim, a facilidade de navegabilidade entre os termos de domínio permite a melhor compreensão de seus relacionamentos. A Figura 1 ilustra as informações do domínio de uma aplicação exemplo sobre Administradora de Imóveis no C&L. O atalho criado na descrição da noção do termo administradora para o termo seguradora é evidenciado. Outros termos do domínio podem ser reconhecidos na árvore com os termos do LAL, esta também evidenciada na figura. 45

55 Atalho para o termo Seguradora Árvore com os termos do LAL Figura 1. Exemplo de visualização de um termo do LAL no C&L Além das informações de nome, noção, impactos e sinônimos de um termo, são disponibilizadas, na parte inferior central do ambiente, também as informações dos cenários e dos termos do léxico que fazem referência ao termo corrente. A arquitetura modular do C&L prevê a adição de novos plug-ins no ambiente. Um exemplo é o plug-in de ontologias, explicado em [15], que fornece apoio semiautomático à geração de ontologias tendo como base o Léxico Ampliado da Linguagem (LAL) e o processo definido em [7]. As funcionalidades dos plug-ins no C&L são disponibilizas de forma transparente, ou seja, como se fossem funcionalidades nativas do sistema. A tabela 1 resume as atuais funcionalidades do C&L. Tabela 1. Funcionalidades oferecidas pela ferramenta C&L Funcionalidades Gerais: - Criar projetos e seus administradores; - Cadastrar usuários em projetos; - Verificar e aprovar ou rejeitar pedidos de alterações em cenários; - Verificar e aprovar ou rejeitar pedidos de alterações em termos de léxicos; - Verificar e aprovar ou rejeitar pedidos de alterações em conceitos; - Verificar e aprovar ou rejeitar pedidos de alterações em relações; - Gerar ontologias de projetos. Funcionalidades de edição do LAL: - Edição: criar, alterar ou remover; - Marcação automática de termos do LAL, de seus sinônimos e de nomes de seus cenários; - Verificação de consistência em conseqüência de remoções de termos. Funcionalidades de edição dos Cenários: - Edição: criar, alterar ou remover; - Marcação automática de termos do LAL, de seus sinônimos e de nomes de seus cenários; - Verificação de consistência em conseqüência de remoções de cenários. Funcionalidades de Entradas e Saídas: - Gerar e recuperar XML de projetos; - Gerar e visualizar históricos em DAML+OIL de ontologias de projetos. 46

56 É possível representar todas as informações de um projeto criado no C&L em um arquivo, gerado automaticamente, no formato XML. Este arquivo pode ser criado tanto com ou sem uma formatação específica. Esta formatação é definida por um arquivo XSL que apresenta o arquivo XML com um layout pré-definido. O arquivo sem formatação não usa layout algum. Uma vez criado o arquivo XML de um projeto, este ficará disponível para todos os usuários do sistema. Além das funcionalidades apresentadas na Tabela 1, o C&L ainda possui um sistema de ajuda que pode ser acessado, a qualquer momento, pelo clique no link titulado Ajuda, localizado no canto superior direito da interface do sistema. Este sistema de ajuda é inspirado nos sistemas de ajuda disponibilizados pelos aplicativos Microsoft. As funcionalidades e ações mais comuns do C&L são listadas alfabeticamente por um pequeno sistema de hipertexto. 5. Filosofia de desenvolvimento O C&L é um exemplo de projeto de software livre que vem sendo evoluído por um grupo de estudantes graduandos, mestrandos e doutorandos do Departamento de Informática da PUC-Rio. Projetos desenvolvidos segundo a filosofia de software livre disponibilizam seus sistemas gratuitamente e colocam à disposição todos seus códigosfonte gerados para que estes possam ser distribuídos e alterados livremente. Este tipo de software ganhou muita exposição com projetos como o Linux e Apache, mas a comunidade de software livre não se restringe de maneira alguma a apenas estes dois nomes. Existem diversos outros projetos famosos como o Mozilla, Jboss ou mesmo o CVS e também milhares de outros que não tem a mesma divulgação, mas nem por isso perdem em qualidade para seus concorrentes comerciais. Atualmente existem muitos projetos de software livre em andamento, dos quais diversos possuem um nível de sucesso igual ou mesmo superior ao de seus equivalentes comerciais [8] e [9]. Todo o C&L é desenvolvido e disponibilizado utilizando software livre. A linguagem PHP [11] é sua linguagem de implementação. O banco de dados escolhido para armazenar suas informações é o MySQL [10]. O software para seu servidor Web é o Apache [1]. O software CVS [3] é o responsável pelo controle de versão e gerenciamento de seus arquivos. 6. Trabalhos Futuros O C&L continua em evolução. Estão previstas as seguintes novas implementações: tornar públicas as informações de cenários e léxicos para possibilitar seu reuso por integrantes de outros projetos; organizar o LAL no C&L de acordo com suas divisões: sujeito, objeto, verbo e estado; atualizar a geração de arquivos do plug-in de ontologias da linguagem DAML+OIL para a linguagem OWL; permitir mais de um administrador por projeto e diferentes níveis de permissão; disponibilizar mecanismos de comunicação entre os usuários de um mesmo projeto e entre os administradores de projetos diferentes como chat, envio de , entre outros; permitir a recuperação da versão de um projeto com base no seu XML gerado em um determinado momento; e, disponibilizar mecanismos para inspeção de cenários e léxico editados. 47

57 7. Conclusão Acredita-se que no mercado não exista, atualmente, uma ferramenta de software livre que trate da edição de cenários e léxicos de acordo com suas regras [6]. Desta maneira, o engenheiro de software é obrigado a usar ferramentas mais genéricas e não tão indicadas para a tarefa, como é o caso de um editor de textos. O C&L preenche esta lacuna oferecendo um ambiente diferenciado de edição. O sistema vem sendo utilizado e evoluído, principalmente, pela turma de Princípio de Engenharia de Software do curso de Engenharia de Computação da PUC- Rio. Seus resultados são positivos e, por isso, sua evolução continua. Referências 1. The Apache Software Foundation, disponível em: acesso em Maio de Carroll, J.; Alpert, S.; Karat, J.; Van Deusen, M.; Rosson, M. Raison d'etre: Capturing design history and rationale in multimedia narratives. Human Factors in Computing Systems (CHI94). Proceedings. Boston, USA: ACM Press, pp Concurrent Versions System, disponível em: acesso em Maio de Hsia, P.et al: Formal Approach to Scenario Analysis. IEEE Software, vol. 11 no. 2, pp Leite, J.C.S.P., Franco, A.P.M.: A Strategy for Conceptual Model Acquisition. First International Symposium on Requirements Engineering. Proceedings. IEEE Computer Society Press, pp Leite, J.C.S.P., Hadad, G.D.S., Doorn, J.H., Kaplan, G.N.: A Scenario Construction Process, Requirements Engineering Journal, Vol.5, N 1, 2000, pp Breitman, K.K., Leite, J.C.S.P.: Ontology as a Requirements Engineering Product, Proceedings of the International Conference on Requirements Engineering, IEEE Computer Society Press, Godfrey, M.W., Tu, Q.: Evolution in Open Source Software: A Case Study. ICSM Mockus, A., Fielding, R.T., Herbsleb, J.D.: Two Case Studies of Open Source Software Development: Apache and Mozilla. Transactions on Software Engineering and Methodology, Vol. 11, No. 3, Julho de 2002, Páginas MySQL, disponível em: acesso em Maio de PHP: Hypertext Preprocessor, disponível em: acesso em Maio de Zorman, L.: Requirements Envisaging through utilizing scenarios. REBUS Dissertação de Doutorado da University of Southern California. 13. Bray, T, Paoli, J., Sperberg-McQueen, C. M., Maler, E., Yergeau, F.: A linguagem XML, disponível em: acesso em Maio de A linguagem DAML+OIL, disponível em: acesso em Maio de Felicíssimo, C.H., Silva, L.F., Breitman, K.K., Leite, J.C.S.P.: Geração de Ontologias subsidiada pela Engenharia de Requisitos. Workshop em Engenharia de Requisitos, São Paulo, Brasil,

58 C-CORE Component Construction and Reuse Ferramenta para Desenvolvimento de Software Baseado em Componentes Raphael Marcilio de Souza Neto, João Ronaldo Del Ducca Cunha, Antonio Francisco do Prado, Adriano A. Bossonaro UFSCar - Universidade Federal de São Carlos, Dept. de Computação Rd. Washington Luís, Km 235, São Carlos SP, Brasil [raphael, jronaldo, prado, bossonaro]@dc.ufscar.br Alexandre Marcilio de Souza, João Marcilio de Souza Junior, Iolanda C. S. Catarino UNOPAR Universidade Norte do Paraná, Dept. de Computação Rua Tietê, 1208, Londrina PR, Brasil [alex_marcilio, joão_marcilio, iolanda]@unopar.br Resumo Este artigo apresenta uma ferramenta RAD para o Desenvolvimento de Software Baseado em Componentes denominada C-CORE. Na C-CORE o desenvolvimento de software é dividido em duas fases. Na primeira fase são desenvolvidos os componentes de um domínio de problema, organizados em frameworks para facilitar o reuso. Na segunda fase são desenvolvidas as aplicações que reusam estes componentes, a partir dos frameworks. A ferramenta C-CORE está integrada com a ferramenta MVCASE, possibilitando que se faça a modelagem dos componentes e aplicações, antes das suas implementações. Abstract This paper presents a RAD tool for the Component-Based Software Development, called C-CORE. In the C- CORE the software development is divided in two phases. In the first phase the components of a problem domain are developed, organized in frameworks to facilite the reuse. In the second phase the application that reuses these components is developed, starting from the frameworks. C-CORE is integrated with MVCASE tool, allowing to create models of components and applications prior to their implementations. 1. Introdução Nos últimos anos tem sido grande o esforço da comunidade e pesquisadores da área desenvolvimento de software, para produzir software com qualidade, baixo custo, no menor prazo, e que esteja atualizado para as modernas plataformas de hardware e software. Uma das ferramentas de apoio ao Processo de Desenvolvimento de Software [11] que disputa a atenção dos projetistas de software são as ferramentas RAD (Rapid Application Development). Ambientes centrados em RAD têm uma abordagem de criação rápida de aplicativos através do reuso de componentes de software. No domínio GUI (Graphical User Interface), as ferramentas RAD possibilitam o desenvolvimento rápido de interfaces gráficas, através do reuso de componentes, com geração automática de código. Em outras áreas, como Banco de Dados e Web, as ferramentas RAD disponibilizam componentes e recursos que facilitam o reuso desses componentes no desenvolvimento das aplicações. O reuso de componentes de software aumenta a produtividade e oferece mais segurança, considerando que os mesmos já foram previamente testados. A experiência e a funcionalidade embutida nos componentes minimiza linhas de código reduzindo o número de erros de programação. 49

59 Motivados por estas idéias de Desenvolvimento de Software Baseado em Componentes (DBC), construiu-se a ferramenta RAD, denominada C-CORE Component Construction and Reuse, que suporta o desenvolvimento de componentes de um Domínio de Problema e suas aplicações, através de recursos textuais e gráficos. Na seção 2 deste artigo apresenta-se uma visão geral da C-CORE com suas principais funcionalidades. Na seção 3 apresenta-se o Processo de Desenvolvimento na C- CORE. Na seção 4 têm-se os trabalhos relacionados. Finalmente, na seção 5, apresentamse as conclusões deste artigo. 2. Visão geral da ferramenta C-CORE A C-CORE é uma ferramenta centrada na linguagem de programação Java. Os requisitos para ferramenta foram identificados a partir de estudos sobre as ferramentas JBuilder [2] e NetBeans [8], Eclipse [3], e outras. Os seguintes recursos foram incluídos na C-CORE, com base nestes estudos e também nas experiências com o DBC[9, 5, 6]: Um Construtor Visual de Interface com o Usuário: que permite criar visualmente aplicações de forma rápida através da seleção de componentes na paleta; Uma Arquitetura Baseada em Componentes e Aberta: que assegura que as aplicações sejam robustas, reuso e de fácil manutenção, e que permite adicionar componentes e ferramentas personalizadas e de terceiros; Um Gerador de código: que inicialmente tem Java como linguagem de implementação Um Compilador de Código: que gera código byte-code através de chamadas ao Java2 SDK; Uma Biblioteca de Componentes Visuais: a Visual Component Library (VCL) que consiste de objetos reusáveis incluindo objetos padrões de interface com o usuário, gerenciamento de dados, gráficos, e multimídia, gerenciamento de arquivos e quadros de diálogos padrões; Um Suporte à Tecnologia do Windows: que é compatível com a tecnologia Windows, incluindo suporte a ODBC, e outros recursos através de APIs; Um Depurador Gráfico: que auxilie a encontrar e eliminar "bugs" no código; Um Suporte para construir e importar Frameworks de componentes: inicialmente para componentes com as arquiteturas JavaBeans [12] e Enterprise JavaBeans [12]. Alguns frameworks já fazem parte do núcleo básico da C-CORE, como os de componentes para WEB, Servlet [12], e de outros domínios básicos nas áreas de GUI, acesso a banco de dados, e outras; Uma Interação com a MVCASE [7]: a C-CORE interage com a MVCASE para modelagem da aplicação. Os modelos devem ser consistentes com as implementações na C-CORE, e vice-versa; Configuração Visual: que permite ao engenheiro de software configurar elementos visuais de forma que lhe seja útil e agradável. As configurações basicamente lidam com as cores e textos que fazem parte da ferramenta. 3. Desenvolvimento de Software baseado em Componentes na C-CORE O Processo de Desenvolvimento de Software Baseado em componentes na C- CORE é dividido em duas fases, Desenvolver Componentes e Desenvolver Aplicações, descritas com mais detalhes a seguir. 50

60 3.1. Desenvolver Componentes Na primeira fase do processo de desenvolvimento, são construídos os componentes de um domínio. Nesta fase, três níveis de abstração são usados para o desenvolvimento dos componentes, podendo ser usadas em conjunto: Design View, Source View e Modelling View. Estas visões podem ser usadas em conjunto, tornando o desenvolvimento de componentes mais interativo e permitindo que engenheiros de software, com diferentes conhecimentos em DBC, possam realizar seu trabalho com melhor qualidade e maior produtividade. No modo Source View (Figura 1), o Engenheiro de Software constrói componentes interagindo com um editor de texto, no qual o código do componente é escrito diretamente na linguagem Java. O Editor possui recursos de orientação à sintaxe, no caso da linguagem Java, e outros como, por exemplo, highlight, que permite destacar palavras reservadas. Figura 1 Source View O modo Source View pode ser usado em conjunto com o modo Modelling View (Figura 2), pois a C-CORE salva as especificações dos componentes em um arquivo XMI[10], o qual também é usado por ferramentas de Modelagem, como no caso da MVCASE. Dessa forma, pode-se alternar entre os diferentes níveis de abstração, que vão desde a modelagem até a implementação. A adoção de XMI visa principalmente integrar a C-CORE com outras ferramentas existentes no grupo de engenharia de software do DC- UFSCar, como a MVCASE, e outra ferramenta em desenvolvimento como a SocManager, que trata do Gerenciamento de Configuração do Software. Na Figura 2, por exemplo, temse uma visão do modelo do componente cujo código foi mostrado na Figura 1. Figura 2 Modelling View No modo Design View (Figura 3), o Engenheiro de Software constrói o componente de forma interativa, reusando interativamente componentes, que já foram construídos. A composição básica da C-CORE já inclui componentes para os domínios de GUI e de acesso a banco de dados. À medida que novos componentes são construídos estes podem 51

61 ser disponibilizados para reuso. O Object Inspector permite o refinamento do componente, através da interação direta do Engenheiro de Software, nas suas propriedades e eventos. Nesse modo ainda, a C-CORE gera código automático para o componente, acessível no modo Source View. Esse código pode ser complementado conforme as necessidades específicas do componente, como por exemplo, no detalhamento do comportamento de um método. Figura 3 Design View Uma vez construídos, os componentes do domínio são organizados em frameworks, que podem ser reusados na segunda fase do processo de desenvolvimento para construir diferentes aplicações. Para tanto, importam-se os frameworks na ferramenta C-CORE, e dependendo da tecnologia usada na construção dos componentes, como no caso de JavaBeans, faz-se o deployment dos mesmos, disponibilizando-os em paletas, organizadas segundo seus domínios. Componentes construídos com outras tecnologias, como no caso de EJB[12], ficam disponíveis em bibliotecas, que são importadas diretamente pelas aplicações. A Figura 4 mostra, por exemplo, uma paleta de componentes JavaBeans do domínio Multimídia, disponíveis para reuso. Figura 4 Componentes do Domínio Multimídia disponível na C-CORE 3.2. Desenvolver Aplicações Nesta fase o Engenheiro de Software desenvolve as aplicações do domínio, cujos componentes estão disponíveis na C-CORE. A C-CORE possui um gerenciador que controla os artefatos de um projeto de uma aplicação, incluindo o código gerado e suas representações gráficas. Todas as informações de um projeto são armazenadas em XMI, permitindo o compartilhamento com demais ferramentas que ofereçam suporte nesta linguagem. A Figura 5 mostra uma aplicação sendo desenvolvida na C-CORE, reusando componentes disponíveis nas paletas. No caso de componentes JavaBeans, o Engenheiro de Software seleciona o componente na paleta, e numa operação drag and drop, adiciona-o na aplicação. No caso de componente EJB, basta definir a diretriz import na aplicação informando o nome do componente e seu pacote. A ajuda semântica para seleção do componente pode ser obtida no framework de modelos que documenta os componentes e está disponível na ferramenta MVCASE integrada com a C-CORE. Nessa etapa de desenvolvimento, a C-CORE auxilia principalmente oferecendo suporte aos requisitos não funcionais, como por exemplo, o desenvolvimento de interfaces gráficas e o tratamento de 52

62 erros. No caso, o Engenheiro de Software reusa componentes do domínio GUI e à medida que os mesmos são selecionados na aplicação, a C-CORE gera o respectivo código. Podese também através do object inspector interagir nas propriedades e eventos dos componentes selecionados que podem ser alterados em tempo de design e em tempo de execução através de chamadas de métodos. À medida que o engenheiro de software desenvolve o projeto, pode-se de igual modo, como apresentado no desenvolvimento de componentes, alternar entre as diferentes visões, com principal destaque para o Modelling View, com o auxilio da ferramenta MVCASE. Figura 5 Interface Principal da C-CORE com uma aplicação sendo desenvolvida A C-CORE permite ao engenheiro de software além de construir componentes e aplicações, compilar e executar suas aplicações, em plataforma cliente e servidor ou WEB. Este recurso torna o processo de desenvolvimento mais interativo e confiável, pois testes podem ser aplicados como forma de detecção de erros durante o desenvolvimento do software. A ferramenta dispõe ainda de recursos para deployment dos componentes e suas aplicações. 4. Trabalhos Relacionados Com o objetivo de facilitar o processo de desenvolvimento rápido de aplicações, existem outras ferramentas como, por exemplo, JBuilder, NetBeans e Eclipse. O JBuilder é uma ferramenta da Borland, disponibilizado em diferentes versões, para desenvolvimento de aplicações em Java. Possui recursos para a implementação de componentes e aplicações através de wizards (assistentes). Seus principais recursos incluem: visualização dos modelos de classes em UML[1], suporte a tecnologias como, Web Services[4], edição de arquivos XML[13] e fornecimento de componentes e ferramentas para construção de aplicações GUI com acesso a banco de dados. O NetBeans é outra ferramenta de desenvolvimento rápido de aplicações na linguagem Java. Seus principais recursos são: compilação e depuração do código e wizards que permitem construir diferentes aplicações usando, por exemplo, RMI[12] e Applets[12]. A ferramenta Eclipse, também permite o desenvolvimento de software na linguagem Java. Suporta o desenvolvimento e reuso de componentes em aplicações WEB e 53