UNIVERSIDADE FEDERAL DE MATO GROSSO INSTITUTO DE COMPUTAÇÃO COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 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

2 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

3 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)

4 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.

5 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.

6 SUMÁRIO LISTA DE FIGURAS....8 LISTA DE TABELAS... 9 LISTA DE SIGLAS E ABREVIATURAS RESUMO INTRODUÇÃO REVISÃO DE LITERATURA VISÃO GERAL DAS TECNOLOGIAS E APLICAÇÕES DE CAMADA ÚNICA APLICAÇÕES DE DUAS CAMADAS APLICAÇÕES MULTI-CAMADAS: WEB O PADRÃO MVC JAVA SERVLET JAVASERVER FACES MAPEAMENTO OBJETO RELACIONAL JPA E HIBERNATE MATERIAS, TÉCNICAS E MÉTODOS APACHE MAVEN FACELETS PAGES VIEWS MANAGED BEANS DOMAIN MODEL PERSISTÊNCIA RESULTADOS CONFIGURAÇÕES DOS ARQUIVOS WEB.XML E FACES-CONFIG.XML ESTRUTURA DA APLICAÇÃO O ARQUIVO POM.XML AS CLASSES MODEL E OS PACOTES AUXILIARES CONVERTERS EXCEPTIONS FILTERS REPOSITORY SERVICE UTIL VALIDATORS VIEWS

7 SUMÁRIO 4. DIFICULDADES ENCONTRADAS PADRÃO DO PROJETO FACELETS E SERVLETS JAVASERVER FACES + PRIMEFACES MANAGED BEANS CLASSES DAO PERSISTÊNCIA VIEWS CONCLUSÕES REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICES APÊNDICE 1. CLASSE ALUNOBEAN APÊNDICE 2. ENTIDADE ALUNO APÊNDICE 3. ENTIDADE PESSOA (PARTE 1) APÊNDICE 4. ENTIDADE PESSOA (PARTE 2) APÊNDICE 5. ENTIDADE PESSOA (PARTE 3) APÊNDICE 6. ENTIDADE PESSOA (PARTE FINAL) APÊNDICE 7. GENERICDAO APÊNDICE 8. CLASSE ALUNOCONVERTER APÊNDICE 9. CLASSE ALUNOFILTER APÊNDICE 10. CLASSE ALUNOREPOSITORY APÊNDICE 11. CLASSES ALUNOSERVICE E ALUNOSERVICEIMPL APÊNDICE 12. HIBERNATEUTIL

8 LISTA DE FIGURAS Figura 1 Arquitetura 1-tier (camada única) Figura 2 Arquitetura 2-tier (duas camadas) Figura 3 Arquitetura J2EE (multi-camadas) Figura 4 Padrão MVC Figura 5 Arquitetura JSF (MVC2) Figura 6 Ciclo de Vida JSF Figura 7 Diagrama de atividades (CRUD Aluno) Figura 8 Estrutura inicial do projeto acadêmico Figura 9 Arquivo listadeestados.xhtml Figura 10 Tela gerada do arquivo listadeestados.xhtml Figura 11 Arquivo persistence.xml Figura 12 Arquivo web.xml Figura 13 Arquivo faces-config.xml Figura 14 Relação de pacotes do projeto academico Figura 15 Relação das pastas de visões do projeto academico Figura 16 As dependências da Apache Figura 17 As dependências do Hibernate Figura 18 As dependências Javax Figura 19 As dependências OmniFaces, PostgreSQL, PrettyFaces, PrimeFaces Figura 20 As dependências Spring e o Build Figura 21 AlunoDAO Figura 22 Pacote Converter Figura 23 Pacotes Exceptions e Filters Figura 24 Pacotes Repository e Service Figura 25 Pacote Util Figura 26 Tela cadastrodecursos.jsf Figura 27 Tela listadeturmas.jsf Figura 28 Tela cadastrodealunos.jsf Figura 29 Tela cadastrodealunos.jsf após clique no botão Foto

9 LISTA DE TABELAS Tabela 1 O padrão modelo-visão-controlador (MVC) Tabela 2 Controle Facelets Page e Template Tags

10 LISTA DE SIGLAS E ABREVIATURAS API CSS HUJM HTTP IDE J2EE Application Programming Interface (Interface de Programação de Aplicação) Cascading Style Sheets (Linguagem de Folhas de Estilo) Hospital Universitário Júlio Müller Hypertext Transfer Protocol (Protocolo de Transferência de Hipertexto) Integrated Development Environment (Ambiente de Desenvolvimento Integrado) Java 2 Platform, Enterprise Edition (Plataforma Edição Empresarial) Java EE Java Enterprise Edition (Java Edição Empresarial) JPA JSF JSP MVC ORM POJO SGPTI XML Java Persistence API JavaServer Faces JavaServer Pages Model-View-Controller (Modelo-Visão-Controlador) Object-Relational Mapping (Mapeamento Objeto Relacional) Plain Old Java Objects (Velhos e Simples Objetos Java) Setor de Gestão de Processos e Tecnologia da Informação extensible Markup Language (Linguagem de Marcação Extensível) 10

11 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

12 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

13 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 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 . 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

14 Figura 1. Descreve a arquitetura de aplicações camada única. (Imagem adaptada de: < 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 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

15 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: < 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 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

16 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 , 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

17 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

18 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 Descrição MVC (Modelo-Visão Controlador) 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

19 Quando é usado Vantagens Desvantagens 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. É 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. 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. 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

20 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

21 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

22 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

23 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 PgAdmin 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

24 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

25 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 ui:component ui:composition ui:debug ui:define ui:decorate ui:fragment ui:include ui:insert ui:param ui:repeat ui:remove Descrição Define um componente modelo e especifica um nome de arquivo. Define uma composição de página e encapsula marcações JSF. Cria um componente de depuração, captura informações da árvore de componentes. Define o conteúdo que é inserido em um template de página. decora partes de uma página. Define um fragmento de modelo, assim como o ui:component, desconsiderando conteúdo exteriores a tag. Permite o encapsulamento de outra página XHTML e sua reutilização dentro de uma view. Insere conteúdo em um modelo. Passa parâmetros para um arquivo ou modelo. Iteração sobre uma coleção de dados. Remove conteúdo de uma pagina. Tabela 2 Controle Facelets Page e Template Tags (adaptado de JUNEAU). 25

26 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

27 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 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 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

28 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

29 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 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

30 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

31 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

32 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

33 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 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

34 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

35 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

36 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

37 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

38 Figura 20. As dependências Springs e o Build 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

39 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

40 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 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

41 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

42 Figura 24. Pacotes Repository e Service 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 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

43 3.11. Validators No pacote Validators há duas classes: CPFValidator e Validator. 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 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

44 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

45 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

46 Dados de Contato: endereço do aluno (logradouro), bairro, CEP, complemento, cidade, estado, telefone residencial, celulares, contato e ; 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

47 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 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 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

48 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 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 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 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

49 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

50 6. REFERÊNCIAS BIBLIOGRÁFICAS COELHO, Hebert; JPA Eficaz As melhores práticas de persistência de dados. 1 a ed. São Paulo. Casa do Código. DUDNEY, Bill; LEHR, Jonathan; WILLIS, Bill; MATTINGLY, LeRoy; Mastering JavaServer Faces. 1 a ed. Indianápolis, Indiana. Wiley Publishing. FARIA, Thiago; Java EE 7 com JSF, PrimeFaces e CDI. 2 a ed. São Paulo. AlgaWorks. FARIA, Thiago; MOREIRA JR, Normandes; JPA e Hibernate. 1 a ed. São Paulo. AlgaWorks. JACOBI, Jonas; FALLOWS, John; Pro JSF and Ajax Building Rich Internet Components. 1 a. ed. Nova Iorque. Apress. JUNEAU, Josh; JavaServer Faces Introduction by Example. 1 a. ed. Nova Iorque. Apress. KEITH, Mike; SCHINCARIOL, Merrick; Pro JPA 2 Mastering the Java Persistence API. 1 a. ed. Nova Iorque. Apress. PRESSMAN, Roger S.; Engenharia de Software Uma Abordagem Profissional. 7 a ed. Porto Alegre. AMGH. SALEH, Hazem; CHRISTENSEN, Allan Lykke; WADIA, Zubin; Pro JSF and HTML5 Building Rich Internet Components. 2 a. ed. Nova Iorque. Apress. SOMMERVILLE, Ian; Engenharia de Software. 9 a ed. São Paulo. Pearson. TONG, Kent Iok; Beginning JSF 2 APIs and JBoss Seam. 1 a ed. Nova Iorque. Apress. 50