RELATÓRIO DE ESTÁGIO SUPERVISIONADO SISTEMA PARA ELABORAÇÃO DE TERMOS DE REFERÊNCIA

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 SISTEMA PARA ELABORAÇÃO DE TERMOS DE REFERÊNCIA JORGE ARAÚJO BEZERRA 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 SISTEMA 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 de Ciência da Computação, do Instituto de Computação da Universidade Federal de Mato Grosso, como requisito 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 CERTIFICADO DE APROVAÇÃO Título: RELATÓRIO DE ESTÁGIO SUPERVISIONADO SISTEMA PARA ELABORAÇÃO DE TERMOS DE REFERÊNCIA Autor: JORGE ARAÚJO BEZERRA Trabalho aprovado em 28 de setembro de Comissão examinadora: Prof. Dr. Raphael de Souza Rosa Gomes Orientador Leonardo Luiz Braun Supervisor Prof. Dr. Allan Gonçalves de Oliveira Instituto de Computação - UFMT

4 Este trabalho é dedicado a minhas duas filhas, minha companheira, meu pai, minha mãe, minha irmã, a toda minha família, a meus colegas de trabalho e a todos que sempre me apoiaram durante o curso.

5 AGRADECIMENTOS A Deus pelo dom da vida, pelo entusiasmo e a força que me fez seguir em frente 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ília pelo apoio. Aos professores do Instituto de Computação, em especial, ao professor Raphael de Souza Gomes, meu coordenador, pela dedicação na correção desse trabalho. Agradecimentos especiais são direcionados a Lucia Antônia Beserra, Juvenal e Leonardo Luiz Braun, pessoas que me ajudaram a continuar no curso e deram todo apoio possível. A todos que de alguma forma contribuíram para meu sucesso durante o curso, o meu muito obrigado.

6 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

7 RESUMO Para atender necessidades do setor público, em especial o Hospital Universitário Júlio Muller, a elaborar termos de referência com rapidez, padronização, reduzir uso de papel e impressões, o presente trabalho tem como objetivo o desenvolvimento de um sistema que auxilie a elaboração de Termos de Referência, para isso foi utilizado as tecnologias padrõ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ção Wildfly10. Para a camada de persistência utiliza-se o padrão JPA implementado pelo Hibernate 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.

8 SUMÁRIO 1 INTRODUÇÃO Justificativa Objetivos Gerais Objetivos Específicos Organização do trabalho REVISÃO DA LITERATURA Termo de Referência Engenharia de software Engenharia de requisitos Requisitos funcionais Requisitos não funcionais Modelagem de Sistema UML Diagrama de classes Modelo Conceitual - DER Modelo Lógico Desenvolvimento Ágil de Software Banco de Dados Java EE Servlet Ciclo de Vida de um Servlet Contexts and Dependency Injection - CDI Beans CDI Escopos de beans CDI JSP MVC JSF Ciclo de vida ORM JPA Java Persistence Query Hibernate HQL

9 2.11 AJAX MATERIAIS, TÉCNICAS E MÉTODOS Estrutura do projeto Engenharia de requisitos Jboss Developer Studio PgAdmin III Maven Primefaces PrettyFaces GIT RESULTADOS O processo Os requisitos A modelagem Estrutura da aplicação Observer com CDI Telas do sistema CONCLUSÕES Dificuldades encontradas Versões futuras REFERÊNCIAS

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

11 LISTA DE TABELAS Tabela 1 Diagramas oficiais da UML Tabela 2 Escopos dos Beans CDI

12 LISTA DE ABREVIATURAS E SIGLAS API CSS CDI CRUD DAO DER DOM EJB HUJM HQL HTML IC Java EE JPA JPQL Application Programming Interface Cascading Style Sheet Context Injection Dependency Create Update Delete Data Access Object Diagrama Entidade Relacionamento Document Object Model Enterprise Java Bean Hospital Universitário Júlio Muller Hibernate Query Language HiperText Markup Language Instituto de Computação Java Enterprise Edition Java Persistence API Java Persistence Query Language

13 JSF JSP MVC ORM SGBD SGPTI TR UFMT UML XML Java Server Faces Java Server Pages Model View Controller Object Relational Mapping Sistema de Gerenciamento de Banco de Dados Setor de Gestão de Processos e Tecnologia da Informação Termo de Referência Universidade Federal de Mato Grosso Unified Modeling Language Extensible Markup Language

14 CAPÍTULO 1 INTRODUÇÃO O procedimento licitatório é dividido em duas fases interna e externa. A fase externa é a que vai desde a publicação do edital até a homologação do procedimento e adjudicação do objeto. A fase interna merece cuidado maior até que a fase externa. É neste momento que a administração pública define o objeto, estabelece os parâmetros da obra ou serviço que deseja contratar ou do bem que pretende adquirir. Nesta fase não se pode cometer 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 base para a elaboração do edital de licitações. Nele são descritos todos os elementos capazes de propiciar a avaliação do custo pela administração mediante especificações técnicas e completas, 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, procedimentos de fiscalização e gerenciamento de contratos, prazos de execução e sanções, tudo de forma clara, concisa e objetiva, sem condições, clausulas ou termos que restrinjam o caráter competitivo 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

15 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 mesmo item e cada setor escreve seu termo sem seguir um modelo, usando dos mais variados títulos de seção e ordem nos termos. Com isso o setor de compras perde muito tempo para analisá-los. A gestão tem necessidade de indicadores, mas diante desse cenário, é inviável produzi-los. 1.2 Objetivos Gerais Como objetivo geral, tem-se desenvolver um sistema para ajudar o HUJM a padronizar a elaboração dos Termos de Referência e permitir acesso rápido e fácil para controle 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 desenvolvimento do sistema; terceiro, dificuldades: são relatos dos principais problemas encontrados no decorrer desse trabalho; quarto, conclusão: é a visão geral e perspectivas para melhorias do sistema.

16 CAPÍTULO 2 REVISÃO DA LITERATURA Na realização desse projeto foi necessário estudar diversas tecnologias e padrões, alguns foram inclusive vistos no decorrer do curso, também foi necessário conhecimento 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ções abaixo. 2.1 Termo de Referência Termo de Referência é o primeiro documento da licitação, ele é a base para o edital, assim como acontece com o projeto básico, em outras modalidades de licitações. O termo é elaborado pelo setor que necessita de algo e a especificação desse algo torna-se o objeto da licitação, ele é construído em conjunto com a área de compras, e aprovado pela administração. Nas licitações que exigem modalidade pregão é necessário a elaboração do termo durante a fase interna do processo licitatório, nele estarão expostos as condições para 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 N o (BRASIL, 2000, art. 8) 1 deve-se observar as seguintes regras: 1

17 Capítulo 2. Revisão da Literatura 4 I - a definição do objeto deverá ser precisa, suficiente e clara, vedadas especificações que, por excessivas, irrelevantes ou desnecessárias, limitem ou frustrem a competiçã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 capazes de 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 de suprimento 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 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 as necessidades dos clientes para um sistema que tem uma finalidade determinada. O processo de descobrir, analisar, documentar e verificar esses requisitos é denominado engenharia de requisitos (SOMMERVILLE, 2011) Requisitos funcionais Os requisitos funcionais descrevem o que um sistema deve fazer. Eles dependem do tipo de software a ser desenvolvido, de seus possíveis usuários e da abordagem geral adotada pela organização ao elaborar os requisitos. Quando expressos como requisitos 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 de sistemas mais específicos descreve com detalhes as funções do sistema, suas entradas, saídas, exceções, etc (SOMMERVILLE, 2011) Requisitos não funcionais São requisitos que não estão diretamente relacionados a serviços oferecidos pelo sistema aos usuários. Eles podem estar relacionados às propriedades emergentes do sistema, como confiabilidade, tempo de resposta e ocupação de área. Uma das alternativas a esse cenário pode ser os requisitos definirem restrições sobre a implementação do sistema,

18 Capítulo 2. Revisão da Literatura 5 como capacidade dos dispositivos de E/S ou apresentação de dados para as interfaces com outros sistemas (SOMMERVILLE, 2011). 2.3 Modelagem de Sistema Modelagem de sistema é a abstração da ideia do sistema e representada através de desenhos, conhecidos como diagramas, cada diagrama ou modelo representa um ponto de vista ou uma funcionalidade do sistema que se pretende desenvolver (SOMMERVILLE, 2011) UML As linguagens fornecem vocabulário e regras para combinação de palavras com a finalidade de comunicar algo. Linguagens de modelagem são linguagens cujo vocabulário e regras têm o foco voltado à representação conceitual e física de um sistema. A linguagem UML é uma linguagem para elaboração de estruturas de projetos de software. O modelo permite 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 qualquer aspecto, ainda que seja um sistema trivial (BOOCH; RUMBAUGH; JACOBSON, 2000). De acordo com Fowler (2005) a UML é um conjunto de representações gráficas que 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 Objetivo Atividades Comportamento procedimental e paralelo Classes Classes, características e comportamento Comunicação Comunicação entre objetos, ênfase nas ligações Estruturas compostas Decomposição de uma classe em tempo de execução Distribuição Distribuição de artefatos dos nós Visão geral da interação Mistura do diagrama de sequência com o de atividade Objetos Exemplo de configurações de instâncias Pacotes Estrutura hierárquica em tempo de compilação Sequência Interação entre objetos, ênfase na sequência Máquinas de estado Como os eventos alteram um objeto no decorrer de sua vida Sincronismo Interação entre objetos, ênfase no sincronismo Casos de uso Como os usuários interagem com um sistema

19 Capítulo 2. Revisão da Literatura Diagrama de classes Os diagramas de classes são usados na criação de um modelo de sistema orientado a objetos para mostrar as classes de um sistema e as associações entre essas classes. Com outas palavras, uma classe de objetos pode ser pensada como sendo uma definição geral de um tipo de objeto do sistema. Uma associação é um link entre classes que indica algum relacionamento entre essas classes. Consequentemente cada classe pode precisar de algum conhecimento sobre sua classe associada (SOMMERVILLE, 2011). Segundo Fowler (2005) os principais elementos que compõem o diagrama de classes 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 a visibilidade 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 representada 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étodos da classe pai Modelo Conceitual - DER O diagrama Entidade-Relacionamento (DER) é um modelo conceitual de alto nível, criado na década de 70, ele é usado para modelar aplicações que manipulam banco de dados. Tem o objetivo de proporcionar aos usuários o entendimento das necessidades elencadas nos requisitos, eliminando dúvidas da equipe de desenvolvimento é uma ferramenta útil durante o projeto da base de dados, nesse diagrama deixa se de lado detalhes de como os dados serão armazenados (CAYRES, 2015) Modelo Lógico O Modelo Lógico é a representação do banco de dados como um conjunto de tabelas. Com isso, podemos utilizar esse modelo para representar a estrutura de um banco de dados relacional dentro do SGBD, para construir o modelo lógico usa-se como base o modelo conceitual que provavelmente já foi validado pelos usuários do sistema e demais atores envolvidos. Mas não é bem assim que acontece, costumeiramente os

20 Capítulo 2. Revisão da Literatura 7 desenvolvedores não fazem uso das boas práticas e pulam a etapa de elaboração do modelo conceitual, 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), é o processo de desenvolvimento rápido de software que são concebidos para produzir, rapidamente, 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 de incrementos, cada incremento inclui uma nova funcionalidade ao sistema. Mesmo existindo muitas abordagens para o desenvolvimento ágil de software, elas possuem algumas características comuns. 1. Os processos de especificação, projeto e implementação são intercalados. A especificação do sistema não é detalhada, a documentação do projeto é minimizada ou gerada automaticamente pelo ambiente de programação usado na implementação do sistema. O documento de requisitos do usuário apenas define os pontos mais relevantes do sistema. 2. O sistema é desenvolvido com o incremento de várias funcionalidades chamadas versões. Os usuários finais e outros stakeholders do sistema são envolvidos na especificação e avaliação de cada versão. Assim eles podem propor alterações ao software e novos requisitos que devem ser implementados em versões futuras. 3. Interfaces de usuário são geralmente desenvolvidas com um sistema interativo de desenvolvimento que permite a criação rápida de interfaces por meio de desenho e posicionamento de ícones na tela. O sistema pode gerar essas interfaces baseada na 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, queremos dizer fatos conhecidos que podem ser registrados e possuem significados implícitos. Por exemplo, 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 armazenado em um disco, usando um computador pessoal e um software como Microsoft

21 Capítulo 2. Revisão da Literatura 8 Figura 1 Desenvolvimento Ágil (SOMMERVILLE, 2011) Access ou Excel, essa coleção de dados armazenados e relacionados que tem um significado implí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 seguintes propriedades: Banco de dados representa algum aspecto do mundo real, muitas vezes chamado de mini mundo ou de universo de discurso. As mudanças feitas no mini mundo são refletidas no banco de dados. Banco de dados é uma coleção logicamente coerente de dados com algum significado inerente. 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 finalidade específica. Ele possui um grupo definido de usuários e as aplicações são predefinidas de 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 desenvolvimento de aplicações Java web, ela é composta por diversas bibliotecas e funcionalidades 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 seu respectivo objetivo, com isso ela é considerada como plataforma guarda-chuva (FARIA, 2015). Segundo Booch, Rumbaugh e Jacobson (2000) java EE é constituído por:

22 Capítulo 2. Revisão da Literatura 9 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 compatibilidade do Java com os produtos desenvolvidos. Um conjunto de Application Programing Interfaces (APIs) para permitir acesso genérico aos recursos comerciais e infraestrutura. Tecnologias que facilitem o desenvolvimento de aplicações Java comerciais Servlet Servlets são classes java, desenvolvidas com uma estrutura bem definida, quando instaladas junto a um Servidor que implementa um Servlet Container (servidor que executa Servlets, muitas vezes chamado de Servidor de Aplicações Java), tratam requisições vindas dos clientes.(gonçalves, 2007) A maior vantagem do servlet é oferecer ao desenvolvedor uma forma de processar as requisições Hypertext transfer Protocol (HTTP) que vêm do cliente e transmitir de volta uma resposta adequada. Eles desempenham bem esse papel e necessitam de poucos recursos para realizar essa funcionalidade (BOOCH; RUMBAUGH; JACOBSON, 2000) Ciclo de Vida de um Servlet Segundo GONÇALVES (2007) o Servlet possuí um ciclo de vida de 3 fases como 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 que conté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 o Servlet é finalizado.

23 Capítulo 2. Revisão da Literatura 10 Figura 2 Ciclo de vida do Servlet Contexts and Dependency Injection - CDI Para Java EE CDI é um dos vários recursos que ajuda a fortalecer a camada web e a camada transacional da plataforma. CDI é um conjunto de serviços que torna mais fá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 mais amplo, permitindo aos desenvolvedores uma grande flexibilidade para integrar vários tipos de componentes em um ambiente mais seguro, flexível e acoplado (ORACLE, 2014) Beans CDI Em CDI, bean é uma fonte de objetos contextuais que definem o estado do aplicativo 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

24 Capítulo 2. Revisão da Literatura Escopos de beans CDI Segundo Faria (2015) as anotações de escopo ilustradas na tabela 1 devem ser importadas do pacote javax.enterprise.context. Onde as 3 primeiras tem os nomes iguais as do pacote javax.faces.bean. Ao usar CDI, deve-se tomar cuidado para não importar o pacote contrário! A é da API JSF mas funciona se usado como CDI. As anotações de escopo do CDI é mostrado na tabela @ConversationScoped Tabela 2 Escopos dos Beans CDI Duração Interação com usuário em uma única requisição HTTP Interação com usuário entre muitas requisições HTTP, ou seja, a sessão do usuário. Estado compartilhado com todos os usuários durante toda a execução da aplicação. É o escopo padrão, se nenhum for especificado. Mantém o mesmo ciclo de vida do bean que o injetou. 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 geram páginas HTML. Dessa forma a página dinâmica é gerada pelo código JSP. Quando uma página JSP é carregada pela primeira vez pelo containner JSP, o código Java é compilado e gera um Servlet que é executado, assim as próximas requisições são enviadas diretamente ao Servlet, não sendo mais necessário recompilar o código Java. Página JSP é um arquivo script 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 em Servlets elas acabam tendo o mesmo ciclo de vida, sendo a inicialização, o atendimento a requisição, e a finalização.(gonçalves, 2007) 2.8 MVC MVC é um padrão de desenvolvimento e design que tenta separar a aplicação em três partes distintas. O Model que está relacionado ao trabalho que a aplicação administra, 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 ou executando algum método que a aplicação precise (GONÇALVES, 2007). De acordo com GONÇALVES (2007) a divisão do MVC é respectivamente:

25 Capítulo 2. Revisão da Literatura 12 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 conhece os controladores (controllers) e nem as apresentações (views), nem ao menos contém referência a algum deles. Portanto consideramos Model como as classes que trabalham na persistência e busca de dados. View: (Apresentação) é a representação visual dos dados do Model. Ou seja, é a responsá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 como esse deve ser alterado, revisto e qual Apresentação (view) deverá ser exibida. Segundo GONÇALVES (2007) é comum vermos aplicações web construídas com 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 isso surgiram duas implementações, sendo o modelo 1 representado pela figura 3 e o modelo 2 representado pela figura 4. O model 1 a arquitetura conhecida como Model 1 é muito comum no desenvolvimento 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. Envolve simplesmente a construção de uma aplicação como um conjunto de páginas JSP. Figura 3 Arquitetura Model 1 - (SESHADRI, 1999) 2 2

26 Capítulo 2. Revisão da Literatura 13 O model 2 é uma implementação mais complexa, o Controlador é um Servlet que recebe as requisições de usuário, repassa ao Modelo, o que é necessário e fornece ao 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 mostra a figura 4, mas a lógica que elas contém é somente a responsável por exibir a interface do usuário. A camada de modelo é totalmente encapsulada em objetos Java (GONÇALVES, 2007). Figura 4 Arquitetura Model 2 - (SESHADRI, 1999) JSF JavaServer Faces é uma tecnologia Java EE que foi projetada para facilitar o desenvolvimento de aplicações Web. O JSF é responsável pela interação do usuário com 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 e processando a ação e os eventos requisitados, após isso, encaminha o comando ao modelo ou a apresentação (GONÇALVES, 2007). O JSF foi definido pelo JCP (Java Community Process 4 ), com isso ele se tornou um padrão de desenvolvimento que facilita o trabalho dos desenvolvedores agilizando a criação de interfaces gráficas. Ele é baseado no padrão MVC que simplifica o desenvolvimento de sistemas (FARIA, 2015) JCP é um conjunto de grupos chamados de JSR que por sua vez (Java Specification Request). O JSR é a especificação de uma nova tecnologia.

27 Capítulo 2. Revisão da Literatura 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 componentes recuperada para a página requisitada, se ela já tiver sido exibida, caso contrário a estrutura hierárquica de componentes será criada. Aplicar valores de requisição: Fase onde cada componente da estrutura hierárquica, criado na fase anterior pode atualizar seu estado com informações vindas da requisição. Processar validações: Fase onde os valores submetidos são convertidos em tipos pré definidos e anexados aos componentes. É nesse momento que entra em ação os validadores e caso surja algum erro de conversão ou validação, invoca-se a fase de renderizaçã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ário sã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ário ao servidor são executados pelo modelo. O método pode retornar algum valor, uma URL, 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 repete toda vez que o usuário interage com a aplicação, sempre que uma requisição é feita ao servidor. A figura 5 ilustra o ciclo de vida do JSF inclusive quando ocorre erro de validação e ou conversão.

28 Capítulo 2. Revisão da Literatura 15 Figura 5 Ciclo de Vida JSF ORM Segundo Bauer e King (2007) mapeamento objeto relacional é o mapeamento de objetos para tabelas do banco de dados de forma transparente, o mapeamento é feito através de metadados que descrevem como os objetos devem ser transformados. Em sua essência, o ORM trabalha com transformações reversíveis de dados de uma representação para outra, isso causa diminuição da performance, no entanto, se o ORM é implementado como um middleware, existem várias oportunidades para otimização que não existiriam para na camada de persistência feita a mão. A gerência e o provimento de metadados que regem 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ção ORM consiste nas seguintes partes: 1. Uma API que realiza as operações básicas (CRUD) dos objetos das classes de persistê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

29 Capítulo 2. Revisão da Literatura 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 em relações do banco de dados, com JPA, os objetos são POJO (Plain Old Java Objects), ou seja, não é necessário muito esforço para tornar os objetos persistentes, bastando fazer algumas anotações nas classes que representam as entidades do sistema, com isso já podemos persistir ou consultar objetos (FARIA, 2015) 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 usada independentemente do SGDB utilizado. Sua estrutura é parecida com a do SQL (FARIA; JUNIOR, 2015) Hibernate O Hibernate é um framework que implementa e especificação JPA, um projeto audacioso que procura solucionar de forma completa o problema de gerenciar dados persistentes com java. O Hibernate é um framework objeto relacional e seu uso faz com que 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 exige do desenvolvedor que siga alguns padrões de desenvolvimento ao escrever a lógica de negócio e as classes de persistência. No mais o Hibernate comunica-se com o banco de dados de forma transparente como se fosse a própria aplicação (GONÇALVES, 2007) 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 HQL usa nomes de classes enquanto o SQL usa nomes de relações, HQL usa nome de atributos enquanto 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 e declarações feitas em JPQL são válidas na HQL também (BAUER; KING, 2007) AJAX Segundo GONÇALVES (2007) AJAX é a sigla para Asynchronous JavaScript and XML, podemos considerá-la como um conjunto de tecnologias incorporadas, sendo

30 Capítulo 2. Revisão da Literatura 17 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.

31 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 ferramenta podem ser visualizado nas figuras 12 e 13. Mysql Workbench: Modelagem do diagrama entidade relacionamento, diagrama disponível na figura 11. Planner: Elaboração e controle do cronograma. Bisage: Modelagem do fluxo de desenvolvimento do projeto, figura 10, e fluxo de como 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

32 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, Primefaces, 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) figura 6, a EAP esta dividida da seguinte forma. No pacote Gerenciamento do projeto temos Planejar Escopo (Termo de abertura do projeto, EAP, Declaração de escopo), Planejar Cronogramas (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), Modelagem (diagrama de classes, DER, BPMN). No pacote gerenciamento do desenvolvimento temos tecnologias (definição das tecnologias a serem utilizadas), Codificação (codificação do projeto), Testes (testes de inserção, busca, alteração e remoção).

33 Capítulo 3. Materiais, Técnicas e métodos 20 Figura 6 Estrutura Analítica do Projeto 3.2 Engenharia de requisitos Para levantamento dos requisitos foi utilizado o método entrevista sem uso de formulários, apenas bate papo, as anotações foram feitas em papel e posteriormente repassadas para o microcomputador com uso do software word Nas entrevistas com os principais envolvidos foram identificados os requisitos do sistema e em reuniões com a equipe do Setor de Gestão de Processos e Tecnologia da Informação foram definidos os principais requisitos não funcionais. 3.3 Jboss Developer Studio Figura 7 JBoss Developer Studio

34 Capítulo 3. Materiais, Técnicas e métodos 21 A figura 7 mostra a tela de boas-vindas da ferramenta de desenvolvimento individual, JBoss Developer Studio usada especialmente para produtividade extrema, ela foi construída com base no eclipse. O JBoss Developer Studio 1 fornece suporte completo ao ciclo de desenvolvimento, incluído um amplo conjunto de recursos, ferramentas e suporte a vários modelos de programaçã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 produtividade com Maven nativamente, e em testes com Arquillian. É totalmente testado e certificado para garantir que todos os plugins, componentes de tempo de execução, e suas dependências sejam compatíveis uns com os outros. 3.4 PgAdmin III Figura 8 PgAdminIII PgAdminIII 2, figura 8, é a plataforma de administração e desenvolvimento Open 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 e plataformas Windows para gerenciar PostgreSQL 7.3 e acima, executando em qualquer plataforma, bem como versões comerciais e derivados. 1 Disponível em 2 Disponível para Download em

35 Capítulo 3. Materiais, Técnicas e métodos 22 PgAdminIII foi concebido para responder às necessidades de todos os usuários, desde escrever consultas SQL simples até o desenvolvimento de bancos de dados complexos. A interface gráfica suporta todas as funcionalidades do PostgreSQL o que facilita a administração. 3.5 Maven Apache Maven é uma ferramenta para o gerenciamento de dependências nos projetos 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 editando apenas um arquivo, com isso diminui o número de decisões que os desenvolvedores precisam tomar. Para esse projeto foi criado um projeto pai hujm-administrativo, e os módulos administrativo-app, administrativo-model, administrativo-service, administrativo-web, administrativo-common conforme imagem 9, que herdam as dependê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 componentes são desenvolvidos com um princípio de design que afirma que "Um bom componente de interface deve ocultar a complexidade, mas manter a flexibilidade"ao fazê-lo. Considerando o DevRates.com, primefaces é o líder na escolha dos desenvolvedores para criar

36 Capítulo 3. Materiais, Técnicas e métodos 23 interfaces gráficas. Todos os componentes tem exemplos 3 de uso e uma boa documentação no site 4 da primefaces e a comunidade ajuda na correção de bugs PrettyFaces PrettyFaces é uma biblioteca OpenSource para Servlet, Java EE e JSF, que permite a criação de URLs amigáveis. PrettyFaces resolve vários problemas de URLs elegantes, 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 compatibilidade completa com JSF sem necessidade de outras configurações, nas versões mais recentes, a partir da 3.3.2, é possível usar anotações ao invés de fazer o mapeamento por arquivos XML, deixando seu uso mais fácil e transparente GIT Git é um sistema para controle de versões de arquivos, muito usado para versionamento de código, com seu uso, diversas pessoas podem trabalhar simultaneamente no mesmo projeto, alterando e ou criando novos arquivos e permitindo que os mesmos possam 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ódigo versionando, fazendo os pushes e commits necessários. 3 Exemplos: fonte: 6 Traduzido e adaptado de Started.html disponível em

37 24 CAPÍTULO 4 RESULTADOS Nas seções abaixo é apresentado os resultados obtidos com a realização desse projeto durante a disciplina de estágio supervisionado. 4.1 O processo O processo seguido na realização do projeto para o desenvolvimento do sistema e que o SGPTI adotou como padrão para as suas demandas de desenvolvimento esta modelado na figura 10. Esse processo mostra que todo projeto a ser desenvolvido pelo setor terá um plano de projeto; primeira etapa do processo, estando o plano de projeto assinado e autorizado, passa-se para a segunda etapa, onde temos a engenharia de requisitos; nessa etapa faz se o levantamento de requisitos por uso de entrevistas ou outras técnicas que forem necessárias, durante a especificação dos requisitos ocorrendo qualquer dúvida retorna-se à entrevista com os stakeholders, não havendo mais dúvidas e os requisitos estando completos, faz a modelagem do sistema, em seguida vem a fase de desenvolvimento; mesmo nessa fase pode ser necessário retornar a análise de requisitos e fazer novas entrevistas com os stakeholders para sanar as dúvidas. Depois passa à etapa de testes, não havendo problemas, o sistema vai para homologação, se não, volta a fase de desenvolvimento para proceder com as devidas correções, após a homologação efetiva-se a entrega e finaliza o projeto.

38 Capítulo 4. Resultados 25 Figura 10 Fluxo de desenvolvimento do sistema

39 Capítulo 4. Resultados Os requisitos Para construir qualquer sistema precisa de requisitos e para a construção desse sistema 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 macroproblemas com 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íticos com 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 as seguintes 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 as seguintes 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 do pedido. 10. O sistema deve permitir a inserção de itens para o termo de referência, com as seguintes informações: código usado no sistema de estoque, título, unidade de medida 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, indicar se 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 seguintes informaçõ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ídica com as seguintes informações: razão social, nome fantasia, natureza jurídica, CNPJ

40 Capítulo 4. Resultados 27 ou CPF, inscrição estadual, logradouro, bairro, CEP, site, , 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ência como 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 informações: número de protocolo, data de criação, pedido de compra, setor que esta elaborando o termo, título do termo, conteúdos, fornecedor e os itens que se pretende adquirir. Para cada item inserido deve indicar: a sequência do item no termo e quantidade. 16. O sistema deve permitir que cada item do termo de referência seja cotado com fornecedores 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 termo de referência, quantidade, unidade de medida, nome do fornecedor e preço. A quantidade é a mesmo do termo de referência. 17. Ao cotar cada item o sistema deve calcular o desvio padrão para os valores inseridos e 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ção inserida no sistema. 20. O sistema deve permitir a totalização por preço médio ou por menor preço, preços que 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 sem treinamento os usuários consigam usá-lo com poucas dificuldades; 2. Responsividade: O layout do sistema deve atender monitores com diversas resoluções e dispositivos mobile; 3. Utilizar tecnologia java + JSF: O desenvolvimento do sistema deve ser feito com a linguagem de programação java para web utilizando o framework JSF. 4. Wildfly10: A aplicação deve ser hospedada no servidor Wildfly O sistema deve utilizar o banco de dados PostgreSQL

41 Capítulo 4. Resultados Integração LDAP: O sistema deve fazer login usando protocolo LDAP e compatível com 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 no banco de dados é fundamental ter uma documentação dessa base de dados para auxiliar na manutenção e em módulos futuros. A seguir apresento uma breve descrição de cada tabela do bando de dados, a figura 11 mostra o DER completo. A tabela principal da base de dados é tr_termo_referencia que é completada pelos relacionamentos para juntas formarem o termo de referência, essa tabela tem como atributo principal titulo_objeto: é um título para o termo de referência; essa tabela 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 apresentação do conteúdo no termo de referência; essa tabela relaciona-se com tr_termo_referencia e com tr_template_termo_referencia. A tabela tr_template_termo_referencia tem como principais atributos descricao: representa os título de seção do termo de referência; texto_padrão: é um campo opcional onde fica um texto pré definido para o respectivo título de seção; flag: é um controle booleano para indicar qual dos títulos de seção representa a especificação dos serviç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 de seus dados como argumento para adquirir algum item, ela tem como atributos principais codigo_identificador: é um título que identifica o pedido de compra; numero: é o número do 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 relacionamentos que identificam cada item do termo de referência, a chave primaria dessa tabela é uma chave composta pelos id_tr_termo_referencia e id_tr_item, ela tem como principais atributos sequencia: representa a posição do item no termo de referência; quantidade: uso futuro; essa tabela relaciona-se com tr_termo_referencia, tr_item, tr_setor e tr_item_cotacao.

42 Capítulo 4. Resultados 29 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 termos de referência, ela tem como principais atributos descricao: é a especificação técnica do serviço ou produto que pretende adquirir; descricao_resumida: é um título para o item; codigo_sistema_externo: é para referenciar outro sistema onde o item já esteja cadastrado, ex: sistema de estoque. Essa tabela relaciona-se com tr_item_termo_referencia e tr_unidade_medida. A tabela tr_unidade_medida é para o cadastro das unidades de medida, ela tem como principais atributos descricao: especificação da unidade de medida; sigla: sigla da 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 principais atributos 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 indicar a hierarquia entre os setores, além disso ela relaciona-se com: tr_item_termo_referencia e tr_representante_setor. A tabela tr_representante_setor é para manter o cadastro dos servidores que fazem 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 é ou não chefe do setor; login_usuario: uso futuro, essa tabela relaciona-se unicamente com tr_setor. A tabela tr_item_cotacao é para manter a cotação de cada item que faz parte de algum termo de referência, ela tem como principais atributos preco: valor do item apresentado pelo fornecedor; quantidade: é a quantidade de itens que se pretende adquirir; limite_desvio_padrao: é uma enumeração para indicar o status do desvio padrão em relação ao item cotado, leva em consideração todos os fornecedores que ofertaram este item para o respectivo 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ísica ou jurídica, é usada nas cotações, os atributos dessa tabela identificam as informações básicas de um fornecedor como endereço, razão social ou nome, CNPJ ou CPF e contatos do respectivo fornecedor. Ela se relaciona unicamente com a tabela tr_item_cotacao. A tabela tr_cotacao_forncedor armazena efetivamente as cotações para cada fornecedor para isso ela possui os seguintes atributos valor_total: contabilização de todos os 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

43 Capítulo 4. Resultados 30 foi realizada a cotação; data_validade: data em que os preços cotados devem ser desconsiderados e uma nova cotação deverá ser feita, essa tabela relaciona-se com a tabela tr_termo_referencia e tr_item_cotacao. A tabela tr_acao_pde_termo_referencia é para interligar as ações do PDE a um termo de referência que esta sendo criada, com isso podemos ter o controle das ações do PDE expressas em termos de referência e esse pode ser usado como argumento para adquirir os itens especificados no termo, essa tabela é apenas um relacionamento da tabela tr_termo_referencia com a tabela pde_acao. A tabela pde_institucional é para controle do PDE da instituição, no caso o HUJM, ela é composta pelos seguintes atributos: apresentacao: para cadastro da apresentação do PDE, numero_versao: para cadastro da versão do PDE, valor_aprovado: valor total estipulado para o PDE; vigencia_ano_inicil: indica o ano de inicio da vigência do PDE; vigencia_ano_final: o ano que em acaba a vigência do PDE. Essa tabela relaciona se unicamente com pde_macro_problema. A tabela pde_macro_problema é para cadastro dos macroproblemas relacionados ao PDE, para isso ela contém os seguintes atributos, nome: título para o macroproblema; descricao: detalhamento do macroproblema; numero: ordem de relevância do macroproblema 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 para cada macroproblema, ela é composta pelos seguintes atributos, descricao: é a identificação do nó crítico; numero: ordem de relevância para o macroproblema, essa tabela relaciona-se com pde_macro_problema e pde_acao. A tabela pde_acao é para o cadastro das ações relacionadas a cada nó crítico identificado, ela é composta pelos seguintes atributos, descricao: indica a ação a ser tomada 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 com pde_no_critico, tr_acao_pde_termo_referenci e pde_ atividade. A tabela pde_atividadade é para cadastro das atividades relacionadas a cada ação do PDE, para isso ela é constituída pelos seguintes atributos, descricao: especificação das atividades necessárias para realizar a ação relacionada; numero: ordem de relevância que a atividade tem na realização da ação, essa tabela relaciona se unicamente com pde_acao.

44 Capítulo 4. Resultados 31 Figura 11 Diagrama Entidade Relacionamento

45 Capítulo 4. Resultados Estrutura da aplicação A estrutura da aplicação foi construída utilizando apache maven seguindo o padrão de projetos MVC, esse padrão separa o projeto em três camadas: modelo, visão e controladores. Com o uso do maven o projeto foi dividido nos seguintes módulos: administrativo-model: representa a camada de modelo do padrão MVC, nesse módulo encontra-se a lógica da aplicação e as classes de persistência que estão implementadas principalmente nos pacotes: br.ufmt.hujm.administrativo.math: Este pacote contém somente a classe Estatística, ela implementa o cálculo do desvio padrão. br.ufmt.hujm.administrativo.model.pde: pacote que contém as classes PdeAcao, PdeIntitucional, PdeMacroProblema e PdeNoCritico. Essas são as classes de persistência para controle do PDE, a estrutura das classes desse pacote pode ser visualizada no diagramas de classes da figura 12. br.ufmt.hujm.administrativo.model.tr: pacote que contém as classes TrConteudo, TrConteudoPK: classe composta por dois atributos que representa respectivamente 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 é a primary key da classe TrItemTermoreferencia, TrPedidoCompra, TrRepresentanteSetor, TrSetor, TrTemplate, TrTermoReferencia e TrUnidadeMedida. Essas são as classes de persistência que compõem o termo de referência, a lógica relacionada ao mesmo esta distribuído nessas mesmas classes, a estrutura completa de cada classe desse pacote pode ser visualizada no diagrama de classes da figura 13.

46 Capítulo 4. Resultados 33 Figura 12 Diagrama de classes pacote PDE

47 Capítulo 4. Resultados Figura 13 Diagrama de Classes pacote TR 34

48 Capítulo 4. Resultados 35 br.ufmt.hujm.administrativo.model.dominio: esse pacote é composto pelas enumerações DominioDesvioPadrao, DominioNacionalidade, DominioSexo, DominioSimNao, DominioUf, DominioTipoPessoa. Essas enumerações representam os domínios utilizados 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 views. administrativo-web: Esse módulo é responsável pelos controllers e pelas Os managedbeans para controle de cada view estão localizados na pasta src/main/java, as views estão na pasta src.main.webapp.resources.pages, na raiz dessa pasta temos as views login e home, nas subpastas pde e tr temos as views para as operações de CRUD com o PDE e TR. Na pasta src.main.webapp.web-inf estão os arquivos de configuração do JSF, como o faces-config.xml e web.xml e outros mais utilizados na aplicação. administrativo-service: Esse módulo é onde está a implementação do padrão DAO utilizado na aplicação juntamente com o arquivo hinernate.cfg.xml, mostrado na figura 15, esse arquivo é responsável pela conexão com o banco de dados e informar quais classes são persistentes. O pacote br.ufmt.hujm.administativo.dao contém exclusivamente um produtor de sessão hibernate.

49 Capítulo 4. Resultados 36 O pacote br.ufmt.hujm.administativo.dao.tr contém as classes DAO que implementão o CRUD para o pacote br.ufmt.hujm.administativo.model.tr do módulo administrativo-model. O pacote br.ufmt.hujm.administativo.dao.pde contém as classes DAO que implementão o CRUD para o pacote br.ufmt.hujm.administativo.model.pde do módulo administrativo-model.

50 Figura 15 Módulo administrativo-service e Hibernate.cfg.xml Capítulo 4. Resultados 37

51 Capítulo 4. Resultados Observer com CDI A aplicação faz uso do context injection dependecy (CDI) e da implementação do padrão observer que ele oferece, esse padrão esta sendo usado na aplicação em um managedbean aplicationscope como ouvidor, enquanto o método salvar,usado no managedbean viewscope, dispara um evento ao chamar o método fire da classe Event, esse evento é capturado pelo método atualizartrtempate que esta escutando uma ação para então poder disparar a atualização da lista de trtemplates, a figura 16 mostra o método que dispara o evento e a figura 17 mostra o método que fica ouvindo o evento. Figura 16 Observer método dispara evento

52 Capítulo 4. Resultados 39 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 de todas 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 ao Active Directory (AD), centralizando os usuários, mas em versão futura terá controle de acesso para permissionamento local, a figura 18 ilustra a tela de login. Figura 18 Tela de Login 1

53 Capítulo 4. Resultados 40 A figura 19 ilustra a tela de cadastro do PDE institucional, a barra de menu faz parte do layout e é usada em todo o sistema, assim como o conteúdo a cima dele, os demais componentes são <p:inputtext> da primefaces com uma máscara aplicada para diminuir os erros com entradas inválidas, essa tela é onde o usuário cadastra a versão do PDE, ano de inicio da vigência, ano de término da vigência, valor aprovado para o PDE e 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 quatro passos, no primeiro passo o usuário deve digitar o número do processo, número dado ao termo 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 na tela de setores e um <p:inputtext> para cadastro do título do termo de referência. Na parte inferior da tela tem três <p:commandbutton> que se repetem ao longo dos passos do wizard, o primeiro executa a ação voltar, o segundo a ação avançar e o terceiro salva o termo na base de dados, se todas as informações estiverem sido fornecidas corretamente, a figura 20 mostra o primeiro passo do wizard.

54 Capítulo 4. Resultados 41 Figura 20 Wizard termo de referência - passo 1 O segundo passo do wizard é composto por um <p:picklist> que do lado esquerdo lista todos os títulos de seção cadastrados no sistema, ao transferir esse título para 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. No lado direito é possível ordenar os títulos de seção para indicar a ordem em que cada um deles deve aparecer no termo de referência impresso e o <p:editor>, editor de texto para a especificação do texto que representara a seção, esse campo já vem preenchido caso o título de seção tenha um texto padrão cadastrado junto, mas o usuário fica livre para alterá-lo, o conteúdo inserido nesse campo faz parte do título de seção selecionado, nesse momento, do lado direito, enquanto os títulos estão do lado esquerdo esse campo permanece desabilitado para edição. A figura 21 mostra o passo 2 do termo de referência. Figura 21 Wizard termo de referência - passo 2

55 Capítulo 4. Resultados 42 O terceiro passo do wizard é onde o usuário indica fornecedores para o setor de compras realizar cotação, essa tela é composta por um <p:picklist> que do lado esquerdo lista todos os fornecedores cadastrados no sistema e ao passar algum para o lado direito significa que ele vai participar da cotação. Ao passar um fornecedor da direita para a esquerda, significa que ele não vai mais fazer parte da cotação. A figura 22 mostra o passo 3 do wizard. Figura 22 Wizard termo de referência - passo 3 O quarto passo do wizard é onde o usuário vai inserir os itens no termo de referência, para isso a tela disponibiliza dois <p:inputnumber>, um representa a ordem do item no termo de referência o outro representa a quantidade, um <p:autocomplete> que após digitar o terceiro caractere começa a sugerir itens que contenham os caracteres digitados em seu título, quanto mais caracteres é digitado mais precisa ficará a busca, caso o item nã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 para adicionar o item ao termo de referência, com isso ele aparece no <p:datatable>, essa tela tem um <p:selectoneradio> que é uma opção para mostrar os preços da cotação, eles podem ser exibidos por menor valor ou por valor médio. Os itens, depois de inseridos no termo de referência e exibidos no datatable, trazem três <p:commandbutton> com eles, o primeiro é 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 o quarto passo do wizard.

56 Capítulo 4. Resultados 43 Figura 23 Wizard - Termo de Referência - passo 4 A Tela de cotação é composta por um <ui:repeat> que recebe a lista de fornecedores do termo de referência e cria a lista de fornecedores dinamicamente com três <p:inputtext> para cada fornecedor, o primeiro é para exibir o nome do fornecedor, o segundo para digitar o preço do item que o fornecedor informou e o terceiro é para indicar se o preço esta dentro do limite de desvio padrão, esse campo é atualizado ao salvar a cotação. Salvando a cotação o desvio padrão é calculado, se tiver algum fornecedor fora do desvio uma mensagem é apresentada ao usuário como na figura 24, se não o sistema retorna 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

57 Capítulo 4. Resultados 44 fornecedor com o preço fora do desvio padrão, o <p:inputext> mais a direita ira mostra a mensagem correspondente. Figura 25 Visualizar cotação