Tesis Doctoral - Dpto. de Sistemas Informáticos y ... · Los sistemas basados en el conocimiento...

Universidad Politécnica de Valencia

Departamento de Sistemas Informáticos y Computación

Tesis Doctoral

CommonKADS-RT: Una Metodología para el Desarrollo de Sistemas Basados en el

Conocimiento de Tiempo Real

Mónica Henao Cálad

Director:

Dr. Vicente Botti Navarro

Valencia, España. Abril de 2.001

Título: CommonKADS-RT: Una metodología para el desarrollo de sistemas

basados en el conocimiento de tiempo real.

Autor:

MSc. Mónica Henao Cálad

Director:

Dr. Vicente Botti Navarro

Tribunal:

Presidente:

Dr. Federico Barber Sanchís

Secretario:

Dra. Eva Onaindía de la Rivaherrera

Vocales titulares: Dr. Richard Benjamins

Dr. Fernando Martín Rubio

Dr. Carlos Iglesias Fernández

Vocales suplentes: Dra. Ana García Serrano

Dr. José Ramón Rizo Aldeguer

Valencia – España

12 de junio de 2001

A mi esposo Riche, que siempre me ha animado, apoyado y brindado su amor y comprensión,

estando a mi lado en todo momento

A mi familia, por sus oraciones, su amor y respaldo durante toda mi vida

Reconocimientos

Hay muchas personas a las que quisiera agradecerle toda su colaboración, amistad y

apoyo durante este largo recorrido, pero en este momento quiero resaltar los siguientes:

Al Doctor Vicente Botti, por su orientación, asesoría y soporte que me permitió

culminar exitosamente este proyecto.

A los miembros del Grupo de Tecnologías Informáticas (GTI) del Departamento de

Informática y Computación (DSIC) de la Universidad Politécnica de Valencia quienes

siempre me apoyaron y me dieron su conocimiento y amistad.

A los profesores del DSIC que me dieron la oportunidad de realizar este doctorado, a

través de sus enseñanzas. En especial a la Dra. Matilde Celma, responsable del programa.

A los coordinadores del convenio UNAL-UPV y directivas de la UPV quienes

hicieron posible la realización de este doctorado y de las diferentes pasantías que realicé

durante la investigación.

A los integrantes del Departamento de Informática y Sistemas de la Universidad

EAFIT, por su apoyo e interés.

A las directivas de la Universidad EAFIT por su patrocinio y soporte en la realización

del doctorado.

Al postgrado de Sistemas de la Universidad Nacional de Colombia, sede Medellín por su colaboración en la realización de los cursos doctorales.

A mi familia y amigos que siempre me animaron y comprendieron todas mis

ausencias.

CommonKADS-RT – Resumen

Resumen

Los sistemas basados en el conocimiento de tiempo real son sistemas informáticos que

manejan el conocimiento de un dominio específico y tienen la capacidad de garantizar una

respuesta en un tiempo fijo, dado que manejan restricciones temporales.

Estos sistemas se han utilizado para solucionar problemas de control de procesos, monitorización, diagnóstico y mantenimiento de fallos, entre otras. Es decir, en situaciones

en donde la toma de decisiones es dependiente del tiempo.

Básicamente las investigaciones en estos sistemas han estado enfocadas hacia su

arquitectura, sobre cómo lograr el cumplimiento de las garantías temporales en el razonamiento del conocimiento o sobre cómo modificar las políticas de planificación de

tiempo real para que sean más predecibles.

No se han hecho muchos trabajos sobre cómo construir un sistema de este tipo, sobre

qué actividades deben ser realizadas para plantear un proyecto que pretenda la creación del sistema o cuáles son las pautas que se deben seguir en dicho desarrollo. Es por esto, por lo

que se ha planteado proponer una metodología para el desarrollo de sistemas basados en el conocimiento de tiempo real, surgiendo CommonKADS-RT.

Esta tesis se centra en el estudio de los sistemas basados en el conocimiento, los

sistemas de tiempo real, los sistemas basados en el conocimiento de tiempo real y los

métodos o metodologías que se han propuesto para el desarrollo de cada uno de esos

sistemas. Esto ha servido para desarrollar CommonKADS-RT, basada en la metodología

CommonKADS para sistemas basados en el conocimiento y RT-UML para sistemas de

tiempo real.

CommonKADS-RT permite seguir, en una forma comprensible y sencilla la

construcción de un sistema basados en el conocimiento de tiempo real. Está fundamentada

en el desarrollo evolutivo, la orientación por riesgos y sigue los planteamientos que la

Ingeniería del Software propone para lo que debe ser una buena metodología.

En CommonKADS-RT se plantea que un sistema basado en el conocimiento de

tiempo real se construye a través del desarrollo de siete modelos del problema o su

solución: el modelo de la organización que describe la empresa u organización en donde se

encuentra el problema y en donde se implantará la solución; el modelo de tareas de alto

nivel para representar los procesos del negocio relacionado con el problema; el modelo de

agentes para especificar las personas y los sistemas automáticos que participan en el problema y su solución; el modelo de conocimientos que precisa el conocimiento que

poseen los agentes para realizar la tarea de alto nivel; el modelo de comunicaciones para

expresar los actos de comunicación que realizan los diferentes agentes que participan en el sistema, para compartir su conocimiento y lograr el objetivo de las tareas de alto nivel; el modelo de diseño en donde se describe la arquitectura y la especificación del diseño global del sistema; y el modelo de tareas de tiempo real para definir la estructura genérica de una

tarea de tiempo real. Los primeros cinco modelos forman la fase de análisis y los dos

últimos la fase del diseño.


Para cada uno de los modelos se plantea su objetivo, los formularios que permiten

guiar su proceso de construcción y reflejar la información para incluir en la documentación

del proceso, los artefactos que resultan del desarrollo del modelo y los roles más

importantes que participan en dicho proceso.

Adicionalmente, las consideraciones metodológicas propuestas en esta tesis, incluyen

la determinación de cuándo es apropiado construir un sistema basado en el conocimiento de

tiempo real y si ésta es la mejor alternativa de solución, a través de unos criterios de

filtrado y de una caracterización del dominio en donde es posible utilizar la metodología.

Para mostrar la aplicación de la metodología se presenta dos casos reales y diferentes

en donde ésta se ha utilizado. En el primer escenario se pone énfasis en la etapa de análisis, especialmente en el modelo de la organización. En el segundo se resalta la fase de diseño, en particular la arquitectura del sistema y el modelo de tareas de tiempo real.

Como resultado de esta investigación se han realizado las siguientes publicaciones:

BOTTI V. Henao M. Soler J. Método de análisis para modelar sistemas basados en el conocimiento en tiempo real. Memorias de la VIII Conferencia de la Asociación Española

para la Inteligencia Artificial, CAEPIA'99. Murcia, España. 1999, pp. 17-25.

HENAO, Mónica. CommonKADS: Una buena herramienta para la gerencia del conocimiento. Revista Universidad EAFIT No. 115. Medellín, Colombia. 2000, pp. 77-93.

SOLER, J. Henao, M. Botti V. A Mobile Robot Application with an Analysis Method

based on CommonKADS. Proceedings of the IASTED International Conference: Intelligent Systems and Control (ISC 2000). 2000, pp. 299-303.

HENAO, M., Soler, J. Botti. La integración de sistemas basados en el conocimiento y

sistemas de tiempo real por medio de un robot móvil. Workshop Luso - Hispano de

Agentes Físicos. Madrid, España. 2001, pp. 49-60.

HENAO, M., Soler, J. Botti V. Developing a Mobile Robot Control Application with

CommonKADS-RT. IEA/AIE 2001, The Fourteenth International Conference on Industrial & Engineering Applications of Artificial Intelligence & Expert Systems. Budapest, Hungary. 2001. (pendiente de publicar)


Abstract

Real-time knowledge-based systems are computer systems with two main abilities. On

the one hand, they can manage knowledge about a specific domain. On the other hand, they

are able to guarantee an answer in a fixed time, given that they can manage temporal restrictions.

Systems of this kind have been used for solving several types of problems, such as

process control systems, monitoring, diagnosis and fault maintenance systems. In general, these systems are applicable in systems where decision making is dependent on time.

In the past, research about such systems has been focused towards issues as their architectures, mechanisms to obtain strict timing guarantees in the reasoning process or modifications to real-time scheduling policies in order to make them more predictable. However, not much of this research has been oriented on how to build such systems, the

activities involved in developing a project to create these systems, or the guidelines to

follow in that development. In this context, this work proposes a new methodology for developing real-time knowledge-based system. This new methodology is called

CommonKADS-RT.

This doctoral thesis is centered in the study of knowledge-based systems, real-time

systems, real-time knowledge-based systems and the methods and methodologies which

have been proposed for developing each of these types of systems. All this has been used

for developing CommonKADS-RT. This methodology is, in turn, based on two

methodologies: CommonKADS, for the development of knowledge-based systems, and

RT-UML, for the development of real-time systems.

CommonKADS-RT allows to follow, in a understandable and easy way, the building

of a real-time knowledge-based system. This new methodology is based on both the

evolving development and the risk orientation, and it follows the guidelines proposed by

Software Engineering for creating a good methodology.

CommonKADS-RT proposes a real-time knowledge-based system to be built by

means of the development of seven problem (or solution) models. The organization model describes the organization or company which has the problem, that is, the organization on

which the solution will be developed. The high-level task model represents the business

processes related with the problem. The agent model specifies the persons and the

automated systems which participate in the problem and its solution. The knowledge model represents the knowledge that agents have for performing the high-level task. The

communication model expresses the communication acts executed by the agents that participate in the system; this model is also used by agents for sharing their knowledge and

therefore for achieving the goals of the high-level tasks. The design model describes the

architecture and specifies the global design of the system. And the real-time task model defines the generic structure of a real-time task. The five former models constitute the

analysis phase, while the two latter models form the design phase.

For each of these models, the following aspects are described: its objective, the forms

which allow to guide its developing process and to gather the information to be included in


the process documentation, the artifacts which result from the model development and the

most important roles which participate in that process.

The methodological proposals of this thesis also include the determination of when it is appropriate to build a real-time knowledge-based system and whether this is the best alternative. This is done by means of some filtering criteria and a characterization of the

domains on which it is possible to use the methodology.

In order to show the applicability of this new methodology, this thesis also presents

two real cases on which it has been applied. In the first scenario, the emphasis is on the

analysis phase, and specially on the organization model. In the second scenario, the design

phase is more deeply developed, specially the system architecture and the real-time task

model.

Some of the proposals of this thesis have been published in the following conferences:










CommonKADS-RT. IEA/AIE 2001, The Fourteenth International Conference on Industrial & Engineering Applications of Artificial Intelligence & Expert Systems. Budapest, Hungary. 2001.


Resum

Els sistemes basats en el coneixement i de temps real són sistemes informàtics que

manegen el coneixement d’un domini específic i tenen la capacitat de garantir una resposta

en un temps fixe, donat que tenen restriccions temporals.

Aquestos sistemes s’han utilitzat per a resoldre problemes de control de processos, monitoritzacio, diagnòstic i manteniment de fallades, i daltres. Es a dir, en situacions a on la

presa de decisions és dependent del temps.

Bàsicament les investigacions en aquestos sistemes han estat enfocades cap a la seva

arquitectura, sobre com aconseguir el compliment de les garanties temporals en el raonament del coneixement o sobre com canviar les polítiques de planificació de temps real per que siguen més predibles.

No s’han desenvolupat molts treballs sobre com construir un sistema d’aquest tipus, sobre què activitats deuen ser realitzades per a plantejar un projecte que tracte la creació del sistema o sobre quines són les pautes a seguir en aquest desenvolupament.

Es per això, per que s’ha plantejat proposar una metodologia pel desenvolupament de

sistemes basats en el coneixement de temps real, d’aquesta manera es planteja

CommonKADS-RT.

La tesi es centra en l’estudi dels sistemes basats en el coneixement, els sistemes de

temps real, els sistemes basats en el coneixement de temps real i els mètodes o

metodologies que s’han proposat pel desenvolupament de cada un d’aquestos sistemes.

Açò ha servit per a desenvolupar CommonKADS-RT, basada en la metodologia

CommonKADS per a sistemes basats en el coneixement i RT-UML per a sistemes de temps

real.

CommonKADS-RT permet seguir, de forma comprensible i senzilla la construcció

d’un sistema basat en el coneixement de temps real.

Es fonamenta al desenvolupament evolutiu, l’orientació per riscs i segueix els

plantejaments que l'Enginyeria del Programari proposa com el que ha de ser una bona

metodologia.

En CommonKADS-RT es planteja que un sistema basat en el coneixement de temps

real es construirà mitjançant el desenvolupament de set models del problema o la seva

solució: el model de l’organització que descriu l’empresa o organització a on es troba el problema i a on s’implantarà la solució; el model de tasques d’alt nivell per representar els

processos del negoci relacionats amb el problema; el model d’agents per a especificar les

persones i els sistemes automàtics que participen en el problema i la seva solució; el model de coneixement que precisa el coneixement que tenen els agents per a realitzar la tasca

d’alt nivell; el model de comunicacions per expressar els actes de comunicació que realitzen

els diferents agents que participen en el sistema, per a compartir el seu coneixement i aconseguir l’objectiu de la tasca d’alt nivell; el model de disseny on es descriu

l’arquitectura i l’especificació del disseny global del sistema; i el model de tasques de


temps real per a definir l’estructura genèrica d’una tasca de temps real.

Els primers cinc models formen la fase d’ anàlisi i els dos últims la fase de disseny.

Per a cada model es planteja el seu objectiu, els formularis que permeten guiar el seu

procés de construcció i reflectir l’informació per a incloure en la documentació del procés, els artefactes que resulten del desenvolupament del model i els rols més importants que

participen en dit procés.

A més a més, les consideracions metodològiques propostes en aquesta tesi, inclouen la

determinació de quan és apropiat construir un sistema basat en el coneixement de temps

real i si aquesta és la millor alternativa de solució, mitjançant uns criteris de filtrat i una

caracterització del domini on és possible utilitzar la metodologia.

Per a mostrar l’aplicació de la metodologia es presenten dos casos reals i diferents on

s’ha utilitzat. En el primer escenari es posa l’èmfasi en l’etapa d’anàlisi, especialment en el model de l’organització.

En el segon es ressalta la fase de disseny, en particular l’arquitectura del sistema i el model de tasques de temps real.

Com a resultat d’aquesta investigació, s’han realitzat les següents publicacions:










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


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


iii

4.3 Terminal de contenedores en el puerto de Valencia .............. 152



4.3.3 Modelo de agentes ........................................................................................ 180

4.3.4 Modelo de conocimientos.............................................................................. 183

4.4 Robot .................................................................................. 190



4.4.3 Modelo de conocimiento ............................................................................... 194

4.4.4 Modelo de diseño.......................................................................................... 197

4.4.5 Modelo de tareas de tiempo real .................................................................... 206

4.5 Conclusiones de la aplicación de CommonKADS-RT ........... 209

Capítulo 5. Conclusiones y trabajos futuros 211

5.1 Introducción ............................................................................ 211

5.2 Conclusiones generales............................................................ 212

5.3 Contribuciones principales ..................................................... 214

5.4 Trabajos futuros...................................................................... 218

ABREVIATURAS 221

REFERENCIAS 223

ANEXO 1 239

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


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


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


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


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


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


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


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


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]


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?


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.


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.


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.


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


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


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.


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.


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.


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.


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


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.


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:


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


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.


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


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.


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.


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


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.


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


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.


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


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


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.


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


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.


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


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


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


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.


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


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


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]:


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.


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


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


Personal

efectuadas por

puede

ser


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


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.


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


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


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.


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.


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


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.


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.


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


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.


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:


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.


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.


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.


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


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.


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


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


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


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:


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:


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.


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


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


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.


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


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.


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


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:


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).


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


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


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


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


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:


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.


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


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


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.


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


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.


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.


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


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


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


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.


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


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.


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


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.


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 Agentes

Modelo de

Tareas de Alto Nivel



Modelo de Tareas de

Tiempo Real

Modelo del Diseño


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


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.


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).


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.


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


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


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.


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,


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


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:


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


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


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.


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)


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.


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)




… … … … … … …

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


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.


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.


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


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.


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


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


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


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


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.


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


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.


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


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.


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:


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


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


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


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.


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


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.


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


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:


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 */


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.


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.


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.


133

3.6.5.1 Formularios del modelo de comunicaciones

• CM-1: Descripción de las transacciones del SBCTR


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


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.


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.


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


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


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


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


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


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.


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.


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?


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


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.


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


implementa


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.


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


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


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


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.


4.2.2 Escenario de una aplicación con un robot móvil navegante

Este escenario se ha desarrollado para validar la metodología CommonKADS-RT, la

arquitectura ARTIS y el software de desarrollo InSiDE en un caso especial, que no está

relacionado con un problema específico de una organización, sino que es un problema que

se diseñó específicamente para esta investigación. Para ello se creó un micro mundo en

donde un robot es controlado por un SBCTR que sabe cómo navegar en un mundo cerrado, puede identificar un objeto por su forma básica y puede moverlo o transportarlo. Este caso, es una situación particular dado que algunos de los planteamientos de la metodología en la

fase de análisis no será necesario analizarlos. Se incluye también la fase de diseño de la

aplicación que se ha construido para este propósito.

4.3 Terminal de contenedores en el puerto de Valencia

Desde hace un tiempo se viene desarrollando en forma conjunta, entre la Empresa

Marítima Valenciana y la Universidad Politécnica de Valencia, un proyecto en donde se

han estudiado diferentes áreas de dicha empresa con el fin de plantear soluciones a

problemas específicos o mejoras a través de soluciones informáticas. Es así, como se ha

venido trabajando en dos áreas prioritarias para el buen funcionamiento del Puerto Príncipe

Felipe de Valencia: Las Operaciones Terrestre y las Operaciones Marítimas. En esta última

es que se ha aplicado la metodología CommonKADS-RT con el objetivo de identificar posibles procesos que pueden mejorarse con la inclusión de un sistema basado en el conocimiento de tiempo real. Para ello, se han realizado múltiples reuniones con personal especializado en cada una de las tareas que se realizan en esta unidad y se ha compartido

información pertinente al proceso.

El objetivo de este caso es el siguiente: “Con este análisis pretendemos conocer en forma

detallada el proceso de las Operaciones Marítimas para plantear soluciones informáticas a situaciones

que requieran un uso intensivo de conocimiento bajo restricciones de tiempo”.


Directamente, se presentarán los resultados obtenidos al aplicar cada uno de los

formularios planteados en CommonKADS-RT.

4.3.1.1 OM-1 Identificación en la organización de los problemas y oportunidades orientados al conocimiento, con el tiempo como factor importante.

El ambiente organizacional no se requiere analizar en detalle porque en este caso

previamente se había definido e identificado el área en donde se presentan los problemas o

en donde se requiere hacer una mejora a los sistemas existentes, siendo ésta la unidad de

Operaciones Marítimas. Es allí en donde se debe realizar el estudio de viabilidad de aplicar


un SBCTR para hacer algunas de sus tareas. Por lo tanto, de este formulario solamente se

presentará la información relacionada con el Contexto de la Organización [BRH00]:

La empresa Marítima Valenciana S.A. forma parte de grupo de empresas Dragrados de

España y se encarga de manejar todo el tránsito de mercancías del Puerto de Valencia. Cuenta

con un equipo humano compuesto por 260 personas, con un alto nivel profesional y su política de

RR.HH. está recogida en los compromisos y valores definidos por su propia plantilla.

Marítima Valenciana S.A. ofrece a sus clientes un servicio integral puerta a puerta de

transporte para sus productos, contando para ello con las tecnologías más avanzadas y con una

estructura de empresa flexible, dinámica, eficiente y con calidad contrastada, donde destaca su

equipo humano altamente cualificado y profesional.

En términos generales las funciones de la empresa giran alrededor de la operación

marítima y la operación terrestre. Para la Operación Marítima se cuenta con un muelle cuya

longitud es de 1500 m, que se ampliará hasta 1900 m y con 9 (+2 en construcción) grúas. Se

trabaja en forma continua al día, 360 días al año. La unidad Operaciones Terrestres opera en un

horario diferente pero también con un rango muy amplio.

Visión: Ser el mejor Terminal Marítimo del Mediterráneo. Lo cual está trabajando a través de un

proyecto de Calidad en compañía de las autoridades portuarias.

Como el área Operaciones Marítimas es compleja y en ella se realizan diversos

procesos, en donde si no se tiene la información apropiada, real y en el momento preciso, se

puede demorar la atención de un barco, entonces se necesita hacer la caracterización de los

problemas que son intensivos en conocimientos y que manejan especificaciones temporales, lo que se detallará a través de los demás formularios.

Se han identificado algunas debilidades, muchas oportunidades, diversas fortalezas y

algunas amenazas también. Para efectos de esta memoria, sólo se incluirán las que se

consideran más relevantes:

• Una de las fortalezas que la empresa presenta es que su personal conoce muy bien el trabajo que realiza, el por qué y para qué de él, dando una visión compartida global, lo que ha facilitado la identificación de los procesos que deben ser estudiados a

fondo y la obtención de la información y el conocimiento de ello.

• Una de las grandes oportunidades que tiene esta empresa es que está en crecimiento, con un interés muy fuerte por mejorar y por invertir en tecnologías apropiadas para

cada uno de sus departamentos y unidades.

• Una de sus debilidades es que varios de sus procesos recaen específicamente sobre el personal, faltando la documentación apropiada o el registro tecnológico de los

procesos y sus conocimientos.

• Una de sus amenazas es que debe competir contra otros puertos que tradicionalmente

han sido mucho más “conocidos” y “grandes”. Esto obviamente también se puede

ver como una oportunidad.


Después de hacer una análisis detallado y de realizar diversas discusiones con expertos

en operaciones marítimas se concluyó que uno de los problemas que se debe solucionar más prontamente, tiene que ver con el hecho de registrar el conocimiento específico de las

tareas que ellos realizan. Esto evitará su perdida, permitiría que se pueda replicar, transmitir y generar así, la memoria corporativa de la empresa.

La operativa marítima es una de las actividades más prioritaria dentro de la empresa, en donde ser realizan procesos complejos, difíciles de determinar como pasos porque

presentan una variedad grande de posibilidades que se pueden dar en una situación

específica, y porque la mayoría de los procesos requieren de un conocimiento que es dado

por la experiencia, por el trabajo del día a día.

El tiempo en el que se realizan las tareas es muy importante porque se quiere que el barco sea atendido lo más rápido posible para que esté el menor tiempo en el muelle y

porque los índices de productividad están en relación directa con el manejo de los recursos

en función del tiempo, lo que hace que éste sea un concepto relevante. A continuación se

presenta el análisis de la operativa marítima con detenimiento.

4.3.1.2 De OM-2: Descripción de los aspectos de la organización que tienen impacto en o son afectados por el problema elegido en OM-1

En este documento quedarán consignados los aspectos más relevantes de la operación

marítima de la empresa Marítima Valenciana S.A.

1) Estructura: La empresa tiene un organigrama en forma jerárquica, que tiende a ser una estructura

plana. Ver Figura 4-1.

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


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


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


• 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


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


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


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


• Trunking. Es un sistema de comunicaciones vía radio que permite la transmisión de

datos y mensajes a todos los terminales, contemplando la conexión a sistemas de

posicionamiento GPS. El control del sistema se realiza a través de una consola donde

un operador analiza y optimiza el uso de la red. El envío de mensajes de estado y mensajes cortos permitirá integrar este sistema dentro del de gestión automático de la

terminal.

• El Sistema automático de gestión de la terminal (TOS) formado por un sistema

central en donde se encuentran los datos y las aplicaciones que se utilizan para

controlar y automatizar las operaciones dentro de la terminal. La plataforma

tecnológica sobre la que se asienta el sistema central es una pareja de Host AS/400

de última generación. Entre las múltiples aplicaciones, hay cuatro que se destacan:

− Control de puertas: Este sistema controla toda la información que se está

recibiendo desde las puertas de entrada o salida de la terminal y en él se asigna un identificador (TAC) de radiofrecuencia (RFID) al contenedor para controlar posteriormente su ubicación.

− Sistema de ubicación automática: Se encarga de buscar y seleccionar la mejor ubicación para los contenedores que entran en la terminal y de controlar la salida

de los mismos.

− Sistema de optimización de máquina: Este sistema controla que una vez que el sistema de ubicación automática asigna posición, se establezca la orden a la

máquina que esté mejor ubicada para que de manera óptima, en tiempo y

operativa, se realice el movimiento.

− Consola de operador local: Esta consola permite al controlador o supervisor realizar un completo seguimiento de las operaciones de la terminal.

El TOS también está formado por un Sistema de Comunicaciones y por un

Sistema Remoto. El de Comunicaciones se encarga de garantizar que todas las

decisiones y órdenes generadas en el sistema central lleguen a todos sus

destinatarios: Operadores Locales, - Puertas- Grúas Transtainers (RTT) - Grúas

Portainer - ReachStacker - Carretillas- Unidades Móviles. La tecnología utilizada

está basada en radio comunicaciones que permiten que el sistema sea actualizado

EN tiempo real. El Sistema Remoto se encarga de recoger la información de los

sensores de posición y lectores de TAG que tienen las grúas transtainer y portainer para mostrárselas al manipulador de la grúa a la vez que se transmiten a

través del sistema de comunicaciones.

Por último, hay muchas unidades móviles equipadas con un terminal que

acceden directamente a las aplicaciones del sistema central.

• Sistema de vigilancia: La terminal de contenedores cuenta con un amplio despliegue

de cámaras conformando un circuito cerrado de televisión. Mediante múltiples

teclados y monitores, y atendiendo a prioridades según el usuario de origen, se puede

examinar la operativa de la terminal. Así mismo, se pueden realizar grabaciones


múltiples en vídeo de hasta 16 cámaras 24h. al día registrando los posibles incidentes

tanto operativos como de seguridad.

• Sistemas informáticos: − Cuenta con una moderna infraestructura de comunicaciones de voz y datos para

conectar todas sus oficinas. Se tienen dos AS/400 para gestionar el TOS (Sistema

Operativo de la Terminal) y dos servidores que se encargan de conformar y

ofrecer los servicios propios de la Intranet de Marítima Valenciana (Ofimática, E-Mail, Internet, Publicación WEB Interna...) Adicionalmente, el sistema permite

establecer la comunicación con los armadores (agentes marítimos y

consignatarios).

− Hay tecnología de intercambio electrónico de documentos (EDI) específica para

el sector del transporte marítimo, lo cual permite hacer una gestión rápida y eficaz

de la información que de manera oficial y desde distintos orígenes llega al Puerto.

− Tienen una página WEB en donde además de tener la información anterior en

forma más detallada, ofrece unos servicios en línea que permiten acceder a

Operaciones Terrestres, Operaciones Marítimas, Planificación, Administración | Facturación, Consignaciones | Logística, Líneas | Ventas.

− Wincasp: Software que permite extraer del bayplan, el plano de las bodegas

(arrival).

− Ships: Software que se utiliza para generar la secuencia de carga.

5) Conocimiento: El conocimiento que se necesita para llevar acabo el proceso mencionado

anteriormente, es el siguiente:

• Los criterios de asignación de los barcos, es decir, el conocimiento que se requiere

para autorizar el atraque de un barco y el sitio en el muelle en donde éste debe

atracar.

• Planificación de los recursos que se demandan para llevar a cabo la carga y descarga

del barco. En especial la asignación de las manos y las grúas. Obviamente esto involucra tener criterios para la optimización de los recursos.

• Planeación de la secuencia de carga y descarga del barco.

• Criterios de optimización de las manos. Para saber cuándo y cuántas manos asignar a

cada uno de los barcos.

• Reglas de manejo de incidencia. Cuando hay información que no coincide con la

situación real de la carga en el barco o en el puerto, entonces se deben tener unas

reglas establecidas para determinar cómo hacer los cambios al plan previamente

definido.


6) Prioridad Asociada: Para la empresa Marítima Valenciana S.A. es fundamental que se mejore el proceso

que actualmente se tiene en el área de Operaciones Marítimas, con el objetivo de que se

cumpla con los criterios de calidad que allí se han establecido y se reflejen en sus índices de gestión (estos se presentan más adelante, en el formulario OM-5). Por lo tanto, en este

momento se dirá que la prioridad es la más alta.

7) Restricciones Temporales: Dentro de los criterios de calidad que se han establecido en esta área, se tienen algunos

que se relacionan directamente con el tiempo.

• En primer lugar, la atención de un barco debe ser lo más rápido posible, una vez él avise que está listo para atracar. Para la atención del barco (carga y descarga) se

miden unos índices de productividad relacionados con los movimientos (carga, descarga, en el muelle y en el barco) y el tiempo.

• La atención del barco es algo periódico, pues generalmente los barcos atracan en

períodos fijos, dados por una unidad de días. Esto no es rígido ni estático y puede

variar pues su cumplimiento depende muchas veces de factores externos como el clima, desperfectos o fallas en el barco, entre otros.

• Los procesos internos de las operaciones marítimas no se deben parar una vez se ha

iniciado el proceso global. Si esto ocurre, entonces se buscan las razones y se

corrigen. Los procesos se deben realizar en un orden específico. Así, que si un

proceso se retraza, afecta a los demás.

• Como el análisis que se realizó de este escenario se hizo a un nivel alto de

abstracción entonces no se identificaron restricciones temporales en forma

cuantitativa, aunque se sabe con certeza, que a más bajo nivel si las hay.

8) Cultura y poder: • Como se dijo anteriormente en el numeral 1), la empresa Marítima Valenciana sigue

una estructura jerárquica en su organización, lo que se refleja al interior de cada uno

de sus departamentos, por eso en Operaciones Marítimas se tiene una estructura

jerárquica, tal como se vio en la Figura 4-2.

• Un cargo puede ser desempeñado por diferentes personas, dependiendo del trabajo y

del turno realizado. Esto ocasiona que en algunos casos, se tengan visiones e ideas

diferentes para la misma situación.

• La operación marítima es la más prioritaria de todas. Esto sirve para determinar decisiones o asignación de recursos, en un momento dado.

9) Impacto: Como ya se manifestó anteriormente, en este proceso intervienen varias unidades de la

Marítima Valenciana: La Dirección Administrativa, Operaciones Terrestres, Operación


Marítima, Recursos Humanos y Servicios Jurídicos. Así, que un cambio en el proceso, inmediatamente se verá reflejado en los demás. Sería importante estudiar la situación

particular de cada una de las relaciones para observar como se comportarían ante los

cambios propuestos.

10) Conclusiones: El proceso que se está analizando es uno de los procesos fundamentales de la empresa,

que dan la razón de ser de la misma, por lo que todos los cambios que se hagan en ella se

verán reflejados en el resto de la empresa, especialmente en las unidades que tienen

relación con él. Si se introducen sistemas que optimizan el tiempo, los recursos y la toma de

decisiones dentro del proceso, se tendrán implicaciones importantes para otros procesos que

se realizan en las demás unidades. Esto es bueno si los demás están preparados, pero puede

tener riesgos asociados porque puede ocasionar cuellos de botellas o malestar en las

personas que no participan directamente en el proceso por sentir que los demás si pueden mejorar su rendimiento.

Se han planteado diversas alternativas para identificar las tareas de alto nivel más

relevantes y para proponer soluciones claves en ellas. Por esto, es importante continuar con

el análisis del modelo de la organización.

4.3.1.3 OM-3 Descripción del proceso en función de las Tareas de Alto Nivel (TAN) en que está compuesto

El proceso de la Operaciones Marítimas está formado por una o varias Tareas de Alto

Nivel – TAN que se caracterizan porque son completas, de gran alcance, tienen unos

objetivos definidos y unas salidas específicas. Para ello se cuenta con el Formulario 4-1

que facilita su comprensión.


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 conocimiento

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


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


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


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


167

contenedores en o del barco. Implica la

asignación

apropiada de

las manos


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



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


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.


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.


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


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


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


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.


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


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.


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


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


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,


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:


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).


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.


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.


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


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:


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.


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)


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;


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


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


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


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


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;


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.


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;


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.


4.4 Robot

Como ya se dijo anteriormente, el problema que vamos a resolver con el Robot no está

ubicado en ningún contexto organizacional, por lo que se obviarán muchos de los

planteamientos del modelo de la organización, en especial aquellos puntos que se refieren

al estudio de aspectos específicos de la empresa.

El problema ya está planteado, se conocen los procesos a modelar, y para propósitos

de validar la metodología es una necesidad la construcción de la aplicación. Todo esto se

puede considerar como precondiciones del proceso que facilitan el análisis de la solución.

En cuanto a la fase de análisis se incluye el modelo de la organización, el de TAN, el de conocimientos. No se presentan los modelos de agentes y de comunicación porque para esta situación no hay un agente en especial que sea quien realiza la TAN. En el momento en

que el sistema esté operando, el único que tendrá interacción con él es el usuario

programador que se encarga de encenderlo, ubicarlo en una posición específica y apagarlo. Aunque los sensores pueden tomarse como agentes software, si se trataran como externos al sistema, en este caso se han considerado como parte de él. Por ello también, es que no hay

comunicación entre agentes en el desarrollo de una TAN.

De la fase de diseño, se incluyen algunos apartes del diseño global, del detallado y se

presentan los resultados de una simulación que se hizo para este caso.

A continuación entonces, se comienza con la definición del problema, es decir, de la

situación inicial.

Este es un caso especial en donde se quiere mostrar que la metodología

CommonKADS-TR no se aplica solamente a casos basados en el conocimiento

relacionados con problemas específicos de una organización, sino que también sirve para

modelar situación en donde se requiera tener un comportamiento inteligente pero aislado de

un sistema organizacional específico. Por lo tanto, la especificación de los modelos de

CommonKADS-TR varía en que algunas cosas, pues no se tiene o no se requiere, la

información que se necesita en algunos de los formularios, en especial en el modelo de la

organización.


Condiciones iniciales: El robot está ubicado en un cuarto cerrado, micro mundo, que está delimitado por unas

paredes que lo cierran. Cada pared tiene un hueco con una forma geométrica básica

(rectángulo, triángulo, semi-círculo). El robot se encuentra situado en una posición inicial fija y conocida. Ese entorno es también conocido para él. También, hay una serie de objetos

con formas geométricas. En el cuarto, uno de los objetos está en algún lugar predefinido, establecido al azar. Dicho objeto debe ser encontrado por el robot, identificado y

desplazado a un lugar en una de las paredes, el cual debe coincidir con su forma física. Es


decir, el rectángulo debe ser guardado en la pared en donde se encuentre el hueco en forma

de rectángulo, y así para cada una de las formas definidas.

Objetivo: Dado un mundo cerrado que contiene figuras geométricas básicas y que sus paredes

tienen incrustaciones también de forma geométrica, se requiere construir un sistema en el que el robot pueda encontrar cada una de las piezas del mundo, identificarlas y ubicarlas en

su lugar respectivo (un proceso de reconocimiento y clasificación o asignación de formas). Las formas básicas son: el rectángulo, el triángulo y el semi-círculo. Ver figura 4-1.

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


• 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


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


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.


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


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


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


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


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


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.


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


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.


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, ...).


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


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.


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


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


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:


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


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


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.


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.


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.


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:


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.


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


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.


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.


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.


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


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.


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.


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.


228



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.


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.


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


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.


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/


233

[Sel96a] B. Selic. An Efficient Object-Oriented Variation of the Statecharts

Formalism for Distributed Real-Time Systems. ObjectTime. Ontario,

Canada. 1996. 8 p.


[Sel96b] B. Selic. Periodic Tasks in ROOM. ObjectTime. Ontario, Canada. 1996.

4 p.


[SFR98] M. Saksena, M. Freedman, P. Rodziewicz. Guidelines for Automated

Implementation of Executable Object Oriented Models for Real-Time

Embedded Control Systems. 13 p.

http://citeseer.nj.nec.com/204508

[SGW94] B. Selic, G. Gullekson, P. Ward. Real-Time Object-Oriented Modeling.

John Wiley & Sons. The United States of America. 1994. 507 p.

[ShC94] K. Shere, R. Carlson. A Methodology for Design, Test, and Evaluation or

Real-Time Systems. IEEE Computer. February 1994. pp. 35-48.

[SkG89] D.B. Skillicorn, J.I. Glasgow. Real-Time Specification Using Lucid.

IEEE Transactions on Software Engineering, Vol. 15 Nª 2. 1989. pp.

221-229.

[Sta88] J. Stankovic. Misconceptions About Real-Time Computing. IEEE

Computer, Vol. 21 N. 10, Oct. 1988. pp10-19.

[Sta92] J. Stankovic. Distributed Real-Time Computing: The Next Generation.

MIT, USA: Technical Report 1992-001, 1992. 16 p.

[StR93] J. Stankovic, K. Ramamritham. What is the Predictability for Real-Time

Systems? Advances in Real-Time Systems. Edited by: John A. Stankovic

and Krithi Ramamritham. IEEE Computer Society Press, California.

1993. 777 p.

• Sistema basado en el conocimiento de tiempo real

[AlS85] M. Ali, D. Scharnhorst. Sensor-Based Fault Diagnosis in a Flight Expert

System. In Proceedings of the Second Conference on Artificial

Intelligence Applications. Washington D.C., IEEE Computer Society.

1985. pp. 49-52.


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.


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.


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/


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.



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.


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?


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?


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?

Tesis Doctoral - Dpto. de Sistemas Informáticos y ... · Los sistemas basados en el conocimiento...

Documents

Transcript of Tesis Doctoral - Dpto. de Sistemas Informáticos y ... · Los sistemas basados en el conocimiento...