relatÓrio de estÁgio supervisionado sistema para … · 2016-10-05 · relatório de estágio...

UNIVERSIDADE FEDERAL DE MATO GROSSOINSTITUTO DE COMPUTAÇÃO

COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM

CIÊNCIA DA COMPUTAÇÃO

RELATÓRIO DE ESTÁGIO SUPERVISIONADOSISTEMA PARA ELABORAÇÃO DE TERMOS DE

REFERÊNCIA

JORGE ARAÚJO BEZERRA

CUIABÁ - MT

2016


COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM

CIÊNCIA DA COMPUTAÇÃO

RELATÓRIO DE ESTÁGIO SUPERVISIONADOSISTEMA PARA ELABORAÇÃO DE TERMOS DE

REFERÊNCIA

JORGE ARAÚJO BEZERRA

Orientador: Prof. Dr. Raphael de Souza Rosa Gomes

Relatório de estágio apresentado ao Curso deCiência da Computação, do Instituto de Compu-tação da Universidade Federal de Mato Grosso,como requisito para obtenção do título de Ba-charel em Ciência da Computação

CUIABÁ - MT

2016


COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EMCIÊNCIA DA COMPUTAÇÃO

CERTIFICADO DE APROVAÇÃO

Título: RELATÓRIO DE ESTÁGIO SUPERVISIONADO SISTEMAPARA ELABORAÇÃO DE TERMOS DE REFERÊNCIA

Autor: JORGE ARAÚJO BEZERRA

Trabalho aprovado em 28 de setembro de 2016.

Comissão examinadora:

Prof. Dr. Raphael de Souza Rosa GomesOrientador

Leonardo Luiz BraunSupervisor

Prof. Dr. Allan Gonçalves de OliveiraInstituto de Computação - UFMT

Este trabalho é dedicado a minhas duas filhas,

minha companheira, meu pai, minha mãe, mi-

nha irmã, a toda minha família, a meus colegas

de trabalho e a todos que sempre me apoiaram

durante o curso.

AGRADECIMENTOS

A Deus pelo dom da vida, pelo entusiasmo e a força que me fez seguir emfrente e chegar até esse momento.

A meu avô Francisco que a pesar da distância, sempre me apoiou.

A meu tio Lucídio pela força em todos os momentos e a toda minha famíliapelo apoio.

Aos professores do Instituto de Computação, em especial, ao professor Raphaelde Souza Gomes, meu coordenador, pela dedicação na correção desse trabalho.

Agradecimentos especiais são direcionados a Lucia Antônia Beserra, Juvenale Leonardo Luiz Braun, pessoas que me ajudaram a continuar no curso e deram todo apoiopossível.

A todos que de alguma forma contribuíram para meu sucesso durante o curso,o meu muito obrigado.

Não acredite em algo simplesmente porque ouviu.

Não acredite em algo simplesmente porque todos falam a respeito...

Não acredite em algo simplesmente porque está escrito em seus livros religiosos.

Não acredite em algo só porque seus professores e mestres dizem que é verdade.

Não acredite em tradições só porque foram passadas de geração em geração.

Mas depois de muita análise e observação, se você vê que algo concorda com a razão, e

que conduz ao bem e benefício de todos, aceite-o e viva-o.

Buda

RESUMO

Para atender necessidades do setor público, em especial o Hospital Universitário JúlioMuller, a elaborar termos de referência com rapidez, padronização, reduzir uso de papele impressões, o presente trabalho tem como objetivo o desenvolvimento de um sistemaque auxilie a elaboração de Termos de Referência, para isso foi utilizado as tecnologiaspadrões do Setor de Gestão de Processos e Tecnologia da Informação (SGPTI), dentre elas:arquitetura MVC, Framework JSF e PrimeFaces, Apache Maven e servidor de aplicaçãoWildfly10. Para a camada de persistência utiliza-se o padrão JPA implementado peloHibernate que é o responsável pela persistência dos dados em uma base PostgreSQL.

Palavras chaves: MVC, Framework, JSF, PrimeFaces, Apache Maven, Wildfly10, JPA,

Hibernate, PostgreSQL.

SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Objetivos Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Organização do trabalho . . . . . . . . . . . . . . . . . . . . . . . . 2

2 REVISÃO DA LITERATURA . . . . . . . . . . . . . . . . . . . . 3

2.1 Termo de Referência . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Engenharia de software . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1 Engenharia de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.2 Requisitos funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.3 Requisitos não funcionais . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Modelagem de Sistema . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3.1 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3.1.1 Diagrama de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.2 Modelo Conceitual - DER . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.3 Modelo Lógico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4 Desenvolvimento Ágil de Software . . . . . . . . . . . . . . . . . . 7

2.5 Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.6 Java EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.6.1 Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.6.1.1 Ciclo de Vida de um Servlet . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.6.2 Contexts and Dependency Injection - CDI . . . . . . . . . . . . . . . . 10

2.6.2.1 Beans CDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.6.2.2 Escopos de beans CDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.7 JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.8 MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.9 JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.9.1 Ciclo de vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.10 ORM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.10.1 JPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.10.1.1 Java Persistence Query . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.10.2 Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.10.2.1 HQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.11 AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 MATERIAIS, TÉCNICAS E MÉTODOS . . . . . . . . . . . . . . . 18

3.1 Estrutura do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Engenharia de requisitos . . . . . . . . . . . . . . . . . . . . . . . 20

3.3 Jboss Developer Studio . . . . . . . . . . . . . . . . . . . . . . . . 20

3.4 PgAdmin III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.5 Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.6 Primefaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.7 PrettyFaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.8 GIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1 O processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 Os requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.3 A modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.4 Estrutura da aplicação . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4.1 Observer com CDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.5 Telas do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5 CONCLUSÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1 Dificuldades encontradas . . . . . . . . . . . . . . . . . . . . . . . 45

5.2 Versões futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

LISTA DE ILUSTRAÇÕES

Figura 1 – Desenvolvimento Ágil (SOMMERVILLE, 2011) . . . . . . . . . . . . 8Figura 2 – Ciclo de vida do Servlet . . . . . . . . . . . . . . . . . . . . . . . . . 10Figura 3 – Arquitetura Model 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Figura 4 – Arquitetura Model 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Figura 5 – Ciclo de vida do JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Figura 6 – Estrutura Analítica do Projeto . . . . . . . . . . . . . . . . . . . . . . 20Figura 7 – JBoss Developer Studio . . . . . . . . . . . . . . . . . . . . . . . . . 20Figura 8 – PgAdminIII . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Figura 9 – Projeto Maven Pai . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Figura 10 – Fluxo de desenvolvimento do sistema . . . . . . . . . . . . . . . . . . 25Figura 11 – Diagrama Entidade Relacionamento . . . . . . . . . . . . . . . . . . 31Figura 12 – Diagrama de classes pacote PDE . . . . . . . . . . . . . . . . . . . . 33Figura 13 – Diagrama de Classes pacote TR . . . . . . . . . . . . . . . . . . . . . 34Figura 14 – Módulo administrativo-model . . . . . . . . . . . . . . . . . . . . . . 35Figura 15 – Módulo administrativo-service e Hibernate.cfg.xml . . . . . . . . . . 37Figura 16 – Observer método dispara evento . . . . . . . . . . . . . . . . . . . . 38Figura 17 – Observer método ouvinte . . . . . . . . . . . . . . . . . . . . . . . . 39Figura 18 – Tela de Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Figura 19 – Cadastro do PDE Institucional . . . . . . . . . . . . . . . . . . . . . 40Figura 20 – Wizard termo de referência - passo 1 . . . . . . . . . . . . . . . . . . 41Figura 21 – Wizard termo de referência - passo 2 . . . . . . . . . . . . . . . . . . 41Figura 22 – Wizard termo de referência - passo 3 . . . . . . . . . . . . . . . . . . 42Figura 23 – Wizard - Termo de Referência - passo 4 . . . . . . . . . . . . . . . . 43Figura 24 – Salvar Cotação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Figura 25 – Visualizar cotação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

LISTA DE TABELAS

Tabela 1 – Diagramas oficiais da UML . . . . . . . . . . . . . . . . . . . . . . . 5Tabela 2 – Escopos dos Beans CDI . . . . . . . . . . . . . . . . . . . . . . . . . 11

LISTA DE ABREVIATURAS E SIGLAS

API Application Programming Interface

CSS Cascading Style Sheet

CDI Context Injection Dependency

CRUD Create Update Delete

DAO Data Access Object

DER Diagrama Entidade Relacionamento

DOM Document Object Model

EJB Enterprise Java Bean

HUJM Hospital Universitário Júlio Muller

HQL Hibernate Query Language

HTML HiperText Markup Language

IC Instituto de Computação

Java EE Java Enterprise Edition

JPA Java Persistence API

JPQL Java Persistence Query Language

JSF Java Server Faces

JSP Java Server Pages

MVC Model View Controller

ORM Object Relational Mapping

SGBD Sistema de Gerenciamento de Banco de Dados

SGPTI Setor de Gestão de Processos e Tecnologia da Informação

TR Termo de Referência

UFMT Universidade Federal de Mato Grosso

UML Unified Modeling Language

XML Extensible Markup Language

CAPÍTULO 1

INTRODUÇÃO

O procedimento licitatório é dividido em duas fases interna e externa. A faseexterna é a que vai desde a publicação do edital até a homologação do procedimento eadjudicação do objeto. A fase interna merece cuidado maior até que a fase externa. É nestemomento que a administração pública define o objeto, estabelece os parâmetros da obraou serviço que deseja contratar ou do bem que pretende adquirir. Nesta fase não se podecometer equívocos, ou acaba por comprometer as fases seguintes do procedimento.

É na fase interna que elabora-se o termo de referência o qual serve de basepara a elaboração do edital de licitações. Nele são descritos todos os elementos capazesde propiciar a avaliação do custo pela administração mediante especificações técnicas ecompletas, orçamentos detalhados, definindo os métodos e as definições de suprimentos,os critérios de aceitação do objeto, deveres do contratado e da contratante, procedimentosde fiscalização e gerenciamento de contratos, prazos de execução e sanções, tudo de formaclara, concisa e objetiva, sem condições, clausulas ou termos que restrinjam o carátercompetitivo do certame.

1.1 Justificativa

Na atual situação, do momento em que são elaborados até a construção do editalé difícil acompanhar o andamento desses termos, pois há uma grande quantidade de termos

Capítulo 1. Introdução 2

para analise e nenhuma ferramenta para auxiliar, seja com buscar ou com classificação,ocorre duplicação, setores diferentes em datas próximas fazem termos pedindo o mesmoitem e cada setor escreve seu termo sem seguir um modelo, usando dos mais variadostítulos de seção e ordem nos termos. Com isso o setor de compras perde muito tempo paraanalisá-los. A gestão tem necessidade de indicadores, mas diante desse cenário, é inviávelproduzi-los.

1.2 Objetivos Gerais

Como objetivo geral, tem-se desenvolver um sistema para ajudar o HUJM apadronizar a elaboração dos Termos de Referência e permitir acesso rápido e fácil paracontrole dos mesmos, ajudando principalmente o setor de compras.

1.3 Objetivos Específicos

Para a construção do sistema temos os seguintes objetivos específicos:

• Estudar sobre os conceitos que envolvem o termo de referência;

• Propor um processo comum para o desenvolvimento de sistemas pelo SGPTI

• Elicitar os requisitos funcionais e não funcionais do sistema;

• Documentar o sistema

• Construir um processo comum para a elaboração dos Termos de Referência;

• Implementar o sistema;

• Testar.

1.4 Organização do trabalho

Este relatório esta dividido da seguinte maneira, primeiro, revisão de literatura:onde será apresentada a fundamentação teórica e conhecimentos das tecnologias utilizadas;segundo, resultados: onde é apresentado o processo que foi seguido para desenvolvimentodo sistema; terceiro, dificuldades: são relatos dos principais problemas encontrados nodecorrer desse trabalho; quarto, conclusão: é a visão geral e perspectivas para melhoriasdo sistema.

CAPÍTULO 2

REVISÃO DA LITERATURA

Na realização desse projeto foi necessário estudar diversas tecnologias e pa-drões, alguns foram inclusive vistos no decorrer do curso, também foi necessário conheci-mento de gestão pública, especificamente na parte de licitações, durante o tramite interno.O embasamento teórico necessário para realização desse projeto esta exposto nas seçõesabaixo.

2.1 Termo de Referência

Termo de Referência é o primeiro documento da licitação, ele é a base para oedital, assim como acontece com o projeto básico, em outras modalidades de licitações. Otermo é elaborado pelo setor que necessita de algo e a especificação desse algo torna-se oobjeto da licitação, ele é construído em conjunto com a área de compras, e aprovado pelaadministração. Nas licitações que exigem modalidade pregão é necessário a elaboraçãodo termo durante a fase interna do processo licitatório, nele estarão expostos as condiçõespara a execução do contrato, as especificações do produto ou serviço e etc (GONÇALVES,2011).

Na fase preparatória do pregão, de acordo com o Decreto No 3.555 (BRASIL,2000, art. 8)1 deve-se observar as seguintes regras:1 http://www.planalto.gov.br/ccivil-03/decreto/D3555compilado.htm

Capítulo 2. Revisão da Literatura 4

I - a definição do objeto deverá ser precisa, suficiente e clara, vedadas es-pecificações que, por excessivas, irrelevantes ou desnecessárias, limitem ou frustrem acompetição ou a realização do fornecimento, devendo estar refletida no termo de referência;

II - o termo de referência é o documento que deverá conter elementos capazesde propiciar a avaliação do custo pela Administração, diante de orçamento detalhado,considerando os preços praticados no mercado, a definição dos métodos, a estratégia desuprimento e o prazo de execução do contrato;

2.2 Engenharia de software

De acordo com Sommerville (2011, p. 05) engenharia de software "é uma

disciplina de engenharia cujo foco está em todos os aspectos de produção de software”

ainda de acordo com Sommerville (2011, p. 03) “software não é apenas um programa ou

programas; ele inclui toda a documentação.“

2.2.1 Engenharia de requisitos

Os requisitos de um sistema são a especificação do que o sistema deve fazer,os serviços oferecidos e as restrições de funcionamento. Esses requisitos refletem asnecessidades dos clientes para um sistema que tem uma finalidade determinada. O processode descobrir, analisar, documentar e verificar esses requisitos é denominado engenharia derequisitos (SOMMERVILLE, 2011).

2.2.2 Requisitos funcionais

Os requisitos funcionais descrevem o que um sistema deve fazer. Eles depen-dem do tipo de software a ser desenvolvido, de seus possíveis usuários e da abordagemgeral adotada pela organização ao elaborar os requisitos. Quando expressos como requi-sitos de usuários, os requisitos funcionais são normalmente descritos de forma abstrata,para serem entendidos pelos usuários do sistema. No entanto, requisitos funcionais desistemas mais específicos descreve com detalhes as funções do sistema, suas entradas,saídas, exceções, etc (SOMMERVILLE, 2011).

2.2.3 Requisitos não funcionais

São requisitos que não estão diretamente relacionados a serviços oferecidospelo sistema aos usuários. Eles podem estar relacionados às propriedades emergentes dosistema, como confiabilidade, tempo de resposta e ocupação de área. Uma das alternativasa esse cenário pode ser os requisitos definirem restrições sobre a implementação do sistema,


como capacidade dos dispositivos de E/S ou apresentação de dados para as interfaces comoutros sistemas (SOMMERVILLE, 2011).

2.3 Modelagem de Sistema

Modelagem de sistema é a abstração da ideia do sistema e representada atravésde desenhos, conhecidos como diagramas, cada diagrama ou modelo representa um pontode vista ou uma funcionalidade do sistema que se pretende desenvolver (SOMMERVILLE,2011).

2.3.1 UML

As linguagens fornecem vocabulário e regras para combinação de palavras coma finalidade de comunicar algo. Linguagens de modelagem são linguagens cujo vocabulárioe regras têm o foco voltado à representação conceitual e física de um sistema. A linguagemUML é uma linguagem para elaboração de estruturas de projetos de software. O modelopermite compreender um sistema, não existe modelo completo o suficiente, sempre seránecessário mais de um, interconectados, para tornar possível o entendimento de qualqueraspecto, ainda que seja um sistema trivial (BOOCH; RUMBAUGH; JACOBSON, 2000).

De acordo com Fowler (2005) a UML é um conjunto de representações gráficasque ajuda na descrição e projeto de sistemas, principalmente sistemas orientado a objetos.Os diagramas que a UML descreve podem ser vistos na tabela 1.

Tabela 1 – Diagramas oficiais da UML

Diagrama ObjetivoAtividades Comportamento procedimental e paraleloClasses Classes, características e comportamentoComunicação Comunicação entre objetos, ênfase nas ligaçõesEstruturas compostas Decomposição de uma classe em tempo de execuçãoDistribuição Distribuição de artefatos dos nósVisão geral da interação Mistura do diagrama de sequência com o de atividadeObjetos Exemplo de configurações de instânciasPacotes Estrutura hierárquica em tempo de compilaçãoSequência Interação entre objetos, ênfase na sequênciaMáquinas de estado Como os eventos alteram um objeto no decorrer de sua vidaSincronismo Interação entre objetos, ênfase no sincronismoCasos de uso Como os usuários interagem com um sistema


2.3.1.1 Diagrama de classes

Os diagramas de classes são usados na criação de um modelo de sistemaorientado a objetos para mostrar as classes de um sistema e as associações entre essasclasses. Com outas palavras, uma classe de objetos pode ser pensada como sendo umadefinição geral de um tipo de objeto do sistema. Uma associação é um link entre classesque indica algum relacionamento entre essas classes. Consequentemente cada classe podeprecisar de algum conhecimento sobre sua classe associada (SOMMERVILLE, 2011).

Segundo Fowler (2005) os principais elementos que compõem o diagrama declasses são:

• propriedade: é a representação das características estruturais da classe.

• atributos: é o nome do atributo com a indicação do tipo ao qual ele pertence e avisibilidade dele, como privada(-) ou pública(+).

• associação: propriedade representada por uma linha cheia que une duas classes.

• multiplicidade: é a indicação de quantos objetos vão compor a propriedade repre-sentada pela associação.

• operações são as ações que a classe sabe realizar, ou seja os métodos.

• generalização é a indicação de que uma classe tem os mesmos atributos e métodosda classe pai.

2.3.2 Modelo Conceitual - DER

O diagrama Entidade-Relacionamento (DER) é um modelo conceitual de altonível, criado na década de 70, ele é usado para modelar aplicações que manipulam bancode dados. Tem o objetivo de proporcionar aos usuários o entendimento das necessidadeselencadas nos requisitos, eliminando dúvidas da equipe de desenvolvimento é uma ferra-menta útil durante o projeto da base de dados, nesse diagrama deixa se de lado detalhes decomo os dados serão armazenados (CAYRES, 2015).

2.3.3 Modelo Lógico

O Modelo Lógico é a representação do banco de dados como um conjuntode tabelas. Com isso, podemos utilizar esse modelo para representar a estrutura de umbanco de dados relacional dentro do SGBD, para construir o modelo lógico usa-se comobase o modelo conceitual que provavelmente já foi validado pelos usuários do sistemae demais atores envolvidos. Mas não é bem assim que acontece, costumeiramente os


desenvolvedores não fazem uso das boas práticas e pulam a etapa de elaboração do modeloconceitual, sem esse modelo para usar como referência o desenvolvedor certamente terádúvidas e na elaboração do modelo lógico corre o risco de deixar algum requisito de fora(CAYRES, 2015).

2.4 Desenvolvimento Ágil de Software

Desenvolvimento ágil de software, segundo (SOMMERVILLE, 2011), é oprocesso de desenvolvimento rápido de software que são concebidos para produzir, ra-pidamente, softwares úteis. A figura 1 exemplifica o processo de desenvolvimento ágil.O software não é desenvolvido por completo de uma só vez, mas como uma série deincrementos, cada incremento inclui uma nova funcionalidade ao sistema. Mesmo exis-tindo muitas abordagens para o desenvolvimento ágil de software, elas possuem algumascaracterísticas comuns.

1. Os processos de especificação, projeto e implementação são intercalados. A espe-cificação do sistema não é detalhada, a documentação do projeto é minimizada ougerada automaticamente pelo ambiente de programação usado na implementaçãodo sistema. O documento de requisitos do usuário apenas define os pontos maisrelevantes do sistema.

2. O sistema é desenvolvido com o incremento de várias funcionalidades chamadasversões. Os usuários finais e outros stakeholders do sistema são envolvidos naespecificação e avaliação de cada versão. Assim eles podem propor alterações aosoftware e novos requisitos que devem ser implementados em versões futuras.

3. Interfaces de usuário são geralmente desenvolvidas com um sistema interativo dedesenvolvimento que permite a criação rápida de interfaces por meio de desenhoe posicionamento de ícones na tela. O sistema pode gerar essas interfaces baseadana Web para um navegador ou para uma plataforma específica, como o Microsoft

Windows.

2.5 Banco de Dados

Banco de dados é uma coleção de dados relacionados. Com dados, queremosdizer fatos conhecidos que podem ser registrados e possuem significados implícitos. Porexemplo, considere os nomes, números de telefone e endereços das pessoas que vocêconhece. Você pode ter registrado esses dados em uma agenda ou, talvez, os tenha ar-mazenado em um disco, usando um computador pessoal e um software como Microsoft


Figura 1 – Desenvolvimento Ágil (SOMMERVILLE, 2011)

Access ou Excel, essa coleção de dados armazenados e relacionados que tem um significadoimplícito, chamamos banco de dados (ELMARI; NAVATHE, 2012).

Para Elmari e Navathe (2012) o uso comum do termo banco de dados énormalmente empregado para dados usados em sistemas computacionais e tem as seguintespropriedades:

• Banco de dados representa algum aspecto do mundo real, muitas vezes chamadode mini mundo ou de universo de discurso. As mudanças feitas no mini mundo sãorefletidas no banco de dados.

• Banco de dados é uma coleção logicamente coerente de dados com algum significadoinerente. Uma variedade de dados aleatória não pode ser considerada base de dados.

• Banco de dados é projetado, construído e populado tendo em mente uma finalidadeespecífica. Ele possui um grupo definido de usuários e as aplicações são predefinidasde acordo com o interesse ou necessidade do usuário pelas aplicações.

2.6 Java EE

Java EE (Java Platform Enterprise Edition) é a plataforma padrão para de-senvolvimento de aplicações Java web, ela é composta por diversas bibliotecas e funcio-nalidades que facilitam a implementação de sistemas web, requisitos de escalabilidade,segurança, integridade entre outros são amplamente suportados pelos servidores de aplica-ção. A plataforma Java EE é composta por uma série de tecnologias cada uma com seurespectivo objetivo, com isso ela é considerada como plataforma guarda-chuva (FARIA,2015).

Segundo Booch, Rumbaugh e Jacobson (2000) java EE é constituído por:


• Regras de construção para desenvolver aplicações Java EE comercias.

• Uma implementação de referência do Java EE que forneça visão operacional.

• Um conjunto de testes de compatibilidade para que terceiros atestem a compatibili-dade do Java com os produtos desenvolvidos.

• Um conjunto de Application Programing Interfaces (APIs) para permitir acessogenérico aos recursos comerciais e infraestrutura.

• Tecnologias que facilitem o desenvolvimento de aplicações Java comerciais.

2.6.1 Servlet

Servlets são classes java, desenvolvidas com uma estrutura bem definida,quando instaladas junto a um Servidor que implementa um Servlet Container (servidorque executa Servlets, muitas vezes chamado de Servidor de Aplicações Java), tratamrequisições vindas dos clientes.(GONÇALVES, 2007)

A maior vantagem do servlet é oferecer ao desenvolvedor uma forma deprocessar as requisições Hypertext transfer Protocol (HTTP) que vêm do cliente e transmitirde volta uma resposta adequada. Eles desempenham bem esse papel e necessitam de poucosrecursos para realizar essa funcionalidade (BOOCH; RUMBAUGH; JACOBSON, 2000).

2.6.1.1 Ciclo de Vida de um Servlet

Segundo GONÇALVES (2007) o Servlet possuí um ciclo de vida de 3 fasescomo mostra a figura 2:

• A inicialização: ocorre quando o Servlet é carregado pelo Servlet Container.

• O atendimento a requisições: enquanto o servidor estiver ativo e a aplicação quecontém o Servlet estiver carregada, este permanece na segunda fase de ciclo.

• A finalização: é quando a aplicação se torna inativa pelo Servlet Container, e oServlet é finalizado.


Figura 2 – Ciclo de vida do Servlet

2.6.2 Contexts and Dependency Injection - CDI

Para Java EE CDI é um dos vários recursos que ajuda a fortalecer a camadaweb e a camada transacional da plataforma. CDI é um conjunto de serviços que torna maisfácil para os desenvolvedores o uso dos Beans, juntamente com o framework JavaServer

Faces nas aplicações web. Projetado para uso com objetos stateful, CDI tem uso maisamplo, permitindo aos desenvolvedores uma grande flexibilidade para integrar vários tiposde componentes em um ambiente mais seguro, flexível e acoplado (ORACLE, 2014).

2.6.2.1 Beans CDI

Em CDI, bean é uma fonte de objetos contextuais que definem o estado doaplicativo e/ou a lógica (ORACLE, 2014).

O bean segundo ORACLE (2014) tem os seguintes atributos:

• Um conjunto de tipos

• Um conjunto de qualificadores

• Um escopo

• Opcionalmente, um Bean EL name

• Um conjunto de interligações

• A implementação do bean


2.6.2.2 Escopos de beans CDI

Segundo Faria (2015) as anotações de escopo ilustradas na tabela 1 devem serimportadas do pacote javax.enterprise.context. Onde as 3 primeiras tem os nomesiguais as do pacote javax.faces.bean. Ao usar CDI, deve-se tomar cuidado para nãoimportar o pacote contrário! A anotação @javax.faces.view.ViewScope é da API JSFmas funciona se usado como CDI. As anotações de escopo do CDI é mostrado na tabela 2.

Tabela 2 – Escopos dos Beans CDI

Escopo Duração@RequestScoped Interação com usuário em uma única requisição HTTP@SessionScoped Interação com usuário entre muitas requisições HTTP, ou seja,

a sessão do usuário.@ApplicationScoped Estado compartilhado com todos os usuários durante toda a

execução da aplicação.@Dependent É o escopo padrão, se nenhum for especificado. Mantém o

mesmo ciclo de vida do bean que o injetou.@ConversationScoped Interação com usuário entre muitas requisições HTTP, com o

início e término controlado pelo programador.

2.7 JSP

Java server pages são páginas Java embebidas em tags HTML que gerampáginas HTML. Dessa forma a página dinâmica é gerada pelo código JSP. Quando umapágina JSP é carregada pela primeira vez pelo containner JSP, o código Java é compilado egera um Servlet que é executado, assim as próximas requisições são enviadas diretamenteao Servlet, não sendo mais necessário recompilar o código Java. Página JSP é um arquivoscript a princípio intermediário que depois é compilado para um Servlet. O arquivo é précompilado ao receber a primeira requisição. Como as páginas JSP são convertidas emServlets elas acabam tendo o mesmo ciclo de vida, sendo a inicialização, o atendimento arequisição, e a finalização.(GONÇALVES, 2007)

2.8 MVC

MVC é um padrão de desenvolvimento e design que tenta separar a aplicaçãoem três partes distintas. O Model que está relacionado ao trabalho que a aplicação adminis-tra, a View, que esta relacionada a exibição dos dados ou informações da aplicação e porúltimo o Controller que coordena os dois anteriores apresentando a interface correta ouexecutando algum método que a aplicação precise (GONÇALVES, 2007).

De acordo com GONÇALVES (2007) a divisão do MVC é respectivamente:


• Model: (Modelo) é o objeto responsável pela representação dos dados do programa.Ele Maneja esses dados e controla suas transformações. Esse modelo não conheceos controladores (controllers) e nem as apresentações (views), nem ao menos con-tém referência a algum deles. Portanto consideramos Model como as classes quetrabalham na persistência e busca de dados.

• View: (Apresentação) é a representação visual dos dados do Model. Ou seja, é aresponsável por exibir os dados resultantes do Model ao usuário.

• Controller(Controlador) é o objeto que responde as ações executadas pelo usuário,atuando sobre os dados apresentados pelo modelo, ele informa ao Modelo comoesse deve ser alterado, revisto e qual Apresentação (view) deverá ser exibida.

Segundo GONÇALVES (2007) é comum vermos aplicações web construídascom código HTML misturado as regras de negócio. Isso aconteceu com JDBC e JSTL.Para resolver esse problema foi incorporado ao desenvolvimento o padrão MVC e com issosurgiram duas implementações, sendo o modelo 1 representado pela figura 3 e o modelo 2representado pela figura 4.

• O model 1 a arquitetura conhecida como Model 1 é muito comum no desenvolvi-mento de aplicações Web de pequeno porte, podendo ser chamada de page-centric.Esta arquitetura fornece o modo mais fácil de reunir uma aplicação Web. Envolvesimplesmente a construção de uma aplicação como um conjunto de páginas JSP.

Figura 3 – Arquitetura Model 1 - (SESHADRI, 1999) 2

2 http://www.javaworld.com/article/2076557/java-web-development/understanding-javaserver-pages-model-2-architecture.html


• O model 2 é uma implementação mais complexa, o Controlador é um Servlet querecebe as requisições de usuário, repassa ao Modelo, o que é necessário e forneceao usuário a visão correspondente ao resultado gerado na requisição feita por ele.As aplicações implementadas nesta arquitetura usam páginas JSP, como mostraa figura 4, mas a lógica que elas contém é somente a responsável por exibir ainterface do usuário. A camada de modelo é totalmente encapsulada em objetos Java(GONÇALVES, 2007).

Figura 4 – Arquitetura Model 2 - (SESHADRI, 1999) 3

2.9 JSF

JavaServer Faces é uma tecnologia Java EE que foi projetada para facilitaro desenvolvimento de aplicações Web. O JSF é responsável pela interação do usuáriocom o restante da aplicação e fornece ferramentas para criação de interfaces gráficas.Além disso, ele opera como controlador (controller) recebendo comandos do usuário eprocessando a ação e os eventos requisitados, após isso, encaminha o comando ao modeloou a apresentação (GONÇALVES, 2007).

O JSF foi definido pelo JCP (Java Community Process4), com isso ele setornou um padrão de desenvolvimento que facilita o trabalho dos desenvolvedores agili-zando a criação de interfaces gráficas. Ele é baseado no padrão MVC que simplifica odesenvolvimento de sistemas (FARIA, 2015).3 http://www.javaworld.com/article/2076557/java-web-development/understanding-javaserver-pages-

model-2-architecture.html4 JCP é um conjunto de grupos chamados de JSR que por sua vez (Java Specification Request). O JSR é a

especificação de uma nova tecnologia.


2.9.1 Ciclo de vida

Segundo Faria (2015) o ciclo de vida do JSF divide-se nas seguintes fases:

• Restaurar visão: Fase onde a visão é restaurada e a estrutura hierárquica de com-ponentes recuperada para a página requisitada, se ela já tiver sido exibida, casocontrário a estrutura hierárquica de componentes será criada.

• Aplicar valores de requisição: Fase onde cada componente da estrutura hierár-quica, criado na fase anterior pode atualizar seu estado com informações vindas darequisição.

• Processar validações: Fase onde os valores submetidos são convertidos em tipospré definidos e anexados aos componentes. É nesse momento que entra em ação osvalidadores e caso surja algum erro de conversão ou validação, invoca-se a fase derenderização de resposta, pulando as etapas seguintes e reexibindo a página atual,possibilitando ao usuário corrigir erros e submeter os dados novamente.

• Atualizar os valores do modelo: Fase em que os valores informados pelo usuáriosão atualizados nos objetos do modelo de dados e os valores locais são Limpos.

• Invocar a aplicação: Fase onde os eventos que originaram o envio do formulárioao servidor são executados pelo modelo. O método pode retornar algum valor, umaURL, ou simplesmente executar a ação sem nenhum retorno.

• Renderizar a resposta: A última fase é a renderização da resposta a qual gera aárvore de componentes nos seus estados atuais e a devolve ao cliente. Isso se repetetoda vez que o usuário interage com a aplicação, sempre que uma requisição é feitaao servidor.

A figura 5 ilustra o ciclo de vida do JSF inclusive quando ocorre erro devalidação e ou conversão.


Figura 5 – Ciclo de Vida JSF 5

2.10 ORM

Segundo Bauer e King (2007) mapeamento objeto relacional é o mapeamentode objetos para tabelas do banco de dados de forma transparente, o mapeamento é feitoatravés de metadados que descrevem como os objetos devem ser transformados. Em suaessência, o ORM trabalha com transformações reversíveis de dados de uma representaçãopara outra, isso causa diminuição da performance, no entanto, se o ORM é implementadocomo um middleware, existem várias oportunidades para otimização que não existiriampara na camada de persistência feita a mão. A gerência e o provimento de metadados queregem a transformação acrescenta um custo no tempo de desenvolvimento, mas o custoé menor do que o custo envolvido na manutenção de uma solução própria. Uma soluçãoORM consiste nas seguintes partes:

1. Uma API que realiza as operações básicas (CRUD) dos objetos das classes depersistência.

2. Uma API ou linguagem que especifique as consultas ou propriedades das classes.

3. Um facilitador para especificar o metadado mapeado

4. Uma técnica para que a implementação ORM interaja com os objetos transacionais,associação de recuperação preguiçosa, e outras funções de otimização.

5 https://pt.wikipedia.org/wiki/JavaServer_Faces


2.10.1 JPA

A API Java Persistence (JPA) é uma especificação que descreve um framework

para persistência de dados. A especificação contempla o mapeamento de objetos emrelações do banco de dados, com JPA, os objetos são POJO (Plain Old Java Objects), ouseja, não é necessário muito esforço para tornar os objetos persistentes, bastando fazeralgumas anotações nas classes que representam as entidades do sistema, com isso jápodemos persistir ou consultar objetos (FARIA, 2015).

2.10.1.1 Java Persistence Query

Para executar as operações CRUD com JPA usamos a JPQL (Java Persistence

Query Language) linguagem de consulta padrão da JPA, essa linguagem pode ser usadaindependentemente do SGDB utilizado. Sua estrutura é parecida com a do SQL (FARIA;JUNIOR, 2015).

2.10.2 Hibernate

O Hibernate é um framework que implementa e especificação JPA, um projetoaudacioso que procura solucionar de forma completa o problema de gerenciar dadospersistentes com java. O Hibernate é um framework objeto relacional e seu uso faz comque o desenvolvedor fique livre para se concentrar nos problemas da lógica do negócio,enquanto a persistência fica por conta dele. Apesar da facilidade em ser configurado exigedo desenvolvedor que siga alguns padrões de desenvolvimento ao escrever a lógica denegócio e as classes de persistência. No mais o Hibernate comunica-se com o banco dedados de forma transparente como se fosse a própria aplicação (GONÇALVES, 2007).

2.10.2.1 HQL

A HQL (Hibernate Query Language) é uma linguagem própria do Hibernate

para uso no lugar do SQL, inclusive, muito similar. Distinguindo se apenas porque o HQLusa nomes de classes enquanto o SQL usa nomes de relações, HQL usa nome de atributosenquanto o SQL usa nome de colunas, as herança do java são entendidas pela linguagem.A linguagem de consulta do JPA é um subconjunto do HQL, com isso, todas as consultas edeclarações feitas em JPQL são válidas na HQL também (BAUER; KING, 2007).

2.11 AJAX

Segundo GONÇALVES (2007) AJAX é a sigla para Asynchronous JavaScript

and XML, podemos considerá-la como um conjunto de tecnologias incorporadas , sendo


as principais: JavaScript e XML, usá-las em conjunto deixa o navegador mais interativo,devido as solicitações assíncronas. Ajax é composto por:

• HTML/XHTML e CSS: formam a camada visual da página web.

• DOM (Document Object Model): renderização e interação com o usuário;

• XML e XSLT: trocam e manipulam os dados;

• XMLHttpRequest: recupera dados de forma assíncrona;

• JavaScript: linguagem de scripts usada no cliente para unir essas tecnologias.

18

CAPÍTULO 3

MATERIAIS, TÉCNICAS E MÉTODOS

No ambiente de modelagem foram usadas as seguintes ferramentas:

• Astah: Modelagem dos diagramas de classes, os diagramas feitos com essa ferra-menta podem ser visualizado nas figuras 12 e 13.

• Mysql Workbench: Modelagem do diagrama entidade relacionamento, diagramadisponível na figura 11.

• Planner: Elaboração e controle do cronograma.

• Bisage: Modelagem do fluxo de desenvolvimento do projeto, figura 10, e fluxo decomo criar termos de referência no sistema.

• Microsoft Word: Especificação dos requisitos.

No ambiente de desenvolvimento foram usadas as seguintes ferramentas:

• Jboss Studio

• Wildfly10

• PgAdminIII

Capítulo 3. Materiais, Técnicas e métodos 19

• Java JDK 8u101

• PostgreSQL 9.4

Ainda no ambiente de desenvolvimento, foi utilizado o frameworks JSF, Pri-

mefaces, Java EE 7 e Hibernate.

O hardware utilizado durante o projeto possui as seguintes configurações:

1. Notebook Philco AMD C-70 APU with Radeon(tm) HD Graphics

• 320 GB HD

• 4 GB Ram

• Fedora 24 workstation 64 bits

2. Micro computador HP

• 320 GB HG

• 8 GB Ram

• Microsoft windows 7 professional 64 bits

3.1 Estrutura do projeto

O projeto foi montado conforme a EAP (Estrutura Analítica do Projeto) figura6, a EAP esta dividida da seguinte forma. No pacote Gerenciamento do projeto temosPlanejar Escopo (Termo de abertura do projeto, EAP, Declaração de escopo), PlanejarCronogramas (Elaboração do cronograma), Plano de riscos (Identificar riscos ao projeto,Indicar ação para os riscos), Plano de comunicação (Definição de como ocorre a comunica-ção com os envolvidos no projeto). No pacote gerenciamento da análise temos Requisitos(engenharia de requisitos), Stakeholdes (identificação dos principais envolvidos), Modela-gem (diagrama de classes, DER, BPMN). No pacote gerenciamento do desenvolvimentotemos tecnologias (definição das tecnologias a serem utilizadas), Codificação (codificaçãodo projeto), Testes (testes de inserção, busca, alteração e remoção).


Figura 6 – Estrutura Analítica do Projeto

3.2 Engenharia de requisitos

Para levantamento dos requisitos foi utilizado o método entrevista sem usode formulários, apenas bate papo, as anotações foram feitas em papel e posteriormenterepassadas para o microcomputador com uso do software word 2013. Nas entrevistas comos principais envolvidos foram identificados os requisitos do sistema e em reuniões com aequipe do Setor de Gestão de Processos e Tecnologia da Informação foram definidos osprincipais requisitos não funcionais.

3.3 Jboss Developer Studio

Figura 7 – JBoss Developer Studio


A figura 7 mostra a tela de boas-vindas da ferramenta de desenvolvimentoindividual, JBoss Developer Studio usada especialmente para produtividade extrema, elafoi construída com base no eclipse.

O JBoss Developer Studio 1 fornece suporte completo ao ciclo de desenvolvi-mento, incluído um amplo conjunto de recursos, ferramentas e suporte a vários modelos deprogramação e estruturas, inclusive o desenvolvimento Container (Docker, OpenShift, Red

Hat CDK), Java EE 7, RichFaces, JavaServer Faces (JSF), Enterprise JavaBeans (EJB),

Java Persistence API (JPA) e Hibernate, JAX-RS com REST Easy, Context Dependency

Injection (CDI), HTML5, e muitas outras tecnologias populares. Ele já traz a produtividadecom Maven nativamente, e em testes com Arquillian. É totalmente testado e certificado paragarantir que todos os plugins, componentes de tempo de execução, e suas dependênciassejam compatíveis uns com os outros.

3.4 PgAdmin III

Figura 8 – PgAdminIII

PgAdminIII 2, figura 8, é a plataforma de administração e desenvolvimentoOpen Source mais popular usada com o PostgreSQL, o mais avançado banco de dados Open

Source no mundo. O aplicativo pode ser usado em Linux, FreeBSD, Solaris, Mac OSX eplataformas Windows para gerenciar PostgreSQL 7.3 e acima, executando em qualquerplataforma, bem como versões comerciais e derivados.1 Disponível em http://developers.redhat.com/downloads/2 Disponível para Download em https://www.pgadmin.org/download/


PgAdminIII foi concebido para responder às necessidades de todos os usuários,desde escrever consultas SQL simples até o desenvolvimento de bancos de dados comple-xos. A interface gráfica suporta todas as funcionalidades do PostgreSQL o que facilita aadministração.

3.5 Maven

Apache Maven é uma ferramenta para o gerenciamento de dependências nosprojetos de software. Baseado no conceito de modelo de objeto de projeto (POM). Com eleé possível configurar um ambiente de desenvolvimento padronizado seguindo boas práticas,permitindo compilação, gerência de dependências e distribuição de uma aplicação editandoapenas um arquivo, com isso diminui o número de decisões que os desenvolvedoresprecisam tomar.

Para esse projeto foi criado um projeto pai hujm-administrativo, e osmódulos administrativo-app, administrativo-model, administrativo-service,administrativo-web, administrativo-common conforme imagem 9, que herdam asdependências comuns do pai, os filhos, as dependências específicas ficam no projeto filho.

Figura 9 – Projeto Maven Pai

3.6 Primefaces

PrimeFaces é uma biblioteca de componentes para uso com JSF, seus compo-nentes são desenvolvidos com um princípio de design que afirma que "Um bom componentede interface deve ocultar a complexidade, mas manter a flexibilidade"ao fazê-lo. Consi-derando o DevRates.com, primefaces é o líder na escolha dos desenvolvedores para criar


interfaces gráficas. Todos os componentes tem exemplos 3 de uso e uma boa documentaçãono site 4 da primefaces e a comunidade ajuda na correção de bugs 5.

3.7 PrettyFaces

PrettyFaces é uma biblioteca OpenSource para Servlet, Java EE e JSF, quepermite a criação de URLs amigáveis. PrettyFaces resolve vários problemas de URLselegantes, tais como: personalização e reescrita de URL, ações de carregamento da página,integração perfeita com a navegação JSF e links, a atribuição view-id dinâmico e compati-bilidade completa com JSF sem necessidade de outras configurações, nas versões maisrecentes, a partir da 3.3.2, é possível usar anotações ao invés de fazer o mapeamento porarquivos XML, deixando seu uso mais fácil e transparente 6.

3.8 GIT

Git é um sistema para controle de versões de arquivos, muito usado paraversionamento de código, com seu uso, diversas pessoas podem trabalhar simultaneamenteno mesmo projeto, alterando e ou criando novos arquivos e permitindo que os mesmospossam existir sem o risco de suas alterações serem sobrescritas (SCHMITZ, 2015).

Para versionar o código desse projeto foi utilizado o repositório da Atlasin

Bitbucket 7 e a ferramenta Atlasian SourceTree 8 como cliente para enviar e baixar o códigoversionando, fazendo os pushes e commits necessários.

3 Exemplos: http://www.primefaces.org/showcase/4 http://www.primefaces.org/5 fonte: http://www.primefaces.org/whyprimefaces6 Traduzido e adaptado de http://www.ocpsoft.org/docs/prettyfaces/3.3.3/en-US/html/Getting Started.html7 https://bitbucket.org/8 disponível em https://www.sourcetreeapp.com/

24

CAPÍTULO 4

RESULTADOS

Nas seções abaixo é apresentado os resultados obtidos com a realização desseprojeto durante a disciplina de estágio supervisionado.

4.1 O processo

O processo seguido na realização do projeto para o desenvolvimento do sis-tema e que o SGPTI adotou como padrão para as suas demandas de desenvolvimentoesta modelado na figura 10. Esse processo mostra que todo projeto a ser desenvolvidopelo setor terá um plano de projeto; primeira etapa do processo, estando o plano deprojeto assinado e autorizado, passa-se para a segunda etapa, onde temos a engenhariade requisitos; nessa etapa faz se o levantamento de requisitos por uso de entrevistas ououtras técnicas que forem necessárias, durante a especificação dos requisitos ocorrendoqualquer dúvida retorna-se à entrevista com os stakeholders, não havendo mais dúvidas eos requisitos estando completos, faz a modelagem do sistema, em seguida vem a fase dedesenvolvimento; mesmo nessa fase pode ser necessário retornar a análise de requisitos efazer novas entrevistas com os stakeholders para sanar as dúvidas. Depois passa à etapa detestes, não havendo problemas, o sistema vai para homologação, se não, volta a fase dedesenvolvimento para proceder com as devidas correções, após a homologação efetiva-se aentrega e finaliza o projeto.

Capítulo

4.R

esultados25

Figura 10 – Fluxo de desenvolvimento do sistema

Capítulo 4. Resultados 26

4.2 Os requisitos

Para construir qualquer sistema precisa de requisitos e para a construção dessesistema foram identificados os seguintes requisitos Funcionais:

1. O sistema deve permitir a inserção do PDE Institucional com as seguintes informa-ções versão, ano de vigência, apresentação do PDE e valor aprovado.

2. Para cada PDE inserido, o sistema deve permitir a inserção de vários macroproblemascom as seguintes informações: sequência, nome e descrição.

3. Para cada macroproblema, o sistema deve permitir a inserção de vários nós críticoscom as seguintes informações: sequência e descrição.

4. Para cada nó crítico, o sistema deve permitir a inserção de várias ações com asseguintes informações: sequência, valor da ação e descrição.

5. Para cada ação, o sistema deve permitir a inserção de várias atividades com asseguintes informações: sequência e descrição.

6. O sistema deve permitir a inserção de títulos de seção.

7. Para cada título de seção, o sistema deve permitir a inserção de texto padrão.

8. O sistema deve permitir a inserção de unidades de medida com as seguintes informa-ções: descrição e sigla.

9. O sistema deve permitir a inserção de pedidos de compra com as seguintes informa-ções: número do pedido, breve descrição, data do pedido e descrição detalhada dopedido.

10. O sistema deve permitir a inserção de itens para o termo de referência, com asseguintes informações: código usado no sistema de estoque, título, unidade demedida e descrição. Os itens podem ser usados em vários termos de referência.

11. O sistema deve permitir a inserção de setores com as seguintes informações: nome,sigla, setor pai, nome do responsável, indicar se elabora termo de referência, indicarse revisa termo de referência e indicar se aprova termo de referência.

12. O sistema deve permitir a inserção de representantes de setor com as seguintesinformações: nome, cargo, setor e indicar se é responsável pelo setor.

13. O sistema deve permitir a inserção de fornecedores seja pessoa física ao jurídicacom as seguintes informações: razão social, nome fantasia, natureza jurídica, CNPJ


ou CPF, inscrição estadual, logradouro, bairro, CEP, site, email, Skype, telefones,ramal, celular, nome para contato.

14. O sistema deve permitir a inserção de conteúdos que comporão o termo de referênciacomo um todo, conteúdo é composto por: título de seção e um texto.

15. O sistema deve permitir a inserção do termo de referência com as seguintes infor-mações: número de protocolo, data de criação, pedido de compra, setor que estaelaborando o termo, título do termo, conteúdos, fornecedor e os itens que se pre-tende adquirir. Para cada item inserido deve indicar: a sequência do item no termo equantidade.

16. O sistema deve permitir que cada item do termo de referência seja cotado comfornecedores que serão previamente selecionados e indicados no termo de referência,a cotação do item deve possuir as seguintes informações: identificação do termode referência, quantidade, unidade de medida, nome do fornecedor e preço. Aquantidade é a mesmo do termo de referência.

17. Ao cotar cada item o sistema deve calcular o desvio padrão para os valores inseridose indicar quais fornecedores estão fora desse desvio.

18. O sistema deve permitir que o termo de referência seja exportado no formato PDF.

19. O sistema deve permitir a alteração, visualização e exclusão de qualquer informaçãoinserida no sistema.

20. O sistema deve permitir a totalização por preço médio ou por menor preço, preçosque são informados na cotação, levando em conta o desvio padrão.

Os requisitos não funcionais levantados foram:

1. Facilidade de utilização: O sistema tem que ser intuitivo para que mesmo semtreinamento os usuários consigam usá-lo com poucas dificuldades;

2. Responsividade: O layout do sistema deve atender monitores com diversas resoluçõese dispositivos mobile;

3. Utilizar tecnologia java + JSF: O desenvolvimento do sistema deve ser feito com alinguagem de programação java para web utilizando o framework JSF.

4. Wildfly10: A aplicação deve ser hospedada no servidor Wildfly10.

5. O sistema deve utilizar o banco de dados PostgreSQL


6. Integração LDAP: O sistema deve fazer login usando protocolo LDAP e compatívelcom Active Directory Microsoft.

7. A aplicação deve ser independente de plataforma

4.3 A modelagem

Apesar do framework Hibernate deixar transparente a criação das tabelas nobanco de dados é fundamental ter uma documentação dessa base de dados para auxiliar namanutenção e em módulos futuros. A seguir apresento uma breve descrição de cada tabelado bando de dados, a figura 11 mostra o DER completo.

A tabela principal da base de dados é tr_termo_referencia que é comple-tada pelos relacionamentos para juntas formarem o termo de referência, essa tabelatem como atributo principal titulo_objeto: é um título para o termo de referência; essatabela se relaciona com mais cinco tabelas, tr_pedido_compra, tr_cotacao_fornecedor,tr_acao_pde_termo_referencia, tr_item_termo _referencia e tr_conteudo_termo_referencia.

A tabela tr_conteudo_termo_referencia, tem como principais atributos texto_conteudo: é o conteúdo de cada título de seção do termo; sequencia: é a ordem de apresen-tação do conteúdo no termo de referência; essa tabela relaciona-se com tr_termo_referenciae com tr_template_termo_referencia.

A tabela tr_template_termo_referencia tem como principais atributos des-cricao: representa os título de seção do termo de referência; texto_padrão: é um campoopcional onde fica um texto pré definido para o respectivo título de seção; flag: é umcontrole booleano para indicar qual dos títulos de seção representa a especificação dosserviços e quantitativos, dentre todos os títulos de seção só pode haver um com essa flag

no status true, essa tabela relaciona se apenas com tr_conteudo_termo_referencia.

A tabela tr_pedido_compra é para cadastro dos pedidos de compra e uso deseus dados como argumento para adquirir algum item, ela tem como atributos principaiscodigo_identificador: é um título que identifica o pedido de compra; numero: é o númerodo pedido; descrição: é onde pode ser descrito com mais palavras qual o objetivo do pedido,essa tabela relaciona-se unicamente com tr_termo_referencia.

A tabela tr_item_termo_referencia é onde ficam armazenados os relacio-namentos que identificam cada item do termo de referência, a chave primaria dessatabela é uma chave composta pelos id_tr_termo_referencia e id_tr_item, ela tem comoprincipais atributos sequencia: representa a posição do item no termo de referência; quan-tidade: uso futuro; essa tabela relaciona-se com tr_termo_referencia, tr_item, tr_setor etr_item_cotacao.


A tabela tr_item é para cadastro dos itens que comporão o termo de referência,esses itens precisão ser tecnicamente descritos e podem ser utilizados em vários termosde referência, ela tem como principais atributos descricao: é a especificação técnicado serviço ou produto que pretende adquirir; descricao_resumida: é um título para oitem; codigo_sistema_externo: é para referenciar outro sistema onde o item já estejacadastrado, ex: sistema de estoque. Essa tabela relaciona-se com tr_item_termo_referenciae tr_unidade_medida.

A tabela tr_unidade_medida é para o cadastro das unidades de medida, elatem como principais atributos descricao: especificação da unidade de medida; sigla: siglada unidade de medida descrita; essa tabela relaciona-se unicamente com tr_item.

A tabela tr_setor é para manter o cadastro dos setores, ela tem como principaisatributos nome: representa o nome do setor; nome_responsavel: nome do gestor do setor;sigla: sigla que identifica o setor; aprova_termo_referencia, elabora_termo_termo_referencia,revisa_termo_referencia: uso futuro; essa tabela possui um alto relacionamento para indi-car a hierarquia entre os setores, além disso ela relaciona-se com: tr_item_termo_referenciae tr_representante_setor.

A tabela tr_representante_setor é para manter o cadastro dos servidores quefazem parte de um setor, ela tem como principais atributos nome: nome do servidor; cargo:cargo ocupado pelo servidor, responsavel: é uma flag para controlar se o funcionário é ounão chefe do setor; login_usuario: uso futuro, essa tabela relaciona-se unicamente comtr_setor.

A tabela tr_item_cotacao é para manter a cotação de cada item que faz partede algum termo de referência, ela tem como principais atributos preco: valor do item apre-sentado pelo fornecedor; quantidade: é a quantidade de itens que se pretende adquirir; li-mite_desvio_padrao: é uma enumeração para indicar o status do desvio padrão em relaçãoao item cotado, leva em consideração todos os fornecedores que ofertaram este item para orespectivo termo de referência; essa tabela relaciona-se com: tr_item_termo_referencia,tr_fornecedor e tr_cotacao_fornecedor.

A tabela tr_fornecedor é para o cadastro de fornecedores, seja pessoa físicaou jurídica, é usada nas cotações, os atributos dessa tabela identificam as informaçõesbásicas de um fornecedor como endereço, razão social ou nome, CNPJ ou CPF e contatosdo respectivo fornecedor. Ela se relaciona unicamente com a tabela tr_item_cotacao.

A tabela tr_cotacao_forncedor armazena efetivamente as cotações para cadafornecedor para isso ela possui os seguintes atributos valor_total: contabilização de todosos itens que faz parte de um termo de referência e foi ofertado pelo mesmo fornecedor;valor_frete: preço cobrado para a entrega dos itens; data_cotação: dia, mês e ano que


foi realizada a cotação; data_validade: data em que os preços cotados devem ser des-considerados e uma nova cotação deverá ser feita, essa tabela relaciona-se com a tabelatr_termo_referencia e tr_item_cotacao.

A tabela tr_acao_pde_termo_referencia é para interligar as ações do PDE aum termo de referência que esta sendo criada, com isso podemos ter o controle das açõesdo PDE expressas em termos de referência e esse pode ser usado como argumento paraadquirir os itens especificados no termo, essa tabela é apenas um relacionamento da tabelatr_termo_referencia com a tabela pde_acao.

A tabela pde_institucional é para controle do PDE da instituição, no caso oHUJM, ela é composta pelos seguintes atributos: apresentacao: para cadastro da apresen-tação do PDE, numero_versao: para cadastro da versão do PDE, valor_aprovado: valortotal estipulado para o PDE; vigencia_ano_inicil: indica o ano de inicio da vigência doPDE; vigencia_ano_final: o ano que em acaba a vigência do PDE. Essa tabela relacionase unicamente com pde_macro_problema.

A tabela pde_macro_problema é para cadastro dos macroproblemas relaci-onados ao PDE, para isso ela contém os seguintes atributos, nome: título para o macro-problema; descricao: detalhamento do macroproblema; numero: ordem de relevância domacroproblema para o PDE; essa tabela relaciona se com pde_intitucional e pde_no_critico.

A tabela pde_no_critico é para o cadastro dos nós críticos identificados paracada macroproblema, ela é composta pelos seguintes atributos, descricao: é a identificaçãodo nó crítico; numero: ordem de relevância para o macroproblema, essa tabela relaciona-secom pde_macro_problema e pde_acao.

A tabela pde_acao é para o cadastro das ações relacionadas a cada nó críticoidentificado, ela é composta pelos seguintes atributos, descricao: indica a ação a sertomada para eliminar o nó crítico; valor_acao: custo estimado para realizar a ação exposta;numero: ordem de relevância da ação para o nó crítico, essa tabela relaciona se compde_no_critico, tr_acao_pde_termo_referenci e pde_ atividade.

A tabela pde_atividadade é para cadastro das atividades relacionadas a cadaação do PDE, para isso ela é constituída pelos seguintes atributos, descricao: especificaçãodas atividades necessárias para realizar a ação relacionada; numero: ordem de relevânciaque a atividade tem na realização da ação, essa tabela relaciona se unicamente compde_acao.

Capítulo

4.R

esultados31

Figura 11 – Diagrama Entidade Relacionamento


4.4 Estrutura da aplicação

A estrutura da aplicação foi construída utilizando apache maven seguindo opadrão de projetos MVC, esse padrão separa o projeto em três camadas: modelo, visão econtroladores. Com o uso do maven o projeto foi dividido nos seguintes módulos:

administrativo-model: representa a camada de modelo do padrão MVC, nessemódulo encontra-se a lógica da aplicação e as classes de persistência que estão implemen-tadas principalmente nos pacotes:

br.ufmt.hujm.administrativo.math: Este pacote contém somente a classeEstatística, ela implementa o cálculo do desvio padrão.

br.ufmt.hujm.administrativo.model.pde: pacote que contém as classesPdeAcao, PdeIntitucional, PdeMacroProblema e PdeNoCritico. Essas são as classes depersistência para controle do PDE, a estrutura das classes desse pacote pode ser visualizadano diagramas de classes da figura 12.

br.ufmt.hujm.administrativo.model.tr: pacote que contém as classesTrConteudo, TrConteudoPK: classe composta por dois atributos que representa respec-tivamente o termo de referência e o template, essa classe é para representar a primary

key da classe TrConteudo como chave composta pelo Hibernate; TrCotacaoFornecedor,TrFornecedor, TrItem, TrItemTermoReferencia, TrItemTermoReferenciaPK: essa classe écomposta por dois atributos que identificam o termo de referência e o item, essa classe é aprimary key da classe TrItemTermoreferencia, TrPedidoCompra, TrRepresentanteSetor,TrSetor, TrTemplate, TrTermoReferencia e TrUnidadeMedida. Essas são as classes depersistência que compõem o termo de referência, a lógica relacionada ao mesmo estadistribuído nessas mesmas classes, a estrutura completa de cada classe desse pacote podeser visualizada no diagrama de classes da figura 13.

Capítulo

4.R

esultados33

Figura 12 – Diagrama de classes pacote PDE

Capítulo

4.R

esultados34

Figura 13 – Diagrama de Classes pacote TR


br.ufmt.hujm.administrativo.model.dominio: esse pacote é compostopelas enumerações DominioDesvioPadrao, DominioNacionalidade, DominioSexo, Domini-oSimNao, DominioUf, DominioTipoPessoa. Essas enumerações representam os domíniosutilizados na aplicação.

A figura 14 mostra a estrutura do projeto pai (módulo) e exibe os filhos(submódulos).

Figura 14 – Módulo administrativo-model

administrativo-web: Esse módulo é responsável pelos controllers e pelasviews.

Os managedBeans para controle de cada view estão localizados na pastasrc/main/java, as views estão na pasta src.main.webapp.resources.pages, na raiz dessapasta temos as views login e home, nas subpastas pde e tr temos as views para as operaçõesde CRUD com o PDE e TR. Na pasta src.main.webapp.WEB-INF estão os arquivosde configuração do JSF, como o faces-config.xml e web.xml e outros mais utilizados naaplicação.

administrativo-service: Esse módulo é onde está a implementação do padrãoDAO utilizado na aplicação juntamente com o arquivo hinernate.cfg.xml, mostrado nafigura 15, esse arquivo é responsável pela conexão com o banco de dados e informar quaisclasses são persistentes.

O pacote br.ufmt.hujm.administativo.dao contém exclusivamente umprodutor de sessão hibernate.


O pacote br.ufmt.hujm.administativo.dao.tr contém as classes DAOque implementão o CRUD para o pacote br.ufmt.hujm.administativo.model.tr domódulo administrativo-model.

O pacote br.ufmt.hujm.administativo.dao.pde contém as classes DAOque implementão o CRUD para o pacote br.ufmt.hujm.administativo.model.pde

do módulo administrativo-model.

Capítulo

4.R

esultados37

Figura 15 – Módulo administrativo-service e Hibernate.cfg.xml


4.4.1 Observer com CDI

A aplicação faz uso do context injection dependecy (CDI) e da implementaçãodo padrão observer que ele oferece, esse padrão esta sendo usado na aplicação em ummanagedBean aplicationScope como ouvidor, enquanto o método salvar,usado no ma-

nagedBean viewScope, dispara um evento ao chamar o método fire da classe Event, esseevento é capturado pelo método atualizarTrTempate que esta escutando uma ação paraentão poder disparar a atualização da lista de trTemplates, a figura 16 mostra o método quedispara o evento e a figura 17 mostra o método que fica ouvindo o evento.

Figura 16 – Observer método dispara evento


Figura 17 – Observer método ouvinte

4.5 Telas do sistema

As telas são o visual do sistema, por elas os usuários interagem e desfrutam detodas as funcionalidades. O sistema esta com o thema Spark da primefaces que tem umaótima documentação 1, a primeira tela do sistema é a de login, o sistema esta integrado aoActive Directory (AD), centralizando os usuários, mas em versão futura terá controle deacesso para permissionamento local, a figura 18 ilustra a tela de login.

Figura 18 – Tela de Login

1 http://www.primefaces.org/spark/documentation.xhtml;jsessionid=6tvnhgpizahcu5e3gf7lglgu


A figura 19 ilustra a tela de cadastro do PDE institucional, a barra de menufaz parte do layout e é usada em todo o sistema, assim como o conteúdo a cima dele, osdemais componentes são <p:inputText> da primefaces com uma máscara aplicada paradiminuir os erros com entradas inválidas, essa tela é onde o usuário cadastra a versão doPDE, ano de inicio da vigência, ano de término da vigência, valor aprovado para o PDEe descreve com detalhes o PDE no campo Apresentação, esse campo é um <p:editor>

editor simples, de texto, fornecido pelo framework primefaces.

Figura 19 – Cadastro do PDE Institucional

A tela de cadastro de TR é um wizard primeFaces que conta com quatropassos, no primeiro passo o usuário deve digitar o número do processo, número dado aotermo de referência depois de protocolado junto ao setor de protocolo, esse campo é um<p:inputText> com uma máscara, a tela contém dois <p:selectOneMenu>, o primeiro épara informar a etapa de tramitação do termo de referência, isso será implantado no futuro,por enquanto esta desabilitado, o segundo é para selecionar o pedido de compra, esse éo pedido cadastrado na tela de compras,o terceiro é para seleção do setor, cadastrado natela de setores e um <p:inputText> para cadastro do título do termo de referência. Naparte inferior da tela tem três <p:commandButton> que se repetem ao longo dos passosdo wizard, o primeiro executa a ação voltar, o segundo a ação avançar e o terceiro salva otermo na base de dados, se todas as informações estiverem sido fornecidas corretamente, afigura 20 mostra o primeiro passo do wizard.


Figura 20 – Wizard termo de referência - passo 1

O segundo passo do wizard é composto por um <p:pickList> que do ladoesquerdo lista todos os títulos de seção cadastrados no sistema, ao transferir esse títulopara o lado direito, significa que o mesmo vai passar a compor o termo de referência,passando o de volta ao lado esquerdo, esta removendo ele do termo de referência. Nolado direito é possível ordenar os títulos de seção para indicar a ordem em que cada umdeles deve aparecer no termo de referência impresso e o <p:editor>, editor de texto para aespecificação do texto que representara a seção, esse campo já vem preenchido caso o títulode seção tenha um texto padrão cadastrado junto, mas o usuário fica livre para alterá-lo, oconteúdo inserido nesse campo faz parte do título de seção selecionado, nesse momento, dolado direito, enquanto os títulos estão do lado esquerdo esse campo permanece desabilitadopara edição. A figura 21 mostra o passo 2 do termo de referência.



O terceiro passo do wizard é onde o usuário indica fornecedores para o setor decompras realizar cotação, essa tela é composta por um <p:pickList> que do lado esquerdolista todos os fornecedores cadastrados no sistema e ao passar algum para o lado direitosignifica que ele vai participar da cotação. Ao passar um fornecedor da direita para aesquerda, significa que ele não vai mais fazer parte da cotação. A figura 22 mostra o passo3 do wizard.


O quarto passo do wizard é onde o usuário vai inserir os itens no termo dereferência, para isso a tela disponibiliza dois <p:inputNumber>, um representa a ordem doitem no termo de referência o outro representa a quantidade, um <p:autoComplete> queapós digitar o terceiro caractere começa a sugerir itens que contenham os caracteres digita-dos em seu título, quanto mais caracteres é digitado mais precisa ficará a busca, caso o itemnão esteja cadastrado é possível navegar até a tela de itens usando o <p:commandButton>

incluir e depois retornar. Estando os três campos preenchidos usa se o botão add item paraadicionar o item ao termo de referência, com isso ele aparece no <p:dataTable>, essa telatem um <p:selectOneRadio> que é uma opção para mostrar os preços da cotação, elespodem ser exibidos por menor valor ou por valor médio. Os itens, depois de inseridos notermo de referência e exibidos no datatable, trazem três <p:commandButton> com eles, oprimeiro é para fazer a cotação do item, isso deve ser feito para cada item, individualmente,o segundo é para alterar o item e o terceiro é para excluir o item. A figura 23 mostra oquarto passo do wizard.


Figura 23 – Wizard - Termo de Referência - passo 4

A Tela de cotação é composta por um <ui:repeat> que recebe a lista defornecedores do termo de referência e cria a lista de fornecedores dinamicamente comtrês <p:inputText> para cada fornecedor, o primeiro é para exibir o nome do fornecedor, osegundo para digitar o preço do item que o fornecedor informou e o terceiro é para indicarse o preço esta dentro do limite de desvio padrão, esse campo é atualizado ao salvar acotação. Salvando a cotação o desvio padrão é calculado, se tiver algum fornecedor forado desvio uma mensagem é apresentada ao usuário como na figura 24, se não o sistemaretorna ao quarto passo do wizard do termo de referência.

Figura 24 – Salvar Cotação

A figura 25 mostra a tela de cotação, porém, para um item já cotado antes,que esta sedo aberta para nova cotação ou apenas para visualização, caso tenha algum


fornecedor com o preço fora do desvio padrão, o <p:inpuText> mais a direita ira mostra amensagem correspondente.

Figura 25 – Visualizar cotação

45

CAPÍTULO 5

CONCLUSÕES

O estágio abordou estudos relacionados ao desenvolvimento de sistemasusando tecnologias Java para web. Durante o estágio foi possível produzir a documentaçãonecessária para desenvolvedor um sistema que atendesse a algumas necessidades básicasda administração pública, em especial, compras públicas. Também foi possível construir aprimeira versão funcional do sistema para elaboração de termos de referência, com isso jáé possível utilizá-lo para elaborar termos, fazer pesquisas usando filtros variados, incluir oPDE no sistema e usar as ações do PDE como referência nos termos, se necessário. Usandoo sistema além de dar agilidade ao fluxo de criação de termos, reduz-se o consumo depapel.

Os esforços empenhados para modelar processos, modelar dados, entrevistarusuários e desenvolver a aplicação, proporcionaram grande aprendizado para o aluno quepode colocar em prática muito dos conhecimentos adquiridos no decorrer do curso.

5.1 Dificuldades encontradas

Durante o decorrer desse trabalho algumas dificuldades foram encontradas,como alteração de tecnologia utilizada, pois começamos o desenvolvimento usando java1.7, Hibernate 3.3 e o servidor de aplicação JBoss 7.1, quando estava quase concluído o

Capítulo 5. Conclusões 46

projeto, foi decidido atualizar o JBoss para Wildfly10, que por si já obriga a atualização doHibernate e java JDK.

Outra adversidade foi a geração do relatório em PDF, na qual comecei usandoo Jasper, mas depois de inúmeras tentativas, não apresentou resultado satisfatório, mudeipara a biblioteca FlaySource que converte HTML para PDF, mesmo com essa bibliotecanem todos os relatórios eram convertidos, dependendo da entrada que o usuário fornecia,principalmente com textos copiado e colado, pois traziam tags XML ou HTML desneces-sárias, após muita pesquisa pude contornar esse empecilho usando a biblioteca Jsoup paralimpar o texto de entrada.

Como dificuldade, também tive a integração da aplicação com o ActiveDirec-

tory, nessa integração foi utilizado o apache shiro, no entanto, para a integração ocorrer deforma satisfatória foi necessário reescrever alguns métodos de autenticação do framework.

5.2 Versões futuras

Como sugestão complementar ao sistema, pode-se:

• Desenvolver a tramitação dos termos de referência.

• Acrescentar Lote para os termos de referência.

• Disponibilizar o cálculo da curva ABC para os itens do termo de referência.

• Acrescentar envio de email com os itens do termo aos fornecedores.

• Incrementar novos módulos para que juntos completem o fluxo para a elaboração deeditais de licitações e auxiliem nesse processo

47

REFERÊNCIAS

BAUER, C.; KING, G. Java Persistence com Hibernate. Ciênia moderna. [S.l.: s.n.], 2007.15, 16

BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML GUIA DO USUÁRIO. [S.l.: s.n.],2000. 5, 8, 9

CAYRES, P. H. Modelagem de banco de Dados. [S.l.: s.n.], 2015. 6, 7

ELMARI, R.; NAVATHE, S. B. Siatemas de banco de dados. 6a edição. ed. [S.l.: s.n.],2012. 8

FARIA, T. JAVA EE 7 Com JSF, Primefaces e CDI. 2a edição. ed. [S.l.: s.n.], 2015. 8, 11,13, 14, 16

FARIA, T.; JUNIOR, N. JPA e Hibernate. 1a edição. ed. [S.l.: s.n.], 2015. 16

FOWLER, M. UML Essencial: Um breve guia para a linguagem-padrão de modelagemde objetos. 3a edição. ed. [S.l.: s.n.], 2005. 5, 6

GONÇALVES, E. DESENVOLVENDO APLICAÇÕES WEB COM JSP, SERELETS,JAVASERVER FACES, HIBERNATE, EJB PERSISTENCE E AJAX. [S.l.: s.n.], 2007. 9, 11,12, 13, 16

GONÇALVES, P. Termo de Referência. 2011. Disponível em: <https://licitacaoviapetroniogoncalves.blogspot.com.br/2011/04/termo-de-referencia.html>. 3

ORACLE. Introduction to Contexts and Dependency Injection for Java EE. 2014.Disponível em: <https://docs.oracle.com/javaee/7/tutorial/cdi-basic.htm#GIWHB>. 10

SCHMITZ, D. Tudo que você queria saber sobre Git e GitHub, mas ti-nha vergonha de perguntar. 2015. Disponível em: <http://tableless.com.br/tudo-que-voce-queria-saber-sobre-git-e-github-mas-tinha-vergonha-de-perguntar/>. 23

https://licitacaoviapetroniogoncalves.blogspot.com.br/2011/04/termo-de-referencia.html

https://licitacaoviapetroniogoncalves.blogspot.com.br/2011/04/termo-de-referencia.html

https://docs.oracle.com/javaee/7/tutorial/cdi-basic.htm#GIWHB

http://tableless.com.br/tudo-que-voce-queria-saber-sobre-git-e-github-mas-tinha-vergonha-de-perguntar/

http://tableless.com.br/tudo-que-voce-queria-saber-sobre-git-e-github-mas-tinha-vergonha-de-perguntar/

Referências 48

SESHADRI, G. Understanding JavaServer Pages Model 2 architecture - Exploring theMVC design pattern. 1999. Disponível em: <http://www.javaworld.com/article/2076557/java-web-development/understanding-javaserver-pages-model-2-architecture.html>. 12,13

SOMMERVILLE, I. Engenharia de Software. 9a edição. ed. [S.l.: s.n.], 2011. vii, 4, 5, 6,7, 8

http://www.javaworld.com/article/2076557/java-web-development/understanding-javaserver-pages-model-2-architecture.html

http://www.javaworld.com/article/2076557/java-web-development/understanding-javaserver-pages-model-2-architecture.html

relatÓrio de estÁgio supervisionado sistema para … · 2016-10-05 · relatório de estágio...

Documents