Departamento de Informática e Matemática Aplicada Programa de Pós-Graduação em Sistemas e Computação
Doutorado em Sistemas e Computação
Um Estilo Arquitetural Baseado na Norma ISO/IEC
30141 para Sistemas de Internet das Coisas
Lidiane Oliveira dos Santos
Natal-RN Maio 2020
Um Estilo Arquitetural Baseado na Norma ISO/IEC 30141 para
Sistemas de Internet das Coisas
Tese de Doutorado apresentada ao Programa de Pós-Graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte como requisito para a obtenção do grau de Doutora em Sistemas e Computação.
Linha de pesquisa: Engenharia de Software
Orientadora
Prof.
aDra. Thais Vasconcelos Batista
PPgSC – Programa de Pós-Graduação em Sistemas e Computação DIMAp – Departamento de Informática e Matemática Aplicada
CCET – Centro de Ciências Exatas e da Terra UFRN – Universidade Federal do Rio Grande do Norte
Natal-RN Maio 2020
Universidade Federal do Rio Grande do Norte - UFRN Sistema de Bibliotecas - SISBI
Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Ronaldo Xavier de Arruda - CCET
Santos, Lidiane Oliveira dos. Um estilo arquitetural baseado na Norma ISO/IEC 30141 para sistemas de internet das coisas / Lidiane Oliveira dos Santos. - 2020.
173f.: il.
Tese (Doutorado) - Universidade Federal do Rio Grande do Norte, Centro de Ciências Exatas e da Terra, Programa de Pós-Graduação em Sistemas e Computação. Natal, 2020. Orientador: Thais Vasconcelos Batista. 1. Computação - Tese. 2. Internet das coisas - Tese. 3. Arquitetura de software - Tese. 4. Estilo arquitetural - Tese. I.
“Um Estilo Arquitetural Baseado na Norma ISO/IEC 30141 para Sistemas de Internet das Coisas”
Esta Tese foi julgada adequada para a obtenção do título de doutor em Ciência da Computação e aprovada em sua forma final pelo Programa de Pós-Graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte.
À minha mãe, Elza Barboza Lopes de Oliveira (In memoriam)
Agradeço primeiramente a Deus, por me permitir chegar até aqui. Aos meus pais e a todos os professores que passaram pela minha vida, por todo o conhecimento compartilhado e ensinamentos que se tornaram minha base educacional.
Agradeço em especial a minha orientadora Thais Batista por conduzir sabiamente o desenvolvimento deste trabalho, por me guiar por esse longo caminho esclarecendo minhas dúvidas, compartilhando suas experiências, me aconselhando inclusive no campo pessoal. Você foi mais que uma orientadora!
Aos professores Jair Leite, Flavio Oquendo e Everton Ranielly pelas sugestões que contribuíram para tornar este trabalho mais sólido.
Ao meu amigo e companheiro de desenvolvimento Eduardo Silva por todo o suporte durante a realização deste trabalho, pelo conhecimento compartilhado, pela ajuda nos artigos, nas implementações e pelos conselhos nos momentos mais difíceis. Você foi muito importante para a concretização deste trabalho!
Aos meus colegas de estudos e laboratório, Bartira, Luana, Jéssica, Jhoseph, Jorge, Camila e Thiago pelo apoio e incentivo.
A todos os alunos que se voluntariaram para participar dos experimentos controlados: Fagner, Larysse, Sávio, Camila, Stéfano, Sérgio, Shirley, Naubert, Murilo e Valmir.
A CAPES pelo apoio financeiro despendido a este trabalho.
Por fim, agradeço a todos que contribuíram direta ou indiretamente para a elaboração deste trabalho.
“Um impossível por vez” (Fábio Maca)
Sistemas de Internet das Coisas
Autor: Lidiane Oliveira dos Santos Orientadora: Prof.a Dra. Thais Vasconcelos Batista
Resumo
A Internet das Coisas (Internet of Things – IoT) vem contribuindo para uma nova revolução tecnológica, promovendo expressivo impacto social. A ideia básica de IoT é permitir conectividade, interação e integração de objetos inteligentes endereçáveis de forma única, que colaboram uns com os outros para atingir objetivos comuns. Embora IoT seja um paradigma promissor para a integração de dispositivos e tecnologias de comunicação, é necessário rever os métodos tradicionais de desenvolvimento de software, considerando as particularidades exigidas pelos sistemas de IoT. Dado o papel fundamental da arquitetura de software no desenvolvimento de sistemas intensivos de software, os desafios relacionados ao desenvolvimento de sistemas de IoT devem ser considerados desde o nível arquitetural. Arquiteturas de software permitem que os stakeholders raciocinem sobre as decisões do projeto antes da implementação, definam restrições, analisem atributos de qualidade e sejam melhor orientados em termos de manutenção e evolução do sistema. No contexto de arquitetura de software, os estilos arquiteturais têm um papel primordial uma vez que especificam os elementos arquiteturais comumente utilizados por uma determinada família de sistemas, juntamente com um conjunto de restrições sobre como esses elementos devem ser usados. Portanto, um estilo arquitetural fornece um ponto de partida para uma modelagem coerente da arquitetura de software, permitindo o reuso de elementos e de um conjunto de decisões arquiteturais previamente definidas e validadas, facilitando o processo de modelagem da arquitetura. A literatura dispõe de muita informação sobre IoT e estilos arquiteturais, porém, existe uma lacuna na integração dos mesmos. As vantagens proporcionadas pelo uso de estilos arquiteturais podem beneficiar a especificação arquitetural de sistemas de IoT, porém, até o
contexto de arquitetura de software para sistemas de IoT, a norma ISO/IEC 30141 propõe um modelo de referência e uma arquitetura de referência para sistemas de IoT, e representa um consenso internacional sobre arquitetura de software para IoT. Porém, tal norma não define um estilo arquitetural. Visando preencher essa lacuna, o principal objetivo deste trabalho é a definição e automatização de um estilo arquitetural que ofereça diretrizes para a modelagem da arquitetura de software de sistemas de IoT, em conformidade com a norma ISO/IEC 30141. A especificação do estilo é realizada usando a linguagem SysADL, uma Linguagem de Descrição Arquitetural (ADL) voltada para a modelagem de sistemas intensivos de software. Esse trabalho também apresenta avaliações do estilo proposto, realizadas através de: (i) uma avaliação de expressividade do estilo utilizando o framework proposto por PATIG (2004), (ii) uma avaliação de usabilidade do estilo, utilizando o framework Cognitive Dimensions of Notation (CDN) (BLACKWELL; GREEN, 2003) e (iii) uma avaliação experimental por meio de dois experimentos controlados para avaliar os efeitos proporcionados pelo uso do estilo. Palavras-chave: Internet das Coisas, Arquitetura de Software, Estilo Arquitetural, Linguagem de Descrição Arquitetural.
Author: Lidiane Oliveira dos Santos Supervisor: Prof.a Dra. Thais Vasconcelos Batista
Abstract
The Internet of Things (IoT) has been contributing to a new technological revolution, promoting a significant social impact. The basic idea of IoT is to enable connectivity, interaction, and integration of uniquely addressable intelligent objects that collaborate with each other to achieve common goals. Although IoT is a promising paradigm for the integration of communication devices and technologies, it is necessary to review the traditional methods of software development considering the particularities required by IoT systems. Given the fundamental role of software architecture in the development of intensive software systems, the challenges related to the development of IoT systems must be considered since the architectural level. A software architecture allows stakeholders to reason about project decisions prior to implementation, define constraints, analyze quality attributes, and be better oriented in terms of system maintenance and evolution. In the context of software architecture, architectural styles have a key role since they specify the architectural elements commonly used by a particular class of systems, along with a set of constraints on how these elements are to be used. Therefore, an architectural style provides a starting point for a coherent modeling of the software architecture, allowing the reuse of elements and a set of previously defined and validated architectural decisions, thus facilitating the architecture modeling process. The literature has much information about IoT and architectural styles, but there is a gap in their integration. The advantages offered by the use of architectural styles can benefit the architectural specification of IoT systems, but there is still no specific architectural style for this type of system in the literature. In the context of software architecture for IoT systems, the ISO/IEC 30141 standard proposes a reference model and a reference architecture for IoT systems, and represents an international consensus on software architecture for IoT. However,
this work is the definition and automation of an architectural style that offers guidelines for modeling the software architecture of IoT systems, in accordance with the ISO/IEC 30141 standard. The style is specified using the SysADL language, an Architectural Description Language (ADL) focused on the modeling of intensive software systems. This work also presents evaluations of the proposed style, performed through: (i) an evaluation of expressiveness of the style using the framework proposed by PATIG (2004), (ii) a usability evaluation of the style using the Cognitive Dimensions of Notation (CDN) framework (BLACKWELL; GREEN, 2003) and (iii) an experimental evaluation using two controlled experiments to evaluate the effects provided by the use of style.
Keywords: Internet of Things, Software Architecture, Architectural Style, Architectural Description Language.
1 Classe de estilos arquiteturais de IoT (MUCCINI; MOGHADDAM, 2018) ... p. 27 2 Arquitetura de referência IoT proposta por GUTH et al. (2016) ... p. 28 3 Relação entre Capítulos, Publicações e Questões de Pesquisa ... p. 32 4 Viewpoints e Views (OQUENDO; LEITE; BATISTA, 2016) ... p. 34 5 Relação entre Modelo de Referência, Arquitetura de Referência e Arquitetura Concreta (Adaptado de BASS, CLEMENTS e KAZMA (2003)) ... p. 35 6 Diagramas da visão estrutural (a) Diagrama de Definição de Blocos (b) Diagrama de Blocos Interno ... p. 37 7 Diagramas da visão comportamental (a) Diagrama de Definição de Blocos (b) Diagrama de Atividades (c) Diagrama Paramétrico ... p. 38 8 Diagrama da visão executável ... p. 38 9 Relação entre os diagramas de SysADL e SysML (Adaptado de LEITE, BATISTA e OQUENDO (2017)) ... p. 39 10 Tabela de Alocação ... p. 40 11 Definições do estilo arquitetural Cliente-Servidor em SysADL (a) BDD de componentes (b) BDD de portas (c) BDD de conectores (d) Diagramas de atividades dos conectores (e) Diagrama de protocolo das portas (Adaptado de OQUENDO, LEITE e BATISTA (2016)) ... p. 42 12 Visão geral da IoT enfatizando as aplicações específicas de domínio e a integração horizontal entre elas (AL-FUQAHA et al., 2015) ... p. 44 13 Os elementos da IoT (AL-FUQAHA et al., 2015) ... p. 45 14 Estrutura da IoT RA (ISO/IEC, 2018) ... p. 46 15 Modelo conceitual da IoT (ISO/IEC, 2018) ... p. 47 16 Modelo de referência para IoT (ISO/IEC, 2018) ... p. 48 17 Visão funcional da arquitetura de referência para IoT (ISO/IEC, 2018) ... p. 50 18 Visão de sistema da arquitetura de referência para IoT (ISO/IEC, 2018)... p. 51 19 Visão de comunicação da arquitetura de referência para IoT (ISO/IEC, 2018) ... p. 51 20 Visão de informação da arquitetura de referência para IoT (ISO/IEC, 2018) ... p. 53
22 Sub-papéis e atividades do Provedor de Serviços IoT (ISO/IEC, 2018) ... p. 54 23 Sub-papéis e atividades do Desenvolvedor de Serviços IoT (ISO/IEC, 2018) ... p. 54 24 Sub-papéis e atividades do Usuário IoT (ISO/IEC, 2018) ... p. 54 25 Etapas do Mapeamento Sistemático ... p. 57 26 Etapas do processo de seleção dos estudos primários (SANTOS et al., 2019) ... p. 61 27 Busca Automática - Número de estudos por biblioteca digital ... p. 62 28 Busca Manual - Número de estudos por fonte da literatura ... p. 63 29 Publicações ao longo dos anos (SANTOS et al., 2019) ... p. 64 30 Abstrações Arquiteturais vs. Requisitos para Modelagem Arquitetural (SANTOS et al., 2019) ... p. 68 31 Menção vs. representação de requisitos nos estudos (SANTOS et al., 2019)... p. 70 32 Percentual de estudos que abordam cada requisito (SANTOS et al., 2019) ... p. 70 33 Loop Mape-K (BELHAJ; BELAÏD; MUKHTAR, 2017) ... p. 78 34 Relações entre as entidades do modelo conceitual definido na norma ISO/IEC 30141 e os elementos do estilo IoT ... p. 79 35 Visão funcional da arquitetura de referência definida na norma ISO/IEC 30141 e as camadas relacionadas ao estilo IoT (Adaptado de ISO/IEC (2018)) ... p. 81 36 Visão de sistema da arquitetura de referência definida na norma ISO/IEC 30141 e as camadas relacionadas ao estilo IoT (Adaptado de ISO/IEC (2018)) ... p. 82 37 Visão de comunicação da arquitetura de referência definida na norma ISO/IEC 30141 e as camadas relacionadas ao estilo IoT (Adaptado de ISO/IEC (2018)) ... p. 82 38 Visão de informação da arquitetura de referência definida na norma ISO/IEC 30141 e as camadas relacionadas ao estilo IoT (Adaptado de ISO/IEC (2018)) ... p. 83 39 IBD SysADL com exemplo genérico de arquitetura baseada no estilo IoT ... p. 84 40 BDD SysADL com as definições dos elementos do estilo IoT... p. 85 41 Comportamento das portas PresenceOPT e PresenceIPT ... p. 86 42 Comportamento dos conectores SensorDataCN e ActuatorCommandCN ... p. 87 43 Atividades abstratas que representam o comportamento do estilo IoT ... p. 87 44 Activity Protocol do estilo IoT ... p. 88 45 Ambiente SysADL Studio ... p. 88 46 Sequência de atividades para utilização de estilos arquiteturais na ferramenta SysADL Studio ... p. 89 47 Instanciação do estilo IoT ... p. 89
49 Referência aos elementos do estilo ... p. 91 50 Verificação das restrições do estilo ... p. 91 51 Sistema Smart Place implantado – (a) dispositivo de hardware instalado em uma sala (b) visão da câmera (c) interface aplicação web da plataforma Smart Place ... p. 95 52 Definição de componentes do Smart Place em um BDD estrutural SysADL em conformidade com o estilo IoT ... p. 97 53 Definição de conectores do Smart Place em um BDD SysADL em conformidade com o estilo IoT ... p. 98 54 IBD SysADL do componente SmartPlaceARCH ... p. 99 55 IBD SysADL do componente RaspberryPiCP ... p. 100 56 IBD SysADL do componente GatewayCP ... p. 101 57 Definição de atividades do Smart Place em um BDD comportamental SysADL em conformidade com o estilo IoT ... p. 102 58 Tabela de alocação do sistema Smart Place... p. 103 59 Angel Wristband – (a) pulseira (b) smartphone exibindo os dados rastreados ... p. 104 60 Definição de componentes do Angel Wristband em um BDD SysADL em conformidade com o estilo IoT ... p. 105 61 Definição de conectores do Angel Wristband em um BDD SysADL em conformidade com o estilo IoT... p. 106 62 IBD dos componentes WristbandARCH, WristbandCP e SmartphoneCP ... p. 107 63 Definição de atividades do Angel Wristband em um BDD comportamental SysADL em conformidade com o estilo IoT ... p. 108 64 Tabela de alocação do sistema Angel Wristband ... p. 108 65 Definição de componentes do Smart Home em um BDD estrutural SysADL em conformidade com o estilo IoT ... p. 111 66 Definição de conectores do Smart Home em um BDD SysADL em conformidade com o estilo IoT ... p. 112 67 IBD SysADL do componente SmartHomeARCH ... p. 113 68 IBD SysADL do componente DoorControllerDeviceCP ... p. 114 69 IBD SysADL do componente LightControllerDeviceCP ... p. 114 70 IBD SysADL do componente AirCondControllerDeviceCP... p. 115 71 IBD SysADL do componente FireControllerDeviceCP ... p. 115 72 IBD SysADL do componente GatewayCP ... p. 116
conformidade com o estilo IoT ... p. 117 74 Tabela de alocação do sistema Smart Home ... p. 117 75 Organização do quadrado latino ... p. 130 76 Análise qualitativa do experimento I ... p. 141 77 Análise qualitativa do experimento II ... p. 146
1 Publicações derivadas desta tese ... p. 31 2 Características dos sistemas de IoT (ISO/IEC, 2018) ... p. 46 3 Fontes da literatura consideradas na busca manual (SANTOS et al., 2019) ... p. 59 4 Critérios de inclusão e exclusão para os procedimentos de busca automática e manual (SANTOS et al., 2019) ... p. 60 5 Estudos primários selecionados (Adaptado de SANTOS et al. (2019)) ... p. 64 6 Distribuição dos estudos de acordo com os requisitos arquiteturais das aplicações de IoT (SANTOS et al., 2019) ... p. 65 7 Requisitos arquiteturais de IoT vs. Estudos (SANTOS et al., 2019) ... p. 67 8 Portas dos componentes do estilo IoT ... p. 75 9 Conectores do estilo IoT ... p. 76 10 Restrições do estilo IoT ... p. 77 11 Requisitos arquiteturais de IoT vs. Elementos do estilo IoT... p. 92 12 Statements de IoT definidos em COSTA (2019) ... p. 121 13 Tarefas definidas para a avaliação da sintaxe concreta (Adaptado de SANTOS et al. (2020b)) ... p. 123 14 Dimensões consideradas na avaliação e resultados observados (Adaptado de SANTOS et al. (2020b))... p. 124 15 Hipóteses avaliadas ... p. 133 16 Questionário de opinião sobre o uso do estilo IoT ... p. 137 17 Vantagens e desvantagens do estilo IoT relatadas pelos participantes no experimento I... p. 142 18 Duração, modularidade, acoplamento e coesão no experimento I ... p. 144 19 Estatística descritiva das métricas de modularidade, acoplamento e coesão no experimento I... p. 144
21 Duração, modularidade, acoplamento e coesão no experimento II ... p. 148 22 Estatística descritiva das métricas de modularidade, acoplamento e coesão no experimento II ... p. 149
ADL – Architectural Description Language ALF – Action Language for Foundational UML BDD – Block Definition Diagrams
DEPML – Deployment View Modeling Language DSL – Domain-Specific Language
GQM - Goal–Question–Metric IBD – Internal Block Diagram IMD – Instituto Metrópole Digital IoT – Internet of Things
IoT RA – IoT Reference Architecture OCL - Object Constraint Language SAL – Srijan Architecture Language
SAML – Software Architecture View Modeling Language SDL – Srijan Deployment Language
SOA – Service-Oriented Architecture
SoaML – Service-Oriented Architecture Modeling Language SysML – Systems Modelling Language
SoS – Systems of Systems
1 Introdução p. 23 1.1 Contextualização ... p. 23 1.2 Motivação ... p. 25 1.3 Objetivos ... p. 29 1.4 Questões de pesquisa ... p. 30 1.5 Relação entre Questões de Pesquisa, Capítulos e Publicações ... p. 31 1.6 Estrutura do documento ... p. 32
2 Conceitos básicos p. 33
2.1 Arquitetura de Software ... p. 34 2.2 SysADL ... p. 36 2.3 Estilo Arquitetural ... p. 40 2.4 Internet das Coisas ... p. 43 2.4.1 Norma ISO/IEC 30141 ... p. 45 2.4.1.1 Características e Modelo Conceitual ... p. 46 2.4.1.2 Modelo de Referência ... p. 48 2.4.1.3 Arquitetura de Referência ... p. 50 2.5 Considerações Finais ... p. 55 3 Mapeamento Sistemático p. 56 3.1 Metodologia de Pesquisa ... p. 56 3.1.1 Questões de Pesquisa ... p. 58 3.1.2 Estratégia de Busca ... p. 58 3.1.3 Critérios de Seleção ... p. 60
3.2 Processo de Seleção... p. 61 3.3 Análise dos Resultados ... p. 63 3.3.1 Requisitos Arquiteturais das Aplicações de IoT (RQ1) ... p. 63 3.3.2 Abordagens Existentes e a Representação dos Requisitos Arquiteturais das
Aplicações de IoT (RQ2) ... p. 67 3.4 Discussões ... p. 70 3.5 Ameaças à Validade ... p. 71 3.6 Considerações Finais ... p. 72 4 Um Estilo Arquitetural para Sistemas de Internet das Coisas p. 73 4.1 Estilo IoT – Visão Conceitual ... p. 74 4.1.1 Elementos do Estilo IoT ... p. 74 4.1.2 Restrições do Estilo IoT ... p. 76 4.2 Estilo IoT e a Norma ISO/IEC 30141 ... p. 79 4.3 Estilo IoT em SysADL ... p. 83 4.3.1 Visão Estrutural ... p. 84 4.3.2 Visão Comportamental ... p. 86 4.3.3 Suporte Ferramental ... p. 88 4.4 Considerações Finais ... p. 92 5 Provas de Conceito p. 94 5.1 Smart Place ... p. 94 5.1.1 Visão Estrutural ... p. 96 5.1.2 Visão Comportamental ... p. 101 5.2 Angel Wristband ... p. 104 5.2.1 Visão Estrutural ... p. 105
5.3 Smart Home ... p. 109 5.3.1 Visão Estrutural ... p. 110 5.3.2 Visão Comportamental ... p. 116 5.4 Considerações Finais ... p. 119
6 Avaliação p. 120
6.1 Avaliação da Sintaxe Abstrata ... p. 120 6.2 Avaliação da Sintaxe Concreta ... p. 123 6.3 Avaliação Experimental ... p. 128 6.3.1 Definição do Projeto Experimental ... p. 128 6.3.2 Planejamento ... p. 129 6.3.2.1 Seleção dos Participantes ... p. 129 6.3.2.2 Seleção das Variáveis ... p. 131 6.3.2.3 Definição das Hipóteses ... p. 133 6.3.2.4 Sistema Alvo ... p. 134 6.3.2.5 Instrumentação ... p. 136 6.3.2.6 Ameaças à Validade ... p. 138 6.3.3 Execução dos Experimentos ... p. 139 6.3.4 Resultados do Experimento I ... p. 140 6.3.4.1 Análise Qualitativa ... p. 141 6.3.4.2 Análise Quantitativa ... p. 143 6.3.5 Resultados do Experimento II ... p. 145 6.3.5.1 Análise Qualitativa ... p. 145 6.3.5.2 Análise Quantitativa ... p. 147 6.3.6 Discussões ... p. 149
7 Conclusão p. 153 7.1 Contribuições ... p. 154 7.2 Revisitando as Questões de Pesquisa ... p. 155 7.3 Limitações ... p. 156 7.4 Trabalhos Futuros ... p. 157
Referências p. 158
Apêndice A – Restrições do estilo IoT em OCL p. 164
1
Introdução
Este Capítulo contextualiza o problema tratado por esse trabalho, estabelece os objetivos e questões de pesquisa, e fornece uma visão geral do trabalho. A Seção 1.1 introduz os conceitos necessários à compreensão do trabalho. A Seção 1.2 discute as necessidades do domínio que motivaram a realização deste trabalho. A Seção 1.3 apresenta os objetivos. A Seção 1.4 apresenta as questões de pesquisa. A Seção 1.5 relaciona as questões de pesquisa, com os capítulos subsequentes e as publicações decorrentes desta tese. Por fim, a Seção 1.6 descreve a estrutura do documento.
1.1
Contextualização
Nos dias de hoje, conectividade e tecnologia estão se tornando cada vez mais onipresentes e acessíveis. Estamos caminhando para uma sociedade na qual tudo e todos estarão conectados e essa possibilidade permitirá novos tipos de aplicações, serviços e formas de interação que nunca imaginamos antes (ZHENG et al., 2011). Nos próximos anos, bilhões de objetos heterogêneos, distribuídos e inteligentes estarão conectados à Internet (CICCOZZI; SPALAZZESE, 2016).
A Internet das Coisas (Internet of Things - IoT) conecta objetos do mundo real adicionando inteligência para processar informações e tomar decisões úteis de forma autônoma (HUANG; LI, 2010b). A tendência crescente é que a IoT promova um impacto social, tanto na nossa maneira de trabalhar quanto de viver, além de abrir uma gama de novas possibilidades, como, por exemplo, novos modelos de negócios e ecossistemas. A ideia básica deste conceito é a presença generalizada de uma variedade de objetos inteligentes, endereçáveis de forma única (como sensores, atuadores, tags, telefones celulares, etc.), capazes de interagir uns com os outros e cooperar para alcançar objetivos comuns (ATZORI; IERA; MORABITO, 2010). Adicionar inteligência a objetos do cotidiano permite-os coletar informações do ambiente, interagir ou controlar o mundo físico e trocar informações através da Internet (BORGIA, 2014).
Embora a IoT seja um paradigma promissor para a integração de dispositivos e tecnologias de comunicação, suas características introduzem novos desafios para a Engenharia de Software, sendo necessário revisitar os métodos tradicionais de desenvolvimento (MOTTA; OLIVEIRA; TRAVASSOS, 2018). Sistemas de IoT possuem uma natureza distribuída e em tempo real, interagem com muitos sistemas externos e processam grandes volumes de dados. Além disso, é necessário lidar com heterogeneidade, que envolve tanto o hardware quanto o software, e a limitação de recursos, como capacidade de armazenamento e processamento, de alguns dispositivos. Sistemas de IoT também devem atender a determinados atributos de qualidade como escalabilidade, modificabilidade, segurança, usabilidade, entre outros. Lidar com todas essas características tornam os sistemas de IoT complexos e desafiadores.
A arquitetura de software é parte fundamental de uma solução de software, sendo considerada o eixo central de qualquer sistema intensivo de software, assumindo um papel importante na qualidade desses sistemas (BASS; CLEMENTS; KAZMAN, 2003). Uma arquitetura de software permite que os stakeholders raciocinem sobre as decisões do projeto antes da implementação, definam restrições, analisem atributos de qualidade e sejam melhor orientados em termos de manutenção e evolução do sistema. Dado o papel fundamental das arquiteturas de software no desenvolvimento de sistemas complexos bem-sucedidos, os desafios relacionados ao desenvolvimento de sistemas de IoT devem ser enfrentados desde o nível arquitetural (BORGIA, 2014) (MOTTA; OLIVEIRA; TRAVASSOS, 2018).
Para a modelagem da arquitetura de software, as linguagens de descrição arquitetural (Architectural Description Language - ADL) (SHAW; GARLAN, 1996) (CLEMENTS, 1996) (MEDVIDOVIC; TAYLOR, 2000) são bastante utilizadas. ADLs são linguagens de alto nível para representar e analisar projetos arquiteturais, provendo um framework conceitual e uma notação sintática para caracterizar arquiteturas de software em termos de seus elementos e relacionamentos, que são essencialmente componentes, conectores e configurações. O padrão internacional ISO/IEC/IEEE 42010 (ISO/IEC/IEEE, 2011) especifica os requisitos que uma linguagem arquitetural deve atender para ser considerada uma ADL.
No contexto de IoT, segundo LEITE, BATISTA e OQUENDO (2017), uma ADL para a modelagem de sistemas de IoT deve dar suporte à:
Modelagem de dispositivos heterogêneos como elementos abstratos; Modelagem de dispositivos ativos e autônomos;
Especificação das conexões e comunicação entre um número indeterminado de dispositivos heterogêneos;
Fácil modificação da arquitetura para refletir as modificações e evoluções do sistema; Especificação de um modelo de arquitetura escalável, permitindo o aumento do número
de dispositivos constituintes.
Ainda de acordo com LEITE, BATISTA e OQUENDO (2017), a linguagem SysADL (OQUENDO; LEITE; BATISTA, 2016) atende a estes requisitos, fornecendo abstrações arquiteturais adequadas para modelar sistemas de IoT. SysADL é uma ADL baseada em SysML (Systems Modelling Language) (OBJECT MANAGEMENT GROUP, 2019a) para sistemas intensivos de software. SysADL une os princípios da engenharia de sistemas utilizados por SysML, às abstrações das ADLs, como componentes, conectores e configurações, permitindo uma representação mais precisa desses elementos arquiteturais. Além disso, SysADL está em conformidade com a norma ISO/IEC/IEEE 42010 (ISO/IEC/IEEE, 2011) e possui uma semântica operacional que permite a verificação da consistência e integridade das arquiteturas. SysADL define três visões que permitem a visualização da arquitetura de software de um sistema sob diferentes perspectivas: (i) estrutural, (ii) comportamental e (iii) executável.
SysADL possui suporte ferramental fornecido por SysADL Studio (LEITE et al., 2018), uma ferramenta gratuita e de código aberto que implementa múltiplas visões, verificação de propriedades, validação, execução e simulação de arquitetura. Nos últimos anos, a ferramenta SysADL Studio tem sido utilizada com sucesso por estudantes e pesquisadores em ambientes acadêmicos no Brasil e na França, o que contribuiu para a avaliação da ferramenta por meio de experimentos controlados.
1.2
Motivação
A abordagem seguida pelas engenharias mais maduras (por exemplo, Engenharia Civil e Química) é construir sistemas (por exemplo, edifícios ou fábricas de produtos químicos) a partir de soluções conhecidas, como projetos comprovados e componentes existentes (KOGUT; CLEMENTS, 1995). A Engenharia de Software também segue esta abordagem e normalmente utiliza arquitetura de software para especificar avaliar o sistema antes que ele seja construído, evitando problemas nas fases mais avançadas do processo de desenvolvimento. Modelos da
arquitetura do sistema são ferramentas importantes para aplicar soluções conhecidas, reutilizar componentes e fazer avaliações antecipadas.
No contexto da reutilização de soluções conhecidas, um pilar importante da arquitetura de software são os estilos arquiteturais. Um estilo arquitetural é a especificação dos elementos arquiteturais e tipos de relacionamentos, juntamente com um conjunto de restrições sobre como estes devem ser usados (BASS; CLEMENTS; KAZMAN, 2003). Um estilo arquitetural fornece um ponto de partida para uma modelagem coerente da arquitetura de software de uma determinada família de sistemas, permitindo o reuso de elementos e de um conjunto de decisões arquiteturais previamente definidas e validadas. O arquiteto de software pode identificar o estilo arquitetural que mais se adequa ao sistema a ser modelado com base nas características dos seus elementos (componentes e conectores), na topologia da arquitetura, nas restrições semânticas e nos mecanismos de interação entre os componentes.
A literatura dispõe de muita informação sobre IoT e estilos arquiteturais, porém existe uma lacuna na integração dos mesmos. O mapeamento sistemático realizado por MUCCINI e MOGHADDAM (2018) mostrou que estilos arquiteturais genéricos, como Pipes-and-Filters, Client-Server, entre outros, são usados na modelagem de sistemas de IoT e que, até o momento em que o estudo foi realizado, não haviam propostas na literatura de um estilo arquitetural específico para sistemas de IoT.
Além do mapeamento sistemático, MUCCINI e MOGHADDAM (2018) propuseram uma classe de estilos arquiteturais para IoT, composta por quatro tipos de estilos que seguem o estilo Camadas, conforme apresentado na Figura 1. Existem de três a quatro camadas, a saber: (i) Perception, que representa os sensores e atuadores; (ii) Processing and Storage, que representa o armazenamento e análise dos dados coletados pela camada inferior (Perception), os quais serão disponibilizados para outras entidades e utilizados por outras aplicações; (iii) Application, que representa a classe de serviços prestados pela IoT e, opcionalmente; (iv) Business, referente à criação de modelos de negócios com informações derivadas da camada Application. Não foi realizada uma especificação detalhada desses estilos, descrevendo seus elementos nem como eles se relacionam semanticamente através de restrições, o que, de acordo com BASS, CLEMENTS e KAZMAN (2003), é fundamental na caracterização de um estilo.
Figura 1: Classe de estilos arquiteturais de IoT (MUCCINI; MOGHADDAM, 2018) CROES (2015) classificou algumas aplicações de IoT em nove classes e realizou um mapeamento associando cada classe a estilos arquiteturais. Esse mapeamento considerou nove estilos: Client-Server, Peer-to-Peer, Pipes-and-Filters, Event-Based, Publish-Subscribe, Service-Oriented, REST, Layered e Microkernel. A escolha dos estilos baseou-se nos mais utilizados e melhor documentados. A análise da adequação dos estilos foi baseada na satisfação dos atributos de qualidade exigidos por cada classe de aplicação IoT, de acordo com os níveis de prioridade. Em média, o estilo Client-Server adequou-se à maioria das classes. Porém, nenhum estilo considerado no mapeamento é específico para sistemas de IoT e, até onde sabemos, nada foi proposto nesse sentido.
Existem algumas propostas de arquiteturas de referência para IoT na literatura (BAUER et al., 2013) (ZHENG et al., 2009) (GUTH et al., 2016). Um exemplo é a arquitetura de referência abstrata proposta por GUTH et al. (2016), que foi derivada de uma comparação de várias plataformas de IoT, incluindo soluções de código aberto, bem como proprietárias. Essa arquitetura de referência para IoT é composta pelos componentes Sensor, Actuator, Device, Driver, Gateway, IoT Integration Middleware e Application, conforme ilustrado na Figura 2. Arquiteturas de referência fornecem a caracterização das funcionalidades de sistemas de software com relação a um determinado domínio de aplicação, enquanto estilos arquiteturais
definem restrições sobre a estrutura e comportamento de uma família de instâncias de arquiteturas. Portanto, arquiteturas de referência e estilos arquiteturais têm utilidades diferentes e podem ser utilizados juntos.
Figura 2: Arquitetura de referência IoT proposta por GUTH et al. (2016)
A norma ISO/IEC 30141 (ISO/IEC, 2018) especifica uma arquitetura de referência genérica para IoT. Ela descreve (i) as características dos sistemas de IoT, (ii) um modelo conceitual que representa os elementos que fazem parte do sistema e seus relacionamentos, (iii) um modelo de referência e (iv) cinco visões da arquitetura de referência. Esta norma representa um consenso sobre o que é a IoT a nível internacional, independentemente de tecnologias, porém, ela não define um estilo arquitetural.
As vantagens proporcionadas pelo uso de estilos arquiteturais podem beneficiar a especificação arquitetural de sistemas de IoT. Um estilo arquitetural para IoT pode complementar os artefatos definidos na norma ISO/IEC 30141 (ISO/IEC, 2018), uma vez que estilos arquiteturais possuem uma finalidade diferente das arquiteturas de referência e podem, inclusive, ser utilizados em conjunto. Além disso, a norma ISO/IEC 30141 (ISO/IEC, 2018) fornece uma base sólida e confiável para a definição de um estilo arquitetural a partir de seus elementos.
Os benefícios que um estilo arquitetural de IoT pode trazer para a indústria de software envolvem aspectos de qualidade, como modularidade, o próprio direcionamento arquitetural
que os estilos promovem, guiando o projeto arquitetural, auxilia os arquitetos e evita que algum elemento ou comportamento básico de IoT seja esquecido, além de reduzir os esforços na tomada de decisões arquiteturais ao longo do projeto. Prover um suporte ferramental para o estilo também pode ser um diferencial que facilitaria sua utilização e a verificação de suas restrições. O que observamos na maioria dos estilos arquiteturais e arquiteturas de referência existentes é a ausência de suporte ferramental, onde se faz necessário buscar informações em suas documentações e utilizá-las manualmente. A possibilidade de verificar de forma automatizada se a arquitetura implementa o estilo corretamente, permite ao arquiteto identificar e corrigir possíveis pontos de desconformidade e garante que todos os projetos arquiteturais, após validados, seguem o mesmo padrão de comportamento básico dos sistemas de IoT.
1.3
Objetivos
Visando suplantar as limitações supracitadas, o principal objetivo deste trabalho é a definição e automatização de um estilo arquitetural que ofereça diretrizes para a modelagem da arquitetura de software de sistemas de IoT, compatível com a norma ISO/IEC 30141 (ISO/IEC, 2018). Um estilo IoT fornecerá ao arquiteto um ponto de partida para uma modelagem coerente, reduzindo a complexidade que envolve esse processo. A especificação do estilo IoT será realizada através da linguagem SysADL. A escolha por SysADL baseou-se no fato desta ser uma ADL voltada para a modelagem de sistemas intensivos de software, que inclui abstrações arquiteturais adequadas para a modelagem de sistemas de IoT (OQUENDO; LEITE; BATISTA, 2016), além de possuir suporte ferramental que permite a representação de múltiplas visões, verificação de propriedades, validação, execução e simulação de arquitetura.
O estilo IoT proposto possui dois diferenciais que podem contribuir a sua disseminação na indústria, a saber, (i) o fato do estilo IoT ser baseado em uma norma, uma vez que os industriais consideram as normas como uma maneira de aumentar a qualidade a produtividade, e (ii) a automatização do estilo IoT em uma ferramenta, que utiliza a linguagem SysADL, uma linguagem que foi baseada em SysML também com o propósito de permear na indústria.
Realizar um mapeamento sistemático para identificar os requisitos relevantes à modelagem arquitetural de sistemas de IoT e como as abordagens existentes expressam arquiteturas que atendem a esses requisitos;
Definir os elementos (componentes e conectores) e restrições do estilo arquitetural IoT com base: (i) no modelo conceitual de IoT definido pela norma ISO/IEC 30141 (ISO/IEC, 2018), (ii) nos requisitos arquiteturais de IoT identificados no mapeamento sistemático, e (iii) nas informações obtidas a partir de trabalhos relacionados;
Especificar o estilo IoT na linguagem SysADL definindo a estrutura e comportamento dos elementos arquiteturais do estilo;
Implementar o suporte a estilos arquiteturais na ferramenta SysADL Studio, estendendo o suporte ferramental de SysADL ao uso de estilos;
Avaliar o estilo arquitetural;
1.4
Questões de pesquisa
Para alcançar o objetivo geral, é fundamental responder algumas questões de pesquisa, descritas a seguir.
Questão 1: Quais os requisitos essenciais para a modelagem arquitetural de sistemas de IoT?
Questão 2: Quais elementos caracterizam sistemas de IoT e como esses elementos normalmente se relacionam?
Questão 3: Quais os benefícios e limitações do estilo IoT para a modelagem arquitetural de sistemas de IoT?
Para responder a Questão 1 foi conduzido um mapeamento sistemático. Para responder a Questão 2 foram investigadas as abordagens atuais que envolvem soluções de arquitetura de software para IoT e a norma ISO/IEC 30141 (ISO/IEC, 2018). Para responder a Questão 3 foram realizados dois experimentos controlados com o objetivo de avaliar de forma prática os efeitos do uso do estilo IoT no projeto arquitetural. Além disso, uma vez que o estilo IoT foi concretizado na linguagem SysADL, avaliamos o impacto da associação do estilo a linguagem em termos de expressividade, aplicando o framework proposto por PATIG (2004), e usabilidade, através do framework CDN (BLACKWELL; GREEN, 2003).
1.5
Relação entre Questões de Pesquisa, Capítulos e
Publicações
A Tabela 1 apresenta as publicações geradas durante o desenvolvimento do trabalho, que contém as respostas para as questões de pesquisas propostas neste trabalho. A Figura 3 apresenta a relação entre capítulos, questões de pesquisas e publicações.
Tabela 1: Publicações derivadas desta tese
Evento ou Periódico Id Título Autores IEEE International
Conference on Software Architecture Companion
ICSA’18 Designing and Executing Software Architectures Models Using SysADL Studio
Eduardo Silva, Lidiane Santos, Victor Cortez, Jair Leite, Thais Batista, Flavio Oquendo
IEEE International Conference on Software Architecture Companion
ICSA’19 Identifying Requirements for Architectural Modeling in Internet of Things Applications
Lidiane Santos, Eduardo Silva, Jorge Pereira, Thais Batista, Jair Leite, Everton Cavalcante
ACM/SIGAPP
Symposium On Applied Computing
SAC’20 An Architectural Style for Internet of Things Systems
Lidiane Santos, Eduardo Silva, Thais Batista, Jair Leite, Everton Cavalcante, Flavio Oquendo
IEEE World Forum on Internet of Things
WFIoT’20 Evaluating a SysML-Based Graphical Notation for Modeling Internet of Things System Architectures
Lidiane Santos, Eduardo Silva, Thais Batista, Jair Leite, Everton Cavalcante, Flavio Oquendo
Future Generation Computer Systems, to be submitted
FGCS’20 Taming Internet of Things Software Architecture
Lidiane Santos, Eduardo Silva, Thais Batista, Jair Leite, Everton Cavalcante, Flavio Oquendo
Figura 3: Relação entre Capítulos, Publicações e Questões de Pesquisa
1.6
Estrutura do documento
O restante deste documento está estruturado como segue. O Capítulo 2 provê os fundamentos para a compreensão deste trabalho e foca em apresentar os conceitos básicos sobre IoT, arquitetura de software, estilos arquiteturais e a linguagem SysADL. O Capítulo 3 descreve o mapeamento sistemático sobre os requisitos arquiteturais dos sistemas de IoT. O Capítulo 4 especifica o estilo IoT e demonstra sua concretização na linguagem SysADL. O Capítulo 5 apresenta as provas de conceito, que consistem no projeto arquitetural de três sistemas reais de IoT utilizando o estilo IoT. O Capítulo 6 descreve o processo de avaliação do estilo IoT e os resultados obtidos. Por fim, Capítulo 7 apresenta as conclusões e trabalhos futuros.
2
Conceitos básicos
Este Capítulo apresenta os principais conceitos relacionados a este trabalho. A Seção 2.1 descreve os conceitos relacionados à arquitetura de software. A Seção 2.2 apresenta a linguagem SysADL. A Seção 2.3 descreve o conceito de estilo arquitetural. A Seção 2.4 introduz o conceito de IoT e descreve a norma ISO/IEC 30141. A Seção 2.5 apresenta as considerações finais.
2.1
Arquitetura de Software
Segundo BASS, CLEMENTS e KAZMA (2003), arquitetura de software é o conjunto de estruturas necessárias para raciocinar sobre o sistema, que compreende elementos de software (por exemplo, serviços, componentes, módulos), as propriedades desses elementos visíveis externamente (ou seja, o comportamento de cada elemento) e as relações entre eles.
A arquitetura de software representa o primeiro nível do mapeamento de requisitos para componentes computacionais, possibilitando avaliar em alto nível a viabilidade de alcançar os requisitos com o projeto proposto (KOGUT; CLEMENTS, 1995). Além disso, as arquiteturas de software desempenham um papel fundamental na determinação da qualidade do sistema. De acordo com NAKAGAWA, OQUENDO e BECKER (2012), as decisões tomadas no nível arquitetural interferem diretamente no alcance dos objetivos de negócio, bem como nos requisitos funcionais e de qualidade.
Um conceito chave em arquitetura de software é o de viewpoint. Todos os interesses dos stakeholders são mapeados em viewpoints. Cada viewpoint está associado uma ou mais visões (views) da arquitetura, definindo as construções, incluindo regras e convenções, para a definição das visões (OQUENDO; LEITE; BATISTA, 2016). Uma visão arquitetural compreende um ou mais modelos de arquitetura de software. Tais modelos são o que o stakeholder vê quando observa a modelagem do sistema através de um viewpoint específico. A norma ISO/IEC/IEEE 42010 (ISO/IEC/IEEE, 2011) enfatiza que visões são essenciais para
representar todos os interesses dos stakeholders e detalhar a arquitetura sob diferentes perspectivas. A Figura 4 ilustra três viewpoints, onde cada um possui uma visão.
Figura 4: Viewpoints e Views (OQUENDO; LEITE; BATISTA, 2016)
A arquitetura de software pode ser documentada através de descrições arquiteturais (ISO/IEC/IEEE, 2011) e ADLs (SHAW; GARLAN, 1996) (CLEMENTS, 1996) (MEDVIDOVIC; TAYLOR, 2000) são usadas para essa finalidade. As ADLs utilizam notações gráficas e/ou textuais para expressar componentes e relacionamentos arquiteturais. Segundo MEDVIDOVIC e TAYLOR (2000), ADLs propõem uma sintaxe e uma estrutura conceitual que permite caracterizar uma arquitetura de forma não ambígua para prover representações formais da arquitetura de software. Além disso, as ADLs geralmente possuem suporte ferramental, que permite a criação, modificação, análise e simulação da arquitetura.
As ADLs descrevem a arquitetura em termos de componentes, conectores e configurações. Componentes são elementos arquiteturais responsáveis por prover as funcionalidades de um sistema. Um componente pode ser simples, fornecendo uma funcionalidade simples, ou composto, ou seja, um componente que é composto por outros componentes. Um componente possui portas claramente definidas, que são pontos de interação entre ele e o meio externo. Portas especificam os dados que um componente provê ou requer de outros componentes na arquitetura. Conector é o elemento responsável por mediar a interação entre os componentes. Conectores definem quais portas podem ser conectadas e como as interações entre os componentes conectados ocorrem. Configurações descrevem a topologia, identificando quais componentes fazem parte de uma arquitetura e como eles são conectados por meio de conectores.
Outros conceitos relevantes em arquitetura de software são: modelo de referência, arquitetura de referência e arquitetura concreta. Um modelo de referência é um framework abstrato destinado a promover a compreensão de uma classe de problemas, porém não fornece soluções específicas para esses problemas (ISO/IEC, 2018). Um modelo de referência não está relacionado a quaisquer padrões, tecnologias ou outros detalhes concretos de implementação (MACKENZIE et al., 2006), mas fornece uma semântica comum que pode ser usada sem ambiguidades em diferentes implementações. O modelo de referência é útil para padronizar os objetos que compõem o modelo e seus relacionamentos, orientar e melhorar a comunicação entre os stakeholders, definir papéis e responsabilidades claras e permitir a comparação de diferentes entidades (ISO/IEC, 2018). Um exemplo concreto de modelo de referência será apresentado na seção 2.4.1.2, que descreve o modelo de referência para IoT definido pela norma ISO/IEC 30141 (ISO/IEC, 2018).
De acordo com BASS, CLEMENTS e KAZMAN (2003), uma arquitetura de referência é um modelo de referência mapeado em entidades de arquitetura de software (que implementam as funcionalidades definidas no modelo de referência) e nos fluxos de dados entre eles. Uma arquitetura de referência possui um conjunto de melhores práticas de desenvolvimento de software (por exemplo, decisões arquiteturais, restrições, legislação e padrões) relacionadas a um determinado domínio de aplicação, que podem ser adotadas, sistematicamente, em todos os projetos de uma organização. A função da arquitetura de referência é fornecer uma base a partir da qual os projetos possam iniciar seu ciclo de vida. Um exemplo real de arquitetura de referência será apresentado na seção 2.4.1.3, que descreve a arquitetura de referência para IoT definida, a partir do modelo conceitual, pela norma ISO/IEC 30141 (ISO/IEC, 2018).
Arquiteturas de referência, quando instanciadas, dão origem a arquiteturas concretas, conforme ilustrado na Figura 5.
Figura 5: Relação entre Modelo de Referência, Arquitetura de Referência e Arquitetura Concreta (Adaptado de BASS, CLEMENTS e KAZMA (2003))
2.2
SysADL
SysADL (OQUENDO; LEITE; BATISTA, 2016) é uma ADL baseada em SysML (Systems Modelling Language) (OBJECT MANAGEMENT GROUP, 2019a), projetada para suportar múltiplas visões arquiteturais, verificação, validação e execução da arquitetura. SysADL une a semântica rigorosa das ADLs aos princípios da engenharia de sistemas utilizados por SysML, para a modelagem de sistemas intensivos de software. Além disso, SysADL está em conformidade com a norma ISO/IEC/IEEE 42010 (ISO/IEC/IEEE, 2011), que representa um padrão internacional sobre os requisitos de uma ADL.
SysADL define três visões da arquitetura de software de um sistema: (i) estrutural, (ii) comportamental e (iii) executável. Na visão estrutural, os elementos arquiteturais que compõem a estrutura de um sistema – componente, portas e conectores – e os relacionamentos entre eles são definidos. A comunicação entre componentes ocorre por meio de conectores que ligam portas de entrada e saída. Em SysADL todos os elementos devem ser declarados antes de serem instanciados. A declaração dos elementos é realizada no Diagrama de Definição de Blocos (Block Definition Diagrams - BDD). A instanciação dos elementos é realizada no Diagrama de Blocos Interno (Internal Block Diagram - IBD), que especifica como as instâncias de componentes e conectores formam a configuração da arquitetura. A Figura 6a apresenta um exemplo básico de BDD estrutural, com declarações de componentes, portas, conectores e tipos de dados, enquanto a Figura 6b ilustra o IBD do componente composto “RTC_System”, onde foram instanciados seus subcomponentes e estabelecidas as devidas conexões entre os subcomponentes através da instanciação dos conectores declarados no BDD.
A visão comportamental é responsável por detalhar o comportamento de componentes, conectores e portas. O comportamento de componentes e conectores é definido por atividades (activity), enquanto o comportamento das portas é definido por protocolos (protocol). Instâncias de protocolos são descritas no Diagrama de Protocolo. Atividades são compostas por ações (actions). O Diagrama de Atividades detalha cada atividade, permitindo a instanciação das ações, a representação dos fluxos de dados entre as ações e os parâmetros da atividade, bem como o uso de elementos como buffer e datastore para representar o armazenamento de dados. Atividades e ações podem possuir restrições (constraint) associadas, responsáveis pela validação de um comportamento esperado, especificadas através de
expressões ALF (Action Language for Foundational UML) (OBJECT MANAGEMENT GROUP, 2019b). O Diagrama Paramétrico é responsável por expressar as restrições.
Figura 6: Diagramas da visão estrutural (a) Diagrama de Definição de Blocos (b) Diagrama de Blocos Interno
A Figura 7a apresenta um exemplo básico de BDD comportamental, com a declaração de uma atividade, ação e restrição. A Figura 7b ilustra o diagrama de atividades da atividade ControllerAC, onde foi instanciada a ação que compõe a atividade e estabelecidas as devidas conexões entre os pins da ação e os parâmetros da atividade. A Figura 7c apresenta o diagrama paramétrico, que associa os pins da ação aos parâmetros da restrição.
Na visão executável, é possível especificar detalhes de cada ação a nível de implementação, através de instruções (statements) ALF. Elementos executáveis também podem ser declarados e instanciados. A Figura 8 apresenta um exemplo básico de BDD executável, com a declaração de um elemento executável correspondente à ação CommandCoolerAN, declarada no BDD comportamental. As instâncias de executáveis devem ser interpretadas por um mecanismo
(engine) ALF para executar a arquitetura. A execução de um modelo de arquitetura SysADL permite simular as operações do sistema a fim de verificar e analisar suas funcionalidades.
Figura 7: Diagramas da visão comportamental (a) Diagrama de Definição de Blocos (b) Diagrama de Atividades (c) Diagrama Paramétrico
Figura 8: Diagrama da visão executável
Além das três visões, SysADL também inclui: (i) Diagrama de Requisitos, para a especificação de requisitos funcionais e não funcionais; (ii) Diagrama de Casos de Uso, para
especificação das preocupações dos stakeholders; (iii) Diagrama de Pacotes, para organização dos elementos de acordo com cada viewpoint e (iv) Tabela de Alocação, para manter a rastreabilidade entre as visões.
A Figura 9 relaciona os diagramas de SysADL com os diagramas de SysML. SysADL e SysML compartilham os Diagramas de Pacotes, Requisitos e Casos de Uso. SysADL especializa o BDD, o IBD, o Diagrama de Atividades e o Diagrama Paramétrico. Esses diagramas foram especializados para permitir a representação de abstrações arquiteturais como componentes, portas, conectores, configuração, entre outras (LEITE; BATISTA; OQUENDO, 2017).
A Figura 10 apresenta um exemplo básico de tabela de alocação, onde é realizada uma associação da visão estrutural com a visão comportamental através da indicação de que a atividade ControllerAC corresponde ao componente ControllerAP e uma associação da visão comportamental com a visão executável, através da indicação de que o executável CommanCoolerEX corresponde a ação CommanCoolerAN.
Figura 9: Relação entre os diagramas de SysADL e SysML (Adaptado de LEITE, BATISTA e OQUENDO (2017))
Figura 10: Tabela de Alocação
SysADL possui suporte ferramental fornecido por SysADL Studio (LEITE et al., 2018), uma ferramenta gratuita e de código aberto que implementa múltiplas visões, verificação, validação, execução e simulação da arquitetura. Nos últimos anos, SysADL Studio tem sido utilizado com sucesso por estudantes e pesquisadores em ambientes acadêmicos no Brasil e na França, o que contribuiu para a avaliação da ferramenta por meio de experimentos controlados. Os diagramas apresentados nas Figuras 5, 6 e 7, além da tabela de alocação apresentada na Figura 10, foram produzidos na ferramenta SysADL Studio (disponível em sysadl.org).
2.3
Estilo Arquitetural
Um estilo arquitetural é a especificação dos elementos arquiteturais e tipos de relacionamentos, juntamente com um conjunto de restrições sobre como estes devem ser usados (BASS; CLEMENTS; KAZMAN, 2003). Um estilo arquitetural é expresso por um vocabulário de elementos em termos de tipos de componentes, conectores e configurações, determinando as composições permitidas de componentes e conectores (OQUENDO; LEITE; BATISTA, 2016). Além disso, um estilo arquitetural possui uma interpretação semântica associada, que permite a análise de arquiteturas projetadas de acordo com o estilo. Dessa forma, estilos arquiteturais definem famílias de arquiteturas (TAYLOR; MEDVIDOVIC; DASHOFY, 2009) restringidas por vocabulário, topologia e semântica de componentes e conectores (KOGUT; CLEMENTS, 1995). As restrições podem ser topológicas, por exemplo, não permitir ciclos, ou podem considerar a semântica de execução (GARLAN; SHAW, 1994).
No estilo arquitetural Cliente-Servidor, por exemplo, os componentes podem assumir dois papeis: cliente (consumidor de serviços) ou servidor (provedor de serviços). As restrições semânticas deste estilo definem o seguinte comportamento: (i) clientes não se comunicam com outros clientes, apenas com o servidor; (ii) componentes do tipo cliente enviam solicitações para o componente do tipo servidor através de um conector e aguardam uma resposta; (iii) o componente servidor recebe a solicitação do cliente e envia a resposta. O estilo Cliente-Servidor pode ser utilizado para modelar um sistema ou parte de um sistema que possui
componentes que enviam solicitações (clientes) para outro componente (servidor) que oferece serviços (OQUENDO; LEITE; BATISTA, 2016).
Para demonstrar a especificação do estilo Cliente-Servidor utilizaremos a linguagem SysADL. Para especificar o estilo Cliente-Servidor em SysADL, a estrutura do estilo deve ser definida por meio de BDDs com (i) componentes abstratos representando cliente e servidor (Figura 11a), (ii) portas abstratas (Figura 11b) e (iii) conectores abstratos (Figura 11c). Os relacionamentos entre os componentes são descritos em termos do protocolo que o servidor usa para se comunicar com os clientes. As definições de comportamento e de protocolos em SysADL são realizadas através de Diagramas de Atividades (Figura 11d) e Diagramas de Protocolos (Figura 11e).
O estilo arquitetural Cliente-Servidor é representado por um componente abstrato (ClientServerARCH), que representa o estilo como um todo, um componente servidor (ServerCP) e zero ou mais componentes cliente (ClientCP), conforme ilustrado na Figura 11a. Uma vez que a comunicação entre cliente e servidor segue o formato de solicitação e resposta (request-reply), as portas ClientCPT e ServerCPT são compostas por duas sub-portas, conforme ilustrado na Figura 11b. Para possibilitar a troca de informações entre as duas portas compostas é necessário um conector composto. O conector ClientServerCN é composto por dois conectores simples, ClientServerQueryCN e ClientServerAnswerCN, conforme ilustrado na Figura 11c. O conector ClientServerQueryCN possui duas portas participantes, transmitindo dados do cliente, através da porta QueryOPT, para o servidor, através da porta QueryPortIPT. O conector ClientServerAnswerCN possui duas portas participantes, transmitindo dados do servidor, através da porta AnswerOPT, para o cliente, através da porta QueryAnswerIPT.
O comportamento do conector ClientServerCN é definido pelo comportamento de seus conectores internos, através de Diagramas de Atividades. Os Diagramas de Atividades apresentados na Figura 11d expressam que os conectores enviam para seus pins de saída quaisquer dados recebidos em seus pins de entrada. O comportamento de cada porta é definido por meio de diagramas de protocolo. A Figura 11e mostra o Diagrama de Protocolo da porta ClientPT. A porta interna QueryOPT envia um valor de qualquer tipo para seu pin de saída e aguarda até que a porta AnswerIPT receba os dados. A porta interna AnswerIPT recebe os dados de seu pin de entrada e devolve o controle para a porta QueryOPT. O comportamento da porta ServerPT é semelhante, porém no sentido inverso.
Figura 11: Definições do estilo arquitetural Cliente-Servidor em SysADL (a) BDD de componentes (b) BDD de portas (c) BDD de conectores (d) Diagramas de Atividades dos
conectores (e) Diagrama de Protocolo das portas (Adaptado de OQUENDO, LEITE e BATISTA (2016))
Detalhes sobre as funcionalidades atribuídas aos clientes ou ao servidor não são definidos pelo estilo, uma vez que um estilo arquitetural deve ser abstrato e representar apenas os elementos essenciais para uma determinada família de sistemas, independente de domínio. O mesmo estilo arquitetural pode ser seguido por diferentes arquiteturas. Um estilo arquitetural não é uma arquitetura, mas transmite uma imagem útil do sistema, impondo restrições úteis à arquitetura. Através dessas restrições, o sistema é organizado e estruturado de maneira coerente e torna-se mais fácil de ser compreendido do que sistemas projetados sem regras (REUSSNER et al., 2016).
2.4
Internet das Coisas
A Internet evoluiu muito nos últimos anos, conectando bilhões de coisas globalmente. Estas coisas têm diferentes tamanhos, capacidades, poder de processamento e suportam diferentes tipos de aplicações (HUANG; LI, 2010a). A maioria dos dispositivos móveis possui diferentes sensores e atuadores, que permitem detectar, tomar decisões inteligentes e compartilhar informações úteis pela Internet (ZHOU; ZHANG, 2011). Assim, a Internet tradicional dá origem à Internet inteligente do futuro, chamada Internet das Coisas (Internet of Things - IoT) (ZHENG et al., 2011). A IoT fornece conectividade para qualquer pessoa, a qualquer hora e lugar, conectando a vida real ao mundo virtual. A ideia básica da IoT é permitir conexão e troca de dados de forma autônoma e segura entre dispositivos e aplicações do mundo real (FAN; CHEN, 2010).
A IoT consiste em um agregado substancial de várias partes. Isso implica que não há uma única solução de IoT, mas uma infinidade de opções que podem ser derivadas das coisas e de outros sistemas disponíveis (MOTTA; OLIVEIRA; TRAVASSOS, 2018). Segundo LI, HUANG e WANG (2011), uma rede IoT pode dar origem a uma variedade de aplicações e serviços que podem trazer benefícios pessoais, profissionais e econômicos significativos. Dentre os possíveis domínios de aplicações estão: Indústria, saúde, agricultura, ambientes inteligentes, previsão de desastres naturais, aviação, automotivo, telecomunicações, logística, cidades inteligentes, segurança, monitoramento do ambiente, transportes inteligentes, entre outros. A Figura 12 apresenta uma visão geral da IoT, onde cada aplicação específica de domínio (vertical markets) interage com serviços independentes de domínio (horizontal
markets), criados a partir de serviços analíticos e computação ubíqua. Em cada domínio, sensores e atuadores comunicam-se diretamente entre si.
Figura 12: Visão geral da IoT enfatizando as aplicações específicas de domínio e a integração horizontal entre elas (AL-FUQAHA et al., 2015)
De acordo com AL-FUQAHA et al. (2015), são necessários seis elementos para que as aplicações de IoT possam cumprir suas funcionalidades: identification, sensing, communication, computation, services and semantics, conforme ilustrado na Figura 13. O elemento identification é crucial para a IoT nomear e combinar serviços e demandas. Identificar os dispositivos unicamente permite aprimorá-lo com personalidades e outras informações, além de permitir que eles se conectem, monitorem, gerenciem e controlem outros dispositivos. O elemento sensing é responsável por coletar dados de objetos relacionados na rede, através de sensores. Os dados coletados são analisados e utilizados para realizar ações específicas com base nos serviços requeridos. O elemento communication é responsável por conectar objetos heterogêneos para fornecer serviços inteligentes específicos, ou seja, ele representa a capacidade de comunicação, interação e troca de informações. O elemento computation representa a capacidade computacional da IoT, materializada nas unidades de processamento, como microcontroladores e microprocessadores, responsáveis pelo processamento de dados. O
elemento services está relacionado à capacidade de as aplicações disponibilizarem determinadas funcionalidades como um serviço de forma independente. O elemento semantics refere-se à capacidade de extrair conhecimento dos dados recebidos de forma inteligente. Essa extração inclui o reconhecimento e a análise de dados, que embasará o processo de tomada de decisão necessário para que a aplicação forneça o serviço exato.
Figura 13: Os elementos da IoT (AL-FUQAHA et al., 2015)
Os sistemas de IoT evoluirão continuamente ao longo do tempo, mas também precisam enfrentar muitos desafios relacionados à escala, complexidade, heterogeneidade, privacidade, segurança, entre outros. Para enfrentar esses desafios é essencial que sejam tratados desde o nível arquitetural. Segundo MOTTA, OLIVEIRA e TRAVASSOS (2018), a arquitetura de software de sistemas de IoT merece maior atenção, uma vez que os limites entre hardware e software não são bem definidos nesse tipo de sistema. Além disso, a arquitetura deve refletir em sua concepção as preocupações sobre portabilidade e interoperabilidade, incluindo uma forma de orquestrar os dispositivos conectados, o que não é trivial (MOTTA; OLIVEIRA; TRAVASSOS, 2018). De acordo com BORGIA (2014), encontrar uma arquitetura escalável, flexível e segura, capaz de lidar com o complexo cenário de IoT, é uma das principais metas para a adoção desse paradigma. Nesse contexto, apresentamos a seguir a norma ISO/IEC 30141, que representa um consenso internacional sobre uma arquitetura de referência para IoT.
2.4.1. Norma ISO/IEC 30141
A norma ISO/IEC 30141 (ISO/IEC, 2018) especifica uma arquitetura de referência genérica para IoT em termos da especificação de: (i) características dos sistemas de IoT, (ii) modelo conceitual, (iii) modelo de referência, e (iv) cinco visões arquiteturais, conforme o esquema apresentado na Figura 14. A IoT RA (IoT Reference Architecture) fornece um conjunto coerente de orientações e normas internacionais para o desenvolvimento da arquitetura de software de sistemas de IoT.
Figura 14: Estrutura da IoT RA (ISO/IEC, 2018)
2.4.1.1. Características e Modelo Conceitual
A Tabela 2 lista as principais características dos sistemas de IoT estabelecidas pela norma. Sistemas de IoT podem implementar todas ou parte destas características.
A Figura 15 apresenta o modelo conceitual com as entidades-chave da IoT e seus relacionamentos. Um modelo conceitual fornece uma estrutura genérica, abstrata e simples, com definições comuns para descrever os conceitos e as relações entre as entidades dentro de um sistema.
Figura 15: Modelo conceitual da IoT (ISO/IEC, 2018)
O elemento IoT-User pode ser um ser humano (Human User) ou um usuário digital (Digital User), como robôs ou serviços de automação, que atuam em nome de usuários humanos. O usuário digital consome serviços (Service) que interagem através da rede de comunicação (Network). O usuário humano interage usando aplicações (Application), que são uma forma especializada de serviço. Algumas aplicações interagem com outros serviços através da rede.
A Entidade física (PhysicalEntity) é um objeto do mundo real que é controlado por um atuador (Actuator) ou monitorado por um sensor (Sensor). Uma entidade física pode ter uma Tag anexada e os sensores podem monitorar a tag em vez da própria entidade física. A Entidade
virtual (Virtual Entity) é uma representação digital de uma entidade física. Atuadores e sensores são tipos de dispositivos de IoT (IoT Device). Os dispositivos de IoT interagem através da rede e podem se comunicar diretamente ou através de um gateway (IoT Gateway), capaz de se conectar à Internet. Data Stores armazenam dados relacionados aos sistemas de IoT, que podem ser dados derivados de dispositivos, gateways ou serviços.
2.4.1.2. Modelo de Referência
A Figura 16 apresenta o modelo de referência para IoT definido pela norma ISO/IEC 30141 (ISO/IEC, 2018), derivado a partir do modelo conceitual. O Domínio de Objetos Físicos (Physical Object Domain) consiste nas entidades físicas e virtuais de um sistema de IoT, referenciadas no modelo conceitual como PhysicalEntity e VirtualEntity, respectivamente.
O Domínio de Controle e Detecção (Sensing & Controlling Domain) fornece informações sobre o ambiente para os outros domínios, além de poder manipular o estado dos objetos físicos por meio da atuação. Este domínio inclui os elementos IoT Device, Sensor, Actuator e IoT Gateway do modelo conceitual.
O Domínio de Gerenciamento e Operação (Operation & Management Domain) representa a coleção de funções responsáveis por manter a integridade geral dos sistemas de IoT e pelo provisionamento, gerenciamento, monitoramento e otimização do desempenho operacional dos sistemas em tempo real.
O Domínio de Serviço de Aplicação (Application Service Domain) contém todos os tipos de provedores de serviços envolvidos em um sistema de IoT. Este domínio inclui os elementos Service e Application do modelo conceitual. Os provedores de serviços formam um domínio de negócios dentro do Domínio de Serviço de Aplicação. Provedores de serviços interagem não apenas com os usuários no Domínio de Usuário para atender suas solicitações, mas também com entidades no Domínio de Controle e Detecção (ou seja, sensores e atuadores) para obter dados de entidades no Domínio de Entidade Física. Um stakeholder do Domínio de Operações e Gerenciamento pode se tornar um cliente de um provedor de serviços.
Através do Domínio de Intercâmbio e Recurso (Resource & Interchange Domain) provedores de serviços podem interagir com organizações externas, como outros sistemas e plataformas de IoT, autoridades policiais, serviços públicos, instituições financeiras e governamentais, etc. Para desempenhar seu papel, o Domínio de Intercâmbio e Recurso precisa de acesso aos recursos digitais com permissão de outros domínios.
Os usuários são os participantes e atores do Domínio de Usuário (User Domain). A principal função do Domínio de Usuário é fornecer acesso a serviços de IoT e informações sobre como usá-los. Este domínio inclui o elemento IoT-User do modelo conceitual. Portanto, usuários podem ser humanos, por exemplo, uma pessoa ou um grupo de pessoas, como uma família, uma sociedade ou uma organização, ou virtuais, por exemplo, interfaces homem-máquina, que fornecem a interface para o usuário acessar, subscrever e receber os serviços providos pelo Domínio de Serviço de Aplicação.
Embora as redes de comunicação entre domínios não sejam especificamente designadas como parte de um dos seis domínios, essas redes (elemento Network do modelo conceitual) desempenham um papel fundamental em um sistema de IoT. Dependendo da infraestrutura dos sistemas de IoT, as redes de comunicação entre domínios podem ser a rede local, a Internet, a Intranet, redes corporativas, redes de longa distância, entre outras.
