Ec.pdf

Ingenier´ del Conocimiento
ıa

Departamento de Computaci´n
o
Curso 2002-2003

Alumna: Laura M. Castro Souto
Profesoras: Amparo Alonso Betanzos
Bertha Guijarro Berdi˜as
n

´
Indice general

1. La Ingenier´ del Conocimiento
ıa 1
1.1. El conocimiento y su contexto . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. La ingenier´ del conocimiento . . . . . . . . . . . . . . . . . . . . . . .
ıa 2
1.3. Los sistemas basados en el conocimiento . . . . . . . . . . . . . . . . . 3

2. Metodolog´ para la construcciń de SSBBC
ıas o 5
2.1. Diferencias entre la IS y la IC . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Metodolog´ adaptadas de la IS . . . . . . . .
ıas . . . . . . . . . . . . . . 7
2.2.1. Metodolog´ de prototipado r´pido . .
ıa a . . . . . . . . . . . . . . 7
2.2.2. Metodolog´ de desarrollo incremental
ıas . . . . . . . . . . . . . . 8
2.2.3. Metodolog´ en cascada . . . . . . . .
ıas . . . . . . . . . . . . . . 8
2.2.4. Metodolog´ en espiral . . . . . . . . .
ıas . . . . . . . . . . . . . . 8
2.3. Metodolog´ CommonKADS . . . . . . . . . .
ıa . . . . . . . . . . . . . . 10
2.3.1. Nivel de Contexto: ¿Por qu´? . . . . .
e . . . . . . . . . . . . . . 10
2.3.2. Nivel de Concepto: ¿Qu´? . . . . . . .
e . . . . . . . . . . . . . . 12
2.3.3. Nivel de Implementaciń: ¿C´mo? . . .
o o . . . . . . . . . . . . . . 12

3. Modelado del contexto en CommonKADS 13
3.1. El Proceso de Modelado del Contexto . . . . . . . . . . . . . . . . . . . 14
3.1.1. El modelo de Organizaciń . . . . .
o . . . . . . . . . . . . . . . . 15
3.1.2. El modelo de las Tareas . . . . . . . . . . . . . . . . . . . . . . 16
3.1.3. El modelo de los Agentes . . . . . . . . . . . . . . . . . . . . . . 16

4. Descripciń conceptual del conocimiento en CommonKADS
o 17
4.1. El modelo del Conocimiento . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1. Conocimiento del dominio . . . . . . . . . . . . . . . . . . . . . 20
4.1.2. Conocimiento inferencial . . . . . . . . . . . . . . . . . . . . . . 23
4.1.3. Conocimiento de la tarea . . . . . . . . . . . . . . . . . . . . . . 26
4.1.4. ¿Inferencia o Tarea? . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.5. Modelo de Datos (IS) vs. Modelo de Conocimiento (IC) . . . . . 28
4.2. Plantillas de modelos de Conocimiento. Elementos reutilizables . . . . . 29
4.2.1. Tipos de Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3. Construcciń de los modelos de Conocimiento . . . . . . . . . .
o . . . . 30
4.3.1. Identificaciń del Conocimiento . . . . . . . . . . . . . .
o . . . . 31
4.3.2. Especificaciń del Conocimiento . . . . . . . . . . . . . .
o . . . . 31

i

ii

4.3.3. Refinado del Conocimiento . . . . . . . . . . . . . . . . . . . . . 33
4.3.4. Documentaciń del modelo de Conocimiento
o . . . . . . . . . . . 34
4.4. El modelo de Comunicaciń . . . . . . . . . . . . .
o . . . . . . . . . . . 34
4.4.1. Plan de Comunicaciń . . . . . . . . . . . .
o . . . . . . . . . . . 36
4.4.2. Transaciones agente-agente . . . . . . . . . . . . . . . . . . . . . 36
4.4.3. Patrones transaccionales . . . . . . . . . . . . . . . . . . . . . . 38
4.4.4. Tćnicas de validaciń . . . . . . . . . . . .
e o . . . . . . . . . . . 39

5. El modelo de Dise˜ o en CommonKADS
n 41
5.1. Principio de Conservaciń de la Estructura . . . . . . . . . . . . . . . .
o 42
5.2. El modelo de Diseõ . . . . . . . . . . . . . . . . . . . . . . . . . . . .
n 42
5.2.1. Diseõ de la arquitectura del sistema . . . . . . . . . . . . . . .
n 43
5.2.2. Identificaciń de la plataforma de implementaciń . . . . . . . .
o o 45
5.2.3. Especificaciń de los componentes de la arquitectura . . . . . .
o 46
5.2.4. Especificaciń de la aplicaciń en el contexto de la arquitectura
o o 48
5.3. Diseõ de prototipos . . . . . . . . . . . . . . . . . . . . . . . . . . . .
n 48
5.3.1. Prototipado de subsistemas de razonamiento . . . . . . . . . . . 48
5.3.2. Prototipado de interfaces de usuario . . . . . . . . . . . . . . . . 49
5.4. SBCs distribuidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6. Tćnicas para la adquisiciń del conocimiento
e o 51
6.1. Escenarios de adquisiciń del conocimiento . . . . . . . . . .
o . . . . . . 51
6.2. Las entrevistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2.1. Entrevistas m´ltiples . . . . . . . . . . . . . . . . . .
u . . . . . . 58
6.3. El an´lisis de protocolos . . . . . . . . . . . . . . . . . . . .
a . . . . . . 59
6.4. Cuestionarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.5. An´lisis del movimiento de ojos . . . . . . . . . . . . . . . .
a . . . . . . 61
6.6. M´todo de observaciń directa . . . . . . . . . . . . . . . . .
e o . . . . . . 62
6.7. Extracciń de curvas cerradas . . . . . . . . . . . . . . . . .
o . . . . . . 62
6.8. Las tćnicas de escalamiento psicol´gico . . . . . . . . . . .
e o . . . . . . 62
6.8.1. Escalamiento multidimensional (EDM ) . . . . . . . . . . . . . . 63
6.8.2. An´lisis de clusters (Clustering) . . . . . . . . . . . .
a . . . . . . 65
6.8.3. Redes ponderadas (Pathfinder ) . . . . . . . . . . . . . . . . . . 68
6.9. La teor´ de constructos personalizados: el Emparrillado . .
ıa . . . . . . 69
6.9.1. Identificaciń de elementos Ei . . . . . . . . . . . . .
o . . . . . . 70
6.9.2. Identificaciń de caracter´
o ısticas cj . . . . . . . . . . . . . . . . . 71
6.9.3. Diseõ de la parrilla . . . . . . . . . . . . . . . . . .
n . . . . . . 71
6.9.4. Formalizaciń . . . . . . . . . . . . . . . . . . . . . .
o . . . . . . 72
6.9.5. An´lisis y estudio de los resultados obtenidos . . . .
a . . . . . . 74
6.10. Tćnicas especiales de adquisiciń de conocimiento en grupo
e o . . . . . . 77
6.10.1. Tormenta de ideas (Brainstorming) . . . . . . . . . . . . . . . . 77
6.10.2. Tćnica nominal de grupo . . . . . . . . . . . . . . .
e . . . . . . 77
6.10.3. M´todo Delphi . . . . . . . . . . . . . . . . . . . . .
e . . . . . . 77

Laura Castro

iii

7. Evaluaciń de los sistemas basados en conocimiento
o 79
7.1. Verificaciń y validaciń . . . . . . . . . . . . . . . . . . . . . . . . . .
o o 82
7.1.1. Sistemas de verificaciń autom´tica . . . . . . . . . . . . . . . .
o a 82
7.1.2. Validaciń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 84

Apńdices
e 86

A. Ampliaciones 87
A.1. Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Bibliograf´
ıa 93

ıa

Cap´
ıtulo 1

La Ingenier´ del Conocimiento
ıa

En este primer tema estableceremos algunos conceptos b´sicos 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 distin-
e ıcil
guir claramente que no es lo mismo que un dato ni tampoco es el mismo concepto que
el de informaciń.
o
Podemos decir que:

Dato Conjunto de seãles, s´
n ımbolos, signos, que llegan a nuestros sentidos,
sin que tengan que tener significado propio.
Informaciń Datos que se agrupan y adquieren un significado que no va
o
impl´
ıcito en ellos, sino que se aprende a manejar.
Conocimiento Conjunto de datos e informaciń que adem´s tiene senti-
o a
do del prop´sito (sirve para algo) y capacidad de generar nuevo
o
conocimiento e informaciń (e incluso acciones).
o

Caracter´
ıstica Ejemplo
Datos Sin interpretar ...-...
Informaciń
o Aãde significado
n S.O.S.
Conocimiento Prop´sito y capacidad
o Alerta, emergencia,
de generaciń
o comenzar un rescate

Cuadro 1.1: Diferencias entre dato, informaciń y conocimiento
o

La definiciń de lo que es conocimiento se hace m´s dif´ ań si consideramos
o a ıcil u
que puede depender del contexto. Obviamente, un f´
ısico y un ajedrecista no tendrń la
a
misma concepciń de lo que es conocimiento referente a sus respectivas actividades.
o

1

2 Apuntes – 1. La Ingenier´ del Conocimiento
ıa

En el caso de la Ingenier´ del Conocimiento1 , esta situaciń se agrava, puesto que
ıa o
su aplicaciń 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 define el conocimiento como “informaciń sobre la informaciń”, puesto
o o
que hay que tener cierta informaciń sobre la informaciń que se va a manejar para
o o
poder usarla adecuadamente.
La representaciń expl´
o ıcita del conocimiento es clave para distinguir entre sistemas
software cl´sicos 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 relaciń 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), comńmente aceptado y univer-
u
salmente reconocido.
Conocimiento semip´ blico, expl´
u ıcito pero no universalmente reco-
nocido ni comńmente aceptado, utilizado casi de forma exclusiva por
u
los especialistas del ´rea concreta.
a
Conocimiento privado, no expl´ ıcito, no universalmente reconocido
ni comńmente aceptado, de marcado carćter heur´
u a ıstico, end´geno
o
de cada uno, fruto de la propia experiencia.

Un sistema de conocimiento pretende familiarizarse con el conocimiento p´blico,
u
implementar el semip´blico y extraer el privado.
u

1.2. La ingenier´ del conocimiento
ıa
Denominamos ingenierá del conocimiento al conjunto de conocimientos y tćnicas
ı e
que permiten aplicar el saber cient´
ıfico a la utilizaciń del conocimiento, entendiendo
o
“conocimiento” como inteligencia o razń natural.
o

Partiendo de la siguiente definiciń de ingenier´ del software 2 (IEEE-99):
o ıa

La IS es la aplicaciń de una aproximaciń sistem´tica, disciplinada y cuan-
o o a
tificable, al desarrollo, funcionamiento y mantenimiento del software (apli-
caciones)

podemos adaptarla a la IC y decir, asimismo, que la IC es la aplicaciń de una
o
aproximaciń sistem´tica, disciplinada y cuantificable, al desarrollo, funcionamiento y
o a
mantenimiento del conocimiento (en aplicaciones, software).
1
En adelante, IC.
2
En adelante, IS.

Laura Castro

1.3. Los sistemas basados en el conocimiento 3

Es por ello que muchas de las metodolog´ utilizadas en el campo de la IS se han
ıas
adaptado a la IC, y que tambiń muchos de los problemas que aparecen en una se
e
reproducen en la otra tambiń. La mayor´ de ellos, como veremos en el tema corres-
e ıa
pondiente, se deben con frecuencia a la especificaciń d´bil de requisitos, a la presencia
o e
de entradas inconsistentes, etc. que dan lugar a diseõs no limpios.
n

Resumiendo, podemos definir la ingenierá del conocimiento como el conjunto de
ı
principios, m´todos, tćnicas y herramientas que permiten la construcciń 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 (soft-
ware) que utiliza y representa expl´
ıcitamente conocimiento sobre un dominio con-
creto para realizar una tarea que requerir´ un experto (de ser realizada por un hu-
ıa
mano), es decir, que es capaz de exportar ese conocimiento a trav´s de los mecanismos
e
apropiados de razonamiento para proporcionar un comportamiento de alto nivel en la
resoluciń de problemas en ese dominio (Guida & Tasso).
o

Las dos caracter´
ısticas clave, tal y como se ha seãlado, son:
n

la representaciń 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 rob´tica, los sistemas conexionis-
o
tas, los sistemas expertos,. . . Estos ultimos fueron uno de los logros m´s importantes,
´ a
porque fueron los primeros en enfrentarse a problemas reales utilizando conocimiento
espec´ıfico de pequeõs dominios. No obstante, en los aõs 60 se produjo un retroceso
n n
en su desarrollo debido al aumento de la complejidad de los problemas que se pretend´ ıa
abordar. Aõs m´s tarde, surgir´ la IC.
n a ıa

Los beneficios m´s 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.

ıa

4 Apuntes – 1. La Ingenier´ del Conocimiento
ıa

Hay varios conceptos que ayudan a distinguir los SBC de software m´s convencional
a
y tambiń de programas de inteligencia artificial:
e
√
La naturaleza m´s bien heur´
a ıstica del conocimiento que contienen (IA,
aõs 50-60).
n
√
La naturaleza altamente espec´
ıfica del conocimiento (Dendral, 1970).
√
La separaciń del conocimiento de c´mo se usa —control— (General
o o
Problem Solver de McCarthy, 1963; Mycin, 1976).

BASE de CONOCIMIENTOS Memoria Activa

−Declarativos
MOTOR DE
−Operativos o de Accion
INFERENCIAS
−Metaconocimiento

explicaciones hechos y datos
y consejos especificos

INTERFAZ DE COMUNICACION, EXPLICACION Y
ADQUISICION DE CONOCIMIENTO

SUBSISTEMA SUBSISTEMA DE SUBSISTEMA DE ADQUISICION
DE USUARIO EXPLICACION DE CONOCIMIENTO

Ingeniero de
Usuario
Conocimiento

Figura 1.1: Esquema de un SBC.

Laura Castro

Cap´
ıtulo 2

Metodolog´ para la construcciń
ıas o
de SSBBC

El ingeniero de conocimiento debe:
√
elicitar
√
estructurar
√
formalizar
√
operacionalizar
toda la informaciń y el conocimiento que estń relacionados con el dominio. Esta
o e ´
no es una tarea trivial, porque el conocimiento no es algo que se pueda observar, la
informaciń 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.
Adem´s, el conocimiento no es s´lo algo dif´ de extraer, sino tambiń un recurso
a o ıcil e
caro; por ello en los ultimos tiempos ha surgido la idea de reutilizaciń 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 con-
ıa
frontaciń, pues la IS no incluye a los sistemas de IC, ´sta desarrolla su software en
o e
problemas mal estructurados o mal definidos 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 an´lisis exhaustivo de la organizaciń donde vamos a
a a o
aplicar nuestro modelo.
Las especificaciones de requisitos en IS son completas antes de empezar; en IC esto
es casi imposible.
En IC es muy importante la adquisiciń del conocimiento, que adem´s 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

6 Apuntes – 2. Metodolog´ para la construcci´n de SSBBC
ıas o

PROBLEMA
PROBLEMA DOMINIO DE APLICACION

ANALISIS DEL PROBLEMA
Y DEL DOMINIO

METODOS DE SOLUCION CONOCIMIENTO DEL DOMINIO
E S P ECI F I CACIONES

MODELADO DE
DISEÑO DE LA CONOCIMIENTO
ARQUITECTURA (o desarrollo del sistema vacio)

DISEÑO MODULAR ADQUISICION DE
CONOCIMIENTO
CONSTRUCCION BC

CODIFICACION Y
COMPROBACION DE PROTOTIPO
CADA MODULO

COMPROBACION
Y EVALUACION
ENSAMBLADO DE
MODULOS Y
COMPROBACION
DEL SISTEMA GLOBAL CONSTRUCCION DEL
SISTEMA META

SISTEMA SOFTWARE SISTEMA BASADO
TRADICIONAL EN CONOCIMIENTO

Figura 2.1: IS vs. IC.

Laura Castro

2.2. Metodolog´ adaptadas de la IS
ıas 7

En IC no se trabaja con lenguajes, sino con herramientas, ya que se ha conseguido
que el control, el manejo del conocimiento sea gen´rico (i.e. motores de inferencias).
e

ıas
En esta secciń revisaremos superficialmente algunas de las metodolog´ que la IC
o ıas
ha “heredado” de la IS.

2.2.1. Metodolog´ de prototipado r´pido
ıa a
Esta metodolog´ consiste en adquirir conocimientos y codificar hasta considerar
ıa
que tenemos un modelo lo suficientemente 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 dem´s poste-
a
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 r´pido para mostrar al experto,
a
que se ir´ refinando y ampliando.
a
Las ventajas de esta metodolog´ residen en que la rapidez en el desarrollo de
ıa
una primera versiń del sistema motiva al experto (pronto se ve algo operativo), y
o
adem´s ayuda a centrar el desarrollo del conocimiento adem´s de no requerir demasiada
a a
experiencia. No obstante, desde el punto de vista de la IC son m´s importantes las
a
desventajas que se presentan:

dificulta la recogida de requisitos
se sustituye el estudio de especificaciones y el diseõ por la codificaciń
n o
r´pida, lo que origina debilidades
a
el crecimiento incontrolado complica la BC
las interacciones no contempladas entre distintas partes o m´dulos del
o
sistema son fuente de muchos problemas, el modelo crece distorsionado
el c´digo resulta generalmente muy poco y mal estructurado
o
no se produce un an´lisis completo de requisitos
a
no hay una buena documentaciń (o ´sta es nula)
o e
el mantenimiento es prćticamente imposible
a

Esta metodolog´ descuida todo lo que no tiene que ver directamente con el core
ıa
del conocimiento (desarrollo de una IU, comunicaciń con otro software,. . . ), con todo
o
lo que ello conlleva.

ıa

ıas o

2.2.2. Metodolog´ de desarrollo incremental
ıas
Ante el desbordamiento de la metodolog´ de prototipado r´pido, 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 diseño

Diseño prototipos codificacion inicial
Implementacion

Prototipo inicial
Prueba (V&V)

Evaluacion
Mantenimiento

Diseño inicial

Figura 2.2: Esquema de la metodolog´ de desarrollo incremental.
ıa

Aunque por incremental es m´s ordenada (manteniendo a la par algunas de las
a
ventajas del prototipado r´pido, como la pronta obtenciń de un sistema y una buena
a o
comunicaciń con los expertos), esta metodolog´ gira, no obstante, en torno a la imple-
o ıa
mentaciń y aunque logr´ organizar un poco m´s los sistemas, no centraba tampoco la
o o a
atenciń en la captura de requisitos y especificaciones, que ser´ m´s 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
Tambiń adaptada de la IS, esta metodolog´ trata de ajustar el alcance de la itera-
e ıa
ciń de desarrollo, que resultaba problem´tico en el caso anterior (ver figura 2.3, p´gina
o a a
11).

A pesar de conseguir reducir los errores al analizar m´s 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
an´lisis de riesgos, adem´s 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
m´ltiples cuestiones: los prototipos sucesivos se van refinando y ampliando, se pueden
u
aãdir especificaciones en cada vuelta hasta llegar a concretar finalmente el elemento
n

Laura Castro

ıas 9

de test. Permite situar el mantenimiento en un nivel adecuado gracias al mencionado
an´lisis de riesgos. Cada fase ayuda a completar la anterior, en lugar de s´lo sumar,
a o
que era m´s 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 m´s grandes. No obstante, ań quedaban dos cuestiones por solucionar:
a u

∗ la adquisiciń del conocimiento segu´ siendo el cuello de botella
o ıa
∗ la capacidad de explicaciń no estaba realmente presente, ya que co-
o
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 m´s adecuada, al
ıa a
fin 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, tratńdolo sin darle un nivel espec´
a ıfico como es imperativo.
Como consecuencia de estos problemas, los SBC eran por aãdidura muy dif´
n ıciles de
mantener, con fases de validaciń muy extensas.
o
Fue primero Newell el que dio la voz de alarma indicando la necesidad de tratar
el conocimiento como algo especial, reflexionando sobre lo que hay que representar y
c´mo se quiere hacerlo, y posteriormente McDermott con su teor´ sobre las “Tareas
o ıa
gen´ricas” segń la que la adquisiciń del conocimiento sigue siempre unos pasos repe-
e 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-diferenciaciń de lo que
o
es conocimiento de la representaciń del mismo. La soluciń pasa por aãdir el Nivel
o o n
de Conocimiento, que est´ por encima del nivel simb´lico. 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 actá es el conocimiento: el agente toma el conocimiento, lo
u
procesa y realiza acciones para conseguir objetivos. Esto permiti´ tambiń abordar las
o e
primeras ideas sobre reutilizaciń del conocimiento: abstraer las tareas gen´ricas para
o e
volver a utilizarlas en sistemas similares.
Una metodolog´ que usa el nivel de conocimiento es KLIC (KBS Life Cycle).
ıa

ıa

ıas o

McDermott. M´todos de limitaciń de roles
e o
Los estudios de McDermott constituyeron los primeros intentos para reutilizar el
m´todo de resoluciń 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 codificado 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 m´todos de resoluciń de problemas,
e o
diferencińdolos de la base de conocimientos. Como conclusiń, extrajo que hay familias
a o
de tareas que se pueden resolver por m´todos cuyo conocimiento de control es abstracto
e
y se puede aplicar a distintas instanciaciones de esa tarea. Adem´s, permite definir
a
en qu´ orden hay que adquirir el conocimiento y tambiń c´mo se implementa (al
e e o
ordenarlo, disminu´ ımos la entrop´ y es m´s fćil implementarlo).
ıa a a

2.3. Metodolog´ CommonKADS
ıa
La metodolog´ CommonKADS (Knowledge Analysis and Documentation Sys-
ıa
tem) es una variaciń de la metodolog´ en espiral de la IC, desarrollada en Europa
o ıa
en torno a 1983. Surge de su predecesora, KADS, al serle aãdido un lenguaje de mo-
n
delado conceptual (CML, Conceptual Modell Language), muy parecido a UML, y que
facilita el diseõ del sistema.
n

La metodolog´ CommonKADS es, pues, una metodolog´ estructurada que cubre
ıa ıa
la gestiń del proyecto, el an´lisis de la organizaciń, la ingenier´ del conocimiento y
o a o ıa
del software. Plasma tres de las ideas m´s utilizadas en IS e IC (modelado, reutilizaciń
a o
y gestiń del riesgo) y, siendo la unica que utiliza Orientaciń a Objetos, se organiza
o ´ o
tal y como se puede observar en la figura 2.4 (p´gina 11).
a

Esta divisiń en niveles y modelos permite su desarrollo sin que unos sean inter-
o
dependientes de otros, es decir, permite un gran nivel de desacoplamiento. El conoci-
miento 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 beneficios, el impacto, la utilidad que tendr´ el
a
SBC que se pretende construir, su viabilidad, etc.

Modelo de Organizaciń Estudia qu´ ´reas de la organizaciń son m´s
o ea o a
susceptibles de sacar provecho de un SBC. Es un estudio profundo de
la organizaciń, del impacto y posibles resultados de la implantaciń
o o
del SBC, espectativas, predisposiciń,. . .
o
Modelo de Tareas Ubicadas las tareas m´s importantes, es el momento
a
de intentar descomponer el/los sistemas en “primitivas” con el fin de

Laura Castro

2.3. Metodolog´ CommonKADS
ıa 11

Analisis del sistema

Especificaciones de requisitos

Diseño

Codificacion

Prueba

Mantenimiento

Figura 2.3: Esquema de la metodolog´ en cascada.
ıa

Modelo de la Modelo de Modelo de
Contexto Organizacion Tareas Agentes

Modelo de Modelo de
Concepto Conocimiento Comunicacion

requisitos requisitos sobre
funcionalidades interacciones
Modelo de
Implementacion Diseño

Figura 2.4: Niveles de la metodolog´ CommonKADS.
ıa

ıa

ıas o

poder abordarlas m´s fćilmente, identificar 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
organizaciń (ya sean personas f´
o ısicas, sistemas de informaciń, etc.).
o
Se analiza en este modelo qu´ normas se les aplican, plantillas, funcio-
e
nes,. . .

2.3.2. Nivel de Concepto: ¿Qu´?
e
Los modelos de este nivel conforman una descripciń conceptual del conocimiento.
o

Modelo de Conocimiento Explica en detalle qu´ tipos de conocimiento
e
e informaciń tenemos involucrados (naturaleza y estructura). Da una
o
visiń de la estructura del conocimiento independiente de la imple-
o
mentaciń.
o
Modelo de Comunicaciń Disecciona c´mo es la comunicaciń entre agen-
o o o
tes involucrados (conceptualmente).

2.3.3. Nivel de Implementaciń: ¿C´mo?
o o
Este nivel se centra en la manera de llevar a cabo, de realizar de manera concreta, el
sistema: mecanismos computacionales, arquitectura, representaciń del conocimiento
o
m´s adecuada, etc.
a

Modelo de Dise˜ o Usando fundamentalmente el Modelo de Conocimien-
n
to y el Modelo de Comunicaciń, se intentan obtener los requisitos y
o
restricciones prćticas del sistema.
a

Laura Castro

Cap´
ıtulo 3

An´lisis de viabilidad e impacto:
a
modelado del contexto en
CommonKADS

El conocimiento siempre funciona dentro de una organizaciń. En este cap´
o ıtulo,
entre otras cosas, veremos:
√
Por qu´ es necesario modelar el contexto
e
√
El papel de los modelos: Organizaciń, Tareas y Agentes
o
√
Pasos y tćnicas en el an´lisis del conocimiento orientado a las empre-
e a
sas y las instituciones
√
Casos de ejemplo

Razones del modelado del contexto
A menudo es dif´ identificar 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 s´lo puede funcionar de forma adecuada si est´ propia-
o a
mente integrado a largo plazo en la organizaciń en la que trabaja.
o
Un SBC actá como un agente que coopera con otros, humanos o no,
u
y lleva a cabo una fracciń de las tareas de la organizaciń.
o o
Un SBC es una herramienta de apoyo dentro del proceso general de la
organizaciń, al igual que cualquier sistema de informaciń, 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:

Identificar qu´ cuestiones suponen problemas y cu´les no.
e a
Decidir soluciones y su viabilidad.
Mejorar las tareas y el conocimiento relativo a ´stas.
e
Planificar la necesidad de cambios en la organizaciń.
o

El papel de los SBC se rige por una serie de directrices:

◦ Normalmente los SBCs encajan mejor en proyectos de mejora de la
organizaciń, m´s que en la visiń 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 autom´ticos, que son pasivos.
ıa a

3.1. El Proceso de Modelado del Contexto
Los pasos a seguir son:

1. Llevar a cabo un estudio de alcance y viabilidad. Herramienta: Modelo
de Organizaciń (OM).
o
2. Llevar a cabo un estudio de impacto y mejora (para enfocar/am-
pliar/refinar el modelo de la organizaciń). Herramienta: Modelos de
o
Tareas y de Agentes (TM, AM).

Cada estudio consta de una parte de an´lisis y una parte de decisiń constructiva:
a o

1. Estudio del alcance y viabilidad:
a) An´lisis.- Se trata de identificar las ´reas problema/oportunidades
a a
y buscar soluciones potenciales, ubicńdolos en una perspectiva
a
m´s amplia en la organizaciń.
a o
b) S´
ıntesis.- Se trata de estudiar la viabilidad econ´mica, tćnica y
o e
del proyecto, elegir el ´rea (o ´reas) m´s comprometedora y la
a a a
soluciń meta.
o
2. Estudio de impacto y mejoras (para cada ´rea elegida en el paso an-
a
terior):
a) An´lisis.- 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 15

b) Diseõ.- Se decide acerca de los cambios en las tareas y las medidas
n
de la organizaciń para asegurar su aceptaciń y la integraciń de
o o o
una soluciń basada en SBC.
o
Como ya hemos visto en el cap´
ıtulo anterior, el nivel contextual aglutina tres mo-
delos:
Estudio de alcance y viabilidad
• Modelo de la Organizaciń (OM) para describir y analizar la or-
o
ganizaciń en sentido amplio
o
Estudio de impacto y mejoras
• Modelo de Tareas (TM) y Modelo de Agentes (AM), m´s centrados
a
y detallados, enfocan las partes relevantes
• TM: tareas y conocimiento relativo a ellas directamente relacio-
nado con el problema a resolver con el SBC
• AM: agentes involucrados en las tareas del TM
Para simplificar este trabajo se dispone de formularios u hojas de trabajo que ayu-
dan 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 informaciń,
o
debiendo ser utilizados de forma flexible.

3.1.1. El modelo de Organizaciń
o
Veremos ahora c´mo analizar una organizaciń intensiva en conocimiento:
o o
∗ Describir aspectos de la organizaciń
o
— carpeta de oportunidades/problemas
— contexto de negocio, metas, estrategia
— organizaciń interna
o
√
estructura
√
procesos
√
personas (plantilla, roles funcionales,. . . )
√
potencial y cultura
√
recursos (conocimiento, sistema de soporte, equipos,. . . )
∗ Hacer este trabajo para la organizaciń presente y la futura
o
∗ Comparar y tomar las primeras decisiones de qu´ hacer
e

ıa

16 Apuntes – 3. Modelado del contexto en CommonKADS

Modelo de Organizacion

OM−5
OM−1 OM−2 OM−3 OM−4

Problemas/Oportunidades Descripcion del area elegida

Contexto general Estructura
Procesos Decomposicion detallada
Personal
Cultura y potencial
Recursos
Soluciones potenciales Descripcion a traves de
Conocimiento activos de conocimiento

Figura 3.1: Modelo de la Organizaciń.
o

Se remite a los apńdices para detalle de las plantillas correspondientes a cada paso
e
del an´lisis del Modelo de Organizaciń.
a o

Hasta aqu´ es el an´lisis de los aspectos est´ticos de la organizaciń, 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 tambiń una serie de plantillas que se
e
adjuntan en los apńdices, las tareas que se determinan componen los procesos de la
e
organizaciń y que fueron esbozadas en algunos apartados referentes al modelo de la
o
Organizaciń.
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
identificadas en el modelo de Tareas. De nuevo, remitimos a los apńdices para estudio
e
de las plantillas asociadas.

Laura Castro

Cap´
ıtulo 4

Descripciń conceptual del
o
conocimiento en CommonKADS

Como hemos visto, CommonKADS organiza la aproximaciń a un SBC de la si-
o
guiente forma:

Modelo de la Modelo de Modelo de
Organizacion Tareas Agentes

Modelo de Modelo de
Conocimiento Comunicacion

Modelo de
Diseño

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 especificar
tareas en dominios intensivos de/en conocimiento.

Un modelo de conocimiento especifica los requisitos de conocimiento y razonamien-
to del sistema futuro. No incluye aspectos de comunicaciń con los usuarios ni con
o
otros agentes software, ni tampoco contiene t´rminos espec´
e ıficos de implementaciń.
o

17

18 Apuntes – 4. Descripciń conceptual del conocimiento en CommonKADS
o

Su estructura es similar a la de los modelos de an´lisis tradicional en ingenier´ del
a ıa
software, siendo un aspecto importante para la reutilizaciń del software.
o

Requisitos y especificaciones
MODELO de interaccion
COMUNICACION

MODELO de ORGANIZACION TAREA MODELO
MODELO de TAREAS INTENSIVA DISEÑO
MODELO de AGENTES en CONOCIMIENTO

MODELO
Tarea seleccionada en estudio de viabilidad CONOCIMIENTO
Requisitos y especificaciones
y desarrollada en modelos de tareas y agentes de razonamiento

El t´rmino conocimiento ya ha sido comentado con anterioridad: lo hab´
e ıamos de-
finido como “informaciń sobre la informaciń”. 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 informaciń sobre la relaciń entre ambas.
o o
El conocimiento se puede utilizar para inferir nueva informaciń, de suerte que no
o
hay realmente una frontera definida entre informaciń y conocimiento.
o

En un SBC, el conocimiento est´ presente como tal en la base de conocimientos.
a
Normalmente, se prefiere tener varias bases de conocimiento, cada una aglutinando
reglas de un tipo determinado, de manera que sea posible su reutilizaciń y tambiń
o e
su correcciń de forma m´s sencilla.
o a

Dentro del modelo del conocimiento, distinguiremos varias categor´ de conoci-
ıas
miento:

Conocimiento de la Tarea ¿Qu´ y c´mo?
e o
Es un conocimiento orientado a la meta y que realiza una descompo-
siciń funcional.
o
Conocimiento Inferencial
Encarna los pasos b´sicos 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 informaciń relevantes del dominio es-
o
t´tico, equivaliendo de algń 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)

Conocimiento Inferencial: HIPOTETIZAR VERIFICAR
(inferencia) (inferencia)

Conocimiento del Dominio: SINTOMA ENFERMEDAD PRUEBA
(tipo) (tipo) (tipo)

Modelo de
Conocimiento

Conocimiento Conocimiento Conocimiento
del Dominio Inferencial de la Tarea

Figura 4.1: Categor´ en el modelo del Conocimiento.
ıas

ıa

o

4.1.1. Conocimiento del dominio
El conocimiento del dominio describe la informaciń est´tica m´s importante y los
o a a
objetos de conocimiento en un determinado dominio.

Tiene dos partes principales:

Esquema del Dominio
Describe la estructura est´tica de la informaciń/conocimiento a trav´s
a o e
de definiciones tipo, siendo comparable al modelo de datos/objetos en
IS. Queda definido a trav´s de los constructos del dominio.
e
Base de Conocimientos
Contiene instancias de los tipos que se especifica en el esquema del
dominio (es decir, conjuntos de instancias de conocimiento), siendo
comparable al contenido de una base de datos.

Modelo de
Conocimiento


Esquema Base de
del Dominio Conocimientos

CONSTRUCTOS

Tipos de
Conceptos Relaciones
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


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 m´todos).
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, adem´s, otros para cubrir aspectos espec´
a ıficos del modelado SBC.

Conceptos y Atributos
Como hemos dicho, un concepto describe un conjunto de objetos o instancias. Las
caracter´
ısticas de los constructos se definen mediante atributos, que pueden tener un
valor (at´mico) que se define a trav´s de un tipo de valor (definiciń 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 definirse con el constructo relacion o re-
´ ´
lacion binaria (e incluso relacion n-aria) a trav´s de las especificaciones de
e
argumentos.
La cardinalidad se define para cada argumento y su valor por defecto es 1. Es posible
especificar un rol para cada argumento.
La propia relaciń puede tener atributos.
o

coche pertenencia persona NO DIRECCIONAL
0+ 0−1

coche propiedad−de persona DIRECCIONAL

coche persona REIFICACION
(si la relacion tiene atributos
propiedad o participa en otras relaciones)

fecha−adquisicion

Figura 4.3: Relaciones en el modelo del Conocimiento.

El modelado de las reglas
Las reglas son una forma natural y comń de representar el conocimiento simb´lico.
u o
Ahora bien, ¿c´mo representamos dependencias entre conceptos en un modelo de datos
o
tradicional?

ıa

o

Para modelar la construcciń de las reglas se usa el constructo tipo de regla:
o

Es similar a una relaciń, donde antecedente y consecuente no son
o
instancias de conceptos sino expresiones de esas instancias.
Se modela una relaciń entre expresiones acerca de los valores de los
o
atributos.
Se modelan un conjunto de reglas de estructura similar.
Las relaciones no son estrictamente l´gicas, es necesario especificar un
o
s´ ´
ımbolo de conexion entre antecedente y consecuente.

Estructura de tipo de regla

La estructura es sencilla:

<antecedente> <s´mbolo-de-conexiń> <consecuente>
ı o

Su uso flexible permite la representaciń de cualquier tipo de dependencia (tipos
o
m´ltiples para antecedente y consecuente).
u

ESTADO causa
ESTADO
INVISIBLE

dependencia
estado

ESTADO tiene−manifestacion ESTADO
INVISIBLE OBSERVABLE
manifestacion
regla

TIPO−de−REGLA regla−manifestacion
DESCRIPCION "..."
ANTECEDENTE estado−invisible
CONSECUENTE estado−observable
SIMBOLO tiene−manifestacion
END−TIPO−de−REGLA

Figura 4.4: Ejemplos de representaciń de Tipos de Regla.
o

Laura Castro


Base de Conocimientos
Es una particiń conceptual de la BC que contiene instancias de los tipos de cono-
o
cimiento definidos 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 conexiń separando antecedente y consecuente.
o

BASE−CONOCIMIENTOS
USA ... de ...
... de ...
EXPRESIONES
/* dependientes−estado */
...
/* manifestacion−regla */
...
END−BASE−CONOCIMIENTOS

Figura 4.5: Ejemplo de representaciń de Base de Conocimientos.
o

4.1.2. Conocimiento inferencial
El conocimiento inferencial describe el nivel inferior de descomposiciń funcional.
o
Describe c´mo las estructuras est´ticas del conocimiento del dominio se pueden usar
o a
para realizar el proceso de razonamiento, permitiendo la reutilizaciń del conocimiento.
o

Sus elementos principales se aprecian en la figura 4.6 y son:

Inferencias Relacionadas con el razonamiento, son las unidades b´sicas
a
de procesado de informaciń.
o
Funciones de Transferencia Relativas a la comunicaciń con otros agen-
o
tes (a un nivel muy b´sico, esta cuestiń se trata realmente en el Mo-
a o
delo de Comunicaciń).
o
Roles de Conocimiento Relacionados indirectamente con el conocimien-
to del dominio.

Una inferencia usa el conocimiento de alguna base de conocimiento para derivar
nueva informaciń.
o
Los roles din´micos son las entradas y salidas en tiempo de ejecuciń de las infe-
a o
rencias.

ıa

o

Modelo de
Conocimiento


Roles de Funciones de
Inferencias
Conocimiento Transferencia

Figura 4.6: Elementos del Conocimiento Inferencial.

explicar

ENTRADA SALIDA
INFERENCIA
(rol dinamico) (rol dinamico)

queja hipotesis

Modelo
Causal

(rol estatico)

Figura 4.7: Ejemplo de Inferencia.

Laura Castro


Inferencias

Las inferencias quedan completamente descritas a trav´s de una especificaciń de-
e 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 nom-
bre captura el rol del elemento en el proceso de razonamiento, realizando un mapeado
expl´
ıcito a los tipos del dominio.
Los roles din´micos son variantes E/S, mientras que los est´ticos son entradas in-
a a
variantes (una base de datos).

INFERENCIA explicar ROL−CONOCIMIENTO nombre
ROLES TIPO dinamico
ENTRADA ... MAPEADO−DOMINIO visible−estado
SALIDA ... END−ROL−CONOCIMIENTO
ESTATICOS ...
ESPECIFICACION "..."
END_INFERENCIA

Funciones de Transferencia

Las funciones de transferencia transfieren un item de informaciń entre el agente de
o
razonamiento del m´dulo 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: s´lo interesa
o
su nombre y su E/S. La especificaciń detallada de las funciones de transferencia es
o
parte de otro modelo, el de Comunicaciń.
o

Iniciativa Iniciativa
sistema externa
Informaciń externa
o obtener recibir
Informaciń interna
o presentar proporcionar

Cuadro 4.1: Nombres estńdar de las Funciones de Transferencia.
a

Estructura Inferencial

La combinaciń de los diferentes conjuntos de inferencias especifica la capacidad
o
inferencial b´sica del sistema en desarrollo. El conjunto de inferencias se puede presen-
a
tar gr´ficamente en una estructura inferencial, que hace ńfasis en los aspectos
a e
din´micos del flujo de datos (roles est´ticos opcionales).
a a

ıa

o

rol conocimiento
queja
dinamico
funcion de
rol estatico
transferencia
modelo
explicar obtener hecho real
causal

hecho
hipotesis predecir comparar
esperado

modelo
resultado
manifestacion

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 comunicaciń
o
durante el proceso de desarrollo, a pesar de que a menudo puedan ser provisionales.
Suele ser util realizar anotaciones con ejemplos espec´
´ ıficos del dominio.
Las estructuras inferenciales definen las capacidades inferenciales del sistema, el
vocabulario y las dependencias de control, pero no el control en s´ (del que se ocupa el
ı
conocimiento).

Reutilizaciń de inferencias
o
El estado ideal ser´ disponer de un conjunto estńdar de inferencias. Con ese obje-
ıa a
tivo, se recomienda el uso de nombres lo m´s estńdar posibles con el fin de favorecer
a a
la reutilizaciń.
o

4.1.3. Conocimiento de la tarea
El conocimiento de la tarea describe metas (por ejemplo, asesorar la suscripciń o
de una hipoteca, diseãr un ascensor,. . . ) y las estrategias que se pueden utilizar para
n
realizar dichas metas. Esta descripciń sigue un esquema jer´rquico.
o a
Tal y como se puede observar en la figura 4.9, distinguiremos, dentro del conoci-
miento de la tarea, la propia Tarea y por otra parte lo que llamaremos el M´todo de la
e
Tarea.

Tarea
La Tarea define la meta del razonamiento en forma de pares (entrada, salida), con
el fin de especificar qu´ es necesario saber.
e
La diferencia principal con las funciones tradicionales es que los datos manipulados
por la tarea se describen tambiń independientemente del dominio.
e

Laura Castro


Modelo de
Conocimiento


Metodo de
Tarea
la Tarea

Figura 4.9: Elementos del Conocimiento de la Tarea.

El hecho de que la descripciń deba ser independiente del dominio tiene como ob-
o
jetivo la reutilizaciń de las tareas.
o

Una tarea se describe por medio de tres slots:

META Descripciń textual informal.
o
SPEC Describe de manera textual e informal la relaciń entre la entrada
o
y la salida de la tarea.
ROLES

Los roles de E/S se especifican en forma de roles funcionales, como en las inferencias,
pero con algunas diferencias:

no hay roles est´ticos
a
no hay mapeado de los roles en t´rminos espec´
e ıficos del dominio; los
roles de las tares estń linkados a los roles inferenciales
a
cada tarea tiene un m´todo asociado
e

M´todo de la Tarea
e
El M´todo de la Tarea describe c´mo se realiza una tarea mediante su descompo-
e o
siciń en subfunciones. Las subfunciones pueden ser otra tarea, inferencias o funciones
o
de transferencia.
La parte central del m´todo 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:

ıa

o

explicar

predecir

obtener comparar

Figura 4.10: Ejemplo de esquema de un posible M´todo de la Tarea.
e

◦ llamadas a procedimientos (tareas, inferencias, funciones de transfe-
rencia)
◦ operaciones de roles (asignaciń, suma/resta,. . . )
o
◦ primitivas de control (repetir,. . . )
◦ condiciones
expresiones l´gicas sobre roles
o
condiciones especiales: tiene soluciń y nueva soluciń
o o

4.1.4. ¿Inferencia o Tarea?
Si el comportamiento interno de una funciń1 es importante para explicar el com-
o
portamiento del sistema como un todo, entonces es necesario definir esta funciń como
o
una tarea.
Durante el desarrollo del modelo, es usual manejar estructuras inferenciales provi-
sionales.

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 ńfasis en el control interno y desarrolla funciones
e
que se describen independientemente del modelo de datos, lo que favorece una mayor
reutilizaciń posterior.
o
1
Donde por funciń 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 reutilizaciń se refiere:
o

√
Los modelos de conocimiento pueden ser parcialmente reutilizados en
aplicaciones nuevas.
√
La gu´ principal para la reutilizaciń es el tipo de tarea.
ıa o
√
Existe un cat´logo de plantillas de tareas intensivas en conoci-
a
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 m´xima eficiencia coste/tiempo, disminuir
a
la complejidad y asegurar la calidad.

Una plantilla es una combinaciń 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´ıfico para el tipo de tarea que describe cada plantilla en par-
ticular. Gracias a estas plantillas este m´todo 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 compa-
a
raciń con los antiguos SSEE.
o
En el trasfondo de esto se encuentran la ciencia cognitiva y la psicolog´
ıa.

La estructura de la descripciń en la plantilla es la siguiente:
o

1. Caracterizaciń general.
o
2. M´todo por defecto.
e
3. Variaciones t´
ıpicas (cambios/ajustes frecuentes).
4. Esquema t´ ıpico del conocimiento del dominio (asunciones sobre las
estructuras del dominio).

ıa

o

Tareas Anal´
ıticas Tareas Sint´ticas
e
Sistemaa Preexiste (aunque no es conocido). No existe ań.
u
Entrada Datos acerca del sistema. Requisitos del sistema que se construir´.
a
Salida Alguna caracter´ ıstica del sistema. Descripciń del sistema construido.
o
Tipos clasificacion´ ˜
diseno
asesoramiento modelado
diagnostico planificacion ´
monitorizacion ´ asignacion´
prediccion´ scheduling

a
Entendemos por sistema un t´rmino abstracto que designa el objeto sobre el que se aplica la
e
tarea. En diagn´stico tćnico, por ejemplo ser´ el artefacto o aparato que est´ siendo diagnosticado.
o e ıa a

Cuadro 4.2: Tareas Anal´
ıticas vs. Tareas Sint´ticas.
e

4.3. Construcciń de los modelos de Conocimiento
o
La metodolog´ CommonKADS enfoca el modelo del conocimiento como un produc-
ıa
to. Esto hace que se forme un cuello de botella por falta de experiencia en el modelado
del conocimiento.
La soluciń, como es fćil 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
soluciń correcta ni un camino ´ptimo. As´ pues, lo que se hace es proporcionar una
o o ı
gu´ que funciona bien en la prćtica.
ıa a

El modelado del conocimiento es una forma especializada de especificaciń de re-
o
quisitos en el que se usan, por tanto, principios generales de la IS.

ESTADOS

Identificacion del Familiarizacion con el dominio, lista
Conocimiento potencial de componentes reutilizables

Especificacion del Escoger plantilla de tareas, construir conceptualizacion
Conocimiento inicial, especificacion completa del modelo del dominio

Refinado del Validacion del modelo del conocimiento,
Conocimiento refinado de las bases de conocimiento

Figura 4.11: Gu´ para el modelado del Conocimiento.
ıa

Laura Castro

4.3. Construcciń de los modelos de Conocimiento
o 31

4.3.1. Identificaciń del Conocimiento
o
META Estudiar los items de conocimiento, prepararlos para su especificaciń.
o
ENTRADA Tarea intensiva en conocimiento, principales items de conocimiento iden-
tificados, clasificaciń de la tarea de la aplicaciń.
o o
ACTIVIDADES Explorar fuentes de informaciń y estudiar la naturaleza de la ta-
o
rea.
Los factores m´s importantes con respecto a las fuentes de informaciń
a o
son su naturaleza (¿son claras? ¿tienen base te´rica?) y su diversidad
o
(¿son conflictivas? ¿con qu´ factor de riesgo?).
e
Las tćnicas para su exploraciń son las tradicionales: marcado de tex-
e o
tos, entrevistas, etc. El problema principal reside en encontrar un ba-
lance 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 ex-
pertos
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 valoraciń de resulta-
o
dos, tanto tangibles (listado de fuentes, res´menes de textos, glosario, descripciń
u o
de escenarios), como intangibles (la propia comprensiń).
o
La presencia de una lista de componentes tiene como objetivo allanar el camino
en el manejo de componentes reutilizables en dos dimensiones:

◦ Dimensiń de la Tarea (elegida del tipo asignado en el TM, construir una
o
lista de plantillas)
◦ Dimensiń del Dominio (tipo de dominio, buscar descripciń estńdar)
o o a

4.3.2. Especificaciń del Conocimiento
o
META Completar la especificaciń del conocimiento excepto para los contenidos de
o
los modelos del dominio (que necesitan s´lo contener instancias).
o
ACTIVIDADES
Elegir una plantilla de la tarea Como l´ ınea base de actuaciń, no debemos
o
olvidar que existe una fuerte preferencia por un modelo de conocimiento
basado en aplicaciones ya existentes (por razones de eficacia y calidad ase-
gurada). Los criterios de selecciń son las caracter´
o ısticas de la tarea de la
aplicaciń (naturaleza de las entradas y salidas del sistema, restricciones del
o
contexto. . . ).
Algunas gu´ para la selecciń de plantillas:
ıas o

ıa

Ec.pdf

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (16)

Semelhante a Ec.pdf

Semelhante a Ec.pdf (20)

Ec.pdf