Universidade Federal de Mato Grosso · modelo proposto em um Sistema Gerenciador de Banco de Dados...
50
UNIVERSIDADE FEDERAL DE MATO GROSSO INSTITUTO DE COMPUTAÇÃO COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO RELATÓRIO DE ESTÁGIO SUPERVISIONADO DESENVOLVIMENTO DE UM SISTEMA WEB DE GERENCIAMENTO DE RESOLUÇÕES DA UFMT GUSTAVO HAYASHI DO NASCIMENTO CUIABÁ – MT Ano 2016
Transcript of Universidade Federal de Mato Grosso · modelo proposto em um Sistema Gerenciador de Banco de Dados...
UNIVERSIDADE FEDERAL DE MATO GROSSO
INSTITUTO DE COMPUTAÇÃO
COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM
CIÊNCIA DA COMPUTAÇÃO
RELATÓRIO DE ESTÁGIO SUPERVISIONADO
DESENVOLVIMENTO DE UM SISTEMA WEB DE
GERENCIAMENTO DE RESOLUÇÕES DA UFMT
GUSTAVO HAYASHI DO NASCIMENTO
CUIABÁ – MT
Ano 2016
UNIVERSIDADE FEDERAL DE MATO GROSSO
INSTITUTO DE COMPUTAÇÃO
COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM
CIÊNCIA DA COMPUTAÇÃO
RELÁTORIO DE ESTÁGIO SUPERVISIONADO
DESENVOLVIMENTO DE UM SISTEMA WEB DE
GERENCIAMENTO DE RESOLUÇÕES DA UFMT
GUSTAVO HAYASHI DO NASCIMENTO
Relatório apresentado ao Instituto de
Computação da Universidade Federal de
Mato Grosso, para obtenção do título de
Bacharel em Ciência da Computação.
CUIABÁ – MT
Ano 2016
UNIVERSIDADE FEDERAL DE MATO GROSSO
INSTITUTO DE COMPUTAÇÃO
COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM
CIÊNCIA DA COMPUTAÇÃO
GUSTAVO HAYASHI DO NASCIMENTO
Relatório de Estágio Supervisionado apresentado à Coordenação do Curso de
Ciência da Computação como uma das exigências para obtenção do título de
Bacharel em Ciência da Computação da Universidade Federal de Mato Grosso
Aprovado por:
Prof. Dr. Allan Gonçalves de Oliveira
Instituto de Computação
(ORIENTADOR)
Prof. Jivago Medeiros Ribeiro
Instituto de Computação
(CONVIDADO)
Prof. MSc. Nielsen Cassiano Simões
Instituto de Computação
(SUPERVISOR)
DEDICATÓRIA
À minha família pelo apoio que sempre
me proporcionaram.
Aos meus professores por seus
ensinamentos.
Aos meus colegas que me apoiaram e
acompanharam durante esta fase de
minha vida.
AGRADECIMENTOS
Agradeço aos meus familiares por me apoiarem durante toda a vida, me
incentivando a buscar o melhor para mim. Aos meus professores que compartilharam
seus conhecimentos e me guiaram durante esta fase de meu aprendizado. Aos meus
colegas com quem compartilhei conhecimento e experiências, me acompanhando
durante esta fase de minha vida.
Obrigado a todos.
6
SUMÁRIO
LISTA DE FIGURAS .......................................................................................................................... 7
LISTA DE TABELAS .......................................................................................................................... 8
LISTA DE SIGLAS E ABREVIATURAS ......................................................................................... 9
RESUMO ............................................................................................................................................ 10
INTRODUÇÃO .................................................................................................................................. 11
1. REVISÃO DE LITERATURA .................................................................................................... 12
1.1. GESTÃO ELETRÔNICA DE DOCUMENTOS ................................................................................... 12 1.2. ENGENHARIA DE SOFTWARE ...................................................................................................... 13
1.2.1. Processos de Software .................................................................................................. 15 1.2.1.1. Modelo de Processo de Software ...................................................................................... 15 1.2.1.2. Atividades do processo ..................................................................................................... 16
1.2.2. Engenharia de Requisitos ............................................................................................. 19 1.2.2.1. Requisitos funcionais e não funcionais ............................................................................. 20 1.2.2.2. O documento de requisitos de software ............................................................................ 20 1.2.2.3. Especificação de requisitos ............................................................................................... 20
1.3. BANCO DE DADOS ..................................................................................................................... 21 1.3.1. Bancos de Dados Relacionais ........................................................................................... 21
1.3.1.1. ACID......................................................................................................................................... 25 1.3.1.2. SQL ........................................................................................................................................... 25
1.3.2. Bancos de Dados Não-Relacionais ................................................................................... 26
2. MATERIAS, TÉCNICAS E MÉTODOS ................................................................................... 30
2.1. MONGODB ................................................................................................................................ 30 2.2. JAVA SERVER FACES ................................................................................................................. 31 2.3. APACHE TOMCAT ...................................................................................................................... 33 2.4. ECLIPSE IDE E JAVA JDK .......................................................................................................... 33
3. RESULTADOS ............................................................................................................................. 35
3.1. LEVANTAMENTO DE REQUISITOS ............................................................................................... 35 3.2. MODELAGEM DOS DADOS ......................................................................................................... 36 3.3. MODELAGEM DO BANCO DE DADOS .......................................................................................... 40 3.4. IMPLEMENTAÇÃO....................................................................................................................... 43
4. DIFICULDADES ENCONTRADAS .......................................................................................... 47
5. CONCLUSÕES ............................................................................................................................. 48
6. REFERÊNCIAS BIBLIOGRÁFICAS ........................................................................................ 49
7
LISTA DE FIGURAS
FIGURA 1 - DIAGRAMA DE UM BD HIERÁRQUICO. ................................................................................ 22 FIGURA 2 - DIAGRAMA DE UM BD DE REDES. ....................................................................................... 23 FIGURA 3 - DIAGRAMA DE UM BD RELACIONAL. .................................................................................. 23 FIGURA 4 - DIAGRAMA DE UM BD ORIENTADO A OBJETOS. ................................................................. 24 FIGURA 5 - CÓDIGO JSON DE UM DOCUMENTO. ................................................................................... 27 FIGURA 6 - MODELO MVC DO JAVA SERVER FACES. ........................................................................... 32 FIGURA 7 - DIAGRAMA ENTIDADE RELACIONAMENTO. ........................................................................ 37 FIGURA 8 - MODELAGEM DOS DADOS DE UMA RESOLUÇÃO. ................................................................. 38 FIGURA 9 – MODELAGEM DE UM ARTIGO. ............................................................................................ 39 FIGURA 10 - MODELAGEM DO RELACIONAMENTO RESULTANTE DE RETIFICAÇÕES. .............................. 39 FIGURA 11 - DIAGRAMA DOS DADOS NO BANCO. ................................................................................. 42 FIGURA 12 - DIAGRAMA DE CLASSES. ................................................................................................... 43 FIGURA 13 - CÓDIGO EM JAVA PARA CONEXÃO, INSERÇÃO E ALTERAÇÃO DE DADOS NO MONGODB. .. 44 FIGURA 14 - MODELO INICIAL DA PÁGINA DE LISTAGEM DE RESOLUÇÕES. ........................................... 45 FIGURA 15 - CÓDIGO DO MODELO INICIAL DA PÁGINA DE LISTAGEM DE RESOLUÇÕES. ......................... 45 FIGURA 16 - CÓDIGO DA CLASSE QUE INTERAGE COM A VISÃO. ............................................................ 46
8
LISTA DE TABELAS
TABELA 1 - EXEMPLO DE DADOS EM UM BANCO ORIENTADO A CHAVES ............................................... 28 TABELA 2 - FORMA DE ARMAZENAMENTO EM LINHAS E COLUNAS ...................................................... 29
9
LISTA DE SIGLAS E ABREVIATURAS
RIM Records and Information Management
UFMT Universidade Federal de Mato Grosso
COLD Computer Output to Laser Disk
MVC Modelo-Visão-Controlador
ACID Atomicidade, Consistência, Isolamento e Durabilidade
AIIM Association for Information and Image Management
SGBD Sistema de Gerenciamento de Banco de Dados
DBMS DataBase Management System
ERM Enterprise Report Management
NOSQL Not Only Structured Query Language
BSON Binary JSON
JSON JavaScript Object Notation
ACID Atomicidade, Consistência, Isolamento e Durabilidade
SQL Structured Query Language
JSF Java Server Faces
DER Diagrama Entidade Relacionamento
GED Gerenciamento Eletrônico de Documentos
10
RESUMO
Este relatório tem como intuito apresentar as atividades realizadas durante o
estágio supervisionado. O objetivo do estágio foi de modelar o esquema de
resoluções utilizado pela Universidade Federal de Mato Grosso e implementar um
sistema web para armazenamento e visualização das resoluções. Primeiramente foi
feito o levantamento dos requisitos do sistema, seguido de um estudo do formato das
resoluções atuais. Como resultado do trabalho desenvolvido, tem-se a modelagem
conceitual de dados para o armazenamento das resoluções e, a implementação do
modelo proposto em um Sistema Gerenciador de Banco de Dados Orientado a
Documentos. Foi desenvolvida também uma tela de visualização das resoluções
inseridas no banco. Por limitações de tempo, o sistema não pode ser completamente
desenvolvido.
11
INTRODUÇÃO
O projeto desenvolvido durante o estágio supervisionado consiste de analisar,
projetar e implementar um sistema para gestão de documentos de resoluções dos
órgãos normativos presentes na Universidade Federal de Mato Grosso (UFMT).
A proposta do sistema partiu da necessidade de se criar um sistema para
facilitar desde a consulta a resoluções existentes, quanto á inserção de novas
resoluções e gerenciamento de retificações possíveis.
O objetivo definido durante o estágio foi de modelar as resoluções a serem
registradas, definir um SGBD apropriado para o projeto e implementar o projeto na
forma de um sistema web para a universidade.
O relatório foi organizado da seguinte forma: no Capítulo 1 é apresentado a
revisão de literatura dos fundamentos teóricos que servem de base para o relatório;
no Capítulo 2 são introduzidas as tecnologias utilizadas durante o estágio
supervisionado para o desenvolvimento do projeto; no Capítulo 3 são apresentados
os resultados atingidos durante o período do estágio; no Capítulo 4 são mencionados
as dificuldades encontradas durante o período do estágio e no Capítulo 5 as
conclusões chegadas ao fim do estágio.
12
1. REVISÃO DE LITERATURA
Neste capítulo serão apresentados os fundamentos teóricos e práticos que
serviram de base para o desenvolvimento deste relatório. O trabalho envolve
basicamente o desenvolvimento de um sistema para gerenciamento eletrônico das
resoluções emitidas pelos órgãos colegiados da UFMT, dessa forma, esse capítulo
apresenta a fundamentação teórica básica para o desenvolvimento de um sistema
nesse contexto.
1.1. Gestão Eletrônica de Documentos
A Gestão Eletrônica de Documentos é feita por um conjunto de tecnologias que
permitem a uma empresa arquivar, gerenciar e recuperar informações contidas em
documentos digitais.
Esses sistemas têm como características desejáveis proporcionar facilidade e
velocidade para encontrar e acessar os documentos via Web ou intranet corporativa.
Estes documentos podem ser de diferentes origens, tais como papel, imagem,
som, arquivos de texto, planilhas eletrônicas, e suas informações contidas podem ser
manipuladas pelo sistema.
Entre as principais tecnologias relacionadas ao GED estão:
Gerenciamento de Documentos
O gerenciamento de documentos é a tecnologia responsável por gerenciar
o documento durante todo seu ciclo de vida (BALDAM, 2002), e possuindo
algumas funções adicionais típicas, entre eles:
o Versionamento;
o Uso de modelos de documentos pré-definidos ou formulários
eletrônicos;
o Integração com programas geradores de documentos;
o Gerenciamento de documentos em construção;
o Fluxos documentais;
o Suporte a diversos tipos documentais.
13
COLD/ERM
A Tecnologia COLD (Computer Output to Laser Disk), também
chamada de ERM (Enterprise Report Management), trata páginas de relatórios,
que inclui a captura, indexação, armazenamento, gerenciamento e recuperação
de dados.
Seu objetivo é gerenciar relatórios vindos de sistemas legados,
geralmente de sistemas robustos como mainframes ou sistemas integrados de
gestão.
Podem chegar a possuir milhares de páginas que podem ser tratadas com
um único documento, de maneira mais automatizada e de fácil consulta.
Seus relatórios são preparados para ter uma forma mais simplificada e
agradável ao usuário que fará a consulta.
Suas aplicações geralmente envolvem extratos bancários, contas de
telefone, relatórios financeiros. (BALDAM, 2002)
RIM
O RIM (Records and Information Management) é o gerenciamento do
ciclo de vida de um documento, independente da mídia em que se encontre.
Através de um sistema RIM é gerenciada a criação, armazenamento,
processamento, manutenção, disponibilização e descarte dos documentos, sob
controle de categorização e tabelas de temporalidade. (BALDAM, 2002)
1.2. Engenharia de Software
A Engenharia de Software, segundo Sommerville (2011), tem o objetivo de
apoiar o desenvolvimento profissional de software, mais do que a programação
individual, dispondo de técnicas para auxiliar a especificação, projeto e evolução de
programas.
14
Ela engloba todos os aspectos da produção de software, desde os estágios
iniciais da especificação do sistema até sua manutenção, e em geral adotam uma
abordagem sistemática e organizada por costumar ser a maneira mais eficiente de
produzir software de alta qualidade.
Porém as vezes se utilizam de abordagens mais criativas e menos formais, por
ser mais adequado e eficiente para um conjunto de circunstâncias, como para o
desenvolvimento de sistemas Web, por requerer uma mistura de habilidades de
projeto e software.
A Engenharia de Software é importante por dois motivos:
Necessidade de se conseguir produzir sistemas confiáveis, econômicos
e em tempo desejável;
Menor gasto em longo prazo, por usar métodos e técnicas de engenharia
de software para sistemas de software comparado com escrever os
códigos como algum projeto pessoal, pois na maioria dos sistemas, a
maior parte do custo acontece na alteração do software depois que ele
passa a ser usado.
Existem vários tipos de softwares, e não existe uma técnica universal de
engenharia de software que se aplique a todos. Entretanto, há três aspectos gerais que
afetam vários tipos diferentes de softwares:
Heterogeneidade – desenvolver técnicas para construção de software
confiável que seja flexível o suficiente para adaptar-se a essa
heterogeneidade;
Entrega – diminuir o tempo de entrega de sistemas, sem comprometer a
qualidade;
Confiança - desenvolver técnicas que demonstrem que o software pode
ter a confiança de seus usuários.
15
1.2.1. Processos de Software
Processos de software são conjuntos de atividades que levam à produção de um
software. (SOMMERVILLE, 2011)
Existem quatro atividades fundamentais que fazem parte de todos os processos
de software:
Especificação de Software – Onde a funcionalidade e as restrições do
software são definidas;
Projeto e Implementação de Software – O software deve ser produzido
para atender ás especificações;
Validação de Software – Onde o software é validado para garantir que
atenda ás demandas do cliente;
Evolução de Software – Onde se garante a flexibilidade do software
para ele evoluir atendendo às necessidades de mudança do cliente.
1.2.1.1. Modelo de Processo de Software
Um modelo de processo de software é uma representação simplificada de um
processo de software, onde cada modelo representa uma perspectiva particular de um
processo, fornecendo informações parciais sobre ele. (SOMMERVILLE, 2011)
Existem vários modelos genéricos de processo de software, e entre os
principais estão:
Modelo em Cascata – Este modelo considera as atividades
fundamentais do processo de especificação, desenvolvimento, validação
e evolução, e representa cada uma delas como fases distintas, como:
especificação de requisitos, projeto de software, implementação, teste
entre outros;
Desenvolvimento Incremental – Este modelo intercala as atividades de
especificação, desenvolvimento e validação. Nele o sistema é
16
desenvolvido como uma série de versões de maneira que cada versão
adiciona funcionalidade á anterior;
Orientada a reuso – Este modelo é baseado na existência de um número
significativo de componentes reusáveis. Seu processo de
desenvolvimento do sistema concentra-se na integração desses
componentes em um sistema já existente em vez de desenvolver um
sistema a partir do zero.
Esses modelos não são mutuamente exclusivos e muitas vezes são usados em
conjunto, especialmente para o desenvolvimento de sistemas de grande porte.
1.2.1.2. Atividades do processo
Os processos de softwares são intercalados com sequências de atividades
técnicas, de colaboração e de gerência, com o intuito de especificar, projetar,
implementar e testar um sistema de software.
Os desenvolvedores de software usam uma variedade de diferentes ferramentas
de software em seu trabalho, que são especialmente úteis para apoiar a edição de
diferentes tipos de documentos e para gerenciar o imenso volume de informações
detalhadas que é gerado em um projeto de grande porte. (SOMMERVILLE, 2011)
As quatro atividades básicas do processo – especificação, desenvolvimento,
validação e evolução – são organizadas de forma diferente conforme o processo de
desenvolvimento. A maneira que essas atividades são feitas depende do tipo do
software, das pessoas e das estruturas organizacionais envolvidas.
1. Especificação de Software
A especificação de software ou engenharia de requisitos é o processo de
compreensão e definição dos serviços requisitados do sistema e identificação
de restrições relativas à operação e ao desenvolvimento do sistema. A
engenharia de requisitos é um estágio particularmente crítico do processo de
17
software, pois erros nessa fase inevitavelmente geram problemas no projeto e
na implementação do sistema.
O processo de engenharia de requisitos tem como objetivo produzir um
documento de requisitos acordados que especifica um sistema que satisfaz os
requisitos dos stakeholders. Requisitos são geralmente apresentados em dois
níveis de detalhe. Os usuários finais e os clientes precisam de uma declaração
de requisitos em alto nível, enquanto desenvolvedores de sistemas precisam de
uma especificação mais detalhada do sistema.
Existem quatro atividades principais do processo de engenharia de
requisitos:
Estudo de viabilidade – Onde é feita uma estimativa da
possibilidade de se satisfazerem as necessidades do usuário
identificado usando-se tecnologias atuais de software e
hardware. O resultado deve informar a decisão de avançar ou
não, com uma análise mais detalhada;
Elicitação e análise de requisitos – Esse é o processo de
derivação dos requisitos do sistema por meio da observação dos
sistemas existentes, além de discussões com os potenciais
usuários e compradores, análise de tarefas, entre outras etapas;
Especificação de requisitos – É a atividade de traduzir as
informações obtidas durante a análise em um documento que
defina um conjunto de requisitos. Dois tipos de requisitos
podem ser incluídos nesse documento. Requisitos do usuário são
declarações abstratas dos requisitos do sistema para o cliente e
usuário final do sistema. Requisitos de sistema são uma
descrição mais detalhada da funcionalidade a ser provida;
Validação de requisitos – Essa atividade verifica os requisitos
quanto a realismo, consistência e completude. Durante esse
processo, os erros no documento de requisitos são
inevitavelmente descobertos. Em seguida o documento deve ser
modificado para a correção desses problemas.
18
Em geral as atividades no processo de requisitos não são feitas em
sequência. A análise de requisitos continua durante a definição e especificação,
e novos requisitos emergem durante o processo. Portanto as atividades de
análise, definição e especificação são intercaladas.
2. Projeto e Implementação de Software
Este é o estágio responsável pela implementação do desenvolvimento de
software. É o processo de conversão de uma especificação do sistema em um
sistema executável, sempre envolvendo processos de projeto e programação de
software, podendo envolver o refinamento da especificação do software se for
usada uma abordagem incremental para o desenvolvimento.
Um projeto de software é uma descrição da estrutura do software a ser
implementado, dos modelos e estruturas de dados usados pelo sistema, das
interfaces entre os componentes do sistema e dos algoritmos usados. Os
projetistas não chegam a um projeto final imediatamente, mas desenvolvem-no
de forma iterativa, acrescentando formalidades e detalhes, enquanto
desenvolvem seu projeto por meio de revisões constantes para correção de
projetos anteriores.
3. Validação de Software
A validação de software tem a intenção de mostrar que um software se
adequa às suas especificações ao mesmo tempo que satisfaz as especificações
do cliente do sistema. O teste de programa, em que o sistema é executado com
dados de testes simulados é a principal técnica de validação, que pode envolver
processos de verificação, como inspeções e revisões, em cada estágio do
processo de software.
4. Evolução do Software
19
Na evolução do software, a flexibilidade dos sistemas de software é uma
das principais razões pelas quais os softwares vêm sendo, cada vez mais,
incorporados em sistemas grandes e complexos. Assim que a decisão pela
fabricação de hardware foi tomada, é muito caro fazer alterações em seu
projeto. Entretanto, as mudanças no software podem ser feitas a qualquer
momento durante ou após o desenvolvimento do sistema.
1.2.2. Engenharia de Requisitos
Os requisitos de um sistema são as descrições do que o sistema deve fazer, os
serviços das quais oferecem e as restrições a seu funcionamento. Esses requisitos
refletem as necessidades dos clientes para um sistema que serve a uma determinada
finalidade. O processo de descobrir, analisar, documentar e verificar esses serviços e
restrições é chamado de engenharia de requisitos. (SOMMERVILLE, 2011)
Alguns dos problemas que surgem durante o processo de engenharia de
requisitos são as falhas em não fazer uma clara separação entre esses diferentes
níveis de descrição. Os requisitos de usuário e de sistema podem ser definidos da
seguinte forma:
1. Requisitos de usuários são declarações, em uma linguagem natural com
diagramas, de quais serviços o sistema deverá fornecer a seus usuários e
as restrições com às quais este deve operar;
2. Requisitos de sistema são descrições mais detalhadas das funções,
serviços e restrições operacionais do sistema do software.
Os requisitos precisam ser escritos em diferentes níveis de detalhamento para
que diferentes leitores possam usá-los de diversas maneiras. Os leitores dos
requisitos de usuários não costumam se preocupar com a forma como o sistema será
implementado. Já os leitores dos requisitos de sistema precisam saber mais
detalhadamente o que o sistema fará.
20
1.2.2.1. Requisitos funcionais e não funcionais
Os requisitos de software são classificados da seguinte forma:
Requisitos funcionais – Declarações de serviços que o sistema deve fornecer,
de como deve reagir a entradas específicas e de como deve se comportar em
determinadas situações;
Requisitos não funcionais – São restrições aos serviços ou funções oferecidas
pelo sistema. Incluem restrições de timing, restrições no processo de
desenvolvimento e de restrições impostas pelas normas.
1.2.2.2. O documento de requisitos de software
O documento de requisitos de software é uma declaração oficial de que os
desenvolvedores do sistema devem implementar. Deve incluir tanto os requisitos de
usuário para um sistema quanto uma especificação detalhada dos requisitos de
sistema.
Documentos de requisitos são essenciais quando um contratante externo está
desenvolvendo o sistema de software. Entretanto os métodos ágeis de
desenvolvimento argumentam que os requisitos mudam tão rapidamente que um
documento de requisitos já está ultrapassado assim que termina de ser escrito.
Portanto, o esforço é, em grande parte, desperdiçado.
1.2.2.3. Especificação de requisitos
A especificação de requisitos é o processo de escrever os requisitos de usuário
e de sistema em um documento de requisitos. Idealmente, os requisitos de usuário e
de sistema devem ser claros, inequívocos, de fácil compreensão, completos e
consistentes.
Os requisitos de usuário para um sistema devem descrever os requisitos
funcionais e não funcionais de modo que sejam compreensíveis para o usuário do
sistema que não tenham conhecimento técnico detalhados.
21
1.3. Banco de Dados
Um Banco de Dados é uma coleção de dados inter-relacionados contendo
informações, projetados para gerenciar grandes blocos de informações (KORTH,
1994).
Seu gerenciamento envolve definir estruturas para armazenamento e definir
mecanismos para a manipulação de informações, além de garantir segurança aos
dados armazenados contra falhas de sistemas ou acesso não autorizado.
Ele permite colocar os dados à disposição de usuários para consultas, inserções
e modificações, dependendo das permissões definidas a ele pelo administrador do
banco de dados.
Para controlar os dados e os usuários de um banco de dados, é necessário se
utilizar de um sistema para gerenciá-lo, chamado de Sistema de Gerenciamento de
Banco de Dados (SGBD), ou em inglês DataBase Management System (DBMS).
Estes sistemas são conjuntos de aplicações com o objetivo de gerenciar o banco
de dados, entre suas tarefas estão:
Permitir o acesso aos dados de maneira simples;
Autorizar um acesso às informações a múltiplos usuários;
Manipular dados presentes no banco de dados (Inserção, Supressão,
Modificação).
1.3.1. Bancos de Dados Relacionais
SGBDs relacionais vêm em muitas formas e tamanhos, cada um com seus
pontos fortes e fracos. Existem vários modelos de bancos de dados relacionais que
são utilizados conforme as necessidades do projeto.
Em seguida será comentado alguns dos principais tipos estruturais de SGBDs:
1. Banco de Dados Hierárquico
22
Figura 1 - Diagrama de um BD Hierárquico.
O modelo hierárquico organiza seus dados utilizando estrutura de árvore.
Na Figura 1 demonstra-se um exemplo de um modelo hierárquico, onde a raiz
da árvore é o pai seguido dos nós filhos. O nó filho não pode ter mais de um
pai, embora o nó pai possa ter mais de um nó filho. (SHARMA, 2010)
No modelo hierárquico, uma coleção de campos nomeados com seus
tipos de dados associados é chamada de tipo registro. Alguns campos nos tipos
registro são chaves. (SHARMA, 2010)
Sua linguagem de manipulação de dados consiste em uma série de
comandos que são embutidos em uma linguagem hospedeira. Esses comandos
acessam e manipulam os itens do banco de dados assim como variáveis
declaradas localmente. (KORTH, 1995)
2. Banco de Dados de Rede
23
Figura 2 - Diagrama de um BD de Redes.
O banco de dados de rede é semelhante ao modelo hierárquico, com
algumas diferenças fundamentais. Ao invés de uma árvore de cabeça para
baixo, ele se parece com uma teia interligada, ou uma rede interligada de
registros, conforme mostrado na Figura 2.
Neles, os nós filhos são chamados de membros e os pais são os
proprietários. A diferença maior é que cada nó filho ou membro pode ter mais
de um nó pai (EDUARDO, 2016).
3. Banco de Dados Relacional
Figura 3 - Diagrama de um BD Relacional.
24
O modelo relacional de banco de dados é o modelo mais antigo e o mais
utilizado atualmente no mundo.
Ele é um modelo representativo (ou de implementação) que se
fundamenta em conceitos da matemática – teoria dos conjuntos e lógica de
predicado. O modelo relacional se refere a três aspectos principais: a estrutura
de dados, a integridade de dados e a manipulação de dados.
Conforme demonstrado na Figura 3, no modelo relacional se conectam
dados em diferentes tabelas, utilizando elementos comuns de dados ou um
campo chave. Dados em bancos relacionais são muito mais flexíveis do que as
estruturas hierárquicas ou de redes.
As ligações entre tabelas são chamadas de relações, as tuplas designam
uma linha ou registro, e as colunas são referidas como atributos ou campo
(EDUARDO, 2016).
4. Banco de Dados Orientado a Objetos
Figura 4 - Diagrama de um BD Orientado a Objetos.
O modelo de banco de dados orientado a objetos, conforme mostrado na
Figura 4, é capaz de lidar com vários tipos novos de dados, como áudio, vídeo,
fotos, gráficos. Ele representa um avanço significativo em relação aos outros.
Os bancos de dados orientados a objetos usam pequenos pedaços
reutilizáveis de software chamados de objetos. Os próprios objetos são
armazenados no banco de dados orientado a objetos (EDUARDO, 2016).
Cada objeto é composto de dois elementos:
25
1) um pedaço de dados (por exemplo, som, vídeo, texto ou gráfico);
2) as instruções, ou programas de software chamados métodos, para o
que fazer com os dados.
1.3.1.1. ACID
O ACID é um dos conceitos mais importantes de bancos de dados relacionais.
Ele define 4 características que todos os SGBDs relacionais devem conter:
Atomicidade, Consistência, Isolamento e Durabilidade (cuja união das iniciais forma
a sigla ACID). (SHARMA, 2010)
Atomicidade – Estado em que as modificações no BD devem ser todas
ou nenhuma feita. Cada transação é dita como “atômica”;
Consistência – Estado que garante que todos os dados serão escritos no
BD;
Isolamento – Requer que múltiplas transações que estejam ocorrendo
“ao mesmo tempo” não se interfiram;
Durabilidade – Garante que toda transação realizada pelo Banco de
Dados não seja perdida.
1.3.1.2. SQL
A linguagem SQL (Structured Query Language) é a linguagem padrão para
SGBDs. Apesar de ser considerada uma linguagem de consulta, ela oferece também
recursos para definir a estrutura de dados, atualizar, incluir, excluir e alterar dados,
especificar restrições de integridade entre outros recursos. (SHARMA, 2010)
26
1.3.2. Bancos de Dados Não-Relacionais
Também conhecidos como bancos NoSQL, os bancos de dados não-relacionais
oferecem meios de armazenar e recuperar dados modelados de forma diferente dos
usados em bancos relacionais. (VAISH, 2013)
O termo NoSQL simboliza “Not Only SQL”, que embora permita o uso de
SQL a maioria dos sistemas não o utilizam. Ao invés de utilizar tabelas, os bancos
NoSQL podem armazenar seus dados em objetos, conjuntos chave-valor ou em
tuplas.
Eles englobam uma variedade de diferentes tecnologias que foram
desenvolvidas diante das necessidades presentes ao se desenvolver aplicativos
modernos:
Desenvolvedores estão trabalhando com aplicativos que geram quantidades
massivas de dados em novos e rapidamente variantes tipos de dados – como
estruturados, semiestruturados, não-estruturados e dados polimórficos;
Agora times pequenos trabalham mais rapidamente, iterando rapidamente e
enviando códigos a cada semana, ou até várias vezes ao dia;
Aplicações que antes serviam a uma quantidade finita de audiência agora são
serviços que sempre devem estar disponíveis, acessível em vários diferentes
dispositivos e escalado globalmente para milhões de usuários.
Bancos de dados relacionais não foram projetados para lidar com os desafios
de agilidade e escalabilidade que os aplicativos modernos enfrentam.
Existem diferentes tipos de bancos de dados NoSQL no momento, entre eles
estão:
1. Orientado a Documentos
O modelo de banco orientado a documentos é utilizado para criar e
gerenciar informações semiestruturadas chamadas de documentos.
27
Os documentos dos bancos são conjuntos de atributos e valores, onde um
atributo pode ser multivalorado.
Em geral os bancos orientados a documentos não possuem esquema, ou
seja, os documentos nele contidos não precisam seguir um mesmo esquema,
ou sequer terem um. (HURWITZ,2013)
Na Figura 5 é mostrado o código JSON de um documento armazenado
em um banco orientado a documentos.
Figura 5 - Código JSON de um documento.
2. Baseado em Grafos
O modelo de banco baseado em grafos é utilizado para armazenar
informações em nós de um grafo cujas arestas representam o tipo de
associação entre esses nós.
Este tipo de banco é mais útil quando se deve lidar com dados altamente
interconectados. Nós e relacionamentos suportam propriedades, um par
chave-valor onde os dados são armazenados.
Estes bancos são navegados seguindo os relacionamentos. Este tipo de
armazenamento não é possível em bancos relacionais devido ás estruturas
rígidas de tabelas e a inaptidão de seguir conexões entre dados onde quer que
ele leve. Um banco orientado a grafos pode ser usado para gerenciar dados
28
geográficos para exploração de petróleo ou para modelar e otimizar redes de
uma provedora de telecomunicações. (HURWITZ,2013)
3. Orientado a Chaves
O modelo de banco de dados orientado a chaves é o mais simples e
oferece grande flexibilidade e escalabilidade. São sistemas distribuídos cuja
estrutura é similar à uma tabela de Hash, e armazenam objetos indexados por
chaves, possibilitando a busca por esses objetos a partir de suas chaves.
Bancos orientados a chaves não oferecem as propriedades ACID, e
necessitam que o implementador planeje as inserções dos dados, replicação e
tolerância a falhas do banco por não serem expressamente controlados pela
tecnologia em si. (HURWITZ,2013)
Na Tabela 1 é mostrado um exemplo de dados em um banco orientado a
chaves.
CHAVE VALOR
Cor Verde
Comida Pizza
Imóvel Casa
Tabela 1 - Exemplo de dados em um banco orientado a chaves
Estes bancos não são tipados, o que resulta na maioria dos dados serem
armazenados como strings.
4. Orientado a Coluna
Banco de dados orientados a coluna são extremamente otimizados para
manipular grandes quantidades de dados distribuídos em de vários servidores,
providenciando alta disponibilidade, extrema escalabilidade e infraestrutura
tolerante a falhas.
29
Seu armazenamento mantém cada coluna do banco de dados
separadamente, guardando contiguamente os valores de atributos pertencendo
à mesma coluna. (HURWITZ,2013)
Na Tabela 2 é mostrado a forma em que são armazenados os dados em
bancos orientados a linhas e a colunas.
ORIENTADO A LINHAS ORIENTADO A COLUNAS
João | 31 | Cuiabá João | Renato | Júlio | Victor
Renato | 25 | Sinop 31 | 25 | 40 | 23
Júlio | 40 | Cáceres Cuiabá | Sinop | Cáceres
Tabela 2 - Forma de Armazenamento em Linhas e Colunas
30
2. MATERIAS, TÉCNICAS E MÉTODOS
Para o desenvolvimento deste trabalho foram utilizados um conjunto de
ferramentas. Para o banco de dados escolheu-se o MongoDB. Para o
desenvolvimento da interface gráfica utilizou-se o Java Server Faces com
componentes do PrimeFaces.
2.1. MongoDB
O MongoDB é um Banco de Dados Orientado a Documentos projetado para
ser flexível, escalável e rápido, mesmo com grandes cargas de dados. É construído
para alta disponibilidade, suporta esquemas ricos e dinâmicos, e permite facilmente
distribuir dados através de múltiplos servidores. (BANKER, 2012)
Ele é um sistema SGBDs que utiliza conceito de dados e documentos
autocontidos e auto descritivos, contendo todas suas informações importantes em um
único documento, livre de esquemas. (MEDEIROS, 2014)
Diferente de um banco relacional que utiliza tabelas, o MongoDB constitui de
uma arquitetura de coleções e documentos. Documentos compõem conjuntos de
chave-valor pares e são a unidade básica de dados no MongoDB. Coleções contêm
conjuntos de documentos e funcionam como um equivalente à tabela de bancos
relacionais. (TECHTARGET, 2014)
E diferente de outros bancos NoSQL, o MongoDB suporta um esquema
dinâmico de dados, possibilitando documentos em uma coleção terem campos e
estruturas diferentes. O banco de dados utiliza um armazenamento de documentos e
um formato de intercâmbio de dados chamado BSON, providenciando uma
representação binária de documentos em formato JSON. Sharding automático
possibilita que dados em uma coleção sejam distribuídos entre vários sistemas para
31
escalabilidade horizontal quando o volume de dados aumenta. (TECHTARGET,
2014).
2.2. Java Server Faces
Java Server Faces (JSF) é, segundo a especificação oficial JSR-000344, um
framework para a construção de interfaces de usuário baseadas em componentes para
aplicações Java Web. Ele incorpora características de um framework MVC para web,
o que se torna uma vantagem por separar claramente a visualização e regras de
negócio. Ele também possui um modelo de programação dirigido a eventos,
abstraindo os detalhes de manipulação dos eventos e organização dos componentes,
possibilitando ao programador se concentrar na lógica de aplicação.
Na Figura 6 é mostrado o modelo MVC. Sua característica principal é dividir a
aplicação em três camadas:
1. Modelo
É o responsável por representar os objetos de negócio, manter o estado de
aplicação e fornecer ao controlador o acesso aos dados. Ele é constituído de
classes de entidade e de negócio, que por sua vez, recebem dados da camada de
visualização e executam regras pertinentes ao negócio;
2. Visão
Ele representa a interface com o usuário, sendo responsável por definir a
forma como os dados serão apresentados e encaminhar as ações do usuário
para o controlador, através de páginas JSP e kits renderizadores (HTML, XML,
etc.). Porém como o JSF utiliza-se de componentes, ela é composta por uma
hierarquia de componentes organizados;
3. Controlador
É o responsável por fazer a ligação entre o modelo e a visualização, além
de interpretar as ações do usuário e as traduzir para uma operação sobre o
modelo, onde são realizadas mudanças, gerando em seguir uma visualização
apropriada. No JSF ele fica por conta de um servlet chamado Faces Servlet, por
arquivos de configuração, pelos Backing Beans e pelos validadores e
conversores.
32
Figura 6 - Modelo MVC do Java Server Faces.
As páginas criadas pelos componentes JSF passam por um ciclo de vida de
processamento toda vez que são executadas. O objeto LifeCycle do JSF usa o objeto
FacesContext em seis fases que compõem o ciclo de vida de uma aplicação JSF.
Cada fase tem uma ação importante em sua aplicação:
1. Restaurar Apresentação: Nesta fase se inicia o processamento da
requisição do ciclo de vida;
2. Aplicar Valores Requisitados: Nesta fase, novos valores inseridos são
extraídos e armazenados por seus apropriados componentes;
3. Processar Validações: Nesta fase, após o valor de cada componente ser
atualizado, eles são validados;
4. Atualizar Valores do Modelo: Esta fase é alcançada após todos os
componentes serem validados. Nela são atualizados os dados do modelo
do aplicativo;
5. Invocar Aplicação: Nesta fase, a implementação JSF manipula quaisquer
eventos do aplicativo, tal como enviar um formulário ou ir a outra página
através de um link;
6. Renderizar Resposta: Esta é a fase final, onde é renderizada a página.
33
2.3. Apache Tomcat
O Apache Tomcat é um servidor web Java. Ele é um container web criado para
executar aplicações Web que utilizam tecnologias Java Servlets e JavaServer Pages.
Entre as principais características do Tomcat, estão:
É um container de Servlets altamente otimizado e leve;
Flexível e escalável;
Seguro.
O Tomcat possui 3 principais componentes, chamados de:
Jasper – analisa os arquivos JSP para serem compilados em código Java
como Servlets (que podem ser manipulados pelo componente Catalina).
Em execução ele detecta mudanças aos arquivos JSP e os recompila;
Catalina – o web container que interage com Java Servlets. Este
componente implementa as especificações para os Servlets e os JSPs;
Coyote – é um componente conector que suporta o protocolo HTTP 1.1
como um web server. Isto permite que Catalina, nominalmente um Java
Servlet ou container JSP poderem agir como um simples web server
que fornece arquivos locais como documentos HTTP.
2.4. Eclipse IDE e Java JDK
O Eclipse é uma Ambiente de Desenvolvimento Integrado (IDE) para
desenvolvimento em quase toda linguagem e arquitetura existente.
Ele suporta principalmente desenvolvimento em Java, porém através de plug-
ins ele integra várias outras linguagens para programação Desktop, em nuvem e web.
Com uma coleção extensa de add-ons presente, ele é uma das melhores ferramentas
para programação presentes no momento.
34
A IDE foi utilizada juntamente com o kit de desenvolvimento da linguagem
Java (JDK), que é um conjunto de utilitários que permitem criar sistemas de software
para a plataforma Java.
A linguagem de programação Java possui um paradigma orientado a objeto.
Diferente de linguagens de programação convencionais que são compiladas para
código nativo, no Java ela é compilada para um bytecode que é executado por uma
máquina virtual.
O Java utiliza o conceito de máquina virtual, uma camada extra existente entre
o sistema operacional e a aplicação, que é responsável por carregar e executar
aplicativos Java, convertendo-os em códigos executáveis de máquina. Esse conceito
proporciona independência de plataforma em geral, não sendo necessário se
preocupar em qual sistema operacional, máquina, configurações entre outros
aspectos para que a aplicação esteja rodando.
35
3. RESULTADOS
Neste capítulo são apresentados os resultados atingidos durante o estágio
supervisionado.
São demonstradas as especificações do sistema determinadas pelo
levantamento de requisitos, as modelagens dos dados a serem armazenados no banco
de dados, a modelagem do banco de dados e a programação da aplicação.
3.1. Levantamento de Requisitos
Para definir as especificações do projeto, foi realizado um levantamento dos
requisitos. Foram realizadas entrevistas com o stakeholder do sistema, afim de
entender o objetivo do sistema a ser desenvolvido e obter informações relevantes
para o projeto.
Também foram analisados documentos de resoluções existentes para
determinar os tipos de informações a serem armazenadas pelo sistema, e as relações
que os documentos tem entre si.
Os seguintes requisitos funcionais foram definidos:
[RF001] O sistema deve permitir ao usuário cadastrar resoluções;
[RF002] O usuário pode consultar resoluções cadastradas;
[RF003] O usuário deve poder anexar arquivos durante o cadastro de
uma resolução;
[RF004] O usuário deve poder especificar no sistema quando o artigo
da resolução a ser cadastrada retifica itens de outras resoluções;
[RF005] O sistema deve exibir referências de retificações de uma
resolução;
[RF006] O sistema deve manter todas as versões de uma resolução.
E os seguintes requisitos não funcionais foram definidos:
36
[RNF001] Todas as resoluções devem seguir o formato que consta no
Manual de Redação da Presidência da República;
[RNF002] As resoluções cadastradas poderão ser consultadas de acordo
com os seguintes campos: órgão, número e data;
[RNF003] O sistema deve permitir o cadastro de resoluções apenas aos
usuários com cadastro;
[RNF004] Qualquer usuário poderá consultar resoluções no sistema;
[RNF005] Ao cadastrar resoluções, os seguintes campos ser
preenchidos obrigatoriamente: número, órgão, data, artigos, cabeçalho e
rodapé;
[RNF006] As resoluções consultadas devem sempre apresentar a última
versão existente, exceto se acessadas por um identificador único da
versão.
Diante das entrevistas e das análises realizadas, foi definido um modelo padrão
para o armazenamento das informações das resoluções. O modelo escolhido foi o que
consta no Manual de Redação da Presidência da República, que constitui a estrutura
básica de uma lei. O mesmo foi escolhido pela semelhança de estrutura dos
documentos de resoluções com o modelo presente no manual.
3.2. Modelagem dos Dados
Em posse dos requisitos do sistema e exemplos de resoluções, foi possível
elaborar o Diagrama Entidade Relacionamento (DER) para o armazenamento das
resoluções. Foi feito o DER primeiramente por ser um modelo conceitual,
apresentando dessa forma, em um nível mais alto de abstração o relacionamento
entre as entidades que compõem uma resolução. A Figura 7 ilustra o diagrama
elaborado.
37
Figura 7 - Diagrama Entidade Relacionamento.
Na Figura 7 é mostrado o DER de uma resolução, com os seguintes atributos:
número, versões, apêndice, data, dia, mês, ano, órgão, tags, cabeçalho, número e
rodapé.
As entidades do diagrama são as seguintes:
Artigo – Unidade básica de apresentação de um texto normativo;
Parágrafo – disposição secundária de um artigo em que se explica ou
modifica a disposição principal;
Inciso – Elemento discriminativo de um artigo se o assunto nele tratado
não puder ser condensado no próprio artigo ou não se mostrar adequado
a constituir um parágrafo;
38
Alínea – Desdobramento de Incisos e Parágrafos;
Seção – Agrupamento de Artigos;
Subseção – Desdobramento de uma Seção;
Capítulo – Agrupamento de Seções;
Subcapítulo – Desdobramento de um Capítulo;
Título – Agrupamento de Capítulos;
Subtítulo – Desdobramento de um Título.
Após a elaboração do DER, optou-se pela implementação do banco de dados
utilizando um modelo não-relacional, foi escolhido o MongoDB. Dessa forma, foram
feitos os modelos buscando-se ilustrar os relacionamentos nesse modelo de dados.
Considerando os relacionamentos entre as informações e o modo em que o
banco de dados orientado a documento lida com eles, foram definidas duas
modelagens: A modelagem do documento da resolução e a modelagem dos artigos
contidos nas resoluções.
Também foi considerado o versionamento das resoluções, resultado das
retificações realizadas por outras resoluções. Foi modelado o versionamento de
forma que os dados da resolução original se mantivessem inalterados, apenas
acrescentando ao documento as informações das novas versões.
Figura 8 - Modelagem dos dados de uma Resolução.
39
Na Figura 8 é mostrado a modelagem dos dados de uma resolução. São
apresentados quais são os dados obrigatórios de se inserir em uma resolução, e o
conjunto de dados não obrigatórios, que só estarão presentes de acordo com as
necessidades do documento.
Figura 9 – Modelagem de um Artigo.
Na Figura 9 é mostrado a modelagem de um Artigo. É apresentado os dados
obrigatórios a serem inseridos, o número e o texto, e os dados não obrigatórios, que
são os desdobramentos do artigo, os parágrafos e os incisos, e seus respectivos
desdobramentos, as alíneas.
Figura 10 - Modelagem do relacionamento resultante de retificações.
40
Na Figura 10 é mostrado a modelagem dos relacionamentos existentes entre as
resoluções. Relacionamentos acontecem quando existe o versionamento de uma
resolução, onde a resolução original é retificada por uma ou mais resoluções
diferentes, o que resulta em um vetor de chaves que apontam para as resoluções
retificadoras.
3.3. Modelagem do Banco de Dados
O Banco de dados escolhido para o desenvolvimento do sistema foi o
MongoDB, um banco de dados NoSQL orientado a documentos.
Por ser um banco orientado a documentos, os dados armazenados nele não
necessariamente possuem um esquema de dados definido, portanto vários
documentos nele contidos não precisam obrigatoriamente possuir o mesmo esquema,
o que colabora com o objetivo do projeto, pois as resoluções possuem tipos de
informações que não estão presentes em todos os documentos.
O versionamento acontece armazenando chaves ligando a resolução original
com a resolução retificadora. As chaves são armazenadas em um vetor, e cada versão
corresponde ao conjunto de chaves armazenadas a partir de nenhuma posição,
correspondendo à resolução original, até a posição de uma chave no vetor,
acumulando as alterações das resoluções das chaves que se passa até ela.
Anexos e apêndices são incluídos de acordo com o assunto da resolução. A
diferença entre eles é que o apêndice segue o mesmo formato das resoluções,
enquanto os anexos não seguem nenhum modelo fixo.
Em resoluções mais extensas os artigos são agrupados de acordo com o tema
sobre o qual versam. Os agrupamentos presentes são:
Seção – agrupa um conjunto de artigos;
Capítulos – agrupa um conjunto de seções;
Título – agrupa um conjunto de capítulos;
E esses agrupamentos podem ainda ter desdobramentos em subseção,
subcapítulo e subtítulo.
41
Os artigos ainda podem se desdobrar em parágrafos e incisos, que podem
também se desdobrar em alíneas.
Toda a modelagem dos dados a serem inseridos ficará por responsabilidade da
aplicação, que deverá ser programada com o esquema dos modelos definidos em
mente.
Na Figura 11 é mostrado um diagrama dos dados no banco, exibindo uma visão
geral de como os dados estarão armazenados no banco.
42
Figura 11 - Diagrama dos Dados no Banco.
43
3.4. Implementação
Após finalizado a modelagem dos dados, se iniciou a programação do projeto.
Os modelos foram implementados na linguagem Java, utilizando o driver para
linguagem Java do MongoDB. Na Figura 12 é mostrado o Diagrama de Classes do
projeto.
Figura 12 - Diagrama de Classes.
44
Em seguida na Figura 13 é mostrado um trecho do código Java responsável
pela conexão com o banco de dados, e pelas operações de inserção e alteração de
dados no banco.
Figura 13 - Código em Java para conexão, inserção e alteração de dados no MongoDB.
Após a programação da modelagem de dados, iniciou-se o planejamento e a
implementação dos componentes web da aplicação. As tecnologias escolhidas para o
desenvolvimento foram o Java Server Faces, um poderoso framework para
desenvolvimento de aplicações web e o Primefaces, uma biblioteca de código aberto
para Java Server Faces 2.0.
Na Figura 14 é mostrado um modelo inicial da tela de listagem de resoluções,
na Figura 15 é mostrado o código da página e na Figura 16 o código da classe Java
que interage com a página.
45
Figura 14 - Modelo inicial da página de listagem de resoluções.
Figura 15 - Código do modelo inicial da página de listagem de resoluções.
46
Figura 16 - Código da classe que interage com a visão.
47
4. DIFICULDADES ENCONTRADAS
Houveram dificuldades no começo do estágio para modelar os documentos de
resoluções. As resoluções não seguiam sempre um padrão fixo, porém pela
semelhança do formato das resoluções com o formato de representação de leis que
consta no Manual de Redação da Presidência da República, concordou-se em adotar
este modelo.
Também houveram dificuldades relacionados ao desenvolvimento web, devido
à falta de conhecimento e prática com as tecnologias. Com o ganho de conhecimento
e experiência se deve superar esta dificuldade.
48
5. CONCLUSÕES
Durante o desenvolvimento das atividades do estágio, foi notado a importância
e presença das tecnologias de bancos de dados NoSQL. Embora ainda menos
conhecidas e utilizadas do que bancos relacionais, sua presença vem crescendo
devido ás necessidades das novas tecnologias que surgem atualmente.
O estudo e desenvolvimento utilizando a tecnologia demonstrou ser uma
experiência valiosa, proporcionando o conhecimento de uma tecnologia com grande
potencial para a formação do discente.
O objetivo do projeto foi parcialmente concluído. O estudo e projeção do
sistema se provaram simples após a definição de um modelo definitivo para as
informações resoluções, porém a implementação do sistema web não foi concluída, o
que o torna o próximo passo para o desenvolvimento do projeto.
49
6. REFERÊNCIAS BIBLIOGRÁFICAS
AIIM. What is Document Management? Disponível em:
<http://www.aiim.org/What-is-Document-Management> (Acessado em 02 de março
de 2016)
BALDAM, Roquemar; VALLE, Rogério; CAVALCANTI, Marcos. 2012. GED
Gerenciamento Eletrônico de Documentos. 2ª Edição. São Paulo: Érica Ltda.
BANKER, Kyle. 2011. MongoDB in Action. 1ª Edição. Shelter Island – NY:
Manning Publications Co.
CCM. Banco de dados – Introdução. Disponível por CCM em:
<http://br.ccm.net/contents/65-bancos-de-dados-introducao> (Acessado em 22 de
março de 2016)
GED. O que é GED? Disponível em: <http://ged.net.br/definicoes-ged.html>
(Acessado em 18 de fevereiro de 2016)
GOMES, Eduardo H. Banco de Dados. Disponível por Eduardo Henrique Gomes
em: <http://ehgomes.com.br/disciplinas/bdd/sgbd.php> (Acessado em 22 de março
de 2016)
HURWITZ, Judith; NUGENT, Alan; HALPER, Fern; KAUFMAN, Marcia. 2013.
Big Data for Dummies.1ª Edição. Hoboken - NJ: Wiley.
KORTH, Henry F; SILBERCHATZ, Abraham. 2006. Sistemas de Banco de Dados.
5ª Edição. Rio de Janeiro – RJ: Editora Campus.
MEDEIROS, Higor. Introdução ao MongoDB. Disponível por DevMedia em:
<http://www.devmedia.com.br/introducao-ao-mongodb/30792> (Acessado em 10 de
março de 2016)
SHARMA, Neeraj; PERNIU, Liviu; CHONG, Raul F; IYER, Abhishek; NANDAN,
Chaitali; MITEA, Adi-Cristina; NONVINKERE, Mallarswami; DANUBIANU,
Mirela. 2010. Database Fundamentals. 1ª Edição. Markham – ON: IBM Corporation.
SOMMERVILLE, Ian. 2011. Engenharia de Software. 9ª Edição. São Paulo – SP:
Pearson Education do Brasil.
50
TECHTARGET. What is MongoDB?. Disponível por TechTarget em:
<http://searchdatamanagement.techtarget.com/definition/MongoDB> (Acessado em
14 de abril de 2016)
VAISH, Gaurav. 2013. Getting Started with NoSQL. 1ª Edição. Birmingham –
Mumbai: Packt Publishing.
