XVIII SEMINCO - SEMINÁRIO DE COMPUTAÇÃO XVIII { { SEMINCO SEMINÁRIO DE COMPUTAÇÃO ANAIS. 09 a 10 de DEZEMBRO de 2009 FURB - BLUMENAU - SC

Transcrição

1 XVIII SEMINCO - SEMINÁRIO DE COMPUTAÇÃO XVIII SEMINCO XBr yrj = mi yrj >n0 { { XBi yji SEMINÁRIO DE COMPUTAÇÃO ANAIS 09 a 10 de DEZEMBRO de 2009 FURB - BLUMENAU - SC

2 Anais do XVIII SEMINCO Seminário de Computação 9a10dedezembrode2009 FURB - Campus I - Blumenau/SC Promoção Universidade Regional de Blumenau - FURB Centro de Ciências Exatas e Naturais - CCEN Departamento de Sistemas e Computação - DSC Centro Acadêmico Livre de Computação - CALCOMP Comissão Organizadora Prof. Everaldo Artur Grahl (Coordenador) Prof. Adilson Vahldick Prof. Alexander Roberto Valdameri Prof. Antonio Carlos Tavares Prof. Dalton Solano dos Reis Matheus Luan Krueger Vilmar Orsi

3 Ficha Catalográfica Elaborada pela Biblioteca da FURB Seminário de Computação (18.: 2009 : Blumenau, SC) Anais do XVIII SEMINCO / promoção Universidade Regional de Blumenau, Departamento de Sistemas e Computação; Everaldo Artur Grahl, Dalton Solano dos Reis (coordenadores). - Blumenau, O Departamento, p. : il. 1. Computação - Congressos. I. Grahl, Everaldo Artur; Reis, Dalton Solano dos. II. Universidade Regional de Blumenau. Departamento de Sistemas e Computação. III. Título. CDD 004 Universidade Regional de Blumenau Reitor Prof. Eduardo Deschamps Vice-Reitor Prof. Romero Fenili Diretor do Centro de Ciências Exatas e Naturais Prof. Sérgio Stringari Chefe do Departamento de Sistemas e Computação Prof. Mauro Marcelo Mattos Coordenador do Colegiado do Curso de Ciências da Computação Prof. Alexander Roberto Valdameri Coordenador do Colegiado do Curso de Sistemas de Informação Prof. Francisco Adell Péricas

4 Apresentação A Universidade Regional de Blumenau - FURB, através do Departamento de Sistemas e Computação, realiza o XVIII Seminário de Computação (SEMINCO) entre os dias 9 e 10 de dezembro de Este ano tivemos a submissão de 88 artigos, sendo que destes foram aprovados 12 artigos provenientes das seguintes instituições: CTISM, FURB, IFCE, UFC, UNED, UFRJ, UFSM, UNIFRA, UNIGRANRIO, UNIPLAC, UNISINOS, UNISUL e UNIVALI. Estes artigos contemplam as seguintes áreas de conhecimento: Engenharia de Software, Integração Hardware / Software, Inteligência Artificial, Informática na Educação e Sistemas de Informação. Agradecemos a todos os envolvidos na organização do evento, bem como a Comissão de Avaliação Interinstitucional que avaliou os diversos artigos submetidos à chamada de trabalhos. Comissão Organizadora Agradecimentos Pró-Reitoria de Administração Contribuintes do Projeto Acredito Sociedade Brasileira de Computação - SBC

5 Comissão de Avaliação Interinstitucional Adilson Vahldick (UDESC) Adriana G. Alves (UNIVALI) Ana Marcia Debiasi Duarte (UNOESC) Angelo Augusto Frozza (IFC) Anita Fernandes (UNIVALI) Aurélio Hoppe (FURB) Carlos Raniery Paula dos Santos (UFRGS) Dalton Solano dos Reis (FURB) Daniel Welfer (UNIPAMPA) Denio Duarte (UFFS) Denise de Oliveira (UFRGS) Everaldo Artur Grahl (FURB) Fabiane Barreto Vavassori Benitti (UNIVALI) Fábio Rafael Segundo (FURB) Fernando dos Santos (FURB) Fernando Osório (USP) Frank Siqueira (UFSC) Giovane Kuhn (UFRGS) Jomi Fred Hubner (UFSC) Joyce Martins (FURB) Juan Marcus T. Ibiapina (UFRGS) Jusane Lara (UTP) Leandro Fernandes (UFF) Leonardo Garcia Fischer (UFRGS) Marcel Hugo (FURB) Marcelo Duduchi (FATEC) Marcos Eduardo Casa (UCS) Maria Inés Castiñeira (UNISUL) Mauricio Capobianco Lopes (FURB) Mauro Marcelo Mattos (FURB) Miguel Wisintainer (FURB) Odisnei Galarraga (Software Process Consultoria) Patrícia Vilain (UFSC) Paulo Rodacki Gomes (FURB) Vitor Pamplona (UFRGS)

6 Engenharia de Software Artigos Selecionados Orquestração de Web Services utilizando BPEL 7 Adilson Vahldick, Juarez Bachmann Uma Ferramenta MDA para Desenvolvimento de Software Orientado a Aspectos 19 Thiago Silva de Souza, Wallace Santos Vialle Rettich, Danilo Ferreira Leite, Diego Cardozo Vieira, Marcos Meirelles P. Araújo, Cristiano de O. Nogueira Ferramenta para Auxiliar no Gerenciamento de Escopo de Projetos conforme o PMBOK Cristiano Born, Adriana Gomes Alves Uma Ferramenta Colaborativa de Edição de Mapas Conceituais para a Especificação de Requisitos de Software Pablo Dall Oglio, João Pablo S. da Silva, Sérgio Crespo C. S. Pinto, João C. Gluz Definição de um Processo de Teste com Integração Contínua: um Estudo de Caso 55 Cristiana Yukie Masuda, Maria Inés Castiñeira Integração Hardware / Software Tratamento de Falhas em Sensores e Atuadores: Um Estudo de Caso com o Robô Lego Mindstorms Douglas Pereira Pasqualin, Guilherme Dhein 68 Inteligência Artifical Estudo Comparativo de Formas de Representação da Mão Humana para o Reconhecimento de Gestos Baseado em Redes Neurais Artificiais, Momentos de Hu e Atributos de Forma Frederico R. Maciel, Antonio C. S. Barros, Rodrigo F. Freitas, Rodrigo C. S. Costa, Paulo C. Cortez, José M. Soares, Miguel G. L. Espinosa 80

7 Avaliação de Métodos de Extração de Características para Inspeção Automática de Laranjas Destinadas à Produção de Suco Utilizando Classificadores Não Paramétricos Rodrigo C. S. Costa, Antonio C. S. Barros, Frederico R. Maciel, Auzuir R. de Alexandria, G. L. B. Ramalho 93 Informática da Educação Sistema para apoio a aprendizagem de Álgebra Relacional 105 Renato Vidal Kinaipp, Adriana Gomes Alves Ensinando Programação Através de Dispositivos Móveis: Mobile Furbot e ifurbot 118 Daniel Severo Estrázulas, Marco Antonio Corrêa, Adilson Vahldick, Mauro Marcelo Mattos Sistemas de Informação Middleware para integração de uma aplicação para dispositivos móveis com aplicações corporativas Thiago Comél, Angelo Augusto Frozza 131 CASGrid: uma Camada de Segurança para Grids computacionais 143 Silvio Augusto Langer, Rogério Turchetti, Victor Alves, Celio Trois

8 7 Orquestração de Web Services utilizando BPEL Adilson Vahldick 1, Juarez Bachmann 1 1 Departamento de Sistemas e Computação Universidade Regional de Blumenau (FURB) Blumenau, SC Brasil {adilsonv77, juarez.bachmann}@gmail.com Resumo. Com a difusão da Internet e ascendência dos web services, precisouse definir formas de realizar e coordenar sua integração. Essa tarefa é chamada de orquestração, e a linguagem BPEL define como mapear e organizar o fluxo de troca de dados entre os web services. O presente artigo trata de ilustrar a BPEL, e apresenta duas ferramentas de modelagem BPEL e dois servidores para sua execução. 1. Introdução Segundo Singh et al. (2006) a utilização de web services vem sofrendo rápida expansão devido à crescente necessidade de comunicação entre aplicativos. Web service é um aplicativo de software, acessível na web (ou em uma intranet corporativa) através de uma URL (Singh et al., 2006), com uma interface bem definida permitindo que as organizações tornem acessíveis as suas informações a outros programas (Sommerville, 2007). Este aplicativo pode ser acessado pelos clientes usando protocolos baseados em XML (tais como SOAP) e pode ter as mais diversas funções, desde o tratamento de requisições simples para informações até a implementação de complexos processos de negócio (Snell, 2002). Os web services podem ser escritos em diversas linguagens de programação e podem ser acessados entre clientes escritos em linguagens diferentes, o que facilita a sua interoperabilidade e a integração entre diversos sistemas. Além disso, Sampaio (2006) destaca que um serviço deve executar unidades completas de trabalho, ou seja, deve processar a sua função de negócio específica sem depender do estado de outros componentes externos, o que acaba por aumentar a sua reutilização. O crescimento das empresas e o processo de globalização fomentam a utilização dos web services. A característica de interoperabilidade permite que clientes e fornecedores, mesmo cada um com seu sistema de informação independente, possam operar com unicidade. A informatização do processo de negócio pode considerar atores externos ao ambiente das empresas, o que acaba por criar novas possibilidades e novas dificuldades para o funcionamento dos softwares corporativos. Uma das formas existentes para a criação e execução destes processos de negócios cada vez mais complexos é a orquestração de web services. Segundo Rosato (2008), orquestração é a composição de web services para criar um novo serviço, o qual possibilita a resolução de uma tarefa em um processo de negócio. Conforme Pant e Juric (2008), a orquestração de serviços pode ser desenvolvida de diversas formas, porém, a solução mais difundida atualmente é a utilização da linguagem BPEL

9 8 (Business Process Execution Language), que é uma linguagem no formato XML, onde se mapeiam os web services e suas interações. Este artigo descreve em mais detalhes a BPEL (seção 2), apresenta duas ferramentas de modelagem de BPEL (seção 3) e aborda o ambiente para execução desses processos (seção 4). Na última seção é feito um comparativo entre essas ferramentas. 2. BPEL Sampaio (2006) define BPEL como uma linguagem utilizada para realizar a orquestração de um conjunto de web services para formar um fluxo de negócios, ou seja, sua função é modelar um processo de negócio com web services. A orquestração é um procedimento utilizado em processos privados, sendo que este modelo consiste na criação de um elemento centralizador que assume o controle dos web services participantes e coordena a execução de diferentes métodos desses serviços (Grahl, 2008). De acordo com Sampaio (2006), a aplicação cliente se comunica com o processo central (coordenador) e faz uma solicitação, sendo que o coordenador inicia o fluxo interno de execução dos web services, invocando e verificando todas as etapas necessárias. A Figura 1 ilustra a estrutura de um processo de orquestração. Figura 1. Orquestração de web services A representação de um processo de negócios em BPEL é feita no formato XML, onde os web services e suas interações são mapeados, definindo assim o fluxo para a execução. Um exemplo de parte do código-fonte de um processo BPEL é representado na Figura 2.

10 9 Figura 2. Parte do código-fonte de um processo BPEL A especificação WSBPEL 2.0 (Weerawarana, 2005) determina a estrutura e a semântica da linguagem, e os seus principais elementos são relacionados nas subseções seguintes Partner Link O partner link é o canal de comunicação entre o processo e os web services que o compõe. Nestes elementos são definidos que métodos serão executados pelo coordenador Variables O elemento variables é usado para definir as variáveis que serão utilizadas pelo processo. Estas variáveis podem receber tanto os dados de entrada vindos do cliente como os resultados da execução dos web services envolvidos no processo Activities A linguagem BPEL disponibiliza inúmeros tipos de atividades que podem ser utilizadas na modelagem/execução dos processos, sendo os principais listados a seguir: receive: elemento que aguarda a chegada de uma mensagem; reply: envia uma mensagem de resposta para alguma solicitação recebida; invoke: invoca uma requisição para um web service através do partner link. assign: utilizado para atribuir valores para as variáveis. if: elemento utilizado para possibilitar a escolha entre mais de uma atividade, de acordo com alguma condição. while: define um laço de repetição para uma atividade enquanto a condição for atendida. foreach: faz a iteração entre os elementos contidos nele.

11 10 Além dos elementos acima descritos, a especificação compreende inúmeros outros, contemplando desde atividades de espera de tempo (wait) até tratamentos de exceções (throw). 3. Ferramentas para modelagem de processos em BPEL O desenvolvimento de processos de negócio na linguagem BPEL não é uma tarefa trivial, pois exige-se conhecimento dos esquemas da linguagem, além de ter de referenciar-se aos web services, onde precisa-se saber quais métodos e parâmetros estão à disposição. Há diversas ferramentas no mercado que possibilitam a modelagem dos processos BPEL de forma gráfica e intuitiva. Entre elas estão o ActiveVOS (Active Endpoints, 2009a) e o plugin BPEL para o Eclipse (Eclipse, 2009). Os recursos das ferramentas serão discutidos com base em um processo de negócio exemplo. O processo consiste na validação de dois campos comuns em um cadastro de pessoas, que são o endereço de e o CEP. Esse processo receberá dois valores de entrada (endereço de e CEP) e devolverá um valor indicando o sucesso ou fracasso da consistência: true ou false. Para implementar este exemplo serão utilizados dois web services públicos disponíveis nos endereços abaixo: CEP: A lógica deste processo de negócio é exibida na Figura 3. Figura 3. Fluxo do processo de negócio exemplo

12 ActiveVOS O ActiveVOS é um sistema construído sobre a plataforma Eclipse que oferece ferramentas para a modelagem, publicação e gerenciamento de aplicativos de processos de negócio (Active Endpoints, 2009a). Essa ferramenta permite que os processos sejam modelados de forma gráfica, apresentando os elementos da linguagem BPEL em uma paleta de componentes, bastando que o usuário arraste os componentes desejados para a área de trabalho e monte os seus fluxos para os processos de negócio. Sendo assim, é desnecessário realizar alterações diretamente na estrutura XML do processo, pois até mesmo a alteração das propriedades de cada elemento é facilitada mediante uma interface gráfica amigável para este fim. A paleta de componentes desta ferramenta é apresentada na Figura 4. Figura 4. Paleta de componentes do ActiveVOS A modelagem do fluxo usado para o processo de negócios exemplo pode ser vista na Figura 5, sendo que há um detalhamento sobre a sua execução logo a seguir.

13 12 Figura 5. Modelagem do processo de validação O processo tem início na atividade receive chamada entrada, responsável por receber os parâmetros (endereço de e CEP). Em seguida é executada a atividade assign chamada set , cuja função é atribuir para o web service de validação de e- mail o endereço informado como parâmetro para o processo. A atividade invoke validar é responsável por executar o web service de validação, sendo que se o retorno dessa execução for igual a false, então é executada atividade assign setfalse, que atribui também o valor false para a variável de saída do processo. Se o resultado da validação do endereço de for igual a true (endereço válido), então é executada a atividade assign setcep, que alimenta a variável do web service de validação de CEP com o parâmetro de entrada do processo BPEL. A atividade invoke validarcep executa o web service de validação do CEP. Se o resultado dessa execução retornar como CEP inválido, é executada a atividade assign setfalse, que atribui o valor false para a variável de saída do processo. Porém, se o CEP for válido, é executada assign settrue para atribuir o valor true à variável de saída. A última atividade é reply saída que retorna o valor previamente atribuído. Alguns aspectos merecem destaque para facilitar a compreensão da execução deste processo. Inicialmente é importante salientar que todos os parâmetros de entrada e de saída, tanto do processo BPEL em si quanto dos métodos dos web services que o compõe, são mapeados como variables dentro do processo. Exemplificando: o parâmetro de entrada do processo relativo ao transforma-se em uma variável chamada, por exemplo, input ; o parâmetro de entrada do método que valida o e-

14 13 mail no web service é ligado a uma variável chamada, por exemplo, ws; e o parâmetro de retorno do web service que informa se o é válido ou não, é mapeado para uma variável chamada retornows. Dessa forma, o objetivo das atividades assign é alimentar as variáveis copiando os valores de uma para a outra conforme a necessidade. Neste exemplo, o assign set é responsável por transferir o valor da variável input (parâmetro de entrada do processo BPEL) para a variável ws (parâmetro de entrada do web service). Outra situação que merece maior esclarecimento é o relacionamento entre o elemento partner link e a atividade invoke. Como supracitado, o partner link é o responsável por realizar a ligação entre o processo BPEL e os web services envolvidos. Desta forma, toda atividade invoke está associada a um partner link para que seja possível executar os serviços. O Eclipse possui uma ferramenta denominada Web Services Explorer cujo objetivo é permitir a realização de testes com web services e processos BPEL. Por ser desenvolvido sobre a plataforma Eclipse, o ActiveVOS também permite o acesso a esta ferramenta de testes, onde é possível informar os valores de entrada dos processos BPEL e executar todo o fluxo (inclusive depurando), obtendo o seu retorno conforme os resultados das execuções dos web services Plugin BPEL para o Eclipse Segundo Eclipse (2009), o objetivo do plugin BPEL é adicionar à IDE do Eclipse suporte para definição, edição, publicação, testes e depuração de processos utilizando a linguagem WSBPEL 2.0. A modelagem também é feita de forma gráfica, arrastando os componentes. A figura 6 apresenta a paleta de componentes disponibilizada por este plugin. Figura 6. Paleta de componentes do plugin do Eclipse

15 14 A figura 7 ilustra a modelagem do processo exemplo com a ferramenta. Figura 7. Modelagem do processo de validação utilizando o plugin do Eclipse Para testar estes processos, assim como no ActiveVOS, deve-se utilizar a ferramenta Web Services Explorer disponível no Eclipse. 4. Execução de processos BPEL Para a execução de uma aplicação BPEL é necessário publicá-la em um servidor de processos BPEL. Alguns servidores são pagos, como Oracle BPEL Process Manager, IBM WebSphere Business Integration Server Foundation e Microsoft BizTalk. Os servidores Apache ODE e ActiveBPEL Engine são dois exemplos de produtos de uso livre, e que serão descritos nessa seção. De acordo com Apache (2009a), Apache ODE trata-se de uma ferramenta cujo objetivo é executar processos de negócio escritos com o padrão BPEL. Essa ferramenta é um complemento ao Apache Tomcat 2, sendo instalada como um aplicativo web dentro deste servidor. A figura 8 ilustra a arquitetura do Apache ODE. Os arquivos com a definição do processo BPEL são compilados pelo servidor e enviados à área de runtime (Ode BPEL Runtime). Essa área é responsável pela persistência dos dados, controle da concorrência e a navegação entre os web services envolvidos. Estes serviços, por sua vez, são 2 O Apache Tomcat é uma implementação das tecnologias Java Servlet e JavaServer Pages (Apache, 2009d). Em outras palavras, trata-se de um servidor de aplicações web desenvolvidas na linguagem Java.

16 15 acessados pelo servidor através da sua camada de integração (ODE Integrationlayer), a qual se comunica tanto com os web services quanto com a camada de runtime. Fonte: Apache (2009b) Figura 8. Arquitetura do servidor Apache ODE Para realizar o deploy de um processo BPEL no Apache ODE, basta copiar o diretório com os arquivos relacionados ao processo criado (arquivos.bpel,.wsdl,.xml, etc) para dentro do diretório de processos do servidor, num caminho como %TOMCAT_HOME%/webapps/ode/WEB-INF/processes (Apache, 2009c). Para facilitar este processo, é possível relacionar um servidor ODE diretamente com o Eclipse, fazendo com que esse deploy seja feito de forma automática pelo Eclipse. O ActiveBPEL Engine, por sua vez, é uma ferramenta que pode ser acoplada a qualquer contêiner de servlets (Apache Tomcat, por exemplo) que utilize a especificação padrão (Active Endpoints, 2009b). Assim como o Apache ODE, o ActiveBPEL Engine também é instalado como um aplicativo web dentro do contêiner de servlets. Para publicar um processo BPEL neste servidor, deve-se gerar um arquivo de deployment com a extensão.bpr, onde deverão constar os arquivos gerados durante a fase de modelagem. A ferramenta de modelagem ActiveVOS, por exemplo, possui uma ferramenta que possibilita exportar os arquivos do processo gerando automaticamente o arquivo.bpr. Em seguida, utilizando-se a interface web do ActiveBPEL Engine acessível através do contêiner de servlets, deve-se selecionar este arquivo e realizar o seu deploy no servidor. Uma vez que um processo BPEL seja publicado em qualquer um destes servidores, ele pode ser acessado da mesma forma que um web service comum, ou seja, é possível iniciar o seu processamento a partir de qualquer aplicação, escrita em

17 16 qualquer linguagem que permita tal recurso, o que reforça a flexibilidade e a facilidade na utilização da orquestração de serviços através de BPEL. 5. Considerações finais A orquestração de serviços através da linguagem BPEL permite que fluxos de processo sejam executados com grande flexibilidade e facilidade. A linguagem BPEL oferece inúmeros recursos para a execução de processos de negócio, incluindo a capacidade de estruturas condicionais e de repetição. Para maximizar a produtividade na criação desses processos, torna-se necessário o uso de ferramentas de modelagem e execução. As ferramentas de modelagem apresentadas neste trabalho são totalmente compatíveis com a especificação WSBPEL 2.0. Suas funcionalidades são bastantes semelhantes, haja vista a íntima ligação que ambas têm com a ferramenta Eclipse: uma é um plugin desta ferramenta e outra (ActiveVOS) é desenvolvida sobre esta plataforma. Apesar disto, durante os testes realizados, verificou-se que o ActiveVOS possui uma usabilidade ligeiramente superior ao plugin, pois este último, por algumas vezes, teve que ser reiniciado após inserir algum componente no fluxo, para que fosse possível visualizar e alterar as suas propriedades corretamente. Também foi mais simples implementar expressões condicionais no ActiveVOS, principalmente porque esta ferramenta possui construtores de expressões que permitem que os as expressões sejam construídas sem a necessidade de conhecer a fundo a respectiva sintaxe, bastando para tanto utilizar a interface gráfica. Com relação às instruções de utilização, as duas contam com bons materiais de apoio (apostilas, tutoriais, help, etc) na internet, mas neste quesito o ActiveVOS também se sobressai devido ao help on-line que pode ser acessado diretamente a partir da ferramenta, onde há uma vasta gama de informações e exemplos bastante didáticos e ilustrados de forma a facilitar o trabalho do usuário. Além disso, a maior diferença entre as ferramentas é o preço: o plugin pode ser utilizado gratuitamente enquanto o ActiveVOS é pago (para desenvolver este trabalho, foi utilizada a versão trial que é gratuita por 30 dias). Outra ferramenta gratuita avaliada foi a Oracle SOA Suite que utiliza uma linguagem proprietária. Por não seguir a especificação BPEL, ela não foi citada durante o trabalho. A execução dos processos BPEL também mostrou-se simplificada, sendo necessária somente a sua publicação em um servidor adequado. Neste trabalho foram apresentados dois servidores de código aberto, integrados com o Apache Tomcat, e as atividades de implantação dos processos em ambos. Com relação à utilização da orquestração de serviços no mercado, há de se levar em consideração estudos e notícias divulgadas na mídia a respeito deste tema. O IDG Now (2007), por exemplo, noticiou a adoção do suporte à linguagem BPEL na camada de gerenciamento de fluxo de processo do Windows Vista. Também segundo pesquisa divulgada pelo IDG Now (2009), 32% dos entrevistados demonstraram intenção em adotar soluções de gerenciamento de processos de negócio em 2010, enquanto 19% afirmaram já estar em busca de parceiros para implementação destas soluções. Sendo assim, pode-se afirmar que a orquestração é mais do que uma tendência: é uma realidade cada vez mais presente no dia a dia das organizações.

18 17 Uma das principais vantagens da orquestração é que, além de possibilitar a criação e gerenciamento destes fluxos, ela cria a possibilidade de adicionar ou remover web services do processo com facilidade, sem necessidade de alterações no código-fonte dos outros serviços envolvidos, resultando em maior flexibilidade e reutilização dos serviços. Diante desta realidade, e analisando a usabilidade das ferramentas expostas e os experimentos efetuados, pode-se concluir que a orquestração de serviços é técnica das mais sólidas e apropriadas para disponibilizar soluções adequadas aos fluxos dos processos de negócio das organizações modernas. Com a sua adoção por parte de grandes empresas (como a Microsoft, por exemplo), tal técnica deve se tornar cada vez mais popular, podendo vir a mudar radicalmente o conceito de sistemas de informação existente atualmente, pois com a crescente adoção da arquitetura SOA no desenvolvimento de sistemas mais desacoplados, a orquestração tem grande potencial para integrar as diversas partes que formarão os processos de negócio das empresas. Referências Active Endpoints (2009a) Welcome to Active Endpoints, Disponível em < Acesso em 05 outubro Active Endpoints (2009b) The ActiveBPEL Engine, Disponível em < Acesso em 05 outubro Apache (2009a) ODE Architectural Overview, Disponível em < Acesso em 19 outubro Apache (2009b) Welcome to Apache ODE, Disponível em < Acesso em 19 outubro Apache (2009c) Deploying a Process in Ode, Disponível em < Acesso em 19 outubro Apache (2009d) Apache TomCat, Disponível em < Acesso em 19 outubro Eclipse (2009) BPEL Project, Disponível em < Acesso em 28 setembro Grahl, Carlos A. C. (2008) O que é BPEL, Disponível em < Acesso em 26 setembro IDG Now (2007) Microsoft adiciona BPM ao Windows Vista, Disponível em < />. Acesso em 28 outubro IDG Now (2009) Estudo identifica prioridades tecnológicas das companhias para 2010, Disponível em < Acesso em 28 outubro 2009.

19 18 Pant, Kapil; Juric, Matjaz (2008) Business Process Driven SOA using BPMN and BPEL: From Business Process Modeling to Orchestration and Service Oriented Architecture, Packt Publishing. Rosato, Fábio (2008) Orquestração vs. Coreografia, Disponível em < Acesso em 26 setembro Sampaio, Cleuton (2006) SOA e Web Services em Java, Rio de Janeiro: Brasport. Singh, Inderjeet et al. (2006) Projetando Web Services com a Plataforma J2EE 1.4, Tradução Cláudio Rodrigues Pistilli, Rio de Janeiro: Ciência Moderna. Sommerville, Ian (2007) Engenharia de Software, São Paulo: Pearson-Addison Wesley. Snell, James (2002) Programming Web Services with SOAP, Beijing: O Reilly. Weerawarana, Sanjiva et al. (2005) Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More, Prentice-Hall.

20 19 Uma Ferramenta MDA para Desenvolvimento de Software Orientado a Aspectos Thiago Silva-de-Souza¹, ², Wallace Santos Vialle Rettich², Danilo Ferreira Leite², Diego Cardozo Vieira², Marcos Meirelles P. Araújo², Cristiano de O. Nogueira² 1 Programa de Pós-Graduação em Informática (PPGI), Universidade Federal do Rio de Janeiro (UFRJ) Rio de Janeiro-RJ, Brasil 2 Escola de Ciência e Tecnologia, Universidade do Grande Rio (UNIGRANRIO), Duque de Caxias-RJ, Brasil {thiagoein, wallace.rettich, danilo.webmaster, dcvieira.info, mmparaujo}@gmail.com, cristiano.con@ig.com.br Resumo. O paradigma da Orientação a Aspectos está sendo cada vez mais utilizado no desenvolvimento de software. Existem diversas linguagens e frameworks para programação orientada a aspectos, tendo como destaque a linguagem AspectJ. No entanto, a modelagem orientada a aspectos ainda não possui um padrão estabelecido, tendo como uma das principais propostas a linguagem de modelagem asideml. As abordagens de modelagem propostas têm em comum o fato de não contar com suporte ferramental suficiente. Diante disso, este artigo apresenta o ambiente acase, uma ferramenta para modelagem asideml, geração automática de código AspectJ, baseada na abordagem Model Driven Architecture, e engenharia reversa de código AspectJ para modelos asideml. 1. Introdução A Programação Orientada a Aspectos (POA) é uma proposta para melhorar a separação de interesses em nível de programação. Para tanto, a POA introduz uma nova abstração, o aspecto (aspect), que pode atuar em conjunto com as abstrações de outros paradigmas de programação, como a orientação a objetos. Para [Kiczales et al. 1997], um aspecto é um tipo particular de interesse. Um interesse é qualquer código relacionado com uma meta, característica, conceito ou tipo de funcionalidade. Em termos de linguagens de programação, a POA já possui muitas opções. Dentre as opções existentes destaca-se a AspectJ [Kiczales et al. 2001], uma linguagem orientada a aspectos que estende a linguagem de programação Java. Um programa AspectJ é dividido em duas partes: a parte do código base, que é implementado através de classes, interfaces e outras construções da linguagem para implementar a funcionalidade básica do programa, e a parte do código de interesses transversais, que é implementado através de aspectos. Para realizar a composição entre os elementos base e os elementos transversais é necessário utilizar um combinador (aspect weaver) [Kiczales et al. 2001]. Enquanto a POA vem amadurecendo e ganhando ampla aceitação no mercado, a separação de interesses em nível de modelagem ainda se mostra incipiente, visto que grande parte das soluções e técnicas desenvolvidas para a orientação a objetos não são

21 20 facilmente adaptáveis à orientação a aspectos (OA). Com o advento do paradigma orientado a aspectos, diversas abordagens de modelagem têm sido propostas, dentre as quais asideml [Chavez 2004], uma linguagem de modelagem baseada na UML para especificar e comunicar designs orientados a aspectos. Ela suporta modelagem estrutural, comportamental e composicional. Para cada categoria de modelagem asideml oferece um conjunto de diagramas e para cada diagrama alguns elementos específicos de modelagem orientada a aspectos são exercitados. A modelagem estrutural em asideml pode ser realizada através de diagramas de aspectos e de classes estendido; a modelagem comportamental pode ser feita através dos diagramas de seqüência, de seqüência aspectual (ou estendido) e de colaboração aspectual; já a modelagem composicional (ou de processo de combinação) é suportada pelos diagramas de classes combinadas, de colaboração combinada e de seqüência combinada. No que se refere a Desenvolvimento de Software Dirigido por Modelos (DSDM), a arquitetura Model Driven Architecture (MDA) [OMG 2009] proposta pelo Object Management Group (OMG) reconhece a importância dos modelos no processo, tornando-os o ponto-chave no desenvolvimento. Ela define que o processo de desenvolvimento de software deve ser direcionado pela atividade de modelagem do sistema, no nível conceitual, independente de qualquer plataforma/implementação. Através de transformações realizadas sobre esse modelo conceitual, novos modelos, com níveis de abstração cada vez mais específicos e ligados à implementação são gerados, de forma que o sistema final é gerado automaticamente, a partir da especificação definida no modelo conceitual. Os modelos construídos são mais formais, evitando ambigüidade, modelos que podem ser entendidos por sistemas de software. A arquitetura MDA compreende três passos principais: o primeiro passo é a geração do Modelo Independente de Plataforma (PIM - Platform Independent Model), definido com um alto grau de abstração, independente de qualquer tipo de tecnologia. Descreve o sistema de software de uma perspectiva que melhor represente o negócio sendo modelado; o segundo passo é a geração de um ou mais Modelos Específicos de Plataforma (PSM - Platform Specific Model). Cada PSM é gerado levando em conta detalhes específicos de uma determinada tecnologia a ser utilizada na implementação. Para cada PIM, vários PSMs podem ser gerados. o último passo é a geração de código-fonte a partir de cada PSM. Esta geração de código não constrói apenas estruturas básicas e templates, como fazem algumas ferramentas CASE tradicionais; o código gerado com MDA deve ser o mais próximo possível da solução de software definitiva, incluindo as regras de negócio. A MDA define, além destes três modelos, as transformações entre os modelos. Uma transformação é uma geração automática de um modelo em outro, conforme uma especificação de transformação, que abrange um conjunto de regras de transformação que descrevem como um modelo pode ser transformado em outro. Um PIM deve ser criado e, então, transformado em um ou mais PSMs, que são então transformados em código. Este trabalho trata, portanto, de um ambiente CASE integrado, que permite a modelagem de aspectos seguindo a notação asideml, bem como a geração automática