Ingenier Ia Del Conocimiento: Departamento de Computaci On

Ingenier del Conocimiento a
Departamento de Computacin o
Curso 2002-2003
Alumna: Profesoras:
Laura M. Castro Souto Amparo Alonso Betanzos Bertha Guijarro Berdias n
Indice general
1. La Ingenier del Conocimiento a 1.1. El conocimiento y su contexto . . . . . . . . . . . . . . . . . . . . . . . 1.2. La ingenier del conocimiento . . . . . . . . . . . . . . . . . . . . . . . a 1.3. Los sistemas basados en el conocimiento . . . . . . . . . . . . . . . . . 2. Metodolog para la construccin de SSBBC as o 2.1. Diferencias entre la IS y la IC . . . . . . . . . 2.2. Metodolog adaptadas de la IS . . . . . . . . as 2.2.1. Metodolog de prototipado rpido . . a a 2.2.2. Metodolog de desarrollo incremental as 2.2.3. Metodolog en cascada . . . . . . . . as 2.2.4. Metodolog en espiral . . . . . . . . . as 2.3. Metodolog CommonKADS . . . . . . . . . . a 2.3.1. Nivel de Contexto: Por qu? . . . . . e 2.3.2. Nivel de Concepto: Qu? . . . . . . . e 2.3.3. Nivel de Implementacin: Cmo? . . . o o 3. Modelado del contexto en CommonKADS 3.1. El Proceso de Modelado del Contexto . . . 3.1.1. El modelo de Organizacin . . . . . o 3.1.2. El modelo de las Tareas . . . . . . 3.1.3. El modelo de los Agentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 2 3 5 5 7 7 8 8 8 10 10 12 12 13 14 15 16 16 17 17 20 23 26 28 28 29 29 30 31 31
4. Descripcin conceptual del conocimiento en CommonKADS o 4.1. El modelo del Conocimiento . . . . . . . . . . . . . . . . . . . . 4.1.1. Conocimiento del dominio . . . . . . . . . . . . . . . . . 4.1.2. Conocimiento inferencial . . . . . . . . . . . . . . . . . . 4.1.3. Conocimiento de la tarea . . . . . . . . . . . . . . . . . . 4.1.4. Inferencia o Tarea? . . . . . . . . . . . . . . . . . . . . 4.1.5. Modelo de Datos (IS) vs. Modelo de Conocimiento (IC) . 4.2. Plantillas de modelos de Conocimiento. Elementos reutilizables . 4.2.1. Tipos de Tareas . . . . . . . . . . . . . . . . . . . . . . . 4.3. Construccin de los modelos de Conocimiento . . . . . . . . . . o 4.3.1. Identicacin del Conocimiento . . . . . . . . . . . . . . o 4.3.2. Especicacin del Conocimiento . . . . . . . . . . . . . . o i
ii 4.3.3. Renado del Conocimiento . . . . . . . . . . 4.3.4. Documentacin del modelo de Conocimiento o 4.4. El modelo de Comunicacin . . . . . . . . . . . . . o 4.4.1. Plan de Comunicacin . . . . . . . . . . . . o 4.4.2. Transaciones agente-agente . . . . . . . . . . 4.4.3. Patrones transaccionales . . . . . . . . . . . 4.4.4. Tcnicas de validacin . . . . . . . . . . . . e o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 34 34 36 36 38 39 41 42 42 43 45 46 48 48 48 49 49 51 51 56 58 59 61 61 62 62 62 63 65 68 69 70 71 71 72 74 77 77 77 77
5. El modelo de Dise o en CommonKADS n 5.1. Principio de Conservacin de la Estructura . . . . . . . . . . . . . . . . o 5.2. El modelo de Diseo . . . . . . . . . . . . . . . . . . . . . . . . . . . . n 5.2.1. Diseo de la arquitectura del sistema . . . . . . . . . . . . . . . n 5.2.2. Identicacin de la plataforma de implementacin . . . . . . . . o o 5.2.3. Especicacin de los componentes de la arquitectura . . . . . . o 5.2.4. Especicacin de la aplicacin en el contexto de la arquitectura o o 5.3. Diseo de prototipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . n 5.3.1. Prototipado de subsistemas de razonamiento . . . . . . . . . . . 5.3.2. Prototipado de interfaces de usuario . . . . . . . . . . . . . . . . 5.4. SBCs distribuidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. Tcnicas para la adquisicin del conocimiento e o 6.1. Escenarios de adquisicin del conocimiento . . . . . . . . . . o 6.2. Las entrevistas . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1. Entrevistas mltiples . . . . . . . . . . . . . . . . . . u 6.3. El anlisis de protocolos . . . . . . . . . . . . . . . . . . . . a 6.4. Cuestionarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5. Anlisis del movimiento de ojos . . . . . . . . . . . . . . . . a 6.6. Mtodo de observacin directa . . . . . . . . . . . . . . . . . e o 6.7. Extraccin de curvas cerradas . . . . . . . . . . . . . . . . . o 6.8. Las tcnicas de escalamiento psicolgico . . . . . . . . . . . e o 6.8.1. Escalamiento multidimensional (EDM ) . . . . . . . . 6.8.2. Anlisis de clusters (Clustering) . . . . . . . . . . . . a 6.8.3. Redes ponderadas (Pathnder ) . . . . . . . . . . . . 6.9. La teor de constructos personalizados: el Emparrillado . . a 6.9.1. Identicacin de elementos Ei . . . . . . . . . . . . . o 6.9.2. Identicacin de caracter o sticas cj . . . . . . . . . . . 6.9.3. Diseo de la parrilla . . . . . . . . . . . . . . . . . . n 6.9.4. Formalizacin . . . . . . . . . . . . . . . . . . . . . . o 6.9.5. Anlisis y estudio de los resultados obtenidos . . . . a 6.10. Tcnicas especiales de adquisicin de conocimiento en grupo e o 6.10.1. Tormenta de ideas (Brainstorming) . . . . . . . . . . 6.10.2. Tcnica nominal de grupo . . . . . . . . . . . . . . . e 6.10.3. Mtodo Delphi . . . . . . . . . . . . . . . . . . . . . e Laura Castro
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
iii 7. Evaluacin de los sistemas basados en conocimiento o 7.1. Vericacin y validacin . . . . . . . . . . . . . . . . . . . . . . . . . . o o 7.1.1. Sistemas de vericacin automtica . . . . . . . . . . . . . . . . o a 7.1.2. Validacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o Apndices e A. Ampliaciones A.1. Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bibliograf a 79 82 82 84 86 87 87 93
Cap tulo 1 La Ingenier del Conocimiento a

En este primer tema estableceremos algunos conceptos bsicos relacionados con la a asignatura que nos ocupa.
1.1.
El conocimiento y su contexto
Qu es el conocimiento? Es dif de concretar, pero podemos sin embargo distine cil guir claramente que no es lo mismo que un dato ni tampoco es el mismo concepto que el de informacin. o Podemos decir que: Dato Conjunto de seales, s n mbolos, signos, que llegan a nuestros sentidos, sin que tengan que tener signicado propio. Informacin Datos que se agrupan y adquieren un signicado que no va o impl cito en ellos, sino que se aprende a manejar. Conocimiento Conjunto de datos e informacin que adems tiene sentio a do del propsito (sirve para algo) y capacidad de generar nuevo o conocimiento e informacin (e incluso acciones). o
Datos Informacin o Conocimiento
Caracter stica Sin interpretar Aade signicado n Propsito y capacidad o de generacin o
Ejemplo ...-... S.O.S. Alerta, emergencia, comenzar un rescate
Cuadro 1.1: Diferencias entre dato, informacin y conocimiento o La denicin de lo que es conocimiento se hace ms dif an si consideramos o a cil u que puede depender del contexto. Obviamente, un f sico y un ajedrecista no tendrn la a misma concepcin de lo que es conocimiento referente a sus respectivas actividades. o
Apuntes 1. La Ingenier del Conocimiento a
En el caso de la Ingenier del Conocimiento1 , esta situacin se agrava, puesto que a o su aplicacin se realiza en dominios muy concretos y diferentes (lo normal es distinto o en cada caso, por ejemplo, para diversos pacientes en un hospital). A veces se dene el conocimiento como informacin sobre la informacin, puesto o o que hay que tener cierta informacin sobre la informacin que se va a manejar para o o poder usarla adecuadamente. La representacin expl o cita del conocimiento es clave para distinguir entre sistemas software clsicos y sistemas software basados en conocimiento. a Como ya hemos estudiado con anterioridad (ver [2]), se pueden establecer categor as en el conocimiento barajado, en relacin al origen y procedencia del mismo con respecto o al experto de quien lo extraemos: Conocimiento p blico, que puede obtenerse directamente a partir u de fuentes t picas (manuales, libros), comnmente aceptado y univeru salmente reconocido. Conocimiento semip blico, expl u cito pero no universalmente reconocido ni comnmente aceptado, utilizado casi de forma exclusiva por u los especialistas del rea concreta. a Conocimiento privado, no expl cito, no universalmente reconocido ni comnmente aceptado, de marcado carcter heur u a stico, endgeno o de cada uno, fruto de la propia experiencia. Un sistema de conocimiento pretende familiarizarse con el conocimiento pblico, u implementar el semipblico y extraer el privado. u
1.2.
La ingenier del conocimiento a
Denominamos ingeniera del conocimiento al conjunto de conocimientos y tcnicas e que permiten aplicar el saber cient co a la utilizacin del conocimiento, entendiendo o conocimiento como inteligencia o razn natural. o Partiendo de la siguiente denicin de ingenier del software 2 (IEEE-99): o a La IS es la aplicacin de una aproximacin sistemtica, disciplinada y cuano o a ticable, al desarrollo, funcionamiento y mantenimiento del software (aplicaciones) podemos adaptarla a la IC y decir, asimismo, que la IC es la aplicacin de una o aproximacin sistemtica, disciplinada y cuanticable, al desarrollo, funcionamiento y o a mantenimiento del conocimiento (en aplicaciones, software).
1 2
En adelante, IC. En adelante, IS.
Laura Castro
1.3. Los sistemas basados en el conocimiento
Es por ello que muchas de las metodolog utilizadas en el campo de la IS se han as adaptado a la IC, y que tambin muchos de los problemas que aparecen en una se e reproducen en la otra tambin. La mayor de ellos, como veremos en el tema correse a pondiente, se deben con frecuencia a la especicacin dbil de requisitos, a la presencia o e de entradas inconsistentes, etc. que dan lugar a diseos no limpios. n Resumiendo, podemos denir la ingenier del conocimiento como el conjunto de a principios, mtodos, tcnicas y herramientas que permiten la construccin de sistemas e e o computacionales inteligentes.
1.3.
Los sistemas basados en el conocimiento
Entendemos por sistema basado en conocimiento 3 un sistema computerizado (software) que utiliza y representa expl citamente conocimiento sobre un dominio concreto para realizar una tarea que requerir un experto (de ser realizada por un hua mano), es decir, que es capaz de exportar ese conocimiento a travs de los mecanismos e apropiados de razonamiento para proporcionar un comportamiento de alto nivel en la resolucin de problemas en ese dominio (Guida & Tasso). o Las dos caracter sticas clave, tal y como se ha sealado, son: n la representacin expl o cita del conocimiento, algo que diferencia a los SBC de los sistemas software que se construyen en IS un dominio concreto, algo que los particulariza y diferencia de los sistemas de IA A partir de la IA, surgieron una serie de ramas: la robtica, los sistemas conexioniso tas, los sistemas expertos,. . . Estos ultimos fueron uno de los logros ms importantes, a porque fueron los primeros en enfrentarse a problemas reales utilizando conocimiento espec co de pequeos dominios. No obstante, en los aos 60 se produjo un retroceso n n en su desarrollo debido al aumento de la complejidad de los problemas que se pretend a abordar. Aos ms tarde, surgir la IC. n a a Los benecios ms importantes que aportan los SBCs son: a Mayor rapidez en la toma de decisiones Mayor calidad en la toma de decisiones Mayor productividad El desarrollo de un SBC es caro para la empresa: se necesita contratar al menos un ingeniero de conocimiento, se va a consumir tiempo del experto. . . Si todo ello se compensa es por estas ventajas competitivas que acabamos de mencionar.
3
A partir de ahora, SBC.
Apuntes 1. La Ingenier del Conocimiento a
Hay varios conceptos que ayudan a distinguir los SBC de software ms convencional a y tambin de programas de inteligencia articial: e La naturaleza ms bien heur a stica del conocimiento que contienen (IA, aos 50-60). n La naturaleza altamente espec ca del conocimiento (Dendral, 1970). La separacin del conocimiento de cmo se usa control (General o o Problem Solver de McCarthy, 1963; Mycin, 1976).
BASE de CONOCIMIENTOS Declarativos Operativos o de Accion Metaconocimiento
Memoria Activa
MOTOR DE INFERENCIAS
explicaciones y consejos
hechos y datos especificos
INTERFAZ DE COMUNICACION, EXPLICACION Y ADQUISICION DE CONOCIMIENTO
SUBSISTEMA DE USUARIO
SUBSISTEMA DE EXPLICACION
SUBSISTEMA DE ADQUISICION DE CONOCIMIENTO
Usuario
Ingeniero de Conocimiento
Figura 1.1: Esquema de un SBC.
Laura Castro
Cap tulo 2 Metodolog para la construccin as o de SSBBC

El ingeniero de conocimiento debe: elicitar estructurar formalizar operacionalizar toda la informacin y el conocimiento que estn relacionados con el dominio. Esta o e no es una tarea trivial, porque el conocimiento no es algo que se pueda observar, la informacin procede a menudo de diversas fuentes, se presenta en diferentes formatos, o puede incluso ser a veces contradictoria. Es necesario organizar de alguna manera el trabajo a realizar. Adems, el conocimiento no es slo algo dif de extraer, sino tambin un recurso a o cil e caro; por ello en los ultimos tiempos ha surgido la idea de reutilizacin del conocimiento. o
2.1.
Diferencias entre la IS y la IC
Los ingenieros de conocimiento y los ingenieros de software estuvieron enfrentados durante mucho tiempo, hasta que se dieron cuenta de no hab motivo para la cona frontacin, pues la IS no incluye a los sistemas de IC, sta desarrolla su software en o e problemas mal estructurados o mal denidos que no son tratables en IS. En IS el cliente pide lo que quiere; en IC se hacen modelos computacionales de un mbito concreto, se hace un anlisis exhaustivo de la organizacin donde vamos a a a o aplicar nuestro modelo. Las especicaciones de requisitos en IS son completas antes de empezar; en IC esto es casi imposible. En IC es muy importante la adquisicin del conocimiento, que adems es continua, o a es el cuello de botella de todos los sistemas; en IS se adquiere todo lo que se necesita para funcionar. 5
Apuntes 2. Metodolog para la construccin de SSBBC as o
PROBLEMA PROBLEMA DOMINIO DE APLICACION
ANALISIS DEL PROBLEMA Y DEL DOMINIO METODOS DE SOLUCION E S P ECI F I CACIONES MODELADO DE CONOCIMIENTO (o desarrollo del sistema vacio) CONOCIMIENTO DEL DOMINIO
DISEO DE LA ARQUITECTURA
DISEO MODULAR
ADQUISICION DE CONOCIMIENTO CONSTRUCCION BC
CODIFICACION Y COMPROBACION DE CADA MODULO
PROTOTIPO
COMPROBACION Y EVALUACION ENSAMBLADO DE MODULOS Y COMPROBACION DEL SISTEMA GLOBAL
CONSTRUCCION DEL SISTEMA META
SISTEMA SOFTWARE TRADICIONAL
SISTEMA BASADO EN CONOCIMIENTO
Figura 2.1: IS vs. IC.
Laura Castro
2.2. Metodolog adaptadas de la IS as
En IC no se trabaja con lenguajes, sino con herramientas, ya que se ha conseguido que el control, el manejo del conocimiento sea genrico (i.e. motores de inferencias). e
2.2.
Metodolog adaptadas de la IS as
En esta seccin revisaremos supercialmente algunas de las metodolog que la IC o as ha heredado de la IS.
2.2.1.
Metodolog de prototipado rpido a a
Esta metodolog consiste en adquirir conocimientos y codicar hasta considerar a que tenemos un modelo lo sucientemente bueno. Tras una serie de entrevistas con los clientes, usuarios y/o expertos, se intenta ver si el dominio puede: tener una parte central de la que puedan colgarse las dems postea riormente tener varias partes que se puedan tratar inicialmente por separado y comenzar con una de ellas Si el contexto es favorable, se desarrolla un prototipo rpido para mostrar al experto, a que se ir renando y ampliando. a Las ventajas de esta metodolog residen en que la rapidez en el desarrollo de a una primera versin del sistema motiva al experto (pronto se ve algo operativo), y o adems ayuda a centrar el desarrollo del conocimiento adems de no requerir demasiada a a experiencia. No obstante, desde el punto de vista de la IC son ms importantes las a desventajas que se presentan: diculta la recogida de requisitos se sustituye el estudio de especicaciones y el diseo por la codicacin n o rpida, lo que origina debilidades a el crecimiento incontrolado complica la BC las interacciones no contempladas entre distintas partes o mdulos del o sistema son fuente de muchos problemas, el modelo crece distorsionado el cdigo resulta generalmente muy poco y mal estructurado o no se produce un anlisis completo de requisitos a no hay una buena documentacin (o sta es nula) o e el mantenimiento es prcticamente imposible a Esta metodolog descuida todo lo que no tiene que ver directamente con el core a del conocimiento (desarrollo de una IU, comunicacin con otro software,. . . ), con todo o lo que ello conlleva. Ingenier del Conocimiento a
2.2.2.
Metodolog de desarrollo incremental as
Ante el desbordamiento de la metodolog de prototipado rpido, se volvi la vista a a a o la IS y una de las primeras metodolog que se adopt fue la de desarrollo incremental. as o
Analisis
formalizar objetivos
Especificaciones
formalizar objetivos
Ajustes del diseo
Diseo prototipos
codificacion inicial
Implementacion Prototipo inicial
Prueba (V&V)
Evaluacion Mantenimiento Diseo inicial
Figura 2.2: Esquema de la metodolog de desarrollo incremental. a Aunque por incremental es ms ordenada (manteniendo a la par algunas de las a ventajas del prototipado rpido, como la pronta obtencin de un sistema y una buena a o comunicacin con los expertos), esta metodolog gira, no obstante, en torno a la impleo a mentacin y aunque logr organizar un poco ms los sistemas, no centraba tampoco la o o a atencin en la captura de requisitos y especicaciones, que ser ms adecuado para un o a a sistema basado en conocimiento, a la par que no dejaba lugar para una etapa ulterior de mantenimiento preceptivo.
2.2.3.
Metodolog en cascada as
Tambin adaptada de la IS, esta metodolog trata de ajustar el alcance de la iterae a cin de desarrollo, que resultaba problemtico en el caso anterior (ver gura 2.3, pgina o a a 11). A pesar de conseguir reducir los errores al analizar ms el modelo, el mantenimiento a sigue siendo demasiado complejo para un sistema basado en conocimiento.
2.2.4.
Metodolog en espiral as
De los modelos planos se pas al modelo en espiral, que aporta un interesante o anlisis de riesgos, adems e plantear las iteraciones como capas en lugar de como a a bloques cerrados. Si bien en IS no se utiliza demasiado porque resulta muy pesado, en IC iba a resolver mltiples cuestiones: los prototipos sucesivos se van renando y ampliando, se pueden u aadir especicaciones en cada vuelta hasta llegar a concretar nalmente el elemento n Laura Castro
2.2. Metodolog adaptadas de la IS as
de test. Permite situar el mantenimiento en un nivel adecuado gracias al mencionado anlisis de riesgos. Cada fase ayuda a completar la anterior, en lugar de slo sumar, a o que era ms el enfoque de metodolog anteriores, sin que se alteren los fundamentos a as anteriores. Fue, pues, uno de los modelos que mejor funcion, aunque no es demasiado bueno al o desarrollar SBC ms grandes. No obstante, an quedaban dos cuestiones por solucionar: a u la adquisicin del conocimiento segu siendo el cuello de botella o a la capacidad de explicacin no estaba realmente presente, ya que coo nocimiento y motivos iban juntos, indivisiblemente Debido a esto, los propios SBC no ten conciencia de sus l an mites. Se necesitaba una metodolog que estructurase el conocimiento de una forma ms adecuada, al a a n y al cabo, la verdadera diferencia entre IS e IC es el tratamiento, el manejo del conocimiento. Todas las metodolog empleadas hasta el momento lo encuadraban as en un lugar o en otro, tratndolo sin darle un nivel espec a co como es imperativo. Como consecuencia de estos problemas, los SBC eran por aadidura muy dif n ciles de mantener, con fases de validacin muy extensas. o Fue primero Newell el que dio la voz de alarma indicando la necesidad de tratar el conocimiento como algo especial, reexionando sobre lo que hay que representar y cmo se quiere hacerlo, y posteriormente McDermott con su teor sobre las Tareas o a genricas segn la que la adquisicin del conocimiento sigue siempre unos pasos repee u o titivos, los que impulsar el desarrollo de metodolog propias de la IC (con ra an as ces, claro est, en las que acabamos de ver). De entre ellas, estudiaremos la metodolog a a CommonKADS. Newell. El nivel de conocimiento El mayor problema detectado hasta el momento es la no-diferenciacin de lo que o es conocimiento de la representacin del mismo. La solucin pasa por aadir el Nivel o o n de Conocimiento, que est por encima del nivel simblico. En este nivel el sistema se a o comporta como un agente que tiene tres vistas: componentes objetivos acciones cuerpo (conocimientos sobre objetos y acciones) El medio sobre el que acta es el conocimiento: el agente toma el conocimiento, lo u procesa y realiza acciones para conseguir objetivos. Esto permiti tambin abordar las o e primeras ideas sobre reutilizacin del conocimiento: abstraer las tareas genricas para o e volver a utilizarlas en sistemas similares. Una metodolog que usa el nivel de conocimiento es KLIC (KBS Life Cycle). a Ingenier del Conocimiento a
10
McDermott. Mtodos de limitacin de roles e o Los estudios de McDermott constituyeron los primeros intentos para reutilizar el mtodo de resolucin de problemas. e o Todos los sistemas ten un motor de inferencias separado del conocimiento hasta an ese momento. McDermott pens que el problema de reutilizar el motor era que parte o del conocimiento de control deb ir codicado en la base de conocimiento. As a la a , vez que se met conocimiento declarativo nuevo se iba deteriorando el anterior. a Para evitarlo, McDermott propuso estudiar los mtodos de resolucin de problemas, e o diferencindolos de la base de conocimientos. Como conclusin, extrajo que hay familias a o de tareas que se pueden resolver por mtodos cuyo conocimiento de control es abstracto e y se puede aplicar a distintas instanciaciones de esa tarea. Adems, permite denir a en qu orden hay que adquirir el conocimiento y tambin cmo se implementa (al e e o ordenarlo, disminu mos la entrop y es ms fcil implementarlo). a a a
2.3.
Metodolog CommonKADS a
La metodolog CommonKADS (Knowledge Analysis and Documentation Sysa tem) es una variacin de la metodolog en espiral de la IC, desarrollada en Europa o a en torno a 1983. Surge de su predecesora, KADS, al serle aadido un lenguaje de mon delado conceptual (CML, Conceptual Modell Language), muy parecido a UML, y que facilita el diseo del sistema. n La metodolog CommonKADS es, pues, una metodolog estructurada que cubre a a la gestin del proyecto, el anlisis de la organizacin, la ingenier del conocimiento y o a o a del software. Plasma tres de las ideas ms utilizadas en IS e IC (modelado, reutilizacin a o y gestin del riesgo) y, siendo la unica que utiliza Orientacin a Objetos, se organiza o o tal y como se puede observar en la gura 2.4 (pgina 11). a Esta divisin en niveles y modelos permite su desarrollo sin que unos sean intero dependientes de otros, es decir, permite un gran nivel de desacoplamiento. El conocimiento se encuentra as perfectamente estructurado y documentado, pues cada modelo posee una serie de plantillas asociadas.
2.3.1.
Nivel de Contexto: Por qu? e
Los modelos de este nivel analizan los benecios, el impacto, la utilidad que tendr el a SBC que se pretende construir, su viabilidad, etc. Modelo de Organizacin Estudia qu reas de la organizacin son ms o ea o a susceptibles de sacar provecho de un SBC. Es un estudio profundo de la organizacin, del impacto y posibles resultados de la implantacin o o del SBC, espectativas, predisposicin,. . . o Modelo de Tareas Ubicadas las tareas ms importantes, es el momento a de intentar descomponer el/los sistemas en primitivas con el n de Laura Castro
2.3. Metodolog CommonKADS a
11
Analisis del sistema
Especificaciones de requisitos
Diseo
Codificacion
Prueba
Mantenimiento
Figura 2.3: Esquema de la metodolog en cascada. a
Contexto
Modelo de la Organizacion
Modelo de Tareas
Modelo de Agentes
Concepto
Modelo de Conocimiento requisitos funcionalidades
Modelo de Comunicacion requisitos sobre interacciones
Implementacion
Modelo de Diseo
Figura 2.4: Niveles de la metodolog CommonKADS. a
12
Apuntes 2. Metodolog para la construccin de SSBBC as o poder abordarlas ms fcilmente, identicar sus entradas y salidas, a a criterios de rendimiento, pre y postcondiciones,. . . Modelo de Agentes Los agentes son los ejecutores de las tareas de la organizacin (ya sean personas f o sicas, sistemas de informacin, etc.). o Se analiza en este modelo qu normas se les aplican, plantillas, funcioe nes,. . .
2.3.2.
Nivel de Concepto: Qu? e
Los modelos de este nivel conforman una descripcin conceptual del conocimiento. o Modelo de Conocimiento Explica en detalle qu tipos de conocimiento e e informacin tenemos involucrados (naturaleza y estructura). Da una o visin de la estructura del conocimiento independiente de la impleo mentacin. o Modelo de Comunicacin Disecciona cmo es la comunicacin entre ageno o o tes involucrados (conceptualmente).
2.3.3.
Nivel de Implementacin: Cmo? o o
Este nivel se centra en la manera de llevar a cabo, de realizar de manera concreta, el sistema: mecanismos computacionales, arquitectura, representacin del conocimiento o ms adecuada, etc. a Modelo de Dise o Usando fundamentalmente el Modelo de Conocimienn to y el Modelo de Comunicacin, se intentan obtener los requisitos y o restricciones prcticas del sistema. a
Laura Castro
Cap tulo 3 Anlisis de viabilidad e impacto: a modelado del contexto en CommonKADS

El conocimiento siempre funciona dentro de una organizacin. En este cap o tulo, entre otras cosas, veremos: Por qu es necesario modelar el contexto e El papel de los modelos: Organizacin, Tareas y Agentes o Pasos y tcnicas en el anlisis del conocimiento orientado a las empree a sas y las instituciones Casos de ejemplo
Razones del modelado del contexto A menudo es dif identicar el uso rentable de tecnolog basadas cil as en conocimiento. El laboratorio es diferente del mundo real. La aceptabilidad de los usuarios es muy importante. Un sistema slo puede funcionar de forma adecuada si est propiao a mente integrado a largo plazo en la organizacin en la que trabaja. o Un SBC acta como un agente que coopera con otros, humanos o no, u y lleva a cabo una fraccin de las tareas de la organizacin. o o Un SBC es una herramienta de apoyo dentro del proceso general de la organizacin, al igual que cualquier sistema de informacin, en general. o o Muchas de estas cuestiones no se ten en cuenta en metodolog anteriores, lo an as que supone un gran avance.
13
14
Apuntes 3. Modelado del contexto en CommonKADS Las metas del modelado del contexto son: Identicar qu cuestiones suponen problemas y cules no. e a Decidir soluciones y su viabilidad. Mejorar las tareas y el conocimiento relativo a stas. e Planicar la necesidad de cambios en la organizacin. o El papel de los SBC se rige por una serie de directrices: Normalmente los SBCs encajan mejor en proyectos de mejora de la organizacin, ms que en la visin tradicional de automatizar las tareas o a o del experto. Las tareas son normalmente demasiado complejas y el proyecto se suele convertir en un fracaso, a ra de expectativas poco realistas. z Es mejor usar los SBCs como herramientas de mejora de procesos. El papel t pico de los SBCs es el de un asistente interactivo inteligente, a diferencia de la mayor de los sistemas automticos, que son pasivos. a a
3.1.
El Proceso de Modelado del Contexto

1. Llevar a cabo un estudio de alcance y viabilidad. Herramienta: Modelo de Organizacin (OM). o 2. Llevar a cabo un estudio de impacto y mejora (para enfocar/ampliar/renar el modelo de la organizacin). Herramienta: Modelos de o Tareas y de Agentes (TM, AM).
Los pasos a seguir son:
Cada estudio consta de una parte de anlisis y una parte de decisin constructiva: a o 1. Estudio del alcance y viabilidad: a) Anlisis.- Se trata de identicar las reas problema/oportunidades a a y buscar soluciones potenciales, ubicndolos en una perspectiva a ms amplia en la organizacin. a o b) S ntesis.- Se trata de estudiar la viabilidad econmica, tcnica y o e del proyecto, elegir el rea (o reas) ms comprometedora y la a a a solucin meta. o 2. Estudio de impacto y mejoras (para cada rea elegida en el paso ana terior): a) Anlisis.- Se estudian las interrelaciones entre la tarea, los agentes a involucrados y el uso de conocimiento para un sistema con xito, e intentando ver qu mejoras se pueden lograr. e Laura Castro
3.1. El Proceso de Modelado del Contexto b) Diseo.- Se decide acerca de los cambios en las tareas y las medidas n de la organizacin para asegurar su aceptacin y la integracin de o o o una solucin basada en SBC. o
15
Como ya hemos visto en el cap tulo anterior, el nivel contextual aglutina tres modelos: Estudio de alcance y viabilidad Modelo de la Organizacin (OM) para describir y analizar la oro ganizacin en sentido amplio o Estudio de impacto y mejoras Modelo de Tareas (TM) y Modelo de Agentes (AM), ms centrados a y detallados, enfocan las partes relevantes TM: tareas y conocimiento relativo a ellas directamente relacionado con el problema a resolver con el SBC AM: agentes involucrados en las tareas del TM Para simplicar este trabajo se dispone de formularios u hojas de trabajo que ayudan en el proceso de modelado: 5 formularios para el OM 2 formularios para el TM 1 formulario para el AM 1 formulario resumen Estas hojas de trabajo funcionan como checklist y como archivo de informacin, o debiendo ser utilizados de forma exible.
3.1.1.
El modelo de Organizacin o
Describir aspectos de la organizacin o carpeta de oportunidades/problemas contexto de negocio, metas, estrategia organizacin interna o estructura procesos personas (plantilla, roles funcionales,. . . ) potencial y cultura recursos (conocimiento, sistema de soporte, equipos,. . . ) Hacer este trabajo para la organizacin presente y la futura o Comparar y tomar las primeras decisiones de qu hacer e Ingenier del Conocimiento a
Veremos ahora cmo analizar una organizacin intensiva en conocimiento: o o
16
Apuntes 3. Modelado del contexto en CommonKADS

Modelo de Organizacion
OM5 OM1 OM2 OM3 OM4
Problemas/Oportunidades
Descripcion del area elegida
Contexto general
Soluciones potenciales
Estructura Procesos Personal Cultura y potencial Recursos Conocimiento
Decomposicion detallada
Descripcion a traves de activos de conocimiento
Figura 3.1: Modelo de la Organizacin. o Se remite a los apndices para detalle de las plantillas correspondientes a cada paso e del anlisis del Modelo de Organizacin. a o Hasta aqu es el anlisis de los aspectos estticos de la organizacin, los que no se , a a o supone que vayan a cambiar.
3.1.2.
El modelo de las Tareas
El modelo de Tareas describe, utilizando tambin una serie de plantillas que se e adjuntan en los apndices, las tareas que se determinan componen los procesos de la e organizacin y que fueron esbozadas en algunos apartados referentes al modelo de la o Organizacin. o
3.1.3.
El modelo de los Agentes
Por su parte, el modelo de Agentes detalla el papel, relevancia, conocimiento y otras caracter sticas relativas a los agentes que llevan a cabo o participan en las tareas identicadas en el modelo de Tareas. De nuevo, remitimos a los apndices para estudio e de las plantillas asociadas.
Laura Castro
Cap tulo 4 Descripcin conceptual del o conocimiento en CommonKADS

Como hemos visto, CommonKADS organiza la aproximacin a un SBC de la sio guiente forma:
Modelo de la Organizacion
Modelo de Tareas
Modelo de Agentes
Modelo de Conocimiento
Modelo de Comunicacion
Modelo de Diseo
En este cap tulo nos centraremos en el modelado del Conocimiento.
4.1.
El modelo del Conocimiento
Los modelos de Conocimiento son una herramienta especializada para especicar tareas en dominios intensivos de/en conocimiento. Un modelo de conocimiento especica los requisitos de conocimiento y razonamiento del sistema futuro. No incluye aspectos de comunicacin con los usuarios ni con o otros agentes software, ni tampoco contiene trminos espec e cos de implementacin. o
17
18
Apuntes 4. Descripcin conceptual del conocimiento en CommonKADS o
Su estructura es similar a la de los modelos de anlisis tradicional en ingenier del a a software, siendo un aspecto importante para la reutilizacin del software. o
Requisitos y especificaciones de interaccion
MODELO COMUNICACION TAREA INTENSIVA en CONOCIMIENTO MODELO CONOCIMIENTO
MODELO de ORGANIZACION MODELO de TAREAS MODELO de AGENTES
MODELO DISEO
Tarea seleccionada en estudio de viabilidad y desarrollada en modelos de tareas y agentes
Requisitos y especificaciones de razonamiento
El trmino conocimiento ya ha sido comentado con anterioridad: lo hab e amos denido como informacin sobre la informacin. Un ejemplo de ello podr ser, por o o a ejemplo, en las jerarqu superclase-subclase de tipos de objetos, un link entre dos as clases, que proporciona informacin sobre la relacin entre ambas. o o El conocimiento se puede utilizar para inferir nueva informacin, de suerte que no o hay realmente una frontera denida entre informacin y conocimiento. o En un SBC, el conocimiento est presente como tal en la base de conocimientos. a Normalmente, se preere tener varias bases de conocimiento, cada una aglutinando reglas de un tipo determinado, de manera que sea posible su reutilizacin y tambin o e su correccin de forma ms sencilla. o a Dentro del modelo del conocimiento, distinguiremos varias categor de conocias miento: Conocimiento de la Tarea Qu y cmo? e o Es un conocimiento orientado a la meta y que realiza una descomposicin funcional. o Conocimiento Inferencial Encarna los pasos bsicos del razonamiento que se pueden hacer en el a dominio (en el contexto de un problema) y que se aplican mediante las tareas. Conocimiento del Dominio Aglutina el conocimiento y la informacin relevantes del dominio eso ttico, equivaliendo de algn modo al modelo de datos o de objetos en a u IS.
Laura Castro
4.1. El modelo del Conocimiento
19
Conocimiento de la Tarea:
DIAGNOSIS (tarea) HIPOTETIZAR (inferencia) VERIFICAR (inferencia)
Conocimiento Inferencial:
Conocimiento del Dominio:
SINTOMA (tipo)
ENFERMEDAD (tipo)
PRUEBA (tipo)
Conocimiento del Dominio
Conocimiento Inferencial
Conocimiento de la Tarea
Figura 4.1: Categor en el modelo del Conocimiento. as
20
4.1.1.
Conocimiento del dominio
El conocimiento del dominio describe la informacin esttica ms importante y los o a a objetos de conocimiento en un determinado dominio. Tiene dos partes principales: Esquema del Dominio Describe la estructura esttica de la informacin/conocimiento a travs a o e de deniciones tipo, siendo comparable al modelo de datos/objetos en IS. Queda denido a travs de los constructos del dominio. e Base de Conocimientos Contiene instancias de los tipos que se especica en el esquema del dominio (es decir, conjuntos de instancias de conocimiento), siendo comparable al contenido de una base de datos.
Esquema del Dominio
Base de Conocimientos
CONSTRUCTOS Conceptos Relaciones Tipos de Regla
Figura 4.2: Constructos del modelo del Conocimiento.
Constructos en el esquema del dominio La mayor son similares a los de O.O. (especialmente los diagramas de clases): a Laura Castro
4.1. El modelo del Conocimiento Conceptos Describen un conjunto de objetos o instancias del dominio que comparten caracter sticas similares (como los objetos en O.O. pero sin operaciones ni mtodos). e Relaciones Como las asociaciones en O.O. Atributos Valores primitivos. Caracter sticas de los conceptos. Tipos de reglas Introducen expresiones (no hay equivalente en IS). Se incluyen, adems, otros para cubrir aspectos espec a cos del modelado SBC. Conceptos y Atributos
21
Como hemos dicho, un concepto describe un conjunto de objetos o instancias. Las caracter sticas de los constructos se denen mediante atributos, que pueden tener un valor (atmico) que se dene a travs de un tipo de valor (denicin de los valores o e o permitidos). Los conceptos son el punto de comienzo para el modelado del conocimiento. Relaciones Las relaciones entre conceptos pueden denirse con el constructo relacion o re lacion binaria (e incluso relacion n-aria) a travs de las especicaciones de e argumentos. La cardinalidad se dene para cada argumento y su valor por defecto es 1. Es posible especicar un rol para cada argumento. La propia relacin puede tener atributos. o
pertenencia 0+ coche propiedadde 01 persona DIRECCIONAL
coche
persona
NO DIRECCIONAL
coche propiedad fechaadquisicion
persona
REIFICACION (si la relacion tiene atributos o participa en otras relaciones)
Figura 4.3: Relaciones en el modelo del Conocimiento.
El modelado de las reglas Las reglas son una forma natural y comn de representar el conocimiento simblico. u o Ahora bien, cmo representamos dependencias entre conceptos en un modelo de datos o tradicional? Ingenier del Conocimiento a
22
Apuntes 4. Descripcin conceptual del conocimiento en CommonKADS o Para modelar la construccin de las reglas se usa el constructo tipo de regla: o Es similar a una relacin, donde antecedente y consecuente no son o instancias de conceptos sino expresiones de esas instancias. Se modela una relacin entre expresiones acerca de los valores de los o atributos. Se modelan un conjunto de reglas de estructura similar. Las relaciones no son estrictamente lgicas, es necesario especicar un o s mbolo de conexion entre antecedente y consecuente.
Estructura de tipo de regla La estructura es sencilla: <antecedente> <smbolo-de-conexin> <consecuente> o
Su uso exible permite la representacin de cualquier tipo de dependencia (tipos o mltiples para antecedente y consecuente). u
ESTADO INVISIBLE
causa
ESTADO
dependencia estado tienemanifestacion manifestacion regla
ESTADO INVISIBLE
ESTADO OBSERVABLE
TIPOdeREGLA reglamanifestacion DESCRIPCION "..." ANTECEDENTE estadoinvisible CONSECUENTE estadoobservable SIMBOLO tienemanifestacion ENDTIPOdeREGLA
Figura 4.4: Ejemplos de representacin de Tipos de Regla. o
Laura Castro
4.1. El modelo del Conocimiento Base de Conocimientos
23
Es una particin conceptual de la BC que contiene instancias de los tipos de conoo cimiento denidos en el esquema del dominio. Las instancias de los tipos de reglas contienen reglas. Su estructura tiene dos partes: el slot usa: <tipos-usados>de <esquema> el slot expresiones: <instancias> Las instancias pueden representarse formalmente, o bien semiformalmente con el s mbolo de conexin separando antecedente y consecuente. o
BASECONOCIMIENTOS USA ... de ... ... de ... EXPRESIONES /* dependientesestado */ ... /* manifestacionregla */ ... ENDBASECONOCIMIENTOS
Figura 4.5: Ejemplo de representacin de Base de Conocimientos. o
4.1.2.
Conocimiento inferencial
El conocimiento inferencial describe el nivel inferior de descomposicin funcional. o Describe cmo las estructuras estticas del conocimiento del dominio se pueden usar o a para realizar el proceso de razonamiento, permitiendo la reutilizacin del conocimiento. o Sus elementos principales se aprecian en la gura 4.6 y son: Inferencias Relacionadas con el razonamiento, son las unidades bsicas a de procesado de informacin. o Funciones de Transferencia Relativas a la comunicacin con otros ageno tes (a un nivel muy bsico, esta cuestin se trata realmente en el Moa o delo de Comunicacin). o Roles de Conocimiento Relacionados indirectamente con el conocimiento del dominio. Una inferencia usa el conocimiento de alguna base de conocimiento para derivar nueva informacin. o Los roles dinmicos son las entradas y salidas en tiempo de ejecucin de las infea o rencias. Ingenier del Conocimiento a
24
Inferencias
Roles de Conocimiento
Funciones de Transferencia
Figura 4.6: Elementos del Conocimiento Inferencial.
explicar ENTRADA (rol dinamico) queja Modelo Causal (rol estatico) INFERENCIA SALIDA (rol dinamico) hipotesis
Figura 4.7: Ejemplo de Inferencia.
Laura Castro
4.1. El modelo del Conocimiento Inferencias
25
Las inferencias quedan completamente descritas a travs de una especicacin dee o clarativa de propiedades de su E/S. Los procesos internos de la inferencia son una caja negra. Rol de Conocimiento Proporcionan un nombre funcional para elementos dato/conocimiento. Dicho nombre captura el rol del elemento en el proceso de razonamiento, realizando un mapeado expl cito a los tipos del dominio. Los roles dinmicos son variantes E/S, mientras que los estticos son entradas ina a variantes (una base de datos).
INFERENCIA explicar ROLES ENTRADA ... SALIDA ... ESTATICOS ... ESPECIFICACION "..." END_INFERENCIA
ROLCONOCIMIENTO nombre TIPO dinamico MAPEADODOMINIO visibleestado ENDROLCONOCIMIENTO
Funciones de Transferencia Las funciones de transferencia transeren un item de informacin entre el agente de o razonamiento del mdulo de conocimiento y otro agente del mundo externo (usuario, o otro sistema,. . . ). Desde el punto de vista del modelo de conocimiento es una caja negra: slo interesa o su nombre y su E/S. La especicacin detallada de las funciones de transferencia es o parte de otro modelo, el de Comunicacin. o Iniciativa sistema obtener presentar Iniciativa externa recibir proporcionar
Informacin externa o Informacin interna o
Cuadro 4.1: Nombres estndar de las Funciones de Transferencia. a
Estructura Inferencial La combinacin de los diferentes conjuntos de inferencias especica la capacidad o inferencial bsica del sistema en desarrollo. El conjunto de inferencias se puede presena tar grcamente en una estructura inferencial, que hace nfasis en los aspectos a e dinmicos del ujo de datos (roles estticos opcionales). a a Ingenier del Conocimiento a
26

rol conocimiento dinamico queja rol estatico explicar modelo causal funcion de transferencia obtener hecho real
hipotesis
predecir
hecho esperado
comparar
modelo manifestacion
resultado
Figura 4.8: Ejemplo de Mapa Inferencial. Uso de las Estructuras Inferenciales Las estructuras inferenciales son representaciones abstractas de los posibles pasos del proceso de razonamiento, y, como tales, son un veh culo importante de comunicacin o durante el proceso de desarrollo, a pesar de que a menudo puedan ser provisionales. Suele ser util realizar anotaciones con ejemplos espec cos del dominio. Las estructuras inferenciales denen las capacidades inferenciales del sistema, el vocabulario y las dependencias de control, pero no el control en s (del que se ocupa el conocimiento). Reutilizacin de inferencias o El estado ideal ser disponer de un conjunto estndar de inferencias. Con ese objea a tivo, se recomienda el uso de nombres lo ms estndar posibles con el n de favorecer a a la reutilizacin. o
4.1.3.
Conocimiento de la tarea
El conocimiento de la tarea describe metas (por ejemplo, asesorar la suscripcin o de una hipoteca, disear un ascensor,. . . ) y las estrategias que se pueden utilizar para n realizar dichas metas. Esta descripcin sigue un esquema jerrquico. o a Tal y como se puede observar en la gura 4.9, distinguiremos, dentro del conocimiento de la tarea, la propia Tarea y por otra parte lo que llamaremos el Mtodo de la e Tarea. Tarea La Tarea dene la meta del razonamiento en forma de pares (entrada, salida), con el n de especicar qu es necesario saber. e La diferencia principal con las funciones tradicionales es que los datos manipulados por la tarea se describen tambin independientemente del dominio. e Laura Castro
4.1. El modelo del Conocimiento

27
Tarea
Metodo de la Tarea
Figura 4.9: Elementos del Conocimiento de la Tarea. El hecho de que la descripcin deba ser independiente del dominio tiene como obo jetivo la reutilizacin de las tareas. o Una tarea se describe por medio de tres slots: META Descripcin textual informal. o SPEC Describe de manera textual e informal la relacin entre la entrada o y la salida de la tarea. ROLES Los roles de E/S se especican en forma de roles funcionales, como en las inferencias, pero con algunas diferencias: no hay roles estticos a no hay mapeado de los roles en trminos espec e cos del dominio; los roles de las tares estn linkados a los roles inferenciales a cada tarea tiene un mtodo asociado e Mtodo de la Tarea e El Mtodo de la Tarea describe cmo se realiza una tarea mediante su descompoe o sicin en subfunciones. Las subfunciones pueden ser otra tarea, inferencias o funciones o de transferencia. La parte central del mtodo de la tarea se denomina estructura de control y describe e el orden de las subfunciones, capturando la estrategia de razonamiento. Los elementos de la estructura de control son: Ingenier del Conocimiento a
28
explicar
predecir
obtener
comparar
Figura 4.10: Ejemplo de esquema de un posible Mtodo de la Tarea. e llamadas a procedimientos (tareas, inferencias, funciones de transferencia) operaciones de roles (asignacin, suma/resta,. . . ) o primitivas de control (repetir,. . . ) condiciones expresiones lgicas sobre roles o condiciones especiales: tiene solucin y nueva solucin o o
4.1.4.
Inferencia o Tarea?
Si el comportamiento interno de una funcin1 es importante para explicar el como portamiento del sistema como un todo, entonces es necesario denir esta funcin como o una tarea. Durante el desarrollo del modelo, es usual manejar estructuras inferenciales provisionales.
4.1.5.
Modelo de Datos (IS) vs. Modelo de Conocimiento (IC)
Los Modelos de Datos contienen datos sobre datos, ya que en Ingenier del a Software lo importante son los datos. Sin embargo, la Ingenier del Conocimiento se a centra en el conocimiento, hace nfasis en el control interno y desarrolla funciones e que se describen independientemente del modelo de datos, lo que favorece una mayor reutilizacin posterior. o
1
Donde por funcin podemos entender tanto tarea como inferencia. o
Laura Castro
4.2. Plantillas de modelos de Conocimiento. Elementos reutilizables
29
4.2.
Plantillas de modelos de Conocimiento. Elementos reutilizables
En lo que llevamos visto hasta el momento, destacan una serie de puntos clave en lo que a reutilizacin se reere: o Los modelos de conocimiento pueden ser parcialmente reutilizados en aplicaciones nuevas. La gu principal para la reutilizacin es el tipo de tarea. a o Existe un catlogo de plantillas de tareas intensivas en conocia miento (como los patrones en O.O.).
Los fundamentos de la reusabilidad pasan por no reinventar la rueda cada vez que nos enfrentamos a un problema, conseguir la mxima eciencia coste/tiempo, disminuir a la complejidad y asegurar la calidad. Una plantilla es una combinacin de elementos del modelo reutilizables: o Estructura inferencial (provisional) Estructura de control t pica Esquema del dominio t pico desde el punto de vista de la tarea Todo ello es espec co para el tipo de tarea que describe cada plantilla en particular. Gracias a estas plantillas este mtodo de modelado soporta el modelado del e conocimiento top-down.
4.2.1.
Tipos de Tareas
El rango de tipos de tareas est limitado. Esto es una ventaja de la IC en compaa racin con los antiguos SSEE. o En el trasfondo de esto se encuentran la ciencia cognitiva y la psicolog a. La estructura de la descripcin en la plantilla es la siguiente: o 1. Caracterizacin general. o 2. Mtodo por defecto. e 3. Variaciones t picas (cambios/ajustes frecuentes). 4. Esquema t pico del conocimiento del dominio (asunciones sobre las estructuras del dominio). Ingenier del Conocimiento a
30

Tareas Anal ticas Preexiste (aunque no es conocido). Datos acerca del sistema. Alguna caracter stica del sistema. clasificacion asesoramiento diagnostico monitorizacion prediccion Tareas Sintticas e No existe an. u Requisitos del sistema que se construir. a Descripcin del sistema construido. o diseno modelado planificacion asignacion scheduling
Sistemaa Entrada Salida Tipos
Entendemos por sistema un trmino abstracto que designa el objeto sobre el que se aplica la e tarea. En diagnstico tcnico, por ejemplo ser el artefacto o aparato que est siendo diagnosticado. o e a a
Cuadro 4.2: Tareas Anal ticas vs. Tareas Sintticas. e
4.3.
Construccin de los modelos de Conocimiento o
La metodolog CommonKADS enfoca el modelo del conocimiento como un produca to. Esto hace que se forme un cuello de botella por falta de experiencia en el modelado del conocimiento. La solucin, como es fcil de preveer, pasa por modelar, a su vez, el proceso. o a No obstante, el modelado es una actividad constructiva para la que no existe una solucin correcta ni un camino ptimo. As pues, lo que se hace es proporcionar una o o gu que funciona bien en la prctica. a a El modelado del conocimiento es una forma especializada de especicacin de reo quisitos en el que se usan, por tanto, principios generales de la IS.
ESTADOS
Identificacion del Conocimiento Especificacion del Conocimiento Refinado del Conocimiento
Familiarizacion con el dominio, lista potencial de componentes reutilizables Escoger plantilla de tareas, construir conceptualizacion inicial, especificacion completa del modelo del dominio
Validacion del modelo del conocimiento, refinado de las bases de conocimiento
Figura 4.11: Gu para el modelado del Conocimiento. a
Laura Castro
4.3. Construccin de los modelos de Conocimiento o
31
4.3.1.
Identicacin del Conocimiento o
META Estudiar los items de conocimiento, prepararlos para su especicacin. o ENTRADA Tarea intensiva en conocimiento, principales items de conocimiento identicados, clasicacin de la tarea de la aplicacin. o o ACTIVIDADES Explorar fuentes de informacin y estudiar la naturaleza de la tao rea. Los factores ms importantes con respecto a las fuentes de informacin a o son su naturaleza (son claras? tienen base terica?) y su diversidad o (son conictivas? con qu factor de riesgo?). e Las tcnicas para su exploracin son las tradicionales: marcado de texe o tos, entrevistas, etc. El problema principal reside en encontrar un balance entre aprender sobre el dominio y convertirse en un experto. Algunas gu as: Hablar con la gente que trata a los expertos pero que no son expertos Evitar sumergirse en teor complicadas y detalladas as Construir unos cuantos escenarios t picos No pasar demasiado tiempo en esta actividad Una vez acometidas estas actividades, puede realizarse una valoracin de resultao dos, tanto tangibles (listado de fuentes, resmenes de textos, glosario, descripcin u o de escenarios), como intangibles (la propia comprensin). o La presencia de una lista de componentes tiene como objetivo allanar el camino en el manejo de componentes reutilizables en dos dimensiones: Dimensin de la Tarea (elegida del tipo asignado en el TM, construir una o lista de plantillas) Dimensin del Dominio (tipo de dominio, buscar descripcin estndar) o o a
4.3.2.
Especicacin del Conocimiento o
META Completar la especicacin del conocimiento excepto para los contenidos de o los modelos del dominio (que necesitan slo contener instancias). o ACTIVIDADES Elegir una plantilla de la tarea Como l nea base de actuacin, no debemos o olvidar que existe una fuerte preferencia por un modelo de conocimiento basado en aplicaciones ya existentes (por razones de ecacia y calidad asegurada). Los criterios de seleccin son las caracter o sticas de la tarea de la aplicacin (naturaleza de las entradas y salidas del sistema, restricciones del o contexto. . . ). Algunas gu para la seleccin de plantillas: as o Ingenier del Conocimiento a
32
Apuntes 4. Descripcin conceptual del conocimiento en CommonKADS o Preferir las que se usan con ms frecuencia (por evidencia emp a rica). Construir una estructura inferencial anotada con ejemplos y un esquema del dominio. Si no se ajusta a ninguna plantilla, cuestionar la intensidad en conocimiento de la tarea. Construir una conceptualizacin inicial del dominio Ha de construirse un o esquema del dominio inicial, que tendr dos partes: a Conceptualizacin espec o ca del dominio (que no es probable que cambie). Conceptualizacin de mtodos espec o e cos (slo necesaria para resolver o ciertos problemas excepciones a la norma, no demasiado relevantes en este punto). Como salida de este paso obtendremos un esquema que debe cubrir al menos las conceptualizaciones espec cas del dominio. Algunas gu sobre cmo actuar: as o Utilizar en lo posible el modelo de datos existente (usar al menos la misma terminolog en los constructos bsicos; har las cooperaciones a a a e intercambios futuros ms sencillos). a Limitar el uso del lenguaje de modelo de conocimiento a conceptos, subtipos y relaciones (concentrarse en los datos, de manera similar a cuando se construye un modelo de clases inicial). Si no existe modelo de datos disponible, usar tcnicas estndar de IS e a para encontrar conceptos y relaciones. Especicar las tres categor del conocimiento Por ultimo, se termina la as especicacin completa del dominio, pudiendo enfrentarse de dos maneras: o 1. Ruta Middle-Out. Es la aproximacin preferida, empieza con el conocio miento inferencial. Como precondicin, la plantilla de la tarea ha de ser o una buena aproximacin de la estructura inferencial. o 2. Ruta Middle-In. Comienza en paralelo con la descomposicin de la tarea o y el modelado del dominio, por lo que consume ms tiempo. Es necesario a si la plantilla de la tarea es de grano demasiado grueso. La estructura inferencial est sucientemente detallada si lo est la explia a cacin que proporciona, o tambin si es fcil encontrar para cada inferencia o e a un tipo de conocimiento del dominio que acte tal y como se espera. u Algunas gu para especicar el conocimiento de la tarea: as Empezar con la estructura de control. No incluir detalles de la memoria de trabajo. Elegir nombres de roles aclarativos (Modelar es nombrar ). No incluir roles de conocimiento esttico. a
Laura Castro
4.3. Construccin de los modelos de Conocimiento o
33
En aplicaciones de tiempo real, considerar usar una representacin alo ternativa al pseudocdigo (UML). o Algunas gu para especicar el conocimiento inferencial : as Comenzar con la representacin grca. o a Elegir los nombres de rol cuidadosamente (carcter dinmico, hiptesis, a a o datos iniciales,. . . ). Usar un conjunto lo ms estndar posible de inferencias. a a Algunas gu para especicar el conocimiento del dominio: as Usar como roles estticos los tipos del dominio (no tienen que tener la a representacin correcta, esta ser una tarea del diseo). o a n
4.3.3.
Renado del Conocimiento
El renado del Conocimiento pasa por: 1. Validacin del modelo de Conocimiento. o 2. Rellenar las Bases de Conocimiento. Validacin del modelo de Conocimiento o La validacin debe ser interna (vericacin, es el modelo adecuado?) y externa o o (validacin contra los requisitos del usuario, es correcto el modelo?). o Existen diferentes tcnicas de validacin: e o Interna: Rutas estructuradas (probar escenarios t picos) Herramientas software Externa: Suele ser ms dif y/o amplia a cil Tcnica principal: simulacin (prototipos, simulacin basada en e o o papel) En cuanto al mantenimiento, segn el punto de vista de CommonKADS, no es u algo diferente del desarrollo del modelo, pues es algo c clico. El modelo es como un repositorio de informacin; debemos especicar requisitos para obtener herramientas o de soporte potentes. Rellenar las Bases de Conocimiento El esquema contiene dos tipos de dominios: tipos de informacin parte de un caso o y tipos de informacin parte de un modelo de conocimiento. o La meta es determinar todas las instancias de cada tipo. Las instancias slo se neo cesitan para un escenario. Algunas gu para el rellenado de las bases de conocimiento: as Ingenier del Conocimiento a
34
Apuntes 4. Descripcin conceptual del conocimiento en CommonKADS o Rellenar las bases de conocimiento es una forma de validar el esquema construido. Normalmente no es posible denir una base de conocimientos correcta y completa en un primer ciclo. Las bases de conocimiento necesitan mantenimiento (el conocimiento cambia con el tiempo). Tcnicas: incorporar facilidades de edicin para las bases de conoe o cimiento, trazas, entrevistas estructuradas, aprendizaje automtico, a mapeado de otras bases de conocimiento.
4.3.4.
Documentacin del modelo de Conocimiento o
Una vez construido el modelo, se redacta un documento KM-1 (ver apndices), que e contendr: a Especicacin del modelo de conocimiento. o Listado de fuentes de informacin. o Listado de los componentes reusables del modelo. Escenarios t picos del problema que resuelve la aplicacin. o Resultados de validacin de la simulacin. o o Material de elicitacin. o
4.4.
El modelo de Comunicacin o
El papel del modelo de Comunicacin es especicar los procesos de transferencia o de informacin/conocimiento. Es, en cierto modo, un control de nivel superior sobre o la ejecucin de la tarea (mltiples tareas intensivas en conocimiento). Tareas de comuo u nicacin adicionales, pueden, adems, aadir facilidades de explicacin al sistema. Un o a n o ejemplo es la interacin bsica sistema-usuario. o a
Requisitos y especificaciones de interaccion
MODELO COMUNICACION TAREA INTENSIVA en CONOCIMIENTO MODELO CONOCIMIENTO
MODELO de TAREAS MODELO de AGENTES
MODELO DISEO
Detallada en modelos de tareas y agentes
Requisitos y especificaciones de razonamiento
Figura 4.12: Relacin del modelo de Comunicacin con otros modelos. o o
Laura Castro
4.4. El modelo de Comunicacin o Las entradas al modelo de Comunicacin son: o Modelo de Tareas Lista de tareas hoja llevadas a cabo por los agentes considerados. Modelo de Conocimiento Funciones de transferencia. Modelo de Agentes Descripcin de agentes relevantes, capacidades, reso ponsabilidades y restricciones.
35
Cada vez ms, los sistemas de informacin son informacin + sistema de comunia o o cacin: o Aplicaciones distribuidas (telemtica). a Organismos virtuales. Sistemas multiagente inteligentes. Manejo de ujos de trabajo. Ingenier concurrente. a Manejo e integracin de la cadena de negocio. o El modelado de la informacin debe cubrir: o Anlisis de la organizacin. a o Anlisis de las tareas. a Anlisis de actores/agentes (sistemas y humanos). a Normalmente, varios actores cooperan en un proceso de negocio o tarea. El modelo de Comunicacin se centra en modelar el dilogo entre agentes afrontndolo mediante o a a una aproximacin semiformal estructurada. o
Tarea
Agente
Plan de Comunicacion
Transaccion
Especificaciones sobre el intercambio de Informacion
Estructura de la Tarea
Figura 4.13: Estructura del modelo de Comunicacin. o
36
Apuntes 4. Descripcin conceptual del conocimiento en CommonKADS o La aproximacin por capas al modelado de las comunicaciones consta de tres niveles: o Plan de Comunicaciones general.- Gobierna el dilogo completo entre a dos agentes. Transacciones individuales.- Son las que unen dos tareas hoja llevadas a cabo por dos agentes diferentes. Especicacin del intercambio de informacin.- Detalla la estructuo o ra de las transacciones.
Como se puede ver, pues, las transacciones son el componente clave del modelo de Comunicacin. Describen qu objetos de informacin se intercambian, indicando los o e o agentes y tareas implicados. Son el bloque de construccin para el dilogo completo o a entre un par de agentes, y tienen una estructura interna. Haciendo abuso de lenguaje, suele llamarse transaccin incluso a lo que se intero cambia entre dos tareas llevadas a cabo por diferentes agentes. A un nivel superior, est el plan de comunicacin, que gobierna el dilogo coma o a pleto entre los agentes, siendo la especicacin concreta del modelo de Comunicacin. o o
4.4.1.
Plan de Comunicacin o
Generalmente es ms fcil comenzar por el plan de comunicacin global. El plan de a a o comunicacin describe completamente el dilogo de alto nivel, siendo sus transacciones o a t picas: entrada de datos, contestacin de preguntas, presentacin de resultados, etc. o o Actividades Para cada agente se confeccionar una lista de todas las tareas en las que participa, a y para cada tarea se identicar el conjunto de transacciones agente-agente asociadas. a El resultado se combina en un diagrama de dilogo (DD, ver gura 4.14) que reprea senta las transacciones entre cada par de agentes que se comunican. Se dibuja, pues, un DD para cada combinacin de dos agentes que intercambian informacin, especicando o o de esta manera el control sobre las transacciones. Como alternativa a la notacin del DD, se puede utilizar tambin pseudocdigo o e o con primitivas de control especiales: enviar, recibir, llevar a cabo, esperar, procesar, repetir,. . .
4.4.2.
Transaciones agente-agente
El nivel de especicacin medio del modelo de Comunicacin est encarnado en la o o a especicacin de las transacciones individuales, estructuradas en un nmero de como u ponentes. Tcnicas simples de formulario son utiles aqu (ver formulario CM-1 en apndices). e e Laura Castro
4.4. El modelo de Comunicacin o

Agente A
(por ejemplo, usuario)
37
Agente B
(por ejemplo, sistema)
Tarea A1 Tarea A2 . . . Tarea Ax
transaccion 1 transaccion 2 . . .
Tarea B1 Tarea B2 . . . Tarea By
Dialogo
(las tareas hoja de los agentes son clave para la construccion del DD)
Figura 4.14: Estructura general de un Diagrama de Dilogo. a Las transacciones suelen agruparse tras un unico plan de comunicacin, salvo en o sistemas multiagente.
Identificador y Nombre Plan de comunicacion
Agentes
Transaccion Restricciones Objetivo informacion
Especificacion intercambio informacion
Figura 4.15: Esquema de la estructura de una transaccin (CM-1). o
Tareas Delegacin Tareas Adopcin Tareas Intercambio o o Request Propose Ask Require Offer Reply Order Agree Report Reject ta Inform Reject td Cuadro 4.3: Tipos de comunicacin. o Ingenier del Conocimiento a
38
Las transacciones tienen, en general, una primera parte informativa y una segunda parte de solicitud de accin (usualmente un mensaje de delegacin de tarea). Las o o transacciones no slo admiten, pues, un contenido, sino tambin una relacin preteno e o dida entre dos agentes. Ambos aspectos deben especicarse expl citamente. Los lenguajes de comunicacin de agentes (ACL) estn inspirados a menudo por la o a teor del acto del habla, que hace distinciones entre el contenido y el efecto pretendido. a
4.4.3.
Patrones transaccionales
Ya por ultimo, nos centraremos en el nivel de detalle del modelo de Comunicacin, o que consiste en la especicacin detallada del mensaje: o Su contenido, expresado mediante una declaracin proposicional (locucin). o o Su intencin2 , expresada mediante un mensaje escrito (ilocucin). o o Los tipos predenidos son los ya indicados en la tabla 4.3 (solicitar, exigir, ordenar, rechazar; proponer, ofrecer, acordar, rechazar; preguntar, responder, informar y enviar informe). Cuadro 4.4: Semntica de algunos tipos de comunicacin. a o request/propose require/offer order/agree reject ask/reply report inform Negociacin para colaborar o Compromiso condicional Efectuar un acuerdo Negarse a efectuar la peticin o Preguntar sobre informacin y recibir respuesta o Informe como consecuencia de un acuerdo previo Accin informativa independiente o
Por supuesto, no slo es posible enviar mensajes simples, tambin se pueden formar o e cadenas naturales de tipos de mensajes. El resumen de la especicacin de los intercambios de informacin se aglutina en el o o formulario CM-2, que slo suele ser necesario para patrones de comunicacin complejos o o (es un detalle del CM-1). Su estructura es la siguiente: Identicador y nombre de la transaccin. o Agentes involucrados (emisor, receptor). Items de informacin; se componen a su vez de: o rol (objeto central + item soporte3 )
2 3
Intencin = propsito + cometido. o o Textos explicativos de material del dominio, trazados de razonamiento, explicaciones porqu/coe
mo.
Laura Castro
4.4. El modelo de Comunicacin o forma sintctica (cadenas de datos, diagramas, etc.) a medio (ventana pop-up, interfaz de l nea de comandos, intervencin humana. . . ) o Especicacin del mensaje. o Control del mensaje (es un renado del control especicado en el plan de comunicacin, que usar la misma notacin: diagramas de estado o o a o pseudocdigo). o
39
4.4.4.
Tcnicas de validacin e o
Para validar el modelo de Comunicacin suelen emplearse walkthroughs en el plan o de comunicacin, para vericar la adecuacin de la estructura de las transacciones, la o o completitud de la lista de items de informacin y la necesidad de ayuda o explicacin. o o Existen tcnicas ms formales, como la tcnica Mago de Oz, que se basa en la e a e misma idea que el test de Turing. No obstante, su uso es caro pues es una tcnica e experimental para validar la interaccin que requiere de la construccin de un software o o maqueta. Gu de Nielsen para la usabilidad a Presentar diagramas simples y naturales. Hablar el lenguaje del usuario. Minimizar la carga de memoria del usuario. Mantener la consistencia de la terminolog a. Proporcionar informacin sobre lo que est pasando (retroalimentao a cin). o Mostrar salidas claramente marcadas desde los estados no deseados. Ofrecer atajos al usuario experto. Gu para pesar el modelo de Comunicacin as o Entradas clave: Tareas hoja del TM. Funciones de transferencia del KM. Tener en cuenta las capacidades de los agentes (AM). La formulacin sintctica del medio es algo entre el CM y el DM (se o a aborda en el CM si existen razones conceptuales para ello). Decidir sobre la informacin de soporte (no en DM). o Ingenier del Conocimiento a
40
Actividades del modelo de Comunicacin o Identicar los objetos de informacin centrales para ser intercambiados o entre agentes. Identicar las transacciones asociadas. Dibujar los DD importantes. Combinar esto en un plan de comunicaciones completo. Especicar las transacciones individuales (CM-1 y CM-2). Validar y pesar el modelo.
Laura Castro
Cap tulo 5 Del anlisis a la implementacin: el a o modelo de Dise o en n CommonKADS

El Diseo del sistema recibe como entradas: n El modelo de Conocimiento (requisitos para la resolucin de probleo mas) El modelo de Comunicacin (reglas de interaccin) o o Otros modelos (requisitos no funcionales)
Y obtendr como salidas la especicacin de una arquitectura software y el diseo a o n de la aplicacin dentro de dicha arquitectura. o
Dominio Aplicacion Sistema Software
Modelos de Analisis Modelo Conocimiento

arquitectura software libros protocolos
expertos
Modelo Comunicacion Modelo Tareas Modelo Diseo
diseo algoritmos diseo TDAs plataforma hardware lenguaje implementacion
casos estrategias razonamiento tiempo respuesta requerido
Modelo Agentes Modelo Organizacion
problemas y oportunidades
Figura 5.1: Del anlisis al diseo en CommonKADS. a n 41
42
Apuntes 5. El modelo de Diseo en CommonKADS n
Entendemos por arquitectura del sistema la descripcin del software en trminos de o e descomposicin en subsistemas, selecin del rgimen(es) de control y descomposicin o o e o de los subsistemas en mdulos software. o Especicar esta arquitectura es el punto central el proceso de diseo, y se parte de n una serie de arquitecturas de referencia para sistemas basados en CommonKADS.
5.1.
Principio de Conservacin de la Estructura o
El principio de Conservacin de la Estructura es el principio central del diseo o n moderno: Debe preservarse el contenido y la estructura del modelo de anlisis durante a el diseo. n Segn esta losof disear es aadir detalles espec u a, n n cos de implementacin a los o resultados del anlisis, preservando la informacin como nocin clave. a o o Esto est directamente relacionado con los criterios de calidad del diseo en general: a n Minimizar el acoplamiento. Maximizar la cohesin. o Transparencia. Mantenimiento.
A estos criterios generales, cuando hablamos de diseo de SBCs, se aaden los n n siguientes: Reusabilidad de elementos de diseo/cdigo resultante. n o Mantenimiento y adaptabilidad (el desarrollo en un solo paso es normalmente poco realista, especialmente para sistemas intensivos en conocimiento). Potencia explicativa. Adquisicin de conocimiento/facilidad para el renado (el conocimieno to cambia con el tiempo).
5.2.
El modelo de Dise o n
En la construccin del modelo de Dise o se seguirn los siguientes pasos: o n a Laura Castro
5.2. El modelo de Diseo n

Paso 1 Paso 2 Paso 3 Paso 4
43
Diseo de la Arquitectura
Especificacion de la Plataforma hw/sw
Detalle de la especificacion de la Arquitectura
Detalle del diseo de la Aplicacion
Arquitecturas de referencia de CommonKADS
Lista de entornos disponibles
Checklist de decisiones arquitecturales
Mapeado predefinido a arquitectura
Conocimiento de soporte al Diseo en CommonKADS
Figura 5.2: Pasos en la construccin del modelo de Diseo. o n
5.2.1.
Dise o de la arquitectura del sistema n
El primer paso en la construccin del modelo de Diseo es, pues, la especicacin o n o de la arquitectura global. El principio que se sigue es separar la funcionalidad de aspectos de la interfaz, para lo que, como ya se ha mencionado, se descompone el sistema en subsistemas, se dene un rgimen de control global y se descomponen los subsistemas en mdulos software. e o La arquitectura global seguir el modelo MVC (Model View Controller ), que fue a desarrollado para el diseo O.O. en lenguaje Smalltalk-80 pero que ha sido adoptado n mayoritariamente en el diseo de software. Este modelo distingue entre los objetos de n una aplicacin y su visualizacin y dene una unidad de control central con rgimen o o e dirigido por eventos. El sistema construido siguiendo esta losof tendr tres subsisa a temas principales, indicados en la gura 5.3.
Subsistema Modelo de Aplicacion El modelo de la aplicacin contiene los datos y funciones de la aplicacin, esto es, o o los objetos del modelo de conocimiento. Los datos estn presentes en forma de bases de conocimiento y datos dinmicos a a manipulados durante el razonamiento (por ejemplo, roles dinmicos), mientras que las a funciones estn representadas por las tares, inferencias y funciones de transferencia. a Subsistema Vistas Este subsistema se encarga de la visualizacin de los datos y funciones de la aplio cacin, haciendo posible la visualizacin de la informacin esttica y dinmica a los o o o a a agentes externos, como el usuario o bien otro sistema software. Ingenier del Conocimiento a
44
entrada
Controlador
usuario sensores
maneja entradas desde agentes externos y funciones internas
vistas controlador
Vistas proporcionan salida a agentes externos (IU, query a BD)
invocacion de funciones
informe de resultados
Modelo Aplicacion funciones de razonamiento (tareas, inferencias) esquema(s) del dominio bases de datos/conocimiento
Figura 5.3: Esquema del Model View Controller. Es posible tener visualizaciones mltiples, agregar la visualizacin de mltiples obu o u jetos de la aplicacin, etc. o La inclusin de este subsistema requiere actualizacin arquitectural o bien mecao o nismos de integracin, como pueden ser una tabla de mapeos o protocolos de mensajes o para noticacin de cambios en el estado de los objetos. o Subsistema Controlador Es la unidad central de control y comandos. Suele estar dirigido por eventos, proporcionando handlers para eventos tanto externos como internos. Permite la activacin de las funciones de la aplicacin y decide qu hacer cuando o o e llegan los resultados. Puede denir sus propias vistas de control para proporcionar informacin sobre el proceso (por ejemplo, al usuario experto). Suele tener un reloj o interno y una agenda, pudiendo tener un comportamiento tipo daemon.
Algunos otros aspectos importantes de la arquitectura MVC, adems de haber sido a desarrollada en el contexto de la O.O. (de hecho, es una descomposicin funcional de o objetos), pasan por darnos cuenta de que su uso no est necesariamente restringido a a una aproximacin al diseo/implementacin O.O., aunque el paradigma de paso de o n o mensajes debe ajustarse bien a los entes de la arquitectura. A la hora de descomponer el modelo de la aplicacin en subsistemas debemos tener o en cuenta que se debe permitir el diseo preservando la estructura, as como permitir n la integracin con otras aproximaciones de la IS. o Laura Castro
5.2. El modelo de Diseo n
45
Las opciones son dos: una descomposicin funcional o bien una descomposicin O.O. o o La opcin escogida por CommonKADS es la segunda, ya que se ajusta bien al carcter o a declarativo de las especicaciones de los objetos en el modelo de conocimiento (puede verse una tarea como un objeto) y adems simplica el mapeado con implementaciones a O.O. en muchas herramientas. Este primer paso en la construccin del modelo de Diseo queda reejado en el o n modelo DM-1 (ver apndices). e
5.2.2.
Identicacin de la plataforma de implementacin o o
El segundo paso en la construccin del modelo de Diseo es la identicacin de la o n o plataforma de implementacin. o Los requisitos espec cos del cliente suelen restringir esta seleccin, lo que es una o razn para colocarla en un paso temprano dentro del proceso. Hoy en d la seleccin o a, o del software es mucho ms importante que la del hardware, aunque puede no serlo en a el caso de aplicaciones en tiempo real. En caso de que la seleccin fuese ms o menos libre, deber o a amos considerar posponerla hasta que se nalizase el tercer paso (especicacin de los componentes de la o arquitectura). Algunos criterios para la seleccin de la plataforma de implementacin pueden ser: o o Existencia de librer de clases de objetos vista (puede ser necesario as construir muchos uno mismo en caso contrario). Formalismo en la representacin del conocimiento (preferentemente o una representacin declarativa). o Existencia de interfaces estndar con otro software (ODBC, CORa BA,. . . suelen ser necesarias a menudo). Facilidades para la escritura del lenguaje (un tecleado dbil normale mente implica ms trabajo en el mapeado del modelo de anlisis). a a Facilidades de control/protocolos (soporte de paso de mensajes, posibilidad de multi-threading). Soporte de CommonKADS (extensin de plataformas dedicadas o por ejemplo, librer de objetos, links con herramientas CASE que as soporten CommonKADS). Este segundo paso en la construccin del modelo de Diseo queda reejado en el o n modelo DM-2 (ver apndices). e Ingenier del Conocimiento a
46
5.2.3.
Especicacin de los componentes de la arquitectura o
El tercer paso en la construccin del modelo de Diseo es la especicacin de los o n o componentes arquitecturales. Esta especicacin consiste en denir los componentes de la arquitectura en ms o a detalle. En particular, se denen las interfaces entre los subsistemas y/o mdulos de o los sistemas, especicando sus componentes. Se realiza as un diseo general de las utilidades de la arquitectura. Algunas plata n formas incorporan una arquitectura CommonKADS en las que las decisiones han sido predenidas; esto tiene como ventaja que este paso se hace ms rpido y fcil, pero por a a a contra destruye la capacidad creativa. Utilidades del Controlador El controlador realiza un control dirigido por eventos con un componente central de control. Puede verse como una implementacin del modelo de comunicacin. o o Las declaraciones t picas son: Activacin y nalizacin de funciones de la aplicacin. o o o Decisin sobre la posibilidad de que el usuario realice interrupciones o para informarse del trazado/contexto. Posibilidad de abortar funciones. Manejo de funciones de transferencia/transacciones. Necesidad o no de procesado concurrente. Utilidades del Modelo de Aplicacin o Tarea: para los objetos necesitamos denir dos operaciones: Un mtodo de inicializacin, para iniciar los valores de la tarea. e o Un mtodo de ejecucin, que invoque al mtodo de la tarea. e o e Mtodo de la Tarea: e Elementos del lenguaje de control (constructos de control). Declaratividad del lenguaje de control (por ejemplo, en O.O., la implementacin natural es una operacin execute, pero destruye o o la naturaleza declarativa; es necesario objeticar la estructura de control). Inferencias: Tres operaciones principales: execute, more solutions y hassolution. Enlaces a los mtodos de inferencia. e Mtodos de Inferencia: e Laura Castro
5.2. El modelo de Diseo n Librer de mtodos. a e Permitir relaciones muchos-a-muchos entre mtodos e inferencias. e Funciones de transferencia: Implementacin v patrones de paso de mensajes. o a Roles dinmicos: a Tipos de datos permitidos: elemento, conjunto, lista,. . . Operaciones de acceso/actualizacin, seleccin, eliminacin, aadir, o o o n etc. Roles estticos: a Funciones de acceso/consulta. Modelo del dominio (bases de conocimiento): Formato representacional. Funciones de acceso/consulta. Funciones de modicacin/anlisis. o a Constructos del dominio: Simplemente inspeccionar. Utilidades de las Vistas Visualizaciones grcas estndar. a a Generacin de formatos externos (por ejemplo, consultas SQL). o Utilidades arquitecturales de actualizacin de vistas: o Tablas de mapeado. Protocolos de mensajes. Interfaces de Usuario Interfaz con el usuario normal: Considerar utilidades especiales (por ejemplo, generacin de leno guaje natural). Uso de visualizaciones espec cas del dominio (depende del diseo n de la aplicacin). o Interfaz con usuarios expertos: Interfaz de trazados. Interfaz de edicin/renado para bases de conocimiento. o
47
Este tercer paso en la construccin del modelo de Diseo queda reejado en el o n modelo DM-3 (ver apndices). e Ingenier del Conocimiento a
48
5.2.4.
Especicacin de la aplicacin en el contexto o o de la arquitectura
El ultimo paso en la construccin del modelo de Diseo es la especicacin del o n o diseo en el contexto de la arquitectura. Esta tarea se divide en dos: n 1. Mapear la informacin de anlisis en la arquitectura.- Se necesitan o a construir o disponer de herramientas de mapeo (por ejemplo, un API). La extensin del mapeo depende de las decisiones que estn ya conso a truidas en la arquitectura. 2. Aadir detalles de diseo.- Debe hacerse el diseo de la aplicacin para n n n o el controlador: Su entrada principal es el Modelo de Comunicacin. o A menudo es necesario el procedimiento natural. Como m nimo es necesario un procedimiento de bootstraping. Otras funciones: manejo de requisitos de explicacin o control de usuario sobre el proceso de razonamiento interrupcin del razonamiento/control estratgico o e permitir escenarios what-if (simulacin) o
La especicacin de la aplicacin en el contexto de la arquitectura queda reejado o o en el formulario DM-4 (ver apndices). e
5.3.
Dise o de prototipos n
El prototipado rpido tiene una mala reputacin porque este trmino ha sido a o e empleado para referirse a implementaciones rpidas y poco cuidadas imposibles de a mantener y escalar. No obstante, hoy en d est considerada como una buena tcnica a a e para comprobar el grado de comprensin que se tiene sobre aquello que se desea llegar o a contruir.
5.3.1.
to?
Prototipado de subsistemas de razonamiento
Cundo puede ser necesario construir un prototipo del subsistema de razonamiena
Cuando contemos con elementos recientemente construidos en el modelo de conocimiento (plantillas nuevas). Cuando sospechemos de agujeros en el conocimiento del dominio. En general, para validar y vericar el modelo del dominio: validar (es el sistema adecuado?) Laura Castro
5.4. SBCs distribuidos vericar (es adecuado el sistema?)
49
Adems la plataforma de implementacin debe soportar el prototipado, su consa o truccin debe ser cuestin de d o o as.
5.3.2.
Prototipado de interfaces de usuario
La construccin de un prototipo de interfaz con el usuario nos brinda la oportunidad o de comprobar la interfaz sin necesidad de desarrollar toda su funcionalidad. Puede ser necesario si el formato de vistas es complejo e incluso para poder construir una interfaz externa ms completa. a
5.4.
SBCs distribuidos
Hay varios campos en los que potencialmente ser interesante usar una arquitectura a distribuida a la hora de construir un SBC: Servicios de razonamiento El modelo de aplicacin funciona como un servicio. No es necesaria o una interfaz de usuario. Servidores basados en conocimiento/ontolgicos o Unican la terminolog SSEE. Un ejemplo ser el GRASP, un servia a dor para piezas de arte. Servicio de mtodos e Un sistema distribuido en forma de un conjunto de mtodos. e Y, por supuesto, combinaciones de los mencionados.
Cap tulo 6 Tcnicas para la adquisicin del e o conocimiento

Llamamos adquisicin del conocimiento al proceso de recoger los datos e inforo macin que necesitamos para construir nuestro SBC. o Para ello se utilizan una serie de tcnicas que pueden ser manuales, usualmente ms e a fciles de usar por parte del ingeniero de conocimiento y ms fciles de aceptar por a a a el experto aunque ms costosas en tiempo, semiautomticas e incluso completamente a a automticas. a El problema es que la adquisicin del conocimiento no es una actividad inmediata. o Los propios expertos no son conscientes de su conocimiento y su forma de actuar, que les resulta complicado verbalizar, pues muchas veces es pragmtico. Para paliar esto en a mayor o menor medida es util elegir, dentro de lo posible, varios expertos, que pueden ser de distintos tipos: Experto terico o acadmico: posee conocimientos ms encaminados a o e a la parte docente, ms formales. Suele ser capaz de explicar racionala mente pero est poco relacionado en la prctica. a a Experto prctico: resuelve los problemas d a d aporta una visin a a a, o ms real (escenarios). Da soluciones, es un experto tcnico, aplica a e algo porque funciona, sin quizs tener una explicacin formal. a o Pese a todo, nunca debemos olvidar que existe un componente personal muy importante, que no se puede evitar.
6.1.
Escenarios de adquisicin del conocimiento o
Hay cuatro escenarios t picos de adquisicin del conocimiento: o
51
52
Apuntes 6. Tcnicas para la adquisicin del conocimiento e o
SISTEMA EXPERTO
EXPERTO
INGENIERO CONOCIMIENTO
Motor Inferencias
(conocimento general solucionador de problemas)
Base Conocimientos
(conocimientos del dominio)
Figura 6.1: Primer escenario de adquisicin del conocimiento. o El escenario 1 (gura 6.1) es el ms t a pico.
SISTEMA EXPERTO
EXPERTO
PROGRAMA EDITOR INTELIGENTE
Motor Inferencias
Base Conocimientos
Figura 6.2: Segundo escenario de adquisicin del conocimiento. o El escenario 2 (gura 6.2) surge de la mente de McCarthy (1968) y su Advice Taker, aunque su mejor trabajo fue teiresias (1976). Consiste en que el experto habla con el programa en lugar de con el ingeniero de conocimiento (que es, obviamente, el que ha construido el programa!), ayudando de este modo a que se implique y favoreciendo la depuracin. Por supuesto, lo extremadamente complejo es la construccin del o o mencionado sistema/programa interlocutor. El programa de induccin por ejemplo, una red de neuronas (escenario 3, gura o 6.3) intenta extraer algn tipo de conocimiento, generalizaciones fundamentalmente, u a partir de los datos. Este conocimiento se traducir posteriormente al mundo del a SBC (paso que, por cierto, puede ser no trivial ni directo). La ventaja es que ya es una tcnica automtica (salvo en la introduccin de los datos). El problema, que la e a o construccin de estos programas de induccin que generalicen algo util no es fcil. o o a Laura Castro
6.1. Escenarios de adquisicin del conocimiento o
53
SISTEMA EXPERTO
DATOS
PROGRAMA DE INDUCCION
Motor Inferencias
Base Conocimientos
Figura 6.3: Tercer escenario de adquisicin del conocimiento. o
SISTEMA EXPERTO
LIBROS TEXTO
PROGRAMA DE COMPRENSION DE TEXTO
Motor Inferencias
Base Conocimientos
Figura 6.4: Cuarto escenario de adquisicin del conocimiento. o El programa de comprensin de texto (escenario 4, gura 6.4) deber comprender o a diagramas, esquemas, y poseer un criterio. La interpretacin del lenguaje natural, o aunque sea referido a un campo espec co, es algo muy complicado. El conocimiento, por su parte, tambin puede ser de muchos tipos (lo iremos viene do).
54
DIRECTIVOS
Identificacion Aprobacion proyecto
EXPERTOS
Descripcion tareas Identificacion ejecuciones exito Respuestas y soluciones
USUARIOS
Hechos y relaciones conocidos Consejos
Plantea problemas y cuestiones
Selecciona buen dominio y tarea Aprende sobre la tarea de directivos, expertos y usuarios Conoce como construir SSBBCC Conoce las ventajas e inconvenientes de las herramientas conocimiento estructurado en forma de conceptos y formalizado
Analiza necesidades de representacion y estrategias de control Regla del pulgar, heuristicas y reglas del dominio Elige la herramienta Construye los distintos prototipos La integra y la mantiene
Laura Castro
6.1. Escenarios de adquisicin del conocimiento o
55
Declogo del Ingeniero de Conocimientoa a Facultades de Comunicacin o Utilizacin efectiva del lenguaje (oral y escrito). o Capacidad de representacin esquemtica. o a Capacidad de interpretacin. o Trato agradable. Inteligencia Capacidad de aprendizaje. Apertura de mente y exibilidad. Tacto y Diplomacia Reexin y tacto. o Energ y Paciencia a Valoracin del trabajo en equipo. o Capacidad de decisin, discusin, cr o o tica y estimulacin. o Persistencia Lgica o Claridad de pensamiento, capacidad de orden. Versatilidad e Inventiva Potencia anal tica. Imaginacin. o Autoconanza Conocimiento del Dominio de Aplicacin o Conocimiento acerca de la Programacin del Sistema o
El problema es que estas todas estas cualidades no suele reunirlas una sola persona, de modo que es necesario la creacin de grupos interprofesionales. o
a
Cuadro 6.1: Declogo del Ingeniero de Conocimiento. a
56
Apuntes 6. Tcnicas para la adquisicin del conocimiento e o Actividad Bsqueda de heur u sticas generales Bsqueda de rutinas u y procedimientos Bsqueda de conceptos u y vocabulario Heur sticas y Procedimientos de toma de decisiones Tcnica e Entrevistas no estructuradas Entrevistas estructuradas Observacin directa o Anlisis de Tareas a Emparrillado Clasicaciones Trazado del proceso de razonamiento Simulaciones Trazado del proceso de razonamiento (Anlisis de a protocolos)
Tipo Conocimiento declarativo procesal semantico
episodico
Bsqueda de heur u sticas analgicas de solucin o o de problemas
Cuadro 6.2: Mtodos de Adquisicin del Conocimiento. e o La tcnica a utilizar para la adquisicin del conocimiento depende no slo del tipo e o o de conocimiento a adquirir, sino tambin del dominio, circunstancias particulares, etc. e
6.2.
Las entrevistas
Las entrevistas son un mtodo sencillo, manual, de adquisicin del conocimiento e o que puede ser utilizado por cualquier persona, en cualquier dominio, con cualquier tipo de experto y con cualquier tipo de conocimiento. Las primeras entrevistas suelen recibir el nombre de entrevistas de despliegue y su nalidad es interaccionar con el experto, conocerse mutuamente, etc. Normalmente hay que vencer una mala predisposicin, explicar lo que se pretende hacer, lo que se espera o del experto,. . . y por tanto su duracin no deber ser muy extensa. o a A continuacin aparecen las sesiones de adquisicin que son de dos tipos: o o No estructuradas (sesiones de carcter general). a Estructuradas (sesiones de carcter espec a co). Tras la toma de contacto, las entrevistas no estructuradas (no se esperan respuestas cerradas a las preguntas que se plantean) sirven para familiarizarse con el dominio concreto. Hay que saber conducirlas para evitar divagaciones y ancdotas del experto. e Muchos de los datos que se adquieran aqu no sern directamente trasladables al SBC, a pero nos ayudarn a hacernos una idea sobre posibles estructuras inferenciales, etc. a Se har por ultimo una entrevista estructurada para cada parte del sistema identia cado, donde s ya se necesitan respuestas concretas. Suelen tener un guin con puntos o similares a: Laura Castro
6.2. Las entrevistas
57
1. Tcnicas de anlisis basadas en tareas familiares. e a a) Observacin directa. o b) Resolucin de casos destacados o dif o ciles. 2. Tcnicas basadas en entrevistas. e a) No estructuradas. b) Estructuradas. c) Anlisis de casos histricos destacados y dif a o ciles. 3. Tcnicas de anlisis basadas en tareas especiales. e a a) Tcnicas psicolgicas para estudiar resolucin de problemas. e o o 1) Anlisis de protocolos. a 2) Anlisis de toma de decisiones. a 3) Brainstorming. b) Tcnicas psicolgicas para estudiar aprendizaje y memoria. e o 1) Resolucin de tareas con informacin limitada. o o 2) Resolucin de tareas con procedimientos limitados. o c) Tcnicas que enjuician caracter e sticas de los conceptos. 1) 2) 3) 4) Clasicaciones. Emparrillado. Escalonadas. Escalamiento psicolgico. o
Cuadro 6.3: Clasicacin de los Mtodos de Adquisicin de Conocimiento. o e o
58
Apuntes 6. Tcnicas para la adquisicin del conocimiento e o Descripcin general de la tarea. o Descripcin de variables involucradas/inuyentes. o Reglas generales que ligan a las variables: Plantilla 1: Por qu? Convierte armaciones en reglas. e Plantilla 2: Cmo? Genera reglas de menor nivel. o Plantilla 3: Cundo? Extrae generalidad de las reglas, generando a otras. Plantilla 4: Qu alternativas hay? Extrae generalidad de las reglas, e generando otras. Plantilla 5: Qu pasar si? Genera ms reglas, con condiciones e a a diferentes. Plantilla 6: Algo ms? Genera ms reglas auxiliares o no contema a pladas.
Es clave tener en cuenta los aspectos no verbales del experto y distinguir sus opiniones personales (sobre todo acerca de la propia ingenier de conocimiento e inteligencia a articial) de la informacin objetiva. o Recomendaciones Las entrevistas deben ser peridicas, hacerse a las mismas horas/d preferibleo as, mente por la maana temprano. Es recomendable usar el lugar de trabajo del experto n como lugar de reunin, sobre todo al principio, tanto por comodidad como porque o tenga sus materiales a mano para consultar. Resulta muy conveniente ir enseando al experto los progresos que se van haciendo. n Por ello, hay que digerir el resultado de una entrevista (realizando un informe para repasarlo con l en la siguiente sesin) antes de concertar otra. e o
6.2.1.
Entrevistas m ltiples u
Un ingeniero de conocimiento y m ltiples expertos u Se da cuando los expertos trabajan en grupo o hay varios tipos de expertos. Si stos e son compatibles, esta clase de entrevistas puede proporcionar muy buenos resultados, por el contraste de opiniones y puntos de vista, lo que asegura un mejor renamiento y ms y mejor conocimiento, de ms alto nivel, aunque si la adquisicin de conocimiento a a o es de carcter general (no estructuradas), no resulta demasiado util hacer esto con a muchos expertos. El problema se presenta si los expertos son incompatibles entre s en ese caso se ; debe prescindir siempre de los conictos y dividir las entrevistas. El problema puede presentarse tambin si es el ingeniero de conocimiento el que no es capaz de controlar e las sesiones (los expertos se centran en un tema, discuten de sus cosas,. . . ) o no se puede concentrar (es muy pesado). Laura Castro
6.3. El anlisis de protocolos a M ltiples ingenieros de conocimiento y un experto u
59
Nunca deber hacerse una entrevista con un solo experto y ms de tres ingenieros a a de conocimiento (no apabullar). Este tipo de entrevistas resulta util cuando en el equipo de trabajo contamos con ingenieros senior/junior. La ventaja que tiene la participacin de varios ingenieros es que se pueden evitar o sesgos introducidos por ellos mismos, cada uno puede aportar cosas, y no se producen vac entre la adquisicin y la implementacin del conocimiento. os o o La desventaja suele ser que el experto es reticente, pues estas sesiones son ms a pesadas para l, aunque siempre pueden hacerse ms cortas. Lo que como sea debe e a evitarse son las discusiones entre los propios ingenieros (mala imagen!). M ltiples ingenieros de conocimiento y m ltiples expertos u u El principal inconveniente de estas entrevistas es que consumen much simo tiempo, aunque tambin aglutina las ventajas de las vistas anteriormente. e Es necesario nombrar un moderador que controle la sesin. Es una de las opciones o ms usadas. a
En general, la tcnica de entrevistas para adquirir conocimiento es cara en tiempo, e en cualquiera de sus variantes. Es una tcnica introspectiva (el experto tiene que e pensar en lo que sabe y verbalizarlo) y requiere un esfuerzo adicional por parte del ingeniero de conocimiento (que debe hacerse con el vocabulario, confeccionar informes, etc). Visto por el lado bueno, es una tcnica muy general, como hemos dicho, que se e puede utilizar en muchos campos y en distintas etapas del desarrollo, sin requerir para ello un entrenamiento especial. Es clave tener en cuenta los aspectos no verbales del experto y distinguir sus opiniones personales (sobre todo acerca de la propia ingenier de conocimiento e inteligencia a articial) de la informacin objetiva. o
6.3.
El anlisis de protocolos a
El anlisis de protocolos es otra tcnica de adquisicin del conocimiento que rea e o quiere algo ms de conocimiento por parte del ingeniero de conocimiento, pero tampoco a un nivel excesivo. Consiste en grabar, bien slo audio o combinado con v o deo, al experto mientras resuelve una tarea, un problema concreto del dominio, motivo por el cual no goza de demasiada aceptacin. Sin embargo, al poder acceder a la grabacin cualquier ingeniero o o de conocimiento, se obvian algunos otros problemas de las entrevistas. Debe quedarle claro al experto que no tiene que explicar lo que va haciendo, sino simplemente verbalizar los pasos que est siguiendo. Pese a ello, el mtodo sigue siendo a e introspectivo.
60
Es recomendable usar siempre ms de una tcnica de adquisicin del conocimiento, a e o y tanto las entrevistas como el anlisis de protocolos son combinables con cualquier a otra. El anlisis de protocolos pasa por cuatro fases: a 1. Obtencin del protocolo.- Se dan las instrucciones al experto: verbalio zar lo que dice en su cabeza durante la resolucin del caso, sin intentar o explicarlo. Se pueden tomar notas. 2. Transcripcin y segmentacin.- Escuchar/ver y transcribir lo grabado, o o separndolo en frases que tengan sentido (desde el punto de vista del a conocimiento). No todo el mundo hace las segmentaciones igual, ni una misma persona segmentar igual una transcripcin la primera a o que sucesivas veces. 3. Codicacin.- Se identican objetos, valores, operadores y relaciones. o Se obtienen las reglas expl citas en el texto (reglas inferenciales sencillas). 4. Interpretacin.- Se obtienen las reglas impl o citas (cosas que no nos dice directamente), se puede analizar la forma de razonar (progresivo, regresivo,. . . ). El problema es que un protocolo solo no nos sirve, hay que probar muchos casos. Por esto y por su inherente dicultad, suele usarse exclusivamente en casos puntuales. Existen variantes: Anlisis del Recuerdo a Si el experto no es capaz de hablarnos mientras resuelve el problema, puede permit rsele verbalizar el proceso al nalizarlo. Anlisis de las dos Fases a Consiste en comparar resultados con el propio experto en la fase de codicacin. o Anlisis del Registro a Aade una entrevista al nal del proceso. n Anlisis de Casos Dif a ciles En vez de cualquier caso, se resuelven casos concretos de dicultad espec ca. Ventajas El ujo de informacin es unidireccional (en entrevistas era bidireccional), del o experto al ingeniero de conocimiento, por lo que se minimizan las interacciones. El protocolo puede ser analizado por tantos ingenieros de conocimiento como sea necesario. Laura Castro
6.4. Cuestionarios
61
Permite adquirir conocimiento que es dif de adquirir mediante entrevistas cil (aspectos relacionados con la estrategia de razonamiento que usa el experto, algo inconsciente que aqu queda reejado). El experto es el reactivo limitante. Inconvenientes Se pueden introducir sesgos (igual que en las entrevistas) inconscientes. Es una tcnica muy costosa en tiempo (el experto debe aprender a hacer el anlisis e a de protocolos que no razone sino que acte), y es muy larga y pesada para el u ingeniero de conocimiento (sobre todo si no tiene experiencia), que debe realizar la transcripcin, segmentacin, etc. o o Es una tcnica introspectiva. e
6.4.
Cuestionarios
Los cuestionarios son una tcnica ms o menos sencilla que consiste en presentar e a al experto una serie de chas u hojas con preguntas concretas (de ah su utilidad). Ventajas Flujo unidireccional. El experto puede contestar el cuestionario cuando desee y donde decida (suelen aceptarla con agrado gracias a esto), por lo que no hay problemas referentes a concierto de reuniones, horarios, etc. Consume menos tiempo que las otras tcnicas vistas hasta ahora. e Es util para describir objetos, jerarqu certidumbres, relaciones del dominio,. . . as, Inconvenientes Su elaboracin no es sencilla. o Es una tcnica introspectiva. e
6.5.
Anlisis del movimiento de ojos a
El anlisis del movimientode ojos es una tcnica de adquisicin del conocimiena e o to que slo se puede usar en los campos en que sea necesario un reconocimiento visual o del problema por parte del experto (existe un aparato Eye Mark Recorder que registra la direccin, posicin y duracin de la mirada). o o o Ingenier del Conocimiento a
62
Los datos que se obtienen no tienen por qu ser directamente trasladables al sistee ma/dominio, aunque s pueden dar informacin sobre el comportamiento del experto, o siendo as un buen punto de partida. Puede ser clave para descubrir la diferencia entre lo que se hace y lo que hay que hacer (que suele ser lo que el experto comunica). Es una tcnica no introspectiva, cuyo principal inconveniente es su carest e a.
6.6.
Mtodo de observacin directa e o
Esta tcnica de adquisicin del conocimiento es siempre recomendable. La obsere o vacin directa consiste en acudir al lugar de trabajo del experto y observar all su o comportamiento. Su inters reside en que se ve lo que realmente pasa, eliminando las interpretacioe nes subjetivas sobre el trabajo del experto. Es un mtodo no introspectivo, aunque e siempre se pueden hacer preguntas y, por supuesto, tomar notas. Puede ser interesante concertar una entrevista despus para aclarar dudas. e Su objetivo fundamental es captar conocimiento procesal, siendo util para renar el sistema (no en conocimiento, pero s a lo mejor en aspectos relacionados con la interfaz, por ejemplo). Su principal inconveniente, la gran cantidad de tiempo del ingeniero de conocimiento que consume, aunque no afecta en absoluto al experto.
6.7.
Extraccin de curvas cerradas o
Esta tcnica suele usarse en campos en los que el conocimiento visual es impore tante, siendo especialmente interesante cuando existen relaciones espaciales entre los elementos del dominio, que se desean extraer. Consiste en confeccionar cartulinas con representaciones de los objetos del dominio (hasta un mximo, por ejemplo, 50) y pedir al experto que relacione, rodendolos, a a encerrndolos en un c a rculo, aqullos que segn su criterio formen patrones, aparezcan e u ligados, tengan caracter sticas similares, etc. Esta fase puede repetirse cuantas veces se desee, aplicando distintos criterios. Es obvio que el conocimiento obtenido por medio de la extraccin de curvas o cerradas puede no ser directamente trasladable al sistema experto, pero sin duda, ayuda en el proceso de establecimiento de relaciones entre los conceptos del dominio y/o para obtener clasicaciones. Es una tcnica bastante fcil de utilizar para el ingeniero de conocimiento, aunque e a requiere conocer con relativa profundidad el campo en que trabajamos y puede aparecer el problema de que el criterio de clasicacin sea dif de explicitar por parte del o cil experto.
6.8.
Las tcnicas de escalamiento psicolgico e o
Las tcnicas de escalamiento psicolgico son una serie de mtodos semiaue o e tomticos de adquisicin de conocimiento que constituyen el conjunto de los ms usados a o a Laura Castro
6.8. Las tcnicas de escalamiento psicolgico e o
63
en IC. Todas ellas tienen el mismo formato de datos a la entrada, una matriz triangular superior : E1 E2 . . . En1 En E1 E2 E3 . . . 0 d12 d13 . . . 0 d23 . . . .. . 0 En d1n d2n . . . d(n1)n 0
donde dij son juicios de distancia que representan cmo se parecen/diferencian o los elementos i y j del dominio. Las salidas de los tres mtodos de escalamiento psicolgico que veremos son distine o tas, pero siempre estn igual formateadas (la misma entrada y datos producen siempre a la misma salida), y hay una relacin constante entre ellas. o No obstante, la aplicacin de estas tcnicas no es sencilla, pues la parte manual, o e encargada de adquirir los elementos del dominio (del experto, mediante entrevistas) es muy importante: el conjunto de elementos debe ser completo y consistente, o de lo contrario el conocimiento que se obtenga ser incompleto, incorrecto y/o inconsistente, a ya que las distancias estn condicionadas por el contexto de propios elementos. En el a otro extremo, elegir demasiados se enfrentar con la negativa y/o imposibilidad del a experto de calcular todas las distancias. n(n 1) Una vez que se tienen los elementos del dominio, hay que obtener las dis2 tancias (si n es el nmero de elementos a manejar). Para ello existen tcnicas auxiliares u e para suplir el hecho de tener que mostrar al experto la tabla directamente: Clasicaciones: consisten en dibujar chas que representen los elementos del dominio y pedir al experto que haga grupos disjuntos con ellos, repitiendo el proceso en varias ocasiones utilizando distintos criterios. La distancia entre dos elementos ser entonces el inverso del nmero a u de veces que esos dos elementos se clasicaron juntos. Emparrillado: es un mtodo matemtico semiautomtico para calcular e a a las distancias que veremos en ms profundidad. a
6.8.1.
Escalamiento multidimensional (EDM )
Existen programas estad sticos que contienen herramientas para llevar a cabo un escalamiento multidimensional sobre un conjunto de datos. El EDM intenta colocar los elementos de la matriz en un espacio de la menor dimensionalidad posible, reduciendo al mximo la dimensionalidad de la matriz. a El problema que tiene es que a veces no es fcil interpretar los resultados, y si la a salida tiene ms de 3 dimensiones no se puede representar. a Ingenier del Conocimiento a
64
Coruna Lugo Santiago Orense P ontevedra V igo Coruna 0 90 60 170 130 150 Lugo 0 120 110 190 210 Santiago 0 120 70 90 Orense 0 100 100 0 20 P ontevedra V igo 0
Coruna Lugo Santiago Orense P ontevedra V igo
Latitud Longitud 75 20 40 60 20 20 60 80 55 20 75 20
Corua Lugo Santiago
Orense Pontevedra
Vigo
Cuadro 6.4: Ejemplo de aplicacin de EDM. o
Laura Castro
65
Adems, existen innitas salidas, porque el mtodo slo ja el origen de coordenadas a e o y no la ubicacin de los elementos (hay, por tanto, innitas orientaciones, innitas o rotaciones de los ejes), lo que genera la dicultad en la interpretacin. o No obstante, ayuda a descompilar conocimiento de los expertos, aunque tambin e puede no ser directamente trasladable al sistema experto.
6.8.2.
Anlisis de clusters (Clustering ) a
El clustering consiste en agrupar los elementos que estn ms cerca entre s En a a . este caso, se buscan los dos elementos ms prximos, se agrupan formando un nuevo a o elemento, se eliminan de las y columnas, se aade el nuevo elemento a la matriz y n se recalculan las distancias con respecto al resto de elementos, repitiendo el proceso hasta que slo queden dos elementos en la matriz, o bien hasta que en nmero de clases o u generadas sea adecuado en nuestro dominio. El resultado nal ser un dendrograma a o rbol jerrquico (ver gura 6.5). a a La cuestin ms delicada en este caso es la forma de recalcular las distancias: o a cmo lo hacemos? escogiendo el mximo? el m o a nimo? una media? La decisin deo pender de lo que sea ms conveniente en el contexto en que estemos trabajando. Esta a a tcnica tambin se incorpora en muchos paquetes estad e e sticos. Adems, como se puede a observar, una vez obtenida la matriz de elementos con sus distancias, ninguna de las tcnicas de escalamiento es introspectiva. e
66
E1 E2 E3 E4 E5 E6 E7
E1 E2 E3 E4 E5 E6 E7 10 10 7 6 13 8 4 7 8 2 8 9 12 3 8 5 5 5 6 6 9
E1 E3 E4 E5 E7 (E2 , E6 )
E1 E3 E4 E5 E7 (E2 , E6 ) 10 7 6 8 10 9 12 8 3 5 5 5 6 6 8
E1 E4 E5 E7 ((E2 , E6 ), E3 )
E1 E4 E5 E7 ((E2 , E6 ), E3 ) 7 6 8 10 5 5 5 6 6 8
E1 (E4 , E5 ) E7 ((E2 , E6 ), E3 )
E1 (E4 , E5 ) E7 ((E2 , E6 ), E3 ) 6 8 10 5 5 8
E1 ((E4 , E5 ), E7 ) ((E2 , E6 ), E3 ) E1 6 10 5 ((E4 , E5 ), E7 ) ((E2 , E6 ), E3 ) E1 (((E4 , E5 ), E7 ), ((E2 , E6 ), E3 )) 6
E1 (((E4 , E5 ), E7 ), ((E2 , E6 ), E3 ))
Cuadro 6.5: Ejemplo de clustering (I). Laura Castro
67
7 6 5 4 3 2 1
E1
E4
E5
E7
E2
E6
E3
Figura 6.5: Ejemplo de clustering (y II): dendrograma.
68
El clustering permite elicitar muy rpido conocimiento muy jerarquizado en la a mente del experto. Es util tambin para validacin, para construccin de interfaces e o o hombre-mquina (comparacin de opiniones sobre la importancia de diferentes aspeca o tos), para comprobar el nivel de nuestro sistema frente a los expertos, e incluso para vericar si las respuestas de un grupo de expertos estn al mismo nivel. a
6.8.3.
Redes ponderadas (Pathnder )
Esta ultima es la menos usada de las tres tcnicas de escalamiento psicolgico que e o vamos a ver. Su salida, como su propio nombre indica, es una red ponderada en la que los nodos son los elementos del dominio y los arcos que los unen aparecen ponderados por un peso que es la distancia que los separa. Slo existir un arco entre dos nodos si o a la distancia entre ellos a travs de cualquier camino es mayor que el valor especicado e entre ambos en la matriz de entrada:
E1 E2 E3
E1 E2 E3 4 5 13
E1 5 E3 4 E2
E1 E2 E3
E1 E2 E3 4 5 6
E1 5 6 E3 4 E2
Cuadro 6.6: Ejemplo de redes ponderadas. El pathnder es muy util si la representacin del conocimiento en nuestro sistema o utiliza algn tipo de red (por ejemplo, una red semntica), ya que la traduccin de u a o conocimiento del dominio es entonces mucho ms directa. a
Laura Castro
6.9. La teor de constructos personalizados: el Emparrillado a
69
En general, las ventajas del escalamiento psicolgico son que proporciona contenio do y a veces incluso arquitectura a nuestra base de conocimientos. Permiten comparar conocimientos, opiniones y criterios de varios expertos sobre un mismo conjunto de elementos, adems de proporcionar un mtodo riguroso para combinar conocimiento que a e procede de distintos expertos o incluso del cliente. No son tcnicas demasiado introse pectivas (salvando la etapa de determinacin de elementos y distancias entre ellos), y o estn libres de cualquier interpretacin que pudiese ser incluida por parte del ingeniero a o de conocimiento. La salida es estndar y tiene un formato riguroso, lo que hace que a diferentes ingenieros de conocimiento con distintos expertos deban obtener los mismos resultados, algo que es un buen paso hacia la reutilizacin (adems de permitir la autoo a matizacin). Por ultimo, son utiles no slo en adquisicin sino tambin en validacin o o o e o y construccin de interfaces de usuario. o En cuanto a los inconvenientes, cada tcnica tiene los suyos. En general, los e elementos y las distancias poseen un proceso de obtencin no trivial. Como hemos o visto, los EDM no son fciles de interpretar y si su salida es grca no es sencilla de a a etiquetar. En clustering puede no ser directo decidir qu criterio (mximo, m e a nimo, media) escoger para el reclculo de distancias, al igual que en redes semnticas. a a Si se usa una herramienta, debemos familiarizarnos con ella; hay que tener una base matemtico-estad a stica para poder saber si es correcto lo que hacemos y saber interpretarlo. Por ultimo, si no existe una estructura de ligazn fuerte entre elementos, o o no hay estas relaciones, estas tcnicas son intiles. e u
6.9.
La teor de constructos personalizados: a el Emparrillado
La siguiente tcnica que veremos, denominada tcnica de constructos persoe e nalizados o emparrillado (repertory grid), no es propiamente una tcnica de ade quisicin de conocimiento, sino ms bien un mtodo auxiliar de clasicacin. En la o a e o prctica se usan herramientas que la implementan, que interrogan al usuario sobre los a elementos del dominio, sus relaciones, etc. con el n de estructurar el conocimiento del experto de una determinada manera (es pues, un mtodo semiautomtico). Nosotros e a estudiaremos su funcionamiento interno. El emparrillado fue desarrollado inicialmente por George Kelly, un psiclogo cl o nico que defend que cada persona organiza sus conocimientos de una manera distinta a y adems cambiante con el tiempo, y reejaba las opiniones de las personas sobre a las cosas en forma de constructos personalizados. Su modelo cognitivo utilizado para razonar con dichos constructos ser ms tarde aplicado por Shaw y Griness a a a la IC (SS.EE. Planet, 1982), siendo as una de las primeras tcnicas de aproximacin e o automtica para tratar el problema de la adquisicin del conocimiento. a o Al estar basada en un modelo del pensamiento humano, esta es una tcnica muy e potente que sirve para tener estructurado y accesible el conocimiento de una persona. Incluye un dilogo inicial con el experto, una sesin de valoracin y un anlisis de los a o o a resultados (es decir, de los grupos, los conceptos y las dimensiones). Ingenier del Conocimiento a
70
Se utilizan dos vertientes: tcnicas binarias, que permiten clasicacin simple, y e o multivaluadas, que proporcionan una clasicacin ms rica, al ser continua, dando opo a cin a la inclusin de nociones de incertidumbre e incluso conjuntos difusos. o o Este mtodo posibilita la obtencin de informacin que el experto no es consciente e o o que conoce (no es introspectiva, por tanto, salvo en su etapa inicial, aunque puede considerarse que es intrusiva, pues desvela al experto eso que no es consciente que sab Por otra parte, matemticamente, la parrilla es una aplicacin de los elementos a). a o del dominio en un conjunto de caracter sticas. Como podemos intuir, la primera fase, de obtencin de elementos y caracter o sticas (constructos: [ci , ci ]) es el momento ms a peliagudo, aunque posteriormente existen frmulas y ecuaciones que ayudan a eliminar o redundancias e informaciones poco signicativas (juicios de umbrales, etc). Una parrilla es una matriz donde las columnas son los elementos del dominio y las las representan los constructos, que son caracter sticas en las que deseamos clasicar. Dichos constructos son bipolares, representando una oposicin de conceptos, o sirvindonos la matriz para ver cmo piensa el experto, cmo se organiza. e o o cj donde Ei cj , cj y vij son los valores que se corresponden por la relacin entre o unos y otros. Cuadro 6.7: Esquema de una parrilla. El emparrillado consta de cinco fases diferenciadas: 1. Identicacin de elementos (Ei ). o 2. Identicacin de caracter o sticas (cj ). 3. Diseo de la parrilla. n 4. Formalizacin de la parrilla. o 5. Interpretacin de resultados. o son los elementos del dominio identicados por el experto son, respectivamente, caracter sticas y su contrapartida en el dominio (su opuesto lgico) o Ei vij ... cj
6.9.1.
Identicacin de elementos Ei o
Como ya vimos en escalamiento psicolgico, los elementos del dominio se obtienen o mediante entrevista con el experto y debe lograrse un conjunto completo, consistente y representativo. Las sesiones pueden ser ms o menos hbiles, pero los elementos a a Laura Castro
71
obtenidos deben ser homogneos, representativos y tener en cuenta que no es util e manejar parrillas demasiado amplias, aunque se pueden manejar varias, lo que tambin e plantea la cuestin de cmo segmentar los elementos (normalmente, se agruparn en o o a una misma parrilla los ms homogneos a su vez entre s a e ).
6.9.2.
Identicacin de caracter o sticas cj
Las caracter sticas se obtienen de la misma manera que los elementos. Deben poder expresarse como un par de conceptos antagnicos, con el n de poder manejar o un segmento clasicatorio. No tienen por qu ser uno el polo negativo del otro, pero e s su negacin lgica en el contexto del dominio. Si el experto no fuese luego capaz de o o clasicar utilizando los conceptos establecidos ser indicativo de que stos estn mal a e a elegidos, no son los que l usa, le estar e amos obligando a clasicar segn otros cnones, u a de manera que habr que replanterselos. a a Para llevar a cabo la seleccin de caracter o sticas se usa normalmente el mtodo de las e tr adas , que consiste en tomar los elementos del dominio de tres en tres y presentarlos al experto, con la propuesta de que enuncie una caracter stica que diferencia a dos de ellos del tercero. Se ha estudiado que cognitivamente este sistema de eleccin es o mucho ms ecaz, pues el hecho de que se muestren tres elementos evita sesgos que se a producir con dos y ayuda a elaborar los constructos por oposicin y no por negacin. an o o No obstante, tambin se puede utilizar extraccin de curvas cerradas, que ya vimos, e o e incluso simplemente entrevistas. Siempre es mejor la tcnica de las tr e adas, pero se puede simultarear con alguna de stas (o con ambas) para contrastar, pues siempre e alguna puede funcionar mejor que otra con segn qu expertos. u e
6.9.3.
Dise o de la parrilla n
Una vez obtenidos elementos del dominio y caracter sticas (constructos), hay que dar valor a la parrilla. Hay varias formas de construirla, que citamos a continuacin de o menos a ms usada: a Dicotmica o Se clasica cada Ei dependiendo de si tiene o no cj (asignacin o binaria). Clasicatoria Se clasican los n Ei en un intervalo 1..n de forma que vij [1, n] representa el orden del elemento con respecto al constructo (su proximidad al constructo). Se obtiene de esta manera una escala de clasicacin o o vector clasicador. Evaluativa Se elige una escala que se adapte a los elementos y se les clasica segn u ella, pudiendo repetirse valores. Representa cmo ve el experto al eleo mento dentro de ese constructo, no siendo en este caso una escalacin o de elementos. Ingenier del Conocimiento a
72
Estos distintos mtodos de diseo de la parrilla no son excluyentes, de hecho, los e n resultados deber ser compatibles independientemente de qu forma de construccin an e o ussemos. En general, siempre es preferible una aproximacin por rangos a una binaa o ria, ya que hay tcnicas de aplicabilidad posterior que no son compatibles con datos e bipolares.
6.9.4.
Formalizacin o
Una vez diseada la parrilla, tenemos una matriz en la que las las nos muestran n cmo var una caracter o a stica de un elemento a otro, y las columnas cmo se comporo tan los elementos en el dominio (segn las caracter u sticas seleccionadas). Es decir, la tabla indica la participacin de un elemento en una caracter o stica: por columnas, la participacin de un elemento en todas las caracter o sticas, y por las, la participacin o de todos los elementos en una determinada caracter stica (constructo): E1 c1 v11 . . . . . . ... ... ... ... vij Ei vi1
cj v1j
La parrilla ha de explorarse en dos sentidos, horizontal y vertical, para obtener dos rboles jerrquicos, uno de elementos y otro de caracter a a sticas, y ver cmo estn o a relacionados. Esta fase puede automatizarse completamente. Clasicacin de elementos o Analizando la matriz por columnas (elementos), calculamos distancias entre elementos para obtener un rbol: a c1 c2 c3 c4 c5 c6 c7 c8 c9 E1 E2 E3 . . . E8 2 3 2 2 4 5 5 4 5 5 ... 4 4 2 2 4 2 1 1
asumiendo un rango [1.,5], hay varias formas de calcular las distancias, pero la que se suele usar es la suma de diferencias en valor absoluto de los valores de los elementos para cada caracter stica: Laura Castro
73
d(E1 , E2 ) = d(E2 , E1 ) = 1 + 0 + 1 + 1 + 0 + 0 + 0 + 2 + 0 = 5 De esta manera se obtiene una matriz triangular superior de distancias entre elementos, y para construir el rbol (dendrograma) se siguen los pasos que ya vimos en a escalamiento psicolgico: se buscan los dos elementos ms prximos, se eliminan de la o a o tabla, se agrupan, se recalculan distancias,. . . ). Clasicacin de caracter o sticas Para las caracter sticas tambin se va a obtener un rbol clasicatorio, pero en esta e a ocasin, como manejamos dos polos, tendremos que calcular dos distancias: o Manejable Deportivo Deportivo . . . La regla de clculo es la misma: a d1 (ci , cj ) = 0 + 1 + 3 + 1 + 0 + 1 + 0 + 1 = 7 d2 (ci , cj ) = d1 (ci , cj ) d2 (ci , cj ) = 2 + 1 + 1 + 3 + 4 + 1 + 0 + 3 = 15 donde cj se calcula a partir de cj . Si se aplic una construccin dicotmica al o o o elaborar la parrilla, simplemente se cambian los polos (se otorgan los valores complementarios); si fue clasicatoria, se invierte el orden, y si fue evaluativa, se sigue misma dinmica que en el siguiente ejemplo: a cj cj 1 2 3 4 5 5 4 3 2 1 E1 E2 E3 E4 E5 E6 E7 E8 2 3 5 2 5 3 3 2 No manejable 2 2 2 1 5 2 3 1 No deportivo 4 4 4 5 1 4 3 5 N odeportivo ...
Una vez calculadas las dos distancias para cada par de caracter sticas por elemento, tendremos una matriz construida de la siguiente forma: E1 .. . E2 ... d1 (ci , cj ) .. En c1 c2
c1 c2 . . . ci
d1 (ci , cj ) = d2 (ci , cj )
. .. . ci
74
donde la submatriz superior son las distancias directas (d1 ) y la submatriz inferior, las distancias inversas (d2 ). El paso a una matriz triangular superior se consigue eligiendo la distancia m nima de las dos (d1 , d2 ), y a partir de ah para obtener el dendrograma el proceso es el que ya conocemos.
6.9.5.
Anlisis y estudio de los resultados obtenidos a
Fundamentalmente, debemos analizar los rboles de elementos y caracter a sticas. Estudiando el primero de ellos, los problemas posibles que podemos encontrar son: Dos elementos estn muy juntos en el rbol y el experto arma que a a no deber an. Debemos comprobar que los valores de la parrilla son correctos y que los clculos estn bien hechos. a a Falta una caracter stica diferenciadora en la parrilla. Dos elementos estn muy separados en el rbol y el experto arma a a que no deber an. Debemos comprobar que los valores de la parrilla son correctos y que los clculos estn bien hechos. a a Falta una caracter stica conciliadora en la parrilla. Dos caracter sticas (constructos) aparecen muy ligadas y no deber an, segn el experto. u Debemos comprobar que los valores de la parrilla son correctos y que los clculos estn bien hechos. a a Falta un elemento diferenciador (que participa de una y no de la otra) en la parrilla. Por su parte, en el rbol de caracter a sticas se estudian tambin las caracter e sticas por pares, empezando por las ms prximas, buscando relaciones entre ellas. El objetivo a o es anar el polo. Paralelas Son caracter sticas (A, B) y (X, Y ) que se comportan: A X B Y como por ejemplo (F amiliar, Coupe) y (Habitable, N oHabitable), ya que F amiliar Habitable Coupe N oHabitable Laura Castro
6.9. La teor de constructos personalizados: el Emparrillado a sin embargo Habitable N oHabitable F amiliar Coupe
75
En estos casos, de acuerdo con el experto, se pueden resumir ambas caracter sticas en una que mantenga este comportamiento. Rec procas Son caracter sticas (A, B) y (X, Y ) que se comportan: A X B Y como se da por ejemplo en el caso de (GranCilindrada, P ocaCilindrada) y (P otente, P ocoP otente), pues GranCilindrada P otente P ocaCilindrada P ocoP otente En estos casos las caracter sticas son t picamente redundantes, puede eliminarse una de ellas o resumir ambas en una nueva. Ortogonales Son caracter sticas (A, B) y (X, Y ) que se comportan: A X A Y o B X B Y
A X B Y
como por ejemplo (Deportivo, N oDeportivo) y (N ervioso, P esado), ya que Deportivo N ervioso Deportivo P esado N oDeportivo N ervioso N oDeportivo P esado En este caso o bien uno de los polos implica relacin, o bien ambos imo plican una, el caso es que algn polo queda suelto (permite eliminar u uno de los polos). Ambiguas Son caracter sticas (A, B) y (X, Y ) que se comportan: A X B X B Y A A B B X Y X Y Ingenier del Conocimiento a
76
Apuntes 6. Tcnicas para la adquisicin del conocimiento e o como por ejemplo (Seguro, Ligero) y (Deportivo, N oDeportivo), ya que Deportivo Deportivo N oDeportivo N oDeporitvo Seguro Ligero Seguro Ligero
No queda muy clara la relacin entre las caracter o sticas (alguno de los polos no est bien denido), se puede estudiar si es posible cambiar a alguna de ellas.
Tambin se suelen construir rboles de por qu y cmo, que sirven para obtener e a e o subconjuntos y superconjuntos de caracter sticas.
Deportivo
BuenaVelocidad
Rapido
Potente
Nervioso
BuenFreno
(a) Ejemplo de rbol por qu. a e
Viajero (Familiar)
Confortable
Seguro
Silencioso
Habitable
BuenaSuspension
Frenos
Carroceria
Repris
(b) Ejemplo de rbol cmo. a o
El emparrillado es, por tanto, como ya hemos dicho, util en clasicacin o para o catalogar expertos. Ayuda tambin en mbitos de incertidumbre, o a la validacin. e a o Sus problemas residen en que los datos aportados por el experto son subjetivos, personales (surgirn distintas parrillas con diferentes expertos; el grado de distanciamiento a entre ellos marca su nivel de similitud). Laura Castro
6.10. Tcnicas especiales de adquisicin de conocimiento en grupo e o
77
6.10.
Tcnicas especiales de e adquisicin de conocimiento en grupo o
Para cerrar este cap tulo hablaremos de una serie de tcnicas especiales a usar cuane do queremos trabajar con un grupo de expertos al mismo tiempo. Sus ventajas e inconvenientes ya fueron mencionados cuando hablamos de las entrevistas mltiples (pgina 58): el precio de obtener una bases de conocimiento ms u a a completas y tener la seguridad de que se han tratado todos los aspectos relevantes del dominio/problema es la introspeccin y el esfuerzo general por ambas partes. o Las tcnicas de adquisicin de conocimiento en grupo ms destacables son: e o a 1. 2. 3. 4. 5. 6. Tormenta de ideas (brainstorming). Tcnica nominal de grupo. e Mtodo Delphi. e Entrevistas. Emparrillado. Escalamiento psicolgico. o
6.10.1.
Tormenta de ideas (Brainstorming )
En adquisicin del conocimiento, para aplicar esta popular tcnica, basada en la o e opinin sajona de que la cantidad mejora la calidad, intentaremos tener varios tipos o de expertos e ingenieros de conocimiento, que expondrn sus ideas (con una breve a explicacin) sin ningn tipo de cr o u tica. Suele ser favorable la presencia de un moderador y su utilidad es maniesta en dominios en los que se requiere inventiva. Una vez recopiladas las ideas, se llevan a cabo una serie de cribas. Las primeras se suelen basar en la aplicabilidad inmediata de la solucin propuesta, el ajuste con reso pecto a restricciones existentes (de tiempo, de coste,. . . ), la compatibilidad con otros aspectos del problema (que no supongan conictos con otros elementos ya implementados/implantados, etc). Reducida la lista, en ultimo caso se puede elegir la denitiva por votacin. o
6.10.2.
Tcnica nominal de grupo e
Esta tcnica es exactamente igual que la anterior, pero en ella las ideas se exponen e por escrito. Es mejor cuando hay gente t mida en el grupo, o que no acepta cr ticas, aplicable fundamentalmente cuando se trata con poca gente.
6.10.3.
Mtodo Delphi e
El mtodo Delphi tambin es un mtodo por escrito, basado en cuestionarios cone e e feccionados por los ingenieros de conocimiento sobre aspectos del problema que se presentan a distintos tipos de expertos. Ingenier del Conocimiento a
78
Los expertos respondern el cuestionario de forma annima, y tambin a un cuesa o e tionario sobre los cuestionarios (son las preguntas relevantes? importantes? sobran? faltan? cules?). Esto ayuda a renarlos, acometiendo una segunda vuelta acoma paada de los resultados de la anterior (media y varianza primer y tercer cuartil). n Se repite iterativamente (aunque con dos vueltas suele ser suciente) hasta obtener una respuesta ms o menos homognea acuerdo. Si existen dispersiones importantes, a e habr que pasar a algo no annimo para identicar el problema, aunque no suele ser a o necesario.
Laura Castro
Cap tulo 7 Evaluacin de los sistemas basados o en conocimiento

La evaluacin de los Sistemas Basados en Conocimiento consta de 4 aspectos que o podemos estudiar: Vericacin o Trata de estudiar la correccin formal de nuestro sistema, algo que o puede hacerse tanto durante el desarrollo como al nal del mismo. De los cuatro aspectos, es el unico criterio esttico. La mayor de a a las herramientas, como por ejemplo Nexpert incluyen correccin de o sintaxis. Validacin o Se trata de ver si el sistema es correcto, si contempla todos los casos, si el modelo computable es vlido. Para poder realizarse, el sistema a debe estar funcionando, por tanto. No es suciente realizar validacin o por mdulos, es imprescindible una prueba global integrada. o Usabilidad Usabilidad y Utilidad son conceptos relativamente recientes, inuencia de la ingenier del software. El primero representa la satisfaccin que a o tiene el usuario con el sistema, la interfaz, el tipo de respuestas, su redaccin, adecuacin a su nivel, etc. Es, pues, un criterio dinmico o o a (el sistema debe estar funcionando). Utilidad Por ultimo, la utilidad es un criterio tambin dinmico que intenta e a analizar el cambio/mejoras que se producen en el entorno/empresa en que se introduce el sistema, ver si satisface las expectativas. Se repasan las propuestas realizadas con el modelo de organizacin/contextual o (motivos que impulsaron al desarrollo del sistema) y se comprueba si se han cumplido.
79
80
Criterios
Tecnicas de Valoracion
Apuntes 7. Evaluacin de los sistemas basados en conocimiento o
Actuacion tras la evaluacion
Figura 7.1: Tcnicas de valoracin para SS.EE. e o

Hacer resolver al sistema un caso de prueba Comparar el sistema con los requisitos establecidos al inicio de la construccion Uso del sistema por parte del usuario segun un escenario y expresion de su opinion Opinion del usuario sobre el criterio no fue capaz de tratar el caso fue capaz de tratar el caso el sistema no cumple los requisitos el sistema cumple los requisitos V minimo? ampliar la respuesta la respuesta no fue exacta fue exacta los conocimientos reformar el sistema seguir con la construccion reformar el sistema o la interface seguir con la construccion ajustar los conocimientos seguir con la construccion
Posibles Valores
Laura Castro
VALOR DE UN CRITERIO? Validez Usabilidad Utilidad Realizacion del trabajo rutinario con el nuevo tandem: usuario + software Comparacion con la situacion anterior a la instalacion del software La nueva situacion es mejor La nueva situacion no es mejor el proyecto ha sido un exito el proyecto no ha sido un exito
Correccion
Inspeccionar y Revisar
el modelo formal o computable en busca del error sintactico establecido
no se se encontraron encontraron errores errores
corregir la sintaxis
seguir con la construccion
PLANO DE LA REALIDAD
PRACTICA REAL ORGANIZACION Sw+Usuario
REALIDAD CONTROLADA Requisitos USUARIO Sw Casos de Prueba
VALIDACION (Completitud y Exactitud) Modelo Formal
VALIDACION (Correspondencia)
Aspectos mas internos del sistema. Aspectos del contexto en un entorno "controlado". Amplia el entorno al usuario. Valora el sistema en el mundo exterior.
Modelo Conceptual
Modelo Computable
VERIFICACION (Redundancia, Incompletitud, Inconsistencia) PLANO DE LA CONSTRUCCION
Figura 7.2: Relacin entre los distintos tipos de evaluacin. o o Ingenier del Conocimiento a
USABILIDAD
UTILIDAD
Verificacion: Validacion: Usabilidad: Utilidad:
81
82
7.1.
7.1.1.
Vericacin y validacin o o
Sistemas de vericacin automtica o a
Todos las pruebas de vericacin de software estndares que existen en ingenier o a a del softwae son aplicables a los SBC y SSEE, aunque son necesarias algunas a mayores. Existen, como hemos mencionado, herramientas que proporcionan vericacin simple o de estructuras, principalmente sintctica. La mayor de los sistemas de vericacin a a o automtica son para sistemas basados en reglas y suelen controlar: a Inconsistencias.- Pueden aparecer por propio error o al trabajar varios ingenieros sobre una misma base de conocimientos. Base Conocimientos + Base Hechos P P atributo(a, x) atributo(a, y) C Redundancias.- Pueden ser o no determinantes (puede haber que eliminarlas o ser correctas/necesarias en nuestro sistema), reduciendo sobre todo la eciencia. Ri ) Rj ) Ri ) Rj ) Rk ) Rr )
Subsuncin.- Si las conclusiones de dos reglas son iguales y las premisas o de las condiciones son una un subconjunto de la regla se dice que hay subsuncin. Es decir, una regla est subsumida en otra si ambas tienen o a la misma conclusin y las premisas de una son un subconjunto de las o premisas de la otra (que es ms general). Igual que en el caso anterior, a pueden querer eliminarse o no, dependiendo del caso. Cadenas circulares.- Son situaciones del tipo: 0 n1 0 1 1 2 ... n
Reglas no disparables.- Si las premisas que tiene una regla nunca son una conclusin de otra ni son hechos iniciales, la regla en cuestin nuno o ca se activar. Con frecuencia es un error debido a que se escribi mal a o esa regla o por falta de conocimiento (ms reglas). a Conclusiones no alcanzables.- Si la conclusin de una regla no es parte o de un antecedente de otra regla (por ejemplo, en encadenamiento regresivo) nunca se llegar a ella. Igual que en el caso anterior (de hecho, a se pueden considerar un tipo especial de reglas no disparables), o bien est mal escrita, o bien falta conocimiento. a Laura Castro
7.1. Vericacin y validacin o o Completitud.- Si la base de conocimientos no est completa puede dara se la situacin en que no hayamos alcanzado ninguna conclusin y o o tampoco quede ninguna regla por ejecutar. Hay cuatro tipos principales de sistemas de vericacin automtica: o a Sistemas de vericacin tabular: se basan en la colocacin de las reglas o o en tablas, agrupndolas por las conclusiones (en una misma la, la a primera columna contiene una conclusin ci y la segunda, las reglas o que concluyen algo sobre ci ), para comprobar posteriormente, dos a dos, la estructura de dichas reglas, pudiendo as detectar redundancias e incluso inconsistencias (si adems de ci tienen en cuenta la negacin a o de ci ). Sistemas de propagacin de restricciones: toman un conjunto de heo chos iniciales e intermedios lo ms completo posible y lo propagan a por el sistema a travz de sus restricciones, comprobando el resultado e (analizando si hay redundancias, etc). Sistemas de vericacin basados en redes de Petri: combierten la base o de conocimientos de reglas en una red de Petri , en la que hiptesis y o conclusiones son nodos y las transiciones representan reglas. Estas reA R1 B G
83
Figura 7.3: Ejemplo de red de Petri. des sirven para comprobar la accesibilidad de las conclusiones, ya que son expresables en forma de sistemas de ecuaciones lineales. Adems, a una vez se dispone del sistema de ecuaciones, si se introduce una inconsistencia y el sistema tiene solucin, signica que el sistema tiene o inconsistencias (est mal); por el contrario, si no la tiene, es que el a sistema es correcto. El peor inconveniente de este tipo de sistemas de vericacin es que o su complejidad es exponencial, aunque a pesar de ello son de los ms a empleados. Sistemas de vericacin basados en grafos dirigidos: a partir de la o base de reglas construyen un grafo dirigido en el que los nodos son los hechos (iniciales, intermedios y conclusiones) y las reglas los arcos, de forma que existir un arco si y slo si existe una regla que ligue ambos a o hechos/nodos. A partir del grafo se calculan las matrices de adyacencia y de la traza de la matriz se analiza si sta indica la existencia de caminos que no e se deber dar, se pueden detectar redundancias, circularidad, etc. a Ingenier del Conocimiento a
84
7.1.2.
Validacin o
En el proceso de validacin es deseable que se involucre un amplio perl de coo laboradores, no slo los ingenieros de conocimiento desarrolladores del sistema, sino o tambin los expertos y uno o varios de los usuarios nales, cuya opinin tambin es e o e importante, casi tanto como la de los propios expertos si son ellos quienes lo van a usar. Como ya se ha mencionado, no slo hay que validar el resultado nal (que, en el o peor de los casos, puede ser espreo), sino si cada paso, paso intermedio, consejo, etc. u que da el sistema lo hace de forma correcta. Tambin es clave que la forma de razonae miento sea la correcta, es decir, que el camino que sigue el sistema para llegar a una conclusin sea el mismo que utiliza el experto (a no ser que est justicado, por ejemplo, o e porque la forma proceder actual sea incorrecta), pues lo hace ms usable. Asimismo es a importante respetar el tipo de lenguaje que se usa, las expresiones, e incluso cuestiones como que si el usuario no entiende algo que le comunica el sistema (por ejemplo, una pregunta), que ste pueda rehacer el mensaje de otra manera. Y, por supuesto, evitar e mensajes de error alarmantes, facilitar la recuperacin de sesiones y asegurar los pasos o que se dan mediante ventanas de conrmacin. o Hay que ser cuidadosos en cmo se realiza la validacin: debe comunicarse al pero o sonal involucrado cunto se estima que va a durar (intervalo temporal realista), la a metodolog y pasos que se debern seguir, as como las expectativas del proceso, evia a tando en la medida de lo posible que se convierta en una tarea tediosa. Referencias estndar de los SBC a El problema de la validacin es que hay que hacerla con respecto a una referencia. o Tanto SBC como SSEE no se dedican a cosas cuyo resultado se conozca siempre perfectamente si es correcto o no, es decir, la necesaria referencia estndar (tambin a e llamada en ocasiones regla de Oro) puede no existir, o bien existir una referencia pero no ser completamente estndar, como sucede si la referencia es el experto o un grupo a de expertos, que pueden no estar de acuerdo y cmo se sabe quin tiene razn? La o e o compensacin que tiene disponer de varios expertos (que deber ser siempre de un o an mismo nivel) es que se puede clasicar el sistema con respecto al tipo de expertos al que se ajusta, siendo, obviamente, preferible que no se ajuste slo a aqul que ms o e a ayud al desarrollo del mismo. o En caso de denir un estndar, debe ser realista, no se puede pretender que el sisa tema vaya ms all de unos determinados niveles. a a Para eliminar sesgos y desviaciones suelen ser utiles los estudios ciegos, en los que los expertos dan su opinin sobre respuestas del propio sistema y otros colegas, sin o identicar de quin provienen, ante un problema. Sea como fuere, en toda validacin e o es necesario efectuar ms de una iteracin. a o Puede suceder que haya en el sistema/contexto/problema variables ms importana tes que otras, que necesitamos con ms urgencia que funcionen bien, lo que puede a establecernos una secuencia de validacin por prioridades, hacia el ajuste no. o
Laura Castro
7.1. Vericacin y validacin o o
85
Otro aspecto clave es mantener los problemas relacionados con la usabilidad al margen de los problemas identicados en la validacin, esto es, relativos a las bases de o conocimiento. Mtodos de validacin e o Existen dos grandes tipos de mtodos de validacin: e o Mtodos cualitativos e Validacin retrospectiva (contra casos histricos). o o Validacin prospectiva (contra casos del d a d o a a). Test de Turing (validaciones annimas en varias iteraciones). o Validacin de subsistemas semiindependientes. o
Mtodos cuantitativos (fundamentalmente mtodos estad e e sticos) Tanto por ciento de acuerdo. Indice kappa.
Apndice A e Ampliaciones
En este apndice se reproducen algunas de las guras que intercalan el texto de los e cap tulos de estos apuntes, en un mayor nivel de detalle.
A.1.
Figuras
Detalle de la gura 1.1 (pgina 4): a
87
88
Apuntes A. Ampliaciones
BASE DE CONOCIMIENTOS
DECLARATIVOS
Conocimientos del dominio Objetos y relaciones Definiciones del vocabulario Hechos disyuntivos y/o inciertos Situaciones tipicas: estadisticas y descripciones de la dinamica del comportamiento Suposiciones Hipotesis Restricciones Taxonomias
MOTOR DE INFERENCIAS
Encadenamiento adelante/atras Unificacion, equiparacion Propagacion de restricciones Gestion de prioridades Agenda Pizarra Razonamiento hipotetico Resolucion Induccion Demonios Metacontrol Gestion de incertidumbre Calculos matematicos
OPERATIVOS o DE ACCION
Procesos de solucion Reglas operativas Heuristicas Ejemplos de soluciones
METACONOCIMIENTOS
Semantica situacional Razonamiento de sentido comun Metarreglas Aprendizaje Tareas genericas de solucion de problemas Clasificacon y construccion de hipotesis y planes de solucion de problemas precompilados
Explicacion y consejos
Hechos y datos especificos
INTERFAZ DE COMUNICACION, EXPLICACION Y ADQUISICION DE CONOCIMIENTO

SUBSISTEMA DE USUARIO
Menus Graficos
SUBSISTEMA DE EXPLICACION
Como? Por que? Que sucede si...?
SUBSISTEMA DE ADQUISICION DEL CONOCIMIENTO

Procesado de palabras Entrada en linea Ayuda Herramientas de depuracion de la BC Librerias de casos y ejemplos Animacion Control de la inferencia
Usuario
Ingenieria del Conocimiento
Figura A.1: Esquema detallado de un SBC.
Laura Castro
Indice de cuadros
1.1. Diferencias entre dato, informacin y conocimiento . . . . . . . . . . . o 4.1. 4.2. 4.3. 4.4. 6.1. 6.2. 6.3. 6.4. 6.5. 6.6. 6.7. Nombres estndar de las Funciones de Transferencia. a Tareas Anal ticas vs. Tareas Sintticas. . . . . . . . . e Tipos de comunicacin. . . . . . . . . . . . . . . . . . o Semntica de algunos tipos de comunicacin. . . . . . a o Declogo del Ingeniero de Conocimiento. . . . a Mtodos de Adquisicin del Conocimiento. . . e o Clasicacin de los Mtodos de Adquisicin de o e o Ejemplo de aplicacin de EDM. . . . . . . . . o Ejemplo de clustering (I). . . . . . . . . . . . Ejemplo de redes ponderadas. . . . . . . . . . Esquema de una parrilla. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 25 30 37 38 55 56 57 64 66 68 70
. . . . . . . . . . . . . . . . . . Conocimiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
Indice de guras
1.1. Esquema de un SBC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1. 2.2. 2.3. 2.4. IS vs. IC. . . . . . . . . . . . . . . . . . . . . . . . . Esquema de la metodolog de desarrollo incremental. a Esquema de la metodolog en cascada. . . . . . . . . a Niveles de la metodolog CommonKADS. . . . . . . a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6 8 11 11 16 19 20 21 22 23 24 24 26 27 28 30 34 35 37 37 41 43 44 52 52 53 53 67 80 81
3.1. Modelo de la Organizacin. . . . . . . . . . . . . . . . . . . . . . . . . o 4.1. Categor en el modelo del Conocimiento. . . . . . . . . as 4.2. Constructos del modelo del Conocimiento. . . . . . . . . 4.3. Relaciones en el modelo del Conocimiento. . . . . . . . . 4.4. Ejemplos de representacin de Tipos de Regla. . . . . . . o 4.5. Ejemplo de representacin de Base de Conocimientos. . . o 4.6. Elementos del Conocimiento Inferencial. . . . . . . . . . 4.7. Ejemplo de Inferencia. . . . . . . . . . . . . . . . . . . . 4.8. Ejemplo de Mapa Inferencial. . . . . . . . . . . . . . . . 4.9. Elementos del Conocimiento de la Tarea. . . . . . . . . . 4.10. Ejemplo de esquema de un posible Mtodo de la Tarea. . e 4.11. Gu para el modelado del Conocimiento. . . . . . . . . . a 4.12. Relacin del modelo de Comunicacin con otros modelos. o o 4.13. Estructura del modelo de Comunicacin. . . . . . . . . . o 4.14. Estructura general de un Diagrama de Dilogo. . . . . . a 4.15. Esquema de la estructura de una transaccin (CM-1). . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1. Del anlisis al diseo en CommonKADS. . . . . . . . . . . . . . . . . . a n 5.2. Pasos en la construccin del modelo de Diseo. . . . . . . . . . . . . . . o n 5.3. Esquema del Model View Controller. . . . . . . . . . . . . . . . . . . . 6.1. 6.2. 6.3. 6.4. 6.5. Primer escenario de adquisicin del conocimiento. . o Segundo escenario de adquisicin del conocimiento. o Tercer escenario de adquisicin del conocimiento. . o Cuarto escenario de adquisicin del conocimiento. . o Ejemplo de clustering (y II): dendrograma. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1. Tcnicas de valoracin para SS.EE. . . . . . . . . . . . . . . . . . . . . e o 7.2. Relacin entre los distintos tipos de evaluacin. . . . . . . . . . . . . . o o 91
92
Apuntes A. Ampliaciones 7.3. Ejemplo de red de Petri. . . . . . . . . . . . . . . . . . . . . . . . . . . A.1. Esquema detallado de un SBC. . . . . . . . . . . . . . . . . . . . . . . 83 88
Laura Castro
Bibliograf a
[1] Alonso Betanzos, Amparo. Apuntes de clase. [2] Vicente Moret, Amparo Alonso, et al. Fundamentos de Inteligencia Articial. Servicio de Publicaciones de la Universidad de La Corua, 2000. n
93
Indice alfabtico e
conocimiento, 1 adquisicin, 51 o anlisis de protocolos, 59 a brainstorming, 77 clustering, 65 constructos personalizados, 69 cuestionarios, 61 curvas cerradas, 62 entrevistas, 56 escalamiento multidimensional, 63 escalamiento psicolgico, 62 o escenarios, 51 mtodo delphi, 77 e movimiento de ojos, 61 observacin directa, 62 o redes ponderadas, 68 tcnica nominal, 77 e tcnicas especiales, 77 e categor 18 as, de la tarea, 26 del dominio, 20 especicacin, 31 o identicacin, 31 o inferencial, 23 ingenier del, 2 a pblico, 2 u privado, 2 renamiento, 33 semipblico, 2 u sistema basado en, 3 constructos, 20 dato, 1 dendrograma, 65 EDM, 63 emparrillado, 69 entrevistas 94 de adquisicin, 56 o de despliegue, 56 estructuradas, 56 no estructuradas, 56 experto acadmico, 51 e prctico, 51 a terico, 51 o informacin, 1 o metodolog a CommonKADS, 10 desarrollo incremental, 8 en cascada, 8 en espiral, 8 prototipado rpido, 7 a modelo de agentes, 12, 16 de comunicacin, 12, 34 o de conocimiento, 12, 17 construccin, 30 o documentacin, 34 o plantillas, 29 validacin, 33 o de diseo, 12, 41 n de organizacin, 10, 15 o de tareas, 12, 16 nivel de concepto, 12 de contexto, 13 de implementacin, 12 o nivel de contexto, 10 pathnder, 68 Petri red de, 83 plan de comunicacin, 36 o
referencia estndar, 84 a reglas cadenas circulares, 82 completitud, 83 conclusiones no alcanzables, 82 inconsistencia, 82 no disparables, 82 redundancia, 82 subsuncin, 82 o SBC, 3 evaluacin, 79 o software ingenier del, 2 a tr adas, 71 transaccin, 36 o usabilidad, 79 utilidad, 79 validacin, 79, 84 o vericacin, 79 o
95

Ingenier Ia Del Conocimiento: Departamento de Computaci On

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ingenier Ia Del Conocimiento: Departamento de Computaci On

Cargado por

Copyright:

Formatos disponibles

Ingenier del Conocimiento a

Laura M. Castro Souto Amparo Alonso Betanzos Bertha Guijarro Berdias n

Ingenier del Conocimiento a

Cap tulo 1 La Ingenier del Conocimiento a

Datos Informacin o Conocimiento

Caracter stica Sin interpretar Aade signicado n Propsito y capacidad o de generacin o

Ejemplo ...-... S.O.S. Alerta, emergencia, comenzar un rescate

Apuntes 1. La Ingenier del Conocimiento a

La ingenier del conocimiento a

En adelante, IC. En adelante, IS.

1.3. Los sistemas basados en el conocimiento

Los sistemas basados en el conocimiento

A partir de ahora, SBC.

Ingenier del Conocimiento a

Apuntes 1. La Ingenier del Conocimiento a

BASE de CONOCIMIENTOS Declarativos Operativos o de Accion Metaconocimiento

hechos y datos especificos

INTERFAZ DE COMUNICACION, EXPLICACION Y ADQUISICION DE CONOCIMIENTO

SUBSISTEMA DE ADQUISICION DE CONOCIMIENTO

Figura 1.1: Esquema de un SBC.

Cap tulo 2 Metodolog para la construccin as o de SSBBC

Apuntes 2. Metodolog para la construccin de SSBBC as o

PROBLEMA PROBLEMA DOMINIO DE APLICACION

ADQUISICION DE CONOCIMIENTO CONSTRUCCION BC

CODIFICACION Y COMPROBACION DE CADA MODULO

COMPROBACION Y EVALUACION ENSAMBLADO DE MODULOS Y COMPROBACION DEL SISTEMA GLOBAL

CONSTRUCCION DEL SISTEMA META

SISTEMA SOFTWARE TRADICIONAL

SISTEMA BASADO EN CONOCIMIENTO

Figura 2.1: IS vs. IC.

2.2. Metodolog adaptadas de la IS as

Metodolog de prototipado rpido a a

Apuntes 2. Metodolog para la construccin de SSBBC as o

Metodolog de desarrollo incremental as

Ajustes del diseo

Implementacion Prototipo inicial

Evaluacion Mantenimiento Diseo inicial

2.2. Metodolog adaptadas de la IS as

Apuntes 2. Metodolog para la construccin de SSBBC as o

Nivel de Contexto: Por qu? e

2.3. Metodolog CommonKADS a

Analisis del sistema

Figura 2.3: Esquema de la metodolog en cascada. a

Modelo de Conocimiento requisitos funcionalidades

Modelo de Comunicacion requisitos sobre interacciones

Figura 2.4: Niveles de la metodolog CommonKADS. a

Ingenier del Conocimiento a

Nivel de Concepto: Qu? e

Nivel de Implementacin: Cmo? o o

Cap tulo 3 Anlisis de viabilidad e impacto: a modelado del contexto en CommonKADS

El Proceso de Modelado del Contexto

Los pasos a seguir son:

Veremos ahora cmo analizar una organizacin intensiva en conocimiento: o o

Apuntes 3. Modelado del contexto en CommonKADS

OM5 OM1 OM2 OM3 OM4

Descripcion del area elegida

Estructura Procesos Personal Cultura y potencial Recursos Conocimiento

Descripcion a traves de activos de conocimiento

El modelo de las Tareas

El modelo de los Agentes

Cap tulo 4 Descripcin conceptual del o conocimiento en CommonKADS

En este cap tulo nos centraremos en el modelado del Conocimiento.

El modelo del Conocimiento