Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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.
CommonKADS-RT – Resumen
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)
CommonKADS-RT – Resumen
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
CommonKADS-RT – Resumen
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:
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.
CommonKADS-RT – Resumen
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
CommonKADS-RT – Resumen
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:
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. (pendent de publicar)
CommonKADS-RT – Tabla de contenido
i
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
CommonKADS-RT – Tabla de contenido
ii
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
CommonKADS-RT – Tabla de contenido
iii
4.3 Terminal de contenedores en el puerto de Valencia .............. 152
4.3.1 Modelo de la organización............................................................................. 152
4.3.2 Modelo de tareas de alto nivel ....................................................................... 178
4.3.3 Modelo de agentes ........................................................................................ 180
4.3.4 Modelo de conocimientos.............................................................................. 183
4.4 Robot .................................................................................. 190
4.4.1 Modelo de la organización............................................................................. 190
4.4.2 Modelo de tareas de alto nivel ....................................................................... 194
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
CommonKADS-RT – Índice de figuras
v
Í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
CommonKADS-RT – Índice de figuras
vi
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
CommonKADS-RT – Índice de figuras
vii
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
CommonKADS-RT – Índice de tablas
ix
Í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
CommonKADS-RT – Índice de formularios
xi
Í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
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................................................................................. 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
CommonKADS-RT – Índice de formularios
xii
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
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................................................................... 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
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
CommonKADS-RT – Capítulo 1. Introducción y objetivos
2
la mejor manera. Las metodologías de desarrollo forman parte de las herramientas del orgware, además de muchas políticas y estrategias organizacionales.
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
Sistemas basados en el conocimiento de tiempo real
Sistemas
Basados en el Conocimiento
Sistemas de Tiempo Real
CommonKADS-RT – Capítulo 1. Introducción y objetivos
3
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
CommonKADS-RT – Capítulo 1. Introducción y objetivos
4
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:
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.
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
CommonKADS-RT – Capítulo 1. Introducción y objetivos
5
• 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:
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.
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.
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)
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. Esdecir, que el modelo describe los aspectos importantes del sistema físico, para
su propósito. [OMG99]
CommonKADS-RT – Capítulo 1. Introducción y objetivos
6
• 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?
CommonKADS-RT – Capítulo 1. Introducción y objetivos
7
• ¿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.
CommonKADS-RT – Capítulo 1. Introducción y objetivos
8
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.
CommonKADS-RT – Capítulo 1. Introducción y objetivos
9
• 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
sistemas basados en el conocimiento de tiempo real.
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 conocimiento de tiempo real.
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 conocimiento de tiempo real.
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.
CommonKADS-RT – Capítulo 1. Introducción y objetivos
10
• 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.
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:
Aspectos
metodológicos de Sistemas de
Tiempo Real
Aspectos
metodológicos de Sistemas Basados
en el Conocimiento
Aspectos
metodológicos de Ingeniería del
Software
CommonKADS-RT – Capítulo 1. Introducción y objetivos
11
− 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
CommonKADS-RT – Capítulo 1. Introducción y objetivos
12
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.
CommonKADS-RT – Capítulo 2. Estado del Arte
14
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.
CommonKADS-RT – Capítulo 2. Estado del Arte
15
• 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.
CommonKADS-RT – Capítulo 2. Estado del Arte
16
− 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.
CommonKADS-RT – Capítulo 2. Estado del Arte
17
• 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
CommonKADS-RT – Capítulo 2. Estado del Arte
18
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.
CommonKADS-RT – Capítulo 2. Estado del Arte
19
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:
CommonKADS-RT – Capítulo 2. Estado del Arte
20
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
CommonKADS-RT – Capítulo 2. Estado del Arte
21
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.
CommonKADS-RT – Capítulo 2. Estado del Arte
22
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
CommonKADS-RT – Capítulo 2. Estado del Arte
23
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.
CommonKADS-RT – Capítulo 2. Estado del Arte
24
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.
CommonKADS-RT – Capítulo 2. Estado del Arte
25
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
CommonKADS-RT – Capítulo 2. Estado del Arte
26
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.
CommonKADS-RT – Capítulo 2. Estado del Arte
27
− 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
CommonKADS-RT – Capítulo 2. Estado del Arte
28
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.
CommonKADS-RT – Capítulo 2. Estado del Arte
29
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.
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
Análisis de
la Tarea
Ingeniería del Conocimiento
Adquisición del Conocimiento Diseño Implementación Mantenimiento
Análisis de
Requerimientos Construcción del
Modelo
Evaluación
del Modelo
Construcción del Modelo
Evaluación
del Modelo
Elicitación Interpretación Formalización / Operacionalización
CommonKADS-RT – Capítulo 2. Estado del Arte
30
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
CommonKADS-RT – Capítulo 2. Estado del Arte
31
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.
CommonKADS-RT – Capítulo 2. Estado del Arte
32
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
CommonKADS-RT – Capítulo 2. Estado del Arte
33
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.
CommonKADS-RT – Capítulo 2. Estado del Arte
34
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.
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.
Base de conocimientos, Razonamiento
interfaz
Cómo se
relacionan Con qué
Qué saben
Quiénes Qué
Modelo de la Organización
Modelo de
Agentes Modelo de
Tareas
Modelo de Conocimientos
Modelo de Comunicaciones
Modelo del Diseño
CommonKADS-RT – Capítulo 2. Estado del Arte
35
− 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
CommonKADS-RT – Capítulo 2. Estado del Arte
36
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.
Figura 2-3 Modelo de la organización de CommonKADS
Modelo de Tareas
Contexto
Organizacional
Problema
actual Problemas y
oportunidades
pertenece
a
situado en
Soluciones
mejorados por
realizadas por
Agente
Modelo
de Agentes
Estructura y
organización
Personas -Roles-
tiene posiciones en
Cultura y
poder
derivado de mantienen
Conocimiento
aplicado
por posee
Recursos computacio.
aplicado
por
puede
ser
puede ser
derivado
de
Proceso Otros recursos
Función
requiere
realizada por usados
en
realizada en
Tarea
define
sirve
parte de
respaldadas por se refiere a se refiere a
CommonKADS-RT – Capítulo 2. Estado del Arte
37
• 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.
CommonKADS-RT – Capítulo 2. Estado del Arte
38
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.
Figura 2-4 Modelo de tareas de CommonKADS
define realizadas por
Tarea
Modelo de Conocimiento
Característica tiene
Agente
especificada
por
Función
Modelo de la Organización
Tarea
sirve
Otro
subsistema
implementada por
Subsistema
SBC
implementada
por
Modelo de Diseño
Entorno
realizadas en
Ingrediente
salida entrada
Capacidades
requiere
Modelo de Agentes
ejecutada
por Transacción
Modelo de Comunicación
Elemento de
información
tiene
especificado
en
recibe
suministra
CommonKADS-RT – Capítulo 2. Estado del Arte
39
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]:
CommonKADS-RT – Capítulo 2. Estado del Arte
40
− 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.
CommonKADS-RT – Capítulo 2. Estado del Arte
41
− 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.
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
participa
en
Transacción
Modelo de Comunicación
Recursos es un
Conocimiento
de aplicación
Restricciones
Agente
tiene
Capacidades tiene
Capacidades de
Razonamiento
tiene
Modelo del Conocimiento
descrito por
Tarea
Modelo de Tareas
Ingrediente
ejecuta
recibe
Conocimiento
estratégico
inicia
suministra
Soluciones
Modelo de la Organización
Personal
efectuadas por
puede
ser
CommonKADS-RT – Capítulo 2. Estado del Arte
42
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.
Figura 2-6 Jerarquía del modelo de conocimientos de CommonKADS
Categoría del Dominio
Categoría de
Inferencia
Categoría de
la Tarea
Esquemas del Dominio
Modelo del Dominio
Inferencia
Roles del Conocimiento
Funciones de
Transferencia
Estrategias Metas
Conceptos Relaciones
Esquema
de Reglas Roles Dinámicos
Roles Estáticos
Categoría del Conocimiento
CommonKADS-RT – Capítulo 2. Estado del Arte
43
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.
CommonKADS-RT – Capítulo 2. Estado del Arte
44
− 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.
Figura 2-7 Modelo de comunicaciones de CommonKADS
participa
en
Transacción
Modelo de Tareas
Agente
participa
en
Artículos de
Información
Transacción
realizada por Capacidades requiere
Plan de
Comunicación
es parte de
Modelo del Conocimiento
realizadas por
Modelo de Diseño
Subsistema de
interacción
Funciones de
Modelo de la Agentes
inicia
Discurso
consiste
de
implementado
por
CommonKADS-RT – Capítulo 2. Estado del Arte
45
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:
Figura 2-8 Pasos del diseño del sistema
Paso 1 Paso 2 Paso 3 Paso 4
Diseño
Arquitectura
Especificac. plataforma
Hw/Sw
Especificac. detallada de
la arquitectura
Diseño
detallado
aplicación
Arquitectura de
referencia de
CommonKADS
Lista de
entornos disponibles
Lista de chequeo
de decisiones de la
arquitectura
Relaciones prefijadas a la
arquitectura
Conocimiento de soporte dado por CommonKADS
CommonKADS-RT – Capítulo 2. Estado del Arte
46
− 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.
CommonKADS-RT – Capítulo 2. Estado del Arte
47
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.
CommonKADS-RT – Capítulo 2. Estado del Arte
48
• 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.
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:
- Posición y propósito
del ciclo dentro del plan
del proyecto
- Objetivos del ciclo y bosquejo del plan
- Restricciones, alternativas consideradas, elecciones tomadas para
el ciclo
- Resumen de la salida del ciclo
anterior, definiendo el punto de
inicio del ciclo actual
- Lista y explicación de los riesgos identificados - Valoración de los riesgos de acuerdo
con el formulario PM-2
- Conclusiones resultantes para el plan
del ciclo y enfoque de desarrollo
- Reportes periódicos delos progresos
- Revisión de las conclusiones de los resultados actuales medidos contra los proyectos de progresoso esperados, como una entrada para el siguiente
ciclo
- Registro de las reuniones de
evaluación y aceptación de las salidas del ciclo
- Salidas del ciclo basadas en los estados de los modelos PM-1.
- Plan del ciclo, haciendo desglose
detallado de las tareas, la asignación
de recursos, salidas del ciclo, valoración de riesgos y detalles del
plan completo del proyecto
- Descripción de loscriterios de aceptación
sobre los cuales seevaluarán las salidas
planeadas del cicloPlan Riesgo
Seguimiento Revisión
CommonKADS-RT – Capítulo 2. Estado del Arte
49
• 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.
CommonKADS-RT – Capítulo 2. Estado del Arte
50
• 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.
CommonKADS-RT – Capítulo 2. Estado del Arte
51
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
CommonKADS-RT – Capítulo 2. Estado del Arte
52
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.
CommonKADS-RT – Capítulo 2. Estado del Arte
53
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:
CommonKADS-RT – Capítulo 2. Estado del Arte
54
• 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.
CommonKADS-RT – Capítulo 2. Estado del Arte
55
− 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.
CommonKADS-RT – Capítulo 2. Estado del Arte
56
− 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.
CommonKADS-RT – Capítulo 2. Estado del Arte
57
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
CommonKADS-RT – Capítulo 2. Estado del Arte
58
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.
CommonKADS-RT – Capítulo 2. Estado del Arte
59
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
subsistemas, a módulos, a componentes) − Es top-down.
− Especifica los requerimientos en un nivel apropiado
− Representa una cantidad manejable de información
en cada momento
− Representación gráfica y textual de la
funcionalidad
− Claramente muestra las interfaces (funcional y
física) − Los gráficos representan los aspectos abstractos del
sistema
− El texto define los detalles − Asignación de funciones a entidades
físicas − Mejora la consistencia de la interfaz
CommonKADS-RT – Capítulo 2. Estado del Arte
60
− 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:
Figura 2-10 Elementos nuevos del Diagrama de Flujo
Flujo de datos
Elemento de control
Proceso de datos
Proceso de control
Almacén de datos Almacén de control
CommonKADS-RT – Capítulo 2. Estado del Arte
61
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.
Figura 2-11 Modelado de un respirador artificial
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.
Comparación
de valores
Interfaz de
monitoreo de
pacientes
Procesar orden de
modificación
Indicador de inicio
de acción
Activación
de alarma
Procedimiento de
regulación de
concentración de O2
Pila/Buffer con valores
Estado del sensor
Datos sensados
Ajuste de
control de
O2
Órdenes de modificación
Órdenes del respirador
Botón de
comando del médico
Monitorización y graduación del
nivel de O2
Valor de O2
asignado
Valor sen- sado de O2
Reducción del nivel de O2
CommonKADS-RT – Capítulo 2. Estado del Arte
62
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:
CommonKADS-RT – Capítulo 2. Estado del Arte
63
• 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:
CommonKADS-RT – Capítulo 2. Estado del Arte
64
− 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.
CommonKADS-RT – Capítulo 2. Estado del Arte
65
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
CommonKADS-RT – Capítulo 2. Estado del Arte
66
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.
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:
Especificación de los
requerimientos
Modelado de la solución
Desarrollo de una simulación
Implementación
CommonKADS-RT – Capítulo 2. Estado del Arte
67
− 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.
CommonKADS-RT – Capítulo 2. Estado del Arte
68
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.
Figura 2-14 MCSE
El proceso de desarrollo del sistema que se sigue en este método es el siguiente:
Necesidad Producto
CONFORMIDAD
Especificación
Diseño Funcional
Especificación
implementación
Aceptación
Validación
Implementación
hardware
Integración
Implementación
software
PRUEBA
VERIFICACIÓN
VALIDACIÓN
Especificación
Diseño
Validación
Implementación
CommonKADS-RT – Capítulo 2. Estado del Arte
69
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.
CommonKADS-RT – Capítulo 2. Estado del Arte
70
− 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
CommonKADS-RT – Capítulo 2. Estado del Arte
71
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:
CommonKADS-RT – Capítulo 2. Estado del Arte
72
• 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).
CommonKADS-RT – Capítulo 2. Estado del Arte
73
• 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.
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
Catálogo de Teléfonos
Validación
del estado
Poner orden
Llenar orden
Cliente
Vendedor
Empleado de transporte
CommonKADS-RT – Capítulo 2. Estado del Arte
74
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á.
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.
< 10 seg.
< 1 seg.
tono sonando
d: enruta
b: escuchar tono
a: levantar auricular
llamador intercambio receptor
c: marcar dígito
suena el teléfono
contesta llamada
tono para
para de sonar
CommonKADS-RT – Capítulo 2. Estado del Arte
75
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].
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.
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.
después (15 seg) después (15 seg) marcar dígito(n)
[incompleto]
Timeout
OK/mostrar mensaje
Marcando
TonoDial
OK/poner tono
marcar dígito(n)
[costo>=50]
[costo<50] Calcular costo
total
Obtener autorización
Cargar a la
cuenta del
CommonKADS-RT – Capítulo 2. Estado del Arte
76
• 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.
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.
Figura 2-20 Apartes de un diagrama de despliegue en UML
Asignación
Actualización
Scheduler
Planificador
GUI
AdminServer:HostMachine
:Scheduler
<<baseDatos>>
BDreuniones
Asignaciones
CommonKADS-RT – Capítulo 2. Estado del Arte
77
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:
CommonKADS-RT – Capítulo 2. Estado del Arte
78
− 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.
CommonKADS-RT – Capítulo 2. Estado del Arte
79
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
CommonKADS-RT – Capítulo 2. Estado del Arte
80
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
CommonKADS-RT – Capítulo 2. Estado del Arte
81
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.
CommonKADS-RT – Capítulo 2. Estado del Arte
82
• 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 conocimiento de tiempo real
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
CommonKADS-RT – Capítulo 2. Estado del Arte
83
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.
CommonKADS-RT – Capítulo 2. Estado del Arte
84
• 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 conocimiento de tiempo real
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.
CommonKADS-RT – Capítulo 2. Estado del Arte
85
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
CommonKADS-RT – Capítulo 2. Estado del Arte
86
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
CommonKADS-RT – Capítulo 2. Estado del Arte
87
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
CommonKADS-RT – Capítulo 2. Estado del Arte
88
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.
CommonKADS-RT – Capítulo 2. Estado del Arte
89
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
CommonKADS-RT – Capítulo 3. CommonKADS-RT
92
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.
CommonKADS-RT – Capítulo 3. CommonKADS-RT
93
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
CommonKADS-RT – Capítulo 3. CommonKADS-RT
94
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.
CommonKADS-RT – Capítulo 3. CommonKADS-RT
95
• 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.
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
Base de conocimientos, restricciones temporales,
Razonamiento
interfaz
Características de Hardware
y Software
Cómo se relacionan Con qué
Qué saben
Quiénes
Qué
Modelo de la Organización
Modelo de Agentes
Modelo de
Tareas de Alto Nivel
Modelo de Conocimientos
Modelo de Comunicaciones
Modelo de Tareas de
Tiempo Real
Modelo del Diseño
CommonKADS-RT – Capítulo 3. CommonKADS-RT
96
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-RT – Capítulo 3. CommonKADS-RT
97
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.
CommonKADS-RT – Capítulo 3. CommonKADS-RT
98
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).
CommonKADS-RT – Capítulo 3. CommonKADS-RT
99
• 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.
CommonKADS-RT – Capítulo 3. CommonKADS-RT
100
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.
Figura 3-2 Ciclo de Desarrollo en CommonKADS-RT
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
Viabilidad
Formalización
Análisis Diseño
Detallado
Construcción
Test de
Planificabilidad
Integración del Sistema
Evolución a largo
plazo
cumplir
Si
No
Ciclo de
Desarrollo
CommonKADS-RT – Capítulo 3. CommonKADS-RT
101
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.
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 de la
Organiza-ción
Modelo de TAN
Modelo de
Agentes
Modelo de Conoci-mientos
Modelo de Comunicacio-
nes
Modelo de
Diseño
Modelo de TTR
Viabilidad X
Análisis X X X X X
Fornalización X X X
Diseño Detallado
X X
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
<<systemModel>>
Organización
Tareas de Alto
Nivel
Conocimiento
Comunicaciones
Agentes
Diseño
Tareas de
Tiempo Real
CommonKADS-RT – Capítulo 3. CommonKADS-RT
102
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.
CommonKADS-RT – Capítulo 3. CommonKADS-RT
103
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,
CommonKADS-RT – Capítulo 3. CommonKADS-RT
104
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 conocimiento con el factor
tiempo como determinante en la realización del proceso
De la lista anterior, elegir realmente los que son intensivos en conocimientos y con tiempos asociados a la toma de decisiones, para
clasificarlos de acuerdo con unas prioridades establecidas en la 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
prioridad asociada
Priorizar o valorar cada uno de los problemas identificados como
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
CommonKADS-RT – Capítulo 3. CommonKADS-RT
105
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 Organización
Aspectos Variantes 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 asociada
Tomada de OM-1 y que indica qué tan significativo es el problema. Si no se ha definido previamente, entonces hacerlo en este momento.
Restricciones Temporales
Identificar algunos conceptos temporales que pueden involucrarse en el problema 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
CommonKADS-RT – Capítulo 3. CommonKADS-RT
106
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.
es_proveedor_de
ARMADOR MARÍTIMA
VALENCIANA
CommonKADS-RT – Capítulo 3. CommonKADS-RT
107
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.
Modelo de la Organización
Proceso de Descomposición Hoja de Trabajo OM-3
Identifica. de la TAN
Nombre de la TAN
Objetivo de la TAN
Tipo de TAN
¿Ejecutada por y en dónde?
Importancia de la TAN
para el proceso
¿Intensiva en conocimiento?
Conocimiento involucrado
¿Tiene restric-ciones
temporales?
¿Es posible introducir un sistema
informático en la
TAN?
Identifica-dor. Se recomien-da que sea un nombre Nemotéc-nico
Nombre
de alguna
de las parte del proceso
en OM-2
Describir
la meta o el objetivo que se
pretende alcanzar al realizar la TAN
En CommonKADS
se han planteado una serie de tareas que pueden servir para
determinar si lo que se está estudiando corresponde a alguna de ellas para hacer
una reutilización de lo allí planteado y optimizar el tiempo
del análisis. Ver anexo 1.
Agente: El agente puede
ser de diferentes tipos: - un actor que es una persona que interactúa
directamente con la situación. - un software que proporciona datos al proceso a través de señales (por ejemplo un sensor). Este puede ser un emisor o
un actuador que recibe o opera sobre el entorno con los productos del proceso.
Indica qué tan
importante es la TAN para
el proceso. Siempre debe ser una respuesta justificada
¿La TAN es intensiva en
conocimientos?
(Alto, Medio,
Bajo) *
Lista de los recursos de
conocimiento
usados en la
TAN
¿Cuáles son
las medidas de tiempo o especificaciones temporales asociadas a la ejecución
de la TAN?
Definir si es posible
implantar un sistema informático para que realice algunas o todas
las actividades de la TAN. Además, especificar qué tipo de sistema informático
(por ejemplo, un sistema tradicional de base de datos o un
SBC o un SBCTR, entre otros)
CommonKADS-RT – Capítulo 3. CommonKADS-RT
108
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.
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 Organización
Capital (Activo) Conocimiento Hoja de Trabajo OM-4
Activo Conocimiento
Poseído por:
Usado en TAN:
¿Forma correcta?
¿Lugar correcto?
¿Tiempo correcto?
¿Calidad correcta?
Nombre
(hoja
OM-3)
Agente
(hoja
OM-3)
TAN (hoja OM-3)
(Si o No; comentario)
(Si o No; comentario)
(Si o No; comentario)
(Si o No; comentario)
… … … … … … …
Formulario 3-4 OM-4: Descripción del componente de conocimiento del modelo de la
organización
Rol-4
Rol-3
Rol-2
Rol-1
Rol-1
Rol-1
TAN-2
TAN-3
TAN-4
TAN-nTAN-1
CommonKADS-RT – Capítulo 3. CommonKADS-RT
109
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.
Modelo de la Organización
Aspectos Variantes Hoja de Trabajo OM-5
Estructura una vez se tenga el SBCTR
De acuerdo con la estructura definida en OM-2, especificar los departamentos, grupos, unidades, en donde estará implantado el SBCTR.
Nombre de la TAN en donde estará el SBCTR
De OM-3 y OM-4
Esquema del Proceso automatizado
Ubicación y relación del SBCTR con la situación actual (situación que no tiene aún el SBCTR). Es decir, hacer un diagrama de contexto para el SBCTR y si es 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 pueden participar
en el desarrollo del SBCTR
Indicar las personas que van a participar en el desarrollo del SBCTR, en su mantenimiento y en el soporte del mismo. Obviamente, definiendo cuál será
específicamente su rol en el proyecto: como usuarios del sistema, como expertos 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
aplicación del SBCTR
Definir el conocimiento o las actividades que el SBCTR no puede realizar, bien
porque no se cuenta con los recursos tecnológicos o porque no es conveniente que realice dichas cosas. Es importante decir por qué esa situación.
Restricciones
Temporales
Determinar, en términos generales cómo se hará el manejo o cumplimiento de
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.
CommonKADS-RT – Capítulo 3. CommonKADS-RT
110
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.
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
datos
conocimiento
Actor 1
SBCTR información
Actor 2
Estímulos Respuestas
datos información
CommonKADS-RT – Capítulo 3. CommonKADS-RT
111
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 ue lo produce
Acciones del SBCTR
Tipo de evento según su llegada
Plazo Máximo
1 Nombre o identificador del evento
Nombre o identificador del agente o del actor que origina el evento
Qué hace el SBCTR con el evento.
Clasificar el evento como periódico o esporádico.
Cuál es el tiempo que el SBCTR tiene para producir una
respuesta apropiada y oportuna a dicho 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 Organización
Lista de Chequeo para el documento de la viabilidad de la decisión. Hoja de Trabajo OM-6
Viabilidad del negocio
Para un área o problema dado y una solución sugerida, las siguientes preguntas tienen
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
CommonKADS-RT – Capítulo 3. CommonKADS-RT
112
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 proyecto
Para un área o problema dada y una solución sugerida, las siguientes preguntas tienen
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 propuestas
Esta es la parte del documento que está directamente relacionada con la gerencia y la
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
CommonKADS-RT – Capítulo 3. CommonKADS-RT
113
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
CommonKADS-RT – Capítulo 3. CommonKADS-RT
114
Figura 3-8 Modelo de la organización de CommonKADS-RT
Organización
debilidades fortalezas amenazas oportunidades
Lista de problemas + lista de estrategias + Contexto organizacional
problemas y estrategias intensivas en
conocimientos y tiempo real
priorización
Lista de posibles SBCTR (ordenados por prioridades)
Problema elegido Estructura
de la
organización
Proceso
asociado al problema
Personas que
participan en el proceso
Conocimiento
Recursos Prioridad
Restricciones
Cultura
y poder
Impacto
TAN del proceso
Identificador
Nombre
Tipo
Intensivo en
Agente
Localización
Importancia
¿Sist. Inf.?
Conocimiento
Restricciones temporales
Activo Conocimiento
SBCTR Propuesto
Ubicación del SBCTR
Esquema del proceso
automatizado
Personas que
participan
Conocimiento
Recursos Restricciones del
Restricciones Cultura
y poder
Impacto
De OM-1, OM-2, OM-3, OM-4, OM-5
Viabilidad
- Viabilidad del Negocio
- Viabilidad técnica
- Viabilidad del proyecto
- Acciones propuestas
OM-1
OM-2
OM-3
OM-4
OM-5
OM-6
CommonKADS-RT – Capítulo 3. CommonKADS-RT
115
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:
TAN1 � Atención
TAN2 � Scheduling
TAN3 � Planificación
TAN4 � Operativa Marítima
TAN5 � Despacho
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:
TAN2,1 � Identificación de requerimientos y situación actual TAN2,2 � Asignación de recursos
TAN2,3 � Adecuación de los demás servicios que están en el Muelle.
CommonKADS-RT – Capítulo 3. CommonKADS-RT
116
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
Organización
(Como en OM-3) Indica el proceso de negocio del cual la TAN es parte, y en
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
1. TAN
predecesoras 2. TAN que la
siguen
3. TAN concurrentes
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: Otras TAN ejecutadas antes que la TAN y que le proporcionan
entradas a ella. TAN ejecutadas después de ésta y que usan alguna(s) de su(s) salida(s) TAN que pueden hacerse en forma simultánea
Objetos manejados en la TAN
1. Objetos de
entrada
2. Objetos de
Los objetos, incluyendo los elementos de datos, información, eventos y de conocimiento que constituyen la entrada de la
TAN. Los objetos, incluyendo la información que entrega la TAN
CommonKADS-RT – Capítulo 3. CommonKADS-RT
117
salida
3. Objetos internos
como salida. Objetos importantes (si los hay), incluyendo los datos, la
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, duración
2. Tiempo límite 3. Periodicidad
4. Control
5. Restricciones
Cada cuánto tiempo se ejecuta la TAN, cuánto tiempo consume
normalmente. Cuál es el tiempo máximo definido para que se realice la TAN, si es que lo tiene. ¿La TAN se realiza en forma periódica o no?
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ó 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: las personas, y los recursos de
sistemas; de OM-3: el ejecutado por)
Los miembros de la empresa (Como en OM-2.1-2.2/3, personas), los sistemas informáticos y los periféricos o
dispositivos (como en OM-2.1, OM-2.2 y OM-3, recursos) que son responsables de realizar la TAN.
Conocimiento y
Habilidades (Como en OM-4) Las habilidades y capacidades necesarias para ejecutar
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
OM-2) Descripción de los recursos consumidos o utilizados en la TAN
(personas, sistemas y equipos, materiales, presupuesto
financiero). También sería importante cuantificar dichos recursos en cuanto a su valor.
Calidad y
Rendimiento
Medidas Lista de las medidas de calidad y de rendimiento (eficiencia) 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.
CommonKADS-RT – Capítulo 3. CommonKADS-RT
118
− 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: Poseído por: Usado en: Dominio:
Elemento de Conocimiento
Agente
Nombre e identificador de la TAN
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
CommonKADS-RT – Capítulo 3. CommonKADS-RT
119
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 Alto Nivel
Descripción de estímulos y respuestas de la TAN Hoja de Trabajo TM-3
Estímulo, puede ser un
evento de entrada de datos o un evento de control y los estados
actuales del sistema completo
Nombre del Escenario, nombre del proceso de la TAN que se ve afectado por el evento
Respuesta, puede ser un evento de salida de
datos (información) o de control resultante y los estados modificados del sistema
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.
CommonKADS-RT – Capítulo 3. CommonKADS-RT
120
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:
CommonKADS-RT – Capítulo 3. CommonKADS-RT
121
• 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
Organización
Indica cómo se ubica el agente en la organización, igual que lo que se definió
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) TAN
Lista de nombres e identificadores de TAN en donde participa el agente (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 temporales
En caso de que el agente tenga que realizar la TAN en un plazo máximo o 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
CommonKADS-RT – Capítulo 3. CommonKADS-RT
122
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
Restricciones Lista de responsabilidades que el agente tiene en la ejecución de la TAN, y de
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 lo produce
Acciones del Sistema
Tipo de evento según su llegada
deadline
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
CommonKADS-RT – Capítulo 3. CommonKADS-RT
123
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 lo produce
Acciones del Sistema Tipo de evento según su llegada
deadline
1 Llamada
de
ascensor
Pasajero
potencial a. Encender botón
b. Poner solicitud en
lista de espera
c. Enviar el ascensor seleccionado al piso
Esporádico a. Encender 2 s. b. 1 s.
c. 5 s. X # pisos
2 Solicitud
piso
Pasajero d. Encender botón
e. Enviar ascensor al piso
Esporádico d. 0.5 s. e. 5 s. X # pisos
3 Presión
botón para
abrir
Pasajero f. Puerta empieza a
abrirse, se inicia el contador de tiempo de
cierre de puerta
Esporádico f. 0.5 s.
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
Pasajero
potencial está en
el piso 1
Solicitud subir elevador
Enciende luz de
llamado
Desciende hasta
piso 1
Puerta se abre Ascensor llega al piso 1
Pasajero
potencial pasa a
ser Pasajero
Pasajero Ascensor
Solicitud piso 3
Enciende
indicador de
piso
Sube hasta
el piso 3
Puerta se abre
Ascensor llega al piso 3
Pasajero se baja
Ascensor queda
en espera de una
solicitud
CommonKADS-RT – Capítulo 3. CommonKADS-RT
124
b)
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.
Pasajero Ascensor
Pasajero
potencial está en
el piso 1
Pulsa botón de
llamado
Enciende luz de
llamado
Cola solicitudes
Apaga luz de
llamado Ascensor llega al piso 1
Pasajero
potencial pasa a
ser Pasajero
Ascensor está en
el piso 5
2 seg.
Puerta se abre
Fin de tiempo de
puerta y cierra
Pasajero Ascensor
Solicitud piso 3
Enciende
indicador de
piso 3
Sube hasta el piso 3
t=5 seg. X 2
pisos
Enciende luz de
llamado
Ascensor llega al piso 3
Pasajero se baja
Ascensor queda
en espera de una
solicitud
Apaga indicador del piso 3
Puerta se abre
Fin de tiempo de
puerta y cierra
3 seg.
CommonKADS-RT – Capítulo 3. CommonKADS-RT
125
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
<<uses>>
<<uses>>
Jefe de
Planificación
Barco
Solicitud de
servicios
Planeación de
actividades
Asignación de
recursos
Orden de
carga
CommonKADS-RT – Capítulo 3. CommonKADS-RT
126
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.
CommonKADS-RT – Capítulo 3. CommonKADS-RT
127
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 Conocimientos usadas
Lista de todas las fuentes de información acerca del dominio de la 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 Conocimientos utilizadas
Lista de las personas que proporcionarán o proporcionaron el 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
CommonKADS-RT – Capítulo 3. CommonKADS-RT
128
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:
CommonKADS-RT – Capítulo 3. CommonKADS-RT
129
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 */
CommonKADS-RT – Capítulo 3. CommonKADS-RT
130
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.
CommonKADS-RT – Capítulo 3. CommonKADS-RT
131
• 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.
CommonKADS-RT – Capítulo 3. CommonKADS-RT
132
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.
CommonKADS-RT – Capítulo 3. CommonKADS-RT
133
3.6.5.1 Formularios del modelo de comunicaciones
• CM-1: Descripción de las transacciones del SBCTR
Modelo de Comunicaciones
Descripción de transacción Hoja de Trabajo CM-1
Nombre / Identificador de la
transacción
Una transacción es definida para cada objeto de información que es 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 intercambio de información
Las transacciones pueden tener una estructura interna que consiste de varios 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 Comunicación
Especificación del intercambio de información Hoja de Trabajo CM-2
Nombre / Identificador de
la transacción
Dar el identificador y nombre de 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.
CommonKADS-RT – Capítulo 3. CommonKADS-RT
134
Especificación de
Mensajes Describir todos los mensajes que forman la transacción. Por cada uno se debe
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 mensajes
Dar, si es necesario, una especificación del control sobre los mensajes dentro de
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.
CommonKADS-RT – Capítulo 3. CommonKADS-RT
135
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:
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.
Percepción Cognición Acción
CommonKADS-RT – Capítulo 3. CommonKADS-RT
136
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
ENTORNO
Tareas de
percepción
Tareas actuadoras
Tareas inteligentes
PLANIFICADOR DE TAREAS
CommonKADS-RT – Capítulo 3. CommonKADS-RT
137
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
tablas Descripción de las bases de datos y tablas de configuración que se requieren en el 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
CommonKADS-RT – Capítulo 3. CommonKADS-RT
138
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.
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.
MicrocontroladorSiemens 88C166
VDC
Aplicación ARTIS
Componente de la interfaz de usuario
Componente de comunicación
Componente de control inteligente
Robot
Sensores
Motor
Batería
Componente de planificación
RS232 C
Radio Ethernet
Señal cable
VDC
CommonKADS-RT – Capítulo 3. CommonKADS-RT
139
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:
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
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
CommonKADS-RT – Capítulo 3. CommonKADS-RT
140
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.
CommonKADS-RT – Capítulo 3. CommonKADS-RT
141
• 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.
CommonKADS-RT – Capítulo 3. CommonKADS-RT
142
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 arquitectura
Descripción de los conceptos y características más relevantes de la 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 procesadores
Número y tipos de 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 subsistema
Hace referencia a los diagramas en los cuales los subsistemas están siendo
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 Hoja de Trabajo DM-2
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 dispositivos sensores y actuadores
Qué tipo de comunicación maneja el SBCTR con su entorno. 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?
CommonKADS-RT – Capítulo 3. CommonKADS-RT
143
¿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 Hoja de Trabajo DM-3
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 tiempo real
¿Cuál es la estructura de la tarea de tiempo real? ¿La TTR es crítica? ¿Qué ocurre si no se cumplen las restricciones temporales de la TTR?
Eventos externos e internos
¿Cómo se manejan los eventos internos del SBCTR? ¿Cómo se manejan los eventos externos?
Métodos para hacer la planificación de las TTR
Especificar la política de planificación de las tareas del SBCTR.
Determinación de los wcet
Para las TTR especificar sus wcet – worst computer execution time
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 Hoja de Trabajo DM-4
Elemento de la Arquitectura
Decisión del Diseño
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
CommonKADS-RT – Capítulo 3. CommonKADS-RT
144
Protocolos de comunicación
Escoger los métodos o lenguajes de comunicación entre el SBCTR y los 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.
CommonKADS-RT – Capítulo 3. CommonKADS-RT
145
− 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.
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.
Tarea de
Tiempo Real
período
deadline
wcet
TAN
Modelo de TAN
realizada en
Tipo TTR
tiene
Agente
Modelo de Agentes
ejecutada por
Parte_inicial
Parte_opcional
Parte_final
Es parte de
Es parte de
Es parte de
Diseño
detallado Modelo de Diseño
hace parte
de
Transacción
Modelo de
Comunicaciones
implementa
Arquitectura
implementada en
Modelo de
Conocimiento
Modelo de Conocimientos
implementa
CommonKADS-RT – Capítulo 3. CommonKADS-RT
146
− 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.
CommonKADS-RT – Capítulo 3. CommonKADS-RT
147
• 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.
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
Componente
percepción
Son MKS de
percepción
Componente
cognición
Son MKS de
razonamiento y
resolución de
problemas
Componente
acción
Son MKS
actuadores
CommonKADS-RT – Capítulo 3. CommonKADS-RT
148
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.
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)
MKS
percepción
KS0
MKS1
cognición
KS0
KS1
KS2
MKS acción
KS0
MKS2
cognición
KS0
Inicial Obligatoria
KS0
KS0
KS0
Opcional
KS1
KS2
Final Obligatoria
KS0
TTR con deadline y wcet
CommonKADS-RT – Capítulo 3. CommonKADS-RT
149
(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 de tiempo real
Especificación del modelo 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
CommonKADS-RT – Capítulo 3. CommonKADS-RT
150
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.
CommonKADS-RT – Capítulo 4. Validación a través de casos 152
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”.
4.3.1 Modelo de la organización
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
CommonKADS-RT – Capítulo 4. Validación a través de casos 153
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.
CommonKADS-RT – Capítulo 4. Validación a través de casos 154
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.
CommonKADS-RT – Capítulo 4. Validación a través de casos
155
Figura 4-1 Organigrama de Marítima Valenciana
Estructura de la Empresa Marítima Valenciana S.A.
VicepresidenciaDirector General
Administración Financiera Recursos Humanosy Servicios Jurídicos
Comercial
Sistemas Análisis yprogramación
TecnologíasInformáticas
OperacionesTerrestres
OperaciónRIBA
Comunicaciones Secuenciación
Planificación
OperacionesMarítimas
Mantenimiento
Explotación
Presidencia
CommonKADS-RT – Capítulo 4. Validación a través de casos 156
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.
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.
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á
Organigrama Operaciones Marítimas
OperacionesRIBA
Comunicaciones Secuenciación
Planificación
OperacionesMarítimas
Armador Comunica-ciones
Operativa
de RIBA Secuencias
CommonKADS-RT – Capítulo 4. Validación a través de casos 157
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.
Figura 4-4 Diagrama de Actividades de los procesos que se realizan en la
Operaciones Marítimas
Donde:
Operaciones
Marítimas
Operaciones
Terrestres
Atención
Scheduling Planificación
Operativa
Marítima
Reserv. Espacio
y Preparación
transbordos
Apoyo
terrestre
Despacho
CommonKADS-RT – Capítulo 4. Validación a través de casos 158
• 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:
Figura 4-5 Relación entre la empresa Marítima Valenciana y el Armador
Figura 4-6 Relación entre la empresa Marítima Valenciana y Sevasa
es_proveedor_de ARMADOR MARÍTIMA
VALENCIANA
es_cliente_de SEVASA MARÍTIMA
VALENCIANA
CommonKADS-RT – Capítulo 4. Validación a través de casos 159
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
Figura 4-7 Relación entre las manos de Sevasa y las unidades de Marítima
Valenciana
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.
sirve Operación RIBA Manos
Planificación
contrata
sirve Operaciones Marítimas
Conductor transtainer
CommonKADS-RT – Capítulo 4. Validación a través de casos 160
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:
Figura 4-9 Relación entre el consignatario del Armador y la unidad Planificación
Figura 4-10 Relación entre el Planner del Armador y la unidad Planificación
Figura 4-11 Relación entre el agente del Armador y la unidad Secuenciación
Figura 4-12 Relación del Capitán del barco con Marítima Valenciana
Figura 4-13 Relación del Primer oficial del barco con Comunicaciones
c) Personas de Soporte: − Operador de la consola del trunking
solicita_atraque Puerto
Capitán
barco
Dice QUÉ Planificación Consignatario
Dice CÓMO Planificación Planner
(Antes de llegar el barco)
carga o descarga
Secuenciación Agente
comunica_incidencias
Comunicaciones Primer oficial
CommonKADS-RT – Capítulo 4. Validación a través de casos 161
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.
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:
<<uses>>
<<uses>
<<uses>>
Comunicador
Operador de
Riba
Jefe de
Planificación
Secuenciador
Solicitud de
servicios
Planeación de
actividades
Asignación de
recursos
Elaboración
secuencia
Carga / descarga barco
Registro de
incidencias
Armador
CommonKADS-RT – Capítulo 4. Validación a través de casos 162
• 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
CommonKADS-RT – Capítulo 4. Validación a través de casos 163
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.
CommonKADS-RT – Capítulo 4. Validación a través de casos 164
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
CommonKADS-RT – Capítulo 4. Validación a través de casos 165
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.
CommonKADS-RT – Capítulo 4. Validación a través de casos
166
Ident. de la
TAN
Nombre
de la
TAN
Objetivo de
la TAN
Tipo de
TAN
Ejecutada
por y en
dónde
Importancia de la
TAN
Intensivo
en conoci- miento
Datos, información y
conocimiento
involucrado
¿Puede tener
restricciones
temporales?
¿Es posible
introducir un
sistema informático
en la TAN?
ATN Atención Establecer la
comunicación
con el Armador y con el barco
para abrir la
carpeta del servicio
----- Comunica-ciones en
Operaciones Marítimas
Es siempre la primera
TAN y debe ser realizada
apropiadamente
porque de ella
depende la
información que se
obtenga del barco
Bajo / nada − Historia del barco
− Información nueva dada
por el Agente, el Armador y el capitán del barco
− Habilidades de
comunicación
− Habilidad de registro de la
información
Puede ser periódica, pues se
sabe cuando llegan
los servicios. Pero
puede variar
Si. Para registrar toda la
información de los barcos. Ya existe un
sistema que registra en
una base de datos todos los datos obtenidos. Habría que revisar si es completo dicho sistema.
SCHE Scheduling Realizar la
planeación de
la atención de
los barcos que
están en el muelle y la
asignación de
los recursos que se requiere
para ello
Planificación
y Scheduling
Jefe de
Planificación
en
Operaciones Marítimas
Es importante porque
trata de minimizar el tiempo de estancia
del barco
Alto − Historia del barco
− Situación actual − Situación prevista del
muelle
− Experiencia en asignación
de barcos al muelle
− Criterios de asignación de
los barcos − Experiencia en
programación de
actividades y recursos. − Optimización de recursos − Evaluación de riesgos − Datos o Inf. obtenida del
proceso para hacer la
notificación al barco y al Agente
No tiene un tiempo
fijo, pero la
atención debe ser rápida desde el mismo momento
en que el barco
avisa que está en
Valencia.
Si, para
la gestión del atraque
de los barcos, o
la programación de las actividades y la
asignación de recursos, con el objetivo de hacer las listas de carga y
descarga, o
registro de la
información
PLAN Planifica-ción
Planear la
secuencia de
carga y
descarga de
Planificación
y Scheduling
Jefe de
Planificación
Secuencia-dores en
Es importante porque
trata de optimizar la
forma de hacer la
carga y descarga del
Alto − Historia
− Lista de carga y descarga
− Disposición por destinos − Plano del barco
No tiene. Aunque
hay unos tiempos que se miden para
ver su ejecución.
Si, para
Hacer la planificación
de la carga y descarga
del barco en función de
CommonKADS-RT – Capítulo 4. Validación a través de casos
167
contenedores en o del barco. Implica la
asignación
apropiada de
las manos
Operaciones Marítimas
barco, en función de
los recursos, de las características del barco
− Características del barco
− Características de la carga
− Experiencia en Planeación
de actividades de carga y
descarga
− Criterios de asignación de
manos, grúas y camiones
Estos se describen
más adelante en el formulario OM-5
la experiencia de los secuenciadores y de la
situación real y actual
OP-MAR
Operativa
Marítima
Hacer la carga
y descarga de
los contenedores
Asignación Los operadores de la Riba en
Operaciones Marítimas
Es importante porque
son los que se
encargan
directamente de
ejecutar el plan y las secuencias.
Medio − Situación actual del barco
y situación final del barco
− Recursos disponibles − Experiencia en la
operación marítima
− Experiencia en transporte
de los diferentes tipos de
contenedores − Conocimiento sobre
manejo de incidencias − Habilidad de solución de
problemas y toma de
decisiones − Habilidad de
comunicación
Debería tener unas especificaciones temporales dependiendo de los criterios de
calidad. Podrían
fijarse en función
del tipo de carga, del número de
contenedores, manos, camiones y
grúas.
Si, para hacer la
actualización del plano
del barco y del puerto
una vez se carguen o
descarguen
contenedores
DES Despacho Consignar toda
la información
del proceso, incluyendo las incidencias
----- Comunica-ciones y
Secuencia-ción en
Operaciones Marítimas
Es muy importante
para mantener la
información
completa y
actualizada de todos los servicios realizados
Bajo / nada − Información obtenida
durante el proceso
No. Debería estar en
línea
Si. Un sistema que
registre (puede ser el mismo que se utilizó en
la Atención) y
comunique la situación
final
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.
CommonKADS-TR – Capítulo 4. Validación a través de casos
169
• 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.
CommonKADS-RT – Capítulo 4. Validación a través de casos
170
Modelo de la Organización Capital (Activo) Conocimiento
Hoja de Trabajo OM-4
Activo
Conocimiento
Poseído por: Usado en
TAN: ¿Forma correcta? ¿Lugar
correcto?
¿Calidad correcta?
Criterios de optimización
de recursos Jefe de Planificación y
secuenciadores SCHE: Scheduling
PLAN: Planificación
- No: son criterios que dependen del encargado, aunque hay muchas directrices que se maneja tácitamente. - Deberían ser al menos registrados en el papel
Si. El conocimiento está
en donde se
realiza la tarea
Si, aunque deberían ser formalizados.
Planificación Secuenciadores PLAN: Planificación
SCHE: Scheduling
- No: los secuenciadores tienen este
conocimiento también en su cabeza. - Hay algunas cosas que quedan registradas en papel - Debería tenerse un sistema informático que
realizara la secuencia
Si No: Puede tener muchas restricciones, ser variable, difícil de
verificar, es basado en la
experiencia y es muy especializado
Scheduling Jefe de Planificación SCHE: Scheduling
PLAN: Planificación
OP-MAR: Operativa
Marítima
- No: También está en la cabeza del ejecutar de la tarea. - No está registrado en ninguna parte, ni en
forma escrita ni en medio electrónico. - Es posible tener un sistema informático que
realice esto
Si
No: es dependiente de la situación, basado en la experiencia - heurístico, es muy dinámico, es incompleto, incierto, y difícil de verificar
Manejo de incidencias Jefe de Planificación, secuenciadores, operadores de Riba y
comunicadores
ANT: Atención
SCHE: Scheduling
PLAN: Planificación
OP-MAR: Operativa
Marítima
DES: Despacho
- No hay nada registrado, depende de la
persona que se enfrente a la situación
Si No, pues es incompleto, heurístico e
incluso puede ser incorrecto
Desarrollo de la
operativa marítima
Operadores de la Riba OP-MAR: Operativa
Marítima
- Si, pues es una TAN que tiene mucha parte
operativa aunque depende de la experiencia
Si Si
Formulario 4-2 OM-4: Descripción del componente de conocimiento del modelo de la organización
CommonKADS-TR – Capítulo 4. Validación a través de casos
171
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.
CommonKADS-RT – Capítulo 4. Validación a través de casos
172
Modelo de la
Organización
Aspectos Variantes
Hoja de Trabajo OM-5
Estructura una vez se tenga
el SBCTR
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.
Nombre de la TAN en donde
estará el SBCTR
PLAN: Planificación
Esquema del Proceso
automatizado
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
empresa Marítima Valenciana. Personas que pueden
participar en el desarrollo
del SBCTR
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. Todas ellas participan en la adquisición del conocimiento. Específicamente estarían los jefes de planificación y los secuenciadores. 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
aplicación del SBCTR
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 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.
CommonKADS-RT – Capítulo 4. Validación a través de casos
173
− 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
CommonKADS-TR – Capítulo 4. Validación a través de casos
174
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:
Figura 4-16 SBCTR ubicado en las actividades de la empresa Marítima Valenciana
Secuenciadores
Base de
Datos SBCTR
Planificación
Secuencia de carga
Operaciones
Marítimas
Operaciones
Terrestres
Atención
Scheduling
Operativa
Marítima
Reserv. Espacio
y Preparación
transbordos
Apoyo
terrestre
Despacho
SBCTR Planificación
CommonKADS-TR – Capítulo 4. Validación a través de casos
175
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,
CommonKADS-TR – Capítulo 4. Validación a través de casos
176
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:
CommonKADS-TR – Capítulo 4. Validación a través de casos
177
− 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).
CommonKADS-TR – Capítulo 4. Validación a través de casos
178
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.
4.3.2 Modelo de tareas de alto nivel
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
Organización
Operaciones Marítimas, específicamente en la unidad Secuenciació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
en la TAN
1. Objetos de entrada: La E.T.A., la Carpeta del Barco, el Bayplan
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.
CommonKADS-TR – Capítulo 4. Validación a través de casos
179
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
Habilidades
Ver TM-1.1 y las explicaciones siguientes
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
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
E.T.A. Bayplan
Situación del barco y del
puerto
Programar Carga y
Descarga
Gestionar atraque
Lista carga y Lista descarga
Hacer la
secuencia de
carga y
descarga
Secuencia de carga
y descarga / Incidencias
Registrar informació
Carpeta
actualizada
CommonKADS-TR – Capítulo 4. Validación a través de casos
180
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:
CommonKADS-TR – Capítulo 4. Validación a través de casos
181
Ident. de la
TAN
Nombre de
la TAN
Tipo de
TAN
¿Ejecutada
por?
¿En dónde? ¿Intensivo
en conoci-miento?
Conocimiento
involucrado ¿Es
importante
para el proceso?
¿Puede tener
restricciones
temporales?
¿Es posible
introducir un
sistema
informático en la
TAN?
PLAN..ATR
Gestionar Atraque
Asignación − Personal de
planificación
− Jefe de
Planificación
Planificación Alto − Historia (puntualidad,..) − Situación prevista en el
día de llegada
(conocimiento que es incierto)
− Experiencia en asignación
de barcos
Este proceso es muy importante y
requiere que se
manejen los siguientes criterios:
− Dar la atención
oportuna a los buques
− Maximizar la
utilización del muelle
- Puede definirse el tipo de tarea según
la frecuencia como
se realiza. Podría
llegar a tener un
comportamiento
periódico.
Si. Un sistema que
tuviera la imagen
del muelle y que de
acuerdo con las especificaciones y
restricciones, permitiera tomar decisiones EN
tiempo real
PLAN..CyD
Programación
de carga y
descarga
Programación − Jefe de
Planificación
− Personal de
Marítima
Planificación Alto − Historia (cómo se ha
cargado el barco
anteriormente) − Situación actual (del
barco, del muelle y del puerto)
− Experiencia en
Programación de
actividades y recursos − Optimización de recursos − Evaluación de riesgos
Tiene que ser realizada
apropiadamente. Los criterios que
se manejan son: − La optimización
de los recursos − Minimizar el
tiempo de carga
y descarga
- Una vez se va a
empezar a atender el barco, deberían
tenerse unos tiempos definidos para la carga y la
descarga, de
acuerdo con el tipo
de barco, de carga, el número de
contenedores, entre otros.
Si. Un scheduler
que asignara los recursos necesarios, las manos para
cargar y descargar el barco
PLAN..SEQ
Generar secuencia de
carga
Planeación − Personal de
Planificación
Planificación Muy Alto − Experiencia en planeación
de secuencia de
contenedores − Conocimiento o manejo
de prioridades de acuerdo
Tiene que ser realizada
apropiadamente. Se tratan los siguientes
- Igual que el anterior
No. Debe ser realizado
manualmente.
CommonKADS-TR – Capítulo 4. Validación a través de casos
182
con los criterios de la
TAN y de Marítima
Valenciana
criterios: − Minimizar el
tiempo de carga
y descarga
− Impedir bloqueos
PLAN..REG
Registro de
Información
(guardar)
(No es intensiva en
conocimiento)
− Personal de
Planificación
− Personal de
Operativa
Marítima
Planificación No − Datos o Inf. obtenida del proceso para guardar la
información y hacer la
notificación al buque y al agente
Es muy
importante y
también requiere
que se haga
apropiadamente
No Si, un sistema de
información que
registrar todo en una
base de datos.
Formulario 4-5 TM-1.1: TAN PLANIFICACIÓN (PLAN)
CommonKADS-RT – Capítulo 4. Validación a través de casos 183
Modelo de Agente Agente
Hoja de Trabajo AM-1
Nombre Actor - Jefe de Planificación
Ubicación en la
Organización
Está ubicado en la Operativa Marítima, siendo uno de los responsables de la atenció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) TAN
Participa en la TAN SCHE y TAN PLAN.
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
Restricciones El jefe de planificación es el responsable de lo que se realiza en la operativa marítima
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;
CommonKADS-RT – Capítulo 4. Validación a través de casos 184
Figura 4-18 Diagrama de Conceptos – Conocimiento del Dominio - de Operaciones
Marítimas
CONCEPT contenedor; ATTRIBUTES: num-boletin: INTEGER; num-contenedor: STRING; clase: INTEGER;
barco carpeta
E.T.A.
bayPlan
maquina conductor
pos-terminal
pila
calle planta
frontal
chasis-Term trastainer
grua
1..*
posicion
1..*
bodega
1..*
secuencia
conduccion-maquinaria
contiene
movimientos
situado-en
contenedor
CommonKADS-RT – Capítulo 4. Validación a través de casos 185
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:
Figura 4-19 Diagrama de estados de Bayplan
Figura 4-20 Diagrama de estados de Pila
descarga carga Llegada Tránsito Salida
bloquear
liberar
desbloquear
desbloquear
bloquear
resevar
Bloqueada Asignada a Servicio
Libre
CommonKADS-RT – Capítulo 4. Validación a través de casos 186
Figura 4-21 Diagrama de estados de Posición
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;
asignar_
contenedor depositar
extraer vacía ocupada
asignada
depositar
asignar vacía
ocupada
extraer asignada
CommonKADS-RT – Capítulo 4. Validación a través de casos 187
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
la tarea en CML2
TASK-METHOD método-asignación; 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
CommonKADS-RT – Capítulo 4. Validación a través de casos 188
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
CML2
TASK planificación
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
la tarea en CML2
TASK-METHOD método-planificación-idealizado; 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.
CommonKADS-RT – Capítulo 4. Validación a través de casos 189
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
CML2
TASK scheduling; 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
la tarea en CML2
TASK-METHOD temporal-dispatching; 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.
CommonKADS-RT – Capítulo 4. Validación a través de casos 190
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.
4.4.1 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
CommonKADS-RT – Capítulo 4. Validación a través de casos 191
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.
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.
Formas básicas
Robot
CommonKADS-RT – Capítulo 4. Validación a través de casos 192
• 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.
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.
Activar robot
Buscar objeto
Identificar objeto
Mover objeto
Administrador Fin Proceso
CommonKADS-RT – Capítulo 4. Validación a través de casos
193
Ident. TAN
Nombre
TAN
Objetivo de la
TAN
Tipo de TAN Importancia de
la TAN para el proceso
¿Es intensiva en
conocimientos?
Conocimiento
involucrado
¿Puede tener
restricciones
temporales?
Config Configuración Establecer las condiciones del micro mundo
Es importante pero
no requiere de
conocimientos
Nada No
ActRobot Activación robot Protocolo de
inicio, verificación
del robot
Igual que la
anterior Nada Si. El robot maneja unos
tiempos para revisar su
batería, los sensores y los motores. Es un tiempo fijo
BuscaObj Búsqueda objeto Encontrar el objeto
que debe reconocer y trasladar
Planeación
Scheduling
Monitorización
Es fundamental para planificar las acciones y asignar los tiempos
Alto Planificación de acciones, interpretación del micro
mundo, verificación de la
trayectoria
Si. Hay tareas que serán
periódicas, que tendrán unos deadlines y también un wcet
IdObj Identificación
objeto
Identificar el objeto encontrado
Clasificación La clave es la
diferenciación
entre las diferentes figuras.
Alto Conocimiento de formas de objetos trigonométricos, planeación de trayectoria, interpretación, verificación.
Igual que la anterior
MovObj Movimiento
objeto
Trasladar el objeto
hasta el sitio en
donde debe ser guardado
Configuración
Planeación
Scheduling
Monitorización
Es necesario tener un planeador
Alto Identificación de la pared
objetivo, planificación de
la trayectoria, cómo
mover el objeto.
Igual que la anterior
Formulario 4-7 Descripción del proceso en función de las TAN que lo componen
CommonKADS-TR – Capítulo 4. Validación a través de casos
194
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.
4.4.2 Modelo de tareas de alto nivel
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.
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:
Percepción
del entorno Planificar
acción Ejecución
de la acción
CommonKADS-TR – Capítulo 4. Validación a través de casos
195
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.
Figura 4-26 Diagrama de Conceptos para el sistema del robot móvil en el micro
mundo
sensor
robot
bumper
batería
plan-búsqueda
sonido planificador
plan-acción
motor
plan-identif
plan-traslado
mundo
formas
1 2
rectángulo
triángulo
círculo
ubicado-en
1..16
posición
CommonKADS-TR – Capítulo 4. Validación a través de casos
196
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:
Figura 4-27 Diagrama de transición de estados del Planificador
Figura 4-28 Diagrama de transición de estados del PlanAcción
Reconociendo objeto
Buscando
objeto
Desplazando objeto
encuentra-objeto
forma-desconocida
objeto-reconocido siguiente-objeto
no-encuentra-objeto
planificando
siguiente
acción
desplazando
acción a ejecutar (mover x,y) (giro α)
acción
completa
No-Detectado
planificando
siguiente
acción
desplazando
acción a ejecutar (mover _,_) (giro α) fin giro
Objeto-Detecta
bump: bumper;
O.K.
detectado
CommonKADS-TR – Capítulo 4. Validación a través de casos
197
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.
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
Robot Planificador
Robot en el estado inicial
envío estado actual / datos
Robot listo
Plan-acciones
1. acción
solicitud de datos
envío estado actual / datos
fin acción
n. acción
Plan-acciones
Ejecuta acción
chequeo
20 segs
100 ms
CommonKADS-TR – Capítulo 4. Validación a través de casos
198
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.
Figura 4-30 Diagrama de componentes principales del robot
El software que el robot tiene es:
MicrocontroladorSiemens 88C166
VDC
Aplicación ARTIS
Componente de la
interfaz de usuario
Componente de
comunicación
Componente de
control inteligente
Robot
Sensores
Motor
Batería
Componente de
planificación
RS232 C
Radio Ethernet
Señal cable
VDC
CommonKADS-TR – Capítulo 4. Validación a través de casos
199
• 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.
CommonKADS-TR – Capítulo 4. Validación a través de casos
200
− 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
Estado del robot Byte indicador: 0x32: moving
0x33: stopped
Byte indicador
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
CommonKADS-TR – Capítulo 4. Validación a través de casos
201
Batería
Nivel de carga en voltios
Bumpers
Valor que indica si alguno de los bumper está presionado.
Byte indicador
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 tramaint estado; // Estado de la trama actual: COMPLETO-
PENDIENTEint leidos_C;// Nº bytes de la cabecera leídos hasta
el momentoint 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 robotunsigned char clase[7]; // Clase del robotunsigned char subclase[4]; // Subclase del robot
};
− Estructura que almacena la información de los sonares.
CommonKADS-TR – Capítulo 4. Validación a través de casos
202
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 respectoal 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 laposición local
short int Lvel, Rvel; // Velocidad de las ruedasshort int battery; // Nivel de la bateríashort int bumpers; // Indicador de choqueshort int timer; // Puerto analógico
seleccionadosonar 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, ...).
CommonKADS-TR – Capítulo 4. Validación a través de casos
203
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
CommonKADS-TR – Capítulo 4. Validación a través de casos
204
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.
CommonKADS-TR – Capítulo 4. Validación a través de casos
205
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.
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
NO_CONNECT
SYNC1
SYNC0_R
SYNC0
CONNECT
SYNC1_R
Si (intentos<100) Envio_SYNC0
Recibo_SYNC0
Envio_SYNC1
Recibo_SYNC1
Envio_SYNC2
Error
Si (intentos>=N)
CONNECTION FAILED
intentos++
intentos=0
CommonKADS-TR – Capítulo 4. Validación a través de casos
206
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:
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; rt-task-type: periodic; 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;
Robot AA
Config ActRobot BuscaObj IdObj MovObj
PercepEntorno PlanAcción EjecAcción
EjecComando LeerSensor VeriObjetivo
In-Agents
MKSs
KSs
CommonKADS-TR – Capítulo 4. Validación a través de casos
207
real-time-task ::= LeerListaSensor; rt-task-type: periodic; 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:
CommonKADS-TR – Capítulo 4. Validación a través de casos
208
(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
CommonKADS-TR – Capítulo 4. Validación a través de casos
209
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
CommonKADS-TR – Capítulo 4. Validación a través de casos
210
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.
CommonKADS-RT – Capítulo 5. Conclusiones y trabajos futuros
212
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 sistemas basados en el conocimiento de tiempo real.
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.
CommonKADS-RT – Capítulo 5. Conclusiones y trabajos futuros
213
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.
CommonKADS-RT – Capítulo 5. Conclusiones y trabajos futuros
214
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:
CommonKADS-RT – Capítulo 5. Conclusiones y trabajos futuros
215
• 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.
CommonKADS-RT – Capítulo 5. Conclusiones y trabajos futuros
216
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
CommonKADS-RT – Capítulo 5. Conclusiones y trabajos futuros
217
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.
CommonKADS-RT – Capítulo 5. Conclusiones y trabajos futuros
218
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.
CommonKADS-RT – Capítulo 5. Conclusiones y trabajos futuros
219
• 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.
CommonKADS-RT – Referencias
224
[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
CommonKADS-RT – Referencias
225
[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.
CommonKADS-RT – Referencias
226
[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.
CommonKADS-RT – Referencias
227
[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.
CommonKADS-RT – Referencias
228
[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.
[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.
CommonKADS-RT – Referencias
229
[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.
CommonKADS-RT – Referencias
230
[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
CommonKADS-RT – Referencias
231
[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.
CommonKADS-RT – Referencias
232
[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/
CommonKADS-RT – Referencias
233
[Sel96a] B. Selic. An Efficient Object-Oriented Variation of the Statecharts
Formalism for Distributed Real-Time Systems. ObjectTime. Ontario,
Canada. 1996. 8 p.
http://www.objectime.com/otl/technical/
[Sel96b] B. Selic. Periodic Tasks in ROOM. ObjectTime. Ontario, Canada. 1996.
4 p.
http://www.objectime.com/otl/technical/
[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.
CommonKADS-RT – Referencias
234
[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.
CommonKADS-RT – Referencias
235
[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.
CommonKADS-RT – Referencias
236
[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/
CommonKADS-RT – Referencias
237
[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.
[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.
[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.
CommonKADS-RT – Referencias
238
• 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 conocimiento de tiempo real?
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?
CommonKADS-RT – Anexo 1
240
11 ¿La Organización comprende las características básicas de un sistema basado en el conocimiento de tiempo real?
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?
CommonKADS-RT – Anexo 1
241
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 conocimiento de tiempo real?
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?