TESIS Commonkads

Universidad Politécnica de Valencia
Departamento de Sistemas Informáticos y Computación
Tesis Doctoral
CommonKADS-RT: Una Metodología para el

Desarrollo de Sistemas Basados en el
Conocimiento de Tiempo Real
Mónica Henao Cálad
Director:
Dr. Vicente Botti Navarro
Valencia, España. Abril de 2.001

Título: CommonKADS-RT: Una metodología para el desarrollo de sistemas
basados en el conocimiento de tiempo real.
Autor:
MSc. Mónica Henao Cálad
Director:
Dr. Vicente Botti Navarro
Tribunal:
Presidente:
Dr. Federico Barber Sanchís
Secretario:
Dra. Eva Onaindía de la Rivaherrera
Vocales titulares:
Dr. Richard Benjamins
Dr. Fernando Martín Rubio
Dr. Carlos Iglesias Fernández
Vocales suplentes:
Dra. Ana García Serrano
Dr. José Ramón Rizo Aldeguer
Valencia – España
12 de junio de 2001
A mi esposo Riche,
que siempre me ha animado, apoyado y brindado su amor y comprensión,
estando a mi lado en todo momento
A mi familia,
por sus oraciones, su amor y respaldo durante toda mi vida
Reconocimientos
Hay muchas personas a las que quisiera agradecerle toda su colaboración, amistad y
apoyo durante este largo recorrido, pero en este momento quiero resaltar los siguientes:
Al Doctor Vicente Botti, por su orientación, asesoría y soporte que me permitió

culminar exitosamente este proyecto.
A los miembros del Grupo de Tecnologías Informáticas (GTI) del Departamento de

Informática y Computación (DSIC) de la Universidad Politécnica de Valencia quienes
siempre me apoyaron y me dieron su conocimiento y amistad.
A los profesores del DSIC que me dieron la oportunidad de realizar este doctorado, a
través de sus enseñanzas. En especial a la Dra. Matilde Celma, responsable del programa.
A los coordinadores del convenio UNAL-UPV y directivas de la UPV quienes

hicieron posible la realización de este doctorado y de las diferentes pasantías que realicé
durante la investigación.
A los integrantes del Departamento de Informática y Sistemas de la Universidad

EAFIT, por su apoyo e interés.
A las directivas de la Universidad EAFIT por su patrocinio y soporte en la realización

del doctorado.
Al postgrado de Sistemas de la Universidad Nacional de Colombia, sede Medellín por

su colaboración en la realización de los cursos doctorales.
A mi familia y amigos que siempre me animaron y comprendieron todas mis

ausencias.
CommonKADS-RT – Resumen
Resumen
Los sistemas basados en el conocimiento de tiempo real son sistemas informáticos que
manejan el conocimiento de un dominio específico y tienen la capacidad de garantizar una
respuesta en un tiempo fijo, dado que manejan restricciones temporales.
Estos sistemas se han utilizado para solucionar problemas de control de procesos,

monitorización, diagnóstico y mantenimiento de fallos, entre otras. Es decir, en situaciones
en donde la toma de decisiones es dependiente del tiempo.
Básicamente las investigaciones en estos sistemas han estado enfocadas hacia su

arquitectura, sobre cómo lograr el cumplimiento de las garantías temporales en el
razonamiento del conocimiento o sobre cómo modificar las políticas de planificación de
tiempo real para que sean más predecibles.
No se han hecho muchos trabajos sobre cómo construir un sistema de este tipo, sobre
qué actividades deben ser realizadas para plantear un proyecto que pretenda la creación del
sistema o cuáles son las pautas que se deben seguir en dicho desarrollo. Es por esto, por lo
que se ha planteado proponer una metodología para el desarrollo de sistemas basados en el
conocimiento de tiempo real, surgiendo CommonKADS-RT.
Esta tesis se centra en el estudio de los sistemas basados en el conocimiento, los

sistemas de tiempo real, los sistemas basados en el conocimiento de tiempo real y los
métodos o metodologías que se han propuesto para el desarrollo de cada uno de esos
sistemas. Esto ha servido para desarrollar CommonKADS-RT, basada en la metodología
CommonKADS para sistemas basados en el conocimiento y RT-UML para sistemas de
tiempo real.
CommonKADS-RT permite seguir, en una forma comprensible y sencilla la

construcción de un sistema basados en el conocimiento de tiempo real. Está fundamentada
en el desarrollo evolutivo, la orientación por riesgos y sigue los planteamientos que la
Ingeniería del Software propone para lo que debe ser una buena metodología.
En CommonKADS-RT se plantea que un sistema basado en el conocimiento de

tiempo real se construye a través del desarrollo de siete modelos del problema o su
solución: el modelo de la organización que describe la empresa u organización en donde se
encuentra el problema y en donde se implantará la solución; el modelo de tareas de alto
nivel para representar los procesos del negocio relacionado con el problema; el modelo de
agentes para especificar las personas y los sistemas automáticos que participan en el
problema y su solución; el modelo de conocimientos que precisa el conocimiento que
poseen los agentes para realizar la tarea de alto nivel; el modelo de comunicaciones para
expresar los actos de comunicación que realizan los diferentes agentes que participan en el
sistema, para compartir su conocimiento y lograr el objetivo de las tareas de alto nivel; el
modelo de diseño en donde se describe la arquitectura y la especificación del diseño global
del sistema; y el modelo de tareas de tiempo real para definir la estructura genérica de una
tarea de tiempo real. Los primeros cinco modelos forman la fase de análisis y los dos
últimos la fase del diseño.
Para cada uno de los modelos se plantea su objetivo, los formularios que permiten
guiar su proceso de construcción y reflejar la información para incluir en la documentación
del proceso, los artefactos que resultan del desarrollo del modelo y los roles más
importantes que participan en dicho proceso.
Adicionalmente, las consideraciones metodológicas propuestas en esta tesis, incluyen

la determinación de cuándo es apropiado construir un sistema basado en el conocimiento de
tiempo real y si ésta es la mejor alternativa de solución, a través de unos criterios de
filtrado y de una caracterización del dominio en donde es posible utilizar la metodología.
Para mostrar la aplicación de la metodología se presenta dos casos reales y diferentes

en donde ésta se ha utilizado. En el primer escenario se pone énfasis en la etapa de análisis,
especialmente en el modelo de la organización. En el segundo se resalta la fase de diseño,
en particular la arquitectura del sistema y el modelo de tareas de tiempo real.
Como resultado de esta investigación se han realizado las siguientes publicaciones:
BOTTI V. Henao M. Soler J. Método de análisis para modelar sistemas basados en el

conocimiento en tiempo real. Memorias de la VIII Conferencia de la Asociación Española
para la Inteligencia Artificial, CAEPIA'99. Murcia, España. 1999, pp. 17-25.
HENAO, Mónica. CommonKADS: Una buena herramienta para la gerencia del

conocimiento. Revista Universidad EAFIT No. 115. Medellín, Colombia. 2000, pp. 77-93.
SOLER, J. Henao, M. Botti V. A Mobile Robot Application with an Analysis Method

based on CommonKADS. Proceedings of the IASTED International Conference: Intelligent
Systems and Control (ISC 2000). 2000, pp. 299-303.
HENAO, M., Soler, J. Botti. La integración de sistemas basados en el conocimiento y

sistemas de tiempo real por medio de un robot móvil. Workshop Luso - Hispano de
Agentes Físicos. Madrid, España. 2001, pp. 49-60.
HENAO, M., Soler, J. Botti V. Developing a Mobile Robot Control Application with
CommonKADS-RT. IEA/AIE 2001, The Fourteenth International Conference on Industrial
& Engineering Applications of Artificial Intelligence & Expert Systems. Budapest,
Hungary. 2001. (pendiente de publicar)
Abstract
Real-time knowledge-based systems are computer systems with two main abilities. On
the one hand, they can manage knowledge about a specific domain. On the other hand, they
are able to guarantee an answer in a fixed time, given that they can manage temporal
restrictions.
Systems of this kind have been used for solving several types of problems, such as
process control systems, monitoring, diagnosis and fault maintenance systems. In general,
these systems are applicable in systems where decision making is dependent on time.
In the past, research about such systems has been focused towards issues as their
architectures, mechanisms to obtain strict timing guarantees in the reasoning process or
modifications to real-time scheduling policies in order to make them more predictable.
However, not much of this research has been oriented on how to build such systems, the
activities involved in developing a project to create these systems, or the guidelines to
follow in that development. In this context, this work proposes a new methodology for
developing real-time knowledge-based system. This new methodology is called
CommonKADS-RT.
This doctoral thesis is centered in the study of knowledge-based systems, real-time

systems, real-time knowledge-based systems and the methods and methodologies which
have been proposed for developing each of these types of systems. All this has been used
for developing CommonKADS-RT. This methodology is, in turn, based on two
methodologies: CommonKADS, for the development of knowledge-based systems, and
RT-UML, for the development of real-time systems.
CommonKADS-RT allows to follow, in a understandable and easy way, the building

of a real-time knowledge-based system. This new methodology is based on both the
evolving development and the risk orientation, and it follows the guidelines proposed by
Software Engineering for creating a good methodology.
CommonKADS-RT proposes a real-time knowledge-based system to be built by

means of the development of seven problem (or solution) models. The organization model
describes the organization or company which has the problem, that is, the organization on
which the solution will be developed. The high-level task model represents the business
processes related with the problem. The agent model specifies the persons and the
automated systems which participate in the problem and its solution. The knowledge model
represents the knowledge that agents have for performing the high-level task. The
communication model expresses the communication acts executed by the agents that
participate in the system; this model is also used by agents for sharing their knowledge and
therefore for achieving the goals of the high-level tasks. The design model describes the
architecture and specifies the global design of the system. And the real-time task model
defines the generic structure of a real-time task. The five former models constitute the
analysis phase, while the two latter models form the design phase.
For each of these models, the following aspects are described: its objective, the forms
which allow to guide its developing process and to gather the information to be included in
the process documentation, the artifacts which result from the model development and the
most important roles which participate in that process.
The methodological proposals of this thesis also include the determination of when it
is appropriate to build a real-time knowledge-based system and whether this is the best
alternative. This is done by means of some filtering criteria and a characterization of the
domains on which it is possible to use the methodology.
In order to show the applicability of this new methodology, this thesis also presents
two real cases on which it has been applied. In the first scenario, the emphasis is on the
analysis phase, and specially on the organization model. In the second scenario, the design
phase is more deeply developed, specially the system architecture and the real-time task
model.
Some of the proposals of this thesis have been published in the following conferences:




Hungary. 2001.
Resum
Els sistemes basats en el coneixement i de temps real són sistemes informàtics que
manegen el coneixement d’un domini específic i tenen la capacitat de garantir una resposta
en un temps fixe, donat que tenen restriccions temporals.
Aquestos sistemes s’han utilitzat per a resoldre problemes de control de processos,

monitoritzacio, diagnòstic i manteniment de fallades, i daltres. Es a dir, en situacions a on la
presa de decisions és dependent del temps.
Bàsicament les investigacions en aquestos sistemes han estat enfocades cap a la seva
arquitectura, sobre com aconseguir el compliment de les garanties temporals en el
raonament del coneixement o sobre com canviar les polítiques de planificació de temps real
per que siguen més predibles.
No s’han desenvolupat molts treballs sobre com construir un sistema d’aquest tipus,
sobre què activitats deuen ser realitzades per a plantejar un projecte que tracte la creació del
sistema o sobre quines són les pautes a seguir en aquest desenvolupament.
Es per això, per que s’ha plantejat proposar una metodologia pel desenvolupament de
sistemes basats en el coneixement de temps real, d’aquesta manera es planteja
CommonKADS-RT.
La tesi es centra en l’estudi dels sistemes basats en el coneixement, els sistemes de

temps real, els sistemes basats en el coneixement de temps real i els mètodes o
metodologies que s’han proposat pel desenvolupament de cada un d’aquestos sistemes.
Açò ha servit per a desenvolupar CommonKADS-RT, basada en la metodologia

CommonKADS per a sistemes basats en el coneixement i RT-UML per a sistemes de temps
real.
CommonKADS-RT permet seguir, de forma comprensible i senzilla la construcció

d’un sistema basat en el coneixement de temps real.
Es fonamenta al desenvolupament evolutiu, l’orientació per riscs i segueix els

plantejaments que l'Enginyeria del Programari proposa com el que ha de ser una bona
metodologia.
En CommonKADS-RT es planteja que un sistema basat en el coneixement de temps

real es construirà mitjançant el desenvolupament de set models del problema o la seva
solució: el model de l’organització que descriu l’empresa o organització a on es troba el
problema i a on s’implantarà la solució; el model de tasques d’alt nivell per representar els
processos del negoci relacionats amb el problema; el model d’agents per a especificar les
persones i els sistemes automàtics que participen en el problema i la seva solució; el model
de coneixement que precisa el coneixement que tenen els agents per a realitzar la tasca
d’alt nivell; el model de comunicacions per expressar els actes de comunicació que realitzen
els diferents agents que participen en el sistema, per a compartir el seu coneixement i
aconseguir l’objectiu de la tasca d’alt nivell; el model de disseny on es descriu
l’arquitectura i l’especificació del disseny global del sistema; i el model de tasques de
temps real per a definir l’estructura genèrica d’una tasca de temps real.
Els primers cinc models formen la fase d’ anàlisi i els dos últims la fase de disseny.
Per a cada model es planteja el seu objectiu, els formularis que permeten guiar el seu
procés de construcció i reflectir l’informació per a incloure en la documentació del procés,
els artefactes que resulten del desenvolupament del model i els rols més importants que
participen en dit procés.
A més a més, les consideracions metodològiques propostes en aquesta tesi, inclouen la

determinació de quan és apropiat construir un sistema basat en el coneixement de temps
real i si aquesta és la millor alternativa de solució, mitjançant uns criteris de filtrat i una
caracterització del domini on és possible utilitzar la metodologia.
Per a mostrar l’aplicació de la metodologia es presenten dos casos reals i diferents on

s’ha utilitzat. En el primer escenari es posa l’èmfasi en l’etapa d’anàlisi, especialment en el
model de l’organització.
En el segon es ressalta la fase de disseny, en particular l’arquitectura del sistema i el

model de tasques de temps real.
Com a resultat d’aquesta investigació, s’han realitzat les següents publicacions:




Hungary. 2001. (pendent de publicar)
CommonKADS-RT – Tabla de contenido
TABLA DE CONTENIDO
Capítulo 1. Introducción y objetivos 1

1.1 Introducción ................................................................................ 1
1.2 Justificación de la tesis ................................................................ 6
1.3 Objetivos...................................................................................... 7
1.4 Descripción breve de la estructuración de esta memoria ........ 10
Capítulo 2. Estado del arte 13

2.1 Introducción .............................................................................. 13
2.2 Los sistemas basados en el conocimiento.................................. 13

2.2.1 Generalidades de los sistemas basados en el conocimiento............................... 14
2.2.2 Clasificación de los sistemas basados en el conocimiento................................. 15
2.2.3 Arquitectura de un sistema basado en el conocimiento ..................................... 18
2.2.4 Procesos en el desarrollo de sistemas basados en el conocimiento .................... 22
2.2.5 Metodologías para el desarrollo de sistemas basados en el conocimiento.......... 25
2.2.6 Metodología CommonKADS .......................................................................... 31
2.2.7 Ventajas y desventajas de CommonKADS....................................................... 49
2.3 Sistemas de tiempo real............................................................. 51

2.3.1 Generalidades de los sistemas de tiempo real ................................................... 51
2.3.2 Especificación de los sistemas de tiempo real .................................................. 53
2.3.3 Métodos para desarrollar sistemas de tiempo real............................................. 56
2.3.4 Metodología RT-UML .................................................................................... 70
2.3.5 Ventajas y desventajas de RT-UML................................................................. 77
2.4 Sistemas basados en el conocimiento de tiempo real................ 79

2.4.1 Generalidades de los sistemas basados en el conocimiento de tiempo real ........ 79
2.4.2 Tipos de sistemas basados en el conocimiento de tiempo real........................... 81
2.4.3 Aplicaciones reconocidas de los sistemas basados en el conocimiento de
tiempo real .................................................................................................... 82
2.4.4 Metodologías para desarrollar sistemas basados en el conocimiento de
tiempo real .................................................................................................... 84
i
2.5 Conclusiones del estado del arte ............................................... 86

2.5.1 Conclusiones de sistemas basados en el conocimiento...................................... 86
2.5.2 Conclusiones de sistemas de tiempo real.......................................................... 87
2.5.3 Conclusiones de sistemas basados en el conocimiento de tiempo real ............... 88
Capítulo 3. CommonKADS-RT 91
3.1 Introducción .............................................................................. 91
3.2 Justificación de CommonKADS-RT......................................... 91
3.3 Fundamentos de CommonKADS-RT....................................... 92

3.3.1 Fortalezas y debilidades de CommonKADS para sistemas basados en el
conocimiento de tiempo real............................................................................ 92
3.3.2 Fortalezas y debilidades de RT-UML para sistemas basados en el
conocimiento de tiempo real............................................................................ 93
3.3.3 Descripción general de CommonKADS-RT..................................................... 94
3.3.4 ¿Por qué un modelo para las tareas de tiempo real?.......................................... 97
3.4 Características del dominio que es apropiado para la

aplicación de CommonKADS-RT............................................. 98
3.5 Ciclo de vida de CommonKADS-RT ........................................ 98
3.6 Modelos que integran a CommonKADS-RT.......................... 100

3.6.1 Modelo de la organización............................................................................. 101
3.6.2 Modelo de tareas de alto nivel ....................................................................... 115
3.6.3 Modelo de agentes ........................................................................................ 120
3.6.4 Modelo de conocimiento ............................................................................... 125
3.6.5 Modelo de comunicaciones ........................................................................... 131
3.6.6 Modelo de diseño.......................................................................................... 134
3.6.7 Modelo de tareas de tiempo real .................................................................... 144
3.7 Conclusiones de CommonKADS-RT...................................... 150
Capítulo 4. Validación experimental de

CommonKADS-RT a través de casos 151
4.1 Introducción ............................................................................ 151
4.2 Tipos de casos .......................................................................... 151

4.2.1 Escenario de la operativa marítima del Puerto Príncipe Felipe de Valencia..... 151
4.2.2 Escenario de una aplicación con un robot móvil navegante ............................ 152
ii
4.3 Terminal de contenedores en el puerto de Valencia .............. 152

4.3.3 Modelo de agentes ........................................................................................ 180
4.3.4 Modelo de conocimientos.............................................................................. 183
4.4 Robot .................................................................................. 190

4.4.3 Modelo de conocimiento ............................................................................... 194
4.4.4 Modelo de diseño.......................................................................................... 197
4.4.5 Modelo de tareas de tiempo real .................................................................... 206
4.5 Conclusiones de la aplicación de CommonKADS-RT ........... 209
Capítulo 5. Conclusiones y trabajos futuros 211

5.1 Introducción ............................................................................ 211
5.2 Conclusiones generales............................................................ 212
5.3 Contribuciones principales ..................................................... 214
5.4 Trabajos futuros...................................................................... 218
ABREVIATURAS 221
REFERENCIAS 223
ANEXO 1 239
iii
CommonKADS-RT – Índice de figuras
ÍNDICE DE FIGURAS
Figura 1-1 Los sistemas basados en el conocimiento de tiempo real..................2

Figura 1-2 Alcance y objetivo de esta tesis..................................................... 10
Figura 2-1 Fases del ciclo de vida de MIKE................................................... 29
Figura 2-2 Modelos de CommonKADS ......................................................... 34
Figura 2-3 Modelo de la organización de CommonKADS.............................. 36
Figura 2-4 Modelo de tareas de CommonKADS ............................................ 38
Figura 2-5 Modelo de agentes de CommonKADS.......................................... 41
Figura 2-6 Jerarquía del modelo de conocimientos de CommonKADS ........... 42
Figura 2-7 Modelo de comunicaciones de CommonKADS............................. 44
Figura 2-8 Pasos del diseño del sistema ......................................................... 45
Figura 2-9 Documentación del ciclo de la gestión del proyecto en
CommonKADS............................................................................ 48
Figura 2-10 Elementos nuevos del Diagrama de Flujo...................................... 60
Figura 2-11 Modelado de un respirador artificial.............................................. 61
Figura 2-12 Modelado de un respirador artificial.............................................. 61
Figura 2-13 Procesos fundamentales del desarrollo con ROOM ....................... 66
Figura 2-14 MCSE .......................................................................................... 68
Figura 2-15 Ejemplo de un gráfico de casos de uso .......................................... 73
Figura 2-16 Ejemplo de un diagrama de secuencia ........................................... 74
Figura 2-17 Apartes de un Diagrama de Estados para un sistema telefónico...... 75
Figura 2-18 Apartes de un diagrama de actividades.......................................... 75
Figura 2-19 Diagrama de Componentes ........................................................... 76
Figura 2-20 Apartes de un diagrama de despliegue en UML............................. 76
Figura 3-1 Modelos de CommonKADS-RT ................................................... 95
Figura 3-2 Ciclo de Desarrollo en CommonKADS-RT................................. 100
Figura 3-3 Ciclo de Implantación del SBCTR .............................................. 100
Figura 3-4 Modelos de CommonKADS-RT en UML ................................... 101
Figura 3-5 Relación entre la empresa Marítima Valenciana y el Armador ..... 106
Figura 3-6 Diagrama de Cooperación de TAN ............................................. 108
Figura 3-7 Forma general de un Diagrama de Contexto para el SBCTR........ 110
v
Figura 3-8 Modelo de la organización de CommonKADS-RT...................... 114

Figura 3-9 Ejemplo de diagramas de secuencia a) y b) ................................. 124
Figura 3-10 Ejemplo de un caso de uso para algunos agentes en la terminal
de contenedores del puerto de Valencia....................................... 125
Figura 3-11 Bases de ARTIS ......................................................................... 135
Figura 3-12 Arquitectura global de un SBCTR............................................... 136
Figura 3-13 Diagrama de componentes principales del robot .......................... 138
Figura 3-14 Topología de ARTIS .................................................................. 139
Figura 3-15 Contenido del Modelo de Tareas de Tiempo Real........................ 145
Figura 3-16 Estructura de la tarea de tiempo real a bajo nivel ......................... 147
Figura 3-17 Ejemplo de un in-agent............................................................... 148
Figura 4-1 Organigrama de Marítima Valenciana......................................... 155
Figura 4-2 Organigrama de Operaciones Marítimas ..................................... 156
Figura 4-3 Vista general de atención a un buque en el puerto de Valencia..... 156
Figura 4-4 Diagrama de Actividades de los procesos que se realizan en la
Operaciones Marítimas............................................................... 157
Figura 4-5 Relación entre la empresa Marítima Valenciana y el Armador ..... 158
Figura 4-6 Relación entre la empresa Marítima Valenciana y Sevasa............ 158
Figura 4-7 Relación entre las manos de Sevasa y las unidades de Marítima
Valenciana ................................................................................. 159
Figura 4-8 Relación entre el conductor del transtainer y Operaciones
Marítimas................................................................................... 159
Figura 4-9 Relación entre el consignatario del Armador y la unidad
Planificación .............................................................................. 160
Figura 4-10 Relación entre el Planner del Armador y la unidad
Planificación .............................................................................. 160
Figura 4-11 Relación entre el agente del Armador y la unidad
Secuenciación ............................................................................ 160
Figura 4-12 Relación del Capitán del barco con Marítima Valenciana ............ 160
Figura 4-13 Relación del Primer oficial del barco con Comunicaciones.......... 160
Figura 4-14 Diagrama de casos de uso de las operaciones marítimas .............. 161
Figura 4-15 Vista general del SBCTR para la Planificación en la TAN
Planificación .............................................................................. 174
vi
Figura 4-16 SBCTR ubicado en las actividades de la empresa Marítima

Valenciana ................................................................................. 174
Figura 4-17 Diagrama de Flujo de la TAN PLAN .......................................... 179
Figura 4-18 Diagrama de Conceptos – Conocimiento del Dominio - de
Operaciones Marítimas............................................................... 184
Figura 4-19 Diagrama de estados de Bayplan................................................. 185
Figura 4-20 Diagrama de estados de Pila ....................................................... 185
Figura 4-21 Diagrama de estados de Posición ................................................ 186
Figura 4-22 Diagrama de estados de Contenedor............................................ 186
Figura 4-23 Un micro mundo posible para que el robot navegue..................... 191
Figura 4-24 Proceso que debe realizar el robot para cumplir con el objetivo
final ........................................................................................... 192
Figura 4-25 Detalle de las actividades de la TAN 2 - Buscar Objeto ............... 194
Figura 4-26 Diagrama de Conceptos para el sistema del robot móvil en el
micro mundo .............................................................................. 195
Figura 4-27 Diagrama de transición de estados del Planificador ..................... 196
Figura 4-28 Diagrama de transición de estados del PlanAcción ...................... 196
Figura 4-29 Diagrama de secuencia entre el concepto Robot y el
Planificador................................................................................ 197
Figura 4-30 Diagrama de componentes principales del robot .......................... 198
Figura 4-31 Diagrama que representa el inicio de la conexión ........................ 205
Figura 4-32 TAN en ARTIS .......................................................................... 206
Figura 4-33 Estado inicial del micro mundo................................................... 208
Figura 4-34 Estado final del micro mundo ..................................................... 208
Figura 4-35 El Pioneer 2 enfrente de un objeto de forma rectangular .............. 209
vii
CommonKADS-RT – Índice de tablas
ÍNDICE DE TABLAS
Tabla 2-1 Características y beneficios del método HPM................................ 59

Tabla 3-1 Relación entre las etapas del ciclo de vida y los modelos de
CommonKADS-RT.................................................................... 101
Tabla 3-2 Descripción de las tareas de alto nivel a través de los eventos
que las afectan............................................................................ 119
Tabla 3-3 Ejemplo de la lista de eventos externos que tienen relación con
el sistema ................................................................................... 122
Tabla 3-4 Tabla de eventos para el caso de un ascensor............................... 123
Tabla 3-5 Estructura de un mensaje según FIPA ......................................... 132
Tabla 3-6 Especificación de los componentes del SBCTR........................... 137
Tabla 4-1 Descripción de la tarea asignación .............................................. 186
Tabla 4-2 Descripción de la tarea de planificación de carga y descarga
del barco .................................................................................... 188
Tabla 4-3 Descripción de la tarea Scheduling para realizar la secuencia
de carga y descarga del barco...................................................... 188
Tabla 4-4 Comparación de la información enviada por el robot Pioneer
con un robot general. .................................................................. 200
ix
CommonKADS-RT – Índice de formularios
ÍNDICE DE FORMULARIOS
Formulario 3-1 OM-1: Identificación en la organización de los problemas y

oportunidades orientados al conocimiento, con el tiempo como
factor importante. ....................................................................... 104
Formulario 3-2 OM-2: Descripción de los aspectos de la organización que
tienen impacto en o están afectados por el problema elegido en
OM-1 ......................................................................................... 105
Formulario 3-3 OM-3: Descripción del proceso en función de las tareas de alto
nivel en que está compuesto........................................................ 107
Formulario 3-4 OM-4: Descripción del componente de conocimiento del
modelo de la organización .......................................................... 108
tendrán impacto o estarán afectados por la solución escogida
del SBCTR................................................................................. 109
Formulario 3-6 Lista de eventos externos que tienen relación con el sistema........ 111
Formulario 3-7 OM-6. Lista de chequeo para el documento de viabilidad de la
decisión de hacer un SBCTR ...................................................... 112
Formulario 3-8 TM-1: Descripción refinada de las tareas de alto nivel dentro
del proceso objetivo.................................................................... 117
Formulario 3-9 TM-2 Especificación del conocimiento empleado en la tarea de
alto nivel y posibles cuellos de botella y áreas para mejorar......... 119
Formulario 3-10 AM-1: Especificación de los agentes del SBCTR ........................ 122
Formulario 3-11 KM-1: Lista de comprobación de la documentación del modelo
del conocimiento ........................................................................ 127
Formulario 3-12 CM-1: Especificación de las transacciones que posibilitan el
diálogo entre dos agentes en el modelo de comunicación............. 133
Formulario 3-13 CM-2: Especificación de los mensajes y los puntos de
información que hacen una transacción individual dentro del
modelo de comunicación ............................................................ 134
Formulario 3-14 DM-1: Descripción de la arquitectura del sistema........................ 142
xi
CommonKADS-RT – Índice de formularios
Formulario 3-15 DM-2: Especificación de las facilidades ofrecidas por y en el

sistema que será implantado........................................................ 143
Formulario 3-17 DM-3: Lista de chequeo de decisiones en relación con la
especificación de la arquitectura ................................................. 143
Formulario 3-18 DM-4: Decisiones del diseño de la aplicación ............................. 144
Formulario 3-19 Especificación de las tareas de tiempo real .................................. 150
Formulario 4-1 OM-3: TAN del Proceso de la atención y prestación de
servicios marítimos..................................................................... 167
Formulario 4-2 OM-4: Descripción del componente de conocimiento del
modelo de la organización .......................................................... 170
tendrán impacto en o estarán afectados por la solución
escogida del SBCTR................................................................... 173
Formulario 4-4 TM-1: Descripción refinada de las tareas de alto nivel dentro
del proceso objetivo.................................................................... 179
Formulario 4-5 TM-1.1: TAN PLANIFICACIÓN (PLAN).................................. 182
Formulario 4-6 AM-1: Especificación de los Agentes del SBCTR ....................... 183
Formulario 4-7 Descripción del proceso en función de las TAN que lo
componen................................................................................... 193
xii
CommonKADS-RT – Capítulo 1. Introducción y objetivos 1
Capítulo 1.
Introducción y objetivos
1.1 Introducción
Los grandes avances en las tecnologías de los sistemas inteligentes y de los sistemas
de tiempo real, así como la necesidad que tienen las grandes industrias de tener software y
sistemas informáticos cada vez más complejos que respondan en tiempos definidos y que
manejen sus conocimientos de acuerdo con los cambios del entorno, han motivado la
investigación y el desarrollo de nuevas aplicaciones que tratan de solucionar, de la manera
más apropiada, dichos requerimientos.
Por el lado de los sistemas inteligentes, los sistemas basados en el conocimiento y los
agentes han revolucionado el concepto de cooperación, el manejo apropiado del
conocimiento, la distribución y el compartimiento del conocimiento, la reutilización y la
especialización de la información y la experiencia de un dominio.
Por el lado de los sistemas de tiempo real, cada vez los sistemas son más sofisticados
para llevar a cabo su función en entornos complejos y dinámicos, requiriendo tener mas
conocimiento y una mejor comunicación para responder adecuadamente, de acuerdo con
situaciones específicas para que se tomen las decisiones más apropiadas.
La confluencia de estas tecnologías está motivando la investigación y el desarrollo de

nuevos tipos de aplicaciones y de sistemas informáticos. Una categoría de estos sistemas
corresponde a los sistemas inteligentes de tiempo real, en particular a los sistemas basados
en el conocimiento de tiempo real, los cuales mediante el manejo de restricciones de tiempo
y de conocimiento específico de un dominio ofrecen una serie de ventajas entre las cuales
se puede mencionar la puntualidad de la información, el aprovechamiento del conocimiento
generado en la misma empresa o en un campo específico del saber y la respuesta correcta
en el momento oportuno. Ver Figura 1-1.
Han tomado tanta importancia los sistemas inteligentes de tiempo real que muchos
grupos de investigación ha propuesto arquitecturas específicas para su construcción, han
creado aplicaciones que resaltan la potencialidad de las mismas y se han comenzado a
introducir en la industria en general. Para ello, es necesario contar con las herramientas
necesarias, tanto de software, de hardware como de orgware, para que se puedan hacer de
la mejor manera. Las metodologías de desarrollo forman parte de las herramientas del
orgware, además de muchas políticas y estrategias organizacionales.
Sistemas de Sistemas
Tiempo Real Basados en el
Conocimiento
Sistemas basados en el
conocimiento de tiempo real
Figura 1-1 Los sistemas basados en el conocimiento de tiempo real
Para proponer aspectos metodológicos específicos para los sistemas basados en el

conocimiento, es importante especificar lo que se quiere decir con Consideraciones
Metodológicas, con Sistemas Basados en el Conocimiento - SBC, con Sistemas de Tiempo
Real - STR y con Sistemas Basados en el Conocimiento de Tiempo Real – SBCTR.
Todo esto conforma el marco teórico y conceptual de esta tesis, que se trata como un
capítulo completo con objetivos muy precisos y que tiene sus propias conclusiones y
referencias pertinentes para cada tema. Pero, dentro de esta introducción, se considera
relevante acordar lo que se entiende por los términos: metodología, método, proceso de
software, entre otros conceptos que se trabajan apropiadamente desde la Ingeniería del
Software.
Es importante también aclarar, que no se pretende construir una ontología para ello,
sino simplemente definir lo que se entenderá cada vez que se presente uno de estos
términos en esta disertación, teniendo como eje central los planteamientos de la Ingeniería
del Software, por ser ésta la encargada en la informática de proponer los conceptos
relacionados con el proceso de desarrollo del software.
Partiendo de lo que la Real Académica de la Lengua Española define en su diccionario

de 1992, las palabras metodología y método se han definido de la siguiente forma:
Metodología:
1. Ciencia del método.
2. Conjunto de métodos que se siguen en una investigación científica o en una
exposición doctrinal.
Método:
1. Modo de decir o hacer con un orden una cosa.
2. Modo de obrar o de proceder, hábito o costumbre que cada uno tiene y observa.
3. Procedimiento que se sigue en las ciencias para hallar la verdad y enseñarla.
Puede ser analítico o sintético.
Si estos conceptos se trasladan al campo de la Ingeniería del Software, entonces vemos

que éstos han sido utilizados en diferentes formas, sin ningún criterio. Por ejemplo, el
concepto metodología es relacionado por algunos como la secuencia de actividades que se

deben realizar para construir un sistema de software. Otros se refieren a la disciplina que
estudia los métodos para hacer sistemas de software. En este último caso no hay diferencia
con la definición de la Real Academia Española (RAE), sólo que para utilizarla
adecuadamente se requiere especificar la connotación que se le va a dar.
Por esto, a continuación se presentan algunas definiciones relevantes.
Para [SGW94] la palabra metodología literalmente significa el “estudio de los

métodos”. Sin embargo, se utiliza comúnmente como un enfoque para llevar a cabo una
tarea. Por tanto, se puede hablar que, para cada una de las etapas del desarrollo del software
se tiene(n) una o varias metodologías como por ejemplo: metodologías para el análisis,
metodologías para el diseño, metodologías para las pruebas, metodologías para la
administración del proyecto, entre otras. Además, estos autores dicen que la metodología es
una colección que debe tener 3 elementos:
• Un lenguaje de modelado,
• unas heurísticas para modelar y
• un marco de trabajo para organizar y ejecutar el trabajo de desarrollo.
Es decir, que una metodología sin alguno de esos elementos, no es una metodología.
[MSC+95], especifican el concepto de metodología desde el punto de vista del

software, diciendo que “una metodología de software es una manera de trabajar que reúne
el conjunto de información, datos o elementos en un repositorio”. Por tanto, es un
instrumento que permite reducir o disminuir la complejidad en la solución de un problema
cuando se está tratando de resolver por medio de un sistema computarizado.
Para [Igl98] “una metodología puede definirse, en un sentido amplio, como un

conjunto de métodos o técnicas que ayudan en el desarrollo de un producto de software.
Sus principales actividades son:
1. La definición y descripción del problema que se desea resolver.

2. El diseño y descripción de una solución que se ajuste a las necesidades del
usuario.
3. La construcción de la solución.
4. La prueba de la solución implementada.”
[Dou99] no define exactamente lo que es una metodología, pero si especifica lo que

ella debe comprender. Así, dice que una metodología consiste de varias partes:
• Un marco semántico,
• un esquema notacional,
• una serie de actividades de trabajo secuenciales y,
• un conjunto de componentes de trabajo para entregar.
“Juntos, el marco de trabajo y el esquema notacional comprenden el Lenguaje de

Modelado. El proceso de desarrollo describe las actividades que dirigen el uso de los
elementos del lenguaje y el conjunto de componentes de diseño que resultan de la

aplicación de estos en una secuencia definida de actividades.”
En [Hum95] se utiliza el término proceso de software y se define de la siguiente

forma: “el proceso de software es la secuencia de pasos que se requiere para desarrollar un
nuevo software o para hacerle mantenimiento a uno existente. Agrupa las consideraciones
técnicas y administrativas para aplicar métodos, herramientas y personas a la tarea del
software. La definición de un proceso de software es la descripción del proceso mismo,
identificando los roles y las tareas específicas para hacer”.
Las anteriores, son sólo algunas percepciones que se encontraron al respecto, y dado
que hay grandes diferencias entre algunas de ellas, consideramos en esta investigación que
es muy importante mantener las bases planteadas en la Ingeniería del Software, con el
vocabulario que se maneja en ese contexto, siguiendo un poco lo que se propone en
FRISCO (A Framework of Information Systems Concepts) [FHP+96]. De esta forma,
creemos que la forma más adecuada de definir una metodología es la siguiente:
Una metodología es un conjunto de métodos, prácticas, estilos, recursos y

conocimientos que permiten desarrollar de una manera efectiva y eficiente cada
una de las actividades que son necesarias para analizar, diseñar, producir,
implantar y mantener un artefacto
El concepto artefacto se refiere a cualquier documento o software que se produce

durante todos los procesos que se realizan, desde que se estudia el problema hasta que la
solución informática se implanta.
Es así como en una metodología de software se debe indicar:
• Qué es lo que se debe hacer, cuáles son las actividades específicas que se deben
realizar - Etapas.
• Cuál es el orden de realización de dichas etapas, cuándo se tienen que hacer las
actividades - Ciclo de Vida.
• Cuáles son las herramientas, conocimientos y utilidades para realizar las etapas -
Métodos.
• Quiénes son los responsables de proporcionar las especificaciones, de hacer el

análisis del problema y de proponer la mejor solución. Quiénes son los responsables
de hacer el sistema informático. Es decir, quién hace cada actividad y qué hacen en
el ciclo de vida. - Los roles y responsabilidades al realizar una actividad.
• Qué se va a obtener al realizar una etapa y al finalizar el proyecto, qué se necesita

obtener para solucionar o cambiar la situación actual. – Los artefactos: resultados,
documentos y el software.
• Cuáles son las guías que se van a utilizar para la toma de decisiones en cada una de
las etapas. - Los mecanismos de decisión.
En cuanto a la palabra método, aunque en esta memoria no presentamos ninguno en

especial, hemos encontrado que hay más acuerdo en la semántica que se trabaja, a pesar de
que algunos la tratan como sinónimo de metodología, sabiendo que en realidad ésta última
contiene la primera.
Por lo tanto, adoptamos la siguiente definición:
Un método es una serie de pasos a seguir para llevar a cabo una

determinada etapa del ciclo de vida de desarrollo de software (por ejemplo:
para elaborar el análisis)
Para los resultados finales de la investigación, se guardará este rigor, pero cuando se
presente los métodos y las metodologías en el capítulo del Estado del Arte, en las secciones
de sistemas basados en el conocimiento, sistemas de tiempo real y sistemas basados en el
conocimiento de tiempo real, se mantendrán los nombres originales, tanto por respeto a sus
creadores como porque es así como son reconocidos en el área tecnológica en que se
utilizan. Por tanto, en esos apartados se podrán ver como si los dos términos fueran
sinónimos.
Por último, es importante también definir el concepto modelo, ya que la metodología

que se propone - CommonKADS-RT - y sus consideraciones metodológicas, están
fundamentadas en la construcción de modelos que reflejan el conocimiento y la
información de un sistema basado en el conocimiento de tiempo real.
Un modelo es una abstracción de un sistema físico, con un propósito que

determina qué es lo que debe ser incluido en el modelo y qué es irrelevante. Es
decir, que el modelo describe los aspectos importantes del sistema físico, para
su propósito. [OMG99]
Hay varios aspectos importantes relacionados con este concepto:
• Un modelo sólo es una aproximación a la realidad y el nivel de detalle que debe

tener es determinado por su propósito.
• Para un mismo sistema físico, es posible definir diversos modelos, de acuerdo con el
punto de vista y el nivel de abstracción que se quiera resaltar. Es decir, el proceso de
modelado es dependiente de las interpretaciones subjetivas del modelador y por eso
se requiere que haya una confrontación con la realidad.
• El proceso de modelado es un proceso cíclico, así que nuevas observaciones pueden

dirigir el refinamiento, la modificación o complementación de un modelo ya
construido. [SFD99].
1.2 Justificación de la tesis

Dado el interés existente en los sistemas basados en el conocimiento de tiempo real se
ha pretendido hacer un estudio sobre lo que realmente implican, tanto desde el sentido de su
aplicación, como de su alcance y de las diversas formas en que se han desarrollado.
Esta investigación está enmarcada en el proyecto “ARTIS: Herramienta para el

desarrollo de sistemas inteligentes en tiempo real estricto", parcialmente subvencionado por
el proyecto nº TAP98-0333-C03-01 de la Comisión Interministerial de Ciencia y
Tecnología (CICYT) de España y que tiene como objetivo principal la construcción de un
software para especificar y desarrollar sistemas inteligentes de tiempo real estricto.
La principal motivación para realizar esta tesis doctoral, es contribuir a la

investigación de cuáles son las guías, los métodos y los procesos para desarrollar sistemas
basados en el conocimiento con restricciones temporales.
En el tema específico de metodologías para sistemas basados en el conocimiento de

tiempo real hay muy poca información en la comunidad científica, por lo que se considera
muy importante que los resultados que se obtengan en esta tesis doctoral contribuyan
positivamente en este campo, lo que redundará en el fortalecimiento del conocimiento que
se tiene al respecto y en la ampliación de la aplicación de este tipo de sistemas en
organizaciones diferentes a las de investigación, haciendo que cada vez más se difunda este
tipo de tecnología.
Es importante resaltar que la importancia de utilizar una metodología radica en el

hecho que si ésta se aplica cuidadosamente, hay una probabilidad muy alta de éxito en la
realización del sistema informático y en la puesta en marcha del mismo.
Esta tesis doctoral pretende analizar los siguientes aspectos referidos a las
metodologías para crear sistemas basados en el conocimiento de tiempo real:
• ¿Hay metodologías con amplia cobertura que sean específicas para el desarrollo de
sistemas basados en el conocimiento de tiempo real? ¿Son apropiadas para el
desarrollo de este tipo de sistemas?
• ¿Es posible que una metodología creada para el desarrollo de sistemas basados en el
conocimiento se pueda aplicar apropiadamente en la construcción de sistemas
basados en el conocimiento de tiempo real?
• ¿Es posible que una metodología creada para el desarrollo de sistemas de tiempo real
se pueda aplicar apropiadamente en la construcción de sistemas basados en el
conocimiento de tiempo real?
• ¿Los conceptos de metodologías, métodos, herramientas que se manejan en la

ingeniería del software son los mismos que se manejan en las áreas de los sistemas
de tiempo real, los sistemas basados en el conocimiento y los sistemas basados en el
conocimiento de tiempo real? ¿Cuáles son las diferencias?
• ¿Es importante que se tomen en cuenta los conceptos que se manejan en cada una de
las diferentes áreas de conocimiento (ingeniería del software, sistemas basados en el
conocimiento, sistemas de tiempo real, inteligencia artificial de tiempo real) para
crear una metodología coherente?
• ¿Las metodologías existentes para desarrollar sistemas basados en el conocimiento

de tiempo real son consecuentes con lo que debe ser una buena metodología para
crear ese tipo de sistemas informáticos?
• Al elegir una metodología existente ¿qué cambios hay que hacerle para que permita
lograr un buen análisis y diseño de un sistema basado en el conocimiento de tiempo
real?
• ¿Cuál es la semántica que se tiene al construir una aplicación que integra un sistema
basado en el conocimiento con un sistema de tiempo real?
• ¿Qué debe tener en cuenta un desarrollador de aplicaciones de software para

construir sistemas basados en el conocimiento de tiempo real?
1.3 Objetivos
Objetivo General:
El objetivo general de la tesis es proponer una metodología para el desarrollo de

sistemas basados en el conocimiento de tiempo real.
Objetivos específicos:
Para poder llevar a cabo el objetivo general, se definen una serie de objetivos
específicos que permitan alcanzarlo. En términos generales se explorarán diferentes
metodologías para el desarrollo de sistemas basados en el conocimiento de tiempo real.
Para ello es importante adentrarse más en cada una de las áreas informáticas involucradas
en este tipo de sistemas. Por eso, se analizarán las características específicas de cada uno de
ellos para identificar tanto los conceptos fundamentales en que está soportado, como los
conceptos que son comunes entre ellos y los que son diferentes. Esto servirá para constituir
un vocabulario apropiado en el área de los sistemas basados en el conocimiento de tiempo
real.
Adicionalmente, se analizarán los métodos y metodologías exclusivas para desarrollar

sistemas basados en el conocimiento y para sistemas de tiempo real, para decidir si es
posible aplicarlas al desarrollo de los sistemas basados en el conocimiento de tiempo real y
en qué forma se haría eso.
Todo esto conlleva a cumplir con la meta final que se ha planteado en la investigación.
Es decir, se trazarán unas directrices metodológicas que facilitarán el análisis y el diseño de
un sistema basado en el conocimiento de tiempo real.
Por último, para que lo propuesto tenga una validez y una aceptación, se analizarán y
diseñarán dos aplicaciones diferentes, pero que serán representativas en el tipo de problema
que se quiere tratar con la metodología propuesta.
A continuación se formalizan los objetivos específicos:
• Establecer un vocabulario básico que refleje la integración de los sistemas

basados en el conocimiento y los sistemas de tiempo real.
Consiste en definir los términos que se manejan en cada de uno de esas

áreas informáticas para poder establecer si hay discrepancias para evitar que al
hablar de sistemas basados en el conocimiento de tiempo real no se caiga en
ambigüedades o contradicciones.
No es la creación de una ontología del dominio, sino el planteamiento

semántico que fundamente el sistema informático y el proceso de su construcción
e implantación.
• Definir los criterios que permiten determinar si una buena alternativa de

solución de un problema es a través de la construcción de un sistema basado
en el conocimiento de tiempo real.
Se realizará una caracterización del tipo de problema que se asocia con el

desarrollo de un sistema basado en el conocimiento de tiempo real como parte de
la solución del mismo. Se describirán las especificaciones mínimas que debe
tener un sistema de ese estilo para que sea considerado como una alternativa de
solución o cambio de la situación específica.
• Identificar y evaluar las metodologías para construir sistemas basados en el

conocimiento de tiempo real.
Consiste en buscar las metodologías que se han propuesto para el

desarrollo de estos sistemas informáticos y determinar qué tan apropiadas son
para ese propósito. En caso de encontrar que si lo son, entonces se propondrán
nuevos enfoques o métodos para abordar el planteamiento completo de un
proyecto de análisis y diseño de estos sistemas.
• Determinar si las metodologías reconocidas para el desarrollo de sistemas

basados en el conocimiento pueden ser utilizadas, sin hacerle ningún cambio,
en la creación de sistema basados en el conocimiento de tiempo real.
Se examinarán las metodologías más reconocidas en el entorno de los

sistemas basados en el conocimiento, para establecer si se pueden aplicar al
desarrollo de sistemas informáticos que además del conocimiento contemplen
restricciones temporales.
Los criterios que se utilizarán son los que se plantean en la ingeniería del
software para saber si una metodología es completa y además, los criterios que
son propios de la ingeniería del conocimiento.
• Determinar si las metodologías o métodos reconocidos para el desarrollo de

sistemas de tiempo real pueden ser utilizados, sin hacerle ningún cambio, en la
creación de sistema basados en el conocimiento de tiempo real.
Este objetivo es similar al anterior, sólo que lo que se examinará en este

caso son las metodologías y los métodos reconocidos en el entorno de los
sistemas de tiempo real, para comprobar si se pueden utilizar en el desarrollo de
En este caso, también se manejarán los criterios de la ingeniería del

software más los específicos de las características de los sistemas de tiempo real.
• Proponer un modelo de ciclo de vida de los sistemas basados en el

Tal como se mencionó en la introducción de esta tesis, es importante

identificar el orden y el alcance de cada una de las etapas que se deben seguir en
el desarrollo de un sistema informático. Por lo tanto, para la metodología que se
propone en esta investigación se plantearán dichas etapas junto con la
especificación de la secuencia o concurrencia que se puede hacer con ellas.
• Definir los modelos, prácticas, recursos, roles y artefactos que se deben

considerar al realizar el análisis y diseño de un sistema basados en el
Consiste en el planteamiento completo de la metodología para desarrollar

sistemas informáticos de este estilo. Cómo se puede observar en la Figura 1-2
Alcance y objetivo de esta tesis, es el planteamiento de aspectos metodológicos
que integren las características de los sistemas basados en el conocimiento, de los
sistemas de tiempo real y de la ingeniería del software, es la zona que aparece en
color negro en dicha figura.
• Realizar la evaluación de la aplicación de la metodología propuesta en esta

tesis.
Se determinarán situaciones reales en las que se pueda aplicar la

metodología CommonKADS-RT que se propone en esta tesis, y se construirán
los diferentes modelos que la conforman para cada una de esos escenarios. Esto
con el fin de identificar si el seguimiento de la misma ofrece beneficios para el
proceso de desarrollo de un sistema basado en el conocimiento de tiempo real.
• Evaluar la metodología propuesta en esta tesis según la Ingeniería del

Software.
De acuerdo con los criterios definidos en la Ingeniería del Software para

determinar si una metodología es completa y apropiada, entonces se analizará
CommonKADS-RT. El resultado de esta evaluación será muy importante porque
podrá servir para identificar las ventajas y desventajas de la metodología, y
también, el planteamiento de futuros trabajos para mejorar lo realizado.
Aspectos Aspectos
metodológicos de metodológicos de
Sistemas de Sistemas Basados
Tiempo Real en el
Conocimiento
Aspectos
metodológicos de
Ingeniería del
Software
Figura 1-2 Alcance y objetivo de esta tesis
1.4 Descripción breve de la estructuración de esta

memoria
A continuación se hará un seguimiento global por los capítulos que conforman esta
memoria.
• En el capítulo 2 se presentará una síntesis del estado del arte necesario para acometer
esta tesis. Incluye aspectos de los principales temas o áreas de conocimiento
relacionados con la investigación, de la siguiente forma:
− En la primera sección del capítulo se explicarán los sistemas basados en el

conocimiento, su definición, arquitectura, aplicación y algunos métodos y
metodologías aplicados para su construcción, resaltando la metodología
CommonKADS.
− En la segunda sección se mostrarán los mismos tópicos del anterior, pero

relacionados con los sistemas de tiempo real. La metodología que se resaltará en
esta sección será RT-UML.
− En la tercera, se presentarán los sistemas basados en el conocimiento de tiempo

real, básicamente con el mismo contenido de los anteriores.
Es importante anotar, que en cada uno de los métodos y metodologías

presentados, se hará una breve valoración de su aplicación a los sistemas basados
en el conocimiento de tiempo real, tal como se manifiesta en uno de los objetivos
de la tesis.
Adicionalmente, para terminar este capítulo, se presentarán las conclusiones

más importantes relacionadas con cada uno de los temas tratados.
• En el capítulo 3 se definirán todas las consideraciones metodológicas para el

desarrollo de un sistema basado en el conocimiento de tiempo real, obteniendo como
resultado la metodología CommonKADS-RT.
− Inicialmente se justificará la relevancia de CommonKADS-RT. Luego se

presentarán las bases o fundamentos de dicha propuesta, resaltando sus bondades
y debilidades. Se hará una caracterización del dominio para el cual es apropiado
aplicar la metodología, con el fin de identificar claramente las situaciones o
problemas a los que más se ajustará aplicar la solución informática con ayuda de
las guías metodológicas. Se propondrá un modelo de ciclo de vida de una
aplicación informática fundamentada en un sistema basado en el conocimiento de
tiempo real. Se describirán cada uno de los modelos que conforman
CommonKADS-RT y por último, se presentarán las conclusiones más
importantes que se obtienen en esta investigación.
− Cada uno de los modelos que se presentará, contendrá los formularios apropiados
para su aplicación, los roles que deben participar en la elaboración de dicho
modelo y los artefactos que se deben producir durante la creación del modelo.
Todo esto ajustado al concepto metodológico que se adoptó en esta tesis y que fue
presentado en la introducción de este capítulo 1.
• En el capítulo 4, se realizará la evaluación experimental de los aspectos

metodológicos de CommonKADS-RT por medio de dos escenarios, con el objetivo
de ver su aplicabilidad.
− Inicialmente se presentarán, tanto las características comunes como las diferentes

de los escenarios y la razón de su elección. Después, se mostrará el primer
escenario dado por una situación que se presenta en una terminal de contenedores,
en concreto en la terminal de Marítima Valenciana S.A. en el Muelle Príncipe
Felipe del Puerto de Valencia y que demostrará la aplicación apropiada de cada
uno de los modelos que se proponen en la metodología, a través de una situación
real y actual.
− El segundo escenario será sobre un micro mundo en el que se utilizará un robot

para hacer una tarea específica. Este escenario es muy importante porque a través
de él se aplicará la metodología para una situación que estará aislada de una
organización, es decir, que no estará enmarcada en un contexto organizacional en
particular.
− Para terminar, se harán los comentarios más relevantes de la utilización de la

metodología y se presentarán las conclusiones de este aspecto.
• En el capítulo 5, se presentarán todas las conclusiones que se han obtenido al

terminar esta investigación y los trabajos que se podrán iniciar partiendo de los
resultados de la misma.
• Posteriormente, se mostrará una lista de las abreviaturas que se usarán en esta

memoria. Luego, se señalarán las referencias bibliográficas empleadas durante la
investigación, separadas por tema: referencias del capítulo Introducción y objetivos,
referencias de la sección de sistemas basados en el conocimiento, de la parte de
sistemas de tiempo real, de la sección de sistemas basados en el conocimiento de
tiempo real, de CommonKADS-TR y de las aplicaciones. Por último, se incluirá el
anexo 1 de los criterios que sirven de guía para determinar si es apropiado,
justificado y conveniente realizar el sistema basado en el conocimiento de tiempo
real.
CommonKADS-RT – Capítulo 2. Estado del Arte 13
Capítulo 2.
Estado del arte
2.1 Introducción
Como fundamento de investigación para esta tesis doctoral, se debe partir de una serie
de tecnología claves para el planteamiento de las consideraciones metodológicas que
permitan desarrollar sistemas basados en el conocimiento de tiempo real. Las tecnologías
claves de las cuales se tratará su estado del arte son:
• Los sistemas basados en el conocimiento que cubrirán aspectos generales, tipos de

sistemas, arquitecturas y metodologías.
• Los sistemas de tiempo real, desde sus características hasta los métodos que se
utilizan para realizar su análisis y el diseño.
• Los sistemas basados en el conocimiento de tiempo real, incluyendo aspectos

referentes a los tipos de sistemas, aplicaciones reconocidas y también, las
metodologías que se han propuesto para su desarrollo.
2.2 Los sistemas basados en el conocimiento

En esta sección se presentan los conceptos relacionados con la Inteligencia Artificial
(IA) y los Sistemas Basados en el Conocimiento (SBC). En ella se introducen los términos
y definiciones específicas de este contexto, ampliando los aspectos relacionados con los
componentes de un SBC, y de algunos métodos y metodologías que son propias para su
construcción.
2.2.1 Generalidades de los sistemas basados en el conocimiento

La Inteligencia Artificial (IA) es un área de la informática que trata de modelar, a
través del ordenador, las capacidades inteligentes del ser humano, incluyendo su habilidad
para solucionar problemas complejos mientras operan y se adaptan a dominios dinámicos,
inciertos y que no están completamente especificados. Para llevar a cabo el objetivo global
de la IA, ésta se ha dividido en una serie de áreas de investigación, cada una con unos
propósitos específicos que permiten aportar conocimientos y métodos particulares que
ayudan al cumplimento de la meta general. Entre éstas están las redes neuronales
artificiales, el procesamiento del lenguaje natural, la visión artificial, el reconocimiento de
formas, la robótica inteligente y los sistemas basados en el conocimiento. Como este
último es uno de los temas básicos de esta investigación, se tratará más a fondo.
Los Sistemas Basados en el Conocimiento (SBC) tratan con problemas complejos en

un dominio y requieren de un elevado conocimiento del mismo. Muchos investigadores
manifiestan que estos sistemas intentan imitar la actuación de un experto humano ante un
problema relacionado con su dominio. Para ello tienen unos mecanismos que reflejan el
conocimiento y el razonamiento que el experto maneja para la toma de decisiones ante
cierta situación [Hen97]. Dentro de estos se encuentran los sistemas expertos, llamados así
por la calidad y cantidad del conocimiento que manejan en relación con el experto humano.
Un SBC tiene un gran número de características atractivas [Gia89]:
• Maneja el conocimiento de un dominio, es decir, maneja los hechos, las heurísticas y

las relaciones que posibilitan el encontrar buenas soluciones a problemas de él.
• Permite acceder fácilmente al conocimiento de ese dominio, ya que el conocimiento

reflejado en el sistema puede estar disponible en cualquier ordenador. Por lo tanto,
en un sentido real, un SBC es la producción en masa de la pericia.
• Simula el proceso de solución de problemas utilizado por un experto humano.
• Puede servir para evitar peligros a los usuarios, ya que puede ser usado en ambientes
pesados que pueden presentar riesgos al ser humano.
• Es permanente es decir, el conocimiento que posee es persistente, continuará

indefinidamente. Esto es contrario a los expertos que en cualquier momento se
pueden retirar. Además, sirve como repositorio de conocimientos con el objetivo de
mantener y hacer que el conocimiento perdure dentro de la organización, logrando
inclusive que sirva como herramienta de registro tecnológico.
• Puede englobar o captar el conocimiento de un número de personas.
• Facilita el acceso a la pericia de múltiples expertos: El conocimiento de varios

expertos puede estar disponible para trabajar simultánea y continuamente un
problema. El nivel de experiencia combinada de varios expertos puede exceder el de
un solo experto humano.
• Da explicación de su conocimiento y razonamiento: El SBC puede explicar

explícitamente en detalle el razonamiento que permitió obtener una conclusión. Un
humano puede estar muy cansado, o no querer hacer esas dos cosas a la vez. Esto
incrementa la confianza de la decisión tomada.
• Respuesta rápida: Dependiendo del software y del hardware usados, un SBC puede
responder rápidamente y tener mayor disponibilidad que la que tiene un experto
humano. Algunas situaciones de emergencia pueden requerir respuesta más rápida
que la de un humano y así el SBC responderá a tiempo.
• Ofrece respuestas en una forma uniforme, no emotiva, y completa en cualquier

situación. Esto puede ser muy importante en casos de tiempo real y emergencia
cuando un experto humano puede no operar en una máxima eficiencia debido al
estrés o a la fatiga.
• Puede servir como un tutor inteligente. El SBC puede actuar como un guía
inteligente dejando que el estudiante ejecute programas ejemplo y acceda a la
explicación del razonamiento del sistema.
• La forma de razonamiento (Motor de Inferencia) y el conocimiento (Base de

Conocimientos) son independientes, lo que implica que los cambios que se realicen
en uno de ellos puede que no requieran cambios en el otro.
• Base de datos inteligente. Un SBC puede ser usado para acceder a una base de datos
de una manera inteligente.
2.2.2 Clasificación de los sistemas basados en el conocimiento

Un SBC se clasifica de diversas formas: por su funcionalidad o propósito, por su
estado de evolución, por el papel que realiza en el entorno, y por la labor de ayuda que le
ofrece al experto con el conocimiento del dominio que él tiene.
• Según la funcionalidad del sistema
Esta clasificación es de acuerdo con la función que él realiza o el propósito para

el cual fue desarrollado. A continuación se explica cada uno de ellos brevemente y se
mencionan algunos de las áreas en las que estos sistemas son representativos [She90]
y [HKL+89]:
− Descubrimiento: Sistemas que generan nuevos conceptos a partir de reglas y

principios consistentes y permiten encontrar nuevas relaciones entre los datos.
o PROSPECTOR: Para el descubrimiento de yacimientos de molibdeno.

o AM: Para la formulación de conceptos y conjeturas sobre la teoría de
números.
o META-DENDRAL: Para el descubrimiento de reglas sobre la conducta de
algunos compuestos en el espectrómetro de masas.
− Diagnóstico: Para detectar las causas del mal funcionamiento de un sistema.
o MYCIN: Diagnostica las causas de enfermedades infecciosas en un paciente.

o ACE: Localiza las causas de fallas en redes telefónicas.
o REACTOR: Encuentra las fallas en los sistemas de enfriado de reactores
nucleares.
− Diseño: Con el objetivo de configurar estructuras a partir de unas condiciones

iniciales.
o XCON: Configura sistemas computarizados.

o SECS: Genera complejos compuestos químicos.
o PALLADIO: Diseña y prueba nuevos circuitos de tipo VLSI.
− Interprete: Sistema que infiere el significado de los datos (analiza los datos), es
decir, sirve para determinar qué está sucediendo en un momento dado.
o PROSPECTOR: Interpreta datos de muestras de material mineral para

detectar yacimientos.
o REACTOR: Interpreta los datos en tiempo real, de reactores nucleares.
o CRYSALIS: Interpreta los datos de un mapa de densidad de electrones para
inferir la estructura tridimensional de una proteína.
− Monitorización: Su objetivo es comparar el estado de un proceso real con el

estado esperado, para detectar desviaciones y sugerir las correcciones.
o YES/MVS: Controla y hace la monitorización de las funciones de un sistema

operativo.
o VM: Hace la monitorización del estado de un paciente en una sala de cuidado
intensivo.
o REACTOR: Hace la monitorización de los procesos de un reactor nuclear.
− Planeación: Para plantear la mejor acción a realizar para alcanzar un objetivo.

o THE UNDERWRITING ADVISOR: Ayuda al asesor de seguros en la
determinación de si otorgar o no una póliza y en qué condiciones.
o PLANNER: Hace la planeación estratégica de una organización.
o KNOBS: Asiste en la planeación táctica de ataques aéreos.
− Predicción: Sistemas que infieren las probables consecuencias de una situación,

utilizando modelos de simulación.
o PLANT: Estima los daños potenciales de plagas sobre plantíos.

o I&W: Predice los posibles lugares de conflictos armados.
o PTRANS: Estima los requerimientos de manufactura de algún producto.
• Según el estado de evolución del sistema
Esta clasificación es de acuerdo con el grado de evolución que el sistema ha

tenido. Es decir, que dependiendo de su propósito, cubrimiento y del conocimiento
que maneja se tienen diversos estados del sistema [Wat86]:
− Prototipo de demostración: El sistema soluciona una porción del problema,

sugiriendo que el enfoque es viable y el desarrollo del sistema es alcanzable. Es
pequeño y se utiliza como estrategia de convencimiento de la utilidad del SBC.
− Prototipo de investigación: El sistema presenta un desempeño aceptable del

problema pero puede ser frágil debido a que no se ha probado y revisado
completamente. Es de tamaño mediano.
− Prototipo de campo: El sistema muestra un buen desempeño y ha sido revisado en

el entorno del usuario. Es de tamaño que varía de mediano a grande.
− Modelo de producción: El sistema exhibe muy buena calidad, desempeño, rapidez

y una ejecución eficiente en el entorno del usuario. Son grandes programas
implementados en lenguajes eficientes.
− Sistema comercial: El sistema es un modelo de producción que está siendo usado

regularmente en una base comercial.
• Según el papel que el sistema desempeñe en el entorno
Esta clasificación se refiere a la forma como el SBC interactúa con el usuario en

términos de compartir tareas y responsabilidades [GuT94]:
− Sistema soporte: Es un SBC que puede darle soporte experto al usuario. Este
sistema puede actuar en diferentes roles, como asistente, colega crítico, segunda
opinión, asesor, consultor tutor, etc. Ofrece conocimientos y competencias pero
no prescribe soluciones o decisiones. Actúa como un ayudante, sin la intención de
reemplazar al experto.
− Sistema prescriptivo: Es un SBC que puede guiar, restringir y controlar la

actividad de un usuario en la ejecución de una tarea compleja. Mejora la calidad y
el tiempo de respuesta sin reemplazar a los expertos. Este sistema tiene la
autoridad para mejorar los objetivos, restricciones, soluciones o decisiones.
− Sistema autónomo: No interactúa con ningún humano ya que se utiliza para

reemplazarlos en un trabajo específico.
Además, otros los clasifican según el nivel de conocimiento que el sistema tiene,
comparado con un experto humano, así: Sistema novato, cuando el conocimiento está
basado más en libros y artículos que en un experto, y requiere de su supervisión. Sistema
colega - ayuda, cuando el conocimiento que maneja está por los niveles del experto
humano. Sistema Experto, que maneja todo el conocimiento de un dominio, razona en
forma similar al experto humano, llegando incluso a tener el conocimiento de varios

expertos.
2.2.3 Arquitectura de un sistema basado en el conocimiento

La arquitectura se refiere a los componentes o módulos que constituyen parte del
sistema, independiente del dominio. Específicamente cuando se habla del SBC se definen
tres tipos de arquitecturas en general:
• Arquitecturas de primera generación, en donde el control y el conocimiento están

centralizados. Esta arquitectura tiene como componentes principales el motor de
inferencia y la base de conocimiento, que se presentan más adelante. Estas
arquitecturas propiciaron o fueron el origen del término Sistema Basado en el
Conocimiento.
• Arquitecturas de segunda generación, guiada principalmente por la filosofía de

sistemas distribuidos. Se habla de agentes inteligentes, en donde cada uno de ellos
presenta un comportamiento inteligente. Surge el término Sistema de Conocimiento
y Sistemas de Agentes Inteligentes.
• Arquitecturas de última generación, en donde la idea básica es la reutilización de

muchos de los componentes del sistema [SDF+00]. Una arquitectura de este tipo es
la que proponen [FBM+99] en la que se dice que un SBC está formado por cinco
elementos básicos:
− Una tarea que define el problema que debería ser solucionado por el SBC.
− Un método de solución de problemas que define su proceso de razonamiento.
− Un modelo del dominio que describe el conocimiento de su dominio.
− Una ontología que provee la terminología usada en las tareas, los métodos de
solución de problemas y el dominio.
− Adaptadores para establecer la relación apropiada entre la tarea, el método de

solución de problema y el dominio. Se define un adaptador para la relación de
entre dos componente de la arquitectura.
Los componentes que en general forman parte de todo sistema basado en el

comportamiento son la base de conocimientos y el motor de inferencia. A continuación se
detallan.
2.2.3.1 Base de conocimientos
Es la estructura que permite guardar el saber relacionado con un dominio y que se

construye a partir de las fuentes de conocimientos.
Desde el punto de vista de la Inteligencia Artificial el conocimiento se ha clasificado

en: hechos, heurísticas y relaciones (reglas). Un hecho es un dato dado, probado y que tiene
un valor de verdad asociado; una heurística es generada a través de la experiencia de la
persona; una relación se establece a partir de los hechos o las heurísticas del dominio.
Una fuente de conocimiento es donde está guardado el conocimiento y se clasifica de

la siguiente forma:
− Fuente de conocimiento estática - fuente secundaria: Es rígida porque su

contenido no se puede variar. Por ejemplo, un libro, una revista, un artículo o una
película.
− Fuente de conocimiento dinámica - fuente primaria: Refleja las características del

conocimiento tales como, la variabilidad, el hecho de ser cambiante e inexacto,
entre otras. El hombre forma parte de este tipo de fuente y en particular, el
experto.
Es importante anotar que algunos autores manejan el concepto único de base de

conocimientos y otros lo dividen en: base de datos y base de relaciones. A continuación se
explica cada uno de ellos.
• Base de datos
Contiene los hechos, los datos y las heurísticas puntuales del dominio. Estos
generalmente son obtenidos de las fuentes estáticas del conocimiento, con la revisión
del experto en el dominio. Típicamente se clasifican en datos de entrada, es decir,
datos requeridos por el sistema y que el usuario le proporciona, y datos inferidos que
se obtienen a partir de la relación de otros.
Un ejemplo de un dato de entrada es: Tipo de Contenedor; un ejemplo de un dato

inferido es: Zona de descarga en el puerto, pues a partir del contenedor se puede saber
en dónde debe ubicarse en el puerto.
• Base de relaciones
Contiene las relaciones que se establecen entre los hechos o las heurísticas del
dominio. Normalmente se establecen por medio de reglas del tipo Si una condición,
Entonces una acción o conclusión. Estas relaciones se ejecutan de acuerdo con el
razonamiento que siga el motor de inferencia.
Ejemplo de una relación:

SI el tipo de contenedor es un frigorífico

ENTONCES La zona en donde se debe descargar es en importaciones.
2.2.3.2 Motor de inferencia
Refleja el razonamiento del experto en el dominio. Su objetivo es derivar nueva

información. Está formado por los algoritmos o programas que reflejan algún tipo de
inferencia, manejan (seleccionan, deciden, interpretan y aplican) los conocimientos de la
base de conocimientos y coordinan las acciones que el sistema, como un todo, debe
realizar. En otras palabras, el motor de inferencia es el centro del SBC ya que se encarga de
controlar las acciones de los otros componentes.
Los problemas que se encarga de resolver este componente son la búsqueda del
conocimiento y su control.
• Para la búsqueda del conocimiento en la base de conocimientos se definen

algoritmos que, de acuerdo con la estructura del conocimiento, permiten hacer la
exploración en la forma más apropiada.
• Para realizar el control del conocimiento. Se utilizan métodos para determinar qué
conocimiento aplicar en un momento dado. Entre ellos hay tres que se destacan
como fundamentales para la resolución:
− Encadenamiento hacia delante (forward chaining) o razonamiento orientado hacia

los datos. Determina el conocimiento a partir de los hechos que el usuario le
proporciona, llegando a obtener una conclusión a partir de las relaciones y los
hechos inferidos. Por ejemplo, un sistema que sirve para planificar la secuencia
de carga de un barco en el puerto, entonces a partir de la situación de la terminal y
del barco puede llegar a determinar cómo debe efectuarse la carga y cómo
quedará el barco cargado. Este proceso desde el punto de vista de las matemáticas
y de la sicología es el que se conoce como Razonamiento Deductivo (Modus
Ponens).
− Encadenamiento hacia atrás (backward chaining) o razonamiento orientado hacia

los objetivos. Parte de un objetivo o conclusión para llegar a obtener los hechos
que permiten su validación. Por ejemplo, si un sistema tiene todos los datos y la
información de la situación final del barco (una vez esté lleno), es decir, del plano
como debe quedar el barco después de haber sido cargado y llega un barco en
particular, entonces el sistema puede llegar a determinar cuál es la situación del
terminal. Este es el Razonamiento Inductivo (Modus Tollens).
− También es posible tener un razonamiento híbrido que es una combinación de los

dos enfoques anteriores. La decisión de cuál aplicar depende de la forma como el
experto razone.
En términos de las arquitecturas de última generación, el motor de inferencia se

especifica como el componente que contiene los métodos de solución de problema. En
donde, un método de solución de problemas – PSM (Problem-Solving Method) “refina los

motores de inferencia genéricos para permitir un control más directo del proceso de
razonamiento. Estos métodos describen el conocimiento de control independiente del
dominio de la aplicación y así dan la posibilidad que diferentes dominio y aplicaciones
reutilice el conocimiento estratégico” [FMB+00]. En la actualidad se han desarrollado
muchos PSM, creando librerías que proveen el soporte para que puedan ser reutilizadas en
la creación de nuevas aplicaciones. Un ejemplo de esto es lo propuesto por Richard
Benjamins en su tesis doctoral [Ben93], sobre métodos de solución de problemas para
diagnóstico.
Además de estos componentes, hay otros que el sistema puede tener y que le servirán
para llegar a la categoría de sistema experto, estos son: el módulo explicativo, el módulo de
adquisición del conocimiento y la interfaz usuario - sistema:
2.2.3.3 Módulo explicativo
Éste se encarga de dar las explicaciones relacionadas con el razonamiento que el

sistema ha seguido para llegar a obtener una conclusión o una recomendación, para aclarar
el por qué o para qué de una pregunta que el sistema le formula al usuario.
2.2.3.4 Módulo de adquisición del conocimiento
A través de este componente el ingeniero del conocimiento o el experto del dominio

puede construir inicialmente el sistema o actualizar el conocimiento de la base de
conocimientos en general. Permite entrar los hechos y las reglas al sistema y probar y
depurar los cambios realizados. “Usualmente el usuario final no debería tener la capacidad
para cambiar el sistema, ya que puede no tener el suficiente conocimiento” [Edm88].
Adicionalmente, por medio de éste se pueden realizar actividades relacionadas con la

configuración del sistema, específicamente del motor de inferencia, de acuerdo con las
necesidades del usuario [Guz96].
En el medio se encuentran herramientas que permiten hacer esta adquisición de forma

automática, tal como TOPKAT (The Open Practical Knowledge Acquisition Toolkit) que
integra técnicas de extracción del conocimiento con el enfoque de modelado de
CommonKADS [Kin94].
2.2.3.5 Interfaz Usuario - Sistema
La interfaz de un usuario con el ordenador es el medio a través del cual se comunican

entre sí. Es el medio mediante el cual el usuario accede a los servicios del SBC.
El tipo de interfaz tiene una fuerte influencia en cómo un usuario ve y entiende la

funcionalidad del sistema [Pri93], ya que el dialogo que se establece le permite relacionar
los detalles de las tareas con el objetivo del sistema informático.
Lo importante en el diseño y construcción de la interfaz es que ésta deber estar de

acuerdo con las necesidades del usuario, el conocimiento que él tiene sobre el dominio y las
características del problema y de su solución.
2.2.4 Procesos en el desarrollo de sistemas basados en el

conocimiento
Para construir un SBC se deben diseñar unos procesos para el manejo del
conocimiento. Dependiendo de la metodología que se siga, estos procesos se hacen en un
momento específico. Es decir, algunas metodologías los incluyen como tareas de una de sus
etapas, otras como una etapa específica y otras como procesos independientes de las etapas
pero paralelas a ellas.
Es importante reseñar que en general los procesos son aplicados y seguidos por grupos
interdisciplinares, en donde las personas pueden jugar varios roles a la vez o un rol ser
realizado por varias personas. Entre estos papeles se tienen los siguientes:
• Experto: Es la persona o grupo de personas que tiene(n) el conocimiento teórico y

práctico del área problema es decir, el (los) perito(s). Este experto debe ser
reconocido en su área de especialización, lo que implica que sus colegas lo
consideran una persona valiosa por sus conocimientos sobre el dominio.
• Ingeniero del Conocimiento (IC): Es (son) la(s) persona(s) encargada(s) de construir

el sistema. Debe(n) tener los conocimientos profundos sobre cómo desarrollar
sistemas basados en el conocimiento, conocer las herramientas de su desarrollo,
conocer algunas de las estrategias efectivas de comunicación y tener unos mínimos
conocimiento de sicología para poder interpretar las expresiones y manifestaciones
del experto [Har92].
• Usuario: Es (son) la(s) persona(s) que va(n) a utilizar el sistema, que se va(n) a ver
beneficiado(s) directamente por la implantación del proyecto. Su conocimiento debe
ser considerado al desarrollar el SBC.
En términos generales los procesos que se realizan con el conocimiento son: la

adquisición, representación y manipulación / validación. A continuación se presenta cada
uno de ellos.
2.2.4.1 Adquisición del conocimiento
Este proceso se refiere a la labor de extracción del conocimiento de las fuentes

estáticas y dinámicas. No debe confundirse con el módulo de adquisición del conocimiento
mencionado en la sección 2.2.3.4.
El objetivo final de este proceso es construir los modelos del conocimiento del SBC
[SFD+99], por ello se realiza durante todo el desarrollo del sistema, desde el mismo
momento en que se comienza a estudiar el problema y su solución hasta cuando se lleva a
cabo su evolución. Por lo tanto se efectúa durante todas las etapas del desarrollo, en unas
con mayor intensidad que en otras. Se puede decir que es un proceso que no termina
[SCG91].
Dependiendo del tipo de fuente de conocimiento que se va a utilizar se sigue alguno de

los siguientes procedimientos:
• Adquisición del conocimiento de una fuente estática. En la sección 2.2.3.1. se

definió lo que era una fuente estática y se presentaron ejemplos de ella. Lo primero
que se debe hacer es seleccionar las fuentes más apropiadas que están relacionadas
con el problema para adquirir los conocimientos básicos del dominio, evaluando
todos los recursos que se tengan disponibles bien sea al interior de la empresa o fuera
de ella. Comúnmente, el experto es quien aconseja qué fuentes estudiar. Luego, se
hace un estudio minucioso de ellas para que así el (los) ingeniero(s) del
conocimiento pueda(n) adquirir ese conocimiento básico y fundamental del dominio
del experto y consiga(n) realizar un proceso de adquisición eficiente y eficaz. Por
último, se debe hacer una comprobación del conocimiento que se extrajo para saber
si éste es correcto o no.
• Adquisición del conocimiento de una fuente dinámica. Esta labor se realiza una
vez se haya adquirido el conocimiento básico del dominio por parte del (los)
ingeniero(s) del conocimiento. Hay diferentes estrategias para ello, a continuación se
presentan las más usuales.
− Entrevista directa o formal: Consiste en realizar conversaciones personales entre

el Ingeniero del Conocimiento (IC) y la fuente del conocimiento, bien sea el
experto o el usuario. El IC establece un plan de la reunión en el que se determina
el objetivo principal de la misma, el tema a tratar, los recursos que se necesitan
para registrar (guardar) la entrevista, la fecha, la hora y el lugar donde se llevará a
cabo dicha entrevista. Este plan debe ser luego enviado a la persona que se va a
entrevistar para que lo revise, lo corrija, lo apruebe y así tenga la oportunidad de
prepararse con anterioridad.
Este tipo de recurso es muy valioso, aunque debe ser manejado con mucha
seriedad y precaución, teniendo en cuenta lo costoso del tiempo que se va a
invertir. Por lo tanto, el IC debe determinar los medios que requiere para poder
conservar y revisar el conocimiento adquirido [McH89].
− Entrevista informal: Se realiza de forma personal pero no planeada. Es

aprovechar la oportunidad del encuentro entre el IC y la persona que tiene el
conocimiento, en donde el primero le hace una pequeña entrevista al segundo.
Obviamente, por ser una entrevista esporádica o imprevista, no se tienen
disponibles los medios que permiten registrar el conocimiento, por lo tanto, se
debe tener mucho cuidado para evitar su inadecuado manejo.
− Observación del trabajo real del experto: Se denomina método de la observación

[Bac95]. Consiste en examinar la labor del experto en su ambiente de trabajo,
solucionando un problema como el que se está tratando de simular.
La ventaja del conocimiento que se adquiere en esta forma es que es muy

espontáneo, ya que el experto está tomando las decisiones sin tener mucho
tiempo para analizar el por qué de ellas. Además, no se le permite cuestionar si
está haciendo lo correcto o no, solamente él hace lo que cree que es mejor en esa
situación.
− Cuestionario: Es una encuesta muy bien diseñada que se utiliza especialmente

para cuando se requiere obtener las ideas que tienen varias personas sobre el
tema. Puede llegar a ser muy difícil de diseñar e inclusive, de manejar.
En el campo de la adquisición del conocimiento se han llevado a cabo numerosas

investigaciones que han dado muy buenos resultados, especialmente en lo referente a la
construcción de herramientas software que permiten automatizar el proceso, y también en
su formalización. Para más información ver [AVS+93] y [FAL98].
2.2.4.2 Representación del conocimiento
Este proceso consiste en coger el conocimiento extraído y representarlo en una forma

inteligible, primero por el ingeniero del conocimiento y luego por la herramienta de
software que se vaya a utilizar.
Cuando el IC hace la adquisición del conocimiento lo va registrando de alguna forma,

es así como comienza a realizar su representación. Después, de acuerdo con la forma
elegida, lo lleva al lenguaje del ordenador para que así quede reflejado en el software. Por
lo tanto, el IC debe conocer muy bien la herramienta de desarrollo.
Quizá lo más complejo de este proceso no es el conocer la herramienta, sino la

elección de la forma más apropiada, según el problema y el experto, de la representación
interna del conocimiento en el ordenador. Para los SBC se han determinado algunas
representaciones que se han convertido en estándar para ello, entre éstas están: la lógica
preposicional y la lógica de predicados, las reglas de producción, las redes semánticas, los
marcos (frames), los guiones (scripts), los lenguajes orientados por objetos y las redes
neuronales [Ben90].
Este proceso por lo tanto, consiste en la construcción de la base de conocimientos del

sistema.
2.2.4.3 Manipulación y pruebas
Después de representar el conocimiento, éste debe ser validado tanto por el ingeniero
del conocimiento como por el experto del dominio. Siempre se debe asegurar que el
conocimiento que se adquiere y que se represente es igual al proporcionado por el experto.
Mediante este proceso de manipulación y prueba se deben hacer todas los ensayos posibles
para evitar mal manejo del conocimiento, bien sea por problemas de interpretación de los
hechos, las heurísticas o las relaciones, o por problemas de obtención de malas
conclusiones y explicaciones.
Básicamente lo que se realiza es evaluar el conocimiento del SBC haciendo pruebas de

casos reales, con el fin de confrontarlos entre sí.
2.2.5 Metodologías para el desarrollo de sistemas basados en el

conocimiento
Las metodologías para construir SBC se caracterizan porque o son específicas para un
dominio o son propiedad de la empresa que las define (no son muy difundidas) o tratan de
ser lo más generales posible para que puedan servir de ayuda en la construcción del sistema
sin importar de qué tipo sea.
En los años 80 se crearon algunos métodos que servían para modelar SBC y que se
basaban en el nivel de conocimiento de Alan Newell [New82]. Este nivel permite describir
el razonamiento en términos de los objetivos a ser alcanzados, las acciones necesarias para
cumplir estos objetivos y el conocimiento necesario para ejecutar dichas acciones. Los
métodos se diferencian entre sí en la estructura que cada uno propone para analizar el
conocimiento, el grado de especificidad de la tarea, su relación con el código ejecutable, y
muchas otras propiedades, pero todas ellas basadas en la idea de construir un “modelo
conceptual” de un sistema que describe el conocimiento requerido y las estrategias en un
nivel lo suficientemente alto de abstracción, independientes de cualquier formalismo de
implementación en particular. Entre ellas está CommonKADS.
A continuación se presentan los métodos y metodologías más usados o reconocidos

para el desarrollo de SBC, clasificándolos según el área informática que propició su origen.
Se presentan primero las metodologías fundamentadas en la ingeniería del software y luego
las de la ingeniería del conocimiento.
2.2.5.1 Metodologías fundamentadas en la ingeniería del software
Siguiendo las directrices de la Ingeniería del Software más tradicional, se han

propuesto metodologías para desarrollar SBC con base en las ya existentes para construir
sistemas de información tradicionales, extendiéndolas para incluir muchas de las
características de los SBC, la construcción de un prototipo y la adquisición del
conocimiento como etapas formales del proceso. El problema que se presenta en muchas de
éstas es que no manejan la idea de modelos conceptuales o no involucran técnicas
orientadas por objetos, dado que fueron anteriores a estos paradigmas. Entre ellas están la
propuesta por [Edm88] y la de [GuT94].
Posteriormente, hasta mediados de la década del 90, los métodos que primaron en la
creación de sistemas basados en el conocimiento estaban fundamentados en el principio de
desarrollar un prototipo incremental desde el comienzo del ciclo de vida del sistema. Desde
que se definen las especificaciones del sistema se construye un software (prototipo) que las
refleja y que se va refinando en la medida en que se continúa con el análisis y el diseño,
hasta llegar a tener el sistema completo. Esta es la razón por la que se llaman por
prototipos, pues se van creando productos que se van evaluando y adaptando. Pero, hay
mucha insatisfacción con este enfoque porque se basa en implementar inmediatamente el
conocimiento obtenido e interpretado en un formalismo dado, sin construir modelos que
permitan hacer su abstracción y descripción en relación con el problema. Además, desde el

punto de vista administrativo es muy difícil realizar el control y el seguimiento de un
proyecto de este tipo.
2.2.5.2 Metodologías específicas de la ingeniería del conocimiento
La Ingeniería del Conocimiento (IC) es el área de la Inteligencia Artificial que se

relaciona con la construcción de Sistemas Basados en el Conocimiento, incluyendo los
procesos de adquisición y representación del conocimiento, y creación del sistema. “Provee
los métodos y las herramientas para construir SBC en una forma sistemática y controlable”
[SDF+00].
Puede verse también como una rama de la Ingeniería del Software que trata de
modelar el conocimiento de un dominio para construir a través de unos métodos y
herramientas un sistema – software de calidad. Esto último surge de la necesidad que se
tenía de crear sistemas basados en el conocimiento que estuvieran siempre respaldados por
un proceso formal de gestión y desarrollo, lo cual no era completamente proporcionado por
la Ingeniería del Software debido a los diferentes aspectos que se incluyen en un proceso de
conocimiento [AFS90].
Como resultado de la investigación en aspectos metodológicos de SBC han surgido

algunas propuestas y productos muy apropiados para soportar el proceso de construcción
del sistema. Se resaltan los siguientes: VITAL [Dom97], KSM [MoC95], MIKE [AFL+93],
PROTÉGÉ-II [EPG+94], KADS [BrW89] y CommonKADS [BFP+97]. Todas se presentan
en forma general, excepto CommonKADS que es la base de la propuesta de esta
investigación, entonces es la que más se detalla.
• METODOLOGÍA VITAL
Esta metodología [Dom97], es el resultado de un proyecto ESPRIT de

investigación y desarrollo en el que estaban involucradas diversas organizaciones
europeas, en especial de Inglaterra y Finlandia, que se fundamentó en los resultados de
otros proyectos como KADS (nombre anterior de CommonKADS).
Vital pretende crear una metodología y un software de soporte para desarrollar

grandes sistemas empotrados basados en el conocimiento. En ella, un proyecto de
desarrollo de un SBC está formado por cuatro etapas, llamadas procesos productos
[MOS+95]:
− Especificación de requerimientos: Descripción de la funcionalidad esperada de la

aplicación y las limitaciones o restricciones eventuales que deben seguirse.
− Modelo conceptual: Este proceso producto provee un modelo del experto que
captura las entidades relevantes del dominio, la estructura de la tarea y el
comportamiento que tiene el experto en la solución de problemas.
− Modelos del diseño: Comprende el modelo del Diseño Funcional y el modelo del
Diseño Técnico. El primero provee una descripción independiente de la
implementación del SBC objetivo y el segundo es una relación entre el modelo
del diseño funcional y el código ejecutable. Obviamente estos modelos dependen
de la situación específica de la implementación.
− Código ejecutable: Comprende todos los componentes del software embebidos en

la aplicación.
Su idea principal es la noción de tener un producto mediante un proceso (muchas

tareas) a través de un enfoque estructurado que cumpla lo siguiente:
− El desarrollo de una aplicación debe ser guiado por la construcción de un proceso

muy bien definido y bien documentado.
− El papel de cada proceso - producto - y sus enlaces con otros se debe hacer en
forma explícita.
− Hay una serie consistente y sistemática de técnicas y métodos que soportan la

construcción de cada proceso – producto -.
La ventaja de esta metodología es que da como resultado diferentes productos

que se integran para formar el todo y que se pueden actualizar para mantener fácilmente
el SBC. También hace la distinción entre la especificación y la implementación del
sistema, lo que facilita la verificación y prueba de la aplicación. También, proporciona
una herramienta de software llamada Alchemist que se compone de una serie de
módulos que asisten al usuario en el desarrollo del sistema y proporciona lenguajes
formales e informales para representar los modelos del nivel de conocimiento (VITAL
KML – Knowledge Modelling Language y KbsSF [DMW93]).
Una desventaja que presenta es que es una metodología que está orientada a la
adquisición del conocimiento de un SBC creando un modelo del nivel del conocimiento
del problema y del diseño de su código. A pesar de tratar la especificación, no es una
metodología que esté orientada a la fase de análisis. Además, para ser orientado a
sistemas empotrados no menciona cómo es la comunicación con el entorno en donde el
sistema está inmerso.
• METODOLOGÍA KSM
KSM (Knowledge Structure Manager). Es uno de los resultados del grupo de

investigación ISYS (Intelligent Systems) en el Departamento de Inteligencia Artificial
de la Universidad Politécnica de Madrid, España [MoC95], [CuM96]. Incluye y
extiende algunas de las ideas comunes de otros enfoques similares de metodologías y
herramientas de ingeniería del conocimiento como CommonKADS y Krest [Ste90].
Es otra metodología interesante vista como un ambiente que permite el desarrollo

de SBC orientado al conocimiento pues se enfoca en la identificación de los modelos de
entendimiento computables del problema que va a ser solucionado. Cubre los pasos del
análisis, el diseño, la implantación y el mantenimiento de una aplicación inteligente.
En ella se parte del concepto de unidad del conocimiento que permite elaborar su
modelado desde el mismo momento del análisis e incluso para hacer una reutilización
de él porque son modelos abstractos que facilitan que en el diseño se pase del modelo
de conocimientos a un código ejecutable. El modelo de conocimientos se comienza a
definir partiendo de la perspectiva del área de conocimientos que permite identificar el
cuerpo de conocimientos que se usa en un dominio específico, para solucionar
problemas determinados. Luego, se aplica la perspectiva de la tarea (define una meta u
objetivo a cumplir con sus entradas y salidas, y el método que especifica el cómo llegar
a esa meta). Este concepto de tarea es el mismo que se tiene en CommonKADS.
Específicamente en KSM se utiliza el lenguaje Link para construir estos métodos. Por
último, se tiene la perspectiva del vocabulario que incluye el léxico conceptual que
define los términos básicos para las áreas de conocimiento, a través del lenguaje
Concel. También, dentro de KSM se ofrece una forma para volver todo este
conocimiento en algo ejecutable por medio de unas interfaces y unas librerías.
Adicionalmente, se ha desarrollado un ambiente de software que soporta dicha

metodología y que ayuda a los IC en la construcción de versiones operacionales del
sistema final. Dicho ambiente está organizado por medio de tres componentes: un
ambiente orientado por objetos, un manejador del nivel de conocimiento y una interfaz
con el usuario. Su gran fortaleza está en que permite crear una versión ejecutable del
modelo del conocimiento.
Con esta metodología se han construido grandes sistemas, entre los cuales están:
Fluids, Trys, Bios, Artemis, Covalto y TCM.
La gran ventaja que tiene KSM es que construye modelos genéricos que pueden
ser reutilizados fácilmente. Pero el problema que presenta es que no proporciona los
criterios para hacer un análisis acerca de la situación inicial sino que parte de la
solución misma. Es decir, de la forma para adquirir y representar el conocimiento sin
saber si realmente es la mejor alternativa para solucionar el problema. Además, no está
enmarcada en todo el proceso de evaluación y planteamiento de proyectos, por lo que
no aplica conceptos de gestión de proyectos.
• METODOLOGÍA MIKE
MIKE (Model-based and Incremental Knowledge Engineering)

[AFL+93],[AFL+98] y [Neu93]. Esta metodología define un marco de trabajo para
extraer, interpretar e implementar conocimiento para construir sistemas basados en el
conocimiento, cubriendo todos los pasos desde la extracción hasta el diseño e
implementación del sistema. Su objetivo fundamental es el desarrollo de un modelo
detallado de procesos para soportar el proceso de ingeniería del conocimiento,
siguiendo con el modelo de ciclo de vida de Boehm [Boe93]. Es decir, en una manera
cíclica e incremental en donde nuevas observaciones pueden refinar, modificar o
completar las representaciones ya existentes.
MIKE propone la integración del modelo de ciclo de vida, prototipos y técnicas

de especificación semi-formal y formal en un marco de trabajo coherente. Para realizar
el nivel informal y semi-formal de descripción se utilizan los principios hipermediales
con nodos y enlaces de diferentes tipos, conteniendo el flujo de datos y el flujo de
control u otras relaciones entre nodos que puede ser semi-formalmente representadas.
Este nivel de representación se llama el hiper modelo y se utiliza para la comunicación
entre el ingeniero del conocimiento y el experto y como una base para la
documentación. Para la especificación formal se utiliza el Lenguaje KARL [AKS+93],
[AFS93], [FAL91], [FAL+93] que permite dar una representación del conocimiento
evitando que se presenten ambigüedades.
El proceso de desarrollo en MIKE consiste de 4 fases que se realizan en forma

cíclica de acuerdo con el modelo de espiral: adquisición del conocimiento, diseño,
implementación y evaluación. Cada una de éstas tiene una serie de actividades que
pueden ser también realizadas siguiendo el mismo modelo de espiral, haciendo un
procesamiento incremental.
La adquisición del conocimiento empieza con la actividad de extracción del

conocimiento a través de entrevistas estructuradas con los expertos, luego sigue con la
interpretación del conocimiento para obtener un modelo informal de los aspectos
funcionales y no funcionales del dominio, y por último se pasa a la actividad de
formalización y operacionalización para construir el modelo formal en KARL.
La siguiente fase es la de diseño, en la cual, además de lo anterior se consideran

los requerimientos no funcionales y se construyen los algoritmos y las estructuras de
datos a través del lenguaje DesignKARL. Posteriormente, se pasa a la fase de
implementación. En ésta se tiene el hardware y el software necesario para la
construcción del sistema y se traducen los modelos definidos con anterioridad a estas
plataformas. Por último, se tiene la fase de evaluación en la que se revisan los objetivos
iniciales contra los productos finales [AFS93], [AFS96]. Gráficamente el ciclo de vida
que se sigue en MIKE se aprecia en la Figura 2-1.
Ingeniería del Conocimiento
Adquisición del Conocimiento Diseño Implementación Mantenimiento
Análisis de Construcción del Evaluación Análisis de Construcción del Evaluación

la Tarea Modelo del Modelo Requerimientos Modelo del Modelo
Elicitación Interpretación Formalización /

Operacionalización
Figura 2-1 Fases del ciclo de vida de MIKE
La importancia de MIKE radica en la transición tan simple que propone para

pasar de las actividades de extracción del conocimiento hasta la fase de evaluación del
sistema final. Pero, hasta el momento sólo se centra en la construcción del modelo de
conocimientos para describir los requerimientos funcionales del SBC, como se pudo
observar en la Figura 2-1. Es así, como esta metodología se fundamenta más en la
integración de prototipos y el desarrollo incremental que en la construcción de
diferentes vistas del problema y del SBC.
• METODOLOGÍA Protégé-II
Protégé-II más que una metodología es un entorno de desarrollo y un conjunto de

herramientas que soportan la construcción de sistemas inteligentes y es propuesto y
creado en el Laboratorio de Sistemas de Conocimiento (KSL - Knowledge System
Language) de la Universidad de Stanford, Estados Unidos. La construcción del SBC se
hace seleccionando y modificando métodos de solución de problemas (PSM - Problem
Solving Method) reutilizables y ontologías del dominio [EPG+94].
Protégé-II provee un generador de herramientas de adquisición del conocimiento

que usa las ontologías del dominio como base, llamado Dash. Definen ontología como
un modelo simple de algún dominio del conocimiento; más formalmente es una
especificación del universo del discurso [GAM94]. Los expertos del dominio usan
dicho instrumento para adquirir el conocimiento que se requiere en la solución de un
problema determinado.
En Protégé hay dos tipos fundamentales de componentes:
− Conocimiento declarativo del dominio que puede ser reutilizado a través de

diferentes tareas de aplicación. La tarea es un modelo de la funcionalidad
requerida.
− Conocimiento procedural de solución del problema, tal como un método de

solución del problema, que puede ser reutilizado a través de diferentes dominio.
Protégé proporciona herramientas para definir ontologías del dominio

(descripción declarativa del dominio de la aplicación), del método (conceptos y
relaciones relevantes de los métodos de solución del problema) y de la aplicación
(conceptos y relaciones específicas de la aplicación). También, proporciona
herramientas para la adquisición del conocimiento y su traducción.
La construcción de un modelo de conocimientos se puede hacer en 3 pasos: 1)

formulación de la ontología del método, 2) definición de la ontología de la aplicación y
3) definición de las relaciones entre 1) y 2).
Una de las características importantes de Protégé-II es que ha considerado

diferentes tipos de usuarios: los expertos del dominio que tienen poco o incluso, ningún
conocimiento de programación, y los programadores. Esto ha permitido que tanto las
herramientas proporcionadas como sus interfaces, sean las apropiadas para cada uno de
ellos. Además, el grupo de investigación ha seguido creciendo y aplicando las
herramientas en el desarrollo de SBC que permiten validar su propuesta a través de
experimentos que miden el proceso de adquisición del conocimiento (para más

información ver [NoM99]).
La fortaleza de Protégé está en la construcción de la base de conocimiento con

información del dominio y del método de solución que opera en dicha base, haciendo
énfasis en la reutilización de esos métodos. Pero, cuando se analiza desde el punto de
vista de los conceptos de metodología que se han definido en esta investigación,
entonces se puede concluir que este método sólo se centra en el proceso de adquisición
para hacer el modelado del conocimiento y en la forma como éste se lleva en una
operación, dejando de lado las diferentes etapas de desarrollo de un proyecto, en
general. Por lo tanto, es un método de diseño e implementación.
• METODOLOGÍA CommonKADS
Tal como se dijo en la introducción, esta metodología se trata más ampliamente

que las demás por ser la base de esta propuesta.
2.2.6 Metodología CommonKADS
2.2.6.1 Perspectiva histórica
Es una metodología para la construcción de sistemas basados en el conocimiento,

resultado de varios proyectos enmarcados dentro del programa ESPRIT, para la innovación
y la aplicación de tecnología informática avanzada en la Unión Europea. Fue desarrollada
en la Universidad de Ámsterdam en cooperación con varios socios europeos, como
universidades, organizaciones de investigación, casas de software y de consultoría. Con ella
se han desarrollado muchos sistemas de conocimiento [CaP96] y por eso actualmente es
considerada por muchas compañías y organizaciones alrededor del mundo como un
estándar para la ingeniería del conocimiento y de los SBC.
Inicialmente, se planteó el desarrollo de un método para la adquisición del

conocimiento en el proceso de construcción de un sistema basado en el conocimiento y se
llamó KADS (Knowledge Acquisition Design System) [BAK92], [BrW89].
Posteriormente y dado los buenos resultados obtenidos, se amplió el proyecto a la

construcción de una metodología completa para el desarrollo de sistemas basados en el
conocimiento, la cual empieza desde el análisis mismo de la organización en donde se va a
hacer el SBC hasta la gestión del proyecto, pasando por el diseño del software. Es en ese
momento cuando se propone y acepta el nombre de CommonKADS.
CommonKADS está fundamentada en los siguientes principios [SAA+98], [SAA+00]:
• La ingeniería del conocimiento hoy en día se enfoca en la realización de actividades

de modelado, antes era vista sólo como un proceso de extracción de la pericia del
experto para traducirla a una forma computacional.
En CommonKADS un proyecto de conocimiento incluye la construcción de una

serie de modelos que constituyen parte del producto entregado. Estos modelos reflejan
diferentes puntos de vista del conocimiento inmerso en un problema y en su solución.
Cada uno tiene un propósito específico, unos productos asociados y unas estrategias
para su desarrollo. Es importante recordar que un modelo es una abstracción útil de
alguna parte de la realidad que hace posible focalizar ciertos aspectos e ignorar otros.
• El modelado del conocimiento primero se concentra en su estructura conceptual y

después en los detalles de la programación, aunque muchos constructores de
software tienen la tendencia a tomar el ordenador como el punto de referencia
dominante en sus actividades de análisis y diseño. En CommonKADS se sigue el
principio que esbozó Alan Newell en 1982 “para que el conocimiento pueda ser
modelado en un nivel conceptual debe ser independiente de las construcciones
informáticas específicas y de la implantación del software”.
• El conocimiento tiene una estructura interna estable en la que aparecen muestras

similares, lo que facilita su análisis para obtener tipos, patrones, roles y estructuras
del conocimiento específico, y así se modela como un todo funcional bien
estructurado, formado por partes que juegan diferentes roles restrictivos y
especializados en la solución de problemas.
• Un proyecto de conocimiento tiene que ser gestionado como un proyecto de

aprendizaje basado en la experiencia, en forma de espiral controlada.
CommonKADS de esta forma favorece el enfoque de administración de proyectos
ordenable, balanceado y que permite un aprendizaje estructurado, en donde los
resultados o “estados” de los modelos actúan como indicadores de gestión para saber
cómo se han realizado las actividades y qué pasos deben seguirse después.
• CommonKADS refleja la influencia de paradigmas ampliamente conocidos como el

análisis y el diseño estructurado, la orientación por objetos, la teoría de las
organizaciones, la reingeniería de procesos y la gerencia de la calidad. Esto tiene la
ventaja que toma en cuenta tanto la experiencia como las estructuras de información
existentes en la organización.
• Desde el punto de vista de CommonKADS, el SBC es un modelo operacional que

exhibe los comportamientos deseados que se han especificado u observado en el
mundo real.
[WVS+92], definen que el desarrollo de un sistema basado en el conocimiento, desde

el punto de vista de CommonKADS, es entendido como la construcción de una serie de
modelos de comportamiento de solución de problemas, vistos en su contexto organizacional
y de aplicación concreto. En estos modelos se incluyen tanto los conocimientos de los
expertos como los de otros sistemas del entorno, tales como la organización, el usuario y la
interacción entre éste y el sistema. Un SBC es una realización computacional asociada con
estos modelos.
CommonKADS también ofrece una serie de formularios que facilita la labor de

construcción del sistema y que permite obtener las especificaciones y los requerimientos de
un problema y su solución, desde el punto de vista de su relación con el resto de la

organización, de los entes que participan en el problema y del conocimiento que se requiere
para llegar al sistema final. Más adelante se ampliará este tema de los modelos. Estos
formularios son su forma estructural.
2.2.6.2 Ciclo de vida en CommonKADS
CommonKADS está fundamentada en el modelo del ciclo de vida en espiral que tanto
se trabaja en la Ingeniería del Software y que proporciona una estructura para el desarrollo
del sistema computarizado [WSB92]:
• El desarrollo se divide en un conjunto de fases con un orden de ejecución

predeterminado.
• Dentro de cada fase debe llevarse a cabo un conjunto de actividades distintas.
• Al final de cada fase han de producirse uno o más productos tangibles (por ejemplo,
documentos, informes, diseños, programas) normalmente como entradas a otras
fases.
La metodología está formada por una serie de etapas, cada una con unas tareas y
productos asociados. Brevemente éstas son:
• El Análisis: Se realiza para comprender el problema desde el punto de vista de la

solución que se piensa desarrollar. Está formado por la especificación de los
requerimientos externos del sistema basado en el conocimiento y por un análisis del
problema específico. Los productos que se deben obtener en esta etapa son: un
documento del proyecto, un documento de los requerimientos, un documento del
modelo (modelo conceptual), un documento de viabilidad y un documento de apoyo.
• El Diseño: En el cual se hace una descripción del comportamiento del sistema

(descripción funcional) y una descripción física en la que se especifica
detalladamente cada uno de sus componentes. De esta etapa debe salir toda la
especificación modular del sistema y la descripción detallada de cómo debe ser,
desde el punto de vista computarizado.
• Implantación del sistema: En esta etapa se considera tanto la integración del software
desarrollado como su adaptación en la organización.
• Instalación: Consiste en la puesta en marcha del sistema con el fin de que comience a
operar en la empresa, iniciándose su proceso productivo.
• El uso: Se plantean actividades relacionadas con el manejo mismo del sistema y de

las salidas o resultados que éste proporciona.
• El mantenimiento y refinamiento del conocimiento.

2.2.6.3 Los modelos de CommonKADS
Permiten describir el conocimiento de la solución de problemas en un dominio

particular usando niveles de abstracción que le posibilitan al ingeniero del conocimiento el
detallar el proceso de solución en una forma independiente del dominio [DMW+94]. La
idea central de esta metodología es agrupar los datos relevantes en modelos separados. En
la Figura 2-2 se presentan los diferentes modelos que soportan el análisis del conocimiento
en CommonKADS y que constituyen su núcleo.
Modelo de la
Organización
Qué Quiénes
Modelo de Modelo de
Tareas Agentes
Qué saben Cómo se
Con qué relacionan
Modelo de Modelo de
Conocimientos Comunicaciones
Base de conocimientos,
Razonamiento
interfaz
Modelo del
Diseño
Figura 2-2 Modelos de CommonKADS
• Modelo de la organización
Este modelo refleja el análisis de las características principales de una
organización con el objetivo de descubrir problemas que pueden ser solucionados por
sistemas de conocimiento, establecer su viabilidad y evaluar el impacto que tendría en
el entorno donde se implanten. Está formado por una serie de constituyentes o
conceptos que reflejan la información y el conocimiento de la organización, sus
problemas y sus soluciones, especialmente basadas en el conocimiento. En la Figura
2-3 se presenta su estructura, siguiendo la notación de [DBM+94]. Donde,
− El Contexto organizacional se relaciona con las características claves del

ambiente de la organización, tales como la misión, la visión, los objetivos de la
organización.
− Problemas y oportunidades: Constituyen la lista de los problemas de la

organización o las necesidades que son consideradas para ser más o menos
urgentes que pueden ser solucionados o mejorados por el SBC.
− Problema actual, referente a un problema o a una oportunidad en la cual la

compañía ha decidido hacer esfuerzos y que ha sido seleccionado de la lista de
Problemas y Oportunidades.
− Solución: Corresponde a los escenarios que han sido o serán desarrollados para
solucionar el problema actual o modificar las necesidades presentes.
− Función: Es un inventario de las funciones que pueden ser distinguidas en una

organización particular. Por ejemplo producción, finanzas, relaciones laborales o
comercial.
− Proceso: Se refiere al flujo de trabajo (work-flow) o de control (control-flow) de

los procedimientos básicos de la empresa.
− Estructura: Indica la disposición de la organización en función de sus

departamentos, grupos, unidades o secciones. También, la descripción del proceso
del negocio, entendiendo un proceso como una parte relevante de la cadena de
valor que es enfocada.
− Personas o roles que se juegan en una organización y que son fundamentales en

los procesos y funciones de la empresa.
− Conocimiento: Representa el conocimiento general y de alto nivel que puede

influir en la definición del problema actual o en sus soluciones.
− Recursos computacionales que soportan los procesos de la compañía.
− Otros recursos: Referente a los demás recursos (económicos, de papelería, de

propiedades, entre otros) que se requieren en la compañía para realizar las
funciones y cumplir con los objetivos de la organización.
− Cultura y Poder: Son las relaciones que existen entre los roles, las formas en que
se realizan las actividades y las políticas formales e informales que soportan la
organización.
Estos constituyentes están clasificados como variables o invariables para que se

puedan tener diferentes instancias del modelo en diferentes soluciones para el mismo
problema:
− Dependientes de la solución considerada. En la Figura 2-3 no están dentro de un

marco de líneas punteadas.
− Los invariables son los que en la Figura 2-3 están encerrados en un marco de
líneas punteadas. No dependen del tipo de solución en particular porque se
asumen como fijos.
En CommonKADS, también se han incluido unos formularios que contienen la

descripción de los constituyentes y que permiten que el Ingeniero del Conocimiento
refleje fácilmente la información relativa a su organización. A continuación se nombran
los que pertenecen al Modelo de la Organización (Organization Model - OM). En

[SAA+98] están detallados:
− OM-1: Identificación en la organización los problemas y oportunidades

orientados al conocimiento.
− OM-2: Descripción de los aspectos de la organización que tienen impacto en o

están afectados por la solución de conocimiento escogida.
− OM-3: Descripción del proceso desde el punto de vista de las tareas en que está
compuesto y sus características principales.
− OM-4: Descripción del componente de conocimiento del modelo de la

organización y sus principales características.
− OM-5: Lista de chequeo para el documento de viabilidad de la decisión.
Contexto
Organizacional
situado en Modelo
de
pertenece realizadas Agentes
mejorados por
Problema a Problemas y por
Soluciones Agente
actual oportunidades
respaldadas
se refiere a se refiere a por puede ser
tiene posiciones en
Estructura y Personas
organización -Roles-
derivado de mantienen puede
aplicado ser
posee
por
derivado aplicado
realizada en Cultura y Conocimiento por Recursos
poder de computacio.
requiere
Función realizada por Proceso Otros
usados
en recursos
define parte de
sirve
Tarea
Modelo
de Tareas
Figura 2-3 Modelo de la organización de CommonKADS

• Modelo de tareas
Para CommonKADS una tarea es una parte de un proceso de negocios que
representa una serie de actividades orientadas a alcanzar un objetivo, llevada a cabo por
unos agentes que siguen unos criterios de calidad y rendimiento. La tarea recibe
entradas y entrega salidas deseables en una forma estructurada y controlada, consume
recursos y requiere (y provee) conocimiento y otras habilidades. El análisis de tareas le
sirve al IC para organizar una vista de las tareas principales que un experto realiza en
un área dada y para determinar el alcance del SBC que servirá de soporte en el análisis
de viabilidad del proyecto.
En [Duu94] se dice "no es posible definir el concepto de tareas en cuanto a las

condiciones necesarias y suficientes, pero nosotros somos capaces de describir qué
clase de actividades y comportamientos se pueden considerar tareas y que pueden ser
aplicados muy útilmente en la metodología". A continuación se presentan estas
características:
− Una tarea tiene un comienzo y un final confirmados. Se ejecuta en un período

relativamente corto o puede ser dividida en sub-tareas que permiten que se
cumpla esto.
− Cada sentencia de la tarea debe ser entendida claramente por quien hace el
trabajo. Una sentencia es una serie coherente de actividades.
− La sentencia describe una parte finita e independiente del trabajo. Es decir, tiene
significado en el contexto del proceso y sus instrucciones deben dar una
descripción completa de la correspondiente tarea.
− Cada tarea debe ser manejable en función del tiempo consumido en su

realización.
− Una tarea comienza con una clave observable que permite definir cuando ésta es
iniciada. Es importante resaltar que en el caso en que la tarea sea continua, la
clave no existe.
− La sentencia de una tarea debe evitar el incluir calificativos.
− La sentencia usa un verbo, excepto cuando varias acciones se ejecutan juntas.
− La tarea se debe poder medir, su resultado o producto puede ser estimado o

medido.
Por lo tanto, el modelo de tareas permite reflejar el proceso de análisis de la tarea

elegida. El enfoque que presenta CommonKADS para este modelo tiene dos ideas
innovadoras: 1) Se pueden tener varias versiones del modelo para modelar las
situaciones actuales, intermedias y requeridas; varios modelos de tareas pueden ser
instanciados en diferentes estados de un proyecto. 2) El tener el modelo enmarcado en
un desarrollo orientado a los riesgos permite que se revisen continuamente.
Los constituyentes de este modelo se ven relacionados en la Figura 2-4 y son los
siguientes:
− Tarea: Entidad que representa una tarea del proceso y que es la parte central del
modelo.
− Característica: Refleja una propiedad de la tarea que la caracteriza en cuanto a un

lenguaje abstracto.
− Entorno: Representa las restricciones formales en la ejecución de la tarea, que son

establecidas dentro de la organización, a través de las leyes generales, de reglas
comerciales o profesionales.
− Ingrediente: Representación de una entrada de la tarea o ingrediente de salida. Un

ingrediente describe los contenidos de información que son usados o producidos
por la tarea. Esta descripción es orientada hacia la semántica de la información,
no a su representación sintáctica.
− Capacidad: Representación de una capacidad necesaria para ejecutar la tarea.
Modelo de la Modelo de
Organización Conocimiento
Función
Tarea
define realizadas
sirve por
implementada por
Otro tiene
subsistema Tarea Característica
implementada
por
Subsistema realizadas
SBC en
requiere
entrada salida
Modelo de Entorno
Diseño Capacidades Ingrediente
tiene
especificada suministra
por ejecutada Transacción
por especificado
en
Agente recibe Elemento de
información
Modelo de
Agentes Modelo de
Comunicación
Figura 2-4 Modelo de tareas de CommonKADS

Los formularios que se proponen para este modelo (TM) son:
− TM-1: Descripción refinada de las tareas dentro del proceso objetivo.

− TM-2: Especificación del conocimiento empleado por una tarea y posibles cuellos
de botella y áreas para mejorar.
Los resultados que se obtienen al construir las diferentes instancias del modelo de
tareas se utilizan en CommonKADS para:
− Documentar el resultado del análisis de las actividades actuales.
− Documentar el resultado del diseño de la tarea y sus actividades propuestas.
− Soportar la administración del cambio organizacional.
− Fijar el alcance de la solución del SBC.
− Soportar la evaluación de la viabilidad del proyecto.
− Identificar las necesidades de capacitación y entrenamiento.
− Evaluar la eficiencia, robustez y calidad del trabajo en la organización.
• Modelo de agentes
Para CommonKADS un agente es quien ejecuta una tarea. Puede ser un
individuo, un sistema de información o cualquier otra entidad capaz de llevar a cabo
dicha ejecución. Incluso el SBC por sí mismo es un agente para CommonKADS, lo
mismo que el usuario que va a interactuar con él.
La idea de agente que se maneja en CommonKADS es la de actor, no es

exactamente la misma que se trabaja en Agentes Inteligentes o en Sistemas
Multiagentes. Para este último, se ha presentado MAS-CommonKADS que es una
extensión de CommonKADS que permite modelar sistemas en los que se presentan
diversos agentes como sistemas distribuidos. Para tener más información al respecto ver
[Igl98].
Este modelo sirve como enlace entre el modelo de tareas, el de comunicación y

el de conocimientos para modelar las capacidades y limitaciones que los agentes tienen
y que están involucradas en la solución de la tarea.
En la Figura 2-5 se muestran los constituyentes del modelo de agentes de

CommonKADS [WaG93]:
− Agente: Se desarrolla por cada tipo de agente identificado. Tiene los siguientes
atributos:
o Nombre
o Tipo. Permite identificar si el agente es un humano o un sistema que debe ser
desarrollado en el SBC o un sistema que ya existe.
o Rol. Este atributo puede ser heredado del modelo de la organización.
o Posición. Se refiere al nivel en donde está el agente en la organización.
También puede ser heredado del modelo de la organización.
− Capacidades de razonamiento: Comprende todos los requerimientos de pericia del

agente, los cuales son importantes o impuestos por la asignación de la tarea y por
las necesidades de comunicación. Para los agentes que son componentes del
sistema y que son desarrollados dentro del mismo proyecto, este constituyente se
usa para comprender una especificación de uno o varios modelos del
conocimiento. Para los agentes humanos, es muy difícil hacer una lista completa
de estos requerimientos, por lo que sólo se especifican aquellos que son
determinantes para la funcionalidad del sistema o varían entre diferentes
usuarios.
− Capacidades: Este constituyente contiene dos atributos:

o Habilidades que se tienen para manipular el entorno en diferentes formas y
acceso a información sensorial. Esto está relacionado con los dispositivos
que pueden imitar los órganos de los sentidos como los brazos robóticos o los
sensores en el ordenador.
o Vocabulario. Describe el lenguaje de comunicación del agente.
− Restricciones: Éste tiene tres atributos, de los cuales los dos primeros solamente
se aplican a agentes humanos:
o Normas que se refieren a lo que el agente considera que es lo más apropiado
para hacer en ciertas situaciones.
o Preferencias de cómo le gustaría al agente realizar una tarea en particular.
o Permisos que tiene el agente dentro de una tarea.
Las relaciones que hay entre el modelo de agentes y los demás se interpretan de
la siguiente forma:
− Relaciones Organización – Agente: Todos los agentes corresponden a personas o

recursos en el modelo de la organización. La posición y el rol de los agentes son
coherentes con sus responsabilidades.
− Relaciones Tarea – Agente: Todas las tareas son asignadas a los agentes que son
capaces de ejecutarlas y todos los ingredientes en el modelo de tareas son
servidos y recibidos por los agentes relevantes.
− Relaciones Conocimiento – Agente: Las capacidades de razonamiento descritas

en el modelo de agentes son modeladas adecuadamente por (un subconjunto de)
el correspondiente modelo de conocimientos.
− Relaciones Comunicación – Agente: Todas las transacciones tienen al menos dos

agentes involucrados, uno que posee la información y otro que la recibe para el
mismo ingrediente. Al menos dos de los agentes involucrados tienen la capacidad
y los permisos requeridos para participar en la transacción.
Modelo de
Comunicación
Transacción
Restricciones
participa inicia
tiene en Soluciones
efectuadas por
Capacidades
tiene
Agente es un Recursos
tiene puede
Capacidades ser
de Personal
Razonamiento
recibe suministra ejecuta Modelo de la
descrito por Organización
Tarea
Conocimiento Conocimiento
de aplicación estratégico Ingrediente
Modelo del
Conocimiento Modelo de
Tareas
Figura 2-5 Modelo de agentes de CommonKADS
Para este modelo sólo se ha proporcionado el siguiente formulario (AM):

o AM-1: Especificaciones del Agente de acuerdo con el modelo de agentes de
CommonKADS
• Modelo de conocimientos
Su propósito es explicar en detalle los tipos y estructuras del conocimiento usado
en la realización de una tarea. Para su definición se ha desarrollado el lenguaje CML2
(CML - Conceptual Modeling Language) [AnS94], que proporciona todas las
estructuras necesarias para especificar los datos y el conocimiento del sistema. La
definición que se hace en este lenguaje, es independiente de la implementación del
mismo. CML2 está basado en el lenguaje (ML)2 [HaB92]. El modelo de conocimientos

sigue una estructura que determina las diferentes categorías del conocimiento que se
maneja en el SBC, como se puede apreciar en la figura 2-5.
En CommonKADS el conocimiento está diferenciado, dependiendo del tipo de

conocimiento que se trate (niveles). La importancia de separar el conocimiento del
dominio del de control es que permite hacer su reutilización. Así, el conocimiento del
dominio puede ser utilizado de nuevo para diferentes tareas y el de la tarea en diferentes
dominios.
− El conocimiento del dominio tiene como propósito definir la conceptualización

del dominio y debe ser representado en forma independiente de su uso.
− El conocimiento de inferencia define el primer tipo de conocimiento de control.

Especifica las derivaciones que constituyen un método de solución del problema,
la forma como se usa el conocimiento del dominio en las inferencias y los roles
del conocimiento que modelan las premisas y las conclusiones de las
deducciones.
− El conocimiento de la tarea representa una estrategia fija para alcanzar las metas
de la solución del problema. Por lo tanto es otro tipo de control que tiene como
propósito especificar el registro de la ejecución de los pasos de inferencia básicos
definidos en el conocimiento de inferencia.
El modelo de interpretación del SBC está formado por el conocimiento de

control, en este caso por el de inferencia y de tarea. Esto también se conoce como un
Método de Solución de Problemas que define en términos genéricos un modelo del
comportamiento de la capacidad de solución de problemas del sistema. Los PSM
forman librería que permiten su reutilización [BeM97], [Ben93] y pueden ser usados
como guía en la adquisición del conocimiento del dominio y del conocimiento adicional
de la solución de problemas específico del dominio, tal como las heurísticas y las
restricciones.
Categoría del
Conocimiento
Categoría de
Categoría del Categoría de la Tarea
Dominio Inferencia
Metas Estrategias
Inferencia Funciones de
Esquemas del Modelo del Transferencia
Dominio Dominio Roles del
Conocimiento
Conceptos Esquema
Relaciones Roles Roles
de Reglas
Dinámicos Estáticos
Figura 2-6 Jerarquía del modelo de conocimientos de CommonKADS

Para el modelo del conocimiento sólo se ha planteado el siguiente formulario

(Knowledge Model - KM):
− KM-1: Lista de chequeo de la documentación del dominio
Muchos métodos y metodología utilizan como base este modelo del

conocimiento, haciendo variaciones en algunos de sus conceptos, pero manteniendo la
estructura y la idea fundamental de reutilización [Abe92], [Abe93], [BrV94] [BrW89].
• Modelo de comunicación
El propósito de este modelo es especificar los procedimientos de intercambio de
información para realizar la transferencia de conocimiento entre los agentes que
participan en la ejecución de una tarea. Al igual que con el modelo anterior, esto es
hecho en una forma conceptual e independiente de su implementación [WHG+93].
El componente clave del modelo es la transacción que describe los actos de

comunicación entre los diferentes agentes que participan en una tarea en el sistema.
Dice qué objetos de información son intercambiados entre qué agentes y qué tareas.
Como plantea [SAA+98] “Las transacciones son bloques de construcción para el
diálogo completo entre dos agentes, lo cual es descrito en el plan de comunicación”.
Por tanto, la transacción por sí misma consiste de diversos mensajes que son detallados
en la especificación del intercambio de información, basada en tipos y patrones de
comunicación.
Este modelo se construye desde lo general hasta lo particular, de la siguiente

forma:
− Se define el plan completo de comunicación que dirige el diálogo entre los

agentes.
− Se determinan las transacciones individuales que relacionan dos tareas, llevadas a

cabo por dos agentes diferentes.
− Se especifica el intercambio de información que detalla la estructura interna de

los mensajes de una transacción.
En la Figura 2-7 se presentan los siguientes constituyentes o conceptos de este

modelo:
− Plan de comunicación: Describe los requerimientos en el orden de las

transacciones, siguiendo la sintaxis que se presenta en [WHG+93]. Contiene la
lista de tareas que son llevadas a cabo por el agente que se está considerando, la
descripción de éste, las funciones de transferencia que pertenecen a la estructura
de la tarea o de la inferencia que participan en la comunicación, y un diagrama de
estados o seudo – código que refleja la especificación del control sobre las
transacciones. Este concepto tiene dos atributos: Requerimientos y Preferencias.
− Transacción: Describe la estructura de las transacciones individuales. Una

transacción tiene como propósito básico transferir una serie de ingredientes del
dueño de la información a un recipiente de información. Cada instancia de la
transacción debería realizar al menos una instancia de la tarea de transferencia en
el modelo del conocimiento, excepto para la inicial que indica que el usuario
necesita usar el sistema para un propósito en particular. Sus atributos son:
Nombre, Tipo de comunicación, Ingredientes adicionales, Restricciones.
− Discurso: Define el plan para llevar a cabo la transacción en particular como un

conjunto de interacciones únicas o acciones lingüísticas. Se utiliza para expresar
cosas como el hecho que hay que suspender un mecanismo o para fraccionar la
transferencia de un ingrediente.
− Artículos de información: Deben precisar cómo se expresan las diferentes

acciones lingüísticas que ocurren en el discurso. Se utilizan para definir la forma
en que son transferidos los ingredientes. Este concepto está formado por dos
atributos: el objeto sintáctico y el medio de salida.
− Capacidades: Por cada parte involucrada en una transacción hay un conjunto de

capacidades que el agente tiene que tener para ejecutar dicha transacción. Para
esto, se tienen dos atributos: conocimiento y habilidad. El primero sirve para
describir el conocimiento relacionado con la tarea de razonamiento del sistema o
con el conocimiento del agente. El segundo se refiere a la(s) habilidad(s) que el
agente debe tener, aparte de su conocimiento, para participar en la transacción.
Modelo de
Tareas
consiste
Discurso Artículos de
de Transacción
Información
realizada por participa

Capacidades requiere en Modelo de la
participa Agentes
es parte de Transacción en
Agente
Plan de inicia
Comunicación
implementado
realizadas por por
Subsistema de
Funciones de interacción
Modelo del Modelo de

Conocimiento Diseño
Figura 2-7 Modelo de comunicaciones de CommonKADS

Al igual que los demás modelos, tiene unos formularios (Communication Model -
CM) que facilitan su construcción:
− CM-1: Especificación de las transacciones que participan en el diálogo entre dos

agentes en el modelo de comunicaciones.
− CM-2: Especificación de los mensajes y la información que forman una

transacción individual dentro del modelo de comunicaciones.
• Modelo de diseño
Proporciona la especificación técnica del sistema en cuanto a la arquitectura, la
plataforma de implementación, los módulos de software, los métodos y mecanismos
computables, necesarios para implementar las funciones ofrecidas en los demás
modelos [VDS+94].
Este modelo es diferente a los demás porque parte del mundo del software. Es
decir, está en el dominio del software del sistema ya que está relacionado con el
software y su organización interna. En cambio los demás pertenecen al dominio de la
aplicación.
Las entradas a este modelo son: El modelo de conocimientos que se puede ver
como una especificación de los requerimientos de solución del problema y las
manifestaciones de la interacción externa y requerimientos no funcionales definidos en
el modelo de la organización. Sirve para describir la estructura del sistema de software
que se necesita para construirlo en función de sub-sistemas, módulos de software,
mecanismos computarizados y constructores que se requieren para implementar los
modelos de conocimientos y de comunicación.
El proceso del diseño consiste de cuatro pasos que se pueden apreciar en la figura
2-7 y que son los siguientes:
Paso 1 Paso 2 Paso 3 Paso 4
Especificac.
Diseño Especificac. Diseño
detallada de
Arquitectura plataforma detallado
la arquitectura
Hw/Sw aplicación
Arquitectura de Lista de Lista de chequeo Relaciones

referencia de entornos de decisiones de la prefijadas a la
CommonKADS disponibles arquitectura arquitectura
Conocimiento de soporte dado por CommonKADS
Figura 2-8 Pasos del diseño del sistema

− Paso 1: Diseñar la arquitectura del sistema que define la estructura general del
software que se está construyendo y que comprende la descomposición del
sistema en sub-sistemas, un régimen de control global y una descomposición de
los sub-sistemas en módulos de software. Para este paso se cuenta con el
formulario (Design Model - DM) DM-1: Descripción de la arquitectura del
sistema.
− Paso 2: Identificar la plataforma de implementación objetivo, es decir, escoger el

hardware y el software que debería ser usado en el sistema. Para esto se tienen
una serie de características relevantes para considerar en el momento en que se va
a elegir el software: disponibilidad de las librerías de los objetos, representación
del conocimiento declarativo, interfaces estándar con otro software, flujo de
control, soporte de CommonKADS y, se cuenta con el formulario DM-2:
Especificación de las facilidades ofrecidas por y en el sistema objetivo que será
implementado.
− Paso 3: Especificar los componentes de la arquitectura. En este paso se diseñan en

detalle cada uno de los sub-sistemas identificados en el paso 1. Así que se hace el
diseño detallado de la representación, el control y las interfaces. Para esto
CommonKADS provee una lista de chequeo que facilita la toma de decisiones.
Se cuenta con el formulario DM-3: Lista de chequeo de decisiones en relación
con la especificación de la arquitectura.
− Paso 4: Especificar la aplicación dentro de la arquitectura. Se toman los

ingredientes de los modelos de análisis (tareas, inferencias, modelos del dominio,
transacciones) y se reflejan en la arquitectura. Para el diseño detallado de la
aplicación (paso 4) se tiene el formulario DM-4: Decisiones de la aplicación de
diseño que especifica las decisiones tomadas para cada uno de los elementos de la
arquitectura.
CommonKADS proporciona algunas ayudas para realizar cada uno de los pasos
del modelo de diseño:
− La arquitectura de referencias está basada en la metáfora Modelo-Vista-

Controlador (Model View Controller - MVC) que fue desarrollada como un
paradigma para diseñar programas en el lenguaje SmallTalk-80. En esta
arquitectura se distinguen tres sub-sistemas principales:
o El modelo de la aplicación que contiene las funciones de razonamiento. Los

datos estáticos son las bases de conocimiento y los datos dinámicos
manipulados durante el proceso de razonamiento.
o Las vistas que especifican las visualizaciones de las funciones y datos de la

aplicación. Hacen que la información estática y dinámica de la aplicación
esté disponible para los agentes externos.
o El controlador es la unidad de control que maneja los eventos internos y

externos.
2.2.6.4 Integración de los modelos
Los modelos de CommonKADS están clasificados en tres niveles o vistas que

posibilita el tener la información completa para construir el SBC en forma eficiente.
• El nivel del entorno, que relaciona la información del entorno del sistema de
conocimientos. Implica tener un entendimiento del contexto de la organización, de
su ambiente y de los factores críticos de éxito correspondientes al sistema de
conocimientos. En este nivel los modelos Organizacional, de Tareas y de Agentes
permiten responder a las siguientes preguntas: ¿Por qué un sistema de conocimiento
es una ayuda potencial o una buena solución de la situación actual? ¿Cuáles
problemas son los que se acoplan más con este tipo de solución? ¿Cuáles son los
beneficios, los costos y el impacto organizacional que tendría esta solución?
• El nivel de conceptos para especificar lo que se quiere modelar. Responde preguntas

como: ¿Cuál es la naturaleza y la estructura del conocimiento involucrado en la
tarea? ¿Cuál es la naturaleza y estructura de la comunicación correspondiente? ¿Qué
conocimiento se requiere para solucionar el problema? Por tanto, es necesario tener
modelos que presenten la descripción conceptual del conocimiento aplicado a una
tarea y los datos que son manejados y entregados por un sistema de conocimientos.
En este nivel se tiene el modelo de conocimientos y el de comunicación.
• El nivel del artefacto o componente para identificar los aspectos técnicos de

programación y de construcción en el ordenador. Da solución a preguntas del cómo:
¿Cómo tiene que ser implementado el conocimiento en un sistema basado en
ordenador? ¿Cómo debe ser la arquitectura del software? ¿Cómo se debe traducir el
conocimiento a un lenguaje comprensible por el ordenador? En este nivel está el
modelo de diseño.
Para ver la integración de los modelos es útil plantear un ejemplo sencillo en el que se
haga esto explícito: en la interacción entre un usuario que proporciona datos a un sistema de
conocimientos y en donde este último razona y le presenta resultados al primero, entonces
los modelos contendrían en términos generales lo siguiente: El modelo de agentes la
descripción de los agentes involucrados, junto con sus capacidades; el modelo de tareas
presenta las tareas, sus entradas y salidas (objetos de información) y su asignación a los
diferentes agentes; Si la tarea es intensiva en conocimientos, entonces se describe en el
modelo de conocimientos, incluyendo una función de transferencia que indique que la
entrada y la salida del proceso de razonamiento deben ser obtenidas o entregadas a otro
agente; En el modelo de comunicación se describe la comunicación entre los agentes que
participan en el sistema; y por último, en el modelo del diseño se especifica la arquitectura
física de dicho sistema.
Además de todo lo anterior, CommonKADS plantea una serie de consideraciones para

la Gestión del Proyecto de Conocimiento (Project Management - PM) [Anj99], formada
por cuatro actividades:
• Revisión. Se revisa el estado actual del proyecto y se definen los principales

objetivos para el ciclo siguiente. Es el primer estado en la administración del
proyecto de cada ciclo.
• Riesgo: Se identifican los obstáculos que pueden presentarse en el desarrollo del

proyecto y que pueden impedir que se cumpla con los objetivos definidos. Se cuenta
con el formulario PM-1: Identificación y valoración de los riesgos del proyecto.
• Plan. Se hace el plan detallado para el siguiente ciclo, en función del grado de
finalización de uno o varios modelos (estados de los modelos). Se tiene el formulario
PM-2: Cómo describir el estado del modelo como un objetivo a ser alcanzado en el
proyecto.
• Seguimiento, para registrar los cambios y lo resultados obtenidos.
Para cada una de estas actividades se ha definido una serie de documentos, reflejados
en la Figura 2-9, que deben ser creados al comienzo del proyecto y completados durante el
progreso de cada ciclo.
Seguimiento - Posición y propósito Revisión

- Reportes periódicos de
los progresos del ciclo dentro del plan
del proyecto
- Registro de las reuniones de
- Resumen de la salida del ciclo
evaluación y aceptación de las
salidas del ciclo anterior, definiendo el punto de
inicio del ciclo actual
- Revisión de las conclusiones de los - Objetivos del ciclo y bosquejo del
resultados actuales medidos contra los plan
proyectos de progresoso esperados, - Restricciones, alternativas
como una entrada para el siguiente consideradas, elecciones tomadas para
ciclo el ciclo
- Plan del ciclo, haciendo desglose - Lista y explicación de los riesgos
detallado de las tareas, la asignación identificados
de recursos, salidas del ciclo, - Valoración de los riesgos de acuerdo
valoración de riesgos y detalles del con el formulario PM-2
plan completo del proyecto - Conclusiones resultantes para el plan
- Salidas del ciclo basadas en los del ciclo y enfoque de desarrollo
estados de los modelos PM-1.
- Descripción de los
criterios de aceptación
sobre los cuales se
evaluarán las salidas
Plan planeadas del ciclo Riesgo
Figura 2-9 Documentación del ciclo de la gestión del proyecto en CommonKADS
2.2.6.5 Artefactos obtenidos al construir un SBC con CommonKADS
Si el proyecto se ha desarrollado siguiendo las pautas planteadas en CommonKADS,

entonces éste estará formado por 3 tipos diferentes de productos que permiten la
conformación del proyecto de conocimientos. Cada uno tiene una importancia relativa para
el proyecto final:
• Documentos detallados de los modelos de CommonKADS, incluyendo los

formularios diligenciados para el sistema en particular. Tal como se mencionó en la
sección 2.2.6.2 Ciclo de Vida en CommonKADS.
• Información relacionada con la administración del proyecto y su seguimiento,

presentado en la Figura 2-9.
• Software del sistema de conocimientos.
2.2.7 Ventajas y desventajas de CommonKADS
• Ventajas o Fortalezas de CommonKADS
Una de las principales cualidades de CommonKADS es el planteamiento del

desarrollo de modelos que reflejan diferentes vistas del proyecto. Entre ellos se resalta
el modelo de conocimiento en el que las partes que lo conforman son independientes del
dominio, es decir que son genéricas y puede ser usadas en otros problemas o SBC que
tengan características o comportamientos similares (los llamados modelos de
interpretación).
La gestión del proyecto que se plantea en CommonKADS es un punto importante

para destacar, ya que involucra aspectos administrativos que muchas veces no se toman
en cuenta al desarrollar un sistema informático. Esto permite que los productos que
resultan al aplicar la metodología, puedan ser valorados e integrados fácilmente en la
Gerencia de la organización.
CommonKADS es importante porque ofrece un marco para la especificación del

conocimiento independiente de la implementación, combinando un conjunto de
modelos de conocimiento reutilizable para unas tareas que se realizan frecuentemente,
como por ejemplo el diagnóstico o la planificación, entre otras. Además, propone un
ciclo de vida en donde se indican las fases, las actividades y los productos más
relevantes para un proyecto de desarrollo de un SBC.
Adicionalmente, los modelos que propone la metodología permiten reflejar

diferentes visiones fundamentales en el SBC, desde el punto de vista de la empresa
hasta la forma como éste se diseña. Dentro de estos modelos, el de Agentes y el de
Comunicaciones son particulares a CommonKADS, siendo quizá una de las debilidades
de las otras metodologías, pues no consideran la comunicación con otros sistemas.
Ambos modelos, le permiten al sistema coordinar las actividades con otros agentes y
ser más que un sistema basado en el conocimiento para ser un sistema que coopera con
otros.
Otro aspecto para resaltar de esta metodología es el hecho de que es una de las
más utilizadas para el desarrollo de SBC, tomándose incluso como el estándar europeo.
Numerosas universidades y empresas europeas como bancos y compañías entre otras
han realizado sus proyectos a través de las técnicas de CommonKADS.
• Desventajas o debilidades de CommonKADS
En general esta metodología cubre todos los aspectos que se necesitan para llevar
a buen término un proyecto de desarrollo de un SBC, desde el estudio del problema
hasta la implantación del software y su gestión. Los aspectos negativos que se presentan
son más de su aplicación que de su conceptualización, porque aplicar lo definido en ella
requiere de mucha experiencia y conocimiento de la misma metodología. Esto por
varias razones:
− La metodología es muy compleja y amplia.
− Hay mucha información relevante que está en diversos sitios, lo que dificulta su
acceso y comprensión.
− No hay una fuente de información que contenga todo lo necesario para su

aplicación.
− No hay un ejemplo completo de la aplicación de la metodología que pueda ser

utilizado como guía. Hay muchos ejemplos pero parciales.
Pero, a pesar de lo anterior y dado los objetivos de esta investigación, se decide

que CommonKADS es la metodología más apropiada para desarrollar sistemas basados
en el conocimiento.
2.3 Sistemas de tiempo real

En esta sección se presentan las generalidades de los sistemas de tiempo real, se
introducen los términos y definiciones utilizados en este tipo de sistemas y se hace mayor
énfasis en las metodologías y métodos más comunes que se tienen para desarrollarlos.
2.3.1 Generalidades de los sistemas de tiempo real

Un Sistema de Tiempo Real (STR) es un sistema informático en el que su buen
funcionamiento depende no sólo de la corrección lógica de los algoritmos y de las
respuestas obtenidas, sino también del momento en que éstas están disponibles [Sta88],
[StR93]. Por esto, para que el sistema esté operando apropiadamente es obligatorio que
proporcione los resultados dentro de un intervalo de tiempo conocido.
Una de las ideas erróneas que se tiene alrededor de este tipo de sistemas es que la
computación de tiempo real es sinónima de computación rápida. Esto ha sido muy discutido
y como lo menciona Ripoll [Rip98], es diferente un sistema de tiempo real a un sistema en
tiempo real, ya que este último se trata de un sistema que es muy rápido y da la sensación
de realidad. El objetivo de los sistemas de tiempo real es realizar su procesamiento
cumpliendo con unos requerimientos de tiempo previamente definidos [Ber98].
Los sistemas de tiempo real también se caracterizan porque tienen como componente
fundamental un programa de ordenador que interactúa con su entorno y que controla y
evalúa el tiempo en que se realizan sus actividades. Para poder cumplir sus especificaciones
temporales deben obedecer a unos requerimientos de: rendimiento (actuar dentro de los
tiempos que se han definido), oportunidad (responder en el momento apropiado y preciso) y
funcionamiento (estar lógicamente bien construidos).
Debido a las características propias que estos sistemas poseen, se han planteado
diversas formas de clasificarlos, algunas de ellas se presentan a continuación:
• Sistemas críticos (Hard Real-Time Systems), en donde es imperativo que el tiempo de

respuesta del sistema sea acotado y el incumplimiento de las restricciones del tiempo
causa un fallo grave en el mismo sistema o en el entorno. Estos requisitos temporales
tienen que ser conocidos con anterioridad para evitar errores en la computación:
“Tener tarde los datos es como tener datos malos” [Dou98].
Según el Manifiesto de Tiempo Real [RTM96] “una actividad (típicamente una

tarea) es considerada de tiempo real crítico si y solamente si ésta tiene un límite
máximo de tiempo crítico para la realización de una acción (típicamente, la ejecución
de la tarea completa), es decir, que el máximo límite de tiempo tiene siempre que ser
alcanzado o de otra forma el sistema falla”. Por lo tanto, el entorno de ejecución y las
propiedades de las actividades tienen que ser conocidas con anticipación para que
puedan ser alcanzados los tiempos definidos. Así, para que el sistema pueda ser
predecible tiene que ser determinista, o sea, que se conocen con anterioridad, tanto los
estados en que puede estar, como las entradas que requiere para que produzca una
salida que le permita pasar de un estado a otro.
En el ámbito de los STR se han especificado unos sistemas críticos en el que

además de la especificación del software, es fundamental el hardware. Estos se
conocen como sistemas empotrados y se usan para controlar equipo especializado que
está ubicado en el mismo entorno del sistema. Por ejemplo, el sistema de
microprocesadores usado para controlar la mezcla de gasolina / aire en el carburador
de muchos automóviles [Lap92].
Por último, es importante mencionar que se han desarrollado muchos STR

críticos, y entre ellos los ejemplos más típicos son: 1) sistema de un marca pasos
cardíaco. 2) el sistema que controla el frenado (ABS) de un coche. 3) el sistema que
controla un reactor nuclear.
• Sistemas no críticos (Soft Real-Time Systems), en donde su ejecución se degrada por

no cumplir, ocasionalmente, con una restricción de tiempo: “Tener tarde los datos es
aún tener datos buenos” [Dou98]. Pueden ser determinísticos o estocásticos. En este
último caso, algunas de las características de las actividades se pueden modelar
como variables estadísticamente descritas al azar. En general, un sistema de tiempo
real no crítico tiene que cumplir con el tiempo pero solamente en el caso promedio.
También de estos sistemas hay muchos ejemplos, entre los cuales están: 1) un
sistema para descomprimir y visualizar archivos mpeg. 2) El sistema de reservas de
vuelos en una aerolínea. 3) Un sistema de predicción del valor de las acciones en la
Bolsa de Valores.
• La clasificación de sistemas críticos y no críticos es la más conocida, pero Bernat en

[Ber98] propone un tercer tipo, llamado Sistemas débilmente críticos (Weakly Hard
Real-Time Systems). Son sistemas en los cuales se define una degradación de los
límites de tiempo que pueden ser incumplidos. Son críticos en el sentido que tienen
que garantizarse de antemano que su especificación temporal se cumplirá, pero
tienen algunas actividades no críticas que tienen asociado un tiempo promedio de
respuesta.
Hay también otra clasificación para estos sistemas, de acuerdo con el comportamiento
que tienen cuando se relacionan con el entorno [Dou99]:
• Sistemas orientados a eventos del entorno, en donde el comportamiento del sistema

es causado por reacciones específicas a sucesos producidos en el entorno.
• Sistemas orientados al tiempo, cuyas acciones están principalmente dirigidas por el

paso del tiempo. Por eso son sistemas que están orientados al manejo de tareas
periódicas más que a la llegada esporádica de eventos.
Un sistema de tiempo real responde a una serie de eventos que pueden ser producidos
en su interior o en su entorno, llamándose eventos internos o externos, respectivamente y
que se caracterizan por lo siguiente:
• Eventos periódicos o síncronos, son aquellos que ocurren en tiempos predecibles en

el flujo de control. Ya que se conoce cuándo se van a producir, entonces es posible
hacer una planificación anticipada de las acciones que el sistema debe realizar
cuando ocurren. Por ejemplo, se sabe que cada minuto el sistema va a recibir una
señal emitida por un sensor de luz.
• Eventos episódicos, aperiódicos o asíncronos, son los que arriban en forma

impredecible al sistema y por esto dificultan el cumplimiento del plan de acción y
respuesta del sistema y provocan que el sistema no sea determinista. Usualmente son
causados por fuentes externas [Lap92] y suelen tener asociado una frecuencia
promedio de llegada. Así, no hay o no se conoce una relación temporal entre dos
eventos consecutivos del sistema. Por ejemplo, cuando el sistema recibe una señal de
alarma que no estaba esperando.
Para comprender completamente esto, es importante aclarar que las actividades

internas de un STR se conocen como tareas que pueden ser periódicas o aperiódicas. “Las
periódicas consisten de una computación que es ejecutada repetidamente, en un patrón
regular y cíclico, en donde el tiempo de duración del intervalo entre el inicio de una
ejecución y la siguiente es una constante llamada período. Las tareas aperiódicas son
realizadas como respuesta a eventos asíncronos y requieren de una medida de su flujo de
llegada” [Ber98].
Con todo esto, ya es posible hablar entonces del desarrollo de estos sistemas. Así, de la
misma forma como ocurre con cualquier otro tipo de sistema, se tienen que realizar dos
etapas o fases importantes: la especificación y la implementación [Ber98]. La primera se
refiere a la determinación del comportamiento externo deseado del sistema y la segunda a
la forma en que el programa - software debe ser organizado para cumplir con las
especificaciones. Pero, la diferencia radica en lo que se define como especificación del
sistema, como se verá a continuación.
2.3.2 Especificación de los sistemas de tiempo real

La construcción de un sistema de tiempo real está formada por una serie de actividades
u operaciones que interactúan entre sí y con el entorno, y que se ejecutan continuamente.
Cada una de estas operaciones modela una pequeña parte del sistema que comúnmente se
llama tarea. Las tareas son así, una abstracción que permite simplificar la descomposición
de los problemas en subproblemas. Este término tarea no se debe confundir con el que se
utiliza en la fase de implementación, ya que en el contexto de la especificación una tarea se
corresponde con una meta que tiene que ser alcanzada normalmente (alto nivel) y en el
contexto de la implementación se refiere a un hilo de ejecución (bajo nivel). A continuación
se presentan las fases del desarrollo:
• La fase de la especificación tiene como objetivo el determinar el comportamiento

que el sistema debe tener para cumplir con su propósito. En el caso de un sistema de
tiempo real, además de esto, se aplica también a la determinación de los requisitos
temporales que el sistema tiene que cumplir y las propiedades que debe tener, lo que
se conoce como la especificación temporal.
La especificación temporal del sistema es fijada por la determinación de los

requisitos temporales del sistema. Los siguientes parámetros o variables permiten
expresar algunas de estas restricciones:
− El plazo de respuesta o deadline, que se define como el tiempo máximo que

posee una tarea para ejecutarse en cada una de sus activaciones. Es decir, la tarea
siempre debe finalizar como mucho cuando se alcanza dicho instante. Por tanto,
un deadline es una restricción temporal que se define para una tarea y que permite
determinar su tiempo máximo de realización o plazo de terminación.
− El mínimo o máximo retardo que tiene que transcurrir antes de comenzar la

ejecución de la tarea.
− El tiempo máximo transcurrido en el cual una tarea tiene que terminar una vez
ésta ha empezado su ejecución.
− El tiempo mínimo de separación que pasa entre dos instantes de inicio de una
tarea.
− El tiempo de respuesta que transcurre desde la entrada hasta la salida del sistema.
Como se puede observar, todas las anteriores restricciones son definidas para el
tiempo, por lo que es importante entonces tener claro lo que éste implica. Para
referirse al tiempo se puede hablar de tiempo absoluto (de acuerdo con el meridiano
de Greenwich o con el estándar de hora local que se esté usando) o de tiempo
relativo (tiempo que ha pasado desde que ha ocurrido un evento conocido en un
proceso). Por ello, cuando se vayan a definir los requerimientos del STR en el
análisis de requisitos, se debe identificar la referencia a utilizar, la forma en que se
debe medir y las unidades respectivas [HaP88].
Para que el STR cumpla con sus restricciones temporales, debe acatar las siguientes
propiedades:
− La predecibilidad (predictability) se refiere a conocer con anterioridad las

restricciones temporales de las tareas para poder determinar cómo se ejecutarán y
cumplirán. Por eso para que un sistema sea predecible, debe ser conocida la
información referente a su especificación temporal [StR93].
− La confiabilidad que consiste en garantizar que lo que se ha modelado es un buen

reflejo de la realidad para que el sistema resultante satisfaga todos los requisitos
del cliente. Como esto compete con el contexto de la implementación del sistema,
se ampliará más adelante.
− La precisión (accuracy) y puntualidad (timeliness). Las acciones del sistema

deben ser realizadas cumpliendo con los requisitos de tiempo preestablecidos.
• La implementación del sistema se refiere a la forma como el programa es organizado

para que se cumpla el objetivo planteado y las especificaciones lógicas y temporales
definidas. Para ampliar esto, ver [Ber98] quien trata el tema de una manera muy
detallada y comprensible.
Es importante decir que cuando se tienen sistemas que requieren manejo del
tiempo se deben considerar otros temas o áreas de la informática que pueden afectar
el cumplimiento de las propiedades del sistema. Es así como el hardware, el lenguaje
de programación, el sistema operativo, la arquitectura del sistema y las metodologías
de desarrollo juegan un papel trascendental dentro de estos sistemas.
− Hardware: además de tener mucha relevancia el procesador, la memoria, los

buses de comunicación y en general toda la parte física del sistema, se quiere
hacer énfasis en una de las características importantes del STR: es un sistema que
se relaciona con el entorno intercambiando información. Así, que las entradas y
las salidas de él usualmente se llevan a cabo por medio de hardware de propósito
específico que se clasifica en:
o Sensores, para leer el estado del entorno,

o Actuadores, para cambiar el entorno,
o Dispositivos de almacenamiento, para registrar el comportamiento del
sistema, y
o Una interfaz usuario – sistema, que sirve como medio de comunicación entre
un usuario humano y el sistema.
− El lenguaje de programación debe proporcionar el soporte apropiado para

desarrollar las características del sistema de tiempo real, ofreciendo instrucciones
especiales para declarar las diferentes restricciones temporales y para realizar su
análisis en tiempo de compilación. Debe garantizar que la creación correcta del
software sea confiable, modular, que se pueda mantener y permita la
estructuración de las tareas. Según [Sta92] el lenguaje debe contar con
procedimientos para el manejo y recuperación ante fallos; debe facilitar el
procesamiento en paralelo y la sincronización; debe permitir el acceso a los
dispositivos de hardware y manejar las interrupciones o solicitudes que se
requieran; y el código generado debe ser fácil de entender, leer y modificar para
facilitar su mantenimiento.
− El sistema operativo tiene un papel muy importante, ya que es quien debe dar el
soporte mínimo para garantizar los requisitos de tiempo real. Si el sistema
operativo es de tiempo real tiene como objetivo básico el conseguir planificar y
ejecutar las tareas o procesos de tiempo real de forma que se garantice que van a
finalizar a tiempo. Por tanto, la política de planificación se constituye en un
elemento crucial ya que el cumplimiento de los límites de tiempo de todas las
tareas dependerá del orden en que éstas se ejecuten.
− La arquitectura para el STR debería proveer soporte para la tolerancia a fallos

(fault tolerant), la planificabilidad (schedulability) y la administración del tiempo.
Para esto los temas de comunicaciones, multiprocesadores y procesamiento
distribuido deben ser estudiados, pero en esta investigación no se ampliará porque
no está dentro del objetivo de la misma. Un estudio más detallado se presenta en
[BaS86].
− Por último, para desarrollar un sistema de este tipo se debe considerar también la
forma en que se llevan a cabo las actividades conducentes a su construcción,
teniendo métodos y herramientas apropiadas para ello.
A continuación se presenta el tema de los métodos de desarrollo en forma más

amplia que los anteriores, dado que éste es parte fundamental del objetivo de esta
investigación.
2.3.3 Métodos para desarrollar sistemas de tiempo real

Como ya se mencionó, cuando se piensa en construir sistemas de tiempo real se debe
tener claro que éstos se diferencian de los sistemas tradicionales en que existen límites de
tiempo u otras especificaciones de requisitos temporales que están asociados a las tareas
que el sistema tiene que realizar. En los STR, la corrección (correctness) y el rendimiento
(performance) son aspectos que se consideran y valoran, lo cual no ocurre en otros tipos de
sistemas informáticos [BuW92].
Estos sistemas tienen una serie de características complejas que pueden ser
distinguidas de otros problemas o sistemas de software y que imponen varias necesidades
que tienen que ser incluidas en las notaciones de modelado [Deu88]. Resumiéndolas, éstas
son:
• Un sistema de tiempo real generalmente responde a estímulos o eventos externos que

deben ser conocidos con anterioridad para que el sistema responda apropiadamente,
a través de dispositivos que perciben (sensores) el entorno o de dispositivos que
actúan (actuadores) sobre dicho entorno.
• Muchos sistemas involucran procesamiento concurrente, es decir la ejecución

simultánea de múltiples cadenas o hilos de ejecución que pueden ser realizadas en
uno o en varios procesadores. Un hilo de ejecución es una serie de instrucciones que
se ejecutan en forma secuencial, síncrona.
Un STR no tiene que cumplir con todo esto a la vez, pero el método de modelado que
se elija debe proporcionar las herramientas necesarias para exhibir lo apropiado. Como dice
[SkG89], es importante que la especificación de un sistema de este tipo no esté muy
relacionada con su arquitectura para evitar perder generalidad, lo que muchas veces no se
puede hacer.
En cuanto al modelo del ciclo de vida, en general se utilizan los mismos de la

ingeniería del software. Por ejemplo, el modelo en cascada, el modelo de prototipado
rápido o el modelo en espiral de Bochm [Pre98], entre otros.
Es importante anotar que en el área de STR se habla de métodos y no de metodologías,

en general. Así, que se guardará ese rigor.
El método que se elija como base para desarrollar el STR tiene que ser un método de
diseño y no una notación de diseño. Es decir, un método de diseño es aquel que incluye
todas las etapas para desarrollar el sistema, no se habla en este caso de un método para la
etapa Diseño. Una notación sugiere un enfoque particular para desarrollar la etapa del
diseño, pero no provee un enfoque sistemático de pasos específicos para ejecutar todas las
etapas de construcción [Gom84], [Gom86], [Gom89].
En caso de diseñar un STR crítico, los métodos deben proporcionar las herramientas
para definir y modelar los requisitos temporales y garantizar los plazos de las tareas críticas
en el peor caso posible o los plazos de todas las tareas en el caso normal, aunque las tareas
acríticas puedan fallar en el peor caso [Del97]. Si el STR crítico es, además, empotrado,
entonces su implementación exige una mezcla de sistemas de hardware y de software, y
depende de muchos tipos de restricciones además de las temporales: peso, tamaño,
fiabilidad, costos, entre otras. Por lo tanto los métodos de diseño deben reflejar estas
particularidades. Uno de los métodos más conocidos para este propósito es POLIS (A
Framework for Hardware-Software Co-Design of Embedded Systems). Para más
información ver [Pol00].
Los métodos y metodologías que se utilizan para construir sistemas de ese tipo son
muy específicos y, en el contexto de esta investigación, se trabaja con aquellos que son más
generales, para aplicaciones que implican más esfuerzo en el análisis del problema y en el
diseño de una solución software.
A continuación se presentan los siguientes métodos: métodos basados en el análisis y

el diseño estructurado, métodos basados en el desarrollo rápido por prototipos, métodos
basados en el paradigma de objetos y métodos que están basados en otros paradigmas:
2.3.3.1 Métodos basados en el análisis y el diseño estructurado
Estos métodos son una extensión del Análisis y del Diseño Estructurado de Ingeniería
del Software. En ellos se evoca la estrategia de la descomposición funcional, en donde el
modelo del sistema es dividido en funciones, transformaciones o procesos y se utilizan los
flujos de datos y los de control para hacer las interfaces entre dichas funciones. El sistema,
por tanto, es estructurado como un conjunto jerárquico de diagramas de flujo de datos y de
control: El diagrama de contexto define los límites entre el sistema a ser desarrollado y el
entorno externo; el modelo entidad - relación permite identificar los almacenamientos de
datos del sistema y mostrar sus relaciones. En algunos métodos, también se utilizan las
máquinas de estado finito con el propósito de definir las características del comportamiento
del sistema.
Este enfoque es muy bueno cuando se puede fácilmente descomponer el sistema. “Sus
mecanismos integradores son las funciones y la jerarquía, los cuales aportan resultados
satisfactorios cuando las funciones están bien identificadas y son estables con el tiempo”
[Mul97]. Pero, como un sistema de tiempo real es restringido por requerimientos no
funcionales (por ejemplo, dependencia y tiempo), los métodos estándar no permiten

expresar bien ese tipo de restricciones [KaY92].
Una ventaja que se tiene cuando se desarrolla software con estos métodos es que ellos
han sido empleados en una gran variedad de proyectos y por lo tanto se cuenta con una gran
cantidad de personas capacitadas para asesorar en estos desarrollos y, además, en el
mercado hay disponibles una variedad de herramientas que facilitan su implantación.
El análisis y el diseño estructurado por sí mismo, tiene ciertas debilidades: No hay

muchas guías que muestren cómo realizar la descomposición del sistema, así que muchas
veces el sistema es dividido en diferentes formas por diferentes personas. Es difícil de
aplicar cuando se quiere estructurar el sistema en tareas concurrentes. No hay unos patrones
especiales que permitan modelar y reflejar las características de los sistemas de tiempo real,
sino que los tratan como si fueran sistemas con las mismas características generales de los
sistemas tradicionales. Muchas veces cuando hay evoluciones funcionales se producen
grandes cambios y surgen modificaciones que pueden ser muy pesadas.
Pero, a pesar de esto y precisamente para subsanar algunas de estas debilidades, se han
definido algunas extensiones de estos métodos para sistemas de tiempo real [Pre98]. Entre
ellos, los más conocidos e importantes son: el método de Hartley-Pirbhai y el método de
Ward y Mellor que a continuación se explican:
• MÉTODO HARTLEY - PIRBHAI
HPM (Hartley Pirbhai Method). Esta extensión es un método gráfico usado para
detallar tanto las funciones de un sistema de tiempo real como sus componentes físicos
[HaH94]. Para ello, se separan las especificaciones del sistema en dos modelos, uno de
procesos que permite representar los datos y los procesos que los manejan y otro de
control que ilustra cómo los sucesos externos hacen que se activen los procesos:
− El modelo de procesos se encuentra conformado por el diagrama de flujo de

datos y la especificación de procesamiento. El diagrama de flujo de datos
representa el flujo de información y las transformaciones que sufren los datos al
moverse desde la entrada hasta la salida de un proceso. La especificación de
procesamiento se utiliza para describir el procedimiento que se realiza al interior
de los procesos que se encuentran representados en el diagrama de flujo de datos.
− El modelo de control está formado por un diagrama de flujo de control y una

especificación de control que muestra cómo se comporta el software cuando
detecta un suceso o señal de control y los procesos que se invocan como resultado
de esa ocurrencia.
Ambos modelos se encuentran relacionados. El modelo de procesos le transmite

al modelo de control las condiciones de los datos y el modelo de control le pasa al de
procesos la información de la activación de los procesos. Cuando los datos de un
proceso hacen que se genere una salida de control se produce una condición de datos.
La especificación de control puede contener una tabla de activación de procesos

que indica los procesos del modelo de flujo que serán ejecutados cuando se produzca un
suceso y un diagrama de transición de estados que representa los estados y los sucesos
que hacen que el sistema cambie. La especificación del proceso contiene una
descripción en el lenguaje de diseño de programa (Language Design Program - LDP)
del algoritmo del proceso, las ecuaciones matemáticas, las tablas, los diagramas o los
gráficos.
En cuanto al análisis de las especificaciones, esta extensión también se puede ver

como los siguientes modelos [RaH00]:
− El modelo de requerimientos que describe lo que el sistema debería hacer (su

función), combinando el análisis estructurado tradicional y las máquinas de
estados finitos para definir su función. Determina que hay un conjunto jerárquico
de diagramas de flujo de datos, diagramas de flujo de control (un diagrama de
flujo de control por cada diagrama de flujo de datos) y máquinas de estado finito
que proveen las bases para la descripción del sistema.
− El modelo de la arquitectura que describe las entidades físicas del sistema y la

asignación de los requerimientos de esas entidades, asegurando la consistencia de
las interfaces. Incluye los diagramas de bloques funcionales que describen las
particiones físicas del sistema, un diagrama de contexto de la arquitectura que
muestra las fronteras físicas del sistema, los diagramas de flujo de la arquitectura
que muestran las entidades físicas (módulos), un diccionario de la arquitectura
que establece la combinación de los flujos de datos y de los de control, y un
diagrama de interconexión que representa los canales físicos, tales como cables
eléctricos, buses, cable óptico, conexiones mecánicas, por medio de los cuales los
módulos intercambian información.
Una de sus grandes fortalezas es que la separación entre los requerimientos y la

arquitectura obliga al ingeniero del sistema a identificar las funciones esenciales sin
restringir la implantación, ya que los detalles del diseño se le dejan a los diseñadores
quienes son los que más conocen cómo usar la tecnología disponible para cumplir con
los requerimientos del sistema.
En la Tabla 2-1 tomada de [HaP88] se reflejan las características y los beneficios

de este método.
Tabla 2-1 Características y beneficios del método HPM

Características Beneficios
− Modelo jerárquico (del sistema, a − Especifica los requerimientos en un nivel apropiado
subsistemas, a módulos, a componentes) − Representa una cantidad manejable de información
− Es top-down. en cada momento
− Representación gráfica y textual de la − Claramente muestra las interfaces (funcional y
funcionalidad física)
− Los gráficos representan los aspectos abstractos del
sistema
− El texto define los detalles
− Asignación de funciones a entidades − Mejora la consistencia de la interfaz
físicas
− Método riguroso − Promueve a fondo el diseño

− Identifica vacíos tempranamente
• MÉTODO WARD and MELLOR
Los autores de esta extensión, Ward y Mellor, crearon notaciones específicas

para el modelado de sistemas de tiempo real. Las características tomadas en cuenta por
ellos según [Pre98] fueron: 1) La información es percibida o generada de forma
continua en el tiempo; 2) se registra la información de control que pasa por el sistema y
el procesamiento de control asociado; 3) incluye las múltiples ocurrencias de una
misma transformación y las transiciones entre ellas.
Por esto, las principales variaciones que hicieron fueron las de agregar a la
notación del flujo de datos convencional la posibilidad de representar datos discretos y
continuos en el tiempo para poder vigilar la información continua que está siendo
generada por algún proceso. Hacen una diferenciación importante entre un flujo de
datos continuo y uno de datos discretos lo que permite que se aíslen los procesos que
son críticos para el rendimiento del sistema, en el momento en que éste se está creando.
Además, en el modelo físico en el que se define dónde y cómo se dará la recolección de
datos continuos, la notación permite establecer en dónde se necesita un hardware que
convierta señales analógicas a digitales y cuáles transformaciones requieren un software
de alto rendimiento.
El diagrama de flujos ha sufrido unos cambios al incluir una representación para

el de sucesos o de control en el que los flujos pueden ser una entrada directa de un
proceso convencional o de un proceso de registro. También tiene el procesamiento de
control cuando hay ocurrencias múltiples del mismo proceso de control o de
transformación de datos. Esto se puede presentar en entornos multitarea en los cuales se
activan las tareas como resultado de algún procesamiento interno o de sucesos externos.
La convención utilizada se presenta en la Figura 2-10:
Proceso
de datos
Flujo de datos
Proceso
de control
Elemento de control
Almacén de datos Almacén de control
Figura 2-10 Elementos nuevos del Diagrama de Flujo

En las Figura 2-11 y Figura 2-12 se presenta un ejemplo de la aplicación de estos

diagramas para modelar un STR que controla y vigila un respirador artificial que está
regulando la cantidad de O2.
Valor sen- Monitorización Valor de O2

sado de O2 y graduación del asignado
nivel de O2
Reducción del
nivel de O2
Figura 2-11 Modelado de un respirador artificial
Activación
de alarma
Estado del
sensor Comparación
Indicador de valores
de inicio
de acción
Pila/Buffer con valores
Interfaz de Procedimiento de
Datos
sensados monitoreo de regulación de
pacientes concentración de O2
Procesar
Ajuste de orden de
control de modificación
Botón de O2
comando del
médico
Órdenes del respirador

Órdenes de modificación
Figura 2-12 Modelado de un respirador artificial
2.3.3.2 Métodos basados en el desarrollo rápido por prototipos
Al igual que para los Sistemas Basados en el Conocimiento, se han propuesto diversos
métodos para la creación de Sistemas de Tiempo Real fundamentados en la idea del
desarrollo rápido por prototipo.
El problema de esto es que el prototipado rápido es de naturaleza ad hoc, difícil de

predecir y de manejar. Por esto, este tema no se trata con detalle en esta investigación. Pero,
por mencionar algunos métodos de este estilo, están los siguientes:
• El propuesto por [LuB88] en el que se combina un modelo secuencial de tiempo real

con un lenguaje de alto nivel para definir los prototipos, un método de diseño
sistemático para su construcción y un entorno automático.
• La metodología propuesta en el Departamento de Defensa de los Estados Unidos de

América, llamada ASSET (Aerospace Systems Simulation, Engineering, and Test
tool) [ShC94]. Consiste de un enfoque analítico para representar un STR y su
entorno, y de una arquitectura de hardware y de software. Integra el modelado, la
simulación y el desarrollo de pruebas operacionales sobre el ciclo de vida.
• La metodología propuesta en el proyecto IPTES (Incremental Prototyping

Technology for Embedded Real-Time Systems), basada en le modelo de ciclo de vida
en espiral de Boehm, que incorpora soporte para la ingeniería concurrente, toma de
decisiones y análisis de riesgos. Incluye la notación extendida de análisis y diseño
estructurado de Ward y Mellor. Permite especificar un modelo lógico que consiste de
un modelo del entorno y uno de comportamiento; un modelo físico formado por
subsistemas, procesadores, tareas y módulos; un modelo de implementación que
describe cómo se implanta el producto [San94].
2.3.3.3 Métodos basados en el paradigma de objetos
Básicamente, el paradigma de objetos está basado en los conceptos de objeto,

abstracción, ocultamiento y encapsulación de la información [Boo94]:
• El objeto se concibe como las entidades en el dominio del problema. La

especificación define las operaciones que pueden ser ejecutadas en el objeto y que
son la parte visible de él (el cuerpo del objeto está oculto para los demás objetos del
sistema).
• La abstracción es usada para establecer la separación de la especificación de un

objeto de su cuerpo.
• La ocultación de la información se usa para estructurar los objetos, es decir para

decidir cuál información debe estar visible y cuál no.
• El encapsulamiento de la información permite que los objetos tengan un cuerpo y

una estructura y que sean ocultos para los demás.
Un objeto, según Gomaa [Gom89] tiene unas características que son importantes de
resaltar:
• Tiene un estado que cambia como resultado de las operaciones entre los objetos del
sistema. Son sus datos persistentes.
• Es caracterizado por las acciones que él provee y que él requiere de otros objetos.
• Es una instancia única de alguna clase.
• Tiene restringida la visibilidad para o desde otros objetos.
• Puede ser visto por su especificación o por su implementación.
En los últimos años, la mayoría de los métodos que se han propuesto para hacer
sistemas de tiempo real han estado basados en el paradigma de objetos ya que presenta
grandes ventajas. La principal es que al estructurar el sistema en objetos se logra que éste
sea más fácil de mantener y que sus componentes puedan ser reutilizables.
Pero también presenta algunos problemas, como por ejemplo que la forma de la
solución depende sustancialmente de la estrategia informal usada para identificar los
objetos y que en términos generales no ofrece alternativas para el manejo del tiempo ni
tampoco considera importante la estructuración de las tareas de tiempo real. Por ello, los
que han planteado métodos orientados por objetos para hacer STR se han basado en algún
método ya existente y han definido una extensión propia que permita modelar
apropiadamente las características específicas de estos sistemas. Los más relevantes son:
HRT-HOOD, ROOM y RT-UML. A continuación se presentan éstos en más detalles.
• METODOLOGÍA HRT-HOOD
HRT-HOOD (Hard Real-Time Hierarchical Object Oriented Design). Esta

metodología es una extensión para tiempo real estricto de una metodología para el
diseño de objetos - HOOD [BuW94a] y [BuW94b]. Fue desarrollada por la Universidad
de York para la Agencia Espacial Europea (European Spatial Agency - ESA).
Básicamente está orientada al diseño del sistema y soporta el reconocimiento de los
tipos de actividades / objetos de acuerdo con los atributos que debe tener un STR (tipo
de tareas: Periódicas, aperiódicas, esporádicas, cíclicas). También permite hacer la
definición explícita de los requerimientos de tiempo para cada objeto de la aplicación y
la descomposición del sistema en una arquitectura lógica (objetos, operaciones y reglas
de descomposición jerárquica y uso) y en una arquitectura física (atributos temporales)
que es adecuada para trabajar con el análisis de planificabilidad de tareas y tiempos
[Del97].
HRT-HOOD hace una clasificación de objetos de acuerdo con las características

de tiempo real: en el programa hay objetos cíclicos, esporádicos, protegidos, y pasivos,
entre otros. Distingue entre la sincronización requerida para ejecutar las operaciones del
objeto (estructura de control del objeto) y cualquier actividad interna, concurrente e
independiente dentro del objeto (thread). Maneja los atributos del objeto para expresar
el límite de tiempo y el tiempo de ejecución en el peor de los casos.
[BuW94a] plantea que el diseño se centra en dos actividades básicas:

− Diseño de la arquitectura lógica, enfocado a satisfacer los requerimientos

funcionales. La arquitectura incluye los objetos, las operaciones y las reglas de
descomposición jerárquica y de uso. El proceso comienza con la producción de
un objeto activo o pasivo que es sometido a un proceso de descomposición y cuyo
resultado es una colección de objetos terminales (cíclicos, esporádicos,
protegidos, pasivos).
− Diseño de la arquitectura física para establecer los requerimientos no funcionales

(los atributos temporales) y se debe garantizar que estos se cumplan una vez se
haya realizado el diseño detallado y la implementación. En esta etapa se lleva a
cabo un análisis de planificación de los objetos terminales para garantizar la
confiabilidad del sistema.
HRT-HOOD está enfocado a las etapas de diseño lógico y físico y busca incluir
las características no funcionales de tiempo y dependencia lo más temprano posible en
el ciclo de vida de desarrollo. Su objetivo final es producir un diseño que facilite el
desarrollo de un método formal y que permita realizar un análisis de planificación.
Aunque ésta es una de sus fortalezas, también es una de sus debilidades ya que no hace
énfasis en el análisis del problema y su modelado gráfico. Por lo tanto, es más bien un
método de diseño.
• MÉTODO ROOM
ROOM (Real-Time Object-Oriented Modeling). Es un método para el desarrollo

de software de tiempo real que se basa en el paradigma de objetos y es el resultado de
un proyecto que se llevó a acabo en los laboratorios de Investigación Bell-Northern,
Estados Unidos [SGW94]. Provee un marco de trabajo completo para desarrollar
software orientado por objetos de tiempo real, utilizando algunos de los modelos
planteados en UML (Unified Modeling Language) para aplicar el paradigma de objetos
al mundo de los sistemas de tiempo real.
Por ello, en este punto se incluye una explicación breve de UML, ya que éste se
utiliza no solamente en ROOM, sino también en otros métodos y metodologías.
UML (Unified Modeling Language). “Es un lenguaje para especificar, visualizar,

construir y documentar artefactos de sistemas de software. Representa una colección de
las mejores prácticas de ingeniería que han sido probadas exitosamente en el modelado de
grandes y complejos sistemas” [OMG99]. Es una notación estándar para el modelado de
sistemas orientados a objeto aceptado por el OMG – Object Management Group [Mul97].
Como todo lenguaje de ese tipo está formado por elementos semánticos y elementos
sintácticos, con la diferencia de que es un lenguaje gráfico que usa una variedad de
elementos visuales para mostrar los elementos semánticos en una forma que es fácilmente
aprovechable y manipulable por un modelador [Dou00].
Los elementos semánticos se refieren a aquella parte del lenguaje que tienen un
significado subyacente, con valores, modos de operación y restricciones. Ejemplos de ello
son las clases, los casos de uso y los estados. Los elementos sintácticos son los que
permiten representar los semánticos. El conjunto de todos los elementos semánticos de un
modelo se denomina el modelo.
En UML se pueden observar tres tipos diferentes de modelos [Dou00]:
• De requerimientos. Hacen énfasis en la identificación de las características del

comportamiento del sistema más que de los objetos que lo conforman o su
implementación. Para esto utiliza los casos de uso que presentan la funcionalidad
externa del sistema.
• Estructurales. Permiten describir, tanto la estructura lógica del sistema como la
física. La lógica a través de las relaciones de herencia entre los elementos
semánticos que tiene que darse siempre y la física a través de las piezas físicas
que lo componen. Además, también se tienen que modelar las relaciones entre la
estructura física y la lógica. Entonces se utilizan los diagramas de clases, de
objetos, de despliegue y de componentes. Los dos últimos también se conocen
como los diagramas de implementación de UML.
• De comportamiento a través de las máquinas de estado que definen el

comportamiento de las clases y los casos de uso, y de los diagramas de
interacción que muestran el comportamiento de objetos o clases que colaboran
entre sí.
La perspectiva de UML está basada en una arquitectura de modelos y vistas, en

donde lo fundamental es cómo se definen esos modelos y lo siguiente es cómo ellos se
muestran gráficamente.
UML propone la utilización de las máquinas de estado finito (statecharts

[Har87]) para los modelos de comportamiento que definen la actuación de los objetos,
y los diagramas de interacción que representan la conducta de diversos objetos
colaborando en conjunto. Estos últimos pueden ser diagramas de colaboración que
resaltan el envío de mensajes durante la actividad de colaboración o diagramas de
secuencia que representan la sucesión temporal de los mensajes.
En el siguiente método que se presenta, RT-UML, se explicarán algunos de los

diagramas utilizados.
Entonces, ROOM utiliza muchos de los componentes que propone UML para el
modelado de las características del sistema. Pero, quizá lo importante de ROOM es que
está basado en el principio que se debe emplear un único modelo para todas las fases
del proceso de desarrollo de software (Análisis, Diseño e Implementación), lo que
facilita el desarrollar un STR. Además, esboza una notación simple y elegante para
describir un sistema o una aplicación.
El planteamiento que se propone es hacer un modelo operacional del sistema que

luego debe ser refinado hasta llegar a su implantación, utilizando el concepto de
modelos ejecutables como medio principal. Dichos modelos tienen una serie de vistas
de estructura y de comportamiento que son compiladas y ejecutadas.
Para ROOM, el software de tiempo real se describe como una red de

colaboración de máquinas de estado finito, llamadas actores, que reflejan el
comportamiento del sistema (son la estructura primaria y están encapsulados) y se
comunican por medio del intercambio de mensajes a través de sus interfaces o puertos.
El modelo de comportamiento de la máquina de estado finito establece que solamente
una transición a la vez puede ser ejecutada por cada actor y que éste permanece inactivo
hasta que le llega un mensaje que le indica que un evento ha ocurrido [Sel92], [Sel96a]
y [Sel96b].
El ciclo de vida del sistema está conformado por la especificación de los

requerimientos del usuario, una etapa de diseño en la que se realiza un modelo de la
solución, una etapa de simulación que se lleva a cabo empleando una herramienta
(ObjectTime) y una etapa de pruebas sobre los resultados de la etapa anterior. Ver
Figura 2-13. Si después de la simulación no se obtienen los resultados deseados, es
necesario repetir la simulación una vez hechas las modificaciones pertinentes hasta
cumplir con los objetivos, siendo así similar al desarrollo por prototipos.
Para el diseño se utiliza la descomposición para refinar gradualmente la

estructura interna y el comportamiento de un actor y la agregación para crear objetos
anidados complejos. Hay una notación de escenarios para describir el comportamiento
del sistema, en donde un escenario puede ser representado mediante una tabla de
secuencia de mensajes que permiten verificar en un momento dado la secuencia
operacional y la creación de escenarios posibles dentro de un proceso. Según [SFR98],
aunque estos escenarios permiten indicar los requisitos temporales no son muy
apropiados para ello porque no muestran realmente su comportamiento.
Especificación de los
requerimientos
Modelado de la
solución
Desarrollo de una
simulación
Implementación
Figura 2-13 Procesos fundamentales del desarrollo con ROOM
La plataforma de ejecución es típicamente el simulador ObjectTime, es una

herramienta comercial que soporta la creación, validación y administración de los
modelos de ROOM y su transformación en modelos ejecutables. En [BoG98] se puede
apreciar una aplicación utilizando ROOM.
ROOM tiene una serie de ventajas que la hacen muy poderosa para modelar el
comportamiento complejo que puede llegar a tener un sistema de tiempo real:
− Es orientada por objetos, lo cual permite explotar todas las fortalezas de ese
paradigma.
− Tiene conceptos de modelado específicos para el dominio de tiempo real, que

facilitan la construcción de modelos de estos sistemas.
− Permite hacer la definición de arquitecturas de alto nivel tanto de comunicación

como de captura, facilitando la detección inicial de los requerimientos o del
diseño.
− Ofrece la captura explícita y la documentación de las arquitecturas del sistema y

cuenta con un alto potencial para la reusabilidad, en la etapa de implementación
por parte de los lenguajes de programación [Sel92].
− Permite manejar actores dinámicos que reflejan los cambios que deben sufrir los
sistemas empotrados de tiempo real para poder responder rápidamente a cualquier
cambio del entorno.
La deficiencia que presenta se debe a que no hace énfasis en el análisis de la

solución, no incluye aspectos relacionados con la viabilidad de la solución y le faltan
herramientas para el modelado del tiempo. Por ejemplo, no habla sobre cuestiones
relacionadas con el sistema en tiempo real ni de la selección del lenguaje de desarrollo,
siendo este aspecto clave para la construcción efectiva del STR. Tampoco plantea
técnicas para hacer el diseño de las pruebas y la elección de equipo de verificación y
desarrollo [Lap92].
• METODOLOGÍA RT-UML
Como este enfoque es fundamental en la propuesta metodológica de

CommonKADS-TR se trata en forma más detallada que las demás, en la sección 2.3.4.
2.3.3.4 Métodos basados en otros paradigmas
Existen otras alternativas para el desarrollo de STR que son muy abiertas y que toman
algunos de los conceptos que son más comunes en ingeniería de software y los aplican.
Entre ellas están MCSE y DARTS:
• METODOLOGÍA MCSE
MCSE (Méthodologie de Conception des Systèmes Electroniques) o (Embedded

Systems CoDesign Methodology). Está orientada al desarrollo de sistemas de control de
tiempo real y tiene gran aplicación en el ámbito industrial. Cubre las fases de
especificación, diseño funcional (diseño preliminar), definición de la implementación
(diseño detallado) e implementación final del sistema [Cal97]. Fue desarrollada en la
Universidad de Nantes, Francia. Gráficamente, MCSE se puede ver en la Figura 2-14.
MCSE está basada en la idea que cualquier sistema puede ser observado por
medio de tres vistas, en donde cada una de ellas explica un aspecto específico y
adiciona información para describir el cómo del sistema:
− Una vista funcional que caracteriza las funciones internas del sistema.
− Una vista temporal que describe el comportamiento de las funciones internas,

expresando la contribución de cada una.
− Una vista del hardware o de los recursos que distinguen la parte física del
sistema.
También, en MCSE se propone un modelo compuesto por 3 dimensiones:
− La dimensión de la estructura funcional.
− La dimensión del comportamiento que usa modelos temporales para describir el

comportamiento de los componentes funcionales.
− La dimensión ejecutiva descrita por una estructura que expresa los componentes
hardware y las interconexiones necesarias para la operación del sistema.
Necesidad CONFORMIDAD Producto
Especificación Validación
VALIDACIÓN
Aceptación
Especificación
VERIFICACIÓN Validación Implementación

Diseño Diseño Funcional
Integración
PRUEBA
Especificación
implementación Implementación Implementación
hardware software
Figura 2-14 MCSE
El proceso de desarrollo del sistema que se sigue en este método es el siguiente:

1) Se hace la especificación completa del sistema que incluye su descripción

funcional, el análisis del entorno, el comportamiento de las entidades, la definición de
entradas y salidas, la especificación operacional y las especificaciones tecnológicas.
2) El diseño funcional basado en modelos que sugieren las funciones internas y el

acoplamiento específico entre dichas funciones, logrando que el diseñador se
concentre en los detalles más específicos del problema.
3) La definición de la implementación del software y del hardware.
4) La implementación final que es un documento completo en el que se tiene la

definición del hardware en una forma de estructura ejecutiva y la definición de la
implementación del software para todos los procesadores programables. Después se
hace una integración y pruebas para combinar todas las partes del desarrollo.
Entre sus ventajas se tiene:
− Es un método no restringido a un campo de acción específico.
− El diseñador tiene la posibilidad de seleccionar el método con el cual desea

ejecutar un paso.
− Posee modelos para describir especificaciones y soluciones.
− Tiene un esquema que facilita el control de las diferentes etapas de desarrollo de

un proyecto y presenta casos de estudio que pueden ser empleados por los
usuarios como una guía para la implementación de sus proyectos.
Quizá su única desventaja es que aún no se considera como un estándar para el

desarrollo de STR y falta que se le conozca más.
• METODOLOGÍA DARTS
DARTS (Design Approach for Real-Time Systems). Se fundamenta en la

descomposición del STR en tareas concurrentes y en la forma en que estas tareas se
comunican [Gom89]. Se puede ver como una extensión de los métodos de análisis y
diseño estructurado que permiten un enfoque para estructurar el sistema en tareas y un
mecanismo para definir las interfaces entre éstas. Fue desarrollada en el Instituto de
Ingeniería del Software de Carnegie Mellon, Estados Unidos.
Provee una serie de guías que siguen los principios de la descomposición y

plantea los pasos que permiten que el constructor del sistema pase de la especificación
del análisis estructurado de tiempo real a un diseño formado por tareas concurrentes.
Los pasos son:
− Hacer el análisis de flujo de datos para poder determinar las principales funciones
del sistema, sus subsistemas y componentes.
− Identificar las tareas concurrentes por medio de unos criterios que permiten
determinar si un proceso debe hacerse como una sola tarea o como una
agrupación de ellas representadas como programas secuenciales. Estos criterios
son un conjunto de heurísticas derivadas de la experiencia obtenida en el diseño
de sistemas concurrentes.
− Establecer las interfaces entre las tareas, definidas en dos clases de módulos: Uno
para la comunicación de las tareas y otro para su sincronización.
− Hacer un diseño individual de las tareas. Como cada tarea es un programa

secuencial, es posible hacer un diagrama de flujo de datos para cada una de ellas.
Luego, para su organización se emplea el método de diseño estructurado con los
diagramas de flujo de datos y flujo de control. Así, una función - transformación
- es agrupada con otras funciones en una tarea basada en la secuencia temporal en
la cual se debe ejecutar. DARTS utiliza las máquinas de estado finito para definir
el comportamiento del sistema y el desarrollo de prototipos evolutivos e
implementación incremental.
La especificación del tiempo de cada tarea se hace en el análisis estructurado de

tiempo real. Se usan diagramas de secuencia de eventos para mostrar la secuencia de
las tareas ejecutadas desde la entrada externa hasta la respuesta del sistema.
Según [Gom89] algunas de las ventajas que ofrece DARTS son:
− Proporciona unos parámetros que facilitan el establecimiento de las interfaces

entre las tareas, lo que le simplifica al diseñador la elaboración del diseño para
que sea más entendible.
− Provee una transición de las especificaciones del análisis estructurado de tiempo

real para el diseño de STR, y ya que este método de análisis es muy conocido y
usado, entonces se puede pasar fácilmente del análisis estructurado de tiempo real
hacia el diseño de tareas concurrentes.
Su desventaja mayor es que no utiliza el paradigma de objetos, por lo que ya se

ha planteado una variación de ella, llamada ADARTS, en la cual se hace una fase para
el ocultamiento de la información en reemplazo del diseño estructurado. Además, no
provee muchas guías para la descomposición del sistema, para lo cual se recomienda
hacer primero los diagramas de transición de estados antes que los diagramas de flujo
de datos. Es decir, que se recomienda ponerle más atención a las consideraciones de
control que a las funcionales.
2.3.4 Metodología RT-UML

RT-UML (Real-Time - Unified Modeling Language) [Dou98], [Dou99] plantea la
ampliación del lenguaje UML para poder hacer el modelado de las características de tiempo
real, permitiendo hacer el análisis y el diseño orientado a objetos para sistemas de tiempo
real crítico utilizando UML para modelar tareas de tiempo real, incluyendo los requisitos
temporales que ellas pueden involucrar. Fue elaborado conjuntamente por ObjectTime
Limited (creadores de ROOM) y Rational Corporation (creadores de UML).
2.3.4.1 Características de RT-UML
La metodología utiliza UML para componer diferentes tipos de modelos: los de

requerimientos, los estructurales y los de comportamiento, cada uno con sus propios
elementos semánticos y visuales.
Para el modelo de requerimientos se utilizan los casos de uso, que son una colección
de posibles secuencias de interacciones entre el sistema y sus actores externos, relacionados
con un objetivo en particular [Hil99].
Para el modelo estructural, se propone hacer una división de dos aspectos diferentes:
• La estructura lógica del sistema que refleja las relaciones inherentes entre los
elementos semánticos que tienen que ser verdaderos durante todo el desarrollo del
sistema y que UML lo modela como asociaciones entre clases, y
• La estructura física, que define las piezas físicas del sistema y la forma como ellas se
relacionan con los elementos lógicos.
Esta metodología tiene grandes fortalezas y una de ellas es el planteamiento en la parte

del diseño de una arquitectura del sistema, tanto física como lógica, que permite modelar
tareas concurrentes, hilos de ejecución, plantear patrones y mostrar su reutilización.
Además, considera diferentes técnicas para modelar el STR. Por ejemplo, ofrece los
casos de uso y escenarios para modelar la comunicación entre los diferentes agentes del
sistema; Los diagramas de estado para modelar el comportamiento de los objetos; Los
diagramas de secuencia para modelar las restricciones temporales en el envío de mensajes;
La representación de las tareas y su sincronización; Los modelos de la topología física del
sistema y los modelos de organización del código fuente.
Admite también, realizar una vista global de la solución a través de un diagrama de

contexto que captura el entorno del sistema, que incluye los actores que participan en el
mismo, y que deja caracterizar los mensajes y eventos que hay entre el sistema y su
entorno. Así, si el sistema es un objeto y hay otros objetos agentes interactuando con él, se
ve reflejado en el diagrama de contexto.
Junto con RT-UML se ha propuesto un ciclo de desarrollo iterativo basado en riesgos,

llamado ROPES (Rapid Object-Oriented Process for Embedded Systems) que usa el meta
modelo de UML estándar para su marco de trabajo semántico y de notación. Este proceso
de desarrollo se enmarca en un prototipo organizado alrededor de los casos de uso del
sistema. La idea central es mantener la corrección y disminuir el riesgo a través de un
análisis en dos dimensiones, la del tiempo y la de los componentes del proceso:
La dimensión del tiempo envuelve las siguientes fases:

• Inicio, en donde se define el problema a resolver, se enumera las entidades con las
que el sistema interactuará (actores), la forma en que lo harán (casos de uso) y se
analiza si es viable realizar el proyecto y si ésta es la mejor forma de implementarlo.
• Elaboración, en donde se busca establecer los objetos, las clases y sus relaciones. Se
definen los fundamentos de la arquitectura estructura del sistema y se desarrolla un
plan del proyecto para establecer las iteraciones en la fase de construcción.
• Construcción, para hacer o elaborar el software.
• Transición, para entregarle a los usuarios una versión de prueba del producto para su
evaluación.
Una vez se han hecho los cambios pertinentes se hace la entrega del producto y se da
la capacitación necesaria.
La dimensión de los componentes de los procesos incluye las siguientes actividades:
• Análisis de requerimientos para establecer lo que debe hacer el sistema.
• Diseño, cómo el sistema será desarrollado en la implementación.
• Implementación, es la generación del código para el sistema ejecutable.
• Pruebas, para verificar el funcionamiento correcto de todo el sistema.
Es importante resaltar que en cada fase de la dimensión del tiempo se aplican las
actividades de la dimensión de los componentes del proceso.
A continuación se presentan las características más importantes de los diagramas que

ofrece UML para modelar un sistema de información computarizado.
2.3.4.2 Diagramas de UML
• Los diagramas de clase representan la estructura estática del modelo, en particular,

las cosas que existen (tales como clases y tipos), su estructura interna, y sus
relaciones con las cosas. Estos diagramas no muestran la información temporal.
Una clase es un descriptor de una serie de objetos con estructura,

comportamiento y relaciones similares. Entonces, la clase representa un concepto
dentro del sistema que está siendo modelado, a través de la estructura de los datos
(atributos) y el comportamiento y las relaciones con los otros elementos. Las
relaciones que se pueden establecer entre varias clases son: la asociación (n-aria,
binaria), la agregación (parte de), generalización (es-un), dependencia, (instancia-
de).
• Los diagramas de objetos que son unos grafos de instancias, incluyendo objetos y
valores de los datos. Este diagrama es instancia del de clases, y muestran el estado
detallado del sistema en un momento del tiempo.
• El diagrama de los casos de uso es un grafo de actores, una serie de casos de uso,
posiblemente algunas interfaces y las relaciones entre esos elementos. Estos
representan la funcionalidad de un sistema como manifestación de entidades externas
que interaccionan con él. Se usan para definir el comportamiento de un sistema sin
especificar su estructura interna.
Catálogo de Teléfonos
Validación
del estado
Vendedor
Poner
Cliente orden
Llenar
orden Empleado de
transporte
Figura 2-15 Ejemplo de un gráfico de casos de uso
El actor define una serie coherente de roles que los usuarios del sistema pueden
jugar cuando interactúan con él. Los casos de uso especifican una secuencia de
acciones que el sistema puede ejecutar, interactuando con los actores. Las relaciones
son asociaciones entre los actores y los casos de uso, generalización entre actores, y
generalizaciones, extensiones e inclusión entre los casos de uso. Un ejemplo de un
gráfico de este estilo es el que se presentó en la Figura 2-15.
• Los diagramas de secuencia, muestran la secuencia explícita de estímulos

organizada en una secuencia de tiempo. En particular, muestra las instancias
participando en la interacción por sus líneas de vida y el estímulo que ellos
intercambian en una secuencia de tiempo. No muestra las asociaciones entre objetos,
pero si reflejan el tiempo.
Una colaboración se define como una serie de participantes y relaciones que

son significativas para una serie de propósitos dados. Una interacción especifica una
secuencia de comunicaciones; contiene una colección de mensajes parcialmente
ordenados que especifican una comunicación entre un rol que envía – emisor - y otro
que recibe – receptor -. Un estímulo es una comunicación entre dos objetos que
transmiten información con la esperanza de que una acción tenga lugar, así que un
estímulo provocará que una operación se realice u ocurra una señal o que se cree o
destruya algún objeto. Un mensaje es una especificación de un estímulo, es decir, de

los roles del emisor y del receptor, la acción que ocurrirá y cuándo se ejecutará.
llamador intercambio receptor

a: levantar auricular
b: escuchar tono
c: marcar dígito
< 10 seg.
d: enruta
tono sonando suena el teléfono
contesta llamada
para de sonar < 1 seg.

tono para
Figura 2-16 Ejemplo de un diagrama de secuencia
• Los diagramas de colaboración se utilizan en el diseño para mostrar una interacción

organizada alrededor de los roles en la interacción y sus enlaces entre sí. Presenta la
relación entre los objetos jugando diferentes roles, pero no los tiempos. Estos
diagramas son muy similares a los de secuencia pero si incluir el tiempo.
Los diagramas de secuencia y los de colaboración se conocen como Diagramas

de Interacción.
• Los diagramas de estados – statechart – pueden ser usados para describir el

comportamiento de entidades con un comportamiento dinámico, especificando sus
respuestas a la recepción de instancias de eventos. Describen posibles secuencias de
estados y acciones a través de las cuales el elemento puede proceder durante su
tiempo de vida como un resultado de reaccionar a eventos discretos (por ejemplo,
señales, invocaciones de operaciones). Se representan por un grafo que equivale a
una máquina de estados. A continuación se presenta un ejemplo de un diagrama de
este estilo. Ver Figura 2-17.
Un estado es una condición durante la vida de un objeto o de una interacción

durante la cual se satisface alguna condición, se ejecuta alguna acción o se espera
por algún evento.
Un evento es una ocurrencia de interés. Para propósitos prácticos en el diagrama

de estados, es una ocurrencia que puede disparar una transición de estado. Hay
diferentes tipos de eventos y de transiciones, pero para efectos de esta tesis no se
incluyen en esta memoria. Para más información ver [OMG99].
Timeout
OK/mostrar mensaje
después (15 seg)
después (15 seg) marcar dígito(n)
[incompleto]
TonoDial marcar dígito(n)
Marcando
OK/poner tono
Figura 2-17 Apartes de un Diagrama de Estados para un sistema telefónico
• Diagramas de actividad. Son una variación de las máquinas de estado en donde los
estados se representan por la ejecución de acciones o subactividades y las
transiciones son disparadas por la terminación de las acciones o subactividades. El
propósito de estos diagramas es enfocar la conducción de los flujos por el
procesamiento interno (opuesto a los eventos externos). Estos diagramas permiten
representar decisiones, actividades concurrentes, actividades en diferentes unidades,
entre otras cosas. Ver el ejemplo que se presenta en la Figura 2-18.
[costo<50] Cargar a la
Calcular costo
total cuenta del
[costo>=50]
Obtener
autorización
Figura 2-18 Apartes de un diagrama de actividades
Los diagramas de interacción junto con los de actividad y de transición de

estados se conocen como Diagramas de Comportamiento.
También hay unos diagramas que se llaman de Implementación ya que

presentan aspectos relacionados con la estructura del código fuente y la estructura de
implementación en tiempo de ejecución. Estos diagramas son: el de componentes y
el de despliegue, que a continuación se amplían.
• Los Diagrama de componentes presentan la estructura del código mismo, las

dependencias de los componentes de software, incluyendo los componentes del
código fuente, los componentes del código binario y los componentes ejecutables.
Como todos los diagramas de UML, éste también es un grafo de componentes
conectados por relaciones, que en este caso son de dependencia. En la Figura 2-19 se
presenta un ejemplo de un diagrama de este tipo.
Scheduler Asignación
Planificador Actualización
GUI
Figura 2-19 Diagrama de Componentes
• Los Diagramas de despliegue presentan la estructura del sistema en tiempo de

ejecución, es decir los elementos de procesamiento en tiempo de ejecución y los
componentes del software, procesos y objetos. En estos diagramas no aparecen los
componentes que no existen en tiempo de ejecución porque son de compilación. Las
relaciones entre los nodos son dadas por asociaciones de comunicación. Siguiendo
con el ejemplo presentado en la figura anterior, a continuación ( ver Figura 2-20 ) se
muestra un posible diagrama de despliegue para esa situación.
AdminServer:HostMachine
<<baseDatos>>
BDreuniones
:Scheduler Asignaciones
Figura 2-20 Apartes de un diagrama de despliegue en UML

2.3.5 Ventajas y desventajas de RT-UML
• Ventajas o Fortalezas de RT-UML
RT-UML tiene grandes ventajas cuando se compara con los otros métodos:
− A diferencia de ROOM que aplica el UML estándar con limitaciones para los
sistemas de tiempo real (por ejemplo el no tener un buen soporte del análisis
riguroso de tiempos y de los límites de tiempo), RT-UML hizo la ampliación del
lenguaje orientado a los sistemas de tiempo real.
− Aunque se ha creado con el propósito de desarrollar sistemas de tiempo real

críticos, es posible aplicarla a otro tipo de STR, ya que permite modelar todas sus
características.
− La metodología propone una fase de diseño muy completa, en la cual se incluyen

tres categorías basadas en el alcance y amplitud de las decisiones dentro de ellas.
Éstas son: El diseño de la arquitectura (relacionado con decisiones estratégicas
que afectan el sistema, tales como el conjunto de tareas y sus interacciones, el
conjunto de artefactos y sus interfaces y las relaciones entre los componentes y el
hardware físico); El diseño mecanístico (se refiere a cómo pequeños conjuntos de
clases y objetos colaboran para alcanzar metas comunes); El diseño detallado
(especifica detalles relacionados con el almacenamiento, los atributos, las
estrategias de implementación de las asociaciones, la selección de algoritmos
internos y la especificación del manejo de excepciones).
− Da la posibilidad de tener una alta reusabilidad al trabajar en su etapa de

elaboración con objetos y clases.
− Ofrece criterios para evitar hacer un mal uso de los diferentes diagramas de UML
y otros para su utilización, lo cual es una buena guía para el constructor del
sistema, en especial para aquellos que no tienen mucha experiencia en la
utilización del lenguaje de modelado.
− Ha sido probada en proyectos de gran envergadura.
− Ha sido adoptada por los pioneros del paradigma de objetos y de UML, lo que da
ciertas garantías.
• Desventajas o Debilidades de RT-UML
En general esta metodología cubre muchos de los aspectos que se necesitan para
llegar a buen término un proyecto de desarrollo de un STR, desde el estudio del
problema hasta la implantación del software. Pero, presenta algunos aspectos negativos
relacionados con la gestión del proyecto. Esto por varias razones:
− La metodología no plantea criterios específicos para construir un sistema de

tiempo real. Es decir, que no propone pautas que permitan seguirse para
determinar si ante una situación específica es posible construir un STR como
parte de su solución.
− La fase de análisis está completamente orientada a la solución, es decir, al análisis

de un sistema de tiempo real. Esto es negativo porque no se consideran otras
posibles alternativas de solución.
− Es una metodología que requiere tener muy buenos conocimientos de UML, lo

que dificulta su aplicabilidad, pues en general los desarrolladores de los STR no
tienen mucha experiencia en los lenguajes de modelado ni en metodología de
análisis y diseño de software.
− No hay muchas fuentes de información, a no ser que sean de UML.
− Las fuentes de información no presentan ningún caso o ejemplo completo de la

aplicación de la metodología que pueda ser utilizado como guía. Hay muchos
ejemplos pero parciales.
Pero, a pesar de lo anterior y dado las fortalezas que ofrece RT-UML, se ha elegido
como la más importante y actual para la construcción de STR.
2.4 Sistemas basados en el conocimiento de

tiempo real
En esta sección se exponen las nociones de los sistemas basados en el conocimiento de
tiempo real. En la primera parte se tienen las diferentes definiciones y enfoques que se han
propuesto para estos sistemas, luego aparecen las ideas básicas del tema que se asumen en
esta investigación y sobre las cuales se ha basado la propuesta metodológica, y por último,
se incluyen los métodos y metodologías más conocidos para la construcción de este tipo de
sistema.
2.4.1 Generalidades de los sistemas basados en el conocimiento de

tiempo real
La inteligencia artificial de tiempo real se basa en el razonamiento acerca de procesos
que están limitados por el tiempo y en donde se usa el conocimiento heurístico para
controlarlos y programarlos [Sta92].
En los últimos años se ha demostrado que es importante la combinación de teorías o

áreas informáticas como por ejemplo, la de los sistemas de tiempo real y la de la
inteligencia artificial porque así se pueden aprovechar los productos o resultados de las
investigaciones realizadas en cada una de ellas para generar sistemas más capaces y
poderosos en el razonamiento en el momento exacto.
De esta forma, los sistemas de tiempo real requieren garantías en el uso de los
recursos, tales como el tiempo, la memoria o el procesador. Las tareas que realizan en
términos generales, son repetitivas y reflejan métodos procedurales, con tiempos de
ejecución y patrones de llegada definidos, asegurando los tiempos de respuesta
establecidos. Su objetivo es producir un resultado en el momento apropiado. Pero, cuando
se aumenta la complejidad de los problemas que pretenden ser solucionados por ellos, es
necesario plantear la aplicación de otras técnicas y métodos como por ejemplo los de la IA.
La inteligencia artificial, se ha encargado de buscar técnicas para trabajar en entornos

variables e incompletamente especificados que requieren de una gran cantidad de
adaptación, creando modelos de computación que imitan la habilidad de los humanos para
trabajar con autonomía en ese tipo de entornos. Pero, no se ha preocupado si el entorno
impone restricciones en cuanto al tiempo para realizar sus tareas ya que está más interesada
en crear soluciones de calidad. Es decir, hacer sistemas diseñados para hacer las cosas
correctas. En general, no ha tenido en cuenta las restricciones o limitaciones de los recursos
físicos. El problema se presenta cuando se necesita que se integre el sistema al mundo real,
en donde las restricciones temporales se vuelven parte importante para el razonamiento del
sistema.
Por todo lo anterior, se pensó en crear sistemas que tuvieran las cualidades de los
sistemas de IA y un comportamiento apropiado para ser utilizado en entornos típicos de
TR- sistemas predecibles temporalmente -, como se explica en [VHB97]. Se afirma
entonces, que “los métodos de inteligencia artificial se están moviendo hacia dominios más
realistas que requieren de respuestas de tiempo real, y que los sistemas de tiempo real se
están moviendo hacia aplicaciones más complejas que requieren comportamiento
inteligente” [MHD+95]. Por lo tanto, si se fusiona apropiadamente un STR con uno de IA
se debe obtener un sistema que hace las cosas correctas en el momento oportuno. Desde el
punto de vista de Musliner [Mus93] es "hacer la mejor elección con base en los recursos y
el conocimiento limitado que el sistema tiene".
En [MHA94] se presenta un ejemplo muy claro y conciso sobre lo que es un sistema

que refleja ese comportamiento: "El vehículo que la NASA desarrolló para moverse en
Marte, tiene que operar a una distancia aproximada de 15 minutos luz de la Tierra y por lo
tanto no puede ser tele-operado. Este sistema tiene que operar continua y autónomamente
en un ambiente incierto y no completamente especificado; tiene que detectar y reaccionar
en el momento oportuno a situaciones imprevisibles pero peligrosas tales como
obstrucciones en las rutas de navegación o terrenos peligrosos que incluso no pueden ser
detectados por los sensores. Esta situación requiere que el sistema tenga procesos de
adaptación y de razonamiento que no son comunes en los sistemas tradicionales de tiempo
real. Afortunadamente, estos temas han sido tratados en diferentes áreas de la Inteligencia
Artificial".
Desgraciadamente, muchas técnicas de IA se caracterizan porque no son predecibles o

tienen una variación muy alta de su rendimiento, haciendo que sea muy difícil que se
garantice su ejecución para sistemas de control de tiempo real.
Muchas de las investigaciones en esta área se enfocan en restringir las técnicas de IA

para que sean más predecibles, proponiendo arquitecturas apropiadas para sistemas
inteligentes de tiempo real. Entre ellas se encuentran: CIRCA (Cooperative Intelligent
Real-time Control Architecture) [Mus93], [MHD+95]; AIS (Adaptative Intelligent Systems)
[Hay90], [Hay95]; Phoenix [HHC90]; REAKT [Rea90], [Rea93], [KeM94]; ARTIS
[GaB95], [GCB95], [Gar96], [CJG+97].
También, se ha trabajado alrededor de los diferentes sistemas que se pueden generar al

relacionar los sistemas de tiempo real y las técnicas de IA. [MHD+95], [Viv98], [Gar96] y
[Ona97] tratan ampliamente las tres formas básicas:
• A través de las técnicas de IA empotradas en un sistema de tiempo real. Se trata de

incluir los métodos de inteligencia artificial dentro de un sistema tradicional de
tiempo real, forzando las computaciones de IA para que cumplan con unos
deadlines, de la misma forma como lo hacen las tareas de tiempo real. Por lo tanto,
el propósito es “ser inteligente bajo tiempo real”.
• “La integración de tareas de tiempo real en el sistema de IA. El sistema se comporta

como un sistema inteligente convencional, pero cuando se produce un evento que
requiere una respuesta de tiempo real, las tareas inteligentes son inhibidas para
ejecutar una tarea de tiempo real” [Viv98]. Ejemplo de estos sistemas son SOAR
[RLN+91] y PRS [IGR92].
• El acoplamiento entre un sistema de IA y uno de tiempo real como componentes

paralelos que trabajan en forma colaborativa, en donde cada uno tiene su propio
comportamiento y entre los dos cooperan para obtener un resultado deseado. Con
este enfoque lo que se pretende es que cada uno de los sistemas mantenga sus
fortalezas y no interfiera en el comportamiento del otro. El sistema global sería
inteligente acerca del tiempo real. Como ejemplo de este enfoque está CIRCA (The
Cooperative Intelligent Real-Time Control Architecture) propuesta por David
Musliner en 1993 [Mus93].
Como se puede observar, estas formas de sistemas no declaran una técnica o área
específica de la Inteligencia Artificial, se habla en forma general. Por lo tanto, es posible
instanciar el término a cualquiera de ellas (mencionadas en la sección 2.2), concretando o
especificando más según las características del área instanciada. En esta investigación la
particularización se hará hacia los sistemas basados en el conocimiento, de la siguiente
manera:
2.4.2 Tipos de sistemas basados en el conocimiento de tiempo real

Como ya se había dicho, los sistemas basados en el conocimiento se pueden ver como
un área específica de la inteligencia artificial. Los sistemas que allí se construyen
básicamente se reconocen porque son para un dominio específico y tienen el conocimiento
separado del razonamiento para solucionar problemas de una forma similar a como lo haría
un experto en dicho dominio. La capacidad para garantizar una respuesta en un tiempo fijo,
dado por el estado del problema es la principal característica que tienen que cumplir el
SBCTR y debe ser aplicado a dominios en donde los problemas sean dependientes del
tiempo, tales como el control de procesos, la monitorización, el diagnóstico y
mantenimiento de fallos, la planificación reactiva, entre otras [BBO+93].
Tradicionalmente los SBC no manejan restricciones temporales ni en su conocimiento

ni en su razonamiento, lo cual puede ser necesario dependiendo de si se requiere que el
sistema reaccione a eventos del entorno como ocurre en los STR. Pero, como ya se ha
dicho, el dominio de problemas de tiempo real es muy diferente de aquellos en los que
tradicionalmente se han aplicado los SBC porque las técnicas de solución de problemas
basadas en conocimientos han sido utilizadas en situaciones en donde los datos son
estáticos y no se requieren respuestas con tiempos críticos [LCS+88], [Laf91].
Las formas presentadas en la sección anterior, implican de por sí definir unas

características muy propias tanto para el sistema resultante como para las técnicas o
métodos utilizados para su desarrollo, por lo que a continuación se presenta cada una de
ellas para el caso de que el sistema inteligente sea un sistema basado en el conocimiento,
creándose entonces tres tipos de sistemas basados en el conocimiento de tiempo real.
• Sistema de tiempo real que tiene algunas tareas basadas en el conocimiento
En este caso, el STR mantiene el comportamiento temporal, pero algunas de las tareas
que debe realizar son SBC. Así, la planificación del sistema incluye la realización de unas
tareas basadas en heurísticas o en técnicas propias de la ingeniería del conocimiento y los
algoritmos de búsqueda y de control del motor de inferencia deben estar acotados para
realizar su función. El asunto importante en este tipo de sistemas es cómo garantizar la
ejecución del SBC y cómo hacer que cumpla con los tiempos asociados.
• Sistema basado en el conocimiento operando en situación de tiempo real
En este caso, el resultado será un sistema que maneja su conocimiento y su

razonamiento de acuerdo con unas restricciones temporales. La base de conocimientos
tendrá además de su estructura de representación del conocimiento unos tiempos de
ejecución asociados con las relaciones que la conforman.
“Un sistema basado en el conocimiento que opera en situaciones de tiempo real

necesita responder a un entorno cambiante de tareas involucrando un flujo asíncrono de
eventos y de requerimientos que varían dinámicamente con limitaciones en el tiempo,
hardware y otros recursos” [LCS+88]. Para ello se requiere tener una arquitectura de
software que proporcione un razonamiento que se adecue rápidamente, que considere
restricciones estrictas de tiempo, el manejo de interrupciones e incluso el manejo de ruido
en la entrada. Cuando al SBC le llega una señal o evento que tiene que ser atendido en ese
mismo instante, entonces interrumpe por completo lo que estaba haciendo y pasa a ejecutar
la tarea específica de tiempo real. Cuando la situación vuelve a la normalidad, entonces el
SBC continuará con su trabajo.
Este tipo de sistemas se necesita porque como menciona Turner en [LCS+88], “la
principal razón para usar un sistema basado en conocimientos de tiempo real es reducir la
carga cognitiva en los usuarios o permitirles incrementar su productividad sin que la carga
cognitiva se les incremente”. Esto tiene muchas implicaciones en el ámbito tecnológico y
social pues hace que la persona que maneje el sistema no tenga que tener todos los
conocimientos del problema y su solución, o en aquellas situaciones que si se requiera le da
la posibilidad de manejar simultáneamente la información completa. Así como un sistema
basado en el conocimiento tiene una utilidad muy especial, estos sistemas también.
• Sistema basado en el conocimiento acoplado con un sistema de tiempo real
En este caso sería lo mismo que lo expresado para el caso general de tener cooperación
entre un sistema de IA y un STR. La clave de este tipo de sistemas es la forma en que se
define la comunicación y la cooperación entre los dos sistemas que lo conforman, lo cual
está fuera del alcance de esta investigación.
2.4.3 Aplicaciones reconocidas de los sistemas basados en el

Para hablar de la aplicación de los SBCTR no se hará referencia a algún tipo en
especial sino a todos en general. Se han planteado muchos sistemas informáticos o
herramientas de desarrollo que combinan las dos tecnologías en diferentes formas [MiG92],
[VHB98]. Hay muchos campos de utilidad de los SBCTR, pero en especial se han
destacado en el aerospacial, las comunicaciones, la medicina, el control de procesos y
sistemas robóticos, entre otros. A continuación se presentan algunos ejemplos de estos
casos:
• Una de las áreas que busca encontrar soluciones inteligentes es la del monitorización
de alarmas y el diagnóstico de fallos porque cada vez se están creando plantas más
complejas que requieren de la intervención de operadores en caso de fallo. Un primer

caso es la reducción del número de alarmas, lo cual involucra realizar el análisis de
la serie de indicadores de alarma que pueden ocurrir cuando un proceso tiene
problemas. Esto aparentemente es una situación de monitorización de variables, pero
cuando el proceso tiene problemas, un solo fallo puede resultar en una multitud de
condiciones de error que dificultan la toma de decisiones del operador humano. Así,
un sistema basado en el conocimiento puede investigar los patrones de los mensajes
de alarmas, incluir sus secuencias de tiempo y examinar las relaciones causa – efecto
bajo la óptica de la dinámica de la planta bajo control. Otro caso sería el tener un
sistema para monitorizar de la planta y usando las medidas apropiadas de predicción,
pueda prevenir las condiciones de las alarmas. [RVK92].
• El sistema ESSOC (Expert System for Satellite Orbit Control) que fue diseñado para
asistir en las maniobras de mantenimiento de estaciones de satélites (Delta V). A
partir de datos de telemetría del satélite determina los comandos apropiados para
ejecutar maniobras exitosas. Este sistema analiza los datos durante la rutina de
chequeo del estado del satélite, diagnostica las causas de anomalías y recomienda
comandos que las resuelven.
• El sistema FLES (Flight Expert System) fue diseñado para asistir al piloto de un
avión en las tareas de evaluación, análisis y diagnóstico de fallos en los sistemas de
la nave. Este sistema está basado en el modelo blackboard de Hearsay, en donde se
tienen fuentes de conocimiento que representan analizadores de interrupciones
provocadas por los sensores. El sistema con base en esas entradas construye una
serie de hipótesis sobre las posibles causas de las interrupciones, a través de un
procedimiento de verificación confirma si un componente no está operando y unos
procedimientos de diagnóstico determinan si el componente es la causa del fallo o es
un efecto de algún otro problema [AlS85].
• HANNIBAL es uno de los primeros sistema que se hicieron en el área de las

comunicaciones. Su razonamiento está relacionado con la interpretación de datos
obtenidos a través de sensores que observan las comunicaciones de radio, con el
objetivo de identificar unidades enemigas y su comunicación en la batalla. Los datos
que se reciben incluyen información acerca de la localización de las comunicaciones
detectadas y las características de la señal. Este sistema, al igual que el anterior, está
construido bajo el modelo de la arquitectura blackboard. A pesar de haber sido
desarrollado hace tantos años, sigue siendo uno de los más representativos del área
[BBE+82].
Como se puede ver, hay muchas aplicaciones de este tipo que reflejan el
comportamiento de sistemas inteligentes de tiempo real. Pero, es importante resaltar que
hay unos problemas que se presentan en este tipo de sistemas, provocados por lo siguiente:
• La adquisición del conocimiento del área de aplicación puede ser muy compleja
porque para que el sistema obtenga buenas inferencia, hay que tener completa la
estructura de las reglas del dominio, en una forma que sea aceptable, verificable y
que soporte la suficiente información.
• El cumplimiento de las restricciones temporales y de los planes de ejecución. Esto

porque en un sistema basado en el conocimiento es muy difícil determinar qué es lo
que el sistema hará exactamente, cómo y cuándo.
Para solucionar en parte estos problemas, se han propuesto entornos específicos de

desarrollo de sistemas basados en el conocimiento de tiempo real. Es decir, arquitecturas
que proporcionan las facilidades para que se cumplan con los requerimientos fundamentales
del sistema. En esta investigación, este tema ha sido dejado de lado porque se pretende que
la metodología CommonKADS-RT sea lo más independiente posible de la arquitectura o el
entorno de desarrollo del sistema, aunque en ella se propone e introduce una arquitectura
desarrollada en el mismo grupo de investigación.
La forma como se construye e implanta el sistema es muy importante para solucionar

o mejorar esos problemas, siendo las metodologías un tema muy importante de trabajo para
lograr llevar el SBCTR a un entorno real. A continuación, se presenta la forma de
desarrollo de éstos, es decir, el apartado de las metodologías, núcleo de esta investigación.
2.4.4 Metodologías para desarrollar sistemas basados en el

Como los sistemas de toma de decisiones y los de control proliferan cada vez más, los
resultados el incremento de los riesgos crecen proporcionalmente durante su operación.
Nuevas tecnologías de toma de decisión en la medicina, la manufactura, el control de
procesos industriales y el transporte están cada vez usando más las basadas en
conocimientos.
Pero, en el campo de los SBCTR no se han desarrollado muchas metodologías que

permiten y faciliten la construcción de estos sistemas. Quizá los que han tenido mayor
impacto, han sido RAM y RTCommonKADS, que a continuación se presentan.
2.4.4.1 Metodología RAM
RAM (REAKT Application Methodology). Esta metodología para construir sistemas

basados en el conocimiento de tiempo real es uno de los productos de un proyecto ESPRIT-
II de la Unión Europea. El objetivo principal del proyecto fue desarrollar una serie de
herramientas y una metodología para aplicar los sistemas basados en el conocimiento en
dominios de tiempo real. Se querían crear definiciones, especificaciones y prototipos de
varias técnicas, para ser eventualmente integradas en un juego de herramientas para el
desarrollo, la utilización y el mantenimiento eficiente de módulos basados en el
conocimiento que pudieran ser empotrados en las aplicaciones de tiempo real [Rea90] y
[Rea93].
El proyecto se basó en la proposición de una arquitectura para desarrollar sistemas

basados en el conocimiento de tiempo real, REAKT (Environment and Methodology for
Real-Time Knowledge-Based Systems) y en la construcción de la metodología RAM.
REAKT plantea tener múltiples agentes y como eje central un blackboard temporal.
Se propone tener un sistema operativo de tiempo real, un administrador de datos de
conocimiento y un servidor experto. Permite definir tareas periódicas, esporádicas o
actuadoras (tareas especiales que tienen como función la comunicación con el mundo
externo) [MKC+93], [ViB96].
RAM consiste de unas guías orientadas a la aplicación y de unas herramientas

computerizadas. Toma como fundamento lo planteado en KADS (anterior a
CommonKADS) y en OMT (Object Modeling Technique), adicionándole el soporte de la
reutilización y de las características de tiempo real. El nivel de dominio se refleja a través
de diferentes modelos: un modelo de objetos, uno dinámico, uno funcional y un modelo de
redes causales.
Este proyecto posibilitó la construcción de una serie de algoritmos y de técnicas para

soportar el desarrollo de los SBCTR y tiene una gran importancia desde el punto de vista
conceptual. REAKT ha sido utilizada como modelo en diferentes proyectos, como por
ejemplo en ARTIS [Gar96]. Pero, desgraciadamente la metodología RAM no es muy
conocida, no se encuentra información de ella, no es muy utilizada, es propiedad de algunas
empresas y presenta algunos inconvenientes en relación con lo que se modela y lo que se
construye.
2.4.4.2 Metodología RTCommonKADS
Es una extensión de CommonKADS para sistemas reactivos y EN Tiempo Real

Basados en Conocimiento - STRBC [Pal99]. En ésta se propone la adición de componentes
que permiten modelar algunas de las características de los sistemas de tiempo real:
• Las tareas reactivas que se ejecutan como respuesta a un evento que puede ser el
resultado de alguna modificación del entorno o de alguna condición temporal que se
haya definido con antelación.
• El modelo continuo de operación que posibilita el no tener definida la finalización de

la tarea.
• El foco de atención que se define cuando el sistema puede dirigir su atención según
el evento o la reacción que está atendiendo en un momento dado.
• Tareas concurrentes que pueden ser ejecutadas al mismo tiempo, en forma paralela.
RTCommonKADS plantea cambios en algunos de los modelos de CommonKADS,

como en el modelo de tareas en el que se introduce la entidad Reacción que refleja un
elemento que puede causar la respuesta de una tarea. Obviamente esto implica definir las
relaciones de esta entidad con los demás modelos, como con el modelo de agentes, el
modelo de comunicaciones y el modelo de experiencia que es como se llama al modelo del
conocimiento en esta metodología.
Adicionalmente, en el modelo de comunicaciones se establece la posibilidad de tener

un tipo de comunicación que se produce cuando hay una reacción al dominio que puede ser
generada en un agente diferente del que procesa la tarea disparada, es decir, que hay una
reacción externa.
En esta propuesta se le adicionan algunos conceptos al modelo de experiencia. Entre

estos, uno de los más importantes es reacción que refleja la conceptualización de una
reacción en el sistema de tiempo real. Además, plantea las relaciones que se pueden tener
con dicho concepto y tipos: al dominio o temporal. Todo esto se hizo en el lenguaje CML.
También, en dicho modelo se han introducido nuevas sentencias de control que permiten la
definición de tareas concurrentes y de un modo de operación.
Esta metodología no plantea ningún cambio relacionado con el modelo de la

organización, ya que considera que éste es independiente del sistema solución. Lo cual no
es tan cierto, ya que los problemas en este modelo deben ser analizados precisamente desde
la óptica de los sistemas basados en el conocimiento de tiempo real, pues como lo explican
[SFD99] “Dentro del modelo de la organización se describe la estructura de la organización
junto con una especificación de las funciones que son ejecutadas por cada unidad
organizacional. Además, éste identifica las deficiencias de los procesos de negocios
actuales y que posiblemente pueden ser mejorados a través de la introducción de un SBC”.
Es así como en el modelo de la organización se especifica el dominio del problema, pero
también se incluyen aspectos del dominio de la solución.
En esta metodología no se hace la diferencia entre lo que es una tarea desde el punto
de vista de un proceso de la organización y lo que es una tarea (thread) de tiempo real.
Además, se confunde el concepto de tiempo real y en tiempo real, tal como se ha planteado
en la sección 2.3.1 de sistemas de tiempo real. En ésta no se hace un tratamiento riguroso
del tiempo, clave de los STR, pues no se plantea la inclusión de las características estrictas
del manejo de las tareas de tiempo real, como el deadline, el período o el tiempo de
ejecución en el peor de los casos. Por lo tanto, más bien se entiende como el manejo de la
temporalidad en un sistema basado en el conocimiento.
2.5 Conclusiones del estado del arte

A continuación presentamos las impresiones que hemos obtenido, una vez terminada
la investigación del estado del arte de las áreas tecnológicas involucradas en ella. Éstas las
hemos clasificado de acuerdo con el tema específico de que se trata:
2.5.1 Conclusiones de sistemas basados en el conocimiento

Un proyecto de conocimiento tiene que ser manejado aprendiendo de la experiencia en
una forma de espiral controlada. El desarrollo de simples o muy bien conocidos sistemas de
información usualmente se hace a través de una ruta fija de administración. Esto es
especialmente claro en los llamados modelos de cascada de desarrollo de sistemas, que
consisten en un número de estados predefinido en una secuencia definida: preparar y
planear el proyecto, investigar acerca de los requerimientos del cliente, especificar y
diseñar el programa del sistema, probar y entregarlo, en este orden solamente. El
conocimiento es mucho más rico y más difícil de entender para que encaje en un enfoque
tan rígido. El desarrollo por prototipos ha sido de esta forma muy popular en los sistemas
de conocimiento porque le permiten aprender en el sitio y cambiar el curso cuando sea
necesario, pero su inconveniente es su naturaleza ad hoc, difícil de predecir y manejar.
Tradicionalmente, mucho del esfuerzo que hacían los ingenieros de información y de

conocimientos estaba directamente relacionado con los aspectos técnicos del problema y de
la solución. Ahora que la tecnología del conocimiento ha alcanzado un buen grado de
madurez y de difusión, esto ya no es su objetivo principal. Muchos factores además del
tecnológico, determinan el éxito o el fracaso de un sistema de conocimiento en la
organización, pues éste no sólo tiene que ejecutar muy bien sus tareas de acuerdo con unos
estándares fijados previamente, sino que tiene que ser aceptado por el usuario final y puede
ser incorporado con otros sistemas de información y con la integración de las estructuras,
procesos y sistemas de calidad de la organización como un todo. La experiencia práctica ha
mostrado que a menudo los factores críticos de éxito para los sistemas de conocimiento son
tan bien los puntos relevantes que en la organización han sido tratados. Muchos fallos en la
automatización han resultado, no sólo de problemas con la tecnología sino también por no
tener en cuenta factores sociales y organizacionales. Aún, muchas metodologías de
desarrollo de sistemas se enfocan en los aspectos técnicos y no soportan el análisis de otro
tipo de elementos relacionados con las personas, el entorno, la organización, la cultura y el
poder, los cuales son determinantes para que el sistema tenga éxito o fracase como
solución. La Metodología CommonKADS ofrece las herramientas para manejar todos estos
aspectos.
2.5.2 Conclusiones de sistemas de tiempo real

Los sistemas de tiempo real tienen aplicación en muchas de las áreas del conocimiento
pero debido a la poca formalización que se ha seguido en su desarrollo o a lo complejo de
su presentación, o de los métodos utilizados, su divulgación y extensión no ha sido lo
suficientemente amplia.
Para construir sistemas más complejos, se ha trabajado con los métodos generales de
Ingeniería de Software y algunas personas y empresas han propuesta otras, pero el
problema es que no se han difundido y las grandes industrias que crean este tipo de
sistemas, simplemente siguen su propio método ad hoc.
Los métodos que se han presentando, son sólo una muestra de los muchos que existen
para construir este tipo de sistemas, han sido elegidos por ser típicos, ampliamente
utilizados y reconocidos, lo que garantiza en cierta forma su efectividad. Para más
información ver por ejemplo [Lee92], [Ell94], [ShC94].
Estos métodos están orientados a las fases de diseño o a la de implementación: Los

que resaltan la fase de diseño están más interesados en modelar el sistema usando
conceptos concretos que se relacionan directamente con los componentes que lo integrarán.
Los que enfatizan la fase de implementación se dedican a actividades de identificación del
lenguaje de programación, de la plataforma hardware, de los protocolos de transferencia y
de los de comunicación. Este último es quizá el más usado pues se trata de construir
aplicaciones relativamente simples, sistemas poco complejo en cuanto a la lógica que se
sigue y muy crítico en el cumplimiento del tiempo. Entonces el proceso de construcción es

muy particular: lo primero que se hace es establecer los requerimientos físicos (tiempos,
frecuencias), luego se hace el diseño básico en un lenguaje de programación y
posteriormente se implementa. Una vez se tiene el software, se miden los tiempos de
ejecución en el hardware definitivo y se hace una prueba o la planificación off-line. Si el
resultado no cumple con los tiempos entonces se regresa al diseño para hacer los ajustes
respectivos.
Pero, cuando lo que se quiere es construir una aplicación muy sólida y compleja,
dirigida al sector industrial, estos métodos y metodologías no son apropiados pues es
necesario que además incluyan la fase de análisis para hacer el modelado conceptual, es
decir, un modelado del entorno del mundo real.
Además, algunos se fundamentan en el enfoque tradicional de “cascada”, lo que

dificulta la validación o comprobación de si el diseño es correcto o no, pues sólo se sabe
hasta el final de todo el proceso. Es muy difícil explorar y validar diferentes alternativas de
diseño, por lo que a veces se pueden producir productos que no son óptimos y que, además,
son de baja calidad.
Es importante resaltar que UML es solamente una Notación estándar (lenguaje de

modelado) que no describe el proceso para utilizarla en el desarrollo de un sistema de
software aplicable. Esto es precisamente lo que debe incluir una metodología, la
descripción del proceso o del método con una lista de actividades para hacer, el orden en
que éstas deberían ser hechas, los elementos producidos y entregables, las clases de
herramientas o habilidades requeridas en cada una de las actividades. O sea, que la
metodología formal consiste tanto de las notaciones como de uno o varios métodos. Es así
como se presume que RT-UML puede ser el método a elegir.
2.5.3 Conclusiones de sistemas basados en el conocimiento de

tiempo real
Los sistemas de inteligencia artificial y tiempo real son requeridos para trabajar
continuamente sobre períodos extendidos de tiempo, teniendo comunicación con el entorno
vía sensores y actuadores, tratando con incertidumbre o datos errados, enfocando recursos
en los eventos más críticos, manejando tanto eventos síncronos como asíncronos en una
forma predecible con tiempos de respuesta garantizados. En caso de que se presente una
sobrecarga de recursos, el sistema tiene que alterar sus objetivos o métodos de ejecución.
Hasta el momento la Inteligencia Artificial de Tiempo Real había sido enfocada desde
tres puntos de vista diferentes:
• Adaptar arquitecturas de software a las operaciones de tiempo real
• Modificar los algoritmos tradicionales de IA para mejorar su predecibilidad;
• Modificar las políticas tradicionales de planificación de tiempo real para acomodar el

uso de algoritmos más predecibles.
Las actividades de investigación han estado centradas en el desarrollo de herramientas

para describir y operacionalizar sistemas inteligentes de tiempo real y en la realización de
sistemas con el objetivo de estudiar la viabilidad de los diferentes enfoques. Todo esto ha
permitido que se propongan y desarrollen nuevas arquitecturas que integran o combinan
estos enfoques, logrando tener muy buenos resultados como REAKT, AIS, CIRCA, entre
otros.
Después de esto y siguiendo la evolución lógica de las investigaciones, han estado

surgiendo algunos métodos y metodologías que permiten desarrollar en una forma
estructurada y bien documentada, sistemas de software de este tipo.
Esta situación es similar a los acontecimientos que se presentaron cuando ocurrió la

crisis del software que permitió que surgiera la Ingeniería del Software, y a los que
posibilitaron el nacimiento de la Ingeniería del Conocimiento. Por lo tanto, es posible que
se esté empezando a dar la “Ingeniería del tiempo real inteligente”.
Pero, como se puede observar, no hay muchas metodologías específicamente creadas

para la construcción de SBCTR. Así, la importancia de RAM está dada por el hecho de
tener en cuenta la filosofía de trabajo de los sistemas de tiempo real, pero no es muy
utilizada por los problemas que se plantearon anteriormente y, RT-CommonKADS tiene
una visión diferente de la que se plantea en esta investigación, pues se centra en el nivel de
conocimiento, dejando de lado características asociadas a la implementación del SBCTR.
Adicionalmente, ninguna de estas metodologías propone criterios para determinar cuándo
es apropiado, conveniente y justificable construir un SBCTR como solución a una situación
específica.
Por todo esto, es necesario proponer una metodología que se ajuste más a los sistemas
basados en el conocimiento de tiempo real, retomando algunas de las consideraciones
planteadas en las metodologías existentes.
CommonKADS-RT – Capítulo 3. CommonKADS-RT 91
Capítulo 3.
CommonKADS-RT
3.1 Introducción
La importancia de toda metodología es que posibilita el tener un proceso de
producción de software más estructurado y controlado, facilitando el desarrollo del
proyecto y su gestión, de forma tal que se alcancen tanto los objetivos como los productos
definidos desde el comienzo.
En este capítulo se presenta la metodología CommonKADS-RT para el desarrollo de

un sistema basado en el conocimiento de tiempo real. Inicialmente se explicará la
justificación y el fundamento de la metodología. Luego se introducirá el ciclo de vida para
el desarrollo de un SBCTR. Por último, se describirá cada uno de los modelos que
componen a CommonKADS-RT y los artefactos que se obtienen en su construcción.
3.2 Justificación de CommonKADS-RT

Como ya se dijo en los capítulos anteriores, un Sistema Basado en el Conocimiento de
Tiempo Real – SBCTR - es un sistema que debe razonar basado en una serie de
conocimientos específicos de un dominio y debe manejar bien sea el razonamiento o el
conocimiento con restricciones temporales. Al igual que con cualquier sistema de
información computarizado, se debe seguir un proceso de desarrollo que permita llevar a
cabo su construcción en una forma ordenada y fiable, por lo que se requiere tener unas
guías metodológicas, que incluyan las etapas o fases que identifican lo que tiene que
realizarse para construir el SBCTR y el modelo de ciclo de vida que especifique cuándo
éstas se deben hacer.
Las metodologías existentes para hacer SBCTR, tal como se expresó en la sección
2.4.4, tienen algunas carencias en cuanto a este concepto metodológico y además, no han
tenido en cuenta una serie de concepciones que permiten modelar las características propias
de estos sistemas, a pesar de que el concepto reacción de RT-CommonKADS es muy útil e
importante. Por ello se propone CommonKADS-RT (CommonKADS-Real-Time) para
ayudar al planteamiento y desarrollo de proyectos de conocimiento bajo restricciones

temporales.
Todo esto hace que se piense en tener herramientas que permitan hacer un buen
modelado del sistema, integrando por ejemplo escenarios estímulo / respuesta y diagramas
de flujo de datos y de control para exhibir las entradas y las salidas del sistema. También se
podrían utilizar las máquinas de estados y los flujos y transformaciones de eventos y
estados para que reflejen los estados en los que puede estar el sistema en un momento
específico. Si se requiere involucrar el procesamiento concurrente entonces es importante
hacer el modelado del diseño físico del sistema, la interconexión de sus componentes y la
ubicación de los datos. Por último, como estos sistemas generalmente deben responder en
forma predecible y rápida, entonces sería importante contar con un medio para establecer su
rendimiento.
3.3 Fundamentos de CommonKADS-RT

CommonKADS-RT está basada en las metodologías CommonKADS y RT-UML,
presentados en el capítulo anterior. Esta elección está soportada por las siguientes ideas:
3.3.1 Fortalezas y debilidades de CommonKADS para sistemas

basados en el conocimiento de tiempo real
Como ya se ha mencionado en diversas secciones, especialmente en la 2.2.7 Ventajas
y desventajas de CommonKADS - página 49, CommonKADS es una buena metodología
para modelar sistemas inteligentes basados en el conocimiento. Integra algunos de los
modelos de UML para complementar el modelado del SBC, pero carece de otros que
permite modelar las restricciones temporales.
Su propósito básico no es el de modelar sistemas de tiempo real. Aunque en algunas

partes se habla del tiempo como una variable importante de considerar, no se amplía mucho
este concepto y, por tanto, no se proponen ni métodos ni se ofrecen alternativas para
establecer el análisis temporal o para definir las restricciones temporales. Por esto hay
varios cambios que son necesarios hacer. Entre ellos está la modificación del lenguaje
CML2 utilizado para definir el modelo de conocimientos, pues debe incluir las
instrucciones necesarias que permitan definir el deadline de una tarea, determinar si ésta es
crítica o si es periódica. Es decir, que ofrezca la posibilidad de incluir todas las condiciones
de una tarea de tiempo real.
Adicionalmente, y tal como se ha manifestado, la metodología CommonKADS gira

alrededor del modelo de conocimiento y está pensada para desarrollar SBC que interactúan
con un usuario humano, pero dado que un SBCTR está en comunicación permanente con su
entorno, a través de periféricos o dispositivos especiales, y que por lo general estos sistemas
son reactivos, entonces es necesario volver a definir algunos de los modelos existentes en la
metodología y plantear incluso uno nuevo, denominado el modelo de tareas de tiempo real.
En este contexto, es importante determinar qué se entiende por tarea, dado que se trata
de una noción relevante que tiene diferentes connotaciones:
• Como un concepto de sentido común, una tarea es una actividad humana para
alcanzar algún propósito.
• Para CommonKADS una tarea es una parte de un proceso de negocios que

representa una actividad orientada a un objetivo, llevada a cabo por unos agentes que
siguen unos criterios de calidad y desempeño. La tarea maneja entradas y entrega
salidas deseables en una forma estructurada y controlada, consume recursos y
requiere (y provee) conocimiento y otras habilidades.
• Desde el punto de vista de los STR, una tarea se refiere a una especificación de bajo
nivel de cada uno de los hilos de ejecución de un proceso.
Por tanto, en CommonKADS se trabaja en estadios más abstractos y no se plantea el

llegar a ese nivel de detalle que se requiere en un SBCTR.
No obstante, CommonKADS sigue siendo la mejor alternativa para usarse como base
en el desarrollo del SBCTR por las siguientes razones:
• Es una metodología consistente y robusta que integra los conceptos más importantes
de la Ingeniería del Software y en especial de la Ingeniería del Conocimiento,
siguiendo con el paradigma de objetos.
• Incluye aspectos relacionados con la gestión del proyecto, permitiendo hacer un

análisis muy completo de la organización, de sus problemas y de las diversas
soluciones.
• El considerar el análisis de riesgos, da la posibilidad de que se ejerza un control más

oportuno y apropiado sobre las actividades de desarrollo.
• Dado que esta metodología es un estándar para el desarrollo de SBC, que ha sido
ampliamente utilizada y validada, da ciertas garantías para su utilización.
• Es posible adecuarla para el desarrollo de otro tipo de sistemas informáticos, en

especial de los SBCTR.
3.3.2 Fortalezas y debilidades de RT-UML para sistemas basados

en el conocimiento de tiempo real
Haciendo un análisis similar al anterior y reforzando los conceptos presentados en la
sección 2.3.5 Ventajas y desventajas de RT-UML - página 77, lo primero que hay que decir
es que el objetivo de RT-UML no es el desarrollo de SBC, sino de STR. Por lo tanto, los
elementos que proporciona no fueron diseñados para modelar el conocimiento y no se
define en forma expresa las técnicas de adquisición, representación y manipulación del

conocimiento.
Adicionalmente, se puede decir que esta metodología es más de diseño que de análisis,
aunque ese no es su propósito, pues pone mucho énfasis en las actividades, modelos y
diagramas que se pueden utilizar para el diseño del STR, dejando de lado el análisis del
problema.
Se escogió UML para modelar las características de tiempo real, porque tiene una serie
de modelos que se pueden aplicar para realizar el análisis de un sistema de tiempo real e
incluso de un sistema basado en el conocimiento de tiempo real. La metodología que
soporta más ampliamente UML es RT-UML para la parte de tiempo real, pero es necesario
adicionarle otras herramientas que permitan modelar el conocimiento temporal.
Así, CommonKADS-RT se basa en estas dos metodologías. CommonKADS para los

componentes basados en el conocimiento y la gestión del proyecto, con algunas
variaciones; en RT-UML para el modelado del tiempo y el tratamiento de los problemas de
tiempo real, también con unos cambios. Adicionalmente, se han tenido en cuenta algunas
técnicas de planificación estratégica y evaluación de proyectos, y las consideraciones
propias fijadas por los sistemas basados en el conocimiento de tiempo real.
3.3.3 Descripción general de CommonKADS-RT

Tal como se dijo en el capítulo 1 de la introducción, en esta investigación se considera
que una metodología de software debe indicar lo siguiente:
• Criterios para identificar si la mejor solución o al menos la más apropiada es un

SBCTR. Ver anexo 1. Esto es un punto muy importante de la metodología
CommonKADS-RT porque sirve de guía o de instructivo para la implementación de
un SBCTR y hace parte de lo que es la viabilidad técnica del sistema.
• Cuáles son las características más importante que debe tener el dominio para que sea
apropiado utilizar esta metodología. Se plantearán en la siguiente sección – 3.4.
• Cuáles son las actividades específicas que se deben realizar (etapas o fases). En el
caso de CommonKADS-RT es la especificación de los diferentes modelos que se
deben elaborar para integrar el SBCTR. Esto es lo que se amplía en la sección 3.6
Modelos que integran a CommonKADS-RT.
• Cuál es el orden de realización de dichas actividades. Es decir, el ciclo de vida que

sigue el SBCTR. Esto es lo que se trata en la sección 3.5 Ciclo de vida de
CommonKADS-RT.
• Cuáles son las herramientas, conocimientos y utilidades para realizar las actividades.
Es decir, cómo se deben preparar los modelos de CommonKADS-RT. También se
plantea en la sección 3.6.
• Los roles y responsabilidades que se tienen tanto en el desarrollo de los modelos,

como en el seguimiento o gestión del proyecto. Esto se especifica en los modelos
que integran la metodología.
• Los resultados, productos o artefactos que se obtienen en cada una de las etapas y
modelos, se incluyen en la sección final de cada modelo de la metodología.
• Los mecanismos que sirven de guía de decisión en cada una de las tareas. Es decir, la
gestión del proyecto. Este tema se trata parcialmente en los modelos y el ciclo de
vida, pero no se profundiza mucho.
A continuación se presenta el esbozo general de la propuesta y luego se detalla cada

uno de los modelos que la componen. Ver Figura 3-1.
Modelo de la
Organización
Qué
Quiénes
Modelo de Modelo de
Tareas de Agentes
Alto Nivel
Qué saben
Con qué Cómo se relacionan
Modelo de Modelo de
Conocimientos Comunicaciones
Base de conocimientos,
restricciones temporales,
Razonamiento
interfaz
Modelo del
Diseño
Características de Hardware
y Software
Modelo de
Tareas de
Tiempo Real
Figura 3-1 Modelos de CommonKADS-RT
• La idea básica es que el desarrollo de un Sistema Basado en el Conocimiento de

Tiempo Real se ve como la construcción de un número de modelos que juntos
constituyen parte del producto que se debe entregar en el proyecto y en donde el
nivel de elaboración de los modelos depende de cada proyecto. Así mismo, en
CommonKADS-RT se proponen una serie de formularios asociados a cada uno de
los modelos que deben ser configurados, refinados y rellenados durante el desarrollo
del proyecto.
• Un proyecto que incluye el construir un SBCTR debe entregar como productos lo

siguiente:
− Los formularios diligenciados,
− La documentación relacionada con el SBCTR. Ésta complementa lo definido en

los formularios, y
− El software, o sea, el SBCTR.
• Lo primero que se debe hacer es empezar con el modelo de la organización para

identificar el problema y las soluciones alternativas. Para ello se toman como base
los formularios de CommonKADS y se les hacen unos cambios relacionados
específicamente con la introducción de herramientas de planificación estratégica y de
los aspectos de los sistemas basados en el conocimiento de tiempo real. Se propone
un nuevo formulario que permite separar el problema de la solución, se utiliza el
diagrama de casos de uso para identificar claramente los agentes y actores
involucrados en el problema seleccionado, se hace el diagrama de actividades para
presentar los procesos y el flujo de control entre ellos. Una vez identificados los
actores, se pueden detallar cada uno de los casos de uso para representar las
funciones del sistema desde el punto de vista del usuario y los escenarios que son
instancias de dichos casos de uso. También se pueden registran los eventos externos
más relevantes para el sistema, tanto los que le entran por medio de un actor como
los que éste produce y entrega. Se analiza el conocimiento que se maneja en el
proceso de acuerdo con la clasificación de dato, información, habilidad o capacidad,
o conocimiento propio del proceso mismo. Por último, se plantean las diferentes
alternativas de solución con su justificación asociada.
• Luego se comienza con el desarrollo del modelo de tareas de alto nivel, variación del
modelo de tareas. Para esto además de utilizar los nuevos formularios, se debe
construir un diagrama de flujo de la TAN seleccionada, un diagrama de conceptos
(entidades o clases), la profundización del diagrama de actividades del modelo de la
organización y los diagramas de estado de aquellos conceptos que lo requieran.
• El modelo de agentes, básicamente es el mismo que el de CommonKADS, sólo que

se introduce una clasificación de los agentes para facilitar su identificación en el
proyecto y modelado: un actor que es una persona que interactúa directamente con el
sistema; un emisor es un diapositivo que da entrada al SBCTR a través de señales
(por ejemplo un sensor); un actuador que es aquel que recibe o opera sobre el
entorno como salida del SBCTR. Estos últimos se conocen como agentes software
que pueden percibir, realizar actividades de cognición o actuar sobre el entorno.
• Después se plantea el modelo de conocimientos con la ayuda también de los

formularios y de los diagramas de secuencia de conceptos, de colaboración y de
actividades. En este modelo se definen las tareas de alto nivel de tiempo real que han
sido identificadas a través del Lenguaje de Modelado de Conocimiento de
CommonKADS - CML con las adiciones de las características temporales. Es bueno

utilizar los diagramas de transición de estados para analizar algunos de los
conceptos que resulten de este punto. Se especifica el modelo de comunicaciones,
utilizando de nuevo los formularios, los diagramas de secuencia y de colaboración.
• Luego se pasa el modelo de diseño, tal como se tiene en CommonKADS,

adicionando el modelado de la arquitectura del SBCTR por medio de diagramas de
componentes y determinando el diseño detallado de la estructura de la tarea de
tiempo real, según dicha arquitectura. Para esto se utiliza RT-UML, ARTIS y otros
métodos apropiados.
• Por último, se definen las características de las tareas de tiempo real en el modelo de
TTR para poder hacer el test off line de planificabilidad y comprobar si el sistema si
lo cumple o no, para poderlo implantar.
Es importante aclarar que el hecho que se hayan definido estos puntos específicos, no
quiere decir que se tengan que dar en ese orden, ya que algunos de los procesos de análisis
se pueden hacer en forma paralela.
3.3.4 ¿Por qué un modelo para las tareas de tiempo real?

Para todo SBCTR la información relacionada con las tareas de tiempo real, es tan
relevante que merece la pena que sea tratada en forma detallada y que se tenga un modelo
específico cuyo propósito final será el de modelar las tareas de tiempo real.
Además, la información que se va a modelar será importante para las decisiones que se
tengan que tomar en cuanto a aspectos de planificabilidad y predecibilidad del sistema.
El modelo de TTR describe las tareas de tiempo real que serán ejecutadas en el
SBCTR. Su alcance está dado por lo siguiente:
• Este modelo sólo contiene aquellas tareas que tienen restricciones temporales
asociadas y que en conjunto deben ser analizadas para determinar la planificabilidad
y predecibilidad del sistema.
• Las tareas de tiempo real son descritas independiente del sistema operativo y de la
plataforma hardware del mismo.
La función de este modelo en CommonKADS-RT es describir los hilos de ejecución

que se necesitan en el sistema basado en el conocimiento de tiempo real, pero a un alto
nivel de abstracción.
3.4 Características del dominio que es apropiado

para la aplicación de CommonKADS-RT
Es importante plantear las particularidades que debe tener el campo en el cual se va a
construir la aplicación de un SBCTR de acuerdo con CommonKADS-RT:
• Los sistemas basados en el conocimiento de tiempo real deben ser sistemas que se
fundamenten y manejen el conocimiento pertinente para solucionar un problema
específico.
• Parten del conocimiento, en donde algún(os) hecho(s), heurística(s) o relación(es)

tienen asociadas características temporales que le dan el calificativo de ser de tiempo
real.
• El problema y su solución estarán descritos por las tareas que lo conforman.
• Las soluciones serán estáticas, es decir, que no cambiarán en el momento de

ejecución.
• La implementación del SBCTR se puede hacer en cualquier lenguaje de

programación, siendo unos más apropiados que otros debido a las características
propias del sistema.
• Dentro de la metodología no se considera la definición de la estrategia de

planificación, ni la forma como se debe realizar el test de planificabilidad y
actividades específicas de la planificación fuera de (off-line) las tareas de tiempo
real. Esto forma parte de la validación temporal del sistema y no está dentro del
alcance de esta investigación.
• CommonKADS-RT incluye aspectos tanto en el ámbito general (de la organización

– macro) como en el ámbito detallado (de las tareas de tiempo real – micro).
3.5 Ciclo de vida de CommonKADS-RT

Al igual que en CommonKADS, en esta propuesta se sigue con el modelo en espiral
orientado por los riesgos. Las etapas que la conforman son las siguientes:
• Viabilidad: En esta etapa lo que se pretende es conocer el problema que se va a

corregir para dar una buena recomendación acerca de su solución. Las actividades
que se realizan son: la definición y ubicación del problema, la determinación del
alcance y los objetivos de la solución, la identificación y el coste de los recursos
(hardware, software y humano) necesarios para emprender el proyecto, el estudio de
viabilidad, la identificación del tipo de SBCTR que se quiere desarrollar (si es que es
el caso), las restricciones, los beneficios y una planeación de la siguiente etapa.
(Modelo de la organización).
• Análisis del Problema: En esta etapa se pretende modelar la solución del problema,
definiendo los procesos que van a quedar reflejados en el sistema, planteando
esquemas para la implantación de los componentes del sistema y determinando
cuáles son las herramientas necesarias para llevar a cabo dicha construcción. Las
actividades son: conceptualización, planteamiento del nuevo sistema, modelado y
planeación de la siguiente etapa. (modelo de la organización, modelo de TAN,
modelo de agentes, modelo de conocimiento, modelo de comunicaciones)
• Formalización: Esta etapa implica la completación y traducción de cada uno de los

modelos de CommonKADS-RT, con el objetivo de determinar las características
generales de lo que será el sistema software. Se definen los componentes de la
arquitectura y se construye un prototipo del SBCTR para demostrar el
funcionamiento del sistema, implicando el desarrollo a pequeña escala de cada uno
de los componentes del sistema. El desarrollo debe ser incremental, incluyendo la
realización de pruebas permanentes. Es importante aclarar, que esto no tiene nada
que ver con el análisis de planificabilidad que debe hacerse una vez el sistema esté
completo. (modelo de conocimientos, modelos de comunicaciones, modelo del
diseño).
• Diseño Detallado: Determinación de la arquitectura del SBCTR, del software

apropiado para la construcción del sistema, tal como el lenguaje de programación y
el sistema operativo, la estructura de las tareas de tiempo real, los componentes
internos del sistema y las estructuras de datos. (modelo del diseño, modelo de tareas
de tiempo real).
• Crecimiento del sistema: Lo que se pretende es construir completamente el sistema

hasta que se logre cumplir con los requerimientos planteados al principio del
proyecto.
• Evaluación: Incluye la realización de las pruebas finales por parte del experto y de
los usuarios, y la realización del test de planificabilidad.
• Integración del Sistema: Introducción y adaptación del sistema con el resto de la

organización, incluyendo actividades de capacitación.
• Evolución a Largo Plazo: Se consideran varios tipos de evolución, un incremento de

la funcionalidad general del sistema, correcciones o adiciones a la base de
conocimientos y una expansión del dominio.
También es importante destacar que, en esta metodología, los procesos de adquisición

y de representación del conocimiento no se consideran etapas o fases ya que deben ser
actividades que tienen que ser realizadas en diferentes momentos del desarrollo del sistema.
Por lo tanto, se consideran como procesos que deben ser paralelos a la metodología. La
documentación y las pruebas tampoco se asocian a un único momento, por lo que deben ser
realizadas como actividades específicas de cada etapa, de cada proceso y de cada modelo.
Adicionalmente, se ha propuesto un Ciclo de Desarrollo (Figura 3-2) que refleja la

relación entre el modelo de espiral y las etapas de este ciclo de vida y un Ciclo de
Implantación (Figura 3-3) que se sigue una vez el sistema ha sido construido.
Viabilidad
Construcción
Diseño Análisis
Detallado
Formalización
Figura 3-2 Ciclo de Desarrollo en CommonKADS-RT
Test de
Planificabilidad
No
cumplir Ciclo de
Desarrollo
Si
Integración del
Sistema
Evolución a largo
plazo
Figura 3-3 Ciclo de Implantación del SBCTR
Los modelos y las técnicas que se proponen en CommonKADS-RT son específicas

para establecer el análisis y el diseño del SBCTR. Las otras etapas del ciclo de vida no se
han considerado en esta investigación. A continuación se presentan los modelos propuestos:
3.6 Modelos que integran a CommonKADS-RT

Como ya se dijo, CommonKADS-RT toma como base los modelos de
CommonKADS, incluyendo las características de los sistemas de tiempo real, agregándole
los métodos que permiten especificar estos comportamientos temporales. En la Figura 3-1
se mostraron cada uno de ellos y su relación. En términos de UML, el conjunto de modelos

de CommonKADS-RT se puede expresar a través de notación de la Figura 3-4.
<<systemModel>>
Tareas de Alto
Organización Nivel
Conocimiento Comunicaciones
Agentes Diseño
Tareas de
Tiempo Real
Figura 3-4 Modelos de CommonKADS-RT en UML
La relación entre los modelos y el ciclo de vida se puede apreciar en la Tabla 3-1
siguiente:
Tabla 3-1 Relación entre las etapas del ciclo de vida y los modelos de CommonKADS-
RT
Modelo Modelo Modelo Modelo de Modelo de Modelo Modelo
de la de TAN de Conoci- Comunicacio- de de TTR
Organiza- Agentes mientos nes Diseño
ción
Viabilidad X
Análisis X X X X X
Fornalización X X X
Diseño X X
Detallado
A continuación se detalla cada uno de estos modelos. Es importante aclarar que los
cambios que se le han hecho a los formularios están resaltados en negrilla.
3.6.1 Modelo de la organización

Este modelo se construye con el fin de estudiar el ambiente de la organización para
determinar lo que está sucediendo en ella y así poder definir cuándo y en dónde se puede
construir un sistema basado en el conocimiento de tiempo real (SBCTR) para solucionar un
problema específico o mejorar un proceso real. Por tanto, a través de él se hace el análisis
de la organización en diversos aspectos: su estructura, sus procesos, el factor humano que
participa en los procesos, los recursos que se generan y consumen, las relaciones entre los
procesos y su gente, entre otras.
Las actividades centrales que se realizan en este modelo tienen que ver con la
identificación y descripción de los patrones de manejo, comunicación y producción que se
poseen, tanto en el momento presente en la organización – situación actual - como en el
futuro - la situación a la que se quiere ir, es decir, la situación deseada una vez el SBCTR
esté inmerso en ella.
El proceso que se sigue para construir completamente este modelo es el siguiente:
Se hace un estudio del alcance y de la viabilidad del sistema por medio de la

identificación de las áreas problema o de las oportunidades y soluciones potenciales para
ponerlas en una amplia perspectiva organizacional. Es decir, que se encuentran áreas
prometedoras en donde los sistemas de conocimiento de tiempo real puedan proporcionar
un valor agregado importante para la organización. Luego, se decide acerca de las
soluciones y sus posibilidades para determinar si el proyecto es importante en cuanto a los
costos y beneficios esperados, viabilidad tecnológica, recursos necesarios y compromisos
dentro de la organización. Después, se hace el análisis de la naturaleza de las tareas
involucradas en el proceso del negocio seleccionado para identificar cuál es el
conocimiento usado por los agentes responsables con el fin de utilizarlo exitosamente y
cuáles mejoras se pueden hacer en este aspecto. En este caso se establece una estrecha
relación entre la tarea, los agentes y el conocimiento. Posteriormente, se determina el
impacto que el SBCTR propuesto tiene en la organización, se prepara un plan de acción y
se presentan los resultados o productos de este estudio.
Al igual que en CommonKADS, esta metodología también incluye una serie de

formularios que sirven como guía en la elaboración de este modelo. A continuación, se
explica cada uno de éstos con los cambios que se necesitan realizar para poder hablar de un
SBCTR.
3.6.1.1 Formularios del modelo de la organización
• OM-1: Identificación en la organización de los problemas y oportunidades

orientados al conocimiento, con el tiempo como factor importante
El propósito de esta fase del modelado es el de adquirir un conocimiento general

de la organización, sus componentes y características para comprender las estructuras y
procesos de la misma que servirán como elementos constituyentes del análisis de
viabilidad. Este formulario tiene mucha utilidad cuando se quieren conocer los procesos
de la organización, sus problemas, las personas o entidades que se ven involucradas en
ellos, entre otras. En general, el resultado de aplicar OM-1 será el de obtener una visión
global del estado actual de la organización. Pero, en caso que esto no sea necesario, se
puede omitir o reducir su alcance, como por ejemplo en la situación en que un proceso
esté identificado como problemático o como susceptible de mejoría.
Como se menciona en [Igl98] hay tres enfoques que se pueden aplicar para
identificar los problemas y oportunidades de una organización:
− A través de un análisis de los procesos de trabajo con el objetivo de determinar el

rendimiento en la organización.
− A través de una análisis de la ubicación, utilidad y disgregación del conocimiento

que se requiere para trabajar en tareas susceptibles de realizar en forma
automática.
− Por medio de un análisis del ambiente cultural, social y del entorno de la

organización.
Para lograr estos propósitos, en CommonKADS se propone diligenciar un

formulario que se llama Identificación de los problemas orientados al conocimiento y
oportunidades en la organización y que como su nombre lo indica, permite hacer un
análisis de las situaciones que en un momento dado se están presentando en la
organización y se orienta hacia aquellas que son intensivas en conocimiento y que
forman el conjunto posible o factible de problemas que pueden ser solucionados por
medio de un SBC.
Adicionalmente, en CommonKADS-RT se propone que se lleve a cabo este

análisis de forma tal que no sólo permita determinar cuáles son los problemas que
actualmente se revelan en la empresa y cuáles serían sus posibles soluciones, sino
también determinar si tienen restricciones temporales importantes que cumplir y el
impacto que pueden producir al interior o al exterior de la organización, con el fin de
definir un plan de acción acorde con las directrices generales de la empresa. Para esto,
se construye una matriz DAFO (Debilidades, Amenazas, Fortalezas, Oportunidades)
con la cual además de ver en dónde hay oportunidad de hacer un SBCTR también se
obtiene la información necesaria para saber qué es lo más importante, necesario o
urgente de solucionar en la empresa. Así, se puede establecer una forma de asignación
de prioridades a los problemas y sus soluciones, de acuerdo con ciertos criterios
definidos por la misma organización.
Para las situaciones intensivas en conocimiento y con el recurso tiempo como

factor determinante, se puede hacer la estimación del tiempo en que el proceso se
realiza en la actualidad y el tiempo en que se tendría que hacer con la solución de
SBCTR. Esto último podría llegar a ser un factor competitivo para la organización, pero
teniendo en cuenta que es un estimativo, ya que el tiempo exacto sólo se sabrá en el
momento en que se tenga una versión operativa del sistema. Es decir, cuando se tenga
el software del modelo del diseño.
A continuación se presenta el nuevo formulario que permite registrar lo

anteriormente mencionado:
Modelo de la Organización Problemas y Oportunidades

Hoja de Trabajo OM-1
Contexto de la organización En este punto, se debe indicar en una forma concisa, las características
claves del ambiente de la organización, entre las cuales están: La misión,
la visión, los objetivos de la organización y los Factores externos con

los que la organización tiene que tratar (los más importantes, por
ejemplo los factores de competencia planteados por Michael Porter
[Por97]).
Matriz DAFO Hacer el análisis de la situación de la organización, utilizando la
planificación estratégica como un elemento importante para la
determinación de las actividades de cambios o mejoras que
realmente se deben realizar en la empresa. Con esta lista, se debe
escoger si es más importante trabajar con los procesos que permiten
tener un impacto al interior de la organización (debilidades y
fortalezas) o hacia el exterior de la misma (oportunidades y
amenazas)
Problemas intensivos en el De la lista anterior, elegir realmente los que son intensivos en
conocimiento con el factor conocimientos y con tiempos asociados a la toma de decisiones, para
tiempo como determinante en clasificarlos de acuerdo con unas prioridades establecidas en la
la realización del proceso organización. Esto obviamente debe estar acorde con la misión, la
visión, los objetivos y las estrategias que la empresa ha definido para
un período. Aplicar los criterios de filtrado. Anexo 1.
Es importante aclarar, que en caso de no poderse hacer esta

actividad en el momento del análisis, se podrá postergar para más
adelante cuando se conozca mejor la situación.
Lista de problemas con su Priorizar o valorar cada uno de los problemas identificados como
prioridad asociada basados en el conocimiento y con la variable tiempo como factor
importante. Según algún criterio definido, como por ejemplo una
prioridad basada en la importancia o relevancia de su solución.
Formulario 3-1 OM-1: Identificación en la organización de los problemas y
oportunidades orientados al conocimiento, con el tiempo como factor importante.
Como se puede observar, lo que se pretende con este formulario es registrar el

ambiente organizacional y los problemas intensivos en conocimiento y de tiempo real.
Por ello, es importante ampliar lo relacionado con la determinación de este tipo de
problema.
Un problema es intensivo en conocimientos cuando algunos de los procesos que

se tienen que realizar para llegar a su solución o a cambiar su condición, están basados
no solamente en los hechos (datos) o en las reglas conocidas de un dominio (relaciones)
sino también en la experiencia de la(s) persona(s) que participan en él o en la misma
cultura de la organización que sabe como solucionarlo.
Por otra parte, una solución debe ser por medio de un sistema de tiempo real
cuando en los procesos del problema hay tareas que requiere que se realicen en unos
períodos definidos o en un tiempo máximo específico.
Así, cuando un problema en su estudio preliminar cumple con esas condiciones,

entonces se presupone que una buena alternativa de solución es a través de un SBCTR.
Para tener más certeza, se analizan los criterios de filtrado, con el objetivo de
determinar si es apropiado o no hacer un SBCTR en una situación específica. Ver anexo
1.
Con los resultados de OM-1 se debe escoger el problema que cumpla con las
condiciones mencionadas anteriormente y que tiene mayor prioridad, necesidad o
urgencia de solucionar. De esta forma, se continúa entonces con el análisis de

requerimientos y con la determinación de los otros modelos de la metodología.
• OM-2: Descripción de los aspectos de la organización que tienen impacto o están

afectados por el problema escogido
Con el fin de profundizar en el estudio del problema elegido, entonces se plantea

lo siguiente:
Modelo de la Aspectos Variantes

Organización Hoja de Trabajo OM-2
Estructura (*) Diagrama de la estructura considerada (parte de la) organización en función de sus
departamentos, grupos, unidades, secciones.
Proceso (*) Es importante hacer un Diagrama de Contexto que permita tener una vista general
del proceso que se está analizando y luego, hacer un Diagrama de Actividades de
UML que permita ver el flujo de control y de información del proceso. Cada una de
las actividades debe ser una Tareas de Alto Nivel (TAN) que se detalla en OM-3.
Personas Cuáles miembros de la organización están involucrados como actores o personas
interesadas, incluyendo tomadores de decisiones, proveedores, usuarios o beneficiarios
(“clientes”) del conocimiento. Estas personas no necesitan ser “personas reales” sino que
pueden ser roles funcionales jugados por personas en la organización. También, es
importante establecer las relaciones que se pueden tener con persona u
organizaciones externas a la empresa, pero que son importantes para el proceso
estudiado, tales como proveedores o clientes. Para este análisis es importante
incluir gráficos que permitan visualizar fácilmente las relaciones entre los
diferentes entes, siguiendo las directrices de los Casos de Uso de UML. Por ejemplo,
ver Figura 3-5.
Recursos Descripción de los recursos que son utilizados en el proceso del negocio. Estos pueden
ser de diferentes tipos, tales como:
1. Sistemas de información y otros recursos computacionales.
2. Equipos y materiales. Entre ellos se debe especificar detalladamente la parte de
sensores y actuadores.
3. Habilidades y aptitudes sociales, interpersonales y otras (no del conocimiento).
4. Tecnología, patentes, derechos.
Conocimiento El conocimiento representa un recurso especial explotado en un proceso del negocio. Por
su importancia clave en el presente contexto, éste se trata aparte. La descripción de este
componente en el modelo de la organización se hace separadamente, en la hoja de
trabajo OM-4 en la valoración del conocimiento
Prioridad Tomada de OM-1 y que indica qué tan significativo es el problema. Si no se ha
asociada definido previamente, entonces hacerlo en este momento.
Restricciones Identificar algunos conceptos temporales que pueden involucrarse en el problema
Temporales 1. si el proceso es periódico o no,
2. si hay un tiempo máximo para realizar el proceso,
3. el tiempo promedio que se tarda el proceso, desde el inicio hasta el final,
4. si hay comunicación con otros procesos o no, entonces especificar los tiempos
y condiciones de esa comunicación. Esto se amplía en OM-5.
Cultura y Poder Las “reglas de juego no escritas”, que incluyen los estilos de trabajo y de comunicación
(“la forma como se hacen las cosas”) y las relaciones y redes informales.
Impacto Hacer la descripción de los efectos que produce la situación actual en la
organización. Para esto se tiene que identificar exactamente a qué otros procesos,
áreas o personas afecta la situación. Esto es importante porque se debe tener en
cuenta cuando se plantee la solución para determinar cuáles serán los riesgos de
ésta y cómo manejarlos.
(*) permite ver en forma más abstracta en dónde está ubicado el problema en la organización.
Formulario 3-2 OM-2: Descripción de los aspectos de la organización que tienen

impacto en o están afectados por el problema elegido en OM-1
es_proveedor_de
MARÍTIMA ARMADOR
VALENCIANA
Figura 3-5 Relación entre la empresa Marítima Valenciana y el Armador
Dada la importancia de la información recopilada en este formulario y de su

relación con la solución, éste debe ser diligenciado siempre, porque es a través de él que
se va a conocer el proceso a estudiar.
Para describir las tareas de alto nivel que conforman el proceso, se utiliza el
diagrama de actividades. Dichas tareas son las que se deben analizar para ver cuáles
requieren del cumplimiento de unas restricciones temporales y son intensivas en
conocimiento. Para ello también se tienen los dos formularios que a continuación se
presentan:
• OM-3: Descripción del proceso en función de las Tareas de Alto Nivel (TAN) en
que está compuesto
Este formulario permite especificar mucho más el proceso que se ha elegido, por
medio de su descomposición en tareas. En CommonKADS se denomina Descripción
del proceso en función de las tareas que lo componen y sus principales características.
Para no confundir este concepto de tarea con el que se maneja en el ámbito de

tiempo real, a partir de ahora se llamará Tarea de Alto Nivel - TAN al componente de un
proceso y Tarea de Tiempo Real - TTR a la de más bajo nivel. Por lo tanto OM-3 hará
una descripción de las TAN en que está compuesto el proceso y las características que
tiene. Ver Formulario 3-3.
Para aquellas TAN que se clasifiquen como no automáticas, se debe justificar las
restricciones tecnológicas o de impacto que hacen que se comporte de esta forma. Es
muy importante tener en cuenta lo que aquí se especifique pues esto deberá verse
reflejado en las soluciones que se planteen como posibles restricciones o limitaciones
del sistema computarizado. En caso de tener que hacer un análisis más detallado de las
TAN, bien sea porque son muy complejas e involucran diversas tipos de problemas
(ejemplo, de análisis o de síntesis), entonces se puede desarrollar otro formulario OM-3
que refleje más detalladamente las características de ellas.
Modelo de la Proceso de Descomposición

Identifica. Nombre Objetivo Tipo de ¿Ejecutada por y en Importancia ¿Intensiva en Conocimiento ¿Tiene ¿Es posible introducir
de la TAN de la de la TAN TAN dónde? de la TAN conocimiento? involucrado restric- un sistema
TAN para el ciones informático en la
proceso temporales? TAN?
Identifica- Nombre Describir En CommonKADS Agente: El agente puede Indica qué tan ¿La TAN es Lista de los ¿Cuáles son Definir si es posible
dor. de alguna la meta o el se han planteado una ser de diferentes tipos: importante es intensiva en recursos de las medidas implantar un sistema
Se de las objetivo serie de tareas que - un actor que es una la TAN para conocimientos? conocimiento de tiempo o informático para que
recomien- parte del que se pueden servir para persona que interactúa el proceso. (Alto, Medio, usados en la especificacio realice algunas o todas
da que sea proceso pretende determinar si lo que directamente con la Siempre debe TAN nes las actividades de la
un nombre en OM-2 alcanzar al se está estudiando situación. ser una Bajo) * temporales TAN. Además,
Nemotéc- realizar la corresponde a alguna - un software que respuesta asociadas a especificar qué tipo de
nico TAN de ellas para hacer proporciona datos al justificada la ejecución sistema informático
una reutilización de proceso a través de señales de la TAN? (por ejemplo, un
lo allí planteado y (por ejemplo un sensor). sistema tradicional de
optimizar el tiempo Este puede ser un emisor o base de datos o un
del análisis. un actuador que recibe o SBC o un SBCTR,
opera sobre el entorno con entre otros)
Ver anexo 1. los productos del proceso.
Formulario 3-3 OM-3: Descripción del proceso en función de las tareas de alto nivel en que está compuesto
* La escala que se ha definido para medir qué tan intensiva es la TAN en conocimientos, está dada por:
• ALTO: Cuando es una tarea que refleja un proceso de análisis o síntesis, relacionando datos e información a través de heurísticas. Por ejemplo la TAN para hacer la planificación de la
carga y la descarga de contenedores de un barco.
•
• MEDIO: Cuando con los datos se toma alguna decisión básica. Es decir, una decisión que puede ser aprendida por cualquiera que no tenga los conocimientos mínimos sobre el dominio en
cuestión. Por ejemplo cuando un barco atraca por primera vez en el puerto y hay que hacerle el registro de información y guardarlo en una carpeta apropiada.
• BAJO / NADA: Cuando sólo es un manejo puro de datos que no requiere tener conocimientos para ello. Por ejemplo, verificar si el barco ha atracado alguna vez en el puerto, lo que es una
simple comparación de datos.
Además, es posible construir un diagrama llamado de Cooperación de TAN,

extensión del diagrama de colaboración de UML, para relacionar todas las TAN ya
detalladas y así tener una vista gráfica de los componentes del problema. Cada TAN es
representada por un rectángulo con su nombre asociado, las relaciones entre ellas se
representan como líneas continuas cuando hay una secuencialidad entre las tareas y
líneas discontinuas cuando se pueden hacer simultáneamente o no hay un orden
establecido en la realización de las tareas involucradas. Esta relación es un intercambio
de información y por tanto debe tener asociado el nombre del rol que se comunica.
TAN-2
Rol-1 Rol-2
Rol-1 Rol-3
TAN-1 TAN-3 TAN-n
Rol-1 Rol-4
TAN-4
Figura 3-6 Diagrama de Cooperación de TAN
• OM-4: Descripción del componente de conocimientos del modelo de la

organización
Este formulario está asociado con la descripción del conocimiento de cada una de
las Tareas de Alto Nivel intensivas en conocimiento que deben realizarse.
Es importante, hacer una clasificación del conocimiento que se maneja en el

proceso, determinando si se trata de datos, información, habilidades o capacidades, o
conocimiento propio del proceso. De tal forma que en el Formulario OM-4 se analice
más detalladamente el que se refiere al último que se mencionó.
El único cambio que se le ha hecho a este formulario es que en CommonKADS

habla de tareas y en CommonKADS-RT se habla es de TAN.
Modelo de la Capital (Activo) Conocimiento

Activo Poseído Usado en ¿Forma ¿Lugar ¿Tiempo ¿Calidad
Conocimiento por: TAN: correcta? correcto? correcto? correcta?
Nombre Agente TAN (hoja (Si o No; (Si o No; (Si o No; (Si o No;
(hoja (hoja OM-3) comentario) comentario) comentario) comentario)
OM-3) OM-3)
… … … … … … …
Formulario 3-4 OM-4: Descripción del componente de conocimiento del modelo de la
organización
Una vez que se conoce muy bien la situación inicial, se comienza el

planteamiento de las diferentes alternativas de solución, teniendo en cuenta lo que se
indicó anteriormente en relación con la solución basada en conocimientos y de tiempo
real.
• OM-5: Descripción de los aspectos de la organización que tendrán impacto o

estarán afectados por la solución escogida del SBCTR
Para continuar con la metodología CommonKADS-RT, se supone entonces que

la alternativa elegida ha sido evaluar la posibilidad de hacer un SBCTR. Para esto se
sigue con el nuevo Formulario 3-5.

Estructura una vez De acuerdo con la estructura definida en OM-2, especificar los departamentos,
se tenga el SBCTR grupos, unidades, en donde estará implantado el SBCTR.
Nombre de la TAN De OM-3 y OM-4
en donde estará el
SBCTR
Esquema del Ubicación y relación del SBCTR con la situación actual (situación que no tiene
Proceso aún el SBCTR). Es decir, hacer un diagrama de contexto para el SBCTR y si es
automatizado posible, introducir el sistema en el diagrama de actividades como un componente
más del proceso, reflejando las relaciones con él, las entradas necesarias para
realizarlo y las salidas que él produce. Todo esto debe ser complementario con
lo de OM-3.
Personas que Indicar las personas que van a participar en el desarrollo del SBCTR, en su
pueden participar mantenimiento y en el soporte del mismo. Obviamente, definiendo cuál será
en el desarrollo del específicamente su rol en el proyecto: como usuarios del sistema, como expertos
SBCTR en el conocimiento, como desarrolladores, o como clientes o proveedores para el
SBCTR.
Recursos Descripción de los elementos de hardware y software que se necesitan para
hacer el SBCTR y para implantarlo.
Conocimiento Determinar el conocimiento que puede manejar el SBCTR. Debe ser coherente
con lo que se definió en OM-3 y en OM-4.
Restricciones de la Definir el conocimiento o las actividades que el SBCTR no puede realizar, bien
aplicación del porque no se cuenta con los recursos tecnológicos o porque no es conveniente
SBCTR que realice dichas cosas. Es importante decir por qué esa situación.
Restricciones Determinar, en términos generales cómo se hará el manejo o cumplimiento de
Temporales los tiempos definidos de cada una de las TAN, de acuerdo con el Diagrama de
Cooperación de TAN.
Es importante resaltar que en este formulario se hace en forma global, el

análisis temporal de cada una de las TAN a diferencia de lo que se hizo en OM-2
que era del proceso completo.
Cultura y Poder Igual que en OM-2
Impacto Hacer la descripción de los efectos que puede producir el SBCTR en la
organización. Para esto se tiene que identificar exactamente a qué otros
procesos, áreas, personas afectará la solución. Se puede contar con la ayuda que
se plantea en [DeH98] que habla de los riesgos que se pueden encontrar en un
proyecto. Este análisis se complementará con la construcción del modelo de
tareas de alto nivel y del de Agentes.
Formulario 3-5 OM-5: Descripción de los aspectos de la organización que tendrán
impacto o estarán afectados por la solución escogida del SBCTR.
Como se sugiere en la parte esquema del proceso automatizado, es importante

hacer un diagrama de contexto que muestre al SBCTR como una sola transformación
conectada a los flujos de datos y flujos de control – eventos que forman las interfaces
entre el SBCTR y el ambiente que lo rodea. Esto es ubicar el SBCTR en la TAN
apropiada, en donde el sistema puede ser un componente más de ella.
Siguiendo los estereotipos de UML, el diagrama de contexto también puede

verse como la comunicación entre unos agentes (objetos externos) y el sistema (flujo de
datos y de control), reflejando siempre la vista más abstracta que permite revelar lo que
el sistema es y lo que no es. Además, ya que el análisis debe ser hecho para un sistema
basado en el conocimiento de tiempo real, se tienen que considerar ciertas variables
temporales de alto nivel. En la Figura 3-7 se plantea una forma de hacer dicho
diagrama, incluyendo la relación con los agentes del sistema.
datos información
datos
SBCTR información
conocimiento
Actor 2
Actor 1
Estímulos Respuestas
Figura 3-7 Forma general de un Diagrama de Contexto para el SBCTR
Donde:
Representa el sistema central
Representa las entradas o salidas al sistema
Es el actor (ser humano que interactúa con el sistema)
Cuando es de entrada es el agente emisor ( sistema de

información o dispositivo externo al sistema), cuando es de
salida es el agente actuador (sistema de información o
dispositivo externo al sistema)
Representa el flujo de datos o información
Es el flujo de conocimiento
Para el análisis de requerimientos se puede utilizar también una lista de eventos

externos para identificar, en forma global, los eventos del ambiente que son de interés
para el SBCTR. En ésta se detalla el nombre de los eventos, las acciones que el sistema
tiene que realizar como respuesta a dichos eventos, la forma en que cada evento llega al
sistema (periódica o esporádicamente) y el tiempo límite en que el sistema tiene que

realizar sus acciones. Ver la Formulario 3-6.
Evento ctor o Agente Acciones del Tipo de evento Plazo Máximo

ue lo produce SBCTR según su llegada
1 Nombre o Nombre o Qué hace el SBCTR Clasificar el evento Cuál es el tiempo
identificador identificador con el evento. como periódico o que el SBCTR tiene
del evento del agente o del esporádico. para producir una
actor que respuesta apropiada
origina el y oportuna a dicho
evento evento
2
..
Formulario 3-6 Lista de eventos externos que tienen relación con el sistema
Con esto se logra conocer realmente cuáles son los activadores del sistema total y
sus reacciones. Así, cuando posteriormente se requiera desglosar los procesos del
sistema, se tendrá computerizada la información completa sobre el entorno y su relación
con el sistema.
En caso de no conocerse el plazo máximo, se pone desconocido y se tendrá en

cuenta para más adelante. Es importante anotar, que esta tabla se puede detallar más en
la medida en que se va avanzando en el proceso del análisis y diseño del SBCTR.
Integrando la información obtenida del diagrama de contexto del SBCTR, el

diagrama de actividades con el SBCTR incluido y la lista de eventos externos, se puede
construir un gráfico completo y detallado del SBCTR.
• OM-6: Lista de chequeo para el documento de viabilidad de la decisión de hacer

un SBCTR
Este formulario plantea una serie de conceptos y criterios que se utilizan en la

preparación y evaluación de un proyecto tecnológico y que se deben tener en cuenta
para tomar una decisión acerca de la posibilidad de solucionar un problema por medio
de un SBCTR.
Modelo de la Lista de Chequeo para el documento de la viabilidad de la decisión.

Viabilidad del Para un área o problema dado y una solución sugerida, las siguientes preguntas tienen
negocio que ser respondidas:
1. ¿Cuáles son los costes esperados para la solución considerada?
2. ¿Cuáles son los beneficios esperados para la organización con la solución
considerada? Se deben identificar tanto los económicos tangibles como los
intangibles.
3. Hacer el cálculo de la razón beneficio / costo o de otra razón económica
4. ¿En cuánto tiempo se espera recuperar la inversión?
5. ¿Cómo se compara con otras posibles soluciones alternativas?
6. ¿Cuál es el impacto de la solución considerada?
7. ¿Se requieren cambios en la organización?
Viabilidad técnica Para un área o problema dado y una solución sugerida, las siguientes preguntas tienen
que ser respondidas:

1. ¿Qué tan compleja, en cuanto al almacenamiento del conocimiento y de procesos
de razonamiento que deben ser realizados, es la tarea de alto nivel a ser ejecutada
por el sistema de conocimiento considerado como solución?
2. ¿Hay aspectos críticos en el proceso relacionados con el tiempo?, ¿El proceso
tiene restricciones temporales?
3. ¿Hay aspectos críticos involucrados que se relacionen con la calidad, con los
recursos necesarios, o con otras cosas? Si es así, ¿cómo es esto?
4. ¿Es clara la forma para medir el éxito? ¿Cómo comprobar que se tiene una
ejecución satisfactoria y es de buena calidad?
5. ¿Qué tan compleja es la interacción requerida con los usuarios finales (interfaces
de usuario)? ¿Son el estado del arte los métodos y las técnicas disponibles y son
adecuadas?
6. ¿Qué tan compleja es la interacción con los otros sistemas de información, otros
dispositivos o periféricos y otros posibles recursos (interoperabilidad,
integración de sistemas, compatibilidad)? ¿Son el estado del arte los métodos y
las técnicas disponibles y son adecuadas?
7. ¿Hay otros riesgos tecnológicos e incertidumbre?
También, se deben hacer preguntas relacionadas con el tipo de herramientas que

pueden ser utilizadas, su disponibilidad, escalabilidad, entre otras.
1. Costes implícitos en la adquisición, adecuación y funcionamiento de los
equipos
2. ¿Cuál es el tiempo de vida útil que se espera tenga el sistema y cuál será la
calidad del servicio prestado en el tiempo?
3. Deben tenerse en cuenta los aspectos críticos, las fallas técnicas y los avances
tecnológicos para así cuando se presente una sobrecarga transitoria se
garantice que los requerimientos temporales críticos se cumplan
4. Se debe garantizar la estabilidad del sistema
En resumen, es aplicar los criterios planteados en el anexo 1.

Viabilidad del Para un área o problema dada y una solución sugerida, las siguientes preguntas tienen
proyecto que ser contestadas:
¿Hay un compromiso adecuado de los actores e interesados (gerentes, expertos,

usuarios, clientes, miembros del equipo del proyecto) para realizar las otras etapas del
proyecto?
¿Pueden estar disponibles los recursos que se necesitan, desde el punto de vista del
tiempo, horario, equipos, personas?
¿Está disponible el conocimiento requerido y otras habilidades?
¿Son realistas las expectativas del proyecto y sus resultados?
¿Es la organización del proyecto y su comunicación interna y externa adecuada?
¿Hay otros riesgos e incertidumbre del proyecto? ¿Cuáles?
Acciones Esta es la parte del documento que está directamente relacionada con la gerencia y la
propuestas toma de decisiones. Para ello se valoran e integran los resultados del análisis que hasta
el momento se ha realizado, en pasos concretos:
Enfoque: ¿Cuál es el enfoque recomendado en las áreas o problemas identificadas?

Solución objetivo: ¿Cuál es la dirección de la solución recomendada para esta
situación?
¿Cuáles son los resultados y los beneficios esperados?
¿Cuáles son las acciones del proyecto que se tienen que llevar a cabo para poder
realizarlo?
¿Si las circunstancias dentro y fuera de la organización cambian, en cuáles condiciones
es prudente reconsiderar la decisión propuesta?
Formulario 3-7 OM-6. Lista de chequeo para el documento de viabilidad de la
decisión de hacer un SBCTR
3.6.1.2 Artefactos del modelo de la organización
El modelo de la organización lo que permite identificar son los elementos del contexto
(perspectiva externa) y del comportamiento (cómo se comporta) del sistema. Dentro de los
del contexto están los actores, los casos de uso, los mensajes externos y los riesgos
identificados; dentro de los de comportamiento están las restricciones del sistema de tiempo
real, la descripción del proceso del negocio, los diagramas de transición, los escenarios y
los protocolos de mensajes entre los diferentes actores y agentes (esta parte se deja para
completarla con otros modelos).
Por lo tanto, los resultados que se obtienen con la definición del modelo de la
organización se refieren a los requerimientos del análisis realizado para identificar en
dónde es posible o viable hacer un SBCTR, además de definir la semántica de dicho
sistema. Para ello se tienen la lista de eventos externos, los casos de uso, el diagrama de
contexto, el diagrama de actividades, el análisis de riesgo, la matriz DOGA y los criterios
de filtrado, entre otros.
En la Figura 3-8 se puede apreciar las actividades y artefactos de este modelo de

CommonKADS-RT.
Es importante resaltar varios aspectos que se observan en dicha figura:
• A este nivel no se considera importante ni conveniente llegar a definir las tareas de

bajo nivel desde el punto de vista de tiempo real. Eso más bien queda para más
adelante como parte el diseño.
• Los formularios OM-1, OM-2, OM-3 y OM-4 forman parte del Dominio del
Problema. Es decir, que ellos se obtienen a través del análisis de la situación actual y
real que se manifiesta en la organización, sin considerar el tipo de solución más
apropiado para modificar ese estado inicial.
• Los formularios OM-5 y OM-6 forman parte del Dominio de la Solución. Es decir,
que están asociados directamente con la solución elegida, con el desarrollo de un
SBCTR.
• En unas situaciones, algunas de las actividades o de los artefactos pueden ser

omitidos. Por ejemplo, si ya está definido el problema a resolver, entonces no es
necesario de hacer la matriz DAFO.
3.6.1.3 Roles en el modelo de la organización
Para llevar a cabo el modelado organizacional se requiere contar con un grupo

interdisciplinario. El perfil del conocimiento, es decir que se necesita que las personas del
equipo sepan de lo siguiente: - Planificación estratégica. - Evalución de proyecto. -
Ingeniería del conocimiento. - Manejo de sistemas de tiempo real. - Tecnologías
informáticas
Organización
debilidades fortalezas
amenazas oportunidades
Lista de problemas + lista de estrategias

OM-1
+ Contexto organizacional
problemas y estrategias intensivas en

conocimientos y tiempo real
priorización
Lista de posibles SBCTR (ordenados

por prioridades)
Problema elegido
Estructura Impacto
de la
organización Cultura OM-2
Proceso Personas que y poder
asociado al participan en el Restricciones
problema proceso Recursos Prioridad
Conocimiento
TAN del proceso

¿Sist. Inf.?
Identificador
Nombre OM-3
Importancia Restricciones
Tipo Agente temporales
Intensivo en
Localización
Conocimiento
OM-4 Activo Conocimiento
SBCTR Propuesto
Impacto
Ubicación del
SBCTR Cultura
Esquema del Personas que Restricciones y poder OM-5
proceso participan
automatizado Recursos Restricciones del
Conocimiento
De OM-1, OM-2, OM-3, OM-4, OM-5

- Viabilidad del Negocio
- Viabilidad técnica
Viabilidad
- Viabilidad del proyecto OM-6
- Acciones propuestas
Figura 3-8 Modelo de la organización de CommonKADS-RT

Adicionalmente, se tiene que tener identificado y concertado al (los) experto(s) del

dominio y al (los) usuario(s) y un gerente o líder de proyecto que sea quien se encargue,
entre otras cosas, de servir como enlace entre el grupo de desarrollo y la alta gerencia.
3.6.2 Modelo de tareas de alto nivel

Las tareas de alto nivel son las partes que conforman un proceso del negocio y que
representan una actividad orientada por las metas, dándole valor a la organización. Éstas a
su vez, pueden estar formadas por otras tareas que pueden ser de tiempo real o no. En
CommonKADS esto se refleja en lo que se denomina el Modelo de Tareas, pero en esta
propuesta se le ha cambiado el nombre por Modelo de Tareas de Alto Nivel para hacer una
diferencia entre las tareas que se relacionan con los procesos del negocio y las tareas que se
manejan a más bajo nivel en los sistemas de tiempo real. Estas últimas se especifican en el
nuevo modelo llamado Modelo de Tareas de Tiempo Real y que se explica más adelante.
Una Tarea de Alto Nivel (TAN) es entonces el reflejo de un proceso organizacional, el

cual se compone de un objetivo, una definición del problema y una forma o método para
alcanzar la solución. Durante la ejecución de la tarea se manejan entradas, se consumen
recursos y se producen salidas de una forma estructurada y controlada, basados en unos
conocimientos y habilidades que permiten definir el método de solución. Adicionalmente,
es importante que la tarea tenga asociados unos criterios de desempeño y de calidad
determinados.
Si por ejemplo se tiene que el proceso que se identificó en unos de los escenarios que
se presentan en el capítulo 4, relacionado con la Operativa Marítima en una terminal de
contenedores, entonces las tareas de alto nivel que lo conforman son:
à Atención
à Scheduling
TAN1
à Planificación
TAN2
à Operativa Marítima
TAN3
à Despacho
TAN4
TAN5
Donde, cada una de ellas debe ser analizada en detalle y puede a su vez, convertirse en
un proceso para ser trabajado independientemente y definido como una TAN que también
debe ser modelada y analizada. Por lo tanto, si en un momento determinado se encuentra
que una buena solución se obtiene con el planteamiento del SBCTR para una de estas TAN,
entonces se deben replantear las consideraciones del modelo de la organización y continuar
con la definición de tareas de alto nivel para ese nuevo proceso.
Siguiendo con el ejemplo anterior, si se quiere sólo trabajar la parte de scheduling,

entonces se tienen las siguientes tareas de alto nivel:
à Identificación de requerimientos y situación actual

à Asignación de recursos
TAN2,1
à Adecuación de los demás servicios que están en el Muelle.

TAN2,2
TAN2,3
Es importante anotar, que este caso se presenta completamente en el Capítulo 4. de

este documento.
Las TAN a su vez, pueden ser descompuestas en tareas hasta llegar a un nivel en
donde no sea posible descomponer más. En el modelo de conocimientos se especificará el
conocimiento que se requiere para llevarlas a cabo. El nivel más bajo de las tareas (las
tareas de las hojas del diagrama de descomposición de tareas), es el que se ampliará en el
modelo de comunicación.
3.6.2.1 Formularios del modelo de TAN
El modelo de tareas de alto nivel, por lo tanto debe permitir examinar cada una de las
tareas en forma global, sus entradas, salidas, precondiciones, criterios de ejecución,
recursos y habilidades necesarias para su realización. Para esto se tienen los formularios
TM-1, TM-2 y TM-3 que permiten reflejar el conocimiento relacionado con dichas
funciones.
• TM-1: Descripción refinada de las tareas de alto nivel dentro del proceso objetivo
Este formulario permite ubicar cada una de las TAN dentro del proceso al que
pertenecen y hacer una descripción más detallada de ella. También amplía la
información que en el modelo de la organización se trató en los apartes que hablaban de
las tareas de alto nivel.
Modelo de Tarea de Alto Nivel Análisis de la Tarea de Alto Nivel

Hoja de Trabajo TM-1
Tarea de alto nivel (Como en OM-3) Identificador y nombre de la TAN
Ubicación en la (Como en OM-3) Indica el proceso de negocio del cual la TAN es parte, y en
Organización dónde es realizada en la organización (Localización y
Estructura).
Objetivo y valor Describe la meta de la TAN y el valor que su ejecución
adiciona al proceso al que ella pertenece.
Dependencia /Flujo Partiendo de los diagramas de actividades y de contexto
realizados como parte del modelo de la organización,
construir el nivel 1 para identificar las TAN que forman el
proceso. También es posible hacer un formulario similar a
OM-3 pero para la TAN específica (esto confirma las ideas
del ciclo de vida en espiral que se sigue en CommonKADS-
RT). Este formulario se llamará TM-1.1 y facilitará el
determinar:
1. TAN Otras TAN ejecutadas antes que la TAN y que le proporcionan

predecesoras entradas a ella.
2. TAN que la TAN ejecutadas después de ésta y que usan alguna(s) de su(s)
siguen salida(s)
3. TAN TAN que pueden hacerse en forma simultánea
concurrentes
Objetos manejados 1. Objetos deLos objetos, incluyendo los elementos de datos, información,
en la TAN entrada eventos y de conocimiento que constituyen la entrada de la
TAN.
2. Objetos de Los objetos, incluyendo la información que entrega la TAN
salida como salida.

3. Objetos Objetos importantes (si los hay), incluyendo los datos, la
internos información y el conocimiento que son usados internamente
dentro de la TAN y que no son entrada ni salida de / para otras.
Se puede utilizar el diagrama de conceptos, pero sin la
especificación de sus atributos y valores, sólo algo general.
También se debe hacer un diagrama de flujo de la TAN,
para mostrar el flujo de los datos y los principales procesos
dentro de ella.
Tiempo y Control 1. Frecuencia, Cada cuánto tiempo se ejecuta la TAN, cuánto tiempo consume
duración normalmente.
2. Tiempo límite Cuál es el tiempo máximo definido para que se realice la
TAN, si es que lo tiene.
3. Periodicidad ¿La TAN se realiza en forma periódica o no?
4. Control Estructura de control sobre la TAN y las otras TAN que
tienen relación de dependencia (entrada / salida) con ella.
Para esto se toma como base el diagrama de actividades del
Modelo anterior y se perfecciona o detalla. También con el
diagrama de flujo que se realizó
5. Restricciones Precondiciones que tienen que cumplirse antes de que la TAN
sea ejecutada;
Poscondiciones que tienen que mantenerse como un resultado
de la ejecución de la TAN; Restricciones que tienen que ser
satisfechas durante la TAN.
Agentes (De OM-1 y OM-2: Los miembros de la empresa (Como en OM-2.1-2.2/3,
las personas, y los personas), los sistemas informáticos y los periféricos o
recursos de dispositivos (como en OM-2.1, OM-2.2 y OM-3, recursos)
sistemas; de OM-3: que son responsables de realizar la TAN.
el ejecutado por)
Conocimiento y (Como en OM-4) Las habilidades y capacidades necesarias para ejecutar
Habilidades exitosamente la TAN. Para esto hay una hoja de trabajo
separada TM-2, que permite detallar mucho más las
características del conocimiento.
Indicar cuáles elementos de la TAN o qué partes de la TAN,
son intensivos en conocimiento. También se deben decir las
capacidades que las tareas proporcionan a la organización.
Recursos (Refinamiento de Descripción de los recursos consumidos o utilizados en la TAN
OM-2) (personas, sistemas y equipos, materiales, presupuesto
financiero). También sería importante cuantificar dichos
recursos en cuanto a su valor.
Calidad y Medidas Lista de las medidas de calidad y de rendimiento (eficiencia)
Rendimiento utilizadas en la organización para determinar la ejecución
exitosa de la TAN; si es que hay.
Formulario 3-8 TM-1: Descripción refinada de las tareas de alto nivel dentro del
proceso objetivo
Como se puede deducir de este formulario, algunos de sus elementos tienen

relación o se pueden expresar de acuerdo con algunos de los paradigmas metodológicos
de la Ingeniería del Software. En todos esos enfoques, se puede hacer una vista
tridimensional de este modelado en diversas dimensiones:
− Modelo Funcional: descomposición en tareas, sus entradas y salidas, y en el flujo

E / S que conecta esas tareas en una red de flujo de información completa. Los
diagramas de actividades y los diagramas de flujo son técnicas ampliamente
usadas en este caso.
− Modelo Estructural: una descripción del contenido de la información y de la

estructura de los objetos que son manejados en la tarea, tales como objetos de
entrada y de salida, en el lenguaje de entidades y sus relaciones (u objetos y
asociaciones). Para esto se utilizan los diagramas de entidad relación, el
diagrama de conceptos (en términos de Objetos es el diagrama de clases) y el de
objetos.
− Modelo Control / Dinámicas: una descripción del orden temporal de y para el

control de las tareas, provee el cuadro de los eventos de disparo, los puntos de
toma de decisión y otros aspectos del tiempo. En el modelado de la información,
este aspecto es comúnmente representado por medio de diagramas estado -
transición o de actividades.
• TM-2: Especificación del conocimiento empleado en la tarea de alto nivel y

posibles cuellos de botella y áreas para mejorar
Si la TAN es intensiva o basada en conocimientos, entonces se pone énfasis en

ella con el fin de establecer la relación directa entre el modelo de tareas de alto nivel y
el modelo de conocimientos.
Modelo de Tarea de Alto Nivel Elemento de Conocimiento

Hoja de Trabajo TM-2
Nombre: Elemento de Conocimiento
Poseído por: Agente
Usado en: Nombre e identificador de la TAN
Dominio: Dominio más amplio de conocimiento que está
embebido (dominio de los especialistas, disciplina,
rama de la ciencia o ingeniería, comunidad
profesional)
Naturaleza del Conocimiento ¿Cuello de botella?/¿Para ser mejorado?
Formal, riguroso
Empírico, cuantitativo
Heurístico
Altamente especializado,
Específico del dominio
Basado en la experiencia
Basado en la acción
Incompleto
Incierto, puede ser incorrecto
Cambiante rápidamente
Difícil de verificar
Tácito, difícil de transferir
Forma del Conocimiento

En la mente
En papel
En forma electrónica
Habilidades de acción
Otros
Estructura del
Conocimiento
Cómo está conformado

Cómo se puede representar
¿Se puede manejar todo en
un ordenador?
¿Cómo se puede pasar de
una TAN a otra?
Disponibilidad del
Conocimiento
Limitaciones en tiempo
Limitaciones en espacio
Limitaciones en acceso
Limitaciones en calidad
Limitaciones en forma
Formulario 3-9 TM-2 Especificación del conocimiento empleado en la tarea de alto
nivel y posibles cuellos de botella y áreas para mejorar
Hasta el momento sólo se ha hablado del conocimiento de las tareas dado que
CommonKADS fue planteada para SBC, pero como CommonKADS-RT también tiene
que involucrar el tiempo, entonces se requiere otra información importante para
modelar apropiadamente la TAN. Por ello se ha incluido el siguiente nuevo formulario.
• TM-3: Descripción de las tareas de alto nivel a través de los eventos que las afectan
Este formulario permite conocer las entradas y salidas de la TAN,

específicamente los estímulos y respuestas que ofrecen y que en última instancia, serán
los que definan el sistema. En realidad es hacer un análisis de escenarios en donde cada
TAN se describe a través de la determinación de sus entradas y salidas, siguiendo este
formulario. Es de anotar que es más conveniente hacer este análisis después de haber
analizado TM-1 y antes de TM-2.
Tabla 3-2 Descripción de las tareas de alto nivel a través de los eventos que las
afectan
Modelo de Tarea de Descripción de estímulos y respuestas de la TAN
Alto Nivel Hoja de Trabajo TM-3
Estímulo, puede ser un Nombre del Escenario, Respuesta, puede ser un evento de salida de
evento de entrada de nombre del proceso de datos (información) o de control resultante y
datos o un evento de la TAN que se ve los estados modificados del sistema
control y los estados afectado por el evento
actuales del sistema
completo
También, en los sistemas de tiempo real se pueden asociar las TAN a los
dispositivos, mecanismos o subsistemas que lo forman. Por lo tanto, si se diligencia el
formulario TM-3 para cada uno de ellos, entonces se tienen el análisis completo de
cómo funciona, qué hace, qué requiere para actuar y qué produce.
Además, se deben modelar los eventos que ocurren en la tarea con la ayuda de
los diagramas de transición de estados y de la lista de eventos externos que se plantea
en el modelo de agentes (como en la Tabla 3-3).
3.6.2.2 Artefactos del modelo de TAN
El modelo de TAN permite describir en forma detallada los procesos intensivos en

conocimientos y con restricciones temporales que se realizan en la unidad de la
organización.
Los artefactos o productos que se obtienen en este modelo son:
• Los formularios diligenciados o la documentación relativa a ellos.
• Los diagramas de flujo y de conceptos para especificar los objetos de la TAN y el

flujo de datos dentro de ella.
• Los diagramas de eventos, de actividades y de transición de estados, para mostrar

las relaciones con las otras TAN o con los agentes y su variación en el tiempo.
• El tipo de tarea, de acuerdo con los tipos de problemas o procesos generales y que
permite reutilizar las plantillas definidas en CommonKADS y optimizan el tiempo
del modelado del conocimiento.
• La identificación de las restricciones temporales que pueden definirse en una TAN.
3.6.2.3 Roles en el modelo de tareas de alto nivel
Para realizar este modelo se requiere que participen el (los) experto(s) del dominio, el
(los) usuario(s), el (los) ingenieros del conocimiento y tiempo real, y el gerente del
proyecto.
3.6.3 Modelo de agentes

Un agente es el ejecutor de una TAN, puede ser un humano, un sistema de
información computarizado o cualquier entidad que sea capaz de realizarla. Así, en este
modelo se define cómo son los agentes, cómo se caracterizan, qué conocimiento tienen y
con quién se comunican. Además, el modelo proporciona el enlace entre los Modelos de
Tarea de Alto Nivel, Comunicación y Conocimiento.
En CommonKADS no se profundiza mucho en este modelo ni se comenta cómo

modelar el problema cuando varios agentes heterogéneos (unos humanos y otros sistemas
computarizados) se comunican para participar en una TAN específica.
Por esto, el concepto que en esta propuesta se maneja es que además de lo anterior, se
debe considerar que:
• El agente puede ser simplemente el que solicita un servicio, el que lo realiza o el que
se ve afectado por lo que otro hace.
• Se propone que los agentes heterogéneos sean tratados en forma diferente,

especialmente para su modelado gráfico. Así, se tiene lo siguientes:
− El agente actor, que es el ser humano que ejecuta una TAN o parte de ella.
− El agente software que se encarga de la percepción, la cognición o la actuación

dentro de una TAN. Dentro de estos pueden haber agentes emisores o agentes
actuadores. El agente a la vez puede hacer tareas de percepción y cognición o de
cognición y acción, o las tres a la vez.
• El SBCTR no se considera un agente para él mismo. Así que sólo será un agente,
cuando se esté modelando otro sistema diferente de él. Pero, es posible que el
SBCTR esté conformado por una serie de agentes, llegando a ser un sistema
multiagentes (esto requiere de otras consideraciones que no están dentro del alcance
de esta investigación).
• También, es importante clasificarlo en relación con la TAN que se definió en TM-1

y, es fundamental determinar las condiciones temporales de las funciones del agente,
esto para efectos prácticos del modelado y manejo del conocimiento del SBCTR.
A continuación se presenta el formulario de este modelo con los cambios ya incluidos:
3.6.3.1 Formularios del modelo de agentes
• AM-1: Especificación de los agentes del SBCTR
Modelo de Agente Agente

Hoja de Trabajo AM-1
Nombre Nombre del agente
Ubicación en la Indica cómo se ubica el agente en la organización, igual que lo que se definió
Organización en el modelo de la organización, incluyendo el tipo (humano, sistema de
información), posición en la estructura de la organización. Se toma como base
el diagrama de contexto y la lista de los eventos que se hicieron
anteriormente. Además, se pueden construir diagramas de casos de uso.
Ubicación en la(s) Lista de nombres e identificadores de TAN en donde participa el agente
TAN (Como en TM-1). También la forma de esa participación, es decir como
solicitante, ejecutor o beneficiario.
Tipo de agente Es un actor o un agente software. Y si es de este último tipo, entonces decir
si es un agente que percibe el entorno, que hace procesos de
razonamientos o que actúa sobre el entorno. En caso de ser un actor que
puede aportar mucho conocimiento para el sistema, entonces debe ser
considerado como una fuente dinámica para realizar el proceso de
adquisición del conocimiento.
Restricciones En caso de que el agente tenga que realizar la TAN en un plazo máximo o
temporales en un momento determinado o cada cierto tiempo (período)
Se Comunica con Lista de nombres de otros de agentes con los que se relaciona
Conocimiento Lista de puntos de conocimiento poseídos por el agente (Como en TM-2)

Otras Destrezas Lista de otras destrezas requeridas o presentes del agente
Responsabilidades y Lista de responsabilidades que el agente tiene en la ejecución de la TAN, y de
Restricciones las restricciones al respecto. Las restricciones pueden referirse tanto a
limitaciones en autoridad, como también a normas externas legales,
profesionales, o semejantes
Formulario 3-10 AM-1: Especificación de los agentes del SBCTR
La relación entre los agentes y el sistema permite determinar los mensajes –

eventos del sistema con el exterior. En un SBCTR es muy importante determinar cómo
es el patrón de llegada de los mensajes, periódicos o aperiódicos, y cómo es el patrón de
sincronización de los mismos, tal como se explicó en el apartado relacionado con
Tiempo Real.
Para este análisis se utiliza la lista de eventos externos para identificar los eventos
del ambiente que son de interés para el SBCTR. En ésta se señala el nombre de los
eventos, quién lo produce, las acciones que el sistema tiene que realizar como respuesta
a dichos eventos, la forma en que cada evento llega al sistema (periódico o esporádico)
y el tiempo límite en que el sistema tiene que realizar las acciones – deadline (ver la
Tabla 3-3).
Tabla 3-3 Ejemplo de la lista de eventos externos que tienen relación con el sistema
Evento Agente que Acciones del Tipo de evento deadline
lo produce Sistema según su llegada
1 ev-señal-sensor Bumper evitar-obstáculo periódico desconocido
2
..
Como se dijo anteriormente, esta tabla se puede detallar más en la medida en que
se vaya avanzando en el proceso de análisis del SBCTR.
Si el evento es periódico, entonces en el modelo de las tareas de tiempo real éste

tiene que tener definido su período y el jitter (variación del período). Si es esporádico
tiene que tener definido el tiempo mínimo entre llegadas y la ratio promedio. A su vez,
las respuestas del sistema tienen que ser definidas en función de deadlines. Cuando sea
apropiado, el rendimiento de la respuesta puede ser especificado como el deadline del
peor de los casos y un tiempo promedio de respuesta.
Hay un caso típico de un sistema inteligente de tiempo real que consiste en

modelar el funcionamiento de un ascensor estándar y que dispone de un sistema de
ascensores en el que hay que optimizar su gestión ante las demandas de los posibles
usuarios [BHS99]. Si se toma como base una TAN para la asignación de un ascensor,
para atender una solicitud de un posible pasajero se tienen que definir cuáles son los
escenarios posibles que se pueden presentar ante esa situación, cómo es la secuencia de
los mensajes que se deben intercambiar, cuáles son los posibles estados en que se puede
estar en un momento dado y cuáles son las características de los eventos que ocurren en
el entorno y que afectan o deben ser procesados por el sistema. Para precisar los
eventos del sistema se utiliza de nuevo la tabla de eventos externos. Ver Tabla 3-4
Tabla 3-4 Tabla de eventos para el caso de un ascensor

Evento Agente que Acciones del Sistema Tipo de evento deadline
lo produce según su llegada
1 Llamada Pasajero a. Encender botón Esporádico a. Encender 2 s.
de potencial b. Poner solicitud en b. 1 s.
ascensor lista de espera
c. Enviar el ascensor c. 5 s. X # pisos
seleccionado al piso
2 Solicitud Pasajero d. Encender botón Esporádico d. 0.5 s.
piso e. Enviar ascensor al e. 5 s. X # pisos
piso
3 Presión Pasajero f. Puerta empieza a Esporádico f. 0.5 s.
botón para abrirse, se inicia el
abrir contador de tiempo de
cierre de puerta
Y, los diagramas de secuencia para un posible escenario son los de la siguiente

figura. En donde en la parte a) se presenta la situación más general y en la b) una
situación más detallada que incluye los tiempos, supuestos, que se han medido para la
realización de algunas de las tareas. Con éste se pueden identificar los conceptos, las
relaciones e incluso las inferencias que se requieren para realizar una TAN que se
encargue de modelar una situación similar.
Además y como se mencionó anteriormente, estos se pueden seguir utilizando

hasta llegar a tener un grado tal de detalle que después permitan pasar fácilmente a la
codificación del sistema o incluso al modelado a un nivel más bajo utilizando, por
ejemplo, las Redes de Petri para garantizar que lo que se ha modelado es realmente lo
que se va a construir.
a)
Pasajero potencial Ascensor Ascensor Pasajero
Pasajero Solicitud subir Solicitud piso 3

potencial está en elevador
el piso 1
Enciende luz de Enciende
llamado indicador de
piso
Desciende hasta Sube hasta
piso 1 el piso 3
Ascensor llega al
piso 3
Ascensor llega al Puerta se abre Puerta se abre
piso 1 Pasajero se baja
Pasajero Ascensor queda
potencial pasa a en espera de una
ser Pasajero solicitud
b)
Pasajero Ascensor Ascensor Pasajero
Pasajero Solicitud piso 3

Pulsa botón de Ascensor está en
potencial está en
llamado el piso 5
el piso 1
Enciende
Enciende luz de indicador de
llamado 2 seg.
piso 3
Sube hasta el
Cola solicitudes piso 3
t=5 seg. X 2
pisos
Apaga luz de
Ascensor llega al llamado Ascensor llega al Apaga indicador
piso 1 piso 3 del piso 3
Puerta se abre
Enciende luz de
Pasajero 3 seg. llamado
potencial pasa a Fin de tiempo de
ser Pasajero puerta y cierra
Puerta se abre
Pasajero se baja
Fin de tiempo de
Ascensor queda puerta y cierra
en espera de una
solicitud
Figura 3-9 Ejemplo de diagramas de secuencia a) y b)
Si se plantea una situación en la cual se tienen varios ascensores y se quiere

aplicar conocimiento para la asignación de uno de ellos de acuerdo con la situación
específica, se requiere entonces de hechos, heurísticas y relaciones para la toma de
decisiones.
En este caso, el pasajero potencial y el pasajero son los agentes actores y el

ascensor es un agente receptor. También, se podrían definir como conceptos del
dominio del ascensor a los botones, las puertas, las alarmas, los sensores, entre otros. La
TAN sería asignar el ascensor más apropiado, y para ello se retomaría lo planteado en
[SAA+98], haciendo una reutilización de las librerías de CommonKADS, para obtener
lo siguiente:
Los diagramas de casos de uso se pueden utilizar de nuevo en este modelo, para
mostrar realmente cómo es la comunicación entre los agentes y el SBCTR, lo cual se
debe detallar mucho más en el modelo de comunicaciones por medio de los diagramas
de secuencia.
Solicitud de
servicios
Jefe de
Planificación Planeación de
actividades
Barco
<<uses>>
Asignación de
recursos
<<uses>>
Orden de
carga
Figura 3-10 Ejemplo de un caso de uso para algunos agentes en la terminal de

contenedores del puerto de Valencia
3.6.3.2 Artefactos del modelo de agentes
Al igual que para el modelo de TAN, los productos de este modelo se refieren a la
documentación, el formulario y los gráficos que en él se han realizado. Es decir:
• El formulario AM-1,
• Los diferentes agentes del SBCTR, con sus características y especificaciones

temporales.
• Los diagramas de casos de uso y la lista de eventos externos.
3.6.3.3 Roles en el modelo de agentes
Son los mismos que participan en el modelo de TAN mas los actores que se hayan
identificado.
3.6.4 Modelo de conocimiento

En CommonKADS este modelo permite explicar en detalle los tipos y estructuras del
conocimiento específico de un dominio y de la situación, que se utilizan en la ejecución de
una TAN particular. Fundamentalmente, este modelo captura las tres principales categorías
del conocimiento: conocimiento de la tarea, conocimiento del dominio y conocimiento de
la inferencia. La descripción que provee es independiente de la implementación del rol que
los diferentes componentes del conocimiento juegan en la solución del problema y lo hace
en una forma que es entendible por los humanos. Esto hace que el modelo de conocimientos
sea un medio importante para la comunicación entre los expertos y los usuarios durante el
desarrollo del sistema y en su ejecución.
Para construir este modelo primero se debe identificar el conocimiento, luego se debe
especificar y después, se debe hacer su refinamiento. A continuación se presenta la idea
general de estos procesos, que al final quedarán reflejados en diferentes formularios y en
especial en el Formulario 3-11 KM-1: Lista de comprobación de la documentación del
modelo del conocimiento.
• Identificación del conocimiento, específicamente la determinación de las fuentes de

conocimiento a utilizar y la construcción de un glosario de términos básicos del
dominio. Esto servirá para establecer el vocabulario común entre los ingenieros del
conocimiento, los expertos y los usuarios. En el glosario se pueden incluir la
terminología propia de los sistemas basados en el conocimiento de tiempo real y de
la metodología misma. Adicionalmente, se debe especificar el apartado del
conocimiento del modelo de la organización, la caracterización de la tarea de
aplicación en el modelo de TAN y la revisión de las diferentes plantillas de las tareas
generales y librerías de CommonKADS para identificar componentes que puedan ser
reutilizados.
• Especificación del conocimiento, en especial del que se va a modelar, diferenciando

las entradas, las inferencias y las salidas. El resultado final de este proceso es la
obtención del conocimiento de inferencia, el conocimiento de la tarea y el del
dominio para el SBCTR.
Para realizar esto, se cuenta con el diagrama de conceptos que es un esquema

del conocimiento del dominio. Este diagrama es muy similar al diagrama de clases
de UML, sólo que no se definen los métodos que se realizan en el concepto ya que
estos formarán parte del conocimiento de la inferencia. Recuérdese en el modelo de
TAN se planteó hacer un diagrama de este estilo a un nivel general, para dar una idea
de los objetos y las relaciones que pueden existir entre ellos.
Para facilitar el manejo del conocimiento del dominio se introduce la idea de

subdominios, análogo al dominio que se manejan en UML, en donde estos son
categorías que se identifican claramente en el dominio del conocimiento.
Por ejemplo en el dominio de marítima, que se presenta en Capítulo 4. sección

4.3, se pueden encontrar diversos conceptos que pueden ser clasificados en sub-
dominios de la siguiente forma:
1) subdominio-muelle. Contiene los conceptos específicos del muelle, tales como: la

posición en la terminal, la pila, la calle y la planta.
2) subdominio-maquinaria. Contiene los conceptos de maquinaria que se manejan

en el muelle: máquina, frontal, grúa, chasis de la terminal, transtainer.
3) subdominio-documentación, que incluye los conceptos: carpeta, E.T.A.,

secuencia y Bayplan.
Identificar sub-dominio del dominio facilita tanto el tratamiento de los

conceptos, como la profundización y reutilización del conocimiento puesto que
posibilita la identificación del tipo de conocimiento y su aplicación en diversos
problemas.
• Refinamiento del conocimiento, en donde se hacen las pruebas de la estructura del

conocimiento a través de simulaciones y en caso de ser positivas las evaluaciones,
entonces se completan las bases de conocimiento.
A continuación se presenta el formulario KM-1 que presenta el registro de la

información relacionada con el proceso de adquisición y representación del conocimiento
planteado en los párrafos anteriores.
Modelo de Conocimientos Lista de comprobación de la documentación del modelo de

conocimientos
Hoja de Trabajo KM-1
Modelo de Conocimientos Especificación completa del modelo de conocimientos en forma textual e
inclusión de algunas figuras relevantes. Es la instanciación de la Figura
3-10, la composición del diagrama de conceptos, la definición de
subdominios, de la base de conocimientos, el conocimiento de
inferencia y de la tarea.
Fuentes Estáticas de Lista de todas las fuentes de información acerca del dominio de la
Conocimientos usadas aplicación que serán o han sido consultadas. Esta lista es primero
producida durante la etapa de identificación. Contiene toda la
descripción bibliográfica y una explicación de para qué es utilizada
cada fuente.
Fuentes Dinámicas de Lista de las personas que proporcionarán o proporcionaron el
Conocimientos utilizadas conocimiento en el dominio específico. En caso de ser varios,
ordenarlos por participación e importancia o relevancia de su
conocimiento para la solución del problema o la realización de la
TAN. También, junto al nombre se debe tener una descripción
detallada de su conocimiento específico. Determinar cuáles son
agentes. Esta información está muy relacionada con lo que se
determina en el modelo de agentes.
Glosario Lista de los términos del dominio de aplicación junto con una definición,
bien sea en forma textual o gráfica. En esta lista se deben incluir los
conceptos del diagrama de conceptos
Componentes considerados Lista de componentes potencialmente reutilizables que fueron
considerados en la etapa de identificación, mas una decisión y una razón
de por qué el componente fue o no fue usado. Los componentes son
típicamente de dos tipos: orientado a tareas (por ejemplo los formularios
de la tarea) y orientados al dominio (por ejemplo las ontologías, las bases
de conocimiento) que se pueden tener.
Escenarios Una lista de los escenarios para la solución de los problemas de la
aplicación recogidos durante el proceso de construcción del modelo.
Estándares de validación Conceptos o criterios a tener en cuenta para hacer la validación de la
planificación de las tareas, del conocimiento y del razonamiento.
Resultados de validación Descripción de los resultados de los estudios de validación, en particular
las simulaciones basadas en papel o en ordenador (prototipos)
Material de Extracción Material obtenido durante las actividades de extracción del conocimiento
(por ejemplo la trascripción de las entrevistas) en apéndices.
Formulario 3-11 KM-1: Lista de comprobación de la documentación del modelo del
conocimiento
Desde el punto de vista de los SBCTR CommonKADS no proporciona muchas

facilidades que permitan el modelado de la especificación temporal del sistema. Es cierto
que en la entidad tarea se incluyen atributos como frecuencia, que sirve para indicar la
frecuencia de la tarea, y duración para definir cuánto durará la tarea. Además, que la
función de transferencia receive que permite establecer la comunicación entre el sistema y
el exterior, cuando éste último tiene la iniciativa y mantiene la información. Pero, a pesar
de esto, hay algunas cosas que faltarían por modelarse, y es lo que se propone en este
modelo.
Al igual que en CommonKADS, se utiliza el lenguaje CML2 para especificar el

conocimiento, adicionándole las instrucciones necesarias para modelar el conocimiento de
tiempo real, para especificar las relaciones temporales.
• En el ámbito del Conocimiento de Inferencia:
inference-knowledge ::= inference-knowledge Inference-knowledge;

[terminology]
[use: use-construct, …, ]
< inference | knowledge-role | transfer-function > *
end inference-knowledge [ Inference-knowledge ;].
transfer-function ::= transfer-function transfer-function ;

terminology]
type: <provide, receive, obtain, present>
roles:
input: Dynamic-knowledge-role ;
output: Dynamic-knowledge-role ;
end transfer-function transfer-function;
Se utilizará las funciones receive y present para definir la comunicación entre los
agentes (actores, emisores y actuadores) y el SBCTR de forma que pueda reflejarse la
comunicación asíncrona entre ellos, lo cual es común en estos sistemas.
Un ejemplo de esto es:
transfer-function medir-señal;
type: receive
roles:
input: señal-sensor;
output: lista-de-medidas;
end transfer-function transfer-function;
• En el ámbito del Conocimiento de la Tarea hay un cambio importante pues se

introduce la idea de tener TAN de tiempo real, por lo que se propone que cuando se
confirme que el proceso que se quiere modelar tiene restricciones temporales que
afectan su ejecución, entonces debe ser tratado en forma diferente a la que no las
tiene. Así que se propone lo siguiente:
real-time-task ::= real-time-task Real-time-task;

[terminology]
[domain-name : Domain ;]
[goal : “Text” ;]
type: rt-task-type;
[from: real-time-task];
relative-time: Yes | No;
[period: Natural; ]
[deadline: Natural; ]
[wcet: Natural; ]
[real-time-task-before : real-time-task];
[formed-by-others: Yes | No;]
roles :
input: role-description+;
output: role-description+;
end real-time-task [Real-time-task ; ]
rt-task-type ::= periodic | esporadic | aperiodic;
De esta misma forma, se plantea que el método de la tarea permita especificar si

la tarea es de tiempo real o no, de la siguiente forma:
task-method ::= task-method task-method;

[realizes : Task | Real-time-task ;]
task-descomposition
[roles : intermediate : role-description+]
control-structure: control-structure
[assumptions : “Text” ;]
end real-time-task-method [task-method ; ]
rt-task-type ::= periodic | esporadic | aperiodic;
Estos tipos de tarea definen la forma en que ellas llegan al sistema y cómo deben ser
atendidas. Si la tarea es periódica, se espera que cada cierto tiempo – período – llegue o sea
activada. Si la tarea es esporádica entonces el sistema sabe qué hacer cuando llegue, pero
no está esperándola, no sabe si llegará. Si es aperiódica entonces se sabe que llegará pero
no cuándo.
Un ejemplo de la estructura de una tarea de tiempo real es el siguiente:
real-time-task planificador-Acciones;
goal: “ se encarga de planificar las acciones que debe hacer el robot de
acuerdo con los valores emitidos por los sensores y por la situación inicial
del micro mundo. Esta tarea es periódica pues debe realizarse cada cierto
tiempo”.
rt-task-type: periodic;
from: buscar-Objeto;
period: 100; /* milisegundos */
deadline: 8; /* milisegundos */
real-time-task-before: percep-Entorno;
formed-by-others: Yes;
roles :
input: lista-medidas-sensor, mapa-inicial;
output: acción;
end real-time-task planificador-Acciones;
El método de esta tarea no se especifica pues se utiliza el planteado para planificación

en el modelo de plantillas planteadas en [SAA00].
• En el ámbito del Conocimiento del dominio se introducen dos nuevos valores a los
tipos de datos manejados en CommonKADS. Por una lado está el symbol (como fue
propuesto en [Pal99], pero incluyéndolo dentro de los tipos primitivos pues si se
define como un value type sólo estará disponible para ese dominio específico.
Además, definiría un nuevo tipo relacionado con el tiempo para determinar si la

las restricciones temporales están considerando el tiempo como relativo o absoluto. Es
decir, se tendría un absolute-time y un relative-time que representan el tiempo absoluto
determinado por los pulsos de un reloj o el relativo dado por el orden estricto impuesto
en los conjuntos de todas las ocurrencias de las transacciones.
primitive-type ::= number | integer | natural | real | image | string | boolean |

universal | date | text | symbol | relative-time | absolute-time;
• En la estructura de control se debe incluir la llamada de una tarea de tiempo real, de

modo que la función debe replantearse así:
function ::= Task | Real-Time-Task | Inference | transfer-function ;
También se pueden incluir las operaciones propuestas en [Pal99].
Como se puede apreciar, en este modelo se asume el no incluir conceptos específicos

para modelar aspectos referentes a las características específicas de un sistema de tiempo
real, porque se considera que todo ello debe ser detallado en la tarea de tiempo real al nivel
del diseño, no al nivel de análisis que se plantea.
3.6.4.1 Artefactos del modelo de conocimientos
• De este modelo se obtiene toda la especificación del conocimiento de la aplicación

en CML2 y los diagramas de concepto y de control.
• Además, la documentación debe incluir la especificación y el registro del proceso de

adquisición del conocimiento que se llevó a cabo para hacer la especificación de los
diferentes modelos.
• El formulario KM-1diligenciado.
3.6.4.2 Roles en el modelo de conocimientos
El (los) experto(s) del dominio, el (los) usuario(s), el (los) ingeniero(s) del

conocimiento de tiempo real (debe saber CML2) y el gerente del proyecto.
3.6.5 Modelo de comunicaciones

En este modelo se reflejan las transacciones de comunicación entre los diferentes
agentes involucrados en el sistema. Esto se hace en una forma conceptual independiente de
la implementación, como con el modelo de conocimientos. Su objetivo es especificar los
procedimientos de intercambio de información para realizar la transferencia del
conocimiento entre los agentes. Es decir, que en este modelo se especifican las necesidades
y deseos en relación con las interfaces que se tiene con los agentes, así es posible tener una
interfaz con el usuario y una interfaz con un sistema software.
El componente clave de este modelo es la transacción que dice qué objetos de

información son intercambiados entre qué agentes y qué tareas.
Para hacer el modelo de comunicaciones es necesario tener lo siguiente:
• Del modelo de TAN la lista de TAN realizadas por un agente en especial. Para este
modelo importan las tareas hoja o sea las que no se descomponen más, junto con sus
objetos de información de entrada y salida
• Del modelo de conocimientos se requiere el conjunto de funciones de transferencia,

nodos hoja en la estructura de inferencia de la tarea que depende de datos o
resultados de razonamiento para el mundo externo.
• Del modelo de agentes se necesita la descripción de los agentes relevantes, con su

conocimiento, capacidades, responsabilidades y restricciones.
Uno de los inconvenientes que tiene el modelo de comunicaciones en CommonKADS,

es que en caso de que los agentes sean seres humanos no plantea alternativas de modelado
de ese intercambio de conocimiento en el ámbito humano. Además, asume que el SBC está
integrado por diferentes agentes de software, cuando en los demás modelos no hace ese
mismo tratamiento. En caso de que así fuera, entonces habría que tomar como base la
metodología MAS-CommonKADS de [Igl98] y hacer otros planteamientos para tener
agentes de tiempo real.
Teniendo como base el SBCTR, entonces se asume que los agentes son objetos
externos al sistema y que por lo tanto en CommonKADS-RT es importante modelar esa
comunicación, a través del modelo de comunicaciones, de los diagramas de casos de uso y
de los diagramas de protocolos [Fip01a] similares a los diagramas de secuencia.
Este modelo es muy importante, dependiendo de la arquitectura del SBCTR, ya que si

lo que se tiene son dos sistemas, uno de tiempo real y otro basado en el conocimiento, la
comunicación entre ellos es fundamental. Así, el SBC puede ver al STR como un agente
que le provee información para su toma de decisiones y viceversa. Por ello, las
transacciones deberán ser modeladas apropiadamente.
Para efectos de esta tesis, se está hablando de un SBCTR genérico, en donde la parte
central está puesta en el conocimiento, y el tiempo real es información adicional que limita
o restringe el acceso de los datos, el razonamiento y el conocimiento mismo. Por esto, el
modelo de comunicaciones de CommonKADS-RT es básicamente el mismo de
CommonKADS, pero incluyendo los diferentes tipos de agentes que pueden presentarse en
el sistema. Esto implica, que deban especificarse diferentes tipos de transacción
dependiendo de los agentes que participan en la comunicación.
La comunicación entre agentes ha sido tratada muy ampliamente por FIPA

(Foundation for Intelligent Physical Agents) [Fip00], a través de una serie de
especificaciones que representan una colección de estándares que tratan de promover la
interoperación de agentes heterogéneos y de servicios que ellos pueden representar. Se
define la asumpción que los agentes se comunican a un nivel de discurso alto, es decir que
el contenido de los mensajes son sentencias con significado acerca del conocimiento o del
entorno del agente. Los agentes entienden y son capaces de ejecutar algunas acciones y de
realizar actos de comunicación, así ellos pueden pasarse entre sí, mensajes semánticamente
significativos para realizar la TAN o lograr un objetivo específico. Estos actos de
comunicación son codificados en un Lenguaje de Comunicación de Agentes (ACL - Agent
Communication Language) que impone un conjunto mínimo de requerimientos en el
servicio de transporte de mensajes. La estructura de un mensaje es la siguiente:
Tabla 3-5 Estructura de un mensaje según FIPA

Mensaje Nombre del mensaje o identificador
Emisor Nombre del agente que manda el mensaje
Receptor Nombre del agente que recibe el mensaje
Contenido Componente de la comunicación que se refiere a un dominio en un lenguaje ACL
El ACL posibilita la comunicación entre los diversos agentes en una forma que les
permita derivar semánticamente información útil sin requerir un acuerdo a priori sobre el
lenguaje usado en la comunicación [Fip01b]. Esto se logra a través de la combinación de
tres aspectos:
• Un rango de tipos de mensajes,

• Una serie de notaciones en las cuales las expresiones lógicas, acciones y objetos
pueden ser expresados.
• El uso de ontologías referenciadas explícitamente que le permiten al agente
interpretar los identificadores en una comunicación relacionada con una o más
interpretaciones compartidas de esos indicadores.
3.6.5.1 Formularios del modelo de comunicaciones
• CM-1: Descripción de las transacciones del SBCTR
Modelo de Descripción de transacción

Comunicaciones Hoja de Trabajo CM-1
Nombre / Identificador de la Una transacción es definida para cada objeto de información que es
transacción producido (salida) en algunas de las actividades de una TAN o en las
funciones de transferencia del modelo de conocimientos, y que tiene que ser
comunicado a otro agente para utilizarlos en sus propias tareas. El nombre
tiene que reflejar, en una forma entendible por el usuario, lo que la
transacción hace con ese objeto de información. En adición al nombre se
debe dar una breve explicación del propósito de la transacción
Objeto de Información Indicar el objeto de información (núcleo) y entre cuál par de TAN es que va
a ser transmitido
Agentes involucrados Indicar el agente que envía y el agente que recibe el objeto de información
Plan de Comunicación Indicar el plan de comunicación del cual es componente la transacción
Restricciones Especificar los requerimientos y (pre) condiciones que tienen que ser
cumplidas para que la transacción pueda ser llevada a cabo. Entre estas
restricciones se deben incluir las de tipo temporal. A veces también es
útil poner las post condiciones que son asumidas para ser validadas después
de la transacción
Especificación del Las transacciones pueden tener una estructura interna que consiste de varios
intercambio de información mensajes de diferentes tipos, o manejan objetos de información de soporte
adicional tales como puntos de explicación o ayuda. Esto es detallado en la
hoja CM-2. En este punto, solamente una referencia o apuntador necesita ser
dado a una especificación del intercambio de información.
Formulario 3-12 CM-1: Especificación de las transacciones que posibilitan el diálogo
entre dos agentes en el modelo de comunicación
Por lo tanto, es la especificación de los mensajes que se envían / reciben los

agentes.
• CM-2: Especificación del intercambio de información dentro del SBCTR
Modelo de Especificación del intercambio de información

Comunicación Hoja de Trabajo CM-2
Nombre / Identificador de Dar el identificador y nombre de la transacción
la transacción
Agentes involucrados Indicar el agente que envía la información y el que la recibe.
Remitente (agente-1)
Receptor (agente-2)
Ítem de Información Lista de todos los puntos de información que van a ser transmitidos en la
transacción. Esto incluye el objeto de información (“central”) en el cual
transferir es el propósito de la transacción. Sin embargo, éste puede contener
otros puntos de información, que por ejemplo provean una ayuda o una
explicación. Por cada punto de información se describe lo siguiente:
1. Rol. Si este es un objeto central (núcleo) o uno de soporte
2. Forma. La forma sintáctica en la cual es transmitido al otro agente, por
ejemplo, en cadena de datos, texto encadenado, cierto tipo de diagrama,
2D o 3D.
3. Medio. El medio a través del cual es manejado en la interacción agente-
agente, por ejemplo, ventana pop-up, navegación y selección dentro de un
menú, interfaz de comandos, intervención humana.
Especificación de Describir todos los mensajes que forman la transacción. Por cada uno se debe
Mensajes definir:
1. Tipo de comunicación. El tipo de la comunicación del mensaje,
describiendo su intención, según los diferentes patrones de comunicación
y la Tabla 3-5 Estructura de un mensaje según
2. Contenido. La instrucción o proposición contenida en el mensaje.
3. Referencia. En ciertos casos, puede ser útil adicionar una referencia, por
ejemplo, cuál es el modelo del dominio de conocimiento o la capacidad del
agente que se requiere para enviar o procesar el mensaje.
Control sobre los Dar, si es necesario, una especificación del control sobre los mensajes dentro de
mensajes la transacción. Esto puede ser realizado en forma de pseudo código o en un
diagrama de estado - transición, similar a como es especificado el control sobre
transacción dentro del plan de comunicación.
Formulario 3-13 CM-2: Especificación de los mensajes y los puntos de información
que hacen una transacción individual dentro del modelo de comunicación
3.6.5.2 Artefactos del modelo de comunicaciones
• De este modelo se obtiene toda la especificación de la comunicación entre los

diversos agentes del SBCTR. Esta especificación estará basada en la FIPA,
siguiendo incluso los protocolos y los mensajes que ellos sugieren.
• Los formularios CM-1 y CM-2 diligenciados.
3.6.5.3 Roles en el modelo de comunicaciones
Igual que en el anterior, pero se requiere que se tenga mucho conocimiento en los
protocolos y mensajes de FIPA.
3.6.6 Modelo de diseño

El modelo de diseño describe la estructura y los mecanismos de los sistemas basados
en el conocimiento de tiempo real involucrados en el proceso del negocio. Este modelo
forma parte de la fase de diseño y plantea que para tener un diseño completo del sistema
hay que tener una arquitectura, una plataforma y el diseño de la aplicación. [VDS+94] es
una buena guía para el diseñador de un SBC pues en él se encuentra este modelo en forma
completa y a un buen nivel de detalle. Esto, junto con lo que se propone en RT-UML para
las características propias del SBCTR es la base para lo que a continuación se presenta. A
diferencia de lo planteado originalmente en CommonKADS, en donde no se llega a la
construcción del sistema, en CommonKADS-RT si se considera ello pues es necesario tener
el sistema, al menos con la parte crítica construida, para poder realizar las pruebas de
planificabilidad y de garantías del SBCTR.
El proceso de diseño en CommonKADS-RT consiste de unos pasos básicos:

1. Diseño de la arquitectura del SBCTR.
2. Identificación de la plataforma de implementación, es decir el hardware y

software que deben ser usados en el SBCTR.
3. Especificación de los componentes de la arquitectura definida.
4. Especificación de la aplicación dentro de la arquitectura, relacionando los

modelos del análisis –conocimientos y de comunicaciones – con la arquitectura
del SBCTR
Arquitectura del sistema

En cuanto a la arquitectura del sistema, ésta se describe a través de varios elementos:
• Una descomposición del SBCTR en subsistemas y módulos
• Un régimen completo de control por medio del cual los subsistemas interactúan.
Al igual que ocurre en las metodologías más completas, en CommonKADS-RT se

propone una arquitectura especialmente diseñada para un SBCTR, llamada ARTIS
(An Architecture for Real-Time Intelligent Systems) [Gar96], [Bot00].
ARTIS constituye una extensión del modelo blackboard (memoria global estructurada
que contiene objetos del espacio de solución) adaptado para entornos de tiempo real
estricto. En ella se combinan y potencian las ventajas de la inteligencia artificial (su
flexibilidad) y de los sistemas de tiempo real (su predecibilidad). Un sistema ARTIS
debe tener funcionalidades de:
Percepción Cognición Acción
Figura 3-11 Bases de ARTIS
Percepción: adquisición e interpretación de datos de sensores para obtener el

conocimiento de las entidades externas que definen el mundo exterior.
Cognición: razonamiento basado en el conocimiento para evaluar situaciones, resolver

problemas y determinar acciones a adoptar. Por lo tanto, están los componentes de
software que deberían realizar las funciones, los datos, la información y el
conocimiento del dominio.
Acción: se ejecutan las acciones deseadas que influyen sobre las entidades externas.
Estas funcionalidades pueden ser conseguidas basando el diseño del sistema en la

arquitectura global percepción / cálculo / acción, como en muestra en la Figura 3-12.
ENTORNO
Tareas de Tareas Tareas

percepción inteligentes actuadoras
PLANIFICADOR DE TAREAS
Figura 3-12 Arquitectura global de un SBCTR
Donde:
• Las tareas de percepción proporcionan una interfaz de comunicación entre las
entidades externas y el sistema.
• Las tareas inteligentes interpretan los eventos provenientes de las tareas de

percepción y realizan el razonamiento y la resolución de problemas. Estas tareas
calculan acciones físicas que deben ser ejecutadas sobre el entorno exterior.
• Las tareas actuadoras transmiten las soluciones calculadas por las tareas inteligentes
al entorno exterior.
• El planificador de tareas es el responsable de planificar todas las tareas del sistema

garantizando sus restricciones temporales.
Es importante resaltar que para poder adaptar el modelo de blackboard a un entorno de

tiempo real, es necesario conocer el tiempo de ejecución de todas las tareas críticas que
integran el sistema.
La definición de los conceptos básicos de la arquitectura se hace en el Formulario 3-14

DM-1: Descripción de la arquitectura del sistema al que se le han adicionado algunos
conceptos importantes para completar la guía de lo que debe ser la arquitectura y los
detalles deben ser dados por ARTIS.
Plataforma de implementación
Este aspecto del diseño se refiere a la determinación de las bibliotecas que se pueden
utilizar en la construcción del SBCTR, incluyendo las librerías de CommonKADS para las
tareas generales. También es importante elegir la forma para representar el conocimiento,
las interfaces con otro software, el lenguaje de desarrollo, entre otras. El resultado de este
proceso es un modelo de componentes.
Junto a ARTIS, se tiene InSiDE (Integrated Simulation and Development

Environment) un entorno de desarrollo visual para agentes basados en la arquitectura de
agente [JGR+00]. Su objetivo principal es permitir que el usuario especifique un sistema en

términos del modelo propuesto por la arquitectura y obtener una compilación del mismo
para su ejecución sobre RT-Linux. InSide ha sido implementado en JAVA, debido a la
portabilidad entre plataformas que ofrece dicho lenguaje. Con esta herramienta se
especifican las creencias y el conocimiento de resolución, estructurados jerárquicamente,
que forman el modelo de usuario del sistema en desarrollo. Las principales características
que proporciona InSiDE son las siguientes:
• Mecanismos de reutilización: los comportamientos implementados pueden ser

usados por diferentes in-agents.
• Implementa un test de planificabilidad (deadline monotonic schedulability test) para

verificar que el sistema cumplirá las restricciones temporales a las que está sujeto.
• Obtienen una simulación del comportamiento en ejecución del sistema en desarrollo.

La simulación permite, por un lado, observar la evolución del sistema por medio de
un cronograma, y por otro obtener resultados sobre la ejecución del mismo, que
posibilita evaluar diversas características de la especificación (calidad, carga crítica,
etc.)
• Permite incluir conocimiento procedural contenido en bibliotecas externas.
• Permite definir un conjunto de controles visuales que facilita la monitorización del

sistema durante su ejecución.
El objetivo final de InSiDE es facilitarle al usuario una visión de alto nivel de la

arquitectura, permitiendo la abstracción de los detalles de la interfaz de programación.
InSiDE obtiene un modelo ejecutable del sistema a partir de un proceso de traducción de la
información introducida por medio de la interfaz. Este modelo de sistema se compone tanto
de los archivos que implementan la arquitectura como de los archivos generados por
InSiDE que efectúan el sistema en desarrollo. Todo ese conjunto de archivos se compila
desde la herramienta para obtener un módulo ejecutable sobre RT-Linux.
El Formulario 3-15 DM-2: Especificación de las facilidades ofrecidas por y en el

sistema que será implantado permite definir atributos y características adicionales a la
plataforma.
Adicionalmente, se establece una tabla en donde deben identificarse los componentes

que pueden formar el SBCTR.
Tabla 3-6 Especificación de los componentes del SBCTR

Componente Descripción
Librerías Cuáles son los objetos y funciones que proveen servicios para los ejecutables.
Bases de datos y Descripción de las bases de datos y tablas de configuración que se requieren en el
tablas SBCTR
Archivos Determinación de los sistemas de archivos y su organización
Documentos Datos que no son ejecutables y que describen componentes, tales como los
sistemas de ayuda
En forma gráfica estos componentes se pueden definir utilizando la notación de

componentes, presentada en la sección 2.3.4.2 de la página 72.
Un ejemplo es el que a continuación se presenta en la Figura 3-13, relacionado con la

aplicación del robot, presentada en el capítulo 4.
Aplicación ARTIS Robot

Microcontrolador
Componente de la Radio Ethernet Siemens 88C166
interfaz de usuario
Señal cable
Componente de
comunicación Sensores
RS232 C
Batería
VDC
Componente de
planificación
Motor
Componente de VDC
control inteligente
Figura 3-13 Diagrama de componentes principales del robot
Diseño detallado
Al nivel de un programador o usuario especializado para el desarrollo de una
aplicación bajo ARTIS, se tiene la siguiente especificación:
• Conocimiento del dominio: información relacionada con el entorno del sistema, los
datos que necesita para resolver un problema. En términos del modelo de
conocimientos es el conocimiento del dominio. En ARTIS esto se realiza mediante el
concepto de creencia que representa una visión parcial del entorno que incluye tanto
la información que es capaz de percibir directamente como la información que
infiere a partir de los datos deducidos. Esto es así porque no es posible que el sistema
pueda disponer de una visión completa del entorno en el que se encuentra en un
instante determinado, si no que tendrá una visión reducida y en ocasiones, no
actualizada del mismo. Para representar adecuadamente la evolución que él ha
seguido a lo largo del tiempo, así como los posibles estados futuros que se pueden
alcanzar a partir de la situación actual, se distinguen los distintos tipos de
información atendiendo a los siguientes criterios:
− Según su carácter:
o observable. Es la información externa que se adquiere directamente a través
de los sensores.
o no observable. Información deducida a partir de la información de los

sensores en el proceso de razonamiento, cuya validez no se puede contrastar
directamente desde el exterior.
− Según su procedencia:
o de entrada.
o interna
o de salida
− Según su estado temporal:

o actual
o pasada
o futura
El proceso de razonamiento basado en el modelo blackboard temporal establece

que la solución debe construirse en forma incremental, utilizando tanto información
actual como futura. Cualquier paso de razonamiento puede aplicarse en cada una de las
etapas de formación de la solución. De esta forma, la secuencia de construcción de la
solución es dinámica y sigue un modelo de razonamiento oportunista (aplicar el
conocimiento adecuado en el momento oportuno).
• Conocimiento de resolución de problemas: relativo a los métodos para resolver

problemas del dominio, para hacer el razonamiento. En términos de CommonKADS
es el conocimiento de inferencia y conocimiento de la tarea. La topología de ARTIS
se presenta en la siguiente Figura 3-14:
AA
In-agent 1 In-agent 2 ... In-agent n
MKS 1.1 MKS 1.2 ... MKS 1.m ...
KS 1.1.1 KS 1.1.2 ... KS 1.1.p
Figura 3-14 Topología de ARTIS
Donde:
− AA es un agente ARTIS que representa un agente físico, que es autónomo,
reactivo, y tiene continuidad temporal. Está compuesto por una serie de métodos
para el manejo de sensores y actuadores, un módulo de control que se
responsabiliza por la ejecución de tiempo real de cada uno de los componentes
del AA, y un servidor inteligente que se encarga de producir respuesta de muy
buena calidad en caso de que tenga tiempo suficiente para hacer el razonamiento.
− Un agente interno (IA – In-Agent) que es una entidad interna que posee el
conocimiento necesario para solucionar un problema en particular, a distintos
niveles de abstracción y el método que se aplica depende del tiempo que tenga
disponible el sistema para razonar antes de proporcionar una respuesta al entorno.

Este conocimiento puede incorporar técnicas de inteligencia artificial. Un in-
agent se caracteriza por un comportamiento periódico, es una tarea específica y
dispone de un plazo máximo de ejecución, deadline.
− Una fuente de conocimientos múltiple (MKS - A Multiple Knowledge Source) que

implementa el concepto de los algoritmos anytime y multiple methods, dando
diversas soluciones al mismo problema con diferente tiempo de cómputo y
diferente nivel de calidad. Así, se permite acotar el tiempo de cómputo para el
caso peor de las entidades especificadas sin necesidad de, a priori, podar las
funcionalidades de las técnicas de IA utilizadas. Estas técnicas, por su propia
naturaleza, tienen tiempos de cómputo no limitados o poco realistas, pudiendo
utilizar técnicas de IA en la resolución de problemas de tiempo real críticos. Para
poder garantizar su planificabilidad es necesario conocer los tiempos de respuesta
en los peores casos de las entidades en ejecución que los constituyen.
El MKS agrupa varios niveles de fuentes de conocimiento y puede ser

interrumpida en cualquier momento devolviendo la solución del último nivel que
se haya ejecutado en forma completa. Los diferentes niveles de un MKS
resuelven el mismo subproblema pero aportando cada uno de ellos una visión
distinta de esta resolución, bien sea porque se implementan métodos múltiples, o
porque se realizan diferentes refinamientos del mismo método.
− Una fuente de conocimientos (KS - Knowledge Source) representa el

conocimiento (métodos, heurísticas, sistemas basados en reglas o cualquier otra
técnica de IA) básico de resolución de una parte de un problema. El conocimiento
puede ser representado en forma procedural, mediante un lenguaje basado en
reglas o mediante la utilización de otros formalismos de representación del
conocimiento. Es la abstracción mínima dentro de la arquitectura ARTIS. El KS
se puede caracterizar por el tipo de operación que realiza en el sistema, así:
o KS de percepción cuando realiza operaciones de entrada, entonces leerá los

valores de variables observables a través de sensores.
o KS de cognición cuando hace operaciones de razonamiento e inferencia,

operará sobre valores observables, no observables e internos calculando
valores de variables internas, de salida o no observables.
o KS de acción cuando sus operaciones son de salida. Actuará sobre el mundo

mediante actuadores a partir de los valores de las variables de salida
previamente calculadas.
La arquitectura propone un modelo de entidades de alto nivel para especificar un

agente inteligente en tiempo real y un modelo del sistema para definir las entidades de
bajo nivel y las tareas ejecutables.
• Conocimiento de control: conocimiento sobre el conocimiento. Es el conocimiento

de la tarea.
En términos de la topología de ARTIS, las creencias del AA se implementan a través

de un conjunto de frames (conceptos). Los conocimientos básicos de resolución, es decir las
KS, se implementan mediante código C (KS procedural) o mediante un lenguaje de
sistemas basados en reglas como Arlips [ViB97] que cumple con los requisitos mínimos
que se exige para el desarrollo de sistemas basados en reglas predecibles temporalmente, de
forma que se pueda utilizar en entornos de tiempo real. Las KS definidas son incluidas en
entidades complejas (MKS) para implementar así el concepto de algoritmo interrumpible,
bien mediante métodos múltiples o bien mediante refinamientos sucesivos. Los MKS, a su
vez se utilizan para construir las diferentes capas (Percepción, Cognición y Acción) que
constituyen los in-agent. De esta forma, y una vez definidas las características propias de
los in-agents (período de activación, plazo máximo de ejecución, importancia) el
comportamiento del sistema queda completamente especificados.
Como parte de este paso del modelo de diseño se propone el MODELO DE TAREAS
DE TIEMPO REAL que hace parte del diseño detallado del SBCTR, que se presenta en la
sección 3.6.7 más adelante pues es necesario definir la tarea de tiempo real, de bajo nivel.
Por último, para el diseño detallado es importante definir cómo se van a manejar los
eventos internos, los externos, qué tipo de acciones puede hacer el sistema (por ejemplo,
imprimir, leer del teclado, acceder a disco duro). Todo esto dependerá de la aplicación, en
especial si el sistema es crítico o no en el cumplimiento de sus tiempos. Para ello se
propone el Formulario 3-16 DM-3: Lista de chequeo de decisiones en relación con la
especificación de la arquitectura.
Aplicación en la arquitectura
Este aspecto del diseño se relaciona con llevar a cabo los modelos del análisis, en
especial el modelo de conocimientos (las tareas, inferencias, bases de conocimiento) y del
modelo de comunicaciones (las transacciones). Para esto se utiliza el Formulario 3-17 DM-
4: Decisiones del diseño de la aplicación.
Para el SBCTR se debe definir también lo relacionado con el test de planificabilidad

off-line, el análisis de garantías de acuerdo con una política de planificación definida. Este
análisis se hace cuando ya el sistema está construido y terminado. Es obligatorio hacerlo
para las partes críticas con el objetivo de verificar los wcet.
Si el test dice que no se cumplen los tiempos, entonces pueden suceder varias cosas:
• Se ajustan o rebajan las restricciones temporales.
• Se vuelve a la fase del análisis o al comienzo del diseño.

3.6.6.1 Formularios del modelo de diseño
• DM-1: Arquitectura del SBCTR
Modelo de Diseño Arquitectura del Sistema

Hoja de Trabajo DM-1
Nombre de la arquitectura Especificación del nombre de la arquitectura utilizada (si la hay)
Características de la Descripción de los conceptos y características más relevantes de la

arquitectura arquitectura escogida.
Tipo de arquitectura Por ejemplo, ARTIS es una arquitectura blackboard
Tipo de SBCTR Qué tipo de SBCTR se va a construir con el objetivo de definir sus
componentes y módulos.
Especificación de los Número y tipos de procesadores
procesadores
Estructura del Subsistema Hace referencia al diagrama con todos los subsistemas. Puede ser un
modelo cliente – servidor o de máquinas abstractas.
Modelo de Control Caracterización del régimen de control de todo el sistema.
Por ejemplo, orientado a eventos, con control centralizado, modelo de
llamada - retorno.
Descomposición del Hace referencia a los diagramas en los cuales los subsistemas están siendo
subsistema descompuestos. Indica para cada descomposición el paradigma que
soporta la descomposición, por ejemplo, orientado a objetos u orientado a
funciones.
Formulario 3-14 DM-1: Descripción de la arquitectura del sistema
• DM-2: Plataforma de implantación del SBCTR
Modelo de Diseño Plataforma de implantación

Paquete de Software Nombre del paquete
Compatibilidad del software Qué tan compatible es con lo que actualmente se tiene
Sistema operativo El sistema operativo en el que se ejecutará el sistema es muy
importante, pues de él dependerá que se tengan que adicionar
procesos para manejar el tiempo y su cumplimiento.
Hardware potencial Plataforma de hardware en que el paquete se ejecutará
Hardware objetivo Plataforma en que el software se ejecutará
Compatibilidad del hardware Qué tan compatible es con lo que actualmente se tiene
Librería de visualización ¿Hay librería disponible? Facilidades de vistas: actualización
automáticas.
Lenguaje de tipos Tipos Fuerte contra débil. ¿Completamente orientado por objetos?
¿Incluye herencia múltiple?
Representación del Conocimiento ¿Declarativa o procedural? ¿Hay posibilidad de definir conjuntos
de reglas?
Protocolos de interacción Protocolos soportados para interactuar con el mundo exterior:
ODBC, CORBA, ...
Cómo es la comunicación con los Qué tipo de comunicación maneja el SBCTR con su entorno.
dispositivos sensores y actuadores En el caso de que el sistema sea crítico, entonces la
comunicación física será asíncrona, pues el sistema no se
puede quedar esperando por una respuesta.
Flujo de control ¿Protocolo de pasada de mensajes? ¿Múltiples hilos de control?
Soporte de CommonKADS ¿El software provee una arquitectura CommonKADS
implementada? Por ejemplo, ¿a través de un paquete de librerías?
¿Soporta un enlace con una herramienta CASE para el análisis de

CommonKADS, por ejemplo leer descripciones en el modelo de
conocimientos y el modelo de comunicación?
Formulario 3-15 DM-2: Especificación de las facilidades ofrecidas por y en el sistema
que será implantado
• DM-3: Especificación de la arquitectura del SBCTR
Modelo de Diseño Especificación de la Arquitectura

Controlador ¿Cuáles son los mecanismos para el manejo de eventos internos / externos?
¿Concurrencia? ¿Posibles interrupciones? ¿Cómo es el control del usuario frente
a la estrategia de razonamiento?
Cómo es la Tarea de ¿Cuál es la estructura de la tarea de tiempo real? ¿La TTR es crítica? ¿Qué
tiempo real ocurre si no se cumplen las restricciones temporales de la TTR?
Eventos externos e ¿Cómo se manejan los eventos internos del SBCTR?
internos ¿Cómo se manejan los eventos externos?
Métodos para hacer la Especificar la política de planificación de las tareas del SBCTR.
planificación de las
TTR
Determinación de los Para las TTR especificar sus wcet – worst computer execution time
wcet
Rol dinámico Tipos de datos para los roles. Operaciones de acceso / modificación para cada
tipo de datos
Rol estático Definir las operaciones de acceso: ¿Darlo - todo, dar - uno, existe - uno?
Modelo del dominio Decidir acerca de la representación de las instancias de reglas. Definir los
métodos de acceso y de modificación.
Acciones del SBCTR ¿Qué acciones puede hacer el sistema, además de acceder a la memoria y al
procesador? Por ejemplo, ¿es posible que el SBCTR tenga funciones de
lectura del teclado, de impresión, lectura de otros dispositivos, entre otros?
Vistas ¿Interfaz de manipulación directa gráfica estándar? ¿Facilidades especiales
requeridas (por ejemplo, producción de lenguaje natural)? Diferentes interfaces:
usuario final, usuario experto. ¿Provee facilidades de entrenamiento genérico?
Formulario 3-16 DM-3: Lista de chequeo de decisiones en relación con la
especificación de la arquitectura
• DM-4: Diseño de la aplicación del SBCTR
Modelo de Diseño Diseño de la Aplicación

Elemento de la Decisión del Diseño
Arquitectura
Controlador Traducir el control del plan de comunicación mas las transacciones en los
manejadores de eventos
Método de la tarea Formalizar la estructura de control
Inferencia Escribir una especificación de la invocación de un método de inferencia
Roles dinámicos Escoger un tipo de datos para cada rol, restringiéndolos a los provistos por la
arquitectura.
Métodos de inferencia Especificar o seleccionar los métodos de inferencia
Modelo del dominio Traduzca las instancias del modelo del dominio en un formato que los represente y
que esté provisto por la arquitectura
Objetos de la vista Seleccione las vistas apropiadas para el modelo de la aplicación y los objetos de
control
Protocolos de Escoger los métodos o lenguajes de comunicación entre el SBCTR y los

comunicación agentes software.
Formulario 3-17 DM-4: Decisiones del diseño de la aplicación
3.6.6.2 Artefactos del modelo de diseño
Como resultados de este modelo se obtiene la especificación completa del sistema, en

cuanto a su arquitectura, componentes, especificación del hardware y del software, diseño
global y PARTE del diseño detallado, pues falta la parte de las tareas de tiempo real.
Al igual que con los otros modelos, en éste también se produce la documentación que
soporta el proceso realizado e incluso, los planes que se tienen para llevar a cabo la
implantación del sistema en la organización, incluyendo los formularios diligenciados.
3.6.6.3 Roles en el modelo de diseño
El (los) ingeniero(s) del conocimiento, el (los) diseñador(es) del sistema, el

especialista en la arquitectura ARTIS y el del hardware.
3.6.7 Modelo de tareas de tiempo real

El modelo de TTR hace parte de la fase de diseño, en la cual se especifica una solución
particular basada en los modelos del análisis.
Junto con el modelo de diseño, este modelo da la especificación técnica del sistema
basado en el conocimiento de tiempo real en función de su arquitectura, la plataforma de
implantación, los módulos del software y los mecanismos computacionales necesarios para
llevar a cabo las funciones determinadas en los modelos de conocimiento y de
comunicaciones.
En términos de los componentes de un modelo en CommonKADS, los del modelo de

TTR, son los siguientes:
• Bases o razones:
− Debería servir para especificar las características particulares de una tarea de
tiempo real.
− Debería proporcionar las herramientas para modelar las tareas de tiempo real a
través de diagramas apropiados.
− Debería permitir la identificación de las tareas de tiempo real que tienen un

comportamiento específico. Por ejemplo, cuándo las tareas son periódicas o no.
− Debería proporcionar la información que se requiere para llevar a cabo un test de

planificabilidad.
• Contenido del MTTR: El contenido de este modelo está dado por los elementos del
modelo y sus relaciones. Se puede apreciar en la Figura 3-15.
Modelo de
Conocimientos Modelo de
Diseño Agentes
Modelo de
Modelo de detallado Agente
Conocimiento
Diseño
Arquitectura
hace parte implementa

de ejecutada por
implementada en Modelo de
Tarea de Comunicaciones
Modelo de Tiempo Real
TAN implementa
realizada en período Transacción
TAN deadline
wcet
tiene
Es parte de
Tipo TTR Es parte de
Parte_inicial Es parte de Parte_final

Parte_opcional
Figura 3-15 Contenido del Modelo de Tareas de Tiempo Real
• Estados del MTTR:

Los estados de este modelo están dados por las diferentes etapas en que él puede
estar. De esta forma se han identificado los siguientes:
− Empieza con la identificación de los componentes de la TTR. En este estado se

tipifican las partes iniciales, opcionales y finales de la tarea de tiempo real.
− Especificación de las variables temporales de los componentes. Se refiere a la

determinación numérica (cantidad de tiempo) que tienen asociadas cada uno de
los componentes de la tarea.
− Ejecución del test de planificabilidad. Es la ejecución del sistema con el objetivo

de ver el cumplimiento de los tiempos definidos en las TTR.
− Aprobación del test. En caso de que se cumplan las restricciones temporales, que
el plan sea efectivo, entonces se termina este modelo.
• Dependencias del MTTR:

Las dependencias se pueden observar en la figura anterior en donde se expresan
tanto las dependencias entre los componentes del modelo de tareas de tiempo real
como las que se refieren a las relaciones con los demás modelos. Estas dependencias
son las siguientes:
− Realizada en: Establece la relación entre el modelo de tareas de tiempo real y el

modelo de tareas de alto nivel para especificar a qué TAN pertenece la TTR.
− Tiene: Es una relación entre dos componentes del modelo, específicamente entre
la TTR y su tipo, en donde este último establece si la TTR es periódica,
esporádica o aperiódica.
− Es parte de: Es la relación de agregación, en donde se establece que la parte

inicial, la opcional y la final forman parte de la TTR.
− Implementada en: Es una de las relaciones entre el modelo de TTR y el modelo

de diseño, para decir que la TTR se construye en la arquitectura que se ha
definido en modelo de diseño.
− Hace parte de: Es otra de las relaciones con el modelo de diseño, para definir que
el modelo de TTR es parte del modelo de diseño.
− Ejecutada por: Establece la relación entre el modelo de TTR y el modelo de

agentes para referirse al responsable de la TTR.
− Implementa: esta relación está fijada entre el modelo de TTR y el modelo de

comunicaciones y también entre el modelo de TTR y el modelo de conocimientos.
En el primer caso es para expresar la dependencia que hay entre una transacción y
una TTR, la segunda es para relacionar la implementación del conocimiento.
• Criterios de calidad para el MTTR:

Los criterios de calidad para este modelo están dados por el cumplimiento o no de
un estado posible, es decir, es la medida en que se logre alcanzar un estado. Por
ejemplo, si ya se han definido los tiempos y plazos para cada una de las TTR, entonces
se ha cumplido con un estado completo y así se ha definido que se asegura la calidad
en él.
Confirmando lo presentado en el modelo anterior, la fase del diseño puede ser

descompuesta en tres categorías básicas:
• El diseño de la arquitectura, en donde se detalla la estructura del software en

términos de subsistemas, paquetes y tareas.
• El diseño mecánico, incluye el diseño de los mecanismos compuestos de clases que

trabajan juntas para alcanzar un objetivo común.
• El diseño detallado para especificar las estructuras de datos primitivas a un nivel

interno y los algoritmos particulares.
Así, el modelo de TTR integra el diseño de la arquitectura, particularmente en lo que se

refiere a las tareas de tiempo real.
Este modelo es representado como una serie de tareas de tiempo real con una
estructura que permite que varias tareas se relacionen entre sí. Una TTR será definida por
sus restricciones temporales y sigue la estructura de un in-agent, el cual consta de un
componente de percepción, un componente inteligente o cognitivo y un componente de
acción. Estos componentes deben ser ejecutados en este orden y la ejecución de cada uno
debe empezar después de la finalización del componente previo. Además, el in-agent se
caracteriza por tener un comportamiento periódico y dispone de un plazo máximo de
ejecución – deadline – para realizar las acciones que crea más oportunas. La Figura 3-16
presenta esta estructura en forma gráfica.
Componente Componente Componente

percepción cognición acción
Son MKS de Son MKS de Son MKS

percepción razonamiento y actuadores
resolución de
problemas
Figura 3-16 Estructura de la tarea de tiempo real a bajo nivel
Donde, un MKS es una entidad con conocimiento para resolver un problema o

subproblema. Está constituido por una secuencia de niveles, cada uno de los cuales está
definido por una secuencia de fuentes de conocimiento (KS) que contienen el conocimiento
para resolver el problema en una forma diferente o para refinar la solución calculada por un
nivel previo (progressive deeping).
La estructura de una tarea de tiempo real está dada por una parte inicial obligatoria,
una parte opcional (si hay tiempo) y una parte final obligatoria. Así, que pasando lo que es
el in-agent a esta estructura, la TTR queda de la siguiente forma (ver Figura 3-17):
• La parte inicial es obligatoria y contiene las partes críticas de la percepción y la

cognición. Tiene tiempo de cómputo limitado y predecible para el peor caso.
Proporciona una primera solución al problema.
• La parte opcional, como su nombre lo dice es opcional y contiene todas las partes
opcionales de la percepción y la cognición. Su tiempo de cómputo para el peor caso
no es predecible o no puede ser garantizado por una política de planificación por ser
tan grande. Refina la solución inicial o proporciona una solución alternativa.
• La parte final es obligatoria e incluye las acciones expresadas en KS de acción.

Tiene un tiempo de cómputo predecible.
MKS MKS1 MKS2 MKS acción

percepción cognición cognición
KS0 KS0 KS0 KS0

KS1
KS2
Inicial Opcional Final

Obligatoria Obligatoria
KS0 KS1 KS0

KS0 KS2
KS0
TTR
con deadline y wcet
Figura 3-17 Ejemplo de un in-agent
Así, se debe garantizar la planificabilidad de las partes iniciales y finales de cada in-
agent o TTR.
El lenguaje de entidades que se tiene, permite definir el conjunto de entidades del

modelo, que se maneja internamente por el sistema, conformado por lo siguiente:
in-agent à (defagent buscaObj

(period int)
(deadline int)
(importance int)
(perception (lista_llamadas_MKS))
(cognition (lista_llamadas_MKS))
(action (lista_llamadas_KS))
(precedence (lista_precedencias)) )
MKS à (defmks name (lista_tipo_parametros)

(lista_nivel)
(lista_nivel)
...
(type Mandatory | Optional)
(importance int)
(method Multiple | Refinament))
KS à (defks name (lista_tipo_parametros)

(wcet int
(codefile string))
Desde el punto de vista de tiempo real para planificar el sistema, se asume que el in-
agente está formado por un período, un deadline, y un tiempo de cómputo del peor caso
(wcet). Si un in-agent no tiene un plazo máximo de ejecución explícito, se le supone igual
al período. En la planificación del conjunto de tareas resultado de la compilación de los in-
agents se garantizará mediante un análisis off-line del mismo, que la parte obligatoria y
final de todos ellos se ejecutará antes de su plazo máximo de realización, ejecutándose, si es
posible, las partes opcionales de cada tarea en el tiempo re procesador disponible entre la
finalización de la parte obligatoria y el inicio de la parte final. Este tema es muy importante
para todo SBCTR pero queda fuera del alcance de esta investigación, será parte de los
trabajos futuros.
También, como parte del diseño detallado se deben especificar los objetos a escala
individual, es decir que se deben especificar en forma de algoritmos o SBC cada uno de los
KS que forman parte del MKS, incluyendo la definición de todos los atributos de la
aplicación en términos de los tipos primitivos de datos provistos por el lenguaje de
implementación.
3.6.7.1 Formularios del modelo de tareas de tiempo real
• RTT-1: Especificación de las TTR
Para este modelo se ha propuesto un formulario que refleja los componentes de la

TAN y sus características Formulario 3-18 Especificación de las tareas de tiempo real:
La información contenida en este formularios servirá para plantear las pruebas de

planificación, lo cual además puede ser complementado con la utilización de los diagramas
de tiempo concurrentes.
Modelo de tareas Especificación del modelo

de tiempo real Hoja de Trabajo RTT-1
TTR-1 Parte inicial
Parte opcional
Parte final
Período
Deadline
Wcet
TTR-2 Parte inicial
Parte opcional
Parte final
Período
Deadline
Wcet
.
Formulario 3-18 Especificación de las tareas de tiempo real
3.6.7.2 Artefactos del modelo de TTR
Los resultados obtenidos al realizar ese modelo se expresan en el diseño detallado del
sistema, la especificación de las TTR y la determinación de sí se cumple o no el test de
planificabilidad. Igual que en los demás, se tiene la documentación de las actividades
realizadas, de las pruebas y de las incidencias posibles.
3.6.7.3 Roles en el modelo de tareas de tiempo real
Son los mismos que participan en el modelo del diseño.
3.7 Conclusiones de CommonKADS-RT

CommonKADS-RT, es la adecuación de técnicas de desarrollo de sistemas basados en
el conocimiento y de técnicas para el desarrollo de sistemas de tiempo real con el propósito
de facilitar la gestión y la construcción de sistemas basados en el conocimiento de tiempo
real. Son consideraciones metodológicas para el desarrollo de ese tipo de sistemas. Sus
objetivos principales son: Incrementar la calidad del producto final, mejorar la
repetibilidad y predecibilidad del trabajo de desarrollo del SBCTR, y disminuir el esfuerzo
para desarrollar el producto final en el nivel requerido de calidad.
Para ello, CommonKADS-RT incluye lo siguiente:
• Una descripción de las actividades que se llevan a cabo en la construcción de un

SBCTR. Es decir, propone las etapas o fases para llevar a cabo desde el estudio del
problema hasta el diseño de la solución de sistema basado en el conocimiento de
tiempo real.
• Especifica los componentes o artefactos resultantes de dichas actividades.
• Define el orden en el cual éstas deben ser ejecutadas, lo que se conoce como el ciclo
de vida.
• Establece los roles o el perfil de cada uno de los que participa en las diferentes etapas
de desarrollo del proyecto de desarrollo del sistema basado en el conocimiento de
tiempo real.
• Propone una arquitectura robusta para la implementación del SBCTR
• Permite llevar hasta el software del sistema, planteando incluso la realización del test
de planificabilidad.
CommonKADS-RT – Capítulo 4. Validación a través de casos 151
Capítulo 4.
Validación experimental de
CommonKADS-RT a través de casos
4.1 Introducción
En este capítulo se presentan dos escenarios en los que se quiere demostrar la
aplicación de CommonKADS-RT. El primero de ellos es acerca del proceso de la operativa
marítima que se realiza en la terminal de contenedores de la empresa Marítima Valenciana
que atiende el puerto marítimo de la ciudad de Valencia, España. El segundo refleja la
situación de tener un robot móvil navegando por un micro mundo especial.
4.2 Tipos de casos
4.2.1 Escenario de la operativa marítima del Puerto Príncipe Felipe

de Valencia
Este escenario está enmarcado en una empresa real en donde se presentan procesos
importantes que requieren el manejo del conocimiento bajo consideraciones temporales. Es
un caso muy importante por su complejidad, delicadeza y por el impacto que podría tener
una solución basada en conocimiento de tiempo real. Para esta investigación también es
trascendental porque permite aplicar la metodología CommonKADS-RT a un caso de estas
características y que además permite ver que los modelos de la metodología pueden ser
usados para representar propuestas para el futuro, pues en este caso se realizó la fase de
análisis pero no se llegó a la del diseño por decisiones tomadas por una de las gerencias
involucradas en el proceso de actualización y adecuación tecnológica que está viviendo la
compañía en estos momentos. De todos modos, es de gran valor el estudio realizado y
faculta que, con pequeñas actualizaciones, pueda ser utilizado posteriormente cuando se
tengan las condiciones para implantar SBCTR.
4.2.2 Escenario de una aplicación con un robot móvil navegante

Este escenario se ha desarrollado para validar la metodología CommonKADS-RT, la
arquitectura ARTIS y el software de desarrollo InSiDE en un caso especial, que no está
relacionado con un problema específico de una organización, sino que es un problema que
se diseñó específicamente para esta investigación. Para ello se creó un micro mundo en
donde un robot es controlado por un SBCTR que sabe cómo navegar en un mundo cerrado,
puede identificar un objeto por su forma básica y puede moverlo o transportarlo. Este caso,
es una situación particular dado que algunos de los planteamientos de la metodología en la
fase de análisis no será necesario analizarlos. Se incluye también la fase de diseño de la
aplicación que se ha construido para este propósito.
4.3 Terminal de contenedores en el puerto de

Valencia
Desde hace un tiempo se viene desarrollando en forma conjunta, entre la Empresa
Marítima Valenciana y la Universidad Politécnica de Valencia, un proyecto en donde se
han estudiado diferentes áreas de dicha empresa con el fin de plantear soluciones a
problemas específicos o mejoras a través de soluciones informáticas. Es así, como se ha
venido trabajando en dos áreas prioritarias para el buen funcionamiento del Puerto Príncipe
Felipe de Valencia: Las Operaciones Terrestre y las Operaciones Marítimas. En esta última
es que se ha aplicado la metodología CommonKADS-RT con el objetivo de identificar
posibles procesos que pueden mejorarse con la inclusión de un sistema basado en el
conocimiento de tiempo real. Para ello, se han realizado múltiples reuniones con personal
especializado en cada una de las tareas que se realizan en esta unidad y se ha compartido
información pertinente al proceso.
El objetivo de este caso es el siguiente: “Con este análisis pretendemos conocer en forma
detallada el proceso de las Operaciones Marítimas para plantear soluciones informáticas a situaciones
que requieran un uso intensivo de conocimiento bajo restricciones de tiempo”.

Directamente, se presentarán los resultados obtenidos al aplicar cada uno de los
formularios planteados en CommonKADS-RT.
4.3.1.1 OM-1 Identificación en la organización de los problemas y oportunidades

orientados al conocimiento, con el tiempo como factor importante.
El ambiente organizacional no se requiere analizar en detalle porque en este caso

previamente se había definido e identificado el área en donde se presentan los problemas o
en donde se requiere hacer una mejora a los sistemas existentes, siendo ésta la unidad de
Operaciones Marítimas. Es allí en donde se debe realizar el estudio de viabilidad de aplicar
un SBCTR para hacer algunas de sus tareas. Por lo tanto, de este formulario solamente se
presentará la información relacionada con el Contexto de la Organización [BRH00]:
La empresa Marítima Valenciana S.A. forma parte de grupo de empresas Dragrados de

España y se encarga de manejar todo el tránsito de mercancías del Puerto de Valencia. Cuenta
con un equipo humano compuesto por 260 personas, con un alto nivel profesional y su política de
RR.HH. está recogida en los compromisos y valores definidos por su propia plantilla.
Marítima Valenciana S.A. ofrece a sus clientes un servicio integral puerta a puerta de
transporte para sus productos, contando para ello con las tecnologías más avanzadas y con una
estructura de empresa flexible, dinámica, eficiente y con calidad contrastada, donde destaca su
equipo humano altamente cualificado y profesional.
En términos generales las funciones de la empresa giran alrededor de la operación

marítima y la operación terrestre. Para la Operación Marítima se cuenta con un muelle cuya
longitud es de 1500 m, que se ampliará hasta 1900 m y con 9 (+2 en construcción) grúas. Se
trabaja en forma continua al día, 360 días al año. La unidad Operaciones Terrestres opera en un
horario diferente pero también con un rango muy amplio.
Visión:
Ser el mejor Terminal Marítimo del Mediterráneo. Lo cual está trabajando a través de un
proyecto de Calidad en compañía de las autoridades portuarias.
Como el área Operaciones Marítimas es compleja y en ella se realizan diversos

procesos, en donde si no se tiene la información apropiada, real y en el momento preciso, se
puede demorar la atención de un barco, entonces se necesita hacer la caracterización de los
problemas que son intensivos en conocimientos y que manejan especificaciones temporales,
lo que se detallará a través de los demás formularios.
Se han identificado algunas debilidades, muchas oportunidades, diversas fortalezas y

algunas amenazas también. Para efectos de esta memoria, sólo se incluirán las que se
consideran más relevantes:
• Una de las fortalezas que la empresa presenta es que su personal conoce muy bien el
trabajo que realiza, el por qué y para qué de él, dando una visión compartida global,
lo que ha facilitado la identificación de los procesos que deben ser estudiados a
fondo y la obtención de la información y el conocimiento de ello.
• Una de las grandes oportunidades que tiene esta empresa es que está en crecimiento,
con un interés muy fuerte por mejorar y por invertir en tecnologías apropiadas para
cada uno de sus departamentos y unidades.
• Una de sus debilidades es que varios de sus procesos recaen específicamente sobre el
personal, faltando la documentación apropiada o el registro tecnológico de los
procesos y sus conocimientos.
• Una de sus amenazas es que debe competir contra otros puertos que tradicionalmente
han sido mucho más “conocidos” y “grandes”. Esto obviamente también se puede
ver como una oportunidad.
Después de hacer una análisis detallado y de realizar diversas discusiones con expertos
en operaciones marítimas se concluyó que uno de los problemas que se debe solucionar
más prontamente, tiene que ver con el hecho de registrar el conocimiento específico de las
tareas que ellos realizan. Esto evitará su perdida, permitiría que se pueda replicar, transmitir
y generar así, la memoria corporativa de la empresa.
La operativa marítima es una de las actividades más prioritaria dentro de la empresa,

en donde ser realizan procesos complejos, difíciles de determinar como pasos porque
presentan una variedad grande de posibilidades que se pueden dar en una situación
específica, y porque la mayoría de los procesos requieren de un conocimiento que es dado
por la experiencia, por el trabajo del día a día.
El tiempo en el que se realizan las tareas es muy importante porque se quiere que el
barco sea atendido lo más rápido posible para que esté el menor tiempo en el muelle y
porque los índices de productividad están en relación directa con el manejo de los recursos
en función del tiempo, lo que hace que éste sea un concepto relevante. A continuación se
presenta el análisis de la operativa marítima con detenimiento.
4.3.1.2 De OM-2: Descripción de los aspectos de la organización que tienen

impacto en o son afectados por el problema elegido en OM-1
En este documento quedarán consignados los aspectos más relevantes de la operación

marítima de la empresa Marítima Valenciana S.A.
1) Estructura:
La empresa tiene un organigrama en forma jerárquica, que tiende a ser una estructura
plana. Ver Figura 4-1.
Estructura de la Empresa Marítima Valenciana S.A.
Presidencia
Vicepresidencia
Director General
Administración Financiera Recursos Humanos Comercial Tecnologías Explotación

y Servicios Jurídicos Informáticas
Sistemas Análisis y Operaciones Operaciones Mantenimiento

programación Terrestres Marítimas
Operación Planificación
RIBA
Figura 4-1 Organigrama de Marítima Valenciana

Comunicaciones Secuenciación
Como se explicó anteriormente, de esta organización nos centraremos en la parte

relacionada con las Operaciones Marítimas, cuyo objetivo es atender las necesidades de los
barcos que atracan en el Muelle Príncipe Felipe de Valencia.
Organigrama Operaciones Marítimas
Operaciones
Marítimas
Operaciones Planificación
RIBA
Comunicaciones Secuenciación
Figura 4-2 Organigrama de Operaciones Marítimas
Para describir lo que en ella se realiza, se presenta un bosquejo del proceso:
2) Proceso:
El proceso que se realiza en las Operaciones Marítimas está descrito en el documento
PR.09.01 del 15 de abril de 1999. Ver Figura 4-3.
Armador Comunica- Secuencias Operativa

ciones de RIBA
Figura 4-3 Vista general de atención a un buque en el puerto de Valencia
Donde:
Indica la unidad organizacional de las Operaciones Marítimas que está

involucrada en el proceso de atención del barco.
Representa entidades que no pertenecen a la empresa Marítima

Valencia pero que participan en el proceso
Indica el fin del proceso
Indica la dirección en que se lleva a cabo el proceso.
El Armador es el representante de la empresa que maneja el barco. En este

caso está por fuera de los niveles de la empresa Marítima Valenciana.
Especificando más el proceso que se realiza al interior de las Operaciones Marítimas,

entonces se presenta un diagrama de actividades de UML en la Figura 4-4.
Operaciones Operaciones
Marítimas Terrestres
Atención
Scheduling Planificación
Reserv. Espacio
y Preparación
transbordos
Operativa Apoyo
Marítima terrestre
Despacho
Figura 4-4 Diagrama de Actividades de los procesos que se realizan en la

Operaciones Marítimas
Donde:
• Atención se refiere al proceso que se realiza cuando el Armador hace contacto con la
empresa Marítima Valenciana S.A. con el fin de solicitar un servicio de carga o
descarga en el Puerto Príncipe Felipe de Valencia. Por lo tanto, en este proceso se
hace la búsqueda de la información de barco o el registro de la misma en caso de ser
un servicio solicitado por primera vez. Este proceso es llevado a cabo por
Comunicaciones que son los que tienen la relación con el Armador.
• Scheduling se refiere al proceso de la planeación de las actividades de la operativa

marítima y de la asignación de los recursos necesarios para llevar a cabo el plan
definido. Este proceso es llevado a cabo por el Jefe de Planificación.
• Planificación se dedica a la elaboración de las secuencias de carga y descarga de los

barcos, realizado por secuenciación.
• Operativa Marítima se relaciona con todas las actividades y acciones que se llevan a
cabo para cumplir con la carga o descarga del barco. Realizado por las Operaciones
de Riba.
• La reserva del espacio, preparación de transbordos y apoyo terrestre son tareas de

Operaciones Terrestres. Por lo tanto en este análisis no se detallarán. Desde el punto
de vista de las Operaciones Marítimas son importantes cuando se presentan
conflictos al querer compartir recursos del otro, como en el caso de los transtainer.
• Despacho. Registra las incidencias que han ocurrido durante la carga y descarga e
informa al Armador y al siguiente puerto la situación final del barco cuando
abandona el Puerto de Valencia. Es realizada por Comunicaciones y Secuenciación.
3) Personas
a) Empresas relacionadas con el proceso de las Operaciones Marítimas:
− Marítima Valenciana S.A.
− SEVASA (estibadores)
− El ARMADOR
Gráficamente, las relaciones entre estas empresas son las siguientes:
es_proveedor_de
MARÍTIMA ARMADOR
VALENCIANA
Figura 4-5 Relación entre la empresa Marítima Valenciana y el Armador
es_cliente_de
MARÍTIMA SEVASA
VALENCIANA
Figura 4-6 Relación entre la empresa Marítima Valenciana y Sevasa

b) Personas que están directamente involucradas en esta operación:

− El personal de MARÍTIMA VALENCIANA
o Jefe de Operaciones Marítimas
o Jefe de Planificación
o Personal de Comunicaciones.
o Secuenciadores
− El personal de la empresa SEVASA

o Estibadores
o Capataz de mano
o Sobordista (forma parte de las manos y define cuáles contenedores)
o Clasificador (está en la calle haciendo lo mismo que el sobordista)
o Conductor de grúa marítima
o Conductor de transtainer
o Conductores de camión
Para establecer las relaciones específicas entre las personas de la empresa SEVASA y
las áreas de MARÍTIMA VALENCIANA es necesario establecer los roles que integran una
mano:
− 1. Capataz de mano
− 1. Sobordista
− 1. Clasificador
− Varios Estibadores
− Un Conductor de grúa marítima
− Uno o varios Conductores de camión
sirve Operación
Manos RIBA
contrata
Planificación
Figura 4-7 Relación entre las manos de Sevasa y las unidades de Marítima
Valenciana
sirve Operaciones
Conductor
transtainer Marítimas
Figura 4-8 Relación entre el conductor del transtainer y Operaciones Marítimas
− El personal del ARMADOR

o Consignatario
o Planner – es el responsable del armador para realizar una rotación del barco
a lo largo de sus diversas escalas. Se encarga de planificar la carga, descarga
y remociones del barco.
o Agente
o Personal del Barco - Marineros
Gráficamente, las relaciones específicas entre las personas del ARMADOR y las
áreas de MARÍTIMA VALENCIANA, son las siguientes:
Dice QUÉ
Consignatario Planificación
Figura 4-9 Relación entre el consignatario del Armador y la unidad Planificación
Dice CÓMO
Planner Planificación
(Antes de llegar el barco)
Figura 4-10 Relación entre el Planner del Armador y la unidad Planificación
carga o descarga
Agente Secuenciación
Figura 4-11 Relación entre el agente del Armador y la unidad Secuenciación
Capitán solicita_atraque
Puerto
barco
Figura 4-12 Relación del Capitán del barco con Marítima Valenciana
comunica_incidencias
Primer
Comunicaciones
oficial
Figura 4-13 Relación del Primer oficial del barco con Comunicaciones
c) Personas de Soporte:
− Operador de la consola del trunking
d) Unidades de la empresa Marítima Valenciana que participan en el proceso:

− Administración Financiera, hace la facturación. Pero en realidad no tiene que ver
en el proceso de las operaciones marítimas.
− Operaciones Marítimas es la responsable y ejecutora del proceso
− Operaciones Terrestres, presta servicios a las Operaciones Marítimas
− Recursos Humanos y Servicios Jurídicos, hace la solicitud de la información y

contratación de manos, cuando se requiere.
− Tecnología Informática, da el soporte en la parte de sistemas de información y

tecnología informática en especial.
Para resumir la forma como las personas – agentes - se relacionan con los procesos de
las Operaciones Marítimas, se presenta el siguiente diagrama de casos de uso de UML, en
donde se muestran las funciones que dichos agentes realizan.
Solicitud de
servicios
Planeación de Comunicador
Armador
actividades
<<uses>
Asignación de
recursos
<<uses>>
Jefe de
Elaboración
secuencia
Planificación
<<uses>>
Operador de
Riba Carga /
descarga barco
Registro de
Secuenciador
incidencias
Figura 4-14 Diagrama de casos de uso de las operaciones marítimas
4) Recursos:
Para realizar los procesos de las Operaciones Marítimas es necesario contar con
recursos básicos de oficina, ordenadores (que no se detallarán en este documento) y los
siguientes sistemas tecnológicos:
• Trunking. Es un sistema de comunicaciones vía radio que permite la transmisión de

datos y mensajes a todos los terminales, contemplando la conexión a sistemas de
posicionamiento GPS. El control del sistema se realiza a través de una consola donde
un operador analiza y optimiza el uso de la red. El envío de mensajes de estado y
mensajes cortos permitirá integrar este sistema dentro del de gestión automático de la
terminal.
• El Sistema automático de gestión de la terminal (TOS) formado por un sistema

central en donde se encuentran los datos y las aplicaciones que se utilizan para
controlar y automatizar las operaciones dentro de la terminal. La plataforma
tecnológica sobre la que se asienta el sistema central es una pareja de Host AS/400
de última generación. Entre las múltiples aplicaciones, hay cuatro que se destacan:
− Control de puertas: Este sistema controla toda la información que se está

recibiendo desde las puertas de entrada o salida de la terminal y en él se asigna un
identificador (TAC) de radiofrecuencia (RFID) al contenedor para controlar
posteriormente su ubicación.
− Sistema de ubicación automática: Se encarga de buscar y seleccionar la mejor

ubicación para los contenedores que entran en la terminal y de controlar la salida
de los mismos.
− Sistema de optimización de máquina: Este sistema controla que una vez que el
sistema de ubicación automática asigna posición, se establezca la orden a la
máquina que esté mejor ubicada para que de manera óptima, en tiempo y
operativa, se realice el movimiento.
− Consola de operador local: Esta consola permite al controlador o supervisor

realizar un completo seguimiento de las operaciones de la terminal.
El TOS también está formado por un Sistema de Comunicaciones y por un

Sistema Remoto. El de Comunicaciones se encarga de garantizar que todas las
decisiones y órdenes generadas en el sistema central lleguen a todos sus
destinatarios: Operadores Locales, - Puertas- Grúas Transtainers (RTT) - Grúas
Portainer - ReachStacker - Carretillas- Unidades Móviles. La tecnología utilizada
está basada en radio comunicaciones que permiten que el sistema sea actualizado
EN tiempo real. El Sistema Remoto se encarga de recoger la información de los
sensores de posición y lectores de TAG que tienen las grúas transtainer y
portainer para mostrárselas al manipulador de la grúa a la vez que se transmiten a
través del sistema de comunicaciones.
Por último, hay muchas unidades móviles equipadas con un terminal que
acceden directamente a las aplicaciones del sistema central.
• Sistema de vigilancia: La terminal de contenedores cuenta con un amplio despliegue

de cámaras conformando un circuito cerrado de televisión. Mediante múltiples
teclados y monitores, y atendiendo a prioridades según el usuario de origen, se puede
examinar la operativa de la terminal. Así mismo, se pueden realizar grabaciones
múltiples en vídeo de hasta 16 cámaras 24h. al día registrando los posibles incidentes
tanto operativos como de seguridad.
• Sistemas informáticos:
− Cuenta con una moderna infraestructura de comunicaciones de voz y datos para
conectar todas sus oficinas. Se tienen dos AS/400 para gestionar el TOS (Sistema
Operativo de la Terminal) y dos servidores que se encargan de conformar y
ofrecer los servicios propios de la Intranet de Marítima Valenciana (Ofimática, E-
Mail, Internet, Publicación WEB Interna...) Adicionalmente, el sistema permite
establecer la comunicación con los armadores (agentes marítimos y
consignatarios).
− Hay tecnología de intercambio electrónico de documentos (EDI) específica para

el sector del transporte marítimo, lo cual permite hacer una gestión rápida y eficaz
de la información que de manera oficial y desde distintos orígenes llega al Puerto.
− Tienen una página WEB en donde además de tener la información anterior en

forma más detallada, ofrece unos servicios en línea que permiten acceder a
Operaciones Terrestres, Operaciones Marítimas, Planificación, Administración |
Facturación, Consignaciones | Logística, Líneas | Ventas.
− Wincasp: Software que permite extraer del bayplan, el plano de las bodegas
(arrival).
− Ships: Software que se utiliza para generar la secuencia de carga.
5) Conocimiento:
El conocimiento que se necesita para llevar acabo el proceso mencionado
anteriormente, es el siguiente:
• Los criterios de asignación de los barcos, es decir, el conocimiento que se requiere

para autorizar el atraque de un barco y el sitio en el muelle en donde éste debe
atracar.
• Planificación de los recursos que se demandan para llevar a cabo la carga y descarga
del barco. En especial la asignación de las manos y las grúas. Obviamente esto
involucra tener criterios para la optimización de los recursos.
• Planeación de la secuencia de carga y descarga del barco.
• Criterios de optimización de las manos. Para saber cuándo y cuántas manos asignar a
cada uno de los barcos.
• Reglas de manejo de incidencia. Cuando hay información que no coincide con la

situación real de la carga en el barco o en el puerto, entonces se deben tener unas
reglas establecidas para determinar cómo hacer los cambios al plan previamente
definido.
6) Prioridad Asociada:
Para la empresa Marítima Valenciana S.A. es fundamental que se mejore el proceso
que actualmente se tiene en el área de Operaciones Marítimas, con el objetivo de que se
cumpla con los criterios de calidad que allí se han establecido y se reflejen en sus índices de
gestión (estos se presentan más adelante, en el formulario OM-5). Por lo tanto, en este
momento se dirá que la prioridad es la más alta.
7) Restricciones Temporales:
Dentro de los criterios de calidad que se han establecido en esta área, se tienen algunos
que se relacionan directamente con el tiempo.
• En primer lugar, la atención de un barco debe ser lo más rápido posible, una vez él
avise que está listo para atracar. Para la atención del barco (carga y descarga) se
miden unos índices de productividad relacionados con los movimientos (carga,
descarga, en el muelle y en el barco) y el tiempo.
• La atención del barco es algo periódico, pues generalmente los barcos atracan en
períodos fijos, dados por una unidad de días. Esto no es rígido ni estático y puede
variar pues su cumplimiento depende muchas veces de factores externos como el
clima, desperfectos o fallas en el barco, entre otros.
• Los procesos internos de las operaciones marítimas no se deben parar una vez se ha
iniciado el proceso global. Si esto ocurre, entonces se buscan las razones y se
corrigen. Los procesos se deben realizar en un orden específico. Así, que si un
proceso se retraza, afecta a los demás.
• Como el análisis que se realizó de este escenario se hizo a un nivel alto de

abstracción entonces no se identificaron restricciones temporales en forma
cuantitativa, aunque se sabe con certeza, que a más bajo nivel si las hay.
8) Cultura y poder:
• Como se dijo anteriormente en el numeral 1), la empresa Marítima Valenciana sigue
una estructura jerárquica en su organización, lo que se refleja al interior de cada uno
de sus departamentos, por eso en Operaciones Marítimas se tiene una estructura
jerárquica, tal como se vio en la Figura 4-2.
• Un cargo puede ser desempeñado por diferentes personas, dependiendo del trabajo y
del turno realizado. Esto ocasiona que en algunos casos, se tengan visiones e ideas
diferentes para la misma situación.
• La operación marítima es la más prioritaria de todas. Esto sirve para determinar

decisiones o asignación de recursos, en un momento dado.
9) Impacto:
Como ya se manifestó anteriormente, en este proceso intervienen varias unidades de la
Marítima Valenciana: La Dirección Administrativa, Operaciones Terrestres, Operación
Marítima, Recursos Humanos y Servicios Jurídicos. Así, que un cambio en el proceso,

inmediatamente se verá reflejado en los demás. Sería importante estudiar la situación
particular de cada una de las relaciones para observar como se comportarían ante los
cambios propuestos.
10) Conclusiones:
El proceso que se está analizando es uno de los procesos fundamentales de la empresa,
que dan la razón de ser de la misma, por lo que todos los cambios que se hagan en ella se
verán reflejados en el resto de la empresa, especialmente en las unidades que tienen
relación con él. Si se introducen sistemas que optimizan el tiempo, los recursos y la toma de
decisiones dentro del proceso, se tendrán implicaciones importantes para otros procesos que
se realizan en las demás unidades. Esto es bueno si los demás están preparados, pero puede
tener riesgos asociados porque puede ocasionar cuellos de botellas o malestar en las
personas que no participan directamente en el proceso por sentir que los demás si pueden
mejorar su rendimiento.
Se han planteado diversas alternativas para identificar las tareas de alto nivel más
relevantes y para proponer soluciones claves en ellas. Por esto, es importante continuar con
el análisis del modelo de la organización.
4.3.1.3 OM-3 Descripción del proceso en función de las Tareas de Alto Nivel
(TAN) en que está compuesto
El proceso de la Operaciones Marítimas está formado por una o varias Tareas de Alto
Nivel – TAN que se caracterizan porque son completas, de gran alcance, tienen unos
objetivos definidos y unas salidas específicas. Para ello se cuenta con el Formulario 4-1
que facilita su comprensión.
Ident. Nombre Objetivo de Tipo de Ejecutada Importancia de la Intensivo Datos, información y ¿Puede tener ¿Es posible
de la de la la TAN TAN por y en TAN en conoci- conocimiento restricciones introducir un
TAN TAN dónde miento involucrado temporales? sistema informático
en la TAN?
ATN Atención Establecer la ----- Comunica- Es siempre la primera Bajo / nada − Historia del barco Puede ser Si. Para registrar toda la
comunicación ciones en TAN y debe ser − Información nueva dada periódica, pues se información de los
con el Armador Operaciones realizada por el Agente, el Armador sabe cuando llegan barcos. Ya existe un
y con el barco Marítimas apropiadamente y el capitán del barco los servicios. Pero sistema que registra en
para abrir la porque de ella − Habilidades de puede variar una base de datos todos
carpeta del depende la comunicación los datos obtenidos.
servicio información que se − Habilidad de registro de la Habría que revisar si es
obtenga del barco información completo dicho sistema.
SCHE Scheduling Realizar la Planificación Jefe de Es importante porque Alto − Historia del barco No tiene un tiempo Si, para
planeación de y Scheduling Planificación trata de minimizar el − Situación actual fijo, pero la la gestión del atraque
la atención de en tiempo de estancia − Situación prevista del atención debe ser de los barcos, o
los barcos que Operaciones del barco muelle rápida desde el la programación de las
están en el Marítimas − Experiencia en asignación mismo momento actividades y la
muelle y la de barcos al muelle en que el barco asignación de recursos,
asignación de − Criterios de asignación de avisa que está en con el objetivo de hacer
los recursos los barcos Valencia. las listas de carga y
que se requiere − Experiencia en descarga, o
para ello programación de registro de la
actividades y recursos. información
− Optimización de recursos
− Evaluación de riesgos
− Datos o Inf. obtenida del
proceso para hacer la
notificación al barco y al
Agente
PLAN Planifica- Planear la Planificación Jefe de Es importante porque Alto − Historia No tiene. Aunque Si, para
ción secuencia de y Scheduling Planificación trata de optimizar la − Lista de carga y descarga hay unos tiempos Hacer la planificación
carga y Secuencia- forma de hacer la − Disposición por destinos que se miden para de la carga y descarga
descarga de dores en carga y descarga del − Plano del barco ver su ejecución. del barco en función de
contenedores Operaciones barco, en función de − Características del barco Estos se describen la experiencia de los
en o del barco. Marítimas los recursos, de las − Características de la carga más adelante en el secuenciadores y de la
Implica la características del − Experiencia en Planeación formulario OM-5 situación real y actual
asignación barco de actividades de carga y
apropiada de descarga
las manos − Criterios de asignación de
manos, grúas y camiones
OP- Operativa Hacer la carga Asignación Los Es importante porque Medio − Situación actual del barco Debería tener unas Si, para hacer la
MAR Marítima y descarga de operadores son los que se y situación final del barco especificaciones actualización del plano
los de la Riba en encargan − Recursos disponibles temporales del barco y del puerto
contenedores Operaciones directamente de − Experiencia en la dependiendo de los una vez se carguen o
Marítimas ejecutar el plan y las operación marítima criterios de descarguen
secuencias. − Experiencia en transporte calidad. Podrían contenedores
de los diferentes tipos de fijarse en función
contenedores del tipo de carga,
− Conocimiento sobre del número de
manejo de incidencias contenedores,
− Habilidad de solución de manos, camiones y
problemas y toma de grúas.
decisiones
− Habilidad de
comunicación
DES Despacho Consignar toda ----- Comunica- Es muy importante Bajo / nada − Información obtenida No. Si. Un sistema que
la información ciones y para mantener la durante el proceso Debería estar en registre (puede ser el
del proceso, Secuencia- información línea mismo que se utilizó en
incluyendo las ción en completa y la Atención) y
incidencias Operaciones actualizada de todos comunique la situación
Marítimas los servicios final
realizados
Formulario 4-1 OM-3: TAN del Proceso de la atención y prestación de servicios marítimos
CommonKADS-TR – Capítulo 4. Validación a través de casos 168
Continuando con el modelo de la organización para este caso, entonces se debe

presentar la información que se refiere al conocimiento, a su valoración.
4.3.1.4 OM-4 Descripción del componente de conocimiento del modelo de la

organización.
En cuanto al conocimiento que se maneja en el proceso, definido en OM-3 en la

sección conocimiento involucrado, es importante clasificarlo según si se trata de datos
(hechos), información (datos procesados), habilidades o capacidades (propios de una
persona), o conocimiento propio del proceso. Así:
• Datos:
− Historia del barco
− Situación actual del muelle
− Lista de carga y descarga del barco
− Características del barco
− Características de la carga
− Planos del barco en función de la carga
− Plano de carga, identificado por destinos, peso y contenedores especiales
− Situación final – deseada del barco
− Datos nuevos obtenidos del proceso a notificar al barco y al Agente
− El puerto de Valencia es el primero y el último de llegada / salida a / de Europa.
Por lo tanto la lista de remociones es muy importante.
− Recursos disponibles
− Lista de remociones y posiciones.
• Información:
− Información nueva dada por el Agente, el Armador y por el Capitán del barco,
− Situación prevista del muelle
− Requerimientos o especificaciones del Armador
− El orden de atención de los buques es por orden de fondeo y por la maquinaria
que esté disponible para operar.
− La información mínima que se requiere para poder dar la orden de atracar un
barco es si éste está lleno o vacío y el número de movimientos.
− La lista de carga normalmente se tiene 4 horas antes de que el barco llegue.
− El caso ideal es tener el E.T.A. y el plano del barco para hacer la planeación de la
operación. Esto se da en un 80 u 85% de los casos. Los otros casos, 15 o 20%,
nos e conocen con anterioridad..
− El objetivo de la Operativa Marítima es no PARAR el buque.
− La hoja de tiempos
− El plano de carga masterplan (en disquete).
− Se puede decir que periódicamente llegan los servicios. Por ejemplo, se sabe que
los miércoles llega el buque X. Obviamente esto puede tener algunas variaciones.
− El orden de atención de los buques es por orden de fondeo y por la maquinaria
que esté disponible para operar.
• Habilidades o capacidades:
− De comunicación,
− De solución de problemas,
− De toma de decisiones.
− De registro de la información
− De evaluación de riesgos
• Conocimiento propio del proceso:

− En programación de actividades y recursos para la asignación de barcos en el
muelle, (criterios de asignación de barcos y criterios de asignación de manos,
grúas y camiones).
− Planeación de actividades de carga y descarga.
− Optimización de recursos o criterios para optimización
− Manejo de incidencias
− Desarrollo de la operación marítima.
El conocimiento del proceso es lo que se debe analizar en OM-4, tal como se presenta
en el Formulario 4-2.
Modelo de la Organización Capital (Activo) Conocimiento

Hoja de Trabajo OM-4
Activo Poseído por: Usado en ¿Forma correcta? ¿Lugar ¿Calidad correcta?
Conocimiento TAN: correcto?
Criterios de optimización Jefe de Planificación y SCHE: Scheduling - No: son criterios que dependen del Si. El Si, aunque deberían ser
de recursos secuenciadores PLAN: Planificación encargado, aunque hay muchas directrices conocimiento está formalizados.
que se maneja tácitamente. en donde se
- Deberían ser al menos registrados en el realiza la tarea
papel
Planificación Secuenciadores PLAN: Planificación - No: los secuenciadores tienen este Si No: Puede tener muchas
SCHE: Scheduling conocimiento también en su cabeza. restricciones, ser variable, difícil de
- Hay algunas cosas que quedan registradas verificar, es basado en la
en papel experiencia y es muy especializado
- Debería tenerse un sistema informático que
realizara la secuencia
Scheduling Jefe de Planificación SCHE: Scheduling - No: También está en la cabeza del ejecutar Si No: es dependiente de la situación,
PLAN: Planificación de la tarea. basado en la experiencia -
OP-MAR: Operativa - No está registrado en ninguna parte, ni en heurístico, es muy dinámico, es
Marítima forma escrita ni en medio electrónico. incompleto, incierto,
- Es posible tener un sistema informático que y difícil de verificar
realice esto
Manejo de incidencias Jefe de Planificación, ANT: Atención - No hay nada registrado, depende de la Si No, pues es incompleto, heurístico e
secuenciadores, SCHE: Scheduling persona que se enfrente a la situación incluso puede ser incorrecto
operadores de Riba y PLAN: Planificación
comunicadores OP-MAR: Operativa
Marítima
DES: Despacho
Desarrollo de la Operadores de la Riba OP-MAR: Operativa - Si, pues es una TAN que tiene mucha parte Si Si
operativa marítima Marítima operativa aunque depende de la experiencia
Formulario 4-2 OM-4: Descripción del componente de conocimiento del modelo de la organización
4.3.1.5 OM-5: Descripción de los aspectos de la organización que tendrán impacto

en o estarán afectados por la solución escogida del SBCTR.
Después del estudio realizado, y por resolución de la empresa Marítima Valenciana

S.A. se ha decidido que la mayoría de las actividades que se están realizando en el
departamento de Operaciones Marítimas se sigan haciendo de la misma forma, con la
ayuda de las herramientas que se tienen en la actualidad. Tal decisión no está fundamentada
en la viabilidad técnica o viabilidad de este proyecto, sino por establecimiento de prioridad
en los proyectos.
Como se manifestó en OM-4, como es posible introducir diversos sistemas

informáticos en los procesos del departamento, entonces estos se tendrán en cuenta y se
considerarán para otros proyectos que se realizarán en el futuro.
A pesar de esto, y con el objetivo específico de continuar validando la propuesta

metodológica de CommonKADS-RT, la empresa continúa apoyando el trabajo a través del
acceso al personal que puede colaborar con el estudio. Esto es muy importante porque el
informe servirá para planear y valorar proyectos posteriores. El análisis se seguirá
aplicando para el caso de las operaciones marítimas, en particular para la TAN PLAN, pues
es la tarea elegida para estudiar en más profundidad por las siguientes razones:
• Es una de las que más requiere conocimiento.
• Muchas de las cosas que se analizan tiene que ver con la rutina que se ha obtenido o
se ha ido ganando de la experiencia de los secuenciadores.
• No es tan compleja para comenzar con la introducción de esta tecnología en la

empresa, lo cual dependerá mucho en la experiencia del Jefe de Planificación.
Adicionalmente, en este caso un SBCTR se puede plantear como una buena opción
para mejorar la TAN (En el Formulario 4-3 se detalla más esta TAN) porque cumple con
los requisitos mínimos para plantear esta alternativa de solución:
• Intensiva en conocimientos
• Es necesario conservar el conocimiento para generar la memoria organizacional
• Muchas de las actividades que allí se realizan deben cumplir con unos tiempos y
deben ser ejecutadas en un período específico de tiempo.

Estructura una vez se tenga El departamento que directamente está relacionado con la decisión de implantar un SBCTR es el de Operaciones Marítimas, en la unidad Planificación.
el SBCTR
Nombre de la TAN en donde PLAN: Planificación
estará el SBCTR
Esquema del Proceso Ver la Figura 4-15 Vista general del SBCTR para la Planificación en la TAN Planificación y la Figura 4-16 SBCTR ubicado en las actividades de la
automatizado empresa Marítima Valenciana.
Personas que pueden Por una parte están las personas del departamento de Tecnologías Informáticas y por otra, están algunas del departamento de Operaciones Marítimas.
participar en el desarrollo Todas ellas participan en la adquisición del conocimiento. Específicamente estarían los jefes de planificación y los secuenciadores.
del SBCTR El GTI del DSIC participa como creador del estudio y desarrollador de las aplicaciones.
Recursos Para hacer el SBCTR se requiere de:
• C++
• Recursos informáticos. Un ordenador para programar el SBCTR, otro para su ejecución.
• Se requiere de documentación apropiada sobre modelos de secuencia de carga y descarga en puertos similares al de Valencia [Dag89], [HwY99],
[PeD90].
Conocimiento El SBCTR hará la planeación de la secuencia de carga y descarga. Para ello es necesario que los datos se obtengan de la base de datos, que el experto en
planificación describa o explique los criterios que sigue para realizar dicha actividad, y que se determinen los datos que se deben introducir en el
momento de la planificación. El SBCTR hará todo el manejo del conocimiento dado por el experto.
Restricciones de la El SBCTR que se hará no implementará técnicas de planificación dinámica sino que es estática. Es decir, el sistema hará el plan y si hay cambios
aplicación del SBCTR durante el proceso, debe volverse a general el plan. Con esto es suficiente para validar su aplicación en el puerto.
Restricciones Temporales El sistema deberá ayudar a mejorar los índices de productividad que se han definido, de acuerdo con los tiempos que allí se tienen. Por ello, el SBCTR
debe manejar los siguientes tiempos:
− Tiempo de atraque
− Inicio operación
− Tiempo de cada uno de los movimientos para la carga y la descarga
− Último movimiento
− Tiempo de terminación de la operación
− Tiempo de abandono del muelle
Los índices son:
− Tiempo bruto de grúa: Suma de los tiempos gastados por cada una de las grúas que operan en el mismo barco, desde el comienzo de la operación
hasta su final.
− Productividad bruta de grúa: Es la relación entre la totalidad de los movimientos hechos y el tiempo bruto de grúa.
− Tiempo neto de grúa: Suma de los tiempos gastados por cada grúa que opera en el mismo barco, desde el primer movimiento hasta el último
− Productividad neta de grúa: La relación entre la totalidad de movimientos hechos y el tiempo neto de grúa.
− Tiempo neto del neto de grúa: Suma de tiempos gastados por cada grúa operando en el mismo barco, desde el primer movimiento hasta el último,
descontando las interrupciones dentro de esos períodos
− Productividad neta del neto de grúa: La relación entre la totalidad de movimientos hechos y el tiempo neto del neto de grúa.
− Tiempo bruto de atraque: Tiempo desde el momento en que el barco atraca y el momento en que deja el muelle
− Productividad bruta de atraque: La relación entre la totalidad de los movimientos hecho y el tiempo bruto de atraque
− Tiempo neto de atraque: Tiempo desde el momento en que se inicia la operación en el barco hasta que se acaba
− Productividad neta de atraque: La relación ente la totalidad de los movimientos hecho y el tiempo neto de atraque
Cultura y Poder Para lograr que el SBCTR se implante apropiadamente, es necesario mantener a las personas de la sección de Planificación informadas del proceso que
se está llevando a cabo e involucrarlas activamente en él.
Impacto Las personas que se ven afectadas son:
− Jefe de Planificación, en forma indirecta pues las actividades que él realiza podrán apoyarse mucho en el sistema.
− Secuenciadores, en forma directa pues el sistema les ayudará a realizar su labor. No constituyendo en ningún momento una amenaza para su cargo,
todo lo contrario: el sistema será una ayuda para mejora su desempeño y su productividad.
Formulario 4-3 OM-5: Descripción de los aspectos de la organización que tendrán impacto en o estarán afectados por la solución escogida del
SBCTR
Base de
Datos
SBCTR Secuencia
Planificación de carga
Secuenciadores
Figura 4-15 Vista general del SBCTR para la Planificación en la TAN Planificación
En donde: à indica el flujo de los datos.

--> indica el flujo de conocimiento
La secuencia de carga incluye la lista de descarga de operaciones, el
plano de descarga de operaciones, la lista de carga para operaciones y el
plano de carga para operaciones.
Además, se tiene la siguiente figura que muestra como quedaría el sistema integrado
en las Operaciones Marítimas:
Operaciones Operaciones
Marítimas Terrestres
Atención
SBCTR
Scheduling
Planificación
Reserv. Espacio
y Preparación
transbordos
Operativa Apoyo
Marítima terrestre
Despacho
Figura 4-16 SBCTR ubicado en las actividades de la empresa Marítima Valenciana

Por último, se debe diligenciar el formulario OM-6 que es el resultado del estudio de
Viabilidad:
• En cuanto a la viabilidad del negocio y a la del proyecto, sólo se dirá en este

documento, que a pesar de que en este momento no se continuará con el
planteamiento de soluciones informáticas para la operativa marítima, sino para otros
procesos de la empresa, ella está dispuesta en el futuro a asumir los costos de la
inversión y considera que el riesgo es mínimo comparado con los beneficios que se
pueden obtener. (Esto es información confidencial).
• En cuanto a la viabilidad técnica: El estudio técnico de este sistema está

fundamentado en la aplicación de los criterios de filtrado propuestos por presentados
en el anexo 1. Es así, como con base en ellos se determina lo siguiente:
El desarrollo e implantación de un sistema basado en el conocimiento de tiempo

real que sirva de apoyo en la prestación del servicio de planificación de la secuencia
de carga y descarga de contenedores es muy importante para la empresa Marítima
Valenciana, ya que permite mejorar la atención del cliente, optimizando la parte
operativa del negocio. Adicionalmente, este sistema le facilita a la compañía su
posicionamiento en términos de los demás puertos, por tener una tecnología
emergente que le ofrece ventajas estratégicas y competitivas. Todo esto hace que
toda la organización pueda estar interesada por el desarrollo del proyecto.
Una vez el sistema esté operando, se espera que la atención (el tiempo de
estancia en el puerto) de los clientes (barcos) se mejore, dando la posibilidad de
aumentar también, el número de atendidos, lo cual representa un retorno a la
inversión al corto plazo.
En cuanto al conocimiento que se requiere para crear dicho sistema, se tiene lo

siguiente: los ingenieros del conocimiento han estado trabajando desde hace algún
tiempo con información relacionada con el puerto, lo que les permite establecer una
comunicación efectiva con los expertos del dominio. Estos expertos son reconocidos
por su labor como gestores de tecnologías informáticas, planificadores y
programadores de actividades marítimas, tanto en la organización para la cual
trabajan, como por sus clientes. Dentro de la organización se tienen otras personas
que también son expertas en la materia, cada una en un área diferente, por ejemplo
unas son expertas en prestar asesoría para la atención del barco, otras en la
programación del atraque de los barcos, y otras en el manejo de los recursos de
tierra. Por esto, la organización está interesada en mantener todo el conocimiento
relacionado con la prestación de servicio de asesoría de todos sus expertos, para que
así dicho conocimiento esté al alcance de todos sus secuenciadores y de cualquier
Armador, logrando que se tenga una transferencia efectiva del conocimiento. Por lo
tanto, es necesario contar con la tecnología apropiada para guardar o registrar el
conocimiento y que sirva a la vez como medio de enseñanza - aprendizaje.
En relación con esto último, es importante aclarar que la propuesta de este

proyecto incluye el mejoramiento del sistema de información tradicional que maneja
las diferentes bases de datos que se relacionan con el barco y su atención,
posibilitando la actualización de los datos y del conocimiento del sistema, lo que le

permite que sea real en la información que ofrece.
Para determinar si el hacer un SBCTR es una buena alternativa en el caso del

planificador de la secuencia de carga y descarga, se estudió si el desarrollar un
algoritmo era apropiado para ello, dando como resultado que No, por la forma en que
los expertos manejan y expresan el conocimiento, ya que trabajan bajo
incertidumbre, conocimiento incompleto y algunos supuestos. Cada secuencia es
diferente porque depende de la situación del puerto, del tipo de carga, del barco y de
los recursos disponibles. Por esto, se decidió que era un problema factible de
resolver utilizando las técnicas de adquisición, representación y manejo del
conocimiento por medio de la ingeniería del conocimiento. Los expertos expresan su
conocimiento por medio de relaciones similares a las reglas de producción, y
razonan mediante deducciones análogas al racionamiento hacia delante.
En la actualidad el secuenciador hace la secuencia con base en la información

que el armador proporciona, la situación del muelle y los recursos disponibles. En
algunos casos es necesario que este proceso incluya variables relacionadas con el
tiempo que se consume en la toma de decisiones y que implica tiempo de estadía y
servicio de barco, el cual debe ser reducido lo más que se pueda. Además, en algunas
situaciones dependiendo de la carga, también el tiempo debe ser considerado para la
planificación de su atención. En este caso, la tecnología de los sistemas basados en el
conocimiento de tiempo real, ofrece grandes ventajas, ya que permite manejar el
conocimiento bajo especificaciones temporales en una forma sencilla y completa
para el usuario, obviando algunos de los inconvenientes que se presentan
actualmente.
Por último, es importante analizar aspectos relacionados con los recursos que se
requieren tanto para el desarrollo del proyecto como para la implantación del
sistema. Los recursos humanos, como se mencionó anteriormente, están disponibles
y dispuestos a trabajar en el proyecto. La relación entre los expertos y los ingenieros
del conocimiento se ha hecho de la mejor forma posible, facilitando la adquisición
del conocimiento. En cuanto al hardware para desarrollo es de propiedad de la
Universidad Politécnica de Valencia, lo que le permite trabajar en forma flexible en
el proyecto, y la empresa y Marítima Valenciana cuenta con el equipo requerido para
implantar el sistema. La herramienta de desarrollo es un producto resultado de un
proyecto de investigación realizado en el GTI (Grupo de tecnologías Informáticas
del DSIC), además se utilizan lenguajes de uso popular, lo cual simplifica la
instalación y ejecución del sistema.
Por lo tanto, se concluye que técnicamente es posible y justificable desarrollar

un SBCTR para la TAN PLAN, de acuerdo a lo mencionado anteriormente. Además,
es posible llevar a cabo su construcción pues se cuenta con los recursos apropiados,
es posible establecer la comunicación con las bases de datos existentes y los
beneficios que se obtendría podrían darse cuando un Secuenciador lo utilice como
apoyo y se evite la diversidad de criterios.
• Planteamiento de alternativas:
− Es posible que se adicionen sistemas de información para registrar la información

en el momento que se realice cada una de las TAN. Para algunas de ellas, sólo es
necesario que se tenga el software apropiado que permita acceder a la base de
datos y actualizar los datos respectivos, obviamente teniendo preparada la base de
datos para ello. Esta alternativa en parte les mejora el proceso, en relación con la
actualización y vigencia de la información, pero deja de lado todo el registro del
conocimiento, de la experiencia que se requiere para llevar a cabo las TAN.
− Otra alternativa es tomar medidas organizacionales en donde se determine que es

necesario que cada una de las personas involucradas en el proceso debe tener un
registro escrito de su conocimiento, de sus experiencias, de los casos típicos en
los cuales a trabajado, de los casos especiales, etc. Esta solución implica menos
utilización de recursos informáticos, pero exige que se tenga unos modelos
estándar que permitan dicho registro y un entrenamiento para el personal en
técnicas de representación del conocimiento. Esta alternativa es muy buena, pero
no sola. Es decir, debe ser acompañada de otras pues así no mejorará en términos
cualitativos el proceso ni en cuanto al tiempo de realización de las tareas. Pero es
importante de hacer de todas formas.
− Hacer el SBCTR que se ha propuesto. Esta es la mejor alternativa, en cuanto a los

beneficios (como se mostró en los diversos formularios) que se pueden tener de
ella, tanto a mediano como a largo plazo. Incluiría la alternativa anterior. Pero,
implica hacer inversiones en tecnología y en la asignación de tiempo para que las
personas más idóneas participen en el proceso.
• En caso de elegirse la última alternativa, los objetivos de este proyecto y del sistema
serán:
− Desarrollar una herramienta del software computacional que sirva como asistente
en la planificación de la secuencia de carga y descarga del barco, utilizando el
enfoque de un sistema basado en el conocimiento de tiempo real.
− Hacer un sistema basado en el conocimiento de tiempo real que permita hacer la

consulta de un servicio de la carga y descarga del barco de una manera mucho
completa y a tiempo.
− Lograr descentralizar el conocimiento de los secuenciadores y del jefe de

planificación al llevarlo a un sistema que pudiera ser accedido por todos.
− Tener una base de conocimiento del sistema, que además de prestarle la asesoría
al secuenciador, también le servía como herramienta de entrenamiento para las
personas que son novatas en el trabajo de las operaciones marítimas.
• En cuanto a la viabilidad del negocio y a la del proyecto, sólo se dirá en este

documento, que la empresa está dispuesta a asumir los costos de la inversión y
consideran que el riesgo es mínimo comparado con los beneficios que se pueden
obtener. (Esto es información confidencial).
Por lo tanto, se decide que la acción a seguir es: Hacer un prototipo robusto que refleje
el comportamiento de la planificación de la secuencia de carga, el cual servirá para
determinar si luego se debe crecer e incluso, si es posible automatizar de esta misma forma
los procesos en otras áreas.
Como se puede observar, y confirmando lo que se mencionó anteriormente, este es un

ejercicio que no se va a llevar a la práctica en el presente y que sirve más para validar la
investigación que para aprobación de la alta gerencia. De todos modos, en casos reales en
las organizaciones, éste debe ser completado apropiadamente y de una manera estratégica.

Se ha decidido continuar con el análisis conceptual de la TAN Planificación: Esta es
una de las tareas que más requiere conocimiento, ya que muchas de las cosas que se
analizan tiene que ver con la rutina que se ha tenido y por el funcionamiento mismo.
También, cuando las actividades llegan al jefe de operaciones para realizar lo que
previamente se planificó, éste puede variarlo y así de acuerdo con su experiencia,
determinar por ejemplo la llegada de otro barco, las manos que se requieren y la secuencia
de carga. Por lo tanto, en esta tarea también el conocimiento es importante. A continuación
se presentan los formularios que precisan la información de esta TAN.
Para hacer la descripción refinada de las TAN dentro del proceso objetivo, utilizamos
el Formulario 3-8 que se presentó en el capítulo anterior.
Modelo de Tarea de Alto Nivel

Tarea de alto nivel PLAN
Ubicación en la Operaciones Marítimas, específicamente en la unidad Secuenciación.
Organización
Objetivo y valor El objetivo de esta TAN es realizar la secuencia de carga y descarga del barco que
se está atendiendo. Esta TAN es muy importante porque en la medida en que se
haga con mayor precisión y exactitud, el barco estará menos tiempo anclado y la
atención será buena. Adicionalmente, se tendrá un mejor manejo de los recursos
involucrados en la TAN.
Dependencia /Flujo Ver formulario 4-6 TM-1.1: TAN PLANIFICACIÓN (PLAN)
1. TAN predecesoras: La TAN ATN
2. TAN que la siguen: La TAN OP-MAR
3. TAN concurrentes. La TAN SCHE
Objetos manejados 1. Objetos de entrada: La E.T.A., la Carpeta del Barco, el Bayplan
en la TAN 2. Objetos de salida: Secuencia de Carga y Descarga del barco
3. Objetos internos: Bayplan mejorado
Ver figura 4-29. Diagrama de Flujo de la TAN PLAN y la Figura 4-20. Diagrama
de Conceptos de Operaciones Marítimas.
Tiempo y Control 1. Frecuencia, duración
− Para hacer la secuencia de carga y descarga no hay un control de tiempos
definido, pues depende de las características del barco y del número de
contenedores a mover, pero es posible determinar unos rangos, unos tiempos
mínimos y máximos de acuerdo con esas características.
− La secuencia de carga y descarga se hace siempre que haya barco en el
muelle.
2. Tiempo límite
No hay un tiempo límite definido, pues depende de las características del barco y
del número de contenedores a mover. Esto se observa en un nivel de alto de
abstracción, pero en los niveles más bajos, se sabe con un grado de certeza muy
alto, que los procesos involucrarán manejo de restricciones temporales
3. Control - Ver Figura 4-17 Diagrama de Flujo de la TAN PLAN
4. Restricciones:
- La orden para planificar la secuencia de carga y descarga es dada una vez la
TAN ATN tenga la información completa para ese proceso.
- El plan se cumple siempre y cuando se cumplan los tiempos y las actividades
de la TAN.
Agentes Los secuenciadores son los que realizan la secuencia de carga y descarga. Ellos son
los responsables.
Conocimiento y Ver TM-1.1 y las explicaciones siguientes
Habilidades
Recursos El tiempo es un recurso muy importante en estas actividades. Las manos, los
trastainers y las grúas.
Formulario 4-4 TM-1: Descripción refinada de las tareas de alto nivel dentro del
proceso objetivo
E.T.A. Situación del Programar

Gestionar barco y del
Bayplan Carga y
atraque puerto Descarga
Lista carga y
Lista descarga
Secuencia de carga Hacer la

Carpeta y descarga
Registrar secuencia de
actualizada / Incidencias
informació carga y
descarga
Figura 4-17 Diagrama de Flujo de la TAN PLAN
Por cada uno de los conocimientos definidos en OM-4 se hace un formulario TM-2. Es
decir, para los criterios para la asignación de los barcos, la planeación (secuencia de carga y
descarga del barco), el scheduling de recursos (grúas y manos) y actividades, los criterios
de optimización de manos y el manejo de incidencias. Luego de hacer el análisis de la
especificación del conocimiento empleado en la tarea de planificación y sus posibles
cuellos de botella y áreas para mejorar, se concluye lo siguiente:
La forma como se hace la secuencia de carga y descarga de contenedores desde y

hacia el barco es uno de los conocimientos básicos para realizar la planificación de dicha
secuencia. Este conocimiento está relacionado principalmente con el agente jefe de
planificación quien es el responsable de realizar la actividad y tiene la experiencia en

cuando a la planificación de tareas y recursos (dominio más amplio del conocimiento).
La naturaleza de este conocimiento se resume así: es un conocimiento empírico que se

aprende en el que-hacer diario y por lo tanto tienen una buena parte de heurísticas
generadas durante el proceso y que ha ido pasando de persona en persona durante los
últimos años. La experiencia en el manejo del conocimiento y la toma de decisiones en
donde se emplea hacen que sea difícil de reproducir y transmitir pues dependerá mucho de
la casuística. Hay ciertas variables que afectan el proceso, como son el tipo de barco, el tipo
de carga, la empresa del Armador, entre otras. Además, una de sus características es que no
está registrado o no hay un proceso escrito de su utilización, por lo que está básicamente en
la mente de los agentes que realizan la TAN. Es posible que este conocimiento sea
modelado y representado en un sistema informático que refleje técnicas de inteligencia
artificial, a través de un SBCTR para que así sea transferido y no sea tan dependiente del
responsable. Se permitiría tener el conocimiento en el momento oportuno, en la forma
apropiada. Aunque TM-1 es una versión más detallada de OM-3, hemos decidido de todos
modos hacer el análisis de las subtareas de PLAN bajo los criterios de ese formularios,
llamándolo TM-1.1 (ver formulario 4-6) para mostrar una descripción detallada de esa
TAN.
4.3.3 Modelo de agentes

En este sistema hay diferentes tipos de actores:
• Los roles que en MARÍTIMA VALENCIANA tendrá relación directa con la TAN
PLAN o se verán afectados por ella, es decir los actores son:
− Jefe de Operaciones Marítimas
− Jefe de Planificación
− Secuenciadores
− Comunicadores
• Los agentes software son los sistemas informáticos que estarían en relación directa
con el SBCTR con las Bases de datos y los sistemas Wincasp y Ships, mencionados
en la parte de recursos en OM-2. Estos agentes son descritos y trabajados en un
proyecto que actualmente se está realizando para la misma unidad de la empresa. No
se considera relevante para esta investigación, incluir dicha información en ella.
A modo de ejemplo se presenta el formulario AM-1 para uno de los actores

identificados:
Ident. Nombre de Tipo de ¿Ejecutada ¿En dónde? ¿Intensivo Conocimiento ¿Es ¿Puede tener ¿Es posible
de la la TAN TAN por? en conoci- involucrado importante restricciones introducir un
TAN miento? para el temporales? sistema
proceso? informático en la
TAN?
PLAN.. Gestionar Asignación − Personal de Planificación Alto − Historia (puntualidad,..) Este proceso es - Puede definirse el Si. Un sistema que
ATR Atraque planificación − Situación prevista en el muy importante y tipo de tarea según tuviera la imagen
− Jefe de día de llegada requiere que se la frecuencia como del muelle y que de
Planificación (conocimiento que es manejen los se realiza. Podría acuerdo con las
incierto) siguientes llegar a tener un especificaciones y
− Experiencia en asignación criterios: comportamiento restricciones,
de barcos − Dar la atención periódico. permitiera tomar
oportuna a los decisiones EN
buques tiempo real
− Maximizar la
utilización del
muelle
PLAN.. Programación Programación − Jefe de Planificación Alto − Historia (cómo se ha Tiene que ser - Una vez se va a Si. Un scheduler
CyD de carga y Planificación cargado el barco realizada empezar a atender que asignara los
descarga − Personal de anteriormente) apropiadamente. el barco, deberían recursos necesarios,
Marítima − Situación actual (del Los criterios que tenerse unos las manos para
barco, del muelle y del se manejan son: tiempos definidos cargar y descargar
puerto) − La optimización para la carga y la el barco
− Experiencia en de los recursos descarga, de
Programación de − Minimizar el acuerdo con el tipo
actividades y recursos tiempo de carga de barco, de carga,
− Optimización de recursos y descarga el número de
− Evaluación de riesgos contenedores,
entre otros.
PLAN.. Generar Planeación − Personal de Planificación Muy Alto − Experiencia en planeación Tiene que ser - Igual que el No. Debe ser
SEQ secuencia de Planificación de secuencia de realizada anterior realizado
carga contenedores apropiadamente. manualmente.
− Conocimiento o manejo Se tratan los
de prioridades de acuerdo siguientes
con los criterios de la criterios:

TAN y de Marítima − Minimizar el
Valenciana tiempo de carga
y descarga
− Impedir
bloqueos
PLAN.. Registro de (No es − Personal de Planificación No − Datos o Inf. obtenida del Es muy No Si, un sistema de
REG Información intensiva en Planificación proceso para guardar la importante y información que
(guardar) conocimiento) − Personal de información y hacer la también requiere registrar todo en una
Operativa notificación al buque y al que se haga base de datos.
Marítima agente apropiadamente
Formulario 4-5 TM-1.1: TAN PLANIFICACIÓN (PLAN)
Modelo de Agente Agente

Hoja de Trabajo AM-1
Nombre Actor - Jefe de Planificación
Ubicación en la Está ubicado en la Operativa Marítima, siendo uno de los responsables de la atención
Organización oportuna y adecuada de los barcos que cargan y descargan contenedores en el puerto
de Valencia. Haciendo una abstracción de la Figura 4-14 Diagrama de casos de uso
de las operaciones marítimas se tiene descrito lo que se refiere a las actividades
globales realizadas por este actor en el proceso.
Ubicación en la(s) Participa en la TAN SCHE y TAN PLAN.
TAN
Se Comunica con Para esta tarea el agente se comunica con los secuenciadores quienes también
participan en el proceso.
Conocimiento Lista de puntos de conocimiento poseídos por el agente planeación de la secuencia de
carga y descarga del barco. Programación del plan, optimización de los recursos de
manos y grúas
Otras Destrezas Habilidad de comunicación. Debe manejar el enfoque sistémico del proceso, además
de los detalles del mismo. Debe ser un tomador de decisiones bajo presión.
Responsabilidades y El jefe de planificación es el responsable de lo que se realiza en la operativa marítima
Restricciones en relación con la atención del barco. Bajo su responsabilidad están los
comunicadores y los secuenciadores, quienes son los que ejecutan las acciones
planeadas y propuestas por él.
Para su trabajo, las restricciones que se presentan están relacionadas con la capacidad
de atención del puerto, con las variables que hacen que la planeación de la secuencia
de carga y descarga sea muy casuística.
Formulario 4-6 AM-1: Especificación de los Agentes del SBCTR
4.3.4 Modelo de conocimientos

Como primera medida se presenta el diagrama de conceptos realizado para la
operativa marítima en la Figura 4-18.
4.3.4.1 Conocimiento del dominio
El esquema del dominio es el que se presentó en la Figura 4-18, adicionándole los

atributos a cada uno de los conceptos y la definición específica de las relaciones o reglas.
Unos ejemplo de la especificación textual, en particular de los conceptos maquina y
contenedor, y de la relación conducción-maquinaria se presenta a continuación:
CONCEPT maquina;
ATTRIBUTES:
num-maquina: INTEGER;
tipo: STRING;
estado: STRING;
operativa: STRING;
posicion-actual: INTEGER = 0;
END CONCEPT maquina;
barco carpeta
E.T.A.
bodega bayPlan
1..*
secuencia
1..*
posicion
1..*
movimientos maquina conductor
contiene
situado-en
conduccion-
contenedor pos-terminal maquinaria
pila frontal grua
chasis-Term trastainer
planta calle
Figura 4-18 Diagrama de Conceptos – Conocimiento del Dominio - de Operaciones

Marítimas
CONCEPT contenedor;
ATTRIBUTES:
num-boletin: INTEGER;
num-contenedor: STRING;
clase: INTEGER;
estado: STRING;
peso: INTEGER;
rango: STRING;
destino: STRING;
buque: STRING;
temperatura: INTEGER;
alturaMaxima: INTEGER;
END CONCEPT contenedor;
BINARY-RELATION conduccion-maquinaria;
DESCRIPTION:
“Conducción por parte de un conductor de una máquina”;
ARGUMENT-1: conductor;
CARDINALITY; 1;
ARGUMENT-2: maquina;
CARDINALITY; 1;
ATTRIBUTES:
Fecha-conduccion;
END BINARY-RELATION conduccion-maquinaria;
Además, para ampliar la especificación se presentan los diagramas de estados de

algunos de esos conceptos:
descarga carga
Llegada Tránsito Salida
Figura 4-19 Diagrama de estados de Bayplan
Libre
resevar
desbloquear
bloquear liberar
desbloquear
Bloqueada Asignada a
Servicio
bloquear
Figura 4-20 Diagrama de estados de Pila

extraer ocupada
vacía
asignar_ depositar
contenedor
asignada
Figura 4-21 Diagrama de estados de Posición
vacía
asignar
ocupada
extraer
asignada depositar
Figura 4-22 Diagrama de estados de Contenedor
4.3.4.2 Conocimiento de la tarea
Si el conocimiento es sobre la asignación de contenedores a la bodega del barco,

entonces se puede utilizar la plantilla de la tarea asignación definida en [SAA00],
haciéndole sólo los ajustes necesarios para manejar la terminología específica del dominio
del puerto. Ver Tabla 4-1.
Tabla 4-1 Descripción de la tarea asignación

Modelo de Conocimiento TAN ATR
Conocimiento Asignación de barcos
Meta Hacer la asignación entre contenedores y bodega, en donde los
contenedores deben ser cargados a la bodega de un barco específico.
Terminología Objetos: los contenedores
Recursos: las posiciones en las bodegas del barco
Grupo-objetos: todos los contenedores que deben ser cargados en el mismo
barco
Localización: la relación entre contenedores y bodega
Entradas Los datos de los contenedores, los de las bodegas del barco, los
requerimientos específicos y si ya hay contenedores ubicados en el barco,
entonces esas asignaciones.
Salidas Un conjunto de localizaciones o relaciones entre el contenedor y la bodega
del barco.
Especificación de la tarea en TASK asignación;
CML2 ROLES:
INPUT:
objetos: “los contenedores que necesitan ser ubicados en las
bodegas de un barco”;
recursos: “las posiciones en las bodegas en donde se van a
ubicar los contenedores en el barco”;
OUTPUT:
localizaciones: “El conjunto de asignaciones contenedor –
posición de la bodega”;
END TASK asignación;
Especificación del método de TASK-METHOD método-asignación;
la tarea en CML2 REALIZES: asignación;
DESCOMPOSITION:
INFERENCES: select-subset, group, assign;
ROLES:
INTERMEDIATE:
conjunto-contenedores: “subconjunto de los contenedores
con la misma prioridad de asignación”;
grupo-contenedores: “conjunto de contenedores que pueden
conjuntamente ser asignados a la misma bodega del barco”;
recurso: “un recurso que es asignado”;
ubicaciones-actual: “asignaciones contenedor-bodega
actual”;
CONTROL-STRUCTURE:
WHILE NOT EMPTY objetos DO
select-subset (objetos -> conjunto-contenedores);
WHILE NOT EMPTY objetos DO
group (conjunto-contenedores -> grupo-
contenedores);
assign (grupo-contenedores + recursos + ubicaciones-
actual -> recurso);
ubicaciones-actual := < grupo-contenedores, recurso
> ADD ubicaciones-actual;
conjunto-contenedores := conjunto-contenedores
DELETE grupo-contenedores;
recursos := recursos DELETE recurso;
END WHILE
contenedores := contenedores DELETE conjunto-
contenedores;
END WHILE
END TASK-METHOD método-asignación;
También, como se mencionó anteriormente, el conocimiento más importante para

modelar es el de la planeación de la secuencia de carga y descarga del barco que está
atracado en el muelle. Es así, como una vez evaluadas las plantillas propuestas en la
librería, se ha decidido que para esta actividad es necesario hacer tanto la planificación
como el scheduling, teniendo en cuenta que el resultado final será un plan estático del plan
de actividades. Es decir, que el plan que se defina no puede variarse durante el proceso. En
caso de que no se cumplirse en su ejecución porque las condiciones reales han variado,
entonces se vuelve a realizar la tarea completa.
La característica de la tarea de planificación es que en ella las acciones son

parcialmente ordenadas en el tiempo, ver Tabla 4-2. La característica del scheduling es que
en ella se toman unas actividades cuyas secuencias temporales son predefinidas, ver Tabla
4-3
Tabla 4-2 Descripción de la tarea de planificación de carga y descarga del barco

Modelo de Conocimiento TAN SEQ
Conocimiento Planificación de la secuencia de carga y descarga del barco
Meta Hacer la planificación para un barco que está en el puerto, de la secuencia
que se debe seguir para cargarlo y descargarlo, de acuerdo con una serie de
criterios.
Terminología Meta: determinación de la secuencia de carga y descarga del barco. Esta
secuencia debe es el plan que se debe seguir para realizar apropiadamente la
tarea.
Acción: es un elemento del plan básico. Por ejemplo, una acción puede ser
“cargar los contenedores que están ubicados más hacia la izquierda y hacia
afuera de la bodega”.
Plan: Son todas las acciones del plan que se está construyendo. Por ejemplo:
“hacer la carga y la descarga a la vez”.
Entradas La meta que se definió anteriormente
Salidas La secuencia completa de carga y descarga.
Especificación de la tarea en TASK planificación
CML2 ROLES:
INPUT:
requerimientos: “los requisitos que el plan debe cumplir”;
meta: “lo que se quiere lograr”;
OUTPUT:
plan: “El conjunto acciones para llevar a cabo la carga y
descarga del barco”;
END TASK planificación;
Especificación del método de TASK-METHOD método-planificación-idealizado;
la tarea en CML2 REALIZES: planificación;
DESCOMPOSITION:
INFERENCES: operationalize, generate, select-subject, sort;
ROLES:
INTERMEDIATE:
requerimientos-críticos: “requisitos que tienen que ser
cumplido”;
requerimientos-no-críticos: “requerimientos que actúan como
preferencias”;
planes-posibles: “todos los planes que pueden ser posibles de
tener”;
planes-válido: “todos los planes que son consistentes con las
restricciones”;
CONTROL-STRUCTURE:
operationalize (requerimientos -> requerimientos-críticos +
requerimientos-no-críticos;
generate (requerimientos + meta -> planes-posibles);
select-subject (planes-posibles + requerimientos-críticos ->
planes-válidos);
sort (planes-válidos + requerimientos-no-críticos -> plan);
END TASK-METHOD método-planificación-idealizado;
Tabla 4-3 Descripción de la tarea Scheduling para realizar la secuencia de carga y

descarga del barco
Modelo de Conocimiento TAN CyD
Conocimiento Scheduling para la secuencia de carga y descarga
Meta Hacer la programación de las actividades del plan de acuerdo con los
recursos disponibles y el tiempo
Terminología Trabajo: secuencia temporal de unidades.
Unidad: una actividad para ser ejecutada en o con un recurso.
Recurso: el medio que puede satisfacer la demanda de la Unidad.
Restricción: una condición restrictiva en la relación entre unidades y

recursos.
Entradas Los trabajos formados por las unidades
Salidas La relación entre las unidades y los recursos, en la cual todos los tiempos de
inicio y fin de las unidades, son determinados.
Especificación de la tarea en TASK scheduling;
CML2 ROLES:
INPUT:
trabajos: “actividades que necesitan ser programadas”;
OUTPUT:
programa: “actividades asignadas con el tiempo asociado”;
END TASK scheduling;
Especificación del método de TASK-METHOD temporal-dispatching;
la tarea en CML2 REALIZES: scheduling;
DESCOMPOSITION:
INFERENCES: specify, select, assign, modify, verify;
ROLES:
INTERMEDIATE:
unidad-candidata: “actividad seleccionada para la siguiente
asignación”;
recurso-objetivo: “recurso seleccionado para la siguiente
asignación”;
valor-de-verdad: “booleano que indica el resultado de la
verificación”;
CONTROL-STRUCTURE:
specify (trabajos-> programa);
WHILE HAS-SOLUTION select (programa -> unidad-
candidata) DO
select (unidad-candidata + programa -> recurso-
objetivo);
assign (unidad-candidata + recurso-objetivo ->
programa);
verify (programa -> valor-de-verdad);
IF valor-de-verdad == false
THEN modify (programa -> programa);
END IF
END WHILE
END TASK-METHOD temporal-dispatching;
Estas TAN requieren que se ejecuten si el sistema tiene tiempo para cumplir con los
plazos que se han definido, así que el manejo de las restricciones temporales será hecho por
el controlador del SBCTR.
Los modelo de comunicaciones, diseño y tareas de tiempo real no se han construido

porque se considera que como el SBCTR no se desarrollará por el momento, entonces no
sería adecuado. Estos quedarán pendientes para cuando se retome el proyecto.
Este caso, como se dijo en su introducción, ha servido para mostrar los modelos de la
fase de análisis, los cuales se han presentado en detalle. Lo importante de esto, es mostrar
que la metodología CommonKADS-RT es una herramienta muy completa para realizar el
estudio de un problema, la formalización del mismo y de su solución. Es una buena
herramienta gerencial de toma de decisiones.
Con esto se termina el análisis de este escenario. Las conclusiones obtenidas de él se

encuentran en la parte final de este mismo capítulo.
4.4 Robot
Como ya se dijo anteriormente, el problema que vamos a resolver con el Robot no está
ubicado en ningún contexto organizacional, por lo que se obviarán muchos de los
planteamientos del modelo de la organización, en especial aquellos puntos que se refieren
al estudio de aspectos específicos de la empresa.
El problema ya está planteado, se conocen los procesos a modelar, y para propósitos

de validar la metodología es una necesidad la construcción de la aplicación. Todo esto se
puede considerar como precondiciones del proceso que facilitan el análisis de la solución.
En cuanto a la fase de análisis se incluye el modelo de la organización, el de TAN, el

de conocimientos. No se presentan los modelos de agentes y de comunicación porque para
esta situación no hay un agente en especial que sea quien realiza la TAN. En el momento en
que el sistema esté operando, el único que tendrá interacción con él es el usuario
programador que se encarga de encenderlo, ubicarlo en una posición específica y apagarlo.
Aunque los sensores pueden tomarse como agentes software, si se trataran como externos al
sistema, en este caso se han considerado como parte de él. Por ello también, es que no hay
comunicación entre agentes en el desarrollo de una TAN.
De la fase de diseño, se incluyen algunos apartes del diseño global, del detallado y se
presentan los resultados de una simulación que se hizo para este caso.
A continuación entonces, se comienza con la definición del problema, es decir, de la

situación inicial.
Este es un caso especial en donde se quiere mostrar que la metodología

CommonKADS-TR no se aplica solamente a casos basados en el conocimiento
relacionados con problemas específicos de una organización, sino que también sirve para
modelar situación en donde se requiera tener un comportamiento inteligente pero aislado de
un sistema organizacional específico. Por lo tanto, la especificación de los modelos de
CommonKADS-TR varía en que algunas cosas, pues no se tiene o no se requiere, la
información que se necesita en algunos de los formularios, en especial en el modelo de la
organización.

Condiciones iniciales:
El robot está ubicado en un cuarto cerrado, micro mundo, que está delimitado por unas
paredes que lo cierran. Cada pared tiene un hueco con una forma geométrica básica
(rectángulo, triángulo, semi-círculo). El robot se encuentra situado en una posición inicial
fija y conocida. Ese entorno es también conocido para él. También, hay una serie de objetos
con formas geométricas. En el cuarto, uno de los objetos está en algún lugar predefinido,
establecido al azar. Dicho objeto debe ser encontrado por el robot, identificado y
desplazado a un lugar en una de las paredes, el cual debe coincidir con su forma física. Es
decir, el rectángulo debe ser guardado en la pared en donde se encuentre el hueco en forma
de rectángulo, y así para cada una de las formas definidas.
Objetivo:
Dado un mundo cerrado que contiene figuras geométricas básicas y que sus paredes
tienen incrustaciones también de forma geométrica, se requiere construir un sistema en el
que el robot pueda encontrar cada una de las piezas del mundo, identificarlas y ubicarlas en
su lugar respectivo (un proceso de reconocimiento y clasificación o asignación de formas).
Las formas básicas son: el rectángulo, el triángulo y el semi-círculo. Ver figura 4-1.
Robot
Formas básicas
Figura 4-23 Un micro mundo posible para que el robot navegue
Proceso a realizar:
Dadas las características de este robot se debe desarrollar un sistema que pueda
cumplir con el objetivo definido. Es así como llega a un nivel más detallado en el análisis
del problema:
El proceso en pasos está dado por la siguiente secuencia:
• Inicialmente se debe activar el robot y hacer un chequeo de su estado a través de la

lectura de sus sensores y de su batería. Este procedimiento ya viene predefinido en el
robot.
• Una vez el robot está listo, debe comenzar a buscar el objeto que se encuentra en el
micro mundo. Para esto debe hacer una serie de tareas que más adelante se definirán.
• Luego de hallar el objeto, el robot debe identificarlo de acuerdo con las formas que
él reconoce.
• También, debe planear la forma como debe moverlo o desplazarlo por el micro
mundo para ubicarlo en la pared que le corresponde. Esto último lo sabe porque en
cada una de las paredes del micro mundo hay un cajón o hueco predeterminado con
una forma de figura específica. Para facilidad de la prueba, se ha definido que
inicialmente son cuatro paredes, el hueco estará siempre en la misma pared (definida
como parte del estado inicial del micro mundo) Además, hay un solo hueco en la
pared y debe ser diferente de las demás.
• Posteriormente, el robot debe mover el objeto hasta llegar al objetivo final. Es decir,
hasta que introduzca el objeto en el hueco que le corresponde. En ese momento, el
proceso se da por terminado con éxito.
En forma gráfica, el proceso completo se representa en la Figura 4-24.
Activar Buscar Identificar Mover

robot objeto objeto objeto
Administrador Fin Proceso
Figura 4-24 Proceso que debe realizar el robot para cumplir con el objetivo final
Como se puede observar, en este proceso sólo interviene el actor humano para definir
las condiciones iniciales del micro mundo o para iniciar la ejecución del sistema. Pero,
durante el desarrollo de la tarea, es el robot autónomo en su realización.
Adicionalmente, este proceso se puede ver como una TAN que empieza con la puesta
en marcha del robot y que termina con el objeto ubicado en su sitio correspondiente.
También esta TAN puede ser divida en otras que permiten estructurar el proceso en una
forma más detallada con el fin de conocer a fondo cuáles son las actividades que el robot
debe realizar. En el formulario OM-3 se puede observar la especificación de las TAN, de
acuerdo con lo planteado en la metodología CommonKADS-TR.
El comportamiento global del robot ha sido modelado en un conjunto de tareas de alto

nivel. Así, el proceso podría ser considerado como una TAN que ha sido dividida para
mejorar su estructura y conocer cada detalle acerca de las actividades realizadas por el
robot. Con el formulario OM-3 (Descripción del proceso a través de las tareas de alto
nivel), se pueden observar la especificación de dichas TAN.
Es importante resaltar que para este caso particular, no se ha considerado necesario

definir dos aspectos que se proponen en la metodología para este formulario: ¿Ejecutada
por y en dónde? ¿Es posible introducir un sistema informático en la TAN?
Esto es porque el único agente que interactúa con el sistema es el usuario o

programador que se encarga de manejarlo. De resto, el conocimiento del sistema se ha
obtenido de personas (los agentes que proporcionaron el conocimiento del proceso a
realizar por el robot y de su manejo) expertas en el tema de la robótica, pero que para
efectos del sistema final no tendrá ninguna relación.
Ident. Nombre Objetivo de la Tipo de TAN Importancia de ¿Es intensiva en Conocimiento ¿Puede tener
TAN TAN TAN la TAN para el conocimientos? involucrado restricciones
proceso temporales?
Config Configuración Establecer las Es importante pero Nada No
condiciones del no requiere de
micro mundo conocimientos
ActRobot Activación robot Protocolo de Igual que la Nada Si. El robot maneja unos
inicio, verificación anterior tiempos para revisar su
del robot batería, los sensores y los
motores. Es un tiempo fijo
BuscaObj Búsqueda objeto Encontrar el objeto Planeación Es fundamental Alto Planificación de acciones, Si. Hay tareas que serán
que debe reconocer Scheduling para planificar las interpretación del micro periódicas, que tendrán unos
y trasladar Monitorización acciones y asignar mundo, verificación de la deadlines y también un wcet
los tiempos trayectoria
IdObj Identificación Identificar el Clasificación La clave es la Alto Conocimiento de formas Igual que la anterior
objeto objeto encontrado diferenciación de objetos
entre las diferentes trigonométricos,
figuras. planeación de trayectoria,
interpretación,
verificación.
MovObj Movimiento Trasladar el objeto Configuración Es necesario tener Alto Identificación de la pared Igual que la anterior
objeto hasta el sitio en Planeación un planeador objetivo, planificación de
donde debe ser Scheduling la trayectoria, cómo
guardado Monitorización mover el objeto.
Formulario 4-7 Descripción del proceso en función de las TAN que lo componen
Además, como no se está analizando la solución informática a un problema existente,

bien sea manual o no, entonces no es posible responder la segunda pregunta, pues la
respuesta es conocida, ya que es un hecho la construcción del sistema.

Este modelo describe los procesos asignados al sistema y que se relacionan con la
organización.
La TAN BuscaObj tiene que incluir actividades con restricciones temporales para
controlar algunas de las acciones del robot. Por ejemplo, dentro de esta tarea es necesario
hacer un plan de las acciones a realizar por el robot, de tal forma que se define una subtarea
llamada PlanAcción con un período de 100 milisegundos, para significar que esta TAN
tiene que ser repetida o realizada cada 100 milisegundos. Lo mismo sucede con leerSensor,
una tarea hoja, que tiene definido como tiempo de ejecución para el peor de los casos
(Worst Computer Execution Time – wcet) es 2 milisegundos. Esto se detallará en el modelo
del conocimiento, más adelante.
Percepción Planificar Ejecución

del entorno acción de la acción
Figura 4-25 Detalle de las actividades de la TAN 2 - Buscar Objeto
Y, si la TAN es descrita o dividida en más tareas es necesario diligenciar esto de

nuevo este formulario. Por ejemplo la tarea EjecAcción es posible dividirla en leerSensor
VeriObjetivo y EjecComando, y así pueden surgir más TAN o TTR.
4.4.3 Modelo de conocimiento

Este modelo muestra el conocimiento usado por el sistema para solucionar sus TAN,
incluyendo las especificaciones de TR.
A través del Diagrama de Conceptos se presenta el esquema del dominio. Ver Figura
4-26.
Un ejemplo de especificación textual del concepto robot y de la relación con el

planificador se presenta a continuación:
Esto es porque el único agente que interactúa con el sistema es el usuario o

programador que se encarga de manejarlo. De resto, el conocimiento del sistema se ha
obtenido de personas (los agentes que proporcionaron el conocimiento del proceso a
realizar por el robot y de su manejo) expertas en el tema de la robótica, pero que para
efectos del sistema final no tendrá ninguna relación.
Además, como no se está analizando la solución informática a un problema existente,

bien sea manual o no, entonces no es posible responder la segunda pregunta, pues la
respuesta es conocida, ya que es un hecho la construcción del sistema.
posición
batería
sensor robot 1 2 motor

1..16
ubicado-en
sonido bumper planificador
mundo
plan-acción
formas
plan-búsqueda plan-traslado
rectángulo
plan-identif
triángulo
círculo
Figura 4-26 Diagrama de Conceptos para el sistema del robot móvil en el micro
mundo
A continuación se presenta uno de estos conceptos:
CONCEPT robot;
ATTRIBUTES:
pos: posición;
bump: bumper;
estado: valor-estado;
vel_derecha: INTEGER;
vel_izq: INTEGER;
sonar_frontal: sonar;
sonar_lateral: sonar;
estado_serial: INTEGER
END CONCEPT robot;
VALUE-TYPE valor-estado;
TYPE NOMINAL:
VALUE-LIST: {apagado, encendido};
END VALUE-TYPE valor-estado;
En cuanto al conocimiento de las tareas, el planificador se puede apreciar a través de

una máquina de estados de la siguiente forma:
no-encuentra- encuentra-objeto
objeto Buscando Reconociendo
objeto forma-desconocida objeto
siguiente-objeto Desplazando objeto-reconocido

objeto
Figura 4-27 Diagrama de transición de estados del Planificador
No-Detectado Objeto-
Detecta
planificando O.K.
planificando
siguiente
siguiente
acción
detectado acción
acción a ejecutar acción a ejecutar

acción
(mover x,y) (giro α) fin giro bump: (mover _,_) (giro α)
completa
bumper;
desplazando desplazando
Figura 4-28 Diagrama de transición de estados del PlanAcción

Adicionalmente, se concluye que al nivel abstracto del nivel del conocimiento, la TAN
de planificación se puede modelar como lo proponen [SAA+00] en los templates
knowledge model. El tratamiento que se haga en el diseño, depende tanto de la arquitectura,
como de los algoritmos de planificación que se estén manejando para garantizar las
restricciones temporales.
La relación entre el robot y el planificador se define a través del siguiente diagrama de

secuencia, en donde las unidades de tiempo están dadas por un tiempo absoluto dado por el
reloj del sistema.
Robot Planificador
Robot en el
estado inicial chequeo
20 segs
envío estado actual / datos
Robot listo
100 ms
Plan-
acciones
Ejecuta acción 1. acción
solicitud de datos
envío estado actual / datos
fin acción
Plan-
acciones
n. acción
Figura 4-29 Diagrama de secuencia entre el concepto Robot y el Planificador
4.4.4 Modelo de diseño

Características del Robot:
El Robot es un Pioneer 2 Mobile Robot modelo DX. Es un robot móvil de cuatro
ruedas que contiene todos los componentes básicos para la sensorización y navegación en
un entorno real, incluyendo la batería de potencia, los motores de control y de las ruedas,
los decodificadores de posición y velocidad, y un conjunto de sonares y bumpers
integrados. Todos los componentes son controlados por un microprocesador Siemens

88C166 que viene con una memoria ROM programable de 32K como parte del procesador
y con una memoria adicional RAM de 32K, y por un software servidor del robot móvil.
Tiene una variedad de puertos de expansión para la entrada y salida, que incluye: un
bus de entrada / salida direccionable para máximo 16 dispositivos, dos puertos seriales RS-
232C, ocho puertos digitales de entrada y salida, cinco puertos A/D y controlador PSU. En
detalle, el Hardware es el siguiente:
• Sonares: El robot contiene 16 sonares, 8 delanteros y 8 traseros, distribuidos en dos

vectores que proporcionan información sobre la detección de objetos. Los sonares se
activan cada 25 hz. (40 ms por sonar y por vector) y la sensibilidad varía desde 10
cm hasta más de 5 m. El mecanismo de activación de los sonares puede ser
controlado por software. Por defecto la secuencia de activación es de izquierda a
derecha para el vector delantero y de derecha a izquierda para el vector trasero.
• Baterías: El Pioneer DX puede contener hasta 3 baterías de 12 V, que suministran la

potencia necesaria para los distintos componentes y accesorios. La duración de una
batería depende de la actividad del robot, variando de 4 a 8 horas para una actividad
normal. Las baterías son muy importantes para conseguir la balanza del robot. En
general, se aconseja operar con 3 baterías; si únicamente se trabaja con una, es
conveniente colocarla en el centro.
• Componentes electrónicos: El microcontrolador, un controlador de motores, dos

controladores de los sonares, uno por cada vector.
Aplicación ARTIS Robot

Microcontrolador
Componente de la Radio Ethernet Siemens 88C166
interfaz de usuario
Señal cable
Componente de
comunicación Sensores
RS232 C
Batería
VDC
Componente de
planificación
Motor
Componente de VDC
control inteligente
Figura 4-30 Diagrama de componentes principales del robot
El software que el robot tiene es:

• El sistema operativo se llama P2OS. Este sistema es común a toda la familia de

robots Pioneer que utiliza la arquitectura cliente / servidor. El servidor se encarga de
gestionar los detalles de bajo nivel del robot, incluyendo el control de los motores, la
activación de los sonares y la decodificación de la posición y de la velocidad. Así,
las aplicaciones de alto nivel no requieren especificar muchos detalles internos del
robot. El P2OS se comunica con la aplicación cliente utilizando dos protocolos
especiales de paquetes, llamado de paquetes de comando del cliente al servidor y,
paquetes de información del servidor del servidor al cliente. Ambos están formados
por un conjunto de bits, agrupados en 4 elementos principales: cabecera (2 bytes),
byte count (1 byte), bloque de datos del cliente o del servidor (N bytes) y checksum
(2 bytes).
El formato que se requiere para el manejo de la información es el siguiente:
• Información enviada:
Tanto para establecer la comunicación con el servidor, como para controlar el

comportamiento del robot, el cliente debe enviar paquetes de comando, al menos cada 2
segundos. Estos paquetes tienen longitud variable, dependiendo del tipo de comando
enviado.
− Cabecera (2 bytes): permite la sincronización del servidor y el cliente. Los valores

son: 0xFA y 0xFB.
− Byte Count (1 byte): indica el número de bytes que forman el paquete, cuyo
tamaño es variable (depende del tipo de comando enviado).
− Número de comando (1 byte): cada comando tiene asignado un número.
− Tipo de argumento (1 byte): tipo del argumento que requiere el comando (entero
positivo, entero negativo, string).
− Argumento (n bytes): valor del argumento del comando (entero o string).
− Checksum (2 bytes): utilizado por el servidor para saber si la trama recibida es

correcta.
• Información recibida:
Como se ha comentado anteriormente, una vez la conexión se ha establecido, el

servidor envía información al cliente acerca del estado del robot cada 100 ms. El paquete
recibido consta de la siguiente información:
− Cabecera (2 bytes): esta información está presente en la mayoría de los paquetes

que recibe cualquier robot, ya que permite la sincronización del cliente con el
servidor. En el caso del robot Pioneer, la cabecera es 0xFA y 0xFB.
− Byte Count (1 byte): indica el número de bytes que vienen a continuación y que
forman parte del paquete. Este campo está presente en todos aquellos paquetes
que recibe cualquier robot cuando el tamaño del paquete es variable. En nuestro
caso, el número de bytes enviados por el servidor depende del número de sonares
cuyo valor varía de una lectura a la siguiente.
− Estado del robot (1 byte): indica si el estado está parado (0x33) o en

movimiento (0x32).
− Posición del robot (Xpos, Ypos, Thpos): el servidor envía unos valores que
multiplicados por unas constantes (DistConvFactor, para Xpos y Ypos;
AngleConvFactor, para Thpos), indican la posición actual del robot en milímetros
y grados, respectivamente.
− Velocidad de las ruedas: el servidor envía la velocidad de cada una de las ruedas
en unas unidades que hay que multiplicar por la constante VelConvFactor para
convertirlas a mm/s.
− Batería: indica el nivel de carga de la batería.
− Bumpers: indicador de choque, tanto para los bumpers delanteros como los
traseros.
− Sonares: la información que el servidor envía acerca de los sonares es variable,

ya que depende del número de sonares cuyo valor haya cambiado de una lectura a
la siguiente. Primero envía el número de sonares cuyo valor ha cambiado, y para
cada uno de esos sonares envía el valor de la nueva lectura, que multiplicada por
la constante RangeConvFactor indica la distancia en mm al obstáculo detectado.
− Checksum: se utiliza para comprobar que los datos de la trama recibida son
correctos.
En la Tabla 4-1 se compara la información enviada por el robot Pioneer, con la

información enviada por cualquier robot general.
Tabla 4-4 Comparación de la información enviada por el robot Pioneer con un robot
general.
ROBOT PIONEER ROBOT GENERAL

Byte indicador:
Estado del robot 0x32: moving Byte indicador
0x33: stopped
Posición del robot Coordenadas en mm (x, y, Th) Tics de las ruedas
Velocidad de las ruedas Valor en mm/s Valor en una unidad

determinada
Batería Nivel de carga en voltios
Bumpers Valor que indica si alguno de los Byte indicador

bumper está presionado.
Sonares Distancia (mm) al obstáculo. Señal (odometría)
Para desarrollar la aplicación es necesario utilizar un lenguaje de programación para

implementar algunas funciones básicas del robot. Es así como se ha utilizado InSiDE que es
la herramienta que en el DSIC se ha construido para componer SBCTR. Esta herramienta
está hecha bajo el lenguaje C. Algunas de las estructuras y funciones que se han
implementado para controlar el robot son las siguientes:
• Estructuras:
− Estructura para la manipulación del estado de los paquetes leídos del puerto serie.
La estructura que se muestra a continuación se utiliza para almacenar el estado de
los paquetes que se van recibiendo.
struct paquete {
int actual_p; // Posición de la última trama
int estado; // Estado de la trama actual: COMPLETO-
PENDIENTE
int leidos_C; // Nº bytes de la cabecera leídos hasta
el momento
int leidos_T; // Nº bytes de la trama leídos hasta el
momento
};
− Estructura que almacena la información de fábrica del robot.
Una vez se ha establecido la comunicación, la primera información que envía el

robot hace referencia al nombre, clase y subclase del robot. Esta información es
almacenada en la siguiente estructura.
struct info {
unsigned char nombre[14]; // Nombre del robot

unsigned char clase[7]; // Clase del robot
unsigned char subclase[4]; // Subclase del robot
};
− Estructura que almacena la información de los sonares.

El robot consta de 16 sonares, numerados de izquierda a derecha: 0-7 son sonares

delanteros, y del 8-15 son los traseros. En la siguiente estructura se almacena el valor
del sonar, que indica la distancia en mm al obstáculo detectado, y la posición del sonar
respecto al origen de coordenadas del robot.
struct sonar {
unsigned short int valor; // Valor del sonar

(distancia en mm).
unsigned short int x,y,Th; // Pos. del sonar respecto
al robot
};
− Estructura que almacena la información sobre las condiciones del robot.
Como se ha comentado anteriormente, después de establecer la comunicación, el

robot envía cada 100 ms un paquete que contiene información sobre el robot. Esta
información es almacenada en la siguiente estructura, para su posterior acceso y
utilización.
struct robot {
unsigned char status; // Estado del robot:
STOPPED, MOVING
short int Xpos,Ypos,Thpos; // Coordenadas de la
posición local
short int Lvel, Rvel; // Velocidad de las ruedas
short int battery; // Nivel de la batería
short int bumpers; // Indicador de choque
short int timer; // Puerto analógico
seleccionado
sonar sonares[16]; // Vector que contiene los
16 sonares
};
• Funciones
− Funciones de acesso al puerto serie.
La comunicación con el robot (establecimiento de la conexión, envío y recepción

de información) se realiza a través del puerto serie. A continuación se muestran las
funciones que gestionan el acceso al puerto serie, llamando a las funciones que se
encargan de la lectura y escritura en el puerto (rt_com_read y rt_com_write).
o void vaciar_puerto(int fd): lee todo el contenido actual del buffer, con el fin
de vaciarlo para prepararlo para realizar una nueva conexión.
o void envio_com(unsigned char num): envía al robot un comando sin

argumentos (COMPULSE, COMOPEN, COMCLOSE, ...).
o void envio_com1(unsigned char num, unsigned char tipo_arg, unsigned short

int valor_arg): envíaa al robot un comando (num), con un argumento
(valor_arg), y su respectivo tipo (tipo_arg).
o int obtener_cabecera(): obtiene la cabecera de la trama enviada por el

servidor. Continua leyendo bytes hasta que encuentra los dos bytes de la
cabecera. Devuelve el número de bytes leídos de la cabecera; -1 si error.
o int obtener_trama(): lee del puerto serie los datos que contiene una trama.
Devuelve el número de bytes leídos.
o int esperar_cabecera(): lee del puerto serie hasta que obtiene la cabecera
completa del paquete enviado por el robot. Devuelve 0 si se leyó
correctamente; -1 en caso de error.
o int esperar_trama(): lee del puerto serie hasta obtener la trama de datos
completa del paquete enviado por el robot. Devuelve –1 si hay error; 0 si se
leyó correctamente y el checksum de la trama es correcto.
− Funciones para la comunicación con el robot.
A continuación se muestran las funciones que permiten establecer la conexión con

el robot (enviando los comandos necesarios), así como aquellas funciones que tratan la
información enviada por el robot, separando la cabecera de los datos, los cuales serán
tratados y almacenados para su posterior acceso.
o int leer_paquete(): lee el contenido del puerto serie, llamando a las funciones
obtener_cabecera() y obtener_trama(), desde donde se había quedado la
última vez. Devuelve –1 si ha ocurrido un error; 1 si la cabecera o la trama
están pendientes de lectura (incompletas); 0 en caso contrario.
o int obtener_ultimo_paquete(): lee todo el contenido del puerto serie,

llamando a la función anterior, sin esperar a que la última trama esté
completa. Devuelve la posición de la última trama completa; -1 en caso de
error.
o int establecer_conexion(): establece la conexión con el robot enviando

sucesivamente las tramas SYNC0, SYNC1 y SYNC2 (mediante la función
envio_com()), al mismo tiempo que espera la respuesta del robot (mediante
la función leer_paquete()). Devuelve 0 si la conexión se ha establecido; -1 si
no se ha podido conectar; 1 si la conexión está inicializada pero no
terminada.
o int conexión_robot(): intenta establecer la conexión con el robot, llamando a

la función anterior. Devuelve –1 si hay error; 0 en caso contrario.
o void inicializar_conexión(): envia al robot los comandos OPEN y PULSE,

provocando la activación de los controladores, de los sonares y de los
motores. Además, el robot empieza a transmitir información, al mismo

tiempo que espera comandos enviados por el cliente.
o int estado_conexion(): devuelve el estado de la conexión (CONNECT,

NO_CONNECT).
o void envio_pulso(): envia al robot el comando PULSE, para evitar que la

conexión se pierda.
o void cerrar_conexión_robot(): cierra la conexión con el robot, enviandole el

comando CLOSE mediante la función envio_com().
− Además, se tienen unas funciones auxiliares para la comunicación se utilizan para

inicializar y acceder a las estructuras utilizadas en la comunicación, calcular el
checksum de la trama enviada y recibida, comprobar que la trama recibida es la
esperada, entre otras.
− Hay funciones para gestionar la información del robot. Una vez la conexión ha
sido establecida, el robot comienza a enviar paquetes de información
periódicamente cada 100 ms a través del puerto serie. Las siguientes funciones
obtienen el paquete enviado por el robot, y lo almacenan en la estructura de datos
robot, para su posterior utilización. Además, existen unas funciones que
permiten imprimir la información que contiene esta estructura.
− Una vez se ha establecido la conexión y los motores son habilitados, es posible

enviar al robot diferentes comandos de movimiento, tanto de traslación como de
rotación. Así que se hicieron unas funciones para controlar el movimiento del
robot. Cuando el robot recibe estos comandos, intenta alcanzar la velocidad y el
ángulo deseados tan pronto como estos son recibidos. Las siguientes funciones
permiten el envío de estos comandos (SETA, SETV, SETRV, SETRA,
VEL, DHEAD, STOP).
Para detallar más el proceso construido en este escenario, se presenta la TAN

configuración que tiene como objetivo el establecimiento de la conexión del robot, y para la
que se establece el siguiente protocolo:
Antes de poder enviar y recibir información del robot, es necesario establecer la

conexión a través del puerto serie. Al encender el robot, éste se encuentra en un estado de
espera (NO_CONNECT). Para establecer la conexión, la aplicación cliente debe mandar
una serie de paquetes de sincronización a través del puerto serie: SYNC0, SYNC1 y
SYNC2, sucesivamente, y recuperar las respuestas enviadas por el servidor. P2OS responde
a cada comando enviado por el cliente, formando una sucesión de paquetes de
sincronización idénticos a los recibidos. El cliente debe esperar la llegada de estos paquetes,
de forma que sólo debe enviar un paquete cuando se ha recibido el eco. Si después de
realizar un número determinado de intentos, no se ha podido establecer la conexión, ésta
falla. Ver Figura 4-31 Diagrama que representa el inicio de la conexión.
Cuando la información se ha establecido, en primer lugar el servidor envía un paquete

que contiene información sobre el nombre (VALENCIA1220), clase (Pioneer) y subclase
(DX) del robot. En este momento, el cliente debe enviar el comando OPEN, para que el
robot comience a activar los sonares y los controladores de los motores, transmitir
información, y espere a recibir los comandos del cliente.
intentos=0
NO_CONNECT
Si (intentos<100) Envio_SYNC0
SYNC0
Recibo_SYNC0
Error
SYNC0_R
intentos++
Envio_SYNC1
SYNC1 Si
(intentos>=N)
Recibo_SYNC1
SYNC1_R
Envio_SYNC2
CONNECTION
CONNECT
FAILED
Figura 4-31 Diagrama que representa el inicio de la conexión
Por defecto la información es enviada cada 100 ms, valor que puede ser modificado
accediendo a la flash ROM del robot.
El servidor espera recibir al menos un paquete de comunicación cada 2 segundos

(valor que puede ser modificado). De lo contrario, se asume que la conexión cliente /
servidor se ha perdido, y cierra los motores del robot. Para evitarlo, se aconseja enviar el
comando PULSE al servidor periódicamente, para indicar que la conexión debe mantenerse.
Desde el punto de la descripción del método para buscar objetos, se presenta el

siguiente seudocódigo:
Módulo Buscar-Objeto
1. Leer sensores
2. Analizar sensores por sector (delanteros, traseros, laterales)
Obtener coordenadas del objeto
3. Si alguna coordenada no coincide con límite del mapa
3.1. Orientar robot en dirección (x, y,θ)
3.2. Avanzar hasta coordenadas
3.3. Módulo Reconocer-Objeto

4. Si no avanzar en dirección predeterminada
5. Volver a 1.
4.4.5 Modelo de tareas de tiempo real

Aplicando la topología de la arquitectura ARTIS para este caso específico, se pueden
apreciar las siguientes relaciones:
Robot
AA
In-Agents
Config ActRobot BuscaObj IdObj MovObj
PercepEntorno PlanAcción EjecAcción MKSs
LeerSensor VeriObjetivo EjecComando KSs
Figura 4-32 TAN en ARTIS
En donde, se tiene una TTR por cada in-agente que se defina, de modo que en este
caso se tienen cinco tareas de tiempo real, definidas de la siguiente forma en términos de
CML2:
real-time-task ::= PlanAcción;

from: BuscaObj;
relative-time: Yes;
period: 100; /* milisegundos*/
deadline: 8; /* milisegundos*/
real-time-task-before : PercepEntorno;
formed-by-others: No;
roles :
input: lista-sensores;
output: acción-planeada;
end real-time-task PlanAcción;
real-time-task ::= LeerListaSensor;

from: PlanAcción;
relative-time: Yes;
wcet: 2; /* milisegundos */
formed-by-others: Yes;
roles :
input: lectura-puerto-serie;
output: lista-sensores;
end real-time-task LeerSensor;
Al traducir estas estructuras de CML2 al lenguaje de bajo nivel (al que el usuario no
tiene acceso, sino que el sistema mismo se encarga de generar) definido en ARTIS se
obtiene lo siguiente:
(defagent buscaObj
(period 100) // 100 ms
(deadline 8) // 8 ms
(importance 1) // el más importante
(perception (percepEntorno))
(cognition (planAcción))
(action (ejecAcción))
(precedence (nil)) )
(defmks planAcción ()
(leerListaSensores)
(veriObjetivo)
(ejeComando)
(type mandatory)
(importance 1))
(defks leerListaSensor ()
(wcet 2)
(codefile ´.\ks_leerListaSensores.c´) )
(defks veriObjetivo()
(wcet )
(codefile ´.ks_veriObejtivo.c´\))
(defks ejecComando ()
(wcet )
(codefile ´.ks_ejecComando.c´\))
Además, en el blackboard se tendrían las clases y objetos (conceptos en

CommonKADS) de forma tal, que definieran sus atributos. Así, para el concepto Robot, se
tendría lo siguiente:
(defclass ROBOT // robot serial

{ (slot pos (type position))
(slot bump (type bumper))
(slot status (type valor-estado))
(slot vel_rigth (type int))
(slot vel_left (type int))
(slot front_sonar_bat[8] (type sonar))
(slot rear_sonar_bat[8] (type sonar))
(slot serial_status (type int)) })
SIMULACIÓN
Se ha hecho una simulación del comportamiento del robot en el micro mundo
planteado anteriormente y actualmente se está implementando con ARTIS.
La Figura 4-33 presenta el estado inicial del micro mundo, con el robot en su posición
inicial. El objeto que el robot tiene que encontrar es un rectángulo en medio del cuarto, y
debería ser movido hasta localizarlo en la parte inferior de la pared de la derecha.
Figura 4-33 Estado inicial del micro mundo
La Figura 4-34 muestra el estado final del micro mundo, cuando el robot ha ubicado
el objeto en el lugar apropiado [SHB00]. En ésta figura se puede apreciar la trayectoria
seguida para alcanzar el objetivo final.
Figura 4-34 Estado final del micro mundo

En la Figura 4-35, se aprecia una fotografía del robot enfrente del objeto.
Figura 4-35 El Pioneer 2 enfrente de un objeto de forma rectangular
4.5 Conclusiones de la aplicación de

CommonKADS-RT
Los dos escenarios presentados en este capítulo, son tan diferentes en su esencia, en el
tipo de problema y en la forma en que se aborda cada uno de ellos, y tienen en común el
tipo de solución propuesta. En ambos casos se plantea el modelado, diseño, construcción e
implantación de un sistema basado en el conocimiento de tiempo real, con un propósito
acorde con el problema. Por tanto, estos dos casos nos permiten llegar a razonamientos
válidos acerca de la utilización de la metodología. Es como si fuera un proceso de
inducción, sólo que no se puede generalizar porque para ellos es necesario aplicar la
metodología a muchos más casos y que además sea probada y aceptada por otros. Pero,
para efectos de esta investigación, se considera que si son validas las afirmaciones que se
hagan al respecto.
Como análisis individual de los escenarios, se concluye que para el caso del robot fue
importante la utilización de la metodología pues se logró formalizar mucho el conocimiento
requerido, se corrigió la estrategia de programar antes de analizar y se registró el proceso
llevado a cabo durante el proyecto. Se encontró que en la parte de diseño hay una carencia
todavía y es la no-inclusión en la metodología de estrategias para definir los métodos de
planificación de las tareas de tiempo real y de técnicas para llevar a cabo el test off-line de
planificabilidad. Por tanto, esta es una mejora que se le puede hacer a la metodología, en
trabajos futuros. Pero, también se demostró con este caso, que CommonKADS-RT sirve
para modelar cualquier situación en donde se requiera tener un comportamiento inteligente
bajo unas restricciones temporales, sin importar lo complejo del problema o si está
enmarcado en un contexto organizacional.
Para el caso del puerto, se logró probar que la utilización de CommonKADS-RT

permitió que los mismos expertos reconocieran e hicieran conciente algunos de los
procesos que realizan en su que-hacer diario y de las formas y estrategias que utilizan para
ello, permitiendo que se replanteen o reafirmen algunos de ellos. Esto quizá no es uno de
los objetivos de la metodología, pero es un valor añadido que se obtiene al utilizarla, porque
así sea que se construya o no el SBCTR, se logra mejor la situación actual.
En ambos casos se comprobó que el realizar un proceso formal de análisis y diseño

asegura que tanto el conocimiento obtenido como el sistema propuesto, se desarrollan de
acuerdo con sus requerimientos. Así, la implementación se hace más fácil y permite
eliminar errores en el proceso. También, la metodología logró que se definiera un
vocabulario común para los ingenieros del conocimiento, los diseñadores, los expertos, los
usuarios y los programadores, en áreas que aparentemente son tan dispares como son las de
los SBC y los STR, facilitando el intercambio de ideas acerca del problema y del sistema y
que se pudieran compartir procesos comunes de trabajo.
Se pudo observar que ciertos elementos de los modelos de CommonKADS-RT son

más relevantes que otros, dependiendo del proyecto. Es decir, que según el problema, la
organización, el sistema y su entorno, algunos aspectos podrán ser considerados y
valorados. No todo lo definido en los formularios de los modelos debe ser especificado, tal
como se acaba de apreciar al comparar el escenario del robot con el del puerto.
También, dependiendo del proyecto y del sistema, es posible realizar varios modelos a
la vez. Es decir, que se pueden estar realizando actividades de diversos modelos en
paralelo, pues en la medida en que se van definiendo los conceptos o se van completando
las especificaciones, el conocimiento y la información pueden servir para modelar distintas
vistas de ello. Esto permite reafirmar la idea de trabajar en un ciclo por espiral, teniendo en
cuenta la valoración de los riesgos y los planes que se van construyendo en la medida que
se avanza en el análisis y diseño del problema y de la situación.
Al usar la metodología, se pudo apreciar que se estaban corrigiendo algunas de las

debilidades de CommonKADS y de RT-UML, pues la primera se dedica más a la fase de
análisis del SBC y la segunda a la fase del diseño del STR, así que con CommonKADS-RT
se ha tratado de fortalecer e integrar estas visiones para que cuando se requiere desarrollar
un SBCTR se pueda tener herramientas a nivel del dominio del problema y de la solución.
Por último, la actividad de analizar y diseñar sistemas para casos reales, como el del
robot y el del puerto, ha permitido que se mejore las consideraciones metodológicas que se
tenían, pues se fueron validando en caliente. Es decir, que en la medida que se iban
desarrollando los casos, se iba modificando la metodología para que se ajustara mucho más
a la práctica real de un proyecto de construcción de un SBCTR. Esto es el valor verdadero
de mostrar la aplicación de una metodología, porque sino se convertiría en el simple
desarrollo de un software mas.
Es importante resaltar que si se quiere tener una metodología completa, que pueda ser
usada para especificar los requerimientos del sistema, describir el entorno del sistema en
donde será implementado (modelo conceptual - fase de análisis), definir la arquitectura del
sistema futuro (fase de diseño) y especificar la plataforma de hardware, los protocolos de
transferencia y de comunicación (fase de implementación), hay que mejorar
CommonKADS-RT. Especialmente en lo que se refiere a esta última fase de
implementación.
CommonKADS-RT – Capítulo 5. Conclusiones y trabajos futuros 211
Capítulo 5.
Conclusiones y trabajos futuros
5.1 Introducción
El desarrollo de sistemas basados en el conocimiento de tiempo real involucra una
serie de procesos y de componentes que requieren de una definición apropiada y un
tratamiento adecuado. Es así, como un sistema basado en el conocimiento de tiempo real
tiene un propósito específico, sigue una arquitectura definida e implica una serie de
actividades que en cierta forma, pueden garantizar su aplicabilidad y utilidad.
Este tipo de sistemas ha generado mucho interés en los últimos años, tanto en la
comunidad científica como en la industria, y es básicamente porque sirven para solucionar
problemas muy complejos que se presentan en diferentes entornos. Se han propuesto
muchas arquitecturas para construirlos y se han desarrollado herramientas software que
facilitan su realización. Las principales aportaciones han estado orientadas hacia la
construcción misma del sistema, pero no se ha dedicado mucho esfuerzo en el desarrollo de
propuestas de gestión de un proyecto de ese estilo, a su especificación, análisis, diseño de la
solución e impacto. Es por esto, que se considera importante el contar con una metodología
que permita guiar el proceso de desarrollo del proyecto y del sistema en forma clara y
válida.
A continuación se presentan las conclusiones más relevantes que se han obtenido

después de realizar esta investigación. Éstas son el resultado, tanto del estudio de los
sistemas basados en el conocimiento, de los sistemas de tiempo real, de los sistemas
basados en el conocimiento de tiempo real y de las metodologías para el desarrollo de
software en general, como de la aplicación que se hizo de la metodología.
Adicionalmente, se presentan los trabajos futuros y las líneas de trabajo que se abren
para complementar el alcance de esta investigación.
5.2 Conclusiones generales

La conclusión más relevante de esta tesis es que la metodología CommonKADS-RT
que se propone en esta investigación, es apropiada para el desarrollo de sistemas basados en
el conocimiento de tiempo real estricto.
También es importante resaltar la viabilidad de adecuar metodologías existentes y

reconocidas para el desarrollo de sistemas de software para el desarrollo de sistemas
basados en el conocimiento de tiempo real.
Es posible utilizar CommonKADS y RT-UML para modelar y diseñar

Para llegar a esta conclusión se desarrolló un proceso incremental de investigación en

el cual se fueron analizando diferentes metodologías para desarrollar sistemas basados en el
conocimiento, sistemas de tiempo real y sistemas basados en el conocimiento de tiempo
real.
La investigación se comenzó con el estudio de los sistemas basados en el

conocimiento de tiempo real, su definición, los diferentes tipos de SBCTR, las arquitecturas
más comunes y los métodos o metodologías que se utilizan para su desarrollo. Así, que una
de las conclusiones más importantes de esta etapa de la investigación es que no hay una
metodología completa en donde se conciban las características propias y específicas de los
sistemas que manejan tanto el conocimiento como las restricciones temporales y que era
necesario plantear una que fuera fácil de manejar, que estuviera basada en conceptos e ideas
probadas y aceptadas, y que integrara los procedimientos de la ingeniería del software.
No hay una metodología completa en donde se conciban las

características propias y específicas de los sistemas que manejan tanto el
conocimiento como las restricciones temporales
También durante el estudio de las áreas implicadas, se encontró que en los sistemas de
tiempo real la mayoría del software que se desarrolla es a la medida, es decir, específico
para la organización. En general, para su desarrollo no se siguen métodos o metodologías
estándar que cubran todo el proceso y ciclo de vida de un sistema informático. Los métodos
que hay son especializados en el diseño del STR, dejando de lado o por fuera lo que se
refiere al análisis del problema y de su solución. Por lo tanto, muchas veces ocurre que este
software sólo soluciona en parte el problema, pues no ha sido creado con una visión
sistémica y holística. Así, que una conclusión importante sobre este tema es que es
necesario proponer, diseñar y aplicar metodologías completas para el desarrollo de sistemas
de tiempo real.
Es necesario proponer, diseñar y aplicar metodologías completas para el

desarrollo de sistemas de tiempo real.
Obviamente, ya se cuenta con RT-UML que es una muy buena alternativa

metodológica para el desarrollo de los STR. Así, que si ésta es mejorada en cuanto a la fase
de análisis y adoptada por la OMG (Object Management Group), se tendría un estándar
metodológico que podría orientar el buen desarrollo de estos sistemas.
El paradigma de desarrollo de modelos para el análisis y diseño de una aplicación ha

sido una de los grandes aportes que se han tomado de los sistemas basados en el
conocimiento, particularmente de CommonKADS. Después de estudiar a fondo esta
metodología, se puede concluir que su aporte, sus planteamientos y su aplicación son muy
valiosos, tanto para el área de la inteligencia artificial, como de la informática en general y
muy especialmente de la gestión organizacional en la era del conocimiento.
CommonKADS tiene un impacto muy positivo y permite que se utilice en diversas
situaciones, no exclusivas de los SBC.
La aportación, los planteamientos y la aplicación de CommonKADS son

muy valiosos, tanto para el área de la inteligencia artificial, como de la
informática en general y muy especialmente de la gestión organizacional
en la era del conocimiento.
Otra conclusión importante es que el dominio de los sistemas basados en el

conocimiento de tiempo real tiene mucha aplicación en situaciones reales de las
organizaciones, así que es necesario tener métodos y metodologías que permitan guiar su
construcción. Las que se conocen actualmente, presentan algunos inconvenientes, bien sea
en el tratamiento del tiempo real o en la fundamentación del conocimiento.
Se necesitan metodologías que conduzcan el desarrollo de sistemas

basados en el conocimiento de tiempo real, lo que permitiría que se difunda
más esta tecnología.
Un alternativa que se puede plantear para formalmente introducir características

temporales basadas en el conocimiento, es crear un grupo de interés similar al creado para
tiempo real en la OMG, el cual se encargaría de estandarizar el vocabulario, las
arquitecturas y los métodos y metodologías apropiados para el fortalecimiento de este
dominio.
Crear un grupo de interés en la OMG para que trabaje alrededor de los

sistemas basados en el conocimiento de tiempo real
Finalmente, se pudo comprobar que una metodología es buena, en la medida en que:

proporcione las herramientas específicas y apropiadas para la construcción de un sistema,
en que se sigan sus pasos y recomendaciones, y se documenten las actividades realizadas.
Además, la elección de la metodología dependerá del dominio del problema, del tipo de
solución, del conocimiento de los analistas y desarrolladores, del interés y apoyo que todo
el grupo de participantes le pongan al proceso planteado en ella, y del alcance de la
metodología. Por tanto se concluye que estos aspectos son los más relevantes para
considerar una metodología en el desarrollo de sistemas informáticos.
El dominio del problema, el tipo de solución, el conocimiento del grupo de

desarrollo, el interés y apoyo organización, y el alcance de la metodología
son los aspectos más relevantes que se deben considerar en una
metodología para el desarrollo de sistemas informáticos.
En este caso, CommonKADS-RT se ha definido para un dominio en donde el

conocimiento bajo restricciones temporales y con plazos de tiempo predeterminados es la
característica fundamental. La valoración que se haga de los criterios de filtrado dará con
cierto grado de certeza que la mejor alternativa de solución es un sistema basado en el
conocimiento de tiempo real. El grupo de desarrollo debe tener conocimiento sobre este
tipo de problemas y soluciones, así como del desarrollo de modelos, de evaluación de
riesgos y del lenguaje de modelado unificado. Y obviamente, para que CommonKADS-RT
y los artefactos producidos durante su aplicación tengan éxito se debe contar con el apoyo
de la alta gerencia, de los expertos en el dominio y de los expertos en la solución.
CommonKADS-RT incluye todos los elementos que la ingeniería del

conocimiento propone para una metodología de desarrollo de software, con
excepción de los mecanismos de decisión.
Desde el punto de vista de la ingeniería del software, en especial, del planteamiento de

lo que debe ser una metodología para un proyecto informático, CommonKADS-RT cumple
con la mayoría de ello. Sólo faltan proponer los mecanismos de decisión. Por lo tanto, se
considera que es válida. En general, los métodos y metodologías de los SBC ponen énfasis
en la fase de análisis y los de los STR lo ponen en la fase de diseño. CommonKADS-RT
integra estos planteamientos pues cubre ambas fases, lo que falta es tratar la fase de
implementación ampliamente.
CommonKADS-RT cubre las fases de análisis y de diseño para el

desarrollo de un sistema basado en el conocimiento de tiempo real
5.3 Contribuciones principales

El objetivo principal de esta investigación es la proposición de una metodología para
el desarrollo de sistemas basados en el conocimiento de tiempo real. Es decir, crear unas
consideraciones relacionadas con el análisis y el diseño de un sistema de ese tipo.
En la introducción de esta memoria se definió que una metodología de software

debería indicar: las actividades específicas a realizarse en el desarrollo del sistema (etapas),
el orden en que éstas se debe realizar (ciclo de vida), las herramientas para realizar las
actividades, los responsables de cada una de las etapas, los artefactos obtenidos, y las guías
para tomar decisiones. Así, que de acuerdo con esto y con los objetivos planteados también
al comienzo, se describirán las principales contribuciones de esta tesis:
• Contribuciones en relación con el área de los sistemas basados en el conocimiento

de tiempo real
Como se planteó en el capítulo del estado del arte, en la sección de los sistemas
basados en el conocimiento de tiempo real, para el desarrollo de estos no se dispone de
muchas metodologías que permitan que su construcción sea más generalizada. Las que
actualmente se conocen tienen una visión diferente del tratamiento del tiempo real, por lo
que se considera que la metodología CommonKADS-RT es un aporte muy importante para
lograr ese objetivo.
CommonKADS-RT facilitará y permitirá que se construyan más sistemas

basados en el conocimiento, lo que redundará en el desarrollo de muchas
otras técnicas y herramientas alrededor de está área
• Contribuciones en relación con las guías de aplicación de la metodología

CommonKADS-RT
Es importante tener una descripción global del proceso que se debe seguir para la
utilización de la metodología deseada. Por ello, al comienzo en CommonKADS-RT se hace
una descripción de ella misma, un planteamiento o esbozo general de las consideraciones
metodológicas que se tienen para desarrollar un SBCTR. Así, el analista del problema y de
la solución puede tener una idea general del proceso que deben llevar a cabo al utilizar la
metodología, facilitando la elaboración de la propuesta del proyecto.
Con CommonKADS-RT se adjunta una descripción general del proceso

que se debe seguir en ella. Es un esbozo general de las actividades, técnicas
y métodos necesarios para analizar y diseñar un SBCTR
Continuando con los aspectos globales que enmarcan la metodología, hay una
aportación importante en relación con la aplicación de CommonKADS-RT. Se ha
considerado fundamental, y en este caso se resalta por servir de ayuda y porque la mayoría
de las metodologías no lo contemplan, la caracterización del dominio en donde es adecuado
utilizar CommonKADS-RT. Es decir, la especificación de las propiedades particulares que
debe tener el dominio en donde se quiere desarrollar un SBCTR utilizando como marco
metodológico CommonKADS-RT.
Se han definido unas características del dominio que es apropiado para la

aplicación de CommonKADS-RT
Durante la investigación se encontró que en las diferentes áreas involucradas en la

misma, y a pesar de estar todas ellas dentro del ámbito de la informática, existen grandes
diferencias en cuanto al manejo de los términos y de los conceptos. Por ejemplo, lo que
para unos es el concepto de tarea, para otros es completamente diferente. Por eso, se
decidió hacer una serie de ajustes que permitieran tener unos conceptos unificados para los
sistemas basados en el conocimiento y los sistemas de tiempo real.
Esto también ocurre en cuanto a lo que se considera como una metodología y un

método en la ingeniería del conocimiento, los sistemas basados en el conocimiento y la
ingeniería del software. Por lo tanto, uno de los aportes de esta investigación, es la
distinción y eliminación de ambigüedad de los conceptos que se manejan dentro del área de
los sistemas basados en el conocimiento de tiempo real, definiendo desde el comienzo de la
metodología, y en particular en cada uno de los modelos que la conforman, el vocabulario
específico.
En CommonKADS-RT se maneja una terminología específica para los

sistemas basados en el conocimiento de tiempo real y para lo que es una
metodología de desarrollo de software, lo cual es consistente y no ambigua.
• Contribuciones en relación con los modelos de CommonKADS-RT
Se ha decidido que para cada uno de los modelos que conforman CommonKADS-RT
se tenga una lista de los artefactos que se producen durante el desarrollo del mismo. De esta
forma, cuando se comienza con el desarrollo de un modelo se sabe desde el comienzo qué
es lo que se debe obtener al final. Así que esta clave o guía se puede ver como un criterio de
calidad del modelo, para determinar en qué estado se está en su construcción y para facilitar
la determinación de su punto final, pues si ya se tienen todos los artefactos y además estos
están completos, entonces se puede asumir que el modelo está terminado. Este es un aporte
muy valioso.
Por otra parte, es importante tener herramientas que permitan evaluar cuál de las
situaciones presentes en la organización es la más importante o urgente de tratar, de
acuerdo con la misión, visión y los factores críticos de éxito que se tengan definidos en la
misma empresa. Para ello, en el modelo de la organización se ha propuesto la inclusión de
la matriz DAFO, herramienta de la planificación estratégica, que guía y facilita la
identificación de aspectos relevantes y actuales de la organización, dándole un valor
agregado a la metodología CommonKADS-RT, pues además de posibilitar el desarrollo de
un SBCTR, es útil para hacer el análisis actual del dominio organizacional.
En el modelo de la organización se ha propuesto la inclusión de la matriz

DAFO, herramienta de la planificación estratégica, que guía y facilita la
identificación de aspectos relevantes y actuales de la organización, dándole
un valor agregado a la metodología CommonKADS-RT.
Cuando se va a solucionar una situación o problema que ocurre en una organización,

es necesario contar con las herramientas apropiadas para llevar a cabo el análisis del
mismo, con el objetivo de plantear alternativas que realmente sí lo corrijan e incluso
permitan mejorarlo. Es así, como es importante contar con unos criterios que le sirvan de
guía a los desarrolladores para evaluar si cierta alternativa informática será viable de aplicar
en un caso específico. Es por ello que se han propuesto unos criterios de filtrado que
apoyan dicho proceso.
Los criterios de filtrado son una aportación significativa de esta

investigación. Permiten evaluar con anticipación, la pertinencia de
proponer como solución un sistema basado en el conocimiento de tiempo

real ante cierta situación.
Se ha considerado trascendental que desde el comienzo del estudio del problema se

planteen interrogantes relacionados con el manejo del conocimiento y de las
especificaciones temporales, pues esto determinará, en cierta medida, el tipo de solución
más conveniente. En este sentido, otro aporte relacionado con el modelo de la
organización es que se ha definido un nuevo formulario y se han incluido en los demás,
variables temporales que permiten definir, a un alto nivel de abstracción, estas
características especiales.
En el modelo de la organización se han introducido muchos cambios

relacionados específicamente con el manejo del tiempo, de las restricciones
temporales. Además, se ha incluido una lista de eventos externos que tienen
relación con el sistema y un nuevo formulario para hacer la descripción de
los aspectos de la organización que tendrán impacto o estarán afectados
por la solución escogida del SBCTR.
En el modelo de agentes se ha introducido la tipología de los agentes, humanos y

software. El primero se denomina actor y para los segundos se han clasificado en agentes
que se encargan de percibir el entorno, agentes que hacen procesos de razonamientos o
cognición y de agentes que realizan acciones sobre el entorno. Esta clasificación de los
agentes posibilita el tener diferentes métodos para su modelado y manejo, el seguir con una
terminología más cercana al lenguaje de modelado unificado, y el servir de acercamiento al
paradigma de agentes inteligentes.
En el modelo de agentes se distinguen los actores de los agentes de

percepción, de cognición y de acción.
En el modelo de comunicación se ha propuesto el manejo de los estándares de

comunicación de agentes FIPA, proporcionando la universalidad y el cubrimiento de la
comunicación posible entre los diferentes agentes del SBCTR.
Incluir FIPA en el modelo de comunicaciones, haciendo que las

transacciones y los mensajes sean de una manera estándar.
La fase de diseño quizá es una de las mayores aportaciones de este trabajo, ya que ésta
no ha sido muy trabajada para los sistemas basados en el conocimiento de tiempo real. En
ella se han incluido dos modelos: el de diseño y el de tareas de tiempo real. Los aportes han
sido varios:
• Tener una arquitectura para el SBCTR, específicamente ARTIS.
• Definir una estructura para la tarea de tiempo real, siguiendo un MKS.
• Especificar el diseño detallado de la aplicación.
• Considerar la realización del test de planificabilidad, aunque no se explique en detalle.
Se propone una arquitectura para el SBCTR, una estructura para las

tareas de tiempo real y el diseño detallado de la aplicación.
5.4 Trabajos futuros
Se proponen las siguientes líneas de trabajo:
• En las áreas de los sistemas basados en el conocimiento y de los sistemas de

tiempo real
− En el área de los sistemas de tiempo real se debería construir o definir una

ontología para ese tipo de sistema, con el objetivo de fijar los conceptos y el
conocimiento del dominio de tiempo real en una forma genérica para tener un
acuerdo común que pueda ser compartido por todos los grupos de investigación,
evitando que se difundan y propaguen erróneamente.
− Fomentar la consideración y el estudio de los sistemas de conocimiento por parte

de la OMG y de la empresa RATIONAL para que así como hay extensiones de
UML para tiempo real, también se tenga unas para sistemas basados en el
conocimiento.
• En el área de los sistemas basados en el conocimiento de tiempo real
− Complementar y crear una conceptualización – ontología -, específicamente para

la aplicación de los sistemas basados en el conocimiento de tiempo real, en la que
se definan claramente los conceptos que en este tipo de sistemas se manipulan,
eliminando la ambigüedad y duplicidad, y posibilitando la reutilización de
componentes del modelo.
− Analizar las tareas intensivas en conocimientos que proponen [SAA+00] desde el

punto de vista del manejo de restricciones temporales y el cumplimiento de
límites de tiempo para su ejecución, entre otras. Esto implica revisar las
características generales, los métodos, las variables de entrada y las de salida de
cada uno de los tipos de tarea. Como resultado se podrán tener plantillas para
tareas intensivas en conocimientos de tiempo real, lo cual sería de mucha utilidad
para cuando se va a construir un sistema basado en el conocimiento de tiempo
real, utilizando CommonKADS-RT.
− Diseñar métodos de solución de problemas (PSM) para tareas específicas de este

tipo de sistemas, bien sea adecuando los que hay para los sistemas basados en el
conocimiento para que incluyan y manejen restricciones temporales o
proponiendo unos nuevos que sean de ese propósito específico. En especial, sería
para las tareas de planificación, scheduling y valoración.
• En la metodología CommonKADS-RT
− Desarrollar una herramienta software que traduzca directamente la nueva

especificación de CommonKADS-RT al lenguaje de bajo nivel de ARTIS. De
esta forma se reduciría el tiempo de desarrollo del sistema e incluso se evitarían
errores en la codificación.
− Analizar la aplicación de ARTIS para cada uno de los tipos de tareas intensivas
en el conocimiento. Esto puede implicar la realización del segundo trabajo
propuesto para el área de los sistemas basados en el conocimiento de tiempo real,
mas la revisión y adecuación de la arquitectura.
− La metodología CommonKADS- RT puede ser mejorada, si se le adicionan

criterios específicos para el diseño detallado del SBCTR, en especial para la
elección, elaboración y ejecución del análisis de desempeño y tests de
planificabilidad. Esto es muy importante porque para que la implantación de un
SBCTR tenga éxito se debe garantizar el cumplimiento de la planificación de las
tareas de tiempo real, en cuanto a su ejecución y al tiempo de las mismas.
− Aplicar la metodología en muchos más casos para obtener conclusiones que

puedan ser generalizadas y aplicadas a la misma metodología. Además que esto
permitiría que se difundieran más los sistemas basados en el conocimiento de
tiempo real y que estuvieran al alcance de organizaciones que los podrían utilizar
en su que-hacer diario.
• En otras áreas de la informática
− Dado el auge y la aplicabilidad que tiene en la actualidad el paradigma de los

sistemas multiagentes, es posible migrar o adecuar la metodología
CommonKADS-RT a una metodología que guíe el proceso de análisis, diseño
construcción e implantación de sistemas basados en agentes inteligentes de
tiempo real.
CommonKADS-RT – Abreviaturas 221
ABREVIATURAS
AIS Adaptative Intelligent Systems
AM Agent Model
ARTIS Arquitectura para Sistema de Tiempo Real Inteligente.
ASSET Aerospace Systems Simulation, Engineering, and Test tool
CIRCA Cooperative Intelligent Real-time Control Architecture
CM Communication Model
CML Conceptual Modeling Language
DAFO Debilidades, Amenazas, Fortalezas y Oportunidades
DARTS Design Approach for Real-Time Systems
DM Design Model
ESA European Spatial Agency
E/S Entrada / Salida
ESSOC Expert System for Satellite Orbit Control
FLES Flight Expert System
FRISCO A Framework of Information Systems Concepts
HPM Hartley Pirbhai Method
HRT-HOOD Hard Real-Time Hierarchical Object Oriented Design
Hz Hertz
IA Inteligencia Artificial
IC Ingeniero del Conocimiento
IPTES Incremental Prototyping Technology for Embedded Real-Time
Systems
KADS Knowledge Acquisition Design System
KM Knowledge Model
KRL Knowledge Representation Language
KSL Knowledge System Language
KSM Knowledge Structure Manager
LDP Language Design Program
MCSE Méthodologie de Conception des Systèmes Electroniques
MIKE Model-based and Incremental Knowledge Engineering
mm milímetro
ms milisegundo
MVC Model - View - Controller
OM Organization Model
OMG Object Management Group
OMT Object Modeling Technique
PM Project Management
PSM Problem Solving Method
RAE Real Academia Española
RAM REAKT Application Methodology
REAKT An Environment for Real-Time Knowledge-Based Systems
ROOM Real-Time Object-Oriented Modeling
ROPES Rapid Object-Oriented Process for Embedded Systems
RT-UML Real-Time - Unified Modeling Language
RTTM Real-Time Task Model
CommonKADS-RT – Abreviaturas 222
STR Sistema de Tiempo Real

SBC Sistema Basado en el Conocimiento
SBCTR Sistema Basado en el Conocimiento de Tiempo Real
TAN Tarea de Alto Nivel
TM Task Model
TOPKAT The Open Practical Knowledge Acquisition Toolkit
TTR Tarea de Tiempo Real
UML Unified Modeling Language
V Voltio
VDC Volt Direct Current
CommonKADS-RT – Referencias 223
REFERENCIAS
• Introducción
[Dou99] B. P. Douglass. Doing Hard Time; Developing Real-Time Systems with

UML, Objects, Frameworks, and Patterns. Addison-Wesley, United
States of America. 1999. 749 p.
[FHP+96] E. Falkenberg, W. Hesse, P. Lindgreen et al. FRISCO, A Framework of
Information System Concepts – The FRISCO Report. 1996. 221 p.
[Hum95] W. Humphrey. A Discipline for Software Engineering. Pittsburgh:
Addison-Wesley Publishing Company. 1995. 789 p.
[Igl98] C. Iglesias. Definición de una metodología para el desarrollo de sistemas
multiagentes. Tesis Doctoral, Universidad Politécnica de Madrid,
España. 1998. 294 p.
[MSC+95] M. Molina, Y. Shahar, J. Cuena, et al. A Structure of Problem-Solving
Methods for Real-time Decision Support: Modeling Approaches Using
Protégé-II and KSM. Proc. Of Knowledge Acquisition of Knowledge
Based Systems Workshop, KAW96. Banff, Canada. 1996. 20p.
http://vendabal.dia.di.upm.es/ksm/publications.html
[OMG99] OMG Unified Modeling Language Specification (draft). Version 1.3 beta
R7. Object Management Group, The United States of America. June
1999. 798 p.
[SGW94] B. Selic, G. Gullekson, P. Ward. Real-Time Object-Oriented Modeling.
John Wiley & Sons. The United States of America. 1994. 525 p.
• Sistemas basados en el conocimiento
[Abe92] M. Aben. Guidelines for the Formal Specification of KADS Models of

Expertise. Technical Report ESPRIT Project P5248 KADS-II, KADS-
II/T1.2/TR/UvA/37/1.0, University of Amsterdam. 1992.
[Abe93] M. Aben. Formally Specify Re-usable Knowledge Model Components.
Knowledge Acquisition Journal, 5. 1992. pp. 119-141.
[AFL+93] J. Angele, D. Fensel, D. Landes, et al. Model-based and Incremental

Knowledge Engineering: The MIKE Approach. In J. Cuena (ED.)
Proceedings of the IFIP TC12 Workshop on Artificial Intelligence from
the Information Processing Perspective - AIFIPP92, Madrid, Spain,
1992. Elsevier, Science Publisher B.V., Amsterdam. 1993.
[AFL+98] J. Angele, D. Fensel, D. Landes, R. Studer. Developing Knowledge-
Based Systems with MIKE. In Journal of Automated Software
Engineering, 5 (4). 1998. pp. 389-418.
http://www.aifb.uni-karlsruhe.de/WBS/publications/index.html
[AFS90] J. Angele, D. Fensel, R. Studer. Applying Software Engineering Methods
and Techniques to Knowledge Engineering. In D. Ehrenberg et al. (eds.),
Wissenbasierte Systeme in der Betriebswirtschaft, Reihe Betriebliche
Informations - und Kommunikationssysteme. No. 15, Erich Schmidt
Verlag. Berlin. 1990. pp. 285-304.
[AFS93] J. Angele, D. Fensel, R. Studer. Formalizing and Operationalizing
Models of Expertise with KARL. Institut fur Angewandte Informatik und
Formale Beschreibungsverfahren, University of Karlsruhe. Research
report. 1993.
[AFS96] J. Angele, D. Fensel and R. Studer. Domain and Task Modeling in
MIKE. In: A.G. Stucliffe, F. van Assche and D. Benyon (eds.): Domain
Knowledge for Interactive System Design, Proceedings of IFIP WG
8.1/13.2 Joint Working Conference, Geneva, 1996, Chapman & Hall.
1996. 17 p.
http://www.aifb.uni-karlsruhe.de/WBS/publications/index.html
[AKS+93] S. Aitken, O. Kuhn, N. Shadbolt, et al. A Conceptual Model of
Hierarchical Skeletal Planning and its Formalization. In Proceedings of
the 3rd KADS Meeting, Munich. 1993.
[Anj99] A. Anjewierden. Engineering and Managing Knowledge. 1999
http://www.commonkads.uva.nl/
[AnS94] A. Anjewierden, G. Schreiber. CML2 syntax (2.2.1). SWI, University of
Amsterdam. 1994. 6 p.
http://www.swi.psy.uva.nl/projects/kads22
[AVS+93] H. Akkermans, F. Van Harmelen, G. Schreiber, et al. A Formalization of

Knowledge Level Models for Knowledge Acquisition. In International
Journal of Intelligent Systems. Special Issue on Knowledge Acquisition,
No. 2, Vol. 8. 1993.
[Bac95] G. Baca. Evaluación de Proyectos. 3 ed. México: McGraw-Hill, 1995.
339 p.
[BaK92] C. Bauer, W. Karbach (eds.). Interpretation Models for KADS.
Proceedings of the 2nd KADS User Meeting (KUM92). Munich. GMD
Report No. 212. 1992.
[BeM97] R. Benjamins, A. Manfred. Structure-preserving Knowledge-Based
System Development through Reusable Libraries: A Case Study in
Diagnosis. 1997. pp. 259-288.
[Ben90] T. Bench-Capo. Knowledge Representation: An Approach to Artificial
Intelligence. Academic Press, London. 1990. 221 p.
[Ben93] R. Benjamins. Problem Solving Methods for Diagnosis. PhD thesis,
University of Amsterdam, Amsterdam, The Netherlands. 1993 172 p.
ISBN 90-9005877-X.
[BFP+97] R. Benjamins, D. Fensel, C. Pierret-Golbreich, et al. Making Knowledge
Engineering Technology Work. 1997.
http://www.aifb.uni-karlsruhe.de/WBS/publications/pub97.html
[Boe93] B. W. Boehm. A Spiral Model of Software Development and
Enhancement. In R. Donald, ed. Software Management. IEEE Computer
Press. 1993. pp. 120-131.
[BrV94] J. Breuker and Van de Velde. CommonKADS Library for Expertise
Modeling; Reusable problem solving components. IOS Press,
Amsterdam, 1994. 359 p.
[BrW89] J. Breuker, B. Wielinga. Models of Expertise in Knowledge Acquisition.
In G. Guida et al. (eds.), Topics in Expert Systems Design. Elsevier
Science Publisher B. V., North Holland. 1989. pp. 265-295.
[CaP96] C. Cadas, N. Parthenios. Catalyst - Use of CommonKADS Methodology
in Knowledge Nased Systems Development. Final Report. 1996. 54 p.
[CuM96] J. Cuena, M. Molina: Building Knowledge Models Using KSM. Proc. Of

Knowledge Acquisition of Knowledge Based Systems Workshop,
KAW96. Banff, Canada. 1996.
[DBM+94] R. De Hoog, B. Benus, C. Metselaar, et al. Organization Model: Model
Definition Document. Technical Report ESPRIT Project P5248 KADS-
II, KADS-II/M6/UvA/041/3.0, University of Amsterdam. 1994. 102 p.
[DMW93] J. Domingue, E. Motta, S. Watt. The Emerging VITAL Workbench. In
Aussenac, N., Boy, G., Gaines, B., Linster, M., Ganascia, J.-G. &
Kodratoff, Y. (eds) Knowledge Acquisition for Knowledge-Based
Systems 7th European Workshop, EKAW'93 Toulouse and Caylus,
France, Springer-Verlag. 1993. pp. 320-339.
[DMW+94] R. De Hoog, R. Martil, B. Wielinga, et al. The CommonKADS Model
Set. Technical Report ESPRIT Project P5248 KADS-II, KADS-
II/M1/DM1.1b/UvA/018/6.0/FINAL, University of Amsterdam. 1994. 31
p.
[Dom97] J. Domingue. VITAL Workbench. Knowledge Media Institute U.K.
http://kmi.open.ac.uk/~john/vital/vital.htm
[Duu94] C. Duursma. Task Model Definition and Task Analysis Process.
Technical Report ESPRIT Project P5248 KADS-II, KADS-
II/M5/VUB/RR/004/2.0, Vrije University of Brussels. 1994. 44 p.
[Edm88] R. Edmunds. The Prentice Hall Guide to Expert Systems. New Jersey:
Prentice Hall, 1988. 364 p.
[EPG+94] H. Erikson, A. Puerta, J. Gennari et al. Custom-Tailored Development
Tools for Knowledge-Based Systems. Technical Report KSL-94-67.
Stanford University, USA. 1994. 18 p.
[FAL91] D. Fensel, J. Angele, D. Landes. KARL: A Knowledge Acquisition and
Representation Language. In Proceedings of Expert Systems and their
Applications, 11th International Workshop, Conference "Tools,
Techniques & Methods", 27-31 May, Avignon. 1991. pp. 513-528.
[FAL+93] D. Fensel, J. Angele, D. Landes, R. Studer. Giving Structured Analysis
Techniques a Formal and Operational Semantics with KARL. In
Proceedings of Requirements Engineering 93 – Prototyping -, Teubner
Verlag, Stuttgart. 1993.
[FAL98] D. Fensel, J. Angele, D. Landes. A Knowledge Acquisition and

Representation Language. IEEE Transactions on Knowledge and Data
Engineering, Vol. 10, No 4. July/August 1998. pp. 527-550.
[FBM+99] D. Fensel, R. Benjamins, E. Motta, et al. UPML A Framework for
Knowledge System Reuse. In Proceeding of the International Joint
Conference on AI (IJCAI-99). Stockholm, Sweden. 1999.
[FMB+00] D. Fensel, E. Motta, R. Benjamins, et al. The Unified Problem-Solving
Method Development Language UPML. Draft. The Netherlands. 2000.
58 p. http://www.cs.vu.nl/~dieter/drafts.html
[GAM94] J. Gennari, R. Altman, M. Musen. Reuse with Protégé-II: From Elevators
to Ribosome. Stanford University School of Medicine. 1994. 9 p.
http://smi-web.stanford.edu/pubs/SMI_Reports/SMI-94-0549.pdf
[Gia89] J. Giarretano. Expert Systems: Principles and Programming. Boston:
PWS-Kent Publishing Company, 1989. 632 p.
[GuT94] G. Guida, C. Tasso. Design and Development of Knowledge Based
Systems. England : John Wiley & Sons. 1994. 476 p.
[Guz96] J. Guzmán. Modelo Integrado Hipermedia y Basado en Conocimiento de
Apoyo al Desarrollo de Aplicaciones Informáticas. Tesis de Maestría
Ingeniería de Sistemas. Universidad Nacional de Colombia, Sede
Medellín. Facultad de Minas. Medellín, 1996.
[HaB92] F. V. Harmelen, J. Balder. (ML)2: A formal language for KADS
conceptual models. In Knowledge Acquisition, Vol. 4, no 1, March 1992.
pp. 127-161.
[Har92] A. Hart. Knowledge Acquisition for Expert Systems. 2ª ed. Estados
Unidos; McGraw-Hill, 1992.
[Hen97] M. Henao. Metodología para el Desarrollo de la Tecnología de Sistemas
Intelimedios. Tesis de la Maestría en Gestión de Tecnologías,
Universidad Pontificia Bolivariana, Medellín, Colombia. 1997. 238 p.
[HKL+89] F. Hickman, J. Killin, L. Land, et al. Analysis for Knowledge-Based
Systems: A Practical Guide to the KADS Methodology. Ellis Horwood,
England. 1989. 190 p.

España. 1998. 294 p.
[Kin94] J. Kingston. Linking Knowledge Acquisition with CommonKADS
Knowledge Representation. AIAI-TR-156. 1994. 21 p.
ftp://ftp.aiai.ed.ac.uk/pub/documents/1994/
[McH89] K. McGraw, K. Harbinson-Briggs. Knowledge Acquisition: Principles
and Guidelines. New Jersey: Prentice-Hall, 1989. 166 p.
[MoC95] M. Molina, J. Cuena. Knowledge Oriented Design and Object Oriented
Design: The Experience of KSM. Proc. Of Knowledge Acquisition of
Knowledge Based Systems Workshop, KAW95. Banff, Canada. 1995.
[MOS+95] E. Motta, K. O´Hara, N. Shadbolt, et al. Solving VT in VITAL: A Study
in Model Construction and Knowledge Reuse. In International Journal of
Human-Computer Studies, Special Issue on the VT Elevator Design
Problem. Vol. 44 (3-4). March-April 1996. 34 p.
http://www2.kmi.open.ac.uk/tr/tr.cfm?trnumber=4
[Neu93] S. Neubert. Model Construction in MIKE. Paper in Lecture Notes of
Artificial Intelligence. (N. Aussenac G. Boy B. Gaines M. Linster J.-G.
Ganascia Y. Kodratoff (Eds.) Knowledge Acquisition for Knowledge-
Based Systems, 7th European Workshop, EKAW ’93. Springer-Verlag.
France, 1993. pp. 200-219.
[New82] A. Newell. The Knowledge Level. Artificial Intelligence No. 18. 1982.
pp. 87-127.
[NoM99] N. Noy, M. Musen. Empirical Studies of Knowledge Acquisition. SMI
Colloquim, Stanford, California, USA. 1999. 59 p.
http://smiweb.stanford.edu/projects/protege/talks/EmpiricalEvaluation/ind
ex.htm
[Pri93] J. Priece. A Guide to Usability: Human Factors in Computing. The
United States of America: Addison-Wesley, 1993. 144 p.
[SAA+98] A. Schreiber, J. Akkermans, A. Anjewierden, et al. CommonKADS,
Engineering of Knowledge; The CommonKADS Methodology [version
0.5]. Amsterdam: Department of Social Science Informatics, University
of Amsterdam, 1998. 285 p.
[SAA+00] A. Schreiber, J. Akkermans, A. Anjewierden, et al. Engineering of

Knowledge and Management; The CommonKADS Methodology. The
United States of America, The MIT Press. 2000. 455 p.
[SCG91] C. Scott, J. Clayton, E. Gibson. A Practical Guide to Knowledge
Acquisition. The United States of America: Addison-Wesley, 1991. 509
p.
[SDF+00] R. Studer, S. Decker, D. Fensel, et al. Situation and Perspective of
Knowledge Engineering. In J. Cuena et al. (eds.), Knowledge
Engineering and Agent Technology, IOS Press. 2000. 16 p.
http://www.cs.vu.nl/~dieter/pub2000.htm
[SFD+99] R. Studer, D. Fensel, S. Decker, et al. Knowledge Engineering: Survey
and Future Directions. In F. Puppe et al. (eds.), Lecture Notes in
Artificial Intelligence (LNAI), Springer Verlag. 1999. 23 p.
http://www.cs.vu.nl/~dieter/pub1999.htm
[She90] C. Sheel. Ingeniería de Sistemas Basados en Conocimientos. México:
Instituto Tecnológico y de Estudios Superiores de Monterrey, 1990.
[Ste90] L. Steels. Components of Expertise. AI Magazine. (11) 2. 1990. pp. 29-
49.
[VDS+94] W. Van de Velde, C. Duursma, G. Schreiber et al. Design Model and
Process. ESPRIT Project P5248 KADS-II, KADS-
II/M7/VUB/RR/064/2.1. 1994. 230 p.
[WaG93] A. Waern, S. Gala. The Common KADS Agent Model. Technical Report
ESPRIT Project P5248 KADS-II, KADS-II/M4/TR/SICS/005/V.2.0.
Swedish Institute of Computer Science, Stockholm, 1993. 44 p.
[Wat86] D. Waterman. A Guide to Expert Systems. Addsison-Wesley Publishing
Company. The United States of America. 1986. 419 p.
[WHG+93] A. Waern, K. Höök, R. Gustavsson et al. The Common-KADS
Communication Model. Technical Report ESPRIT Project P5248 KADS-
II, KADS-II/M3/SICS/TR/006/V.2.0. Swedish Institute of Computer
Science, Stockholm, 1993. 96 p.
[WSB92] B. Wielinga, A. Schreiber, J. Breuker. KADS: A Modeling Approach to
Knowledge Engineering. In Knowledge Acquisition Journal, Vol. 4, no
1, March 1992. pp. 5-53.
[WVS+92] B. Wielinga, W. Van de Velde, W. Schreiber, et al. Towards a

Unification of Knowledge Modeling Approaches. Technical Report
ESPRIT Project P5248 KADS-II/ T1.1/TR/UvA/004/4.0, University of
Amsterdam, Free University of Brussels & Netherlands Energy Research
Foundation ECN. 1992.
• Sistemas de tiempo real
[BaS86] T. Baker, G. Scallon. An Architecture for Real-Time Software Systems.

IEEE Software, Vol. 3 Nº 3, 1986. pp. 50-58.
[Ber98] G. Bernat. Specification and Analysis or Weakly Hard Real-Time
Systems. Ph.D. Thesis, Universitat de les llles Baleares. 1998. 174 p.
[BoG98] D. Bourgoyne, J.L. Gresham. Object-Oriented Modeling for Embedded
Print Engine Control. 1998. 11 p.
http://www.objectime.com/
[Boo94] G. Booch. Object-Oriented Analysis and Design with Applications.
Benjamin Commings, California. 1994. 589 p.
[BuW92] A. Burns. A.J. Wellings. Designing Hard Real-Time Systems.
Proceedings 11th Ada Europe conference, Springer-Verlag Lecture Notes
in Computer Science 603, File: adaeurope92_BW.ps.Z 1992. 10 p.
http://dcpu1.cs.york.ac.uk:6666/real-time
[BuW94a] A. Burns. A.J. Wellings. A Design Method for Hard Real-time Systems.
Real-Time Systems. Vol. 6, No. 1, 1994. pp. 73-114.
[BuW94b] A. Burns. A.J. Wellings. HRT-HOOD, A Design Method for Hard Real-
Time Ada. Department of Computer Science, University of York, UK,
File: YCS199.ps.Z . 1994. 44 p.
[Cal97] J.P. Calvez. Specification and Design of Embedded Real-time Systems;
MCSE Methodology. 1997.
http://www.ireste.fr/mcse/htmlan
[Del97] J.A. de la Puente. Diseño de sistemas de tiempo real - Introducción a
HRT-HOOD. Madrid. 1997.
ftp://ftp.dit.upm.es/str/software/mine.tar.gz
[Deu88] M. Deutsch. Focusing Real-Tome Systems Analysis on User Operations.

IEEE Software, Sept. 1988. pp. 39-50
[Dou98] B. P. Douglass. Real-Time UML. Addison-Wesley, United States of
America. 1998. 365 p.
[Dou99] B. P. Douglass. Doing Hard Time; Developing Real-Time Systems with
UML, Objects, Frameworks, and Patterns. Addison-Wesley, United
States of America. 1999. 749 p.
[Dou00] B. P. Douglass. The UML for Systems Engineering. I-Logix Technical
paper, The United States of America. 2000, 12 p.
http://www.ilogix.com/whitepapers_c.htm
[Ell94] J. Ellis. Objectifying Real-Time Systems. Cambridge University Press.
The United States of America. 1994. 542 p.
[Gom84] H. Gomaa. A Software Design Method for Real-Time Systems.
Communications of the ACM, Vol. 27 Nº 9. 1984. pp. 938-949.
[Gom86] H. Gomaa. Software Development of Real-Time Systems.
Communications of the ACM, Vol. 29 Nº 7. 1986. pp. 657-668.
[Gom89] H. Gomaa. Software Design Methods for Real-Time Systems. George
Mason University. USA. 1989. 45 p.
http://www.sei.cmu.edu/publications/documents/cms/cm.022.html
[HaH94] K. Haggerty, L. Haggerty. Introduction to Structured Methods. H&A
Systems Engineering. USA.
http://www.hasys.com/tutorials/index.html
[HaP88] D. Hatley, I. Pirbhai. Strategies for Real-Time System Specification.
New York, Dorset House Publishing. 1988. 386 p.
[Har87] D. Harel. Statecharts: A Visual Formalism for Complex Systems.
Science of Computing Programming 8, 1987. pp. 231-274.
[Hil99] N. Hillary. Bringing the Gap between Requirements and Design with Use
Cases and Scenarios. I-Logix, Inc. – Rhapsody Technical Papers. 11 p.
http://www.ilogix.com/door_paper.htm
[KaY92] K. Kavi, S. Yang. Real-Time Systems Design Methodologies: An
Introduction and a Survey. En: Real-Time Systems; Abstractions,
Languages, and Design Methodologies. USA : IEEE Computer Society
Press, 1992. 660 p.
[Lap92] P. Laplante. Real-Time Systems Design and Analysis; An Engineer’s

Handbook. IEEE Computer Society Press. Los Alamitos, 1992. 339 p.
[Lee92] M. Lee. Object-Oriented Analysis in the Real World. Project
Technology, Inc. San Leandro, California. 1992. 11p.
http://www.projtech.com
[LuB88] Luqi, V. Berzins. Rapidly Prototyping Real-Time Systems. IEEE
Software, Vol. 5 Nº5, Sept 1988. pp. 25-36.
[Mul97] P.A. Muller. Modelado de objetos con UML. Francia, 1997. 381 p.
[OMG99] OMG Unified Modeling Language Specification (draft). Version 1.3 beta
R7. Object Management Group, The United States of America. June
1999. 798 p.
[Pol00] POLIS. A Framework for Hardware-Software Co-Design of Embedded
Systems. Berkeley University. 2000.
http://www-cad.eecs.berkeley.edu/research/hsc/
[Pre98] R. Pressman. Ingeniería del Software; Un Enfoque Práctico. 4 Ed.
España: McGraw-Hill, 1998. 581 p.
[RaH00] J. Rader, L. Haggerty. Supporting Systems Engineering with Methods
and Tools: A Case Study. Hughes Aircrafts and H&A Systems
Engineering. 2000. pp. 1330-1334.
http://www.hasys.com/cases/asilomar.pdf
[Rip98] I. Ripoll. Real-Time Linux (RT-Linux). Revista Linux Focus.
http://www.linuxfocus.org/Castellano/May1998/article4.html
[RTM96] REAL-TIME MANIFESTO.
http://www.realtime-os.com/rtmanifesto/
[San94] J.M. Sanz. IPTES: Tecnología de prototipado incremental para sistemas
de tiempo real empotrados. Especial Tecnología Software Nº 9.
Comunicaciones de Telefónica I+D. Madrid, España. 21 p.
http://www.tid.es/presencia/publicaciones/comsid/esp/articulos/home.ht
ml
[Sel92] B. Selic. Real-Time Object-Oriented Modeling. ObjectTime. Ontario,
Canada. 1992. 27 p.
http://www.objectime.com/otl/technical/
[Sel96a] B. Selic. An Efficient Object-Oriented Variation of the Statecharts

Formalism for Distributed Real-Time Systems. ObjectTime. Ontario,
Canada. 1996. 8 p.
[Sel96b] B. Selic. Periodic Tasks in ROOM. ObjectTime. Ontario, Canada. 1996.
4 p.
[SFR98] M. Saksena, M. Freedman, P. Rodziewicz. Guidelines for Automated
Implementation of Executable Object Oriented Models for Real-Time
Embedded Control Systems. 13 p.
http://citeseer.nj.nec.com/204508
[SGW94] B. Selic, G. Gullekson, P. Ward. Real-Time Object-Oriented Modeling.
John Wiley & Sons. The United States of America. 1994. 507 p.
[ShC94] K. Shere, R. Carlson. A Methodology for Design, Test, and Evaluation or
Real-Time Systems. IEEE Computer. February 1994. pp. 35-48.
[SkG89] D.B. Skillicorn, J.I. Glasgow. Real-Time Specification Using Lucid.
IEEE Transactions on Software Engineering, Vol. 15 Nª 2. 1989. pp.
221-229.
[Sta88] J. Stankovic. Misconceptions About Real-Time Computing. IEEE
Computer, Vol. 21 N. 10, Oct. 1988. pp10-19.
[Sta92] J. Stankovic. Distributed Real-Time Computing: The Next Generation.
MIT, USA: Technical Report 1992-001, 1992. 16 p.
[StR93] J. Stankovic, K. Ramamritham. What is the Predictability for Real-Time
Systems? Advances in Real-Time Systems. Edited by: John A. Stankovic
and Krithi Ramamritham. IEEE Computer Society Press, California.
1993. 777 p.
• Sistema basado en el conocimiento de tiempo real
[AlS85] M. Ali, D. Scharnhorst. Sensor-Based Fault Diagnosis in a Flight Expert

System. In Proceedings of the Second Conference on Artificial
Intelligence Applications. Washington D.C., IEEE Computer Society.
1985. pp. 49-52.
[BBE+82] B. Brown, J. Buckman, R. Engelmore, et al. Communication Intelligence

Task – HANNIBAL Demonstration, Technical Report, ESL, Inc. 1982
[BBO+93] F. Barber, V. Botti, E. Onaindia, A. Crespo. Temporal Reasoning in
REAKT (An Environment for Real-Time Knowledge-Based Systems).
Technical Report. Spain 1993. 16 p.
[CJG+97] C. Carrascosa, V.J. Julián, A. García-Fornes, A. Espinosa. Un lenguaje
para el desarrollo y prototipado rápido de sistemas de tiempo real
inteligentes. Actas de la VII Conferencia de la Asociación Española para
la Inteligencia Artificial. España. 1997. pp. 685-694.
[GaB95] A. García-Fornés, V. Botti. ARTIS: Una Arquitectura para Sistemas de
Tiempo Real Inteligentes. VI Conferencia de la Asociación Española
para la Inteligencia Artificial. 1995. pp. 161-174.
[Gar96] A. García-Fornés. ARTIS: Un modelo y una arquitectura para sistemas
de tiempo real inteligentes. Tesis Doctoral, Universidad Politécnica de
Valencia, España. 1996. 149 p.
[GCB95] A. García-Fornes, A. Crespo, V. Botti. Adding Hard Real-Time Tasks to
Artificial Intelligence Environments. Proc. 20th Workshop on Real-Time
Programming. 1995.
[Hay90] B. Hayes-Roth. Architectural Foundations for Real-Time Performance in
Intelligent Agents. Journal of Real-Time Systems, 2(1/2). 1990. pp. 99-
125
[Hay95] B. Hayes-Roth. An Architecture for Adaptative Intelligent Systems.
Artificial Intelligence, 72. 1995. pp. 329-365.
[HHC90] A. Howe, D. Hart, P. Cohen. Addressing Real-Time Constraints in the
Design of Autonomous Agents. Journal of Real-Time Systems. 2(1/2).
1990. pp. 81-97.
[IGR92] F. Ingrand, M. Georgeff, A. Rao. An Architecture for Real-Time
Reasoning ans System Control. IEEE Expert, 7(6), 1992. pp 34-44.
[KeM94] D. Kersula, A. Mensch. REAKT: A Real-Time Architecture for
Knowledge Based Systems. IFAC Artificial Intelligence in Real-Time
Control. ISBN 84-7721-274-0. 1994. pp. 513-518.
[Laf91] T.J. Laffey. The Real-Time Expert. Byte, Jan. 1991. pp. 259-264.
[LCS+88] T. Laffey, P. Cox, J. Schmidt, et al. Real-Time Knowledge-Based

Systems. AI Magazine. Spring 1988. pp. 27-45.
[MHA94] D. Musliner, J. Hendler, A. Agrawala. The Challenges of Real-Time AI.
University of Maryland, Technical report CS-TR-3290, UMIACS-TR-
94-69, June, 1994. 22 p.
[MHD+95] D. Musliner, J. Hendler, E. Durfee, et al. The Challenges of Real-Time
Artificial Intelligence. Computer IEEE, 28(1). 1995. pp. 58-66.
[MiG92] K. Mills, H. Gomaa. A Knowledge-Based Approach for Automating a
Design Methods for Concurrent and Real-Time Systems. Proceedings of
The SEKE´96, ACM, June 10-12, 1992. pp. 1-8.
[MKC+93] A. Mensch, D. Kersual, A. Crespo, et al. REAKT Architecture.
Workshop on Integration Technology for Real-Time Intelligent Control
Systems. Madrid. 1993.
[Mus93] D. Musliner. CIRCA: The Cooperative Intelligent Real-Time Control
Architecture. Dissertation Research PhD Thesis. The University of
Michigan. 1993. 183 p.
http://www.cs.umd.edu/users/musliner/
[Ona97] E. Onaindía. Modelo de Representación y Razonamiento Temporal para
Sistemas Basados en el Conocimiento de Tiempo Real. Tesis Doctoral,
Universidad Politécnica de Valencia, Valencia. 1997. 162 p.
[Pal99] J. Palma. Ingeniería del Conocimiento en Sistemas para Tiempo Real
Basados en Conocimiento: Una extensión a CommonKADS. Tesis
Doctoral, Universidad de Murcia, España. 1999. 298 p.
[Rea90] REAKT. Environment and Methodology for Real-Time Knowledge-
Based Systems. 1990.
http://apollo.cordis.lu/cordis-cgi/srchidadb.
[Rea93] REAKT EP5146. Knowledge Acquisition report for the SARAS
Demonstrator: semester S5. The Consortium REAKT. 1993. 54 p.
[RLN+91] P. Rosenbloom, J. Laird, A. Newell, et al. A Preliminary Analisys of the
SOAR Architecture as a Basis for General Intelligence. Artificial
Intelligence, 47, 1991. pp 289-325.
[RVK92] M. G. Rodd, H. B. Verbruggen, A. J. Krijgsman. Artificial Intelligence in

Real-Time Control. Engineering Applications Artificial Intelligence. Vol.
5, Nº 5. Great Britain. 1992. pp. 385-399.
[Sta92] J. Stankovic. Advances in Real-Time Systems. California, IEEE
Computer Society Press, 1992. 777 p.
[VHB97] E. Vivancos, L. Hernández, V. Botti. Técnicas y Arquitecturas de
Inteligencia Artificial en Tiempo Real. Madrid. Informática y
Automática. Vol. 30 Núm. 4, Dic. 1997. pp. 5-22.
[VHB98] E. Vivancos, L. Hernández, V. Botti. Construcción y Análisis Temporal
de Sistemas Basados en Reglas para Entornos de Tiempo Real. VII
Conferencia de la Asociación Española de Inteligencia Artificial,
CAEPIA`97, España. 1998. pp. 675-684.
[ViB96] E. Vivancos, V. Botti. Técnicas de Inteligencia Artificial en Tiempo
Real. Reporte Técnico, Universidad Politécnica de Valencia. 1996. 9 p.
[Viv98] E. Vivancos. Incorporación de agentes basados en reglas en una
arquitectura para entornos de tiempo real. Propuesta de Tesis Doctoral,
Universidad Politécnica de Valencia. 1998. 30 p.
• CommonKADS-RT
[BHS99] V. Botti, M. Henao, J. Soler. Método de análisis para modelar sistemas

basados en el conocimiento en tiempo real. Memorias de la VIII
Conferencia de la Asociación Española para la Inteligencia Artificial,
CAEPIA'99. Murcia, España. 1999. pp. 17-25.
[Bot00] V. Botti. Agentes Inteligentes de Tiempo Real: Control Voraz.
Documentos interno DSIC, Universidad Politécnica de Valencia, España.
2000. 65 p.
[DeH98] R. De Hoog. List of Frequency Encounter Project Risks. Technical report
SWI, Social Science Informatics, University of Amsterdam. 1998. 14 p.
[Fip00] FIPA – The Foundation for Intelligent Physical Agents. 2000.
http://www.fipa.org/
[Fip01a] Foundation for Intelligent Physical Agents. FIPA Interaction Protocol

Library Specification. Geneve, Switzerland. Document number
XC00025D. 2001. 24 p. http://www.fipa.org/specs/fipa00025/
[Fip01b] Foundation for Intelligent Physical Agents. FIPA Abstract Architecture
Specifications. Geneve, Switzerland. Document number XC00001. 2001.
62 p. http://www.fipa.org/specs/fipa00001/
[Gar96] A. García-Fornés. ARTIS: Un modelo y una arquitectura para sistemas
de tiempo real inteligentes. Tesis Doctoral, Universidad Politécnica de
Valencia, España. 1996. 149 p.
España. 1998. 294 p.
[JGR+00] V.J. Julián, M. González, M. Rebollo, et al. InSiDE: una herramienta
para el desarrollo de Agentes ARTIS. Simposium Español de Informática
Distribuida. Ourense, España. 2000. pp 79-87.
[Por97] M. Porter. Ventaja competitiva; Creación y sostenimiento de un
desempeño superior. México: Compañía editorial Continental S.A. 1997.
550 p.
[SAA+98] A. Schreiber, J. Akkermans, A. Anjewierden, et al. CommonKADS,
Engineering of Knowledge; The CommonKADS Methodology [version
0.5]. Amsterdam: Department of Social Science Informatics, University
of Amsterdam, 1998. 285 p.
[VDS+94] W. Van de Velde, C. Duursma, G. Schreiber et al. Design Model and
Process. ESPRIT Project P5248 KADS-II, KADS-
II/M7/VUB/RR/064/2.1. 1994. 230 p.
[ViB97] E. Vivancos, V. Botti. Compiling Rule-Based Programas for Real-Time
Environment. ACM-SIGPLAN Wokshop on Languages, Compilers and
Tools for Real-Time Systemas, Las Vegas, United States of America.
1997. pp 77-81.
• Puerto
[BRH00] V. Botti, M. Rebollo, M. Henao. Análisis de los procesos de la Operativa

Marítima. Documento de Trabajo, Análisis001124. Valencia, España.
2000. 16 p.
[Dag89] C. Dagazo. The Crane Scheduling Problem. Transpn. Res. Vol. 23B, Nº
3. Pergamon Press. 1989. pp. 159-175.
[HwY99] K. Hwan, K. Young. An optimal Routing Algorithm for a Transfer Crane
in Port Container Terminals. Transportation Science, Vol. 33, Nº 1.
Institute for Operations Research and Management Sciences. 1999.
[PeD90] R. Peterkofskly, C. Daganzo. A Branch and Bound Solution Method for
the Crane Scheduling Problem. Transpn. Res. Vol. 24B, Nº 3. Pergamon
Press 1990. pp. 159-172.
• Robot
[SHB00] J. Soler, M. Henao, V. Botti. A Mobile Robot Application with an

Analysis Method based on CommonKADS. Proceedings of the IASTED
International Conference: Intelligent Systems and Control (ISC 2000).
Hawaii. 2000. pp. 299-303.
[SAA+00] A. Schreiber, J. Akkermans, A. Anjewierden, et al. Engineering of
Knowledge and Management; The CommonKADS Methodology. The
United States of America, The MIT Press. 2000. 455 p.
CommonKADS-RT – Anexo 1 239
ANEXO 1
Criterios de Filtrado
Criterios para determinar la importancia del sistema basados en el
conocimiento de tiempo real en la Organización
1 ¿Está la gerencia en donde se presenta la raíz del problema, interesada en solucionar

dicho problema?
2 ¿En caso de que se cambie la situación actual, la Organización se ve realmente

beneficiada?
3 ¿La Organización está dispuesta a introducir una tecnología emergente para que se
realice la tarea que se está analizando?
4 ¿La Organización está dispuesta a introducir una tecnología emergente para que haga
parte de su que-hacer diario?
5 ¿Ha evaluado la dirección de la Organización las implicaciones que tiene el introducir

esta tecnología para solucionar el problema planteado?
6 ¿Está interesada la Organización en emprender el desarrollo de un sistema basado en el

7 ¿La Organización está dispuesta a invertir recursos y tiempo para que se desarrolle un
sistema útil, eficiente y efectivo?
8 ¿Ha hecho la Empresa un estudio Costo / beneficios en donde se muestre la

recuperación de la inversión al desarrollar un sistema de este tipo?
9 ¿Si la Organización se divide en niveles estratégicos, tácticos y operativos, en cuál de

ellos estará situado el sistema?
10 ¿La Organización está interesada en registrar el conocimiento que se necesita para

poder dar soluciones a problemas del dominio en tiempos acotados?
11 ¿La Organización comprende las características básicas de un sistema basado en el

Criterios para estimar la complejidad del problema a resolver
12 ¿Tiene la empresa experiencia en el desarrollo de sistemas basados en el

conocimiento?
13 ¿Tiene la empresa experiencia en el desarrollo de sistemas de tiempo real?
14 ¿Tiene un alto grado de dificultad y complejidad el problema a resolver?
15 ¿Se ha planteado algún tipo de solución que no implique la utilización de una

herramienta computacional y que ofrezca algunos beneficios?
16 ¿Hay algunos pasos o secuencia determinadas para solucionar el problema?
17 ¿Se ha evaluado el desarrollo de un sistema de información tradicional en donde se

tenga un proceso algorítmico?
18 ¿El solucionar el problema requiere de conocimientos muy especializados o expertos?
19 ¿En el dominio del problema hay muchas personas que conocen cómo solucionar el
problema?
20 ¿Se puede encontrar el conocimiento del área disperso entre varias personas expertas?
21 ¿El problema está bien definido con datos e información completamente conocidos y
exactos?
22 ¿El problema requiere de datos o información del entorno para su solución?
23 ¿La solución que el sistema provea puede tener conocimiento probabilístico asociado?
24 ¿Se tienen mediciones de tiempos de los procesos que están involucrados en el

problema?
25 ¿Si hay tiempos definidos, se tiene un plan para poderlos cumplir?
26 ¿En caso de no poderse cumplir un plazo o un tiempo, qué ocurriría?
27 ¿El sistema requiere que se tengan disponibles diferentes recursos (periféricos,

dispositivos) para que la información se represente y afecte el entorno?
28 ¿El sistema que se desarrolle como solución requiere de especificaciones de tiempos y

el manejo apropiado de valores temporales para funcionar y actuar?
29 ¿Hay algún tipo de restricción que se deba tener en cuenta cuando se plantee la
solución?
30 ¿Una solución que se vea valiosa actualmente permanecerá vigente durante los
próximos años?
31 ¿La solución del problema está enmarcada en un dominio de aplicación específico del
conocimiento?
32 ¿El área de pericia del humano es crítica y difícil de asimilar?
33 ¿El sistema requiere de conocimientos teóricos para poder solucionar el problema?
34 ¿El sistema requiere de conocimientos prácticos, experiencia en problemas similares

para poder solucionar la situación actual?
Criterios relacionados con los recursos requeridos
35 ¿Está dispuesta la organización en proporcionar todos los recursos, tiempo – dinero –

personas, que se requieren para hacer un análisis completo de la situación actual y
poder así establecer una especificación adecuada?
36 ¿Está dispuesta la organización en proporcionar los recursos, tanto del hardware como
el software y de las personas que se requiere para desarrollar el sistema basado en el
37 ¿La organización cuenta con personal que puede asumir el papel y la responsabilidad
que se han definido como necesarias para poder llevar a cabo un proyecto de este tipo?
38 ¿Las personas pueden formar un equipo de trabajo?
39 ¿Hay dentro de la empresa una persona reconocida que posea una gran influencia o
experiencia en el desarrollo de la tarea?
40 ¿Podría la empresa contratar personas externas que sean idóneas para que participen en
el proyecto?
41 ¿Están las personas disponibles e interesadas en participar en el desarrollo del sistema

basado en el conocimiento de tiempo real?
42 ¿Si no se dispone de un experto en el dominio, se puede solucionar el problema entre

varias de las personas que están involucradas con esa situación?
43 ¿El experto está dispuesto a proporcionar todo el conocimiento para que el sistema
haga su simulación?
44 ¿Tiene el experto facilidad para expresar dichos conocimientos?

TESIS Commonkads

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

TESIS Commonkads

Hochgeladen von

Copyright:

Verfügbare Formate

Universidad Politécnica de Valencia

Departamento de Sistemas Informáticos y Computación

CommonKADS-RT: Una Metodología para el

Mónica Henao Cálad

Valencia, España. Abril de 2.001

Al Doctor Vicente Botti, por su orientación, asesoría y soporte que me permitió

A los miembros del Grupo de Tecnologías Informáticas (GTI) del Departamento de

A los coordinadores del convenio UNAL-UPV y directivas de la UPV quienes

A los integrantes del Departamento de Informática y Sistemas de la Universidad

A las directivas de la Universidad EAFIT por su patrocinio y soporte en la realización

Al postgrado de Sistemas de la Universidad Nacional de Colombia, sede Medellín por

A mi familia y amigos que siempre me animaron y comprendieron todas mis

Estos sistemas se han utilizado para solucionar problemas de control de procesos,

Básicamente las investigaciones en estos sistemas han estado enfocadas hacia su

Esta tesis se centra en el estudio de los sistemas basados en el conocimiento, los

CommonKADS-RT permite seguir, en una forma comprensible y sencilla la

En CommonKADS-RT se plantea que un sistema basado en el conocimiento de

Adicionalmente, las consideraciones metodológicas propuestas en esta tesis, incluyen

Para mostrar la aplicación de la metodología se presenta dos casos reales y diferentes

Como resultado de esta investigación se han realizado las siguientes publicaciones:

BOTTI V. Henao M. Soler J. Método de análisis para modelar sistemas basados en el

HENAO, Mónica. CommonKADS: Una buena herramienta para la gerencia del

SOLER, J. Henao, M. Botti V. A Mobile Robot Application with an Analysis Method

HENAO, M., Soler, J. Botti. La integración de sistemas basados en el conocimiento y

This doctoral thesis is centered in the study of knowledge-based systems, real-time

CommonKADS-RT allows to follow, in a understandable and easy way, the building

CommonKADS-RT proposes a real-time knowledge-based system to be built by

BOTTI V. Henao M. Soler J. Método de análisis para modelar sistemas basados en el

HENAO, Mónica. CommonKADS: Una buena herramienta para la gerencia del

SOLER, J. Henao, M. Botti V. A Mobile Robot Application with an Analysis Method

HENAO, M., Soler, J. Botti. La integración de sistemas basados en el conocimiento y

Aquestos sistemes s’han utilitzat per a resoldre problemes de control de processos,

La tesi es centra en l’estudi dels sistemes basats en el coneixement, els sistemes de

Açò ha servit per a desenvolupar CommonKADS-RT, basada en la metodologia

CommonKADS-RT permet seguir, de forma comprensible i senzilla la construcció

Es fonamenta al desenvolupament evolutiu, l’orientació per riscs i segueix els

En CommonKADS-RT es planteja que un sistema basat en el coneixement de temps

A més a més, les consideracions metodològiques propostes en aquesta tesi, inclouen la

Per a mostrar l’aplicació de la metodologia es presenten dos casos reals i diferents on

En el segon es ressalta la fase de disseny, en particular l’arquitectura del sistema i el

Com a resultat d’aquesta investigació, s’han realitzat les següents publicacions:

BOTTI V. Henao M. Soler J. Método de análisis para modelar sistemas basados en el

HENAO, Mónica. CommonKADS: Una buena herramienta para la gerencia del

SOLER, J. Henao, M. Botti V. A Mobile Robot Application with an Analysis Method

HENAO, M., Soler, J. Botti. La integración de sistemas basados en el conocimiento y

Capítulo 1. Introducción y objetivos 1

1.2 Justificación de la tesis ................................................................ 6

1.4 Descripción breve de la estructuración de esta memoria ........ 10

Capítulo 2. Estado del arte 13

2.2 Los sistemas basados en el conocimiento.................................. 13

2.3 Sistemas de tiempo real............................................................. 51

2.4 Sistemas basados en el conocimiento de tiempo real................ 79

2.5 Conclusiones del estado del arte ............................................... 86

3.2 Justificación de CommonKADS-RT......................................... 91

3.3 Fundamentos de CommonKADS-RT....................................... 92

3.4 Características del dominio que es apropiado para la

3.5 Ciclo de vida de CommonKADS-RT ........................................ 98

3.6 Modelos que integran a CommonKADS-RT.......................... 100

3.7 Conclusiones de CommonKADS-RT...................................... 150

Capítulo 4. Validación experimental de

4.2 Tipos de casos .......................................................................... 151

4.3 Terminal de contenedores en el puerto de Valencia .............. 152

4.4 Robot .................................................................................. 190