Aula 05 - Contexto e Sensibilidade ao Contexto

Foram discutidos nesta aula assuntos relacionados ao contexto: histórico, definições e sistemas sensíveis ao contexto.

Inicialmente foi apresentado o contexto em Lógica. A lógica na sua tentativa de formalizar o pensamento humano faz uso de expressões cujos valores verdade dependem do contexto implícito. Por exemplo, ao avaliar a expressão "Brasília é a capital do Brasil" constatamos que ela é verdadeira. Todavia se essa expressão fosse avaliada em 1900, a resposta seria diferente, pois estaríamos em outra época. Percebemos que o tempo, que está implícito, é o contexto que influência a avaliação da expressão.

Em seguida vimos que o contexto em linguagens de programação está relacionado, no caso do paradigma imperativo, com o contexto estático (constantes, definições) e com o contexto dinâmico (comportamento durante a execução de um programa). Discutimos ainda a necessidade de um paradigma para aplicações ubíquas.

Um sistema tradicional é composto por: entrada, processamento e saída. Um sistema sensível ao contexto agrega um novo elemento: o contexto. Que influência o seu comportamento de acordo com a percepção do ambiente.

Foram apresentadas diversas definições de contexto, baseadas essencialmente no artigo Towards a Better Understanding of Context and Context-Awareness (Anind K. Dey and Gregory D. Abowd, 1999), que será o segundo artigo a ser resumido e discutido na disciplina.

De um modo geral essas definições afirmam que o contexto é um conjunto de informações relacionadas a localização, tempo, estado de entidades, entre outras. No entanto as definições têm diferenças. Por exemplo, na definição de Dey e Abowd (1999) essas entidades devem ser relevantes para a interação entre um usuário e uma aplicação. Já na definição de Viana (2010), o contexto pode ser utilizado em um momento posterior  para melhorar interação com o usuário ou adaptar a aplicação ou o conteúdo acessado. Viana apresenta ainda os conceitos de zona de observação (o que pode ser observado pelo sistema) e o de zona de interesse (o que o sistema deseja observar). O ontexto, num dado instante, é a interseção dessas zonas (Veja a figura abaixo adaptada de Viana (2010)). 

O contexto possui uma natureza evolutiva, isto é, elementos (entidades e relações) podem ser incluídos ou removidos. Possui ainda uma natureza dinâmica, o estado das entidades (e suas relações) que o compõe variam com o tempo. Viana (2010) representa a natureza evolutiva em função dos conceitos de zona de interesse e zona de observação. Essa relação pode ser entendida da seguinte maneira: com o passar do tempo tanto o que é de interesse do sistema quanto o que ele pode observar variam. Dessa forma, a interseção entre as duas zonas (o contexto) pode se modificar (aumentar ou diminuir) com o passar do tempo.

Sistemas sensíveis ao contexto foi um dos últimos temas discutidos. Eles são capazes de utilizar o contexto para mudar seu comportamento e prover serviços adequados aos seus usuários. Antes de concluir as discussões sobre contexto o Professor Lincoln apresentou sua definição para Sistema Ubíquo:

“Um sistema ubíquo pode ser entendido como um sistema distribuído, móvel ou não, onde seus componentes se agrupam de maneira dinâmica, espontânea, transparente e colaborativa para o compartilhamento de recursos, serviços e informações com o intuito de executar um conjunto de atividades particular em um determinado contexto.”

E logo após para Sistema Ubíquo Sensível ao Contexto:

“Assim, um sistema ubíquo sensível ao contexto é um sistema que utiliza o contexto (ou histórico de contexto) para garantir a realização da sua função, podendo para isso, alterar a sua interface de serviço ou modificar sua estrutura para gerar um novo comportamento.”

As notas de aula referentes a esta aula, ministrada em 01/03/2011, podem ser baixadas aqui.

Aula 04 - Computação Ubíqua: Requisitos Desafiadores

Como citou o Paulo Ramon no post da aula 3 da nossa disciplina, há muito a ser vencido para que essa coisa toda de ubiquidade seja posta em prática. Na nossa quarta aula vimos que são mais do que desafiadores os requisitos para tornar real esse novo paradigma. Principalmente os requisitos não funcionais que se tornam cada vez mais difíceis de serem modelados.

Foram listados alguns requisitos que são desafiadores como a Mobilidade, que é fundamental na computação ubíqua. Dispositivos podem se mover, assim como pessoas e até mesmo o código dos programas. Então, como prever para quais dispositivos nosso código vai se mover? A capabilidade de cada um?

Um novo conceito foi nos apresentado, Contexto. Agora as nossas aplicações devem ser capazes de identificar situações do ambiente que podem influenciar diretamente no comportamento dela. A definição de contexto será melhor apresentada no post da próxima aula que será feito pelo Adriano Dodo.

Temos agora que nos preocupar com a heterogeneidade de dispositivos. Quantidade e diversidade destes dispositivos e aplicações que estarão disponíveis assim como fazer esses diversos dispositivos e aplicações se comunicarem e cooperarem para atingir seus objetivos.

A computação ubíqua também prever que os dispositivos poderão tomar decisões de forma autônoma, percebendo o ambiente, identificando atores e mudanças no contexto. Com isso temos que nos preocupar agora também com a privacidade. Cuidados devem ser tomados para que os usuários não se sintam invadidos.

É necessário que os dispositivos estejam sempre disponíveis e sejam invisíveis, as pessoas não precisam ver o perceber que os dispositivos ubíquos ou aplicações estejam espalhados pelo ambiente. As aplicações também devem adaptar seu conteúdo para diferentes dispositivos, redes e usuários. Elas devem se reconfigurar de acordo com o ambiente e o dispositivo que elas se encontram, e serem tolerantes a falhas e   exceções que podem ocorrer no ambiente.

Agora mais que nunca a portabilidade, que se caracteriza pela independência de hardware, sistema operacional ou linguagem de programação, se torna necessária. O reuso de soluções já criadas se torna fundamental na computação ubíqua.

Para tentar resolver todos esses problemas existem algumas soluções como: Sistemas de Middleware, Componentes de Software, Meta Modelos para ambientes heterogêneos, Coordenação do Contexto entre outras.

Discutimos as principais limitações para o desenvolvimento de software ubíquo e vimos que essas soluções listadas anteriormente são específicas para problemas isolados, não existindo uma preocupação com todas as etapas do desenvolvimento. A reutilização é negligenciada ou tratada de maneira não sistemática. O foco é colocado na implementação em detrimento da modelagem e as linguagens de programação atuais não são adequados para o desenvolvimento de software ubíquo.

Vimos que alguns processos de desenvolvimento da engenharia de software, como Linha de Produto de Software, Desenvolvimento Generativo de Software e Desenvolvimento Baseado em Componentes são limitados uma vez que não foram concebidos para lidar com esse tipo de software. O problema parece está na concepção do modelo computacional.

Por fim, vimos que novos direcionamentos como a Ubiquitous Abstract Machine, proposta por Robin Milner, que é uma alternativa a visão da máquina de von Neuman, podem nos ajudar no desenvolvimento de sistemas ubíquos.

As notas de aula referentes a esta aula, ministrada em 28/02/2011, podem ser baixadas aqui.