• Nenhum resultado encontrado

5. Avaliação

5.1. Análise da DSL Intermediária Proposta

5.2.1. Análise Comparativa

Esta Seção efetua uma análise comparativa entre LWiSSy e as DSLs propostas por [LOSILLA, 2007] e [SHIMIZU, 2011]. Para realizar esta comparação, o mesmo sistema para RSASF foi modelado com as três DSLs e, por fim, uma análise entre os modelos gerados foi efetuada para avaliar o poder de

97

expressividade das três DSLs com relação à capacidade de otimização (refinamento), separação de interesses (diferentes perfis de desenvolvedor envolvidos), modelagem comportamental e estrutural do sistema, e programação da rede considerando diferentes níveis de granularidade. O sistema modelado pertence ao domínio de AAL (Ambient Assisted Living) [DELICATO, 2009].

Sistemas AAL visam prover suporte não intrusivo às tarefas diárias das pessoas com o objetivo de garantir uma maior qualidade de vida aos indivíduos. A ideia básica é monitorar algumas variáveis presentes tanto no ambiente onde o indivíduo se localiza quanto no próprio indivíduo, a fim de garantir uma assistência rápida, automatizada e eficiente em situações de emergência. Nesse contexto, um cenário baseado em um sistema para detecção de quedas acidentais foi escolhido para a modelagem utilizando as DSLs supramencionadas.

5.2.1.1. Descrição do sistema

O sistema AAL modelado, nomeado Accidental Fall Detection System, monitora um indivíduo e avalia informações coletadas por sensores a fim de analisar variáveis que permitam detectar a ocorrência de uma possível queda. Para que seja possível efetuar esta análise é preciso obter dados a respeito da localização na qual o indivíduo se encontra, dos seus sinais corporais, de movimentos bruscos que ele possa ter realizado e do tempo em que ele permanece em uma mesma posição. Caso uma queda seja detectada, ações como enviar um alerta para o serviço de emergência e iniciar o monitoramento dos sinais vitais são disparadas. A fim de possibilitar a detecção de quedas, o ambiente deve estar equipado com nós sensores capazes de capturar tais informações e com nós atuadores capazes de efetuar uma chamada para o hospital ou um centro de saúde sempre que uma queda ocorrer. Além disso, os nós devem, por exemplo, realizar uma análise dos dados recebidos por meio da execução de algoritmos de processamento de imagem. Considerando tais

98

requisitos, a RSASF para o sistema AAL aqui descrito será composta de um nó sensor (equipado de acelerômetros) presente em um crachá e acoplado ao indivíduo monitorado, três sensores de imagens (câmeras), três nós sensores fixos (equipados com sensores de localização) e vários atuadores com diferentes funções. Com o intuito de analisar os dados obtidos, faz-se necessária a definição de uma estação central que será responsável pelo processamento da informação recebida a fim de detectar a queda.

O sistema de RSASF para o cenário descrito funciona da seguinte maneira. Sensores instalados em uma parede formam a triangulação da posição do indivíduo monitorado utilizando sinais de RSSI (received signal strength

indication) e podem detectar qualquer mudança na posição do mesmo.

Enquanto isso, o nó sensor instalado no crachá detecta movimentos bruscos e determina se o indivíduo está parado ou em movimento. Os dados capturados são então enviados para a central de controle. Se o indivíduo efetuar um movimento atípico, a central envia um sinal para que nós atuadores liguem as câmeras. Feito isto, a central recebe as imagens da sala e efetua um processamento com o objetivo de descobrir se o indivíduo está apenas caminhando ou se ele está em queda. No caso de detecção de queda, a central entra em contato com um hospital ou serviço de emergência através de um nó atuador.

5.2.1.2. Modelagem do sistema utilizando diferentes DSLs

A primeira DSL utilizada para modelagem do sistema descrito foi LWiSSy. No modelo estrutural, definido pelo especialista de domínio (Figura 5-3), o sistema foi dividido em três regiões. A região UserLocationRegion é formada pelos grupos de nós BadgeGroup e MovementGroup, que são responsáveis pela coleta de dados do ambiente e do indivíduo, respectivamente. Por sua vez, a região

UserVideoRegion é composta pelo grupo de nós VideoGroup, o qual gerencia as

câmeras presentes no ambiente. Por fim, a região CentralStationRegion também é composta por apenas um grupo de nós, ProcessingGroup, o qual é responsável

99

pelo processamento dos dados coletados para detecção da queda e gerenciamento dos atuadores presentes na rede. Além disso, ainda foram definidos os tipos de recursos que serão utilizados em cada grupo de nós (movementSensor, positionSensor, etc.), a quantidade de nós presente em cada um dos grupos de nós, as conexões existentes na rede e as aplicações que serão executadas pelo sistema.

Figura 5-3 Modelagem estrutural do sistema Accidental Fall Detection System utilizando a DSL LWiSSy.

Após a definição do modelo estrutural, o especialista de domínio efetuou a modelagem comportamental de cada uma das quatro aplicações que compõem o sistema, a saber, Position Sensing, Movement Sensing, Video Check e Fall

Check.

A aplicação Position Sensing (Figura 5-4) é responsável pela coleta de dados sobre a posição do indivíduo no ambiente monitorado. Esta aplicação é composta por três atividades. Na primeira atividade, ConfigurateRadio, o rádio do nó sensor desta aplicação é configurado. Feito isto, os dados são coletados a partir dos nós sensores instalados no crachá do indivíduo, através da atividade

100

Após a coleta dos dados, estes são enviados a estação central a cada 20 minutos por meio da atividade SendGatheredData. Ao término do envio dos dados, a aplicação voltará a executar a segunda tarefa.

Figura 5-4 Modelagem comportamental da aplicação Position Sensing utilizando a DSL LWiSSy.

A aplicação Movement Sensing (Figura 5-5) é responsável pela coleta de dados sobre a movimentação do indivíduo no ambiente monitorado. Esta aplicação assemelha-se muito com a aplicação Position Sensing uma vez que o fluxo computacional será o mesmo; a única mudança diz respeito aos dados coletados a partir do ambiente. Nesta aplicação os dados são coletados a partir dos nós sensores instalados na parede com o intuito de analisar a movimentação do indivíduo pelo ambiente. Portanto, a única atividade que difere das apresentadas no modelo anterior é a atividade de leitura dos dados dos sensores, a qual neste modelo é nomeada de ReadMovementData e efetua a leitura dos dados dos nós sensores acima descritos.

101

Figura 5-5 Modelagem comportamental da aplicação Movement Sensing utilizando a DSL LWiSSy.

A aplicação Video Check (Figura 5-6), a qual é iniciada a partir de uma solicitação da estação central apenas se uma possibilidade de queda for detectada, liga as câmeras de vídeo e envia as imagens coletadas à estação central. O modelo comportamental desta aplicação é composto por quatro atividades. A primeira atividade, ConfigurateRadio, configura os rádios dos nós presentes na aplicação. Logo após, as imagens coletadas pelas câmeras são lidas pelos nós sensores presentes na rede (atividade ReadCameraData) e enviadas a estação base (atividade SendGatheredData).

Figura 5-6 Modelagem comportamental da aplicação Video Check utilizando a DSL LWiSSy.

A última aplicação a ser modelada é a aplicação Fall Check (Figura 5-7). Esta aplicação deve ser implantada na estação central. Inicialmente, o rádio dos nós pertencentes à aplicação são configurados (atividade ConfigurateRadio). Feito

102

isto, os dados sobre a movimentação e posição do indivíduo no ambiente são

recebidos (atividades ReceiveMovementData e ReceivePostionData,

respectivamente), um processamento a fim de determinar se há possibilidade de queda é efetuado (atividade AnalyzeFall) e, caso haja, as câmeras de vídeo do ambiente são disparadas (atividade TurnOnCameras) e os dados coletados pelas câmeras são recebidos pela estação central (atividade ReceiveCameraData) para que uma nova análise seja efetuada a fim de detectar se realmente ocorreu uma queda (atividade AnalyzeImages). Caso a queda tenha de fato acontecido, a aplicação aciona um hospital ou serviço de emergência (atividade

CallToEmergency), desliga as câmeras (atividade TurnOffCameras), uma vez que

as imagens que registraram a queda já foram obtidas, e aguarda trinta minutos para começar a receber dados do ambiente novamente.

103

Para finalizar a modelagem do sistema AAL com a DSL LWiSSy, o especialista de redes efetuou a modelagem de refinamento do sistema, conforme mostrado na Figura 5-8. Durante esta modelagem, foram definidos a topologia da rede (FLAT) e o protocolo de comunicação utilizado (FLOODING). Além disso, foram determinados quais os tipos de nós sensores utilizados (neste caso, todos os grupos utilizam nós da plataforma Sun SPOT [Sun SPOT, 2012]), bem como os demais protocolos da rede.

Figura 5-8 Modelagem de refinamento do sistema Accident Fall Detection System utilizando a DSL LWiSSy.

A próxima modelagem do sistema AAL que será descrita (Figura 5-9) foi projetada com a DSL proposta por [LOSILLA, 2007]. Assim como ocorre em LWiSSy, a DSL de Losilla é composta pelos elementos região e grupo de nós. Dessa forma, as mesmas regiões que foram definidas com o uso de LWiSSy também foram definidas neste modelo, sendo elas: UserLocationRegion,

UserVideoRegion e CentralStationRegion.

A primeira região a ser descrita será a UserLocationRegion. Ela é composta por dois elementos do tipo NodeGroup: MovementGroup e BadgeGroup. No elemento MovementGroup são definidos dois fluxos comportamentais. O primeiro fluxo executa a coleta de dados acerca dos movimentos efetuados pelo

104

ReadMovementData) e armazena-os em sua memória RAM (Functional Unit StoreRAM1). A inserção de um componente Timer (externally fired) com o range

de 20 minutos indica a inclusão de um timer do tipo one shot neste fluxo, ou seja, este timer será considerado apenas durante a primeira execução do fluxo comportamental. O segundo fluxo modelado neste grupo de nós é responsável por recuperar os dados coletados pelos nós sensores a partir da memória RAM (Functional Unit RetrieveRAM1) e enviá-los a estação central por meio da

Functional Unit SendGatheredData. Assim como no fluxo anterior, um elemento Timer foi definido, mas o timer presente neste fluxo é cíclico e, portanto, sempre

será considerado ao longo da execução deste fluxo.

Figura 5-9 Modelagem do sistema Accidental Fall Detection utilizando a DSL proposta por [LOSILLA, 2007].

O segundo NodeGroup presente nesta região, BadgeGroup, possui fluxos comportamentais semelhantes aos modelados no NodeGroup anterior. No

105

entanto, a variável monitorada por este NodeGroup será a posição do indivíduo no ambiente monitorado. Esta variável será observada através da coleta dos dados dos sensores positionSensor que estão instalados no crachá do indivíduo.

Na região UserVideoRegion apenas um NodeGroup foi definido (VideoGroup). Este NodeGroup contém dois fluxos comportamentais. O primeiro deles efetua a

coleta das imagens capturadas pelas câmeras (Functional Unit

ReadCameraData) e armazena os dados obtidos na memória RAM dos nós

sensores. O outro fluxo recupera os dados da memória RAM, por meio da

Functional Unit RetrieveRAM1, e envios a estação central (Functional Unit SendGatheredData).

A última região a ser modelada foi a CentralStateRegion, a qual é composta apenas pelo NodeGroup ProcessingGroup. Ele recebe os dados coletados pelos

NodeGroups presentes na região UserLocationRegion (ReceiveMovementData e ReceivePostionData) e processa-os a fim de avaliar a possibilidade de queda no

ambiente monitorado (Fall?). Caso um possível cenário de queda tenha sido detectado, atuadores efetuam a ligação das câmeras presentes no ambiente. Este fluxo comportamental será realizado a cada 30 minutos. Com as câmeras ligadas, o fluxo comportamental definido em VideoGroup é executado e os dados lá coletados são recuperados pela estação central através do segundo fluxo comportamental definido em ProcessingGroup. Após a recuperação destes dados, uma nova análise é realizada com o objetivo de definir se de fato houve um cenário de queda no ambiente (Really fall?). Se tal cenário for detectado, atuadores entrarão em contato com o serviço de emergência para que o indivíduo possa ser socorrido (CallToEmergency) e, uma vez que a queda já foi detectada e as medidas esperadas foram tomadas, as câmeras são desligadas (TurnOffCameras).

A DSL desenvolvida por [SHIMIZU, 2011] foi a última na qual o sistema AAL foi modelado. Assim como acontece em LWiSSy, o metamodelo proposto em

106

[SHIMIZU, 2011] é composto por três modelos, os quais se distinguem entre si pelo nível de granularidade considerado.

O modelo que aborda o nível da rede como um todo foi o primeiro a ser projetado (Figura 5-10). Nele foram inseridas as informações acerca dos nós sensores que serão utilizados no sistema de RSASF (SourceNodes). Mais especificamente, informações sobre qual o tipo de dado que será coletado e qual o intervalo que deve ser considerado durante as coletas. Além disso, foi definido que todos os dados coletados nos SourceNodes serão enviados a um nó Sink.

Figura 5-10 Modelagem em nível de rede do sistema Accidental Fall Detection System utilizando a DSL proposta por [SHIMIZU, 2011].

No segundo modelo (Figura 5-11), o qual considera a granularidade em nível de grupo de nós, todas as informações que foram incluídas no primeiro modelo são consideradas. Além disso, informações acerca da topologia de rede de cada grupo de nós (topology) e a maneira como os dados serão disseminados ao longo da rede (locationCond) são acrescentadas. As topologias disponíveis nesta DSL são tree e mesh. Quanto ao critério de disseminação de dados, o desenvolvedor poderá escolher entre a comunicação indireta (opção N hop, onde

N é a quantidade de saltos desejada) e a comunicação direta (opção allnode). No

caso do sistema AAL foi definido que todos os grupos de nós (InputGroup) terão a topologia de rede mesh e a disseminação de dados será do tipo allnode.

107

Figura 5-11 Modelagem em nível de grupos de nós do sistema Accidental Fall Detection System utilizando a DSL proposta por [SHIMIZU, 2011].

O último modelo produzido (Figura 5-12) acrescenta informações acerca do

comportamento dos nós na rede. Neste modelo foram definidos

comportamentos diferentes três comportamentos diferentes para os nós presentes na rede.

Figura 5-12 Modelagem em nível de nós do sistema Accidental Fall Detection System utilizando a DSL proposta por [SHIMIZU, 2011].

108

O primeiro comportamento, fluxo mais a esquerda da Figura 5-12, determina que amostras a respeito do movimento do indivíduo serão coletadas a cada 20 minutos e os dados coletados serão enviados diretamente ao nó sink a partir do nó sensor. Já o segundo comportamento definido, fluxo central da Figura 5-12, indica que dados a respeito da posição do indivíduo serão coletados a cada 20 minutos e enviados diretamente ao nó sink. O último comportamento definido, fluxo mais a direita da Figura 5-12, determina que serão efetuadas coletas de dados de vídeo a partir do ambiente monitorado e que estes dados também serão enviados diretamente ao no sink. Todos os comportamentos definidos utilizam o protocolo de roteamento Collection Tree

Protocol (parâmetros protocol dos elementos SendingTask e ReceivingTask).

Todos os fluxos definidos enviam os dados coletados ao nó sink através do componente ReceivingTask, o qual está associado diretamente ao nó sink por meio da conexão existente entre este componente e o componente Node, responsável pela definição do nó sink.

5.2.1.3. Análise comparativa das DSLs

Após a modelagem do sistema Accidental Fall Detection com as três DSLs (LWiSSy e as propostas por [LOSILLA, 2007] e [SHIMIZU, 2011]) é possível comparar o poder de expressividade de cada uma delas de acordo com as características expostas no início da Seção 5.2.1. O resultado geral da comparação é exibido na Tabela 5-1 e será detalhado ao longo desta Seção.

LWiSSy Losilla Shimizu

Capacidade de refinamento Modelagem efetuada em uma visão específica. Encapsulada em um modelo geral. Encapsulada ao longo de todos os modelos. Separação de interesses Cada visão é modelada por apenas um especialista.

Não considera. Não considera.

Modelagem estrutural e comportamental Efetuadas em modelos diferentes. Efetuadas em um mesmo modelo. Não considera o nó sink.

109 acordo com granulosidade considera um nível diferente de granulosidade. entre os níveis de granulosidade. considera um nível diferente de granulosidade.

Tabela 5-1 Resultado geral da análise comparativa entre as DSLs.

Com relação à capacidade de refinamento das DSLs em questão, observa-se que LWiSSy difere das demais por incluir atributos de refinamento apenas no último modelo. Isto facilita o processo de modelagem do sistema uma vez que restringe a definição dos atributos de refinamento apenas ao especialista de redes, provendo uma melhor separação de interesses entre os diferentes perfis de especialistas envolvidos. Além disso, outro fator que merece destaque é a quantidade de parâmetros de refinamento em LWiSSy, os quais formam um conjunto muito maior do que aqueles suportados pelas demais DSLs e, por isso, permitem um ajuste mais detalhado dos parâmetros de refinamento da rede e levando assim a um melhor desempenho da rede.

O segundo ponto a ser analisado também envolve a separação de interesses, ou seja, a separação entre os diferentes perfis de desenvolvedor envolvidos na modelagem de sistemas de RSASF. Nota-se claramente que apenas LWiSSy leva em consideração este fator. Na DSL proposta por [LOSILLA, 2007] há apenas um modelo que engloba tanto características de domínio quanto de redes. Já na DSL proposta por [SHIMIZU, 2011], é possível observar que características de domínio e de RSASF se misturam ao longo dos modelos, causando assim uma dependência direta entre os especialistas envolvidos. Enquanto isso, em LWiSSy, a divisão dos papéis dos especialistas é clara e não há conceitos das duas áreas (domínio e RSASF) envolvidos em um mesmo modelo.

A terceira característica analisada foi quanto à capacidade de modelagem comportamental. Esta característica é apresentada pelas três DSLs, porém todas elas tratam a modelagem comportamental de maneira diferente. Em LWiSSy há um modelo específico para definição do comportamento de cada uma das aplicações que são executadas no sistema de RSASF. Isto facilita a modelagem comportamental uma vez que conceitos comportamentais e estruturais não são utilizados em um único modelo. Já na DSL proposta por

110

[LOSILLA, 2007] o comportamento é definido dentro de cada um dos grupos de nós em termos de fluxos comportamentais. Dessa forma, não há uma clara divisão entre os conceitos e, além disso, não é possível determinar qual dos fluxos será executado primeiro, uma vez que nenhum tipo de ordem é definida durante os fluxos modelados. A última DSL, aquela proposta por [SHIMIZU, 2011] define o comportamento dos nós da rede no último modelo que a compõe. Neste caso não é possível determinar qual o fluxo comportamental esperado para o nó sink e, portanto, não é possível efetuar nenhum processamento neste nó, o qual funciona apenas como uma interface entre a rede e um computador externo para que os dados coletados sejam recebidos e armazenados fora da rede.

Por fim, a capacidade de programação da rede considerando diferentes níveis de granularidade (nível de rede, nível de grupo de nós e nível de nós) foi analisada. A DSL proposta por [LOSILLA, 2007] difere das demais por não possibilitar uma clara separação entre os diversos níveis de granularidade, uma vez que apenas um modelo é utilizado ao longo do desenvolvimento de todo o sistema. As outras DSLs, LWiSSy e a proposta por [SHIMIZU, 2011], utilizam três modelos que englobam diferentes níveis de granularidade e, dessa forma, ambas possuem esta capacidade de programação.

Após efetuarmos a comparação entre as três DSLs, é possível afirmar que LWiSSy possui maior poder de expressividade uma vez que engloba a maior quantidade de características de domínio e de RSASF e permite a clara separação entre os conceitos e especialistas envolvidos no processo de modelagem desses sistemas.

Documentos relacionados