Implementaçao de Projetos Web Utilizando o Seam Framework

UNIVERSIDADE NORTE DO PARANÁ
SISTEMA DE ENSINO PRESENCIAL CONECTADO
ESPECIALIZAÇÃO EM DESENVOLVIMENTO DE APLICAÇÕES WEB
BASEADAS NA TECNOLOGIA JAVA
RICARDO RODRIGUES BARCELAR
IMPLEMENTAÇÃO DE PROJETOS WEB UTILIZANDO O SEAM FRAMEWORK
Cuiabá/MT
2013
RICARDO RODRIGUES BARCELAR
IMPLEMENTAÇÃO DE PROJETOS WEB UTILIZANDO O SEAM FRAMEWORK
Trabalho de Conclusão de Curso apresentado ao
curso de especialização em Desenvolvimento de
Aplicações Web Baseadas na Tecnologia Java da
Universidade Norte do Paraná, como requisito
parcial para obtenção do Título de Especialista.
Tutor Orientador: Higor Vinicius Navarro Fabricio
Cuiabá/MT
2013
RESUMO
Este trabalho faz uma abordagem teorico-prática sobre o Seam Framework com
foco no desenvolvimento de projetos web. O desenvolvimento web com Java EE
com seus inúmeros componentes exige um grande conhecimento acerca de sua
estrutura. A despeito de constituir uma plataforma seus componentes não são
coesos necessitando de muito trabalho de programação na camada de negócio. O
Seam surge neste cenário como uma solução ágil de coesão e traz em seu
framework um conjunto de ferramentas para simplificar o desenvolvimento. Diante
disso, objetiva-se neste trabalho realizar um estudo do JBoss Seam e constatar a
viabilidade de seu uso em projetos web. Para tanto, um estudo de caso acerca da
construção de uma aplicação web para uma associação de classe foi construído,
com vistas a comprovar sua viabilidade e compreender o uso de seus componentes.
Para subsidiar esta pesquisa diversas referências oficiais foram consultadas, bem
como autores com literaturas consagradas por sua qualidade e acertividade sobre o
tema. Por fim, após a revisão teórica e a implementação foi possível discutir o
emprego e a viabilidade acerca do uso do framework, chegando a uma conclusão
positiva sobre o emprego do JBoss Seam.
ABSTRACT
This paper makes a theoretical and practical approach about Seam Framework
focusing on the development of web projects. The web development with Java EE
with its numerous components requires a great knowledge of their structure. Despite
provide a platform their components are not very cohesive needing programming
work in the business layer. Seam arises in this scenario as an agile solution cohesion
and bring in your framework a set of tools to simplify development. Therefore, the
objective of this research was to conduct a study from JBoss Seam and to prove the
feasibility of its use in web projects. Therefore, a case study about building a web
application for an association class was built, in order to confirm your viability and
understand the use of their components. To support this research various official
references were consulted, as well as literature devoted to authors for their quality
and assertiveness about the topic. Finally, after reviewing theoretical and
implementation was possible to discuss the use and the feasibility about the use of
the framework, reaching a positive conclusion about use of JBoss Seam.
SUMÁRIO
1 INTRODUÇÃO ......................................................................................................... 7
1.1 Justificativa ...................................................................................................... 8
1.2 Objetivo Geral................................................................................................... 9
1.3 Objetivos Específicos ...................................................................................... 9
2 PLATAFORMA JAVA ENTERPRISE EDITION – JAVA EE ................................. 10
2.1 Arquitetura Java EE ....................................................................................... 11
2.2 Componentes e Conteineres ........................................................................ 12
2.3 APIs da plataforma......................................................................................... 14
2.4 Tecnologias Requeridas pela Plataforma Java EE ..................................... 16
2.4.1 ENTERPRISE JAVABEANS (EJB) ........................................................... 16
2.4.2 JAVA SERVLET ........................................................................................ 17
2.4.3 JAVASERVER FACES - JSF .................................................................... 17
2.4.4 JAVASERVER PAGES - JSP.................................................................... 22
2.4.5 JAVASERVER PAGES STANDARD TAG LIBRARY - JSTL .................... 22
2.4.6 JAVA PERSISTENCE - JPA ..................................................................... 22
2.4.7 JAVA TRANSACTION - JTA ..................................................................... 23
2.4.8 JAVA API FOR RESTFUL WEB SERVICES - REST................................ 24
2.4.9 MANAGED BEANS ................................................................................... 24
2.4.10 CONTEXTS AND DEPENDENCY INJECTION FOR THE JAVA EE
PLATFORM (JSR 299) - CDI ............................................................................. 24
2.4.11 BEAN VALIDATION ................................................................................ 25
2.4.12 JAVA MESSAGE SERVICE - JMS.......................................................... 25
2.4.13 JAVA EE CONNECTOR ARCHITECTURE - JCA .................................. 25
2.4.14 JAVAMAIL ............................................................................................... 25
2.4.15 JAVA AUTHORIZATION CONTRACT FOR CONTAINERS - JACC ...... 26
2.4.16 JAVA AUTHENTICATION SERVICE PROVIDER INTERFACE FOR
CONTAINERS - JASPIC .................................................................................... 26
2.5 Serviços Padrão do Java EE ......................................................................... 26
3 SEAM FRAMEWORK ............................................................................................ 28
3.1 Integração entre o JBoss Seam e o Java EE............................................... 28
3.2 Modelo de Componentes .............................................................................. 29
3.3 Bijeção ............................................................................................................ 30
3.4 Contexto de Componentes ........................................................................... 31
3.5 Eventos Seam................................................................................................. 32
3.6 Seam Data Validation..................................................................................... 33
3.7 Página de Navegação .................................................................................... 35
3.7.1 ELEMENTOS DE NAVEGAÇÃO............................................................... 35
3.8 Biblioteca de Tags do JBoss Seam.............................................................. 37
3.8.1 TAGS DE NAVEGAÇÃO ........................................................................... 37
3.8.2 TAGS DE SELEÇÃO ................................................................................. 38
3.8.3 TAGS DE FORMATAÇÃO ........................................................................ 39
3.9 RichFaces ....................................................................................................... 40
3.9.1 BIBLIOTECA DE TAGS DOS COMPONENTES RICHFACES ................. 40
3.9.2 TEMAS RICHFACES ................................................................................ 42
4 METODOLOGIA..................................................................................................... 44
4.1 Cenário ............................................................................................................ 44
4.2 Descrição da Proposta .................................................................................. 44
5 ESTUDO DE CASO: PROJETO JBOSS SEAM ................................................... 46
5.1 Ferramentas (Tecnologia) ............................................................................. 46
5.1.1 SERVIDOR DE APLICAÇÃO JBOSS AS.................................................. 46
5.1.2 SEAM FRAMEWORK................................................................................ 47
5.1.3 SISTEMA GERENCIADOR DE BANCO DE DADOS POSTGRESQL...... 48
5.1.4 ECLIPSE IDE ............................................................................................ 48
5.1.5 IREPORTS E JASPERREPORTS ............................................................ 49
5.2 Levantamento de Requisitos ........................................................................ 50
5.3 Modelagem do Sistema ................................................................................. 51
5.3.1 DIAGRAMA DE CASO DE USO ............................................................... 51
5.3.2 DIAGRAMA DE CLASSE .......................................................................... 51
5.4 Implementação ............................................................................................... 52
5.5 Avaliação e discussão ................................................................................... 60
6 CONCLUSÃO......................................................................................................... 61
7 REFERÊNCIAS BIBLIOGRÁFICAS ...................................................................... 63
7
1 INTRODUÇÃO
Contemporaneamente os sistemas computacionais são requisitos de sucesso
para as empresas, corporações, órgãos públicos, etc, sejam empreendimentos de
pequeno ou grande porte. Em situações cujos processos são complexos torna-se,
então, imperativo a utilização de uma aplicação que envolva o armazenamento e
processamento dos dados.
Ocorre que ao longo dos anos o modelo de desenvolvimento destes sistemas
mudou caminhando na direção da descentralização. Os primeiros sistemas, que ora
tinham seu processamento e armazenamento centralizado em um grande
computador saiu de um modelo monolítico, evoluiu para um modelo cliente-servidor
e chega aos dias atuais com uma proposta de modelo multicamadas com acessos
diversificados através da internet por meio de navegadores web e dispositivos
móveis.
É neste cenário que o desenvolvimento web se desponta como uma solução
atrativa permitindo, inclusive, o acesso descentralizado das informações
corporativas.
O desenvolvimento web normalmente está associado a programação e
marcação, configuração e trabalho realizado na retaguarda dos sítios, mas também
pode ser usado para se referir ao projeto visual das páginas e ao desenvolvimento
de um comércio eletrônico.
Em virtude deste cenário surgiram muitas ferramentas com o intuito de
facilitar a tarefa do programador em criar desde simples sites de internet até
verdadeiras soluções de gerenciamento com considerável volume de dados.
Considerando a plataforma Java, o desenvolviento de aplicações neste
cenário tornou-se viável com o nascimento da tecnologia J2EE (Java2 Platform
Enterprise Edition) na qual é possível projetar, desenvolver, empacotar e implantar
aplicações empresariais baseadas em compontentes. Desde então, soluções foram
desenvolvidas visando atender o desenvolvimento distribuído.
O JBoss Seam foi um dos frameworks criado a partir da especificação do
J2EE. Esta solução também é conhecida como Seam Framework, foco deste
trabalho. De acordo FARLEY (2008), o JBoss Seam é um framework que tem como
objetivo otimizar o desenvolvimento de aplicações Java Enterprise Edition (JEE).
Desde seu lançamento observa-se uma grande evolução. Atualmente sua versão
estável é a 2.3.0.Final - considerando sua proposta original. Graças a sua
estabilidade e a forma integradora pela qual foi projetado tem sido massiva sua
adoção em novos projetos e migração de sistemas legados.
Partindo desta breve contextualização, este trabalho se propõe a realizar um
estudo a partir de uma abordagem teórico-prática acerca do Seam Framework. Além
de tratar dos aspectos relativos a plataforma Java Enterprise Edition, que é o cerne
do framework, serão abordadas outras soluções com a qual o Seam interage. Com o
intuito de demonstrar sua aplicabilidade e deixar claro suas interações, neste
trabalho será apresentado um sistema desenvolvido utilizando a versão mais
recente deste framework.
Para tanto, além desta introdução e de uma breve justificativa da realização
do trabalho, serão abordados em capítulos pontos que são importantes para a
8
perfeita compreensão do Seam Framework, a saber: Um breve estudo sobre a
plataforma plataforma Java Enterprise Edition, um capítulo dedicado ao estudo do
JBoss Seam e, por fim, um estudo de caso com o JBoss Seam, onde será
apresentado um Sistema desenvolvido com a última versão desta ferramenta
rodando em um conteiner web.
1.1 Justificativa
Nas últimas cinco décadas o desenvolvimento de software sofreu inúmeras
mudanças, desde a manutenção do código público ao código proprietário, escrita de
códigos básicos até a utilização de poderosas plataformas de desenvolvimento.
Com a evolução dessas plataformas de desenvolvimento os programadores
passaram a ter disponível um arcabouço muito vasto de ferramentas para a
construção de suas aplicações. Dentre elas, é possível citar desde plataformas
completas para desenvolvimento e execução de sistemas e aplicações como o .NET
Framework da Microsoft a soluções mais simplistas como o PHP.
A plataforma Java, muito utilizada no desenvolvimento de software pela sua
flexibilidade, segurança e versatilidade, por si só já dispõe de uma gama de
soluções para desenvolviemento de programas – desktop, soluções distribuídas e
sistemas embarcados que de igual forma é bastante atrativa.
Com tantas possibilidades, o profissional deve optar por aquela ferramenta
que, de acordo com os requisitos do sistema, disponibilidade de recursos e outras
variáveis que devem ser analisadas, melhor lhe aprouver para o caso. Esta decisão
pode tornar-se em um grande problema, visto que deve ser considerado muitos
aspectos: desde o financeito até a questão de qualificação do corpo técnico.
Diante dessa conjuntura este trabalho apresenta o JBoss Seam, como uma
solução baseada na plataforma Java Enterprise Edition que tem sido amplamente
divulgada e utilizada nos mais diferentes cenários. Dentre eles o Governo de Mato
Grosso através da Secretária de Segurança Pública e da Polícia Judiciária Civil, o
Governo de São Paulo e o Governo do Ceará no segmento governamental, a Caixa
Econômica Federal no segmento bancário, sem dizer das inúmeras fábricas de
software privadas que comercializam seus produtos construidos a partir deste
framework. Basta uma breve pesquisa na Internet para encontrar centenas de
soluções web contruidas com JBoss Seam, cuja identificação primária pode ser feita
pela extensão das URL’s terminadas em “.seam.”
Abordar este tema, que apesar de não ser inédito nem novo, proverá
conhecimentos práticos sobre a aplicabilidade do Seam Framework no
desenvolvimento de soluções web, visto que hoje o mercado tende para que as
aplicações sejam acessadas de qualquer lugar e por qualquer tipo de dispositivo
senão o computador pessoal ou notebook. Para isso, uma abordagem teórica é
imprescindível para localizar teoricamente o tema e apresentar as tecnologias
envolvidas. Além do quê, é a teoria que fornece o embasamento necessário para
compreender o funcionamento de cada parte da proposta prática. Esta vem com o
cunho de demonstrar como os componentes se relacionam, podem e devem ser
utilizados, visto que o Seam Framework agrega outro frameworks bastante comuns
9
no mercado que com ele podem ser melhor trabalhados permitindo um enfoque
maior no negócio do que na programação de mais baixo nível.
Conhecer o Seam Framework na teoria e na prática, permite ao analista de
tecnologia da informação ou ao programador decidir se esta é a ferramenta
adequada para seu problema ou mesmo tomá-lo como solução para
desenvolvimento de suas aplicações.
No âmbito acadêmico, o estudo do JBoss Seam permitirá uma revisão dos
conceitos da programação para web com vistas ao uso de frameworks, preocupação
voltada para ao negócio com o devido respeito ao padrões de projetos, bem como
um aprofundamento no conhecimento das técnicas de programação.
1.2 Objetivo Geral
Apresentar o Seam Framework como solução para o desenvolvimento de
projetos para web.
Verificar a viabilidade de seu uso no desenvolvimento de projetos web.
1.3 Objetivos Específicos
- Realizar uma revisão teórica sobre a plataforma de desenvolvimento web
Java.
- Apresentar os frameworks e componentes que se relacionam com o Seam
Framework.
- Implementar uma aplicação utilizando o Seam Framework a título de estudo
de caso.
10
2 PLATAFORMA JAVA ENTERPRISE EDITION – JAVA EE
Java é uma linguagem de programação, criada pela Sun Microsystems Inc,
voltada para o desenvolvimento de aplicações que funcionem sobre uma máquina
virtual e não seja dependente do tipo de sistema operacional, seja Windows, Linux,
Unix, Solaris ou Mac, assim como em dispositivos móveis como telefones celulares,
PDA’s e mainframes. Devido a essa versatilidade, a linguagem Java conta com três
conhecidos ambientes de desenvolvimento:
- Java SE (Java Standard Edition), que é a plataforma utilizada em Servidores
e PC’s;
- Java EE (Java Enterprise Edition) voltado para redes, internet e intranets –
que será nosso alvo de estudo neste capítulo; e
- Java ME (Java Micro Edition) que é plataforma de aplicações para
dispositivos móveis como PDA’s e celulares.
O Java EE é a plataforma Java voltada para redes, internet, intranets e
semelhantes. Sendo assim, PRADO(2013) explica que ela contém bibliotecas
especialmente desenvolvidas para o acesso a servidores, a sistemas de e-mail, a
banco de dados, entre outras características. Graças a essas características o Java
EE foi desenvolvido para suportar uma grande quantidade de usuários simultâneos.
Historicamente, o Java EE surgiu da necessidade de criar aplicações
multicamadas. Nos anos 90, o SQL se firmou como linguagem padrão para acesso a
bancos de dados relacionais permitindo que os sistemas pudessem ser divididos em
três camadas: cliente, servidor e banco de dados. Simultaneamente, o paradigma da
programação estruturada evoluiu para a programação orientada a objetos. Com isso,
a camada de dados se tornou mais independente da camada que trata da aplicação
em si. Como uma evolução natural, era necessário que o desenvolvimento se
dividisse ainda mais, de modo a desmembrar as camadas em componentes
especializados.
Da tendência corrente no final da década de 90 que resultava no
desenvolvimento de programas corporativos que fornecessem estruturas
multicamadas destinadas a distribuição de aplicativos seguros, flexíveis e
disponíveis, a Sun lançou o Java 2 Platform, Enterprise Edition ou J2EE, como era
conhecida inicialmente, até ter seu nome trocado para Java EE na versão 5.0.
Posteriormente, foi chamada de Java EE 5. A versão atual é chamada de Java EE 7.
A partir do Java EE, a Sun possibilitou o desenvolvimento de aplicações Java
com várias camadas, separando camadas de apresentação, negócio e dados. A
tecnologia passou a dar suporte a recursos de conexão de banco de dados
compartilhado, componentes para publicação de dados dinânicos na WEB (JSP,
Servlet), componentes de negócio e persistência (EJB), entre outros.
Na figura a seguir é possível acompanhar toda a evolução do Java EE até
sua versão atual:
11
Figura 1 - Evolução do Java EE
Fonte: http://marseille.labo-java.net/2013/02/18/a-la-decouverte-de-java-ee-7/
2.1 Arquitetura Java EE
Segundo Gupta(2012), na arquitetura Java EE os diferentes componentes
trabalham juntos para fornecer um sistema integrado como mostrado na figura
abaixo:
Figura 2 - Arquitetura Java EE 6
Fonte: Gupta(2012)
Ainda que a versão Java EE 7 já tenha sido lançada e seja a versão corrente
da plataforma, neste trabalho será abordada a versão Java EE 6, haja vista ser o
padrão ainda mais comumente utilizado pela grande maioria dos desenvolvedores e
ser a plataforma utilizada no estudo de caso.
Como se vê na figura 2, cada componente tem uma função especifica, a
saber:
- Os componentes JPA(Java Persistence API), JTA(Java Transaction API) e
JMS(Java Message Service) são responsáveis por fornecer os serviços básicos
como banco de dados acesso, transações e mensagens.
12
- Managed Beans e o EJB (Enterprise Java Beans) proporcionam uma
programação simplificada da camada de modelo usando POJO’s.
- CDI(Contexts and Dependency Injection), interceptors e Common
Annotations fornecem conceitos que são aplicáveis a uma ampla variedade de
componentes, tais como injeção de dependência, interceptors e um conjunto de
common Annotations.
- CDI Extensions permitem estender a plataforma além suas capacidades
existentes de uma forma padrão.
- Web Services usando JAX-RS e JAX-WS, JSF (JavaServer Faces),
JSP(Java Server Pages) e EL(Expression Language) definem o modelo de
programação para serviços web. Permite o registro automático de serviços web de
terceiros de uma forma muito natural.
- Bean Validation provê um padrão na declaração de restrições e validação
através de diferentes tecnologias.
Uma das grandes características do Java EE 6 é o uso constante das
anotações com o intuito de eliminar os arquivos XML com o intuito de aumentar a
produtividade.
2.2 Componentes e Conteineres
Segundo OLIVEIRA(2013), o foco da plataforma é simplificar o
desenvolvimento de soluções no âmbito corporativo através de padrões, serviços e,
principalmente, componentes modulares. Estes componentes, unidades de software
em nível de aplicação com suporte a um conteiner, são configuráveis durante o
desenvolvimento e incorporam um modelo de programação de acordo com o
"contrato de componente" com seu conteiner. Isto é, um conteiner, oferece serviços
de gerenciamento de ciclo de vida, segurança, distribuição e runtime para seus
componentes.
É justamente neste ponto que o Java EE difere-se da Plataforma Java
Standard Edition (Java SE), pela adição de bibliotecas que fornecem funcionalidade
para implementar software Java distribuído, tolerante a falhas e multicamada,
baseada amplamente em componentes modulares executando em um servidor de
aplicações.
Normalmente, as aplicações de vários níveis são difíceis de escrever, porque
envolvem muitas linhas de código para lidar com transações e gerenciamento de
estado, multithreading, pool de recursos, e outros detalhes complexos de baixo
nível.
A arquitetura baseada em componentes é independente de plataforma e torna
as aplicações Java EE faceis de escrever, visto que a lógica de negócio está
organizada em componentes reutilizáveis.
Um componente é uma unidade de software funcional independente que é
montado em um aplicativo Java EE com suas classes e arquivos relacionados e que
se comunica com outros componentes. A especificação define os seguintes
componentes Java EE:
13
- Aplicativos clientes e applets: componentes que são executados no cliente.
- Java Servlet, JavaServer Faces e JavaServer Pages (JSP): componentes
web que rodam no servidor.
- EJB(Enterprise JavaBeans) ou Enterprise Beans são componentes de
negócios que são executados no servidor.
A figura 3 ilustra bem a interação desses componentes dividindo-os em
camadas:
Figura 3 - Interação entre os componentes Java EE
Fonte: http://docs.oracle.com/javaee/6/tutorial/doc/bnaay.html#bnabj
Os componentes Java EE são escritos na linguagem de programação Java e
são compiladas da mesma forma como qualquer programa na linguagem. As
diferenças entre os componentes do Java EE e classes Java "padrão" é que os
componentes são montados em uma aplicação Java EE, eles são verificados para
serem bem formados e se estiverem em conformidade com a especificação Java EE
são implantados em produção, onde são executados e gerenciados pelo servidor
Java EE. (Conteiner) (ORACLE, 2013)
O servidor Java EE ou conteiner é uma interface entre um componente e a
plataforma de baixo nível com a funcionalidade que suporta o componente. Antes de
ser executado, um Enterprise Bean, ou qualquer componente do aplicativo deve ser
montado e implantado em um conteiner(deploy).
Existem vários tipos de conteiners:
- Conteiner Web: responsável pela hospedagem de páginas JSP e JSF,
servlets e javaBeans.
- Conteiner EJB: responsável por gerenciar a execução dos Enterprise
JavaBeans.
14
- Servidor Java EE: fornece conteiner Web e EJB
A figura abaixo ilustra a relação entre os conteiners Java EE.
Figure 4 - Relação entre Conteiner Java EE
Fonte: http://docs.oracle.com/javaee/6/tutorial/doc/bnaay.html#bnabj
Um conteiner também gerencia serviços não configuráveis, como o Enterprise
Bean, ciclos de vida do servlet, conexão de banco de dados, pooling de recursos,
persistência de dados, etc.
2.3 APIs da plataforma
Uma das características do Java EE é que a especificação fornece uma uma
grande quantidade de API’s. Esta também é uma das principais críticas, visto que a
maioria delas é de pequeno alcance para aplicações Java web. Uma aplicação
pequena ou média não utiliza a pilha completa Java EE. (RAHMAM, 2009).
Nesta versão (Java EE 6) apesar de existir 28 especificações, existe o profile
(perfil), na qual é possível configurar os recursos que serão utilizados na aplicação e
deixando a mesma mais leve.
As figuras abaixo informam as API’s disponíveis em cada perfil:
Figura 5 – API’s no Conteiner da Aplicação Cliente
Fonte: http://docs.oracle.com/javaee/6/tutorial/doc/bnaay.html#bnabj
15
!
Figura 6 - API's no Container EJB
Fonte: http://docs.oracle.com/javaee/6/tutorial/doc/bnaay.html#bnabj
Figura 7 – API’s no Conteiner Web
Fonte: http://docs.oracle.com/javaee/6/tutorial/doc/bnaay.html#bnabj
16
2.4 Tecnologias Requeridas pela Plataforma Java EE
De acordo com a especificação do Java EE contida no site da Oracle, a
plataforma oferece ao desenvolvedor algumas facilidades, que na realidade são
tecnologias requeridas pela plataforma que constituem um conjunto de API’s usadas
em aplicações Java EE.
2.4.1 ENTERPRISE JAVABEANS (EJB)
EJB ou Enterprise JavaBeans é um dos principais componentes da
plataforma. É um componente do tipo servidor que executa no conteiner do servidor
de aplicação. Os principais objetivos da tecnologia EJB são fornecer um rápido e
simplificado desenvolvimento de aplicações Java baseado em componentes
distribuídos, transacionais, seguros e portáveis.
O componente EJB possui 3 (três) tipos fundamentais:
- Entity beans;
- Session Beans; e
- Message Driven Beans;
Os Entity Beans representam objetos que vão persistir numa base de dados
ou outra unidade de armazenamento. Também controlam a persistência de dados,
definindo o padrão para:
- Criação de metadados, mapeamento de entidades para tabelas do modelo
relacional;
- API EntityManager, API para realização de CRUD (create, retrieve, update e
delete);
- Java Persistence Query Language (JPQL), linguagem semelhante ao SQL
ANSI para pesquisa de dados persistidos;
Os Entity Beans não necessitam de um conteiner EJB para serem
executados.
Os Session Beans executam algumas tarefas para o cliente e podem manter
o estado durante uma sessão com o cliente. Os Session Beans que mantém o
estado são do tipo Statefull, ao passo que os que não possuem esta capacidade são
do tipo Stateless.
Os Message Driven Beans processam mensagens de modo assíncrono entre
os EJB’s cuja API de mensagens é Java Message Service (JMS). Necessitam de um
EJB conteiner para serem executados.
A partir da versão 3.1 o uso do Enterprise Java Beans simplificou o
desenvolvimento. O uso de anotações (XML opcional) e POJOs/POJIs são as
características marcantes. É possível criar interfaces opcionais, ou seja, somente as
cria se realmente for necessáio. O fragmento de código abaixo mostra um exemplo
de session local.
17
@Stateless
public class PessoaDao(){
public void salvar(Pessoa pessoa){
//...
}
}
Em versões anteriores, os EJB’s só poderia existir em deployments no
formato EAR. Agora é possível empacotá-los no formato WAR. No EJB 3.1 também
há o suporte a serviços assíncronos com o uso da anotação @Asynchronous.
(SANTANA, 2013).
2.4.2 JAVA SERVLET
Tecnologia Java Servlet permite definir classes de servlet HTTP específicos.
A classe Servlet estende as capacidades dos servidores que hospedam aplicativos
acessados por meio de um modelo de programação de solicitação-resposta. Apesar
de servlets poderem responder a qualquer tipo de pedido, eles são comumente
usados para estender os aplicativos hospedados por servidores web.
Na plataforma Java EE 6, os recursos da tecnologia Java Servlet incluem o
seguinte:
- Suporte a anotações;
- Suporte nativo às chamadas assíncronas;
- Facilidade de configuração;
- Melhorias para API’s existentes.
No fragmento de código abaixo podemos observar o uso de anotações na
criação do Servlet, sem necessidade de alterações no arquivo web.xml:
@WebServlet(name=”Pedido”, urlPatterns={“/Pedido”})
public class Pedido extends HttpServlet {
//...
}
2.4.3 JAVASERVER FACES - JSF
JavaServer Faces é um framework de interface de usuário para a construção
de aplicações web utilizando componentes. Conecta esses componentes a objetos
de negócio e automatiza o processo no uso de JavaBeans e navegação de páginas.
O JavaServer Faces ganhou expressão na versão 1.1 evidenciando
maturidade e segurança. Atualmente, é considerado pela comunidade Java como a
última palavra em termos de desenvolvimento de aplicações Web utilizando Java,
resultado da experiência e maturidade adquiridas com o JSP/Servlet (Model1),
Model2 (MVC).
18
O JSF é fortemente baseado nos padrões MVC(Model - View - Controler) e
Front Controller.
Conforme material instrucional da empresa de treinamentos K19, o MVC
confere ao JSF a característica de isolar a lógica de negócio da lógica de
apresentação dividindo a aplicação nos três tipos de componentes da arquitetura:
modelo, visão e controlador.
O modelo encapsula os dados e as funcionalidades da aplicação; a visão é
responsável pela exibição de informações, cujos dados são obtidos do modelo;
enquanto o controlador recebe as requisições do usuário e aciona o modelo e/ou a
visão.
Pelo padrão Front Controller, todas as requisições do usuário são recebidas
pelo mesmo componente, neste caso um Servlet. Dessa forma, tarefas que devem
ser realizadas em todas as requisições podem ser implementadas por esse
componente. Isso evita a repetição de código e facilita a manutenção do sistema.
PITANGA(2013) explica que no JSF, o controle é composto por um servlet
denominado FacesServlet, por arquivos de configuração e por um conjunto de
manipuladores de ações e observadores de eventos. O FacesServlet é responsável
por receber requisições da WEB, redirecioná-las para o modelo e então remeter uma
resposta. Os arquivos de configuração são responsáveis por realizar associações e
mapeamentos de ações e pela definição de regras de navegação. Os manipuladores
de eventos são responsáveis por receber os dados vindos da camada de
visualização, acessar o modelo, e então devolver o resultado para o FacesServlet.
O modelo representa os objetos de negócio e executa uma lógica de negócio
ao receber os dados vindos da camada de visualização. Finalmente, a visualização
é composta por component trees (hierarquia de componentes UI), tornando possível
unir um componente ao outro para formar interfaces mais complexas. A figura a
seguir mostra a arquitetura do JavaServer Faces baseada no modelo MVC.
Figura 8 - Arquitetura JSF baseada no Modelo MVC
Fonte: http://www.guj.com.br/content/articles/jsf/jsf.pdf
19
Segundo GEARY e HORSTMANN(2007), os JavaServer Faces possui as
seguintes partes:
- Um conjunto de componentes pré-fabricados de interface de usuário;
- Um modelo de programação orientado a eventos;
- Um modelo de componentes que permite a desenvolvedores independentes
fornecerem componentes adicionais.
Alguns componentes são simples como campos input e botões, enquanto
outros são bastante sofisticados como tabela de dados e árvores. Neste sentido,
existem várias implementações do JavaServer Faces, dentre elas a Sun Mojarra,
MyFaces, e outras. É possível ainda utilizar bibliotecas de componentes como
PrimeFaces, RichFaces, ICEFaces e outras.
O JSF possui todos os códigos necessários para manipular eventos e
organizar componentes. Dessa forma, os programadores podem ignorar tais
detalhes e empenharem-se na lógica de programação.
Por integrar o padrão Java EE, suas bibliotecas estão incluídas nos
servidores de aplicação Java EE e pode ser facilmente adicionado a um conteiner
web autonomo, como o Tomcat, por exemplo.
Um subprojeto, também mantido pela Sun, e integrado ao JSF é o Facelets,
cujas principais características são:
- Permite integração com todas as versões do JSF;
- Facilidade na criação de templates;
- O atributo “jsfc” que permite incluir trechos de código JSF nas tags HTML;
- Elimina o "JSP Compiler to Servlet" incrementando de 30% a 50% a
performance do sistema;
- Facilidade para criar componentes reutilizáveis;
- Usa XHTML como tecnologia de view do JSF;
- Precisão para reportar erros.
A tecnologia Facelets, disponível como parte do JavaServer Faces 2.0,
passou a ser a tecnologia de apresentação padrão para a construção de aplicações
web baseadas em JSF.
A partir da Versão 2.0 do JSF, houveram muitas melhorias, porém uma que
se destaca é a inserão do AJAX de forma nativa, visto que nas versões anteriores é
necessário recorrer a frameworks de terceiros como RichFaces, PrimeFaces, etc.
Parte importante do JSF é o controle de escopo (contexto). Na execução de
aplicações web são três os escopos: Application, Session, Request. A partir do JSF
2, além dos três escopos já mencionados, foi incorporado um quarto escopo
denominado ViewScoped.
No ApplicationScoped todos os objetos e atributos vinculados ao
managedBean poderão ser vistos por toda a aplicação da mesma forma. No
SessionScoped todos os objetos e atributos vinculados ao managedBean poderão
ser vistos por um único usuário enquanto durar sua sessão. No RequestScoped os
dados são válidos apenas durante a comunicação entre o cliente (browser) e o
servidor. O viewScope, adicionado a partir da versão 2 do JSF, foi criado para
resolver o problema de sempre utilizar session quando era necessário manter os
20
dados entre requisições, que não onerasse tanto a aplicação e oferece suporte ao
modelo statefull do framework, onde é possível manter os dados durante quantas
requisições forem necessárias, desde que todas estas sejam realizadas para a
mesma view. (PACHECO, 2013)
Um dos fundamentos de maior relevância do JSF é seu ciclo de vida que se
dá entre a requisição e a resposta do servidor de aplicação. Este ciclo está
respresentado na figura abaixo:
Figura 9 - Ciclo de vida do JSF
Fonte: http://imasters.com.br/linguagens/java/conheca-o-ciclo-fe-vida-do-jsf/
Segundo VINICIUS(2013), são vários os motivos da existência deste ciclo,
dentre estes:
- Manter o controle de estado dos componentes de interface;
- Alinhar ouvintes de eventos com seus respectivos eventos;
- Controle de navegação entre páginas, que deve ser realizado pelo servidor;
- Permitir que validações e conversões sejam realizadas no lado do servidor.
Para elucidar a figura 9 é convém descrever o que acontece em cada fase:
- Fase 1: Restore View (Restauração da visão): A partir de uma requisição
proveniente do servlet FacesServlet, é identificado qual visão está sendo requisitada
por meio do identificador desta que é determinado pelo nome da página. Tendo
identificado a página, esta é salva no FacesContext (caso ainda não tenha sido) e
sua respectiva árvore de componentes é construída.
- Fase 2: Apply Request Values (Aplicar valores da requisição): Cada
componente da visão, criado ou recuperado, passa a ter o seu valor. Nesse
contexto, existem algumas diferenças ocasionadas pelo valor do atributo
“immediate” em cada componente.
- Fase 3: Process Validation (Processar as validações): Esta é a primeira
manipulação de eventos do ciclo, aqui serão executadas as validações definidas
pelo servidor em cada componente. Não existindo valores inválidos, o ciclo segue
21
para a Fase 4. Existindo, uma mensagem de erro será gerada (adicionada ao
contexto do Faces, FacesContext) e o componente é marcado como inválido. Neste
caso, o ciclo segue para a Fase 6 (Renderizar a resposta).
- Fase 4: Update Model Values (Atualizar valores de modelo): Os valores
enviados pela requisição e validados pela fase 3, são atualizados em seus
respectivos atributos contidos nos backings beans, onde somente as propriedades
enviadas são atualizadas. É importante dizer que, mesmo após a fase de validação,
fase 3, os valores enviados podem estar inválidos a nível de negócio ou a nível de
conversão de tipos, o que pode ser verificado pelo próprio bean.
- Fase 5: Invoke Application (Invocar aplicação): Nesta fase, os valores dos
componentes da requisição, estão validados convertidos e disponíveis nos backings
beans. Assim a aplicação tem os insumos necessários para aplicar a lógica de
negócio.
- Fase 6: Render Response (Renderizar a resposta): O processo ‘Renderizar
a resposta’ consiste na apresentação da página referente ao resultado da aplicação
ao usuário. Neste contexto existem três possibilidades: Caso seja a primeira
requisição da página, os componentes associados são criados e vinculados a visão;
Se for a primeira submissão, os componentes são traduzidos para o HTML; ou caso
tenha ocorrido algum erro: Existindo os marcadores <f:message /> ou <f:messages
/> na página, os erros são exibidos ao usuário.
A especificação do JavaServer Faces que compõe a plataforma Java EE é
extremamente ampla. Neste tópico foram destacadas aquelas julgadas como as
principais características do JavaServer Faces considerando suas versões a partir
do JSF 1.2. Tudo isso não esgota o assunto que é vasto e cheio de nuâncias. O
conteúdo poderia abordar outros componentes de igual importância da tecnologia,
porém estes serão apenas citados, ficando para outra oportunidade o detalhamento
de cada um:
- Validação de entrada;
- Manipulação de Eventos;
- Conversão de dados entre objetos do modelo e os componentes JSF;
- Gerenciamento na criação de objetos do modelo;
- Configuração da navegação entre páginas;
- Uso de Expression Language (EL);
Todas estas funcionalidades estão disponíveis usando API’s Java padrão e
arquivos de configuração baseados em XML. Nas versões mais recentes do Java
EE estão disponíveis outros recursos como:
- A capacidade de utilizar anotações em vez de um arquivo de configuração
para especificar beans gerenciados e outros componentes;
- Facelets, uma tecnologia de imagem que substitui JavaServer Pages (JSP)
usando arquivos XHTML;
- Apoio Ajax;
- Componentes compostos;
- Navegação implícita.
22
2.4.4 JAVASERVER PAGES - JSP
A tecnologia JavaServer Pages (JSP) permite acrescentar trechos de código
servlet diretamente em um documento baseado em texto. A página JSP é um
documento baseado em texto que contém dois tipos de texto:
- Os dados estáticos, que podem ser expressas em qualquer formato
baseado em texto, como HTML ou XML;
- Elementos JSP, que determinam como a página constrói o conteúdo
dinâmico.
Assim permite que código Java e certas ações pré-definidas sejam
intercaladas com conteúdo de marcação estático, resultando na página sendo
compilada e executada no servidor para ser entregue num documento HTML ou
XML. As páginas compiladas e qualquer dependência de biblioteca Java usa os
bytecodes primeiro que o formato nativo de software, e deve assim ser executado
com uma JVM, a máquina virtual Java, integrada com o host do sistema operacional
para prover um ambiente de abstração de plataforma.
A sintaxe de JSP é uma mistura de dois tipos básicos de conteúdo: scriptlet
elements e markup. Markup é tipicamente um padrão HTML ou XML, enquanto os
elementos scriptlet são blocos de código Java os quais podem ser unidos com o tipo
de marcação, markup. Quando a página é requisitada o código Java é executado e
sua saída é adicionada, in loco, com o ambiente de marcação para gerar a página
final.
Ocorre que com o advento do JavaServer Faces a tecnologia tem caído em
desuso, contudo mantém seu nicho para aplicações mais simples.
A plataforma Java EE 6 requer JavaServer Pages 2.2 para compatibilidade
com versões anteriores, mas recomenda o uso de Facelets como a tecnologia de
exibição em novas aplicações.
2.4.5 JAVASERVER PAGES STANDARD TAG LIBRARY - JSTL
O JavaServer Pages Standard Tag Library (JSTL) encapsula funcionalidades
do núcleo comum a muitas aplicações JSP. Em vez de misturar tags de vários
fornecedores em seus aplicativos JSP, é possível usar um único conjunto padrão de
tags. Essa padronização permite implantar os aplicativos em qualquer conteiner JSP
que suporte JSTL. Com isso a implementação é otimizada.
JSTL possui tags de iteração e condicionais que lhe permite lidar com
controle de fluxo, tags para manipular documentos XML, documentos, tags de
internacionalização, tags para acessar bancos de dados usando SQL, assim como
outras funções comumente usadas.
2.4.6 JAVA PERSISTENCE - JPA
O Java Persistence API (JPA) é uma solução baseada em padrões Java para
persistência. Persistência que usa um objeto/abordagem relacional para preencher a
23
lacuna entre um modelo orientado a objeto e um banco de dados relacional. O Java
Persistence API também pode ser usado em aplicações Java SE, fora do ambiente
Java EE. Java Persistence é composto pelas seguintes áreas:
- O Java Persistence API
- A linguagem de consulta
- Objeto/metadados de mapeamento relacional
A JPA define um meio de mapeamento objeto-relacional para objetos Java
simples e comuns (POJOs), denominados beans de entidade. Diversos frameworks
de mapeamento objeto/relacional como o Hibernate implementam a JPA. Também
gerencia o desenvolvimento de entidades do Modelo Relacional usando a plataforma
nativa Java SE e Java EE.
Segundo material instrucional da empresa K19, a especificação JPA foi criada
com o objetivo de padronizar as ferramentas ORM para aplicações Java e
consequentemente diminuir a complexidade do desenvolvimento. Atualmente, essa
especificação está na sua segunda versão.
Gupta(2012) explica que uma tabela de banco de dados, geralmente com
várias colunas, armazena o estado persistente de um aplicativo. Várias linhas são
armazenadas em tabela de banco de dados para capturar diferentes estados. Uma
única coluna ou combinação de colunas pode definir a singularidade de cada tabela
como uma restrição de chave primária. Estas tabelas geralmente mantém relações
definidas entre eles usando chave estrangeira. Assim, o JPA define um mapeamento
padrão entre a aplicação e o banco de dados através de um POJO. Ele define a
sintaxe para capturar a chave primária e estrangeira e demais restrições, bem como
a forma pela qual os registros podem ser criados, lidos, atualizados e excluídos
usando esses POJO’s. Transações, caching, validação e outros recursos
semelhantes requeridos por uma aplicação que acesse a uma base de dados
também são definidos pelo JPA. Para tanto, a API faz uso extensivo de anotações e
necessita de configuração em arquivos .xml.
Atualmente na segunda versão é indispensável na criação de aplicações no
padrão Java EE.
2.4.7 JAVA TRANSACTION - JTA
O Transaction API Java (JTA), segundo o tutorial oficial do Java EE 6, fornece
uma interface padrão para demarcar transações. A arquitetura Java EE fornece um
recurso automático para lidar com a confirmação ou reversão da transação
(Commit/Rollback). Um auto commit significa que qualquer outra aplicação que
acessa os dados terão acesso a eles atualizados após cada operação de leitura ou
gravação do banco de dados.
Através da interface JTA o desenvolvedor interage com o monitor de
transação, normalmente implementado em um servidor de aplicações para
determinar as fronteiras de uma transação dentro de uma aplicação, isto é, através
da interface JTA ele define o início da transação e determina se ela será confirmada
(commit) ou não (rollback).
24
2.4.8 JAVA API FOR RESTFUL WEB SERVICES - REST
Utilizar um WebService é uma das maneiras mais comuns de se integrar
aplicações diferentes. Existem diferentes tipos de arquiteturas para web services, e
o RESTful é mais simples em comparação aos outros web services, que geralmente
utilizam o SOAP. RESTfull é um WebService que utiliza HTTP e segue os princípios
REST.
REST (REpresentational State Transfer) é um estilo de arquitetura de
software para hipermídia distribuída, tal como a World Web Wide.
Na prática funciona como um conjunto de princípios que servem para definir
um sistema, tais como:
- Arquitetura Cliente-Servidor;
- Não armazena estado;
- Uma única interface bem definida, tais como os métodos do HTTP(Get,
Post, Put, Delete); etc.
RESTfull possui 3 características fundamentais:
- Possui uma URI base para o WebService;
- Um formato de dados suportado pelo WebService, em geral XML ou JSON;
- Um conjunto de operações suportados, utilizando os métodos HTTP.
No Java EE existe a especificação JAX-RS (JSR-311) que padroniza
anotações para criar um WebService seguindo os princípios do REST.
2.4.9 MANAGED BEANS
Gupta(2012), define Managed Beans como um POJO que é tratado como um
componente gerenciado por um conteiner Java EE. Ele fornece uma base comum
para diferentes tipos de componentes que existem na plataforma Java EE. Além
disso, a especificação também define um pequeno conjunto de serviços básicos,
como a injeção de recursos, retornos de chamada do ciclo de vida e interceptores.
Representam uma generalização dos Managed Beans especificados pela
tecnologia JavaServer Faces e pode ser usado em qualquer lugar em um aplicativo
Java EE, e não apenas nos módulos da web. Normalmente, um Managed Bean não
é usado por si só, sendo que na maioria dos casos é utilizado por outros
componentes.
2.4.10 CONTEXTS AND DEPENDENCY INJECTION FOR THE JAVA EE
PLATFORM (JSR 299) - CDI
CDI para a plataforma Java EE define um conjunto de serviços contextuais
aos componentes de negócio, fornecidos pelo conteiner Java EE, que tornam mais
fácil para os desenvolvedores a utilização de EJB’s, juntamente com JavaServer
Faces em aplicações web. Projetado para uso com objetos stateful, CDI também
tem usos mais amplos, permitindo aos desenvolvedores uma grande flexibilidade
para integrar diferentes tipos de componentes de forma flexível e segura.
25
É uma tecnologia que cuida da parte de injeção de dependências. Com o CDI
habilitado todas as classes são consideradas como se fossem Managed Beans, e
portanto, passíveis de injeção e serem injetadas. É possível utilizar com CDI toda a
classe pública com um construtor público ou alguns que receba parâmetros e esteja
anotado com a anotação @Inject.
2.4.11 BEAN VALIDATION
A especificação Bean Validation define um modelo de metadados e API para
validação de dados em componentes JavaBeans. Em vez de distribuir validação dos
dados ao longo de várias camadas, como o navegador e o lado do servidor, você
pode definir as restrições de validação em um só lugar e compartilhá-los através das
diferentes camadas.
Segundo Gupta(2012), as restrições podem ser declarados na forma de
anotações colocado em um campo, propriedade, parâmetro de método ou classe.
Restrições também podem ser definidas em interfaces ou superclasses.
Especificando uma restrição em uma interface significa que a restrição é imposta a
todas as classes que implementam a interface. Da mesma forma, todas as classes
herdadas de uma superclasse herdam o comportamento de validação.
2.4.12 JAVA MESSAGE SERVICE - JMS
Java Message Service é uma API da linguagem Java para middleware
orientado à mensagens que permite que os componentes de aplicativos Java EE
criem, enviem, recebam e leiam mensagens. Ele permite a comunicação distribuída,
flexível, confiável e assíncrona.
2.4.13 JAVA EE CONNECTOR ARCHITECTURE - JCA
O JCA é uma arquitetura genérica para ligar aplicações Java EE a sistemas
legados desenvolvidos em arquitecturas heterogéneas (possivelmente fora da
plataforma Java, incluindo bases de dados).
O JDBC - Java Database Connection é usado especificamente para ligar
aplicações Java a bases de dados e pode ser considerado como uma
implementação de um adaptador de recursos para ligação a bases de dados SQL.
2.4.14 JAVAMAIL
A API JavaMail é utilizada para modelar um sistema de e-mail. Esta API
possui implementações para alguns dos protocolos mais populares para envio e
recebimento de e-mails e fornece um forma bem fácil de usá-los.
O JavaMail possui duas partes:
- Uma interface em nível de aplicativo usado pelos componentes do aplicativo
para enviar o e-mail;
- A interface do provedor de serviço.
26
A plataforma Java EE inclui a API JavaMail com um prestador de serviço que
permite que os componentes do aplicativo enviem e-mail quando conectados a
Internet.
2.4.15 JAVA AUTHORIZATION CONTRACT FOR CONTAINERS - JACC
A especificação Java Authorization Contract for Containers define um contrato
entre um servidor de aplicativos Java EE e um provedor de política de autorização.
A especificação JACC define classes java.security.Permission que
satisfazem o modelo de autorização Java EE. A especificação define a semântica de
provedores de políticas que usam as classes de permissão para atender aos
requisitos de autorização da plataforma Java EE, incluindo a definição e utilização
de papéis (Roles).
2.4.16 JAVA AUTHENTICATION
CONTAINERS - JASPIC
SERVICE
PROVIDER
INTERFACE
FOR
O JASPIC define uma interface de provedor de serviço (SPI) pelo qual os
provedores de autenticação que implementam mecanismos de autenticação de
mensagens que podem ser integrados.
2.5 Serviços Padrão do Java EE
Os conteineres que hospedam as aplicações Java EE devem fornecer a cada
tipo de componente visto acima um conjunto de serviços que consistem em:
- Conectividade, a fim de proporcionar a comunicação com outros
componentes e clientes do aplicativo. Isso pode ser feito através de RMI (Remote
Method Invocation) e CORBA.
- Serviços de Diretório, sendo obrigados a fornecer serviço de atribuição de
nomes nos quais os componentes podem ser registrados e descobertos. Isto é feito
através da JNDI (Java Naming and Directory Interfaces).
- Acesso a dados e persistência, de modo que a aplicação tenha acesso a
fonte de dados. Pode ser realizado via JDBC (Java Database Connection).
- Conectividade Legada, que permite a integração com servidores legados e
ERP’s (Enterprise Resource Planning) através do componente JCA.
- Segurança, que está incorporada no Java EE, bem como por API’s como o
JAAS (Java Authentication and Authorization Service).
- Suporte para XML, de modo a suportar a análise de documentos XML
usando DOM (Document Object Model), XSTL (eXtensible Styleshet Language
Transformation) e outras tecnologias.
- Transasões, também fornecido pela especificação JTA no Java EE, de
modo a controlar as transações que serão realizadas em banco de dados.
- Troca de Mensagens e e-mails, que são realizadas pelas API’s JMS e
JavaMail também já integradas ao Java EE.
27
Todos os servidores devem suportar os serviços descritos nesta sessão. Na
figura a seguir um esquema de serviços que devem ser suportados por qualquer
servidor Java EE:
Figura 10 - Plataforma Java EE com serviços disponíveis
Fonte: BOND et al (2003)
Como visto o Java EE é um padrão dinâmico para produção de aplicativos
corporativos seguros, escaláveis e altamente disponíveis, de modo que define quais
serviços devem ser fornecidos pelos servidores que o suportam.
Conforme explicam BOND, et al(2003), embora a especificação do Java EE
defina um conjunto de serviços e tipos de componentes, ela não contém
informações sobre como organizar a arquitetura lógica em máquinas físicas,
ambiente ou espaços de endereços.
A plataforma Java EE fornece um ambiente comum para construção de
aplicativos seguros escaláveis e independente de plataforma.
28
3 SEAM FRAMEWORK
Como o título deste capítulo já deixa claro o JBoss Seam é um framework. Na
verdade é um framework que está acima de outro framework, o Java EE, que
também fica acima de outro framework, o Java. (FARLEY, 2008).
A palavra framework tem um amplo significado, contudo no caso do Seam e
sob o ponto de vista da tecnologia representa a moldagem de um conjunto de API’s
e serviços em um ambiente que facilita ou simplifica o desenvolvimento de
aplicações, neste caso Java EE.
O Seam simplifica atividades rotineiras e comuns, fornecendo utilitários
nativos que em outras situações o programador teria que escrever. Conforme
explica FARLEY(2008), ele atende os deveres de um framework de duas formas:
- Simplificando o Java EE por meio de um conjunto de atalhos e
simplificações do framework padrão Java EE, tornando fácil e eficaz o uso de
componentes web e de negócios.
- Extendendo o Java EE visto que integra um conjunto de conceitos e
ferramentas. Tais extensões trazem novas funcionalidades para dentro do Java EE.
Ao longo deste capítulo serão listados vários serviços e utilitários que o JBoss
Seam fornece.
3.1 Integração entre o JBoss Seam e o Java EE
O ambiente padrão do Java EE é formado pelo Java SE(Java Standard
Edition) e suas API’s como o JDBC para acesso a banco de dados, JAXP para
processamento de XML entre outros que suportam todos os recursos da camada
enterprise do Java EE como JSF, JSP e Servlets usados no desenvolvimento web,
bem como o JAX-WS para web services entre outros, como ilustrado na figura
abaixo:
Figura 11 - Padrão Java EE
Fonte: Adaptado de Farley(2008)
Mesmo com os diversos recursos oferecidos pelo Java EE e os diversos
avanços em relação ao predecessor J2EE o Seam Framework simplifica ainda mais
o desenvolvimento web. O Seam atua entre a camada de código da aplicação e o
Java EE como se vê na figura abaixo:
29
Figura 12 - Seam Framework
Fonte: Adaptado de Farley(2008)
3.2 Modelo de Componentes
O conjunto de facilidades fornecidas pelo Seam Framework derivam
principalmente de seu modelo de componentes. Em verdade, este modelo é uma
extensão do modelo de componentes já existente no JSF através dos managed
beans.
Um benefício fundamental fornecido pelo modelo de componentes é o uso
direto de componentes EJB acoplados as páginas JSF. Para tanto o Seam fornece
uma ponte entre o modelo de componentes do JSF e o modelo de componentes do
EJB, permitindo a utilização direta como um managed bean.
Segundo ALLEN(2008), no processo de resolver o descompasso entre JSF e
EJB 3, os arquitetos Seam ampliaram a solução e criaram um modelo de
componente universal, trazendo os serviços fornecidos implícitos na programação
com EJB 3, como transações, interceptores e segurança, para componentes nãoEJB, tais como JavaBeans. ALLEN(2008) explica ainda que para os componentes
que não sejam EJB, o JBoss Seam é quem processa as anotações ou sinônimos
dessas anotações pertencentes ao API do Seam Framework API. Dessa forma, não
é necessário um conteiner EJB para aproveitar os benefícios que o EJB 3 fornece.
SALTER(2009), informa que o JBoss Seam implementa os seguintes
componentes:
- JavaBeans/POJO’s
- Stateless Session Bean
- Stateful Session Bean
- JPA Entity
- Message-driven Bean
Um componente é definido através da anotação @Name. Quando o nome é
utilizado no JSF, a instância do bean será automaticamente inicializada e usada
como um bean acoplado no JSF.
30
Usando esta anotação em uma classe, esta será vinculada automaticamente
uma instância desta com um componente JSF.
@Name("minhaClasse")
public class MinhaClasse{
3.3 Bijeção
Segundo FARLEY(2008), o Seam oferece uma visão mais abrangente de
dependências por injeção denominada bijeção. Este conceito suporta a propagação
das referências em dois sentidos, ou seja um componente pode ser injetado no
contexto ou pode ter uma injeção da referência realizada. Tudo isso de uma forma
muito simples utilizando anotações (@In e @Out). Possibilita atualizações dinâmicas
do componente de modo que a injeção não é realizada uma única vez, a bijeção
ocorre a cada invocação do componente.
No Seam a anotação @In é usada para injetar um componente Seam em
outro componente, podendo ser aplicada a membros de classe ou a métodos
assessores, como nos trechos de código abaixo:
@In
private AlgumBean algumBean
ou
@In
public AlgumBean getAlgumBean(){
return algumBean;
}
Assim como é possível importar ou injetar um valor é possível exportar o valor
de componentes ao introduzir o conceito de outjeção para o escopo onde o mesmo
foi criado. Isto é feito utilizando a anotação @Out e é aplicada de forma similar a
anotação de injeção, porém com fim de exportar o compomente. Sua aplicação pode
ser observada no trecho de código abaixo:
@Out
private AlgumBean algumBean
ou
@Out
public AlgumBean getAlgumBean(){
return algumBean;
}
Esta anotação carrega consigo o atributo scope que permite especificar o
contexto da outjeção.
A injeção e a outjeção não é um evento que ocorre uma única vez. Estes
eventos serão realizadas toda vez que um componente Seam for invocado.
31
Grande parte dos componentes do Seam também fornecem um número
poderoso de serviços extendidos no topo do padrão Java EE.
3.4 Contexto de Componentes
Os contextos do JBoss Seam são semelhantes aos contextos de uma
aplicação web pura em Java EE (componentes JSF, Servlet e JSP). Os contextos
são áreas de objetos onde é possível associar um namespace (string) para
identificação de um objeto ao armazená-lo no contexto. O contexto determina um
tempo de vida para os objetos que ali são armazenados. O tempo de vida determina
um escopo de existência dos objetos ao torná-los disponíveis para os Servlets e
JSP's ou componentes JSF da aplicação.
Numa aplicação Java EE simples existem os seguintes contextos para
armazenar objetos:
- Page
- Request
- Session
- Application
Não convém aqui voltar a descrevê-los visto que já foram alvo de estudo no
capítulo anterior.
Os contextos Seam são complementares e distintos dos contextos do Java
EE. No Entanto, alguns deles são internamente os mesmos contextos do Java EE. O
Seam disponibiliza os seguintes contextos: stateless, event, page, conversation,
session, business process e application.
- Stateless: Contexto para armazenar a referência para objetos sem estado
em session stateless EJB).
- Event: É equivalente ao contexto request do Java EE. Recebe outro nome
em razão de ser utilizado em outras situações além de requisições Web como
invocação RMI ou invocação via Seam Remoting aos componentes Seam. Este
contexto está associado ao ciclo de vida JSF. Durante o processamento do ciclo de
vida os objetos associados estarão disponíveis e serão eliminados somente ao final
do ciclo de vida JSF. Este contexto tem o tempo de vida de uma requisição Ajax
realizada pelas bibliotecas de componentes visuais JSF com suporte a Ajax.
- Page: Permite armazenar objetos que são criados e usados em uma tela
JSF. Este contexto pode ser comparado com o contexto page do Java EE. Contudo,
um objeto armazenado neste contexto estará diponível somente para a página JSF
correspondente que o instanciou a partir de algum listener de evento. Como a
documentação sugere, este contexto é útil em alguns componentes visuais como,
por exemplo, numa lista clicável de opções que precisa de um objeto com valores
específicos para esta lista e página JSF. Objetos neste contexto estarão disponíveis
mesmo em sucessivas requisições Ajax a partir de componentes visuais a partir do
navegador web.
- Conversation: Este contexto é considerado o grande diferencial do JBoss
Seam, o qual agrega valor no desenvolvimento de aplicações Web com JSF. O
contexto de conversação permite armazenar objetos que terão um tempo de vida
32
maior que uma requisição (event) e menor que uma sessão (session). Com este
contexto é possível definir um escopo para objetos que são usados para
implementar um fluxo de telas que realizam um caso de uso. Em um Componente
Seam é possível anotar o início da conversação e em outro método usar outra
anotação para demarcar o fim da conversação. (@Begin e @End). Funcionando
dessa forma é possível abrir várias janelas de navegação para uma mesma tela JSF
e cada janela representar uma conversação diferente (contexto diferente de objetos)
para execução simultânea do mesmo caso de uso. Cada janela é um contexto
separado que não influência um outro contexto aberto.
- Session: Este contexto é equivalente ao contexto Java EE de mesmo nome.
Define um escopo para manter objetos no contexto enquanto o usuário estiver
logado na aplicação
- Business Process: Define um contexto para objetos que são associados a
um processo de negócio gerenciado pelo jBPM. Objetos armazenados neste
contexto pertencem a um processo e podem ser compatilhados entre vários usuários
que acessam o mesmo processo de negócio. Só faz sentido usar este escopo se a
máquina de processos implementada pelo jBPM estiver em uso numa aplicação
Java EE em conjunto com o JBoss Seam.
- Application: É equivalente ao contexto Java EE de mesmo nome. Objetos
armazenados neste contexto estarão disponíveis para todas as conversações e
usuários que acessam a aplicação. É útil ao armazenar objetos com conteúdo que
não mudam com freqüência para compatilhar para toda aplicação. Muitos objetos
internos do próprio Seam são armazenados neste contexto.
Todos os contextos acima definem namespaces para dar nome ao objeto
armazenado. Os nomes para os objetos armazenados nestes contextos são
chamados de context variable. Em uma página JSF, ao usar uma expression
language (EL) para associar um componente visual a um objeto (seam component)
armazenado em um destes contextos, o Seam realiza a busca do objeto a partir do
nome indicado na expressão em uma ordem de prioridade (event, page,
conversation, session, business process, application). Também é possível indicar
programaticamente (dentro de um método do Managed Bean ou Seam Component)
qual contexto deve obter o objeto sem realizar uma busca nos vários contextos
simplesmente utilizando anotação (@Scope).
3.5 Eventos Seam
O Seam introduz dois novos tipos de eventos ao modelo de eventos do JSF:
- Ações de Página (Page Actions): são eventos disparados logo depois que
uma requisição web é realizada e respondida antes que a página seja renderizada.
Estas ações são implementadas como métodos de um managed beans JSF ou
métodos de um componente Seam.
- Eventos voltados ao componente: fornecem um esquema de notificação
geral de eventos para os componentes Seam. Um conjunto de nomes de eventos
podem ser definidos e os métodos de componentes podem ser registrados como
33
callbacks desses eventos. Assim, qualquer componente pode disparar um evento
em qualquer lugar no código de negócio e qualquer operação pode ser invocada.
O JBoss Seam implementa os chamados Action Listeners, que são utilizados
como alvo de formulários de submissão e links em aplicações web. Eles agem como
parte do controlador no padrão MVC suportados pelo JSF. Os Actions Listeners são
capazes de executar qualquer regra de negócio que é necessária para lidar com os
dados fornecidos pelo usuário em suas solicitações.
O Seam também suporta o uso de JavaBeans ou POJO’s como action
listeners. Este tipicamente implementam regras de negócio, e não apenas simples
operações de persistência.
3.6 Seam Data Validation
SALTER(2009), afirma que o Seam vai muito além de fornecer recursos ao
JSF servindo como Bean de apoio. O Seam fornece ferramentas de validação, com
fito a impedir a inserção de dados inválidos que possam comprometer a segurança
da aplicação.
Este modelo de validação é realizado utilizando o Hibernate Validator. Para
tanto são utilizadas as seguintes anotações, entre outras:
@Pattern – Especifica uma validação através do uso de expressão regular
(regex);
@Range – Especifica que o valor deve estar entre um mínimo e um máximo;
@AssertFalse - Verifica se anotação é false;
@AssertTrue - Verifica se anotação é true;
@Email - Verifica se a seqüência especificada é um endereço de e-mail
válido;
@Length(min=, max=) - Precisa ser uma string. Validar que a string está
entre min e max incluído;
@Max - Verifica se o valor anotado é inferior ou igual ao valor máximo
especificado;
@Min - Verifica se o valor anotado é maior do que ou igual ao mínimo
especificado;
@NotNull - Verifique se o valor anotado não é nulo;
@NotEmpty - Precisa ser uma string. Verifica se a string não é nulo ou vazio;
@Null - Verifique se o valor anotado é nulo;
@Pattern(regex=, flag=) - Precisa ser uma string. Verifica se a cadeia
anotada corresponde à expressão regular regex;
@Size(min=, max=) - Verifica se o tamanho do elemento anotado é entre
mínimo e máximo. Tamanho da coluna será definido para max;
@Valid - Realizar a validação recursivamente sobre o objeto associado, ou
seja com objetos que tenham relacionamento;
Um exemplo da aplicação é visto no trecho de código abaixo:
34
public class Cidade {
@Length(max=2, min=2)
private Char uf;
@NotNull
private String nome;
@Length(max=8)
@Pattern("^\d*$")
private String cep;
/*Getters e Setters*/
}
Dessa forma não é mais necessário especificar o tipo de validação a ser
utilizado na página JSF. Em vez disso utiliza-se apenas a tag <s:validate> ou
<s:validateAll>, como nos trechos de código a seguir:
<h:form>
<div>
<h:messages/>
</div>
<div>
Estado:
<h:inputText value="#{cidade.uf}">
<s:validate/>
</h:inputText>
</div>
<div>
Nome da Cidade:
<h:inputText value="#{cidade.nome}">
<s:validate/>
</h:inputText>
</div>
<div>
Cep:
<h:inputText value="#{cidade.cep}">
<s:validate/>
</h:inputText>
</div>
<div>
<h:commandButton/>
</div>
</h:form>
Ou simplesmente:
<h:form>
<div>
<h:messages/>
</div>
<s:validateAll>
<div>
Estado:
35
<h:inputText value="#{cidade.uf}"/>
</div>
<div>
Nome da Cidade:
<h:inputText value="#{cidade.nome}"/>
</div>
<div>
Cep:
<h:inputText value="#{cidade.cep}"/>
</div>
<div>
<h:commandButton/>
</div>
<s:validateAll>
</h:form>
3.7 Página de Navegação
A navegação entre páginas com JSF fornece um conjunto limitado de
recursos. O JBoss Seam fornece uma linguagem de navegação concisa que
incorpora o gerenciamento do escopo de conversação, segurança, tratamento de
exceções, os parâmetros de requisição, notificação de eventos, e muito mais. No
Seam o que define o fluxo de navegação é o namespace de navegação, usado para
configurar os componentes de navegação.
O namespace é usado dentro do arquivo WEB-INF/pages.xml. Este unifica a
lógica de navegação e é controlado pelo Seam. Esta lógica inclui parâmetros de
página, gerenciamento de conversa e permite que a navegação seja baseada na
avaliação de Expression Language (EL) em vez de depender de valores de retorno.
Além disso, é possível notificar eventos, manipular exceções genéricas, aplicar
restrições de segurança, etc.
3.7.1 ELEMENTOS DE NAVEGAÇÃO
De acordo com ORSHALICK(2009), o esquema em XML do JBoss Seam usa
as seguintes notações para indicar os elementos necessários e possíveis para
realizar a navegação:
<pages> é o elemento raiz que define a configuração geral aplicado a todas as
páginas.
<page> Define a navegação, bem como o controle da ógica associada a um view-id.
<conversation> Configura um escopo de conversação quando chamado.
<exception> Define a manipulação para um tipo específico de exceção.
<http-error> Especifica um código de erro HTTP e que este seja retornado para
o usuário.
<mensagem> Especifica uma mensagem que deve ser exibida para o usuário.
<restrict> Configura uma restrição de segurança para uma página definida
através de EL.
36
<description> Fornece uma descrição para a página que será exibida no
ConversationSwitcher. Sem essa descrição a conversação não vai aparecer no
componente.
<param> Define um parâmetro de página a ser definido a partir de solicitação GET.
<action> Define uma ação a ser executada.
<header> Especifica cabeçalhos de HTTP a ser adicionado a uma página.
<navigation> Define as regras de navegação associadas a uma página.
<rule> Especifica uma ação específica. Seu conteúdo deve retornar um valor
booleano resultado de uma expressão em que a navegação deve ocorrer.
<redirect> Redireciona o usuário para o valor especificado em view-id.
<render> Especifica um view-id para ser processado.
<raise-event> Configura um evento a ser gerado quando da exibição da página
ou de navegação.
<beginconversation> Inicia uma conversação de longa duração.
<endconversation> Termina uma conversação longa.
Figure 13 - Elementos da página de navegação
Fonte: ORSHALICK (2009)
Exemplo de sua aplicação pode ser visto no trecho de código abaixo:
<page login-required="true" view-id="/ManterAgenda.xhtml">
<restrict>#{s:hasRole(‘admin’)}
<action execute="#{redirect.captureCurrentView()}"/>
<navigation>
<begin-conversation />
<rule if-outcome="editarAgenda">
<redirect view-id="/Agenda/Agenda.xhtml"/>
</rule>
<rule if-outcome="mostrarAgenda">
37
<redirect view-id="/Agenda/AgendaView.xhtml"/>
</rule>
</navigation>
</page>
...
<exception class="org.jboss.seam.security.AuthorizationException”>
<end-conversation/>
<redirect view-id=”/generalError.xhtml”>
<message>
Você não tem autorização para acessar o recurso
</message>
</redirect>
</exception>
O modelo de nagegação entre páginas do JBoss Seam também dá suporte a
gestão de pageflow (fluxo de navegação) da aplicação usando jPDL(Linguagem de
Definição de Processo jBPM). Como sugere o nome, jPDL faz parte do jBPM
(Gestão de Processos de Negócio) que é a ferramenta JBoss para definição de
workflows e orquestração de tarefas dentro de um processo de negócio. (FARLEY,
2008).
Ademais, o JBoss Seam permite misturar a navegação JSF e pageflow jBPM
na mesma aplicação Seam, além de possibilitar o uso do escopo de conversação.
3.8 Biblioteca de Tags do JBoss Seam
Uma biblioteca estendida de tags JSF é definida pelo Seam para fornecer
controle sobre a navegação de conversação, menu simplificado, validação de beans
bem como para formatação componente.
Para possibilitar esta integração e o uso da biblioteca de Tags do Seam é
necessário declarar seu uso. Isso pode ser feito através de facelets:
/* Na versão 2.3.0.Final */
xmlns="http://www.w3.org/1999/xhtml"
xmlns:s="http://jboss.org/schema/seam/taglib"
/* Nas versões anteriores */
xmlns=”http://www.w3.org/1999/xhtml”
xmlns:s=”http://jboss.com/products/seam/taglib”
3.8.1 TAGS DE NAVEGAÇÃO
ORSHALICK(2009) informa que o Seam fornece um conjunto de
componentes controlar a propagação da conversação em ambos solicitações GET e
POST. Esses componentes também estendem as capacidades do JSF para permitir
que solicitações GET desencadeiem ações junto aos actions listeners.
38
<s:link> Link que executa um pedido GET para invocar uma ação e permite a
propagação da convesação.
<s:button> Botão que executa uma requisição GET para invocar uma ação e
permite a propagação da convesação.
<s:conversationId> Adiciona um ID a conversação em para um link ou botão JSF.
<s:conversation Propagation> Permite a propagação da conversação podendo
ser controlado por um link ou botão de comando do JSF.
<s:defaultAction> Configura um botão (por exemplo, <h:commandButton>) como
ação padrão quando o formulário é enviado usando a tecla Enter (Return).
O trecho de código abaixo exemplifica o uso da tag <s:link>:
<s:link view-id=”/inicio.xhtml” propagation=”none” value=”Voltar ao
Início” />
3.8.2 TAGS DE SELEÇÃO
Em JSF sempre é necessário usar componentes de seleção para escolher
valor em uma lista de objetos ou uma enumeração de valores. Com o padrão JSF é
necessário o desenvolvimento de conversores e mesmo o tratamento deste objetos
a fim de possibilitar seu uso. O Seam torna esta tarefa simples por meio das tags
<s:selectItems>, <s:enumItem>, <s:convertEntity> e <s:selectItems>.
Assim é possível associar diretamente um atributo da entidade JPA ao componente.
<s:convertEntity> Converte uma entidade gerenciada para o seu identificador
único. Usado para selecionar entidades em um componente de seleção.
<s:convertEnum> Converte um enum para a sua representação constante.
Geralmente utilizado para a seleção de enums em um componente de seleção.
<s:enumItem> Cria um SelectItem de um valor enumerado permitindo que o rótulo
seja exibido.
<s:selectItems> Cria um SelectItem a partir de uma List, Set, DataModel ou
Array. Itera sobre a coleção com uma variavél permitindo que o itemLabel e
ItemValue seja definido através de EL.
No trecho de código abaixo é exibido um exemplo de seu emprego:
<h:selectOneMenu id=”ddCargo” value=”#{associado.cargo}”
required=”true”>
<s:selectItems noSelectionLabel=”--Selecione--” var=”type”
value=”#{creditCardTypes}” itemLabel=”#{type.description}”/>
<s:convertEntity />
</h:selectOneMenu>
39
3.8.3 TAGS DE FORMATAÇÃO
As seguintes tags de formatação permitem decorar campos inválidos com
estilos e mensagens. Além da formatação da mensagem, o Seam também dispõe de
tags para formatação de componentes:
<s:decorate> "decora" um campo de entrada JSF quando a validação falhar ou
quando a tag required for igual a "true". É definida usando Facelets.
<s:label> "decora" um campo de entrada(input) com uma etiqueta(label). Esta tag
é colocada no interior do elemento HTML, e está associado com o componente de
entrada mais próximo.
<s:message> "decora" um campo de entrada com a mensagem de erro de
validação associada a esse campo.
<s:div> Renderiza um componente <div>. Permite que o <div> seja
opcionalmente renderizado.
<s:span> Renderiza um componente <span>. Permite que o <span> seja
opcionalmente renderizado.
<s:fragment> Permite renderizar opcionalmente um fragmento HTML.
Estas foram apenas algumas das tags possíveis de serem utilizadas com o
Seam Framework. Segue abaixo uma lista completa das tags disponibilizadas pelo
JBoss Seam:
- s:button
- s:cache
- s:conversationId
- s:conversationName
- s:conversationPropagation
- s:convertAtomicBoolean
- s:convertAtomicInteger
- s:convertAtomicLong
- s:convertDateTime
- s:convertEntity
- s:convertEnum
- s:decorate
- s:defaultAction
- s:div
- s:download
- s:enumItem
- s:fileUpload
- s:formattedText
- s:fragment
- s:graphicImage
- s:label
- s:link
- s:message
- s:remote
- s:resource
- s:selectItems
- s:selection
- s:span
- s:taskId
- s:token
- s:transformImageBlur
- s:transformImageSize
- s:transformImageType
- s:validate
- s:validateAll
- s:validateEquality
- s:validateFormattedText
40
3.9 RichFaces
De acordo com a descrição no site oficial do RichFaces, este é um framework
que contém uma biblioteca de componentes ricos para JavaServer Faces. O
RichFaces extende as capacidades Ajax Framework do JSF com recursos
avançados.
O RichFaces aproveita várias partes da estrutura do JSF 2, incluindo ciclo de
vida, validação, instalações de conversão e gerenciamento de recursos estáticos e
dinâmicos. Oferece suporte a Ajax e é personalizável podendo ser incorporado em
qualquer aplicação JSF.
Além disso, a estrutura do RichFaces é projetado para ser usado de forma
integrada com outras bibliotecas na mesma página, proprocionando mais opções
para o desenvolvimento de aplicações.
O Kit de Desenvolvimento de Componentes (CDK), utilizado para a criação da
interface do usuário da biblioteca RichFaces inclui um recurso de geração de código
e um mecanismo de templates usando XHTML (eXtend hyper-text markup
language). Isso proporciona o manuseio de recursos para gerar imagens, sons,
planilhas do Microsoft Excel, e muito mais durante tempo de execução (runtime).
Possibilita ainda a personalização da aplicação por meio de temas,
proporcionando sua alteração em tempo de execução. Para isso, o RichFaces trás
consigo uma série de skins, contudo permite ao usuário criar a sua própria.
O RichFaces consiste das seguintes partes:
- Componentes ricos e Ajax dividido em duas bibliotecas de tags (a4j:,
rich:);
- Skins;
- Extensão para validação de objetos no lado do cliente utilizando Bean
Validation (JSR 303);
- CDK (Component Development Kit).
3.9.1 BIBLIOTECA DE TAGS DOS COMPONENTES RICHFACES
Os componentes RichFaces são divididos em duas bibliotecas de tags:
- a4j:
- rich:
Para habilitá-las nas páginas XHTML é preciso incluir os seguintes
namespaces:
xmlns:rich="http://richfaces.org/rich"
xmlns:a4j="http://richfaces.org/a4j"
A biblioteca de tags a4j: fornece suporte Ajax em nível de página e outras
tags de suporte. Fornece recursos básicos como enviar um pedido, o que enviar
para o servidor, e o que atualizar. As seguintes tags são fornecidas:
41
- a4j:actionparam
- a4j:ajaxListener
- a4j:commandButton
- a4j:commandLink
- a4j:facet
- a4j:form
- a4j:htmlCommandLink
- a4j:include
- a4j:jsFunction
- a4j:keepAlive
- a4j:loadBundle
- a4j:loadScript
- a4j:loadStyle
- a4j:log
- a4j:mediaOutput
- a4j:outputPanel
- a4j:page
- a4j:poll
- a4j:portlet
- a4j:push
- a4j:queue
- a4j:region
- a4j:repeat
- a4j:status
- a4j:support
A biblioteca de tags rich: fornece tags de componentes ricos. Pode-se
entender componentes ricos como tags HTML padrão que fornecem recursos
avançados, como por exemplo, um tab panel. Muitos componentes ricos também
possuem embutido suporte a Ajax. Estes componentes disparam pedidos Ajax e
fazem atualizações parciais de página automaticamente. A maioria destes
componente podem ser personalidados usando a4j: tags. As seguintes tags são
fornecidas:
- rich:ajaxValidator
- rich:beanValidator
- rich:calendar
- rich:changeExpandListener
- rich:colorPicker
- rich:column
- rich:columnGroup
- rich:columns
- rich:comboBox
- rich:componentControl
- rich:contextMenu
- rich:currentDateChangeListener
- rich:dataDefinitionList
- rich:dataFilterSlider
- rich:dataGrid
- rich:dataList
- rich:dataOrderedList
- rich:dataTable
- rich:datascroller
- rich:dndParam
- rich:dragIndicator
- rich:dragListener
- rich:dragSupport
- rich:dropDownMenu
- rich:dropListener
- rich:progressBar
- rich:recursiveTreeNodesAdaptor
- rich:scrollableDataTable
- rich:scrollerListener
- rich:separator
- rich:simpleTogglePanel
- rich:sliderListener
- rich:spacer
- rich:subTable
- rich:suggestionbox
- rich:tab
- rich:tabPanel
- rich:toggleControl
- rich:togglePanel
- rich:toolBar
- rich:toolBarGroup
- rich:toolTip
- rich:tree
- rich:treeNode
- rich:treeNodesAdaptor
- rich:virtualEarth
42
O intuito aqui não é explorar em detalhes cada tag do RichFaces, mas
apenas dar uma visão geral sobre seu emprego e suas vantagens. Os detalhes e
referência sobre cada tag pode ser amplamente encontrada no website JSF Toolbox
(http://www.jsftoolbox.com/documentation/richfaces/09-TagReference/index.jsf),
especializado em desenvolvimento com JavaServer Faces.
Embora existam inúmeras tags em RichFaces, existem apenas três conceitos
fundamentais:
- O envio de requisições AJAX;
- Renderização parcial do JSF;
- Processamento de parte da página JSF.
Tudo isso é muito importante para a criação de regiões Ajax na página,
validação e desempenho.
3.9.2 TEMAS RICHFACES
É possível criar temas com diferentes esquemas de cores. Os temas podem
ser personalizados, criados novos temas e substituídos em nível de CSS. O recurso
é baseado na tecnologia XCSS que fornece flexibilidade e dinâmica. RichFaces
fornece um conjunto de temas pré-definidos:
- DEFAULT
- plain
- emeraldTown
- blueSky
- wine
- japanCherry
- ruby
- classic
- deepMarine
- Laguna
- GlassX
- DarkX
Como se viu o RichFaces extende os componentes do JavaServer Faces, por
isso também é considerado como uma biblioteca de componentes para JSF. É
notório que este framework é muito mais que isso.
O RichFaces contribui para fazer do JBoss Seam uma ferramenta ainda mais
poderosa, por agregar mais componentes visuais com foco a interfaces ricas e
suporte Ajax.
Finalizando este capítulo é possível concluir sobre o JBoss Seam que ele
integra as tecnologias mais cogitadas do mercado open source como AJAX, JSF,
EJB 3.0, BPM, entre outras em um único framework, para facilitar o desenvolvimento
de aplicações RIA (Rich Internet Application), de maneira integrada e eliminando a
complexidade dessas API’s. Com isso, o Seam possibilita a criação de aplicações
43
complexas com poucas classes java, interfaces com usuário poderosas e com
arquivos XML de configuração.
44
4 METODOLOGIA
O objetivo do trabalho é apresentar o Seam Framework como solução para o
desenvolvimento de projetos para web e verificar a viabilidade de seu uso. Para este
feito foi proposto, depois de realizada uma revisão teórica acerca das tecnologias
que envolvem a solução, implementar uma aplicação utilizando o JBoss Seam.
O tipo de estudo a ser aplicado será o estudo de caso, cujos resultados serão
apresentados na forma de uma aplicação web onde os passos para sua construção
serão descritos de acordo com a tecnologia/componente utilizado e avaliado sua
viabilidade.
4.1 Cenário
Conforme a proposta deste trabalho houve a necessidade de levantar um
local ou empreendimento que necessitasse de uma aplicação para controle de seus
fluxos e armazenamento de informações. Para tanto, o local escolhido foi uma
associação de classe de servidores públicos, cuja necessidade inicial era o controle
de seus associados. Contudo, como associação ela não necessita apenas do
controle de seus associados, mas também de seus colaboradores, bens e serviços
oferecidos.
Sem o intuito de divulgar o local onde foi realizado o trabalho, este será
tratado apenas como “Associação de Classe”. Esta congrega pessoas e interesses
de uma classe de servidores públicos do Estado de Mato Grosso e está sediada em
Cuiabá/MT. Coloca a disposição de seus associados uma ampla área de lazer, hotel
e áreas para eventos privados – área de churrasqueira, salão de festas, campo de
futebol, etc. Para manter em funcionamento toda a estrutura a associação mantém
um grupo de funcionários responsáveis por cuidar da área administrativa,
jardinagem, limpeza e manutenção (serviços gerais). No local também funciona o
sindicato da classe que utiliza o mesmo cadastro de associados mantido pela
associação.
4.2 Descrição da Proposta
Com o intuito de atender as necessidades de controle da Associação de
Classe e cumprir com os objetivos deste trabalho, após o levantamento e análise de
requisitos, foi proposto o desenvolvimento de uma aplicação web que realizasse o
controle dos associados como função principal e dispusesse das seguintes
funcionalidades: controle de fornecedores, cadastro de funcionários(colaboradores),
controle de patrimônio, agenda para uso das áreas privativas, controle das
hospedagens no hotel, agenda de contatos, geração de relatórios em PDF e
possibilidade do sistema enviar mensagens eletrônicas (e-mail) a seus associados.
Além disso a aplicação deve possibilitar o acesso via web (utilizando um navegador)
de modo a não ficar preso a instalação da aplicação nos computadores e
possibilitasse seu acesso externo (fora da sede da associação).
De posse dessas informações, verificou-se a viabilidade do uso Seam
Framework como solução para o desenvolvimento da aplicação requerida. Passo
45
importante, foi a especificaçãos das ferramentas utilizadas, na qual especifica as
características e razões de escolha de cada uma.
Seguindo os passoas para desenvolvimento de software, em especial
orientado a objetivos foi realizado o levantamento de requisitos e em seguida a
elaboração de alguns diagramas da UML como forma de modelar a aplicação e
uniformizar a especificação dos artefatos. Dessa forma, foram selecionados os
Diagramas de Caso de Uso e o Diagrama de Classe para delimitar as
funcionalidades da aplicação, bem como a estrutura e suas relações
respectivamente.
Também, foram descritas as etapas do desenvolvimento com a explicitação
de algumas telas com fito a demonstrar a aplicabilidade do JBoss Seam e suas
interações.
Por fim, foi realizada a análise da aplicação do Seam Framework no
desenvolvimento de um projeto web com vistas a cumprir o objetivo proposto para
este trabalho.
46
5 ESTUDO DE CASO: PROJETO JBOSS SEAM
Este capítulo destina-se a descrever e demonstrar os aspectos relacionados
ao desenvolvimento de um projeto web utilizando o Seam Framework. Para este
feito, o sistema a ser desenvolvido visa atender as necessidade de controle de uma
“Associação de Classe” conforme cenário descrito no capítulo anterior e acatando o
levantamento de requisitos realizado.
5.1 Ferramentas (Tecnologia)
Antes de iniciar o desenvolvimento do projeto foi necessário realizar uma
seleção das ferramentas a serem utilizadas. Tais ferramentas estão focadas na
necessidade do desenvolvimento e produção da aplicação considerando desde o
conteiner web até a IDE de desenvolvimento. A escolha das ferramentas pode
seguir critérios específicos em razão das necessidade e disponibilidade de recursos
da empresa. Neste caso, foram adotadas ferramentas open source como se segue
nos tópicos a seguir.
5.1.1 SERVIDOR DE APLICAÇÃO JBOSS AS
Um dos requisitos da aplicação é que seja acessado via web por meio de um
browser. Com o uso do Seam Framework, a escolha natural de um servidor de
aplicação é pelo JBoss Application Server. Contudo convém esclarecer que seria
possível o uso de qualquer outro conteiner web que suportasse Java EE como
descrito no capítulo 2.
A versão do JBoss AS escolhida foi a 7.1 em razão da compatibilidade com a
versão do JBoss Seam empregada e por suportar o uso das versões mais recentes
dos componentes assessórios.
Figura 14 - JBoss AS 7.1
47
5.1.2 SEAM FRAMEWORK
Este framework foi largamente explorado no capítulo 3 deste trabalho.
Contudo, o Jboss Seam destaca-se por ser um framework para aplicações web
desenvolvido pela JBoss uma divisão da Red Hat, para o desenvolvimento de
aplicações Java EE de maneira fácil, por meio da integração com tecnologias como
JavaServer Faces, Java Persistence API, Enterprise JavaBeans(EJB 3.0), AJAX e o
Gerenciamento de processos de negócio. Como visto, este framework extende o
Java EE possibilitando um desenvolvimento mais consistente, rápido, utilizando os
padrões de projeto já consagrados e permitindo ao desenvolvedor preocupar-se
mais com as regras de negócio.
A versão utilizada foi a 2.3.0.Final em razão de sua melhor aceitação no
mercado comparado com a versão 3.1.0.Final. Outrossim, a versão 2.3.0.Final
mantém a linha do projeto inicial do framework e suporta as versões mais recentes
do JSF (JSF 2.1) e da especificação do JPA (JPA 2).
Figura 15 - JBoss Seam 2.3.0.Final
48
5.1.3 SISTEMA GERENCIADOR DE BANCO DE DADOS POSTGRESQL
O PostgreSQL é um SGBD (Sistema Gerenciador de Banco de Dados)
objeto-relacional de código aberto. É extremamente robusto e confiável, além de ser
extremamente flexível e rico em recursos.
A opção por este SGBD se deu por ser uma solução de nível corporativo, com
funcionalidades sofisticadas, multiplataforma, com performance admirável e
altamente escalável. Além disso, integra-se muito bem com aplicações
desenvolvidas em Java.
A versão utilizada é a 9.1 com a ferramenta de administração PGAdmin III.
Figura 16 - PostgreSql 9.1
5.1.4 ECLIPSE IDE
O Eclipse foi a IDE (Integrated Development Environment) escolhida para
realizar o desenvolvimento da aplicação. Oferece em seu estado mais básico os
recursos mínimos para o desenvolvimento de aplicações. Como ambiente integrado
de desenvolvimento oferece inúmeras facilidades e possibilita o uso extensivo de
plugins que automatizam algumas tarefas de desenvolvimento e gestão de recursos.
Dos plugins utilizados destaca-se o JBoss Tools por apresentar um conjunto
de ferramentas da JBoss especializadas para o desenvolvimento de aplicações web
e corporativas em Java, dentre as quais pode-se citar:
- Hibernate Tools: ferramentas para se trabalhar com o framework ORM
Hibernate;
- Seam Dev Tools: ferramentas para se trabalhar com Seam framework;
49
- Visual Web Tools: editor visual que permite trabalhar com qualquer
tecnologia web, tais como JSF (suporte a Richfaces), Seam, JSP, HTML e outros;
- JBoss Server Manager: ferramentas para gerenciamento do servidor de
aplicações JBoss;
- JSF Tools: ferramentas para desenvolvimento JSF;
- entre outras.
A versão utilizada neste projeto foi o Eclipse Juno SR1.
Figura 17 - IDE Eclipse Juno SR1
5.1.5 IREPORTS E JASPERREPORTS
O framework JasperReports foi a escolha para a produção de relatórios. Esta
ferramenta tem sido largamente utilizada para geração de relatórios em aplicações
Java. O iReports é uma ferramenta visual para a edição de relatórios baseados em
JasperReports. Este conjunto possibilita a geração dos documentos não somente no
formato PDF, mas também RTF, HTML, XML, XLS, etc
A versão utilizada deste conjunto de ferramentas foi a 5.0.1.
Figura 18 - iReport 5.0.1
50
Por fim, convém ressaltar que este conjunto de ferramentas permite o
desenvolvimento de aplicações corporativas em seus mais diversos níveis de
complexidade. O ambiente de desenvolvimento configurado dessa forma possibilita
e atende todas as necessidades da aplicação proposta.
5.2 Levantamento de Requisitos
O levantamento de requisitos foi realizado in loco na Associação de Classe no
dia 19 de abril de 2013 com a participação dos principais stakeholders, a saber o
presidente da associação, o presidente do sindicado e os servidores do setor
administrativo.
Para elicitação dos requisitos foram utilizadas as seguintes técnicas:
a) Levantamento orientado a Ponto de Vista: neste modelo os stakeholder
informaram seu interesse no sistema seguindo seu próprio ponto de vista, os quais
foram utilizados para estruturar e organizar o processo de levantamento e os
próprios requisitos. As seguintes fases foram seguidas:
- Brainstorming
- Estruturação da idéias
- Documentação
b) Etnografia: Com esta técnica foi possível compreender os requisitos
sociais e organizacionais através da inserção do analista no cenário onde o sistema
será utilizado e os requisitos foram levantados.
c) Entrevista: Com a anuência do presidente da associação foram realizadas
entrevistas com os servidores do setor administravo, que serão os principais
usuários do sistema, para que elicitassem as funcionalidades desejadas e se
concordavam com aquilo que já havia sido proposto por outros colegas.
d) Análise de documentos: Os stakeholders a todo momento apresentaram
documentos e planilhas que realizavam os controles de forma manual. Tais
documentos foram analisados e considerados na elicitação dos requisitos.
Todo este trabalho está consolidado nos apêndices A, B e C, denominados
“Especificação dos requisitos funcionais”, “Especificação dos requisitos nãofuncionais” e “Regras de Negócio”, respectivamente.
Concluido os documentos foram submetidos a apreciação dos stakeholders
na pessoa do presidente da associação. No dia 22 de abril de 2013, o documento foi
revisado, realizado alguns ajustes e finalizado.
51
5.3 Modelagem do Sistema
A modelagem de um software é a atividade de construir modelos que
expliquem as características ou o comportamento de um software. Para isso podem
ser usados modelos gráficos na identificação das características e funcionalidades
que o software deverá prover (análise de requisitos), e no planejamento de sua
construção.
NOGUEIRA(2009) bem explica a utilização da modelagem na análise de
requisitos:
O princípio básico da análise de requisitos é identificar
e documentar o que é realmente necessário, desta
forma comunicando a todos os envolvidos no projeto da
forma mais clara possível, de maneira não-ambígua de
modo que os riscos sejam identificados sem correr riscos
de imprevistos (Nogueira,2013). (Grifo nosso)
Segundo a IEEE (1990), a análise de requisitos é um processo que envolve o
estudo das necessidades do usuário para se encontrar uma definição correta
ou completa do sistema ou requisito de software.
Estes modelos gráficos que simbolizam os artefatos dos componentes de
software utilizados e os seus interrelacionamentos servirão justamente para
encontrar, identificar e documentar tais requisitos. A modelagem de programas
orientados a objeto normalmente usa a linguagem gráfica UML.
Através do desenvolvimento dos diagramas de Caso de Uso e do diagrama
de Classe da UML foram delimitadas as funcionalidades, a estrutura e as relações
dos componentes da aplicação proposta.
5.3.1 DIAGRAMA DE CASO DE USO
O diagrama de caso de uso define as funcionalidades propostas para sistema
baseado no levantamento de requisitos.
No apêndice D está disposto o diagrama de caso de uso proposto para a
Associação de Classe.
No apêndice E estão as especificações do caso de uso nas quais encontramse os cenários principais e alternativos de cada funcionalidade.
5.3.2 DIAGRAMA DE CLASSE
O diagrama de classe exibe de forma estática a estrutura e relação entre as
classes. O diagrama de classe extraído a partir da análise das funcionalidades
requeridas está disposto no apêndice F.
52
5.4 Implementação
A implementação do projeto foi realizada utilizando o Eclipse IDE com plugin
JBoss Tools em razão das facilidades que oferece, permitindo, assim, maior
produtividade. A utilização deste plugin também facilita o uso do JBoss AS,
agilizando as tarefas de Build e Deploy nesta fase de desenvolvimento.
O JBoss Seam também disponibiliza em seu framework a ferramenta SeamGen que realiza todas estas tarefas de modo simplificado e permite a criação de
templates automatizados, configuração do web.xml e demais configurações
necessárias.
Com o ambiente configurado foi criado um novo projeto utilizando o plugin
JBoss Tools através da opção: New Seam Web Project como se observa na figura a
abaixo.
Figura 19 - Criação de Seam Web Project com o plugin JBoss Tools
Com isso, o Eclipse IDE cria a estrutura básica de diretórios já incluindo as
bibliotecas necessárias, conforme figura a seguir.
53
Figura 20 - Estrutura de pacotes
Neste projeto optou-se pelo uso de componentes Seam puros ao invés do
uso de EJB 3. Isso permite que a aplicação seja empacotada em um arquivo .war,
porém requer o uso de um conteiner Java EE completo mesmo não utilizando EJB
em razão de outras funcionalidades como o JTA.
Neste projeto também é feito uso extensivo de um serviço central para todas
as ações de persistência, o EntityManager. Este ficará responsável pelo
mapeamento objeto-relacional e proverá as API’s necessárias para consultas,
sincronização, insersão, atualização e exclusão de objetos no banco de dados. O
EntityManager se integra ao JTA no controle das transações. Para tanto, o
EntityManager utiliza o arquivo persistence.xml para definir as unidades de
persistências e a forma pela qual se conectará ao banco de dados.
Outro arquivo de configuração muito poderoso na arquitetura Seam é o
components.xml, pois ele permite a configuração de componentes que devem ser
inicializados automaticamente sem a necessidade de serem anotados com a
anotação @Name. Neste projeto é necessário que EntityManager seja um
componente automaticamente inicializado para que possa ser utilizado pelos
backing beans e demais componentes. Assim o components.xml deve conter a
seguinte entrada:
54
<persistence:managed-persistence-context
name="entityManager" auto-create="true" persistence-unit-jndi
name="java:/amdepolEntityManagerFactory"/>
<persistence:entity-manager-factory name="entityManagerFactory"
persistence-unit-name="amdepol" installed="false"/>
Dessa forma é possível injetar o componente entityManager utilizando a
anotação @In.
Uma vez compreendido a razão e a configuração destes arquivos é possível
dar início a codificação das classes.
O trabalho agora é a implementação dos Entity Beans. Aspecto importante a
ser destacado neste ponto é que as classes são anotadas com a anotação @Entity
o qual define o POJO como um Entity Bean. A anotação do JBoss Seam @Name
deve também ser acrescentada para que esta classe se transforme em um
componente Seam e permita o vínculo automático com componentes JSF. Convém
ressaltar que a anotação @Name não é completamente automática. Para que o Seam
processe essas anotações é preciso incluir um arquivo seam.properties (vazio,
conforme o caso) na raiz do projeto. Dessa forma, o Seam irá varrer o projeto em
busca desses componentes.
Os Entity Beans foram criados conforme especificação contida no diagrama
de classe do apêndice F. Abaixo segue um trecho de código da classe Pessoa.java.
O código completo podem ser visto no apêndice H que contém todo código fonte da
aplicação.
@Entity
@Table(name="PESSOA",
uniqueConstraints=@UniqueConstraint(columnNames="PES_NOME"))
@Name("pessoa")
@Inheritance(strategy=InheritanceType.JOINED)
@SequenceGenerator(name="SEQ_ID_PESSOA",
sequenceName="SEQ_ID_PESSOA", allocationSize=1, initialValue=1)
public class Pessoa implements Serializable{
...
}
Depois de criadas todas as Entity Beans, o passo seguinte é a criação dos
componentes de negócio. O próprio Seam se responsabiliza em integrar estes
componentes com a camada de visão (JSF). O interessante é que este componente
pode ser puramente Seam ou também um Session Bean EJB 3, que não é o caso.
Estes componentes nada mais são que Managed Beans e Backing Beans,
contudo, é necessário que estas classes trabalhem dentro de um contexto. O JSF
dispõe de recursos limitados neste sentido, ao passo que o Seam extende suas
possibilidades quando acrescenta dois conceitos extremamente importantes à
solução: o contexto de conversação e a Bijeção.
55
Pode-se considerar que o cadastro, edição ou exclusão de um associado é
uma conversação. Isto porque para realização dessas ações necessita-se de um
escopo menor que a sessão e maior que um simples evento. Para tanto, o Seam
possibilita o uso da anotação @Scope(ScopeType.CONVERSATION)para definir o
escopo de conversação. É Importante destacar as anotações @Begin e @End,
responsáveis pelo início e fim da conversação, respectivamente.
Estas funcionalidades do Seam foram amplamente utilizadas no projeto como
se vê no trecho de código da classe AssociadoAction.java.
@Name("associadoAction")
@Scope(ScopeType.CONVERSATION)
public class AssociadoAction{
...
@Begin(join=true)
public String novo(){
setAssociado(new Associado());
return ("editarAssociado");
}
@End
public String salvar(){
try{
associado = entityManager.merge(associado);
entityManager.flush();
facesMessages.add("#{messages.salvaSucesso}");
return "mostrarAssociado";
}catch (PersistenceException e) {
facesMessages.add("#{messages.duplicidade}");
return null;
}
}
...
}
Utilizando a anotação @Scope(ScopeType.CONVERSATION fica definido
qual o escopo do componente. Ao ser acionado o método public String novo()
a conversação é inicada e ao clicar em public String salvar()é encerrada.
Não são somente estas anotações que tem poderes para iniciar e finalizar
uma conversação. O Seam também dispõe de outros componentes com a mesma
possibilidade, porém serão exemplificados mais a frente.
A bijeção também é outro ponto forte do Seam, pois possibilita atualizações
dinâmicas de um componente. Quando foram criados os Entity Bean, estes foram
anotados com a anotação @Name, o que os transformou em componentes Seam.
Com isso, agora é possível aplicar o conceito da bijeção, mantendo o componente
sempre atualizado e possibilitando o acesso pela página JSF diretamente mapeando
o Entity Bean, não sendo mais necessária sua instância no Managed Bean como
acontece no JSF puro.
56
Possibilita ainda, que outros componente que estejam disponíveis sejam
injetados na instância da classe simplesmente utilizando a anotação @In, como se
vê na injeção do componente EntityManager e FacesMessages.
@Name("associadoAction")
@Scope(ScopeType.CONVERSATION)
public class AssociadoAction{
public AssociadoAction() {
}
@In
private EntityManager entityManager;
@In(required=false)
private EnderecoList enderecoList;
@In
private FacesMessages facesMessages;
@In(required=false, create=true)
@Out(required=false)
private Associado associado;
...
}
Na definição do atributo associado foi utilizado o conceito da bijeção, o qual
possibilita que o componente Seam “associado" esteja sempre atualizado, mesmo
que tenha sido alterado por outra classe ou mesmo esta classe promova a alteração.
Para tratar e controlar valores clicáveis apresentados em componentes do
tipo
dataTable
o
Seam
dispõe
das
anotações
@DataModel
e
@DataModelSelection que podem ser utilizadas em List, Map, Set ou Object[].
Um List anotado com @DataModel funciona com o mesmo princípio da
bijeção, possibilitando que o valor clicado quando exibido em um dataTable seja
injetado por um objeto anotado com @DataModelSelection, como no exemplo
extraído da classe AssociadoAction.java.
@DataModel
private List<Associado> associados;
@DataModelSelection
private Associado associadoSelecionado;
Figure 21 - componente dataList
57
A criação das páginas JSF segue o mesmo padrão das aplicações JSF com
destaque ao uso de componentes específicos do Seam Framework, Richfaces e
Facelets.
Nesta aplicação foi utilizado o template padrão gerado pelo Seam-Gen
utilizando facelets e aplicadas as adaptações necessárias. Estas páginas já vem
com o namespace correspondente configurado como se vê abaixo:
<!DOCTYPE
composition
PUBLIC
"-//W3C//DTD
XHTML
Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1transitional.dtd">
<ui:composition xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:s="http://jboss.org/schema/seam/taglib"
xmlns:rich="http://richfaces.org/rich"
xmlns:a4j="http://richfaces.org/a4j"
template="/layout/template.xhtml" >
<ui:define name="body">
...
1.0
A partir da daí é possível o uso dos diversos recurso que os frameworks
disponibilizam, como nos trechos de código abaixo da página Associado.xhtml:
<h:outputLabel value="Data de Nascimento:" />
<h:column >
<rich:calendar id="dt_nascimento" showWeeksBar="false"
value="#{associado.dtNascimento}" locale="pt_BR" popup="true"
datePattern="dd/MM/yyyy" enableManualInput="true"
inputClass="maskDate" inputSize="20"/>
<rich:jQuery id="mskDataN" selector=".rf-cal-inp" timing="domready"
query="mask('99/99/9999',{placeholder:'_'})" />
</h:column>
<h:message for="dt_nascimento" errorClass="errors"/>
No exemplo acima foi utilizado o componente <rich:calendar> do
RichFaces para criação do campo Data de Nascimento e do componente
<rich:jQuery> para invocar a biblioteca do jQuery para formatação do campo.
Figure 22 - Componente rich:calendar
58
<h:outputLabel value="Sexo:" />
<h:selectOneRadio id="sexo" value="#{associado.sexo}"
required="true">
<f:selectItems value="#{comboSexo}" var="sex"
label="#{sex.descricao}"/>
<s:convertEnum />
</h:selectOneRadio>
<h:message for="sexo" errorClass="errors"/>
No trecho acima uma tag Seam foi utilizada junto com o componente
<h:selectOneRadio> com a finalidade de invocar um converter do Seam
Framework, poupando o programador da implementação de um converter que o
caso requer.
Figure 23 – Componente usando s:convertEnun
<rich:list id="listDocumentos" var="doc"
value="#{associado.documentos}" >
<a4j:commandLink onclick="return confirm('Confirma?');”
action="#{associadoAction.remDocumento(doc)}
render="listDocumentos" immediate="true">
<h:graphicImage value="/img/limpar.png"/>
</a4j:commandLink>
<h:outputText
<h:outputText
<h:outputText
<h:outputText
value="#{doc.tipoDocumento.descricao}"/>
value="#{doc.numero}"/>
value="#{doc.orgaoEmissor}" />
value="#{doc.uf.sigla}"
rendered="#{not empty doc.uf.sigla}"
/>
</rich:list>
Nesse trecho obseva-se o uso de recursos Ajax da biblioteca do RichFaces,
na qual uma lista de valores é exibida. Um link com uma imagem possibilita a
exclusão de valores da lista e atualização automática da lista. Isto acontece por meio
de chamadas Ajax sem o reload da página.
Figure 24 – Componente a4j:commandLink
Ao longo do projeto foram inúmeros os usos de tags oriundas das bibliotecas
do Seam e do RichFaces. Abaixo um último exemplo que permite a finalização do
escopo de conversação através de um link.
59
<s:link id="menuAssociado" action="manterAssociado" value="PESSOAS"
rendered="#{identity.loggedIn}" propagation="none" style="textdecoration: none; color:black"/>
Este código foi utilizado no arquivo menu.xhtml e exemplifica, mais uma vez,
o uso de uma tag Seam, no caso para criação de um link. O componente
<s:link>, assim como o <s:button>, tem a possibilidade de encerrar, iniciar ou
juntar conversações. No caso em pauta está impedindo a propagação da
conversação findando-a. Consequentemente, a partir deste momento nenhum
componente disponível na conversação poderá ser mais utilizado.
Figure 25 - Menu
A navegação entre as páginas no JBoss Seam fica por conta do arquivo
pages.xml que recebe o retorno dos métodos de ação contidos nos managed beans.
Este mesmo trabalho é realizado pelo faces-config.xml no JSF, contudo o Seam
dispõe de recursos mais avançados.
Um trecho do pages.xml pode ser visto abaixo gerenciando a navegação da
página Associado.xhtml.
<page login-required="true" view-id="/Associado/Associado.xhtml">
<action execute="#{redirect.captureCurrentView()}"/>
<navigation>
<rule if-outcome="manterAssociado">
<redirect view-id="/Associado/ManterAssociado.xhtml"/>
</rule>
<rule if-outcome="mostrarAssociado">
<redirect view-id="/Associado/AssociadoView.xhtml"/>
</rule>
</navigation>
</page>
Neste mesmo arquivo o Seam é capaz de fazer o tratamento de exceções,
como destacado no código abaixo:
<exception class="org.jboss.seam.framework.EntityNotFoundException">
<redirect view-id="/error.xhtml">
<message severity="warn">Registro não encontrado</message>
</redirect>
</exception>
<exception class="javax.persistence.EntityNotFoundException">
<redirect view-id="/error.xhtml">
<message severity="warn">Registro não encontrado</message>
</redirect>
</exception>
<exception class="javax.persistence.EntityExistsException">
<redirect view-id="/error.xhtml">
<message severity="warn">Registro duplicado</message>
</redirect>
</exception>
60
Pode-se dizer que estes são recursos chaves do Seam Framework, que faz
com que ele se destaque dos demais frameworks para desenvolvimento web. Porém
não esgota suas possibilidades. Os exemplos se repetem inúmeras vezes na
aplicação para associação de classe. Não convém aqui ficar replicando código, pois
dessa forma o texto ficaria muito extenso.
No apêndice H é possível observar o código fonte da aplicação com inúmeros
pontos onde os conceitos do Seam Framework foram aplicados.
5.5 Avaliação e discussão
Após conhecer as possibilidades do Seam Framework fica evidente que a
produtividade no desenvolvimento vai aumentar, primeiramente porque o conceito
inicial do Seam Framework é de simplificar a tarefa do programador. Durate a
implementação da aplicação para a associação de classe foi possível perceber que
com o JBoss Seam muitas tarefas foram simplificadas comparadas com outras
ferramentas produtivas como o próprio JavaServer Faces.
O JBoss Seam já trás no framework uma série de conversores
implementados, como é o caso do s:convertEntity e do s:convertEnun que
de outra sorte deveria ser implementado.
A boa integração com o JPA através do EntityManager e JTA e os conceitos
oriundos da implentação dos EntityBeans possibilitaram a criação da camada de
persistência de forma muito rápida. Além disso, as operações de insersão, edição,
exclusão e consulta de dados ficou simplificada e flexível.
Com a integração com o RichFaces o desenvolvimento de interfaces ricas
ficou simples, visto que além dos componentes já existentes no JSF, o framework
acrescentou componentes outrora vistos somente em aplicações desktop. Tudo isso
sem contar dos demais componentes visuais do Seam que possibilitaram integração
diretamente com a camada de negócio.
Todos estes conceitos foram possíveis de serem aplicados e trouxeram um
ganho muito grande no desenvolvimento da aplicação, pois foi possível preocuparse de fato com as regras de negócio ao invés da implementação de componentes de
baixo nível.
Ainda avaliando o uso do Seam, na versão 2.3.0.Final do JBoss Seam
utilizando JSF 2.0 e JPA 2 as requisições Ajax são nativas e isto possibilitou ainda
mais performance nas aplicações, sem dizer que o JBoss AS 7.1 também evoluiu
bastante em relação as versões anteriores de forma a carregar os serviços sob
demanda e iniciar os serviços em pouco mais de 5 segundos.
Por fim, a integração do JBoss Seam com as demais tecnologias se efetivou
de forma muito simples, sem muitas configurações de ambiente e trouxe um
resultado que pode ser dizer muito positivo em termos de produtividade no
desenvolvimento, consistência na gerência dos dados, transações e performance
nas operações. Tudo isso de modo a atender todos os requisitos não funcionais
discriminados na fase de projeto.
61
6 CONCLUSÃO
Em um mundo em que quase todas as informações estão disponíveis na web
não seria diferente se as aplicações corporativas também estivessem. Ao longo
deste trabalho foram abordados aspectos relacionados ao desenvolvimento de uma
aplicação para web – um projeto web com vistas a realizar uma apresentação e um
estudo sobre o Seam Framework.
O JBoss Seam é oriundo da plataforma Java EE que tem suas origens no
J2EE, quando ainda as aplicações web eram desenvolvidas puramente utilizando
servlets. Razão pela qual no primeiro capítulo de conteúdo foi realizada uma revisão
teórica sobre a plataforma Java EE, seus componentes e tecnologias envolvidas.
Conhecendo o Java EE é possível perceber que não existe coesão nas
soluções empregadas para o desenvolvimento de uma aplicação web java, razão
pela qual o programador precisa deter conhecimento sobre várias tecnologias além
de implementar muito código da camada de negócio.
Deste fato, surge o Seam Framework em um momento em que se
despontavam outras soluções para desenvolvimento web mais atrativas do que
usando Java EE (2005). O Seam veio promover uma arquitetura unificada de
componentes utilizando o que tem de melhor no Java EE e agregando
funcionalidades. Por isso, ele é um framework Java EE.
Conhecer o Java EE permitiu, então, compreender a frase que diz que o
“JBoss Seam extende o Java EE”, pois no capítulo seguinte a abordagem sobre o
Seam deixou claro a insersão de pontos chave deste novo framework: a injeção de
dependência (bijeção), novos contextos (escopos), melhor controle da
navegabilidade entre páginas, novos componentes para desenvolvimento de
interfaces, etc.
Com isso o Seam promoveu a integração da camada de negócio com a de
visão permitindo o desenvolvimento centrado no domínio de negócio, permitindo
ainda outras tecnologias serem utilizadas na camada de apresentação (Richfaces,
Primefaces, etc). Implementou um modelo unificado de componentes, onde não há
distinção entre componentes da camada de apresentação e da camada de negócios,
suporte nativo a Ajax sem a necessidade de codificação de javaScript.
Para compreender como tudo isso funciona foi implementado um projeto web
denominado Aplicação Associação de Classe com a finalidade de demonstrar a
aplicabilidade do Seam Framework e seus benefícios no desenvolvimento web.
Inicialmente, foi realizada algumas tarefas da parte de projeto como o levantamento
e análise de requisitos utilizando alguns diagramas da UML e em seguinda a
apresentação das fases da implementação, com destaque aos pontos de uso do
JBoss Seam.
A implementação do projeto web permitiu constatar os benefícios do
desenvolvimento web utilizando o Seam Framework, visto que promove o uso de
arquiteturas simples removendo camadas desnecessárias ao se utilizar
componentes textuais. Percebeu-se ainda que o Seam unifica as API’s tornando-as
mais acessíveis, funcionais e atrativas, além e prover novas funcionalidades como o
contexto de conversação, bijeção, gerenciamento de exceções, mecanismos de
logs, mensagens, etc.
62
Por fim, é possível afirmar que o Seam Framework atualmente constitui uma
excelente ferramenta para desenvolvimento web, unido inúmeros recursos, novos e
outros já conhecidos, com performance, segurança e produtividade, sendo
extremante viável seu emprego em qualquer projeto web.
Neste trabalho foram abrangidos apenas algumas funcionalidades do Seam
Framework. Em estudos futuros é aconselhável outras abordagens ao tema como o
uso de jBPM visto que este combina a facilidade de desenvolvimento de aplicações
web, aqui abordadas, com fluxos de trabalho, fluxos de processos corporativos em
um mecanismo de processo flexível e escalável. Além, também, de enfatizar o
desenvolvimento utilizando EJB 3, visto que inicialmente o Seam veio para integrar
JSF com EJB 3.
63
7 REFERÊNCIAS BIBLIOGRÁFICAS
ALLEN, Dan. Seam in Action. MEAP Edition. Manning Early Access Program, 2008.
BOND,Martin; HAYWOOD, Dan; LAW, Debbie; LONGSHAW, Andy; ROXBURGH,
Peter. Aprenda J2EE em 21 dias com EJB, JSP, Servlets, JNDI, JDBC e XML.
São Paulo: Pearson Education do Brasil, 2003.
FARLEY, Jim. Projetos Práticos com Jboss Seam. Rio de Janeiro: Editora Ciência
Moderna Ltda., 2008.
GREARY, David; HORSTMANN, Cay. Core JavaServer Faces Fundamentos. 2ª
Edição. Rio de Janeiro: Alta Books, 2007.
GUPTA, Arun. Java EE 6 – Pocket Guide. 1ª Edition. USA: O’Reilly Media, Inc.,
2012.
IEEE – Instituteof Eletricaland Eletronics Engineers. Standards Glossary of
Software Engineering Terminology: Std 610.12, N.Y.,1990. 84p.
K19 Treinamentos. Desenvolvimento Web com JSF2 e JPA2. São Paulo, 2012.
NOGUEIRA, Admilson. UML - Unified Modeling Language - Requisitos, Classes
e Objetos. Disponível em <http://www.linhadecodigo.com.br/artigo/776/uml-unifiedmodeling-language-requisitos-classes-e-objetos.aspx>. Acesso em 03 de junho de
2013.
OLIVEIRA, Eric C. M. Conhecendo a Plataforma J2EE – Um Breve Overview.
Disponível
em
<http://www.linhadecodigo.com.br/artigo/333/conhecendo-aplataforma-j2ee-um-breve-overview.aspx>. Acesso em 15 de maio de 2013.
ORACLE. The Java EE 6 Tutorial. Redwookd CA USA, 2013. Disponível em <Fonte:
http://docs.oracle.com/javaee/6/tutorial/doc/bnaay.html#bnabj>. Acesso em 27 de
maio de 2013.
ORSHALICK, Jacob. SeamUI.
Disponível em <http://refcardz.dzone.com/refcardz/seam-ui>. Acesso em 01 de
junho de 2013.
PACHECO, Juliano. Entendendo os Escopos no JSF (JavaServer Faces) – 2013.
Disponível
em
<http://www.pletax.com/2013/02/entendendo-os-escopos-no-jsfjavaserver-faces/>. Acesso em 15 de maio de 2013.
PITANGA, Talita. JavaServer Faces: A mais nova tecnologia Java para
desenvolvimento WEB.
64
Disponível em <http://www.guj.com.br/content/articles/jsf/jsf.pdf>. Acesso em 15 de
maio de 2013.
PRADO, Alexandro do Anjos. JEE – Um Caminho Prazeroso e Interessante.
Disponível
em
<http://www.devmedia.com.br/jee-um-caminho-prazeroso-einteressante/3747>. Acesso em 15 de maio de 2013.
PRATO, Benjamin. A la découverte de Java EE 7 – 2013. Disponível em
<http://marseille.labo-java.net/2013/02/18/a-la-decouverte-de-java-ee-7/>.
Acesso
em 15 de maio de 2013.
RAHMAN,
Reza.
Java
EE
Overview
–
2009.
Disponível
em
<http://www.theserverside.com/news/1363662/Java-EE-6-Overview>. Acesso em 15
de maio de 2013.
RICHFACES. The Next-Generation JSF Component Framework by JBoss.
Disponível em <http://www.jboss.org/richfaces>. Acesso em 01 de junho de 2013.
SALTER, David. Seam 2.x Web Development - Build Robust Web Applications
with Seam, Facelets, and RichFaces, using the JBoss Application Server.
Olton-UK: Packt Publishing Ltd., 2009.
SANTANA, Otávio Gonçalves de. Introdução Java EE 6. Disponível em
<http://www.devmedia.com.br/introducao-java-ee-6/21364>. Acesso em 15 de maio
de 2013.
SPOCK. Sobre os contextos do JBoss Seam – 2008. Disponível em
<http://blog.spock.com.br/2008/07/sobre-os-contextos-do-jboss-seam.html>. Acesso
em 20 de maio de 2013.
STORI, Daniel Augusto. Uma Breve História dos Patterns (JEE) – 2010.
Disponível em <http://coliriodamente.wordpress.com/2010/09/02/uma-breve-historiados-patterns-jee/>. Acesso em 15 de maio de 2013.
TARANTULA CONSULTING. RichFaces Tag Reference. Disponível em
<http://www.jsftoolbox.com/documentation/richfaces/09-TagReference/index.jsf>.
Acesso em 08 de junho de 2013.
VINICIUS, Samuel. Conheça o ciclo de vida do JSF – 2013. Disponível em
<http://imasters.com.br/linguagens/java/conheca-o-ciclo-fe-vida-do-jsf/>. Acesso em
13 de maio de 2013.
APÊNDICE A
ESPECIFICAÇÃO DE REQUISITOS FUNCIONAIS
ASSOCIAÇÃO DE CLASSE
Versão: 1.0
Data: 19/04/2013
LRF01
Histórico da Revisão
Data
Versão
Descrição
Autor
19/04/2013
1.0
Levantamento de requisitos in
RICARDO R BARCELAR
loco na sede da Associação
22/04/2013
1.1
Revisão pelo stakeholder
1.
RICARDO R BARCELAR
Introdução
Considerando a necessidade de levantar os requisitos funcionais da aplicação
web foi realizada uma visita à sede da associação de classe no dia 19 de abril de
2013.
Inicialmente foi realizada uma apresentação pelo presidente da associação o
qual explicou o que era a “Associação de Classe”: Esta congrega pessoas e
interesses de uma classe de servidores públicos do Estado de Mato Grosso e está
sediada em Cuiabá/MT. Coloca a disposição de seus associados uma ampla área
de lazer, hotel e áreas para eventos privados – área de churrasqueira, salão de
festas, campo de futebol, etc. Para manter em funcionamento toda a estrutura a
associação mantém um grupo de funcionários responsáveis por cuidar da área
administrativa, jardinagem, limpeza e manutenção (serviços gerais). No local
também funciona o sindicato da classe que utiliza o mesmo cadastro de associados
mantido pela associação.
Com isso, ficou claro que o domínio de negócio seria uma aplicação web que
realizasse o controle dos associados como função principal e dispusesse das
seguintes
funcionalidades:
controle
de
fornecedores,
cadastro
de
funcionários(colaboradores), controle de patrimônio, agenda para uso das áreas
privativas, controle das hospedagens no hotel, agenda de contatos, geração de
relatórios em PDF e possibilidade do sistema enviar mensagens eletrônicas (e-mail)
a seus associados. Além disso, a aplicação deveria possibilitar o acesso via web
(utilizando um navegador) de modo a não ficar preso a instalação da aplicação nos
computadores e possibilitasse seu acesso externo (fora da sede da associação).
Uma vez definido o domínio do negócio, foram aplicadas as seguintes
técnicas de levantamento de requisitos:
- Levantamento orientado a ponto de vista;
- Etnografia;
- Entrevista; e
- Análise de documentos.
Os stakeholders, presidente da Associação, Presidente do Sindicado e
servidores do setor administrativo da Associação de Classe participaram
efetivamente da elicitação dos requisitos funcionais.
Inicialmente, foi realizada uma reunião na qual os stakeholders informaram
aquilo que entendiam ser importante constar na aplicação através da técnica de
Brainstorming. Isto feito, os requisitos foram organizados e estão populados neste
documento.
Findada a reunião, passou-se a observação da rotina de trabalho através da
inserção no ambiente de trabalhos dos servidores do setor administrativo com fito a
compreender os requisitos sociais e organizacionais da instituição (Etnografia).
Em seguida, algumas entrevistas foram realizadas de forma individual com os
servidores do setor administrativo com o intuito de refinar as idéias e as
necessidades da aplicação com vistas a atender as necessidades de controle dos
serviços oferecidos pela associação. Durante a entrevista foram coletados
formulários que servirão de orientação para criação da base dados, ou seja, os
dados a serem manipulados.
1.1
Objetivo
Elicitar os requisitos funcionais de uma aplicação web para a Associação de
Classe.
1.2
Público Alvo
- Analista de sistema responsável pelo desenvolvimento
- Stakeholders
1.3
Referências
- Ficha de cadastro dos associados
- Ficha de cadastro de funcionários
- Ficha de controle de hospedagem
- Livro de patrimônio
- Planilha contendo relação de fornecedores
- Planilha contendo relação de instituições
2.
Requisitos Funcionais
RF_01: Manter cadastro dos associados – Manter uma relação completa dos
associados incluindo nos dados cadastrais endereços, telefones e e-mail’s.
•
Fonte da Informação: Stakeholders
•
Prioridade: [X] Essencial
[ ] Importante [ ] Desejável
RF_02: Manter vinculado aos associados seus dependentes – Manter uma
relação de dependentes para aqueles associados que o possuem.
•
Fonte da Informação: Stakeholders
•
Prioridade: [X] Essencial
[ ] Importante [ ] Desejável
RF_03: Manter o status do associado – Manter a informação de status do
associado em relação ao seu vínculo com a Associação de Classe e o
Sindicato, assim como em caso de pensionista o vínculo com o associado
falecido.
•
Fonte da Informação: Stakeholders
•
Prioridade: [X] Essencial
[ ] Importante [ ] Desejável
RF_04: Manter fotos do associados – Manter armazenado no cadastro do
associado a foto do mesmo.
•
Fonte da Informação: Stakeholders
•
Prioridade: [ ] Essencial
[X] Importante [ ] Desejável
RF_05: Manter cadastro de fornecedores – Manter um cadastro de
fornecedores que prestam serviços a associação. Neste cadastro deverão
constar os telefones, bem como o nome dos contatos nas empresas.
•
Fonte da Informação: Stakeholders
•
Prioridade: [ ] Essencial
[X] Importante [ ] Desejável
RF_06: Manter cadastro dos colaboradores – Manter um cadastro com os
dados de todos os colaboradores (servidores) da associação de modo a fazer
constar os documentos pessoais, função e horário de trabalho.
•
Fonte da Informação: Stakeholders
•
Prioridade: [X] Essencial
[ ] Importante [ ] Desejável
RF_08: Manter controle de hospedagens no hotel – Manter um controle das
pessoas (normalmente associados) hospedados no hotel de trânsito da
associação. Neste controle deverão constar os dados do hóspede e seus
acompanhantes, bem como informação de maioridade com o respectivo
documento de identificação. Deverá, ainda, ser possível realizar
agendamentos de apartamentos para datas futuras.
•
Fonte da Informação: Stakeholders
•
Prioridade: [X] Essencial
[ ] Importante [ ] Desejável
RF_09: Manter cadastro de outras instituições de classe – Manter um
cadastro de outras instituições de classe, bem como de instituições parceiras
de interesse. Neste cadastro deverão constar endereço, telefone para contato
e os dados dos respectivos representantes.
•
Fonte da Informação: Stakeholders
•
Prioridade: [X] Essencial
[ ] Importante [ ] Desejável
RF_10: Manter o controle do patrimônio – Manter um controle de todos bens
permanentes da associação com a qualificação completa do material, estado
de conservação, distribuição e atribuição de um identificador único e numérico
a ser denominado de “Número de Patrimônio”.
•
Fonte da Informação: Stakeholders
•
Prioridade: [X] Essencial
[ ] Importante [ ] Desejável
RF_11: Enviar e-mail – O sistema deverá possibilitar o envio de e-mail em
massa para os associados cadastrados no sistema. Para tanto, o sistema
deve possibilitar a seleção do conjunto de destinatários filtrando-os por
aposentados, ativos, pensionistas, etc.
•
Fonte da Informação: Stakeholders
•
Prioridade: [ ] Essencial
[X] Importante [ ] Desejável
RF_12: Enviar SMS – O sistema deve possibilitar o envio de SMS em massa
para os associados cadastrados no sistema. Para tanto, o sistema deve
possibilitar a seleção do conjunto de destinatários filtrando-os por
aposentados, ativos, pensionistas, etc. Deve permitir ainda o agendamento de
mensagens para datas especiais, como por exemplo, o aniversário do
associado.
•
Fonte da Informação: Stakeholders
•
Prioridade: [ ] Essencial
[ ] Importante [X] Desejável
RF_13: Manter Agenda – Manter uma agenda que possibilite o controle dos
compromissos da associação, bem como as reservas de espaços privados
dentro do clube, tais como campo de futebol, áreas de churrasqueira e salão
de festas.
•
Fonte da Informação: Stakeholders
•
Prioridade: [ ] Essencial
[X] Importante [ ] Desejável
RF_14: Emissão de relatórios – O sistema deve possibilitar a emissão de
relatórios, em especial com referência a situação dos associados e dados das
funcionalidades: Agenda, Servidores, hospedagem, patrimônio, etc.
•
Fonte da Informação: Stakeholders
•
Prioridade: [ ] Essencial
[X] Importante [ ] Desejável
RF_15: Emissão de etiquetas de endereçamento – O sistema deve
possibilitar a emissão de etiquetas do tipo PIMACO para endereçamento de
envelopes. Deverão ser contemplados dois tipos de endereçamento: um com
o endereço residencial do associado e outro com o endereço funcional (do
local de trabalho).
3.
•
Fonte da Informação: Stakeholders
•
Prioridade: [ ] Essencial
[ ] Importante [X] Desejável
Definições, acrônimos e abreviações
Prioridade dos requisitos:
•
Essencial: indica que o requisito é imprescindível para o funcionamento
do sistema. Requisitos essenciais devem ser implementados desde as
primeiras iterações do desenvolvimento construção do sistema.
Importante: indica que o requisito não é essencial para o
funcionamento do sistema, contudo seu funcionamento, sem
implementação do requisito, se torna insatisfatório. Requisitos
importantes devem ser implantados o mais rápido possível, porém não
impede que apenas parte do sistema seja implantada.
• Desejável: indica que o requisito não compromete as funcionalidades
básicas do sistema, podendo funcionar de forma satisfatória sem ele.
Requisitos desejáveis podem ser implantados por último, sem
comprometer o funcionamento do sistema.
•
APÊNDICE B
ESPECIFICAÇÃO DE REQUISITOS NÃO-FUNCIONAIS
ASSOCIAÇÃO DE CLASSE
Versão: 1.0
Data: 19/04/2013
LRNF01
Histórico da Revisão
Data
Versão
Descrição
Autor
19/04/2013
1.0
Levantamento de requisitos in
RICARDO R BARCELAR
loco na sede da Associação
22/04/2013
1.1
Revisão pelo stakeholder
1.
RICARDO R BARCELAR
Introdução
Considerando a necessidade de levantar os requisitos não-funcionais da
aplicação web foi realizada uma visita à sede da associação de classe no dia 19 de
abril de 2013.
Inicialmente foi realizada uma apresentação pelo presidente da associação o
qual explicou o que era a “Associação de Classe”: Esta congrega pessoas e
interesses de uma classe de servidores públicos do Estado de Mato Grosso e está
sediada em Cuiabá/MT. Coloca a disposição de seus associados uma ampla área
de lazer, hotel e áreas para eventos privados – área de churrasqueira, salão de
festas, campo de futebol, etc. Para manter em funcionamento toda a estrutura a
associação mantém um grupo de funcionários responsáveis por cuidar da área
administrativa, jardinagem, limpeza e manutenção (serviços gerais). No local
também funciona o sindicato da classe que utiliza o mesmo cadastro de associados
mantido pela associação.
Com isso, ficou claro que o domínio de negócio seria uma aplicação web que
realizasse o controle dos associados como função principal e dispusesse das
seguintes
funcionalidades:
controle
de
fornecedores,
cadastro
de
funcionários(colaboradores), controle de patrimônio, agenda para uso das áreas
privativas, controle das hospedagens no hotel, agenda de contatos, geração de
relatórios em PDF e possibilidade do sistema enviar mensagens eletrônicas (e-mail)
a seus associados. Além disso, a aplicação deveria possibilitar o acesso via web
(utilizando um navegador) de modo a não ficar preso a instalação da aplicação nos
computadores e possibilitasse seu acesso externo (fora da sede da associação).
Uma vez definido o domínio do negócio, foram aplicadas as seguintes
técnicas de levantamento de requisitos:
- Levantamento orientado a ponto de vista;
- Etnografia;
- Entrevista; e
- Análise de documentos.
Os stakeholders, presidente da Associação, Presidente do Sindicado e
servidores do setor administrativo da Associação de Classe participaram
efetivamente da elicitação dos requisitos não-funcionais.
Inicialmente, foi realizada uma reunião na qual os stakeholders informaram
aquilo que entendiam ser importante em termos de qualidade, confiabilidade,
portabilidade, segurança e utilidade. Isto feito, os requisitos foram organizados e
estão populados neste documento.
Findada a reunião, passou-se a observação da rotina de trabalho através da
inserção no ambiente de trabalhos dos servidores do setor administrativo com fito a
compreender as rotinas, os requisitos de segurança e aquilo que proporcionasse
maior ergonomia na utilização do software.
Em seguida, algumas entrevistas foram realizadas de forma individual com os
servidores do setor administrativo com o intuito de refinar as idéias e os requisitos da
aplicação com vistas a atender as necessidades de acesso, plataformas, locais de
acesso, bem como conhecer o nível de habilidade de uso de sistemas
computacionais por parte dos entrevistados.
1.1
Objetivos
Elicitar os requisitos não-funcionais de uma aplicação web para a Associação
de Classe.
1.2
Público Alvo
- Analista de sistema responsável pelo desenvolvimento
- Stakeholders
1.3
Referências
- Estatuto da Associação de Classe
2.
Requisitos Não-Funcionais
RNF_01: Mensagens amigáveis – O sistema deverá emitir mensagens
amigáveis em caso de uma ação incorreta ou não permitida por parte do
usuário, de forma a permitir a fácil compreensão por qualquer pessoa, assim
como a indicação das possibilidades de ação.
•
Fonte da Informação: Stakeholders
•
Prioridade: [X] Essencial
[ ] Importante [ ] Desejável
RNF_02: Acesso em múltiplas plataformas – O sistema deverá ser acessível
em qualquer tipo de sistema operacional. Foi relatado pelos stakeholders que
há a necessidade de acesso a aplicação de diferentes tipos de sistemas
operacionais e equipamentos. Isto se justifica pelo fato do presidente utilizar
computador com sistema operacionais IOS (Apple), a administração utilizar
plataforma Microsoft e não haver interesse na aquisição de licença para
servidores, que no caso utilizam Sistema Operacional Linux.
•
Fonte da Informação: Stakeholders
•
Prioridade: [X] Essencial
[ ] Importante [ ] Desejável
RNF_03: Acesso por dispositivos móveis – O sistema deverá ser acessível
em dispositivos móveis como tablets e smartphones. Isto se justifica pelo fato
da presidência necessitar de acesso aos dados da associação por meio de
seu smartphone em reuniões e eventos externos.
•
Fonte da Informação: Stakeholders
•
Prioridade: [ ] Essencial
[ ] Importante [X] Desejável
RNF_04: Restrição no acesso não autorizado – O sistema deverá dispor de
mecanismo que filtre os acessos ao sistema somente a pessoas autorizadas
pela administração. Requisitos de segurança como a criptografia da senha
são solicitados. De igual forma algumas funcionalidades deverão ter o acesso
restringido, como por exemplo, o cadastro de novos usuários no sistema..
•
Fonte da Informação: Stakeholders
•
Prioridade: [ ] Essencial
[X] Importante [ ] Desejável
RNF_05: Facilidade de uso – O sistema deverá ser ergonômico, intuitivo e
fácil de usar de modo a permitir a fácil adaptação dos usuários, facilidade no
acesso as informações e que possua o mesmo mecanismo de acesso para
todas as funcionalidades.
•
Fonte da Informação: Stakeholders
•
Prioridade: [ ] Essencial
[X] Importante [ ] Desejável
RNF_06: Cor predominante Azul – O sistema deve ter em seu design a cor
predominante azul, de modo a dar uma identidade visual com a cor da
Associação.
3.
•
Fonte da Informação: Stakeholders
•
Prioridade: [ ] Essencial
[ ] Importante [X] Desejável
Definições, acrônimos e abreviações
Prioridade dos requisitos:
•
Essencial: indica que o requisito é imprescindível para o funcionamento
do sistema. Requisitos essenciais devem ser implementados desde as
primeiras iterações do desenvolvimento construção do sistema.
•
Importante: indica que o requisito não é essencial para o
funcionamento do sistema, contudo seu funcionamento, sem
implementação do requisito, se torna insatisfatório. Requisitos
importantes devem ser implantados o mais rápido possível, porém não
impede que apenas parte do sistema seja implantada.
•
Desejável: indica que o requisito não compromete as funcionalidades
básicas do sistema, podendo funcionar de forma satisfatória sem ele.
Requisitos desejáveis podem ser implantados por último, sem
comprometer o funcionamento do sistema.
APÊNDICE C
REGRAS DE NEGÓCIO
ASSOCIAÇÃO DE CLASSE
Versão: 1.0
Data: 19/04/2013
RN01
Histórico da Revisão
Data
Versão
Descrição
Autor
19/04/2013
1.0
Levantamento de requisitos in
RICARDO R BARCELAR
loco na sede da Associação
22/04/2013
1.1
Revisão pelo stakeholder
1.
RICARDO R BARCELAR
Introdução
Este documento apresenta os requisitos de negócio da aplicação, os
quais foram levantados junto aos stakeholders e a legislação que regula o
funcionamento da associação de classe.
1.1
Objetivos
Explicitar as regras de negócio da aplicação
1.2
Público Alvo
- Analista de sistema responsável pelo desenvolvimento
- Stakeholders
1.3
Referências
- Estatuto da Associação de Classe
2.
Regras de Negócios
RN_01: Critério de Associação – Toda pessoa para se tornar associado
deverá ser funcionário público de carreira da classe a qual a associação
representa. Para tanto no cadastro do associado no sistema deverá ser
obrigatório informação sobre seu cargo e lotação.
RN_02: Critério de Associação de Pensionista – O pensionista para se tornar
associado deverá ter parentesco de 1º grau com o associado falecido e
mesmo estar associado quando do seu falecimento. No cadastro do sistema
deverá constar o vínculo do pensionista com o servidor público associado
enquanto vivo.
RN_03: Dependentes – Para ser dependente do Associado o mesmo deverá
ter parentesco de 1º grau e ter seu cadastro vinculado ao associado. Dessa
forma, poderá gozar dos benefícios de uso das áreas privativas e gozar de
alguns serviços da associação.
RN_04: Associado Benemérito – A critério dos membros da associação
poderão ser dados títulos de associados beneméritos. Tais pessoas quando
agraciadas deverão ser registradas no sistema com a qualificação de
“Associado Benemérito”.
RN_05: Informações Funcionais – Todo associado deverá manter atualizado
junto a administração da associação seus dados funcionais. Para tanto, o
sistema deverá ser capaz de armazenar informações funcionais como
matrícula, lotação, nível na carreira, data de posse e se na situação de
aposentado a data da aposentadoria.
RN_06: Condição de sindicalização – O associado poderá gozar de todos os
serviços e benefícios oferecidos pela associação de classe, mas deverá
também se sindicalizar ou não para que seus direitos sejam defendidos na
pessoa do presidente do sindicato. Dessa forma, o sistema deverá manter a
informação dos associados que são sindicalizados ou não.
RN_07: Uso das áreas privativas – O uso das áreas privativas é restrito
somente aos associados e quando reservados ao seus convidados. Dessa
forma, o sistema deverá restringir a reserva destes locais somente ao
responsável associado.
RN_08: Hospedagem no Hotel de Trânsito – A reserva e uso do hotel é
restrito somente aos associados. Este podem trazer consigo convidados
desde que membros da família devidamente identificados. Dessa forma, o
sistema deverá restringir a reserva de hospedagem somente a associados e
quando estes estiverem acompanhados deverão identificá-los e registrá-los
na reserva com um documento de identidade válido.
RN_09: Controle de Patrimônio – O presidente da associação é o responsável
pelo controle de todos os bens permanentes devendo prestar contas de todo
o acervo quando da passagem de função em razão das eleições. Para tanto,
o sistema deverá manter o controle patrimonial atribuindo um número de
patrimônio a todo bem permanente de forma individualizada permitindo a fácil
identificação e controle do acervo.
APÊNDICE D
DIAGRAMA DE CASO DE USO
APÊNDICE E
ESPECIFICAÇÃO DE CASO DE USO
NÚMERO
CASO DE USO
DESCRIÇÃO
UC001
Logar no Sistema
Usuário para acessar o sistema de dever informar usuário e
senha válidos
ATOR
Usuário
CENÁRIO PRINCIPAL
Sistema permite o acesso
1) Usuário para acessar o sistema deve informar a URL na qual será exibida a tela de login
do sistema.
2) Usuário informa, nos campos correspondentes e previamente cadastrado, seu usuário e
senha.
3) Sistema valida as informações.
4) Sistema concede acesso as funcionalidades.
5) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 1 Sistema rejeita o acesso
1) Usuário para acessar o sistema deve informar a URL na qual será exibida a tela de login
do sistema.
2) Usuário informa, nos campos correspondentes e previamente cadastrado, seu usuário e
senha.
3) Sistema invalida as informações.
4) Sistema emite a mensagem “Login inválido.”
5) Sistema exibe novamente a tela de login.
6) Sistema encerra o caso de uso.
REQUISITOS ESPECIAIS
1) O nome de usuário (login) deve ser único no sistema.
PRÉ CONDIÇÃO
Usuário deve ser previamente cadastrado no sistema.
PÓS CONDIÇÃO
Usuário acessando o sistema.
NÚMERO
CASO DE USO
DESCRIÇÃO
UC002
Manter Usuário
Caso de uso responsável por manter o cadastro de usuários do
sistema.
ATOR
Admin
CENÁRIO PRINCIPAL
Cadastrar Usuário
1) Admin realiza login e obtém acesso ao sistema.
2) Admin solicita o formulário de cadastro de usuário.
3) Sistema exibe o formulário de cadastro de usuário.
4) Admin informa os dados requeridos, bem como vincula este usuário a um funcionário.
5) Sistema verifica se há duplicidade de login.
6) Sistema exibe os dados para confirmação.
7) Admin confirma o cadastro.
8) Sistema registra o Usuário.
9) Sistema emite a mensagem “Usuário cadastrado com sucesso.”
10) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 1 Cadastrar Autor (login já existente)
1) Admin realiza login e obtém acesso ao sistema.
2) Admin solicita o formulário de cadastro de usuário.
3) Sistema exibe o formulário de cadastro de usuário.
4) Admin informa os dados requeridos.
5) Sistema verifica se há duplicidade de login.
6) Sistema detecta duplicidade de login.
7) Sistema emite a mensagem “Nome de usuário (login) existente. Informe um login
diferente.”
8) Sistema verifica se há duplicidade de login.
9) Sistema exibe os dados para confirmação.
10) Admin confirma o cadastro.
11) Sistema registra o Usuário.
12) Sistema emite a mensagem “Registro realizado com sucesso.”
13) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 2 Editar Usuário
1) Admin realiza login e obtém acesso ao sistema.
2) Admin aciona formulário de consulta de Usuários e informa o parâmetro de busca.
3) Sistema busca as informações e exibe o formulário com os dados do Usuário selecionado.
4) Sistema apresenta o resultado da consulta em uma lista.
5) Admin aciona a funcionalidade de edição do usuário.
6) Sistema carregas as informações do usuário selecionado.
7) Admin informa as alterações.
8) Sistema exibe os dados para confirmação.
9) Admin confirma as informações.
10) Sistema registra as alterações.
11) Sistema emite a mensagem “Alteração realizada com sucesso.”
12) Sistema encerra o caso de uso.
REQUISITOS ESPECIAIS
1) O nome de usuário (login) deve ser único no sistema.
2) Em caso de Edição não é permitido a alteração no nome do usuário (login).
PRÉ CONDIÇÃO
Cadastrado: Não especificado
Edição: Admin deve estar logado no sistema
PÓS CONDIÇÃO
Usuário cadastrado/alterado
NÚMERO
CASO DE USO
DESCRIÇÃO
UC003
Manter Apartamento
Caso de uso responsável por manter
apartamentos disponíveis no hotel.
ATOR
Admin
CENÁRIO PRINCIPAL
Cadastrar Apartamento
1) Admin solicita o formulário de cadastro de apartamento.
2) Sistema exibe o formulário de cadastro de apartamento.
3) Admin informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e persiste os dados.
5) Sistema emite a mensagem “Registro realizado com sucesso.”
o
cadastro
de
6) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 1 Cadastrar Apartamento (Apartamento já existente)
1) Admin solicita o formulário de cadastro de apartamento.
2) Sistema exibe o formulário de cadastro de apartamento.
3) Admin informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e detecta duplicidade.
5) Sistema emite a mensagem “Registro já existente”
6) Sistema exibe novamente o formulário de cadastro de apartamento para nova tentativa
7) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 2 Editar Apartamento
1) Admin aciona formulário de consulta de apartamento e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com o(s) apartamento(s) encontrado(s).
3) Admin aciona a funcionalidade de edição dos dados.
4) Sistema carregas as informações do apartamento selecionado.
5) Admin informa as alterações e confirma a alteração.
6) Sistema valida as informações e persiste os dados.
7) Sistema emite a mensagem “Registro realizado com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 3 Excluir Apartamento
1) Admin aciona formulário de consulta de apartamento e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com o(s) apartamento(s) encontrado(s).
3) Admin aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações do apartamento selecionado.
5) Admin clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e realiza a operação.
7) Sistema emite a mensagem “Registro excluído com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 4 Excluir Apartamento (Violação de Chave Estrangeira)
1) Admin aciona formulário de consulta de apartamento e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com o(s) apartamento(s) encontrado(s).
3) Admin aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações do apartamento selecionado.
5) Admin clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e detecta violação de chave estrangeira.
7) Sistema emite a mensagem “O registro não pode ser excluído – Vínculo existente.”
8) Sistema encerra o caso de uso.
REQUISITOS ESPECIAIS
1) O usuário deve estar logado no sistema
2) Descrição do apartamento deve ser único
PRÉ CONDIÇÃO
PÓS CONDIÇÃO
NÚMERO
CASO DE USO
DESCRIÇÃO
ATOR
CENÁRIO PRINCIPAL
UC004
Manter Situação do Associado
Caso de uso responsável por manter o cadastro de situação do
associado.
Admin
Cadastrar situação do associado
1) Admin solicita o formulário de cadastro de situação do associado .
2) Sistema exibe o formulário de cadastro de situação do associado .
3) Admin informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e persiste os dados.
5) Sistema emite a mensagem “Registro realizado com sucesso.”
6) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 1 Cadastrar situação do associado ( situação do associado já
existente)
1) Admin solicita o formulário de cadastro de situação do associado .
2) Sistema exibe o formulário de cadastro de situação do associado .
3) Admin informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e detecta duplicidade.
5) Sistema emite a mensagem “Registro já existente”
6) Sistema exibe novamente o formulário de cadastro de situação do associado para nova
tentativa
7) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 2 Editar situação do associado
1) Admin aciona formulário de consulta de situação do associado e informa o parâmetro de
busca.
2) Sistema busca as informações e exibe uma grid com a(s) situação(ões) do(s)
associado(s) encontrado(s).
3) Admin aciona a funcionalidade de edição dos dados.
4) Sistema carregas as informações da situação do associado selecionada.
5) Admin informa as alterações e confirma a alteração.
6) Sistema valida as informações e persiste os dados.
7) Sistema emite a mensagem “Registro realizado com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 3 Excluir situação do associado
1) Admin aciona formulário de consulta de situação do associado e informa o parâmetro de
busca.
2) Sistema busca as informações e exibe uma grid com a(s) situação(ões) do(s)
associado(s) encontrado(s).
3) Admin aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações da situação do associado selecionado.
5) Admin clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e realiza a operação.
7) Sistema emite a mensagem “Registro excluído com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 4 Excluir
situação do associado (Violação de Chave
Estrangeira)
1) Admin aciona formulário de consulta de situação do associado e informa o parâmetro de
busca.
2) Sistema busca as informações e exibe uma grid com a(s) situação(ões) do(s)
associado(s) encontrado(s).
3) Admin aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações da situação do associado selecionado.
5) Admin clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e detecta violação de chave estrangeira.
7) Sistema emite a mensagem “O registro não pode ser excluído – Vínculo existente.”
8) Sistema encerra o caso de uso.
REQUISITOS ESPECIAIS
1) O usuário deve estar logado no sistema
2) Descrição da situação do associado deve ser única
PRÉ CONDIÇÃO
PÓS CONDIÇÃO
NÚMERO
CASO DE USO
DESCRIÇÃO
UC005
Manter Tipo de Associado
Caso de uso responsável por manter o cadastro de tipo de
associado.
ATOR
Admin
CENÁRIO PRINCIPAL
Cadastrar tipo de associado
1) Admin solicita o formulário de cadastro de tipo de associado .
2) Sistema exibe o formulário de cadastro de tipo de associado .
3) Admin informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e persiste os dados.
5) Sistema emite a mensagem “Registro realizado com sucesso.”
6) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 1 Cadastrar tipo de associado (Tipo de associado já existente)
1) Admin solicita o formulário de cadastro de tipo de associado .
2) Sistema exibe o formulário de cadastro de tipo de associado .
3) Admin informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e detecta duplicidade.
5) Sistema emite a mensagem “Registro já existente”
6) Sistema exibe novamente o formulário de cadastro de tipo de associado para nova
tentativa
7) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 2 Editar tipo de associado
1) Admin aciona formulário de consulta de apartamento e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com o(s) tipo(s) de associado(s)
encontrado(s).
3) Admin aciona a funcionalidade de edição dos dados.
4) Sistema carregas as informações do tipo de associado selecionado.
5) Admin informa as alterações e confirma a alteração.
6) Sistema valida as informações e persiste os dados.
7) Sistema emite a mensagem “Registro realizado com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 3 Excluir tipo de associado
1) Admin aciona formulário de consulta de tipo de associado e informa o parâmetro de
busca.
2) Sistema busca as informações e exibe uma grid com o(s) tipo(s) de associado(s)
encontrado(s).
3) Admin aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações do tipo de associado selecionado.
5) Admin clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e realiza a operação.
7) Sistema emite a mensagem “Registro excluído com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 4 Excluir tipo de associado (Violação de Chave Estrangeira)
1) Admin aciona formulário de consulta de tipo de associado e informa o parâmetro de
busca.
2) Sistema busca as informações e exibe uma grid com o(s) tipo(s) de associado(s)
encontrado(s).
3) Admin aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações do tipo de associado selecionado.
5) Admin clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e detecta violação de chave estrangeira.
7) Sistema emite a mensagem “O registro não pode ser excluído – Vínculo existente.”
8) Sistema encerra o caso de uso.
REQUISITOS ESPECIAIS
1) O usuário deve estar logado no sistema
2) Descrição do tipo de associado deve ser único
PRÉ CONDIÇÃO
PÓS CONDIÇÃO
NÚMERO
UC006
CASO DE USO
Manter Turma
DESCRIÇÃO
Caso de uso responsável por manter o cadastro de turma.
ATOR
Admin
CENÁRIO PRINCIPAL
Cadastrar turma
1) Admin solicita o formulário de cadastro de turma.
2) Sistema exibe o formulário de cadastro de turma.
3) Admin informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e persiste os dados.
5) Sistema emite a mensagem “Registro realizado com sucesso.”
6) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 1 Cadastrar turma (Turma já existente)
1) Admin solicita o formulário de cadastro de turma .
2) Sistema exibe o formulário de cadastro de turma.
3) Admin informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e detecta duplicidade.
5) Sistema emite a mensagem “Registro já existente”
6) Sistema exibe novamente o formulário de cadastro de turma para nova tentativa
7) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 2 Editar turma
1) Admin aciona formulário de consulta de turma e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com a(s) turma (s) encontrada(s).
3) Admin aciona a funcionalidade de edição dos dados.
4) Sistema carregas as informações da turma selecionada.
5) Admin informa as alterações e confirma a alteração.
6) Sistema valida as informações e persiste os dados.
7) Sistema emite a mensagem “Registro realizado com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 3 Excluir turma
1) Admin aciona formulário de consulta de turma e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com a(s) turma(s) encontrada(s).
3) Admin aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações da turma selecionado.
5) Admin clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e realiza a operação.
7) Sistema emite a mensagem “Registro excluído com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 4 Excluir turma (Violação de Chave Estrangeira)
1) Admin aciona formulário de consulta de turma e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com a(s) turma(s) encontrada(s).
3) Admin aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações da turma selecionado.
5) Admin clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e detecta violação de chave estrangeira.
7) Sistema emite a mensagem “O registro não pode ser excluído – Vínculo existente.”
8) Sistema encerra o caso de uso.
REQUISITOS ESPECIAIS
1) O usuário deve estar logado no sistema
2) Descrição da turma deve ser única
PRÉ CONDIÇÃO
PÓS CONDIÇÃO
NÚMERO
UC007
CASO DE USO
Manter Unidade
DESCRIÇÃO
Caso de uso responsável por manter o cadastro de unidade.
ATOR
Admin
CENÁRIO PRINCIPAL
Cadastrar unidade
1) Admin solicita o formulário de cadastro de unidade .
2) Sistema exibe o formulário de cadastro de unidade .
3) Admin informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e persiste os dados.
5) Sistema emite a mensagem “Registro realizado com sucesso.”
6) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 1 Cadastrar turma (Unidade já existente)
1) Admin solicita o formulário de cadastro de unidade .
2) Sistema exibe o formulário de cadastro de unidade .
3) Admin informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e detecta duplicidade.
5) Sistema emite a mensagem “Registro já existente”
6) Sistema exibe novamente o formulário de cadastro de unidade para nova tentativa
7) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 2 Editar unidade
1) Admin aciona formulário de consulta de unidade e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com a(s) unidade(s) encontrada(s).
3) Admin aciona a funcionalidade de edição dos dados.
4) Sistema carregas as informações da unidade selecionada.
5) Admin informa as alterações e confirma a alteração.
6) Sistema valida as informações e persiste os dados.
7) Sistema emite a mensagem “Registro realizado com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 3 Excluir unidade
1) Admin aciona formulário de consulta de unidade e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com a(s) unidade(s) encontrada(s).
3) Admin aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações da unidade selecionado.
5) Admin clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e realiza a operação.
7) Sistema emite a mensagem “Registro excluído com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 4 Excluir unidade (Violação de Chave Estrangeira)
1) Admin aciona formulário de consulta de unidade e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com a(s) unidade(s) encontrada(s).
3) Admin aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações da unidade selecionado.
5) Admin clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e detecta violação de chave estrangeira.
7) Sistema emite a mensagem “O registro não pode ser excluído – Vínculo existente.”
8) Sistema encerra o caso de uso.
REQUISITOS ESPECIAIS
1) O usuário deve estar logado no sistema
2) Nome da unidade deve ser única
PRÉ CONDIÇÃO
PÓS CONDIÇÃO
NÚMERO
UC008
CASO DE USO
Manter Associado
DESCRIÇÃO
Caso de uso responsável por manter o cadastro de associados.
ATOR
Usuário
CENÁRIO PRINCIPAL
Cadastrar associado
1) Usuário solicita o formulário de cadastro de associado.
2) Sistema exibe o formulário de cadastro de associado.
3) Usuário informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e persiste os dados.
5) Sistema emite a mensagem “Registro realizado com sucesso.”
6) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 1 Cadastrar associado (Associado já existente)
1) Usuário solicita o formulário de cadastro de associado.
2) Sistema exibe o formulário de cadastro de associado .
3) Usuário informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e detecta duplicidade.
5) Sistema emite a mensagem “Registro já existente”
6) Sistema exibe novamente o formulário de cadastro de associado para nova tentativa
7) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 2 Cadastrar associado pensionista
1) Usuário solicita o formulário de cadastro de associado.
2) Sistema exibe o formulário de cadastro de associado.
3) Usuário informa os dados requeridos informando que o associado é pensionista.
4) Sistema chama o caso de uso ”Informar vínculo do pensionista”.
5) Usuário informa o pensionista que a vincula.
6) Sistema valida as informações e persiste os dados.
7) Sistema emite a mensagem “Registro realizado com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 3 Editar associado
1) Usuário aciona formulário de consulta de associado e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com o(s) associados(s) encontrado(s).
3) Usuário aciona a funcionalidade de edição dos dados.
4) Sistema carregas as informações do associado selecionado.
5) Usuário informa as alterações e confirma a alteração.
6) Sistema valida as informações e persiste os dados.
7) Sistema emite a mensagem “Registro realizado com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 4 Excluir associado
1) Usuário aciona formulário de consulta de associados e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com o(s) associados(s) encontrado(s).
3) Usuário aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações do associado selecionado.
5) Usuário clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e realiza a operação.
7) Sistema emite a mensagem “Registro excluído com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 5 Excluir associado (Violação de Chave Estrangeira)
1) Usuário aciona formulário de consulta de associado e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com o(s) associado(s) encontrado(s).
3) Usuário aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações do associado selecionado.
5) Usuário clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e detecta violação de chave estrangeira.
7) Sistema emite a mensagem “O registro não pode ser excluído – Vínculo existente.”
8) Sistema encerra o caso de uso.
REQUISITOS ESPECIAIS
1) O usuário deve estar logado no sistema
2) Matrícula e número do associado devem ser únicos
3) Lotação, tipo de associado e situação do associado são campos obrigatórios.
PRÉ CONDIÇÃO
PÓS CONDIÇÃO
NÚMERO
CASO DE USO
DESCRIÇÃO
ATOR
CENÁRIO PRINCIPAL
UC009
Informar vínculo do pensionista
Caso de uso responsável por possibilitar a inserção de vínculo
do pensionista com associado falecido
Usuário
Informar vínculo
1) Durante o cadastro ou atualização de um associado o usuário seleciona “Pensionista”
como tipo de associado.
2) Sistema renderiza um campo para o usuário informar qual o vínculo.
3) Usuário informa o vínculo.
4) Sistema encerra o caso de uso.
REQUISITOS ESPECIAIS
1) O usuário deve estar logado no sistema
PRÉ CONDIÇÃO
Estar realizando o cadastro ou edição de um associado.
PÓS CONDIÇÃO
NÚMERO
CASO DE USO
DESCRIÇÃO
UC010
Manter Funcionário
Caso de uso responsável por manter o cadastro de
funcionários.
ATOR
Usuário
CENÁRIO PRINCIPAL
Cadastrar funcionário
1) Usuário solicita o formulário de cadastro de funcionário.
2) Sistema exibe o formulário de cadastro de funcionário.
3) Usuário informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e persiste os dados.
5) Sistema emite a mensagem “Registro realizado com sucesso.”
6) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 1 Cadastrar funcionário(Funcionário já existente)
1) Usuário solicita o formulário de cadastro de funcionário.
2) Sistema exibe o formulário de cadastro de funcionário.
3) Usuário informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e detecta duplicidade.
5) Sistema emite a mensagem “Registro já existente”
6) Sistema exibe novamente o formulário de cadastro de funcionário para nova tentativa
7) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 2 Editar funcionário
1) Usuário aciona formulário de consulta de funcionário e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com o(s) funcionário(s) encontrado(s).
3) Usuário aciona a funcionalidade de edição dos dados.
4) Sistema carregas as informações do funcionário selecionado.
5) Usuário informa as alterações e confirma a alteração.
6) Sistema valida as informações e persiste os dados.
7) Sistema emite a mensagem “Registro realizado com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 3 Excluir funcionário
1) Usuário aciona formulário de consulta de funcionário e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com o(s) funcionário(s) encontrado(s).
3) Usuário aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações do funcionário selecionado.
5) Usuário clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e realiza a operação.
7) Sistema emite a mensagem “Registro excluído com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 4 Excluir funcionário (Violação de Chave Estrangeira)
1) Usuário aciona formulário de consulta de funcionário e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com o(s) funcionário(s) encontrado(s).
3) Usuário aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações do funcionário selecionado.
5) Usuário clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e detecta violação de chave estrangeira.
7) Sistema emite a mensagem “O registro não pode ser excluído – Vínculo existente.”
8) Sistema encerra o caso de uso.
REQUISITOS ESPECIAIS
1) O usuário deve estar logado no sistema
2) Dados do funcionários devem ser únicos
PRÉ CONDIÇÃO
PÓS CONDIÇÃO
NÚMERO
UC011
CASO DE USO
Manter Fornecedor
DESCRIÇÃO
Caso de uso responsável por manter o cadastro de fornecedor.
ATOR
Usuário
CENÁRIO PRINCIPAL
Cadastrar fornecedor
1) Usuário solicita o formulário de cadastro de fornecedor.
2) Sistema exibe o formulário de cadastro de fornecedor.
3) Usuário informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e persiste os dados.
5) Sistema emite a mensagem “Registro realizado com sucesso.”
6) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 1 Cadastrar fornecedor(Fornecedor já existente)
1) Usuário solicita o formulário de cadastro de fornecedor.
2) Sistema exibe o formulário de cadastro de fornecedor.
3) Usuário informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e detecta duplicidade.
5) Sistema emite a mensagem “Registro já existente”
6) Sistema exibe novamente o formulário de cadastro de fornecedor para nova tentativa
7) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 2 Editar fornecedor
1) Usuário aciona formulário de consulta de fornecedor e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com o(s) fornecedor(es) encontrado(s).
3) Usuário aciona a funcionalidade de edição dos dados.
4) Sistema carregas as informações do fornecedor selecionado.
5) Usuário informa as alterações e confirma a alteração.
6) Sistema valida as informações e persiste os dados.
7) Sistema emite a mensagem “Registro realizado com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 3 Excluir fornecedor
1) Usuário aciona formulário de consulta de fornecedor e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com o(s) fornecedor(es) encontrado(s).
3) Usuário aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações do fornecedor selecionado.
5) Usuário clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e realiza a operação.
7) Sistema emite a mensagem “Registro excluído com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 4 Excluir fornecedor(Violação de Chave Estrangeira)
1) Usuário aciona formulário de consulta de fornecedor e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com o(s) fornecedore(s) encontrado(s).
3) Usuário aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações do fornecedor selecionado.
5) Usuário clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e detecta violação de chave estrangeira.
7) Sistema emite a mensagem “O registro não pode ser excluído – Vínculo existente.”
8) Sistema encerra o caso de uso.
REQUISITOS ESPECIAIS
1) O usuário deve estar logado no sistema
2) Descrição do fornecedor deve ser único
PRÉ CONDIÇÃO
PÓS CONDIÇÃO
NÚMERO
CASO DE USO
DESCRIÇÃO
UC012
Manter hospedagem
Caso de uso responsável por manter o controle das
hospedagens no hotel.
ATOR
Usuário
CENÁRIO PRINCIPAL
Cadastrar hospedagem somente do associado
1) Usuário solicita o formulário de cadastro de hospedagem .
2) Sistema exibe o formulário de cadastro de hospedagem.
3) Usuário informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e persiste os dados.
5) Sistema emite a mensagem “Registro realizado com sucesso.”
6) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 1 Cadastrar hospedagem com acompanhante
1) Usuário solicita o formulário de cadastro de hospedagem .
2) Sistema exibe o formulário de cadastro de hospedagem.
3) Usuário informa os dados requeridos informa que há acompanhante(s).
4) Sistema chama o caso de uso “informar acompanhante”.
5) Usuário confirma os dados.
6) Sistema valida as informações e persiste os dados.
7) Sistema emite a mensagem “Registro realizado com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 2 Cadastrar hospedagem (Hospedagem já registrada)
1) Usuário solicita o formulário de cadastro de hospedagem.
2) Sistema exibe o formulário de cadastro de hospedagem .
3) Usuário informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e detecta duplicidade.
5) Sistema emite a mensagem “Registro já existente”
6) Sistema exibe novamente o formulário de cadastro de hospedagem para nova tentativa
7) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 3 Editar hospedagem
1) Usuário aciona formulário de consulta de hospedagem e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com a(s) hospedagem(s) encontrada(s).
3) Usuário aciona a funcionalidade de edição dos dados.
4) Sistema carregas as informações da hospedagem selecionada.
5) Usuário informa as alterações e confirma a alteração.
6) Sistema valida as informações e persiste os dados.
7) Sistema emite a mensagem “Registro realizado com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 4 Excluir hospedagem
1) Usuário aciona formulário de consulta de hospedagem e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com a(s) hospedagem(s) encontrada(s).
3) Usuário aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações da hospedagem selecionada.
5) Usuário clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e realiza a operação.
7) Sistema emite a mensagem “Registro excluído com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 5 Excluir hospedagem (Violação de Chave Estrangeira)
1) Usuário aciona formulário de consulta de hospedagem e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com a(s) hospedagem(s) encontrada(s).
3) Usuário aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações da hospedagem selecionada.
5) Usuário clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e detecta violação de chave estrangeira.
7) Sistema emite a mensagem “O registro não pode ser excluído – Vínculo existente.”
8) Sistema encerra o caso de uso.
REQUISITOS ESPECIAIS
1) O usuário deve estar logado no sistema
PRÉ CONDIÇÃO
PÓS CONDIÇÃO
NÚMERO
CASO DE USO
DESCRIÇÃO
UC013
Informar acompanhante
Caso de uso responsável por possibilitar o cadastro de
acompanhante de associado hospedado no hotel
ATOR
Usuário
CENÁRIO PRINCIPAL
Informar acompanhante
1) Durante o cadastro ou atualização de uma hospedagem o usuário seleciona a
funcionalidade de adicionar acompanhante.
2) Sistema renderiza uma tela de modo a possibilitar o cadastro dos dados do(a)
acompanhante.
3) Usuário informa os dados requeridos da acompanhante e confirma o cadastro.
4) Sistema valida as informações.
5 Sistema emite a mensagem “Acompanhante cadastrado com sucesso.”
6) Sistema encerra o caso de uso.
REQUISITOS ESPECIAIS
1) O usuário deve estar logado no sistema
PRÉ CONDIÇÃO
PÓS CONDIÇÃO
NÚMERO
CASO DE USO
DESCRIÇÃO
Estar realizando um cadastro ou edição de hospedagem
UC014
Manter Agenda
Caso de uso responsável por manter o registro
compromissos e reserva de área privativa
ATOR
Usuário
CENÁRIO PRINCIPAL
Cadastrar agenda
1) Usuário solicita o formulário de cadastro de agenda.
2) Sistema exibe o formulário de cadastro de agenda.
3) Usuário informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e persiste os dados.
5) Sistema emite a mensagem “Registro realizado com sucesso.”
6) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 1 Cadastrar agenda (Agenda já registrada)
1) Usuário solicita o formulário de cadastro de agenda.
2) Sistema exibe o formulário de cadastro de agenda .
3) Usuário informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e detecta duplicidade.
5) Sistema emite a mensagem “Registro já existente”
6) Sistema exibe novamente o formulário de cadastro de agenda para nova tentativa
7) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 2 Editar agenda
1) Usuário aciona formulário de consulta de agenda e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com a(s) agenda(s) encontrada(s).
3) Usuário aciona a funcionalidade de edição dos dados.
4) Sistema carregas as informações da agenda selecionada.
5) Usuário informa as alterações e confirma a alteração.
6) Sistema valida as informações e persiste os dados.
7) Sistema emite a mensagem “Registro realizado com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 3 Excluir agenda
1) Usuário aciona formulário de consulta de agenda e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com a(s) agenda(s) encontrada(s).
3) Usuário aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações da agenda selecionada.
5) Usuário clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e realiza a operação.
7) Sistema emite a mensagem “Registro excluído com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 4 Excluir agenda (Violação de Chave Estrangeira)
1) Usuário aciona formulário de consulta de agenda e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com a(s) agenda(s) encontrada(s).
3) Usuário aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações da agenda selecionada.
5) Usuário clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e detecta violação de chave estrangeira.
de
7) Sistema emite a mensagem “O registro não pode ser excluído – Vínculo existente.”
8) Sistema encerra o caso de uso.
REQUISITOS ESPECIAIS
1) O usuário deve estar logado no sistema
2) Não deve coincidir duas agendas na mesma data/hora
PRÉ CONDIÇÃO
PÓS CONDIÇÃO
NÚMERO
UC015
CASO DE USO
Manter Instituição
DESCRIÇÃO
Caso de uso responsável por manter o cadastro de instituição
ATOR
Usuário
CENÁRIO PRINCIPAL
Cadastrar instituição
1) Usuário solicita o formulário de cadastro de instituição.
2) Sistema exibe o formulário de cadastro de instituição.
3) Usuário informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e persiste os dados.
5) Sistema emite a mensagem “Registro realizado com sucesso.”
6) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 1 Cadastrar instituição(Instituição já registrada)
1) Usuário solicita o formulário de cadastro de instituição.
2) Sistema exibe o formulário de cadastro de instituição.
3) Usuário informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e detecta duplicidade.
5) Sistema emite a mensagem “Registro já existente”
6) Sistema exibe novamente o formulário de cadastro de instituição para nova tentativa
7) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 2 Editar instituição
1) Usuário aciona formulário de consulta de instituição e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com a(s) instituição(ões) encontrada(s).
3) Usuário aciona a funcionalidade de edição dos dados.
4) Sistema carregas as informações da instituição selecionada.
5) Usuário informa as alterações e confirma a alteração.
6) Sistema valida as informações e persiste os dados.
7) Sistema emite a mensagem “Registro realizado com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 3 Excluir instituição
1) Usuário aciona formulário de consulta de instituição e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com a(s) instituição(ões) encontrada(s).
3) Usuário aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações da instituição selecionada.
5) Usuário clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e realiza a operação.
7) Sistema emite a mensagem “Registro excluído com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 4 Excluir instituição (Violação de Chave Estrangeira)
1) Usuário aciona formulário de consulta de instituição e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com a(s) instituição(ões) encontrada(s).
3) Usuário aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações da instituição selecionada.
5) Usuário clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e detecta violação de chave estrangeira.
7) Sistema emite a mensagem “O registro não pode ser excluído – Vínculo existente.”
8) Sistema encerra o caso de uso.
REQUISITOS ESPECIAIS
1) O usuário deve estar logado no sistema
2) Descrição da instituição deve ser único
3) Os dados do representante da instituição é campo obrigatório.
PRÉ CONDIÇÃO
PÓS CONDIÇÃO
NÚMERO
UC016
CASO DE USO
Manter Patrimônio
DESCRIÇÃO
Caso de uso responsável por manter o cadastro de patrimônio
ATOR
Usuário
CENÁRIO PRINCIPAL
Cadastrar patrimônio
1) Usuário solicita o formulário de cadastro de patrimônio.
2) Sistema exibe o formulário de cadastro de patrimônio.
3) Usuário informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e persiste os dados.
5) Sistema emite a mensagem “Registro realizado com sucesso.”
6) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 1 Cadastrar patrimônio (Patrimônio já registrado)
1) Usuário solicita o formulário de cadastro de patrimônio.
2) Sistema exibe o formulário de cadastro de patrimônio.
3) Usuário informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e detecta duplicidade.
5) Sistema emite a mensagem “Registro já existente”
6) Sistema exibe novamente o formulário de cadastro de patrimônio para nova tentativa
7) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 2 Editar patrimônio
1) Usuário aciona formulário de consulta de patrimônio e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com o(s) patrimônio(s) encontrado(s).
3) Usuário aciona a funcionalidade de edição dos dados.
4) Sistema carregas as informações do patrimônio selecionado.
5) Usuário informa as alterações e confirma a alteração.
6) Sistema valida as informações e persiste os dados.
7) Sistema emite a mensagem “Registro realizado com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 3 Excluir patrimônio
1) Usuário aciona formulário de consulta de patrimônio e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com o(s) patrimônio(s) encontrado(s).
3) Usuário aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações do patrimônio selecionado.
5) Usuário clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e realiza a operação.
7) Sistema emite a mensagem “Registro excluído com sucesso.”
8) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 4 Excluir patrimônio (Violação de Chave Estrangeira)
1) Usuário aciona formulário de consulta de patrimônio e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com o(s) patrimônio(s) encontrado(s).
3) Usuário aciona a funcionalidade de visualização dos dados.
4) Sistema carregas as informações do patrimônio selecionado.
5) Usuário clica no botão excluir e confirma a operação.
6) Sistema verifica os vínculos e detecta violação de chave estrangeira.
7) Sistema emite a mensagem “O registro não pode ser excluído – Vínculo existente.”
8) Sistema encerra o caso de uso.
REQUISITOS ESPECIAIS
1) O usuário deve estar logado no sistema
2) O número de patrimônio deve ser único
3) O número de patrimônio é campo obrigatório.
PRÉ CONDIÇÃO
PÓS CONDIÇÃO
NÚMERO
UC017
CASO DE USO
Baixar Patrimônio
DESCRIÇÃO
Caso de uso responsável baixar o patrimônio inservível
ATOR
Usuário
CENÁRIO PRINCIPAL
Baixar o patrimônio
1) Usuário aciona formulário de consulta de patrimônio e informa o parâmetro de busca.
2) Sistema busca as informações e exibe uma grid com o(s) patrimônio(s) encontrado(s).
3) Usuário aciona a funcionalidade de visualização dos dados.
4) Sistema exibe os dados do patrimônio e um botão para realizar a baixa.
5) Usuário clica em baixar material e confirma a operação.
6) Sistema realiza a baixa do material.
7) Sistema emite a mensagem “Patrimônio baixado com sucesso.”
8) Sistema encerra o caso de uso.
REQUISITOS ESPECIAIS
1) O usuário deve estar logado no sistema
PRÉ CONDIÇÃO
O usuário deve estar executando o caso de uso “Manter
patrimônio”
PÓS CONDIÇÃO
Patrimônio não é apagado fisicamente, porém não é mais
acessível.
NÚMERO
CASO DE USO
DESCRIÇÃO
UC018
Enviar e-mail
Caso de uso responsável pelo envio de e-mail a partir do
cadastro de associados
ATOR
Usuário
CENÁRIO PRINCIPAL
Enviar e-mail
1) Usuário solicita o formulário de envio de e-mail.
2) Sistema exibe o respectivo formulário.
3) Usuário chama o caso de uso “Selecionar destinatários”.
4) Sistema busca os e-mails dos associados selecionados.
5) Usuário redige a mensagem e informa o assunto.
6) Usuário clica no botão “Enviar mensagem”.
7) Sistema envia a mensagem aos associados selecionados e emite a mensagem “E-mail
enviado com sucesso”
8) Sistema encerra o caso de uso.
REQUISITOS ESPECIAIS
1) O usuário deve estar logado no sistema
PRÉ CONDIÇÃO
O associado selecionado deve possuir e-mail registrado em
seu cadastro.
PÓS CONDIÇÃO
NÚMERO
CASO DE USO
DESCRIÇÃO
UC019
Enviar SMS
Caso de uso responsável pelo envio de SMS a partir do
cadastro de associados
ATOR
Usuário
CENÁRIO PRINCIPAL
Enviar SMS
1) Usuário solicita o formulário de envio de SMS.
2) Sistema exibe o respectivo formulário.
3) Usuário chama o caso de uso “Selecionar destinatários”.
4) Sistema busca os números de telefone celulares dos associados selecionados.
5) Usuário redige a mensagem e informa o assunto.
6) Usuário clica no botão “Enviar mensagem”.
7) Sistema se conecta ao gateway de envio dos SMS’s.
8) Sistema envia a mensagem aos associados selecionados e emite a mensagem “SMS
enviado com sucesso”
9) Sistema encerra o caso de uso.
REQUISITOS ESPECIAIS
1) O usuário deve estar logado no sistema
PRÉ CONDIÇÃO
O associado selecionado deve possuir e-mail registrado em
seu cadastro.
PÓS CONDIÇÃO
NÚMERO
CASO DE USO
DESCRIÇÃO
UC020
Selecionar destinatários
Caso de uso responsável por filtrar os associados selecionados
como destinatários de e-mail ou SMS
ATOR
Usuário
CENÁRIO PRINCIPAL
Selecionar destinatários para e-mail
1) Estando na tela de envio de e-mail o usuário inicia o filtro de associados que receberão a
mensagem.
2) Sistema filtra os associados e constrói uma lista de e-mails quando o caso de uso origem
é o “Enviar e-mail”
3) Sistema libera o envio da mensagem.
4) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 1 Selecionar destinatários para SMS
1) Estando na tela de envio de SMS o usuário inicia o filtro de associados que receberão a
mensagem.
2) Sistema filtra os associados e constrói uma lista de telefones celulares quando o caso de
uso origem é o “Enviar SMS”
3) Sistema libera o envio da mensagem.
4) Sistema encerra o caso de uso.
REQUISITOS ESPECIAIS
1) O usuário deve estar logado no sistema
PRÉ CONDIÇÃO
O usuário deve estar executando o caso de uso “Enviar email” ou “Enviar SMS”.
PÓS CONDIÇÃO
Lista de e-mail selecionados pronto para uso
NÚMERO
CASO DE USO
DESCRIÇÃO
UC021
Manter agenda de envio
Caso de uso responsável pelo envio de SMS programado a
partir do cadastro de associados
ATOR
Usuário
CENÁRIO PRINCIPAL
Cadastrar agenda de envio
1) Usuário solicita o formulário de cadastro de agenda de envio de SMS.
2) Sistema exibe o formulário de cadastro de agenda de envio de SMS.
3) Usuário informa os dados requeridos e confirma o cadastro.
4) Sistema valida as informações e persiste os dados.
5) Sistema emite a mensagem “Registro realizado com sucesso.”
6) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 2 Acionar o envio do SMS
1) Sistema monitora o cadastro de agenda de envio.
2) Sistema detecta que há um SMS a ser enviado.
3) Sistema aciona o caso de uso “Enviar SMS” passando como parâmetro os destinatários.
4) Sistema encerra o caso de uso.
REQUISITOS ESPECIAIS
1) Deve ser usado a API do Quartz para monitorar a agenda.
PRÉ CONDIÇÃO
PÓS CONDIÇÃO
NÚMERO
UC022
CASO DE USO
Gerar Relatório
DESCRIÇÃO
Caso de uso responsável pela geração de relatórios em PDF
ATOR
Usuário
CENÁRIO PRINCIPAL
Gerar relatório
1) Usuário solicita o formulário de geração de relatório a partir de um menu de opções.
2) Sistema exibe o formulário para parametrizar o relatório.
3) Usuário informa os dados requeridos e confirma a geração do relatório.
4) Sistema valida as informações, busca as informações no banco de dados e gera um
documento em PDF com as informações solicitadas.
5) Sistema encerra o caso de uso.
CENÁRIO ALTERNATIVO 2 Gerar etiquetas PIMACO de endereço
1) Usuário solicita o formulário de geração de relatório a partir de um menu de opções.
2) Sistema exibe o formulário para parametrizar a geração das etiquetas.
3) Usuário informa os dados requeridos e confirma a geração do relatório.
4) Sistema valida as informações, busca as informações no banco de dados e gera um
documento em PDF com a formatação própria para impressão em formulário de etiquetas
PIMACO.
5) Sistema encerra o caso de uso.
REQUISITOS ESPECIAIS
PRÉ CONDIÇÃO
PÓS CONDIÇÃO
Documento PDF gerado
APÊNDICE F
DIAGRAMA DE CLASSE
APÊNDICE G
TELAS DO SISTEMA
Figura G:1 – Tela de Login
Figura G:2 – Tela principal com exibição do menu com as funcionalidades. Menu criado a
partir do componente rich:menu
Figura G:3 – Tela de consulta de associados
Figura G:4 – Tela de edição de associado com abertuda de um Modal Panel para insersão de
documento
Figura G:5 – Tela de edição de associado com abertuda de um Modal Panel para insersão de
endereço fazendo uso do componente rich:select. A esquerda da tela uma lista de
dependentes fazendo uso do componente rich:list. Na parte inferior o envio e renderização de
fotografias
Figura G:6 – Tela de cadastro de hospedagem com adição de acompanhante por meio de um
Modal Panel
Figura G:7 – Tela de cadastro de funcionário com validação de campos e máscara
personalizada para o campo horário
Figura G:8 – Tela de envio de e-mail fazendo uso do componente rich:pickList para filtragem
dos associados
Figura G:9 – Tela de envio de SMS. Esta funcionalidade se conecta a um Gateway SMS
provedor do serviço por meio de um WebService
Figura G:10 – Tela de geração de relatório parametrizado. Esta funcionalidade utiliza o
JasperReports para gerar o arquivo PDF
Figura G:11 – Relatório de bens patrimoniais gerado pelo sistema
APÊNDICE F
CÓDIGO FONTE