Diseño e Implementación de Sistemas Basados en Conocimiento La metodología CommonKADS Diseño e Implementación de Sistemas Basados en Conocimiento 6.1 Introducción 6.2 Diseño que mantiene la estructura 6.3 Paso 1: Diseño arquitectura del sistema 6.4 Paso 2: Identificar plataforma implementación 6.5 Paso 3:Especificar componentes arquitectónicos 6.6 Paso 4: Especificar aplicación 6.7 Ejemplo de Implementación. Aplicación Vivienda en Prolog Carlos Alonso González Dpto. de Informática Universidad de Valladolid

6.1 Introducción Diseño Entrada Salida Modelo de conocimiento Requisitos funcionales relacionados con razonamiento Modelo de comunicación Requisitos funcionales relacionados con la interacción Otros modelos: requisitos no funcionales Salida Especificación de una arquitectura software Diseño de la aplicación sobre esta arquitectura

Arquitectura del sistema Fundamento del proceso de diseño Descripción de la estructura del software en términos de: Descomposición en subsistemas Régimen de Control Descomposición de subsistemas en módulos software CommonKADS proporciona Arquitectura de Referencia Esquema de arquitectura que se puede particularizar para diversos sistemas

6.2 Diseño que mantiene la estructura I Objetivo: minimizar diferencias entre especificaciones de la aplicación y especificaciones de la arquitectura Diseño que no mantiene la estructura Por ejemplo, Sistema Experto primera generación (una sola base de reglas, sin estructura) Se pierde distinción entre los distintos tipos de conocimiento Diseño que mantiene la estructura Conserva el contenido y la estructura de los modelos de análisis

Diseño que mantiene la estructura II “Mantener simultáneamente el contenido y la estructura del modelo de análisis durante el diseño” Principio fundamental de diseño moderno El diseño se contempla como “añadir detalles específicos de la implementación a los resultados del análisis” Directamente relacionado con criterios de calidad

Criterios de calidad para el diseño de Sistemas Basados en Conocimiento Reutilización de código/elementos de diseño Hace explícito el propósito de los fragmentos de código Facilita Mantenimiento y Adaptación Facilita el trazado de requisitos Explicación Permite explicar el proceso de razonamiento en términos del modelo de conocimiento Ayuda a la elicitación de conocimiento El modelo de conocimiento aporta semántica al código, facilitando Editores de conocimiento Aprendizaje, ...

Etapas proceso de diseño

6.3 Paso 1: Diseño arquitectura del sistema Descripción arquitectura Descomposición en subsistemas Régimen de Control Descomposición de subsistemas en módulos software CommonKADS propone una arquitectura de referencia, descrita a dos niveles Arquitectura del sistema global Arquitectura del subsistema “Modelo de Aplicación”

Arquitectura de referencia: Model-View-Controller

Subsistema “Modelo de Aplicación” En general, datos y funciones que proporcionan la funcionalidad de la aplicación En CommonKADS, el modelo de conocimiento Datos: Bases de conocimiento Datos dinámicos manipulados durante el razonamiento (papeles dinámicos) Funciones: Tareas, subtareas, inferencias y funciones de transferencia

Subsistema “vistas” Visualizar datos y funciones de aplicación Quizás múltiples visualizaciones del mismo elemento Combinar visualizaciones de múltiples elementos de la aplicación Desacoplo objetos/visualización Requiere mecanismos de actualización/integridad

Subsistema “controlador” “Unidad central de comando y control” Proporciona manejadores para eventos internos y externos Activa funciones de aplicación Puede definir sus propias vistas Puede incluir reloj interno y agenda Comportamiento tipo demon

Arquitectura del subsistema “Modelo de Aplicación” Principio Diseño que mantiene la estructura Opciones Descomposición funcional u orientada al objeto Elección: descomposición orientada al objeto Encaja bien con el carácter declarativo con que se especifican los componentes del modelo de conocimiento Simplifica asociación componentes-objetos si utilizamos implementación Orientada a Objeto

Arquitectura Subsistema “Modelo de Aplicación”

6.4 Paso 2: Identificar plataforma implementación Criterios selección Biblioteca de clases para “vistas” Su desarrollo requiere mucho trabajo de implementación Formalismos declarativos de representación de conocimiento idem Interfaces estándar con otro software ODBC, CORBA Suele ser necesario Lenguaje tipado Tipado débil supone mayor trabajo al volcar elementos de análisis Flujos de control Soporte CommonKADS

6.5 Paso 3: Especificar componentes arquitectónicos 3.1 Controlador Interfaz de gestor de eventos internos, externos ¿Control tipo demon (reloj y agenda)? ¿Se precisan interrupciones (en la ejecución de tareas)? ¿Necesidad de proceso concurrente?

Paso 3: Especificar componentes arquitectónicos 3.2 Vistas Tipos de vistas: ventanas, menús SQL, browsers ... Múltiples vistas, asegurando integridad Interfaces Interfaz de usuario final Facilidades especiales? Visualizaciones específicas del dominio Interfaz experto Interfaz para traza Interfaz para editar/refinar bases de conocimientos

Interfaz experto: traza

Paso 3: Especificar componentes arquitectónicos 3.3 Modelo de aplicación Tarea Método de Tarea Inferencia Método de Inferencia Función de Transferencia Papel Dinámico Papel Estático Modelo de Dominio Constructores del Dominio

Modelo de aplicación: facilidades (I) Tarea: Operaciones inicializar, ejecutar Método de tarea: Elementos del lenguaje de control ¿Declarativos o imperativos? Inferencia Ejecutar, ¿mas soluciones?, ¿tiene solución? Conexión con métodos de inferencia

Modelo de aplicación: facilidades (II) Método de inferencia (método computacional que realiza la inferencia) ¿Biblioteca de métodos? Relación “muchos-a-muchos” ente inferencias y métodos de inferencia Función de transferencia Mecanismo de paso de mensajes Papel Dinámico Tipos de datos permitidos: elemento, lista, conjunto ... Operaciones de acceso/modificación: seleccionar, añadir, eliminar ...

Modelo de aplicación: facilidades (III) Papel Estático Funciones de acceso/query Modelo de dominio (Base de Conocimiento) representación Funciones de modificación/análisis Constructores de dominio (Esquema de dominio) documentación

6.6 Paso 4: Especificar aplicación Se trata de especificar la aplicación en el contexto de la arquitectura Paso 4a: “proyectar la información de análisis sobre la arquitectura” “Proyectar” modelo de conocimiento y comunicación en la arquitectura e.g. para cada tarea Modelo Conocimiento, crear objeto tarea Asegura “conservación de la estructura” Proceso manual tedioso (ver pagina http://www.commonkads.uva.nl/) Paso 4b: “añadir detalles de diseño” Lista de detalles de diseño que hay que añadir para operazionalizar totalmente el modelo de análisis

4b: Añadir detalles de diseño Para el “modelo de aplicación” Para cada método de tarea: escribir estructura de control en el lenguaje proporcionado Para cada inferencia: Identificar asociación papeles con dominio Escribir la especificación de la invocación a la inferencia Método de inferencia Especificar un método de inferencia para cada inferencia Típico método razonamiento IA: encadenamiento hacia delante, ... Algoritmo estándar: ordenar, seleccionar, ... Para cada papel dinámico: Elegir tipo de dato

6.7 Ejemplo de Implementación. Aplicación Vivienda en PROLOG Implementación en PROLOG del Diseño que preserva la estructura de los modelos de análisis Plataforma software: Prolog 1 capa abstracción: facilidades o-o, objetos-CK, facilidades inferencias 2 capa abstracción: Modelo MVC

Implementación Prolog

O-O Kernel 1er capa sobre el núcleo Prolog Aporta conceptos orientación a objeto Objetivo: Facilitar implementación Prolog de la descomposicion de objetos del subsistema modelo de aplicación Facilidades para actualizar vistas requeridas por arquitectura MVC Proporciona tres tipos de primitivas O-O Definición de clases, atributos y operaciones Acciones, como creación de objetos, modificación de valores,... Queries, cómo acceder al valor actual de un atributo  oo_kernel.pl

CommonKADS Kernel 2a capa sobre el núcleo Prolog Aporta soporte CommonKADS en arquitectura MVC Objetivo Facilitar volcar modelo de comunicación en subsistema controlador Facilitar volcar modelo de conocimiento en subsistema modelo de aplicación Proporciona Soporte para descomposición de objetos del subsistema modelo de aplicación Incluye extensiones especificas para la arquitectura  ck_kernel.pl

Biblioteca de métodos de Inferencia Interprete de reglas con Encadenamiento hacia delante Encadenamiento hacia atrás inf_methods.pl

Realización de la aplicación 4a: Volcar modelo de análisis en la arquitectura Especializar las clases definidas en ck_kernel.pl E.g. Modelo conocimiento, Tareas: def_class(assess_case, task). def_class(abstract_case, task). def_class(match_case, task). E. g. Modelo de comunicación: def_class(order_assessment, transaction). def_class(get_case, transaction).... 4b: codificar extensiones especificas de la aplicación Definir tipos de datos para papeles dinámicos Para cada inferencia, implementar operación llamada al método de inferencia Para cada método de tarea, implementar método execute Escribir manipuladores de cada transacción 4b: codificar las vistas model.pl views_term.pl controller.pl