M01412 by Fainor

FACULDADE INDEPENDENTE DO NORDESTE – FAINOR CURSO DE ENGENHARIA DA COMPUTAÇÃO

JOÃO SILVA PEREIRA JUNIOR

MODELAGEM E DESENVOLVIMENTO DE UMA FERRAMENTA WEB QUE AUXILIA NO PROCESSO DE AVALIAÇÃO DE ENSINO APRENDIZAGEM

VITÓRIA DA CONQUISTA – BA NOVEMBRO – 2013

JOÃO SILVA PEREIRA JUNIOR

MODELAGEM E DESENVOLVIMENTO DE UMA FERRAMENTA WEB QUE AUXILIA NO PROCESSO DE AVALIAÇÃO DE ENSINO APRENDIZAGEM

Monografia apresentada à Faculdade Independente do Nordeste, como requisito parcial para a obtenção do titulo de Bacharel em Engenharia da Computação. Orientador: Msc. Leard de Oliveira Fernandes

VITÓRIA DA CONQUISTA – BA NOVEMBRO – 2013

P436m

Pereira Junior, João Silva Modelagem e desenvolvimento de uma ferramenta Web que auxilia no processo de avaliação de ensino aprendizagem./ João Silva Pereira Junior._ _ Vitória da Conquista, 2013. 68 f. Orientador(a): Prof. Leard de Oliveira Fernandes Monografia (Graduação) – Faculdade Independente do Nordeste, Curso de Engenharia de computação, 2013. 1. Instrução pelos colegas Servidor 4. Java I. Título.

2.Ensino aprendizagem 3.

CDD 005.13 Catalogação na fonte: Biblioteca da Fainor

Aos meus pais, João e Laura, pela criação, educação e motivação que me dão para conseguir atingir meus objetivos.

AGRADECIMENTOS

Gostaria de agradecer aos meus pais, minhas irmãs e toda a minha família pelo apoio e os meus amigos que sempre mantiveram a confiança em meu potencial. Quero também agradecer a todos os professores com quem eu tive a honra de poder aprender, todo o conhecimento a respeito do curso eu considero como um bem muito valioso. E finalmente, mas não menos importante, eu agradeço também aos colegas com quem eu convivi, alguns por pouco tempo, outros por toda a minha vida acadêmica, foram vários momentos que ficarão guardados na minha memória.

“Mau será o dia do homem quando ele se tornar absolutamente satisfeito com a vida que está levando, quando não estiver mais eternamente batendo nas portas de sua alma um enorme desejo de fazer algo maior.” - Phillips Brooks

RESUMO

Hoje em dia a influência da tecnologia está em diversas áreas, especialmente na educação, agindo como uma fonte de se adquirir mais conhecimento. Sem se afastar do ensino tradicional e presencial, a tecnologia torna-se um recurso muito importante, adicionando novas formas de interação e obtendo uma troca de informações benéfica ao processo de ensino aprendizagem. O objetivo deste trabalho é a utilização da tecnologia da informação para auxiliar o professor, avaliando o seu desempenho em sala de aula de forma instantânea, empregando o método de ensino interativo conhecido por Instrução pelos Colegas, aplicado em um ambiente virtual de aprendizagem. A ferramenta foi desenvolvida utilizando o ciclo de vida de desenvolvimento de sistemas e ela é composta por duas partes, um servidor desenvolvido na linguagem de programação Java que faz a comunicação entre as aplicações clientes, além do acesso ao banco de dados, e um servidor Web responsável pelo gerenciamento do banco de dados. Com os testes realizados, a ferramenta mostrou ser capaz de ser utilizada nas instituições educacionais, no processo de avaliação do ensino, e promover uma aprendizagem de qualidade como consequência. Cabe ao professor adicionar aulas e questões a uma turma, enviar questões aos alunos, receber um relatório e a partir do nível de acerto, determinar a continuidade ou revisão do assunto. Palavras-chave: Instrução pelos Colegas, Ambiente virtual de aprendizagem, Servidor, Web, Java, Ensino aprendizagem.

ABSTRACT

Nowadays the influence of technology is in various areas, especially in education, acting as a source of acquiring more knowledge. Without departing from the traditional classroom teaching, the technology becomes a very important resource, adding new forms of interaction and getting an exchange of information beneficial to the teaching learning process. The objective of this work is the use of information technology to assist the teacher to evaluate their performance in the classroom instantaneously, using the method of interactive teaching known as Peer Instruction, applied in a virtual learning environment. The tool was developed using the systems development life cycle, and it is composed of two parts, a server developed in Java programming language that makes communication between the client applications, and access to the database, and a Web server responsible for managing the database. With the tests performed, the tool proved to be able to be used in educational institutions, in the evaluation of the teaching process, and promote quality learning as a result. It is up to the teacher to add lecture and questions to a class, submit questions for students to answer, and at the end of the question the teacher receives a report from the level of accuracy that can determine the continuation or revision of the subject. Keywords: Peer Instruction, Virtual Learning Environment, Server, Web, Java, Teaching learning.

LISTA DE FIGURAS Figura 1 – Processo de aplicação do método IpC ................................................ 18 Figura 2 – Funções socket para um simples programa cliente-servidor TCP ...... 21 Figura 3 – Do código fonte à execução do programa ........................................... 24 Figura 4 – Diagrama de classes do servidor ........................................................ 33 Figura 5 – Diagrama de Caso de Uso .................................................................. 34 Figura 6 – Exemplo de uma conexão ServerSocket............................................. 41 Figura 7 – Diagrama Entidade Relacionamento do sistema ................................. 42 Figura 8 – Arquitetura do Sistema ........................................................................ 46 Figura 9 – Estrutura do projeto ServidorQuiz ....................................................... 46 Figura 10 – Arquivo de conexão ao MySQL ConexaoBD.java ............................. 46 Figura 11 – Registro do Servidor Quiz ................................................................. 51 Figura 12 – Janela do Servidor Quiz .................................................................... 52 Figura 13 – Lista de professores do Servidor Web .............................................. 54 Figura 14 – Lista de cursos do Servidor Web....................................................... 55 Figura 15 – Lista de disciplinas do Servidor Web ................................................. 56 Figura 16 – Lista de turmas do Servidor Web ...................................................... 56 Figura 17 – Lista de alunos e aulas de uma turma do Servidor Web ................... 57 Figura 18 – Lista de questões de uma aula do Servidor Web .............................. 58 Figura 19 – Relatório de uma questão do Servidor Web ...................................... 59 Figura 20 – Relatório de uma aula do Servidor Web ............................................ 59 Figura 21 – Teste unitário do login do aluno ........................................................ 60 Figura 22 – Teste de desempenho do servidor .................................................... 61 Figura 23 – Janela do servidor em teste do sistema ............................................ 61

LISTA DE QUADROS Quadro 1 – Sumário de servidor e cliente ............................................................ 20 Quadro 2 – Métodos utilizados na classe AlunoBD .............................................. 47 Quadro 3 – Métodos utilizados na classe ProfessorBD ....................................... 47 Quadro 4 – Métodos utilizados na classe TurmaBD ............................................ 48 Quadro 5 – Métodos utilizados na classe AulaBD ................................................ 48 Quadro 6 – Métodos utilizados na classe QuestaoBD ......................................... 49 Quadro 7 – Métodos utilizados na classe Questao_has_AulaBD ........................ 50 Quadro 8 – Métodos utilizados na classe Servidor .............................................. 53 Quadro 9 – Resultado do questionário de usabilidade do sistema ....................... 62

LISTA DE SIGLAS E ABREVIATURAS API – Application Programming Interface AVA – Ambiente Virtual de Aprendizagem BD – Banco de Dados IDE – Integrated Development Environment IpC – Instrução pelos Colegas IHC – Interface Humano-Computador JDK – Java Development Kit JIT – Just In Time JVM – Java Virtual Machine LDD – Linguagem de Definição de Dados LMD – Linguagem de Manipulação de Dados MER – Modelo Entidade Relacionamento RA – Registro Acadêmico SGBD – Sistema Gerenciador de Banco de Dados SQL – Structured Query Language TCP – Transmission Control Protocol UML – Unified Modeling Language

SUMÁRIO

1 INTRODUÇÃO .................................................................................................. 14 1.1 CONTEXTUALIZAÇÃO .................................................................................. 14 1.2 OBJETIVOS ................................................................................................... 15 1.2.1 Objetivo Geral ............................................................................................. 15 1.2.2 Objetivos Específicos .................................................................................. 15

2 REFERENCIAL TEÓRICO................................................................................ 16 2.1 TECNOLOGIA DA INFORMAÇÃO NO ENSINO APRENDIZAGEM .............. 16 2.1.1 Instrução pelos Colegas .............................................................................. 17 2.1.2 Ambiente Virtual de Aprendizagem ............................................................. 19 2.2 MODELO CLIENTE-SERVIDOR .................................................................... 20 2.2.1 Socket ......................................................................................................... 20 2.3 BANCO DE DADOS ....................................................................................... 22 2.3.1 Modelo Entidade Relacionamento ............................................................... 22 2.3.2 SQL ............................................................................................................. 22 2.4 JAVA .............................................................................................................. 23 2.4.1 Etapas do desenvolvimento de uma aplicação java .................................... 23 2.4.2 Características do Java ............................................................................... 24 2.5 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE ........................... 25 3 METODOLOGIA.................................................................................................. 27 3.1 TIPO DE PESQUISA QUANTO AOS OBJETIVOS ........................................ 27 3.2 TIPO DE PESQUISA QUANTO À ABORDAGEM .......................................... 27 3.3 TIPO DE PESQUISA QUANTO AOS PROCEDIMENTOS TÉCNICOS ......... 27 3.4 INSTRUMENTOS DE PESQUISA.................................................................. 27 3.5 PERÍODO DE EXECUÇÃO DA PESQUISA ................................................... 28 4 DESENVOLVIMENTO ...................................................................................... 29 4.1 MODELAGEM DE NEGÓCIOS ...................................................................... 29 4.2 ANÁLISE DE REQUISITOS ........................................................................... 29 4.2.1 Introdução ................................................................................................... 29 4.2.2 Prioridade dos requisitos ............................................................................. 29 4.2.3 Requisitos de software ................................................................................ 30 4.2.3.1 Requisitos funcionais ............................................................................ 30 4.2.3.2 Requisitos não funcionais ..................................................................... 31 4.2.3.2.1 Requisitos de processo ......................................................................... 31 4.2.3.2.2 Requisitos de produto............................................................................ 32 4.2.4 Diagrama de classes ................................................................................... 33 4.2.5 Diagrama de Caso de Uso .......................................................................... 34 4.2.5.1 Atores ...................................................................................................... 34 4.2.5.2 Diagrama ................................................................................................. 34 4.2.5.3 Descrição dos Casos de Uso ................................................................ 35 4.3 PROJETO ...................................................................................................... 39

4.3.1 Projeto de dados ......................................................................................... 39 4.3.1.1 Descrição do banco de dados ............................................................... 39 4.3.1.1.1 Descrição dos dados do sistema ........................................................... 40 4.3.1.1.2 Relacionamento entre os dados ............................................................ 40 4.3.1.1.3 Consultas .............................................................................................. 40 4.3.1.2 Estrutura de dados ................................................................................. 41 4.3.1.3 Diagrama Entidade Relacionamento .................................................... 42 4.3.2 Projeto de Arquitetura.................................................................................. 43 4.3.3 Projeto Procedimental ................................................................................. 43 4.3.4 Projeto de Interface ..................................................................................... 44 4.4 CODIFICAÇÃO .............................................................................................. 45 4.4.1 Servidor Java .............................................................................................. 45 4.4.1.1 O pacote bd (banco de dados) .............................................................. 45 4.4.1.1.1 ConexaoBD ........................................................................................... 46 4.4.1.1.2 AlunoBD ................................................................................................ 47 4.4.1.1.3 ProfessorBD .......................................................................................... 47 4.4.1.1.4 TurmaBD ............................................................................................... 47 4.4.1.1.5 AulaBD .................................................................................................. 48 4.4.1.1.6 QuestaoBD ............................................................................................ 48 4.4.1.1.7 Questao_has_AlunoBD ......................................................................... 50 4.4.1.2 O pacote servidor ................................................................................... 50 4.4.1.2.1 Registro ................................................................................................. 50 4.4.1.2.2 Servidor Tela ......................................................................................... 51 4.4.1.2.3 Tempo ................................................................................................... 51 4.4.1.2.4 Servidor ................................................................................................. 52 4.4.1 Servidor Web ............................................................................................... 54 4.5 TESTES ......................................................................................................... 60 5 CONCLUSÃO ................................................................................................... 63 5.1 TRABALHOS FUTUROS ............................................................................... 64 REFERÊNCIAS .................................................................................................... 65 APÊNDICES ........................................................................................................ 68

1 INTRODUÇÃO 1.1 CONTEXTUALIZAÇÃO

Para Braga (2013), o processo de ensino-aprendizagem não é garantido somente pelo professor e o seu método didático, o aluno deve participar efetivamente, e a interação mútua é importante para estreitar as relações e maximizar a distribuição do conhecimento. Unindo os quatro elementos do ensinoaprendizagem: o professor, o aluno, o conteúdo e o ambiente, e uma interação saudável entre eles, uma melhoria da qualidade de ensino é alcançada (SANTOS, 2001). A avaliação do processo de ensino é favorável aos alunos e o processo educacional, além do professor, pois permite reformular suas estratégias através de diagnósticos, detectando problemas no método de ensino. Atualmente existem poucas formas de avaliar o professor, como questionários no fim do semestre, com resultados que envolvem todo o conteúdo lecionado pelo professor nesse tempo, generalizando e tirando o foco do problema real. O professor precisa repensar e reconstruir a sua própria didática e para isso, precisa ser avaliado constantemente (DIAS JUNIOR; FERREIRA, 2008). De acordo com Meirelles (et al., 2005) é evidente o surgimento de práticas pedagógicas por meio da observação de teorias de aprendizagem, facilitando a aquisição de conhecimento mediante uso de ambientes virtuais de ensino e aprendizagem com o auxílio de novas tecnologias. O acompanhamento do professor, identificando as dificuldades da turma ou efetuando perguntas sobre um assunto que não seriam feitas pelo aluno, traz uma proximidade que ajuda a atingir os objetivos de ambos. Segundo Valentini e Soares (2005) a mediação dos processos educativos com a tecnologia da informação deve ser planejada cuidadosamente em um ambiente de aprendizagem, envolvendo todas as partes e permitindo a interação contínua visando sempre a transmissão de informações. Justifica-se o trabalho por se tratar de uma ferramenta útil, porém pouco utilizada pelas instituições de ensino. O professor entra na sala de aula, passa o seu conteúdo e a única maneira de quantificar o seu modo de ensino pelo entendimento dos alunos é por meio de testes e avaliações que englobam muitos assuntos, e

mesmo assim o professor não consegue identificar qual é o ponto de maior deficiência dos alunos. Uma ferramenta que envolva a comunicação sem fio e dispositivos móveis, uma tecnologia quase unânime entre os alunos e de rápido retorno para o professor deve acrescer o desempenho tanto do ensino, como de aprendizagem. Ela chega como um suporte para o professor, que pode utilizar os resultados das questões para aprimorar o planejamento de suas aulas.

1.2 OBJETIVOS

1.2.1 Objetivo Geral

Desenvolver uma ferramenta Web que complemente as técnicas pedagógicas do professor no processo de ensino aprendizagem. 1.2.2 Objetivos Específicos 

Construir o sistema utilizando o ciclo de vida de desenvolvimento de software realizando as etapas de: modelagem de negócios, análise de requisitos, projeto, codificação e testes.



Desenvolver um ambiente Web que gerencie o banco de dados e que exiba relatórios de aula e questões de cada turma.



Implementar um sistema de comunicação cliente-servidor, que faça interface com aplicativos Android.

2 REFERENCIAL TEÓRICO

2.1 TECNOLOGIA DA INFORMAÇÃO NO ENSINO APRENDIZAGEM

Segundo Moran (2000), muitos professores e alunos atualmente pensam que a forma de ensino convencional está desatualizada, que o aprendizado está ficando escasso e estão se desmotivando aos poucos. A educação é muito importante para a transformação da sociedade, por isso vem sendo pressionada por mudanças, e com o auxílio de novas tecnologias, espera-se ampliar os conceitos de aula, de espaço e tempo, de comunicação e criar novas conexões entre o presencial e o virtual (MORAN, 2000). O mais importante no processo de ensino-aprendizado não é se preocupar na transmissão do conhecimento do assunto a ser ensinado com excelência, mas sim acompanhar o nível de aprendizagem por parte do aluno. Para uma melhoria nos resultados, o método de ensino deveria, além de utilizar o processo tradicional de aprendizagem, incrementá-lo e facilitá-lo (SANTOS, 2001). Cysneiros (1998) destaca a utilização de projeção de slides utilizando um computador ou notebook como uma inovação utilizada na atualidade. Porém o aluno, inativo pelo fato do ambiente estar geralmente à meia luz para estas apresentações, acaba divagando, deixando o professor lecionando seu conteúdo solitário. Filipetto e Rosa (2012) acreditam que o professor tem o papel de dar oportunidade aos alunos, envolvendo-os na era globalizada em que se encontram, adotando o uso de tecnologias de informação e comunicação dentro e fora da sala de aula. Para Moran (1995), as tecnologias modificariam as responsabilidades do professor, passando as informações, deixando para o professor a tarefa de estimular a curiosidade do aluno de buscar as informações mais relevantes, de pesquisar. De acordo com Liu (2007), um ambiente de aprendizado sem fio oferece muitas oportunidades educacionais que não são encontradas em outros ambientes. Os dispositivos móveis permitem, sem restrições de tempo ou localidade, a aplicação da computação, para ambos os professores e alunos, enquanto a Internet disponibiliza a interconexão entre eles mesmos ou a outros dispositivos (LIU, 2007). Desde a década de 90, já existe a preocupação de inovar o ensinoaprendizado integrando tecnologias que auxiliam o professor a lecionar com mais

eficiência. Destaque para o Peer Instruction, ou Instrução pelos Colegas (IpC), de Eric Mazur, e o Ambiente Virtual de Aprendizagem (AVA). 2.1.1 Instrução pelos Colegas

A Instrução pelos Colegas (IpC), desenvolvida em 1991 por Eric Mazur, na Universidade de Harvard, Estados Unidos, se trata de uma ferramenta de ensinoaprendizado em que o professor utiliza testes conceituais, tradução livre do termo criado por ele, ConcepTests, e debate do conteúdo através de interações com os alunos (OLIVEIRA, 2012). Segundo Lasry (2008), “o método está sendo bem recebido pela comunidade de cientistas e adotado por um grande número de universidades devido, entre outras razões, a sua aproximação com o senso comum e sua efetividade documentada”. O IpC utiliza uma abordagem diferente em sala de aula. Ao invés de utilizar todo o tempo da aula instruindo o conhecimento dos livros, o professor divide o tempo total em pequenos intervalos e o assunto em tópicos, cada tópico o professor faz uma breve apresentação sobre os conceitos principais e em seguida direciona uma questão de múltipla escolha aos alunos. Os alunos recebem um tempo para pensar e responder a questão que achar correta (ARAUJO; MAZUR, 2013). A resposta dos alunos é feita normalmente flashcards (cartões de resposta), um conjunto de cartões representando uma alternativa cada, ou clickers, um equipamento similar a um controle remoto que o aluno envia a resposta via radiofrequência. O professor avalia esse processo instantaneamente, tornando o feedback um recurso precioso para a continuidade da aula (ARAUJO; MAZUR, 2013; OLIVEIRA, 2012). O fato de utilizar tecnologias sem fio ou de outra natureza, além de ser mais prático, não enriquece a aprendizagem no método IpC. De acordo com Mazur (1997, apud. Oliveira, 2012) “é importante notar que o sucesso da Instrução pelos Colegas é independente do tipo do processo de votação, de recursos financeiros e tecnológicos”. Com base no resultado das questões respondidas o professor pode seguir um dos três casos seguintes antes de revelar a resposta correta (ARAUJO; MAZUR, 2013; OLIVEIRA, 2012):



O primeiro caso seria explicar a questão, resolvê-la passo a passo se for necessário, e revelar a alternativa correta, caso o índice de acerto for maior ou igual a 70% das respostas.



No segundo caso, quando o índice de acerto ficar entre 30% e 70% das respostas, o professor sugere que os alunos discutam sobre o assunto entre eles afim de que um convença ao outro que sua escolha é a correta. A seguir o professor reenvia a mesma questão ou envia uma questão similar. Geralmente a porcentagem de acerto aumenta.



Se menos de 30% dos alunos acertarem a questão, geralmente é indicado ao professor que explique o assunto novamente, agora de uma forma diferente, e assim enviar outra questão ainda do mesmo assunto.

Para Oliveira (2012), o sucesso do IpC depende da qualidade das questões escolhidas pelo professor, além de abordar propriamente o assunto escolhido, a questão não pode ser tão difícil ou tão fácil, é importante que parte dos alunos saibam a resposta. A Figura 1 ilustra os passos utilizados na aplicação do método IpC. Figura 1 – Processo de aplicação do método IpC

Fonte: Araujo e Mazur, 2013.

2.1.2 Ambiente Virtual de Aprendizagem

O ambiente virtual de aprendizagem (AVA) é definido por Valentini e Soares (2005) como o “uso de recursos digitais de comunicação utilizados para mediar a aprendizagem”. O AVA utiliza um espaço virtual na Web para desenvolver estratégias e condições que forneçam a construção de conceitos, através de interações entre professores, alunos e o objeto de conhecimento (VALENTINI; SOARES, 2005 ). Segundo Dos Santos (2002), “os AVA agregam interfaces que permitem a produção de conteúdos e canais variados de comunicação, permitem também o gerenciamento de banco de dados e controle total das informações circuladas no e pelo ambiente”. A informação que antes era passada através da pedra e posteriormente do papel, agora é circulada eletronicamente, por meio de textos, imagens, sons, etc. Nem sempre um website educacional, uma tecnologia de realidade virtual, ou uma instituição de ensino virtual se referem especificamente a um AVA. Embora o portal de uma instituição de ensino, que cobre uma variedade de cursos, pode ser considerada uma subcategoria, um AVA pode ser usados para pequenas partes de um currículo. Um AVA integra as tecnologias da informação com as abordagens pedagógicas em um espaço social, ocorrendo interações educacionais, além de incluírem os alunos como atores, ajudando na construção do espaço virtual (DILLENBOURG et al., 2002). O ambiente educacional ainda não foi completamente alterado pela tecnologia, a maioria da comunicação ainda é feita presencialmente da sala de aula, mas os AVA têm proporcionado um aumento no nível de contato e interação dos alunos através do processo de aprendizagem, reestruturando a sua experiência e alavancando as relações entre alunos e professores (PICCOLI et al., 2001 ). É irrelevante comparar a eficiência, separadamente, de um AVA com uma sala de aula tradicional, pois ao fazer essa comparação, estaria insinuando a utilização da tecnologia como ferramenta, a fim de substituir o professor, e não ajudá-lo no auxílio ao processo de ensino. Por isso, o ambiente virtual não tem que imitar a comunicação no espaço real para se tornar mais eficiente, pelo contrário, deve-se buscar a criação de novas formas de aprimorar a experiência da sala de aula (DILLENBOURG et al., 2002).

2.2 MODELO CLIENTE-SERVIDOR

O modelo cliente-servidor é um modelo de interação entre dois programas no qual de um lado um programa cliente solicita um serviço para o programa servidor. Embora existam outros modos de comunicação entre processos, o mais comum é através o modelo cliente-servidor (FOROUZAN, 2007). A aplicação do servidor fica sempre ligada aguardando um contato do cliente, que faz uma requisição e recebe uma resposta do servidor (KUROSE; ROSS, 2012). No Quadro 1 são apresentadas as principais características das aplicações do servidor e do cliente. Quadro 1 – Sumário de servidor e cliente

Servidor Inicia primeiro Não precisa saber a origem do cliente Espera passivamente e relativamente muito tempo por um contato do cliente Comunica com o cliente por envio e recebimento de dados Continua funcionando após termino de conexão com o cliente e aguarda por outro

Cliente Inicia depois Precisa saber qual servidor conectará Inicia um contato no exato momento que precisa de comunicação Comunica com o servidor por envio e recebimento de dados Pode terminar após a interação com o servidor

Fonte: Comer, 2008

2.2.1 Socket

De acordo com Lin, socket é a comunicação de dados entre dois pontos finais criados por aplicações de rede usando um API, na linguagem de programação utilizada. A programação de sockets é diferente das maneiras convencionais pelo fato de especificar alguns detalhes, como endereço de um computador remoto, número de uma porta, ou se a aplicação agirá como cliente ou servidor (COMER, 2008). Para a comunicação entre sockets por protocolo TCP, utilizando o modelo cliente-servidor, oito funções (primitivas) são usadas para uma aplicação básica (TANENBAUM, 2011):  SOCKET – cria um novo terminal de comunicação;  BIND – associa um endereço local com um socket;

 LISTEN – anuncia a disponibilidade para aceitar novas conexões;  ACCEPT – estabelece uma conexão vindoura passivamente;  CONNECT – obtém uma conexão ativamente;  SEND – envia alguns dados pela conexão;  RECEIVE – recebe alguns dados da conexão;  CLOSE – encerra a conexão.

As quatro primeiras primitivas, SOCKET, BIND, LISTEN e ACCEPT, são executadas apenas pelo servidor, enquanto as instruções SOCKET e CONNECT são da parte do cliente, e por fim SEND, RECEIVE e CLOSE são executadas por ambos. A Figura 2 ilustra uma comunicação cliente-servidor por meio de sockets. Figura 2 – Funções socket para um simples programa cliente-servidor TCP

Fonte: Lin et al., 2012

2.3 BANCO DE DADOS

A definição de banco de dados continua sendo muito genérica. Segundo Heuser (2004), o banco de dados denomina-se repositório compartilhador de dados. É caracterizado também por uma estrutura computacional integrada que armazena uma coleção de dados brutos de interesse do usuário final, além de dados sobre dados, gerenciando as informações, como por exemplo, nome de variáveis e os tipos de valores armazenados nessas variáveis (ROB; CORONEL, 2009). Elmasri e Navathe (2010) definem SGBD como “um sistema de software de propósito geral que facilita os processos de definição, construção, manipulação e compartilhamento de bancos de dados entre vários usuários e aplicações”, sendo complementado pela definição de Rob e Coronel (2009), “uma coleção de programas que administram a estrutura do banco de dados, e controlam o acesso de dados armazenados à mesma”. 2.3.1 Modelo Entidade Relacionamento

O modelo Entidade Relacionamento (MER) foi criado como um padrão para a modelagem conceitual e desenvolvido para facilitar o banco de dados, especificando esquemas que representam, especialmente, a sua estrutura lógica. Por sua conveniência em representar os conceitos e interações da realidade em um esquema conceitual, muitas ferramentas para projetos de bancos de dados são fundamentados do modelo ER (HEUSER, 2004; SILBERSCHATZ et al., 2010). Normalmente ele é representado por um diagrama ER, que são notações esquemáticas associadas ao modelo. O modelo contém três elementos básicos: entidade, relacionamento e atributo.

2.3.2 SQL

O SQL (Structured Query Language, traduzido Linguagem de Consulta Estruturada) foi originalmente projetada e implementada pela IBM na década de 1970, com o nome de SEQUEL. Todos os SGBD relacionais tem suporte ao SQL, que se autodenomina a linguagem padrão do banco de dados relacional (ROB; CORONEL, 2009; SILBERSCHATZ et al., 2010).

SQL é uma linguagem de banco de dados abrangente, pois permite determinar, consultar e atualizar dados. Portanto ela se encaixa nas amplas categorias de linguagem de definição de dados (LDD), e de linguagem de manipulação de dados (LMD). Na LLD, contém comandos de criação de objetos, como tabelas, índices, ou comandos para permitir o acesso a esses objetos no BD. Na LMD, dentro das tabelas, utilizam os comandos de inserir, atualizar, excluir e recuperar os dados (ROB; CORONEL, 2009; ELMASRI et al., 2010).

2.4 JAVA

A linguagem de programação Java, inicialmente reconhecida pelo codinome “Green”, partiu de um projeto de pesquisa criado em 1991 por um grupo liderado por James Gosling e Patrick Naughton, pela empresa Sun Microsystems, que em 2009 foi adquirida pela Oracle Corporation. Com a revolução dos microprocessadores na contribuição do desenvolvimento de computadores pessoais, surgiu o Java, baseada em C++ e orientada a objetos (DEITEL, 2012; HORSTMANN, 2009). Enquanto outras linguagens de programação, tais como C e C++, são compilados para modelos particulares de processador ou sistema operacional, o código fonte do Java é compilado em um formato universal, dentro da Máquina Virtual do Java, ou Java Virtual Machine (JVM). O JVM, juntamente com um pacote de APIs (Application Programming Interface), ou Interface de Programação de Aplicativos, compõem o Ambiente de Tempo de Execução do Java, o JRE (Java Runtime Environment) (NIEMEYER; LEUCK, 2013). 2.4.1 Etapas do desenvolvimento de uma aplicação Java

No primeiro passo, a parte de criação do programa em Java, o código fonte será escrito em um editor de texto, obedecendo as regras de sintaxe e semântica do Java. O editor pode ser um programa simples, como o Notepad do Microsoft Windows e gedit do Linux, até os mais completos IDEs (Integrated Development Environments), ou Ambientes Integrados de Desenvolvimento, como o Eclipse e o Netbeans. O nome do arquivo deve ser o mesmo nome da classe principal do programa, com a extensão “.java” indicando que é o arquivo do código fonte do Java (DEITEL, 2012; HORSTMANN, 2009).

Quando o programa está pronto, o próximo passo é compilá-lo, isto é, a tradução do código fonte, pelo compilador javac embutido no JDK, para a criação de um arquivo de extensão “.class” e traduzido em bytecodes, que consistem em instruções da máquina virtual (JVM) necessárias para a execução da aplicação (DEITEL, 2012; HORSTMANN, 2009). Segundo Deitel (2012), JVM “é uma aplicação que simula um computador, mas oculta o sistema operacional e o hardware subjacentes dos programas que interagem com ela” O compilador não criará o arquivo se encontrar erros no programa. A Figura 3 ilustra todo o processo, do código fonte ao aplicativo em execução. Figura 3 – Do código fonte à execução do programa

Fonte: Horstmann, 2009

2.4.2 Características do Java

Apesar de ser baseada em C++, o Java foi projetado para ser especificamente mais simples, com um tamanho menor e mais confiável do que as linguagens já existentes na época. Para isso foi eliminado quase metade de recursos similares aos do C++ para garantir um passo adiante a uma maior confiabilidade (SEBESTA, 2009). Como o Java foi desenvolvido primeiramente para a Internet, duas características deveriam ser apropriadas para a linguagem: segurança e portabilidade. O sucesso da portabilidade do Java é atribuído à sua linguagem, mas o fato que torna esse fator bem sucedido é o interpretador da máquina virtual (JVM). Os aplicativos em Java agora são traduzidos para a linguagem de máquina antes de serem executados utilizando um compilador Just-in-time (JIT), ou seja, em tempo de execução, deixando sua eficiência competitiva com as outras linguagens. Além do

mais, o programa será executado, sem mudança no código, por diversos sistemas operacionais e em navegadores para os aplicativos do Java em ambiente Web, chamados applets (HORSTMANN, 2009; SEBESTA, 2009).

2.5 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE

Dependendo do tipo de software a ser dependido e estrutura organizacional envolvida, as atividades do processo de desenvolvimento variam, se adaptando aos objetivos necessários à realização do trabalho. Para o trabalho presente, é feito o modelo evolucionário dos seguintes processos: modelagem de negócios, análise de requisitos, projeto, codificação e testes (SOMMERVILLE, 2011). A modelagem de negócios define-se como a abstração dos dados relativa aos negócios que utilizam a tecnologia da informação, eliminando detalhes irrelevantes e sempre se baseia nos aspectos mais importantes, buscando os requisitos em um sistema. O modelo de negócios funciona na ação de tomada de decisões priorizando as metas, negociando com os contratantes e utilizando os recursos apropriados (ERIKSSON, 2000). A análise e especificação de requisitos são responsáveis por especificar as características, restrições e interações que o software deve possuir.

Pressman

(2011) adiciona que o modelo de requisitos expõe as solicitações dos clientes, formam a base para o projeto do sistema e define os requisitos que serão validados após a construção do software. São classificadas em requisitos funcionais e requisitos não funcionais Os requisitos funcionais é uma lista de serviços que determina como o sistema deve se comportar em situações específicas e os requisitos não funcionais são as funcionalidades oferecidas por um sistema como um todo (SOMMERVILLE, 2011). O projeto é um processo que inicia a estruturar o sistema pela interpretação dos requisitos. Para o trabalho foi utilizado os seguintes projetos: projeto de dados, projeto de arquitetura, projeto procedimental e projeto de interface. O projeto de dados cria um modelo de dados e então é refinado em etapas mais específicas, sendo fundamental para a implementação do banco de dados do sistema. O projeto de arquitetura equivale a um detalhamento gráfico da estrutura de um sistema, dividindo-o em módulos e camadas. O projeto de interface representa a interação do sistema com o usuário ou com os elementos externos e internos que o compõem.

Por fim o projeto procedimental, ou de componentes transforma a arquitetura do sistema em um conjunto de descrições de procedimentos que ocorrem no software (PRESSMAN, 2011; SOMMERVILLE, 2011). A implementação, ou codificação, do sistema utiliza

dos

projetos

para

programar a interface do sistema, o acesso aos dados, detalhando cada componente especificado nas fases anteriores até que cumpra com o que foi proposto (SOMMERVILLE, 2011). Segundo Pressman (2011), teste são atividades que podem ser predefinidas ou sistemáticas, com o objetivo de verificar se o código fonte foi implementado com sucesso. Para o trabalho foram utilizados o teste unitário, que testa as classes e métodos individualmente, e o teste de sistema, que verifica os requisitos e testa o programa como um todo quando este já se encontra integrado com possíveis elementos externos (SOMMERVILLE, 2011).

3 METODOLOGIA

3.1 TIPO DE PESQUISA QUANTO AOS OBJETIVOS

Para o desenvolvimento do projeto foram realizadas pesquisas exploratórias e descritivas. O planejamento da pesquisa exploratória segundo Gil (2002) é “bastante flexível, de modo que possibilite a consideração dos mais variados aspectos relativos ao fato estudado”. Na parte exploratória, utilizou-se de entrevistas com o orientador da monografia, visando capturar as informações sobre a natureza e estrutura do sistema de software desenvolvido. Também foram utilizadas consultas em fontes bibliográficas que abordam a utilização de tecnologia da informação para auxiliar o método de ensino-aprendizado em salas de aula. De acordo com Barros e Lehfeld (2007), a pesquisa descritiva descreve o objeto as ser pesquisado, buscando determinar suas características, causas, etc. Ela foi representada pela descrição das características do sistema, seguindo o ciclo de vida do desenvolvimento de software.

3.2 TIPO DE PESQUISA QUANTO À ABORDAGEM

Nas fases em que foram utilizadas as pesquisas exploratórias foi feita a aplicabilidade da análise qualitativa. A análise qualitativa envolve a observação e interpretação dos dados a serem utilizados, dependendo dos fatores, como os instrumentos de pesquisa e categorização de conteúdo (GIL, 2002).

3.3 TIPO DE PESQUISA QUANTO AOS PROCEDIMENTOS TÉCNICOS

Para a realização dos procedimentos técnicos foi utilizada a pesquisa básica. Para Moresi (2003), a pesquisa básica “objetiva gerar conhecimentos novos úteis para o avanço da ciência sem aplicação prática prevista. Envolve verdades e interesses universais”.

3.4 INSTRUMENTOS DE PESQUISA

Para o desenvolvimento da ferramenta foram utilizadas:



Modelagem UML – Astah Community



Diagrama Entidade Relacionamento – MySQL Wokrbench



Banco de Dados – MySQL



Linguagem de programação – Java



Codificação do software – Eclipse IDE



Ferramenta de teste - JUnit



Servidor Web – VertrigoServ



Desenvolvimento das páginas dinânmicas (PHP) – Adobe Dreamweaver

3.5 PERÍODO DE EXECUÇÃO DA PESQUISA

A pesquisa foi feita entre os meses de agosto e novembro de 2013, sempre na cidade de Vitória da Conquista –BA.

4 DESENVOLVIMENTO

4.1 MODELAGEM DE NEGÓCIOS

A proposta do desenvolvimento da ferramenta partiu-se da observação da relação entre o professor e alunos na sala de aula e da ideia de incorporar as tecnologias vigentes numa maneira de auxiliar o processo de ensino aprendizagem. O propósito do sistema é gerenciar e auxiliar a comunicação entre dois clientes, professor e aluno, em uma ferramenta que serve de feedback instantâneo a respeito do entendimento dos alunos em relação ao conteúdo ministrado pelo professor. O projeto é viável por se tratar de um meio de comunicação entre dispositivos desde que mantenha a integridade dos dados.

4.2 ANÁLISE DE REQUISITOS 4.2.1 Introdução

Essa etapa do sistema especifica as funcionalidades do Servidor Quiz, apresentando

informações

necessárias

para,

futuramente,

projeto

desenvolvimento do sistema, até finalmente a fase de testes. A organização dos dados envolvidos no processo facilitam o entendimento do que foi proposto e as decisões que serão tomadas adiante.

4.2.2 Prioridades dos requisitos Para determinar as prioridades dos requisitos, as categorias “essencial”, “importante” e “desejável” foram incluídas. 

Essencial – requisito necessário para o funcionamento do sistema.



Importante – requisito de suma importância, o sistema funciona sem ele, mas de maneira ineficaz.



Desejável – o sistema funciona de maneira eficaz sem ele, devido à falta de tempo, pode ser deixado para as próximas atualizações de sistema.

4.2.3 Requisitos do software

Nessa seção serão especificados os requisitos funcionais e não-funcionais identificados para o desenvolvimento do sistema.

4.2.3.1 Requisitos funcionais

[RF001]

Utilizar um identificador

O servidor deverá identificar, com um código, cada requisição recebida pelos clientes (professor e aluno), a fim de facilitar a comunicação entre ambos. Prioridade:

[RF002]

 Essencial

 Importante

 Desejável

Efetuar login

O servidor deverá permitir o acesso dos usuários, através do login e senha de cada, às suas funcionalidades autorizadas. Prioridade:

[RF003]

 Essencial

 Importante

 Desejável

Acessar o Banco de Dados

O servidor realizará as operações de consulta, inserção e exclusão de dados no banco de dados referente às solicitações dos clientes. Prioridade:

[RF004]

 Essencial

 Importante

 Desejável

Registrar acessos

O servidor registrará os acessos e solicitações de cada cliente em um arquivo de texto. Prioridade:

[RF005]

 Essencial

 Importante

 Desejável

Enviar questão

O servidor permitirá ao professor enviar apenas uma questão por vez, podendo enviar uma nova questão após o término do tempo de duração da anterior. Prioridade:

 Essencial

 Importante

 Desejável

[RF006]

Evitar enviar uma questão mais de uma vez

O servidor permitirá ao cliente professor enviar cada questão somente uma vez. Quando enviada, ela será desativada para envio. Prioridade:

[RF007]

 Essencial

 Importante

 Desejável

Responder questão

O servidor permitirá ao cliente aluno responder cada questão uma vez e somente se o aluno estiver cadastrado na turma da questão enviada. Prioridade:

[RF008]

 Essencial

 Importante

 Desejável

Computar questão

O servidor computará a resposta da questão do cliente aluno apenas dentro do tempo estipulado pelo cliente professor. Prioridade:

 Essencial

 Importante

 Desejável

4.2.3.2 Requisitos não funcionais

4.2.3.2.1 Requisitos de processo

Os requisitos de processo são medidas adotadas para o desenvolvimento do servidor.

[RNF001]

Linguagem de programação

O servidor será desenvolvido na linguagem de programação Java. Prioridade:

[RNF002]

 Essencial

 Importante

 Desejável

Banco de dados

Os dados do sistema serão armazenados e gerenciados pelo SGBD MySQL. Prioridade:

[RNF003]

 Essencial

 Importante

 Desejável

Modelagem

O sistema deverá ser modelado utilizando a linguagem UML. Prioridade:

 Essencial

 Importante

 Desejável

4.2.3.2.2 Requisitos de produto

Os requisitos de produto especificam as características do servidor.

[RNF004]

Confidencialidade

O servidor não deverá informar aos clientes (professor e aluno) nenhuma informação sobre turmas, aulas, e questões em que não estejam cadastrados. Prioridade:

[RNF005]

 Essencial

 Importante

 Desejável

Autenticação

O servidor permitirá acesso aos usuários do sistema apenas se possuírem login e senha cadastrados no referente aplicativo cliente. Prioridade:

[RNF006]

 Essencial

 Importante

 Desejável

Multiplataforma

Por ser em Java, o servidor deve funcionar em quase todos os sistemas operacionais. Prioridade:

[RNF007]

 Essencial

 Importante

 Desejável

Tempo de Resposta

O servidor deverá enviar a resposta paras os clientes em no máximo 5 segundos. Prioridade:

[RNF008]

 Essencial

 Importante

 Desejável

Concorrência

O sistema deverá suportar a carga de até 50 acessos simultâneos. Prioridade:

 Essencial

 Importante

 Desejável

4.2.4 Diagrama de classes

O diagrama de classes representa a estrutura dos dados que circulam pelo servidor e que sĂŁo enviados e recebidos pelos clientes. A Figura 4 demonstra o diagrama utilizado para a arquitetura do banco de dados do sistema. Figura 4 â&#x20AC;&#x201C; Diagrama de classes do servidor

Fonte: Autoria PrĂłpria, 2013

4.2.5 Diagrama de Caso de Uso

4.2.5.1 Atores

Ator

Descrição

Servidor

Representa a aplicação do servidor

Professor

Representa o aplicativo cliente do professor

Aluno

Representa o aplicativo cliente do aluno

4.2.5.2 Diagrama Figura 5 – Diagrama de Caso de Uso

Fonte: Autoria Própria, 2013

4.2.5.3 Descrição dos Casos de Uso

Número do Caso de Uso Nome do Caso de Uso Ator(es) Descrição

Pré-condições Pós-condições Cenário principal

Cenário alternativo Exceções Inclusão (includes) Extensões (extend)

Número do Caso de Uso Nome do Caso de Uso Ator(es) Descrição Pré-condições Pós-condições Cenário principal

Cenário alternativo Exceções Inclusão (includes) Extensões (extend)

UC001 Efetuar Login Servidor, Professor Este caso de uso tem por objetivo permitir a autenticação do cliente professor cadastrado no sistema. O professor deverá estar cadastrado no sistema. O servidor envia o nome do professor para as boas vindas. 1- O usuário envia a solicitação de login ao servidor, além do login e senha. 2- O servidor verifica se a senha é correta para o nome do usuário especificado. (EXC001) Não há. EXC001 – Se o usuário ou senha estiverem incorretos, enviar uma mensagem de erro. Não há. Não há.

UC002 Gerenciar turmas Servidor, Professor Este caso de uso tem por objetivo gerenciar as turmas equivalentes ao professor conectado. O professor deverá ter efetuado o login. (UC001) Não há. 1- O usuário envia a solicitação de turmas ao servidor. 2- O servidor envia as turmas do professor conectado. (EXC001) 3- A lista de turmas será ordenada pelo nome da turma Não há. EXC001 – Se o professor não tiver turma cadastrada no sistema, enviar uma lista vazia. UC001 – Efetuar Login UC003 – Selecionar turma

Número do Caso de Uso Nome do Caso de Uso Ator(es) Descrição Pré-condições Pós-condições Cenário principal

Cenário alternativo Exceções Inclusão (includes) Extensões (extend)

Número do Caso de Uso Nome do Caso de Uso Ator(es) Descrição Pré-condições Pós-condições Cenário principal

Cenário alternativo

Exceções Inclusão (includes) Extensões (extend)

UC003 Selecionar turma Servidor, Professor Este caso de uso tem por objetivo selecionar a turma desejada. Deve haver ao menos uma turma na lista. (UC002) Não há. 1- O usuário solicita ao servidor as aulas e envia o identificador da turma escolhida. 2- O servidor seleciona as aulas da turma escolhida. (UC004) Não há. Não há Não há. Não há.

UC004 Gerenciar aula Servidor, Professor Este caso de uso tem por objetivo gerenciar as aulas equivalentes à turma escolhida. O professor deverá ter selecionado uma turma. (UC003) Não há. 1- O usuário envia a solicitação de aulas ao servidor. 2- O servidor consulta e envia uma lista de aulas do professor conectado. (EXC001) 3- A lista de aulas está ordenada pela data da aula. 4- O professor seleciona a aula. (CA001, CA002, CA003) CA001 – O professor cadastra uma nova aula. CA002 – O professor edita uma aula existente. CA003 – O professor exclui uma aula existente. EXC001 – Se o professor não tiver uma aula cadastrada no sistema, enviar uma lista vazia. Não há. UC005 - Selecionar aula

Número do Caso de Uso Nome do Caso de Uso Ator(es) Descrição Pré-condições Pós-condições Cenário principal

Cenário alternativo Exceções Inclusão (includes)

Número do Caso de Uso Nome do Caso de Uso Ator(es) Descrição Pré-condições Pós-condições Cenário principal

Cenário alternativo

Exceções Inclusão (includes) Extensões (extend)

UC005 Selecionar aula Servidor, Professor Este caso de uso tem por objetivo selecionar a aula desejada. Deve haver ao menos uma aula na lista. (UC004) O usuário envia ao servidor o número identificador da aula escolhida. 1- O usuário solicita ao servidor as questões e envia o identificador da aula escolhida. 2- O servidor seleciona as questões da aula escolhida. (UC006) Não há. Não há. Não há.

UC006 Gerenciar questão Servidor, Professor Este caso de uso tem por objetivo listar as questões equivalentes à aula escolhida. O professor deverá ter selecionado uma aula. (UC008) Não há. 1- O usuário envia a solicitação de questões ao servidor. 2- O servidor consulta e envia uma lista de questões do professor conectado. (EXC001) 3- O professor envia uma questão. (CA001, CA002, CA003, CA004) CA001 – O professor cadastra uma nova questão. CA002 – O professor edita uma questão existente. CA003 – O professor exclui uma questão existente. CA003 – O professor exibe o relatório de uma questão existente. EXC001 – Se o professor não tiver uma questão cadastrada no sistema, enviar uma lista vazia. Não há. UC007 – Enviar questão

Número do Caso de Uso Nome do Caso de Uso Ator(es) Descrição Pré-condições Pós-condições Cenário principal

Cenário alternativo Exceções

Inclusão (includes) Extensões (extend)

Número do Caso de Uso Nome do Caso de Uso Ator(es) Descrição Pré-condições Pós-condições Cenário principal

Cenário alternativo Exceções Inclusão (includes) Extensões (extend)

UC007 Enviar questão Servidor, Professor, Aluno Este caso de uso tem por objetivo enviar a questão escolhida aos alunos. Deve haver ao menos uma questão na lista. (UC006) O servidor retorna uma mensagem de confirmação. 1- O usuário envia ao servidor a solicitação de envio de questão, além do número identificador da questão escolhida e o tempo de duração. (EXC001, EXC002) 2- O servidor ativa a questão, deixando visível para o aluno que está cadastrado nela. Não há. EXC001 – Se houver uma questão ativa no servidor, o servidor envia um alerta. EXC002 – Se a questão já foi enviada antes, o servidor envia um alerta. Não há. Não há.

UC008 Efetuar login do aluno Servidor, Aluno Este caso de uso tem por objetivo permitir a autenticação do cliente aluno cadastrado no sistema. O aluno deverá estar cadastrado no sistema. Não há. 1- O usuário envia a solicitação de login ao servidor, além do RA e a senha. 2- O servidor verifica se a senha é correta para o nome do usuário especificado. (EXC001) Não há. EXC001 – Se o usuário ou senha estiverem incorretos, enviar uma mensagem de erro. Não há. Não há.

Número do Caso de Uso Nome do Caso de Uso Ator(es) Descrição Pré-condições Pós-condições Cenário principal

Cenário alternativo Exceções

Inclusão (includes) Extensões (extend)

UC009 Responder questão Servidor, Aluno Este caso de uso tem por objetivo receber e responder a questão enviada pelo cliente professor. O aluno deverá ter efetuado o login. (UC008) O servidor retorna uma mensagem de confirmação. 1- O usuário envia a solicitação da questão ao servidor. 2- O servidor envia a questão ativada pelo professor. (EXC001) 3- O usuário envia a solicitação de resposta, além da resposta da questão ao servidor. 4- O servidor registra a resposta do aluno no banco de dados. (EXC002, EXC003) Não há. EXC001 – Se o professor não tiver uma questão cadastrada no sistema, enviar uma questão vazia. EXC002 – Se o tempo da questão se esgotou no servidor, servidor envia um alerta. EXC0023– Se o aluno tentar responder novamente a mesma questão, servidor envia um alerta. UC008 - Efetuar login do aluno Não há.

4.3 PROJETO 4.3.1 Projeto de Dados

4.3.1.1 Descrição do banco de dados

O sistema Servidor Quiz busca permitir a intercomunicação entre seus clientes, o professor e o aluno. Assim, o professor pode enviar questões aos alunos sobre o assunto que está sendo lecionado, e obter uma resposta sobre a eficiência da sua didática. De acordo com o número de questões acertadas, o professor pode presumir o nível de entendimento dos alunos sobre aquele assunto, ou aquela aula, ou ainda toda a turma ao longo do semestre letivo. O papel que o servidor desempenhará será o de controle da comunicação e gerenciamento de dados dos clientes.

4.3.1.1.1 Descrição dos dados do sistema 

Uma turma é composta pelo ano e o semestre letivo, um curso, uma disciplina, um turno e um professor.



Um professor é caracterizado pelo seu nome, um nome de usuário (login), e a senha de acesso.



Um aluno é representado pelo seu registro acadêmico (RA) e sua senha de acesso.



Uma aula é composta pela data que será realizada e o assunto que será lecionado.



Uma questão contém um enunciado, três alternativas, uma resposta correta, um indicador de que ela está disponível para os alunos, a data em que a questão foi enviada pelo professor, o tempo de duração para ser respondida e um identificador de que ela foi enviada.

4.3.1.1.2 Relacionamentos entre os dados 

Uma turma contém várias aulas, mas uma aula pertence a somente uma turma.



Cada turma tem um professor, e o professor pode lecionar em várias turmas.



Uma turma é composta por vários alunos, e cada aluno frequenta várias turmas.



Cada aula possui muitas questões, e cada questão pertence a somente uma aula.



Uma questão é respondida por vários alunos, e um aluno responde muitas questões.

4.3.1.1.3 Consultas

O servidor recebe as solicitações dos clientes e é responsável por lidar com o banco de dados. A cada consulta realizada, o servidor enviará a resposta de acordo à solicitação feita.



Verificar a autenticidade no login dos clientes professor e aluno.



Listar as turmas do professor.



Listar as aulas da turma solicitada pelo professor.



Listar as questões da aula solicitada pelo professor.



Disponibilizar a questão escolhida pelo professor no servidor, pelo tempo determinado.



Enviar a questão disponível para o aluno responder.



Enviar ao professor o relatório da questão escolhida.

4.3.1.2 Estruturas de Dados

Toda a comunicação do servidor com os clientes é feita utilizando o protocolo TCP por meio de sockets. Os dados trocados pelos dois são organizados em Arrays, unidimensionais ou multidimensionais, de Strings, transformados em variáveis do tipo Object. As formas de envio e recebimentos de dados são feitos por ObjectOutputStream e ObjectInputStream, respectivamente. Na parte em que ocorre o registro da comunicação com o servidor, utiliza-se PrintStream e BufferedReader para escrever e ler em um arquivo de texto. O servidor Web se comunica com o banco de dados por meio do PHP. A Figura 6 exemplifica a estrutura de dados do servidor, demonstrando uma simples aplicação do ServerSocket, realizando a conexão, utilizando a forma de transmissão aplicada no trabalho. Figura 6 – Exemplo de uma aplicação ServerSocket

Fonte: Autoria Própria, 2013

4.3.1.3 Diagrama Entidade Relacionamento

O diagrama ER foi modelado baseando-se no diagrama de classes UML na fase de requisitos. O BD representa a parte acadêmica de uma instituição, com a centralização da turma para o propósito do trabalho, lembrando que é responsabilidade do administrador do servidor cadastrar os dados referentes à instituição: cursos, disciplinas, professores, alunos, turnos e turmas. Na turma é feito o cadastrado do professor, do curso, da disciplina, do turno, de um nome fantasia representando-a, além do ano e semestre vigente. A partir da turma criada, é feito o cadastro dos alunos e das aulas dessa turma, as questões são cadastradas na aula desejada e, finalmente, na medida em que as questões são enviadas aos alunos, é registrada a resposta dada pelo aluno para o professor poder contabilizar a quantidade de acertos. A Figura 7 ilustra o diagrama feito na ferramenta MySQL Workbench. Figura 7 – Diagrama Entidade Relacionamento do sistema

Fonte: Autoria Própria, 2013

4.3.2 Projeto de Arquitetura

A arquitetura do projeto é composta por dois módulos: o módulo cliente e o módulo servidor. O módulo cliente contém as aplicações do professor e do aluno. O módulo servidor é formado também por duas aplicações: uma aplicação em Java responsável pela comunicação com os clientes e com o SGBD MySQL, além do servidor Web gerenciador dos dados do sistema. Os módulos se intercomunicam através do uso de sockets em Java pelo protocolo TCP. O servidor em Java, orientado a objetos, possui três camadas: a camada UI (Interface com o Usuário) por meio da biblioteca Java Swing, a camada de negócios e comunicação utilizando a biblioteca Java ServerSocket e FileOutputStream, e finalmente a camada de dados com o auxílio do Java JDBC. A Figura 8 demonstra a arquitetura como um todo. Figura 8 – Arquitetura do Sistema

Fonte: Autoria Própria, 2013

4.3.3 Projeto Procedimental

Na descrição dos procedimentos do sistema, apenas o módulo do servidor será especificado. O servidor na maioria do tempo fica em modo de espera,

aguardando conexão dos clientes, às vezes múltiplos ao mesmo tempo, por isso o servidor utiliza Threads para executá-las concorrentemente, ou seja, vários clientes simultaneamente. Os seguintes passos definem o ciclo de vida do servidor. 

Ao abrir o programa, o ServerSocket é iniciado, a tela do servidor é aberta e o valor 2525 é enviado para abrir a porta.



Ao abrir a porta, o servidor é iniciado e entra no modo de espera, aguardando conexões do cliente, as informações são exibidas na tela além de ativar a inicialização da thread.



O servidor inicia a thread através do método run() e entra em um laço que inicia a conexão com o cliente e recebe um código de solicitação.



Ao receber o código, o mesmo passa por uma seleção, para que seja executado de acordo com a sua condição.



Se o código corresponde a um dos identificadores, então é direcionada a uma rotina, caso contrário, é enviado um código de erro ao cliente.



A rotina realiza a operação no banco de dados de acordo com o que foi solicitado e coleta os dados a serem enviados ao cliente.



Ao enviar os dados ao cliente, volta-se ao laço, aguardando uma nova conexão.



Ao fechar a tela do servidor, o laço será interrompido, os serviços serão finalizados propriamente, encerrando o servidor, e finalmente a tela será fechada.

4.3.4 Projeto de Interface

Para projetar a interface tanto do Servidor Java quanto do Servidor Web, foi analisados os requisitos de Interface Humano-Computador (IHC) e usabilidade. O Servidor Java possui apenas uma janela, com uma estrutura simples, sem muita interatividade, e o processo de inicialização é automático, facilitando ao usuário, que apenas precisa abrir a janela do servidor para deixá-lo funcionando. O registro do servidor dá um suporte ao usuário, mantendo o histórico das operações realizadas, caso necessite de uma auditoria.

Foi observada também a usabilidade na parte do Servidor Web. As páginas seguem um padrão para que o usuário consiga identificar os dados baseando-se nas páginas visitadas anteriormente. Na parte superior da página possui um indicador da página atual, além do indicador da página inicial e da página originadora da atual, proporcionando uma navegabilidade mais eficaz do usuário. As caixas de diálogo orientam a operação escolhida pelo usuário, que interage com o servidor através dos formulários de cadastros, por botões de editar e excluir e por links que direcionam para a página escolhida. Finalmente a utilização de gráficos para ilustrar os resultados ao usuário de maneira que facilite a vizualização.

4.4 CODIFICAÇÃO

Na fase de codificação o software foi desenvolvido de acordo com as especificações das fases anteriores. O servidor consiste em duas aplicações: o servidor desenvolvido na linguagem de programação Java, que se encarrega de se comunicar com os clientes e interagir com o banco de dados, e o servidor web, que é encarregado somente de gerenciar os dados diretamente com o banco de dados. 4.4.1 Servidor Java

O servidor Java foi desenvolvido utilizando a plataforma Eclipse IDE, necessitando incluir um driver para permitir a comunicação entre o Java e o banco de dados MySQL. Foi criado um projeto na plataforma, com o nome de ServidorQuiz. O projeto consiste em dois pacotes, o pacote de operações no banco de dados e o pacote onde contém o servidor socket, a interface gráfica e o relatório. A Figura 9 ilustra a estrutura do projeto com os pacotes, classes, driver e o registro em arquivo de texto. 4.4.1.1 O pacote bd (banco de dados)

O pacote bd é onde acontece a interação do servidor com o banco de dados. Esse pacote corresponde à camada de dados na arquitetura do servidor.

Figura 9 – Estrutura do projeto ServidorQuiz

Fonte: Autoria Própria, 2013

4.4.1.1.1 ConexaoBD

A primeira classe a ser mencionada é responsável pela conexão ao banco de dados MySQL. Nesse projeto, para a comunicação com o banco de dados será a porta 3333, diferente da porta padrão, a 3306. A conexão é feita pelo usuário root, com a senha toor. Todas as outras classes do pacote bd utilizam a conexão por essa classe. A Figura 10 demonstra a classe ConexaoBD, com suas bibliotecas incluídas e os dados citados acima. Figura 10 – Arquivo de conexão ao MySQL ConexaoBD.java

Fonte: Autoria Própria, 2013

4.4.1.1.2 AlunoBD

A classe AlunoBD é responsável pelas consultas referentes ao aluno e aparece em duas ocasiões: na primeira, é responsável em fazer a autenticação do cliente aluno e na segunda é consultado o identificador de cada aluno para registrar a resposta de uma questão. Os métodos utilizados nessa classe estão do quadro 2. Quadro 2 – Métodos utilizados na classe AlunoBD

Método consultaRA consultaSenha getRaPeloId

Descrição Dado um RA, verifica se ele consta no banco de dados. Dado o RA do aluno, verifica se a senha está correta. Pelo RA do aluno, retorna o id correspondente.

Fonte: Autoria Própria, 2013

4.4.1.1.3 ProfessorBD

Similar à classe do aluno, o ProfessorBD também é responsável pela autenticação do cliente professor, além de retornar o nome na mensagem de boas vindas assim que efetua o login. O quadro 3 mostra os métodos da classe. Quadro 3 – Métodos utilizados na classe ProfessorBD

Método consultaLogin consultaSenha consultaNome

Descrição Dado um login, verifica se ele consta no banco de dados. Dado o login do progessor, verifica se a senha está correta. Pelo login do professor, retorna o seu nome.

Fonte: Autoria Própria, 2013

4.4.1.1.4 TurmaBD

Referente às turmas lecionadas pelo professor, sua finalidade é enviar ao professor suas turmas com informações como o semestre e ano letivos, o nome da turma, geralmente contendo o nome da disciplina, e o turno. O quadro 4 exibe dois métodos, um sendo interno, pois as turmas são enviadas para o cliente em forma de matriz, e para inicializar a matriz é preciso saber o seu tamanho.

Quadro 4 – Métodos utilizados na classe TurmaBD

Método getNum

getTurmas

Descrição Dado o login do professor, retorna o número de turmas ativas que ele possui. Utilizado pelo método getTurmas. Dado o login do professor, retorna as turmas ativas que ele possui. Envia uma matriz contendo em uma linha os ids de cada turma e na outra as informação da turma: ano e semestre letivos, nome da turma e turno.

Fonte: Autoria Própria, 2013

4.4.1.1.5 AulaBD

A aula contém uma interação maior com o professor, além de enviar as aulas da turma selecionada, existe a opção de adicionar, editar e excluir aulas. Por também enviar uma matriz, existe um método que faz a contagem de aulas de uma determinada turma. A seguir no quadro 5 as informações da classe AulaBD. Quadro 5 – Métodos utilizados na classe AulaBD

Método adiciona edita exclui getNumIdTurma

getAulaIdTurma

Descrição Recebe uma data, um assunto e o id da turma em que vai incluir e adiciona a aula no banco. Recebe uma data, um assunto e o id da aula e edita a aula no banco. Recebe o id da aula e a exclui do banco. Dado o id de uma turma, retorna o número de aulas que ela possui. Utilizado pelo método getAulaIdTurma. Dado o id de uma turma, retorna as aulas que ela possui. Envia uma matriz contendo em uma linha o id da turma, em outro os ids das aulas e por último, as informação da aula: a data e o assunto.

Fonte: Autoria Própria, 2013

4.4.1.1.6 QuestaoBD

É a classe com mais métodos e também a mais solicitada, pois ambos os clientes, professor e aluno, realizam requisições dela. Enquanto o professor escolhe e envia uma questão, o aluno aguarda o envio e responde essa questão. Além de conter os métodos de adicionar, editar e excluir, diversos métodos integram as

partes do envio por parte do professor e do recebimento por parte do aluno. Essa lógica será explicada detalhadamente na classe do Servidor. Enquanto isso, os métodos utilizados na classe estão no quadro 6. Quadro 6 – Métodos utilizados na classe QuestaoBD

Método adiciona edita exclui getQuestao getNum getNumRA getRAs

getQuestoes

setQuestao setEnviado setDuracao getLancamento getDuracao podeReceber foiEnviado podeEnviar desativarTodas

Descrição Recebe o enunciado, três alternativas, a resposta e o id da aula em que vai incluir e adiciona a questão no banco. Recebe o enunciado, três alternativas, a resposta e o id da aula e edita a questão no banco Recebe o id da questão e a exclui do banco. Seleciona a questão que está ativa no servidor para o aluno Dado o id de uma aula, retorna o número de questões que ela possui. Utilizado pelo método getQuestoes. Dado o id de uma questão, retorna o número de alunos que estão cadastrados na turma vinculada a ela. Utilizado pelo método getRAs. Dado o id de uma questão, retorna os alunos que estão cadastrados na turma vinculada a ela. Dado o id de uma aula, retorna as questões que ela possui. Envia ao professor uma matriz contendo em uma linha o id da turma, no próximo o id da aula, em outro os ids das questões, o enunciado, as alternativas e a resposta. Dado o id de uma questão, ativa ela, deixando disponível para o aluno responder. Ao deixar questão ativa, dado o id da questão e a hora da ativação, inclui o dia e hora do envio. Ao deixar questão ativa, dado o id da questão e a hora da ativação, inclui a duração que a questão ficará ativa. Dado o id de uma questão, retorna o dia e hora em que ela foi enviada. Dado o id de uma questão, retorna o tempo de duração que ela ficou ativa. Pelo RA, o cliente aluno verifica se possui uma questão de sua turma ativa no servidor. Dado o id de uma questão, verifica se ela já foi enviada. Dado o id de uma questão, verifica se ela pode ser enviada. Dado o login, desativa todas as questões de um professor no servidor.

Fonte: Autoria Própria, 2013

4.4.1.1.7 Questao_has_AlunoBD

Essa classe também é bem usada, pois ela cadastra as respostas dos alunos nas questões enviadas e é responsável por consultar o resultado para enviar o relatório ao professor. O quadro 7 demonstra seus métodos. Quadro 7 – Métodos utilizados na classe Questao_has_AulaBD

Método addRAsQuestao addResposta duplicado getResposta getTotal getCertas getErradas getNulas

Descrição Dado o RA do aluno e o id da questão, o aluno é cadastrado na questão. Dado o RA do aluno, o id da questão e alternativa escolhida pelo aluno, a resposta é cadastrada na questão. Dado o RA do aluno e o id da questão, é verificado se o aluno já está cadastrado na questão. Dado o RA do aluno e o id da questão, a resposta do aluno é selecionada. Dado o id da questão, é retornado o número de alunos cadastrados na questão. Dado o id da questão, é retornado o número de alunos que acertaram a questão. Dado o id da questão, é retornado o número de alunos que erraram a questão. Dado o id da questão, é retornado o número de respostas nulas na questão.

Fonte: Autoria Própria, 2013

4.4.1.2 O pacote servidor

O pacote servidor é onde acontece a interação do servidor com as aplicações dos clientes. Esse pacote corresponde à camada de negócios comunicação na arquitetura do servidor. 4.4.1.2.1 Registro

A classe Registro é responsável por armazenar as informações que são passadas pelo servidor, em um arquivo de texto, e de atualizar a tela do servidor com mais informações. A cada registro feito, é capturada a data e hora de que foi realizado. O método escrever se encarrega de executar essas tarefas. A Figura 11 mostra o funcionamento da classe, abrindo o arquivo de texto, colhendo a hora da

mensagem e gravando no arquivo, além de enviar a mesma informação para o ServidorTela demonstrar na janela do servidor. Figura 11 – Registro do Servidor Quiz

Fonte: Autoria Própria, 2013

4.4.1.2.2 ServidorTela

Responsável pela interação com o usuário, a janela foi desenvolvida utilizando a biblioteca Swing do Java e contém apenas dois métodos: o ServidorTela, o método construtor da classe e responsável pelos componentes da janela e suas funcionalidades, e o addLog, o método que atualiza a área de texto, adicionando as informações enviadas pelo Registro. A dimensão da janela é de 800x600 pixels para que possa utilizar uma fonte maior no texto e também para funcionar em monitores de baixa resolução. A fonte escolhida foi Tahoma, com o tamanho 22. A Figura 12 ilustra a janela do Servidor Quiz. 4.4.1.2.3 Tempo

A classe Tempo corresponde ao envio da questão do professor para o aluno. Nela, é registrada a data e hora do lançamento e o tempo de duração de uma

determinada questão. Também é responsável por disponibilizar a questão ao aluno na duração do tempo estipulado pelo professor. Figura 12 – Janela do Servidor Quiz

Fonte: Autoria Própria, 2013

4.4.1.2.4 Servidor

É a principal classe do sistema, porque é responsável por iniciar e encerrar o servidor, abrir a janela, conectar com os clientes, consultar as requisições no banco de dados, enviar a questão do professor e disponibilizá-la durante o tempo estipulado e registrar as respostas dos alunos. Para isso, ela interage com todas as outras classes diretamente ou indiretamente. No método run ocorre as operações do servidor, ele recebe a conexão do cliente com um Array de Strings contendo o código de identificação e os dados necessários para a operação enviada, e direciona a um método do mesmo nome do código para ser feita a operação no banco de dados e enviar o resultado para o cliente por um Array de Strings, ou uma matriz de Array se necessário. No quadro 8

lista os métodos da classe. Os métodos citados abaixo do run representam os métodos, e respectivamente os códigos, enviados pelo cliente. Quadro 8 – Métodos utilizados na classe Servidor Método Descrição Recebe as informações do cliente, verifica se o login e professorLogin senha do professor são compatíveis e envia ao cliente a resposta de acordo com o resultado. Recebe as informações do cliente, verifica se o RA e alunoLogin senha do aluno são compatíveis e envia ao cliente a resposta de acordo com o resultado. Recebe o login do professor e envia as turmas lecionadas reqTurma por ele ou uma lista vazia se for o caso. Recebe o identificador de turma e envia as aulas reqAula pertencentes a ela, ou uma lista vazia se for o caso. Recebe o identificador de aula e envia as questões reqQuestao pertencentes a ela, ou uma lista vazia se for o caso. Recebe o identificador de questão e envia o relatório das reqRelatorio respostas, ou uma lista vazia se for o caso. Recebendo o login, o identificador da questão e o tempo de duração no servidor, consulta se a questão já foi questaoEnvia enviada ou se já existe outra questão ativa, caso contrário, invoca a classe Tempo para conceder a questão aos alunos. questaoAluno

Recebe o RA do aluno e verifica se existe questão ativa no servidor e se o aluno está cadastrado na turma referente à questão, se for confirmado, envia a questão.

alunoResponde

Recebe o identificador da questão, o RA do aluno e a resposta, verifica se o aluno já respondeu a questão, ou se o tempo já foi esgotado, caso contrário, registra a resposta do aluno no banco de dados.

addAula

Recebe o identificador da turma, a data e o assunto, adiciona no banco de dados e envia uma confirmação.

Recebe o identificador da aula, a data e o assunto, edita no banco de dados e envia uma confirmação. Recebe o identificador da aula, exclui no banco de dados excluiAula e envia uma confirmação. Recebe o identificador da aula, o enunciado, três addQuestao alternativas e a resposta, adiciona no banco de dados e envia uma confirmação. Recebe o identificador da questão, o enunciado, três editaQuestao alternativas e a resposta, edita no banco de dados e envia uma confirmação. Recebe o identificador da questão, exclui no banco de excluiQuestao dados e envia uma confirmação. Fonte: Autoria Própria, 2013 editaAula

Quadro 8 – Métodos utilizados na classe Servidor (continuação)

Método open close start main run

Descrição Inicia o ServerSocket com o número da porta indicada e a janela. Finaliza o programa encerrando todos as variáveis necessárias. Inicializa a Thread, permitindo o servidor receber solicitações através do método run. Inicia o servidor com a porta 2525 e inicia a thread do servidor com o método start Responsável por conectar com o cliente, receber a solicitação e indicar o método para que a resposta seja enviada ao cliente.

Fonte: Autoria Própria, 2013

4.4.2 Servidor Web

O Servidor Web, que foi implementado no Adobe Dreamweaver CS6, consiste em páginas em PHP e HTML responsáveis pelo gerenciamento dos dados do ServidorQuiz. Apesar de adicionar, editar e remover as aulas e questões que o servidor Java também faz, cabe a ele incluir, editar e remover os cursos, disciplinas e turmas, além de cadastrar os professores e alunos. A Figura 13 ilustra a página da lista de professores cadastrados da instituição, além das opções de poder editar ou excluir os registros ou de cadastrar um novo professor. Figura 13 – Lista de professores do Servidor Web

Fonte: Autoria Própria, 2013

A lista de cursos é mais simples, porém contém as mesmas opções da lista dos professores, como vista na Figura 14. Figura 14 – Lista de cursos do Servidor Web

Fonte: Autoria Própria, 2013

Na lista de disciplinas, além das mesmas, possui os cursos em que elas estão cadastradas, no caso de uma disciplina conter alunos de diversos cursos, por isso ela contém as opções de adicionar, editar, excluir e de adicionar ou remover um curso a uma disciplina escolhida. A Figura 15 mostra a lista de disciplinas conforme explicado.

Figura 15 – Lista de disciplinas do Servidor Web

Fonte: Autoria Própria, 2013

A partir das informações anteriores cadastradas, é possível realizar o cadastro de uma turma, que assim como as outras listas mencionadas antes, é de responsabilidade da instituição a realização dos cadastros e gerenciamento destes dados. A Figura 16 ilustra a lista de turmas cadastradas, além das opções de editar, excluir e adicionar, e ao clicar em algum dos links disponíveis na coluna Nome da tabela, é direcionado à página da turma correspondente. Figura 16 – Lista de turmas do Servidor Web

Fonte: Autoria Própria, 2013

Ao selecionar uma turma, o usuário vai para a página onde se encontra informações da mesma, divididas em duas partes: os alunos que estão cadastrados, com as opções de cadastrar novos alunos ou excluir, e as aulas dessa turma, cadastradas pelo professor, composta pela data e o assunto da aula, e as funcionalidades de cadastro, edição e exclusão contidas em quase todas as telas. Ao clicar no link da data da aula, será direcionado para a lista de questões da aula escolhida, caso o usuário queira ver o relatório de uma aula, é preciso clicar no link “Relatório da aula”, ao lado da data da aula escolhida. Todas essas informações são mostradas na Figura 17. Figura 17 – Lista de alunos e aulas de uma turma do Servidor Web

Fonte: Autoria Própria, 2013

De uma aula, é possível visualizar a lista de cada questão cadastrada pelo professor, composta pelo enunciado, três alternativas, a alternativa correta representada por 0, 1 e 2, simbolizando cada alternativa, e por último, um campo binário, que informa se a questão foi enviada aos alunos ou não. O professor pode adicionar novas questões, editá-las, excluí-las e, ao clicar no link do enunciado da questão desejada, ver o relatório da questão. A Figura 18 é um exemplo de uma lista de questões.

Figura 18 – Lista de questões de uma aula do Servidor Web

Fonte: Autoria Própria, 2013

No relatório da questão, o professor pode ver a estatística de uma questão enviada aos alunos na sala de aula. O relatório contém a data e hora que a questão foi lançada, o tempo de duração que a questão ficou disponível para os alunos responderem, o total de alunos da turma, a quantidade de questões acertadas, erradas e anuladas. Vale ressaltar que uma questão é anulada quando o aluno não comparece à aula, ou não responde a questão no tempo proposto. Um gráfico ilustra essa estatística das questões, como pode ser visto na Figura 19. O relatório da aula engloba o resultado de todas as questões enviadas durante a mesma. Ele contém o assunto e a data, o total de alunos da turma, o total de questões enviadas e a quantidade de questões acertadas, erradas e anuladas correspondente a todas as questões da aula. Esse relatório possui dois gráficos, um determina a estatística da quantidade total de questões e o outro mostra o desempenho de cada questão enviada, separadamente. A Figura 20 ilustra o relatório de uma aula.

Figura 19 – Relatório de uma questão do Servidor Web

Fonte: Autoria Própria, 2013 Figura 20 – Relatório de uma aula do Servidor Web

Fonte: Autoria Própria, 2013

4.5 TESTES

Para a fase de testes, formam consideradas três fases: teste de unidade, teste de sistema e o teste de aceitação. No teste de unidade, foram testadas as classes do sistema, separadamente, e na classe Servidor, todas as solicitações feitas pelo cliente. A ferramenta utilizada para esse tipo de teste foi a JUnit, um plugin do Eclipse que permite fazer uma análise do código fonte, conhecida como caixa branca. Ao testar cada requisição, mesmo as requisições que necessitam um acesso maior ao banco de dados, foi comprovado que o tempo de resposta sempre foi menor do que 1 segundo, superando a expectativa proposta nos requisitos do sistema. A Figura 21 demonstra um dos testes unitários feito pelo JUnit e o tempo de resposta na requisição de login do aluno. Figura 21 – Teste unitário do login do aluno

Fonte: Autoria Própria, 2013

Para fazer o teste de desempenho, também foi utilizado o JUnit, dessa vez realizando 60 conexões simultâneas do login do aluno, simulando um ambiente em sala de aula, a fim de verificar a estabilidade do servidor mesmo com várias requisições ao mesmo tempo. A Figura 22 demonstra que além do servidor se portar-se bem durante o teste, o tempo de resposta total foi satisfatório, menos de 1 segundo.

Figura 22 – Teste de desempenho do servidor

Fonte: Autoria Própria, 2013

Para o teste de sistema, foi observado o comportamento do servidor de acordo com as requisições, feitas pelos aplicativos cliente do professor de do aluno desenvolvidos para smartphones com o sistema operacional Android, utilizando o teste caixa preta para testar todas as funcionalidades do sistema. A Figura 23 mostra o progresso na janela do servidor de uma questão enviada pelo professor, estipulando 90 segundos para receber a resposta, e a confirmação da resposta do aluno antes de esgotar o tempo. Figura 23 – Janela do servidor em teste de sistema

Fonte: Autoria Própria, 2013

O teste de aceitação foi feito com cinco professores, que assistiram uma apresentação feita com o servidor e os aplicativos cliente do aluno e do professor em um smartphone e um tablet, respectivamente. Após a apresentação, os participantes tiveram um breve treinamento de como manusear os aplicativos, principalmente o do professor, que realiza mais tarefas. O servidor funcionou perfeitamente durante a apresentação e treinamento. Ao fim do treinamento, foi aplicado um questionário objetivo, onde é avaliada a usabilidade do sistema, assim como o seu desempenho, de acordo com os participantes. O questionário, que se encontra no Apêndice A, contém 8 questões, sendo 6 com as alternativas ruim, regular, bom e ótimo, e as 2 últimas de sim ou não, a respeito da aplicabilidade do sistema em sala de aula. De acordo com o resultado do questionário, no Quadro 9, os participantes gostaram da interface do aplicativo, acharam o tempo de resposta rápido, porém acharam que as mensagens de erro e a navegabilidade podem ser melhoradas para aumentar a facilidade de manuseamento do sistema. Por fim, foi unanimidade as respostas de que o sistema é apto a ser utilizado em sala de aula, contendo os requisitos necessários para a professor avaliar o processo de ensino. Quadro 9 – Resultado do questionário de usabilidade do sistema Questões As telas do sistema contêm todas as informações importantes para a sua utilização? Os botões, símbolos, menus e demais itens são similares entre as telas? O sistema sempre informa de forma clara, quando uma determinada ação está sendo ou foi concluída? O sistema produz mensagens de erro claras e propõe dicas para sua resolução? O sistema possui fácil navegação para usuários iniciantes se tornem peritos facilmente? O tempo de resposta do sistema de acordo com as operações realizadas é satisfatório? Questões O sistema possui os requisitos necessários para o professor utilizá-lo em sala de aula? Você concorda com a utilização deste sistema a fim de avaliar o processo de ensino? Fonte: Autoria Própria, 2013

Ruim

Regular

Bom

Ótimo

40%

60%

20%

80%

20%

80%

40%

20%

40%

60%

20%

80%

Sim

Não

100%

5 CONCLUSÃO

Este trabalho teve como objetivo o desenvolvimento de uma ferramenta Web, que é utilizada como um auxílio na avaliação do ensino do professor na sala de aula, por meio de questões que determinam o nível de entendimento da turma a respeito de um determinado conteúdo. Utilizando os conceitos de Instrução pelos Colegas e ambientes virtuais de aprendizagem, foi possível elaborar um sistema que monitore e avalie o processo de ensino do professor por meio de envio de questões aos alunos sobre o assunto lecionado, utilizando um dispositivo conectado a uma rede sem fio, e obter um relatório contendo o resultado de acertos assim que encerrar o tempo da questão, através de um aplicativo voltado para esse fim. Para o desenvolvimento da ferramenta foram aplicadas as fases do ciclo de vida de desenvolvimento de sistemas: a modelagem de negócio, a análise de requisitos, os projetos do sistema, a codificação e os testes de desenvolvimento, afim de que o resultado seja um sistema feito nos moldes do que foi proposto. O sistema conecta-se com os clientes em uma forma segura de transmissão de dados, os dados são manipulados apenas por usuários permitidos, o servidor permite esse acesso após a autenticação de cada usuário. A aplicabilidade da ferramenta depende apenas no aprimoramento do gerenciador dos dados do servidor Web, adequando as variáveis nos moldes da instituição educacional que for utilizá-lo. Foi constatada, nos testes realizados, a eficiência do servidor nos quesitos de velocidade de resposta, na precisão das operações no banco de dados e no desempenho de conexões simultâneas, fatores importantes identificados nos requisitos do sistema. A comunicação do servidor com os clientes também foram bem sucedidas, seguindo o protocolo de troca de mensagens e exibindo o progresso na tela de acordo a solicitação feita pelo cliente. O servidor Web, além de realizar o gerenciamento do banco de dados, exibiu os relatórios de questões e aulas, para o professor poder avaliar o ensino de forma clara, utilizando dados concretos e representando-os através de gráficos.

5.1 TRABALHOS FUTUROS

É recomendado para trabalhos futuros o desenvolvimento do servidor utilizando o protocolo HTTP através dos métodos GET e POST, assim facilita a integração da ferramenta para um ambiente virtual mais completo, envolvendo todos os componentes da instituição em um portal, que pode ser disponibilizado no site da instituição. Outra sugestão é incluir na parte do aluno uma opção, além da resposta, na qual o aluno identifique o coeficiente de certeza na sua resposta, sendo as prioridades baixa, média e alta. O coeficiente, junto com a resposta, pode ser envolvido em uma fórmula, cujo resultado indique o desempenho geral da turma sobre o assunto abordado com precisão, já que cada aluno indicará a resposta e o nível de certeza sobre ela. Por último, pode-se implementar uma ferramenta que possa incluir imagens como parte do enunciado, assim o professor pode elaborar questões que envolvam leituras de gráficos, cálculos geométricos, etc.

REFERÊNCIAS

ARAUJO, Ives Solano; MAZUR, Eric. Instrução pelos colegas e ensino sob medida: uma proposta para o engajamento dos alunos no processo de ensino-aprendizagem de Física. Caderno Brasileiro de Ensino de Física, v. 30, n. 2, p. 362-384, 2013. BARROS, Aidil Jesus da Silveira; LEHFELD, Neide Aparecida de Souza. Fundamentos de metodologia científica. 3. ed. São Paulo: Makron Books, 2007. BRAGA, Osmar R. A relação professor-aluno e o processo de ensinoaprendizagem: um desafio para a ação docente. Disponível em: <http://www.emdialogo.uff.br/content/relacao-professor-aluno-e-o-processo-deensino-aprendizagem-um-desafio-para-acao-docente>. Acesso em: 26 nov. 2013. COMER, Douglas E. Computer networks and internets, 5th edition. Prentice Hall Press, 2008. CYSNEIROS, Paulo G. Novas tecnologias na sala de aula: melhoria do ensino ou inovação conservadora. Anais... Encontro Nacional de Didática e Prática de Ensino, p. 199-216, 1998. DEITEL, H. M.; DEITEL, P. J. Java: how to program, 9th Edition. Prentice Hall, 2012. DIAS JUNIOR, Luiz Dourado; FERREIRA, Benedito de Jesus Pinheiro. Avaliação docente em ambientes virtuais de aprendizagem (AVA): propostas de atividades com o uso do Moodle e Teleduc. Anais… Workshop de Informática na Escola. 2008. DILLENBOURG, Pierre; SCHNEIDER, Daniel; SYNTETA, Paraskevi. Virtual learning environments. Proceedings of the 3rd Hellenic Conference'Information & Communication Technologies in Education, p. 3-18. Grécia, 2002. DOS SANTOS, Edméa Oliveira. Ambientes virtuais de aprendizagem: por autorias livres, plurais e gratuitas. Educação e Contemporaneidade, v. 11, n. 18, p. 424, 2002. ELMASRI, R.; NAVATHE, S. Fundamentals of database systems, 6th edition. Pearson Addison-Wesley, 2010. FILIPETTO, Luana Bortoluzzi; ROSA, Tatiana Costa. Uma nova relação aluno/professor: a inserção das TICs em sala de aula. Anais... do XVI Simpósio de Ensino, Pesquisa e Extensão. Santa Maria: Unifra, 2012. FOROUZAN, Behrouz A. Data communication and networking, 4th edition. McGraw-Hill, New York, 2007. GIL, Antônio Carlos. Como elaborar projetos de pesquisa. 4. ed. - São Paulo: Atlas, 2002

HEUSER, Carlos Alberto. Projeto de banco de dados. 5. ed. Série Livros Didáticos – Instituto de Informática da UFRGS, n. 4. Sagra-Luzzatto, 2004. HORSTMANN, Cay S. Java Concepts: Compatible with Java 5, 6 and 7. John Wiley & Sons, 2009. KUROSE, James F.; ROSS, Keith W. Computer networking: a top-down approach, 6th edition. Pearson Education, 2012. LASRY, Nathaniel. Clickers or flashcards: is there really a difference?. The Physics Teacher, v. 46, p. 242, 2008. LIN, Ying-Dar; HWANG, Ren-Hung; BAKER, Fred. Computer Networks: an open source approach. McGraw-Hill, 2012. LIU, Tzu-Chien. Teaching in a wireless learning environment: A case study. Educational Technology & Society, v. 10, n. 1, p. 107-123, 2007. MAZUR, Eric. Peer instruction: A user's manual. Physics Today, v. 50, n. 4, p. 6869, 1997. MEIRELLES, Luiz Fernando T.; TAROUCO, Liane M. R. Framework para aprendizagem com mobilidade. Anais... Simpósio Brasileiro de Informática na Educação, p. 623-633, 2005. MORAN, José Manuel. Ensino e aprendizagem inovadores com tecnologias. Informática na Educação: Teoria & Prática. Porto Alegre, vol. 3, n.1, 2000. MORAN, José Manuel. Novas tecnologias e o re-encantamento do mundo. Revista tecnologia educacional. Rio de Janeiro, v. 23, n. 126, p. 24-26, 1995. MORESI, Eduardo. Metodologia da Pesquisa. Manual. Universidade Católica de Brasília. Brasília: UCB, 2003. NIEMEYER , Patrick; LEUCK , Daniel. Learning Java, 4th Edition. O’reilly Media, 2013. OLIVEIRA, Vagner. Uma proposta de ensino de tópicos de eletromagnetismo via instrução pelos colegas e ensino sob medida para o ensino médio. Dissertação (Mestrado Profissional em Ensino de Física) - Porto Alegre: UFRGS, Instituto de Física, Programa de Pós-Graduação em Ensino de Física, 2012. PICCOLI, Gabriele; AHMAD, Rami; IVES, Blake. Web-based virtual learning environments: A research framework and a preliminary assessment of effectiveness in basic IT skills training. MIS quarterly, p. 401-426, 2001. PRESSMAN, Roger S. Engenharia de software: uma abordagem profissional, 7. edição. McGraw Hill Brasil, 2011.

ROB, Peter; CORONEL, Carlos. Database Systems: design, implementation, and management, 8th edition. Thomson Course Technology, 2009. SANTOS, Sandra Carvalho. O processo de ensino-aprendizagem e a relação professor-aluno: Aplicação dos “sete princípios para a boa prática na educação de ensino superior”. Caderno de Pesquisas em Administração , São Paulo, v. 08, nº 1, 2001. SEBESTA, Robert W. Concepts of programming languages, 10th edition. Pearson Addison-Wesley, 2009. SILBERSCHATZ, Albert; KORTH, Henry F.; SUDARSHAN, S. Database System Concepts, 6th edition. McGraw-Hill, 2010. SOMMERVILLE, Ian. Software Engineering, 9th edition. Pearson Addison-Wesley, 2011. TANENBAUM, Andrew S. Computer Networks, 4th edition. Prentice Hall, 2011. VALENTINI, C. B.; SOARES, E. M. S. Aprendizagem em ambientes virtuais: compartilhando ideias e construindo cenários. Caxias do Sul: EDUCS, 2005.

APÊNDICE A - Questionário de avaliação do nível de usabilidade do sistema

Nome:_________________________________

1) As telas do sistema contêm todas as informações importantes para a sua utilização? Ruim ( )

Regular ( )

Bom ( )

Ótimo ( )

2) Os botões, símbolos, menus e demais itens são similares entre as telas? Ruim ( )

Regular ( )

Bom ( )

Ótimo ( )

3) O sistema sempre informa de forma clara, quando uma determinada ação está sendo ou foi concluída? Ruim ( )

Regular ( )

Bom ( )

Ótimo ( )

4) O sistema produz mensagens de erro claras e propõe dicas para sua resolução? Ruim ( )

Regular ( )

Bom ( )

Ótimo ( )

5) O sistema possui fácil navegação para usuários iniciantes se tornem peritos facilmente? Ruim ( )

Regular ( )

Bom ( )

Ótimo ( )

6) O tempo de resposta do sistema de acordo com as operações realizadas é satisfatório? Ruim ( )

Regular ( )

Bom ( )

Ótimo ( )

7) O sistema possui os requisitos necessários para o professor utilizá-lo em sala de aula? Sim ( )

Não ( )

8) Você concorda com a utilização deste sistema a fim de avaliar o processo de ensino? Sim ( )

Não ( )