View
224
Download
0
Category
Preview:
Citation preview
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
Recommended