Visão de camadas

Neste tipo de visão a arquitetura é dividida em unidades chamadas camadas, mos- trando esses elementos e as relações entre eles. Este tipo de visão ajuda a trazer atributos de modicabilidade e portabilidade para a arquitetura que está sendo denida (CLEMENTS et al., 2010).

A Figura 17 mostra a visão de camadas da arquitetura proposta. Para a denição dela utilizou-se as camadas identicadas na Seção 3.3.7 e na visão tecnológica mostrada na Seção 3.4. Assim, ela é composta por quatro camadas:

Figura 17: Visão de camadas da arquitetura. Fonte: autoria própria.

• IoT Layer: responsável pelo monitoramento dos pacientes através de dispositivos de sensoriamento;

• Application Layer: responsável pelo acesso e manipulação dos dados médicos dos pacientes e pelo controle de privacidade dos mesmos por usuários nais. Vale ressaltar que nesta arquitetura de software, o termo application (aplicação) sempre é utilizado para se referir a programas projetados para serem utilizados por usuários nais (pacientes, enfermeiras, médicos, etc.);

• Fog Layer: responsável pelo gerenciamento e armazenamento de um subconjunto de dados dos pacientes mais próximo das aplicações. Esta camada também se en- carrega de receber dados gerados pelos dispositivos da IoT Layer e pelos sistemas da Application Layer. Por m, ela é encarregada de validar o acesso ao subconjunto de dados armazenados no domínio dela;

• Cloud Layer: camada encarregada do armazenamento do conjunto completo de dados médicos dos pacientes, das informações de aplicações proprietárias de dados e das autorizações para acesso a eles. Ademais, ela provê a documentação dos da- dos gerenciados na solução, disponibilizando a estrutura dos tipos de dados que podem ser manipulados e a descrição das interfaces que devem ser utilizadas para manipulação dos mesmos.

Interagindo com a IoT Layer estão os vários tipos de dispositivos identicados na Seção 3.3.7, os quais realizam o monitoramento dos pacientes gerando dados sobre a saúde deles. Relacionando-se com a Application Layer estão os sistemas que manipulam dados sobre a saúde dos pacientes. Esses sistemas podem ser utilizados por pacientes, médicos, enfermeiros, familiares, equipe de resgate, equipe hospitalar, entre outros.

4.3.2 Visões de decomposição

Uma visão de decomposição é usada para mostrar como as responsabilidades de um sistema são divididas entre os módulos e como esses módulos são decompostos em sub- módulos (CLEMENTS et al., 2010).

Ao mesmo tempo, de acordo com Clements et al. (2010), combinar visões é uma estratégia que permite um melhor entendimento do sistema como um todo. Logo, se as visões forem dissociadas umas das outras, ninguém será capaz de entender o sistema como um todo.

Assim, nesta seção utiliza-se o conceito de visão de decomposição combinado com o de visão de camadas, decompondo-a em módulos. Em seguida, visões de decomposições desses módulos são descritas, mostrando-se os submódulos que os compõem.

4.3.2.1 Visão de decomposição das camadas

A Figura 18 mostra a visão de decomposição das quatro camadas descritas na Se- ção 4.3.1. Nela podemos ver que a IoT Layer é formada por dois tipos de módulos: os Sensors e os IoT Gateways. Os módulos do tipo Sensor representam cada um dos dispositivos que são responsáveis pelo monitoramento dos pacientes, gerando dados sobre as condições dos mesmos.

Já os IoT Gateways são elementos de software encarregados de receber os dados bru- tos gerados nos sensores. Eles também são responsáveis por realizar pré-processamentos nos dados brutos, objetivando eliminar informações desnecessárias e ruídos. Em adição, eles realizam conversões de dados, transformando os dados brutos dos sensores nas es- truturas de registros médicos denidas na Cloud Layer. Esses módulos também devem solicitar e receber as concessões de autorização para enviar essas informações à Fog Layer. Assim, estes são um dos tipos de módulos que implementam os requisitos RF2 e RF5.

A Application Layer também é composta por dois tipos de módulos. O primeiro deles são as Patient Applications, as quais representam elementos de software que permitem

Figura 18: Visão de decomposição das camadas. Fonte: autoria própria.

ao paciente visualizar os dados relativos aos seus Registros Pessoais de Saúde e através do qual ele pode gerenciar esses dados. Assim, por meio de um módulo desse tipo, o paciente controla quais aplicações podem manipular (ler e/ou alterar) os dados dele, contribuindo para o atendimento do RNF1. Um módulo do tipo Patient Application funciona como uma carteira digital (Wallet) do Blockchain. Assim, através da criação de transações, ele realiza o seu registro e concede acesso aos seus dados. Dessa forma, este módulo proporciona o atendimento dos requisitos RF1, RF3 e RF4.

Stakeholder Applications são o segundo tipo de módulos da Application Layer. Eles representam elementos de software que são encarregados de manipular um subconjunto de dados de um paciente e para fazer isso eles precisam solicitar acesso a essas informações. Desse modo, eles também implementam os requisitos RF2 e RF5. Um módulo do tipo Stakeholder Application realiza as solicitações de acesso e recebe as concessões para essa tarefa por meio de transações do Blockchain. Logo, eles também são carteiras digitais do Blockchain. Além disso, estes módulos são encarregados de enviar as alterações feitas nos dados do paciente para a Fog Layer.

A Fog Layer é formada por um conjunto de módulos chamados Fog Nodes. Estes módulos são elementos de software que fornecem serviços para manter um subconjunto de Registros Pessoais de Saúde dos pacientes mais próximo das aplicações. Portanto, eles auxiliam no provimento do requisito RNF4.

Os Fog Nodes devem executar isolados em contêineres e podem ser implantados em componentes físicos virtualizados (switches, roteadores, pequenos servidores, etc.) locali- zados geogracamente entre as coisas e a nuvem.

Além disso, esses módulos são encarregados do processo de vericação de autoriza- ção para que Stakeholder Applications e IoT Gateways possam manipular os Registros Pessoais de Saúde de um paciente. Assim, apenas módulos que tenham sido previamente autorizados por um paciente podem realizar manipulações nos registros médicos dele. Logo, os Fog Nodes ajudam no atendimento do requisito RNF2.

Ao mesmo tempo, a arquitetura denida neste trabalho utiliza a estratégia de consenso Proof of Authority, descrita anteriormente na Seção 2.4.1. Nesse sentido, um Fog Node funciona como um nó do Blockchain. Logo, um módulo desse tipo recebe as transações e as compartilha na rede para que elas possam ser validadas por nós que representam as autoridades.

Fog Nodes também são encarregados de receber os dados gerados em Stakeholder Applications e IoT Gateways. Para isso, este módulo disponibiliza uma interface REST, fornecendo acesso por meio das operações POST, GET, PUT e DELETE, capacidade que contribui no atendimento do RNF3. Por m, eles sincronizam o subconjunto de dados e as autorizações com a Cloud Layer.

Data Documentation, Medical Records Managment e Authorization Tran- sactions Management são os módulos que compõem a Cloud Layer. O primeiro é um elemento de software encarregado de disponibilizar a estrutura dos Registros Pessoais de Saúde gerenciados pela solução, bem como a descrição das interfaces disponibilizadas para manipulação desses dados. Logo, esse é um dos módulos que contribuem para o atendi- mento do requisito RNF3. Vale ressaltar que, a denição das estruturas dos Registros Pessoais de Saúde é responsabilidade da instituição de saúde que venha a instanciar a arquitetura denida neste trabalho.

O Medical Records Managment é um elemento de software que tem como função manter todo o conjunto de Registros Pessoais de Saúde dos pacientes. Além disso, este módulo é encarregado de receber da Fog Layer novos dados e disponibilizar para essa camada acesso aos dados por ele armazenados. Assim, este módulo também fornece uma interface REST para disponibilizar as operações de manipulação dos dados.

O Authorization Transactions Management é formado por elementos de software que funcionam como Authorities na rede Blockchain, validando as transações geradas na rede e selando-as em blocos. Ademais, esses elementos armazenam o conjunto completo das transações de registro de aplicações do paciente e das transações de autorização. Por m, este módulo também mantém o registro dos Fog Nodes que fazem parte da solução, de modo que apenas os Fog Nodes registrados nele podem interagir com o Medical Records

Managment.

4.3.2.2 Visão de decomposição dos módulos

No intuito de prover um maior detalhamento da arquitetura projetada, as Figuras 19, 20 e 21 mostram a decomposição dos módulos existentes nas camadas IoT, Application e Fog em submódulos.

A Figura 19 mostra a visão de decomposição dos módulos da IoT Layer em submó- dulos. Com ela, pode-se ver que os módulos IoT Gateways são formados por cinco tipos de submódulos, os quais são:

Figura 19: Visão de decomposição dos módulos da IoT Layer em submódulos. Fonte: autoria própria.

• Data Receiver: representa um elemento de software encarregado de receber os dados brutos coletados a partir de sensores. Um submódulo deste tipo deve ser capaz de entender os variados protocolos de comunicação utilizados pelos sensores que precisem se conectar ao módulo IoT Gateway do qual ele faz parte. Logo, ele disponibiliza interfaces para esses protocolos de comunicação, permitindo que os dados brutos dos sensores sejam recebidos pelo IoT Gateway. Por m, o Data Receiver é incumbido de repassar os dados recebidos a um Data Filter;

• Data Filter: corresponde a um elemento de software encarregado de realizar ltra- gens nos dados recebidos pelo Data Receiver. Assim, ele tem a atribuição de denir, detectar e corrigir erros nesses dados. Após o processo de ltragem, ele repassa os dados a um Data Converter;

• Data Converter: representa um elemento de software incumbido de aplicar con- versões nos dados recebidos pelo IoT Gateway, colocando-os nas estruturas de re- gistros médicos denidas no módulo Data Documentation da Cloud Layer. Além disso, este submódulo faz a conversão dos dados brutos para o formato JSON e os adaptam para as terminologias denidas no Data Documentation. Desse modo, este submódulo contribui para o provimento do RNF3. Por m, ele repassa os dados convertidos a um Data Sender;

• Data Sender: corresponde a um elemento de software encarregado de enviar a Fog Layer os dados recebidos pelo IoT Gateway do qual ele faz parte. Este processo de envio de dados é realizado utilizando o procolo HTTPS e, nele, o Data Sender utiliza as permissões concedidas pelo próprio paciente e recebidas pelo Digital Wallet; • Digital Wallet: representa um elemento de software que implementa uma carteira

digital do Blockchain. Assim, ele é encarregado de enviar transações solicitando permissão para inserir os dados coletados pelos sensores no Registro Pessoal de Saúde do paciente e de receber as transações de autorização concedidas pelo paciente para que o IoT Gateway possa realizar essa tarefa.

Na Figura 20 é mostrada a visão de decomposição dos módulos da Application Layer em submódulos. Como já mencionado anteriormente na Seção 4.3.2.1, essa camada é formada por dois tipos de módulos, os quais são compostos por seis tipos de submódulos:

Figura 20: Visão de decomposição dos módulos da Application Layer em submódulos. Fonte: autoria própria.

• User Interface (UI): é um elemento de software que permite a interação do usuá- rio com a aplicação, permitindo que o mesmo possa solicitar a realização de ações

e o possibilitando de visualizar o resultado das mesmas. Assim, este é o submódulo que permite ao usuário visualizar o envio e recebimento de transações. Além disso, através dele um usuário pode visualizar os registros médicos mantidos na solução e, em módulos do tipo Stakeholder Application, inserir, alterar e remover dados sobre a saúde do(s) paciente(s);

• Controller: representa um elemento de software responsável por interpretar os eventos gerados na UI e solicitar a realização das ações necessárias para o provimento das respostas a esses eventos;

• Business: corresponde a um elemento de software encarregado de executar todas as regras de negócio necessárias ao funcionamento da aplicação da qual ele faz parte. De modo que, este é o submódulo responsável por solicitar conversões de dados ao Data Converter, requisitar manipulações de dados ao Data Access, solicitar o envio de transações a Digital Wallet e receber transações dessa última. Vale ressaltar, que em Patient Applications as regras de negócio executadas por este submódulo devem se restringir a leitura de dados, conforme denido nos requisitos funcionais. Em contrapartida, as regras executadas em Stakeholder Applications também podem abranger alteração, inserção e remoção de novos dados;

• Data Converter: representa um elemento de software incumbido de aplicar con- versões nos dados manipulados pela aplicação. Assim, este submódulo é encarregado de entender a semântica dos dados trocados com a Fog Layer realizando as transfor- mações necessárias ao funcionamento da aplicação. Para isso, ele deve obedecer as padronizações denidas no Data Documentation da Cloud Layer e ser capaz de in- terpretar as terminologias para representação dos registros médicos denidas nesse módulo. Portanto, este submódulo contribui para o atendimento do RNF3 nas aplicações. É importante salientar que em aplicações do tipo Patient Application, o Data Converter deve realizar apenas as conversões dos dados recebidos a partir da Fog Layer para o formato e terminologia utilizados no módulo. Já em Stakeholder Applications, este submódulo também precisa realizar conversões a m de preparar os dados gerados nesses módulos para serem recebidos na Fog Layer. Logo, o Data Converter deve colocar os novos registros médicos gerados nesse tipo de aplicações no padrão de estruturas e terminologia denidos pelo Data Documentation;

• Data Access: corresponde a um elemento de software que representa um cliente encarregado de requisitar manipulações (leitura e/ou escrita) de Registros Pessoais de Saúde à Fog Layer. Em módulos do tipo Patient Application, este submódulo

apenas realiza requisições de leitura aos dados do paciente usuário da aplicação. Em contrapartida, em módulos do tipo Stakeholder Application, este submódulo também pode requisitar outros tipos de manipulações de dados (inserções, alterações e/ou remoções), conforme autorizado previamente pelo paciente proprietário do PHR. Por m, toda a comunicação realizada entre este submódulo e a Fog Layer utiliza as operações denidas no estilo REST e é feita sob o protocolo HTTPS;

• Digital Wallet: representa um elemento de software que implementa uma carteira digital do Blockchain. Logo, este submódulo é encarregado de realizar o envio e recebimento das transações que envolvem a aplicação da qual ele faz parte.

A Figura 21 mostra a visão de decomposição dos módulos que formam a Fog Layer, os chamados Fog Nodes. Como pode ser visto, cada módulo desse tipo é composto por oito submódulos, os quais são:

Figura 21: Visão de decomposição de um Fog Node em submódulos. Fonte: autoria própria.

• Blockchain Node: corresponde a um elemento de software encarregado de receber as transações geradas pelos submódulos Digital Wallet dos módulos Patient Appli- cation, Stakeholder Application e IoT Gateway e as compartilhar na rede para serem validadas pelos nós Authorities. Por m, toda a comunicação realizada entre este submódulo e as demais camadas da arquitetura se dá através do protocolo HTTPS; • Communication: este submódulo fornece uma interface REST para que as cama- das IoT Layer e Application Layer possam manipular os Registros Pessoais de Saúde

dos pacientes. Assim, este submódulo contribui para o atendimento da parte sintá- tica do RNF3. Em adição, toda comunicação entre este submódulo e as camadas Application Layer e IoT Layer é feita sob o protocolo HTTPS;

• Authorization: é um elemento de software responsável por vericar se um módulo que está solicitando uma operação ao Communication tem autorização para a re- alização da mesma. Este processo de vericação de autorização é feito através da análise de transações validadas, consultadas através do submódulo Blockchain Node. Assim sendo, este submódulo autoriza a realização da operação para módulos auto- rizados e impede a execução da operação para módulos não autorizados. Portanto, este é o submódulo de um Fog Node responsável pelo atendimento do RNF2; • Storage: é um elemento de software responsável por disponibilizar um subconjunto

de dados dos pacientes mais próximo das aplicações. Dessa forma, este submódulo contribui para o atendimento do RNF4;

• Replication: representa um elemento de software encarregado de replicar para um Fog Node próximo a ele, um subconjunto de dados (classicados como críticos) que esteja armazenado no Fog Node do qual ele faz parte. Dessa forma, este submódulo contribui para aumentar a disponibilidade dos dados, funcionando como uma técnica de tolerância a falhas implementada por meio de redundância de dados;

• Policies: é um elemento de software que gerencia informações relacionadas às polí- ticas de armazenamento no Fog Node. Assim, este submódulo mantém informações que dizem respeito à criticidade do dado, tempo da última utilização do mesmo, tempo de armazenamento do dado, entre outras. Essas informações são utilizadas para decidir quais deles deverão ser liberados primeiro da Fog Layer, quais devem ser mantidos armazenados nessa camada e quais tem maior prioridade com relação a sua disponibilização. Logo, este submódulo também contribui para o atendimento do RNF4;

• Synchronization: é um elemento de software responsável pela sincronização dos dados armazenados na Fog Layer com os dados armazenados na Cloud Layer. Desse modo, este submódulo é encarregado de enviar dados de tempos em tempos para Cloud Layer a m de mantê-los atualizados nessa camada. Ele também busca infor- mações requisitadas pela Application Layer que não estejam armazenadas no Fog Node. Além disso, o Synchronization é encarregado por liberar espaço para armaze- namento no Fog Node caso necessário, para isso ele utiliza as informações do Policies.

Por m, ele realiza busca prévia de dados que serão utilizados nas aplicações para prover melhor desempenho na entrega dessas informações as mesmas. Portanto, ele também contribui para o atendimento do RNF4;

• Data Compression: corresponde a um elemento de software encarregado de rea- lizar, quando necessário, compressões de dados, reduzindo o número de bits neces- sários para representá-los. Desse modo, este submódulo contribui para a diminuição do volume de dados envidados do Synchronization para a Cloud Layer.