6. Diseño e Implementación deSistemas Basados en Conocimiento

6.1 Introducción6.2 Diseño que mantiene la estructura6.3 Paso 1: Diseño arquitectura del sistema6.4 Paso 2: Identificar plataforma implementación6.5 Paso 3:Especificar componentes arquitectónicos6.6 Paso 4: Especificar aplicación6.7 Ejemplo de Implementación. Aplicación Vivienda en Prolog

Carlos Alonso GonzálezDpto. de InformáticaUniversidad de Valladolid

La metodología CommonKADS

6-2

6.1 Introducción

Diseño

• Entrada– 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

6-3

Applicationdomain

Softwaresystem

communicationmodel

knowledgemodel

taskmodel

agentmodel

organizationmodel

designmodel

experts

textbooks

protocols

cases

reasoningstrategies

requiredresponse time

Analysismodels

problems &opportunities

implementationlanguage

softwarearchitecture

hardwareplatform

algorithmdesign

datastructuredesign

6-4

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-5

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

6-6

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

6-7

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, ...

6-8

design architecture

specifyhw/sw platform

detailedarchitecturespecification

detailedapplication

design

Step 1 Step 2 Step 3 Step 4

CommonKADS referencearchitecture

list ofavailableenvironments

checklistof architecuredecisions

predefinedmappingsto architecture

support knowledge for CommonKADS design

Etapas proceso de diseño

6-9

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”

6-10

Arquitectura de referencia:Model-View-Controller

application model

reasoning functions(tasks, inferences)domain schema(s)

controller

data/knowledge bases

views

provides outputto external agents

(user interface,database query)

handles input from external

agentsand from

internal functions

resultreport updatesfunction

invocationsinformation

access

controllerviews

User Input

Sensors

Databases

User interface

External system interface

6-11

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

6-12

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

6-13

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

6-14

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

6-15

Arquitectura Subsistema“Modelo de Aplicación”

dynamic role

datatypedomain-mappingcurrent binding

access/updatefunctions

task

I/O rolesmethod

execute

transferfunction

I/O roles

task method

intermediate rolescontrol specification

execute

static role

domain-mapping

access functionsdomain model

domain-model nameuses

access functionsinferencing functions

inference

I/O rolesstatic rolesmethod

give-solutionmore-solutions?has-solution?

inference method

algorithm speclocal vars

execute

domain construct

6-16

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-17

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?

6-18

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

6-19

Interfaz experto: traza

Static role bindings

Application tracer Task control

EXECUTING task t2

REPEATNEW-SOLUTION(inference B)

inference A

inference B

UNTIL HAS-SOLUTION(inference D)

Dynamic role bindings

Inference structure

Domain knowledge used by inference A

IF obj.a1 > 2 AND obj.a2 < 4THEN obj.a3 = "xyz"

IF obj.a1 =< 2THEN obj.a3 = "abc"

object 1 object 1object 2 object 3

object 4object 5

Role X Role Y Role Z

Role U Role V Role W

object 7object 6

X ZB

A

D

C

U

V

W

6-20

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

6-21

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

6-22

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 ...

6-23

Modelo de aplicación: facilidades (III)

• Papel Estático– Funciones de acceso/query

• Modelo de dominio (Base de Conocimiento)– representación– Funciones de acceso/query– Funciones de modificación/análisis

• Constructores de dominio (Esquema de dominio)– documentación

6-24

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

6-25

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-26

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

6-27

Implementación Prolog

SWI-Prolog (+XPCE)

O-O kernel

inferencemethodlibrary

CommonKADS kernel

"model""controller"

"views"

architecturalfacilities

applicationrealization

implementationplatform

6-28

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

6-29

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

6-30

Biblioteca de métodos de Inferencia

• Interprete de reglas con– Encadenamiento hacia delante– Encadenamiento hacia atrás

inf_methods.pl

6-31

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