Modelagem e Especificação de um Middleware para Redes de ...
Modelagem e Especificação de um Middleware para Redes de ... Modelagem e Especificação de um Middleware para Redes de ...
74 5.3 Características entes usuários. Isso porque os usuários podem pensar em uma rede para uma aplicação de seu interesse, podendo inclusive criar seus próprios transdutores. 5.3 Características De acordo com os paradigmas discutidos no Capítulo 3 o Kratos é um middleware que mescla orientação a aplicação e orientação a mensagens. Ele integra aplicações distribuídas por meio do uso de mensagens, provendo as habilidades de criação, manipulação, armazenamento e comunicação de dados através do mecanismo de mensagens. Por exemplo: mensagens são utilizadas para a comunicação entre um sistema usuário e os sensores para solicitação de dados, reorganização da rede, desativação de algum sensor, dentre outras atividades. O fato do middleware ser orientado a mensagens traz algumas vantagens como a entrega confiável sem duplicação de mensagens e o envio e recebimento de mensagens que são feitos de forma assíncrona, possibilitando a execução independente das aplicações e um alto grau de tolerância a falhas. Em um middleware orientado a mensagens a comunicação ocorre basicamente de duas formas: ponto-a-ponto (point-to-point), em que as mensagens são enviadas com base no método de comunicação um-para-um e publicação-subscrição (publish-subscribe), onde as mensagens são publicadas com base no método um-para-muitos, que é o caso deste middleware [2]. O Kratos é um middleware caixa branca. Portanto, para sua utilização, é necessário que o usuário forneça uma implementação específica para a aplicação. Sendo assim, diferentes tipos de implementações são possíveis, já que essas implementações são oriundas de fora do middleware, diferente de um middleware caixa preta, onde todas as possíveis implementações estão em seu interior, cabendo ao usuário apenas escolher entre elas. Além disso, pelo fato do middleware ser construído a partir de detalhes e exigências de ferramentas para a área de saúde, ele é considerado um middleware vertical. Outras características importantes são: • Capacidade de agregação de novas funcionalidades, fazendo com que o middleware seja capaz de atender a novas expectativas, tornando-o cada vez mais especialista; • Independência de tecnologias de rede; essa característica faz com que o middleware possa se comunicar com os transdutores conectados em diferentes tipos de redes, como por exemplo, um sensor em uma rede sem fios pode enviar dados para o middleware assim como um sensor conectado por uma rede cabeada; • Descoberta automática de dispositivos e de capacidades; o middleware é capaz de detectar imediatamente transdutores que estão em região tangível e seus recursos;
5.4 Diagrama de contexto 75 • Qualidade de serviço; o middleware prioriza a coleta de dados de sensores que enviam dados mais relevantes para a aplicação. Por exemplo, entre temperatura e frequência cardíaca num monitoramento de um paciente de Unidade de Terapia Intensiva, o middleware dá preferência aos dados coletados pelo sensor de frequência cardíaca; • Capacidade de localização e roteamento; essa característica faz com que o middleware saiba a localização de um sensor em relação a uma referência central e em relação aos outros sensores e também a sua própria localização em relação a RSSF; • Escalabilidade; o middleware é capaz de se adequar às mudanças da RSSF, como o aumento ou diminuição do número de transdutores. As características citadas fazem do middleware uma ferramenta computacional com funcionalidades importantes para o gerenciamento de uma RSSF, podendo ser utilizado em diversas aplicações de maneira eficaz [9]. 5.4 Diagrama de contexto O diagrama da figura 5.1 mostra o middleware Kratos de uma maneira simplificada. O middleware terá três atores diretos: • Sistema usuário: aplicação que usará os recursos da RSSF; • Atuador: dispositivo que alterará as condições do meio no qual está inserido; • Sensor: dispositivo que coletará dados do meio no qual está inserido. Figura 5.1: Caso de uso Gerenciar middleware
- Page 25 and 26: Introdução CAPÍTULO 1 1.1 Contex
- Page 27 and 28: 1.2 Motivação 27 1.2 Motivação
- Page 29 and 30: CAPÍTULO 2 Tecnologias e aplicaç
- Page 31 and 32: 2.1 Redes de Sensores sem Fio 31
- Page 33 and 34: 2.1 Redes de Sensores sem Fio 33 se
- Page 35 and 36: 2.2 Comunicação em redes sem fio
- Page 37 and 38: 2.2 Comunicação em redes sem fio
- Page 39 and 40: 2.2 Comunicação em redes sem fio
- Page 41 and 42: 2.3 Considerações finais 41 estã
- Page 43 and 44: CAPÍTULO 3 Middlewares para Redes
- Page 45 and 46: 3.2 Middlewares baseados em program
- Page 47 and 48: 3.4 Middlewares direcionados a apli
- Page 49 and 50: 3.6 Avaliação geral 49 plataforma
- Page 51: 3.7 Considerações finais 51 Figur
- Page 54 and 55: 54 4.1 A família de padrões IEEE
- Page 56 and 57: 56 4.2 Padrão IEEE 1451.0 Tabela 4
- Page 58 and 59: 58 4.2 Padrão IEEE 1451.0 As class
- Page 60 and 61: 60 4.2 Padrão IEEE 1451.0 Figura 4
- Page 62 and 63: 62 4.2 Padrão IEEE 1451.0 4.2.7 Mo
- Page 64 and 65: 64 4.2 Padrão IEEE 1451.0 4.2.9 Mo
- Page 66 and 67: 66 4.2 Padrão IEEE 1451.0 • Acom
- Page 68 and 69: 68 4.4 Considerações finais do PH
- Page 71 and 72: Middleware Kratos CAPÍTULO 5 Vislu
- Page 73: 5.2 Objetivos e requisitos 73 • C
- Page 77 and 78: 5.5 Introdução à arquitetura do
- Page 79 and 80: 5.6 Descrição dos subsistemas 79
- Page 81 and 82: 5.6 Descrição dos subsistemas 81
- Page 83 and 84: 5.6 Descrição dos subsistemas 83
- Page 85 and 86: 5.6 Descrição dos subsistemas 85
- Page 87 and 88: 5.6 Descrição dos subsistemas 87
- Page 89 and 90: 5.6 Descrição dos subsistemas 89
- Page 91 and 92: 5.6 Descrição dos subsistemas 91
- Page 93 and 94: 5.6 Descrição dos subsistemas 93
- Page 95 and 96: 5.6 Descrição dos subsistemas 95
- Page 97 and 98: 5.7 Considerações finais 97 • a
- Page 99 and 100: 5.7 Considerações finais 99 Figur
- Page 101 and 102: CAPÍTULO 6 Conclusões e trabalhos
- Page 103 and 104: Referências Bibliográficas [1] AK
- Page 105 and 106: Referências Bibliográficas 105 [2
- Page 107 and 108: Referências Bibliográficas 107 [4
5.4 Diagrama <strong>de</strong> contexto 75<br />
• Qualida<strong>de</strong> <strong>de</strong> serviço; o middleware prioriza a coleta <strong>de</strong> dados <strong>de</strong> sensores que<br />
enviam dados mais relevantes <strong>para</strong> a aplicação. Por exemplo, entre temperatura e<br />
frequência cardíaca n<strong>um</strong> monitoramento <strong>de</strong> <strong>um</strong> paciente <strong>de</strong> Unida<strong>de</strong> <strong>de</strong> Terapia Intensiva,<br />
o middleware dá preferência aos dados coletados pelo sensor <strong>de</strong> frequência<br />
cardíaca;<br />
• Capacida<strong>de</strong> <strong>de</strong> localização e roteamento; essa característica faz com que o<br />
middleware saiba a localização <strong>de</strong> <strong>um</strong> sensor em relação a <strong>um</strong>a referência central<br />
e em relação aos outros sensores e também a sua própria localização em relação a<br />
RSSF;<br />
• Escalabilida<strong>de</strong>; o middleware é capaz <strong>de</strong> se a<strong>de</strong>quar às mudanças da RSSF, como<br />
o a<strong>um</strong>ento ou diminuição do número <strong>de</strong> transdutores.<br />
As características citadas fazem do middleware <strong>um</strong>a ferramenta computacional<br />
com funcionalida<strong>de</strong>s importantes <strong>para</strong> o gerenciamento <strong>de</strong> <strong>um</strong>a RSSF, po<strong>de</strong>ndo ser<br />
utilizado em diversas aplicações <strong>de</strong> maneira eficaz [9].<br />
5.4 Diagrama <strong>de</strong> contexto<br />
O diagrama da figura 5.1 mostra o middleware Kratos <strong>de</strong> <strong>um</strong>a maneira simplificada.<br />
O middleware terá três atores diretos:<br />
• Sistema usuário: aplicação que usará os recursos da RSSF;<br />
• Atuador: dispositivo que alterará as condições do meio no qual está inserido;<br />
• Sensor: dispositivo que coletará dados do meio no qual está inserido.<br />
Figura 5.1: Caso <strong>de</strong> uso Gerenciar middleware