fisicamente dispostos de maneira distribuída;
(iii) Controle do fluxo de entrega das informações de contexto, utilizando parâmetros de QoC, possibilitando uma economia de processamento e de energia e, consequente, o aumento do tempo de vida da bateria dos dispositivos móveis; (iv) Distribuição das informações de contexto;
(v) Processamento ou obtenção dos dados brutos obtidos dos sensores para a transformação em informações de contexto;
(vi) Notificação de informações de contexto através de eventos.
Segundo Barua et.al. [6], a taxa de atualização das informações é um importante requisito na distribuição dos dados. Dependendo das configurações de cada sensor, e diferentes taxas de atualização poderão ser adotados. Nossa proposta permite às aplicações ubíquas definir a taxa de atualização e a frequência de recebimento dos dados.
A interoperabilidade é outro requisito importante, uma vez que a infraestrutura ciente de contexto deve permitir que as aplicações recebam facilmente as informações de contexto em um ambiente ubíquo. Em nossa proposta, a interoperabilidade é obtida pela especificação de comunicação DDS. Essa especificação garante um canal de comunicação com baixo acoplamento entre as aplicações e as fontes de contexto. Com isso, garantimos a distribuição e o compartilhamento das informações de forma transparente entre as aplicações ubíquas.
5.2 Linguagem para Especificação de Requisitos de
Contexto
Em nosso trabalho propomos uma linguagem de definição de requisitos de contexto que garante flexibilidade na especificação dos mesmos. Nesta linguagem, denominada MHN Context Language, define quais informações de contexto são requeridas pela aplicação e, de forma opcional, parâmetros de QoC associados às
5.2 Linguagem para Especificação de Requisitos de Contexto 59 mesmas. Trata-se de um modelo descritivo de meta-informação para a representação de requisitos de contexto obtidos dos provedores de contexto.
Essa meta-informação suporta a especificação de informações relativas à descoberta e inicialização dos provedores de contexto, de modo a criar um meio universal de interoperabilidade com os provedores de contexto distribuídos em um ambiente ubíquo. Toda estrutura da linguagem foi implementada usando a especificação XML, uma linguagem neutra com relação à implementação e que permite a criação de outras linguagens a partir dela. No apêndice A é exposto o esquema XML Schema Definition (XSD)1 que detalha a estrutura da MHN Context Language proposta.
De acordo com as informações definidas na especificação, a infraestrutura do MHNCS irá localizar os provedores de contexto que melhor atendem as necessidades de cada aplicação.
A listagem 5.1 apresenta um exemplo de especificação de requisitos de contexto sem a definição de parâmetros de QoC. Neste exemplo, temos o elemento contextInformation, presente na linha 3, utilizado para descrever a informação de contexto. O tipo da informação é definido através do elemento information, o qual é composto por dois atributos: id: específica a informação de contexto que a aplicação deseja receber; e o init: utilizado para determinar a quantidade de provedores de contexto que serão inicializados. O init recebe os seguintes valores: (i) SINGLE: define que será inicializado apenas um provedor de contexto; e (ii) ALL: quando a aplicação deseja inicializar todos os provedores de contexto que fornecem a mesma informação.
1 <?xml version=" 1 . 0 " encoding="UTF−8"?>
2 <requirement>
3 <c o n te x tIn fo rm a tio n>
4 <information id=" l o c a t i o n " i n i t ="SINGLE"/>
5 <information id=" time " i n i t ="ALL"/>
6 </c o n te x tIn fo rm a tio n>
7 <qualityOfContext/>
8 </requirement>
Listagem 5.1: Descrição de requisitos de contexto sem QoC
5.2 Linguagem para Especificação de Requisitos de Contexto 60 Algumas aplicações sensíveis ao contexto tem a necessidade em obter dados do mesmo tipo de informação de sensores diferentes. Estes sensores estão dispersos sobre uma região, sendo assim, apesar de coletarem o mesmo tipo de informação os valores retornados por eles são diferentes. Sistemas sensíveis ao contexto podem realizar analises estatísticas ou inferir um novo fato através dos dados coletados. Pode- se exemplificar isto com um sistema capaz de coletar dados de diversos sensores de temperatura espalhando em uma região metropolitana e determinar a temperatura média. Dessa forma, é possível expressar várias informações de contexto e inicializar um ou vários provedores de contexto, conforme apresentado nas linhas 4 e 5.
5.2.1 Especificação de Parâmetros de QoC
Para especificar os parâmetros de QoC na MHN Context Language é utilizado o elemento qualityOfContext. O elemento property serve para descrever as propriedades relacionadas aos parâmetros de QoC suportados pela linguagem. O property possui um conjunto de atributos que serve para especificar as propriedades dos parâmetros de QoC, conforme a estrutura definida no apêndice A. A listagem 5.2 apresenta um exemplo de definição de requisitos de contexto atribuindo parâmetros de QoC. Neste exemplo, temos nas linhas 4-5 a definição das informações de contexto. Os parâmetros de QoC são definidos pelo elemento property linha 7-8. Na linha 7 a aplicação define que deseja receber as informações com uma taxa de atualização (REFRESH_RATE) de 120 segundos e, neste caso, serão entregues sempre as cinco últimas atualizações. Finalmente, na linha 8 é determinado que cada informação recebida não poderá ter uma idade igual ou superior a 120 segundos.
1 <?xml version=" 1 . 0 " encoding="UTF−8"?>
2 <requirement>
3 <c o n te x tIn fo rm a tio n>
4 <information id=" l o c a t i o n " i n i t ="SINGLE"/>
5 <qualityOfContext>
6 <property name="REFRESH_RATE" time=" 120 " kind="GET_LAST" amount=" 5 "/>
7 <property name="FRESHNESS" age=" 120 " op=" l t e "/>
8 </qualityOfContext>
9 </c o n te x tIn fo rm a tio n>
10 </requirement>
5.2 Linguagem para Especificação de Requisitos de Contexto 61 Especificando o parâmetro de QoC Frequência
Para requerer o parâmetro de QoC frequência a aplicação utilizará atributo name para especificar esse parâmetro, e também terá que determinar o intervalo de tempo que deseja receber uma nova informação pelo atributo time. O atributo kind permite a aplicação definir a variante da frequência. Essa variante pode ser:
1. MINIMUM define que a aplicação, a cada intervalo de tempo, deseja receber pelo menos a última atualização;
2. EXACT define que a aplicação, a cada intervalo de tempo, deseja receber exatamente a última atualização;
3. MAXIMUM define que a aplicação, a cada intervalo de tempo, deseja receber pelo menos uma atualização e no máximo as N últimas atualizações. E o atributo amount será utilizado pela aplicação para determinar a quantidade de atualizações que deseja receber.
Especificando o parâmetro de QoC Taxa de Atualização
Para especificar o parâmetro Refresh rate, além de especificar o intervalo de tempo que deseja receber uma nova informação pelo atributo time, a aplicação também definirá a variante desse parâmetro, semelhante ao Frequency. E neste caso o Refresh rate possui dois tipo de variante:
1. Get_All: define que a aplicação, a cada intervalo de tempo, deseja processar todas as atualizações recebidas;
2. Get_Last: Define que a aplicação, a cada intervalo de tempo, deseja processar apenas as N últimas atualizações recebidas. Semelhante a Frequency MAXIMUM, aplicação também utiliza atributo amount para determinar o número de atualizações.
Especificando o parâmetro de QoC Atualidade
Com relação ao parâmetro Freshness, além de utilizar o atributo name, há dois atributos que devem ser utilizados pela aplicação que são o atributo age e o
5.3 Arquitetura do MobileHealthNet Context Service 62