A aplicação AAL foi também modelada com base no trabalho proposto por (SHIMIZU et al., 2011), conforme mostrado na Figura 61. Nesta modelagem foram utilizados três modelos que se distinguem pelo nível de granularidade considerado, podendo ser classificados como nível de rede, nível de grupos e nível de nós.
Figura 61. Modelo AccidentalFallDetection utilizando a abordagem de (SHIMIZU et al., 2011)
(a) (b)
(c)
A Tabela 31 apresenta a análise de características da abordagem de (SHIMIZU et al., 2011). No nível PIM, o trabalho de (SHIMIZU et al., 2011) apresenta uma organização em três níveis de granularidade diferentes. No
entanto, tal abordagem não define um nível PSM, apesar de possuir suporte a plataforma TinyOS. Assim, as transformações apresentadas em (SHIMIZU et al., 2011) fazem uma ponte direta do nível de PIM para o nível de código. Dessa forma, todo e qualquer reúso de modelo deve ocorrer no nível PIM, aumentando a complexidade das transformações M2M necessárias e tornando-as específicas para uma plataforma alvo, diminuindo a capacidade reusar as regras de transformações existentes ao estender a abordagem para uma nova plataforma.
Tabela 31. Feature Analisys de (SHIMIZU et al., 2011).
ID Propriedade Escala Análise
MDA01 Suporte a PIMs 4 Provê informações independentes de
plataforma em três níveis de granularidade diferentes.
MDA02 Suporte a PSMs 0 Característica não especificada. Possui suporte a plataforma TinyOS mas sem fazer a intermédio entre PIM e PSM. MDA03 Pode ter múltiplos PSMs alvos. 0 Característica não especificada.
MDA04 Integração de Modelos 2 Integra os modelos PIM para a geração do código fonte da plataforma alvo.
MDA05 Evolução da aplicação 1 Suporte a evolução a partir do modelo PIM. MDA06 Interoperabilidade 1 Utiliza notação DSML para criação dos
modelos.
MDA07 Mapeamentos são modelados. 2 Transformação não especificada no documento mas com geração um protótipo da aplicação. MDA08 Suporte para gerenciamento de complexidade
de modelos
1 Suporte nativo do Eclipse.
MDA09 Corretude 0 Característica não especificada.
MDA10 Expressividade 1 PIM não expressa comportamento de
aplicações.
MDA11 Padrões e Genericidade 0 Característica não especificada. MDA12 Suporte a refatoramento 0 Característica não especificada. MDA13 Mapeamento intramodelos 0 Característica não especificada.
MDA14 Rastreabilidade 0 Característica não especificada.
MDA15 Ciclo de vida 2 Especificado parcialmente o processo de
engenharia de domínio.
MDA16 Padronização 0 Não utiliza padrões especificados.
4.4.5 Análise da ArchWiSeN
Esta Subseção descreve a modelagem da aplicação usando a abordagem ArchWiSeN. Assim, foram definidos o modelo da visão estrutural (Figura 62) e modelo da visão comportamental (Figura 62).
Na Figura 62 observa-se que o sistema foi dividido em três regiões.
UserLocationRegion é formada pelos grupos de nós BadgeGroup e PositionGroup, 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 que gerencia as câmeras. Por fim, CentralStationRegion é composta por apenas um grupo de nós, ProcessingGroup, responsável 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 presentes em cada um dos grupos de nós, as conexões existentes na rede e as aplicações que serão executadas.
Figura 62. Visão estrutural do sistema AccidentalFallDetection modelado com a ArchWiSeN.
A visão comportamental das quatro aplicações que compõem o sistema, a saber, MovementSensing, Position Sensing, VideoCheck e FallCheck é apresentada na Figura 63. A aplicação MovementSensing coleta dados sobre a movimentação do indivíduo no ambiente e os envia à estação central. PositionSensing coleta dados sobre a posição do indivíduo no ambiente e também os envia à estação central.
VideoCheck, iniciada pela estação central apenas se uma possibilidade de queda é detectada, liga as câmeras de vídeo e envia as imagens coletadas à estação central. Por fim, FallCheck recebe os dados sobre a movimentação e posição do indivíduo, efetua um processamento a fim de determinar se há possibilidade de queda e, caso
haja, coleta dados das câmeras de vídeo para confirmar se ocorreu, de fato, uma queda. Em caso positivo, a aplicação aciona um hospital ou serviço de emergência. Por fim, foram definidos a topologia de rede e o protocolo de comunicação utilizados através do estereótipo «system» na Figura 62. Além disso, foram determinados quais os tipos de nós sensores que serão utilizados (nesse caso, todos os grupos utilizam nós da plataforma TinyOS).
Figura 63. Visão comportamental (4 aplicações).
A Tabela 32 apresenta a análise de características da ArchWiSeN apresentada nesta Tese. A ArchWiSeN possui um suporte ao PIM definido em diferentes visões que estão associadas a seus respectivos desenvolvedores no processo de engenharia de aplicação. Além disso, possui o suporte PSMs das plataformas TinyOS e Sun SPOT além de permitir mapeamentos para um
middleware genérico. Tais características dão suporte à separação de interesses entre os desenvolvedores, criando um ambiente de desenvolvimento onde os especialistas lidam apenas com as informações que pertencem a sua área de experiência. Ademais, o processo de engenharia de domínio permite a adição de nova semântica no nível PIM ou de novas plataformas no nível PSM, tornando a ArchWiSeN uma abordagem extensível. ArchWiSeN possui o suporte a integração de modelos através do PIM onde diagramas UML de Classe e Atividades são mapeados para um PSM alvo. Ao converter aplicações para código fonte, a ArchWiSeN adota padrões de projeto associados a plataforma alvo como, por exemplo, o padrão placeholder para TinyOS. Além disso, apresenta um mapeamento intramodelos do nível PIM para PIM na forma de um analisador de propriedades não funcionais em tempo de projeto. No processo de engenharia de aplicação apresentado, a ArchWiSeN favorece a evolução de aplicações a partir da manutenção do modelo PIM. Apesar de não possuir mecanismos robustos de rastreabilidade, a ArchWiSeN separa o código que pode ser inserido pelos desenvolvedores no código gerado entre tags para melhor organização. Além disso, o processo de engenharia de aplicação da ArchWiSeN compreende todos os passos do ciclo de vida da aplicação com exceção dos testes, debugs e implantação.
Tabela 32. Feature Analisys da ArchWiSeN
ID Propriedade Escala Análise
MDA01 Suporte a PIMs 4 ArchWiSeN possui um suporte a PIM definido
em diferentes visões que estão associadas a seus respectivos desenvolvedores no processo de engenharia de aplicação.
MDA02 Suporte a PSMs 4 ArchWiSeN possui o suporte PSMs das
plataformas TinyOS e Sun SPOT além de permitir mapeamentos para um middleware genérico. O processo de engenharia de domínio permite também a adição de novos PSMs à ArchWiSeN.
MDA03 Pode ter múltiplos PSMs alvos. 4 Pode possuir qualquer PSM especificado como alvo.
MDA04 Integração de Modelos 2 Possui o suporte a integração de modelos através do PIM onde diagramas de classe e atividades podem ser mapeados para um PSM alvo que possui suas próprias especificações de metamodelo.
MDA05 Evolução da aplicação 3 Possui forte suporte a evolução de aplicações a partir da manutenção do modelo PIM.
MDA06 Interoperabilidade 2 ArchWiSeN utiliza a notação UML entendida a partir de perfis e pode exportar modelos XMI mas tal interoperabilidade não foi testada MDA07 Mapeamentos são modelados. 2 ArchWiSeN trabalha diretamente com a visão
de configuração para alternar entre diferentes mapeamentos.
MDA08 Suporte para gerenciamento de complexidade de modelos
1 ArchWiSeN usufrui do suporte nativo do plugin Papyrus para o gerenciamento de complexidade de modelos.
MDA09 Corretude 0 ArchWiSeN não realiza validações de
corretude no modelo PIM.
MDA10 Expressividade 3 Ao considerar as diferentes granularidades e diferentes visões nas quais os desenvolvedores estão envolvidos a ArchWiSeN provê o alto grau de expressividade.
MDA11 Padrões e Genericidade 2 Ao converter aplicações para código fonte a ArchWiSeN adota padrões de projeto associados a plataforma alvo como, por exemplo, o padrão placeholder para TinyOS. MDA12 Suporte a refatoramento 2 Apesar de não possuir mecanismos robustos
de rastreabilidade, a ArchWiSeN separa o código que pode ser inserido pelos
desenvolvedores no código gerado entre tags para melhor organização.
MDA13 Mapeamento intramodelos 2 Possui um mapeamento intramodelo do nível PIM para PIM na forma de um analisador de propriedades não funcionais em tempo de projeto.
MDA14 Rastreabilidade 1 Possui o mecanismo nativo do plugin ATL do
Eclipse.
MDA15 Ciclo de vida 2 O processo de engenharia de aplicação da
ArchWiSeN compreende todos os passos do ciclo de vida da aplicação com exceção dos testes, debugs e implantação.
MDA16 Padronização 3 ArchWiSeN utiliza tecnologias MDA conforme
especificado pela OMG.
4.4.6 Análise dos Resultados
A partir da análise dos resultados obtidos foi possível comparar o grau de comprometimento de cada abordagem com o padrão MDA da OMG. Apesar de esta análise consistir de apenas um checklist de propriedades presentes nas diferentes abordagens, a ArchWiSeN apresentou características que demonstram um maior grau de comprometimento com o padrão MDA. É importante ressaltar que tal fato isolado não resulta em nenhuma vantagem ou desvantagem direta da ArchWiSeN com relação as outras abordagens. No entanto, esse resultado demonstra que a ArchWiSeN já possui um grau de comprometimento com o padrão onde ganhos clássicos de abordagens MDA (como reúso e redução no
esforço do desenvolvimento) puderam ser constatados, conforme apresentado nas avaliações anteriores presentes neste Capítulo.