Protótipo de um modelo de gerenciamento de espaços baseado na Internet das Coisas
Tags: iot, webdev, database, api
Published: 2023-01-17 20:35:28

> Esse é o texto selecionado do meu trabalho de conclusão, escrito junto com Thátilla Curty

## 1 Introdução

Com a introdução da globalização nos mais variados contextos do cotidiano, nota-se a busca constante por tecnologia para tornar atividades das mais complexas às mais simples, virtualmente praticáveis. Paralelamente a isso, vê-se conceitos de escritórios, moradias e lazer com propostas inovadoras a fim de modernizar a gestão de espaços compartilhados. Logo, unindo-se às duas vertentes, vê-se a busca por métodos que realizem o controle e a organização do acesso a alguns espaços a fim de restringi-los a um determinado grupo de pessoas por tempo predefinidos. Disponibilidade de salas para locação é prática cada vez mais comum, assim como aluguéis de imóveis a curto prazo, espaço privativo existente em um local mais amplo, bem como salas privativas de bares e restaurantes nos quais soluções convencionais ainda são muito aplicadas a fim de pô-los em uso, como a utilização de fechaduras, trincos, cadeados e chaves. Um desses *cases* de compartilhamento de espaços é a empresa de aluguéis de imóveis *Airbnb*, que permite que usuários, chamados de anfitriões, aluguem espaços para viajantes desconhecidos. Pensando rapidamente sobre essa relação, fica evidenciado o poder de uma ferramenta de gerenciamento, que tranquilizaria ambas as partes e ainda melhoraria a experiência dos mesmos. Essas ferramentas, no entanto, não são efetivas no controle organizacional, tampouco auxiliam na privacidade dos envolvidos, podendo esses pontos serem alcançados por fechaduras inteligentes. Porém, ainda há uma carência de dispositivos como este de baixo custo no qual seja possível centralizar e gerenciar remotamente. Com intuito de suprir essas carências, funcionalidades e conceitos da Internet das Coisas são aplicadas, cuja natureza pode ser descrita com base na capacidade de dispositivos se comunicarem entre eles e com usuários, do controle e automação de atividades cotidianas e na redução dos custos destas atividades. Todos estes aspectos, quando aliados, proporcionam uma melhor experiência a quem utilizará o dispositivo. Desta forma, propõe-se no presente trabalho o estudo e desenvolvimento de um protótipo de dispositivo de gestão inteligente do acesso de espaços compartilhados utilizando-se da *IoT*.

## 2 Justificativa

O uso de objetos tem sido revolucionado ao redor do mundo com a inserção de dispositivos inteligentes, cada vez mais e mais pessoas se aventuram neste mundo, integrando suas casas com assistentes virtuais, obtendo assim uma experiência totalmente única. Indo de encontro a esse anseio por obter uma melhor experiência, a criação de um sistema de gerenciamento como proposto nesse trabalho irá, sem sombra de dúvidas, impactar a vida de todos aqueles que compartilham espaços, desde professores e alunos, que usam laboratórios como os presentes em nossa instituição, bem como aqueles que alugam salas comerciais, escritórios e tantos outros recursos que podem ser compartilhados. Diferentemente do que se pensava há alguns anos, a internet das coisas não é um assunto de ficção, já é uma realidade e é impreterível abraçarmos seus conceitos e ideias para construir tecnologias cada vez mais acessíveis e impactantes para as pessoas.

## 3 Objetivos

O objetivo deste trabalho é desenvolver um sistema de reservas constituído por um aplicativo *web* e um dispositivo físico, que permita um maior controle do uso dos espaços compartilhados.

Como objetivos específicos têm-se as escolhas das ferramentas mais eficazes para o desenvolvimento do sistema, ou seja, a escolha das tecnologias, *frameworks* e bancos de dados que irão permitir a realização do projeto.

## 4 Desenvolvimento

Neste capítulo serão apresentados conceitos relacionados à temática e ao desenvolvimento do trabalho no qual se baseia na funcionalidade de fechaduras digitais e na comunicação com os utilizadores, descrevendo a implementação da *IoT* (*Internet* das coisas), bem como suas ramificações para a prototipagem através da interface estética por meio da programação voltada ao *front-end* e não menos importante, o desenvolvimento do *back-end* a fim de garantir a eficácia da comunicação.

### 4.1 Fechadura Digital

As fechaduras digitais conforme ilustrado na Figura 1, são dispositivos eletrônicos que possuem a capacidade tanto de facilitar quanto dificultar a entrada e saída de pessoas a determinados ambientes, além de permitir vantagens secundárias como a comodidade no dia-a-dia. Ainda que possuam benefícios consideráveis, estes dispositivos ainda possuem certa resistência quando a implementação por parte dos brasileiros. Isso se dá por alguns motivos, dentre eles destacam-se o custo considerável que são comercializadas custando em média mil reais, a dificuldade de instalação e a necessidade de mão de obra qualificada para reparos. Através dos inúmeros tipos de acionamento, como explicado por (GOUVEIA, 2017), as fechaduras podem funcionar por meio de cartão de aproximação, biometria, senha numérica e até mesmo por *bluetooth*, permitindo a abertura por comando de voz, por exemplo.


![Figura 1 - Exemplo de Fechadura Digital](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fcsz5zgr271udrzfnuh2.png)

### 4.2 Iot: *Internet of Things*

Segundo Weber (2010, p.1), “A *Internet* das Coisas (*IoT*) é uma arquitetura de informação global emergente baseada na *Internet* que facilita a troca de bens e serviços”. Logo, o objetivo deste conceito é fornecer representações nos sistemas de informação de objetos físicos, permitindo que sejam consultadas qualquer informação pertinente a eles através da *internet*.

Objetos simples e cotidianos, assim como serviços mais avançados de informação, podem interagir e comunicar. Segundo Magrani (2018, p.22), é essa conexão das coisas junto a Internet “com capacidade para compartilhar, processar, armazenar e analisar um volume enorme de dados entre si” que explicita e unifica os conceitos de *IoT* e *Big Data*, sendo este último termo, referência a uma quantidade volumosa de dados que, também segundo Magrani (2018, p.22), “têm potencial de ser explorados para obter informações.”.

É pelo uso de tecnologias interconectadas e demais vantagens e características da *IoT*, que a mesma, segundo Magrani (2018, p.24) “poderá trazer diversos benefícios aos consumidores.”, sendo possível solução para desafios de gestão pública, por exemplo.

### 4.2 Banco de Dados

Desde os primórdios da humanidade o ser humano busca formas de armazenar informação, desenhos rupestres, a invenção do papiro, as fotografias e tantas outras formas de registrar e armazenar informações de modo digital.

A informação possui valor estratégico, sendo necessário cuidado e estudos para o desenvolvimento de um sistema de gerenciamento de banco de dados (SGBD). Para (FONTES, 2006), é fundamental que a informação não seja apenas armazenada como também seja disponibilizada para quem necessita dela.

### 4.4 Plataformas de Prototipagem

Prototipar é a ação de criar um protótipo, ou seja, criar uma versão do seu produto que permita testar e validar ideias antes de conceber o produto que será entregue ao mercado. Com o intuito de atender a demandas de profissionais e entusiastas da cultura *maker*, nos últimos anos surgiram inúmeras plataformas que visam facilitar o desenvolvimento de protótipos.

#### 4.4.1 Arduino

A plataforma *Arduino*, como o exemplo da Figura 2, lançada em 2005 por um grupo de pesquisadores tem por objetivo democratizar o acesso à tecnologia, facilitando o desenvolvimento de projetos e apoiando atividades de ensino. Como citado por (MCROBERTS, 2015),“A maior vantagem do *Arduino* em relação a outras plataformas de desenvolvimento de microcontroladores é sua facilidade de utilização, o que permite que pessoas que não sejam da área técnica possam aprender o básico e criar seus próprios projetos em um período relativamente curto”. Esta plataforma é baseada nos conceitos de *softwares* e *hardwares* livres, permitindo que todo e qualquer usuário contribua com novas bibliotecas e funcionalidades, além de permitir a fabricação de placas genéricas por outros fabricantes.



![Figura 2 - Arduino](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nf3v9btw5f8obna97ugy.png)

Este ecossistema de desenvolvimento conta com uma IDE (*Integrated Development Environment*, que em português significa Ambiente de Desenvolvimento Integrado), que permite programação de placas como ESP32, NODEMCU, etc. A IDE, como explicado por (MCROBERTS, 2015), permite compilar e embarcar códigos escritos em *wiring*, linguagem tipo C/C++ que permite uma abstração de particularidades dos *hardwares*, facilitando o desenvolvimento.

#### 4.4.2 Raspberry

As placas *raspberry* criadas e mantidas pela *Raspberry Foundation*, são uma opção para o desenvolvimento de protótipos. Segundo (OLIVEIRA; ZANETTI; NABARRO, 2018), são plataformas versáteis que permitem fácil conexão de circuitos e módulos eletrônicos, sendo uma excelente ferramenta para desenvolvimento de conceitos *IoT*.


![Figura 3 - Raspberry](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/39biydhizu6ul2yqeiij.png)

Estes microcomputadores de baixo custo são constituídos de placa única como ilustrado na Figura 3, possuindo capacidades suficientes para desenvolvimento de projetos envolvendo robótica, ainda que possuam capacidade de armazenamento, processamento e memória RAM inferiores se comparados a de computadores convencionais.

As primeiras placas desenvolvidas tinham por objetivo proporcionar o acesso a computação através de suas placas, que não eram maiores do que um celular.

Aliando seu tamanho compacto ao poder de processamento de um computador, as placas *raspberry* logo se tornaram uma alternativa para criação de servidores, *machine learning* e demais aplicações da computação. Ademais, trabalham com código aberto através de um sistema operacional baseado na distribuição *Linux Debian*, sendo, de acordo com (OLIVEIRA; ZANETTI; NABARRO, 2018), uma ferramenta de inclusão digital tendo vasta opção de programas gratuitos por ser um *software* livre.

### 4.5 Comunicação entre as partes

Para que a comunicação exista, as partes (transmissor e receptor) devem possuir um pré-acordo de como será a troca de informações. Numa aula, por exemplo, o professor deve falar a mesma língua nativa dos estudantes. Já para comunicação usando a rede de computadores, hoje já melhor, definida como uma rede de *hosts*, se faz necessário que as partes saibam quais são as regras para que possa haver a troca de dados. O protocolo HTTP, que foi desenvolvido em 1965 por Ted Nelson e que viria a se tornar um dos pilares da *WEB* moderna, é um protocolo da camada de aplicação do modelo TCP/IP, que segundo (COMER, 2015), permite o acesso das informações de modo de texto estruturado, não se preocupando de como o dado ali foi recebido/tratado já que no modelo TCP/IP cada camada tem sua função.

Para (KUROSE; ROSS, 2006), O HTTP está dividido em duas partes, servidor e cliente, que se comunicam através de mensagens HTTP. Deste modo, entende-se que o HTTP provê uma estrutura para essas mensagens bem como a forma como essas mensagens são compartilhadas.

### 4.6 Aplicação *Web*

Os sistemas *Web* evoluíram significativamente desde suas primeiras versões, isso se deve a muitos fatores, mas especialmente ao aumento de desempenho das máquinas como um todo. Nos primórdios da *web*, a principal forma de se visualizar um *site* era carregar um arquivo estático que seria apenas exibindo na tela do usuário, ou seja, toda a parte de tratamento de dados e envio de mídias era feito dentro do servidor e entregue pronto ao computador do usuário. Assim, como explicado por (CUNHA, 2022), “ todos os arquivos e documentos produzidos dentro do sistema eram armazenados localmente ou em algum diretório da rede.”

Com o aumento da performance dos computadores pessoais passou a ser possível a criação de sistemas mais complexos e robustos, dentro dos navegadores, aumentando a interoperabilidade de sistemas e abrindo uma nova era de desenvolvimento. Um exemplo dessa evolução pode ser vista nos editores de texto, em que no início dos anos 2000, seria inimaginável pensar em um editor de texto que não fosse um programa específico de computador, hoje já somos capazes de escrever dentro do próprio navegador, sincronizados com nossos celulares e *tablets*. Uma aplicação *web* é geralmente composta de *frontend* e *backend*, a primeira sendo tudo aquilo que é realizado diretamente no navegador do usuário e da experiência do usuário com o produto.

É nesta parte que os desenvolvedores se debruçam para garantir não só a correta funcionalidade do sistema mas também que essa experiência seja simples e satisfatória. Um exemplo desta preocupação pode ser vista em certos padrões: o botão de busca que sempre fica posicionado na parte superior das páginas ou ainda as informações de contato que são colocadas no rodapé. Nada impede o usuário de inverter a localização dessas informações, mas, pensando na experiência para o usuário, faz sentido que seja o mais próximo daquilo que ele já está habituado a realizar.

Por *backend*, entende-se tudo aquilo que está acontecendo no servidor da aplicação, no qual é dele a responsabilidade de tratar os dados dos bancos ao usuário e rotinas que demandem mais processamento por exemplo.

A comunicação entre *backend* e *frontend*, como visto no tópico anterior e no decorrer deste, é feito principalmente pelos métodos do protocolo HTTP. Através de uma interface de programação de aplicação, as comumente chamadas API’s (*Application Programming*

*Interface*), é possível integrar os serviços do cliente e do servidor resultando em uma melhor performance e experiência do usuário.

### 4.7 Robôs de auto-atendimento

A fim de otimizar as operações, melhorar o atendimento e interface com o cliente, empresas buscam os robôs de auto-atendimento como recursos. Essas ferramentas, como (WITTEL, 2017) explica, surgiram para suprir demandas de canais diferenciados de atendimento ao cliente no qual podem ser conceituados como interfaces automatizadas de conversação ou assistentes virtuais. Em outras palavras, os *chatbots* funcionam com inteligencia artificial que trabalham a partir de comandos preestabelecidos, fornecendo em tempo real, atendimento especializado aos clientes. Esses robôs de auto-atendimento se integram a aplicativos de comunicação, como *whatsapp, telegram e facebook* , como forma mais versátil e simples à se comunicar com o cliente, uma vez que, segundo (WITTEL, 2017) , não necessita de download adicional de qualquer programa.

## 5 Metodologia

Neste trabalho será utilizada a pesquisa experimental qualitativa, que baseia-se na manipulação direta de variáveis relacionadas com o objeto de estudo, tendo como finalidade testar hipóteses. Objetivando o melhor desenvolvimento do protótipo, optou-se por uma pesquisa de cunho experimental visando reproduzir a situação-problema em condições controladas, criando modelos de solução. Isso implica dizer que serão versões simplificadas do problema maior, a fim de proporcionar um maior entendimento do tema.

Ao colocar a pesquisa em ação, escolhendo como ambiente teste e papel de espaço compartilhado a fim de aplicar o gerenciamento por meio do protótipo, os laboratórios do campus IFF Macaé servirão de objeto de estudo com finalidade de observar o funcionamento dos mesmos com objetivo de fundamento para nossas reproduções físicas do protótipo, imaginando-se sempre, sua aplicabilidade nos laboratórios de informática, bem como a realidade cotidiana do fluxo de pessoas e o gerenciamento nesses espaços.

Primeiramente, será desenvolvido o modelo problemático, descrevendo o funcionamento atual das reservas. Ademais, serão realizadas análises com o propósito de encontrar uma melhor versão para os usuários deste sistema.

Após o devido entendimento da situação problema, da devida delimitação de requisitos e necessidades, dará-se início a segunda etapa que, em suma, canaliza-se no estudo aprofundado de aplicações da *IoT*, com intuito de entender e desenvolver aplicações reais que apresentam limitações mas também, inúmeras possibilidades.

Como consequência, é dado início à criação de uma versão teste para o sistema *web* de agendamento, buscando encontrar a forma mais simples à utilização do usuário. Com este intuito ocorre ainda a procura por uma forma prática e eficiente de se desenvolver e manter o sistema *web*. Portanto é nesta etapa do desenvolvimento deste trabalho que as primeiras versões do sistema começam a serem desenhadas e testadas.

Após alcançar uma certa maturidade do sistema *web*, iniciaremos a construção da fechadura que compõe nosso sistema. A ela, damos o papel de usabilidade, comunicação e organização, criando um dispositivo *IoT* que se conectará ao nosso sistema desenvolvido.

## 6 Resultados e discussões

Ao iniciar-se o descritivo do modelo problemático sendo a implantação do protótipo e gerenciamento do espaço nos laboratórios de informática do IFF *campus* Macaé, durante a execução da primeira etapa de estudo, observou-se a maneira na qual se dá as reservas dos mesmos atualmente: É disponibilizado em um site monitorado pelo professor responsável pelos laboratórios do IFF, a possibilidade de datas e horários disponíveis a serem utilizados, onde o usuário pode se cadastrar. Para acessar os espaços é disponibilizado chaves ou senhas que são únicas e compartilhadas a todos. Desta forma, é necessário contar com a cooperação e bom senso dos usuários uma vez que não há um controle, na prática, de permanência das pessoas no ambiente em seu horário específico.

Dando sequência ao entendimento do modelo problemático, bem como estudo de tecnologias para tornar-se possível o desenvolver de um protótipo que suprisse as necessidades e fragilidades já citadas, foi dado inicio ao desdobramento deste trabalho, se iniciando com a aplicação *web*.

O *frontend* foi construído pensando em três tipos de usuários: o primeiro, sendo ele o usuário sem qualquer nível de acesso, esse usuário poderá apenas visualizar as reservas realizadas; o segundo tipo de usuário é o usuário com nível de acesso comum, este usuário terá acesso à partes específicas do sistema que o permitirão controlar suas reservas; o terceiro e último usuário é o administrador, este por sua vez terá nível de acesso total, desde realizar reservas até inserir novos usuários no sistema. A premissa fundamental do funcionamento das reservas é que uma reserva só poderá ser efetivada se, e somente se, o horário estiver livre. Na realização da reserva o usuário selecionará o intervalo de horários, informará o título da reserva e irá informar a sua senha de acesso. Acerca dessas informações, será necessário realizar validações para garantir o correto funcionamento, entre estas regras destaca-se as orientações para a seleção de horários, o horário final deverá ser posterior ao horário inicial e deverá ser impossível ao usuário realizar uma reserva com horários anteriores ao horário da realização da reserva, ou seja, no passado. Nas figuras 4 e 5 é possível visualizar como o *frontend* foi constituído, pensado em uma experiência simples e intuitiva ao usuário.


![Figura 4 - Página Home: Sistema Moisés](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wumh13xsjxdkk8b94jz9.png)



![Figura 5 - Página Reservas: Sistema Moisés](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/86tqtwyccxu0dg1vcmlm.png)


O *backend*, por sua vez foi pensado de modo a validar as informações vindas do *frontend* através das requisições HTTP, e realizar as operações necessárias junto ao banco de dados. Deste modo é no *backend* onde os dados são tratados, manipulados e disponibilizados para as demais partes do sistema. Para criação de um modelo o mais fidedigno possível, as rotas de acesso que compõe esse sistema são protegidas a nível de acesso, ou seja, apenas usuários que possuam nível de acesso compatível podem realizar ações que afetem o banco de dados. Este nível de acesso é compartilhado através da realização do login, na forma de uma chave única, criada junto com a criação do usuário no sistema, e esta chave é salva pelo sistema que realizou o login para então ser usada na realização das requisições permitindo a interação com os dados. Uma vez que a reserva é realizada no *frontend*, validada pela API e então salva no banco de dados, dá-se início a última parte de interação do sistema.

Uma vez que o usuário realizou uma reserva, ele terá acesso ao espaço reservado durante o período solicitado, e somente durante aquele período. Esta regra é o cerne da questão aqui. Este sistema foi pensado para que os usuários tenham a devida privacidade, e estejam assegurados sobre a disponibilidade daquele recurso. De posse da senha, informada pelo próprio usuário no momento em que se realizou a reserva, o usuário deverá utilizar o *bot* disponível para poder adentrar ao espaço, é ele o responsável por comandar o dispositivo físico, liberando ou não a fechadura. 

O *bot* foi desenvolvido com o intuito de possibilitar uma interface amigável aos usuários, nas figuras 6 e 7 é mostrado como essa interação ocorre. Ao enviar um comando para iniciar o *bot*, o usuário recebe uma mensagem de boas vindas informando como o mesmo funciona, nesta mensagem é dito ao usuário que para que ele acesse o espaço reservado, basta enviar a senha do horário.


![Figura 6 - Bot: mensagens informativas](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wy7138wo1d1mdbe1z3vn.png)




![Figura 7 - Bot: envio de mensagens](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/v4wmj8srvd91p10gpepm.png)



Ao enviar a senha, o *bot* irá valida-la junto a API do nosso sistema, sendo a senha válida, o *bot* irá realizar uma requisição para que a fechadura seja aberta, em caso contrário, o *bot* irá fechar manter o espaço bloqueado ao acesso. A fechadura do presente modelo foi constituída de modo a permitir interações vias requisições HTTP. Além das interações via rede, foi pensado na necessidade de liberação do espaço, de dentro para fora, de uma maneira física, com isso em mente foi colocado um botão capaz de controlar a fechadura.

Na figura 8, é possível observar as partes físicas utilizadas na construção da fechadura.


![Figura 8 - Fechadura](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/u8h2v360rs4ke78pzpzp.png)



Para alcançar o objetivo principal desta empreitada, foi necessário delimitar o escopo de possibilidades e determinar as regras de uso para o sistema. Evitando o planejamento excessivo, e a perda de tempo com problemas que podiam ou não serem reais, deu-se início ao desenvolvimento do sistema *web* utilizando a combinação de tecnologias com maior domínio, em especial destaca-se o *Flask*. Foi este *microframework* que possibilitou construir essa primeira versão. Neste primeiro momento, enquanto se entendia o problema, estas tecnologias ofereceram exatamente o que era necessário, um ambiente de desenvolvimento rápido, facilmente integrado e com uma curva de aprendizado que favorecia os objetivos deste projeto. De posse do conhecimento necessário a cerca do problema, conhecendo os pormenores, foi possível analisar de maneira qualitativa as ferramentas que tínhamos para desenvolver a solução. Com base nos primeiros experimentos, notou-se alguns problemas, entre eles destacam-se a dificuldade de manutenção do código e o tempo de latência entre as requisições. Para que o objetivo fosse alcançado de maneira minimamente satisfatória, foi necessário rever as tecnologias.

Falando um pouco dessas escolhas, é de interesse destacar que não há aqui um juízo de valor sobre a eficácia geral dessas ferramentas. Este trabalho não se propõe a encontrar a tecnologia perfeita, atendo-se tão somente a busca da ferramenta mais adequada aos requisitos do modelo e prévios conhecimentos daqueles que o realizaram. Ao observar os requisitos e regras do nosso modelo, percebeu-se que a forma mais prática e assertiva, no momento, de implementar a solução era tendo como base o fluxo de comunicação acima apresentado e portanto dá-se início a última etapa de desenvolvimento.

Para escolha das tecnologias finais deste trabalho, era necessário levar em consideração a capacidade de acesso aos dados, a modelagem de dados, tempo de desenvolvimento e o conhecimento necessário para que todos os outros aspectos fossem atendidos.

Desta forma, o *framework* escolhido para desempenhar o papel de *frontend* foi o Angular, devido a sua alta organização de pastas, que favorece o desenvolvimento da aplicação de maneira limpa e clara, além disso, os recursos disponíveis como requisições

HTTP e autorização de rotas foram fundamentais para a agilidade na codificação do projeto. O *backend* por sua vez, possuía necessidades singulares a cerca do acesso dos dados e nesse quesito a plataforma .NET, em especial o ASP.NET, atendia de maneira impactante o que se era esperado. Isso se deve principalmente as possibilidades de manipulação dos dados dentro da linguagem C Sharp, aliado ao uso do *Entity Framework Core* (um mapeador de banco de dados de objeto para .NET) que disponibiliza todo o acesso aos dados diretamente via código C Sharp, sem a necessidade de implementações de consultas SQL por parte do programador.

No que tange a construção da fechadura o pensamento inicial era a inserção direta do *bot* Telegram em uma *raspberry* para que o controle da fechadura fosse feita diretamente por ele, sem a necessidade de requisições HTTP, contudo, devido ao alto preço dessas placas, e aliado a uma busca por desenvolver o modelo com o mínimo necessário, optou-se por outra abordagem. Ao separar o *bot* Telegram da fechadura, foi possível utilizar o ESP-32 como cérebro da fechadura, o que barateou significativamente a construção do modelo. O *bot* Telegram foi desenvolvido utilizando *Python* , principal tecnologia utilizada para este fim, que já disponibilizava interfaces para acesso a API do Telegram, facilitando o desenvolvimento do nosso *bot*.

## 7 Conclusão e Trabalhos futuros

Ao findar este trabalho, nota-se que foi possível desenvolver um protótipo de sistema de reservas prático e funcional a usuários, com custo baixo e que beneficiaria toda comunidade que compartilha espaços, proporcionando um ambiente mais saudável e operacional. Com um olhar mais voltado a tecnicidade do mesmo, é perceptível que as escolhas tecnológicas feitas foram assertivas, sendo elas capazes de desempenhar o esperado, com qualidade e foco na experiência do usuário. Além do mais, os aspectos de familiaridade das tecnologias escolhidas foram decisivos para a escolha, visando um desenvolvimento ágil e eficiente do uso do tempo. Por inviabilidade operacional, não foi possível a instalação da fechadura nas dependências do Instituto Federal Fluminense *campus* Macaé, este revés, no entanto, não foi determinante na condução deste trabalho uma vez que o mesmo serviu de inspiração mas o presente trabalho não se limita a ele.

Como fruto de tudo que foi observado, algumas demandas para futuros trabalhos são levantadas. A primeira dessas demandas é a instalação do sistema para observação de seu desempenho e impactos no dia-a-dia, buscando identificar possíveis melhorias. Outro ponto é o estudo acerca da melhor maneira de disponibilizar esse sistema aos usuários, como por exemplo, o estudo sobre o uso de computação em nuvem em contraponto a servidores físicos. Não menos importante,destacam-se as necessidades de pesquisa acerca da demanda por esse produto, ou seja, ouvir possíveis consumidores e usuários afim de estabelecer o real impacto deste sistema.

## Referências

ANDRADE, A. P. de. *O que é Flask?* 2020. Disponível em: [<https://www.treinaweb.com. br/blog/o-que-e-flask>](https://www.treinaweb.com.br/blog/o-que-e-flask)

BRANAS, R. *AngularJS essentials: Design and construct reusable, maintainable, and modularweb applications with AngularJS*. 1. ed. Birmingham,United Kingdom: Packt Publishing, 2014. Disponível em: [<https://books.google.com.br/books?hl= pt-BR&lr=&id=qYtlDwAAQBAJ&oi=fnd&pg=PA1&dq=internet+das+coisas&ots= rgSvBwh959&sig=ZaOg-dOO_botZ4fIpLQPBSYECiE#v=onepage&q=internet% 20das%20coisas&f=false>.](https://books.google.com.br/books?hl=pt-BR&lr=&id=qYtlDwAAQBAJ&oi=fnd&pg=PA1&dq=internet+das+coisas&ots=rgSvBwh959&sig=ZaOg-dOO_botZ4fIpLQPBSYECiE#v=onepage&q=internet%20das%20coisas&f=false)

COMER, D. E. *Interligação de redes com TCP/IP*. 6. ed. Rio de Janeiro: Elsevier, 2015 Disponível em: [<https://books.google.com.br/books?hl=pt-BR&lr=&id=F1_jBwAAQBAJ&oi=fnd&pg=PT5&dq=modelo+TCP/IP&ots=k0rfRnwcJy&sig= 14ySYGiYFzATRq9OQJniYxTRNiY#v=onepage&q=modelo%20TCP%2FIP&f=false>.](https://books.google.com.br/books?hl=pt-BR&lr=&id=F1_jBwAAQBAJ&oi=fnd&pg=PT5&dq=modelo+TCP/IP&ots=k0rfRnwcJy&sig=14ySYGiYFzATRq9OQJniYxTRNiY#v=onepage&q=modelo%20TCP%2FIP&f=false) 

CUNHA, F. *Sistema Web: o que é e como funciona?* 2022. Disponível em: [<https://mestresdaweb.com.br/tecnologias/sistema-web-o-que-e-e-como-funciona/>.](https://mestresdaweb.com.br/tecnologias/sistema-web-o-que-e-e-como-funciona/) 

FILIPEFLOP. *Placa Uno R3 + Cabo USB para Arduino.* 2017. [2022]. 1 fotografia. Disponível em: [<https://www.filipeflop.com/produto/placa-uno-r3-cabo-usb-para-arduino/>.](https://www.filipeflop.com/produto/placa-uno-r3-cabo-usb-para-arduino/) 

FONTES, E. *Segurança da informação: o usuário faz a diferença*. 1. ed. São Paulo - SP: Saraiva, 2006. 

GOUVEIA, F. *Fechaduras digitais: como funcionam e por que usá-las?* LinkedIn: Fahim Gouveia, 2017. Disponível em: [<https://www.linkedin.com/pulse/ fechaduras-digitais-como-funcionam-e-por-que-us%C3%A1-las-fahim-gouveia/>](https://www.linkedin.com/pulse/fechaduras-digitais-como-funcionam-e-por-que-us%C3%A1-las-fahim-gouveia/)

GUEDES, M. *O que é o Angular e para que serve?* 2020. Disponível em:[<https://www.treinaweb.com.br/blog/o-que-e-o-angular-e-para-que-serve>](https://www.treinaweb.com.br/blog/o-que-e-o-angular-e-para-que-serve)

HOUSE, C. *Angular 2 versus React: There Will Be Blood*. 2016. Disponível em: [<https:// www.freecodecamp.org/news/angular-2-versus-react-there-will-be-blood-66595faafd51>](https://www.freecodecamp.org/news/angular-2-versus-react-there-will-be-blood-66595faafd51)

KUROSE, J. F.; ROSS, K. W. *Redes de Computadores e a internet: Uma abordagem top-down*. 3. ed. São Paulo, SP: Editora Pearson, 2006.

MAGRANI, E. *Internet das coisas*. 1. ed. Rio de Janeiro,Brasil: FGV EDITORA, 2018. Disponível em: [<https://books.google.com.br/books?hl=pt-BR&lr=&id= qYtlDwAAQBAJ&oi=fnd&pg=PA1&dq=internet+das+coisas&ots=rgSvBwh959&sig= ZaOg-dOO_botZ4fIpLQPBSYECiE#v=onepage&q=internet%20das%20coisas&f= false>.](https://books.google.com.br/books?hl=pt-BR&lr=&id=qYtlDwAAQBAJ&oi=fnd&pg=PA1&dq=internet+das+coisas&ots=rgSvBwh959&sig=ZaOg-dOO_botZ4fIpLQPBSYECiE#v=onepage&q=internet%20das%20coisas&f=false)

MCROBERTS, M. *Arduino Basico*. 2. ed. Sao Paulo, Brasil: Novatec Editora Ltda., 2015. Disponível em: [<https://www.google.com.br/books/edition/Arduino_B%C3%A1sico/ kfZyDwAAQBAJ?hl=pt-BR&gbpv=1>](https://www.google.com.br/books/edition/Arduino_B%C3%A1sico/kfZyDwAAQBAJ?hl=pt-BR&gbpv=1)

Meta Platforms. *React - uma biblioteca javascript para criar interfaces de usuário*. 2022. Disponível em: [<https://pt-br.reactjs.org/>](https://pt-br.reactjs.org/)

OLIVEIRA, C. L. V.; ZANETTI, H. A. P.; NABARRO, C. B. M. *Raspberry PI descomplicado*. 1. ed. São Paulo - SP: Saraiva Educação, 2018.

PADO. *Fechadura Digital de Sobrepor com Cartão RFID FDS-50.* 2020. [2022]. 1 fotografia. Disponível em: [<https://www.lojapado.com.br/ -fechadura-eletrica-digital-cartao-rfid-sobrepor-/p>.](https://www.lojapado.com.br/-fechadura-eletrica-digital-cartao-rfid-sobrepor-/p)

ROTH, D.; ANDERSON, R.; LUTTIN, S. *Visão geral do ASP.NET Core*. [S.l.], 2022. Disponível em: [<https://docs.microsoft.com/pt-br/aspnet/core/ introduction-to-aspnet-core?view=aspnetcore-6.0>.](https://docs.microsoft.com/pt-br/aspnet/core/introduction-to-aspnet-core?view=aspnetcore-6.0) 

USINAINFO. *ESP32*. 2022. Disponível em: [<https://www.usinainfo.com.br/esp32-611#:~:text=O%20ESP32%20%C3%A9%20um%20pequeno,destaca%2Dse%20dentre% 20tantos%20outros.>](https://www.usinainfo.com.br/esp32-611#:~:text=O%20ESP32%20%C3%A9%20um%20pequeno,destaca%2Dse%20dentre%20tantos%20outros.)

WEBER, R. H. *Internet of Things: Legal Perspectives*. 2010th. ed. Berlin,Heidelberg: Springer, 2010. Disponível em: [<https://link.springer.com/chapter/10.1007/ 978-3-642-11710-7_1>.](https://link.springer.com/chapter/10.1007/978-3-642-11710-7_1)

WIKIPEDIA. *RaspberryP.* 2019. [2022]. 1 fotografia. Disponível em: [<https://pt.wikipedia.org/wiki/RaspberryP>.](https://pt.wikipedia.org/wiki/RaspberryP) 

WITTEL. *Robôs de autoatendimento: conheça o potencial dos bots*. Blog Wittel, 2017. Disponível em: [<https://blog.wittel.com/ robos-de-autoatendimento-conheca-o-potencial-dos-bots/>.](https://blog.wittel.com/robos-de-autoatendimento-conheca-o-potencial-dos-bots/) 

## Repositórios

[https://github.com/nicolas-souza/Moises_WebApp.git](https://github.com/nicolas-souza/Moises_WebApp.git)

[https://github.com/nicolas-souza/Moises_Api](https://github.com/nicolas-souza/Moises_Api)

[https://github.com/nicolas-souza/Moises_bot](https://github.com/nicolas-souza/Moises_bot)

[https://github.com/nicolas-souza/Moises_fechadura](https://github.com/nicolas-souza/Moises_fechadura)