suportada pela maioria das APIs e arcabouços para processamento de ontologias.
De acordo com os artefatos de entrada relacionados a serviços produzidos na (a2) atividade de projeto, desenvolvedores devem considerar as linguagens, técnicas e ferramentas computacionais mais adequadas para atender às necessidades de projeto de cada serviço a ser reusado, estendido e implementado. Por exemplo, quanto ao processamento de informações de contexto baseadas em ontologias, três serviços podem ser considerados: o serviço de armazenamento, o serviço de consulta e o serviço de inferência.
O desenvolvedor deve optar por um serviço de armazenamento que forneça mecanismos eficientes para o armazenamento e para a recuperação de informações de contexto baseadas em ontologias.
Ao desenvolver um serviço de consulta, o desenvolvedor deve escolher linguagens de consulta para informações baseadas em ontologias que sejam compatíveis com a linguagem de ontologia utilizada no (d4) documento de modelo ontológico da apli- cação. Além disso, a linguagem de consulta deve também atender à expressividade requisitada por cada consulta especificada na (a2) atividade de projeto.
Ao desenvolver um serviço de inferência, o desenvolvedor precisa identificar as máquinas de inferência apropriadas para atender às necessidades de projeto especificadas no (d4) documento de modelo ontológico da aplicação e nos artefatos relacionados a serviços (d5, d6 e d7). Por exemplo, existem máquinas de inferência que suportam vários tipos de inferência, assim como diferentes linguagens de ontologias e linguagens de regras com vários níveis de expressividade.
É importante observar que o processo POCAp é neutro com respeito à tecnologia utilizada para apoiar o desenvolvimento de aplicações cujas informações de contexto são baseadas em ontologias. Esse fato oferece liberdade ao desenvolvedor na escolha do suporte computacional necessário para transformar os artefatos da (a2) atividade de projeto naimplementação da aplicação sensível a contexto.
6.5
Atividade de verificação e validação (a4)
A atividade de verificação e validação consiste em executar a aplicação sensível a contexto com casos de teste derivados da especificação das informações de contexto a serem processadas pela aplicação.
Os artefatos de entrada atividade de verificação e validação são o (d1)documento de requisitos, o (d3) documento de reúso do modelo, o (d4) documento de modelo ontológico da aplicação, gerados pela (a1) atividade de análise e especificação, e a implementação da aplicação sensível a contexto, produzida na (a3) atividade de desenvolvimento.
Requisitos funcionais são usados na (a4) atividade de verificação e validação para checar se a aplicação atende às especificações correspondentes. Uma vez que o analista estende o (g1) modelo ontológico de informações de contexto que o processo POCAp assume existir para gerar o (d4) documento de modelo ontológico da aplicação e o (d3) documento de reúso do modelo, durante esta atividade é importante avaliar se essas duas especificações são apropriadamente tratadas na implementação da aplicação. Isto é relevante a fim de melhor acomodar futuras extensões na aplicação. Os serviços de um engenheiro de ontologias podem ser úteis durante esta atividade.
No caso de aplicações cujas informações de contexto são baseadas em ontologias, (u4) validadores devem também preocupar-se com requisitos não-funcionais. Para ambientes de computação sensível a contexto, a interoperabilidade entre sistemas de software heterogêneos é um dos desafios a serem tratados. Validadores devem avaliar a adequação de padrões para promover a interoperabilidade não apenas entre aplicações, mas também entre serviços de infra-estruturas de software.
Outro requisito não-funcional importante é o armazenamento de informações de contexto. Validadores devem avaliar as estratégias de implementação utilizadas para prever o armazenamento adequado de informações de contexto baseadas em ontologias.
O desempenho de aplicações sensíveis a contexto, por sua vez, pode ser afetado segundo as características das máquinas de inferência utilizadas por desenvolve- dores. Validadores devem avaliar o tempo de resposta de inferência sobre informações de contexto baseadas em ontologias considerando os requisitos de desempenho da aplicação. Além disso, validadores devem considerar os tempos intermediários que compõem um processo de inferência para identificar pontos de otimização no desempenho da aplicação.
6.6
Considerações finais
Este capítulo apresentou o processo de software POCAp como uma alternativa para a demanda por técnicas de Engenharia de Software para apoiar o desenvolvimento de aplicações sensíveis a contexto. Esse processo compreende um conjunto de atividades para analisar, especificar, projetar, implementar e testar aplicações cujas informações de contexto são baseadas em ontologias.
Assim, este trabalho reforça a importância de um engenheiro de ontologias para apoiar uma equipe de desenvolvimento nas atividades que exigem conhecimento relativo a metodologias para construção de ontologias, e ao projeto, implementação e teste de serviços habilitados para processar a semântica fornecida por ontologias.
Quanto à construção de aplicações sensíveis a contexto, outra característica do processo POCAp é que este é independente tanto do modelo ontológico de informação
6.6. CONSIDERAÇÕES FINAIS 121 contextual quanto da infra-estrutura de serviços existentes. Esse fato confere ao processo POCAp a característica de ser genérico quanto ao desenvolvimento de aplicações sensíveis a contexto, especialmente aquelas cujas informações de contexto são apoiadas por ontologias.
Nesse interim, o próximo capítulo descreve como o processo POCAp é instanciado ao utilizar como modelo e infra-estrutura de apoio, respectivamente, o modelo SeCoM e a infra-estrutura de serviços SCK. O próximo capítulo também relata a utilização do processo POCAp na extensão de uma aplicação Web com informações de contexto instanciadas a partir do modelo SeCoM, e a integração da mesma com os serviços de armazenamento, consulta e inferência da infra-estrutura SCK.
C
APÍTULO7
Instanciação do Processo POCAp
Este capítulo descreve como utilizar o processo POCAp para a construção de aplicações sensíveis a contexto baseadas em ontologias. Inicialmente, o processo é instanciado para construir aplicações cujas informações de contexto são apoiadas pelo modelo SeCoM, como modelo ontológico de informação contextual, e pela infra-estrutura de serviços SCK, como infra-estrutura computacional para interpre- tação da semântica desse classe de modelos [Bulcão Neto et al., 2006b].
De maneira complementar, é apresentada a instanciação do processo POCAp para construir uma aplicação sensível a contexto a partir do modelo SeCoM e da infra-estrutura de serviços SCK.
Para finalizar este capítulo, são apresentadas as considerações finais quanto ao mecanismo de instanciação do processo POCAp, que também incluem questões de projeto que desenvolvedores de aplicações sensíveis a contexto baseadas em ontologias devem considerar.
7.1
Os artefatos SeCoM e SCK no processo POCAp
Como o processo POCAp prevê a existência de um (g1) modelo de informações de contexto baseado em ontologias (atividade (a1) na Figura 6.2, página 115) e de um (g2) documento de descrição de infra-estrutura de serviços (atividade (a2) na Figura 6.3, página 117), este trabalho descreve como o modelo SeCoM e a infra-estrutura de serviços SCK podem ser utilizados como artefatos auxiliares para a construção de aplicações sensíveis a contexto. As quatro atividades do processo POCAp instanciadas
com o SeCoM e a SCK são apresentadas a seguir. Documentos e atividades numerados ao longo deste capítulo referem-se às Figuras 6.1, 6.2 e 6.3 do Capítulo 6, respectivamente encontradas nas páginas 113, 115 e 117.
Uma instância da (a1) atividade de análise e especificação
Uma vez que as sub-atividades de (a1.1) análise e especificação de requisitos e (a1.2) análise e especificação de informação contextual são independentes do (g1)
modelo de informações de contexto baseado em ontologias, o (u1) analista produz o (d1) documento de requisitose o (d2)documento de informações de contexto de maneira independente do modelo de informação contextual SeCoM.
A primeira sub-atividade dependente de um modelo ontológico é a (a1.3) sub-atividade de análise e especificação de reúso do modelo. Neste caso, o modelo SeCoM é usado como um artefato auxiliar para que o analista possa mapear e combi- nar o (d2) documento de informações de contextode acordo com os termos ontológicos fornecidos na forma de atores, dispositivos, localização, tempo e atividades, tal como fornecido pelo modelo SeCoM (vide Figura 4.1, página 63). Em seguida, o analista produz o (d3) documento de reúso do modelo, que contém os termos ontológicos da aplicação que o modelo SeCoM representa.
Durante a (a1.4) sub-atividade de análise e especificação de extensão do modelo, os termos que o modelo SeCoM não representa são modelados pelo analista como uma extensão desse modelo. Por exemplo, se uma aplicação sensível a contexto demanda a representação de atributos físicos de pessoas — por exemplo, altura e peso — o analista define uma ontologia particular para representar tal tipo de informação. O modelo SeCoM é estendido quando a nova ontologia de atributos físicos importa a ontologia Actor em que pessoas já são representadas, como (act:Person, rdf:subClassOf, act:Actor). Os termos identificados nas (a1.3 e a1.4) sub-atividades de reúso e extensão do modelo formam o (d4) documento de modelo ontológico da aplicação.
Uma instância da (a2) atividade de projeto
Baseado tanto no (d1) documento de requisitos, gerado na sub-atividade (a1.1), quanto no (d4)documento de modelo ontológico da aplicação, gerado na sub-atividade (a1.4), o (u2) projetista deve combinar as demandas da aplicação em questão em termos de armazenamento, consulta e inferência da semântica de informações de contexto com os correspondentes serviços de uma infra-estrutura, como a SCK.
A característica de configurabilidade da infra-estrutura SCK, em particular, visa atender a uma ampla variedade de requisitos de armazenamento, consulta e infe- rência. Quando as operações disponíveis nos serviços da infra-estrutura SCK não
7.1. OS ARTEFATOS SECOM E SCK NO PROCESSO POCAP 125 atendem aos requisitos de uma aplicação, os serviços precisam ser estendidos para implementar a operação requisitada — isso demanda que o projetista especifique as novas operações de acordo com o mecanismo de extensão aceito pela infra-estrutura SCK.
Se uma aplicação sensível a contexto demanda um serviço que não é fornecido pela infra-estrutura SCK, o projetista deve então especificar a estrutura desse serviço para fins de implementação. Se o novo serviço precisa manipular a semântica de informações de contexto, ele tem de explorar a semântica definida no (d4)documento de modelo ontológico da aplicação.
Uma instância da (a3) atividade de desenvolvimento
Nesta atividade, (u3) desenvolvedores podem se beneficiar da utilização do modelo semântico de informações de contexto SeCoM e da infra-estrutura de serviços SCK.
Com relação ao modelo SeCoM, todo o conhecimento de uma aplicação sensível a contexto está separado de sua lógica de programação. Essa separação de interesses é uma estratégia clássica da Engenharia de Software que tem por objetivo facilitar a manutenção, a portabilidade e a evolução da lógica de uma aplicação sensível a contexto. Uma vez que o modelo SeCoM é baseado na linguagem de ontologia OWL, ele adiciona a uma aplicação a habilidade de poder inferir sobre informações de contexto instanciadas a partir desse modelo.
Os serviços da infra-estrutura SCK também facilitam o desenvolvimento de aplicações sensíveis a contexto devido às seguintes razões: (a) essas aplicações não necessitam implementar toda sua infra-estrutura para armazenar, consultar e inferir informações de contexto; (b) a infra-estrutura SCK utiliza um formato uniforme e padrão de intercâmbio de informações de contexto, no caso, o modelo de triplas RDF [Manola & Miller, 2004]; e (c) aplicações se beneficiam do aspecto de configurabilidade dos serviços da infra-estrutura SCK.
Uma instância da (a4) atividade de verificação e validação
Durante esta atividade, os (u4) validadores devem ter uma preocupação especial com os requisitos não-funcionais.
Considerando a expressividade de modelos de informação contextual, algumas ontologias do modelo SeCoM têm o mais alto nível de expressividade que uma ontologia OWL pode alcançar. Por exemplo, as ontologias Activity e Spatial possuem a expressividade de Lógica de Descrições do tipo SHOIN(D)1. Isto tem implicações quanto à complexidade de tempo de processos de inferência que é, por sua vez, uma
1Lógica de atributos, complemento, propriedades transitiva e inversa, hierarquia de propriedades,
preocupação relacionada ao desempenho de sistemas computacionais.
O modelo SeCoM é um modelo de informação contextual viável porque sua arqui- tetura em duas camadas permite que aplicações o reusem e/ou estendam para seus propósitos. A viabilidade é comprovada por medidas realizadas com respeito ao tempo de importação de cada ontologia do modelo SeCoM, que é, em média, menor que 2% do tempo de resposta total de inferência sobre cada ontologia.
Com relação a requisitos não-funcionais, este trabalho sugere que validadores investiguem, principalmente, o comportamento temporal do serviço de inferência da infra-estrutura SCK. Devem ser consideradas, por exemplo, a capacidade de infe- rência e a variedade de serviços suportadas por cada máquina de inferência a ser utilizada com o serviço em questão. A implementação atual do serviço de inferência fornece suporte completo a informações de contexto codificadas em OWL, assim como a habilidade de medir tempos intermediários do processo de inferência.