Licenciatura em Novas Tecnologias da Comunicação. ocumentação ROTÓTIPO ALFA PROJETO IAMEG1

Transcrição

1 Licenciatura em Novas Tecnologias da Comunicação ocumentação ROTÓTIPO ALFA PROJETO IAMEG1 26 Abril de 2016

2 EMBROS iogo Mendes enrique Almeida oão Jesus iago Ribeiro Professores Professora de Perfil Maria João Antunes Professores Apoio Helder Caixinha Pedro Amado roponente rofessora Helena Caspurro 2

3 Índice do documento Mapa de Navegação 5 Base de Dados 6 Fluxogramas 8 Fluxograma do registo na plataforma 8 Fluxograma do login com Facebook 10 Fluxograma do Calendário 11 Fluxograma de partilha de conteúdos 12 Arquitetura da plataforma 14 3

4 Indice de figuras Figura 2 - Base de Dados 7 Figura 3 - Fluxograma de registo na plataforma 9 Figura 4 - Fluxograma do login com Facebook 10 Figura 5 - Fluxograma do Calendário 11 Figura 6 - Fluxograma de partilha de conteúdos 13 Figura 7 - Arquitetura da plataforma 14 4

5 Mapa de Navegação (VER ANEXO 1) A plataforma contempla três níveis de privilégios, correspondentes aos três tipos de utilizadores. O utilizador não registado consegue visualizar todos os conteúdos da plataforma mas não consegue interagir ou partilhar conteúdo. O utilizador registado consegue visualizar, interagir e partilhar conteúdo na plataforma, não conseguindo criar conteúdo novo. O admin tem o mesmo tipo de acesso que o utilizador registado, mas usufrui adicionalmente de outras permissões, pois tem acesso à página de administração. Um utilizador de tipo admin tem acesso a duas secções de gestão, de conteúdos e de utilizadores, e a uma secção de criação de conteúdo. É nesta tab que o admin terá à sua disposição as páginas de criação de eventos, notícias e pensamentos. É também permitida a edição dos mesmo. Como foi referido anteriormente, a secção de gestão está dividida em duas tabs, a de gestão de conteúdo onde poderá aceitar/rejeitar e apagar imagens, vídeos e comentários relacionados com notícias e eventos. Na tab de gestão social o admin consegue então ativar ou desativar utilizadores bem como editar todas as respectivas informações. Os admins serão os sócios do Instituto e aqueles a quem lhes é atribuído esse estatuto. Toda esta secção de backoffice será apenas trabalhada no módulo versão beta do trabalho de Projeto, que terá início no mês de maio de

6 Base de Dados A base de dados do projeto, Figura 2, é constituída por onze tabelas e três tabelas de relação (fruto de relações muitos para muitos). Destacam-se as tabelas que surgem das relações muitos para muitos, na tabela utilizador_has_eventos guardam-se os id s dos utilizadores que irão atender aos eventos (e os respetivos id s). Na tabela eventos_has_imagens guardam-se os id s das imagens e os id s dos eventos a que pertencem, o mesmo acontece na tabela eventos_has_videos. É ainda pertinente discutir a tabela eventos pois irá armazenar dados provenientes da API do Google Maps (latitude e longitude). Para além de armazenar todas as informações relativas aos eventos, como por exemplo, título, descrição, horário, custo, dinamizador e morada, irá ainda guardar as duas coordenadas da posição relativa à morada que o utilizador registado & admin irá inserir na página de registo do evento. Essas coordenadas irão ser utilizadas novamente na página do respetivo evento permitindo mostrar a sua posição num mapa. A tabela utilizadores também é fundamental pois armazena toda a informação relativa aos utilizadores, no entanto o elemento fulcral desta explicação são os campos criados para que a API do Facebook possa guardar os dados dos utilizadores na base de dados. No campo Fuid é guardado o Facebook id do utilizador, no campo Fname é guardado o nome de Facebook do utilizador e no campo F é guardado o que está associado ao Facebook do utilizador. 6

7 Figura 2 - Base de Dados 7

8 Fluxogramas Como foi discutido e acordado tanto nas aulas de perfil como nas aulas de apoio da Unidade Curricular de Projeto, foram elaborados fluxogramas para as funcionalidades mais importantes neste momento do desenvolvimento do projeto. Com este fator em consideração foram realizados fluxogramas para o funcionamento do calendário, para o login com Facebook e para a partilha de conteúdos. Fluxograma do registo na plataforma Tendo em consideração a Figura 3, se o utilizador estiver logado acaba a sua interação com esta funcionalidade. Caso não esteja é verificado se se encontra registado ou não, sendo a resposta positiva, o utilizador fará login. Introduz o e a password. De seguida o utilizador ser selecionado, através de uma query SELECT, que irá corresponder o introduzido ao existente na base de dados. De seguida converte a password introduzia para um hash e compara esse hash com o gravado na base de dados, através de password_verify. Se ambos os valores forem iguais o login é bem sucedido. Por outro lado, se o utilizador não se encontrar registado, terá de realizar esse processo, preenchendo os campos do formulário corretamente (nome, , contacto, país, data de nascimento, password e confirmação de password), caso introduza incorretamente ficará neste processo até o preencher de uma maneira correta. Depois de os dados serem aceites serão guardados na base de dados, através de uma query INSERT, que irá inserir os dados nos respetivos campos na tabela utilizadores, sendo enviado um de confirmação para o endereço de correio eletrónico que o utilizador introduziu no processo de registo. No conteúdo desse para além dos dados de login, estará presente um link de confirmação, após o clique nesse link, se os dados corresponderem, irá existir uma atualização do campo ativo na tabela utilizadores para 1, e ativará a conta. Caso contrário o utilizador tem de se registar novamente. 8

9 Figura 3 - Fluxograma de registo na plataforma 9

10 Fluxograma do login com Facebook Analisando a Figura 4, se o utilizador já estiver registado, irá fazer login com o id do utilizador e acabará a interação com esta funcionalidade. Caso não esteja, tem duas opções, ou se regista pelo processo normal, falado no ponto anterior, ou utiliza o Facebook para completar esse processo. Se optar pelo Facebook, terá que numa primeira instância logar-se no Facebook. Posteriormente uma query SELECT irá selecionar todos as tokens de acesso e irá ser feita uma verificação da existência de uma token. Caso exista passará por um processo de validação, que, se for aceite, será guardado numa variável de sessão. Caso não exista uma token será pedido autorização ao utilizador para que esta seja inserida na BD, apenas será inserida depois de garantida essa autorização. Se todas as verificações forem aceites os dados do Facebook irão ser introduzidos na base de dados, através de uma query INSERT nos respetivos campos da tabela utilizadores. Este processo é concluído com o login na plataforma. Figura 4 - Fluxograma do login com Facebook 10

11 Fluxograma do Calendário Tendo em conta a Figura 5, o utilizador irá ver o calendário, ao clicar num dia de um determinado mês e ano, sendo-lhe mostrado(s) o(s) evento(s) correspondentes a esse dia, através de uma query SELECT de todos os eventos que tenham o campo data_evento igual à data selecionada. Caso existam eventos é lhe mostrado o nome, o horário e o custo do respetivo evento. Se o utilizador clicar sobre o evento entrará na página correspondente acabando a sua interação com a funcionalidade calendário. Figura 5 - Fluxograma do Calendário 11

12 Fluxograma de partilha de conteúdos Na fase de partilha de conteúdos, Figura 6, há dois tipos de utilizadores que interagem indiretamente entre si, o utilizador registado e o utilizador registado e admin. O utilizador não registado ao entrar na página de um evento pode partilhar conteúdo, imagens, vídeos ou comentar. Caso o utilizador partilhe, esse conteúdo irá ser guardado na BD através de uma query INSERT do conteúdo nos respetivos campos das tabelas correspondentes. Depois deste processo o utilizador registado e admin, na sua condição de admin, visualizará uma listagem de pedidos pendentes, através de uma query SELECT da tabela do respetivo conteúdo que tenha o campo ativo a 0. Depois de escolher esse conteúdo terá duas opções, permitir ou não. Caso permita, através de uma query UPDATE, o campo ativo irá passar para 1 e passará a ser mostrado na página do evento, caso contrário esse conteúdo será removido da base de dados. 12

13 Figura 6 - Fluxograma de partilha de conteúdos 13

14 Arquitetura da plataforma A plataforma está sustentada numa base de dados, explicada no ponto 2 (Figura 2), que realiza trocas de informação (nos dois sentidos) com o servidor devido à utilização da linguagem PHP. A ligação entre a base de dados e o php é feita através de SQL, é também devido a este canal de comunicação que permite comunicar, indiretamente, a base de dados ao servidor. A plataforma utiliza três API s diferentes, a do Google Maps, a do Facebook e a do Google+. Potenciado pelas interações dos utilizadores, a comunicação das API s funciona nos dois sentidos com o browser e o servidor (armazenando dados). Existe ainda um simple mail transfer protocol (SMTP) que comunica diretamente com o servidor e que permite o serviço de , neste caso a confirmação do registo por correio eletrónico. Figura 7 - Arquitetura da plataforma 14

15 15