Inteligencia Artificial TP Kappa Mauricio Notti - Pablo Pilotti - Pablo Speciale
Etapa 1 : Se solicita desarrollar en Kappa_PC un sistema capaz de hacer un pronóstico del estado del tiempo, solicitando al usuario la menor cantidad de información necesaria. Para modelar los conocimientos de dominio creamos varias clases e instancias aprovechando las facilidades que posee Kappa PC para esta tarea. La estructura que diseñamos es la siguiente: En primer lugar se pueden observar las clases predefinidas por Kappa PC. Dentro de las clases que definimos, las principales son Nube, Viento y EstadoClima. En la clase Nube se almacena la información que corresponde a las características de las nubes. Los slots de esta clase son: Nube:Altura. Valores permitidos: Baja, Media, Alta. Nube:Aspecto.Valores permitidos: Algodón, Capas. Nube:Clase. Nube:Clase = Nube. Para clasificar las nubes, generamos dos clases TipoEstrato y TipoCúmulo que heredan las características de la clase Nube y nos permiten distinguir entre los dos tipos principales de nubes, estratos y cúmulos. En cada una de ellas seteamos los valores que identifican a cada tipo. TipoEstrato:Clase = TipoEstrato TipoEstrato:Aspecto = Capas TipoCumulo:Clase = TipoCúmulo TipoCumulo:Aspecto = Algodón TipoCumulo:Altura. Valores permitidos: Alta, Baja. Dentro de las nubes de "tipo estrato" distinguimos tres posibles casos, Estratos, NimboEstrato y CirroEstrato. Estos tres tipos se diferencian en la altura: Estrato:Clase = Estrato Estrato:Altura = Baja NimboEstrato:Clase = NimboEstrato NimboEstrato:Altura = Media CirroEstrato:Clase = CirroEstrato CirroEstrato:Altura = Alta Dentro de la clase "tipo cúmulo" tenemos los Cumulos y los CumuloNimbos: Cumulo:Clase = Cumulo Cumulo:Color = Blanco CumuloNimbo:Clase = CumuloNimbo
CumuloNimbo:Color = Gris De forma similar, definimos la clase Viento con sólo un slot: Viento:Dirección. Valores permitidos: NES, SN, NS. También necesitamos modelar y almacenar los conocimientos sobre el clima y el pronóstico. Con este motivo generamos la clase EstadoClima: EstadoClima:HayNubes. Valores de tipo booleano. EstadoClima:HayViento. Valores de tipo booleano. EstadoClima:Pronostico. Valores permitidos: Soleado, BuenTiempo, Chubascos, Lluvia24hs, LluviaBreve, LluviaLigera, LluviaProlongada, LluviaPersistente. Al iniciar el sistema se crea una instancia de esta clase ya que esta información será requerida en todas las circunstancias. La instancia la llamamos climaactual. En el caso de las nubes y el viento, se creará las instancia sólo cuando sea necesario. Las instancias las creamos con MakeInstance(@inst, @<class>). Una observación interesante es que la instancia nube se crea bajo la clase Nube y luego va cambiando a medida que se determina el tipo de la nube. Para implementar esto, Kappa PC provee la llamada MoveInstance(@inst, @newclass). Una vez descripta la estructura de nuestra base de conocimientos, pasaremos a detallar las reglas con las que trabajará el motor de inferencia. Para trabajar con la metodología FordwardChaining, diferenciamos tres tipos de reglas. Las que setean las configuraciones iniciales, encargadas de consultar si hay o no nubes y viento y crear las correspondientes instancias. Este conjunto de reglas está compuesto por: RSetHayNubes Not( KnownValue?( climaactual, HayNubes ) ) THEN AskValue( climaactual, HayNubes ) RSetHayViento Instance?( nube ) And ( nube:clase #= Estrato Or nube:clase #= NimboEstrato Or nube:clase #= CirroEstrato ) And Not( KnownValue?( climaactual, HayViento ) THEN AskValue( climaactual, HayViento ) RHayNubes climaactual:haynubes #= TRUE And Not( Instance?( nube ) ) THEN { MakeInstance( nube, Nube ); AskValue( nube, Aspecto ); AskValue( nube, Altura ); } RHayVientos climaactual:hayviento #= TRUE And Not( Instance?( viento ) ) THEN { MakeInstance( viento, Viento ); AskValue( viento, Direccion ); }
El segundo tipo de reglas que distinguimos es el de las de clasificación de nubes.este conjunto de reglas está compuesto por: RHayTipoCumulos Instance?( nube ) And nube:clase #= Nube And nube:aspecto #= Algodon And ( nube:altura #= Alta Or nube:altura #= Baja ) THEN { MoveInstance( nube, TipoCumulo ); AskValue( nube, Color ); } RHayTipoEstratos Instance?( nube ) And nube:clase #= Nube And nube:aspecto #= Capas THEN MoveInstance( nube, TipoEstrato ); RHayCumulos Instance?( nube ) And nube:clase #= TipoCumulo And nube:color #= Blanco THEN { MoveInstance( nube, Cumulo ); Assert( nube, Clase ); } RHayCumuloNimbos Instance?( nube ) And nube:clase #= TipoCumulo And nube:color #= Gris THEN { MoveInstance( nube, CumuloNimbo ); Assert( nube, Clase ); } RHayEstratos Instance?( nube ) And nube:clase #= TipoEstrato And nube:altura #= Baja THEN { MoveInstance( nube, Estrato ); Assert( nube, Clase ); } RHayNimboEstratos Instance?( nube ) And nube:clase #= TipoEstrato And nube:altura #= Media THEN { MoveInstance( nube, NimboEstrato ); Assert( nube, Clase ); } RHayCirroEstratos Instance?( nube ) And nube:clase #= TipoEstrato And nube:altura #= Alta THEN { MoveInstance( nube, CirroEstrato ); Assert( nube, Clase ); } Y por último el tercer grupo de reglas, que son las de pronóstico. Estas reglas se encargan de setear el valor de climaactual:pronostico que representa la conclusión obtenida por el sistema a partir de los datos de entrada. Según el texto analizado, es necesario considerar las siguientes casos: RSoleado
THEN climaactual:haynubes #= FALSE climaactual:pronostico = Soleado THEN RBuenTiempo Instance?( nube ) And nube:clase #= Cumulo climaactual:pronostico = BuenTiempo THEN RLluviaLigera Instance?( nube ) And nube:clase #= Estrato And ( ( Instance?( viento ) And Not( viento:direccion #= NES ) ) Or climaactual:hayviento #= FALSE ) climaactual:pronostico = LluviaLigera THEN RLluviaProlongada Instance?( nube ) And Instance?( viento ) And nube:clase #= Estrato And viento:direccion #= NES climaactual:pronostico = LluviaProlongada RLluviaBreve Instance?( nube ) And nube:clase #= NimboEstrato And Instance?( viento ) And viento:direccion #= SN THEN climaactual:pronostico = LluviaBreve RLluviaPersistente Instance?( nube ) And nube:clase #= NimboEstrato And Instance?( viento ) And viento:direccion #= NES THEN climaactual:pronostico = LluviaPersistente THEN RChubascos Instance?( nube ) And nube:clase #= CumuloNimbo climaactual:pronostico = Chubascos RLluvia24hs Instance?( nube ) And nube:clase #= CirroEstrato And Instance?( viento ) And viento:direccion #= NS THEN climaactual:pronostico = Lluvia24hs En el caso de BackwardChaining, hicimos algunas modificaciones que simplificaron el modelo, con el objetivo de que el sistema siga haciendo la menor cantidad de preguntas necesarias. La modificación más importante fue eliminación de las reglas se seteo, que ya no eran necesarias, y de las las reglas de clasificación de nubes. Esto tuvo como consecuencia la modificación de las clausulas if del conjunto de reglas de pronóstico para poder diferencias
entre los diferentes tipos de nubes y el el agredo al la clausula then para que cree la instancia necesaria sí es que corresponde. En conjunto de reglas es el siguiente: THEN RSoleado climaactual:haynubes #= FALSE climaactual:pronostico = Soleado RBuenTiempo climaactual:haynubes #= TRUE And Nube:Aspecto #= Algodon And ( Nube:Altura #= Alta Or Nube:Altura #= Baja ) And Nube:Aspecto #= Algodon And Nube:Color #= Blanco THEN { MakeInstance( nube, Cumulo ); climaactual:pronostico = BuenTiempo; } RLluviaLigera climaactual:haynubes #= TRUE And Nube:Aspecto #= Capas And Nube:Altura #= Baja And (climaactual:hayviento #= FALSE Or (climaactual:hayviento #= TRUE And Not( Viento:Direccion #= NES))) THEN { MakeInstance( nube, Estrato ); climaactual:pronostico = LluviaLigera; } RLluviaProlongada climaactual:haynubes #= TRUE And Nube:Aspecto #= Capas And Nube:Altura #= Baja And climaactual:hayviento #= TRUE And Viento:Direccion #= NES THEN { MakeInstance(nube, Estrato); climaactual:pronostico = LluviaProlongada; } THEN RLluviaBreve climaactual:haynubes #= TRUE And Nube:Aspecto #= Capas And Nube:Altura #= Media And climaactual:hayviento #= TRUE And Viento:Direccion #= SN {MakeInstance(nube, NimboEstrato); climaactual:pronostico =LluviaBreve;} RLluviaPersistente climaactual:haynubes #= TRUE And Nube:Aspecto #= Capas And Nube:Altura #= Media And climaactual:hayviento #= TRUE And Viento:Direccion #= NES THEN { MakeInstance( nube, NimboEstrato ); climaactual:pronostico = LluviaPersistente; } RChubascos climaactual:haynubes #= TRUE And Nube:Aspecto #= Algodon And ( Nube:Altura #= Alta Or Nube:Altura #= Baja )
And Nube:Color #= Gris THEN { MakeInstance( nube, CumuloNimbo ); climaactual:pronostico = Chubascos; } RLluvia24hs climaactual:haynubes #= TRUE And Nube:Aspecto #= Capas And Nube:Altura #= Alta And climaactual:hayviento #= TRUE And Viento:Direccion #= NS THEN {MakeInstance( nube, CirroEstrato ); climaactual:pronostico = Lluvia24hs; } Además de las reglas y la estructura de clases, agregamos una botonera gráfica que facilitar la ejecución del sistema en sus diferentes modos y estrategias. Esto lo hicimos con las utilidades que provee Kappa PC a través del Session Windows. Se pueden observar los paneles en la siguiente imagen. La funcionalidad de estos botones está implementada a través de funciones de usuario. Por ejemplo el botón DepthFirst ejecuta la función RunDepthFirst que tiene la siguiente forma. RunDepthFirst Body { SetForwardChainMode(DEPTHFIRST); ForwardChain([NOASSERT]); PostMessage( "El tiempo es...cha cha channn ", GetValue( climaactual, Pronostico ) ); }; Otro ejemplo es la función reset() para el backward chaining, que se encarga de resetear las condiciones iniciales de sistema. Reset Body { If Instance?( nube ) Then DeleteInstance( nube ); If Instance?( viento ) Then DeleteInstance( viento );
If Instance?( climaactual ) Then DeleteInstance( climaactual ); MakeInstance( climaactual, EstadoClima ); ResetValue( climaactual:pronostico ); ResetValue( climaactual:haynubes ); ResetValue( climaactual:hayviento ); ResetValue( Nube:Altura ); ResetValue( Nube:Aspecto ); ResetValue( Nube:Color ); ResetValue( Viento:Direccion ); }; Etapa 2: Basándose en el problema sugerido, se deberá estudiar el funcionamiento del motor de inferencias de KAPPA-PC. 1. Funcionamiento Sistemático: Forward chaining Es un mecanismo de razonamiento que comienza con las condiciones o datos y se dirige hacia las conclusiones o metas. Forward chaining empieza cuando un objeto:slot es removido de la agenda. Este par representa un cambio reciente, en consecuencia se buscan las reglas activas y se las agrega a la lista de reglas. Una regla es activada por un objeto:slot si esta lo contiene en su premisa. A continuación el motor de inferencia busca una regla cuya premisa sea TRUE y la aplica, de lo contrario la elimina de la lista. El algoritmo termina cuando no hay mas reglas para aplicar o cuando concluye una meta preestablecida. Existen varias formas de insertar reglas en la lista y para eliminar ítems de la agenda llamadas estrategias. Las estrategias en forward chaining pueden ser seteadas mediante la función: SetForwardChainMode(ruleChainMode, agendamode). El primer argumento setea la estrategia de búsqueda. Puede ser uno de los siguientes valores: SELECTIVE, DEPTHFIRST, BREADTHFIRST o BESTFIRST. Las diferencias entre las distintas estrategias serán tratadas más adelante. El segundo argumento setea la estrategia de resolución de conflictos en la agenda. Los argumentos pueden ser: IGNORE o NO IGNORE. Si esta seteada la opción IGNORE, la agenda de hechos no procesara un ítem si hay una versión reciente del mismo, en cambio si esta seteada en NOIGNORE se procesaran todos los ítem, estén o no repetidos. El propósito de las estrategias es modificar el modo de resolución de conflictos tanto para la selección de reglas como para la de ítem de la agenda. Kappa Pc cuenta con las siguientes estrategias de selección de reglas:
Evaluación Selectiva Esta estrategia expande el árbol de búsqueda por la rama correspondiente a la primer regla activa de la lista, descartando a las demás. Vamos a tomar como ejemplo el sistema que pronostica el estado del tiempo, con el apoyo del rule trace en step mode, para mostrar con mas detalle esta estrategia. Ejemplo: Inicialmente el motor de inferencia examina todas las reglas de la lista y ejecuta la primer regla que encuentra activa, en este caso la primer regla activa es RSetHayNubes, que fue construida de la siguiente manera: MakeRule( RSetHayNubes, [], Not( KnownValue?( climaactual, HayNubes ) ), { AskValue( climaactual, HayNubes ); } ); Al ejecutarse, se lanza cuadro de dialogo que solicita información sobre si hay nubes. Es importante observar que la lista de reglas está ordenada por la prioridad. En nuestro caso todas las reglas tienen la misma prioridad, por lo que no hacemos suposiciones sobre el orden de la lista. Luego del ingreso del usuario -en este ejemplo: FALSE- se agrega el nuevo ítem en la agenda como muestra la figura.
A continuación se descartan todas las reglas de la lista y se agregan solo las reglas que activa el primer ítem de la agenda, eliminándose este último. Como vemos en la figura, RHayNubes y RSoleado, son las únicas activas. Si hay ítems en la agenda y reglas en la lista, el motor de inferencia tiene como prioridad eliminar ítems de la agenda. Luego de vaciar la agenda se busca una nueva regla para ejecutar y el proceso continuara por esa rama. Con el inference browser observamos el camino que siguió el motor de inferencia.
Evaluación Primero en profundidad Esta estrategia expande el árbol de búsqueda por la rama correspondiente a la primer regla activa de la lista, y luego agrega las nuevas reglas en el principio de la lista. Al igual que la evaluación anterior, eliminar ítems de la agenda tiene prioridad sobre la evaluación de las reglas. Por lo tanto la única diferencia que tiene con la evaluación selectiva es que en vez de eliminar reglas de la lista, las agrega al principio. La evaluación primero en profundidad tiene la desventaja de consumir mucha memoria, la cantidad de reglas es exponencial en función de la profundidad, pero la ventaja de ser completa, ya que explora todo el árbol de búsqueda. Investigando esta estrategia encontramos algunas diferencias con el manual. Un ejemplo mostrará esto con más detalle: Ejemplo: Inicialmente todas las reglas están activas, la primera en dispararse es RSetHayNubes. Luego del ingreso del usuario - esta vez supongamos TRUE- se agrega el slot climaactua:haynubes.
A continuación se elimina el ítem de la agenda agregando las reglas al principio de la lista. Aquí la primer diferencia: debido que las reglas ya se encuentran en la lista no las agrega, dejando la lista en el mismo estado. El problema de hacer esto es que pueden evaluarse reglas en un orden diferente al que corresponde. Como veremos más adelante. Continuando con el ejemplo, vemos que al comenzar a evaluar, la primer regla que se aplica es RHayNubes. Como resultado se agregan los ítems nube:altura y nube:aspecto con el valor ingresado por el usuario, en esta corrida fueron: Algodón y Alta respectivamente.
Dos observaciones importantes que no menciona el manual son: la primera, los ítems se agregan y se sacan por el principio de la lista. La segunda, eliminación de ítems en la agenda se realiza de manera perezosa (lazzy). En otras palabras, en el caso de haber más de un ítem en la agenda, en lugar de eliminarlos a todos, el motor de inferencia elimina el primer ítem (agregando las reglas a la lista) y luego evalúa las reglas de la lista. En este caso, eliminar el ítem nube:altura activa las reglas RHayEstratos, RHayNimboEstratos, RHayCirroEstratos. Pero, como observamos antes, no las agrega. A continuación comienza la evaluación de las reglas y notamos que evalúa RSetHayViento antes de cualquier regla disparada por nube:altura. Notamos entonces que no se evalúan las reglas en el orden deseado. Estos problemas pudieron ser manejados gracias a la función Assert. Evaluación Primero a lo Ancho. Esta estrategia expande el árbol de búsqueda por la rama correspondiente a la primer regla activa de la lista, y luego agrega las nuevas reglas en el final de la lista. Al igual que la evaluación anterior, esta estrategia es completa pero utiliza más recursos que la evaluación selectiva.
La evaluación primero a lo ancho agrega las reglas en el final de la lista ordenadas según la prioridad. A diferencia de las estrategias anteriores, en el caso de que existan ítems en la agenda y reglas en la lista, el motor de inferencia le da prioridad a la eliminación de reglas. Para mostrar mejor esta estrategia vamos a ver un ejemplo. Ejemplo: El pronóstico que vamos a obtener es "lluvia ligera", el cual corresponde a los valores: climaactual:haynubes = TRUE nube:aspecto = Capas nube:altura = Baja climaactual:hayviento = FALSE En el comienzo se tiene todas las reglas que machean según los hechos actuales. Si proseguimos, nos preguntará si hay nubes. Y luego, una vez contestado "climaactual:haynubes = TRUE", se tiene climaactual:haynubes en la agenda, con su correspondiente Rule list: Si hay ítems en la agenda y reglas en la lista, el motor de inferencia tiene como prioridad eliminar ítems de la lista. Como la primera regla RHayNubes es la que machea, entonces dicha regla se evalúa. Ahora, se nos preguntará por el "Aspecto" y la "Altura". Como ya habíamos adelantado, estos valores son Capas y Baja, respectivamente. De esta manera, se agrega en la agenda nube:aspecto y nube:altura:
Nuevamente, el motor de inferencia trata de consumir la lista de regla (pues tiene prioridad la lista): Como ya se consumieron todas las reglas de la lista, se pasa a consumir los ítems de la agenda. El ítem en cuestión es climaactual:haynubes: A modo de ilustración de la estrategia a quedado claro que primero intenta consumir las reglas de la lista. Entonces, el proceso continuará así y se nos preguntará si hay viento, de esta manera, podrá concluir que el pronóstico es "lluvia ligera" (si es que la pregunta fue contestada con FALSE). Evaluación Primero el mejor Esta estrategia expande el árbol de búsqueda por la rama correspondiente a la primer regla activa de la lista, y luego agrega las nuevas reglas de manera tal que la lista queda ordenada según la prioridad. Es decir, que esta estrategia es similar a evaluación primero a lo profundo, pero tiene en cuenta las prioridades. Al igual que la evaluación anterior, esta estrategia es completa pero utiliza más recursos que la evaluación selectiva. A diferencia de la estrategia anterior, en el caso de que existan ítems en la agenda y reglas en
la lista, el motor de inferencia le da prioridad a la agenda. En nuestro modelo todas las reglas tienen la misma prioridad, por lo que esta evaluación se comporta igual que la evaluación primero en profundidad. Backward Chaining El aspecto principal del Backward Chaining es que el razonamiento está guiado por lo que denominamos un objetivo o goal (en Fordward Chaining, el goal es opcional). Un goal es un hecho, o conjunto de hechos, que queremos verificar. Para esto, el sistema de inferencia selecciona las reglas cuyas post-condiciones matchean (i.e. prueban) algún hecho del goal, y luego trata de verificar las pre-condiciones correspondientes. Estas pre-condiciones pasan a ser nuevos subgoals. El proceso se reitera hasta poder satisfacer las pre-condiciones necesarias para alcanzar el goal principal, o hasta agotar todas las posibilidades. Podemos analizar el comportamiento del Backward Chaining distinguiendo tres pasos. Una vez fijado el goal, el primero de los pasos consiste en determinar si este ha sido satisfecho o no. La validez del goal puede chequearse desde el SHELL de Kappa PC a través de la función "TestGoal(@goal)". En caso de que el goal no este satisfecho, tiene lugar un segundo paso en el cual se seleccionan las reglas que prueban los hechos en cuestión, analizando para cada una de ellas la condición de la clausula if y generando así los nuevos subgoals. Este paso se conoce como expansión. Es importante resaltar que en la implementación de Kappa PC, los hechos del goal se expanden de izquierda a derecha (esto puede observarse desde el Inference Browser). Una vez expandidos todo los hechos, es necesario consultar al usuario la información que no pueda deducirse a través de ninguna regla. Esta información corresponderá al valor de un cierto slot, que podrá ser ingresado por medio de un cuadro de diálogo. En los casos en los que se haya descripto la lista de valores permitidos del slot, Kappa PC mostrará la lista correspondiente. También es posible contestar con el valor desconocido. Una observación a destacar es que este paso es opcional. Para evitar las consultas sobre el valor de un slot en particular, puede setearse la opción de NOASK en dicho slot. Y para evitar todas las consultas, puede pasarse el parámetro [NOASK] al método de Kappa PC que implementa el Backward Chaining. Por medio del proceso descripto anteriormente el Backward Chaining genera un árbol de búsqueda. La construcción de este árbol puede analizarse paso a paso desde el Inference Browser. La raíz del árbol consiste en el goal principal. Los nodos de los demás niveles alternan entre dos tipos. Existen niveles donde los nodos representan slots de una clase o instancia (i.e. hechos), y niveles compuestos de reglas. El primer nivel está compuesto por nodos "tipo slot" que representan los hechos que componen al goal principal. Al expandir estos nodos se obtienen las reglas que componen el segundo nivel y los slot que forman el siguiente nivel. De esta forma es como se genera el árbol de búsqueda.
Hay varios aspectos a considerar a la hora de obtener modificaciones en la introducción de información. La información introducida corresponde siempre al valor de algún slot. Como mencionamos en el punto anterior, la modificación más importante que puede hacerse en este ámbito es evitar la consulta de información para todos los slots o para uno en particular, a través de las opciones de NOASK. Otro concepto importante relacionado con la introducción de información es el de los monitores (lo analizaremos en el punto tres ;-). También se puede elegir el tipo de los slots y su cardinalidad (uno o más valores). Los tipos predefinidos son TEXT, NUMBER, BOOLEAN y OBJECT. Para el tipo TEXT y OBJECT puede definirse una lista de valores permitidos. Para el tipo NUMBER puede setearse una cota máxima y una mínima. El tipo BOOLEAN consiste obviamente de los valores TRUE y FALSE. En el momento de consultar la información, Kappa PC despliega un cuadro de diálogo. En este cuadro puede setearse el prompt y agregar un comentario Además de las propiedades de los slots, hay más factores que influyen en la introducción de información. Por ejemplo, si la claúsula if de una regla está compuesta por el Or o el And de varios hechos, el orden en el que aparecen los hechos influye en las consultas realizadas en el proceso de Backward Chaining Como conclusión explicaremos las modificaciones que tuvimos que hacer al modelo usado en forward chaining para poder correrlo con backward chaining. En nuestro caso, fue necesario hacer algunas modificaciones al modelo que diseñamos inicialmente basándonos en la metodología de razonamiento del Fordward Chaining. Las principales complicaciones surgieron del hecho de que incluimos reglas para clasificar las nubes y, al usar Backward Chaining, se activaban primero las reglas "más específicas" que consultan por ejemplo el color de las nubes, sin conocer previamente valores como el aspecto que permite distinguir entre los dos tipos principales de nubes (estratos y cúmulos). Esto trajo como
consecuencia que la información solicitada al usuario no sea mínima, es decir que en algunos casos se pedía información que podría no haber sido necesaria sí antes se hubiesen hechos las consultas correspondientes. Para solucionar esto, eliminamos las reglas de clasificación y agregamos esta información en las pre-condiciones de las reglas de pronóstico. 2. Otras estructuras de control: Monitores Empezaremos por explicar qué es un monitor en KappaPC. Los monitores son métodos que son activados cuando un par objeto:slot es accedido. Los monitores pueden ser vistos como funciones privadas o funciones que cambian el valor de los slots. KappaPC provee cuatro tipos de slots: If Needed: Este método se llamará automáticamente cuando el valor del slot sea requerido y el slot este indefinido. When Accessed: El método es ejecutado cuandl se accede el slot. La diferencia con el caso anterior es que el método sera lanzado aún cuando se conozca el valor del slot. Before Change: El método es automáticamente ejecutado justo antes que se setee el slot con el nuevo valor. After Change: El método es ejecutado automáticamente justo después de que cambie el slot. En nuestro caso no fue necesario utilizar slots, pero son una herramienta muy útil en este tipo de sistemas. Las funcionalidades más interesante que encontramos son la posibildad de activar y desactivar reglas invocando desde un monitor a las funciones "ActivateRule(@rule)" "DeactivateRule(@rule)". También puede ser interesante cambiar la prioridad de una regla mientras el sistema está en pleno funcionamiento. 3. Uso de Patterns en las reglas Si al enunciar una regla utilizamos un par instancia:slot, hacemos que la regla sea específica para esa instancia. Para evitar esto y crear reglas más generales que capturen un aspecto del sistema sobre todos los elementos de una misma clase, KappaPc propone las utilización de variables en las reglas. Estas variables son conocidas con el nombre de Patterns. Para definir un pattern usamos una expresión de la forma [var Class]. Var representará a cualquier instancia de la clase Class, y por lo tanto basta con reescribir la regla original substituyendo el nombre de la instancia particular por nuestra variable para obtener una regla general. En nuestro caso, podríamos definir [var_nube Nube] o [var_clima EstadoClima] para hacer las reglas más generales, pero no tiene mucho sentido ya que solo creamos una instancia de para cada una de las clases. En las pruebas que realizamos vemos que efectivamente el resultado es el mismo y se hace absurdo el uso de patterns. Más allá del poca utilidad que encontramos nuestro modelo, estamos convencidos de que el uso de variables es de gran utilidad, principalmente cuando se trabaja con sistemas de dimensiones reales en los que seguramente habrá varias instancias de cada clase.