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

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

Download "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 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, 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, 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 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 (www.eclipse.org). 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 (www.cos.ufrj.br/~odyssey). 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 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 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 1 31

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) 2 Fakultät Informatik, Universität Stuttgart, Germany 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, 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, 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, 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

Ferramenta para instanciação de processos de software que permite o gerenciamento de projetos de desenvolvimento distribuído

Ferramenta para instanciação de processos de software que permite o gerenciamento de projetos de desenvolvimento distribuído Ferramenta para instanciação de processos de software que permite o gerenciamento de projetos de desenvolvimento distribuído Ana Paula Chaves 1, Jocimara Segantini Ferranti 1, Alexandre L Erário 1, Rogério

Leia mais

Table 1. Dados do trabalho

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

Leia mais

Um processo para construção de software mais transparente

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

Leia mais

Palavras-chave: Desenvolvimento Baseado em Componentes (DBC), Transformação de Software, framework e ObjectPascal.

Palavras-chave: Desenvolvimento Baseado em Componentes (DBC), Transformação de Software, framework e ObjectPascal. Construção e Reutilização de de Software do Domínio de Cardiologia João L C Moraes, Daniel Lucrédio, Adriano A Bossonaro, Dr Rubens Tofano, Prof Dr Antonio F Prado DC/UFSCar - Departamento de Computação

Leia mais

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

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

Leia mais

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

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

Leia mais

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

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

Leia mais

Requisitos para testes de sistemas de informação baseados na WEB

Requisitos para testes de sistemas de informação baseados na WEB Requisitos para testes de sistemas de informação baseados na WEB Raphael Augusto F. S. de Oliveira 1, Rodolfo F. Resende 1 1 Departamento de Ciência da Computação Universidade Federal de Minas Gerais (UFMG)

Leia mais

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

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

Leia mais

Uma Ontologia Genérica para a Análise de Domínio e Usuário na Engenharia de Domínio Multiagente

Uma Ontologia Genérica para a Análise de Domínio e Usuário na Engenharia de Domínio Multiagente Uma Ontologia Genérica para a Análise de Domínio e Usuário na Engenharia de Domínio Multiagente Carla Gomes de Faria1, Ismênia Ribeiro de Oliveira1, Rosario Girardi1 1Universidade Federal do Maranhão (UFMA)

Leia mais

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

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

Leia mais

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

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

Leia mais

A IMPORTÂNCIA DA ATIVIDADE DE TESTE NO DESENVOLVIMENTO DE SOFTWARE

A IMPORTÂNCIA DA ATIVIDADE DE TESTE NO DESENVOLVIMENTO DE SOFTWARE A IMPORTÂNCIA DA ATIVIDADE DE TESTE NO DESENVOLVIMENTO DE SOFTWARE Karla Pires de Souza (FPM ) karlapsouza@hotmail.com Angelita Moutin Segoria Gasparotto (FPM ) angelita@usp.br A atividade de teste de

Leia mais

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

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

Leia mais

Controle de métricas no processo de desenvolvimento de software através de uma ferramenta de workflow

Controle de métricas no processo de desenvolvimento de software através de uma ferramenta de workflow Controle de métricas no processo de desenvolvimento de software através de uma ferramenta de workflow Gustavo Zanini Kantorski, Marcelo Lopes Kroth Centro de Processamento de Dados Universidade Federal

Leia mais

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

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

Leia mais

ANALISTA DE INFORMÁTICA / SISTEMAS

ANALISTA DE INFORMÁTICA / SISTEMAS EMPRESA MUNICIPAL DE INFORMÁTICA - EMPREL ANALISTA DE INFORMÁTICA / SISTEMAS ALEXANDRE CANTINHO SALSA JUNIOR 900861 30º 60,00 ANA CECILIA VITAL DE ANDRADE, 901526 14º 67,00 ANDRE LUIZ DE OLIVEIRA LOPES

Leia mais

I Workhop Brasileiro de Tecnologias para Colaboração WCSCW

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

Leia mais

RESULTADOS. Nome Global ( /100) PT1840719 ADÃO AZEVEDO MALHEIRO MATOS BARBOSA 94 B1 PT1840720 ADRIANA MORAIS SOUSA 52 A1

RESULTADOS. Nome Global ( /100) PT1840719 ADÃO AZEVEDO MALHEIRO MATOS BARBOSA 94 B1 PT1840720 ADRIANA MORAIS SOUSA 52 A1 PT1840719 ADÃO AZEVEDO MALHEIRO MATOS BARBOSA 94 B1 PT1840720 ADRIANA MORAIS SOUSA 52 A1 PT1840721 ADRIANA XAVIER DA SILVA FERNANDES 38 Pré-A1 PT1840722 ALEXANDRA FILIPA AZEVEDO SANTOS 52 A1 PT1840723

Leia mais

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

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

Leia mais

Aplicação da ISO/IEC TR 15504 na Melhoria do Processo de Desenvolvimento de Software de uma Pequena Empresa

Aplicação da ISO/IEC TR 15504 na Melhoria do Processo de Desenvolvimento de Software de uma Pequena Empresa Aplicação da ISO/IEC TR 15504 na Melhoria do Processo de Desenvolvimento de Software de uma Pequena Empresa Odair Jacinto da Silva 1, Carlos Alberto Borges 1, Clênio Sampaio Salviano 2, Adalberto N. Crespo

Leia mais

EProcessos: Um Sistema para Edição de Processos de Software

EProcessos: Um Sistema para Edição de Processos de Software Universidade Federal de Ouro Preto - UFOP Instituto de Ciencias Exatas e Biologicas - ICEB Departamento de Computação - DECOM EProcessos: Um Sistema para Edição de Processos de Software Aluno: Sávio Geraldo

Leia mais

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

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

Leia mais

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

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

Leia mais

Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa

Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Dayana Henriques Fonseca 1, Frederico Miranda Coelho 1 1 Departamento de Ciência da Computação Universidade Presidente Antônio Carlos (UNIPAC)

Leia mais

Corrida da Saúde. Infantis A - Feminino

Corrida da Saúde. Infantis A - Feminino Corrida da Saúde Classificação geral do corta-mato, realizado no dia 23 de Dezembro de 2007, na Escola E.B. 2,3 de Valbom. Contou com a participação dos alunos do 4º ano e do 2º e 3º ciclos do Agrupamento

Leia mais

MOR: Uma Ferramenta para o Mapeamento Objeto-Relacional em Java

MOR: Uma Ferramenta para o Mapeamento Objeto-Relacional em Java MOR: Uma Ferramenta para o Mapeamento Objeto-Relacional em Java Leonardo Gresta Paulino Murta Gustavo Olanda Veronese Cláudia Maria Lima Werner {murta, veronese, werner}@cos.ufrj.br COPPE/UFRJ Programa

Leia mais

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS

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

Leia mais

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

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

Leia mais

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

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

Leia mais

ABCTool - Uma Ferramenta para Cooperação Baseada na Arquitetura do Sistema

ABCTool - Uma Ferramenta para Cooperação Baseada na Arquitetura do Sistema ABCTool - Uma Ferramenta para Cooperação Baseada na Arquitetura do Sistema Cynthia Maria Silva de Barros Mestranda do PPGEE-PUC-Minas* cmsbarros@zipmail.com.br Carlos Alberto Marques Pietrobon Professor-Orientador

Leia mais

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

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

Leia mais

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

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

Leia mais

PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS

PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS Élysson Mendes Rezende Bacharelando em Sistemas de Informação Bolsista de Iniciação Científica

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

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

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

Leia mais

4ª Parte Processo de Teste

4ª Parte Processo de Teste 4ª Parte Processo de Teste Atividades de preparação Ø Planejamento: define itens a testar, aspectos gerenciais e recursos necessários; para a execução da bateria de testes. Ø Desenho: completa as especificações

Leia mais

GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código

GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código Igor Steinmacher 1, Éderson Fernando Amorim 1, Flávio Luiz Schiavoni 1, Elisa Hatsue Moriya Huzita 1 1 Departamento de Informática

Leia mais

Unified Modeling Language UML - Notações

Unified Modeling Language UML - Notações Unified Modeling Language UML - Notações Prof. Ms. Elvio Gilberto da Silva elvio@fmr.edu.br UML Ponto de Vista É gerada com propósito geral de uma linguagem de modelagem visual usada para especificar,

Leia mais

O USO DE SOFTWARE PARA CONTROLE DE VERSÕES COMO FERRAMENTA DE APOIO À PRODUÇÃO DE MATERIAIS INSTRUCIONAIS DA EDUCAÇÃO A DISTÂNCIA - EaD

O USO DE SOFTWARE PARA CONTROLE DE VERSÕES COMO FERRAMENTA DE APOIO À PRODUÇÃO DE MATERIAIS INSTRUCIONAIS DA EDUCAÇÃO A DISTÂNCIA - EaD O USO DE SOFTWARE PARA CONTROLE DE VERSÕES COMO FERRAMENTA DE APOIO À PRODUÇÃO DE MATERIAIS INSTRUCIONAIS DA EDUCAÇÃO A DISTÂNCIA - EaD VITÓRIA ES 04 2010 José Mário Costa Junior Ifes - jcjunior@ifes.edu.br

Leia mais

Engenharia de Software I

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

Leia mais

Metodologia para a Adaptação de Processos de Software baseada no Modelo SSE-CMM

Metodologia para a Adaptação de Processos de Software baseada no Modelo SSE-CMM Metodologia para a Adaptação de Processos de Software baseada no Modelo SSE-CMM Rosana Wagner, Lisandra Manzoni Fontoura Programa de Pós-Graduação em Informática (PPGI) Centro de Tecnologia Universidade

Leia mais

ControlPro: Uma Ferramenta de Acompanhamento de Projetos Integrada a um Ambiente de Desenvolvimento de Software

ControlPro: Uma Ferramenta de Acompanhamento de Projetos Integrada a um Ambiente de Desenvolvimento de Software ControlPro: Uma Ferramenta de Acompanhamento de Projetos Integrada a um Ambiente de Desenvolvimento de Software Rodrigo Dal Moro, Julio Cesar Nardi, Ricardo de Almeida Falbo Departamento de Informática

Leia mais

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

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

Leia mais

Teste de Regressão. R. Anido Baseado em notas de aulas da profa. Eliane Martins

Teste de Regressão. R. Anido Baseado em notas de aulas da profa. Eliane Martins Teste de Regressão R. Anido Baseado em notas de aulas da profa. Eliane Martins Testes de Regressão Objetivo Utilização Falhas de regressão Manutenção do conjunto de testes Redução do conjunto de testes

Leia mais

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

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

Leia mais

Processo de Teste de Software

Processo de Teste de Software Processo de Teste de Software Introdução Auri Marcelo Rizzo Vincenzi Gilcimar Divino de Deus Instituto de Informática Universidade Federal de Goiás 22 de agosto de 2008 Organização Teste Desafios do Teste

Leia mais

PADRÕES DE PROJETO E FRAMEWORK NO DESENVOLVIMENTO DE SOFTWARE

PADRÕES DE PROJETO E FRAMEWORK NO DESENVOLVIMENTO DE SOFTWARE PADRÕES DE PROJETO E FRAMEWORK NO DESENVOLVIMENTO DE SOFTWARE Nelson Ribeiro de Carvalho Júnior 1 RESUMO Atualmente o cenário mundial cuja dependência do software está cada vez mais evidente requer que

Leia mais

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

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

Leia mais

Um Simulador para Avaliação da Antecipação de Tarefas em Sistemas Gerenciadores de Workflow

Um Simulador para Avaliação da Antecipação de Tarefas em Sistemas Gerenciadores de Workflow Um Simulador para Avaliação da Antecipação de Tarefas em Sistemas Gerenciadores de Workflow Resumo. A fim de flexibilizar o fluxo de controle e o fluxo de dados em Sistemas Gerenciadores de Workflow (SGWf),

Leia mais

Orientações para o Planejamento e Realização do Projeto Final

Orientações para o Planejamento e Realização do Projeto Final Orientações para o Planejamento e Realização do Projeto Final Simone Diniz Junqueira Barbosa Versão: 1.0.4 Orientações para o Planejamento e Realização do Projeto Final Sumário 1 Introdução... 3 2 Projeto

Leia mais

Gerenciamento de Workflows Científicos em Bioinformática

Gerenciamento de Workflows Científicos em Bioinformática Gerenciamento de Workflows Científicos em Bioinformática Agosto de 2007 Estudante: Orientador: Co-orientadora: Luciano Antonio Digiampietri João Carlos Setubal Claudia Bauzer Medeiros Roteiro Introdução

Leia mais

DESENVOLVENDO APLICAÇÕES WEB UTILIZANDO A FERRAMENTA WEBSCHARTS

DESENVOLVENDO APLICAÇÕES WEB UTILIZANDO A FERRAMENTA WEBSCHARTS UNIVERSIDADE FEDERAL DE MATO GROSSO DO SUL DEPARTAMENTO DE COMPUTAÇÃO E ESTATÍSTICA DESENVOLVENDO APLICAÇÕES WEB UTILIZANDO A FERRAMENTA WEBSCHARTS LÍCIO SÉRGIO FERRAZ DE BRITO MARCELO AUGUSTO SANTOS TURINE

Leia mais

3 OOHDM e SHDM 3.1. OOHDM

3 OOHDM e SHDM 3.1. OOHDM 32 3 OOHDM e SHDM Com a disseminação em massa, desde a década de 80, de ambientes hipertexto e hipermídia, principalmente a Web, foi identificada a necessidade de elaborar métodos que estruturassem de

Leia mais

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr Engenharia de Software Apostila I >>> Introdução à ES - HEngholmJr Histórico de Revisões Data Versão Descrição Autor 12/08/2014 1.0 Criação da primeira versão HEngholmJr Agenda Introdução à Engenharia

Leia mais

Suporte à Engenharia Reversa para o ambiente SEA

Suporte à Engenharia Reversa para o ambiente SEA Otavio Pereira Suporte à Engenharia Reversa para o ambiente SEA Orientador: Ricardo Pereira e Silva Universidade Federal de Santa Catarina - UFSC Departamento de Informática e Estatística - INE Florianópolis

Leia mais

UML - Unified Modeling Language

UML - Unified Modeling Language UML - Unified Modeling Language Casos de Uso Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 24 de abril

Leia mais

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

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

Leia mais

TURMA 10 H. CURSO PROFISSIONAL DE: Técnico de Multimédia RELAÇÃO DE ALUNOS

TURMA 10 H. CURSO PROFISSIONAL DE: Técnico de Multimédia RELAÇÃO DE ALUNOS Técnico de Multimédia 10 H 7536 Alberto Filipe Cardoso Pinto 7566 Ana Isabel Lomar Antunes 7567 Andreia Carine Ferreira Quintela 7537 Bruno Manuel Martins Castro 7538 Bruno Miguel Ferreira Bogas 5859 Bruno

Leia mais

Um Processo de Engenharia de Domínio com foco no Projeto Arquitetural Baseado em Componentes

Um Processo de Engenharia de Domínio com foco no Projeto Arquitetural Baseado em Componentes Um Processo de Engenharia de Domínio com foco no Projeto Arquitetural Baseado em Componentes Ana Paula Blois 1, 2, Karin Becker 2, Cláudia Werner 1 1 COPPE/UFRJ, Universidade Federal do Rio de Janeiro,

Leia mais

Resumo de TCC Desenvolvimento de um sistema ERP com foco nas tecnologias de software livre / código aberto

Resumo de TCC Desenvolvimento de um sistema ERP com foco nas tecnologias de software livre / código aberto UFSC - Universidade Federal de Santa Catarina CTC Centro Tecnológico INE Departamento de Informática e Estatística INE5631 Projetos I Prof. Renato Cislaghi Resumo de TCC Desenvolvimento de um sistema ERP

Leia mais

MARACATU. A component search tool. Especificação, Projeto e Implementação de uma Arquitetura para um Engenho de Busca de Componentes

MARACATU. A component search tool. Especificação, Projeto e Implementação de uma Arquitetura para um Engenho de Busca de Componentes MARACATU A component search tool Especificação, Projeto e Implementação de uma Arquitetura para um Engenho de Busca de Componentes Vinicius Cardoso Garcia July 29, 2005 Agenda Introdução Especificação

Leia mais

No artigo anterior explicamos. Desenvolvimento de Software Dirigido por Caso de Uso. Parte II: Especificando Caso de Uso

No artigo anterior explicamos. Desenvolvimento de Software Dirigido por Caso de Uso. Parte II: Especificando Caso de Uso Desenvolvimento de Software Dirigido por Caso de Uso Parte II: Especificando Caso de Uso Vinicius Lourenço de Sousa viniciuslsousa@gmail.com Atua no ramo de desenvolvimento de software há mais de 10 anos,

Leia mais

WSCAD. Sistemas Computacionais de Alto Desempenho. Pirenópolis - GO - Brasil - 1 O a 1 2 de Setembro. li Workshop em. Organização.

WSCAD. Sistemas Computacionais de Alto Desempenho. Pirenópolis - GO - Brasil - 1 O a 1 2 de Setembro. li Workshop em. Organização. li Workshop em Sistemas Computacionais de Alto Desempenho Pirenópolis - GO - Brasil - 1 O a 1 2 de Setembro WSCAD 2001 Organização ApOIO Universidade de Brasília Anais 11 W orkshop em Sistemas Computacionais

Leia mais

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

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

Leia mais

TEMA: PROJETO INTEGRADOR 2011.2 SISTEMA MICROCONTROLADO DE PROTEÇÃO E ACESSO VEICULAR CURSO: ELETRÔNICA MÓDULO 3 - MANHÃ

TEMA: PROJETO INTEGRADOR 2011.2 SISTEMA MICROCONTROLADO DE PROTEÇÃO E ACESSO VEICULAR CURSO: ELETRÔNICA MÓDULO 3 - MANHÃ : Alexandre Barros de Araújo Jarbas Lucena da Silva Oziel Aires de Queiroz Thiago Pereira da Silva Romário Medeiros Araujo SISTEMA MICROCONTROLADO DE PROTEÇÃO E ACESSO VEICULAR MÓDULO 3 - MANHÃ Edvanilson

Leia mais

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento

Leia mais

18º Congresso de Iniciação Científica IMPLEMENTAÇÃO DE UM MODELO DE TESTE DE APLICAÇÕES WEB

18º Congresso de Iniciação Científica IMPLEMENTAÇÃO DE UM MODELO DE TESTE DE APLICAÇÕES WEB 18º Congresso de Iniciação Científica IMPLEMENTAÇÃO DE UM MODELO DE TESTE DE APLICAÇÕES WEB Autor(es) HARLEI MIGUEL DE ARRUDA LEITE Orientador(es) PLÍNIO ROBERTO SOUZA VILELA Apoio Financeiro PIBIC/CNPQ

Leia mais

EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE

EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE UNIVERSIDADE CATÓLICA DE PELOTAS CENTRO POLITÉCNICO TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE por Miguel Aguiar Barbosa Trabalho de curso II submetido como

Leia mais

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

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

Leia mais

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

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

Leia mais

Unioeste Universidade Estadual do Oeste do Paraná

Unioeste Universidade Estadual do Oeste do Paraná Unioeste Universidade Estadual do Oeste do Paraná CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS Colegiado de Informática Curso de Bacharelado em Informática Especificação de Requisitos e Modelagem Orientada

Leia mais

Ontologia de Domínio da Biodisponibilidade de Ferro: Uma Experiência no Projeto Nutri-Fuzzy-Orixás

Ontologia de Domínio da Biodisponibilidade de Ferro: Uma Experiência no Projeto Nutri-Fuzzy-Orixás Ontologia de Domínio da Biodisponibilidade de Ferro: Uma Experiência no Projeto Nutri-Fuzzy-Orixás Alessandra Brito F. Oliveira 1; Vera Maria Benjamim Werneck 1 ; Regina Serrão Lanzillotti 1 ; Haydée Serrão

Leia mais

1º EXAMINADOR 2º EXAMINADOR 3º EXAMINADOR MÉDIA ESC. X3 MED PON DID. X4 TIT. X2 P.A. X1. - - - - - - - - - - - - - - - - Desclassificado

1º EXAMINADOR 2º EXAMINADOR 3º EXAMINADOR MÉDIA ESC. X3 MED PON DID. X4 TIT. X2 P.A. X1. - - - - - - - - - - - - - - - - Desclassificado PLANILHA DE 01 02 03 04 05 06 07 08 Adeilton Correia de Barros Júnior Aline Lopes Timóteo Ana Paula Carvalho Cavalcanti Furtado Alysson Barros de Morais André Felipe Lemos Audrey Bezerra Vasconcelos Boaz

Leia mais

SEQUÊNCIA LISTA NOMINAL DOS CANDIDATOS APROVADOS 1 MAURO ROBERTO P. DUARTE 2 PAULO RENATO PEDRONI DE ALMEIDA 3 ALEX LOPES LYRIO 4 MARCOS ANDRE MURTA

SEQUÊNCIA LISTA NOMINAL DOS CANDIDATOS APROVADOS 1 MAURO ROBERTO P. DUARTE 2 PAULO RENATO PEDRONI DE ALMEIDA 3 ALEX LOPES LYRIO 4 MARCOS ANDRE MURTA LISTA NOMINAL DOS CANDIDATOS APROVADOS 1 MAURO ROBERTO P. DUARTE 2 PAULO RENATO PEDRONI DE ALMEIDA 3 ALEX LOPES LYRIO 4 MARCOS ANDRE MURTA RIBEIRO 5 ALEXANDRE FERREIRA DE MENEZES 6 ADALBERTO GOMES DA SILVA

Leia mais

PSQT Prêmio SESI Qualidade no Trabalho

PSQT Prêmio SESI Qualidade no Trabalho ANEXO II PSQT Prêmio SESI Qualidade no Trabalho Manutenção Evolutiva Modelo: 4.0 Sistema Indústria, 2008 Página 1 de 18 Histórico da Revisão Data Descrição Autor 06/12/2007 Necessidades para atualização

Leia mais

Relatório sobre a Trilha de CSCW WebMídia 2003 Salvador BA

Relatório sobre a Trilha de CSCW WebMídia 2003 Salvador BA Organização da Trilha: Renata Mendes de Araujo UNIRIO Flávia Maria Santoro UNIRIO Comitê de Avaliação da Trilha: Ana Carolina Salgado UFPE Hugo Fuks PUC-Rio José Valdeni UFRGS - UFRJ Organização Geral

Leia mais

Introdução a INGENIAS:

Introdução a INGENIAS: Universidade do Estado do Rio Grande do Norte UERN Universidade Federal Rural do Semi-Árido UFERSA Mestrado em Ciência da Computação MCC Disciplina: Engenharia de Software Orientada a Agentes Professores:

Leia mais

Avaliando modelos arquiteturais através de um checklist baseado em atributos de qualidade

Avaliando modelos arquiteturais através de um checklist baseado em atributos de qualidade Avaliando modelos arquiteturais através de um checklist baseado em atributos de qualidade Aluno: Rafael Ferreira Barcelos barcelos@cos.ufrj.br Orientador: Guilherme Horta Travassos ght@cos.ufrj.br Nível:

Leia mais

Projeto Final de Engenharia de Computação

Projeto Final de Engenharia de Computação Orientações para Desenvolvimento do Projeto Final de Engenharia de Computação compilado por: Noemi Rodriguez texto baseado em: Orientações para o Planejamento e Realização do Projeto Final, de Simone Barbosa

Leia mais

Transformação de modelos em processos de desenvolvimento de software

Transformação de modelos em processos de desenvolvimento de software 1068 X Salão de Iniciação Científica PUCRS Transformação de modelos em processos de desenvolvimento de software Vinycio de Correa Lunelli 1, Profa. Dra. Ana Paula Terra Bacelo 1 1 Faculdade de Informática,

Leia mais

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA INTRODUÇÃO O projeto de um banco de dados é realizado sob um processo sistemático denominado metodologia de projeto. O processo do

Leia mais

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

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

Leia mais

Processos de Software

Processos de Software Processos de Software Prof. Sandro Bezerra (srbo@ufpa.br) Adaptado a partir de slides produzidos pelo Prof. Dr. Alexandre Vasconcelos 1/27 Processo Ação regular e contínua (ou sucessão de ações) realizada

Leia mais

Estudo de Caso Sistema de Caixa Automático

Estudo de Caso Sistema de Caixa Automático Estudo de Caso Sistema de Caixa Automático Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Notas de Aula Ulrich Schiel Notas de Aula Ariadne

Leia mais

Projeto de Sistemas I

Projeto de Sistemas I Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Projeto de Sistemas I Professora: Kelly de Paula Cunha E-mail:kellypcsoares@ifsp.edu.br Requisitos: base para todo projeto, definindo o

Leia mais

Proposta de uma ferramenta para instanciação de processos de software que permite o gerenciamento de projetos de desenvolvimento distribuído

Proposta de uma ferramenta para instanciação de processos de software que permite o gerenciamento de projetos de desenvolvimento distribuído Proposta de uma ferramenta para instanciação de processos de software que permite o gerenciamento de projetos de desenvolvimento distribuído Ana Paula Chaves, Jocimara Segantini Ferranti, Alexadre L Erário,

Leia mais

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

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

Leia mais

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

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

Leia mais

Documento de Visão. Versão 2.5 Projeto SysTrack - Grupo 01

Documento de Visão. Versão 2.5 Projeto SysTrack - Grupo 01 Documento de Visão Versão 2.5 Projeto SysTrack - Grupo 01 Junho de 2011 Histórico de revisão: DATA VERSÃO DESCRIÇÃO AUTORES 19/02/2011 1.0 Versão inicial. João Ricardo, Diogo Henrique. 24/02/2011 2.0 Modificação

Leia mais

Comunicado Técnico ISSN 1677-8464

Comunicado Técnico ISSN 1677-8464 Ministério da Agricultura, Pecuária e Abastecimento Comunicado Técnico Dezembro, 25 2002 Campinas, SP ISSN 1677-8464 Cobertura de Testes Unitários no SIGI João Francisco Gonçalves Antunes 1 Moacir Pedroso

Leia mais

FATEsC - Uma Ferramenta de apoio ao teste estrutural de componentes

FATEsC - Uma Ferramenta de apoio ao teste estrutural de componentes FATEsC - Uma Ferramenta de apoio ao teste estrutural de componentes Vânia Somaio Teixeira 1,2, Marcio Eduardo Delamaro 1, Auri Marcelo Rizzo Vincenzi 3 1 Programa de Pós-graduação em Ciência da Computação

Leia mais

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

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

Leia mais

LINGUAGEM DE ESPECIFICAÇÃO E DESCRIÇÃO (SDL) APLICADA AO PROCESSO DE VERIFICAÇÃO E VALIDAÇÃO DE SISTEMAS REATIVOS

LINGUAGEM DE ESPECIFICAÇÃO E DESCRIÇÃO (SDL) APLICADA AO PROCESSO DE VERIFICAÇÃO E VALIDAÇÃO DE SISTEMAS REATIVOS LINGUAGEM DE ESPECIFICAÇÃO E DESCRIÇÃO (SDL) APLICADA AO PROCESSO DE VERIFICAÇÃO E VALIDAÇÃO DE SISTEMAS REATIVOS Fabiana Fraga Ferreira Bacharelanda em Sistemas de Informação Bolsista de Iniciação Científica

Leia mais

Conectando Bancos de Dados Microsoft Access no BrOffice.org Base. fornecido pelo Projeto de Documentação do BrOffice.org

Conectando Bancos de Dados Microsoft Access no BrOffice.org Base. fornecido pelo Projeto de Documentação do BrOffice.org Conectando Bancos de Dados Microsoft Access no BrOffice.org Base fornecido pelo Projeto de Documentação do BrOffice.org Índice 1 Introdução...2 1.1 Versão... 2 1.2 Licenciamento...2 1.3 Mensagem do Projeto

Leia mais

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - MÓDULO 3 - MODELAGEM DE SISTEMAS ORIENTADA A OBJETOS COM UML 1. INTRODUÇÃO A partir de 1980, diversos métodos de desenvolvimento de sistemas surgiram para apoiar o paradigma orientado a objetos com uma

Leia mais

3. PARADIGMA ORIENTADO A OBJETOS

3. PARADIGMA ORIENTADO A OBJETOS Paradigmas de Linguagens I 1 3. PARADIGMA ORIENTADO A OBJETOS Este paradigma é o que mais reflete os problemas atuais. Linguagens orientada a objetos (OO) são projetadas para implementar diretamente a

Leia mais

Unidade II. Outras ferramentas que também auxiliam o gerenciamento de projetos são: WBS, gráficos Gantt, PERT/CPM, ECD, entre outros.

Unidade II. Outras ferramentas que também auxiliam o gerenciamento de projetos são: WBS, gráficos Gantt, PERT/CPM, ECD, entre outros. GERENCIAMENTO DE PROJETOS DE TI Unidade II 2 FERRAMENTAS PARA GESTÃO DE PROJETOS A gestão de projeto como já visto no capítulo anterior é uma tarefa trabalhosa que requer muito controle. Assim, para ajudar

Leia mais

Algumas propriedades dos objetos:

Algumas propriedades dos objetos: Orientação a Objetos Vivemos num mundo de objetos. Esses objetos existem na natureza, nas entidades feitas pelo homem, nos negócios e nos produtos que usamos. Eles podem ser categorizados, descritos, organizados,

Leia mais