PLATAFORMA DE VOLUNTARIADO: DESENVOLVIMENTO DE UMA PLATAFORMA PARA MONITORIZAR E GERIR OS PROJETOS DE VOLUNTARIADO DO GAT

(1)

PLATAFORMA DE VOLUNTARIADO:

DESENVOLVIMENTO DE UMA PLATAFORMA PARA MONITORIZAR E GERIR OS PROJETOS DE VOLUNTARIADO DO GAT

Filipe Daniel Gomes Ribeiro

Orientador

Prof. Dra. Patrícia Isabel Sousa Trindade Silva Leite

Coorientador

Prof. Dra. Isabel Maria de Freitas Soares Ferreira

Projeto apresentado

ao Instituto Politécnico do Cávado e do Ave

para obtenção do Grau de Mestre em Engenharia Informática

junho, 2020

(2)

(3)

(4)

(5)

PLATAFORMA DE VOLUNTARIADO:

DESENVOLVIMENTO DE UMA PLATAFORMA PARA MONITORIZAR E GERIR OS PROJETOS DE VOLUNTARIADO DO GAT

Filipe Daniel Gomes Ribeiro

Orientador

Prof. Dra. Patrícia Isabel Sousa Trindade Silva Leite

Coorientador

Prof. Dra. Isabel Maria de Freitas Soares Ferreira

Projeto apresentado

ao Instituto Politécnico do Cávado e do Ave

para obtenção do Grau de Mestre em Engenharia Informática

junho, 2020

(6)

DECLARAÇÃO

Nome: Filipe Daniel Gomes Ribeiro

Endereço eletrónico: a15061@alunos.ipca.pt

Título do Projeto: Plataforma de Voluntariado: Desenvolvimento de uma plataforma para monitorizar e gerir os projetos de voluntariado do GAT

Orientador: Prof. Dra. Patrícia Isabel Sousa Trindade Silva Leite Coorientador: Prof. Dra. Isabel Maria de Freitas Soares Ferreira Ano de conclusão: junho, 2020

Designação do Curso de Mestrado: Mestrado em Engenharia Informática

Nos exemplares das Dissertações /Projetos/ Relatórios de Estágio de mestrado ou de outros trabalhos entregues para prestação de Provas Públicas, e dos quais é obrigatoriamente enviado exemplares para depósito legal, deve constar uma das seguintes declarações:

☒ É AUTORIZADA A REPRODUÇÃO INTEGRAL DESTA DISSERTAÇÃO/TRABALHO APENAS PARA EFEITOS DE INVESTIGAÇÃO, MEDIANTE DECLARAÇÃO ESCRITA DO INTERESSADO, QUE A TAL SE COMPROMETE;

☐ É AUTORIZADA A REPRODUÇÃO PARCIAL DESTA DISSERTAÇÃO/TRABALHO (indicar, caso tal seja necessário, nº máximo de páginas, ilustrações, gráficos, etc.), APENAS PARA EFEITOS DE INVESTIGAÇÃO, MEDIANTE DECLARAÇÃO ESCRITA DO INTERESSADO, QUE A TAL SE COMPROMETE;

☐ DE ACORDO COM A LEGISLAÇÃO EM VIGOR, NÃO É PERMITIDA A REPRODUÇÃO DE QUALQUER PARTE DESTA DISSERTAÇÃO/TRABALHO

Instituto Politécnico do Cávado e do Ave,26/06/2020

Assinatura: ________________________________________________

(7)

PLATAFORMA DE VOLUNTARIADO: DESENVOLVIMENTO DE UMA PLATAFORMA PARA MONITORIZAR E GERIR OS PROJETOS DE VOLUNTARIADO DO GAT

RESUMO

O projeto GAT (Gestão de Atividades Turísticas) surge no âmbito da unidade curricular de Gestão das Instituições Sociais e Culturais, lecionada ao 3º ano da Licenciatura em Gestão de Atividades Turísticas, nas quais os alunos desenvolvem vários projetos de inovação e voluntariado em múltiplas instituições.

Em cada um dos eventos é feito um registo utilizado a rede social Facebook contento fotografias e informação geral do evento, que neste momento, atendendo à dimensão dos projetos desenvolvidos, assim como à quantidade dos mesmos, deparam-se com um problema de acesso e gestão da informação.

O objetivo passa criar uma plataforma web composta por um website de acesso público disponibilizando informação estática como informação geral sobre o projeto GAT, informação dinâmica como os projetos e eventos bem como as equipas e organizações associadas ao projeto. Será constituído também por uma dashboard de apoio onde é possível alterar toda a informação dinâmica do website.

O presente documento descreve todo esse processo, implementando uma metodologia Design Science Research, apresentada por Ken Peffers.

Com este projeto, os responsáveis do GAT centralizam todo o conteúdo num sistema web, aumentando a visibilidade dos seus projetos e eventos, sendo possível também enaltecer o trabalho meritório das diferentes instituições que acolhem os projetos.

Palavras-chave: Voluntariado, Plataforma, Gestão de Informação, Desenvolvimento de Software.

(8)

(9)

PLATAFORMA DE VOLUNTARIADO: DESENVOLVIMENTO DE UMA PLATAFORMA PARA MONITORIZAR E GERIR OS PROJETOS DE VOLUNTARIADO DO GAT

ABSTRACT

The GAT (Gestão de Actividades Turísticas) project comes under the curricular unit of "Management of Social and Cultural Institutions", present in the 3rd year of the Degree in Management of Tourism Activities, in which students have developed, several projects of social innovation and volunteering in multiple institutions.

In each of the events is made a report using the social network Facebook, with photos and general information of the event, which, given the size of the projects developed, as well as the amount of them, they are faced with a problem of access and management. of the information.

The objective with this project is to create a web platform with a public website presenting static information as general information about the GAT project, dynamic information such as projects and events as well as project teams and organizations. It will also be created a support dashboard where it is possible change all the dynamic information of the website.

This document describes and present the whole process, implementing for that a methodology Design Science Research, by Ken Peffers.

With this project, the managers of GAT centralize all content in a single web system, increasing the visibility of their projects and events, and can also praise the meritorious work of the different organizations that host the projects.

Keywords: Volunteering, Platform, Information Management, Software Development

(10)

(11)

AGRADECIMENTOS

É importante destacar que a realização deste projeto de mestrado contou com importantes apoios que sem os mesmos este projeto não se teria tornado realidade.

Em primeiro lugar queria agradecer as professoras Dra. Patrícia Leite e Dra. Isabel Ferreira não só por toda a orientação, apoio e disponibilidade, mas por todas as opiniões e críticas, pautadas sempre por um elevado nível científico que, passo a passo contribuíram para a realização deste projeto.

Em segundo lugar, a todos os docentes da quinta edição do Mestrado em Engenharia Informática com que tive oportunidade de partilhar opiniões e conhecimento ao longo deste percurso académico. Uma palavra especial para o professor Dr. Luís Ferreira pela disponibilidade, acompanhamento e pela excelência enquanto diretor do mestrado referido.

Continuando no contexto académico, quero agradecer a todos os meus colegas que tive a oportunidade de conhecer, por todo o apoio, não só neste projeto, mas em todo o percurso académico que trilhamos juntos.

Dirijo também um agradecimento a toda a minha família, por todo apoio e paciência ao longo não só deste projeto, mas no percurso de todo o mestrado. Um agradecimento especial à minha esposa Paula Sampaio, pelo apoio incondicional, compreensão e paciência durante todo este percurso.

Por fim, e de forma sucinta, o meu profundo agradecimento a todas as pessoas que direta ou indiretamente contribuíram para a concretização deste projeto.

(12)

(13)

LISTA DE ABREVIATURAS E/OU SIGLAS

DSRM - Design Science Research Methodology GAT - Gestão de Atividades Turísticas

IPCA - Instituto Politécnico do Cávado e do Ave IPSS - Instituição Particular de Solidariedade Social

ONGD - Organização Não-Governamental para o Desenvolvimento

(14)

(15)

ÍNDICE

RESUMO ... I ABSTRACT ... III AGRADECIMENTOS ... V LISTA DE ABREVIATURAS E/OU SIGLAS ... VII ÍNDICE ... IX ÍNDICE DE FIGURAS ... XI ÍNDICE DE TABELAS ... XIII

INTRODUÇÃO ... 1

1. REVISÃO DE LITERATURA ... 5

2. METODOLOGIA DE INVESTIGAÇÃO ... 9

3. ESPECIFICAÇÃO DOS REQUISITOS... 13

3.1 REQUISITOS FUNCIONAIS ... 14

3.2 REQUISITOS NÃO FUNCIONAIS ... 18

4. DESENHO E DESENVOLVIMENTO... 23

4.1 MODELAÇÃO DO SISTEMA ... 23

4.1.1 DIAGRAMA DE CLASSES ...23

4.1.2 DIAGRAMA DE CASOS DE USOS ...24

4.1.3 DIAGRAMA DE ACTIVIDADES ...27

4.1.4 DIAGRAMA DE SEQUÊNCIA ...33

4.2 ANÁLISE DA TECNOLOGIA ... 39

4.2.1 MODELO DE DADOS ...39

4.2.2 SERVERSIDE...40

4.2.3 CLIENTSIDE ...40

4.3 MOCKUP E DESENVOLVIMENTO DA SOLUÇÃO ... 41

4.3.1 DASHBOARD ...41

4.3.2 WEBSITE ...42

4.3.3 BASE DE DADOS E API ...44

CONCLUSÕES ... 45

REFERÊNCIAS BIBLIOGRÁFICAS ... 47

OUTRAS REFERÊNCIAS ... 51

ANEXOS ... 53

(16)

(17)

ÍNDICE DE FIGURAS

Figura 1 - Web Database Applications with PHP & MySQL (Williams & Lane,

2009) ... 5

Figura 2 - Processo DSRM (Peffers et al., 2007) ... 11

Figura 3 - Modelo de domínio da solução ... 14

Figura 4 - Diagrama de classes do sistema ... 24

Figura 5 - Diagrama de Casos de uso global do sistema ... 25

Figura 6 - Diagrama de Casos de Uso: Gerir Utilizadores ... 26

Figura 7 - Diagrama de Casos de Uso: Gerir Projetos ... 26

Figura 8 - Diagrama de Casos de Uso: Gerir Equipas ... 27

Figura 9 - Diagrama de Atividades: Consultar Website ... 28

Figura 10 - Diagrama de Atividades: Dashboard ... 29

Figura 11 - Diagrama de Atividade: Utilizadores ... 30

Figura 12 - Diagrama de Atividade: Projetos ... 31

Figura 13 - Diagrama de Atividade: Organizações ... 32

Figura 14 - Diagrama de Atividade: Equipas ... 33

Figura 15 - Diagrama de Sequência: Consultar Website ... 34

Figura 16 Diagrama de Sequência: Submeter formulário ... 34

Figura 17 - Diagrama de Sequência: Adicionar Utilizador ... 35

Figura 18 - Diagrama de Sequência: Criar Projeto ... 36

Figura 19 - Diagrama de Sequência - Criar Evento ... 36

Figura 20 - Diagrama de Sequência: Criar Equipa ... 37

Figura 21 - Diagrama de Sequência: Criar Turma ... 38

Figura 22 - Diagrama de Sequência: Criar Organização ... 38

Figura 23 - Mockup da Dashboard: Listagem dos projetos ... 42

Figura 24 - Mockup do website: Página Principal ... 43

(18)

(19)

ÍNDICE DE TABELAS

Tabela 1 - Especificação RF001 ... 15

Tabela 19 - Especificação RNF01... 19

(20)

(21)

INTRODUÇÃO

Enquadramento do Projeto

O voluntariado faz parte de um conjunto de comportamentos de ajuda; consiste em uma qualquer atividade em que, livremente, se disponibiliza tempo para beneficiar outra pessoa, grupo ou causa (Wilson, 2000).

A observação, e a ideia de ajudar os outros fazem parte da vida há milhares de anos, de acordo com o psicólogo Carol Ryff, que ao fazer a revisão de documentos de inúmeros filósofos ao longo da história, concluiu que as relações uns com os outros são "uma característica central de uma vida positiva" (Ryff & Singer, 2008).

Analisando alguns dados estatísticos, de acordo com o artigo “Volunteering In Cross- National Perspective: Initial Comparisons” (Anheier & Salamon, 1999, p58), à data do mesmo, em média 32.1% da população da Europa fazia trabalho de voluntariado, e num outro estudo “Individual and Social Factors in Volunteering Participation Rates in Europe” (Gil-Lacruz, Marcuello, & Saz-Gil, 2017) apresenta que, à data da elaboração do mesmo, em Portugal 11% da população analisada fazia trabalho de voluntariado, com uma percentagem muito inferior à Holanda que com 45% era o país que apresentava a taxa mais elevada.

A motivação para o voluntariado tem sido objeto de inúmeros estudos (Musick &

Wilson, 2007). A sua participação está relacionada com a cultura, religião ou até mesmo com contextos sociais, que conseguem fornecer oportunidades, expectativas e exigências para a atividade do voluntariado. Estes contextos são especialmente centrais no caso da participação voluntária entre os estudantes (Grönlund et al., 2011), sendo considerado por diversos governos como essencial para perpetuar uma sociedade civil (Smith et al., 2010).

A nível pessoal existem vários benefícios para quem pratica voluntariado (Hall, Lasby, Ayer, & Gibbons, 2009). De acordo com o estudo “Motivations and Benefits of Student Volunteering: Comparing Regular, Occasional, and Non-Volunteers in Five Countries” (Smith et al., 2010), o principal motivo para a prática de voluntariado é “A importância de ajudar os outros (90.2%)” seguido de “Trabalhar por uma causa considerada importante (87.8%)”. Segundo o mesmo estudo, é-nos apresentado como principais benefícios:

- “Oportunidade de aprender coisas novas (85.9%)”;

- “Angariar skills de liderança (83.8%)”.

De destacar em terceiro lugar “Satisfação pessoal com 83.2%” o que está diretamente em consonância com a afirmação, já apresentada, do psicólogo Carol Ryff.

(22)

Num contexto académico a prática de voluntariado pode melhorar o desenvolvimento académico dos alunos, quer no desenvolvimento de habilidades pessoais quer no senso de responsabilidade civil, além de estar associados também à escolha da atividade profissional e à empregabilidade dos mesmos (Astin & Sax, 1998).

É neste contexto que se enquadra o projeto GAT Solidário, o projeto de estudo para a implementação do sistema aqui apresentado.

O projeto GAT Solidário surge no âmbito da unidade curricular de Gestão das Instituições Sociais e Culturais, lecionada ao 3º ano da Licenciatura em Gestão de Atividades Turísticas, em que, desde 2011, são desenvolvidos pelos alunos, vários projetos de inovação social e voluntariado em diversas instituições sem fins lucrativos da região de influência do IPCA.

Com o objetivo de promover a divulgação dos projetos realizados, não só pelos alunos, mas também do trabalho desenvolvido pelas respetivas instituições que acolhem os alunos, foi criada uma página no Facebook: GAT Solidário¹.

Mais recentemente, a partir de 2016, no âmbito da unidade curricular de Fundamentos de Gestão, lecionadas ao 1º ano de várias Licenciaturas da Escola Superior de Gestão, pelas Professoras Paula Loureiro, Teresa Dieguez e Isabel Ferreira, outros projetos de empreendedorismo social começaram a ser desenvolvidos de forma colaborativa entre as várias turmas. Por forma a promover a divulgação e a partilha das experiências dos alunos, as docentes criaram uma outra página Facebook:

Empreendedorismo, Voluntariado e Inovação Social no IPCA². Motivação

O projeto GAT Solidário está no ativo e efetua diferentes eventos desde 2011. Em cada uma das atividades é feito um registo contendo fotografias e uma descrição do evento bem como a informação de quem participou no mesmo, nas páginas da rede social Facebook já apresentadas.

Neste momento, atendendo à dimensão dos projetos desenvolvidos, assim como à quantidade dos mesmos, deparam-se com um problema de acesso e gestão da informação associadas aos vários projetos. Atendendo que o objetivo é promover a divulgação dos projetos desenvolvidos pelos alunos, assim como o trabalho meritório desenvolvido pelas instituições, continuar com a utilização do Facebook como instrumento de divulgação

1 https://www.facebook.com/gatsolidario/

2 https://www.facebook.com/Empreendedorismo-Voluntariado-e-Inovacao-Social- no-IPCA-1840885182814673

(23)

não parece o mais adequado, fazendo com que seja difícil gerir e aceder rapidamente a informação associada aos eventos já desenvolvidos.

Objetivos

Tendo em conta a motivação, o desafio passa por criar uma plataforma digital na forma de um website para aglomerar toda a temática dos projetos de voluntariado e inovação social desenvolvidos.

Conseguir aceder aos projetos e respetivos eventos, identificar as instituições que acolhem os mesmos e conseguir promover o seu trabalho, divulgar as diferentes equipas que estiveram presentes nos eventos em cada ano letivo são, entre outros, aspetos que se pretende concretizar.

É essencial que toda a informação referente aos projetos e eventos, as equipas e respetivas turmas, ou mesmo as organizações, seja feito de forma dinâmica, existindo, para isso, a necessidade de criar uma dashboard onde seja possível fazer toda a gestão pretendida.

Toda a informação e funcionalidades implementadas foram identificadas e analisadas num processo de levantamento de requisito com as diferentes entidades envolvidas no projeto GAT Solidário.

Procura-se, assim, dar resposta a um problema concreto e realmente sentido numa comunidade: uma comunidade, de docentes e alunos, que desenvolve projetos de empreendedorismo, voluntariado e inovação social no IPCA, como instrumento ativo de ensino e aprendizagem dos conteúdos associados a várias unidades curriculares lecionadas.

(24)

(25)

1. REVISÃO DE LITERATURA

Perante a problemática apresentada, estando esta relacionada com a gestão e visualização da informação, mais propriamente a gestão e visualização de informação na web, é essencial conhecer e dominar alguns conceitos.

Fazendo uma retrospetiva, a internet (ou world wide web) foi originalmente pensada para uma utilização simples, apenas com texto, seguindo uma arquitetura cliente – servidor. Um modelo simples com um suporte para visualização de pequenos websites, com problemas de escalabilidade, e normalmente não suportando muito tráfego (Offutt Jeff, 2002).

As aplicações web começaram a tomar uma proporção maior, a tirar melhor partido do hardware implementado diferentes tecnologias (Offutt Jeff, 2002) e com o passar do tempo toda a arquitetura acabou por mudar e se adaptar às necessidades.

Uma aplicação moderna normalmente segue um modelo N-tier, normalmente composto por três camadas (Offutt Jeff, 2002), como apresentado na Figura 1.

Figura 1 - Web Database Applications with PHP & MySQL (Williams & Lane, 2009)

Partindo da camada inferior, ou camada de dados, esta é composta por uma base de dados e por um sistema gestor de base de dados (SGBD), sendo esta camada o suporte de toda a aplicação (Williams & Lane, 2009).

Como forma de armazenar todo o conteúdo podemos seguir duas abordagens para a modelação da base de dados. Podemos optar por um modelo relacional, um modelo apresentado por Edgar Frank Codd no artigo “Relational Database: A Practical Foundation for Productivity”, afirmando que este oferece melhorias drásticas na

(26)

produtividade, tanto para o utilizador final quanto para os programadores (Codd, 1989).

Este modelo fornece um elevado nível de relacionamentos entre as diferentes entidades (Astrahan et al., 1976) presentes na arquitetura, além de garantir um independência dos dados e uma estruturação simples dos mesmos (Codd, 1989). As grandes vantagens deste modelo passam por simplificar tanto a tarefa de desenvolver as aplicações como a forma como os dados são manipulados, reduzindo o esforço que normalmente é dedicado para a manutenção das aplicações (Codd, 1989). Este modelo também é conhecido como modelo de dados SQL, por usar esta linguagem para efetuar todas as operações.

Por outro lado, podemos optar por um modelo não relacional, também conhecidas como base de dados NoSQL, que ao contrário da anterior segue uma abordagem em que todos os dados são armazenados de forma não estrutural, não existindo obrigatoriamente relações entre os mesmos. O artigo “Survey on NoSQL Database” (Han Jing, E Haihong, Le Guan, & Du Jian, 2011), apresenta a velocidade de leitura e de escrita, o suporte para grande volume de dados, a fácil escalabilidade e o baixo custo como principais vantagens na utilização de bases de dados NoSQL, no entanto existem vários desafios, como sobrecarga, complexidade, confiabilidade e consistência além de ser uma tecnologia mais recente (Leavitt, 2010) comparativamente à anterior.

É essencial entender os requisitos do sistema, para então escolher a tecnologia que melhor se adequa ao modelo de dados que será implementado. Este é o primeiro passo para um correto desenvolvimento de toda a aplicação (Williams & Lane, 2009).

De seguida, na estrutura da aplicação está a camada lógica. Esta é responsável por fazer a comunicação entre a camada de dados com a camada de apresentação (Williams

& Lane, 2009). Esta camada é também responsável por executar todas as validações necessárias, bem como controlar o fluxo de toda a aplicação, como o controlo de acesso (Adamkó Attila, 2019). Esta camada é normalmente configurada num servidor (Williams

& Lane, 2009) e pode ser implementada utilizando diferentes tecnologias, chamadas serverside, como PHP, Ruby, Phyton, Node.Js entre outras. Foi realizado uma comparação de algumas das principais tecnologias de forma a escolher a que mais de adequa ao que se pretende implementar.

Por último, está presente a camada de apresentação, normalmente composta por um website acessível através de um browser (Williams & Lane, 2009) no lado do cliente, onde é apresentado todo o conteúdo e é feita toda a interação com o servidor.

De uma forma sucinta, o artigo “Quality Attributes of Web Software Applications”

(Offutt Jeff, 2002), apresenta alguns critérios para a qualidade de aplicações web, entre outros:

- Confiabilidade - Usabilidade

(27)

- Segurança - Escalabilidade - Manutenção

Cada um dos itens apresentados anteriormente foi tido em consideração aquando da implementação de todo o sistema, não só na escolha das tecnologias, mas também no seu desenvolvimento.

Além de analisar toda a estrutura de uma aplicação web, é importante analisar um outro projeto de voluntariado, sendo este uma referência para a equipa do GAT Solidário.

Estamos a falar do projeto “Filhos do Coração”, projeto que surgiu em 2007 com uma reportagem do canal de televisão TVI com o nome de “Infância Traficada” e tem como visão a denúncia da escravatura infantil, resgatar e reabilitar crianças vítimas deste flagelo. Foi fundado pela jornalista Alexandra Borges, que começou por resgatar três crianças a quem pagava a Educação do seu próprio bolso. O nome “Filhos do Coração”

surgiu, após o lançamento de um livro com o mesmo nome com a parceria do futebolista Luís Figo, com o objetivo de angariar fundos para a associação. Em 2009 o Ministério do Trabalho e da Segurança Social e o Ministério dos Negócios Estrangeiros reconheceram a Associação como uma IPSS e ONGD respetivamente (Filhos do Coração, 2016).

Até ao momento a associação, em conjunto com a organização Americana “Touch a Life Kids”, já resgatou um total de 93 crianças e 86 estão à sua responsabilidade num centro de acolhimento em Kumassi, no Gana (Filhos do Coração, 2016).

Ao analisar o website do projeto³, podemos notar a organização de todo o conteúdo e visualizar em detalhe informações sobre o projeto. Na página principal, à data atual, que se encontra dividida em três partes, são-nos mostrados todos os projetos, algumas formas de contribuir para o projeto em geral, quais os leilões que estão ativos ou a possibilidade de se tornar parceiro do projeto. Por último é apresentado o conjunto dos projetos e campanhas que estão a decorrer à data da consulta.

Sendo este um projeto de referência, é interessante analisar o website para perceber como está estruturado e que informação é apresentada.

3 https://www.filhosdocoracao.org

(28)

(29)

2. METODOLOGIA DE INVESTIGAÇÃO

A revisão de literatura permitiu caracterizar não só a problemática do presente projeto, mas também toda a sua arquitetura aplicacional, que apoia a construção e implementação da solução pretendida, que vá ao encontro dos objetivos definidos.

Tendo por base a problemática (um problema com relevância prática), assim como a rede de conceitos definido aquando da revisão de literatura (gestão da informação, arquitetura de um sistema web), por forma a garantir rigor ao trabalho em curso, define- se, nesta secção, a metodologia de investigação mais adequada face aos objetivos inerentes ao presente projeto.

Tendo presente que o objetivo do projeto é desenhar um produto ou artefacto que pretenda resolver um problema real, na área do desenvolvimento de software, que ainda não exista (Romme A., 2003), foi adotada uma metodologia de Design Science, aplicável a engenharia como ciências da computação (Pacheco Lacerda, Dresch, Proença, Valle, &

Júnior, 2013). Uma metodologia que está presente na Engenharia de Software e Sistemas de Informação por vários anos, quer no desenvolvimento de novas linguagens de programação, novos algoritmos, entre outras (Iivari, 2007).

A metodologia Design Science é responsável por conceber e validar sistemas que ainda não existem e que permitem a solução de um problema específico, seja criar ou alterar projetos, processos e software ou mesmo métodos que possam melhorar uma situação já existente. Esta metodologia define a existência de uma constante preocupação e foco durante todo o desenvolvimento, prevenindo que o projeto se afaste dos objetivos definidos inicialmente. (Pacheco Lacerda et al., 2013).

A metodologia Design Science Research é apresentada no artigo “Making a Difference: Organization as Design” (Romme A., 2003), como sendo a ideal para transformar situações inexistentes nas desejadas, e como uma das principais formas de desenvolver o conhecimento e de realizar pesquisas científicas. Permite também estender os limites da capacidade humana e organizacional, criando assim artefactos novos e inovadores, principalmente como já referido, na área de Sistemas de Informação (Hevner, March, Park, & Ram, 2004).

Com a informação apresentada, a metodologia Design Science Research enquadra- se com o que se pretende resolver neste projeto.

Existem algumas abordagens para Design Science Research, neste projeto será analisado segundo a visão do autor Ken Peffers apresentada no artigo “A Design Science Research Methodology for Information Systems Research” (Peffers, Tuunanen, Rothenberger, & Chatterjee, 2007). A investigação para a presente projeto será dividido em seis partes definidos pela metodologia apresentada:

(30)

IDENTIFICAÇÃO E MOTIVAÇÃO PARA O PROBLEMA

Numa primeira fase foi identificado o problema, as principais necessidades e a sua real motivação e importância, tal como foi apresentado e detalhado anteriormente (secção Motivação).

DEFINIÇÃO DOS OBJETIVOS ESPERADOS

Numa segunda fase, foram identificados todos os objetivos previstos e funcionalidades desejadas pela equipa responsável do GAT Solidário. Estes foram identificados e especificados nas diversas reuniões no decorrer do projeto. Procura-se, assim, dar resposta a um problema concreto de gestão de informação com o desenvolvimento de uma plataforma para aglomerar toda a temática dos projetos desenvolvidos (secção Objetivos).

DESENHO E DESENVOLVIMENTO

A terceira fase inclui o desenho das funcionalidades desejadas (secção Especificação dos requisitos), da arquitetura e o desenvolvimento de todo o sistema (Peffers et al., 2007).

Partindo dos objetivos, foi identificado o modelo de domínio da solução, bem como os respetivos diagramas de classes, casos de uso, atividades e de sequência de forma a descrever e representar a aplicação pretendida (ver secção Modelação do Sistema).

De seguida foi realizada uma análise comparativa entre diferentes tecnologias orientadas para o desenvolvimento web, de forma a identificar a tecnologia a utilizar nas diferentes camadas (secção Análise Tecnológica).

Previamente ao desenvolvimento da plataforma foi ainda realizado um mockup (Anexo-I, Anexo-II) da solução de forma a prever, simular e identificar o design gráfico pretendido tanto do website como da dashboard.

Por último foi implementado as diferentes camadas da solução, utilizando as tecnologias definidas de forma a concretizar o que foi idealizado num artefacto funcional.

DEMONSTRAÇÃO

Na quarta fase foi apresentada uma demonstração presencial de forma a provar que o artefacto desenvolvido consegue resolver uma ou mais instância do problema (Peffers et al., 2007). Foi apresentado toda a solução sob a forma de uma demonstração aos

(31)

responsáveis pelo projeto GAT Solidário, mostrando assim todas as funcionalidades implementadas.

AVALIAÇÃO

Na quinta fase, perante a solução desenvolvida o objetivo é avaliar se a mesma corresponde a todas as necessidades definidas ao comparar os objetivos com os resultados observados na demonstração (Peffers et al., 2007).

COMUNICAÇÃO

Por último na sexta fase, foi realizada toda a documentação do problema, presente no corrente documento, a sua importância e os diferentes processos do produto que foi desenvolvido, difundindo assim todo o conhecimento resultante (Hevner et al., 2004).

Figura 2 - Processo DSRM (Peffers et al., 2007)

A figura 2 apresenta as diferentes fases da metodologia apresentada de uma forma sequencial, no entanto, pode existir uma abordagem não sequencial ao problema sendo possível voltar para uma atividade anterior e prosseguir o processo.

(32)

(33)

3. ESPECIFICAÇÃO DOS REQUISITOS

Após as diversas interações com os responsáveis do projeto, foi possível delinear e definir a visão que estes pretendem para a solução final do sistema. Foram identificados três atores com perspetivas distintas que irão interagir com o sistema, todos importantes para definir todo o domínio no mesmo:

- Professor: Este ator representa a entidade que manipula todo o conteúdo dinâmico no sistema, sendo divididos em três categorias com diferentes permissões. Os “professores” que apenas podem alterar o contudo, os “administradores”, que para além de alterar o contudo podem também adicionar novos professores ou administradores bem como alterar as suas perdições. Por último existe o “responsável” que para além das funcionalidades anteriores pode eliminar qualquer utilizador do sistema.

- Voluntário: Este pode-se candidatar como voluntário para um projeto em específico a decorrer ou para o projeto GAT solidário como um todo. Este voluntário tem que ser aluno da instituição associada ao GAT Solidário,

- Utilizador: É aquele que consulta todo o conteúdo de acesso público disponível no sistema através do website.

De forma superficial, o sistema web pretendido terá que disponibilizar:

- Informação sobre o projeto GAT Solidário, como a sua história e a da unidade curricular que está associado.

- Informação de contacto e redes sociais.

- Informação dos parceiros ou organizações associadas ao projeto.

- Informação de todos os projetos, bem como cada evento realizado nos mesmos.

- Informação das diferentes turmas, que em cada ano letivo estiveram associadas aos diferentes projetos.

- Disponibilizar um formulário de inscrição para possibilitar a candidatura como voluntário para o projeto.

Com base na informação apresentada anteriormente, podemos representar o problema através do modelo de domínio, sendo assim possível identificar entidades importantes na lógica de negócio. A Figura 3 apresenta o modelo de domínio desenhado para a solução.

(34)

Figura 3 - Modelo de domínio da solução

Partindo do modelo de domínio, é essencial definir e especificar os requisitos do sistema. Cada requisito contém um determinado objetivo que no seu conjunto, refletem as necessidades do cliente, definindo assim a lista de serviços e funcionalidades que o sistema deve disponibilizar (Sommerville, 2016). Um requisito pode ser caracterizado como uma funcionalidade ou qualidade que o sistema deve possuir, de forma a conferir valor aos seus utilizadores (Kelly & Tolvanen, 2008). Da perspetiva de um engenheiro de software pode ser caracterizado como algo que precisa de ser desenvolvido, para atender a algo que alguém deseja ou necessita, quer para resolver um problema ou atingir um objetivo.

Podemos caracterizar os requisitos em duas categorias, requisitos funcionais e não funcionais, que em conjunto definem todos os requisitos do sistema.

3.1 REQUISITOS FUNCIONAIS

Os requisitos funcionais descrevem funcionalidades que o sistema deve fornecer ou, em alguns casos o que não deve fazer (Sommerville, 2016).

Podem ser enquadrados em duas categorias, requisitos funcionais implícitos, correspondendo aos normalmente identificados pela equipa de desenvolvimento com base no seu conhecimento no domínio do sistema e os requisitos funcionais explícitos, que representam os solicitados pelo utilizador.

Para este problema, os requisitos funcionais identificados estão representados em cada uma das seguintes tabelas (Tabela 1 – Tabela 18), em que, cada uma especifica um requisito através de um identificador, o modulo a que este pertence, sendo do website ou dashboard, a sua versão e prioridade (essencial, importante e normal), bem como o seu nome e descrição.

(35)

Identificador RF001 Módulo Website Nome Apresentar informação sobre o projeto GAT Solidário.

Versão 1 Prioridade Essencial

Descrição O sistema deverá apresentar informação estática relacionada com o projeto GAT como, informação geral, contatos e formulário de candidatura como voluntário.

Tabela 1 - Especificação RF001

Identificador RF002 Módulo Website

Nome Disponibilidade da informação no website.

Descrição Qualquer informação acedida através do website pode ser consultada por qualquer utilizador.

Nome Informação dos projetos e eventos dinamicamente.

Descrição O sistema deve apresentar de forma dinâmica informação dos diferentes projetos de voluntariado bem como os respetivos eventos realizados em cada um dos mesmos.

Nome Informação dos eventos dinamicamente.

Descrição Deve dispor informação dinamicamente de cada evento como título, descrição, conteúdo relevante e imagens.

Nome Possibilidade de filtrar os eventos.

Descrição Na listagem dos eventos deverá disponibilizar a opção de filtrar os mesmo por organização.

(36)

Identificador RF006 Módulo Website Nome Informação das equipas e turmas dinamicamente.

Descrição O sistema deve apresentar de forma dinâmica os diferentes equipas de voluntariado bem como as respetivas turmas.

Nome Notificação a quando uma nova inscrição como voluntário.

Descrição O sistema deve enviar um email aos responsáveis do GAT Solidário a quando de uma nova inscrição como voluntário.

Nome Notificação a quando de um erro.

Descrição O sistema deverá avisar o utilizador na forma de mensagens no ecrã caso eventualmente surja algum erro.

Identificador RF009 Módulo Dashboard

Nome Gestão do conteúdo na dashboard.

Descrição Deve ser possível gerir todo conteúdo dinâmico na dashboard, como projetos, eventos, organizações, equipas e turmas onde é possível criar, editar e apagar qualquer tipo de conteúdo.

(37)

Identificador RF010 Módulo Dashboard Nome Associar evento a um projeto.

Descrição Ao criar um evento deverá ser possível associar o mesmo a um projeto.

Nome Associar evento a uma organização.

Descrição Ao criar um evento deverá ser possível associar o mesmo a uma organização.

Nome Associar turma a uma equipa.

Descrição Ao criar uma turma deverá ser possível associar a mesma a uma equipa.

Nome Disponibilização do conteúdo da dashboard no website.

Descrição O conteúdo introduzido na dashboard deve estar disponível no website.

Nome Acesso restrito à dashboard.

Descrição Toda as funcionalidades na dashboard deverão ser acessíveis após login válido.

(38)

Identificador RF015 Módulo Dashboard Nome Restrição para remover utilizadores do sistema.

Descrição Apenas o utilizador responsável pode eliminar utilizadores do sistema.

Nome Novos utilizadores no sistema.

Descrição Apenas o responsável ou administradores do sistema podem adicionar novos utilizadores.

Nome Alterar permissões de utilizadores.

Descrição Apenas o responsável ou administradores do sistema podem alterar as permissões de um utilizador removendo ou garantindo permissões de administrador.

Nome Alterar perfil de utilizador.

Descrição Um utilizador autorizado pode editar o seu perfil, podendo alterar o nome e a sua password.

3.2 REQUISITOS NÃO FUNCIONAIS

Os requisitos não funcionais especificam ou limitam as características de serviços ou funções oferecidas por todo o sistema (Sommerville, 2016), podendo ser de diferentes categorias:

- Aspeto: aspeto visual e estética do sistema (interface gráfica).

(39)

- Operacionalidade: características do sistema para funcionar corretamente no ambiente em que está inserido.

- Usabilidade: facilidade na utilização do sistema para garantir uma boa experiência de utilização.

- Manutenção do sistema e suporte: prevenir possíveis correções no sistema e antecipar novas funcionalidades.

- Desempenho: velocidade do sistema tanto como disponibilidade, confiabilidade e tolerância a falhas.

- Legal: ter em conta as regras e leis que afetam o sistema na sua operação.

- Segurança: segurança, confiabilidade e integridade do produto.

- Cultura e Política: relacionado com fatores sociais e humanitários globais ou onde o sistema é implementado.

Para este problema, os requisitos não funcionais identificados estão representados em cada uma das seguintes tabelas (Tabela 19 – Tabela 26), em que, cada uma especifica um requisito através de um identificador, a sua versão e prioridade (essencial, importante e normal), bem como o seu nome e descrição, em semelhança com os requisitos funcionais.

Identificador RNF001

Nome User interface simples e intuitiva.

Versão 1 Prioridade Importante

Descrição A aplicação deverá ter uma interface simples e intuitiva para motivar e facilitar a sua utilização.

Tabela 19 - Especificação RNF01

Nome Utilização de um design responsivo.

Descrição Implementar um design responsivo na interface gráfica de todo a aplicação para uma melhor experiência em dispositivos móveis.

(40)

Nome Disponibilidade em diferentes browsers.

Descrição Uma vez que a interface se destina a ser apresentada num browser impõe-se a

compatibilidade com os navegadores web mais comuns da atualidade (Google Chrome, Mozilla, Opera e Edge).

Nome Otimização do código.

Descrição Todo o código implementado deverá estar otimizado de forma a garantir uma fácil manutenção do mesmo.

Nome Notificações na utilização da dashboard.

Descrição O sistema deverá apresentar notificações quando é feita uma interação com o sistema, ex.

Guardar um projeto.

Nome Documentação da solução.

Descrição O desenvolvimento da aplicação deverá ser feito tendo em conta futuras atualizações e alterações. Ao mesmo tempo deverá existir documentação que permitam que pessoas externas ao projeto atual se possam contextualizar e realizar operações de manutenção ao software em funcionamento.

(41)

Nome Privacidade nos dados dos utilizadores.

Descrição O sistema não apresentará aos utilizadores quaisquer dados de considerado privado.

Nome Idioma do sistema.

Descrição O sistema terá de suportar o idioma português em toda a sua utilização.

(42)

(43)

4. DESENHO E DESENVOLVIMENTO

4.1 MODELAÇÃO DO SISTEMA

O processo de modelação de um sistema pode ser visto como a criação de modelos abstratos do mesmo, em que cada modelo representa uma visão ou perspetiva diferente do mesmo, utilizando uma notação gráfica com o desenho de diferentes diagramas na Linguagem de Modelagem Unificada (UML) (Sommerville, 2016). A linguagem UML foi apresentada por Grady Booch, James Rumbaugh, e Ivar Jacobson (Rumbaugh, Jacobson,

& Booch, 2004) que tornaram standard a modelação orientada a objetos (Sommerville, 2016).

A linguagem UML apresenta diferentes tipos de diagramas, o artigo “Can UML be simplified? Practitioner use of UML in separate domains” (Erickson & Siau, 2007) apresenta o diagrama de classes, de casos de uso e de sequência como os essenciais para a modelação de um sistema web. Além dos anteriores, foi também desenhado o diagrama de atividades por forma a completar a especificação do sistema.

Para este contexto foi utilizado uma abstração da linguagem UML que mais se adequou a descrição deste projeto em contexto de projeto de tese, de forma a facilitar a leitura e compreensão da especificação, mesmo por entidades sem conhecimento da área. Sento está demostração uma amostra da especificação total, podendo esta ser detalhada futuramente.

4.1.1 DIAGRAMA DE CLASSES

O diagrama de classes, aqui apresentado na Figura 4, representa o conjunto de classes e a relação entre as mesmas (Sommerville, 2016), bem como todos os atributos e operações em cada uma das mesmas. Representa assim uma visão estática do sistema (Rumbaugh et al., 2004).

(44)

Figura 4 - Diagrama de classes do sistema

Através do diagrama de classes podemos observar que a entidade professor tem a possibilidade de criar equipas, turmas, projetos eventos e organizações. Uma equipa contém um conjunto de turmas associadas bem como cada projeto é constituído por múltiplos eventos. Para um evento está também associado a organização em que este ocorreu. Conseguimos assim modular e visualizar todo o sistema dinâmico que é pretendido.

4.1.2 DIAGRAMA DE CASOS DE USOS

Ao desenhar o diagrama de casos de uso é possível definir o comportamento entre o sistema, ou parte dele com os diferentes atores e a relação entre os mesmos (Rumbaugh et al., 2004).

Ao analisar o sistema em questão foi definido um diagrama de casos de uso global de forma a demonstrar o pretendido, conforme se apresenta na Figura 5, que se segue.

(45)

Figura 5 - Diagrama de Casos de uso global do sistema

Ao observar o diagrama da Figura 5 podemos concluir que:

- Tal como já apresentado, existem três tipos de atores responsáveis por submeter todo o conteúdo na plataforma, aqui apresentados como “Professor” que gere todo o conteúdo bem como o seu perfil, para além deste existe o ator “Administrador” e “Responsável” que fazem toda a gestão dos utilizadores. Neste contexto qualquer um destes atores serão identificados por “Professor”

salvo aquando de uma maior especificação dos mesmos.

- Qualquer um dos atores “Professor”, antes de qualquer operação terá de efetuar login no sistema.

- Relacionado com a gestão de conteúdos, um professor pode fazer a gestão de todo o conteúdo relacionado tanto com os projetos como com as equipas.

- Todo o conteúdo é então disponível, sendo possível a sua consulta pelos utilizadores, onde pode consultar a informação de contactos, informação geral e o formulário de voluntário. É possível também preencher o formulário e submeter uma nova candidatura como voluntário.

Referente ao caso de uso da gestão de utilizadores, pode ainda ser especificado, como mostra na Figura 6.

(46)

Figura 6 - Diagrama de Casos de Uso: Gerir Utilizadores

Neste momento é feita uma distinção entre o “Responsável” onde apenas este pode remover utilizadores e o/s “Administrado” que consegue não só adicionar um novo utilizador como alterar as suas permissões, ou seja, dar ou remover permissões de administrador a um utilizador.

Os casos de uso correspondentes à gestão dos projetos e das equipas foram igualmente especificados separadamente do caso de uso principal. A Figura 7 representa, assim o case de uso para a gestão de projetos.

Figura 7 - Diagrama de Casos de Uso: Gerir Projetos

(47)

Neste caso um “Professor”, tem a possibilidade de inserir, editar ou apagar um projeto, organização ou evento. Ao criar ou editar um evento pode também associar o mesmo ao projeto a que este está associado bem como a organização em que foi realizado. No seguimento, na Figura 8, procura-se, assim representar o caso de uso destinado à gestão das equipas.

Figura 8 - Diagrama de Casos de Uso: Gerir Equipas

À semelhança dos projetos, em relação as equipas, um “Professor” tem a possibilidade e criar, atualizar ou apagar uma equipa ou uma turma. Ao criar ou editar uma turma é possível associar a mesma à equipa a que esta está associada.

4.1.3 DIAGRAMA DE ACTIVIDADES

O presente diagrama representa uma visão dinâmica do sistema e a ligação entre as suas diferentes atividades (Rumbaugh et al., 2004). Neste contexto o elemento usado no UML para tarefas declarar tarefas sincronizadas, foi utilizado como elemento de decisão, para aumentar a legibilidade dos diagramas.

(48)

Figura 9 - Diagrama de Atividades: Consultar Website

Como apresentado na Figura 9, qualquer utilizador tem a possibilidade de aceder ao website e consultar toda a informação presente. Em conformidade com os requisitos, é possível consultar:

- Informação geral do projeto.

- Os diferentes projetos e respetivos eventos.

- As turmas pertencentes as diferentes equipas.

- As diferentes organizações parceiras do projeto.

- Os contactos e redes sociais do projeto.

- O formulário de voluntário e submeter uma nova candidatura caso pretendido.

Na dashboard de gestão do conteúdo, como apresentado na Figura 10, o utilizador após efetuar o login consegue fazer todas as diferentes operações presentes na plataforma.

(49)

Figura 10 - Diagrama de Atividades: Dashboard

O utilizador tem ainda a possibilidade de alterar o seu perfil, onde pode alterar o nome e a password, além de conseguir efetuar todas as operações relacionadas com a gestão dos utilizadores, projetos, equipas e organizações.

Em relação aos utilizadores e a gestão dos mesmos, como apresentado na Figura 11, tendo em consideração os diferentes tipos de utilizadores já referidos, é possível:

- Adicionar um novo utilizador.

- Apagar um determinado utilizador

- Alterar as permissões de um utilizador, atribuindo ou removendo permissões de administrador.

(50)

Figura 11 - Diagrama de Atividade: Utilizadores

Relacionado com os projetos, como apresentado na Figura 12, é possível efetuar toda a gestão dos mesmos por parte dos utilizadores.

(51)

Figura 12 - Diagrama de Atividade: Projetos

Um professor pode assim adicionar, editar ou remover um projeto ou evento. Ao criar um novo evento pode, case deseje, associar o projeto a que este pertence, bem como a organização em que foi realizado.

(52)

Figura 13 - Diagrama de Atividade: Organizações

Referente às organizações, como é apresentado na Figura 13, o processo é semelhante aos projetos. Um professor tem a possibilidade de adicionar, editar ou eliminar uma organização, para que possa posteriormente aparecer no website ou mesmo associar a um evento realizado nessa mesma organização.

(53)

Figura 14 - Diagrama de Atividade: Equipas

Para a gestão das equipas, apresentado na Figura 14, o processo é bastante similar à gestão dos projetos.

O utilizador pode igualmente criar, editar ou eliminar uma equipa ou turma. Posteriormente ou na sua criação pode assim associar as diferentes turmas à equipa a que esta pertence.

4.1.4 DIAGRAMA DE SEQUÊNCIA

No diagrama de sequência é possível simular as diferentes interações entre os diversos atores o sistema e os seus componentes (Robertson & Robertson, 2012). Partindo do diagrama de casos de uso, foram definidos os diferentes diagramas de sequência.

(54)

Figura 15 - Diagrama de Sequência: Consultar Website

A Figura 15 representa o diagrama de sequência para uma consulta por parte de um utilizador ao website.

Este ao aceder ao mesmo, é feito um pedido ao servidor com a informação que este pretende, dependente da página que o utilizador está a consultar. O servidor de seguida response e o conteúdo é apresentado no website, sendo uma consulta normal ao website e independente da página que utilizador esteja a consultar.

Figura 16 Diagrama de Sequência: Submeter formulário

(55)

Ao aceder ao website e após navegar para a página onde se encontra o formulário, é possível submeter uma candidatura como voluntario. Ao submeter é feito um pedido novamente ao servidor com os dados do voluntário, para este registar a candidatura e enviar a informação novamente para o utilizador após o seu registo estar concluído, demonstrado na Figura 16.

Figura 17 - Diagrama de Sequência: Adicionar Utilizador

Como mencionado, na dashboard é possível adicionar um novo utilizador, aqui representado no diagrama de sequência da Figura 17, o professor define os campos com a informação correspondente e guarda o mesmo.

Ao guardar a informação o servidor irá receber os dados, guardar na base de dados e retornar uma notificação para a interface, mostrando ao professor que o utilizador foi adicionado com sucesso. É possível também alterar ou eliminar um utilizador, em que o processo é bastante semelhante ao descrito anteriormente, é feito um pedido ao servidor, este processa o pedido retornando sempre uma notificação de volta para a interface.

(56)

Figura 18 - Diagrama de Sequência: Criar Projeto

O diagrama de sequência da Figura 18, representa o processo de criação de um novo projeto. O responsável define os campos com a informação correspondente ao mesmo, ao guardar a informação, o servidor irá receber os dados, guardar na base de dados e retornar uma notificação para a interface. É também possível atualizar ou remover o um projeto, sendo o processo semelhante ao descrito anteriormente. Para atualizar, ao alterar os valores e ao guardar os dados, estes serão atualizados na base de dados. Após atualizar a informação o servidor irá retornar uma notificação para a interface.

Para remover um projeto existente é necessário selecionar o projeto pretendido e remover o mesmo, o servidor irá processar o pedido e apagar o projeto da base de dados. Ao apagar o projeto, o servidor irá atualizar todas os eventos que estão associados a este projeto, fazendo com que estes fiquem sem projeto associado para uma coerência do sistema. Após terminar o processo o servidor irá retornar uma notificação para a interface.

Figura 19 - Diagrama de Sequência - Criar Evento

(57)

Para a criação de um novo evento, apresentado no diagrama de sequência da Figura 19, é necessário definir a informação pretendida, ao guardá-lo o servidor irá receber os dados, guardar na base de dados e retornar uma notificação para a interface.

Em semelhança com os projetos, o processo de atualizar ou remover um evento é bastante semelhante ao de criar. Para editar um evento existente é necessário selecionar o evento pretendido, alterar os valores e ao guardar os dados em que serão atualizados na base de dados. Após atualizar a informação o servidor irá retornar uma notificação para a interface.

Para remover um evento existente, após selecionar o pretendido, o servidor ao receber o pedido irá apagar toda a informação da base de dados. Após terminar o processo o servidor irá retornar uma notificação para a interface.

Figura 20 - Diagrama de Sequência: Criar Equipa

Para adicionar uma nova equipa, apresentado no diagrama de sequência da Figura 20, é necessário definir a informação pretendida e guardar a mesma. Ao guardar a equipa o servidor irá receber os dados, guardar na base de dados e retornar uma notificação.

Para editar ou atualizar uma equipa existente é necessário selecionar a equipa pretendida, alterar os valores e ao guardar os dados, estes serão atualizados na base de dados. Após atualizar a informação o servidor irá retornar uma notificação para a interface.

Para apagar uma equipa existente, ao remover a mesma, o servidor irá processar o pedido e apagar da base de dados. Ao apagar a equipa, irá atualizar todas as turmas que estão associados a esta equipa, fazendo com que estas fiquem sem equipa associada. Após terminar o processo o servidor irá retornar uma notificação para a interface.

(58)

Figura 21 - Diagrama de Sequência: Criar Turma

Para adicionar uma nova turma, apresentado no diagrama de sequência da Figura 21, é necessário definir a informação pretendida e guardar a mesma. Ao guardar a turma o servidor irá receber os dados, guardar na base de dados e retornar uma notificação para a interface.

Para editar ou atualizar uma turma existente é necessário selecionar a turma pretendida, alterar os valores e ao guardar os dados, estes serão atualizados na base de dados. Após atualizar a informação o servidor irá retornar uma notificação para a interface.

Para remover uma turma existente é necessário selecionar a turma pretendida, o servidor ao receber o pedido irá apagar toda a informação da base de dados. Após terminar o processo o servidor irá retornar uma notificação para a interface.

Figura 22 - Diagrama de Sequência: Criar Organização

À semelhança dos anteriores, para adicionar uma nova organização, apresentado no diagrama de sequência da Figura 22, é necessário definir a informação pretendida e guardar a mesma. Ao guardar a organização o servidor irá receber os dados, guardar na base de dados e retornar uma notificação para a interface.

(59)

Para editar ou atualizar uma organização existente é necessário selecionar a organização pretendida, alterar os valores e ao guardar os dados estes serão atualizados na base de dados. Após atualizar a informação o servidor irá retornar uma notificação para a interface.

Para apagar uma organização existente é necessário selecionar a organização pretendida, ao remover a mesma o servidor irá processar o pedido e apagar da base de dados. Ao apagar a organização, irá atualizar todas os eventos que estão associados à organização, fazendo com que estes fiquem sem organização associada.

Após terminar o processo o servidor irá retornar uma notificação para a interface.

4.2 ANÁLISE DA TECNOLOGIA

Ao planear o desenvolvimento de um software ou produto, existem diversas tecnologias que podem ser adotadas e utilizadas durante o processo de desenvolvimento.

A escolha de uma tecnologia pode depender de diversos fatores. O processo de decisão pode ser visto como um processo composto por quatro fases (Slade, 1993), a identificação do problema, identificação das alternativas, avaliação das alternativas e por fim selecionar entre as alternativas analisadas.

Neste caso, como já apresentado, trata-se de desenvolvimento de um software web. Neste momento, com base na arquitetura por camadas já apresentada, é necessário identificar a tecnologia que que melhor se adapta a cada uma das mesmas. Durante a análise de uma tecnologia podemos ter em consideração diversos fatores como, a plataforma em que esta será implementada, a sua estabilidade, desempenho e comunidade. Tendo em conta que não existe uma tecnologia perfeita (Slade, 1993) selecionar uma tecnologia de desenvolvimento correta pode gerar soluções coesas, fáceis de entender e de fazer debug (Reghunadh & Jain, 2011).

Como se trata de uma solução web, irá aglomerar diferentes tecnologias orientadas para a mesma. Sendo um modelo por camadas, cada camada será analisada de forma independente, onde serão identificadas e analisadas algumas das tecnologias mais populares de forma a encontrar a que melhor se adapta a cada uma das mesmas.

4.2.1 MODELO DE DADOS

Das arquiteturas existentes de base de dados podemos referir o modelo relacional SQL, ou não relacional NoSql. Embora mais recentes, as base dados NoSQL têm ganho popularidade numa área dominada até à data pelo modelo SQL (Parker, Poe, & Vrbsky, 2013), estando por vezes associado com à gestão de grande volume de dados (Stonebraker, 2010).

O estudo “Comparing NoSQL MongoDB to an SQL DB” (Parker et al., 2013) compara uma das soluções NoSQL existentes, o MongoDB, com SQL Server que segue uma abordagem relacional, para diferentes operações como inserção, atualização e seleção para diferentes volumes de dados. Das conclusões apresentadas, de forma geral a arquitetura MongoDB tem uma melhor performance para inserções, atualizações e consultas simples. A arquitetura SQL consegue uma melhor performance quando são feitas atualizações em atributos que não são chave primária e em consultas com agregações entre os dados. Existem também grandes

(60)

vantagens na utilização de bases de dados NoSQL, a velocidade de leitura e escrita, facilidade de escalabilidade, bem como o baixo custo para a sua implementação (Parker et al., 2013).

Um outro artigo “A performance comparison of SQL and NoSQL databases” (Li & Manoharan, 2015), que à semelhança do anterior compara diferentes tecnologias NoSQL e SQL. De forma a possibilitar uma sincronização com o artigo anterior, será analisado apenas as tecnologias MongoDB e SQL Server. Das conclusões apresentadas, a tecnologia MongoDB apresenta bons resultados de performance comparativamente com a SQL Server, apresentado melhores resultados nas operações de leitura, escrita e remoção dos dados.

Sendo o projeto GAT um projeto inserido na atividade académia, o baixo custo para a implementação do projeto a realizar é um ponto importante, além disso sendo este o primeiro projeto para organizar todo o conteúdo, uma possível escalabilidade é outro fator a ter em consideração.

4.2.2 SERVERSIDE

Ao analisar diferentes tecnologias que são direcionados para esta camada, o artigo “Performance comparison and evaluation of Node.js and traditional web server (IIS)” (Chaniotis, Kyriakou, & Tselikas, 2015) apresenta que a tecnologia NodeJs, supera o PHP em termos de performance, eficiência de memória e na utilização de recursos de processamento disponíveis. Neste ponto, apesar de o NodeJs não ser amplamente utilizado, a forma como é utilizado e os recurso que oferece faz dele uma boa alternativa a tecnologias convencionais como PHP, Python ou Java (Chitra & Satapathy, 2017).

No artigo “Performance Comparison and Evaluation of Web Development Technologies in PHP, Python, and Node.js” (Lei, Ma, & Tan, 2015), da análise do autor o NodeJs apresenta em geral um resultado bastante positivo comparativamente ao PHP ou Phyton, principalmente a lidar com um grande volume de pedidos.

A tecnologia Node.Js é implementada utilizando JavaScript com o foco em performance e baixo consumo de memória (Tilkov & Vinoski, 2010), para um desenvolvimento fácil e escalável de aplicações web (Lei et al., 2015).

4.2.3 CLIENTSIDE

Corresponde à camada de apresentação, neste projeto é constituída por duas partes, o website de acesso público e a dashboard para a gestão de todo o conteúdo dinâmico no website.

Para implementar o website será utilizado standards atuais no desenvolvimento web, com a combinação de HTML5, CSS3 e JavaScript (Tilkov & Vinoski, 2010), essenciais na construção de páginas web.

No caso da dashboard, será implementada como uma SPA (Single Page Application), uma página dinâmica constituída por componentes individuais que são alterados e manipulados sem uma nova atualização de toda a página (Madhuri A. Jadhav, Balkrishna R. Sawant, 2015). Por vezes a construção de uma SPA em JavaScript torna-se bastante complexo (Madhuri A. Jadhav, Balkrishna R. Sawant, 2015). De forma a responder a essa necessidade surgiram diversas frameworks para auxiliar na sua construção, garantindo uma interface gráfica fluida e de qualidade (Madhuri A. Jadhav, Balkrishna R. Sawant, 2015).

Será utilizada a framework Angular para implementação da dashboard. Esta está entre as principais frameworks de JavaScript de acordo com o website (“Web framework rankings | HotFrameworks,” 2019), que

(61)

cria rankings de frameworks de diversas linguagens baseando-se na popularidade dos projetos desenvolvidos no GitHub entre outras métricas. Podemos destacar ainda React e Vue.Js que estão também entre as mais populares, não existindo grandes diferenças entre eles, acabando por ser uma questão de preferência.

De uma forma sucinta, será utilizado MongoDB, Node.Js e Angular como principais tecnologias para desenvolver e implementar toda a aplicação, fazendo com que seja utilizado uma linguagem comum entre todas as camadas, JavaScript, considerado como uma vantagem (Chaniotis et al., 2015) e fazendo com que exista uma consistência em toda aplicação.

4.3 MOCKUP E DESENVOLVIMENTO DA SOLUÇÃO

Para o desenvolvimento de uma aplicação web é crucial considerar a interface como parte importante do processo. A interface pode ser vista como o sistema intermediário entre os utilizadores e o conteúdo, garantindo uma experiência coesa na utilização de toda aplicação (Fleming & Koman, 1998).

Com base nos diagramas definidos, e em parceria com responsáveis do projeto GAT foi possível elaborar um mockup para toda a solução de forma a visualizar o resultado pretendido, com um design responsivo e que correspondesse ao que que era requisitado. Todo o conteúdo presentes nos mockups são meramente ilustrativos, podendo ser alterados na solução implementada.

Em relação ao desenvolvimento, cada uma das camadas foi desenvolvida separadamente, de forma a serem independentes entre si comunicando entre elas apenas por API.

4.3.1 DASHBOARD

O mockup da dashboard foi projetado para ser funcional, fácil de utilizar e que responda a todas as necessidades identificadas na modelação do sistema, pois será utilizado diariamente pelos responsáveis do projeto GAT para a gestão de todo o conteúdo.