Embed Size (px)
Citation preview
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIA DA COMPUTAÇÃO – BACHARELADO
FERRAMENTA DE APOIO AO PROFESSOR PARA O
CONTROLE DE DISCIPLINAS UTILIZANDO DISPOSITIVO
MÓVEL
WAGNER LINO
BLUMENAU 2012
2012/1-28
WAGNER LINO
FERRAMENTA DE APOIO AO PROFESSOR PARA O
CONTROLE DE DISCIPLINAS UTILIZANDO DISPOSITIVO
MÓVEL
Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Ciência da Computação — Bacharelado.
Prof. Dalton Solano dos Reis, M.Sc - Orientador
BLUMENAU 2012
2012/1-28
FERRAMENTA DE APOIO AO PROFESSOR PARA O
CONTROLE DE DISCIPLINAS UTILIZANDO DISPOSITIVO
MÓVEL
Por
WAGNER LINO
Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por:
______________________________________________________ Presidente: Prof. Dalton Solano dos Reis, M.Sc – Orientador, FURB
______________________________________________________ Membro: Prof. Francisco Adell Péricas, M.Sc - FURB
______________________________________________________ Membro: Prof. Miguel Alexandre Wisintainer, M.Sc - FURB
Blumenau, 10 de Julho de 2012
Dedico este trabalho a todos os amigos e familiares que estiveram comigo na realização deste, incentivando e apoiando.
AGRADECIMENTOS
A Deus, pelo seu imenso amor e graça.
À minha família, pelo apoio nas horas difíceis.
Aos meus amigos, pelos empurrões e cobranças.
Ao meu orientador, Dalton Solano dos Reis, por ter acreditado na conclusão deste
trabalho.
Ao Léo Jonathan Faht, pelo tempo deicado para ajudar na realização deste trabalho.
RESUMO
Este trabalho apresenta o desenvolvimento de uma ferramenta para apoiar o professor no controle de disciplinas diretamente pelo iPhone, a fim de permitir mobilidade no registro de frequência. Esta ferramenta trabalha como uma aplicação que se conecta em uma base de dados através de um webservice disponibilizado pelo Ambiente Virtual de Aprendizagem da FURB, solicitando informações como as disciplinas que o professor ministra, os alunos das disciplinas e os dias que possui aula para serem exibidos na tela do dispositivo. Esta aplicação ainda permite efetuar a marcação de frequência de maneira offline (sem a necessidade de estar conectado a internet) atualizando as informações assim que o acesso a internet estiver ativo. Possui também a capacidade de enviar as informações para o webservice com segurança utilizando criptografia e armazenar no aparelho os dados retornados do webservice.
Palavras-chave: iPhone. iOS. Dispositivo móvel. Sistema de aprendizagem móvel.
ABSTRACT
This paper presentes the tool’s development to support the teacher in control of disciplines directly by the iPhone, to enable mobility in record attendance. This tool works like an application that connects to a database via a webservice available for the Virtual Learning System of FURB, requesting information of the disciplines that the teacher minister, students of the disciplines and the class days to appear on device screen. This application also allows to perform the marking frequency in offline mode (without the need to be connected to the internet) updating the information when the access to the is internet is active. It also has the ability to send the information to the webservice securely using encryption and store on device the data returned from the webservice.
Key-words: iPhone. iOS. Mobile device. Mobile learning system.
LISTA DE ILUSTRAÇÕES
Figura 1 – Interface do CFN para registro de frequência .........................................................15
Figura 2 – Foto de um iPhone ..................................................................................................17
Figura 3 – Tela inicial do Xcode ..............................................................................................19
Figura 4 – Ambiente de desenvolvimento do Xcode ...............................................................19
Figura 5 – Ambiente do Xcode para criação de interfaces.......................................................20
Figura 6 – Interface do Moodle para o iPhone .........................................................................21
Figura 7 – Interface do Synceasy .............................................................................................22
Figura 8 – Ações disponíveis ao professor...............................................................................25
Quadro 1 – Caso de uso UC01 .................................................................................................26
Quadro 2 – Caso de uso UC02 .................................................................................................26
Quadro 3 – Caso de uso UC03 .................................................................................................27
Quadro 4 – Caso de uso UC04 .................................................................................................27
Figura 9 – Diagrama de pacotes da aplicação CFN..................................................................28
Figura 10 - Storyboard..............................................................................................................28
Figura 11 – Pacote Controllers .................................................................................................30
Figura 12 – Pacote Auxiliares ..................................................................................................31
Figura 13 – Pacote Banco .......................................................................................................32
Figura 14 – Diagrama de sequência referente ao caso de uso UC01 .......................................33
Figura 15 – Diagrama de sequência referente ao caso de uso UC02 .......................................34
Figura 16 – Diagrama de sequência referente ao caso de uso UC03 .......................................34
Figura 17 – Diagrama de sequência referente ao caso de uso UC04 .......................................34
Figura 18 – Modelo de entidades e relacionamentos da aplicação...........................................35
Figura 19 – Formato de um objeto JSON.................................................................................36
Quadro 5 – Exemplo de chamada de um método do webservice .............................................37
Quadro 6 – Definição do método montaMensagemComMetodo.............................................37
Quadro 7 – Definição do método executaMetodo....................................................................38
Quadro 8 – Definição do método iniciaComDadoseRetornaSemConversao...........................39
Quadro 9 – Exemplo da verificação da conexão com a internet ..............................................40
Quadro 10 – Exemplo da rotina que processa a pool de frequências .......................................41
Figura 20 – Efetuar login..........................................................................................................42
Figura 21 – Selecionar disciplina .............................................................................................43
Figura 22 – Selecionar aula ......................................................................................................44
Figura 23 – Registrar frequência ..............................................................................................45
Figura 24 – Aplicação em modo offline ...................................................................................46
Quadro 11 – Marcações utilizadas para medir o tempo ...........................................................47
Quadro 12 – Tempo médio para comunicação com o webservice ...........................................47
Figura 25 – Gráfico do tempo médio em milisegundos para comunicação com o webservice 48
Quadro 13 – Tempo médio para exibir resultado na interface .................................................48
Figura 26 – Gráfico do tempo médio para exibir resultado na interface..................................49
Figura 27 – Heapshots no Instruments .....................................................................................50
Quadro 14 – Quantidade bytes por classe ................................................................................50
Quadro 15 – Quantidade de bytes do objetos do banco de dados ............................................51
Quadro 16 – Fórmula matemática para o cálculo de memória necessária ...............................51
LISTA DE SIGLAS
3G – 3 Geração (Rede de telefonia móvel de terceira geração)
API – Application Programming Interface
CFN – Controle de Frequência e Notas
DME – Divisão de Modalidades de Ensino
DRA – Divisão de Registros Acadêmicos
GPS – Global Positioning System
JSON – JavaScript Object Notation
LMS – Learning Management System
SDK – Software Development Kit
SQL – Structured Query Language
TIC – Tecnologias de Informação e Comunicação
TIMS – Tecnologias da Informação Móveis e Sem fio
UML – Unified Modeling Language
XML – eXtensible Markup Language
SUMÁRIO
1 INTRODUÇÃO .................................................................................................................12
1.1 OBJETIVOS DO TRABALHO ........................................................................................12
1.2 ESTRUTURA DO TRABALHO......................................................................................13
2 FUNDAMENTAÇÃO TEÓRICA....................................................................................14
2.1 MOBILE LEARNING ........................................................................................................14
2.2 CONTROLE DE FREQUÊNCIA E NOTAS ...................................................................14
2.2.1 Sincronização de dados ...................................................................................................15
2.2.2 Criptografia .....................................................................................................................16
2.3 IOS.....................................................................................................................................16
2.3.1 iPhone..............................................................................................................................17
2.3.2 Objective-C .....................................................................................................................17
2.3.3 Xcode ..............................................................................................................................18
2.3.4 Persistência de dados.......................................................................................................20
2.4 TRABALHOS CORRELATOS........................................................................................20
2.4.1 Mobile Moodle................................................................................................................21
2.4.2 Synceasy: Aplicativo para Sincronização de Arquivos entre Dispositivos Móveis e
Computadores Utilizando Metadados .............................................................................22
2.4.3 Sistema de Proteção para Servidores de Jogos Online contra Softwares Clientes Não
Oficiais ............................................................................................................................22
3 DESENVOLVIMENTO....................................................................................................24
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO.......................24
3.2 ESPECIFICAÇÃO ............................................................................................................25
3.2.1 Casos de uso....................................................................................................................25
3.2.1.1 Efetuar login .................................................................................................................25
3.2.1.2 Selecionar disciplina .....................................................................................................26
3.2.1.3 Selecionar aula..............................................................................................................26
3.2.1.4 Efetuar frequência.........................................................................................................27
3.2.2 Diagrama de classes ........................................................................................................27
3.2.2.1 Pacote Controllers ................................................................................................28
3.2.2.2 Pacote Auxiliares...................................................................................................30
3.2.2.3 Pacote Banco...............................................................................................................31
3.2.3 Diagrama de sequência ...................................................................................................33
3.2.4 Banco de dados / Persistência .........................................................................................34
3.3 IMPLEMENTAÇÃO ........................................................................................................35
3.3.1 Técnicas e ferramentas utilizadas....................................................................................35
3.3.1.1 Webservice ...................................................................................................................36
3.3.1.2 CFN...............................................................................................................................39
3.3.2 Operacionalidade da implementação ..............................................................................41
3.3.2.1 Efetuar login .................................................................................................................42
3.3.2.2 Selecionar disciplina .....................................................................................................42
3.3.2.3 Selecionar dia da aula ...................................................................................................43
3.3.2.4 Registrar frequência......................................................................................................44
3.4 RESULTADOS E DISCUSSÃO ......................................................................................46
3.4.1 Performance ....................................................................................................................47
3.4.2 Uso da memória ..............................................................................................................49
4 CONCLUSÕES..................................................................................................................52
4.1 EXTENSÕES ....................................................................................................................53
REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................54
12
1 INTRODUÇÃO
Com o crescimento significativo de posse e uso dos celulares, pode-se afirmar que este
aparelho é atualmente um dos principais meios de inclusão da população brasileira ao uso das
Tecnologias de Informação e Comunicação (TIC). O seu uso já atinge 84% dos brasileiros
residentes em área urbana e 16% na área rural (CETIC-BR, 2012).
A utilização do celular para acesso a internet é reduzido em comparação às demais
atividades realizadas no aparelho, porém, o uso de internet somente em celulares pré-pagos
cresceu de 5 milhões em 2010 para 18 milhões em 2011. Planos de internet para pré-pagos
são responsáveis por 81% do crescimento (CETIC-BR, 2012).
Devido a esta abrangência e a característica de poder ouvir música, assistir vídeos e ter
a mobilidade de fazer estas tarefas em qualquer lugar, o número de funcionários e estudantes
de instituições de ensino que possuem e usam os celulares vem crescendo. Atualmente a
maioria deste uso é pessoal e informal, mas progressivamente universidades e colégios estão
respondendo tecnicamente, pedagogicamente e socialmente ao grande número de pessoas
utilizando celulares, incorporando os aparelhos aos processos e administração de pesquisas e
educação (ANDERSON; BLACKWOOD, 2004, p. 3).
O uso de dispositivos móveis por instituições de ensino para fornecer informações e
auxiliar professores possibilita que processos como o Controle de Frequência e Notas (CFN)
não necessitem mais ser em papel. Desta forma, o processo das informações torna-se mais
prático e ágil.
A Universidade Regional de Blumenau (FURB) possui um sistema de CFN em
ambiente Web e a presente proposta propõe estender o uso do CFN para o iPhone
(UNIVERSIDADE REGIONAL DE BLUMENAU, 2012).
1.1 OBJETIVOS DO TRABALHO
O objetivo deste trabalho é disponibilizar um aplicativo para o professor efetuar o
controle de frequência dos alunos através do iPhone.
Os objetivos específicos do trabalho são:
a) efetuar o armazenamento das informações no iPhone;
13
b) garantir a integridade e autenticidade das informações que são enviadas e
recebidas pelo dispositivo;
c) atualizar as informações na base de dados do CFN que forem salvas no aparelho
quando a aplicação estiver em modo offline;
d) enviar e receber as informações através de um webservice1.
1.2 ESTRUTURA DO TRABALHO
Este trabalho é formado por quatro capítulos. O capítulo 2 contém a fundamentação
téorica necessária para o entendimento do trabalho, as ferramentas utilizadas para o
desenvolvimento e apresenta trabalhos correlatos. No capítulo 3 é abordado o
desenvolvimento do aplicativo, onde são explanados os principais requisitos do trabalho, a
especificação contendo diagramas de casos de uso, classe e sequência. Por fim, no capítulo 4
foca-se em apresentar conclusões e futuras implementações.
1 webservice é uma solução utilizada na integração de sistemas e comunicação entre aplicações diferentes.
14
2 FUNDAMENTAÇÃO TEÓRICA
Na seção 2.1 é realizada uma explanação sobre mobile learning. Na seção 2.2 aborda-
se o conceito do CFN. Na seção 2.3 é explicado o dispositivo móvel iPhone, assim como
principais conceitos de persistência de dados e aspectos importantes para sincronização das
informações. Na seção 2.4 apresenta a linguagem de programação Objective-C e na seção 2.5
são apresentadas as ferramentas utilizadas neste trabalho. Por fim, na seção 2.6 são
apresentados trabalhos correlatos ao trabalho proposto.
2.1 MOBILE LEARNING
A definição de mobile learning ou m-learning é a utilização de Tecnologias da
Informação Móveis e Sem fio (TIMS) como celular, palmtop, computador de mão para
aprendizagem com a característica da mobilidade dos atores humanos, que podem estar
fisicamente distantes dos outros atores, ou também em espaços físicos formais de educação,
como salas de aula, salas de treinamento ou local de trabalho (REINHARDT; al., 2007, p. 1).
Com o mobile learning professores podem disponibilizar material como vídeo e
arquivo de áudio e distribuir para os alunos. O material faz parte do trabalho de casa, onde
pode ser necessário assistir a um vídeo antes de responder a uma lista de perguntas. Estudos
indicam que a combinação de áudio e vídeo vem se apresentando mais atrativo que a
tradicional leitura, gerando assim um ganho no aprendizado de alunos através do uso destas
mídias (REPLY, 2008).
2.2 CONTROLE DE FREQUÊNCIA E NOTAS
O CFN é uma ferramenta web, em desenvolvimento pela Divisão de Modalidades de
Ensino (DME) da Universidade Regional de Blumenau (FURB) que tem como objetivo
principal facilitar o controle de frequência e notas das disciplinas de graduação.
15
As principais funcionalidades do CFN são (UNIVERSIDADE REGIONAL DE
BLUMENAU, 2009):
a) registrar a frequência dos alunos;
b) cadastrar avaliações, com os respectivos pesos;
c) registrar as notas dos alunos;
d) emitir relatórios para entrega (na forma de anexo) a Divisão de Registros
Acadêmicos (DRA).
A Figura 1 apresenta um exemplo da interface web do CFN, onde pode ser vista a tela
de registro de frequência de alunos.
Fonte: Universidade Regional de Blumenau (2012).
Figura 1 – Interface do CFN para registro de frequência
2.2.1 Sincronização de dados
Sincronização refere-se ao processo em que os dados de uma determinada origem são
propagados ao destino, podendo este ser um ou mais. Esta técnica pode ocorrer de 3 maneiras
(MICROSOFT, 2012):
a) contínua: onde qualquer inclusão, exclusão e alteração ocorrida na origem é
imediatamente repassada para o destino;
16
b) agendada: os dados são replicados para o destino, fazendo com que sempre esteja
coerente com a origem;
c) sob demanda: os dados alterados no destino são enviados para a origem, ocorrendo
a união das informações e logo após a origem envia os dados para o destino.
Conflitos nas informações, caso existam, são detectados e resolvidos. No fim, a
origem e o destino eventualmente acabam tendo as informações iguais.
2.2.2 Criptografia
É um termo para denominar a junção da palavra grega kryptos (“escondida”) e graphia
(“escrever”). Trata-se de uma técnica que visa codificar uma mensagem de forma que
somente o emissor e o receptor conseguem decifrá-la (BRAGHETTO, 2003).
Um dos métodos utilizados para criptografar uma mensagem é o RSA, que foi criado
em 1977 por Ronald Rivest, Adi Shamir e Leonard Adleman, na época professores do
Instituto Técnológico de Massachusetts (MIT).
O RSA é um método que utiliza chaves simétricas, utilizando duas chaves distintas:
uma pública, utilizada para criptografar uma mensagem e pode ser divulgada livremente e
uma chave privada, que deve ser mantida em segredo pelo seu dono e é utilizada para decifrar
a mensagem (CERT, 2003).
2.3 IOS
É o sistema operacional desenvolvido especialmente para dispositivos móveis baseado
no Mac OS X, combinando excelente desempenho com grande estabilidade. Ele gerencia o
consumo de bateria do aparelho para viabilizar uma duração maior de bateria e até garante em
operações multitarefas com vários aplicativos que estes não interfiram no no desempenho e na
duração da bateria. Como a Apple desenvolve tanto o hardware como o sistema operacional,
tudo funciona de forma inteligente. É essa integração que permite que os aplicativos
aproveitem ao máximo todos os benefícios e recursos de hardware disponíveis no aparelho
(APPLE, 2012a).
17
2.3.1 iPhone
O iPhone é um telefone desenvolvido pela Apple que combina 3 dispositivos em um:
telefone celular, central multimídia e computador portátil. Com ele é possível efetuar e
receber chamadas, ouvir músicas, assistir filmes, fotografar, visualizar mapas e dados de
satélites através do Global Positioning System (GPS), enviar e receber mensagens de correio
eletrônico e navegar na internet através de conexões sem fio como 3G e Wireless Fidelity
(Wi-Fi). Além de jogos e aplicativos padrões a Apple disponibiliza ferramentas e bibliotecas
para desenvolvimento de outros jogos e aplicativos (APPLE, 2012b).
O grande diferencial do iPhone, comparado aos concorrentes foi a sua tela sensível ao
toque, exigindo apenas o uso dos dedos para interação com o dispositivo. Enquanto que a
maioria dos outros produtos com essa característica a interação ocorre através de uma caneta
de ponta fina (WILSON, 2012).
Na Figura 2 é possível ver um exemplo da aparência do iPhone.
Figura 2 – Foto de um iPhone
2.3.2 Objective-C
Criada nos anos 80 por Brad Cox e Tom Love, a linguagem Objective-C é o resultado
da união da linguagem C com a orientação a objetos proveniente da linguagem Smalltalk.
18
A sintaxe da linguagem é em grande parte, parecida com a linguagem C. Uma
diferença significante é a adição de mensagens. Mensagens são similares a chamada de
funções, só que ao invés de chamar um método, uma mensagem é passada.
Após deixar a Apple, Steve Jobs fundou uma nova empresa chamada NeXT para
desenvolver toda uma nova geração de computadores. O sistema operacional desenvolvido
pela NeXT para executar nestes computadores foi chamado de NeXTstep. Para criar o sistema
operacional, a empresa licenciou a linguagem Objective-C.
Durante os anos 90 a Apple havia perdido uma enorme fatia do mercado de
computadores e lutava para lançar um novo sistema operacional. Com a aquisição da NeXT
pela Apple, o sistema operacional NeXTstep serviu como base para o desenvolvimento do
atual sistema operacional da Apple, o Mac OS X. Com isto a linguagem Objective-C tornou-
se a linguagem padrão de desenvolvimento da Apple e posteriormente o núcleo do Mac OS X
foi modificado para criar o sistema operacional do iPhone (TECHOTOPIA, 2011).
2.3.3 Xcode
Xcode é uma plataforma produtiva e integrada para o desenvolvimento de aplicações
para o iPhone e Mac OS X que contempla um extenso conjunto de bibliotecas de
programação e interfaces.
Além das tradicionais tarefas de edição e compilação do código fonte o Xcode através
do iPhone SDK consegue gerenciar todos os dispositivos para teste, empacotar os devidos
certificados necessários para a instalação do aplicativo no próprio iPhone, além de executar
passo a passo o aplicativo que está instalado no próprio dispositivo (APPLE, 2012c).
A Figura 3 apresenta a tela inicial e as Figuras 4 e 5 demonstram o ambiente de
desenvolvimento do Xcode. Conforme a Apple (APPLE, 2012d), o Xcode está na versão
4.3.3.
19
Figura 3 – Tela inicial do Xcode
Figura 4 – Ambiente de desenvolvimento do Xcode
20
Figura 5 – Ambiente do Xcode para criação de interfaces
2.3.4 Persistência de dados
Persistência é a técnica que se refere ao armazenamento de dados, por exemplo, em um
arquivo ou banco de dados, de modo que os dados continuam a existir após o término do
programa que os criou e possam ser recuperados posteriormente (COSTA, 2003).
Uma alternativa para efetuar a persistência de dados no iPhone é o Core Data, que é
um framework de persistência disponibilizada pela Apple. Ela permite que os dados
organizados pelo modelo entidade-atributo sejam salvos em XML, binário ou SQLite. Os
dados podem ser manipulados usando objetos gráficos que representam as entidades e os seus
relacionamentos. O modelo de persistência padrão do Core Data é o SQLite, fazendo com que
o desenvolvedor não se preocupe em executar comandos SQL (APPLE, 2011).
2.4 TRABALHOS CORRELATOS
Abaixo são apresentados trabalhos correlatos que exploram a utilização de dispositivos
móveis para a área da educação.
21
2.4.1 Mobile Moodle
O Moodle, também conhecido como Learning Management System (LMS) se tornou
popular entre educadores ao redor do mundo, por ser uma ferramenta para criação de websites
dinâmicos para estudantes, contendo fóruns de discussão e bases de conhecimento. Muitas
universidades estão usando o Moodle como plataforma para disponibilizar cursos online
inteiros para seus alunos (MOODLE, 2008).
O Mobile Moodle é um sistema integrado ao sistema de aprendizagem Moodle e tem a
capacidade de criar cenários de aprendizagem para serem utilizados em dispositivos móveis.
Professores podem criar os cursos com as ferramentas e metodologias que já conhecem sobre
o Moodle e os estudantes podem iniciar o curso em um computador desktop e continuar o
curso acessando através de um dispositivo móvel em qualquer lugar (MOODLE, 2008). A
Figura 6 demonstra a interface do Moodle para o iPhone.
Fonte: Moodle (2008).
Figura 6 – Interface do Moodle para o iPhone
22
2.4.2 Synceasy: Aplicativo para Sincronização de Arquivos entre Dispositivos Móveis e Computadores Utilizando Metadados
Segundo Müller (2011), o Synceasy é um aplicativo para sincronizar arquivos entre um
celular e um computador. O aplicativo é baseado na arquitetura cliente/servidor e a
comunicação entre o cliente e o servidor é feita através de sockets. A sincronização é feita
através de um algoritmo onde é gerada uma lista de informações dos arquivos como nome,
última data de alteração, tamanho e o hash do arquivo. O mesmo processo é feito no servidor
e então as duas listas são comparadas. Se o valor do hash de ambas for diferente, a última
versão dos arquivos é definida pela data de alteração mais atual.
Na figura 7 é demonstrado a interface do aplicativo onde é possível efetuar a
sincronização.
Fonte: Müller (2011).
Figura 7 – Interface do Synceasy
2.4.3 Sistema de Proteção para Servidores de Jogos Online contra Softwares Clientes Não Oficiais
A proteção oferecida faz com que um software servidor só se comunique com
23
softwares cliente em que ele confia. Todo software cliente que deseja se conectar em um
software servidor passa por validações antes e depois de se conectar, para provar que é
confiável. Para prevenir adulteração do sistema é utilizado o algoritmo de criptografia AES de
caixa branca para garantir a autenticidade da conexão.
Criptografia de caixa branca é uma técnica de ofuscação de código que se destina a
implementar algoritmos de criptografia de tal forma que, mesmo se alguém não autorizado
tiver acesso total a sua implementação e a plataforma de execução, será incapaz de extrair
informações a respeito sobre a chave de criptografia (Gesser, 2010).
24
3 DESENVOLVIMENTO
Este capítulo detalha as etapas do desenvolvimento da ferramenta. São apresentados os
requisitos, a especificação e a implementação do mesmo, mencionando as técnicas e
ferramentas utilizadas.
O desenvolvimento da ferramenta envolveu as fases de instalação e configuração do
ambiente de desenvolvimento Xcode, introdução ao desenvolvimento e depuração de
aplicações, levantamento de requisitos, especificação e posterior implementação da aplicação.
O trabalho consiste em um aplicativo para o iPhone para efetuar o registro de
frequência dos alunos, conectando-se ao servidor do CFN através de funções disponíveis em
um webservice, possibilitando ser usado de maneira offline, salvando as informações no
aparelho e atualizando as informações no servidor quando a conexão com a internet for
reestabelecida.
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO
Os requisitos apresentados encontram-se classificados em Requisito Funcional (RF) e
Requisito Não-Funcional (RNF), os quais são:
a) a ferramenta deverá disponibilizar uma interface para permitir o registro das
frequências (RF);
b) a ferramenta deverá permitir a seleção de disciplinas, aulas e alunos (RF);
c) a ferramenta deverá permitir o registro de frequência mesmo quando offline (RF);
d) a ferramenta deverá se comunicar com o servidor do CFN através de um
webservice (RF);
e) a ferramenta deverá ser implementado na linguagem de programação Objective-C
(RNF);
f) a ferramenta deverá ser implementado utilizando o ambiente de desenvolvimento
Xcode 4.3 (RNF);
g) a ferramenta deverá ser implementado utilizando as bibliotecas disponíveis no
iPhone SDK (RNF);
25
3.2 ESPECIFICAÇÃO
A especificação do presente trabalho foi desenvolvida utilizando a notação Unified
Modeling Language (UML) em conjunto com a ferramenta Dia, gerando os diagramas de
casos de uso, de classes e de sequência apresentados nas seções seguintes.
3.2.1 Casos de uso
O diagrama de casos de uso é representado pela Figura 8 com as interações com o ator
Professor.
Figura 8 – Ações disponíveis ao professor
3.2.1.1 Efetuar login
O primeiro caso de uso UC01 – Efetuar Login (Quadro 1) descreve como o
professor efetua o login na aplicação.
26
UC01 – Efetuar login: possibilita ao professor conectar-se a base de dados do CFN. Pré-condição O professor possuir um cadastro na base de dados do CFN.
Cenário principal 1. O professor informa o nome e a senha. 2. O professor clica no botão entrar.
Fluxo alternativo 01
Caso não existir conexão com a internet, os dados do professor serão obtidos através dos registros salvos no banco de dados local.
Exceção No passo 1 do cenário principal, caso o professor informe um nome ou uma senha que são inválidos, uma mensagem de erro é mostrada.
Pós-condição A conexão com a base de dados do CFN é estabelecida. Quadro 1 – Caso de uso UC01
3.2.1.2 Selecionar disciplina
O segundo caso de uso UC02 – Selecionar disciplina (Quadro 2) descreve como
o professor efetua a seleção de uma disciplina.
UC02 – Selecionar disciplina: possibilita ao professor selecionar uma disciplina para efetuar a marcação de frequência.
Pré-condição O desenvolvedor deve ter executado o caso de uso UC01. Cenário principal 1. O professor seleciona uma das disciplinas listadas. Fluxo alternativo
01 Caso não existir conexão com a internet, as disciplinas serão obtidas através dos registros salvos no banco de dados local.
Fluxo alternativo 02
Caso o usuário desejar desconectar, este deve clicar no botão sair.
Pós-condição É exibido uma lista com os dias de aula da disciplina. Quadro 2 – Caso de uso UC02
3.2.1.3 Selecionar aula
O terceiro caso de uso UC03 – Selecionar aula (Quadro 3) descreve como o
professor efetua a seleção de aula da disciplina selecionada.
27
UC03 – Selecionar aula: possibilita ao professor selecionar uma aula para efetuar a marcação de frequência.
Pré-condição O desenvolvedor deve ter executado o caso de uso UC02. Cenário principal 1. O professor seleciona uma das aulas listadas. Fluxo alternativo
01 Caso não existir conexão com a internet, as aulas serão obtidas através dos registros salvos no banco de dados local.
Fluxo alternativo 02
Caso o professor desejar desconectar, este deve clicar no botão sair.
Pós-condição É exibido uma lista com os alunos da disciplina e a quantidade de frequência.
Quadro 3 – Caso de uso UC03
3.2.1.4 Efetuar frequência
O quarto caso de uso UC04 – Efetuar frequência (Quadro 4) descreve como o
professor efetua o registro da frequência dos alunos.
UC04 – Efetuar frequência: possibilita ao professor registrar a frequência dos alunos da disciplina.
Pré-condição O desenvolvedor deve ter executado o caso de uso UC03. Cenário principal 1. O professor seleciona um aluno.
2. O professor informa a quantidade de faltas (0, 1, 2, 3 ou 4). 3. O professor clica no botão salvar.
Fluxo alternativo 01
Caso não exista conexão com a internet, os alunos e frequências serão obtidos através de registros salvos no banco de dados local.
Fluxo alternativo 02
Caso o professor desejar desconectar, este deve clicar no botão sair.
Exceção No passo 3 do cenário principal, se não existir conexão com a internet, as informações do aluno e da frequência serão salvos na base de dados local e salvos em uma lista de espera. Esta lista será processada no momento que existir conexão com a internet, fazendo o registro da frequência na base do CFN.
Pós-condição A frequência é registrada na base de dados do CFN. Quadro 4 – Caso de uso UC04
3.2.2 Diagrama de classes
O diagrama de classes apresenta uma visão de como as classes estão estruturadas e
relacionadas. Nesta seção são descritas as classes necessárias para o desenvolvimento da
aplicação. A Figura 9 demonstra o diagrama de pacotes da aplicação, bem como as classes
envolvidas.
28
Figura 9 – Diagrama de pacotes da aplicação CFN
3.2.2.1 Pacote Controllers
Este pacote é composto por classes da camada de visão do aplicativo, as quais estão
diretamente relacionadas com o Storyboard do projeto. O Storyboard é uma representação
visual das interfaces do usuário de uma aplicação para iOS, mostrando conteúdo das telas e as
conexões entre as telas. Ele é composto por uma sequência de cenas, onde cada cena
representa uma tela (APPLE, 2012e).
A Figura 10 ilustra o StoryBoard da aplicação CFN.
Figura 10 - Storyboard
29
Cada classe representa uma tela do StoryBoard da aplicação. Conforme a lógica
aplicada em cada tela, a quantidade de atributos e métodos varia. A classe
CFNBaseViewController é a classe base das interfaces da aplicação. Ela contém métodos
para informar ao professor se o aplicativo está funcionando de forma offline (sem conexão
com a internet), se está processando alguma solicitação feita pelo professor e a execução da
lista de frequências salvas que não foi possível enviar para o servidor no momento que o
professor salvou a frequência.
A classe CFNLoginViewController controla a tela que permite o professor efetuar a
conexão com a base de dados do CFN, assim como as validações se os dados de login
informados são válidos. É necessário que o professor pressione o botão responsável pela
transição desta classe para a classe que lista as disciplinas.
A listagem das disciplinas do professor é controlada pela classe
CFNDisciplinasViewController. A propriedade disciplinas é um objeto da classe
NSArray que é utilizado para armazenar as informações das disciplinas carregadas da base de
dados local do aparelho após os dados terem sido recebidos pelo webservice e armazenados
no atributo dadosDisciplinas que também é um objeto da classe NSArray.
Após selecionar uma disciplina, são listadas as aulas daquela disciplina. A classe
responsável por controlar as aulas é a CFNAulasViewController. Esta classe possui um
atributo aulas da classe NSArray que armazena as datas das aulas da disciplina selecionada e
exibe na tela para o professor selecionar que aula deseja registrar a frequência.
A classe CFNAlunosViewController é encarregada da tela que exibe os alunos da
disciplina selecionada e a frequência a ser registrada. Após selecionar a frequência e
pressionar o botão salvar, a frequência é salva na base de dados do CFN (caso a aplicação
esteja conectada a internet) e o próximo aluno da lista é selecionado através do método
selecionaProximoAluno.
Por último, a classe CFNSobreViewController é responsável apenas por exibir uma
tela com o nome das pessoas envolvidas no desenvolvimento da aplicação.
A Figura 11 ilustra as classes envolvidas no pacote controllers.
30
Figura 11 – Pacote Controllers
3.2.2.2 Pacote Auxiliares
Este pacote (Figura 12) abriga as classes auxiliares que contém toda a lógica da
aplicação.
A classe CFNWebservice contém os métodos necessários para efetuar a autenticação
na base de dados do CFN, listar as disciplinas do professor, listar os alunos de uma
determinada disciplina e efetuar o registro da frequência do aluno.
A criptografia das informações é de responsabilidade da classe CFNCriptografia,
contendo o método rsa_decrypt que resultará em uma chave de encriptação que será usada
para criptografar as demais informações a serem enviadas através do método
criptografaString.
A classe CFNDadosSessao contém atributos que armazenam informações essenciais
para serem utilizadas nas várias telas da aplicação. O atributo conexãoON é um exemplo, onde
em cada uma das telas da aplicação é verificado se a conexão com a internet está ativa.
A verificação se existe uma conexão com a internet ativa é feita pela classe
31
Reachability, que foi desenvolvida pela Apple, porém não integra no SDK de
desenvolvimento do iPhone. Através do método isReachable é determinado se a aplicação
consegue conectar-se a internet ou não.
Já a classe CFNXmlParser trata de converter o retorno do webservice, que está no
formato JSON, em objetos da linguagem Objective-C. O método
iniciaComDadoseRetornaSemConversao faz esta conversão.
Por último, a classe CFNBancoDados é responsável por inserir, alterar, excluir, os dados
do professor, disciplinas, aulas, alunos e frequências na base de dados local do aparelho
através do framework CoreData.
Figura 12 – Pacote Auxiliares
3.2.2.3 Pacote Banco
Neste pacote encontram-se as classes que tratam a inclusão, alteração e exclusão das
informações no banco de dados local.
32
A Figura 13 mostra o diagrama de classes do pacote.
Figura 13 – Pacote Banco
A classe Professor contém atributos que armazenam as informações do professor, tal
como o atributo usuario e senha. Possui também métodos para adicionar e excluir uma
disciplina específica ou então uma lista de disciplinas.
Na classe Disciplina é armazenado as informações das disciplinas como nome e
código. O atributo professor armazena o código do professor que ministra a disciplina.
Conta ainda com métodos para adicionar ou excluir aulas e alunos.
As classes Aula e Aluno além de terem atributos para guardar as informações
33
pertinentes a cada um, possuem um atributo disciplina que armazena o código da disciplina
a qual pertencem.
As classes Frequencia e PoolFrequencia armazenam a frequência registrada, porém
esta última contém o atributo salvou, que determina se a frequência já foi salva na base de
dados do CFN. Quando este atributo for verdadeiro, a frequência é excluída da base de dados
local do aparelho pois tal informação já vai existir na classe Frequencia.
As classes Adicionais tem como objetivo adicionar nas classes a funcionalidade de
recuperar as informações do banco de dados. A classe PoolFrequencia possui além desta
funcionalidade os métodos para excluir uma frequência do banco de dados e alterar uma
frequência informando que a mesma foi salva na base de dados do CFN.
3.2.3 Diagrama de sequência
O diagrama de sequência apresenta uma visão interna do processo e da comunicação
entre as classes para cada caso de uso. A seguir são apresentados os diagramas de sequência
referentes ao casos de uso UC01, UC02, UC03 e UC04.
A Figura 14 demonstra o diagrama de sequência referente ao caso de uso UC01.
Figura 14 – Diagrama de sequência referente ao caso de uso UC01
34
A Figura 15 demonstra o diagrama de sequência referente ao caso de uso UC02.
Figura 15 – Diagrama de sequência referente ao caso de uso UC02
A Figura 16 demonstra o diagrama de sequência referente ao caso de uso UC03.
Figura 16 – Diagrama de sequência referente ao caso de uso UC03
A Figura 17 demonstra o diagrama de sequência referente ao caso de uso UC04.
Figura 17 – Diagrama de sequência referente ao caso de uso UC04
3.2.4 Banco de dados / Persistência
A Figura 18 ilustra o modelo de entidade e relacionamento (MER) da aplicação,
gerado através do framework CoreData.
As tabelas Professor, Disciplina, Aula, Aluno e Frequencia possuem atributos
para armazenar as informações necessárias para a aplicação.
A tabela PoolFrequencia é uma cópia da tabela de Frequencia, porém contém o
35
atributo salvou a mais.
Figura 18 – Modelo de entidades e relacionamentos da aplicação
3.3 IMPLEMENTAÇÃO
A seguir são descritas as técnicas e ferramentas utilizadas na implementação, bem
como detalhes das principais classes e rotinas implementadas durante o desenvolvimento da
aplicação.
3.3.1 Técnicas e ferramentas utilizadas
Nesta seção são demonstradas as técnicas e ferramentas utilizadas no desenvolvimento
da aplicação.
36
3.3.1.1 Webservice
Para a comunicação da aplicação com a base de dados do CFN foi desenvolvido um
webservice utilizando a linguagem de programação Java e foi disponibilizado para uso pela
DME. O webservice retorna um objeto do tipo JavaScript Object Notation (JSON) com as
informações solicitadas.
JSON é um formato para troca de dados, tal como o XML, sendo fácil a leitura, escrita
das informações e também a análise e geração por máquinas. É completamente independente
da linguagem de programação, mas usa convenções que são familiares para os programadores
da linguagem de programação C, C++, C#, Java, JavaScript, Perl, Python e muitas outras.
Com isto, JSON se torna ideal para a troca de dados (JSON, 2012).
Ele utiliza duas estruturas de dados mundialmente conhecidas:
a) uma coleção com pares de nomes/valores. Em várias linguagens de programação
esta definição é conhecida como struct, dictionary, hash table;
b) uma lista ordenada de valores. Em várias linguagens de programação esta definição
é conhecida como array, list, vector.
A Figura 19 ilustra o formato de um objeto JSON.
Figura 19 – Formato de um objeto JSON
O Quadro 5 demonstra a chamada de um método do webservice. É usado como
exemplo o método buscaDisciplinasComPessoa:(NSString *)cdPessoa
usandoAcesso:(NSString *)chAuth.
37
... 88. - (NSArray *)buscaDisciplinasComPessoa:(NSString *)cdPessoa usandoAcesso:(NSString *)chAuth { 89. 90. NSString *metodo = [[NSString alloc] initWithFormat:@"op=BUSCA_DISCIPLINAS&chaveAuth=%@&codigoPessoa=%@", chAuth, cdPessoa]; 91. 92. NSData *data = [self executaMetodo:[self montaMensagemComMetodo:metodo]]; 93. 94. if (data != nil) { 95. return [[CFNXmlParser parser] iniciaComDados:data eRetornaSemConversao:NO]; 96. } 97. return nil; 98. }
Quadro 5 – Exemplo de chamada de um método do webservice
Na linha 90 é criado um objeto de nome metodo, da classe NSString e alocado na
memória através do método alloc. Em seguida é definido o método do webservice que vai
ser chamado através do método initWithFormat, passando como parâmetros o código da
pessoa e a chave de acesso que estão armazenados nas variáveis cdPessoa e chAuth
respectivamente.
A linha 92 mostra a variável metodo sendo passada como parâmetro para o método
montaMensagemComMetodo e o retorno deste método é passado como parâmetro para o
método executaMetodo. Após enviar as informações para o webservice, o resultado é
armazenado na variável data, da classe NSData.
Em seguida é feita uma verificação na variável data para ver se esta possui dados e se
for verdadeiro é chamado o trecho de código conforme demonstrado nas linhas 94 a 98. Este
método faz a conversão dos dados retornados do webservice em objetos JSON. A variável
parser é um objeto em memória da classe CFNXmlParser.
Os quadros 6, 7 e 8 demonstram com mais detalhes os métodos
montaMensagemComMetodo, executaMetodo e iniciaComDadoseRetornaSemConversao,
respectivamente. ...
45. - (NSString *)montaMensagemComMetodo:(NSString *)metodo { 46. 47. NSString *mensagemCriptografada = [[CFNCriptografia criptografia] criptografaString:metodo withChave:[chaveEncriptacao intValue]]; 48. 49. NSString *mensagem = [[NSString alloc] initWithFormat: @"<mensagem xmlns=\"http://ava.furb.br/\">\n" "<string_criptografada xsi:type=\"xsd:string\">%@</string_criptografada>\n" "</mensagem>\n", mensagemCriptografada];
... Quadro 6 – Definição do método montaMensagemComMetodo
38
No Quadro 6 na linha 47 é chamado o método criptografaStringwithChave
passando como parâmetro a variável metodo e a chave de encriptação obtida no momento da
autenticação com o webservice. O resultado deste método é armazenado na variável
mensagemCriptografada.
Em seguida na linha 49 é alocado um objeto do tipo NSString através do método
alloc e através do método initWithFormat a mensagem criptografada é formatada em xml
para ser enviada ao webservice. ...
151. NSURL *url = [NSURL URLWithString:@"http://ava.furb.br/servicos/cfn/webservice_cfn_json_crypt.php"]; 152. NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url]; 153. NSString *tamanhoMsg = [NSString stringWithFormat:@"%d", [xmlEnvio length]]; 154. 155. [request addValue:@"text/xml" forHTTPHeaderField:@"Content-Type"]; 156. [request addValue:@"" forHTTPHeaderField:@"SOAPAction"]; 157. [request addValue:tamanhoMsg forHTTPHeaderField:@"Content-Length"]; 158. [request addValue:@"ava.furb.br" forHTTPHeaderField:@"Host"]; 159. [request setHTTPMethod:@"POST"]; 160. [request setHTTPBody:[xmlEnvio dataUsingEncoding:NSUTF8StringEncoding]]; 161. 162. NSURLResponse *response; 163. NSData *data; 164. data = [NSURLConnection sendSynchronousRequest:request returningResponse:&response error:nil];
... Quadro 7 – Definição do método executaMetodo
No Quadro 7 na linha 151, um objeto da classe NSURL é instanciado para receber o
endereço do webservice do CFN. Na linha 152 através do comando [NSMutableURLRequest
requestWithURL:url] é criado um canal de comunicação com o webservice utilizando o
endereço armazenado na variável url e atribuído a variável request. A linha 153 define o
tamanho do xml que precisa ser preenchido posteriormente no cabeçalho da requisição.
As linhas 155 a 158 preenchem o cabeçalho da requisição informando que será
enviado um arquivo do tipo XML através do comando addValue:@"text/xml"
forHTTPHeaderField:@"Content-Type"]. Também é informado o tamanho do XML
utilizando o comando addValue:tamanhoMsg forHTTPHeaderField:@"Content-Length"],
o host onde o webservice está armazenado através do comando addValue:@"ava.furb.br"
forHTTPHeaderField:@"Host"] e também o método POST através do comando
setHTTPMethod que define o envio de informações para o webservice.
Na linha 160 é atribuído o arquivo xml que vai ser enviado através do comando
39
[request setHTTPBody:[xmlEnvio dataUsingEncoding:NSUTF8StringEncoding]].
O comando [NSURLConnection sendSynchronousRequest:request
returningResponse:&response error:nil] na linha 164 faz o envio do arquivo XML e o
retorno do webservice com as informações é armazenado na variável data. ...
51. NSArray *array; 52. if (semConversao) { 53. array = [[NSArray alloc] initWithObjects:[soapResults copy], nil]; 54. } else { 55. array = [NSJSONSerialization JSONObjectWithData:[soapResults dataUsingEncoding:NSStringEncodingConversionAllowLossy] options:kNilOptions error:nil]; 56. }
... Quadro 8 – Definição do método iniciaComDadoseRetornaSemConversao
No Quadro 8 na linha 51 é declarado uma variável de nome array do tipo NSArray
que vai armazenar a conversão do retorno do webservice. A linha 55 demonstra a variável
soapResults, que contém o XML de retorno do webservice, sendo passada por parâmetro
para o método JSONObjectWithData da classe NSJSONSerialization, responsável pela
conversão dos dados em objetos da linguagem Objective-C.
3.3.1.2 CFN
A ferramenta desenvolvida foi chamada de CFN e foi implementada sob o paradigma
da orientação a objetos na linguagem de programação Objective-C, utilizando o ambiente de
desenvolvimento Xcode versão 4.3.3 (para codificação e desenho das interfaces), em sistema
operacional Mac OS X versão 10.7.4. Este ambiente oferece todos os recursos necessários
para o desenvolvimento da aplicação. A ferramenta possui recursos de login, seleção de
disciplinas, seleção de aulas e registro da frequência dos alunos.
Um diferencial da aplicação é a capacidade de funcionar normalmente caso a aplicação
não possua conexão com a internet. É necessário que pelo menos no primeiro acesso a
ferramenta, a conexão com a internet esteja estabelecida para gravar as informações na base
de dados do aparelho.
O Quadro 9 demonstra como é realizada essa verificação e como a aplicação se
comporta. Como o código desenvolvido é padrão para o login, seleção de disciplinas, aulas e
alunos, é utilizado o login como exemplo.
40
... 59. if ([[CFNDadosSessao sessao] conexaoON]) { 60. 61. dispatch_queue_t autenticacao = dispatch_queue_create("autenticacao", NULL); 62. dispatch_async(autenticacao, ^{ 63. dispatch_async(dispatch_get_main_queue(), ^{ 64. [self mostrarMensagemComTipo:[super tipoProcessando]]; 65. }); 66. self.dadosAutenticacao = [[CFNWebservice webservice] autenticaComUsuario:usuario.text eSenha:senha.text]; 67. [self terminouRequisicaoWebservice]; 68. }); 69. dispatch_release(autenticacao); 70. 71. } else { 72. 73. [self carregaProfessorComDados:nil]; 74. [self performSegueWithIdentifier:@"Disciplinas" sender:nil]; 75. }
... Quadro 9 – Exemplo da verificação da conexão com a internet
No Quadro 9 na linha 59 é utilizado o método conexaoON da classe CFNDadosSessao
para verificar se existe uma conexão com a internet ativa. Caso o retorno do método seja
verdadeiro então conforme a linha 61 demonstra, é criada uma fila cujo objetivo é processar
paralelamente o código que estiver nela, evitando assim que a tela principal da aplicação fique
travada esperando que o processo seja finalizado. O método dispatch_async é que
determina a execução da fila de maneira assíncrona.
Na linha 66 é realizada a chamada do método autenticaComUsuarioeSenha da classe
CFNWebservice passando como parâmetro o usuário e a senha. O retorno do webservice é
armazenado na variável dadosAutenticacao, um objeto da classe NSArray.
A linha 67 demonstra a chamada do método terminouRequisicaoWebservice que
tem por finalidade salvar as informações na base de dados local do aparelho e exibe a próxima
tela, no caso a lista de disciplinas.
Se não existir conexão com a internet, as informações são recuperadas da base de
dados local do aparelho, através do método carregaProfessorComDados e logo após é
executado o método performSegueWithIdentifier passando por parâmetro a palavra
Disciplinas, que vai exibir a lista de disciplinas, conforme demonstra as linhas 71 a 75.
Outro diferencial da aplicação é a capacidade de armazenar na base local do aparelho
as frequências que não foram salvas na base de dados do CFN, se no momento de registrar a
frequência do aluno não existir conexão com a internet. As frequências são armazenadas na
tabela PoolFrequencia. Os registros presentes nesta tabela serão processados no momento
que existir conexão com a internet ou então no início da aplicação, após ser efetuado o login.
41
O código responsável por processar a pool de frequências é demonstrado no Quadro
10. ...
116. NSArray *pool = [PoolFrequencia frequenciasNaPoolDoProfessor:professor usingContext:context]; 117. if ([pool count] > 0) { 118.
... 122. if ([[CFNDadosSessao sessao] necessitaLogar]) { 123. 124. NSArray *dadosAutenticacao = [[CFNWebservice webservice] autenticaComUsuario:professor.usuario eSenha:professor.senha];
... 128. } 129. 130. PoolFrequencia *frequencia = nil; 131. for (int i = 0; i < [pool count]; i++) { 132. 133. frequencia = [pool objectAtIndex:i]; 134. 135. Aluno *aluno = frequencia.aluno; 136. Aula *aula = frequencia.aula; 137. 138. [[CFNWebservice webservice] liberaFrequenciaAulaComPessoa:professor.codigo eLiberar:@"true" paraAula:aula.codigo usandoAcesso:professor.acesso]; 139. 140. [[CFNWebservice webservice] efetuaFrequenciaComPessoa:professor.codigo eAluno:aluno.codigo eFrequencia:frequencia.quantidade paraAula:aula.codigo usandoAcesso:professor.acesso]; 141. 142. frequencia = [PoolFrequencia salvouFrequenciaDaPool:frequencia usingContext:context]; 143. 144. [PoolFrequencia removeFrequencia:frequencia usingContext:context]; 145. } 146.
... 149. }
Quadro 10 – Exemplo da rotina que processa a pool de frequências
3.3.2 Operacionalidade da implementação
A operacionalidade da aplicação é apresentada em função dos casos de uso da
aplicação, fazendo o uso de imagens para facilitar o entendimento de cada uma das
funcionalidades disponibilizadas. A seguir são apresentadas as seguintes funcionalidades da
aplicação CFN: Efetuar login, Selecionar disciplina, Selecionar aula e Efetuar
42
frequência.
3.3.2.1 Efetuar login
Esta funcionalidade permite ao professor efetuar o login na base de dados do CFN. O
caso de uso criado para esta funcionalidade é o UC01 - Efetuar login. Ao iniciar a
aplicação o professor deve informar um nome de usuário e uma senha, conforme demonstrado
na Figura 20.
Figura 20 – Efetuar login
Para efetuar o login, o professor deve seguir os seguintes passos:
a) preencher o campo usuario;
b) preencher o campo senha;
c) clicar no botão Entrar.
3.3.2.2 Selecionar disciplina
Esta funcionalidade permite ao professor selecionar uma disciplina para listar as aulas.
43
O caso de uso criado para esta funcionalidade é o UC02 - Selecionar disciplina. A
Figura 21 demonstra como selecionar a disciplina. Para selecionar uma disciplina o professor
deve clicar no nome da disciplina desejada e depois clicar no botão Selecionar.
Figura 21 – Selecionar disciplina
3.3.2.3 Selecionar dia da aula
Esta funcionalidade permite ao professor selecionar uma aula para listar os alunos. O
caso de uso criado para esta funcionalidade é o UC03 – Selecionar aula. A Figura 22
demonstra como selecionar a aula. Para selecionar uma aula o professor deve clicar no nome
da aula que deseja efetuar a frequência e depois clicar no botão Selecionar.
44
Figura 22 – Selecionar aula
3.3.2.4 Registrar frequência
Esta funcionalidade permite ao professor registrar a frequência do aluno. O caso de uso
criado para esta funcionalidade é o UC04 – Efetuar frequência. A figura 23 demonstra
como registrar a frequência.
45
Figura 23 – Registrar frequência
Para registrar a frequência o professor deve seguir os seguintes passos:
a) clicar no nome do aluno e selecionar a quantidade de faltas;
b) clicar no botão Salvar para efetuar a frequência.
Se o registro de frequência for concluído com sucesso, após o usuário clicar no botão
Salvar, o próximo aluno da lista já vai ser automaticamente selecionado. Caso no momento
de salvar a frequência o aplicativo não possuir conexão com a internet (Figura 24), a
frequência será salva na base de dados local e em uma lista de pool. No momento que o
aplicativo conectar-se a internet, esta lista de pool será executada salvando as frequências da
base de dados do CFN.
46
Figura 24 – Aplicação em modo offline
3.4 RESULTADOS E DISCUSSÃO
O presente trabalho apresentou o projeto e desenvolvimento de uma ferramenta para o
iPhone para servir de apoio ao professor. O propósito é ler informações de uma base de dados,
tais como as disciplinas de um determinado professor e os alunos de uma determinada
disciplina, mostrar estas informações no iPhone e gravar o registro de frequência novamente
na base de dados, utilizando um webservice para a comunicação da aplicação com a base de
dados.
A aplicação foi desenvolvida utilizando a técnica de orientação a objetos. Optou-se por
utilizar esta técnica pois isto facilita a leitura e a reutilização de código permitindo uma
compreensão maior do código escrito, além do fato do próprio SDK para iPhone ser todo
baseado em orientação a objetos.
Tanto a análise de uso da memória quanto os testes de performance foram efetuados
utilizando-se o simulador disponibilizado pela Apple para a criação de aplicações. Durante os
testes não foi percebido qualquer travamento da aplicação, mas é importante evidenciar que
47
não existia nenhuma outra aplicação utilizando a conexão com a internet.
O hardware utilizado possui a seguinte descrição básica:
a) notebook Apple modelo Macbook Pro;
b) processador Intel Core 2 Duo 2.53 Gigahertz, com 3 Megabytes de cache L2;
c) quatro gigabytes de memória RAM DDR3 1067Mhz;
d) sistema operacional Mac OS X versão 10.7.4;
e) resolução de vídeo 1280 x 800, com profundidade de 32 bits de cores.
3.4.1 Performance
Para a marcação do tempo médio que a aplicação leva para efetuar as etapas, foi
utilizado o método NSLog em pontos estratégicos. Foram colocadas marcações antes de
chamar um método do webservice e após o retorno. O Quadro 11 demonstra tais marcações.
Quadro 11 – Marcações utilizadas para medir o tempo
Desta forma sempre são analisadas marcações pares subtraindo o tempo da segunda
pelo tempo da primeira, resultando no tempo em que a aplicação leva para enviar e receber
informações do webservice.
No Quadro 12 é possível ver o tempo médio que cada etapa levou para ser concluída. Tempo em milisegundos
Etapa Teste 1 Teste 2 Teste 3
Login 392.920017 298.422039 293.250024
Disciplinas/Aulas 214.927971 219.231009 205.751956
Alunos 478.410017 301.588953 303.384960
Frequência 794.843018 618.809998 557.292044
Quadro 12 – Tempo médio para comunicação com o webservice
48
Na Figura 25 é possível visualizar o tempo médio em milisegundos na forma de
gráfico.
Figura 25 – Gráfico do tempo médio em milisegundos para comunicação com o webservice
As disciplinas e aulas são medidas em conjunto porque o mesmo método que retorna
as disciplinas também retorna os dados das aulas.
Para a etapa dos alunos foi utilizado uma disciplina com 40 alunos em média mas não
significa que uma quantidade maior de alunos vai aumentar o tempo médio. Durante os testes
constatou-se que a performance da aplicação e o tempo de comunicação da aplicação com a
base de dados está relacionado mais diretamente a velocidade da conexão com a internet e ao
tempo de resposta do servidor do CFN.
Por fim, foi marcado o tempo médio que a aplicação leva para apresentar o resultado
na interface e o professor perceber que tal etapa foi concluída. O tempo foi marcado
colocando marcações no início de ações que o professor executa: login, selecionar uma
disciplina, selecionar uma aula, registrar uma frequência e marcações no final do método
viewDidApper que é quando a tela é carregada e exibida na aplicação. No Quadro 13 é
demonstrado estes tempos. Tempo em milisegundos
Etapa Teste 1 Teste 2 Teste 3
Login 214.856029 254.813015 218.141973
Disciplinas 931.935012 972.082019 934.486985
Aulas 364.683986 364.766002 366.485000
Alunos 367.088974 367.820978 369.536996
Frequência 501.836002 462.926984 426.882029
Quadro 13 – Tempo médio para exibir resultado na interface
49
A Figura 26 demonstra um gráfico destes tempos.
Figura 26 – Gráfico do tempo médio para exibir resultado na interface
3.4.2 Uso da memória
A análise do uso de memória da aplicação foi feita utilizando a ferramenta Instruments
na versão 4.3 disponibilizada junto com o SDK. Com o Instruments é possível tirar heapshots,
que são como uma fotografia da memória em determinado momento. Pode-se então comparar
o uso de memória em determinados tempos e observar os objetos que foram alocados e sua
quantidade de bytes.
A Figura 27 mostra os heapshots tirados com o Instruments.
50
Figura 27 – Heapshots no Instruments
O primeiro heapshot (Baseline) é tirado assim que a aplicação completou sua
inicialização. Depois é feito o login e a busca das disciplinas tirando logo em seguida o
heapshot 1. Após selecionar uma disciplina e listar as aulas foi tirado o heapshot 2. Em
seguinda é feito a seleção da aula e a busca dos alunos e tirado o heapshot 3. O heapshot 4 é
tirado após o registro da frequência.
No Quadro 14 é possível identificar quantos bytes cada objeto de classe ocupa em
memória. Classe Bytes
CFNLoginViewController 192
CFNDisciplinasViewController 192
CFNAulasViewController 208
CFNAlunosViewController 208
CFNBancoDados 16
CFNCriptografia 16
CFNDadosSessao 32
CFNXmlParser 16
CFNWebservice 16
Reachability 32
Quadro 14 – Quantidade bytes por classe
Também foi possível identificar quantos bytes cada objeto da classe Professor,
Disciplina, Aula, Aluno, Frequencia e PoolFrequencia ocupa em memória, conforme o
51
Quadro 15. Classe Bytes
Professor 64
Disciplina 64
Aula 64
Aluno 48
Frequencia 48
PoolFrequencia 48
Quadro 15 – Quantidade de bytes do objetos do banco de dados
Utilizando a fórmula apresentada no Quadro 16, onde MN representa a memória
necessária para ser alocada, QO a quantidade de objetos e QB a quantidade de bytes, é possível
determinar quanto de memória será preciso alocar caso o número de disciplinas, aulas, alunos
seja maior.
MN = QO * QB
Quadro 16 – Fórmula matemática para o cálculo de memória necessária
52
4 CONCLUSÕES
Uma das principais motivações para que fosse realizado o trabalho é explorar a
tecnologia que o iPhone dispõe, criando um aplicativo para ser utilizado por professores com
possibilidade de ser usado em qualquer lugar, através da internet.
Os resultados finais foram satisfatórios, pois foi possível realizar o objetivo principal
da aplicação que é efetuar o registro da frequência pelo iPhone, enviar os dados de forma
criptografada para o webservice, gravar informações na base de dados local do aparelho
quando estiver em modo offline e atualizar as informações quando o acesso a internet for
estabelecido.
Quanto as tecnologias utilizadas, a IDE de desenvolvimento Xcode, se mostrou
suficiente e eficiente para o desenvolvimento. A integração com o simulador do iPhone,
facilita muito o desenvolvimento.
Como limitação a ferramenta não possui o sincronismo de forma bidirecional, que é
quando independente de onde a informação é registrada (aplicativo no celular ou site), após a
sincronização os dados são os mesmos em ambos mantendo uma coerência das informações.
Como vantagem a ferramenta possui uma arquitetura de fácil entendimento e através
dos testes de usabilidade também foi possível perceber que a ferramenta é bem prática para o
professor efetuar o registro de frequência. Já os testes de perfomance mostraram que a
ferramenta exige pouco processamento de CPU, sendo assim o tempo de resposta da
ferramenta para as ações feitas pelo professor depende exclusivamente da velocidade de
conexão com a internet. Já o teste de memória mostrou que a ferramenta inteira ocupou
aproximadamente 1,5 MB de memória utilizando uma disciplina com uma média de 50
alunos.
A maior dificuldade em relação ao desenvolvimento foi a utilização do webservice. Por
ter sido desenvolvido pela DME, as dúvidas que surgiam na utilização, ficavam na depedência
de disponibilidade da equipe do DME.
Já os trabalhos correlatos mostraram que o algoritmo RSA utilizado neste trabalho se
mostrou mais simples de ser implementado e entendido. Pelo fato de ser utilizado uma chave
pública para encriptar e só ser possível desencriptar com a chave privada, o RSA se mostra
bastante confiável. Os trabalhos mostraram também que a sincronização agregaria agilidade a
ferramenta fazendo buscar os dados do webservice somente quando houvesse alguma
alteração.
53
4.1 EXTENSÕES
Durante o desenvolvimento do trabalho, foram verificadas possíveis melhorias para o
mesmo, que não puderam ser contempladas neste trabalho. Uma das melhorias que pode ser
feita é a inclusão, alteração e exclusão de notas, avaliações e fórmulas de média, tornando
assim a aplicação mais completa para o controle de disciplinas. Os métodos para efetuar tais
ações já estão disponíveis no webservice para serem utilizadas, bastando apenas efetuar as
alterações necessárias na aplicação.
Outra melhoria seria a respeito de como é efetuado o registro de frequência.
Atualmente para registrar a frequência é necessário selecionar o aluno, selecionar o número
de faltas e clicar no botão salvar. A frequência poderia ser registrada apenas selecionando o
número de faltas, evitando assim a necessidade de clicar no botão salvar.
Por fim, uma melhoria na parte de sincronização das informações do aplicativo. Como
não é possível saber o que foi incluído, alterado e excluído na base de dados do CFN, os
dados são sempre recuperados do webservice. Possibilitando essa alteração no webservice, a
aplicação somente precisaria efetuar a busca das informações na base de dados do CFN
quando houver alguma inclusão, alteração ou exclusão.
54
REFERÊNCIAS BIBLIOGRÁFICAS
ANDERSON, Paul; BLACKWOOD, Adam. Mobile and PDA technologies and their future use in education. [S.l.], 2004. Disponível em: <http://www.niace.org.uk/mobiletechnology/pdf/mobile/faq/JISCTechnologyandStandards.pdf>. Acesso em: 13 set. 2009.
APPLE. iOS. [S.l.], 2012a. Disponível em: <http://www.apple.com/br/iphone/ios/>. Acesso em: 19 jun. 2012.
_____. iPhone. [S.l.], 2012b. Disponível em: <http://www.apple.com/br/iphone/features/>. Acesso em: 19 jun. 2012.
_____. What’s new in Xcode 4. [S.l.], 2012c. Disponível em: <https://developer.apple.com/technologies/tools/whats-new.html>. Acesso em: 19 jun. 2012.
_____. Xcode 4. [S.l.], 2012d. Disponível em: <https://developer.apple.com/xcode/>. Acesso em: 19 jun. 2012.
_____. Storyboard. [S.l.], 2012e. Disponível em: <http://developer.apple.com/library/mac/#documentation/General/Conceptual/Devpedia-CocoaApp/Storyboard.html>. Acesso em 11 jun. 2012.
_____. Introduction to core data programming guide. [S.l.], 2011. Disponível em: <http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/CoreData/cdProgrammingGuide.html>. Acesso em: 29 maio. 2012.
BRAGHETTO. Criptografia assimétrica e assinatura digital. [S.l.], 2003. Disponível em: <http://www.braghetto.eti.br/files/Trabalho%20Oficial%20Final%20RSA.pdf>. Acesso em: 9 jun. 2012.
CETIC-BR. Pesquisa sobre as tecnologias da informação e da comunicação no Brasil. [S.l.], 2011. Disponível em: <http://www.cetic.br/usuarios/tic/2011-total-brasil/apresentacao-tic-domicilios-2011.pdf>. Acesso em: 19 jun. 2012.
CERT.BR. Criptografia. [S.l], 2003. Disponível em: <http://cartilha.cert.br/criptografia/>. Acesso em: 9 jun. 2012.
COSTA, Heitor. Bancos de dados orientados a objetos. [S.l.], 2003. Disponível em: <http://www.dcc.ufla.br/~heitor/Artigos/Artigo_007.html>. Acesso em: 19 jun. 2012.
55
GESSER, Thiago A. Sistema de proteção para servidores de jogos online contra softwares clientes não oficiais. 2010. 94 f. Trabalho de Conclusão de Curso (Bacharel em Ciência da Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
JSON. Introducing json. [S.l.], 2012. Disponível em: <http://www.json.org>. Acesso em: 19 jun. 2012.
MICROSOFT. Synchronizing data. [S.l.], 2012. Disponível em: <http://msdn.microsoft.com/en-us/library/ms151793.aspx>. Acesso em: 18 jun. 2012.
MOODLE. Mobile Moodle project. [S.l.], 2008. Disponível em: <http://www.mobilemoodle.org/momo18/>. Acesso em: 18 jun. 2012.
MÜLLER, Bernardo M. Synceasy – Aplicativo para sincronização de arquivos entre dispositivos móveis e computadores utilizando metadados. 2011. 56 f. Trabalho de Conclusão de Curso (Bacharel em Ciência da Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
REINHARD, Nicolau et al. Aprendizagem com mobilidade no contexto organizacional. [S.l.], 2007. Disponível em: <http://www.inf.unisinos.br/~mobilab/download/projeto.pdf>. Acesso em: 11 set. 2009.
REPLY. Dispositivos da Apple em mais um projeto de m-learning. [S.l.], 2008. Disponível em: <http://dotreply.blogspot.com/2008/03/dispositivos-da-apple-em-mais-um.html>. Acesso em: 19 jun. 2012.
TECHOTOPIA. The history of Objective-C. [S.l.], 2011. Disponível em: <http://www.techotopia.com/index.php/The_History_of_Objective-C>. Acesso em: 19 jun. 2012.
UNIVERSIDADE REGIONAL DE BLUMENAU. Divisão de modalidades de ensino: controle de frequência e notas. Blumenau, 2012. Disponível em: <http://ava.furb.br/ava/CFN_Beta/CFN.html#LOGIN>. Acesso em: 19 jun. 2012.
_____. Divisão de modalidades de ensino: controle de frequência e notas. Blumenau, 2009. Trabalho não publicado. [mensagem pessoal]. Mensagem recebida por <[email protected]> em 12 set. 2009.
WILSON, Tracy. Como funciona o iPhone. [S.l.], 2012. Disponível em: <http://eletronicos.hsw.uol.com.br/iphone.htm>. Acesso em: 18 jun. 2012.
