Sistema de gestão das inspecções de ascensores

José Luís Silva Oliveira Sistema de Gestão das Inspecções de Ascensores abril 2023 UMinho | 2023 José Luís Silva Oliveira Sistema de Gestão das Inspecções de Ascensores 2 i José Luís Silva Oliveira Sistema de Gestão das Inspecções de Ascensores Dissertação de Mestrado Mestrado Integrado em Engenharia Electrónica Industrial e Computadores Trabalho efectuado sob a orientação do Professor Doutor Sérgio Adriano Fernandes Lopes Professor Doutor Henrique Manuel Dinis dos Santos abril 2023 ii DIREITOS DE AUTOR E CONDIÇÕES DE UTILIZAÇÃO DO TRABALHO POR TERCEIROS Este é um trabalho académico que pode ser utilizado por terceiros desde que respeitadas as regras e boas práticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licença abaixo indicada. Caso o utilizador necessite de permissão para poder fazer um uso do trabalho em condições não previstas no licenciamento indicado, deverá contactar o autor, através do RepositóriUM da Universidade do Minho. Licença concedida aos utilizadores deste trabalho Atribuição CC BY https://creativecommons.org/licenses/by/4.0/ iii Agradecimentos Agradeço especialmente à minha família por todo o apoio moral, por todo o amor e toda a dedicação que me deram ao longo de todo o meu percurso académico. A todos os meus colegas de curso e amigos que contribuíram para a minha integração na Universidade e enriquecimento pela partilha de conhecimentos e experiências, em especial ao João Silva por toda a disponibilidade e ajuda e pelos conhecimentos que me transmitiu para a realização deste trabalho. Quero agradecer ao Professor Doutor Sérgio Adriano Fernandes Lopes por toda a disponibilidade prestada e por toda a ajuda, orientação e sugestões que contribuíram para melhorar e concluir esta dissertação. Agradeço igualmente ao Professor Doutor Henrique Manuel Dinis dos Santos também por toda a ajuda prestada. Para finalizar, um agradecimento a todos os docentes desta Universidade que transmitiram o seu conhecimento e boas práticas para a minha carreira profissional. iv DECLARAÇÃO DE INTEGRIDADE Declaro ter atuado com integridade na elaboração do presente trabalho académico e confirmo que não recorri à prática de plágio nem a qualquer forma de utilização indevida ou falsificação de informações ou resultados em nenhuma das etapas conducente à sua elaboração. Mais declaro que conheço e que respeitei o Código de Conduta Ética da Universidade do Minho. v RESUMO O ascensor é um meio de transporte obrigatório e essencial para a deslocação de pessoas e bens, principalmente em edifícios de habitação colectiva e edifícios públicos. Com o crescendo de construção deste tipo de edifícios o número de ascensores também tem vindo a aumentar, e é cada vez mais importante garantir que funcionam em segurança e que cumprem a legislação, nomeadamente quanto às inspecções periódicas obrigatórias. É uma responsabilidade das Câmaras Municipais garantir o cumprimento das inspecções periódicas de ascensores. Para isso é necessário verificar continuamente a validade de todos os equipamentos e dar seguimento a todos pedidos de inspecções, efectuadas pelos proprietários, gestores ou empresas de manutenção. Cada pedido envolve uma requisição formal, um pagamento e a actualização do estado do ascensor, após ser encaminhado para a entidade inspectora que faz o agendamento e a inspecção. A gestão de todo este processo de inspecção periódica é bastante complexa, minuciosa e demorada, dado que envolve várias entidades e documentos, pesquisas diárias e troca de informação. A pesquisa por aplicações semelhantes revela a inexistência de uma que envolva todas as entidades e suporte a totalidade deste processo. Uma plataforma de gestão de inspecções completa permite tornar o processo mais simples, com menos falhas e garantir a proximidade entre todos os intervenientes. Nesta dissertação foi desenvolvida uma aplicação web de gestão que permite o controlo das inspecções periódicas de ascensores, desde alertas de prazos, realizar pedidos, visualizar resumida e detalhadamente a informação sobre os ascensores, comunicar agendamentos e actualizar o estado dos ascensores tendo em conta os resultados das inspecções. Esta plataforma proporciona uma interface simples e intuitiva, e constitui uma ferramenta importante para auxiliar todas as entidades envolvidas e garantir o cumprimento legal das inspecções. PALAVRAS-CHAVE: Ascensores, Inspecções, Aplicação Web, Node.Js, Vue.Js vi ABSTRACT The lift is a mandatory and essential means of transportation of people and goods, mainly in collective housing buildings and public buildings. With the growth of construction of this type of buildings, the number of lifts has also been increasing, and the concern to guarantee that they work safely and that they comply with the legislation, in particular with regard to mandatory periodic inspections, is increasingly important. It is the responsibility of the Municipal Councils to ensure the fulfilment of lifts' periodic inspections. For that, it is essential to continuously check the validity of all equipment and follow up on all inspection requests carried out by the owners, managers or maintenance companies. Each order involves a formal request, payment and a lift status update after being forwarded to the inspection entity which makes the scheduling and inspection. The management of all the process is quite complex, meticulous and time-consuming, as it involves several entities and documentation, daily searches and exchange of information. The search for similar applications reveals the lack of one that involves all entities and supports the entirety of this process. A complete inspection management platform makes the process simpler, with fewer failures and ensures proximity between all stakeholders. In this dissertation a management web application was developed that allows the control of periodic lift’s inspections, from deadline alerts, making requests, viewing summarized and detailed information concerning the lifts, communicating schedules and updating the lift’s status considering the results of the inspections. This platform provides a simple and intuitive interface and is an important tool to help all involved entities and to ensure legal compliances with inspections. KEYWORDS: Lifts, Inspections, Web Application, Node.Js, Vue.Js vii ÍNDICE Resumo .............................................................................................................................................. v Abstract ............................................................................................................................................. vi ÍNDICE .............................................................................................................................................. vii Lista de Figuras ................................................................................................................................... x Lista de Tabelas ................................................................................................................................ xiii Lista de Abreviaturas, Siglas e Acrónimos .......................................................................................... xiv 1. Introdução .................................................................................................................................. 1 1.1. Contextualização ................................................................................................................. 1 1.2. Motivação ........................................................................................................................... 2 1.3. Problema ............................................................................................................................ 2 1.4. Objectivos ........................................................................................................................... 3 1.5. Estrutura ............................................................................................................................. 4 2. Estado de Arte ............................................................................................................................ 5 2.1. Ascensores ......................................................................................................................... 5 2.1.1 Evolução ..................................................................................................................... 5 2.1.2 Legislação ................................................................................................................... 5 2.1.3 Processo de Inspecção ................................................................................................ 8 2.2 Plataformas web para gestão de serviços ............................................................................. 9 2.2.1 GESElevador .............................................................................................................. 10 2.2.2 iAuditor ..................................................................................................................... 11 2.2.3 Elevator Inspection .................................................................................................... 12 2.3 Tecnologias ....................................................................................................................... 13 2.3.1 Ferramentas .............................................................................................................. 13 2.3.2 Base de Dados .......................................................................................................... 14 2.3.3 Front-end de aplicações web ...................................................................................... 14 2.3.4 Back-end de aplicações web ...................................................................................... 17 2.3.5 Aplicações móveis ..................................................................................................... 19 2.3.6 Funcionalidades ........................................................................................................ 20 3. Análise e Concepção................................................................................................................. 22 xiv LISTA DE ABREVIATURAS, SIGLAS E ACRÓNIMOS RGEU - Regulamento Geral de Construções Urbanas CM – Câmara Municipal EMIE – Empresa de Manutenção de Instalações de Elevação EI – Entidade Inspectora DGE – Direcção Geral de Energias IDE - Integrated Development Environment SMTP - Simple Transfer Protocol IAM - Identity Access Management XACML - eXtensible Access Control Markup Language BD – Base de dados DER – Diagrama de entidades e relacionamentos HTML - HyperText Markup Language CSS3 - Cascading Style Sheets JSP – Java Server Pages MVVM - Model–View View-Model MVC - Model View Controller MTV - Model Template View UI – User Interface API - Application Programming Interface CC – Cloud Computing IoT – Internet of Things URL - Uniform Resource Locator HTTP - Hypertext Transfer Protocol XML - eXtensible Markup Language JSON - JavaScript Object Notation CRUD - Create, read, update and delete JS - JavaScript 1 1. INTRODUÇÃO 1.1. Contextualização Os ascensores são dos meios de transporte mais seguros que existem, com uma taxa de mortalidade de 0,00000015% nos EUA, tendo em conta que, segundo o jornal LA Times [1], os elevadores fazem anualmente 18 bilhões de viagens das quais resultam em média 27 mortes. Contudo os acidentes acontecem, e alguns são fatais, podendo ser causados por diversos motivos como: portas que não fecham; inutilização ou violação dos contactos de segurança; esmagamento (mãos, braços, pés e pernas); queda no poço do elevador; excesso de peso; uso inadequado; falhas mecânicas e desnivelamento entre a cabine e o pavimento. Nos EUA, os acidentes que ocorrem com ascensores, matam cerca de 30 pessoas e ferem gravemente 17 mil por ano [2]. Uma boa manutenção, para detectar antecipadamente falhas e desgastes que possam ocorrer, e inspecções periódicas realizadas no tempo devido, reduzem a possibilidade de ocorrência de acidentes. Actualmente existe um grande número de edifícios de habitação colectiva e de serviços abertos ao público com ascensores, quer para transporte de pessoas, quer para transporte de mercadorias. Assim, e para que esses equipamentos ofereçam segurança e cumpram a legalidade têm de ser alvo de inspecções periódicas obrigatórias. Inicialmente, uma das entidades responsáveis pelo ascensor, o proprietário, o gestor ou a empresa de manutenção, solicita a inspecção à Câmara Municipal, entidade responsável por garantir o cumprimento das inspecções, que após emissão e confirmação do pagamento encaminha para a entidade inspectora. A entidade inspectora posteriormente agenda e executa o serviço, dando fim ao processo. Todos estes passos são comunicados às entidades envolvidas no pedido. Por ser um processo com vários passos, comunicações e entidades, a sua conclusão pode-se tornar demorada, ou mesmo ficar pendente, colocando em risco a segurança das pessoas. Assim, a criação de sistemas de suporte online tornou-se uma prioridade não só para as câmaras municipais, mas também para as restantes entidades. 2 1.2. Motivação Existe uma grande falha quanto ao cumprimento da obrigatoriedade da realização das inspecções periódicas de ascensores, sejam elevadores, escadas mecânicas, tapetes rolantes ou montacargas, uma vez que, mesmo existindo legislações em vigor, muitas dos equipamentos estão a funcionar de forma ilegal. Só na cidade de Lisboa, existe um atraso que ronda os 2 anos nas inspecções aos ascensores [3], gerando em consequência, um descontentamento por parte dos proprietários e dos condóminos, por razões não só de carácter económico, uma vez que é pago um serviço que não é prestado, mas também por questões óbvias de segurança. Esta situação não existe apenas em Portugal, mas em muitos outros países surge o mesmo problema. Dos mais de 4,2 milhões de elevadores existentes na União Europeia [4], a Grécia é um dos países com maior número de ascensores, cerca de 450.000 [4], com uma grande incidência de acidentes [4] e uma enorme necessidade e interesse de que sejam efectuadas inspecções periódicas obrigatórias a todos os ascensores [5][6]. A mesma situação acontece na Coreia, onde por ano ocorrem mais de 90 acidentes [6]. Para dar resposta a esta lacuna têm surgido no mercado algumas plataformas para o serviço de inspecções de ascensores, no entanto, a maioria delas está direccionada apenas para uma entidade, não permitindo que vários utilizadores façam a gestão de um equipamento, pelo que não podem suportar todo o processo, desde os pedidos até à certificação, pois envolvem inevitavelmente diferentes entidades. Assim, o projecto desta dissertação é diferente dos existentes, uma vez que o sistema proposto possibilita uma interacção entre todas as entidades envolvidas no processo de inspecção de ascensores. 1.3. Problema Tendo em conta o enquadramento referido na secção anterior, o problema deste projecto consiste na dificuldade de aproximar todos os intervenientes no processo de inspecção de ascensores e torna-lo mais ágil e interactivo. Neste processo estão envolvidas várias entidades, a Câmara Municipal, responsável por garantir o cumprimento das inspecções periódicas, o proprietário e o gestor do ascensor, a empresa de manutenção do equipamento, uma vez que é obrigatório a existência de um contracto que garanta as manutenções, e por último a entidade inspectora, responsável pela realização das inspecções. No seguimento do pedido de inspecção efectuado pelo proprietário, gestor ou empresa de manutenção e após pagamento efectuado à Câmara Municipal é encaminhado para a entidade inspectora, que procede 3 ao agendamento e dá conhecimento às restantes entidades. Efectuada a inspecção comunicado o resultado acompanhado por um relatório. No caso de aprovação, a validade é de 2 anos, tendo que ser solicitada nova inspecção 60 dias antes do término da validade. Se houver lugar a reprovação tem de ser solicitada uma reinspecção do prazo de 30 dias, contudo se não estiverem reunidas todas as condições de segurança é efectuada a selagem e só pode entrar em funcionamento após efectuada uma nova inspecção. Além dos tipos de pedidos referidos, inspecção periódica, reinspecção e selagem, existem outros menos relevantes mas que têm de ser tidos em conta, e que só podem ser solicitados pela Câmara Municipal, como a inspecção extraordinária, inquérito a acidentes, peritagem, relatório e parecer. Assim, e uma vez que cada actor tem funções diferentes e existem prazos a cumprir, é necessário disponibilizar funcionalidades que suportem todo este processo. 1.4. Objectivos Esta dissertação tem como objectivo final o desenvolvimento de uma plataforma web e móvel com base no ascensor, que permita a interacção entre todos os intervenientes no processo de inspecção periódica de ascensores, Câmara Municipal, o proprietário e o gestor do ascensor, a empresa de manutenção e a entidade inspectora, bem como garantir o cumprimento legal das inspecções, de acordo com o Decreto-Lei 320/2002, de uma forma mais fácil e próxima de todos, desde o recebimento de alertas da proximidade da caducidade da validade da inspecção, antes 60 dias, a realização do pedido de inspecção periódica, a necessidade de ser solicitada uma reinspecção após reprovação, ou mesmo uma selagem no caso de estar em causa a segurança normal de funcionamento, até à normalização do estado do ascensor com a realização da inspecção, reinspeção ou selagem. Além dos pedidos referidos, é necessário incluir outros apenas para a Câmara Municipal, como a inspecção extraordinária, inquérito a acidentes, peritagem, relatório e parecer. É também pretendido que a aplicação disponibilize a possibilidade de visualização de toda a informação de um ascensor, bem como suporte para armazenamento de ficheiros relativos a cada ascensor e utilização de Google Maps na localização do equipamento. Nos dias de hoje além das plataformas web para gestão de vários serviços, também há uma grande necessidade de existirem aplicações móveis, por serem uma forma de interacção fundamental para alguns utilizadores, nomeadamente os técnicos das inspecções. Contudo, e por ser um sistema demasiado grande e complexo para ser implementado como um produto com todas as funcionalidades, o desenvolvimento da aplicação móvel fica excluído. 4 1.5. Estrutura A dissertação está organizada em 6 capítulos. O primeiro capítulo contém uma introdução ao projecto, expondo a contextualização, a motivação, o problema e os objectivos. No segundo capítulo é feita uma revisão da literatura, são mencionadas e comparadas algumas plataformas web existentes, com realce das suas vantagens e o que os diferencia. Ainda neste capítulo é feita uma breve descrição de algumas tecnologias utilizadas no desenvolvimento de plataformas web e móvel. No capítulo três é apresentada a concepção para o desenvolvimento da plataforma, através da descrição dos requisitos, do mapa de funcionalidades, dos casos de uso, do modelo de dados, de arquitectura e do desenho das interfaces. No quarto capítulo é explicada toda a implementação da plataforma, quer ao nível do back-end , quer ao nível do front-end , bem como todas as funcionalidades e um resumo dos requisitos que foram desenvolvidos. No capítulo cinco, são apresentados os testes e resultados alcançados. Finalmente, no capítulo 6, e último capítulo, é concluída a dissertação, com também referência para o trabalho futuro. 5 2. ESTADO DE ARTE Para definir com clareza o problema, e obter uma ideia sobre o estado actual do conhecimento sobre o tema, nomeadamente as lacunas em termos de soluções e as contribuições da investigação para o seu desenvolvimento, foram efectuadas várias pesquisadas em diferentes motores de busca, utilizando combinações de palavras-chave como “sistema”, “inspecção”, “ascensor”, “elevador”, “gestão”, “plataforma”, “ system ”, “ inspection ”, “ lift ”, “ elevator ”, “ management ”, “ platform ”. Contudo, não foi encontrada documentação sobre o tema em concreto, mas sim sobre inspecções de outros equipamentos e de plataformas web para outros tipos de gestão, levando à conclusão que este assunto ainda não fora muito estudado (ou não tenha gerado interesse suficiente), apesar da sua importância. 2.1. Ascensores 2.1.1 Evolução Um ascensor é definido como sendo um aparelho electromecânico capaz de conduzir pessoas e/ou cargas de um local para outro, podendo ser na vertical, na horizontal ou mesmo na diagonal, e é de uma extrema importância em edifícios, principalmente os de maior altura, para a locomoção das pessoas. O primeiro ascensor, accionado por uma máquina a vapor, foi inventado por Elisha Otis e entrou em serviço em 1857 em Nova Iorque [7]. Com a construção de grandes arranha-céus, o ascensor teve uma grande evolução, passando por várias modificações até aos dias de hoje. Os EUA e a China são os países onde existem mais ascensores, os EUA tem à volta de 900 mil ascensores [2] e a China uns impressionantes 4 milhões, onde alguns funcionam a uma velocidade de 20,5 m/s (73 km/h) [7]. Em Portugal existem cerca de 140.000 ascensores [7], e a maior percentagem pertence às empresas Otis (USA), Schindler (Suíça) e Thyssenkrupp (Alemanha). Existem ainda as empresas Schmitt (Alemanha), Orona (Espanha), Kone (Finlândia) e as nacionais Pinto & Cruz, Grupnor, Nogueira e Macedo, entre outras. 2.1.2 Legislação Estes equipamentos têm obrigatoriamente de ser instalados segundo o Regulamento Geral de Construções Urbanas (RGEU) [8], em edifícios com uma altura superior a 11,5 metros, e as suas 6 características dependem do tipo de edifício, isto é, se são escritórios, apartamentos, hotéis, hospitais, escolas, etc. Os ascensores são um meio de transporte muito seguro, uma vez que são fabricados respeitando normas de segurança muito exigentes e são sujeitos a manutenções regulares e inspecções periódicas. Qualquer ascensor para poder operar tem de estar em perfeitas condições e com um certificado válido. Para obter o certificado a inspecção tem de ser solicitada 5 anos após a sua instalação e posteriormente de 2 em 2 anos pelo proprietário ou Empresa de Manutenção de Instalações de Elevação (EMIE) à Câmara Municipal ou empresa contratada. No decorrer da inspecção, se não for detectada nenhuma cláusula para reprovação, é emitido um certificado válido pelo período de dois anos, caso contrário, o proprietário ou a EMIE têm 30 dias para efectuar a reparação necessária e solicitar uma reinspeção [9]. De acordo com o Decreto-Lei 320/2002, qualquer ascensor tem de obedecer a várias regras, entre as quais a obrigatoriedade de terem um contracto com uma EMIE, onde esta assume a responsabilidade por deficientes manutenções. As periodicidades das inspecções, antes de decorrida a 2ª inspecção, são as referidas na Tabela 1. Tabela 1 - Periodicidade das Inspecções Ascensores o 2 anos, quando situados em edifícios comerciais ou de prestação de serviços, abertos ao público; o 4 anos, quando situados em edifícios mistos, de habitação e comerciais ou de prestação de serviços; o 4 anos, quando situados em edifícios habitacionais com mais de 32 fogos ou mais de oito pisos; o 6 anos, quando situados em edifícios habitacionais não incluídos no número anterior; o 6 anos, quando situados em estabelecimentos industriais; o 6 anos, nos casos não previstos nos números anteriores. Escada mecânica o 2 anos Monta-cargas o 6 anos Após decorrida a 2ª inspecção a periodicidade das inspecções passa a ser bienal. O Município pode solicitar uma inspecção extraordinária sempre que for comunicado, por qualquer utilizador, o deficiente funcionamento do ascensor, ou falta de segurança. 7 É obrigatória a comunicação de todos os acidentes ocorridos no prazo máximo de 3 dias, após a ocorrência, devendo ser imediata se houver vítimas mortais. No caso de resultarem mortes, ferimentos graves ou prejuízos materiais importantes o ascensor dever ser imobilizado e selado até uma inspecção para relatório técnico e o Município deve enviar à DGE cópia dos inquéritos. Qualquer ascensor que não ofereça as necessárias condições de segurança para o seu funcionamento, o Município pode solicitar que seja feita a selagem do equipamento. Após a selagem, e para que volte a funcionar, tem de ser solicitada uma nova inspecção. As inspecções periódicas das instalações devem ser requeridas no prazo legal, à respectiva câmara municipal e acompanhado do comprovativo do pagamento da taxa associada. A inspecção periódica é efectuada no prazo máximo de 60 dias após o pedido. Caso não seja solicitada a inspecção pode ser aplicada uma coima de € 250 a € 5 000. Compete à EMIE enviar ao proprietário da instalação os elementos necessários, para que este proceda ao pagamento da taxa devida e lhe devolva o respectivo comprovativo. No caso de o proprietário não solicitar o pedido nem devolver à EMIE o comprovativo do pagamento da taxa de inspecção periódica, a empresa deve comunicar o incumprimento à câmara municipal no fim do mês em que a inspecção deveria ter sido requerida. Neste último caso, o proprietário fica sujeito à aplicação das sanções legais e a câmara municipal intimá-lo-á a pagar a respectiva taxa no prazo de 15 dias. Por acordo entre o proprietário da instalação e a EMIE, poderá o pagamento da taxa ser efectuado por esta. Após a realização da inspecção periódica e estando o ascensor nas condições regulamentares, deverá ser emitido o certificado de inspecção periódica pela entidade que efectuou a inspecção, mencionando o mês em que deverá ser solicitada a próxima inspecção, devendo a EMIE afixar o mesmo no ascensor e em local bem visível. O certificado de inspecção periódica obedece ao modelo aprovado por despacho do director-geral da Energia. A entidade inspectora deverá enviar ao proprietário do ascensor um documento da realização da inspecção, com conhecimento à câmara municipal e à EMIE respectiva. Sempre que o ascensor apresente deficiências que colidam com a segurança de pessoas, não pode ser emitido o certificado de inspecção periódica, sendo impostas as cláusulas adequadas ao proprietário ou ao explorador com conhecimento à EMIE, para resolução. Após 30 dias deve ser solicitada uma reinspecção ao ascensor, e emitido o certificado de inspecção periódica se a instalação estiver em condições de segurança. Se houver lugar a mais que uma reinspecção, a responsabilidade do pagamento da respectiva taxa é da EMIE. 8 2.1.3 Processo de Inspecção Na Figura 1 é apresentado um diagrama que explica o processo do serviço de controlo da periodicidade de inspecção de ascensores, com base no Decreto-Lei 320/2002 que visa aprovar as regras quanto à inspecção de ascensores. Figura 1 - Diagrama do serviço de inspecção 9 O serviço inicia-se quando é efectuado um novo pedido referente a um ascensor, pedido este que pode ser:  inspecção periódica;  reinspecção;  selagem;  inspecção extraordinária;  inquérito a acidentes;  peritagem;  relatório;  parecer. O pedido além de ter que ser feito pelo proprietário ou gestor, caso exista, também pode ser feito pela empresa de manutenção do ascensor ou pela Câmara Municipal. Sendo uma inspecção periódica, o pedido tem de ser efectuado até 60 dias antes de terminar a validade. No caso de uma reinspecção, esta tem de ser solicitada no prazo máximo de 30 dias após reprovação. A Câmara Municipal emite uma nota de pagamento com o valor associado ao tipo de pedido. Após confirmado o pagamento, é enviado o respectivo recibo a quem fez o pedido e à empresa de manutenção do ascensor. Importa referir que quando a Câmara Municipal faz um pedido de um ascensor da sua responsabilidade, não é gerada nenhuma nota de pagamento. Em simultâneo a Câmara Municipal reencaminha o pedido para a Entidade Inspectora, que, após recepção procede ao agendamento do serviço, comunicando igualmente à Câmara Municipal, ao proprietário e/ou gestor e à empresa de manutenção do ascensor. Este agendamento tem de ser efectuado até 60 dias após o pedido. Por fim, a Entidade Inspectora efectua o serviço enviando para todas as entidades envolvidas o respectivo relatório e, em caso de aprovação, o certificado. 2.2 Plataformas web para gestão de serviços As plataformas web para gestão de serviços são usadas em qualquer área de negócios, como:  Na agricultura – por exemplo o CLUeFARM [10], onde os serviços são integrados permitindo a partilha de informação entre os agricultores;  Na área social – no apoio aos idosos [11];  Na saúde – na gestão do estado e relatórios da inspecção de dispositivos médicos [12]; 16 Tabela 2 - Prós e contras das frameworks front-end React Vue Angular Prós Componentes reutilizáveis Arquitectura baseada em componentes Simples Fácil integração Desempenho do servidor MVC integrado Fluxo de dados OneDirection MVC integrado Fácil de aprender Sintaxe simples Vinculação de dados bidireccional Tamanho pequeno Virtual DOM Integração de terceiros Muita documentação Melhoria contínua Grande comunidade Fácil integração Contras Difícil de aprender Pequena comunidade Uso do Typescript Muito complexo Emprego limitado Pesado Pouca documentação Migração difícil Mudanças rápidas Difícil de aprender Tipicamente, as frameworks front-end seguem arquitecturas como por exemplo, o Model-View View-Model (MVVM ) ou o Model-View-Controller ( MVC ) . O MVVM, criado em 2005, por John Gossman [29], é um padrão de arquitectura que realça a separação de interesses, por forma a permitir a separação da lógica da interface do utilizador da lógica do back-end , mantendo assim o código da interface do utilizador simples e livre da lógica da aplicação para facilitar a sua gestão. O MVVM , (Figura 7), separa três camadas distintas: o Model, a lógica do backend , o ViewMode, que permite a interacção com o Model e a View , que recebe os dados de forma a possibilitar a actualização dos elementos da interface do utilizador (UI) [29]. Figura 7 - Esquema MVVM O MVC [30] é a arquitectura de desenvolvimento mais usada na maior parte das tecnologias web [12][13], e separa a aplicação em três camadas distintas, conforme Figura 8.A camada de interacção com o utilizador (view) , a manipulação de dados (model) e a camada de controlo (controller) . O model representa os dados, as regras aplicadas a esses dados e ajuda a reduzir a complexidade do código que 17 o programador precisa de escrever. A view gere toda a parte gráfica e o controller processa e responde a eventos [31]. Figura 8 - Esquema MVC 2.3.4 Back-end de aplicações web No desenvolvimento back-end , onde são implementados os serviços da plataforma, são escolhidas tecnologias como o Java, por ser uma linguagem de programação bastante utilizada para aplicações cliente-servidor [10], no entanto, os novos projectos assentam mais em JS/node e Phyton. A Figura 9 ilustra a arquitectura do modelo cliente-servidor. Figura 9 - Modelo cliente-servidor Neste modelo, o cliente faz um pedido a um servidor que fornece a resposta. Nas aplicações web, os clientes e servidores usam a troca de mensagens HTTP para comunicarem. Na implementação de serviços web existem dois protocolos de comunicação principais, SOAP e REST [32]. O Simple Object Access Protocol (SOAP), fornece uma forma de comunicação através do método HTTP POST, com mensagens standard de XML, entre aplicações que são executadas em diferentes sistemas operativos, com tecnologias e linguagens de programação distintas. Os serviços são descritos formalmente, ou seja, de forma bem definida e normalizada, o que permite geração de código de middleware . Já o protocolo REST, usa o método HTTP com regras (utiliza os métodos GET, POST, PUT e DELETE) e mensagens em qualquer formato, tipicamente JSON. O modelo cliente-servidor encontra o seu expoente máximo nas arquitecturas orientadas a serviços (SOA), divisão da aplicação em múltiplos serviços isolados e que falam entre si [33], devido ao 18 seu bom desempenho e à sua flexibilidade, e por ser utilizada no desenvolvimento de tecnologias como a Cloud Computing (CC) e a Internet das Coisas (IoT) [34]. Existe uma vasta gama de tecnologias que pode ser usada para o seu desenvolvimento, algumas apresentadas na Figura 10, tais como o Apache e o Nginx, servidores HTTP, o MySQL, o MongoDB e o PostgreSQL, sistemas de gestão de base de dados. O Node.js como ambiente de execução server-side , as frameworks Django e Flask, Express, Angular e React, Ruby on Rails e Laravel, e as respectivas linguagens, Python, Javascript, Ruby e PHP. Figura 10 - Ferramentas back-end Como se pode observar na Figura 11, e com base no site Intagleo [27], as frameworks back-end mais populares são: Laravel, Flask e Django . Figura 11 - Principais frameworks back-end 19 A Laravel é uma framework de back-end para PHP [35], com uma boa sintaxe, capacidade de acomodar grandes equipas e com ferramentas modernas. Segue o padrão do modelo de arquitectura MVC [36], facilita o desenvolvimento back-end , inclui o seu próprio sistema de migração de banco de dados e possui um ecossistema robusto. A Flask é outra estrutura de back-end para Python [35], no entanto é mais leve e mais adequada para o desenvolvimento de projectos mais pequenos. Possui um conjunto de ferramentas integradas e oferece suporte para recursos como modelos Jinja2, cookies seguros, testes de unidade e despacho de solicitação RESTful [36]. Além disso fornece documentação extensa e é uma óptima solução para programadores Python. A Django é uma framework de desenvolvimento rápida para web , também para Python [36] , open-source e utiliza o padrão de projecto próprio denominado Model Template View ( MTV ) [36], semelhante ao Model View Controller ( MVC ) , separando as responsabilidades da aplicação em camadas, aumentando a legibilidade do código e organização da aplicação. É muito recomendada para o desenvolvimento de projectos mais profissionais e complexos e possui um grande conjunto de ferramentas que facilita a criação de aplicações. O Node.js é um ambiente de execução JavaScript que funciona do lado do servidor e permite aos programadores o desenvolvimento de aplicações em rede, em tempo real e de alta escalabilidade, de uma forma simples e rápida, não dependendo de um browser para a execução. O uso de Node.js trás grandes vantagens como a flexibilidade, a leveza e a produtividade [20]. As linguagens de programação de alto nível mais usadas são o Python, o JavaScript e o PHP. O Python é uma linguagem de programação interpretada, orientada a objectos, funcional, imperativa e de script [20]. Esta linguagem tem vindo a crescer, sendo a 3ª mais utilizada, após o JavaScript. O JavaScript é, hoje em dia, a linguagem mais popular a nível mundial e é projectado tanto para o desenvolvimento front-end como para o back-end , sendo usada na construção de aplicações desktop e móveis [21]. 2.3.5 Aplicações móveis O desenvolvimento móvel pode ser feito para as plataformas Android, iOS ou Windows Phone. Actualmente existem várias opções para o desenvolvimento de aplicações como por exemplo o Java para Android nativo, Objective-C para iOS, e frameworks multiplataforma como o Xamarin e Cordova, entre outras. As aplicações podem ser nativas ou híbridas. 20 Aplicações Nativas As aplicações nativas são desenvolvidas apenas para um sistema móvel específico (e.g., Android), e utilizam linguagens de programação específicas (e.g., Java), oferecendo uma experiência de utilização optimizada do dispositivo. Aplicações Híbridas O desenvolvimento de aplicações híbridas utiliza maioritariamente tecnologias web , como o HTML5, JavaScript, e CSS, e recorrem ao uso de frameworks que abstraem a plataforma, como o React Native, Ionic ou Xamarim, permitindo que o produto final seja utilizado quer num telemóvel Android, iOS ou Windows. O ciclo de desenvolvimento é bastante mais curto e mais barato. Para o utilizador final é invisível que uma aplicação seja desenvolvida com uma destas tecnologias. A Tabela 3 apresenta as vantagens de desenvolver uma aplicação móvel em ambiente nativo e em ambiente híbrido. Tabela 3 - Aplicações Híbridas vs. Aplicações Nativa Aplicações Híbridas Aplicações Nativas Mais barato para desenvolver Melhor experiência para o utilizador final Maior alvo do mercado. Acesso directo a características e serviços via API Facilidade na criação de protótipos. Produto mais preciso para um mercado único Acesso à maior parte das livrarias JavaScript . Mais fácil encontrar erros Facilidade para programadores provenientes de programação web . Utilização de IDE nativo Multiplataforma (Android, IOS, Windows Phone). Documentação e comunidade maior. Menor performance Melhor performance 2.3.6 Funcionalidades O desenvolvimento de aplicações web inclui funcionalidades essenciais como por exemplo o processo de login, e o envio de e-mail. Existem várias soluções a nível dos mecanismos de autenticação, contudo uma das mais usadas é o Passport , um middleware de autenticação para Node.js [20]. Este mecanismo é muito flexível e modular e possui várias estratégias de autenticação como o nome e password, Facebook, Twitter, Google, 21 entre outras. Para a sua utilização é necessário instalar dependências, configurar a aplicação e os dados de acesso à base de dados e configurar o gestor de base de dados MySQ L [20] . O envio de e-mails é uma tarefa essencial em aplicações web. A utilização do e-mail do Node.js é simples, sendo necessário o uso de módulos cuja combinação permita o envio de e-mails através de servidores Simple Mail Transfer Protocol (SMTP) [10][21]. Quando numa plataforma web existem vários tipos de utilizadores, as permissões são geridas de acordo com a sua categoria, e é muito usado o Identity Access Management (IAM ) , uma vez que é simples, seguro e produtivo [22], e permite a sincronização com a base de dados (MySQL). Quanto ao tratamento das restrições de acesso aos dados pode ser feito através do eXtensible Access Control Markup Language ( XACML ) utilizando ainda uma linguagem de política ABAC [11]. 22 3. ANÁLISE E CONCEPÇÃO Este capítulo faz a análise e concepção da plataforma web . São identificados todos os requisitos fundamentais, as permissões de cada tipo de utilizador e os casos de uso. São ainda apresentados o modelo de dados, a arquitectura e os mockups da plataforma. Importa referir que apesar do sistema ser concebido como integrando uma aplicação móvel, no âmbito desta dissertação apenas foi desenvolvida uma aplicação web . 3.1 Requisitos Os requisitos descrevem as funcionalidades pretendidas para a plataforma web . Na Tabela 4 são descritos os requisitos funcionais (RF) e na Tabela 5 os requisitos não funcionais (RNF), tendo por referência o Decreto-Lei 320/2002 que visa aprovar as regras quanto à inspecção de ascensores e a perícia em todo o processo. Os requisitos não funcionais são apenas orientadores das preocupações de concepção e implementação, são colocados de forma qualitativa e não para serem verificados através de testes. Tabela 4 - Requisitos funcionais da plataforma Requisito Designação Descrição RF1 Autenticação/ Login O acesso à plataforma requer autenticação, sem isso é necessário criar uma nova conta. Há ainda a possibilidade de recuperar os dados de acesso. Como é uma plataforma que envolve várias entidades, de gestão da Câmara Municipal, não existe a possibilidade de criar registo. A criação é feita pelo administrador ou validada aquando da comunicação de um ascensor onde é comunicado um novo utilizador. RF1.1 (Des)bloquear conta Na eventualidade da conta ser acedida indevidamente ou na tentativa falhada de aceder 3 vezes, a conta é bloqueada por segurança, podendo ser desbloqueada apenas pela Câmara Municipal, o administrador. RF1.2 Multi-utilizador Suportar os tipos de utilizador Município, EI, EMIE, Proprietário e Gestor, proporcionando-lhe a cada tipo as funcionalidades úteis com permissões adequadas. RF2 Gestão de conta 23 RF2.1 Consultar dados da conta Visualizar todos os dados do utilizador. Podem ainda ser alterados os dados pessoais e de acesso, associar a conta às redes sociais e o tratamento dos dados pessoais, de acordo com a lei de protecção de dados. É possível ainda alterar a password . RF2.2 Delegar utilizador Um utilizador pode criar uma conta para outro utilizador, com as mesmas permissões. RF3 Alertas e mensagens Para garantir o funcionamento do serviço, é enviado de forma automática um alerta inicial com 2 meses de antecedência sobre a caducidade do ascensor. Enquanto a inspecção periódica não for solicitada, a cada 15 dias é enviado novo alerta. No caso de uma reprovação, é enviado um alerta para ser solicitada uma reinspeção no prazo de 30 dias. Sempre que houver alguma actualização no historial do ascensor, seja, um pagamento, um agendamento ou o resultado da inspecção, é enviado uma mensagem. Tantos os alertas como as mensagens, são enviados para o e-mail . RF3.1 Caixa de mensagens Todas as mensagens recebidas são guardadas durante um ano, ou até o utilizador eliminar. Podem ser enviadas novas mensagens. RF4 Gestão de ascensores RF4.1 Inserir/comunicar novo ascensor O utilizador deve, sempre que seja instalado um novo ascensor, comunicar a sua existência, bem como todos os dados e documentos importantes. Após comunicação a Câmara Municipal valida o ascensor e disponibiliza o acesso. RF4.2 Fornecer resumo sobre todos os ascensores Listagem dos ascensores associados a cada utilizador, por exemplo o proprietário vê os seus, a CM vê todos. Na listagem um resumo com os dados mais importantes de cada elevador: número identificativo do equipamento, a situação actual (aprovado, reprovado ou selado), a sua localização, empresa de manutenção e validade do certificado. RF4.3 Consultar dados de um ascensor Toda a informação sobre cada elevador, além dos do resumo: georreferenciação, características de equipamento, tipo de edifício, documentos. Todos os 24 dados apenas podem ser alterados pela Câmara Municipal. RF4.3.1 Declinar a responsabilidade Quando o ascensor já não está à responsabilidade do proprietário ou da empresa de manutenção, devem comunicar a declinação. Sendo actualizado pela Câmara Municipal. RF4.3.1 Assumir a responsabilidade Quando o gestor ou empresa de manutenção assume responsabilidade de um ascensor, pode fazê-lo através do código de portabilidade do ascensor gerado aquando da sua criação. RF5 Gestão de pedidos RF5.1 Listar pedidos Listagem de todos os pedidos de inspecção periódica associados ao utilizador. RF5.2 Inserção de novo pedido O proprietário ou empresa de manutenção pode solicitar uma nova inspecção periódica, reinspeção, selagem, inspecção extraordinária, inquérito a acidentes, peritagem, relatório ou parecer, estes últimos 4 apenas podem ser solicitados pela Câmara Municipal. A inspecção tem de ser solicitada antes 60 dias de terminar a licença e a reinspecção 30 dias após reprovação. RF5.2.1 Pagamento Após efectuado o pedido é gerado uma nota de pagamento. O recibo é enviado para quem fez o pedido e para a empresa de manutenção. RF6 Gestão de inspecções RF6.1 Agendamento Após o pagamento, o pedido é enviado para a entidade inspectora para proceder à marcação da mesma. A EI tem de efectuar a inspecção no prazo máximo de 60 dias. Esta informação permanece até à inspecção. O agendamento pode ser alterado pela entidade inspectora. RF6.2 Inspecção A entidade inspectora efectua o serviço conforme agendamento. RF6.3 Resultado Executada a inspecção, a entidade inspectora actualiza a situação do ascensor, isto é, aprovado, reprovado, selado, bem como a submissão do relatório e do certificado, no caso de aprovação. Quando a entidade 25 inspectora insere o resultado, os documentos são armazenados, ficando associados ao serviço. Tabela 5 - Requisitos não funcionais da plataforma Requisito Designação Descrição RNF1 Desempenho Boa rapidez de reposta às acções do utilizador. RNF2 Fiabilidade Prevenir/reduzir a saturação de comunicações, limites de dados, etc. Suportar um elevado número de sessões em simultâneo. RNF3 Segurança Proporcionar um nível de segurança e privacidade adequados. RNF4 Eficiência Consumo de poucos recursos. RNF5 Usabilidade Fácil utilização. Eficiência das tarefas. O sistema deve ser claro nas mensagens apresentadas ao utilizador. A apresentação deve ser agradável e adequada ao utilizador. RNF6 Aplicações cliente Multiplataforma Compatível com dispositivos móveis. 3.2 Mapa de Funcionalidades Cada tipo de utilizador tem acesso a diferentes funcionalidades com diferentes permissões, conforme descrito na Tabela 6. Importa realçar que para as funcionalidades descritas na Tabela 4 não listadas na Tabela 6, o acesso é total para todos os tipos de utilizadores. Tomando como exemplo a funcionalidade de consulta de ascensor, o Município tem permissão para visualizar todos os ascensores, enquanto a EMIE, o Proprietário e o Gestor apenas visualizam os ascensores em que têm responsabilidades. Já a EI só tem acesso aos ascensores que têm um pedido por finalizar. Tabela 6 - Permissões Município EI EMIE Proprietário Gestor Criar ascensor Comunicar ascensor 32 Como é representado na Figura 18 cada utilizador tem acesso ao seu perfil. Nesta página o utilizador autenticado pode editar alguma informação, bem como alterar a password de acesso. Figura 18 - Mockup da Plataforma web : Perfil Por fim, o utilizador tem à sua disposição uma página de mensagens, Figura 19, onde é possível visualizar todas notificações do ciclo do pedido de um serviço. Figura 19 - Mockup da Plataforma web : Mensagens 33 3.6 Modelo de Dados O modelo de dados identifica e relaciona toda a informação da plataforma. O modelo ER representado na Figura 20 e Figura 21 permite visualizar e interpretar as relações existentes entre as várias estruturas de dados. Segue uma breve descrição das principais entidades: Ascensores – Armazena todos os dados dos ascensores: nº do ascensor, código de portabilidade, titular/proprietário, gestor, rua, nº de porta/bloco, freguesia, código postal, tipo de edifício, nº de pisos, estado, data de instalação, tipo, carga, nº máximo de pessoas a transportar, instalador, empresa de manutenção, data da última inspecção, validade, características e observações. Esta tabela faz ligação com a tabela “Pedidos” para que fique registado todo o histórico dos pedidos efectuados a um determinado ascensor, porque cada ascensor pode ter vários pedidos tendo em conta o seu estado, contudo um pedido é referente apenas a um ascensor. Users – Guarda os dados pessoais dos utilizadores da plataforma, com destaque para o campo que identifica o tipo de utilizador, nomeadamente a Câmara Municipal (administrador), Câmara Municipal (tesoureiro), proprietário, gestor, empresa de manutenção de instalações de elevação e entidade inspectora. Além disso, contém os outros dados mais habituais: nome, morada, números de telefone/telemóvel, e-mail, website , NIF e password encriptada. Pedidos – Armazena o pedido associado a um ascensor; nº do pedido, nº do ascensor, proprietário, EMIE, tipo de pedido e EI. O pedido pode dar origem a uma nota de pagamento. Faz ligação com "Notas de pagamento", uma vez que vários pedidos podem ter uma nota de pagamento em comum. Notas de pagamento – Armazena os dados referentes ao pagamento do pedido de inspecção do ascensor: nº da nota de pagamento, nº do pedido, valor, dados de pagamento, prazo. Após o pagamento dará origem ao recibo. Recibos – Armazena os dados do pagamento já efectuado: nº do recibo, n.º da nota de pagamento, data de pagamento e data de emissão. 34 Notificações – São guardados os dados relativos a todos os tipos de alertas associados a um ascensor: nº da notificação, tipo de notificação e nº do ascensor. Agendamentos – Armazena os dados quando é efectuada uma marcação de uma inspecção de um ascensor por parte da EI: nº do agendamento, nº do pedido, data e hora de marcação, e nome do técnico. Inspecções – Armazena os dados do resultado da inspecção de um determinado ascensor, como o resultado: nº do agendamento e resultado. Files – Armazena a informação de ficheiros PDF: tipo, (pedido, pagamento, factura, relatório, outros e dados de pagamento), nome e caminho onde foi guardado, para ser mais fácil visualizar o documento. Figura 20 - Modelo ER dos dados (parte 1) 35 Figura 21 - Modelo ER dos dados (parte 2) 3.7 Arquitectura As tecnologias escolhidas para implementar a plataforma web estão na Figura 22, tanto para o servidor como para o navegador. Figura 22 - Arquitectura A plataforma denomina-se “InspAscensores”, e para a parte web foi escolhida a stack MEVN: MySQL, Express.js, Vue.js e Node.js. 36 No lado do frontend, responsável por disponibilizar ao utilizador toda a informação e funcionalidades essenciais para o processo, bem como as páginas a apresentar, já identificadas e desenhadas, a escolha recaiu sobre Vue.js em conjunto com o Vuetify, uma vez que apresenta uma estrutura bastante intuitiva, e bastante simples em comparação com outras framework de front-end para aplicações de grande escala. Por ser uma framework bastante fácil de estudar e aprender, com a possibilidade de migração de projectos ou libraries existentes de uma forma fácil, e estimula o desenvolvimento de um código limpo, de leitura fácil e rápida leitura, a escolha compensou, porque o tempo que é gasto no estudo das especificidades de uma framework pode acabar por adiar o desenvolvimento da aplicação. A librarie escolhida para permitir a comunicação HTTP foi a Axios. Para disponibilizar uma visualização georreferenciada dos ascensores foi utilizada a interface GoogleAPIs e para garantir o pagamento associado aos pedidos foi integrado o gateway de pagamento PayPal. No lado do back-end , a camada do servidor, foi utilizada a framework Node.js. A escolha pelo Node.js justifica-se por ser um ambiente de execução em código aberto para programação em linguagem JavaScript, e permite usar a mesma linguagem. Além disso o Node.js tem crescido rapidamente nos últimos anos e é uma framework muito fácil para iniciantes no desenvolvimento web , com muitos tutorias e uma grande comunidade. Proporciona uma vasta escalabilidade para aplicações, é muito rápido e muito eficiente, possui um grande conjunto de pacotes open-source e permite criar sites SaaS, aplicações desktop e aplicações móveis. Por forma a gerir a interface REST para que os pedidos provenientes do navegador sejam processados pelo servidor foi usada a framework Express. O papel do serviço REST é basicamente fazer a interface à base de dados e gerir ficheiros, ficando do lado do cliente a lógica de funcionamento e naturalmente a interface com o utilizador. Por forma a permitir a manipulação de ficheiros usou-se o middleware multer. Ainda do lado do servidor, e para armazenar os dados, foi usado o MySQL, uma vez que, conforme já explicado no capítulo anterior, é uma base de dados relacional e open-source . 37 4. IMPLEMENTAÇÃO Devido à dimensão do sistema projectado a aplicação móvel ficou fora da implementação no âmbito deste trabalho. Por isso, neste capítulo apenas se descreve a implementação da aplicação web . São descritos neste capítulo a finalidade e o funcionamento dos vários elementos que compõem o back-end e o front-end , com uma maior incidência no front-end , dado que é composto por vários processos e técnicas, ao contrário do back-end , que acaba por ser mais repetitivo. 4.1 Requisitos Desenvolvidos Na tabela 7 são apresentadas as funcionalidades que foram desenvolvidas, tendo por base as funcionalidades definidas no capítulo anterior. Tabela 7 - Requisitos desenvolvidos Requisito Designação Desenvolvido RF1 Autenticação/Login Sim RF1.1 (Des)bloquear conta Sim RF2 Gestão de conta RF2.1 Consultar dados da conta Sim RF2.2 Delegar utilizador Não RF3 Alertas e mensagens Sim/Não RF3.1 Caixa de mensagens Não RF4 Gestão de ascensores RF4.1 Inserir/comunicar novo ascensor Sim RF4.2 Fornecer resumo sobre todos os ascensores Sim RF4.3 Consultar dados de um ascensor Sim RF4.3.1 Declinar a responsabilidade Sim RF4.3.1 Assumir a responsabilidade Sim RF5 Gestão de pedidos RF5.1 Listar pedidos Sim RF5.2 Inserção de novo pedido Sim RF5.2.1 Pagamento Sim 38 RF6 Gestão de inspecções RF6.1 Agendamento Sim RF6.2 Inspecção Sim RF6.3 Resultado Sim 4.2 Back-end Neste subcapítulo é descrito o back-end da aplicação, nomeadamente a base de dados, a API web fornecida e os componentes que implementam a API e manipulam a BD. 4.2.1 Base de Dados A definição da BD foi feita com o MySQL Workbench, através da linguagem SQL, respeitando o modelo de dados definido no capítulo anterior, com acréscimos de algumas variáveis e a concretização do tipo e tamanho das variáveis necessários à definição da BD, como por exemplo aumentar o tamanho da variável da descrição na tabela freguesias, ou mesmo diminuir o tamanho da variável codPostal por ser de tamanho fixo. Os diagramas apresentados na Figura 23 e Figura 24 permitem ter uma visão da estrutura geral da base de dados, identificando as entidades envolvidas, os respectivos atributos, e as relações entre entidades. Todos os campos de texto foram definidos como VARCHAR, diferindo apenas na quantidade de caracteres, de acordo com o conteúdo da variável. Já os campos com datas foram definidos como DATE. As entidades com variáveis pré-definidas, como estados, tiposEdificio, tiposAscensor, tiposUser e tiposPedido, foram definidas como ENUM, por forma a garantir que os valores utilizados são válidos. Os ficheiros são guardados em pastas específicas, sendo o caminho e o tipo de ficheiro guardados na tabela files para evitar que a BD fique sobrecarregada com dados BLOB. Nesta fase não foi tido em conta a forma como seria efectuada a manutenção da base de dados, sendo previsto a sua execução em trabalho futuro. 39 Figura 23 - Modelo ER da base de dados (parte 1) Figura 24 - Modelo ER da base de dados (parte 2) 40 4.2.2 API web Nas tabelas seguintes são apresentados, por tipo de recurso, as diferentes rotas e os caminhos dos pedidos suportados pela API web , bem como o tipo de acesso necessário, a acção/resposta e os dados do pedido. Na coluna com os dados do pedido, em vários casos os campos não são detalhados, porque correspondem aos campos da tabela da base de dados correspondente ao recurso. A execução das operações CRUD na BD foram feitas através de queries em SQL, sendo utilizado o método query(). Na Tabela 8, é possível verificar as diferentes rotas associadas aos utilizadores, desde a criação, visualização, edição e eliminação da conta, até à autenticação e recuperação da conta. É importante referir que os utilizadores que são proprietários, gestores ou EMIE, só têm acesso à lista de todos os utilizadores aquando a comunicação de um ascensor. Após uma autenticação bem-sucedida é enviado uma resposta com os dados do nome, e-mail e o token de acesso, bem como o tipo de utilizador que é utilizado no front-end para filtrar e controlar o acesso a determinadas páginas e funcionalidades, libertando assim o servidor desse papel. Tabela 8 - Tabela URI – Users Método HTTP URI Tipo de Acesso Dados do pedido Acção/Resposta POST …/users Admin Campos da conta Conta criada GET Público Listar todos PUT …/users/:id Privado Campos da conta Conta actualizada GET Público Listar um DELETE Admin Conta eliminada POST …/users/auth Público E-mail e password Token da sessão POST …/users/accountRec Privado E-mail Código de recuperação enviado para o e-mail POST …/users/validate E-mail e código de recuperação Conta validada POST …/users/updatePass E-mail e password Password actualizada POST …/users/editPass Password antiga e nova password PUT …/users/bloq/:id Admin Conta (des)bloqueada Na Tabela 9, estão as rotas usadas no que diz respeito aos ascensores. Por forma a não sobrecarregar o front-end foi criada uma rota para listar apenas os ascensores cuja validade está prestes a terminar. 41 Tabela 9 - Tabela URI – Ascensores Método HTTP URI Tipo de Acesso Dados do pedido Acção/Resposta POST …/ascensores Privado Campos do ascensor Ascensor comunicado/criado GET Privado Listar todos PUT …/ascensores/:id Admin Campos do ascensor Ascensor actualizado GET Público Listar um DELETE Admin Ascensor eliminado GET …/ascensores/prazo Privado Listar ascensores com validade a expirar PUT …/ascensores/declin/:id Privado Responsabilidade declinada PUT …/ascensores/assum Privado n.º do ascensor e código de portabilidade Responsabilidade assumida Quanto aos pedidos, as rotas que foram definidas de acordo com a Tabela 10. Na rota para um novo pedido, pode ser criado apenas um pedido, ou vários pedidos, pelo que é recebido um objecto de arrays . Tabela 10 - Tabela URI – Pedidos Método HTTP URI Tipo de Acesso Dados do Pedido Acção/Resposta POST …/pedidos Privado Id do ascensor e tipo de serviço Pedido criado GET Privado Listar todos pedidos PUT …/pedidos/:id Admin Campos do pedido Pedido actualizado DELETE Admin Pedido eliminado Não foi utilizada a rota para criar notas de pagamento, uma vez que essa operação apenas é realizada aquando a criação do pedido. Foi tomada esta decisão, porque podem haver vários pedidos onde é gerado apenas uma nota de crédito, daí ser implementado juntamente com o pedido, não havendo necessidade de criar uma rota. A desvantagem desta decisão é a falta de flexibilidade desta operação, dado que numa possível actualização poderá haver necessidade de criar uma funcionalidade específica para criar notas de pagamento, pelo tesoureiro. 48 a password está correcta, bem como verificar se o utilizador está activo. De seguida, caso o e-mail exista, mas a password não esteja correcta e a conta do utilizador esteja activa, é feita uma nova consulta à BD, agora usando o UPDATE, onde irá actualizar o n.º de tentativas de acesso e bloquear a conta, no caso de 3 tentativas seguidas de autenticação falhadas. Se as credenciais estiverem correctas e a conta activa, é efectuado o login , enviando um token de acesso, contudo, se a conta já estiver bloqueada e mesmo que as credenciais estejam correctas, não é possível efectuar o login . Figura 28 - Diagrama de actividade UML do comportamento da função do back-end : Login Criar/comunicar ascensor Na funcionalidade de criar ou comunicar um ascensor, representada na Figura 29, são feitas várias consultas à BD, da mesma forma, usando a função query(). Contudo, quando é comunicado ou inserido um ascensor em que também é comunicado ou inserido novos utilizadores, seja proprietário, gestor, ou EMIE, é criado um novo ascensor e novos utilizadores nas tabelas “Ascensores” e “Users”, respectivamente, usando o INSERT. No caso de ser feita uma comunicação de um ascensor, seja por parte de um proprietário, gestor ou EMIE, o processo fica sujeito a validação do administrador, o mesmo acontece com a comunicação 49 de um novo utilizador. Após a validação do administrador, é atribuído o número do processo do ascensor, ficando visível e enviando um e-mail aos utilizadores associados. No que diz respeito à validação de novos utilizadores, e após a validação, é enviado um e-mail com os dados de acesso, à semelhança do procedimento da criação de um utilizador. Quando é feita a validação por parte do administrador é feito um UPDATE do que foi comunicado nas tabelas “Ascensores” e “Users”, ou no caso de, por algum motivo, não for validado, os registos são eliminados através do DELETE. Figura 29 - Diagrama de actividade UML do comportamento da função do back-end: Novo Ascensor 50 Novo pedido Quanto à funcionalidade para efectuar um novo pedido, Figura 30, são feitas várias consultas à base de dados. Primeiramente, e se estiver sujeito a pagamento, é criado um novo registo na tabela “Notas de pagamento” e um novo pedido na tabela “Pedidos”, através do INSERT, de seguida é actualizado o estado do ascensor através do UPDATE à tabela “Ascensores” e enviado e-mail aos utilizadores associados ao ascensor. Caso não haja lugar a pagamento não é criado nenhuma nota de pagamento. No caso do pedido ser para vários ascensores, é criado apenas uma nota de pagamento, se houver pagamento, e são criados vários pedidos, uma vez que são equipamentos diferentes e podem ter agendamentos e resultados diferentes. Figura 30 - Diagrama de actividade UML do comportamento da função do back-end: Novo Pedido 51 4.3 Front-end Neste capítulo são descritos os componentes que compõem o front-end , de modo a demonstrar como funcionam. No desenvolvimento do front-end , foi utilizada a library Vuetify. Além de ser a library de componentes mais usada no Vue.js, o Vuetify disponibiliza aos programadores tudo o que é necessário para criar aplicações, oferecendo elementos fáceis de utilizar e com design moderno, uma vez que usa a especificação Material Design, a linguagem gráfica desenvolvida pela Google. 4.3.1 Estrutura Estrutura lógica Na Figura 31 está apresentada a estrutura lógica no lado do cliente com todos os componentes, instâncias Vue reutilizáveis, com os serviços e outros artefactos associados, separados por pastas para ajudar a compreender a relação entre eles: conta, users, mapa, pedidos, ascensores, inspeccoes, notasPagamento e generalViews. No topo desta estrutura está a App.vue, que é responsável por iniciar a aplicação. Os serviços router.js e store.js têm a funcionalidade de gestão/manipulação de rotas e armazenamento local de dados, respectivamente. Todos os componentes, com excepção dos que estão associados às pastas generalViews e services, têm uma ligação directa com o router.js e a store.js, uma vez que todos usam dados guardados na memória para filtrar as restrições de acesso e usam as rotas para transição entre páginas. Os componentes da pasta generalViews importam os serviços da pasta services e apenas são usados pelos componentes das pastas ascensores, inspeccoes e notasPagamento. Além de não ser visível na estrutura lógica, os componentes da pasta ascensores também importam o componentePaypal.vue, para ser efectuado o pagamento relacionado com o pedido. Os componentes GetFiles.vue e UploadFiles.vue, que importam os serviços GetFilesService.js e UploadFilesService.js, respectivamente, apenas são importados pelos componentes das pastas notas de pagamento e inspecções. Os componentes da pasta inspecções importam ainda a view Calendar.vue. Por forma a fazer pedidos HTTP, foi usada a Axios, uma library JavaScript muito popular pela sua sintaxe simples, pela sua execução rápida, e pelos seus recursos para lidar com erros. 52 Para se conseguir visualizar e manipular coordenadas geográficas num mapa de navegação, recorreu-se ao vue2-google-maps, um módulo npm que associado à conta Gmail e após gerar uma chave de API do Google Maps, todo o processo foi possível. Por último e por forma a simular os pagamentos dos serviços, foi usado um outro módulo npm, vue-paypal-checkout, que através da criação de uma conta na PayPal Developer Dashboard, tornou possível simular os pagamentos, usando contas e pagamentos fictícios. Figura 31 - Estrutura Lógica Estrutura física No Vue.js tanto a parte da interface, template , como do comportamento do componente, script , e da estilização, style , estão reunidas todas no mesmo ficheiro, mas separados de uma forma bastante organizada, por tags : <template>, <script> e <style>, sendo uma das mais notáveis qualidades do Vue.js. Conforme demonstrado na Figura 32, a organização dos ficheiros foi feita da seguinte forma:  public A template index.html faz o processamento de uma forma global de todos os componentes do projecto.  assets A subpasta assets contém todo o conteúdo estático da aplicação presente em todas as sessões dos utilizadores como logotipos e imagens fixas, associados à plataforma.  views Dentro da pasta views foram criadas pastas por tipo de funcionalidades (ascensores, conta, inspecções, mapa, notasPagamento, pedidos e users), em que cada uma delas contém os componentes relacionados.  generalViews Já a pasta generalViews, contém as views que estão associadas às views anteriormente indicadas. 53  http-common.js É responsável pela inicialização da Axios com HTTP base URLe cabeçalhos.  main.js  router.js Contém todas as rotas definidas para os componentes, de modo a ser atribuído um caminho único através do vue-router.  store.js Contém os dados guardados na memória do front-end aquando da autenticação ou recuperação da conta, nomeadamente o número de identificação, o e-mail e o tipo de utilizador. Figura 32 - Árvore de pastas e ficheiros: Front-end 4.3.2 Comportamento Com o desenvolvimento do front-end foi cumprido com o que era proposto. Foi verificado o cumprimento de todos os requisitos, sendo feita a correcta ligação com o back-end . Foram desenvolvidas as páginas essenciais da plataforma InspAscensores e por tipos de utilizadores, desde a autenticação, a gestão da conta, a visualização, edição, criação/comunicação e eliminação de ascensores e utilizadores, verificação da recepção de alertas de expiração da validade dos ascensores, realização de novos pedidos, pagamentos, agendamentos e inserir o resultado. Foi ainda desenvolvida a página de visualização de georreferenciação dos ascensores e a manipulação de ficheiros na plataforma. 54 De seguida são apresentados três comportamentos, à semelhança do back-end . Autenticação/ Login Sempre que um utilizador, após ter recebido o convite do administrador, aceda pela primeira vez à aplicação InspAscensores, deverá introduzir o seu e-mail e a password enviada pelo administrador, sendo o login validado através do POST (…/users/auth), podendo proceder à sua alteração. Caso o utilizador tenha esquecido da password , poderá recuperar, POST (…/users/accountRec), sendo enviado um código para o e-mail que terá de introduzir, juntamente com o e-mail , na plataforma. De seguida é convidado a definir uma nova password . O fluxograma de autenticação pode ser visualizado na Figura 33. Figura 33 - Diagrama de actividade UML do comportamento da função do front-end: Login 55 Criar/comunicar ascensor Na plataforma InspAscensores, os proprietários, os gestores e as EMIE podem comunicar um novo ascensor, fluxograma na Figura 34. O administrador tem a permissão de criar ascensores e validar as comunicações. Figura 34 - Diagrama de actividade UML do comportamento da função do front-end: Novo ascensor 56 Tanto para criar como comunicar um ascensor é feito por etapas. Primeiro os dados do proprietário, a seguir do gestor, caso tenha, depois os dados da EMIE e por último os dados do ascensor. Os dados de uma das etapas das entidades são previamente preenchidos dependendo do tipo de utilizador que estiver autenticado, sem possibilidade de editar, as restantes entidades podem ser inseridas através da selecção de utilizadores existentes visíveis através do GET (…/users) ou comunicar uma nova entidade. Quando é comunicado ou inserido uma nova entidade é verificado se o NIF e o e-mail já existem, salvaguardando a duplicação de utilizadores. Só é possível avançar para a próxima etapa se os dados forem válidos. Na etapa dos dados do ascensor, é automaticamente preenchido os dados do proprietário, gestor e EMIE, baseado nas etapas anteriores, e só é possível concluir a comunicação ou criação se os dados estiverem preenchidos e válidos, POST (…/ascensores). Novo pedido Após o utilizador aceder à plataforma, pode visualizar a lista total dos seus ascensores, ou um em particular, e dependendo do estado e validade do ascensor, o utilizador pode solicitar novo pedido, a partir da página com a listagem de todos os ascensores, pode ser solicitado para vários ascensores com informações comuns, como: morada, proprietário, EMIE e tipo de serviço a que está sujeito. Quando o utilizador efectua o pedido, é-lhe apresentado uma caixa de diálogo com um resumo do pedido e se pretende continuar, caso valide pode efectuar o pagamento de imediato ou posteriormente, neste passo, caso seja o administrador a efectuar o pedido, além das opções dos outros utilizadores, também pode optar por dar seguimento ao pedido estando isento de pagamento. É ainda possível trocar o titular do pedido, quando por exemplo é a EMIE ou o gestor a fazer o pedido, mas pretende que seja em nome do proprietário. Após confirmação com pagamento é apresentada uma nova caixa de diálogo com o valor a pagar e redireccionado para a página do Paypal para proceder ao pagamento. Se o pagamento for bemsucedido, ou se tiver seleccionado a opção para pagar depois ou esteja isento de pagamento é registado o pedido, POST (…/pedidos). O comportamento desta funcionalidade está apresentado na Figura 35. 57 Figura 35 - Diagrama de actividade UML do comportamento da função do front-end: Novo pedido 64 Figura 41 - Insomnia - Lista de Ascensores Figura 42 - Plataforma web - Página de Ascensores Figura 43 - Plataforma web - Página de um Ascensor 65 5.4 Gestão de Pedidos Sendo o pedido a acção principal e inicial de todo este processo, através da página de ascensores, e por forma a garantir que fosse correctamente registado, foram realizados vários testes, conforme mostrado na Tabela 18. Na Figura 44 o resultado da resposta do back-end com a lista de pedidos e na Figura 45 a página web referente aos pedidos. Nesta página é possível seguir todo o percurso dos pedidos até à conclusão, disponibilizando atalhos para a página do ascensor, do proprietário e da EMIE e também para as páginas correspondentes ao estado actual, isto é, notas de pagamento e inspecções. O administrador pode ainda editar e eliminar um pedido. Após pagamento efectuado a EI passa a ter acesso ao pedido onde irá proceder ao agendamento, indicando a data, hora e técnico de forma dinâmica. UC-17: Listar pedidos UC-18: Inserir novo pedido UC-19: Editar pedido UC-20: Eliminar pedido Tabela 18 - Testes à gestão de pedidos UC ID Cenário Descrição Resultado esperado Resultado obtido 17 1 Visualização de todos os pedidos por parte do Administrador Verificar se o administrador visualiza todos os pedidos Lista de todos os pedidos Lista de todos os pedidos 2 Visualização de todos os pedidos por utilizador comum Verificar se um utilizador que não o administrador visualiza os pedidos que não os seus Lista apenas os seus Lista apenas os seus 3 Visualização de todos os pedidos por EI Verificar se a EI visualiza os pedidos já pagos Lista apenas os já pagos Lista apenas os já pagos 18 1 Inserir pedido de serviço Verificar se o pedido foi registado, e o estado do ascensor actualizado Pedido registado e pendente Pedido registado e situação de pedido pendente 19 1 Editar pedido com dados válidos Verificar se o pedido é actualizado com dados válidos Pedido actualizado Pedido actualizado Editar pedido com dados inválidos Verificar se o pedido é actualizado com dados inválidos Erro Erro Editar pedido por um utilizador comum Verificar se um utilizador que não o administrador pode editar o pedido Sem acesso Sem acesso 20 1 Eliminar pedido Verificar se o pedido é eliminado Pedido eliminado Pedido eliminado 2 Eliminar pedido por parte de um utilizador comum Verificar se um utilizador que não o administrador pode eliminar o pedido Sem acesso Sem acesso 66 Figura 44 - Insomnia - Lista de Pedidos Figura 45 - Plataforma web - Página de Pedidos 5.5 Gestão de Pagamentos No seguimento do pedido, e caso haja lugar a um pagamento, seja de imediato ou posteriormente, foi necessário garantir que a nota de pagamento fosse registada com o valor correcto e a ligação ao Paypal para pagamento fosse efectuado. Na Tabela 19 estão os testes e resultados das UC e na Figura 46 e Figura 47 a lista de notas de pagamento enviada pelo back-end e a página das notas de pagamento, respectivamente. Nesta página é possível observar o estado do pagamento e visualizar com mais detalhe a que se refere. É ainda possível fazer upload e download de documentos (dados de pagamento, comprovativo de pagamento e recibo) tendo em conta a situação da nota de pagamento. UC-21: Gerar pagamento UC-22: Listar pagamento 67 Tabela 19 - Testes à gestão de pagamentos UC ID Cenário Descrição Resultado esperado Resultado obtido 21 1 Gerar pagamento após pedido Verificar se é gerado pagamento após efectuar pedido Redireccionado para PAYPAL Redireccionado para PAYPAL 2 Gerar pagamento após pedido e para pagar depois Verificar se é gerado pagamento após efectuar pedido e para pagar depois. Pedido criado Pedido criado 22 1 Visualização de todas as notas de pagamento por parte do Administrador e do Tesoureiro Verificar se o administrador e o tesoureiro visualizam todos os pedidos Lista de todas as notas de pagamento Lista de todas as notas de pagamento 2 Visualização de todas as notas de pagamento por utilizador comum Verificar se um utilizador que não o administrador visualiza as notas de pagamento que não os suas Lista apenas as suas Lista apenas as suas 3 Visualização de notas de pagamento por EI Verificar se a EI visualiza as notas de pagamento Sem acesso Sem acesso Figura 46 - Insomnia - Listar Notas de Pagamento Figura 47 - Plataforma web - Lista de Notas de Pagamento 5.6 Gestão de Inspecções Após pedido efectuado e pago, se tiver lugar a pagamento, é agendado o serviço e registado o resultado após o serviço. Assim, foram realizados testes, Tabela 20, por forma a garantir que estas duas 68 acções fossem realizadas correctamente, sem falhas. A resposta com a listagem das inspecções agendadas por parte do back-end pode ser observada na Figura 48. Na Figura 49 é apresentada a view das inspecções agendadas onde são visualizados o ponto de situação e o calendário com os respectivos agendamentos. Nesta página além da EI poder editar e eliminar o serviço, pode, após concluir a inspecção, registar o resultado escolhendo as opções que tem à disposição com o upload dos documentos. Após a EI submeter o resultado, é possível fazer o download do relatório e do certificado, em caso de aprovação. UC-23: Listar agendamento UC-24: Inserir agendamento UC-25: Editar agendamento UC-26: Eliminar agendamento UC-27: Inserir resultado Tabela 20 - Testes à gestão de inspecções UC ID Cenário Descrição Resultado esperado Resultado obtido 23 1 Visualização de todos os agendamentos por parte do Administrador e EI Verificar se o administrador e a EI visualizam todos os ascensores Lista de todos os ascensores Lista de todos os ascensores 2 Visualização de todos os agendamentos por utilizador comum Verificar se um utilizador que não o administrador nem a EI visualiza os agendamentos que não os seus Lista apenas os seus Lista apenas os seus 24 1 Inserir agendamento com os dados obrigatórios Verificar se o agendamento é registado com os dados preenchidos Agendamento criado Agendamento criado 2 Inserir agendamento com falta de dados Verificar se o agendamento é registado sem dados. Não é possível Não é possível 25 1 Editar agendamento com dados válidos Verificar se o agendamento é actualizado com dados válidos Agendamento actualizado Agendamento actualizado 2 Editar agendamento com dados inválidos Verificar se o agendamento é actualizado com dados inválidos Erro Erro 3 Editar agendamento por um utilizador comum Verificar se um utilizador que não o administrador ou a EI pode editar o agendamento Sem acesso Sem acesso 26 1 Eliminar agendamento Verificar se o agendamento é eliminado Agendamento eliminado Agendamento eliminado 2 Eliminar agendamento por parte de um utilizador comum Verificar se um utilizador que não o administrador ou a EI pode eliminar o agendamento Sem acesso Sem acesso 27 1 Inserir resultado com informação completa e ficheiro Verificar se é inserido o resultado com informação completa e ficheiro Resultado inserido Resultado inserido 69 2 Inserir resultado com informação incompleta e/ou sem ficheiro Verificar se é inserido o resultado com informação incompleta e/ou sem ficheiro Não é possível Não é possível Figura 48 - Insomnia - Listar Agendamentos Figura 49 - Plataforma web - Página de Inspecções 70 6. CONCLUSÃO 6.1 Conclusões Este trabalho teve como objectivo o desenvolvimento de uma plataforma de gestão para inspecções periódicas de ascensores. O trabalho dividiu-se essencialmente em duas partes. A primeira dedicada à revisão da literatura ou estado de arte, onde foi realizado um estudo da legislação a que estão sujeitos os ascensores, nomeadamente a obrigatoriedade e periodicidade das inspecções, ao estudo e comparação das soluções semelhantes que já existem no mercado, e ao estudo de tecnologias e linguagens de programação web essenciais para o desenvolvimento uma plataforma web moderna. A segunda fase foi dedicada à concepção e ao desenvolvimento de toda a plataforma web, assim como à fase de testes e resultados. A parte inicial desta fase foi muito importante, uma vez que permitiu definir com facilidade as funcionalidades a serem implementadas no desenvolvimento da plataforma. Foi feito o levantamento dos requisitos, foram estruturadas as funcionalidades, os casos de uso e o modelo de dados e foram elaborados os mockups da plataforma. Nesta parte de concepção procedeu-se ainda à definição da arquitectura de todo o sistema, sendo identificados os elementos relevantes, como a existência da camada do servidor, onde é feita a ligação com a base de dados e ficheiros e a camada do navegador, onde é feita a interacção com o utilizador. Na fase seguinte, a implementação da plataforma web , foi respeitada toda a concepção, com algumas alterações e inclusões, tendo em conta as necessidades que foram surgindo. Foram validadas todas as entidades envolvidas, tendo em contas as suas permissões e funcionalidades. Na implementação da camada do navegador, e uma vez que alguns dos utilizadores, nomeadamente os proprietários, não têm um grande conhecimento e agilidade nas tecnologias, foi tido em consideração as interfaces da plataforma, por forma a tornar a utilização o mais simples e intuitiva possível, mas ao mesmo tempo eficiente e moderna. Durante o desenvolvimento da plataforma InspAscensores surgiram várias dificuldades, que contribuíram para alguns atrasos, dado que não dominava muito bem algumas tecnologias, contudo foram colmatadas através de pesquisas e ajuda por parte dos orientadores e colegas. Apesar da plataforma desenvolvida ser ainda uma versão protótipo, já apresenta um grande potencial para dar cumprimento à obrigatoriedade das inspecções periódicas de ascensores e é uma mais valia para as Câmaras Municipais utilizarem e disponibilizarem para as entidades envolvidas. 71 6.2 Trabalho Futuro Embora a plataforma InspAscensores cumpra com os objectivos definidos, é importante desenvolver num futuro algumas funcionalidades que foram inicialmente pensadas, mas que não foram realizadas, bem como outras que foram identificadas ao longo do desenvolvimento. Dado que não foi desenvolvida uma aplicação móvel, a mesma poderá ser criada em trabalho futuro, através de uma aplicação móvel nativa que ainda utiliza a mesma API do backend e do frontend web desenvolvido. Será importante criar a funcionalidade de caixa de mensagens, por forma a haver uma interacção entre os vários utilizadores, embora esta funcionalidade não seja tão importante para todo o processo de inspecções. Mais importante será criar a possibilidade de um utilizador delegar o acesso a outro do mesmo tipo, não havendo a limitação de acesso único. No que diz respeito à questão de segurança, e aquando da produção, será usada um certificado de segurança HTTPS, por forma a ser encriptada a comunicação entre o cliente e o servidor. Já na autenticação será de utilizar a autenticação de 2 factores e a autenticação federada. Na aplicação web seria de melhorar a plataforma de gestão de ascensores, com a possibilidade de visualização do histórico e todos os documentos associados a cada equipamento. 72 BIBLIOGRAFIA [1] K. Kaplan, “Are elevators really hazardous to your health?,” 2011. https://www.latimes.com/health/la-xpm-2011-dec-15-la-heb-elevator-safety-death-201112115story.html (accessed Nov. 19, 2020). [2] BBC, “Quão comuns são acidentes com elevadores?,” 2018. https://www.bbc.com/portuguese/geral-46314769 (accessed Nov. 18, 2020). [3] L. Miguel and D. Lapas, Análise de risco e inspeções de segurança em elevadores, escadas mecânicas e tapetes rolantes . 2014. [4] V. Zarikas, M. Loupis, N. Papanikolaou, and C. Kyritsi, “Statistical survey of elevator accidents in Greece,” Saf. Sci. , vol. 59, pp. 93–103, Nov. 2013, doi: 10.1016/j.ssci.2013.05.001. [5] S. S. Kalligeros, “The necessity of lift inspections in Greece,” Emerg. Technol. Non-Destructive Test. V - Proc. 5th Conf. Emerg. Technol. NDT , no. May, pp. 467–470, 2012, doi: 10.1201/b11837-85. [6] S. T. Park and B. S. Yang, “An implementation of risk-based inspection for elevator maintenance,” J. Mech. Sci. Technol. , vol. 24, no. 12, pp. 2367–2376, 2010, doi: 10.1007/s12206-010-1004-1. [7] A. Vasconcelos, “ASCENSORES: O TRANSPORTE VERTICAL INDISPENSÁVEL NA CONSTRUÇÃO EM ALTURA.” https://haengenharia.pt/noticias/ascensores-o-transporte-vertical-indispensavel-naconstrucao-em-altura (accessed Nov. 18, 2020). [8] M. das O. P.-G. do Ministro, “Decreto-Lei n.o 38382,” Diário do Gov. n.o 166/1951, 1o Supl. Série I 1951-08-07 , pp. 715–729, 1951. [9] O. do T. e A. Ministério das Cidades, “Decreto-Lei n.o 320/2002,” Diário da República n.o 300/2002, Série I-A 2002-12-28 , pp. 8160–8169, 2002. [10] M. Colezea, G. Musat, F. Pop, C. Negru, A. Dumitrascu, and M. Mocanu, “CLUeFARM: Integrated web-service platform for smart farms,” Comput. Electron. Agric. , vol. 154, no. August, pp. 134–154, 2018, doi: 10.1016/j.compag.2018.08.015. [11] M. Rosaa, C. Fariab, A. M. Barbosac, A. I. Martinsa, A. F. Almeidaa, and N. P. Rocha, “A platform of services to support community-dwelling older adults integrating fhir and complex security mechanisms,” Procedia Comput. Sci. , vol. 160, pp. 314–321, 2019, doi: 10.1016/j.procs.2019.11.085. [12] L. Gurbeta, A. Badnjevic, E. Zunic, and F. Nejra Pinjo, “Software Package for Tracking Status of Tnspection Dates and Reports of Medical Devices in Healthcare Tnstitutions of Bosnia and Herzegovina,” pp. 4–8. 73 [13] R. Silva, “GOFut - Plataforma WEB gestão online de futebol,” 2016. [14] P. Tripathi, V. Kumar Singh, and M. Chandra Trivedi, “Smart vehicle management using cost effective approach,” Mater. Today Proc. , no. xxxx, 2020, doi: 10.1016/j.matpr.2020.07.068. [15] A. N. de Souza and F. Dalla Rosa, “Desenvolvimento de uma plataforma web de apoio ao gerenciamento de acidentes de trânsito,” Transportes , vol. 23, no. 3, p. 26, 2015, doi: 10.14295/transportes.v23i3.876. [16] Gobox, “Inspauto.” https://gobox.pt/details/14 (accessed Nov. 21, 2020). [17] GESAutarquia, “GESElevador.” https://gesautarquia.pt/geselevador (accessed Nov. 21, 2020). [18] SafetyCulture, “iAuditor Elevator Inspection Software.” https://safetyculture.com/app/elevatorinspection-software/ (accessed Nov. 21, 2020). [19] Snappii, “Elevator Inspection.” https://www.snappii.com/app/elevator-inspection/ (accessed Nov. 21, 2020). [20] Didatica, “A Linguagem Python.” https://didatica.tech/a-linguagem-python/ (accessed Dec. 28, 2020). [21] F. Portela and R. Queirós, Introdução ao Desenvolvimento Moderno para a Web , FCA-Edit. 2018. [22] A. Andreica et al. , “Design and implementation of an integrated Web service architecture,” WEBIST 2011 - Proc. 7th Int. Conf. Web Inf. Syst. Technol. , no. January 2014, pp. 631–637, 2011, doi: 10.5220/0003477606310637. [23] Devmedia, “NoModelo Entidade Relacionamento (MER) e Diagrama Entidade-Relacionamento (DER).” https://www.devmedia.com.br/modelo-entidade-relacionamento-mer-e-diagrama-entidaderelacionamento-der/14332 (accessed Dec. 28, 2020). [24] Wikipédia, “SQL.” https://pt.wikipedia.org/wiki/SQL (accessed Dec. 28, 2020). [25] Hotframeworks, “JavaScript.” https://hotframeworks.com/languages/javascript (accessed Dec. 21, 2020). [26] J. Voutilainen, “Evaluation of Front-end JavaScript Frameworks for Master Data Management Application Development,” no. December, pp. 4–6, 2017, [Online]. Available: https://www.theseus.fi/bitstream/handle/10024/138668/Voutilainen_Jaakko.pdf?sequence=1 [27] Nikhil, “13 Best JavaScript Framework For 2020,” Lambdatest , 2020. https://www.lambdatest.com/blog/best-javascript-framework-2020/ (accessed Dec. 21, 2020). [28] InVerita, “Most popular JavaScript frameworks in 2020,” 2020. https://becominghuman.ai/most-popular-javascript-frameworks-in-2020-e60534b14b36 (accessed Dec. 21, 2020). 80 Figura 66 - Plataforma web - Assumir Responsabilidades Figura 67 - Plataforma web - Código de Portabilidade Figura 68 - Plataforma web - Responsabilidade Assumida Figura 69 - Plataforma web - Mapa Ascensores 81 Figura 70 - Plataforma web - Novo Pedido Figura 71 - Plataforma web - Finalizar Pedido Figura 72 - Plataforma web - Pagamento do Pedido Figura 73 - Plataforma web - Submeter Comprovativo Figura 74 - Plataforma web - Dados do Pagamento 82 Figura 75 - Plataforma web - Dados do Pagamento (Cont.) Figura 76 - Plataforma web - Eliminar Pedido Figura 77 - Plataforma web - Pedido Eliminado Figura 78 - Plataforma web - Criar Agendamento (Data) Figura 79 - Plataforma web - Criar Agendamento (Hora) 83 Figura 80 - Plataforma web - Criar Agendamento (Técnico) Figura 81 - Plataforma web - Agendamento Criado Figura 82 - Plataforma web - Eliminar Agendamento Figura 83 - Plataforma web - Inserir Resultado Figura 84 - Plataforma web - Agendamento Eliminado Figura 85 - Plataforma web - Resultado Inserido Figura 86 - Plataforma web - Página Sobre