instituto federal do paranÁ hudo cim assenÇo...

INSTITUTO FEDERAL DO PARANÁ

HUDO CIM ASSENÇO

LUCAS FOLMANN LIMA

RODRIGO BRADASH OSTERNACK

PAPYRUS: SISTEMA DE LICITAÇÃO DE LIVROS PARA BIBLIOTECA

CURITIBA

2011

HUDO CIM ASSENÇO

LUCAS FOLMANN LIMA

RODRIGO BRADASH OSTERNACK

PAPYRUS: SISTEMA DE LICITAÇÃO DE LIVROS PARA BIBLIOTECA

Trabalho de Conclusão de Curso apresentado à

disciplina de Projetos como requisito parcial à

conclusão do Curso Técnico em Informática

Integrado ao Ensino Médio do Instituto Federal do

Paraná.

Orientador: Paulo Roberto Vieira Jr.

Co-orientadora: Elaini Simoni Angelotti.

CURITIBA

2011

RESUMO

O processo de licitação de livros do Instituto Federal do Paraná (IFPR), realizado através de suas bibliotecas, aborda o recebimento das solicitações de livros vindos de professores e servidores públicos da instituição e o gerenciamento dessas solicitações. Após entrevistas com o responsável pelo gerenciamento desse processo de licitação, foram constatadas necessidades por parte dele com relação à organização do processo, podendo citar dentre as principais a dificuldade na pesquisa de informações, as constantes falhas no envio de formulários por parte de quem realiza a solicitação de livros e o desgastante processo de organizar uma licitação. Para suprir estas e outras necessidades, foi idealizado o Papyrus, um sistema web desenvolvido em linguagem Java, que tem a função de controlar o preenchimento e envio de formulários, assim como a organização de licitações, a fim de minimizar as falhas e simplificar o processo. Como ponto característico, o sistema fará pesquisas automáticas de dados de cada livro, incluindo seu valor, em websites de livrarias pré-estabelecidas (Livraria Cultura). Sendo o objetivo específico deste projeto a resolução do problema apresentado pelo entrevistado, ele não abordará as demais tarefas que um sistema comum de bibliotecas realiza, como por exemplo, o controle de locação de livros realizados por usuários da biblioteca. Palavras-chave: Licitação. Biblioteca. Pedido. Sistema. Pesquisa automática.

LISTA DE ILUSTRAÇÕES

FIGURA 1 – Diagrama de Casos de Uso .................................................................. 20

FIGURA 2 – Classes DAO ........................................................................................ 76

FIGURA 3 – Classes de Entidade, Facades e Managed Beans ............................... 78

FIGURA 4 – Diagrama de Entidades e Relacionamentos ......................................... 80

FIGURA 5 – Diagrama do Modelo Relacional ........................................................... 93

FIGURA 6 – Página Inicial....................................................................................... 933

FIGURA 7 – Menu de Sistema .................................................................................. 93

FIGURA 8 – Menu de Cadastro .............................................................................. 934

FIGURA 9 – Gerenciamento de Pessoas ................................................................ 935

FIGURA 10 – Tela de Cadastro de Pessoas, Etapa 1 ............................................ 935



FIGURA 13 – Gerenciamento de Licitações............................................................ 937

FIGURA 14 – Tela de Cadastro de Licitações ........................................................... 98

FIGURA 15 – Gerenciamento de Livros .................................................................... 99

FIGURA 16 – Tela de Cadastro de Livros ............................................................... 100

FIGURA 17 – Gerenciamento de Pedidos .............................................................. 101

FIGURA 18 – Tela de Cadastro de Pedidos............................................................ 102

LISTA DE TABELAS

TABELA 1 - Descrição do caso de uso Gerenciar Pessoas ........................................... 21

TABELA 2 - Descrição do caso de uso Listar Pessoas ................................................... 22

TABELA 3 - Descrição do caso de uso Incluir Pessoas .................................................. 23

TABELA 4 - Descrição do caso de uso Alterar Pessoas ................................................. 24

TABELA 5 - Descrição do caso de uso Remover Pessoas ............................................ 24

TABELA 6 - Descrição do caso de uso Gerenciar Licitações ........................................ 25

TABELA 7 - Descrição do caso de uso Listar Licitações ................................................ 26

TABELA 8 - Descrição do caso de uso Incluir Licitações ............................................... 27

TABELA 9 - Descrição do caso de uso Alterar Licitações .............................................. 27

TABELA 10 - Descrição do caso de uso Remover Licitações ....................................... 28

TABELA 11 - Descrição do caso de uso Login ................................................................. 29

TABELA 12 - Descrição do caso de uso Contatar Administrador ................................. 29

TABELA 13 - Descrição do caso de uso Gerenciar Disciplinas ..................................... 30

TABELA 14 - Descrição do caso de uso Listar Disciplinas ............................................. 31

TABELA 15 - Descrição do caso de uso Incluir Disciplinas ............................................ 32

TABELA 16 - Descrição do caso de uso Alterar Disciplinas ........................................... 32

TABELA 17 - Descrição do caso de uso Remover Disciplinas ...................................... 33

TABELA 18 - Descrição do caso de uso Gerenciar Recebimentos .............................. 34

TABELA 19 - Descrição do caso de uso Listar Recebimentos ...................................... 34

TABELA 20 - Descrição do caso de uso Incluir Recebimentos ..................................... 36

TABELA 21 - Descrição do caso de uso Alterar Recebimentos .................................... 36

TABELA 22 - Descrição do caso de uso Remover Recebimentos ................................ 37

TABELA 23 - Descrição do caso de uso Gerenciar Funções ......................................... 38

TABELA 24 - Descrição do caso de uso Listar Funções ................................................ 38

TABELA 25 - Descrição do caso de uso Incluir Funções ............................................... 39

TABELA 26 - Descrição do caso de uso Alterar Funções .............................................. 40

TABELA 27 - Descrição do caso de uso Remover Funções .......................................... 41

TABELA 28 - Descrição do caso de uso Gerenciar Cargos ........................................... 41

TABELA 29 - Descrição do caso de uso Listar Cargos ................................................... 42

TABELA 30 - Descrição do caso de uso Incluir Cargos .................................................. 43

TABELA 31 - Descrição do caso de uso Alterar Cargos ................................................. 44

TABELA 32 - Descrição do caso de uso Remover Cargos ............................................ 44

TABELA 44 - Descrição do caso de uso Cotar Pedidos ................................................. 54

TABELA 45 - Descrição do caso de uso Gerenciar Livro ............................................... 55

TABELA 46 - Descrição do caso de uso Listar Livro ....................................................... 55

TABELA 47 - Descrição do caso de uso Incluir Livro ...................................................... 56

TABELA 48 - Descrição do caso de uso Alterar Livro ..................................................... 57

TABELA 49 - Descrição do caso de uso Remover Livro ................................................. 58

TABELA 50 - Descrição do caso de uso Gerenciar Pedido ........................................... 58

TABELA 51 - Descrição do caso de uso Listar Pedido ................................................... 59

TABELA 52 - Descrição do caso de uso Incluir Pedido .................................................. 60

TABELA 53 - Descrição do caso de uso Alterar Pedido ................................................. 61

TABELA 54 - Descrição do caso de uso Remover Pedido ............................................. 62

TABELA 55 - Descrição do caso de uso Gerenciar Itens ............................................... 63

TABELA 56 - Descrição do caso de uso Listar Item ........................................................ 63

TABELA 57 - Descrição do caso de uso Incluir Item ....................................................... 64

TABELA 59 - Descrição do caso de uso Remover Item ................................................. 64

TABELA 66 - Dicionário de dados da tabela Campi ........................................................ 83

TABELA 67 - Dicionário de dados da tabela Biblioteca .................................................. 84

TABELA 68 - Dicionário de dados da tabela PessoaJuridica ......................................... 84

TABELA 69 - Dicionário de dados da tabela Pedido ....................................................... 85

TABELA 70 - Dicionário de dados da tabela Item ............................................................ 86

TABELA 71 - Dicionário de dados da tabela PessoaJuridicaLicitacao ......................... 86

TABELA 72 - Dicionário de dados da tabela Licitacao .................................................... 87

TABELA 73 - Dicionário de dados da tabela Endereco ................................................... 87

TABELA 74 - Dicionário de dados da tabela Pessoa ...................................................... 88

TABELA 75 - Dicionário de dados da tabela PessoaFisica ............................................ 88

TABELA 76 - Dicionário de dados da tabela Livro ........................................................... 89

TABELA 77 - Dicionário de dados da tabela Professor ................................................... 89

TABELA 78 - Dicionário de dados da tabela ServidorPublico ........................................ 90

TABELA 79 - Dicionário de dados da tabela Disciplina ................................................... 90

TABELA 80 - Dicionário de dados da tabela ProfessorDisciplina ................................. 90

TABELA 81 - Dicionário de dados da tabela Funcao ...................................................... 90

TABELA 82 - Dicionário de dados da tabela Cargo ......................................................... 90

TABELA 83 - Dicionário de dados da tabela Status ........................................................ 91

TABELA 84 - Dicionário de dados da tabela ÁreaDoConhecimento ............................ 91

TABELA 85 - Dicionário de dados da tabela RegistroRecebimento ............................. 91

LISTA DE SIGLAS

AACR2 - Anglo-American Cataloguing Rules, Second Edition ABNT - Associação Brasileira de Normas Técnicas API - Application Programming Interface CRUD - Create-Read-Update-Delete DAO - Data Access Object DER - Diagrama de Entidade e Relacionamento EJB - Enterprise Java Bean GUI - Graphical User Interface HD - Hard Disk HQL - Hibernate Query Language HTML - HyperText Markup Language IDE - Integrated Development Environment IFPR - Instituto Federal de Educação Ciência e Tecnologia do Paraná IOC - Inversion of Control ISBN - International Standard Book Number IU - Interface de Usuário JDBC - Java Database Connectivity JSF - Java Server Faces JSP - Java Server Pages MARC - Machine Readable Cataloging MB - Mega Byte MEC - Ministério da Educação MER - Modelo de Entidade-Relacionamento MR - Modelo Relacional MVC - Model, View, Controller ORM - Object-Relational Mapping PDF - Portable Document Format PUC-PR - Pontifícia Universidade Católica do Paraná RAM - Random Access Memory RNP - Rede Nacional de Ensino e Pesquisa SGBD - Sistema Gerenciador de Banco de Dados SQL - Structured Query Language TB - Tera Byte UML - Linguagem de Modelagem Unificada XML - Extensible Markup Language

SUMÁRIO

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

1.1 DIAGNÓSTICO ATUAL ................................................................................... 1

1.2 OBJETIVO GERAL E OBJETIVOS ESPECÍFICOS ........................................ 2

1.3 JUSTIFICATIVA .............................................................................................. 3

2. SOLUÇÃO PROPOSTA ................................................................................. 4

2.1 DELIMITAÇÃO ................................................................................................ 4

2.2 RECURSOS E TECNOLOGIAS ...................................................................... 4

2.3 FUNDAMENTAÇÃO TEÓRICA ....................................................................... 5

2.3.1 Plataforma Java .............................................................................................. 5

2.3.2 Padrões de projeto .......................................................................................... 6

2.3.2.1 Model, View, Controller ................................................................................... 7

2.3.2.2 Inversion of Control ......................................................................................... 8

2.3.2.3 Data Access Object ......................................................................................... 8

2.3.2.4 Facade ............................................................................................................ 9

2.3.3 JavaServer Faces ......................................................................................... 10

2.3.4 Object-Relational Mapping ............................................................................ 11

2.3.4.1 Hibernate ....................................................................................................... 12

2.3.5 JBossSeam ................................................................................................... 13

2.3.5 Sistema Gerenciador de Banco de Dados .................................................... 13

2.3.7 Trabalhos relacionados .................................................................................. 15

2.4 METODOLOGIA ............................................................................................ 16

2.4.1 Ambiente de desenvolvimento ...................................................................... 16

2.4.2 Modelagem .................................................................................................... 16

2.4.2 Testes ............................................................................................................ 18

3. ESPECIFICAÇÃO TÉCNICA ........................................................................ 19

3.1 DIAGRAMA DE CASO DE USO ................................................................... 19

3.1.1 Especificação dos Casos de Uso .................................................................. 21

3.2 DIAGRAMA DE CLASSES ............................................................................ 75

3.2.1 Classes DAO ................................................................................................. 75

3.2.2 Classes de Entidade, Facades e Managed Beans ........................................ 77

3.3 MODELO LÓGICO DA BASE DE DADOS .................................................... 79

3.3.1 Diagrama de Entidade e Relacionamento ..................................................... 79

3.3.2 Diagrama do Modelo Relacional ................................................................... 81

3.3.3 Dicionário de dados ....................................................................................... 83

4. IMPLEMENTAÇÃO DO SISTEMA E SUAS FUNCIONALIDADES .............. 92

4.1 MENU ............................................................................................................ 92

4.2 PESSOAS ..................................................................................................... 93

4.3 LICITAÇÕES ................................................................................................. 96

4.4 LIVROS ......................................................................................................... 97

4.5 PEDIDOS ...................................................................................................... 99

5. CONSIDERAÇÕES FINAIS ........................................................................ 102

5.1 RESULTADOS E TRABALHOS FUTUROS ................................................ 102

REFÊRENCIAS ....................................................................................................... 104

GLOSSÁRIO ........................................................................................................... 107

ANEXOS ................................................................................................................. 108

1

1 INTRODUÇÃO

Este projeto de conclusão de curso consiste no desenvolvimento de um

sistema, de nome Papyrus, que será feito especialmente para solicitação de livros

na biblioteca do Instituto Federal do Paraná (IFPR). Atualmente o processo de

solicitação de livros para a biblioteca é feito com base no envio de uma planilha por

e-mail, preenchida pelos professores ou servidores públicos a partir de um modelo já

existente, exemplificado pelo anexo A. Isto permite alguns erros, sendo que o

principal deles é a falta de informações referente aos livros solicitados, como autor,

International Standard Book Number (ISBN), editora, entre outros.

Como alternativa a este processo, uma das principais características do

sistema será a pesquisa automática de livros e preços, tendo como base a Livrarias

Cultura. O sistema fará buscas automáticas deixando o processo mais fácil para o

professor ou servidor público e minimizando os erros.

1.1 DIAGNÓSTICO ATUAL

Atualmente, o processo de licitação de livros para a biblioteca do IFPR é

controlado por meio de planilhas eletrônicas, administradas por um funcionário da

biblioteca. Estas planilhas são referentes ao controle de pedidos de livros, cotação

dos livros pelo fornecedor, saldo referente a cada fornecedor, controle de

recebimento dos livros e o envio dos mesmo para as bibliotecas do IFPR.

O controle de pedidos de livros é feito através de uma planilha que contém

as seguintes informações: autor, título, edição, editora, ano, ISBN, quantidade,

volume, valor unitário, valor total, site pesquisado, data da pesquisa, data do pedido

e área de conhecimento, sendo esta última só preenchida pelo administrador. A

solicitação de livros é feita através de e-mails enviados, por professores ou

servidores públicos, a um funcionário responsável pela administração da planilha.

Após o recebimento dos e-mails, o funcionário verifica se as informações

foram corretamente preenchidas. Caso haja alguma informação faltando, ele faz a

pesquisa do livro no site das livrarias Saraiva, Curitiba e Cultura. Caso o livro não

seja encontrado em nenhuma das três livrarias, ele é marcado em vermelho na

planilha e removido da licitação. A etapa seguinte é o envio desta planilha aos

2

fornecedores vencedores da licitação. Cada fornecedor recebe uma lista diferente,

sendo que a separação das listas ocorrerá com base em algum dos campos da

planilha citados anteriormente (autor, International Standard Book Number (ISBN),

editora, etc.), o que é decidido durante o processo de licitação. Depois do

recebimento das listas, os fornecedores verificam a disponibilidade dos livros

solicitados. Caso o livro não esteja disponível, o fornecedor envia uma resposta ao

funcionário com a relação dos livros que não poderão ser enviados com seus

respectivos motivos. O funcionário então monta outra lista, contendo os livros que

irão substituir aqueles que não poderão ser fornecidos, para suprir o saldo

remanescente do fornecedor.

No recebimento dos livros, o funcionário controla os livros recebidos, os

encaminhados e os que estão para chegar através da planilha de controle de

recebimento. Assim que o livro chega para o funcionário, ele irá registrar o

recebimento do livro na sua planilha e encaminhará o livro para a sua respectiva

biblioteca.

1.2 OBJETIVO GERAL E OBJETIVOS ESPECÍFICOS

O objetivo geral do projeto é automatizar o processo de licitação de livros

para a biblioteca do IFPR.

Os objetivos específicos são definidos abaixo:

a) Permitir o cadastro de professores, servidores públicos, fornecedores,

campi, bibliotecas, licitações e livros;

b) Enviar notificações automáticas por e-mails nas seguintes situações:

− Notificar o professor e o servidor público, caso ocorra alteração do status

das solicitações feitas por eles;

− Notificar o professor e o servidor público, caso ocorra a abertura do

período de licitação;

− Notificar o professor e o servidor público, caso ocorra o encerramento do

período de licitação;

− Notificar o fornecedor, caso ocorra alteração das licitações aprovadas

para a licitação.

c) Pesquisar automaticamente preços na Livrarias Cultura;

3

d) Pesquisar automaticamente livros na Livrarias Cultura;

e) Controlar a recepção de livros;

f) Permitir a verificação do status do pedido;

g) Permitir a solicitação de livros.

1.3 JUSTIFICATIVA

O sistema beneficiará o usuário e a instituição, simplificando e agilizando o

processo de solicitação de livros, pois serão minimizadas as falhas no processo,

uma vez que o sistema permitirá pesquisas automatizadas. Estas pesquisas irão

fornecer os dados que faltarem na hora do cadastro de livros, automatizando um

processo que atualmente é feito de forma manual pelo administrador da planilha.

4

2 SOLUÇÃO PROPOSTA

O sistema irá cadastrar professores, servidores públicos, fornecedores,

bibliotecas, campi, licitações e livros. Os professores e servidores públicos

devidamente cadastrados poderão entrar no sistema e realizar solicitações de livros.

As solicitações são ordenadas de acordo com a data de realização, e serão

avaliadas pelo administrador. Só farão parte da licitação as solicitações aceitas pelo

administrador.

Após serem avaliadas pelo administrador as solicitações estarão disponíveis

aos fornecedores vencedores da licitação, que também estarão cadastrados.

Ao verificar o estoque, o fornecedor deverá informar ao sistema quais livros

não poderão ser enviados, bem como suas respectivas justificativas. Se o saldo do

fornecedor ainda não tiver sido alcançado, o administrador poderá incluir na licitação

requisições entregues fora do prazo.

O administrador ficará responsável por dar baixa nos livros recebidos e

encaminhá-los às suas devidas bibliotecas, assim como atualizar o status das

solicitações. Quando isto ocorrer, o sistema notificará via e-mail os professores e

servidores públicos da situação de suas solicitações.

2.1 DELIMITAÇÃO

No ambiente da biblioteca, este sistema não será responsável pela

administração de livros locados da biblioteca por alunos, professores ou funcionários

dos campi. Será limitado aos campi do estado do Paraná.

2.2 RECURSOS E TECNOLOGIAS

No desenvolvimento do projeto será usado Java 1.6. Esta linguagem foi

escolhida por ser independente de plataforma e por ser uma linguagem orientada a

objetos. Para Integrated Development Environment (IDE) foi escolhido o Eclipse

3.6.2 por ter melhor compatibilidade com os demais recursos que serão utilizados no

projeto.

5

Também será utilizado o Sistema Gerenciador de Banco de Dados (SGBD)

MySQL, este por sua vez escolhido por ser, segundo Suehring (2002), um dos

sistemas de gerenciamento de banco de dados livres mais populares que existe e

que, por ser otimizado para aplicações web, é amplamente utilizado na internet.

Outro fator que ajuda na popularidade do MySQL é sua disponibilidade para

praticamente qualquer sistema operacional, como Linux e outros sistemas baseados

em Unix, além de Windows e Mac OS.

Também será utilizado o padrão Data Access Object (DAO), porque o

sistema irá precisar persistir os dados no banco de dados, e o principal benefício

deste padrão é a fácil migração de uma base de dados. Outro padrão a ser utilizado

será o Model, View, Controller (MVC) que também foi escolhido por fornecer

benefícios ao sistema, entre eles o principal é o baixo acoplamento entre as classes.

Pela necessidade de persistir os dados em uma base de dados, será

utilizado o framework Hibernate, porque ele facilita e reduz a codificação necessária

para a persistência dos dados. Será utilizado o framework Java Server Faces (JSF),

que é especializado na criação de páginas web, agilizando o processo de

implementação.

2.3 FUNDAMENTAÇÃO TEÓRICA

Serão apresentadas algumas informações sobre as tecnologias que estarão

presentes no projeto. O objetivo é deixar o leitor mais familiarizado com as

tecnologias e terminologias apresentadas neste tópico.

2.3.1 Plataforma Java

Segundo Horstmann e Cornell (2001), a linguagem de programação Java

surgiu na internet em 1995 e ganhou rapidamente o status de celebridade, pois ela é

uma linguagem elaborada com extrema solidez que tem ganho aceitação por parte

de todos os principais fornecedores e envolvidos. Seus recursos de segurança e

proteção atendem tanto aos programadores quanto aos usuários de programas

Java. A plataforma Java tem inclusive suporte incorporado para realizar tarefas de

6

programação avançadas como programação em rede, conectividade de bancos de

dados e multiprocessamento, de forma imediata.

Desde 1995, a plataforma já passou por vários testes e revisões que a

aprimoraram. A versão 1.2, por exemplo, que foi lançada em 1998, entre os vários

aprimoramentos que teve, ela apresentou um que se destacou: o toolkit de interface

de usuário chamado “Swing”, que permitia aos programadores escrever aplicativos

graphical user interface (GUI) realmente portáveis.

Ainda segundo Horstmann e Cornell (2001), a linguagem Java é totalmente

orientada a objetos, mas foram acrescentados recursos à plataforma que eliminam a

possibilidade de se criar código com os tipos mais comuns de erros, comparando-se

a outras linguagens semelhantes como por exemplo o C++. Um exemplo de

recursos acrescentado foi a coleta de lixo automática, que libera memória

automaticamente.

De acordo com a Oracle (2011), Java é a tecnologia mais ampla e ativa do

planeta, usada por mais de 6,5 milhões de desenvolvedores e presente em mais de

4,5 bilhões de dispositivos. Ela é uma linguagem que funciona em quase todos os

dispositivos, computadores e redes, como por exemplo laptops, datacenters,

consoles de jogo, supercomputadores científicos, telefones celulares e até na

internet.

2.3.2 Padrões de projeto

Alexander1 (1977, citado por GAMMA, 1994) diz, “Cada padrão descreve um

problema que ocorre muitas vezes em nosso ambiente e descreve a solução para

este problema, de tal forma que você pode usar esta solução um milhão de vezes,

sem nunca fazê-la da mesma forma”. Embora Alexander esteja falando de

arquitetura e construções, o princípio é o mesmo para padrões de projetos

orientados a objetos. A diferença é que as soluções são expressadas em termos de

objetos e interfaces ao invés de portas e paredes, mas a idéia principal é a mesma,

uma solução para um problema dentro de um contexto.

1 ALEXANDER, C. et al. A Pattern Language: Towns, Buildings, Construction. 1. ed. New York: Oxford University Press, 1977.

7

Segundo Gamma (1994), os padrões de projetos podem ser divididos em 3

categorias:

a) Criacional: são padrões relacionados a criação de objetos;

b) Estrutural: padrões que lidam com a composição de classes ou objetos;

c) Comportamental: padrões que caracterizam as formas pelas quais as

classes ou objetos interagem e distribuem responsabilidades.

Segundo o autor, os padrões de projetos tornam mais fácil a reutilização de

projetos e arquiteturas bem sucedidas, além de ajudar a escolher alternativas que

tornam um sistema reutilizável e a evitar alternativas e comprometam a

reusabilidade.

2.3.2.1 Model, View, Controller (MVC)

Segundo Eckstein (2007) o padrão MVC foi inicialmente introduzido por

Trygve Reenskaug um desenvolvedor de Smalltalk na Xerox Palo Alto Research

Center em 1979. Este padrão fornece uma maneira de dividir a funcionalidade

envolvida na manutenção e apresentação dos dados de uma aplicação.

Segundo o mesmo autor, o MVC pode ser dividido em 3 elementos:

a) Model: Representa os dados e regras sobre o acesso e a atualização destes

dados. O model também mantém o estado persistente do negócio e fornece

ao controller a capacidade de acessar as funcionalidades da aplicação

encapsuladas pelo próprio model;

b) View: Especifica exatamente como os dados do model devem ser

apresentados. Se os dados mudam, a view precisa mudar a apresentação

dos mesmos. Isso poder ser alcançado usando um push model no qual o

model é responsável por lançar uma notificação de mudança a todos os

Listeners interessados, ou usando um pull model onde a view é responsável

por chamar o modelo quando é necessária a atualização dos dados;

8

c) Controller: Define o comportamento da aplicação, é ele que interpreta as

ações do usuário e as mapeia para chamadas do model. Em um cliente de

aplicações Web essas ações do usuário poderiam ser cliques de botões ou

seleções de menus. As ações realizadas pelo model incluem ativar

processos de negócio ou alterar o estado do model.

De acordo com Eckstein (2007), uma mais recente implementação do MVC

propõe que o controller permaneça entre o model e a view. A principal

diferença entre esse modelo e o tradicional MVC é que nesse as notificações

de mudanças no estado dos objetos do model são comunicados para a view

através do controller. Portanto, o controller mediará o fluxo de dados entre

os objetos do model e view em ambas as direções. Objetos da view, sempre

utilizarão o controller como meio de interpretar as ações do usuário em

mudança nas propriedades do model.

2.3.2.2 Inversion of Control (IOC)

Segundo Fowler (2004), Inversion of Control (ou atualmente Dependency

Injection) é um padrão de projeto que tem como solução o desacoplamento entre as

classes, isto é, uma classe nunca deve instanciar outra classe dentro dela.

Tendo como base o mesmo artigo, essa inversão de controle ocorre no

sentido de que o controle a ser invertido é sobre os objetos da classe. Ele é invertido

para um framework responsável pelas dependências de cada classe. Este

framework por sua vez é configurado de uma forma que possa reutilizar o código

apenas fornecendo as necessidades ao framework sem ter que refazer todo o

código.

O objetivo principal deste padrão é tornar a aplicação flexível, para que ela

possa ser montada para atender a diferentes serviços e componentes de maneira

configurável.

2.3.2.3 Data Access Object (DAO)

Segundo a Sun Microsystems (2001-2002), o Data Access Object é um

padrão de projeto que abstrai a origem e o modo de obtenção ou gravação dos

dados, de modo que o restante do sistema manipula os dados de forma

9

transparente. Isso ajuda muito em processos de migrações de fonte de dados e

testes unitários. Dessa forma o DAO consegue manipular a conexão com a fonte de

dados fazendo com que seja um único ponto de acesso.

Com base no artigo citado anteriormente este padrão traz os seguintes

benefícios:

a) Transparência: Objetos de negócios podem usar a fonte de dados sem saber

os detalhes da implementação desta fonte. O acesso é transparente porque

os detalhes desta implementação estão escondidos dentro do DAO;

b) Reduz a Complexidade dos Objetos de Negócio: Porque o DAO gerencia toda

a complexidade de acesso aos dados, isto simplifica o código dos objetos de

negócio e outros objetos que utilizam o DAO;

c) Centraliza o Acesso aos Dados em uma Camada Separada: O DAO

centraliza todo o código de conexão e manipulação de dados deixando o

código da aplicação mais limpo e fácil de manuseá-lo;

d) Fácil Migração: A camada DAO facilita para a aplicação para migrar para um

diferente implementação de banco de dados. A migração envolve apenas as

mudanças na camada DAO porque os objetos de negócio não tem

conhecimento da forma como é implementado o banco de dados.

2.3.2.4 Facade

Segundo Gamma (2000), o padrão Facade estrutura o sistema em

subsistemas para assim reduzir a complexidade, uma vez que define uma interface

de alto nível que facilita o uso do subsistema. O objetivo do padrão é de minimizar a

comunicação e as dependências entre os subsistemas, para isso cria-se um objeto

de fachada que fornece uma interface única e simplificada para as ações mais

gerais de um subsistema.

Ainda segundo o mesmo autor, as principais situações em que o uso do

Facade se torna vantajoso são quando:

a) A maioria dos padrões, quando aplicados em um sistema, resultam em mais

e menores classes, para isso o Facade oferece uma visão mais simples

desse sistema.

10

b) Existem muitas dependências entre clientes e as classes de implementação

de uma abstração. A implementação de um Facade desacopla o subsistema

dos clientes e outros subsistemas, promovendo assim a independência do

subsistema.

c) O Facade é utilizado para definir um ponto de entrada para cada nível do

sistema. Se os subsistemas são dependentes, então o Facade simplifica as

dependências entre eles, fazendo se comunicarem através de suas

fachadas.

2.3.3 Java Server Faces (JSF)

Segundo Geary e Horstmann (2004), o JSF é um framework que contém

todos os códigos necessários para manipulação de eventos e organização de

componentes. A sua vantagem prometida é proporcionar o desenvolvimento rápido

de interfaces de usuário ao Java server-side.

Segundo os mesmos autores citados anteriormente, o JSF é composto das

seguintes partes:

a) Um conjunto de componentes de interface de usuário (IU) pré

desenvolvidos;

b) Um modelo de programação dirigido por eventos;

c) Um modelo de componentes que permite a desenvolvedores independentes

fornecerem componentes adicionais.

Para Geary e Horstmann (2004), estes são os principais serviços que o JSF

oferece:

a) Arquitetura MVC;

b) Conversão de data;

c) Validação e tratamento de erros;

d) Internacionalização;

e) Componentes personalizados;

f) Suporte a ferramentas.

Segundo a Oracle (2011), facilidade de uso é o objetivo principal do Java

Server Faces. Uma arquitetura que define claramente uma separação entre a lógica

11

da aplicação e da apresentação, tornando fácil de conectar a camada de

apresentação para o código do aplicativo. Este projeto permite que cada membro de

uma equipe de desenvolvimento de aplicações web foque a sua parte no processo

de desenvolvimento, e também oferece um modelo de programação simples para

ligar as partes.

2.3.4 Object-relational mapping (ORM)

Segundo Ambler (2011), existem incompatibilidades conceituais entre os

bancos de dados relacionais e a orientação a objetos, uma vez que esta última é

baseada em princípios da engenharia de software e a primeira é baseada em

princípios matemáticos.

Para resolver estas diferenças, de acordo com o mesmo autor, é utilizada a

técnica de mapeamento objeto-relacional, o ORM. Esta técnica sugere a maneira

como devemos persistir o estado de um objeto (seus atributos, relacionamentos e/ou

heranças) em tabelas de banco de dados relacional (como por exemplo, o MySQL).

Para Bauer e King (2007), ORM é a persistência automatizada (e

transparente) de objetos em um aplicativo Java para as tabelas de um banco de

dados relacional, usando metadados que descrevem o mapeamento entre os

objetos e o banco de dados. O ORM, em sua essência, trabalha na transformação

de dados de uma representação para outra, mas isto implica em problemas de

desempenho. No entanto, se o ORM for implementado como um middleware2,

existem muitas oportunidades para otimização que não existiriam em uma

persistência implementada “a mão”.

Ainda para os mesmos autores, o ORM consiste em quatro partes:

a) Uma Interface de Programação de Aplicações (API) para executar as

operações básicas de adicionar, ler, atualizar e remover em objetos;

b) Uma linguagem ou API para especificar consultas que se referem a classes

ou propriedades das classes;

c) Uma facilidade para a especificação de metadados de mapeamento;

2 Segundo a Rede Nacional de Ensino e Pesquisa (2006), Middleware é o neologismo criado para designar camadas de software que não constituem diretamente aplicações, mas que facilitam o uso de ambientes ricos em tecnologia da informação.

12

d) Uma técnica para a implementação ORM para interagir com objetos

transacionais e outras funções de otimização.

Ainda segundo os mesmos autores, na plataforma Java, o framework Hibernate, que

implementa o padrão Java Persistence API, é o mais recomendado.

2.3.4.1 Hibernate

Segundo Bauer e King (2007), o Hibernate é um framework de mapeamento

objeto/relacional para Java. Este framework transforma os dados da estrutura lógica

de um banco de dados em objetos definidos pelo desenvolvedor. Usando o

Hibernate, não há a necessidade de escrever muito do código de acesso a banco de

dados e de SQL, pois ele utiliza a sua própria Hibernate Query Language (HQL),

acelerando a velocidade do seu desenvolvimento. Vale lembrar que, apesar do fato

do Hibernate utilizar uma linguagem própria para realizar a persistência dos dados,

podemos mudar a qualquer momento o SGDB utilizado.

Conforme os mesmo autores, os principais motivos que fazem com que o

Hibernate seja recomendado para a persistência de dados em Java são:

a) Produtividade: Hibernate elimina muito do trabalho pesado e deixa você se

concentrar no problema do negócio. Não importa qual seja a sua preferência

quanto a estratégia de desenvolvimento de aplicativos, o Hibernate, usado

em conjunto com as ferramentas apropriadas, irá reduzir significativamente o

tempo de desenvolvimento;

b) Manutenção: Menos linhas de código tornam o sistema mais compreensível,

porque enfatiza a lógica do negócio. Ainda mais importante, um sistema com

menos código é mais fácil de ser administrado. A persistência

objeto/relacional automatizada reduz substancialmente o número de linhas

de código.

c) Desempenho: Dada uma tarefa de persistência, várias otimizações são

possíveis. Algumas são muito mais fáceis com o SQL/JDBC escrito. A

maioria delas, no entanto, são muito mais fáceis de conseguir com o

Hibernate, além disso, permite que elas possam ser usadas o tempo todo.

13

2.3.5 JBossSeam

JBoss Seam é um web application framework para Java desenvolvido pela

JBoss. Por ele prover um conjunto de bibliotecas próprias, ele facilita a realização de

uma aplicação voltada para a internet, aliviando a sobrecarga associada a atividades

comuns realizadas em desenvolvimento Web. Segundo a SeamFramework (2011), o

JBoss Seam estabelece um modelo de componentes uniforme para toda a lógica de

negócio da aplicação. Um componente Seam pode ser stateful, com o estado

associado a qualquer um dos vários contextos bem definidos, incluindo os contextos

de execução demorada, persistencia, negócios e os de conversação, que são

preservados entre as múltiplas requisições web em uma interação do usuário.

A empresa Red Hat (2011) afirma que os componentes do JBoss Seam,

sendo simples classes Java, são por natureza testáveis por unidade. Mas para

aplicações complexas, o teste unitário sozinho é insuficiente. O teste de integração

tem sido tradicionalmente uma tarefa difícil e confusa para aplicações web em Java.

Entretanto, o Seam fornece testabilidade para as aplicações como uma

característica do cerne do framework. O desenvolvedor pode escrever facilmente

testes com o JUnit ou TestNG que reproduzem uma interação completa com o

usuário, exercitando todos os componentes do sistema fora da visão (página JSP ou

Facelets). Os testes podem ser executados diretamente de dentro do Integrated

Development Enviroment (IDE) do desenvolvedor, onde o Seam irá fazer

automaticamente o deploy dos componentes EJB usando o JBoss Embedded.

De Acordo com Farley (2007), pode-se gerar automaticamente um create-

read-update-delete (CRUD) aplicação web a partir de um banco de dados existente

usando a ferramenta de linha de comando seam-gen fornecido com o framework.

Seam inclui também um criador de documentos PDF, e-mails, criação de

gráficos e criação de planilhas Microsoft Excel.

2.3.6 Sistema de gerenciamento de bando de dados (SGBD)

Segundo Silberschatz, Korth e Sudarshan (2005), Sistemas de

Gerenciamento de Banco de Dados (SGBD) são programas utilizados para a

manipulação dos dados de um banco de dados (DB). Os SGBDs servem de ponte

entre as aplicações e o banco de dados. Um SGBD não contém apenas os dados

14

em si, mas armazena completamente toda a descrição dos dados, seus

relacionamentos e formas de acesso.

Ainda segundo os mesmos autores, um SGBD principalmente corrige os

erros existentes no sistema de processamento de arquivos típico como:

a) Inconsistência e redundância de dados, uma vez que aplicações são

mantidas por diferentes desenvolvedores.

b) Dificuldade no acesso aos dados.

c) Isolamento de dados.

d) Problemas de integridade.

e) Problemas de atomicidade.

f) Anomalias no acesso concorrente.

g) Problemas na segurança.

Segundo Date (2000), uma das vantagens de usar um SGBD é em casos de

compartilhamento de dados, isto porque SGBD’s multiusuários fornecem controle de

concorrência para assegurar que atualizações simultâneas resultem em

modificações corretas, assim como a facilidade de definir visões de usuário, que é

usada para especificar a porção da base de dados que é de interesse para um grupo

particular de usuários. Outra vantagem são as restrições de acesso multiusuário

uma vez que, no processamento tradicional de arquivos, quando múltiplos usuários

compartilham uma base de dados, é comum que alguns usuários não autorizados

não tenham acesso a todas as informações da base de dados.

Segundo a Oracle (2006), o Programa de Banco de Dados MySQL é um

sistema cliente/servidor que consiste de um servidor SQL multi-tarefa que suporta

acessos diferentes, diversos programas, clientes, bibliotecas, ferramentas

administrativas e diversas interfaces de programação (API's).

Segundo Suehring (2002), aplicações web normalmente apresentam muitas

leituras e poucas gravações. O MySQL é rápido o suficiente para atender a

demanda da velocidade da Internet. Outra vantagem é a capacidade do MySQL

rodar confortavelmente para muitas aplicações em um computador Intel® Pentium®

com 32 MegaBytes (MB) de memória RAM ou menos. Também o tamanho de

tabelas, uma vez que as tabelas do MySQL podem alcançar grandes proporções,

embora às vezes possam encontrar limitações de tamanho de arquivo do sistema

15

operacional que o hospeda. No entanto, algumas arquiteturas podem acomodar até

8 TeraBytes (TB) por tabela usando o MySQL.

2.3.7 Trabalhos relacionados

Alguns sistemas que realizam funções semelhantes às do Papyrus são o

SophiA, o Pergamum, o Gnuteca e o Alexandria, apresentados a seguir.

O Gnuteca, SophiA e Alexandria são basicamente sistemas para automação

dos processos de uma biblioteca comum, não incluindo a solicitação de livros nem

pregões, somente cadastro de alunos e livros, gerenciamentos de empréstimo e

devolução, cobranças de multas, etc.

De acordo com a empresa Solis, o Gnuteca é um software livre, o que

significa que o mesmo pode ser copiado, distribuído e modificado livremente.Ele

funciona totalmente em web, o que significa que ele pode ser acessado por qualquer

navegador de internet do usuário.

Alexandria é um sistema produzido no Chile.Segundo a Companion

Corporation, neste software estão bem dividida as funcionalidades do administrador

(que controla tudo) e dos usuários.

A Primasoft oferece o sistema SophiA Biblioteca em três versões distintas

(Básico, Intermediário e Avançado) que podem ser vistas no anexo B.O SophiA

permite a informatização da biblioteca de acordo com as necessidades da

instituição.

O sistema com as funcionalidades mais próximas às do Papyrus (como por

exemplo a criação de listagens para pregão), é o Pergamum, que possui as

principais funções de uma biblioteca, funcionando de forma integrada da aquisição

ao empréstimo.

De acordo com a PUC-PR, o software é comercializado de forma singular.

Os produtos existentes são: o sistema Pergamum, personalização de layout,

consultoria, treinamentos, gestão de acervos bibliográficos e desenvolvimento de

sites institucionais.

O sistema Pergamum possui alguns diferenciais para com os outros

sistemas, dentre eles pode-se citar a geração de listagens para Pregão, a realização

16

de cobranças de devoluções personalizadas e envios periódicos de e-mails

cobrando materiais atrasados.

O diferencial do sistema Papyrus, serão as funções relacionadas a

pesquisas automáticas de livros e preços. Diferentemente dos sistemas citados, o

Papyrus não fará o gerenciamento integrado de dados e funções de uma biblioteca

comum. Será desenvolvido exclusivamente para o IFPR, atendendo às

necessidades e possuindo um layout dentro das normas da instituição.

2.4 METODOLOGIA

A seguir serão apresentadas informações referentes às especificações

mínimas necessárias para o desenvolvimento do projeto. Também serão

apresentados os métodos utilizados para testes e informações sobre os diagramas e

modelos técnicos utilizados neste documento.

2.4.1 Ambiente de desenvolvimento

Para o desenvolvimento do projeto será necessário um computador que

atenda as seguintes especificações:

a) Processador Intel Pentium 4 ou superior;

b) 1GB de memória RAM;

c) 80GB de HD.

2.4.2 Modelagem

O projeto seguirá a análise orientada a objetos. Segundo Larman (2000), durante a

análise orientada a objetos há uma ênfase na descoberta dos objetos ou conceitos

do domínio do problema.

Para o mesmo autor, a essência da análise orientada a objetos é enfatizar a

consideração de um domínio de problema e uma solução lógica, segundo a

perspectiva de objetos.

De acordo com Larman (2000), um modelo hoje muito aceitado na indústria

para a modelagem orientada a objetos é a linguagem Linguagem de Modelagem

17

Unificada (UML). UML é um sistema de notação dirigida à modelagem de sistemas,

usando conceitos orientados a objetos. Padroniza artefatos e notações, mas não

define um processo padrão de desenvolvimento, para aumentar a probabilidade de

aceitação ampla de uma notação de modelagem padronizada. Dentro da UML

existem vários modelos utilizados na análise orientada a objetos. Os modelos

utilizados neste projeto serão:

a) Diagrama de caso de uso: Segundo Larman (2000), um caso de uso é um

documento narrativo que descreve os eventos de um ator (um agente

externo ao sistema) que usa o sistema para executar um processo. Um

diagrama de caso de uso ilustra um conjunto de casos de uso para um

sistema, os atores e a relação entre os atores e os casos de uso. A

finalidade do diagrama é apresentar um tipo de diagrama de contexto,

através do qual pode-se compreender rapidamente quais são os atores

externos de um sistema e as maneiras com as quais eles o utilizam.

b) Diagrama de classes: De acordo com o mesmo autor, um diagrama de

classes ilustra as especificações para as classes e interfaces de uma

aplicação. As informações típicas incluem classes, associações, atributos,

interfaces, métodos, tipo do atributo, navegabilidade e dependências. Um

diagrama de classes mostra definições para entidades de software, e não

conceito do mundo real.

Para a descrição de dados serão utilizados os modelos de dados. Segundo

Silberschatz, Korth e Sudarshan (2005), um modelo de dados é um conjunto de

ferramentas conceituais utilizadas para a descrição de dados, relacionamentos entre

dados, semântica de dados e regras de consistência. Os modelos são classificados

em três grupos: modelos lógicos com base em objetos, modelos lógicos com base

em registros e modelos físicos.

Neste projeto serão utilizados os seguintes modelos

a) Modelo de Entidade e Relacionamento (MER), como Modelo Lógico com

Base em Objetos: De acordo com Silberschatz, Korth e Sudarshan (2005), o

MER tem por base a percepção do mundo real como um conjunto de objetos

básicos, chamados entidades, e do relacionamento entre eles. Foi

desenvolvido para facilitar o projeto do banco de dados, permitindo a

especificação do “esquema da empresa”, que representa toda a estrutura

18

lógica do banco de dados. O MER é útil para mapear, sobre um esquema

conceitual, o significado de interações das empresas reais.

b) Modelo Relacional (MR), como Modelo Lógico com Base em Registros:

Ainda segundo os mesmos autores, o MR usa um conjunto de tabelas para

representar tanto os dados como a relação entre eles, sendo que cada

tabela possui múltiplas colunas e cada coluna possui um nome único. De

acordo com Date (2000), a estrutura fundamental do modelo relacional é a

relação (tabela). Uma relação é constituída por um ou mais atributos

(campos) que traduzem o tipo de dados a armazenar. Cada instância do

esquema (linha) é chamada de tupla (registro). O modelo relacional

implementa estruturas de dados organizadas em relações.

2.4.3 Testes

Segundo Pressman(1995) a atividade de teste de software é um elemento

crítico da garantia de qualidade de software e representa a última revisão de

especificação, projeto e codificação.

Segundo Myers (2004), há uma série de regras que podem servir como

objetivos de teste:

a) A atividade de teste é o processo de executar um programa com a intenção

de descobrir erros;

b) Um bom caso de teste é aquele que tem uma elevada probabilidade de

revelar um erro ainda não descoberto;

c) Um teste bem sucedido é aquele que revela um erro ainda não descoberto.

O tipo de teste que será usado no projeto será o teste de caixa preta

(também conhecido como teste funcional), que de acordo com Pressman (1995),

possibilita que o engenheiro de software derive conjuntos de condições de entrada

que exercitem completamente todos os requisitos funcionais para um programa.

Para Pressman (1995), o teste de caixa preta consiste em descobrir erros

nas seguintes categorias: funções incorretas ou ausentes; erros de interface; erros

nas estruturas de dados ou no acesso a banco de dados externos; erros de

desempenho; e erros de inicialização e término.

19

3 ESPECIFICAÇÃO TÉCNICA

Neste capítulo serão apresentados os diagramas da UML utilizados neste

projeto: o Diagrama de Casos de Uso e o Diagrama de Classes, incluindo a

especificação dos casos de uso. Além destes, também serão apresentados os

modelos para a descrição dos dados: o Diagrama de Entidade e Relacionamento, o

Diagrama do Modelo Relacional e o Dicionário de Dados, além da especificação do

Diagrama do Modelo Relacional.

3.1 DIAGRAMA DE CASO DE USO

A seguir será apresentado o Diagrama de Caso de Uso do projeto, que

conterá seus casos de uso, atores e o relacionamento entre eles.

20

FIGURA 1 - Diagrama de Casos de Uso

21

3.1.1 Especificação dos Casos de Uso

Nesta seção serão apresentadas as descrições de cada caso de uso do

diagrama apresentado na Figura 1. Para isto serão usadas tabelas contendo o nome

de cada caso de uso, seu objetivo, os atores que terão acesso a ele, o fluxo

principal, o fluxo alternativo, as pré-condições e pós-condições para seu

funcionamento e eventuais regras.

NOME: Gerenciar Pessoas

OBJETIVO • Realizar as tarefas com relação ao gerenciamento

de usuários (incluir, alterar, remover e listar);

ATORES • Administrador;

FLUXO

PRINCIPAL

• O sistema deve abrir uma página contendo um

botão referente à opção de inclusão, uma tabela

que execute o caso de uso “Listar Pessoas” e dois

botões referentes às opções de “Alterar” ou “Excluir”

para cada item da tabela;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES

Não se aplica;

PRÉ-

CONDIÇÕES

• A opção “Gerenciar Pessoas” deve ter sido

escolhida pelo ator no menu do sistema;

PÓS-

CONDIÇÕES

• Deve ser aberta a página referente à opção

escolhida pelo ator;

REGRAS Não se aplica;

Tabela 1 - Descrição do caso de uso Gerenciar Pessoas

NOME: Listar Pessoas

OBJETIVO • Mostrar uma lista das pessoas cadastradas no

sistema e as possíveis ações;


FLUXO • Deve ser exibida uma tabela listando todas as

22

PRINCIPAL pessoas já cadastradas no sistema;

• Na lista devem aparecer, além dos dados de cada

item, dois botões que indiquem as opções de

“Alterar” ou “Remover” um item;

• Se o ator escolher uma dessas opções, o sistema

deve mostrar a janela que execute o caso de uso

referente à opção escolhida;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES

• Enquanto o ator não escolher nenhuma ação de um

dos itens da lista, o caso de uso “Gerenciar

Pessoas” é executado normalmente;

PRÉ-

CONDIÇÕES

• O caso de uso “Gerenciar Pessoas” deve estar

sendo executado;

PÓS-

CONDIÇÕES

• Deve ser aberta a janela referente à ação escolhida

pelo ator;


Tabela 2 - Descrição do caso de uso Listar Pessoas

NOME: Incluir Pessoas

OBJETIVO • Adicionar uma pessoa ao banco de dados;


FLUXO

PRINCIPAL

• O sistema deve mostrar uma janela contendo três

etapas. Na primeira, devem ser mostrados os

campos de preenchimento dos atributos comuns a

todas as pessoas, além de uma ComboBox para

escolher o tipo. Na segunda, um botão que execute

o caso de uso “Modificar Endereço”. Na terceira,

devem ser mostrados os campos de preenchimento

dos atributos específicos para o tipo de pessoa

selecionado na primeira etapa;

• Quando o ator efetuar o cadastro, o sistema deve

verificar se os campos obrigatórios da pessoa não

estão vazios ou nulos;

23

• Se todos os campos foram devidamente validados,

o sistema adiciona esta pessoa ao banco de dados

com os atributos preenchidos, fecha a janela e

atualiza a lista do caso de uso “Listar Pessoas”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES

• Se, após a verificação os campos obrigatórios não

foram preenchidos, o sistema deve informar o erro

ao ator;

• Se o ator clicar em “Voltar” na segunda ou terceira

etapa, o sistema deve retornar à etapa anterior;

PRÉ-

CONDIÇÕES

• O ator deve ter escolhido a opção “Incluir Pessoas”

no caso de uso “Gerenciar Pessoas”;

PÓS-

CONDIÇÕES

• Deve ser adicionado uma pessoa ao banco de

dados;

REGRAS • Todos os campos são obrigatórios;

Tabela 3 - Descrição do caso de uso Incluir Pessoas

NOME: Alterar Pessoas

OBJETIVO • Alterar o registro ou dados de uma pessoa;


FLUXO

PRINCIPAL

• O sistema deve abrir uma janela mostrando o nome

dos atributos e seus respectivos campos, seguindo

as três etapas do caso de uso “Incluir Pessoas”;

• Nos campos de preenchimento já devem estar

escritos os dados atuais;

• Quando o ator efetuar a alteração, o sistema deve

verificar se os campos obrigatórios da pessoa não



o sistema deve substituir os dados antigos desta

pessoa pelos atuais, fechar a janela e atualizar a

lista do caso de uso “Listar Pessoas”;

FLUXO

ALTERNATIVO

• Se, após a verificação, os campos obrigatórios não

24

E DE

EXCEÇÕES


ao ator;

PRÉ-

CONDIÇÕES

• O ator deve ter escolhido a opção “Alterar” de um

item da lista do caso de uso “Listar Pessoas”;

PÓS-

CONDIÇÕES

• Os dados de uma pessoa devem ter sido alterados

no banco de dados;


Tabela 4 - Descrição do caso de uso Alterar Pessoas

NOME: Remover Pessoas

OBJETIVO • Excluir uma pessoa do banco de dados;


FLUXO

PRINCIPAL

• O sistema deve abrir uma janela mostrando o nome de

todos os atributos da pessoa a ser excluída e seus

respectivos valores;

• Na tela deve ser feita uma pergunta ao ator se ele

deseja prosseguir com a exclusão;

• Se a resposta for “Sim”, o sistema deve remover a

pessoa e seus dados do banco de dados, fechar a

janela e atualizar a lista do caso de uso “Listar

Pessoas”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES

• Se a resposta for “Não”, a exclusão deve ser

cancelada e o sistema deve voltar à página anterior;

PRÉ-

CONDIÇÕES

• O ator deve ter escolhido a opção “Excluir” de um item

da lista do caso de uso “Listar Pessoas”;

PÓS-

CONDIÇÕES

• Uma pessoa deve ter sido removido do banco de

dados;


Tabela 5 - Descrição do caso de uso Remover Pessoas

25

NOME: Gerenciar Licitações


de licitações (incluir, alterar, remover e listar);


FLUXO

PRINCIPAL



que execute o caso de uso “Listar Licitações” e dois



FLUXO

ALTERNATIVO

E DE

EXCEÇÕES

Não se aplica;

PRÉ-

CONDIÇÕES

• A opção “Gerenciar Licitação” deve ter sido


PÓS-

CONDIÇÕES




Tabela 6 - Descrição do caso de uso Gerenciar Licitações

NOME: Listar Licitações

OBJETIVO • Mostrar uma lista das licitações cadastradas no



FLUXO

PRINCIPAL

• Deve ser exibida uma tabela listando todas as

licitações já cadastradas no sistema;







26

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



Licitação” é executado normalmente;

PRÉ-

CONDIÇÕES

• O caso de uso “Gerenciar Licitação” deve estar

sendo executado;

PÓS-

CONDIÇÕES


pelo ator;


Tabela 7 - Descrição do caso de uso Listar Licitações

NOME: Incluir Licitações

OBJETIVO • Adicionar uma licitação ao banco de dados;


FLUXO

PRINCIPAL

• O sistema deve abrir uma janela com o nome de

todos os atributos e seus respectivos campos de

preenchimento;


verificar se os campos obrigatórios da licitação não



o sistema adiciona esta licitação ao banco de dados


atualiza a lista do caso de uso “Listar Licitações”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES


foram preenchidos, o cadastro deve ser cancelado e

o sistema deve informar o erro ao ator;

PRÉ-

CONDIÇÕES

• O ator deve ter escolhido a opção “Incluir Licitação”

no caso de uso “Gerenciar Licitação”;

PÓS-

CONDIÇÕES

• Deve ser adicionada uma licitação ao banco de

dados;


27

Tabela 8 - Descrição do caso de uso Incluir Licitações

NOME: Alterar Licitações

OBJETIVO • Alterar o registro ou dados de uma licitação;


FLUXO

PRINCIPAL


dos atributos e seus respectivos campos;


escritos os dados atuais e o campo “Data de Início”

não pode ser editável;


verificar se os campos obrigatórios da licitação não




licitação pelos atuais, fechar a janela e atualizar a

lista do caso de uso “Listar Licitações”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;

• Se o ator não selecionar nenhum item na lista, o

sistema deverá interpretar como nulo e proceder da

maneira descrita acima;

PRÉ-

CONDIÇÕES


item da lista do caso de uso “Listar Licitação”;

PÓS-

CONDIÇÕES

• Os dados de uma licitação devem ter sido alterados

no banco de dados;


Tabela 9 - Descrição do caso de uso Alterar Licitações

NOME: Remover Licitações

OBJETIVO • Excluir uma licitação do banco de dados;

28


FLUXO

PRINCIPAL


todos os atributos da licitação a ser excluída e seus





licitação e seus dados do banco de dados, fechar a


Licitações”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



PRÉ-

CONDIÇÕES


da lista do caso de uso “Listar Licitação”;

PÓS-

CONDIÇÕES

• Uma licitação deve ter sido removida do banco de

dados;


Tabela 10 - Descrição do caso de uso Remover Licitações

NOME: Relizar Login

OBJETIVO • Efetuar o login de um usuário no sistema;

ATORES • Administrador, Fornecedor, Professor e Servidor

Público;

FLUXO

PRINCIPAL

• O sistema deve abrir uma página com os campos

“Login” e “Senha” a serem preenchidos;

• Se o ator efetivar o login, o sistema deve verificar se

o nome de login e válido e a senha é compatível;

• Se os campos forem válidos, o login deve ser

efetuado e este ator deve ter acesso ao sistema;

• O ator deve ser automaticamente direcionado à

página inicial do sistema com acesso às áreas

29

permitidas para seu tipo de usuário;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES

• Se algum campo for inválido, o sistema deve

informar o erro ao ator e pedir novos valores;

PRÉ-

CONDIÇÕES

Não se aplica;

PÓS-

CONDIÇÕES

• Um ator deve ter acessado o sistema;

• O ator deve ter sido direcionado à página inicial do

sistema;


Tabela 11 - Descrição do caso de uso Login

NOME: Contatar Administrador

OBJETIVO • Enviar uma mensagem via e-mail ao administrador;


Público;

FLUXO

PRINCIPAL

• O sistema deve abrir uma página com uma caixa de

texto destinada à inserção da mensagem que deve

ser enviado ao administrador;

• Se o ator clicar no botão para o envio da

mensagem, o sistema deve enviar esta mensagem

ao e-mail do administrador;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES

• Se o ator tentar enviar o e-mail mas a mensagem

estiver nula, o envio deve ser cancelado e o sistema

deve informar o erro ao ator;

PRÉ-

CONDIÇÕES

• A opção contatar administrador deve ter sido

escolhida por um ator no menu do sistema;

PÓS-

CONDIÇÕES

• Um mensagem deve ter sido enviada ao

administrador via e-mail;


Tabela 12 - Descrição do caso de uso Contatar Administrador

30

NOME: Gerenciar Disciplinas


de disciplinas (incluir, alterar, remover e listar);


FLUXO

PRINCIPAL



que execute o caso de uso “Listar Disciplinas” e dois



FLUXO

ALTERNATIVO

E DE

EXCEÇÕES

Não se aplica;

PRÉ-

CONDIÇÕES

• A opção “Gerenciar Disciplinas” deve ter sido


PÓS-

CONDIÇÕES




Tabela 13 - Descrição do caso de uso Gerenciar Disciplinas

NOME: Listar Disciplinas

OBJETIVO • Mostrar uma lista das disciplinas cadastradas no



FLUXO

PRINCIPAL


disciplinas já cadastradas no sistema;







31

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



Disciplinas” é executado normalmente;

PRÉ-

CONDIÇÕES

• O caso de uso “Gerenciar Disciplinas” deve estar

sendo executado;

PÓS-

CONDIÇÕES


pelo ator;


Tabela 14 - Descrição do caso de uso Listar Disciplinas

NOME: Incluir Disciplinas

OBJETIVO • Adicionar uma disciplina ao banco de dados;


FLUXO

PRINCIPAL



preenchimento;


verificar se os campos obrigatórios da disciplina não



o sistema adiciona esta disciplina ao banco de

dados com os atributos preenchidos, fecha a janela

e atualiza a lista do caso de uso “Listar Disciplinas”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;

PRÉ-

CONDIÇÕES

• O ator deve ter escolhido a opção “Incluir Disciplina”

no caso de uso “Gerenciar Disciplinas”;

PÓS-

CONDIÇÕES

• Deve ser adicionado uma disciplina ao banco de

dados;


32

Tabela 15 - Descrição do caso de uso Incluir Disciplinas

NOME: Alterar Disciplinas

OBJETIVO • Alterar o registro ou dados de uma disciplina;


FLUXO

PRINCIPAL




escritos os dados atuais e todos os campos devem

ser editáveis;


verificar se os campos obrigatórios da disciplina não




disciplina pelos atuais, fechar a janela e atualizar a

lista do caso de uso “Listar Disciplinas”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;

PRÉ-

CONDIÇÕES


item da lista do caso de uso “Listar Disciplina”;

PÓS-

CONDIÇÕES

• Os dados de uma disciplina devem ter sido

alterados no banco de dados;


Tabela 16 - Descrição do caso de uso Alterar Disciplinas

NOME: Remover Disciplinas

OBJETIVO • Excluir uma disciplina do banco de dados;


FLUXO • O sistema deve abrir uma janela mostrando o nome de

33

PRINCIPAL todos os atributos da disciplina a ser excluída e seus





disciplina e seus dados do banco de dados, fechar a


Disciplinas”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



PRÉ-

CONDIÇÕES


da lista do caso de uso “Listar Disciplina”;

PÓS-

CONDIÇÕES

• Uma disciplina deve ter sido removida do banco de

dados;


Tabela 17 - Descrição do caso de uso Remover Disciplinas

NOME: Gerenciar Recebimentos


de recebimentos de itens pedidos (incluir, alterar,

remover e listar);


FLUXO

PRINCIPAL



que execute o caso de uso “Listar Recebimentos” e

dois botões referentes às opções de “Alterar” ou

“Excluir” para cada item da tabela;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES

Não se aplica;

34

PRÉ-

CONDIÇÕES

• A opção “Gerenciar Recebimentos” deve ter sido


PÓS-

CONDIÇÕES




Tabela 18 - Descrição do caso de uso Gerenciar Recebimentos

NOME: Listar Recebimentos

OBJETIVO • Mostrar uma lista dos recebimentos de itens

cadastrados no sistema e as possíveis ações;


FLUXO

PRINCIPAL

• Deve ser exibida uma tabela listando todos os

recebimentos de itens já cadastrados no sistema;







FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



Recebimentos” é executado normalmente;

PRÉ-

CONDIÇÕES

• O caso de uso “Gerenciar Recebimentos” deve

estar sendo executado;

PÓS-

CONDIÇÕES


pelo ator;


Tabela 19 - Descrição do caso de uso Listar Recebimentos

NOME: Incluir Recebimentos

OBJETIVO • Adicionar um recebimento ao banco de dados;

35


FLUXO

PRINCIPAL

• O sistema deve abrir uma janela. Na primeira etapa,

deve ser mostrada uma lista com todas as licitações

cadastradas e um botão “Selecionar” para cada item

da tabela;

• Ao selecionar uma licitação, deve ser mostrada a

segunda etapa. Esta deve conter uma lista com

todos os pedidos cadastrados nesta licitação além

de um botão “Listar Itens”, que deve listar todos os

itens do respectivo pedido em uma tabela separada

e um botão “Selecionar” para cada item da tabela;

• Ao selcionar um item, deve ser mostrada a terceira

etapa. Esta deve conter o nome de todos os

atributos do recebimento e seus respectivos campos

de preenchimento;


verificar se os campos obrigatórios do recebimento

não estão vazios ou nulos;


o sistema adiciona este recebimento ao banco de

dados com os atributos preenchidos, fecha a janela

e atualiza a lista do caso de uso “Listar

Recebimentos”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;

• Se, na segunda ou terceira etapa, o ator escolher a

opção “Voltar”, o sistema deve retornar à etapa

anterior;

PRÉ-

CONDIÇÕES

• O ator deve ter escolhido a opção “Incluir

Recebimento” no caso de uso “Gerenciar

Recebimento”;

PÓS- • Deve ser adicionado um recebimento ao banco de

36

CONDIÇÕES dados;


Tabela 20 - Descrição do caso de uso Incluir Recebimentos

NOME: Alterar Recebimentos

OBJETIVO • Alterar o registro ou dados de um recebimento;


FLUXO

PRINCIPAL




escritos os dados atuais e todos os campos deve

ser editáveis;


verificar se os campos obrigatórios do recebimento



o sistema deve substituir os dados antigos deste

recebimento pelos atuais, fechar a janela e atualizar

a lista do caso de uso “Listar Recebimentos”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;

PRÉ-

CONDIÇÕES


item da lista do caso de uso “Listar Recebimentos”;

PÓS-

CONDIÇÕES

• Os dados de um recebimento devem ter sido



Tabela 21 - Descrição do caso de uso Alterar Recebimentos

NOME: Remover Recebimentos

OBJETIVO • Excluir um recebimento do banco de dados;

37


FLUXO

PRINCIPAL


todos os atributos do recebimento a ser excluído e

seus respectivos valores;



• Se a resposta for “Sim”, o sistema deve remover o

recebimento e seus dados do banco de dados, fechar

a janela e atualizar a lista do caso de uso “Listar

Recebimentos”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



PRÉ-

CONDIÇÕES


da lista do caso de uso “Listar Recebimentos”;

PÓS-

CONDIÇÕES

• Um recebimento deve ter sido removido do banco de

dados;


Tabela 22 - Descrição do caso de uso Remover Recebimentos

NOME: Gerenciar Funções


de funções (incluir, alterar, remover e listar);


FLUXO

PRINCIPAL



que execute o caso de uso “Listar Funções” e dois



FLUXO

ALTERNATIVO

E DE

Não se aplica;

38

EXCEÇÕES

PRÉ-

CONDIÇÕES

• A opção “Gerenciar Funções” deve ter sido


PÓS-

CONDIÇÕES




Tabela 23 - Descrição do caso de uso Gerenciar Funções

NOME: Listar Funções

OBJETIVO • Mostrar uma lista das funções cadastradas no



FLUXO

PRINCIPAL


funções já cadastrados no sistema;







FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



Funções” é executado normalmente;

PRÉ-

CONDIÇÕES

• O caso de uso “Gerenciar Funções” deve estar

sendo executado;

PÓS-

CONDIÇÕES


pelo ator;


Tabela 24 - Descrição do caso de uso Listar Funções

NOME: Incluir Funções

39

OBJETIVO • Adicionar uma função ao banco de dados;


FLUXO

PRINCIPAL



preenchimento;


verificar se os campos obrigatórios da função não

estão vazios ou nulos e se o nome é válido;


o sistema adiciona esta função ao banco de dados


atualiza a lista do caso de uso “Listar Funções”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;

• Se o nome da função já for existente, o sistema

deve cancelar o cadastro e informar o erro ao ator;

PRÉ-

CONDIÇÕES

• O ator deve ter escolhido a opção “Incluir Funções”

no caso de uso “Gerenciar Funções”;

PÓS-

CONDIÇÕES

• Deve ser adicionado uma função ao banco de

dados;


Tabela 25 - Descrição do caso de uso Incluir Funções

NOME: Alterar Funções

OBJETIVO • Alterar o registro ou dados de uma função;


FLUXO

PRINCIPAL




escritos os dados atuais e todos os campos deve

ser editáveis;

40


verificar se os campos obrigatórios da função não




função pelos atuais, fechar a janela e atualizar a

lista do caso de uso “Listar Funções”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;

• Se o nome da função já for existente, o sistema

deve cancelar a alteração e informar o erro ao ator;

PRÉ-

CONDIÇÕES


item da lista do caso de uso “Listar Funções”;

PÓS-

CONDIÇÕES

• Os dados de uma função devem ter sido alterados

no banco de dados;


Tabela 26 - Descrição do caso de uso Alterar Funções

NOME: Remover Funções

OBJETIVO • Excluir uma função do banco de dados;


FLUXO

PRINCIPAL


todos os atributos do recebimento a ser excluído e

seus respectivos valores;




função e seus dados do banco de dados, fechar a


Funções”;

FLUXO

ALTERNATIVO


41

E DE

EXCEÇÕES


PRÉ-

CONDIÇÕES


da lista do caso de uso “Listar Funções”;

PÓS-

CONDIÇÕES

• Uma função deve ter sido removido do banco de

dados;


Tabela 27 - Descrição do caso de uso Remover Funções

NOME: Gerenciar Cargos


de cargos (incluir, alterar, remover e listar);


FLUXO

PRINCIPAL



que execute o caso de uso “Listar Cargos” e dois



FLUXO

ALTERNATIVO

E DE

EXCEÇÕES

Não se aplica;

PRÉ-

CONDIÇÕES

• A opção “Gerenciar Cargos” deve ter sido escolhida

pelo ator no menu do sistema;

PÓS-

CONDIÇÕES




Tabela 28 - Descrição do caso de uso Gerenciar Cargos

NOME: Listar Cargos

OBJETIVO • Mostrar uma lista dos cargos cadastrados no


42


FLUXO

PRINCIPAL


cargos já cadastrados no sistema;







FLUXO

ALTERNATIVO

E DE

EXCEÇÕES


dos itens da lista, o caso de uso “Gerenciar Cargos”

é executado normalmente;

PRÉ-

CONDIÇÕES

• O caso de uso “Gerenciar Cargos” deve estar sendo

executado;

PÓS-

CONDIÇÕES


pelo ator;


Tabela 29 - Descrição do caso de uso Listar Cargos

NOME: Incluir Cargos

OBJETIVO • Adicionar um cargo ao banco de dados;


FLUXO

PRINCIPAL



preenchimento;


verificar se os campos obrigatórios do cargo não



o sistema adiciona este cargo ao banco de dados


atualiza a lista do caso de uso “Listar Cargos”;

43

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;

• Se o nome do cargo já for existente, o sistema deve

cancelar o cadastro e informar o erro ao ator;

PRÉ-

CONDIÇÕES

• O ator deve ter escolhido a opção “Incluir Cargo” no

caso de uso “Gerenciar Cargos”;

PÓS-

CONDIÇÕES

• Deve ser adicionado um cargo ao banco de dados;


Tabela 30 - Descrição do caso de uso Incluir Cargos

NOME: Alterar Cargos

OBJETIVO • Alterar o registro ou dados de um cargo;


FLUXO

PRINCIPAL




escritos os dados atuais e todos os campos são

editáveis;


verificar se os campos obrigatórios do cargo não




cargo pelos atuais, fechar a janela e atualizar a lista

do caso de uso “Listar Cargos”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;

• Se o nome do cargo já for existente, o sistema deve

cancelar a alteração e informar o erro ao ator;

44

PRÉ-

CONDIÇÕES


item da lista do caso de uso “Listar Cargo”;

PÓS-

CONDIÇÕES

• Os dados de um cargo devem ter sido alterados no

banco de dados;


Tabela 31 - Descrição do caso de uso Alterar Cargos

NOME: Remover Cargos

OBJETIVO • Excluir um cargo do banco de dados;


FLUXO

PRINCIPAL


todos os atributos do cargo a ser excluído e seus





cargo e seus dados do banco de dados, fechar a


Cargos”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



PRÉ-

CONDIÇÕES


da lista do caso de uso “Listar Cargo”;

PÓS-

CONDIÇÕES

• Um cargo deve ter sido removido do banco de dados;


Tabela 32 - Descrição do caso de uso Remover Cargos

NOME: Gerenciar Status de Pedidos


de status do pedido (incluir, alterar, remover e

45

listar);


FLUXO

PRINCIPAL

• O sistema deve abrir uma página mostrando um

botão "Novo Status", para inclusão, e executar o

caso de uso “Listar Status de Pedidos”;

• Ao ser escolhida uma opção pelo ator, o sistema

deve abrir a página referente à opção escolhida;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES

• Se o ator escolher a opção “Pagina Inicial”, deve ser

direcionado para a página inicial do sistema;

• Se o ator escolher a opção “Logoff" este caso de

uso deve ser parado imediatamente e o usuário

redirecionado à tela de login;

PRÉ-

CONDIÇÕES

• A opção “Gerenciar Status de Pedidos” deve ter

sido escolhida pelo ator no menu do sistema;

PÓS-

CONDIÇÕES




Tabela 33 - Descrição do caso de uso Gerenciar Status de Pedidos

NOME: Listar Status de Pedidos

OBJETIVO • Mostrar uma lista dos status cadastrados no

sistema;


FLUXO

PRINCIPAL


status já cadastrados no sistema;





deve executar o caso de uso referente à opção

escolhida, abrindo assim uma janela;

FLUXO

ALTERNATIVO


dos itens da lista, o caso de uso “Gerenciar Status

46

E DE

EXCEÇÕES

de Pedidos” é executado normalmente;

PRÉ-

CONDIÇÕES

• O caso de uso “Gerenciar Status de Pedidos” deve


PÓS-

CONDIÇÕES


pelo ator;


Tabela 34 - Descrição do caso de uso Listar Status de Pedidos

NOME: Inlcuir Status de Pedidos

OBJETIVO • Adicionar um status do pedido ao banco de dados;


FLUXO

PRINCIPAL

• O sistema deve abrir uma janela com:

- Um campo de texto para o atributo "nome" e

um upload de imagem para o "icone"

- Botões "Salvar" e "Cancelar ;

• Quando o ator clicar no botão "Salvar", o sistema

deve verificar se o campo "nome" não está vazio ou

nulo;


o sistema adiciona o status ao banco de dados com

os atributos preenchidos, fecha a janela e atualiza a

lista do caso de uso “Listar Status de Pedidos”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;

• Caso o ator tenha clicado em "Cancelar", o sistema

deve parar este caso de uso, fechar a janela e

excluir todas as informações referentes a inclusão

do novo status;

PRÉ-

CONDIÇÕES

• O ator deve ter escolhido a opção “Novo Status” no

caso de uso “Gerenciar Status de Pedidos”;

PÓS- • Deve ser adicionado um status ao banco de dados;

47

CONDIÇÕES


Tabela 35 - Descrição do caso de uso Inlcuir Status de Pedidos

NOME: Alterar Status de Pedidos

OBJETIVO • Alterar o registro ou dados do status do pedido;


FLUXO

PRINCIPAL


dos atributos e seus respectivos campos, um botão

"Alterar" e outro "Cancelar";

• Os campos dentro da já devem estar preenchidos

com os dados do status;

• Quando o ator clicar no botão "Alterar", o sistema

deve verificar se os campos obrigatórios do status




status pelos atuais, fechar a janela e atualizar a lista

do caso de uso “Listar Status de Pedidos”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;



excluir todas as alterações feitas no status;

PRÉ-

CONDIÇÕES

• O ator deve ter escolhido a opção “Editar” de um

item da lista do caso de uso “Listar Status de

Pedidos”;

PÓS-

CONDIÇÕES

• Os dados de um status devem ter sido alterados no

banco de dados;

REGRAS Nao se aplica;

Tabela 36 - Descrição do caso de uso Alterar Status de Pedidos

48

NOME: Remover Status de Pedidos

OBJETIVO • Excluir um status do banco de dados;


FLUXO

PRINCIPAL

• O sistema deve abrir uma janela de confirmação

mostrando o nome do status a ser excluído;




status e seus dados do banco de dados, fechar a

janela e atualizar a lista do caso de uso “Listar Status

de Pedidos”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES


cancelada e a janela fechada;

PRÉ-

CONDIÇÕES


da lista do caso de uso “Listar Status de Pedidos”;

PÓS-

CONDIÇÕES

• Um status deve ter sido removido do banco de dados;


Tabela 37 - Descrição do caso de uso Remover Status de Pedidos

NOME: Gerenciar Campi


de campi (incluir, alterar, remover e listar);


FLUXO

PRINCIPAL


botão "Novo Campus", para inclusão, e executar o

caso de uso "Listar Campi";



FLUXO

ALTERNATIVO



49

E DE

EXCEÇÕES


uso deve ser parado imediatamente e o usuário


PRÉ-

CONDIÇÕES

• A opção “Gerenciar Campi” deve ter sido escolhida


PÓS-

CONDIÇÕES




Tabela 38 - Descrição do caso de uso Gerenciar Campi

NOME: Listar Campi

OBJETIVO • Mostrar uma lista dos campus cadastrados no



FLUXO

PRINCIPAL


campus já cadastrados no sistema;





deve executar o caso de uso e mostrar a janela

referentes à opção escolhida;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES


dos itens da lista, o caso de uso “Gerenciar Campi”


PRÉ-

CONDIÇÕES

• O caso de uso “Gerenciar Campi” deve estar sendo

executado;

PÓS-

CONDIÇÕES


pelo ator;


Tabela 39 - Descrição do caso de uso Listar Campi

50

NOME: Incluir Campi

OBJETIVO • Adicionar um campus ao banco de dados;


FLUXO

PRINCIPAL



preenchimento;

• Um endereço poderá ser adicionado ao campus (e

posteriormente alterado) se o usuário clicar no

botão "Cadastro Endereco", que abre o caso de uso

"Modificar Endereco";

• Nesta mesma janela, mas em uma aba diferente, o

sistema permitirá adicionar uma nova biblioteca

(Caso de uso Incluir Biblioteca) ou selecionar uma já

cadastrada e incluí-la na tabela referente às

bibliotecas associadas ao campus;

• O sistema permitirá excluir as bibliotecas inclusas

na tabela, referente às bibliotecas associadas ao

campus;


verificar se os campos obrigatórios não estão vazios

ou nulos;


o sistema adiciona o campus ao banco de dados


atualiza a lista do caso de uso “Listar Campi”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;




do novo campus;

PRÉ- • O ator deve ter escolhido a opção “Incluir Campus”

51

CONDIÇÕES no caso de uso “Gerenciar Campi”;

PÓS-

CONDIÇÕES

• Deve ser adicionado um campus ao banco de

dados;


Tabela 40 - Descrição do caso de uso Incluir Campi

NOME: Alterar Campi

OBJETIVO • Alterar o registro ou dados de um campus;


FLUXO

PRINCIPAL



• Os campos já devem estar preenchidos com os

dados atuais;

• O endereço poderá ser alterado se o usuário clicar

no botão "Cadastro Endereco", que abre o caso de

uso "Modificar Endereco";

• Nesta mesma janela, mas em uma aba diferente, o

sistema permitirá adicionar uma nova biblioteca

(Caso de uso Incluir Biblioteca) ou selecionar uma já

cadastrada e incluí-la na tabela referente às

bibliotecas associadas ao campus;

• O sistema permitirá excluir as bibliotecas inclusas

na tabela referente às bibliotecas associadas ao

campus;



ou nulos;



campus pelos atuais, fechar a janela e atualizar a

lista do caso de uso “Listar Campi”;

FLUXO • Se, após a verificação, os campos obrigatórios não

52

ALTERNATIVO

E DE

EXCEÇÕES


ao ator;



excluir todas as alterações feitas no campus;

PRÉ-

CONDIÇÕES

• O ator deve ter escolhido a opção “Editar” de um

item da lista do caso de uso “Listar Campi”;

PÓS-

CONDIÇÕES

• Os dados de um campus devem ter sido alterados

no banco de dados;


Tabela 41 - Descrição do caso de uso Alterar Campi

NOME: Remover Campi

OBJETIVO • Excluir um campus do banco de dados;


FLUXO

PRINCIPAL

• O sistema deve abrir uma janela mostrando o nome do

campus a ser excluído;




campus e seus dados do banco de dados, fechar a

janela e atualizar a lista do caso de uso “Listar Campi”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



PRÉ-

CONDIÇÕES


da lista do caso de uso “Listar Campi”;

PÓS-

CONDIÇÕES

• Um campus deve ter sido removido do banco de

dados;


Tabela 42 - Descrição do caso de uso Remover Campi

53

NOME: Alterar Dados Pessoais

OBJETIVO • Alterar o registro ou dados pessoais de um usuário;


Público;

FLUXO

PRINCIPAL


dos atributos e seus respectivos campos, incluindo

telefones, e-mails e endereços do usuário;


escritos os dados atuais;


verificar se os campos obrigatórios do usuário não




usuário pelos atuais e fechar a janela;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;

PRÉ-

CONDIÇÕES

• O ator deve ter escolhido a opção “Alterar Dados

Pessoais” no menu do sistema;

PÓS-

CONDIÇÕES

• Os dados de um usuário devem ter sido alterados

no banco de dados;


Tabela 43 - Descrição do caso de uso Alterar Dados Pessoais

NOME: Cotar Pedidos

OBJETIVO • Preenchimento dos atributos referentes à cotação

de um item;

ATORES • Administrador, Fornecedor;

FLUXO

PRINCIPAL

• O sistema deve abrir uma janela mostrando os

dados do item a ser cotado;

• Deve ser mostradas também os campos de

54

preenchimento dos dados da cotação;

• Ao digitar um valor unitário, o sistema já deve

calcular o total baseado no número de itens

pedidos;

• Ao digitar um valor de desconto, o sistema já deve

calcular o novo total, com o desconto;

• Quando o ator efetuar a cotação, o sistema deve

verificar se os campos obrigatórios do usuário não



o sistema deve adicionar os dados desta cotação ao

item e fechar a janela;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;

PRÉ-

CONDIÇÕES

• O ator deve ter escolhido a opção “Cotar Pedidos”

no menu do sistema;

PÓS-

CONDIÇÕES

• Os dados referentes à cotação de um item devem

ter sido incluídos no banco de dados;


Tabela 33 - Descrição do caso de uso Cotar Pedidos

NOME: Gerenciar Livros


de livro (incluir, alterar, remover e listar);

ATORES • Professor e Servidor Público, Administrador;

FLUXO

PRINCIPAL



que execute o caso de uso “Listar Livros” e dois



FLUXO Não se aplica;

55

ALTERNATIVO

E DE

EXCEÇÕES

PRÉ-

CONDIÇÕES

• A opção “Gerenciar Livro” deve ter sido escolhida


PÓS-

CONDIÇÕES




Tabela 34 - Descrição do caso de uso Gerenciar Livro

NOME: Listar Livros

OBJETIVO • Mostrar uma lista dos livros cadastrados no sistema

e as possíveis ações;


FLUXO

PRINCIPAL

• Deve ser exibida uma tabela listando todos os livros

já cadastrados no sistema;







FLUXO

ALTERNATIVO

E DE

EXCEÇÕES


dos itens da lista, o caso de uso “Gerenciar Livros” é

executado normalmente;

PRÉ-

CONDIÇÕES

• O caso de uso “Gerenciar Livros” deve estar sendo

executado;

PÓS-

CONDIÇÕES


pelo ator;


Tabela 35 - Descrição do caso de uso Listar Livro

56

NOME: Incluir Livro

OBJETIVO • Adicionar um livro ao banco de dados;


FLUXO

PRINCIPAL



preenchimento, incluindo área do conhecimento;

• Ao digitar pelo menos 3 caracteres do titulo do livro,

o sistema deverá automaticamente executar o caso

de uso “Pesquisa Automatica de Livro”;


verificar se os campos obrigatórios do livro não



o sistema adiciona este livro ao banco de dados


atualiza a lista do caso de uso “Listar Livro”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;

PRÉ-

CONDIÇÕES

• O ator deve ter escolhido a opção “Incluir Livro” no

caso de uso “Gerenciar Livro”;

PÓS-

CONDIÇÕES

• Deve ser adicionado um livro ao banco de dados;

REGRAS • Não se aplica;

Tabela 36 - Descrição do caso de uso Incluir Livro

NOME: Alterar Livro

OBJETIVO • Alterar o registro ou dados de um livro;


FLUXO

PRINCIPAL



57


dados atuais;

• Ao digitar pelo menos 3 caracteres do titulo do livro,

o sistema deverá automaticamente executar o caso

de uso “Pesquisa Automatica de Livro”;


verificar se os campos obrigatórios do livro não




livro pelos atuais, fechar a janela e atualizar a lista

do caso de uso “Listar Livro”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;

PRÉ-

CONDIÇÕES


item da lista do caso de uso “Listar Livro”;

PÓS-

CONDIÇÕES

• Os dados de um livro devem ter sido alterados no

banco de dados;


Tabela 37 - Descrição do caso de uso Alterar Livro

NOME: Remover Livro

OBJETIVO • Excluir um livro do banco de dados;


FLUXO

PRINCIPAL


todos os atributos do livro a ser excluído e seus





livro e seus dados do banco de dados, fechar a janela

58

e atualizar a lista do caso de uso “Listar Livro”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



PRÉ-

CONDIÇÕES


da lista do caso de uso “Listar Livro”;

PÓS-

CONDIÇÕES

• Um livro deve ter sido removido do banco de dados;


Tabela 38 - Descrição do caso de uso Remover Livro

NOME: Gerenciar Pedido


de pedido (incluir, alterar, remover, listar);


FLUXO

PRINCIPAL



que execute o caso de uso “Listar Pedidos” e dois



FLUXO

ALTERNATIVO

E DE

EXCEÇÕES

Não se aplica;

PRÉ-

CONDIÇÕES

• A opção “Gerenciar Pedidos” deve ter sido


PÓS-

CONDIÇÕES




Tabela 39 - Descrição do caso de uso Gerenciar Pedido

NOME: Listar Pedido

59

OBJETIVO • Mostrar uma lista dos pedidos cadastrados no



FLUXO

PRINCIPAL


pedidos já cadastrados no sistema;



“Alterar” ou “Remover” um pedido;




FLUXO

ALTERNATIVO

E DE

EXCEÇÕES


dos itens da lista, o caso de uso “Gerenciar Pedido”


PRÉ-

CONDIÇÕES

• O caso de uso “Gerenciar Pedido” deve estar sendo

executado;

PÓS-

CONDIÇÕES


pelo ator;


Tabela 40 - Descrição do caso de uso Listar Pedido

NOME: Incluir Pedido

OBJETIVO • Adicionar um pedido ao banco de dados;


FLUXO

PRINCIPAL



preenchimento, incluindo itens. O campo referente

ao usuário já deve estar preenchido com o nome do

usuário que está fazendo o pedido e não pode ser

modificado;

• Quando o ator for incluir um Item na área de “Itens”,

o sistema deve executar o caso de uso “Incluir

60

Itens”;

• Deve ser mostrada uma tabela com todos os itens

cadastrados no pedido além de um botão

“Remover” para cada item da tabela;


verificar se os campos obrigatórios do pedido não



o sistema adiciona este pedido ao banco de dados


atualiza a lista do caso de uso “Listar Pedido”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;

PRÉ-

CONDIÇÕES

• O ator deve ter escolhido a opção “Incluir Pedido”

no caso de uso “Gerenciar Pedido”;

PÓS-

CONDIÇÕES

• Deve ser adicionado um pedido ao banco de dados;


Tabela 41 - Descrição do caso de uso Incluir Pedido

NOME: Alterar Pedido

OBJETIVO • Alterar o registro ou dados de um pedido;


FLUXO

PRINCIPAL


dos atributos e seus respectivos campos. O campo

referente ao usuário já deve estar preenchido com o

nome do usuário que fez o pedido e não pode ser

modificado;


dados atuais;

• Quando o ator for modificar a área de “Itens” do

61

pedido, o sistema deve executar o caso de uso

“Incluir Itens”;

• Deve ser mostrada uma tabela com todos os itens já

cadastrados no pedido além de um botão

“Remover” para cada item da tabela;






pedido pelos atuais, fechar a janela e atualizar a

lista do caso de uso “Listar Pedido”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;

PRÉ-

CONDIÇÕES


item da lista do caso de uso “Listar Pedido”;

PÓS-

CONDIÇÕES

• Os dados de um pedido devem ter sido alterados no

banco de dados;


Tabela 42 - Descrição do caso de uso Alterar Pedido

NOME: Remover Pedido

OBJETIVO • Excluir um pedido do banco de dados;


FLUXO

PRINCIPAL


todos os atributos do pedido a ser excluído e seus





pedido e seus dados do banco de dados, fechar a

62


Pedido”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



PRÉ-

CONDIÇÕES


da lista do caso de uso “Listar Pedido”;

PÓS-

CONDIÇÕES

• Um pedido deve ter sido removido do banco de dados;


Tabela 43 - Descrição do caso de uso Remover Pedido

NOME: Gerenciar Itens de Pedidos


de itens (incluir, alterar, remover, listar);


FLUXO

PRINCIPAL

• O sistema deve mostrar uma área da janela do caso

de uso “Incluir Pedidos” ou “Alterar Pedidos”

referente ao gerenciamento de itens, com um epaço

para o caso de uso “Incluir Itens de Pedidos” e uma

tabela que execute o caso de uso “Listar Itens de

Pedidos” e um botão “Excluir” para cada item da

tabela;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES

Não se aplica;

PRÉ-

CONDIÇÕES

• O caso de uso “Incluir Pedidos” ou “Alterar Pedidos”

deve estar sendo executado;

PÓS-

CONDIÇÕES

• Deve ser executado o caso de uso da preferência

do ator;


63

Tabela 44 - Descrição do caso de uso Gerenciar Itens

NOME: Listar Item

OBJETIVO • Mostrar uma lista dos itens cadastrados no sistema

e as possíveis ações;


FLUXO

PRINCIPAL

• Deve ser exibida uma tabela listando todos os itens

já cadastrados no respectivo pedido;


item, um botão para remove-los item;


deve executar o caso de uso referente à opção

escolhida;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES


dos itens da lista, o caso de uso “Gerenciar Item” é

executado normalmente;

PRÉ-

CONDIÇÕES

• O caso de uso “Gerenciar Item” deve estar sendo

executado;

PÓS-

CONDIÇÕES


pelo ator;


Tabela 45 - Descrição do caso de uso Listar Item

NOME: Incluir Item

OBJETIVO • Adicionar um item a um pedido no banco de dados;


FLUXO

PRINCIPAL

• O sistema deve mostrar o nome de todos os

atributos e seus respectivos campos de

preenchimento, incluindo livro, preços e site da

pesquisa;


64




o sistema adiciona este item ao pedido com os

atributos preenchidos e atualiza a lista do caso de

uso “Listar Item”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;

PRÉ-

CONDIÇÕES

• O ator deve ter escolhido a opção “Incluir Item” no

caso de uso “Gerenciar Item”;

PÓS-

CONDIÇÕES

• Deve ser adicionado um item a um pedido no banco

de dados;


Tabela 46 - Descrição do caso de uso Incluir Item

NOME: Remover Item

OBJETIVO • Excluir um item do banco de dados;


FLUXO

PRINCIPAL

• O sistema deve remover o item e seus dados do

pedido e do banco de dados, fechar a janela e

atualizar a lista do caso de uso “Listar Item”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



PRÉ-

CONDIÇÕES


da lista do caso de uso “Listar Item”;

PÓS-

CONDIÇÕES

• Um item deve ter sido removido do banco de dados;


Tabela 47 - Descrição do caso de uso Remover Item

65

NOME: Gerenciar Bibliotecas


de biblioteca (alterar, remover, listar);


FLUXO

PRINCIPAL

• O sistema deve executar o caso de uso “Listar

Bibliotecas”;



• Neste caso de uso não existe a opção para

inclusão;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES




uso deve ser parado imediatamente e o usuario


PRÉ-

CONDIÇÕES

• A opção “Gerenciar Bibliotecas” deve ter sido

escolhida pelo ator no menu do sistema ;

PÓS-

CONDIÇÕES



REGRAS • Usuario deve estar logado;

Tabela 60 - Descrição do caso de uso Gerenciar Bibliotecas

NOME: Listar Bibliotecas

OBJETIVO • Mostrar uma lista das bibliotecas cadastradas no



FLUXO

PRINCIPAL


bibliotecas já cadastrados no sistema;


biblioteca, dois botões que indiquem as opções de

“Alterar” ou “Remover” uma biblioteca;


66



FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



Bibliotecas” é executado normalmente;

PRÉ-

CONDIÇÕES

• O caso de uso “Gerenciar Bibliotecas” deve estar

sendo executado;

PÓS-

CONDIÇÕES


pelo ator;


Tabela 61 - Descrição do caso de uso Listar Bibliotecas

NOME: Incluir Biblioteca

OBJETIVO • Adicionar uma biblioteca ao banco de dados;


FLUXO

PRINCIPAL



preenchimento;

• Um endereço poderá ser adicionado à biblioteca (e

posteriormente alterado) se o usuario clicar no

botão "Cadastro Endereco", que abre o caso de uso

"Modificar Endereco";



ou nulos;


o sistema adiciona esta biblioteca ao banco de

dados com os atributos preenchidos e fecha a

janela;

FLUXO

ALTERNATIVO

E DE



ao ator;

67

EXCEÇÕES • Caso o ator tenha clicado em "Cancelar", o sistema



da nova biblioteca;

PRÉ-

CONDIÇÕES

• O ator deve ter escolhido a opção “Incluir Biblioteca”

no caso de uso “Gerenciar Campi”;

PÓS-

CONDIÇÕES

• Deve ser adicionado uma biblioteca ao banco de

dados;


Tabela 62 - Descrição do caso de uso Incluir Biblioteca

NOME: Alterar Biblioteca

OBJETIVO • Alterar o registro ou dados de uma biblioteca;


FLUXO

PRINCIPAL




dados atuais;

• O endereço poderá ser alterado se o usuario clicar

no botão "Cadastro Endereco", que abre o caso de

uso "Modificar Endereco";


verificar se os campos obrigatórios da biblioteca não




biblioteca pelos atuais, fechar a janela e atualizar a

lista do caso de uso “Listar Biblioteca”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;



68

excluir todas as alterações feitas na biblioteca;

PRÉ-

CONDIÇÕES

• O ator deve ter escolhido a opção “Alterar” de uma

biblioteca da lista do caso de uso “Listar Biblioteca”;

PÓS-

CONDIÇÕES

• Os dados da biblioteca devem ter sido alterados no

banco de dados;


Tabela 63 - Descrição do caso de uso Alterar Biblioteca

NOME: Remover Biblioteca

OBJETIVO • Excluir um biblioteca do banco de dados;


FLUXO

PRINCIPAL

• O sistema deve abrir uma janela mostrando o nome da

biblioteca a ser excluída;




biblioteca e seus dados do banco de dados, fechar a


Biblioteca”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



PRÉ-

CONDIÇÕES


da lista do caso de uso “Listar Biblioteca”;

PÓS-

CONDIÇÕES

• Uma biblioteca deve ter sido removido do banco de

dados;


Tabela 64 - Descrição do caso de uso Remover Biblioteca

NOME: Pesquisa Automatica de Livro

OBJETIVO • Pesquisar um livro online, e registrar seus dados;


69

FLUXO

PRINCIPAL

• O sistema deve mostrar na suggestion box “Titulo”,

uma lista contendo os resultados da busca da

pesquisa feita automaticamente pelo sistema;

• Quando o ator clicar em um item da lista o sistema

deve atualizar todos os campos do Livro com os

valores correspondente ao livro selecionado;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES

• Se o autor não clicar em nenhum, os dados da

pesquisa são descartados e o ator terá de colocar as

informações do livro manualmente;

PRÉ-

CONDIÇÕES

• O ator deve ter digitado o título do livro, no suggestion

box “Titulo” do caso de uso “Incluir Livro”;

PÓS-

CONDIÇÕES

• Os dados do livro devem ter sido procurados, e

registrado conforme a escolha do ator;


Tabela 65 - Descrição do caso de uso Pesquisa Automática de Livro

NOME: Modificar Endereco

OBJETIVO • Adicionar um endereco ao banco de dados ou

alterar um já existente;


FLUXO

PRINCIPAL

• O sistema deve verificar automaticamente se o

usuário está adicionando um novo endereco ou

querendo alterar um já existente;

• Após a verificação é aberta uma janela com o nome

de todos os atributos e seus respectivos campos de

preenchimento;

• Se na verificação do sistema for constatado que o

usuario está querendo alterar os dados de

endereco, os campos já devem estar preenchidos,

mas se for um novo endereco, os campos de

preenchimento devem estar vazios;

• Quando o ator efetuar o cadastro/modificação, o

70

sistema deve verificar se os campos obrigatórios



o sistema adiciona este novo endereco ao banco de

dados com os atributos preenchidos e fecha a

janela;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;



excluir todas as informações referentes a

modificação/inclusão do endereço;

PRÉ-

CONDIÇÕES

• O ator deve ter clicado no botão “Cadastro

Endereco” no caso de uso “Incluir/Alterar Campi”,

"Incluir/Alterar Biblioteca" ou “Incluir/Alterar Pessoa”;

PÓS-

CONDIÇÕES

• Deve ser adicionado um endereço ao banco de

dados;


Tabela 66- Descrição do caso de uso Modificar Endereco

NOME: Gerenciar Área Conhecimento


de área de conhecimento (incluir, alterar, remover,

listar);


FLUXO

PRINCIPAL


botão "Nova Área", para inclusão, e executar o caso

de uso "Listar Área Conhecimento";



FLUXO

ALTERNATIVO



71

E DE

EXCEÇÕES


uso deve ser parado imediatamente e o usuario


PRÉ-

CONDIÇÕES

• A opção “Gerenciar Área Conhecimento” deve ter

sido escolhida pelo ator no menu do sistema ;

PÓS-

CONDIÇÕES




Tabela 67 - Descrição do caso de uso Gerenciar Área Conhecimento

NOME: Listar Área Conhecimento

OBJETIVO • Mostrar uma lista das áreas de conhecimento

cadastradas no sistema e as possíveis ações;


FLUXO

PRINCIPAL

• Deve ser exibida uma tabela listando todas as áreas

já cadastrados no sistema;


área, dois botões que indiquem as opções de

“Alterar” ou “Remover” ;




FLUXO

ALTERNATIVO

E DE

EXCEÇÕES


dos itens da lista, o caso de uso “Gerenciar Área

Conhecimento” é executado normalmente;

PRÉ-

CONDIÇÕES

• O caso de uso “Gerenciar Área Conhecimento” deve


PÓS-

CONDIÇÕES


pelo ator;


Tabela 68- Descrição do caso de uso Listar Área Conhecimento

72

NOME: Incluir Área Conhecimento

OBJETIVO • Adicionar uma área de conhecimento ao banco de

dados;


FLUXO

PRINCIPAL



preenchimento;



ou nulos;


o sistema adiciona esta área de conhecimento ao

banco de dados com os atributos preenchidos e

fecha a janela;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;




da nova área de conhecimento;

PRÉ-

CONDIÇÕES

• O ator deve ter escolhido a opção “Incluir Área

Conhecimento” no caso de uso “Gerenciar Área

Conhecimento”;

PÓS-

CONDIÇÕES

• Deve ser adicionado uma área de conhecimento ao

banco de dados;


Tabela 69 - Descrição do caso de uso Incluir Área Conhecimento

NOME: Alterar Área Conhecimento

OBJETIVO • Alterar o registro ou dados de uma área de

conhecimento;


73

FLUXO

PRINCIPAL




dados atuais;



ou nulos;



área de conhecimento pelos atuais, fechar a janela

e atualizar a lista do caso de uso “Listar Área

Conhecimento”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



ao ator;



excluir todas as alterações feitas na área de

conhecimento;

PRÉ-

CONDIÇÕES


item da lista do caso de uso “Listar Área

Conhecimento”;

PÓS-

CONDIÇÕES

• Os dados da área de conhecimento devem ter sido



Tabela 70 - Descrição do caso de uso Alterar Área Conhecimento

NOME: Remover Área Conhecimento

OBJETIVO • Excluir uma área de conhecimento do banco de

dados;


FLUXO

PRINCIPAL

• O sistema deve abrir uma janela mostrando o nome da

área a ser excluída;

74




área de conhecimento e seus dados do banco de

dados, fechar a janela e atualizar a lista do caso de

uso “Listar Área Conhecimento”;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES



PRÉ-

CONDIÇÕES


da lista do caso de uso “Listar Área Conhecimento”;

PÓS-

CONDIÇÕES

• Uma Área de Conhecimento deve ter sido removida do

banco de dados;


Tabela 71 - Descrição do caso de uso Remover Área Conhecimento

NOME: Pesquisa Automatica de Livro

OBJETIVO • Pesquisar um livro online, e registrar seus dados;


FLUXO

PRINCIPAL

• O sistema deve mostrar na suggestion box “Titulo”,

uma lista contendo os resultados da busca da

pesquisa feita automaticamente pelo sistema;

• Quando o ator clicar em um item da lista o sistema

deve atualizar todos os campos do Livro com os

valores correspondente ao livro selecionado;

FLUXO

ALTERNATIVO

E DE

EXCEÇÕES

• Se o autor não clicar em nenhum, os dados da

pesquisa são descartados e o ator terá de colocar as

informações do livro manualmente;

PRÉ-

CONDIÇÕES

• O ator deve ter digitado o título do livro, no suggestion

box “Titulo” do caso de uso “Incluir Livro”;

PÓS- • Os dados do livro devem ter sido procurados, e

75

CONDIÇÕES registrado conforme a escolha do ator;


Tabela 72 - Descrição do caso de uso Pesquisa Automática de Livro

3.2 DIAGRAMA DE CLASSES

Aqui será apresentado o Diagrama de Classes do projeto, que conterá todas

as classes utilizadas no desenvolvimento do sistema, seus respectivos atributos e

métodos, além dos relacionamentos entre elas.

O Diagrama de Classes está dividido em duas figuras, separando o

diagrama principal das classes de acesso ao Banco de Dados (Classes DAO), com

o intuito de organiza-lo para melhor entendimento.

3.2.1 Classes DAO

76

FIGURA 2 – Classes DAO

77

3.2.2 Classes de Entidade, Facades e Managed Beans

78

FIGURA 3 - Classes de Entidade, Facades e Managed Beans

79

3.3 MODELO LÓGICO DA BASE DE DADOS

A seguir serão apresentados os diagramas referentes à lógica de criação do

banco de dados que são: diagrama de entidade e relacionamento, diagrama do

modelo relacional e dicionário de dados.

3.3.1 Diagrama de Entidade e Relacionamento (DER)

O Diagrama de Entidade e Relacionamento (DER) é basicamente composto

por uma série de componentes, que são: atributos, relacionamentos, entidades e

indicadores de tipo dos atributos. Para Pressman (1995), o principal propósito de um

DER é representar entidades (objeto de dados) e seus relacionamentos com outras

entidades.

80

FIGURA 4 - Diagrama de Entidades e Relacionamentos

81

3.3.2 Diagrama do Modelo Relacional

O diagrama do modelo relacional é feito a partir da modelagem do DER e é

uma forma de representar graficamente a estrutura e organização do banco de

dados relacional em tabelas.

82

FIGURA 5 - Diagrama do Modelo Relacional

83

3.3.3 Dicionário de dados

Segundo Pressman (1995), o dicionário de dados é uma listagem

organizada de todos os elementos de dados que são pertinentes ao sistema com

precisão e definições rigorosas para que o usuário e o analista de sistema tenham

uma comum compreensão de entradas, saídas, componentes armazenados e

cáculos internmediários.

Nome Descrição Tipo Tamanho Nulo Regra Chaves Default Unique

nome

Armazena o

nome do

campus

varchar 30 --- --- --- --- X

cnpj

Armazena o

CNPJ do

campus

int --- --- --- --- --- X

nomeRe

present

ante

Armazena o

nome do

representante

do campus

varchar 30 --- --- --- --- ---

email Armazena o e-

mail do campus varchar 30 X --- --- --- ---

id Armazena o ID

do campus int --- --- --- PK --- ---

enderec

o_id

Armazena o ID

do endereço do

campus

int --- X --- FK --- ---

telefone

Armazena um

número de

telefone

int --- X --- --- --- ---

Campi

Tabela 48 - Dicionário de dados da tabela Campi


84

nome Armazena o

nome da biblioteca

varchar 30 --- --- --- --- X

email Armazena o

email da biblioteca

varchar 30 X --- --- --- ---

nomeRepresent

ante

Armazena o nome do

representante da biblioteca

varchar 30 --- --- --- --- ---

id Armazena o ID da biblioteca int --- --- --- PK --- ---

endereco_id

Armazena o ID do endereço da

biblioteca int --- X --- FK --- ---

campus_id

Armazena o ID do campus a

que a biblioteca pertence

Int --- X --- FK --- ---

telefone Armazena um

número de telefone

int --- X --- --- --- ---

Biblioteca Tabela 49 - Dicionário de dados da tabela Biblioteca


cnpj Armazena o

CNPJ da pessoa jurídica

int --- --- --- --- --- X

id_pessoa

Armazena o ID da pessoa

jurídica int --- --- --- PK/FK --- ---

PessoaJuridica Tabela 50 - Dicionário de dados da tabela PessoaJuridica


dataPedido

Armazena a data em que o pedido foi feito

date --- --- --- --- --- ---

id Armazena o ID do pedido

int --- --- --- PK --- ---

id_status

Armazena o ID do status do

pedido int X --- --- FK --- ---

id_usuario

Armazena o ID do usuario que

fez o pedido int --- --- --- FK --- ---

85

id_licitacao

Armazena o ID da licitação que

o pedido pertence

int X --- --- FK --- ---

Pedido Tabela 51 - Dicionário de dados da tabela Pedido


dataPesquisa

Armazena a data em que a pesquisa de livro foi feita

date --- X --- --- --- ---

sitePesquisa

Armazena o site onde a pesquisa de livro foi feita

varchar 100 X --- --- --- ---

quantidade

Armazena a quantidade de livros pedidos

int --- --- --- --- --- ---

valorUnitarioPes

quisa

Armazena o preço unitário

do livro de acordo com a pesquisa feita

double --- X --- --- --- ---

id Armazena o ID do item

int --- --- --- PK --- ---

id_pedido

Armazena o ID do pedido que o

item pertence int --- X --- FK --- ---

id_livro Armazena o ID

do livro requisitado

int --- --- --- FK --- ---

id_pessoa


jurídica do livro requisitado

int --- X --- FK --- ---

valorUnitarioFornecedor

Armazena o preço por

unidade do livro da pessoa

jurídica

double --- X --- --- --- ---

motivo

Motivo pelo qual o fornecedor

não pôde disponibilizar o

item

varchar 300 X --- --- --- ---

descontoFornec

edor

Armazena o desconto

oferecido pela double --- X --- --- --- ---

86

pessoa jurídica

dataCotacaoFornecedor

Armazena a data em que a pessoa jurídica

enviou seu preço

date --- X --- --- --- ---

Item Tabela 52 - Dicionário de dados da tabela Item

Nome Descrição Tipo Tamanho Nulo Regra Chaves Default Unique id_licita

cao Armazena o ID

da licitação int --- X --- FK --- ---

Fornecedor_id_pessoa

Armazena o ID da pessoa jurídica da licitação

int --- X --- FK --- ---

saldo Armazena o

orçamento da licitação

double --- --- --- --- --- ---

id


jurídica com a licitação

int --- --- --- PK --- ---

PessoaJuridicaLicitacao Tabela 53 - Dicionário de dados da tabela PessoaJuridicaLicitacao


inicio

Armazena a

data do início do

período de

licitação

date --- --- --- --- --- ---

nomencl

atura

Armazena a

nomenclatura

da licitação

varchar 30 --- --- --- --- ---

respons

avel

Armazena o

nome do

responsável

pela licitação

varchar 30 --- --- --- --- ---

id Armazena o ID

da licitação int --- --- --- --- --- ---

87

process

o

Armazena o

número do

processo

int --- --- --- --- --- X

termino

Armazena a

data do término

do período de

licitação

date --- --- --- --- --- ---

Licitacao

Tabela 54 - Dicionário de dados da tabela Licitacao

Nome Descrição Tipo Tamanho Nulo Regra Chaves Default Unique complemento

Armazena o complemento varchar 30 X --- --- --- ---

rua Armazena a rua varchar 30 X --- --- --- ---

uf Armazena o UF varchar 2 X --- --- PR ---

cep Armazena o CEP

int --- X --- --- --- X

cidade Armazena a cidade

varchar 30 X --- --- --- ---

bairro Armazena o

bairro varchar 30 X --- --- --- ---

numero Armazena o numero do

complemento int --- X --- --- --- ---

id Armazena o código do endereço

int --- --- --- PK --- ---

Endereco Tabela 55 - Dicionário de dados da tabela Endereco


email Armazena o email da pessoa

varchar 30 --- --- --- --- ---

nome Armazena o

nome da pessoa

varchar 30 --- --- --- --- ---

endereco_id

Armazena código do endereço

int --- X --- FK --- ---

88

id_pessoaJuridi

ca

Armazena código do

fornecedor ao qual a pessoa

faz parte

int --- X --- FK --- ---

senha Armazena a

senha da pessoa

text --- --- --- --- --- ---

role Indica se a

pessoa é um administrador

varchar 50 --- --- --- FALSE ---

id Armazena o código da

pessoa int --- --- --- PK --- ---

telefoneCelular

Armazena um número de

telefone dos três disponíveis

int --- X --- --- --- ---

telefoneComerci

al



int --- X --- --- --- ---

telefoneResiden

cial



int --- X --- --- --- ---

Pessoa Tabela 56 - Dicionário de dados da tabela Pessoa


matricula

Armazena a matricula da pessoa física

varchar 30 --- --- --- --- X

rg Armazena o rg

da pessoa física int --- --- --- --- --- X

cpf Armazena o cpf da pessoa física int --- --- --- --- --- X

id_biblioteca

Armazena o id da biblioteca ao qual a pessoa física pertence

int --- --- --- FK --- ---

id_pessoa

Armazena o código da

pessoa física int --- --- --- PK/FK --- ---

PessoaFisica Tabela 57 - Dicionário de dados da tabela PessoaFisica

89


editora Armazena a

editora do livro varchar 30 --- --- --- --- ---

id_área_conhecimento

Armazena o id da área de

conhecimento do livro

int --- X --- FK --- ---

autor Armazena o autor do livro varchar 30 --- --- --- --- ---

isbn Armazena o isbn do livro

int --- --- --- --- --- X

isbn13 Armazena o isbn-13 do livro

int --- X --- --- --- X

volume Armazena o volume do livro

int --- --- --- --- --- ---

ano Armazena o ano do livro

date --- X --- --- --- ---

titulo Armazena o titulo do livro varchar 30 --- --- --- --- ---

edicao Armazena a

edição do livro int --- --- --- --- --- ---

id Armazena o

código do livro int --- --- --- PK --- ---

Livro Tabela 58 - Dicionário de dados da tabela Livro


id_pessoaFisica

Armazena o ID da pessoa física

professor int --- --- --- PK/FK --- ---

funcao_id

Armazena o ID da função do

professor int --- X --- FK --- ---

Professor Tabela 59 - Dicionário de dados da tabela Professor


cargo_id

Armazena o código do cargo

do servidor público na instituição

int --- X --- FK --- ---

id_pessoaFisica


pessoa física servidor público

int --- --- --- PK/FK --- ---

90

Servidor Público Tabela 60 - Dicionário de dados da tabela ServidorPublico


id Armazena o código da disciplina

int --- --- --- PK --- ---

nome Armazena o

nome da disciplina

varchar 30 --- --- --- --- X

Disciplina Tabela 61 - Dicionário de dados da tabela Disciplina


id_disciplina

Armazena o código da disciplina

int --- --- --- PK/FK --- ---

professor_id_pessoaFi

sica

Armazena o código do professor

int --- --- --- PK/FK --- ---

ProfessorDisciplina Tabela 62 - Dicionário de dados da tabela ProfessorDisciplina


id Armazena o código da

função int --- --- --- PK --- ---

nome Armazena o

nome da função varchar 30 --- --- --- --- X

Funcao Tabela 63 - Dicionário de dados da tabela Funcao


id Armazena o

código do cargo int --- --- --- PK --- ---

nome Armazena o nome do cargo

varchar 30 --- --- --- --- X

Cargo Tabela 64 - Dicionário de dados da tabela Cargo


91

id Armazena o código do status

int --- --- --- PK --- ---

icone Armazena um

ícone para status

varchar 100 X --- --- --- ---

nome Armazena o

nome do status varchar 30 --- --- --- --- X

Status Tabela 65 - Dicionário de dados da tabela Status

Nome Descrição Tipo Tamanho Nulo Regra Chaves Default Unique id Armazena o

código da área int --- --- --- PK --- ---

nome Armazena o nome da área

varchar 30 --- --- --- --- X

ÁreaDoConhecimento Tabela 66 - Dicionário de dados da tabela ÁreaDoConhecimento

Nome Descrição Tipo Tamanho Nulo Regra Chaves Default Unique id Armazena o

código do registro

int --- --- --- PK --- ---

id_item Armazena o código do item

recebido

int --- --- --- FK --- ---

data Armazena a data em que

foram recebidos os livros

date --- --- --- --- --- ---

quantidade

Armazena o quantidade

recebida

int --- --- --- --- --- ---

RegistroRecebimento Tabela 67 - Dicionário de dados da tabela RegistroRecebimento

Nome Descrição Tipo Tamanho Nulo Regra Chaves Default Unique pessoaJuridicaLicitacao_

id


pessoaJuridicaLicitacao

int --- --- --- PK/FK --- ---

áreasConhecimento_id

Armazena o nome da áreas de conhecime

int --- --- --- PK/FK --- ---

92

PessoaJuridicaLicitacao_ÁreaConhecimento Tabela 86 - Dicionário de dados da tabela PessoaJuridicaLicitacao_ÁreaConhecimento

93

4 IMPLEMENTAÇÃO DO SISTEMA E SUAS FUNCIONALIDADES

Neste capítulo serão apresentadas as principais funcionalidades do sistema,

assim como as principais interfaces e suas funções (todas as telas aqui mostradas

estão na visão do administrador).

4.1 MENU

Através do menu, localizado em todas as páginas do sistema (com exceção

da página de Login), o usuário pode transitar por entre todas as páginas acessíveis

a seu tipo de usuário. É composta por “Menu”, “Sistema” e “Cadastro”.

FIGURA 6 – Página Inicial

FIGURA 71 – Menu de Sistema

94

FIGURA 8 – Menu de Cadastro

4.2 PESSOAS

A página de Gerenciamento de Pessoas tem a função de realizar operações

com todo o tipo de pessoas relacionadas ao sistema (ver Tabela 1). Esta página

contém um painel com o formulário de pesquisa que pode ser mostrado através do

link “Pesquisar” e ocultado através do link “Ocultar Pesquisa”. Também tem uma

tabela que lista todas as pessoas cadastradas no sistema (ver Tabela 2). O

administrador pode escolher Editar ou Remover qualquer pessoa da tabela através

dos botões localizados na coluna “Ações”. Pode também escolher Visualizar

representantes caso a pessoa escolhida seja uma Pessoa Jurídica.

95

FIGURA 9 – Gerenciamento de Pessoas

No topo existe o botão “Nova Pessoa”, que abre a janela de cadastro de

pessoas, que é composta de três etapas: Dados Comuns, Endereço e Dados

Específicos (ver Tabela 3).

FIGURA 10 – Tela de Cadastro de Pessoas, Etapa 1

96



97

4.3 LICITAÇÕES

A página de Gerenciamento de Licitações tem a função de realizar

operações com licitações (ver Tabela 6). Esta página contém um painel com o

formulário e as opções de pesquisa (por nomenclatura ou responsável), que pode

ser mostrado através do link “Pesquisar” e ocultado através do link “Ocultar

Pesquisa”.. Também apresenta uma tabela que lista todas as licitações já

cadastradas em ordem decrescente de id (ver Tabela 26). O administrador pode

escolher Editar, Remover, Visualizar, Adicionar Pedidos ou Adicionar Fornecedores

em cada licitação da tabela através dos botões localizados na coluna “Ações”.

FIGURA 13 – Gerenciamento de Licitações

No topo existe o botão “Nova Licitação”, que abre a janela de cadastro de

licitações (ver Tabela 8). Ao preencher corretamente todos os campos e clicar em

“Salvar”, o sistema automaticamente envia um e-mail a todos os professores e

servidores públicos notificando-os sobre início do período de licitação.

98

FIGURA 14 – Tela de Cadastro de Licitações

4.4 LIVROS

A página de Gerenciamento de Livros tem a função de realizar operações

com livros (ver Tabela 45). Esta página contém um painel com o formulário e as

opções de pesquisa (por título, autor, editora, ISBN ou área de conhecimento) que

pode ser mostrado através do link “Pesquisar” e ocultado através do link “Ocultar

Pesquisa”. Também tem uma tabela que lista todos os livros já cadastrados no

sistema (ver Tabela 46). O administrador pode escolher Editar ou Remover qualquer

livro da tabela através dos botões localizados na coluna “Ações”.

99

FIGURA 15 – Gerenciamento de Livros

No topo existe o botão “Novo Livro”, que abre a janela de cadastro de livros

(ver Tabela 47). Na janela, ao preencher com ao menos três caracteres o campo

“Título” e apertar o tabulador o sistema realiza a pesquisa automática de livros que

contenham o texto digitado (ver Tabela 65). Os resultados são armazenados na

tabela da parte inferior da tela. O usuário pode utilizar o botão “Copiar Dados”,

localizado na coluna “Ações” da tabela de resultados, para preencher

automaticamente os campos do livro.

100

FIGURA 16 – Tela de Cadastro de Livros

4.5 PEDIDOS

A página de Gerenciamento de Pedidos tem a função de realizar operações

com livros (ver Tabela 45). Esta página contém uma tabela que lista todos os

pedidos cadastrados no sistema pelo respectivo usuário ou todos, se o usuário for

administrador (ver Tabela 46). O usuário pode escolher Visualizar, Editar ou

Remover qualquer pedido da tabela através dos botões localizados na coluna

“Ações”. Se for administrador também pode alterar o status do pedido.

101

FIGURA 17 – Gerenciamento de Pedidos

No topo existe o botão “Novo Pedido”, que abre a janela de cadastro de

pedidos (ver Tabela 52). Esta janela é composta de duas abas. A primeira contém

os campos de preenchimento dos atributos do item (ver Tabela 57) e a segunda os

dados do livro selecionado. Ao selecionar um livro e apertar o tabulador, o sistema

automaticamente pesquisa o preço deste e preenche o campo “Valor unitário

pesquisado”. Ao adicionar um item, o sistema adiciona este à tabela na parte inferior

da página, onde o usuário pode remove-lo através do botão localizado na coluna

“Ações” (ver Tabela 55).

102

FIGURA 18 – Tela de Cadastro de Pedidos

103

5 CONSIDERAÇÕES FINAIS

Neste capítulo serão apresentados os resultados finais e objetivos atingidos

com a implementação do Papyrus.

5.1 RESULTADOS E TRABALHOS FUTUROS

Os objetivos propostos foram alcançados com êxito. O sistema permite o

cadastro de pessoas em geral (professores, servidores públicos, fornecedores),

didciplinas, cargos, funções, áreas de conhecimento, livros, bibliotecas, campi,

status e licitações. Todos os cadastros funcionam através de janelas com campos

de preenchimento dos atributos a serem persistidos no banco de dados, facilitando o

armazenamento de dados assim como a segurança dos mesmos pelo uso de uma

base de dados ao invés de planilhas eletrônicas.

Através do Jboss Mail, o sistema envia automaticamente e-mails quando

ocorre a alteração do status de um pedido (para o respectivo “pedinte”), a abertura

de um processo de licitação (para todos os usuários que possam realizar pedidos),

quando um fornecedor realiza a cotação de um item (para o administrador) e na

alteração dos pedidos de uma licitação (para os fornecedores). Este processo, além

de economizar tempo de todos os usuários do sistema, facilita a interação dos

clientes com o administrador através da página de Contatar Administrador.

O sistema também permite a pesquisa de livros e seus dados no site da

Livrarias Cultura. Utilizando a biblioteca java.net, o sistema faz a procura do livro na

ferramenta de pesquisa do portal da livraria, faz o download da página de resultados

e mostra-os em uma tabela na tela de cadastro de livro. Ao copiar os dados, os

campos do livro são preenchidos automaticamente com os dados do item

selecionado da tabela. Método semelhante é utilizado na pesquisa de preço, que

automaticamente pesquisa o valor unitário do livro requisitado no mesmo site.

Ao receber um certo número de itens, o administrador do sistema pode

cadastrar o recebimento destes no sistema, que enviará uma notificação via e-mail

automática ao usuário que requeriu o item. O usuário também poderá verificar todos

os seus pedidos realizados assim como o status de cada um.

A solicitação de livros se dá a partir da tela de cadastro de pedidos, onde o

usuário selciona um livro (ou pesquisa um novo caso ele não exista), informa o site

104

de pesquisa (por padrão a LivrariasCultura.com) e o valor pesquisado (feito

automaticamente pelo sistema).

No futuro, seria de grande contribuição ao processo a geração de relatórios

no formato “.pdf”, contendo a listagem de licitações ou de listagem de itens de uma

licitação.

105

REFERÊNCIAS

AMBLER, S., Mapping Objects to Relational Databases: O/R Mapping In Detail [S.l.: s.n.]. Disponível em: <http://www.agiledata.org/essays/mappingObjects.html>. Acesso em: 20 mar. 2011.

AMBLER, S., The Object-Relational Impedance Mismatch [S.l.: s.n.]. Disponível em: <http://www.agiledata.org/essays/impedanceMismatch.html>. Acesso em: 20 mar. 2011.

BAUER, C.; KING, G., Java Persistence with Hibernate [S.l.]: Manning, 2006.

COMPANION CORPORATION. Alexandria. Disponível em: <http://www.alexandria.cl/>. Acesso em: 27 abr. 2011.

DATE, C., Introdução a Sistemas de Banco de Dados. [S.l.]: Campus, 2000.

ECKSTEIN, R. Java SE Application Design With MVC. [S.I. : s.n.], mar. 2007. Disponível em: <http://www.oracle.com/technetwork/articles/javase/index-142890.html#1>. Acesso em: 20 mar. 2011.

FARLEY, J. (20 jul 2007). PracticalJBossSeamProjects (First ed.). Apress.pp. 229.ISBN 1590598636.

FOWLER, M. Inversion of Control Containers and the Dependency Injection pattern.[S.I. : s.n.],23 jan. 2004. Disponível em: <http://martinfowler.com/articles/injection.html>. Acesso em: 20 mar. 2011

GAMMA, E. et al. Design Patterns: Elements of Reusable Object-Oriented Software.[S.I.]: Addison-Wesley Professional, 2000.

HORSTMANN, C.; CORNELL, G. Core JavaTM 2 - Fundamentos. Tradução João Eduardo Nóbrega Tortello. São Paulo: Makron Books, 2001. 1 v.

KORTH, H.; SILBERSCHATZ, A.; SUDARSHAN, S., Sistema de Banco de Dados. 3. ed. [S.I.]: Makron Books.

106

LARMAN,C. Utilizando UML e Padrões: Uma introdução à análise e ao projeto orientados a objetos. Porto Alegre : Bookman, 2000

MYERS, G. The Art of Software Tests. 1. ed. [S. I.] : Wiley, 1979.

ORACLE. MySQL 5.5 Reference Manual. Disponível em: <http://dev.mysql.com/doc/refman/5.5/en/what-is-mysql.html>. Acesso em: 26 mar. 2011.

ORACLE. Saiba mais sobre a tecnologia Java. Disponível em: <http://www.java.com/pt_BR/about/>. Acesso em: 06 abr. 2011.

PRADO, A. O que é a plataforma Java. Disponível em: <http://www.devmedia.com.br/articles/post-6044-O-que-e-a-plataforma-Java.html>. Acesso em: 22 mar 2011.

PRESSMAN, R. Engenharia de software. Tradução José Carlos Barbosa dos Santos. São Paulo : Markron, 1995

PRIMASOFT. Sophia Biblioteca. Disponível em: <http://www.primasoft.com.br/2006/html/interna_2.php?cod=1345&segmento=36&cor=12&titulosegmento=Outras%20Bibliotecas&imagem=uplimagens/72cb150a4eff8421693ec99d0e8997ae.jpg>. Acesso em: 27 abr. 2011.

PUC-PR. Conheça o Pergamum. Disponível em: <http://www.pergamum.pucpr.br/redepergamum/>. Acesso em: 27 abr. 2011.

RED HAT. JBossSeam. Disponível em: <http://www.jboss.com/products/seam/>. Acesso em: 22 mar. 2011.

REDE NACIONAL DE ENSINO E PESQUISA. O que é middleware. Disponível em: <http://www.rnp.br/noticias/2006/not-060926.html>. Acesso em: 01 jun. 2011.

SUEHRING, S. MySQL Bible [S.l.]: Willey, 2002.

SUN MYCROSYSTEMS. Core J2EE Pattern Catalog: Core J2EE Patterns - Data Access Object. [S.I. : s.n.], © 2001-2002. Disponível em: <http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html>. Acesso em: 21 mar. 2011.

107

SEAMFRAMEWORK. Introduction to JBoss Seam. Disponível em: <http://docs.jboss.org/seam/latest/reference/en-US/html/Book-Preface.html>. Acesso em: 27 abr. 2011.

SOLIS. O que é Gnuteca?. Disponível em: <http://www.solis.org.br/projetos/gnuteca>. Acesso em: 27 abr. 2011.

108

GLOSSÁRIO

Licitação: é o procedimento administrativo para as compras ou serviços contratados

pelos governos, seja Federal, Estadual ou Municipal;

Pregão Eletrônico: é uma modalidade de licitação, na qual não há limites de

valores;

Cotação: é o ato de promover tomada de preços junto aos fornecedores

credenciados, para a realização do pedido de compra, ou seja, cotação nada mais é

do que a exploração, a pesquisa de preços.

109

ANEXO

A - Planilha usada de modelo para solicitações de livros.

LIS

TA

DE

LIV

RO

S P

AR

A C

OM

PR

A

AU

TO

R

TÍT

UL

O

VO

LU

ME

ED

IÇÃ

O

ED

ITO

RA

AN

O

ISB

N

TO

TA

L

QU

AN

T. E

XE

MP

LA

RE

S

0

VL

UN

IT R

$

VL

TO

TA

L R

$

R$

0,00

110

PÁ

GIN

A D

A P

ES

QU

ISA

DE

PR

EÇ

O

DA

TA

DA

PE

SQ

UIS

A

B – níveis do sistema SophiA.

instituto federal do paranÁ hudo cim assenÇo...

Documents