Ingenierıa del Conocimiento. De la Extraccion al

Modelado de Conocimiento

J. T. Palma, E. Paniagua, F. Martın y R. MarınDpto. Ingenierıa de la Informacion y las Comunicaciones

Universidad de MurciaFacultad de Informatica. Campus de Espinardo{jpalma,paniagua,fmartin,roque}@dif.um.es

Resumen

En el presente trabajo se intentara dar una vision general del estado actual en el que se encuentrala disciplina Ingenierıa del Conocimiento. Para comprender la situacion actual de esta disciplina esimprescindible un analisis de su evolucion historica, analizando cada uno de los paradigmas en los quese ha ido basando. Este analisis nos permitira analizar las causas que dieron lugar a la crisis que seprodujo en esta disciplina y cuales fueron las medidas que se articularon para salvarla. Se concluira eltrabajo con una revision de las metodologıas mas utilizadas ası como analisis del presente y futuro de laIngenierıa del Conocimiento

Palabras claves: Ingenierıa del Conocimiento, metodologıas, modelado de conocimiento.

1 ¿Que es la Ingenierıa delConocimiento (IC)?

Pongamonos en la situacion de un profano enesta materia e intentemos resolver esta pregun-ta. Lo primero que harıamos serıa consultar elDiccionario de la Real Academia para buscar elsignificado de las palabras ingenierıa y conoci-miento y obtendrıamos lo siguiente:

Ingenierıa:

1. f. Conjunto de conocimientos ytecnicas que permiten aplicar el sabercientıfico a la utilizacion de la materiay de las fuentes de energıa.

2. Profesion y ejercicio del ingeniero.

Conocimiento:

1. m. Accion y efecto de conocer.

2. Entendimiento, inteligencia, razonnatural. . . .

Atendiendo a estas definiciones podrıamos esta-blecer como definicion de Ingenierıa del Conoci-miento ”Conjunto de conocimientos y tecnicasque permiten aplicar el saber cientıfico a la uti-lizacion del conocimiento (entendimiento, inte-ligencia o razon natural)”. Evidentemente, estadefinicion no nos aclararıa nada acerca de nues-tro objetivo inicial. Para seguir en nuestro em-peno no nos queda otra opcion que consultar aotras personas, que casi con toda seguridad nosdirigirıan hacia el campo de los ordenadores yla informatica (la asociacion es bastante simpleconocimiento → sociedad del conocimiento →nuevas tecnologıas → informatica). Si empe-zamos a consultar bibliografıa relativa a la in-formatica en busca de nuestro objetivo nos en-contraremos con el termino ingenierıa del soft-ware (IS en adelante) y junto a el nos podemosencontrar la siguiente definicion:

Inteligencia Artificial. Revista Revista Iberoamericana de Inteligencia Artificial. No.11 (2000), pp. 46-72.(ISSN: 1137-3601). c©AEPIA (http://aepia.dsic.upv.es/).

La aplicacion de una aproximacion sistematica,disciplinada y cuantificable al desarrollo, fun-cionamiento y mantenimiento del software; enotras palabras, la aplicacion de la ingenierıa alsoftware [IEEE, 1999].

Esta definicion ya nos puede ayudar algo, yaque nos da la vision de que el concepto de in-genierıa aplicado a las ciencias de computacion(o mas ampliamente la vision ingenieril de lainformatica) va encaminada hacia la sistemati-zacion del desarrollo de software. Sin embar-go, todavıa no estamos en disposicion de res-ponder a la pregunta que nos planteabamos alprincipio. Si establecemos un pequeno parale-lismo entre la IS y la IC, podrıamos llegar adeducir que si en la IS el elemento central esel software, en la IC el elemento central debeser el ’software con conocimiento’. Pero ¿quepodrıamos entender por ’software con conoci-miento’?. Una rapida consulta nos lleva altermino sistema experto o sistema basado enconocimiento (SBC en adelante), que se pue-de definir como: ”un sistema software capazde soportar la representacion explıcita del co-nocimiento de un dominio especıfico y de ex-plotarlo a traves de los mecanismos apropia-dos de razonamiento para proporcionar un com-portamiento de alto nivel en la resolucion deproblemas”[Guida and Tasso, 1994]. En otraspalabras los SBC tratan con problemas po-co estructurados en los que nos podemos en-contrar requisitos subjetivos, entradas incon-sistente, incompletas o con incertidumbre yque no pueden ser resueltos aplicando los al-goritmos clasicos o la investigacion operativa[Alonso et al., 1995].

De esta forma podemos establecer que el obje-tivo de la IC es el mismo que el de la IS y queno es mas que el de transformar el proceso dedesarrollo de SBC de un arte a un disciplina in-genieril. Una vez que hemos llegado a este nivel,ya estamos en condiciones de dar una respuestaa la pregunta objeto de esta seccion:

la Ingenierıa del Conocimiento es la discipli-na tecnologica que se centra en la aplicacionde una aproximacion sistematica, disciplinaday cuantificable al desarrollo, funcionamiento ymantenimiento de Sistemas Basados en Cono-cimiento. En otras palabras, el objetivo ultimode la IC es el establecimiento de metodolgıasque permitan abordar el desarrollo de SBC deuna forma mas sistematica.

Un punto que merece la pena aclarar ahora esel significado del concepto metodologıa. A lolargo de este trabajo, entenderemos por meto-dologıa un conjunto de metodos y practicas quepermiten desarrollar de una manera efectiva to-das aquellas tareas que estan implicadas en eldiseno, produccion, mantenimiento y extensionde un determinado producto, que en nuestrocaso es un SBC. Por lo tanto, una metodologıaindica como se deben desarrollar las tareas de-finidas de acuerdo a un determinado ciclo devida. Esta ultima afirmacion es de vital impor-tancia por cuanto implica que una metodologıanecesita de la existencia de un ciclo de vida, yque ademas supone el punto de apoyo sobre elque se define.

Como se puede apreciar, la IC y la IS son disci-plinas completamente paralelas, aunque presen-ten un desfase temporal de unos 10 anos. Mu-chas de las tecnicas de IS han sido adapatadas ala IC con relativo exito, aunque queda todavıamucho camino por recorrer. Sin embargo, nose debe pensar en la IC como la piedra filoso-fal que nos permitira solucionar el desarrollo deaplicaciones para problemas mal estructuradosy cuya definicion no es completa, mas bien ladebemos considerar como una herramienta quenos permitira aislar y delimitar las partes delproblema que provocan esa indefinicion y comoabordar su desarrollo. A pesar de esta, en prin-cipio, limitacion, la IC tiene que ser analizadadesde una perspectiva mas amplia, ya que em-pieza a ser utilizadas en otras disciplinas queen la actualidad estan adquiriendo una enormeimportancia, como por ejemplo la Gestion delConocimiento.

A continuacion, y para hacernos una idea decuales fueron las causas que originaron la nece-sidad de establecer la IC como una disciplina,haremos una revision historica en la que podre-mos apreciar como ha evolucionado esta disci-plina desde sus inicios hasta nuestros dıas.

2 Del Principio hasta laCrisis de la Ingenierıa delConocimiento

Desde sus principios, el principal objetivode la Inteligencia Artificial (IA, en adelan-

te) era el desarrollo de sistemas que pudie-ran ”pensar”y resolver problemas tan inteli-gentemente como lo hacıan los expertos huma-nos. Los primeros trabajos que se iniciaronen esta area se centraban en el desarrollo detecnicas generales para la resolucion de pro-blemas, como por ejemplo los trabajos de Fi-kes y Nilsson [Fikes and Nilsson, 1971] en 1971que dieron como resultado el sistema de pla-nificacion STRIPS, o los de Newell y Simons[Newell and Simon, 1988] en 1963 y que desem-bocaron en el GPS (General Problem Solver).Sin embargo, a finales de la decada de los se-tenta, los investigadores en el campo de la IAreconocieron que los metodos generales de reso-lucion de problemas y las tecnicas de busquedadesarrolladas en los diez anos anteriores resul-taban insuficientes para resolver ciertos proble-mas de investigacion y desarrollo. Como resul-tado de esta afirmacion, se empezo a considerarque el potencial de un ordenador a la hora deresolver problemas radicaba en el conocimien-to que poseıa sobre el dominio de la aplicacionmas que en el mecanismo de inferencia emplea-do. Por lo tanto, indirectamente se establecioque era mas necesario el conocimiento especıficosobre el dominio de la aplicacion, que un cono-cimiento general que pudiera ser aplicado sobrevarios dominios. Esta postura llevo a los inves-tigadores a afirmar que el conocimiento podıaser adquirido de los expertos y ”transferido” aun ordenador a traves de una representacionque estos pudieran manipular.

El conjunto de ideas que surgieron a finales de ladecada de los setenta puede ser considerado co-mo el primer punto de inflexion en el desarrollode los Sistemas Basados en Conocimiento (SBCen adelante) o Sistemas Expertos, dando lugara sistemas que fueron aplicados en multitudde dominios. Entre estos sistemas se encuen-tran prospector[Duda et al., 1978], xcon

[Mcdermott, 1982], mycin[Shortliffe, 1976],guidon[Clancey, 1979], les [Scarl et al., 1987]e internist [Miller et al., 1982].

Estos sistemas eran construidos utilizando eltıpico ciclo de codificacion y correccion de erro-res, tan utilizado en los laboratorios de inves-tigacion de donde surgieron. El conocimientoque poseıan estos primeros SBC se obtenıa pre-guntando a los expertos como resolvıan un de-terminado problema. Posteriormente, el inge-niero del conocimiento codificaba lo que se re-cogıa del experto en forma de reglas heurısticas

(empıricas o asociacionales) que de alguna for-ma mapeaban las caracterısticas observablesdel problema en las conclusiones. Estos SBCestaban dotados de una estructura de controlsimple y una representacion uniforme del cono-cimiento. El conocimiento era representado enun mismo nivel de abstraccion e implıcitamentese combinaba conocimiento sobre como desa-rrollar una determinada tarea, sobre que se en-cuentra en el dominio y el por que funcionan lascosas.

El hecho de que en los primeros SBC el conoci-miento sobre el problema no estuviera estructu-rado llevo, a pesar de los prometedores resulta-dos obtenidos, a que la transferencia de estos alcampo comercial a la hora de construir grandesSBC fuera un fracaso en la mayorıa de los casos.Aparecıan problemas de estimacion del tiempode desarrollo, no se cumplıan las expectativasiniciales sobre lo que deberıa de hacer el produc-to y, sobre todo, el mantenimiento y verificacionde dichos sistemas era una tarea difıcil y costo-sa. Como se indica en [Studer et al., 1998], es-ta situacion es directamente comparable con loque ocurrio en el desarrollo de los sistemas deinformacion tradicionales en la tan mencionadacrisis del software a finales de los sesenta: losmedios con los que se desarrollaron los proto-tipos academicos no pudieron ser extendidos aldiseno y mantenimiento de los grandes sistemasde informacion de larga durabilidad requeridospor las empresas. Por lo tanto, de la misma for-ma que la crisis del software dio como resultadoel establecimiento de la Ingenierıa del Softwarecomo una disciplina, la situacion que se produjocon el desarrollo de los primeros SBC dejo clarola necesidad de establecer planteamientos masmetodologicos, dando como resultado el naci-miento de la Ingenierıa del Conocimiento comouna disciplina mas de la IA. El objetivo de es-ta nueva disciplina, al igual que la Ingenierıadel Software, es la de transformar el proceso deconstruccion de un SBC de un arte a un pro-ceso de ingenierıa. Para llevar a cabo este finse tenıa que revisar todo el proceso de desarro-llo y mantenimiento de los SBC, y desarrollarmetodos, lenguajes y herramientas especializa-das para dicho fin [Shaw and Gaines, 1992].

3 Buchanan y su Modelo deCiclo de Vida

Si observamos desde este nuevo punto de vis-ta ingenieril el desarrollo de los primeros sis-temas expertos en las decadas de los setentay ochenta, se puede considerar que el procesode construccion de un SBC era un proceso detransferencia del conocimiento humano a unabase de conocimiento implementada en un or-denador. El conocimiento humano, como ya semenciono en apartados anteriores era, extraıdomediante una serie de entrevistas al experto.Obviamente, este proceso de transferencia des-cansaba sobre la idea de que el conocimientorequerido por el SBC puede ser recogido e im-plementado en un ordenador. El paradigma dela Ingenierıa del Conocimiento como un proce-so de transferencia tiene su culminacion en eltrabajo de [Buchanan et al., 1983]. En dichotrabajo se presenta el desarrollo de un SBC co-mo un proceso de Adquisicion de Conocimiento,entendido este como la transferencia y trans-formacion de la experiencia en la resolucion deproblemas desde alguna fuente de conocimientoa un programa. El conocimiento a ser elicitadoesta formado por una coleccion de hechos, pro-cedimientos y reglas sobre un dominio concreto.Para este proceso de extraccion de conocimien-to se necesita una persona, el ingeniero del co-nocimiento que sirva de intermediario entre elexperto y el programa.

Una de las aportaciones mas importante deltrabajo de Buchanan fue la identificacion delproceso de adquisicion de conocimiento comoun cuello de botella en el proceso de desarrollode un SBC. Este problema aparece como con-secuencia de la falta de ”conocimiento”que elingeniero del conocimiento tiene sobre el domi-nio de la aplicacion, lo que nos lleva a un pro-blema de comunicacion con el experto. Paraayudar al ingeniero del conocimiento a solven-tar este problema, se propone un ciclo de vidapara el proceso de adquisicion de conocimien-to que abarca desde la concepcion del sistemahasta su madurez. La metodologıa propuestase basaba en el tıpico ciclo de vida en casca-da utilizado en los inicios de la ingenierıa delsoftware (figura 1), de la que se puede deducirque el proceso de construccion de un sistemaexperto se plantea como un proceso de revisioncasi constante, que puede implicar la redefini-

cion de los conceptos, de las representaciones oel refinamiento del sistema implementado. Esterefinamiento pasa por repetir el ciclo en sus dosultimas etapas para de esta forma ajustar la ba-se de conocimiento y las estructuras de controlhasta alcanzar el comportamiento deseado.

La importancia de esta metodologıa radica enque es el primer intento de planteamiento deuna metodologıa para el desarrollo de SBC quepermitıa abordar problemas que se pueden pre-sentar en el mundo de la industria. Como sepuede observar, la metodologıa presentada sebasaba en el clasico ciclo de vida planteado enel modelo de cascada por la Ingenierıa del Soft-ware, permitiendo la realizacion de bucles paracompletar etapas pasadas. Durante los anos si-guientes se plantearon numerosas modificacio-nes a esta metodologıa para permitir el desarro-llo por prototipado [Kahn, 1994] o su adapta-cion al ciclo de vida en espiral derivado del tra-bajo de [Boehm, 1988].

Estas metodologıas fueron utilizadas con rela-tivo exito hasta principios de la decada de losnoventa, fecha en la que se replantea la inge-nierıa del conocimiento desde la perspectiva dela transferencia hacıa la perspectiva del mode-lado, como un intento de solucionar el proble-ma del cuello de botella que suponıa la fase deadquisicion de conocimiento. Ademas del pro-blema que suponıa el cuello de botella de la ad-quisicion de conocimiento, se detectaron caren-cias importantes que intentarıan ser resueltas ala luz de nuevas metodologıas. Las carenciasque hicieron replantear la Ingenierıa del Cono-cimiento se pueden resumir en:

• La generacion de explicaciones era com-plicada debido a la ausencia de separa-cion explıcita entre el conocimiento sobreel ”como”, el ”que”y el ”por que”, li-mitandose dichas explicaciones a simplestrazas de ejecucion.

• El sistema no tenıa conciencia de sus pro-pias limitaciones, con lo que tendıan a darrespuestas de escasa utilidad en vez de res-ponder con un simple ”no se”(tal y comoactuarıa un experto responsable) a pregun-tas que pueden estar fuera de su dominiode conocimiento.

• El mantenimiento de dichos sistemas eracomplicado. Por un lado la validacion

Figura 1: Modelo de Ciclo de Vida propuesto por Buchanan et al.

del conocimiento era una tarea comple-ja al estar este desperdigado sobre la ba-se de reglas. Por otro lado, la dispersiondel conocimiento provocaba que la exten-sion de la base de conocimiento (median-te la adicion de nuevas reglas) resultaracompleja, sobre todo a la luz del traba-jo de [Heckerman and Horovitz, 1986] quedemostraron que la independencia y mo-dularidad de un conjunto de reglas de unabase de conocimiento no era tan evidente,ya que la adicion de reglas podıan produ-cir interacciones negativas con el resto delas reglas, degradando de esta forma la efi-ciencia del sistema.

4 El Cuello de Botella dela Adquisicion de Conoci-miento

Como ya mencionamos en el apartado ante-rior el termino cuello de botella de la adquisi-cion de conocimiento fue acunado por Bucha-nan [Buchanan et al., 1983] y se utilizo para ha-cer referencia al hecho de que la adquisicion deconocimiento es el punto que plantea una ma-yor dificultad a la hora de crear una base deconocimiento. En [Musen, 1993] se enumeran

las causas principales de esta dificultad radicanen los siguientes problemas:

1. El problema del conocimiento tacito.Aunque no se sabe exactamente comoel conocimiento tacito es codificado psi-cologicamente en la memoria humana, seda por hecho que la resolucion de proble-mas por parte de los expertos involucra eluso de este tipo de conocimiento. Por lotanto, no es de extranar que el conocimien-to tacito sea el objeto de estudio de la ad-quisicion de conocimiento. Ademas, a me-dida que las personas se vuelven mas ex-perimentadas en su area de conocimientoy aplican repetidamente su conocimientodeclarativo a determinadas tareas, este sevuelve tacito, perdiendo de esta forma con-ciencia de lo que realmente saben. Conse-cuentemente, el conocimiento que es masidoneo para su incorporacion a un SBC,y por lo tanto el objeto de la adquisicionde conocimiento, es el tipo de conocimientosobre el que los expertos tienen menos con-ciencia, con lo cual su adquisicion se haceuna tarea bastante compleja.

2. El problema de la comunicacion. Es-te problema radica en que los expertos enuna determinada area de aplicacion y losingenieros del conocimiento no utilizan el

mismo lenguaje para comunicarse. Comose afirma en [Musen, 1993], para poder re-presentar el conocimiento relevante en undeterminado tema, el ingeniero del conoci-miento se debe familiarizar con el dominode la aplicacion, debe de aprender el vo-cabulario utilizado en dicha area, y quizas,una nueva forma de ver los problemas. Porlo tanto, el ingeniero del conocimiento de-be esforzarse en comprender el area sobrela que el experto va a hablar, o puede noentender lo que el experto trata de comu-nicar. Por otro lado, el problema de la co-municacion no solo recae en la falta de co-nocimiento sobre el dominio que posee elingeniero del conocimiento, sino que tam-bien se debe al hecho de que el experto, enla mayor parte de los casos, carece de cono-cimientos de programacion, y por lo tanto,no sabe que conocimiento es el es idoneopara ser codificado en el ordenador.

3. El problema de utilizar representa-ciones del conocimiento. Ademas delas barreras linguısticas y cognitivas, otrocomponente adicional al cuello de botellade la adquisicion del conocimiento radi-ca en el lenguaje elegido para la codifica-cion del mismo, ya que los lenguajes usa-dos para codificar el conocimiento carecengeneralmente de la suficiente potencia ex-presiva. En [McCarthy and Hayes, 1969]se introdujo el termino adecuacion episte-mologica como la habilidad de un forma-lismo de representacion del conocimientopara expresar los hechos que una personaconoce sobre algun aspecto del mundo re-al. Este aspecto es bastante importante yaque hay experimentos que demuestran quela forma en la que es modelado el cono-cimiento del experto, depende fuertemen-te del lenguaje de representacion utilizado.Por lo tanto, las primitivas ofrecidas porlas herramientas de construccion de SBCtiene una influencia bastante fuerte la for-ma en el que el conocimiento sobre el do-minio es adquirido.

Estos problemas se hicieron cada vez mas evi-dentes a medida que se intentaba abordar laconstruccion de SBC mas complejos, dando lu-gar a que las funcionalidades esperadas no secumplieran y que tampoco se cumplieran conlos plazos establecidos para el desarrollo. Esto

evidenciaba el hecho de que se habıa llegado aun punto en el que el tamano de los problemasque se intentaban abordar requerıa de unas me-todologıas de desarrollo mas elaboradas de loque existıan en esos momentos.

5 El Nivel de Conocimiento

Aunque la crisis de la ingenierıa del conocimien-to era palpable, pocos esfuerzos se realizaronpara determinar cual eran las causas principa-les de dicha crisis. Fue Newell [Newell, 1982] elprimero que analizo en profundidad este pro-blema. Para Newell el principal problema quehabıa que abordar era el establecimiento de ladiferencia que existe entre lo que entendemospor conocimiento y su representacion, diferen-cias que en ese momento no estaban claras. Elorigen de este problema se debıa al hecho deque al ser el nivel simbolico el nivel mas alto enla jerarquıa, tanto el conocimiento como su re-presentacion se colocaban en dicho nivel, y porlo tanto, no se podıan diferenciar de una formaclara. Para resolver el problema, Newell pro-pone la existencia de un nivel adicional al quele da el nombre de nivel de conocimiento. Estenuevo nivel hay que considerarlo realmente co-mo un nivel y como veremos nos va a ayudara distinguir entre lo que es conocimiento y surepresentacion.

En una rapida aproximacion al nivel de conoci-miento, podemos decir que:

• El sistema en este nivel es un agente.

• Sus componentes son los objetivos, accio-nes y cuerpos.

• El medio lo constituye el conocimiento.Por lo tanto, el agente procesara el conoci-miento que tiene para determinar que ac-ciones tiene que tomar.

• La ley de comportamiento esta determina-da por el principio de racionalidad: las ac-ciones son seleccionadas para alcanzar losobjetivos, es decir, el agente selecciona lasacciones que sabe que le llevan a cubrir losobjetivos.

Por lo tanto, al definir un sistema en el nivelde conocimiento lo estamos tratando como si

poseyera conocimiento y objetivos, ademas desuponer que hara todo lo posible para alcan-zar dichos objetivos, en la medida en que suconocimiento se lo permita. En la jerarquıa deniveles, el nivel de conocimiento se situa sobreel nivel simbolico, con lo que sus componentes(acciones, objetivos y cuerpos) y medio (cono-cimiento) pueden ser definidos en terminos dedicho nivel. La definicion estructural de estenuevo nivel es bastante simple, ya que solo po-demos decir que esta formado de cuerpos deconocimiento, objetivos y acciones, y que estosestan de alguna forma conectados en el sentidode que todos los componentes son tenidos encuenta en la seleccion las acciones que hay quetomar.

Hasta la aparicion de este nuevo nivel, se con-sideraba que el nivel simbolico estaba divido endos subniveles: uno que era propiamente el ni-vel simbolico y otro que corresponde al nivel deconocimiento, pero la descripcion de sistemasque manifiestan un comportamiento inteligen-te necesita que estos dos niveles sean tratadospor separado. La existencia de este nivel quedareflejada en la siguiente hipotesis:

Hipotesis del Nivel de Conocimiento.Existe un nivel adicional en los sistemas com-putacionales, que esta situado justo encima denivel simbolico, que esta caracterizado por te-ner el conocimiento como medio y el principiode racionalidad como ley del comportamiento.

Para describir este nuevo nivel de formaautonoma, es decir, sin hacer referencia algu-na a los niveles inferiores, se deben de tratarlos siguientes aspectos: la estructura del nivel,constituida por sus componentes y las leyes decomposicion, las leyes de comportamiento quelo rige, y por ultimo del medio, el conocimiento.

5.1 La Estructura del Nivel deConocimiento

El agente, es decir, el sistema definido en el ni-vel del conocimiento, tiene una estructura muysimple. En una primera aproximacion pode-mos decir que un agente esta compuesto de uncuerpo fısico, que le permite interaccionar conel entorno. Este cuerpo fısico esta formado porun conjunto de acciones a traves de las cua-les se puede realizar dicha interaccion. Aunqueel cuerpo fısico que permite la interaccion con

el entorno puede ser lo complejo que se quiera,su complejidad no queda reflejada en el sistemadescrito en el nivel de conocimiento, ya que es-te ultimo solo puede evocar el comportamientodel sistema.

Otro de los elementos que se encuentran en es-te nivel es el cuerpo de conocimiento, que escomo una memoria que contiene todo lo que elagente sabe en un determinado instante. Comose puede deducir, el conocimiento es anadido aesta memoria por medio de la ejecucion de lasacciones. Aunque de algun modo este cuerpode conocimiento se comporta como una memo-ria, no tiene ninguna similitud estructural conel concepto de memoria utilizado en los nivelesinferiores. Finalmente se puede decir que unagente posee un conjunto de objetivos. Un ob-jetivo es una parte diferenciada del cuerpo delconocimiento que define un determinado esta-do del entorno. Esta diferenciacion del restodel cuerpo del conocimiento les permite desa-rrollar un papel distinto en el comportamientoque presenta el agente, describiendo de algunaforma las intenciones del mismo.

Un hecho importante que se puede deducir esque en este nivel no existe ninguna ley de com-posicion, a diferencia de los niveles inferioresen los que diferentes leyes de composicion defi-nen sistemas con distinto comportamiento. Es-ta ausencia de estructura es la clave del nivelde conocimiento, en el sentido de que el com-portamiento del sistema se define en terminosde lo que el agente sabe, y no en la forma deensamblar sus componentes. Por lo tanto, po-demos decir que la estructura interna del sis-tema se define de una forma en la que no setiene que conocer nada sobre ella para predecirel comportamiento del mismo, el cual solo de-pende de lo que sabe el agente, lo que quiere yde los medios que tiene para interaccionar conel entorno. Como se vera mas adelante, esteservira como punto de partida de la idea de lareutilizacion del conocimiento, es decir, la po-sibilidad de definir componentes genericos deconocimiento que puedan ser aplicables a dis-tintos problemas se puede interpretar como lautilizacion del mismo nivel de conocimiento pa-ra distintas instancias de los niveles inferiores.

5.2 El principio de Racionalidad

Bajo este nombre se esconde la ley que rigeel comportamiento de un agente y que permi-te la prediccion de su comportamiento. Esteprincipio puede ser formulado en los siguientesterminos:

Principio de racionalidad. Si un agente tie-ne conocimiento de que una de sus accionespuede llevarle a la consecucion de uno de susobjetivos, entonces el agente seleccionara dichaaccion.

Como se puede observar este principio estable-ce la conexion del conocimiento y los objetivoscon el proceso de seleccion de acciones, sin es-pecificar el mecanismo por el que se lleva a cabodicha conexion. Esta caracterıstica tambien esdistintiva respecto al resto de niveles. En losdemas niveles, el comportamiento queda deter-minado por la forma en que son procesados loscomponentes. En el nivel de conocimiento elprincipio de racionalidad nos define la conexionentre las acciones y los objetivos de acuerdo conel conocimiento que posee el agente.

5.3 La Naturaleza del Conoci-miento

En las secciones anteriores quedo claro que elmedio utilizado en el nivel de conocimiento es elpropio conocimiento, es decir, algo que es pro-cesado segun el principio de racionalidad. Enuna definicion mas formal, podemos decir:

Conocimiento. Cualquier cosa que puede seradscrita a un agente y que su comportamientose puede computar segun el principio de racio-nalidad.

El conocimiento puede ser descrito totalmen-te en terminos funcionales (que hace), o enterminos estructurales (una serie de objetos queposeen determinadas propiedades y relaciones).Sin embargo, hay que tener en cuenta que el pa-pel que juega el conocimiento no puede ser cu-bierto directamente por una estructura fısica,sino que se cubre aproximadamente e indirec-tamente por distintos sistemas simbolicos.

Un aspecto diferenciador del conocimiento res-pecto a los medios que podemos encontrar en elresto de los niveles, es el hecho de que el conoci-

miento no puede ser descrito en terminos de losdistintos estados en los que pueden encontrarsesus estructuras fısicas. Esta caracterıstica di-ferenciadora le da al conocimiento un aspectoabstracto, con lo que no puede ser explicitadocon la claridad que lo son el resto de los me-dios de los niveles inferiores. Solo puede serimaginado como resultado de los procesos in-terpretativos que operan en el nivel simbolico.Por lo tanto, no lo podemos considerar como unconjunto de expresiones simbolicas con una or-ganizacion estatica, hay que considerarlo comocompuesto de procesos y estructuras de datos.

Esta vision del conocimiento puede considerarsecomo la constatacion de la existencia del cue-llo de botella de la adquisicion de conocimientoen el proceso de desarrollo de un SBC. El he-cho de que sea una entidad abstracta y difıcilde detectar, nos puede ayudar a comprender lodifıcil del proceso de extraccion de conocimien-to. Si ademas, a esto le unimos la situacion queexistıa antes del trabajo de Newell, en la queel nivel de conocimiento se consideraba partedel nivel simbolico, el proceso de construccionde un SBC se convertıa en un intento de su-perar dos barreras: por un lado la dificultadde la deteccion del conocimiento, y por el otro,el intento de implementarlo directamente en elnivel simbolico, que como dijo Newell, solo per-mite reflejar un conjunto bastante reducido dela variedad de todos los posibles comportamien-tos, resultado de intentar representar un com-portamiento indeterminista mediante estructu-ras deterministas. Newell nos indica que esteproblema puede ser resuelto representando elconocimiento en un nivel superior, el nivel deconocimiento.

6 KLIC

KLIC (KBS life cycle o Ciclo de Vida pa-ra SBC) fue presentada por Guida y Tasso[Guida and Tasso, 1994]. Supuso el primer in-tento serio en el planteamiento de una metodo-logıa para le desarrollo de SBC, ya que no solose le da importancia al propio proceso de des-arrollo sino que tambien se presta mucha aten-cion a los productos generados en cada una delos procesos. Basicamente, en el nivel mas altode abstraccion el ciclo de vida propuesto estacompuesto de una serie de fases que se corres-

ponden con los procesos principales del ciclo devida: diseno, produccion y mantenimiento. Ca-da una de estas fases se descompone en una se-rie de tareas. El modelo planteado es una mez-cla entre un modelo ciclo de vida en cascada,las fases se ejecutan en un orden estrictamentesecuencial y un modelo en espiral, ya que la eje-cucion de las tareas puede implicar estructurasde control de tipo bucle, ademas de estructurascondicionales, de seleccion y de ejecucion para-lela.

KLIC se organiza en 6 fases que se agrupan entres macrofases que se corresponden con los pro-cesos de analisis, desarrollo y mantenimiento:

Fase-0. Analisis de Posibilidades. En estafase se indentifican que areas de la organi-zacion bajo estudio se podrıan beneficiardel desarrollo de un SBC y se clasificande acuerdo a su importancia estrategica ytactica, beneficios esperados, costes y com-plejidad tecnica. El producto que se generaen esta fase es el informe sobre el analisisde posibilidades, que entre otras cosas in-cluye un plan maestro para la organizacionpara que esta se beneficie del uso de las tec-nologıas basadas en el conocimiento.

Fase-1. Analisis de Viabilidad. En esta fa-se se analiza el dominio de aplicacion (po-siblemente sugerido por el plan maestro) yse identifica el problema que hay que resol-ver. A partir de aquı, se analizan los requi-sitos, se definen los objetivos del proyectoy se describen las especificaciones funcio-nales, tecnicas y el criterio de aceptabili-dad. El producto generado en esta fasees el Informe sobre el analisis de la viabi-lidad que ademas de la informacion ante-riormente comentada, incluye las primerasversiones del diseno tecnico, el diseno de laorganizacion y del plan del proyecto.

Fase-2. Construccion del Demostrador.El principal objetivo de esta fase es la cons-truccion de una primera version y muy li-mitada del SBC. Esta primera version nospermitira entre otras cosas: validar, refi-nar y reconsidear las decisiones tecnicas yel plan del proyecto realizados en la Fase1, y refinar el analisis de requisitos una vezconsultados los usuarios finales. Los pro-ductos de esta fase son el Demostrador yel informe sobre el demostrador en el que

se resume las actividades realizadas y losresultados alcanzados.

Fase-3. Desarrollo del Prototipo. El obje-tivo de esta fase es la de encontrar la solu-cion tecnica mas apropiada para la aplica-cion considerada y en base a esta, construirel SBC objeto del proyecto. Los productosgenerados en esta fase son: el prototipo,que es un SBC que de alguna forma cum-pla con todas las especificaciones funcio-nales, el conjunto de herramientas de des-arrollo que han servido de ayuda para laconstruccion de la Base de Conocimientoy el informe sobre el prototipo, en el que serecogen un resumen de las actividades des-arrolladas y los resultados alcanzados. Sinembargo, un hecho bastante importante esque los autores proponen un desarrollo in-cremental para el prototipo. De esta formavemos como en un ciclo de vida en cascadase intercalan fases basadas en un ciclo devida en espiral.

Fase-4. Implementacion, Instalacion yEntrega del Producto Final. Aquı elobjetivo es el desarrollo del SBC completo,el cual tiene que tener el mismo compor-tamiento que el prototipo pero tiene queestar instalado en un entorno real de ope-racion, verificado con datos reales y, even-tualmente, entregado a los usuarios paraque lo exploten. Los productos de esta faseson: el Sistema final, el Sistema de sopor-te para el mantenimiento, los manuales deusuario, tecnicos y de mantenimiento y elInforme sobre el Sistema Final.

Fase-5. Mantenimiento y Extension. Es-ta fase comienza una vez que el productofinal (el SBC desarrollado) es entregado alos usuarios finales para su utilizacion y seextiende durante el resto del ciclo de vidadel SBC. En ella se monitoriza la vida ope-racional del SBC, se realizan intervencio-nes correctivas, intervenciones adaptativasy se realiza un mantenimiento proactivo yevolutivo. Los productos de esta fase son:las nuevas versiones del SBC, ası como losmanuales actualizados, y la historia de mo-dificaciones del SBC.

Como podemos apreciar, el trabajo de Guida yTaso supone una de las primeras aproximacio-nes serias hacia una metodologıa para el des-

arrollo de SBC. La base de este trabajo resideen el intento de adaptar los resultados alcan-zados en la Ingenierıa del Software al campode la Ingenierıa del Conocimiento que en esosmomentos empezaba ha adquirir un auge im-portante. Aunque en lıneas generales KLIC sebasa en el modelo de ciclo de vida en cascadaclasico, deja sentadas las bases sobre las quese construiran las nuevas metodologıas: (1) seconsidera el proceso de desarrollo de SBC unatarea compleja y distinta a la del desarrollo desistemas software tradicionales, y se adopta elciclo de vida en espiral como el mas adecuadopara esta fase; y (2) el analisis la viabilidad delproyecto abarca un espectro mas amplio que enla Ingenierıa del Software, requiriendo un estu-dio mucho mas profundo del entorno organiza-cional en el que se desarrolla. Como veremosen los siguientes parrafos, estos aspectos serancomunes a las nuevas metodologıas basadas enel paradigma del modelado del conocimiento.

7 Los Primeros Pasos hacialas Tecnicas de Modelado

En la seccion anterior quedo claro que an-tes de la aparicion del trabajo de Newe-ll [Newell, 1982] la discusion en el desarro-llo de SBC se realizaba en terminos del nivelsimbolico, con lo que el debate no se centra-ba en la relacion entre las tareas y el tipo deconocimiento que necesitan. Para centrar ladiscusion en dichos terminos, se plantea que elanalisis de los SBC se haga de manera inde-pendiente a la implementacion. Como el lector,puede suponer esta proposicion desemboca enel nuevo paradigma de la Ingenierıa del Conoci-miento basado en el modelado del conocimien-to. Pero como veremos, el camino que se tuvoque recorrer desde que se reconociera la exis-tencia del nivel de conocimiento a la aparicionde las primeras metodologıas no fue un caminosencillo, sino mas bien un proceso en el que sefueron refinando una serie de ideas que fueronsurgiendo. Por esto, creemos que es importan-te comentar dos trabajos que la mayor partede los autores los situan en el puente entre lasmetodologıas modernas y el trabajo de Newell.Se trata de los metodos de limitacion de rolesy las tareas genericas, trabajos que se puedenconsiderar paralelos y que ponen de manifiestodos de los aspectos mas importantes que han

llevado al planteamiento de metodologıas parael desarrollo de SBC: la idea de limitar los pape-les (roles) que puede jugar el conocimiento den-tro de un determinado dominio y los conceptosde tareas y metodos genericos como elementosconstitutivos de los SBC.

7.1 Metodos de Limitacion deRoles

Los metodos con limitacion de roles (MLR, enadelante) [McDermott, 1988] se pueden consi-derar como uno de los primeros intentos de ex-plotar la reutilizacion de los metodos de resolu-cion de problemas en el desarrollo de los SBC.McDermott puso de manifiesto que todos losSBC desarrollados hasta la fecha de su traba-jo se caracterizaban por tener un conocimien-to de control, es decir, un motor de inferenciao metodo de resolucion de problema utilizado(MRP, en adelante) bastante sencillo. Esta sim-plicidad del conocimiento de control aportabala flexibilidad suficiente para que este pudieseser aplicado a gran cantidad de tareas de dis-tinta naturaleza. Sin embargo, esta flexibilidadobligaba a que parte del conocimiento de con-trol necesario para llevar a cabo tareas concre-tas se codificara junto con la base de conoci-miento, con lo que la seleccion y secuencia deacciones que se llevaba a cabo dependıa del do-minio de la aplicacion. Obviamente, esta faltade distincion entre el control y el conocimientoespecıfico de la aplicacion conllevaba problemasde mantenimiento en las aplicaciones desarro-lladas.

Otro problema que surgıa al utilizar MRP queobligaban a anadir el conocimiento de controlespecıfico de la tarea, al mismo tiempo que seconstruıa la base de conocimiento, es que no seproporcionaba ninguna guıa sobre que tipo deconocimiento deberıa ser adquirido y como estedeberıa ser codificado. Esto era debido a quelos requisitos necesarios sobre el conocimientoespecıfico de la tarea no se podıan establecerhasta que no se conociese el conocimiento decontrol adicional que se necesitaba, y por su-puesto, esto no se podıa deducir de la definiciondel MRP.

Para resolver estos problemas, McDermott pro-puso analizar los MRP utilizados en distintasaplicaciones y redefinirlos llevando hasta sus

ultimas consecuencias la diferenciacion, tan uti-lizada en los SBC desarrollados hasta la fecha,del MRP y la base de conocimiento especıficode la tarea. Este analisis llevo a las siguientesconclusiones:

• Existıan familias de tareas (como por ejem-plo el diagnostico) que podıan ser resueltaspor metodos cuyo conocimiento de controlera lo suficientemente abstracto como paraque no se viese influenciada por las carac-terısticas particulares de cualquiera de losmiembros de la familia de tareas.

• Al definir un metodo en los terminos ante-riores, se indicaba implıcitamente que ro-les pueden jugar los componentes del co-nocimiento especıfico de la tarea. De es-ta forma, la definicion del metodo propor-cionaba una guıa lo suficientemente clarade que conocimiento debe ser adquirido ycomo este debe ser implementado.

• La definicion de los roles que podıa jugar elconocimiento especıfico de la tarea, provo-caba una disminucion en la diversidad delconocimiento que se tenıa que utilizar enla implementacion de la tarea.

A estos metodos que proporcionaban las lıneasbasicas para la adquisicion y codificacion de co-nocimiento se les denomino Metodos con Limi-tacion de Roles. Este tipo de metodos cons-tituıa una clase bastante importante ya queademas de indicar que conocimiento era nece-sario adquirir, se podıan utilizar en un amplionumero de dominios diferentes. Generalmente,un MLR estaba formado por un bucle defini-do sobre 5 o 10 pasos. Algunos de estos pa-sos operaban sobre modulos de conocimiento es-pecıficos de la tarea, con la condicion de que ensu definicion no se incluyera ningun tipo de co-nocimiento de control. De esta forma, se conse-guıa dotar de cierta regularidad al conocimien-to especıfico de la tarea requerido por el MLR.Esta regularidad en el conocimiento hacıa tra-table la automatizacion de la adquisicion delconocimiento. De esta idea surgieron varias he-rramientas entre las que cabe destacar MOLE[Eshelman et al., 1993] que se centraba en elMLR de cubrir y diferenciar y que fue aplicadocon exito a numerosos problemas de diagnosticoy SALT [Marcus and McDermott, 1993] que sebasaba el MLR de proponer y revisar.

Los MLR propuestos por McDermott fueronutilizados en un gran numero de dominios dife-rentes, pero sin embargo, cuando se intentabaabordar algun problema del mundo real apa-recıa el problema de como precisar si una tareaconcreta podıa ser resuelta por un MLR deter-minado (hay que tener en cuenta que este pro-blema esta todavıa sin resolver). Otros de losinconvenientes que aparecieron se debieron alhecho de que los MLR presentaran una estruc-tura fija, con lo que no se podıan utilizar enproblemas que requerıan la combinacion de va-rios MLR. La principal causa de este problemaradicaba en el hecho de que no se habıa definidode una forma clara la estructura y los elemen-tos constitutivos del conocimiento de control delos MLR, problema que serıa resulto de formaparalela por el trabajo de Chandrasekaran quese describira a continuacion.

7.2 Las Tareas Genericas y LasEstructuras de Tareas

El concepto de tarea generica (TG, en adelante)[Chandrasekaran, 1983, Chandrasekaran, 1986][Chandrasekaran and Johnson, 1993] tiene susorıgenes en los trabajos de Gomez y Chandra-sekaran [Gomez and Chandrasekaran, 1981],que dieron como resultado la identificaciondel proceso de clasificacion como un elementocomun a los problemas de diagnostico, yen los trabajos de Mittal y Chandrasekaran[Mittal and Chandrasekaran, 1984] que anadie-ron la abstraccion de datos como otro de loselementos comunes a dicho proceso. Estosresultados fueron producto del trabajo realiza-do en el desarrollo del sistema de diagnosticoMDX [Chandrasekaran and Mittal, 1983][Chandrasekaran et al., 1979].

El trabajo del grupo de Chandrasekaran sebasa en la idea intuitiva de que tienen queexistir tipos de conocimiento y requisitos decontrol que sean comunes al razonamiento dediagnostico en diferentes dominios, de la mis-ma forma que cabe esperar que la representa-cion del conocimiento asociado a la tarea dediagnostico se pueda realizar utilizando un vo-cabulario comun. Ademas, cabe esperar que es-ta idea se pueda aplicar a otros tipos de razona-miento, como se hizo con el proceso de diseno,y que el resultado obtenido fuera distinto al ob-tenido con el proceso de diagnostico. Otra delas ideas que sirvieron de base para este trabajo

fue el hecho de que la experiencia este constitui-da por un conjunto organizado de conocimien-to (mas de lo que podıan ofrecer los sistemasbasados en reglas), con un comportamiento decontrol que esta indexado por la organizacion yforma del conocimiento que contienen.

Todos estos antecedentes llevaron a la defi-nicion de un TG como una estructura deconocimiento que se describe en el nivel deconocimiento, y que especifica una tarea deutilidad general (por ejemplo, clasificacion),un metodo para llevarla a cabo y las clasesde conocimiento que necesita dicho metodo.En la primera aproximacion se identificaronseis TG [Chandrasekaran, 1986]: clasificacionjerarquica, valoracion de hipotesis, transferen-cia de informacion dirigida por conocimiento,ensamblado abductivo, diseno jerarquico porseleccion de planes y refinamiento y abstraccionde estados.

Estas TG pueden ser utilizadas como primitivasa la hora de definir tareas mas complejas comoel diagnostico y diseno. Por lo tanto, las TGpueden ser vistas como bloques constructivospara la composicion de tareas mas complejas.Sin embargo, a pesar de que se admitıa la ne-cesidad del analisis en el nivel de tareas y lasventajas que este ofrecıa a la adquisicion de co-nocimiento y la Ingenierıa del Conocimiento, ladefinicion de las TG presentaban las siguientesdesventajas [Chandrasekaran et al., 1992]:

• No queda claro cual es la diferencia entretareas y clases de tareas, y no se especificacomo estan relacionadas las TG complejascon las simples.

• Las TG propuestas estan definidas a nive-les de complejidad diferentes, es decir, noqueda claro cual es el nivel de abstraccionen el que se tienen que definir.

Para solventar dichos problemas se propone unaevolucion del concepto de TG hacıa el conceptode Estructura de Tareas (ET, en adelante). Eneste nuevo marco se consideran los siguienteselementos:

• Tareas. El termino tarea se refiere aun tipo de problema o conjunto de ins-tancias de problemas con algo en comun,

es decir, especifica el problema a resolvery el objetivo a alcanzar. En este pun-to es importante distinguir entre una ins-tancia de tarea, especificada como un parproblema/objetivo concretos (por ejemplo,el diagnostico de un determinado pacien-te con unos sıntomas especıficos), y tareas,que especifican una familia de instancias deun determinado tipo, familias que puedenser descritas a distintos grados de granula-ridad. Observese que en la definicion de latarea no se ha incluido nada de como llevara cabo la misma.

• Metodos y Subtareas. Los metodos sonlos medios que nos permiten llevar a ca-bo una tarea. Un metodo se define co-mo un conjunto de subtareas que permitenla transformacion del estado inicial de unatarea en el estado objetivo. Puede conte-ner informacion adicional relacionada conla forma en que las subtareas son ordena-das en el tiempo. Las tareas obtenidas pue-den ser aplicadas directamente o por mediode otros metodos, y por consiguiente, otrassubtareas.

• Estructuras de Tareas. La ET es unarbol de tareas, metodos y subtareas apli-cadas de forma recursiva hasta que las ta-reas que se alcancen puedan ser llevadas acabo utilizando el conocimiento del que sedispone. Esta estructura nos permite es-pecificar el hecho de que para una mismatarea se pueden utilizar mas de un metodo.

El uso de ET nos permite definir procesos derazonamiento en el nivel de conocimiento sinhacer referencia alguna a la implementacion, esdecir, el nivel simbolico. En las figuras 2-A y 2-B se pueden apreciar las ET que correspondencon la tarea de diagnostico y la de diseno.

Como conclusion podemos decir que las ET fa-cilita el modelado del conocimiento ya que per-mite asociar las tareas con los metodos quela desarrollan y el conocimiento necesario pa-ra usar dicho metodo. Otro aspecto que po-tencia el uso de las ET es el hecho de que per-mite combinar distintos tipos de metodos parallevar a cabo una tarea. Finalmente, los pro-blemas que surgıan del uso de las TG quedanresueltos, ya que mediante la definicion separa-da de los metodos y las tareas queda claro queconocimiento queda asociado a cada elemento,

Figura 2: Estructura de Tareas para el Diagnostico (A) y el Diseno (B). Los cırculos representan lastareas y los rectangulos metodos.

y gracias a la ET, queda explicitado la relacionentre subtareas y tareas. Ademas, la propiajerarquıa inherente a la ET nos permite dejarclaro a que nivel de abstraccion se define cadatarea, y consecuentemente, cuales son las tareasmas generales y cuales las mas especıficas.

La importancia de este marco de trabajo re-side en que es el primer intento serio de des-cripcion de un sistema inteligente en el nivel deconocimiento, permitiendo por tanto la defini-cion de componentes genericos que pueden ser”reutilizados”en diferentes dominios. Una delas carencias importantes de la aproximacion deChandrasekaran es que no se hace referencia enningun momento al conocimiento del dominionecesario para las tareas, ya que solo se descri-be la estructura de las tareas en el dominio. Porlo tanto, es necesario fundir esta aproximacioncon la aproximacion de McDermott para teneruna aproximacion que aborde todos los aspec-tos necesarios para modelar el conocimiento: laestructura de tareas-metodos y la funcion quejuega el conocimiento del dominio.

Aparte de las consideraciones anteriores, elunico reproche que se le puede hacer es queno se indica ninguna metodologıa que dirigie-

se el proceso de modelado, pero como veremosen las siguientes secciones, los conceptos de ta-rea, metodo y su ensamblado en una estructurade tarea-metodo-descomposicion formaron unabase lo suficientemente solida que permitio eldesarrollo de metodologıas que completasen elcamino iniciado por Chandrasekaran.

8 Metodologıas Basadas enel Modelado de Conoci-miento

Conjuntamente a los trabajos anteriormentecitados, otros investigadores realizaron tra-bajos en la misma lınea, entre los que ca-ben destacar a Clancey [Clancey, 1985] quepropuso la clasificacion heurıstica como unmetodo generico de resolucion de problemas,Friedlan [Friedland and Iwasaky, 1985] con surefinamiento de esqueletos de planes, y porultimo, los componentes de experiencia de Ste-els [Steels, 1990]. Subyacente a todos estos tra-bajos esta la conviccion de que existen patronesrecurrentes de comportamiento que los inge-

nieros del conocimiento implementan, bien ex-plıcitamente o bien implıcitamente, en sus sis-temas. Ademas, estos patrones de comporta-miento describen los requisitos de conocimientoque necesita el sistema y, por lo tanto, puedendirigir la adquisicion del mismo.

Los trabajos desarrollados en la segunda mi-tad de la decada de los ochenta, y a la vistadel trabajo de McDermott[McDermott, 1988],se englobaron dentro de los que se denominaronmetodos con limitacion de roles. Estos metodosaportaron la ventaja de que proporcionabanuna manera de clarificar el conocimiento usadoen la resolucion del problema y proporcionabanuna serie de expectativas que podıan dirigir laadquisicion del contenido del conocimiento re-querido por las aplicaciones [Musen, 1992]. Deesta forma, se podıa afirmar que si todos losroles de un metodo de resolucion de problemasestaban cubiertos en la base de conocimiento,esta esta completa, en caso contrario, dirıamosque esta incompleta (si falta algun rol por cu-brir) o sobredimensionada (si existen elementosen la base de conocimiento que no estan asocia-dos a ningun rol).

Sin embargo, los metodos con limitacion deroles presentaban dos problemas importantes.Por un lado, al asumir que el comportamientodel sistema puede ser descrito en terminos abs-tractos, es decir, sin hacer referencia a la imple-mentacion, se impide el modelado de los siste-mas en los que consideraciones especıficas sobreel dominio pueden alterar la estrategia de con-trol del sistema. Por otro lado, al ser bastantegenericos resulta difıcil aplicarlos a problemasconcretos, ya que dicha generalidad hace que lascondiciones requeridas por dichos problemas nose cumplan en el modelo generico.

Estos problemas provocaron un replanteamien-to de estado de la Ingenierıa del Conocimien-to que dio como resultado la aparicion de nue-vas metodologıas de desarrollo de SBC. Es-tas nuevas metodologıas, que se basaron enlas ideas resultantes de los trabajos anterio-res, permiten realizar el analisis del sistemaen el nivel de conocimiento, ofreciendo la po-sibilidad de especificar el problema a diferen-tes niveles de granularidad, con lo cual se po-tencia la idea de la reutilizacion de componen-tes de conocimiento. Por otro lado, estas nue-vas metodologıas ofrecen un ciclo de vida com-pleto para el proceso de desarrollo (al igual

que existe en la ingenierıa del software), pro-porcionado pautas a seguir desde el analisishasta la implementacion final del sistema. Acontinuacion ofreceremos una breve exposi-cion de las tres metodologıas mas importantes:CommonKADS [Schreiber et al., 1999], MI-KE [Angele et al., 1998] [Angele et al., 1996] yPROTEGE-II [Eriksson et al., 1995]. Finaliza-remos dicha exposicion citando un conjunto demetodologıas, que si bien no han llegado al es-tatus de las anteriores, ofrecen resultados bas-tante significativos.

8.1 CommonKADS

KADS es una metodologıa completa para eldesarrollo de SBC. Ha sido el resultado de untrabajo que ha durado aproximadamente unadecada dentro de dos proyectos SPRIT. En susinicios, KADS se centraba en el problema delcuello de botella de suponıa la adquisicion deconocimiento, para posteriormente convertirseen una metodologıa completa para el desarrollode SBC [Schreiber et al., 1993]. En la actuali-dad, CommonKADS, nombre que recibe la evo-lucion de KADS, cubre la gestion del proyecto,el analisis organizacional y los aspectos relati-vos a las Ingenierıas del Software y Conocimien-to relacionados con el desarrollo de SBC.

En CommonKADS podemos ver reflejadas tresideas que han emergido, no solo de la experien-cia en la Ingenierıa del Conocimiento, sino tam-bien del campo de la Ingenierıa del Softwareen general. Estas tres ideas se pueden concre-tar en tres conceptos: modelado, reutilizaciony gestion del riesgo.

El principal producto que resulta de la apli-cacion de CommonKADS es el conjunto demodelos. Este conjunto de modelos se pue-de considerar una agrupacion estructurada deconocimiento que refleja todos aquellos aspec-tos importantes para que el SBC tenga exitodentro de un contexto organizacional deter-minado. Para reflejar los diferentes aspec-tos del contexto en el cual se quiere implan-tar el SBC, CommonKADS ofrece seis mode-los [de Hoog et al., 1994]: organizacion, tareas,agentes, comunicacion, conocimiento y diseno.Todos estos modelos estan relacionados entre sıy pueden ser configurados gracias a unas plan-tillas que la metodologıa ofrece para su confec-cion. Los tres primeros modelos describen el

contexto en el cual se va a desenvolver el SBC.Los modelos de experiencia y agentes propor-cionan los requisitos de entrada que guiaran laimplementacion del sistema a traves del modelode diseno. Como se puede deducir, cada una deestas agrupaciones intentan responder a cadauna de las preguntas claves en el desarrollo deun SBC: ¿Es un SBC la solucion idonea para elproblema que se quiere resolver?, pregunta quese puede responder por la descripcion del con-texto dado por los tres primeros modelos; ¿Cuales la naturaleza y la estructura tanto del cono-cimiento como de la comunicacion utilizada?,cuya respuesta se puede encontrar en el modelode experiencia y en el modelo de comunicacion;y finalmente, ¿Como debe ser implementado elconocimiento?, pregunta que intenta esclarecerel modelo del diseno.

Mencion especial al modelo de conocimien-to. Este modelo, que esta descrito en[Wielinga et al., 1994], describe el conocimien-to que tiene un determinado agente y que esrelevante para la consecucion de una determi-nada tarea, ademas de describir la estructuradel mismo en funcion de su uso. Obviamente,este modelo se hace en el nivel de conocimiento,sin hacer referencia a aspectos de implementa-cion. Para poder llevar a cabo este modelado delos distintos papeles que puede jugar el conoci-miento, este esta distribuido en tres categorıasdisjuntas:

• Conocimiento de tareas. Describe deuna forma recursiva la descomposicion deuna tarea de alto nivel en varias subtareas.El conocimiento sobre una tarea se divideen dos partes: por una lado la tarea, quesirve para especificar que es lo que implicala aplicacion de la tarea ya que define suobjetivo en terminos de los roles de entraday de salida; por otro lado, esta el metodo dela tarea, que define el como se lleva a cabodicha tarea, indicando en que subtareas sedescompone y en que orden deben de serprocesadas (control).

• Conocimiento del dominio. Especificalos hechos y asunciones que necesita el pro-ceso de razonamiento para llevar a cabo sucometido en el dominio de la aplicacion. Elconocimiento del dominio puede ser estruc-turado en una serie de modelos del dominoque proporcionen una vision coherente de

las distintas partes del dominio de la apli-cacion. Por lo tanto, en este apartado seva a especificar la forma, estructura y con-tenido del conocimiento relevante para laaplicacion. La forma y la estructura cons-tituyen lo que se denomina la ontologıa deldominio.

• Conocimiento sobre inferencias. Des-cribe los procesos primitivos de razona-miento que tienen lugar en una aplicacion,ası como los roles de conocimiento que sonusados por las inferencias. Obviamente,estos roles de conocimientos estan relacio-nados con elementos del conocimiento deldominio. Hay que tener en cuenta, que lasinferencias son consideradas primitivas res-pecto a un modelo de experiencia determi-nado, ya que en otros modelos de experien-cia la misma inferencia puede ser una tareadescomponible.

Figura 3: El Modelo de Conocimiento en Com-monKADS.

CommonKADS propone el lenguajeCML (Conceptual Modelling Language)[Anjewierden, 1997], para materializar laespecificacion del modelo de conocimiento.Este lenguaje permite la definicion de todos los

elementos anteriormente citados, ası como laestructuracion del conocimiento en las partesanteriormente citadas. Ademas propone eluso de una notacion grafica, que permite nosolo la definicion de las estructuras de tareas(relacion tareas-subtareas), sino que tambienpermite la definicion de la ontologıa y losconceptos del dominio y la definicion de ladependencia de los datos entre las inferencias atraves de las estructuras de inferencias (figura3). Aparte de CML, tambien se propone el usode (ML)2 [Harmelen et al., 1991] que esta masorientado hacia la formalizacion del modelo.Esta descomposicion del nivel de conocimientoen el conocimiento especıfico del dominio porun lado, y de las tareas y las inferencias porotro, favorece la reutilizacion del conocimientoen dos niveles. Al haber definido un conjuntode inferencias elementales independientes de laaplicacion se permite que estas sean utilizadasen otros procesos de resolucion de problemas.En este sentido es importante tener en cuentael trabajo de [Aben, 1993] donde se catalogany clasifican el conjunto de inferencias basicasque pueden ser utilizadas en CommonKADS.El otro nivel de reutilizacion lo establece elconocimiento del dominio, que al ser definidoindependientemente de las tareas, puede serreutilizado por otro conjunto de tareas defini-das sobre el mismo dominio. Para favorecerla reutilizacion del conocimiento del dominioCommonKADS permite definir las ontologıasa distintos niveles de generalizacion y distintospuntos de vista, lo que abre el abanico deposibles adaptaciones a otras aplicaciones.

Otro de los aspectos importantes que introdu-jo CommonKADS fue la definicion de un mar-co de trabajo para la gestion y planificaciondel proyecto. CommonKADS define un ciclode vida para el desarrollo del proyecto basa-do en un modelo en espiral como el propuestopor [Boehm, 1988]. El modelo en espiral queplantea CommonKADS se basa en los siguien-tes principios [Schreiber et al., 1999]:

• La planificacion del proyecto se centraprincipalmente en los productos y las sali-das que tienen que producirse como resul-tado, mas que un conjunto de actividadeso fases.

• La planificacion se realiza de una formaadaptativa a lo largo de un serie de ciclos

en espiral, que estan dirigidos por una va-loracion sistematica de los riesgos del pro-yecto.

• El control de calidad es una parte mas dela gestion del proyecto, ya que la calidadesta integrada en el desarrollo del SBC pormedio de la metodologıa.

Figura 4: El Ciclo de Vida en CommonKADS.

Estos principios estan garantizados por un la-do, por el conjunto de modelos, y por otro, porel ciclo de vida en espiral. Este ciclo de vidaconsta de cuatro fases (figura 4):

• Revision. Es el primer paso de cada ci-clo y en el se revisa el estado actual delproyecto y se establecen los objetivos prin-cipales que se quieren cubrir en el ciclo encuestion.

• Valoracion de riesgos. Las lıneas gene-rales del proyecto establecidas en el pasoanterior sirven de entradas para esta fase.Su funcion principal es la identificacion yvaloracion de los principales obstaculos quenos podemos encontrar para la consecucionexitosa del proyecto, ası como las accionesque se deben tomar para minimizar dichosriesgos.

• Planificacion. Una vez obtenida una vi-sion clara de los objetivos que hay que cu-brir, los riesgos que se pueden presentary las acciones que hay que tomar, hay querealizar una planificacion del trabajo a rea-lizar. En dicha planificacion hay que esta-blecer la distribucion de la carga del traba-jo en terminos de que tareas hay que reali-

zar, una temporalizacion de dichas tareas,la distribucion de los recursos, etc.

• Monitorizacion. Es la ultima fase delciclo y esta constituida por el desarrollopropiamente dicho. El trabajo realizadoen esta fase esta controlado y dirigido porel director del proyecto. Para determinarel grado de cumplimiento de los objetivosse requieren reuniones con los agentes im-plicados en el proyecto (usuarios, adminis-tradores, expertos, ..). El resultado de di-chas reuniones se utilizara como entradadel proceso de revision del siguiente ciclo.

Como se puede observar, la metodologıa Com-monKADS abarca todo los aspectos del des-arrollo de un SBC, desde los analisis inicialesque sirven para identificar problemas y para es-tablecer la idoneidad de la solucion basada enun SBC, hasta la implementacion del mismo,proporcionando un marco de trabajo donde lle-var a cabo la gestion del proyecto. Tambien hayque resaltar que el modelado del conocimientoposibilita la definicion de componentes reutili-zables, tanto en el nivel de tareas como en el deconceptualizacion del dominio, como resultadode la agrupacion de las ideas que surgieron des-pues del trabajo de Newell [Newell, 1982]. Todoesto hace que CommonKADS haya sido adop-tado no solo en Europa, donde se ha convertidoen un estandar de facto, sino que tambien em-pieza a ser utilizado en el resto del mudo.

8.2 MIKE

MIKE (Model-based and Incremental kno-wledge Engineering) [Angele et al., 1998][Angele et al., 1996] proporciona una metodo-logıa para el desarrollo de SBC que cubre todoslos aspectos del proceso, desde la adquisicionde conocimiento hasta su diseno e implemen-tacion. Al igual que CommonKADS, MIKEse desarrolla por medio de un ciclo de vida enespiral, al que se le han anadido determinadoselementos que permiten unir el prototipadocon un proceso de desarrollo incremental ysostenible dentro del paradigma del modelado.

El proceso de desarrollo se puede resumir encuatro fases aplicadas de forma cıclica: adqui-sicion de conocimiento, diseno, implementacion

y evaluacion. Una de las aportaciones princi-pales de esta metodologıa es la de detallar elproceso a realizar en cada una de las fases (fi-gura 5), poniendo especial hincapie en la fasede adquisicion.

De esta forma, la fase de adquisicion empiezacon la extraccion de conocimiento, con la que seobtienen descripciones informales sobre el co-nocimiento del dominio y del proceso de reso-lucion. La extraccion de dichas descripcionespuede realizarse a traves de entrevistas estruc-turadas con los expertos. El resultado de estafase se resume en el modelo de elicitacion, cons-tituidos por los protocolos de conocimiento quequedan almacenados en los nodos-protocolos, endonde la informacion es almacenada en lengua-je natural. En la metodologıa se propone parala creacion de este modelo semiformal, el usode un sistema hipermedia como MEMO (Me-diating Model Organization) [Neubert, 1993].

Una vez terminada la fase de extraccion se en-tra en la interpretacion. En esta fase, todaslas estructuras identificadas en la fase anteriorpasan a ser descritas en un lenguaje mas fijoy restringido. Esta nueva representacion reco-ge mas formalmente toda la informacion sobrela estructura, es decir, la dependencia entre losdatos y las inferencias, dejando la descripcionde las inferencias en lenguaje natural. Todaesta informacion queda recogida en el modelode estructura, que es el resultado de esta fase.Este modelo informal esta compuesto de varioscontextos:

• Contexto de actividad. Esta formadopor todos los nodos de actividad, que re-presentan un paso dentro del proceso deresolucion. Junto a estos nodos de activi-dad se colocan los nodos de refinamiento,que indican la descomposicion estructuralde una actividad determinada. Como po-demos ver, este contexto refleja la descom-posicion jerarquica de tareas que existe enel dominio. El contenido de cada nodo ac-tividad se corresponde con una descripcioninformal de la especificacion de la activi-dad.

• Contexto de ordenacion. Sirve para in-dicar como quedan relacionadas las acti-vidades por medio de la especificacion delcontrol necesario para llevarla a cabo.

Figura 5: Fases en el Ciclo de Vida en MIKE.

• Contexto de conceptos. Esta forma-do por nodos que representan los con-ceptos del dominio y, por lo tanto, des-criben la estructura estatica del mismo.En este modelo se incluyen enlaces en-tre los nodos que sirven para indicar co-mo dichos conceptos estan organizados me-diante asociacion, agregacion y generaliza-cion. En este contexto se propone utili-zar un notacion grafica derivada de OMT[Rumbaugh et al., 1991].

• Contexto de flujo de datos. Presentauna vision del domino en un nivel concre-to de la jerarquıa de actividades. En estavision, los nodos-actividad se enlazan conlos nodos-conceptos mediante los enlacesde flujo de datos.

• Contexto de requisitos no funciona-les. Se utiliza para describir cuales son losrequisitos no funcionales (de mantenibili-dad y eficiencia) que debe cumplir el siste-ma.

El modelo de estructura recoge, de esta forma,todos los aspectos funcionales y no funcionalesdel dominio. Este modelo, junto con el de elici-tacion, forman las bases para establecer la co-municacion entre el experto y el ingeniero delconocimiento, pudiendo incorporar al expertoen el proceso de construccion y evaluacion delmodelo. Ademas, todos los elementos del mo-delo de estructura estan enlazados con sus co-rrespondientes partes del modelo de elicitacionpor medio de enlaces de elicitacion, permitien-

do el seguimiento de la evolucion de los mode-los. Como se puede observar se sigue mante-niendo el principio de separacion entre el co-nocimiento del dominio y las tareas del que sedesarrollan en el mismo.

Una vez construido el modelo de estructura, seentra en la fase de formalizacion y operacionali-zacion. En esta fase, se intenta crear un mode-lo mas formal que el de estructura mediante lautilizacion de un lenguaje formal, KARL (Kno-wledge Acquisition Representation Languaje)[Fensel, 1995]. La caracterıstica principal de es-te lenguaje es que combina la descripcion con-ceptual de un SBC con una especificacion for-mal y ejecutable. De esta forma, se pueden es-pecificar formalmente, eliminado cualquier va-guedad e imprecision, las inferencias detectadasen la fase anterior. Al igual que ocurre en losmodelos anteriores, los elementos de este mode-lo se asocian mediante enlaces de formalizacioncon los elementos correspondientes en el mo-delo de estructura. El hecho de que el mode-lo resultante, el modelo KARL¸ sea ejecutable(bajo ciertas restricciones), permite una evalua-cion del modelo por parte del experto. Con laobtencion del modelo KARL, termina la fase deadquisicion del conocimiento quedando identi-ficados, no solo la estructura del dominio, sinotambien los requisitos funcionales y no funcio-nales.

El modelo formal representado en el modeloKARL es la entrada de la siguiente fase, el di-seno. En esta fase se consideran los requisi-

Figura 6: Ciclo de Vida en MIKE.

tos no funcionales (mantenibilidad, eficiencia yrestricciones impuestas por la plataforma hard-ware y software elegida) y se genera un nue-vo modelo mas detallado, el modelo del di-seno, especificado en el lenguaje DesignKARL[Landes, 1994], que es una extension de KARLa la que se le anade la capacidad de expresaralgoritmos y estructuras de datos. Esta faseequivale a lo que en la Ingenierıa del Softwarese realiza mediante el diseno detallado. Una vezobtenido el modelo del diseno, se pasa a la fasede implementacion, en la que se materializa enla plataforma hardware y software elegida. Porultimo, la ultima fase del proceso de desarrollotermina con la evaluacion, en la que se vuelvea requerir la intervencion del experto.

Como ya hemos mencionado, todos estos pasosson realizados de una forma cıclica, basada enel modelo en espiral de Boehm [Boehm, 1988].De esta forma, los resultados de la evaluacionsirven de entrada para la depuracion de los mo-delos en una nueva fase de adquisicion de cono-cimiento. Sin embargo, MIKE aporta una mo-dificacion al metodo clasico de Boehm, ya quelas subfases en las que se dividen algunas de lasfases anteriores se realizan tambien siguiendoun modelo en espiral (figura 6).

Como podemos ver, MIKE es una potente me-todologıa que integra formalismos de represen-tacion informales y formales con un desarro-llo por prototipado. Comparada con Common-KADS, se puede decir que MIKE ofrece unaforma sencilla de transicion entre el resultadode la adquisicion de conocimiento, el modelo deconocimiento y el modelo de diseno, a diferencia

de CommonKADS donde estas transiciones noestan lo suficientemente especificadas. Sin em-bargo, a favor de CommonKADS hay que decirque ofrece soporte para un analisis de contextomas amplio, permitiendo evaluar el impacto dela utilizacion de un SBC en una gran organiza-cion. Este analisis de contexto, no esta tratadoen MIKE, que solo se centra en el desarrollo delmodelo de conocimiento, aunque es uno de loscaminos en los que se esta trabajando.

8.3 Protege-II

PROTEGE-II [Puerta et al., 1992][Eriksson et al., 1995] [Tu et al., 1995] fueel resultado de un proyecto cuyo principal ob-jetivo era resolver las limitaciones del trabajorealizado en la construccion de la herramientaPROTEGE [Musen, 1989a] [Musen, 1989b].PROTEGE es una metaherramienta quepermite a los desarrolladores generar herra-mientas para la adquisicion de conocimientopara distintos dominios de aplicacion, peroque se basen en la utilizacion del metodo deresolucion de problemas con limitacion deroles denominado refinamiento de patrones deplanes episodicos. El uso de un solo metodode resolucion de problemas hacıa imposibleabordar problemas que no pudieran ser re-sueltos por dicho metodo. Para resolver estaslimitaciones se desarrolla PROTEGE-II, queesta disenada para soportar una Ingenierıa delConocimiento orientada a tareas mas generalque PROTEGE. PROTEGE-II proporcionaun entorno para Ingenierıa de Conocimientoen el que el desarrollador puede especificartareas, y puede seleccionar metodos de resolu-cion de una librerıa de metodos reutilizables.Para permitir el modelado, se distinguen lossiguientes elementos:

• Tareas. Es un problema en el mundo real,localizado dentro de una organizacion (ta-rea aplicacion), o una especificacion abs-tracta de objetivos independientes del do-minio que tienen que ser alcanzados (cla-ses de tareas, o tarea). La descripcion deuna tarea es una especificacion abstractadel problema que tiene que ser resuelto porel metodo. Debe incluir definiciones abs-tractas de los datos disponibles (entradas)y de las solucion (salida) y las relacionesque se deben mantener entre ellos. Aun-

que en la especificacion de una tarea no seindica como se resuelve, esta condiciona laseleccion del metodo para su resolucion.

• Metodo. Un metodo es un modelo inde-pendiente del dominio, que indica como seresuelve el problema especificado por la ta-rea. Ademas de la especificacion de la en-trada y la salida de la tarea, el metodo po-see una definicion abstracta de los roles quejuega el conocimiento del dominio en la re-solucion del problema. La seleccion de unmetodo depende de factores que van masalla de la especificacion de la tarea, comola disponibilidad de la experiencia, requisi-tos de espacio y tiempo de computacion, yla compatibilidad con el resto de metodosque cooperan en la resolucion del proble-ma. Los metodos pueden delegar proble-mas a subtareas que, a su vez, pueden serresueltas por otros metodos, formando unarbol de tareas-metodos-subtareas.

• Mecanismos. Los mecanismos se puedenconsiderar como metodos primitivos queno pueden ser descompuestos en otras sub-tareas. Por lo tanto, pueden ser conside-rados como cajas negras que no admitendescomposicion.

Como se puede deducir, estos elementos se ase-mejan mucho a las estructuras de tareas pro-puestas por Chandrasekaran, ya que disponende tareas que pueden ser resueltas por diferen-tes metodos, que a su vez pueden delegar enotras subtareas que pueden ser descompuestas.Esta descomposicion termina cuando se alcan-zan los mecanismos. Esta estrategia de des-composicion ayuda a la reutilizacion de compo-nentes de dos formas: por un lado, los meca-nismos, al desarrollar funciones muy definidas,pueden ser aplicables a varios dominios (comolas inferencias en CommonKADS); y por otro,la existencia de metodos descomponibles hacemas flexible la reutilizacion de conocimiento, yaque permiten la utilizacion de metodos y me-canismos alternativos para la resolucion de sussubtareas.

Ademas de estos elementos relacionados con laestructura de tareas-metodos, en PROTEGE-IIse distinguen distintos tipos de ontologıas. Laontologıa del dominio incluye una descripciondeclarativa del dominio, y representa la con-ceptualizacion del dominio de la aplicacion. La

ontologıa de los metodos define los conceptos yrelaciones que utilizan los metodos, y sirve demarco para especificar sus entradas y salidas.Estas ontologıas de los metodos se correspon-den con la terminologıa generica utilizada porel conjunto de roles del metodo. Para que losmetodos de resolucion de problemas puedan serreutilizables por diferentes dominios, deben serdefinidos en terminos independientes del domi-nio. De la misma forma, para que las ontologıasque definen los terminos y relaciones de un de-terminado area de aplicacion puedan ser reuti-lizadas por diferentes tareas y metodos, debende ser definidas de forma independiente de losmetodos de resolucion. Estos requisitos de re-utilizacion pueden provocar la aparicion de di-ferencias entre la ontologıa del metodo y la deldominio en el que se va a utilizar dicho metodo.Para poder tratar con este problema de la in-teraccion entre estas ontologıas, PROTEGE-IIintroduce el concepto de ontologıa de la aplica-cion, que sirve para extender la ontologıa deldominio con conceptos y relaciones propios dela ontologıa del metodos. De todas formas, aun-que se haya definido una ontologıa intermediaentre el metodo y el dominio, todavıa puedenaparecer problemas cuando se intenta adaptaruna ontologıa de la aplicacion con la correspon-diente al metodo elegido. Estos problemas pue-den ser:

• Diferencias terminologicas, que ocu-rren cuando los mismos terminos y rela-ciones reciben distintos nombres en las dosontologıas. Para solventar este problema,PROTEGE-II permite definir correspon-dencias de renombrado, que se utilizan pa-ra establecer la traduccion de terminos.

• Diferencias semanticas, ocurren cuan-do el concepto de partida resulta de unatransformacion semantica del concepto quele corresponde (por ejemplo, la temperatu-ra definida en grados Celsius o en gradosFarenheit). La solucion de este problemapasa por definir correspondencias de filtra-do.

• Diferencias representacionales. Es ladiferencia mas compleja que se puede pre-sentar en la estructura de una ontologıa.Esta aparece cuando un concepto esta de-finido en una ontologıa por medio de unconjunto de parametros con sus valores, y

otra ontologıa representa el mismo concep-to por medio de una jerarquıa de subcon-ceptos.

Por lo tanto, y partiendo de la base de quePROTEGE-II tiene una librerıa de metodosgenericos, la construccion de un modelo de co-nocimiento se puede hacer en tres pasos: (1)formulacion de la ontologıa del metodo, inclu-yendo el conjunto de roles de conocimiento queutiliza, (2) definicion de la ontologıa de la apli-cacion independientemente de la del metodo yreutilizando alguna ontologıa del dominio pre-viamente definida, y (3) formulacion de las re-laciones de correspondencia entre las dos onto-logıas (aplicacion y metodo). En la figura 7 sepuede ver de forma esquematica las relacionesentre las distintas ontologıas.

Aparte de la definicion de nuevos modelos porreutilizacion, una de las caracterısticas impor-tantes de PROTEGE-II es que facilita la ge-neracion de herramientas para la adquisicionde conocimiento de forma independiente de losmetodos que se vayan a utilizar. La genera-cion de la herramienta de adquisicion de cono-cimiento se hace de manera grafica y dirigidapor la ontologıa del dominio. En PROTEGE-II se propone un analisis de la adquisicion deconocimiento que presenta las siguientes fases:

1. Identificacion de los usuarios potencialesde la herramienta de adquisicion.

2. Segmentacion de la base de conocimientoy determinacion de que parte va a ser ad-quirida por la herramienta.

3. Definicion de un lenguaje en el que expre-sar el conocimiento (puede ser un lenguajegrafico).

4. Especificacion de la semantica para dicholenguaje, ademas de las semantica denota-cional que describe la generacion de la basede conocimiento.

De esta forma, el analisis de la adquisicion deconocimiento se considera una fase mas en eldesarrollo de una herramienta de adquisicion deconocimiento, que una vez terminada, permi-te el desarrollo de la herramienta, proceso quepuede ser simplificado gracias a PROTEGE-II.

Figura 7: Distintas Ontologıas en PROTEGE-II y sus relaciones.

Como se ha descrito, PROTEGE-II define unmarco que permite la definicion de nuevos mo-delos de conocimiento por reutilizacion de com-ponentes definidos en una librerıa. Este nuevomodelo puede ser creado por reconfiguracion dealguno de los componentes de la librerıa o porcombinacion de varios componentes de la mis-ma. La diferencia principal de esta aproxima-cion con otras basadas en la reutilizacion, esque esta orientada a la minimizacion del costede programacion, a diferencia de otras aproxi-maciones como puede ser la de los componentesde experiencia [Steels, 1990]. Sin embargo, unade las debilidades mas importantes es que noaporta la definicion de un ciclo de vida com-pleto para el desarrollo de aplicaciones al estarmas centrado en la fase de adquisicion de co-nocimiento. Esta falta de definicion de un ciclode vida trae consigo un problema importante,y es que al carecer de un analisis de contexto,se complica el uso de la herramienta para gran-des aplicaciones que tengan que trabajar en unentorno determinado.

9 Otras Metodologıas

Aunque las anteriores metodologıas han sido lasque mas difusion han tenido, existen bastantestrabajos que han dado lugar a metodologıas o

marcos de trabajo que han intentado cubrir as-pectos concretos de los entornos donde fuerondesarrolladas, mostrando su utilidad en bastan-tes aplicaciones, pero que de algun modo hansido oscurecidas por los resultados y aceptacionde las anteriores. En los siguientes parrafos da-remos una breve descripcion de este conjuntode trabajos.

Una de las metodologıas mas intere-santes es VITAL [Shadbolt et al., 1993][Domingue et al., 1993] que al igual que Com-monKADS se desarrollo con la colaboracion devarias empresas y bajo un proyecto ESPRIT.Al igual que CommonKADS se basa en laidea de que el desarrollo de un SBC se vefavorecido por la adopcion de una metodologıade desarrollo estructurada. Esta metodologıaproduce cuatro productos como resultado desu aplicacion: Especificacion de requisitos,donde se describe la funcionalidad que seesperan del SBC final; Modelo Conceptual,equivalente al modelo de experiencia propuestoen CommonKADS; Modelo de Diseno, basadoen la idea de MIKE en el sentido de quese describe en dos fases: Modelo de disenofuncional, independiente de la implementacion,y Modelo de diseno tecnico, que dependede la implementacion; por ultimo, el CodigoEjecutable, que engloba todo los componentessoftware que pueden ser objeto de un manteni-miento posterior. Todo estos productos estandirigidos por una metodologıa para la direcciondel proyecto que especifica el ciclo de vida delmismo. Otro aspecto importante es que, aligual que MIKE, ofrece lenguajes formales einformales para representar los distintos nivelesde especificacion que podemos encontrarnosen el nivel de conocimiento. Por lo tanto,esta metodologıa que ofrece un ciclo de vidaestructurado para la direccion del proyectoque facilita el mantenimiento, depuracion yreutilizacion de los productos obtenidos.

KSM [Cuena and Molina, 1994][Cuena and Molina, 1997] es otro trabajoque propone un entorno software para ayudara la construccion, operacionalizacion y reuti-lizacion de modelos de conocimiento. Paradefinir un modelo hay que hacerlo desde tresperspectivas: (1) la perspectiva del area deconocimiento, que es un descripcion modularde las ontologıas implicadas en el modelo, (2)la perspectiva de tareas, similar a la capa detareas de CommonKADS y (3) la perspectiva

del vocabulario, que engloba los terminosbasicos que son compartidos por otros modulosde conocimiento. Al igual que CommonKADSy PROTEGE-II, KSM proporciona elementoscomputables que implementan los mecanismosbasicos de resolucion de problemas, que sedenominan primitivas de representacion. Deesta forma, se ofrece una forma sencilla deoperacionalizar el modelo en el nivel de cono-cimiento, ya que solo harıa falta asociar lasprimitivas de representacion con sus respec-tivas areas de conocimiento. Sin embargo, aligual que en VITAL, no existe un analisis decontexto, ademas de no ofrecer directrices parala direccion del proyecto.

Otras aproximaciones que han tenido ciertadifusion son: DESIRE (framework for DEs-ign and Specification of Interacting REasoningcomponents) [Brazier et al., 1997] mas orienta-da hacia los sistemas multiagentes proporcio-nando modelos genericos reutilizables para de-terminados tipos de aplicaciones multiagentesy que permiten su implantacion de diferentesdominios. Incluye tecnicas de verificacion y va-lidacion para las propiedades estaticas de sis-temas que desarrollan razonamientos comple-jos. COMMET (The COMponential METho-dology) [Steels, 1993] es un entorno de trabajoque soporta el desarrollo de SBC en tres nive-les: nivel de conocimiento, nivel de ejecucion ynivel de codigo ofreciendo posibilidad de reuti-lizar componentes en cada uno de los niveles.

Se pueden citar mas marcos de trabajo, perocomo podemos observar no aparecen aportacio-nes importantes que no hayan sido abordadaspor otras metodologıas. De todas formas, estapequeno barrido puede servir para resaltar laimportancia que esta adquiriendo la Ingenierıadel Conocimiento y que esta tomando cuerpode verdadera ingenierıa, ya que tiene metodo-logıas de trabajo estructuradas y bien definidasque han sido aplicadas a numerosos problemasreales con exito.

10 Conclusiones

Como podemos observar a traves de esteanalisis historico, la Ingenierıa del Conocimien-to ha alcanzado la madurez necesaria como paraque las metodologıas planteadas sean utilizadasa nivel industrial. Sin embargo, a pesar de los

cambios en los paradigmas sobre los que se hansustentado todas las metodologıas, existen dosaspectos comunes a todas ellas:

• Todas las metodologıas consideran suma-mente importante el analisis de viabilidadde la aplicacion, entendido este dentro deun contexto organizacional que va mas alladel sistema objeto del desarrollo.

• La propia naturaleza de los SBC (el motorde inferencia separado de la base de cono-cimiento) hace que todas las metodologıasplanteen la fase de desarrollo siguiendo unmodelo de desarrollo incremental, en el quese hace especial hincapie en la extensiongradual de la base de conocimiento.

Partiendo de estos dos aspectos comunes, lasdistintas metodologıas han ido adaptandose ala evolucion que se ha ido produciendo en elcampo de la ingenierıa del software. Ası, aligual que en la Ingenierıa del Software, la In-genierıa del Conocimiento ha pasado desde elmodelo clasico de cascada al modelo de ci-clo de vida en espiral apoyado en la gestionde riesgos. Tambien se puede apreciar comouna de las principales ventajas que aportaronlas tecnicas orientadas a objetos en la Inge-nierıa del Software, como es el hecho de lareduccion del salto semantico entre el disenodel sistema y su implementacion, permitien-do que las estructuras se mantengan a lo lar-go del proceso de desarrollo, tambien se hayatrasladado a la Ingenierıa del Conocimiento enaspectos tales como el paradigma del modela-do y metodologıas que se basan en un disenoque preserve la estructura por medio de la re-utilizacion [Benjamins and Aben, 1997]. Estaaproximacion de estas dos disciplinas ha lle-vado a que la metodologıa mas extendida enla Ingenierıa del Conocimiento CommonKADS[Schreiber et al., 1999] utilice UML (UnifiedModeling Language [Booch et al., 1997]) parala notacion grafica de varios de sus mode-los. Sin embargo, la utilizacion a nivel in-dustrial de las metodologıas ha puesto de ma-nifiesto ciertas carencias que empiezan a sersubsanadas a traves de distintas extensiones.Entre estas extensiones podemos citar RT-CommonKADS [Palma-Mendez, 1999], en laque se incorporan elementos que hacen posi-ble el modelado de ciertas caracterısticas pro-pias de los dominios con una fuerte compo-

nente de tiempo real, y MASCommonKADS[Iglesias-Fernandez, 1997], en la cual se planteala metodologıas desde un punto de vista masorientado hacia el modelado de agentes.

Sin embargo, en la actualidad estamos vi-viendo un nuevo auge en la disciplina de laIngenierıa del conocimiento. Este auge esdebido principalmente a dos causas: el impulsoque han sufrido los Sistemas Multiagentes yla Gestion del Conocimiento. La primera deestas causas obedece a la respuesta que intentadar la Ingenierıa del Conocimiento al nuevoparadigma que se abre en la Ingenierıa delSoftware, el Analisis Orientado a Agentes.En este sentido, podemos encontrar un buennumero de propuestas, que surgiendo delarea de la Ingenierıa del Conocimiento se hanorientado mas al modelado de sistemas multia-gentes. Entre estas propuestas podemos citar:ARCHON [Cockburn and Jennings, 1996],aplicada a sistemas industriales, DES-IRE [Brazier et al., 1997], MADE[O’Hare and Wooldridge, 1992] o ADEPT[Jennings et al., 1996], aplicada a procesosde gestion de negocio, basada en GRATE[Jennings et al., 1992].

El otro aspecto que ha influido en este nue-vo impulso a la Ingenierıa del Conocimientoes la Gestion de Conocimiento, entendida estacomo ”el conjunto de procedimientos, reglas ysistemas destinados a captar, tratar, recuperar,presentar y transmitir los datos, informacionesy conocimientos dentro de una organizacion.”[Maestre-Yenes, 2000]. Al ser el conocimien-to el principal elemento, cualquier intento deimplantar una polıtica de Gestion de Conoci-miento en una organizacion tiene que pasar poruna fase de identificacion del mismo. Es en estepunto donde se encuentran las dos disciplinas, ydonde la experiencia adquirida a lo largo de losanos por la Ingenierıa del Conocimiento ha sidode gran ayuda. Como ejemplo de esta sinergiatenemos los modelos de organizacion, agentes ytareas de CommonKADS que pueden ser utili-zados como punto de partida para la Gestionde Conocimiento [Schreiber et al., 1999].

Como podemos ver, la Ingenierıa del Conoci-miento es un area en continua expansion, queno solo se centra en el desarrollo de SBC sinoque abarca otras areas como el Modelado desistemas Multiagentes y la Gestion del Conoci-miento. Sin embargo, todavıa existen aspectos

que no estan lo suficientemente explotados y ra-cionalizados como es el paso del diseno o modeloa la implementacion, campo que esta totalmen-te abierto y en el que los Ingenieros del Softwaretienen mucho que decir.

Referencias

[Aben, 1993] M. Aben. CommonKADS infe-rences. Technical Report ESPRIT ProjectP5248 KADS-II/M2/TR/UvA/041/1.0, Un-viersity of Amsterdam, June 1993.

[Alonso et al., 1995] F. Alonso, N. Juristo,J. L. Mate, and J. Pazos. Trends in life-cycle models for SE and KE: Proposal fora spiral-conical life-cycle approach. Interna-tional Journal of Software Engineering andKnowledge Engineering., 5(3):445–465, 1995.

[Angele et al., 1996] J. Angele, D. Fensel, andR. Studer. Domain and task modelling inMIKE. In A. Sutchliffe, editor, Domain Kno-wledge for Interactive System Design. Chap-man & Hall, 1996.

[Angele et al., 1998] J. Angele, S. Decker,R. Perkuhn, and R. Studer. Develo-ping knowledge-based systems with MIKE.Journal of Automated Software Engineering,5(4):326–389, 1998.

[Anjewierden, 1997] A. Anjewier-den. CML2. Technical Re-port 11, University of Amsterdam,http://www.swi.psy.uva.nl/usr/anjo/cml2,1997.

[Benjamins and Aben, 1997] R. Benjaminsand M. Aben. Structure-preservingknowledge-based system developmentthrough reusable libraries: A case studyin diagnosis. International Journal ofHuman-Computer Studies, 47:259–258,1997.

[Boehm, 1988] B. W. Boehm. A spiral modelof software development and enhancement.IEEE Computer, pages 61–72, May 1988.

[Bonissone and Johnson, 1983] P. P. Bonissoneand H. E. Johnson. Expert system for dieselelectric automotive repair. Technical report,General Electrics Co., 1983.

[Booch et al., 1997] G. Booch, I. Jacobson,and J. Rumbagh. The UML specifica-tion documents. Technical report, Ra-tional Software Corp., Santa Clara. CA,http://www.rational.com, 1997.

[Brazier et al., 1997] F. M. T. Brazier,B. Dunin-Keplicz, N. Jennings, and J. Treur.DESIRE: Modelling multi-agent systems ina compositional formal framework. Interna-tional Journal of Cooperative InformationSystems, 6:67–94, 1997.

[Buchanan et al., 1983] B. G. Buchanan,R. Barstow, R. Bechtal, J. Bennet, W. Clan-cey, C. Kulikowsky, T. Mitchell, and D. A.Waterman. Constructing an expert sys-tem. In F. Hayes-Roth, D. A. Waterman,and D. B. Lenat, editors, Building ExpertSystems, pages 127–167. Addison Wesley,1983.

[Chandrasekaran and Johnson, 1993] B. Chan-drasekaran and T. R. Johnson. Generic tas-ks and task structures: History, critique andnew directions. In J. M. David, J. P. Krivine,and R. Simmons, editors, Second Generationof Expert Systems, pages 222–272. Springer-Verlag, 1993.

[Chandrasekaran and Mittal, 1983] B. Chan-drasekaran and S. Mittal. Conceptualrepresentation of medical knowledge fordiagnosis by computer: Mdx and relatedsystems. In M. Yovits, editor, Advances inComputers, pages 271–293. Academic Press,1983.

[Chandrasekaran et al., 1979] B. Chandraseka-ran, F. Gomez, S. Mittal, and J. Smith. Anapproach to medical diagnosis based on con-ceptual structures. In Proc. of the 6th IJCAI,pages 134–142, Tokio, Japan, 1979.

[Chandrasekaran et al., 1992] B. Chandraseka-ran, T. R. Johnson, and J. W. Smith. Taskstructure analysis for knowledge modeling.Communications fo the ACM, 35(9):124–137,1992.

[Chandrasekaran, 1983] B. Chandrasekaran.Towards a taxonomy of problem solvingtypes. AI Magazine, 4(1):9–17, 1983.

[Chandrasekaran, 1986] B. Chandrasekaran.Generic tasks in knowledge-based reasoning:High-level building blocks for system desing.IEEE Expert, 1(3):23–30, 1986.

[Clancey, 193] W. J. Clancey. GUIDON. Jour-nal of Computer-Based Instruction, 10(1-2):8–15, 193.

[Clancey, 1979] W. J. Clancey. Tutoring ru-les for guiding a case method dialogue. In-tenational Journal of Man-Machine Studies,11(1):25–49, 1979.

[Clancey, 1985] W. J. Clancey. Heuristic cals-sification. Artificial Intelligence, 27:289–350,1985.

[Cockburn and Jennings, 1996] D. Cockburnand N. R. Jennings. ARCHON: A dis-trubuted artificial intelligence system forindustrial applications. In G.. M. P. O’Hareand N. R. Jennings, editors, Foundationsof Distributed Artificial Intelligence, pages319–344. John Willey and Sons, 1996.

[Cuena and Molina, 1994] J. Cuena andM. Molina. KSM: An environment forknowledge oriented design of applicationsusing structured knowledge architectures.In K. Brunnstein and E. Raubold, editors,Applications and Impacts. InformationProcessing’94, volume 2. Elsevier Science(North Holland), 1994.

[Cuena and Molina, 1997] J. Cuena andM. Molina. KSM; an environment for designstructured knowledge models. In Tzafestas,editor, Knowledge-Based Systems: AdvancedConcepts, Techniques and Applications.World Sicientific Publishing Company, 1997.

[de Hoog et al., 1994] R. de Hoog, R. Marti-lo, B. Wielinga, R. Taylor, C. Bright, andW. Van de Velde. The CommonKADS mo-del set. Technical Report ESPRIT ProjectP5248 KADS-II/M1/DM.1b/UvA/018/6.0,University of Amsterdam and Lloyd’s Regis-ter and Touche Ross Management Consul-tans and Free University of Brussels, June1994.

[Domingue et al., 1993] J. Domingue, E. Mot-ta, and S. Watt. The emerging VITAL wor-kbench. In Proceedings of the 7th EuropeanKnowledge Acquisition for Knowledge-BasedSystems EKAW’93, pages 320–339, 1993.

[Duda et al., 1978] R. Duda, P. E. Hart, N. J.Nilsson, R. Reboh, J. Slocum, and G. Suther-land. Development of the PROSPECTORconsultation system for mineral explotation.

Technical report, Stanford Research Institu-te, 1978.

[Eriksson et al., 1995] H. Eriksson, T. Shahar,S. W. Tu, A. R. Puerta, and M. A. Mu-sen. Task modelling with reusable problem-solving methods. Artificial Intelligence,79(2):293–326, 1995.

[Eshelman et al., 1993] L. Eshelman, D. Ehret,J. McDermott, and M. Tan. Mole: A tena-cious knowledge-acquisition tool. In B. G.Buchanan and D. C. Wilkins, editors, Re-adings in Knowledge Acquisition and Lear-ning: Automating the Construction and Im-provement of Expert Systems, pages 253–259.Kaufmann, San Mateo, CA, 1993.

[Fensel, 1995] D. Fensel. The Knowledge Acqui-sition and Representation Language KARL.Kluwer Academic Press, 1995.

[Fikes and Nilsson, 1971] R. Fikes and N.Nils-son. STRIPS: A new approach to the applica-tion of theorem proving to problem solving.Artificial Intelligence, 2(3/4):189–208, 1971.

[Fox and Iwasaky, 1984] M. S. Fox and Y. Iwa-saky. ISIS: A knowledge-based system forfactory scheduling. Expert Systems, 1(1):25–49, 1984.

[Friedland and Iwasaky, 1985] P. Friedlandand Y. Iwasaky. The concept and imple-mentation of skeletal plans. Journal ofAutomated Reasoning, 1:161–208, 1985.

[Gomez and Chandrasekaran, 1981] F. Gomezand B. Chandrasekaran. Knowledge organi-sation and distribution for medical diagno-sis. IEEE Transactions on Systems, Man andCybernetics, 11(1):34–42, 1981.

[Gonzalez et al., 1986] A. J. Gonzalez, R. L.Osborne, C. Kemper, and S. Lowenfeld. On-line diagnosis of turbine generators using ar-tificial intelligence. IEEE Transaction onEnergy Conversion, 1(2):68–74, 1986.

[Guida and Tasso, 1994] G. Guida and C. Tas-so. Design and Development of Knowledge-Based Systems. From Life Cycle to Metho-dology. John Wiley and Sons Ltd., BaffinsLane, Chichester, England, 1994.

[Harmelen et al., 1991] F. Van Harmelen,J. R. Balder, M. Aben, and J. M. Akker-mans. (ml)2: A formal language for

KADS conceptual models. TechnicalReport ESPRIT Project P5248 KADS-II/T1.2/TR/ECN/006/1.0, NetherlandsEnergy Research Centre ECN and Univer-sity of Amsterdam, June 1991.

[Heckerman and Horovitz, 1986] D. Hec-kerman and E. Horovitz. The myth ofmodularity in rule-based systems. Technicalreport, Standford University, 1986.

[Holland et al., 1984] J. D. Holland, E. L. Hut-chings, and L. Weitzman. An interactive, ins-pectable, simulation-based training system.AI Magazine, 5(2):15–27, 1984.

[IEEE, 1999] IEEE. IEEE Standards Soft-ware Engineering. Customer and Termino-logy Standards, volume 1. IEEE, 1999.

[Iglesias-Fernandez, 1997] Carlos A. Iglesias-Fernandez. Definicion de Una MetodologıaPara el Desarrollo de Sistemas Multiagentes.PhD thesis, Dpto. de Ingenierıa de SistemasTelematicos, Universidad Politecnica de Ma-drid, 1997.

[Jennings et al., 1992] N. R. Jennings, E. H.Mamdani, I. Laresgoiti, J. Perez, and J. Co-rera. GRATE: A general framework for co-operative problem solving. Journal of In-telligent Systems Engineering, 1(2):102–114,1992.

[Jennings et al., 1996] N. R. Jennings, P. Fara-tin, T. J. Norman, P. O’Brien, M. E. Wie-gand, C. Voudouris, J. L. Alty, T. Miah, andE. H. Mamdani. ADEPT: Managing businessprocesses using intelligent agents. In Proce-edings of the BCS Expert Systems 96 Con-ference ISIP Track, pages 5–23, Cambridge,UK, 1996.

[Kahn, 1994] A. F. Kahn. Managingknowledge-based systems developmentusing standard life-cycle techniques. InE. Turban and J. Liebowitz, editors, Ma-naging Expert Systems, pages 120–160. IdeaGroup Publishing, 1994.

[Landes, 1994] D. Landes. DesignKARL. a lan-guage for design of knowledge-based systems.In Proceedings of the 6th International Con-ference on Software Engineering and Kno-wledge Engeneering SEKE´94, pages 78–85,1994.

[Maestre-Yenes, 2000] P. Maestre-Yenes. Dic-cionario de Gestion Del Conocimiento EnInformatica. Monografıas Y Publicaciones.Gestion Del Conocimiento. Fundacion Din-tel, 2000.

[Marcus and McDermott, 1993] S. Marcus andJ. McDermott. Salt: A knowledge acquisitionlanguage for propose-and-revise systems. InB. G. Buchanan and D. C. Wilkins, editors,Readings in Knowledge Acquisition and Lear-ning: Automating the Construction and Im-provement of Expert Systems, pages 263–281.Kaufmann, San Mateo, CA, 1993.

[McCarthy and Hayes, 1969] K. McCarthy andP. J. Hayes. Some philosophical problemsform the standpoint of artificial intelligence.Machine Intelligence, 4:463–502, 1969.

[Mcdermott, 1982] J. Mcdermott. R1: A rule-based configurer of computer systems. Arti-ficial Intelligence, 10(1):39–88, 1982.

[McDermott, 1988] J. McDermott. Prelimi-nary steps towards a taxonomy of problem-solving methods. In S. Marcus, editor, Au-tomating Knowledge Acquisition for ExpertSystems, pages 225–256. 1988.

[Miller et al., 1982] R. A. Miller, H. E. Pople,and J. D. Myers. INTERNIST-i, an experi-mental computer-based diagnosis consultantfor general internal medicine. New EnglandJournal of Medicine, 37(8):468–476, 1982.

[Mittal and Chandrasekaran, 1984] S. Mit-tal and B. Chandrasekaran. Patrec: Aknowledge-directed data-base for a diag-nostic expert system. Computer, 17:51–58,1984.

[Musen, 1989a] M. A. Musen. Automa-ted Generation of Model-Based Knowledge-Acquisition Tools. Pitam, London, 1989.

[Musen, 1989b] M. A. Musen. An editor for theconceptual models of interactive knowledgeacquisition tools. International Journal ofMan-Machine Studies, 31:673–698, 1989.

[Musen, 1992] M. A. Musen. Overcoming thelimitations of role-limiting methods. Kno-wledge Acquisition, 4(2):165–170, 1992.

[Musen, 1993] M. A. Musen. An overview ofknowledges acquisition. In J. M. David, J. P.Krivine, and R. Simmons, editors, Second

Generation of Expert Systems, pages 405–427. Springer Verlag, 1993.

[Neubert, 1993] S.Neubert. Model construc-trion in MIKE. In Knowledge Acquisitionfor Knowledge-BAsed Systems. Proceedingsof the 7th European Workshop EKAE’93(LNCS No. 723), pages 200–219. Springer-Verlag, 1993.

[Newell and Simon, 1988] A.Newell and H. A.Simon. GPS: A program that simulates hu-man thought. In A. Collins and E. E. Smith,editors, Readings in Cognitive Science: APerspective from Psychology and ArtificialIntelligence, pages 453–460. Kaufmann, SanMateo, CA, 1988.

[Newell, 1982] Allen Newell. The knowledge le-vel. Artificial Intelligence, 18:87–127, 1982.

[O’Hare and Wooldridge, 1992] G. M. P.O’Hare and M. J. Wooldridge. A softwareengineering perspective on multi-agentsystem design. experiece in the developmentof MADE. In M. Avouris and Les Gesser,editors, Distributed Artificial Intelligence:Theory and Praxis, pages 109–127. KluwerAcademic Publishers, 1992.

[Palma-Mendez, 1999] Jose T. Palma-Mendez.Ingenierıa Del Conocimiento Para SistemasEn Tiempo Real Basados En Conocimiento.PhD thesis, Facultad de Informatica, Univer-sidad de Murcia, 1999.

[Puerta et al., 1992] A. R. Puerta, J. W.Egar, S. W. Tu, and M. A. Musen. Amultiple-method knowledge-acquisition shellfor the automatic generation of knowledge-acquistion tools. Knowledge Acquisition,4(2):171–196, 1992.

[Rumbaugh et al., 1991] J. Rumbaugh,M. Blaha, W. Premerlani, and V. F.Eddy. Object-Oriented Modelling andDesign. Prentice-Hall, New Jersey, 1991.

[Scarl et al., 1987] E. A. Scarl, A. R. Jamieson,and C. I. Delaune. Diagnosis and sensor va-lidation through knowledge of structure andfunction. IEEE Transaction on System, Manand Cybernetics, 17(3):360–368, 1987.

[Schreiber et al., 1993] G. Schreiber, B. J. Wie-linga, and J. A. Breuker, editors. KADS: APrinciple Approach to Knowledge-Based Sys-tem Development. Academic Press, 1993.

[Schreiber et al., 1999] A. T. Schreiber, J. M.Akkermans, A. A. Anjewierden, R. de Ho-og, N. R. Shadbolt, W. Van de Velde, andB. J. Wielinga, editors. Knowledge Engine-ering and Management. The CommonKADSMethodology. MIT Press, Cambridge, Mas-sachusetts. London, England, 1999.

[Shadbolt et al., 1993] N. Shadbolt, E. Motta,and A. Rouge. Constructing knowledge-based systems. IEEE Software, 10(6):34–38,1993.

[Shaw and Gaines, 1992] M. L. G. Shaw andB. R. Gaines. The synthesis of knowled-ge engineering and software engineering. InP. Loucopoulos, editor, Advanced Informa-tion Systems Engineering (LNCS 593). 1992.

[Shortliffe, 1976] E. H. Shortliffe. Computer-Based Medical Consultations: Mycin. Ame-rica Elsevier, New York, 1976.

[Steels, 1990] L. Steels. Components of exper-tise. AI Magazine, 11(2):30–49, 1990.

[Steels, 1993] L. Steels. The componential fra-mework and its role in reusability. In J. M.David, J. P. Krivine, and R. Simmons, edi-tors, Second Generation of Expert Systems,pages 273–298. Springer-Verlag, 1993.

[Studer et al., 1998] R. Studer, V. R. Benja-mins, and D. Fensel. Knowledge engineering:Principles and methods. Data and Knowled-ge Engineering, (25):161–197, 1998.

[Tu et al., 1995] S. W. Tu, H. Eriksson, J. Gen-nari, Y. Shahar, and M. A. Musen. Ontology-based configuration of problem-solving met-hods and generation of knowledge acquisi-tion tools: Application of PROTEGE-II toprotocol-based decision support. ArtificialIntelligence in Medicine, 7:257–289, 1995.

[Wielinga et al., 1994] B. Wielinga, J. M.Akkermans, H. A. Hassan, O. Olsson,K. Orsvarn, A. Schreiber, P. Terpstra,W. Van de Velde, and S. Wells. Exper-tise model definition document. Techni-cal Report ESPRIT Project P5248 /KADS-II/M2/UvA/026/5.0, University of Amster-dam and Free University of Brussels and Net-herlands Energy Research Centre ECN, June1994.