O terceiro estudo de caso foi desenvolvido no contexto de cuidados com a saúde (health care) em um cenário inspirado em (Hegering, Kupper et al., 2003). A aplicação considera como usuários (i) pacientes com doenças críticas, envolvidos em suas atividades diárias; (ii) médicos e (iii) equipe ambulatorial, de modo que os usuários usem dispositivos móveis convencionais ou para fins específicos, conectados a Internet através de tecnologias de rede sem fio (e.g. Wi-Fi, 3G, Bluetooth, etc.) e/ou através de infraestruturas cabeadas (ver Figura 45). Alguns indicadores de saúde (como pressão sanguínea, pulsação cardíaca, taxa glicêmica, movimentos, etc.) do paciente são continuamente monitorados por sensores instalados no próprio paciente. Além das informações fornecidas por esses sensores, a aplicação considera ainda informações médicas dos pacientes (histórico médico ou prontuário), como por exemplo, se um paciente é fumante ou não, se ele/ela tem alguma doença e/ou alergia. Além disso, o histórico médico do paciente armazena eventos anteriores e diagnósticos médicos. Em aplicações health care, se o paciente tem complicações em seu estado de saúde, um conjunto de ações precisam ser realizadas, como acionar uma equipe de emergência para socorrer o paciente. Essa aplicação foi escolhida devido à sua relevância no mundo real e porque ela usa diferentes tipos de informações de contexto fornecidas por diversos tipos de dispositivos móveis ou ainda de fins específicos para aplicações
healthcare, como sensores de monitoramento de sinais vitais do paciente. Ademais, essa
aplicação considera vários tipos de serviços, incluindo serviços com a mesma funcionalidade (como serviços de localização baseados em GPS, 3G ou em níveis de sinal WiFi), cada um com qualidade de serviço diferente. Essas características desse terceiro estudo de caso permitem ilustrar a integração de várias plataformas heterogêneas e ainda os processos de seleção e composição de serviços e de adaptação.
Figura
5.3.1. Ontologia de dom A ontologia de con ontologia descreve os conc conceitos são usados como semânticos. A Figura 46 apr tarefas (tasks) possíveis de representam objetos genér
Ontology, apresentada na F
herdam diretamente ou ind tarefas e objetos denotam u aplicações. Por exemplo, a
Temperature e BPM, sign
subscrever para receber not batimentos por minuto relacionamentos entre a tar possível atualizar o históric internação, etc.
ra 45. Ambiente do estudo de caso HealthCare
domínio
ontexto Healthcare foi criada para esse estud onceitos do ambiente de monitoramento de p mo entrada e saída dos serviços e na criação apresenta essa ontologia. As elipses mais escu de serem realizadas, as elipses de cor cinza ( néricos que foram definidos na ontologia G Figura 3. Por fim, as elipses brancas apresen ndiretamente de um generic object. Os relacio
uma ação que pode ser utilizada como uma , a tarefa Subscribe está associada aos objetos ignificando que workflows podem incluir a notificações da pressão sanguínea, da temperatu
do paciente, respectivamente. Outro ex tarefa Update e o objeto MedicalProfile, sign
rico médico de um paciente após cada ocorrên
87 tudo de caso. Tal e pacientes. Esses ão dos workflows curas representam a (generic object)
Generic Context
entam objetos que cionamentos entre a atividade pelas os BloodPressure, atividades como ratura e da taxa de exemplo são os ignificando que é rência de consulta,
88
Figura 46. Descrição parcial da ontologia de contexto Healthcare
5.3.1. Workflow
Para exemplificar o uso da aplicação, a pressão sanguínea de um paciente foi escolhida como parâmetro a ser monitorado durante as suas atividades diárias. Se a pressão sanguínea atual do paciente está acima do limiar máximo definido (maxBloodPressure), é possível detectar a iminência de um ataque cardíaco ou outro tipo de complicação. Nesses casos, os parentes do paciente são procurados e uma mensagem de alerta sobre o seu estado de saúde é enviada usando os serviços de mensagens (SMS, e-mail ou mensagem de voz). Além disso, a equipe de emergência é acionada para dar assistência ao paciente, sendo fornecidas também informações sobre as condições de saúde atual (através dos sensores) e o histórico médico do paciente, assim como informação sobre a localização do mesmo (fornecida por provedores de serviços de localização). Tais informações podem ser úteis, por exemplo, para selecionar uma ambulância apropriada para o determinado tipo de emergência (por exemplo, ambulância de transporte, de emergência ou intensiva). Enquanto a equipe de emergênciapresta assistência ao paciente, um hospital (o mais próximo ou o que mais se adéqüe ao caso em questão) pode também ser acionado para se preparar para receber o paciente, providenciando uma assistência eficiente e apropriada para o problema, organizando previamente o material e contatando a equipe hospitalar necessária para tratar do paciente. Além disso, no caso de não haver leitos disponíveis, alternativamente outros hospitais da vizinhança podem ser contatados para receber o paciente. Finalmente, a melhor rota entre a localização atual do paciente até o hospital (o caminho mais curto ou mais rápido) é calculada para que dessa forma a equipe de emergência chegue o mais rápido possível à localização atual do paciente e se locomova até o
89 hospital que irá atendê-lo, completando a ação de ajuda. Em seguida, o histórico médico do paciente é atualizado com o evento ocorrido.
O workflow semântico desse estudo de caso é composto por 13 atividades (representadas por tuplas: task/object), sendo elas apresentadas na Tabela 5:
Tabela 5. Atividades do workflow do estudo de caso HealthCare.
Atividade Responsável por
1. (Subscribe,
bloodPressure)
Subscreve a aplicação ao monitoramento da pressão sanguínea do paciente.
2. (Consult,
medicalProfile)
Consulta o histórico médico do paciente.
3. (Search,
closestRelatives)
Procura por familiares próximos ao usuário.
4. (Search,
closestDoctors)
Procura por médicos que possam prestar assistência ao paciente.
5. (Send, message) Envia mensagem para usuário.
6. (Search,
closestAmbulances)
Procura por ambulâncias próximas ao paciente.
7. (Select, ambulance) Seleciona uma ambulância.
8. (Call, ambulance) Chama ou requisita uma ambulância específica.
9. (Search, hospitals) Procura por hospitais disponíveis.
10. (Select, hospital) Seleciona um hospital para receber o paciente.
11. (Call, hospital) Comunica ao hospital que um paciente está a caminho.
12. (Determine,
ambulanceRoute)
Determina uma rota para a ambulância.
13. (Update,
medicalProfile)
Atualiza o histórico do paciente com o novo evento.
Cada uma dessas atividades (abstratas)é realizada por pelo menos um serviço (concreto), que implementa os requisitos de cada atividade. No caso das atividades 4 e
5, mais de um serviço é oferecido, cada um baseado em diferentes tecnologias. Essa
característica objetiva possibilitar a criação de vários planos de execuções, permitindo a avaliação dos mecanismos de seleção e adaptação do OpenCOPI. Desse modo, a
atividade 4 é realizada por três serviços, sendo cada um deles baseado em uma
tecnologia específica (localização baseada nas redes de celular, em GPS ou no nível do sinal de redes WiFi), de modo que cada serviço provê diferentes níveis de qualidade de serviço. A atividade 5 é realizada também por três serviços, sendo cada um deles baseado em uma tecnologia específica (envio de mensagens através de emails, SMS ou mensagens de voz). A combinação desses diferentes serviços resulta em nove possíveis planos de execução.
90 5.3.2.1. Serviços disponíveis
Existem vários provedores de serviços envolvidos nessa aplicação:
CTHealthMonitor e JCAFMonitor são abstrações de serviços providos respectivamente
por um widget do Context Toolkit e pelo JCAF. Esses serviços monitoram informações de contexto sobre o estado atual do paciente; mais especificamente, são responsáveis por sincronamente ou assincronamente prover o valor da pressão sanguínea do paciente que vem sendo monitorado. Os sensores usados pelo paciente verificam a pressão sanguínea e essa informação é enviada ao monitor. Os provedores
WifiLocalizationMiddleware, GPSLocalizationMiddleware e
CellularLocalizationMiddleware são responsáveis por fornecer serviços sobre a
localização de pessoas e ambulâncias. Portanto, a localização pode ser fornecida por vários serviços distintos, baseados em diferentes tecnologias que capturam a localização física e/ou geográfica, porém proporcionando a mesma informação. Assim como nos outros estudos de caso, um desses serviços equivalentes pode ser selecionado em tempo de execução de acordo com a qualidade dos serviços (parâmetros QoS/QoC) e, em caso de falha do serviço selecionado, outras opções de serviços de localização podem ser usadas. O mesmo ocorre com os serviços responsáveis pela comunicação entre os atores da aplicação (GSMSystem, EmailSystem e VoiceMessagingSystem). Eles podem enviar mensagens de alerta sobre o estado de saúde atual do paciente para seu médico e parentes. Então, vários serviços – envio de SMS (mensagens curtas de texto), e-mail e mensagens de voz – estão disponíveis para executar a mesma tarefa (envio de uma mensagem de alerta) e um deles é escolhido de acordo com o QoS dos serviços que os compõem.
Os sistemas a seguir são sistemas hospitalares que fornecem serviços úteis para essa aplicação. HospitalsManagementSystem representa um sistema que gerencia informação relativa a hospitais (por exemplo disponibilidade, especialidade, etc.) e fornece serviços capazes de selecionar (SelectHospital) o hospital mais apropriado para o caso em questão, considerando a localização do paciente e seu estado de saúde, a localização da equipe de emergência e hospitais e suas disponibilidades. Ele também permite contatar o hospital selecionado (CallHospital). O MedicalProfileDatabase é um sistema Web que proporciona informação sobre o histórico médico do paciente, que é uma espécie de dossiê contendo informações prévias e atuais sobre o paciente e que pode influenciar o seu tratamento ou estar correlacionado com o problema em
91 questão.Esse sistema provê os serviços ConsultMedicalProfile e UpdateMedicalProfile. Por fim o sistema AmbulanceManagementSystem é uma abstração de serviço provido pelo JCAF e que oferece serviços de contexto que gerencia e integra equipes de emergências e ambulâncias, fornecendo serviços para selecionar (SelectAmbulance) e acionar equipes de emergências de acordo com a gravidade da emergência (CallAmbulance), além de descrever a melhor opção de rota para a ambulância (DetermineRoute). Esse serviço é abstraído por um driver construído para integrar o serviços providos no JCAF ao OpenCOPI.
Os metadados de qualidade de cada serviço utilizado nesse estudo de caso são apresentados na Tabela 6. Esses metadados são utilizados nos processos de seleção de planos de execução e de adaptação. Podemos observar nessa tabela que alguns serviços possuem apenas parâmetros QoS (availability, performance e responsing) pois não são serviços de contexto. Os valores dos metadados não são reais e foram determinados de modo a possibilitar a avaliação do mecanismo de seleção e adaptação do OpenCOPI.
Tabela 6. Metadados dos serviços do Estudo de caso 3.
Serviços
QoS QoC
Availability Performance Responsing Correctness Freshness
CTHealthMonitor 6 4 6 7 9 JCAFMonitor 2 6 9 6 5 ConsultMedicalProfile e UpdateMedicalPRofile 8 8 10 - - SelectAmbulance 7 8 7 9 9 CallAmbulance 7 8 7 - - DetermineRoute 7 8 7 9 8 SearchHospital, SelectHospital e CallHospital 9 9 10 - - SearchByGPS 8 8 4 10 2 SearchByCellular 4 2 7 7 6 SearchByWiFi 8 3 6 5 5 SendSMS 7 7 9 - - SendMail 9 5 7 - - SendVoiceMsg 9 2 6 - - 5.3.2.2. Planos de execução
A Figura 47 ilustra o grafo que representa os planos de execução do workflow dessa aplicação. Nessa figura, cada círculo representa um serviço e o número no interior no círculo mostra qual atividade é realizada pelo respectivo serviço. Os serviços 1’ e 1’’ realizam a atividade 1, Os serviços 4’, 4’’ e 4’’’ são as possíveis opções para realizar a
atividade 4 e os serviços 5’, 5’’ e 5’’’ são as possíveis opções de serviços para realizar a atividade 5.
92
Figura 47. Planos de execução do estudo de caso HealthCare
Essa combinação de serviços resulta em dezoito possíveis planos de execução. A atividade SubscribeBloodPressure (atividade 1) pode ser realizada pelos serviços
CTHealthMonitor e JCAFMonitor. A atividade SearchClosestDoctors pode ser
realizada por serviços providos pelas plataformas GPSLocalizationMiddleware,
WifiLocalizationMiddleware e CellularLocalizationMiddleware. A atividade
SendMessage pode ser realizada pelos serviços SendSMS, SendMail e SendVoiceMsg.
Essa combinação de serviços permite a criação de dezoito planos de execução. Cada um desses planos foi nomeado como EP1, EP2, ..., EP18 para facilitar a explicação da avaliação. A Tabela 7 ilustra os serviços que diferem em cada plano de execução. Os serviços que atendem às outras atividades do workflow são compartilhados por todos os planos de execução uma vez que existe apenas uma opção de serviço para cada uma das atividades.
Tabela 7. Lista de planos de execução do Estudo de caso 3.
Plano de Execução Serviços que diferem os planos de execução
EP1 CTHealthMonitor, SearchByGPS, SendSMS
EP2 CTHealthMonitor, SearchByGPS, SendMail
EP3 CTHealthMonitor, SearchByGPS, SendVoiceMsg
EP4 CTHealthMonitor, SearchByCellular, SendSMS
EP5 CTHealthMonitor, SearchByCellular, SendMail
EP6 CTHealthMonitor, SearchByCellular, SendVoiceMsg
EP7 CTHealthMonitor, SearchByWiFi, SendSMS
EP8 CTHealthMonitor, SearchByWiFi, SendMail
EP9 CTHealthMonitor, SearchByWiFi, SendVoiceMsg
EP10 JCAFMonitor, SearchByGPS, SendSMS
EP11 JCAFMonitor, SearchByGPS, SendMail
EP12 JCAFMonitor, SearchByGPS, SendVoiceMsg
EP13 JCAFMonitor, SearchByCellular, SendSMS
EP14 JCAFMonitor, SearchByCellular, SendMail
EP15 JCAFMonitor, SearchByCellular, SendVoiceMsg
EP16 JCAFMonitor, SearchByWiFi, SendSMS
EP17 JCAFMonitor, SearchByWiFi, SendMail
EP18 JCAFMonitor, SearchByWiFi, SendVoiceMsg
5.3.2.3. Implantação e execução
Os serviços utilizados nesse estudo de caso são implantados em um mesmo servidor. Nada impede que sejam implantados em diferentes servidores; entretanto o uso
93 de diferentes servidores pode distorcer os resultados da análise do overhead gerado pelo OpenCOPI, impossibilitando uma comparação com o overhead gerado pelo estudo de caso 1 (cujo resultados são apresentados na Seção 6.3. Overhead).
5.3.3.Discussão
Esse terceiro estudo de caso tem objetivos parecidos com o do primeiro estudo de caso, porém possui um workflow com um maior número de atividades e também mais serviços com funcionalidades semelhantes, resultando em um maior número de planos de execução. Essa característica possibilita a avaliação do crescimento em escala do
overhead gerado pelos mecanismos de composição, seleção e adaptação do OpenCOPI e
pela execução dos serviços. Além disso, essa aplicação tem como objetivo usar serviços dos middleware de provisão de contexto Context Toolkit e JCAF, simultaneamente. Essa característica enfatiza ainda mais o requisito de transparência suportado pelo OpenCOPI, permitindo que aplicações utilizem serviços providos por diferentes middleware subjacentes sem precisar conhecer as suas APIs e modelos de contexto.
5.4. Conclusão do capítulo
Esse capítulo apresentou os estudos de caso desenvolvidos para motivar a utilização do OpenCOPI e mais importante que isso, esses estudos de casos foram utilizados na validação e avaliação da plataforma.
94