Ediney dos Santos

UNIVERSIDADE FEDERAL DE MATO GROSSO
INSTITUTO DE COMPUTAÇÃO
COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM
CIÊNCIA DA COMPUTAÇÃO
RELATÓRIO DE ESTÁGIO SUPERVISIONADO
DESENVOLVIMENTO DE UM CONTROLE ACADÊMICO
PARA O HOSPITAL UNIVERSITÁRIO JÚLIO MÜLLER
EDINEY DOS SANTOS LOPES
CUIABÁ – MT
2016
UNIVERSIDADE FEDERAL DE MATO GROSSO
INSTITUTO DE COMPUTAÇÃO
COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM
CIÊNCIA DA COMPUTAÇÃO
RELATÓRIO DE ESTÁGIO SUPERVISIONADO
DESENVOLVIMENTO DE UM CONTROLE ACADÊMICO
PARA O HOSPITAL UNIVERSITÁRIO JÚLIO MÜLLER
EDINEY DOS SANTOS LOPES
Relatório
apresentado
ao
Instituto
de
Computação da Universidade Federal de
Mato Grosso, para obtenção do título de
Bacharel em Ciência da Computação.
CUIABÁ – MT
2016
UNIVERSIDADE FEDERAL DE MATO GROSSO
INSTITUTO DE COMPUTAÇÃO
COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM
CIÊNCIA DA COMPUTAÇÃO
EDINEY DOS SANTOS LOPES
Relatório de Estágio Supervisionado apresentado à Coordenação do Curso de
Ciência da Computação como uma das exigências para obtenção do título de
Bacharel em Ciência da Computação da Universidade Federal de Mato Grosso
Aprovado por:
Prof. Dr. Raphael de Souza Rosa Gomes
Instituto de Computação
(ORIENTADOR)
Prof. Dr. Thiago Meirelles Ventura
Instituto de Computação
(CONVIDADO)
Leonardo Luiz Braun
HUJM/SGPTI
(SUPERVISOR)
DEDICATÓRIA
A Deus, pois dele emana toda a sabedoria.
À minha esposa Sinei, companheira fiel.
À minha filha Vanessa, razão da minha vida.
À minha mãe, Fátima, meu porto seguro.
AGRADECIMENTOS
Agradeço primeiramente a Deus, pois sozinho não teria concluído esse
trabalho. “Vinde a mim todos os que estais cansados e sobrecarregados e eu vos
aliviarei” (Mateus 11:28-30). Agradeço também à minha família pelo apoio e
incentivo.
Agradeço aos professores do Instituto de Computação, por terem sido
fundamentais na minha vida acadêmica. Agradeço especialmente os professores
Maurício Pereira e Nelcileno Araújo por me ajudarem quando precisei recorrer à
Coordenação do Curso.
Agradeço ao meu orientador professor Raphael de Souza Gomes por me
orientar e instruir com paciência, sendo decisivo para a realização deste trabalho.
Agradeço a todos da equipe da SGPTI do Hospital Júlio Müller, cujo
companheirismo enriqueceu minha formação profissional. Agradeço em especial ao
meu supervisor de estágio Leonardo Braun, um exemplo do que é ser um líder de um
grande time de profissionais.
Agradeço aos amigos que fiz no Instituto de Computação, companheiros que
levarei por toda minha vida.
SUMÁRIO
LISTA DE FIGURAS .................................................................................................................... .8
LISTA DE TABELAS .................................................................................................................... 9
LISTA DE SIGLAS E ABREVIATURAS ................................................................................... 10
RESUMO ...................................................................................................................................... 11
INTRODUÇÃO ............................................................................................................................ 12
1.
REVISÃO DE LITERATURA ............................................................................................ 13
1.1. VISÃO GERAL DAS TECNOLOGIAS E APLICAÇÕES DE CAMADA ÚNICA.... 13
1.2. APLICAÇÕES DE DUAS CAMADAS ........................................................................ 14
1.3. APLICAÇÕES MULTI-CAMADAS: WEB ................................................................ 15
1.4. O PADRÃO MVC......................................................................................................... 17
1.5. JAVA SERVLET .......................................................................................................... 19
1.6. JAVASERVER FACES ................................................................................................ 20
1.7. MAPEAMENTO OBJETO RELACIONAL................................................................ 22
1.8. JPA E HIBERNATE..................................................................................................... 22
2.
MATERIAS, TÉCNICAS E MÉTODOS ............................................................................ 23
2.1. APACHE MAVEN ....................................................................................................... 24
2.2. FACELETS PAGES ..................................................................................................... 25
2.3. VIEWS .......................................................................................................................... 27
2.4. MANAGED BEANS ..................................................................................................... 27
2.5. DOMAIN MODEL ....................................................................................................... 27
2.6. PERSISTÊNCIA........................................................................................................... 28
3.
RESULTADOS .................................................................................................................... 29
3.1. CONFIGURAÇÕES DOS ARQUIVOS WEB.XML E FACES-CONFIG.XML ........ 29
3.2. ESTRUTURA DA APLICAÇÃO ................................................................................. 31
3.3. O ARQUIVO POM.XML ............................................................................................. 33
3.4. AS CLASSES MODEL E OS PACOTES AUXILIARES ............................................ 38
3.5. CONVERTERS ............................................................................................................ 39
3.6. EXCEPTIONS .............................................................................................................. 40
3.7. FILTERS ...................................................................................................................... 40
3.8. REPOSITORY.............................................................................................................. 41
3.9. SERVICE ...................................................................................................................... 42
3.10. UTIL ........................................................................................................................... 42
3.11. VALIDATORS ........................................................................................................... 43
3.12. VIEWS ........................................................................................................................ 43
6
SUMÁRIO
4.
DIFICULDADES ENCONTRADAS .................................................................................. 47
4.1. PADRÃO DO PROJETO ............................................................................................. 47
4.2. FACELETS E SERVLETS .......................................................................................... 47
4.3. JAVASERVER FACES + PRIMEFACES ................................................................... 47
4.4. MANAGED BEANS ..................................................................................................... 48
4.5. CLASSES DAO ............................................................................................................ 48
4.6. PERSISTÊNCIA........................................................................................................... 48
4.7. VIEWS .......................................................................................................................... 48
5.
CONCLUSÕES ................................................................................................................... 49
6.
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................ 50
7.
APÊNDICES........................................................................................................................ 51
APÊNDICE 1. CLASSE ALUNOBEAN ............................................................................. 51
APÊNDICE 2. ENTIDADE ALUNO .................................................................................. 52
APÊNDICE 3. ENTIDADE PESSOA (PARTE 1) .............................................................. 53
APÊNDICE 4. ENTIDADE PESSOA (PARTE 2) .............................................................. 54
APÊNDICE 5. ENTIDADE PESSOA (PARTE 3) .............................................................. 55
APÊNDICE 6. ENTIDADE PESSOA (PARTE FINAL) .................................................... 56
APÊNDICE 7. GENERICDAO ........................................................................................... 57
APÊNDICE 8. CLASSE ALUNOCONVERTER ............................................................... 58
APÊNDICE 9. CLASSE ALUNOFILTER ......................................................................... 59
APÊNDICE 10. CLASSE ALUNOREPOSITORY............................................................. 60
APÊNDICE 11. CLASSES ALUNOSERVICE E ALUNOSERVICEIMPL ...................... 61
APÊNDICE 12. HIBERNATEUTIL ................................................................................... 62
7
LISTA DE FIGURAS
Figura 1 – Arquitetura 1-tier (camada única) ........................................................... 14
Figura 2 – Arquitetura 2-tier (duas camadas) ........................................................... 15
Figura 3 – Arquitetura J2EE (multi-camadas) ......................................................... 16
Figura 4 – Padrão MVC .......................................................................................... 18
Figura 5 – Arquitetura JSF (MVC2) ........................................................................ 20
Figura 6 – Ciclo de Vida JSF .................................................................................. 21
Figura 7 – Diagrama de atividades (CRUD Aluno) ................................................. 23
Figura 8 – Estrutura inicial do projeto acadêmico .................................................... 24
Figura 9 – Arquivo listadeestados.xhtml ................................................................. 26
Figura 10 – Tela gerada do arquivo listadeestados.xhtml ......................................... 26
Figura 11 – Arquivo persistence.xml ....................................................................... 28
Figura 12 – Arquivo web.xml ................................................................................. 29
Figura 13 – Arquivo faces-config.xml ..................................................................... 30
Figura 14 – Relação de pacotes do projeto academico ............................................. 32
Figura 15 – Relação das pastas de visões do projeto academico .............................. 33
Figura 16 – As dependências da Apache ................................................................. 34
Figura 17 – As dependências do Hibernate .............................................................. 35
Figura 18 – As dependências Javax ......................................................................... 36
Figura 19 – As dependências OmniFaces, PostgreSQL, PrettyFaces, PrimeFaces .... 37
Figura 20 – As dependências Spring e o Build ........................................................ 38
Figura 21 – AlunoDAO ........................................................................................... 39
Figura 22 – Pacote Converter .................................................................................. 40
Figura 23 – Pacotes Exceptions e Filters ................................................................. 41
Figura 24 – Pacotes Repository e Service ................................................................ 42
Figura 25 – Pacote Util ........................................................................................... 43
Figura 26 – Tela cadastrodecursos.jsf ...................................................................... 44
Figura 27 – Tela listadeturmas.jsf ........................................................................... 44
Figura 28 – Tela cadastrodealunos.jsf ..................................................................... 45
Figura 29 – Tela cadastrodealunos.jsf após clique no botão Foto ............................. 46
8
LISTA DE TABELAS
Tabela 1 – O padrão modelo-visão-controlador (MVC) ........................................... 18
Tabela 2 – Controle Facelets Page e Template Tags ............................................... 25
9
LISTA DE SIGLAS E ABREVIATURAS
API
Application Programming Interface (Interface de Programação de
Aplicação)
CSS
Cascading Style Sheets (Linguagem de Folhas de Estilo)
HUJM
Hospital Universitário Júlio Müller
HTTP
Hypertext Transfer Protocol (Protocolo de Transferência de Hipertexto)
IDE
Integrated Development Environment (Ambiente de Desenvolvimento
Integrado)
J2EE
Java 2 Platform, Enterprise Edition (Plataforma Edição Empresarial)
Java EE Java Enterprise Edition (Java Edição Empresarial)
JPA
Java Persistence API
JSF
JavaServer Faces
JSP
JavaServer Pages
MVC
Model-View-Controller (Modelo-Visão-Controlador)
ORM
Object-Relational Mapping (Mapeamento Objeto Relacional)
POJO
Plain Old Java Objects (Velhos e Simples Objetos Java)
SGPTI
Setor de Gestão de Processos e Tecnologia da Informação
XML
eXtensible Markup Language (Linguagem de Marcação Extensível)
10
RESUMO
Este trabalho apresenta o desenvolvimento do Controle Acadêmico HUJM, um
sistema que será integrado ao Framework Class, do Setor de Gestão de Processos e
Tecnologia da Informação (SGPTI) do Hospital Universitário Julio Müller e que tem
por finalidade gerir a frequência acadêmica do referido hospital. O intuito principal
do estágio foi estruturar um sistema web compatível com o ambiente do framework
da SGPTI e que atendesse a necessidade objeto de sua implementação. Para tanto,
foram abordados temas das áreas de desenvolvimento Web com o uso do padrão de
projeto MVC, utilizando os recursos da JavaServer Faces (JSF) e do PrimeFaces,
passando por toda a parte de desenvolvimento Java na IDE do Eclipse combinados
com Apache Maven e o Server Wildfly, até chegar a área de Banco de Dados,
incluindo a JPA, o framework de persistência Hibernate e o seu destino final, o banco
PostgreSQL, onde os dados ficarão armazenados. Ao final, foram apresentados os
resultados obtidos e possíveis melhorias no desenvolvimento dessa aplicação web.
Palavras chaves: desenvolvimento web, Facelets, JavaServer Faces.
11
INTRODUÇÃO
O Setor de Gestão de Processos e Tecnologia da Informação (SGPTI) do
Hospital Universitário Julio Müller atualmente vem passando por um momento de
inovação e de aperfeiçoamento em sua rotina de trabalho, e nesse contexto se destaca
a implantação de um ambiente para desenvolvimento Java, com foco principal na
criação de um framework, ou seja, de um módulo de gerenciamento de permissão
para novos sistemas. Por esse motivo as aplicações existentes, e também as em
construção, estão sendo refatoradas para essa nova realidade, inclusive o sistema
acadêmico, que é objeto deste trabalho.
O Controle Acadêmico HUJM, como dito anteriormente, é parte do
ambiente de desenvolvimento de aplicações Java da SGPTI e tem como objetivo
gerir toda a rotina dos acadêmicos que frequentam as dependências do Hospital
Universitário Julio Muller, contendo dados pessoais dos alunos bem como dados que
atestam o seu vínculo com o Hospital. Esse controle se faz necessário devido ao fato
do HUJM acolher alunos da área de saúde (internos, residentes, etc.) que estejam
cursando disciplinas que exija serem aplicadas em ambiente hospitalar.
O objetivo desse trabalho é abordar todas as ferramentas e metodologias
escolhidas para o desenvolvimento da aplicação do Controle Acadêmico HUJM e o
resultado obtido com essas escolhas.
12
1. REVISÃO DE LITERATURA
Para a realização das atividades propostas foram necessárias diversas
pesquisas e aprofundamento em conceitos vistos no decorrer do curso de Ciência da
Computação, da mesma forma um estudo bem criterioso da especificação JavaServer
Faces, que é uma tecnologia relativamente nova, para uma melhor compreensão de
seu uso e características.
As subsessões seguintes descrevem temas e conceitos envolvidos no
decorrer das atividades desse estágio supervisionado.
1.1 - Visão geral das tecnologias e aplicações de camada única
No decorrer da história dos computadores, o desenvolvimento de aplicações
passa constantemente por mudanças e esse processo evolutivo tem refletido
diretamente na produtividade e na flexibilidade do ambiente de desenvolvimento,
que vem se adaptando à medida que vão surgindo novas tecnologias, como veremos
a seguir.
Ao final dos anos 70 e início dos anos 80, houve a mudança de
computadores grandes para computadores pessoais (PCs), e o seu uso deixou de ser
algo exclusivo para poucos usuários, tornando-se mais popular (JACOBI &
FALLOWS, 2006).
Embora a maioria das aplicações desenvolvidas à época representar o que
tinha de mais avançado, elas foram projetadas para tarefas com usuário único e os
dados eram exclusivos, ou seja, não eram compartilhados. Não havia uma central de
bases de dados ou sistemas de e-mail.
Do ponto de vista da manutenção do sistema, esta solução de camada única
consistia em uma aplicação residente em uma máquina. Ela abrigaria ao mesmo
tempo as camadas de apresentação (telas), a das regras de negócio e a de dados, o
que tornava praticamente impossível o compartilhamento de informações (JACOBI
& FALLOWS, 2006). Essa realidade é facilmente expressada na Figura 1 a seguir.
13
Figura 1. Descreve a arquitetura de aplicações camada única. (Imagem adaptada de:
<https://www.cs.colorado.edu/~kena/classes/7818/f06/lectures/02/>)
Percebe-se, pelo que mostra a Figura 1, que a principal característica da
arquitetura 1-tier (camada única) é possuir todo o sistema de informação na máquina
cliente.
1.2 - Aplicações de duas camadas
Também conhecida por cliente-servidor tornou-se o centro das atenções na
década de 1980, aposentando as soluções de camada única. A arquitetura de duas
camadas permite o compartilhamento de dados, mudando a maneira de desenvolver e
implantar as aplicações a partir de então. Aplicações de duas camadas interagem
diretamente com o usuário, sendo que a lógica para a tela de visualização e as regras
de negócios são armazenadas na máquina cliente, enquanto que os dados residem em
um servidor remoto (JACOBI & FALLOWS, 2006).
Esta arquitetura permite que vários usuários acessem os dados
(centralizados na máquina servidor) com aplicações desktop nas máquinas clientes.
14
Exemplo: Microsoft Outlook. A Figura 2 mostra graficamente como seria essa
arquitetura.
Figura 2. Descreve a arquitetura de aplicações com duas camadas. (Imagem adaptada de:
<https://www.cs.colorado.edu/~kena/classes/7818/f06/lectures/02/>).
A arquitetura 2-tier (duas camadas), como se observa na Figura 2, é difere
da arquitetura 1-tier (camada única) pelo fato de separar o sistema de informação em
duas partes: uma contendo a lógica da aplicação e a gerencia de recursos armazenado
em uma máquina servidor, ficando tão somente a camada de aplicação na máquina
cliente.
1.3 - Aplicações multi-camadas: Web
A fase seguinte no desenvolvimento de aplicações chegou com a Internet e
os navegadores web e introduziu a arquitetura de três camadas, ou de vários níveis de
camadas. Arquitetura com vários níveis de camadas permite aos desenvolvedores que
se concentrem em modelos de domínios (acesso a dados), Views (apresentação), e
nos controladores (lógica). Este paradigma de programação, que representa a divisão
15
entre essas camadas, é conhecido como padrão Modelo-Visão-Controlador, ou como
o nome em inglês Model-View-Controller (MVC).
Essa arquitetura foi introduzida pela primeira vez nos aparelhos SmallTalk e
se espalhou na comunidade de desenvolvedores na década de 1980, transformando
em uma combinação de um cliente padrão (navegador da Web) e um protocolo de
comunicação padrão (HTTP), dando aos usuários acesso ubíquo para aplicações
centralizadoras, como o e-mail, por exemplo, através de um navegador (JACOBI &
FALLOWS, 2006).
A partir de então, as aplicações já podiam ser baixadas da internet, bem
como suas atualizações.
A Figura 3 mostra um esquema simples de arquitetura para uma aplicação
multi-camadas. O Cliente via browser (navegador) ou móbile (smartphone) acessa a
aplicação, num contêiner Java, para então ter contato ao sistema de informação. Tudo
ocorrendo por meio de um protocolo de comunicação.
Figura 3. Arquitetura J2EE comum a uma solução de software multi-camadas. (Imagem retirada de JACOBI and
FALLOWS, 2006).
As aplicações Web (WebApps, também conhecidas como aplicações
baseadas na Web) se caracterizam por possuir um amplo conjunto de conceitos e
16
terminologias associadas, além de possuírem características de aplicações hipermídia
(PRESSMAN, 2011).
Esse tipo de sistema não necessita executar a partir de uma instalação local,
como acontece com as aplicações desktop. Basta o uso de um navegador web para
acontecer a execução da maioria das aplicações web.
1.4 – O Padrão MVC
A parte mais sensível de um software interativo é a interface do usuário (ou
a View) por ser o meio de contato que os usuários utilizam para se comunicar com a
aplicação (DUDNEY, 2004). Em outras palavras, é a parte mais visível da maioria
dos sistemas de software.
Além das alterações diárias nos requisitos, podem existir exigências como o
suporte a mais de um sistema operacional, cada um pode necessitar uma aparência
diferente, por exemplo. Uma exigência como esta pode complicar o que à primeira
vista poderia ter sido uma simples interface.
As aplicações ditas monolíticas (camada única) são altamente acopladas,
tornando até mesmo pequenas alterações complicadas e sujeitas a erros.
Consequentemente, as alterações podem se propagar por todo o sistema. Além disso,
os requisitos do usuário podem forçar a manutenção de versões distintas para a
mesma aplicação. Isso adiciona uma dimensão adicional de complexidade e muitas
vezes resultam em versões de uma mesma aplicação, mas dessincronizadas.
O padrão MVC oferece uma solução flexível para esses problemas,
dissociando os componentes Model, View e Controller de uma aplicação e
proporcionando uma interface uniforme entre eles.
Nesse sentido, Dudney (2004) elenca abaixo o que ele define como boas
práticas de programação:
• disponibilizar diferentes representações da mesma aplicação de dados;
• fornecer uma aparência diferente e uma interface com o usuário, sem
afetar o resto da aplicação;
• os eventos devem atualizar instantaneamente os dados da aplicação ou
outros componentes da interface do usuário, enquanto que as alterações aos dados de
17
aplicação devem ser refletidas imediatamente nos componentes de interface do
usuário;
• reuso de um ou mais componentes da interface do usuário de forma
independente dos dados da aplicação;
A estrutura do padrão MVC é descrita na Figura 4. O Cliente via
navegador, faz uma requisição ou envio de dados ao Controlador, que num primeiro
momento trata essas informações ao mesmo tempo em que solicita um
comportamento do Modelo e uma resposta da Visão. O Modelo por sua vez,
encapsula funcionalidades e objetos e incorpora os estados para finalmente enviar os
dados para a Visão, que prepara esses dados para retornar ao Cliente.
Figura 4. Padrão MVC (PRESSMAN, 2011).
Para Sommerville (2011), o padrão MVC é base do gerenciamento em
muitos sistemas baseados em Web e as noções de separação e independência são
fundamentais para o projeto de arquitetura. A Tabela 1 descreve o comportamento do
padrão MVC.
Nome
MVC (Modelo-Visão Controlador)
Descrição
Separa a apresentação e a interação dos dados do
sistema. O sistema é estruturado em três
componentes lógicos que interagem entre si. O
componente Modelo gerencia o sistema de dados
e as operações associadas a esses dados. O
componente Visão define e gerencia como os
18
dados
são
apresentados
ao
usuário.
O
componente Controlador gerencia à interação do
usuário (por exemplo, teclas, cliques do mouse,
etc.) e passa essas interações para a Visão e o
Modelo.
Quando é usado
É usado quando existem várias maneiras de se
visualizar e interagir com dados. Também
quando são futuros requisitos de interação e
apresentação de dados.
Vantagens
Permite que os dados sejam alterados de forma
independentemente de sua representação, e viceversa. Apoia a apresentação dos mesmos dados
de maneiras diferentes, com as alterações feitas
em uma representação aparecendo em todas elas.
Desvantagens
Quando o modelo de dados e as interações são
simples, pode envolver código adicional e
complexidade de código.
Tabela 1. O padrão modelo-visão-controlador (MVC) – (Adaptado de SOMMERVILLE, 2011).
1.5 – Java Servlet
A primeira tecnologia para a produção de aplicações web dinâmicas com
Java recebeu o nome de Java Servlet, lançada em 1997 pela Sun Microsystems.
Embora não seja usado diretamente pelos desenvolvedores em Java Web, os servlets
são as classes que estão na base de todos os aplicativos Java EE (JUNEAU, 2014).
Muitos desenvolvedores usam servlets com JSP e JSF, ambas as
tecnologias compilam páginas com servlets, em seus containers. Mesmo que os
servlets possam atender a qualquer tipo de solicitação, é mais comum responderem
às solicitações de HTTP.
Os servlets fornecem aos desenvolvedores a flexibilidade para projetar
aplicações usando programação no estilo request-response. Eles desempenham um
papel fundamental no desenvolvimento orientado à serviços e diferentes tipos de
aplicações web podem ser criados e cada um deles é voltado para proporcionar
diferentes funcionalidades (JUNEAU, 2014).
Servlets tem a capacidade de fornecer respostas HTTP e também processar
as regras de negócios dentro de um mesmo código.
19
1.6 - JavaServer Faces
No ano de 2004 a Sun Microsystems apresentou o seu novo framework Java
Web em um esforço de ajudar a simplificar o desenvolvimento de aplicações web.
Surgia então o JavaServer Faces (JSF), que seria uma evolução do JavaServer Pages
(JSP), acrescentando uma maneira mais organizada em relação ao ciclo de vida e um
melhor aproveitamento das modernas tecnologias web (SALEH, 2013).
JSF faz uso de arquivos XML para construir as views e de classes Java para
montar toda a lógica da aplicação e nesse contexto adere à arquitetura de projetos
MVC. Todas as chamadas são processadas por um servlet chamado FacesServlet
(JUNEAU, 2014).
O FacesServlet é o responsável pela construção da árvore de componentes,
pelo processamento de eventos, definindo os processos seguintes e retornando as
respostas das chamadas. JSF usa um arquivo de recursos chamado faces-config.xml
para especificar os detalhes da aplicação, tais como as regras de navegação dentre
outras configurações. Além disso, tecnologia JSF permite integração com outras
tecnologias como Ajax, por exemplo, permitindo assim desenvolver um conteúdo
mais dinâmico.
A arquitetura do JSF é baseada no padrão MVC2. Ao contrário do padrão
MVC1, o padrão MVC2 desacopla a view do controller a partir do model. A Figura 5
mostra bem a arquitetura JSF MVC2.
Figura 5. Arquitetura JSF(Padrão MVC2). (SALEH, LYKKE e WADIA, 2013).
20
Conforme visto em Faria (2015), ao executar uma página construída usando
componentes JSF, ela passará por um ciclo de vida de processamento bem definido,
constituído por 6 fases:
1 – Restaurar visão;
2 – Aplicar valores de requisição;
3 – Processar validações;
4 – Atualizar os valores do modelo;
5 – Invocar a aplicação;
6 – Renderizar a resposta.
Todas essas fases do ciclo de vida do JSF estão representadas na Figura 6,
abaixo.
Figura 6. Ciclo de vida JSF (extraído de FARIA, 2015)
No momento que é feito uma requisição, a primeira fase restaura a visão e a
hierarquia dos componentes que compõem a página solicitada. A seguir, numa
segunda etapa é feito a aplicação dos valores da requisição com a atualização de
informações obtidas na requisição. Depois, um terceiro momento essas mesmas
informações devem ser validadas, ou seja, convertidas em tipos específicos e
anexadas aos componentes. A partir de então a aplicação começa a efetuar a
atualização dos valores nos objetos do modelo de dados. Em seguida, a aplicação é
21
invocada e os eventos de formulário são executados. O processo final consiste na
renderização da resposta para que seja gerada a saída com todos os componentes nos
seus estados atuais e então é enviada uma resposta ao cliente (usuário).
1.7 – Mapeamento Objeto Relacional (ORM)
Mapeamento objeto relacional é uma técnica de programação para
conversão de dados entre banco de dados relacionais e linguagens de programação
orientada a objetos (FARIA, 2015). Está interligada com a JPA e com técnicas de
persistência, como visto no tópico anterior e também no próximo.
1.8 – JPA e Hibernate
A Java Persistence API (JPA) é um framework para persistência em Java,
que oferece uma API de mapeamento objeto-relacional e soluções para integrar
persistência com sistemas corporativos escaláveis (FARIA, 2015). Ainda segundo
FARIA, com o uso de JPA, os objetos passam a ser definidos como POJO (Plain Old
Java Objects), ou seja, classes que representam entidades do sistema utilizando de
anotações para persistir objetos.
Além dos recursos da JPA, a ferramenta Hibernate ORM possui alguns
módulos que complementam a persistência, além de possuir um conjunto de
interfaces para consultas usando critérios, a Critéria e uma linguagem de consulta
chamada HQL (Hibernate Query Language). Outra opção SQL é a JPQL (Java
Persistence Query Language), que é uma linguagem de consulta padrão da JPA e
permite escrever consultas portáveis, independente do banco de dados.
22
2. MATERIAS, TÉCNICAS E MÉTODOS
Para a construção do ambiente de desenvolvimento, foram utilizados os
seguintes softwares, plugins e bibliotecas:
• Eclipse Java EE IDE Mars.1 com plugin JBoss;
• Wildfly 9.0.2;
• JDK 8u71;
• Postgresql 9.3.0.1.
• PgAdmin 3-1.22.0
Para a idealização da aplicação foi levado em conta a Análise de Sistema e
Processos já efetuada pela equipe de desenvolvimento da SGPTI, que idealizou o
Controle Acadêmico, não sendo necessário começar por essa fase inicial. Entretanto
foram realizados esboços para o entendimento e simular o sistema proposto.
Um dos esboços criados foi o Diagrama de Atividades que simula um
CRUD da entidade central da aplicação, como é mostrado na Figura 7, a seguir.
Figura 7. Diagrama de atividades (CRUD Aluno).
23
2.1 - Apache Maven
Apache Maven é uma ferramenta de gerenciamento de configuração do
projeto de desenvolvimento de uma aplicação. Cada projeto Maven tem um arquivo
POM (Project Object Model), ou projeto de modelo de objeto, o pom.xml. O arquivo
POM inclui as dependências do projeto para compilar e construir o projeto em um
artefato (SALEH, 2013). Para tanto, o Maven recebe as dependências do arquivo
POM e depois efetua os downloads dessas dependências no disco local, caso não
sejam encontrados nele para depois disso, executar a compilação e a montagem das
fontes compiladas para um artefato. O artefato alvo desse trabalho é o arquivo WAR
para aplicação web Java EE. Uma das características mais fortes do Maven é a sua
estrutura rígida em suas aplicações, como mostrado na Figura 8.
Figura 8. Estrutura inicial do projeto acadêmico.
Como mostrado, a raiz do projeto contém duas subpastas principais (src e
target) e o arquivo (POM). O diretório src contém o código-fonte da aplicação e o
diretório target contém os artefatos gerados. O diretório src tem um número de
subdiretórios e cada um desses diretórios tem uma finalidade específica:
• src/main/java: contém o código-fonte Java da aplicação;
• src/main/resources: contém os recursos que a aplicação precisa, tais
como o pacote de recursos;
• src/test/java: reservado para os testes da aplicação;
24
• src/test/resources: reservado para os testes de recursos;
• src/main/webapp: inclui os arquivos do projeto de aplicação JEE Web;
• src/test: inclui os testes de unidade da aplicação;
2.2 Facelets Pages
Existem várias definições para o Facelets. Criado pela Sun Microsystems e
atualmente mantido pela Oracle, Facelets é um sistema de template web, subprojeto
do JSF e linguagem de descrição de páginas.
Na documentação do Facelets na Oracle estão elencadas as vantagens de
seu uso, os quais seguem abaixo:
• suporte para reuso de código através de templates e componentes;
• extensibilidade funcional dos componentes e customização de objetos
server-side;
• tempo de compilação rápido;
• validação da EL em tempo de compilação;
• renderização de alto desempenho.
Abaixo, na Tabela 2 há uma descrição das tags existentes no Facelets:
Tag
Descrição
ui:component
Define um componente modelo e especifica um nome de arquivo.
ui:composition
Define uma composição de página e encapsula marcações JSF.
ui:debug
Cria um componente de depuração, captura informações da árvore de
componentes.
ui:define
Define o conteúdo que é inserido em um template de página.
ui:decorate
decora partes de uma página.
ui:fragment
Define um fragmento de modelo, assim como o ui:component, desconsiderando
conteúdo exteriores a tag.
ui:include
Permite o encapsulamento de outra página XHTML e sua reutilização dentro de
uma view.
ui:insert
Insere conteúdo em um modelo.
ui:param
Passa parâmetros para um arquivo ou modelo.
ui:repeat
Iteração sobre uma coleção de dados.
ui:remove
Remove conteúdo de uma pagina.
Tabela 2 – Controle Facelets Page e Template Tags (adaptado de JUNEAU).
25
E, finalmente, a Figura 9 mostra um arquivo XHTML do projeto acadêmico
com as configurações do Facelets:
Figura 9. Arquivo listadeestados.xhtml do projeto acadêmico (exibido com Sublime Text 3).
Conforme se verifica na Figura 9, o Facelets consegue conciliar os diversos
componentes importados, e assim, incrementa o corpo do XHTML e o resultado final
é visto na Figura 10.
Figura 10. Tela gerada do arquivo listadeestados.jsf
26
2.3. Views
As views de uma aplicação JSF nada mais são do que a interface da
aplicação. Trata-se das telas (páginas) que compõem a parte visual do sistema. As
views são responsáveis pelo contato direto com o usuário, interagindo com ele,
recebendo comandos (eventos) e retornando respostas do sistema. Entretanto, para
que haja comunicação com o sistema as views são dependentes dos managed beans,
que são as classes que recebem os dados inseridos na interface da aplicação.
2.4. Managed Beans
O objetivo principal das classes Managed Beans é se comunicar com as
Views da aplicação. Após essa comunicação, precisam repassar as informações
coletadas para as classes entidades, dentro do que rege as regras de negócios e
aguardar uma definição do processo e retornar uma resposta para a interface.
2.5. Domain Model
O primeiro passo foi verificar as configurações iniciais da aplicação. O
segundo passo foi organizar o processo de comunicação com o usuário e coleta de
dados (views e managed beans). O passo seguinte é trabalhar as classes de domínio,
ou seja, o tratamento desses dados. Essa é fase de elaboração das regras de negócios,
fase de definir o comportamento das classes que serão entidades do sistema e aquelas
que funcionarão como auxiliares dentro da lógica proposta.
O Model pode ser subdividido em subsistemas, na maneira mais
conveniente para o desenvolvedor, separando entidades, regras de negócios, beans,
DAO’s, etc. As configurações necessárias para o mapeamento objeto/relacional
(persistência) será aplicado nas classes entidades através de anotações JPA.
27
2.6 – Persistência
Persistência pode ser entendida como transformar as classes, mais
especificamente, as entidades do sistema, em objetos a serem refletidos no banco de
dados. Ela é estruturada na JPA e faz uso de um arquivo chamado persistence.xml.
O arquivo persistence.xml é o ponto de partida de qualquer aplicação que
use a JPA. Nele ficarão configurações responsáveis por informar com qual banco de
dados a aplicação deve se conectar, configurações específicas da implementação,
entidades a serem utilizados, arquivos de configurações e outros (COELHO, 2015).
A pasta META-INF é o local onde deve estar o arquivo de persistência,
caso não seja gerada pela IDE, pode ser criada manualmente, como mostrada abaixo
na Figura 11.
Figura 11 – Arquivo persistence.xml e sua localização no projeto academico.
28
3. RESULTADOS
Os resultados obtidos com esse trabalho são uma primeira versão do
Controle Acadêmico HUJM e a correspondente documentação do código fonte. O
Controle Acadêmico HUJM é parte do ambiente de desenvolvimento de aplicações
Java da SGPTI e tem como objetivo gerir toda a rotina dos acadêmicos que
frequentam as dependências do Hospital Universitário Julio Muller, contendo dados
pessoais dos alunos bem como dados que atestam o seu vínculo com o Hospital.
A criação e construção da aplicação transcorreram em paralelo à criação e
construção do framework de desenvolvimento da SGPTI ao qual o Controle
Acadêmico fará parte. Essa primeira versão da aplicação não pode ser considerada
como uma versão pronta, pois a mesma teve como primeiro objetivo atender aos
requisitos da disciplina Estágio Supervisionado e para a conclusão do Curso
Bacharelado em Ciência da Computação da Universidade Federal de Mato Grosso.
Entretanto, a mesma deverá passar pelo crivo da equipe de desenvolvimento da
SGPTI e passar por ajustes, se necessário, para que possa ser incorporada ao seu
ambiente.
Ao inicio do trabalho, a primeira preocupação foi em procurar atender os
requisitos do projeto dentro dos meios disponíveis pelo framework JSF e ferramentas
auxiliares.
Nas subsessões seguintes será descrito os pormenores e detalhes da
construção da aplicação.
3.1 - Configuração dos arquivos web.xml e faces-config.xml
Inicialmente, existem dois arquivos de configuração, que são o web.xml e
faces-config.xml.
O arquivo web.xml é o descritor padrão da implementação do módulo web
em
que
o
Faces
Servlets
está
definido.
O
principal
objetivo
do
o Faces Servlets é interceptar os pedidos para as páginas JSF, a fim de preparar o
contexto JSF antes de acessar a página JSF solicitada. A Figura 12 mostra o arquivo
web.xml do Acadêmico HUJM.
29
Figura 12. Arquivo web.xml.
Agora, passamos para o arquivo faces-config, que inclui a configuração
relacionado especificamente ao JSF. Na verdade, uma vez que JSF 2.0, o
arquivo faces-config se torna opcional, pois a maioria da configuração JSF pode ser
definida usando as anotações Java.
A Figura 13 mostra o arquivo de configuração faces-config do acadêmico
HUJM. À esquerda a localização do arquivo no projeto e à direita o conteúdo interno
do arquivo, com suas configurações, como se vê na imagem.
Figura 13. Arquivo faces-config.xml
30
3.2. Estrutura da aplicação
A estrutura da aplicação procurou seguir o padrão MVC, subdividindo o
projeto em Modelo, Visão e Controladores. Como foi dito no decorrer desse trabalho,
não há um padrão rigoroso de como deve ser distribuído os pacotes de códigos,
ficando ao critério do desenvolvedor, implementar de acordo com sua interpretação
do problema. No nosso caso em particular, entendeu-se que a parte que se refere aos
controladores seria representada pelos arquivos de configurações JSF. Veremos na
próxima subseção mais detalhada quais são esses arquivos e suas particularidades.
A parte que se refere às visões seriam distribuídas em subpastas existentes
na pasta webapp do projeto. Também será detalhada mais a frente.
E por fim, a parte que se refere ao Modelo ficou alocada no pacote Model.
Esse pacote é subdividido em outros subpacotes, de acordo com suas atribuições e
comportamento. Vale salientar que outros pacotes se fizeram necessários para
auxiliar no desenvolvimento da aplicação. Na Figura 14 vemos uma relação dos
pacotes criados no projeto acadêmico.
31
Figura 14 – Relação dos pacotes do projeto acadêmico.
Toda essa parte que constitui o folder src/main/java, mostrado na Figura 14
acima, representa toda a lógica da aplicação que está entre a interface e o banco de
dados. Logo abaixo aparece o folder src/main/resources destinado a arquivos que
servirão de recursos para a aplicação. O arquivo persistence.xml se encontra nesse
folder. Em seguida vemos duas pastas de testes, src/test/java e src/test/resources.
Entre meio as pastas de sistemas ficam a Maven Dependencies
(dependências do Maven), a JRE System Library (as bibliotecas Java) e as
Referenced Libraries (bibliotecas referenciadas). As dependências Maven são as
importações efetuadas pelo arquivo pom.xml. Já as bibliotecas Java, nesse caso
podem ser entendidas pela versão do jdk, indispensável para o projeto. As bibliotecas
referenciadas são arquivos ocasionais, que dependendo da necessidade, podem ser
agregadas a aplicação.
Cada uma das subpastas da lógica da aplicação será vistas nos tópicos
seguintes. Assim como será visto também, as subpastas que compõem a visão da
32
aplicação, no folder src/main/webapp. Essa outra parte da estrutura pode ser visto
na Figura 15, a seguir.
Figura 15 – Relação das pastas de visões do projeto acadêmico.
3.3. O arquivo pom.xml
O arquivo pom.xml é o responsável por importar todas as dependências
externas necessárias ao projeto. No cabeçalho do arquivo ficam as configurações do
repositório do próprio arquivo, como, por exemplo, o namespace e o esquema.
Seguido das configurações do arquivo local, dentro do projeto. A partir daí começam
as declarações de dependências.
33
O primeiro lote de dependências, visto na Figura 16, são as dependências da
Apache: BeanUtil e Commons IO. A dependência BeanUtil traz funcionalidades que
podem ser úteis em tarefas com classes beans, na comunicação com a interface. A
Commons IO também auxilia na comunicação com a interface, em funcionalidades
de entradas e saídas, como implementações de stream e filtros, por exemplo.
Figura 16. As dependências da Apache.
O segundo lote de dependências são responsáveis pela persistência dos
dados. Trata-se das dependências do Hibernate. São elas: Hibernate Core,
Hibernate EntityManager e Hibernate Validator. O Hibernate Core é nada mais
que o núcleo do Hibernate. As funcionalidades centrais do Hibernate se encontra
nessa dependência. Já no Hibernate EntityManager estão as configurações da JPA,
na criação das entidades para fazer o mapeamento objeto-relacional. A função do
Hibernate Validator é fazer a validação dos dados que serão persistidos no banco de
dados. Todas essas dependências estão na Figura 17, abaixo.
34
Figura 17. As dependências do Hibernate.
Esse terceiro lote de dependências é o mais extenso de todos do projeto. São
quatro dependências Javax. Em Java temos os pacotes principais, que são o núcleo
da linguagem. Javax é um pacote de extensão. As quatro dependências Javax
importadas para o projeto são: Javax CDI, Javax Faces, Javax Inject, Javax Servlet
e Javax Validation. E as funcionalidades seguem abaixo, respectivamente:
• javax cdi: reúne recursos para tratar das injeções e dependências de
contexto;
• javax faces: trata-se do núcleo que compila o JSF;
• javax inject: trata das injeções do JSF;
• javax servlet: compõem o servlet da aplicação.
Na Figura 18, vemos todas as dependências Javax.
35
Figura 18. As dependências Javax.
O quarto lote, na verdade são várias dependências unitárias, com exceção
das dependências do PrettyFaces. Começamos pela dependência da OmniFaces. A
OmniFaces é uma biblioteca de utilitários para JSF. A dependência seguinte trata do
driver do banco de dados, no nosso caso, do PostgreSQL. O PrettyFaces é um
redirecionador de URL para JSF e as suas dependências tratam da configuração e da
reescrita necessária para o redirecionamento. E a outra dependência, a do
PrimeFaces, é responsável pela remodelagem visual dos componentes JSF. Todas
essas dependências estão distribuídas na Figura 19, a seguir.
36
Figura 19. As dependências OmniFaces, PostgreSQL, PrettyFaces e PrimeFaces
Finalizando, temos as dependências do framework Springs, que são três:
Context, Core e TX. O Spring auxilia no fornecimento de injeções de dependências e
controla o ciclo de vida do JSF. No Build fica o compilador do Maven e demais
plugins, caso necessários. A Figura 20 mostra essa parte do arquivo pom.xml.
37
Figura 20. As dependências Springs e o Build.
3.4. As classes Model e os pacotes auxiliares
O pacote Model é subdivido em subpacotes: Beans, DAO e Entities. O
pacote Beans armazena os managed beans, assim como o pacote DAO armazena as
classes DAO e por fim, o pacote Entities, as entidades do projeto.
Um exemplo de managed bean é visto no Apêndice 1. A classe AlunoBean
instancia a entidade Aluno e um AlunoDAO. A entidade Aluno está representada no
Apêndice 2 e herda alguns atributos na entidade Pessoa, cujo código, devido sua
extensão está distribuído nos Apêndices 3, 4, 5 e 6. A classe AlunoDAO, que pode
ser vista na Figura 21, tem uma particularidade: não possui, de momento, atributos e
métodos. Só estende da classe GenericDAO, que aí sim, possui todas as
funcionalidades de um DAO, utilizáveis por todas as classes DAO do projeto. O
GenericDAO é exposto no Apêndice 7.
38
Figura 21. AlunoDAO
Além do pacote Model, ficou definido outros pacotes auxiliares: Converters,
Exceptions, Filters, Repository, Service, Util e Validators.
• Converters: é um pacote reservado às classes que têm por função serem
conversores de entidades. Muitos dados coletados em componentes tais como o
combobox não é a entidade propriamente dita e sim o id dessa entidade.
• Exceptions: pacote reservado ao tratamento dos casos de exceções;
• Filters: pacote reservado às informações que necessitam ser passar por um
sistema de filtro;
• Repository: pacote que trata a camada de persistência do banco de dados;
• Service: pacote que desempenha várias funções (serviços) para a
aplicação;
• Util: pacote que contém classes de utilidades diversas à aplicação;
• Validators: pacote reservado à validação de informações;
3.5. Converters
Quando há a necessidade de converter um objeto para o tipo String ou o
contrário usa-se um componente do JSF chamado converter. Sua atuação fica entre a
view (página JSF) e o Managed Bean. Na Figura 22 pode se ver o pacote Converter e
as classes que o compõe e no Apêndice 8, a classe AlunoConverter.
39
Figura 22. Pacote Converter
3.6. Exceptions
Um sistema deve estar preparado para situações inesperadas em sua
execução e é para isso que servem as exceções (exceptions, em inglês). Classes
Exceptions procuram tratar esses problemas. Nesse projeto as duas classes com essas
funcionalidades, a CustomExceptionHandler e a CustomExceptionHandlerFactory
auxiliam na navegação. O pacote Exceptions aparece juntamente com o pacote
Filters na Figura 23.
3.7. Filters
Na medida em que o usuário navega pela aplicação, efetuando comandos e
transações, é necessário realizar operações importantes para o sistema, antes o fluxo
de navegação seja concluído, e nesse projeto, a classe ConexaoFilters desempenha
esse papel. Entretanto, há funções específicas nos outros filtros. Destacamos aqui a
classe AlunoFilter, como exemplo, que é fundamental para o projeto, apesar de sua
simplicidade aparente, como verifica-se no Apêndice 9.
40
Figura 23. Pacotes Exceptions e Filters
3.8. Repository
A função desse pacote é trabalhar em conjunto com o pacote Converter.
Suas classes servem de repositório até que o processo de conversão de tipos das
páginas JSF e os managed beans seja concluída. A Figura 24 mostra o pacote
Repository e o pacote Service e no Apêndice 10, encontra-se a classe
AlunoRepository.
41
Figura 24. Pacotes Repository e Service.
3.9. Service
Para trabalhar com regras de negócios, como geração de listas de consultas,
foram criadas as classes Service, A vantagem desse tipo de solução é evitar
sobrecarregar as classes DAO. O Apêndice 11 exibe os códigos fontes da classe
AlunoService e também de AlunoServiceImpl.
3.10. Util
Esse pacote abriga várias classes que trabalham individualmente em funções
específicas, como por exemplo, o HibernateUtil, que cria as fábricas de sessões que
acessam o banco de dados. Nesse pacote estão outras classes importantes para o
sistema, tais como a FacesContextUtil e PhaseListenerUtil, etc. O Apêndice 12
mostra a classe HibernateUtil e suas propriedades.
42
3.11. Validators
No pacote Validators há duas classes: CPFValidator e EmailValidator.
Ambas as classes possuem algoritmos característicos para efetuar a validação dos
dados recebidos da interface e comprovar sua veracidade. A Figura 25 mostra o
pacote Validators, juntamente com o pacote Util, visto no tópico anterior.
25. Pacote Util
3.12. Views
As páginas do projeto (views) representam a interface da aplicação. São elas
que interagem com o usuário, ou seja, é o primeiro estágio do tráfego dos dados pelo
sistema. As figuras seguintes: Figura 26, Figura 27, Figura 28 e Figura 29 mostram
algumas das telas geradas pelo sistema.
43
Figura 26. Tela cadastrodecurso.jsf
Na Figura 26 podemos ver uma tela de cadastro. Ela é composta por um
cabeçalho, cujos componentes são oriundos de um arquivo template, que replica para
todas as telas do sistema. No corpo dessa página encontra-se um formulário
destinado ao cadastro de cursos, cujos campos incluem: nome do curso, instituição
de ensino, turma, estágio/atividade, data de criação no sistema e a data da última
alteração efetuada. Além dos botões Salvar e Voltar.
Figura 27. Tela listadeturmas.jsf
A Figura 27 assim como a figura anterior, importa o cabeçalho do sistema.
O corpo da página reflete o resultado de uma consulta que exibe uma lista de turmas.
44
Nesse exemplo em específico a consulta retornou uma lista vazia, pois não há turma
cadastrada. A tela tem como opção exibir o nome da turma, seu código e o curso ao
qual pertence. Acima da tabela gerada há um botão Nova Turma, que redireciona
para a tela Cadastro de Turmas.
Figura 28. Tela cadastrodealunos.jsf
A Figura 28 mostra uma das principais telas do Controle Acadêmico. A tela
Cadastro de Alunos é a responsável pela inclusão do aluno dentro do sistema. Seu
corpo é composto por um formulário subdividido em três painéis, sendo eles: Dados
do Aluno, Dados de Contato e Dados do Estágio/Atividade. Descrevemos abaixo
cada um dos componentes desses painéis:
Dados do Aluno: código interno (id gerada pelo sistema), Registro GEP
(código fornecido pelo HUJM), Registro RGA (código fornecido pela instituição de
ensino), CPF, RG, nome do aluno, sexo, data de nascimento, naturalidade, estado de
origem, instituição de ensino, nível de escolaridade, curso e turma;
45
Dados de Contato: endereço do aluno (logradouro), bairro, CEP,
complemento, cidade, estado, telefone residencial, celulares, contato e email;
Dados do Estágio/Atividade: descrição, programa, data de início, data de
término, horários, benefícios (uso de estacionamento e/ou biblioteca) e local, com
data de início e data fim.
A página possui também botões Gravar e Fechar para quando o processo
de cadastro esteja terminado. Outros botões são: o Adicionar, para incluir mais locais
ao estágio/atividade, os botões auxiliares de calendário nas datas e o botão Foto, para
capturar uma foto do aluno.
Figura 29. Tela cadastrodealunos.jsf após clique no botão Foto
A Figura 29 mostra a mesma tela da Figura 28, com a exceção de exibir
também uma janela pop-up com a imagem de uma webcam. Isso deve-se a um clique
no botão Foto,
logo abaixo do cabeçalho. Esse é um recurso oferecido pela
showcase do PrimeFace e configurado nessa página. Após clicar no botão Capture,
da janela suspensa, a imagem da webcam é salva em um local no disco rígido e
apenas o endereço dessa imagem é armazenada.
46
4. DIFICULDADES ENCONTRADAS
4.1. Padrão de Projeto
No início do projeto ficou definido que a aplicação seria desenvolvida com
as características JSF utilizando repositórios maven. Entretanto, ao utilizar a IDE do
Eclipse nota-se a raiz do Projeto JSF é totalmente diferente de um Projeto Maven.
Ao decorrer do tempo percebeu-se que não há uma maneira única de
desenvolver uma aplicação JSF, pode-se também criar um projeto de página
dinâmica web. São várias maneiras de se chegar a um mesmo objetivo.
Ao final, buscou-se não se desviar do que fora proposto e a aplicação foi
desenvolvida em JSF aos padrões Maven.
Definido que o projeto seguiria os padrões do Maven, outra vez verificou-se
que a raiz do projeto gerado pela IDE do Eclipse difere do padrão mencionado na
documentação do Maven. Depois de analisadas as diferenças, optou-se por seguir
com o padrão gerado pelo Eclipse, tendo em vista que mudanças provocariam atrasos
desnecessários.
4.2. Facelets e Servlets
Configurar Facelets e Servlet exige dedicação e concentração. Muitos
recursos podem não funcionar se não tiverem nas configurações especificas. Desde a
versão do JDK, passando pelo Server, se houver algum conflito de versões, a
aplicação pode não responder.
4.3. JavaServer Faces + PrimeFaces
Muitos recursos existentes no JSF também são encontrados na showcase do
PrimeFaces. Uma página XHML pode conter componentes do JSF e também do
PrimeFaces. No inicio alguns problemas na compilação desses componentes
surgiram devido a essa variedade e foi preciso se familiarizar com o comportamento
de cada um dos componentes.
47
4.4. Managed Beans
A parte que se refere aos Managed Beans foi desafiadora devido ao seu
comportamento. Também não há um padrão, podendo atuar apenas como um
comunicador com as views, recebendo tão somente os eventos e repassando para
outras classes que se encarregariam das regras de negócios, como também eles
próprios tratar das regras de negócios e se comunicarem com as views e com as
classes DAO.
4.5. Classes DAO
No que se refere às classes DAO, o impasse se deveu também pela ausência
de um padrão. As maneiras de implementar as DAO são as mais variadas. Uma
alternativa seria cada entidade possuir a sua DAO com o seu CRUD específico.
Outra maneira seria criar um DAO genérico e estendê-lo para as demais classes. Tem
implementações que separam as consultas em classes distintas.
4.6. Persistência
A persistência das classes com o banco pode ser feita através de arquivos de
configuração, como o hibernate.cfg.xml ou através de anotações. Optou-se pelas
anotações devido a uma maior facilidade com o conceito. Porém o uso de anotações
exige atenção com a validação da JPA.
4.7. Views
A dificuldade quanto as views deveu-se à pouca familiaridade em relação a
recursos de designer de interfaces web, como por exemplo, o CSS. Na medida do
possível procurou-se implantar esses conceitos.
48
5. CONCLUSÕES
O presente trabalho baseou-se nos conceitos de Desenvolvimento Java
Web, utilizando a tecnologia JSF (JavaServer Faces). O objetivo do trabalho foi
desenvolver uma ferramenta de controle acadêmico para o Hospital Universitário
Júlio Müller. A aplicação foi idealizada em uma estrutura Maven, seguindo os
padrões MVC para a geração dos pacotes, das telas e para a configuração do
ambiente.
No decorrer do estágio, com estudo dos conceitos e o uso das ferramentas,
foi possível implementar uma primeira versão da aplicação. A preocupação inicial
era aplicar os recursos do JSF, mas com o passar do tempo, novas atividades
surgiram, exigindo uma pluralidade de tecnologias envolvidas no sistema. Conceitos
como persistência de dados, mapeamento objeto-relacional, tratamento de eventos,
conversões, dentre outros tiveram que ser implantados no projeto.
Posteriormente novas funcionalidades podem ser integradas a aplicação,
tornando-a mais robusta, como por exemplo, gerenciamento de relatórios, controle de
usuários. Quando o Controle Acadêmico for incorporado ao ambiente de
desenvolvimento da SGPTI, e passar a ter acesso a todas as funcionalidades do
framework recém-implantado, alterações e adaptações serão necessárias, mas essas
mudanças não afetarão a estrutura do projeto, podendo perfeitamente ser
reaproveitado o código fonte.
49
6. REFERÊNCIAS BIBLIOGRÁFICAS
COELHO, Hebert; 2015. JPA Eficaz As melhores práticas de persistência de dados.
1a ed. São Paulo. Casa do Código.
DUDNEY, Bill; LEHR, Jonathan; WILLIS, Bill; MATTINGLY, LeRoy; 2004.
Mastering JavaServer Faces. 1a ed. Indianápolis, Indiana. Wiley Publishing.
FARIA, Thiago; 2015. Java EE 7 com JSF, PrimeFaces e CDI. 2a ed. São Paulo.
AlgaWorks.
FARIA, Thiago; MOREIRA JR, Normandes; 2015. JPA e Hibernate. 1a ed. São
Paulo. AlgaWorks.
JACOBI, Jonas; FALLOWS, John; 2006. Pro JSF and Ajax Building Rich Internet
Components. 1a. ed. Nova Iorque. Apress.
JUNEAU, Josh; 2014. JavaServer Faces Introduction by Example. 1a. ed. Nova
Iorque. Apress.
KEITH, Mike; SCHINCARIOL, Merrick; 2009. Pro JPA 2 Mastering the Java
Persistence API. 1a. ed. Nova Iorque. Apress.
PRESSMAN, Roger S.; 2011. Engenharia de Software Uma Abordagem
Profissional. 7a ed. Porto Alegre. AMGH.
SALEH, Hazem; CHRISTENSEN, Allan Lykke; WADIA, Zubin; 2013. Pro JSF
and HTML5 Building Rich Internet Components. 2a. ed. Nova Iorque. Apress.
SOMMERVILLE, Ian; 2011. Engenharia de Software. 9a ed. São Paulo. Pearson.
TONG, Kent Iok; 2009. Beginning JSF 2 APIs and JBoss Seam. 1a ed. Nova Iorque.
Apress.
50
7. APÊNDICES
APÊNDICE 1. Classe AlunoBean
51
APÊNDICE 2. Entidade Aluno
52
APÊNDICE 3. Entidade Pessoa (parte 1)
53
APÊNDICE 4. Entidade Pessoa (parte 2)
54
APÊNDICE 5. Entidade Pessoa (parte 3)
55
APÊNDICE 6. Entidade Pessoa (parte final)
56
APÊNDICE 7. GenericDAO
57
APÊNDICE 8. Classe AlunoConverter
58
APÊNDICE 9. Classe AlunoFilter
59
APÊNDICE 10. Classe AlunoRepository
60
APÊNDICE 11. As classes AlunoService e AlunoServiceImpl
61
APÊNDICE 12. HibernateUtil
62