Desenvolvimento de Sistema CRUD (MVC) PHP / MYSQL

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

MensalAnual

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.pdf> 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_TAMANHO_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.

73

APÊNDICES

74

Apêndice A – Glossário de Termos Técnicos

Glossário é um dicionário com vários termos, que contem palavras técnicas, ou

que possa ter palavras em outro idioma, como pode ser visto o exemplo de um

glossário do sistema na tabela abaixo.

Glossário do sistema

Termo Significado

Base de Dados É possível dizer de uma forma genérica que qualquer conjunto de dados é uma Base de Dados (BD): uma agenda com as moradas de pessoas conhecidas, uma lista de CDs, um livro, apontamentos tirados nas aulas, os dados guardados nos computadores das Finanças. Sobre os contribuintes e a World Wide Web.

Banco de Dados É uma coleção de dados relacionados e armazenados em algum dispositivo. Inicialmente definidos como base de dados. Mais conhecidos ORACLE, SQL, MYSQL.

PHP Codes / MYSQL Server

Arquivos de programação online executáveis em servidor, com armazenamento em banco de dados MYSQL, assim como aplicando regras da linguagem de banco de dados SQL.

Computação em Nuvem / Clouding Computer

Tecnologia de computação nas nuvens, armazenamento e processamento em servidores remotos, com espelhamentos simultâneos e com configurações instantâneas de acordo com a necessidade.

Criptografia Consiste em cifrar um arquivo ou mensagem usando um conjunto de cálculos. O arquivo cifrado (ou criptografado) torna-se incompreensível até que seja descriptografado. Os cálculos usados para criptografar ou descriptografar o arquivo são chamados de chaves. Apenas alguém que tenha a chave poderá ler o arquivo criptografado.

Customização É empregada no sentido de personalização, adaptação. Desta forma, customizar é adaptar algo de acordo com o gosto ou necessidade de alguém; Alterar algo para fazer com que sirva melhor aos requisitos de alguém. Customização pode ser entendida como sendo adequação ao gosto do cliente.

Interface Meio de comunicação entre duas coisas distintas, assim como a interface entre o computador e usuário é o sistema operacional e seus aplicativos.

Query É o meio de efetuar consultas em banco de dados

Hardware A parte física do computador e/ou outros dispositivos.

Software A parte logica, sistema operacional, os programas.

Sqlite Banco de dados que utiliza a linguagem SQL com menos espaço.


75

Apêndice B – Entrevista com o cliente sobre satisfação e melhorias

Esta pesquisa teve por meio de levantamento de dados a função de

demonstrar a situação atual da biblioteca acadêmica da Faculdade de Tecnologia de Tatuí. Qual o nível de satisfação de uso do sistema atual? Administração e funcionários da biblioteca apontaram como sendo, seu índice de satisfação, apontando melhorias, algumas falhas do sistema, sendo o resultado baseado em todos que responderam verbalmente sua opinião como sendo 20% acham o sistema bom, mas que pode ser melhorado, e 80% dizem que o sistema é regular, por meio da amostragem, baseando-se em suas reclamações de itens ainda não atendidos pelo sistema em questão. Qual o índice de inadimplência de devolução de cada curso? Administração da biblioteca – Hoje 50% das alocações de automação industrial, 30% do curso de gestão empresarial, 15% de gestão em tecnologia da informação e 5% para os demais cursos, isso para cada curso no qual não há devolução no prazo. Qual curso possui maior utilização de livros? Administração da biblioteca – Curso de automação industrial. Alunos GTI – Qual o tempo médio para geração de relatórios de pendências? Administração da biblioteca – Aproximadamente 5 (cinco) minutos. Qual o prazo de suspensão? O RA seria suspenso permanentemente? Administração da biblioteca – a cada 1 (um) dia de atraso, corresponde a 3 (três) de bloqueio, caso o mesmo ultrapasse 10 (dez) dias, ou seja, equivalente a 30 de suspensão o RA do aluno é bloqueado de fazer alocação. Existe algum tipo de comunicação entre a secretaria e a biblioteca? Administração da biblioteca – Não há comunicação secretaria biblioteca, tal como não há entre biblioteca e aluno. Há algum tipo de controle de pendência quando o aluno se forma? Administração da biblioteca – Hoje não há esse controle para nenhum aluno que sai da instituição. Os alunos tentam fazer alocações por meio de carteirinhas de outros alunos? Há hoje alguma trava que evitaria isso? Administração da biblioteca – Não, hoje alguns alunos fazem alocações com carteirinhas de outros alunos, não há um controle que valida se o aluno que porta a carteirinha é o aluno que esta realmente levando o livro em questão.

76

Apêndice C – Dicionário de Dados do Banco de Dados

Importante: Para efetuar a leitura das tabelas abaixo, destaca-se que os itens com # e sublinhados

são chaves primárias, itens apenas sublinhados são chaves secundarias, itens em itálico são chaves

únicas, conforme nomenclatura de engenharia de software.

Tabela 18: Tabela operador

Tabela: operador

Campo Domínio Tamanho Descrição

NomeOperador Alfanumérico 255 Nome do Operador

DataCadastro Data/Hora 8 Data de Cadastro

#ChaveOperadorPIN Inteiro 11 Identificação do Operador


Tabela 19: Tabela regra de sistema

Tabela: regrassistema


PeriodoAlocacao Alfanumérico 2 Tempo de permanência

ValorMulta Numérico 2 Período de Bloqueio

Frequencia alfanumérico 6 Clico do período (bloqueio)

#ItemTipo Inteiro 11 A quem atribui a regra


Tabela 20: Tabela aluguel operação

Tabela: aluguel_operacao


#IdOperacao Inteiro 11 Id da Operação

RAAluno alfanumérico 20 Identifica aluno

DataOperacao Data/Hora 8 Data da solicitação

ChaveOperadorPIN Inteiro 11 Identificador de Operador

ChaveSegurancaOperacao alfanumérico 45 Valida entrada no sistema


77

Tabela 21: Tabela Cadastro de alunos

Tabela: cadastro_alunos


#IdAlunos Inteiro 11 Id no sistema

RAAluno Alfanumerico 20 Identifica o aluno

NomeAluno Alfanumerico 255 Nome do Aluno

Status Caractere 1 Estatus do aluno


Tabela 22: Tabela aluguel operação itens

Tabela: aluguel_operacao_itens


#Id Inteiro 11 Identificação das entradas

idOperacao Inteiro 11 Identifica a operação

IdMaterial Inteiro 11 Qual material foi retirado

N_Tombo alfanumérico 11 Numero do Tombo

StatusDevolucao Caractere 1 (D) Disponível - (A) Alocado

DataRetirada Data/Hora 8 Data que foi retirado o material

DataDevolucaoPrev Data/Hora 8 Data Prevista para devolução

DataDevolucao Data/Hora 8 Data em que foi devolvido

MultaDevoucao Caractere 1 (S) atribui – (N) não atribui

RAAluno Alfanumerico 20 Identifica o aluno

AplicaMulta Caractere 1 (S) mantem – (N) remove

ItemTipo Inteiro 11 Valida regra de sistema


Tabela 23: Tabela entrada de itens

Tabela: entrada_itens


#IdEntradaEstoque Inteiro 11 Id de entrada do item novo

IdMaterial Inteiro 11 Id material referente a entrada

N_Tombo alfanumérico 11 Numero entrada do material

78

Motivo Texto 45 Material - Novo / Devolvido

DataEntrada Data/Hora 8 Data de Tombo do material


Tabela 24: Tabela itens perdidos

Tabela: itens_perdidos


IdOperacao Inteiro 11 Id operação (não devolução)

IdMaterial Inteiro 11 Id material referente a entrada

N_Tombo Alfanumérico 11 Numero identificação da entrada

StatusDevolucao Caractere 1 (P) Perdido – (D) Devolvido

DataRetirada Data/Hora 8 Data que foi retirado material

RAAluno alfanumérico 20 RA do aluno inadimplente


Tabela 25: Tabela saída de itens

Tabela: saida_itens


#IdEntradaEstoque Inteiro 11 Id de saida do item

IdMaterial Inteiro 11 Id material referente a saida

N_Tombo Alfanumérico 11 Numero saida do material

Motivo Texto 45 Material - Transferido / Perdido

DataSaida Data/Hora 8 Data de saida do material


Tabela 26: Tabela material

Tabela: material


#IdMaterial Inteiro 11 Identificação do item novo

NomeMaterial Alfanumérico 225 Nome do material

Autor Alfanumérico 225 Nome do autor do material

Editora Alfanumérico 225 Nome da editora

Ano Alfanumérico 4 Ano de publicação

Edicao Alfanumérico 14 Edição da publicação

79

DescricaoMaterial Alfanumérico 255 Descrição do material

ISBN Alfanumérico 18 Código ISBN do material

ISSN Alfanumérico 13 Código ISSN do material

Classificacao Alfanumérico 25 Classificação Autor

DataInclusacao Data/Hora 8 Data de inclusão

UsuarioAceite Inteiro 11 Código do operador


Tabela 27: Tabela cursos

Tabela: cursos


#IdCurso Inteiro 11 Identificação do curso

NomeCurso Inteiro 11 Nome do curso


Tabela 28: Tabela disciplinas

Tabela: disciplinas


#IdDisciplina Inteiro 11 Identificação de disciplina

NomeDisciplina Inteiro 11 Nome da disciplina


80

Apêndice D – Telas do sistema

Figura 29 - Tela de login do sistema


Figura 30 - Tela Inicial do sistema


81

Figura 31 - Tela de cadastro de alunos


Figura 32 - Tela de cadastro de materiais


82

Figura 33 - Tela de cadastro de Cursos


Figura 34 - Tela de cadastro de Disciplinas


83

Figura 35 - Tela de Gerenciamento de Associação Materiais


Figura 36 - Tela de Gerenciamento de alocações


84

Figura 37 - Tela de Geração de alocação


Figura 38 - Tela de geração de relatório geral pendências para conferências


Documents

Desenvolvimento de Sistema CRUD (MVC) PHP / MYSQL