UNIVERSIDADE ANHEMBI MORUMBI ARIEL HENRIQUE CANAL DENNIS ESTEVÃO HOBSON GUILHERME LUIZ FERREIRA THIAGO BUENO DE OLIVEIRA

Transcrição

1 UNIVERSIDADE ANHEMBI MORUMBI ARIEL HENRIQUE CANAL DENNIS ESTEVÃO HOBSON GUILHERME LUIZ FERREIRA THIAGO BUENO DE OLIVEIRA ADAPTAÇÃO DA UNIDADE WEB E ÁREA DE SERVIÇOS AO ALUNO DA UNIVERSIDADE ANHEMBI MORUMBI PARA DISPOSITIVOS ANDROID São Paulo 2011

2 ARIEL HENRIQUE CANAL DENNIS ESTEVÃO HOBSON GUILHERME LUIZ FERREIRA THIAGO BUENO DE OLIVEIRA ADAPTAÇÃO DA UNIDADE WEB E ÁREA DE SERVIÇOS AO ALUNO DA UNIVERSIDADE ANHEMBI MORUMBI PARA DISPOSITIVOS ANDROID Trabalho de Conclusão de Curso apresentado como exigência parcial para a obtenção do título de Bacharel em Sistemas de Informação da Universidade Anhembi Morumbi. Orientadora: Profa. Msc. Regiane Aparecida Marucci São Paulo 2011

3 ARIEL HENRIQUE CANAL DENNIS ESTEVÃO HOBSON GUILHERME LUIZ FERREIRA THIAGO BUENO DE OLIVEIRA ADAPTAÇÃO DA UNIDADE WEB E ÁREA DE SERVIÇOS AO ALUNO DA UNIVERSIDADE ANHEMBI MORUMBI PARA DISPOSITIVOS ANDROID Trabalho de Conclusão de Curso apresentado como exigência parcial para a obtenção do título de Bacharel em Sistemas de Informação da Universidade Anhembi Morumbi, sob a orientação da Profa. Regiane Aparecida Marucci. Aprovado em Nome do orientador/titulação/ies Nome do convidado/ titulação/ies Nome do convidado/ies

4 Este trabalho é dedicado a todos os nossos familiares e amigos que nos apoiaram durante o desenvolvimento do projeto.

5 AGRADECIMENTOS Agradecemos a nossa Orientadora, professora Regiane Aparecida Marucci, pelo conhecimento compartilhado e pelas orientações precisas que nos ajudaram no decorrer do projeto. A todos os professores que nos ajudaram de forma direta e indireta com os conteúdos lecionados durante os quatro anos de curso.

6 A vida é uma peça de teatro que não permite ensaios. Por isso, cante, chore, dance, ria e viva intensamente, antes que a cortina se feche e a peça termine sem aplausos. (Charles Chaplin).

7 RESUMO Este trabalho propõe o desenvolvimento de um aplicativo móvel capaz de prover os principais dados e conteúdos disponíveis na Unidade Web e Área de Serviços ao Aluno (detalhados na seção Abrangência), ambos da Universidade Anhembi Morumbi. Em outras palavras, o aplicativo proposto visa oferecer aos alunos da Universidade uma alternativa de acesso aos dados já disponíveis a eles nos sistemas da Instituição. Os dados são capturados através de um webservice (também desenvolvido neste trabalho) e repassados para a interface da aplicação Android. O WebService foi desenvolvido com a plataforma.net da Microsoft e visa facilitar a adaptação dos mesmos serviços da Universidade para outras plataformas como, Symbian OS (celulares Nokia), ios (iphone, ipad e ipod Touch), RIM (celulares BlackBerry) e Windows Phone 7. As informações que estarão disponíveis para os usuários do aplicativo são: horários de aula, sala de aula de cada disciplina, nome do(s) professor(res), notas, quantidade de faltas do semestre, quantidade máxima de faltas (do semestre, por disciplina), plano de ensino, plano de aulas, material de aulas, atividades e consulta de notas. PALAVRAS CHAVE: Universidade Anhembi Morumbi. Aplicativo Android. Scraping. Webservice..NET

8 ABSTRACT The following document presents the development of a mobile application capable to provide the main data and content available at Unidade Web and Área de Serviços ao Aluno (detailed at Abrangência section), both systems from Anhembi Morumbi s University. In other words, the mobile application aims to offer to the students an alternative access to get the contents already available to them in both systems. Those contents will be captured through a webservice (the development will be explained in this document) and redirected to a Android device. The webservice was developed using the Microsoft s.net plataform and designed to integrate with others mobile operational systems such as Symbyan OS, ios, RIM and Windows Phone 7. The informations that will be available at the mobile application will be: classe schedule, classroom number for each discipline, name (s) teacher (rs), grades, number of absences of the semester, maximum number of absences (the semester, per discipline), teaching plan, teaching materials, activities and information of grades. KEYWORDS: Universidade Anhembi Morumbi. Android Application. Scraping. Webservice..NET

9 LISTA DE FIGURAS Figura 1: Tela de Abertura da Disciplina Figura 2: Passos para acesso à Unidade Web Figura 3: Tela de acesso a Central do Aluno Figura 4: Passos para consulta ao Horário de Aula Figura 5: Passos para acesso ao Boletim de Notas e Faltas Figura 6: Passos necessários para acesso às Faltas Mensais Figura 7: A Arquitetura do Android Figura 8: Versões da Plataforma Figura 9: Tamanhos de Tela e Densidades Figura 10: Linguagens que formam o XPath Figura 11: Informações sobre a conta do usuário diretamente no iphone Figura 12: Exemplo da obtenção do HTML da página inicial da Universidade Anhembi Morumbi Figura 13: Exemplo da Utilização do HTML Agility Pack e XPath para recuperar as informações necessárias Figura 14: Conteúdo do site da Anhembi Morumbi obtidos através de Web Scraping Figura 15: Implementação de um Contrato - Interface Figura 16: Implementação de um serviço que assina um contrato Figura 17: Arquitetura do WCF Figura 18: Exemplo de Objeto JSON Figura 19: Diagrama de Casos de Uso Figura 20: Fluxo de Comunicação Entre Os Módulos Figura 21: Representação dos arquivos do módulo UAM-droid_WebService Figura 22: Tela de Login da Área de Serviços ao Aluno Figura 23: Tela com os menus oferecidos ao aluno Figura 24: Lista com o nome e código de cada disciplina em que o aluno está matriculado Figura 25: Trecho de código que representa a técnica Web Scraping no Método GetListaDeDisciplinas Figura 26: Retorno do método GetListaDeDisciplinas em formato JSON... 59

10 Figura 27: Diagrama de classes que representa a camada UAM-droid_Model Figura 28: Diagrama de Classes do Módulo Android Figura 29: Formulário de Login do Aplicativo Android Figura 30: Tela de Disciplinas do Dia no Aplicativo Android Figura 31: Tela da Disciplina Detalhada no Aplicativo Android Figura 32: Tela de Termos de Privacidade no Aplicativo Android Figura 33: Passos para Obter Informações no Aplicativo Android Figura 34: Menu Inferior e Menu Central Figura 35: Falha ao converter dados do servidor Figura 36: Erro - RA ou senha incorreto(s)! Figura 37: Listagem de Disciplinas Apresentando Duplicidade Figura 38: Lista de Disciplinas sem Duplicidades Figura 39: Parte inferior do aplicativo - erro ao tentar detalhar disciplina online... 76

11 LISTA DE TABELAS Tabela 1: Tamanhos de Tela e Densidades Suportados Tabela 2: Descrição dos métodos expostos pelo WebService Tabela 3: Parâmetros de entrada para o método GetListaDisciplinas Tabela 4: Parâmetros de entrada para o método GetDisciplinasDoDia Tabela 5: Parâmetros de entrada para o método GetDisciplinasDetalhada Tabela 6: Teste - Validar RA e Senha Tabela 7: Teste - Analisar Lista de Disciplinas Retornada Tabela 8: Teste - Analisar Disciplinas do Dia Tabela 9: Teste - Abrir detalhamento de disciplinas online Tabela 10: Teste - Abrir detalhamento de disciplinas presenciais Tabela 11: Teste - Efetuar download do arquivo disponível na unidade web Tabela 12: Teste - Consultar Termos de Privacidade Tabela 13: Teste - Efetuar Logout... 78

12 LISTA DE ABREVIATURAS E SIGLAS API ARM GEX HTML HTTP IPC JSON MIT MSMQ NFC OHA PERL REGEX REST RF RIA RIM RNF SOAP TCP UC URL VM W3C WCF WS Application Programming Interface Acorn RISC Machine Graduação Executiva Hyper Text Markup Language Hyper Text Transfer Protocol Inter-Process Communication JavaScript Object Notation Massachussets Institute of Technology Microsoft Message Queuing Near Field Communication Open Handset Alliance Practical Extraction and Report Language Regular Expressions Representational State Transfer Requisito Funcional Rich Internet Applicaton Research in Motion Requisito Não Funcional Simple Object Access Protocol Transmission Control Protocol Use Case (Caso de Uso) Universal Resource Locator Virtual Machine World Wide Web Consortium Windows Communication Foundation WebService

13 SUMÁRIO 1 INTRODUÇÃO OBJETIVO JUSTIFICATIVA ABRANGÊNCIA ESTRUTURA DO TRABALHO TECNOLOGIAS E CONCEITOS ANÁLISE DA UNIDADE WEB Plano de Ensino Plano de Aulas Material de Aulas Atividades Passos para o acesso ao Plano de Aula Conclusão sobre a Unidade Web ANÁLISE DA ÁREA DE SERVIÇOS AO ALUNO Horário de Aula Boletim de Notas e Faltas Consulta de Faltas Mensais Conclusão sobre a Área de Serviços ao Aluno ANDROID Arquitetura Funcionalidades e Conceitos Básicos do Framework Activities AndroidManifest.xml Armazenamento de Dados Histórico de Versões Publicadas Tipos de Telas Suportados Sobre as Aplicações Android A Distribuição da Aplicação e o Android Market PADRÕES E TECNOLOGIAS XPath HTML Agility Pack... 40

14 2.4.3 Web Scraping Windows Communication Foundation (WCF) Representational State Transfer (REST) JavaScript Object Notation (JSON) MODELAGEM DO UAM-DROID IDENTIFICAÇÃO DOS REQUISITOS DO SISTEMA Requisitos Funcionais Requisitos Não Funcionais DIAGRAMA DE CASOS DE USO ARQUITETURA DO SISTEMA Fluxo de Comunicação entre os Módulos Módulo WebService Módulo Aplicativo Android IMPLEMENTAÇÃO E ESTRATÉGIAS DE DESENVOLVIMENTO WEBSERVICE UAM-droid_WebService GetListaDisciplinas GetDisciplinasDoDia GetDisciplinasDetalhada UAM-droid_Worker Criação do método GetListaDisciplinas UAM-droid_Model UAM-droid_Requester MÓDULO ANDROID Módulo: Conexão com o WebService Classe: OpenFile.java Classe: Web.java Módulo: Classes Modelo Classe: Disciplina.java Classe: Arquivo.java Classe: Horario.java Módulo: Interfaces Classe: App.java... 65

15 Classe: LoginForm.java Classe: Hoje.java Classe: DisciplinaDetalhada.java Classe: Privacidade.java Classe: UAMdroid.java Interface e Layout e do Aplicativo Requisitos Mínimos para Execução do Aplicativo TESTES VALIDAR RA E SENHA ANALISAR LISTA DE DISCIPLINAS RETORNADA ANALISAR DISCIPLINAS DO DIA ANALISAR DETALHAMENTO DAS DISCIPLINAS ONLINE ABRIR DETALHAMENTO DAS DISCIPLINAS PRESENCIAIS EFETUAR DOWNLOAD DE ARQUIVO DISPONÍVEL NA UNIDADE WEB CONSULTAR TERMOS DE PRIVACIDADE EFETUAR LOGOUT CONCLUSÕES TRABALHOS FUTUROS REFERÊNCIAS APÊNDICE A DETALHAMENTO DOS CASOS DE USO UC1 CONSULTAR DISCIPLINAS DO DIA UC2 LISTAR DISCIPLINAS UC3 CONSULTAR DISCIPLINA DETALHADA UC4 EFETUAR DOWNLOAD DE ARQUIVO... 85

16 16 1 INTRODUÇÃO A Universidade Anhembi Morumbi, atualmente, possui dois sistemas onde os alunos podem acessar seus dados, a Área de Serviços ao Aluno e a Unidade Web. Na Área de Serviços, o aluno consulta informações referentes à sua matrícula, faltas e notas. Na Unidade Web, os conteúdos são os arquivos disponibilizados pelos professores e pela universidade. Atualmente, o acesso aos dois sistemas da universidade quando o aluno está em suas dependências, pode ser realizado das seguintes formas: Utilizando os laboratórios extra aula Utilizando um celular ou notebook com acesso à internet Com o objetivo de tornar esses sistemas mais acessíveis aos alunos, este trabalho propõe o desenvolvimento do aplicativo UAM-droid, que será capaz de prover os principais dados e conteúdos da Unidade Web e Área de Serviços ao Aluno, sem separar em dois sistemas. O aplicativo funcionará sobre a plataforma Android, que é um sistema operacional para dispositivos móveis, e acessará os dados dos sistemas através de um WebService, que também será criado para facilitar o desenvolvimento do aplicativo para outros sistemas operacionais móveis, como: Symbian OS (celulares Nokia), ios (iphone, ipad e ipod Touch), RIM (celulares BlackBerry) e Windows Phone OBJETIVO O objetivo principal deste trabalho é desenvolver um aplicativo para a plataforma Android capaz de prover os principais dados e conteúdos disponíveis na Unidade Web e Área de Serviços ao Aluno (detalhados na seção Abrangência), ambos da Universidade Anhembi Morumbi. 1.2 JUSTIFICATIVA Nos dias de hoje, a maioria dos estudantes universitários tem algum tipo de trabalho fixo. Por esse motivo, a sua rotina diária torna-se muitas vezes exaustiva e

17 17 corrida, fazendo com que a leitura de conteúdos disponibilizados pelos professores ou pela universidade seja feita apenas momentos antes do horário de aula. Há casos em que o aluno não sabe em qual sala ocorrerá sua aula ou precisa consultar as notas e faltas de uma determinada disciplina. Para ter acesso ao conteúdo disponível na Unidade Web ou na Área de Serviços ao Aluno da Universidade Anhembi Morumbi, momentos antes da aula, o aluno tem apenas três opções: 1. Deslocar-se até um laboratório extra-aula da própria universidade, aguardar até que algum computador esteja disponível, acessar a Unidade Web ou Área de Serviços ao Aluno e ler o conteúdo ou salvá-lo em um pen drive para ser impresso posteriormente; 2. Acessar de dentro da sala de aula a Unidade Web ou Área de Serviços ao Aluno através de um notebook que tenha acesso à internet e ler o conteúdo; 3. Acessar de dentro da sala de aula a Unidade Web ou Área de Serviços ao Aluno através de um aparelho celular ou smartphone e ler o conteúdo. No primeiro caso, o aluno deverá chegar à universidade com bastante antecedência para que haja o tempo necessário de aguardar um computador disponível no laboratório extra-aula, pois normalmente os laboratórios estão lotados. Na segunda hipótese, não é necessário tanto tempo disponível, mas o aluno nem sempre tem um notebook com acesso à internet à sua disposição. Na terceira opção, o acesso ao dispositivo é mais fácil, pois a maioria dos alunos possuem um aparelho celular ou smartphone à sua disposição. O problema desse caso é o custo, pois normalmente o acesso à internet através das redes das operadoras de celular é tarifado, e esse valor é, normalmente, ainda mais caro se o aparelho não possuir um plano de dados. Portanto, o custo acaba sendo elevado se forem consideradas a quantidade de páginas web e autenticações que o aluno deverá fazer para obter uma simples informação ou conteúdo. Diante do que foi exposto, este trabalho propõe o desenvolvimento de um aplicativo móvel capaz de permitir o acesso às principais funcionalidades da Unidade Web ou Área de Serviços ao Aluno da Universidade Anhembi Morumbi através de dispositivos Android, possibilitando um acesso mais facilitado, ou seja, com menos cliques em relação à navegação tradicional, pelo site da instituição.

18 ABRANGÊNCIA O aplicativo proposto neste trabalho será capaz de disponibilizar aos alunos, através de dispositivos Android, com acesso à internet, os seguintes dados disponíveis na Unidade Web e Área de Serviços ao Aluno da Universidade Anhembi Morumbi. Área de Serviços ao Aluno: o Horários de Aula; o Sala de aula de cada disciplina; o Nome do(s) professor(res); o Notas; o Quantidades de Faltas (do semestre e mensal); o Quantidade Máxima de Faltas (do semestre, por disciplina). Unidade Web: o Plano de Ensino; o Plano de Aulas; o Material de Aulas; o Atividades. A seguir são descritos os itens que não serão disponibilizados pelo aplicativo desenvolvido neste trabalho. Em relação à Área de Serviços ao Aluno não será possível: Efetuar quaisquer tipos de matrículas (dependências, adaptações, matérias optativas e outras); Consultar informações financeiras; Consultar ou alterar o cadastro; Solicitar ou consultar requerimentos; Incluir, alterar ou consultar o plano de atividades (acompanhamento de estágio); Acessar quaisquer outras funcionalidades que possam ser disponibilizadas após a conclusão deste projeto. Já na Unidade Web não será possível: Fazer upload de arquivos; Consultar arquivos disponíveis na seção Troca de Arquivos ;

19 19 Responder aos questionários online; Acessar as matérias online; Acessar quaisquer outras páginas que não estejam descritas no capítulo Abrangência. O acesso ao aplicativo será limitado exclusivamente aos alunos da universidade, não podendo ser acessado por quaisquer outros tipos de usuários. Apesar da segurança ser um item fundamental para o desenvolvimento de qualquer aplicativo, este projeto contempla apenas a segurança mínima, visto que este aplicativo não será distribuído em larga escala. O aprimoramento da segurança poderá ser desenvolvido em trabalhos futuros. 1.4 ESTRUTURA DO TRABALHO Além deste capítulo, o trabalho está subdividido em outros quatro capítulos. No capítulo dois, apresenta-se o funcionamento do Android, além de citar as principais características do sistema operacional e um breve histórico do seu crescimento. Ainda neste capítulo, é feita uma análise sobre as principais características e funcionalidades da Unidade Web e Área de Serviços ao Aluno, ambos da Universidade Anhembi Morumbi, além de uma explicação sobre os padrões e tecnologias utilizados para o desenvolvimento. Já no capítulo três, todo o detalhamento da modelagem do aplicativo é apresentado. São detalhados os requisitos funcionais e não funcionais, o diagrama de casos de uso e a arquitetura de funcionamento do aplicativo. No quarto capítulo, toda a implementação e as estratégias de desenvolvimento são explanadas. O quinto capítulo apresenta informações sobre os testes realizados no aplicativo. O sexto e último capítulo, descreve as conclusões e algumas sugestões de trabalhos futuros relacionados ao projeto.

20 20 2 TECNOLOGIAS E CONCEITOS Neste capítulo, serão abordadas as características referentes à plataforma Android e suas principais funcionalidades, o funcionamento da Área de Serviços ao Aluno e da Unidade Web e os padrões e tecnologias utilizados no desenvolvimento do aplicativo UAM-droid. 2.1 ANÁLISE DA UNIDADE WEB A Unidade Web é um espaço web dedicado ao aluno, com o intuito de fornecer todos os dados e materiais de aula das disciplinas que o mesmo está cursando. O sistema utiliza o Blackboard para organizar e disponibilizar aos alunos os dados fornecidos pelos professores e pela universidade. Ao acessar a aba de Disciplinas e Comunidades e selecionar uma matéria, o aluno tem as seguintes funcionalidades (para matérias presenciais): A Figura 1 apresenta a tela de abertura de uma disciplina na Unidade Web. Figura 1: Tela de Abertura da Disciplina. Fonte: (UNIVERSIDADE ANHEMBI MORUMBI, 2011) Avisos: Contém os avisos publicados pelo professor responsável pela disciplina e pela universidade; Professor (a): Apresenta informações sobre o professor responsável pela disciplina; Plano de Ensino: Apresenta o plano de ensino da disciplina;

21 21 Plano de Aulas: Apresenta o cronograma de aulas da disciplina; Material de Aulas: Apresenta arquivos disponibilizados pelo professor da disciplina; Atividades: Apresenta as atividades disponibilizadas para download e atividades para que os alunos façam online; Permite enviar para o professor e a todos os alunos cadastrados na disciplina; Fórum de Discussão: Permite que os alunos criem tópicos e discutam sobre determinados assuntos referentes à disciplina; Biblioteca: Permite que o aluno consulte e reserve itens da biblioteca da universidade; Cadastro de atividades complementares: Permite ao aluno cadastrar suas atividades complementares; Serviços: Apresenta a tela de acesso a Área de Acesso ao Aluno. Nas seções seguintes apresenta-se uma explicação detalhada das funcionalidades mais utilizadas pelos alunos Plano de Ensino Esta funcionalidade da Unidade Web tem como objetivo informar ao aluno sobre o plano de ensino da disciplina, que apresenta o conteúdo programático, critérios de avaliação, recursos didáticos utilizados e bibliografia recomendada Plano de Aulas No plano de aula o aluno tem acesso ao planejamento das aulas com todas as datas e conteúdos abordados. Este conteúdo pode ser disponibilizado diretamente na web ou em arquivo para download Material de Aulas Nesta funcionalidade, os professores inserem materiais que os alunos necessitam para realizar trabalhos individuais ou em grupo, estudar para provas, ou

22 22 simplesmente se preparar para assistir uma aula já sabendo o conteúdo que será abordado na mesma Atividades Em atividades, são disponibilizados pelo professor, enunciados de trabalho, atividades ou quaisquer outros arquivos a critério do professor da disciplina Passos para o acesso ao Plano de Aula Atualmente, para que o aluno tenha acesso aos conteúdos das disciplinas da Unidade Web, ele deve seguir os passos apresentados na Figura 2. Para acessar o conteúdo disponibilizado ao aluno, seja ele qual for, deve-se seguir os passos listados, onde apenas o último passo mudará caso outro conteúdo seja escolhido. Figura 2: Passos para acesso à Unidade Web. Fonte: (Os Autores, 2011)

23 23 1. A página principal do site da Universidade Anhembi Morumbi deve ser acessada, e o botão É nosso aluno? deve ser clicado 2. O aluno é transferido para uma página secundária do site da universidade, onde é possível encontrar outro botão para acesso a Unidade Web. O botão Unidade Web deve ser clicado 3. Neste passo o aluno tem opção de escolher sobre qual semestre ele quer obter informações 4. Na próxima página, é solicitado ao usuário as informações de login e senha para acesso ao conteúdo disponibilizado. Esse login e senha são os mesmos cadastrados na Área de Serviços ao Aluno. O botão Iniciar Sessão deve ser clicado 5. Nesta página, é exibido o menu principal da Unidade Web, em seguida, a aba Disciplinas e Comunidades deve ser clicada 6. Nesta página, o aluno pode escolher entre obter mais informações das matérias que ele cursa e as comunidades da universidade. O aluno deve escolher a disciplina que deseja obter informações 7. Neste passo, supõe-se que o aluno quer se informar sobre o plano de aulas da matéria, logo o aluno deve clicar na pasta Plano de Aulas 8. Neste caso, o Plano de Aulas é apresentado ao aluno Conclusão sobre a Unidade Web Após a análise das funcionalidades da Área de Unidade Web que serão utilizadas para o projeto UAM-droid, é importante ressaltar que o aluno necessita de sete (ou oito) passos para acesso ao conteúdo de uma matéria específica. Isso é baseado em acessos individuais às funções, com início na página principal do site da Universidade Anhembi Morumbi. 2.2 ANÁLISE DA ÁREA DE SERVIÇOS AO ALUNO A Área de Serviços ao Aluno (ou Central de Atendimento) tem como foco oferecer informações sobre a matrícula do aluno. As informações o auxiliam a

24 24 encontrar o local de suas aulas, apresentar notas e faltas, entre outras funcionalidades. São elas: Atualização de cadastro o Endereço eletrônico/ Permite ao aluno alterar ou incluir um endereço eletrônico para contato da universidade o Contatos de emergência: Permite incluir ou alterar contatos para qualquer emergência que venha a acontecer Central de Atendimento o Solicitação de serviços: Permite solicitar requerimentos, como atestados de matrícula ou de frequência, 2ª via para o cartão de acesso, certificados, declarações, diplomas, histórico escolar, plano de ensino, transferências, entre outros o Andamento de Requerimentos: Permite consultar todas as requisições feitas durante sua matrícula na universidade o Requerimentos para interagir: Permite que o aluno interaja com os requerimentos em aberto e que dependam de sua resposta para continuidade Horário de Aula: Permite verificar as disciplinas do aluno, com informações de dias, salas e horários de cada disciplina Financeiro: Exibe as informações sobre as mensalidades do aluno, como boletos que foram pagos, que estão em atraso ou solicitar segunda via de boletos Boletim de notas e faltas: Possibilita, após a seleção de semestre, verificar notas e faltas do semestre selecionado, separados por disciplina Consulta de faltas mensais: Exibe as faltas do aluno separadas por disciplina, mês e semestre Acompanhamento de estágios: Exibe informações sobre o estágio obrigatório que cada aluno tem que cumprir Matrículas em disciplinas de GEX (Graduação Executiva): Permite acompanhar e se matricular em disciplinas que estão relacionadas à graduação executiva da Anhembi Morumbi O acesso a esse serviço é feito através do botão É nosso aluno?, localizado na página principal do site da Universidade Anhembi Morumbi. Esse link redireciona

25 25 para uma página secundária como apresentado na Figura 3. Nessa página existe um botão para acesso ao serviço que fica localizado no centro, próximo a outros serviços que o aluno possa se interessar. Figura 3: Tela de acesso a Central do Aluno. Fonte: (UNIVERSIDADE ANHEMBI MORUMBI, 2011) Horário de Aula Na Figura 4, é apresentado o passo a passo para acesso ao conteúdo disponível ao aluno na funcionalidade de Horário de Aula. Durante o processo é necessária a navegação por várias páginas e o campo login é solicitado somente uma vez. Esta figura descreverá de forma geral como um aluno navegará entre as páginas e funcionalidades do sistema. Ela irá mostrar onde existem as opções de acessos, juntamente com as informações que o site exige que sejam fornecidas, como login e senha. A seguir serão explicados detalhadamente todos os passos necessários para que o aluno consulte o seu horário de aula. 1. A página principal do site da Universidade Anhembi Morumbi deve ser acessada, e o botão É nosso aluno? deve ser clicado 2. O usuário é transferido para uma página secundária do site da universidade, onde é possível encontrar outro botão para acesso a Área de serviço ao Aluno (Central de Atendimento). O botão Central de Atendimento deve ser clicado 3. Na próxima página, é solicitado ao usuário as informações de login e senha para acesso ao conteúdo disponibilizado. Esse login e senha são os mesmos cadastrados na Unidade Web. O botão Entrar deve ser clicado

26 26 4. Na página seguinte, são listadas para o aluno as funcionalidades que estão disponíveis para seu acesso. Dentre elas, está a funcionalidade de Horário de Aula. O link Horário de Aula deve ser clicado 5. Nesta nova página, as disciplinas nas quais o aluno está matriculado são listadas, de forma abreviada, onde é possível saber qual o horário de início e fim da aula, a sala e a unidade em que a aula será lecionada. Porém, para uma visualização geral da disciplina, o link contendo o código e abreviação da disciplina deve ser clicado 6. Em outra página, são disponibilizadas ao aluno todas as informações da disciplina como o nome professor, onde é possível, através de um ícone, enviar para o mesmo. Também é informada a data em que o aluno foi matriculado nessa disciplina e o campus em que a mesma é lecionada. Figura 4: Passos para consulta ao Horário de Aula. Fonte: (Os Autores, 2011)

27 Boletim de Notas e Faltas Na Figura 5, é apresentado o passo a passo para acesso ao conteúdo disponível ao aluno através da funcionalidade de Consulta de Faltas Mensais. Durante todo o processo, é necessária a navegação por várias páginas e o campo login é solicitado por duas vezes. A seguir serão explicados detalhadamente todos os passos necessários para que o aluno consulte o seu boletim de notas e faltas. Figura 5: Passos para acesso ao Boletim de Notas e Faltas. Fonte: (Os Autores, 2011)

28 28 1. A página principal do site da Universidade Anhembi Morumbi deve ser acessada, e o botão É nosso aluno? deve ser clicado 2. O usuário é transferido para uma página secundária do site da universidade, onde é possível encontrar outro botão para acesso a Área de serviço ao Aluno (Central de Atendimento). O botão Central de Atendimento deve ser clicado 3. Na próxima página, é solicitado ao usuário as informações de login e senha para acesso ao conteúdo disponibilizado. Esse login e senha são os mesmos cadastrados na Unidade Web. O botão Entrar deve ser clicado 4. Na página seguinte, são listadas para o aluno as funcionalidades que estão disponíveis para seu acesso. Dentre elas, está a funcionalidade de Boletim de Notas e Faltas. O link Boletim de Notas e Faltas deve ser clicado 5. Na página seguinte, o aluno seleciona qual semestre deseja consultar seu boletim de notas e faltas 6. Em outra página, são disponibilizadas ao aluno todas as informações de Notas e Faltas do semestre selecionado Nesta funcionalidade, são listados, além das informações do curso, informações de notas N1, notas N2, notas finais, faltas finais e a situação de conclusão da matéria (ou seja, se o aluno foi ou não aprovado). Outras informações também são disponibilizadas, como carga horária e campus em que é lecionada a disciplina Consulta de Faltas Mensais Na Figura 6, é apresentado o passo a passo para acesso ao conteúdo disponível ao aluno na funcionalidade de Consulta de Faltas Mensais. Durante todo o processo, é necessária a navegação por várias páginas e o campo login é solicitado por duas vezes. Esta figura apresenta de forma global as navegações necessárias para a conclusão da busca. No entanto, entre o passo seis e sete, não existe mudança de página, apenas uma atualização da mesma.

29 29 Figura 6: Passos necessários para acesso às Faltas Mensais. Fonte: (Os Autores, 2011) A seguir serão explicados detalhadamente todos os passos necessários para que o aluno consulte as suas faltas mensais, por semestre. 1. A página principal do site da Universidade Anhembi Morumbi deve ser acessada, e o botão É nosso aluno? deve ser clicado 2. O usuário é transferido para uma página secundária do site da universidade, onde é possível encontrar outro botão para acesso a Área de serviço ao Aluno (Central de Atendimento). O botão Central de Atendimento deve ser clicado 3. Na próxima página, são solicitadas ao usuário as informações de login e senha para acesso ao conteúdo disponibilizado. Esse login e senha são os mesmos cadastrados na Unidade Web. O botão Entrar deve ser clicado 4. Na página seguinte, são listadas para o aluno as funcionalidades que estão disponíveis para seu acesso. Dentre elas, está a funcionalidade de

30 30 Consulta de Faltas Mensais. O link Consulta de Faltas Mensais deve ser clicado 5. Nesta nova página, são solicitadas novamente as informações de login e senha do usuário para dar continuidade na solicitação do serviço. 6. Na página seguinte, o aluno seleciona qual semestre deseja consultar suas faltas 7. Nesta página, são listadas as faltas mensais do aluno, separadas por disciplina e de acordo com o semestre escolhido no passo anterior Na funcionalidade de Faltas Mensais são listadas para o aluno as faltas mensais por matéria no semestre que foi selecionado no passo seis. É possível saber o nome da disciplina, o código e o total de faltas por semestre Conclusão sobre a Área de Serviços ao Aluno Após a análise das funcionalidades da Área de Serviços ao Aluno (Central de Atendimento On-line) que serão utilizadas para o projeto UAM-droid, é importante ressaltar que o aluno necessita de no mínimo, seis passos para acesso a uma informação específica. Isso é baseado em acessos individuais às funções, com início na página principal do site da Universidade Anhembi Morumbi. Em algumas funcionalidades, como a de Consulta a Faltas Mensais, é necessário um passo a mais, totalizando sete passos para conclusão do acesso à informação. 2.3 ANDROID O Android foi construído com a intenção de permitir aos desenvolvedores criar aplicações móveis que possam tirar o total proveito do que um aparelho portátil possa oferecer. Foi construído para ser verdadeiramente aberto. Por exemplo, uma aplicação pode apelar a qualquer uma das funcionalidades do núcleo do telefone, tais como efetuar chamadas, enviar mensagens de texto ou utilizar a câmera, que permite aos desenvolvedores adaptarem e evoluir cada vez mais estas funcionalidades (PEREIRA e SILVA, 2009). Inicialmente, a empresa responsável pelo seu desenvolvimento foi a Google, mas hoje essa responsabilidade é da Open Handset Alliance (OHA). A Open Handset Alliance (OHA) é a junção de cinquenta empresas de tecnologia, incluindo fabricantes de hardware, operadoras de celular e desenvolvedores de software (MEIER, 2010).

31 31 processos. Atualmente, a Google apenas gerencia o projeto e faz a engenharia dos Arquitetura Segundo Dimarzio (2008), o Android é uma plataforma baseada em Java e na versão 2.6 do kernel Linux, sendo assim uma distribuição Linux. A arquitetura da plataforma Android é composta de cinco camadas, conforme ilustrada na Figura 7. O núcleo ARM (Acorn RISC Machine) Linux é base para todas as outras camadas. Os processadores ARM são conhecidos por altas performances com baixo consumo de energia, requisito fundamental para o Android, já que é um sistema para dispositivos móveis. Figura 7: A Arquitetura do Android. Fonte: (GOOGLE INC., 2011) A camada de biblioteca fornece os códigos de baixo nível. Ela é responsável pelo tráfego seguro (e criptografado) via TCP/IP, suporte para o componente de navegação, codecs de áudio e vídeo, suporte para o banco de dados SQLite, biblioteca C e outras funcionalidades básicas de um sistema Linux.

32 32 Dalvik é o interpretador de bytecodes em tempo de execução, muito semelhante ao interpretador de bytecodes do Java. Com o Dalvik, uma nova cópia do interpretador é ativada para cada aplicativo em execução. Dessa forma, o ambiente fica muito mais confiável e seguro, já que os aplicativos trabalham de forma separada e independente (GOOGLE INC., 2011). O framework de aplicações é a camada responsável pelas Applications Programming Interfaces (API s) do Android. Ela é a responsável pelos códigos de alto nível, como: gerenciamento de janelas, gerenciamento de notificações, provedores de conteúdo, entre outros. A camada de aplicativos é a mais personalizável, já que é nesta camada que o usuário pode instalar e desinstalar aplicativos de acordo com as suas necessidades. O Android já vem com um conjunto de aplicativos que não podem ser desinstalados (Telefone, Mensagens SMS, Calendário, etc.) Funcionalidades e Conceitos Básicos do Framework A plataforma Android possui uma série de conceitos bem específicos que são de conhecimento essencial para o desenvolvimento de um aplicativo Activities Uma activity é um componente do aplicativo que fornece uma tela com a qual os usuários podem interagir para fazer algo como discar um telefone, tirar uma foto, enviar um ou ver um mapa. Cada atividade é iniciada em uma janela. A janela normalmente preenche a tela, mas ela pode ser menor ou flutuar sobre as outras janelas (GOOGLE INC., 2011). Um aplicativo possui normalmente várias activities, mas em quase todos os casos o aplicativo possui a Main Activity, que é a janela aberta por padrão quando o aplicativo inicia. Dentro de uma aplicação Android, existem quatro possíveis funções para cada activity. São elas: Criar: a activitiy é criada e iniciada; Parar: o processo é pausado e colocado na fila; Restaurar: o processo volta a ser executado;

33 33 Destruir: o processo é destruído e não poderá ser retomado futuramente. Quando uma nova janela é aberta dentro do aplicativo, o processo da janela anterior é parado e colocado em uma pilha. O princípio básico dessa pilha é last in, first out, ou seja, quando o usuário apertar o botão voltar, a última janela ativa será a primeira a ser fechada e a janela atual será destruída. O Android disponibiliza várias funções para que o aplicativo manipule as Activity s, são elas: oncreate(): É executado quando activity é criada, ou seja, quando ela é executada pela primeira vez; onrestart(): É executado quando uma activity foi parada e vai voltar a executar; onstart(): É executado antes da activity ser mostrada para o usuário; onresume(): É executado imediatamente após uma activity ser mostrada ao usuário depois de ter sido parada; onpause(): É executado imediatamente após outra activity se tornar ativa no sistema. Esse método é utilizado normalmente para salvar dados não salvos, parar animações e outras contribuições para que o aplicativo não consuma bateria sem necessidade; onstop(): É executado quando uma activity está há muito tempo indisponível para o usuário ou quando outra activity a sobrescreveu; ondestroy(): É executado imediatamente antes de uma activity ser destruída. É a última chamada que a activity receberá AndroidManifest.xml Toda aplicação Android deve ter obrigatoriamente um arquivo chamado AndroidManifest.xml. Esse arquivo armazena informações essenciais para a execução e instalação de qualquer aplicativo. Entre os dados armazenados nesse arquivo estão: O nome do aplicativo; Os componentes do aplicativo (Activity s, serviços, os nomes das classes e todos os outros componentes do aplicativo);

34 34 Determina o processo que hospedará o aplicativo;;especifica as permissões que o aplicativo necessitará para ser executado; Determina a versão mínima da plataforma para que o aplicativo seja instalado; Lista as bibliotecas que o aplicativo requer Armazenamento de Dados A escolha da melhor maneira de armazenar os dados dependerá de fatores como a restrição de acesso aos dados armazenados (público, para usuários e outras aplicações ou restrito) e quanto espaço que será ocupado (GOOGLE INC., 2011). As opções de armazenamento são: Shared Preferences: armazena pares restritos de chave-valor; Internal Storage: armazena dados privados na memória do telefone; External Storage: armazena dados público na memória externa do telefone; SQLite Databases: armazena dados num banco de dados privado. Network Connection: armazena dados em algum servidor web Histórico de Versões Publicadas O Android foi inicialmente distribuído com a versão 1.5, denominada Cupcake. Trata-se de uma versão primária da plataforma, que suportava somente alguns recursos básicos, como: escutar música e fotografar. A parte mais evoluída dessa versão estava relacionada aos aplicativos oferecidos pelo Google, como a Busca na Web e o Youtube. A versão seguinte foi a 1.6, Donut, que basicamente melhorou o que já existia, não houve muita inovação nessa versão. A versão 2.0 foi lançada, mas logo substituída pela 2.1, a Eclair. Essa versão foi a que teve mais repercussão. Trouxe várias inovações como um suporte aprimorado ao Google Maps. Essa versão também foi a primeira a ter suporte à HTML5 e Bluetooth 2.1.

35 35 Logo após a Eclair, o Android 2.2 foi distribuído, a versão chama-se Froyo. Essa versão trouxe poucas inovações grandiosas. A maior parte das modificações ficou mesmo com as melhorias na estabilidade e desempenho. A partir dessa versão, o Android passou a utilizar o motor de Javascript V8, que é utilizado no navegador Google Chrome convencional (desktop), e disponibilizou ferramentas de teste através da USB (para desenvolvedores). A versão seguinte é a 2.3, Gingerbread, que trouxe várias melhorias para a interface do usuário. Essa versão foi marcada por ser a primeira a interpretar Near Field Communication (NFC, uma tecnologia de transmissão de dados que permite pagar ônibus com o celular, em outros países). A partir dessa versão o Android passou a suportar telas maiores (tablets, por exemplo). A versão mais atual é a 3.0, Honeycomb, que é uma versão dedicada aos tablets, não podendo ser instalada em qualquer dispositivo. Segundo dados oficiais apresentados na Figura 8, as versões mais utilizadas da plataforma são as 2.1 (Eclair) e 2.2 (Froyo), que juntas somam uma fatia de 91,1% sobre os dispositivos ativos. Figura 8: Versões da Plataforma. Fonte: (GOOGLE INC., 2011) Tipos de Telas Suportados As versões mais recentes do Android têm suporte para vários tipos de telas/displays. A variação dos tipos suportados pelo sistema operacional varia desde a densidade (pontos por pixel) até a resolução. Os tamanhos das telas são divididos em quatro grupos:

36 36 Small; Normal; Large; Xlarge. Já os níveis de densidade são classificados em: ldpi (low); mdpi (medium); hdpi (high); xhdpi (extra high). A Tabela 1 descreve os tipos de telas suportados de acordo com a densidade e o tamanho da tela. Tabela 1: Tamanhos de Tela e Densidades Suportados. High Extra high Low Density Medium density density density (120), ldpi (160), mdpi (240), hdpi (320), xhdpi Small screen QVGA (240x320) WQVGA400 Normal (240x400) screen WQVGA432 (240x432) Large screen Extra Large screen Fonte: (GOOGLE INC., 2011) HVGA (320x480) WVGA800 (480x800) WVGA854 (480x854) WVGA800 (480x800) WVGA854 (480x854) De acordo com dados oficiais publicados na Figura 9, a maior parte dos usuários ativos, possuem dispositivos equipados telas normal e hdpi, ou seja: WVGA800 e WVGA854.

37 37 Figura 9: Tamanhos de Tela e Densidades. Fonte: (GOOGLE INC., 2011) Sobre as Aplicações Android As aplicações Android são escritas com a linguagem de programação Java. Depois de escritos, todos os códigos e arquivos necessários para o bom funcionamento de uma aplicação são compilados em um arquivo com sufixo.apk. Esse arquivo gerado é utilizado para instalar o aplicativo no Android, já que todas as informações necessárias estão contidas nele. Depois de instalado, cada aplicativo é executado, por padrão, em uma máquina virtual isolada, onde ele não tem acesso aos dados e variáveis de outras aplicações em execução. O sistema operacional, por padrão, atribui um ID de usuário diferente para cada aplicação. Essa identificação não é conhecida pelo aplicativo, ou seja, é utilizado apenas para controle do sistema operacional. Em resumo, o Android é um sistema operacional multiusuário, onde cada aplicação em execução é um usuário diferente, inacessível por outros usuários. No entanto, é possível desenvolver um aplicativo para que compartilhe o mesmo ID de usuário e consequentemente a mesma Virtual Machine (VM). Por exemplo: a aplicação SMS poderia solicitar dados da aplicação Agenda de Contatos, para tornar mais fácil a seleção do destinatário de uma mensagem de texto. Para que isso seja possível, as duas aplicações deverão ocupar o mesmo usuário Android e compartilhar o mesmo ID da VM (GOOGLE INC., 2011).

38 A Distribuição da Aplicação e o Android Market Uma aplicação Android é distribuída através de um arquivo com sufixo.apk, que concentra todos os códigos e recursos necessários para o seu funcionamento e instalação. Uma vez em posse deste arquivo compilado com sufixo.apk, o usuário do Android poderá instalar facilmente a aplicação, apenas executando esse arquivo no seu dispositivo. Caso a opção Permitir Fontes Desconhecidas estiver habilitada no celular, um assistente de instalação será executado e informará todos os recursos que o aplicativo poderá utilizar, caso o usuário concorde, o aplicativo será instalado e estará pronto para utilização. Uma segunda maneira de distribuir o aplicativo é através do Android Market. É um aplicativo desenvolvido pela Google a fim de facilitar a instalação e desinstalação de aplicativos pagos e gratuitos. O Android Market permite que o usuário pesquise, leia um resumo do aplicativo, veja telas e comente quaisquer aplicativos que estejam publicados na sua base de dados. Além da instalação e desinstalação, o Market também gerencia as atualizações disponíveis para cada aplicativo que tenha sido instalado através do Market. O Android Market é normalmente utilizado por desenvolvedores que desejam publicar o seu aplicativo para um número maior de pessoas, facilitando sua distribuição. Para publicar uma aplicação gratuita no Android Market, são necessários apenas três passos (GOOGLE INC., 2011): Criar um perfil de desenvolvedor na Google; Pagar uma taxa de 25 dólares americanos, através da Google Checkout; Aceitar os termos do Android Market Developer Distribution Agreement disponíveis em A publicação de aplicações pagas exige que o desenvolvedor seja licenciado digitalmente, para que possa controlar variáveis como: o tempo de utilização do aplicativo e o estado de licenciamento do aplicativo. Dessa forma, o desenvolvedor poderá proibir ou permitir a utilização do seu aplicativo de acordo com as variáveis fornecidas pela Google.

39 PADRÕES E TECNOLOGIAS Nesta seção são abordados os padrões e tecnologias utilizados para o desenvolvimento do projeto UAM-droid XPath XPath é uma linguagem para localizar informações em um documento XML/XHTML. A linguagem se tornou recomendada pela World Wide Consortium (W3C) em 16 de novembro de 1999 e se tornou referência entre os desenvolvedores que precisavam localizar dados dentro de documentos extensíveis. A Figura 10 apresenta as linguagens que formam o XPath. Figura 10: Linguagens que formam o XPath. Fonte: (W3C, 2011) As linguagens que formam o XPath são (W3C, 2011): XQuery: É uma linguagem de consulta semelhante ao SQL, porém é aplicada a documentos XML; XPointer: É uma linguagem que encontra elementos XML dentro de um documento extensível. Esta linguagem é considerada bem parecida com o XPath, e sua diferença é que a XPointer só permite navegar entre childnodes (nós-filho) utilizando números; XLink: É uma linguagem que permite inserir links dentro de documentos XML. Também foi recomendada pela W3C em 27 de junho de 2001; XSLT: É uma linguagem bem parecida com HTML e permite ao desenvolvedor criar tabelas de acordo com um documento XML.

40 HTML Agility Pack HTML Agility Pack é uma biblioteca open-source escrita na plataforma.net que tem a função de ler e escrever códigos HMTL. Esta biblioteca apresenta métodos para fixação de HTML e navegação dentro de documentos (OBIWAN, 2011). Os desenvolvedores utilizam esta biblioteca quando precisam extrair informações de algum documento HTML que está quebrado ou com erros de sintaxe. Esta biblioteca inclui muitos métodos que ajudam a manipular o HTML em geral, para extrair informações ou para converter o HTML para outra versão. A biblioteca está disponível em (OBIWAN, 2011) Web Scraping Web Scraping, também conhecida como Web Harvesting e Web Crawling, é uma técnica de extração de dados de páginas da web. A técnica foi criada em 1993 por um aluno do Massachusetts Institute of Technology (MIT) chamado Matthew Gray. Nesta época, ele sentiu a necessidade de medir o tamanho da web para criar o primeiro banco de dados de Uniform Resource Locators (URL s), que foi chamado de World Wide Web Wanderer (GRAY, 1995). Matthew Gray criou o Wanderer utilizando uma mistura da linguagem Practical Extraction and Report Language (PERL) e chamadas de Hyper Text Transfer Protocol (HTTP) para extrair as URL s das páginas e inseri-las em seu repositório. A utilização desta técnica permite que o desenvolvedor consiga executar as seguintes ações: Obter conteúdos de documentos HTML; Navegar entre documentos HTML utilizando XPath e Regular Expressions (Regex); Extrair dados específicos de documentos HTML utilizando o reconhecimento de tags HTML. Um exemplo de utilização da técnica de Web Scraping é o aplicativo Consumo, criado pela Nyvra Software, uma empresa brasileira que cria aplicações

41 41 para dispositivos Apple. Este aplicativo permite ao usuário verificar informações relevantes de sua conta telefônica da operadora Vivo diretamente no seu iphone. Para o desenvolvimento deste aplicativo, foi utilizado Web Scraping, pois a Operadora Vivo não disponibiliza uma plataforma de integração para clientes. A Figura 11 apresenta como um usuário da operadora Vivo consegue visualizar as suas informações diretamente no iphone. Figura 11: Informações sobre a conta do usuário diretamente no iphone 4. Fonte: (NYVRA SOFTWARE, 2009) A grande necessidade de um desenvolvedor utilizar a técnica de Web Scraping nos dias de hoje, é a falta de automatização de alguns serviços e também a falta de API s para serviços muito utilizados pela população. Grandes empresas como os Correios, operadoras de celular, universidades e principalmente sites do governo brasileiro, não apresentam nenhuma forma de integração entre o cliente e o serviço, o que leva o desenvolvedor utilizar esta técnica para extrair as informações necessárias e apresentá-las em uma nova interface mais amigável. A Figura 12 apresenta exemplos da implementação da técnica Web Scraping na linguagem C#, assim como a Figura 13 e a Figura 14, que serão explicadas detalhadamente no capítulo 4. Os códigos contidos nas respectivas figuras

42 42 apresentam a utilização de classes do.net framework como: HttpWebRequest, utilizada para enviar requisições; HttpWebResponse, utilizada para receber requisições e StreamReader, utilizada para leitura do stream retornado. Também são apresentadas classes para o controle de documentos extensíveis, como: HTMLDocument, utilizada para ler um um documento HTML (pertence a biblioteca HTML Agility Pack, detalhada anteriormente); XPathNavigator, XPathNodeIterator e XPathExpression, que são utilizadas para navegar dentro de documentos extensíveis. Figura 12: Exemplo da obtenção do HTML da página inicial da Universidade Anhembi Morumbi. Fonte: (Os Autores, 2011) Figura 13: Exemplo da Utilização do HTML Agility Pack e XPath para recuperar as informações necessárias. Fonte: (Os Autores, 2011)

43 43 Figura 14: Conteúdo do site da Anhembi Morumbi obtidos através de Web Scraping. Fonte: (Os Autores, 2011) Já que os motores de busca da internet indexam as páginas com base no HTML gerado, podemos considerar que eles utilizam a técnica de Web Scraping para obter o HTML das páginas, armazenar em seus repositórios e para criar os filtros que os usuários utilizam para encontrar páginas de um determinado assunto a partir de uma determinada palavra-chave Windows Communication Foundation (WCF) Quando iniciou a criação do.net Framework 3.0, um entre quatro dos grandes pilares que havia dentro dele era o Indigo que mais tarde recebeu o nome de Windows Communication Foundation, ou simplesmente WCF. O WCF unificou as várias tecnologias de programação distribuídas na plataforma Microsoft em um único modelo, baseando-se na arquitetura orientada a serviços (SOA) (AECE, 2009) A WCF apresenta uma forma de desenvolvimento que é totalmente desacoplada de regras de negócio e totalmente interoperável, possibilitando uma vasta quantidade de maneiras de se conectar com um serviço. A WCF juntou em sua arquitetura quatro tipos de transporte: HTTP ( Transmission Control Protocol (TCP, net.tcp://), Inter-Process Communication (IPC, net.pipe://) e Microsoft Message Queuing (MSQM, net.msmq://) possibilitando que desenvolvedores unifiquem seus serviços dentro de um projeto WCF. Antes da criação desta plataforma, os desenvolvedores tinham que implementar serviços em arquiteturas diferentes para cada tipo de transporte.

44 44 A WCF utiliza um conceito onde todo serviço exposto assina um contrato, que apresenta todos os métodos que deverão ser expostos. Um contrato é definido por uma Interface e cada serviço é definido por uma classe (LÖWY, 2007). A Figura 15 apresenta exemplos da criação de serviços WCF, assim como a Figura 16. Figura 15: Implementação de um Contrato - Interface. Fonte: (Os Autores, 2011) Figura 16: Implementação de um serviço que assina um contrato. Fonte: (Os Autores, 2011) A arquitetura da plataforma WCF é dividida em três partes (NET CONNECTED FRAMEWORK TEAM, 2010), como mostra a Figura 17.

45 45 Figura 17: Arquitetura do WCF. Fonte: (NET CONNECTED FRAMEWORK TEAM, 2010) Modelo de programação: A camada de modelo de programação define quais tipos de serviços serão expostos ao cliente, os modelos são: Simple Object Access Protocol (SOAP) Services, Web HTTP Services, Data Services, Rich Internet Applicaton (RIA) Services e Workflow Services; Modelo de serviço: A camada de modelo de serviço define toda a estrutura que os serviços definidos deverão ser orientados, os itens deste modelo são: Data Contract, Service Contract e Service Behavior; Modelo de canal: A camada de modelo de canal define quais formatos de entrada/saída deverão ser fornecidos, quais maneiras de transporte de dados serão utilizadas e quais protocolos serão respeitados para a execução dos serviços. As configurações dos serviços WCF são feitas através de Endpoints, que são conjuntos de três propriedades (AECE, 2009): Address: Define o endereço onde o serviço está publicado; Binding: Define como o cliente irá se conectar com o serviço. Para cada tipo de transporte existe um tipo de Binding, onde é definido tempo de limite de chamada, tamanho de pacotes para envio, tamanho de pacotes para recebimento, tamanho de buffer, entre outros; Contract: Define quais métodos serão expostos no serviço, informando quais são os parâmetros de entrada e os parâmetros de saída.

46 Representational State Transfer (REST) Segundo Roy Thomas Fielding (2000), o REST é uma arquitetura criada por Roy Fielding em O objetivo principal é facilitar as requisições entre cliente e servidor, tornando-as mais intuitivas e simples. Com esse modelo, todos os dados que devem ser passados do cliente para o servidor (serviço) são transportados através da URL deste serviço, ou seja, o REST estabelece o HTTP como principal meio de transporte de parâmetros ou informações para um serviço disponibilizado na internet. Além de simplificar a forma de transmissão de parâmetros, o REST também propõe a organização dos métodos disponibilizados, já que estes serão acessados através de HTTP. Veja o exemplo de uma requisição à um serviço utilizando a arquitetura REST para a seguinte URL listar_disciplinas/usuario/senha/. Na URL mostrada, o cliente está acessando um serviço disponibilizado no endereço e está informando dois parâmetros: usuário e senha. Ao desenvolver um serviço com a arquitetura REST, pode-se solicitar ao consumidor do serviço inúmeros parâmetros, já que estes poderão ser enviados ao servidor da mesma maneira (através da URL), separados por barras JavaScript Object Notation (JSON) JavaScript Object Notation (JSON) é um formato de troca de dados de peso leve. É fácil para os seres humanos a ler e escrever. É fácil para máquinas para analisar e gerar (Introducing JSON, 2011). O JSON foi criado por Douglas Crockford para servir de intercâmbio leve de dados computacionais. O JSON tem sua utilização bastante difundida principalmente por causa da facilidade que os desenvolvedores encontram em criar analisadores JSON. Apesar de ser bastante utilizado com a linguagem JavaScript (presente na grande maioria dos navegadores, atualmente), a sua implementação não está associada exclusivamente à essa linguagem.

47 47 O media-type oficial do JSON é application/json e sua extensão é.json. Veja um exemplo de um objeto JSON na Figura 18: Figura 18: Exemplo de Objeto JSON Fonte: (Os Autores, 2011)

48 48 3 MODELAGEM DO UAM-droid Para o desenvolvimento do aplicativo proposto neste trabalho, inicialmente, a partir da análise realizada das funcionalidades disponíveis na Unidade Web e Serviços ao Aluno foram elencados os requisitos funcionais e não funcionais que o aplicativo deveria contemplar. Em seguida, com o intuito de detalhar os requisitos funcionais elencados foi elaborado o diagrama de caso de uso e o detalhamento dos mesmos. Além disso, apresenta-se a arquitetura do sistema, que, foi dividido em dois módulos. O módulo WebService e o módulo Aplicativo Android. Este capítulo apresenta os resultados da modelagem do aplicativo UAM-droid. 3.1 IDENTIFICAÇÃO DOS REQUISITOS DO SISTEMA A identificação dos requisitos do sistema foi feita para contemplar todos os itens listados na abrangência do projeto. A descrição dos requisitos está organizada em requisitos funcionais e requisitos não funcionais Requisitos Funcionais RF01 - O aplicativo deve disponibilizar ao aluno os horários, sala de cada aula e o(s) nome(s) do(s) professor(es) de cada disciplina. RF02 - O aplicativo deve disponibilizar ao aluno as notas e as faltas mensais disponíveis na Área de Serviços ao Aluno. RF03 - O aplicativo deve disponibilizar ao aluno a quantidade máxima de faltas permitidas, para cada disciplina. RF04 - O aplicativo deve disponibilizar ao aluno o conteúdo da seção Plano de Ensino, Plano de Aulas, Material de Aulas e Atividades da Unidade Web. RF05 - O aplicativo deverá armazenar o RA e senha do aluno na memória interna do dispositivo móvel (de forma segura) durante a utilização do aplicativo, evitando que esses dados sejam solicitados ao aluno mais de uma vez.

49 Requisitos Não Funcionais RNF01 - O aplicativo deve funcionar em dispositivos Android, com versão igual ou superior à 2.2. RNF02 - As cores predominantes deverão ser verde, preto e branco, seguindo o padrão de identidade visual da Universidade Anhembi Morumbi. RNF03 - O aplicativo deve fornecer a informação que o aluno busca em menos passos em relação ao sistema atual. RNF04 - O RA e a senha do aluno deverão ser solicitados somente na primeira tela de acesso durante toda a utilização. RNF05 - O armazenamento do RA e senha deverá ser feito de maneira segura, impedindo que os dados armazenados sejam acessados por outro agente que não o aplicativo. 3.2 DIAGRAMA DE CASOS DE USO A Figura 19 apresenta o Diagrama de casos de uso que foi elaborado a partir do levantamento dos requisitos funcionais identificados. Figura 19: Diagrama de Casos de Uso. Fonte: (Os Autores, 2011)

50 50 Como pode ser visto na Figura 19 caso de uso UC1 tem por objetivo permitir que o aluno consulte as principais informações das disciplinas que serão ministradas no dia em que a consulta está sendo executada. Para cada disciplina são exibidos: nome da disciplina, nome do professor, sala, horário, total de faltas e máximo de faltas permitidas. O UC1 inclui o caso de uso UC2, permitindo assim ao aluno visualizar todas as disciplinas que o aluno está cursando no presente semestre. O caso de uso UC3 é acessado a partir do UC1, e tem por objetivo apresentar informações adicionais como: notas, faltas mensais e lista de arquivos disponíveis para download, dentre eles, o Plano de Ensino, Plano de Aulas e Material de Aulas. Este caso de uso também inclui o caso de uso UC2. O caso de uso UC4 é acessado a partir do UC3, para que o aluno consiga efetuar o download de um arquivo previamente disponibilizado pelo professor. Todos os casos de uso partem do princípio que o ator esteja devidamente autenticado no aplicativo através de seu RA e Senha. As especificações detalhadas dos casos de uso encontram-se no Apêndice A. 3.3 ARQUITETURA DO SISTEMA Após o levantamento e modelagem dos requisitos do aplicativo UAM-droid, foi elaborada a arquitetura do sistema, dividida em dois módulos. O módulo WebService e o módulo Aplicativo Android. Esta seção apresenta a arquitetura do WebService e a arquitetura do aplicativo Android, fornecendo um detalhamento do fluxo de comunicação entre estes dois módulos Fluxo de Comunicação entre os Módulos O fluxo de comunicação entre os módulos Aplicativo Android e WebService é representado na Figura 20. O passo 1 indica uma interação humana entre o aluno e um dispositivo móvel com o sistema operacional Android, no qual ele está iniciando o processo de interação com o sistema UAM-droid.

51 51 Figura 20: Fluxo de Comunicação Entre Os Módulos Fonte: (Os Autores, 2011) O passo 2 indica que o aplicativo UAM-droid está sendo executado e iniciando a conexão com o módulo WebService para disponibilizar as informações necessárias ao aluno. O passo 3 apresenta os dados enviados ao módulo WebService, através de uma chamada. O passo 4 indica que o módulo WebService está processando a requisição recebida através do módulo Android e encaminha requisições para os servidores da Unidade Web e para os servidores da Área de Serviços ao Aluno da Universidade Anhembi Morumbi. As informações enviadas aos servidores são semelhantes às informações utilizadas ao acessar ambos sistemas através de um navegador. O passo 5a apresenta o servidor da Unidade Web da Universidade Anhembi Morumbi processando as informações recebidas através do módulo WebService. O passo 5b apresenta o servidor da Área de Serviços ao Aluno da Universidade Anhembi Morumbi processando as informações recebidas através do módulo WebService. O passo 6 apresenta as informações recebidas pelos servidores da Unidade Web e Área de Serviços ao Aluno, ambos da Universidade Anhembi Morumbi. O passo 7 indica que o módulo WebService está processando as informações recebidas e está aplicando a técnica de Web Scraping para extrair as informações necessárias. Após a técnica ser aplicada, as informações extraídas são encapsuladas em classes conhecidas pelo módulo Android.

52 52 O passo 8 indica a resposta do módulo WebService ao módulo Android, através de uma chamada HTTP retornando os dados em formato JSON. O passo 9 apresenta o módulo Android processando as informações recebidas pelo módulo WebService. O passo 10 indica que as informações estão na tela do dispositivo e prontas para serem consumidas pelo aluno que as requisitou no inicio do fluxo. Todos os detalhes sobre os dois módulos são apresentados no capítulo Módulo WebService O módulo WebService foi desenvolvido com a plataforma WCF da Microsoft e é responsável pelo fornecimento das informações para o módulo Aplicativo Android e pela comunicação com os servidores da Universidade Anhembi Morumbi, onde a Área de Serviços ao Aluno e Unidade Web se encontram. A arquitetura do módulo WebService consiste em quatro camadas, sendo UAM-droid_Model, UAM-Droid_Requester, UAM-Droid_WebService e UAM- Droid_Worker. A camada UAM-droid_WebService é a porta de entrada do serviço, onde os métodos estão expostos para que o aplicativo Android se integre a ele e utilize estes métodos. A camada UAM-droid_Worker é responsável por montar as requisições necessárias para que cada método apresentado na camada UAM-droid_WebService tenha o seu retorno apropriado. É nesta camada em que o Web Scraping é aplicado, para efetuar a extração das informações necessárias das páginas HTML da Área de Serviços ao Aluno e da Unidade Web, assim podendo transformá-las em dados legíveis para serem retornados pelo WebService e serem consumidos pelo aplicativo Android. A camada UAM-droid_Model é responsável pelas classes disponíveis em todo o módulo WebService e pelo módulo Android, assim mantendo transparência entre a comunicação dos módulos, pois ambos enxergam as mesmas classes. A camada UAM-droid_Requester é responsável pelas chamadas aos servidores da Universidade Anhembi Morumbi enviando os dados montados pela camada UAM-droid_Worker.

53 53 Todos os detalhes da implementação do módulo webservice serão apresentados no capítulo Módulo Aplicativo Android Este módulo é responsável por fazer a interação entre o WebService e o aluno. Todas as informações necessárias são requisitadas ao WebService que retorna os dados estritamente necessários para o processamento da tela do aplicativo. Conceitualmente o aplicativo pode ser dividido em três camadas, são elas: Conexão com o WebService, Classes Modelo e Interfaces. A camada Conexão WebService, como o nome já diz, tem como principal responsabilidade realizar a conexão com a Universidade Anhembi Morumbi, através do WebService. Além dessa função, essa camada faz a conversão dos dados retornados pelo WebService (em JSON) para as Classes Modelo. Já a camada de Classes Modelo é formada pelas classes que são utilizadas como modelo de dados das disciplinas e armazenam todos os dados obtidos de cada disciplina. Finalmente, a camada de Interfaces é composta pelas classes que controlam as telas do aplicativo. Cada classe é responsável por uma tela, podendo manipular os possíveis eventos de cada interface (exemplo: cliques).

54 54 4 IMPLEMENTAÇÃO E ESTRATÉGIAS DE DESENVOLVIMENTO Este capítulo detalha todas as estratégias de implementação, utilizadas no desenvolvimento dos módulos WebService e Aplicativo Android. Neste capítulo é possível encontrar especificações mais detalhadas sobre as classes e o fluxo de comunicação entre elas. 4.1 WEBSERVICE A implementação do módulo WebService foi feita com a linguagem C# e com um projeto do tipo WCF da plataforma.net, utilizando a divisão de quatro camadas, descritas no capítulo 3. A escolha da divisão por camadas foi feita visando a manutenção do código, estrutura e facilidade para desenvolver UAM-droid_WebService A primeira e única camada exposta do módulo WebService é a UAMdroid_WebService, que apresenta todos os métodos e parâmetros disponíveis para consumo de um cliente, neste caso o módulo Android. A camada UAMdroid_WebService é do tipo Windows Communication Foundation Service Project e possui três arquivos fundamentais para o seu funcionamento, apresentados na Figura 21; Figura 21: Representação dos arquivos do módulo UAM-droid_WebService Fonte: (Os Autores, 2011)

55 55 O arquivo IUAMDroidService.cs atua como uma interface, onde são registrados todos os métodos e parâmetros que serão expostos por quem o implementar. O arquivo UAMDroidService.svc implementa o contrato IUAMDroidService e passa a expor todos os métodos e parâmetros contidos na interface. Este arquivo é o responsável pela execução de cada método, é nele que os algoritmos estão contidos. O arquivo web.config atua como um configurador do serviço exposto, é responsável por determinar qual é o endereço do serviço, timeout, tipo de protocolo, entre outros. são: Os métodos e parâmetros expostos pela camada UAM-droid_WebService Tabela 2: Descrição dos métodos expostos pelo WebService Método Parâmetros de Entrada Parâmetros de Saida GetDisciplinaDetalhada String codigo String token DisciplinaDetalhada GetDisciplinasDoDia String token DisciplinasDoDia GetListaDisciplinas String token ListaDisciplinas Fonte: (Os Autores,2011) GetListaDisciplinas Este método é responsável por listar as disciplinas em que o aluno está matriculado, retornando em forma de dicionário, o código identificador e o nome de cada disciplina. É utilizado para listar as disciplinas na tela do aplicativo Android. Tabela 3: Parâmetros de entrada para o método GetListaDisciplinas Nome Tipo Observação Token Fonte: (Os Autores, 2011) String O valor deste parâmetro é composto pela fórmula: base64(ra base64(senha))

56 GetDisciplinasDoDia Este método é responsável por retornar as informações das disciplinas que serão ministradas ao aluno no dia em que a consulta está sendo realizada, limitando-se a retornar somente as informações contidas na classe DisciplinasDoDia (detalhada na Figura 27). Tabela 4: Parâmetros de entrada para o método GetDisciplinasDoDia Nome Tipo Observação Token Fonte: (Os Autores, 2011) String O valor deste parâmetro é compost pela fórmula: base64(ra base64(senha)) GetDisciplinasDetalhada Este método é responsável por retornar as informações de uma disciplina específica, de acordo com o código passado como parâmetro. As informações retornadas são limitadas a classe DisciplinaDetalhada. Tabela 5: Parâmetros de entrada para o método GetDisciplinasDetalhada Nome Tipo Observação Token Código Fonte: (Os Autores, 2011) String String O valor deste parâmetro é compost pela fórmula: base64(ra base64(senha)) Código identificador da disciplina UAM-droid_Worker A camada UAM-droid_Worker é a responsável por todo o algoritmo de criação dos requests aos servidores da Universidade Anhembi Morumbi e principalmente pela aplicação da técnica Web Scraping para extrair os dados necessários. Os algoritmos criados são simulações de acesso a cada funcionalidade da Unidade

57 57 Web e Área de Serviços ao Aluno da Universidade Anhembi Morumbi, e com os resultados eles são manipulados para atender o retorno de cada método. Na próxima seção será explicado detalhadamente como o método GetListaDisciplinas foi desenvolvido, para entendimento da técnica Web Scraping Criação do método GetListaDisciplinas Antes de desenvolver o algoritmo, foi necessário acessar a Área de Serviços ao Aluno da Universidade Anhembi Morumbi com o R.A e senha de um dos componentes do grupo, neste caso com o R.A e senha do integrante Guilherme Ferreira, de acordo com a Figura 22. Figura 22: Tela de Login da Área de Serviços ao Aluno Fonte: (UNIVERSIDADE ANHEMBI MORUMBI, 2011) Após a autenticação ser feita, o aluno é redirecionado para a tela apresentada na Figura 23, onde contém os links de ações disponíveis ao aluno autenticado. Figura 23: Tela com os menus oferecidos ao aluno Fonte: (UNIVERSIDADE ANHEMBI MORUMBI, 2011)

58 58 A tela escolhida para extrair a lista e código de cada disciplina em que o aluno está matriculado é a Consulta de Faltas Mensais, pois nesta tela contém a lista de todas as disciplinas e seus códigos, de acordo com a Figura 24. Figura 24: Lista com o nome e código de cada disciplina em que o aluno está matriculado Fonte: (UNIVERSIDADE ANHEMBI MORUMBI, 2011) Com a lista de disciplinas em que o aluno está matriculado, foi possível obter o HTML gerado e aplicar a técnica Web Scraping. O trecho de código da Figura 25 apresenta a técnica sendo executada para extrair as informações. A técnica utiliza expressões em forma de XPath para extrair as informações, no caso da Figura 25 para extrair o nome de cada disciplina foi utilizada a expressão /html/body/table/tr/td[@align='left'], que retorna todas as disciplinas e cada uma delas é adicionada em uma lista. Em seguida foi utilizada a expressão XPath /html/body/table/tr/td[@align='right'][1] para extrair os códigos de cada disciplina (CRT) e cada um deles é adicionado em uma lista que guarda estes códigos. Para finalizar, ambas listas são percorridas e é criada uma estrutura de dados do tipo Dictionary<string, string>, que armazena chave e valor, no caso, código da disciplina e nome. Com os dados formatados, o retorno é feito para o cliente (módulo Android), que recebe os dados no formato de JSON, apresentados na Figura 26

59 59 Figura 25: Trecho de código que representa a técnica Web Scraping no Método GetListaDeDisciplinas Fonte: (Os Autores, 2011) Figura 26: Retorno do método GetListaDeDisciplinas em formato JSON Fonte: (Os Autores, 2011)

60 UAM-droid_Model Figura 27: Diagrama de classes que representa a camada UAM-droid_Model Fonte: (Os Autores, 2011) A Figura 27 apresenta o Diagrama de Classes. Esta camada é a responsável pela modelagem do WebService, onde todas as classes de modelo foram criadas. As classes DisciplinaDetalhada, DisciplinasDoDia e ListaDisciplinas são expostas como retorno dos métodos disponibilizados pelo serviço. As classes Disciplina, DiaLocalHora, QtdeFaltaMes compõem uma disciplina. As classes Request e Response são responsáveis apenas por enviar trafegar requests e responses entre o WebService e os servidores da Universidade Anhembi Morumbi. As classes Common e Login foram criadas para complementar informações e auxiliar outras classes.

61 UAM-droid_Requester Esta camada é responsável apenas por enviar os requests aos servidores da Universidade Anhembi Morumbi, ela possui a classe WebConnection.cs que é uma abstração da classe HttpWebRequest da plataforma.net e foi desenvolvida de uma maneira genérica, onde ela simplesmente envia requisições com os parâmetros passados a ela, nenhuma inteligência é implementada nesta camada. 4.2 MÓDULO ANDROID O módulo Android foi desenvolvido em JAVA, que, é a linguagem padrão para a criação de aplicativos para este sistema. A implementação deste aplicativo é composta de várias classes, algumas são classes modelo, e outras são apenas heranças de classes nativas do Android. Conceitualmente, todas essas classes estão separadas em três módulos: módulo de conexão com WebService, módulo de Classes Modelo e módulo de Interfaces. Neste capítulo, cada módulo e suas respectivas classes são detalhados Módulo: Conexão com o WebService Neste módulo estão presentes as classes que têm por objetivo conectar o aplicativo ao WebService desenvolvido, invocar os métodos e converter os resultados obtidos em JSON para classes modelo, permitindo, assim, que os dados retornados do WebService possam ser utilizados no aplicativo. O módulo é composto de duas classes: OpenFile.java e Web.java Classe: OpenFile.java Essa classe é responsável por acessar o endereço do arquivo disponível, previamente recebido através do WebService, e disponibilizar este arquivo para o aluno.

62 62 Todos os downloads efetuados pelo aluno são armazenados no cartão de memória de seu celular, separados por pastas com o nome da disciplina a qual o arquivo pertence. Ao acessar o endereço do arquivo, através das classes HTTP do Android, é possível obter o tamanho do arquivo antes mesmo de efetuar o download dele. Portanto, neste momento, a classe valida se o arquivo que o aluno está solicitando o download já está no cartão de memória. Essa validação é feita através da comparação do tamanho do arquivo, em bytes, e seu nome. Caso o arquivo não exista, o seu download é efetuado enquanto uma barra de progresso é exibida ao aluno. Depois de obtido, através do download ou do cartão de memória, o arquivo é aberto para visualização no smartphone do aluno, através do aplicativo padrão para a extensão do arquivo Classe: Web.java Essa classe é responsável por invocar o WebService, converter o JSON obtido em string e convertê-la em classes modelo. Os métodos públicos dessa classe apenas reproduzem os métodos disponibilizados pelo WebService: getdisciplinas, getdisciplinashoje e getdisciplinadetalhada. O método getdisciplinas recebe como parâmetro o token do aluno, conectase ao WebService, através do método connect, e transforma a lista de disciplinas obtida em um ArrayList de classes Disciplina.java, que será detalhada posteriormente. O método getdisciplinashoje, recebe como parâmetro o token do aluno, conecta-se ao WebService através do método connect e complementa a lista de disciplinas, obtidas previamente e armazenadas no ArrayList, com os dados retornados neste método. O método getdisciplinadetalhada funciona de forma semelhante ao método anterior, a única diferença é que ele recebe como parâmetro, além do token, o código da disciplina que deve ser detalhada.

63 63 Como explicado anteriormente, depois de obtida, nenhuma disciplina é duplicada, dentro do aplicativo, ou seja, existe um ArrayList de classes Disciplina.java, onde cada posição corresponde à uma disciplina. Ao receber as informações de determinada disciplina, através do WebService, estes dados são apenas complementados à classe Disciplina.java já existente no ArrayList. A busca da disciplina no ArrayList é feita através de seu código Módulo: Classes Modelo Figura 28: Diagrama de Classes do Módulo Android Fonte: (Os Autores, 2011)

64 64 Este módulo é responsável por fornecer ao sistema, classes para que cada disciplina possa ser armazenada. O módulo é composto de três classes: Disciplina.java, Arquivo.java e Horario.java. As classes modelo são representados no diagrama da Figura Classe: Disciplina.java Essa classe armazena os dados de cada uma das disciplinas em seus atributos. Como visto no diagrama da Figura 28 existem dois atributos que são ArrayLists, um da classe Arquivo.java e outro da classe Horario.java, já que cada disciplina pode ter vários arquivos e vários horários e dias diferentes por semana. Além dos atributos, que são privados, essa classe possui métodos públicos para obtenção e gravação de cada um dos seus atributos, além do método gethorariodia, que recebe como parâmetro o dia da semana e retorna os horários da disciplina para este dia Classe: Arquivo.java Essa classe armazena em seus atributos os dados dos arquivos disponíveis em cada uma das disciplinas Classe: Horario.java Essa classe armazena em seus atributos o horário, dia e sala em que a disciplina é lecionada Módulo: Interfaces Este módulo é responsável por gerenciar todas as telas que compõem a interface do sistema. Todas as classes são heranças da classe Activity do Android. O módulo de interfaces é o maior, sendo composto por seis classes: App.java, DisciplinaDetalhada.java, Hoje.java, LoginForm.java, Privacidade.java e UAMdroid.java.

65 Classe: App.java É responsável por fornecer métodos e atributos de uso comum, a todas as outras classes do aplicativo. É na classe App.java que fica armazenado o ArrayList de classes Disciplina.java que serve como base para geração das interfaces ao aluno, além de gerar e fornecer o token do aluno, RA, senha, entre outros Classe: LoginForm.java Essa classe mostra ao aluno um formulário de login contendo o logotipo da Universidade Anhembi Morumbi, e os espaços para que o aluno digite seu RA e senha, além de um botão para que os dados sejam validados. A Figura 29 ilustra a tela gerada. Figura 29: Formulário de Login do Aplicativo Android Fonte: (Os Autores, 2011) Para que ocorra a validação do RA e senha do aluno, o aplicativo invoca o método getdisciplinas no WebService. Caso a lista de disciplinas do aluno seja obtida com êxito, o aplicativo gera uma sessão de login do aluno e não solicitará mais o RA e senha do aluno durante toda a utilização daquela sessão. Os dados de acesso (RA e senha) do aluno não são armazenados em quaisquer outros lugares que não sejam variáveis da memória interna, no próprio smartphone do aluno.

66 66 A durabilidade de uma sessão nos aplicativos Android não tem tempo determinado. A sessão permanecerá ativa enquanto o aluno estiver utilizando o aplicativo. Caso o aplicativo fique inativo, o Android irá limpar a sessão logo que precisar de espaço na memória interna do smartphone. Nessa tela, ao pressionar o botão voltar do smartphone, nenhuma ação é tomada, portanto não haverá nenhuma alteração na interface do sistema. Já ao pressionar a tela menu do smatphone, o menu inferior do aplicativo é aberto, disponibilizando ao aluno apenas consultar os termos de privacidade do sistema, através da classe Privacidade.java Classe: Hoje.java Depois de efetuado o login com sucesso, a sessão é criada e o aluno é redirecionado para esta classe, onde o método getdisciplinashoje é invocada através da módulo de conexão com WebService. Depois de todos os dados estarem atualizados, essa interface é montada e mostrada ao aluno através do método montatela, que, é privado desta classe. Figura 30: Tela de Disciplinas do Dia no Aplicativo Android Fonte: (Os Autores, 2011)

67 67 Essa interface possui basicamente duas áreas: disciplinas do dia e demais disciplinas, como mostra o exemplo na Figura 30. A área de disciplinas do dia mostra ao aluno algumas informações básicas das disciplinas que são lecionadas naquele dia. São exibidas para cada disciplina: nome, nome do professor, horários de início e fim, sala de aula, número total de faltas e número máximo de faltas permitido. Na área de demais disciplinas, o aluno pode encontrar uma lista com os nomes de todas as outras disciplinas que não foram listadas na área de disciplinas do dia. Ao selecionar qualquer disciplina, do dia ou não, o aluno visualizará o detalhamento daquela disciplina, através da classe DisciplinaDetalhada.java. Nessa tela, ao pressionar o botão voltar do smartphone, nenhuma ação é tomada, portanto não haverá nenhuma alteração na interface do sistema. Já ao pressionar a tela menu do smatphone, o menu inferior do aplicativo é aberto, disponibilizando ao aluno consultar os termos de privacidade do sistema, a lista de disciplinas, e efetuar logout. Ao consultar os termos de privacidade, a interface gerada pela classe Privacidade.java é invocada e apresentada ao aluno. Na consulta de lista de disciplinas, um menu flutuante é exibido no centro do aplicativo, contendo uma lista com os nomes de cada uma das disciplinas. Ao selecionar uma das disciplinas, essa é detalhada e mostrada ao aluno através da interface gerada pela classe DisciplinaDetalhada.java. Ao selecionar logout, a sessão é encerrada e a interface gerada pela classe LoginForm.java é apresentada ao aluno Classe: DisciplinaDetalhada.java Quando o aluno seleciona alguma disciplina na interface apresentada pela classe Hoje.java, essa classe é invocada e recebe como parâmetro o código da disciplina que o aluno selecionou. Ao receber esse código, a classe DisciplinaDetalhada.java valida se o código é válido, no ArrayList de disciplinas presente na classe App.java. Caso o código seja

68 68 válido, o detalhamento da disciplina é invocado ao WebService através do módulo de conexão com o WebService, e este código é passado como parâmetro. Após receber os dados do WebService, a classe monta a tela de detalhamento da disciplina e apresenta ao aluno. Essa tela apresenta os seguintes dados: nome da disciplina, nome do professor, horários de aula (horário de início, horário final, dia da semana e sala de aula), total de faltas, total de faltas permitidas, faltas mensais, notas (N1, N2 e Final) e lista de arquivos disponíveis na Unidade Web. A Figura 31 ilustra a tela gerada. Figura 31: Tela da Disciplina Detalhada no Aplicativo Android Fonte: (Os Autores, 2011) Ao selecionar qualquer arquivo disponível na lista de arquivos da Unidade Web, a classe OpenFile.java é invocada, passando como parâmetro a classe Arquivo.java correspondente ao arquivo selecionado. Nessa tela ao pressionar o botão voltar do smartphone, o aluno volta à interface apresentada pela classe Hoje.java. Ao pressionar o botão menu do smartphone, o mesmo menu inferior apresentado na tela de disciplinas do dia é aberto.

69 Classe: Privacidade.java Essa classe é responsável por apresentar ao aluno uma interface flutuante contendo os termos de privacidade do aplicativo, como mostra a Figura 32. Ao pressionar o botão voltar do smartphone, essa interface é fechada. Ao pressionar o botão menu, do smartphone, nenhuma ação é tomada e a interface permanece inalterada. Figura 32: Tela de Termos de Privacidade no Aplicativo Android Fonte: (Os Autores, 2011) Classe: UAMdroid.java Essa classe tem como única responsabilidade inicializar e reinicializar a execução do aplicativo, quando o aplicativo é aberto pelo aluno, ou quando o aluno volta a utilizar o aplicativo depois de ter alternado para outra aplicação de seu smartphone. Essa classe não apresenta interface alguma para o aluno, apenas invoca a classe correta de acordo com o estado da sessão. Caso haja alguma sessão ainda ativa no smartphone, o aplicativo invoca a classe Hoje.java, caso contrário, a classe invocada é a LoginForm.java.

70 Interface e Layout do Aplicativo O aplicativo está dividido em quatro telas, basicamente: formulário de login, tela de disciplinas do dia, tela de disciplinas detalhadas e termos de privacidade. No aplicativo Android desenvolvido, o aluno consegue obter qualquer informação da disciplina (dentro da abrangência do projeto), com apenas três passos, como ilustra a Figura 33: Figura 33: Passos para Obter Informações no Aplicativo Android Fonte: (Os Autores, 2011) Figura 34: Menu Inferior e Menu Central Fonte: (Os Autores, 2011)