Embed Size (px)
Citation preview
UNIVERSIDADE DO VALE DO ITAJAÍ
André Luiz Fernandes dos Santos
ANÁLISE E APLICAÇÃO DO MDA PARA CONSTRUÇÃO DE SISTEMAS DE SOFTWARE
Paulo Roberto Riccioni Gonçalves Professor orientador
São José
2006
2
UNIVERSIDADE DO VALE DO ITAJAÍ
ANÁLISE E APLICAÇÃO DO MDA PARA CONSTRUÇÃO DE SISTEMAS DE SOFTWARE
Área de Desenvolvimento de Software
André Luiz Fernandes dos Santos Acadêmico
Trabalho de Conclusão de Curso apresentado como requisito parcial para obtenção do título de bacharel em ciências da computação na Universidade do Vale do Itajaí, Centro de Educação São José.
Prof. Paulo Roberto Riccioni Gonçalves
São José
2006
3
DEDICATÓRIA
Aos meus amigos e familiares, que de alguma forma me deram força e apoio para a
concretização deste trabalho.
4
AGRADECIMENTO
À minha esposa Fernanda, pela compreensão e carinho.
Aos meus pais Roberto e Marli, por todo o apoio dado durante o curso.
Aos professores e colegas do curso, pela troca de experiências;
Em especial aos professores Alecir, Paulo Bermejo e Paulo Riccioni, pelo apoio prestando no
desenvolvimento deste trabalho.
5
RESUMO As empresas de desenvolvimento de software, em sua maioria, têm dificuldades em manter
uma documentação atualizada e precisa de seus projetos, devido a crescente demanda por
novos sistemas computacionais. Com o uso do MDA (Arquitetura Orientada a Modelo), esses
problemas tendem a ser minimizados devido à tecnologia oferecer geração do código-fonte da
aplicação a partir de modelos UML. Assim, obtém-se ganho na produtividade e na
manutenção da documentação do sistema.
O AndroMDA é um gerador de framework que utiliza o paradigma orientado a modelo,
possibilitando a geração de código-fonte a partir de modelos UML. Por meio de diagramas,
como de classes e atividades são geradas as implementações das classes e da interface gráfica
do sistema.
Em sistemas web a confecção da interface gráfica costuma ser complexa e o resultado final
insatisfatório. Para minimizar esse problema a Sun Microsystems criou o JSF (JavaServer
Faces), que é uma tecnologia que possui diversos componentes de interface gráfica, como
botões, caixas de texto, listas de seleção, entre outros. Com o auxílio de ferramentas de
desenvolvimento, como o Studio Creator, o uso dessa tecnologia possibilita a criação
simplificada e mais produtiva da interface gráfica e vínculo da aplicação com o banco de
dados.
Para demonstrar o uso prático do MDA e JSF, será desenvolvido ao longo deste trabalho um
sistema de manutenção de cadastro de doadores de sangue. O sistema vai oferecer
funcionalidades como inserção de novos doadores no sistema, alteração dos dados de
doadores já cadastrados e busca de doadores. Uma abordagem mais detalhada sobre a
aplicação será feita na sessão 3.4.
Primeiramente será desenvolvido o modelo UML da aplicação; esse modelo servirá para gerar
o código-fonte do sistema, além de manter uma documentação atualizada da aplicação. Para a
transformação do modelo em código-fonte será utilizado o AndroMDA, um gerador de
framework que utiliza os conceitos do MDA para fazer a conversão do modelo. Após o
código da aplicação ter sido gerado, será implementada a camada de apresentação (interface
gráfica) do sistema, utilizando JSF e uma ferramenta IDE para auxiliar a criação da interface.
6
ABSTRACT Most of the software companies have problems to maintain the documentation of their
projects updated and concise, because of the crescent demand of new computer systems. By
using MDA (Model Driven Architecture), these problems can be minimized due to this
technology offers generation of source code of the application based on UML models. By
this, there is more productivity in the process of code development and in the management of
the documentation.
AndroMDA is a tool that generates a framework that uses the concept of model driven
architecture, that can generate the source code based on the UML models. By class diagrams
and activity diagrams, the implementation of the application classes and the user interface are
generated.
In web applications, the implementation of the graphical use interface in general may be
complex and the final result unsatisfactory. To minimize this problem Sun Microsystem
created JSF (JavaServer Faces), a technology that has many user interface components like
buttons, input texts, dropdown lists, and more. By the help of some development tool, like
Studio Creator, the use of this technology simplifies and turns more productive the
development of graphical user interfaces and the link between application and database.
To demonstrate the practical use of MDA and JSF, a blood giver management application will
be developed during this project. This application will offer function like insertion of new
blood givers, data update of blood givers and blood giver search. More details about this
application will be presented in Chapter 3.4.
First an UML modeling of the application will be created; this model will be used to generate
the source code of the application and to maintain an updated documentation about the
application. To generate the source code will be used AndroMDA, a framework generator
based on the concepts of MDA. Afterwards the presentation layer (graphical interface) will be
developed using JSF and an IDE tool to help the creation of this graphical interface.
7
ÍNDICE DE FIGURAS Figura 1 - Ilustração do MDA. 20
Figura 2 - Interoperabilidade entre modelos PSM. 22
Figura 3 - Modelo PIM da classe “Doador” 24
Figura 4 - Modelo PSM das classes “Doador” e “DoadoresService” 25
Figura 5 - Descrição do núcleo da UML 2.0 27
Figura 6 - Camadas da arquitetura MOF 28
Figura 7 - Exemplo de modelagem OCL 29
Figura 8 - Exemplo de uma classe em UML especificada em XMI 30
Figura 9 - Janela de propriedades avançadas do sistema 35
Figura 10 - Janela de variáveis de ambiente 35
Figura 11 - Janela de nova variável de ambiente 36
Figura 12 - Tela de opções do MagicDraw. 38
Figura 13 - Tela de variáveis do MagicDraw. 39
Figura 14 - Tela para adicionar uma nova variável 39
Figura 15 - Script para a criação da tabela "doador" 42
Figura 16 - Script de criação da tabela "estados" 43
Figura 17 - Código de criação da tabela "tipo_sanguineo" 43
Figura 18 - Tela principal da aplicação 44
Figura 19 - Tela de cadastro de novos doadores 44
Figura 20 - Tela de busca de doadores 45
Figura 21 - Sessão Containment do Magic Draw 46
Figura 22 - Sessão Containment do Magic Draw depois da criação do modelo “doador” 46
8
Figura 23 - Sessão Containment do Magic Draw após criação do pacote
“org.andromda.doador” 47
Figura 24 - Elementos da barra de ferramentas 48
Figura 25 - Diagrama de classe do pacote "vo" 49
Figura 26 - Tela de edição de métodos 50
Figura 27 - Classe "DoadoresService" 51
Figura 28 – Tela de alteração de “Tags” 52
Figura 29 - Entidade "doador" no pacote "service". 52
Figura 30 - Diagrama "Value Objects" após a criação da dependência. 53
Figura 31 - Diagrama "DoadorService" após a criação da dependência. 54
Figura 32 – Processo de transformação do modelo PIM em código de programação. 54
Figura 33 – Janela de relatório do Magic Draw, após a geração do arquivo XMI. 55
Figura 34 – Definição do tipo de projeto. 56
Figura 35 – Local do novo projeto. 56
Figura 36 – Lista de componentes JSF 57
Figura 37 – Aba “Properties” 58
Figura 38 – Tela de adição de “Data Source” 60
Figura 39 – Lista de tabelas trazidas pelo “Data Source” 60
Figura 40 – Lista de “Data Providers” disponíveis. 61
Figura 41 – Vinculação de um “Data Provider” com um “Drop Down List” 62
Figura 42 – Navigation Case 63
9
ÍNDICE DE QUADROS Quadro 1 – Perguntas e respostas para a configuraçã do ambiente de desenvolvimento 41
Quadro 2 – Descrição dos diretórios do ambiente de desenvolvimento 41
Quadro 3 - Campos da tabela "doador" 42
Quadro 4 – Descrição da tabela “estados” 43
Quadro 5 – Lista de estados brasileiros contidos na tabela “estados” Erro!
Indicador não definido.
Quadro 6 - Atributos da Classe DoadorVO 48
10
SUMÁRIO DEDICATÓRIA 3
AGRADECIMENTO 4
RESUMO 5
ABSTRACT 6
1 INTRODUÇÃO 13
1.1 CONTEXTUALIZAÇÃO 14
1.2 PROBLEMA 15
1.3 OBJETIVOS 15
1.3.1 Objetivo geral 15
1.3.2 Objetivos específicos 16
1.3.3 Escopo e delimitação do trabalho 16
1.3.4 Resultados esperados 16
1.4 JUSTIFICATIVA 16
1.5 ASPECTOS METODOLÓGICOS 17
1.5.1 Metodologia 17
1.5.2 Plano de trabalho 18
2 MODEL DRIVEN ARCHITECTURE (MDA) 19
2.1 HISTÓRIA DO MDA 19
2.2 MDA HOJE 20
2.3 BENEFÍCIOS DO MDA 21
2.3.1 Produtividade 21
2.3.2 Portabilidade 21
11
2.3.3 Interoperabilidade 22
2.3.4 Manutenção e Documentação 23
2.4 PIM 23
2.5 PSM 24
2.6 UML 25
2.7 MOF 27
2.8 OCL 28
2.9 XMI 29
3 APLICAÇÃO DO MDA E JSF PARA CONSTRUÇÃO DE SISTEMAS DE
SOFTWARE 32
3.1 JAVASERVER FACES (JSF) 32
3.2 FERRAMENTAS UTILIZADAS 33
3.2.1 Maven 34
3.2.2 AndroMDA 36
3.2.3 MagicDraw 37
3.2.4 MySQL 40
3.3 CRIAÇÃO DO AMBIENTE DA APLICAÇÃO 40
3.4 DEFINIÇÃO DA APLICAÇÃO 42
3.4.1 Criação do banco de dados 42
3.4.2 Descrição da aplicação 43
3.4.3 Implementação do modelo PIM 45
3.5 GERAÇÃO DE CÓDIGO 54
3.5.1 Construção da Interface Gráfica 55
12
4 CONCLUSÃO 64
5 REFERÊNCIAS BIBLIOGRÁFICAS 66
6 ASSINATURAS 68
13
1 INTRODUÇÃO
O Model Driven Architecture (MDA), ou Arquitetura Orientada por Modelos, é uma infra-
estrutura para desenvolvimento de software proposta pela Object Management Group (OMG)
e foi desenvolvida para possibilitar a codificação de sistemas computacionais, utilizando
linguagens de modelagem como se fosse uma linguagem de programação. Ferramentas que
implementam MDA permitem gerar código em linguagem HTML, XML, WSDL, IDL, entre
outras. O MDA também pode fazer uso de máquinas virtuais para executar o modelo do
sistema computacional diretamente (FRANKEL, 2003, p32).
A OMG, além de criar o MDA, também foi responsável pela criação da UML, Corba, OMA,
XML, XMI, OCL, CWM e MOF. Sua principal motivação para a criação do MDA foi a de
proporcionar uma maior importância da modelagem no desenvolvimento de sistemas
(ANNEKE; WARMER; BAST, 2003, p26).
Linguagens de modelagem, como a UML, são informais, o que significa dizer que não podem
ser processadas. Desenvolvedores utilizam essas linguagens como um guia para auxiliar no
processo de codificação, e não como algo que vai contribuir na produção do sistema
(FRANKEL, 2003, p32).
O MDA possui três modelos principais: PIM (Plataform Independent Model ou Modelo
Independente de Plataforma), que é uma linguagem de modelo de sistemas que não leva em
conta em qual linguagem de programação ou plataforma o aplicativo será desenvolvido, PSM
(Plataform Specific Model ou Modelo Específico de Plataforma), que é criado a partir do PIM
e gera um modelo do aplicativo a ser desenvolvido, mas levando em conta as características
da linguagem de programação e plataforma destino, e por fim, code, que é o código-fonte do
aplicativo propriamente dito, gerado a partir do PSM. Um benefício oferecido pelo MDA é a
produtividade, que se justifica pelo fato de desenvolvedores PIM terem menos trabalho
porque detalhes específicos de plataforma não precisam ser levados em conta. Já em nível
14
PSM e de codificação, há pouco trabalho a se fazer, pois há menos código a ser feito, porque
a maior parte do sistema foi gerada pelo PIM (ANNEKE; WARMER; BAST, 2003, p29).
Assim, os desenvolvedores podem focar mais em modelar o sistema do que resolver os
problemas na mão, alterando diversas vezes o código-fonte. O resultado é um sistema que se
encaixa melhor nas necessidades do usuário final. O usuário ganha mais funcionalidade em
menos tempo (ANNEKE; WARMER; BAST, 2003, p29).
Outro benefício do MDA é a portabilidade, pois o PIM é independente de plataforma, sendo
assim o PIM pode ser transformado num PSM de qualquer plataforma. É possível fazer a
comunicação entre sistemas de diferentes plataformas, gerados a partir de um PIM. Essa
comunicação, no MDA, é chamada de ponte. Essa ponte é necessária porque quando os PMS
são gerados para diferentes plataformas, eles não podem se comunicar diretamente, sendo
assim é necessário transformar conceitos de uma plataforma em conceitos de outra
plataforma. (ANNEKE; WARMER; BAST, 2003, p30)
1.1 CONTEXTUALIZAÇÃO
Segundo a OMG (2005), o MDA surgiu para separar as regras de negócio da lógica de
programação. Com o MDA é possível utilizar uma linguagem de modelagem (como a UML)
para gerar código de aplicações, independente de linguagem de programação e de plataforma.
Sistemas criados usando MDA podem manter interoperabilidade entre si, mesmo que sejam
concebidos em linguagens e plataformas diferentes.
O MDA conseguiu adeptos no mercado, empresas de grande porte como a Borland, EDS,
Ericsson e IBM já o utilizam no seu dia-a-dia. Mais detalhes sobre algumas empresas que
utilizam o MDA podem ser encontrados em
http://www.omg.org/mda/mda_files/Member_and_Analyst_Quotes.pdf.
É possível encontrar no mercado hoje em dia ferramentas que utilizam o MDA para a geração
de códigos. Uma das mais conhecidas hoje é o AndroMDA. O AndroMDA é um framework
que aceita vários modelos (em geral modelos em UML, transformados em XMI por alguma
ferramenta case) e transforma esses modelos em componentes para várias linguagens, como
Java, .Net, HTML, PHP; para isso basta criar os plug-ins (ou configurar os já existentes) que
traduzam o modelo para a linguagem desejada. (ANDROMDA, 2005)
15
A partir do estudo do AndroMDA se espera obter um ponto de partida para a execução deste
trabalho. O AndroMDA será analisado em sua forma de utilização e resultados obtidos, e no
caso de a ferramenta se inserir no contexto deste trabalho, ela poderá ser utilizada no auxilio
do desenvolvimento do trabalho ou então alguns dos seus conceitos poderão ser aproveitados
para a codificação de uma ferramenta própria.
1.2 PROBLEMA
Um dos principais problemas encontrados no desenvolvimento de aplicações nos dias de hoje
é tornar a implementação de sistemas de software produtivo, e ao mesmo tempo manter uma
documentação do sistema consistente com o que está codificado. Não é difícil encontrar
aplicações já desenvolvidas que não possuem qualquer tipo de documentação. Isso torna
posteriores alterações na aplicação mais demoradas e complicadas, pois sem um documento
apropriado sobre como está estruturado o sistema, o programador tem que muitas vezes
“adivinhar” o que determinados trechos do código-fonte faz ou então perder tempo analisando
o código até que se possa entender o funcionamento do mesmo.
Outro fator que diminui a produtividade no desenvolvimento de aplicações, em especial
sistemas web, é a implementação da interface gráfica com o usuário. Diferentemente das
aplicações desktop, que contam com várias ferramentas e funcionalidades do sistema
operacional, o desenvolvimento de uma interface para aplicações web exige mais esforço do
programador, pois não existe ainda como implementar uma interface nos moldes de como e
feito em ferramentas, tal como o Borland Delphi, até mesmo porque há limitações da
linguagem HTML, que é utilizada para gerar os formulários e componentes do mesmo das
aplicações web.
1.3 OBJETIVOS
1.3.1 Objetivo geral
Desenvolver uma aplicação, que utilize os princípios do Model-Driven Architecture (MDA),
tendo o seu código-fonte gerado em J2EE a partir de um Plataform Independent Model
(PIM).
16
1.3.2 Objetivos específicos
Para a realização deste trabalho foram definidos os objetivos específicos:
• Analisar a viabilidade da integração entre MDA e JavaServer Faces;
• Averiguar casos de utilização de MDA no meio científico;
• Aplicar os conceitos de MDA no desenvolvimento de sistemas web;
• Investigar ferramentas existentes de geração de código via modelagem MDA;
• Aplicar os conceitos do JavaServer Faces (JSF) no código gerado;
• Desenvolver uma aplicação web a partir de um modelo PIM, onde esse modelo será
traduzido para a linguagem Java, e a interface gráfica será criada utilizando JSF.
1.3.3 Escopo e delimitação do trabalho
Este trabalho se limitará em gerar código Java (J2EE) para a implementação de uma aplicação
que utilizará o framework JSF. O modelo utilizado pela ferramenta para gerar código é o
MDA. Não faz parte do escopo deste trabalho detalhar características de plataforma, sistema
operacional, hardware, outros frameworks, containers ou qualquer outro conceito ou
tecnologia não relacionados ao JSF e MDA.
1.3.4 Resultados esperados
Os resultados esperados ao término deste trabalho são averiguar a viabilidade da aplicação da
arquitetura MDA para construção de sistemas para a web com base no framework JSF a partir
dos resultados do estudo e aplicação destas tecnologias. Ainda, construir uma aplicação web,
que será o resultado prático do estudo feito sobre MDA e JSF.
1.4 JUSTIFICATIVA
A importância deste trabalho é a pesquisa de uma maneira que permita tornar mais rápida o
desenvolvimento de uma aplicação web, que pode ser muito complexa, como descrito no
capítulo 1.2 deste trabalho. Espera-se que a aplicação do MDA e JSF apresente ao
desenvolvedor um ganho significativo em termos de velocidade de desenvolvimento.
17
A espera de ganho é baseada na escolha de novos conceitos que prometem agilizar o
desenvolvimento de sistemas. Esses conceitos são o MDA, uma metodologia de
transformação de modelos UML em código-fonte, e JSF, um framework para linguagem Java.
A ferramenta a ser desenvolvida durante o trabalho vai integrar esses dois conceitos (gerar
código JSF, baseado na modelagem MDA), esperando assim que com essa integração se
agilize ainda mais o desenvolvimento de sistemas online.
O JavaServer Faces (JSF, ou simplesmente Faces) torna fácil desenvolver aplicações web,
oferecendo suporte a componentes de interface gráfica (como caixas de texto, listas, painéis e
tabela de dados). (MANN, 2005, p4).
O MDA nada mais é do que usar linguagens de modelagem como linguagem de programação,
ao invés de apenas uma ferramenta de design. Programar em linguagem de modelagem pode
aumentar a produtividade, qualidade e longevidade de um sistema (FRANKEL, 2003, pXV).
O Model Driven Architecture (MDA) é uma nova metodologia no campo da ciência da
computação. O conceito da transformação de modelos é importante para a percepção dos
benefícios do MDA (ANNEKE; WARMER; BAST, 2003).
1.5 ASPECTOS METODOLÓGICOS
1.5.1 Metodologia
No princípio do desenvolvimento deste trabalho será usada a pesquisa exploratória, que
segundo Andrade (1999, p106):
[...] é o primeiro passo de todo o trabalho científico. São finalidades de uma pesquisa exploratória, sobretudo quando bibliográfica, proporcionar maiores informações sobre determinado assunto; facilitar a delimitação de um tema de trabalho; definir os objetivos ou formular as hipóteses de uma pesquisa ou descobrir novo tipo de enfoque para o trabalho que se tem em mente. Através das pesquisas exploratórias avalia-se a possibilidade de desenvolver uma boa pesquisa sobre determinado assunto. Portanto, a pesquisa exploratória, na maioria dos casos, constitui um trabalho preliminar ou preparatório para outro tipo de pesquisa.
Os dados referentes a este trabalho serão levantados por pesquisa bibliográfica, que segundo
Marconi e Lacatos (1999, p27):
[...] é um apanhado geral sobre os principais trabalhos já realizados, revestidos de importância por serem capazes de fornecer dados atuais e
18
relevantes relacionados com o tema. O estudo da literatura pertinente pode ajudar a planificação do trabalho, evitar duplicações e certos erros, e representa uma fonte indispensável de informações podendo até orientar indagações.
A pesquisa bibliográfica deve começar pelas obras de caráter geral: enciclopédias, anuários,
catálogos, resenhas, abstracts, que indicarão fontes de consultas mais específicas.
(ANDRADE, 1999)
Será feita também uma pesquisa documental, que segundo Pádua (2002, p65):
[...] é aquela realizada a partir de documentos contemporâneos ou retrospectivos, considerados cientificamente autênticos (não-fraudados); tem sido largamente utilizada nas ciências sociais, na investigação histórica, a fim de descrever/comparar fatos sociais, estabelecendo suas características ou tendências; além das fontes primárias, os documentos propriamente ditos, utilizam-se as fontes chamadas secundárias, como dados estatísticos, elaborados por institutos especializados e considerados confiáveis para a realização da pesquisa.
1.5.2 Plano de trabalho
Primeiramente será levantada a bibliografia necessária para a execução do trabalho. A
bibliografia deve atingir os assuntos abordados neste trabalho, como o MDA e o JSF. Depois
será feito um estudo do MDA, visando entender seus conceitos e técnicas para a modelagem
de sistemas. Em paralelo será estudado o framework JSF, buscando a compreensão de seus
conceitos e de como utiliza-lo em aplicações web. Após ter se apropriado desses conceitos,
será descrito como serão integrados o MDA e o JSF, para a geração de aplicações web.
19
2 MODEL DRIVEN ARCHITECTURE (MDA)
Neste capítulo é apresentado o histórico do Model Driven Architecture, ou Arquitetura
Orientada a Modelo (doravante referenciado por MDA), os benefícios propiciados por essa
arquitetura e como utilizá-la para o desenvolvimento de softwares.
A OMG garante que ao fazer uso do MDA, o desenvolvimento de aplicações feitas para
serem executadas em diversas plataformas de hardware e software se torna eficiente, pois
uma das vantagens dessa arquitetura é a interoperabilidade. A produtividade também
aumenta, pois colocando o foco no modelo da aplicação, não é necessário se preocupar com
detalhes sobre onde a aplicação será instalada e executada. Na conversão do modelo para
código-fonte é que existirá essa preocupação, porém o modo como é feita essa conversão
provavelmente já estará implementado e poderá ser utilizado para converter qualquer outro
modelo de aplicação.
2.1 HISTÓRIA DO MDA
O MDA iniciou o uso de modelos para ajudar no desenvolvimento de aplicações, e
então no ano de 1997 foram lançados a UML e o Meta-Object Facility (MOF). (OMG, 1996).
Embora os modelos UML possam ser desenvolvidos em qualquer plataforma, a contínua
proliferação de middlewares (módulos dotados com APIs de alto nível, que proporcionam a
sua integração com aplicações desenvolvidas em diversas linguagens de programação) sugere
que um MOF independente de plataforma seja o segredo para desenvolver sistemas mais
estáveis. O MDA une padrões de modelagem definidos pela OMG com qualquer tecnologia
de middleware, transformando o modelo numa implementação da aplicação modelada. O
MDA garante interoperabilidade e portabilidade para a aplicação em nível de modelo.
Com base nos problemas ocorridos com o ciclo de vida de desenvolvimento de
software tradicional, a OMG, criou o Model Driven Architecture (MDA). Este modelo
apresenta uma forma de desenvolver softwares capazes de serem independentes de
20
plataforma, que possam se comunicar com outros softwares de forma rápida e simples,
utilizando tecnologias cada vez mais modernas com a função de acompanhar a evolução do
mercado (COSTA, 2004). A Figura 1 ilustra o MDA.
Figura 1 - Ilustração do MDA. Fonte: OMG, 2001, Modificado
2.2 MDA HOJE
O MDA suporta diversas linguagens de modelagem, como a UML e o MOF. Há também
diversas ferramentas disponíveis no mercado que oferecem suporte ao MDA. Dependendo da
ferramenta, ela pode oferecer suporte parcial ou total às funcionalidades do MDA, inclusive
meios para se comunicar com outras ferramentas (ANNEKE; WARMER; BAST, 2003, p62).
Anneke, Warmer e Bast (2003, p62) também lembram que o MDA é uma arquitetura nova, ou
seja, nenhuma linguagem de programação ou ferramenta estão totalmente desenvolvidas para
gerar todo o código de uma aplicação modelada pelos princípios do MDA. Ainda há
necessidade da intervenção do programador, embora a maioria das ferramentas consiga
codificar boa parte do código da aplicação.
21
2.3 BENEFÍCIOS DO MDA
Nesta sessão são enumerados os principais benefícios do uso do MDA no desenvolvimento de
sistemas.
2.3.1 Produtividade
No MDA o foco do processo de desenvolvimento é a definição do modelo PIM do sistema. O
modelo PSM é gerado depois, a partir do modelo PIM. Os desenvolvedores responsáveis pelo
modelo PIM não se preocupam com detalhes específicos da plataforma onde será implantado
o sistema, pois durante a conversão do modelo PIM para o modelo PSM os detalhes da
plataforma destino são automaticamente adicionados. (ANNEKE; WARMER; BAST, 2003,
p.29)
Um dos principais ganhos, em termos de produtividade, está no fato de que os
desenvolvedores do modelo PIM têm menos trabalho, pois não precisam considerar em que
plataforma o sistema será executado. Quando o código da aplicação for gerado, haverá pouco
código a ser implementado manualmente, pois grande parte do código foi gerado a partir do
PIM. (ANNEKE; WARMER; BAST, 2003, p29).
Outro fator que contribui para o ganho de produtividade é que os desenvolvedores devem
prestar mais atenção ao modelo PIM, ao invés de resolver as regras de negócio manualmente.
Isto resulta num sistema que se encaixa bem com as expectativas do usuário final. (ANNEKE;
WARMER; BAST, 2003, p29)
É importante ressaltar que para obter ganho de produtividade é necessário utilizar ferramentas
que automatizem a geração do modelo PSM por meio do modelo PIM. Isso implica que é
necessário que todos os dados possíveis sobre a aplicação a ser desenvolvida devem ser
informados no modelo PIM e/ou na ferramenta de geração do modelo PSM. (ANNEKE;
WARMER; BAST, 2003, p29)
2.3.2 Portabilidade
Como o modelo PIM é, por definição, independente de plataforma, a partir de um modelo
PIM é possível gerar modelos PSM para diversas plataformas. Tudo o que for especificado no
modelo PIM é totalmente portável. (ANNEKE; WARMER; BAST, 2003, p29)
22
Para as plataformas mais populares (Microsoft Windows, Linux, Solaris, UNIX, por exemplo)
há diversas ferramentas disponíveis para a transformação do PIM num PSM da plataforma
desejada. Algumas dessas ferramentas sertão discutidas no capítulo 4 deste trabalho.
2.3.3 Interoperabilidade
Um modelo PIM pode gerar modelos PSM para diversas plataformas, e ainda permite que a
mesma aplicação seja executada em plataformas diferentes. Na Figura 2 há um exemplo de
modelos PSM gerados a partir de um modelo PIM, ligados por meio de relacionamentos
chamados de “ponte”.
Figura 2 - Interoperabilidade entre modelos PSM. Fonte: ANNEKE; WARMER; BAST, 2003, p30, modificado
Figura 1:
Conforme a figura acima, é possível transformar um modelo PIM em diversos modelos PSM,
e por serem de plataformas diferentes, os PSMs não podem comunicar-se entre si diretamente.
Para permitir a comunicação entre PSMs de diferentes plataformas, é necessário o uso de
pontes, que são geradas por ferramentas que a partir do PIM geram o PSM e a implementação
da ponte, que permite que haja comunicação entre sistemas sendo executados em plataformas
diferentes, o que é chamado de “interoperabilidade”. (ANNEKE; WARMER; BAST, 2003,
p30)
23
2.3.4 Manutenção e Documentação
Trabalhando com o ciclo de vida do MDA, os desenvolvedores podem se dedicar mais em
definir o modelo PIM da aplicação do que se preocupar em escrever todo o código. O PIM,
então, gera o PSM, que é utilizado para gerar o código do sistema. Esse modelo PIM é uma
representação exata do código-fonte da aplicação; sendo assim, o PIM pode ser considerado
como uma documentação de alto nível do sistema. (ANNEKE; WARMER; BAST, 2003, p31)
A diferença do PIM para a documentação convencional é que o PIM não é abandonado depois
de elaborado. Alterações na aplicação serão feitas no PIM, para então gerar novamente o
PSM e posteriormente o código. Algumas ferramentas permitem que alterações feitas
diretamente no PSM sejam integradas automaticamente no PIM, fazendo com que a
documentação do sistema continue consistente com o código-fonte atual. (ANNEKE;
WARMER; BAST, 2003, p31)
2.4 PIM
De acordo com a OMGb (2003, p20), o PIM (Modelo Independente de Plataforma) é um
modelo que descreve o sistema a ser implementado, porém não especifica detalhes de como
usá-lo ou em que plataforma a aplicação será implantada.
Para Siegel (2001, p4-5), todo o desenvolvimento de uma aplicação, utilizando MDA, se
inicia com a definição do PIM, em geral utilizando a UML. O PIM expressa apenas as regras
de negócio e comportamentos da aplicação. A clareza de uma modelagem PIM permite que a
definição das regras de negócio no modelo sejam fiéis ao que se espera no final do
desenvolvimento.
Uma vantagem do PIM é o fato dele ser independente de plataforma, fazendo com que o
modelo possa ser aproveitado integralmente sem um prazo determinado, sendo alterado
apenas quando houver alteração das regras de negócio Siegel (2001, p5). Outra vantagem é
poder usar o mesmo modelo PIM para desenvolver a aplicação para outras plataformas de
hardware e/ou software. A Figura 3 mostra um exemplo de modelagem, utilizando o PIM.
24
Figura 3 - Modelo PIM da classe “Doador”
2.5 PSM
O PSM (Modelo Específico de Plataforma) é produzido pela transformação do modelo PIM
da mesma aplicação a ser desenvolvida. O modelo PSM também indica como a aplicação
utiliza as funcionalidades da plataforma na qual ela será implantada OMGb (2003, p26).
O PSM pode provê mais ou menos detalhes, dependendo de seu propósito. O PSM pode ser
uma implementação do sistema, se nele conter toda a informação necessária para se codificar
um sistema e como coloca-lo em operação na plataforma escolhida, ou pode ser usado como
se fosse um PIM, visando refinar mais o PSM que pode ser implementado diretamente OMGb
(2003, p26).
O PSM que é uma implementação do sistema vai prover diversas informações, na qual podem
incluir código-fonte, especificações de como executar a aplicação e outras configurações
OMGb (2003, p26). A Figura 4 apresenta a classe PSM com os atributos privados, pois todo
acesso a eles será feito por meio de métodos definidos no código-fonte.
25
Figura 4 - Modelo PSM das classes “Doador” e “DoadoresService”
2.6 UML
A UML é uma linguagem padrão para a elaboração da estrutura de projetos de software. A
UML poderá ser empregada para a visualização, especificação, construção e documentação de
artefatos que façam uso de sistemas complexo de software (BOOCH; RUMBAUGH;
JACOBSON; 2000, p13).
A UML é apenas uma linguagem e, portanto, é somente uma parte de um método para
desenvolvimento de software. A UML é independente do processo, apesar de ser
perfeitamente utilizada em processo orientado a casos de usos, centrado na arquitetura,
iterativo e incremental (BOOCH; RUMBAUGH; JACOBSON; 2000, p13).
Ainda segundo Booch, Rumbaugh e Jacobson (2000, p15), a UML é uma linguagem de
especificação, que constrói modelos precisos, sem ambigüidades e completos. Por isso ela é
geralmente a linguagem escolhida para se especificar o PIM da aplicação. Segundo a OMG, a
UML não é obrigatória para a geração de sistemas pela arquitetura MDA, mas é utilizada em
99% dos projetos que utilizam o MDA.
Atualmente a OMG está trabalhando na versão 2.0, com a finalidade de fazer a UML fornecer
melhor suporte ao MDA. O padrão UML 2.0 trás melhorias na definição dos diagramas,
assim como a incorporação de novos diagramas que ajudarão a especificar modelos de uma
26
forma mais efetiva. Outro ponto forte da UML 2.0 é a compatibilidade com as linguagens
MOF, CWM, entre outros metamodelos reconhecidos pela OMG (OMGa, 2004).
Segundo a OMGa (2004), a UML possui diferentes tipos de diagramas, onde quatro desses
são diagramas que representam as estruturas de aplicação, seis representam características
diferentes de aspectos de comportamento dinâmico e três ilustram como os módulos da
aplicação são organizados e gerenciados.
Segundo Berkenkötter (2003) apud Costa (2004), “a UML 2.0 possui algumas características
que a valorizam como linguagem para a modelagem de sistemas em tempo real. Em nível
estrutural, a UML 2.0 possibilita a construção de modelos por hierarquia, permitindo
implementar vários níveis de abstração sobre um modelo e suportando de forma eficaz a
modelagem de sistemas complexos em tempo real”.
Costa Berkenkötter (2003) apud Costa (2004) também cita que “em nível comportamental, a
UML 2.0 foi enriquecida com um novo modelo de ação e um modelo de tempo. O novo
modelo de ação especifica mais de vinte tipos diferentes de ações, permitindo assim uma
classificação mais detalhada das mesmas. O modelo do tempo define conceitos usados para
representar nos diagramas comportamentais as relações com o tempo, tais como: os instantes
dos eventos, a duração e a sua periodicidade”.
Costa Berkenkötter (2003) apud Costa (2004) diz que “em relação aos diagramas temporais é
possível visualizar o impacto do tempo num ou mais objetos. Assim, enquanto que um
diagrama de estado permite representar as alterações do estado de um objeto, um diagrama de
tempo permite visualizar qual o efeito do tempo no estado de um ou mais objetos
relacionando-os entre si”. A Figura 5 mostra o núcleo da UML 2.0.
27
Figura 5 - Descrição do núcleo da UML 2.0 Fonte: Costa apud Berkenkötter, 2004
2.7 MOF
O MOF (Meta Model Facility) define um conjunto de construção de metamodelos, onde um
projetista de software pode definir diversos metamodelos interoperáveis entre si. O MOF
captura a estrutura e a semântica de metamodelos arbitrários, em particular o metamodelo
MDA e vários tipos de metadados (MELLOR; SCOTT; UHL et al, 2004, p78).
Interoperabilidade de metamodelos é necessária para a integração de ferramentas e aplicações
por meio de um ciclo de vida, usando semânticas comuns. O MOF também provê padrões de
acesso a dados, definindo padrões para linguagens que utilizam MOF para acessar modelos
(MELLOR; SCOTT; UHL et al, 2004, p78).
Um dos padrões utilizados pelo MOF é o XMI, no qual define regras para derivar um
esquema XML de uma linguagem de modelagem que utiliza o MOF, assim como regras para
gerar um documento XML. A combinação do MOF e de padrões como o XMI serve como a
espinha dorsal de uma estrutura MDA básica que possibilita a elaboração de uma estrutura
mais complexa, apresentando os modelos de marcação e funções de mapeamento, e
eventualmente, uma superestrutura MDA que contém metamodelos e perfis customizados
(MELLOR; SCOTT; UHL et al, 2004, p78).
A UML é mais ampla do que o MOF, com o seu suporte a casos de usos e modelagem de
comportamento, notação gráfica e mecanismos extensíveis. A OMG tem procurado unificar o
MOF e a UML, fazendo com que a notação gráfica da UML seja utilizada em metamodelos
MOF (MELLOR; SCOTT; UHL et al, 2004, p78). A Figura 6 mostra as camadas da
arquitetura MOF:
28
Camada M3
Camada M2
Camada M0
Camada M1
Modelo MOF
Metamodelo CWM
Metamodelo Esquema XML
Esquema BD Relacional Modelo de CatML XML Schema ou DTD
Metamodelo UML
Objetos Dados Documento XML
Figura 6 - Camadas da arquitetura MOF Fonte: OMG, 2000, modificado
2.8 OCL
A OCL (Object Constraint Language) é uma linguagem de expressão que possibilita escrever
expressões sobre modelos, como regras de derivação de atributos, corpo de operações de
consulta, invariantes e pré e pós-condições. A OCL pode ser usada tanto com UML quanto
com MOF, aumentando as possibilidades dessas linguagens e permitindo ao projetista de
software definir modelos mais precisos (ANNEKE; WARMER; BAST, 2003, p163).
Uma expressão OCL sempre descreve o que é o valor, mas nunca diz como a expressão deve
ser calculada; porém uma expressão OCL pode ser traduzida para uma linguagem de
programação (por exemplo, Java) para especificar como a expressão é executada. Expressões
OCL são expressões que não causam efeitos colaterais (ANNEKE; WARMER; BAST, 2003,
p163).
Em geral a OCL é utilizada em conjunto com a UML para especificar constraints. O tipo mais
comum de constraints são as invariáveis, pré-condicionais e pós-condicionais. Hoje em dia o
uso da OCL para especificar outros propósitos se tornou popular. Dentre esses propósitos
pode-se citar especificações de:
• valor inicial de atributos;
29
• regras de derivação de atributos e associações;
• corpo de operações de consulta;
• alvos para mensagens que estão sendo enviadas;
• condições de um diagrama dinâmico;
• operações de usuário-final num modelo UML.
Um modelo UML de um sistema se torna mais preciso e mais completo com a aplicação da
OCL. No contexto do MDA, isso significa que o modelo de origem de uma transformação se
torna mais rico, sendo possível gerar um modelo alvo mais completo. A possibilidade de
especificar um modelo mais completo e preciso permite uma transformação MDA, gerando
um PSM ou código mais detalhado. O ganho com a utilização do MDA é considerável
(ANNEKE; WARMER; BAST, 2003, p163). A Figura 7 apresenta a definição de uma classe
e uma regra, utilizando OCL:
Pessoa
+ IdPessoa: Integer
+ NomePessoa: String
+ RgPessoa: String
-------- {IsUnique (idPessoa)}
Figura 7 - Exemplo de modelagem OCL Fonte: ANNEKE; WARMER; BAST, 2003, modificado
A OCL também pode ser usada como uma camada do modelo MOF, permitindo a escrita
sobre metamodelos. O primeiro uso da OCL com o MOF é feito na definição do metamodelo
UML. Diversas invariantes são definidas na OCL para completar o diagrama que mostra o
metamodelo graficamente. Assim os metamodelos se tornam mais precisos e constitui em
melhor especificação com menos ambigüidade (ANNEKE; WARMER; BAST, 2003, p163).
2.9 XMI
O XML Metadata Interchange (XMI) é um padrão que permite definir objetos usando a
Extensible Markup Language (XML). O XMI é mais do que um conjunto de regras, ele é
30
quase um padrão de modelagem que possibilita modelar aplicações, usando XML. A versão
2.0 do XMI especifica como criar esquemas XML a partir de modelos e versões anteriores do
XMI especificam como criar DTDs (Document Type Definition) XML a partir de modelos.
Tanto DTDs como esquemas definem o conteúdo de documentos XML. O XMI também
especifica como fazer engenharia reversa de modelos a partir de documentos XML, DTDs e
esquemas XML (GROSE; DONEY; BRODSKY, 2002, p3). A Figura 8 ilustra como é uma
classe, modelada em UML, especificada em XMI.
Figura 8 - Exemplo de uma classe em UML especificada em XMI Fonte: GROSE; DONEY; BRODSKY, 2002, p9
Grose, Doney e Brodsky (2002, p3) enumeram as seguintes vantagens do XMI:
• provê um padrão para a representação de objetos em XML, permitindo a troca de
informações entre os objetos usando o XML;
• especifica como criar esquemas XML a partir de modelos;
• permite criar documentos XML e evoluí-los de acordo com o crescimento da aplicação;
• permite que qualquer um trabalhe com XML, sem a necessidade se ser um expert em
XML.
31
Grose, Doney e Brodsky (2002, p4) afirmam que é necessário utilizar o XMI, porque o XML
não é orientado a objeto, assim faz-se necessário mapear objetos em XML. Há várias
maneiras de se fazer o mapeamento, devido à flexibilidade do XML. Entretanto, essa
flexibilidade oferecida pelo XML torna-se um inconveniente quando há a troca de
informações entre documentos XML. Se uma ferramenta utiliza um método para mapear
objetos e outra ferramenta utiliza um outro método, essas ferramentas serão incapazes de
interpretar uma o mapeamento da outra. O XMI utiliza modelos para garantir que os objetos
são compartilhados consistentemente. Uma ferramenta que usa XMI pode compartilhar
objetos com outra ferramenta que também usa XMI.
32
3 APLICAÇÃO DO MDA E JSF PARA CONSTRUÇÃO DE
SISTEMAS DE SOFTWARE
Este capítulo trata sobre a implementação de uma aplicação exemplo, que mostra como
utilizar MDA e JSF de forma prática. Para tal é necessário desenvolver o PIM dessa aplicação
e transformá-lo em código-fonte. Os procedimentos necessários para desenvolver o modelo
PIM até a tradução desse modelo em código-fonte são abordados neste capítulo.
No desenvolvimento de softwares, um framework é uma estrutura de suporte definida em que
um outro projeto de software pode ser organizado e desenvolvido. Tipicamente, um
framework pode incluir programas de apoio, bibliotecas de código, linguagens de script e
outros softwares para ajudar a desenvolver e juntar diferentes componentes do seu projeto
(WIKIPEDIA, 2005).
A vantagem trazida por um framework é a possibilidade de usar diversos componentes em
várias aplicações diferentes, aumentando a produtividade, pois não é necessário desenvolver
novamente o que é comum nas aplicações. Como exemplo, pode-se citar um sistema de
autenticação de usuários por meio de login e senha. Supondo que o método de autenticação
para todas as aplicações seja implementado da mesma forma é mais produtivo inserir essa
implementação de autenticação num framework do que para cada nova aplicação
reimplementar o mesmo método.
3.1 JAVASERVER FACES (JSF)
O JavaServer Faces é uma solução holística para vários problemas de desenvolvedores de
software e para os consumidores que o utilizam. Para o usuário final, o JSF oferece um uso
mais intuitivo para aplicações web. Para desenvolvedores, JavaServer Faces provê uma API
padrão, orientada a objeto e fácil de usar que facilita o desenvolvimento de aplicações web
(DUDNEY; LEHR; WILLIS et al, 2004, pXV).
33
O JSF é uma especificação com implementações de vários fornecedores. Essa especificação
define um conjunto de componentes de interface gráfica, sendo possível a implementação de
novos componentes. Esses componentes contam com estratégias de validação de dados de
entrada, na qual é propagado automaticamente para os objetos da aplicação. Os eventos são
disparados por ações do usuário, como clicar num botão ou link, e também é possível alterar o
estado de outros componentes (BERGSTEN, 2004, p18).
Para desenvolvedores Java habituados com desenvolvimento de aplicações desktop, pode-se
pensar no JSF como sendo o “Swing para aplicações server-side”. Desenvolvedores
acostumados com JavaServer Pages (JSP) perceberão que o JSF já traz pronto o que
desenvolvedores JSP precisariam fazer manualmente. Se o desenvolvedor estiver
familiarizado com outros frameworks, como o Struts, notará que o JSF usa uma arquitetura
similar (GEARY; HORSTMANN, 2004, p3).
Em linhas gerais, a grande vantagem do JSF é tornar mais rápida e produtiva o
desenvolvimento das interfaces gráficas de aplicações web. Mais rápida porque há diversos
componentes já desenvolvidos para o JSF, como caixas de texto, tabelas, botões, entre outros
controles comumente encontrados em aplicações desktop. Sem o auxílio de uma ferramenta,
toda a interface gráfica de aplicações web é codificada manualmente pelo desenvolvedor, e
em termos de interação com o usuário, o ponto fraco da interface gráfica web é que sempre
que um formulário é submetido para o servidor há um reload da página, fazendo com que a
aplicação seja lenta e exija mais recursos do servidor. Com o JSF, a interação dos
componentes visuais é como numa aplicação desktop, não sendo necessário esperar o refresh
do formulário quando submetê-lo, por exemplo. A informação é processada no servidor, sem
que haja o reload.
3.2 FERRAMENTAS UTILIZADAS
Para o desenvolvimento da aplicação proposta neste trabalho foram usadas o Maven, J2EE,
um kit de desenvolvimento de software desenvolvido pela Sun Microsystem, o AndroMDA,
que é a ferramenta responsável em gerar código da aplicação a partir do modelo PIM, o
Magic Draw para a construção do modelo PIM da aplicação e transformação desse modelo
em código-fonte e o MySQL, um sistema gerenciador de banco de dados, onde serão
34
armazenadas os dados informados por usuários da aplicação. Os procedimentos de instalação
e configuração dessas ferramentas são abordados na seqüência deste trabalho.
3.2.1 Maven
Maven é um gerenciador de projeto, desenvolvido pela Apache Software Foundation. O
Maven é baseado num Modelo de Objetos de Projeto (POM) e provê gerenciamento e
automação de projetos desenvolvidos em linguagem Java (Maven, 2006).
O modelo POM descreve todo o processo de construção de um projeto de software, suas
dependências em outros módulos e a sua seqüência de construção. O Maven executa funções
de compilação e de empacotamento do sistema. O Maven é capaz de baixar plug-ins
necessários para o desenvolvimento de uma aplicação, de acordo com as tecnologias usadas
em sua implementação (WIKIPÉDIA, 2006).
Para instalar o Maven, é necessário obtê-lo do seu site oficial, localizado em
http://maven.apache.org. A versão utilizada neste trabalho foi a 2.0.4, outras versões dessa
ferramenta podem não funcionar de acordo com os passos descritos adiante.
Após obtê-lo a partir do link informado acima, é necessário descompactar o arquivo em um
diretório. Neste trabalho o diretório a ser utilizado é “C:\Maven”. Ao descompactar o arquivo
será criada a estrutura de diretórios “C:\Maven\maven-2.0.4”.
Depois da instalação do Maven é preciso criar variáveis de ambiente, para que o sistema
operacional possa localizar a ferramenta a partir de qualquer outro diretório. Segue um
exemplo de como definir variáveis de ambiente no Microsoft Windows XP. Em outros
sistemas operacionais o processo pode ser diferente.
Primeiro é necessário acessar a janela “Propriedades do sistema”, aba “Avançado”, como
mostrado na Figura 9:
35
Figura 9 - Janela de propriedades avançadas do sistema
O botão “Variáveis de ambiente” dá acesso à janela ilustrada na Figura 10:
Figura 10 - Janela de variáveis de ambiente
36
Para criar a nova variável de sistema, na qual conterá o caminho onde está instalado o Maven,
é necessário acessar a janela “Nova variável de ambiente”. A nova variável terá como nome
“M2_HOME”, e seu valor “C:\Maven\maven-2.0.4”, de acordo com a Figura 11:
Figura 11 - Janela de nova variável de ambiente
Depois de definir a nova variável “M2_HOME” é preciso definir uma outra variável, que será
utilizada pelo Maven. Essa variável contém o diretório de onde serão armazenados plug-ins
necessários para desenvolver a aplicação. Para isto, deve-se criar uma nova variável chamada
“M2_REPO”, com o valor “C:\Documents and Settings\usuario\.m2\repository”, seguindo as
instruções descritas anteriormente. Deve-se trocar a palavra “usuario” pelo nome de usuário
utilizado para iniciar o Windows XP.
Para possibilitar a execução do Maven a partir de qualquer diretório no prompt de comando, a
variável de ambiente “PATH” deve ser alterada, adicionando o texto
“%JAVA_HOME%\bin;%M2_HOME%\bin” no seu conteúdo. Dessa forma o sistema
operacional consegue localizar os comandos necessários para acionar o Maven e o Java, sem
precisar informar o caminho completo dessas ferramentas sempre que forem executadas.
3.2.2 AndroMDA
O AndroMDA é um gerador de framework que utiliza o paradigma orientado a modelo
(MDA). Modelos desenvolvidos em ferramentas CASE, como o Magic Draw, são
transformados em código-fonte da linguagem de programação desejada (ANDROMDA,
2005).
O AndroMDA tem como característica uma arquitetura de plug-ins. Assim, o AndroMDA é
basicamente uma ferramenta de transformação (modelo para código-fonte). Os plug-ins
utilizados pelo AndroMDA são chamados de cartuchos. Caso seja necessário, o
37
desenvolvedor pode escrever cartuchos próprios, que a partir do modelo de entrada gera uma
saída, como um código-fonte ou um script de criação de tabelas para um banco de dados. Há
uma série de cartuchos já implementados, como os que suportam as tecnologias Spring, EJB,
Webservices, Hibernate, Struts, JSF, Java e XSD (ANDROMDA, 2005).
O uso do AndroMDA requer a instalação manual do plug-in andromdapp-maven-plugin-
install-3.2-SNAPSHOT.zip no repositório do Maven. Este plug-in é o único componente de
instalação manual, pois os outros são instalados e configurados pelo Maven. O plug-in deve
ser baixado do site do AndroMDA no link
http://team.andromda.org/maven2/org/andromda/maven/plugins/andromdapp-maven-
plugin/3.2-SNAPSHOT/andromdapp-maven-plugin-install-3.2-SNAPSHOT.zip, Este arquivo
deve ser copiado para o diretório definido na variável de ambiente M2_HOME, e
descompactado. A estrutura de diretórios da instalação do plug-in é parecida com
“C:\Documents and Settings\usuario\.m2\repository\org\andromda\maven\plugins\andromda-
maven-plugin”.
3.2.3 MagicDraw
O MagicDraw é uma ferramenta case que permite a modelagem visual de diagramas UML. O
MagicDraw é capaz de gerar código XMI a partir dos modelos UML, necessário para que o
AndroMDA faça a tradução do modelo para código-fonte.
A versão do MagicDraw utilizada neste trabalho é a 11.5 CE (Community Edition). Essa é
uma versão gratuita da ferramenta e com algumas limitações em relação à versão comercial;
porém essas limitações não afetam o desenvolvimento da aplicação proposta neste trabalho.
Para realizar a instalação do MagicDraw é necessário obtê-lo a partir da página do
desenvolvedor, localizada em http://www.magicdraw.com. Após o recebimento do arquivo
MD_UML_115_CE_win.exe basta executá-lo e aguardar o processo de instalação.
Depois de instalado o MagicDraw é necessário definir no programa o local onde está o
repositório do Maven. Para isso deve-se executar o MagicDraw e acessar o item Enviroment a
partir do menu Options, como demonstrado na Figura 12.
38
Figura 12 - Tela de opções do MagicDraw.
Na tela de opções há um item à esquerda chamado Path Variables. É a partir desse item onde
se define as variáveis que serão utilizadas pelo MagicDraw. Essa tela é mostrada na Figura
13.
39
Figura 13 - Tela de variáveis do MagicDraw.
Para adicionar uma nova variável é necessário ir ao botão Add, e então uma janela se abrirá,
onde se informará o nome da variável, seu conteúdo e uma descrição. Essa janela é mostrada
na Figura 14:
Figura 14 - Tela para adicionar uma nova variável
40
3.2.4 MySQL
O sistema gerenciador de banco de dados (SGBD) escolhido neste trabalho é o MySQL,
versão 5.1, distribuído sob a licença open source. Para a instalação do MySQL, primeiro é
preciso obter uma cópia da instalação do mesmo a partir da página
http://dev.mysql.com/downloads/mysql/5.1.html, e pode ser instalado em qualquer diretório.
Depois da instalação do MySQL é necessário instalar o driver JDBC, que vai permitir a
comunicação da aplicação com o banco de dados. O driver pode ser obtido a partir do
endereço http://dev.mysql.com/downloads/connector/j/3.1.html. A versão utilizada neste
projeto é a 3.1.13. Após o término da transferência do arquivo é preciso descompactá-lo no
diretório de instalação do MySQL.
3.3 CRIAÇÃO DO AMBIENTE DA APLICAÇÃO
Depois de instaladas as ferramentas para o desenvolvimento da aplicação é preciso utilizar o
Maven para fazer a configuração inicial da aplicação a ser desenvolvida. Essa configuração é
necessária para que o Maven transfira para o repositório local, definido na variável de
ambiente M2_REPO, todos os plug-ins das tecnologias necessárias para a criação da
aplicação. Para isso, é deve-se ir ao prompt de comando e, a partir de qualquer diretório,
digitar o comando “mvn org.andromda.maven.plugins:andromdapp-maven-plugin:generate”.
É importante observar que o diretório raiz não deverá ter espaços em seu nome ou o Maven
não conseguirá executar a configuração do ambiente.
Em seguida o Maven apresentará uma série de perguntas, das quais obterá respostas para
configurar o ambiente de acordo com as características da aplicação. As perguntas e
respectivas respostas para configurar a aplicação estão no Quadro 1.
Perguntas Respostas Please choose the type of application to generate [richclient, j2ee] j2ee Please enter the location in which your new application will be created C:/ Please enter your first and last name André Santos Which kind of modeling tool will you use? [uml1.4, uml2, emf-uml2] uml2 Please enter the name of your J2EE project TCC Please enter an id for your J2EE project doador Please enter a version for your project 1.0 Please enter the root package name for your J2EE project org.andromda.doador Would you like an EAR or standalone WAR? [ear, war] ear Please enter the type of transactional/persistence cartridge to use [hibernate, ejb, ejb3, spring, none]
spring
41
Please enter the database backend for the persistence layer [hypersonic, mysql, oracle, db2, informix, mssql, pointbase, postgres, sybase, sabdb, progress, derby]
mysql
Will your project need workflow engine capabilities? (it uses jBPM and Hibernate3)? [yes, no]
no
Please enter the hibernate version number (enter '2' for 2.1.x or '3' for 3.0.x) [2, 3] 3 Will your project have a web user interface? [yes, no] yes Would you like your web user interface to use JSF or Struts? [jsf, struts] jsf Would you like to be able to expose your services as web services? [yes, no] no
Quadro 1 – Perguntas e respostas para a configuraçã do ambiente de desenvolvimento
Ao final do processo deve aparecer a mensagem “BUILD SUCCESSFULL”, indicando que o
ambiente foi configurado corretamente. Debaixo do diretório C:\ foi criado outro diretório
chamado “doador”, que possui a estrutura descrita no quadro a seguir (cada diretório é um
sub-projeto criado pelo Maven).
Diretório Descrição doador Diretório raiz da aplicação, contém todos os sub-projetos da aplicação. app Contém recursos e classes que são necessários para criar o arquivo .ear. common Contém recursos e classes que são compartilhados com outros sub-projetos, como value
objects. core Contém classes de entidade, objetos de acesso ao banco de dados e no caso da aplicação deste
trabalho, o framework Spring. mda Diretório onde será desenvolvido o modelo UML da aplicação, e onde o AndroMDA cria os
arquivos necessários para gerar o código-fonte da aplicação. web Diretório onde ficam armazenados arquivos da camada de apresentação (interface gráfica).
Quadro 2 – Descrição dos diretórios do ambiente de desenvolvimento
Após a criação do ambiente da aplicação é preciso configurar o mesmo, para que fique
configurado de acordo com as características da aplicação. No arquivo
doador\mda\src\main\config\andromda.xml o valor da propriedade
“enableSpringTransactionsWhenEjbsEnabled” deve ser alterado para “falso”, já que a
aplicação não usará Spring para controlar transações com o banco de dados.
No arquivo “doador\pom.xml” os seguintes ajustes precisam ser feitos:
• A sessão “<jdbc.driver.jar>” deve ter o conteúdo alterado para
“${jboss.home}/server/default/lib/mysql-connector-java-3.1.13-bin.jar</jdbc.driver.jar>”,
para que a aplicação utilize o driver JDBC apropriado para a conexão com o MySQL;
• A sessão “<jdbc.username>” deve conter um nome de usuário do MySQL, com privilégio
de acesso e escrita no banco de dados da aplicação, e a sessão “<jdbc.password>” a senha
desse usuário.
42
3.4 DEFINIÇÃO DA APLICAÇÃO
Após a criação e configuração do ambiente da aplicação, descrita na sessão 4.2, é necessário a
criação do modelo UML (PIM) da aplicação e de um banco de dados, para armazenar as
informações sobre os doadores. A partir desse modelo, será gerado um arquivo XMI, que o
AndroMDA é capaz de ler e transformar em código-fonte.
3.4.1 Criação do banco de dados
Os dados referentes aos doadores serão gravados em um esquema criado no MySQL,
chamado de “TCC”. Esse esquema possui três tabelas, “doador”, “estados” e
“tipo_sanguineo”. A tabela “doador” é onde ficarão armazenadas as informações sobre os
doadores cadastrados. Os campos da tabela “doador” estão descritos no Quadro 3.
Campo Descrição cod_doador É um identificador único para cada doador, definido pelo próprio banco (auto increment). nome Armazena o nome do doador cadastrado. email Guarda o e-mail do doador. O preenchimento não é obrigatório. endereço Contém o endereço do doador. telefone Guarda o telefone do doador uf Armazena o código do estado referente ao estado onde reside o doador. sangue Contém o código referente ao tipo sangüíneo do doador.
Quadro 3 - Campos da tabela "doador"
O script de criação da tabela “doador” é exibido na Figura 15.
DROP TABLE IF EXISTS `tcc`.`doador`; CREATE TABLE `tcc`.`doador` ( `cod_doador` int(10) unsigned NOT NULL auto_increment, `nome` varchar(64) NOT NULL default '', `email` varchar(255) default NULL, `endereco` varchar(255) NOT NULL default '', `telefone` varchar(16) NOT NULL default '', `uf` char(2) NOT NULL default '', `sangue` varchar(3) NOT NULL default '', PRIMARY KEY (`cod_doador`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
Figura 15 - Script para a criação da tabela "doador"
A tabela “estados” contém todos os estados brasileiros cadastrados, e é composta pelos
campos “sigla” e “nome, descritos no Quadro 4:
43
Campo Descrição sigla Contém a sigla referente ao estado, por exemplo “AM” para “Amazonas” e “RS” para “Rio
Grande do Sul”. nome Armazena o nome do estado.
Quadro 4 – Descrição da tabela “estados”
Abaixo o script de criação da tabela de estados:
DROP TABLE IF EXISTS `tcc`.`estados`; CREATE TABLE `tcc`.`estados` ( `sigla` char(2) character set ucs2 NOT NULL default '', `nome` varchar(45) NOT NULL default '', PRIMARY KEY (`sigla`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
Figura 16 - Script de criação da tabela "estados"
A tabela de doadores contém os tipos sangüíneos que um doador de sangue pode possuir. Essa
tabela possui um campo chamado “tipo_sangue”, na qual armazena os tipos sangüíneos
possíveis, que são “A+”, “A-”, “AB+”, “AB-”, “B+”, “B-”, “O+” e “O-”. A Figura 17 mostra
o script para a criação da tabela “tipo_sangue”:
DROP TABLE IF EXISTS `tcc`.`tipo_sanguineo`; CREATE TABLE `tcc`.`tipo_sanguineo` ( `tipo_sangue` varchar(3) NOT NULL default '', PRIMARY KEY (`tipo_sangue`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
Figura 17 - Código de criação da tabela "tipo_sanguineo"
3.4.2 Descrição da aplicação
A aplicação proposta neste trabalho, a qual servirá para demonstrar de forma prática a
aplicação do MDA e JSF, é a manutenção de um cadastro de doadores de sangue. A
manutenção de cadastro engloba funções como adição de novos doadores, edição de doadores
já existentes, exclusão de doadores cadastrados e pesquisa de doadores.
A tela principal do sistema deve permitir acesso a tela de cadastro de novo doador e a de
pesquisa de doadores cadastrados no sistema, como mostrada na Figura 18:
44
Figura 18 - Tela principal da aplicação
A tela principal contém dois botões, “Cadastro de Novos Doadores” e “Busca de Doadores”
que possibilitam acesso as telas de cadastro de novos doadores e de pesquisa de doadores já
cadastrados, respectivamente. A Figura 19 ilustra a tela de cadastro de novos doadores.
Figura 19 - Tela de cadastro de novos doadores
A tela de cadastro de novos doadores é composta pelas caixas de texto “Nome”, “E-mail”,
“Endereço” e “Telefone”, onde serão digitadas essas informações, e todos devem ser
obrigatoriamente preenchidos, com exceção do campo “E-mail”. Na mesma tela há duas
caixas de seleção, “UF”, onde contém uma lista de estados brasileiros e “Sangue”, na qual é
possível escolher o tipo sangüíneo do doador que está sendo cadastrado. As opções da caixa
de seleção “UF” vêm da tabela “estados” e as opções da caixa “Sangue” são provenientes da
tabela “tipo_sangue”.
45
Ao acionar o botão “Salvar”, os dados preenchidos na tela serão inseridos na tabela
“doadores”, caso todos os campos estejam preenchidos; os campos serão limpos e é possível
então cadastrar um novo doador. O botão “Voltar” dá acesso à tela principal da aplicação.
A tela de busca de doadores contém três campos, “Nome”, “UF” e “Sangue”. A busca por
doadores é baseada nos campos preenchidos. Por exemplo, se nenhum campo for preenchido,
o resultado da busca será o retorno de todos os doadores cadastrados no banco de dados.
Assim, é possível pesquisar um doador por nome, por UF ou tipo de sangue ou ainda
combinar esses três campos para se obter uma busca mais refinada. A tela de busca de
doadores é ilustrada na Figura 20.
Figura 20 - Tela de busca de doadores
3.4.3 Implementação do modelo PIM
Nesta sessão será descrito os passos necessários para a criação do modelo PIM da aplicação.
A partir desse modelo, o código-fonte da aplicação é gerado, por meio de um arquivo XMI
referente ao modelo. O arquivo XMI é criado por meio de uma ferramenta capaz de processar
o modelo e converte-lo para XMI. No exemplo proposto neste trabalho foi utilizado o Magic
Draw, descrito na sessão 4.1.3.
Para iniciar a criação do modelo da aplicação é preciso iniciar o Magic Draw e abrir o arquivo
XMI criado durante a criação do ambiente da aplicação. O arquivo XMI está no diretório
“mda/src/main/uml/”, e se chama “doador.xmi”. Para abrir o arquivo a partir do Magic Draw
é preciso acessar o menu “File/Open Project” e navegar até o diretório onde se encontra o
arquivo “doador.xmi”.
Ao abrir o arquivo “doador.xmi” percebe-se à esquerda da janela uma sessão denominada
“Containment”, onde é exibida a estrutura de pacotes do modelo UML da aplicação, mostrada
46
na Figura 21. Os passos necessários para a construção do modelo da aplicação serão
detalhados a seguir.
Figura 21 - Sessão Containment do Magic Draw
Primeiro é preciso criar um novo elemento chamado “model” (modelo), clicando com o
mouse no elemento principal, chamado data. Surge então um menu, e para criar o modelo é
necessário acessar a opção “New Element/Model”. O nome do modelo criado é “doador”, e o
Magic Draw exibe a estrutura mostrada na Figura 22.
Figura 22 - Sessão Containment do Magic Draw depois da criação do modelo “doador”
A partir do modelo “doador” é feita a criação das classes e pacotes da aplicação. Pressionando
o botão direito do mouse sobre o modelo “doador” e acessando a opção
“NewElement/Package” é criado um pacote sob esse modelo. O pacote em questão é chamado
de “org.andromda.doador”. O Magic Draw apresenta a estrutura ilustrada na Figura 23 após a
criação desse pacote.
47
Figura 23 - Sessão Containment do Magic Draw após criação do pacote “org.andromda.doador”
Mais três pacotes precisam ser criados para a implementação da aplicação. Esses pacotes
devem ficar sob o pacote “org.andromda.doador”. Cada um desses pacotes vai conter
determinadas classes do sistema e são descritos a seguir:
• vo: esse pacote contém as classes “doadoresVO[]” e “doadorVO”. A classe “doadorVO”
contém apenas os atributos referentes a um doador e é um reflexo da tabela “doador”
criada no banco de dados. Já a classe “doadoresVO[]” é uma lista que pode conter várias
instâncias da classe “doadorVO”.
• service: contém a classe “DoadoresService”, a qual implementa métodos de acesso e
manipulação de dados, como inserção, exclusão, alteração e busca de doadores.
• domain: contém a classe “Doador”, que mantém a tabela “doador” do banco de dados
persistente enquanto a aplicação estiver ativa.
3.4.3.1 Pacote VO
O pacote “vo” (value objects ou objetos de valor) deve estar sob o pacote
“org.andromda.doador”. Para isso é preciso chamar o menu de opções, ativando-o com o
botão direito do mouse sobre o pacote “org.andromda.org”, e a seguir selecionar a opção
“New Element/Package”. O novo pacote deve se chamar “vo”.
Após a criação do pacote “vo” é necessário criar um novo modelo sob esse pacote. Para criar
o novo modelo é preciso acionar o botão direito do mouse sobre o pacote “vo” e acessar a
opção “New Diagram/Class Diagram”. O Magic Draw apresenta um novo espaço para a
criação de um diagrama de classes e deve se chamar “Value Objects”. Para adicionar
elementos no diagrama há uma barra de ferramentas, exibida na Figura 24. Para criar uma
48
nova classe no diagrama, deve-se selecionar o elemento Class e posicioná-lo dentro do
diagrama.
Figura 24 - Elementos da barra de ferramentas
Ao surgir a nova classe no diagrama, deve-se nomeá-la para “DoadorVO”. O estereótipo da
classe é “ValueObject”. Para definir um esterótipo a uma classe é preciso acionar o botão
direito do mouse sobre a classe e acessar a opção “Stereotype”. A seguir aparece uma lista
com os estereótipos possíveis, e então se deve selecionar a opção “ValueObject”.
Definido o estereótipo da classe, é preciso criar os atributos, detalhados no Quadro 5. Para
adicionar um novo atributo à classe é preciso acionar o botão direito do mouse sobre a classe
e escolher a opção “Insert New Attribute”. Um novo atributo chamado “-unnamed1” será
criado. É necessário alterar para o nome do novo atributo, e também trocar o sinal de “-“ para
o símbolo “+”. Para cada atributo mencionado no Quadro 5 é necessário realizar essa
operação. Todos os atributos são do tipo “String”, ao escolher o tipo de dados aparece duas
possibilidade para “String”, deve-se escolher a opção “String[datatype]”.
Atributo Descrição nome Armazena o nome do doador cadastrado. email Guarda o e-mail do doador. O preenchimento não é obrigatório. endereço Contém o endereço do doador. telefone Guarda o telefone do doador uf Armazena o código do estado referente ao estado onde reside o doador. sangue Contém o código referente ao tipo sangüíneo do doador.
Quadro 5 - Atributos da Classe DoadorVO
49
Após adicionar todos os atributos para a classe “DoadorVO” é preciso criar a classe
“DoadoresVO[]”, que não possui atributos ou métodos. O diagrama de classe deve ser
idêntico ao diagrama exibido na Figura 25.
Figura 25 - Diagrama de classe do pacote "vo"
3.4.3.2 Pacote service
O pacote “service” contém uma classe chamada “DoadoresService”, na qual são
implementados os métodos utilizados para acessar o banco de dados. Deve ser criada sob o
pacote “org.andromda.doador” um pacote chamado service, e sob o novo pacote é preciso
criar um diagrama de classes de nome “DoadoresService” e estereótipo “Service”. No
diagrama de classes criado deve ser posicionado uma classe chamada “DoadoresService”.
Para adicionar um novo método é preciso acionar o botão direito do mouse sobre a classe e
selecionar a opção “Insert New Operation”. Surge um novo método chamado “unnamed()”,
que deve ser renomeado para o nome desejado.
Para definir os parâmetros de entrada e de retorno de um método é preciso acionar duas vezes
o botão esquerdo do mouse sobre o método desejado, e então surge uma tela para a edição do
método selecionado, mostrada na Figura 26. É possível definir novos métodos a partir da
opção “Parameters”, que se encontra do lado esquerdo da tela.
50
Figura 26 - Tela de edição de métodos
Para adicionar um novo parâmetro é preciso acionar o botão “Create”. Na lista surge um novo
parâmetro, no campo “Name” deve ser informado o nome do parâmetro, em “Type” o tipo do
valor (devem ser selecionados apenas os tipos sucedidos por [datatype]); em “Defaul Value”
deve ser informado o valor padrão do parâmetro, caso haja algum e em “Direction” a direção
que o valor do parâmetro deve seguir, por exemplo, parâmetros de entrada devem ser
definidos como “inout” e valores retornados pelo método devem ser definidos como “return”.
Os métodos da classe “DoadoresService” são detalhados a seguir:
• retornaTodosDoadores(): esse método retorna todos os doadores cadastrados na tabela
“doador”, sem qualquer filtragem.
• retornaDoador(codDoador: int): retorna apenas um doador, de acordo com o código
informado pelo parâmetro “codDoador”.
• cadastraDoador(doadorVO: DoadoresVO): insere os doadores no banco de dados. Os
dados do doador estão no parâmetro “doadorVO”.
51
• alterarDoador(doadorVO: DoadoresVO): altera o doador passado pelo parâmetro
“doadorVO”.
• excluiDoador(codDoador: int): exclui o doador pelo código informado pelo parâmetro
“codDoador”.
• filtraBusca(nome: String, uf: String, tipoSangue: String): retorna uma lista de doadores,
baseada nos parâmetros informados. Os parâmetros não são de preenchimento obrigatório,
porém quanto mais parâmetros informados maior será a filtragem da busca.
• Depois de criados todos os métodos da classe “DoadorService” o Magic Draw deve
mostrar um diagrama de classe idêntico ao exibido pela Figura 27.
Figura 27 - Classe "DoadoresService"
3.4.3.3 Pacote domain
O pacote “domain” contém uma entidade chamada “Doador”, a qual possui os atributos da
classe “doadorVO” que se encontra no pacote “vo”, e essa entidade vai mapear a tabela
“doador” do banco de dados. É preciso criar o pacote “domain” sob o pacote
“org.andromda.doador” e criar um diagrama de classe com o nome de “Domain Objects” no
novo pacote.
É necessário colocar uma nova entidade no diagrama e chamá-la de “Doador”. A entidade
criada deve conter os mesmos campos (atributos) da tabela “doador” ou da classe “doador”
que se encontra no pacote “vo”. Para criar uma nova entidade é preciso inserir no diagrama
uma classe e definir seu estereótipo como “Entity”.
Para fazer a ligação da nova entidade com a tabela “doador” deve-se acessar a opção “Tags”,
conforme a Figura 28. No painel central há um atributo chamado
52
“andromda.persistence.table”. O valor desse atributo deve ser alterado, no painel da direita,
para a tabela na qual se deseja fazer ligação, no caso a tabela “doador”.
Figura 28 – Tela de alteração de “Tags” Após a criação da entidade “doador”, o diagrama contido no pacote “domain” deve estar
como mostrado na Figura 29.
Figura 29 - Entidade "doador" no pacote "service".
Para completar o diagrama “DoadoresService” é necessário criar algumas relações entre os
objetos criados até então nos três pacotes do modelo. A primeira dependência é uma relação
entre a entidade “Doador” do pacote “domain” e a classe “DoadorVO” do pacote “vo”. Essa
relação diz para o AndroMDA implementar a conversão de métodos entre os dois objetos.
Para criar a dependência é preciso abrir o diagrama contido no pacote “vo”, e arrastar, a partir
53
da sessão “Containment”, a entidade “Doador” do pacote “domain”. Uma referência dessa
entidade surge no diagrama.
Para criar a dependência entre os dois objetos deve-se usar a ferramenta “Dependency”, a
quarta opção do grupo “Common” da caixa de ferramentas. Para finalizar a criação da
dependência é preciso, com a ferramenta “Dependency” ativada, pressionar o botão esquerdo
do mouse sobre a entidade “Doador”, e com o botão ainda pressionado, posicionar o ponteiro
sobre a classe “DoadorVO” e então soltar o botão do mouse. Surge uma seta entre os dois
objetos, indicando que a dependência foi criada. A Figura 30 mostra como deve estar o
diagrama após essa operação.
Figura 30 - Diagrama "Value Objects" após a criação da dependência.
A próxima dependência a ser definida é entre os objetos “DoadorService”, do pacote
“service” e a entidade “Doador”. Essa relação implementa a forma de como os registros do
banco de dados serão lidos e/ou escritos pela aplicação.
Para fazer essa dependência é necessário arrastar, com o mouse, a entidade “Doador” para o
diagrama “DoadoresService”, e então criar a dependência, pressionando, com a ferramenta
“Dependency” ativada, o botão esquerdo do mouse sobre a classe “DoadorService” e arrastar
o ponteiro até a entidade “Doador” e soltar o botão do mouse. O diagrama deve ser idêntico
ao mostrado na Figura 31.
54
Figura 31 - Diagrama "DoadorService" após a criação da dependência.
3.5 GERAÇÃO DE CÓDIGO
Após a criação do modelo PIM da aplicação, explicada na sessão 3.4.3, é necessário gerar o
código-fonte desse modelo para Java. O Magic Draw, utilizado para implementar o modelo
da aplicação, também é capaz de gerar código XMI de modelos UML. O AndroMDA utiliza
esse arquivo XMI para fazer a tradução do modelo PIM para código-fonte da linguagem alvo,
no caso específico deste trabalho Java. A Figura 32 ilustra esse processo.
Figura 32 – Processo de transformação do modelo PIM em código de programação.
Para gerar o código XMI do modelo, no Magic Draw é preciso acessar o item “Export UML2
XMI” a partir do menu “File/Export”. O Magic Draw apresenta uma janela para que seja
selecionado um diretório onde será salvo o arquivo XMI. Deve ser selecionado o diretório
“mda\src\main\uml”, gerado pelo AndroMDA e descrito com mais detalhes na Sessão 3.3. Na
parte inferior da tela o Magic Draw exibe um relatório, como demonstrado na Figura 33, e em
caso de haver erros durante o processo eles estão especificados nesse relatório.
55
Figura 33 – Janela de relatório do Magic Draw, após a geração do arquivo XMI.
Com o arquivo XMI gerado, já é possível gerar o código da aplicação por meio do
AndroMDA. Para tal, é preciso acessar o prompt de comando e mudar para o diretório raiz
(C:\TCC\doador) do framework gerado pelo AndroMDA e comentado na sessão 3.3. Para
gerar o código é preciso digitar no prompt o comando “mvn install”. O AndroMDA então
inicia o processo de conversão do modelo em código-fonte e durante esse processo são
apresentadas diversas mensagens na tela, descrevendo o que o AndroMDA está fazendo no
momento. É preciso estar conectado na Internet, pois o AndroMDA pode precisar fazer o
download de algum arquivo adicional a partir de seu repositório online. Ao final do processo,
caso não haja nenhum erro, deve surgir uma mensagem “BUILD SUCCESSFULL”, indicando
que o código-fonte foi gerado com sucesso.
3.5.1 Construção da Interface Gráfica
Embora seja possível gerar a interface gráfica da aplicação utilizando o AndroMDA, por meio
de diagramas de atividade, a interface gerada pelo AndroMDA em geral precisa ser ajustada
posteriormente para se adequar ao formato desejado, e para aplicações de pequeno porte não
compensa o esforço para desenvolver um diagrama de atividades. Assim, neste trabalho
optou-se desenvolver a interface gráfica utilizando o Studio Creator, uma ferramenta de
desenvolvimento de aplicações Java desenvolvida pela Sun Microsystems, que fornece
suporte nativo ao JSF.
3.5.1.1 Criação de um Projeto no Studio Creator
Para criar um novo projeto no Studio Creator é necessário acessar o item “New Project”,
presente no menu File. Surge uma janela, ilustrada na Figura 34, onde se é definido o tipo de
56
projeto. Para criar uma aplicação JSF deve-se selecionar em “Categorires” o item “Web”, e
em “Projects” o item “JSF WEb Application”.
Figura 34 – Definição do tipo de projeto.
Depois de escolhido o tipo de projeto, deve ser definido o local onde o esse projeto será salvo.
No exemplo da Figura 35, o local escolhido é o drive “C:\”. O nome do projeto é “Doador”, e
o pacote na qual pertence os arquivos referentes ao projeto “doador”.
Figura 35 – Local do novo projeto.
57
Depois de criada a aplicação, surge uma página em branco, pronta para receber quaisquer
componentes de interface gráfica para compor uma página com elementos JSF. Na sessão
3.5.1.2 esses componentes serão vistos com mais detalhes.
3.5.1.2 Utilização dos Componentes de Interface Gráfica
É apresentado nesta sessão como utilizar alguns elementos de interface gráfica e como montar
os formulários de entrada de dados com esses componentes. A Figura 18, que se encontra na
sessão 3.4.2, ilustra a tela principal da aplicação, que possui um elemento chamado “Static
Text”, na qual serve para colocar na página um texto fixo, como por exemplo, a frase “Bem-
vindo ao Sistema de Cadastro de Doadores” na tela inicial da aplicação. A tela inicial ainda
possui outros dois componentes do tipo “Button” que servem para disparar uma ação qualquer
quando acionado, como executar um método de algum objeto ou acessar outras telas da
aplicação.
A lista de componentes JSF, disponibilizados pelo Studio Creator, se encontram ao lado
esquerdo da tela principal, na aba chamada “Palette”, como ilustrado na Figura 36. Para
colocar qualquer um desses componentes é preciso clicar com o botão esquerdo do mouse
sobre o componente desejado e em seguida posicionar o ponteiro do mouse sobre a página e
clicar novamente com o botão esquerdo para inserir o componente na página.
Figura 36 – Lista de componentes JSF
Para criar a tela principal da aplicação é preciso então colocar um componente “Static Text” e
dois “Button”. Para alterar o texto padrão do componente “Static Text”, deve-se ir até a aba
58
“Properties”, ao lado direito do Studio Creator e ilustrada na Figura 37, e digitar a frase
desejada na propriedade “text”.
Figura 37 – Aba “Properties”
O mesmo procedimento deve ser feito para os dois “Button”, colocá-los no formulário e
alterar a propriedade “text” para o valor desejado.
A tela de cadastro de doadores, ilustrada na Figura 19, é composta por quatro componentes
conhecidos por “Text Field”. Esse tipo de componente é utilizado para que o usuário insira
informações, que posteriormente podem ser processadas e inseridas em uma tabela num
banco de dados, por exemplo. Cada um desses componentes tem alinhado à sua esquerda um
“Static Text”, que serve para orientar o usuário sobre que valor preencher em cada campo de
entrada.
Esse formulário possui ainda dois componentes do tipo “Drop Down List”. Esse componente
oferece ao usuário uma ou mais opções de valores possíveis para ser escolhido. Os valores
que compõem um “Drop Down List” podem vir de um banco de dados, ou serem definidos
estaticamente dentro da propriedade “items”. No caso da aplicação de cadastro de doadores,
os valores serão carregados de tabelas no banco de dados e o modo de trazer essas
informações é abordado na sessão 3.5.1.3.
A tela de cadastro possui ainda dois “Buttons”, um com o atributo “value” definido como
“Salvar”, na qual processa o formulário para que os valores preenchidos nos campos de
59
entrada sejam inseridos na tabela “doador”, do banco de dados. O outro “Button” tem o
“value” definido como “Voltar”, e seu propósito é retornar a aplicação para a tela principal.
A tela de busca de doadores possui um “Text Field”, onde o usuário pode entrar com um texto
para que seja feita uma pesquisa por nome de doador. A tela ainda possui dois “Drop Down
Lists”, que trazem valores do banco referentes a, respectivamente, a UF e tipo de sangue a ser
escolhido para refinar a pesquisa de doadores. O “Button” “Buscar”, quando acionado, traz na
tela uma pesquisa filtrada de acordo com os valores definidos nos campos de entrada,
enquanto que o “Button” “Voltar” retorna para a tela principal da aplicação.
3.5.1.3 Populando “Drop Down Lists”
As telas de cadastro e de busca de doadores possuem dois campos de entrada “UF” e
“Sangue”, que são componentes do tipo “Drop Down List”, na qual listam, respectivamente,
as Unidades Federativas brasileiras cadastradas na tabela “estados” e os tipos sangüíneos
conhecidos possíveis para a espécie humana, cadastrados na tabela “tipo_sanguineo”.
Primeiramente é necessário criar um “Data Source”, que é um componente que faz a
comunicação da aplicação com o banco de dados. Para criar um novo “Data Source” no
Studio Creator é preciso acessar a aba “Servers”, que está ao lado esquerdo da tela principal.
Nessa aba se encontra um item chamado “Data Sources”, com uma lista de “Data Sources”
pré-definidos. Para criar um novo “Data Source” é necessário apontar o mouse sobre o item
principal e clicar com o botão direito, e então acionar a opção “Add Data Source”. Na janela
que se abre, ilustrada na Figura 38, é onde serão informados os parâmetros necessários para a
definição de um novo “Data Source”, que vai fazer a conexão com o banco “Doador”, onde
estão as tabelas que a aplicação necessita para fazer a inserção de informações e a pesquisa
das mesmas.
60
Figura 38 – Tela de adição de “Data Source”
As informações a serem preenchidas na tela de adição de um novo “Data Source” devem
seguir ao que foi ilustrado na Figura 38, caso todos os passos explicados neste trabalho
tenham sido seguidos à risca. Do contrário, será necessário alterar essas informações para que
estejam de acordo com o que foi alterado nas etapas descritas anteriormente. A estrutura do
novo “Data Source” deve ser como ao que está ilustrado na Figura 39.
Figura 39 – Lista de tabelas trazidas pelo “Data Source”
Após a criação do novo “Data Source”, surge um novo item chamado “DataSourceDoador”.
O próximo passo é arrastar, com o mouse, as tabelas “estados” e “tipo_sanguineo” desse novo
item para o formulário de cadastro de doadores. Com isso surgem dois novos componentes do
tipo “Data Provider”. São esses componentes responsáveis pelo retorno das informações
cadastradas no banco de dados. Esses novos “Data Providers” podem ser visualizados no
canto inferior esquerdo do Studio Creator, como mostrado na Figura 40.
61
Figura 40 – Lista de “Data Providers” disponíveis.
Após a criação dos “Data Providers” é preciso associá-los com seus respectivos “Drop Down
Lists”. Para isso é preciso clicar sobre o “Drop Down List” “UF” com o botão direito do
mouse. Em seguida deve-se acessar a opção “Bind to Data”. Na janela que se abre, é
necessário clicar sobre a aba “Bind to Data Provider”, na qual dará a opção de escolher o
“Data Provider” a ser vinculado ao “Drop Down List” “UF”. No campo “Choose a Data
Provider to bind to dropDown1” o “Data Provider” selecionado deve ser o
“estadosDataProvider”. Em “Value Field” deve ser selecionado o campo “sigla” da tabela
“estados” e em “Display Field” o campo “nome”. Ao final deve-se ter o resultado mostrado
na Figura 41.
62
Figura 41 – Vinculação de um “Data Provider” com um “Drop Down List”
Ao final da configuração percebe-se que o texto mostrado pelo “Drop Down List” “UF”
mudou para “abc”, indicando que a vinculação com o “Data Provider” foi feita com sucesso,
e que quando a aplicação estiver em modo de execução o “Drop Down List” “UF” apresentará
todos os registros cadastrados na tabela “estados”. Para vincular o campo “Sangue” com a
tabela “tipo_sanguineo” deve ser seguido os mesmos procedimentos da vinculação do campo
“UF” com a tabela “estados”, apenas trocando o campo “Choose a Data Provider to bind to
dropDown2” para “tipo_sanguineoDataProvider”, e em “Value Field” e “Display Field”
selecionar o campo “tipo_sangue”. Todo o processo feito na tela de cadastro de doadores deve
ser executado na tela de busca de doadores.
3.5.1.4 Definição da navegação entre páginas
Um dos recursos oferecido pelo JSF é o “Navigation Case”, onde são criadas ligações entre as
páginas, permitindo definir de forma prática e direta a navegação de todo o sistema. Para criar
o “Navigation Case” da aplicação é necessário clicar com o botão direito do mouse sobre
qualquer página e escolher a opção “Page Navigation”. Abre-se então uma janela, com uma
representação de todas as páginas da aplicação.
63
Para criar uma ligação entre a página principal (Page1.jsp) com a tela de cadastro de doadores
(cadastro.jsp) é necessário clicar sobre a representação da página principal. A representação
aumenta de tamanho e é possível visualizar os dois botões pertecentes a essa página. Ao clicar
sobre o “Button1”, botão de acesso ao cadastro, o sistema deve redirecionar o usuário para a
tela de cadastro de doadores. Para estabelecer essa ligação deve-se clicar com o botão
esquerdo do mouse sobre o “Button1” e com o botão ainda pressionado, arrastar o ponteiro do
mouse até a página “cadastro.jsp”. Surge então uma seta, indicando que a ligação entre as
duas páginas foi estabelecida.
Para estabelecer uma ligação entre a página principal e a página de busca de doadores, deve-
se executar os mesmos passos da criação da ligação com a tela de cadastro, porém ligando o
“Button2” com a página “pesquisa.jsp”. Outras ligações devem ser definidas, das páginas
“cadastro.jsp” e “pesquisa.jsp” para a página principal, estabelecendo o botão voltar como
ponto de partida dessas ligações. Ao final da configuração do “Navigation Case” deve-se ter
algo similar ao case ilustrado na Figura 42.
Figura 42 – Navigation Case
64
4 CONCLUSÃO
A utilização do MDA tem pontos positivos, dentre os quais o fato de manter modelo e código-
fonte sincronizados, pois qualquer alteração feita no sistema deve ser feita no modelo, e a
partir dele gerado novamente o código da aplicação. Com isso obtém-se também a vantagem
de sempre haver uma documentação atualizada do sistema. E com a existências de
ferramentas, como o AndroMDA, a aplicação do MDA no desenvolvimento de software se
torna facilitada, já que a própria ferramenta se encarrega de muitas vezes procurar os módulos
necessários para gerar o código-fonte da aplicação, de acordo com requisitos pré-definidos
(frameworks de persistência de banco de dados e de interface gráfica, por exemplo).
Contudo é preciso uma avaliação criteriosa sobre o uso do MDA. Embora seu uso esteja se
difundindo, as ferramentas de geração de código-fonte não estão muito amigáveis ao usuário,
em termos de interface gráfica para sua operação e configuração. Sistemas de “pequeno
porte”, como a aplicação desenvolvida no decorrer deste trabalho, tendem levar mais tempo
para serem desenvolvidas utilizando o MDA, do que serem feitas diretamente em uma
ferramenta de desenvolvimento como o Studio Creator.
É possível gerar a interface gráfica da aplicação por meio do AndroMDA, utilizando
diagramas de atividade, porém o resultado final em geral não é satisfatório, pois é necessário
fazer diversos ajustes na interface gráfica até que fique como planejada. Por esse motivo
optou-se neste trabalho gerar a interface da aplicação direto no Studio Creator, ao invés de
usar o AndroMDA para esse fim.
O uso do framework JSF traz vantagens quanto ao desenvolvimento da interface gráfica, em
especial quando se faz uso de ferramentas de desenvolvimento de software, como o Studio
Creator. Essas ferramentas facilitam a criação da interface, oferecendo funcionalidades como
o “arrastar e soltar” componentes na tela, assim como vincular os campos de entrada de um
formulário diretamente com seus respectivos campos dentro de uma tabela no banco de dados.
65
Após o desenvolvimento da aplicação proposta no decorrer deste trabalho, pode-se verificar
que o uso do JSF ajudou a aumentar a produtividade no desenvolvimento da aplicação, já que
o Studio Creator dá um bom suporte a esse framework, facilitando a sua aplicação no
desenvolvimento de softwares. Já o uso do MDA se mostrou mais complexo, e dada essa
complexidade em contraste com a simplicidade da aplicação desenvolvida, o MDA foi um
fator dificultador ao invés de facilitador, pois teve que ser estudado, além de ocorrerem
problemas técnicos, como os servidores do AndroMDA, responsáveis por manter módulos
necessários para a tradução do modelo em código-fonte, ficarem offline diversas vezes,
impossibilitando o uso dessa ferramenta no momento.
66
5 REFERÊNCIAS BIBLIOGRÁFICAS
ANDRADE, Maria Margarida de. Introdução à Metodologia do Trabalho Científico. 4.ed. São Paulo : Editora Atlas, 1999. 153p. ISBN 85-224-2300-8.
ANDROMDA. AndroMDA Model Driven Architecture Framework. Disponível em http://www.andromda.org. Acesso em 13/09/2005.
ANNEKE, Kleppe; WARMER, Jos; BAST, Wim. MDA Explained: the Model Driven Architecture: Practice and Promise. Addison Wesley, 2003. 192p. ISBN 0-321-19442-X.
BERGSTEN, Hans. JavaServer Faces. Sebastopol : O’Reilly, 2004. 606p. ISBN 0-596-00539-3.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML, Guia do Usuário. 5.ed. Rio de Janeiro : Editora Campus, 2000. 472p. ISBN 85-352-0562-4.
COSTA, Janaina. Um Estudo Sobre a Arquitetura Orientada por Modelos (MDA). São José, 2004. 144p. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação). UNIVALI, 2004.
DUDNEY, Bill; LEHR, Jonathan; WILLIS, Bill et al. Mastering JavaServer Faces. Indianapolis : Wiley Publishing, 2004. 456p. ISBN 0-471-46207-1.
FRANKEL, David. Model Driven Architecture. Applying MDA to Enterprise Computing. Indianapolis : Wiley Publishing, 2003. 329p. ISBN 0-471-31920-1.
GEARY, David; HORSTMANN, Cay. Core JavaServer Faces. Prentice Hall PTR, 2004. 637p. ISBN 0-131-46305-5.
GROSE, Timothy J.; DONEY, Gary C.; BRODSKY, Stephen A. Mastering XMI: Java Programming with XMI, XML and UML. Wiley Publishing, 2002. 480p. ISBN 0-471-38429-1.
MANN, Kito. JavaServer Faces in Action. Greenwich : Manning Publications, 2005. 1038p. ISBN 1-932394-11-7.
MARCONI, Marina de Andrade; LAKATOS, Eva Maria. Técnicas de Pesquisa. 4.ed. São Paulo : Editora Atlas, 1999. 260p. ISBN 85-224-2267-2.
MAVEN Welcome to Maven. 2006. Disponível em: http://maven.apache.org/. Acesso em 09/10/2006.
MELLOR, Stephen J.; SCOTT, Kendall; UHL, Axel et al. MDA Distilled: Principles of Model-Driven Architecture. Addison Wesley, 2004. 176p. ISBN 0-201-78891-8.
OMG. OMG Model Driven Architecture. Disponível em http://www.omg.org/mda. Acesso em 13/09/2005.
OMG.a UML - Unified Modeling Language. 2004. Disponível em: http://www.uml.org/#UML2.0. Acesso em 29/10/2005.
67
OMG.b. The MDA Guide Version 1.0.1. 2003. 62p.
OMG.c. MDA FAQ. Disponível em http://www.omg.org/mda/faq_mda.htm. Acesso em 05/11/2005.
PÁDUA, Elisabete Matallo Marchesini de. Metodologia da Pesquisa. Abordagem Teórico-Prática. 8.ed. Campinas : Papirus Editora, 2002. 120p. ISBN 85-308-0607-7.
SIEGEL, Jon. Developing in OMG’s Model-Driven Architeture. 2001. 12p.
WIKIPÉDIA. Framework. Disponível em http://pt.wikipedia.org/wiki/Framework. Acesso em 15/11/2005.
WIKIPÉDIA.a. Apache Maven. Disponível em http://pt.wikipedia.org/wiki/Apache_Maven. Acesso em 09/10/2006.
68
6 ASSINATURAS
______________________________________ Acadêmico: André Luiz Fernandes dos Santos
___________________________________________ Professor Orientador: Paulo Roberto Riccioni
