Monografia MDA e SOA
-
Upload
flaviogranero -
Category
Documents
-
view
6.312 -
download
1
description
Transcript of Monografia MDA e SOA
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
•
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 é
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
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.