1

FLÁVIO GRANERO MALTEMPE

ESTUDO DO MDA E SOA

Londrina - Paraná 2006

2

FLÁVIO GRANERO MALTEMPE

ESTUDO DO MDA E SOA

Monografia apresentada ao Curso de PósGraduação em Engenharia de Software e Banco de Dados da Universidade Estadual de Londrina, como requisito parcial à obtenção do título de Especialista. Orientador: Prof. Ms. Sérgio Akio Tanaka

Londrina - Paraná 2006

i

FLÁVIO GRANERO MALTEMPE

ESTUDO DO MDA E SOA

Monografia apresentada ao Curso de PósGraduação em Engenharia de Software e Banco de Dados da Universidade Estadual de Londrina, como requisito parcial à obtenção do título de Especialista.

COMISSÃO EXAMINADORA

______________________________________________ Prof. Ms. Rodolfo Miranda de Barros Universidade Estadual de Londrina ______________________________________________ Prof. Dr. Y Universidade Federal do Rio de Janeiro ______________________________________________ Prof. Ms. Sergio Akio Tanaka Centro Universitário Filadélfia

Londrina, ____ de____________ de 2006

ii

DEDICATÓRIA

Dedico este trabalho à Elen.

iii

AGRADECIMENTOS

Agradeço aos meus pais pelo apoio durante o tempo em que estive ocupado neste trabalho e aos amigos pelos incentivos. Agradeço principalmente à Elen que sempre me motivou quando as dificuldades surgiam.

iv

“A imaginação é muito mais importante que o conhecimento” Albert Einstein

v

MALTEMPE, Flávio G. ESTUDO DO MDA e SOA. 2006. Monografia (Pós-Graduação em Engenharia de Software e Banco de Dados) - Universidade Estadual de Londrina.

RESUMO

A indústria de software busca constantemente novas metodologias para o desenvolvimento de sistemas de alta qualidade e custo reduzido. Uma forma de aumentar a qualidade é priorizar as fases de captura de requisitos e elaboração durante o desenvolvimento, o que consequentemente aumenta o custo do projeto, já que se gasta mais tempo em fases anteriores à implementação. Para melhorar a relação entre qualidade e custo, surgiu o paradigma MDA, que consiste em transformar modelos do sistema escritos na linguagem UML, em modelos para uma tecnologia específica, geralmente códigos de linguagens de programação. Além de aplicar o MDA para tornar a fase de implementação menos dispendiosa, pode-se projetar o software em uma arquitetura que seja flexível e altamente reutilizável. A arquitetura orientada a serviços ou SOA possui essas qualidades, dividindo o sistema em pequenas partes que se comunicam mesmo em plataforma diferentes, sendo que cada parte ou serviço pode ser utilizado por diversos sistemas que necessitem da funcionalidade provida. Por meio de um estudo de caso simples, esse trabalho mostra o desenvolvimento de um sistema com técnicas de MDA, disponibilizando ainda suas funcionalidades como serviços de uma arquitetura SOA. Para isso, faz uso de uma ferramenta comercial que auxilia no processo de transformações dos modelos e na publicação dos serviços. Apresenta um exemplo de consumo desses serviços e conclui explicando porque os conceitos apresentados são aplicáveis em processos de fábricas de software através do uso de ferramentas. Palavras-chave: arquitetura de software; MDA; arquitetura orientada a serviços; UML.

vi

MALTEMPE, Flávio G. ESTUDO DO MDA e SOA. 2006. Monografia (Pós-Graduação em Engenharia de Software e Banco de Dados) - Universidade Estadual de Londrina.

ABSTRACT

The software industry constantly searches for new methodologies to develop high quality systems with a reduced cost. A form to increase the quality is to prioritize the requirements capture and elaboration phases during the development, increasing the project cost, since more time is spent in previous phases to the implementation. To improve the relation between quality and cost, the MDA paradigm appeared, that consists of transforming system models written in UML language, into specific technology models, generally programming languages codes. Beyond applying the MDA to become the implementation phase less expensive, software can be projected in a flexible and highly reusable architecture. The service oriented architecture or SOA has these qualities, dividing the system in small parts that communicate in different platforms, where each part or service can be used by distinct systems that needs the provided functionality. By a simple case study, this work shows a system development applying MDA techniques, publishing its functionalities as services of SOA architecture. For this, it makes use of a commercial tool that assists the models transformation process and the services publication. It presents an example of services consumption and concludes explaining why the presented concepts are applicable in software factories processes through the use of tools. Key-words: software architecture; MDA; service oriented architecture; UML.

vii

LISTA DE FIGURAS

FIGURA 1 - DIAGRAMA DE CASOS DE USO DO SISTEMA DE CONTROLE FINANCEIRO. ................ 16 FIGURA 2 - ESBOÇO DO DIAGRAMA DE CLASSES DO SISTEMA DE CONTROLE FINANCEIRO. ... 21 FIGURA 3 – DIAGRAMA DE CLASSES COM ESTEREÓTIPOS APLICADOS ............................................ 25 FIGURA 4 – DIAGRAMA DE SEQÜÊNCIA PARA O FLUXO BÁSICO DO CASO DE USO “GERENCIAR MOVIMENTO”. ........................................................................................................................................................ 26 FIGURA 5 – DIAGRAMA DE CLASSES COM MÉTODOS. .............................................................................. 27 FIGURA 6 – CLASSES BEAN GERADAS NO PROCESSO DE TRANSFORMAÇÃO ................................... 32 FIGURA 7 – ESTRUTURA DOS ARQUIVOS GERADOS PELA TRANSFORMAÇÃO ................................ 33 FIGURA 8 – ASSISTENTE DE CRIAÇÃO DE SERVIÇOS DA WEB ............................................................... 35 FIGURA 9 – ESCOLHA DOS MÉTODOS A SEREM PUBLICADOS COMO SERVIÇOS ............................ 36 FIGURA 10 – GRÁFICO PARA O ARQUIVO DE DEFINIÇÃO DO SERVIÇO GERADO ........................... 37 FIGRA 11 – APLICATIVO WEB CONSUMIDOR DE SERVIÇOS DO CONTROLE FINANCEIRO .......... 39

viii

LISTA DE QUADROS

QUADRO 1 - DETALHAMENTO DO CASO DE USO “GERENCIAR MOVIMENTO”................................ 19

ix

SUMÁRIO

RESUMO....................................................................................................................................................................... v

ABSTRACT.................................................................................................................................................................. vi

LISTA DE FIGURAS................................................................................................................................................. vii

LISTA DE QUADROS.............................................................................................................................................. viii

1 INTRODUÇÃO ......................................................................................................................................................... 1 1.1 OBJETIVOS ............................................................................................................................................................ 2 1.2 JUSTIFICATIVA ...................................................................................................................................................... 3 2 FUNDAMENTAÇÃO TEÓRICA ........................................................................................................................... 4 2.1 ARQUITETURA DE SOFTWARE ............................................................................................................................... 4 2.2 UML ........................................................................................................................................................................ 6 2.3 MDA ........................................................................................................................................................................ 8 2.4 SOA ....................................................................................................................................................................... 11 2.5 CONSIDERAÇÕES FINAIS .............................................................................................................................. 14 3 ESTUDO DE CASO ............................................................................................................................................... 15 3.1 ESCOPO ............................................................................................................................................................... 15 3.2 CASOS DE USO E REQUISITOS NÃO-FUNCIONAIS ................................................................................................ 16 3.3 DIAGRAMA DE CLASSES ..................................................................................................................................... 19 4 APLICAÇÃO DO MDA E SOA NO ESTUDO DE CASO CONTROLE FINANCEIRO PESSOAL ............ 21 4.1 MODELAGEM DO SISTEMA NA FERRAMENTA RSA .............................................................................................. 22 4.1.1 Modelo de casos de uso .............................................................................................................................. 23 4.1.2 Modelo de Análise....................................................................................................................................... 24 4.2 PROCESSO DE TRANSFORMAÇÃO MDA ............................................................................................................... 28 4.2.1 Escolha da tecnologia ................................................................................................................................. 28 4.2.2 Criação do processo de transformação ...................................................................................................... 30 4.2.3 Modelos gerados pela transformação......................................................................................................... 31 4.3 PUBLICAÇÃO DE SERVIÇOS DO APLICATIVO ........................................................................................................ 34 4.4 EXEMPLO DE CONSUMO DOS SERVIÇOS ............................................................................................................... 38 4.5 CONSIDERAÇÕES FINAIS ..................................................................................................................................... 39 5 CONCLUSÕES E TRABALHOS FUTUROS ..................................................................................................... 40 REFERÊNCIAS ......................................................................................................................................................... 42

1

1 Introdução

A demanda mundial por novos projetos de software cresceu muito nos últimos anos, levando empresas de desenvolvimento a buscar técnicas para melhorar seus processos de produção, diminuindo custos e riscos nos projetos, já que o mercado mostra que esses são fatores cruciais para seu sucesso. É comum um projeto de software passar por problemas durante sua realização e ser encerrado antes da conclusão, ou mais comum, ainda, é um projeto da área necessitar de mais que o dobro dos recursos esperados em seu início.

Uma das maneiras de se melhorar a produtividade em uma empresa do setor é aplicar conceitos de reuso na fabricação de software. O uso de frameworks e componentes têm trazido êxito, diminuindo em muito o trabalho repetitivo que acontecia a cada novo projeto. A premissa desse tipo de reuso é criar objetos que possam ser reutilizados, construindo-os de forma desacoplada e coesa, definindo-se interfaces entre um pacote deles e o restante do sistema.

Mas, devido ao baixo nível de abstração apresentado por esses conceitos, a manutenção dos sistemas ainda é custoso, já que pequenas alterações nas implementações dos objetos base podem ocasionar alterações em todo o sistema. Outro problema na manutenção de sistemas existentes vem da sua falta de portabilidade. Portabilidade significa poder alterar a plataforma ou tecnologia em que o software funciona para outras, caso seja necessário para os negócios da empresa, sem necessitar de altos gastos com reconstruções.

2

1.1 Objetivos

Com a finalidade de proporcionar níveis de reusabilidade cada vez mais elevados em projetos de software é que surgiu recentemente um novo paradigma aplicado à arquitetura dos sistemas, chamado SOA, ou Service Oriented Architecture (Arquitetura Orientada a Serviços). Trata-se de um tipo de arquitetura de software onde o mesmo é quebrado em partes de acordo com suas funcionalidades, as quais são chamadas de serviços. Os serviços por sua vez podem ser combinados para formar diferentes aplicações, permitindo a reutilização em um escala maior, deixando que serviços possam ser aprimorados de forma independente. Mas serviços são difíceis de gerenciar durante o desenvolvimento e sua portabilidade tem pouca importância, já que a comunicação ocorre por um protocolo padrão e difundido entre várias tecnologias.

Para facilitar o desenvolvimento de aplicação utilizando SOA, propõe-se a utilização do deste paradigma em conjunto com a visão de desenvolvimento de software onde utiliza-se a modelagem dos objetos do sistema para construí-lo, garantindo a sua interoperabilidade. Essa visão foi apresentada no ano de 2000 pela OMG (Object Management Group) através do artigo SOLEY (2000) intitulado “Model Driven Architecture” (Arquitetura dirigida a modelos), que deu origem a sigla MDA.

Este trabalho apresenta uma forma de desenvolvimento de aplicativos em uma arquitetura SOA. Para isso, utiliza-se o MDA para modelar de maneira padronizada cada um dos serviços e a partir desses modelos, que são independentes de plataforma, fazer uso de uma ferramenta disponível no mercado para transformá-los em executáveis para uma plataforma específica.

3

1.2 Justificativa

Arquitetos de aplicações acreditam que o SOA ajuda os negócios a responder mais rapidamente e com custo reduzido às mudanças do mercado, pois promove o reuso em um nível mais elevado (serviços) ao invés de objetos. Cada serviço pode ser implementado utilizando uma tecnologia diferente, bastando que o protocolo de comunicação seja entendido por todos.

Existem casos onde um serviço precisa ser portado de uma tecnologia para outra, como acontece ao optar-se por aproveitar sistemas em produção que não se encontram na arquitetura SOA e criar serviços para as suas funcionalidades. Para esses casos a utilização do MDA no desenvolvimento traz os melhores benefícios. Depois de se gastar recursos com a modelagem do serviço, o MDA pode gerar o serviço para a tecnologia escolhida bastando escolher uma ferramenta que reconheça os padrões definidos pela OMG. Isso aumenta a reusabilidade e diminui os custos de manutenção, já que uma única alteração nos modelos pode ser gerada novamente para todas as tecnologias em uso.

A seqüência deste trabalho se encontra divida em quatro capítulos. No capítulo 2 apresenta-se a fundamentação teórica, onde descreve-se brevemente as tecnologias envolvidas na pesquisa, como os conceitos de arquitetura de software, MDA, UML e SOA. Nos capítulo 3 e 4 tem-se a apresentação e a documentação de um aplicativo simples que é utilizado para exemplificar o processo proposto aplicando-se a integração de MDA e SOA. No capítulo final, as conclusões obtidas com a pesquisa e algumas sugestões para trabalhos futuros.

4

2 Fundamentação Teórica

Para que seja possível o entendimento das técnicas e tecnologias utilizadas, este capítulo apresenta os conceitos teóricos de maior relevância. As seções dividem-se para tratar dos seguintes assuntos individualmente: arquitetura de software, com a definição e alguns exemplos de arquiteturas utilizadas na construção de aplicativos; UML, onde se apresenta a linguagem de modelagem utilizada para documentar arquiteturas de programas; MDA, com uma explicação mais detalhada sobre esse paradigma de construção de software; em seguida os conceitos a respeito do SOA e exemplos de utilizações atuais da tecnologia; e finalmente uma seção com as considerações finais.

2.1 Arquitetura de Software

O conceito de arquitetura de software teve origem no ano de 1968 com uma pesquisa de Edsger Dijkstra e David Pantas onde enfatizaram que a estrutura de um sistema de software é parte crucial em um projeto. Para ilustrar essa importância, pode-se citar WOODS (2005), que a define da seguinte maneira: "Arquitetura de software é um conjunto de decisões de design, que se feitas incorretamente, pode causar o cancelamento do projeto",

Definir a arquitetura de um software é a tarefa de escolher como o mesmo será estruturado, ou seja, quais partes são necessárias para a sua constituição. Essas partes podem ser componentes, que são pequenas partes de código, como módulos, ou pedaços maiores, como programas independentes para gerenciamento de banco de dados. Outros elementos a serem definidos pela arquitetura são as interfaces entre as partes do sistema, descrevendo abstrações de como os componentes interagem entre si, por exemplo. Além disso, para um projeto de software,

5

deve-se definir se o sistema será dividido em camadas, que isolam funcionalidades e que podem ser distribuídas em diferentes máquinas, ou ainda se serão feitas chamadas a métodos remotos. Um arquiteto de software deve ser capaz de selecionar quais componentes se adequam melhor a uma situação e como as funcionalizados do sistema serão isoladas e distribuídas.

A arquitetura de software deve ser documentada para facilitar a comunicação entre todos os envolvidos no projeto. Uma documentação bem realizada garante que componentes e padrões possam ser reutilizados em todo o projeto, e que decisões críticas possam ser feitas no seu início. Os processos de construção de software baseados em documentos, como é o caso do RUP (Rational Unified Process) possuem artefatos específicos para a definição da arquitetura.

Para facilitar a criação desses documentos e seu entendimento por parte dos envolvidos, diversos tipos de linguagens foram criados ao longo do tempo, mas uma delas acabou se tornando consenso entre a maioria dos projetistas. Trata-se de um conjunto de símbolos que representam a visão do sistema de forma padronizada, o quais são definidos pela OMG e formam a linguagem chamada de UML, que será melhor explicada na próxima seção deste capitulo.

Existe uma série de arquiteturas comumente utilizadas em projetos de software. Pode-se citar como exemplos: sistema monolítico, arquitetura cliente-servidor, três camadas, n-camadas, arquitetura distribuída, arquitetura de plugin, componentizada e orientada a serviços. Este último tipo pode ser também chamado de arquitetura SOA, que é tema desse trabalho e será detalhado em um seção posterior deste capítulo.

6

2.2 UML

A UML é uma linguagem gráfica definida pela OMG (Object Management Group), que é um consórcio de empresas formado para controlar diversos padrões relativos à orientação a objetos. A linguagem UML surgiu da unificação e padronização de algumas linguagens de modelagem orientadas a objetos, com a finalidade de facilitar a troca de informações entre os envolvidos em projetos de software.

De acordo com FOWLER (2005), a UML pode ser utilizada de três modos diferentes por uma equipe de desenvolvimento de software: como esboço, como projeto e como linguagem de programação. No primeiro caso, a UML é utilizada para produzir esboços de diagramas e transmitir aspectos do sistema entre os desenvolvedores, ou ainda para facilitar o entendimento de código já construído. No segundo modo, é utilizada de maneira mais criteriosa e como parte da documentação do projeto. O projeto é realizado na fase inicial do desenvolvimento, e deve ser o mais completo possível e conter os detalhes necessários para o programador codificar. Os diagramas são responsáveis pela modelagem do sistema antes da fase de implementação e devem possibilitar sua visão completa.

O aperfeiçoamento do uso da UML na especificação de projetos de software aliado ao uso de ferramentas CASE’s que se utilizam dos diagramas para gerar código em determinada linguagem de programação nos leva ao terceiro modo de uso apresentado: a UML como linguagem de programação. Este modo exige ferramentas sofisticadas, que transformem os modelos UML diretamente em código executável. Essas ferramentas se baseiam na estratégia chamada MDA, descrita em maiores detalhes na próxima seção deste capitulo.

7

Com o uso da UML no decorrer dos anos, novas características foram adicionadas e assim foram especificadas novas versões da linguagem visual. As mudanças mais significativas ocorreram na versão 2.0, onde foram melhorados os digramas que modelam a lógica comportamental, sendo todas as mudanças aperfeiçoamentos para o uso de MDA. Na seqüência, apresentam-se as diferenças entre a UML 1.x e a UML 2.0.

Na UML 2 foram introduzidos três novos diagramas: diagramas de visão geral da integração, diagramas de temporização e diagramas de estrutura composta. Os diagramas de colaboração passaram a chamar diagramas de comunicação e os diagramas de pacotes e diagramas de objetos, que já eram amplamente utilizados, tornaram-se oficiais (FOWLER, 2005).

Para o objetivo proposto, os diagramas de maior importância são:

diagramas de casos de uso: utilizados para capturar os requisitos funcionais do sistema, mostrando também como ocorrem interações entre ele e os usuários;

diagramas de classes: são os diagramas de maior importância para a técnica de MDA e também os mais utilizados em processos de modelagem. Descrevem quais os tipos de objetos presentes, seus relacionamentos, atributos e operações;

diagramas de pacotes: propiciam uma forma de organizar as classes ou outros elementos da UML na modelagem de sistemas grandes, sendo que cada classe pode pertencer a um único pacote;

8

diagramas de seqüência: descrevem como os objetos do sistema se comunicam, mostrando a troca de mensagens entre eles através de uma linha de tempo com a finalidade de executar uma funcionalidade, ou seja, um caso de uso;

diagramas de Estado: representação gráfica do ciclo de vida de um objeto, mostrando seu comportamento e suas possíveis mudanças de estado.

A próxima seção aprofunda o conhecimento da técnica MDA e destaca as funcionalidades de cada diagrama para a construção do aplicativo, fazendo-se uso da UML como uma linguagem de programação.

2.3 MDA

A MDA é uma técnica de desenvolvimento de software criada pela OMG onde diferentes modelos de objetos são ligados para construir um sistema completo. A OMG é um grupo formado por empresas de desenvolvimento de software do mundo todo que tem como propósito definir padrões a serem adotados, tanto para MDA como para a linguagem de modelagem já estudada, a UML.

Segundo MELLOR (2004), o MDA se baseia na idéia de produzir aplicativos através de linguagens com alto nível de abstração e de facilitar o reuso de partes do mesmo. Desenvolver em alto nível significa utilizar ferramentas que trabalhem com linguagens simples e abstratas, onde referências com o mundo real sejam feitas com mais facilidade e que elas possam ser mapeadas para linguagens de baixo nível, ou linguagem de máquina, as quais são muito mais complexas e necessitam de muito mais tempo para a codificação. Em uma arquitetura MDA um sistema é

9

construído usando-se modelos UML ao invés de código, o que resulta em um alto nível de abstração e aumenta a reusabilidade, já que os modelos usam o paradigma de orientação a objetos. Esse paradigma tem como uma de suas qualidades fundamentais a possibilidade de reutilizar objetos em todo o sistema. Quanto mais coeso um objeto, mais alto seu grau de reutilização.

A independência de tecnologia obtida com o uso de modelos é mais uma das vantagens da técnica MDA, cuja premissa principal é transformar modelos abstratos em aplicativos, usando a UML como linguagem de programação. Os modelos mais abstratos são classificados como modelos independentes de plataforma ou tecnologia e são chamados de modelos PIM (Platform Independent Model). O processo de transformação desses modelos é realizado através de uma função de mapeamento, que resulta em modelos específicos de plataforma (PSM). Portanto, para gerar o sistema para diferentes plataformas a partir de um modelo PIM, basta que existam funções de mapeamento para todas as plataformas desejadas.

Um exemplo de função de mapeamento seria o mapeamento de um modelo UML para o seu correspondente em código Java. Um diagrama de classes pode ser mapeado completamente em código Java, onde cada classe do diagrama dá origem a declaração da classe de mesmo nome na linguagem objetivo.

Ainda de acordo com MELLOR (2004), a maneira correta de separar os modelos dependentes e os independentes de plataforma, é pensar da seguinte maneira:

10

PIM : um PIM é um modelo para um determinado propósito, sendo abstrato, ou seja, que pode representar diferentes plataformas. Como exemplo, tem-se que um modelo PIM não precisa capturar detalhes sobre segurança ou persistência.

PSM : é um modelo feito especialmente para uma plataforma. Para um sistema que utilize banco de dados, por exemplo, esse modelo deve conter referências para as tabelas do banco e classes para acesso a esse dados. Outro exemplo seria a definição de classes para o controle de acesso ao sistema, com níveis de acesso atribuídos a usuários.

Em um processo de desenvolvimento que não use MDA, existe o problema de manutenção entre o modelo do projeto e a sua implementação, sendo necessário um trabalho de manutenção no modelo sempre que alterações são feitas no código, ou vice-versa. Já na programação orientada a modelos, existe apenas o trabalho de se manter uma função de mapeamento separada, que transforme o modelo abstrato (PIM) no modelo especifico (PSM). Assim, apenas as alterações no modelo mais abstrato são importantes, e as mesmas podem ser desfeitas com mais facilidade, com as alterações refletidas no código rapidamente.

Durante o processo de modelagem, pode-se necessitar de algumas definições necessárias para o aplicativo que inexistem na UML, como por exemplo, a informação de que uma classe é persistente. Para contornar esse problema, a UML permite extensões através de “profiles”, onde o uso de palavras-chave (estereótipos nas versões 1.x da UML) acrescenta funcionalidades ao vocabulário padrão e também existem as chamadas constraints que determinam quando um modelo está bem formado. Mas, mesmo com esses mecanismos, existem casos mais complexos. Um exemplo mais complexo ocorre quando há a necessidade de uma interface de usuário (UI) especifica para uma funcionalidade. A função de mapeamento gera UIs padronizadas, até mesmo

11

porque esses detalhes de implementação dizem respeito especificamente a plataforma alvo, não podendo ficar em modelos genéricos. Para esses casos, MDA faz uso de Modelos Elaborados, que nada mais são do que alterações manuais feitas modelo gerado, através da adição de código normalmente, e a implementação de um mecanismo para que na próxima transformação essas alterações não sejam perdidas.

Na seção seguinte, a arquitetura de aplicações SOA será apresentada de modo que se tenha conhecimento necessário para modelar serviços e gerá-los para uma tecnologia específica através dos conceitos de MDA aqui descritos.

2.4 SOA

O cenário de negócios mundial muda continuamente e rapidamente. Para que as organizações possam acompanhar essas mudanças, o setor de tecnologia da informação (TI) deve se adequar de maneira ágil. Essa flexibilização para acompanhar novos modelos de negócios e operações da empresa pode ser conseguida mais facilmente desenvolvendo-se soluções com a arquitetura identificada pela sigla SOA (Service Oriented Architecture), ou arquitetura orientada a serviços. Segundo BROWN (2005), neste tipo de arquitetura, os sistemas deixam de ser monolíticos, ou seja, focados em resolver todas as necessidades do negócio, para serem sistemas compostos, formados pela integração de diferentes fontes para formar uma solução completa.

Existem outras formas de arquiteturas compostas mais tradicionais, onde o aplicativo é dividido em camadas, como por exemplo, em camada de apresentação com o servidor Web, camada com o servidor de aplicação e a camada de acesso aos dados. No entanto, são difíceis de projetar, construir e manter.

12

A arquitetura SOA pode ser considerada a evolução da divisão em camadas. O sistema passa a ser uma composição de diferentes serviços, cada um atendendo uma necessidade específica, e que agrupados atendem a um processo de negócio mais sofisticado. Isso torna o sistema mais componentizado e, por conseqüência, mais flexível e com maior probabilidade de reuso de suas partes em outras situações. Além disso, serviços são mantidos e testados individualmente e podem ser implementados em diferentes plataformas ou linguagens, bastando que cada um possua uma interface bem definida.

Com serviços independentes, entende-se que os mesmos podem estar fisicamente distribuídos, sendo necessário um meio de comunicação para que ocorra a devida integração. Exemplos de meios amplamente difundidos são redes internas (intranets) e a própria internet. Serviços disponibilizados nesses contextos são chamados de Webservices. Eles usam um protocolo, como SOAP (Simple Object Access Protocol) ou REST (Representational State Transfer), e trocam documentos escritos em XML (Extensible Markup Language), onde o formato desses documentos é definido em arquivos do tipo WSDL (Web Services Description Language). Esses documentos e protocolos são definidos pelo W3C (World Wide Web Consortium), um consórcio de empresas que da mesma maneira que a OMG, define os padrões a serem seguidos pelas ferramentas e programadores, onde os padrões se restringem àqueles relacionados à internet (KRAFZIG, 2004).

No cenário empresarial, a agregação de serviços é útil para interligar soluções legadas e processos dentro da companhia. Os sistemas dos departamentos de Recursos Humanos (RH), de Tecnologia da Informação e de Controle Financeiro, por exemplo, podem ter seus processos mapeados para se comunicarem facilmente, independentemente das peculiaridades das aplicações

13

de cada área. Dessa forma, um processo de contratação de pessoal pode ser implementado por um software que orquestra o conjunto de serviços disponibilizados pelos sistemas da empresa. Ao se contratar uma pessoa, ações são disparadas para o cadastro em RH e ainda para o cadastro de seu salário nas finanças da empresa. Nesse contexto, modificações futuras podem ser mais facilmente realizadas.

A adoção de SOA pelas empresas abre ainda um novo modelo de negócios, crescente nos dias de hoje: outsourcing de serviços. Isso significa que empresas podem desenvolver um serviço específico e bem focado e cobrar pelo seu uso. Um bom exemplo é o serviço de busca de CEPs oferecido pela empresa dos correios, para que qualquer aplicativo ligado a internet possa consumi-lo e preencher campos de endereço a partir de um número de CEP informado.

Na internet o número de webservices disponibilizados tem se multiplicado rapidamente. Diversos websites passaram a prover serviços especializados que originam novos tipos de aplicativos web. Esses novos aplicativos consomem diferentes serviços, combinando-os a fim de disponibilizar algo mais completo e melhor direcionado. O termo mashup designa essas aplicações compostas e são os maiores responsáveis pela chamada Web 2.0. Um exemplo seria a união de serviços de localização (como mapas) a catálogos virtuais de compras. Assim, é possível apresentar resultados mais precisos, indicando a loja mais próxima do consumidor.

Como mostrado, o ponto principal na elaboração de serviços está na definição das interfaces de comunicação, que devem ser bem modeladas e documentadas. A modelagem de serviços pode ser feita utilizando-se UML, com diagramas de classes e de componentes. Tal modelagem propicia ainda o uso da técnica MDA para a transformação dos modelos para uma linguagem específica e compilável. Existem ferramentas e frameworks no mercado com a função

14

de prover esse tipo de processo de desenvolvimento, o qual será exemplificado no próximo capítulo.

2.5 Considerações Finais

Depois de apresentados os conceitos de arquitetura de software, UML, MDA e SOA, falta então descrever como esses conceitos serão unidos neste trabalho. Conhecer arquiteturas é importante para entender a diferença entre outros padrões e o padrão defendido e a ser utilizado, SOA. Desenvolver aplicativos modularizados e integrados através de serviços não é uma tarefa fácil de ser gerenciada, nem que demande pouco trabalho. Com a finalidade de agilizar o processo de desenvolvimento e fazer com que futuras alterações possam ser implementadas rapidamente sem perder a flexibilidade da arquitetura é que se insere a técnica MDA. Conhecimentos de UML são a base para a construção de modelos úteis e transformáveis por MDA, a fim de obter-se os serviços compiláveis em algum modelo específico.

No nicho de ferramentas de produtividade existem aquelas que auxiliam desde a modelagem do sistema com UML até a escrita de testes, e já possuem funções de mapeamento para linguagens de programação comumente utilizadas. No capítulo 3 tem-se a descrição dos requisitos de um sistema simples para controle de finanças pessoais, que será utilizado como estudo de caso da aplicação das técnicas apresentadas. No capítulo 4 descreve-se o uso de uma ferramenta com suporte a transformações MDA na implementação do projeto.

15

3 Estudo de Caso

Para aplicar os conceitos propostos neste trabalho, descrevem-se neste capítulo os requisitos básicos para um sistema que servirá de exemplo na aplicação dos conceitos apresentados neste trabalho. Portanto, sua construção será feita utilizando técnicas de MDA com diagramas UML necessários e ainda em uma arquitetura orientada a serviços. Nas próximas seções tem-se uma análise de requisitos breve, partindo-se da definição do escopo, casos de uso e um esboço das classes.

3.1 Escopo

O sistema aqui proposto tem como escopo o controle financeiro de pessoas físicas, onde as mesmas cadastraram suas receitas e despesas realizadas em cada dia para saberem quanto de saldo possuem. Cada despesa ou receita representa um movimento nas finanças e deve estar relacionado a uma ou mais contas, o que permite que se totalizem os movimentos de cada conta. Além disso, os movimentos podem ser cadastrados com uma data de vencimento futura com a finalidade de agendá-los. O sistema deve ainda disponibilizar opções de listagem de movimentos sempre ordenados por data de vencimento. Visualizar os movimentos com vencimento em um período de tempo escolhido ou aqueles que estejam associados a uma conta, também deve ser possível. Para os movimentos visíveis, é preciso mostrar tanto o saldo disponível, que é a soma de todos os movimentos visíveis, quanto o saldo atual, que é a soma dos movimentos vencidos até a data atual. Por fim, o sistema deve disponibilizar as funcionalidades para acesso através da Web ou ainda provendo serviços para outros aplicativos através de uma interface Webservice.

16

3.2 Casos de Uso e Requisitos Não-Funcionais

Como pode ser percebido na descrição do escopo, trata-se de um sistema simples, onde o único interressado (stakeholder) é o usuário comum, que o utiliza com o objetivo de gerenciar seus movimentos financeiros e classificá-los em contas, para assim acompanhar o histórico de movimentos e obter saldos por intervalo de tempo e por conta. Logo, para um melhor funcionamento do sistema é necessário um requisito de segurança, para que um usuário possa ser identificado, impossibilitando então que dados sejam vistos por pessoas desautorizadas.

A partir dessas informações, listam-se os casos de uso que o sistema deve satisfazer para alcançar seus objetivos. O diagrama de casos de uso pode ser observado na Figura 1. **Falta corrigir o relacionamento entre os Casos de uso

Figura 1 - Diagrama de Casos de Uso do sistema de controle financeiro.

17

UC-01 Gerenciar Movimento: o usuário pode cadastrar movimentos, editá-los posteriormente ou ainda removê-los. Esse caso de uso está mais bem detalhado através de seu cenário de sucesso e extensões no Quadro 1.

UC-02 Controlar Conta: o usuário deve associar pelo menos uma conta a cada movimento cadastrado. No entanto, o controle é feito sem que o usuário tenha acesso direto ao cadastro de contas, que só são criadas durante a gerência de movimentos.

UC-03 Visualizar Movimentos: cada usuário pode visualizar os movimentos a que está associado.

UC-04 Visualizar Movimentos por Período: o usuário especifica um intervalo de datas para visualizar os movimentos que possuem a data de vencimento dentro do período.

UC-05 Visualizar Movimentos por Conta: o usuário pode filtrar os movimentos que deseja visualizar escolhendo uma ou mais contas. Assim apenas os movimentos associados às mesmas serão exibidos.

UC-06 Calcular Saldo Disponível: a partir dos movimentos em exibição obtidos através de UC-04 ou UC-05, o saldo disponível é obtido pela soma dos valores desses movimentos.

UC-07 Calcular Saldo Atual: depois de obter uma lista de movimentos em UC-04 ou UC-05, o saldo atual é a soma dos valores dos movimentos da lista que já venceram, ou seja, que possuem a data de vencimento menor que a data atual.

18

UC-08 Autenticar Usuário: para que o usuário possa realizar qualquer operação do sistema, ele deve de identificar através de um nome (login) e uma senha. Assim o sistema sabe a qual usuário deve associar novos movimentos e quais podem ser listados.

Para complementar a análise desse controle financeiro pessoal, necessita-se documentar quais os requisitos não-funcionais que devem ser satisfeitos. São eles:

Interface Web: o sistema deve possibilitar o uso completo de suas funcionalidades através uma interface Web, ou seja, deve ser acessível de qualquer navegador.

Interface Webservice: uma interface de serviços deve ser disponibilizada para que aplicações em uma arquitetura SOA possam fazer uso das funcionalidades do controle financeiro.

19

Caso de Uso Gerenciar Movimento Ator Primário: Usuário Escopo: Sistema de controle financeiro pessoal Objetivo: O usuário armazena, altera ou remove um movimento financeiro. Acionador: O usuário deseja cadastrar um novo movimento. Cenário de Sucesso Principal: 1. Usuário: Informa dados do movimento 2. Usuário: Informa nome das contas às quais o movimento está associado 3. Sistema: Confirma a inclusão do movimento 4. Sistema: Atualiza cálculo de saldo disponível e atual. Extensões: *a. A qualquer momento, o usuário pode cancelar o cadastro. 1a. Dados do movimento estão incompletos 1a1. Sistema informa quais dados estão faltando 1a2. Usuário fornece dados ausentes 1a2a. Usuário não fornece dados ausentes 1a2b. Sistema não permite seqüência do cadastro 2a. Alguma conta informa não existe 2a1. Sistema cria a conta com o nome informado 2b. Nenhuma conta é informada 2b1. Sistema informa que pelo menos uma conta é necessária 2b2. Usuário informa o nome da conta 2b2a. Usuário não informa nenhum valor 2b2b. Sistema não permite seqüência do cadastro •

Quadro 1 - Detalhamento do caso de uso “Gerenciar Movimento”.

3.3 Diagrama de Classes

Com a lista de requisitos funcionais e não-funcionais detalhados na seção 3.2, pode-se chegar a um esboço do diagrama de classes, que pode ser observado na Figura 2. Ele contém as classes TMovimento, que representa todos os movimentos cadastrados pelo usuário e contém as propriedades necessários para satisfazer todos os casos de uso, com exceção do UC-02, que depende somente da classe TConta. A classe TUsuario implementa o controle de acesso ao sistema e persiste os dados de cadastro dos usuários. Já a classe TControleFinanceiro é

20

imprescindível para que os requisitos não-funcionais sejam atendidos. Trata-se da interface do sistema onde são disponibilizados os serviços que podem vir a serem consumidos dentro de uma arquitetura SOA, funcionando como o padrão de projeto façade, que limita o que os aplicativos externos visualizam do sistema. Nesta classe, tem-se uma prévia dos métodos da interface da aplicação.

Esse esboço de diagrama tem como objetivo apenas apresentar as possíveis classes do sistema e seus atributos. Relacionamentos e cardinalidades são importantes para a visualização das dependências elas. Já os métodos de cada classe serão obtidos quando os diagramas de seqüência de cada caso de uso forem desenhados, os quais serão necessários para uma modelagem mais completa do sistema, a ser mostrado no próximo capítulo deste trabalho.

No capítulo 4, o estudo de MDA e SOA será colocado em prática, utilizando a ferramenta de desenvolvimento chamada IBM® RSA (Rational Software Architect). Ela permite que os requisitos capturados sejam modelados e transformados em um sistema funcional, dentro dos conceitos de uma arquitetura de serviços.

21

Figura 2 - Esboço do diagrama de classes do sistema de controle financeiro.

4 Aplicação do MDA e SOA no estudo de caso controle financeiro pessoal

Exemplificar a aplicação dos estudos realizados nos capítulos anteriores deste trabalho é o objetivo das seções seguintes. Nelas tem-se os detalhes da modelagem dos casos de uso e das classes do sistema utilizando a ferramenta IBM® Rational® Software Architect (RSA) (RATIONAL, 2007). Partindo-se da definição dos requisitos do projeto já realizada, detalha-se como será feita a arquitetura do sistema para prover SOA, o processo de transformação dos modelos UML em modelos específicos para a plataforma também a ser escolhida, e por fim mostra-se como os serviços disponibilizados pelo controle financeiro pessoal podem ser consumidos para funcionar como uma aplicação Web.

22

4.1 Modelagem do sistema na ferramenta RSA

Os passos aqui descritos visam mostrar como a ferramenta IBM® RSA pode ajudar na análise arquitetural e na documentação de um sistema, focando-se então nas tarefas de análise de requisitos e design da aplicação. A ferramenta RSA utiliza amplamente os princípios de desenvolvimento dirigido por modelos (MDA), que foram estudados nos capítulos anteriores. Através dela define-se os modelos do sistema utilizando a notação UML em vários níveis de abstração, com a possibilidade de gerar modelos específicos de plataforma (PSM) a partir de modelos mais abstratos (PIM).

Como processo de desenvolvimento, utiliza-se então o Rational® Unified Process (RUP) de forma simplificada, focando principalmente a disciplina de Análise e Desenvolvimento. Assim, parte-se do ponto que os requisitos foram capturados no capítulo anterior, representando a fase de concepção do processo. A próxima etapa é então a fase de Elaboração. Não é objetivo desse documento detalhar as fases, iterações ou disciplinas do RUP. O objetivo é mostrar como definir uma arquitetura SOA para o sistema e construí-lo utilizando o MDA.

Nas próximas subseções tem-se a definição dos modelos necessários para que a ferramenta possa realizar a transformação MDA de forma eficiente. Na próxima seção deste capítulo mostra-se então o resultado das transformações que originam os modelos de implementação.

23

4.1.1 Modelo de casos de uso

O primeiro modelo a ser cadastrado na ferramenta representa os requisitos do sistema. O diagrama de casos de uso obtido na fase de concepção é apresentado na Figura 1 e faz esse papel. O mesmo foi então redesenhado para que a realização de cada caso de uso pudesse ser concluído. Baseando-se então nos casos de uso e nos requisitos não-funcionais pode-se chegar a uma solução candidata para a arquitetura da aplicação. Como o acesso as informações e funcionalidades poderá ser realizado tanto através de WebServices quanto por uma interface Web a ser acessada via navegador, a arquitetura que atende esses objetivos é a chamada arquitetura de n camadas. Essas camadas são divididas da seguinte forma:

Camada de acesso aos dados, onde deve ser alocado o sistema gerenciador de banco de dados e uma camada do sistema para controlar o acesso aos mesmos e fazer mapeamentos quando necessário;

Camada de Negócios, onde ficam as partes do sistema responsáveis pelas regras de negócio. Ela obtém os dados da camada de acesso, processa e apresenta através da camada de apresentação.

Camada de Apresentação, onde se configura o servidor Web e a parte do aplicativo responsável por criar as páginas Web e gerenciar as sessões de acesso. Além disso, nesta camada são disponibilizadas as interfaces para chamadas de serviços da arquitetura SOA;

24

Camada Cliente, formada tanto por navegadores mostrando as páginas geradas pelo servidor Web, quanto por outros aplicativos que consomem os serviços disponibilizados via Webservices.

Depois de modelar os casos de uso na ferramenta RSA e escolher-se a arquitetura que atende os requisitos do projeto, passa-se a fase de realização dos casos de uso. Mais detalhes na próxima subseção.

4.1.2 Modelo de Análise

O objetivo do modelo de análise é representar de forma abstrata todo o projeto. Essa representação é feita realizando-se os casos de uso, ou seja, definindo quais classes são necessárias para que cada uma das funcionalidades possa ser implementada. No capítulo anterior mostrou-se um esboço do diagrama de classes do sistema, na Figura 2. A partir deste diagrama, foram feitas adaptações para que a arquitetura escolhida possa ser implementada. Para isso, definem-se quais classes ficarão em cada camada da aplicação, atribuindo a elas estereótipos que indicam sua função. Foram adicionadas classes no esboço feito durante a captura de requisitos, como as de interface da aplicação localizadas na camada de apresentação, que recebem o estereótipo Bounday, classes de controle (Control) que ficarão na camada de negócios e as classes de dados com o estereótipo Entity, que farão o acesso a dados persistidos. O novo diagrama de classes é mostrado na Figura 3.

A captura do modelo de análise também abrange os diagramas de seqüência, que mostram os cursos básicos e alternativos na utilização de cada caso de uso. Criando esses diagramas é que se define como as classes interagem através de chamadas de métodos públicos. Vejamos o

25

diagrama de seqüência do curso básico para o caso de uso “Gerenciar Movimento” na Figura 4. Note que o usuário faz uso do sistema apenas pelas funcionalidades disponíveis na classe da camada de apresentação, no caso ControleFinanceiroUI, que por sua vez verifica se o usuário foi autenticado através de um método da classe de controle de usuários e só então dispara o método para criar ou remover um movimento, localizados na classe ProcessarMovimento.

Figura 3 – Diagrama de classes com estereótipos aplicados

Depois de criados todos os diagramas de seqüência, pode-se apresentar o diagrama de classe mais detalhado, onde os métodos das classes já se encontram declarados, juntamente com seus parâmetros e tipos de retorno. Foi necessário adicionar um parâmetro chamado “uid” a todos

26

os métodos da interface do sistema, para fins de autenticação. Esse parâmetro é a identificação que o usuário recebe ao se autenticar com um login e senha válidos.

Alguns tipos não são nativos da linguagem UML e tiveram que ser criados, como é o caso dos tipos primitivos Date para campos com datas e Double para campos com casas decimais. Além desses, definiu-se um tipo complexo chamado ListaMovimentos para o retorno de um conjunto de dados de movimentos e saldos, necessários para os casos de uso que herdam de “Visualizar Movimentos”. O diagrama de classes completo está na Figura 5.

Figura 4 – Diagrama de seqüência para o fluxo básico do caso de uso “Gerenciar Movimento”.

27

O modelo de análise obtido se encontra em uma forma abstrata e independente de plataforma ou tecnologia. Ele pode ser reutilizado para diversas implementações do sistema. Na próxima seção, utiliza-se esse modelo para a obtenção de um modelo de implementação, que já represente o sistema em uma plataforma específica.

Figura 5 – Diagrama de classes com métodos.

28

4.2 Processo de transformação MDA

Passada a fase de elaboração do projeto apresentada anteriormente, chega-se a fase de implementação, onde o aplicativo é construído de fato, utilizando uma plataforma específica de forma que satisfaça os requisitos estabelecidos. Este capítulo apresenta a construção do sistema de controle financeiro pessoal proposto e já especificado através de modelos de casos de uso e modelos de análise, ambos criados na ferramenta do estudo de caso.

No principio desta fase, portanto, é necessário saber qual tecnologia será empregada na construção do aplicativo, possibilitando que técnicas de transformação MDA sejam aplicadas, a fim de reduzir o custo da implementação ao gerar automaticamente o máximo de código possível. Nas subseções a seguir, explica-se esse processo que culmina na obtenção de modelos PSM para a tecnologia escolhida.

4.2.1 Escolha da tecnologia

Levando em conta requisitos não-funcionais, como a necessidade de acesso às funções do software de controle financeiro através da internet e o uso de webservices para formar uma arquitetura orientada a serviços, verificou-se que a melhor arquitetura para atender essas necessidades seria a utilização de n-camadas. Assim, cada uma das camadas conteria uma parte do sistema, separadas de acordo com suas funções, como prover acesso a dados, controlar os dados e aplicar as regras de negócio e apresentar as informações.

Para melhor implementar essa divisão, propõe-se como tecnologia a plataforma Java, sendo mais especificamente necessária para o projeto em questão a plataforma chamada Java

29

Enterprise Edition (J2EE), que usa programas Java em uma arquitetura Web, ou seja, que possibilita a execução em um servidor de aplicações para a Internet, tornando-os acessíveis via navegadores ou clientes Java.

De acordo com os requisitos, necessita-se ainda que clientes construídos em outras tecnologias possam consumir as funcionalidades do sistema proposto, criando uma arquitetura SOA, para que o mesmo sistema possa ser consumido de diferentes formas. Com esse fim, optase pela implementação através da construção de Enterprise Java Beans(EJB), que são como componentes que agrupados formam uma aplicação J2EE mais robusta, e que fazem uso de recursos da tecnologia Java para facilmente gerar meios de comunicação entre as camadas definidas. Essa comunicação pode ser tanto local, quando as camadas internas necessitam comunicar-se entre si ou com o banco de dados, quanto permitindo a definição dos chamados “Beans de sessão”, que são importantes na camada de apresentação para a comunicação com agentes externos. Os “Beans de sessão”, quando definidos como independentes do estado do sistema, possibilitam que seus métodos sejam publicados como serviços, recebendo chamadas pelo protocolo SOAP.

A ferramenta RSA tem a capacidade de modelar projetos J2EE diretamente. Como essa é plataforma escolhida para a implementação, cria-se um novo projeto J2EE na mesma área de trabalho do projeto com os modelos de caso de uso e análise, mas com o nome de “WebControlFin”, e marca-se no assistente de criação que deseja-se um EJB padrão, que se chamará “WebControlFinEJB”. Além disso, aplicativos J2EE precisam de um servidor de aplicação para funcionar, que é responsável por prover serviços e controlar os Beans. A

30

ferramenta RSA se integra facilmente com o servidor IBM® WebSphere®, bastando-se indicar ao assistente para que classes e bibliotecas sejam adicionas ao projeto.

Na próxima subseção mostra-se como criar um processo que transforme os modelos já existentes e independentes de plataforma em classes EJB e classes Java, que farão parte do projeto recém criado.

4.2.2 Criação do processo de transformação

Para realizar a transformação dos modelos PIM para PSM, a RSA necessita da aplicação de Profiles. Profiles são conjuntos de pré-definições aplicáveis a modelos, como estereótipos ou padrões. Existem profiles para diversas tecnologias, incluindo EJB, que faremos uso.

Aplica-se o profile EJB no projeto de controle financeiro com os modelos básicos e então estereótipos especiais são disponibilizados. Esses estereótipos guiam o processo de transformação e aplicamos os mesmos em classe ou atributos com funções especiais. As classes que recebem o estereótipo “Serviço” darão origem a Beans de Sessão e classes com o estereótipo “Entidade” serão “Beans Entidade”, responsáveis pela persistência de dados. Pode-se também informar em classes entidades, qual atributo será usado como chave primária no mapeamento para o banco de dados, como o estereótipo “ID”. A tarefa de mapeamento dos Beans de entidade dessas classes é simples, porque a RSA gera os artefatos necessários para a construção e acesso de bases no gerenciador IBM® DB2® automaticamente, deixando o processo transparente para o desenvolvedor.

31

Depois de classificar as classes e atributos, basta criar o processo de transformação também através de um assistente. Nele defini-se o projeto origem, o destino e alguns parâmetros adicionais. Criando-se uma transformação do tipo UML para EJB, tendo como origem o projeto de modelagem e como destino o projeto EJB criado juntamente com o J2EE, temos uma transformação pronta para ser acionada.

“O arquivo de transformação deve ficar no projeto origem e tem o formato “<Nome_da_Tranformação>.ts”. Dentre as opções fornecidas pela RSA para esse arquivo, aciona-se a de transformação através do menu de contexto. Na próxima seção inspeciona-se as classes geradas através da execução do processo.

4.2.3 Modelos gerados pela transformação

O processo de transformação gera classes EJB para as classes do modelo de análise estereotipadas e classes auxiliares em Java para as classes sem estereótipo. No projeto exemplo observa-se a criação de um Bean de sessão para a classe ControleFinUI e três Beans de entidade para as classes Usuário, Conta e Movimento. As classes com o estereótipo Control, que não é um estereótipo do profile EJB, geram classes Java simples. Veja na Figura 6 as classes Bean geradas.

32

Figura 6 – Classes Bean geradas no processo de transformação

As classes Java geradas possuem métodos vazios aguardando implementação e comentários que separam o código gerado do código adicionado pelo desenvolvedor. A ferramenta mostra os erros de compilação dos arquivos antes mesmo do projeto ser compilado. Como tipos primitivos como Date e Double foram gerados com esses mesmos nomes, é necessário adicionar uma cláusula import em java.util.date em arquivos com classes que usem o tipo Date. Depois de corrigidos os erros, pode-se ver como ficou a estrutura do EJB, com as classes já agrupadas nos pacotes “entidades”, “comum” e “beans”. Esses pacotes agrupam as classes da camada de acesso a dados, as classes Java com as regras de negócio e o Bean de sessão da camada de apresentação, respectivamente. Veja a estrutura na Figura 7.

33

Figura 7 – Estrutura dos arquivos gerados pela transformação

34

4.3 Publicação de serviços do aplicativo

Os textos anteriores mostram como o sistema de controle financeiro pôde ser implementado partindo-se de modelos na linguagem UML diretamente para a linguagem Java, fazendo de transformações MDA, possibilitado pelo uso da ferramenta de desenvolvimento IBM® RSA®.

Para completar então a proposta deste estudo de caso, o sistema gerado deve ainda prover serviços com a finalidade de implementarmos uma arquitetura SOA. Para isso, usa-se mais uma funcionalidade da RSA, agora para tornar métodos do Bean de sessão em serviços acessíveis pelo protocolo SOAP.

Existem alguns requisitos para que a interface de chamada dos serviços, que é definida em um arquivo WSDL, possa ser criada partindo-se de um EJB. Primeiramente esse EJB deve estar inserido em um projeto web J2EE. Como criamos o EJB juntamente com o projeto WebControlFin, isso já está definido. Depois, deve-se garantir que o Bean de sessão a ser utilizado, que no nosso caso será a classe ControleFinUI, é independente do estado da aplicação, ou seja Stateless. A necessidade de independência de estado é um requisito da própria arquitetura SOA, para que ao consumir os serviços, o cliente não precise se preocupar com a seqüência das requisições.

Preparados os pré-requisitos, aciona-se a opção de novo serviço da Web. A janela inicial do assistente de criação do mesmo pode ser observada na Figura 8. Escolhe-se como tipo do serviço o item “De baixo para cima Serviço da Web” e indica-se a classe EJB com os métodos.

35

Existem outras opções, mas usa-se esta para criar os serviços partindo-se de um EJB. Pode-se também criar o serviço a partir do arquivo WSDL já existente.

Figura 8 – Assistente de criação de serviços da Web

Solicita-se ao assistente que ele crie testes para os serviços e também um cliente, que será um novo projeto Java, já pronto para consumir os serviços do controle financeiro.

Na Figura 9 mostra-se a captura do passo do assistente onde marca-se quais métodos do EJB serão transformados em serviços, publicados portanto no arquivo de definição do

36

WebService que tem a extensão WSDL. Neste arquivo ficam gravados a estrutura dos serviços, seus parâmetros e tipos aceitos, bem como os tipos de retorno. Aplicações cliente precisam usar esse arquivo para saberem como fazer chamadas corretas ao sistema.

Figura 9 – Escolha dos métodos a serem publicados como serviços

Encerrado o assistente, a ferramenta já instancia os aplicativos para testes, tanto do serviço Web gerado, quando do cliente do serviço, que recebeu no nome automático de WebControlFinEJBEJBClient. Pode-se obter um gráfico do arquivo WSDL ligado ao serviço

37

ControlFinUIService, que está na Figura 10. Note os métodos publicados, os parâmetros e os tipos simples e complexos.

Finalizando, utiliza-se a ferramenta RSA para distribuir a aplicação J2EE que contém o serviço. Com o servidor WebSphere® em execução, acessa-se o aplicativo no endereço local http://localhost:9080/JControlFinWeb/services/ControleFinUI. Ao acrescentar “/wsdl” a esse endereço, qualquer aplicativo consumidor encontra a definição dos serviços disponíveis.

Figura 10 – Gráfico para o arquivo de definição do serviço gerado

A próxima seção visa exemplificar o consumo do Webservice, efetuando chamadas a serviços e mostrando as respostas obtidas. Utiliza a interface Web criada pelo assistente de

38

criação de serviços web, de maneira simples, porém funcional, satisfazendo assim o requisito do sistema para uma interface acessada por navegadores.

4.4 Exemplo de consumo dos serviços

A aplicação J2EE criada para ser cliente do projeto de controle financeiro é um sistema simples, mas que exemplifica claramente o uso dos serviços à disposição. O cliente foi instalado no mesmo servidor Websphere® onde está o provedor de serviços do controle financeiro pessoal, mas nada impede que as requisições sejam feitas via internet, deixando cada aplicação em uma máquina específica, onde o cliente deve conseguir acessar o serviço em um endereço válido.

Na figura 11 observa-se uma captura do navegador com a aplicação cliente carregada. Na parte esquerda tem-se uma lista com os serviços disponíveis, a parte central fica com os formulários para preenchimento dos valores dos parâmetros do serviço escolhido e no quadro inferior, as respostas das requisições. Ainda na Figura 11 nota-se que foi invocado o serviço de autenticação de um usuário (Login) e o provedor do serviço respondeu que os mesmo eram inválidos.

O consumo dos serviços pode ser feito por qualquer aplicativo que reconheça os arquivos de descrição WSDL e que possam enviar mensagens XML através da internet pelo protocolo http. Apesar de ser comum o uso de clientes em formato de websites, ferramentas para construção de aplicativos desktop, como Delphi® e Microsoft® Visual Studio®, podem importar arquivos WSDL e criar implementações para consumo rapidamente.

39

Figra 11 – Aplicativo web consumidor de serviços do controle financeiro

4.5 Considerações Finais

O estudo de caso apresentado neste capítulo serviu para exemplificar o uso dos conceitos estudados em um projeto real. Destaca-se a facilidade de uso proporcionada pela ferramenta RSA, que se mostrou um excelente produto para que fábricas de software apliquem as técnicas MDA em seus projetos, codificando aplicações na plataforma Java ou C++. A integração com outros produtos da IBM também merece destaque, como a preparação de distribuições para o servidor de aplicação WebSphere® e a persistência de objetos feita de forma transparente no gerenciados de banco de dados DB2®.

Após a transformação do modelo de análise, mostrou-se uma forma de incorporar o aplicativo em uma arquitetura SOA, publicando serviços com o assistente da ferramenta RSA e

40

exemplificou-se o consumo das funcionalidades por meio de uma página Web, de outro projeto J2EE.

5 Conclusões e Trabalhos Futuros

O desenvolvimento orientado a modelos está se tornando cada vez mais uma forma viável para a construção de aplicativos onde se reduz o tempo gasto com implementações, para que o foco do projeto possa estar na obtenção de requisitos, documentações e teste do sistema. Assim, o MDA é uma técnica que agrega qualidade ao processo de desenvolvimento de software. Menciona-se também o fato de ferramentas MDA possibilitarem que um mesmo modelo seja transformado para diferentes tecnologias específicas, de acordo com a necessidade do desenvolvedor, provendo assim reuso em alto nível.

Para complementar as vantagens do uso do MDA, pode-se utilizar a arquitetura SOA, a fim de tornar os sistemas escaláveis e de fácil manutenção. Sistemas complexos podem ser divididos em partes menores e com finalidades específicas, alocados em espaços físicos diferentes e ainda estarem sobre a responsabilidade de equipes de desenvolvimento distintas. Essa abordagem torna os sistemas de diferentes empresas mais facilmente integráveis, já que a comunicação segue um padrão conhecido.

Conclui-se que o uso de técnicas de MDA para a construção de software em uma arquitetura de serviços (SOA) é aplicável em projetos reais, não importando seu tamanho ou sua complexidade. Existem tanto ferramentas livres como AndroMDA, StarUML e OpenMDX, quanto ferramentas comerciais como IBM® RSA®, Compuware® OptimalJ™ e Interactive Objects® ArcStyler™, que provêem essa metodologia de forma a obter o máximo de resultado

41

na a aplicação dos conceitos. Apenas algumas incorporam funções de modelagem, mas todas possibilitam transformações de modelos UML em modelos específicos que variam, tanto em arquitetura, quanto na tecnologia empregada.

Como trabalhos futuros, sugerem-se estudos com exemplos feitos em outras ferramentas de transformação MDA, com outros servidores de aplicação ou tecnologias, ou ainda utilizando formas de transformação diferenciadas, como a conversão de um modelo UML diretamente em definições de serviços com arquivos WSDL.

42

Referências

SOLEY, R. Model Driven Architecture. In: Object Management Group, MDA Presentations and Papers. 2000. Disponível em <ftp://ftp.omg.org/pub/docs/omg/00-11-05.pdf>. Acesso em : 21 fev. 2007.

BIEBERSTEIN, N. et al. Service-Oriented Architecture (SOA) Compass: Business Value, Planning, and Enterprise Roadmap. IBM Press, 2005. 272 p.

MELLOR, Stephen J. et al. MDA Distilled - Principles Of Model-Driven Architecture. Boston: Addison Wesley, 2004. 176 p.

BOLONHA J. C. et al. Delphi 8 Para Plataforma .Net - Curso Completo. 1ed. Bonsucesso: Axcel, 2004. 1376 p.

WOODS, Eóin, ROZANSKI Nick. Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives. 1ed. Boston: Addison Wesley, 2005. 576p

CLEMENTS, Paul, KOGUT, Paul. The Software Architecture Renaissance. Pittsburgh : Carnegie Mellon University, 1994. p.11-18

FOWLER, Martin. UML Essencial: Um breve guia para a linguagem-padrão de modelagem de objetos. 3ed. Porto Alegre: Bookman, 2005. 154p.

BROWN, Alan W. et al. SOA Development Using the IBM Rational Software Development Platform : A Practical Guide. 2005. 36p

43

KRAFZIG, Dirk et al. Enterprise SOA: Service-Oriented Architecture Best Practices. New Jersey: Prentice Hall PTR, 2004. 408p.

RATIONAL Software Architect. In: IBM Rational Software Architect. Disponível em <http://www-306.ibm.com/software/awdtools/architect/swarchitect/>. Acesso em 04 jun. 2007.