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

Graduaçã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ós-

Graduaçã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, opta-

se 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.