Introdução - Projetos

1
RODISON DOS SANTOS FERREIRA
UMA APLICAÇÃO PRÁTICA DE UML PARA
SISTEMAS J2EE
Trabalho de Conclusão de Curso
apresentado ao Curso de Bacharelado
em Sistemas de Informação da
Universidade Federal de Santa Catarina
como requisito parcial para obtenção do
grau de bacharel em Sistemas de Informação
Orientador: Prof. Raul Sidnei Wazlawick, Dr.
Florianópolis
2004
2
RODISON DOS SANTOS FERREIRA
UMA APLICAÇÃO PRÁTICA DE UML PARA
SISTEMAS J2EE
Florianópolis, 14 de junho de 2004
BANCA EXAMINADORA
______________________________
Prof. Raul Sidnei Wazlawick
Universidade Federal de Santa Catarina
Orientador
_______________________________
______________________________
Prof. José Eduardo De Lucca
Prof. Frank Augusto Siqueira
Universidade Federal de Santa Catarina
Universidade Federal de Santa Catarina
3
AGRADECIMENTOS
Agradeço primeiramente à minha família,
por todo o apoio que me deram e por terem
sempre me mostrado o caminho certo para o
meu crescimento.
Agradeço aos meus amigos por toda a
força e diversão proporcionada quando eu
precisava, e por saber que eu sempre posso
contar com eles para qualquer coisa.
Agradeço aos meus professores que me
ensinaram não só suas matérias, mas também
um pouco do que é a vida.
E, por fim, agradeço à Universidade
Federal de Santa Catarina por me possibilitar
aprender tudo o que eu aprendi até hoje.
4
SUMÁRIO
1. INTRODUÇÃO ..................................................................................................... 9
1.1. Contextualização ........................................................................................... 9
1.2. Objetivos do Trabalho ................................................................................. 11
1.2.1. Objetivo Geral ....................................................................................... 11
1.2.2. Objetivos Específicos............................................................................ 11
1.2.3. Justificativa do Trabalho ....................................................................... 12
1.2.4. Escopo .................................................................................................. 12
1.2.5. Meta ...................................................................................................... 13
2. A ARQUITETURA J2EE .................................................................................... 14
2.1. Java ............................................................................................................. 14
2.2. O Modelo de Componentes......................................................................... 15
2.3. Componentes J2EE .................................................................................... 17
2.3.1. Clientes J2EE ........................................................................................... 17
2.3.1.1. Clientes Web ......................................................................................... 17
2.3.1.2. Clientes da Aplicação ............................................................................ 17
2.3.2. Componentes JavaBeans ..................................................................... 18
2.3.3. Componentes Web ............................................................................... 18
2.3.4. Componentes de Negócios (Enterprise JavaBeans) ............................ 18
2.3.5. Servidor J2EE (Application Server)....................................................... 19
2.3.6. APIs J2EE ............................................................................................. 21
2.4. Componentes?! ........................................................................................... 22
3. UML ................................................................................................................... 23
3.1. Componentes UML versus Componentes de Software e Componentes
EJBs. .......................................................................................................................... 33
4. PROPOSTAS PARA O MAPEAMENTO EJB/UML ............................................ 34
4.1. Especificação UML 1.5 – Tratamento do Mapeamento EJB/UML. .............. 36
4.2. Java Specification Request-26 – UML/EJB Mapping Specification (JSR-26)
.................................................................................................................................... 38
4.3. Proposta de AHMED ................................................................................... 43
5
5. Mapeamento J2EE para UML ............................................................................ 44
5.1. Servlets ....................................................................................................... 44
5.1.1. Relacionamentos .................................................................................. 44
5.2. Páginas Web e JSPs ................................................................................... 47
5.2.1. JSPs ..................................................................................................... 47
5.2.2. Páginas Web ........................................................................................ 47
5.2.3. Relacionamentos .................................................................................. 48
5.3. Struts ........................................................................................................... 48
5.3.1. Classe ActionServlet do Struts ............................................................. 48
5.3.2. Classe Form do Struts .......................................................................... 49
5.3.3. Classe Action do Struts......................................................................... 50
5.4. EJBs ............................................................................................................ 51
5.4.1. Interfaces .............................................................................................. 51
5.4.2. Session e Entity Beans ......................................................................... 52
5.4.3. SessionBeans ....................................................................................... 52
5.4.4. EntityBeans ........................................................................................... 55
5.4.5. Relacionamentos CMR ......................................................................... 57
5.4.6. EJBs e os diagramas de interação ....................................................... 57
5.5. WebServices ............................................................................................... 59
5.5.1. Interface ................................................................................................ 60
5.5.2. Visão externa e interna do WebService ................................................ 60
5.5.3. Padrões de Nomes ............................................................................... 61
5.5.4. WebServices e os diagramas de interação ........................................... 61
Bibliografia ............................................................................................................. 63
6
Lista de Figuras
Figura 1: Diagrama de Casos de Uso 24
Figura 2: Diagrama de Classes 25
Figura 3: Diagrama de classes utilizado para representar dependências entre
pacotes. 26
Figura 4: Diagrama de estados 27
Figura 5: Diagrama de Atividades 28
Figura 6: Diagrama de Seqüência 29
Figura 7: Diagrama de Colaboração 30
Figura 8: Diagrama de Componentes 31
Figura 9: Diagrama de Distribuição 32
Figura 10: Exemplo de Modelagem externa e interna de um EJB segundo a
especificação UML 1.5 37
Figura 11: Exemplo de uma modelagem interna de um EJB segundo a
especificação UML 1.5 38
Figura 12: Exemplo de modelagem externa de EJBs segundo a JSR-26. 41
Figura 13: Exemplo de Modelagem Interna de EJBs segundo a JSR-26. 42
Figura 14: Diagrama de Distribuição de EJBs segundo a JSR-26. 42
Figura 15: Representação de um Servlet 44
Figura 16: Relacionamentos de um Servlet 44
Figura 17: Especificando parâmetros através de nota 45
Figura 18: Especificando os tipos de parâmetros 45
Figura 19: Utilização do estereótipo <<Submit>> ao invés do <<POST>> e do
<<GET>>. 46
Figura 20: Relacionamento entre dois Servlets através do estereótipo
<<Forward>>. 46
Figura 21: À esquerda, o ícone de uma página JSP. À direita, a representação de
uma página JSP através do estereótipo <<ServerPage>>. 47
Figura 22: À esquerda, o ícone de uma página Web. À direita, a representação de
uma página Web através do estereótipo <<ClientPage>>. 47
7
Figura 23: Relacionamentos entre ServerPages e ClientPages. 48
Figura 24: Representação do Action Servlet do Struts. 48
Figura 25: Página Web chamando o ActionServlet do Struts. 49
Figura 26: Representação de uma classe Form do Struts. 49
Figura 27: Classe Form do Struts sendo chamada pelo ActionServlet do Struts. 50
Figura 28: Representação da classe Action do Struts 50
Figura 29: Uma classe Action do Struts sendo chamada pelo ActionServlet do
Struts. 51
Figura 30: Exemplo de representação um EJB utilizando o símbolo de
subsistemas da UML. 51
Figura 31: Representação de um EJB e alguma de suas interfaces 52
Figura 32: Representação de um SessionBean 53
Figura 33: Visualização externa de um SessionBean. 53
Figura 34: Visualização interna de um SessionBean 54
Figura 35: Representação de um EntityBean. 55
Figura 36: Representação externa de um EntityBean. 55
Figura 37: Representação interna de um EntityBean 56
Figura 38: Exemplo de modelagem de relacionamentos CMR 57
Figura 39: Exemplo de diagrama de interação segundo AHMED 58
Figura 40: Exemplo de uma outra alternativa para a utilização de EJBs em
diagramas de seqüência. 59
Figura 41: Exemplo de um WebService modelado como um subsistema da UML.
60
Figura 42: Representação do WebService com sua interface. 60
Figura 43: Representação da visão interna do WebService 61
Figura 44: Representação da utilização de WebServices em diagramas de
interação. 62
8
Resumo
FERREIRA, Rodison dos Santos. Uma Aplicação Prática de UML para Sistemas
J2EE. Florianópolis, 2004. 32f. Trabalho de Conclusão de Curso (Bacharelado em
Sistemas de Informação) – Curso de Bacharelado em Sistemas de Informação,
UFSC, 2004.
O presente trabalho busca fornecer, através de uma visão prática, uma forma de
modelar sistemas baseados na arquitetura J2EE. Primeiramente, são apresentadas
cada uma das três propostas de mapeamento J2EE/UML, a proposta da própria
especificação da UML 1.5, a proposta da Sun Microsystems, a JSR-26 e a proposta
feita por Kawar Zaman Ahmed. Além de um pouco destas três propostas, o autor ainda
sugere alguns acréscimos a estas propostas, principalmente para tratar do
mapeamento UML de tecnologias novas como o framework web Jakarta Struts e a
tecnologia de WebServices. Todos estes conceitos são mais bem discutidos através da
implementação de um sistema feito pelo autor, utilizando na prática o que é sugerido.
9
1. INTRODUÇÃO
1.1. Contextualização
No início da computação existiam apenas sistemas simples, isto porque a
computação naquele tempo não podia ser muito complexa devido às limitações do
hardware. À medida que o tempo foi passando o hardware foi evoluindo e o software
também. Com máquinas mais potentes passou a ser possível executar operações mais
complexas. Com o barateamento da memória, um software já podia trabalhar com
milhares de dados armazenados. E até hoje é assim, quanto mais o hardware evolui e
se torna barato, mais a complexidade do software aumenta.
Antigamente, um software de alto nível era aquele software desktop monousuário
que era instalado no computador e que vez ou outra dava algum problema, pois se
formatava o computador ou se excluía algum arquivo e o sistema deixava de funcionar;
daí era necessário reinstalá-lo.
Com o advento da Internet, passou a surgir a necessidade destes sistemas
desktops se comunicarem com a Internet. Estes sistemas agora podiam acessar uma
única base de dados através da Internet. Os sistemas evoluíram para sistemas
multiusuários. Só que à medida que os sistemas evoluíram, os problemas também
aumentaram. Agora era necessário lidar com acesso concorrente e distribuído, era
necessário fazer controles de transação de dados, era necessário implementar uma
política de segurança para o sistema para impedir que qualquer pessoa não-autorizada
acessasse os dados do sistema pela Internet.
O problema é que os programadores começaram a perder mais tempo se
preocupando com todas estas implementações do que com a implementação das
regras de negócios. E a evolução não parou por aí. Tamanha foi a integração da
10
Internet com os sistemas corporativos que hoje em dia a maior parte dos sistemas
estão sendo migrados para o ambiente Web.
Com o tempo, notou-se que as arquiteturas de programação existentes já não
conseguiam acompanhar a evolução do software por isso surgiram arquiteturas de
programação mais evoluídas como a arquitetura J2EE e o .NET. O objetivo dessas
arquiteturas é fazer com que o programador não se concentre em questões de baixo
nível como segurança, múltiplos acessos, acesso concorrente, transações, etc, mas sim
na lógica do negócio. Com isso, pode-se tentar resolver o grande paradoxo da
computação: “desenvolver sistemas cada vez mais complexos em um tempo cada vez
menor”.
No entanto, não bastou apenas a arquitetura de software evoluir; a forma como os
sistemas são construídos, pensados também precisou mudar. Mudou o paradigma: saiu
a programação estruturada e surgiu a programação orientada a objetos. Surgiu a
Engenharia de Software, área responsável por estudar tudo o que é e pode ser utilizado
para construir e planejar um software. Surgiu a necessidade de seguir uma metodologia
de desenvolvimento de software. Várias surgiram no mercado, cada uma utilizando uma
notação gráfica própria para representar classes, relacionamentos, etc. Logo, havia
dezenas de notações diferentes para representar a mesma coisa. Então, os autores de
três das mais importantes metodologias da área se uniram para unificar e padronizar a
linguagem para representar o desenvolvimento de softwares. Assim, surgiu a UML.
Porém, existem vários elementos utilizados na arquitetura J2EE que não foram
muito bem pensados na especificação UML. Muitos analistas de sistemas e
programadores começaram a encontrar dificuldades na hora de especificar sistemas
J2EE com a UML. A própria OMG – Object Management Group, grupo responsável pela
linguagem UML – começou a incluir conceitos da arquitetura J2EE na especificação da
UML. A criadora da arquitetura J2EE, a SUN Microsystems, também criou um perfil da
UML para mapeamento EJB/UML. Além desses dois, houve mais um grupo de autores
11
– ligados à empresa Rational, criadora da linguagem UML – que propuseram um outro
perfil da UML para J2EE e sistemas Web.
Felizmente, a linguagem UML é uma linguagem desenvolvida para evoluir. É
possível que uma dessas propostas venha a ser a proposta oficial da linguagem.
Porém, o que fazer enquanto essas propostas não são aprovadas uma vez que as
empresas já estão a anos utilizando essas tecnologias? E o que fazer com as novas
tecnologias utilizadas como a tecnologia Jakarta Struts? Como utilizar a UML para criar
testes automatizados? Como representar tudo isto na prática, utilizando a linguagem
UML para tal fim? É este o ponto que será procurado alcançar neste trabalho.
1.2. Objetivos do Trabalho
1.2.1. Objetivo Geral
O objetivo geral deste trabalho é apresentar, de uma forma prática, algumas dicas
para adaptar a linguagem UML à arquitetura de desenvolvimento J2EE.
1.2.2. Objetivos Específicos
 Estudar a arquitetura J2EE;
 Estudar a linguagem de modelagem de sistemas UML;
 Estudar as três propostas de mapeamento da arquitetura J2EE para UML;
 Estudar a proposta de mapeamento de sistemas Web utilizando a UML;
 Estudar o framework Jakarta Struts;
 Estudar a tecnologia de WebServices.
 Estudar design patterns e os J2EE design patterns;
 Apresentar todos os conceitos citados acima;
 Desenvolver uma aplicação para pôr em prática os conceitos acima;
 Avaliar a utilização destes conceitos em um sistema de verdade.
12
1.2.3. Justificativa do Trabalho
Como analista de sistemas de uma empresa que começou a ingressar na
arquitetura J2EE, percebe-se que muitos conceitos que se julgavam dominados não
são totalmente compreendidos. Ao migrar para a arquitetura J2EE, sente-se a
necessidade de se especificar características desta arquitetura com a linguagem UML.
Porém, nota-se que a especificação UML não é suficiente, faltam algumas lacunas a
serem preenchidas e isto pode prejudicar na hora de fazer a modelagem de um
sistema. Além da questão do J2EE existem outras questões como a utilização de
frameworks para a parte Web como o Jakarta Struts e a adoção de novas tecnologias
como os WebServices no processo de desenvolvimento de um software.
1.2.4. Escopo
Esta proposta não tem como fim a geração automática de código, principalmente
porque seria necessário uma ferramenta que fosse integrada com a presente proposta
e a ferramenta utilizada para geração de código. Ela tem como finalidade fornecer uma
forma de representar o código o mais perto do real possível para que não haja colunas
em branco entre o que foi modelado e o que está no código.
Da mesma forma que a metodologia XP diz "teste primeiro, codifique depois", esta
proposta se baseia em um incremento desta frase, no sentido de "modele primeiro,
depois elabore os testes e, só por último, codifique". O objetivo da modelagem é
fornecer uma visão mais clara do sistema que está sendo construído não só para os
analistas, mas principalmente para os programadores, aqueles que vão tornar o projeto
em realidade. Fazendo a modelagem do sistema antes de tudo, pode-se garantir que o
sistema foi bem pensado e bem organizado, bem estruturado. Com a modelagem, os
programadores e analistas de sistemas podem perceber onde aplicar determinado
design patterns, onde são necessários tais estruturas de objetos, etc.
O ideal, seria que o programador NUNCA mexesse no código sem mexer na
modelagem antes. PRINCIPALMENTE na fase de manutenção do sistema, ou seja,
depois que o sistema já está considerado pronto, já está rodando em produção e é
13
necessário fazer aquelas alterações "mínimas" em 1 hora. De nada adianta os
programadores e os analistas fazerem a modelagem de um sistema, se depois que o
sistema estiver pronto a modelagem não refletir o código e vice-versa.
1.2.5. Meta
A presente proposta visa representar o mais fielmente possível o código gerado da
forma mais simples possível, sem necessitar utilizar certas "burocracias" que algumas
propostas sugerem para que o processo de modelagem se torne prático, completo, sem
ser demorado.
O desafio deste trabalho será fazer a modelagem completa de um sistema
utilizando os conceitos mostrados nesta proposta. O sistema será desenvolvido
utilizando ferramentas baseadas em código livre e ferramentas freeware. O objetivo é
mostrar como fazer a modelagem de um sistema completo, do início até o fim,
passando por todas as dificuldades de desenvolvimento, restrições de ferramentas,
utilização e adaptação de tecnologias novas, etc.
Para desenvolver o sistema, será utilizada uma metodologia de desenvolvimento
que pode ser considerada uma mescla entre RUP, ICONIX e eXtreme Programming.
OBS:
O Sistema a ser desenvolvido ainda está sendo escolhido e definido. O
objetivo desta primeira fase do projeto é aprender a utilizar as tecnologias que
serão aqui utilizadas (EJBs, Struts, Design Patterns, Ant, JUnit, etc) e estudar as
principais propostas de mapeamento J2EE/UML.
14
2. A ARQUITETURA J2EE
Com o aumento da complexidade do software, surgiu a necessidade de uma
arquitetura mais avançada. Segundo AHMED (1), “o J2EE, Java 2 Platform Enterprise
Edition, é tal estrutura. O J2EE é uma plataforma completa para distribuir sistemas
complexos. Ela aumenta o nível de abstração para a equipe de desenvolvimento
oferecendo um conjunto de mecanismos (JSP, Enterprise JavaBeans, servlets) e
serviços (JDBC, JMS e RMI, para citar alguns), permitindo que a equipe se concentre
em seu valor comercial central em vez de construir a intra-estrutura”.
Segundo BODOFF (2), “o J2EE é uma tecnologia baseada em componentes de
software para projeto, desenvolvimento, montagem e implantação de aplicações
comerciais. Ela apresenta um modelo de aplicação distribuída multicamada, a
capacidade de reutilização de componentes, troca de dados integrada baseada na
Extensible Markup Language (XML), um modelo de segurança unificado e um flexível
controle de transações”.
2.1. Java
O J2EE é uma das três áreas da plataforma Java. A plataforma Java é composta
por uma linguagem de programação chamada Java e por uma máquina virtual,
chamada Java Virtual Machine (JVMTM), onde os programas Java são executados. Para
cada sistema operacional é feita uma JVM específica. Desta forma, qualquer software
feito em Java é independente de plataforma. Qualquer sistema operacional (Windows,
Linux, Unix, Solaris, PalmOS, celulares) que tenham um JVM instalada pode rodar
programas Java.
A plataforma Java se divide em três áreas:
 Java 2 Micro Edition (J2ME): arquitetura Java para aplicações móveis como
celulares, handhelds (computadores de mão como o PalmTop TM), dispositivos
15
(MP3 Players, GPS, relógios, etc), eletrodomésticos (microondas, geladeira, etc),
computadores de bordo (utilizados em carros, aviões, etc) e outras aplicações do
mesmo tipo. Ela contém uma JVM reduzida para rodar aplicações simples.
 Java 2 Standard Edition (J2SE): arquitetura Java para aplicações tradicionais
como aplicações desktop de modo console (ou terminal, ou modo texto) ou de
modo gráfico (através das bibliotecas gráficas Swing, SWT, AWT, etc).
 Java 2 Enterprise Edition (J2EE): arquitetura Java para aplicações comerciais.
Esta é a arquitetura tratada neste trabalho.
2.2. O Modelo de Componentes
A
tecnologia
J2EE
é
uma
tecnologia
baseada
em
componentes.
O
desenvolvimento baseado em componentes oferece muitas vantagens, entre elas a
reutilização de programação.
Quando se vai fazer um sistema novo, ao invés de desenvolver uma classe que
gera um texto PDF a partir de uma página HTML, pode-se utilizar um componente que
faz essa conversão automaticamente. Dessa forma não se perde tempo “refazendo a
roda”, ou seja, criando algo que alguém já criou antes.
O modelo de componentes é um conceito que é utilizado na indústria
automobilística, por exemplo. Se a cada vez que se fosse construir um carro fosse
necessário também criar um motor, rodas, freios e todos os outros componentes que
um carro contém, levaria muito tempo para se construir um carro novo e o custo de
construção do carro seria muito maior.
Até pouco tempo atrás, era exatamente isso que se fazia, sempre que se ia
construir um software novo, tudo era criado do zero. Exatamente para evitar isso é que
a indústria de software passou a utilizar o modelo de componentes.
16
Como explicitado por AHMED (1), estas são algumas vantagens do modelo de
componentes:
 Produtividade mais alta: Menos desenvolvedores podem conseguir mais
reunindo uma aplicação a partir de componentes pré-definidos e testados
previamente em vez de implementar uma solução personalizada a partir do zero.
 Desenvolvimento rápido: Os componentes existentes podem ser reunidos
rapidamente para criar novas aplicações.
 Qualidade mais alta: Em vez de testar as aplicações inteiras, os desenvolvedores
podem se concentrar em testar a integração e a funcionalidade geral da
aplicação conseguida através dos componentes pré-definidos.
 Manutenção mais fácil: Como os componentes são independentes, a
manutenção é muito mais fácil e com um custo menor.
Deve-se ressaltar, porém que é muito importante que todos os componentes
utilizados estejam muito bem testados, principalmente se quem fez os componentes é a
própria empresa (o que acontece hoje em dia na maior parte dos casos). Quando se
compra o componente de uma outra empresa, é necessário ter garantias que o
componente utilizado não contém erros. O sistema não pode correr o risco de não
funcionar direito por causa de um erro de um componente de terceiros.
Infelizmente ainda não há um mercado de componentes de software muito
amadurecido e muito menos órgãos que fiscalizem a qualidade destes componentes. O
mercado de componentes é um mercado que está marcado para crescer faz anos, mas
que ainda não se manifestou com força, principalmente no Brasil.
17
2.3. Componentes J2EE
A especificação J2EE define os seguintes componentes J2EE:
 Clientes da aplicação e applets: componentes executados no cliente;
 Componentes da tecnologia Java Servlet e JavaServer PagesTM (JSPTM):
componentes Web executados no servidor;
 Componentes Enterprise JavaBean (EJB, ou enterprise beans): componentes
de negócios que são executados no servidor.
Há ainda o modelo de componentes JavaBeans, pertencentes à plataforma J2SE
2.3.1. Clientes J2EE
Um cliente J2EE pode ser um cliente Web ou um cliente da aplicação.
2.3.1.1. Clientes Web
Um cliente Web pode ser um conjunto de páginas Web dinâmicas (como páginas
HTML, XML, etc) que são executadas em um navegador Web ou um conjunto de
applets (mini aplicações gráficas que são executadas em um navegador Web através
do Plugin Java).
2.3.1.2. Clientes da Aplicação
Um cliente da aplicação é geralmente uma aplicação desktop de modo console
(ou terminal, ou modo texto) ou de modo gráfico (através das bibliotecas gráficas Swing,
SWT, AWT, etc).
18
2.3.2. Componentes JavaBeans
Os componentes JavaBeans são na verdade classes que têm uma estrutura
definida. JavaBeans são classes simples que contém atributos e métodos get e set para
acessar os dados destes atributos. Eles são muito utilizados para transportar dados de
objetos entre as diferentes camadas da aplicação e também para criar componentes
gráficos.
2.3.3. Componentes Web
Os componentes Web da arquitetura J2EE podem ser servlets ou JSPs. Os
servlets
são
classes
da
linguagem
de
programação
Java
que
processam
dinamicamente solicitações (requests) e constroem respostas (responses). Eles ainda
podem trabalhar com outros serviços como controle de sessão, redirecionamento de
informação, etc. São geralmente utilizados em sistemas Web.
As páginas JSP são como páginas HTML, mas elas contém trechos de código de
programação embutida dentro dela. É até possível fazer programas apenas utilizando
páginas JSP.
2.3.4. Componentes de Negócios (Enterprise JavaBeans)
Os componentes de negócios são representados pelos Enterprise JavaBeans
(EJBs). Um EJB é um conjunto de classes Java que implementam as regras de negócio
de um sistema e que se comunicam com elementos externos (outras classes ou outros
EJBs) através de interfaces locais (quando se acessa um EJB da mesma máquina onde
ele se encontra) ou remotas (quando se acessa um EJB através da rede, de uma outras
máquina).
Existem três tipos de EJBs:
19
 Beans de Sessão (Session Beans): Responsáveis por implementar a lógica do
negócio.
 Beans de Entidade (Entity Beans): Responsáveis por persistir os dados da
aplicação em bancos de dados, arquivos e outros meios.
 Beans Orientados a Mensagens (Message-Driven Beans): Responsáveis por
se comunicar com serviços externos de forma assíncrona.
Este trabalho se concentrará apenas nos session beans e nos entity beans.
2.3.5. Servidor J2EE (Application Server)
O servidor J2EE (ou servidor de aplicações) é um servidor responsável por
implementar serviços de middleware, por ser a ponte de ligação entre a programação
de alto nível e a programação de baixo nível como serviços de rede, segurança,
transações, etc. Todos estes serviços de baixo nível são implementados pelo servidor
J2EE.
Estes são alguns serviços implementados pelo servidor de aplicações:
 Invocação Remota de Métodos: O servidor J2EE implementa toda a conexão de
rede entre cliente e servidor.
 Balanceamento de Carga: Os clientes são redirecionados para os servidores
mais livres. Se um servidor está sobrecarregado, um diferente servidor é
escolhido.
 Tratamento de Falhas Transparente: Se uma conexão de rede cai, ou se um
servidor estraga, o próprio servidor de aplicação retoma o serviço de onde ele
parou e redireciona os serviços para outro servidor ativo automaticamente.
20
 Integração com o Back-End: O desenvolvedor pode configurar o servidor de
aplicações para persistir os dados da aplicação em bases de dados, sistemas
legados ou outros tipos de persistência.
 Transações: O servidor trata o acesso simultâneo às bases de dados, bem como
faz o controle de erro dessas bases de dados.
 Clustering: Permite que os serviços, o processamento e o armazenamento sejam
divididos em várias máquinas e provê serviços como espelhamento, etc.
 Reinstalação Dinâmica: Uma aplicação pode ser instalada, iniciada, parada ou
desinstalada do servidor sem a necessidade de reiniciar o servidor para isso.
 Desligamento Limpo: É possível desligar o servido no entanto sem para os
serviços principais utilizados pelos clientes.
 Logging e Auditoria: Todas as operações feitas são registradas em arquivos de
log, bem como os erros do sistema. Assim é possível descobrir quem mexeu no
servidor e o quê foi alterado.
 Gerenciamento de Sistemas: O servidor oferece ferramentas para gerenciar as
aplicações que ele contém.
 Threading: O servidor trata o acesso de múltiplos clientes ao mesmo tempo.
 Orientação a Mensagens: O servidor faz todo o tratamento de enviar e receber
mensagens, síncronas ou assíncronas.
 Ciclo de Vida de Objetos: Os objetos podem ser criados, recriados, destruídos
pelo próprio servidor.
21
 Pool de Recursos: O servidor pode criar e gerenciar pool de recursos, como pool
de conexão ao banco de dados, de acesso aos EJBs, etc.
 Segurança: O servidor permite configurar toda a parte de segurança do sistema
através de autenticações e autorizações a cada componente do sistema.
 Caching: As consultas mais feitas podem ser armazenadas no cache do servidor,
otimizando assim o acesso à base de dados.
2.3.6. APIs J2EE
Além de tudo isso, a arquitetura J2EE ainda apresenta as seguintes APIs:
 Java DataBase Connectivity (JDBC): Responsável por se comunicar com
bancos de dados.
 Java Message Service (JMS): Responsável por enviar, receber, criar e ler
mensagens.
 Java Naming and Directory Interface (JNDI): Serviço de nomeação e diretório.
Serviço de nomes utilizados para encontrar, chamar e organizar os componentes
dentro do servidor.
 Java Transaction API (JTA): API para controle de transações.
 JavaMail API: API responsável por enviar, receber, criar e ler e-mails.
 Java API for XML Processing (JAXP): API Java para manipular arquivos XML.
 Java Authentication and Authorization Service (JAAS): API de segurança,
autenticação e autorização de usuários.
22
2.4. Componentes?!
Segundo FRANK (3), componentes de software são “unidades funcionais de
software que executam uma atividade bem definida no sistema, produzidos e
implantados independentementes, distribuídos em código binário, combinados para
compor aplicações, configurados de acordo com a necessidade do usuário, que podem
ser facilmente atualizados e reutilizados e que podem ser criados usando métodos,
técnicas e ferramentas de desenvolvimento padronizados”.
A tecnologia J2EE se diz ser baseada em componentes. No entanto, um
componente de software deveria ser independente de linguagem, ou seja, um
componente J2EE poderia ser inserido em um sistema .NET sem nenhum problema e o
inverso também deveria ser verdadeiro.
Porém, a especificação de componentes EJBs versão 2.1 prevê a inclusão de uma
implementação de interfaces de EJBs baseada no modelo de WebServices. Com isso,
um EJB poderá ser realmente denomidado um componente, pois através de uma
interface WebService qualquer aplicação (não importa a linguagem com a qual ela foi
escrita) poderá acessar os serviços de um componentes EJB.
23
3. UML
A Unified Modelling Language (UML) é uma linguagem gráfica utilizada para fazer
a modelagem e para auxiliar o desenvolvimento de sistemas. A UML não é uma
metodologia de desenvolvimento. Ela é apenas uma linguagem gráfica para representar
elementos utilizados em um sistema como classes, objetos, pacotes, relações como
agregação, herança, etc.
A UML surgiu da união de três metodologias existentes: a metodologia Booch (de
Grady Booch), a metodologia OOSE (de Ivar Jacobson) e o OMT (de James
Rumbaugh). Estes três autores juntos se uniram na empresa Rational Software
Corporation (atualmente comprada pela IBM) e criaram a linguagem UML.
A especificação UML indica no total oito diagramas utilizados:
24
 Diagrama de Caso de Uso: o diagrama de caso de uso mostra os casos de uso,
os atores e suas relações.
Figura 1: Diagrama de Casos de Uso
25
 Diagrama de Classe: diagrama que mostra as classes, seus atributos e métodos,
interfaces, pacotes, subsistemas e suas relações um com o outro.
Figura 2: Diagrama de Classes
26
Figura 3: Diagrama de classes utilizado para representar dependências entre
pacotes.
27
 Diagrama de Gráfico de Estados: capturam o comportamento dinâmico do
sistema. Mostra todos os estados pelos quais o sistema pode passar e qual
evento ocasiona a mudança de estados. Pode ser aplicado ao sistema, a um
conjunto de entidades ou a uma classe específica.
Figura 4: Diagrama de estados
28
 Diagrama de Atividades: é uma extensão do gráfico de estados e é muito
parecido com um fluxograma. Serve para mostrar todos os passos do sistema de
forma seqüencial ou em paralelo. Também pode ser aplicado ao sistema, a um
conjunto de entidades ou a uma classe específica. Também pode ser utilizado
para descrever o fluxo de um caso de uso.
Figura 5: Diagrama de Atividades
29
 Diagramas de Interação: são utilizados para modelar o comportamento dinâmico
do sistema. Existem dois tipos de diagramas de interação:
o Diagrama de Seqüência: utilizado para modelar a troca de mensagens
entre objetos, ou entre o sistema e o mundo externo. Captura a ordem das
mensagens trocadas em relação com o tempo.
Figura 6: Diagrama de Seqüência
30
o Diagrama de Colaboração: modela a troca de mensagens entre objetos
mostrando as relações estruturais entre eles.
Figura 7: Diagrama de Colaboração
31
 Diagrama de Componentes: representa a manifestação física de uma parte do
sistema, como um arquivo, um executável, etc.
Figura 8: Diagrama de Componentes
32
 Diagrama de Distribuição: representa a arquitetura do sistema. Mostra os
servidores, a parte de hardware, os componentes instalados, etc.
Figura 9: Diagrama de Distribuição
33
3.1. Componentes UML versus Componentes de Software e
Componentes EJBs.
Componentes de software, como já citado, são unidades de software que
executam uma atividade bem definida no sistema. São exemplos de componentes os
EJBs, componentes COM, ActiveX, etc. Geralmente são formados por conjuntos de
classes que os implementam.
Para a UML, no início, componentes eram manifestações físicas do sistema como
arquivos .class, arquivos executáveis, arquivos de empacotamento como os arquivos
.JAR, etc, que eram acessíveis através de interfaces. Antigamente a UML não previa
uma arquitetura de componentes como os componentes EJBs e isso causou um
impasse entre os desenvolvedores de software: “poderiam os componentes UML serem
utilizados para representar componentes EJBs?”.
O principal problema é que não há uma forma adequada, na UML, de desmembrar
um componente em um conjunto de classes. Também não há como ligar um
componente a uma classe. Dessa forma, de acordo com a especificação da UML 1.5
proposta pela OMG (6), fica muito difícil fazer uma modelagem mostrando as relações
com os componentes EJBs e as classes que se relacionam com eles.
Com a versão 2.0 da UML (a próxima versão da linguagem UML a ser lançada),
espera-se que o modelo de componentes da UML comece a refletir melhor os conceitos
dos componentes EJBs.
34
4. PROPOSTAS PARA O MAPEAMENTO EJB/UML
Segundo AHMED (1), existem alguns desafios a serem tratados na hora de fazer
um mapeamento da arquitetura J2EE utilizando UML:
 Um componente EJB implementa métodos comerciais na interface Remote, mas
não a interface em si. Isso é contrário ao conceito UML de realização da
interface.
 Um EJB está relacionado com uma interface Remote e Home. É necessário que
um modelador UML respeite de modo consistente esse padrão de arquitetura.
 Os servlets, os EJBs e outros itens da arquitetura contém arquivos descritores da
distribuição associados.
 Diferente da maioria das outras classes Java, os EJBs, servlets e JSPs são
enviados em um tipo específico de arquivo de armazenamento (arquivos .JAR,
.WAR e .EAR) juntamente com seus descritores de distribuição.
 Os atributos do componente de entidade mapeia os elementos em um banco de
dados.
 Os EJBs têm a noção de transações e segurança.
 Os EJBs da sessão podem ter potencialmente um comportamento dinâmico
significante.
 Esquemas permanentes podem ser distribuídos pelos componentes da entidade.
35
 Os JSPs são logicamente um híbrido no sentido de que têm aspectos do cliente e
do servidor.
Além desses desafios, poderia se dizer que existem mais alguns:
 Hoje em dia, muitas empresas não estão mais utilizando o modelo Servlets/JSP
puro. Muitos estão utilizando frameworks de apresentação de dados na parte
Web. O principal deles é o framework Jakarta Struts. O Struts é um framework
que liga páginas JSP à classes de controle de dados da interface, como classes
de validação de dados e classes que modelam as ações que serão feitas pelo
usuários na página Web. Tais ligações entre classes de controle do Struts e
páginas JSP precisam ser mapeadas.
 Com o advento do processo de desenvolvimento eXtreme Programming (XP), os
desenvolvedores passaram a adotar o paradigma de “teste primeiro, codifique
depois”, ou seja, primeiro o desenvolvedor deve elaborar todos os testes que
devem ser feitos para só depois de elaborados os testes, começar a codificar o
sistema. Atualmente, a UML não sugere nenhum artifício para ajudar a criar
testes de unidade e testes de validação.
 A UML não fornece uma sintaxe específica para representar design patterns e os
design patterns da arquitetura J2EE (J2EE Design Patterns).
Para suprir uma parte destas necessidades, surgiram no mercado três propostas
para o mapeamento J2EE/UML: a proposta apresentada pela OMG na própria
especificação UML 1.5, a proposta apresentada pela SUN Microsystems com a Java
Specification Request-26 – UML/EJB Mapping Specification (JSR-26) e a proposta
apresentada por AHMED (1).
36
4.1. Especificação UML 1.5 – Tratamento do Mapeamento
EJB/UML.
A especificação UML 1.5 apresentam algumas sugestões para o mapeamento
EJB/UML:
 Componentes EJBs devem ser mapeados com o símbolo de componentes da
UML e representados no diagrama de componentes da UML.
 As interfaces Home e Remote devem ser representadas como interfaces do
componente.
 As ligações entre componentes devem ser representadas através de relações de
dependências.
 Dentro do componente, podem ser representados as classes que compõe o
componente EJB.
 A classe Bean do componente EJB deve ser representado com o estereótipo
<<focus>> dentro do componente.
 Classes utilizadas pelos EJBs – como as classes de chaves primárias de um entity
bean ou classes auxiliares – devem ser representadas com o estereótipo
<<auxiliary>> dentro do componente.
 O arquivo de empacotamento do componente EJB (um arquivo EJB-JAR, por
exemplo) deve ser representado como uma classe dentro do componente com o
estereótipo <<file>>.
37
O problema desta representação são os mesmos falados anteriormente, ou seja,
não há como ligar classes ou entidades Web aos componentes, não há como
representar uma classe completa (com seus atributos e métodos) em um diagrama de
componentes e mais, não há a sugestão de nomenclaturas mais específicas para os
componentes EJBs (qual é o estereótipo para um entity bean com persistência CMP?
Ou um session bean stateless?).
Estes e outros defeitos desta proposta fez com que muitos desenvolvedores não
se sentissem à vontade para utilizá-la. Por isso, surgiu a necessidade de outras
propostas para este mapeamento.
Exemplos de modelagem EJB segundo a especificação UML 1.5:
Figura 10: Exemplo de Modelagem externa e interna de um EJB segundo a
especificação UML 1.5
38
Figura 11: Exemplo de uma modelagem interna de um EJB segundo a
especificação UML 1.5
4.2.
Java
Specification
Request-26
–
UML/EJB
Mapping
Specification (JSR-26)
A JSR é uma proposta feita pela SUN Microsystems (empresa criadora da
plataforma JAVA e da arquitetura J2EE) para fazer um mapeamento mais completo de
EJBs com a UML. Para isso, ela sugere que seja criado um perfil específico da UML
para EJBs.
Um perfil da UML é uma extensão da gramática UML para representar casos
específicos. Existem atualmente vários perfis já aprovados pela OMG, tais como o perfil
UML para Modelagem de Negócios e o perfil UML para processo de desenvolvimento
de software.
39
Este perfil, sugere a adoção de alguns estereótipos, como:
 <<JavaInterface>>: Indica a interface de uma classe Java padrão.
 <<EJBCreateMethod>>: Indica um método EJB Create.
 <<EJBFinderMethod>>: Indica um método EJB Finder.
 <<EJBRemoteMethod>>: Indica um método EJB Remoto.
 <<EJBRemoteInterface>>: Indica que a classe é uma Interface Remota EJB.
 <<EJBSessionHomeInterface>>: Indica que a classe representa um EJB
Session Home.
 <<EJBEntityHomeInterface>>: Indica que a classe representa um EJB Entity
Home.
 <<EJBPrimaryKey>>: Indica que a classe é uma classe EJB Primary Key,
utilizada em um entity bean.
 <<EJBRealizeHome>>: Indica que a classe bean realiza uma interface Home.
 <<EJBRealizeRemote>>: Indica que a classe bean realiza uma interface Remote.
 <<EJBImplementation>>: Indica que a classe é a classe de implementação do
EJB, é uma classe bean.
 <<EJBEnterpriseBean>>: Indica que o componente é um EJB.
40
 <<EJBSessionBean>>: Indica que o componente é um Sesion Bean.
 <<EJBEntityBean>>: Indica que o componente é um Entity Bean.
 <<JavaClassFile>>: Indica que o elemento é um arquivo .class.
 <<JavaArchiveFile>>: Indica que o elemento é um arquivo de empacotamento
“.jar”.
 <<EJB-JAR>>: Indica que o elemento é um arquivo de empacotamento “ejb-jar”.
 <<EJBDescriptor>>: Indica que o elemento é um arquivo de descrição (um
arquivo deployment descriptor).
 <<EJBClientJAR>>: Indica que o elemento é um arquivo de empacotamento “ejbclient-jar”.
Além destes estereótipos, o perfil EJB/UML sugere a adoção dos seguintes
valores marcados (tagged values):
 EJBSessionType: Aceita os valores Stateful ou Stateless. Valor marcado que
indica se um EJB Session Bean é um session stateful ou stateless.
 EJBTransType: Aceita os valores Bean ou Container. Indica se o método de
persistência de um EJB Session Bean é gerenciado pelo próprio EJB ou se é
gerenciado pelo contêiner.
 EJBPersistenceType: Aceita os valores Bean ou Container. Indica se o EJB
Entity Bean é um entity BMP (persistência gerenciada pelo próprio EJB) ou se é
um entity CMP (persistência gerenciada pelo contêiner).
41
Neste perfil EJB/UML, os EJBs não são representados com o símbolo de
componentes da UML, mas sim com o símbolo de subsistemas da UML.
Exemplos de modelagem de EJBs segundo a JSR-26:
Figura 12: Exemplo de modelagem externa de EJBs segundo a JSR-26.
42
Figura 13: Exemplo de Modelagem Interna de EJBs segundo a JSR-26.
Figura 14: Diagrama de Distribuição de EJBs segundo a JSR-26.
43
4.3. Proposta de AHMED
AHMED (1) apresenta uma proposta de mapeamento EJB/UML baseado na
proposta da Sun, a JSR-26. No entanto, esta proposta inclui mais alguns detalhes
ausentes na especificação JSR-26, como:
 A utilização de diagramas de robustez para a modelagem dos EJB segundo a
arquitetura MVC.
 A utilização do perfil de mapeamento UML/Web proposto por Jim Conallen.
 A aplicação dos estereótipos <<WebArchiveFile>> (representa um arquivo de
empacotamento .WAR), <<EnterpriseArchiveFile>> (representa um arquivo de
empacotamento .EAR),
<<ApplicationServer>>
<<WebServer>> (representa um navegador Web),
(representa
um
servidor
de
aplicações)
e
<<DataBaseServer>> (representa um servidor de banco de dados).
Esta é a proposta na qual se baseará este trabalho. Toda a descrição desta
proposta será demonstrada na prática com o desenvolvimento da aplicação de exemplo
sugerida por este autor.
44
5. MAPEAMENTO J2EE PARA UML
5.1. Servlets
Os Servlets podem ser representados através do estereótipo <<HTTPServlet>>.
Figura 15: Representação de um Servlet
5.1.1. Relacionamentos
Existem duas formas de se chamar um Servlet, através de um método POST ou
GET. Logo, quando uma página web, uma classe, um EJB ou outro servlet acessa um
servlet, essa representação pode ser expressa com o estereótipo <<POST>> ou
<<GET>>.
Figura 16: Relacionamentos de um Servlet
Quando são passadas variáveis para o servlet (seja argumentos na própria URL no caso de GETs - ou através de atributos setados na sessão, pode-se expressar estes
parâmetros através de uma nota:
45
Figura 17: Especificando parâmetros através de nota
Pode-se ainda especificar o tipo do atributo através dos seguintes estereótipos:
<<HTTPSessionVariable>> : Para atributos setados na sessão.
<<HTTPRequestVariable>> : Para atributos setados no Request.
<<URLVariable>> : Para variáveis setadas pela URL.
<<HTTPContextVariable>> : Para variáveis setadas no Contexto.
Exemplo:
Figura 18: Especificando os tipos de parâmetros
46
Em um diagrama de classes, se uma classe se relaciona com o Servlet através de
GETs e POSTs, pode-se utilizar uma ação genérica para representar esse
relacionamento através do estereótipo <<Submit>>.
Figura 19: Utilização do estereótipo <<Submit>> ao invés do <<POST>> e do
<<GET>>.
Após a sua execução, normalmente o Servlet redireciona para outro Servlet ou
para uma Página Web. Esse relacionamento é dado pelo estereótipo <<Forward>>.
Figura 20: Relacionamento entre dois Servlets através do estereótipo
<<Forward>>.
47
5.2. Páginas Web e JSPs
5.2.1. JSPs
Uma página JSP é denominada ServerPage. Um ServerPage tem um ícone
próprio de representação ou pode ser representado também pelo estereótipo
<<ServerPage>>.
Figura 21: À esquerda, o ícone de uma página JSP. À direita, a representação de
uma página JSP através do estereótipo <<ServerPage>>.
5.2.2. Páginas Web
Uma página Web é denominada ClientPage. Um ClientPage também tem um
ícone próprio de representação ou pode ser representado pelo estereótipo
<<ClientPage>>.
Figura 22: À esquerda, o ícone de uma página Web. À direita, a representação de
uma página Web através do estereótipo <<ClientPage>>.
48
5.2.3. Relacionamentos
Um ClientPage ou um ServerPage podem se comunicar com outras páginas. Esse
relacionamento é expresso através do estereótipo <<Link>>.
Figura 23: Relacionamentos entre ServerPages e ClientPages.
5.3. Struts
Uma página simples utilizando Struts é composta pela página JSP, por uma classe
ActionServlet, uma classe Form e uma classe Action.
5.3.1. Classe ActionServlet do Struts
O ActionServlet é na verdade um Servlet responsável pelo controle MVC do
Struts. O ActionServlet recebe uma requisição de uma página Web e repassa essa
requisição para o Form e para o Action. O ActionServlet pode ser representado através
do estereótipo <<StrutsActionServlet>>.
Figura 24: Representação do Action Servlet do Struts.
49
A chamada de uma página para um ActionServlet é representada através do
estereótipo <<submit>>.
Figura 25: Página Web chamando o ActionServlet do Struts.
5.3.2. Classe Form do Struts
A classe Form do Struts é utilizada para fazer a validação dos dados passados
pela página JSP. Esta classe pode ser representada através do estereótipo
<<StrutsForm>>.
Figura 26: Representação de uma classe Form do Struts.
A chamada de um Struts Form por um Struts Action Servlet é representada
através do estereótipo <<Forward>>.
50
Figura 27: Classe Form do Struts sendo chamada pelo ActionServlet do Struts.
5.3.3. Classe Action do Struts
A classe Action do Struts é utilizada para executar as ações esperadas a partir da
chamada da página JSP. É nesta classe Action que estará o código a ser executado.
Esta classe Action pode criar novos objetos, chamar um EJB, etc. Esta classe pode ser
representada com o estereótipo <<StrutsAction>>.
Figura 28: Representação da classe Action do Struts
A chamada de um Struts Action por um Struts ActionServlet é representada
também através do estereótipo <<Forward>>.
51
Figura 29: Uma classe Action do Struts sendo chamada pelo ActionServlet do
Struts.
5.4. EJBs
Tanto a proposta de AHMED (1) quanto a proposta da JSR-26 (7) utilizam
subsistemas de UML para representar EJBs. Esta parece ser realmente a melhor
alternativa para esta representação devido às limitações do símbolo de componentes
da UML conforme visto anteriormente.
Figura 30: Exemplo de representação um EJB utilizando o símbolo de
subsistemas da UML.
5.4.1. Interfaces
Um EJB deve ser mostrado juntamente com suas interfaces. Existem quatro tipos
de interfaces para um EJB: a interface Home Remota, a interface Remota, a interface
52
Home Local e a interface Local. Estas interfaces podem ser representadas através dos
seguintes estereótipos:
<<EJBRemoteHomeInterface>> : representa a interface Home Remota;
<<EJBRemoteInterface>> : representa a interface Remota;
<<EJBLocalHomeInterface>> : representa a interface Home Local;
<<EJBLocalInterface>> : representa a interface Local.
Figura 31: Representação de um EJB e alguma de suas interfaces
5.4.2. Session e Entity Beans
Esta proposta se concentra em dois tipos de EJB, os SessionBeans e os
EntityBeans.
5.4.3. SessionBeans
Os
SessionBeans
podem
ser
representados
<<EJBSessionBean>> no símbolo de subsistema.
através
do
estereótipo
53
Figura 32: Representação de um SessionBean
Externamente, os session beans podem ser representados da seguinte maneira:
Figura 33: Visualização externa de um SessionBean.
Internamente, os SessionBeans podem ser representados de uma maneira
semelhante à visualização mostrada acima. Porém, deve ser mostrada também a
classe de implementação do EJB. Esta classe é representada com o estereótipo
<<EJBImplementation>>.
54
Figura 34: Visualização interna de um SessionBean
Para a representação de um EJB, foram adotados os seguintes padrões de
nomes:
- Nome do EJB: [nome da classe] + EJB. Exemplo: ShoppingCartEJB
- Nome da interface Home Remota: [nome da classe] + Home. Exemplo:
ShoppingCartHome
- Nome da interface Remota: [nome da classe]. Exemplo: ShoppingCart
- Nome da interface Home Local: [nome da classe] + LocalHome. Exemplo:
ShoppingCartLocalHome
-
Nome
da
interface
Local:
[nome
da
classe]
+
Local.
Exemplo:
ShoppingCartLocal
- Nome da classe de implementação do EJB: [nome da classe] + Bean. Exemplo:
ShoppingCartBean
55
Um SessionBean pode ser um SessionBean Stateless ou Stateful. No caso, essa
informação pode ser representada através do valor marcado EJBSessionType.
{EJBSessionType = Stateful} : quando o Session é Stateful
{EJBSessionType = Stateless} : quando o Session é Stateless
5.4.4. EntityBeans
Os
EntityBeans
podem
ser
representados
através
do
estereótipo
<<EJBEntityBean>> no símbolo de subsistema.
Figura 35: Representação de um EntityBean.
Externamente, os session beans podem ser representados da seguinte maneira:
Figura 36: Representação externa de um EntityBean.
56
Internamente, os EntityBeans contém uma classe a mais que os SessionBeans.
Além da classe de implementação do Bean, os EntityBeans ainda podem ter uma
classe para definir a chave primária do EJB. Esta classe pode representada através do
estereótipo <<EJBPrimaryKey>>. Para esta classe também foi adotado um padrão de
nome:
- Nome da classe de chave primária: [nome da classe] + PK. Exemplo:
CustomerOrderPK.
Assim, internamente os EntityBeans podem ser representados da seguinte
maneira:
Figura 37: Representação interna de um EntityBean
Um EntityBean pode ter dois tipos de persistência, a persistência gerenciada pelo
bean, ou Bean Managed Persistence (BMP), ou persistência gerenciada pelo Contêiner,
ou Container Managed Persistence (CMP). Essa informação pode ser representada
através do valor marcado EJBPersistenceType.
57
{EJBPersistenceType = Bean} : quando o Entity tem persistência BMP
{EJBPersistenceType = Container} : quando o Entity tem persistência CMP.
5.4.5. Relacionamentos CMR
Quando um EntityBean é do tipo CMP, é possível fazer relacionamentos entre os
EntityBeans simulando os relacionamentos das tabelas do banco de dados que elas
representam. Este relacionamento é chamado de CMR (Container Managed
Relashionship). Estes relacionamentos podem ser expressos através de um diagrama
de classes, fazendo eles como se fosse a modelagem de dados de uma base de dados
relacional.
Figura 38: Exemplo de modelagem de relacionamentos CMR
5.4.6. EJBs e os diagramas de interação
A especificação JSR-26 (7) não traz nenhuma informação sobre como os EJBs
podem ser representados em um diagrama de interação. Já AHMED (1) apresenta a
seguinte proposta:
58
Figura 39: Exemplo de diagrama de interação segundo AHMED
A desvantagem desta proposta é que são necessários muitos objetos no diagrama
representando as interfaces. Além do que, segundo esta proposta, temos uma interface
(no caso a classe Control) que acessa outra interface. Na verdade é o EJB que acessa
a outra interface.
Por isso, sugere-se que em um diagrama de interação não seja mostrada as
interfaces do EJB, mas sim o próprio EJB. Para cada mensagem enviada deve mostrar
qual a interface utilizada segundo o padrão abaixo:
<<EJBRemoteInterface>> : representa uma mensagem enviada a um método da
interface Remota;
<<EJBLocalInterface>> : representa uma mensagem enviada a um método da
interface Local.
<<EJBRemoteCreateMethod>> : representa uma mensagem executando o
método create da interface Home Remota;
59
<<EJBLocalCreateMethod>> : representa uma mensagem executando o método
create da interface Home Local;
<<EJBRemoteFinderMethod>> : representa uma mensagem executando um
método Finder da interface Home Remota;
<<EJBLocalFinderMethod>> : representa uma mensagem executando um método
Finder da interface Home Local;
Figura 40: Exemplo de uma outra alternativa para a utilização de EJBs em
diagramas de seqüência.
5.5. WebServices
Quando se vai criar um WebService, geralmente são necessárias duas classes:
uma interface e uma classe de implementação do WebService. Nesse sentido, ele tem
um comportamento muito parecido com um EJB pois a classe de implementação do
WebService não mostra no código a realização da interface; esse relacionamento é
definido através de arquivos XML. Por isso, os WebServices também podem ser
representados como um subsistemas de UML. Um WebService pode ser representado
através do estereótipo <<WebService>>.
60
Figura 41: Exemplo de um WebService modelado como um subsistema da UML.
5.5.1. Interface
Um WebService sempre deve ser mostrado em um diagrama de classes com a
sua interface. A interface do WebService define quais os métodos que serão
disponibilizados no WebService, quais os parâmetros e o que retorna este método. A
interface
do
WebService
pode
ser
representada
através
do
estereótipo
<<WebServiceInterface>>.
Figura 42: Representação do WebService com sua interface.
5.5.2. Visão externa e interna do WebService
A figura acima mostra a visão externa de um WebService. Na visão interna, é
necessário mostrar a classe de implementação do WebService. A classe de
implementação do WebService pode ser representada através do estereótipo
<<WebServiceImplementation>>.
61
Figura 43: Representação da visão interna do WebService
5.5.3. Padrões de Nomes
Para representar um WebService, foi utilizado o seguinte padrão de nomes:
-
Nome
do
WebService:
[nome
do
WebService]
+
WS.
Exemplo:
StringProcessorWS
- Nome da Interface: [nome do Webservice]. Exemplo: StringProcessor
- Nome da Classe de Implementação: [nome do WebService] + Impl. Exemplo:
StringProcessorImpl
5.5.4. WebServices e os diagramas de interação
Em um diagrama de interação (da mesma forma que os EJBs), é mostrado
apenas o WebService sem as suas interfaces.
62
Em um cliente do WebService, é necessário primeiramente obter a referência do
WebService.
Esta
ação
pode
ser
representada
através
do
estereótipo
<<WebServiceCreate>>.
Figura 44: Representação da utilização de WebServices em diagramas de
interação.
63
BIBLIOGRAFIA
1.AHMED, Khawar Zaman. UMRYSH, Cary E. Desenvolvendo Aplicações
Comerciais em Java com J2EETM e UML. Rio de Janeiro: Editora Ciência
Moderna Ltda., 2002.
2.BODOFF, Stephanie. GREEN, Dale. &. Tutorial do J2EETM. Rio de Janeiro: Editora
Campus, 2002.
3.FRANK, Augusto Siqueira. INE 5612, Desenvolvimento de Sistemas Orientados a
Objetos II. Unidade I, Introdução à Tecnologia de Componentes. Florianópolis,
2002. <http://www.inf.ufsc.br/~frank>>
4.BOOCH, Grady. RUMBAUGH, James. JACOBSON, Ivar. UML, Guia do Usuário.
Rio de Janeiro: Editora Campus, 2000.
5.ROMAN, Ed. AMBLER, Scott. JEWELL, Tyler. Mastering Enterprise JavaBeansTM.
Second Edition. USA: The Middleware Company, 2002.
6.OMG. OMG Unified Modeling Language Specification. Versão 1.5. USA: OMG,
2003. <<http://www.omg.org/technology/documents/formal/uml.htm>>
7.GREENFIELD, Jack. UML Profile for EJB. USA: Rational Software Corporation,
2001. <<http://jcp.org/aboutJava/communityprocess/review/jsr026/>>