Detecting Multiples ellipses

En esta sección se mostrará la forma de conectar el sistema de inferencia (agente inteligente) descrito en los capítulos anteriores.

El aspecto de contexto no determinístico tiene un resultado nominal, por lo tanto puede tratarse de igual manera que un aspecto de contexto determinístico en la capa de servicios.

El sistema de inferencia puede verse como una capa de software intermedia entre la capa “Aspectos de sensado” y la capa “Aspectos de contexto”. Los aspectos de contexto atómicos utilizados para inferir el aspecto de contexto de alto nivel, no están vinculados con el contexto del usuario; en cambio el aspecto de contexto inferido si lo está.

En la arquitectura del sistema de inferencia se incorporó la clase “Control de sensores” cuyas responsabilidades son:

•Administrar la relación con los sensores.

•Administrar el mecanismo de dependencias por cambio en los sensores.

•Administrar la relación entre los sensores y los atributos de inferencia

(aspectos de contexto atómicos).

El modelo planteado es demasiado “simplista”, ya que no considera problemas de bajo nivel tales como las políticas de sensado y el tratamiento de errores. Por este motivo es necesario cambiar las responsabilidades del “Control de sensores” y aprovechar las capas “abstracciones del hardware” y “aspectos de sensado” provistas por el framework.

7.4.1 Capa de software intermedia

El SensingConcern de la capa “Aspecto de contexto” convierte el valor recogido por el sensor en un objeto del dominio del aspecto de contexto relacionado. La lógica de conversión se efectúa mediante una estructura tipo “Diccionario”, es decir, para cada valor sensado se obtiene unívocamente el valor correspondiente del aspecto de contexto tratado.

Para que la conexión entre el sistema de inferencia y las clases del framework sea efectiva, es evidente que se debe convertir al mecanismo de inferencia en “algo” cuya funcionalidad sea parecida a la de un SensingConcern. De esta manera resulta transparente para el framework el procedimiento por el cual se obtiene un aspecto de contexto a partir del valor sensado. Para generalizar la funcionalidad del SensingConcern se debe tener en cuenta que deberá operar con dos tipos de aspectos de contexto:

• Aspecto de contexto determinístico: convierte un valor sensado en un

objeto aspecto de contexto por medio de una estructura tipo diccionario (la conversión es unívoca).

• Aspecto de contexto no determinístico: convierte valores sensados en un objeto aspecto de contexto mediante un algoritmo de inferencia (la conversión tiene incertidumbre).

De la explicación anterior surge la diferencia entre la semántica y funcionalidad entre un atributo y un aspecto de contexto. Un atributo tiene la funcionalidad que le impone el algoritmo de inferencia. Un aspecto de contexto debe tener la funcionalidad relacionada con la sensibilidad al contexto impuesta por el framework.

Para hacer portable el sistema de inferencia y permitir una evolución independiente del mismo, resulta clara la necesidad de no “contaminar” la funcionalidad de los objetos atributo y aspecto de aspecto. Sin embargo, al mismo tiempo debemos asociarlos de algún modo para que colaboren entre sí.

Una manera eficiente de separar la funcionalidad de los objetos, pero a su vez hacer que colaboren entre sí, es mediante el patrón de diseño “Decorator” [Gamma 1995].

Figura 7.5 Relación aspectos de contexto y atributos

El rol de “decorador” lo cumple el aspecto de contexto concreto y el rol de decorado el atributo del sistema de inferencia. El aspecto de contexto tiene una variable de instancia que apunta al atributo relacionado. El aspecto de contexto delega toda funcionalidad que sea relativa a la inferencia, sólo implementa la funcionalidad sensible a contexto.

Existen dos tipos de atributos en el sistema de inferencia, ellos son:

• Atributo de inferencia: es necesario para efectuar la inferencia del

atributo clase. No está relacionado con el “contexto” del usuario, es interno al sistema de inferencia.

• Atributo clase: es el resultado del sistema de inferencia. Está

relacionado directamente con el contexto del usuario.

Con el esquema planteado, la conexión entre cada SensingConcern del framework y cada aspecto de contexto atómico quedaría de la siguiente forma (figura 7.6).

7.4.2 Control de sensores

Dado que la funcionalidad de administrar los sensores pasa a formar parte de las clases del framework; el comportamiento del Control de sensores cambia ligeramente. Ahora este pasa a tener dos funcionalidades importantes:

•Administrar los cambios en los aspectos de contexto atómicos. •Construir el “caso” para luego inferir la clase que le corresponde. La relación del Control de sensores y los aspectos de contexto quedaría de la siguiente manera (figura 7.7):

Figura 7.7 Relación Control de sensores y aspectos de contexto

7.4.3 Control principal

El Control de sensores del sistema de inferencia convierte la información proveniente de sensores en un “caso” a clasificar, y luego pasa el control al Control principal. Este último pasa el “caso” a la base de reglas y obtiene la clase que le corresponde. La clase es un valor del dominio del atributo clase y por ende del aspecto de contexto relacionado. A partir de ese momento el aspecto de contexto se comporta de manera semejante a cualquier aspecto de contexto determinístico.

La conexión entre el resultado del algoritmo de inferencia y las clases del framework queda de la siguiente manera (figura 7.8):

ControlPpal atributoClase controlSensores baseReglas clasificar() nuevoCaso() AspectoContexto

fuzzySets : Col de FuzzySets valorMinimo : Double valorMaximo : Double valorCrisp : Double atributo observador : Object fuzzificar() cambioEstado()

El atributo clase tiene la misma característica estructural que un aspecto de contexto de inferencia, es decir, las mismas variables de instancia.

7.4.4 Restricciones en la capa de servicios

La capa de servicios del framework dispone de una jerarquía de objetos Constraints, necesarios en la configuración de las restricciones que debe evaluar el ServiceProvider para otorgar servicios disponibles a los usuarios. El framework posibilita incorporar tres tipos de restricciones:

• Simple: se refiere a un aspecto en particular. Por ejemplo, en el aspecto

de contexto Locación se puede ingresar la restricción Locación = “Aula 1”.

• Nula: no es una restricción. Los servicios contenidos en el

ServiceProvider se brindan al usuario en cualquier circunstancia. Por ejemplo, información general para toda persona que pase por la facultad.

• Compuesta: se refiere a la combinación de varios aspectos de contexto.