U NIVERSIDADE F EDERAL DE G OIÁS
I NSTITUTO DE I NFORMÁTICA
PAULO C ÉSAR F ERREIRA M ELO
CSVM: Uma Plataforma para
CrowdSensing Móvel Dirigida por
Modelos em Tempo de Execução
Goiânia
2014
U NIVERSIDADE F EDERAL DE G OIÁS
I NSTITUTO DE I NFORMÁTICA
AUTORIZAÇÃO PARA P UBLICAÇÃO DE D ISSERTAÇÃO
EM
F ORMATO E LETRÔNICO
Na qualidade de titular dos direitos de autor, AUTORIZO o Instituto de Informática da Universidade Federal de Goiás – UFG a reproduzir, inclusive em outro formato
ou mídia e através de armazenamento permanente ou temporário, bem como a publicar na
rede mundial de computadores (Internet) e na biblioteca virtual da UFG, entendendo-se
os termos “reproduzir” e “publicar” conforme definições dos incisos VI e I, respectivamente, do artigo 5o da Lei no 9610/98 de 10/02/1998, a obra abaixo especificada, sem que
me seja devido pagamento a título de direitos autorais, desde que a reprodução e/ou publicação tenham a finalidade exclusiva de uso por quem a consulta, e a título de divulgação
da produção acadêmica gerada pela Universidade, a partir desta data.
Título: CSVM: Uma Plataforma para CrowdSensing Móvel Dirigida por Modelos em
Tempo de Execução
Autor(a): Paulo César Ferreira Melo
Goiânia, 15 de Outubro de 2014.
Paulo César Ferreira Melo – Autor
Dr. Fábio Moreira Costa – Orientador
PAULO C ÉSAR F ERREIRA M ELO
CSVM: Uma Plataforma para
CrowdSensing Móvel Dirigida por
Modelos em Tempo de Execução
Dissertação apresentada ao Programa de Pós–Graduação do
Instituto de Informática da Universidade Federal de Goiás,
como requisito parcial para obtenção do título de Mestre em
Computação.
Área de concentração: Sistemas Distribuídos..
Orientador: Prof. Dr. Fábio Moreira Costa
Goiânia
2014
PAULO C ÉSAR F ERREIRA M ELO
CSVM: Uma Plataforma para
CrowdSensing Móvel Dirigida por
Modelos em Tempo de Execução
Dissertação defendida no Programa de Pós–Graduação do Instituto de
Informática da Universidade Federal de Goiás como requisito parcial
para obtenção do título de Mestre em Computação, aprovada em 15 de
Outubro de 2014, pela Banca Examinadora constituída pelos professores:
Prof. Dr. Fábio Moreira Costa
Instituto de Informática – UFG
Presidente da Banca
Prof. Dr. Carlos André Guimarães Ferraz
Centro de Informática – UFPE
Prof. Dr. Sérgio Teixeira de Carvalho
Instituto de Informática – UFG
Todos os direitos reservados. É proibida a reprodução total ou parcial do
trabalho sem autorização da universidade, do autor e do orientador(a).
Paulo César Ferreira Melo
Graduou–se em Ciência da Computação na UFG - Universidade Federal de
Goiás. Durante sua graduação, foi monitor no Instituto de Informática da
UFG e bolsista do CNPq em um trabalho de iniciação científica. Durante o
Mestrado, foi bolsista e colaborou no projeto M@TURE, desenvolvido em
parceria com INRIA Paris-Rocquencourt.
Dedico a todos que de forma direta ou indireta fizeram parte desta caminhada e
de diferentes maneiras, contribuiram no desenvolvimento deste trabalho.
Agradecimentos
Agradeço a Deus por me amparar nos momentos mais difíceis, me dando força
para encarar e superar as dificuldades, mostrar o caminho nas horas mais incertas e sempre
atender as minhas preces.
À minha família, a qual amo muito, pelo apoio, carinho e por serem o alicerce
que me manteve de pé durante esta importante etapa na minha vida.
À minha noiva e companheira Lanna Marla Andrade por sua paciência e compreensão durante minhas ausências, o seu amor sempre incondicional, os seus conselhos
me mantendo sempre lúcido em minhas decisões e por sempre acreditar em mim e se
esforçar para me manter motivado durante está longa jornada.
Aos amigos e colegas do grupo M@ture e do LABORA, que no pouco convívio
que tivemos, contribuiram com este trabalho.
À PRPPG da Universidade Federal de Goiás, pelo apoio financeiro durante a
elaboração deste trabalho.
Aos servidores do Instituto de Informática, em especial as servidoras Mirian e
Patrícia que em suas atribuições sempre se mostraram dispostas e prontas à esclarecer
minhas duvidas e me orientar nas questões relacionadas ao programa de pós-graduação.
Aos amigos que fizeram parte desse momento sempre me ajudando e incentivando.
Agradeço de forma especial ao meu orientador Fábio Moreira Costa pela atenção
e paciência durante estes últimos 5 anos e por ter sido um grande mestre e um exemplo
de profissional. Seus concelhos me guiaram pela vida acadêmica e sem o seu apoio e
motivação este trabalho certamente não seria possível.
Por fim, agradeço á todos pelo apoio.
“Que os vossos esforços desafiem as impossibilidades, lembrai-vos de
que as grandes coisas do homem foram conquistadas do que parecia impossível.”
Charles Chaplin,
referência desconhecida.
Resumo
Melo, Paulo César F.. CSVM: Uma Plataforma para CrowdSensing Móvel Dirigida por Modelos em Tempo de Execução. Goiânia, 2014. 140p. Dissertação
de Mestrado. Instituto de Informática, Universidade Federal de Goiás.
Recentes avanços na computação ubíqua tem colaborado para a ascensão de uma categoria emergente de dispositivos móveis que apresentam capacidades computacionais e
de sensoriamento, tais como smartphones e dispositivos vestíveis. A proliferação destes
dispositivos em uma rede de comunicação integram e contribuem para a evolução da Internet das Coisas. A presença desses dispositivos móveis aumenta a oportunidade para o
desenvolvimento de aplicações que utilizam da capacidade de sensoriamento desses dispositivos a fim de medir, inferir e entender os indicadores do ambiente. Uma vez que, os
dados sensoreados por essas aplicações são compartilhados entre diferentes dispositivos
móveis, surge o paradigma denominado CrowdSensing móvel. A complexidade de aplicações pertencentes ao domínio de CrowdSensing móvel está associada a fatores como
interoperabilidade entre diferentes dispositivos móveis, identificação e captação de dados provenientes desses dispositivos e adaptação de seu uso em ambientes heterogêneos
e dinâmicos. Com base nesse problema associado ao paradigma de CrowdSensing móvel, abordagens de engenharia de software dirigida por modelos (MDE) e de modelos em
tempo de execução constituem uma forma de lidar com aplicações complexas por meio
do uso de modelos. Neste trabalho propomos a utilização de uma abordagem dirigida por
modelos em tempo de execução para criação e processamento de consultas de crowdsensing móvel. Mostramos como essa abordagem pode ser empregada por meio da definição
de uma linguagem de modelagem específica para o domínio de crowdsensing móvel, denominada CSML. Neste sentido, construímos e validamos o metamodelo da CSML que
captura os principais aspectos do domínio e seu ambiente de execução, que envolve uma
máquina de execução de modelos descritos em CSML, denominada CSVM . Essa abordagem dirigida por modelos facilita a especificação de consultas de crowdsensing móvel,
além de possibilitar sua alteração durante seu processamento.
Palavras–chave
Crowdsensing Móvel, Internet das Coisas, Modelos em Tempo de Execução
Abstract
Melo, Paulo César F.. CSVM: A Model Driven Platform for Mobile CrowdSensing. Goiânia, 2014. 140p. MSc. Dissertation. Instituto de Informática, Universidade Federal de Goiás.
Recent advances in ubiquitous computing has contributed to the rise of an emerging
category of mobile devices that have computational capabilities and sensing, such as
smartphones and wearable devices. The proliferation of these devices in a communications network contribute to the evolution of the Internet of Things. The presence of these
mobile devices increases the chance for the development of applications using the sensing
ability of these devices to measure, and understand the environmental indicators. Once the
data sensoreados by these applications are shared between different mobile devices, arise
the paradigm called mobile CrowdSensing. The complexity of applications belonging
to the mobile CrowdSensing domain is associated with factors such as interoperability
between different mobile devices, data identification and capture from these devices and
adapting their use in heterogeneous and dynamic environments. Based on this problem
associated with the paradigm of mobile CrowdSensing, software engineering approaches
directed by models (MDE) and runtime models are a way of dealing with complex applications by using models. We propose the use of an approach run by runtime models for
creating and processing mobile crowdsensing queries. We show how this approach can be
used by defining a specific modeling language for mobile crowdsensing domain, called
CSML. In this sense, we constructed and validated the metamodel CSML that captures
the main aspects of the domain and its execution environment, which involves a execution engine models described in CSML called CSVM. This approach driven by models
facilitates the specification of mobile crowdsensing queries, and enable it changes during
processing.
Keywords
Mobile Crowdsensing, Internet of Things, Models at RunTime
Sumário
Lista de Figuras
12
Lista de Tabelas
14
1
15
17
17
18
20
20
Introdução
1.1
1.2
Objetivos
Motivação
1.2.1
1.3
1.4
2
Cenário
Contribuições
Organização da dissertação
Referencial Teórico
2.1
CrowdSensing
2.1.1
Internet das Coisas
2.1.2
Computação Móvel e Sensoriamento Móvel
2.1.3
Sensoriamento Participativo
2.1.4
CrowdSensing Móvel
Aplicações de Crowdsensing Móvel
Características de Crowdsensing Móvel
2.1.5
2.2
Considerações Gerais
Abordagem Dirigida por Modelos em Tempo de Execução
2.2.1
Engenharia Dirigida por Modelos
Modelos e Metamodelos
Linguagens de Modelagem Específicas de Domínio
2.2.2
2.2.3
Modelos em Tempo de Execução
Máquina de Execução de Modelos
User Interface - UI
Synthesis Engine - SE
Middleware - M
Service Broker - SB
2.2.4
2.3
3
Considerações Gerais
Conclusão
A Linguagem CSML
3.1
3.2
Terminologia
CSML
3.2.1
3.2.2
Metamodelo: Visão Geral
Metamodelo: Detalhamento
Esquema de Controle do Ambiente
22
22
23
25
25
26
26
27
27
28
28
29
31
32
33
35
36
36
37
37
37
38
39
40
42
44
45
Esquema de Controle da Consulta
Esquema de Dados
3.2.3
3.3
3.4
4
Exemplo de Uso
Modelo Geral de Execução
Considerações Finais
Arquitetura da CSVM
4.1
4.2
4.3
4.4
Visão Geral da Arquitetura
Arquitetura da CSVMProvider
4.2.1
Camada de Síntese
4.2.2
Camada de Middleware
4.2.3
Camada de Broker
Arquitetura da CSVM4Dev
4.3.1
Camada de Aplicação
4.3.2
Camada de Síntese
4.3.3
Camada de Middleware
4.3.4
Camada de Broker
Processo de Registro de Dispositivos
Registro na plataforma
4.5
4.6
5
4.5.1
Subscrição
4.5.2
Notificação
Considerações Finais
Implementação da CSVM
5.1
5.2
5.3
5.4
5.5
5.6
5.7
6
Processo de Consulta
Visão Geral
Tecnologias Utilizadas
5.2.1
Model-View-Controller
5.2.2
RESTFul
5.2.3
GCM
CSVMProvider
CSVM4Dev
Registro de dispositivos
5.5.1
Registro do dispositivo na CSVM4Dev
5.5.2
Registro de dispositivos na CSVMProvider
Processamento de consultas
5.6.1
Especificação de consultas na CSVM4Dev
5.6.2
Processamento de consultas na CSVMProvider
5.6.3
Processamento de consultas na CSVM4Dev
Considerações Finais
Estudo de Caso e Avaliação
6.1
Estudo de Caso
6.1.1
6.1.2
Descrição Geral
Modelagem do Cenário
1a etapa: Especificação e Modelagem
2a etapa: Processamento
3a etapa: Resposta
48
49
51
53
54
56
57
60
60
62
63
65
66
68
69
70
72
73
74
75
76
78
79
79
80
81
82
83
84
86
87
88
89
91
91
92
95
96
97
97
97
98
99
100
104
6.1.3
6.2
Considerações Gerais
Avaliação de Desempenho
6.2.1
6.2.2
Metodologia
Processamento do esquema de controle da consulta com variação da quantidade de dispositivos
6.2.3
7
7.2
7.3
8
Considerações Gerais
Trabalhos Relacionados
7.1
CrowdSensing Móvel
7.1.1
Medusa
7.1.2
Vita
7.1.3
MobIoT
Modelos em Tempo de Execução
7.2.1
CVM
7.2.2
MGridVM
Conclusão
Conclusão
8.1
110
Processamento e agregação do esquema de dados com variação na quantidade de tipos de sensores
6.3
108
Processamento e agregação do esquema de dados com variação na quantidade de dispositivos
6.2.5
107
Processamento do esquema de controle da consulta com variação na quantidade de tipos de sensores
6.2.4
105
105
105
Trabalhos futuros
111
112
113
113
114
116
118
120
120
121
123
124
125
Referências Bibliográficas
127
A
Esquemas do Cenário
133
B
Modelos do Estudo de Caso
136
Lista de Figuras
2.1
2.2
2.3
2.4
2.5
3.1
3.2
3.3
3.4
3.5
3.6
Iniciativas englobadas pela Internet das Coisas e relacionadas à CrowdSensing Móvel.
Internet das Coisas como resultado da convergência de diferentes visões
[5].
Iniciativas englobadas pela MDE
Arquitetura de metamodelagem - MOF [43].
Arquitetura em camadas de uma máquina de execução genérica
Representação Geral da G-CSML
Definição e uso da CSML usando a arquitetura de metamolagem da OMG.
Visão Geral do Metamodelo da CSML
Metamodelo que descreve o Esquema de Controle do Ambiente.
Pacote de enumerações mantidas pelo Esquema de Controle do Ambiente.
(a) e (b) representam respectivamente os tipos de sensores e operações
mantidos pelo metamodelo do ECS.
(b)
Tipos de operação.
Diagrama do metamodelo que descreve o Esquema de Controle da Consulta.
3.8 Diagrama do Metamodelo que descreve o Esquema de Dados.
3.9 Representação em X-CSML do esquema de controle para registro do
dispositivo.
3.10 Representação em X-CSML do esquema de controle da consulta (a) e
sua instância (b).
3.11 Representação em X-CSML do esquema de dados (a) e sua instância (b).
23
24
29
30
35
41
43
45
46
47
47
47
3.7
(b)
(b)
Instância do esquema de controle da consulta.
Instância do esquema dados.
3.12 Modelo de execução da CSVM.
4.1
4.2
4.3
Visão Geral da Plataforma CSVM
Arquitetura Geral da Plataforma CSVM
Arquitetura geral em camadas da CSVM, representado sua configuração
da CSVMProvider (a) e da CSVM4Dev (b).
(b)
4.4
4.5
4.6
4.7
4.8
4.9
Arquitetura em camadas da CSVM4Dev.
Modelo da Camada de Síntese da CSVMProvider.
Modelo da Camada de Middleware da CSVMProvider.
Modelo da Camada de Broker da CSVMProvider.
Camada de Aplicação da CSVM4Dev.
Modelo da Camada de Aplicação da CSVM4Dev.
Modelo da Camada de Síntese da CSVM4Dev.
48
50
52
52
53
53
53
54
57
58
59
59
61
62
64
66
67
69
4.10
4.11
4.12
4.13
Modelo da Camada de Middleware da CSVM4Dev.
Modelo da Camada de Broker CSVM4Dev.
Arquitetura de um registro.
Arquitetura de uma consulta.
5.1
Mapeamento da arquitetura em camadas da plataforma de acordo com o
padrão MVC.
Diagrama de classes da CSVMProvider.
Diagrama de classe da CSVM4Dev.
(a) e (b) representam layouts utilizados para configurar o registro do
dispositivo.
5.2
5.3
5.4
(a)
(b)
Tela de Registro do Dispositivo.
Tela de Seleção de Sensores.
5.5
5.6
5.7
5.8
Diagrama de sequência do registro do dispositivo na CSVM4Dev.
Diagrama de sequência do registro do dispositivo na CSVMProvider.
Diagrama de sequência da especificação de uma consutla na CSVM4Dev.
Diagrama de sequência do processamento de uma consulta na CSVMProvider.
5.9 Máquina de estados para seleção de recursos na CSVMProvider.
5.10 Máquina de estados para o processamento dos dados retornados pelos
dispositivos.
5.11 Diagrama de sequência do processamento de uma consutla na CSVM4Dev.
Diagrama de camadas da CSVM com as principais etapas na processamento de consultas.
6.2 Esquema de controle para registro do dispositivo descrito em X-CSML.
6.3 Esquema de controle da consulta descrito em X-CSML para o problema 3.
6.4 Instância do esquema de controle da consulta descrita em X-CSML para
o problema 3.
6.5 Esquema de dados descrito em X-CSML para o problema 3.
6.6 Instância do esquema de dados descrita em X-CSML para o problema 3.
6.7 Tempo de Processamento de Consultas com variação da Quantidades de
Dispositivos.
6.8 Tempo de Processamento de Consultas com 25, 50 e 100 Dispositivos.
6.9 Tempo de Processamento de Consultas com Variação da Quantidades de
Tipos de Sensores.
6.10 Tempo de Processamento e Agregação de Dados com Variação da Quantidade de Dispositivos.
6.11 Tempo de Processamento e Agregação de Dados com Variação a Quantidade de Tipos de Sensores.
70
71
72
74
81
85
87
88
88
88
89
90
92
93
94
95
96
6.1
7.1
7.2
7.3
Medusa - Arquitetura do Sistema [50].
Vita - Arquitetura [28].
Arquitetura do MobIoT [26].
99
100
101
102
102
104
108
109
110
111
112
115
116
119
Lista de Tabelas
6.1
6.2
Sensores utilizados por aplicações de crowdsensing conforme o problema
a ser modelado
Representação de campo e valor de uma consulta especificada a partir
do problema 3.
100
101
CAPÍTULO 1
Introdução
Em uma de suas definições, a Internet pode ser descrita como sendo um conglomerado de redes de comunicação, à qual vários computadores e dispositivos estão
conectados em escala mundial, usufruindo de serviços e recursos dela provenientes. A
Internet e a comunicação sem fio evoluíram de uma infraestrutura onipresente onde se conectava apenas computadores para um modelo onde é possível conectar também objetos e
aparelhos do dia-a-dia (coisas). Este avanço contribuiu para o surgimento de um novo paradigma, denominado Internet das Coisas, o qual vem ganhando cada vez mais espaço. A
ideia principal deste conceito é a presença pervasiva de uma variedade de coisas ou objetos – tais como sensores, atuadores, telefones móveis, etiquetas RFID (Radio-Frequency
IDentification) e outros – os quais possuem uma representação única na Internet e são
capazes de interagir entre si para alcançar objetivos comuns [13]. A unificação de todas
as coisas conectadas sobre uma infraestrutura comum enseja novas formas de interação,
dentre as quais pode-se destacar tanto a possibilidade de controlar remotamente as coisas
ao nosso redor, quanto de obter informações sobre seu estado.
A Internet das Coisas terá um alto impacto em vários aspectos do dia-a-dia
e comportamento de seus usuários. Partindo desta abordagem e considerando os atuais smartphones como um dos itens de competência da Internet das Coisas, podemos
classificá-los como um tipo complexo de coisa, pois apresenta um alto poder computacional e uma variedade de funções. Essas características inerentes a estes dispositivos são
provenientes do progresso em pesquisa e desenvolvimento na área de computação móvel.
Esse progresso possibilitou a execução de funções computacionais avançadas, de modo
que aplicações direcionadas a dispositivos móveis tornaram-se abundantes, complexas e
presentes nos mais diversos domínios como: entretenimento, saúde e negócios.
Atualmente, os smartphones são equipados com uma quantidade cada vez maior
de sensores embarcados, tais como acelerômetro, giroscópio, GPS, luminosidade, microfone, proximidade, câmera e outros, os quais possibilitam o sensoriamento de dados do
ambiente para que possam ser interpretados e processados por diversas aplicações. Este
cenário cria e aumenta a oportunidade para o desenvolvimento de aplicações que fazem
uso da capacidade de sensoriamento dos dispositivos móveis, transformando os dados
16
coletados em informação útil e de fácil acesso para o usuário.
Essas aplicações podem ser classificadas em duas categorias baseadas no tipo
de fenômeno a ser monitorado, caracterizando-as ou como pessoais, onde o fenômeno
monitorado diz respeito a um único indivíduo (por exemplo, o padrão de movimento
relacionado a um exercício do indivíduo), ou como coletivas, quando o fenômeno é
monitorado em larga escala, fazendo-se necessária a análise de dados provenientes de
vários indivíduos (por exemplo, para monitoramento do congestionamento no tráfego de
veículos). Deste último, surge o conceito de crowdsensing móvel, que a partir dos dados
coletados, visa medir e mapear fenômenos de interesse comum [23].
Dentre os problemas inerentes a este tipo de cenário destaca-se a dificuldade no
desenvolvimento de aplicações de crowdsensing móvel, devido a fatores como interoperabilidade entre diferentes dispositivos móveis, identificação e captação de dados provenientes desses dispositivos e adaptação de seu uso em ambientes heterogêneos e dinâmicos.
Assim sendo, a utilização de métodos tradicionais para transpor esses problemas, requer
um grande esforço. Buscando solucioná-los, este trabalho propõe uma abordagem dirigida
por modelos baseada nos princípios estabelecidos pela Engenharia Dirigida por Modelos
(Model-Driven Engineering, MDE), a qual descreve o comportamento da aplicação por
meio de uma linguagem de modelagem específica para o domínio de crowdsensing móvel.
Optamos por utilizar tal abordagem com o objetivo de reduzir de forma substancial a distância semântica entre o problema a ser resolvido e a plataforma utilizada,
promovendo o uso de abstrações mais próximas do domínio do problema. Dentre as iniciativas englobadas pela Engenharia Dirigida por Modelos, destaca-se a de Modelos em
Tempo de Execução ([email protected] ou m@rt), a qual será aplicada neste trabalho,
uma vez que possibilita a representação causalmente conectada do ambiente e das consultas de crowdsensing móvel que estão sendo processadas. Desta forma, o uso de m@rt
permite a adaptação a ambientes dinâmicos de crowdsensing, caracterizados pela entrada
e saída de dispositivos do espaço monitorado e/ou modificação da consulta, mantendo
uma representação atualizada do ambiente e das consultas em execução. De acordo com
essa abordagem, os modelos são o meio pelo qual usuários e/ou aplicações de terceiros
especifiquem e modifiquem consultas durante o seu processamento.
Com o intuito de demonstrar a viabilidade desta abordagem, construímos uma
plataforma dirigida por modelos em tempo de execução denominada CSVM, que permite
criar e executar aplicações de crowdsensing móvel por meio da interpretação de modelos
descritos em uma linguagem de modelagem específica para o domínio de crowdsensing,
denominada CSML.
Baseado na abordagem proposta, e com o intuito de demonstrar as capacidades
da plataforma, apresentamos um cenário de uma casa noturna que compreende um
conjunto de aplicações de crowdsensing móvel. Isso nos permitiu avaliar a abrangência
1.1 Objetivos
17
da CSML e o comportamento da CSVM. Foi realizado uma avaliação do desempenho
da plataforma, por meio da análise de quatro experimentos que refletem etapas críticas
do processamento de modelos realizado pela CSVM. Os resultados obtidos nos permitiu
avaliar além do desempenho também a escalabilidade da CSVM diante do aumento do
número de dispositivos e sensores envolvidos no processamento de uma consulta.
1.1
Objetivos
O objetivo geral deste trabalho é propor o uso de uma abordagem dirigida
por modelos para crowdsensing móvel por meio da construção de uma máquina de
execução de modelos capaz de prover serviços sensoriamento remoto participativo a
partir de um conjunto heterogêneo de recursos (dispositivos e sensores). A máquina
construída a partir desta abordagem foram projetadas para processarem modelos descritos
em uma linguagem de modelagem interpretada e específica de domínio, e que podem ser
modificados em tempo de execução. A modificação de modelos em tempo de execução
tem como finalidade manter uma auto-representação causalmente conectada do ambiente
e das consultas de crowdsensing especificadas.
Dentre os objetivos específicos, destacam-se:
• Descrever aplicações de crowdsensing móvel, por meio da abordagem descrita por
Modelos em Tempo de Execução;
• Projetar um metamodelo, que sustente a criação de modelos de crowdsensing,
retratados neste trabalho por esquemas de controle e de dados para, modelar e
interpretar aplicações de crowdsensing móvel construídas para diferentes cenários;
• Propor uma arquitetura para ambientes de crowdsensing que compreende uma máquina de execução de modelos projetada para execução de aplicações de crowdsensing e para fornecer serviços descritos por modelos de alto nível.
• Facilitar o desenvolvimento de aplicações de crowdsensing móvel;
• Implementar um protótipo da CSVM que permite a criação de cenários qualquer
dentro do domínio de aplicação de crowdsensing móvel;
• Realizar um avaliação de desempenho da plataforma por meio de quarto diferentes
experimentos que representam momentos críticos do processamento de modelos de
crowdsensing.
1.2
Motivação
As aplicações em dispositivos móveis são utilizadas constantemente para auxiliar as pessoas na realização de diversas atividades. Esses dispositivos apresentam re-
1.2 Motivação
18
cursos, como a presença de sensores embarcados, que estimulam o desenvolvimento de
aplicações complexas que fazem uso desses recursos de forma colaborativa visando, por
exemplo, ao bem-estar e segurança de seus usuários. Neste contexto aplica-se o conceito
de crowdsensing móvel, segundo o qual os dados gerados pelo sensoriamento feito por
um conjunto de dispositivos móveis distribuídos são transformados em informações utilizadas por diferentes aplicações.
A essência de crowdsensing móvel, bem como os principais desafios, está
na diversidade e quantidade de dispositivos associados, nas condições dinâmicas dos
cenários e no processo de identificação de dispositivos para atenderem a uma determinada
requisição [23].
Para demonstrar a abrangência das aplicações de crowdsensing e os principais
desafios enunciados, apresentamos um cenário que compreende as diferentes formas
como essas aplicações podem ser construídas e modificadas para atender a diferentes
necessidades dos usuários.
O cenário corresponde à utilização de aplicações de crowdsensing móvel para
realizar medições em uma casa noturna, visando manter e melhorar a qualidade do
ambiente, detectar riscos e auxiliar na correção de falhas.
Uma infraestrutura física de redes de sensores sem fio claramente atenderia o
propósito apresentado, porém com algumas restrições: o custo da instalação e manutenção
da estrutura; a dificuldade de ampliação da infraestrutura quando necessário; e a precisão
dos dados coletados, pois, apesar de serem instalados em pontos estratégicos e cobrirem
uma vasta área, as leituras dos sensores podem não corresponder com exatidão às informações do contexto real, podendo haver distorção entre esses dados. Uma aplicação de
crowdsensing móvel pode substituir essa infraestrutura e transpor as limitações apresentadas através do uso colaborativo de sensores embarcados em dispositivos móveis presentes
no ambiente. Desta forma, não há custo de instalação de uma estrutura de sensores físicos, a infraestrutura poderá ser ampliada por meio da alteração da consulta inicial quando
necessário, especificando uma quantidade maior de dispositivos a serem monitorados e
por fim, a precisão dos dados é maior pois a leitura é realizada por meio do dispositivo do
usuário o que representa com exatidão a informação no contexto real.
Por meio deste cenário, pretendemos demonstrar a flexibilidade da abordagem
proposta aplicada em diferentes contextos de crowdsensing, desde aplicações simples até
aplicações mais complexas. A subseção 1.2.1 descreve o cenário enunciado acima.
1.2.1
Cenário
Uma casa noturna, para obter o alvará de funcionamento deve seguir algumas
normas de segurança definidas pela ABNT. Essas normas regem condutas de prevenção e
1.2 Motivação
19
reação frente a possíveis acidentes e determinam um conjunto de problemas que podem
ser modelados por aplicações de crowdsensing.
Outra característica deste cenário, é a preocupação com o bem-estar de seus
usuários, exigindo controle do alto fluxo de pessoas e dos serviços fornecidos. Em suma,
para o conforto e segurança dos usuários algumas regras devem ser satisfeitas:
1. Possuir um sistema de detecção de incêndio - caso detectado aumento na temperatura e queda na umidade de forma drástica, um alerta deve ser disparado.
2. Manter o nível de ruído do ambiente em padrões aceitáveis; caso os níveis sonoros
estejam superiores àqueles considerados normais pela ABNT, o volume deve ser
diminuído;
3. Manter a temperatura do ambiente controlada em 22◦ C; caso a temperatura esteja
superior a 22◦ , deve ser mantido o sistema de refrigeração; caso a temperatura esteja
inferior a 22◦ , o sistema deve ser desligado;
4. Controlar a luminosidade do ambiente; caso a incidência de luz esteja abaixo do
determinado, algumas lâmpadas devem ser acesas; caso a incidência de luz esteja
acima do determinado, algumas lâmpadas devem ser apagadas;
5. Controlar a quantidade de pessoas no interior do ambiente; caso a quantidade
máxima de pessoas tenha sido atingida, deve ser interrompida a entrada de novas
pessoas.
O ambiente deve possuir sistemas automatizados que processam dados obtidos
pelo sensoriamento realizado pelos dispositivos móveis presentes no ambiente. Além dos
sistemas automatizados, os dados monitorados por aplicações de crowdsensing podem ser
utilizados por usuários com finalidades dependendo do tipo de usuário:
• Proprietário: a fim de auxiliar na gestão da casa noturna, como por exemplo para
obter o dia em que o ambiente é mais frequentado, e consequentemente poder lançar
promoções.
• Funcionário: a fim de prevenir doenças ocupacionais causadas, por exemplo, pela
exposição constante a altos níveis sonoros.
• Cliente: a fim de auxiliar na tomada de decisão, através de informações obtidas
referentes à agitação do ambiente (movimentação das pessoas presentes).
A importância das aplicações de crowdsensing neste cenário (ou em cenários semelhantes) pode ser evidenciada pela tragédia ocorrida em 27 de janeiro de 2013 em uma
boate localizada na cidade de Santa Maria no Rio Grande do Sul, onde laudos realizados
pelo Instituto Geral de Perícias (IGP) apontam que durante o incêndio, a temperatura no
interior da boate ultrapassou 100◦ C. Neste exemplo, mesmo não possuindo uma infraestrutura de sensores sem fio, a temperatura poderia ser medida através dos dispositivos
1.3 Contribuições
20
móveis das pessoas no interior da boate e as informações obtidas através dessa medição seriam enviadas a uma aplicação de gerenciamento da temperatura do ambiente que
acionaria um alarme antes de atingir proporções maiores ou poderia soar um alarme na
brigada de incêndio.
1.3
Contribuições
Este trabalho apresenta como contribuição, a aplicação de uma abordagem
dirigida por modelos para criação e processamento de consultas de crowdsensing móvel.
Associado a essa abordagem tem-se a definição de uma linguagem de modelagem
interpretada e específica para o domínio de crowdsensing móvel, denominada CSML
(CrowdSensing Modeling Language) que permite modelar o ambiente e as consultas
desse domínio. Nesse sentindo, foi construído e validado o metamodelo da CSML e seu
ambiente de execução.
Uma contribuição relacionada à CSML e seu ambiente de execução, é a demonstração de sua expressividade e aplicabilidade para construção e processamento de aplicações de crowdsensing móvel pertencentes a domínios altamente dinâmicos. Em nosso
trabalho, demonstramos como essa característica de dinamicidade é capturada e tratada
por meio do uso de modelos em tempo de execução, uma vez que, a abordagem proposta
permite que as consultas sejam modificadas durante sua execução, seja por intervenção
do usuário, ou por alteração no ambiente monitorado.
Outra contribuição deste trabalho está relacionada a construção do ambiente de
execução, o qual define a forma de associar o usuário com a plataforma para criação
e execução de modelos em tempo de execução descritos em CSML. O ambiente de
execução envolve uma máquina de execução de modelos específica para o domínio
de crowdsensing móvel denominada CSVM capaz de processar modelos em tempo de
execução descritos em CSML. Além de sua importância no emprego de técnicas de
processamento de modelos, a CSVM demonstra a flexibilidade na criação de consultas
a partir de modelos de alto nível que podem ser modificados em tempo de execução.
1.4
Organização da dissertação
O Capítulo 2 introduz o estado da arte associado à abordagem proposta, envolvendo o problema-alvo e a técnica empregada. O Capítulo 3 detalha o metamodelo para
construção da linguagem de modelagem específica de domínio (DSML) proposta, e descreve a execução de aplicações de crowdsensing utilizando uma abordagem dirigida por
modelos em tempo de execução apresentada na forma de uma arquitetura genérica para
construção do ambiente de execução. O Capítulo 4 descreve a arquitetura da plataforma
1.4 Organização da dissertação
21
proposta (CSVM), detalhando seus elementos, seguido do Capítulo 5 que apresenta detalhes da implementação da plataforma e o protótipo de uma aplicação de crowdsensing.
O Capítulo 6 demonstra como a abordagem proposta pode ser aplicada ao cenário descrito neste capítulo, apresentando um estudo de caso e analisando os resultados obtidos.
O Capítulo 7 discute outros trabalhos existentes que estão relacionados à execução de
aplicações de crowdsensing. Por fim, o Capítulo 8 apresenta as conclusões do trabalho,
discutindo suas contribuições, limitações e possíveis trabalhos futuros.
CAPÍTULO 2
Referencial Teórico
Este capítulo apresenta os conceitos sobre os quais o presente trabalho foi
desenvolvido. Desta forma, este capítulo foi dividido em duas seções que retratam as
principais áreas investigadas: referente à área fim, a Seção 2.1 apresenta os principais
conceitos do problema-alvo deste trabalho ou o domínio de aplicação que é CrowdSensing
móvel partindo de conceitos mais abrangentes até as principais características e aplicações
do domínio; e referente à área meio, a Seção 2.2 apresenta a técnica de modelos em
tempo de execução empregada neste trabalho para construção e execução das aplicações
de CrowdSensing móvel.
2.1
CrowdSensing
Nesta seção apresentamos os conceitos referentes ao problema alvo deste trabalho, partindo dos conceitos mais abrangentes que o englobam. Desta forma, a Figura
2.1 apresenta as iniciativas associadas à Internet das Coisas e relacionadas ao domínio
explorado neste trabalho, crowdsensing móvel. Assim, o domínio de crowdsensing móvel
pode ser dividido em sensoriamento participativo, ou seja, compartilhamento de sensores que requer o envolvimento ativo do indivíduo, e sensoriamento oportunista, ou seja,
compartilhamento de sensores de forma mais autônoma, onde o envolvimento do usuário é mínimo. Parte dos dispositivos associados a crowdsensing móvel são representados
por smartphones (presentes no contexto de Mobile Phone Sensing), embora este domínio
possa ser estendido a outros dispositivos/objetos móveis, tais como, dispositivos vestíveis
e veículos equipados com sensores. Todos essas iniciativas estão inseridas no contexto de
sensoriamento móvel, que compreende parte da Internet das Coisas.
Seguindo os conceitos apresentados, na Seção 2.1.1 apresentamos a definição e
as principais características da Internet das Coisas. A Seção 2.1.2 descreve o conceito
de sensoriamento móvel com base nos princípios da computação móvel. A Seção 2.1.3
aborda a definição de sensoriamento participativo e os seus principais desafios. Por fim,
a Seção 2.1.4 discute o conceito de CrowdSensing móvel, descrevendo suas principais
características e aplicações.
2.1 CrowdSensing
23
Figura 2.1: Iniciativas englobadas pela Internet das Coisas e relacionadas à CrowdSensing Móvel.
2.1.1
Internet das Coisas
A Internet das Coisas pode ser definida como sendo a presença pervasiva de uma
variedade de coisas ou objetos em torno de nós – tais como etiquetas RFID, sensores,
atuadores, smartphones, etc – os quais possuem representação única na Internet e são
capazes de interagir entre si para alcançar objetivos comuns. Essas “coisas” podem ainda
ser definidas como objetos que possuem identidades e personalidades virtuais que operam
em espaços inteligentes, utilizando interfaces inteligentes para se conectar e comunicar no
contexto social, ambiental e do usuário [5].
A partir dos conceitos apresentados, é possível vislumbrar algumas características de nível de sistema, e dentre as principais, estão a heterogeneidade dos dispositivos (coisas), escalabilidade, troca de dados por meio de redes sem fio, uso de soluções
para otimizar o uso de energia (bateria), capacidades de rastreamento e localização, autoorganização (capacidade de reagir de forma autônoma a alterações do ambiente), interoperabilidade semântica, gerenciamento de dados, segurança e privacidade [41].
A Figura 2.2 apresenta o paradigma de Internet das Coisas como resultado da
convergência de três diferentes visões. A primeira visão é derivada de uma perspectiva
orientada às "Coisas", compreendendo desde itens mais simples, como etiquetas RFID
(Radio-Frequency IDentification), até itens inteligentes, como smartphones. A tecnologia
Near Field Communication (NFC), juntamente com redes de sensores e atuadores sem fio
e RFID, são os principais responsáveis por conectar o mundo real com o mundo digital.
Visando melhorar aspectos de rastreabilidade e comunicação, muitos esforços vêm sendo
empreendidos a fim de criar protocolos e padrões globais de comunicação. Com este
objetivo, foi proposta uma arquitetura baseada em identificador único/universal/ubíquo
(uID), cuja ideia principal é o desenvolvimento de soluções para prover visibilidade única
e global dos objetos. Assim, a visão orientada às “coisas”, pressupõe que os objetos
(coisas) serão cada vez mais inteligentes, apresentando capacidades como comportamento
2.1 CrowdSensing
24
autônomo e proativo, sensibilidade ao contexto e comunicação colaborativa.
Figura 2.2: Internet das Coisas como resultado da convergência
de diferentes visões [5].
Passando para a visão orientada à Internet, temos como destaque uma iniciativa
para promover o Protocolo de Internet (IP) como a tecnologia de rede utilizada para a
conexão de objetos inteligentes ao redor do mundo, a qual foi inicialmente proposta pela
IPSO (IP for Smart Objects) Alliance [29]. É importante ressaltar que esta proposta só foi
possível devido à evolução do protocolo IP para a versão 6 (IPv6), permitindo representar
uma quantidade maior de endereços IP (o que será necessário para representar a ampla
gama de objetos conectados à Internet). Ainda nesta perspectiva, o termo web of things
(web de coisas) refere-se à reutilização dos padrões da Web para conectar e integrar os
objetos (coisas) na Web [24].
Por fim, têm-se a visão orientada a Semântica, que apresenta como principais
desafios interconectar e organizar a informação gerada pela Internet das Coisas [65].
Diante desses desafios, o uso de tecnologias semânticas oferece uma solução elegante.
Dentre os desafios relacionados à Internet das Coisas, o escopo deste trabalho envolve: a capacidade de interconectar diferentes dispositivos móveis de maneira uniforme,
o rastreamento e localização dos dispositivos, a capacidade de reagir de forma autônoma
a alterações no ambiente e o gerenciamento de dados gerados por esses dispositivos. A
Seção 2.1.2 apresenta os conceitos relacionados à computação móvel e sensoriamento
móvel que compreendem parte da Internet das Coisas.
2.1 CrowdSensing
2.1.2
25
Computação Móvel e Sensoriamento Móvel
A evolução dos dispositivos móveis tem feito com que eles apresentem cada vez
mais funcionalidades e recursos. Uma importante característica referentes a esses dispositivos, refere-se à sua mobilidade e sua capacidade de sensoriamento. Esta última, por
sua vez, dar-se-á devido aos smartphones atuais possuírem sensores embarcados, possibilitando a detecção e captação de dados do ambiente externo. Dentre os sensores mais
comuns a esses dispositivos, podemos encontrar: acelerômetro, giroscópio, GPS, luminosidade, bússola digital, captação de áudio (microfone), proximidade e detecção de imagem (câmera). Coletivamente, esses sensores estão proporcionando aos desenvolvedores
a possibilidade de investir em novas aplicações que fazem uso destas informações e geram
conteúdo significante para o usuário.
Este cenário contribuiu para o surgimento de novas aplicações pertencentes
a uma ampla variedade de domínios, tais como saúde, redes sociais, monitoramento
ambiental, segurança e transporte, originando uma área de pesquisa denominada Mobile
Phone Sensing [38].
A combinação destes avanços tem aberto portas para pesquisas inovadoras e
conduzido o desenvolvimento de aplicações de sensoriamento para um patamar que tem
revolucionado tanto setores de negócios quanto nossas vidas cotidianas.
Entretanto, um dos grandes impasses desta abordagem refere-se à arquitetura,
onde há pouco ou nenhum consenso, sobre quais componentes da arquitetura devem ser
executados nos smartphones e quais devem ser executados em servidores externos (por
exemplo, na nuvem). Alguns pesquisadores propõem, por exemplo, que os dados brutos
dos sensores não devem ser enviados para a nuvem, respeitando questões de privacidade
[38] [34].
Por outro lado, um dos principais benefícios do uso de computação em nuvem é a
capacidade de calcular e extrair grandes volumes de dados de vários de usuários, podendo
também compartilhar uma versão agregada desses dados com a população em geral, ao
mesmo tempo em que preserva a identidade dos usuários.
2.1.3
Sensoriamento Participativo
O avanço em pesquisas relacionadas ao sensoriamento móvel contribui para o
surgimento de um novo paradigma, denominado Sensoriamento Participativo. O sensoriamento participativo é o processo pelo qual indivíduos e comunidades usam cada vez
mais as capacidades de um conjunto de dispositivos móveis e serviços em nuvem para
coletar e analisar dados [19].
Em outra definição, o sensoriamento participativo compreende tarefas implantadas nos dispositivos móveis para formar redes de sensores participativas (RSPs) interati-
2.1 CrowdSensing
26
vas que permitem aos usuários públicos e profissionais coletarem, analisarem e compartilharem o conhecimento local [10]. Desta forma, um dos principais benefícios do sensoriamento participativo móvel é o aumento do conhecimento que será adquirido sobre o
mundo real, devido ao grande número de dispositivos móveis.
Várias aplicações podem ser desenvolvidas segundo este paradigma e em diferentes áreas, como: planejamento urbano, gestão de recursos naturais e saúde pública.
Um dos desafios enfrentados por esta abordagem é que dado o número crescente
de dispositivos móveis capazes integrar este cenário, as abordagens de detecção participativa devem ser escaláveis [25].
2.1.4
CrowdSensing Móvel
Com a evolução da computação móvel, crowdsensing móvel surge como um
novo termo referindo-se ao compartilhamento de informações coletadas a partir de diferentes dispositivos móveis, a fim de medir e mapear fenômenos de interesse comum. Para
realizar esta coleta, há duas possíveis maneiras: de forma participativa, onde os usuários
exercem uma ação por meio do smartphone e disponibilizam os dados sensoriados; e de
forma oportunista, onde o usuário inicialmente libera o acesso da aplicação aos dados sensoriados e esta, por sua vez, quase de forma autônoma, envia os dados para um servidor
backend para processamento [23].
Aplicações de Crowdsensing Móvel
As aplicações de crowdsensing móvel (Mobile Crowdsensing, MCS) podem ser
classificadas em três categorias diferentes baseadas no tipo de fenômeno a ser monitorado,
que pode ser: ambiental, de infraestrutura e social [23].
Aplicações MCS ambientais monitoram fenômenos naturais, como por exemplo
os níveis de poluição em uma determinada cidade. Essas aplicações permitem realizar o
monitoramento de vários fenômenos ambientais de grande escala.
Aplicações de infraestrutura englobam fenômenos de grande escala relacionados
com a infraestrutura pública. Exemplos deste tipo de aplicação incluem a disponibilidade
de estacionamento, condições das estradas, medição de congestionamento de tráfego em
tempo real, entre outras.
Por último, tem-se as aplicações sociais, onde os usuários compartilham informações “monitoradas” entre si a fim de colaborarem para uma causa comum. Partindo
desta definição, as pessoas podem, por exemplo, compartilhar seus hábitos alimentares e
comparar com os de outras pessoas. Uma aplicação desse tipo poderia ser utilizada por
uma comunidade de diabéticos por exemplo.
2.1 CrowdSensing
27
Características de Crowdsensing Móvel
Partindo do princípio de que milhões de pessoas possuem pelo menos um
dispositivo móvel (tais como os smartphones), as aplicações de crowdsensing surgem
como uma alternativa de baixo custo e tempo, reduzindo esforços para o desenvolvimento
de infraestruturas especializadas de sensores.
Ambientes de crowdsensing móvel são característicos por apresentarem alta
dinamicidade, de modo que os dispositivos móveis, o tipo de dado de cada sensor e a
qualidade (em termos de precisão, latência e confiança) podem mudar aleatoriamente.
Isto ocorre devido a fatores como a mobilidade dos dispositivos, autonomia de bateria,
canais de comunicação e preferências do proprietário. Com base neste pressuposto, a
literatura cita como um problema complexo a garantia da qualidade dos dados desejados
e a dificuldade na identificação do conjunto certo de dispositivos que podem fornecer tais
informações [23].
Uma outra característica importante, intrínseca a este cenário, é a possibilidade
de reutilização dos dados monitorados e captados pelos sensores. Assim sendo, para o
provimento de um serviço eficiente que suporte aplicações concorrentes, é fundamental
primeiramente identificar as necessidades de dados comuns e consequentemente suportar
o reuso dos dados. Por fim, para garantir a colaboração e participação massiva dos
usuários deve-se atentar às formas de incentivo, visando recrutar, engajar e reter os
participantes envolvidos. [62]
2.1.5
Considerações Gerais
Nesse capítulo apresentamos o conceito de crowdsensing móvel e suas principais
características. Os conceitos apresentados nesta seção são fundamentais para compreensão deste trabalho, uma vez que este trabalho se propõe a apresentar uma plataforma
dirigida por modelos a fim de diminuir a complexidade existente no desenvolvimento e
execução de aplicações de crowdsensing móvel. Com intuito de facilitar a compreensão
da técnica empregada, a Seção 2.2 apresenta os principais conceitos relacionados à abordagem dirigida por modelos, mais especificamente à engenharia dirigida por modelos,
explorando principalmente as características de modelos em tempo de execução e máquinas de execução de modelos.
2.2 Abordagem Dirigida por Modelos em Tempo de Execução
2.2
28
Abordagem Dirigida por Modelos em Tempo de Execução
Nesta seção discutiremos a abordagem dirigida por modelos em tempo de
execução a qual foi adotada neste trabalho. Com esta abordagem, os modelos são tratados
como artefatos tanto para o desenvolvimento quanto para a execução de aplicações,
deixando de representar apenas esboços de ideias e documentação [54]. A Seção 2.2.1
apresenta os princípios da engenharia dirigida por modelos. A Seção 2.2.2 e apresenta os
principais conceitos de modelos em tempo de execução. Por fim, a Seção 2.2.3 discute a
construção de máquinas de execução de modelos utilizadas para realizar a abordagem de
modelos em tempo de execução empregada neste trabalho.
2.2.1
Engenharia Dirigida por Modelos
Model-Driven Engineering (MDE) refere-se a um conjunto de técnicas para
permitir o uso de modelos como os principais artefatos de desenvolvimento no processo
de engenharia de software [22]. Para este propósito, a utilização de modelos pode abranger
as diversas áreas da engenharia de software (desde o desenvolvimento até a manutenção),
não se restringindo à compreensão ou documentação de um sistema de software.
A necessidade de lidar com a complexidade evolutiva encontrada no desenvolvimento de sistemas de software é um dos fatores que contribuem para o emprego de
abordagem dirigidas por modelo. O progresso vivido em diversas áreas da Computação,
mais incisivamente em termos de capacidade de processamento e ubiquidade, contribuiu
para a construção de aplicações cada vez mais complexas, as quais utilizam técnicas e tecnologias capazes de sustentá-las em ambientes heterogêneos e dinâmicos (em constante
mudança).
Assim sendo, a utilização de métodos tradicionais de desenvolvimento para
concepção dessas aplicações requer um grande esforço. Um dos principais fatores que
dificultam o desenvolvimento dessas aplicações é a distância semântica entre o problema
a ser resolvido e a plataforma utilizada na sua implantação. Diante desta dificuldade,
abordagens de MDE propõem, por meio da utilização de abstrações mais próximas do
domínio do problema, reduzir essa distância.
O termo Engenharia Dirigida por Modelos engloba recentemente várias iniciativas, como Model-Driven Development (MDD), Model-Driven Architecture (MDA) e
Modelos em Tempo de Execução (Figura 2.3).
A primeira iniciativa a propor um conjunto de padrões e princípios para o uso sistematizado de modelos foi a MDA, que foi concebida com o objetivo de permitir a descri-
2.2 Abordagem Dirigida por Modelos em Tempo de Execução
29
Figura 2.3: Iniciativas englobadas pela MDE.1
ção funcionalidades de um sistema independentemente de plataforma de implementação,
promovendo a interoperabilidade e portabilidade do sistema [57].
Como objetivos das abordagens de MDD, têm-se a construção de linguagens de
modelagem e transformações capazes de gerar artefatos da plataforma de implementação
mediante a transformação dos modelos descritos por meio dessas linguagens [55]. Outros
objetivos da MDE compreendem: aumentar a velocidade de desenvolvimento, melhorar a
qualidade do software, tornar os componentes de software reusáveis, gerir a complexidade
através da abstração, propiciar um ambiente produtivo e sustentar a interoperabilidade e
portabilidade.
Modelos e Metamodelos
Partindo dos princípios da MDE, o uso de modelos é proposto não apenas como
representação visual, mas como definição formal dos elementos de um software em construção [54]. Desta forma, um modelo é uma abstração ou representação reduzida de um
sistema, que abstrai a complexidade de seus elementos. Um modelo pode ser representado de forma gráfica ou textual e é formalizado por uma linguagem de modelagem cujas
construções são definidas por um metamodelo.
A linguagem de modelagem é definida por sua sintaxe e semântica, da mesma
forma que outras linguagens formais. De modo geral, a sintaxe de uma linguagem de
modelagem pode ser dividia em duas partes: sintaxe concreta que representa sua notação
textual ou gráfica, e sintaxe abstrata, que representa os conceitos da linguagem e os
relacionamentos entre eles. A semântica também pode ser dividida em duas partes: a
1 Figura
extraída do material da disciplina Tópicos em Engenharia Dirigida por Modelos, ministrada
pelo professor Fábio Moreira Costa no ano 2011.
2.2 Abordagem Dirigida por Modelos em Tempo de Execução
30
semântica estática, que define critérios de validação dos modelos, e a semântica dinâmica,
que define o significado dos modelos em sua execução.
Existem diferentes abordagens para descrever a semântica dinâmica de linguagens de modelagem as quais podem ser agrupadas em categorias [9]: por tradução, onde a
semântica da linguagem é definida pela tradução de seus conceitos em conceitos de outra
linguagem que possui uma semântica precisa; operacional, que permite modelar o comportamento operacional dos elementos descritos pela linguagem. A semântica operacional
é incorporada ao interpretador ou mecanismo que processa e executa os modelos; por extensão, que permite a descrição da semântica como uma extensão de outra linguagem; e
denotacional, que é definida pelo mapeamento entre as construções da linguagem e o domínio semântico que envolve elementos matemáticos representando elementos primitivos
da semântica.
Um metamodelo define o que pode ser expresso em um modelo em termos
de construções para representação das entidades do domínio e seus relacionamentos. O
metamodelo expressa as características de um domínio e pode ser utilizado para instanciar
diferentes modelos para um mesmo domínio. Desta forma pode-se dizer que um modelo é
uma instância de um metamodelo. Neste trabalho, demonstramos essa característica pela
definição de um metamodelo para o domínio de crowdsensing móvel, o qual é utilizado
para construir um modelo para especificação de consultas de crowdsensing móvel.
Figura 2.4: Arquitetura de metamodelagem - MOF [43].
Com a popularização da abordagem dirigida por modelos, fez-se necessária a padronização da construção de modelos e metamodelos, sendo que uma das iniciativas mais
importantes nesse sentido foi conduzida pelo OMG (Object Management Group), por
meio de uma arquitetura de metamodelagem denominada MOF (Meta-Object Facility),
ilustrada na Figura 2.4 [43]. A arquitetura apresentada descreve a especificação da MOF
2.2 Abordagem Dirigida por Modelos em Tempo de Execução
31
em quatro camadas, onde cada elemento de uma camada inferior é uma instância de algum elemento da camada superior. A distribuição em camadas é especificada da seguinte
forma [54]:
• Camada M3: representa o meta-metamodelo utilizado para construção de metamodelos. Esta camada integra a especificação da MOF que, possui um modelo formalizado por meio de suas próprias abstrações (modelo MOF), o que elimina a
necessidade de um nível superior. A partir deste modelo, é possível construir metamodelos que descrevem a sintaxe abstrata e semântica estática de linguagens de
modelagem para diversos domínios. Essas linguagens integram o nível M2.
• Camada M2: possui metamodelos que descrevem a sintaxe abstrata e semântica
estática. A UML (Unified Modeling Language) é um exemplo de linguagem de
modelagem definida a partir do modelo MOF. Esses metamodelos são utilizados
para construir os modelos que integram o nível M1.
• Camada M1: composta por modelos que descrevem aplicações e sistemas usando
as definições presentes em M2. Esses modelos representam os objetos existentes no
nível M0. Desta forma, essa camada contém por exemplo, as classes de um sistema
orientado à objetos ou as definições de tabelas de um banco de dados relacional.
• Camada M0: integrada por objetos que representam entidades do mundo real.
Outra definição proveniente da especificação da MOF, é o padrão para representação de modelos no formato XMI (XML Metada Interchange), utilizado para o intercâmbio de modelos usando XML.
Linguagens de Modelagem Específicas de Domínio
Uma linguagem de modelagem específica de domínio (Domain Specific Modeling Language - DSML) é uma linguagem de modelagem, que por meio das definições
descritas no metamodelo, associada a uma sintaxe concreta e uma semântica operacional, permite a construção de modelos para um determinado domínio da aplicação. Assim
sendo, as DSMLs representam aspectos estruturais e comportamentais do domínio da
aplicação.
Grande parte do sucesso no emprego de abordagens dirigidas por modelos está
associada à utilização de DSMLs [21]. O uso dessa abordagem aplicada a um domínio
específico permite atingir um alto grau de automatização no processamento de modelos.
Uma DSML captura os conceitos, relacionamentos, restrições e semânticas do
domínio da aplicação e permite que os usuários programem de forma declarativa por
meio da construção de modelos [11]. As DSMLs possuem duas finalidades distintas:
automatizar a geração de código-fonte com base em um modelo específico de domínio
ou interpretar em tempo de execução modelos específicos de domínios para identificar
2.2 Abordagem Dirigida por Modelos em Tempo de Execução
32
as necessidades dos usuários. Neste trabalho, foi proposta uma i-DSML para o domínio
de crowdsensing. Uma i-DSML (Interpreted-DSMLs) segue a definição tradicional de
DSML proposta pela MDE, tendo como diferença o fato que ela requer uma máquina de
execução que interpreta modelos em tempo de execução.
2.2.2
Modelos em Tempo de Execução
Um problema inerente do gerenciamento de sistemas e principalmente de aplicações móveis é a constante variação dos ambientes nos quais eles estão imersos, fazendo-se
necessária uma adaptação do sistema ao ambiente. Modelos têm sido empregados como
meio para lidar com este tipo de complexidade que envolve o gerenciamento de sistemas em tempo de execução. Para esta finalidade, deve-se implantar modelos em tempo
de execução ([email protected] ou m@rt) que proveem representações apropriadas dos
elementos de um sistema em execução, proporcionando sua adaptação e evolução sem a
necessidade de interromper seu ciclo [8].
Modelos em tempo de execução retomam a ampla visão de MDE, onde considera
que os modelos não são apenas artefatos primários de desenvolvimento, mas também são
o principal meio pelo qual os desenvolvedores compreendem, interagem, configuram e
modificam o comportamento do software em tempo de execução [22].
Outra importante característica desses modelos é que eles estão diretamente
relacionados à reflexão computacional, visto que ambos buscam definir representações
que refletem o sistema em execução, possuindo ainda uma relação de causalidade entre o
modelo e o sistema.
Em uma abordagem mais visionária, pode-se imaginar modelos de tempo de
execução sendo utilizados para corrigir erros de projeto ou para implantar novas decisões
de projeto em um sistema em execução. Da perspectiva de evolução do software durante
sua execução, um modelo em tempo de execução pode ser visto como modelo de
desenvolvimento ao vivo, que permite a evolução dinâmica do mesmo.
Desde a concepção de modelos em tempo de execução, várias técnicas vêm
sendo investigadas e as principais dimensões incluem [8]:
• Estrutura versus Comportamento: Os modelos estruturais tendem a enfatizar a
forma como um software é construído atualmente. Já os modelos comportamentais
partem de uma ótica de como o sistema executa, podendo ser representados em
termos de fluxos de eventos.
• Procedural versus Declarativa: O modelo pode ser procedural, que reflete a
estrutura e o comportamento do sistema detalhando os procedimentos/passos a
serem executados, ou o modelo pode ser mais declarativo, por exemplo, em termos
de objetivos do sistema, descrevendo a tarefa a ser executada sem se preocupar
2.2 Abordagem Dirigida por Modelos em Tempo de Execução
33
com detalhes de como o modelo será executado pelo mecanismo de execução de
modelos.
• Funcional versus Não-funcional: A maioria dos modelos baseia-se nas funcionalidades do sistema, mas há também a necessidade de modelos que capturem e
representem características não funcionais (por exemplo, aspectos de segurança).
• Formal versus Informal: Os modelos formais possuem a vantagem de apoiar o
“raciocínio” automático sobre o estado e o comportamento do sistema, mas podem
não capturar ou expressar adequadamente os conceitos do domínio requerido de
uma forma simples e acessível, por exemplo, aos usuários finais. Modelos informais
são mais acessíveis aos usuários, porém são mais inconsistentes e incompletos que
os modelos formais.
2.2.3
Máquina de Execução de Modelos
Além de descreverem sistemas estaticamente, modelos também podem ser usados para descrever o comportamento de sistemas em tempo de execução. Segundo a MDE,
um sistema deve ser descrito por modelos de forma independente de uma plataforma específica (Platform Independent Model - PIM) e, por meio de linguagens de transformação
de modelos implementadas por mecanismos específicos, o modelo do sistema deve ser
transformado em um modelo específico para uma determinada plataforma (Platform Specific Model - PSM) [57]. Desta forma, o foco do processo de desenvolvimento passa a ser
centrado em modelos e não mais em código.
A transformação de um modelo independente de plataforma em um modelo
específico de plataforma é realizada por meio de máquinas de execução de modelos [35].
Essa transformação compreende o processamento de modelos (PIM) pelas máquinas de
execução de modelos, que adicionam comportamento aos modelos, gerando um modelo
específico para a plataforma alvo. Em abordagens que envolve a execução dinâmica de
modelos, essa transformação resulta em comandos a serem aplicados no sistema.
Máquinas de execução de modelos têm como premissa básica que o custo do
desenvolvimento possa ser transferido e/ou eliminado, por meio de uma plataforma que
formula, sintetiza e executa serviços relacionados à um domínio específico de aplicação
[17].
De modo geral, essas máquinas tendem a ser construídas para para processar modelos em UML (Unified Modeling Language [52]. Contudo, outras abordagens empregam
essas máquinas para execução de modelos específicos de domínios [3, 17].
Além disso, uma máquina de execução de modelos é utilizada para ensejar o
emprego de modelos na construção e adaptação de aplicações, sendo capaz de interpretálos em tempo de execução. Como uma de suas atribuições, a máquina de execução
2.2 Abordagem Dirigida por Modelos em Tempo de Execução
34
é responsável por capturar e processar de forma operacional a semântica dinâmica da
linguagem. Para possibilitar a criação de aplicações complexas, a máquina de execução,
bem como o metamodelo da DSML (Linguagem de Modelagem Específica de Domínio),
devem incorporar grande parte do conhecimento específico de seu domínio.
Uma máquina de execução de modelos para domínios específicos possui o
comportamento do modelo do sistema embutido em sua própria construção, de forma
a simplificar a modelagem do sistema, uma vez que elimina a necessidade de definir
diferentes modelos para diferentes situações de um mesmo sistema. Em contrapartida, em
uma máquina de execução de UML o comportamento é capturado por meio de diagramas
comportamentais (por exemplo, diagramas de estado).
O conceito de máquinas virtuais de execução de modelos foi definido com base
na abordagem específica de domínio e foi apresentado para o domínio de comunicação,
por meio da CVM (Communication Virtual Machine) [17] e para o domínio de microgids,
por meio da MGridVM (Microgid Virtual Machine) [4]. Neste sentido, este trabalho
apresenta uma máquina virtual de execução de modelos para o domínio de crowdsensing
móvel.
Conforme ilustrado na Figura 2.5, à arquitetura de máquinas de execução de
modelos apresentam uma arquitetura padrão disposta em quatro camadas. Cada máquina
possui uma linguagem de modelagem específica de domínio. Cada camada mantém um
modelo em tempo de execução do sistema, em seu respectivo nível de abstração. A manipulação desse modelo em tempo de execução ocorre por meio de eventos gerados pelas
camada subjacentes ou do sistema, ou por meio de chamadas das camadas sobrejacentes,
ou de alterações feitas no modelo pelo usuário utilizando uma linguagem de modelagem.
Eventos são interações entre as camadas que têm sua origem em um nível inferior
para um nível superior ou entre o sistema e a máquina de execução de modelos. Em
contrapartida, chamadas são interações entre as camadas que ocorrem no sentido contrário
dos eventos, com origem em um nível superior para um nível inferior ou entre a máquina
de execução de modelos e o sistema.
Uma vez gerado um evento, por alguma camada ou pelo sistema, esse evento
é capturado pela camada imediatamente superior, e caso possua mecanismos para tratamento desse evento, ele é tratado e as operações realizadas resultam na alteração do
modelo em tempo de execução mantido pela camada. Por outro lado, caso não haja mecanismos para o tratamento do evento gerado, eles são repassados para a camada imediatamente superior à camada que o capturou. Desta forma, o evento passa por todas as
camadas em busca de mecanismos para o seu tratamento, caso o evento atinja a camada
mais superior e ainda assim não foi tratado, o usuário é notificado e a responsabilidade em
resolvê-lo é repassada a ele. Uma vez que, modelos em tempo de execução apresentam
uma conexão casual com o sistema, as alterações executadas no modelo são aplicadas
2.2 Abordagem Dirigida por Modelos em Tempo de Execução
35
também no sistema.
Figura 2.5: Arquitetura em camadas de uma máquina de execução
genérica
O processamento dos modelos construídos pelo usuário envolve as quatro camadas da máquina de execução de modelos que serão detalhadas abaixo.
User Interface - UI
Esta camada é responsável por prover uma interface externa para utilização da
plataforma. Desta forma, esta camada possibilita ao usuário criar, alterar, salvar e validar
modelos a serem interpretados pela máquina de execução.
De modo geral, a camada de interface com o usuário permite a definição,
validação e gerenciamento de modelos. A validação mantém os modelos consistentes
com as regras definidas no metamodelo. A UI apresenta três principais componentes:
(1) Modeling Environment (ME), que fornece aos usuários especialistas um ambiente
gráfico de modelagem para facilitar a criação de modelos específicos de domínio; (2)
User Interface (UI), que fornece uma interface amigável a usuários casuais para facilitar
2.2 Abordagem Dirigida por Modelos em Tempo de Execução
36
a criação de modelos específicos de domínio; e (3) Schema Transformation Environment
(STE)responsável pela validação e transformação dos modelos criados pelo usuário (na
ME e UI) em modelos textuais baseados em XML [68]. Em seguida, o modelo é enviada
para camada SE.
Synthesis Engine - SE
Esta camada é responsável pela transformação de um modelo fornecido pela UI
em uma representação algorítmica ou script de controles a serem executados pela camada
de middleware. Essa camada mantém um modelo em tempo de execução com o estado
atual do sistema.
Alterações no modelo em tempo de execução podem ocorrer: (1) pela alteração
no modelo de entrada realizada pelo usuário (por meio da UI); ou (2) por mudanças no
sistema controlado. No primeiro caso é realizado o cálculo da diferença entre o novo
modelo de entrada e o modelo mantido em tempo de execução na camada SE, com
o objetivo de evitar a geração desnecessária de scripts de configuração. Em seguida,
é gerado um script para aplicar as diferenças no sistema. No segundo caso, após a
camada SE receber eventos informando que houve mudanças no sistema, esses eventos
são analisados e o modelo em tempo de execução mantido pela camada é atualizado. Em
seguida, a camada SE informa que houve alterações à camada UI para que atualize o
modelo especificado pelo usuário [17].
Os eventos recebidos da camada inferior (CM) que a SE não possui mecanismos
para tratá-los, são repassados para camada superior (UI) para que o usuário possa tratá-los
de forma adequada.
Middleware - M
A camada de middleware é responsável por executar as requisições/scripts de
controle gerados pela camada SE e também gerenciar os serviços providos pela máquina
de execução (englobando as tarefas de execução). Após execução dos scripts, ela se
encarrega de gerar comandos a serem executados na camada de broker (SB). Além disso,
é responsabilidade desta camada a aplicação de propriedades não-funcionais no script
executado, como por exemplo autenticar os comandos gerados em conformidade com o
privilégio de acesso do usuário.
Os eventos ou exceções geradas pela camada SB são manipulados pela camada
de middleware. Caso a camada não possua mecanismos para tratar esses eventos, eles são
enviados à camada acima (SE) para serem tratados.
2.3 Conclusão
37
Service Broker - SB
A camada Service Broker (SB), ou simplesmente broker, fornece uma API para
a camada de middleware que permite interagir com a aplicação/sistema subjacente à
máquina de interpretação [68]. Essa camada é responsável por gerenciar os recursos, que
são elementos finais controlados pela máquina de execução, tendo como objetivo prover
uma interface de acesso aos recursos de maneira independente de tecnologia.
Além de gerenciar os recursos, essa camada têm como principais funções:
monitorar o modelo em tempo de execução do sistema; monitorar os eventos lançados
pelos recursos controlados; e selecionar os recursos apropriados para aplicar os comandos
recebidos pela camada de middleware.
2.2.4
Considerações Gerais
Neste capítulo apresentamos os fundamentos de abordagens de engenharia dirigida por modelos, que são empregados em máquinas de execução de modelos específicas de domínio para possibilitar a construção e processamento de modelos de alto nível.
Para isso, foram apresentados os principais conceitos referentes a modelos e metamodelos, destacando a arquitetura de metamodelagem, a qual envolve quatro camadas, bem
como as principais características de linguagens de modelagem específicas de domínio
(DSMLs) utilizadas na construção de modelos. Além disso, também tratamos dos princípios relacionados a modelos construídos e modificados em tempo de execução e como
estes podem ser aplicados em diferentes cenários. Por fim, discutimos as características
gerais da abordagem de execução e interpretação de modelos utiliza neste trabalho.
2.3
Conclusão
Os conceitos discutidos neste capítulo são fundamentais para a compreensão do
presente trabalho, uma vez que a abordagem proposta envolve a utilização de modelos
para reduzir a complexidade envolvida no processo de criação e execução de aplicações
de crowdsensing móvel. O capítulo seguinte apresenta detalhes dessa abordagem.
CAPÍTULO 3
A Linguagem CSML
Ambientes de crowdsensing móvel compreendem uma vasta quantidade de aplicações que necessitam comunicar e trocar dados entre si. Sua essência, bem como os
principais desafios, está na diversidade e quantidade de dispositivos associados, nas condições dinâmicas dos cenários e no processo de identificação de dispositivos para atenderem a uma determinada requisição [23]. Para transpor essas dificuldades, propomos
uma abordagem dirigida por modelos em tempo de execução e, para viabilizá-la, definimos uma linguagem de modelagem de aplicações de crowdsensing móvel, denominada
CSML, juntamente com seu modelo de execução que envolve uma plataforma para execução de modelos para o domínio de crowdsensing móvel, CSVM.
Muitas abordagens dirigidas por modelos se apoiam na geração de código.
Porém, este trabalho segue uma linha diferente, onde modelos especificados em CSML
são diretamente interpretados e executados por uma plataforma específica [17] (descrita
na Seção 3.3).
A construção de linguagens de modelagem específicas de domínio (DomainSpecific Modeling Languages, DSMLs) deve refletir um conjunto de requisitos específicos. Em particular, identificamos quatro principais requisitos para a CSML:
• Simplicidade: Ser simples e intuitiva, para facilitar o seu uso e compreensão;
• Independente de dispositivos: Possibilitar que diferentes dispositivos integrem a
plataforma e utilizem seus serviços;
• Expressividade: Deve ser capaz de modelar a maioria dos cenários de aplicações
de crowdsensing;
• Flexibilidade: Deve possibilitar a reconfigurar consultas em resposta a alterações
do ambiente e/ou na intenção do usuário.
Neste capítulo discutiremos a linguagem de modelagem CSML, apresentando
na Seção 3.2 sua definição, principais características e sua construção com base em seu
metamodelo. Na Seção 3.3 apresentamos uma visão geral de como deve ser definido
e criado um modelo de execução para CSML, onde apresentamos também a CSVM,
uma máquina de execução de modelos para o domínio de crowdsensing que compõe
3.1 Terminologia
39
o ambiente de execução proposto e que aplica os conceitos de modelos em tempo de
execução descritos no Capítulo 2.
3.1
Terminologia
Com o intuito de facilitar o entendimento, esta seção apresenta os principais
termos empregados neste trabalho e suas definições.
• Problemas de crowdsensing: são problemas que podem ser modelados por
aplicações de crowdsensing, por exemplo, medir o nível de poluição de um determinado local.
• Aplicação de crowdsensing: são aplicações que utilizam dados monitorados
e compartilhados por diferentes dispositivos móveis para compor uma informação
útil ao usuário. Por exemplo, uma aplicação para monitorar a temperatura de um
ambiente e controlar a temperatura do ar condicionado.
• Serviços de crowdsensing: os serviços de crowdsensing no contexto deste
trabalho se referem ao registro de dispositivos na plataforma e a especificação de
consultas de crowdsensing.
• Funcionalidades de crowdsensing: equivalem aos serviços de crowdsensing, porém com um nível maior de detalhamento, por exemplo, recrutar dispositivos, manter modelos em tempo de execução, processar requisições, obter e agregar
dados sensoriados.
• Consultas de crowdsensing: são consultas geradas a partir da modelagem
de um problema de crowdsensing e possuem como principal finalidade definir quais
os sensores desejados e quais as condições de monitoramento desses sensores, como
localização e quantidade.
• Recursos dos dispositivos: referem-se aos sensores embarcados nos dispositivos móveis.
• Recursos do ambiente: referem-se aos dispositivos registrados na plataforma
que compartilham seus recursos (sensores).
• Dispositivo lógico: é à representação lógica de um dispositivo físico registrado
na plataforma e seu conjunto de sensores.
• Esquemas: são modelos descritos em uma linguagem de modelagem específica
de domínio (a CSML), utilizados para descrever: os componentes do ambiente,
que englobam os dispositivos registrados e os sensores associados a cada um
deles (esquema de controle do ambiente); as consultas de crowdsensing móvel,
por meio do (esquema de controle da consulta); e os dados a serem monitorados
em conformidade com os tipos de sensores especificados em uma consulta de
crowdsensing (esquema de dados).
3.2 CSML
3.2
40
CSML
A CSML é uma linguagem de modelagem específica para ambientes de crowdsensing móvel que permite descrever e modelar em tempo de execução aplicações pertencentes a este domínio. Ela também pode ser caracterizada como uma linguagem declarativa segundo a qual usuários e, principalmente, desenvolvedores, devem se preocupar
apenas em especificar as características das tarefas de crowdsensing a serem realizadas,
isentando-os dos detalhes de como o executor da CSML interpretará e executará essas
tarefas.
As tarefas de crowdsensing são especificadas a partir de modelos descritos
em CSML pelos usuários (tanto especialistas do domínio, ou seja desenvolvedores de
aplicações de crowdsensing, quanto usuários finais) de forma simples e direta, o que a
caracteriza como uma linguagem de modelagem de alto nível.
A CSML compreende duas formas de representação sendo uma delas com base
na linguagem XML (eXtensible Markup Language), X-CSML, e a outra por meio de
elementos gráficos, a G-CSML.
A linguagem X-CSML possui sua sintaxe definida por um esquema XML.
Esta notação possibilita representar o ambiente e as consultas assim como os dados a
serem transferidos, por meio de tags XML que denotam elementos do metamodelo da
CSML, suas especificações (características, propriedades ou atributos) e suas relações.
Desta forma ela possibilita mapear, por exemplo, relacionamentos onde um elemento
dispositivo, que apresenta como características o proprietário, a marca e o modelo, se
associa com o elemento que define os tipos de sensores para os quais ele oferece suporte.
A X-CSML é uma representação interna utilizada pela CSVM para manipulação
de modelos. Uma das principais vantagens no seu uso é sua capacidade de modelar
cenários complexos, por meio de construções utilizando tags XML. Para uma melhor
compreensão, apresentamos na subseção 3.2.3 exemplos de uso de X-CSML em um dos
cenários descritos no Capítulo 1.
A G-CSML (Graphical CSML) é uma representação alternativa que usa elementos gráficos para denotar características de consultas de crowdsensing. Esta variação gráfica da CSML é análoga ao digrama de Entidade e Relacionamento (ER) aplicado na área
de banco de dados. Contudo, apesar da similaridade gráfica, elas apresentam semânticas
diferentes.
A Figura 3.1 apresenta um exemplo de uso da G-CSML, onde Dispositivo1 e
Dispositivo2 participam da aplicação de crowdsensing compartilhando dados coletados
por seus sensores de temperatura. O modelo G-CSML apresentado representa uma
instância de uma consulta criada por uma aplicação (ou usuário) que solicita dados de dois
sensores de temperatura localizados no INF-UFG. Além das propriedades da consulta, o
3.2 CSML
41
Figura 3.1: Representação Geral da G-CSML
modelo especifica o tipo de notificação (neste caso, SobDemanda) e a operação que será
realizada sobre os dados coletados (neste caso, Média). Estas e outras propriedades serão
detalhadas na subseção 3.2.3.
A gramática que define os elementos da linguagem G-CSML não foi explorada
neste trabalho, sendo que sua definição é apresentada apenas informalmente. Sua definição formal fará parte de trabalhos futuros. A definição formal da CSML segue os mesmos
moldes que a definição formal da CML (Communication Modeling Language) apresentada em [15].
Adotando uma perspectiva comportamental de aplicações de crowdsensing é
possível identificar duas funcionalidades principais comuns a todas elas: o registro de
dispositivo, onde o usuário permite que seu dispositivo componha o ambiente de crowdsensing, e a especificação de consultas, onde o usuário informa quais dados serão necessários de acordo com o contexto da aplicação. Em particular, nestes dois momentos
faz-se necessária a intervenção do usuário para descrever tanto as características e capacidades do dispositivo que deseja que sejam compartilhadas (etapa de registro), quanto
as informações do ambiente que deseja monitorar (de acordo com cada aplicação) como
por exemplo, os tipos e quantidade de sensores desejados e sua localização. Um modelo
descrito em CSML pode ser modificado ao longo da execução de uma aplicação de crowdsensing. Devido a esta natureza e a outros aspectos como adaptação e reflexão (que serão
descritos em seguida), os modelos em CSML podem ser considerados como modelos de
tempo de execução [66].
Para alcançarmos os requisitos definidos no inicio deste capítulo e facilitar
a compreensão do usuário quanto à modelagem das aplicações, optamos por dividir
a CSML de acordo com modelos que representam controle e dados, cada qual com
finalidades distintas e bem definidas. Partindo deste princípio, a definição da CSML é
dividida em duas partes, que permitem a construção de esquemas de controle e esquemas
de dados.
3.2 CSML
42
Esquemas de controle são modelos que representam a configuração lógica de
crowdsensing e podem ser subdividido em dois tipos de esquema: esquema de controle
do ambiente e esquema de controle da consulta. O esquema de controle do ambiente representa a configuração do ambiente, definindo os tipos de dispositivos, tipos de sensores
e tipos de operações que são suportados pela plataforma. O esquema de controle da consulta por sua vez, define uma consulta de crowdsensing propriamente dita (especificada
pelo usuário ou aplicação). Esquemas de dados, por sua vez, são modelos que representam
os dados que devem ser monitorados por dispositivos participantes da consulta.
A partir da CSML, é possível definir instâncias dos esquemas apresentados. A
relação entre um esquema e uma instância se equipara ao relacionamento entre uma
classe e um objeto. Assim sendo, uma instância é a materialização ou concretização
de um esquema, que se dá por meio da associação de valores às tags predefinidas
no esquema. Essas tags representam as informações que caracterizam o esquema. Por
exemplo, um esquema de dados pode possuir tags como tipo de sensor e valor,
enquanto a instância desse esquema de dados compreenderia essas tags com os valores
temperatura e 25 respectivamente.
Assim como um programa manipula um conjunto de dados, a metamodelagem
proposta apresenta a mesma característica, onde o esquema de controle representa o
programa e o esquema de dados, por sua vez, os dados que o programa manipula. Na
seção seguinte, apresentamos o metamodelo da CSML.
3.2.1
Metamodelo: Visão Geral
O metamodelo da CSML define os elementos necessários para construção de
aplicações no domínio de crowdsensing, incorporando conhecimento e requisitos específicos deste domínio.
Antes porém de apresentar o metamodelo da CSML propriamente dito, optamos
por representar a definição e uso da CSML na Figura 3.2 usando a arquitetura de
metamodelagem da OMG, descrita na Seção 2.2. Desta forma, a linguagem proposta é
definida no nível M2 e seu uso é feito por meio da definição de elementos (modelo e
objetos) nos níveis M1 e M0.
A partir do meta-metamodelo (o modelo MOF, no nível M3), definimos no nível
M2 o metamodelo da CSML (CSML Metamodel), que propõe um conjunto de elementos
para construção de aplicações de crowdsensing. A construção do metamodelo da CSML
é dividida em duas partes: o metamodelo do esquema de controle (CS Metamodel) e o
metamodelo do esquema de dados (DS Metamodel).
Em concordância com a arquitetura apresentada, o metamodelo do esquema
de controle é composto pelo metamodelo do esquema de controle do ambiente (ECS
3.2 CSML
43
Metamodel), que descreve como o ambiente de crowdsensing pode ser construído (por
meio do registro de dispositivos e um conjunto predefinido de tipos de sensores) e
pelo metamodelo do esquema de controle da consulta (QCS Metamodel), que especifica
elementos para construção de consultas de crowdsensing. Por outro lado, o metamodelo
do esquema de dados permite definir as estruturas que compreendem a transferência
de dados entre os componentes de uma aplicação de crowdsensing. A junção destes
metamodelos compreende o metamodelo da CSML.
Figura 3.2: Definição e uso da CSML usando a arquitetura de
metamolagem da OMG.
Os metamodelos descritos acima são utilizados para construir os modelos que
integram o nível M1 e que são usados para definir as funcionalidades de crowdsensing
das aplicações. Na arquitetura de metamodelagem, esses modelos são representados por
meio de esquemas.
O esquema de controle do ambiente (EnvControlSchema - ECS) descreve todo o
ambiente de crowdsensing compreendendo os dispositivos registrados (com seus respectivos sensores) e um conjunto elementos predefinidos. Desta forma, um ECS é definido
em termos de um conjunto de elementos, que podem ser:
• Tipos de dispositivo: definidos em termos da marca, modelo, sistema operacional e categoria (smartphone, tablet e outros) dos dispositivos.
• Tipos de sensor: definem o tipos de sensor associados aos dispositivos.
• Tipos de operação: compreendem um conjunto de operações associadas aos
dados coletados pelos dispositivos. Por exemplo, o cálculo da média da temperatura
de um ambiente.
• Tipos de combinação: compreendem a forma de associar os dados coletados por
dois ou mais dispositivos.
• Notificação: compreendem a forma em que os dados serão notificados pelos
dispositivos, como por exemplo, com base em algum evento.
3.2 CSML
44
Em relação ao esquema de controle da consulta (QueryControlSchema - QCS),
este permite especificar uma ou mais consultas, informando os tipos de sensor desejados
e relacionando a cada um a quantidade, a localização, a operação, o tipo de combinação e
notificação. As consultas são especificadas de acordo com o domínio da aplicação.
Por fim, o esquema de dados (DataSchema) é construído de forma automática
como resultado de uma consulta previamente especificada por uma aplicação (ou usuário).
Assim sendo, o esquema de dados representa um formulário (form) a ser preenchido,
contendo atributos como valor, tipo de dado, unidade de medida, tipo de sensor, precisão
e horário da coleta do dado. O esquema de dados descreve também dados referentes à
requisição, como tipo da requisição e da notificação e o identificador (id) da consulta
geradora deste esquema de dados.
Os esquemas de controle que integram a camada M1 são modelos em tempo de
execução para ambientes de crowdsensing, sendo portanto uma auto-representação causalmente conectada do ambiente e das consultas especificadas. Desta forma, qualquer
alteração no ambiente (por exemplo, registro ou cancelamento do registro) ou na consulta
(por exemplo, alteração dos tipos de sensores a serem monitorados) refletem imediatamente no modelo, bem como qualquer alteração no modelo em tempo de execução refletirá no comportamento da aplicação. Este comportamento caracteriza a camada M1 como
sendo dinâmica.
Finalmente, na camada M0 temos instâncias dos modelos do nível M1 que
representam objetos reais ou uma concretização dos modelos que os descrevem. Da
mesma forma que entre as camadas M1 e M2 há uma relação de instanciação par a
par (ou seja, cada metamodelo em M2 descreve um modelo em M1), as camadas M0
e M1 mantém esta relação e seu significado. Uma instância do esquema de controle
do ambiente (ECS Instance) representa um conjunto (ou subconjunto) de dispositivos
específicos (registrados) com seus respectivos sensores. Por outro lado, uma instância do
esquema de controle da consulta (QCS Instance) representa um conjunto de dispositivos
(previamente escolhidos) que satisfazem os critérios da consulta (como localização e
tipos de sensores) especificada pelo usuário. Desta forma, a criação desta instância está
totalmente associada ao esquema de controle do ambiente que descreve os dispositivos
que estão registrados e os sensores que cada um deles está compartilhando. A instância do
esquema de dados (DS Instance) representa o form com os campos/atributos preenchidos
como resultado da execução da consulta.
3.2.2
Metamodelo: Detalhamento
Uma vez descrita a arquitetura de modelagem da CSML e as características
gerais de seu metamodelo a próxima seção apresenta um detalhamento do metamodelo
3.2 CSML
45
Figura 3.3: Visão Geral do Metamodelo da CSML
utilizando diagramas de classe UML (Unified Modeling Language). O diagrama de
classes da Figura 3.3 apresenta a estrutura geral do metamodelo da CSML. A seguir
apresentamos respectivamente os metamodelos do esquema de controle do ambiente, do
esquema de consultas e do esquema de dados a fim de elucidar a estrutura e os principais
elementos do metamodelo da CSML. É importante ressaltar que adotamos o padrão UML
para representar os metamodelos por entendermos que é um padrão amplamente utilizado
e de fácil interpretação.
Esquema de Controle do Ambiente
Em um cenário de crowdsensing móvel que compreende diversas aplicações em
execução simultaneamente, uma importante etapa que antecede a troca e compartilhamento de dados pelos dispositivos participantes é o registro desses dispositivos. Nesta
etapa, os dispositivos se anunciam de forma a compor o grupo de dispositivos participantes. Partindo desse pressuposto, uma das finalidades do metamodelo do Esquema de
Controle do Ambiente (Environment Control Schema - ECS), apresentado no diagrama
da Figura 3.4, é descrever elementos que permitam que o usuário registre seu dispositivo
com suas características e capacidades.
Para modelar o registro do dispositivo, utiliza-se o elemento Registration, que
possui um identificador único (registerID). Desta forma, o metamodelo determina que
cada registro deve referir-se a um único dispositivo (Device) com o seu tipo (marca,
modelo, sistema operacional e categoria) e proprietário. No registro deve-se também
informar quais sensores do dispositivo o usuário deseja compartilhar (DeviceSensor).
Após sua criação, um registro de dispositivo passa a fazer parte do ECS. A
partir daí, o anúncio do dispositivo pode ser feito utilizando o modelo plug-and-play [61],
significando que, após se registrar no ambiente, o dispositivo já está apto a colaborar com
as aplicações de crowdsensing.
O ECS é responsável também por descrever os componentes do ambiente e
mantê-los sempre atualizados. Estes componentes englobam os dispositivos que estão
registrados e os sensores associados a cada um deles, assim como um conjunto de
elementos predefinidos. Ao analisarmos as características de ambientes de crowdsensing,
identificamos cinco elementos que podem ser predefinidos. Seguindo a notação UML
3.2 CSML
46
Figura 3.4: Metamodelo que descreve o Esquema de Controle do
Ambiente.
adotada, optamos por representá-los por meio de enumerações, conforme mostrado na
Figura 3.5:
• Tipo de Sensor (SensorKindList) - define o conjunto de tipos de sensores suportados pelo ambiente;
• Tipo de Operação (OperationKind) - define os tipos de operações passíveis de
serem realizadas entre os dados coletados pelos sensores, por exemplo, o cálculo da
média da umidade do ar em um ambiente;
• Tipo de Combinação (CombinationKind) - define a forma de combinar dados
coletados de dois ou mais sensores (do mesmo tipo ou não);
• Tipo de Notificação (NotifyKind) - define a forma que os dispositivos participantes
de uma consulta devem notificar os dados coletados;
• Tipo de Requisição (RequestKind) - define a forma que uma determinada requisição será enviada aos demais dispositivos, podendo ser para um único dispositivo,
para um grupo de dispositivos selecionados ou para todos os dispositivos registrados.
A Figura 3.6 ilustra dois exemplos de elementos predefinidos pelo metamodelo
do ECS, respectivamente, para sensores, 3.6(a), e para operações, 3.6(b). Os elementos
predefinidos são atualizados automaticamente de acordo com o surgimento de novos tipos,
por exemplo o surgimento de novos sensores embarcados nos dispositivos móveis.
Os tipos de sensores (SensorKind) mantidos pelo ECS apresentam uma característica específica que os diferem dos demais tipos. Eles podem ser decompostos em tipos
3.2 CSML
47
Figura 3.5: Pacote de enumerações mantidas pelo Esquema de
Controle do Ambiente.
(a) Tipos de sensores.
(b) Tipos de operação.
Figura 3.6: (a) e (b) representam respectivamente os tipos de sensores e operações mantidos pelo metamodelo do ECS.
primitivos, PrimitiveSensorKind, que é uma representação virtual de um sensor físico
embarcado no dispositivo, e tipos compostos, CompositeSensorKind, que são formados
pela combinação de dois ou mais tipos de sensores (podendo estes serem primitivos ou
compostos). Desta forma, os tipos compostos são sensores virtuais instanciados a partir
de dois ou mais sensores físicos, ou seja, eles não representam sensores embarcados nos
dispositivos.
De maneira geral o ECS representa a estrutura de um ambiente de crowdsensing,
controlando em tempo de execução os novos recursos e aqueles já disponíveis. Desta
forma, o ECS vai sendo construído dinamicamente à medida que novos dispositivos se
registram para participar do ambiente.
3.2 CSML
48
Esquema de Controle da Consulta
A essência de ambientes de crowdsensing está no compartilhamento e troca de
dados entre os componentes participantes, seja de forma oportunista (sem intervenção
humana) ou participativa (com intervenção humana). Porém, o que determina a eficiência
e eficácia do uso destes dados são as aplicações desenvolvidas e a plataforma que as apoia.
Essas aplicações devem expor as necessidades de crowdsensing de forma automatizada
(por meio de uma autorização prévia do usuário) ou permitir que o usuário as especifique
manualmente.
Neste sentido, e aplicando a abordagem dirigida por modelos em tempo de
execução, este trabalho propõe a criação de um metamodelo que descreve os principais
elementos para a criação de consultas de crowdsensing móvel. O diagrama da Figura 3.7
apresenta o metamodelo do Esquema de Controle da Consulta (Query Control Schema QCS).
Figura 3.7: Diagrama do metamodelo que descreve o Esquema de
Controle da Consulta.
O metamodelo do QCS é relativamente simples e sua construção, conforme
diagrama apresentado, compreende três elementos principais. É importante notar que
em nossa proposta as consultas representam subscrições (representadas pelo elemento
Subscription e geradas pelos dispositivos solicitantes). Cada subscrição gerada deve
conter um ou mais tipos de sensores (elemento SensorTypeRequest) associados. Estes
tipos de sensores englobam atributos que caracterizam uma consulta de crowdsensing
e são especificados de acordo com a necessidade de uma determinada aplicação de
crowdsensing.
3.2 CSML
49
Desta forma, ao especificar uma consulta o usuário deve informar o tipo de
combinação (aggregation) que estará associada à subscrição (esta combinação pode ser
aplicada a fim de combinar dados de diferentes sensores ou uma simples junção dos dados
coletados); para cada sensor solicitado, deve-se especificar:
• Tipo (type) - define o tipo do sensor a ser monitorado com base nos tipos de
sensores mantido pelo ECS.
• Quantidade (quantity) - define a quantidade de dispositivos a serem monitorados,
de acordo com o tipo de sensor especificado.
• Localização (location) - determina a localização a ser monitorada.
• Operação (operation) - define qual operação será realizada sobre o conjunto de
dados coletados por um determinado tipo de sensor e é delimitada pelos tipos de
operações mantido pelo ECS.
• Requisição (request) - determina o tipo de notificação que estará associado a um
determinado tipo de sensor. Esse tipo é definido com base nos tipos predefinidos
de notificações mantidos pelo ECS e refere-se ao momento em que os dados
necessitarão ser coletados, podendo ser no momento da consulta, agendado para
uma data/hora futura ou com base em algum evento disparado.
A criação da instância do QCS é realizada pela plataforma e envolve a seleção de
dispositivos que satisfaçam a consulta especificada pelo usuário por meio do QCS. Desta
forma, a instância compreende o QCS mais os dispositivos recrutados. De modo geral, o
QCS controla (em tempo de execução) a escolha e manutenção de dispositivos registrados
na plataforma durante toda a execução de uma consulta. Por exemplo, o usuário pode
especificar uma consulta (QCS), da forma: necessito da média de 10 (dez) sensores de
umidade localizados no INF-UFG. A instância desse QCS compreende o próprio QCS e o
conjunto de dez dispositivos recrutados para participar colaborativamente dessa consulta.
A fim de manter a consistência de uma instância do QCS, propomos neste
trabalho representar o QCS como um modelo em tempo de execução, que é mantido
sincronizado com a aplicação e com o ambiente. Ou seja, o usuário poderá editar
uma consulta previamente especificada (modelo QCS) e esta alteração será refletida
no comportamento da plataforma de execução. Da mesma forma, qualquer variação do
ambiente (por exemplo, um dispositivo que esteja participando de uma aplicação fica
indisponível) refletirá no QCS. Em ambos cenários, faz-se necessária uma adaptação da
instância do QCS conforme as mudanças identificadas.
Esquema de Dados
Como foi descrito anteriormente, compartilhamento e troca de dados estão
presente na essência de ambientes de crowdsensing e qualquer falha nesta etapa é
3.2 CSML
50
prejudicial à aplicação. Partindo deste pressuposto, apresentamos a última, mas não
menos importante parte que integra o metamodelo da CSML, o metamodelo do Esquema
de Dados (Data Schema - DS), ilustrado no diagrama da Figura 3.8.
Este metamodelo descreve os elementos necessários para construção de um
esquema de dados, que contém um formulário (form) que deverá ser preenchido pelos
dispositivos selecionados em uma consulta (especificados na instância do QCS) com
informações do sensor (SensorInformation) requerido na aplicação. Este form é um
template que descreve como, quando e quais dados devem ser monitorados, através dos
seguintes campos:
• Data e hora (timeStamp) - expressa o momento em que o dado foi coletado.
• Precisão (accuracy) - especifica a precisão com a qual o dado foi coletado.
• Tipo de sensor (sensorType) - especifica o sensor a ser monitorado em conformidade com o tipo descrito em uma consulta ao ser especificada pelo usuário.
• Valor (value) - determina o valor coletado do sensor.
• Tipo de dado (dataType) - define a representação dos dados coletados (por exemplo, tipos como inteiro ou texto).
• Unidade (unit) - define a unidade de medida referente ao dado coletado pelo sensor.
Uma das principais características do DS é que sua construção ocorre de forma
automática (sem intervenção do usuário), tendo como referência a consulta especificada
pelo usuário na forma de um QCS. De maneira geral, para cada tipo de sensor especificado
em uma consulta (QCS) um DS é construído. Assim sendo, a partir de um QCS um ou
mais DS são derivados.
Figura 3.8: Diagrama do Metamodelo que descreve o Esquema de
Dados.
Conforme ilustrado no diagrama, o DS pode ser representado por uma requisição (Request) ou notificação (Notification). Uma requisição é representada pelo próprio
3.2 CSML
51
DS enviado aos dispositivos escolhidos e é construída de forma automática a partir de
um QCS. Desta forma, ela contém o identificador do QCS que a originou (queryControlSchemaID), o tipo de requisição, que define se aquele DS será enviado a um ou mais
dispositivos (type) e, por fim, a forma com que os dados devem ser notificados, ou seja,
enviados do dispositivo (period). A notificação representa a instância do DS que é construída a partir de uma requisição (DS) no dispositivo móvel selecionado. A instância do
DS compreende o formulário preenchido com informações coletadas do ambiente monitorado.
Na seção seguinte, apresentaremos um exemplo de uso destes modelos ilustrando
seu uso no cenário descrito na Seção 1.2.
3.2.3
Exemplo de Uso
Para apresentar os exemplos de uso dos modelos descritos, optamos por utilizar
a X-CSML (representação da CSML com base em XML). Deste modo, ilustramos a
aplicabilidade dos modelos e também a conveniência do uso desta representação. Nesta
seção, os modelos foram utilizados para descrever um problema de crowdsensing no
cenário apresentado na Seção 1.2. Mais especificamente, o problema pode ser descrito
como: “Em uma casa noturna um novo gerente é contratado e, entre suas atribuições está
o monitoramento da temperatura do interior do ambiente durante um evento. Para isso,
foi-lhe dado um novo smartphone para uso nessa tarefa. O novo gerente foi orientado
a utilizar uma aplicação de monitoramento da temperatura que recorre aos serviços de
crowdsensing da plataforma CSVM para realizar a captura dos dados.”
Para que o novo gerente possa especificar consultas referentes ao problema,
ele precisa antes registrar seu dispositivo na plataforma, assim como outros dispositivos
de frequentadores (funcionários e/ou clientes) da boate precisam ter sido registrados. A
Figura 3.9 apresenta o esquema de controle, em X-CSML, gerado após o gerente solicitar
o registro do dispositivo. Este esquema passa então a integrar o esquema de controle do
ambiente, mantido no repositório.
Após solicitado o registro, o gerente pode especificar consultas e utilizar os recursos de crowdsensing fornecidos pela plataforma. Em geral, as consultas das aplicações de crowdsensing são construídas em resposta a questionamentos, como: Preciso de
X sensores do tipo Y localizados na região Z. Desta forma, e de acordo com o problema
apresentado no início desta seção, o gerente especifica a seguinte consulta: Preciso de
10 sensores de temperatura localizados na boate X.
A Figura 3.10(a) apresenta o esquema de controle da consulta em X-CSML
referente à consulta especificada pelo gerente. O tipo de operação (avg) e o tipo de
requisição (onDemand) também são especificados como parte da consulta. O próximo
3.2 CSML
52
Figura 3.9: Representação em X-CSML do esquema de controle
para registro do dispositivo.
passo envolve a criação de uma instância do esquema de controle da consulta, por meio
da seleção de dispositivos registrados na plataforma que satisfaça a consulta especificada
pelo gerente. Os dispositivos recrutados são adicionados na representação em X-CSML
para auxiliar no processamento da consulta. A Figura 3.10(b) apresenta apenas parte dessa
instância, cuja versão completa compreende 10 dispositivos recrutados. O Apêndice A,
apresenta o modelo X-CSML completo dessa instância.
(a) Esquema de controle da consulta.
(b) Instância do esquema de controle da consulta.
Figura 3.10: Representação em X-CSML do esquema de controle
da consulta (a) e sua instância (b).
3.3 Modelo Geral de Execução
(a) Esquema de dados.
53
(b) Instância do esquema dados.
Figura 3.11: Representação em X-CSML do esquema de dados (a)
e sua instância (b).
Tão logo especificada a consulta e recrutados os dispositivos, é gerado o esquema
de dados referente à consulta. A Figura 3.11(a) apresenta o código X-CSML do esquema
de dados, contendo: um form a ser enviado a cada dispositivo e uma lista com os
dispositivos recrutados. É importante ressaltar que a requisição envolve o envio do form
“vazio” para preenchimento após captura dos dados pelos dispositivos recrutados. Após
recebido o form, cada dispositivo inicia o monitoramento do ambiente.
A Figura 3.11(b) apresenta o X-CSML da instância do esquema de dados recebido dos dispositivos. Essa instância representa o form preenchido com dados referentes
ao sensor requisitado. Por fim, essa instância será notificada para composição da resposta
solicitada pelo gerente.
3.3
Modelo Geral de Execução
Apesar do metamodelo da CSML prover abstrações que possibilitam descrever
uma aplicação de crowdsensing, isto isoladamente não é suficiente para se obter uma
plataforma executável, capaz atender e processar requisições em tempo de execução. Com
o intuito de preencher essa lacuna, propomos e desenvolvemos uma máquina de execução,
a CSVM, responsável por carregar e interpretar modelos definidos em CSML e executar
as ações neles descritas. Podemos dizer então que essa máquina de execução implementa
a semântica operacional da linguagem.
O conceito empregado neste trabalho para criação do ambiente e da máquina de
execução, foi inspirado na CVM (Communication Virtual Machine) [17] e na MGridVM
3.4 Considerações Finais
54
(Microgrid Virtual Machine) [3] , embora as similaridades estejam restritas à definição
geral das camadas e de algumas de suas funcionalidades.
Figura 3.12: Modelo de execução da CSVM.
A partir de um modelo definido em CSML, a CSVM é capaz de executar as
tarefas de crowdsensing de forma automática, sem a necessidade de intervenção humana.
Ela também é capaz de identificar e capturar as alterações (durante a execução de uma
aplicação) do modelo CSML e adaptar as consultas em andamento. A arquitetura da
CSVM será detalhada no capítulo a seguir juntamente com sua implementação.
A Figura 3.12 apresenta uma visão geral do modelo de execução da CSVM
e os principais componentes que o integram. Conforme ilustrado, um modelo de alto
nível especificado pelo usuário em CSML é interpretado e processado pela máquina de
execução de modelos (CSVM). Durante o processamento desse modelo a CSVM mantém
um modelo em tempo de execução (Model at runtime - M@rt) sempre atualizado sendo
que qualquer alteração nesse modelo também reflete no funcionamento da CSVM (i).
Um outro comportamento associado à CSVM e descrito no modelo de execução
é o acesso constante a dispositivos registrados no ambiente, os quais por sua vez, enviam
notificações à CSVM (ii). A figura ilustra também uma configuração da CSVM que é
implementada para ser executada nos dispositivos móveis, dando suporte à construção
de modelos de alto nível e ao processamento de requisições. Esta implementação é
denominada CSVM4Dev (CrowdSensing Virtual Machine for Device). Na subseção
seguinte apresentaremos uma visão geral da CSVM e suas principais funcionalidades.
3.4
Considerações Finais
Neste capítulo apresentamos a linguagem de modelagem específica para o domínio de crowdsensing, CSML, que descreve a forma com a qual usuários podem especificar
consultas de crowdsensing seguindo as premissas de que as consultas podem ser mantidas
ou alteradas em tempo de execução de acordo com as necessidades do usuário ou varia-
3.4 Considerações Finais
55
ção do ambiente. Para isso, construímos o metamodelo dessa linguagem, que incorpora
os principais aspectos e características de seu domínio de aplicação.
Em seguida, apresentamos uma visão geral da CSVM, uma plataforma dirigida
por modelos que foi construída seguindo a arquitetura padrão de máquinas de execução de
modelos composta por camadas (conforme descrito na Seção 2.2) e encapsula as tarefas
necessárias à execução de aplicações de crowdsensing. Nesse sentido, apresentamos o
modelo de execução da CSVM e, associado a ele, os dois principais elementos da CSVM:
CSVMProvider e CSVM4Dev.
Com base na abordagem dirigida por modelos para o domínio de crowdsensing
móvel e seu modelo de execução apresentados neste capítulo, o Capítulo 4 apresenta
detalhes da arquitetura da CSVM em conformidade com esta abordagem, seguido de sua
implementação, descrita no Capítulo 5.
CAPÍTULO 4
Arquitetura da CSVM
Aplicações de crowdsensing móvel apresentam um conjunto de características
que as diferenciam de aplicações tradicionais de redes de sensores. Essas características
resultam tanto em novas oportunidades quanto em um alto grau de complexidade. Para
dar suporte ao comportamento dessas aplicações a arquitetura deve satisfazer alguns requisitos básicos, como: diversidade de dispositivos, limitações de recursos, dinamicidade
do ambiente, privacidade, segurança e integridade dos dados.
O projeto da CSVM foi guiado por um conjunto de decisões arquiteturais
fundamentadas nos principais desafios relacionados às aplicações de crowdsensing móvel
(discutidos na Seção 2.1). Desta forma a CSVM deve:
• Permitir que usuários ou desenvolvedores de aplicações de crowdsensing especifiquem suas necessidades de dados em uma linguagem de alto nível;
• Identificar e selecionar automaticamente os dispositivos que podem prover os dados
desejados;
• Produzir instruções para configurar as atividades de sensoriamento nos dispositivos;
• Refletir mudanças dinâmicas do cenário, adaptando o conjunto de dispositivos e
sensores escolhidos para garantir a qualidade dos dados desejados;
• Permitir que o usuário altere uma consulta em execução e refletir esta alteração no
comportamento da plataforma;
• Apresentar uma arquitetura no provedor de serviço que abstraia a forma de acesso
a diferentes dispositivos físicos;
• Apresentar uma camada independente de dispositivo que acesse os diferentes
sensores físicos embarcados;
Para responder a estes desafios, a CSVM é uma plataforma que incorpora uma
abordagem dirigida por modelos em tempo de execução para ambientes de crowdsensing
(discutida na Seção 2.2) e integra características sobre o domínio a qual ela se aplica,
crowdsensing móvel, o que inclui serviço de detecção e recrutamento de dispositivos,
unidades de sensoriamento e relações matemáticas entre as diferentes unidades. O uso da
abordagem proposta neste trabalho, já não exige que os desenvolvedores de aplicações
4.1 Visão Geral da Arquitetura
57
de crowdsensing sejam especialistas no domínio abordado, sendo que as solicitações dos
usuários podem ser especificadas de forma simples e rápida.
No restante deste capítulo descrevemos detalhadamente a arquitetura da plataforma CSVM, incluindo seus principais componentes e como eles interagem para prover
o comportamento de crowdsensing descrito pelo modelo em execução da plataforma. Na
primeira seção apresentamos a arquitetura geral da plataforma, descrevendo o fluxo de
processamento para registro de dispositivos e para consulta assim como os componentes
envolvidos. A seção seguinte descreve em detalhes os componentes e serviços da CSVM.
4.1
Visão Geral da Arquitetura
Conforme visto na Seção 2.1, a arquitetura de plataformas de crowdsensing móvel geralmente compreende dois tipos de componentes, um representando os dispositivos
de coleta e propagação de dados sensoreados e outro correspondente ao servidor de backend para a análise e processamento dos dados sensoreados [23].
Figura 4.1: Visão Geral da Plataforma CSVM
Seguindo esta abordagem, este trabalho propõe uma arquitetura estruturada na
forma de uma parte central (CSVMProvider), representada por um provedor de serviço
(componente backend), e uma parte distribuída (CSVM4Dev), localizada nos dispositivos
móveis. Desta forma, a plataforma CSVM, como apresentado na Figura 4.1, compreende
uma única instância da CSVMProvider e várias instâncias da CSVM4Dev. Cada instância
da CSVM4Dev é executada em um dispositivo diferente. A Figura 4.2 representa as
interações entre os principais componentes desta arquitetura.
O fluxo ilustrado na Figura 4.2 sintetiza as principais funcionalidades das etapas
de registro e consulta das aplicações de crowdsensing, que por sua vez serão detalhadas
na Subseção 4.4 e 4.5, respectivamente. Os componentes da arquitetura e as interações
entre eles são descritos a seguir:
4.1 Visão Geral da Arquitetura
58
Figura 4.2: Arquitetura Geral da Plataforma CSVM
CSVM4Dev. É um componente distribuído que é executado nos dispositivos físicos dos
usuários e provê o ambiente para interação do usuário com a plataforma. Ele compreende
um conjunto de serviços que permite ao usuário criar aplicações de crowdsensing e
participar de forma colaborativa de ambientes de crowdsensing por meio da abordagem
dirigida por modelos. Tendo o usuário especificado a necessidade de um serviço de
crowdsensing (registro ou consulta), este componente auxilia na criação do modelo e
se encarrega, de comunicar diretamente com o Provedor de Serviço enviando-o para
processamento (Figura 4.2, passo 2). A CSVM4Dev é dividida em quatro camadas que,
de modo geral, fornecem serviços que auxiliam na criação e modificação de modelos
em tempo de execução. Esses serviços compreendem, de forma resumida: uma interface
gráfica por meio da qual o usuário pode utilizar os recursos da plataforma; mecanismos de
processamento e interpretação de modelos; e acesso a recursos locais do dispositivo. As
camadas e os serviços da CSVM4Dev serão apresentados de forma detalhada na Seção
4.3. A Figura 4.2 ilustra também parte do ambiente de execução da CSVM4Dev, sendo:
• SO: refere-se ao sistema operacional do dispositivo e funciona como uma ponte
que conecta a CSVM4Dev aos sensores embarcados.
• Sensores: Representa a capacidade de sensoriamento do dispositivo, sendo composto por um conjunto de sensores nele embarcados.
CSVMProvider. Representa o núcleo da plataforma CSVM, sendo responsável
pelos principais serviços de crowdsensing. Ele consiste basicamente de uma máquina
de interpretação e execução de modelos para o domínio de crowdsensing. Em suma,
a CSVMProvider incorpora, em três camadas, conceitos da abordagem dirigida por
4.1 Visão Geral da Arquitetura
59
modelos em tempo de execução para processar e interpretar modelos (esquemas) criados
pelo usuário ou por uma aplicação. Cada camada apresenta responsabilidades específicas
com a finalidade de atender requisições de crowdsensing. Após processar o modelo de
uma consulta, este componente se encarrega de recrutar os dispositivos necessários para
atendê-la, bem como enviar uma requisição a cada um deles utilizando um serviço de
mensagens (Figura 4.2, passo 4 e 5).
Este componente é também responsável por manter um repositório de esquemas
(Figura 4.2, passo 3), onde as informações armazenadas representam o estado atual tanto
do ambiente de crowdsensing quanto das consultas em execução e seus respectivos dados
coletados. Qualquer alteração no ambiente ou em uma determinada consulta é refletida
automaticamente no repositório e no comportamento da CSVM.
Na Seção 2.2.3, foi apresentada uma arquitetura em camadas genérica para
construção de máquinas de execução de modelos de forma independente de domínio.
A arquitetura da CSVM é uma adaptação dessa arquitetura genérica, assim como a CVM
[17] e a MGridVM [3].
Contudo, ao propormos uma especialização dessa arquitetura genérica para o domínio de crowdsensing móvel, fez-se necessária a adoção de uma arquitetura distribuída
que atendesse as necessidades impostas pelos cenários deste domínio, tendo um componente central e outro distribuído nos dispositivos móveis.
(a) Arquitetura em camadas da
CSVMProvider.
(b) Arquitetura em camadas da
CSVM4Dev.
Figura 4.3: Arquitetura geral em camadas da CSVM, representado sua configuração da CSVMProvider (a) e da
CSVM4Dev (b).
4.2 Arquitetura da CSVMProvider
60
A Figura 4.3 ilustra as camadas que integram a CSVM, tanto na parte central,
definida pelo provedor de serviço (CSVMProvider), quanto na parte que executa nos
dispositivos móveis (CSVM4Dev).
De modo geral, cada camada apresenta um conjunto de funcionalidades específicas relacionadas ao domínio e mantém em níveis de abstração diferentes um modelo em
tempo de execução que reflete o ambiente e a aplicação em execução. Em seguida detalharemos os dois componentes da plataforma CSVM apresentando modelos que especificam
sua construção, considerando cada camada.
4.2
Arquitetura da CSVMProvider
A CSVMProvider é uma máquina de interpretação e execução de modelos para
o domínio de crowdsensing, cuja motivação são os desafios apresentados no início deste
capítulo. Ela processa uma linguagem de modelagem própria específica para o domínio
de crowdsensing, denominada CSML (descrita no Capítulo 3).
Um modelo construído pelo usuário em CSML (também conhecido por esquema) é interpretado pela CSVMProvider a fim de determinar as ações a serem executadas. Desta forma a CSVMProvider coordena todo o fluxo de execução de acordo com
as funcionalidades suportadas (registro ou consulta) e gerencia os recursos disponíveis.
Como descrito na seção 4.1, a CSVMProvider apresenta uma arquitetura em
quatro três (ilustrada na Figura 4.3(a)), as quais serão descritas a seguir.
4.2.1
Camada de Síntese
A camada de síntese (CrowdSensing Synthesis layer - CSS) é responsável por
interpretar os modelos (esquemas) recebidos em X-CSML e sintetizá-los resultando em
comandos a serem executados pelas camadas subjacentes. Esta camada é responsável
também por manter um modelo em tempo de execução que reflete o estado atual da
consulta de crowdsensing móvel.
A Figura 4.4 ilustra os principais elementos que compõem o modelo da camada
de síntese da CSVMProvider. Nesta figura é possível identificar um elemento principal
(SynthesisManager), que gerencia os demais elementos. Todas chamadas à camada de
síntese passam antes por este elemento e todos eventos provenientes desta camada são
sinalizados por ele.
O X-CSMLParser é o elemento responsável pela interpretação dos modelos
descritos em X-CSML (descrita na seção 4.1). Ele compreende dois outros componentes:
4.2 Arquitetura da CSVMProvider
61
Figura 4.4: Modelo da Camada de Síntese da CSVMProvider.
• CommandGenerator - é responsável por gerar comandos que serão executados
pelas camadas subjacentes. Esses comandos são gerados a partir da interpretação
do modelo realizada previamente pelo X-CSMLParser.
• DataSchemaGenerator - é o elemento responsável por gerar um esquema de dados
a partir do esquema de controle de uma consulta especificada pelo usuário.
O RepositoryManager é outro importante componente desta camada, responsável por manter o repositório de modelos da CSVMProvider atualizado. Para esta finalidade, ele conta com um conjunto predefinido de tipos de operações básicas utilizadas
em bancos de dados relacionais conhecidas como CRUD (acrônimo para Create, Read,
Update e Delete) e representadas no modelo pelo elemento OperationKind.
O elemento AdaptativeManager é responsável por gerenciar as mudanças no
m@rt (modelo em tempo de execução) mantido por esta camada. Essas mudanças são
iniciadas ou (1) pelo usuário, por meio da camada de interface da CSVM4Dev ao alterar
o modelo da consulta ou as configurações de um dispositivo, ou (2) por mudanças no
ambiente que são capturadas por meio de eventos gerados pela camada de broker (descrita
posteriormente nesta seção).
Finalmente, o componente ConstraintManager é responsável por gerenciar as
restrições que governam as funcionalidades desta camada. A versão atual da CSVMProvider se restringe a duas regras principais aplicadas à camada de síntese:
• Regra de Adaptação: define que as adaptações no modelo em tempo de execução
devem ser realizadas de acordo com a origem da mudança (conforme descrito
acima), podendo ser a partir do:
– Usuário - a adaptação deve ser realizada por meio do cálculo da diferença
entre um novo modelo gerado e o modelo mantido em tempo de execução.
4.2 Arquitetura da CSVMProvider
62
– Ambiente - a adaptação deve ser realizada de forma automática, adicionando
e/ou removendo componentes do modelo mantido em tempo de execução de
acordo com a (in)disponibilidade de recursos.
• Regra de Processamento de Consultas: determina que uma consulta especificada
pelo usuário só poderá ser processada caso o dispositivo requisitante já esteja
registrado na plataforma.
4.2.2
Camada de Middleware
A camada de middleware (CrowdSensing Middleware layer - CSM) é responsável pela seleção de dispositivos com base em informações extraídas do m@rt, notadamente informações sobre as capacidades dos dispositivos e sua localização. A CSM
comunica diretamente com as demais camadas, processando comandos gerados pela camada de síntese e gerando eventos para ela, assim como comandos para serem executados
na camada de broker.
Outra importante função da camada CSM está relacionada à aplicação de requisitos não-funcionais, mais especificamente privacidade e segurança. A Figura 4.5 representa
o modelo da camada de middleware e seus principais elementos. O MiddlewareManager é
o elemento central, responsável por gerenciar as principais funcionalidades desta camada
e pela comunicação com as demais camadas.
Figura 4.5: Modelo da Camada de Middleware da CSVMProvider.
O LogicalResourceManager é o elemento responsável pela seleção dos recursos
que serão utilizados para atender as consultas. Para isto, ele segue a política de recrutamento (descrita abaixo).
Os requisitos de privacidade e segurança são tratados pelos elementos PrivacyManager e SecurityManager respectivamente. Em relação à privacidade, na atual versão
é utilizado um método de ocultação da informação do proprietário do dispositivo quando
este é recrutado para sensoriamento, mantendo o sigilo dessa informação. A segurança,
4.2 Arquitetura da CSVMProvider
63
por sua vez, é aplicada somente ao acesso aos recursos do ambiente e são individualmente
definidas pelos usuários.
O componente ConstraintsManager, assim como o componente de mesmo nome
da camada de síntese, é responsável por definir regras que definem as funcionalidades da
camada de middleware. No entanto, este elemento apresenta uma única regra:
• Regra de Recrutamento: define que os dispositivos registrados (presentes no esquema de controle do ambiente) serão inicialmente recrutados com base em suas
capacidades de sensoriamento e em sua localização lógica, ambas definidas conforme especificação do usuário realizada por meio do esquema de controle da consulta.
4.2.3
Camada de Broker
A camada de broker (Broker para CrowdSensing layer - CSB) permite à CSVMProvider interagir com os dispositivos que oferecem capacidade de sensoriamento. Dentre
suas principais responsabilidades estão: abstrair a diversidade de dispositivos presentes
em ambientes de crowdsensing; manter o modelo em tempo de execução causalmente
conectado com a plataforma; selecionar os recursos (dispositivos e seus sensores) físicos
apropriados para enviar requisições solicitando acesso a seus sensores; e monitorar os
dispositivos registrados no ambiente.
A estrutura desta camada é mostrada na Figura 4.6, que representa os principais
elementos de seu modelo. O BrokerManager, assim como os gerentes das camadas
superiores, é responsável por coordenar e gerenciar os demais componentes da camada
de broker e representa a interface de comunicação com a camada de middleware.
O ResourceManager é um dos mais importantes elementos deste modelo, sendo
encarregado de gerenciar os recursos da plataforma. No nosso contexto, os recursos podem ser componentes de software e hardware que fornecem serviços de crowdsensing.
Para possibilitar a interação entre a plataforma e os dispositivos registrados, esta camada
provê interfaces (representadas pelo elemento Interface) que viabilizam a comunicação
entre a CSVMProvider e a CSVM4Dev: a DevelopInterface, que possibilita que aplicações de crowdsensing comuniquem com a plataforma CSVM e utilizem suas funcionalidades (registro e consulta) e recursos (dispositivos registrados no ambiente); e a CSInterface, responsável pela comunicação direta com os dispositivos heterogêneos que integram
o ambiente. A CSInterface é gerenciada pelo componente CSResourceManager, que controla as ações a serem realizadas nos dispositivos recrutados, como o envio de requisições,
o recebimento de notificações e a verificação de disponibilidade dos dispositivos.
Além de abstrair as diferenças entre os recursos existentes, a camada de broker
tem como responsabilidade ocultar das camadas superiores detalhes relacionados à dinâ-
4.2 Arquitetura da CSVMProvider
64
Figura 4.6: Modelo da Camada de Broker da CSVMProvider.
mica do ambiente, que envolve a disponibilidade ou não dos dispositivos registrados em
uma determinada localização. Em resposta a esta dinamicidade do ambiente, o elemento
AutonomicManager adiciona à plataforma a capacidade de se auto-gerenciar, como forma
de manter em tempo de execução a integridade das informações relacionadas aos dispositivos presentes na plataforma. O auto-gerenciamento envolve o constante monitoramento
dos recursos do ambiente e das solicitações dos usuários e a análise das mudanças, definindo a ação apropriada a ser tomada em resposta. Associado a este componente tem-se
o StateManager, que mantém durante a execução de uma aplicação de crowdsensing, o
estado atualizado dos dispositivos participantes, podendo ser: (1) habilitado, caso o dispositivo e sua capacidade atendam a consulta; (2) desabilitado, quando por intervenção
direta ou indireta do usuário o dispositivo deixa de atender os requisitos da consulta, ou
quando o dispositivo fica indisponível por fatores externos ao usuário, como ausência de
carga na bateria ou problemas com o acesso à Internet.
Este comportamento autonômico possibilita manter o modelo em tempo de
execução causalmente conectado com a plataforma, seja por mudanças no ambiente
que refletirão no modelo por meio de adaptações realizadas pela camada de broker,
ou por alterações no modelo do usuário que serão detectadas pela camada de broker,
interpretadas pela camada de síntese e que por sua vez refletirão no funcionamento da
plataforma.
A camada de broker também apresenta aspectos que definem suas funcionalidades e como elas serão executadas. Neste sentido, a camada de broker apresenta:
• Controle de Acesso: delimita, por meio do AccessControlManager o escopo de
acesso dos recursos externos definindo a priori duas restrições: (1) qualquer dis-
4.3 Arquitetura da CSVM4Dev
65
positivo móvel pode se registrar, desde que atenda aos requisitos mínimos como
presença de sensores embarcados; (2) para especificar uma consulta o dispositivo
deverá estar previamente registrado na plataforma.
• Controle Autonômico: descreve, por meio do AutonomicManager, o comportamento autonômico de acordo com as mudanças externas (seja do ambiente ou do
usuário) a fim de manter o modelo em tempo de execução causalmente conectado
(conforme descrito anteriormente). O AutonomicManager define que as mudanças
resultantes do monitoramento do ambiente refletem no funcionamento da plataforma por meio de eventos gerados pela camada de broker e tratados pela camada
de síntese.
• Seleção de Recurso: determina, por meio do ResourceManager como os dispositivos (físicos) devem ser selecionados. Para a atual versão da CSVMProvider, a
seleção de dispositivos é realizada de forma aleatória. Contudo, este trabalho apresenta como trabalho futuro a otimização no processo de seleção de recurso por meio
da injeção de inteligência na escolha dos dispositivos.
4.3
Arquitetura da CSVM4Dev
A CSVM4Dev é uma adaptação/configuração da CSVM para dispositivos móveis. Sua finalidade é integrar os sensores embarcados nesses dispositivos e possibilitar
que o usuário especifique consultas de crowdsensing a serem posteriormente tratadas pela
CSVMProvider. Ela apresenta características similares à CSVMProvider, como sua arquitetura em camadas (Figura 4.3(b)). Apesar de ser uma configuração da CSVM, ela possui
funcionalidades específicas, em função das limitações dos dispositivos móveis (em termos
de recursos de processamento, armazenamento e energia).
Além disso, a arquitetura da CSVM4Dev é multiplataforma e independente de
dispositivo móvel, ou seja, ela pode ser executada em qualquer dispositivo móvel independente de marca, modelo ou sistema operacional (embora neste trabalho apresentemos
apenas sua implementação para a plataforma Android). Esta característica, associada às
funcionalidades da camada de broker da CSVMProvider e da CSVM4Dev, possibilita que
dispositivos heterogêneos interajam entre si, tornando este cenário de crowdsensing ainda
mais complexo.
Em relação a sua arquitetura em camadas, a CSVM4Dev é subdividida em quatro
níveis, diferenciando-se da CSVMProvider por apresentar uma camada adicional que
possibilita a interação do usuário com a plataforma. As demais camadas apresentam
construções semelhantes às da CSVMProvider. A seguir apresentamos uma descrição
detalhada da arquitetura de cada camada da CSVM4Dev.
4.3 Arquitetura da CSVM4Dev
4.3.1
66
Camada de Aplicação
A camada de aplicação (Crowdsensing Application layer - CSApp) provê uma
interface externa para utilização da plataforma, a qual permite ao usuário especificar e
manter modelos de crowdsensing em CSML. Esses modelos representam as duas funcionalidades básicas para as quais a plataforma provê suporte: registro (de dispositivos e suas
capacidades) e consultas. A Figura 4.7 apresenta os principais componentes da camada
de aplicação e suas interfaces de comunicação. A camada de aplicação é dividida em
duas subcamadas: (1) subcamada referente às aplicações de crowdsensing propriamente
ditas; e (2) subcamada referente à API (CSVM API) para acesso às funcionalidades da
plataforma.
Figura 4.7: Camada de Aplicação da CSVM4Dev.
Os componentes Registro, Consulta e Aplicações, que integram a subcamada superior, representam aplicações padrão da plataforma e aplicações de terceiros construídas
sobre a CSVM API. Essas aplicações possibilitam a interação do usuário com a plataforma, por meio de uma interface gráfica (UI) que permite ao usuário solicitar o registro
de dispositivos e/ou especificar consultas.
A CSVM API fornece apoio às aplicações de crowdsensing (aplicações padrão
e aplicações desenvolvidas por terceiros) por meio de uma API para construção dos
esquemas (de controle e de dados) em X-CSML. Desta forma, aplicações de terceiros
podem especificar consultas com base no metamodelo de esquema de controle e de
dados proposto neste trabalho. Essa API reduz a complexidade no desenvolvimento
de aplicações de crowdsensing, de forma que os desenvolvedores se concentrem no
desenvolvimento das aplicações móveis, enquanto a API abstrai a parte de processamento
de modelos (esquema de controle e esquema de dados) e provimento de serviços de
crowdsensing.
Os principais componentes da CSApp estão descritos no modelo da camada,
apresentado na Figura 4.8. O AplicationManager é o elemento responsável por coordenar
o envio e recebimento de modelos entre a camada de aplicação e a camada de síntese,
além de gerenciar outros três elementos: X-CSMLGenerator, ProgrammingInterface e
4.3 Arquitetura da CSVM4Dev
67
UserInterface. O X-CSMLGenerator se encarrega de criar modelos em X-CSML a partir
das necessidades do usuário, tanto para o registro de dispositivos, quanto para a especificação de consultas, a serem enviados para processamento central pela CSVMProvider.
Desta forma, este elemento deve incorporar o conjunto de regras especificadas no metamodelo da CSML para construção dos modelos propriamente ditos. A ProgrammingInterface possibilita a troca de mensagens entre uma aplicação de crowdsensing desenvolvida
por terceiros e a CSVM4Dev a fim de permitir que desenvolvedores de aplicações de
crowdsensing utilizem as funcionalidades da CSVM por meio da CSVM API.
A interface do usuário, representada no modelo pelo elemento UserInterface, descreve três interfaces que refletem as principais funcionalidades da plataforma:
QueryInterface, RegistrationInterface e ConfigInterface. Além disso, essa camada mantém um conjunto predefinido de restrições (ConstraintType) e ações (ActionType) que
auxiliam o usuário na execução de tarefas.
A interface QueryInterface representa uma interface gráfica para especificação
de consultas de crowdsensing. O ambiente gráfico consiste de um formulário (QueryFormEditor) que possibilita que os usuários expressem suas necessidades de sensoriamento
por meio de um conjunto de ações definidas na enumeração ActionType. Desta forma, o
usuário pode criar uma nova consulta ou visualizar, editar e deletar uma consulta previamente especificada.
Figura 4.8: Modelo da Camada de Aplicação da CSVM4Dev.
A interface RegistrationInterface consiste em uma interface gráfica por meio da
qual o usuário registra um dispositivo e informa a configuração com a qual ele deve ser
registrado. A configuração envolve informações do dispositivo (marca, modelo e proprietário) e o conjunto de sensores para os quais o usuário autoriza o compartilhamento.
4.3 Arquitetura da CSVM4Dev
68
Por meio das operações definidas na enumeração ActionType, essa interface permite ao
usuário criar, visualizar, editar ou deletar uma solicitação de registro, apresentando maior
flexibilidade para o usuário na manipulação dos modelos. A interação do usuário com
a interface é facilitada pelo elemento RegistrationFormEditor, que define um formulário
onde o usuário configura o dispositivo para registro e seleciona os sensores que deseja
compartilhar.
No contexto deste projeto a plataforma deve permitir que o usuário especifique
de forma explícita requisitos de segurança e privacidade a serem aplicados em seu dispositivo particularmente. Neste sentido, o elemento ConfigInterface descreve um ambiente
gráfico que permite que o usuário defina um conjunto de restrições de privacidade e segurança. Essas restrições são representadas no modelo pelo elemento Constraints. Desta
forma, o usuário pode criar/consultar/atualizar/deletar restrições por meio de categorias
de restrições predefinas:
• Restrições de Privacidade: determina como sua identidade será tratada, tanto na
geração de consultas quanto na participação colaborativa em outras aplicações. Por
exemplo, informar a localização mas ocultar a identificação.
• Restrições de Segurança: se restringe ao controle de acesso que define qual a forma
de acesso ao dispositivo, podendo ser divida em três: (1) acesso liberado, que
permite acesso a todas informações necessárias do dispositivo de forma automática;
(2) acesso restrito, que permite acesso automático a parte das informações e, quando
necessário, solicita acesso às demais partes; e (3) acesso bloqueado, que não permite
nenhum tipo de acesso ao dispositivo.
4.3.2
Camada de Síntese
A camada de síntese (CrowdSensing Synthesis layer - CSS) é a essência da
CSVM4Dev e é responsável por validar e converter os modelos criados na CSApp em
modelos textuais baseadas em XML (X-CSML) antes de enviá-los à CSVMProvider. De
forma geral, em relação às funcionalidades, a CSS apresenta algumas similaridades com
sua camada equivalente na CSVMProvider, sendo que seus principais elementos estão
representados na Figura 4.9. Ela tem como componente central o SynthesisManager, que
realiza tanto a comunicação com as camadas de interface e middleware quanto a gerência
dos componentes internos.
O SchemaParser é o elemento responsável pela interpretação de modelos, tanto
do esquema de controle gerado na camada de aplicação, quanto do esquema de dados enviado pela CSVMProvider, quando esta processa uma consulta. As informações presentes
nos modelos são mantidas em um banco de dados local através do elemento StorageManager, que por sua vez contém um conjunto predefinido de ações. Uma ação representa
4.3 Arquitetura da CSVM4Dev
69
Figura 4.9: Modelo da Camada de Síntese da CSVM4Dev.
uma operação que pode ser executada sobre o banco de dados do dispositivo móvel e é
definida pelo elemento ActionType, que define os seguintes tipos: create, read, update e
delete. Em suma, o StorageManager gerencia diretamente a base de dados, mantendo os
modelos em tempo de execução armazenados e em conformidade com o ambiente e as
consultas de crowdsensing.
O componente TaskManager é responsável por instanciar tarefas a partir de
um esquema de dados proveniente de uma consulta. Essas tarefas são executados pela
camada CSS a fim de coordenar o processamento dos esquemas de dados na CSVM4Dev.
O TaskManager contém o QueryProcessor, que auxilia na execução dessas tarefas,
englobando a geração de comandos para as camadas inferiores para validar os requisitos
de segurança (camada de middleware) e acessar os recursos do dispositivo que satisfaçam
a consulta processada (broker).
4.3.3
Camada de Middleware
A camada de middleware (CrowdSensing Middleware layer - CSM) da
CSVM4Dev se restringe ao emprego de requisitos não-funcionais. Uma vez que os requisitos tenham sido determinados pelo usuário, esta camada se encarrega de aplicá-los
e validá-los durante o processamento dos modelos. Esses requisitos compreendem dois
aspectos: segurança e privacidade.
Para especificar esses requisitos o usuário conta com a interface gráfica fornecida
pela camada CSApp, que permite alterá-los a qualquer momento. Esta camada será
acionada por meio de eventos enviados pela camada de broker ao receber eventos da
4.3 Arquitetura da CSVM4Dev
70
Figura 4.10: Modelo da Camada de Middleware da CSVM4Dev.
CSVMProvider e por comandos gerados pela camada de síntese. Ao receber eventos
enviados pela camada de broker, a camada de middleware valida o conteúdo recebido
segundo as restrições de segurança e privacidade definidas e, caso o conteúdo esteja de
acordo com essas restrições, ela repassa os eventos à camada de síntese.
Ao receber comandos da camada de síntese, a CSM é responsável por aplicar
definitivamente as restrições de segurança e privacidade repassando comandos à camada
de broker para envio do modelo à CSVMProvider. Essas restrições estão definidos nos
elementos SecurityManager e PrivacyManager, respectivamente.
4.3.4
Camada de Broker
A camada de broker (CrowdSensing Broker layer - CSB) é responsável pelo gerenciamento dos recursos dos dispositivos móveis e pela comunicação com a CSVMProvider. Os recursos associados à CSVM4Dev podem ser classificados em duas categorias
distintas de acordo com sua forma de acesso: internos, quando associados ao conjunto
de sensores embarcados no dispositivo e compartilhados de acordo com a autorização do
usuário; e externos, quando se referem a serviços de crowdsensing (por meio de consultas
especificadas pelo usuário) mantidos pela CSVMProvider.
Assim como sua equivalente na CSVMProvider, a camada de broker possui um
conjunto de elementos que descrevem tanto suas funcionalidades, como comunicação e
acesso a recursos internos, quanto suas restrições. O modelo da camada de broker que
compreende esses elementos é representado pelo diagrama de classe da Figura 4.11.
O elemento central da camada, denominado BrokerManager é responsável por
coordenar e gerenciar os demais componentes, mantendo a integração entre eles. O
BrokerManager é composto por alguns elementos que definem os comandos e requisições
recebidos pela camada de broker. Esses elementos são: o Handler (manipulador) e o
ConstraintManager (que gerencia regras para seleção de recursos).
O Handler captura as requisições enviadas pela CSVMProvider que chegam à
camada CSB e indica a ação que deve ser tomada para cada uma. Ele identifica os tipos
4.3 Arquitetura da CSVM4Dev
71
Figura 4.11: Modelo da Camada de Broker CSVM4Dev.
de sensores exigidos pela CSVMProvider por meio do esquema de dados e seleciona os
recursos presentes no dispositivo que atendem à requisição. O processo de escolha dos
recursos envolve ações que são aplicadas aos recursos selecionados em resposta a uma
requisição. Essas ações possuem restrições associadas que definem, por meio do elemento
ConstraintManager), a forma de acesso aos recursos, por exemplo, o usuário permite
acesso aos recursos do dispositivo somente quando a capacidade da bateria estiver acima
de vinte por cento.
Os dois tipos de recursos gerenciados pela camada de broker são descritos por
meio de um gerenciador de recursos, definido pelo ResourceManager. O gerenciador de
recursos define a interface dos recursos gerenciados e como estes podem ser acessados.
Essa interface é descrita através do elemento Interface. Conforme apresentado no diagrama de classes da Figura 4.11, a Interface compreende o subelemento CSInterface,
que representa uma interface responsável pela comunicação direta com a CSVMProvider.
Desta forma, ela possibilita que a CSVMProvider acesse os recursos de sensoriamento
do dispositivo e possibilita que a CSVM4Dev acesse os recursos do ambiente (dispositivos registrados) mantido pela CSVMProvider. Para a efetivação desta comunicação, a
CSVMProvider implementa na camada de broker uma interface equivalente.
O gerenciamento dos recursos externos é descrito pelo CSResourceManager,
que define os padrões de comunicação utilizados para comunicação com a CSVMProvider, de modo que a CSInterface disponibiliza o acesso aos serviços de comunicação
da CSVM4Dev. Em contrapartida, o DeviceResourceManager descreve o acesso e gerenciamento dos recursos que serão efetivamente utilizados para realizar os serviços de
crowdsensing especificados nos modelos. Para esta finalidade, ele define um conjunto de
serviços que abstrai da camada superior a diversidade dos sensores embarcados no dispositivo móvel.
O conjunto de elementos e serviços fornecidos pela camada de broker devem
4.4 Processo de Registro de Dispositivos
72
fornecer suporte as duas principais funções que a CSVM disponibiliza para os usuários:
o registro de dispositivos e a especificação de consultas. Estas funções serão descritas nas
seções seguintes.
4.4
Processo de Registro de Dispositivos
Para o provimento de serviços de crowdsensing móvel a plataforma CSVM
dispõe de uma infraestrutura de dispositivos físicos que se registram e informam suas
capacidades de sensoriamento na plataforma. Cada dispositivo registrado contribui para
aumentar a cobertura de regiões monitoradas e/ou aumentar a precisão do sensoriamento
em uma determinada região. O registro de um dispositivo é condição necessária para
que suas capacidades de sensoriamento fiquem disponíveis para uso pela plataforma. O
incentivo para realizar o registro se dá pelo fato de que, uma vez registrado, o dispositivo
pode fazer uso dos serviços da plataforma.
A composição de todos os dispositivos móveis registrados resulta na construção
de um ambiente “virtual” de crowdsensing móvel, que abstrai infraestruturas físicas
destes dispositivos e, consequentemente de seus sensores embarcados. A diversidade
de dispositivos e, consequentemente de sensores a eles associados, é o que determina
a capacidade de sensoriamento e cobertura da plataforma.
A etapa de registro é primordial para o funcionamento da plataforma e antecede
suas demais funcionalidades. A Figura 4.12 ilustra o processo de registro de um dispositivo móvel por meio de uma visão detalhada da arquitetura geral apresentada na Figura
4.2.
Figura 4.12: Arquitetura de um registro.
4.4 Processo de Registro de Dispositivos
73
O processo de registro pode ser dividido em duas etapas distintas: (1) o registro
do dispositivo no serviço de comunicação, e (2) o registro do dispositivo na plataforma
propriamente dita. Entretanto, antes que isto seja possível, é necessário que o usuário de
forma participativa, instale o módulo da CSVM para dispositivos móveis (CSVM4Dev)
e especifique, por meio da camada de aplicação, os recursos (sensores) que serão compartilhados. Posteriormente, o modelo (esquema de controle) criado pelo usuário, representando as informações que fazem parte do registro do dispositivo, é convertido pela
CSVM4Dev em X-CSML e preparado para envio à CSVMProvider, aplicando os requisitos de segurança e privacidade definidos pelo usuário. Concluída esta parte inicial, o
dispositivo se registra no serviço de comunicação para habilitá-lo a receber consultas geradas pela CSVMProvider (ilustrado na Figura 4.12 passos 1 e 2). Em seguida, a CSVMProvider procede com o registro do dispositivo na plataforma.
Registro na plataforma
Após o usuário especificar as informações do dispositivo (proprietário, marca
e modelo) bem como os sensores que deseja compartilhar, a camada de broker da
CSVM4Dev, procede com o envio da requisição de registro na plataforma (Figura 4.12
passo 3). Este envio ocorre na forma de modelo, mais especificamente como um esquema
de controle por meio do qual o dispositivo publica suas capacidades.
A camada de broker da CSVMProvider recebe a requisição e, em seguida, gera
eventos para as camadas superiores prosseguirem com o processamento do modelo. Neste
momento, a camada de middleware se encarrega de validar os aspectos de segurança e
privacidade, conforme descrito na Seção 4.1. A interpretação do modelo (esquema de
controle) ocorre efetivamente na camada de síntese.
Para o serviço de registro, a interpretação do modelo envolve identificar se as
informações estão completas e, posteriormente executar um conjunto de operações diretamente nos esquemas mantidos pela CSVMProvider (Figura 4.12 passo 4). A primeira
operação realizada pela camada de síntese compreende uma consulta ao esquema de controle do ambiente mantido no repositório para verificar a unicidade do dispositivo; se
este já estiver registrado ela apenas atualiza o registro existente; caso contrário, ela cria
um novo registro com os dados contidos no modelo. Desta forma, o dispositivo passa a
integrar o esquema do controle do ambiente.
Concluído o registro do dispositivo no repositório e, consequentemente no
ambiente de crowdsensing mantido pela plataforma, a camada de síntese gera comandos
às camadas subjacentes para notificar o dispositivo da conclusão do registro (Figura
4.12 passo 6). Uma vez registrado, o dispositivo está habilitado a especificar consultas
utilizando a plataforma e participar de forma colaborativa na construção de respostas a
4.5 Processo de Consulta
74
consultas feitas por usuários de outros dispositivos registrados. O processo de consulta é
descrito na Seção 4.5.
4.5
Processo de Consulta
O principal serviço em se tratando do domínio de crowdsensing é a especificação
de consultas. Uma consulta em crowdsensing se refere ao conjunto de sensores e suas
especificações (tais como tipo, localização e quantidade) necessárias para satisfazer as
necessidades de aplicações de crowdsensing móvel.
A plataforma CSVM aplica duas restrições em relação à especificação de consultas: (1) uma consulta só pode ser definida por dispositivos registrados na plataforma; (2)
a consulta só será processada se houver recursos disponíveis no ambiente que satisfaçam
as condições especificadas pelo usuário.
Do mesmo modo que no registro, a arquitetura do processamento de consultas,
retratada na Figura 4.13, representa uma fração da arquitetura geral (apresentada na Seção
4.1) enfatizando as etapas compreendidas no processo de especificação e execução de
uma consulta de crowdsensing. Estas etapas referem-se à subscrição de consultas e à
notificação dos dados requisitados.
Figura 4.13: Arquitetura de uma consulta.
De modo geral, o processo de consulta se resume em: modelagem da consulta
realizada pelo usuário ou aplicação; subscrição do modelo resultante (esquema de controle da consulta) junto ao provedor de serviço (Figura 4.13, passo 1); e recrutamento dos
dispositivos (Figura 4.13, passo 2, 3 e 4). Este processo será detalhado em seguida, tendo
como referência as etapas de subscrição e notificação.
4.5 Processo de Consulta
4.5.1
75
Subscrição
A subscrição refere-se às etapas iniciais do processamento de consultas. Contudo, antes de qualquer processamento propriamente dito as consultas devem ser especificadas pelo usuário. Visando facilitar este processo, a CSV4Dev disponibiliza, por meio
da camada de broker, uma interface gráfica que auxilia na modelagem de consultas. A interface gráfica, construída de acordo com construções da CSML, possibilita que o usuário
exponha seu interesse em sensoriamento remoto de uma determinada localização, podendo ainda especificar mais de um tipo de sensor por consulta e combiná-los a fim de
derivar informações compostas.
Da mesma forma que no registro de dispositivos, o modelo descrito por meio
da interface gráfica é convertido em X-CSML na CSVM4Dev. Em seguida, são aplicadas
as restrições de segurança e privacidade previamente definidas. Este modelo representa
o esquema de controle da consulta (QCS - Query Control Schema, definido na Seção
3.2). A camada de síntese da CSVM4Dev se encarrega também de manter este esquema
de controle em uma base de dados local, pois, após tê-lo especificado, o usuário pode
alterá-lo, desde que a respectiva consulta ainda esteja em execução.
O envio de consulta à CSVMProvider é realizada pela camada de broker da
CSVM4Dev após completados os passos descritos acima. Isto é feito por meio do envio
do esquema de controle da consulta por meio sua interface de comunicação (CSInterface).
Isto corresponde ao passo 1 da Figura 4.13. Por esta mesma interface a camada de
broker da CSVMProvider recebe a subscrição e gera eventos para as camadas superiores
interpretarem e processarem a consulta, conforme descrito a seguir.
A camada de middleware da CSVMProvider, ao receber os eventos da camada
de broker verifica se o esquema de controle da consulta está condizente com as restrições
de segurança e privacidade e o repassa à camada de síntese. Uma das principais funcionalidades da CSVMProvider é realizada por esta última camada e refere-se à interpretação
do esquema de controle da consulta e à subsequente geração de comandos para seleção
dos dispositivos.
A partir da interpretação e análise do modelo, uma sequência de transações é
realizada sobre a base de dados (4.13 passo 2), que mantém o repositório de esquemas da
CSVMProvider. A primeira delas é a persistência das informações presentes no esquema
de controle da consulta, realizada pela camada de síntese da CSVMProvider. Em seguida,
a camada de síntese gera comandos à camada imediatamente inferior repassando as
seguintes informações extraídas do QCS: os tipos, a quantidade e a localização associada
a cada tipo de sensor.
Neste momento ocorre a segunda transação com o repositório, realizada pela
camada de middleware da CSVMProvider a fim de selecionar recursos (dispositivos)
lógicos de acordo com o comando recebido da camada de síntese. Por exemplo, após
4.5 Processo de Consulta
76
a camada de síntese gerar um comando (getLogicalDevice) passando como parâmetro
o tipo, localização lógica e a quantidade de um determinado sensor (por exemplo, dez
sensores de temperatura localizados no prédio do Instituto de Informática da UFG)
conforme especificado na consulta, a camada de middleware se encarrega de obter os
dispositivos através de um comando SQL aplicado ao repositório. Esta seleção segue a
regra de recrutamento descrita na seção 4.1.
Após obtido um conjunto de dispositivos lógicos recrutados, a camada de middleware realiza uma chamada à camada de broker para escolha dos dispositivos físicos
que compreenderão a consulta. Após escolhidos os dispositivos, a camada de middleware
gera um evento destinado à camada de síntese para geração de uma instância do esquema
de controle da consulta e sua representação em X-CSML. Esta instância representa o
modelo em tempo de execução e compreende os dispositivos selecionados, os tipos de
sensores associados a cada um deles, a localização e a quantidade associada aos tipos de
sensores, as operações que serão aplicadas às medições e o tipo de notificação (conforme
descrito na seção 3.2 e exemplificado na seção 3.2.3.
A representação do modelo em tempo de execução em X-CSML facilita a compreensão e é interpretada pela CSVMProvider em dois momentos distintos: na subscrição/requisição de interesse em dados de sensoriamento dos dispositivos; na associação de
notificações enviadas pela CSVM4Dev após obter o dado sensoriado. Portanto, a camada
de síntese interpreta o modelo em X-CSML e instancia a partir dele um esquema de dados.
Conforme descrito no Capítulo 3, o esquema de dados representa um formulário (form)
vazio a ser preenchido por cada dispositivo recrutado, contendo informações referentes
aos sensores que deverão ser medidos.
A camada de síntese gera então chamadas à camada de broker para o envio
das requisições aos dispositivos. Esta, por sua vez, utiliza a interface CSInterface para
comunicar com o serviço de comunicação gerando várias solicitações (de acordo com o
número de dispositivos recrutados) contendo o ID de registro de cada dispositivo para o
envio do esquema de dados a cada um deles (Figura 4.13 passo 3).
A etapa de subscrição se encerra com o serviço de comunicação que processa a
solicitação do provedor de serviço e envia a requisição aos dispositivos (4.13 passo 4).
Cada dispositivo processa a requisição recebida e, a partir dos dados sensoreados, envia
notificações ao provedor de serviço. Essa etapa é descrita a seguir.
4.5.2
Notificação
De maneira oposta à subscrição, a notificação refere-se à etapa final do processamento da consulta. Ela tem início com o recebimento de requisições de sensores a serem monitorados pelos dispositivos recrutados em uma consulta. A camada de broker da
4.5 Processo de Consulta
77
CSVM4Dev é responsável por esta tarefa e, em seguida, encaminha o esquema de dados
recebido na requisição para interpretação e processamento por meio de eventos à camada
superior.
Novamente a camada de middleware da CSVM4Dev se encarrega de validar
as regras de privacidade e segurança. Feito isso, ela gera eventos para a camada de
síntese, que interpreta o modelo recebido e extrai as seguintes informações: qual ou quais
sensores estão sendo solicitados e quando devem ser amostrados. Uma vez identificadas
essas informações, o esquema de dados, assim como os demais modelos, é persistido em
uma base local para posterior recuperação caso haja qualquer modificação no interesse de
sensoriamento da aplicação.
A camada de síntese gera então comandos solicitando acesso aos recursos
locais do dispositivo de acordo com os tipos de sensores especificados no esquema
de dados. A camada de middleware intercepta o comando e verifica se o recurso está
disponível conforme predefinido na política de acesso e na configuração do dispositivo
definida no momento em que ele foi registrado. Finalizada esta verificação, o comando
é repassado à camada de broker, que solicita ao sistema operacional acesso ao recurso
especificado. Uma vez que o acesso tenha sido liberado, ela aciona o sensor para capturar
a informação desejada. Caso o tipo de notificação especifique que o sensoriamento deverá
ser realizado periodicamente, a camada de broker ficará responsável por acioná-lo sempre
que necessário.
Após obtidas as informações sensoreadas, a camada de broker gera eventos
à camada superior informando que a tarefa está concluída. A camada de middleware
simplesmente repassa o evento à camada de síntese, que por sua vez cria uma instância do
esquema de dados recebido. Esta instância representa o form preenchido com informações
monitoradas pelos sensores requisitados. Nesta instância (conforme definido no Capítulo
3) há informações como: o tipo de sensor, precisão com que o dado foi coletado, data e
hora da coleta, o valor coletado propriamente dito, o tipo de dado e a unidade de medida.
Concluído o processamento da requisição, a CSVM4Dev, através da camada de
broker, notifica o provedor de serviço (Figura 4.13 passo 5) enviando-lhe o esquema
de dados preenchido (ou seja, a instância do esquema de dados). A CSVMProvider
recebe a instância do esquema de dados por meio da camada de broker e gera eventos
para a camada superior informando que uma nova instância do esquema de dados foi
recebida. A camada de middleware verifica os aspectos relacionados a segurança e
privacidade e repassa o evento à camada superior. Ao receber o evento, a camada de
síntese interpreta a instância do esquema de dados recebida a fim de identificar a instância
do esquema de controle da consulta correspondente. Uma vez identificado a instância
esquema de controle da consulta, ela interpreta pela segunda vez este modelo em tempo
de execução a fim de construir a resposta para o dispositivo solicitante por meio da
4.6 Considerações Finais
78
realização de operações (especificadas no esquema de controle da consulta) sobre os
dados recebidos através da instância do esquema de dados. Esta interpretação possibilita
que a CSVMProvider identifique também se a consulta foi satisfeita por completo ou se
ainda há pendências.
Na medida em que os dispositivos recrutados processam as requisições e geram
as notificações, a CSVMProvider se encarrega de aplicar as operações relacionadas a cada
subconjunto monitorado, como por exemplo, calcular a média. No fim, ela realiza uma
agregação de toda informação obtida, compondo uma instância do esquema de dados geral
para então enviá-lo ao dispositivo solicitante. Antes porém, é importante destacar que
tanto o esquema de dados gerado pela CSVMProvider quanto as instâncias do esquema
de dados recebidas são armazenados (Figura 4.13 passo 6). Ao fim deste processamento a
CSVMProvider envia uma mensagem contendo a instância do esquema de dados (resposta
à consulta) para o dispositivo que gerou a consulta (Figura 4.13 passos 7 e 8).
Tendo recebido a resposta da consulta, a camada de broker da CSVM4Dev gera
eventos à camada superior para verificação e validação do modelo recebido. A camada
de síntese, ao receber o evento, interpreta a instância do esquema de dados recebida e a
associa com o esquema de controle da consulta correspondente, pois pode haver mais de
uma consulta em execução vinculada àquele dispositivo. Ao fim deste processamento ela
repassa o modelo à camada de aplicação para apresentação do resultado ao usuário.
4.6
Considerações Finais
Neste capítulo apresentamos a arquitetura geral da CSVM, incluindo seus principais componentes e como eles interagem para prover serviços de crowdsensing. Em
seguida detalhamos os dois principais componentes dessa arquitetura: componente móvel
(CSVM4Dev) e componente servidor (CSVMProvider). Para os dois principais componentes foram apresentados sua arquitetura em camadas e para cada camada foi apresentado o modelo que a descreve.
Mostramos também neste capítulo detalhes de como o processo de registro de
dispositivos e o processo de consulta ocorre e como os componentes interagem em cada
etapa. No Capítulo 5, apresentamos a implementação da CSVM a fim de prover suporte
para as funcionalidades de crowdsensing apresentadas no Capítulo 3.
CAPÍTULO 5
Implementação da CSVM
Com o objetivo de demonstrar a viabilidade da arquitetura proposta, foi desenvolvido um protótipo que implementa as funcionalidades da plataforma para provimento
de serviços de crowdsensing, através principalmente da criação e manutenção de modelos
em tempo de execução. O protótipo abrange as duas partes da arquitetura da plataforma
CSVM: uma parte desenvolvida para os dispositivos móveis, CSVM4Dev, e outra parte
desenvolvido como um provedor de serviço na nuvem, CSVMProvider.
A Seção 5.1 apresenta uma visão geral do protótipo desenvolvido, seguido pela
Seção 5.2, que descreve as principais técnicas e tecnologias empregadas no desenvolvimento da plataforma. A implementação da CSVMProvider e CSV4Dev é descrita nas
Seções 5.3 e 5.4, respectivamente. Por fim, apresentamos detalhes de como os processos
de registro de dispositivos (Seção 5.5) e processamento de consultas (Seção 5.6) foram
implementados,
5.1
Visão Geral
De modo geral, no protótipo foram implementadas as funcionalidades básicas
de crowdsensing alinhadas à abordagem dirigida por modelos: registrar os dispositivos,
especificar consultas, selecionar dispositivos voluntários, manter modelos em tempo de
execução, processar requisições e obter dados sensoriados.
Para o desenvolvimento do protótipo foi utilizado a IDE Eclipse para aplicações
Java EE com plugin ADT (Android Development Tools) e o Android SDK (Software
Development Kit) para o desenvolvimento de aplicações Android. O protótipo e seu
código fonte pode ser encontrado no repositório do projeto 1 .
Nessa implementação, optamos por priorizar os aspectos funcionais e estruturais
da plataforma, para só então considerar aspectos não-funcionais como segurança e privacidade. É importante ressaltar que, a parte implementada é suficientemente completa para
demonstrar e validar a abordagem.
1 https://subversion.assembla.com/svn/crowdsensing/
5.2 Tecnologias Utilizadas
80
Além das funcionalidades implementadas, o protótipo envolve três operações
aplicadas a modelos: criação, associada à geração do modelo; interpretação, associada à
análise do modelo a fim de definir comandos e ações a serem executadas pela plataforma;
e transformação, associada a alteração do modelo durante à execução, que reflete as
mudanças tanto no ambiente quanto em uma consulta.
As funcionalidades apresentadas nessa seção refletem a arquitetura proposta no
Capítulo 4, e para implementá-las foi utilizado um conjunto de técnicas e tecnologias que
serão apresentadas na Seção seguinte.
5.2
Tecnologias Utilizadas
Esta seção apresenta as principais técnicas e tecnologias utilizadas na implementação da CSVM. Cada tecnologia foi utilizada para um propósito específico.
O padrão Model-View-Controller (MVC) foi utilizado para representar a estrutura em camadas da CSVM e os fatores que levaram à essa escolha foram: facilitar a
estruturação da plataforma em diferentes componentes; contribuir com a qualidade da
implementação da plataforma a longo prazo; reduzir o tempo de desenvolvimento, teste e
manutenção da plataforma; e proporcionar a reutilização da lógica implementada (obtido
graças ao desacoplamento dos componentes), tanto para evolução da plataforma, quanto
para aplicá-la em projetos semelhantes. Os detalhes da implementação deste padrão é
apresentado na seção 5.2.1.
Em relação à comunicação, para realizar a interação entre as partes envolvidas,
optou-se por utilizar diferentes protocolos de acordo com o sentido da comunicação.
Desta forma, a comunicação estabelecida no sentido do dispositivo para o provedor de
serviço (Device-to-Provider, D2P) emprega o formato padrão de serviço web baseado no
protocolo HTTP (HyperText Transfer Protocol - Protocolo de Transferência de Hipertexto) e troca de dados segundo JSON (JavaScript Object Notation - Notação de Objetos
JavaScript) que são implementados na plataforma através de serviços RESTFul. Por outro lado, a comunicação com origem no provedor de serviço (Provider-to-Device, P2D)
utiliza um protocolo de troca de mensagens com base no serviço GCM (Google Cloud
Messaging) da Google.
Optamos por esta abordagem híbrida por contemplar o modelo arquitetural
proposto, onde parte da comunicação se origina no provedor de serviço e parte no
dispositivo móvel. Ambos protocolos estão presentes na camada de broker, responsável
pela comunicação entre os componentes da plataforma e serão detalhados nas seções 5.2.2
e 5.2.3.
5.2 Tecnologias Utilizadas
5.2.1
81
Model-View-Controller
A arquitetura em camadas adotada na CSVM foi implementada seguindo o padrão Model-View-Controller (MVC). MVC é um padrão arquitetural de software que propõe uma separação entre a lógica de negócio e a apresentação da informação/funcionalidades ao usuário usando um mediador [16]. A premissa principal desse padrão é baseada
na modularidade e abrange três aspectos diferentes: o modelo (model), que consiste na
lógica (regras de negócio, implementada na forma de funções) e dados da aplicação; a
visão (view), que consiste na representação dos dados e funcionalidades de forma gráfica;
e o controlador (controller), que faz a mediação e acessa as funcionalidades da aplicação.
Para representar as camadas da plataforma de acordo com o padrão MVC, fezse necessária a associação dessas camadas com os componentes do MVC, levando em
consideração as funcionalidades de cada uma. A Figura 5.1 ilustra a arquitetura resultante
dessa associação e as principais interações entre os elementos.
Figura 5.1: Mapeamento da arquitetura em camadas da plataforma de acordo com o padrão MVC.
O componente View pertence exclusivamente à CSVM4Dev e compreende a camada de aplicação, possibilitando por meio dela a interação do usuário com a plataforma
(1). Desta forma, seus principais serviços são apresentados por meio de um conjunto de
elementos gráficos que auxiliam na especificação de serviços de crowdsensing. A CSVMProvider não apresenta este componente por não possuir interação direta com o usuário.
De acordo com a abordagem proposta o usuário pode registrar o dispositivo e/ou
especificar uma consulta. Essas ações influenciam diretamente no gerenciamento de modelos em tempo de execução que são mantidos pela plataforma. Desta forma, essas ações
compreendem parte das regras de negócio da plataforma e estão implementadas na camada de síntese da CSVM4Dev, que é implementada pelo componente Model. Assim,
este componente interage de forma direta (representada no diagrama pelas setas contínuas) com a View, tanto para especificar as necessidades do usuário quanto para notificar
5.2 Tecnologias Utilizadas
82
as respostas às solicitações realizadas (2). Esse componente também é responsável pelas
interações com a base de dados.
Na CSVM4Dev o componente Controller engloba as camadas de middleware
e broker, que têm como principal responsabilidade o gerenciamento de requisitos nãofuncionais (segurança e privacidade) e recursos internos (sensores) e externos (conexão
com o ambiente de crowdsensing da plataforma) respectivamente. Sua interação com a
View ocorre de forma indireta (representada no diagrama pelas setas tracejadas) por meio
do processamento e resposta a eventos específicos disparados por determinadas ações
do usuário (3). Essas ações se restringe a apresentação dos recursos para os quais o
dispositivo provê suporte para que eles possam ser selecionados no momento do registro.
Outra interação presente neste diagrama proposto, relacionada à CSVM4Dev,
compreende os componentes Model e Controller (4), onde uma vez interpretado o modelo
na camada de síntese, os comandos são gerados e repassados de forma direta à camada de
middleware e, consequentemente, ao broker para executas as ações exigidas pela camada
superior. De modo geral, as alterações serão refletidas nos modelos, seja por ações internas
(realizada pelo usuário) ou por eventos disparados pela CSVMProvider.
A CSVMProvider é estruturada apenas por dois componentes MVC (Model e
Controller) que implementam suas três camadas (Síntese, Middleware e Broker). O Controller possibilita, por meio do broker, que a CSVMProvider gerencie os dispositivos
móveis que estão registrados na plataforma e controle a comunicação com eles (5). Desta
forma, o componente Controller, além de gerenciar as conexões com os dispositivos, também controla a aplicação de um conjunto de restrições, gerando eventos ao componente
Model (mais especificamente à camada de síntese), e processando chamadas advindas
deste componente (6). Assim sendo, este componente controla o funcionamento da plataforma, por meio da interação direta com os dispositivos móveis e coordenação das ações
a serem realizadas pela CSVMProvider.
O Model por sua vez, implementa o conjunto de regras de negócio de acordo
com a abordagem dirigida por modelos, tendo como principais atribuições a interpretação
de modelos em tempo de execução e o gerenciamento do repositório de modelos.
5.2.2
RESTFul
Os serviços RESTful implementados seguem os princípios de REST (Representational State Transfer). REST é um tipo de arquitetura para sistemas distribuídos que
utiliza conceitos com base na presença de recursos, tratados como serviços (funcionalidades), e como elementos de informação utilizados por meio de um identificador global
denominado URI (Uniform Resource Identifier) [20]. Os componentes (clientes e servidores) manipulam esses recursos através de um protocolo padrão de comunicação (HTTP),
5.2 Tecnologias Utilizadas
83
que define um conjunto de operações (verbos): POST, GET, PUT, DELETE, HEAD e
OPTIONS. Outra importante característica dos serviços RESTFul está na flexibilidade
para estender novas funcionalidades, pois cada funcionalidade pode ser implementada de
forma independente sem que haja a necessidade de refatoração do código.
O REST trabalha com três formatos para troca de mensagens: XML, JSON ou
texto puro. A CSVM utiliza o formato JSON (JavaScript Object Notation) por se tratar
de um formato menor que o equivalente em XML, o que facilita a transmissão dos dados
pela rede. Além disso, JSON possui uma estrutura simples sendo sua interpretação mais
rápida e precisa. Os detalhes de sua implementação são apresentados nas Seções 5.3 e
5.4.
5.2.3
GCM
Google Cloud Messaging (GCM). É um serviço da Google que permite a
comunicação de um aplicativo na Nuvem com um dispositivo Android através da troca de
mensagens. Esta troca de mensagens é intermediada pelos servidores GCM, que fornecem
um ID único para cada dispositivo, fazendo-se então necessário que cada dispositivo
se registre previamente neste serviço. Nesta etapa de registro, deve-se informar qual a
aplicação que o dispositivo deseja se registrar e quem é o remetente (servidor) associado
a essa aplicação. Com isso, o GCM restringe o envio de mensagens, de forma que apenas
o servidor associado, que conhece o ID dos dispositivos registrados, pode enviá-las. Em
relação ao envio de mensagens, o GCM possibilita que o Provedor de Serviço envie
requisições de compartilhamento de dados a um conjunto de dispositivos recrutados
conforme a necessidade de uma determinada aplicação
A implementação deste serviço envolve tanto o processo de registro no próprio
GCM quanto o de envio de mensagens e incluem um conjunto de credenciais necessárias
para o seu funcionamento, sendo elas:
• ID do registro (Registration ID): Identificação emitida pelos servidores GCM
para o aplicativo Android rodando em um dispositivo específico e utilizada para
identificar os dispositivos que estão aptos a receber uma determinada mensagem.
• ID do remetente (Sender ID): Equivale ao número de identificação do projeto
previamente criado na API GCM do Google referente à aplicação e é utilizado
no processo de registro para a fim de identificar um servidor habilitado para enviar
mensagens para os dispositivos.
• ID da aplicação (Application ID): Representa a identificação do aplicativo Android
que está registrado para receber mensagens. Este identificador é único, ou seja,
todos dispositivos, uma vez instalada a aplicação, possuirão o mesmo identificar,
5.3 CSVMProvider
84
sendo esta sua principal diferença em relação ao ID do registro (que identifica cada
dispositivo unicamente).
• Chave de acesso (API Key): Uma chave de acesso armazenada no servidor que
autoriza o acesso aos serviços do Google.
Neste trabalho, o serviço GCM foi utilizado para promover a conexão da CSVMProvider com os dispositivos móveis. A utilização do serviço GCM concede à CSVMProvider uma capacidade de coordenar e gerenciar a comunicação com os dispositivos, pois
ao contrário da implementação de serviços RESTFul, onde as solicitações devem sempre
partir dos dispositivos móveis, ele possibilita que as mensagens tenham origem no provedor de serviço. Neste sentido, uma aplicação no dispositivo não precisa estar em execução para receber mensagens. O sistema “acorda” a aplicação por meio da transmissão de
eventos, que envia uma mensagem para a aplicação que está rodando em background no
dispositivo (como um daemon).
Uma das maiores vantagens da solução GCM está na flexibilidade em relação a
configuração do comportamento da troca de mensagens, por exemplo, agendando o envio
da mensagem ou a enviando imediatamente. Na plataforma CSVM as aplicações construídas sobre o GCM são implementados tanto na aplicação móvel quanto no provedor de
serviço.
5.3
CSVMProvider
A implementação da CSVMProvider envolve a construção das camadas da
CSVM que fornecem as funcionalidades básicas de um cenário de crowdsensing móvel: registrar dispositivos móveis e processar consultas especificadas pelo usuário. Essas
funcionalidades serão detalhadas na seção 5.5.2 e 5.6.2 respectivamente. A Figura 5.2
apresenta um diagrama com as principais classes utilizadas na implementação das camadas da CSVMProvider.
As classes que compõem a CSVMProvider foram agrupadas em pacotes onde,
cada pacote representa uma camada da CSVMProvider. No pacote Broker contém as
classe EnvCSResource e QueryCSResource que são responsáveis por disponibilizar as
funcionalidades de registro e consulta à CSVM4Dev. Por exemplo, quando o usuário
especificar uma consulta na CSVM4Dev, um recurso de consulta de crowdsensing é
solicitado à CSVMProvider e a classe QueryCSResource é instanciada. Outra classe
importante do pacote Broker é a ResourceManager que implementa métodos que
controlam os recursos da plataforma. Esses métodos são responsáveis por verificar e
atualizar o status (ativo ou inativo) dos dispositivos e manter uma lista atualizada com
dispositivos recrutados. A última classe desse pacote é a GCMSender que implementa
5.3 CSVMProvider
85
Figura 5.2: Diagrama de classes da CSVMProvider.
os principais métodos do serviço GCM para envio de mensagens aos dispositivos móveis
(utilizado para esta finalidade o método sender).
No pacote Middleware a classe LogicalResourceManager encarrega de selecionar recursos lógicos da plataforma. Em outras palavras, esta classe possui métodos de
acesso ao repositório, onde aplica comandos SQL para selecionar os dispositivos registrados que satisfaça uma determinada consulta.
O pacote Synthesis compreende um número maior de classes, uma vez que
possui mais atribuições. A classe SchemaParser implementa um conjunto de métodos para interpretação dos modelos, como por exemplo os métodos queryProcessor e
dataSchemaProcessor responsáveis pela interpretação de um QCS e de um DS, respectivamente. A RepositoryManager é outra classe importante que controla as interações
com o banco de dados (repositório) e instancia a classe GenericDAOImpl para aplicar
comandos SQL diretamente no banco de dados. Esta classe, por sua vez, implementa
um conjunto de métodos da interface GenericDAO que abstrai as entidades presentes na
implementação da plataforma.
A classe CommandGenerator implementa um conjunto de comandos que são
aplicados a classe LogicalResourceManager para seleção dos dispositivos. Em relação
ao processamento de consultas, a classe DataSchemaGenerator implementa o método
generate responsável pela geração do esquema de dados referente a uma consulta. E
por fim, a última classe do pacote de síntese é a AggregateData que aplica as operações
(por exemplo, média) definidas em uma consulta (através do método aggregate) sobre
os esquemas de dados notificados pelos dispositivos recrutados.
5.4 CSVM4Dev
86
Em relação as tecnologias utilizadas, a CSVMProvider foi implementada por
meio da plataforma Java 1.7 (J2EE - Java 2 Enterprise Edition) e tendo como base a
arquitetura de web services RESTful. Para a implementação dos serviços RESTful, foi
utilizado um conjunto de tecnologias open source como: JAX-RS (Java API for RESTFul
web services) [27], que fornece suporte para criação de serviços REST e oferece uma
forma padrão de implementação desses serviços; Jersey [44], um framework que fornece
um conjunto de bibliotecas para o desenvolvimento de webservices RESTful usando a
API JAX-RS; e JSON, padrão para formato de dados utilizado na comunicação com os
dispositivos móveis.
Outros serviços de terceiros utilizados no desenvolvimento da CSVMProvider
incluem Apache Tomcat [63], um contêiner de servlets sobre o qual a aplicação é
executada; Hibernate [6, 31], um framework para o mapeamento objeto-relacional, que
no contexto deste trabalho se aplica entre objetos escritos na linguagem Java, e MySQL
[45], um banco de dados relacional.
5.4
CSVM4Dev
Os módulos da CSVM4Dev foram desenvolvidos para dispositivos Android
utilizando a suíte de desenvolvimento Android SDK 22.6, de modo que Java foi a
linguagem de programação adotada. Para integração com o módulo de comunicação da
CSVMProvider, foi necessário implementar um cliente RESTful. Para esta finalidade, a
classe ClientWebService é a interface direta com a CSVMProvider e é responsável por
gerenciar as requisições através das operações GET e POST.
Para persistência local de dados, foi utilizada uma biblioteca que implementa
um banco de dados SQL auto-contido/embutido, denominado SQLite [59, 46], sendo a
classe DBAdapter responsável por implementar e gerenciar as conexões com esta base
de dados. O DBAdapter é instanciado pela classe SotrageManager responsável por
intermediar as chamadas de acesso ao banco de dados. Estas duas classe integram o
pacote Synthesis juntamente com a classe QueryProcessor que implementa métodos
relacionados ao processamento de consultas geradas pela CSVMProvider. A Figura 5.3
apresenta as demais classes e pacotes utilizados na implementação da CSVM4Dev.
No pacote Middleware, a classe MiddlewareManager implementa o tratamento
de comandos gerados pela camada de síntese e métodos que realizam chamadas ao pacote
Broker. No Broker temos um conjunto de classes que estendem a classe Request que
implementa os serviços RESTFul para dispositivos móveis e é responsável por gerar requisições para CSVMProvider. As classes que a estendem são denominadas EnvCSRequest,
QueryCSRequest, DataSchemaRequest e são responsáveis por enviarem para CSVM-
5.5 Registro de dispositivos
87
Figura 5.3: Diagrama de classe da CSVM4Dev.
Provider o esquema de controle, esquema de controle da consulta e esquema de dados,
respectivamente.
Outras duas importantes classes do pacote Broker são a LocalResourceManager
responsável implementar métodos de acesso aos sensores do dispositivo e a
CSResourceManager que implementa métodos para utilização dos serviços GCM,
com destaque para o método getRegistrationId que solicita o registro no serviço
GCM.
O último pacote refere-se à camada de aplicação e possui como principais
classes a QueryActivity e a RegistrationActivity que implementam as interfaces
QueryInterface e RegistrationInterface e possuem métodos que auxiliam na
especificação de consultas e registro de dispositivos respectivamente. Essas interfaces são
responsáveis por gerar o modelo em X-CSML de consultas especificadas pelo usuário ou
do registro de dispositivos.
A CSVM4Dev, implementa três principais funcionalidades: (1) para registro do
dispositivo; (2) para especificação de consultas; e (3) processamento de consultas. As
subseções abaixo apresentam detalhes do desenvolvimento dessas três funcionalidades.
5.5
Registro de dispositivos
A implementação do processo de registro de dispositivos foi decomposto em
duas etapas principais. Uma etapa compreende os detalhes de implementação relacionados à configuração do dispositivo na CSVM4Dev para registro do dispositivo na plataforma. A outra abordagem, apresenta detalhes de implementação relacionados ao regis-
5.5 Registro de dispositivos
88
tro do dispositivo no ambiente de crowdsensing mantido pela CSVMProvider. As seções
abaixo, descrevem a implementação dessas etapas.
5.5.1
Registro do dispositivo na CSVM4Dev
O registro do dispositivo envolve um conjunto de interfaces de usuário que auxiliam o usuário na configuração do dispositivo para efetuar o registro. Cada interface
é gerenciada por uma Activity. Em termos gerais, uma Activity é uma classe gerenciadora de UI (Interface com o usuário). A Figura 5.4 apresenta as duas interfaces que
compõem a funcionalidade de registro e, para gerenciá-las, foi implementada a classe
RegisterActivity. A Figura 5.4(a) apresenta a tela principal de registro do dispositivo,
possibilitando ao usuário configurar as informações básicas do dispositivo como, proprietário, localização, marca e modelo, onde as duas últimas são extraídas automaticamente
do próprio dispositivo. Ela disponibiliza também um botão para seleção de sensores que
se deseja compartilhar. A view mostrada na Figura 5.4(b) é acionada após o usuário pressionar o botão Select Sensor e apresenta o conjunto de sensores disponíveis no dispositivo.
A classe LocalResourceManager é responsável por identificar os sensores presentes no
dispositivo por meio da chamada ao método getListSensorType, que utiliza classes
nativas do Android presentes no pacote android.hardware.
(a) Tela de Registro do Dispositivo.
(b) Tela de Seleção de Sensores.
Figura 5.4: (a) e (b) representam layouts utilizados para configurar o registro do dispositivo.
Por meio das interfaces apresentadas acima o usuário consegue especificar a configuração de seu dispositivo que deseja compartilhar, gerando o esquema de controle no
dispositivo. Este e outros processos que envolvem o registro do dispositivo estão detalhados no diagrama de sequência da Figura 5.5. Quando o usuário conclui a configuração do
5.5 Registro de dispositivos
89
registro, a camada de aplicação por meio da classe RegistrationInterface gera o XCSML referente ao registro. Em seguida, o MiddlewareManager se encarrega de aplicar
as restrições predefinas e repassar comandos à camada de broker para envio do esquema
de controle à CSVMProvider. Concluída esta etapa, o CSResourceManager, implementa
o método getRegistrationId do Google Play Services SDK, que solicita o registro do
dispositivo no serviço GCM.
Figura 5.5: Diagrama de sequência do registro do dispositivo na
CSVM4Dev.
O envio do esquema de controle gerado na CSVM4Dev para a CSVMProvider
é realizado pela classe Request, que possui um atributo url configurado com o endereço
do webservice que contêm o recurso que se deseja acessar. Esta classe implementa o
método POST e realiza também a formatação da mensagem em JSON. Após confirmação
do registro, cada camada da CSVM4Dev gera eventos à camada imediatamente superior
para apresentar uma mensagem ao usuário informando que o dispositivo foi registrado.
5.5.2
Registro de dispositivos na CSVMProvider
O registro do dispositivo envolve todas as camadas da CSVMProvider e a
implementação desta etapa está retratada no diagrama de sequência da Figura 5.6. Uma
vez que a camada de Broker recebe uma requisição de registro do dispositivo, enviada
pela CSVM4Dev tendo como parâmetro o EnvCS (o esquema de controle gerado no
dispositivo e que integrará o esquema de controle do ambiente) ela dispara um conjunto
de eventos (métodos) às demais camadas para processamento do modelo. Caso tenha
sido configurada alguma restrição, a camada de Middleware se encarrega de aplicá-las.
5.5 Registro de dispositivos
90
As restrições são inseridas na CSVMProvider diretamente no banco de dados de forma
manual.
Figura 5.6: Diagrama de sequência do registro do dispositivo na
CSVMProvider.
Com as restrições aplicadas, é disparado um evento que aciona o método
registrationProcessor, encarregado de primeiramente realizar o parsing do modelo,
verificar se todas informações estão presentes e, em seguida, realizar duas outras verificações: (1) quanto aos tipos de sensores informados, verificando se o sistema de tipos já
contempla aqueles sensores ou se é necessário inseri-los; (2) quanto ao dispositivo, verificando se ele já está registrado. Se o dispositivo já estiver registrado, as informações
do dispositivo são atualizadas. Caso contrário, as informações são inseridas no EC Ambiente. As duas verificações são realizadas pela camada do Motor de Síntese por meio de
operações CRUD (Create, Read, Update e Delete) realizadas diretamente no Repositório
e implementadas pela classe GenericDAOImpl. Esta classe implementa funcionalidades
disponibilizadas pelo hibernate que gerenciam as sessões e operações CRUD referentes
ao Repositório através de uma instância da classe EntityManager (responsável por coordenar as sessões e operações) e de chamadas a seus métodos.
Por fim, os métodos da classe GenericDAOImpl retornam valores booleanos
true se foi possível realizar a operação e false caso contrário. Este retorno determina a
criação da resposta por meio da classe Response que, caso o valor retornado seja true,
ela incorpora o status ok à mensagem a ser retornada. Em seguida, a mensagem é enviada
ao dispositivo que solicitou o registro.
5.6 Processamento de consultas
5.6
91
Processamento de consultas
O processamento de consultas é a principal funcionalidade da plataforma CSVM
e sua implementação envolve etapas que compreende desde a criação de uma consulta até
retorno de seu resultado. Essas etapas podem ser dividas em: (1) especificação de consultas na CSVM4Dev, compreende desde a criação da consulta até seu envio à CSVMProvider ; (2) o processamento de consultas na CSVMProvider, envolve o recebimento de
consultas, a seleção de recursos e o envio de subscrições aos dispositivos selecionados;
(3) o processamento de consultas na CSVM4Dev, compreende o processamento de subscrições, captura dos dados do sensor solicitado e envio da resposta à CSVMProvider. Os
detalhes de implementação de cada etapa são descritos nas seções abaixo.
5.6.1
Especificação de consultas na CSVM4Dev
A implementação do processo de especificação de consultas no dispositivo
móvel assume que as funcionalidades são acionadas diretamente pelo usuário ou por
uma aplicação de terceiros. A Figura 5.7 apresenta o processo de especificação de uma
consulta. A CSVM4Dev contém uma interface gerenciada pela classe QueryActivity,
que permite o usuário especificar uma consulta. Outras classes fundamentais no processo
de especificação da consulta são:
• A classe QueryCS que representa o modelo (Esquema de Controle da Consulta QCS) onde os atributos representam as características do modelo, como: lista com
os tipos de sensores, localização, quantidade e operação por tipo de sensor, tipo
de requisição e tipo de combinação. Os valores para o tipo de requisição e tipo
de combinação são predefinidos pela CSVM4Dev como onDemand e Aggregation
respectivamente, enquanto os demais são especificados pelo usuário.
• A classe DBAdapter é responsável por persistir o QCS no banco de dados local
(SQLite) do dispositivo.
• A classe QueryCSExecutor configura a conexão para envio do QCS, por meio da
especificação RESTFul. Esta configuração envolve o preenchimento da URL que
contêm o referido recurso no webservice, como por exemplo, http://IP/CSApp_
Webservice/qcs/newQuery.
• A classe Request implementa as funcionalidades da camada de broker referentes à
conexão com a CSVMProvider.
• A classe QueryCSRequest estende a classe Request e implementa métodos responsáveis pelo envio do QCS ao webservice.
A conexão entre a CSVM4Dev e o CSVMProvider é criada de forma assíncrona,
criando uma thread específica para cada conexão. A comunicação entre o dispositivo
5.6 Processamento de consultas
92
Figura 5.7: Diagrama de sequência da especificação de uma consutla na CSVM4Dev.
móvel e o provedor de serviço é assíncrona pois, após uma consulta ser especificada e
enviada à CSVMProvider, o dispositivo precisa ser “liberado” para que o usuário possa
realizar outras atividades. Outro importante aspecto é a economia no consumo de carga
da bateria e de memória, pois através do assincronismo, o processo gerado a partir de uma
consulta é executado em stand by, desta forma a aplicação não necessita ficar esperando
por tempo indeterminado o resultado.
Para obter este comportamento, foi utilizado AsyncTask. O AsyncTask é uma
classe que permite realizar operações em segundo plano sem ter que manipular diretamente threads e handlers. A cada requisição gerada pela CSVM4Dev um novo objeto da
classe AsyncTask é instanciado e uma thread é criada. Após a requisição ser processada
pela CSVMProvider, a CSVM4Dev recebe uma resposta que ativa a thread específica
daquela requisição.
5.6.2
Processamento de consultas na CSVMProvider
O processamento de consultas (ou subscrições), assim como o registro, envolve
todas as camadas da CSVMProvider, porém sua complexidade é maior. Para retratar a
lógica implementada, a Figura 5.8 apresenta o diagrama de sequência do processamento
de uma consulta na CSVMProvider. O desenvolvimento desta funcionalidade está pautado
em três princípios: (1) o processamento da consulta está diretamente associado com a
disponibilidade de recurso, ou seja, dispositivos registrados que satisfaçam as condições
5.6 Processamento de consultas
93
especificadas na consulta; (2) caso haja a disponibilidade de recurso (dispositivos) que
satisfaça a consulta, deve-se selecionar/recrutar os dispositivos por meio de uma política
de seleção; (3) uma vez selecionados os dispositivos deve-se então manter um M@RT
com as características da consulta.
Figura 5.8: Diagrama de sequência do processamento de uma
consulta na CSVMProvider.
Para cada consulta recebida uma sequência de comandos/métodos é acionada.
Caso haja alguma regra e/ou política de segurança definida, a classe PolicyManager
presente na camada de Middleware é encarregada de aplicá-la. Concluída esta etapa, o
método queryProcessor da classe SchemaParser recebe como parâmetro o Esquema
de Controle da Consulta (QCS) contendo uma lista dos tipos de sensores requisitados. Este
método é implementado para interpretar o modelo da consulta e, a partir das informações
contidas no modelo, iniciar o recrutamento de dispositivos.
A Figura 5.9 representa todo o processo de seleção de recursos. Uma vez identificados os recursos necessários (com base no tipo de sensor especificado na consulta),
a camada de síntese gera comandos por meio da classe CommandGenerator para efetivar
a seleção. O objeto LogicalResourceManager da camada de Middleware é instanciado
para efetivar o recrutamento/seleção do recurso e consequentemente criar o m@rt. Esta
seleção é realizada por meio de uma política que compreende um algoritmo simples, o
qual seleciona os primeiros dispositivos retornados por uma consulta ao repositório.
Caso todas condições impostas na consulta sejam satisfeitas, ou seja, a quantidade de dispositivos e o tipo de sensor especificado, uma lista com os dispositivos recrutados é retornada à camada de Broker para selecionar os dispositivos físicos com base
5.6 Processamento de consultas
94
em sua localização. Uma lista com os dispositivos efetivamente recrutados é enviada à
camada de Síntese, mais especificamente à classe SynthesisManager para atualização do
m@rt e geração do Esquema de Dados (form).
Para cada tipo de sensor especificado na consulta, um form é gerado. O método
generator da classe DataSchemaGenerator é responsável pela estruturação do form.
Cada form criado é então adicionado a uma lista que é repassada ao GCMSender para
enviá-los aos dispositivos recrutados. O GCMSender utiliza o serviço GCM para se
comunicar com os dispositivos móveis por meio do ID registrado por cada dispositivo.
Figura 5.9: Máquina de estados para seleção de recursos na
CSVMProvider.
Cada dispositivo recrutado recebe e processa a requisição enviada pela CSVMProvider e em seguida retorna o form preenchido com informação monitorada do ambiente. Ao receber este form a CSVMProvider inicia o processamento identificando a
consulta que o originou. A Figura 5.10 representa este processamento por meio de uma
máquina de estados que contempla as etapas de agregação e processamento dos dados
retornados pelos dispositivos. Um objeto AggregateData é instanciado para realizar a
agregação dos dados já monitorados por meio do método aggregate, a fim de compor
a resposta à consulta. Esta classe é encarregada de, em seguida, realizar a operação especificada na consulta, onde cada operação realiza um cálculo específico (por exemplo,
caso a operação seja avg, o cálculo da média é realizado sobre os dados retornados pelos
dispositivos).
Após cada form recebido de um dispositivo recrutado ser processado, o
RepositoryManager atualiza o Esquema de Dados mantendo assim a integridade do
repositório e auxiliando no gerenciamento da consulta, pois desta forma é possível identificar se todos forms foram processados e consequentemente, se a consulta foi finalizada.
Em seguida, o próprio RepositoryManager se encarrega de verificar se possui mais al-
5.6 Processamento de consultas
95
Figura 5.10: Máquina de estados para o processamento dos dados
retornados pelos dispositivos.
gum form a ser processado. A CSVMProvider aguarda até que todos os forms de uma
determinada consulta tenham sido processados para em seguida enviar a resposta. Para
conseguir este controle na CSVMProvider, o RepositoroyManager gerencia as consultas que estão em processamento e mantém uma informação de quantos forms restam para
que ela seja finalizada.
5.6.3
Processamento de consultas na CSVM4Dev
Diferente do processo de especificação de consultas, o processamento de uma
consulta na CSVM4Dev, apresentado na Figura 5.11, é disparado por eventos gerados
pela CSVMProvider, o qual envia à CSVM4Dev um esquema de dados que contêm
informações referentes ao tipo de sensor a ser monitorado. Ao iniciar a CSVM4Dev,
um objeto da classe GCMBroadcastReceiver é instanciado e fica executando em background ouvindo eventos disparados pela CSVMProvider. Ao receber um evento, a
classe GCMBroadcastReceiver é acionada através do médoto onReceive. Este método, de posse do Esquema de Dados, chama o método getSensorData, da classe
LocalResourceManager, para ativar o sensor requisitado e iniciar o monitoramento. Assim que obtido um valor referente ao sensor monitorado, uma instância do esquema de
dados é gerada pela classe QueryProcessor contendo o valor monitorado, a data e hora
em que o dado foi obtido, assim como a precisão e a unidade de medida relacionadas ao
sensor.
A etapa final compreende o envio do esquema de dados à CSVMProvider. Este processo tem início com a configuração da conexão realizada pela classe
5.7 Considerações Finais
96
Figura 5.11: Diagrama de sequência do processamento de uma
consutla na CSVM4Dev.
DataSchemaExecutor e prossegue com o envio do Esquema de Dados propriamente dito
de responsabilidade da classe DataSchemaRequest finalizando o processamento da consulta. Encerrado o processamento da consulta no dispositivo móvel, a CSVMProvider
interpreta e processa o Esquema de Dados (conforme apresentado na Figura 5.10) a fim
de compor a resposta final para o dispositivo solicitante.
5.7
Considerações Finais
Neste capítulo foi discutido a implementação da CSVM e dos processos intrínsecos a ela em conformidade com a arquitetura descrita no Capítulo 4. Assim, para demonstra a viabilidade da arquitetura proposta, foi apresentado um protótipo que implementa as
funcionalidades da plataforma para provimento de serviços de crowdsensing móvel, incluindo a implementação dos principais elementos (CSVMProvider e CSVM4Dev) que o
compõe.
Uma das limitações presentes na implementação da CSVM refere-se a aspectos
de segurança e privacidade, que necessitam de aprofundamento e investigação, sendo
assim apresentados como trabalhos futuros no Capítulo 8.
A implementação da plataforma, tanto de seus componentes, quanto dos seus
processos, contribuem para definição de sua capacidade em relação ao domínio de
aplicação. A capacidade da CSVM bem como seu desempenho serão avaliados no
Capítulo 6.
CAPÍTULO 6
Estudo de Caso e Avaliação
Este capítulo tem o objetivo de demonstrar a viabilidade da nossa abordagem
para o uso de uma plataforma para crowdsensing móvel dirigida por modelos em tempo
de execução. Para demonstrar as capacidades da plataforma, apresentamos na Seção 6.1
um estudo de caso, que utiliza o cenário descrito na Seção 1.2 para demonstrar o uso da
CSVM para a construção (por meio de modelos) de algumas aplicações representativas.
Uma vez apresentado o estudo de caso, a sequência deste capítulo apresenta
uma avaliação realizada para medir o desempenho da CSVM levando em consideração
etapas críticas do processamento de consultas de crowdsensing, mais especificamente dos
modelos que as descrevem. Desta forma, a Seção 6.2 apresenta a metodologia empregada
na realização dos experimentos e os resultados obtidos.
6.1
Estudo de Caso
Esta seção, apresenta um estudo de caso projetado com base no cenário da casa
noturna apresentado na Seção 1.2 a fim de demonstrar a capacidade da plataforma em
atender aos principais requisitos específicos para o domínio de crowdsensing (apresentados no Capítulo 3): simplicidade, independente de dispositivo , expressividade e flexibilidade.
Para efeito de demonstrar a abrangência da nossa proposta, este cenário compreende o ciclo total do processamento de consultas de crowdsensing pela plataforma. A
seção seguinte apresenta algumas considerações sobre o cenário visando a sua realização
como parte do estudo de caso proposto.
6.1.1
Descrição Geral
Uma casa noturna, conforme descrito na Seção 1.2, precisa estar adequada a
um conjunto de normas e se preocupar em proporcionar um ambiente agradável a seus
clientes. A casa noturna possui sistemas automatizados que auxiliam nessa tarefa. Os
principais fatores associados à qualidade do ambiente estão associados ao sistema de
6.1 Estudo de Caso
98
climatização, iluminação e sonorização. Para o bem-estar dos clientes e atendimento à
norma de segurança, a casa noturna deve possuir uma quantidade limite de pessoas em
seu interior. Em conjunto, essas características representam os principais serviços a serem
monitorados em uma casa noturna.
Para assumir, a casa noturna necessita de uma pessoa, normalmente representada
pelo gerente. O gerente têm como principal atribuição realizar o monitoramento completo
do ambiente e mantê-lo em funcionamento durante os shows e eventos. Ele possui uma
aplicação que o auxilia na análise e realização deste monitoramento. Este monitoramento
envolve um conjunto de tarefas:
•
•
•
•
•
•
Detectar riscos de incêndio;
Manter a temperatura controlada;
Manter o nível de ruído do ambiente em padrões aceitáveis;
Controlar a luminosidade do ambiente;
Controlar a quantidade de pessoas no interior do ambiente;
Verificar a agitação no interior do ambiente.
Por fim, a casa noturna apresenta duas importantes características: a maioria dos
frequentadores possui um dispositivo móvel com sensores embarcados; e o alto fluxo de
usuários que transitam, entrando e saindo do ambiente com frequência.
6.1.2
Modelagem do Cenário
Este cenário pode ser modelado por um conjunto de aplicações que utilizam
os serviços de crowdsensing fornecidos pela plataforma CSVM para realização das
principais tarefas de monitoramento descritas na Seção 6.1.1. A Figura 6.1, apresenta
o diagrama em camadas da CSVM e as principais etapas para realização deste cenário.
Para realização do cenário segundo a abordagem proposta neste trabalho, três
etapas devem ser seguidas:
1. Especificação e Modelagem:
• Registro do dispositivo na plataforma;
• Identificação do conjunto de sensores necessários ao problema;
• Especificação consultas de crowdsensing associadas ao conjunto de sensores
listados na etapa anterior;
2. Processamento
• Seleção de dispositivos que satisfaçam a consulta;
• Monitoramento dos dados requisitados;
3. Resposta
6.1 Estudo de Caso
99
• Geração de resposta;
• Visualização e análise da resposta recebida;
Figura 6.1: Diagrama de camadas da CSVM com as principais
etapas na processamento de consultas.
1a etapa: Especificação e Modelagem
Para poder utilizar os serviços de crowdsensing da CSVM, o gerente da casa
noturna deverá possuir em seu dispositivo, além da aplicação de crowdsensing que o
auxiliará na análise dos dados monitorados do ambiente, também o componente móvel
da plataforma CSVM, a CSVM4Dev. O passo seguinte é registrar o dispositivo na
CSVM, o que é feito utilizando a interface de usuário fornecida pela camada de aplicação
da CSVM4Dev. Para registrar o dispositivo, o gerente deve especificar as informações
do dispositivo (marca, modelo e proprietário) juntamente com os sensores que deseja
compartilhar. A CSVM4Dev se encarrega de gerar o esquema de controle em X-CSML,
apresentado na Figura 6.2. O registro é concluído quando o esquema de controle do
dispositivo é inserido no repositório de esquemas e passa a integrar o esquema de controle
do ambiente.
Antes de especificar uma consulta de crowdsensing, o gerente deve identificar
o conjunto de sensores necessários para o problema em questão. Neste cenário, os
problemas são representados pelas tarefas de monitoramento descritas na Seção 6.1.1.
A Tabela 6.1 apresenta os problemas a serem modelados pela aplicação de crowdsensing,
associados a um ou mais sensores.
De posse destas informações, o gerente é capaz de especificar consultas relacionadas ao domínio do problema, informando os sensores que deseja monitorar. A consulta
6.1 Estudo de Caso
100
Figura 6.2: Esquema de controle para registro do dispositivo descrito em X-CSML.
no
1
2
3
4
5
6
Problema
Sensor(es)
Detectar riscos de incêndio
Umidade e temperatura
Manter a temperatura controlada
Umidade e temperatura
Manter o nível de ruído do ambiente em padrões aceitáveis
Áudio
Controlar a luminosidade do ambiente
Luminosidade
Controlar a quantidade de pessoas no interior do ambiente
Geolocalização
Verificar a agitação no interior do ambiente
Acelerômetro
Tabela 6.1: Sensores utilizados por aplicações de crowdsensing
conforme o problema a ser modelado
deve ser especificada pela aplicação de crowdsensing e enviada à CSVM4Dev em XCSML por meio da API CSVM (Figura 6.1 etapa 1-1). Por exemplo, o problema 3,“Manter o nível de ruído do ambiente em padrões aceitáveis”, pode ser especificado da seguinte
forma: Necessito de 20 sensores de áudio localizados na boate X. Deve-se informar a operação e o tipo de requisição desejada, conforme apresentado na Tabela 6.2. A Figura 6.3
apresenta o esquema de controle da consulta equivalente ao problema 3.
Por fim, na CSVM4Dev, o esquema de controle da consulta (QCS) especificada
pelo usuário é gerado na camada de aplicação e repassado à camada de síntese (Figura 6.1
etapa 1-2) para armazenamento e geração de comandos à camada de middleware (Figura
6.1 etapa 1-3), que por sua vez, realiza chamadas à camada de broker (Figura 6.1 etapa
1-4) para envio do QCS à CSVMProvider (Figura 6.1 etapa 1-5).
2a etapa: Processamento
Ao receber o QCS, a CSVMProvider inicia a interpretação e o processamento da
consulta. A camada de síntese realiza a interpretação do modelo, identificando os tipos
de sensores (neste caso áudio) e a localização (boate X). Realizada esta interpretação, a
6.1 Estudo de Caso
101
Campo
Tipo de sensor
Quantidade
Localização
Operação
Requisição
Valor
áudio
20
boate X
avg
onDemand
Tabela 6.2: Representação de campo e valor de uma consulta especificada a partir do problema 3.
Figura 6.3: Esquema de controle da consulta descrito em X-CSML
para o problema 3.
camada de síntese repassa comandos à camada de middleware (Figura 6.1 etapa 2-1) para
selecionar 20 dispositivos que satisfaçam as condições relacionadas ao tipo e quantidade
de sensores e gerar a instância do QCS após selecionado os dispositivos. A Figura 6.4
apresenta parte da instância do QCS descrita em X-CSML para o problema 3. O Apêndice
B, apresenta o X-CSML completo dessa instância.
Em seguida, a instância do QCS é passada (Figura 6.1 etapa 2-2) a camada de
síntese que gera o esquema de dados com base na consulta especificada. A Figura 6.5
apresenta parte desse esquema de dados que compreende um form que será enviado e os
dispositivos recrutados para requisitar o monitoramento do áudio da boate. O Apêndice
B, apresenta o X-CSML completo desse esquema de dados.
Nesta etapa, duas situações distintas podem ocorrer que alteram diretamente o
comportamento da plataforma: (1) o gerente pode alterar uma consulta acrescentando
um novo tipo de sensor à consulta que está sendo processada; ou (2) algum dispositivo
recrutado deixar o ambiente. Em seguida é detalhado o comportamento da plataforma
nessas duas situações:
Situação 1: Alteração de uma consulta acrescentando um novo tipo de sensor
• Problema antigo: Manter o nível de ruído do ambiente em padrões aceitáveis;
6.1 Estudo de Caso
Figura 6.4: Instância do esquema de controle da consulta descrita
em X-CSML para o problema 3.
Figura 6.5: Esquema de dados descrito em X-CSML para o problema 3.
102
6.1 Estudo de Caso
103
• Consulta em processamento: Necessito de 20 sensores de áudio localizados
na boate X;
• Problema novo: Manter o nível de ruído do ambiente em padrões aceitáveis
e verificar a agitação no interior do ambiente;
• Consulta nova: Necessito de 20 sensores de áudio localizados na boate X e
10 sensores de acelerômetro localizados na boate X;
• Comportamento:
1. A CSVM4Dev recebe a nova consulta através da camada de aplicação,
gera o modelo em X-CSML e o repassa à camada de síntese;
2. A camada de síntese localiza o esquema de controle da consulta (QCS)
em questão no repositório e o atualiza com os dados da nova consulta.
Em seguida gera comandos às camadas inferiores para envio do QCS
atualizado;
3. A camada de broker envia o QCS atualizado para a CSVMProvider;
4. Na CSVMProvider, após o QCS atualizado ser recebido pela camada de
broker ele é enviado à camada de síntese que por meio de um identificador
do QCS é integrado ao QCS em processamento;
5. A camada de síntese da CSVMProvider calcula a diferença entre o QCS
atualizado e o antigo e gera comandos para a camada de middleware
recrutar novos dispositivos conforme o novo QCS.
Situação 2: Um dispositivo recrutado sai do ambiente que está sendo monitorado
• Problema: Manter o nível de ruído do ambiente em padrões aceitáveis;
• Consulta em processamento: Necessito de 20 sensores de áudio localizados
na boate X;
• Ocorrência: Um dispositivo recrutado sai da boate;
• Comportamento:
1. A camada de broker da CSVMProvider verifica de 15 em 15 minutos o
estado (ativo ou inativo) dos dispositivos recrutados;
2. Caso identificada a indisponibilidade de um dos dispositivos, conforme
ocorrência apresentada, a camada de broker gera eventos para as camadas
superiores alterarem a instância do esquema de controle da consulta que
possuía aquele dispositivo indisponível;
3. A camada de síntese atualiza a instância do QCS e repassa comandos para
a camada de middleware selecionar um novo dispositivo que possua um
sensor de áudio (conforme especificado na consulta);
4. A camada de middleware seleciona um novo dispositivo e realiza chamadas à camada de broker para verificar a disponibilidade do novo disposi-
6.1 Estudo de Caso
104
tivo e requisitar seu sensor;
5. Caso o dispositivo esteja disponível, ele procederá com o processamento
da consulta; Caso contrário, a camada de broker gera eventos para a
camada de síntese a fim de selecionar um novo dispositivo e retorna o
passo 3.
3a etapa: Resposta
De posse do esquema de dados, a camada de broker da CSVM4Dev seleciona
o(s) sensor(es) descritos no esquema de dados (Figura 6.1 etapa 3-1). Cada dispositivo
recrutado presente na boate, realiza a medição do áudio e, em seguida, “preenche” o
form recebido gerando uma instância do esquema de dados equivalente. A Figura 6.6
apresenta uma instância do esquema de dados gerada por um dos dispositivos recrutados
após realizar a medição. Em seguida, a CSVM4Dev envia os dados à CSVMProvider
(Figura 6.1 etapa 3-2). Neste momento, a camada de síntese da CSVMProvider, à
medida que os dispositivos notificam os dados, realiza a agregação destes dados a fim
de compor a resposta final para o gerente. A CSVMProvider aguarda até que todos os 20
dispositivos notifiquem seus dados. Após receber os dados medidos pelos 20 dispositivos,
a CSVMProvider, mais especificamente a camada de síntese, realiza a operação informada
(neste cenário, realiza a média), e gera a resposta e a notifica ao gerente (Figura 6.1 passo
3-3).
Figura 6.6: Instância do esquema de dados descrita em X-CSML
para o problema 3.
A resposta é recebida pela CSVM4Dev, que a repassa (através da interface
disponibilizada na camada de aplicação) para a aplicação de crowdsensing utilizada pelo
gerente. Esta aplicação se encarregará de analisar a resposta e, caso necessário, realizar
alguma ação.
6.2 Avaliação de Desempenho
6.1.3
105
Considerações Gerais
O estudo de caso apresentado permitiu demonstrar que dado um cenário, um
conjunto de aplicações de crowdsensing móvel podem ser modeladas, a fim de auxiliar
na execução de tarefas cotidianas, contribuindo para melhorar a qualidade do ambiente e
prevenir riscos. A escolha de um cenário representativo, como de uma casa noturna, nos
possibilita analisar as capacidades da abordagem proposta neste trabalho.
Diante das características deste cenário, por exemplo, dinamicidade e heterogeneidade, torna-se aplicável o uso de uma plataforma para crowdsensing móvel dirigida
por modelo que podem ser modificados em tempo de execução. Nesse sentido, mostramos
que a utilização da CSVM se insere ao cenário proposto e cumpre os principais requisitos
apresentados.
Em suma, as principais exigências e restrições do cenário apresentado foram
sobrepostas pela utilização da plataforma CSVM, uma vez que ela permite modelar as
principais características desse cenário, como diversidade de dispositivos presentes (como
pode ser visto por meio da instância do esquema de controle da consulta apresentado no
Apêndice B) e principalmente a flexibilidade quando se faz necessário a alteração de uma
consulta.
6.2
Avaliação de Desempenho
Uma vez construídos os esquemas de controle e os esquemas de dados que
representam uma aplicação de crowdsensing, seu processamento junto à plataforma foi
avaliado. O objetivo da avaliação foi verificar o tempo gasto no processamento de modelos
para avaliar o impacto do processamento de modelos em cenários de crowdsensing móvel.
A avaliação envolve a interpretação do modelo, seleção de recursos e geração de resposta.
A Seção 6.2.1 apresenta a metodologia empregada na elaboração dos experimentos e utilizada na avaliação. Em seguida, são apresentados os resultados obtidos em cada
experimento. Por fim, tem-se as considerações gerais.
6.2.1
Metodologia
Para realizar essa avaliação, foi elaborado um conjunto de experimentos que
representam as etapas mais críticas da execução de uma consulta de crowdsensing pela
CSVM. A execução desses experimentos na plataforma CSVM foi utilizada para avaliar
o impacto do processamento de modelos em cenários de crowdsensing móvel. Com base
no cenário descrito na Seção 6.1, foram projetados quatro experimentos que simulam as
etapas de processamento e geração de respostas pela plataforma.
Os experimentos elaborados para esta avaliação são brevemente descritos abaixo:
6.2 Avaliação de Desempenho
Experimento 1 Processamento do esquema de controle da consulta com
quantidade de dispositivos recrutados para um único tipo de sensor;
Experimento 2 Processamento do esquema de controle da consulta com
quantidade de tipos de sensores;
Experimento 3 Processamento e agregação do esquema de dados com
quantidade de dispositivos recrutados para um único tipo de sensor;
Experimento 4 Processamento e agregação do esquema de dados com
quantidade de tipos de sensores;
106
variação da
variação da
variação na
variação na
O tempo relacionado ao processamento do esquema de controle da consulta
(Experimentos 1 e 2), tc , combinado com o tempo de agregação dos dados notificados
pelo conjunto de dispositivos recrutados e geração de respostas (Experimentos 3 e 4),
ta , corresponde ao tempo de processamento de uma consulta T na CSVMProvider, onde
T = tc + ta .
Para o cálculo do tempo gasto na realização desses experimentos, não foi
considerado o tempo de processamento na CSVM4Dev, pois esse tempo pode variar
de dispositivo para dispositivo, uma vez que cada dispositivo apresenta características
específicas como, quantidade de memória disponível, capacidade de processamento, além
de fatores externos como por exemplo o tipo de conexão utilizada.
No entanto, uma vez que se faz necessário estimar o tempo total gasto pela plataforma no processamento de uma consulta, Tt , deve se adicionar o tempo de troca de
mensagens entre o provedor e os dispositivos utilizando uma infraestrutura de comunicação, tr , e o tempo que o dispositivo leva para processar uma requisição, td . Desta forma
podemos assumir o tempo total gasto pela CSVM no processamento de uma consulta
sendo, Tt = tc + ta + tr + td .
O ambiente para realização dos experimentos consiste em uma máquina com
processador AMD Quad-Core 2.4GHz, 4GB de RAM, Sistema Operacional Windows 8.1
de 64 bits para executar a CSVMProvider e um dispositivo móvel Samsung Galaxy SIII,
16GB de memória, Sistema Operacional Android 4.3 para executar a CSVM4Dev. Todos
os experimentos foram realizados em um único dispositivo móvel, que simula outros
dispositivos quando necessário. Essa metodologia não comprometeu o resultado, uma vez
que as avaliações estão relacionadas à manipulação de modelos em tempo de execução na
CSVMProvider, não levando em consideração o tempo de processamento nos dispositivos
móveis.
Foram realizadas 10 (dez) execuções de cada experimento, onde para cada
execução foi realizada uma variação ou na quantidade de dispositivos recrutados (para
1 (um) tipo de sensor, por exemplo temperatura) ou na quantidade de tipos de sensores.
Para cada variação foram realizadas 10 (dez) execuções, totalizando 100 execuções de
cada experimento. Em seguida, foi calculado o tempo médio de execução eliminando
6.2 Avaliação de Desempenho
107
do cálculo o outlier. Para o cálculo do tempo médio final, foi subtraído do tempo de
processamento de cada variação o tempo de acesso ao banco de dados, uma vez que
ao isolarmos as transações com o banco de dados identificamos que o tempo de acesso e
realização de transações com o banco se caracterizava como um gargalo no processamento
das consultas. Ao isolarmos o tempo gasto nas operações com o banco de dados realizados
por soluções de terceiros (hibernate e MySQL) e apesar dessas soluções integrarem a
solução proposta neste trabalho, esse fator não comprometeu a análise dos experimentos,
uma vez que avaliamos o tempo gasto por nossa solução na interpretação e processamento
de modelos propriamente dito.
Para validar a abrangência e escalabilidade da plataforma, alguns experimentos
transcendem o cenário apresentado. Assim, eles não surgiram de uma demanda específica
e apresentam caráter teórico. Contudo, outros cenários podem exigir da plataforma um
comportamento semelhante ao experimentado nesta seção.
Antes de executar os experimentos, foi construído um esquema de controle do
ambiente contendo 100 (cem) dispositivos, 15 (quinze) tipos de sensores e 2 (dois) tipos
de operações aritméticas (média e soma). Para cada dispositivo foi inserida a localização
lógica boate x associada ao cenário do estudo de caso e para cada dispositivo foram
associados também os 15 tipos de sensores. Em seguida este esquema de controle
do ambiente foi inserido no repositório. As seções seguintes, apresentam detalhes e
resultados dos experimentos realizados.
6.2.2
Processamento do esquema de controle da consulta com variação da quantidade de dispositivos
Este experimento tem o objetivo de medir o tempo de processamento do modelo
de uma consulta, considerando uma variação na quantidade de dispositivos recrutados e
sua construção equivale a 2a etapa descrita na Seção 6.1.2. Segue-se um detalhamento do
experimento.
Objetivo do experimento: Medir o tempo de processamento do modelo de consulta,
mantendo constante o número de tipos de sensor e variando a quantidade de
dispositivos;
Ações realizadas pela CSVM: Interpretar o esquema de controle da consulta e aplicar
o algoritmo de seleção de dispositivos com base na variação da quantidade de
dispositivo;
O gráfico da Figura 6.7 apresenta o tempo médio de processamento de
uma consulta em relação à quantidade de dispositivos. O resultado foi obtido por
meio da medição do processamento de uma consulta especificada na forma: N
6.2 Avaliação de Desempenho
108
sensores de temperatura localizados na boate x, onde N é a quantidade
de dispositivos e varia de 1 até 10. O resultado nos mostra que à medida em
que aumentados o número de dispositivos, o tempo aumenta em média 0,19 milissegundos (para cada novo dispositivo). Assim, para o experimento proposto podemos afirmar
que a plataforma CSVM consegue escalar bem em relação ao aumento do número de
dispositivos.
Figura 6.7: Tempo de Processamento de Consultas com variação
da Quantidades de Dispositivos.
Com base nesse resultado, pode-se concluir também que, a abordagem não é
eficiente para um número muito grande de dispositivos recrutados, o que aponta para a
necessidade de reduzir o número de dispositivos para amostrar os dados que o usuário
necessita. Nesse sentido, deve-se admitir alguma tolerância com relação à precisão ou a
resolução dos dados.
O gráfico da Figura 6.8 apresenta o tempo de processamento de consulta referente a uma extensão deste experimento, onde extrapolamos a quantidade de dispositivos
a fim de avaliar a forma como a CSVM escala consultas com um número relativamente
grande de dispositivos. Desta forma, iniciamos o experimento com 25 dispositivos e dobramos até obtermos 100. Verificamos que, à medida que o número de dispositivos dobra,
o tempo de processamento aumenta em média 6,70 milissegundos.
6.2.3
Processamento do esquema de controle da consulta com variação na quantidade de tipos de sensores
Este segundo experimento tem o objetivo de medir o tempo de processamento do
modelo de uma consulta, considerando uma variação na quantidade dos tipos de sensores.
O experimento pode ser detalhado da seguinte forma:
6.2 Avaliação de Desempenho
109
Figura 6.8: Tempo de Processamento de Consultas com 25, 50 e
100 Dispositivos.
Objetivo do experimento: Medir o tempo de processamento do modelo de consulta,
mantendo constante a quantidade de dispositivo e variando a quantidade de tipos
de sensores;
Ações realizadas pela CSVM: Interpretar o esquema de controle da consulta e aplicar o
algoritmo de seleção de dispositivos;
A Figura 6.9 apresenta um gráfico do tempo de processamento do modelo
em relação à variação do tipo de sensores. Neste experimento, foram utilizados 10
tipos diferentes de sensores presentes em um único dispositivo. A consulta foi modelada da seguinte forma: 1 sensor M localizado na boate X, onde M é o tipo
de sensor e pode variar de 1 a 10 tipos. Por exemplo, caso M = 2, podemos
ter a seguinte consulta: 1 sensor de temperatura e luminosidade localizado
na boate X.
O resultado apresentado no gráfico, mostra que à medida que aumentamos o
número de tipos de sensores em uma consulta, o tempo de processamento aumenta
linearmente em média 4,87 milissegundos (para cada novo tipo acrescentado).
Ao compararmos os dois experimentos apresentados, temos que o custo de acrescentar novos tipos de sensores à consulta (experimento 2) é maior que o custo de acrescentar novos dispositivos (experimento 1). Este resultado, decorre do comportamento do
algoritmo de seleção, uma vez que a cada tipo de sensor associado à consulta ele dispara
um conjunto de métodos que realizam tanto operações no banco de dados como a criação de uma estrutura de dados linear e dinâmica para armazenamento dos dispositivos
recrutados. Desta forma, ao manter a quantidade de tipos de sensores constante e variar a
quantidade de dispositivos, conforme experimento 1, o custo é menor devido ao número
de operações realizadas. Em contrapartida, quando a quantidade de dispositivos é mantida
6.2 Avaliação de Desempenho
110
Figura 6.9: Tempo de Processamento de Consultas com Variação
da Quantidades de Tipos de Sensores.
constante e a quantidade de tipos de sensores é variada, o custo é maior, pois o número de
operações realizaras será diretamente proporcional à quantidade de tipos de sensores.
6.2.4
Processamento e agregação do esquema de dados com variação
na quantidade de dispositivos
Este experimento refere-se à geração de respostas (3a etapa apresentada no
estudo de caso) realizada pela CSVMProvider. Neste experimento, desejamos medir o
tempo que a CSVMProvider leva para reunir os dados notificados pelos dispositivos
recrutados e gerar a resposta para o dispositivo solicitante. Abaixo seguem os detalhes
do experimento:
Objetivo do experimento: Medir o tempo de processamento e agregação de dados notificados pelos dispositivos participantes de uma consulta referentes a um único tipo
de sensor;
Ações realizadas pela CSVM: Interpretar o esquema de dados, verificar quantidade de
dispositivos que ainda não concluíram o processamento, aplicar a operação definida
na consulta e gerar a resposta;
O gráfico da Figura 6.10 apresenta o tempo médio de processando dos dados
notificados pelos dispositivos em relação à quantidade de dispositivos. Em relação aos
experimentos anteriores, percebemos um aumento no tempo de processamento, que
decorre do fato de que a quantidade de ações realizadas pela CSVMProvider durante
esta etapa é maior que a quantidade de ações realizadas no processamento de consulta.
À medida que mais dispositivos associados a um único tipo sensor, notificam dados à
6.2 Avaliação de Desempenho
111
CSVMProvider, o tempo de processamento aumenta em média 49,21 milissegundos (para
cada novo dispositivo).
Figura 6.10: Tempo de Processamento e Agregação de Dados com
Variação da Quantidade de Dispositivos.
6.2.5
Processamento e agregação do esquema de dados com variação
na quantidade de tipos de sensores
Este último experimento refere-se à mesma etapa do experimento anterior mas
difere pela quantidade de dispositivos e tipos de sensores envolvidos. Neste experimento,
os dados são notificados por um único dispositivo, porém a quantidade de tipos de
sensores é variável. Os detalhes do experimentos são apresentados abaixo:
Objetivo do experimento: Medir o tempo de processamento e agregação de dados notificados por um dispositivo participante de uma consulta;
Ações realizadas pela CSVM: Interpretar o esquema de dados, verificar quantidade de
dispositivos que ainda não concluíram o processamento, aplicar a operação definida
na consulta e gerar a resposta;
O gráfico da Figura 6.11 apresenta o tempo médio de processamento dos dados em relação à quantidade de tipos de sensores. É possível notar um pequeno aumento
em relação ao experimento apresentado anteriormente. Porém, apesar deste aumento, a
quantidade de ações/operações empregadas neste processamento equivale aquela do experimento anterior, uma vez que não estamos considerando o tempo gasto na comunicação
com o dispositivo e nem o tempo gasto pelo dispositivo na geração dos dados.
Em suma, à medida que aumentamos o número de tipos de sensores, o tempo de
processamento aumenta em média 52,18 milissegundos (para cada novo tipo de sensor).
6.3 Considerações Gerais
112
Figura 6.11: Tempo de Processamento e Agregação de Dados com
Variação a Quantidade de Tipos de Sensores.
O alto tempo de processamento nesta etapa decorre do fato de que a cada notificação
(instância do esquema de dados contendo o dado monitorado) enviada pelo dispositivo
e relacionada a um tipo de sensor, a CSVMProvider realiza a interpretação da instância
do esquema de dados recebida, aplica a operação definida na consulta e por fim, gera a
resposta. A geração da resposta só será concluída após o dispositivo enviar a instância do
esquema de dados referente a todos os tipos de sensores associados à consulta.
6.3
Considerações Gerais
O uso da CSVM permite modelar a maioria das aplicações de crowdsensing
inseridas em diferentes cenários. Além disso, o estudo de caso apresentado demonstra que
a CSVM atende aos principais requisitos dos ambientes de crowdsensing: simplicidade,
interoperabilidade, expressividade e flexibilidade.
Em relação à avaliação quantitativa, os resultados obtidos apresentam uma
diferença substancial entre o processamento do esquema de controle da consulta e o
processamento do esquema de dados notificados (tempo de resposta). O aumento no
tempo de processamento do esquema de dados em relação ao esquema de consulta, é
justificado pelo maior número de ações realizadas na etapa de processamento e agregação
de dados, onde as principais ações envolvem a interpretação do esquema de dados e a
geração de resposta.
Em relação ao desempenho, o uso da CSVM não é recomendado em situações
críticas que demandam alta interatividade. Contudo, os experimentos realizados, nos permitem demonstrar a escalabilidade da CSVM à medida que inserimos novos dispositivos
ou aumentamos o número de tipos de sensores.
CAPÍTULO 7
Trabalhos Relacionados
Este capítulo apresenta e discute trabalhos representativos da literatura da área
que propõem abordagens de solução para o problema de CrowdSensing móvel. Esses
trabalhos são apresentados em duas categorias: aqueles que tratam do problema-alvo e
aqueles que utilizam a mesma técnica empregada.
Partindo de uma outra perspectiva, este capítulo apresenta uma revisão bibliográfica sobre a utilização de modelos em tempo de execução em diferentes domínios de
aplicação, comparando outros trabalhos encontrados na literatura com o presente trabalho
do ponto de vista do uso e adaptação das técnicas relacionadas.
Na sessão 7.1 discutiremos as principais características relativas ao domínio de
CrowdSensing móvel, apresentando trabalhos relacionados e comparando-os com este.
Para lidar com as especificidades dos ambientes de CrowdSensing móvel este trabalho
propõe o uso de Modelos em Tempo de Execução. A sessão 7.2 retoma a discussão de
trabalhos relacionados, porém utiliza como elemento chave o uso de Modelos em Tempo
de Execução aplicado a diferentes contexto e qual a relação destes trabalhos com o nosso.
7.1
CrowdSensing Móvel
Um dos principais assuntos discutidos pela comunidade acadêmica da área está
diretamente relacionado à forma com que os ambientes e aplicações de CrowdSensing
móvel são estruturados. Ganti et al propõem em [23] um modelo arquitetural unificado
que aborda diversas limitações encontradas no desenvolvimento e implantação de aplicativos para CrowdSensing. Esse trabalho tem sido usado como referência para inúmeros
outros trabalhos nesta área, incluindo o presente trabalho. No referido trabalho, o modelo
arquitetural obedece três princípios básicos:
• O modelo deve permitir que desenvolvedores e/ou usuários especifiquem suas necessidades de dados em uma linguagem de alto nível. Este princípio é representado
neste trabalho pela CSML que possibilita aos desenvolvedores e usuários descreve-
7.1 CrowdSensing Móvel
114
rem suas consultas de CrowdSensing por meio de modelos descritos tanto por uma
interface gráfica ou por uma representação em XML (X-CSML);
• O modelo deve prever a identificação automática do conjunto de dispositivos que
fornecerão os dados desejados e também produzir instruções para configurar as
atividades de sensoriamento nos dispositivos, além de adaptar o conjunto de dispositivos escolhidos quando houver mudanças dinâmicas no ambiente. Em relação a
este aspecto, nosso trabalho apresenta uma abordagem dirigida por modelos onde,
na camada de síntese da CSVM, o componente CSMLParser interpreta o modelo
de consulta previamente criado usando a aplicação de CrowdSensing em execução
no cliente e gera comandos tanto para seleção dos dispositivos que fornecerão os
dados, quanto para criação de um formulário (esquema de dados) para configurar
as atividades de sensoriamento nos dispositivos selecionados. Para adaptação dinâmica às mudanças do ambiente, propomos a utilização de modelos em tempo de
execução, que mantém os modelos do ambiente e das consultas causalmente conectados com o sistema, ou seja, qualquer intervenção no modelo é refletida no sistema
e qualquer intervenção no sistema é refletida no modelo;
• O modelo deve possuir uma camada para lidar com dispositivos heterogêneos.
Neste trabalho esta funcionalidade está implementada na camada de broker (CSB)
da CSVM. Uma das funções da camada de broker é prover uma interface que
permite que dispositivos heterogêneos interajam com a CSVMProvider, compartilhando ou obtendo dados de ambientes de CrowdSensing. Desta forma, os dispositivos, independente de suas características, acessam o mesmos recursos da plataforma da mesma forma.
De acordo com o que foi exposto acima, a proposta de Ganti et al pode ser
considerada como um modelo para a definição da arquitetura utilizada em nosso trabalho.
Os princípios por eles introduzidos foram implementados na CSVM de forma a compor
uma arquitetura consistente para execução de aplicações de CrowdSensing.
Na literatura predominam trabalhos que adotam uma arquitetura particionada,
onde parte dos componentes estão localizados nos dispositivos móveis (para coleta e
propagação de dados dos sensores) e outra parte em um backend ou na nuvem (para
análise, processamento e armazenamento de dados das aplicações de CrowdSensing).
7.1.1
Medusa
Moo-Ryong Ra et al apresenta Medusa [50], um framework que fornece uma
linguagem de programação de alto nível e um sistema distribuído para o desenvolvimento
eficiente de aplicações de CrowdSensing móvel. Ele emprega uma arquitetura particionada entre smartphones e um servidor na nuvem para coordenar as tarefas (Figure 7.1).
7.1 CrowdSensing Móvel
115
Figura 7.1: Medusa - Arquitetura do Sistema [50].
Em Medusa, as tarefas criadas por uma aplicação de Crowdsensing são especificadas como uma sequência de etapas e descritas utilizando uma linguagem de programação de alto nível denominada MedScript. Essa é uma linguagem específica de domínio
baseada em XML, que define uma instância de uma tarefa, especificando a sequência de
ações executadas por um único dispositivo. Ela é composta por dois elementos principais:
stages e connectors. Stage descreve ações para processamento, monitoramento e comunicação automática ou dependente de intervenção humana. Já connectors é o elemento
que expressa o fluxo de controle entre os stages. Para que as tarefas criadas utilizando
MedScript possam ser executadas foi implantado no servidor o MedScript Interpreter,
que executa checagens das tarefas submetidas e em seguida notifica o Task Tracker, que é
responsável por coordenar o estágio de execução de todas as instâncias da tarefa.
Com base no exposto, nosso trabalho apresenta uma estratégia diferente ao
utilizarmos a linguagem de modelagem CSML, por meio da qual possibilitamos duas
formas de descrever uma consulta de CrowdSensing: uma fundamentada em XML (como
no Medusa) e a outra por meio de uma interface gráfica (front-end). Esta linguagem
facilita a compreensão e interação de usuários e desenvolvedores com a plataforma
proposta.
Vale ressaltar ainda que outro aspecto característico de Medusa é o suporte à
intervenção humana em várias etapas do processamento de uma tarefa. Esta intervenção
ocorre em alguns estágios e caracteriza-se pelas seguintes ações: autorizar a execução
de uma instância da tarefa, rever os dados antes da submissão, ativar manualmente o
sensor e assinar o resultado (desde que requerida pelo solicitante). Esta dependência
deixa o sistema mais oneroso. Em contrapartida, nosso trabalho prevê um processamento
7.1 CrowdSensing Móvel
116
automático das consultas especificadas pelo usuário, o que alcançamos após o usuário
registrar seu dispositivo e aceitar o termo de serviço, concordando com o recebimento de
requisições e envio de dados sensoriados. No entanto, o usuário pode a qualquer momento
redefinir regras de acesso e privacidade, restringindo ou liberando acesso aos dados dos
sensores.
A comunicação é um fator crítico para ambientes de CrowdSensing e amplamente discutido na comunidade científica. Relacionado a esta característica, Medusa
apresenta em sua arquitetura o Worker Manager, que utiliza o Amazon Mechanical Turk
(AMT) para recrutar colaboradores para uma determinada tarefa de CrowdSensing, por
meio do envio de uma notificação utilizando Short Message Service (SMS) e o Android
Cloud to Device Messaging (C2DM) para as demais trocas de mensagens entre o servidor e os dispositivos móveis. O serviço C2DM foi oficialmente descontinuado em 26 de
junho de 2012, sendo substituído pelo Google Cloud Messaging for Android (GCM) que
foi implementado neste trabalho para prover a troca de mensagens de forma simples e rápida. A seleção dos dispositivos “colaboradores” foi implementada em sua totalidade em
nosso provedor de serviço, possibilitando aplicarmos politicas de escolhas mais eficientes
e maior flexibilidade em relação ao Medusa.
7.1.2
Vita
Vita [28] é um sistema ciber-físico (CPS) móvel para aplicações de CrowdSensing descrito através de uma arquitetura universal particionada (Figura 7.2). Similarmente
ao nosso trabalho, Hu et al expõe por meio do Vita uma arquitetura orientada a serviço
(SOA) que adota os princípios de projeto de REpresentational State Transfer (REST)-ful
Web Services [48], para apoiar as interações entre a plataforma móvel e a nuvem.
Figura 7.2: Vita - Arquitetura [28].
O sistema Vita fornece um ambiente de desenvolvimento (Development Environment Provision) e interfaces de programação (API) por meio da Cloud Platform para
7.1 CrowdSensing Móvel
117
apoiar os desenvolvedores e permitir que provedores de serviços de terceiros possam participar no desenvolvimento de diferentes aplicações e serviços para CrowdSensing móvel.
Contudo, o processo de desenvolvimento de aplicações no Vita apresenta alta demanda
de comunicação, caracterizada pelo grande volume de dados e pacotes transferidos entre a plataforma móvel e o provedor de serviço. Na modelagem da CSVM, foi proposta
uma API que permite que aplicações desenvolvidas por terceiros utilizem recursos da
plataforma. Essa API é disponibilizada através da CSVM4Dev, desta forma, a comunicação entre as aplicações de terceiros e a CSVM ocorre em sua totalidade nos dispositivos
móveis. Assim, desenvolvedores devem se preocupar apenas em projetar aplicações que
se comuniquem com a interface externa provida pela camada de aplicação e descrevam
mensagens utilizando a CSML ou outra linguagem reconhecida pela plataforma. Neste
sentido, a principal diferença com o Vita está relacionada à comunicação com o provedor
de serviço, onde na CSVM é realizada unicamente através de suas partes: CSVM4Dev e
CSVMProvider.
O controle e tratamento de falhas é uma das principais preocupações relacionadas a ambientes de CrowdSensing móvel. Neste cenário, as falhas podem ser caracterizadas, por exemplo, pela saída do dispositivo de uma determinada área monitorada, bateria
descarregada e perda na conexão. No Vita esta preocupação está refletida na implementação do Service State Synchronization Mechanism (S3M), projetado para detectar e se
recuperar de possíveis falhas no dispositivo móvel. Este mecanismo limita-se ao tratamento de falha por indisponibilidade de serviço, utilizando Redes de Petri e a Linguagem
de Execução de Processos de Negócio (BPEL).
Neste trabalho optamos por uma abordagem diferente, onde a falha ocasionada
pela indisponibilidade de serviço do dispositivo móvel é detectada pelo provedor de serviço. Esta funcionalidade está implementada na camada de broker da CSVMProvider,
mais especificamente pelo componente StateManager, que gerencia os estados do dispositivo, a fim de identificar se o mesmo está disponível ou não. Ele possui um timer configurado (com um tempo estimado de 15 minutos) que determina de quanto em quanto
tempo o provedor enviará uma requisição para controle. O provedor envia a requisição
aos dispositivos que estão envolvidos em uma consulta de CrowdSensing e aguarda uma
resposta para atualizar e reconfigurar o modelo da consulta quando necessário.
Em relação à saída do dispositivo de uma determinada região monitorada,
repassamos esta responsábilidade ao proprietário do dispositivo. Assim sendo, faz-se
necessário que a cada alteração de localização o usuário informe manualmente sua nova
localização (por meio da interface gráfica da CSVM4Dev).
Referente aos elementos que participam de uma aplicação de CrowdSensing móvel, eles são em sua maioria representados por dispositivos móveis com recursos limitados
de energia, memória e processamento. Vita introduz um novo mecanismo de otimização
7.1 CrowdSensing Móvel
118
de recursos chamado Application-oriented Service Collaboration Model (ASCM), responsável por alocar tarefas computacionais entre os dispositivos móveis e a plataforma de
computação em nuvem de maneira eficiente e eficaz. Para otimizar esta alocação de tarefas o ASCM possui uma ferramenta chamada social vector, que é composto por vários
atributos representando informações do usuário e recursos computacionais disponíveis,
sendo os principais: atributos sociais contínuos, que inclui poder computacional, tempo
restante da bateria e capacidade de comunicação; atributos sociais discretos, que inclui o
número de tarefas similares executadas e o número de tarefas remanescentes. Para obter o
resultado desejado, Vita adota duas técnicas computacionais: Algoritmos genéticos [37]
e K-means [32].
Nossa proposta não prevê uma alocação inteligente de recursos como em Vita.
Optamos por realizar tal procedimento de maneira simples, realizando a primeira seleção
dos dispositivos com base na localização e em seguida selecionando-os de acordo com os
sensores compartilhados, visando atender à requisição de uma determinada aplicação de
CrowdSensig.
7.1.3
MobIoT
Uma característica desejável a todas plataformas e aplicações de CrowdSensing
móvel refere-se à escalabilidade. Neste sentido, o trabalho de Hachem et al apresenta
MobIoT [26], um middleware orientado a serviços que pemrite a detecção móvel participativa (ou, CrowdSensing móvel) em larga escala. Um dos fatores que contribui para o
alcance da escalabilidade proposta por Hachem et al é a limitação da participação de dispositivos (sensores) considerados redundantes. A redundância é caracterizada por dados
similares enviados por mais de um sensor, que além de não beneficiar a qualidade de detecção, aumenta a comunicação e o consumo de energia. A estratégia empregada na construção deste middleware para limitar o número de dispositivos participantes concentrase nas características de mobilidades dos dispositivos que satisfazem uma cobertura de
monitoramento. Esta cobertura refere-se à área geográfica abrangida pela aplicação de
CrowdSensing. Portanto, para cada dispositivo registrado, faz-se necessário uma análise
para estimar o deslocamento desses dispositivos. Neste sentido, a complexidade do sistema aumenta linearmente conforme a quantidade de dispositivos registrados.
A escalabilidade não é um dos principais alvos do nosso trabalho, mas entendemos que esta característica é de extrema importância para o bom funcionamento das
aplicações de CrowdSensing.
As principais semelhanças entre o MobIoT e nosso trabalho estão relacionadas
à arquitetura (Figura 7.3) e implementação, onde alguns elementos e funcionalidades
podem ser facilmente mapeadas de um modelo para o outro. Tanto a arquitetura do
7.1 CrowdSensing Móvel
119
MobIoT quanto da CSVM, são dividas em duas etapas: o registro de dispositivos e a
especificação de consultas. Em relação à implementação, ambos utilizam um webservice
RESTful para comunicação com os dispositivos móveis.
Figura 7.3: Arquitetura do MobIoT [26].
Entre as principais contribuições do trabalho de Hachem et al destacam-se:
• O projeto e análise de uma abordagem de registro determinística
• A modelagem matemática, projeto e análise de uma abordagem de registro probabilística, introduzida em [25].
As principais contribuições estão diretamente relacionadas à decisão de registro
dos serviços de sensoriamento dos dispositivos e tem como principal finalidade garantir
a escalabilidade da solução. O que as diferencia é o processamento que antecede a tomada de decisão, determinando se um dispositivo deve ou não se registrar. Na abordagem
determinística a decisão é tomada com base no conhecimento exato dos caminhos dos
dispositivos registrados, o que resulta em uma decisão precisa, porém com uma complexidade de tempo adicional. Em contrapartida, a abordagem apresentada por Hachem et
al em [25], utiliza modelos de mobilidade probabilísticos para estimar a movimentação
dos dispositivos a fim de acelerar a fase de pesquisa do algoritmo. O conhecimento gerado nessa abordagem pode ser então explorado por um novo dispositivo para auxiliá-lo
a decidir se deve ou não registrar seus serviços.
Nosso trabalho não emprega nenhuma estratégia para o controle de registro dos
dispositivos, podendo todos se registrarem na plataforma proposta. Esta decisão está
diretamente embasada pelo fato de que a cada consulta gerada todo o processamento
(desde o recrutamento até a reposta da consulta) é realizado em tempo real, em outras
palavras, no momento para o qual a consulta foi solicitada os dados serão requeridos.
Desta forma, esta abordagem não realiza uma estimativa de quais dispositivos estarão
7.2 Modelos em Tempo de Execução
120
presentes no local, como no MobIoT. Outra característica obtida através dessa estratégia,
está relacionada ao número de dispositivos registrados, pois a não restrição relacionada ao
registro, possibilita que o ambiente seja composto por mais dispositivos, o que aumenta a
probabilidade de uma consulta ser atendida.
7.2
Modelos em Tempo de Execução
Nesta seção, são apresentados trabalhos que empregam o uso de modelos em
tempo de execução (m@rt) como técnica para solucionar problemas aplicados a diferente
contextos. O uso de modelos em tempo de execução, conforme descrito na Seção 2.2, tem
como intuito prover representações mais apropriadas dos elementos de um sistema. Esta
técnica se aplica a sistemas que precisam ser monitorados, adaptados e evoluídos durante
sua execução. Assim, as seções seguintes apresentam uma comparação, considerando as
principais características que definem a abordagem de m@rt baseada na execução de
modelos, como arquitetura proposta, linguagem de modelagem, restrições e limitações
dos trabalhos.
7.2.1
CVM
O uso de modelos em tempo de execução, se aplica a uma categoria de aplicações
que estão relacionadas ao provimento de serviços a partir de um conjunto heterogêneo
de recursos e se inserem em um cenário dinâmico. A CVM (Communication Virtual
Machine) é apresentada por Clarke et al em [17], como um exemplo de plataforma
para construção e e execução de aplicações que se enquadram nessa categoria, destinada
especificamente à realização de serviços de comunicação.
Uma característica importante de plataforma dirigida por modelos, está relacionada à linguagem de modelagem processada por elas. Neste sentido, a CVM realiza o
processamento de modelos descritos em uma linguagem de modelagem específica para
o domínio de comunicação, denominada Linguagem de Modelagem de Comunicação
(Communication Modeling Language, CML) [15]. A CML é linguagem declarativa, que
permite descrever os participantes, dados, e tipos de mídia envolvidos em uma comunicação. Informações associadas às tecnologias e dispositivos utilizados em uma comunicação, não são descritos em CML.
Outro aspecto apresentado por Clarke et al, se refere a CVM como uma plataforma centrada no usuário devido ao alto nível dos modelos descritos por meio da CML,
que podem ser construídos tanto por usuários especialistas de domínio, quanto por usuários finais.
7.2 Modelos em Tempo de Execução
121
A partir de um modelo CML, a CVM é capaz de realizar serviços de comunicação de forma automática, sem a necessidade de intervenção do usuário. Além disso, um
modelo descrito em CML pode ser modificado ao longo de uma comunicação, sendo a
CVM capaz de identificar essas mudanças e adaptar a comunicação em andamento para
atender aos novos requisitos. Isso qualifica os modelos em CML como modelos de tempo
de execução [8].
A CVM conta com uma arquitetura organizada em camadas que possuem responsabilidades bem definidas e encapsulam as principais funcionalidades envolvidas na
realização da comunicação.Essas camadas são divididas em quatro: interface de comunicação com o usuário, mecanismo de síntese, middleware de comunicação e intermediador
de comunicação em rede.
A CVM emprega dois importantes conceitos relacionados à capacidade autogerenciáveis: computação autônoma para construção de sistemas auto-gerenciáveis e uso
de políticas para guiar o gerenciamento de sistemas.
O trabalho proposto apresenta diversas similaridades com a CVM, contudo sua
principal diferença além do domínio de aplicação, está no projeto arquitetural da CSVM.
Apesar de sua estrutura em camadas e algumas funcionalidades serem semelhantes à
CVM, a CSVM apresenta duas configurações distintas que são executadas parte em um
dispositivo móvel e parte em um servidor. Desta forma, sua estrutura em camadas deve ser
modificada para atender as limitações e funcionalidades imposta por cada componente.
Assim como na CVM, os modelos descritos por meio da CSVM possibilita que
consultas de crowdsensing sejam facilmente especificadas tanto por usuários especialista
quanto “leigos” em relação ao domínio, devido ao alto nível exigido pela linguagem. Uma
vez especificado uma consulta de crowdsensing, os serviços realizados pela CSVM são
automáticos, não necessitando da intervenção do usuário, como por exemplo, aceitar uma
requisição.
Em relação alterações realizadas em tempo de execução, a CSVM possui um
recurso similar ao apresentado pela CVM, onde as alterações em uma aplicação de
crowdsensing são identificadas pela plataforma, seja por intervenção direta do usuário
ou por meio do monitoramento da aplicação realizado pela CSVM. Após identificado
essas mudanças, a CSVM é capaz de adaptar a aplicação em andamento para atender a
nova configuração do ambiente.
7.2.2
MGridVM
Allison et al, apresentam em [3], a Máquina Virtual de Redes Elétricas Locais
(Microgrid Virtual Machine, MGridVM), uma solução dirigida por modelos para o gerenciamento de microgrids inspirada na CVM. A MGridVM emprega a mesma estratégia
7.2 Modelos em Tempo de Execução
122
da CVM, onde sua arquitetura é organizada em quatro camadas para uma máquina que
executa modelos de microgrid criados pelos usuários. Assim como na CVM, cada camada
possui funções bem definidas e são dividas em: interface do usuário, síntese, middleware
e broker.
Allison et al propõem o uso da MGridVM para possibilitar a construção de aplicações de gerenciamento dos elementos de uma rede elétrica inteligente. Desta forma, foi
apresentado a Linguagem de Modelagem de Redes Elétricas Locais (Microgrid Modeling
Language, MGridML) [4]. Ela possibilita ao usuário criar modelos que descrevem fontes
e cargas de energia em uma microgrid. Um modelo construído a partir da MGridML, é
composto por dois esquemas: esquema de controle e esquema de dados.
O esquema de controle específica a configuração lógica da microgrid. O esquema
de dados, específica as instâncias dos tipos de elementos definidos no esquema de
controle, e assim representa um dispositivo físico em uma microgrid.
Em relação ao uso de políticas para determinar o funcionamento do sistema, a
MGridML permite a atribuição de políticas aos esquemas. Neste contexto, uma política
consiste em um tripa "evento-condição-ação", que possibilita que regras ou restrições
sejam adicionadas na forma de comportamento do modelo.
A arquitetura da CSVM é semelhante a arquitetura da MGridVM e suas diferenças, assim como comparada à CVM, está na arquitetura distribuído presente na CSVM,
onde parte da plataforma executará no dispositivo móvel e outra parte no servidor. Desta
forma, as camadas presentes no servidor são: camada de síntese, camada de middleware
e camada de broker. Enquanto as camadas presentes no dispositivos móveis são: camada
de aplicação, camada de síntese, camada de middleware e camada de broker.
Em relação aos modelos descritos em MGridML, a CSML permite também descrever modelos compostos por esquema de controle e esquema de dados, porém apresenta uma definição diferente a cerca desses esquemas. Um esquema de controle descrito
em CSML pode ser subdivido em dois: esquema de controle do ambiente e esquema de
controle da consulta. O esquema de controle do ambiente representa a configuração do
ambiente definindo quais os tipos de dispositivos, tipos de sensores e tipos de operações
são suportados pela plataforma. O esquema de controle da consulta por sua vez, define
os elementos de uma consulta de crowdsensing especificada pelo usuário ou aplicação.
Por fim, o esquema de dados representa uma instância da consulta, informando quais os
dados referente a um tipo de sensor o dispositivo recrutado (participante da consulta) deve
monitorar.
A CSML não apresenta um tratamento de políticas conforme presente na
MGridVM. O comportamento do modelo também é determinado por regras e políticas,
porém são implementas diretamente na CSVM, e a adição de novas regras devem ser feitas a nível de código, diferentemente da MGridVM que permite a adição de novas regras
7.3 Conclusão
123
na forma de comportamento.
7.3
Conclusão
Neste capítulo apresentamos os principais trabalhos relacionados tanto ao
domínio/problema-alvo de crowdsensing móvel quanto ao uso da abordagem/técnica dirigida por modelos em tempo de execução. A primeira categoria de trabalhos relacionados,
ou seja, direcionados à crowdsensing móvel, as principais características investigadas e
comparadas foram: a utilização de uma arquitetura particionada/distribuída; a definição
de uma linguagem de alto nível e específica de domínio; os aspectos e a forma de intervenção do usuário durante o processamento de uma consulta para autorizar o acesso ao
dispositivo e o envio de informação, sendo obrigatória ou não; os protocolos de comunicação utilizados (por exemplo SMS, C2DM e GCM); a utilização de serviços RESTFul;
a incorporação de uma API para apoiar o desenvolvimento de aplicações por terceiros;
a forma de controle e tratamento de falhas; a utilização de métodos para otimização de
recursos; e técnicas que visam a escalabilidade.
Em relação a segunda categoria de trabalhos relacionados, ou seja, que utilizam
uma abordagem dirigida por modelos em tempo de execução, as características analisadas
foram: o emprego de uma plataforma para construção e execução de aplicações de acordo
com um domínio específico; a definição de uma linguagem de modelagem específica de
domínio; a utilização de técnicas para tratamento de modelos em tempo de execução; o
uso de uma arquitetura em camadas; utilização de abordagens de computação autônoma;
emprego de sistemas auto-gerenciáveis; a representação de modelos por meio de esquemas; e por fim, o uso de políticas.
Desta forma, foi realizado uma comparação sistemática dos trabalhos apresentados neste capítulo em concordância com as características descristas a fim de posicionar
este trabalho em relação aos demais e mostrar seu diferencial e suas limitações..
CAPÍTULO 8
Conclusão
Diante da complexidade inerente às aplicações de crowdsensing móvel, devido
a fatores como ubiquidade, interoperabilidade entre diferentes dispositivos móveis, identificação e captação de dados provenientes desses dispositivos e adaptação de seu uso em
ambientes heterogêneos e dinâmicos, a adoção de uma abordagem dirigida por modelos se
mostra eficiente uma vez que reduz essa complexidade por meio do emprego de técnicas
de modelagem que diminui de forma substancial a distância semântica entre o problema
a ser resolvido e a plataforma utilizada. Desta forma, a abordagem dirigida por modelos
promove o uso de abstrações mais próximas ao domínio do problema.
Neste trabalho, foi apresentada uma abordagem dirigida por modelos para definição de uma linguagem de modelagem específica para o domínio de crowdsensing (CSML)
que permite descrever e modelar as principais funcionalidades de crowdsensing móvel:
registro de dispositivos e especificação de consultas. A construção da CSML foi pautada
em quatro principais requisitos, determinados por seu domínio de aplicação: simplicidade,
interoperabilidade, expressividade e flexibilidade. A partir dessa definição, propusemos a
criação de um metamodelo para CSML capaz de capturar as principais características das
aplicações de crowdsensing móvel, e em conformidade com esse metamodelo a descrição
de modelos apresentados neste trabalho como esquemas de controle e esquemas de dados.
Para a execução de modelos descritos em CSML e que podem ser criados e
modificados em tempo de execução, este trabalho propõe, a partir de uma arquitetura
genérica para máquinas de execução de modelos (discutida na Seção 2.2), o uso de
uma especialização dessa máquina específica para o domínio de crowdsensing móvel,
denominada CSVM. Assim como a arquitetura genérica, a CSVM apresenta camadas
bem definidas que neste trabalho foram descritas por meio de modelos que expressam as
atribuições de cada uma.
Para manter conformidade com o domínio, de modo geral a CSVM inclui serviços e operações para processamento de modelos que envolvem: detecção e recrutamento
de recursos (dispositivos), gerenciamento de recursos heterogêneos (unidades de sensoriamento), manutenção de um esquema de controle do ambiente contendo os dispositivos
registrados e relações/operações matemáticas aplicadas a diferentes unidades. Seguindo
8.1 Trabalhos futuros
125
essa abordagem, este trabalho propõe uma arquitetura estruturada em duas partes: central
(CSVMProvider), representada por um provedor de serviço e distribuída (CSVM4Dev),
presente nos dispositivos móveis.
De modo geral, entre as contribuições deste trabalho, podemos destacar a utilização de uma abordagem dirigida por modelos em tempo de execução para criação e
processamento de aplicações de crowdsensing móvel. Neste contexto, modelos não são
usados apenas para expressarem consultas de crowdsensing, mas também como forma de
manter uma representação atualizada da consulta em execução.
A abordagem proposta neste trabalho também apresenta algumas limitações.
Apesar de propor uma linguagem de modelagem específica para o domínio de crowdsensing apresentando seu metamodelo por meio de sua sintaxe abstrata, o presente trabalho
não formaliza sua semântica estática. Outra limitação se refere aos aspectos de segurança
e privacidade, ainda que a arquitetura proposta expõe a necessidade de tratar tais aspectos,
eles não foram explorados neste trabalho. Desta forma, a implementação da CSVM não
incorpora aspectos de segurança e privacidade.
Por fim, o presente trabalho propõe uma abordagem dirigida por modelos que
permite criação e processamento de uma variedade de aplicações pertencentes ao domínio
de crowdsensing móvel compreendendo um conjunto de dispositivos heterogêneos. Essa
abordagem possibilita, por meio da CSML, modelar a maioria dos cenários de crowdsensing móvel e reconfigurar consultas mediante alteração do ambiente e/ou intenção
do usuário. Esses comportamentos forma comprovados por meio do cenário apresentado
como estudo de caso deste trabalho.
8.1
Trabalhos futuros
Nesta seção apresentamos as áreas que não foram cobertas por este trabalho
e necessitam de investigação. Como trabalho futuro, planejamos estender a plataforma
para que ela possa permitir o processamento de políticas, principalmente relacionadas
a segurança e privacidade. Nesse sentido, desejamos evoluir a CSVM para permitir o
gerenciamento dinâmico de políticas, possibilitando sua adição e manutenção.
Outra proposta de trabalho futuro, está relacionado a localização dos dispositivos
que apesar de ser informada pelos dispositivos de forma lógica, apresenta pouca precisão
quanto a sua real localização. Uma possível solução nessa direção é a utilização de
um sistema de localização indoor a ser mantido na CSVMProvider, ou a utilização das
coordenadas reais de sua localização obtidas pelo sensor de geolocalização (GPS).
Apesar do algoritmo de seleção de dispositivos proposto neste trabalho atender
às consultas especificadas com agilidade, pretendemos evolui-lo em relação à precisão
dos dados monitorados e ampliação da cobertura do ambiente. Assim, um possível
8.1 Trabalhos futuros
126
comportamento do algoritmo seria: selecionar o menor número de dispositivos que atenda
uma determinada consulta a fim de cobrir em sua totalidade o ambiente a ser monitorado.
Nesse sentido, o tempo de seleção do dispositivo aumentaria, em contrapartida obteríamos
uma otimização no uso de recursos e consequentemente no uso da infraestrutura de
comunicação, utilizada para troca de mensagens entre os dispositivos e o servidor.
Nessa direção e abordando principalmente o problema da cobertura, ou seja,
obter uma cobertura grande do ambiente monitorado sem utilizar uma grande quantidade
de dispositivos, uma possível solução seria aplicar a abordagem apresentada por Hachem
et al em [26], que se concentra em modelos de mobilidade probabilísticos para estimar
a movimentação dos dispositivos que satisfaçam uma cobertura de monitoramento e
limitar assim o número de registros de dispositivos. Desta forma, podemos alcançar uma
escalabilidade melhor da plataforma.
Além disso, como a mobilidade é um fator crítico em ambientes de crowdsensing
móvel, planejamos adicionar á camada de broker da CSVMProvider um comportamento
para permitir que um dispositivo participante de uma consulta, ao desconectar de uma
rede e se conectar em outra, possa manter sua conexão à plataforma e continuar o
monitoramento. Para isso, é importante que seja estabelecido um timer, a fim de manter
“aceitável” o desempenho do processamento da consulta. A escolha desse timer deve ser
estabelecida de forma que o seu valor seja menor que o tempo de seleção de um novo
dispositivo.
Em relação a implementação, planejamos melhorar o desempenho no gerenciamento do banco de dados realizado pelo hibernate por meio da utilização de técnicas
de tunning que altera sua configuração padrão e permite otimizar seu comportamento
principalmente em relação ao gerenciamento de seções abertas com o banco de dados. A
aplicação dessa técnica é precedida por uma análise minuciosa tanto do comportamento
do hibernate ao gerar instruções, quanto do comportamento do MySQL ao processá-las.
Desta forma, podemos obter uma redução no tempo de acesso ao banco de dados e na
aplicação de operações CRUD.
Contudo, primeiramente desejamos avaliar a aplicação da abordagem proposta
em um ambiente de crowdsensing real com o intuito de alcançar uma melhor compreensão
de sua aplicabilidade. Assim, planejamos realizar testes de desempenho em ambientes
reais e altamente dinâmicos além de realizar uma avaliação quanto a usabilidade da
plataforma.
Referências Bibliográficas
[1] A FREEN , S.; A BID, K. A novel approach on applications, research challenges
and mining for mobile crowdsensing. International Journal of Advanced Trends in
Computer Science and Engineering, 2(1):75–80, 2013.
[2] A LAM , S.; C HOWDHURY, M. M.; N OLL , J.
Senaas: An event-driven sensor
virtualization approach for internet of things cloud. In: Networked Embedded
Systems for Enterprise Applications (NESEA), 2010 IEEE International Conference
on, p. 1–6. IEEE, 2010.
[3] A LLISON , M.; A LLEN , A. A.; YANG , Z.; C LARKE , P. J. A software engineering
approach to user-driven control of the microgrid. In: SEKE, p. 59–64, 2011.
[4] A LLISON , M.; M ORRIS , K. A.; YANG , Z.; C LARKE , P. J.; C OSTA , F. M. Towards Reliable Smart Microgrid Behavior Using Runtime Model Synthesis. In: 2012 IEEE
14th International Symposium on High-Assurance Systems Engineering, número Cm,
p. 185–192. IEEE, Oct. 2012.
[5] ATZORI , L.; I ERA , A.; M ORABITO, G. The internet of things: A survey. Computer
Networks, 54(15):2787–2805, 2010.
[6] B AUER , C.; K ING , G. Java Persistance with Hibernate. Dreamtech Press, 2006.
[7] B ÉZIVIN , J. Model driven engineering: An emerging technical space. In: Generative and transformational techniques in software engineering, p. 36–64. Springer,
2006.
[8] B LAIR , G.; B ENCOMO, N.; F RANCE , R. B.
Models@ run. time.
Computer,
42(10):22–27, 2009.
[9] B RYANT, B. R.; G RAY, J.; M ERNIK , M.; C LARKE , P. J.; F RANCE , R. B.; K ARSAI , G.
Challenges and directions in formalizing the semantics of modeling languages.
Computer Science and Information Systems/ComSIS, 8(2):225–253, 2011.
Referências Bibliográficas
128
[10] B URKE , J. A.; E STRIN , D.; H ANSEN , M.; PARKER , A.; R AMANATHAN , N.; R EDDY, S.;
S RIVASTAVA , M. B. Participatory sensing. Center for Embedded Network Sensing,
2006.
[11] C HEN , K.; S ZTIPANOVITS , J.; N EEMA , S. Toward a semantic anchoring infrastructure for domain- specific modeling languages. In: Proceedings of the 5th
ACM international conference on Embedded software, p. 35–43. ACM, 2005.
[12] C HON , Y.; L ANE , N. D.; L I , F.; C HA , H.; Z HAO, F. Automatically characterizing
places with opportunistic crowdsensing using smartphones. In: Proceedings of
the 2012 ACM Conference on Ubiquitous Computing, p. 481–490. ACM, 2012.
[13] C HUI , M.; L ÖFFLER , M.; R OBERTS , R. The internet of things. McKinsey Quarterly,
2:1–9, 2010.
[14] C LARK , T.; S AMMUT, P.; W ILLANS , J. Applied metamodelling: a foundation for
language driven development. 2008.
[15] C LARKE , P. J.; H RISTIDIS , V.; WANG , Y.; P RABAKAR , N.; D ENG , Y. A declarative
approach for specifying user-centric communication. In: Collaborative Technologies and Systems, 2006. CTS 2006. International Symposium on, p. 89–98. IEEE,
2006.
[16] DE P ROJETO, P. O modelo mvc-model view controller, 2008.
[17] D ENG , Y.; M ASOUD S ADJADI , S.; C LARKE , P. J.; H RISTIDIS , V.; R ANGASWAMI ,
R.; WANG , Y. Cvm–a communication virtual machine. Journal of Systems and
Software, 81(10):1640–1662, 2008.
[18] D ERLER , P.; L EE , E. A.; V INCENTELLI , A. S. Modeling cyber–physical systems.
Proceedings of the IEEE, 100(1):13–28, 2012.
[19] E STRIN , D. Participatory sensing: applications and architecture [internet predictions]. Internet Computing, IEEE, 14(1):12–42, 2010.
[20] F IELDING , R. T.; TAYLOR , R. N. Principled design of the modern web architecture. ACM Transactions on Internet Technology (TOIT), 2(2):115–150, 2002.
[21] F RANCE , R.; RUMPE , B.
Domain specific modeling.
Software and Systems
Modeling, 4(1):1–3, 2005.
[22] F RANCE , R.; RUMPE , B. Model-driven development of complex software: A
research roadmap.
In: 2007 Future of Software Engineering, p. 37–54. IEEE
Computer Society, 2007.
Referências Bibliográficas
129
[23] G ANTI , R. K.; Y E , F.; L EI , H. Mobile crowdsensing: Current state and future
challenges. Communications Magazine, IEEE, 49(11):32–39, 2011.
[24] G UINARD, D.; T RIFA , V. Towards the web of things: Web mashups for embedded
devices. In: Workshop on Mashups, Enterprise Mashups and Lightweight Composition on the Web (MEM 2009), in proceedings of WWW (International World Wide
Web Conferences), Madrid, Spain, 2009.
[25] H ACHEM , S.; PATHAK , A.; I SSARNY, V. Probabilistic registration for large-scale
mobile participatory sensing.
In: Pervasive Computing and Communications
(PerCom), 2013 IEEE International Conference on, p. 132–140. IEEE, 2013.
[26] H ACHEM , S.; PATHAK , A.; I SSARNY, V. Service-oriented middleware for largescale mobile participatory sensing. Pervasive and Mobile Computing, 10:66–82,
2014.
[27] H ADLEY, M.; S ANDOZ , P.
Jax-rs: Java api for restful web services.
Java
Specification Request (JSR), 311, 2008.
[28] H U, X.; C HU, T. H.; C HAN , H. C.; L EUNG , V. C. Vita: A crowdsensing-oriented
mobile cyber physical system. 2013.
[29] H UI , J.; C ULLER , D.; C HAKRABARTI , S. 6lowpan: Incorporating ieee 802.15. 4
into the ip architecture–internet protocol for smart objects (ipso) alliance, white
paper# 3, january 2009, 2009.
[30] J AYARAMAN , P. P.; S INHA , A.; S HERCHAN , W.; K RISHNASWAMY, S.; Z ASLAVSKY, A.;
H AGHIGHI , P. D.; L OKE , S.; D O, M. T. Here-n-now: A framework for context-aware
mobile crowdsensing. In: Proc. of the Tenth International Conference on Pervasive
Computing, 2012.
[31] JB OSS G ROUP . Hibernate. http://hibernate.org/. Acessado em fevereiro de
2014.
[32] K ANUNGO, T.; M OUNT, D. M.; N ETANYAHU, N. S.; P IATKO, C. D.; S ILVERMAN , R.;
W U, A. Y. An efficient k-means clustering algorithm: Analysis and implementation. Pattern Analysis and Machine Intelligence, IEEE Transactions on, 24(7):881–
892, 2002.
[33] K APADIA , A.; KOTZ , D.; T RIANDOPOULOS , N. Opportunistic sensing: Security
challenges for the new paradigm. In: Communication Systems and Networks and
Workshops, 2009. COMSNETS 2009. First International, p. 1–10. IEEE, 2009.
Referências Bibliográficas
130
[34] K HAN , W. Z.; X IANG , Y.; A ALSALEM , M. Y.; A RSHAD, Q. Mobile phone sensing
systems: A survey. Communications Surveys & Tutorials, IEEE, 15(1):402–427,
2013.
[35] K IRSHIN , A.; D OTAN , D.; H ARTMAN , A. A uml simulator based on a generic model
execution engine. In: MoDELS Workshops, volume 4364, p. 324–326, 2006.
[36] K LYNE , G.; C ARROLL , J. J. Resource description framework (rdf): Concepts and
abstract syntax. 2006.
[37] KOZA , J. R. Genetic programming: on the programming of computers by means
of natural selection, volume 1. MIT press, 1992.
[38] L ANE , N. D.; M ILUZZO, E.; L U, H.; P EEBLES , D.; C HOUDHURY, T.; C AMPBELL , A. T.
A survey of mobile phone sensing. Communications Magazine, IEEE, 48(9):140–
150, 2010.
[39] L EE , G. M.; C RESPI , N. Shaping future service environments with the cloud and
internet of things: networking challenges and service evolution. In: Leveraging
applications of formal methods, verification, and validation, p. 399–410. Springer,
2010.
[40] M ILUZZO, E.; PAPANDREA , M.; L ANE , N. D.; S ARROFF , A. M.; G IORDANO, S.; C AMP BELL ,
A. T. Tapping into the vibe of the city using vibn, a continuous sensing
application for smartphones. In: Proceedings of 1st international symposium on
From digital footprints to social and community intelligence, p. 13–18. ACM, 2011.
[41] M IORANDI , D.; S ICARI , S.; D E P ELLEGRINI , F.; C HLAMTAC, I. Internet of things:
Vision, applications and research challenges. Ad Hoc Networks, 10(7):1497–
1516, 2012.
[42] M OMTCHEV, V.; K IRYAKOV, A. Triple space communication.
[43] O MG , Q. Meta object facility (mof) 2.0 query/view/transformation specification.
Final Adopted Specification (November 2005), 2008.
[44] O RACLE C ORPORATION .
Jersey - RESTful Web Services in Java.
https:
//jersey.java.net/index.html. Acessado em fevereiro de 2014.
[45] O RACLE C ORPORATION . MySQL. http://www.mysql.com/. Acessado em fevereiro de 2014.
[46] OWENS , M.; A LLEN , G. The definitive guide to SQLite, volume 1. Springer, 2006.
Referências Bibliográficas
131
[47] PARWEKAR , P. From internet of things towards cloud of things. In: Computer
and Communication Technology (ICCCT), 2011 2nd International Conference on, p.
329–333. IEEE, 2011.
[48] PAUTASSO, C.; Z IMMERMANN , O.; L EYMANN , F. Restful web services vs. big’web
services: making the right architectural decision. In: Proceedings of the 17th
international conference on World Wide Web, p. 805–814. ACM, 2008.
[49] P RESSER , M.; G LUHAK , A. The internet of things: Connecting the real world with
the digital world. EURESCOM mess@ ge–The Magazine for Telecom Insiders, 2,
2009.
[50] R A , M.-R.; L IU, B.; L A P ORTA , T. F.; G OVINDAN , R. Medusa: A programming framework for crowd-sensing applications. In: Proceedings of the 10th international
conference on Mobile systems, applications, and services, p. 337–350. ACM, 2012.
[51] R ICHARDSON , L.; RUBY, S. RESTful web services. O’Reilly Media, Inc., 2008.
[52] R IEHLE , D.; F RALEIGH , S.; B UCKA -L ASSEN , D.; O MOROGBE , N. The architecture
of a uml virtual machine. ACM SIGPLAN Notices, 36(11):327–341, 2001.
[53] R ODRIGUES , T. C.; DANTAS , P. V.; D ELICATO, F. C.; P IRES , P. D. F.; M ICELI , C.;
P IRMEZ , L. Using mda for building wireless sensor network applications. 4th
Brazilian Symposium on Software Components, Architectures and Reuse (SBCARS
2010), 2010.
[54] S EIDEWITZ , E. What models mean. Software, IEEE, 20(5):26–32, 2003.
[55] S ELIC, B.
The pragmatics of model-driven development.
Software, IEEE,
20(5):19–25, 2003.
[56] S HERCHAN , W.; J AYARAMAN , P. P.; K RISHNASWAMY, S.; Z ASLAVSKY, A.; L OKE ,
S.; S INHA , A. Using on-the-move mining for mobile crowdsensing. In: Mobile
Data Management (MDM), 2012 IEEE 13th International Conference on, p. 115–124.
IEEE, 2012.
[57] S OLEY, R.; OTHERS . Model driven architecture. OMG white paper, 308:308, 2000.
[58] S OUSA , G. Desenvolvimento de Máquinas de Execução para Linguagens de
Modelagem Específicas de Domínio: Uma Estratégia Baseada em Engenharia
Dirigida por Modelos. Mestrado em ciência da computação, Universidade Federal
de Goiás, 2012.
Referências Bibliográficas
132
[59] SQL ITE C ONSORTIUM . SQLite. http://www.sqlite.org/. Acessado em fevereiro
de 2014.
[60] S TAHL , T.; VÖLTER , M. Model-Driven Software Development: Technology, Engineering, Management. Wiley, 1 edition, 2006.
[61] S TIRBU, V. Towards a restful plug and play experience in the web of things.
In: Semantic computing, 2008 IEEE international conference on, p. 512–517. IEEE,
2008.
[62] S UN , J. Incentive mechanisms for mobile crowd sensing: Current states and
challenges of work. arXiv preprint arXiv:1310.8364, 2013.
[63] T HE A PACHE S OFTWARE F OUNDATION . Apache Tomcat. http://tomcat.apache.
org/. Acessado em outubro de 2013.
[64] T HOMPSON , C.; W HITE , J.; D OUGHERTY, B.; S CHMIDT, D. C. Optimizing mobile
application performance with model–driven engineering. In: Software Technologies for Embedded and Ubiquitous Systems, p. 36–46. Springer, 2009.
[65] TOMA , I.; S IMPERL , E.; H ENCH , G. A joint roadmap for semantic technologies
and the internet of things. In: Proceedings of the 3rd STI Roadmapping Workshop,
2009.
[66] WANG , Y.; C LARKE , P. J.; W U, Y.; A LLEN , A.; D ENG , Y. Runtime models to support
user-centric communication. Models@runtime Workshop in conjunction Models,
2008.
[67] W U, Y.; A LLEN , A.; H ERNANDEZ , F. A user-centric communication middleware
for cvm. 12th Software Engineering and Applications, p. 210–215, 2008.
[68] W U, Y.; A LLEN , A. A.; H ERNANDEZ , F.; F RANCE , R.; C LARKE , P. J. A domainspecific modeling approach to realizing user-centric communication. Software:
Practice and Experience, 42(3):357–390, Mar. 2012.
[69] X IAO, Y.; S IMOENS , P.; P ILLAI , P.; H A , K.; S ATYANARAYANAN , M. Lowering the barriers to large-scale mobile crowdsensing. In: Proceedings of the 14th Workshop
on Mobile Computing Systems and Applications, p. 9. ACM, 2013.
[70] YAN , T.; M ARZILLI , M.; H OLMES , R.; G ANESAN , D.; C ORNER , M.
mcrowd: a
platform for mobile crowdsourcing. In: Proceedings of the 7th ACM Conference
on Embedded Networked Sensor Systems, p. 347–348. ACM, 2009.
APÊNDICE A
Esquemas do Cenário
Neste apêndice são apresentados os modelos (esquema de controle e/ou esquema
de dados) utilizados para exemplificar o cenário descritos no Capítulo 1. Os modelos
são descritos em X-CSML e são versões completas de seus equivalentes apresentados no
Capítulo 3.
Listing A.1: Instância do esquema de controle da consulta descrita
em X-CSML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<? xml v e r s i o n = " 1 . 0 " e n c o d i n g = "UTF−8" ? >
<xcsml>
<controlSchema>
<queryControlSchema>
< s u b s c r i p t i o n s u b s c r i p t i o n I D ="1">
<aggregation />
<sensorTypeRequest id ="1">
<type>temperature </ type>
< q u a n t i t y >10< / q u a n t i t y >
< l o c a t i o n > b o a t e x< / l o c a t i o n >
< o p e r a t i o n > avg < / o p e r a t i o n >
< r e q u e s t >onDemand< / r e q u e s t >
< device id ="1">
<type>
< b r a n d >Samsung< / b r a n d >
<model > G a l a x y S5< / model >
</ type>
<owner > J o h n < / owner >
</ device>
< device id ="2">
<type>
< b r a n d >LG< / b r a n d >
<model >Nexus 5< / model >
</ type>
<owner >Mary< / owner >
</ device>
< device id ="3">
Apêndice A
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
134
<type>
< b r a n d >Sony< / b r a n d >
<model > X p e r i a Z2< / model >
</ type>
<owner > P a u l < / owner >
</ device>
< device id ="4">
<type>
< b r a n d >Samsung< / b r a n d >
<model > G a l a x y S3< / model >
</ type>
<owner >Ana< / owner >
</ device>
< device id ="5">
<type>
< b r a n d >Samsung< / b r a n d >
<model > G a l a x y S4< / model >
</ type>
<owner > J o s e p h < / owner >
</ device>
< device id ="6">
<type>
< b r a n d >Samsung< / b r a n d >
<model > G a l a x y Note 3< / model >
</ type>
<owner > L o r e n < / owner >
</ device>
< device id ="7">
<type>
< b r a n d >Samsung< / b r a n d >
<model > G a l a x y S5< / model >
</ type>
<owner > M i c h a e l < / owner >
</ device>
< device id ="8">
<type>
<brand>Motorola< / brand>
<model >Moto G< / model >
</ type>
<owner >Kennedy< / owner >
</ device>
< device id ="9">
<type>
< b r a n d >Sony< / b r a n d >
<model > X p e r i a Z< / model >
</ type>
Apêndice A
74
75
76
77
78
79
80
81
82
83
84
85
86
87
<owner > S t u a r t < / owner >
</ device>
< d e v i c e i d = " 10 " >
<type>
< b r a n d >LG< / b r a n d >
<model >Nexus 4< / model >
</ type>
<owner > S t e v e < / owner >
</ device>
< / sensorTypeRequest>
</ subscription>
< / queryControlSchema>
< / controlSchema>
< / xcsml>
135
APÊNDICE B
Modelos do Estudo de Caso
Neste apêndice apresentamos os modelos, descritos em X-CSML, utilizados na
implementação do cenário descrito no Capítulo 6.
Listing B.1: Instância do esquema de controle da consulta descrita
em X-CSML para o problema 3 do estudo de caso
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
<? xml v e r s i o n = " 1 . 0 " e n c o d i n g = "UTF−8" ? >
<xcsml>
<controlSchema>
<queryControlSchema>
< s u b s c r i p t i o n s u b s c r i p t i o n I D ="1">
<aggregation />
<sensorTypeRequest id ="1">
<type>temperature </ type>
< q u a n t i t y >10< / q u a n t i t y >
< l o c a t i o n > b o a t e x< / l o c a t i o n >
< o p e r a t i o n > avg < / o p e r a t i o n >
< r e q u e s t >onDemand< / r e q u e s t >
< device id ="1">
<type>
< b r a n d >Samsung< / b r a n d >
<model > G a l a x y S5< / model >
</ type>
<owner > J o h n < / owner >
</ device>
< device id ="2">
<type>
< b r a n d >LG< / b r a n d >
<model >Nexus 5< / model >
</ type>
<owner >Mary< / owner >
</ device>
< device id ="3">
<type>
< b r a n d >Sony< / b r a n d >
<model > X p e r i a Z2< / model >
Apêndice B
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
137
</ type>
<owner > P a u l < / owner >
</ device>
< device id ="4">
<type>
< b r a n d >Samsung< / b r a n d >
<model > G a l a x y S3< / model >
</ type>
<owner >Ana< / owner >
</ device>
< device id ="5">
<type>
< b r a n d >Samsung< / b r a n d >
<model > G a l a x y S4< / model >
</ type>
<owner > J o s e p h < / owner >
</ device>
< device id ="6">
<type>
< b r a n d >Samsung< / b r a n d >
<model > G a l a x y Note 3< / model >
</ type>
<owner > L o r e n < / owner >
</ device>
< device id ="7">
<type>
< b r a n d >Samsung< / b r a n d >
<model > G a l a x y S5< / model >
</ type>
<owner > M i c h a e l < / owner >
</ device>
< device id ="8">
<type>
<brand>Motorola< / brand>
<model >Moto G< / model >
</ type>
<owner >Kennedy< / owner >
</ device>
< device id ="9">
<type>
< b r a n d >Sony< / b r a n d >
<model > X p e r i a Z< / model >
</ type>
<owner > S t u a r t < / owner >
</ device>
< d e v i c e i d = " 10 " >
Apêndice B
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
138
<type>
< b r a n d >LG< / b r a n d >
<model >Nexus 4< / model >
</ type>
<owner > S t e v e < / owner >
</ device>
< d e v i c e i d = " 11 " >
<type>
< b r a n d >Samsung< / b r a n d >
<model > G a l a x y S5< / model >
</ type>
<owner > P e t e r < / owner >
</ device>
< d e v i c e i d = " 12 " >
<type>
< b r a n d >LG< / b r a n d >
<model >Nexus 5< / model >
</ type>
<owner > George < / owner >
</ device>
< d e v i c e i d = " 13 " >
<type>
< b r a n d >Sony< / b r a n d >
<model > X p e r i a Z2< / model >
</ type>
<owner >Mark< / owner >
</ device>
< d e v i c e i d = " 14 " >
<type>
< b r a n d >Samsung< / b r a n d >
<model > G a l a x y S3< / model >
</ type>
<owner > Samantha < / owner >
</ device>
< d e v i c e i d = " 15 " >
<type>
< b r a n d >Samsung< / b r a n d >
<model > G a l a x y S4< / model >
</ type>
<owner > P h i l i p < / owner >
</ device>
< d e v i c e i d = " 16 " >
<type>
< b r a n d >Samsung< / b r a n d >
<model > G a l a x y Note 3< / model >
</ type>
Apêndice B
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
139
<owner > C r i s t o p h e r < / owner >
</ device>
< d e v i c e i d = " 17 " >
<type>
< b r a n d >Samsung< / b r a n d >
<model > G a l a x y S5< / model >
</ type>
<owner > J o s h < / owner >
</ device>
< d e v i c e i d = " 18 " >
<type>
<brand>Motorola< / brand>
<model >Moto G< / model >
</ type>
<owner > J a n n e t < / owner >
</ device>
< d e v i c e i d = " 19 " >
<type>
< b r a n d >Sony< / b r a n d >
<model > X p e r i a Z< / model >
</ type>
<owner > J e n n i f e r < / owner >
</ device>
< d e v i c e i d = " 20 " >
<type>
< b r a n d >LG< / b r a n d >
<model >Nexus 4< / model >
</ type>
<owner > T a y l o r < / owner >
</ device>
< / sensorTypeRequest>
</ subscription>
< / queryControlSchema>
< / controlSchema>
< / xcsml>
Listing B.2: Esquema de dados descrito em X-CSML para o problema 3 do estudo de caso
1
2
3
4
5
6
7
<? xml v e r s i o n = " 1 . 0 " e n c o d i n g = "UTF−8" ? >
<xcsml>
<dataSchema>
< r e q u e s t requestID = "1">
< q u e r y C o n t r o l S c h e m a I D >1< / q u e r y C o n t r o l S c h e m a I D >
<type> multicast </ type>
< p e r i o d >onDemand< / p e r i o d >
Apêndice B
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
140
< form >
<sensorInformation>
<sensorType>audio< / sensorType>
< v a l u e >< / v a l u e >
< d a t a T y p e >< / d a t a T y p e >
< u n i t >< / u n i t >
< t i m e S t a m p >< / t i m e S t a m p >
< a c c u r a c y >< / a c c u r a c y >
</ sensorInformation>
< / form >
<deviceRequest>
< d e v i c e I D >1< / d e v i c e I D >
< d e v i c e I D >2< / d e v i c e I D >
< d e v i c e I D >3< / d e v i c e I D >
< d e v i c e I D >4< / d e v i c e I D >
< d e v i c e I D >5< / d e v i c e I D >
< d e v i c e I D >6< / d e v i c e I D >
< d e v i c e I D >7< / d e v i c e I D >
< d e v i c e I D >8< / d e v i c e I D >
< d e v i c e I D >9< / d e v i c e I D >
< d e v i c e I D >10< / d e v i c e I D >
< d e v i c e I D >11< / d e v i c e I D >
< d e v i c e I D >12< / d e v i c e I D >
< d e v i c e I D >13< / d e v i c e I D >
< d e v i c e I D >14< / d e v i c e I D >
< d e v i c e I D >15< / d e v i c e I D >
< d e v i c e I D >16< / d e v i c e I D >
< d e v i c e I D >17< / d e v i c e I D >
< d e v i c e I D >18< / d e v i c e I D >
< d e v i c e I D >19< / d e v i c e I D >
< d e v i c e I D >20< / d e v i c e I D >
</ deviceRequest>
</ request>
< / dataSchema>
< / xcsml>