Desenvolvimento de Sistema CRUD (MVC) PHP / MYSQL

8,097 views

Published on

Trabalho de graduação engenharia de software e desenvolvimento de sistema de gestão de biblioteca acadêmica para FATEC-TA (Faculdade de Tecnologia de Tatuí)

Desenvolvimento de Sistema CRUD (MVC) PHP / MYSQL

  1. 1. 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
  2. 2. 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 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.
  3. 3. ANDERSON LUCAS DOS SANTOS ROGÉRIO DE MORAES SERGIO DE JESUS RIBEIRO JUNIOR ( ) 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.
  4. 4. 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.
  5. 5. “É 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)
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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)
  12. 12. 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
  13. 13. 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. 14. 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. 15. 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. 16. 16 Figura 2 - Média de alocação de livros na biblioteca da FATEC Tatuí Fonte: Autoria própria 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 Fonte: Autoria própria A atual aplicação utilizada na biblioteca da instituição é OPENSOURCE, e com isso constam alguns problemas, tais como nos tópicos abaixo:  Duplicidade de informação em algumas tabelas sem uma organização;  Consultas restritas e sem otimização de query’s;  Penalidades dos prazos de entrega.  Falta de controles mais precisos em parte da gestão bibliotecária. 0 5000 10000 15000 20000 Diario Mensal Anual 80 2000 20000 Baseado em numero de livros 50% Automoção Industrial 30% Gestão Empresarial 15% Gestão em Tecnologia da Informação 5% Outros Cursos e suas inadimplências
  17. 17. 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. 18. 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. 19. 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. 20. 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. 21. 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. 22. 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. 23. 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. 24. 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. 25. 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. 26. 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. 27. 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. 28. 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. 29. 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. 30. 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. Fonte: Autoria própria 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. Fonte: Autoria própria 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. 31. 31 Figura 4 - Modelo de casos de uso ator operador Fonte: Autoria própria 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 Fonte: Autoria própria
  32. 32. 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. 33. 33 Figura 6 - Diagrama de sequência de alocação Fonte: Autoria própria 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. 34. 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. 35. 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. 36. 36 Figura 7 - Diagrama de classes de projeto Fonte: Autoria própria
  37. 37. 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. 38. 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. 39. 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. 40. 40 Figura 10 - Diagrama de entidade relacionamento (DER) Fonte: Autoria própria
  41. 41. 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. 42. 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. 43. 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 Fonte: Autoria própria Agora vemos o controle do operador com a seguinte tabela de ALI abaixo; Tabela 5: Exemplo de arquivos lógicos interno operador Operador Campo Tamanho Formato Nome 255 Alfanumérico DataCadastro 8 Data ChaveOperadorPIN 11 Inteiro DER 3 RLR 1 Complexidade: SIMPLES Fonte: Autoria própria 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 Campo Tamanho Formato IdOperacao 11 Inteiro RAaluno 20 Alfanumérico DataOperacao 8 Data ChaveoperadorPIN 11 Inteiro ChaveSegurançaOperacao 9 Alfanumerico DER 5 RLR 4 Complexidade: SIMPLES Fonte: Autoria própria
  44. 44. 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 Campo Tamanho Formato Id 11 Inteiro IdOperacao 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 RAAluno 20 Alfanumérico AplicarMulta 1 Alfanumérico ItemTipo 11 Inteiro DER 12 RLR 3 Complexidade: SIMPLES Fonte: Autoria própria 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 Campo Tamanho Formato IdMaterial 11 Inteiro NomeMaterial 255 Alfanumérico Titulo 255 Alfanumérico Autor 255 Alfanumérico Editora 255 Alfanumérico Ano 8 Data
  45. 45. 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 Fonte: Autoria própria 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 Campo Tamanho Formato ChaveOperadorPIN 11 Inteiro RAAluno 13 Alfanumérico DataOperacao 8 Data IdOperacao 11 Inteiro ChaveSegurancaOperacao 255 Alfanumérico DER 5 RLR 1 Complexidade: SIMPLES Fonte: Autoria própria
  46. 46. 46 Tabela 10: Exemplo de AIE de materiais cadastrados Material_cadastrado_por_operador Campo Tamanho Formato ChaveOperadorPIN 11 Inteiro IdOperacao 11 Inteiro 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 DER 13 RLR 2 Complexidade: SIMPLES Fonte: Autoria própria Tabela 11: Exemplo de Arquivos de interface externa de curso cadastrado curso_cadastrado_por_operador Campo Tamanho Formato ChaveOperadorPIN 11 Inteiro RAAluno 13 Alfanumérico IdCurso 11 Inteiro NomeCurso 225 Alfanumerico DER 4 RLR 2 Complexidade: SIMPLES Fonte: Autoria própria
  47. 47. 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 Fonte: Autoria própria
  48. 48. 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 DER 5 ALR 1 Complexidade: SIMPLES Fonte: Autoria própria 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. 49. 49 Figura 13 - Exemplo de tela de associação de cursos, materiais e disciplinas DER 7 ALR 1 Complexidade: SIMPLES Fonte: Autoria própria 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. 50. 50 Figura 14 - Exemplo de tela de relatórios de pendencias de livros DER 3 ALR 1 Complexidade: SIMPLES Fonte: Autoria própria 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. 51. 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. 52. 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. 53. 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. 54. 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 Fonte: Autoria própria
  55. 55. 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) Fonte: Autoria própria 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 Fonte: Autoria própria Abaixo veremos a tabela da visão de aplicações Web (SERVIDOR).
  56. 56. 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) Fonte: Autoria própria Abaixo observa-se a figura da aplicação WEB (servidor); Figura 18 - Exemplo de visão de aplicação Web (servidor) Fonte: Autoria própria
  57. 57. 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) Fonte: Autoria própria
  58. 58. 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. 59. 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. 60. 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 Fonte: Autoria própria 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. 61. 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 Fonte: Autoria própria 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. 62. 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 Fonte: Autoria própria 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. 63. 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 Fonte: Autoria própria 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 Fonte: Autoria própria
  64. 64. 64 Operações e Itens de Operações CREATE TABLE IF NOT EXISTS `aluguel_operacao` ( `IdOperacao` 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 (`IdOperacao`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ; CREATE TABLE IF NOT EXISTS `aluguel_operacao_itens` ( `Id` int(11) NOT NULL AUTO_INCREMENT, `IdOperacao` int(11) DEFAULT NULL, `IdMaterial` int(11) DEFAULT NULL, `StatusDevolucao` text, `DataRetirada` date DEFAULT NULL, `DataDevolucaoPrev` date DEFAULT NULL, `DataDevolucao` date DEFAULT NULL, `MultaDevolucao` double DEFAULT NULL, `RAAluno` int, `AplicarMulta` char(1) DEFAULT NULL, PRIMARY KEY (`Id`), 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 Fonte: Autoria própria
  65. 65. 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 Fonte: Autoria própria 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. 66. 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 Fonte: Autoria própria 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. 67. 67 Figura 28 - Modelo de modelagem EER do banco de dados Fonte: Autoria própria
  68. 68. 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. 69. 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. 70. 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. 71. 71 REFERÊNCIAS A Guide to Project Management Body of Knowledge - PMBOK® Guide 2004 Edition Project Management Institute - PMI®. A Guide to Project Management Body of Knowledge - PMBOK® Guide 2007 Edition Project Management Institute - PMI®. ALBRETCHT, A.J., Measuring application developlement productivity, in Proceedings IBM Aplications Development Symposium, Monterey, California, October 14-17 1979. ALVES, W. P. Banco de Dados: Teoria e Desenvolvimento. 1ª Edição, São Paulo: Editora Érica, 2009. AREND, Felipe Gabriel - geração de operações crud a partir de metadados. Retirado de: <http -app.inf.ufsm.br bdtg arquivo.php id 153 do nload 1> em 5 mai. 2014. ARROYO, Alexander, SANTOS, Fabio. Programação para Web utilizando - PHP Básico Unicamp, 2002. Retirado de: <http://ci.ufpel.edu.br/treinamento/apostilas/programacao/php/phpbasico_unicamp.p df> em 19 set. 2013 ARROYO, Alexander, SANTOS, Fabio. Programação para Web utilizando - PHP Avançado Unicamp, 2006. Retirado de: <ftp.unicamp.br/pub/apoio/treinamentos/desenweb/apostila_php_avancado.pdf> em 19 set. 2013 BARROS, D.J., Documento De Requisitos Para Desenvolvimento De Software Para Controle Em Consultório De Ortodontia: Gerenciamento De Pacientes. Engenharia de Software Fatec Tatuí. 2012. CENTRO DE COMPUTACAO UNICAMP, Banco de Dados Básico, 2001. Retirado de: <http://ftp.unicamp.br/pub/apoio/treinamentos/bancodados/cursodb.pdf> em 18 de abril de 2014. DATE, C. J. INTRODUÇÃO A SISTEMAS DE BANCOS DE DADOS. 8. ed. Rio de Janeiro: Elsevier, 2003. FABBRI, Sandra. Gerencia e Planejamento de Software - Métricas - Curso de Pós-graduação “Lato-Sensu” – Desenvolvimento de Software para Web, UFSCar, São Carlos, Janeiro 2005. Il. Fred R. McFadden, Jeffrey A. Hoffer e Mary B. Prescott, Modern Database Management, Fifth Edition, Addison-Wesley. 1999. Il.
  72. 72. 72 GAMMA et al., Design Patterns: Elements of Reusable Object-Oriented Software, 1994. Editora Addison-Wesley Professional, 1º Edição. (November 10, 1994). GIL, A.C. Métodos e Técnicas de Pesquisa Social. 5. Ed. São Paulo:Atlas, 1999. DATE, C.J. Introdução a Banco de Dados, 8º Edição: ELSEVIER, 2004. HELDMAN, Ki, Gerencia de Projetos Fundamentos - 5º Edição: Elsevier, 2005. MACORATTI, J. C, UML - Diagrama de Classes e objetos, 2004. Retirado de: <http://www.macoratti.net/net_uml1.htm> em 15 de abril de 2004. Il. MATTASO, M. L. Q., INTRODUÇÃO A BANCO DE DADOS RELACIONAL - O modelo relacional, 2007. Retirado de: <www.cos.ufrj.br/~marta/BdRel.pdf> em 18 de abril de 2014. MOREIRA, Jussara. MÉTRICAS ORIENTADAS À FUNÇÃO, 2010. Retirado de: <http://nti.facape.br/jussaramoreira/mps/material/METRICAS_ORIENTADAS_AO_T AMANHO_E_TECNICAS.doc> em 16 abril 2014. Il. NIXON, Robin. Learn PHP, MYSQL, JavaScript SECOND EDITION, 2º Ed.: O'REILLY, 2012. p.5 PRESSMAN, Roger S. Engenharia de Software - 6ª Edição: Pearson, 2006. SANCHES, A. R., AULA: Modelo físico - BANCO DE DADOS, 2005. Retirado de: <http://www.ime.usp.br/~andrers/aulas/bd2005-1/aula12.html> em 18 de abril de 2014. SELLTIZ, C. at al. Métodos de Pesquisa nas Relações Sociais. São Paulo: EPU/EDUSP, 1947. SOMMERVILLE, I., Engenharia de Software. 6ª Edição, São Paulo: Addison Wesley, 2003. SOMMERVILLE, I., Engenharia de Software. 8ª Edição: Pearson, 2007. W3RESOURCE, MySQL Triggers, 2013. Retirado de: http://www.w3resource.com/mysql/mysql-triggers.php> em 23 abr. 2014.
  73. 73. 73 APÊNDICES

×