Gestão de Biblioteca da FATEC Tatuí

CENTRO PAULA SOUZA
FACULDADE DE TECNOLOGIA DE TATUÍ
CURSO SUPERIOR DE TECNOLOGIA EM GESTÃO DA TECNOLOGIA DA
INFORMAÇÃO
ANDERSON LUCAS DOS SANTOS
ROGÉRIO DE MORAES
SERGIO DE JESUS RIBEIRO JUNIOR
DESENVOLVIMENTO DO SOFTWARE DE GESTÃO DE BIBLIOTECA DA
FACULDADE DE TECNOLOGIA DE TATUI
Tatuí, SP
1º semestre / 2014

ROGÉRIO DE MORAES
DESENVOLVIMENTO DO SOFTWARE DE GESTÃO DE BIBLIOTECA DA
FACULDADE DE TECNOLOGIA DE TATUI
Tatuí, SP
1º semestre / 2014
Trabalho de Graduação apresentado à
Faculdade de Tecnologia de Tatuí,
como exigência parcial para obtenção
do grau de Tecnólogo em Gestão da
Tecnologia da Informação, sob a
orientação dos Professores Esp. José
Márcio Mathias e Osvaldo D'Estefano
Rosica.

ROGÉRIO DE MORAES
( ) Aprovado ( ) Reprovado
Com média
________________________________
Prof.
________________________________
Prof.
________________________________
Prof.
________________________________
Prof.
Tatuí, 20 de Junho de 2014
Trabalho de Graduação apresentado à
Faculdade de Tecnologia de Tatuí,
como exigência parcial para obtenção
do grau de Tecnólogo em Gestão da
Tecnologia da Informação, sob a
orientação dos Professores Esp. José
Márcio Mathias e Osvaldo D' Estefano
Rosica.

AGRADECIMENTOS
Agradecemos a todos os professores que se empenharam em nos transmitir
seus conhecimentos e suas experiências. Em especial ao professor Dr. Mauro
Tomazela, Professor Dr. Anderson Luiz de Souza, Prof. Dra. Eoná Mouro Ribeiro,
Professora Dra. Elide Silva Garcia Vivan, Professor Esp. José Marcio Matias,
Professora Esp. Patrícia Moreno, Professor Engenheiro Helder Boccaletti, Professor
Osvaldo D’ Estefano Rosica e Professor Gino Carlo Campra.

“É algo complicado, é difícil desenhar
produtos concentrando-se no público-alvo.
Muitas vezes, as pessoas não sabem o que
querem até que você mostre à elas. ”
(Steve Jobs)

RESUMO
Atualmente a Faculdade de Tecnologia de Tatuí utilizava-se de uma
ferramenta de gestão gratuita chamada OPENBIBLIO, a qual não possuía
flexibilidade, tal como não traz todos os itens necessários para uma gestão mais
eficiente. Visualizando essa necessidade, nosso projeto prevê itens necessários
colhidos durante o nosso levantamento de requisitos efetuados junto à
administração da biblioteca. Tendo como princípio para o desenvolvimento, a visão
de gerenciamento de projetos, de engenharia de software, técnicas de análise e
desenvolvimento de sistemas, por meio das quais nós optamos por utilizar uma
linguagem de programação para internet estável e segura (PHP), com o
desenvolvimento em formato de camadas MVC (baseado em Modelo – Lógica de
Negócios, Visão - Telas e Controle – Forma de interação), com o padrão CRUD
(Create / Criar, Retried / Consultar, Update / Alterar, Delete / Excluir), dessa forma
podendo o projeto, ser hospedado tanto localmente, como em nuvem (Internet).
Palavras-chaves: Biblioteca, Programação, Internet

ABSTRACT
Currently the college of Technology in Tatuí uses a free management tool
called OpenBiblio, which lacked flexibility, as it did not bring all necessary for a more
efficient management of items, you will see this need, our project provides necessary
items raised during the assessment required made by the management of the library,
as a principle for developing the vision of project management, software
development systems engineering, analysis techniques, and through which we chose
to use a programming language for stable and safe internet (PHP) with the
development of layers in MVC format (based on Model - Logical Business, Overview
- Screenshots and Control - form of interaction) with the standard CRUD (Create,
Retried, Change, Delete), this way the project can be hosted both locally and in the
cloud (Internet).
Key-words: Library, Programming, Internet

LISTA DE FIGURAS
Figura 1 - Satisfação dos usuários da biblioteca .................................................15
Figura 2 - Média de alocação de livros na biblioteca da FATEC Tatuí ...............16
Figura 3 - Nível de inadimplência de entrega de livros........................................16
Figura 4 - Modelo de casos de uso ator operador................................................31
Figura 5 - Modelo de casos de uso ator aluno......................................................31
Figura 6 - Diagrama de sequência de alocação....................................................33
Figura 7 - Diagrama de classes de projeto............................................................36
Figura 8 - Simbologia dos relacionamentos entre as classes.............................37
Figura 9 - Simbologia e terminologia do DER.......................................................38
Figura 10 - Diagrama de entidade relacionamento (DER)....................................40
Figura 11 - Exemplo de tela de cadastro de Materiais .........................................47
Figura 12 - Exemplo de tela de cadastro Cursos..................................................48
Figura 13 - Exemplo de tela de associação de cursos, materiais e disciplinas.49
Figura 14 - Exemplo de tela de relatórios de pendencias de livros ....................50
Figura 15 - Complexidade relativa às perguntas..................................................52
Figura 16 - Figura da com o cálculo de fator de ajuste........................................53
Figura 17 - Exemplo de visão de distribuição desktop........................................55
Figura 18 - Exemplo de visão de aplicação Web (servidor).................................56
Figura 19 - Exemplo de modelo de gráfico (Gantt)...............................................57
Figura 20 - Modelo de tabela em SQLite com chave candidata primaria ...........60
Figura 21 - Modelo de tabela em MySQL com chave candidata primaria...........61
Figura 22 - Modelo de tabela em SQLite com chave candidata secundaria.......62
Figura 23 - Exemplo de tabela em MySQL com chave candidata secundaria ...63
Figura 24 - Exemplo de modelo de VIEW SQlite e MySQL...................................63
Figura 25 - Exemplo de modelo de tabela de operações e Itens de operações.64
Figura 26 - Exemplo de modelo de VIEW de operações em MySQL...................65
Figura 27 - Exemplo de Trigger para atualizar registros de status.....................66
Figura 28 - Modelo de modelagem EER do banco de dados...............................67
Figura 29 - Tela de login do sistema......................................................................80
Figura 30 - Tela Inicial do sistema .........................................................................80
Figura 31 - Tela de cadastro de alunos .................................................................81
Figura 32 - Tela de cadastro de materiais .............................................................81

Figura 33 - Tela de cadastro de Cursos.................................................................82
Figura 34 - Tela de cadastro de Disciplinas..........................................................82
Figura 35 - Tela de Gerenciamento de Associação Materiais .............................83
Figura 36 - Tela de Gerenciamento de alocações ................................................83
Figura 37 - Tela de Geração de alocação ..............................................................84
Figura 38 - Tela de geração de relatório geral pendências para conferências..84

LISTA DE TABELAS
Tabela 1: Casos de uso – Ator operador...............................................................30
Tabela 2: Casos de uso – Ator aluno.....................................................................30
Tabela 3: Cálculo de complexidade ALI e AIE ......................................................42
Tabela 4: Exemplo de arquivos lógicos interno aluno.........................................43
Tabela 5: Exemplo de arquivos lógicos interno operador...................................43
Tabela 6: Exemplo de Arquivos lógicos interno alocação ..................................43
Tabela 7: Exemplo de arquivos lógicos interno alocação...................................44
Tabela 8: Exemplo de arquivos lógicos interno material.....................................44
Tabela 9: Exemplo de Arquivos de interface externa de aluno atendido...........45
Tabela 10: Exemplo de AIE de materiais cadastrados.........................................46
Tabela 11: Exemplo de Arquivos de interface externa de curso cadastrado.....46
Tabela 12: Cálculo de complexidade de ALR .......................................................47
Tabela 13: Exemplo de tabela de cálculo de pontos por função ........................51
Tabela 14: Exemplo de tabela de perguntas com os principais requisitos........52
Tabela 15: Exemplo de tabela de cálculos das pontuações finais .....................54
Tabela 16: Exemplo de tabela de visão sobre distribuição do desktop .............55
Tabela 17: Tabela de exemplo da visão aplicação Web (servidor) .....................56
Tabela 18: Tabela operador....................................................................................76
Tabela 19: Tabela regra de sistema .......................................................................76
Tabela 20: Tabela aluguel operação ......................................................................76
Tabela 21: Tabela Cadastro de alunos ..................................................................77
Tabela 22: Tabela aluguel operação itens.............................................................77
Tabela 23: Tabela entrada de itens........................................................................77
Tabela 24: Tabela itens perdidos...........................................................................78
Tabela 25: Tabela saída de itens............................................................................78
Tabela 26: Tabela material......................................................................................78
Tabela 27: Tabela cursos........................................................................................79
Tabela 28: Tabela disciplinas.................................................................................79

LISTA DE SIGLAS
ABNT - Associação Brasileira de Normas Técnicas
ANSI - American National Standards Institute
ASP - Active Server Pages
BD - Banco de Dados
COBIT - Control Objectives for Information and related Technology
DB - Database
CRUD - Create, Retried, Update, Delete (Criar, Consultar, Atualizar, Apagar)
FATEC - Faculdade de Tecnologia
HTML - Hyper Text Markup Language
ISO - International Organization for Standardization
JQuery - Biblioteca JavaScript cross-browser
MySQL - Linguagem de Consulta Estruturada (Structured Query Language)
MVC - Model, View, Control (Camadas - Modelo, Visão, Controle)
NBR - Norma Brasileira
PHP - Hypertext Preprocessor
PF - Pontos por função
PMBOK - Project Management Body of Knowledge
SGBD - Sistema Gerenciador de Banco de Dados
SQL - Structured Query Language (Linguagem de Banco de Dados)
XML - Extensible Markup Language
Web - World Wide Web (Internet)

SUMÁRIO
1 INTRODUÇÃO .......................................................................................................14
2 FASES DO PROJETO DO SISTEMA....................................................................19
3 SOFTWARE E SEU DESENVOLVIMENTO ..........................................................23
3.1 ENGENHARIA DE SOFTWARE ......................................................................23
3.2 DESENVOLVIMENTO DO SOFTWARE..........................................................23
4 VISÃO GERAL DO SISTEMA ...............................................................................25
4.1 REQUISITOS FUNCIONAIS DO SISTEMA.....................................................25
4.1.1 Cadastro de materiais .............................................................................25
4.1.2 Cadastro de alunos..................................................................................26
4.1.3 Cadastro de operador..............................................................................26
4.2 REQUISITOS NÃO FUNCIONAIS DO SISTEMA ............................................27
4.2.1 Segurança e confiabilidade ....................................................................27
4.2.2 Tolerância a falhas...................................................................................27
4.2.3 Portabilidade ............................................................................................28
4.2.4 Hardware ..................................................................................................28
4.2.5 Software....................................................................................................28
5 VISÃO DE CASO DE USO ....................................................................................29
5.1 CONCEITO DE CASO DE USO ......................................................................29
5.2 OPERAÇÃO DO SISTEMA..............................................................................29
5.3 DEFINIÇÃO DE ATORES................................................................................29
5.4 TABELA DE CASOS DE USO .........................................................................30
5.4.1 Modelos de casos de uso .......................................................................30
6 MODELOS DE SEQUÊNCIA.................................................................................32
6.1 DIAGRAMAS DE SEQUÊNCIA........................................................................32
7 VISÃO LÓGICA – NÍVEL DE ANALISE ................................................................34
7.1 RELACIONAMENTOS PRINCIPAIS ENTRE AS CLASSES ...........................34
7.2 DIAGRAMA DE CLASSES DO PROJETO ......................................................35
7.3 SÍMBOLOS DOS RELACIONAMENTOS ENTRE AS CLASSES ....................37
8 DIAGRAMAS DE ENTIDADE E RELACIONAMENTO .........................................38
8.1 RELACIONAMENTOS ENTRE ENTIDADES ..................................................38
9 VISÃO GERENCIAL: GERENCIAMENTO DE PROJETO ....................................41

9.1 MÉTRICAS DE SOFTWARE ...........................................................................41
9.2 PONTOS POR FUNÇÃO .................................................................................42
9.2.1 Arquivos lógicos internos.......................................................................42
9.2.2 Arquivos interface externa (AIE) ............................................................45
9.2.3 Entradas externas (EE)............................................................................47
9.2.4 Consultas externas (CE) .........................................................................48
9.2.5 Saídas externas (SE) ...............................................................................49
10 PLANEJAMENTO POR DECOMPOSIÇÃO ........................................................51
10.1 TABELA DE CONTAGEM..............................................................................51
10.2 QUESTÕES DE AVALIAÇÃO DE COMPLEXIDADE DE SOFTWARE .........51
10.3 CÁLCULO DO FATOR DE AJUSTE..............................................................52
10.4 PRODUTIVIDADE, QUALIDADE, PREÇO E DOCUMENTAÇÃO .................53
11 VISÃO SOBRE DISTRIBUIÇÃO E IMPLEMENTAÇÃO (DEPLOYMENT)..........55
12 CRONOGRAMA ..................................................................................................57
13 BANCO DE DADOS DO SISTEMA .....................................................................58
13.1 INTRODUÇÃO A BANCO DE DADOS E SUAS REGRAS ............................58
13.2 DESENVOLVIMENTO DE TABELAS DO SISTEMA E VIEWS .....................60
13.3 DESENVOLVIMENTO DE TRIGGERS (GATILHOS) ....................................65
13.4 REPRESENTAÇÃO DO MODELO LÓGICO RELACIONAL DO BANCO DE
DADOS ..................................................................................................................66
14 SISTEMA EM MVC E CRUD COM PHP E MYSQL.............................................68
14.1 INTRODUÇÃO A CONCEITOS DE CRUD EM SISTEMA MVC ....................68
15 CONSIDERAÇÕES FINAIS.................................................................................70
REFERÊNCIAS.........................................................................................................71
APÊNDICES .............................................................................................................73
Apêndice A – Glossário de Termos Técnicos ........................................................74
Apêndice B – Entrevista com o cliente sobre satisfação e melhorias ....................75
Apêndice C – Dicionário de Dados do Banco de Dados........................................76
Apêndice D – Telas do sistema .............................................................................80

14
1 INTRODUÇÃO
No mundo globalizado, onde vivemos a necessidade da inovação, é
decorrente de uma sequência de ações compostas por implementação e
implantação, as quais nos permite gerar um acesso mais seguro e com maior
integridade de informações, sendo esse um fator importante para uma gestão mais
exata e funcional em todos os setores e processos.
Sendo por meio dessa evolução onde a segurança da informação, tal como a
integridade dos dados, começou a apresentar e a gerar muitas melhorias por meios
de softwares, a qual antigamente as bibliotecas eram gerenciadas por meio de
entradas manuscritas em livros de controle, tendo em vista que o mesmo permitia
haver erros de cadastramento, tanto relativos a quem fez a sua alocação, tal como
do item alocado, assim como podendo haver falhas com relação à quantificação
exata de exemplares, seu estado, duplicidade de informações, assim como possível
perda da mesma em caso de problemas gerados por forças naturais (Ex.:
Incêndios).
O fator da duplicidade, onde a necessidade de implantação de um sistema
apenas informatizado, não é fator decisivo para evitar a falha do mesmo.
Atualmente, o sistema (OPENBIBLIO) utilizado na faculdade de tecnologia de Tatuí,
disponibilizado no SOURCEFORGET (Código Aberto / Livre), apresenta campos
desnecessários, como também, não apresenta todos os requisitos e solicitações
identificados como necessários pela instituição.
O novo software de gestão de biblioteca da Faculdade de Tecnologia de Tatuí
prevê solucionar os atuais problemas, levantados por uma entrevista feita com os
atuais funcionários da biblioteca, onde foram encontrados entre eles, as possíveis
melhorias; o controle dos livros alocados e disponíveis com o bloqueio de uso em
caso de exceder o prazo estabelecido pela instituição, tal como suspensão da
carteirinha aplicada ao RA (Registro do Aluno) do aluno que não atenda os prazos
estabelecidos no sistema, seguindo as regras da biblioteca que poderá ser
contemplada de forma eficaz com a utilização do software proposto, efetuando a
geração de relatórios por períodos de livro mais alocado, assim como bloqueio de
utilização de usuários com pendência de forma automática, esse item, não está
presente no sistema atual. Para contemplar tal lacuna, utiliza-se para o novo sistema

15
proposto, o desenvolvimento de técnicas de gestão de projetos, engenharia de
software, tal como boas práticas de desenvolvimento e análise de sistemas para
apresentar uma solução funcional.
Uma pesquisa feita por meio de um questionário com os alunos e funcionários
da biblioteca, foram levantados o grau de satisfação, a média de alocação de livros
por dia, e também o nível de inadimplência dos usuários, onde será mostrado abaixo
um gráfico com os resultados alcançados a partir da pesquisa. Com a visão de
gestão de projetos, como da engenharia de software aplicada a desenvolvimento de
sistemas, sendo o produto final direcionado a FATEC Tatuí, como a outras
instituições de ensino, sendo resultado da necessidade da instituição o
desenvolvimento deste projeto.
Abaixo, pela figura 1, observa-se, de forma destacada, qual o nível de
satisfação em porcentagem dos usuários do sistema, tanto internos (funcionários),
como externos (alunos), os quais interagem de forma direta e indireta com o
sistema, sendo o resultado de 80% de usuários parcialmente satisfeitos, os quais
necessitam de mais facilidade e agilidade no processo.
Figura 1 - Satisfação dos usuários da biblioteca
Fonte: Autoria própria
Pela figura 2, observa-se o número de livros alocados por período em média,
sendo os mesmos distribuídos com uma média de 80 alocações diárias, 2.000
mensais e cerca de 20.000 anuais.
20%
80%
Bom
Regular

16
Figura 2 - Média de alocação de livros na biblioteca da FATEC Tatuí
Devido ao número de alocações, os quais foram baseados em dias letivos, ou
seja, quando há alunos na instituição e a biblioteca está aberta, determina-se a
necessidade de um controle mais efetivo, tendo em vista que o nível de
inadimplência dos alunos é elevado em alguns cursos, conforme demonstra na
figura 3.
Figura 3 - Nível de inadimplência de entrega de livros
A atual aplicação utilizada na biblioteca da instituição é OPENSOURCE, e
com isso constam alguns problemas, tais como nos tópicos abaixo:
 Duplicidade de informação em algumas tabelas sem uma organização;
 Consultas restritas e sem otimização de query’s;
 Penalidades dos prazos de entrega.
 Falta de controles mais precisos em parte da gestão bibliotecária.
0
5000
10000
15000
20000
Diario
Mensal
Anual
80
2000
20000
Baseado em numero de livros
50%
Automoção
Industrial
30% Gestão
Empresarial
15% Gestão
em
Tecnologia
da
Informação
5% Outros
Cursos e suas inadimplências

17
 Gerenciamento com ausência de motores (triggers) para automatizar ações
no sistema e garantir uma maior segurança, tendo em vista que operações
realizadas diretamente na página podem sofrer alterações durante o processo
de gravação, caso o mesmo ocorra uma queda de conexão por parte do
usuário, tal como ausência de controle de transações, os quais evitariam
quase 100% esses erros, tanto por fatores externos, como externos.
Com base nos dados levantados por meios de pesquisas e entrevistas, sobre
as dificuldades e complexidades que envolvem o gerenciamento do atual sistema
bibliotecário da FATEC Tatuí, determina-se a seguinte questão: De que modo
desenvolver um software, que com eficiência possa auxiliar no gerenciamento da
gestão bibliotecária da FATEC Tatuí?
Visando uma melhoria na gestão bibliotecária da instituição, partindo da
análise de sistemas, e das confecções de documentações de engenharia de
software, para o fim de aprimorar e melhorar o atendimento, assim como o serviço
em visão de gerenciamento de uma melhor organização das informações que
alimentarão o sistema, sendo eles os cadastros, relatórios e consultas, que o
software disponibilizara com eficiência, eficácia, contemplando assim, precisão nos
dados e resultados. Contudo, maximizando os recursos, e acrescentando
melhorarias no controle e na integridade dos dados, o que facilitará a consulta dos
livros existentes ou não, para que possa ter um amplo melhoramento em questão do
uso do sistema em relação aos funcionários e alunos que necessitam da biblioteca e
com isso, o controle dos livros alocados.
O desenvolvimento de um sistema de gestão bibliotecário que contemple
todos os benefícios para se obter com eficiência e eficácia uma boa gestão
bibliotecária para a instituição FATEC Tatuí:
 Efetuando os levantamentos de requisitos por meios de pesquisas e
entrevistas, para se obter todas as reais necessidades a serem
contempladas;
 Cadastramentos dos livros, revistas, apostilas, alunos, funcionários, etc;
 Consultas aos itens disponíveis na biblioteca (livros, revistas, alunos, CD’S,
DVD’S, etc.);
 Relatórios de frequências de alocações, devoluções, e bloqueios, com
precisão nos prazos;

18
 Desenvolvimento do software em ambiente WEB, para melhor
compatibilidade em amplas plataformas (Windows, Linux, Mac), e aplicações
que disponibilizem interfaces dinâmicas, direcionado para aplicações em
ambientes desktops.
Um sistema para gestão bibliotecária que possa contemplar todos os recursos
necessários, contando com um alto controle de cadastramento de livros, com todos
os atributos necessários, também contará com o cadastramento de alunos, o
sistema irá criar um relatório de acompanhamento do aluno que venha a fazer uma
nova alocação, sabendo assim, quantos dias ele fará a devolução do livro, ou a
máxima alocação de livros existentes que ele poderá realizar.
Aplicando esses conceitos ao sistema, teremos a facilidade do uso e do
controle do software, para que os funcionários da biblioteca possam realizar com
segurança o controle dos livros, alunos e de todos aqueles que necessitarão do uso
da biblioteca para uso pessoal.
Sendo abordadas nesse projeto de sistema, várias técnicas como o
levantamento de requisitos feito por meios de entrevistas e pesquisas de campo, o
qual pode fornecer, um melhor detalhamento das reais necessidades encontradas,
e também com a utilização de orientação a objetos junto a programação para
podermos realizar todos os testes e assim, corrigir todos os erros e dificuldades
encontradas.

19
2 FASES DO PROJETO DO SISTEMA
Para início das fases de desenvolvimento do projeto, precisa-se compreender
o que é projeto, quais suas etapas, como também fazer um olhar das técnicas da
engenharia de software para encontrar a melhor solução no desenvolvimento do
software.
A definição proposta no PMBOK (PMI, 2004, p. 21), diz que "um projeto é um
esforço temporário empreendido para criar um produto, serviço ou resultado
exclusivo”.
Desta forma para que um projeto seja viável, precisará passar por todas fases
de analises e levantamento de dados, sendo o primeiro passo a criação do Termo
de abertura de projeto.
Segundo PMBOK (PMI, 2004, p.45), o termo de abertura de projetos é a
autorização do projeto, sob a qual constam as necessidades do projeto, as
quais serão levantadas durante sua documentação.
Com o termo de abertura definido, é necessário definir o Escopo do projeto,
contendo as “caixinhas de tarefas”, cada item, e qual será a pessoa responsável.
Nesse momento, também definimos premissas e restrições.
Conforme PMBOK (PMI, 2004, p. 43), tendo o escopo inicialmente é visto
como a delimitação de premissas, restrições, a organização de recursos
que as partes interessadas estão dispostas a investir, tal como no
refinamento adicional durante cada processo do projeto.
Sendo essa documentação descrita pelo PMI, o levantamento de requisitos
da engenharia de softwares, o projeto para o desenvolvimento de um sistema.
Dessa forma Sommerville define (2007, p. 79) os requisitos do software
como uma das características a qual é capaz de tornar possível atingir os
objetivos do sistema, sendo o processo demarcado pela análise,
documentação e verificação dos serviços necessários e suas propriedades,
sendo uma definição de requisitos mais precisa serviços os quais constaram
ou não no projeto.
Podendo os requisitos ser divididos em duas categorias essenciais:
Requisitos funcionais e não funcionais, dessa forma podendo identificar suas
necessidades na documentação do sistema.
Os quais define Sommerville, (2007, p. 80), como sendo: requisitos
funcionais como declarações de serviços que o sistema deverá fornecer, a
forma como devera se comportar ou não, assim como os itens que deveram
fazer parte do mesmo, por outro lado, os requisitos não funcionais são
essenciais para seu funcionamento, são restrições e exigências detectadas
pelo analista.

20
Havendo acontecido o processo de levantamento dos requisitos tanto
funcionais, e não funcionais, para construção da EAP (Estrutura Analítica de
Projetos), sob a qual apenas itens constantes nelas irão compor o projeto.
Conforme nota apenas itens que compõem as atividades previstas na EAP
fazem parte do projeto, pois toda e qualquer tarefa que não consta na EAP
está também fora do escopo, sendo o escopo as caixas de trabalho a ser
entregue no final do projeto (HELDMAN, 2005, p. 100).
Tendo em vista que a documentação é um item vital utilizado durante o
processo de desenvolvimento de softwares, sendo iniciada no momento do
levantamento de requisitos, contemplando alterações durante todo seu processo,
sendo ele a implementação e testes, sua implantação e revisões, até o produto final.
Sendo utilizado para o desenvolvimento convencionalmente o Modelo
espiral, o qual segundo Pressman (2006) faz a combinação da prototipação
com aspectos, tal como utilização de modelos sistemáticos de cascatas,
gerando dessa forma a possibilidade de desenvolvimento e analise de
novas versões de forma mais rápida do sistema, sendo o mesmo dividido
em um conjunto de atividades as quais orientam sua confecção.
A partir desse modelo, podemos fazer cada fase do projeto de forma eficiente
e eficaz, com menores possibilidades de falhas nos processos, entretanto devemos
saber identificar os requisitos da forma correta, fazendo seu levantamento de forma
consciente. Assim como todo projeto de desenvolvimento de sistema possui uma
dependência de identificação dos chamados casos de uso, sendo eles responsáveis
por identificar de uma forma geral o comportamento dos itens por parte do usuário.
Segundo Sommerville (2007), Objetivo dos casos de uso é orientar ao
programador as funcionalidades envolvidas no sistema, tal como os
usuários envolvidos e integrações com sistemas externos, sendo o maior
propósito do Caso de só fornecer uma descrição do comportamento pelo
ponto de vista do usuário, partindo-se de modelos de sistema orientados a
objetos gerando cenários para obter requisitos do sistema e descrever seus
modelos.
Outro item altamente relevante no processo é a identificação dos “atores do
sistema”, os quais sofrem ou não interações de acordo com seu nível de acesso ao
sistema e suas operações, partindo do caso de uso que possibilita identificar de uma
forma mais clara a interação dos atores do sistema.
Segundo Sommerville (2003), Atores são papéis de elementos externos ao
sistema e que interagem diretamente com o sistema. Um outro sistema que
interage com o sistema a ser desenvolvido também é considerado um ator,
desde que este sistema não faça parte do desenvolvido.

21
Desta forma os atores são itens importantes para identificação dos níveis de
acesso, qual pessoa pode acessar qual tipo de informação, fazer suas alterações,
quais os procedimentos para realizações de operações.
De acordo com Sommerville, (2003) os engenheiros de requisitos não
precisam se limitar aos modelos propostos em qualquer método de uma
forma especifica, entretanto esses modelos são uteis em algumas vezes
como parte do processo de análise dos objetos do sistema, pois refletem
em boa parte no entendimento do usuário final e como poderá isso
contribuir de forma direta com identificação de objetos com seus fluxos
aplicados a operações efetuadas no objeto. Modelos de sequência mostram
a interação entre objetos ao longo do tempo.
No diagrama de sequência, se encontram todos os fluxos de trocas de
mensagens através da primeira ação, desencadeia-se assim uma série de elementos,
os quais de acordo com os acontecimentos, geram consequências às quais podem
sofrer ou não alteração de acordo com a ação do ator. Com isso, gerando os
chamados caminhos alternativos, identificando os elementos que compõem a
estrutura básica de um software, sendo necessária a implementação de uma
linguagem a qual seja possível modelar as informações de tal forma que atinja a
proximidade com o projeto em questão, desta forma partindo-se do pré-suporto, sob
o qual a aplicação poderá ser acessada de múltiplas plataformas e sistemas
operacionais diferentes, de uma forma dinâmica na nuvem (Desenvolvimento WEB).
Segundo (NIXON, 2012) os benefícios do PHP, MYSQL, JavaScript e CSS,
permite uma migração da web 1.0 para a web 1.1, possuindo
compatibilidade com a web 2.0 sendo sites dinâmicos com resposta
cliente/servidor, podendo ter suas requisições baseadas em processos
AJAX, sendo essas requisições com resposta sem atualizar a página.
Dessa forma, o aplicativo poderá ter total compatibilidade com dispositivos
atuais (Multiplataforma), melhor interação com o cliente, além da total
compatibilidade com tecnologia cliente servidor, utilizando PHP junto a
JAVASCRIPT.
Hoje existem inúmeras tecnologias baseadas no JAVASCRIPT, uma das mais
utilizadas na atualidade, é a JQUERY, linguagem a qual aperfeiçoa os itens
primitivos e sua interação com os objetos da página, utilizando a chamada
programação orientada a objetos, entre as vantagens da linguagem, encontram-se
várias funcionalidades relacionadas à disponibilidade de conectores, dos mais
diversos bancos de dados, tal como suporte para diversos protocolos.

22
Existem inúmeras vantagens em utilizar o PHP, entre elas suporte para
inúmeros bancos de dados, entre eles MYSQL, Postgre SQl, Oracle, DB2,
tal como suporte a variáveis padrão e protocolos, como DOM, XML, IMAP,
POP3, LDAP, HTML, entre outros (ARROYO; SANTOS, 2002, p.1).
Com a possibilidade de geração de entrada em diversos bancos de dados
com pouca alteração na codificação, a linguagem PHP possibilita uma forma
eficiente e funcional para criação de tecnologias com suporte para rodar na nuvem,
pois todos os dispositivos atuais possuem compatibilidade em seus navegadores
(Browsers). Sendo assim, a utilização da chamada programação orientada a objetos
é fundamental, pois a mesma oferece uma maior flexibilidade, interação entre
objetos de diferentes tipos e formatos, assim como uma melhor visão e
aprimoramento de técnicas atuais.
Arroyo e Santos, (2006, p.4) definem a chamada POO (Programação
Orientada a Objetos), como uma técnica a qual modela processos de
programação efetuando tratamento de cada elemento, respeitando suas
características e tipos, aplicando suas funcionalidades, obtendo dessa
forma melhor desempenho, chegando a uma realidade aproximada.
Com a definição da linguagem desejada, o próximo passo será identificar a
melhor forma de armazenamento da informação, sendo esse um dos principais
elementos que compõem páginas dinâmicas com fins específicos. Sendo a função
do banco de dados, o armazenamento e gestão de consultas das informações.
Define-se um banco de dados como um conjunto de informações
"persistentes", com fim de utilização em sistemas de aplicação gerando
armazenamento e consulta posterior de dados de uma empresa, tendo seus
relacionamentos de informação sempre gerenciados de forma precisa
(DATE, 2004, p. 10).
Podendo utilizar-se de linguagens de banco de dados mais comuns e
funcionais, como SQL, linguagem a qual suporta trigger, procedures, entre outras
funções além de fazer o armazenamento da informação. Havendo compreendido
conceitos básicos de gestão de projetos, de engenharia de software e de sistemas, é
possível desenvolver um software funcional.

23
3 SOFTWARE E SEU DESENVOLVIMENTO
Software é um conjunto de arquivos executáveis (Binários), formados por
conjuntos de rotinas, os quais possuem uma base de dados (Bancos de Dados),
com a finalidade de agilizar a transformação de dados em informações que podem
ser interpretadas e utilizadas em seus fins. Como por exemplo, fornecer meios de
gerar relatórios de controle, efetuar a gestão do mesmo por meio de dados
registrados e processados, e com a possibilidade de armazenar informações com
mais segurança.
Embora existam milhares de softwares, com diferentes formatos e rotinas,
precisa-se visualizar qual a real necessidade de quem irá opera-lo, partindo então da
necessidade de possuir um software que forneça dados com precisão nos registros,
para controlar e gerenciar o acesso ao acervo de livros, o irá nos permitir realizar
cadastros, consultas e gerar relatórios com base nos dados fornecidos pelo usuário,
para isso precisa-se compreender e utilizar todos os conceitos da engenharia de
software.
3.1 ENGENHARIA DE SOFTWARE
“Engenharia de software é a criação e a utilização de sólidos princípios de
engenharia, a fim de obter softwares econômicos que sejam confiáveis e que
trabalhem de forma eficientemente em máquinas reais.” (PRESSMAN, 2006, p.17).
Desta forma, é possível compreender que é por meio do processo de
engenharia de requisitos, que é determinada a melhor solução, nos quais os itens
realmente relevantes e necessários se encontram, evitando desperdício de
processamento e de armazenamento.
3.2 DESENVOLVIMENTO DO SOFTWARE
O processo para alocação de um livro envolve toda uma dinâmica composta
por etapas, desde o atendimento, reconhecimento do perfil do aluno, tal como todo o
histórico de alocações e suas preferências atuais, tudo através de um relatório. E ao
processo de entrega de um livro, sendo necessários então registros dessas

24
informações, de forma segura, para assim equilibrar e obter melhores resultados. E
por meio desses registros que fornecerão de forma eficaz, o administrador do
sistema, tal como, os funcionários, irá ter uma maior percepção de quais opções
poderão apresentar ao aluno.

25
4 VISÃO GERAL DO SISTEMA
O sistema deverá gerenciar, desde cadastro dos livros, alunos, funcionários,
registros de alocações, consulta dos livros, revistas, e também realizará em questão,
a consulta da entrega de uma alocação já feita através de outro aluno. O software
também constará com uma restrição de acessos por níveis hierárquicos, desde as
funções de cadastro, alteração e exclusão. Isso levará a outro quesito a ser
ressaltado que é o módulo de segurança da informação, através de criptografia de
senhas, armazenamento de sua base de dados de forma criptografada, oferecendo
assim confiabilidade e a tão almejada portabilidade, por ser um sistema feito com
linguagem WEB.
Segundo (Sommerville, 2003) os requisitos funcionais do sistema são
inerentes ao sistema em si, ou seja, por meio de suas funcionalidades um
programa, deverá ter o processamento efetuado e uma saída deste mesmo
processamento. Sendo os requisitos não funcionais do sistema inerentes ao
sistema como um todo, tendo em vista uma interoperabilidade com
ferramentas e serviços externos que são necessários para o seu bom
funcionamento.
Partindo dos requisitos funcionais, os quais o usuário (operador) tem um
contato direto com o sistema, e possui seu conhecimento sobre o mesmo, podemos
identificar os requisitos funcionais como sendo cadastros, consultas, e relatórios. E
como os não funcionais as tecnologias que podem impedir invasões, e alterações
nos dados por usuário sem privilegio, como existências de logs de acesso, e a
escolha do formato do banco de dados com maior tolerância a falhas, à sua
atribuição a portabilidade pela plataforma escolhida para desenvolvimento.
4.1 REQUISITOS FUNCIONAIS DO SISTEMA
4.1.1 Cadastro de materiais
O cadastro de materiais terá as seguintes funções:
a) Armazenar um cadastro dos materiais ativos da biblioteca através de uma
chave primaria que será o número de código do material (ID);
b) O número do código do material deverá agregar os seguintes atributos: nome,
título, autor, editora, edição, ISBN, tombo, data da publicação, estado de

26
alocação, volume, data de alocação, data de devolução, descrição, código do
aluno que fez a locação, e chave do operador responsável pela locação;
c) Através do registro da chave primária denominada número de código do
material (ID), o sistema deverá disponibilizar os seguintes métodos: adicionar,
alterar, consultar e tornar ativo ou inativo, disponível ou alocado.
d) O sistema estará apto a tornar indisponível o material caso esteja alugado,
tornando-o inativo, e poderá estar excluindo o cadastro do material caso
esteja sem efetuar sua devolução a certo período de tempo denominado pelo
administrador do sistema, ou em caso de perda ou danos causados ao
material.
4.1.2 Cadastro de alunos
O cadastro de alunos terá as seguintes funções:
a) Armazenar um cadastro de alunos ativos da biblioteca através de uma chave
primaria que será o número de código do aluno (RA - Registro de Aluno);
b) O número do código do aluno deverá agregar os seguintes atributos: nome,
telefone fixo, telefone celular, data de nascimento, e-mail;
c) Através do registro da chave primária denominada número de código do
aluno (RA), o sistema deverá disponibilizar os seguintes métodos: adicionar,
alterar, consultar e tornar ativo ou inativo. E serão visualizadas na tela as
informações requeridas pelos métodos chamados;
d) O sistema estará apto a fechar um cadastro, tornando-o inativo caso esteja
sem efetuar alocação a certo período de tempo denominado pelo
administrador do sistema, e poderá ter a opção de exclusão caso o aluno
esteja retido da FATEC Tatuí.
4.1.3 Cadastro de operador
O cadastro de operador terá as seguintes funções:
a) Deverá armazenar um cadastro de operadores ativos da biblioteca através de
uma chave primaria que será o número da chave do operador, gerado quando
um novo operador for cadastrado no sistema;

27
b) Chave do operador deverá agregar os seguintes atributos: nome, data de
cadastro, e a chave do operador (PIN);
c) Através do registro da chave primária denominada número da chave do
operador, o sistema deverá disponibilizar os seguintes métodos: adicionar,
alterar, consultar, excluir. E serão visualizadas na tela as informações
requeridas pelos métodos chamados pelo usuário do sistema;
d) O sistema estará apto a excluir um cadastro de operador, tornando-o
indisponível caso não esteja mais em uso no sistema.
4.2 REQUISITOS NÃO FUNCIONAIS DO SISTEMA
4.2.1 Segurança e confiabilidade
A segurança engloba dois aspectos importantes:
a) O acesso ao sistema deverá ser mediante a entrada de senha,
impossibilitando. Possíveis pessoas curiosas efetuar o acesso ao aplicativo e
alterar dados, o mesmo deverá ser acessado por meio de um PIN-KEY para
evitar cancelamento de reservas e apagar registro de alocação, em caso de
um operador não possuir permissão para esse acesso;
b) O sistema deverá permitir uma cópia de segurança do banco de dados em
um sub-banco no qual será feito por meio de um robô (Tarefa Crom).
4.2.2 Tolerância a falhas
Existem duas importantes considerações com respeito à tolerância de erros:
a) No caso do sistema cair, por ausência da internet, ou a própria conectividade
do servidor oscilar, possíveis erros de gravação em sistemas convencionais
seria possível, mas todas as transações são controladas por transações SQL
em nosso sistema;
b) Para evitar perda de dados por erro humano nosso sistema gerará logs
(Arquivos de registros com histórico de informação), nos quais todas as
ações do sistema serão armazenadas.

28
4.2.3 Portabilidade
Existem duas importantes considerações com respeito à portabilidade:
a) O Software é desenvolvido em nuvem, plataforma a qual teve resultados de
desempenho e estabilidade comprovados em inúmeras plataformas
existentes no mercado, possibilidade de conexão com banco de dados
estáveis e seguros, os quais oferecem controles de transação, backup
simultâneo (em tempo real), utilizando-se de tecnologias como PHP e
MYSQL;
b) Oferecera uma interface limpa e amigável, reduzindo a necessidade de longas
horas de treinamentos.
4.2.4 Hardware
No que abrange os requisitos mínimos de hardware:
a) A base de desenvolvimento considerara como requisito mínimo do hardware
para a utilização do software no back-end do sistema (Servidor WEB /
Servidor de Dados): processador com 2.3 Ghz, 2 GB de memória RAM, 500
GB de armazenamento em disco;
b) Os requisitos do usuário final são apenas um dispositivo, não existem
requisitos definidos, apenas precisa rodar Windows, Linux ou Android
(Preferencial Tablet).
4.2.5 Software
No que abrange os requisitos mínimos de software:
a) Servidor WEB Linux (Cents OS ou Debian), com Apache2, instanciado com
o PHP5 + MYSQL Server;
b) Os requisitos de software são um sistema operacional atualizado, sendo ele
WINDOWS (A partir de XP), Linux (Ubuntu, Debian, etc.), Android (2.3 ou
superior, preferencial em Tablet), instalado um navegador atualizado
(Preferencial Internet Explorer 10 ou Google Chrome versão (Compilação)
32 ou superior ou Firefox versão (Compilação) 23 ou superior) para um
melhor desempenho.

29
5 VISÃO DE CASO DE USO
5.1 CONCEITO DE CASO DE USO
Segundo (Sommerville, 2007), Objetivo dos casos de uso é orientar ao
programador as funcionalidades envolvidas no sistema, tal como os usuários
envolvidos e integrações com sistemas externos, sendo o maior propósito do Caso
de só fornecer uma descrição do comportamento pelo ponto de vista do usuário,
partindo-se de modelos de sistema orientados a objetos gerando cenários para obter
requisitos do sistema e descrever seus modelos.
5.2 OPERAÇÃO DO SISTEMA
O aluno que necessita da locação de um livro, o qual o livro lhe fornecera
conhecimento e/ou esclarecimento de dúvidas. Este aluno então procura o livro na
biblioteca FATEC Tatuí, e caso consiga com eficiência encontrar o livro de seu
desejo, para que em seguida possa efetuar sua locação. E para efetuar a locação,
será preenchido os dados do aluno, junto as informações do livro, o qual será
gerado um perfil de aluno, que por meios dele estará automaticamente cadastrando
todas as suas movimentações de alocações, desde os livros mais alocados, datas
em que foram alocados e seus status de pendências com a biblioteca.
5.3 DEFINIÇÃO DE ATORES
Segundo (Sommerville, 2003), atores são papéis de elementos externos ao
sistema e que interagem diretamente com o sistema. Outro sistema que interage
com o sistema a ser desenvolvido também é considerado um ator, desde que este
sistema não faça parte do desenvolvido. Ator é aquele presente no modelo de usos
de casos que de alguma forma interage como elemento no sistema, disparando
determinada ação. São pessoas ou outros subsistemas, que fazem parte do mesmo
ou não.
a) Ator operador: é aquele que irá efetuar o cadastro dos livros, alunos, e as
operações de alocações e devoluções.
b) Ator aluno: é aquele que irá executar a locação e devolução de um livro.

30
5.4 TABELA DE CASOS DE USO
As tabelas de caso de uso fornecem uma referência e explicam as ações
representadas por cada terminologia verbal pelo ator como podemos ver na tabela
abaixo;
Tabela 1: Casos de uso – Ator operador
Nº
ord.
Caso de Uso Descrição
01 adicionarOpe Método que inclui as informações na classe operador no BD.
02 alterarOpe Método que modifica as informações na classe operador no
BD.
03 consultarOpe Método que consulta o registro na classe operador no BD.
04 inativarOpe Método que altera o status na classe operador no BD.
Abaixo vemos a tabela de casos de usos do ator aluno, os quais nos mostram
as ações representadas;
Tabela 2: Casos de uso – Ator aluno
Nº
ord.
Caso de Uso Descrição
01 adicionarAlu Método que inclui as informações na classe aluno no BD.
02 alterarAlu Método que modifica as informações na classe aluno no BD.
03 consultarAlu Método que consulta o registro na classe aluno no BD.
04 InativarAlu Método que altera o status na classe aluno no BD.
5.4.1 Modelos de casos de uso
Os modelos de Casos de Uso propõem uma visualização gráfica das ações
que são executadas pelos atores envolvidos no processo. O gerenciamento das
ações apresentara os seguintes atores nas figuras abaixo;

31
Figura 4 - Modelo de casos de uso ator operador
Abaixo vemos a figura do modelo de casos de uso do ator aluno que contará
com as seguintes ações de gerenciamento.
Figura 5 - Modelo de casos de uso ator aluno

32
6 MODELOS DE SEQUÊNCIA
Segundo (Sommerville, 2003) os engenheiros de requisitos não precisam se
limitar aos modelos propostos em qualquer método de uma forma especifica,
entretanto esses modelos podem ser uteis em algumas vezes como parte do
processo de análise dos objetos do sistema, pois refletem em boa parte no
entendimento do usuário final e como poderá isso contribuir de forma direta com
identificação de objetos com seus fluxos aplicados a operações efetuadas no objeto.
Modelos de sequência mostram a interação entre objetos ao longo do tempo.
No diagrama de sequência se encontram todos os fluxos de trocas de
mensagens através da primeira ação, então assim desencadeia-se uma série de
elementos os quais de acordo com os acontecimentos, geram consequências às
quais podem sofrer ou não alterações de acordo com cada ação do ator, isso
gerando os chamados caminhos alternativos.
Denominando-se curso normal o primeiro tipo de rota que a ação gerada
pelos atores até o final do curso, assim como curso alternativo, caso o ator sofra
algum tipo de interferência de uma condição imposta, podendo existir inúmeros
caminhos alternativos nesse sistema.
6.1 DIAGRAMAS DE SEQUÊNCIA
a) O diagrama de sequência de alocação pode ser visto na figura a seguir:

33
Figura 6 - Diagrama de sequência de alocação
Curso normal:
1) O aluno consulta livros disponíveis;
2) O operador informa as melhores opções;
2.1) O aluno escolhe o livro;
2.2) O operador solicita os dados do aluno para realizar a locação;
2.3) O aluno informa os dados ao operador;
2.3.1) Efetua cadastro caso o aluno não seja cadastrado;
2.3.2) O sistema informa o cadastro efetuado com sucesso;
3) O operador efetua a entrega do livro e do período de locação;
Curso Alternativo
2.2) O operador solicita os dados do aluno para cadastro;
2.3) O aluno informa os dados ao operador para realizar o cadastro;
2.3.1) O vendedor verifica o cadastro do aluno, caso o aluno não seja
cadastrado;
2.3.2) O sistema informa o retorna que aluno já é cadastrado;

34
7 VISÃO LÓGICA – NÍVEL DE ANALISE
É de suma importância no processo de uma confecção de um software
construir uma visão lógica e com relacionamentos voltados para as regras de
negócios, estimulando assim de uma forma clara e objetiva, de encontrar falhas, e
poder realizar melhorias, assim aprimorando a modelagem da aplicação logo em seu
processo inicial, identificando seus processos no ambiente de utilização do aplicativo
ou sistema.
Partindo por outro meio de modelagem, o diagrama de classes incluem
detalhes, com as devidas melhorias agregadas e relacionadas a cada objeto do
sistema, de uma forma em que a classe disposta no diagrama seja em formas de
retângulos, divididas em três linhas, sendo seu nome, seus atributos
(características), tal como seus métodos aplicados (funções incluir, remover, alterar,
entre outros). Reafirmando sua funcionalidade no processo, o autor Sommerville
(2003), identifica os objetos dos sistemas, e suas relações entre si como uma das
áreas mais difícil de analisar no projeto e na sua orientação a objetos.
7.1 RELACIONAMENTOS PRINCIPAIS ENTRE AS CLASSES
 Agregação – Relacionamentos estruturados na visão de regras de negócios,
determinadas como cada classe pode afetar o fluxo em um sistema, sem
haver a necessidade de outro.
 Herança – Relacionamento dos objetos os quais possuem características
comuns de uns herdarem características de outros, (Ex.: classe filha herda da
classe pai).
 Dependência – Relacionamento em que um objeto depende de outro para
sua existência, quando o objeto principal é alterado, seu dependente recebe
automaticamente a alteração. Em muitos casos ela deixa de ser utilizada,
utilizando-se um atributo ou método de outra classe para a mesma função.
 Agregação - Relacionamento que define que uma classe deverá ter um valor
somente se não interagir sozinha, mas unicamente junto a outra classe. Pois
quando uma classe não possui função sozinha essa classe, portanto deve ser
agregada a outra.

35
 Composição – Relacionamento em que certas classes apenas existem com a
finalidade de verificar existências de outras classes que compõem o mesmo
objeto, ao de destruir uma classe, a classe composta será destruída junto à
outra classe.
7.2 DIAGRAMA DE CLASSES DO PROJETO
O Diagrama de Classes de Projeto é o resultado de um refinamento do
Diagrama de Classes de Análise. O qual e usado para:
 Adicionar métodos;
 Criação de atributos;
 Adição da direção das associações;
 Possível detalhamento dos atributos e associações;
 Alteração na estrutura das classes e associações;
Como pode ser vista na figura a seguir:

36
Figura 7 - Diagrama de classes de projeto

37
7.3 SÍMBOLOS DOS RELACIONAMENTOS ENTRE AS CLASSES
Pode ser vista logo abaixo a figura sobre simbologia dos relacionamentos entre as
classes.
Figura 8 - Simbologia dos relacionamentos entre as classes
Fonte: MACORATTI, 2004.

38
8 DIAGRAMAS DE ENTIDADE E RELACIONAMENTO
Os diagramas de entidade e relacionamentos (denominados como “DER”)
possuem como finalidade poder visualizar as tabelas (“Entidades”), com seus
atributos (“Campos”) e suas possíveis ligações entre si (“relacionamentos”), já
predefinidos com suas funções dentro do sistema na estrutura do banco de dados.
Segundo Alves (2009), utilizamo-se as seguintes terminologias e representações
para a construção de um diagrama de entidade e relacionamento, seguindo a
simbologia mostrada na figura a seguir:
Figura 9 - Simbologia e terminologia do DER
Fonte: Fred R. McFadden, 1999
8.1 RELACIONAMENTOS ENTRE ENTIDADES
Os relacionamentos entre as entidades, as quais todas possuem atributos
próprios sendo eles armazenados no banco de dados, podemos identificar alguns
tipos de entradas possíveis. Partindo do princípio em que as entidades são
compostas por campos de chave candidata primaria, candidata secundaria, ou
campo comum, o qual não exige uma integridade. Sendo assim, podemos encontrar
diversos tipos de relacionamentos, entre eles 1 para 1, representado (“1..1”), por
meio do qual um item pode ser acessado por apenas um único usuário, ex.: Uma
empresa pode ter apenas um diretor, relacionamento 1 para muitos, representado
(“1..N”), através do mesmo, uma empresa poderá ter muitos operadores. Existindo
mais duas outras formas de representar esses relacionamentos, sendo 1 ou muitos

39
para 1 ou muitos, representado (“1..N para 1...N”), tendo em vista que um atendente
pode atender a muitos clientes, tal como muitos atendentes podem atender a um
cliente, da mesma forma, existindo o relacionamento muitos para muitos,
representado (“N..M”), o qual muitos itens, estão relacionados a outros itens, este
tipo de relacionamento não é muito utilizado, um exemplo disto pode ser vista na
figura abaixo no diagrama entidade e relacionamento.

40
Figura 10 - Diagrama de entidade relacionamento (DER)

41
9 VISÃO GERENCIAL: GERENCIAMENTO DE PROJETO
O Planejamento do programa é essencial, embora em muitos casos seja
esquecido. Havendo inúmeros casos em que programas com pouca programação,
estruturas de decisão, recebem custos altos ao serem revendidas as empresas, tais
como em muitos casos realizam os testes de suas aplicações finais em seu cliente,
ao invés de fazê-los no momento de seu desenvolvimento. Para que seja possivel
obter um bom aproveitamento do processo, através de um planejamento efetivo e
funcional, utiliza-se as chamadas métricas de software, desta forma obtendo valor
justo, real visão da cobertura das funcionalidades do software, como uma real
dimensão da qualidade do projeto como um todo.
Assim como Pressman (1995), define essas métricas, como sendo resultados
da contagem de linhas dos códigos (LOC), velocidade de processamento do
programa, espaço de armazenamento na memória, assim como os BUGs (falhas de
execução / erros) em um determinado período durante seu desenvolvimento, nessas
métricas obtemos então, a qualidade, complexidade, eficiência, facilidade de uso,
confiabilidade e grau de manutenção desse software ao final de seu
desenvolvimento.
Segundo Sommerville (2003), mas medições de software resultam em atrasos
no desenvolvimento do software, por outro lado são necessárias para assim
assegurar um mínimo de qualidade, assim como reduzir o número de erro no
desenvolvimento de um projeto. Em suma as métricas são responsáveis por nos
fornece orientações sobre como será o projeto de uma forma mais precisa, como
uma maior profundidade.
9.1 MÉTRICAS DE SOFTWARE
Ao abordarmos aspectos de medição de software poderemos fazê-los pela
medição de sua produtividade, utilizando linhas de código (LOC), embora existam
projetos curtos e funcionais por outro lado outro grande e não tão bem elaborados,
assim como com menor funcionalidade. Outra forma podendo ser também aplicada
é o ponto de função, através do qual segundo (ALBRETCHT, 1979) “A medição
deveria avaliar através do PF (pontos por função), a produtividade através de cinco
aspectos, sendo eles: número de entradas do usuário, números de saídas do

42
usuário, números de consultas do usuário, número de arquivos do usuário, número
de interface externas. Através da métrica de pontos de função, reduzimos custos
altos para aplicações com códigos grandes, porem pouco funcionais. ” Ao
observarmos essas métricas de software obtemos uma melhor mensuração através
dos pontos de função, em um modelo em que as melhorias são possíveis e
comprovadas, sendo suas respectivas denominações pelas siglas ALI, AIE, EE, CE
e SE.
9.2 PONTOS POR FUNÇÃO
9.2.1 Arquivos lógicos internos
Os Arquivos Lógicos Internos são dados que são fornecidos como controle,
presentes na aplicação e identificados pelo usuário. Sua função é de armazenar
dados obtidos na execução de um processo em uma aplicação. Sendo assim os
Dados Elementares Referenciados (DER), consiste em um campo único,
reconhecido pelo usuário, assim como o Registro Lógico Referenciado (RLR), como
um subgrupo de dados reconhecido pelo usuário dentro do ALI ou em um AIE.
Tanto a contagem de complexidade dos ALI, como dos AIE, serão definidas pela
seguinte tabela:
Tabela 3: Cálculo de complexidade ALI e AIE
Fonte: FABRI, 2005, p. 48.
Como referência do projeto de desenvolvimento de controle temos as
seguintes tabelas de ALI representadas. Vemos a tabela com o controle do aluno
com a seguinte tabela de ALI abaixo;

43
Tabela 4: Exemplo de arquivos lógicos interno aluno
cadastro_alunos
Campo Tamanho Formato
IdAlunos 11 Int
RAAluno 20 Alfanumérico
NomeAlunos 20 Alfanumérico
Status 1 Alfanumérico
DER 4 RLR 3 Complexidade: SIMPLES
Agora vemos o controle do operador com a seguinte tabela de ALI abaixo;
Tabela 5: Exemplo de arquivos lógicos interno operador
Operador
Nome 255 Alfanumérico
DataCadastro 8 Data
ChaveOperadorPIN 11 Inteiro
Em seguida também veremos o controle de operação da alocação com a
seguinte tabela de ALI abaixo:
Tabela 6: Exemplo de Arquivos lógicos interno alocação
aluguel_operacao
IdOperacao 11 Inteiro
RAaluno 20 Alfanumérico
DataOperacao 8 Data
ChaveoperadorPIN 11 Inteiro
ChaveSegurançaOperacao 9 Alfanumerico

44
Em seguida também veremos o controle de alocação de itens com a seguinte
tabela de ALI abaixo:
Tabela 7: Exemplo de arquivos lógicos interno alocação
aluguel_operacao_itens
Id 11 Inteiro
IdMaterial 11 Inteiro
n_tombo 255 Alfanumérico
StatusDevolucao 255 Alfanumérico
DataRetitrada 8 Data
DataDevolucaoPrev 8 Data
DataDevolocao 8 Data
MultaDevolucao 6 Double
AplicarMulta 1 Alfanumérico
ItemTipo 11 Inteiro
Podemos ver a seguir o controle do livro com a seguinte tabela de ALI abaixo:
Tabela 8: Exemplo de arquivos lógicos interno material
Material
IdMaterial 11 Inteiro
NomeMaterial 255 Alfanumérico
Titulo 255 Alfanumérico
Autor 255 Alfanumérico
Editora 255 Alfanumérico
Ano 8 Data

45
Edicao 255 Alfanumérico
Volume 255 Alfanumérico
DescricaoMaterial 255 Alfanumérico
ISBN 255 Alfanumérico
ISSN 255 Alfanumérico
Classificacao 255 Alfanumérico
CodeMaterial 10 Alfanumérico
Disponivel 1 Alfanumérico
DataInclusao 8 Data
UsuarioAceite 11 Inteiro
DER 16 RLR 5 Complexidade: Médio
9.2.2 Arquivos interface externa (AIE)
Os chamados arquivos de interface externa são dados que são informados
logicamente relacionados e estão presentes fora da fronteira da aplicação, como
podemos visualizar um exemplo na tabela abaixo:
Tabela 9: Exemplo de Arquivos de interface externa de aluno atendido
aluno_atendido_operador
DataOperacao 8 Data
ChaveSegurancaOperacao 255 Alfanumérico

46
Tabela 10: Exemplo de AIE de materiais cadastrados
Material_cadastrado_por_operador
NomeMaterial 225 Alfanumerico
Autor 225 Alfanumerico
Editora 225 Alfanumerico
Ano 4 Alfanumerico
Edição 225 Alfanumerico
Volume 45 Alfanumerico
DescricaoMaterial 225 Alfanumerico
ISBN 19 Alfanumerico
ISSN 13 Alfanumerico
Classificacao 25 Alfanumerico
DataInclusao 10 Data
Tabela 11: Exemplo de Arquivos de interface externa de curso cadastrado
curso_cadastrado_por_operador
IdCurso 11 Inteiro
NomeCurso 225 Alfanumerico

47
9.2.3 Entradas externas (EE)
As chamadas entradas externas se referem às telas de interface do
programa, nas quais o usuário iria efetuar entrada de dados, tal como efetuar suas
consultas sobre os dados armazenados no mesmo. Para obtermos os valores das
entradas externas, efetua-se o cálculo de sua complexidade.
Tabela 12: Cálculo de complexidade de ALR
Fonte: Adaptado de FABRI, 2005, p. 73
Abaixo veremos algumas figuras das telas que o software de gestão da
biblioteca irá receber, e a representação de cada ação que elas irão possuir, vemos
abaixo a figura da tela de cadastro de materiais que contará com o ID do Material,
sendo um campo não visível ao usuário, assim como os dados referentes aos livros:
Figura 11 - Exemplo de tela de cadastro de Materiais
DER 17 ALR 1 Complexidade: SIMPLES

48
A seguir veremos a figura da tela de cadastro de curso que contará com a
Chave IdCurso, a qual será associado será chave para relação entre disciplina e
material.
Figura 12 - Exemplo de tela de cadastro Cursos
9.2.4 Consultas externas (CE)
As consultas externas são baseadas em qualquer operação de consulta do
sistema a fim de obter resultados sobre dados cadastrados pelo usuário do sistema.
Em um sistema dinâmico baseado no padrão CRUD (Inclusão, Relação/Consulta,
Alteração e Exclusão na mesma Tela), podemos contemplar de uma consulta na
mesma tela de cadastro, como em nosso próximo exemplo na figura a seguir a qual
nos permite fazer a relação de quais materiais estão associados às quais disciplinas.

49
Figura 13 - Exemplo de tela de associação de cursos, materiais e disciplinas
No exemplo anterior é utilizada uma consulta para localizar qual matéria vai
ser o associado a qual disciplina e a qual curso.
9.2.5 Saídas externas (SE)
As saídas externas são as responsáveis para geração de relatórios do
sistema, emissões gráficas geradas para impressão. Como se encontra abaixo a
figura do relatório responsável pela visualização de alunos que estão com alugueis
pendentes, os quais terão suas carteirinhas suspensas, e/ou já foram suspensas.

50
Figura 14 - Exemplo de tela de relatórios de pendencias de livros
Destaca-se que é de suma importância durante o desenvolvimento da
documentação fazer análise de impacto para cada item colocado e retirado, tanto de
relatórios, para evitar erros ou duplicidade de informações.

51
10 PLANEJAMENTO POR DECOMPOSIÇÃO
10.1 TABELA DE CONTAGEM
A seguinte tabela expressa a contagem da complexidade funcional dos itens
analisados apresentados no capítulo anterior, baseando-se em um exemplo parcial
do sistema, sendo o intuito ilustrar os passos.
Tabela 13: Exemplo de tabela de cálculo de pontos por função
Componentes
Lógicos
Complexidade
Funcionários
Total
Complexidade
Total Tipo
Complexidade
ALI 4__ SIMPLES
1__ MÉDIA
_ __ COMPLEXA
X7 28_
X10 10_
X15 ___
38_
AIE __3_ SIMPLES
____ MÉDIA
____ COMPLEXA
X6 18_
X7 ___
X10 ___
_18_
EE __2_ SIMPLES
____ MÉDIA
____ COMPLEXA
X3 _6_
X4 ___
X6 ___
_6_
CE __1_ SIMPLES
____ MÉDIA
____ COMPLEXA
X4 4_
X5 ___
X7 ___
_4_
SE __1_ SIMPLES
____ MÉDIA
____ COMPLEXA
X3 3_
X4 ___
X6 ___
__3_
Total de Pontos 79
Fonte: Adaptado de FABRI, 2005, p. 94
10.2 QUESTÕES DE AVALIAÇÃO DE COMPLEXIDADE DE SOFTWARE
“Ao analisar a complexidade de um software podemos utilizar uma métrica de
software, que poderá ser utilizada com qualquer tipo de medição, mas que esteja
ligado a um sistema de software, documentação ou até mesmo um processo
relacionado” (Sommerville, 2003). Inclui-se então um questionário relativo a
complexidade da aplicação segundo as métricas de software. Compostas por 14
questões analisando os principais requisitos a ter sua funcionalidade atingida, de
acordo com seu grau de complexidade, desde necessidades a adicionais oferecidos,
como pode ser vista na seguinte figura abaixo;

52
Figura 15 - Complexidade relativa às perguntas
Fonte: ALVES (2009, p.3 apud (ou citado por) BARROS, 2012, p. 46).
Abaixo vemos a tabela de perguntas compostas por 14 questões analisando
os principais requisitos a ter sua funcionalidade atingida;
Tabela 14: Exemplo de tabela de perguntas com os principais requisitos
Nº Questão Pontos
1 - O sistema exige backup e recuperação de dados? 0
2 - É requerida comunicação de dados? 0
3 - Existem funções de processamento distribuído? 0
4 - O desempenho é crítico? 0
5 - O sistema funcionará num sistema operacional existente e
Intensamente utilizado?
0
6 - São requeridas entrada de dados on-line? 3
7 - As entradas on-line requerem que as transações de entrada
sejam construídas com várias telas e operações?
1
8 - Os arquivos são atualizados on-line? 5
9 - Entradas, saídas, arquivos e consultas são complexos? 0
10 - O processamento interno é complexo? 0
11 - O código é projetado para ser reusável? 0
12 - A conversão e a instalação estão incluídas no projeto? 0
13 - O sistema é projetado para múltiplas instalações em diferentes
organizações?
0
14 - A aplicação é projetada de forma a facilitar e o uso pelo usuário? 1
Total de pontos no questionário: 10
Fonte: MOREIRA, 2010.
10.3 CÁLCULO DO FATOR DE AJUSTE
O cálculo de fator de ajuste possui o objetivo de transformar os pontos de
função bruto (PF) em pontos de função líquido, pelo qual se obtém uma pontuação
com intuito de interagir com as próximas equações as quais determinaram a
qualidade da documentação do software, tal como o seu custo final. Equação para
se obter os pontos líquidos como pode ser vista na figura abaixo:

53
Figura 16 - Figura da com o cálculo de fator de ajuste
Fonte: FABRI, 2005, p. 99
Sendo:
 PFL é o que se pretende encontrar, os pontos por função líquidos;
 PFB são os pontos por função brutos obtidos da tabela de contagem;
 Fi é a soma dos valores de ajustes da complexidade;
Partindo desses pontos, chega-se a seguinte resolução:
PFL = 79 * [0,65 + 0,01 * (10)] = PFL = 59,25
O projeto apontou aproximadamente 59,25 pontos por função liquido.
10.4 PRODUTIVIDADE, QUALIDADE, PREÇO E DOCUMENTAÇÃO
Após encontrar os pontos de funções líquidos, através do ajuste dos pontos
de função brutos, possuímos quatro fatores principais a ser analisado no que
concerne ao aspecto do software, apesar dos números apresentados possuírem
certo teor subjetivo, através dos mesmos obtemos esses dados para os documentos
de requisitos vista na seguinte tabela:

54
Tabela 15: Exemplo de tabela de cálculos das pontuações finais
Produtividade
Produtividade
= PFL 85,5 /
2 pessoas
Produtividade
42,75
Qualidade
Qualidade
Erros 8 /
85,5 PFL
Qualidade
0,90
Custo
Custo
$ 4.200,00 /
85,5 PFL
Custo
49,12
Documentação
Documentação
45 Páginas /
85,5 PFL
Documentação
0,52

55
11 VISÃO SOBRE DISTRIBUIÇÃO E IMPLEMENTAÇÃO (DEPLOYMENT)
A visão de distribuição e implementação precisa ser considerada, desde
avaliação do hardware e a relação dos dispositivos interligados para implantação do
sistema. Por se tratar de uma aplicação Clouding Computer (WEB), descreveremos
os dispositivos locais que estarão interligados a rede representada na seguinte
tabela abaixo;
Tabela 16: Exemplo de tabela de visão sobre distribuição do desktop
Visão Geral Desktop
Hardware
Desktop CPU 2.3 GHz, 3 GB RAM, 320 GB de disco
Link Dados 2 Mbps ADSL
Modem Modem Speed Touch Thomson St-510 V6 Adsl
Firewall Firewall Asa 5505 Cisco
Impressora Impressora Laser Samsung Mono Ml2165
Software
Sistema Operacional Windows 8 Pro
Navegadores IE 10 (MSIE) - Chrome / FireFox (WebKit)
A seguir veremos a figura representada pela estrutura da tabela de visão
sobre a distribuição do desktop:
Figura 17 - Exemplo de visão de distribuição desktop
Abaixo veremos a tabela da visão de aplicações Web (SERVIDOR).

56
Tabela 17: Tabela de exemplo da visão aplicação Web (servidor)
Visão Geral Desktop
Hardware
Arquitetura Processador Intel Xeon Quad-Core E5606, 2.13 GHz
Modelo Servidor HP DL160 G6 (PN 641354-205)
Memória RAM 4GB de memória RAM
Armazenamento HD de 500 GB SATA III, Controladora Smart Array
P410 (Raid 0 e 1), Rack 1U
Software
Sistema Operacional Red Hat Enterprise
Gerenciador Cpanel X
Servidor Web Apache 2.2 (PHP 5 + MYSQL 3.2)
Abaixo observa-se a figura da aplicação WEB (servidor);
Figura 18 - Exemplo de visão de aplicação Web (servidor)

57
12 CRONOGRAMA
O cronograma estabelecido para estipular o rascunho do projeto até sua fase
de implantação final, utilizando do modelo de Gantt para representar os passos
concluídos e ainda em andamento, assim como os próximos a serem executados, as
barras azuis informam as fases concluídas, assim como as vermelhas as que ainda
serão executas ou estão sendo executadas. A seguir ilustraremos um modelo de
como deve ser desenvolvido o gráfico do cronograma, sendo esse um item
fundamental no processo de desenvolvimento de sistemas.
Figura 19 - Exemplo de modelo de gráfico (Gantt)

58
13 BANCO DE DADOS DO SISTEMA
13.1 INTRODUÇÃO A BANCO DE DADOS E SUAS REGRAS
O primeiro item o qual é necessário desenvolver é o banco de dados do
sistema, baseando-se na análise dos dados, em conjunto a estrutura básica a
aplicação, com adaptações e melhorias, na confecção do processo. Para isso
iremos entender os princípios básicos e a utilização de sua linguagem.
A definição de um banco de dados consistente, de linguagem de fácil
manipulação, a qual forneça estabilidade, segurança e integridade da informação,
sendo de suma importância no desenvolvimento de nosso sistema, tendo em vista
que o mesmo poderia seguir diversos tipos e formatos, os quais cada um possui
uma característica particular o qual vislumbra para cada tipo de requisito em
determinado estabelecimento, sendo para empresas de baixa demanda, tal como de
alta.
Segundo (Centro de Computação Unicamp, 2001, p. 2), Banco de dados é
uma coleção de dados inter-relacionados, representando informações sobre
um domínio específico [...] Sendo O Objetivo principal de um sistema de
banco de dados é possibilitar um ambiente que seja adequado e eficiente
para uso na recuperação e armazenamento de informações.
Sendo assim, o banco de dados seria um armazém de informações
indexadas, com um fim único, sendo ele armazenar, consultar, atualizar e remover
registros de dados baseados em índices e padrões de integridade da informação.
Segundo DATE (2003, p.6) define-se o banco de dados como sendo um
sistema automatizado cuja finalidade seria o armazenamento de
informações com a possibilidade de o usuário buscar, atualizar as
informações dentro de suas necessidades [...] Sendo esse processo
gerenciado pelo computador, nos chamados sistemas gerenciadores de
banco de dados, assim como gerados pelas linguagens de banco de dados,
como SQL.
Ou seja, esses dados coletados e catalogados possui um fim comum,
relacionados por índices de metadados e dados, sendo esse processo realizado por
gerenciadores de banco de dados e suas ações por meio de linguagens de banco de
dados. Outro benefício da utilização de banco de dados seria a questão de não ter
perdas caso a estrutura do mesmo receba novos campos, com relação a
funcionalidade da aplicação já existente, até sua atualização.
Segundo (MATTASO, 2007, p. 11) Os dados armazenados no banco de
dados são descritos pelos metadados, com finalidade de gerenciar as
informações nos SGBD (Sistemas gerenciadores de banco de Dados),
Sendo as informações a ele adicionadas, assim como novos campos,
independentes não afetando dessa forma a estrutura do sistema.

59
Assim sendo os bancos de dados atuais, diferentes dos antigos, chamados de
Arquivos de Dados, os quais apenas faziam alocação por separadores, sem índices
e metadados, consegue aperfeiçoar o processo de consultas e adição, remoção de
registros, tal como garantir uma maior integridade da informação, dessa forma
eliminando duplicidade de informação ou dados inconsistentes durante a sua
execução, graças a controles de transações, tal como a existências de gatilhos
(Triggers), responsáveis por fazer ações durante execução de algum tipo de
atividade em determinada tabela, fazendo assim alterações, em eventos tais como
Inserir, Remover, Atualizar.
Sendo os principais elementos que constitui os SGBD as Tabelas (TABLES),
Visões (VIEWS) e os INDICES (INDEX), sendo eles Chaves, CHAVE CANDIDATA
PRIMARIA / PRIMARY (PRYMARY KEY), CHAVE CANDIDATA SECUNDARIA
(FOREIGN KEY) e CHAVE ÚNICA (UNIQUE KEY), sendo que a CANDIDATA
SECUNDARIA gera a chamada Integridade de referenciais.
Segundo (SANCHES, 2005) “O valor armazenado em um atributo ou mais
atributos de um registro deve ser único em relação a todos os registros da
tabela. Este é o conceito de chave primária. Devemos portanto definir quais
registros irão compor a chave primária, sendo que cada tabela possui uma
única chave primária. Quando se define um atributo como chave primaria,
fica implícito as cláusulas UNIQUE e NOT NULL para este atributo, não
sendo necessário a especificação destas.”
Por meio das chaves primarias possuímos modelos (Índices) nos quais
devem ser baseadas a entradas em tabelas primárias, como em um cadastro de
livros, deve possuir uma Chave Candidata Primaria para os Gêneros de Livros, e
uma Chave Candidata Secundaria na tabela dos livros relacionando a elas. Dessa
forma apenas valores que constam na tabela de Gêneros poderão constar no
cadastro de livros, assim garantindo integridade e prevenindo erros de entradas
invalidas no cadastro e podendo até mesmo ocasionar erros no sistema.
Segundo (SANCHES, 2005) Sendo o DOMINIO (Tipo do dado) o formato o
qual vai ser definido para as entradas, podendo ser de números inteiros,
decimais, money (para moedas), podendo ser atribuídos como decimal, float
ou numeric, Data, DATATIME, Binary (para armazenamento de arquivos ou
elementos especiais), podendo esse domínio ter restrições durante seu
preenchimento com um CHECK (Confirmação), para que o valor de um
atributo fique atrelado a um conjunto de valores a ele atribuído, assim como
a definição de um valor padrão, caso o mesmo não seja preenchido, para
campos que não aceitam valor vazio.
Havendo sido definido os domínios a integridade da informação é garantida,
evitando falhas de cadastro, dados em duplicidade, assim como erros por campos
necessários não preenchidos.

60
Cadastro de Alunos em SQLite
CREATE TABLE Cadastro_Alunos (
IdAlunos INTEGER PRIMARY KEY AUTOINCREMENT,
RAAluno INTEGER UNIQUE,
NomeAlunos VARCHAR,
Status CHAR
);
Existem diversos tipos de SGBD no mercado, os quais se utilizam de diversas
linguagens e padrões, alguns mais robustos, com suporte a mais registros com
garantida de integridade, outros com bases com menos espaço de alocação, tudo
depende da necessidade, vale destacar que entre eles estão:
 Microsoft SQL – Utiliza-se da linguagem SQL da Microsoft;
 MYSQL – Utiliza-se da linguagem SQL da Comunidade MYSQL;
 SQLite – Utiliza-se da linguagem SQL da Comunidade MYSQL;
13.2 DESENVOLVIMENTO DE TABELAS DO SISTEMA E VIEWS
O primeiro item que desenvolveremos são as tabelas e associam-se aos seus
índices, sendo eles responsáveis por garantir a integridade da informação dos dados
cadastrados. Na Figura a seguir encontra-se um exemplo de tabela utilizado em
nosso sistema:
Figura 20 - Modelo de tabela em SQLite com chave candidata primaria
Com a CHAVE CANDIDATA PRIMARIA IdAlunos, o sistema faz a associação
do registro do aluno, com os itens alocados, tal como possíveis pendências
existentes. As quais serão realizadas suas repetitivas ações de baixas, tanto para
devolução, como para perdidos no caso de não devolução do mesmo, como durante
o processo de alocação do mesmo. Cada linguagem de banco possui suas
particularidades, o exemplo acima foi desenvolvido em SQLite, já a Figura abaixo é
desenvolvida em MySQL, alguns tipos de funções e atributos são semelhas, outros
podem sofrer alterações como é o exemplo de DOMINIO, no qual o INTEGER do
SQLite, no MySQL se torna INT, os DOMINIOS VARCHAR, assim como CHAR
necessitam que sejam delimitados os seus tamanhos, o atributo que faz a

61
Cadastro de Alunos em MySQL
CREATE TABLE Cadastro_Alunos (
IdAlunos INT PRIMARY KEY Auto_Increment,
RAAluno INT UNIQUE KEY,
NomeAlunos VARCHAR(255),
Status CHAR(1)
);
numeração automática no SQLite é AUTOINCREMENT, já a sintaxe no Mysql é
Auto_Increment, esses são alguns exemplos da diferença.
Figura 21 - Modelo de tabela em MySQL com chave candidata primaria
Importante salientar que esse, assim como outros itens são necessários para
o desenvolvimento consciente ou atualização do sistema e suas dependências.
Para que se possa ter integridade nas tabelas necessita-se também ter
CHAVES SECUNDARIAS CANDIDATAS, as quais vão determinar que o campo
deva conter um conteúdo igual ao de outra tabela para ser aceito, ou seja, um
conteúdo que preenchera um list (Lista) na tela de sistema dando opções validas.
Na figura abaixo teremos um exemplo da associação da tabela de Cadastro de
Disciplinas, com a ID do Material e suas definições, sendo esse um vínculo efetuado
por três tabelas:

62
Cadastro de cada Material Relacionados a Disciplinas
CREATE TABLE ItemDisciplina (
IdDisciplina INTEGER REFERENCES Disciplinas (IdDisciplina ),
IdMaterial INTEGER REFERENCES Material ( IdMaterial )
);
CREATE TABLE Disciplinas (
IdDisciplinas INTEGER PRIMARY KEY AUTOINCREMENT,
NomeDisciplina VARCHAR
);
CREATE TABLE Material (
IdMaterial INTEGER PRIMARY KEY AUTOINCREMENT,
NomeMaterial VARCHAR,
DescricaoMaterial VARCHAR,
ISBN INTEGER,
CodeMaterial VARCHAR,
Disponivel CHAR,
DataInclusao DATE,
UsuarioAceite INTEGER
);
Figura 22 - Modelo de tabela em SQLite com chave candidata secundaria
Na tabela encima são relacionadas as disciplinas e os materiais associados a
cada uma delas, por meio dessa tabela é possível fazer a consulta de materiais
relacionados de uma forma mais efetiva e agilizada, sendo gerada a Visão (VIEW)
da mesma, podemos ter um acesso rápido, como se todas as tabelas relacionadas
fossem uma única tabela. A forma na qual são referenciados os Índices em cada
linguagem de banco de dados possui suas diferenças como se identifica na Figura a
seguir:

63
Consulta de itens cadastrados como existentes ou perdidos
CREATE VIEW Consulta_Materiais AS
select NomeMaterial, DescricaoMaterial, ISBN, CodeMaterial, IdMaterial as
Material, (select IdDisciplina from itemdisciplina where IdMaterial = Material)
as IdDisciplinaMaterial, (select NomeDisciplina from disciplinas where
IdDisciplinas = IdDisciplinaMaterial) as Disciplina from material;
Cadastro de cada Material Relacionados a Disciplinas
CREATE TABLE itemdisciplina (
IdDisciplina INT,
IdMaterial INT,
FOREIGN KEY (IdDisciplina) REFERENCES disciplinas (IdDisciplinas),
FOREIGN KEY (IdMaterial) REFERENCES material (IdMaterial));
CREATE TABLE disciplinas (
IdDisciplinas INT PRIMARY KEY AUTO_INCREMENT,
NomeDisciplina VARCHAR(255)
);
CREATE TABLE material (
IdMaterial INT PRIMARY KEY AUTO_INCREMENT,
NomeMaterial VARCHAR(225),
DescricaoMaterial VARCHAR(255),
ISBN INT,
CodeMaterial VARCHAR(10),
Disponivel CHAR(1),
DataInclusao DATE,
UsuarioAceite INT
);
Figura 23 - Exemplo de tabela em MySQL com chave candidata secundaria
Por meio da VIEW Consulta Materiais poderemos localizar materiais
disponíveis na biblioteca os quais estão listados, associados a cursos, caso não
estejam disponíveis são mostrados como indisponíveis e o motivo, assim como ao
selecionar o item no sistema ira informar se estão todos alocados ou não. No
desenvolvimento da VIEW observa-se que mesmo em linguagens de banco de
dados diferentes, a estrutura é praticamente a mesma, em nosso exemplo é
exatamente a mesma estrutura, conforme na figura abaixo:
Figura 24 - Exemplo de modelo de VIEW SQlite e MySQL

64
Operações e Itens de Operações
CREATE TABLE IF NOT EXISTS àluguel_operacao` (
ÌdOperacao` int(11) NOT NULL AUTO_INCREMENT,
` RAAluno` int(11) DEFAULT NULL,
`TotalItens` int(11) DEFAULT NULL,
`DataOperacao` date DEFAULT NULL,
`ChaveOperadorPIN` text,
`ChaveSegurancaOperacao` text,
PRIMARY KEY (ÌdOperacao`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
CREATE TABLE IF NOT EXISTS àluguel_operacao_itens` (
Ìd` int(11) NOT NULL AUTO_INCREMENT,
ÌdOperacao` int(11) DEFAULT NULL,
ÌdMaterial` int(11) DEFAULT NULL,
`StatusDevolucao` text,
`DataRetirada` date DEFAULT NULL,
`DataDevolucaoPrev` date DEFAULT NULL,
`DataDevolucao` date DEFAULT NULL,
`MultaDevolucao` double DEFAULT NULL,
`RAAluno` int,
ÀplicarMulta` char(1) DEFAULT NULL,
PRIMARY KEY (Ìd`),
FOREIGN KEY (IdMaterial) REFERENCES Material (IdMaterial)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
No exemplo anterior, temos como verificar qual Material é ou foi um item
catalogado no acervo da biblioteca, constando tanto a descrição, nome, numeração,
tal como seu estado, como disponível, ou perdido, sendo essa a consulta inicial em
nosso banco de dados.
Para obter um resultado mais preciso de livros alocados, precisam-se fazer
um controle de disponibilidade, o mesmo é gerado a partir do momento no qual é
gerada a entrada ou a saída de um item, tal como quando é determinado o mesmo
como “Perda”, no caso de alocação e não devolução do mesmo. Para isso
geraremos uma tabela de controle de Operações, uma relacional como cada item da
operação, assim como uma entrada na tabela entrada e devoluções, para obter um
controle se os itens estão disponíveis ou não para serem alocados. A tabela de
controle apenas possuíra os itens enquanto estiverem alocados, após esse período
os mesmos serão removidos, ou passaram para a tabela perdidos caso os mesmos
não sejam devolvidos.
Figura 25 - Exemplo de modelo de tabela de operações e Itens de operações

65
Consulta de itens alocados por aluno
CREATE VIEW Consulta_Aluno_Alocacao AS
select IdOperacao as OP, RAAluno as ID_ALUNO, (select NomeAlunos from
cadastro_alunos where RAAluno = ID_ALUNO) as NomeAluno, (select
IdMaterial from aluguel_operacao_itens where OP) as ID_MATERIAL, (select
NomeMaterial from material where IdMaterial = ID_MATERIAL) as
NomeMaterial, (select DataRetirada from aluguel_operacao_itens where
IdOperacao = OP) as DataRetirada, (select DataDevolucaoPrev from
aluguel_operacao_itens where IdOperacao = OP) as DataDevolucaoPrev,
(select DataDevolucao from aluguel_operacao_itens where IdOperacao = OP)
as DataDevolucao, (select StatusDevolucao from aluguel_operacao_itens
where IdOperacao = OP) as StatusDevolucao from aluguel_operacao;
Após desenvolvermos as tabelas referentes as transações (operações), cria-
se a view para exibir o resultado da operação, nesta view exibe-se a operação foi
finalizada ou não e os itens agregados a ela, disponível, ou perdido, sendo essa a
consulta inicial em nosso banco de dados.
Figura 26 - Exemplo de modelo de VIEW de operações em MySQL
Tanto na VIEW (Visão), como em SELECT (Consulta) utiliza-se o “AS” para
relacionar itens que passaram para parâmetros utilizados em outras consultas
dentro do mesmo comando.
13.3 DESENVOLVIMENTO DE TRIGGERS (GATILHOS)
Para obtermos um melhor funcionamento de ações aplicadas no banco de
dados, evitando erros de execução, os mesmos os quais poderiam resultar em
registros incorretos, utiliza-se os chamados (“Gatilhos”), sendo esse um recurso
oferecido pelas linguagens e sistemas gerenciadores de banco de dados com o
objetivo de executar ações no banco de dados baseadas em entradas por
parâmetros os quais sofrem ações tanto em inserção, tais como em alteração e
remoção de entradas no banco de dados, sendo esse um dos recursos utilizados
para otimização no processo de geração de logs de operações em sistemas.
Segundo (W3RESOURCE, 2013) “Um gatilho é um conjunto de ações que
são executados automaticamente quando uma operação de mudança
específico (SQL INSERT, UPDATE ou DELETE) é executada em uma

66
Geração de Status durante inserção de nova operação
DELIMITER $$
CREATE TRIGGER incluir_status_alocacao
AFTER INSERT ON aluguel_operacao_itens
FOR EACH ROW BEGIN
update entrada_itens set StatusAlocacao = NEW.StatusDevolucao
where n_tombo = NEW.n_tombo;
END $$
DELIMITER ;
Geração de Status durante devolução de itens da operação
DELIMITER $$
CREATE TRIGGER atualizar_status_alocacao
AFTER update ON aluguel_operacao_itens
FOR EACH ROW BEGIN
update entrada_itens set StatusAlocacao = NEW.StatusDevolucao
where n_tombo = NEW.n_tombo;
END $$
DELIMITER ;
tabela especificada. Triggers são úteis para tarefas como a aplicação das
regras de negócio, validação de dados de entrada, e manter uma trilha de
auditoria.”
Por meio dos gatilhos conseguimos fazer as alterações necessárias dentro do
banco de dados de forma automatizada seguindo as devidas regras de negócios. Na
Figura abaixo encontram-se algumas regras que serão aplicadas no banco de dados
da Biblioteca da instituição.
Figura 27 - Exemplo de Trigger para atualizar registros de status
13.4 REPRESENTAÇÃO DO MODELO LÓGICO RELACIONAL DO BANCO DE
DADOS
Após fazer os levantamentos de requisitos obtivemos o banco de dados final,
o qual vislumbra o seguinte padrão modelado, Na Figura abaixo o Modelo Relacional
EER foi gerado pelo MYSQL WorkBench, com todos relacionamentos de tabelas,
índices de Chaves Candidatas Primarias e Secundarias, necessárias para garantir a
integridade da informação cadastrada e facilitar o processo de consulta.

67
Figura 28 - Modelo de modelagem EER do banco de dados

68
14 SISTEMA EM MVC E CRUD COM PHP E MYSQL
14.1 INTRODUÇÃO A CONCEITOS DE CRUD EM SISTEMA MVC
Na busca por uma solução viável para o processo de desenvolvimento, tendo
em vista novas tendências do mercado, aplicadas a novas tecnologias (formas de
desenvolvimento e linguagens atuais), foi identificado à necessidade de criar um
sistema o qual obtivesse um melhor desempenho e oferece-se de uma forma segura
e estável a melhor solução, sendo essa desenvolvida em plataforma WEB
(computação em Nuvem / Clouding Computer), podendo ser a mesma tanto em um
servidor local, como na Internet, em um servidor de banco de dados o mesmo
armazenado, ou todo sistema em Nuvem. A linguagem escolhida foi o PHP, por
questão de estabilidade, ótima performance e resultados satisfatórios ao interagir
com outras linguagens, as tecnologias aplicadas as linguagens foram um sistema
que pode-se fazer todas operações de forma dinâmica, sem complicações, com
possibilidade de inclusão e edição, sem precisar alterar entre telas sendo itens de
mesma categoria de metadados.
Segundo (AREND, 2011, p.9-10) Em sistema de informações com a
necessidade da geração e coleta de dados, são efetuadas ações a partir de
informações de metadados, sendo essas a criação, obtenção, atualização e
exclusão dos dados (CRUD, do inglês create, retrieve, update e delete),
com a possibilidade de criação de páginas dinâmica com templates
(Modelos) gerados a partir de metadados."
Esse sistema, por sua vez, segue um padrão em sua evolução o qual se
deriva o MVC, esse padrão permite separar as telas, da lógica de negócios, assim
como fazer o controle de transações das ações por elas geradas e a elas
associadas. Sendo por meio deste processo possível reduzir tempo em processo de
manutenção do sistema, pois o mesmo possui código, de telas e de lógica de
negócios separados.
Segundo (Gamma et al., 1994, p. 20), o MVC é composto por três
divisões, denominadas como camadas do sistema, sendo elas: Modelo –
Sendo a responsável por representar as lógicas de negócios aplicadas e a
funções a elas associadas vinculadas com os dados, Visão – Representada
como as telas do sistema, e a camada de Controle, a qual controla as
interações entre as outras camadas e acompanha a execução de ações na
aplicação [...] “o que definimos como sendo BACKEND e FRONTEND.
Por meio dessa divisão de camadas podemos identificar quais partes do
sistema interagem com as outras, reduzindo tempo de programação caso seja
precisa alterar parte do sistema, pois se a alteração for na tela, basicamente o que

69
encontrará será conteúdo de telas e chamadas (INCLUDES) de outros arquivos, os
quais guardaram as regras de negócios a eles associados, assim evitando
retrabalho para localizar o conteúdo desejado, sem precisar passar por conteúdo o
qual não seja semelhante.
Para o desenvolvimento da Interface do CRUD, utiliza-se o jQuery EasyUI
1.3.6, pois ele utiliza-se de HTML5, e é uma das mais recentes bibliotecas de
jQuery, desta forma possibilitando maiores interações com os objetos, entre eles os
objetos utilizados Datagrid (Views / Visões), ComboGrid (Combobox com DataGrid
Integrado), DateTimeBox (Calendario associado ao campo de data), Dialog /
Window (Janelas), Messager (Alertas), itens denominados como plug-ins.

70
15 CONSIDERAÇÕES FINAIS
Com o propósito de desenvolver um sistema de gestão de biblioteca para a
instituição Faculdade de Tecnologia de Tatuí, o qual a proposta é solucionar as
lacunas encontradas por meios de pesquisas e entrevistas, feitas de forma direta
com os alunos e funcionários da biblioteca. Com as gerações de relatórios mais
precisos, automatização no processo de baixa de perdidos, de alunos com
pendência de possibilidade de comunicação dessa informação com a secretaria
acadêmica da instituição em questão, nós podemos por meio do uso das técnicas de
engenharia de software, desta forma podendo oferecer uma melhor solução, sendo
por meio do software desenvolvido possível:
 Efetuar geração de relatórios detalhados sobre pendências de matérias e de
alunos;
 Efetuar baixa de forma automatizada das pendências de forma automatizada,
respeitando as regras de sistema configuradas;
 Flexibilidade para definir as regras de negócios aplicadas à penalização por
devolução com tempo superior ao permitido, tal como suspensão do direito de
uso da carteirinha pelo bloqueio do RA do aluno no sistema;
Por meio da utilização de um sistema CRUD foi possível produzir uma interface
mais limpa e mais fácil de acessar, graças à tecnologia MVC é possível separar as
funcionalidades em camadas, dessa forma facilitando alterações futuras, assim
como correções de regras de negócios necessárias, sendo possível uma evolução
em trabalhos futuros do sistema, sem dificuldades extremas para seu entendimento
do funcionamento. Tendo sido desenvolvido o CRUD com uma tecnologia de licença
GPL, o EASY JQUERY UI, assim como a própria linguagem de programação da
lógica de negócios PHP, tal como seu banco de dados MYSQL. Sendo utilizado o
sistema em nuvem visualizando a possibilidade de ser acessado de diferentes
dispositivos, a partir de diferentes sistemas operacionais.
Os resultados obtidos ao concluir esse projeto mostram a forma correta de
desenvolver um projeto de sistema, respeitando os processos de engenharia de
sistemas, tal como demonstram a facilidade do processo, por meio de um passo a
passo, com exemplos de cada fase do projeto, deixando em aberto possibilidade de
melhorias futuras.

71
REFERÊNCIAS
A Guide to Project Management Body of Knowledge - PMBOK® Guide 2004
Edition Project Management Institute - PMI®.
A Guide to Project Management Body of Knowledge - PMBOK® Guide 2007
Edition Project Management Institute - PMI®.
ALBRETCHT, A.J., Measuring application developlement productivity, in
Proceedings IBM Aplications Development Symposium, Monterey, California,
October 14-17 1979.
ALVES, W. P. Banco de Dados: Teoria e Desenvolvimento. 1ª Edição, São Paulo:
Editora Érica, 2009.
AREND, Felipe Gabriel - geração de operações crud a partir de metadados.
Retirado de: <http -app.inf.ufsm.br bdtg arquivo.php id 153 do nload 1>
em 5 mai. 2014.
ARROYO, Alexander, SANTOS, Fabio. Programação para Web utilizando - PHP
Básico Unicamp, 2002. Retirado de:
<http://ci.ufpel.edu.br/treinamento/apostilas/programacao/php/phpbasico_unicamp.p
df> em 19 set. 2013
ARROYO, Alexander, SANTOS, Fabio. Programação para Web utilizando - PHP
Avançado Unicamp, 2006. Retirado de:
<ftp.unicamp.br/pub/apoio/treinamentos/desenweb/apostila_php_avancado.pdf>
em 19 set. 2013
BARROS, D.J., Documento De Requisitos Para Desenvolvimento De Software
Para Controle Em Consultório De Ortodontia: Gerenciamento De Pacientes.
Engenharia de Software Fatec Tatuí. 2012.
CENTRO DE COMPUTACAO UNICAMP, Banco de Dados Básico, 2001. Retirado
de: <http://ftp.unicamp.br/pub/apoio/treinamentos/bancodados/cursodb.pdf>
em 18 de abril de 2014.
DATE, C. J. INTRODUÇÃO A SISTEMAS DE BANCOS DE DADOS. 8. ed. Rio de
Janeiro: Elsevier, 2003.
FABBRI, Sandra. Gerencia e Planejamento de Software - Métricas - Curso de
Pós-graduação “Lato-Sensu” – Desenvolvimento de Software para Web, UFSCar,
São Carlos, Janeiro 2005. Il.
Fred R. McFadden, Jeffrey A. Hoffer e Mary B. Prescott, Modern Database
Management, Fifth Edition, Addison-Wesley. 1999. Il.

72
GAMMA et al., Design Patterns: Elements of Reusable Object-Oriented
Software, 1994. Editora Addison-Wesley Professional, 1º Edição. (November 10,
1994).
GIL, A.C. Métodos e Técnicas de Pesquisa Social. 5. Ed. São Paulo:Atlas, 1999.
DATE, C.J. Introdução a Banco de Dados, 8º Edição: ELSEVIER, 2004.
HELDMAN, Ki, Gerencia de Projetos Fundamentos - 5º Edição: Elsevier, 2005.
MACORATTI, J. C, UML - Diagrama de Classes e objetos, 2004. Retirado de:
<http://www.macoratti.net/net_uml1.htm> em 15 de abril de 2004. Il.
MATTASO, M. L. Q., INTRODUÇÃO A BANCO DE DADOS RELACIONAL - O
modelo relacional, 2007. Retirado de:
<www.cos.ufrj.br/~marta/BdRel.pdf> em 18 de abril de 2014.
MOREIRA, Jussara. MÉTRICAS ORIENTADAS À FUNÇÃO, 2010. Retirado de:
<http://nti.facape.br/jussaramoreira/mps/material/METRICAS_ORIENTADAS_AO_T
AMANHO_E_TECNICAS.doc> em 16 abril 2014. Il.
NIXON, Robin. Learn PHP, MYSQL, JavaScript SECOND EDITION, 2º Ed.:
O'REILLY, 2012. p.5
PRESSMAN, Roger S. Engenharia de Software - 6ª Edição: Pearson, 2006.
SANCHES, A. R., AULA: Modelo físico - BANCO DE DADOS, 2005. Retirado de:
<http://www.ime.usp.br/~andrers/aulas/bd2005-1/aula12.html>
em 18 de abril de 2014.
SELLTIZ, C. at al. Métodos de Pesquisa nas Relações Sociais. São Paulo:
EPU/EDUSP, 1947.
SOMMERVILLE, I., Engenharia de Software. 6ª Edição, São Paulo: Addison
Wesley, 2003.
SOMMERVILLE, I., Engenharia de Software. 8ª Edição: Pearson, 2007.
W3RESOURCE, MySQL Triggers, 2013. Retirado de:
http://www.w3resource.com/mysql/mysql-triggers.php> em 23 abr. 2014.

Gestão de Biblioteca da FATEC Tatuí

Gestão de Biblioteca da FATEC Tatuí

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Gestão de Biblioteca da FATEC Tatuí

Similaire à Gestão de Biblioteca da FATEC Tatuí (20)

Gestão de Biblioteca da FATEC Tatuí