iMestre - Sistema Web de Auxílio a Professores

INSTITUTO FEDERAL DE EDUCAÇÃO CIÊNCIA E TECNOLOGIA DA BAHIA BACHARELADO EM SISTEMAS DE INFORMAÇÃO

LUCAS AMPARO BARBOSA

iMestre: Sistema Web de Auxílio a Professores

Vitória da Conquista 2015

LUCAS AMPARO BARBOSA

iMestre: Sistema Web de Auxílio a Professores DOCUMENTAÇÃO, MODELAGEM E IMPLEMENTAÇÃO

Monografia apresentada ao Instituto Federal de Educação, Ciência e Tecnologia da Bahia – IFBA, curso de Bacharelado em Sistemas de Informação como requisito parcial para a obtenção do grau de Bacharel em Sistemas de Informação.

Orientador: Prof. Luiz Fernando Cardeal de Souza

Vitória da Conquista 2015

TERMO DE APROVAÇÃO

Lucas Amparo Barbosa

iMestre: Sistema Web de Auxílio a Professores

Monografia aprovada como requisito parcial para obtenção do grau de Bacharel em Sistemas de Informação, Instituto Federal de Educação Ciência e Tecnologia do estado da Bahia - IFBA, pela seguinte banca examinadora:

_________________________________________________ Luiz Fernando Cardeal de Souza – Orientador Especialista

_________________________________________________ Mailson Sousa Couto Mestre

_________________________________________________ Crescêncio Rodrigues Lima Neto Mestre

Vitória da Conquista, 27 de novembro de 2015.

A Deus, meus pais e os amigos que fiz nessa estrada.

AGRADECIMENTOS

Primeiramente à Deus, por ter me presenteado com a capacidade de construir aquilo que imagino. Aos meus pais, por terem me dado o suporte necessário para evoluir, tanto intelectual quanto socialmente. Aos meus amigos, por aguentarem todas as minhas reclamações. Sem vocês, já teria morrido de stress. A minha namorada Thamires, por ouvir todas as minhas lamúrias e o quão cansado essa última fase da faculdade pode deixar uma pessoa. Ao meu orientador Fernando Cardeal, pela paciência de Jó para construirmos juntos este projeto. Aos professores do IFBA, que me ensinaram boa parte do que eu sei. Em especial a Luís Paulo, que sempre está à disposição para ajudar no que for necessário.

O Caminho até aqui... Em 2011 uma caminhada nova começou. Era um novo desafio em um terreno já conhecido. Não sabia o que iria encontrar, mas estava preparado para qualquer coisa que viesse. Eu estava pronto. No primeiro semestre, aquele gás todo, querendo fazer a diferença. Ajudar em tudo e a todos, fazer um "nome"... Fazer a diferença, no geral. "Mas a vida é uma caixinha de surpresas", já dizia o poeta... Nada é exatamente da forma que esperamos. Vieram as decepções, as brigas, as infelicidades. Pessoas arrogantes, pessoas acovardadas, pessoas acomodadas. De tudo um pouco é experimentado no ambiente "acadêmico". Mas nem tudo são pedras, existem também as flores. O trigo perdido no joio. Pessoas incríveis, parceiras e, acima de tudo, competentes.Cada uma em sua especialidade, cada uma com sua habilidade. Ninguém é obrigado a ser bom em tudo. A comunhão destas habilidades nos trouxeram ao ponto em que estamos hoje: A Formatura. Aprendi muita coisa no caminho até aqui. Nem tudo que aprendi foi bom, mas com certeza absoluta me fizeram uma pessoa melhor. Por isso, obrigado.

EPÍGRAFE RESUMO Este trabalho tem como objetivo desenvolver um aplicativo que visa centralizar diversas funções necessárias à execução da atividade de um professor, tais como confeccionar atividades e lançar notas, em um único aplicativo, acessível via web. Estas demandas foram elucidadas a partir da solicitação do professor Tony e evoluídas através de pesquisas comparativas de diversos aplicativos. Para atendelas, foi projetado o iMestre. Aplicando-se o conhecimento de desenvolvimento de software, como padrões de projetos e ciclos de vida, a construção do sistema foi feita a partir do uso de alguns frameworks, como Doctrine e Foundation, e da linguagem PHP, amplamente difundida na comunidade de desenvolvimento web, somado ao SGBD MySQL, culminando em um sistema que supre as necessidades previamente levantadas.

Palavras-chave: Desenvolvimento. Programação Web. Banco de Dados. PHP.

ABSTRACT This study aims to develop an application that intended to centralize various functions necessary to perform the activity of a teacher such as confection activities and launch notes, in a single application, accessible via web. These demands were elucidated from Tony teacher's request and evolved through comparative research for various applications. To meet them, it was designed on iMestre. Applying the software development knowledge, such as design patterns and life cycles, system construction was made from the use of some frameworks, as Doctrine and Foundation, and the PHP language, widespread in the web development community , added to the DBMS MySQL, culminating in a system that meets the needs previously raised. Key-words: Development. Web Programming. Database. PHP.

LISTA DE FIGURAS FIGURA 1: ARQUITETURA CLIENTE/SERVIDOR VIA INTERNET. ........................ 20 FIGURA 2: PROCESSO DE ANÁLISE E SÍNTESE. ................................................. 22 FIGURA 3: EXEMPLO DE MODELO ENTIDADE-RELACIONAMENTO .................. 27 FIGURA 4: EXEMPLOS DE MODELOS LÓGICOS. ................................................. 28 FIGURA 5: FLUXO DE PROTOTIPAÇÃO................................................................. 29 FIGURA 6: OUTRO FLUXO DE PROTOTIPAÇÃO. .................................................. 30 FIGURA 7: ANALOGIA DO FACADE. ....................................................................... 32 FIGURA 8: TELA DE USO DO DIARION, DASHBOARD DE TURMA. ..................... 41 FIGURA 9: TELA DE USO DO PROFESSOR TECH II. ............................................ 42 FIGURA 10: IMAGEM DO USO DO DAYPO ONLINE. ............................................ 43 FIGURA 11: TELA DE USO DO FET. ....................................................................... 44 FIGURA 12: COMPARATIVO ENTRE AS FUNCIONALIDADES DO SISTEMA....... 45 FIGURA 13: MODELO BASE DO IMESTRE............................................................. 49 FIGURA 14: LÓGICA DO NÚCLEO PHP .................................................................. 52 FIGURA 15: TELA DE LOGIN IMESTRE .................................................................. 55 FIGURA 16: TELA INICIAL DO IMESTRE ................................................................ 55 FIGURA 17: TELA DE LISTAGEM DE TURMAS CADASTRADAS. ......................... 56 FIGURA 18: TELA DE LANÇAMENTO DE FREQUÊNCIAS E SUA IMPRESSÃO. . 56 FIGURA 19: INSERÇÃO DE QUESTÕES EM AVALIAÇÃO E SUA IMPRESSÃO. .. 57 FIGURA 20: TELA DE CADASTRO DE QUESTÕES. .............................................. 57 FIGURA 21: TELA RESPONSIVA DE CADASTRO DE NOVO USUÁRIO. .............. 58 FIGURA 22: EXEMPLO DE RELATÓRIO APRESENTADO AO FINAL DE BATERIA DE TESTE BETA. ............................................................................................... 59

LISTA DE QUADROS QUADRO 1: PADRÕES DE PROJETO. ................................................................... 31 QUADRO 2: VALIDAÇÃO DOS REQUISITOS. ........................................................ 54

SUMÁRIO 1. INTRODUÇÃO ...................................................................................................... 13 1.1.

Considerações Iniciais ................................................................................. 13

1.2.

Justificativa ................................................................................................... 13

1.3.

Problema de Pesquisa ................................................................................. 13

1.4.

Hipótese ....................................................................................................... 13

1.5.

Objetivos ...................................................................................................... 13

1.5.1. Geral ......................................................................................................... 13 1.5.2. Específicos................................................................................................ 14 1.6.

Metodologia .................................................................................................. 14

1.6.1. Classificação da Pesquisa ........................................................................ 14 1.6.2. Metodologia de Trabalho .......................................................................... 14 1.7.

Estrutura do Trabalho................................................................................... 16

2. REVISÃO DA LITERATURA .............................................................................. 17 2.1.

O PROFESSOR E SUAS FUNÇÕES .......................................................... 17

2.2.

SOFTWARE ................................................................................................. 18

2.2.1. O que é software? ..................................................................................... 18 2.2.2. Tipos de Software ..................................................................................... 18 2.2.3. Aplicações Web ........................................................................................ 18 2.3.

SERVIDOR .................................................................................................. 19

2.4.

ARQUITETURA CLIENTE/SERVIDOR ........................................................ 19

2.6.

ENGENHARIA E MODELAGEM DE SISTEMAS ......................................... 22

2.6.1. O que é Engenharia de Software .............................................................. 22 2.6.2. Modelos de Processos .............................................................................. 23 2.6.3. O Modelo Incremental ............................................................................... 24 2.6.4. Análise de Requisitos ............................................................................... 25 2.6.5. Modelagem de Base de Dados ................................................................. 26 2.6.6. Prototipação .............................................................................................. 28 2.6.7. Padrões de Desenvolvimento ................................................................... 30 2.6.8. Unified Modeling Language (UML) ........................................................... 33 2.6.9. Orientação a Objetos ................................................................................ 35 2.6.10. Linguagem PHP..................................................................................... 35 2.6.11. Testes de Software ................................................................................ 36 2.6.12. Documentação e Treinamento .............................................................. 38 3. ESTADO DA ARTE ............................................................................................ 41 4. MODELAGEM E IMPLEMENTAÇÃO DO IMESTRE .......................................... 46 4.1.

ENGENHARIA DE REQUISITOS ................................................................ 46

4.1.1. Descrição do minimundo........................................................................... 46 4.1.2. Método de Elucidação dos Requisitos ...................................................... 47 4.2.

MODELAGEM DE DADOS .......................................................................... 47

4.2.1. Modelo Conceitual .................................................................................... 47 4.2.2. Modelo Lógico........................................................................................... 47 4.3.

MODELAGEM UML ..................................................................................... 47

4.3.1. Diagrama de Casos de Uso ...................................................................... 47 4.3.2. Diagrama de Classes ................................................................................ 48 4.4.

PROTOTIPAÇÃO ......................................................................................... 48

4.4.1. Alguns protótipos ...................................................................................... 48 4.5.

DESENVOLVIMENTO ................................................................................. 49

4.5.1. Implementação da base de dados ............................................................ 49 4.5.2. Implementação e uso do Doctrine ............................................................ 49 4.5.3. Implementação e uso do Foundation ........................................................ 50 5. TESTES .............................................................................................................. 54 5.1.

VALIDAÇÃO ................................................................................................. 54

5.2.

TESTES DE SISTEMA................................................................................. 54

5.3.

AMOSTRAGEM ........................................................................................... 58

5.4.

TESTES DE ACEITAÇÃO ............................................................................ 59

6. CONSIDERAÇÕES FINAIS ................................................................................ 60 6.1.

CONCLUSÕES ............................................................................................ 60

6.2.

LIMITAÇÕES DO PROJETO ....................................................................... 61

6.3.

TRABALHOS FUTUROS ............................................................................. 61

Referências ............................................................................................................... 62 APÊNDICE A – Análise de Requisitos ...................................................................... 64 APÊNDICE B – Modelo Conceitual da Base de Dados ............................................. 67 APÊNDICE C – Modelo Lógico da Base de Dados ................................................... 68 APÊNDICE D – Diagramas de Caso de Uso............................................................. 69 APÊNDICE E – DIAGRAMA DE CLASSES .............................................................. 72

13

1. INTRODUÇÃO 1.1.

Considerações Iniciais É difícil encontrar uma ferramenta baseada em computadores que auxilie

as atividades básicas de um professor. A maioria é paga ou, quando gratuita, possui limites que impossibilitam a sua real utilização. Esse panorama pode ser visto na tabela comparativa apresentada na sessão 3.6 do Estado da Arte. 1.2.

Justificativa As atividades cotidianas de um professor consistem em: planejar e ministrar

aulas, construindo materiais a serem usados em sala, como apresentações ou apostilas; preparar e corrigir avaliações, sejam elas escritas ou não, em grupo ou individuais. É por meio delas que o professor qualifica e mensura o nível de aprendizagem dos seus alunos; e administrar resultados, de forma clara, para que os seus estudantes possam saber onde erraram e onde devem melhorar. A proposta do sistema é auxiliar o professor em tais atividades, automatizando algumas funções e facilitando outras. Dessa forma, o professor poderá despender tempo em outras atividades que incrementem seu potencial didático. 1.3.

Problema de Pesquisa Será viável o desenvolvimento de um sistema que auxilie professores em

suas atividades cotidianas, que seja baseado na web e não necessite de nenhuma instalação em seus computadores pessoais? 1.4.

Hipótese É possível desenvolver um sistema que auxilie professores em suas

atividades através do uso da linguagem de programação PHP, juntamente com a linguagem de estilos CSS e a base de dados MySQL. Para auxiliar o uso de tais ferramentas, os frameworks Doctrine e Foundation possuem uma grande importância, agilizando a construção do aplicativo. 1.5.

Objetivos

1.5.1. Geral Desenvolver uma aplicação com base na web que auxilie professores a realizar atividades básicas do exercício de sua função.

14

1.5.2. Específicos •

Elucidar requisitos para um sistema que supra as funções básicas de

um professor.

1.6.

•

Desenvolver o sistema segundo os padrões de Engenharia de Software.

•

Testar o sistema desenvolvido.

Metodologia A metodologia aplicada na construção deste projeto foi amplamente

discutida com o orientador, para que pudesse atender as demandas científicas da melhor forma possível. 1.6.1. Classificação da Pesquisa A natureza do projeto é predominantemente qualitativa, já que efetua mensurações de variáveis. A finalidade aplicada a desenvolvimento web do projeto deve-se por ter um produto final o lançamento de um aplicativo. Possui também uma etapa que consiste em pesquisa de campo, já que alguns professores foram entrevistados, de forma transversal, coletando dados de vários indivíduos diferentes num mesmo momento. 1.6.2. Metodologia de Trabalho O começo de um projeto de desenvolvimento é a Engenharia de Requisitos, onde o desenvolvedor irá elucidar todas as necessidades que serão atendidas pelo sistema a ser desenvolvido. Após a conclusão da Análise [1], produto final da Engenharia de Requisitos, é iniciada a construção do modelo da base de dados que irá suprir a necessidade dessa aplicação. Essa modelagem se divide em duas partes: Conceitual e Lógica. A Conceitual é de alto nível, mostrando os relacionamentos entre as entidades que compõe a base. A Lógica já mostra dados pertinentes aos tipos de dados que cada atributo irá armazenar. Concluída a etapa anterior, inicia-se o processo de Prototipação do programa [2]. Nesta fase, o desenvolvedor irá “desenhar” as interfaces que serão implementadas futuramente, para que seja possível pensar de forma mais objetiva todo o fluxo, a navegação, do sistema, e prevenir que erros de interface aconteçam

15

num estágio mais avançado da implementação, quando serão muito mais complicados de se corrigir. Após debatida a Interface do aplicativo, já é possível iniciar a implementação [3]. Nesta etapa, o desenvolvedor irá criar a codificação. Neste trabalho, foi escolhida a linguagem de programação PHP, juntamente com o SGBD MySQL. Esses dois, em conjunto, formam um pacote básico amplamente utilizado para desenvolvimento em Plataforma Web. O PHP possui uma comunidade de usuários muito grande e ativa, permitindo que se encontre muito material para estudo. O MySQL é gratuito e suficientemente robusto para atender a demanda do sistema. Para auxiliar o desenvolvimento, dois frameworks foram selecionados. Um deles é o Doctrine, que permite o Mapeamento Objeto Relacional, criando e gerenciando uma camada de persistência no aplicativo. O segundo framework é o Foundation, que facilita a construção de sites responsivos através de uma biblioteca CSS simples, intuitiva e fácil de usar. Em nível estrutural, dois padrões foram escolhidos para serem implementados no desenvolvimento. O primeiro é o n-Camadas, onde foram escolhidas 3 camadas: Uma visual, para a aplicação; Uma Intermediária, que mantém a lógica de negócio do sistema; E uma terceira, para persistência. O Doctrine que ocupa essa terceira camada, facilitando o trabalho do desenvolvedor que não necessita criar a maioria dos scripts do CRUD diretamente. O segundo padrão é o Facade (Fachada), que está implementada na segunda camada do sistema, permitindo que as funcionalidades do sistema tenham uma interface simplificada, intermediando a comunicação entre a Interface da aplicação e os dados na base de dados, aplicando as regras de negócio que forem necessárias. Concorrente a todas essas está o Modelo de Ciclo de Vida [4] que é utilizado no trabalho, chamado de Incremental. Por meio dele é possível efetuar correções em todo o projeto sem ter que voltar todo o processo ao início.

16

1.7.

Estrutura do Trabalho O segundo capítulo apresenta alguns aplicativos que executam funções

úteis às atividades cotidianas de um professor, comparando-as com o objetivo de mensurar as funcionalidades implementadas em cada uma e como elas poderiam ser melhoradas. O terceiro capítulo elucida os conhecimentos utilizados que viabilizaram a construção do aplicativo. Termos técnicos, padrões e métodos foram explicados nele. O quarto capítulo mostra os ativos construídos durante a implementação do projeto, como Documento de Requisitos, Diagramas em geral, etc. O quinto capítulo demonstra os resultados dos testes aplicados ao sistema, a fim de comprovar que o mesmo atendeu à demanda para qual foi projetado.

17

2. REVISÃO DA LITERATURA 2.1.

O PROFESSOR E SUAS FUNÇÕES O Professor (ou docente) é uma pessoa que tem como profissão repassar

o conhecimento. Requer qualificações acadêmicas e pedagógicas para que consiga transmitir tal conhecimento da melhor forma possível. É considerada uma das profissões mais antigas e respeitadas do mundo, por ser responsável pela formação do cidadão, como afirmava Platão (380 a.C.). Segundo Freire (2002), ensinar é fazer com que o educando consiga discernir novos padrões de vida, de pensar e agir, podendo aplica-las da forma que lhe for mais coerente da resolução de seus problemas cotidianos. O autor também afirma que o educador deve ter liberdade para expressar suas opiniões, mas sem esquecer de mostrar todas faces de um determinado ponto, pois este pode ser visto de diversos ângulos, em formas diferentes, evitando assim manipular as conclusões que devem ser inerentes única e exclusivamente dos alunos. As funções básicas de um professor, descritas em Brasil (1996), são:  Participar da elaboração da proposta pedagógica do estabelecimento de ensino;  Elaborar e cumprir plano de trabalho, segundo a proposta pedagógica do estabelecimento de ensino;  Zelar pela aprendizagem dos alunos;  Estabelecer estratégias de recuperação para os alunos de menor rendimento;  Ministrar os dias letivos e horas-aula estabelecidos, além de participar integralmente dos períodos dedicados ao planejamento, à avaliação e ao desenvolvimento profissional;  Colaborar com as atividades de articulação da escola com as famílias e a comunidade. Todas essas atividades exigem muito tempo do profissional. Seus contratos têm como base as aulas que são ministradas, no sistema de 20/40/60 horas-aula semanais. Porém, sabe-se que a maior parte do trabalho é feito fora das salas, como planejar aulas e corrigir avaliações. Esse exercício demanda muito mais tempo do que

18

as atividades em classe. Pode-se dizer então que o professor é um profissional de tempo integral, mesmo que seu contrato diga que o mesmo trabalha apenas por vinte horas por semana. 2.2.

SOFTWARE Este item tem como objetivo explicar o que é uma das partes mais

importantes do funcionamento lógico de um computador. 2.2.1. O que é software? Segundo Norton (2006), software é um conjunto de instruções que faz o computador executar tarefas. Simplificando, o software diz ao computador o que fazer. 2.2.2. Tipos de Software Segundo Velloso (2011), existem dois grandes grupos para separar os tipos de software: Do Fabricante e Do Usuário. Os Softwares do Fabricante, em geral, são divididos em Sistemas Operacionais e Programas Utilitários. O primeiro gerencia a criação e manutenção de arquivos, controla os periféricos básicos e permite a execução de utilitários em geral, além de prover um certo nível de segurança nos dados. Já o segundo, são aplicativos que acompanham o Sistema Operacional, auxiliando nas suas tarefas. Os Softwares do Usuário, também chamados de “Aplicativos” podem ser divididos em diversos tipos, como editores de texto, jogos, executores de multimídia, etc. e são criados por empresas ou usuários sem relação direta com o Sistema Operacional, executando uma determinada tarefa, necessária ou não para o bom funcionamento do computador. O iMestre, sistema desenvolvido no presente projeto, se encaixa na categoria de Software Aplicativo, mais especificamente, é um Aplicativo Web. 2.2.3. Aplicações Web Segundo Pressman (2006), Aplicativos Web cobrem uma gama de aplicações, variando desde um conjunto de arquivos ligados por hipertexto até ambientes computacionais complexos, interligados a bases de dados e aplicações externas.

19

Em geral são executados pelos navegadores web e, quase sempre, necessitam de uma conexão ativa com a Internet para serem utilizados e/ou atualizados. 2.3.

SERVIDOR Conforme afirma Morimoto (2008), servidor é uma máquina que permanece

ligada o tempo inteiro, sempre executando uma mesma rotina. Existem vários tipos de servidores e cada um dele executa um serviço, que nesse caso significa um aplicativo que irá responder as requisições de um cliente. Morimoto (2008) divide os servidores em dois grandes grupos: Locais e Internet. O primeiro grupo, Servidores Locais, é composto basicamente por:  Proxy: Intermediário entre a rede local e uma rede externa, otimizando conexão ou controlando acesso;  DHCP: Automatiza configurações de rede;  DNS: Atribui nomes a cada endereço lógico da rede;  Firewall: Proteger a rede interna de acessos externos indevidos;  Arquivos: Compartilhar Arquivos;  Impressão: Compartilhar uma ou mais impressoras; O segundo grupo, Servidores da Internet, são os serviços locais configurados em larga escala, e o Servidor Web, que serve para gerenciar um site. O servidor a ser utilizado no projeto proverá o serviço de web. Morimoto (2008) descreve o Servidor Web como “a espinha dorsal da Internet”. São esses servidores que hospedam todos os sites e Aplicativos Web. 2.4.

ARQUITETURA CLIENTE/SERVIDOR Arquitetura de Aplicação, segundo Kurose e Ross (2006), determina como

a aplicação é organizada, dividindo as funções e cargas que são executas por ela. As arquiteturas modernas mais utilizadas são: Cliente/Servidor, P2P (Ponto-a-Ponto) e Híbrida (Cliente/Servidor + P2P). A Arquitetura Cliente/Servidor é uma arquitetura onde cada componente do sistema possui uma função específica: Ou ele provê um serviço ou usa o serviço disponibilizado por outros. Segundo Marçula e Benini Filho (2008), o servidor é um

20

computador potente e dedicado somente à tarefa oferecida enquanto o cliente é o terminal acessado pelos usuários, conectados ao servidor através de uma rede. No caso do iMestre, essa rede é a Internet. A abstração dessa estrutura pode ser vista na Figura 1. Figura 1: Arquitetura Cliente/Servidor via Internet.

Fonte: Próprio Autor.

A Arquitetura Cliente/Servidor é amplamente utilizada em serviços disponibilizados na Internet, pois atende a necessidade de confiabilidade e a escalabilidade dos sistemas. Segundo Tanembaum (2003), ela é amplamente utilizada, aplicável quando o cliente e o servidor estão no mesmo local geográfico, mas também quando estão muito distantes. Para adicionar um novo cliente, basta conectá-lo e acessar o sistema, já que esse não “perceberá” a presença de outros clientes utilizando o mesmo aplicativo. Essa arquitetura tem como características o desvinculo com meio de comunicação, escalabilidade, alto custo de implantação, tráfego de rede reduzido, centralização de controle e segurança. Como desvantagens desse modelo, Kurose e Ross (2006) cita as instabilidades resultantes da inaptidão do servidor de lidar com grandes ou muitas requisições simultâneas. 2.5.

N-Camadas Para solucionar o problema do fluxo de dados entre os componentes de um

sistema, é proposto uma estrutura que divida o mesmo em várias camadas onde, para aumentar o acoplamento entre as camadas, uma só poderá se comunicar com a

21

camada vizinha. Um exemplo de arquitetura em camadas é a Máquina Virtual do Java, que isola os níveis mais baixos de hardware. Segundo Braude (2005) um sistema dividido em camadas não permite que duas camadas tenham utilização recíproca, apenas relacionamento unilateral. Essa arquitetura pode simplificar o processo de implementação de um software, através do compartilhamento de camadas e a independência entre elas. Apresenta como vantagens a possibilidade de reuso, o suporte simplificado a implementação de padronizações e a intercambialidade. Já como desvantagem, pode-se citar a menor eficiência causada pelo overhead das múltiplas camadas. A arquitetura em três camadas é um dos modelos n-camadas, dividindo o sistema em três partes: Apresentação, Lógica de Negócio e Dados ou Persistência. O artigo de Santos (2005) apresenta essa mesma divisão, demonstrando que a arquitetura lógica em três camadas pode ser aplicada em quaisquer sistemas, independente do porte do mesmo. Ela atende à demanda de separação entre as etapas da construção dos objetos tratados pelo sistema, além de potencialmente aumentar o desempenho do mesmo. A camada de Persistência é responsável pela inserção e recuperação dos dados no SGBD responsável pelo gerenciamento do banco de dados da aplicação. Também é nessa camada que os objetos básicos do sistema devem ser criados, simulando um Mapeamento Objeto Relacional, permitindo a camada de Lógica trabalhar exclusivamente orientada a objetos. A camada de Lógica de Negócios pode ser considerada como o coração e a mais importante das três, pois é nela que todo o processamento é executado, tanto para serem armazenados na base de dados quanto para serem apresentados ao usuário. A camada de Apresentação irá implementar a GUI (Graphical User Interface), que é responsável pela interação do usuário com o sistema. Graças a independência das camadas, essa apresentação pode ser desenvolvida para qualquer plataforma (web, desktop ou mobile) a partir de uma única camada de Lógica de Negócio.

22

2.6.

ENGENHARIA E MODELAGEM DE SISTEMAS Este item tem como objetivo elucidar informações inerentes as etapas que

constituem o projeto e a modelagem de um software. 2.6.1. O que é Engenharia de Software Segundo Pfleeger (2004), Engenharia de Software é o processo de utilizar os conhecimentos do engenheiro nas áreas de computação para ajudar a resolver problemas. O processo de construção da Engenharia de Software é iniciado a partir da análise. Essa etapa divide o problema em menores partes, mais simples de serem compreendidas e manipuladas. Subsequente a essa atividade, inicia-se o processo de síntese, que consiste em elaborar uma solução para cada uma das menores partes e unifica-los em uma estrutura maior. Esse processo é exemplificado na Figura 2. Figura 2: Processo de Análise e Síntese.

Fonte: Próprio Autor, baseado em Pfleeger.

23

Para resolver cada um dos problemas, é utilizado um método, o processo formal para produzir um resultado. Para auxiliar esse processo existem as ferramentas, possibilitando a realização de determinada tarefa da melhor forma possível. A união entre métodos e ferramentas é chamado de procedimento, algo semelhante a uma receita. Aliado ao procedimento, existem os paradigmas que podem ser ilustrados como uma determinada forma de se executar uma ação. Para melhor compreensão, pode-se utilizar as seguintes comparações: Na culinária, preparar um molho de tomate é um método, utilizar uma panela de adequada para molhos é uma ferramenta. A combinação entre a receita do molho, a escolha das panelas e colheres forma um procedimento. E o estilo de fazer o molho, seja italiano ou árabe, pode ser comparado com o paradigma. 2.6.2. Modelos de Processos Processo, segundo Paula Filho (2009), é uma receita a ser seguida por um projeto. Este, por sua vez, concretiza uma abstração. O autor também alerta sobre o cuidado para não confundir processo com sua execução ou o produto por ele confeccionado. Já Pfleeger (2004) descreve processo como uma série de etapas, atividades, restrições e recursos para se alcançar uma determinada saída. Para Silva (2010), o processo define a sequência que os métodos serão aplicados, como os produtos serão entregues, controlando a sua qualidade e os marcos que identificam cada uma dessas etapas, permitindo o monitoramento do progresso. Dessa forma, o processo uniformiza a construção de um “Produto de Software”. Sendo assim, um processo de desenvolvimento de software tem como ponto de partida a escolha de um modelo de ciclo de vida, onde o mais caótico é chamado de “codifica-remenda” por Paula Filho (2009). Nesse “modelo”, os desenvolvedores começam imediatamente a codificar, corrigindo (remendando) os erros à medida que vão surgindo.

24

Sommerville (2007) ainda discute os modelos básicos do processo de desenvolvimento de software, citando três modelos: Cascata, Evolucionário e Baseado em componentes. O modelo Cascata separa as atividades fundamentais do processo em fases distintas, sendo necessário, assim, recomeçar o processo desde o início quando algo corresponde as expectativas do cliente. A construção de uma parede é um bom exemplo deste modelo pois, caso a parede não fique correta, é necessário recomeçar o planejamento desde o início. O modelo Evolucionário tem como característica principal a alta velocidade de confecção de uma primeira versão do software, que deverá ser refinada pelo cliente. A mesma parede usada no exemplo do Cascata, depois de pronta, pode ser usada como exemplo no modelo Evolucionário. Quando se inicia o acabamento da parede, faz-se primeiramente o reboco, para depois prepara-la para receber as demãos de tinta e, finalmente, é pintada várias vezes, a depender da qualidade da tinta e do gosto do cliente. O último modelo básico, Baseado em Componentes, tem como foco a integração entre diversos componentes já prontos e reusáveis. Algo que pode exemplificar esse modelo é um carro. O carro é composto por vários componentes diferentes, fabricados em várias partes do mundo e montados nas fábricas montadoras, de forma que cada componente desse seja integrado ao outro formando um único sistema funcional. 2.6.3. O Modelo Incremental Um dos processos mais utilizados atualmente no mercado é o Desenvolvimento em Fases, também conhecimento como Modelo Incremental. Nesse modelo, o sistema é subdividido em subsistemas, agrupados por funcionalidades. Esse modelo apresenta como vantagem a possibilidade de se desenvolver mesmo que os requisitos não estejam apresentados de forma clara. Outra vantagem é a possibilidade de já poder utilizar parcialmente funções básicas do sistema, postergando outros aprimoramentos. Ainda tem como vantagens a facilidade de lidar com erros do sistema e reduz o tempo de desenvolvimento do software.

25

Em contrapartida, as desvantagens são o porte de cada etapa do desenvolvimento, que devem ser pequenas; possíveis problemas relacionados a arquitetura do sistema, que devem ser manipulados e “contornados” posteriormente. 2.6.4. Análise de Requisitos Requisitos, segundo Cegalla (2005), são condições necessárias ou exigências de algo. No contexto da Ciência da Computação, segundo Pfleeger (2004), requisito é uma característica do sistema ou algo que ele é capaz de realizar. Para Paula Filho (2009), o conceito de qualidade só é atendido quando o enunciado de um requisito é:  Correto: Todo requisito é um requisito do produto a ser construído;  Preciso: Cada requisito possuir uma única interpretação;  Completo: O requisito reflete todas as decisões da especificação e não contém pendência alguma;  Consistente: Não existem conflitos entre subconjuntos de requisitos;  Priorizado: Cada requisito é classificado de acordo a sua importância e estabilidade;  Verificável: O requisito deve ser verificável através de um processo finito que possa ser executado por uma pessoa ou máquina;  Modificável: Permite a mudança de qualquer requisito, de forma simples e suprindo todas as necessidades de qualidade;  Rastreável: Permite a determinação dos processos anteriores e as suas consequências. A primeira etapa do processo de desenvolvimento de software, independente do modelo que foi escolhido, é a Engenharia de Requisitos. Esse processo é dividido em quatro grandes etapas, segundo Sommerville (2007): • Estudo de viabilidade: Analisa se o sistema proposto terá um custo adequado comercialmente e se pode ser desenvolvido com o orçamento atual. • Elicitação e análise de requisitos: Derivação dos requisitos através da observação de sistemas semelhantes e entrevistas com usuários e clientes. Essa etapa auxilia o analista a compreender o sistema a ser especificado.

26

• Especificação de requisitos: Traduzir as informações coletadas em um documento, separando e diferenciando os requisitos de usuário e os requisitos de sistema. • Validação de Requisitos: Verificar a qualidade dos requisitos e, caso necessário, modifica-los para a forma mais adequada. Os requisitos são divididos em dois grandes grupos: Usuário e Sistema. O primeiro são declarações ilustradas dos serviços que são esperados do sistema e as restrições as quais eles devem atender. O segundo grupo define em detalhes as funções, serviços e restrições do sistema e deve definir exatamente o que será implementado. Outras subdivisões desses grupos maiores são referentes ao “domínio” que cada requisito irá especificar. São elas: 

Funcionais, onde declaração os serviços que o sistema deve fornecer ou

aquilo que ele não irá fornecer; 

Não-funcionais, restrições sobre os serviços oferecidos, aplicados em

geral ao sistema como um todo; 

Domínio, que são provenientes do domínio onde a aplicação está

alocada e podem ser associados aos funcionais ou não-funcionais, a depender da situação. 2.6.5. Modelagem de Base de Dados 2.6.5.1. O que é Banco de Dados? De forma genérica, Elmasri e Navathe (2011) definem banco de dados como uma coleção de fatos conhecidos, que podem ser registrados e organizados, tendo significado implícito, chamados de dados. Esses dados devem estar relacionados. De forma mais específica, uma base de dados representa um aspecto do mundo real, chamado de minimundo. Os dados inseridos neles devem ter uma lógica coerente, atendendo a demanda que foi projetado e servindo como fonte de informação relevante para a finalidade que foi projetado.

27

2.6.5.2. Sistemas Gerenciadores de Bancos de Dados Um Sistema Gerenciador de Banco de Dados, ou SGBD, segundo Silberschatz et al. (1999) tem como objetivo principal proporcionar um ambiente conveniente e eficiente, tornando possível recuperar e armazenar as informações do banco de dados. No caso do iMestre, o SGBD escolhido é o MySQL. Esse SGBD é extremamente leve, gratuito e utilizado em cerca de 15 milhões de aplicações ao redor do mundo, entre elas o Facebook, que conta com uma base de dados que atende mais de 1 bilhão de usuários. Além disso, o MySQL tem suporte a diversas linguagens de programação, possibilitando a confecção de diversas aplicações com diferentes aplicabilidades (como um aplicativo para Smartphones e uma aplicação Web). 2.6.5.3.

Modelo Entidade Relacionamento O Modelo Entidade Relacionamento (MER), também conhecido como

Modelo Conceitual, segundo Machado e Abreu (2012), demonstra esquemas puramente conceituais sobre a essência dos relacionamentos do minimundo que está sendo projetado. Esse modelo não demonstra procedimentos ou fluxo de dados. A Figura 3 exemplifica um MER simples, onde a entidade “Pessoa” tem um relacionamento com a entidade “Dependente”. A cardinalidade dele demonstra que uma pessoa pode ter nenhum (0) ou vários (n) dependentes. Figura 3: Exemplo de Modelo Entidade-Relacionamento

Fonte: Próprio Autor.

2.6.5.4.

Modelo Lógico O Modelo Lógico, segundo Heuser (2009), é uma descrição de uma base

de dados que depende do SGBD escolhido para atender a aplicação, pois nesta modelagem já é mostrada cada um dos tipos de dados que os atributos irão ter e suas dimensões. A Figura 4 exemplifica dois tipos de modelos lógicos. O Modelo A demonstra uma representação dos dados em alto nível, compreensível a qualquer

28

leitor sem que seja necessário o conhecimento da ferramenta que irá gerenciar a base de dados. Já o Modelo B está vinculado ao SGBD, utilizando a nomenclatura que o mesmo aceita para cada tipo de dado. Neste caso, a nomenclatura é a do MySQL. A cardinalidade é novamente apresentada, significando que esse modelo é um mapeamento do MER. Figura 4: Exemplos de Modelos Lógicos.

Fonte: Próprio Autor

2.6.5.5.

Linguagem SQL A definição de Damas (2007) para a linguagem SQL é uma linguagem com

objetivo de manipulação de dados, servindo de interface entre o usuário dos dados e o SGBD. Ela implementa os conceitos do Modelo Relacional, possibilitando criar, alterar e remover elementos de um banco de dados; consultar e controlar acessos ao banco; e garantir consistência e integridade. 2.6.6. Prototipação Prototipação, segundo Gustafson (2003), é um modelo de ciclo de vida que permite ao desenvolvedor criar um modelo do software que será implementado, numa versão descartável, visando testar conceitos e requisitos. Para o cliente, os protótipos são relevantes pois permitem uma avaliação mais “palpável” do que será desenvolvido. É através deles o cliente poderá analisar conteúdos que serão apresentados, onde eles serão inseridos. Dependendo do nível do protótipo, até cores, fontes do texto, etc. Por meio dessa análise, diversas falhas,

29

sejam de comunicação, interpretação ou planejamento serão descobertas e sanadas, em tempo hábil, evitando maiores impactos no projeto. Segundo Pressman (2006), protótipos podem ser apresentados em três formas distintas:  Protótipo de papel ou digital de baixa qualidade, que retrata a interação homem-computador, capacitando o usuário a entender quanta interação irá acontecer no decorrer do uso;  Protótipo de trabalho, que implementa um subconjunto de uma função exigida pelo software;  Programa que execute parte ou toda a função desejada, mas com evoluções pendentes que não irão modificar a rotina de execução do mesmo. Como é apresentado na Figura 5, o protótipo deve ser avaliado pelo cliente e/ou usuários do sistema, a fim de que ele seja o mais próximo da realidade possível. Após isso que se inicia a real construção do aplicativo. Figura 5: Fluxo de Prototipação.

Fonte: Pressman adaptado por Dilonei Grando.

30

Outro exemplo pode ser visto na Figura 6, onde o fluxo é apresentado de forma circular, representando a constante evolução e retorno ao começo que acontece no processo. Figura 6: Outro Fluxo de Prototipação.

Fonte: DEM/INPE.

2.6.7. Padrões de Desenvolvimento Padrões de Projeto, aqui chamados de Padrões de Desenvolvimento, são soluções padronizadas que visam resolver um determinado problema que ocorre com frequência no contexto de projeto de software. Segundo Gamma et al. (2007), um padrão tem quatro elementos essenciais: Nome; Problema, que descreve quando aplicar o padrão; Solução, descrevendo os elementos de forma abstrata e um arranjo base para os elementos que o compõe; Consequências, descrevendo o “custo-benefício” da aplicação desse padrão. Os padrões podem ser separados segundo o seu Propósito (Criação, Estrutural ou Comportamental) ou segundo seu Escopo (Classe ou Objeto). Os padrões de Criação são aqueles que tem como objetivo abstrair o processo de criação dos respectivos objetos. Esses padrões se tornam importante no decorrer da evolução do sistema pois o deixa menos depende de heranças, permitindo uma maior composição e relacionamento entre objetos. O padrão mais famoso desse grupo é o Fábrica, fornecendo uma interface única para criação de diversos objetos,

31

dependentes entre si, sem especificar as classes concretas. Outro padrão amplamente utilizado desse grupo é o Instância Única, que garante que uma classe tenha uma única instância e tenha o ponto de acesso único. Os padrões Estruturais são os que se preocupam com a forma que classes e objetos são organizados para formar estruturas maiores. Os padrões mais utilizados são o Adaptador, que permite a conversão de uma interface de classe em outra completamente diferente, possibilitando que elas trabalhem juntas; e o Fachada, que fornece uma interface unificada para um conjunto de interfaces. O último grupo, chamados de Comportamentais, se responsabilizam pelo algoritmo e a atribuição de responsabilidades entre os objetos. O principal padrão desse grupo é o Cadeia de Responsabilidade, que cria uma sequência de objetos que podem (ou não) executar uma determinada tarefa. Tal tarefa é passada de um objeto a outro até que chegue em um que saiba como executá-la. Outros também muito utilizados são o Comando, que encapsula as solicitações de um objeto através de um terceiro, permitindo assim um melhor monitoramento das atividades; e o Observador, que cria uma dependência entre vários objetos a partir de um único que, quando este muda de estado, os dependentes são notificados e atualizados. O Quadro 1, Gamma et al. (2007) apresenta a organização dos padrões conhecidos, segundo seu propósito e escopo. Quadro 1: Padrões de Projeto. Propósito

Escopo

Classe

Criação

Estrutural

Comportamental

Fábrica

Adaptador

Interpretador Template

Objeto

Fábrica Abstrata

Adaptador

Cadeia de Responsabilidade

Construtor

Ponte

Comando

Protótipo

Compositor

Iterator

Instância Única

Decorador

Mediador

Fachada

Memento

FlyWeight

Observador

Proxy

Estado Estratégia Visitante

Fonte: Adaptado de Gamma, Helm. 2007.

32

No atual projeto, será utilizado o padrão Facade. Juntamente com este padrão, será implementada a arquitetura 3-Camadas. 2.6.7.1.

Facade O Padrão Facade, ou Fachada, é um padrão que visa ocultar as classes

mais internas do sistema, minimizando a comunicação e as dependências entre subsistemas. Segundo Freeman e Freeman (2007), este padrão fornece uma interface simples e unificada para um conjunto de interfaces de diferentes subsistemas. Para a aplicação cliente acessar um método de uma classe é necessário o uso de uma Interface secundária chamada de Fachada. É por meio dela que o acesso aos métodos da classe é feito. A Figura 7 apresenta uma analogia do Facade, demonstrando o ponto único de acesso. Figura 7: Analogia do Facade.

Fonte: Marcos Brizeno, baseado em GAMMA (2007).

Este padrão permite o reuso facilitado de códigos e, graças a divisão das funções em várias classes, facilita também a descoberta de erros e a modularização do sistema, permitindo a programação de funções diferentes ao mesmo tempo, por mais de uma pessoa. Para Gamma et al. (2007), as vantagens do uso do Facade estão no isolamento dos componentes do subsistema, reduzindo assim o número de objetos a serem manipulados; fraqueza do acoplamento entre clientes e subsistemas; não impedimento do uso das classes do subsistema, caso necessário. Já Braude (2005) cita como desvantagens do Fachada a proibição de mencionar classes que fazem parte do conjunto de classes que a fachada faça parte, usando apenas a classe de fachada como ponto de contato. Outra desvantagem é o

33

esforço adicional para tornar os métodos das classes englobadas pela fachada acessíveis aos usuários dela, mesmo que não haja nenhum processamento no valor que é repassado pela função. 2.6.8. Unified Modeling Language (UML) UML é definida como uma linguagem padrão para elaborar a estrutura de um projeto de software. Booch (2005) afirma que ela é adequada para modelagem de sistemas, além de destinada a visualização, especificação, construção e documentação de tais sistemas. No quesito visualização, a UML é utilizada de tal forma que um desenvolvedor possa escrever o modelo de seu sistema para que qualquer outro desenvolvedor ou ferramenta seja capaz de interpretá-la. No quesito especificação, a UML é abrangente pois seus diagramas são precisos e sem ambiguidades, impedindo que haja mais de uma interpretação das funções a serem executadas no aplicativo. O autor Fowler (2005) afirma que o maior valor da UML está na comunicação e no entendimento, já que um bom diagrama ajuda a transmitir as ideias sobre o projeto, melhorando a compreensão de todo o fluxo que irá acontecer no software. Mesmo sendo um conjunto considerável de diagramas que auxiliam na definição de uma aplicação como um todo, outros diagramas, não contidos na UML também podem ser utilizados, desde que seja mais vantajoso. Alguns diagramas da UML tendem a ser complexos demais, tornando-os irrelevantes, a depender da complexidade do software que é estruturado. Segundo a classificação mostrada por Lima (2008), a UML possui dez diagramas, separados em dois grupos:  Diagramas Estruturais: Descrevem elementos da estrutura que compõe o sistema. Os mais importantes são: o

Classe: Mostra o conjunto de classes, com seus atributos e

métodos, além de seus relacionamentos;

34

o

Componente: Indica os componentes externos utilizados no

sistema e seus relacionamentos; o

Implantação: Demonstra características físicas do sistema e suas

demandas de hardware.  Diagramas Comportamentais: Descrevem o comportamento dos elementos e suas interações. Os mais relevantes são: o

Caso de uso: Demonstra as funcionalidades que ocorrem no

o

Sequência: Demonstra toda a interação entre diversos objetos,

sistema;

em uma determinada situação e intervalo de tempo; o

Comunicação: Demonstra a interação geral entre objetos;

o

Atividade: Demonstra execução de ações e atividades e as

transições consequentes; o

Máquina de Estado: Demonstra os estados que um objeto pode

assumir em seu processo de construção, uso e destruição. No projeto do iMestre serão apresentados os diagramas de Caso de Uso e Classes. O Diagrama de Caso de Uso, segundo Deboni (2003), deve identificar usuários do sistema, chamados de atores, e representar funções sob seus pontos de vista. As descrições dos casos de uso devem especificar completamente a funcionalidade representada por ele, permitindo um melhor entendimento do mesmo por parte dos envolvidos no processo de construção do software. O Diagrama de Classes, também segundo Deboni (2003), tem como objetivo principal criar uma fundação sólida para que o software seja implementado. Nele estarão descritas todas as classes do sistema, seus métodos e atributos. Essas classes, em tempo de execução, serão instanciadas como objetos. Na área de construção, a UML tem como vantagem a possibilidade de ser mapeada para diversas linguagens de programação diferenciadas, desde que orientadas a objetos. No setor de documentação, a UML abrange a arquitetura do sistema, incluindo detalhes até de sua implantação e testes.

35

2.6.9. Orientação a Objetos Orientação a objetos é definido por Lima (2008) como a abstração de itens do mundo real, convertendo-os em mecanismos que podem ser manipulados por meio de softwares.

2.6.9.1.

Classes Classe é definida por Dall’oglio (2007) como uma estrutura estática, ou

seja, que não muda o seu valor, que é usada para descrever objetos através de métodos e atributos. Ela é o modelo que será utilizado para criar um objeto. 2.6.9.2.

Objetos Um objeto é uma estrutura dinâmica, que pode alterar seus valores durante

a execução, gerada a partir de uma determinada classe, segundo Dall’oglio (2007). Pode-se dizer que um objeto é uma instância de uma classe, já que ele existe por um determinado tempo (seu tempo de execução) para depois ser destruído. 2.6.10.

Linguagem PHP Segundo Soares (2011), PHP é um acrônimo de HyperText Preprocessor,

uma linguagem de programação open source, utilizada mundialmente, principalmente no âmbito da programação web. Ela foi desenvolvida por Rasmus Lerdof em 1994 e, inicialmente, tinha como objetivo monitorar o acesso ao currículo de Lerdof na Internet. Nesse começo, a linguagem foi nomeada de PHP/FI (Personal Home Page/Forms Interpreter). Em 1997, os estudantes Andi Gutmans e Zeev Suraski resolveram cooperar com Ramus para o aprimoramento da nova linguagem. Em 1998, após o lançamento do PHP 3, os estudantes começaram a trabalhar numa reescrita no núcleo do PHP, batizando-o de Mecanismo Zend. O PHP 4 adveio desse novo core. E, mesmo com todo esse trabalho, a linguagem ainda precisava evoluir no sentido de orientação a objetos. Para sanar essa necessidade, foi desenvolvido o PHP 5. Segundo Lockhart (2015), o PHP atualmente é uma linguagem de rápida evolução apoiada por dezenas de equipes de desenvolvedores. Juntamente com o sistema de controle de versão Git, permite a construção de sistemas completamente

36

auditáveis, e uma série de novas e boas práticas que incrementam a qualidade dos sistemas desenvolvidos por tal linguagem. 2.6.11.

Testes de Software Gustafson (2003) define teste de software como a execução do mesmo

com dados e os seus comportamentos. Já Pressman (2006) define teste como um conjunto de atividades que podem ser planejadas e executadas de forma sistemática. Segundo Rezende (2005), os tipos de testes mais convencionais são:  Amostragem: Seleciona-se uma parte do conjunto total de dados, agrupados a partir de características específicas. Assim pode-se testar todos os tipos de dados sem sobrecarga usando o volume como um todo;  Sistemático: Com critérios estabelecidos por um conjunto de pessoas;  Simulado: Valores são inseridos de forma caótica.  Automatizado: Feito por meio de programas que automatizam o lançamento dos valores e, muitas vezes, já aditam a sua saída. Rezende (2005) ainda define outros tipos de testes, menos convencionais. São eles:  Verificação e Validação: Verificação confere se o software atende todos os requisitos que foi projetado. Já validação é o retorno do usuário a respeito do software que ele esperada receber;  Alfa e Beta: Testes executados pelos clientes, variando apenas o ambiente onde os testes acontecem;  Recuperação: Força o sistema a falhar, com objetivo de verificar os seus mecanismos de recuperação;  Segurança: Testa os mecanismos de proteção embutidos no software e se estes irão de fato evitar acessos indevidos;  Estresse: Força o sistema a funcionar em situações completamente anormais, com o objetivo de exigir o máximo dos recursos disponíveis;  Desempenho: Avalia o desempenho do software, de forma isolada ou integrada a terceiros, quando necessário.

37

Na prática, todos os testes aplicados são mistos, se adequando as necessidades específicas de cada rotina a ser testada. No caso do iMestre serão utilizados testes de Amostragem, Verificação, Alfa e Beta. 2.6.11.1. Verificação e Validação Comumente a etapa de testes de um software é chamada de Verificação e Validação, ou V&V, definidos por Pressman (2006) apud Boehm através de duas perguntas: ‘Verificação: “Estamos construindo certo o produto? ” Validação: “Estamos construindo o produto certo? ” As atividades de V&V vão muito além dos testes em si, incluindo etapas de revisão documental e de banco de dados até monitoração de desempenho. Tais rotinas auxiliam na confecção de um software que apresente um alto grau de qualidade. 2.6.11.2. Testes Alpha e Beta Como o iMestre é um aplicativo que tem como objetivo atender os mais variados usuários, é demasiadamente custoso efetuar testes com cada um dos usuários do sistema. Um dos processos mais comuns utilizados para a descoberta de erros que apenas usuários comuns podem detectar são chamados de Testes Alpha e Testes Beta. Nos testes alpha, os testes são executados sob a supervisão do desenvolvedor, que estará registrando erros e problemas que possam ocorrer, num ambiente controlado e preparado para tal. Nos testes beta, os testes são executados pelo próprio usuário final, sem a presença do desenvolvedor, onde o sistema irá enviar mensagens caso ocorra algum erro interno e o usuário irá registrar falhas que lhe forem visíveis, tudo sendo reportado ao desenvolvedor posteriormente. 2.6.11.3. Amostragem O teste de amostragem é quando uma parcela da população total de cada subconjunto de funções de um sistema é escolhida para ser executada e observar o

38

seu comportamento. Pressupõe-se que, por terem sido implementadas da mesma forma, toda a população daquele subconjunto se portará de forma idêntica a parcela que foi separada para o teste. Dessa forma é possível testar uma grande quantidade de rotinas sem a eventual sobrecarga que isso pode demandar, caso utilize toda a população existem de dados e/ou códigos. 2.6.12.

Documentação e Treinamento A Documentação do software é de fundamental importância pois ela

auxiliará em diversas atividades posteriores a finalização do trabalho em si. A Documentação Geral do Sistema (DGS) é composta por diversos artifícios. São eles: • Análise de Requisitos: Apresenta o resultado da Engenharia de Requisitos e as funcionalidades que serão desenvolvidas no sistema; • Diagrama Entidade-Relacionamento do Banco de Dados: Apresenta o modelo, em alto nível, da base de dados que irá atender o sistema; • Diagrama Lógico do Banco de Dados: Apresenta o modelo, em nível técnico, da base de dados que irá atender o sistema; • Coleção de Diagramas de Caso de Uso: Apresenta todos os casos de uso a serem atendidos pelo sistema; • Coleção de Diagramas de Classes: Apresenta todas as classes presentes no sistema; • Coleção de Mockups: Apresenta todos os protótipos desenvolvidos para o sistema, em sua versão final; • Dicionário de Funções: Apresenta os dados que serão processados por cada função do sistema, sua entrada e sua respectiva saída; • Manual do usuário final: Apresenta instruções de uso do sistema, de forma clara; • Wiki online com o conteúdo do Manual: Apresenta instruções de uso do sistema, de forma clara, amparada em uma plataforma wiki; • Vídeo-aula de uso do software: Apresenta um exemplo prático do uso de cada uma das funcionalidades do sistema; • Projeto do Sistema: O presente documento; Cada documento desse tem sua função na continuação do projeto, sendo que um dos mais importantes são os que tem como público-alvo o usuário final. É

39

através desses artigos que o treinamento de uso será feito, tornando o sistema auto didático, simples e intuitivo. 2.6.13.

Ferramentas Utilizadas Este item tem como objetivo apresentar um breve resumo sobre as

ferramentas utilizadas para facilitar a construção do software iMestre, em todas as suas etapas. 2.6.13.1. Astah Community Astah é um software desenvolvido em Java pela empresa Change Vision, que possui uma gama de ferramentas que auxiliam na criação de diagramas UML. O programa possui licença proprietária, porém a sua versão Community, que é utilizada no trabalho, é gratuita. 2.6.13.2. brModelo brModelo é um ferramenta freeware voltada para o ensino de modelagem de banco de dados. Ela possui elementos que auxiliam na criação de modelos Entidade-Relacionamento e Lógico, além de mapeadores que permitem a conversão entre os modelos de alto nível até o script SQL propriamente dito. 2.6.13.3. Eclipse Eclipse é uma famosa IDE originalmente criada para a linguagem Java. Mas por ser comunitária e ter um grande número de usuários, logo recebeu atualizações que permitiam o desenvolvimento de diversas linguagens diferentes, entre elas o PHP, que é utilizada nesse trabalho.

2.6.13.4. Doctrine O Projeto Doctrine é um conjunto de diversas bibliotecas PHP focadas no armazenamento de dados e mapeamento Objeto-Relacional. A ferramenta é utilizada desde 2006, extremamente flexível e capaz de se integrar a outros frameworks PHP. 2.6.13.5. Foundation

40

Foundation é um framework CSS desenvolvido pela Zurb que tem como principal objetivo a criação de layouts que possam ser acessados de quaisquer dispositivos. Esse processo é chamado de responsividade. 2.6.13.6. PHPMyAdmin phpMyAdmin é uma ferramenta gratuita escrita em PHP com o objetivo de auxiliar a administração de bases de dado MySQL através da web. 2.6.13.7. EasyPHP EasyPHP é um pacote WAMP que inclui a linguagem PHP, servidor web Apache, base de dados MySQL e o gerente de bancos de dados phpMyAdmin. Ele é simples de ser instalado e não requer configurações para o seu funcionamento básico.

41

3. ESTADO DA ARTE Esta seção tem como objetivo mostrar um comparativo entre algumas ferramentas similares ao iMestre que foram encontradas em pesquisas e tem objetivos equivalentes, conforme descrito detalhadamente a seguir. A princípio, será apresentada uma breve explicação dos aplicativos, comentando vantagens e desvantagens. Ao final, uma tabela comparativa entre as funções será demonstrada. 3.1.

Educador.net1 Desenvolvido em 2000, pela AIX Sistemas para auxiliar duas entidades

educacionais, é um sistema que dispõe de mecanismos para gestão de diário de classe, além de controle de turmas e diversos gráficos. Porém, ele não auxilia na confecção de provas nem na comunicação com terceiros. 3.2.

Gennera Diarion2 É uma ferramenta Web que permite ao professor o cadastro de frequências

e notas, além de alguns gráficos que permitem analisar o desenvolvimento dos alunos, seja individualmente ou a turma como um todo, conforme visto na Figura 8. Figura 8: Tela de uso do Diarion, dashboard de turma.

Fonte: Distribuição Gennera.

É desenvolvido pela empresa Gennera, desde 2011. Apresenta como vantagens uma interface agradável e intuitiva, que facilita a sua utilização como diário

1 2

http://oeducador.net http://www.gennera.com.br/diarion.html

42

de classe. Já como desvantagens, a ferramenta é paga e não oferece suporte as funções de criação de avaliações nem banco de questões. 3.3.

Professor Tech II3 O Professor Tech II é um sistema local que gerencia um banco de questões,

permitindo a organização das mesmas por área de conhecimento, nível de dificuldade, etc. O software foi descontinuado comercialmente em 2009, mas ainda pode ser utilizado de forma gratuita, porém sem suporte algum. Sua interface é apresentada na Figura 9. Figura 9: Tela de Uso do Professor Tech II.

Fonte: Próprio Autor.

O sistema é bem simples de ser utilizado e possui um esquema de catalogação das questões muito efetivo. A geração do exercício para ser impresso é satisfatória, mas deixa a desejar nos aspectos de organização e apresentação das questões. Outro aspecto em que o mesmo falha é na ausência de suporte a diversas outras funções inerentes a atividade de um professor, resumindo-se apenas a gestão de conteúdo para avaliações.

3

http://www.comofazerascoisas.com.br/software-professor-tech-2-download-gratis.html

43

3.4.

Daypo Online Tests4 O Daypo web é dedicado a criar questionários, testes e cursos para

aprendizado online. É possível criar atividades para autoaprendizagem, repetindo até a completa memorização. Caso o usuário seja um professor, é possível criar um teste de forma aleatória e aplicar aos alunos, permitindo a publicação online das respostas. Uma ilustração de uso do Daypo é apresentada na Figura 10. Figura 10: Imagem do uso do Daypo Online.

Fonte: Próprio Autor.

As vantagens do sistema estão na facilidade do uso, com uma tela bem simples que permite uma rápida compreensão de como utiliza-la. Porém, o aplicativo só se encontra em inglês, espanhol ou francês, dificultando o uso dos professores brasileiros em sua totalidade. Outra falha do Daypo está no mecanismo de correção das questões dissertativas, que consiste em comparação literal entre a resposta do aluno e a resposta do professor. Mais uma falha que foi encontrada está na ferramenta de impressão, que gera um arquivo simples demais, sem organização alguma no conteúdo, como se fosse um simples “rascunho”, impedindo que seja utilizado de forma profissional. Este aplicativo também não oferece suporte a nenhuma outra função necessária para auxiliar um professor, como gestão de notas ou frequências.

4

http://www.daypo.net/

44

3.5.

Free Timetabling Software (FET)5 FET é um software open source para agendamento automático dos

horários de uma instituição de ensino. Liviu Lalescu é o idealizador do sistema e conta com uma grande rede de contribuintes, graças ao aplicativo ser gratuito. O uso do FET é apresentado na Figura 11. Figura 11: Tela de uso do FET.

Fonte: Distribuição FET.

O sistema possui tradução para o Português Brasileiro e atende satisfatoriamente a função que promete fazer. A desvantagem principal dele é que, a depender da complexidade dos horários, o tempo para a montagem do mesmo se torna quase inviável, tornando o sistema pouco indicado para uma instituição de grande porte. Outra desvantagem relacionada ao seu uso é que só executa essa única função, não atendendo demandas mais objetivas da atividade docente, como criação de atividades ou gestão de diário de classe.

5

http://lalescu.ro/liviu/fet/

45

3.6.

Comparativo entre os sistemas

O Educador.net é uma ferramenta muito completa de gestão dos alunos e tem como alvo o professor, mas não possibilita o uso de um banco de questões. Já o Gennera Diarion é voltado apenas para a gestão de “diário de classe” virtual. Enquanto isso, o Professor Tech II tem como objetivo a gestão de avaliações, incluindo um banco de questões consideravelmente robusto e bem catalogado (por área de conhecimento e nível de dificuldade). O aplicativo Daypo Online também tem como objetivo a criação de avaliações, mas não possibilita a gestão de banco de questões e sua execução é pouquíssimo profissional. Por último, o TEF tem como função principal a criação automatizada dos horários da instituição e a cumpre muito bem, mesmo que não ele não possa ser aplicado a instituições de grande porte. A Figura 12 demonstra a comparação entre os aplicativos estudados e suas funções, comparando-os ao projeto apresentado por meio desde trabalho. Figura 12: Comparativo entre as funcionalidades do sistema.

Fonte: Próprio Autor.

46

4. MODELAGEM E IMPLEMENTAÇÃO DO IMESTRE O processo de modelagem é a etapa que será definido o escopo do sistema, as funções que ele irá ter. Também é nessa etapa que ele será construído de fato, através da confecção de modelos que permitem um melhor estudo das estruturas que o compõe (base de dados, casos de uso, etc.) e implementação dos códigos necessários para que ele funcione. 4.1.

ENGENHARIA DE REQUISITOS Entender a necessidade a qual o aplicativo deve atender é de fundamental

importância. Por meio de entrevistas com os possíveis clientes e usuários, descobrese quais as necessidades que eles anseiam em um sistema. Os usuários analisados para a construção do iMestre foram um professor da Rede Estadual da Bahia, o orientando e o orientador deste trabalho. 4.1.1. Descrição do minimundo Existem diversos aplicativos disponíveis ao público que tem como objetivo a gestão acadêmica. Em geral, eles abrangem atividades como gestão de notas e presenças, e até mesmo montagem de horários. O iMestre foi planejado para atender o máximo de demandas básicas da atividade de um professor, independentemente do nível de atuação do mesmo. O software deverá gerenciar escolas (chamadas de instituições), as disciplinas ministradas nelas pelo professor, as turmas e seus respectivos alunos. Dentro desses grupos, ainda existem as gestões de avaliações, notas e frequências. Essas três atividades são a base das ações executadas por um professor. Todas as seguintes são consequências delas: Controle do Banco de Questões, Pareceres sobre os alunos. Outra demanda atendida pelo iMestre é a questão de comunicação dos professores. Ele permitirá a criação e envio de mensagens para os e-mails vinculados aos alunos. As duas últimas necessidades atendidas são: a criação de ementas para cada disciplina; e a montagem de horários.

47

4.1.2. Método de Elucidação dos Requisitos O método de elucidação dos requisitos para o iMestre consistiu em selecionar as funções básicas de um professor, por meio do Documento de Normas e Diretrizes da Educação (1996), entrevista com professores e estudo comparativo dos softwares que já existiam no mercado. O resultado da Análise de Requisitos está no Apêndice A. 4.2.

MODELAGEM DE DADOS Planejar a melhor forma de organizar os dados pertinentes ao sistema

também constitui uma etapa relevante do projeto do software, já que a eficiência do mesmo está diretamente relacionada a velocidade de recuperação de dados e a capacidade dele em gerar informações relevantes a partir disto. 4.2.1. Modelo Conceitual O Modelo Entidade-Relacionamento da base de dados do iMestre. Ele atendo as demandas que foram levantadas na etapa anterior da implementação, e é demonstrado no Apêndice B desse documento. 4.2.2. Modelo Lógico O Modelo Lógico é um mapeamento do modelo conceitual, mas contendo informações sobre a base de dados que será utilizada, o MySQL. O resultado desse mapeamento está presente no Apêndice C. 4.3.

MODELAGEM UML UML é uma linguagem internacional de padronização de modelos para

serem implementados seguindo o paradigma de orientação a objetos. Quando tal documentação é construída, de forma correta e coerente, o projeto pode ser analisado e melhorado por qualquer desenvolvedor, em qualquer lugar do mundo, independente da língua que fale, pois a simbologia utilizada é a mesma em todo o planeta. 4.3.1. Diagrama de Casos de Uso Os diagramas de Caso de Uso do iMestre demonstram as funcionalidades que estão implementadas no sistema, de forma clara e objetiva, ressaltando quem é que ativa cada evento. Esse diagrama está contido no Apêndice D.

48

4.3.2. Diagrama de Classes Os diagramas de Classes do iMestre apresentam a organização e os métodos implementados no sistema, ocultando os atributos, pois estes já foram apresentados no modelo Lógico do Banco de Dados. Também foram suprimidos os métodos “getter and setters”, pois são apenas meios de alimentar ou recuperar valores dos atributos, sem lógica de programação relevante. Esse diagrama pode ser visto no Apêndice E. 4.4.

PROTOTIPAÇÃO Por meio da criação de protótipos, de alto ou baixo nível, é possível discutir

com os usuários melhores formas de apresentação dos dados, seja em conceitos de organização até mesmo conteúdo que deve ser apresentado nas telas. 4.4.1. Alguns protótipos Os protótipos de baixa qualidade desenvolvidos no projeto iMestre não atendem todas as telas que o sistema requer, mas já serve de base para analisar a modelagem gráfica do mesmo. O modelo apresentado na Figura 13 mostra a separação básica do iMestre, com três setores: Cabeçalho, Lateral e Principal. A lógica apresentada aí afirma que o cabeçalho é estático, modificando apenas a quantidade de mensagens que pode existir numa caixa de entrada. A área lateral irá conter links de acesso rápido a informações relevantes, no contexto da aplicação. A última área, a principal, é a mais importante. Nela serão inseridos os dados que estão utilizados no momento: um formulário de cadastro, uma tabela com listagem, etc.

49

Figura 13: Modelo Base do iMestre.

Fonte: Próprio Autor.

4.5.

DESENVOLVIMENTO Essa subseção irá apresentar informações pertinentes ao desenvolvimento

do aplicativo, iniciando com a implementação da base de dados. Em seguida, será explicado o uso dos frameworks que facilitaram a confecção das mesmas. Por fim, será demonstrada as configurações necessárias para execução do iMestre. 4.5.1. Implementação da base de dados Após a modelagem da base de dados, é possível criar uma versão do script correspondente ao modelo efetuado com auxílio do brModelo. Se a criação do modelo lógico estiver sido feita já inserindo os tipos de dados aceitos pelo SGBD, no caso do iMestre, o MySQL, essa conversão só precisará da inserção de “;” (pontos-e-vírgulas) entre os comandos de criação de cada tabela. Após essa etapa, basta executar tal script na ferramenta de gestão do banco de dados, a phpMyAdmin. 4.5.2. Implementação e uso do Doctrine A implementação do Doctrine é simples. Após implementada a base de dados, com todos os seus relacionamentos, é necessário que os arquivos do framework sejam adicionados no diretório do projeto. Também é necessária a criação de dois arquivos no projeto: “bootstrap.php” e “build_models.php”. O bootstrap tem como função configurar o acesso ao banco de dados. Também é responsável pelo carregamento automático de todas as classes do

50

sistema, tornando desnecessário múltiplos comandos “require_once(‘classe.php’)”, já que uma única instância de “require_once(‘bootstrap.php’)” trará o que for necessário. O build_models é um código simples que usa o schema da base de dados como modelo e cria todas as classes respectivas. Elas são inseridas num novo diretório chamado de “generated” com o nome “Base+nome da tabela no banco”. No diretório configurado para receber as classes são criadas classes vazias com o nome da tabela no banco. Elas fazem a função de “fachada” já que, pelo modelo de 3camadas, a camada responsável pela persistência não deve ter lógica de negócio alguma. Nelas serão implementados métodos como salvar() ou deletar(). Terminado esse processo, a conexão com a base de dados está implementada e gerenciada pelo framework. 4.5.3. Implementação e uso do Foundation A implementação do Foundation também é consideravelmente simples. Como qualquer framework CSS, basta referenciar o arquivo CSS nos cabeçalhos de cada página HTML/PHP que vá utilizá-la. O uso dela também é simplificado. Ele é desenvolvido de uma forma em que a página é dividida em 12 setores. Cada elemento inserido deve utilizar um ou mais desses setores. E dessa forma eles vão se “encaixando”, até chegar ao limite de 12. Quando o limite for atingido, começa-se uma nova linha. Outra implementação que o Foundation utiliza é o conceito da responsividade. Para cada tipo de tela há um comando. Os tamanhos préconfigurados na biblioteca são: small; medium; large; e x-large. Dessa forma, um mesmo elemento pode carregar configurações para diversas telas. Para exemplificar, imagine um formulário HTML com três campos de texto. Numa tela “large”, cada campo deverá utilizar quatro setores. Se essa tela for “small”, cada campo deverá utilizar todos os doze setores da tela. Dessa forma, o código implementado será como apresentado na Listagem 1. Listagem 1: Uso do Foundation 1. 2. 3. 4. 5. 6. 7. 8.

51

9. 10. 11.

O mesmo deve ser aplicado caso seja necessário gerenciar mais tamanhos de tela. E esse é apenas uma das funções pré-configuradas pelo Foundation. Ele também implementa uma gama de outras funcionalidades, desde criação de botões estilizados ou menus dropdown. 4.5.4. Implementação do iMestre A parte mais importante do trabalho todo é o funcionamento do sistema iMestre. Esta parte do capítulo irá demonstrar como é o processo de instalação do núcleo do sistema, possibilitando o seu uso. 4.5.4.1.

Implementação do Servidor Web Existem diversos serviços que implementem servidores web. Os mais

utilizados são o IIS (Internet Information Services), da Microsoft, e o Apache, da Apache Foundation. Esta segunda opção é gratuita e utilizada no projeto iMestre. Sua implementação é consideravelmente simples e varia de acordo ao sistema operacional utilizado 4.5.4.2.

Implementação do PHP Core O PHP é uma linguagem interpretada, ou seja, o seu código fonte é

interpretado e compilado pelo servidor e enviado para o cliente. Para que o servidor web possa executar essa função, é necessária a instalação do núcleo do PHP, que é o responsável por interpretar cada função do código fonte e criar a página que será visualizada pelo cliente. A Figura 14 é apresenta a lógica do core do PHP.

52

Figura 14: Lógica do núcleo PHP

Fonte: Próprio Autor.

4.5.4.3.

Implementação do MySQL Uma vez que o SGBD do projeto foi escolhido, é impossível a

implementação de outra ferramenta para esse objetivo. A implementação do MySQL também varia de acordo ao sistema operacional em que o aplicativo irá ser executado. 4.5.4.4.

Implementação Alternativa do WAMP/LAMP Server Existem aplicativos que facilitam a instalação das ferramentas que foram

apresentadas anteriormente. São chamados de WAMP (Windows + Apache + MySQL + PHP) ou LAMP (Linux, ao invés de Windows), a depender do sistema operacional que for utilizado. Para Windows, os mais utilizados são o WAMPServer 6, Vertrigo7 e EasyPHP8. Já para Linux, a instalação é possível através do comando de instalação “install lamp-server^”, variando de acordo com a distribuição que seja utilizada. O projeto utilizou o EasyPHP, que automatizou a instalação e préconfiguração dos requisitos para o bom funcionamento do servidor Web.

6

http://www.wampserver.com/en/ http://vertrigo.sourceforge.net/?lang=pt 8 http://www.easyphp.org/ 7

53

4.5.4.5.

Implementação do Sistema iMestre A implementação do núcleo principal do iMestre é consideravelmente

simples, desde que se tenha conhecimento sobre computação. O primeiro passo que o aplicativo esteja pronto para uso é executar o arquivo SQL que contém o schema da base de dados, todos seus relacionamentos e o conteúdo mínimo para sua execução. Em seguida, basta disponibilizar os arquivos do sistema no diretório de execução do servidor web que foi instalado. No caso do EasyPHP, é a pasta locaweb no subdiretório data. A última etapa é configurar o arquivo bootstrap.ini com o usuário e senha de acesso ao SGBD.

54

5. TESTES 5.1.

VALIDAÇÃO

Os testes de validação consistem em verificar se cada um dos pontos projetados na Análise de Requisitos foi implementado de forma satisfatória. O resultado da Validação é apresentado no Quadro 2. Quadro 2: Validação dos Requisitos.

Requisito

Atendimento

CRUD Professor

Total

Convidar Professor por e-Mail

Total

CRUD Instituições

Total

CRUD Turmas

Total

Notas de Alunos

Total

Boletim de Turma

Total

Presenças

Total

Ementa

Total

CRUD Alunos

Total

CRUD Avaliações

Total

Geração Automática de Avaliação

Total

Cadastro de Questões

Total

e-Mail Coletivo

Total

Blog

Total

Horários

Total

5.2.

TESTES DE SISTEMA

Para execução dos Testes de Sistema, ou seja, em ambiente controlado pelo programador, incluindo exibição de mensagens de erro e alertas do PHP, foram executadas diversas fases de testes, simulando inserções de dados e avaliando o retorno que a aplicação apresentava. A função de login, apresentada na figura 15, foi testada a fim de evitar que algum usuário sem as devidas permissões tenha acesso as informações dos usuários do aplicativo.

55

Figura 15: Tela de Login iMestre

Fonte: Próprio Autor.

A tela inicial do iMestre, como vista na figura 16, tem como objetivo centralizar algumas das funções mais importantes do sistema, agilizando o acesso a elas. Figura 16: Tela Inicial do iMestre

Fonte: Próprio Autor.

A tela apresentada na figura 17 é a Listagem de Turmas. Esta função é uma das mais importantes do sistema pois agrupa uma série de execuções relevantes. São elas a inserção de alunos em uma turma, o lançamento de frequências e o planejamento de aulas.

56

Figura 17: Tela de Listagem de Turmas Cadastradas.

Fonte: Próprio Autor.

A figura 18 apresenta o lançamento de frequências e sua respectiva impressão. Pode-se observar que o dia 12/01 para o aluno “Fulano de Tal Silveira” está marcado como “Ausente”. Isso é novamente percebido na impressão da frequência, mostrando que a execução está sendo bem-feita. Figura 18: Tela de Lançamento de Frequências e sua impressão.

Fonte: Próprio Autor.

57

A figura 19 apresenta a inserção de questões em uma avaliação précadastrada e a sua visualização para impressão. O cabeçalho visível na impressão é configurável por meio do cadastro de Instituição. Figura 19: Inserção de Questões em Avaliação e sua Impressão.

Fonte: Próprio Autor.

A figura 20 mostra a tela de cadastro de questões, que serão posteriormente utilizadas para alimentar as avaliações (vide Figura 19). Figura 20: Tela de Cadastro de Questões.

Fonte: Próprio Autor.

58

Uma característica presente no iMestre é a responsividade, possibilitando que a aplicação seja utilizada em telas de dimensões menores que um computador comum, como tablets ou celulares. A figura 21 demonstra tal funcionalidade. Figura 21: Tela responsiva de cadastro de novo usuário.

Fonte: Próprio Autor.

5.3.

AMOSTRAGEM

Os testes de amostragem foram efetuados pelo programador, inserindo uma quantidade pequena de informações, avaliando o retorno destes, conferindo se estão dentro do esperado. Por exemplo, ao cadastrar um Aluno, o retorno esperado é que este aluno apareça na Listagem de Alunos e que uma tupla na base de dados seja criada com as informações inseridas.

59

5.4.

TESTES DE ACEITAÇÃO

Testes Beta são rotinas de teste executadas em ambientes externos e alheios ao desenvolvedor, normalmente sendo o usuário final que utiliza o sistema da forma que achar mais viável, apresentando assim falhas mais pertinentes a realidade. Foram executadas diversas baterias de testes, totalizando oito. Ao final de cada uma delas, um relatório era produzindo, informando falhas e correções necessárias. Esses pontos eram imediatamente corrigidos, melhorando assim a usabilidade do sistema. Um exemplo desse relatório é apresentado na figura 22. Figura 22: Exemplo de relatório apresentado ao final de bateria de Teste Beta.

Fonte: Próprio Autor.

60

6. CONSIDERAÇÕES FINAIS 6.1.

CONCLUSÕES

A utilização da tecnologia nas atividades de um professor agrega um grande valor, melhorando a qualidade do mesmo, além de resultar em uma considerável economia de tempo. Neste trabalho foi construído um sistema que centraliza diversas funções que auxiliem um docente, desde construção de provas até o lançamento de notas e frequências. Após um estudo do estado da arte no que diz respeito ao tema do projeto, foram elucidados requisitos que deveriam ser atendidos pelo software. O resultado desse estudo foi uma tabela comparativa que permitiu ter uma melhor visão das reais necessidades de um professor. Com os requisitos bem definidos, as etapas de prototipação e modelagem de dados tiveram como objetivo transformar o que era abstrato em algo que pudesse ser implementado. Subsequente a modelagem, iniciou-se a implementação, onde de fato foi construído o projeto. Essa é uma das partes mais importantes do trabalho, mas não a única. Após a implementação, iniciou-se a fase de testes. Nesta etapa é que o software foi validado, buscando saber se ele corresponde as expectativas e atende à demanda para o qual foi projetado. Outros erros menores, de codificação, tradução, lógica e interação homem-máquina também foram sanados nesta etapa. Por isso, é considerada parte chave do desenvolvimento. Após os testes, foi possível dizer que o iMestre atendeu as demandas para quais foi projetado, de forma satisfatória. O sistema se mostrou capaz de atender os requisitos para os quais foi projetado. Através de testes, foram simuladas diversas criações de avaliações, com questões de diversos tipos. O cadastro de alunos, turmas e notas também foi validado e se mostrou muito satisfatório. As plataformas de blog e disco virtual atendem bem a necessidade elucidada nos requisitos. Os testes apontaram que o iMestre é uma ferramenta extremamente útil e que centraliza diversas funções em um único aplicativo, agilizando atividades e otimizando o tempo do usuário.

61

6.2.

LIMITAÇÕES DO PROJETO

Como limitação principal do projeto foi encontrada a disponibilidade das hospedagens gratuitas que foram utilizadas. No começo do projeto, uma hospedagem foi utilizada. Ela não atendeu as expectativas, poluindo o sistema com publicidade e não estando disponível quando necessário. Para tentar resolver tal problema, a migração de servidor foi necessária. Nessa nova tentativa, o problema das propagadas foi resolvido. Porém, a limitação encontrada agora era na criação de arquivos. O servidor permitia o gerenciamento de apenas 1000 (mil) arquivos, chamados de inodes pela equipe de suporte. Após isso, perdia-se por completo o controle das funções de escrita do site. Novamente, a migração foi necessária. O último plano de hospedagem utilizado, dessa vez uma plataforma em nuvem, não possuía nem propagandas nem limitações de inodes. Porém, sua disponibilidade era baixíssima, muitas vezes impossibilitando baterias de testes (alpha e beta). 6.3.

TRABALHOS FUTUROS

Uma série de trabalhos futuros estão sendo planejados para o iMestre. Entre eles pode-se destacar: 

Remodelagem da Interface Gráfica do sistema;



Utilização do padrão CVS para importação de alunos;



Importação/Exportação de boletins e frequências.



Melhoria no sistema de Cadastro de Questões, permitindo uso de imagens, tabulações, etc.

62

Referências BOOCH, G. UML – Guia do Usuário. 2ª. ed. Rio de Janeiro: Elsevier, 2005. BRASIL. LEI Nº 9.394, DE 20 DE DEZEMBRO DE 1996. Palácio do Planalto, 1996. Disponivel em: . Acesso em: 02 abril 2015. BRAUDE, E. Projeto de Software: da programação à arquitetura: uma abordagem baseada em Java. Porto Alegre: Bookman, 2005. CEGALLA, D. P. Dicionário Escolar da Lingua Portuguesa. São Paulo: Companhia Editora Nacional, 2005. DALL'OGLIO, P. PHP Programando Orientado a Objetos. São Paulo: Novatec, 2007. DAMAS, L. SQL, structured query language. 6ª. ed. Rio de Janeiro: LTC, 2007. DATE, C. J. Introducción a los Sistemas de bases de datos. 7ª. ed. Ciudad do México: Pearson Educación, 2001. DEBONI, J. E. Z. Modelagem orientada a objetos com a UML. [S.l.]: Futura, 2003. ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 6ª. ed. São Paulo: Pearson Addison Wesley, 2011. FOWLER, M. UML Essencial: um breve guia para a linguagem-padrão de modelagem de objetos. 3ª. ed. Porto Alegre: Bookman, 2005. FREEMAN, E.; FREEMAN, E. Use a Cabeça! - Padrões de Projeto. 2ª. ed. [S.l.]: Alta Books, 2007. FREIRE, P. Pedagogia da Autonomia: saberes necessários à prática educativa. 25ª. ed. Rio de Janeiro: Paz e Terra S/A, 2002. GAMMA, E. et al. Padrões de Projeto - Solucões reutilizáveis de software orientado a objetos. São Paulo: Bookman, 2007. GUSTAFSON, D. A. Teoria e Problemas de Engenharia de Software. Porto Alegre: Bookman, 2003. HEUSER, C. A. Projeto de Banco de Dados. 6ª. ed. Porto Alegre: Bookman, 2009. KUROSE, J. F.; ROSS, K. W. Redes de Computadores e a Internet. 3ª. ed. São Paulo: Pearson Addison Wesley, 2006. LIMA, A. D. S. UML 2.0 - Do requisito à solução. 3ª. ed. São Paulo: Érica, 2008. LOCKHART, J. Modern PHP. Sebastopol: O'Reilly, 2015.

63

MACHADO, F.; ABREU, M. Projeto de Banco de Dados - Uma visão prática. 17ª. ed. São Paulo: Érica, 2012. MARÇULA, M.; BENINI FILHO, P. A. Informática Conceitos e Aplicações. 3ª. ed. São Paulo: Érica, 2008. MORIMOTO, C. E. Servidores Linux. [S.l.]: Sul Editores, 2008. NORTON, P. Introduction to Computers. 6ª. ed. Nova Deli: McGraw-Hill Publishing Company, 2006. PAULA FILHO, W. D. P. Engenharia de Software: fundamentos, métodos e padrões. 3ª. ed. Rio de Janeiro: LTC, 2009. PFLEEGER, S. L. Engenharia de Software: teoria e prática. 2ª. ed. São Paulo: Prentice Hall, 2004. PLATÃO. A República. Ênio Padilha - Engenheiro, Escritor, Palestrante, 380 a.C. Disponivel em: . Acesso em: 07 Novembro 2014. PRESSMAN, R. S. Engenharia de Software. São Paulo: Pearson Markon Books, 2006. REZENDE, D. A. Engenharia de Software e Sistemas de Informação. 3ª. ed. Rio de Janeiro: Brasport, 2005. SANTOS, C. C. D. Padrões de Arquiteturas em Projetos de Sistemas Multicamadas. Universidade de São Paulo. São Paulo, p. 16. 2005. SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de Banco de Dados. 3ª. ed. São Paulo: Pearson Makron Books, 1999. SILVA, M. T. Autoria de Artefato de Software. Pontifícia Universidade Católica do Rio Grande do Sul. Porto Alegre, p. 233. 2010. SOARES, W. PHP 5 - Conceitos, Programação e Integração com Banco de Dados. 6ª. ed. São Paulo: Érica, 2011. SOMMERVILLE, I. Engenharia de Software. 8ª. ed. São Paulo: Pearson AddisonWesley, 2007. TANENBAUM, A. S. Redes de Computadores. Rio de Janeiro: Elsevier, 2003. VELLOSO, F. D. C. Informática, Conceitos Básicos. 8ª. ed. Rio de Janeiro: Elsevier, 2011.

64

APÊNDICE A – Análise de Requisitos 1.

Visão geral do Produto O sistema deve permitir o gerenciamento de informações pessoais dos alunos, assim como suas notas e as turmas e instituições as quais o professor ministra aulas. Deve permitir a confecção de planejamentos para atividades e avaliações, além da publicação de dados relevantes aos alunos. 1.1.

Descrição dos usuários Os usuários do sistema serão unificados em uma única tabela, sendo separados por categoria: • Administrador do sistema: Usuário responsável por gerenciar o sistema. • Professor: Cadastra alunos, turmas e escolas. Gerencia notas e atividades. Acessa relatórios gerenciais. • Aluno: Usuário externo ao sistema que acessar uma pequena parte dele, disponibilizado pelo professor. 2.

Requisitos Funcionais Esta seção contém os requisitos funcionais do sistema.

2.1.

Requisitos de gerenciamento de usuários O Sistema terá por padrão, um administrador, e este por sua vez será responsável por administrar todos os professores cadastrados. Estes que irão gerenciar todos os outros acessos aos seus pertences, como notas 2.1.1.RF001 – Cadastrar professor/usuário O Software deve ser capaz de permitir o cadastro de professores, apenas através de formulário público disponível na web ou convite enviado pelos administradores do sistema. 2.1.2.RF002 – Alterar cadastro de usuário Tanto o usuário quanto os administradores podem alterar informações no cadastro do usuário. Administrador não consegue ver senha do usuário, apenas criar uma nova. 2.1.3.RF003 – Excluir/Inativar cadastro de usuário Somente usuário pode excluir sua própria conta. 2.1.4.RF004 – Convidar professores por E-mail. Os administradores podem convidar professores via e-mail, pre-construindo o cadastro dos mesmos. 2.2. Gerenciamento de Instituições O software deve ser capaz de permitir o cadastro de instituições de ensino, onde serão alocadas as turmas. 2.2.1.RF005 – Cadastrar Instituição O Sistema permitirá o cadastro de Instituições, com dados como nome, endereço e telefone de contato. 2.2.2.RF006 – Editar Instituição Administradores poderão alterar dados e parâmetros da instituição a qualquer momento, por exemplo: alterar nome ou telefone. 2.2.3.RF007 – Excluir Instituição O sistema deve permitir a exclusão de uma instituição desde que ela não tenha nenhuma turma vinculada.

65

2.3. Gerenciamento de Turma O Sistema deverá permitir o cadastro de turmas, separadas por disciplinas, onde serão alocados os alunos. 2.3.1.RF008 – Cadastrar Turma O sistema deverá permitir o cadastro de turmas, inserindo a disciplina que será ministrada na mesma. 2.3.2.RF009 – Excluir Turma Somente poderá ser excluída uma turma que não tenha nenhum aluno vinculado. 2.3.3.RF010 – Gerenciar notas de alunos O professor poderá inserir os valores obtidos pelos alunos nas avaliações previamente cadastradas. 2.3.4.RF011 – Gerar Boletim de Turma O professor poderá gerar automaticamente um boletim com todas as notas dos alunos vinculados à ela. Poderá solicitar boletins anuais, semestrais ou bimestrais, a depender da configuração da turma. 2.3.5.RF012 – Gerar Lista de Presença Física O professor poderá gerar automaticamente uma lista de presença com todos os alunos vinculados à ela, podendo imprimi-la. 2.3.6.RF013 – Gerenciar Presenças O professor poderá gerenciar a presença dos alunos cadastrados na turma, inserindo em uma interface quem está ou não presente em determinada aula. 2.3.7.RF014 – Gerenciar Ementa O professor poderá cadastrar as aulas e o conteúdo das mesmas, construindo um calendário para a turma. 2.4. Gerenciamento de Alunos O sistema gerenciará os dados pertinentes aos alunos que o professor ministra aulas. 2.4.1.RF015 – Cadastrar alunos O professor cadastrará seus alunos, inserindo dados como nome, e-mail, data de nascimento, entre outros, e os agrupará em turmas previamente cadastradas. 2.4.2.RF016 – Editar alunos O professor poderá editar qualquer dado do cadastro de seu aluno. 2.4.3.RF017 – Excluir alunos O professor poderá excluir qualquer aluno, desde que não exista nenhuma nota vinculada ao mesmo. 2.4.4.RF018 – Gerar Boletim Individual O professor poderá gerar o boletim individual de determinado aluno, contendo apenas o resultado das avaliações do mesmo. 2.5. Gerenciamento de Avaliações O sistema deve permitir o cadastro de avaliações, sejam escritas, seminários ou orais, inserindo o conteúdo e os seus valores. 2.5.1.RF019 – Cadastrar Avaliação O sistema permitirá ao professor cadastrar avaliações diversas, inserindo o seu conteúdo e os valores. 2.5.2.RF020 – Excluir Avaliação Uma avaliação só poderá ser excluída se ainda não tiver sido realizada. 2.5.3.RF021 – Cadastrar Questão

66

O professor poderá inserir uma questão, de múltipla escolha ou aberta, e sua respectiva resposta. Também deverá ser inserido o seu nível de dificuldade, disciplina, tema e turma escolar. 2.5.4.RF022 – Gerar Avaliação Através de Banco de Questões O professor poderá utilizar o seu próprio banco de questões, ou o Banco Público de Questões do iMestre, e construir uma avaliação. Deverá ser selecionado a quantidade de questões e o nível de dificuldade das mesmas. 2.5.5.RF023 – Revisar Questão do Banco Público (Opcional) O professor poderá solicitar uma revisão em uma questão do Banco Público, quando este acreditar que ela esteja mal redigida ou com a resposta errada. Também poderá reavaliar o nível de dificuldade. 2.5.6.RF024 – Agenda de Avaliações O sistema irá montar uma agenda de avaliações a partir do cadastro de avaliações previamente feito pelo usuário. 2.6. Gerenciamento de Comunicação O sistema deve permitir a comunicação do professor com alunos, pais e colegas. 2.6.1.RF025 – Email Coletivo O professor poderá escrever uma mensagem dentro do sistema e esta será enviada para um grupo de pessoas cadastradas, seja por turma, instituição, disciplina ou individualmente. 2.6.2.RF026 – Ferramenta de Blog (Opcional) O sistema permitirá que o professor utilize um sistema de blog para disponibilizar diversos arquivos para seus alunos. 2.6.3.RF027 – Pareceres Individualizados O sistema permitirá que o professor informe pareceres específicos de cada aluno, informando comportamento e/ou rendimento deste. 2.6.4.RF028 – Gestão de Horários O sistema permitirá a configuração dos horários semanais do professor, informando onde ele estará ministrando aulas e/ou avaliações, podendo ou não ser publicada posteriormente. 3.

Requisitos Não-Funcionais Esta seção concentra a relação de requisitos que restringem a utilização do sistema ou do desenvolvimento dele. RNF001 – Integridade dos Dados Visando manter a integridade dos dados do sistema, toda alteração ou exclusão de registro deverá obedecer a todos os requisitos de integridade referencial. 3.2.RNF002 – Segurança e privacidade Para aquelas informações que necessitem de maior controle de segurança e privacidade (exemplo: cadastro de senhas de usuários), o sistema deve contar com recursos de encriptação. 3.1.

67

APÊNDICE B – Modelo Conceitual da Base de Dados

68

APÊNDICE C – Modelo Lógico da Base de Dados

69

APÊNDICE D – Diagramas de Caso de Uso Diagrama 1 – Controle de Aluno

Diagrama 2 – Controle de Avaliação

70

Diagrama 3 – Controle de Blog (Opcional)

Diagrama 4 – Controle de Disciplinas

71

Diagrama 5 – Controle de Instituição

Diagrama 6 – Controle de Turmas

72

APÊNDICE E – DIAGRAMA DE CLASSES