Universidad Politécnica de Valencia Departamento de Sistemas Informáticos y Computación

Tesis Doctoral

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

Mónica Henao Cálad Director:

Dr. Vicente Botti Navarro Valencia, España. Abril de 2.001

Título:

CommonKADS-RT: Una metodología para el desarrollo de sistemas basados en el conocimiento de tiempo real.

Autor: MSc. Mónica Henao Cálad Director: Dr. Vicente Botti Navarro Tribunal: Presidente: Dr. Federico Barber Sanchís Secretario: Dra. Eva Onaindía de la Rivaherrera Vocales titulares: Dr. Richard Benjamins Dr. Fernando Martín Rubio Dr. Carlos Iglesias Fernández Vocales suplentes: Dra. Ana García Serrano Dr. José Ramón Rizo Aldeguer

Valencia – España 12 de junio de 2001

A mi esposo Riche, que siempre me ha animado, apoyado y brindado su amor y comprensión, estando a mi lado en todo momento

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

Reconocimientos Hay muchas personas a las que quisiera agradecerle toda su colaboración, amistad y apoyo durante este largo recorrido, pero en este momento quiero resaltar los siguientes: Al Doctor Vicente Botti, por su orientación, asesoría y soporte que me permitió culminar exitosamente este proyecto. A los miembros del Grupo de Tecnologías Informáticas (GTI) del Departamento de Informática y Computación (DSIC) de la Universidad Politécnica de Valencia quienes siempre me apoyaron y me dieron su conocimiento y amistad. A los profesores del DSIC que me dieron la oportunidad de realizar este doctorado, a través de sus enseñanzas. En especial a la Dra. Matilde Celma, responsable del programa. A los coordinadores del convenio UNAL-UPV y directivas de la UPV quienes hicieron posible la realización de este doctorado y de las diferentes pasantías que realicé durante la investigación. A los integrantes del Departamento de Informática y Sistemas de la Universidad EAFIT, por su apoyo e interés. A las directivas de la Universidad EAFIT por su patrocinio y soporte en la realización del doctorado. Al postgrado de Sistemas de la Universidad Nacional de Colombia, sede Medellín por su colaboración en la realización de los cursos doctorales. A mi familia y amigos que siempre me animaron y comprendieron todas mis ausencias.

CommonKADS-RT – Resumen

Resumen Los sistemas basados en el conocimiento de tiempo real son sistemas informáticos que manejan el conocimiento de un dominio específico y tienen la capacidad de garantizar una respuesta en un tiempo fijo, dado que manejan restricciones temporales. Estos sistemas se han utilizado para solucionar problemas de control de procesos, monitorización, diagnóstico y mantenimiento de fallos, entre otras. Es decir, en situaciones en donde la toma de decisiones es dependiente del tiempo. Básicamente las investigaciones en estos sistemas han estado enfocadas hacia su arquitectura, sobre cómo lograr el cumplimiento de las garantías temporales en el razonamiento del conocimiento o sobre cómo modificar las políticas de planificación de tiempo real para que sean más predecibles. No se han hecho muchos trabajos sobre cómo construir un sistema de este tipo, sobre qué actividades deben ser realizadas para plantear un proyecto que pretenda la creación del sistema o cuáles son las pautas que se deben seguir en dicho desarrollo. Es por esto, por lo que se ha planteado proponer una metodología para el desarrollo de sistemas basados en el conocimiento de tiempo real, surgiendo CommonKADS-RT. Esta tesis se centra en el estudio de los sistemas basados en el conocimiento, los sistemas de tiempo real, los sistemas basados en el conocimiento de tiempo real y los métodos o metodologías que se han propuesto para el desarrollo de cada uno de esos sistemas. Esto ha servido para desarrollar CommonKADS-RT, basada en la metodología CommonKADS para sistemas basados en el conocimiento y RT-UML para sistemas de tiempo real. CommonKADS-RT permite seguir, en una forma comprensible y sencilla la construcción de un sistema basados en el conocimiento de tiempo real. Está fundamentada en el desarrollo evolutivo, la orientación por riesgos y sigue los planteamientos que la Ingeniería del Software propone para lo que debe ser una buena metodología. En CommonKADS-RT se plantea que un sistema basado en el conocimiento de tiempo real se construye a través del desarrollo de siete modelos del problema o su solución: el modelo de la organización que describe la empresa u organización en donde se encuentra el problema y en donde se implantará la solución; el modelo de tareas de alto nivel para representar los procesos del negocio relacionado con el problema; el modelo de agentes para especificar las personas y los sistemas automáticos que participan en el problema y su solución; el modelo de conocimientos que precisa el conocimiento que poseen los agentes para realizar la tarea de alto nivel; el modelo de comunicaciones para expresar los actos de comunicación que realizan los diferentes agentes que participan en el sistema, para compartir su conocimiento y lograr el objetivo de las tareas de alto nivel; el modelo de diseño en donde se describe la arquitectura y la especificación del diseño global del sistema; y el modelo de tareas de tiempo real para definir la estructura genérica de una tarea de tiempo real. Los primeros cinco modelos forman la fase de análisis y los dos últimos la fase del diseño.

CommonKADS-RT – Resumen

Para cada uno de los modelos se plantea su objetivo, los formularios que permiten guiar su proceso de construcción y reflejar la información para incluir en la documentación del proceso, los artefactos que resultan del desarrollo del modelo y los roles más importantes que participan en dicho proceso. Adicionalmente, las consideraciones metodológicas propuestas en esta tesis, incluyen la determinación de cuándo es apropiado construir un sistema basado en el conocimiento de tiempo real y si ésta es la mejor alternativa de solución, a través de unos criterios de filtrado y de una caracterización del dominio en donde es posible utilizar la metodología. Para mostrar la aplicación de la metodología se presenta dos casos reales y diferentes en donde ésta se ha utilizado. En el primer escenario se pone énfasis en la etapa de análisis, especialmente en el modelo de la organización. En el segundo se resalta la fase de diseño, en particular la arquitectura del sistema y el modelo de tareas de tiempo real. Como resultado de esta investigación se han realizado las siguientes publicaciones: BOTTI V. Henao M. Soler J. Método de análisis para modelar sistemas basados en el conocimiento en tiempo real. Memorias de la VIII Conferencia de la Asociación Española para la Inteligencia Artificial, CAEPIA'99. Murcia, España. 1999, pp. 17-25. HENAO, Mónica. CommonKADS: Una buena herramienta para la gerencia del conocimiento. Revista Universidad EAFIT No. 115. Medellín, Colombia. 2000, pp. 77-93. SOLER, J. Henao, M. Botti V. A Mobile Robot Application with an Analysis Method based on CommonKADS. Proceedings of the IASTED International Conference: Intelligent Systems and Control (ISC 2000). 2000, pp. 299-303. HENAO, M., Soler, J. Botti. La integración de sistemas basados en el conocimiento y sistemas de tiempo real por medio de un robot móvil. Workshop Luso - Hispano de Agentes Físicos. Madrid, España. 2001, pp. 49-60. HENAO, M., Soler, J. Botti V. Developing a Mobile Robot Control Application with CommonKADS-RT. IEA/AIE 2001, The Fourteenth International Conference on Industrial & Engineering Applications of Artificial Intelligence & Expert Systems. Budapest, Hungary. 2001. (pendiente de publicar)

CommonKADS-RT – Resumen

Abstract Real-time knowledge-based systems are computer systems with two main abilities. On the one hand, they can manage knowledge about a specific domain. On the other hand, they are able to guarantee an answer in a fixed time, given that they can manage temporal restrictions. Systems of this kind have been used for solving several types of problems, such as process control systems, monitoring, diagnosis and fault maintenance systems. In general, these systems are applicable in systems where decision making is dependent on time. In the past, research about such systems has been focused towards issues as their architectures, mechanisms to obtain strict timing guarantees in the reasoning process or modifications to real-time scheduling policies in order to make them more predictable. However, not much of this research has been oriented on how to build such systems, the activities involved in developing a project to create these systems, or the guidelines to follow in that development. In this context, this work proposes a new methodology for developing real-time knowledge-based system. This new methodology is called CommonKADS-RT. This doctoral thesis is centered in the study of knowledge-based systems, real-time systems, real-time knowledge-based systems and the methods and methodologies which have been proposed for developing each of these types of systems. All this has been used for developing CommonKADS-RT. This methodology is, in turn, based on two methodologies: CommonKADS, for the development of knowledge-based systems, and RT-UML, for the development of real-time systems. CommonKADS-RT allows to follow, in a understandable and easy way, the building of a real-time knowledge-based system. This new methodology is based on both the evolving development and the risk orientation, and it follows the guidelines proposed by Software Engineering for creating a good methodology. CommonKADS-RT proposes a real-time knowledge-based system to be built by means of the development of seven problem (or solution) models. The organization model describes the organization or company which has the problem, that is, the organization on which the solution will be developed. The high-level task model represents the business processes related with the problem. The agent model specifies the persons and the automated systems which participate in the problem and its solution. The knowledge model represents the knowledge that agents have for performing the high-level task. The communication model expresses the communication acts executed by the agents that participate in the system; this model is also used by agents for sharing their knowledge and therefore for achieving the goals of the high-level tasks. The design model describes the architecture and specifies the global design of the system. And the real-time task model defines the generic structure of a real-time task. The five former models constitute the analysis phase, while the two latter models form the design phase. For each of these models, the following aspects are described: its objective, the forms which allow to guide its developing process and to gather the information to be included in

CommonKADS-RT – Resumen

the process documentation, the artifacts which result from the model development and the most important roles which participate in that process. The methodological proposals of this thesis also include the determination of when it is appropriate to build a real-time knowledge-based system and whether this is the best alternative. This is done by means of some filtering criteria and a characterization of the domains on which it is possible to use the methodology. In order to show the applicability of this new methodology, this thesis also presents two real cases on which it has been applied. In the first scenario, the emphasis is on the analysis phase, and specially on the organization model. In the second scenario, the design phase is more deeply developed, specially the system architecture and the real-time task model. Some of the proposals of this thesis have been published in the following conferences: BOTTI V. Henao M. Soler J. Método de análisis para modelar sistemas basados en el conocimiento en tiempo real. Memorias de la VIII Conferencia de la Asociación Española para la Inteligencia Artificial, CAEPIA'99. Murcia, España. 1999, pp. 17-25. HENAO, Mónica. CommonKADS: Una buena herramienta para la gerencia del conocimiento. Revista Universidad EAFIT No. 115. Medellín, Colombia. 2000, pp. 77-93. SOLER, J. Henao, M. Botti V. A Mobile Robot Application with an Analysis Method based on CommonKADS. Proceedings of the IASTED International Conference: Intelligent Systems and Control (ISC 2000). 2000, pp. 299-303. HENAO, M., Soler, J. Botti. La integración de sistemas basados en el conocimiento y sistemas de tiempo real por medio de un robot móvil. Workshop Luso - Hispano de Agentes Físicos. Madrid, España. 2001, pp. 49-60. HENAO, M., Soler, J. Botti V. Developing a Mobile Robot Control Application with CommonKADS-RT. IEA/AIE 2001, The Fourteenth International Conference on Industrial & Engineering Applications of Artificial Intelligence & Expert Systems. Budapest, Hungary. 2001.

CommonKADS-RT – Resumen

Resum Els sistemes basats en el coneixement i de temps real són sistemes informàtics que manegen el coneixement d’un domini específic i tenen la capacitat de garantir una resposta en un temps fixe, donat que tenen restriccions temporals. Aquestos sistemes s’han utilitzat per a resoldre problemes de control de processos, monitoritzacio, diagnòstic i manteniment de fallades, i daltres. Es a dir, en situacions a on la presa de decisions és dependent del temps. Bàsicament les investigacions en aquestos sistemes han estat enfocades cap a la seva arquitectura, sobre com aconseguir el compliment de les garanties temporals en el raonament del coneixement o sobre com canviar les polítiques de planificació de temps real per que siguen més predibles. No s’han desenvolupat molts treballs sobre com construir un sistema d’aquest tipus, sobre què activitats deuen ser realitzades per a plantejar un projecte que tracte la creació del sistema o sobre quines són les pautes a seguir en aquest desenvolupament. Es per això, per que s’ha plantejat proposar una metodologia pel desenvolupament de sistemes basats en el coneixement de temps real, d’aquesta manera es planteja CommonKADS-RT. La tesi es centra en l’estudi dels sistemes basats en el coneixement, els sistemes de temps real, els sistemes basats en el coneixement de temps real i els mètodes o metodologies que s’han proposat pel desenvolupament de cada un d’aquestos sistemes. Açò ha servit per a desenvolupar CommonKADS-RT, basada en la metodologia CommonKADS per a sistemes basats en el coneixement i RT-UML per a sistemes de temps real. CommonKADS-RT permet seguir, de forma comprensible i senzilla la construcció d’un sistema basat en el coneixement de temps real. Es fonamenta al desenvolupament evolutiu, l’orientació per riscs i segueix els plantejaments que l'Enginyeria del Programari proposa com el que ha de ser una bona metodologia. En CommonKADS-RT es planteja que un sistema basat en el coneixement de temps real es construirà mitjançant el desenvolupament de set models del problema o la seva solució: el model de l’organització que descriu l’empresa o organització a on es troba el problema i a on s’implantarà la solució; el model de tasques d’alt nivell per representar els processos del negoci relacionats amb el problema; el model d’agents per a especificar les persones i els sistemes automàtics que participen en el problema i la seva solució; el model de coneixement que precisa el coneixement que tenen els agents per a realitzar la tasca d’alt nivell; el model de comunicacions per expressar els actes de comunicació que realitzen els diferents agents que participen en el sistema, per a compartir el seu coneixement i aconseguir l’objectiu de la tasca d’alt nivell; el model de disseny on es descriu l’arquitectura i l’especificació del disseny global del sistema; i el model de tasques de

CommonKADS-RT – Resumen

temps real per a definir l’estructura genèrica d’una tasca de temps real. Els primers cinc models formen la fase d’ anàlisi i els dos últims la fase de disseny. Per a cada model es planteja el seu objectiu, els formularis que permeten guiar el seu procés de construcció i reflectir l’informació per a incloure en la documentació del procés, els artefactes que resulten del desenvolupament del model i els rols més importants que participen en dit procés. A més a més, les consideracions metodològiques propostes en aquesta tesi, inclouen la determinació de quan és apropiat construir un sistema basat en el coneixement de temps real i si aquesta és la millor alternativa de solució, mitjançant uns criteris de filtrat i una caracterització del domini on és possible utilitzar la metodologia. Per a mostrar l’aplicació de la metodologia es presenten dos casos reals i diferents on s’ha utilitzat. En el primer escenari es posa l’èmfasi en l’etapa d’anàlisi, especialment en el model de l’organització. En el segon es ressalta la fase de disseny, en particular l’arquitectura del sistema i el model de tasques de temps real. Com a resultat d’aquesta investigació, s’han realitzat les següents publicacions: BOTTI V. Henao M. Soler J. Método de análisis para modelar sistemas basados en el conocimiento en tiempo real. Memorias de la VIII Conferencia de la Asociación Española para la Inteligencia Artificial, CAEPIA'99. Murcia, España. 1999, pp. 17-25. HENAO, Mónica. CommonKADS: Una buena herramienta para la gerencia del conocimiento. Revista Universidad EAFIT No. 115. Medellín, Colombia. 2000, pp. 77-93. SOLER, J. Henao, M. Botti V. A Mobile Robot Application with an Analysis Method based on CommonKADS. Proceedings of the IASTED International Conference: Intelligent Systems and Control (ISC 2000). 2000, pp. 299-303. HENAO, M., Soler, J. Botti. La integración de sistemas basados en el conocimiento y sistemas de tiempo real por medio de un robot móvil. Workshop Luso - Hispano de Agentes Físicos. Madrid, España. 2001, pp. 49-60. HENAO, M., Soler, J. Botti V. Developing a Mobile Robot Control Application with CommonKADS-RT. IEA/AIE 2001, The Fourteenth International Conference on Industrial & Engineering Applications of Artificial Intelligence & Expert Systems. Budapest, Hungary. 2001. (pendent de publicar)

CommonKADS-RT – Tabla de contenido

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 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.2.7

Generalidades de los sistemas basados en el conocimiento............................... 14 Clasificación de los sistemas basados en el conocimiento................................. 15 Arquitectura de un sistema basado en el conocimiento ..................................... 18 Procesos en el desarrollo de sistemas basados en el conocimiento .................... 22 Metodologías para el desarrollo de sistemas basados en el conocimiento.......... 25 Metodología CommonKADS .......................................................................... 31 Ventajas y desventajas de CommonKADS....................................................... 49

2.3

Sistemas de tiempo real............................................................. 51

2.3.1 2.3.2 2.3.3 2.3.4 2.3.5

Generalidades de los sistemas de tiempo real ................................................... 51 Especificación de los sistemas de tiempo real .................................................. 53 Métodos para desarrollar sistemas de tiempo real............................................. 56 Metodología RT-UML .................................................................................... 70 Ventajas y desventajas de RT-UML................................................................. 77

2.4

Sistemas basados en el conocimiento de tiempo real................ 79

2.4.1 2.4.2 2.4.3

Generalidades de los sistemas basados en el conocimiento de tiempo real ........ 79 Tipos de sistemas basados en el conocimiento de tiempo real........................... 81 Aplicaciones reconocidas de los sistemas basados en el conocimiento de tiempo real .................................................................................................... 82 Metodologías para desarrollar sistemas basados en el conocimiento de tiempo real .................................................................................................... 84

2.4.4

i

CommonKADS-RT – Tabla de contenido

2.5

Conclusiones del estado del arte ............................................... 86

2.5.1 2.5.2 2.5.3

Conclusiones de sistemas basados en el conocimiento...................................... 86 Conclusiones de sistemas de tiempo real.......................................................... 87 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 Fortalezas y debilidades de RT-UML para sistemas basados en el conocimiento de tiempo real............................................................................ 93 Descripción general de CommonKADS-RT..................................................... 94 ¿Por qué un modelo para las tareas de tiempo real?.......................................... 97

3.3.2 3.3.3 3.3.4

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 3.6.2 3.6.3 3.6.4 3.6.5 3.6.6 3.6.7

Modelo de la organización............................................................................. 101 Modelo de tareas de alto nivel ....................................................................... 115 Modelo de agentes ........................................................................................ 120 Modelo de conocimiento ............................................................................... 125 Modelo de comunicaciones ........................................................................... 131 Modelo de diseño.......................................................................................... 134 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 4.2.2

Escenario de la operativa marítima del Puerto Príncipe Felipe de Valencia..... 151 Escenario de una aplicación con un robot móvil navegante ............................ 152

ii

CommonKADS-RT – Tabla de contenido

4.3

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

4.3.1 4.3.2 4.3.3 4.3.4

Modelo de la organización............................................................................. 152 Modelo de tareas de alto nivel ....................................................................... 178 Modelo de agentes ........................................................................................ 180 Modelo de conocimientos.............................................................................. 183

4.4

Robot

4.4.1 4.4.2 4.4.3 4.4.4 4.4.5

Modelo de la organización............................................................................. 190 Modelo de tareas de alto nivel ....................................................................... 194 Modelo de conocimiento ............................................................................... 194 Modelo de diseño.......................................................................................... 197 Modelo de tareas de tiempo real .................................................................... 206

4.5

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

Capítulo 5.

.................................................................................. 190

Conclusiones y trabajos futuros

211

5.1

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

5.2

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

5.3

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

5.4

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

ABREVIATURAS

221

REFERENCIAS

223

ANEXO 1

239

iii

CommonKADS-RT – Índice de figuras

ÍNDICE DE FIGURAS Figura 1-1

Los sistemas basados en el conocimiento de tiempo real..................2

Figura 1-2

Alcance y objetivo de esta tesis..................................................... 10

Figura 2-1

Fases del ciclo de vida de MIKE................................................... 29

Figura 2-2

Modelos de CommonKADS ......................................................... 34

Figura 2-3

Modelo de la organización de CommonKADS.............................. 36

Figura 2-4

Modelo de tareas de CommonKADS ............................................ 38

Figura 2-5

Modelo de agentes de CommonKADS.......................................... 41

Figura 2-6

Jerarquía del modelo de conocimientos de CommonKADS ........... 42

Figura 2-7

Modelo de comunicaciones de CommonKADS............................. 44

Figura 2-8

Pasos del diseño del sistema ......................................................... 45

Figura 2-9

Documentación del ciclo de la gestión del proyecto en CommonKADS............................................................................ 48

Figura 2-10

Elementos nuevos del Diagrama de Flujo...................................... 60

Figura 2-11

Modelado de un respirador artificial.............................................. 61

Figura 2-12

Modelado de un respirador artificial.............................................. 61

Figura 2-13

Procesos fundamentales del desarrollo con ROOM ....................... 66

Figura 2-14

MCSE .......................................................................................... 68

Figura 2-15

Ejemplo de un gráfico de casos de uso .......................................... 73

Figura 2-16

Ejemplo de un diagrama de secuencia ........................................... 74

Figura 2-17

Apartes de un Diagrama de Estados para un sistema telefónico...... 75

Figura 2-18

Apartes de un diagrama de actividades.......................................... 75

Figura 2-19

Diagrama de Componentes ........................................................... 76

Figura 2-20

Apartes de un diagrama de despliegue en UML............................. 76

Figura 3-1

Modelos de CommonKADS-RT ................................................... 95

Figura 3-2

Ciclo de Desarrollo en CommonKADS-RT................................. 100

Figura 3-3

Ciclo de Implantación del SBCTR .............................................. 100

Figura 3-4

Modelos de CommonKADS-RT en UML ................................... 101

Figura 3-5

Relación entre la empresa Marítima Valenciana y el Armador ..... 106

Figura 3-6

Diagrama de Cooperación de TAN ............................................. 108

Figura 3-7

Forma general de un Diagrama de Contexto para el SBCTR........ 110

v

CommonKADS-RT – Índice de figuras

Figura 3-8

Modelo de la organización de CommonKADS-RT...................... 114

Figura 3-9

Ejemplo de diagramas de secuencia a) y b) ................................. 124

Figura 3-10

Ejemplo de un caso de uso para algunos agentes en la terminal de contenedores del puerto de Valencia....................................... 125

Figura 3-11

Bases de ARTIS ......................................................................... 135

Figura 3-12

Arquitectura global de un SBCTR............................................... 136

Figura 3-13

Diagrama de componentes principales del robot .......................... 138

Figura 3-14

Topología de ARTIS .................................................................. 139

Figura 3-15

Contenido del Modelo de Tareas de Tiempo Real........................ 145

Figura 3-16

Estructura de la tarea de tiempo real a bajo nivel ......................... 147

Figura 3-17

Ejemplo de un in-agent............................................................... 148

Figura 4-1

Organigrama de Marítima Valenciana......................................... 155

Figura 4-2

Organigrama de Operaciones Marítimas ..................................... 156

Figura 4-3

Vista general de atención a un buque en el puerto de Valencia..... 156

Figura 4-4

Diagrama de Actividades de los procesos que se realizan en la Operaciones Marítimas............................................................... 157

Figura 4-5

Relación entre la empresa Marítima Valenciana y el Armador ..... 158

Figura 4-6

Relación entre la empresa Marítima Valenciana y Sevasa............ 158

Figura 4-7

Relación entre las manos de Sevasa y las unidades de Marítima Valenciana ................................................................................. 159

Figura 4-8

Relación entre el conductor del transtainer y Operaciones Marítimas................................................................................... 159

Figura 4-9

Relación entre el consignatario del Armador y la unidad Planificación .............................................................................. 160

Figura 4-10

Relación entre el Planner del Armador y la unidad Planificación .............................................................................. 160

Figura 4-11

Relación entre el agente del Armador y la unidad Secuenciación ............................................................................ 160

Figura 4-12

Relación del Capitán del barco con Marítima Valenciana ............ 160

Figura 4-13

Relación del Primer oficial del barco con Comunicaciones.......... 160

Figura 4-14

Diagrama de casos de uso de las operaciones marítimas .............. 161

Figura 4-15

Vista general del SBCTR para la Planificación en la TAN Planificación .............................................................................. 174

vi

CommonKADS-RT – Índice de figuras

Figura 4-16

SBCTR ubicado en las actividades de la empresa Marítima Valenciana ................................................................................. 174

Figura 4-17

Diagrama de Flujo de la TAN PLAN .......................................... 179

Figura 4-18

Diagrama de Conceptos – Conocimiento del Dominio - de Operaciones Marítimas............................................................... 184

Figura 4-19

Diagrama de estados de Bayplan................................................. 185

Figura 4-20

Diagrama de estados de Pila ....................................................... 185

Figura 4-21

Diagrama de estados de Posición ................................................ 186

Figura 4-22

Diagrama de estados de Contenedor............................................ 186

Figura 4-23

Un micro mundo posible para que el robot navegue..................... 191

Figura 4-24

Proceso que debe realizar el robot para cumplir con el objetivo final ........................................................................................... 192

Figura 4-25

Detalle de las actividades de la TAN 2 - Buscar Objeto ............... 194

Figura 4-26

Diagrama de Conceptos para el sistema del robot móvil en el micro mundo .............................................................................. 195

Figura 4-27

Diagrama de transición de estados del Planificador ..................... 196

Figura 4-28

Diagrama de transición de estados del PlanAcción ...................... 196

Figura 4-29

Diagrama de secuencia entre el concepto Robot y el Planificador................................................................................ 197

Figura 4-30

Diagrama de componentes principales del robot .......................... 198

Figura 4-31

Diagrama que representa el inicio de la conexión ........................ 205

Figura 4-32

TAN en ARTIS .......................................................................... 206

Figura 4-33

Estado inicial del micro mundo................................................... 208

Figura 4-34

Estado final del micro mundo ..................................................... 208

Figura 4-35

El Pioneer 2 enfrente de un objeto de forma rectangular .............. 209

vii

CommonKADS-RT – Índice de tablas

ÍNDICE DE TABLAS Tabla 2-1

Características y beneficios del método HPM................................ 59

Tabla 3-1

Relación entre las etapas del ciclo de vida y los modelos de CommonKADS-RT.................................................................... 101

Tabla 3-2

Descripción de las tareas de alto nivel a través de los eventos que las afectan............................................................................ 119

Tabla 3-3

Ejemplo de la lista de eventos externos que tienen relación con el sistema ................................................................................... 122

Tabla 3-4

Tabla de eventos para el caso de un ascensor............................... 123

Tabla 3-5

Estructura de un mensaje según FIPA ......................................... 132

Tabla 3-6

Especificación de los componentes del SBCTR........................... 137

Tabla 4-1

Descripción de la tarea asignación .............................................. 186

Tabla 4-2

Descripción de la tarea de planificación de carga y descarga del barco .................................................................................... 188

Tabla 4-3

Descripción de la tarea Scheduling para realizar la secuencia de carga y descarga del barco...................................................... 188

Tabla 4-4

Comparación de la información enviada por el robot Pioneer con un robot general. .................................................................. 200

ix

CommonKADS-RT – Índice de formularios

ÍNDICE DE FORMULARIOS Formulario 3-1

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

Formulario 3-2

OM-2: Descripción de los aspectos de la organización que tienen impacto en o están afectados por el problema elegido en OM-1 ......................................................................................... 105

Formulario 3-3

OM-3: Descripción del proceso en función de las tareas de alto nivel en que está compuesto........................................................ 107

Formulario 3-4

OM-4: Descripción del componente de conocimiento del modelo de la organización .......................................................... 108

Formulario 3-5

OM-5: Descripción de los aspectos de la organización que tendrán impacto o estarán afectados por la solución escogida del SBCTR................................................................................. 109

Formulario 3-6

Lista de eventos externos que tienen relación con el sistema........ 111

Formulario 3-7

OM-6. Lista de chequeo para el documento de viabilidad de la decisión de hacer un SBCTR ...................................................... 112

Formulario 3-8

TM-1: Descripción refinada de las tareas de alto nivel dentro del proceso objetivo.................................................................... 117

Formulario 3-9

TM-2 Especificación del conocimiento empleado en la tarea de alto nivel y posibles cuellos de botella y áreas para mejorar......... 119

Formulario 3-10

AM-1: Especificación de los agentes del SBCTR ........................ 122

Formulario 3-11

KM-1: Lista de comprobación de la documentación del modelo del conocimiento ........................................................................ 127

Formulario 3-12

CM-1: Especificación de las transacciones que posibilitan el diálogo entre dos agentes en el modelo de comunicación............. 133

Formulario 3-13

CM-2: Especificación de los mensajes y los puntos de información que hacen una transacción individual dentro del modelo de comunicación ............................................................ 134

Formulario 3-14

DM-1: Descripción de la arquitectura del sistema........................ 142

xi

CommonKADS-RT – Índice de formularios

Formulario 3-15

DM-2: Especificación de las facilidades ofrecidas por y en el sistema que será implantado........................................................ 143

Formulario 3-17

DM-3: Lista de chequeo de decisiones en relación con la especificación de la arquitectura ................................................. 143

Formulario 3-18

DM-4: Decisiones del diseño de la aplicación ............................. 144

Formulario 3-19

Especificación de las tareas de tiempo real .................................. 150

Formulario 4-1

OM-3: TAN del Proceso de la atención y prestación de servicios marítimos..................................................................... 167

Formulario 4-2

OM-4: Descripción del componente de conocimiento del modelo de la organización .......................................................... 170

Formulario 4-3

OM-5: Descripción de los aspectos de la organización que tendrán impacto en o estarán afectados por la solución escogida del SBCTR................................................................... 173

Formulario 4-4

TM-1: Descripción refinada de las tareas de alto nivel dentro del proceso objetivo.................................................................... 179

Formulario 4-5

TM-1.1: TAN PLANIFICACIÓN (PLAN).................................. 182

Formulario 4-6

AM-1: Especificación de los Agentes del SBCTR ....................... 183

Formulario 4-7

Descripción del proceso en función de las TAN que lo componen................................................................................... 193

xii

CommonKADS-RT – Capítulo 1. Introducción y objetivos

1

Capítulo 1. Introducción y objetivos 1.1

Introducción

Los grandes avances en las tecnologías de los sistemas inteligentes y de los sistemas de tiempo real, así como la necesidad que tienen las grandes industrias de tener software y sistemas informáticos cada vez más complejos que respondan en tiempos definidos y que manejen sus conocimientos de acuerdo con los cambios del entorno, han motivado la investigación y el desarrollo de nuevas aplicaciones que tratan de solucionar, de la manera más apropiada, dichos requerimientos. Por el lado de los sistemas inteligentes, los sistemas basados en el conocimiento y los agentes han revolucionado el concepto de cooperación, el manejo apropiado del conocimiento, la distribución y el compartimiento del conocimiento, la reutilización y la especialización de la información y la experiencia de un dominio. Por el lado de los sistemas de tiempo real, cada vez los sistemas son más sofisticados para llevar a cabo su función en entornos complejos y dinámicos, requiriendo tener mas conocimiento y una mejor comunicación para responder adecuadamente, de acuerdo con situaciones específicas para que se tomen las decisiones más apropiadas. La confluencia de estas tecnologías está motivando la investigación y el desarrollo de nuevos tipos de aplicaciones y de sistemas informáticos. Una categoría de estos sistemas corresponde a los sistemas inteligentes de tiempo real, en particular a los sistemas basados en el conocimiento de tiempo real, los cuales mediante el manejo de restricciones de tiempo y de conocimiento específico de un dominio ofrecen una serie de ventajas entre las cuales se puede mencionar la puntualidad de la información, el aprovechamiento del conocimiento generado en la misma empresa o en un campo específico del saber y la respuesta correcta en el momento oportuno. Ver Figura 1-1. Han tomado tanta importancia los sistemas inteligentes de tiempo real que muchos grupos de investigación ha propuesto arquitecturas específicas para su construcción, han creado aplicaciones que resaltan la potencialidad de las mismas y se han comenzado a introducir en la industria en general. Para ello, es necesario contar con las herramientas necesarias, tanto de software, de hardware como de orgware, para que se puedan hacer de

CommonKADS-RT – Capítulo 1. Introducción y objetivos

2

la mejor manera. Las metodologías de desarrollo forman parte de las herramientas del orgware, además de muchas políticas y estrategias organizacionales.

Sistemas de Tiempo Real

Sistemas Basados en el Conocimiento

Sistemas basados en el conocimiento de tiempo real

Figura 1-1 Los sistemas basados en el conocimiento de tiempo real

Para proponer aspectos metodológicos específicos para los sistemas basados en el conocimiento, es importante especificar lo que se quiere decir con Consideraciones Metodológicas, con Sistemas Basados en el Conocimiento - SBC, con Sistemas de Tiempo Real - STR y con Sistemas Basados en el Conocimiento de Tiempo Real – SBCTR. Todo esto conforma el marco teórico y conceptual de esta tesis, que se trata como un capítulo completo con objetivos muy precisos y que tiene sus propias conclusiones y referencias pertinentes para cada tema. Pero, dentro de esta introducción, se considera relevante acordar lo que se entiende por los términos: metodología, método, proceso de software, entre otros conceptos que se trabajan apropiadamente desde la Ingeniería del Software. Es importante también aclarar, que no se pretende construir una ontología para ello, sino simplemente definir lo que se entenderá cada vez que se presente uno de estos términos en esta disertación, teniendo como eje central los planteamientos de la Ingeniería del Software, por ser ésta la encargada en la informática de proponer los conceptos relacionados con el proceso de desarrollo del software. Partiendo de lo que la Real Académica de la Lengua Española define en su diccionario de 1992, las palabras metodología y método se han definido de la siguiente forma: Metodología: 1. Ciencia del método. 2. Conjunto de métodos que se siguen en una investigación científica o en una exposición doctrinal. Método: 1. Modo de decir o hacer con un orden una cosa. 2. Modo de obrar o de proceder, hábito o costumbre que cada uno tiene y observa. 3. Procedimiento que se sigue en las ciencias para hallar la verdad y enseñarla. Puede ser analítico o sintético. Si estos conceptos se trasladan al campo de la Ingeniería del Software, entonces vemos que éstos han sido utilizados en diferentes formas, sin ningún criterio. Por ejemplo, el

CommonKADS-RT – Capítulo 1. Introducción y objetivos

3

concepto metodología es relacionado por algunos como la secuencia de actividades que se deben realizar para construir un sistema de software. Otros se refieren a la disciplina que estudia los métodos para hacer sistemas de software. En este último caso no hay diferencia con la definición de la Real Academia Española (RAE), sólo que para utilizarla adecuadamente se requiere especificar la connotación que se le va a dar. Por esto, a continuación se presentan algunas definiciones relevantes. Para [SGW94] la palabra metodología literalmente significa el “estudio de los métodos”. Sin embargo, se utiliza comúnmente como un enfoque para llevar a cabo una tarea. Por tanto, se puede hablar que, para cada una de las etapas del desarrollo del software se tiene(n) una o varias metodologías como por ejemplo: metodologías para el análisis, metodologías para el diseño, metodologías para las pruebas, metodologías para la administración del proyecto, entre otras. Además, estos autores dicen que la metodología es una colección que debe tener 3 elementos: • • •

Un lenguaje de modelado, unas heurísticas para modelar y un marco de trabajo para organizar y ejecutar el trabajo de desarrollo.

Es decir, que una metodología sin alguno de esos elementos, no es una metodología. [MSC+95], especifican el concepto de metodología desde el punto de vista del software, diciendo que “una metodología de software es una manera de trabajar que reúne el conjunto de información, datos o elementos en un repositorio”. Por tanto, es un instrumento que permite reducir o disminuir la complejidad en la solución de un problema cuando se está tratando de resolver por medio de un sistema computarizado. Para [Igl98] “una metodología puede definirse, en un sentido amplio, como un conjunto de métodos o técnicas que ayudan en el desarrollo de un producto de software. Sus principales actividades son: 1. 2. 3. 4.

La definición y descripción del problema que se desea resolver. El diseño y descripción de una solución que se ajuste a las necesidades del usuario. La construcción de la solución. La prueba de la solución implementada.”

[Dou99] no define exactamente lo que es una metodología, pero si especifica lo que ella debe comprender. Así, dice que una metodología consiste de varias partes: • • • •

Un marco semántico, un esquema notacional, una serie de actividades de trabajo secuenciales y, un conjunto de componentes de trabajo para entregar.

“Juntos, el marco de trabajo y el esquema notacional comprenden el Lenguaje de Modelado. El proceso de desarrollo describe las actividades que dirigen el uso de los

CommonKADS-RT – Capítulo 1. Introducción y objetivos

4

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

Una metodología es un conjunto de métodos, prácticas, estilos, recursos y conocimientos que permiten desarrollar de una manera efectiva y eficiente cada una de las actividades que son necesarias para analizar, diseñar, producir, implantar y mantener un artefacto

El concepto artefacto se refiere a cualquier documento o software que se produce durante todos los procesos que se realizan, desde que se estudia el problema hasta que la solución informática se implanta. Es así como en una metodología de software se debe indicar: •

Qué es lo que se debe hacer, cuáles son las actividades específicas que se deben realizar - Etapas.

•

Cuál es el orden de realización de dichas etapas, cuándo se tienen que hacer las actividades - Ciclo de Vida.

•

Cuáles son las herramientas, conocimientos y utilidades para realizar las etapas Métodos.

•

Quiénes son los responsables de proporcionar las especificaciones, de hacer el análisis del problema y de proponer la mejor solución. Quiénes son los responsables de hacer el sistema informático. Es decir, quién hace cada actividad y qué hacen en el ciclo de vida. - Los roles y responsabilidades al realizar una actividad.

•

Qué se va a obtener al realizar una etapa y al finalizar el proyecto, qué se necesita obtener para solucionar o cambiar la situación actual. – Los artefactos: resultados, documentos y el software.

CommonKADS-RT – Capítulo 1. Introducción y objetivos

•

5

Cuáles son las guías que se van a utilizar para la toma de decisiones en cada una de las etapas. - Los mecanismos de decisión.

En cuanto a la palabra método, aunque en esta memoria no presentamos ninguno en especial, hemos encontrado que hay más acuerdo en la semántica que se trabaja, a pesar de que algunos la tratan como sinónimo de metodología, sabiendo que en realidad ésta última contiene la primera. Por lo tanto, adoptamos la siguiente definición:

Un método es una serie de pasos a seguir para llevar a cabo una determinada etapa del ciclo de vida de desarrollo de software (por ejemplo: para elaborar el análisis)

Para los resultados finales de la investigación, se guardará este rigor, pero cuando se presente los métodos y las metodologías en el capítulo del Estado del Arte, en las secciones de sistemas basados en el conocimiento, sistemas de tiempo real y sistemas basados en el conocimiento de tiempo real, se mantendrán los nombres originales, tanto por respeto a sus creadores como porque es así como son reconocidos en el área tecnológica en que se utilizan. Por tanto, en esos apartados se podrán ver como si los dos términos fueran sinónimos.

Por último, es importante también definir el concepto modelo, ya que la metodología que se propone - CommonKADS-RT - y sus consideraciones metodológicas, están fundamentadas en la construcción de modelos que reflejan el conocimiento y la información de un sistema basado en el conocimiento de tiempo real.

Un modelo es una abstracción de un sistema físico, con un propósito que determina qué es lo que debe ser incluido en el modelo y qué es irrelevante. Es decir, que el modelo describe los aspectos importantes del sistema físico, para su propósito. [OMG99]

Hay varios aspectos importantes relacionados con este concepto: •

Un modelo sólo es una aproximación a la realidad y el nivel de detalle que debe tener es determinado por su propósito.

CommonKADS-RT – Capítulo 1. Introducción y objetivos

6

•

Para un mismo sistema físico, es posible definir diversos modelos, de acuerdo con el punto de vista y el nivel de abstracción que se quiera resaltar. Es decir, el proceso de modelado es dependiente de las interpretaciones subjetivas del modelador y por eso se requiere que haya una confrontación con la realidad.

•

El proceso de modelado es un proceso cíclico, así que nuevas observaciones pueden dirigir el refinamiento, la modificación o complementación de un modelo ya construido. [SFD99].

1.2

Justificación de la tesis

Dado el interés existente en los sistemas basados en el conocimiento de tiempo real se ha pretendido hacer un estudio sobre lo que realmente implican, tanto desde el sentido de su aplicación, como de su alcance y de las diversas formas en que se han desarrollado. Esta investigación está enmarcada en el proyecto “ARTIS: Herramienta para el desarrollo de sistemas inteligentes en tiempo real estricto", parcialmente subvencionado por el proyecto nº TAP98-0333-C03-01 de la Comisión Interministerial de Ciencia y Tecnología (CICYT) de España y que tiene como objetivo principal la construcción de un software para especificar y desarrollar sistemas inteligentes de tiempo real estricto. La principal motivación para realizar esta tesis doctoral, es contribuir a la investigación de cuáles son las guías, los métodos y los procesos para desarrollar sistemas basados en el conocimiento con restricciones temporales. En el tema específico de metodologías para sistemas basados en el conocimiento de tiempo real hay muy poca información en la comunidad científica, por lo que se considera muy importante que los resultados que se obtengan en esta tesis doctoral contribuyan positivamente en este campo, lo que redundará en el fortalecimiento del conocimiento que se tiene al respecto y en la ampliación de la aplicación de este tipo de sistemas en organizaciones diferentes a las de investigación, haciendo que cada vez más se difunda este tipo de tecnología. Es importante resaltar que la importancia de utilizar una metodología radica en el hecho que si ésta se aplica cuidadosamente, hay una probabilidad muy alta de éxito en la realización del sistema informático y en la puesta en marcha del mismo. Esta tesis doctoral pretende analizar los siguientes aspectos referidos a las metodologías para crear sistemas basados en el conocimiento de tiempo real: •

¿Hay metodologías con amplia cobertura que sean específicas para el desarrollo de sistemas basados en el conocimiento de tiempo real? ¿Son apropiadas para el desarrollo de este tipo de sistemas?

•

¿Es posible que una metodología creada para el desarrollo de sistemas basados en el conocimiento se pueda aplicar apropiadamente en la construcción de sistemas basados en el conocimiento de tiempo real?

CommonKADS-RT – Capítulo 1. Introducción y objetivos

7

•

¿Es posible que una metodología creada para el desarrollo de sistemas de tiempo real se pueda aplicar apropiadamente en la construcción de sistemas basados en el conocimiento de tiempo real?

•

¿Los conceptos de metodologías, métodos, herramientas que se manejan en la ingeniería del software son los mismos que se manejan en las áreas de los sistemas de tiempo real, los sistemas basados en el conocimiento y los sistemas basados en el conocimiento de tiempo real? ¿Cuáles son las diferencias?

•

¿Es importante que se tomen en cuenta los conceptos que se manejan en cada una de las diferentes áreas de conocimiento (ingeniería del software, sistemas basados en el conocimiento, sistemas de tiempo real, inteligencia artificial de tiempo real) para crear una metodología coherente?

•

¿Las metodologías existentes para desarrollar sistemas basados en el conocimiento de tiempo real son consecuentes con lo que debe ser una buena metodología para crear ese tipo de sistemas informáticos?

•

Al elegir una metodología existente ¿qué cambios hay que hacerle para que permita lograr un buen análisis y diseño de un sistema basado en el conocimiento de tiempo real?

•

¿Cuál es la semántica que se tiene al construir una aplicación que integra un sistema basado en el conocimiento con un sistema de tiempo real?

•

¿Qué debe tener en cuenta un desarrollador de aplicaciones de software para construir sistemas basados en el conocimiento de tiempo real?

1.3

Objetivos

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

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

CommonKADS-RT – Capítulo 1. Introducción y objetivos

8

Adicionalmente, se analizarán los métodos y metodologías exclusivas para desarrollar sistemas basados en el conocimiento y para sistemas de tiempo real, para decidir si es posible aplicarlas al desarrollo de los sistemas basados en el conocimiento de tiempo real y en qué forma se haría eso. Todo esto conlleva a cumplir con la meta final que se ha planteado en la investigación. Es decir, se trazarán unas directrices metodológicas que facilitarán el análisis y el diseño de un sistema basado en el conocimiento de tiempo real. Por último, para que lo propuesto tenga una validez y una aceptación, se analizarán y diseñarán dos aplicaciones diferentes, pero que serán representativas en el tipo de problema que se quiere tratar con la metodología propuesta. A continuación se formalizan los objetivos específicos: • Establecer un vocabulario básico que refleje la integración de los sistemas basados en el conocimiento y los sistemas de tiempo real. Consiste en definir los términos que se manejan en cada de uno de esas áreas informáticas para poder establecer si hay discrepancias para evitar que al hablar de sistemas basados en el conocimiento de tiempo real no se caiga en ambigüedades o contradicciones. No es la creación de una ontología del dominio, sino el planteamiento semántico que fundamente el sistema informático y el proceso de su construcción e implantación. • Definir los criterios que permiten determinar si una buena alternativa de solución de un problema es a través de la construcción de un sistema basado en el conocimiento de tiempo real. Se realizará una caracterización del tipo de problema que se asocia con el desarrollo de un sistema basado en el conocimiento de tiempo real como parte de la solución del mismo. Se describirán las especificaciones mínimas que debe tener un sistema de ese estilo para que sea considerado como una alternativa de solución o cambio de la situación específica. • Identificar y evaluar las metodologías para construir sistemas basados en el conocimiento de tiempo real. Consiste en buscar las metodologías que se han propuesto para el desarrollo de estos sistemas informáticos y determinar qué tan apropiadas son para ese propósito. En caso de encontrar que si lo son, entonces se propondrán nuevos enfoques o métodos para abordar el planteamiento completo de un proyecto de análisis y diseño de estos sistemas.

CommonKADS-RT – Capítulo 1. Introducción y objetivos

9

• Determinar si las metodologías reconocidas para el desarrollo de sistemas basados en el conocimiento pueden ser utilizadas, sin hacerle ningún cambio, en la creación de sistema basados en el conocimiento de tiempo real. Se examinarán las metodologías más reconocidas en el entorno de los sistemas basados en el conocimiento, para establecer si se pueden aplicar al desarrollo de sistemas informáticos que además del conocimiento contemplen restricciones temporales. Los criterios que se utilizarán son los que se plantean en la ingeniería del software para saber si una metodología es completa y además, los criterios que son propios de la ingeniería del conocimiento. • Determinar si las metodologías o métodos reconocidos para el desarrollo de sistemas de tiempo real pueden ser utilizados, sin hacerle ningún cambio, en la creación de sistema basados en el conocimiento de tiempo real. Este objetivo es similar al anterior, sólo que lo que se examinará en este caso son las metodologías y los métodos reconocidos en el entorno de los sistemas de tiempo real, para comprobar si se pueden utilizar en el desarrollo de sistemas basados en el conocimiento de tiempo real. En este caso, también se manejarán los criterios de la ingeniería del software más los específicos de las características de los sistemas de tiempo real. • Proponer un modelo de ciclo de vida de los sistemas basados en el conocimiento de tiempo real. Tal como se mencionó en la introducción de esta tesis, es importante identificar el orden y el alcance de cada una de las etapas que se deben seguir en el desarrollo de un sistema informático. Por lo tanto, para la metodología que se propone en esta investigación se plantearán dichas etapas junto con la especificación de la secuencia o concurrencia que se puede hacer con ellas. • Definir los modelos, prácticas, recursos, roles y artefactos que se deben considerar al realizar el análisis y diseño de un sistema basados en el conocimiento de tiempo real. Consiste en el planteamiento completo de la metodología para desarrollar sistemas informáticos de este estilo. Cómo se puede observar en la Figura 1-2 Alcance y objetivo de esta tesis, es el planteamiento de aspectos metodológicos que integren las características de los sistemas basados en el conocimiento, de los sistemas de tiempo real y de la ingeniería del software, es la zona que aparece en color negro en dicha figura.

CommonKADS-RT – Capítulo 1. Introducción y objetivos

10

• Realizar la evaluación de la aplicación de la metodología propuesta en esta tesis. Se determinarán situaciones reales en las que se pueda aplicar la metodología CommonKADS-RT que se propone en esta tesis, y se construirán los diferentes modelos que la conforman para cada una de esos escenarios. Esto con el fin de identificar si el seguimiento de la misma ofrece beneficios para el proceso de desarrollo de un sistema basado en el conocimiento de tiempo real. • Evaluar la metodología propuesta en esta tesis según la Ingeniería del Software. De acuerdo con los criterios definidos en la Ingeniería del Software para determinar si una metodología es completa y apropiada, entonces se analizará CommonKADS-RT. El resultado de esta evaluación será muy importante porque podrá servir para identificar las ventajas y desventajas de la metodología, y también, el planteamiento de futuros trabajos para mejorar lo realizado.

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

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:

CommonKADS-RT – Capítulo 1. Introducción y objetivos

11

−

En la primera sección del capítulo se explicarán los sistemas basados en el conocimiento, su definición, arquitectura, aplicación y algunos métodos y metodologías aplicados para su construcción, resaltando la metodología CommonKADS.

−

En la segunda sección se mostrarán los mismos tópicos del anterior, pero relacionados con los sistemas de tiempo real. La metodología que se resaltará en esta sección será RT-UML.

−

En la tercera, se presentarán los sistemas basados en el conocimiento de tiempo real, básicamente con el mismo contenido de los anteriores. Es importante anotar, que en cada uno de los métodos y metodologías presentados, se hará una breve valoración de su aplicación a los sistemas basados en el conocimiento de tiempo real, tal como se manifiesta en uno de los objetivos de la tesis. Adicionalmente, para terminar este capítulo, se presentarán las conclusiones más importantes relacionadas con cada uno de los temas tratados.

•

•

En el capítulo 3 se definirán todas las consideraciones metodológicas para el desarrollo de un sistema basado en el conocimiento de tiempo real, obteniendo como resultado la metodología CommonKADS-RT. −

Inicialmente se justificará la relevancia de CommonKADS-RT. Luego se presentarán las bases o fundamentos de dicha propuesta, resaltando sus bondades y debilidades. Se hará una caracterización del dominio para el cual es apropiado aplicar la metodología, con el fin de identificar claramente las situaciones o problemas a los que más se ajustará aplicar la solución informática con ayuda de las guías metodológicas. Se propondrá un modelo de ciclo de vida de una aplicación informática fundamentada en un sistema basado en el conocimiento de tiempo real. Se describirán cada uno de los modelos que conforman CommonKADS-RT y por último, se presentarán las conclusiones más importantes que se obtienen en esta investigación.

−

Cada uno de los modelos que se presentará, contendrá los formularios apropiados para su aplicación, los roles que deben participar en la elaboración de dicho modelo y los artefactos que se deben producir durante la creación del modelo. Todo esto ajustado al concepto metodológico que se adoptó en esta tesis y que fue presentado en la introducción de este capítulo 1.

En el capítulo 4, se realizará la evaluación experimental de los aspectos metodológicos de CommonKADS-RT por medio de dos escenarios, con el objetivo de ver su aplicabilidad. −

Inicialmente se presentarán, tanto las características comunes como las diferentes de los escenarios y la razón de su elección. Después, se mostrará el primer

CommonKADS-RT – Capítulo 1. Introducción y objetivos

12

escenario dado por una situación que se presenta en una terminal de contenedores, en concreto en la terminal de Marítima Valenciana S.A. en el Muelle Príncipe Felipe del Puerto de Valencia y que demostrará la aplicación apropiada de cada uno de los modelos que se proponen en la metodología, a través de una situación real y actual. −

El segundo escenario será sobre un micro mundo en el que se utilizará un robot para hacer una tarea específica. Este escenario es muy importante porque a través de él se aplicará la metodología para una situación que estará aislada de una organización, es decir, que no estará enmarcada en un contexto organizacional en particular.

−

Para terminar, se harán los comentarios más relevantes de la utilización de la metodología y se presentarán las conclusiones de este aspecto.

•

En el capítulo 5, se presentarán todas las conclusiones que se han obtenido al terminar esta investigación y los trabajos que se podrán iniciar partiendo de los resultados de la misma.

•

Posteriormente, se mostrará una lista de las abreviaturas que se usarán en esta memoria. Luego, se señalarán las referencias bibliográficas empleadas durante la investigación, separadas por tema: referencias del capítulo Introducción y objetivos, referencias de la sección de sistemas basados en el conocimiento, de la parte de sistemas de tiempo real, de la sección de sistemas basados en el conocimiento de tiempo real, de CommonKADS-TR y de las aplicaciones. Por último, se incluirá el anexo 1 de los criterios que sirven de guía para determinar si es apropiado, justificado y conveniente realizar el sistema basado en el conocimiento de tiempo real.

CommonKADS-RT – Capítulo 2. Estado del Arte

13

Capítulo 2. Estado del arte 2.1

Introducción

Como fundamento de investigación para esta tesis doctoral, se debe partir de una serie de tecnología claves para el planteamiento de las consideraciones metodológicas que permitan desarrollar sistemas basados en el conocimiento de tiempo real. Las tecnologías claves de las cuales se tratará su estado del arte son: •

Los sistemas basados en el conocimiento que cubrirán aspectos generales, tipos de sistemas, arquitecturas y metodologías.

•

Los sistemas de tiempo real, desde sus características hasta los métodos que se utilizan para realizar su análisis y el diseño.

•

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

2.2

Los sistemas basados en el conocimiento

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

CommonKADS-RT – Capítulo 2. Estado del Arte

2.2.1

14

Generalidades de los sistemas basados en el conocimiento

La Inteligencia Artificial (IA) es un área de la informática que trata de modelar, a través del ordenador, las capacidades inteligentes del ser humano, incluyendo su habilidad para solucionar problemas complejos mientras operan y se adaptan a dominios dinámicos, inciertos y que no están completamente especificados. Para llevar a cabo el objetivo global de la IA, ésta se ha dividido en una serie de áreas de investigación, cada una con unos propósitos específicos que permiten aportar conocimientos y métodos particulares que ayudan al cumplimento de la meta general. Entre éstas están las redes neuronales artificiales, el procesamiento del lenguaje natural, la visión artificial, el reconocimiento de formas, la robótica inteligente y los sistemas basados en el conocimiento. Como este último es uno de los temas básicos de esta investigación, se tratará más a fondo. Los Sistemas Basados en el Conocimiento (SBC) tratan con problemas complejos en un dominio y requieren de un elevado conocimiento del mismo. Muchos investigadores manifiestan que estos sistemas intentan imitar la actuación de un experto humano ante un problema relacionado con su dominio. Para ello tienen unos mecanismos que reflejan el conocimiento y el razonamiento que el experto maneja para la toma de decisiones ante cierta situación [Hen97]. Dentro de estos se encuentran los sistemas expertos, llamados así por la calidad y cantidad del conocimiento que manejan en relación con el experto humano. Un SBC tiene un gran número de características atractivas [Gia89]: •

Maneja el conocimiento de un dominio, es decir, maneja los hechos, las heurísticas y las relaciones que posibilitan el encontrar buenas soluciones a problemas de él.

•

Permite acceder fácilmente al conocimiento de ese dominio, ya que el conocimiento reflejado en el sistema puede estar disponible en cualquier ordenador. Por lo tanto, en un sentido real, un SBC es la producción en masa de la pericia.

•

Simula el proceso de solución de problemas utilizado por un experto humano.

•

Puede servir para evitar peligros a los usuarios, ya que puede ser usado en ambientes pesados que pueden presentar riesgos al ser humano.

•

Es permanente es decir, el conocimiento que posee es persistente, continuará indefinidamente. Esto es contrario a los expertos que en cualquier momento se pueden retirar. Además, sirve como repositorio de conocimientos con el objetivo de mantener y hacer que el conocimiento perdure dentro de la organización, logrando inclusive que sirva como herramienta de registro tecnológico.

•

Puede englobar o captar el conocimiento de un número de personas.

•

Facilita el acceso a la pericia de múltiples expertos: El conocimiento de varios expertos puede estar disponible para trabajar simultánea y continuamente un problema. El nivel de experiencia combinada de varios expertos puede exceder el de un solo experto humano.

CommonKADS-RT – Capítulo 2. Estado del Arte

15

•

Da explicación de su conocimiento y razonamiento: El SBC puede explicar explícitamente en detalle el razonamiento que permitió obtener una conclusión. Un humano puede estar muy cansado, o no querer hacer esas dos cosas a la vez. Esto incrementa la confianza de la decisión tomada.

•

Respuesta rápida: Dependiendo del software y del hardware usados, un SBC puede responder rápidamente y tener mayor disponibilidad que la que tiene un experto humano. Algunas situaciones de emergencia pueden requerir respuesta más rápida que la de un humano y así el SBC responderá a tiempo.

•

Ofrece respuestas en una forma uniforme, no emotiva, y completa en cualquier situación. Esto puede ser muy importante en casos de tiempo real y emergencia cuando un experto humano puede no operar en una máxima eficiencia debido al estrés o a la fatiga.

•

Puede servir como un tutor inteligente. El SBC puede actuar como un guía inteligente dejando que el estudiante ejecute programas ejemplo y acceda a la explicación del razonamiento del sistema.

•

La forma de razonamiento (Motor de Inferencia) y el conocimiento (Base de Conocimientos) son independientes, lo que implica que los cambios que se realicen en uno de ellos puede que no requieran cambios en el otro.

•

Base de datos inteligente. Un SBC puede ser usado para acceder a una base de datos de una manera inteligente.

2.2.2

Clasificación de los sistemas basados en el conocimiento

Un SBC se clasifica de diversas formas: por su funcionalidad o propósito, por su estado de evolución, por el papel que realiza en el entorno, y por la labor de ayuda que le ofrece al experto con el conocimiento del dominio que él tiene. • Según la funcionalidad del sistema Esta clasificación es de acuerdo con la función que él realiza o el propósito para el cual fue desarrollado. A continuación se explica cada uno de ellos brevemente y se mencionan algunos de las áreas en las que estos sistemas son representativos [She90] y [HKL+89]: −

Descubrimiento: Sistemas que generan nuevos conceptos a partir de reglas y principios consistentes y permiten encontrar nuevas relaciones entre los datos. o o o

PROSPECTOR: Para el descubrimiento de yacimientos de molibdeno. AM: Para la formulación de conceptos y conjeturas sobre la teoría de números. META-DENDRAL: Para el descubrimiento de reglas sobre la conducta de algunos compuestos en el espectrómetro de masas.

CommonKADS-RT – Capítulo 2. Estado del Arte

−

Diagnóstico: Para detectar las causas del mal funcionamiento de un sistema. o o o

−

XCON: Configura sistemas computarizados. SECS: Genera complejos compuestos químicos. 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 o o

−

MYCIN: Diagnostica las causas de enfermedades infecciosas en un paciente. ACE: Localiza las causas de fallas en redes telefónicas. 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 o o

−

16

PROSPECTOR: Interpreta datos de muestras de material mineral para detectar yacimientos. REACTOR: Interpreta los datos en tiempo real, de reactores nucleares. 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 o o

YES/MVS: Controla y hace la monitorización de las funciones de un sistema operativo. VM: Hace la monitorización del estado de un paciente en una sala de cuidado intensivo. 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 o o

PLANT: Estima los daños potenciales de plagas sobre plantíos. I&W: Predice los posibles lugares de conflictos armados. PTRANS: Estima los requerimientos de manufactura de algún producto.

CommonKADS-RT – Capítulo 2. Estado del Arte

17

• Según el estado de evolución del sistema Esta clasificación es de acuerdo con el grado de evolución que el sistema ha tenido. Es decir, que dependiendo de su propósito, cubrimiento y del conocimiento que maneja se tienen diversos estados del sistema [Wat86]: −

Prototipo de demostración: El sistema soluciona una porción del problema, sugiriendo que el enfoque es viable y el desarrollo del sistema es alcanzable. Es pequeño y se utiliza como estrategia de convencimiento de la utilidad del SBC.

−

Prototipo de investigación: El sistema presenta un desempeño aceptable del problema pero puede ser frágil debido a que no se ha probado y revisado completamente. Es de tamaño mediano.

−

Prototipo de campo: El sistema muestra un buen desempeño y ha sido revisado en el entorno del usuario. Es de tamaño que varía de mediano a grande.

−

Modelo de producción: El sistema exhibe muy buena calidad, desempeño, rapidez y una ejecución eficiente en el entorno del usuario. Son grandes programas implementados en lenguajes eficientes.

−

Sistema comercial: El sistema es un modelo de producción que está siendo usado regularmente en una base comercial.

• Según el papel que el sistema desempeñe en el entorno Esta clasificación se refiere a la forma como el SBC interactúa con el usuario en términos de compartir tareas y responsabilidades [GuT94]: −

Sistema soporte: Es un SBC que puede darle soporte experto al usuario. Este sistema puede actuar en diferentes roles, como asistente, colega crítico, segunda opinión, asesor, consultor tutor, etc. Ofrece conocimientos y competencias pero no prescribe soluciones o decisiones. Actúa como un ayudante, sin la intención de reemplazar al experto.

−

Sistema prescriptivo: Es un SBC que puede guiar, restringir y controlar la actividad de un usuario en la ejecución de una tarea compleja. Mejora la calidad y el tiempo de respuesta sin reemplazar a los expertos. Este sistema tiene la autoridad para mejorar los objetivos, restricciones, soluciones o decisiones.

−

Sistema autónomo: No interactúa con ningún humano ya que se utiliza para reemplazarlos en un trabajo específico.

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

CommonKADS-RT – Capítulo 2. Estado del Arte

18

forma similar al experto humano, llegando incluso a tener el conocimiento de varios expertos.

2.2.3

Arquitectura de un sistema basado en el conocimiento

La arquitectura se refiere a los componentes o módulos que constituyen parte del sistema, independiente del dominio. Específicamente cuando se habla del SBC se definen tres tipos de arquitecturas en general: •

Arquitecturas de primera generación, en donde el control y el conocimiento están centralizados. Esta arquitectura tiene como componentes principales el motor de inferencia y la base de conocimiento, que se presentan más adelante. Estas arquitecturas propiciaron o fueron el origen del término Sistema Basado en el Conocimiento.

•

Arquitecturas de segunda generación, guiada principalmente por la filosofía de sistemas distribuidos. Se habla de agentes inteligentes, en donde cada uno de ellos presenta un comportamiento inteligente. Surge el término Sistema de Conocimiento y Sistemas de Agentes Inteligentes.

•

Arquitecturas de última generación, en donde la idea básica es la reutilización de muchos de los componentes del sistema [SDF+00]. Una arquitectura de este tipo es la que proponen [FBM+99] en la que se dice que un SBC está formado por cinco elementos básicos: −

Una tarea que define el problema que debería ser solucionado por el SBC.

−

Un método de solución de problemas que define su proceso de razonamiento.

−

Un modelo del dominio que describe el conocimiento de su dominio.

−

Una ontología que provee la terminología usada en las tareas, los métodos de solución de problemas y el dominio.

−

Adaptadores para establecer la relación apropiada entre la tarea, el método de solución de problema y el dominio. Se define un adaptador para la relación de entre dos componente de la arquitectura.

Los componentes que en general forman parte de todo sistema basado en el comportamiento son la base de conocimientos y el motor de inferencia. A continuación se detallan.

CommonKADS-RT – Capítulo 2. Estado del Arte

2.2.3.1

19

Base de conocimientos

Es la estructura que permite guardar el saber relacionado con un dominio y que se construye a partir de las fuentes de conocimientos. Desde el punto de vista de la Inteligencia Artificial el conocimiento se ha clasificado en: hechos, heurísticas y relaciones (reglas). Un hecho es un dato dado, probado y que tiene un valor de verdad asociado; una heurística es generada a través de la experiencia de la persona; una relación se establece a partir de los hechos o las heurísticas del dominio. Una fuente de conocimiento es donde está guardado el conocimiento y se clasifica de la siguiente forma: −

Fuente de conocimiento estática - fuente secundaria: Es rígida porque su contenido no se puede variar. Por ejemplo, un libro, una revista, un artículo o una película.

−

Fuente de conocimiento dinámica - fuente primaria: Refleja las características del conocimiento tales como, la variabilidad, el hecho de ser cambiante e inexacto, entre otras. El hombre forma parte de este tipo de fuente y en particular, el experto.

Es importante anotar que algunos autores manejan el concepto único de base de conocimientos y otros lo dividen en: base de datos y base de relaciones. A continuación se explica cada uno de ellos. • Base de datos Contiene los hechos, los datos y las heurísticas puntuales del dominio. Estos generalmente son obtenidos de las fuentes estáticas del conocimiento, con la revisión del experto en el dominio. Típicamente se clasifican en datos de entrada, es decir, datos requeridos por el sistema y que el usuario le proporciona, y datos inferidos que se obtienen a partir de la relación de otros. Un ejemplo de un dato de entrada es: Tipo de Contenedor; un ejemplo de un dato inferido es: Zona de descarga en el puerto, pues a partir del contenedor se puede saber en dónde debe ubicarse en el puerto. • Base de relaciones Contiene las relaciones que se establecen entre los hechos o las heurísticas del dominio. Normalmente se establecen por medio de reglas del tipo Si una condición, Entonces una acción o conclusión. Estas relaciones se ejecutan de acuerdo con el razonamiento que siga el motor de inferencia. Ejemplo de una relación:

CommonKADS-RT – Capítulo 2. Estado del Arte

20

SI el tipo de contenedor es un frigorífico ENTONCES La zona en donde se debe descargar es en importaciones.

2.2.3.2

Motor de inferencia

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

Para la búsqueda del conocimiento en la base de conocimientos se definen algoritmos que, de acuerdo con la estructura del conocimiento, permiten hacer la exploración en la forma más apropiada.

•

Para realizar el control del conocimiento. Se utilizan métodos para determinar qué conocimiento aplicar en un momento dado. Entre ellos hay tres que se destacan como fundamentales para la resolución: −

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

−

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

−

También es posible tener un razonamiento híbrido que es una combinación de los dos enfoques anteriores. La decisión de cuál aplicar depende de la forma como el experto razone.

En términos de las arquitecturas de última generación, el motor de inferencia se especifica como el componente que contiene los métodos de solución de problema. En

CommonKADS-RT – Capítulo 2. Estado del Arte

21

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

2.2.3.3

Módulo explicativo

Éste se encarga de dar las explicaciones relacionadas con el razonamiento que el sistema ha seguido para llegar a obtener una conclusión o una recomendación, para aclarar el por qué o para qué de una pregunta que el sistema le formula al usuario.

2.2.3.4

Módulo de adquisición del conocimiento

A través de este componente el ingeniero del conocimiento o el experto del dominio puede construir inicialmente el sistema o actualizar el conocimiento de la base de conocimientos en general. Permite entrar los hechos y las reglas al sistema y probar y depurar los cambios realizados. “Usualmente el usuario final no debería tener la capacidad para cambiar el sistema, ya que puede no tener el suficiente conocimiento” [Edm88]. Adicionalmente, por medio de éste se pueden realizar actividades relacionadas con la configuración del sistema, específicamente del motor de inferencia, de acuerdo con las necesidades del usuario [Guz96]. En el medio se encuentran herramientas que permiten hacer esta adquisición de forma automática, tal como TOPKAT (The Open Practical Knowledge Acquisition Toolkit) que integra técnicas de extracción del conocimiento con el enfoque de modelado de CommonKADS [Kin94].

2.2.3.5

Interfaz Usuario - Sistema

La interfaz de un usuario con el ordenador es el medio a través del cual se comunican entre sí. Es el medio mediante el cual el usuario accede a los servicios del SBC. El tipo de interfaz tiene una fuerte influencia en cómo un usuario ve y entiende la funcionalidad del sistema [Pri93], ya que el dialogo que se establece le permite relacionar los detalles de las tareas con el objetivo del sistema informático.

CommonKADS-RT – Capítulo 2. Estado del Arte

22

Lo importante en el diseño y construcción de la interfaz es que ésta deber estar de acuerdo con las necesidades del usuario, el conocimiento que él tiene sobre el dominio y las características del problema y de su solución.

2.2.4

Procesos en el desarrollo de sistemas basados en el conocimiento

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

Experto: Es la persona o grupo de personas que tiene(n) el conocimiento teórico y práctico del área problema es decir, el (los) perito(s). Este experto debe ser reconocido en su área de especialización, lo que implica que sus colegas lo consideran una persona valiosa por sus conocimientos sobre el dominio.

•

Ingeniero del Conocimiento (IC): Es (son) la(s) persona(s) encargada(s) de construir el sistema. Debe(n) tener los conocimientos profundos sobre cómo desarrollar sistemas basados en el conocimiento, conocer las herramientas de su desarrollo, conocer algunas de las estrategias efectivas de comunicación y tener unos mínimos conocimiento de sicología para poder interpretar las expresiones y manifestaciones del experto [Har92].

•

Usuario: Es (son) la(s) persona(s) que va(n) a utilizar el sistema, que se va(n) a ver beneficiado(s) directamente por la implantación del proyecto. Su conocimiento debe ser considerado al desarrollar el SBC.

En términos generales los procesos que se realizan con el conocimiento son: la adquisición, representación y manipulación / validación. A continuación se presenta cada uno de ellos.

2.2.4.1

Adquisición del conocimiento

Este proceso se refiere a la labor de extracción del conocimiento de las fuentes estáticas y dinámicas. No debe confundirse con el módulo de adquisición del conocimiento mencionado en la sección 2.2.3.4. El objetivo final de este proceso es construir los modelos del conocimiento del SBC [SFD+99], por ello se realiza durante todo el desarrollo del sistema, desde el mismo momento en que se comienza a estudiar el problema y su solución hasta cuando se lleva a cabo su evolución. Por lo tanto se efectúa durante todas las etapas del desarrollo, en unas

CommonKADS-RT – Capítulo 2. Estado del Arte

23

con mayor intensidad que en otras. Se puede decir que es un proceso que no termina [SCG91]. Dependiendo del tipo de fuente de conocimiento que se va a utilizar se sigue alguno de los siguientes procedimientos: •

Adquisición del conocimiento de una fuente estática. En la sección 2.2.3.1. se definió lo que era una fuente estática y se presentaron ejemplos de ella. Lo primero que se debe hacer es seleccionar las fuentes más apropiadas que están relacionadas con el problema para adquirir los conocimientos básicos del dominio, evaluando todos los recursos que se tengan disponibles bien sea al interior de la empresa o fuera de ella. Comúnmente, el experto es quien aconseja qué fuentes estudiar. Luego, se hace un estudio minucioso de ellas para que así el (los) ingeniero(s) del conocimiento pueda(n) adquirir ese conocimiento básico y fundamental del dominio del experto y consiga(n) realizar un proceso de adquisición eficiente y eficaz. Por último, se debe hacer una comprobación del conocimiento que se extrajo para saber si éste es correcto o no.

•

Adquisición del conocimiento de una fuente dinámica. Esta labor se realiza una vez se haya adquirido el conocimiento básico del dominio por parte del (los) ingeniero(s) del conocimiento. Hay diferentes estrategias para ello, a continuación se presentan las más usuales. −

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

−

Entrevista informal: Se realiza de forma personal pero no planeada. Es aprovechar la oportunidad del encuentro entre el IC y la persona que tiene el conocimiento, en donde el primero le hace una pequeña entrevista al segundo. Obviamente, por ser una entrevista esporádica o imprevista, no se tienen disponibles los medios que permiten registrar el conocimiento, por lo tanto, se debe tener mucho cuidado para evitar su inadecuado manejo.

−

Observación del trabajo real del experto: Se denomina método de la observación [Bac95]. Consiste en examinar la labor del experto en su ambiente de trabajo, solucionando un problema como el que se está tratando de simular.

CommonKADS-RT – Capítulo 2. Estado del Arte

24

La ventaja del conocimiento que se adquiere en esta forma es que es muy espontáneo, ya que el experto está tomando las decisiones sin tener mucho tiempo para analizar el por qué de ellas. Además, no se le permite cuestionar si está haciendo lo correcto o no, solamente él hace lo que cree que es mejor en esa situación. −

Cuestionario: Es una encuesta muy bien diseñada que se utiliza especialmente para cuando se requiere obtener las ideas que tienen varias personas sobre el tema. Puede llegar a ser muy difícil de diseñar e inclusive, de manejar.

En el campo de la adquisición del conocimiento se han llevado a cabo numerosas investigaciones que han dado muy buenos resultados, especialmente en lo referente a la construcción de herramientas software que permiten automatizar el proceso, y también en su formalización. Para más información ver [AVS+93] y [FAL98].

2.2.4.2

Representación del conocimiento

Este proceso consiste en coger el conocimiento extraído y representarlo en una forma inteligible, primero por el ingeniero del conocimiento y luego por la herramienta de software que se vaya a utilizar. Cuando el IC hace la adquisición del conocimiento lo va registrando de alguna forma, es así como comienza a realizar su representación. Después, de acuerdo con la forma elegida, lo lleva al lenguaje del ordenador para que así quede reflejado en el software. Por lo tanto, el IC debe conocer muy bien la herramienta de desarrollo. Quizá lo más complejo de este proceso no es el conocer la herramienta, sino la elección de la forma más apropiada, según el problema y el experto, de la representación interna del conocimiento en el ordenador. Para los SBC se han determinado algunas representaciones que se han convertido en estándar para ello, entre éstas están: la lógica preposicional y la lógica de predicados, las reglas de producción, las redes semánticas, los marcos (frames), los guiones (scripts), los lenguajes orientados por objetos y las redes neuronales [Ben90]. Este proceso por lo tanto, consiste en la construcción de la base de conocimientos del sistema.

2.2.4.3

Manipulación y pruebas

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

CommonKADS-RT – Capítulo 2. Estado del Arte

25

Básicamente lo que se realiza es evaluar el conocimiento del SBC haciendo pruebas de casos reales, con el fin de confrontarlos entre sí.

2.2.5

Metodologías para el desarrollo de sistemas basados en el conocimiento

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

2.2.5.1

Metodologías fundamentadas en la ingeniería del software

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

CommonKADS-RT – Capítulo 2. Estado del Arte

26

permitan hacer su abstracción y descripción en relación con el problema. Además, desde el punto de vista administrativo es muy difícil realizar el control y el seguimiento de un proyecto de este tipo.

2.2.5.2

Metodologías específicas de la ingeniería del conocimiento

La Ingeniería del Conocimiento (IC) es el área de la Inteligencia Artificial que se relaciona con la construcción de Sistemas Basados en el Conocimiento, incluyendo los procesos de adquisición y representación del conocimiento, y creación del sistema. “Provee los métodos y las herramientas para construir SBC en una forma sistemática y controlable” [SDF+00]. Puede verse también como una rama de la Ingeniería del Software que trata de modelar el conocimiento de un dominio para construir a través de unos métodos y herramientas un sistema – software de calidad. Esto último surge de la necesidad que se tenía de crear sistemas basados en el conocimiento que estuvieran siempre respaldados por un proceso formal de gestión y desarrollo, lo cual no era completamente proporcionado por la Ingeniería del Software debido a los diferentes aspectos que se incluyen en un proceso de conocimiento [AFS90]. Como resultado de la investigación en aspectos metodológicos de SBC han surgido algunas propuestas y productos muy apropiados para soportar el proceso de construcción del sistema. Se resaltan los siguientes: VITAL [Dom97], KSM [MoC95], MIKE [AFL+93], PROTÉGÉ-II [EPG+94], KADS [BrW89] y CommonKADS [BFP+97]. Todas se presentan en forma general, excepto CommonKADS que es la base de la propuesta de esta investigación, entonces es la que más se detalla. • METODOLOGÍA VITAL Esta metodología [Dom97], es el resultado de un proyecto ESPRIT de investigación y desarrollo en el que estaban involucradas diversas organizaciones europeas, en especial de Inglaterra y Finlandia, que se fundamentó en los resultados de otros proyectos como KADS (nombre anterior de CommonKADS). Vital pretende crear una metodología y un software de soporte para desarrollar grandes sistemas empotrados basados en el conocimiento. En ella, un proyecto de desarrollo de un SBC está formado por cuatro etapas, llamadas procesos productos [MOS+95]: −

Especificación de requerimientos: Descripción de la funcionalidad esperada de la aplicación y las limitaciones o restricciones eventuales que deben seguirse.

−

Modelo conceptual: Este proceso producto provee un modelo del experto que captura las entidades relevantes del dominio, la estructura de la tarea y el comportamiento que tiene el experto en la solución de problemas.

CommonKADS-RT – Capítulo 2. Estado del Arte

27

−

Modelos del diseño: Comprende el modelo del Diseño Funcional y el modelo del Diseño Técnico. El primero provee una descripción independiente de la implementación del SBC objetivo y el segundo es una relación entre el modelo del diseño funcional y el código ejecutable. Obviamente estos modelos dependen de la situación específica de la implementación.

−

Código ejecutable: Comprende todos los componentes del software embebidos en la aplicación.

Su idea principal es la noción de tener un producto mediante un proceso (muchas tareas) a través de un enfoque estructurado que cumpla lo siguiente: −

El desarrollo de una aplicación debe ser guiado por la construcción de un proceso muy bien definido y bien documentado.

−

El papel de cada proceso - producto - y sus enlaces con otros se debe hacer en forma explícita.

−

Hay una serie consistente y sistemática de técnicas y métodos que soportan la construcción de cada proceso – producto -.

La ventaja de esta metodología es que da como resultado diferentes productos que se integran para formar el todo y que se pueden actualizar para mantener fácilmente el SBC. También hace la distinción entre la especificación y la implementación del sistema, lo que facilita la verificación y prueba de la aplicación. También, proporciona una herramienta de software llamada Alchemist que se compone de una serie de módulos que asisten al usuario en el desarrollo del sistema y proporciona lenguajes formales e informales para representar los modelos del nivel de conocimiento (VITAL KML – Knowledge Modelling Language y KbsSF [DMW93]). Una desventaja que presenta es que es una metodología que está orientada a la adquisición del conocimiento de un SBC creando un modelo del nivel del conocimiento del problema y del diseño de su código. A pesar de tratar la especificación, no es una metodología que esté orientada a la fase de análisis. Además, para ser orientado a sistemas empotrados no menciona cómo es la comunicación con el entorno en donde el sistema está inmerso. • METODOLOGÍA KSM KSM (Knowledge Structure Manager). Es uno de los resultados del grupo de investigación ISYS (Intelligent Systems) en el Departamento de Inteligencia Artificial de la Universidad Politécnica de Madrid, España [MoC95], [CuM96]. Incluye y extiende algunas de las ideas comunes de otros enfoques similares de metodologías y herramientas de ingeniería del conocimiento como CommonKADS y Krest [Ste90]. Es otra metodología interesante vista como un ambiente que permite el desarrollo de SBC orientado al conocimiento pues se enfoca en la identificación de los modelos de

CommonKADS-RT – Capítulo 2. Estado del Arte

28

entendimiento computables del problema que va a ser solucionado. Cubre los pasos del análisis, el diseño, la implantación y el mantenimiento de una aplicación inteligente. En ella se parte del concepto de unidad del conocimiento que permite elaborar su modelado desde el mismo momento del análisis e incluso para hacer una reutilización de él porque son modelos abstractos que facilitan que en el diseño se pase del modelo de conocimientos a un código ejecutable. El modelo de conocimientos se comienza a definir partiendo de la perspectiva del área de conocimientos que permite identificar el cuerpo de conocimientos que se usa en un dominio específico, para solucionar problemas determinados. Luego, se aplica la perspectiva de la tarea (define una meta u objetivo a cumplir con sus entradas y salidas, y el método que especifica el cómo llegar a esa meta). Este concepto de tarea es el mismo que se tiene en CommonKADS. Específicamente en KSM se utiliza el lenguaje Link para construir estos métodos. Por último, se tiene la perspectiva del vocabulario que incluye el léxico conceptual que define los términos básicos para las áreas de conocimiento, a través del lenguaje Concel. También, dentro de KSM se ofrece una forma para volver todo este conocimiento en algo ejecutable por medio de unas interfaces y unas librerías. Adicionalmente, se ha desarrollado un ambiente de software que soporta dicha metodología y que ayuda a los IC en la construcción de versiones operacionales del sistema final. Dicho ambiente está organizado por medio de tres componentes: un ambiente orientado por objetos, un manejador del nivel de conocimiento y una interfaz con el usuario. Su gran fortaleza está en que permite crear una versión ejecutable del modelo del conocimiento. Con esta metodología se han construido grandes sistemas, entre los cuales están: Fluids, Trys, Bios, Artemis, Covalto y TCM. La gran ventaja que tiene KSM es que construye modelos genéricos que pueden ser reutilizados fácilmente. Pero el problema que presenta es que no proporciona los criterios para hacer un análisis acerca de la situación inicial sino que parte de la solución misma. Es decir, de la forma para adquirir y representar el conocimiento sin saber si realmente es la mejor alternativa para solucionar el problema. Además, no está enmarcada en todo el proceso de evaluación y planteamiento de proyectos, por lo que no aplica conceptos de gestión de proyectos. • METODOLOGÍA MIKE MIKE (Model-based and Incremental Knowledge Engineering) [AFL+93],[AFL+98] y [Neu93]. Esta metodología define un marco de trabajo para extraer, interpretar e implementar conocimiento para construir sistemas basados en el conocimiento, cubriendo todos los pasos desde la extracción hasta el diseño e implementación del sistema. Su objetivo fundamental es el desarrollo de un modelo detallado de procesos para soportar el proceso de ingeniería del conocimiento, siguiendo con el modelo de ciclo de vida de Boehm [Boe93]. Es decir, en una manera cíclica e incremental en donde nuevas observaciones pueden refinar, modificar o completar las representaciones ya existentes.

CommonKADS-RT – Capítulo 2. Estado del Arte

29

MIKE propone la integración del modelo de ciclo de vida, prototipos y técnicas de especificación semi-formal y formal en un marco de trabajo coherente. Para realizar el nivel informal y semi-formal de descripción se utilizan los principios hipermediales con nodos y enlaces de diferentes tipos, conteniendo el flujo de datos y el flujo de control u otras relaciones entre nodos que puede ser semi-formalmente representadas. Este nivel de representación se llama el hiper modelo y se utiliza para la comunicación entre el ingeniero del conocimiento y el experto y como una base para la documentación. Para la especificación formal se utiliza el Lenguaje KARL [AKS+93], [AFS93], [FAL91], [FAL+93] que permite dar una representación del conocimiento evitando que se presenten ambigüedades. El proceso de desarrollo en MIKE consiste de 4 fases que se realizan en forma cíclica de acuerdo con el modelo de espiral: adquisición del conocimiento, diseño, implementación y evaluación. Cada una de éstas tiene una serie de actividades que pueden ser también realizadas siguiendo el mismo modelo de espiral, haciendo un procesamiento incremental. La adquisición del conocimiento empieza con la actividad de extracción del conocimiento a través de entrevistas estructuradas con los expertos, luego sigue con la interpretación del conocimiento para obtener un modelo informal de los aspectos funcionales y no funcionales del dominio, y por último se pasa a la actividad de formalización y operacionalización para construir el modelo formal en KARL. La siguiente fase es la de diseño, en la cual, además de lo anterior se consideran los requerimientos no funcionales y se construyen los algoritmos y las estructuras de datos a través del lenguaje DesignKARL. Posteriormente, se pasa a la fase de implementación. En ésta se tiene el hardware y el software necesario para la construcción del sistema y se traducen los modelos definidos con anterioridad a estas plataformas. Por último, se tiene la fase de evaluación en la que se revisan los objetivos iniciales contra los productos finales [AFS93], [AFS96]. Gráficamente el ciclo de vida que se sigue en MIKE se aprecia en la Figura 2-1.

Ingeniería del Conocimiento Adquisición del Conocimiento Análisis de Construcción del la Tarea Modelo

Elicitación

Diseño

Implementación Mantenimiento

Evaluación Análisis de Construcción del del Modelo Requerimientos Modelo

Evaluación del Modelo

Interpretación Formalización / Operacionalización

Figura 2-1 Fases del ciclo de vida de MIKE

La importancia de MIKE radica en la transición tan simple que propone para pasar de las actividades de extracción del conocimiento hasta la fase de evaluación del

CommonKADS-RT – Capítulo 2. Estado del Arte

30

sistema final. Pero, hasta el momento sólo se centra en la construcción del modelo de conocimientos para describir los requerimientos funcionales del SBC, como se pudo observar en la Figura 2-1. Es así, como esta metodología se fundamenta más en la integración de prototipos y el desarrollo incremental que en la construcción de diferentes vistas del problema y del SBC. • METODOLOGÍA Protégé-II Protégé-II más que una metodología es un entorno de desarrollo y un conjunto de herramientas que soportan la construcción de sistemas inteligentes y es propuesto y creado en el Laboratorio de Sistemas de Conocimiento (KSL - Knowledge System Language) de la Universidad de Stanford, Estados Unidos. La construcción del SBC se hace seleccionando y modificando métodos de solución de problemas (PSM - Problem Solving Method) reutilizables y ontologías del dominio [EPG+94]. Protégé-II provee un generador de herramientas de adquisición del conocimiento que usa las ontologías del dominio como base, llamado Dash. Definen ontología como un modelo simple de algún dominio del conocimiento; más formalmente es una especificación del universo del discurso [GAM94]. Los expertos del dominio usan dicho instrumento para adquirir el conocimiento que se requiere en la solución de un problema determinado. En Protégé hay dos tipos fundamentales de componentes: −

Conocimiento declarativo del dominio que puede ser reutilizado a través de diferentes tareas de aplicación. La tarea es un modelo de la funcionalidad requerida.

−

Conocimiento procedural de solución del problema, tal como un método de solución del problema, que puede ser reutilizado a través de diferentes dominio.

Protégé proporciona herramientas para definir ontologías del dominio (descripción declarativa del dominio de la aplicación), del método (conceptos y relaciones relevantes de los métodos de solución del problema) y de la aplicación (conceptos y relaciones específicas de la aplicación). También, proporciona herramientas para la adquisición del conocimiento y su traducción. La construcción de un modelo de conocimientos se puede hacer en 3 pasos: 1) formulación de la ontología del método, 2) definición de la ontología de la aplicación y 3) definición de las relaciones entre 1) y 2). Una de las características importantes de Protégé-II es que ha considerado diferentes tipos de usuarios: los expertos del dominio que tienen poco o incluso, ningún conocimiento de programación, y los programadores. Esto ha permitido que tanto las herramientas proporcionadas como sus interfaces, sean las apropiadas para cada uno de ellos. Además, el grupo de investigación ha seguido creciendo y aplicando las herramientas en el desarrollo de SBC que permiten validar su propuesta a través de

CommonKADS-RT – Capítulo 2. Estado del Arte

31

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

2.2.6

Metodología CommonKADS

2.2.6.1

Perspectiva histórica

Es una metodología para la construcción de sistemas basados en el conocimiento, resultado de varios proyectos enmarcados dentro del programa ESPRIT, para la innovación y la aplicación de tecnología informática avanzada en la Unión Europea. Fue desarrollada en la Universidad de Ámsterdam en cooperación con varios socios europeos, como universidades, organizaciones de investigación, casas de software y de consultoría. Con ella se han desarrollado muchos sistemas de conocimiento [CaP96] y por eso actualmente es considerada por muchas compañías y organizaciones alrededor del mundo como un estándar para la ingeniería del conocimiento y de los SBC. Inicialmente, se planteó el desarrollo de un método para la adquisición del conocimiento en el proceso de construcción de un sistema basado en el conocimiento y se llamó KADS (Knowledge Acquisition Design System) [BAK92], [BrW89]. Posteriormente y dado los buenos resultados obtenidos, se amplió el proyecto a la construcción de una metodología completa para el desarrollo de sistemas basados en el conocimiento, la cual empieza desde el análisis mismo de la organización en donde se va a hacer el SBC hasta la gestión del proyecto, pasando por el diseño del software. Es en ese momento cuando se propone y acepta el nombre de CommonKADS. CommonKADS está fundamentada en los siguientes principios [SAA+98], [SAA+00]: •

La ingeniería del conocimiento hoy en día se enfoca en la realización de actividades de modelado, antes era vista sólo como un proceso de extracción de la pericia del experto para traducirla a una forma computacional.

CommonKADS-RT – Capítulo 2. Estado del Arte

32

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

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

•

El conocimiento tiene una estructura interna estable en la que aparecen muestras similares, lo que facilita su análisis para obtener tipos, patrones, roles y estructuras del conocimiento específico, y así se modela como un todo funcional bien estructurado, formado por partes que juegan diferentes roles restrictivos y especializados en la solución de problemas.

•

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

•

CommonKADS refleja la influencia de paradigmas ampliamente conocidos como el análisis y el diseño estructurado, la orientación por objetos, la teoría de las organizaciones, la reingeniería de procesos y la gerencia de la calidad. Esto tiene la ventaja que toma en cuenta tanto la experiencia como las estructuras de información existentes en la organización.

•

Desde el punto de vista de CommonKADS, el SBC es un modelo operacional que exhibe los comportamientos deseados que se han especificado u observado en el mundo real.

[WVS+92], definen que el desarrollo de un sistema basado en el conocimiento, desde el punto de vista de CommonKADS, es entendido como la construcción de una serie de modelos de comportamiento de solución de problemas, vistos en su contexto organizacional y de aplicación concreto. En estos modelos se incluyen tanto los conocimientos de los expertos como los de otros sistemas del entorno, tales como la organización, el usuario y la interacción entre éste y el sistema. Un SBC es una realización computacional asociada con estos modelos. CommonKADS también ofrece una serie de formularios que facilita la labor de construcción del sistema y que permite obtener las especificaciones y los requerimientos de

CommonKADS-RT – Capítulo 2. Estado del Arte

33

un problema y su solución, desde el punto de vista de su relación con el resto de la organización, de los entes que participan en el problema y del conocimiento que se requiere para llegar al sistema final. Más adelante se ampliará este tema de los modelos. Estos formularios son su forma estructural.

2.2.6.2

Ciclo de vida en CommonKADS

CommonKADS está fundamentada en el modelo del ciclo de vida en espiral que tanto se trabaja en la Ingeniería del Software y que proporciona una estructura para el desarrollo del sistema computarizado [WSB92]: •

El desarrollo se divide en un conjunto de fases con un orden de ejecución predeterminado.

•

Dentro de cada fase debe llevarse a cabo un conjunto de actividades distintas.

•

Al final de cada fase han de producirse uno o más productos tangibles (por ejemplo, documentos, informes, diseños, programas) normalmente como entradas a otras fases.

La metodología está formada por una serie de etapas, cada una con unas tareas y productos asociados. Brevemente éstas son: •

El Análisis: Se realiza para comprender el problema desde el punto de vista de la solución que se piensa desarrollar. Está formado por la especificación de los requerimientos externos del sistema basado en el conocimiento y por un análisis del problema específico. Los productos que se deben obtener en esta etapa son: un documento del proyecto, un documento de los requerimientos, un documento del modelo (modelo conceptual), un documento de viabilidad y un documento de apoyo.

•

El Diseño: En el cual se hace una descripción del comportamiento del sistema (descripción funcional) y una descripción física en la que se especifica detalladamente cada uno de sus componentes. De esta etapa debe salir toda la especificación modular del sistema y la descripción detallada de cómo debe ser, desde el punto de vista computarizado.

•

Implantación del sistema: En esta etapa se considera tanto la integración del software desarrollado como su adaptación en la organización.

•

Instalación: Consiste en la puesta en marcha del sistema con el fin de que comience a operar en la empresa, iniciándose su proceso productivo.

•

El uso: Se plantean actividades relacionadas con el manejo mismo del sistema y de las salidas o resultados que éste proporciona.

•

El mantenimiento y refinamiento del conocimiento.

CommonKADS-RT – Capítulo 2. Estado del Arte

2.2.6.3

34

Los modelos de CommonKADS

Permiten describir el conocimiento de la solución de problemas en un dominio particular usando niveles de abstracción que le posibilitan al ingeniero del conocimiento el detallar el proceso de solución en una forma independiente del dominio [DMW+94]. La idea central de esta metodología es agrupar los datos relevantes en modelos separados. En la Figura 2-2 se presentan los diferentes modelos que soportan el análisis del conocimiento en CommonKADS y que constituyen su núcleo.

Modelo de la Organización Qué

Quiénes Modelo de Agentes Cómo se relacionan

Modelo de Tareas Qué saben Con qué

Modelo de Comunicaciones

Modelo de Conocimientos

Base de conocimientos, Razonamiento interfaz Modelo del Diseño

Figura 2-2 Modelos de CommonKADS

•

Modelo de la organización

Este modelo refleja el análisis de las características principales de una organización con el objetivo de descubrir problemas que pueden ser solucionados por sistemas de conocimiento, establecer su viabilidad y evaluar el impacto que tendría en el entorno donde se implanten. Está formado por una serie de constituyentes o conceptos que reflejan la información y el conocimiento de la organización, sus problemas y sus soluciones, especialmente basadas en el conocimiento. En la Figura 2-3 se presenta su estructura, siguiendo la notación de [DBM+94]. Donde, −

El Contexto organizacional se relaciona con las características claves del ambiente de la organización, tales como la misión, la visión, los objetivos de la organización.

−

Problemas y oportunidades: Constituyen la lista de los problemas de la organización o las necesidades que son consideradas para ser más o menos urgentes que pueden ser solucionados o mejorados por el SBC.

CommonKADS-RT – Capítulo 2. Estado del Arte

35

−

Problema actual, referente a un problema o a una oportunidad en la cual la compañía ha decidido hacer esfuerzos y que ha sido seleccionado de la lista de Problemas y Oportunidades.

−

Solución: Corresponde a los escenarios que han sido o serán desarrollados para solucionar el problema actual o modificar las necesidades presentes.

−

Función: Es un inventario de las funciones que pueden ser distinguidas en una organización particular. Por ejemplo producción, finanzas, relaciones laborales o comercial.

−

Proceso: Se refiere al flujo de trabajo (work-flow) o de control (control-flow) de los procedimientos básicos de la empresa.

−

Estructura: Indica la disposición de la organización en función de sus departamentos, grupos, unidades o secciones. También, la descripción del proceso del negocio, entendiendo un proceso como una parte relevante de la cadena de valor que es enfocada.

−

Personas o roles que se juegan en una organización y que son fundamentales en los procesos y funciones de la empresa.

−

Conocimiento: Representa el conocimiento general y de alto nivel que puede influir en la definición del problema actual o en sus soluciones.

−

Recursos computacionales que soportan los procesos de la compañía.

−

Otros recursos: Referente a los demás recursos (económicos, de papelería, de propiedades, entre otros) que se requieren en la compañía para realizar las funciones y cumplir con los objetivos de la organización.

−

Cultura y Poder: Son las relaciones que existen entre los roles, las formas en que se realizan las actividades y las políticas formales e informales que soportan la organización.

Estos constituyentes están clasificados como variables o invariables para que se puedan tener diferentes instancias del modelo en diferentes soluciones para el mismo problema: −

Dependientes de la solución considerada. En la Figura 2-3 no están dentro de un marco de líneas punteadas.

−

Los invariables son los que en la Figura 2-3 están encerrados en un marco de líneas punteadas. No dependen del tipo de solución en particular porque se asumen como fijos.

En CommonKADS, también se han incluido unos formularios que contienen la descripción de los constituyentes y que permiten que el Ingeniero del Conocimiento refleje fácilmente la información relativa a su organización. A continuación se nombran

CommonKADS-RT – Capítulo 2. Estado del Arte

36

los que pertenecen al Modelo de la Organización (Organization Model - OM). En [SAA+98] están detallados: −

OM-1: Identificación en la organización los problemas y oportunidades orientados al conocimiento.

−

OM-2: Descripción de los aspectos de la organización que tienen impacto en o están afectados por la solución de conocimiento escogida.

−

OM-3: Descripción del proceso desde el punto de vista de las tareas en que está compuesto y sus características principales.

−

OM-4: Descripción del componente de conocimiento del modelo de la organización y sus principales características.

−

OM-5: Lista de chequeo para el documento de viabilidad de la decisión.

Contexto Organizacional Modelo de Agentes

situado en pertenece a

Problema actual

mejorados por

Problemas y oportunidades

se refiere a

realizadas por Soluciones

Agente

respaldadas por

se refiere a

puede ser

tiene posiciones en Estructura y organización

Personas -Rolesderivado de

mantienen aplicado por

realizada en

Cultura y poder

puede ser

posee

derivado de

Conocimiento

realizada por

Proceso

aplicado por

Recursos computacio.

requiere Función

define

usados en

parte de

sirve Tarea

Modelo de Tareas

Figura 2-3 Modelo de la organización de CommonKADS

Otros recursos

CommonKADS-RT – Capítulo 2. Estado del Arte

•

37

Modelo de tareas

Para CommonKADS una tarea es una parte de un proceso de negocios que representa una serie de actividades orientadas a alcanzar un objetivo, llevada a cabo por unos agentes que siguen unos criterios de calidad y rendimiento. La tarea recibe entradas y entrega salidas deseables en una forma estructurada y controlada, consume recursos y requiere (y provee) conocimiento y otras habilidades. El análisis de tareas le sirve al IC para organizar una vista de las tareas principales que un experto realiza en un área dada y para determinar el alcance del SBC que servirá de soporte en el análisis de viabilidad del proyecto. En [Duu94] se dice "no es posible definir el concepto de tareas en cuanto a las condiciones necesarias y suficientes, pero nosotros somos capaces de describir qué clase de actividades y comportamientos se pueden considerar tareas y que pueden ser aplicados muy útilmente en la metodología". A continuación se presentan estas características: −

Una tarea tiene un comienzo y un final confirmados. Se ejecuta en un período relativamente corto o puede ser dividida en sub-tareas que permiten que se cumpla esto.

−

Cada sentencia de la tarea debe ser entendida claramente por quien hace el trabajo. Una sentencia es una serie coherente de actividades.

−

La sentencia describe una parte finita e independiente del trabajo. Es decir, tiene significado en el contexto del proceso y sus instrucciones deben dar una descripción completa de la correspondiente tarea.

−

Cada tarea debe ser manejable en función del tiempo consumido en su realización.

−

Una tarea comienza con una clave observable que permite definir cuando ésta es iniciada. Es importante resaltar que en el caso en que la tarea sea continua, la clave no existe.

−

La sentencia de una tarea debe evitar el incluir calificativos.

−

La sentencia usa un verbo, excepto cuando varias acciones se ejecutan juntas.

−

La tarea se debe poder medir, su resultado o producto puede ser estimado o medido.

Por lo tanto, el modelo de tareas permite reflejar el proceso de análisis de la tarea elegida. El enfoque que presenta CommonKADS para este modelo tiene dos ideas innovadoras: 1) Se pueden tener varias versiones del modelo para modelar las situaciones actuales, intermedias y requeridas; varios modelos de tareas pueden ser instanciados en diferentes estados de un proyecto. 2) El tener el modelo enmarcado en un desarrollo orientado a los riesgos permite que se revisen continuamente.

CommonKADS-RT – Capítulo 2. Estado del Arte

38

Los constituyentes de este modelo se ven relacionados en la Figura 2-4 y son los siguientes: −

Tarea: Entidad que representa una tarea del proceso y que es la parte central del modelo.

−

Característica: Refleja una propiedad de la tarea que la caracteriza en cuanto a un lenguaje abstracto.

−

Entorno: Representa las restricciones formales en la ejecución de la tarea, que son establecidas dentro de la organización, a través de las leyes generales, de reglas comerciales o profesionales.

−

Ingrediente: Representación de una entrada de la tarea o ingrediente de salida. Un ingrediente describe los contenidos de información que son usados o producidos por la tarea. Esta descripción es orientada hacia la semántica de la información, no a su representación sintáctica.

−

Capacidad: Representación de una capacidad necesaria para ejecutar la tarea.

Modelo de la Organización

Modelo de Conocimiento

Función Tarea sirve implementada por

define

Otro subsistema

realizadas por

Tarea

tiene

Característica

implementada por Subsistema SBC

realizadas en

requiere entrada

Modelo de Diseño

Entorno

Capacidades

especificada por

salida

Ingrediente tiene suministra

ejecutada por Agente Modelo de Agentes

Transacción especificado en Elemento de información

recibe

Modelo de Comunicación

Figura 2-4 Modelo de tareas de CommonKADS

CommonKADS-RT – Capítulo 2. Estado del Arte

39

Los formularios que se proponen para este modelo (TM) son: − −

TM-1: Descripción refinada de las tareas dentro del proceso objetivo. TM-2: Especificación del conocimiento empleado por una tarea y posibles cuellos de botella y áreas para mejorar.

Los resultados que se obtienen al construir las diferentes instancias del modelo de tareas se utilizan en CommonKADS para: −

Documentar el resultado del análisis de las actividades actuales.

−

Documentar el resultado del diseño de la tarea y sus actividades propuestas.

−

Soportar la administración del cambio organizacional.

−

Fijar el alcance de la solución del SBC.

−

Soportar la evaluación de la viabilidad del proyecto.

−

Identificar las necesidades de capacitación y entrenamiento.

−

Evaluar la eficiencia, robustez y calidad del trabajo en la organización.

•

Modelo de agentes

Para CommonKADS un agente es quien ejecuta una tarea. Puede ser un individuo, un sistema de información o cualquier otra entidad capaz de llevar a cabo dicha ejecución. Incluso el SBC por sí mismo es un agente para CommonKADS, lo mismo que el usuario que va a interactuar con él. La idea de agente que se maneja en CommonKADS es la de actor, no es exactamente la misma que se trabaja en Agentes Inteligentes o en Sistemas Multiagentes. Para este último, se ha presentado MAS-CommonKADS que es una extensión de CommonKADS que permite modelar sistemas en los que se presentan diversos agentes como sistemas distribuidos. Para tener más información al respecto ver [Igl98]. Este modelo sirve como enlace entre el modelo de tareas, el de comunicación y el de conocimientos para modelar las capacidades y limitaciones que los agentes tienen y que están involucradas en la solución de la tarea. En la Figura 2-5 se muestran los constituyentes del modelo de agentes de CommonKADS [WaG93]:

CommonKADS-RT – Capítulo 2. Estado del Arte

40

−

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

−

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

−

Capacidades: Este constituyente contiene dos atributos: o Habilidades que se tienen para manipular el entorno en diferentes formas y acceso a información sensorial. Esto está relacionado con los dispositivos que pueden imitar los órganos de los sentidos como los brazos robóticos o los sensores en el ordenador. o Vocabulario. Describe el lenguaje de comunicación del agente.

−

Restricciones: Éste tiene tres atributos, de los cuales los dos primeros solamente se aplican a agentes humanos: o Normas que se refieren a lo que el agente considera que es lo más apropiado para hacer en ciertas situaciones. o Preferencias de cómo le gustaría al agente realizar una tarea en particular. o Permisos que tiene el agente dentro de una tarea.

Las relaciones que hay entre el modelo de agentes y los demás se interpretan de la siguiente forma: −

Relaciones Organización – Agente: Todos los agentes corresponden a personas o recursos en el modelo de la organización. La posición y el rol de los agentes son coherentes con sus responsabilidades.

−

Relaciones Tarea – Agente: Todas las tareas son asignadas a los agentes que son capaces de ejecutarlas y todos los ingredientes en el modelo de tareas son servidos y recibidos por los agentes relevantes.

−

Relaciones Conocimiento – Agente: Las capacidades de razonamiento descritas en el modelo de agentes son modeladas adecuadamente por (un subconjunto de) el correspondiente modelo de conocimientos.

CommonKADS-RT – Capítulo 2. Estado del Arte

−

41

Relaciones Comunicación – Agente: Todas las transacciones tienen al menos dos agentes involucrados, uno que posee la información y otro que la recibe para el mismo ingrediente. Al menos dos de los agentes involucrados tienen la capacidad y los permisos requeridos para participar en la transacción.

Modelo de Comunicación Transacción

Restricciones

tiene Capacidades

participa en

inicia Soluciones

efectuadas por

tiene Agente tiene

Capacidades de Razonamiento

es un

Recursos

puede ser Personal recibe

suministra

ejecuta

descrito por

Modelo de la Organización

Tarea Conocimiento de aplicación

Conocimiento estratégico

Modelo del Conocimiento

Ingrediente

Modelo de Tareas

Figura 2-5 Modelo de agentes de CommonKADS

Para este modelo sólo se ha proporcionado el siguiente formulario (AM): o AM-1: Especificaciones del Agente de acuerdo con el modelo de agentes de CommonKADS

•

Modelo de conocimientos

Su propósito es explicar en detalle los tipos y estructuras del conocimiento usado en la realización de una tarea. Para su definición se ha desarrollado el lenguaje CML2 (CML - Conceptual Modeling Language) [AnS94], que proporciona todas las estructuras necesarias para especificar los datos y el conocimiento del sistema. La definición que se hace en este lenguaje, es independiente de la implementación del

CommonKADS-RT – Capítulo 2. Estado del Arte

42

mismo. CML2 está basado en el lenguaje (ML)2 [HaB92]. El modelo de conocimientos sigue una estructura que determina las diferentes categorías del conocimiento que se maneja en el SBC, como se puede apreciar en la figura 2-5. En CommonKADS el conocimiento está diferenciado, dependiendo del tipo de conocimiento que se trate (niveles). La importancia de separar el conocimiento del dominio del de control es que permite hacer su reutilización. Así, el conocimiento del dominio puede ser utilizado de nuevo para diferentes tareas y el de la tarea en diferentes dominios. −

El conocimiento del dominio tiene como propósito definir la conceptualización del dominio y debe ser representado en forma independiente de su uso.

−

El conocimiento de inferencia define el primer tipo de conocimiento de control. Especifica las derivaciones que constituyen un método de solución del problema, la forma como se usa el conocimiento del dominio en las inferencias y los roles del conocimiento que modelan las premisas y las conclusiones de las deducciones.

−

El conocimiento de la tarea representa una estrategia fija para alcanzar las metas de la solución del problema. Por lo tanto es otro tipo de control que tiene como propósito especificar el registro de la ejecución de los pasos de inferencia básicos definidos en el conocimiento de inferencia.

El modelo de interpretación del SBC está formado por el conocimiento de control, en este caso por el de inferencia y de tarea. Esto también se conoce como un Método de Solución de Problemas que define en términos genéricos un modelo del comportamiento de la capacidad de solución de problemas del sistema. Los PSM forman librería que permiten su reutilización [BeM97], [Ben93] y pueden ser usados como guía en la adquisición del conocimiento del dominio y del conocimiento adicional de la solución de problemas específico del dominio, tal como las heurísticas y las restricciones.

Categoría del Conocimiento

Categoría del Dominio

Categoría de Inferencia

Categoría de la Tarea Metas

Esquemas del Dominio Conceptos

Relaciones

Modelo del Dominio Esquema de Reglas

Inferencia

Estrategias

Funciones de Transferencia

Roles del Conocimiento Roles Dinámicos

Roles Estáticos

Figura 2-6 Jerarquía del modelo de conocimientos de CommonKADS

CommonKADS-RT – Capítulo 2. Estado del Arte

43

Para el modelo del conocimiento sólo se ha planteado el siguiente formulario (Knowledge Model - KM): −

KM-1: Lista de chequeo de la documentación del dominio

Muchos métodos y metodología utilizan como base este modelo del conocimiento, haciendo variaciones en algunos de sus conceptos, pero manteniendo la estructura y la idea fundamental de reutilización [Abe92], [Abe93], [BrV94] [BrW89].

•

Modelo de comunicación

El propósito de este modelo es especificar los procedimientos de intercambio de información para realizar la transferencia de conocimiento entre los agentes que participan en la ejecución de una tarea. Al igual que con el modelo anterior, esto es hecho en una forma conceptual e independiente de su implementación [WHG+93]. El componente clave del modelo es la transacción que describe los actos de comunicación entre los diferentes agentes que participan en una tarea en el sistema. Dice qué objetos de información son intercambiados entre qué agentes y qué tareas. Como plantea [SAA+98] “Las transacciones son bloques de construcción para el diálogo completo entre dos agentes, lo cual es descrito en el plan de comunicación”. Por tanto, la transacción por sí misma consiste de diversos mensajes que son detallados en la especificación del intercambio de información, basada en tipos y patrones de comunicación. Este modelo se construye desde lo general hasta lo particular, de la siguiente forma: −

Se define el plan completo de comunicación que dirige el diálogo entre los agentes.

−

Se determinan las transacciones individuales que relacionan dos tareas, llevadas a cabo por dos agentes diferentes.

−

Se especifica el intercambio de información que detalla la estructura interna de los mensajes de una transacción.

En la Figura 2-7 se presentan los siguientes constituyentes o conceptos de este modelo: −

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

CommonKADS-RT – Capítulo 2. Estado del Arte

44

−

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

−

Discurso: Define el plan para llevar a cabo la transacción en particular como un conjunto de interacciones únicas o acciones lingüísticas. Se utiliza para expresar cosas como el hecho que hay que suspender un mecanismo o para fraccionar la transferencia de un ingrediente.

−

Artículos de información: Deben precisar cómo se expresan las diferentes acciones lingüísticas que ocurren en el discurso. Se utilizan para definir la forma en que son transferidos los ingredientes. Este concepto está formado por dos atributos: el objeto sintáctico y el medio de salida.

−

Capacidades: Por cada parte involucrada en una transacción hay un conjunto de capacidades que el agente tiene que tener para ejecutar dicha transacción. Para esto, se tienen dos atributos: conocimiento y habilidad. El primero sirve para describir el conocimiento relacionado con la tarea de razonamiento del sistema o con el conocimiento del agente. El segundo se refiere a la(s) habilidad(s) que el agente debe tener, aparte de su conocimiento, para participar en la transacción.

Modelo de Tareas Discurso

consiste de

Artículos de Información

Transacción

realizada por Capacidades

requiere es parte de

Plan de Comunicación realizadas por

Funciones de

Modelo del Conocimiento

participa en

Transacción

participa en

Modelo de la Agentes

inicia implementado por

Subsistema de interacción

Modelo de Diseño

Figura 2-7 Modelo de comunicaciones de CommonKADS

Agente

CommonKADS-RT – Capítulo 2. Estado del Arte

45

Al igual que los demás modelos, tiene unos formularios (Communication Model CM) que facilitan su construcción: −

CM-1: Especificación de las transacciones que participan en el diálogo entre dos agentes en el modelo de comunicaciones.

−

CM-2: Especificación de los mensajes y la información que forman una transacción individual dentro del modelo de comunicaciones.

•

Modelo de diseño

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

Paso 1

Diseño Arquitectura

Arquitectura de referencia de CommonKADS

Paso 2

Especificac. plataforma Hw/Sw

Lista de entornos disponibles

Paso 3

Paso 4

Especificac. detallada de la arquitectura

Lista de chequeo de decisiones de la arquitectura

Diseño detallado aplicación

Relaciones prefijadas a la arquitectura

Conocimiento de soporte dado por CommonKADS

Figura 2-8 Pasos del diseño del sistema

CommonKADS-RT – Capítulo 2. Estado del Arte

46

−

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

−

Paso 2: Identificar la plataforma de implementación objetivo, es decir, escoger el hardware y el software que debería ser usado en el sistema. Para esto se tienen una serie de características relevantes para considerar en el momento en que se va a elegir el software: disponibilidad de las librerías de los objetos, representación del conocimiento declarativo, interfaces estándar con otro software, flujo de control, soporte de CommonKADS y, se cuenta con el formulario DM-2: Especificación de las facilidades ofrecidas por y en el sistema objetivo que será implementado.

−

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

−

Paso 4: Especificar la aplicación dentro de la arquitectura. Se toman los ingredientes de los modelos de análisis (tareas, inferencias, modelos del dominio, transacciones) y se reflejan en la arquitectura. Para el diseño detallado de la aplicación (paso 4) se tiene el formulario DM-4: Decisiones de la aplicación de diseño que especifica las decisiones tomadas para cada uno de los elementos de la arquitectura.

CommonKADS proporciona algunas ayudas para realizar cada uno de los pasos del modelo de diseño: −

La arquitectura de referencias está basada en la metáfora Modelo-VistaControlador (Model View Controller - MVC) que fue desarrollada como un paradigma para diseñar programas en el lenguaje SmallTalk-80. En esta arquitectura se distinguen tres sub-sistemas principales: o

El modelo de la aplicación que contiene las funciones de razonamiento. Los datos estáticos son las bases de conocimiento y los datos dinámicos manipulados durante el proceso de razonamiento.

o

Las vistas que especifican las visualizaciones de las funciones y datos de la aplicación. Hacen que la información estática y dinámica de la aplicación esté disponible para los agentes externos.

o

El controlador es la unidad de control que maneja los eventos internos y externos.

CommonKADS-RT – Capítulo 2. Estado del Arte

2.2.6.4

47

Integración de los modelos

Los modelos de CommonKADS están clasificados en tres niveles o vistas que posibilita el tener la información completa para construir el SBC en forma eficiente. •

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

•

El nivel de conceptos para especificar lo que se quiere modelar. Responde preguntas como: ¿Cuál es la naturaleza y la estructura del conocimiento involucrado en la tarea? ¿Cuál es la naturaleza y estructura de la comunicación correspondiente? ¿Qué conocimiento se requiere para solucionar el problema? Por tanto, es necesario tener modelos que presenten la descripción conceptual del conocimiento aplicado a una tarea y los datos que son manejados y entregados por un sistema de conocimientos. En este nivel se tiene el modelo de conocimientos y el de comunicación.

•

El nivel del artefacto o componente para identificar los aspectos técnicos de programación y de construcción en el ordenador. Da solución a preguntas del cómo: ¿Cómo tiene que ser implementado el conocimiento en un sistema basado en ordenador? ¿Cómo debe ser la arquitectura del software? ¿Cómo se debe traducir el conocimiento a un lenguaje comprensible por el ordenador? En este nivel está el modelo de diseño.

Para ver la integración de los modelos es útil plantear un ejemplo sencillo en el que se haga esto explícito: en la interacción entre un usuario que proporciona datos a un sistema de conocimientos y en donde este último razona y le presenta resultados al primero, entonces los modelos contendrían en términos generales lo siguiente: El modelo de agentes la descripción de los agentes involucrados, junto con sus capacidades; el modelo de tareas presenta las tareas, sus entradas y salidas (objetos de información) y su asignación a los diferentes agentes; Si la tarea es intensiva en conocimientos, entonces se describe en el modelo de conocimientos, incluyendo una función de transferencia que indique que la entrada y la salida del proceso de razonamiento deben ser obtenidas o entregadas a otro agente; En el modelo de comunicación se describe la comunicación entre los agentes que participan en el sistema; y por último, en el modelo del diseño se especifica la arquitectura física de dicho sistema. Además de todo lo anterior, CommonKADS plantea una serie de consideraciones para la Gestión del Proyecto de Conocimiento (Project Management - PM) [Anj99], formada por cuatro actividades: •

Revisión. Se revisa el estado actual del proyecto y se definen los principales objetivos para el ciclo siguiente. Es el primer estado en la administración del proyecto de cada ciclo.

CommonKADS-RT – Capítulo 2. Estado del Arte

48

•

Riesgo: Se identifican los obstáculos que pueden presentarse en el desarrollo del proyecto y que pueden impedir que se cumpla con los objetivos definidos. Se cuenta con el formulario PM-1: Identificación y valoración de los riesgos del proyecto.

•

Plan. Se hace el plan detallado para el siguiente ciclo, en función del grado de finalización de uno o varios modelos (estados de los modelos). Se tiene el formulario PM-2: Cómo describir el estado del modelo como un objetivo a ser alcanzado en el proyecto.

•

Seguimiento, para registrar los cambios y lo resultados obtenidos.

Para cada una de estas actividades se ha definido una serie de documentos, reflejados en la Figura 2-9, que deben ser creados al comienzo del proyecto y completados durante el progreso de cada ciclo.

Seguimiento

- Reportes periódicos de los progresos - Registro de las reuniones de evaluación y aceptación de las salidas del ciclo

- Revisión de las conclusiones de los resultados actuales medidos contra los proyectos de progresoso esperados, como una entrada para el siguiente ciclo

Plan

- 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 - Salidas del ciclo basadas en los estados de los modelos PM-1. - Descripción de los criterios de aceptación sobre los cuales se evaluarán las salidas planeadas del ciclo

Revisión - Posición y propósito del ciclo dentro del plan del proyecto - Resumen de la salida del ciclo anterior, definiendo el punto de inicio del ciclo actual - Objetivos del ciclo y bosquejo del plan - Restricciones, alternativas consideradas, elecciones tomadas para el ciclo - 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

Riesgo

Figura 2-9 Documentación del ciclo de la gestión del proyecto en CommonKADS

2.2.6.5

Artefactos obtenidos al construir un SBC con CommonKADS

Si el proyecto se ha desarrollado siguiendo las pautas planteadas en CommonKADS, entonces éste estará formado por 3 tipos diferentes de productos que permiten la conformación del proyecto de conocimientos. Cada uno tiene una importancia relativa para el proyecto final:

CommonKADS-RT – Capítulo 2. Estado del Arte

49

•

Documentos detallados de los modelos de CommonKADS, incluyendo los formularios diligenciados para el sistema en particular. Tal como se mencionó en la sección 2.2.6.2 Ciclo de Vida en CommonKADS.

•

Información relacionada con la administración del proyecto y su seguimiento, presentado en la Figura 2-9.

•

Software del sistema de conocimientos.

2.2.7

Ventajas y desventajas de CommonKADS

• Ventajas o Fortalezas de CommonKADS Una de las principales cualidades de CommonKADS es el planteamiento del desarrollo de modelos que reflejan diferentes vistas del proyecto. Entre ellos se resalta el modelo de conocimiento en el que las partes que lo conforman son independientes del dominio, es decir que son genéricas y puede ser usadas en otros problemas o SBC que tengan características o comportamientos similares (los llamados modelos de interpretación). La gestión del proyecto que se plantea en CommonKADS es un punto importante para destacar, ya que involucra aspectos administrativos que muchas veces no se toman en cuenta al desarrollar un sistema informático. Esto permite que los productos que resultan al aplicar la metodología, puedan ser valorados e integrados fácilmente en la Gerencia de la organización. CommonKADS es importante porque ofrece un marco para la especificación del conocimiento independiente de la implementación, combinando un conjunto de modelos de conocimiento reutilizable para unas tareas que se realizan frecuentemente, como por ejemplo el diagnóstico o la planificación, entre otras. Además, propone un ciclo de vida en donde se indican las fases, las actividades y los productos más relevantes para un proyecto de desarrollo de un SBC. Adicionalmente, los modelos que propone la metodología permiten reflejar diferentes visiones fundamentales en el SBC, desde el punto de vista de la empresa hasta la forma como éste se diseña. Dentro de estos modelos, el de Agentes y el de Comunicaciones son particulares a CommonKADS, siendo quizá una de las debilidades de las otras metodologías, pues no consideran la comunicación con otros sistemas. Ambos modelos, le permiten al sistema coordinar las actividades con otros agentes y ser más que un sistema basado en el conocimiento para ser un sistema que coopera con otros. Otro aspecto para resaltar de esta metodología es el hecho de que es una de las más utilizadas para el desarrollo de SBC, tomándose incluso como el estándar europeo. Numerosas universidades y empresas europeas como bancos y compañías entre otras han realizado sus proyectos a través de las técnicas de CommonKADS.

CommonKADS-RT – Capítulo 2. Estado del Arte

50

• Desventajas o debilidades de CommonKADS En general esta metodología cubre todos los aspectos que se necesitan para llevar a buen término un proyecto de desarrollo de un SBC, desde el estudio del problema hasta la implantación del software y su gestión. Los aspectos negativos que se presentan son más de su aplicación que de su conceptualización, porque aplicar lo definido en ella requiere de mucha experiencia y conocimiento de la misma metodología. Esto por varias razones: −

La metodología es muy compleja y amplia.

−

Hay mucha información relevante que está en diversos sitios, lo que dificulta su acceso y comprensión.

−

No hay una fuente de información que contenga todo lo necesario para su aplicación.

−

No hay un ejemplo completo de la aplicación de la metodología que pueda ser utilizado como guía. Hay muchos ejemplos pero parciales.

Pero, a pesar de lo anterior y dado los objetivos de esta investigación, se decide que CommonKADS es la metodología más apropiada para desarrollar sistemas basados en el conocimiento.

CommonKADS-RT – Capítulo 2. Estado del Arte

2.3

51

Sistemas de tiempo real

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

2.3.1

Generalidades de los sistemas de tiempo real

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

Sistemas críticos (Hard Real-Time Systems), en donde es imperativo que el tiempo de respuesta del sistema sea acotado y el incumplimiento de las restricciones del tiempo causa un fallo grave en el mismo sistema o en el entorno. Estos requisitos temporales tienen que ser conocidos con anterioridad para evitar errores en la computación: “Tener tarde los datos es como tener datos malos” [Dou98]. Según el Manifiesto de Tiempo Real [RTM96] “una actividad (típicamente una tarea) es considerada de tiempo real crítico si y solamente si ésta tiene un límite máximo de tiempo crítico para la realización de una acción (típicamente, la ejecución de la tarea completa), es decir, que el máximo límite de tiempo tiene siempre que ser alcanzado o de otra forma el sistema falla”. Por lo tanto, el entorno de ejecución y las propiedades de las actividades tienen que ser conocidas con anticipación para que puedan ser alcanzados los tiempos definidos. Así, para que el sistema pueda ser predecible tiene que ser determinista, o sea, que se conocen con anterioridad, tanto los

CommonKADS-RT – Capítulo 2. Estado del Arte

52

estados en que puede estar, como las entradas que requiere para que produzca una salida que le permita pasar de un estado a otro. En el ámbito de los STR se han especificado unos sistemas críticos en el que además de la especificación del software, es fundamental el hardware. Estos se conocen como sistemas empotrados y se usan para controlar equipo especializado que está ubicado en el mismo entorno del sistema. Por ejemplo, el sistema de microprocesadores usado para controlar la mezcla de gasolina / aire en el carburador de muchos automóviles [Lap92]. Por último, es importante mencionar que se han desarrollado muchos STR críticos, y entre ellos los ejemplos más típicos son: 1) sistema de un marca pasos cardíaco. 2) el sistema que controla el frenado (ABS) de un coche. 3) el sistema que controla un reactor nuclear. •

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

•

La clasificación de sistemas críticos y no críticos es la más conocida, pero Bernat en [Ber98] propone un tercer tipo, llamado Sistemas débilmente críticos (Weakly Hard Real-Time Systems). Son sistemas en los cuales se define una degradación de los límites de tiempo que pueden ser incumplidos. Son críticos en el sentido que tienen que garantizarse de antemano que su especificación temporal se cumplirá, pero tienen algunas actividades no críticas que tienen asociado un tiempo promedio de respuesta.

Hay también otra clasificación para estos sistemas, de acuerdo con el comportamiento que tienen cuando se relacionan con el entorno [Dou99]: •

Sistemas orientados a eventos del entorno, en donde el comportamiento del sistema es causado por reacciones específicas a sucesos producidos en el entorno.

•

Sistemas orientados al tiempo, cuyas acciones están principalmente dirigidas por el paso del tiempo. Por eso son sistemas que están orientados al manejo de tareas periódicas más que a la llegada esporádica de eventos.

CommonKADS-RT – Capítulo 2. Estado del Arte

53

Un sistema de tiempo real responde a una serie de eventos que pueden ser producidos en su interior o en su entorno, llamándose eventos internos o externos, respectivamente y que se caracterizan por lo siguiente: •

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

•

Eventos episódicos, aperiódicos o asíncronos, son los que arriban en forma impredecible al sistema y por esto dificultan el cumplimiento del plan de acción y respuesta del sistema y provocan que el sistema no sea determinista. Usualmente son causados por fuentes externas [Lap92] y suelen tener asociado una frecuencia promedio de llegada. Así, no hay o no se conoce una relación temporal entre dos eventos consecutivos del sistema. Por ejemplo, cuando el sistema recibe una señal de alarma que no estaba esperando.

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

2.3.2

Especificación de los sistemas de tiempo real

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

CommonKADS-RT – Capítulo 2. Estado del Arte

•

54

La fase de la especificación tiene como objetivo el determinar el comportamiento que el sistema debe tener para cumplir con su propósito. En el caso de un sistema de tiempo real, además de esto, se aplica también a la determinación de los requisitos temporales que el sistema tiene que cumplir y las propiedades que debe tener, lo que se conoce como la especificación temporal. La especificación temporal del sistema es fijada por la determinación de los requisitos temporales del sistema. Los siguientes parámetros o variables permiten expresar algunas de estas restricciones: −

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

−

El mínimo o máximo retardo que tiene que transcurrir antes de comenzar la ejecución de la tarea.

−

El tiempo máximo transcurrido en el cual una tarea tiene que terminar una vez ésta ha empezado su ejecución.

−

El tiempo mínimo de separación que pasa entre dos instantes de inicio de una tarea.

−

El tiempo de respuesta que transcurre desde la entrada hasta la salida del sistema.

Como se puede observar, todas las anteriores restricciones son definidas para el tiempo, por lo que es importante entonces tener claro lo que éste implica. Para referirse al tiempo se puede hablar de tiempo absoluto (de acuerdo con el meridiano de Greenwich o con el estándar de hora local que se esté usando) o de tiempo relativo (tiempo que ha pasado desde que ha ocurrido un evento conocido en un proceso). Por ello, cuando se vayan a definir los requerimientos del STR en el análisis de requisitos, se debe identificar la referencia a utilizar, la forma en que se debe medir y las unidades respectivas [HaP88].

Para que el STR cumpla con sus restricciones temporales, debe acatar las siguientes propiedades: −

La predecibilidad (predictability) se refiere a conocer con anterioridad las restricciones temporales de las tareas para poder determinar cómo se ejecutarán y cumplirán. Por eso para que un sistema sea predecible, debe ser conocida la información referente a su especificación temporal [StR93].

−

La confiabilidad que consiste en garantizar que lo que se ha modelado es un buen reflejo de la realidad para que el sistema resultante satisfaga todos los requisitos del cliente. Como esto compete con el contexto de la implementación del sistema, se ampliará más adelante.

CommonKADS-RT – Capítulo 2. Estado del Arte

− •

55

La precisión (accuracy) y puntualidad (timeliness). Las acciones del sistema deben ser realizadas cumpliendo con los requisitos de tiempo preestablecidos.

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

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

Sensores, para leer el estado del entorno, Actuadores, para cambiar el entorno, Dispositivos de almacenamiento, para registrar el comportamiento del sistema, y Una interfaz usuario – sistema, que sirve como medio de comunicación entre un usuario humano y el sistema.

−

El lenguaje de programación debe proporcionar el soporte apropiado para desarrollar las características del sistema de tiempo real, ofreciendo instrucciones especiales para declarar las diferentes restricciones temporales y para realizar su análisis en tiempo de compilación. Debe garantizar que la creación correcta del software sea confiable, modular, que se pueda mantener y permita la estructuración de las tareas. Según [Sta92] el lenguaje debe contar con procedimientos para el manejo y recuperación ante fallos; debe facilitar el procesamiento en paralelo y la sincronización; debe permitir el acceso a los dispositivos de hardware y manejar las interrupciones o solicitudes que se requieran; y el código generado debe ser fácil de entender, leer y modificar para facilitar su mantenimiento.

−

El sistema operativo tiene un papel muy importante, ya que es quien debe dar el soporte mínimo para garantizar los requisitos de tiempo real. Si el sistema operativo es de tiempo real tiene como objetivo básico el conseguir planificar y ejecutar las tareas o procesos de tiempo real de forma que se garantice que van a finalizar a tiempo. Por tanto, la política de planificación se constituye en un elemento crucial ya que el cumplimiento de los límites de tiempo de todas las tareas dependerá del orden en que éstas se ejecuten.

CommonKADS-RT – Capítulo 2. Estado del Arte

56

−

La arquitectura para el STR debería proveer soporte para la tolerancia a fallos (fault tolerant), la planificabilidad (schedulability) y la administración del tiempo. Para esto los temas de comunicaciones, multiprocesadores y procesamiento distribuido deben ser estudiados, pero en esta investigación no se ampliará porque no está dentro del objetivo de la misma. Un estudio más detallado se presenta en [BaS86].

−

Por último, para desarrollar un sistema de este tipo se debe considerar también la forma en que se llevan a cabo las actividades conducentes a su construcción, teniendo métodos y herramientas apropiadas para ello.

A continuación se presenta el tema de los métodos de desarrollo en forma más amplia que los anteriores, dado que éste es parte fundamental del objetivo de esta investigación.

2.3.3

Métodos para desarrollar sistemas de tiempo real

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

Un sistema de tiempo real generalmente responde a estímulos o eventos externos que deben ser conocidos con anterioridad para que el sistema responda apropiadamente, a través de dispositivos que perciben (sensores) el entorno o de dispositivos que actúan (actuadores) sobre dicho entorno.

•

Muchos sistemas involucran procesamiento concurrente, es decir la ejecución simultánea de múltiples cadenas o hilos de ejecución que pueden ser realizadas en uno o en varios procesadores. Un hilo de ejecución es una serie de instrucciones que se ejecutan en forma secuencial, síncrona.

Un STR no tiene que cumplir con todo esto a la vez, pero el método de modelado que se elija debe proporcionar las herramientas necesarias para exhibir lo apropiado. Como dice [SkG89], es importante que la especificación de un sistema de este tipo no esté muy relacionada con su arquitectura para evitar perder generalidad, lo que muchas veces no se puede hacer. En cuanto al modelo del ciclo de vida, en general se utilizan los mismos de la ingeniería del software. Por ejemplo, el modelo en cascada, el modelo de prototipado rápido o el modelo en espiral de Bochm [Pre98], entre otros.

CommonKADS-RT – Capítulo 2. Estado del Arte

57

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

2.3.3.1

Métodos basados en el análisis y el diseño estructurado

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

CommonKADS-RT – Capítulo 2. Estado del Arte

58

funcionales (por ejemplo, dependencia y tiempo), los métodos estándar no permiten expresar bien ese tipo de restricciones [KaY92]. Una ventaja que se tiene cuando se desarrolla software con estos métodos es que ellos han sido empleados en una gran variedad de proyectos y por lo tanto se cuenta con una gran cantidad de personas capacitadas para asesorar en estos desarrollos y, además, en el mercado hay disponibles una variedad de herramientas que facilitan su implantación. El análisis y el diseño estructurado por sí mismo, tiene ciertas debilidades: No hay muchas guías que muestren cómo realizar la descomposición del sistema, así que muchas veces el sistema es dividido en diferentes formas por diferentes personas. Es difícil de aplicar cuando se quiere estructurar el sistema en tareas concurrentes. No hay unos patrones especiales que permitan modelar y reflejar las características de los sistemas de tiempo real, sino que los tratan como si fueran sistemas con las mismas características generales de los sistemas tradicionales. Muchas veces cuando hay evoluciones funcionales se producen grandes cambios y surgen modificaciones que pueden ser muy pesadas. Pero, a pesar de esto y precisamente para subsanar algunas de estas debilidades, se han definido algunas extensiones de estos métodos para sistemas de tiempo real [Pre98]. Entre ellos, los más conocidos e importantes son: el método de Hartley-Pirbhai y el método de Ward y Mellor que a continuación se explican: • MÉTODO HARTLEY - PIRBHAI HPM (Hartley Pirbhai Method). Esta extensión es un método gráfico usado para detallar tanto las funciones de un sistema de tiempo real como sus componentes físicos [HaH94]. Para ello, se separan las especificaciones del sistema en dos modelos, uno de procesos que permite representar los datos y los procesos que los manejan y otro de control que ilustra cómo los sucesos externos hacen que se activen los procesos: −

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

−

El modelo de control está formado por un diagrama de flujo de control y una especificación de control que muestra cómo se comporta el software cuando detecta un suceso o señal de control y los procesos que se invocan como resultado de esa ocurrencia.

Ambos modelos se encuentran relacionados. El modelo de procesos le transmite al modelo de control las condiciones de los datos y el modelo de control le pasa al de procesos la información de la activación de los procesos. Cuando los datos de un proceso hacen que se genere una salida de control se produce una condición de datos.

CommonKADS-RT – Capítulo 2. Estado del Arte

59

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

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

−

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

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

Beneficios

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

CommonKADS-RT – Capítulo 2. Estado del Arte − Método riguroso

60 − Promueve a fondo el diseño − Identifica vacíos tempranamente

• MÉTODO WARD and MELLOR Los autores de esta extensión, Ward y Mellor, crearon notaciones específicas para el modelado de sistemas de tiempo real. Las características tomadas en cuenta por ellos según [Pre98] fueron: 1) La información es percibida o generada de forma continua en el tiempo; 2) se registra la información de control que pasa por el sistema y el procesamiento de control asociado; 3) incluye las múltiples ocurrencias de una misma transformación y las transiciones entre ellas. Por esto, las principales variaciones que hicieron fueron las de agregar a la notación del flujo de datos convencional la posibilidad de representar datos discretos y continuos en el tiempo para poder vigilar la información continua que está siendo generada por algún proceso. Hacen una diferenciación importante entre un flujo de datos continuo y uno de datos discretos lo que permite que se aíslen los procesos que son críticos para el rendimiento del sistema, en el momento en que éste se está creando. Además, en el modelo físico en el que se define dónde y cómo se dará la recolección de datos continuos, la notación permite establecer en dónde se necesita un hardware que convierta señales analógicas a digitales y cuáles transformaciones requieren un software de alto rendimiento. El diagrama de flujos ha sufrido unos cambios al incluir una representación para el de sucesos o de control en el que los flujos pueden ser una entrada directa de un proceso convencional o de un proceso de registro. También tiene el procesamiento de control cuando hay ocurrencias múltiples del mismo proceso de control o de transformación de datos. Esto se puede presentar en entornos multitarea en los cuales se activan las tareas como resultado de algún procesamiento interno o de sucesos externos. La convención utilizada se presenta en la Figura 2-10:

Proceso de datos Flujo de datos

Proceso de control Elemento de control

Almacén de datos

Almacén de control

Figura 2-10 Elementos nuevos del Diagrama de Flujo

CommonKADS-RT – Capítulo 2. Estado del Arte

61

En las Figura 2-11 y Figura 2-12 se presenta un ejemplo de la aplicación de estos diagramas para modelar un STR que controla y vigila un respirador artificial que está regulando la cantidad de O2.

Valor sensado de O2

Monitorización y graduación del nivel de O2

Valor de O2 asignado

Reducción del nivel de O2

Figura 2-11 Modelado de un respirador artificial

Activación de alarma Estado del sensor Indicador de inicio de acción

Pila/Buffer con valores Datos sensados

Botón de comando del médico

Comparación de valores

Interfaz de monitoreo de pacientes

Procedimiento de regulación de concentración de O2

Ajuste de control de O2

Procesar orden de modificación

Órdenes del respirador Órdenes de modificación

Figura 2-12 Modelado de un respirador artificial

2.3.3.2

Métodos basados en el desarrollo rápido por prototipos

Al igual que para los Sistemas Basados en el Conocimiento, se han propuesto diversos métodos para la creación de Sistemas de Tiempo Real fundamentados en la idea del desarrollo rápido por prototipo.

CommonKADS-RT – Capítulo 2. Estado del Arte

62

El problema de esto es que el prototipado rápido es de naturaleza ad hoc, difícil de predecir y de manejar. Por esto, este tema no se trata con detalle en esta investigación. Pero, por mencionar algunos métodos de este estilo, están los siguientes: •

El propuesto por [LuB88] en el que se combina un modelo secuencial de tiempo real con un lenguaje de alto nivel para definir los prototipos, un método de diseño sistemático para su construcción y un entorno automático.

•

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

•

La metodología propuesta en el proyecto IPTES (Incremental Prototyping Technology for Embedded Real-Time Systems), basada en le modelo de ciclo de vida en espiral de Boehm, que incorpora soporte para la ingeniería concurrente, toma de decisiones y análisis de riesgos. Incluye la notación extendida de análisis y diseño estructurado de Ward y Mellor. Permite especificar un modelo lógico que consiste de un modelo del entorno y uno de comportamiento; un modelo físico formado por subsistemas, procesadores, tareas y módulos; un modelo de implementación que describe cómo se implanta el producto [San94].

2.3.3.3

Métodos basados en el paradigma de objetos

Básicamente, el paradigma de objetos está basado en los conceptos de objeto, abstracción, ocultamiento y encapsulación de la información [Boo94]: •

El objeto se concibe como las entidades en el dominio del problema. La especificación define las operaciones que pueden ser ejecutadas en el objeto y que son la parte visible de él (el cuerpo del objeto está oculto para los demás objetos del sistema).

•

La abstracción es usada para establecer la separación de la especificación de un objeto de su cuerpo.

•

La ocultación de la información se usa para estructurar los objetos, es decir para decidir cuál información debe estar visible y cuál no.

•

El encapsulamiento de la información permite que los objetos tengan un cuerpo y una estructura y que sean ocultos para los demás.

Un objeto, según Gomaa [Gom89] tiene unas características que son importantes de resaltar:

CommonKADS-RT – Capítulo 2. Estado del Arte

63

•

Tiene un estado que cambia como resultado de las operaciones entre los objetos del sistema. Son sus datos persistentes.

•

Es caracterizado por las acciones que él provee y que él requiere de otros objetos.

•

Es una instancia única de alguna clase.

•

Tiene restringida la visibilidad para o desde otros objetos.

•

Puede ser visto por su especificación o por su implementación.

En los últimos años, la mayoría de los métodos que se han propuesto para hacer sistemas de tiempo real han estado basados en el paradigma de objetos ya que presenta grandes ventajas. La principal es que al estructurar el sistema en objetos se logra que éste sea más fácil de mantener y que sus componentes puedan ser reutilizables. Pero también presenta algunos problemas, como por ejemplo que la forma de la solución depende sustancialmente de la estrategia informal usada para identificar los objetos y que en términos generales no ofrece alternativas para el manejo del tiempo ni tampoco considera importante la estructuración de las tareas de tiempo real. Por ello, los que han planteado métodos orientados por objetos para hacer STR se han basado en algún método ya existente y han definido una extensión propia que permita modelar apropiadamente las características específicas de estos sistemas. Los más relevantes son: HRT-HOOD, ROOM y RT-UML. A continuación se presentan éstos en más detalles. • METODOLOGÍA HRT-HOOD HRT-HOOD (Hard Real-Time Hierarchical Object Oriented Design). Esta metodología es una extensión para tiempo real estricto de una metodología para el diseño de objetos - HOOD [BuW94a] y [BuW94b]. Fue desarrollada por la Universidad de York para la Agencia Espacial Europea (European Spatial Agency - ESA). Básicamente está orientada al diseño del sistema y soporta el reconocimiento de los tipos de actividades / objetos de acuerdo con los atributos que debe tener un STR (tipo de tareas: Periódicas, aperiódicas, esporádicas, cíclicas). También permite hacer la definición explícita de los requerimientos de tiempo para cada objeto de la aplicación y la descomposición del sistema en una arquitectura lógica (objetos, operaciones y reglas de descomposición jerárquica y uso) y en una arquitectura física (atributos temporales) que es adecuada para trabajar con el análisis de planificabilidad de tareas y tiempos [Del97]. HRT-HOOD hace una clasificación de objetos de acuerdo con las características de tiempo real: en el programa hay objetos cíclicos, esporádicos, protegidos, y pasivos, entre otros. Distingue entre la sincronización requerida para ejecutar las operaciones del objeto (estructura de control del objeto) y cualquier actividad interna, concurrente e independiente dentro del objeto (thread). Maneja los atributos del objeto para expresar el límite de tiempo y el tiempo de ejecución en el peor de los casos. [BuW94a] plantea que el diseño se centra en dos actividades básicas:

CommonKADS-RT – Capítulo 2. Estado del Arte

64

−

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

−

Diseño de la arquitectura física para establecer los requerimientos no funcionales (los atributos temporales) y se debe garantizar que estos se cumplan una vez se haya realizado el diseño detallado y la implementación. En esta etapa se lleva a cabo un análisis de planificación de los objetos terminales para garantizar la confiabilidad del sistema.

HRT-HOOD está enfocado a las etapas de diseño lógico y físico y busca incluir las características no funcionales de tiempo y dependencia lo más temprano posible en el ciclo de vida de desarrollo. Su objetivo final es producir un diseño que facilite el desarrollo de un método formal y que permita realizar un análisis de planificación. Aunque ésta es una de sus fortalezas, también es una de sus debilidades ya que no hace énfasis en el análisis del problema y su modelado gráfico. Por lo tanto, es más bien un método de diseño. • MÉTODO ROOM ROOM (Real-Time Object-Oriented Modeling). Es un método para el desarrollo de software de tiempo real que se basa en el paradigma de objetos y es el resultado de un proyecto que se llevó a acabo en los laboratorios de Investigación Bell-Northern, Estados Unidos [SGW94]. Provee un marco de trabajo completo para desarrollar software orientado por objetos de tiempo real, utilizando algunos de los modelos planteados en UML (Unified Modeling Language) para aplicar el paradigma de objetos al mundo de los sistemas de tiempo real. Por ello, en este punto se incluye una explicación breve de UML, ya que éste se utiliza no solamente en ROOM, sino también en otros métodos y metodologías. UML (Unified Modeling Language). “Es un lenguaje para especificar, visualizar, construir y documentar artefactos de sistemas de software. Representa una colección de las mejores prácticas de ingeniería que han sido probadas exitosamente en el modelado de grandes y complejos sistemas” [OMG99]. Es una notación estándar para el modelado de sistemas orientados a objeto aceptado por el OMG – Object Management Group [Mul97]. Como todo lenguaje de ese tipo está formado por elementos semánticos y elementos sintácticos, con la diferencia de que es un lenguaje gráfico que usa una variedad de elementos visuales para mostrar los elementos semánticos en una forma que es fácilmente aprovechable y manipulable por un modelador [Dou00]. Los elementos semánticos se refieren a aquella parte del lenguaje que tienen un significado subyacente, con valores, modos de operación y restricciones. Ejemplos de ello son las clases, los casos de uso y los estados. Los elementos sintácticos son los que permiten representar los semánticos. El conjunto de todos los elementos semánticos de un modelo se denomina el modelo.

CommonKADS-RT – Capítulo 2. Estado del Arte

65

En UML se pueden observar tres tipos diferentes de modelos [Dou00]: •

•

•

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

La perspectiva de UML está basada en una arquitectura de modelos y vistas, en donde lo fundamental es cómo se definen esos modelos y lo siguiente es cómo ellos se muestran gráficamente. UML propone la utilización de las máquinas de estado finito (statecharts [Har87]) para los modelos de comportamiento que definen la actuación de los objetos, y los diagramas de interacción que representan la conducta de diversos objetos colaborando en conjunto. Estos últimos pueden ser diagramas de colaboración que resaltan el envío de mensajes durante la actividad de colaboración o diagramas de secuencia que representan la sucesión temporal de los mensajes. En el siguiente método que se presenta, RT-UML, se explicarán algunos de los diagramas utilizados.

Entonces, ROOM utiliza muchos de los componentes que propone UML para el modelado de las características del sistema. Pero, quizá lo importante de ROOM es que está basado en el principio que se debe emplear un único modelo para todas las fases del proceso de desarrollo de software (Análisis, Diseño e Implementación), lo que facilita el desarrollar un STR. Además, esboza una notación simple y elegante para describir un sistema o una aplicación. El planteamiento que se propone es hacer un modelo operacional del sistema que luego debe ser refinado hasta llegar a su implantación, utilizando el concepto de modelos ejecutables como medio principal. Dichos modelos tienen una serie de vistas de estructura y de comportamiento que son compiladas y ejecutadas. Para ROOM, el software de tiempo real se describe como una red de colaboración de máquinas de estado finito, llamadas actores, que reflejan el comportamiento del sistema (son la estructura primaria y están encapsulados) y se comunican por medio del intercambio de mensajes a través de sus interfaces o puertos. El modelo de comportamiento de la máquina de estado finito establece que solamente una transición a la vez puede ser ejecutada por cada actor y que éste permanece inactivo

CommonKADS-RT – Capítulo 2. Estado del Arte

66

hasta que le llega un mensaje que le indica que un evento ha ocurrido [Sel92], [Sel96a] y [Sel96b]. El ciclo de vida del sistema está conformado por la especificación de los requerimientos del usuario, una etapa de diseño en la que se realiza un modelo de la solución, una etapa de simulación que se lleva a cabo empleando una herramienta (ObjectTime) y una etapa de pruebas sobre los resultados de la etapa anterior. Ver Figura 2-13. Si después de la simulación no se obtienen los resultados deseados, es necesario repetir la simulación una vez hechas las modificaciones pertinentes hasta cumplir con los objetivos, siendo así similar al desarrollo por prototipos. Para el diseño se utiliza la descomposición para refinar gradualmente la estructura interna y el comportamiento de un actor y la agregación para crear objetos anidados complejos. Hay una notación de escenarios para describir el comportamiento del sistema, en donde un escenario puede ser representado mediante una tabla de secuencia de mensajes que permiten verificar en un momento dado la secuencia operacional y la creación de escenarios posibles dentro de un proceso. Según [SFR98], aunque estos escenarios permiten indicar los requisitos temporales no son muy apropiados para ello porque no muestran realmente su comportamiento.

Especificación de los requerimientos

Modelado de la solución

Desarrollo de una simulación

Implementación

Figura 2-13 Procesos fundamentales del desarrollo con ROOM La plataforma de ejecución es típicamente el simulador ObjectTime, es una herramienta comercial que soporta la creación, validación y administración de los modelos de ROOM y su transformación en modelos ejecutables. En [BoG98] se puede apreciar una aplicación utilizando ROOM. ROOM tiene una serie de ventajas que la hacen muy poderosa para modelar el comportamiento complejo que puede llegar a tener un sistema de tiempo real:

CommonKADS-RT – Capítulo 2. Estado del Arte

67

−

Es orientada por objetos, lo cual permite explotar todas las fortalezas de ese paradigma.

−

Tiene conceptos de modelado específicos para el dominio de tiempo real, que facilitan la construcción de modelos de estos sistemas.

−

Permite hacer la definición de arquitecturas de alto nivel tanto de comunicación como de captura, facilitando la detección inicial de los requerimientos o del diseño.

−

Ofrece la captura explícita y la documentación de las arquitecturas del sistema y cuenta con un alto potencial para la reusabilidad, en la etapa de implementación por parte de los lenguajes de programación [Sel92].

−

Permite manejar actores dinámicos que reflejan los cambios que deben sufrir los sistemas empotrados de tiempo real para poder responder rápidamente a cualquier cambio del entorno.

La deficiencia que presenta se debe a que no hace énfasis en el análisis de la solución, no incluye aspectos relacionados con la viabilidad de la solución y le faltan herramientas para el modelado del tiempo. Por ejemplo, no habla sobre cuestiones relacionadas con el sistema en tiempo real ni de la selección del lenguaje de desarrollo, siendo este aspecto clave para la construcción efectiva del STR. Tampoco plantea técnicas para hacer el diseño de las pruebas y la elección de equipo de verificación y desarrollo [Lap92]. •

METODOLOGÍA RT-UML Como este enfoque es fundamental en la propuesta metodológica de CommonKADS-TR se trata en forma más detallada que las demás, en la sección 2.3.4.

2.3.3.4

Métodos basados en otros paradigmas

Existen otras alternativas para el desarrollo de STR que son muy abiertas y que toman algunos de los conceptos que son más comunes en ingeniería de software y los aplican. Entre ellas están MCSE y DARTS: • METODOLOGÍA MCSE MCSE (Méthodologie de Conception des Systèmes Electroniques) o (Embedded Systems CoDesign Methodology). Está orientada al desarrollo de sistemas de control de tiempo real y tiene gran aplicación en el ámbito industrial. Cubre las fases de especificación, diseño funcional (diseño preliminar), definición de la implementación (diseño detallado) e implementación final del sistema [Cal97]. Fue desarrollada en la Universidad de Nantes, Francia. Gráficamente, MCSE se puede ver en la Figura 2-14.

CommonKADS-RT – Capítulo 2. Estado del Arte

68

MCSE está basada en la idea que cualquier sistema puede ser observado por medio de tres vistas, en donde cada una de ellas explica un aspecto específico y adiciona información para describir el cómo del sistema: −

Una vista funcional que caracteriza las funciones internas del sistema.

−

Una vista temporal que describe el comportamiento de las funciones internas, expresando la contribución de cada una.

−

Una vista del hardware o de los recursos que distinguen la parte física del sistema. También, en MCSE se propone un modelo compuesto por 3 dimensiones:

−

La dimensión de la estructura funcional.

−

La dimensión del comportamiento que usa modelos temporales para describir el comportamiento de los componentes funcionales.

−

La dimensión ejecutiva descrita por una estructura que expresa los componentes hardware y las interconexiones necesarias para la operación del sistema.

Necesidad

CONFORMIDAD

Producto

Especificación

Validación VALIDACIÓN

Aceptación

Especificación

VERIFICACIÓN Diseño

Validación

Implementación

Diseño Funcional Integración

Especificación implementación

PRUEBA Implementación hardware

Implementación software

Figura 2-14 MCSE

El proceso de desarrollo del sistema que se sigue en este método es el siguiente:

CommonKADS-RT – Capítulo 2. Estado del Arte

69

1) Se hace la especificación completa del sistema que incluye su descripción funcional, el análisis del entorno, el comportamiento de las entidades, la definición de entradas y salidas, la especificación operacional y las especificaciones tecnológicas. 2) El diseño funcional basado en modelos que sugieren las funciones internas y el acoplamiento específico entre dichas funciones, logrando que el diseñador se concentre en los detalles más específicos del problema. 3) La definición de la implementación del software y del hardware. 4) La implementación final que es un documento completo en el que se tiene la definición del hardware en una forma de estructura ejecutiva y la definición de la implementación del software para todos los procesadores programables. Después se hace una integración y pruebas para combinar todas las partes del desarrollo. Entre sus ventajas se tiene: −

Es un método no restringido a un campo de acción específico.

−

El diseñador tiene la posibilidad de seleccionar el método con el cual desea ejecutar un paso.

−

Posee modelos para describir especificaciones y soluciones.

−

Tiene un esquema que facilita el control de las diferentes etapas de desarrollo de un proyecto y presenta casos de estudio que pueden ser empleados por los usuarios como una guía para la implementación de sus proyectos.

Quizá su única desventaja es que aún no se considera como un estándar para el desarrollo de STR y falta que se le conozca más.

• METODOLOGÍA DARTS DARTS (Design Approach for Real-Time Systems). Se fundamenta en la descomposición del STR en tareas concurrentes y en la forma en que estas tareas se comunican [Gom89]. Se puede ver como una extensión de los métodos de análisis y diseño estructurado que permiten un enfoque para estructurar el sistema en tareas y un mecanismo para definir las interfaces entre éstas. Fue desarrollada en el Instituto de Ingeniería del Software de Carnegie Mellon, Estados Unidos. Provee una serie de guías que siguen los principios de la descomposición y plantea los pasos que permiten que el constructor del sistema pase de la especificación del análisis estructurado de tiempo real a un diseño formado por tareas concurrentes. Los pasos son: −

Hacer el análisis de flujo de datos para poder determinar las principales funciones del sistema, sus subsistemas y componentes.

CommonKADS-RT – Capítulo 2. Estado del Arte

70

−

Identificar las tareas concurrentes por medio de unos criterios que permiten determinar si un proceso debe hacerse como una sola tarea o como una agrupación de ellas representadas como programas secuenciales. Estos criterios son un conjunto de heurísticas derivadas de la experiencia obtenida en el diseño de sistemas concurrentes.

−

Establecer las interfaces entre las tareas, definidas en dos clases de módulos: Uno para la comunicación de las tareas y otro para su sincronización.

−

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

La especificación del tiempo de cada tarea se hace en el análisis estructurado de tiempo real. Se usan diagramas de secuencia de eventos para mostrar la secuencia de las tareas ejecutadas desde la entrada externa hasta la respuesta del sistema. Según [Gom89] algunas de las ventajas que ofrece DARTS son: −

Proporciona unos parámetros que facilitan el establecimiento de las interfaces entre las tareas, lo que le simplifica al diseñador la elaboración del diseño para que sea más entendible.

−

Provee una transición de las especificaciones del análisis estructurado de tiempo real para el diseño de STR, y ya que este método de análisis es muy conocido y usado, entonces se puede pasar fácilmente del análisis estructurado de tiempo real hacia el diseño de tareas concurrentes.

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

2.3.4

Metodología RT-UML

RT-UML (Real-Time - Unified Modeling Language) [Dou98], [Dou99] plantea la ampliación del lenguaje UML para poder hacer el modelado de las características de tiempo real, permitiendo hacer el análisis y el diseño orientado a objetos para sistemas de tiempo real crítico utilizando UML para modelar tareas de tiempo real, incluyendo los requisitos

CommonKADS-RT – Capítulo 2. Estado del Arte

71

temporales que ellas pueden involucrar. Fue elaborado conjuntamente por ObjectTime Limited (creadores de ROOM) y Rational Corporation (creadores de UML).

2.3.4.1

Características de RT-UML

La metodología utiliza UML para componer diferentes tipos de modelos: los de requerimientos, los estructurales y los de comportamiento, cada uno con sus propios elementos semánticos y visuales. Para el modelo de requerimientos se utilizan los casos de uso, que son una colección de posibles secuencias de interacciones entre el sistema y sus actores externos, relacionados con un objetivo en particular [Hil99]. Para el modelo estructural, se propone hacer una división de dos aspectos diferentes: •

La estructura lógica del sistema que refleja las relaciones inherentes entre los elementos semánticos que tienen que ser verdaderos durante todo el desarrollo del sistema y que UML lo modela como asociaciones entre clases, y

•

La estructura física, que define las piezas físicas del sistema y la forma como ellas se relacionan con los elementos lógicos.

Esta metodología tiene grandes fortalezas y una de ellas es el planteamiento en la parte del diseño de una arquitectura del sistema, tanto física como lógica, que permite modelar tareas concurrentes, hilos de ejecución, plantear patrones y mostrar su reutilización. Además, considera diferentes técnicas para modelar el STR. Por ejemplo, ofrece los casos de uso y escenarios para modelar la comunicación entre los diferentes agentes del sistema; Los diagramas de estado para modelar el comportamiento de los objetos; Los diagramas de secuencia para modelar las restricciones temporales en el envío de mensajes; La representación de las tareas y su sincronización; Los modelos de la topología física del sistema y los modelos de organización del código fuente. Admite también, realizar una vista global de la solución a través de un diagrama de contexto que captura el entorno del sistema, que incluye los actores que participan en el mismo, y que deja caracterizar los mensajes y eventos que hay entre el sistema y su entorno. Así, si el sistema es un objeto y hay otros objetos agentes interactuando con él, se ve reflejado en el diagrama de contexto. Junto con RT-UML se ha propuesto un ciclo de desarrollo iterativo basado en riesgos, llamado ROPES (Rapid Object-Oriented Process for Embedded Systems) que usa el meta modelo de UML estándar para su marco de trabajo semántico y de notación. Este proceso de desarrollo se enmarca en un prototipo organizado alrededor de los casos de uso del sistema. La idea central es mantener la corrección y disminuir el riesgo a través de un análisis en dos dimensiones, la del tiempo y la de los componentes del proceso: La dimensión del tiempo envuelve las siguientes fases:

CommonKADS-RT – Capítulo 2. Estado del Arte

72

•

Inicio, en donde se define el problema a resolver, se enumera las entidades con las que el sistema interactuará (actores), la forma en que lo harán (casos de uso) y se analiza si es viable realizar el proyecto y si ésta es la mejor forma de implementarlo.

•

Elaboración, en donde se busca establecer los objetos, las clases y sus relaciones. Se definen los fundamentos de la arquitectura estructura del sistema y se desarrolla un plan del proyecto para establecer las iteraciones en la fase de construcción.

•

Construcción, para hacer o elaborar el software.

•

Transición, para entregarle a los usuarios una versión de prueba del producto para su evaluación.

Una vez se han hecho los cambios pertinentes se hace la entrega del producto y se da la capacitación necesaria. La dimensión de los componentes de los procesos incluye las siguientes actividades: •

Análisis de requerimientos para establecer lo que debe hacer el sistema.

•

Diseño, cómo el sistema será desarrollado en la implementación.

•

Implementación, es la generación del código para el sistema ejecutable.

•

Pruebas, para verificar el funcionamiento correcto de todo el sistema.

Es importante resaltar que en cada fase de la dimensión del tiempo se aplican las actividades de la dimensión de los componentes del proceso. A continuación se presentan las características más importantes de los diagramas que ofrece UML para modelar un sistema de información computarizado.

2.3.4.2 •

Diagramas de UML

Los diagramas de clase representan la estructura estática del modelo, en particular, las cosas que existen (tales como clases y tipos), su estructura interna, y sus relaciones con las cosas. Estos diagramas no muestran la información temporal. Una clase es un descriptor de una serie de objetos con estructura, comportamiento y relaciones similares. Entonces, la clase representa un concepto dentro del sistema que está siendo modelado, a través de la estructura de los datos (atributos) y el comportamiento y las relaciones con los otros elementos. Las relaciones que se pueden establecer entre varias clases son: la asociación (n-aria, binaria), la agregación (parte de), generalización (es-un), dependencia, (instanciade).

CommonKADS-RT – Capítulo 2. Estado del Arte

73

•

Los diagramas de objetos que son unos grafos de instancias, incluyendo objetos y valores de los datos. Este diagrama es instancia del de clases, y muestran el estado detallado del sistema en un momento del tiempo.

•

El diagrama de los casos de uso es un grafo de actores, una serie de casos de uso, posiblemente algunas interfaces y las relaciones entre esos elementos. Estos representan la funcionalidad de un sistema como manifestación de entidades externas que interaccionan con él. Se usan para definir el comportamiento de un sistema sin especificar su estructura interna.

Catálogo de Teléfonos Validación del estado Vendedor

Cliente

Poner orden

Llenar orden

Empleado de transporte

Figura 2-15 Ejemplo de un gráfico de casos de uso

El actor define una serie coherente de roles que los usuarios del sistema pueden jugar cuando interactúan con él. Los casos de uso especifican una secuencia de acciones que el sistema puede ejecutar, interactuando con los actores. Las relaciones son asociaciones entre los actores y los casos de uso, generalización entre actores, y generalizaciones, extensiones e inclusión entre los casos de uso. Un ejemplo de un gráfico de este estilo es el que se presentó en la Figura 2-15. •

Los diagramas de secuencia, muestran la secuencia explícita de estímulos organizada en una secuencia de tiempo. En particular, muestra las instancias participando en la interacción por sus líneas de vida y el estímulo que ellos intercambian en una secuencia de tiempo. No muestra las asociaciones entre objetos, pero si reflejan el tiempo. Una colaboración se define como una serie de participantes y relaciones que son significativas para una serie de propósitos dados. Una interacción especifica una secuencia de comunicaciones; contiene una colección de mensajes parcialmente ordenados que especifican una comunicación entre un rol que envía – emisor - y otro que recibe – receptor -. Un estímulo es una comunicación entre dos objetos que transmiten información con la esperanza de que una acción tenga lugar, así que un estímulo provocará que una operación se realice u ocurra una señal o que se cree o

CommonKADS-RT – Capítulo 2. Estado del Arte

74

destruya algún objeto. Un mensaje es una especificación de un estímulo, es decir, de los roles del emisor y del receptor, la acción que ocurrirá y cuándo se ejecutará.

llamador

intercambio

receptor

a: levantar auricular b: escuchar tono

< 10 seg.

c: marcar dígito d: enruta

tono sonando

suena el teléfono contesta llamada

tono para

para de sonar

< 1 seg.

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.

CommonKADS-RT – Capítulo 2. Estado del Arte

75

Un evento es una ocurrencia de interés. Para propósitos prácticos en el diagrama de estados, es una ocurrencia que puede disparar una transición de estado. Hay diferentes tipos de eventos y de transiciones, pero para efectos de esta tesis no se incluyen en esta memoria. Para más información ver [OMG99].

Timeout OK/mostrar mensaje después (15 seg) TonoDial

después (15 seg)

marcar dígito(n) [incompleto]

marcar dígito(n)

Marcando

OK/poner tono

Figura 2-17 Apartes de un Diagrama de Estados para un sistema telefónico •

Diagramas de actividad. Son una variación de las máquinas de estado en donde los estados se representan por la ejecución de acciones o subactividades y las transiciones son disparadas por la terminación de las acciones o subactividades. El propósito de estos diagramas es enfocar la conducción de los flujos por el procesamiento interno (opuesto a los eventos externos). Estos diagramas permiten representar decisiones, actividades concurrentes, actividades en diferentes unidades, entre otras cosas. Ver el ejemplo que se presenta en la Figura 2-18.

Calcular costo total

[costo=50]

Obtener autorización

Figura 2-18 Apartes de un diagrama de actividades Los diagramas de interacción junto con los de actividad y de transición de estados se conocen como Diagramas de Comportamiento. También hay unos diagramas que se llaman de Implementación ya que presentan aspectos relacionados con la estructura del código fuente y la estructura de implementación en tiempo de ejecución. Estos diagramas son: el de componentes y el de despliegue, que a continuación se amplían.

CommonKADS-RT – Capítulo 2. Estado del Arte

•

76

Los Diagrama de componentes presentan la estructura del código mismo, las dependencias de los componentes de software, incluyendo los componentes del código fuente, los componentes del código binario y los componentes ejecutables. Como todos los diagramas de UML, éste también es un grafo de componentes conectados por relaciones, que en este caso son de dependencia. En la Figura 2-19 se presenta un ejemplo de un diagrama de este tipo.

Scheduler

Asignación

Planificador

Actualización

GUI

Figura 2-19 Diagrama de Componentes •

Los Diagramas de despliegue presentan la estructura del sistema en tiempo de ejecución, es decir los elementos de procesamiento en tiempo de ejecución y los componentes del software, procesos y objetos. En estos diagramas no aparecen los componentes que no existen en tiempo de ejecución porque son de compilación. Las relaciones entre los nodos son dadas por asociaciones de comunicación. Siguiendo con el ejemplo presentado en la figura anterior, a continuación ( ver Figura 2-20 ) se muestra un posible diagrama de despliegue para esa situación.

AdminServer:HostMachine BDreuniones

:Scheduler

Asignaciones

Figura 2-20 Apartes de un diagrama de despliegue en UML

CommonKADS-RT – Capítulo 2. Estado del Arte

2.3.5

77

Ventajas y desventajas de RT-UML

• Ventajas o Fortalezas de RT-UML RT-UML tiene grandes ventajas cuando se compara con los otros métodos: −

A diferencia de ROOM que aplica el UML estándar con limitaciones para los sistemas de tiempo real (por ejemplo el no tener un buen soporte del análisis riguroso de tiempos y de los límites de tiempo), RT-UML hizo la ampliación del lenguaje orientado a los sistemas de tiempo real.

−

Aunque se ha creado con el propósito de desarrollar sistemas de tiempo real críticos, es posible aplicarla a otro tipo de STR, ya que permite modelar todas sus características.

−

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

−

Da la posibilidad de tener una alta reusabilidad al trabajar en su etapa de elaboración con objetos y clases.

−

Ofrece criterios para evitar hacer un mal uso de los diferentes diagramas de UML y otros para su utilización, lo cual es una buena guía para el constructor del sistema, en especial para aquellos que no tienen mucha experiencia en la utilización del lenguaje de modelado.

−

Ha sido probada en proyectos de gran envergadura.

−

Ha sido adoptada por los pioneros del paradigma de objetos y de UML, lo que da ciertas garantías.

• Desventajas o Debilidades de RT-UML En general esta metodología cubre muchos de los aspectos que se necesitan para llegar a buen término un proyecto de desarrollo de un STR, desde el estudio del problema hasta la implantación del software. Pero, presenta algunos aspectos negativos relacionados con la gestión del proyecto. Esto por varias razones:

CommonKADS-RT – Capítulo 2. Estado del Arte

78

−

La metodología no plantea criterios específicos para construir un sistema de tiempo real. Es decir, que no propone pautas que permitan seguirse para determinar si ante una situación específica es posible construir un STR como parte de su solución.

−

La fase de análisis está completamente orientada a la solución, es decir, al análisis de un sistema de tiempo real. Esto es negativo porque no se consideran otras posibles alternativas de solución.

−

Es una metodología que requiere tener muy buenos conocimientos de UML, lo que dificulta su aplicabilidad, pues en general los desarrolladores de los STR no tienen mucha experiencia en los lenguajes de modelado ni en metodología de análisis y diseño de software.

−

No hay muchas fuentes de información, a no ser que sean de UML.

−

Las fuentes de información no presentan ningún caso o ejemplo completo de la aplicación de la metodología que pueda ser utilizado como guía. Hay muchos ejemplos pero parciales.

Pero, a pesar de lo anterior y dado las fortalezas que ofrece RT-UML, se ha elegido como la más importante y actual para la construcción de STR.

CommonKADS-RT – Capítulo 2. Estado del Arte

2.4

79

Sistemas basados en el conocimiento de tiempo real

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

2.4.1

Generalidades de los sistemas basados en el conocimiento de tiempo real

La inteligencia artificial de tiempo real se basa en el razonamiento acerca de procesos que están limitados por el tiempo y en donde se usa el conocimiento heurístico para controlarlos y programarlos [Sta92]. En los últimos años se ha demostrado que es importante la combinación de teorías o áreas informáticas como por ejemplo, la de los sistemas de tiempo real y la de la inteligencia artificial porque así se pueden aprovechar los productos o resultados de las investigaciones realizadas en cada una de ellas para generar sistemas más capaces y poderosos en el razonamiento en el momento exacto. De esta forma, los sistemas de tiempo real requieren garantías en el uso de los recursos, tales como el tiempo, la memoria o el procesador. Las tareas que realizan en términos generales, son repetitivas y reflejan métodos procedurales, con tiempos de ejecución y patrones de llegada definidos, asegurando los tiempos de respuesta establecidos. Su objetivo es producir un resultado en el momento apropiado. Pero, cuando se aumenta la complejidad de los problemas que pretenden ser solucionados por ellos, es necesario plantear la aplicación de otras técnicas y métodos como por ejemplo los de la IA. La inteligencia artificial, se ha encargado de buscar técnicas para trabajar en entornos variables e incompletamente especificados que requieren de una gran cantidad de adaptación, creando modelos de computación que imitan la habilidad de los humanos para trabajar con autonomía en ese tipo de entornos. Pero, no se ha preocupado si el entorno impone restricciones en cuanto al tiempo para realizar sus tareas ya que está más interesada en crear soluciones de calidad. Es decir, hacer sistemas diseñados para hacer las cosas correctas. En general, no ha tenido en cuenta las restricciones o limitaciones de los recursos físicos. El problema se presenta cuando se necesita que se integre el sistema al mundo real, en donde las restricciones temporales se vuelven parte importante para el razonamiento del sistema. Por todo lo anterior, se pensó en crear sistemas que tuvieran las cualidades de los sistemas de IA y un comportamiento apropiado para ser utilizado en entornos típicos de TR- sistemas predecibles temporalmente -, como se explica en [VHB97]. Se afirma entonces, que “los métodos de inteligencia artificial se están moviendo hacia dominios más

CommonKADS-RT – Capítulo 2. Estado del Arte

80

realistas que requieren de respuestas de tiempo real, y que los sistemas de tiempo real se están moviendo hacia aplicaciones más complejas que requieren comportamiento inteligente” [MHD+95]. Por lo tanto, si se fusiona apropiadamente un STR con uno de IA se debe obtener un sistema que hace las cosas correctas en el momento oportuno. Desde el punto de vista de Musliner [Mus93] es "hacer la mejor elección con base en los recursos y el conocimiento limitado que el sistema tiene". En [MHA94] se presenta un ejemplo muy claro y conciso sobre lo que es un sistema que refleja ese comportamiento: "El vehículo que la NASA desarrolló para moverse en Marte, tiene que operar a una distancia aproximada de 15 minutos luz de la Tierra y por lo tanto no puede ser tele-operado. Este sistema tiene que operar continua y autónomamente en un ambiente incierto y no completamente especificado; tiene que detectar y reaccionar en el momento oportuno a situaciones imprevisibles pero peligrosas tales como obstrucciones en las rutas de navegación o terrenos peligrosos que incluso no pueden ser detectados por los sensores. Esta situación requiere que el sistema tenga procesos de adaptación y de razonamiento que no son comunes en los sistemas tradicionales de tiempo real. Afortunadamente, estos temas han sido tratados en diferentes áreas de la Inteligencia Artificial". Desgraciadamente, muchas técnicas de IA se caracterizan porque no son predecibles o tienen una variación muy alta de su rendimiento, haciendo que sea muy difícil que se garantice su ejecución para sistemas de control de tiempo real. Muchas de las investigaciones en esta área se enfocan en restringir las técnicas de IA para que sean más predecibles, proponiendo arquitecturas apropiadas para sistemas inteligentes de tiempo real. Entre ellas se encuentran: CIRCA (Cooperative Intelligent Real-time Control Architecture) [Mus93], [MHD+95]; AIS (Adaptative Intelligent Systems) [Hay90], [Hay95]; Phoenix [HHC90]; REAKT [Rea90], [Rea93], [KeM94]; ARTIS [GaB95], [GCB95], [Gar96], [CJG+97]. También, se ha trabajado alrededor de los diferentes sistemas que se pueden generar al relacionar los sistemas de tiempo real y las técnicas de IA. [MHD+95], [Viv98], [Gar96] y [Ona97] tratan ampliamente las tres formas básicas: •

A través de las técnicas de IA empotradas en un sistema de tiempo real. Se trata de incluir los métodos de inteligencia artificial dentro de un sistema tradicional de tiempo real, forzando las computaciones de IA para que cumplan con unos deadlines, de la misma forma como lo hacen las tareas de tiempo real. Por lo tanto, el propósito es “ser inteligente bajo tiempo real”.

•

“La integración de tareas de tiempo real en el sistema de IA. El sistema se comporta como un sistema inteligente convencional, pero cuando se produce un evento que requiere una respuesta de tiempo real, las tareas inteligentes son inhibidas para ejecutar una tarea de tiempo real” [Viv98]. Ejemplo de estos sistemas son SOAR [RLN+91] y PRS [IGR92].

•

El acoplamiento entre un sistema de IA y uno de tiempo real como componentes paralelos que trabajan en forma colaborativa, en donde cada uno tiene su propio comportamiento y entre los dos cooperan para obtener un resultado deseado. Con

CommonKADS-RT – Capítulo 2. Estado del Arte

81

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

2.4.2

Tipos de sistemas basados en el conocimiento de tiempo real

Como ya se había dicho, los sistemas basados en el conocimiento se pueden ver como un área específica de la inteligencia artificial. Los sistemas que allí se construyen básicamente se reconocen porque son para un dominio específico y tienen el conocimiento separado del razonamiento para solucionar problemas de una forma similar a como lo haría un experto en dicho dominio. La capacidad para garantizar una respuesta en un tiempo fijo, dado por el estado del problema es la principal característica que tienen que cumplir el SBCTR y debe ser aplicado a dominios en donde los problemas sean dependientes del tiempo, tales como el control de procesos, la monitorización, el diagnóstico y mantenimiento de fallos, la planificación reactiva, entre otras [BBO+93]. Tradicionalmente los SBC no manejan restricciones temporales ni en su conocimiento ni en su razonamiento, lo cual puede ser necesario dependiendo de si se requiere que el sistema reaccione a eventos del entorno como ocurre en los STR. Pero, como ya se ha dicho, el dominio de problemas de tiempo real es muy diferente de aquellos en los que tradicionalmente se han aplicado los SBC porque las técnicas de solución de problemas basadas en conocimientos han sido utilizadas en situaciones en donde los datos son estáticos y no se requieren respuestas con tiempos críticos [LCS+88], [Laf91]. Las formas presentadas en la sección anterior, implican de por sí definir unas características muy propias tanto para el sistema resultante como para las técnicas o métodos utilizados para su desarrollo, por lo que a continuación se presenta cada una de ellas para el caso de que el sistema inteligente sea un sistema basado en el conocimiento, creándose entonces tres tipos de sistemas basados en el conocimiento de tiempo real. • Sistema de tiempo real que tiene algunas tareas basadas en el conocimiento En este caso, el STR mantiene el comportamiento temporal, pero algunas de las tareas que debe realizar son SBC. Así, la planificación del sistema incluye la realización de unas tareas basadas en heurísticas o en técnicas propias de la ingeniería del conocimiento y los algoritmos de búsqueda y de control del motor de inferencia deben estar acotados para realizar su función. El asunto importante en este tipo de sistemas es cómo garantizar la ejecución del SBC y cómo hacer que cumpla con los tiempos asociados.

CommonKADS-RT – Capítulo 2. Estado del Arte

82

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

2.4.3

Aplicaciones reconocidas de los sistemas basados en el conocimiento de tiempo real

Para hablar de la aplicación de los SBCTR no se hará referencia a algún tipo en especial sino a todos en general. Se han planteado muchos sistemas informáticos o herramientas de desarrollo que combinan las dos tecnologías en diferentes formas [MiG92], [VHB98]. Hay muchos campos de utilidad de los SBCTR, pero en especial se han destacado en el aerospacial, las comunicaciones, la medicina, el control de procesos y sistemas robóticos, entre otros. A continuación se presentan algunos ejemplos de estos casos: •

Una de las áreas que busca encontrar soluciones inteligentes es la del monitorización de alarmas y el diagnóstico de fallos porque cada vez se están creando plantas más

CommonKADS-RT – Capítulo 2. Estado del Arte

83

complejas que requieren de la intervención de operadores en caso de fallo. Un primer caso es la reducción del número de alarmas, lo cual involucra realizar el análisis de la serie de indicadores de alarma que pueden ocurrir cuando un proceso tiene problemas. Esto aparentemente es una situación de monitorización de variables, pero cuando el proceso tiene problemas, un solo fallo puede resultar en una multitud de condiciones de error que dificultan la toma de decisiones del operador humano. Así, un sistema basado en el conocimiento puede investigar los patrones de los mensajes de alarmas, incluir sus secuencias de tiempo y examinar las relaciones causa – efecto bajo la óptica de la dinámica de la planta bajo control. Otro caso sería el tener un sistema para monitorizar de la planta y usando las medidas apropiadas de predicción, pueda prevenir las condiciones de las alarmas. [RVK92]. •

El sistema ESSOC (Expert System for Satellite Orbit Control) que fue diseñado para asistir en las maniobras de mantenimiento de estaciones de satélites (Delta V). A partir de datos de telemetría del satélite determina los comandos apropiados para ejecutar maniobras exitosas. Este sistema analiza los datos durante la rutina de chequeo del estado del satélite, diagnostica las causas de anomalías y recomienda comandos que las resuelven.

•

El sistema FLES (Flight Expert System) fue diseñado para asistir al piloto de un avión en las tareas de evaluación, análisis y diagnóstico de fallos en los sistemas de la nave. Este sistema está basado en el modelo blackboard de Hearsay, en donde se tienen fuentes de conocimiento que representan analizadores de interrupciones provocadas por los sensores. El sistema con base en esas entradas construye una serie de hipótesis sobre las posibles causas de las interrupciones, a través de un procedimiento de verificación confirma si un componente no está operando y unos procedimientos de diagnóstico determinan si el componente es la causa del fallo o es un efecto de algún otro problema [AlS85].

•

HANNIBAL es uno de los primeros sistema que se hicieron en el área de las comunicaciones. Su razonamiento está relacionado con la interpretación de datos obtenidos a través de sensores que observan las comunicaciones de radio, con el objetivo de identificar unidades enemigas y su comunicación en la batalla. Los datos que se reciben incluyen información acerca de la localización de las comunicaciones detectadas y las características de la señal. Este sistema, al igual que el anterior, está construido bajo el modelo de la arquitectura blackboard. A pesar de haber sido desarrollado hace tantos años, sigue siendo uno de los más representativos del área [BBE+82].

Como se puede ver, hay muchas aplicaciones de este tipo que reflejan el comportamiento de sistemas inteligentes de tiempo real. Pero, es importante resaltar que hay unos problemas que se presentan en este tipo de sistemas, provocados por lo siguiente: •

La adquisición del conocimiento del área de aplicación puede ser muy compleja porque para que el sistema obtenga buenas inferencia, hay que tener completa la estructura de las reglas del dominio, en una forma que sea aceptable, verificable y que soporte la suficiente información.

CommonKADS-RT – Capítulo 2. Estado del Arte

•

84

El cumplimiento de las restricciones temporales y de los planes de ejecución. Esto porque en un sistema basado en el conocimiento es muy difícil determinar qué es lo que el sistema hará exactamente, cómo y cuándo.

Para solucionar en parte estos problemas, se han propuesto entornos específicos de desarrollo de sistemas basados en el conocimiento de tiempo real. Es decir, arquitecturas que proporcionan las facilidades para que se cumplan con los requerimientos fundamentales del sistema. En esta investigación, este tema ha sido dejado de lado porque se pretende que la metodología CommonKADS-RT sea lo más independiente posible de la arquitectura o el entorno de desarrollo del sistema, aunque en ella se propone e introduce una arquitectura desarrollada en el mismo grupo de investigación. La forma como se construye e implanta el sistema es muy importante para solucionar o mejorar esos problemas, siendo las metodologías un tema muy importante de trabajo para lograr llevar el SBCTR a un entorno real. A continuación, se presenta la forma de desarrollo de éstos, es decir, el apartado de las metodologías, núcleo de esta investigación.

2.4.4

Metodologías para desarrollar sistemas basados en el conocimiento de tiempo real

Como los sistemas de toma de decisiones y los de control proliferan cada vez más, los resultados el incremento de los riesgos crecen proporcionalmente durante su operación. Nuevas tecnologías de toma de decisión en la medicina, la manufactura, el control de procesos industriales y el transporte están cada vez usando más las basadas en conocimientos. Pero, en el campo de los SBCTR no se han desarrollado muchas metodologías que permiten y faciliten la construcción de estos sistemas. Quizá los que han tenido mayor impacto, han sido RAM y RTCommonKADS, que a continuación se presentan.

2.4.4.1

Metodología RAM

RAM (REAKT Application Methodology). Esta metodología para construir sistemas basados en el conocimiento de tiempo real es uno de los productos de un proyecto ESPRITII de la Unión Europea. El objetivo principal del proyecto fue desarrollar una serie de herramientas y una metodología para aplicar los sistemas basados en el conocimiento en dominios de tiempo real. Se querían crear definiciones, especificaciones y prototipos de varias técnicas, para ser eventualmente integradas en un juego de herramientas para el desarrollo, la utilización y el mantenimiento eficiente de módulos basados en el conocimiento que pudieran ser empotrados en las aplicaciones de tiempo real [Rea90] y [Rea93]. El proyecto se basó en la proposición de una arquitectura para desarrollar sistemas basados en el conocimiento de tiempo real, REAKT (Environment and Methodology for Real-Time Knowledge-Based Systems) y en la construcción de la metodología RAM.

CommonKADS-RT – Capítulo 2. Estado del Arte

85

REAKT plantea tener múltiples agentes y como eje central un blackboard temporal. Se propone tener un sistema operativo de tiempo real, un administrador de datos de conocimiento y un servidor experto. Permite definir tareas periódicas, esporádicas o actuadoras (tareas especiales que tienen como función la comunicación con el mundo externo) [MKC+93], [ViB96]. RAM consiste de unas guías orientadas a la aplicación y de unas herramientas computerizadas. Toma como fundamento lo planteado en KADS (anterior a CommonKADS) y en OMT (Object Modeling Technique), adicionándole el soporte de la reutilización y de las características de tiempo real. El nivel de dominio se refleja a través de diferentes modelos: un modelo de objetos, uno dinámico, uno funcional y un modelo de redes causales. Este proyecto posibilitó la construcción de una serie de algoritmos y de técnicas para soportar el desarrollo de los SBCTR y tiene una gran importancia desde el punto de vista conceptual. REAKT ha sido utilizada como modelo en diferentes proyectos, como por ejemplo en ARTIS [Gar96]. Pero, desgraciadamente la metodología RAM no es muy conocida, no se encuentra información de ella, no es muy utilizada, es propiedad de algunas empresas y presenta algunos inconvenientes en relación con lo que se modela y lo que se construye.

2.4.4.2

Metodología RTCommonKADS

Es una extensión de CommonKADS para sistemas reactivos y EN Tiempo Real Basados en Conocimiento - STRBC [Pal99]. En ésta se propone la adición de componentes que permiten modelar algunas de las características de los sistemas de tiempo real: •

Las tareas reactivas que se ejecutan como respuesta a un evento que puede ser el resultado de alguna modificación del entorno o de alguna condición temporal que se haya definido con antelación.

•

El modelo continuo de operación que posibilita el no tener definida la finalización de la tarea.

•

El foco de atención que se define cuando el sistema puede dirigir su atención según el evento o la reacción que está atendiendo en un momento dado.

•

Tareas concurrentes que pueden ser ejecutadas al mismo tiempo, en forma paralela.

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

CommonKADS-RT – Capítulo 2. Estado del Arte

86

generada en un agente diferente del que procesa la tarea disparada, es decir, que hay una reacción externa. En esta propuesta se le adicionan algunos conceptos al modelo de experiencia. Entre estos, uno de los más importantes es reacción que refleja la conceptualización de una reacción en el sistema de tiempo real. Además, plantea las relaciones que se pueden tener con dicho concepto y tipos: al dominio o temporal. Todo esto se hizo en el lenguaje CML. También, en dicho modelo se han introducido nuevas sentencias de control que permiten la definición de tareas concurrentes y de un modo de operación. Esta metodología no plantea ningún cambio relacionado con el modelo de la organización, ya que considera que éste es independiente del sistema solución. Lo cual no es tan cierto, ya que los problemas en este modelo deben ser analizados precisamente desde la óptica de los sistemas basados en el conocimiento de tiempo real, pues como lo explican [SFD99] “Dentro del modelo de la organización se describe la estructura de la organización junto con una especificación de las funciones que son ejecutadas por cada unidad organizacional. Además, éste identifica las deficiencias de los procesos de negocios actuales y que posiblemente pueden ser mejorados a través de la introducción de un SBC”. Es así como en el modelo de la organización se especifica el dominio del problema, pero también se incluyen aspectos del dominio de la solución. En esta metodología no se hace la diferencia entre lo que es una tarea desde el punto de vista de un proceso de la organización y lo que es una tarea (thread) de tiempo real. Además, se confunde el concepto de tiempo real y en tiempo real, tal como se ha planteado en la sección 2.3.1 de sistemas de tiempo real. En ésta no se hace un tratamiento riguroso del tiempo, clave de los STR, pues no se plantea la inclusión de las características estrictas del manejo de las tareas de tiempo real, como el deadline, el período o el tiempo de ejecución en el peor de los casos. Por lo tanto, más bien se entiende como el manejo de la temporalidad en un sistema basado en el conocimiento.

2.5

Conclusiones del estado del arte

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

2.5.1

Conclusiones de sistemas basados en el conocimiento

Un proyecto de conocimiento tiene que ser manejado aprendiendo de la experiencia en una forma de espiral controlada. El desarrollo de simples o muy bien conocidos sistemas de información usualmente se hace a través de una ruta fija de administración. Esto es especialmente claro en los llamados modelos de cascada de desarrollo de sistemas, que consisten en un número de estados predefinido en una secuencia definida: preparar y planear el proyecto, investigar acerca de los requerimientos del cliente, especificar y diseñar el programa del sistema, probar y entregarlo, en este orden solamente. El

CommonKADS-RT – Capítulo 2. Estado del Arte

87

conocimiento es mucho más rico y más difícil de entender para que encaje en un enfoque tan rígido. El desarrollo por prototipos ha sido de esta forma muy popular en los sistemas de conocimiento porque le permiten aprender en el sitio y cambiar el curso cuando sea necesario, pero su inconveniente es su naturaleza ad hoc, difícil de predecir y manejar. Tradicionalmente, mucho del esfuerzo que hacían los ingenieros de información y de conocimientos estaba directamente relacionado con los aspectos técnicos del problema y de la solución. Ahora que la tecnología del conocimiento ha alcanzado un buen grado de madurez y de difusión, esto ya no es su objetivo principal. Muchos factores además del tecnológico, determinan el éxito o el fracaso de un sistema de conocimiento en la organización, pues éste no sólo tiene que ejecutar muy bien sus tareas de acuerdo con unos estándares fijados previamente, sino que tiene que ser aceptado por el usuario final y puede ser incorporado con otros sistemas de información y con la integración de las estructuras, procesos y sistemas de calidad de la organización como un todo. La experiencia práctica ha mostrado que a menudo los factores críticos de éxito para los sistemas de conocimiento son tan bien los puntos relevantes que en la organización han sido tratados. Muchos fallos en la automatización han resultado, no sólo de problemas con la tecnología sino también por no tener en cuenta factores sociales y organizacionales. Aún, muchas metodologías de desarrollo de sistemas se enfocan en los aspectos técnicos y no soportan el análisis de otro tipo de elementos relacionados con las personas, el entorno, la organización, la cultura y el poder, los cuales son determinantes para que el sistema tenga éxito o fracase como solución. La Metodología CommonKADS ofrece las herramientas para manejar todos estos aspectos.

2.5.2

Conclusiones de sistemas de tiempo real

Los sistemas de tiempo real tienen aplicación en muchas de las áreas del conocimiento pero debido a la poca formalización que se ha seguido en su desarrollo o a lo complejo de su presentación, o de los métodos utilizados, su divulgación y extensión no ha sido lo suficientemente amplia. Para construir sistemas más complejos, se ha trabajado con los métodos generales de Ingeniería de Software y algunas personas y empresas han propuesta otras, pero el problema es que no se han difundido y las grandes industrias que crean este tipo de sistemas, simplemente siguen su propio método ad hoc. Los métodos que se han presentando, son sólo una muestra de los muchos que existen para construir este tipo de sistemas, han sido elegidos por ser típicos, ampliamente utilizados y reconocidos, lo que garantiza en cierta forma su efectividad. Para más información ver por ejemplo [Lee92], [Ell94], [ShC94]. Estos métodos están orientados a las fases de diseño o a la de implementación: Los que resaltan la fase de diseño están más interesados en modelar el sistema usando conceptos concretos que se relacionan directamente con los componentes que lo integrarán. Los que enfatizan la fase de implementación se dedican a actividades de identificación del lenguaje de programación, de la plataforma hardware, de los protocolos de transferencia y de los de comunicación. Este último es quizá el más usado pues se trata de construir aplicaciones relativamente simples, sistemas poco complejo en cuanto a la lógica que se

CommonKADS-RT – Capítulo 2. Estado del Arte

88

sigue y muy crítico en el cumplimiento del tiempo. Entonces el proceso de construcción es muy particular: lo primero que se hace es establecer los requerimientos físicos (tiempos, frecuencias), luego se hace el diseño básico en un lenguaje de programación y posteriormente se implementa. Una vez se tiene el software, se miden los tiempos de ejecución en el hardware definitivo y se hace una prueba o la planificación off-line. Si el resultado no cumple con los tiempos entonces se regresa al diseño para hacer los ajustes respectivos. Pero, cuando lo que se quiere es construir una aplicación muy sólida y compleja, dirigida al sector industrial, estos métodos y metodologías no son apropiados pues es necesario que además incluyan la fase de análisis para hacer el modelado conceptual, es decir, un modelado del entorno del mundo real. Además, algunos se fundamentan en el enfoque tradicional de “cascada”, lo que dificulta la validación o comprobación de si el diseño es correcto o no, pues sólo se sabe hasta el final de todo el proceso. Es muy difícil explorar y validar diferentes alternativas de diseño, por lo que a veces se pueden producir productos que no son óptimos y que, además, son de baja calidad. Es importante resaltar que UML es solamente una Notación estándar (lenguaje de modelado) que no describe el proceso para utilizarla en el desarrollo de un sistema de software aplicable. Esto es precisamente lo que debe incluir una metodología, la descripción del proceso o del método con una lista de actividades para hacer, el orden en que éstas deberían ser hechas, los elementos producidos y entregables, las clases de herramientas o habilidades requeridas en cada una de las actividades. O sea, que la metodología formal consiste tanto de las notaciones como de uno o varios métodos. Es así como se presume que RT-UML puede ser el método a elegir.

2.5.3

Conclusiones de sistemas basados en el conocimiento de tiempo real

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

Adaptar arquitecturas de software a las operaciones de tiempo real

•

Modificar los algoritmos tradicionales de IA para mejorar su predecibilidad;

•

Modificar las políticas tradicionales de planificación de tiempo real para acomodar el uso de algoritmos más predecibles.

CommonKADS-RT – Capítulo 2. Estado del Arte

89

Las actividades de investigación han estado centradas en el desarrollo de herramientas para describir y operacionalizar sistemas inteligentes de tiempo real y en la realización de sistemas con el objetivo de estudiar la viabilidad de los diferentes enfoques. Todo esto ha permitido que se propongan y desarrollen nuevas arquitecturas que integran o combinan estos enfoques, logrando tener muy buenos resultados como REAKT, AIS, CIRCA, entre otros. Después de esto y siguiendo la evolución lógica de las investigaciones, han estado surgiendo algunos métodos y metodologías que permiten desarrollar en una forma estructurada y bien documentada, sistemas de software de este tipo. Esta situación es similar a los acontecimientos que se presentaron cuando ocurrió la crisis del software que permitió que surgiera la Ingeniería del Software, y a los que posibilitaron el nacimiento de la Ingeniería del Conocimiento. Por lo tanto, es posible que se esté empezando a dar la “Ingeniería del tiempo real inteligente”. Pero, como se puede observar, no hay muchas metodologías específicamente creadas para la construcción de SBCTR. Así, la importancia de RAM está dada por el hecho de tener en cuenta la filosofía de trabajo de los sistemas de tiempo real, pero no es muy utilizada por los problemas que se plantearon anteriormente y, RT-CommonKADS tiene una visión diferente de la que se plantea en esta investigación, pues se centra en el nivel de conocimiento, dejando de lado características asociadas a la implementación del SBCTR. Adicionalmente, ninguna de estas metodologías propone criterios para determinar cuándo es apropiado, conveniente y justificable construir un SBCTR como solución a una situación específica. Por todo esto, es necesario proponer una metodología que se ajuste más a los sistemas basados en el conocimiento de tiempo real, retomando algunas de las consideraciones planteadas en las metodologías existentes.

CommonKADS-RT – Capítulo 3. CommonKADS-RT

91

Capítulo 3. CommonKADS-RT 3.1

Introducción

La importancia de toda metodología es que posibilita el tener un proceso de producción de software más estructurado y controlado, facilitando el desarrollo del proyecto y su gestión, de forma tal que se alcancen tanto los objetivos como los productos definidos desde el comienzo. En este capítulo se presenta la metodología CommonKADS-RT para el desarrollo de un sistema basado en el conocimiento de tiempo real. Inicialmente se explicará la justificación y el fundamento de la metodología. Luego se introducirá el ciclo de vida para el desarrollo de un SBCTR. Por último, se describirá cada uno de los modelos que componen a CommonKADS-RT y los artefactos que se obtienen en su construcción.

3.2

Justificación de CommonKADS-RT

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

CommonKADS-RT – Capítulo 3. CommonKADS-RT

92

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

3.3

Fundamentos de CommonKADS-RT

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

3.3.1

Fortalezas y debilidades de CommonKADS para sistemas basados en el conocimiento de tiempo real

Como ya se ha mencionado en diversas secciones, especialmente en la 2.2.7 Ventajas y desventajas de CommonKADS - página 49, CommonKADS es una buena metodología para modelar sistemas inteligentes basados en el conocimiento. Integra algunos de los modelos de UML para complementar el modelado del SBC, pero carece de otros que permite modelar las restricciones temporales. Su propósito básico no es el de modelar sistemas de tiempo real. Aunque en algunas partes se habla del tiempo como una variable importante de considerar, no se amplía mucho este concepto y, por tanto, no se proponen ni métodos ni se ofrecen alternativas para establecer el análisis temporal o para definir las restricciones temporales. Por esto hay varios cambios que son necesarios hacer. Entre ellos está la modificación del lenguaje CML2 utilizado para definir el modelo de conocimientos, pues debe incluir las instrucciones necesarias que permitan definir el deadline de una tarea, determinar si ésta es crítica o si es periódica. Es decir, que ofrezca la posibilidad de incluir todas las condiciones de una tarea de tiempo real. Adicionalmente, y tal como se ha manifestado, la metodología CommonKADS gira alrededor del modelo de conocimiento y está pensada para desarrollar SBC que interactúan con un usuario humano, pero dado que un SBCTR está en comunicación permanente con su entorno, a través de periféricos o dispositivos especiales, y que por lo general estos sistemas son reactivos, entonces es necesario volver a definir algunos de los modelos existentes en la metodología y plantear incluso uno nuevo, denominado el modelo de tareas de tiempo real.

CommonKADS-RT – Capítulo 3. CommonKADS-RT

93

En este contexto, es importante determinar qué se entiende por tarea, dado que se trata de una noción relevante que tiene diferentes connotaciones: •

Como un concepto de sentido común, una tarea es una actividad humana para alcanzar algún propósito.

•

Para CommonKADS una tarea es una parte de un proceso de negocios que representa una actividad orientada a un objetivo, llevada a cabo por unos agentes que siguen unos criterios de calidad y desempeño. La tarea maneja entradas y entrega salidas deseables en una forma estructurada y controlada, consume recursos y requiere (y provee) conocimiento y otras habilidades.

•

Desde el punto de vista de los STR, una tarea se refiere a una especificación de bajo nivel de cada uno de los hilos de ejecución de un proceso.

Por tanto, en CommonKADS se trabaja en estadios más abstractos y no se plantea el llegar a ese nivel de detalle que se requiere en un SBCTR.

No obstante, CommonKADS sigue siendo la mejor alternativa para usarse como base en el desarrollo del SBCTR por las siguientes razones: •

Es una metodología consistente y robusta que integra los conceptos más importantes de la Ingeniería del Software y en especial de la Ingeniería del Conocimiento, siguiendo con el paradigma de objetos.

•

Incluye aspectos relacionados con la gestión del proyecto, permitiendo hacer un análisis muy completo de la organización, de sus problemas y de las diversas soluciones.

•

El considerar el análisis de riesgos, da la posibilidad de que se ejerza un control más oportuno y apropiado sobre las actividades de desarrollo.

•

Dado que esta metodología es un estándar para el desarrollo de SBC, que ha sido ampliamente utilizada y validada, da ciertas garantías para su utilización.

•

Es posible adecuarla para el desarrollo de otro tipo de sistemas informáticos, en especial de los SBCTR.

3.3.2

Fortalezas y debilidades de RT-UML para sistemas basados en el conocimiento de tiempo real

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

CommonKADS-RT – Capítulo 3. CommonKADS-RT

94

define en forma expresa las técnicas de adquisición, representación y manipulación del conocimiento. Adicionalmente, se puede decir que esta metodología es más de diseño que de análisis, aunque ese no es su propósito, pues pone mucho énfasis en las actividades, modelos y diagramas que se pueden utilizar para el diseño del STR, dejando de lado el análisis del problema. Se escogió UML para modelar las características de tiempo real, porque tiene una serie de modelos que se pueden aplicar para realizar el análisis de un sistema de tiempo real e incluso de un sistema basado en el conocimiento de tiempo real. La metodología que soporta más ampliamente UML es RT-UML para la parte de tiempo real, pero es necesario adicionarle otras herramientas que permitan modelar el conocimiento temporal. Así, CommonKADS-RT se basa en estas dos metodologías. CommonKADS para los componentes basados en el conocimiento y la gestión del proyecto, con algunas variaciones; en RT-UML para el modelado del tiempo y el tratamiento de los problemas de tiempo real, también con unos cambios. Adicionalmente, se han tenido en cuenta algunas técnicas de planificación estratégica y evaluación de proyectos, y las consideraciones propias fijadas por los sistemas basados en el conocimiento de tiempo real.

3.3.3

Descripción general de CommonKADS-RT

Tal como se dijo en el capítulo 1 de la introducción, en esta investigación se considera que una metodología de software debe indicar lo siguiente: •

Criterios para identificar si la mejor solución o al menos la más apropiada es un SBCTR. Ver anexo 1. Esto es un punto muy importante de la metodología CommonKADS-RT porque sirve de guía o de instructivo para la implementación de un SBCTR y hace parte de lo que es la viabilidad técnica del sistema.

•

Cuáles son las características más importante que debe tener el dominio para que sea apropiado utilizar esta metodología. Se plantearán en la siguiente sección – 3.4.

•

Cuáles son las actividades específicas que se deben realizar (etapas o fases). En el caso de CommonKADS-RT es la especificación de los diferentes modelos que se deben elaborar para integrar el SBCTR. Esto es lo que se amplía en la sección 3.6 Modelos que integran a CommonKADS-RT.

•

Cuál es el orden de realización de dichas actividades. Es decir, el ciclo de vida que sigue el SBCTR. Esto es lo que se trata en la sección 3.5 Ciclo de vida de CommonKADS-RT.

•

Cuáles son las herramientas, conocimientos y utilidades para realizar las actividades. Es decir, cómo se deben preparar los modelos de CommonKADS-RT. También se plantea en la sección 3.6.

95

CommonKADS-RT – Capítulo 3. CommonKADS-RT

•

Los roles y responsabilidades que se tienen tanto en el desarrollo de los modelos, como en el seguimiento o gestión del proyecto. Esto se especifica en los modelos que integran la metodología.

•

Los resultados, productos o artefactos que se obtienen en cada una de las etapas y modelos, se incluyen en la sección final de cada modelo de la metodología.

•

Los mecanismos que sirven de guía de decisión en cada una de las tareas. Es decir, la gestión del proyecto. Este tema se trata parcialmente en los modelos y el ciclo de vida, pero no se profundiza mucho.

A continuación se presenta el esbozo general de la propuesta y luego se detalla cada uno de los modelos que la componen. Ver Figura 3-1.

Modelo de la Organización Qué Quiénes

Modelo de Tareas de Alto Nivel

Modelo de Agentes

Qué saben Cómo se relacionan

Con qué Modelo de Conocimientos

Modelo de Comunicaciones

Base de conocimientos, restricciones temporales, Razonamiento interfaz Modelo del

Diseño Características de Hardware y Software Modelo de Tareas de Tiempo Real

Figura 3-1 Modelos de CommonKADS-RT

•

La idea básica es que el desarrollo de un Sistema Basado en el Conocimiento de Tiempo Real se ve como la construcción de un número de modelos que juntos constituyen parte del producto que se debe entregar en el proyecto y en donde el nivel de elaboración de los modelos depende de cada proyecto. Así mismo, en CommonKADS-RT se proponen una serie de formularios asociados a cada uno de

CommonKADS-RT – Capítulo 3. CommonKADS-RT

96

los modelos que deben ser configurados, refinados y rellenados durante el desarrollo del proyecto. •

Un proyecto que incluye el construir un SBCTR debe entregar como productos lo siguiente: −

Los formularios diligenciados,

−

La documentación relacionada con el SBCTR. Ésta complementa lo definido en los formularios, y

−

El software, o sea, el SBCTR.

•

Lo primero que se debe hacer es empezar con el modelo de la organización para identificar el problema y las soluciones alternativas. Para ello se toman como base los formularios de CommonKADS y se les hacen unos cambios relacionados específicamente con la introducción de herramientas de planificación estratégica y de los aspectos de los sistemas basados en el conocimiento de tiempo real. Se propone un nuevo formulario que permite separar el problema de la solución, se utiliza el diagrama de casos de uso para identificar claramente los agentes y actores involucrados en el problema seleccionado, se hace el diagrama de actividades para presentar los procesos y el flujo de control entre ellos. Una vez identificados los actores, se pueden detallar cada uno de los casos de uso para representar las funciones del sistema desde el punto de vista del usuario y los escenarios que son instancias de dichos casos de uso. También se pueden registran los eventos externos más relevantes para el sistema, tanto los que le entran por medio de un actor como los que éste produce y entrega. Se analiza el conocimiento que se maneja en el proceso de acuerdo con la clasificación de dato, información, habilidad o capacidad, o conocimiento propio del proceso mismo. Por último, se plantean las diferentes alternativas de solución con su justificación asociada.

•

Luego se comienza con el desarrollo del modelo de tareas de alto nivel, variación del modelo de tareas. Para esto además de utilizar los nuevos formularios, se debe construir un diagrama de flujo de la TAN seleccionada, un diagrama de conceptos (entidades o clases), la profundización del diagrama de actividades del modelo de la organización y los diagramas de estado de aquellos conceptos que lo requieran.

•

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

•

Después se plantea el modelo de conocimientos con la ayuda también de los formularios y de los diagramas de secuencia de conceptos, de colaboración y de actividades. En este modelo se definen las tareas de alto nivel de tiempo real que han sido identificadas a través del Lenguaje de Modelado de Conocimiento de

CommonKADS-RT – Capítulo 3. CommonKADS-RT

97

CommonKADS - CML con las adiciones de las características temporales. Es bueno utilizar los diagramas de transición de estados para analizar algunos de los conceptos que resulten de este punto. Se especifica el modelo de comunicaciones, utilizando de nuevo los formularios, los diagramas de secuencia y de colaboración. •

Luego se pasa el modelo de diseño, tal como se tiene en CommonKADS, adicionando el modelado de la arquitectura del SBCTR por medio de diagramas de componentes y determinando el diseño detallado de la estructura de la tarea de tiempo real, según dicha arquitectura. Para esto se utiliza RT-UML, ARTIS y otros métodos apropiados.

•

Por último, se definen las características de las tareas de tiempo real en el modelo de TTR para poder hacer el test off line de planificabilidad y comprobar si el sistema si lo cumple o no, para poderlo implantar.

Es importante aclarar que el hecho que se hayan definido estos puntos específicos, no quiere decir que se tengan que dar en ese orden, ya que algunos de los procesos de análisis se pueden hacer en forma paralela.

3.3.4

¿Por qué un modelo para las tareas de tiempo real?

Para todo SBCTR la información relacionada con las tareas de tiempo real, es tan relevante que merece la pena que sea tratada en forma detallada y que se tenga un modelo específico cuyo propósito final será el de modelar las tareas de tiempo real. Además, la información que se va a modelar será importante para las decisiones que se tengan que tomar en cuanto a aspectos de planificabilidad y predecibilidad del sistema. El modelo de TTR describe las tareas de tiempo real que serán ejecutadas en el SBCTR. Su alcance está dado por lo siguiente: •

Este modelo sólo contiene aquellas tareas que tienen restricciones temporales asociadas y que en conjunto deben ser analizadas para determinar la planificabilidad y predecibilidad del sistema.

•

Las tareas de tiempo real son descritas independiente del sistema operativo y de la plataforma hardware del mismo.

La función de este modelo en CommonKADS-RT es describir los hilos de ejecución que se necesitan en el sistema basado en el conocimiento de tiempo real, pero a un alto nivel de abstracción.

CommonKADS-RT – Capítulo 3. CommonKADS-RT

3.4

98

Características del dominio que es apropiado para la aplicación de CommonKADS-RT

Es importante plantear las particularidades que debe tener el campo en el cual se va a construir la aplicación de un SBCTR de acuerdo con CommonKADS-RT: •

Los sistemas basados en el conocimiento de tiempo real deben ser sistemas que se fundamenten y manejen el conocimiento pertinente para solucionar un problema específico.

•

Parten del conocimiento, en donde algún(os) hecho(s), heurística(s) o relación(es) tienen asociadas características temporales que le dan el calificativo de ser de tiempo real.

•

El problema y su solución estarán descritos por las tareas que lo conforman.

•

Las soluciones serán estáticas, es decir, que no cambiarán en el momento de ejecución.

•

La implementación del SBCTR se puede hacer en cualquier lenguaje de programación, siendo unos más apropiados que otros debido a las características propias del sistema.

•

Dentro de la metodología no se considera la definición de la estrategia de planificación, ni la forma como se debe realizar el test de planificabilidad y actividades específicas de la planificación fuera de (off-line) las tareas de tiempo real. Esto forma parte de la validación temporal del sistema y no está dentro del alcance de esta investigación.

•

CommonKADS-RT incluye aspectos tanto en el ámbito general (de la organización – macro) como en el ámbito detallado (de las tareas de tiempo real – micro).

3.5

Ciclo de vida de CommonKADS-RT

Al igual que en CommonKADS, en esta propuesta se sigue con el modelo en espiral orientado por los riesgos. Las etapas que la conforman son las siguientes: •

Viabilidad: En esta etapa lo que se pretende es conocer el problema que se va a corregir para dar una buena recomendación acerca de su solución. Las actividades que se realizan son: la definición y ubicación del problema, la determinación del alcance y los objetivos de la solución, la identificación y el coste de los recursos (hardware, software y humano) necesarios para emprender el proyecto, el estudio de viabilidad, la identificación del tipo de SBCTR que se quiere desarrollar (si es que es el caso), las restricciones, los beneficios y una planeación de la siguiente etapa. (Modelo de la organización).

CommonKADS-RT – Capítulo 3. CommonKADS-RT

99

•

Análisis del Problema: En esta etapa se pretende modelar la solución del problema, definiendo los procesos que van a quedar reflejados en el sistema, planteando esquemas para la implantación de los componentes del sistema y determinando cuáles son las herramientas necesarias para llevar a cabo dicha construcción. Las actividades son: conceptualización, planteamiento del nuevo sistema, modelado y planeación de la siguiente etapa. (modelo de la organización, modelo de TAN, modelo de agentes, modelo de conocimiento, modelo de comunicaciones)

•

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

•

Diseño Detallado: Determinación de la arquitectura del SBCTR, del software apropiado para la construcción del sistema, tal como el lenguaje de programación y el sistema operativo, la estructura de las tareas de tiempo real, los componentes internos del sistema y las estructuras de datos. (modelo del diseño, modelo de tareas de tiempo real).

•

Crecimiento del sistema: Lo que se pretende es construir completamente el sistema hasta que se logre cumplir con los requerimientos planteados al principio del proyecto.

•

Evaluación: Incluye la realización de las pruebas finales por parte del experto y de los usuarios, y la realización del test de planificabilidad.

•

Integración del Sistema: Introducción y adaptación del sistema con el resto de la organización, incluyendo actividades de capacitación.

•

Evolución a Largo Plazo: Se consideran varios tipos de evolución, un incremento de la funcionalidad general del sistema, correcciones o adiciones a la base de conocimientos y una expansión del dominio.

También es importante destacar que, en esta metodología, los procesos de adquisición y de representación del conocimiento no se consideran etapas o fases ya que deben ser actividades que tienen que ser realizadas en diferentes momentos del desarrollo del sistema. Por lo tanto, se consideran como procesos que deben ser paralelos a la metodología. La documentación y las pruebas tampoco se asocian a un único momento, por lo que deben ser realizadas como actividades específicas de cada etapa, de cada proceso y de cada modelo.

100

CommonKADS-RT – Capítulo 3. CommonKADS-RT

Adicionalmente, se ha propuesto un Ciclo de Desarrollo (Figura 3-2) que refleja la relación entre el modelo de espiral y las etapas de este ciclo de vida y un Ciclo de Implantación (Figura 3-3) que se sigue una vez el sistema ha sido construido.

Viabilidad Construcción

Diseño Detallado

Análisis

Formalización

Figura 3-2 Ciclo de Desarrollo en CommonKADS-RT

Test de Planificabilidad

cumplir

No

Ciclo de Desarrollo

Si Integración del Sistema

Evolución a largo plazo

Figura 3-3 Ciclo de Implantación del SBCTR Los modelos y las técnicas que se proponen en CommonKADS-RT son específicas para establecer el análisis y el diseño del SBCTR. Las otras etapas del ciclo de vida no se han considerado en esta investigación. A continuación se presentan los modelos propuestos:

3.6

Modelos que integran a CommonKADS-RT

Como ya se dijo, CommonKADS-RT toma como base los modelos de CommonKADS, incluyendo las características de los sistemas de tiempo real, agregándole los métodos que permiten especificar estos comportamientos temporales. En la Figura 3-1

101

CommonKADS-RT – Capítulo 3. CommonKADS-RT

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.



Organización

Tareas de Alto Nivel

Conocimiento

Comunicaciones

Agentes

Diseño

Tareas de Tiempo Real

Figura 3-4 Modelos de CommonKADS-RT en UML

La relación entre los modelos y el ciclo de vida se puede apreciar en la Tabla 3-1 siguiente:

Tabla 3-1 Relación entre las etapas del ciclo de vida y los modelos de CommonKADSRT Modelo Modelo Modelo Modelo de Modelo de Modelo Modelo de de TTR de la de TAN de ConociComunicacioOrganizaAgentes mientos nes Diseño ción Viabilidad Análisis Fornalización Diseño Detallado

X X

X

X

X X

X X

X 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

CommonKADS-RT – Capítulo 3. CommonKADS-RT

102

problema específico o mejorar un proceso real. Por tanto, a través de él se hace el análisis de la organización en diversos aspectos: su estructura, sus procesos, el factor humano que participa en los procesos, los recursos que se generan y consumen, las relaciones entre los procesos y su gente, entre otras. Las actividades centrales que se realizan en este modelo tienen que ver con la identificación y descripción de los patrones de manejo, comunicación y producción que se poseen, tanto en el momento presente en la organización – situación actual - como en el futuro - la situación a la que se quiere ir, es decir, la situación deseada una vez el SBCTR esté inmerso en ella. El proceso que se sigue para construir completamente este modelo es el siguiente: Se hace un estudio del alcance y de la viabilidad del sistema por medio de la identificación de las áreas problema o de las oportunidades y soluciones potenciales para ponerlas en una amplia perspectiva organizacional. Es decir, que se encuentran áreas prometedoras en donde los sistemas de conocimiento de tiempo real puedan proporcionar un valor agregado importante para la organización. Luego, se decide acerca de las soluciones y sus posibilidades para determinar si el proyecto es importante en cuanto a los costos y beneficios esperados, viabilidad tecnológica, recursos necesarios y compromisos dentro de la organización. Después, se hace el análisis de la naturaleza de las tareas involucradas en el proceso del negocio seleccionado para identificar cuál es el conocimiento usado por los agentes responsables con el fin de utilizarlo exitosamente y cuáles mejoras se pueden hacer en este aspecto. En este caso se establece una estrecha relación entre la tarea, los agentes y el conocimiento. Posteriormente, se determina el impacto que el SBCTR propuesto tiene en la organización, se prepara un plan de acción y se presentan los resultados o productos de este estudio. Al igual que en CommonKADS, esta metodología también incluye una serie de formularios que sirven como guía en la elaboración de este modelo. A continuación, se explica cada uno de éstos con los cambios que se necesitan realizar para poder hablar de un SBCTR.

3.6.1.1

Formularios del modelo de la organización

• OM-1: Identificación en la organización de los problemas y oportunidades orientados al conocimiento, con el tiempo como factor importante El propósito de esta fase del modelado es el de adquirir un conocimiento general de la organización, sus componentes y características para comprender las estructuras y procesos de la misma que servirán como elementos constituyentes del análisis de viabilidad. Este formulario tiene mucha utilidad cuando se quieren conocer los procesos de la organización, sus problemas, las personas o entidades que se ven involucradas en ellos, entre otras. En general, el resultado de aplicar OM-1 será el de obtener una visión global del estado actual de la organización. Pero, en caso que esto no sea necesario, se puede omitir o reducir su alcance, como por ejemplo en la situación en que un proceso esté identificado como problemático o como susceptible de mejoría.

CommonKADS-RT – Capítulo 3. CommonKADS-RT

103

Como se menciona en [Igl98] hay tres enfoques que se pueden aplicar para identificar los problemas y oportunidades de una organización: −

A través de un análisis de los procesos de trabajo con el objetivo de determinar el rendimiento en la organización.

−

A través de una análisis de la ubicación, utilidad y disgregación del conocimiento que se requiere para trabajar en tareas susceptibles de realizar en forma automática.

−

Por medio de un análisis del ambiente cultural, social y del entorno de la organización.

Para lograr estos propósitos, en CommonKADS se propone diligenciar un formulario que se llama Identificación de los problemas orientados al conocimiento y oportunidades en la organización y que como su nombre lo indica, permite hacer un análisis de las situaciones que en un momento dado se están presentando en la organización y se orienta hacia aquellas que son intensivas en conocimiento y que forman el conjunto posible o factible de problemas que pueden ser solucionados por medio de un SBC. Adicionalmente, en CommonKADS-RT se propone que se lleve a cabo este análisis de forma tal que no sólo permita determinar cuáles son los problemas que actualmente se revelan en la empresa y cuáles serían sus posibles soluciones, sino también determinar si tienen restricciones temporales importantes que cumplir y el impacto que pueden producir al interior o al exterior de la organización, con el fin de definir un plan de acción acorde con las directrices generales de la empresa. Para esto, se construye una matriz DAFO (Debilidades, Amenazas, Fortalezas, Oportunidades) con la cual además de ver en dónde hay oportunidad de hacer un SBCTR también se obtiene la información necesaria para saber qué es lo más importante, necesario o urgente de solucionar en la empresa. Así, se puede establecer una forma de asignación de prioridades a los problemas y sus soluciones, de acuerdo con ciertos criterios definidos por la misma organización. Para las situaciones intensivas en conocimiento y con el recurso tiempo como factor determinante, se puede hacer la estimación del tiempo en que el proceso se realiza en la actualidad y el tiempo en que se tendría que hacer con la solución de SBCTR. Esto último podría llegar a ser un factor competitivo para la organización, pero teniendo en cuenta que es un estimativo, ya que el tiempo exacto sólo se sabrá en el momento en que se tenga una versión operativa del sistema. Es decir, cuando se tenga el software del modelo del diseño. A continuación se presenta el nuevo formulario que permite registrar lo anteriormente mencionado:

Modelo de la Organización

Problemas y Oportunidades Hoja de Trabajo OM-1

Contexto de la organización

En este punto, se debe indicar en una forma concisa, las características claves del ambiente de la organización, entre las cuales están: La misión,

CommonKADS-RT – Capítulo 3. CommonKADS-RT

Matriz DAFO

Problemas intensivos en el conocimiento con el factor tiempo como determinante en la realización del proceso

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]). 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) 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 Priorizar o valorar cada uno de los problemas identificados como prioridad asociada basados en el conocimiento y con la variable tiempo como factor importante. Según algún criterio definido, como por ejemplo una prioridad basada en la importancia o relevancia de su solución.

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

Como se puede observar, lo que se pretende con este formulario es registrar el ambiente organizacional y los problemas intensivos en conocimiento y de tiempo real. Por ello, es importante ampliar lo relacionado con la determinación de este tipo de problema. Un problema es intensivo en conocimientos cuando algunos de los procesos que se tienen que realizar para llegar a su solución o a cambiar su condición, están basados no solamente en los hechos (datos) o en las reglas conocidas de un dominio (relaciones) sino también en la experiencia de la(s) persona(s) que participan en él o en la misma cultura de la organización que sabe como solucionarlo. Por otra parte, una solución debe ser por medio de un sistema de tiempo real cuando en los procesos del problema hay tareas que requiere que se realicen en unos períodos definidos o en un tiempo máximo específico. Así, cuando un problema en su estudio preliminar cumple con esas condiciones, entonces se presupone que una buena alternativa de solución es a través de un SBCTR. Para tener más certeza, se analizan los criterios de filtrado, con el objetivo de determinar si es apropiado o no hacer un SBCTR en una situación específica. Ver anexo 1. Con los resultados de OM-1 se debe escoger el problema que cumpla con las condiciones mencionadas anteriormente y que tiene mayor prioridad, necesidad o

CommonKADS-RT – Capítulo 3. CommonKADS-RT

105

urgencia de solucionar. De esta forma, se continúa entonces con el análisis de requerimientos y con la determinación de los otros modelos de la metodología. • OM-2: Descripción de los aspectos de la organización que tienen impacto o están afectados por el problema escogido Con el fin de profundizar en el estudio del problema elegido, entonces se plantea lo siguiente: Modelo de la Organización

Aspectos Variantes Hoja de Trabajo OM-2

Estructura (*)

Diagrama de la estructura considerada (parte de la) organización en función de sus departamentos, grupos, unidades, secciones. 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. 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. 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. 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 Tomada de OM-1 y que indica qué tan significativo es el problema. Si no se ha definido previamente, entonces hacerlo en este momento. 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. 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. 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.

Proceso (*)

Personas

Recursos

Conocimiento

Prioridad asociada Restricciones Temporales

Cultura y Poder Impacto

(*) 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

CommonKADS-RT – Capítulo 3. CommonKADS-RT

MARÍTIMA VALENCIANA

es_proveedor_de

ARMADOR

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.

CommonKADS-RT – Capítulo 3. CommonKADS-RT

Modelo de la Organización Identifica. Nombre de la TAN de la TAN

Proceso de Descomposición Hoja de Trabajo OM-3 Objetivo Tipo de de la TAN TAN

Identificador. Se recomienda que sea un nombre Nemotécnico

Describir la meta o el objetivo que se pretende alcanzar al realizar la TAN

Nombre de alguna de las parte del proceso en OM-2

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.

107

¿Ejecutada por y en dónde?

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.

Importancia de la TAN para el proceso Indica qué tan importante es la TAN para el proceso. Siempre debe ser una respuesta justificada

¿Intensiva en conocimiento?

Conocimiento involucrado

¿La TAN es intensiva en conocimientos? (Alto, Medio,

Lista de los recursos de conocimiento usados en la TAN

Bajo)

*

¿Tiene restricciones temporales? ¿Cuáles son las medidas de tiempo o especificacio nes temporales asociadas a la ejecución de la TAN?

¿Es posible introducir un sistema informático en 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)

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.

108

CommonKADS-RT – Capítulo 3. CommonKADS-RT

Además, es posible construir un diagrama llamado de Cooperación de TAN, extensión del diagrama de colaboración de UML, para relacionar todas las TAN ya detalladas y así tener una vista gráfica de los componentes del problema. Cada TAN es representada por un rectángulo con su nombre asociado, las relaciones entre ellas se representan como líneas continuas cuando hay una secuencialidad entre las tareas y líneas discontinuas cuando se pueden hacer simultáneamente o no hay un orden establecido en la realización de las tareas involucradas. Esta relación es un intercambio de información y por tanto debe tener asociado el nombre del rol que se comunica.

TAN-2

Rol-1 Rol-1 TAN-1

TAN-3 Rol-1

Rol-2 Rol-3

TAN-n

Rol-4 TAN-4

Figura 3-6 Diagrama de Cooperación de TAN

• OM-4: Descripción del componente de conocimientos del modelo de la organización Este formulario está asociado con la descripción del conocimiento de cada una de las Tareas de Alto Nivel intensivas en conocimiento que deben realizarse. Es importante, hacer una clasificación del conocimiento que se maneja en el proceso, determinando si se trata de datos, información, habilidades o capacidades, o conocimiento propio del proceso. De tal forma que en el Formulario OM-4 se analice más detalladamente el que se refiere al último que se mencionó. El único cambio que se le ha hecho a este formulario es que en CommonKADS habla de tareas y en CommonKADS-RT se habla es de TAN.

Modelo de la Organización Activo Poseído Conocimiento por:

Capital (Activo) Conocimiento Hoja de Trabajo OM-4 Usado en ¿Forma ¿Lugar TAN: correcta? correcto?

Nombre (hoja OM-3)

Agente (hoja OM-3)

TAN OM-3)

…

…

…

¿Tiempo ¿Calidad correcto? correcta?

(hoja (Si o No; (Si o No; (Si o No; (Si o No; comentario) comentario) comentario) comentario)

…

…

…

…

Formulario 3-4 OM-4: Descripción del componente de conocimiento del modelo de la organización

CommonKADS-RT – Capítulo 3. CommonKADS-RT

109

Una vez que se conoce muy bien la situación inicial, se comienza el planteamiento de las diferentes alternativas de solución, teniendo en cuenta lo que se indicó anteriormente en relación con la solución basada en conocimientos y de tiempo real. • OM-5: Descripción de los aspectos de la organización que tendrán impacto o estarán afectados por la solución escogida del SBCTR Para continuar con la metodología CommonKADS-RT, se supone entonces que la alternativa elegida ha sido evaluar la posibilidad de hacer un SBCTR. Para esto se sigue con el nuevo Formulario 3-5.

Modelo de la Organización

Aspectos Variantes Hoja de Trabajo OM-5

Estructura una vez se tenga el SBCTR Nombre de la TAN en donde estará el SBCTR Esquema del Proceso automatizado

De acuerdo con la estructura definida en OM-2, especificar los departamentos, grupos, unidades, en donde estará implantado el SBCTR. De OM-3 y OM-4

Personas que pueden participar en el desarrollo del SBCTR Recursos Conocimiento Restricciones de la aplicación del SBCTR Restricciones Temporales

Cultura y Poder Impacto

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. 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. Descripción de los elementos de hardware y software que se necesitan para hacer el SBCTR y para implantarlo. Determinar el conocimiento que puede manejar el SBCTR. Debe ser coherente con lo que se definió en OM-3 y en OM-4. 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. 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. Igual que en OM-2 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

CommonKADS-RT – Capítulo 3. CommonKADS-RT

Como se sugiere en la parte esquema del proceso automatizado, es importante hacer un diagrama de contexto que muestre al SBCTR como una sola transformación conectada a los flujos de datos y flujos de control – eventos que forman las interfaces entre el SBCTR y el ambiente que lo rodea. Esto es ubicar el SBCTR en la TAN apropiada, en donde el sistema puede ser un componente más de ella. Siguiendo los estereotipos de UML, el diagrama de contexto también puede verse como la comunicación entre unos agentes (objetos externos) y el sistema (flujo de datos y de control), reflejando siempre la vista más abstracta que permite revelar lo que el sistema es y lo que no es. Además, ya que el análisis debe ser hecho para un sistema basado en el conocimiento de tiempo real, se tienen que considerar ciertas variables temporales de alto nivel. En la Figura 3-7 se plantea una forma de hacer dicho diagrama, incluyendo la relación con los agentes del sistema. datos datos conocimiento

información

SBCTR

información

Actor 2

Actor 1 Estímulos

Respuestas

Figura 3-7 Forma general de un Diagrama de Contexto para el SBCTR Donde: Representa el sistema central Representa las entradas o salidas al sistema Es el actor (ser humano que interactúa con el sistema) Cuando es de entrada es el agente emisor ( sistema de información o dispositivo externo al sistema), cuando es de salida es el agente actuador (sistema de información o dispositivo externo al sistema) Representa el flujo de datos o información Es el flujo de conocimiento

Para el análisis de requerimientos se puede utilizar también una lista de eventos externos para identificar, en forma global, los eventos del ambiente que son de interés para el SBCTR. En ésta se detalla el nombre de los eventos, las acciones que el sistema tiene que realizar como respuesta a dichos eventos, la forma en que cada evento llega al

111

CommonKADS-RT – Capítulo 3. CommonKADS-RT

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.

1

Evento

ctor o Agente ue lo produce

Acciones del SBCTR

Nombre o identificador del evento

Nombre o identificador del agente o del actor que origina el evento

Qué hace el SBCTR con el evento.

Tipo de evento según su llegada Clasificar el evento como periódico o esporádico.

Plazo Máximo Cuál es el tiempo que el SBCTR tiene para producir una respuesta apropiada y oportuna a dicho evento

2 ..

Formulario 3-6 Lista de eventos externos que tienen relación con el sistema

Con esto se logra conocer realmente cuáles son los activadores del sistema total y sus reacciones. Así, cuando posteriormente se requiera desglosar los procesos del sistema, se tendrá computerizada la información completa sobre el entorno y su relación con el sistema. En caso de no conocerse el plazo máximo, se pone desconocido y se tendrá en cuenta para más adelante. Es importante anotar, que esta tabla se puede detallar más en la medida en que se va avanzando en el proceso del análisis y diseño del SBCTR. Integrando la información obtenida del diagrama de contexto del SBCTR, el diagrama de actividades con el SBCTR incluido y la lista de eventos externos, se puede construir un gráfico completo y detallado del SBCTR. • OM-6: Lista de chequeo para el documento de viabilidad de la decisión de hacer un SBCTR Este formulario plantea una serie de conceptos y criterios que se utilizan en la preparación y evaluación de un proyecto tecnológico y que se deben tener en cuenta para tomar una decisión acerca de la posibilidad de solucionar un problema por medio de un SBCTR. Modelo de la Organización

Lista de Chequeo para el documento de la viabilidad de la decisión. Hoja de Trabajo OM-6

Viabilidad del negocio

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

Viabilidad técnica

CommonKADS-RT – Capítulo 3. CommonKADS-RT

112

que ser respondidas: 1. ¿Qué tan compleja, en cuanto al almacenamiento del conocimiento y de procesos de razonamiento que deben ser realizados, es la tarea de alto nivel a ser ejecutada por el sistema de conocimiento considerado como solución? 2. ¿Hay aspectos críticos en el proceso relacionados con el tiempo?, ¿El proceso tiene restricciones temporales? 3. ¿Hay aspectos críticos involucrados que se relacionen con la calidad, con los recursos necesarios, o con otras cosas? Si es así, ¿cómo es esto? 4. ¿Es clara la forma para medir el éxito? ¿Cómo comprobar que se tiene una ejecución satisfactoria y es de buena calidad? 5. ¿Qué tan compleja es la interacción requerida con los usuarios finales (interfaces de usuario)? ¿Son el estado del arte los métodos y las técnicas disponibles y son adecuadas? 6. ¿Qué tan compleja es la interacción con los otros sistemas de información, otros dispositivos o periféricos y otros posibles recursos (interoperabilidad, integración de sistemas, compatibilidad)? ¿Son el estado del arte los métodos y las técnicas disponibles y son adecuadas? 7. ¿Hay otros riesgos tecnológicos e incertidumbre? También, se deben hacer preguntas relacionadas con el tipo de herramientas que pueden ser utilizadas, su disponibilidad, escalabilidad, entre otras. 1. Costes implícitos en la adquisición, adecuación y funcionamiento de los equipos 2. ¿Cuál es el tiempo de vida útil que se espera tenga el sistema y cuál será la calidad del servicio prestado en el tiempo? 3. Deben tenerse en cuenta los aspectos críticos, las fallas técnicas y los avances tecnológicos para así cuando se presente una sobrecarga transitoria se garantice que los requerimientos temporales críticos se cumplan 4. Se debe garantizar la estabilidad del sistema

Viabilidad del proyecto

Acciones propuestas

En resumen, es aplicar los criterios planteados en el anexo 1. 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? Esta es la parte del documento que está directamente relacionada con la gerencia y la toma de decisiones. Para ello se valoran e integran los resultados del análisis que hasta el momento se ha realizado, en pasos concretos: Enfoque: ¿Cuál es el enfoque recomendado en las áreas o problemas identificadas? Solución objetivo: ¿Cuál es la dirección de la solución recomendada para esta situación? ¿Cuáles son los resultados y los beneficios esperados? ¿Cuáles son las acciones del proyecto que se tienen que llevar a cabo para poder realizarlo? ¿Si las circunstancias dentro y fuera de la organización cambian, en cuáles condiciones es prudente reconsiderar la decisión propuesta?

Formulario 3-7 OM-6. Lista de chequeo para el documento de viabilidad de la decisión de hacer un SBCTR

CommonKADS-RT – Capítulo 3. CommonKADS-RT

3.6.1.2

113

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

CommonKADS-RT – Capítulo 3. CommonKADS-RT

debilidades amenazas

Organización fortalezas oportunidades

Lista de problemas + lista de estrategias + Contexto organizacional

OM-1

problemas y estrategias intensivas en conocimientos y tiempo real priorización Lista de posibles SBCTR (ordenados por prioridades) Problema elegido Impacto

Estructura de la organización

Cultura y poder Restricciones

Personas que Proceso asociado al participan en el proceso Recursos Prioridad problema Conocimiento

OM-2

TAN del proceso ¿Sist. Inf.?

Identificador Nombre

Restricciones temporales

Importancia Tipo

Agente

Intensivo en

OM-3

Localización Conocimiento

OM-4

Activo Conocimiento

SBCTR Propuesto Ubicación del SBCTR Esquema del proceso automatizado

Impacto Cultura Restricciones y poder

Personas que participan

OM-5

Recursos Restricciones del Conocimiento De OM-1, OM-2, OM-3, OM-4, OM-5 Viabilidad

-

Viabilidad del Negocio Viabilidad técnica Viabilidad del proyecto Acciones propuestas

Figura 3-8 Modelo de la organización de CommonKADS-RT

OM-6

CommonKADS-RT – Capítulo 3. CommonKADS-RT

115

Adicionalmente, se tiene que tener identificado y concertado al (los) experto(s) del dominio y al (los) usuario(s) y un gerente o líder de proyecto que sea quien se encargue, entre otras cosas, de servir como enlace entre el grupo de desarrollo y la alta gerencia.

3.6.2

Modelo de tareas de alto nivel

Las tareas de alto nivel son las partes que conforman un proceso del negocio y que representan una actividad orientada por las metas, dándole valor a la organización. Éstas a su vez, pueden estar formadas por otras tareas que pueden ser de tiempo real o no. En CommonKADS esto se refleja en lo que se denomina el Modelo de Tareas, pero en esta propuesta se le ha cambiado el nombre por Modelo de Tareas de Alto Nivel para hacer una diferencia entre las tareas que se relacionan con los procesos del negocio y las tareas que se manejan a más bajo nivel en los sistemas de tiempo real. Estas últimas se especifican en el nuevo modelo llamado Modelo de Tareas de Tiempo Real y que se explica más adelante. Una Tarea de Alto Nivel (TAN) es entonces el reflejo de un proceso organizacional, el cual se compone de un objetivo, una definición del problema y una forma o método para alcanzar la solución. Durante la ejecución de la tarea se manejan entradas, se consumen recursos y se producen salidas de una forma estructurada y controlada, basados en unos conocimientos y habilidades que permiten definir el método de solución. Adicionalmente, es importante que la tarea tenga asociados unos criterios de desempeño y de calidad determinados. Si por ejemplo se tiene que el proceso que se identificó en unos de los escenarios que se presentan en el capítulo 4, relacionado con la Operativa Marítima en una terminal de contenedores, entonces las tareas de alto nivel que lo conforman son: TAN1 TAN2 TAN3 TAN4 TAN5

à Atención à Scheduling à Planificación à Operativa Marítima à 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 TAN2,2 TAN2,3

à Identificación de requerimientos y situación actual à Asignación de recursos à Adecuación de los demás servicios que están en el Muelle.

CommonKADS-RT – Capítulo 3. CommonKADS-RT

116

Es importante anotar, que este caso se presenta completamente en el Capítulo 4. de este documento. Las TAN a su vez, pueden ser descompuestas en tareas hasta llegar a un nivel en donde no sea posible descomponer más. En el modelo de conocimientos se especificará el conocimiento que se requiere para llevarlas a cabo. El nivel más bajo de las tareas (las tareas de las hojas del diagrama de descomposición de tareas), es el que se ampliará en el modelo de comunicación.

3.6.2.1

Formularios del modelo de TAN

El modelo de tareas de alto nivel, por lo tanto debe permitir examinar cada una de las tareas en forma global, sus entradas, salidas, precondiciones, criterios de ejecución, recursos y habilidades necesarias para su realización. Para esto se tienen los formularios TM-1, TM-2 y TM-3 que permiten reflejar el conocimiento relacionado con dichas funciones. • TM-1: Descripción refinada de las tareas de alto nivel dentro del proceso objetivo Este formulario permite ubicar cada una de las TAN dentro del proceso al que pertenecen y hacer una descripción más detallada de ella. También amplía la información que en el modelo de la organización se trató en los apartes que hablaban de las tareas de alto nivel.

Modelo de Tarea de Alto Nivel

Análisis de la Tarea de Alto Nivel Hoja de Trabajo TM-1

Tarea de alto nivel Ubicación en la Organización

(Como en OM-3) (Como en OM-3)

Identificador y nombre de la TAN 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). Describe la meta de la TAN y el valor que su ejecución adiciona al proceso al que ella pertenece. 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 CommonKADSRT). Este formulario se llamará TM-1.1 y facilitará el determinar:

1.

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

Objetivo y valor Dependencia /Flujo

2. 3. Objetos manejados en la TAN

1.

2.

TAN predecesoras TAN que la siguen TAN concurrentes Objetos de entrada Objetos

Los objetos, incluyendo los elementos de datos, información, eventos y de conocimiento que constituyen la entrada de la TAN. de Los objetos, incluyendo la información que entrega la TAN

CommonKADS-RT – Capítulo 3. CommonKADS-RT

3.

Tiempo y Control

Agentes

Conocimiento y Habilidades

Recursos

Calidad y Rendimiento

1.

salida Objetos internos

2.

Frecuencia, duración Tiempo límite

3. 4.

Periodicidad Control

5.

Restricciones

117

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

(De OM-1 y OM-2: las personas, y los recursos de sistemas; de OM-3: el ejecutado por) (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. (Refinamiento de Descripción de los recursos consumidos o utilizados en la TAN OM-2) (personas, sistemas y equipos, materiales, presupuesto financiero). También sería importante cuantificar dichos recursos en cuanto a su valor. 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

CommonKADS-RT – Capítulo 3. CommonKADS-RT

−

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) ¿Cuello de botella?/¿Para ser mejorado?

Naturaleza del Conocimiento Formal, riguroso Empírico, cuantitativo Heurístico Altamente especializado, Específico del dominio Basado en la experiencia Basado en la acción Incompleto Incierto, puede ser incorrecto Cambiante rápidamente Difícil de verificar Tácito, difícil de transferir Forma del Conocimiento En la mente En papel En forma electrónica Habilidades de acción Otros Estructura del Conocimiento

CommonKADS-RT – Capítulo 3. CommonKADS-RT

119

Cómo está conformado Cómo se puede representar ¿Se puede manejar todo en un ordenador? ¿Cómo se puede pasar de una TAN a otra? Disponibilidad del Conocimiento Limitaciones en tiempo Limitaciones en espacio Limitaciones en acceso Limitaciones en calidad Limitaciones en forma

Formulario 3-9 TM-2 Especificación del conocimiento empleado en la tarea de alto nivel y posibles cuellos de botella y áreas para mejorar

Hasta el momento sólo se ha hablado del conocimiento de las tareas dado que CommonKADS fue planteada para SBC, pero como CommonKADS-RT también tiene que involucrar el tiempo, entonces se requiere otra información importante para modelar apropiadamente la TAN. Por ello se ha incluido el siguiente nuevo formulario. • TM-3: Descripción de las tareas de alto nivel a través de los eventos que las afectan Este formulario permite conocer las entradas y salidas de la TAN, específicamente los estímulos y respuestas que ofrecen y que en última instancia, serán los que definan el sistema. En realidad es hacer un análisis de escenarios en donde cada TAN se describe a través de la determinación de sus entradas y salidas, siguiendo este formulario. Es de anotar que es más conveniente hacer este análisis después de haber analizado TM-1 y antes de TM-2. Tabla 3-2 Descripción de las tareas de alto nivel a través de los eventos que las afectan Modelo de Tarea de Descripción de estímulos y respuestas de la TAN Alto Nivel 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, Respuesta, puede ser un evento de salida de nombre del proceso de datos (información) o de control resultante y la TAN que se ve los estados modificados del sistema afectado por el evento

También, en los sistemas de tiempo real se pueden asociar las TAN a los dispositivos, mecanismos o subsistemas que lo forman. Por lo tanto, si se diligencia el formulario TM-3 para cada uno de ellos, entonces se tienen el análisis completo de cómo funciona, qué hace, qué requiere para actuar y qué produce.

CommonKADS-RT – Capítulo 3. CommonKADS-RT

120

Además, se deben modelar los eventos que ocurren en la tarea con la ayuda de los diagramas de transición de estados y de la lista de eventos externos que se plantea en el modelo de agentes (como en la Tabla 3-3).

3.6.2.2

Artefactos del modelo de TAN

El modelo de TAN permite describir en forma detallada los procesos intensivos en conocimientos y con restricciones temporales que se realizan en la unidad de la organización. Los artefactos o productos que se obtienen en este modelo son: •

Los formularios diligenciados o la documentación relativa a ellos.

•

Los diagramas de flujo y de conceptos para especificar los objetos de la TAN y el flujo de datos dentro de ella.

•

Los diagramas de eventos, de actividades y de transición de estados, para mostrar las relaciones con las otras TAN o con los agentes y su variación en el tiempo.

•

El tipo de tarea, de acuerdo con los tipos de problemas o procesos generales y que permite reutilizar las plantillas definidas en CommonKADS y optimizan el tiempo del modelado del conocimiento.

•

La identificación de las restricciones temporales que pueden definirse en una TAN.

3.6.2.3

Roles en el modelo de tareas de alto nivel

Para realizar este modelo se requiere que participen el (los) experto(s) del dominio, el (los) usuario(s), el (los) ingenieros del conocimiento y tiempo real, y el gerente del proyecto.

3.6.3

Modelo de agentes

Un agente es el ejecutor de una TAN, puede ser un humano, un sistema de información computarizado o cualquier entidad que sea capaz de realizarla. Así, en este modelo se define cómo son los agentes, cómo se caracterizan, qué conocimiento tienen y con quién se comunican. Además, el modelo proporciona el enlace entre los Modelos de Tarea de Alto Nivel, Comunicación y Conocimiento. En CommonKADS no se profundiza mucho en este modelo ni se comenta cómo modelar el problema cuando varios agentes heterogéneos (unos humanos y otros sistemas computarizados) se comunican para participar en una TAN específica. Por esto, el concepto que en esta propuesta se maneja es que además de lo anterior, se debe considerar que:

CommonKADS-RT – Capítulo 3. CommonKADS-RT

121

•

El agente puede ser simplemente el que solicita un servicio, el que lo realiza o el que se ve afectado por lo que otro hace.

•

Se propone que los agentes heterogéneos sean tratados en forma diferente, especialmente para su modelado gráfico. Así, se tiene lo siguientes: −

El agente actor, que es el ser humano que ejecuta una TAN o parte de ella.

−

El agente software que se encarga de la percepción, la cognición o la actuación dentro de una TAN. Dentro de estos pueden haber agentes emisores o agentes actuadores. El agente a la vez puede hacer tareas de percepción y cognición o de cognición y acción, o las tres a la vez.

•

El SBCTR no se considera un agente para él mismo. Así que sólo será un agente, cuando se esté modelando otro sistema diferente de él. Pero, es posible que el SBCTR esté conformado por una serie de agentes, llegando a ser un sistema multiagentes (esto requiere de otras consideraciones que no están dentro del alcance de esta investigación).

•

También, es importante clasificarlo en relación con la TAN que se definió en TM-1 y, es fundamental determinar las condiciones temporales de las funciones del agente, esto para efectos prácticos del modelado y manejo del conocimiento del SBCTR. A continuación se presenta el formulario de este modelo con los cambios ya incluidos:

3.6.3.1

Formularios del modelo de agentes

• AM-1: Especificación de los agentes del SBCTR

Modelo de Agente

Agente Hoja de Trabajo AM-1

Nombre Ubicación en la Organización

Nombre del agente 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. 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. 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. 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) Lista de nombres de otros de agentes con los que se relaciona

Ubicación en la(s) TAN Tipo de agente

Restricciones temporales Se Comunica con

122

CommonKADS-RT – Capítulo 3. CommonKADS-RT

Conocimiento Otras Destrezas Responsabilidades y Restricciones

Lista de puntos de conocimiento poseídos por el agente (Como en TM-2) Lista de otras destrezas requeridas o presentes del agente 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

1 2 ..

Evento

Agente que lo produce

Acciones del Sistema

Tipo de evento según su llegada

deadline

ev-señal-sensor

Bumper

evitar-obstáculo

periódico

desconocido

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

CommonKADS-RT – Capítulo 3. CommonKADS-RT

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 1 Llamada de ascensor

2 Solicitud piso

Agente que lo produce

Acciones del Sistema Tipo de evento deadline según su llegada

Pasajero potencial

a. Encender botón b. Poner solicitud en lista de espera c. Enviar el ascensor seleccionado al piso d. Encender botón e. Enviar ascensor al piso f. Puerta empieza a abrirse, se inicia el contador de tiempo de cierre de puerta

Pasajero

3 Presión Pasajero botón para abrir

Esporádico

a. Encender 2 s. b. 1 s. c. 5 s. X # pisos

Esporádico

d. 0.5 s. e. 5 s. X # pisos

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 Pasajero potencial está en el piso 1

Ascensor

Ascensor

Solicitud subir elevador

Solicitud piso 3

Enciende indicador de piso

Enciende luz de llamado Desciende hasta piso 1

Ascensor llega al piso 1 Pasajero potencial pasa a ser Pasajero

Pasajero

Ascensor llega al piso 3

Puerta se abre

Sube hasta el piso 3

Puerta se abre Pasajero se baja Ascensor queda en espera de una solicitud

124

CommonKADS-RT – Capítulo 3. CommonKADS-RT

b) Pasajero Pasajero potencial está en el piso 1

Pulsa botón de llamado Enciende luz de llamado

Ascensor

Ascensor

Ascensor está en el piso 5

2 seg.

Apaga luz de llamado

Ascensor llega al piso 3

Puerta se abre Pasajero potencial pasa a ser Pasajero

Solicitud piso 3

Enciende indicador de piso 3 Sube hasta el piso 3 t=5 seg. X 2 pisos

Cola solicitudes

Ascensor llega al piso 1

Pasajero

3 seg.

Apaga indicador del piso 3

Enciende luz de llamado

Fin de tiempo de puerta y cierra Puerta se abre Pasajero se baja Ascensor queda en espera de una solicitud

Fin de tiempo de puerta y cierra

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.

125

CommonKADS-RT – Capítulo 3. CommonKADS-RT

Solicitud de servicios Jefe de Planificación

Planeación de actividades

Barco

Asignación de recursos Orden de carga

Figura 3-10 Ejemplo de un caso de uso para algunos agentes en la terminal de contenedores del puerto de Valencia

3.6.3.2

Artefactos del modelo de agentes

Al igual que para el modelo de TAN, los productos de este modelo se refieren a la documentación, el formulario y los gráficos que en él se han realizado. Es decir: •

El formulario AM-1,

•

Los diferentes agentes del SBCTR, con sus características y especificaciones temporales.

•

Los diagramas de casos de uso y la lista de eventos externos.

3.6.3.3

Roles en el modelo de agentes

Son los mismos que participan en el modelo de TAN mas los actores que se hayan identificado.

3.6.4

Modelo de conocimiento

En CommonKADS este modelo permite explicar en detalle los tipos y estructuras del conocimiento específico de un dominio y de la situación, que se utilizan en la ejecución de una TAN particular. Fundamentalmente, este modelo captura las tres principales categorías del conocimiento: conocimiento de la tarea, conocimiento del dominio y conocimiento de la inferencia. La descripción que provee es independiente de la implementación del rol que los diferentes componentes del conocimiento juegan en la solución del problema y lo hace en una forma que es entendible por los humanos. Esto hace que el modelo de conocimientos

CommonKADS-RT – Capítulo 3. CommonKADS-RT

126

sea un medio importante para la comunicación entre los expertos y los usuarios durante el desarrollo del sistema y en su ejecución. Para construir este modelo primero se debe identificar el conocimiento, luego se debe especificar y después, se debe hacer su refinamiento. A continuación se presenta la idea general de estos procesos, que al final quedarán reflejados en diferentes formularios y en especial en el Formulario 3-11 KM-1: Lista de comprobación de la documentación del modelo del conocimiento. •

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

•

Especificación del conocimiento, en especial del que se va a modelar, diferenciando las entradas, las inferencias y las salidas. El resultado final de este proceso es la obtención del conocimiento de inferencia, el conocimiento de la tarea y el del dominio para el SBCTR. Para realizar esto, se cuenta con el diagrama de conceptos que es un esquema del conocimiento del dominio. Este diagrama es muy similar al diagrama de clases de UML, sólo que no se definen los métodos que se realizan en el concepto ya que estos formarán parte del conocimiento de la inferencia. Recuérdese en el modelo de TAN se planteó hacer un diagrama de este estilo a un nivel general, para dar una idea de los objetos y las relaciones que pueden existir entre ellos. Para facilitar el manejo del conocimiento del dominio se introduce la idea de subdominios, análogo al dominio que se manejan en UML, en donde estos son categorías que se identifican claramente en el dominio del conocimiento. Por ejemplo en el dominio de marítima, que se presenta en Capítulo 4. sección 4.3, se pueden encontrar diversos conceptos que pueden ser clasificados en subdominios de la siguiente forma: 1) subdominio-muelle. Contiene los conceptos específicos del muelle, tales como: la posición en la terminal, la pila, la calle y la planta. 2) subdominio-maquinaria. Contiene los conceptos de maquinaria que se manejan en el muelle: máquina, frontal, grúa, chasis de la terminal, transtainer. 3) subdominio-documentación, que incluye los conceptos: carpeta, E.T.A., secuencia y Bayplan.

CommonKADS-RT – Capítulo 3. CommonKADS-RT

127

Identificar sub-dominio del dominio facilita tanto el tratamiento de los conceptos, como la profundización y reutilización del conocimiento puesto que posibilita la identificación del tipo de conocimiento y su aplicación en diversos problemas. •

Refinamiento del conocimiento, en donde se hacen las pruebas de la estructura del conocimiento a través de simulaciones y en caso de ser positivas las evaluaciones, entonces se completan las bases de conocimiento.

A continuación se presenta el formulario KM-1 que presenta el registro de la información relacionada con el proceso de adquisición y representación del conocimiento planteado en los párrafos anteriores.

Modelo de Conocimientos

Lista de comprobación de la documentación del modelo de conocimientos Hoja de Trabajo KM-1

Modelo de Conocimientos

Especificación completa del modelo de conocimientos en forma textual e inclusión de algunas figuras relevantes. Es la instanciación de la Figura 3-10, la composición del diagrama de conceptos, la definición de subdominios, de la base de conocimientos, el conocimiento de inferencia y de la tarea. 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. 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. 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 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. 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. Conceptos o criterios a tener en cuenta para hacer la validación de la planificación de las tareas, del conocimiento y del razonamiento. Descripción de los resultados de los estudios de validación, en particular las simulaciones basadas en papel o en ordenador (prototipos) Material obtenido durante las actividades de extracción del conocimiento (por ejemplo la trascripción de las entrevistas) en apéndices.

Fuentes Estáticas de Conocimientos usadas

Fuentes Dinámicas de Conocimientos utilizadas

Glosario

Componentes considerados

Escenarios Estándares de validación Resultados de validación Material de Extracción

Formulario 3-11 KM-1: Lista de comprobación de la documentación del modelo del conocimiento

CommonKADS-RT – Capítulo 3. CommonKADS-RT

128

Desde el punto de vista de los SBCTR CommonKADS no proporciona muchas facilidades que permitan el modelado de la especificación temporal del sistema. Es cierto que en la entidad tarea se incluyen atributos como frecuencia, que sirve para indicar la frecuencia de la tarea, y duración para definir cuánto durará la tarea. Además, que la función de transferencia receive que permite establecer la comunicación entre el sistema y el exterior, cuando éste último tiene la iniciativa y mantiene la información. Pero, a pesar de esto, hay algunas cosas que faltarían por modelarse, y es lo que se propone en este modelo. Al igual que en CommonKADS, se utiliza el lenguaje CML2 para especificar el conocimiento, adicionándole las instrucciones necesarias para modelar el conocimiento de tiempo real, para especificar las relaciones temporales. •

En el ámbito del Conocimiento de Inferencia: inference-knowledge ::= inference-knowledge Inference-knowledge; [terminology] [use: use-construct, …, ] < inference | knowledge-role | transfer-function > * end inference-knowledge [ Inference-knowledge ;]. transfer-function

::= transfer-function transfer-function ; terminology] type: roles: input: Dynamic-knowledge-role ; output: Dynamic-knowledge-role ; end transfer-function transfer-function;

Se utilizará las funciones receive y present para definir la comunicación entre los agentes (actores, emisores y actuadores) y el SBCTR de forma que pueda reflejarse la comunicación asíncrona entre ellos, lo cual es común en estos sistemas. Un ejemplo de esto es: transfer-function medir-señal; type: receive roles: input: señal-sensor; output: lista-de-medidas; end transfer-function transfer-function; •

En el ámbito del Conocimiento de la Tarea hay un cambio importante pues se introduce la idea de tener TAN de tiempo real, por lo que se propone que cuando se confirme que el proceso que se quiere modelar tiene restricciones temporales que afectan su ejecución, entonces debe ser tratado en forma diferente a la que no las tiene. Así que se propone lo siguiente:

CommonKADS-RT – Capítulo 3. CommonKADS-RT

129

real-time-task ::= real-time-task Real-time-task; [terminology] [domain-name : Domain ;] [goal : “Text” ;] type: rt-task-type; [from: real-time-task]; relative-time: Yes | No; [period: Natural; ] [deadline: Natural; ] [wcet: Natural; ] [real-time-task-before : real-time-task]; [formed-by-others: Yes | No;] roles : input: role-description+; output: role-description+; end real-time-task [Real-time-task ; ] rt-task-type

::= periodic | esporadic | aperiodic;

De esta misma forma, se plantea que el método de la tarea permita especificar si la tarea es de tiempo real o no, de la siguiente forma: task-method

rt-task-type

::= 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 ; ] ::= periodic | esporadic | aperiodic;

Estos tipos de tarea definen la forma en que ellas llegan al sistema y cómo deben ser atendidas. Si la tarea es periódica, se espera que cada cierto tiempo – período – llegue o sea activada. Si la tarea es esporádica entonces el sistema sabe qué hacer cuando llegue, pero no está esperándola, no sabe si llegará. Si es aperiódica entonces se sabe que llegará pero no cuándo. Un ejemplo de la estructura de una tarea de tiempo real es el siguiente: real-time-task planificador-Acciones; goal: “ se encarga de planificar las acciones que debe hacer el robot de acuerdo con los valores emitidos por los sensores y por la situación inicial del micro mundo. Esta tarea es periódica pues debe realizarse cada cierto tiempo”. rt-task-type: periodic; from: buscar-Objeto; period: 100; /* milisegundos */ deadline: 8; /* milisegundos */

CommonKADS-RT – Capítulo 3. CommonKADS-RT

130

real-time-task-before: percep-Entorno; formed-by-others: Yes; roles : input: lista-medidas-sensor, mapa-inicial; output: acción; end real-time-task planificador-Acciones; El método de esta tarea no se especifica pues se utiliza el planteado para planificación en el modelo de plantillas planteadas en [SAA00]. •

En el ámbito del Conocimiento del dominio se introducen dos nuevos valores a los tipos de datos manejados en CommonKADS. Por una lado está el symbol (como fue propuesto en [Pal99], pero incluyéndolo dentro de los tipos primitivos pues si se define como un value type sólo estará disponible para ese dominio específico. Además, definiría un nuevo tipo relacionado con el tiempo para determinar si la las restricciones temporales están considerando el tiempo como relativo o absoluto. Es decir, se tendría un absolute-time y un relative-time que representan el tiempo absoluto determinado por los pulsos de un reloj o el relativo dado por el orden estricto impuesto en los conjuntos de todas las ocurrencias de las transacciones. primitive-type

•

::= number | integer | natural | real | image | string | boolean | universal | date | text | symbol | relative-time | absolute-time;

En la estructura de control se debe incluir la llamada de una tarea de tiempo real, de modo que la función debe replantearse así: function

::= Task | Real-Time-Task | Inference | transfer-function ;

También se pueden incluir las operaciones propuestas en [Pal99].

Como se puede apreciar, en este modelo se asume el no incluir conceptos específicos para modelar aspectos referentes a las características específicas de un sistema de tiempo real, porque se considera que todo ello debe ser detallado en la tarea de tiempo real al nivel del diseño, no al nivel de análisis que se plantea.

3.6.4.1

Artefactos del modelo de conocimientos

•

De este modelo se obtiene toda la especificación del conocimiento de la aplicación en CML2 y los diagramas de concepto y de control.

•

Además, la documentación debe incluir la especificación y el registro del proceso de adquisición del conocimiento que se llevó a cabo para hacer la especificación de los diferentes modelos.

CommonKADS-RT – Capítulo 3. CommonKADS-RT

•

131

El formulario KM-1diligenciado.

3.6.4.2

Roles en el modelo de conocimientos

El (los) experto(s) del dominio, el (los) usuario(s), el (los) ingeniero(s) del conocimiento de tiempo real (debe saber CML2) y el gerente del proyecto.

3.6.5

Modelo de comunicaciones

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

Del modelo de TAN la lista de TAN realizadas por un agente en especial. Para este modelo importan las tareas hoja o sea las que no se descomponen más, junto con sus objetos de información de entrada y salida

•

Del modelo de conocimientos se requiere el conjunto de funciones de transferencia, nodos hoja en la estructura de inferencia de la tarea que depende de datos o resultados de razonamiento para el mundo externo.

•

Del modelo de agentes se necesita la descripción de los agentes relevantes, con su conocimiento, capacidades, responsabilidades y restricciones.

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

CommonKADS-RT – Capítulo 3. CommonKADS-RT

132

Este modelo es muy importante, dependiendo de la arquitectura del SBCTR, ya que si lo que se tiene son dos sistemas, uno de tiempo real y otro basado en el conocimiento, la comunicación entre ellos es fundamental. Así, el SBC puede ver al STR como un agente que le provee información para su toma de decisiones y viceversa. Por ello, las transacciones deberán ser modeladas apropiadamente. Para efectos de esta tesis, se está hablando de un SBCTR genérico, en donde la parte central está puesta en el conocimiento, y el tiempo real es información adicional que limita o restringe el acceso de los datos, el razonamiento y el conocimiento mismo. Por esto, el modelo de comunicaciones de CommonKADS-RT es básicamente el mismo de CommonKADS, pero incluyendo los diferentes tipos de agentes que pueden presentarse en el sistema. Esto implica, que deban especificarse diferentes tipos de transacción dependiendo de los agentes que participan en la comunicación. La comunicación entre agentes ha sido tratada muy ampliamente por FIPA (Foundation for Intelligent Physical Agents) [Fip00], a través de una serie de especificaciones que representan una colección de estándares que tratan de promover la interoperación de agentes heterogéneos y de servicios que ellos pueden representar. Se define la asumpción que los agentes se comunican a un nivel de discurso alto, es decir que el contenido de los mensajes son sentencias con significado acerca del conocimiento o del entorno del agente. Los agentes entienden y son capaces de ejecutar algunas acciones y de realizar actos de comunicación, así ellos pueden pasarse entre sí, mensajes semánticamente significativos para realizar la TAN o lograr un objetivo específico. Estos actos de comunicación son codificados en un Lenguaje de Comunicación de Agentes (ACL - Agent Communication Language) que impone un conjunto mínimo de requerimientos en el servicio de transporte de mensajes. La estructura de un mensaje es la siguiente: Tabla 3-5 Estructura de un mensaje según FIPA Mensaje

Nombre del mensaje o identificador

Emisor Receptor Contenido

Nombre del agente que manda el mensaje Nombre del agente que recibe el mensaje Componente de la comunicación que se refiere a un dominio en un lenguaje ACL

El ACL posibilita la comunicación entre los diversos agentes en una forma que les permita derivar semánticamente información útil sin requerir un acuerdo a priori sobre el lenguaje usado en la comunicación [Fip01b]. Esto se logra a través de la combinación de tres aspectos: • • •

Un rango de tipos de mensajes, Una serie de notaciones en las cuales las expresiones lógicas, acciones y objetos pueden ser expresados. El uso de ontologías referenciadas explícitamente que le permiten al agente interpretar los identificadores en una comunicación relacionada con una o más interpretaciones compartidas de esos indicadores.

CommonKADS-RT – Capítulo 3. CommonKADS-RT

3.6.5.1

133

Formularios del modelo de comunicaciones

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

Descripción de transacción Hoja de Trabajo CM-1

Nombre / Identificador de la transacción

Una transacción es definida para cada objeto de información que es producido (salida) en algunas de las actividades de una TAN o en las funciones de transferencia del modelo de conocimientos, y que tiene que ser comunicado a otro agente para utilizarlos en sus propias tareas. El nombre tiene que reflejar, en una forma entendible por el usuario, lo que la transacción hace con ese objeto de información. En adición al nombre se debe dar una breve explicación del propósito de la transacción Indicar el objeto de información (núcleo) y entre cuál par de TAN es que va a ser transmitido Indicar el agente que envía y el agente que recibe el objeto de información Indicar el plan de comunicación del cual es componente la transacción 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 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.

Objeto de Información Agentes involucrados Plan de Comunicación Restricciones

Especificación del intercambio de información

Formulario 3-12 CM-1: Especificación de las transacciones que posibilitan el diálogo entre dos agentes en el modelo de comunicación

Por lo tanto, es la especificación de los mensajes que se envían / reciben los agentes. • CM-2: Especificación del intercambio de información dentro del SBCTR Modelo de Comunicación

Especificación del intercambio de información Hoja de Trabajo CM-2

Nombre / Identificador de la transacción Agentes involucrados

Dar el identificador y nombre de la transacción

Ítem de Información

Indicar el agente que envía la información y el que la recibe. Remitente (agente-1) Receptor (agente-2) 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 agenteagente, por ejemplo, ventana pop-up, navegación y selección dentro de un menú, interfaz de comandos, intervención humana.

CommonKADS-RT – Capítulo 3. CommonKADS-RT

Especificación de Mensajes

Control sobre los mensajes

134

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

CommonKADS-RT – Capítulo 3. CommonKADS-RT

2.

Identificación de la plataforma de implementación, es decir el hardware y software que deben ser usados en el SBCTR.

3.

Especificación de los componentes de la arquitectura definida.

4.

Especificación de la aplicación dentro de la arquitectura, relacionando los modelos del análisis –conocimientos y de comunicaciones – con la arquitectura del SBCTR

Arquitectura del sistema En cuanto a la arquitectura del sistema, ésta se describe a través de varios elementos: •

Una descomposición del SBCTR en subsistemas y módulos

•

Un régimen completo de control por medio del cual los subsistemas interactúan. Al igual que ocurre en las metodologías más completas, en CommonKADS-RT se propone una arquitectura especialmente diseñada para un SBCTR, llamada ARTIS (An Architecture for Real-Time Intelligent Systems) [Gar96], [Bot00]. ARTIS constituye una extensión del modelo blackboard (memoria global estructurada que contiene objetos del espacio de solución) adaptado para entornos de tiempo real estricto. En ella se combinan y potencian las ventajas de la inteligencia artificial (su flexibilidad) y de los sistemas de tiempo real (su predecibilidad). Un sistema ARTIS debe tener funcionalidades de:

Percepción

Cognición

Acción

Figura 3-11 Bases de ARTIS Percepción: adquisición e interpretación de datos de sensores para obtener el conocimiento de las entidades externas que definen el mundo exterior. Cognición: razonamiento basado en el conocimiento para evaluar situaciones, resolver problemas y determinar acciones a adoptar. Por lo tanto, están los componentes de software que deberían realizar las funciones, los datos, la información y el conocimiento del dominio. Acción: se ejecutan las acciones deseadas que influyen sobre las entidades externas. Estas funcionalidades pueden ser conseguidas basando el diseño del sistema en la arquitectura global percepción / cálculo / acción, como en muestra en la Figura 3-12.

136

CommonKADS-RT – Capítulo 3. CommonKADS-RT

ENTORNO

Tareas de percepción

Tareas inteligentes

Tareas actuadoras

PLANIFICADOR DE TAREAS

Figura 3-12 Arquitectura global de un SBCTR

•

Donde: Las tareas de percepción proporcionan una interfaz de comunicación entre las entidades externas y el sistema.

•

Las tareas inteligentes interpretan los eventos provenientes de las tareas de percepción y realizan el razonamiento y la resolución de problemas. Estas tareas calculan acciones físicas que deben ser ejecutadas sobre el entorno exterior.

•

Las tareas actuadoras transmiten las soluciones calculadas por las tareas inteligentes al entorno exterior.

•

El planificador de tareas es el responsable de planificar todas las tareas del sistema garantizando sus restricciones temporales.

Es importante resaltar que para poder adaptar el modelo de blackboard a un entorno de tiempo real, es necesario conocer el tiempo de ejecución de todas las tareas críticas que integran el sistema. La definición de los conceptos básicos de la arquitectura se hace en el Formulario 3-14 DM-1: Descripción de la arquitectura del sistema al que se le han adicionado algunos conceptos importantes para completar la guía de lo que debe ser la arquitectura y los detalles deben ser dados por ARTIS.

Plataforma de implementación Este aspecto del diseño se refiere a la determinación de las bibliotecas que se pueden utilizar en la construcción del SBCTR, incluyendo las librerías de CommonKADS para las tareas generales. También es importante elegir la forma para representar el conocimiento, las interfaces con otro software, el lenguaje de desarrollo, entre otras. El resultado de este proceso es un modelo de componentes. Junto a ARTIS, se tiene InSiDE (Integrated Simulation and Development Environment) un entorno de desarrollo visual para agentes basados en la arquitectura de

CommonKADS-RT – Capítulo 3. CommonKADS-RT

137

agente [JGR+00]. Su objetivo principal es permitir que el usuario especifique un sistema en términos del modelo propuesto por la arquitectura y obtener una compilación del mismo para su ejecución sobre RT-Linux. InSide ha sido implementado en JAVA, debido a la portabilidad entre plataformas que ofrece dicho lenguaje. Con esta herramienta se especifican las creencias y el conocimiento de resolución, estructurados jerárquicamente, que forman el modelo de usuario del sistema en desarrollo. Las principales características que proporciona InSiDE son las siguientes: •

Mecanismos de reutilización: los comportamientos implementados pueden ser usados por diferentes in-agents.

•

Implementa un test de planificabilidad (deadline monotonic schedulability test) para verificar que el sistema cumplirá las restricciones temporales a las que está sujeto.

•

Obtienen una simulación del comportamiento en ejecución del sistema en desarrollo. La simulación permite, por un lado, observar la evolución del sistema por medio de un cronograma, y por otro obtener resultados sobre la ejecución del mismo, que posibilita evaluar diversas características de la especificación (calidad, carga crítica, etc.)

•

Permite incluir conocimiento procedural contenido en bibliotecas externas.

•

Permite definir un conjunto de controles visuales que facilita la monitorización del sistema durante su ejecución.

El objetivo final de InSiDE es facilitarle al usuario una visión de alto nivel de la arquitectura, permitiendo la abstracción de los detalles de la interfaz de programación. InSiDE obtiene un modelo ejecutable del sistema a partir de un proceso de traducción de la información introducida por medio de la interfaz. Este modelo de sistema se compone tanto de los archivos que implementan la arquitectura como de los archivos generados por InSiDE que efectúan el sistema en desarrollo. Todo ese conjunto de archivos se compila desde la herramienta para obtener un módulo ejecutable sobre RT-Linux. El Formulario 3-15 DM-2: Especificación de las facilidades ofrecidas por y en el sistema que será implantado permite definir atributos y características adicionales a la plataforma. Adicionalmente, se establece una tabla en donde deben identificarse los componentes que pueden formar el SBCTR. Tabla 3-6 Especificación de los componentes del SBCTR Componente

Descripción

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

138

CommonKADS-RT – Capítulo 3. CommonKADS-RT

En forma gráfica estos componentes se pueden definir utilizando la notación de componentes, presentada en la sección 2.3.4.2 de la página 72. Un ejemplo es el que a continuación se presenta en la Figura 3-13, relacionado con la aplicación del robot, presentada en el capítulo 4.

Aplicación ARTIS Componente de la interfaz de usuario

Robot Radio Ethernet

Microcontrolador Siemens 88C166

Señal cable Componente de comunicación Componente de planificación

RS232 C

Sensores Batería VDC Motor

Componente de control inteligente

VDC

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.

139

CommonKADS-RT – Capítulo 3. CommonKADS-RT

o

no observable. Información deducida a partir de la información de los sensores en el proceso de razonamiento, cuya validez no se puede contrastar directamente desde el exterior.

−

Según su procedencia: o de entrada. o interna o de salida

−

Según su estado temporal: o actual o pasada o futura

El proceso de razonamiento basado en el modelo blackboard temporal establece que la solución debe construirse en forma incremental, utilizando tanto información actual como futura. Cualquier paso de razonamiento puede aplicarse en cada una de las etapas de formación de la solución. De esta forma, la secuencia de construcción de la solución es dinámica y sigue un modelo de razonamiento oportunista (aplicar el conocimiento adecuado en el momento oportuno). •

Conocimiento de resolución de problemas: relativo a los métodos para resolver problemas del dominio, para hacer el razonamiento. En términos de CommonKADS es el conocimiento de inferencia y conocimiento de la tarea. La topología de ARTIS se presenta en la siguiente Figura 3-14: AA In-agent 1

In-agent 2 ...

In-agent n

MKS 1.1 MKS 1.2 ... MKS 1.m ... KS 1.1.1 KS 1.1.2 ... KS 1.1.p

Figura 3-14 Topología de ARTIS Donde: − AA es un agente ARTIS que representa un agente físico, que es autónomo, reactivo, y tiene continuidad temporal. Está compuesto por una serie de métodos para el manejo de sensores y actuadores, un módulo de control que se responsabiliza por la ejecución de tiempo real de cada uno de los componentes del AA, y un servidor inteligente que se encarga de producir respuesta de muy buena calidad en caso de que tenga tiempo suficiente para hacer el razonamiento. −

Un agente interno (IA – In-Agent) que es una entidad interna que posee el conocimiento necesario para solucionar un problema en particular, a distintos niveles de abstracción y el método que se aplica depende del tiempo que tenga

CommonKADS-RT – Capítulo 3. CommonKADS-RT

140

disponible el sistema para razonar antes de proporcionar una respuesta al entorno. Este conocimiento puede incorporar técnicas de inteligencia artificial. Un inagent se caracteriza por un comportamiento periódico, es una tarea específica y dispone de un plazo máximo de ejecución, deadline. −

Una fuente de conocimientos múltiple (MKS - A Multiple Knowledge Source) que implementa el concepto de los algoritmos anytime y multiple methods, dando diversas soluciones al mismo problema con diferente tiempo de cómputo y diferente nivel de calidad. Así, se permite acotar el tiempo de cómputo para el caso peor de las entidades especificadas sin necesidad de, a priori, podar las funcionalidades de las técnicas de IA utilizadas. Estas técnicas, por su propia naturaleza, tienen tiempos de cómputo no limitados o poco realistas, pudiendo utilizar técnicas de IA en la resolución de problemas de tiempo real críticos. Para poder garantizar su planificabilidad es necesario conocer los tiempos de respuesta en los peores casos de las entidades en ejecución que los constituyen. El MKS agrupa varios niveles de fuentes de conocimiento y puede ser interrumpida en cualquier momento devolviendo la solución del último nivel que se haya ejecutado en forma completa. Los diferentes niveles de un MKS resuelven el mismo subproblema pero aportando cada uno de ellos una visión distinta de esta resolución, bien sea porque se implementan métodos múltiples, o porque se realizan diferentes refinamientos del mismo método.

−

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

KS de percepción cuando realiza operaciones de entrada, entonces leerá los valores de variables observables a través de sensores.

o

KS de cognición cuando hace operaciones de razonamiento e inferencia, operará sobre valores observables, no observables e internos calculando valores de variables internas, de salida o no observables.

o

KS de acción cuando sus operaciones son de salida. Actuará sobre el mundo mediante actuadores a partir de los valores de las variables de salida previamente calculadas.

La arquitectura propone un modelo de entidades de alto nivel para especificar un agente inteligente en tiempo real y un modelo del sistema para definir las entidades de bajo nivel y las tareas ejecutables.

CommonKADS-RT – Capítulo 3. CommonKADS-RT

•

141

Conocimiento de control: conocimiento sobre el conocimiento. Es el conocimiento de la tarea.

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

Aplicación en la arquitectura Este aspecto del diseño se relaciona con llevar a cabo los modelos del análisis, en especial el modelo de conocimientos (las tareas, inferencias, bases de conocimiento) y del modelo de comunicaciones (las transacciones). Para esto se utiliza el Formulario 3-17 DM4: Decisiones del diseño de la aplicación. Para el SBCTR se debe definir también lo relacionado con el test de planificabilidad off-line, el análisis de garantías de acuerdo con una política de planificación definida. Este análisis se hace cuando ya el sistema está construido y terminado. Es obligatorio hacerlo para las partes críticas con el objetivo de verificar los wcet. Si el test dice que no se cumplen los tiempos, entonces pueden suceder varias cosas: •

Se ajustan o rebajan las restricciones temporales.

•

Se vuelve a la fase del análisis o al comienzo del diseño.

CommonKADS-RT – Capítulo 3. CommonKADS-RT

3.6.6.1

142

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 Tipo de arquitectura Tipo de SBCTR

Descripción de los conceptos y características más relevantes de la arquitectura escogida. Por ejemplo, ARTIS es una arquitectura blackboard Qué tipo de SBCTR se va a construir con el objetivo de definir sus componentes y módulos. Número y tipos de procesadores

Especificación de los procesadores Estructura del Subsistema Modelo de Control

Descomposición del subsistema

Hace referencia al diagrama con todos los subsistemas. Puede ser un modelo cliente – servidor o de máquinas abstractas. Caracterización del régimen de control de todo el sistema. Por ejemplo, orientado a eventos, con control centralizado, modelo de llamada - retorno. 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 Paquete de Software Compatibilidad del software Sistema operativo

Plataforma de implantación Hoja de Trabajo DM-2

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

CommonKADS-RT – Capítulo 3. CommonKADS-RT

143

¿Soporta un enlace con una herramienta CASE para el análisis de CommonKADS, por ejemplo leer descripciones en el modelo de conocimientos y el modelo de comunicación?

Formulario 3-15 DM-2: Especificación de las facilidades ofrecidas por y en el sistema que será implantado

• DM-3: Especificación de la arquitectura del SBCTR Modelo de Diseño

Especificación de la Arquitectura Hoja de Trabajo DM-3

Controlador

¿Cuáles son los mecanismos para el manejo de eventos internos / externos? ¿Concurrencia? ¿Posibles interrupciones? ¿Cómo es el control del usuario frente a la estrategia de razonamiento? ¿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? ¿Cómo se manejan los eventos internos del SBCTR? ¿Cómo se manejan los eventos externos? Especificar la política de planificación de las tareas del SBCTR.

Cómo es la Tarea de tiempo real Eventos externos e internos Métodos para hacer la planificación de las TTR Determinación de los wcet Rol dinámico Rol estático Modelo del dominio Acciones del SBCTR

Vistas

Para las TTR especificar sus wcet – worst computer execution time Tipos de datos para los roles. Operaciones de acceso / modificación para cada tipo de datos Definir las operaciones de acceso: ¿Darlo - todo, dar - uno, existe - uno? Decidir acerca de la representación de las instancias de reglas. Definir los métodos de acceso y de modificación. ¿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? ¿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 Controlador

Decisión del Diseño

Método de la tarea Inferencia Roles dinámicos Métodos de inferencia Modelo del dominio Objetos de la vista

Traducir el control del plan de comunicación mas las transacciones en los manejadores de eventos Formalizar la estructura de control Escribir una especificación de la invocación de un método de inferencia Escoger un tipo de datos para cada rol, restringiéndolos a los provistos por la arquitectura. Especificar o seleccionar los métodos de inferencia Traduzca las instancias del modelo del dominio en un formato que los represente y que esté provisto por la arquitectura Seleccione las vistas apropiadas para el modelo de la aplicación y los objetos de control

CommonKADS-RT – Capítulo 3. CommonKADS-RT

Protocolos de comunicación

144

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

CommonKADS-RT – Capítulo 3. CommonKADS-RT

− •

Debería proporcionar la información que se requiere para llevar a cabo un test de planificabilidad.

Contenido del MTTR: El contenido de este modelo está dado por los elementos del modelo y sus relaciones. Se puede apreciar en la Figura 3-15.

Modelo de Conocimientos Diseño detallado

Modelo de Diseño

Modelo de Agentes

Modelo de Conocimiento

Agente

Arquitectura hace parte de

implementa

ejecutada por

implementada en Modelo de TAN

Modelo de Comunicaciones

Tarea de Tiempo Real implementa realizada en

TAN

período deadline wcet

Transacción

tiene

Es parte de Tipo TTR

Es parte de Parte_inicial

Es parte de

Parte_final

Parte_opcional

Figura 3-15 Contenido del Modelo de Tareas de Tiempo Real

•

Estados del MTTR: Los estados de este modelo están dados por las diferentes etapas en que él puede estar. De esta forma se han identificado los siguientes: −

Empieza con la identificación de los componentes de la TTR. En este estado se tipifican las partes iniciales, opcionales y finales de la tarea de tiempo real.

−

Especificación de las variables temporales de los componentes. Se refiere a la determinación numérica (cantidad de tiempo) que tienen asociadas cada uno de los componentes de la tarea.

−

Ejecución del test de planificabilidad. Es la ejecución del sistema con el objetivo de ver el cumplimiento de los tiempos definidos en las TTR.

CommonKADS-RT – Capítulo 3. CommonKADS-RT

− •

•

146

Aprobación del test. En caso de que se cumplan las restricciones temporales, que el plan sea efectivo, entonces se termina este modelo.

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

Realizada en: Establece la relación entre el modelo de tareas de tiempo real y el modelo de tareas de alto nivel para especificar a qué TAN pertenece la TTR.

−

Tiene: Es una relación entre dos componentes del modelo, específicamente entre la TTR y su tipo, en donde este último establece si la TTR es periódica, esporádica o aperiódica.

−

Es parte de: Es la relación de agregación, en donde se establece que la parte inicial, la opcional y la final forman parte de la TTR.

−

Implementada en: Es una de las relaciones entre el modelo de TTR y el modelo de diseño, para decir que la TTR se construye en la arquitectura que se ha definido en modelo de diseño.

−

Hace parte de: Es otra de las relaciones con el modelo de diseño, para definir que el modelo de TTR es parte del modelo de diseño.

−

Ejecutada por: Establece la relación entre el modelo de TTR y el modelo de agentes para referirse al responsable de la TTR.

−

Implementa: esta relación está fijada entre el modelo de TTR y el modelo de comunicaciones y también entre el modelo de TTR y el modelo de conocimientos. En el primer caso es para expresar la dependencia que hay entre una transacción y una TTR, la segunda es para relacionar la implementación del conocimiento.

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

Confirmando lo presentado en el modelo anterior, la fase del diseño puede ser descompuesta en tres categorías básicas: •

El diseño de la arquitectura, en donde se detalla la estructura del software en términos de subsistemas, paquetes y tareas.

147

CommonKADS-RT – Capítulo 3. CommonKADS-RT

•

El diseño mecánico, incluye el diseño de los mecanismos compuestos de clases que trabajan juntas para alcanzar un objetivo común.

•

El diseño detallado para especificar las estructuras de datos primitivas a un nivel interno y los algoritmos particulares.

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

Componente 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

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

148

CommonKADS-RT – Capítulo 3. CommonKADS-RT

no es predecible o no puede ser garantizado por una política de planificación por ser tan grande. Refina la solución inicial o proporciona una solución alternativa. •

La parte final es obligatoria e incluye las acciones expresadas en KS de acción. Tiene un tiempo de cómputo predecible.

MKS percepción KS0

MKS1 cognición KS0 KS1 KS2

MKS2 cognición KS0

Inicial Obligatoria

MKS acción

KS0

Opcional

KS0 KS0 KS0

KS1 KS2

Final Obligatoria KS0

TTR con deadline y wcet

Figura 3-17 Ejemplo de un in-agent

Así, se debe garantizar la planificabilidad de las partes iniciales y finales de cada inagent 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)

CommonKADS-RT – Capítulo 3. CommonKADS-RT

149

(importance int) (method Multiple | Refinament)) KS

à

(defks name (lista_tipo_parametros) (wcet int (codefile string))

Desde el punto de vista de tiempo real para planificar el sistema, se asume que el inagente 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 inagents se garantizará mediante un análisis off-line del mismo, que la parte obligatoria y final de todos ellos se ejecutará antes de su plazo máximo de realización, ejecutándose, si es posible, las partes opcionales de cada tarea en el tiempo re procesador disponible entre la finalización de la parte obligatoria y el inicio de la parte final. Este tema es muy importante para todo SBCTR pero queda fuera del alcance de esta investigación, será parte de los trabajos futuros. También, como parte del diseño detallado se deben especificar los objetos a escala individual, es decir que se deben especificar en forma de algoritmos o SBC cada uno de los KS que forman parte del MKS, incluyendo la definición de todos los atributos de la aplicación en términos de los tipos primitivos de datos provistos por el lenguaje de implementación.

3.6.7.1

Formularios del modelo de tareas de tiempo real

• RTT-1: Especificación de las TTR Para este modelo se ha propuesto un formulario que refleja los componentes de la TAN y sus características Formulario 3-18 Especificación de las tareas de tiempo real: La información contenida en este formularios servirá para plantear las pruebas de planificación, lo cual además puede ser complementado con la utilización de los diagramas de tiempo concurrentes. Modelo de tareas Especificación del modelo de tiempo real Hoja de Trabajo RTT-1 TTR-1

TTR-2

Parte inicial Parte opcional Parte final Período Deadline Wcet Parte inicial Parte opcional Parte final Período Deadline

CommonKADS-RT – Capítulo 3. CommonKADS-RT

150

Wcet .

Formulario 3-18 Especificación de las tareas de tiempo real

3.6.7.2

Artefactos del modelo de TTR

Los resultados obtenidos al realizar ese modelo se expresan en el diseño detallado del sistema, la especificación de las TTR y la determinación de sí se cumple o no el test de planificabilidad. Igual que en los demás, se tiene la documentación de las actividades realizadas, de las pruebas y de las incidencias posibles.

3.6.7.3

Roles en el modelo de tareas de tiempo real

Son los mismos que participan en el modelo del diseño.

3.7

Conclusiones de CommonKADS-RT

CommonKADS-RT, es la adecuación de técnicas de desarrollo de sistemas basados en el conocimiento y de técnicas para el desarrollo de sistemas de tiempo real con el propósito de facilitar la gestión y la construcción de sistemas basados en el conocimiento de tiempo real. Son consideraciones metodológicas para el desarrollo de ese tipo de sistemas. Sus objetivos principales son: Incrementar la calidad del producto final, mejorar la repetibilidad y predecibilidad del trabajo de desarrollo del SBCTR, y disminuir el esfuerzo para desarrollar el producto final en el nivel requerido de calidad. Para ello, CommonKADS-RT incluye lo siguiente: •

Una descripción de las actividades que se llevan a cabo en la construcción de un SBCTR. Es decir, propone las etapas o fases para llevar a cabo desde el estudio del problema hasta el diseño de la solución de sistema basado en el conocimiento de tiempo real.

•

Especifica los componentes o artefactos resultantes de dichas actividades.

•

Define el orden en el cual éstas deben ser ejecutadas, lo que se conoce como el ciclo de vida.

•

Establece los roles o el perfil de cada uno de los que participa en las diferentes etapas de desarrollo del proyecto de desarrollo del sistema basado en el conocimiento de tiempo real.

•

Propone una arquitectura robusta para la implementación del SBCTR

•

Permite llevar hasta el software del sistema, planteando incluso la realización del test de planificabilidad.

CommonKADS-RT – Capítulo 4. Validación a través de casos

151

Capítulo 4. Validación experimental de CommonKADS-RT a través de casos 4.1

Introducción

En este capítulo se presentan dos escenarios en los que se quiere demostrar la aplicación de CommonKADS-RT. El primero de ellos es acerca del proceso de la operativa marítima que se realiza en la terminal de contenedores de la empresa Marítima Valenciana que atiende el puerto marítimo de la ciudad de Valencia, España. El segundo refleja la situación de tener un robot móvil navegando por un micro mundo especial.

4.2

Tipos de casos

4.2.1

Escenario de la operativa marítima del Puerto Príncipe Felipe de Valencia

Este escenario está enmarcado en una empresa real en donde se presentan procesos importantes que requieren el manejo del conocimiento bajo consideraciones temporales. Es un caso muy importante por su complejidad, delicadeza y por el impacto que podría tener una solución basada en conocimiento de tiempo real. Para esta investigación también es trascendental porque permite aplicar la metodología CommonKADS-RT a un caso de estas características y que además permite ver que los modelos de la metodología pueden ser usados para representar propuestas para el futuro, pues en este caso se realizó la fase de análisis pero no se llegó a la del diseño por decisiones tomadas por una de las gerencias involucradas en el proceso de actualización y adecuación tecnológica que está viviendo la compañía en estos momentos. De todos modos, es de gran valor el estudio realizado y faculta que, con pequeñas actualizaciones, pueda ser utilizado posteriormente cuando se tengan las condiciones para implantar SBCTR.

CommonKADS-RT – Capítulo 4. Validación a través de casos

4.2.2

152

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

Este escenario se ha desarrollado para validar la metodología CommonKADS-RT, la arquitectura ARTIS y el software de desarrollo InSiDE en un caso especial, que no está relacionado con un problema específico de una organización, sino que es un problema que se diseñó específicamente para esta investigación. Para ello se creó un micro mundo en donde un robot es controlado por un SBCTR que sabe cómo navegar en un mundo cerrado, puede identificar un objeto por su forma básica y puede moverlo o transportarlo. Este caso, es una situación particular dado que algunos de los planteamientos de la metodología en la fase de análisis no será necesario analizarlos. Se incluye también la fase de diseño de la aplicación que se ha construido para este propósito.

4.3

Terminal de contenedores en el puerto de Valencia

Desde hace un tiempo se viene desarrollando en forma conjunta, entre la Empresa Marítima Valenciana y la Universidad Politécnica de Valencia, un proyecto en donde se han estudiado diferentes áreas de dicha empresa con el fin de plantear soluciones a problemas específicos o mejoras a través de soluciones informáticas. Es así, como se ha venido trabajando en dos áreas prioritarias para el buen funcionamiento del Puerto Príncipe Felipe de Valencia: Las Operaciones Terrestre y las Operaciones Marítimas. En esta última es que se ha aplicado la metodología CommonKADS-RT con el objetivo de identificar posibles procesos que pueden mejorarse con la inclusión de un sistema basado en el conocimiento de tiempo real. Para ello, se han realizado múltiples reuniones con personal especializado en cada una de las tareas que se realizan en esta unidad y se ha compartido información pertinente al proceso. El objetivo de este caso es el siguiente: “Con este análisis pretendemos conocer en forma detallada el proceso de las Operaciones Marítimas para plantear soluciones informáticas a situaciones que requieran un uso intensivo de conocimiento bajo restricciones de tiempo”.

4.3.1

Modelo de la organización

Directamente, se presentarán los resultados obtenidos al aplicar cada uno de los formularios planteados en CommonKADS-RT.

4.3.1.1

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

El ambiente organizacional no se requiere analizar en detalle porque en este caso previamente se había definido e identificado el área en donde se presentan los problemas o en donde se requiere hacer una mejora a los sistemas existentes, siendo ésta la unidad de Operaciones Marítimas. Es allí en donde se debe realizar el estudio de viabilidad de aplicar

CommonKADS-RT – Capítulo 4. Validación a través de casos

153

un SBCTR para hacer algunas de sus tareas. Por lo tanto, de este formulario solamente se presentará la información relacionada con el Contexto de la Organización [BRH00]: La empresa Marítima Valenciana S.A. forma parte de grupo de empresas Dragrados de España y se encarga de manejar todo el tránsito de mercancías del Puerto de Valencia. Cuenta con un equipo humano compuesto por 260 personas, con un alto nivel profesional y su política de RR.HH. está recogida en los compromisos y valores definidos por su propia plantilla. Marítima Valenciana S.A. ofrece a sus clientes un servicio integral puerta a puerta de transporte para sus productos, contando para ello con las tecnologías más avanzadas y con una estructura de empresa flexible, dinámica, eficiente y con calidad contrastada, donde destaca su equipo humano altamente cualificado y profesional. En términos generales las funciones de la empresa giran alrededor de la operación marítima y la operación terrestre. Para la Operación Marítima se cuenta con un muelle cuya longitud es de 1500 m, que se ampliará hasta 1900 m y con 9 (+2 en construcción) grúas. Se trabaja en forma continua al día, 360 días al año. La unidad Operaciones Terrestres opera en un horario diferente pero también con un rango muy amplio.

Visión: Ser el mejor Terminal Marítimo del Mediterráneo. Lo cual está trabajando a través de un proyecto de Calidad en compañía de las autoridades portuarias.

Como el área Operaciones Marítimas es compleja y en ella se realizan diversos procesos, en donde si no se tiene la información apropiada, real y en el momento preciso, se puede demorar la atención de un barco, entonces se necesita hacer la caracterización de los problemas que son intensivos en conocimientos y que manejan especificaciones temporales, lo que se detallará a través de los demás formularios. Se han identificado algunas debilidades, muchas oportunidades, diversas fortalezas y algunas amenazas también. Para efectos de esta memoria, sólo se incluirán las que se consideran más relevantes: •

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

•

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

•

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

•

Una de sus amenazas es que debe competir contra otros puertos que tradicionalmente han sido mucho más “conocidos” y “grandes”. Esto obviamente también se puede ver como una oportunidad.

CommonKADS-RT – Capítulo 4. Validación a través de casos

154

Después de hacer una análisis detallado y de realizar diversas discusiones con expertos en operaciones marítimas se concluyó que uno de los problemas que se debe solucionar más prontamente, tiene que ver con el hecho de registrar el conocimiento específico de las tareas que ellos realizan. Esto evitará su perdida, permitiría que se pueda replicar, transmitir y generar así, la memoria corporativa de la empresa. La operativa marítima es una de las actividades más prioritaria dentro de la empresa, en donde ser realizan procesos complejos, difíciles de determinar como pasos porque presentan una variedad grande de posibilidades que se pueden dar en una situación específica, y porque la mayoría de los procesos requieren de un conocimiento que es dado por la experiencia, por el trabajo del día a día. El tiempo en el que se realizan las tareas es muy importante porque se quiere que el barco sea atendido lo más rápido posible para que esté el menor tiempo en el muelle y porque los índices de productividad están en relación directa con el manejo de los recursos en función del tiempo, lo que hace que éste sea un concepto relevante. A continuación se presenta el análisis de la operativa marítima con detenimiento.

4.3.1.2

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

En este documento quedarán consignados los aspectos más relevantes de la operación marítima de la empresa Marítima Valenciana S.A.

1) Estructura: La empresa tiene un organigrama en forma jerárquica, que tiende a ser una estructura plana. Ver Figura 4-1.

155

CommonKADS-RT – Capítulo 4. Validación a través de casos

Estructura de la Empresa Marítima Valenciana S.A. Presidencia Vicepresidencia Director General

Administración Financiera

Recursos Humanos y Servicios Jurídicos

Comercial

Tecnologías Informáticas

Sistemas

Análisis y programación

Explotación

Operaciones Terrestres

Operaciones Marítimas

Operación RIBA

Mantenimiento

Planificación

Figura 4-1 Organigrama de Marítima Valenciana Comunicaciones

Secuenciación

CommonKADS-RT – Capítulo 4. Validación a través de casos

156

Como se explicó anteriormente, de esta organización nos centraremos en la parte relacionada con las Operaciones Marítimas, cuyo objetivo es atender las necesidades de los barcos que atracan en el Muelle Príncipe Felipe de Valencia.

Organigrama Operaciones Marítimas

Operaciones Marítimas

Operaciones RIBA

Planificación

Comunicaciones

Secuenciación

Figura 4-2 Organigrama de Operaciones Marítimas

Para describir lo que en ella se realiza, se presenta un bosquejo del proceso:

2) Proceso: El proceso que se realiza en las Operaciones Marítimas está descrito en el documento PR.09.01 del 15 de abril de 1999. Ver Figura 4-3.

Armador

Comunicaciones

Secuencias

Operativa de RIBA

Figura 4-3 Vista general de atención a un buque en el puerto de Valencia Donde: Indica la unidad organizacional de las Operaciones Marítimas que está

CommonKADS-RT – Capítulo 4. Validación a través de casos

157

involucrada en el proceso de atención del barco. Representa entidades que no pertenecen a la empresa Marítima Valencia pero que participan en el proceso Indica el fin del proceso Indica la dirección en que se lleva a cabo el proceso. El Armador es el representante de la empresa que maneja el barco. En este caso está por fuera de los niveles de la empresa Marítima Valenciana.

Especificando más el proceso que se realiza al interior de las Operaciones Marítimas, entonces se presenta un diagrama de actividades de UML en la Figura 4-4. Operaciones Marítimas

Operaciones Terrestres

Atención

Scheduling

Planificación

Reserv. Espacio y Preparación transbordos

Operativa Marítima

Apoyo terrestre

Despacho

Figura 4-4 Diagrama de Actividades de los procesos que se realizan en la Operaciones Marítimas

Donde:

CommonKADS-RT – Capítulo 4. Validación a través de casos

158

•

Atención se refiere al proceso que se realiza cuando el Armador hace contacto con la empresa Marítima Valenciana S.A. con el fin de solicitar un servicio de carga o descarga en el Puerto Príncipe Felipe de Valencia. Por lo tanto, en este proceso se hace la búsqueda de la información de barco o el registro de la misma en caso de ser un servicio solicitado por primera vez. Este proceso es llevado a cabo por Comunicaciones que son los que tienen la relación con el Armador.

•

Scheduling se refiere al proceso de la planeación de las actividades de la operativa marítima y de la asignación de los recursos necesarios para llevar a cabo el plan definido. Este proceso es llevado a cabo por el Jefe de Planificación.

•

Planificación se dedica a la elaboración de las secuencias de carga y descarga de los barcos, realizado por secuenciación.

•

Operativa Marítima se relaciona con todas las actividades y acciones que se llevan a cabo para cumplir con la carga o descarga del barco. Realizado por las Operaciones de Riba.

•

La reserva del espacio, preparación de transbordos y apoyo terrestre son tareas de Operaciones Terrestres. Por lo tanto en este análisis no se detallarán. Desde el punto de vista de las Operaciones Marítimas son importantes cuando se presentan conflictos al querer compartir recursos del otro, como en el caso de los transtainer.

•

Despacho. Registra las incidencias que han ocurrido durante la carga y descarga e informa al Armador y al siguiente puerto la situación final del barco cuando abandona el Puerto de Valencia. Es realizada por Comunicaciones y Secuenciación.

3) Personas a) Empresas relacionadas con el proceso de las Operaciones Marítimas: − Marítima Valenciana S.A. − SEVASA (estibadores) − El ARMADOR Gráficamente, las relaciones entre estas empresas son las siguientes:

MARÍTIMA VALENCIANA

es_proveedor_de ARMADOR

Figura 4-5 Relación entre la empresa Marítima Valenciana y el Armador

MARÍTIMA VALENCIANA

es_cliente_de SEVASA

Figura 4-6 Relación entre la empresa Marítima Valenciana y Sevasa

CommonKADS-RT – Capítulo 4. Validación a través de casos

159

b) Personas que están directamente involucradas en esta operación: − El personal de MARÍTIMA VALENCIANA o Jefe de Operaciones Marítimas o Jefe de Planificación o Personal de Comunicaciones. o Secuenciadores −

El personal de la empresa SEVASA o Estibadores o Capataz de mano o Sobordista (forma parte de las manos y define cuáles contenedores) o Clasificador (está en la calle haciendo lo mismo que el sobordista) o Conductor de grúa marítima o Conductor de transtainer o Conductores de camión

Para establecer las relaciones específicas entre las personas de la empresa SEVASA y las áreas de MARÍTIMA VALENCIANA es necesario establecer los roles que integran una mano: − − − − − −

1. Capataz de mano 1. Sobordista 1. Clasificador Varios Estibadores Un Conductor de grúa marítima Uno o varios Conductores de camión

sirve Manos

Operación RIBA

contrata Planificación

Figura 4-7 Relación entre las manos de Sevasa y las unidades de Marítima Valenciana

Conductor transtainer

sirve

Operaciones Marítimas

Figura 4-8 Relación entre el conductor del transtainer y Operaciones Marítimas

−

El personal del ARMADOR o Consignatario o Planner – es el responsable del armador para realizar una rotación del barco a lo largo de sus diversas escalas. Se encarga de planificar la carga, descarga y remociones del barco.

CommonKADS-RT – Capítulo 4. Validación a través de casos

o o

160

Agente Personal del Barco - Marineros

Gráficamente, las relaciones específicas entre las personas del ARMADOR y las áreas de MARÍTIMA VALENCIANA, son las siguientes:

Dice QUÉ Consignatario

Planificación

Figura 4-9 Relación entre el consignatario del Armador y la unidad Planificación

Dice CÓMO Planificación

Planner (Antes de llegar el barco)

Figura 4-10 Relación entre el Planner del Armador y la unidad Planificación

carga o descarga Agente

Secuenciación

Figura 4-11 Relación entre el agente del Armador y la unidad Secuenciación

Capitán solicita_atraque barco

Puerto

Figura 4-12 Relación del Capitán del barco con Marítima Valenciana

comunica_incidencias Primer oficial

Comunicaciones

Figura 4-13 Relación del Primer oficial del barco con Comunicaciones

c) Personas de Soporte: − Operador de la consola del trunking

CommonKADS-RT – Capítulo 4. Validación a través de casos

161

d) Unidades de la empresa Marítima Valenciana que participan en el proceso: − Administración Financiera, hace la facturación. Pero en realidad no tiene que ver en el proceso de las operaciones marítimas. −

Operaciones Marítimas es la responsable y ejecutora del proceso

−

Operaciones Terrestres, presta servicios a las Operaciones Marítimas

−

Recursos Humanos y Servicios Jurídicos, hace la solicitud de la información y contratación de manos, cuando se requiere.

−

Tecnología Informática, da el soporte en la parte de sistemas de información y tecnología informática en especial.

Para resumir la forma como las personas – agentes - se relacionan con los procesos de las Operaciones Marítimas, se presenta el siguiente diagrama de casos de uso de UML, en donde se muestran las funciones que dichos agentes realizan.

Solicitud de servicios

Armador

Planeación de actividades

Comunicador

indica el flujo de conocimiento La secuencia de carga incluye la lista de descarga de operaciones, el plano de descarga de operaciones, la lista de carga para operaciones y el plano de carga para operaciones.

Además, se tiene la siguiente figura que muestra como quedaría el sistema integrado en las Operaciones Marítimas: Operaciones Marítimas

Operaciones Terrestres

Atención

SBCTR Planificación

Scheduling

Reserv. Espacio y Preparación transbordos

Operativa Marítima

Apoyo terrestre

Despacho

Figura 4-16 SBCTR ubicado en las actividades de la empresa Marítima Valenciana

CommonKADS-TR – Capítulo 4. Validación a través de casos

175

Por último, se debe diligenciar el formulario OM-6 que es el resultado del estudio de Viabilidad: •

En cuanto a la viabilidad del negocio y a la del proyecto, sólo se dirá en este documento, que a pesar de que en este momento no se continuará con el planteamiento de soluciones informáticas para la operativa marítima, sino para otros procesos de la empresa, ella está dispuesta en el futuro a asumir los costos de la inversión y considera que el riesgo es mínimo comparado con los beneficios que se pueden obtener. (Esto es información confidencial).

•

En cuanto a la viabilidad técnica: El estudio técnico de este sistema está fundamentado en la aplicación de los criterios de filtrado propuestos por presentados en el anexo 1. Es así, como con base en ellos se determina lo siguiente: El desarrollo e implantación de un sistema basado en el conocimiento de tiempo real que sirva de apoyo en la prestación del servicio de planificación de la secuencia de carga y descarga de contenedores es muy importante para la empresa Marítima Valenciana, ya que permite mejorar la atención del cliente, optimizando la parte operativa del negocio. Adicionalmente, este sistema le facilita a la compañía su posicionamiento en términos de los demás puertos, por tener una tecnología emergente que le ofrece ventajas estratégicas y competitivas. Todo esto hace que toda la organización pueda estar interesada por el desarrollo del proyecto. Una vez el sistema esté operando, se espera que la atención (el tiempo de estancia en el puerto) de los clientes (barcos) se mejore, dando la posibilidad de aumentar también, el número de atendidos, lo cual representa un retorno a la inversión al corto plazo. En cuanto al conocimiento que se requiere para crear dicho sistema, se tiene lo siguiente: los ingenieros del conocimiento han estado trabajando desde hace algún tiempo con información relacionada con el puerto, lo que les permite establecer una comunicación efectiva con los expertos del dominio. Estos expertos son reconocidos por su labor como gestores de tecnologías informáticas, planificadores y programadores de actividades marítimas, tanto en la organización para la cual trabajan, como por sus clientes. Dentro de la organización se tienen otras personas que también son expertas en la materia, cada una en un área diferente, por ejemplo unas son expertas en prestar asesoría para la atención del barco, otras en la programación del atraque de los barcos, y otras en el manejo de los recursos de tierra. Por esto, la organización está interesada en mantener todo el conocimiento relacionado con la prestación de servicio de asesoría de todos sus expertos, para que así dicho conocimiento esté al alcance de todos sus secuenciadores y de cualquier Armador, logrando que se tenga una transferencia efectiva del conocimiento. Por lo tanto, es necesario contar con la tecnología apropiada para guardar o registrar el conocimiento y que sirva a la vez como medio de enseñanza - aprendizaje. En relación con esto último, es importante aclarar que la propuesta de este proyecto incluye el mejoramiento del sistema de información tradicional que maneja las diferentes bases de datos que se relacionan con el barco y su atención,

CommonKADS-TR – Capítulo 4. Validación a través de casos

176

posibilitando la actualización de los datos y del conocimiento del sistema, lo que le permite que sea real en la información que ofrece. Para determinar si el hacer un SBCTR es una buena alternativa en el caso del planificador de la secuencia de carga y descarga, se estudió si el desarrollar un algoritmo era apropiado para ello, dando como resultado que No, por la forma en que los expertos manejan y expresan el conocimiento, ya que trabajan bajo incertidumbre, conocimiento incompleto y algunos supuestos. Cada secuencia es diferente porque depende de la situación del puerto, del tipo de carga, del barco y de los recursos disponibles. Por esto, se decidió que era un problema factible de resolver utilizando las técnicas de adquisición, representación y manejo del conocimiento por medio de la ingeniería del conocimiento. Los expertos expresan su conocimiento por medio de relaciones similares a las reglas de producción, y razonan mediante deducciones análogas al racionamiento hacia delante. En la actualidad el secuenciador hace la secuencia con base en la información que el armador proporciona, la situación del muelle y los recursos disponibles. En algunos casos es necesario que este proceso incluya variables relacionadas con el tiempo que se consume en la toma de decisiones y que implica tiempo de estadía y servicio de barco, el cual debe ser reducido lo más que se pueda. Además, en algunas situaciones dependiendo de la carga, también el tiempo debe ser considerado para la planificación de su atención. En este caso, la tecnología de los sistemas basados en el conocimiento de tiempo real, ofrece grandes ventajas, ya que permite manejar el conocimiento bajo especificaciones temporales en una forma sencilla y completa para el usuario, obviando algunos de los inconvenientes que se presentan actualmente. Por último, es importante analizar aspectos relacionados con los recursos que se requieren tanto para el desarrollo del proyecto como para la implantación del sistema. Los recursos humanos, como se mencionó anteriormente, están disponibles y dispuestos a trabajar en el proyecto. La relación entre los expertos y los ingenieros del conocimiento se ha hecho de la mejor forma posible, facilitando la adquisición del conocimiento. En cuanto al hardware para desarrollo es de propiedad de la Universidad Politécnica de Valencia, lo que le permite trabajar en forma flexible en el proyecto, y la empresa y Marítima Valenciana cuenta con el equipo requerido para implantar el sistema. La herramienta de desarrollo es un producto resultado de un proyecto de investigación realizado en el GTI (Grupo de tecnologías Informáticas del DSIC), además se utilizan lenguajes de uso popular, lo cual simplifica la instalación y ejecución del sistema. Por lo tanto, se concluye que técnicamente es posible y justificable desarrollar un SBCTR para la TAN PLAN, de acuerdo a lo mencionado anteriormente. Además, es posible llevar a cabo su construcción pues se cuenta con los recursos apropiados, es posible establecer la comunicación con las bases de datos existentes y los beneficios que se obtendría podrían darse cuando un Secuenciador lo utilice como apoyo y se evite la diversidad de criterios. •

Planteamiento de alternativas:

CommonKADS-TR – Capítulo 4. Validación a través de casos

•

•

177

−

Es posible que se adicionen sistemas de información para registrar la información en el momento que se realice cada una de las TAN. Para algunas de ellas, sólo es necesario que se tenga el software apropiado que permita acceder a la base de datos y actualizar los datos respectivos, obviamente teniendo preparada la base de datos para ello. Esta alternativa en parte les mejora el proceso, en relación con la actualización y vigencia de la información, pero deja de lado todo el registro del conocimiento, de la experiencia que se requiere para llevar a cabo las TAN.

−

Otra alternativa es tomar medidas organizacionales en donde se determine que es necesario que cada una de las personas involucradas en el proceso debe tener un registro escrito de su conocimiento, de sus experiencias, de los casos típicos en los cuales a trabajado, de los casos especiales, etc. Esta solución implica menos utilización de recursos informáticos, pero exige que se tenga unos modelos estándar que permitan dicho registro y un entrenamiento para el personal en técnicas de representación del conocimiento. Esta alternativa es muy buena, pero no sola. Es decir, debe ser acompañada de otras pues así no mejorará en términos cualitativos el proceso ni en cuanto al tiempo de realización de las tareas. Pero es importante de hacer de todas formas.

−

Hacer el SBCTR que se ha propuesto. Esta es la mejor alternativa, en cuanto a los beneficios (como se mostró en los diversos formularios) que se pueden tener de ella, tanto a mediano como a largo plazo. Incluiría la alternativa anterior. Pero, implica hacer inversiones en tecnología y en la asignación de tiempo para que las personas más idóneas participen en el proceso.

En caso de elegirse la última alternativa, los objetivos de este proyecto y del sistema serán: − Desarrollar una herramienta del software computacional que sirva como asistente en la planificación de la secuencia de carga y descarga del barco, utilizando el enfoque de un sistema basado en el conocimiento de tiempo real. −

Hacer un sistema basado en el conocimiento de tiempo real que permita hacer la consulta de un servicio de la carga y descarga del barco de una manera mucho completa y a tiempo.

−

Lograr descentralizar el conocimiento de los secuenciadores y del jefe de planificación al llevarlo a un sistema que pudiera ser accedido por todos.

−

Tener una base de conocimiento del sistema, que además de prestarle la asesoría al secuenciador, también le servía como herramienta de entrenamiento para las personas que son novatas en el trabajo de las operaciones marítimas.

En cuanto a la viabilidad del negocio y a la del proyecto, sólo se dirá en este documento, que la empresa está dispuesta a asumir los costos de la inversión y consideran que el riesgo es mínimo comparado con los beneficios que se pueden obtener. (Esto es información confidencial).

CommonKADS-TR – Capítulo 4. Validación a través de casos

178

Por lo tanto, se decide que la acción a seguir es: Hacer un prototipo robusto que refleje el comportamiento de la planificación de la secuencia de carga, el cual servirá para determinar si luego se debe crecer e incluso, si es posible automatizar de esta misma forma los procesos en otras áreas.

Como se puede observar, y confirmando lo que se mencionó anteriormente, este es un ejercicio que no se va a llevar a la práctica en el presente y que sirve más para validar la investigación que para aprobación de la alta gerencia. De todos modos, en casos reales en las organizaciones, éste debe ser completado apropiadamente y de una manera estratégica.

4.3.2

Modelo de tareas de alto nivel

Se ha decidido continuar con el análisis conceptual de la TAN Planificación: Esta es una de las tareas que más requiere conocimiento, ya que muchas de las cosas que se analizan tiene que ver con la rutina que se ha tenido y por el funcionamiento mismo. También, cuando las actividades llegan al jefe de operaciones para realizar lo que previamente se planificó, éste puede variarlo y así de acuerdo con su experiencia, determinar por ejemplo la llegada de otro barco, las manos que se requieren y la secuencia de carga. Por lo tanto, en esta tarea también el conocimiento es importante. A continuación se presentan los formularios que precisan la información de esta TAN. Para hacer la descripción refinada de las TAN dentro del proceso objetivo, utilizamos el Formulario 3-8 que se presentó en el capítulo anterior.

Modelo de Tarea de Alto Nivel Tarea de alto nivel Ubicación en la Organización Objetivo y valor

Dependencia /Flujo

Objetos manejados en la TAN

Tiempo y Control

PLAN Operaciones Marítimas, específicamente en la unidad Secuenciación. 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. 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 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. 1. Frecuencia, duración − Para hacer la secuencia de carga y descarga no hay un control de tiempos definido, pues depende de las características del barco y del número de contenedores a mover, pero es posible determinar unos rangos, unos tiempos mínimos y máximos de acuerdo con esas características. − La secuencia de carga y descarga se hace siempre que haya barco en el muelle.

CommonKADS-TR – Capítulo 4. Validación a través de casos

Agentes Conocimiento y Habilidades Recursos

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. Los secuenciadores son los que realizan la secuencia de carga y descarga. Ellos son los responsables. Ver TM-1.1 y las explicaciones siguientes El tiempo es un recurso muy importante en estas actividades. Las manos, los trastainers y las grúas.

Formulario 4-4 TM-1: Descripción refinada de las tareas de alto nivel dentro del proceso objetivo

E.T.A. Bayplan

Gestionar atraque

Situación del barco y del puerto

Programar Carga y Descarga

Lista carga y Lista descarga

Carpeta actualizada

Registrar informació

Secuencia de carga y descarga / Incidencias

Hacer la secuencia de carga y descarga

Figura 4-17 Diagrama de Flujo de la TAN PLAN

Por cada uno de los conocimientos definidos en OM-4 se hace un formulario TM-2. Es decir, para los criterios para la asignación de los barcos, la planeación (secuencia de carga y descarga del barco), el scheduling de recursos (grúas y manos) y actividades, los criterios de optimización de manos y el manejo de incidencias. Luego de hacer el análisis de la especificación del conocimiento empleado en la tarea de planificación y sus posibles cuellos de botella y áreas para mejorar, se concluye lo siguiente: La forma como se hace la secuencia de carga y descarga de contenedores desde y hacia el barco es uno de los conocimientos básicos para realizar la planificación de dicha secuencia. Este conocimiento está relacionado principalmente con el agente jefe de

CommonKADS-TR – Capítulo 4. Validación a través de casos

180

planificación quien es el responsable de realizar la actividad y tiene la experiencia en cuando a la planificación de tareas y recursos (dominio más amplio del conocimiento). La naturaleza de este conocimiento se resume así: es un conocimiento empírico que se aprende en el que-hacer diario y por lo tanto tienen una buena parte de heurísticas generadas durante el proceso y que ha ido pasando de persona en persona durante los últimos años. La experiencia en el manejo del conocimiento y la toma de decisiones en donde se emplea hacen que sea difícil de reproducir y transmitir pues dependerá mucho de la casuística. Hay ciertas variables que afectan el proceso, como son el tipo de barco, el tipo de carga, la empresa del Armador, entre otras. Además, una de sus características es que no está registrado o no hay un proceso escrito de su utilización, por lo que está básicamente en la mente de los agentes que realizan la TAN. Es posible que este conocimiento sea modelado y representado en un sistema informático que refleje técnicas de inteligencia artificial, a través de un SBCTR para que así sea transferido y no sea tan dependiente del responsable. Se permitiría tener el conocimiento en el momento oportuno, en la forma apropiada. Aunque TM-1 es una versión más detallada de OM-3, hemos decidido de todos modos hacer el análisis de las subtareas de PLAN bajo los criterios de ese formularios, llamándolo TM-1.1 (ver formulario 4-6) para mostrar una descripción detallada de esa TAN.

4.3.3

Modelo de agentes

En este sistema hay diferentes tipos de actores: •

Los roles que en MARÍTIMA VALENCIANA tendrá relación directa con la TAN PLAN o se verán afectados por ella, es decir los actores son: − Jefe de Operaciones Marítimas − Jefe de Planificación − Secuenciadores − Comunicadores

•

Los agentes software son los sistemas informáticos que estarían en relación directa con el SBCTR con las Bases de datos y los sistemas Wincasp y Ships, mencionados en la parte de recursos en OM-2. Estos agentes son descritos y trabajados en un proyecto que actualmente se está realizando para la misma unidad de la empresa. No se considera relevante para esta investigación, incluir dicha información en ella.

A modo de ejemplo se presenta el formulario AM-1 para uno de los actores identificados:

CommonKADS-TR – Capítulo 4. Validación a través de casos

Ident. de la TAN

Nombre de la TAN

PLAN.. ATR

Gestionar Atraque

PLAN.. CyD

Programación de carga y descarga

PLAN.. SEQ

Generar secuencia de carga

Tipo de TAN

181

¿Ejecutada ¿En dónde? por?

¿Intensivo en conocimiento?

− Personal de planificación − Jefe de Planificación

Planificación

Alto

Programación − Jefe de Planificación − Personal de Marítima

Planificación

Alto

− Personal de Planificación

Planificación

Muy Alto

Asignación

Planeación

Conocimiento involucrado

¿Es importante para el proceso?

¿Puede tener restricciones temporales?

- Puede definirse el Este proceso es − Historia (puntualidad,..) tipo de tarea según muy importante y − Situación prevista en el la frecuencia como requiere que se día de llegada se realiza. Podría manejen los (conocimiento que es llegar a tener un siguientes incierto) comportamiento − Experiencia en asignación criterios: periódico. − Dar la atención de barcos oportuna a los buques − Maximizar la utilización del muelle - Una vez se va a Tiene que ser − Historia (cómo se ha empezar a atender realizada cargado el barco el barco, deberían apropiadamente. anteriormente) tenerse unos Los criterios que − Situación actual (del tiempos definidos se manejan son: barco, del muelle y del para la carga y la − La optimización puerto) descarga, de de los recursos − Experiencia en acuerdo con el tipo − Minimizar el Programación de de barco, de carga, tiempo de carga actividades y recursos el número de y descarga − Optimización de recursos contenedores, − Evaluación de riesgos entre otros. - Igual que el − Experiencia en planeación Tiene que ser anterior realizada de secuencia de apropiadamente. contenedores Se tratan los − Conocimiento o manejo siguientes de prioridades de acuerdo

¿Es posible introducir un sistema informático en la TAN? Si. Un sistema que tuviera la imagen del muelle y que de acuerdo con las especificaciones y restricciones, permitiera tomar decisiones EN tiempo real

Si. Un scheduler que asignara los recursos necesarios, las manos para cargar y descargar el barco

No. Debe ser realizado manualmente.

CommonKADS-TR – Capítulo 4. Validación a través de casos

182

con los criterios de la TAN y de Marítima Valenciana

PLAN.. REG

Registro de Información (guardar)

(No es − Personal de intensiva en Planificación conocimiento) − 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

criterios: − Minimizar el tiempo de carga y descarga − Impedir bloqueos Es muy importante y también requiere que se haga apropiadamente

Formulario 4-5 TM-1.1: TAN PLANIFICACIÓN (PLAN)

No

Si, un sistema de información que registrar todo en una base de datos.

CommonKADS-RT – Capítulo 4. Validación a través de casos

Modelo de Agente Nombre Ubicación en Organización

Ubicación en TAN Se Comunica con

183

Agente Hoja de Trabajo AM-1

Actor - Jefe de Planificación la 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. la(s) Participa en la TAN SCHE y TAN PLAN.

Conocimiento

Otras Destrezas Responsabilidades y Restricciones

Para esta tarea el agente se comunica con los secuenciadores quienes también participan en el proceso. 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 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. El jefe de planificación es el responsable de lo que se realiza en la operativa marítima en relación con la atención del barco. Bajo su responsabilidad están los comunicadores y los secuenciadores, quienes son los que ejecutan las acciones planeadas y propuestas por él. Para su trabajo, las restricciones que se presentan están relacionadas con la capacidad de atención del puerto, con las variables que hacen que la planeación de la secuencia de carga y descarga sea muy casuística.

Formulario 4-6 AM-1: Especificación de los Agentes del SBCTR

4.3.4

Modelo de conocimientos

Como primera medida se presenta el diagrama de conceptos realizado para la operativa marítima en la Figura 4-18.

4.3.4.1

Conocimiento del dominio

El esquema del dominio es el que se presentó en la Figura 4-18, adicionándole los atributos a cada uno de los conceptos y la definición específica de las relaciones o reglas. Unos ejemplo de la especificación textual, en particular de los conceptos maquina y contenedor, y de la relación conducción-maquinaria se presenta a continuación: CONCEPT maquina; ATTRIBUTES: num-maquina: INTEGER; tipo: STRING; estado: STRING; operativa: STRING; posicion-actual: INTEGER = 0; END CONCEPT maquina;

CommonKADS-RT – Capítulo 4. Validación a través de casos

barco

184

carpeta

E.T.A. bodega

bayPlan

1..*

secuencia

1..* posicion 1..* maquina

movimientos

contiene situado-en contenedor

pos-terminal

pila

conductor

conduccionmaquinaria

frontal

chasis-Term planta

grua

trastainer

calle

Figura 4-18 Diagrama de Conceptos – Conocimiento del Dominio - de Operaciones Marítimas

CONCEPT contenedor; ATTRIBUTES: num-boletin: INTEGER; num-contenedor: STRING; clase: INTEGER;

CommonKADS-RT – Capítulo 4. Validación a través de casos

185

estado: STRING; peso: INTEGER; rango: STRING; destino: STRING; buque: STRING; temperatura: INTEGER; alturaMaxima: INTEGER; END CONCEPT contenedor; BINARY-RELATION conduccion-maquinaria; DESCRIPTION: “Conducción por parte de un conductor de una máquina”; ARGUMENT-1: conductor; CARDINALITY; 1; ARGUMENT-2: maquina; CARDINALITY; 1; ATTRIBUTES: Fecha-conduccion; END BINARY-RELATION conduccion-maquinaria;

Además, para ampliar la especificación se presentan los diagramas de estados de algunos de esos conceptos:

descarga Llegada

carga Tránsito

Salida

Figura 4-19 Diagrama de estados de Bayplan

Libre resevar desbloquear bloquear

liberar

desbloquear Bloqueada

Asignada a Servicio

bloquear

Figura 4-20 Diagrama de estados de Pila

CommonKADS-RT – Capítulo 4. Validación a través de casos

186

extraer

vacía

asignar_ contenedor

ocupada

depositar asignada

Figura 4-21 Diagrama de estados de Posición

vacía

asignar ocupada

extraer

asignada

depositar

Figura 4-22 Diagrama de estados de Contenedor

4.3.4.2

Conocimiento de la tarea

Si el conocimiento es sobre la asignación de contenedores a la bodega del barco, entonces se puede utilizar la plantilla de la tarea asignación definida en [SAA00], haciéndole sólo los ajustes necesarios para manejar la terminología específica del dominio del puerto. Ver Tabla 4-1.

Tabla 4-1 Descripción de la tarea asignación Modelo de Conocimiento

TAN ATR

Asignación de barcos Hacer la asignación entre contenedores y bodega, en donde los contenedores deben ser cargados a la bodega de un barco específico. Objetos: los contenedores Terminología 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 Los datos de los contenedores, los de las bodegas del barco, los Entradas requerimientos específicos y si ya hay contenedores ubicados en el barco, entonces esas asignaciones. Un conjunto de localizaciones o relaciones entre el contenedor y la bodega Salidas del barco. Especificación de la tarea en TASK asignación; Conocimiento Meta

CommonKADS-RT – Capítulo 4. Validación a través de casos

187

ROLES: INPUT: objetos: “los contenedores que necesitan ser ubicados en las bodegas de un barco”; recursos: “las posiciones en las bodegas en donde se van a ubicar los contenedores en el barco”; OUTPUT: localizaciones: “El conjunto de asignaciones contenedor – posición de la bodega”; END TASK asignación; Especificación del método de TASK-METHOD método-asignación; REALIZES: asignación; la tarea en CML2 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 -> grupocontenedores); assign (grupo-contenedores + recursos + ubicacionesactual -> 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 conjuntocontenedores; END WHILE END TASK-METHOD método-asignación; CML2

También, como se mencionó anteriormente, el conocimiento más importante para modelar es el de la planeación de la secuencia de carga y descarga del barco que está atracado en el muelle. Es así, como una vez evaluadas las plantillas propuestas en la librería, se ha decidido que para esta actividad es necesario hacer tanto la planificación como el scheduling, teniendo en cuenta que el resultado final será un plan estático del plan de actividades. Es decir, que el plan que se defina no puede variarse durante el proceso. En caso de que no se cumplirse en su ejecución porque las condiciones reales han variado, entonces se vuelve a realizar la tarea completa. La característica de la tarea de planificación es que en ella las acciones son parcialmente ordenadas en el tiempo, ver Tabla 4-2. La característica del scheduling es que en ella se toman unas actividades cuyas secuencias temporales son predefinidas, ver Tabla 4-3

CommonKADS-RT – Capítulo 4. Validación a través de casos

188

Tabla 4-2 Descripción de la tarea de planificación de carga y descarga del barco Modelo de Conocimiento

TAN SEQ

Planificación de la secuencia de carga y descarga del barco 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. Meta: determinación de la secuencia de carga y descarga del barco. Esta Terminología 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”. La meta que se definió anteriormente Entradas La secuencia completa de carga y descarga. Salidas Especificación de la tarea en TASK planificación ROLES: CML2 INPUT: requerimientos: “los requisitos que el plan debe cumplir”; meta: “lo que se quiere lograr”; OUTPUT: plan: “El conjunto acciones para llevar a cabo la carga y descarga del barco”; END TASK planificación; Especificación del método de TASK-METHOD método-planificación-idealizado; REALIZES: planificación; la tarea en CML2 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; Conocimiento Meta

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 Meta

Scheduling para la secuencia de carga y descarga Hacer la programación de las actividades del plan de acuerdo con los recursos disponibles y el tiempo 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.

Terminología

CommonKADS-RT – Capítulo 4. Validación a través de casos

189

Restricción: una condición restrictiva en la relación entre unidades y recursos. Los trabajos formados por las unidades Entradas La relación entre las unidades y los recursos, en la cual todos los tiempos de Salidas inicio y fin de las unidades, son determinados. Especificación de la tarea en TASK scheduling; ROLES: CML2 INPUT: trabajos: “actividades que necesitan ser programadas”; OUTPUT: programa: “actividades asignadas con el tiempo asociado”; END TASK scheduling; Especificación del método de TASK-METHOD temporal-dispatching; REALIZES: scheduling; la tarea en CML2 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 -> unidadcandidata) DO select (unidad-candidata + programa -> recursoobjetivo); assign (unidad-candidata + recurso-objetivo -> programa); verify (programa -> valor-de-verdad); IF valor-de-verdad == false THEN modify (programa -> programa); END IF END WHILE END TASK-METHOD temporal-dispatching;

Estas TAN requieren que se ejecuten si el sistema tiene tiempo para cumplir con los plazos que se han definido, así que el manejo de las restricciones temporales será hecho por el controlador del SBCTR. Los modelo de comunicaciones, diseño y tareas de tiempo real no se han construido porque se considera que como el SBCTR no se desarrollará por el momento, entonces no sería adecuado. Estos quedarán pendientes para cuando se retome el proyecto. Este caso, como se dijo en su introducción, ha servido para mostrar los modelos de la fase de análisis, los cuales se han presentado en detalle. Lo importante de esto, es mostrar que la metodología CommonKADS-RT es una herramienta muy completa para realizar el estudio de un problema, la formalización del mismo y de su solución. Es una buena herramienta gerencial de toma de decisiones. Con esto se termina el análisis de este escenario. Las conclusiones obtenidas de él se encuentran en la parte final de este mismo capítulo.

CommonKADS-RT – Capítulo 4. Validación a través de casos

4.4

190

Robot

Como ya se dijo anteriormente, el problema que vamos a resolver con el Robot no está ubicado en ningún contexto organizacional, por lo que se obviarán muchos de los planteamientos del modelo de la organización, en especial aquellos puntos que se refieren al estudio de aspectos específicos de la empresa. El problema ya está planteado, se conocen los procesos a modelar, y para propósitos de validar la metodología es una necesidad la construcción de la aplicación. Todo esto se puede considerar como precondiciones del proceso que facilitan el análisis de la solución. En cuanto a la fase de análisis se incluye el modelo de la organización, el de TAN, el de conocimientos. No se presentan los modelos de agentes y de comunicación porque para esta situación no hay un agente en especial que sea quien realiza la TAN. En el momento en que el sistema esté operando, el único que tendrá interacción con él es el usuario programador que se encarga de encenderlo, ubicarlo en una posición específica y apagarlo. Aunque los sensores pueden tomarse como agentes software, si se trataran como externos al sistema, en este caso se han considerado como parte de él. Por ello también, es que no hay comunicación entre agentes en el desarrollo de una TAN. De la fase de diseño, se incluyen algunos apartes del diseño global, del detallado y se presentan los resultados de una simulación que se hizo para este caso. A continuación entonces, se comienza con la definición del problema, es decir, de la situación inicial. Este es un caso especial en donde se quiere mostrar que la metodología CommonKADS-TR no se aplica solamente a casos basados en el conocimiento relacionados con problemas específicos de una organización, sino que también sirve para modelar situación en donde se requiera tener un comportamiento inteligente pero aislado de un sistema organizacional específico. Por lo tanto, la especificación de los modelos de CommonKADS-TR varía en que algunas cosas, pues no se tiene o no se requiere, la información que se necesita en algunos de los formularios, en especial en el modelo de la organización.

4.4.1

Modelo de la organización

Condiciones iniciales: El robot está ubicado en un cuarto cerrado, micro mundo, que está delimitado por unas paredes que lo cierran. Cada pared tiene un hueco con una forma geométrica básica (rectángulo, triángulo, semi-círculo). El robot se encuentra situado en una posición inicial fija y conocida. Ese entorno es también conocido para él. También, hay una serie de objetos con formas geométricas. En el cuarto, uno de los objetos está en algún lugar predefinido, establecido al azar. Dicho objeto debe ser encontrado por el robot, identificado y desplazado a un lugar en una de las paredes, el cual debe coincidir con su forma física. Es

CommonKADS-RT – Capítulo 4. Validación a través de casos

191

decir, el rectángulo debe ser guardado en la pared en donde se encuentre el hueco en forma de rectángulo, y así para cada una de las formas definidas. Objetivo: Dado un mundo cerrado que contiene figuras geométricas básicas y que sus paredes tienen incrustaciones también de forma geométrica, se requiere construir un sistema en el que el robot pueda encontrar cada una de las piezas del mundo, identificarlas y ubicarlas en su lugar respectivo (un proceso de reconocimiento y clasificación o asignación de formas). Las formas básicas son: el rectángulo, el triángulo y el semi-círculo. Ver figura 4-1.

Robot Formas básicas

Figura 4-23 Un micro mundo posible para que el robot navegue

Proceso a realizar: Dadas las características de este robot se debe desarrollar un sistema que pueda cumplir con el objetivo definido. Es así como llega a un nivel más detallado en el análisis del problema: El proceso en pasos está dado por la siguiente secuencia: •

Inicialmente se debe activar el robot y hacer un chequeo de su estado a través de la lectura de sus sensores y de su batería. Este procedimiento ya viene predefinido en el robot.

•

Una vez el robot está listo, debe comenzar a buscar el objeto que se encuentra en el micro mundo. Para esto debe hacer una serie de tareas que más adelante se definirán.

•

Luego de hallar el objeto, el robot debe identificarlo de acuerdo con las formas que él reconoce.

•

También, debe planear la forma como debe moverlo o desplazarlo por el micro mundo para ubicarlo en la pared que le corresponde. Esto último lo sabe porque en cada una de las paredes del micro mundo hay un cajón o hueco predeterminado con una forma de figura específica. Para facilidad de la prueba, se ha definido que inicialmente son cuatro paredes, el hueco estará siempre en la misma pared (definida como parte del estado inicial del micro mundo) Además, hay un solo hueco en la pared y debe ser diferente de las demás.

CommonKADS-RT – Capítulo 4. Validación a través de casos

•

192

Posteriormente, el robot debe mover el objeto hasta llegar al objetivo final. Es decir, hasta que introduzca el objeto en el hueco que le corresponde. En ese momento, el proceso se da por terminado con éxito.

En forma gráfica, el proceso completo se representa en la Figura 4-24.

Activar robot Administrador

Buscar objeto

Identificar objeto

Mover objeto Fin Proceso

Figura 4-24 Proceso que debe realizar el robot para cumplir con el objetivo final

Como se puede observar, en este proceso sólo interviene el actor humano para definir las condiciones iniciales del micro mundo o para iniciar la ejecución del sistema. Pero, durante el desarrollo de la tarea, es el robot autónomo en su realización. Adicionalmente, este proceso se puede ver como una TAN que empieza con la puesta en marcha del robot y que termina con el objeto ubicado en su sitio correspondiente. También esta TAN puede ser divida en otras que permiten estructurar el proceso en una forma más detallada con el fin de conocer a fondo cuáles son las actividades que el robot debe realizar. En el formulario OM-3 se puede observar la especificación de las TAN, de acuerdo con lo planteado en la metodología CommonKADS-TR. El comportamiento global del robot ha sido modelado en un conjunto de tareas de alto nivel. Así, el proceso podría ser considerado como una TAN que ha sido dividida para mejorar su estructura y conocer cada detalle acerca de las actividades realizadas por el robot. Con el formulario OM-3 (Descripción del proceso a través de las tareas de alto nivel), se pueden observar la especificación de dichas TAN. Es importante resaltar que para este caso particular, no se ha considerado necesario definir dos aspectos que se proponen en la metodología para este formulario: ¿Ejecutada por y en dónde? ¿Es posible introducir un sistema informático en la TAN? Esto es porque el único agente que interactúa con el sistema es el usuario o programador que se encarga de manejarlo. De resto, el conocimiento del sistema se ha obtenido de personas (los agentes que proporcionaron el conocimiento del proceso a realizar por el robot y de su manejo) expertas en el tema de la robótica, pero que para efectos del sistema final no tendrá ninguna relación.

CommonKADS-RT – Capítulo 4. Validación a través de casos

Ident. TAN

Nombre TAN

Objetivo de la TAN

Tipo de TAN

Config

Configuración

ActRobot

Activación robot

Establecer las condiciones del micro mundo Protocolo de inicio, verificación del robot

BuscaObj

Búsqueda objeto

Encontrar el objeto que debe reconocer y trasladar

Planeación Scheduling Monitorización

IdObj

Identificación objeto

Identificar el objeto encontrado

Clasificación

MovObj

Movimiento objeto

Trasladar el objeto hasta el sitio en donde debe ser guardado

Configuración Planeación Scheduling Monitorización

193

Importancia de la TAN para el proceso Es importante pero no requiere de conocimientos Igual que la anterior

¿Es intensiva en conocimientos?

Conocimiento involucrado

¿Puede tener restricciones temporales?

Nada

No

Nada

Si. El robot maneja unos tiempos para revisar su batería, los sensores y los motores. Es un tiempo fijo Si. Hay tareas que serán periódicas, que tendrán unos deadlines y también un wcet

Es fundamental para planificar las acciones y asignar los tiempos La clave es la diferenciación entre las diferentes figuras.

Alto

Es necesario tener un planeador

Alto

Alto

Planificación de acciones, interpretación del micro mundo, verificación de la trayectoria Conocimiento de formas de objetos trigonométricos, planeación de trayectoria, interpretación, verificación. Identificación de la pared objetivo, planificación de la trayectoria, cómo mover el objeto.

Formulario 4-7 Descripción del proceso en función de las TAN que lo componen

Igual que la anterior

Igual que la anterior

CommonKADS-TR – Capítulo 4. Validación a través de casos

194

Además, como no se está analizando la solución informática a un problema existente, bien sea manual o no, entonces no es posible responder la segunda pregunta, pues la respuesta es conocida, ya que es un hecho la construcción del sistema.

4.4.2

Modelo de tareas de alto nivel

Este modelo describe los procesos asignados al sistema y que se relacionan con la organización. La TAN BuscaObj tiene que incluir actividades con restricciones temporales para controlar algunas de las acciones del robot. Por ejemplo, dentro de esta tarea es necesario hacer un plan de las acciones a realizar por el robot, de tal forma que se define una subtarea llamada PlanAcción con un período de 100 milisegundos, para significar que esta TAN tiene que ser repetida o realizada cada 100 milisegundos. Lo mismo sucede con leerSensor, una tarea hoja, que tiene definido como tiempo de ejecución para el peor de los casos (Worst Computer Execution Time – wcet) es 2 milisegundos. Esto se detallará en el modelo del conocimiento, más adelante.

Percepción del entorno

Planificar acción

Ejecución de la acción

Figura 4-25 Detalle de las actividades de la TAN 2 - Buscar Objeto

Y, si la TAN es descrita o dividida en más tareas es necesario diligenciar esto de nuevo este formulario. Por ejemplo la tarea EjecAcción es posible dividirla en leerSensor VeriObjetivo y EjecComando, y así pueden surgir más TAN o TTR.

4.4.3

Modelo de conocimiento

Este modelo muestra el conocimiento usado por el sistema para solucionar sus TAN, incluyendo las especificaciones de TR. A través del Diagrama de Conceptos se presenta el esquema del dominio. Ver Figura 4-26. Un ejemplo de especificación textual del concepto robot y de la relación con el planificador se presenta a continuación:

CommonKADS-TR – Capítulo 4. Validación a través de casos

195

Esto es porque el único agente que interactúa con el sistema es el usuario o programador que se encarga de manejarlo. De resto, el conocimiento del sistema se ha obtenido de personas (los agentes que proporcionaron el conocimiento del proceso a realizar por el robot y de su manejo) expertas en el tema de la robótica, pero que para efectos del sistema final no tendrá ninguna relación. Además, como no se está analizando la solución informática a un problema existente, bien sea manual o no, entonces no es posible responder la segunda pregunta, pues la respuesta es conocida, ya que es un hecho la construcción del sistema.

posición

sensor

1..16

batería

robot

1

2

motor

ubicado-en sonido

bumper

planificador

mundo

plan-acción formas

plan-traslado

plan-búsqueda

rectángulo

plan-identif triángulo

círculo

Figura 4-26 Diagrama de Conceptos para el sistema del robot móvil en el micro mundo

CommonKADS-TR – Capítulo 4. Validación a través de casos

196

A continuación se presenta uno de estos conceptos: CONCEPT robot; ATTRIBUTES: pos: posición; bump: bumper; estado: valor-estado; vel_derecha: INTEGER; vel_izq: INTEGER; sonar_frontal: sonar; sonar_lateral: sonar; estado_serial: INTEGER END CONCEPT robot; VALUE-TYPE valor-estado; TYPE NOMINAL: VALUE-LIST: {apagado, encendido}; END VALUE-TYPE valor-estado; En cuanto al conocimiento de las tareas, el planificador se puede apreciar a través de una máquina de estados de la siguiente forma:

encuentra-objeto

no-encuentraobjeto

Buscando objeto

Reconociendo objeto

forma-desconocida

siguiente-objeto

Desplazando objeto

objeto-reconocido

Figura 4-27 Diagrama de transición de estados del Planificador

No-Detectado

ObjetoDetecta

planificando siguiente acción acción completa

acción a ejecutar (mover x,y) (giro α)

desplazando

planificando siguiente acción

detectado fin giro

bump: bumper;

O.K.

acción a ejecutar (mover _,_) (giro α)

desplazando

Figura 4-28 Diagrama de transición de estados del PlanAcción

CommonKADS-TR – Capítulo 4. Validación a través de casos

197

Adicionalmente, se concluye que al nivel abstracto del nivel del conocimiento, la TAN de planificación se puede modelar como lo proponen [SAA+00] en los templates knowledge model. El tratamiento que se haga en el diseño, depende tanto de la arquitectura, como de los algoritmos de planificación que se estén manejando para garantizar las restricciones temporales. La relación entre el robot y el planificador se define a través del siguiente diagrama de secuencia, en donde las unidades de tiempo están dadas por un tiempo absoluto dado por el reloj del sistema.

Robot

Robot en estado inicial

el

Planificador

chequeo 20 segs envío estado actual / datos Robot listo

100 ms

Ejecuta acción

Planacciones 1. acción

solicitud de datos

envío estado actual / datos fin acción Planacciones n. acción

Figura 4-29 Diagrama de secuencia entre el concepto Robot y el Planificador

4.4.4

Modelo de diseño

Características del Robot: El Robot es un Pioneer 2 Mobile Robot modelo DX. Es un robot móvil de cuatro ruedas que contiene todos los componentes básicos para la sensorización y navegación en un entorno real, incluyendo la batería de potencia, los motores de control y de las ruedas, los decodificadores de posición y velocidad, y un conjunto de sonares y bumpers

CommonKADS-TR – Capítulo 4. Validación a través de casos

198

integrados. Todos los componentes son controlados por un microprocesador Siemens 88C166 que viene con una memoria ROM programable de 32K como parte del procesador y con una memoria adicional RAM de 32K, y por un software servidor del robot móvil. Tiene una variedad de puertos de expansión para la entrada y salida, que incluye: un bus de entrada / salida direccionable para máximo 16 dispositivos, dos puertos seriales RS232C, ocho puertos digitales de entrada y salida, cinco puertos A/D y controlador PSU. En detalle, el Hardware es el siguiente: •

Sonares: El robot contiene 16 sonares, 8 delanteros y 8 traseros, distribuidos en dos vectores que proporcionan información sobre la detección de objetos. Los sonares se activan cada 25 hz. (40 ms por sonar y por vector) y la sensibilidad varía desde 10 cm hasta más de 5 m. El mecanismo de activación de los sonares puede ser controlado por software. Por defecto la secuencia de activación es de izquierda a derecha para el vector delantero y de derecha a izquierda para el vector trasero.

•

Baterías: El Pioneer DX puede contener hasta 3 baterías de 12 V, que suministran la potencia necesaria para los distintos componentes y accesorios. La duración de una batería depende de la actividad del robot, variando de 4 a 8 horas para una actividad normal. Las baterías son muy importantes para conseguir la balanza del robot. En general, se aconseja operar con 3 baterías; si únicamente se trabaja con una, es conveniente colocarla en el centro.

•

Componentes electrónicos: El microcontrolador, un controlador de motores, dos controladores de los sonares, uno por cada vector.

Aplicación ARTIS Componente de la interfaz de usuario

Robot Radio Ethernet

Microcontrolador Siemens 88C166

Señal cable Componente de comunicación Componente de planificación

RS232 C

Sensores Batería VDC Motor

Componente de control inteligente

Figura 4-30 Diagrama de componentes principales del robot El software que el robot tiene es:

VDC

CommonKADS-TR – Capítulo 4. Validación a través de casos

•

199

El sistema operativo se llama P2OS. Este sistema es común a toda la familia de robots Pioneer que utiliza la arquitectura cliente / servidor. El servidor se encarga de gestionar los detalles de bajo nivel del robot, incluyendo el control de los motores, la activación de los sonares y la decodificación de la posición y de la velocidad. Así, las aplicaciones de alto nivel no requieren especificar muchos detalles internos del robot. El P2OS se comunica con la aplicación cliente utilizando dos protocolos especiales de paquetes, llamado de paquetes de comando del cliente al servidor y, paquetes de información del servidor del servidor al cliente. Ambos están formados por un conjunto de bits, agrupados en 4 elementos principales: cabecera (2 bytes), byte count (1 byte), bloque de datos del cliente o del servidor (N bytes) y checksum (2 bytes).

El formato que se requiere para el manejo de la información es el siguiente: •

Información enviada:

Tanto para establecer la comunicación con el servidor, como para controlar el comportamiento del robot, el cliente debe enviar paquetes de comando, al menos cada 2 segundos. Estos paquetes tienen longitud variable, dependiendo del tipo de comando enviado.

•

−

Cabecera (2 bytes): permite la sincronización del servidor y el cliente. Los valores son: 0xFA y 0xFB.

−

Byte Count (1 byte): indica el número de bytes que forman el paquete, cuyo tamaño es variable (depende del tipo de comando enviado).

−

Número de comando (1 byte): cada comando tiene asignado un número.

−

Tipo de argumento (1 byte): tipo del argumento que requiere el comando (entero positivo, entero negativo, string).

−

Argumento (n bytes): valor del argumento del comando (entero o string).

−

Checksum (2 bytes): utilizado por el servidor para saber si la trama recibida es correcta.

Información recibida:

Como se ha comentado anteriormente, una vez la conexión se ha establecido, el servidor envía información al cliente acerca del estado del robot cada 100 ms. El paquete recibido consta de la siguiente información: −

Cabecera (2 bytes): esta información está presente en la mayoría de los paquetes que recibe cualquier robot, ya que permite la sincronización del cliente con el servidor. En el caso del robot Pioneer, la cabecera es 0xFA y 0xFB.

CommonKADS-TR – Capítulo 4. Validación a través de casos

200

−

Byte Count (1 byte): indica el número de bytes que vienen a continuación y que forman parte del paquete. Este campo está presente en todos aquellos paquetes que recibe cualquier robot cuando el tamaño del paquete es variable. En nuestro caso, el número de bytes enviados por el servidor depende del número de sonares cuyo valor varía de una lectura a la siguiente.

−

Estado del robot (1 byte): indica si el estado está parado (0x33) o en movimiento (0x32).

−

Posición del robot (Xpos, Ypos, Thpos): el servidor envía unos valores que multiplicados por unas constantes (DistConvFactor, para Xpos y Ypos; AngleConvFactor, para Thpos), indican la posición actual del robot en milímetros y grados, respectivamente.

−

Velocidad de las ruedas: el servidor envía la velocidad de cada una de las ruedas en unas unidades que hay que multiplicar por la constante VelConvFactor para convertirlas a mm/s.

−

Batería: indica el nivel de carga de la batería.

−

Bumpers: indicador de choque, tanto para los bumpers delanteros como los traseros.

−

Sonares: la información que el servidor envía acerca de los sonares es variable, ya que depende del número de sonares cuyo valor haya cambiado de una lectura a la siguiente. Primero envía el número de sonares cuyo valor ha cambiado, y para cada uno de esos sonares envía el valor de la nueva lectura, que multiplicada por la constante RangeConvFactor indica la distancia en mm al obstáculo detectado.

−

Checksum: se utiliza para comprobar que los datos de la trama recibida son correctos.

En la Tabla 4-1 se compara la información enviada por el robot Pioneer, con la información enviada por cualquier robot general.

Tabla 4-4 Comparación de la información enviada por el robot Pioneer con un robot general. ROBOT PIONEER

ROBOT GENERAL

Estado del robot

Byte indicador: 0x32: moving 0x33: stopped

Byte indicador

Posición del robot

Coordenadas en mm (x, y, Th)

Tics de las ruedas

Velocidad de las ruedas

Valor en mm/s

Valor en determinada

una

unidad

CommonKADS-TR – Capítulo 4. Validación a través de casos

201

Batería

Nivel de carga en voltios

Bumpers

Valor que indica si alguno de los Byte indicador bumper está presionado.

Sonares

Distancia (mm) al obstáculo.

Señal (odometría)

Para desarrollar la aplicación es necesario utilizar un lenguaje de programación para implementar algunas funciones básicas del robot. Es así como se ha utilizado InSiDE que es la herramienta que en el DSIC se ha construido para componer SBCTR. Esta herramienta está hecha bajo el lenguaje C. Algunas de las estructuras y funciones que se han implementado para controlar el robot son las siguientes: • Estructuras: −

Estructura para la manipulación del estado de los paquetes leídos del puerto serie. La estructura que se muestra a continuación se utiliza para almacenar el estado de los paquetes que se van recibiendo. struct paquete { int actual_p; // Posición de la última trama int estado; // Estado de la trama actual: COMPLETOPENDIENTE

int leidos_C; // Nº bytes de la cabecera leídos hasta el momento

int leidos_T; // Nº bytes de la trama leídos hasta el momento

};

−

Estructura que almacena la información de fábrica del robot.

Una vez se ha establecido la comunicación, la primera información que envía el robot hace referencia al nombre, clase y subclase del robot. Esta información es almacenada en la siguiente estructura. struct info { unsigned char nombre[14]; unsigned char clase[7]; unsigned char subclase[4];

// Nombre del robot // Clase del robot // Subclase del robot

};

−

Estructura que almacena la información de los sonares.

CommonKADS-TR – Capítulo 4. Validación a través de casos

202

El robot consta de 16 sonares, numerados de izquierda a derecha: 0-7 son sonares delanteros, y del 8-15 son los traseros. En la siguiente estructura se almacena el valor del sonar, que indica la distancia en mm al obstáculo detectado, y la posición del sonar respecto al origen de coordenadas del robot. struct sonar { unsigned

short

int

valor;

//

Valor

del

sonar

(distancia en mm).

unsigned short int x,y,Th; // Pos. del sonar respecto al robot

};

−

Estructura que almacena la información sobre las condiciones del robot.

Como se ha comentado anteriormente, después de establecer la comunicación, el robot envía cada 100 ms un paquete que contiene información sobre el robot. Esta información es almacenada en la siguiente estructura, para su posterior acceso y utilización. struct robot { unsigned char status;

//

Estado

del

robot:

STOPPED, MOVING

short

int

Xpos,Ypos,Thpos;

//

Coordenadas

de

la

posición local

short short short short

int int int int

Lvel, Rvel; battery; bumpers; timer;

// Velocidad de las ruedas // Nivel de la batería // Indicador de choque // Puerto analógico

seleccionado

sonar sonares[16];

// Vector que contiene los

16 sonares

};

• Funciones −

Funciones de acesso al puerto serie.

La comunicación con el robot (establecimiento de la conexión, envío y recepción de información) se realiza a través del puerto serie. A continuación se muestran las funciones que gestionan el acceso al puerto serie, llamando a las funciones que se encargan de la lectura y escritura en el puerto (rt_com_read y rt_com_write). o void vaciar_puerto(int fd): lee todo el contenido actual del buffer, con el fin de vaciarlo para prepararlo para realizar una nueva conexión. o

void envio_com(unsigned char num): envía al robot un comando sin argumentos (COMPULSE, COMOPEN, COMCLOSE, ...).

CommonKADS-TR – Capítulo 4. Validación a través de casos

−

203

o

void envio_com1(unsigned char num, unsigned char tipo_arg, unsigned short int valor_arg): envíaa al robot un comando (num), con un argumento (valor_arg), y su respectivo tipo (tipo_arg).

o

int obtener_cabecera(): obtiene la cabecera de la trama enviada por el servidor. Continua leyendo bytes hasta que encuentra los dos bytes de la cabecera. Devuelve el número de bytes leídos de la cabecera; -1 si error.

o

int obtener_trama(): lee del puerto serie los datos que contiene una trama. Devuelve el número de bytes leídos.

o

int esperar_cabecera(): lee del puerto serie hasta que obtiene la cabecera completa del paquete enviado por el robot. Devuelve 0 si se leyó correctamente; -1 en caso de error.

o

int esperar_trama(): lee del puerto serie hasta obtener la trama de datos completa del paquete enviado por el robot. Devuelve –1 si hay error; 0 si se leyó correctamente y el checksum de la trama es correcto.

Funciones para la comunicación con el robot.

A continuación se muestran las funciones que permiten establecer la conexión con el robot (enviando los comandos necesarios), así como aquellas funciones que tratan la información enviada por el robot, separando la cabecera de los datos, los cuales serán tratados y almacenados para su posterior acceso. o

int leer_paquete(): lee el contenido del puerto serie, llamando a las funciones obtener_cabecera() y obtener_trama(), desde donde se había quedado la última vez. Devuelve –1 si ha ocurrido un error; 1 si la cabecera o la trama están pendientes de lectura (incompletas); 0 en caso contrario.

o

int obtener_ultimo_paquete(): lee todo el contenido del puerto serie, llamando a la función anterior, sin esperar a que la última trama esté completa. Devuelve la posición de la última trama completa; -1 en caso de error.

o

int establecer_conexion(): establece la conexión con el robot enviando sucesivamente las tramas SYNC0, SYNC1 y SYNC2 (mediante la función envio_com()), al mismo tiempo que espera la respuesta del robot (mediante la función leer_paquete()). Devuelve 0 si la conexión se ha establecido; -1 si no se ha podido conectar; 1 si la conexión está inicializada pero no terminada.

o

int conexión_robot(): intenta establecer la conexión con el robot, llamando a la función anterior. Devuelve –1 si hay error; 0 en caso contrario.

o

void inicializar_conexión(): envia al robot los comandos OPEN y PULSE, provocando la activación de los controladores, de los sonares y de los

CommonKADS-TR – Capítulo 4. Validación a través de casos

204

motores. Además, el robot empieza a transmitir información, al mismo tiempo que espera comandos enviados por el cliente. o

int estado_conexion(): devuelve el estado de la conexión (CONNECT, NO_CONNECT).

o

void envio_pulso(): envia al robot el comando PULSE, para evitar que la conexión se pierda.

o

void cerrar_conexión_robot(): cierra la conexión con el robot, enviandole el comando CLOSE mediante la función envio_com().

−

Además, se tienen unas funciones auxiliares para la comunicación se utilizan para inicializar y acceder a las estructuras utilizadas en la comunicación, calcular el checksum de la trama enviada y recibida, comprobar que la trama recibida es la esperada, entre otras.

−

Hay funciones para gestionar la información del robot. Una vez la conexión ha sido establecida, el robot comienza a enviar paquetes de información periódicamente cada 100 ms a través del puerto serie. Las siguientes funciones obtienen el paquete enviado por el robot, y lo almacenan en la estructura de datos robot, para su posterior utilización. Además, existen unas funciones que permiten imprimir la información que contiene esta estructura.

−

Una vez se ha establecido la conexión y los motores son habilitados, es posible enviar al robot diferentes comandos de movimiento, tanto de traslación como de rotación. Así que se hicieron unas funciones para controlar el movimiento del robot. Cuando el robot recibe estos comandos, intenta alcanzar la velocidad y el ángulo deseados tan pronto como estos son recibidos. Las siguientes funciones permiten el envío de estos comandos (SETA, SETV, SETRV, SETRA, VEL, DHEAD, STOP).

Para detallar más el proceso construido en este escenario, se presenta la TAN configuración que tiene como objetivo el establecimiento de la conexión del robot, y para la que se establece el siguiente protocolo: Antes de poder enviar y recibir información del robot, es necesario establecer la conexión a través del puerto serie. Al encender el robot, éste se encuentra en un estado de espera (NO_CONNECT). Para establecer la conexión, la aplicación cliente debe mandar una serie de paquetes de sincronización a través del puerto serie: SYNC0, SYNC1 y SYNC2, sucesivamente, y recuperar las respuestas enviadas por el servidor. P2OS responde a cada comando enviado por el cliente, formando una sucesión de paquetes de sincronización idénticos a los recibidos. El cliente debe esperar la llegada de estos paquetes, de forma que sólo debe enviar un paquete cuando se ha recibido el eco. Si después de realizar un número determinado de intentos, no se ha podido establecer la conexión, ésta falla. Ver Figura 4-31 Diagrama que representa el inicio de la conexión.

CommonKADS-TR – Capítulo 4. Validación a través de casos

205

Cuando la información se ha establecido, en primer lugar el servidor envía un paquete que contiene información sobre el nombre (VALENCIA1220), clase (Pioneer) y subclase (DX) del robot. En este momento, el cliente debe enviar el comando OPEN, para que el robot comience a activar los sonares y los controladores de los motores, transmitir información, y espere a recibir los comandos del cliente.

intentos=0 NO_CONNECT Si (intentos=N)

Recibo_SYNC1 SYNC1_R Envio_SYNC2 CONNECT

CONNECTION FAILED

Figura 4-31 Diagrama que representa el inicio de la conexión

Por defecto la información es enviada cada 100 ms, valor que puede ser modificado accediendo a la flash ROM del robot. El servidor espera recibir al menos un paquete de comunicación cada 2 segundos (valor que puede ser modificado). De lo contrario, se asume que la conexión cliente / servidor se ha perdido, y cierra los motores del robot. Para evitarlo, se aconseja enviar el comando PULSE al servidor periódicamente, para indicar que la conexión debe mantenerse. Desde el punto de la descripción del método para buscar objetos, se presenta el siguiente seudocódigo:

1. 2. 3.

Módulo Buscar-Objeto Leer sensores Analizar sensores por sector (delanteros, traseros, laterales) Obtener coordenadas del objeto Si alguna coordenada no coincide con límite del mapa 3.1. Orientar robot en dirección (x, y,θ) 3.2. Avanzar hasta coordenadas

CommonKADS-TR – Capítulo 4. Validación a través de casos

4. 5.

206

3.3. Módulo Reconocer-Objeto Si no avanzar en dirección predeterminada Volver a 1.

4.4.5

Modelo de tareas de tiempo real

Aplicando la topología de la arquitectura ARTIS para este caso específico, se pueden apreciar las siguientes relaciones:

Robot AA

Config

ActRobot

BuscaObj IdObj

PercepEntorno PlanAcción

LeerSensor

MovObj

EjecAcción

VeriObjetivo EjecComando

In-Agents

MKSs

KSs

Figura 4-32 TAN en ARTIS

En donde, se tiene una TTR por cada in-agente que se defina, de modo que en este caso se tienen cinco tareas de tiempo real, definidas de la siguiente forma en términos de CML2: real-time-task ::= PlanAcción; 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;

CommonKADS-TR – Capítulo 4. Validación a través de casos

207

real-time-task ::= LeerListaSensor; rt-task-type: periodic; from: PlanAcción; relative-time: Yes; wcet: 2; /* milisegundos */ formed-by-others: Yes; roles : input: lectura-puerto-serie; output: lista-sensores; end real-time-task LeerSensor; Al traducir estas estructuras de CML2 al lenguaje de bajo nivel (al que el usuario no tiene acceso, sino que el sistema mismo se encarga de generar) definido en ARTIS se obtiene lo siguiente: (defagent buscaObj (period 100) // 100 ms (deadline 8) // 8 ms (importance 1) // el más importante (perception (percepEntorno)) (cognition (planAcción)) (action (ejecAcción)) (precedence (nil)) ) (defmks planAcción () (leerListaSensores) (veriObjetivo) (ejeComando) (type mandatory) (importance 1)) (defks leerListaSensor () (wcet 2) (codefile ´.\ks_leerListaSensores.c´) ) (defks veriObjetivo() (wcet ) (codefile ´.ks_veriObejtivo.c´\))

(defks ejecComando () (wcet ) (codefile ´.ks_ejecComando.c´\))

Además, en el blackboard se tendrían las clases y objetos (conceptos en CommonKADS) de forma tal, que definieran sus atributos. Así, para el concepto Robot, se tendría lo siguiente:

CommonKADS-TR – Capítulo 4. Validación a través de casos

208

(defclass ROBOT // robot serial { (slot pos (type position)) (slot bump (type bumper)) (slot status (type valor-estado)) (slot vel_rigth (type int)) (slot vel_left (type int)) (slot front_sonar_bat[8] (type sonar)) (slot rear_sonar_bat[8] (type sonar)) (slot serial_status (type int)) })

SIMULACIÓN Se ha hecho una simulación del comportamiento del robot en el micro mundo planteado anteriormente y actualmente se está implementando con ARTIS. La Figura 4-33 presenta el estado inicial del micro mundo, con el robot en su posición inicial. El objeto que el robot tiene que encontrar es un rectángulo en medio del cuarto, y debería ser movido hasta localizarlo en la parte inferior de la pared de la derecha.

Figura 4-33 Estado inicial del micro mundo La Figura 4-34 muestra el estado final del micro mundo, cuando el robot ha ubicado el objeto en el lugar apropiado [SHB00]. En ésta figura se puede apreciar la trayectoria seguida para alcanzar el objetivo final.

Figura 4-34 Estado final del micro mundo

CommonKADS-TR – Capítulo 4. Validación a través de casos

209

En la Figura 4-35, se aprecia una fotografía del robot enfrente del objeto.

Figura 4-35 El Pioneer 2 enfrente de un objeto de forma rectangular

4.5

Conclusiones de CommonKADS-RT

la

aplicación

de

Los dos escenarios presentados en este capítulo, son tan diferentes en su esencia, en el tipo de problema y en la forma en que se aborda cada uno de ellos, y tienen en común el tipo de solución propuesta. En ambos casos se plantea el modelado, diseño, construcción e implantación de un sistema basado en el conocimiento de tiempo real, con un propósito acorde con el problema. Por tanto, estos dos casos nos permiten llegar a razonamientos válidos acerca de la utilización de la metodología. Es como si fuera un proceso de inducción, sólo que no se puede generalizar porque para ellos es necesario aplicar la metodología a muchos más casos y que además sea probada y aceptada por otros. Pero, para efectos de esta investigación, se considera que si son validas las afirmaciones que se hagan al respecto. Como análisis individual de los escenarios, se concluye que para el caso del robot fue importante la utilización de la metodología pues se logró formalizar mucho el conocimiento requerido, se corrigió la estrategia de programar antes de analizar y se registró el proceso llevado a cabo durante el proyecto. Se encontró que en la parte de diseño hay una carencia todavía y es la no-inclusión en la metodología de estrategias para definir los métodos de planificación de las tareas de tiempo real y de técnicas para llevar a cabo el test off-line de planificabilidad. Por tanto, esta es una mejora que se le puede hacer a la metodología, en trabajos futuros. Pero, también se demostró con este caso, que CommonKADS-RT sirve para modelar cualquier situación en donde se requiera tener un comportamiento inteligente bajo unas restricciones temporales, sin importar lo complejo del problema o si está enmarcado en un contexto organizacional. Para el caso del puerto, se logró probar que la utilización de CommonKADS-RT permitió que los mismos expertos reconocieran e hicieran conciente algunos de los procesos que realizan en su que-hacer diario y de las formas y estrategias que utilizan para ello, permitiendo que se replanteen o reafirmen algunos de ellos. Esto quizá no es uno de los objetivos de la metodología, pero es un valor añadido que se obtiene al utilizarla, porque así sea que se construya o no el SBCTR, se logra mejor la situación actual. En ambos casos se comprobó que el realizar un proceso formal de análisis y diseño asegura que tanto el conocimiento obtenido como el sistema propuesto, se desarrollan de

CommonKADS-TR – Capítulo 4. Validación a través de casos

210

acuerdo con sus requerimientos. Así, la implementación se hace más fácil y permite eliminar errores en el proceso. También, la metodología logró que se definiera un vocabulario común para los ingenieros del conocimiento, los diseñadores, los expertos, los usuarios y los programadores, en áreas que aparentemente son tan dispares como son las de los SBC y los STR, facilitando el intercambio de ideas acerca del problema y del sistema y que se pudieran compartir procesos comunes de trabajo. Se pudo observar que ciertos elementos de los modelos de CommonKADS-RT son más relevantes que otros, dependiendo del proyecto. Es decir, que según el problema, la organización, el sistema y su entorno, algunos aspectos podrán ser considerados y valorados. No todo lo definido en los formularios de los modelos debe ser especificado, tal como se acaba de apreciar al comparar el escenario del robot con el del puerto. También, dependiendo del proyecto y del sistema, es posible realizar varios modelos a la vez. Es decir, que se pueden estar realizando actividades de diversos modelos en paralelo, pues en la medida en que se van definiendo los conceptos o se van completando las especificaciones, el conocimiento y la información pueden servir para modelar distintas vistas de ello. Esto permite reafirmar la idea de trabajar en un ciclo por espiral, teniendo en cuenta la valoración de los riesgos y los planes que se van construyendo en la medida que se avanza en el análisis y diseño del problema y de la situación. Al usar la metodología, se pudo apreciar que se estaban corrigiendo algunas de las debilidades de CommonKADS y de RT-UML, pues la primera se dedica más a la fase de análisis del SBC y la segunda a la fase del diseño del STR, así que con CommonKADS-RT se ha tratado de fortalecer e integrar estas visiones para que cuando se requiere desarrollar un SBCTR se pueda tener herramientas a nivel del dominio del problema y de la solución. Por último, la actividad de analizar y diseñar sistemas para casos reales, como el del robot y el del puerto, ha permitido que se mejore las consideraciones metodológicas que se tenían, pues se fueron validando en caliente. Es decir, que en la medida que se iban desarrollando los casos, se iba modificando la metodología para que se ajustara mucho más a la práctica real de un proyecto de construcción de un SBCTR. Esto es el valor verdadero de mostrar la aplicación de una metodología, porque sino se convertiría en el simple desarrollo de un software mas. Es importante resaltar que si se quiere tener una metodología completa, que pueda ser usada para especificar los requerimientos del sistema, describir el entorno del sistema en donde será implementado (modelo conceptual - fase de análisis), definir la arquitectura del sistema futuro (fase de diseño) y especificar la plataforma de hardware, los protocolos de transferencia y de comunicación (fase de implementación), hay que mejorar CommonKADS-RT. Especialmente en lo que se refiere a esta última fase de implementación.

CommonKADS-RT – Capítulo 5. Conclusiones y trabajos futuros

211

Capítulo 5. Conclusiones y trabajos futuros 5.1

Introducción

El desarrollo de sistemas basados en el conocimiento de tiempo real involucra una serie de procesos y de componentes que requieren de una definición apropiada y un tratamiento adecuado. Es así, como un sistema basado en el conocimiento de tiempo real tiene un propósito específico, sigue una arquitectura definida e implica una serie de actividades que en cierta forma, pueden garantizar su aplicabilidad y utilidad. Este tipo de sistemas ha generado mucho interés en los últimos años, tanto en la comunidad científica como en la industria, y es básicamente porque sirven para solucionar problemas muy complejos que se presentan en diferentes entornos. Se han propuesto muchas arquitecturas para construirlos y se han desarrollado herramientas software que facilitan su realización. Las principales aportaciones han estado orientadas hacia la construcción misma del sistema, pero no se ha dedicado mucho esfuerzo en el desarrollo de propuestas de gestión de un proyecto de ese estilo, a su especificación, análisis, diseño de la solución e impacto. Es por esto, que se considera importante el contar con una metodología que permita guiar el proceso de desarrollo del proyecto y del sistema en forma clara y válida. A continuación se presentan las conclusiones más relevantes que se han obtenido después de realizar esta investigación. Éstas son el resultado, tanto del estudio de los sistemas basados en el conocimiento, de los sistemas de tiempo real, de los sistemas basados en el conocimiento de tiempo real y de las metodologías para el desarrollo de software en general, como de la aplicación que se hizo de la metodología. Adicionalmente, se presentan los trabajos futuros y las líneas de trabajo que se abren para complementar el alcance de esta investigación.

CommonKADS-RT – Capítulo 5. Conclusiones y trabajos futuros

5.2

212

Conclusiones generales

La conclusión más relevante de esta tesis es que la metodología CommonKADS-RT que se propone en esta investigación, es apropiada para el desarrollo de sistemas basados en el conocimiento de tiempo real estricto.

También es importante resaltar la viabilidad de adecuar metodologías existentes y reconocidas para el desarrollo de sistemas de software para el desarrollo de sistemas basados en el conocimiento de tiempo real. Es posible utilizar CommonKADS y RT-UML para modelar y diseñar sistemas basados en el conocimiento de tiempo real. Para llegar a esta conclusión se desarrolló un proceso incremental de investigación en el cual se fueron analizando diferentes metodologías para desarrollar sistemas basados en el conocimiento, sistemas de tiempo real y sistemas basados en el conocimiento de tiempo real.

La investigación se comenzó con el estudio de los sistemas basados en el conocimiento de tiempo real, su definición, los diferentes tipos de SBCTR, las arquitecturas más comunes y los métodos o metodologías que se utilizan para su desarrollo. Así, que una de las conclusiones más importantes de esta etapa de la investigación es que no hay una metodología completa en donde se conciban las características propias y específicas de los sistemas que manejan tanto el conocimiento como las restricciones temporales y que era necesario plantear una que fuera fácil de manejar, que estuviera basada en conceptos e ideas probadas y aceptadas, y que integrara los procedimientos de la ingeniería del software. No hay una metodología completa en donde se conciban las características propias y específicas de los sistemas que manejan tanto el conocimiento como las restricciones temporales

También durante el estudio de las áreas implicadas, se encontró que en los sistemas de tiempo real la mayoría del software que se desarrolla es a la medida, es decir, específico para la organización. En general, para su desarrollo no se siguen métodos o metodologías estándar que cubran todo el proceso y ciclo de vida de un sistema informático. Los métodos que hay son especializados en el diseño del STR, dejando de lado o por fuera lo que se refiere al análisis del problema y de su solución. Por lo tanto, muchas veces ocurre que este software sólo soluciona en parte el problema, pues no ha sido creado con una visión sistémica y holística. Así, que una conclusión importante sobre este tema es que es necesario proponer, diseñar y aplicar metodologías completas para el desarrollo de sistemas de tiempo real. Es necesario proponer, diseñar y aplicar metodologías completas para el desarrollo de sistemas de tiempo real.

CommonKADS-RT – Capítulo 5. Conclusiones y trabajos futuros

213

Obviamente, ya se cuenta con RT-UML que es una muy buena alternativa metodológica para el desarrollo de los STR. Así, que si ésta es mejorada en cuanto a la fase de análisis y adoptada por la OMG (Object Management Group), se tendría un estándar metodológico que podría orientar el buen desarrollo de estos sistemas. El paradigma de desarrollo de modelos para el análisis y diseño de una aplicación ha sido una de los grandes aportes que se han tomado de los sistemas basados en el conocimiento, particularmente de CommonKADS. Después de estudiar a fondo esta metodología, se puede concluir que su aporte, sus planteamientos y su aplicación son muy valiosos, tanto para el área de la inteligencia artificial, como de la informática en general y muy especialmente de la gestión organizacional en la era del conocimiento. CommonKADS tiene un impacto muy positivo y permite que se utilice en diversas situaciones, no exclusivas de los SBC. La aportación, los planteamientos y la aplicación de CommonKADS son muy valiosos, tanto para el área de la inteligencia artificial, como de la informática en general y muy especialmente de la gestión organizacional en la era del conocimiento.

Otra conclusión importante es que el dominio de los sistemas basados en el conocimiento de tiempo real tiene mucha aplicación en situaciones reales de las organizaciones, así que es necesario tener métodos y metodologías que permitan guiar su construcción. Las que se conocen actualmente, presentan algunos inconvenientes, bien sea en el tratamiento del tiempo real o en la fundamentación del conocimiento. Se necesitan metodologías que conduzcan el desarrollo de sistemas basados en el conocimiento de tiempo real, lo que permitiría que se difunda más esta tecnología.

Un alternativa que se puede plantear para formalmente introducir características temporales basadas en el conocimiento, es crear un grupo de interés similar al creado para tiempo real en la OMG, el cual se encargaría de estandarizar el vocabulario, las arquitecturas y los métodos y metodologías apropiados para el fortalecimiento de este dominio. Crear un grupo de interés en la OMG para que trabaje alrededor de los sistemas basados en el conocimiento de tiempo real

Finalmente, se pudo comprobar que una metodología es buena, en la medida en que: proporcione las herramientas específicas y apropiadas para la construcción de un sistema, en que se sigan sus pasos y recomendaciones, y se documenten las actividades realizadas. Además, la elección de la metodología dependerá del dominio del problema, del tipo de solución, del conocimiento de los analistas y desarrolladores, del interés y apoyo que todo el grupo de participantes le pongan al proceso planteado en ella, y del alcance de la metodología. Por tanto se concluye que estos aspectos son los más relevantes para considerar una metodología en el desarrollo de sistemas informáticos.

CommonKADS-RT – Capítulo 5. Conclusiones y trabajos futuros

214

El dominio del problema, el tipo de solución, el conocimiento del grupo de desarrollo, el interés y apoyo organización, y el alcance de la metodología son los aspectos más relevantes que se deben considerar en una metodología para el desarrollo de sistemas informáticos. En este caso, CommonKADS-RT se ha definido para un dominio en donde el conocimiento bajo restricciones temporales y con plazos de tiempo predeterminados es la característica fundamental. La valoración que se haga de los criterios de filtrado dará con cierto grado de certeza que la mejor alternativa de solución es un sistema basado en el conocimiento de tiempo real. El grupo de desarrollo debe tener conocimiento sobre este tipo de problemas y soluciones, así como del desarrollo de modelos, de evaluación de riesgos y del lenguaje de modelado unificado. Y obviamente, para que CommonKADS-RT y los artefactos producidos durante su aplicación tengan éxito se debe contar con el apoyo de la alta gerencia, de los expertos en el dominio y de los expertos en la solución. CommonKADS-RT incluye todos los elementos que la ingeniería del conocimiento propone para una metodología de desarrollo de software, con excepción de los mecanismos de decisión.

Desde el punto de vista de la ingeniería del software, en especial, del planteamiento de lo que debe ser una metodología para un proyecto informático, CommonKADS-RT cumple con la mayoría de ello. Sólo faltan proponer los mecanismos de decisión. Por lo tanto, se considera que es válida. En general, los métodos y metodologías de los SBC ponen énfasis en la fase de análisis y los de los STR lo ponen en la fase de diseño. CommonKADS-RT integra estos planteamientos pues cubre ambas fases, lo que falta es tratar la fase de implementación ampliamente. CommonKADS-RT cubre las fases de análisis y de diseño para el desarrollo de un sistema basado en el conocimiento de tiempo real

5.3

Contribuciones principales

El objetivo principal de esta investigación es la proposición de una metodología para el desarrollo de sistemas basados en el conocimiento de tiempo real. Es decir, crear unas consideraciones relacionadas con el análisis y el diseño de un sistema de ese tipo. En la introducción de esta memoria se definió que una metodología de software debería indicar: las actividades específicas a realizarse en el desarrollo del sistema (etapas), el orden en que éstas se debe realizar (ciclo de vida), las herramientas para realizar las actividades, los responsables de cada una de las etapas, los artefactos obtenidos, y las guías para tomar decisiones. Así, que de acuerdo con esto y con los objetivos planteados también al comienzo, se describirán las principales contribuciones de esta tesis:

CommonKADS-RT – Capítulo 5. Conclusiones y trabajos futuros

•

215

Contribuciones en relación con el área de los sistemas basados en el conocimiento de tiempo real

Como se planteó en el capítulo del estado del arte, en la sección de los sistemas basados en el conocimiento de tiempo real, para el desarrollo de estos no se dispone de muchas metodologías que permitan que su construcción sea más generalizada. Las que actualmente se conocen tienen una visión diferente del tratamiento del tiempo real, por lo que se considera que la metodología CommonKADS-RT es un aporte muy importante para lograr ese objetivo. CommonKADS-RT facilitará y permitirá que se construyan más sistemas basados en el conocimiento, lo que redundará en el desarrollo de muchas otras técnicas y herramientas alrededor de está área •

Contribuciones en relación con las guías de aplicación de la metodología CommonKADS-RT

Es importante tener una descripción global del proceso que se debe seguir para la utilización de la metodología deseada. Por ello, al comienzo en CommonKADS-RT se hace una descripción de ella misma, un planteamiento o esbozo general de las consideraciones metodológicas que se tienen para desarrollar un SBCTR. Así, el analista del problema y de la solución puede tener una idea general del proceso que deben llevar a cabo al utilizar la metodología, facilitando la elaboración de la propuesta del proyecto. Con CommonKADS-RT se adjunta una descripción general del proceso que se debe seguir en ella. Es un esbozo general de las actividades, técnicas y métodos necesarios para analizar y diseñar un SBCTR

Continuando con los aspectos globales que enmarcan la metodología, hay una aportación importante en relación con la aplicación de CommonKADS-RT. Se ha considerado fundamental, y en este caso se resalta por servir de ayuda y porque la mayoría de las metodologías no lo contemplan, la caracterización del dominio en donde es adecuado utilizar CommonKADS-RT. Es decir, la especificación de las propiedades particulares que debe tener el dominio en donde se quiere desarrollar un SBCTR utilizando como marco metodológico CommonKADS-RT. Se han definido unas características del dominio que es apropiado para la aplicación de CommonKADS-RT

Durante la investigación se encontró que en las diferentes áreas involucradas en la misma, y a pesar de estar todas ellas dentro del ámbito de la informática, existen grandes diferencias en cuanto al manejo de los términos y de los conceptos. Por ejemplo, lo que para unos es el concepto de tarea, para otros es completamente diferente. Por eso, se decidió hacer una serie de ajustes que permitieran tener unos conceptos unificados para los sistemas basados en el conocimiento y los sistemas de tiempo real.

CommonKADS-RT – Capítulo 5. Conclusiones y trabajos futuros

216

Esto también ocurre en cuanto a lo que se considera como una metodología y un método en la ingeniería del conocimiento, los sistemas basados en el conocimiento y la ingeniería del software. Por lo tanto, uno de los aportes de esta investigación, es la distinción y eliminación de ambigüedad de los conceptos que se manejan dentro del área de los sistemas basados en el conocimiento de tiempo real, definiendo desde el comienzo de la metodología, y en particular en cada uno de los modelos que la conforman, el vocabulario específico. En CommonKADS-RT se maneja una terminología específica para los sistemas basados en el conocimiento de tiempo real y para lo que es una metodología de desarrollo de software, lo cual es consistente y no ambigua. •

Contribuciones en relación con los modelos de CommonKADS-RT

Se ha decidido que para cada uno de los modelos que conforman CommonKADS-RT se tenga una lista de los artefactos que se producen durante el desarrollo del mismo. De esta forma, cuando se comienza con el desarrollo de un modelo se sabe desde el comienzo qué es lo que se debe obtener al final. Así que esta clave o guía se puede ver como un criterio de calidad del modelo, para determinar en qué estado se está en su construcción y para facilitar la determinación de su punto final, pues si ya se tienen todos los artefactos y además estos están completos, entonces se puede asumir que el modelo está terminado. Este es un aporte muy valioso. Por otra parte, es importante tener herramientas que permitan evaluar cuál de las situaciones presentes en la organización es la más importante o urgente de tratar, de acuerdo con la misión, visión y los factores críticos de éxito que se tengan definidos en la misma empresa. Para ello, en el modelo de la organización se ha propuesto la inclusión de la matriz DAFO, herramienta de la planificación estratégica, que guía y facilita la identificación de aspectos relevantes y actuales de la organización, dándole un valor agregado a la metodología CommonKADS-RT, pues además de posibilitar el desarrollo de un SBCTR, es útil para hacer el análisis actual del dominio organizacional. En el modelo de la organización se ha propuesto la inclusión de la matriz DAFO, herramienta de la planificación estratégica, que guía y facilita la identificación de aspectos relevantes y actuales de la organización, dándole un valor agregado a la metodología CommonKADS-RT. Cuando se va a solucionar una situación o problema que ocurre en una organización, es necesario contar con las herramientas apropiadas para llevar a cabo el análisis del mismo, con el objetivo de plantear alternativas que realmente sí lo corrijan e incluso permitan mejorarlo. Es así, como es importante contar con unos criterios que le sirvan de guía a los desarrolladores para evaluar si cierta alternativa informática será viable de aplicar en un caso específico. Es por ello que se han propuesto unos criterios de filtrado que apoyan dicho proceso. Los criterios de filtrado son una aportación significativa de esta investigación. Permiten evaluar con anticipación, la pertinencia de

CommonKADS-RT – Capítulo 5. Conclusiones y trabajos futuros

217

proponer como solución un sistema basado en el conocimiento de tiempo real ante cierta situación. Se ha considerado trascendental que desde el comienzo del estudio del problema se planteen interrogantes relacionados con el manejo del conocimiento y de las especificaciones temporales, pues esto determinará, en cierta medida, el tipo de solución más conveniente. En este sentido, otro aporte relacionado con el modelo de la organización es que se ha definido un nuevo formulario y se han incluido en los demás, variables temporales que permiten definir, a un alto nivel de abstracción, estas características especiales. En el modelo de la organización se han introducido muchos cambios relacionados específicamente con el manejo del tiempo, de las restricciones temporales. Además, se ha incluido una lista de eventos externos que tienen relación con el sistema y un nuevo formulario para hacer la descripción de los aspectos de la organización que tendrán impacto o estarán afectados por la solución escogida del SBCTR.

En el modelo de agentes se ha introducido la tipología de los agentes, humanos y software. El primero se denomina actor y para los segundos se han clasificado en agentes que se encargan de percibir el entorno, agentes que hacen procesos de razonamientos o cognición y de agentes que realizan acciones sobre el entorno. Esta clasificación de los agentes posibilita el tener diferentes métodos para su modelado y manejo, el seguir con una terminología más cercana al lenguaje de modelado unificado, y el servir de acercamiento al paradigma de agentes inteligentes. En el modelo de agentes se distinguen los actores de los agentes de percepción, de cognición y de acción.

En el modelo de comunicación se ha propuesto el manejo de los estándares de comunicación de agentes FIPA, proporcionando la universalidad y el cubrimiento de la comunicación posible entre los diferentes agentes del SBCTR. Incluir FIPA en el modelo de comunicaciones, haciendo que las transacciones y los mensajes sean de una manera estándar. La fase de diseño quizá es una de las mayores aportaciones de este trabajo, ya que ésta no ha sido muy trabajada para los sistemas basados en el conocimiento de tiempo real. En ella se han incluido dos modelos: el de diseño y el de tareas de tiempo real. Los aportes han sido varios: • Tener una arquitectura para el SBCTR, específicamente ARTIS. • Definir una estructura para la tarea de tiempo real, siguiendo un MKS. • Especificar el diseño detallado de la aplicación. • Considerar la realización del test de planificabilidad, aunque no se explique en detalle.

CommonKADS-RT – Capítulo 5. Conclusiones y trabajos futuros

218

Se propone una arquitectura para el SBCTR, una estructura para las tareas de tiempo real y el diseño detallado de la aplicación.

5.4

Trabajos futuros

Se proponen las siguientes líneas de trabajo: •

•

En las áreas de los sistemas basados en el conocimiento y de los sistemas de tiempo real −

En el área de los sistemas de tiempo real se debería construir o definir una ontología para ese tipo de sistema, con el objetivo de fijar los conceptos y el conocimiento del dominio de tiempo real en una forma genérica para tener un acuerdo común que pueda ser compartido por todos los grupos de investigación, evitando que se difundan y propaguen erróneamente.

−

Fomentar la consideración y el estudio de los sistemas de conocimiento por parte de la OMG y de la empresa RATIONAL para que así como hay extensiones de UML para tiempo real, también se tenga unas para sistemas basados en el conocimiento.

En el área de los sistemas basados en el conocimiento de tiempo real −

Complementar y crear una conceptualización – ontología -, específicamente para la aplicación de los sistemas basados en el conocimiento de tiempo real, en la que se definan claramente los conceptos que en este tipo de sistemas se manipulan, eliminando la ambigüedad y duplicidad, y posibilitando la reutilización de componentes del modelo.

−

Analizar las tareas intensivas en conocimientos que proponen [SAA+00] desde el punto de vista del manejo de restricciones temporales y el cumplimiento de límites de tiempo para su ejecución, entre otras. Esto implica revisar las características generales, los métodos, las variables de entrada y las de salida de cada uno de los tipos de tarea. Como resultado se podrán tener plantillas para tareas intensivas en conocimientos de tiempo real, lo cual sería de mucha utilidad para cuando se va a construir un sistema basado en el conocimiento de tiempo real, utilizando CommonKADS-RT.

−

Diseñar métodos de solución de problemas (PSM) para tareas específicas de este tipo de sistemas, bien sea adecuando los que hay para los sistemas basados en el conocimiento para que incluyan y manejen restricciones temporales o proponiendo unos nuevos que sean de ese propósito específico. En especial, sería para las tareas de planificación, scheduling y valoración.

CommonKADS-RT – Capítulo 5. Conclusiones y trabajos futuros

•

•

219

En la metodología CommonKADS-RT −

Desarrollar una herramienta software que traduzca directamente la nueva especificación de CommonKADS-RT al lenguaje de bajo nivel de ARTIS. De esta forma se reduciría el tiempo de desarrollo del sistema e incluso se evitarían errores en la codificación.

−

Analizar la aplicación de ARTIS para cada uno de los tipos de tareas intensivas en el conocimiento. Esto puede implicar la realización del segundo trabajo propuesto para el área de los sistemas basados en el conocimiento de tiempo real, mas la revisión y adecuación de la arquitectura.

−

La metodología CommonKADS- RT puede ser mejorada, si se le adicionan criterios específicos para el diseño detallado del SBCTR, en especial para la elección, elaboración y ejecución del análisis de desempeño y tests de planificabilidad. Esto es muy importante porque para que la implantación de un SBCTR tenga éxito se debe garantizar el cumplimiento de la planificación de las tareas de tiempo real, en cuanto a su ejecución y al tiempo de las mismas.

−

Aplicar la metodología en muchos más casos para obtener conclusiones que puedan ser generalizadas y aplicadas a la misma metodología. Además que esto permitiría que se difundieran más los sistemas basados en el conocimiento de tiempo real y que estuvieran al alcance de organizaciones que los podrían utilizar en su que-hacer diario.

En otras áreas de la informática −

Dado el auge y la aplicabilidad que tiene en la actualidad el paradigma de los sistemas multiagentes, es posible migrar o adecuar la metodología CommonKADS-RT a una metodología que guíe el proceso de análisis, diseño construcción e implantación de sistemas basados en agentes inteligentes de tiempo real.

CommonKADS-RT – Abreviaturas

221

ABREVIATURAS AIS AM ARTIS ASSET CIRCA CM CML DAFO DARTS DM ESA E/S ESSOC FLES FRISCO HPM HRT-HOOD Hz IA IC IPTES KADS KM KRL KSL KSM LDP MCSE MIKE mm ms MVC OM OMG OMT PM PSM RAE RAM REAKT ROOM ROPES RT-UML RTTM

Adaptative Intelligent Systems Agent Model Arquitectura para Sistema de Tiempo Real Inteligente. Aerospace Systems Simulation, Engineering, and Test tool Cooperative Intelligent Real-time Control Architecture Communication Model Conceptual Modeling Language Debilidades, Amenazas, Fortalezas y Oportunidades Design Approach for Real-Time Systems Design Model European Spatial Agency Entrada / Salida Expert System for Satellite Orbit Control Flight Expert System A Framework of Information Systems Concepts Hartley Pirbhai Method Hard Real-Time Hierarchical Object Oriented Design Hertz Inteligencia Artificial Ingeniero del Conocimiento Incremental Prototyping Technology for Embedded Real-Time Systems Knowledge Acquisition Design System Knowledge Model Knowledge Representation Language Knowledge System Language Knowledge Structure Manager Language Design Program Méthodologie de Conception des Systèmes Electroniques Model-based and Incremental Knowledge Engineering milímetro milisegundo Model - View - Controller Organization Model Object Management Group Object Modeling Technique Project Management Problem Solving Method Real Academia Española REAKT Application Methodology An Environment for Real-Time Knowledge-Based Systems Real-Time Object-Oriented Modeling Rapid Object-Oriented Process for Embedded Systems Real-Time - Unified Modeling Language Real-Time Task Model

CommonKADS-RT – Abreviaturas

STR SBC SBCTR TAN TM TOPKAT TTR UML V VDC

Sistema de Tiempo Real Sistema Basado en el Conocimiento Sistema Basado en el Conocimiento de Tiempo Real Tarea de Alto Nivel Task Model The Open Practical Knowledge Acquisition Toolkit Tarea de Tiempo Real Unified Modeling Language Voltio Volt Direct Current

222

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, KADSII/T1.2/TR/UvA/37/1.0, University of Amsterdam. 1992.

[Abe93]

M. Aben. Formally Specify Re-usable Knowledge Model Components. Knowledge Acquisition Journal, 5. 1992. pp. 119-141.

CommonKADS-RT – Referencias

[AFL+93]

224

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 KnowledgeBased Systems with MIKE. In Journal of Automated Software Engineering, 5 (4). 1998. pp. 389-418. http://www.aifb.uni-karlsruhe.de/WBS/publications/index.html

[AFS90]

J. Angele, D. Fensel, R. Studer. Applying Software Engineering Methods and Techniques to Knowledge Engineering. In D. Ehrenberg et al. (eds.), Wissenbasierte Systeme in der Betriebswirtschaft, Reihe Betriebliche Informations - und Kommunikationssysteme. No. 15, Erich Schmidt Verlag. Berlin. 1990. pp. 285-304.

[AFS93]

J. Angele, D. Fensel, R. Studer. Formalizing and Operationalizing Models of Expertise with KARL. Institut fur Angewandte Informatik und Formale Beschreibungsverfahren, University of Karlsruhe. Research report. 1993.

[AFS96]

J. Angele, D. Fensel and R. Studer. Domain and Task Modeling in MIKE. In: A.G. Stucliffe, F. van Assche and D. Benyon (eds.): Domain Knowledge for Interactive System Design, Proceedings of IFIP WG 8.1/13.2 Joint Working Conference, Geneva, 1996, Chapman & Hall. 1996. 17 p. http://www.aifb.uni-karlsruhe.de/WBS/publications/index.html

[AKS+93]

S. Aitken, O. Kuhn, N. Shadbolt, et al. A Conceptual Model of Hierarchical Skeletal Planning and its Formalization. In Proceedings of the 3rd KADS Meeting, Munich. 1993.

[Anj99]

A. Anjewierden. Engineering and Managing Knowledge. 1999 http://www.commonkads.uva.nl/

[AnS94]

A. Anjewierden, G. Schreiber. CML2 syntax (2.2.1). SWI, University of Amsterdam. 1994. 6 p. http://www.swi.psy.uva.nl/projects/kads22

CommonKADS-RT – Referencias

[AVS+93]

225

H. Akkermans, F. Van Harmelen, G. Schreiber, et al. A Formalization of Knowledge Level Models for Knowledge Acquisition. In International Journal of Intelligent Systems. Special Issue on Knowledge Acquisition, No. 2, Vol. 8. 1993.

[Bac95]

G. Baca. Evaluación de Proyectos. 3 ed. México: McGraw-Hill, 1995. 339 p.

[BaK92]

C. Bauer, W. Karbach (eds.). Interpretation Models for KADS. Proceedings of the 2nd KADS User Meeting (KUM92). Munich. GMD Report No. 212. 1992.

[BeM97]

R. Benjamins, A. Manfred. Structure-preserving Knowledge-Based System Development through Reusable Libraries: A Case Study in Diagnosis. 1997. pp. 259-288.

[Ben90]

T. Bench-Capo. Knowledge Representation: An Approach to Artificial Intelligence. Academic Press, London. 1990. 221 p.

[Ben93]

R. Benjamins. Problem Solving Methods for Diagnosis. PhD thesis, University of Amsterdam, Amsterdam, The Netherlands. 1993 172 p. ISBN 90-9005877-X.

[BFP+97]

R. Benjamins, D. Fensel, C. Pierret-Golbreich, et al. Making Knowledge Engineering Technology Work. 1997. http://www.aifb.uni-karlsruhe.de/WBS/publications/pub97.html

[Boe93]

B. W. Boehm. A Spiral Model of Software Development and Enhancement. In R. Donald, ed. Software Management. IEEE Computer Press. 1993. pp. 120-131.

[BrV94]

J. Breuker and Van de Velde. CommonKADS Library for Expertise Modeling;

Reusable

problem

solving

components.

IOS

Press,

Amsterdam, 1994. 359 p. [BrW89]

J. Breuker, B. Wielinga. Models of Expertise in Knowledge Acquisition. In G. Guida et al. (eds.), Topics in Expert Systems Design. Elsevier Science Publisher B. V., North Holland. 1989. pp. 265-295.

[CaP96]

C. Cadas, N. Parthenios. Catalyst - Use of CommonKADS Methodology in Knowledge Nased Systems Development. Final Report. 1996. 54 p.

CommonKADS-RT – Referencias

[CuM96]

226

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 KADSII, 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, KADSII/M1/DM1.1b/UvA/018/6.0/FINAL, University of Amsterdam. 1994. 31 p.

[Dom97]

J. Domingue. VITAL Workbench. Knowledge Media Institute U.K. http://kmi.open.ac.uk/~john/vital/vital.htm

[Duu94]

C. Duursma. Task Model Definition and Task Analysis Process. Technical

Report

ESPRIT

Project

P5248

KADS-II,

KADS-

II/M5/VUB/RR/004/2.0, Vrije University of Brussels. 1994. 44 p. [Edm88]

R. Edmunds. The Prentice Hall Guide to Expert Systems. New Jersey: Prentice Hall, 1988. 364 p.

[EPG+94]

H. Erikson, A. Puerta, J. Gennari et al. Custom-Tailored Development Tools for Knowledge-Based Systems. Technical Report KSL-94-67. Stanford University, USA. 1994. 18 p.

[FAL91]

D. Fensel, J. Angele, D. Landes. KARL: A Knowledge Acquisition and Representation Language. In Proceedings of Expert Systems and their Applications,

11th

International

Workshop,

Conference "Tools,

Techniques & Methods", 27-31 May, Avignon. 1991. pp. 513-528. [FAL+93]

D. Fensel, J. Angele, D. Landes, R. Studer. Giving Structured Analysis Techniques a Formal and Operational Semantics with KARL. In Proceedings of Requirements Engineering 93 – Prototyping -, Teubner Verlag, Stuttgart. 1993.

CommonKADS-RT – Referencias

[FAL98]

227

D. Fensel, J. Angele, D. Landes. A Knowledge Acquisition and Representation Language. IEEE Transactions on Knowledge and Data Engineering, Vol. 10, No 4. July/August 1998. pp. 527-550.

[FBM+99]

D. Fensel, R. Benjamins, E. Motta, et al. UPML A Framework for Knowledge System Reuse. In Proceeding of the International Joint Conference on AI (IJCAI-99). Stockholm, Sweden. 1999.

[FMB+00]

D. Fensel, E. Motta, R. Benjamins, et al. The Unified Problem-Solving Method Development Language UPML. Draft. The Netherlands. 2000. 58 p. http://www.cs.vu.nl/~dieter/drafts.html

[GAM94]

J. Gennari, R. Altman, M. Musen. Reuse with Protégé-II: From Elevators to Ribosome. Stanford University School of Medicine. 1994. 9 p. http://smi-web.stanford.edu/pubs/SMI_Reports/SMI-94-0549.pdf

[Gia89]

J. Giarretano. Expert Systems: Principles and Programming. Boston: PWS-Kent Publishing Company, 1989. 632 p.

[GuT94]

G. Guida, C. Tasso. Design and Development of Knowledge Based Systems. England : John Wiley & Sons. 1994. 476 p.

[Guz96]

J. Guzmán. Modelo Integrado Hipermedia y Basado en Conocimiento de Apoyo al Desarrollo de Aplicaciones Informáticas. Tesis de Maestría Ingeniería de Sistemas. Universidad Nacional de Colombia, Sede Medellín. Facultad de Minas. Medellín, 1996.

[HaB92]

F. V. Harmelen, J. Balder. (ML)2: A formal language for KADS conceptual models. In Knowledge Acquisition, Vol. 4, no 1, March 1992. pp. 127-161.

[Har92]

A. Hart. Knowledge Acquisition for Expert Systems. 2ª ed. Estados Unidos; McGraw-Hill, 1992.

[Hen97]

M. Henao. Metodología para el Desarrollo de la Tecnología de Sistemas Intelimedios. Tesis de la Maestría en Gestión de Tecnologías, Universidad Pontificia Bolivariana, Medellín, Colombia. 1997. 238 p.

[HKL+89]

F. Hickman, J. Killin, L. Land, et al. Analysis for Knowledge-Based Systems: A Practical Guide to the KADS Methodology. Ellis Horwood, England. 1989. 190 p.

CommonKADS-RT – Referencias

[Igl98]

228

C. Iglesias. Definición de una metodología para el desarrollo de sistemas multiagentes. Tesis Doctoral, Universidad Politécnica de Madrid, España. 1998. 294 p.

[Kin94]

J. Kingston. Linking Knowledge Acquisition with CommonKADS Knowledge Representation. AIAI-TR-156. 1994. 21 p. ftp://ftp.aiai.ed.ac.uk/pub/documents/1994/

[McH89]

K. McGraw, K. Harbinson-Briggs. Knowledge Acquisition: Principles and Guidelines. New Jersey: Prentice-Hall, 1989. 166 p.

[MoC95]

M. Molina, J. Cuena. Knowledge Oriented Design and Object Oriented Design: The Experience of KSM. Proc. Of Knowledge Acquisition of Knowledge Based Systems Workshop, KAW95. Banff, Canada. 1995.

[MOS+95]

E. Motta, K. O´Hara, N. Shadbolt, et al. Solving VT in VITAL: A Study in Model Construction and Knowledge Reuse. In International Journal of Human-Computer Studies, Special Issue on the VT Elevator Design Problem. Vol. 44 (3-4). March-April 1996. 34 p. http://www2.kmi.open.ac.uk/tr/tr.cfm?trnumber=4

[Neu93]

S. Neubert. Model Construction in MIKE. Paper in Lecture Notes of Artificial Intelligence. (N. Aussenac G. Boy B. Gaines M. Linster J.-G. Ganascia Y. Kodratoff (Eds.) Knowledge Acquisition for KnowledgeBased Systems, 7th European Workshop, EKAW ’93. Springer-Verlag. France, 1993. pp. 200-219.

[New82]

A. Newell. The Knowledge Level. Artificial Intelligence No. 18. 1982. pp. 87-127.

[NoM99]

N. Noy, M. Musen. Empirical Studies of Knowledge Acquisition. SMI Colloquim, Stanford, California, USA. 1999. 59 p. http://smiweb.stanford.edu/projects/protege/talks/EmpiricalEvaluation/ind ex.htm

[Pri93]

J. Priece. A Guide to Usability: Human Factors in Computing. The United States of America: Addison-Wesley, 1993. 144 p.

[SAA+98]

A. Schreiber, J. Akkermans, A. Anjewierden, et al. CommonKADS, Engineering of Knowledge; The CommonKADS Methodology [version 0.5]. Amsterdam: Department of Social Science Informatics, University of Amsterdam, 1998. 285 p.

CommonKADS-RT – Referencias

[SAA+00]

229

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

[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 KADSII, KADS-II/M3/SICS/TR/006/V.2.0. Swedish Institute of Computer Science, Stockholm, 1993. 96 p.

[WSB92]

B. Wielinga, A. Schreiber, J. Breuker. KADS: A Modeling Approach to Knowledge Engineering. In Knowledge Acquisition Journal, Vol. 4, no 1, March 1992. pp. 5-53.

CommonKADS-RT – Referencias

[WVS+92]

230

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 RealTime Ada. Department of Computer Science, University of York, UK, File: YCS199.ps.Z . 1994. 44 p.

[Cal97]

J.P. Calvez. Specification and Design of Embedded Real-time Systems; MCSE Methodology. 1997. http://www.ireste.fr/mcse/htmlan

[Del97]

J.A. de la Puente. Diseño de sistemas de tiempo real - Introducción a HRT-HOOD. Madrid. 1997. ftp://ftp.dit.upm.es/str/software/mine.tar.gz

CommonKADS-RT – Referencias

[Deu88]

231

M. Deutsch. Focusing Real-Tome Systems Analysis on User Operations. IEEE Software, Sept. 1988. pp. 39-50

[Dou98]

B. P. Douglass. Real-Time UML. Addison-Wesley, United States of America. 1998. 365 p.

[Dou99]

B. P. Douglass. Doing Hard Time; Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns. Addison-Wesley, United States of America. 1999. 749 p.

[Dou00]

B. P. Douglass. The UML for Systems Engineering. I-Logix Technical paper,

The

United

States

of

America.

2000,

12

p.

http://www.ilogix.com/whitepapers_c.htm [Ell94]

J. Ellis. Objectifying Real-Time Systems. Cambridge University Press. The United States of America. 1994. 542 p.

[Gom84]

H. Gomaa. A Software Design Method for Real-Time Systems. Communications of the ACM, Vol. 27 Nº 9. 1984. pp. 938-949.

[Gom86]

H.

Gomaa.

Software

Development

of

Real-Time

Systems.

Communications of the ACM, Vol. 29 Nº 7. 1986. pp. 657-668. [Gom89]

H. Gomaa. Software Design Methods for Real-Time Systems. George Mason University. USA. 1989. 45 p. http://www.sei.cmu.edu/publications/documents/cms/cm.022.html

[HaH94]

K. Haggerty, L. Haggerty. Introduction to Structured Methods. H&A Systems Engineering. USA. http://www.hasys.com/tutorials/index.html

[HaP88]

D. Hatley, I. Pirbhai. Strategies for Real-Time System Specification. New York, Dorset House Publishing. 1988. 386 p.

[Har87]

D. Harel. Statecharts: A Visual Formalism for Complex Systems. Science of Computing Programming 8, 1987. pp. 231-274.

[Hil99]

N. Hillary. Bringing the Gap between Requirements and Design with Use Cases and Scenarios. I-Logix, Inc. – Rhapsody Technical Papers. 11 p. http://www.ilogix.com/door_paper.htm

[KaY92]

K. Kavi, S. Yang. Real-Time Systems Design Methodologies: An Introduction and a Survey. En: Real-Time Systems; Abstractions, Languages, and Design Methodologies. USA : IEEE Computer Society Press, 1992. 660 p.

CommonKADS-RT – Referencias

[Lap92]

232

P. Laplante. Real-Time Systems Design and Analysis; An Engineer’s Handbook. IEEE Computer Society Press. Los Alamitos, 1992. 339 p.

[Lee92]

M. Lee. Object-Oriented Analysis in the Real World. Project Technology, Inc. San Leandro, California. 1992. 11p. http://www.projtech.com

[LuB88]

Luqi, V. Berzins. Rapidly Prototyping Real-Time Systems. IEEE Software, Vol. 5 Nº5, Sept 1988. pp. 25-36.

[Mul97]

P.A. Muller. Modelado de objetos con UML. Francia, 1997. 381 p.

[OMG99]

OMG Unified Modeling Language Specification (draft). Version 1.3 beta R7. Object Management Group, The United States of America. June 1999. 798 p.

[Pol00]

POLIS. A Framework for Hardware-Software Co-Design of Embedded Systems. Berkeley University. 2000. http://www-cad.eecs.berkeley.edu/research/hsc/

[Pre98]

R. Pressman. Ingeniería del Software; Un Enfoque Práctico. 4 Ed. España: McGraw-Hill, 1998. 581 p.

[RaH00]

J. Rader, L. Haggerty. Supporting Systems Engineering with Methods and Tools: A Case Study. Hughes Aircrafts and H&A Systems Engineering. 2000. pp. 1330-1334. http://www.hasys.com/cases/asilomar.pdf

[Rip98]

I. Ripoll. Real-Time Linux (RT-Linux). Revista Linux Focus. http://www.linuxfocus.org/Castellano/May1998/article4.html

[RTM96]

REAL-TIME MANIFESTO. http://www.realtime-os.com/rtmanifesto/

[San94]

J.M. Sanz. IPTES: Tecnología de prototipado incremental para sistemas de tiempo real empotrados. Especial Tecnología Software Nº 9. Comunicaciones

de

Telefónica

I+D.

Madrid,

España.

21

p.

http://www.tid.es/presencia/publicaciones/comsid/esp/articulos/home.ht ml [Sel92]

B. Selic. Real-Time Object-Oriented Modeling. ObjectTime. Ontario, Canada. 1992. 27 p. http://www.objectime.com/otl/technical/

CommonKADS-RT – Referencias

[Sel96a]

233

B. Selic. An Efficient Object-Oriented Variation of the Statecharts Formalism for Distributed Real-Time Systems. ObjectTime. Ontario, Canada. 1996. 8 p. http://www.objectime.com/otl/technical/

[Sel96b]

B. Selic. Periodic Tasks in ROOM. ObjectTime. Ontario, Canada. 1996. 4 p. http://www.objectime.com/otl/technical/

[SFR98]

M. Saksena, M. Freedman, P. Rodziewicz. Guidelines for Automated Implementation of Executable Object Oriented Models for Real-Time Embedded Control Systems. 13 p. http://citeseer.nj.nec.com/204508

[SGW94]

B. Selic, G. Gullekson, P. Ward. Real-Time Object-Oriented Modeling. John Wiley & Sons. The United States of America. 1994. 507 p.

[ShC94]

K. Shere, R. Carlson. A Methodology for Design, Test, and Evaluation or Real-Time Systems. IEEE Computer. February 1994. pp. 35-48.

[SkG89]

D.B. Skillicorn, J.I. Glasgow. Real-Time Specification Using Lucid. IEEE Transactions on Software Engineering, Vol. 15 Nª 2. 1989. pp. 221-229.

[Sta88]

J. Stankovic. Misconceptions About Real-Time Computing. IEEE Computer, Vol. 21 N. 10, Oct. 1988. pp10-19.

[Sta92]

J. Stankovic. Distributed Real-Time Computing: The Next Generation. MIT, USA: Technical Report 1992-001, 1992. 16 p.

[StR93]

J. Stankovic, K. Ramamritham. What is the Predictability for Real-Time Systems? Advances in Real-Time Systems. Edited by: John A. Stankovic and Krithi Ramamritham. IEEE Computer Society Press, California. 1993. 777 p.

• Sistema basado en el conocimiento de tiempo real [AlS85]

M. Ali, D. Scharnhorst. Sensor-Based Fault Diagnosis in a Flight Expert System. In Proceedings of the Second Conference on Artificial Intelligence Applications. Washington D.C., IEEE Computer Society. 1985. pp. 49-52.

CommonKADS-RT – Referencias

[BBE+82]

234

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

[Hay95]

B. Hayes-Roth. An Architecture for Adaptative Intelligent Systems. Artificial Intelligence, 72. 1995. pp. 329-365.

[HHC90]

A. Howe, D. Hart, P. Cohen. Addressing Real-Time Constraints in the Design of Autonomous Agents. Journal of Real-Time Systems. 2(1/2). 1990. pp. 81-97.

[IGR92]

F. Ingrand, M. Georgeff, A. Rao. An Architecture for Real-Time Reasoning ans System Control. IEEE Expert, 7(6), 1992. pp 34-44.

[KeM94]

D. Kersula, A. Mensch. REAKT: A Real-Time Architecture for Knowledge Based Systems. IFAC Artificial Intelligence in Real-Time Control. ISBN 84-7721-274-0. 1994. pp. 513-518.

[Laf91]

T.J. Laffey. The Real-Time Expert. Byte, Jan. 1991. pp. 259-264.

CommonKADS-RT – Referencias

[LCS+88]

235

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-TR94-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 KnowledgeBased Systems. 1990. http://apollo.cordis.lu/cordis-cgi/srchidadb.

[Rea93]

REAKT EP5146. Knowledge Acquisition report for the SARAS Demonstrator: semester S5. The Consortium REAKT. 1993. 54 p.

[RLN+91]

P. Rosenbloom, J. Laird, A. Newell, et al. A Preliminary Analisys of the SOAR Architecture as a Basis for General Intelligence. Artificial Intelligence, 47, 1991. pp 289-325.

CommonKADS-RT – Referencias

[RVK92]

236

M. G. Rodd, H. B. Verbruggen, A. J. Krijgsman. Artificial Intelligence in Real-Time Control. Engineering Applications Artificial Intelligence. Vol. 5, Nº 5. Great Britain. 1992. pp. 385-399.

[Sta92]

J. Stankovic. Advances in Real-Time Systems. California, IEEE Computer Society Press, 1992. 777 p.

[VHB97]

E. Vivancos, L. Hernández, V. Botti. Técnicas y Arquitecturas de Inteligencia Artificial en Tiempo Real. Madrid. Informática y Automática. Vol. 30 Núm. 4, Dic. 1997. pp. 5-22.

[VHB98]

E. Vivancos, L. Hernández, V. Botti. Construcción y Análisis Temporal de Sistemas Basados en Reglas para Entornos de Tiempo Real. VII Conferencia de la Asociación Española de Inteligencia Artificial, CAEPIA`97, España. 1998. pp. 675-684.

[ViB96]

E. Vivancos, V. Botti. Técnicas de Inteligencia Artificial en Tiempo Real. Reporte Técnico, Universidad Politécnica de Valencia. 1996. 9 p.

[Viv98]

E. Vivancos. Incorporación de agentes basados en reglas en una arquitectura para entornos de tiempo real. Propuesta de Tesis Doctoral, Universidad Politécnica de Valencia. 1998. 30 p.

•

CommonKADS-RT

[BHS99]

V. Botti, M. Henao, J. Soler. Método de análisis para modelar sistemas basados en el conocimiento en tiempo real. Memorias de la VIII Conferencia de la Asociación Española para la Inteligencia Artificial, CAEPIA'99. Murcia, España. 1999. pp. 17-25.

[Bot00]

V. Botti. Agentes Inteligentes de Tiempo Real: Control Voraz. Documentos interno DSIC, Universidad Politécnica de Valencia, España. 2000. 65 p.

[DeH98]

R. De Hoog. List of Frequency Encounter Project Risks. Technical report SWI, Social Science Informatics, University of Amsterdam. 1998. 14 p.

[Fip00]

FIPA – The Foundation for Intelligent Physical Agents. 2000. http://www.fipa.org/

CommonKADS-RT – Referencias

[Fip01a]

237

Foundation for Intelligent Physical Agents. FIPA Interaction Protocol Library

Specification.

Geneve,

Switzerland.

Document

number

XC00025D. 2001. 24 p. http://www.fipa.org/specs/fipa00025/ [Fip01b]

Foundation for Intelligent Physical Agents. FIPA Abstract Architecture Specifications. Geneve, Switzerland. Document number XC00001. 2001. 62 p. http://www.fipa.org/specs/fipa00001/

[Gar96]

A. García-Fornés. ARTIS: Un modelo y una arquitectura para sistemas de tiempo real inteligentes. Tesis Doctoral, Universidad Politécnica de Valencia, España. 1996. 149 p.

[Igl98]

C. Iglesias. Definición de una metodología para el desarrollo de sistemas multiagentes. Tesis Doctoral, Universidad Politécnica de Madrid, España. 1998. 294 p.

[JGR+00]

V.J. Julián, M. González, M. Rebollo, et al. InSiDE: una herramienta para el desarrollo de Agentes ARTIS. Simposium Español de Informática Distribuida. Ourense, España. 2000. pp 79-87.

[Por97]

M. Porter. Ventaja competitiva; Creación y sostenimiento de un desempeño superior. México: Compañía editorial Continental S.A. 1997. 550 p.

[SAA+98]

A. Schreiber, J. Akkermans, A. Anjewierden, et al. CommonKADS, Engineering of Knowledge; The CommonKADS Methodology [version 0.5]. Amsterdam: Department of Social Science Informatics, University of Amsterdam, 1998. 285 p.

[VDS+94]

W. Van de Velde, C. Duursma, G. Schreiber et al. Design Model and Process.

ESPRIT

Project

P5248

KADS-II,

KADS-

II/M7/VUB/RR/064/2.1. 1994. 230 p. [ViB97]

E. Vivancos, V. Botti. Compiling Rule-Based Programas for Real-Time Environment. ACM-SIGPLAN Wokshop on Languages, Compilers and Tools for Real-Time Systemas, Las Vegas, United States of America. 1997. pp 77-81.

CommonKADS-RT – Referencias

•

238

Puerto

[BRH00]

V. Botti, M. Rebollo, M. Henao. Análisis de los procesos de la Operativa Marítima. Documento de Trabajo, Análisis001124. Valencia, España. 2000. 16 p.

[Dag89]

C. Dagazo. The Crane Scheduling Problem. Transpn. Res. Vol. 23B, Nº 3. Pergamon Press. 1989. pp. 159-175.

[HwY99]

K. Hwan, K. Young. An optimal Routing Algorithm for a Transfer Crane in Port Container Terminals. Transportation Science, Vol. 33, Nº 1. Institute for Operations Research and Management Sciences. 1999.

[PeD90]

R. Peterkofskly, C. Daganzo. A Branch and Bound Solution Method for the Crane Scheduling Problem. Transpn. Res. Vol. 24B, Nº 3. Pergamon Press 1990. pp. 159-172.

•

Robot

[SHB00]

J. Soler, M. Henao, V. Botti. A Mobile Robot Application with an Analysis Method based on CommonKADS. Proceedings of the IASTED International Conference: Intelligent Systems and Control (ISC 2000). Hawaii. 2000. pp. 299-303.

[SAA+00]

A. Schreiber, J. Akkermans, A. Anjewierden, et al. Engineering of Knowledge and Management; The CommonKADS Methodology. The United States of America, The MIT Press. 2000. 455 p.

CommonKADS-RT – Anexo 1

239

ANEXO 1

Criterios de Filtrado Criterios para determinar la importancia del sistema basados en el conocimiento de tiempo real en la Organización 1

¿Está la gerencia en donde se presenta la raíz del problema, interesada en solucionar dicho problema?

2

¿En caso de que se cambie la situación actual, la Organización se ve realmente beneficiada?

3

¿La Organización está dispuesta a introducir una tecnología emergente para que se realice la tarea que se está analizando?

4

¿La Organización está dispuesta a introducir una tecnología emergente para que haga parte de su que-hacer diario?

5

¿Ha evaluado la dirección de la Organización las implicaciones que tiene el introducir esta tecnología para solucionar el problema planteado?

6

¿Está interesada la Organización en emprender el desarrollo de un sistema basado en el conocimiento de tiempo real?

7

¿La Organización está dispuesta a invertir recursos y tiempo para que se desarrolle un sistema útil, eficiente y efectivo?

8

¿Ha hecho la Empresa un estudio Costo / beneficios en donde se muestre la recuperación de la inversión al desarrollar un sistema de este tipo?

9

¿Si la Organización se divide en niveles estratégicos, tácticos y operativos, en cuál de ellos estará situado el sistema?

10 ¿La Organización está interesada en registrar el conocimiento que se necesita para poder dar soluciones a problemas del dominio en tiempos acotados?

CommonKADS-RT – Anexo 1

240

11 ¿La Organización comprende las características básicas de un sistema basado en el conocimiento de tiempo real?

Criterios para estimar la complejidad del problema a resolver 12 ¿Tiene la empresa experiencia en el desarrollo de sistemas basados en el conocimiento? 13 ¿Tiene la empresa experiencia en el desarrollo de sistemas de tiempo real? 14 ¿Tiene un alto grado de dificultad y complejidad el problema a resolver? 15 ¿Se ha planteado algún tipo de solución que no implique la utilización de una herramienta computacional y que ofrezca algunos beneficios? 16 ¿Hay algunos pasos o secuencia determinadas para solucionar el problema? 17 ¿Se ha evaluado el desarrollo de un sistema de información tradicional en donde se tenga un proceso algorítmico? 18 ¿El solucionar el problema requiere de conocimientos muy especializados o expertos? 19 ¿En el dominio del problema hay muchas personas que conocen cómo solucionar el problema? 20 ¿Se puede encontrar el conocimiento del área disperso entre varias personas expertas? 21 ¿El problema está bien definido con datos e información completamente conocidos y exactos? 22 ¿El problema requiere de datos o información del entorno para su solución? 23 ¿La solución que el sistema provea puede tener conocimiento probabilístico asociado? 24 ¿Se tienen mediciones de tiempos de los procesos que están involucrados en el problema? 25 ¿Si hay tiempos definidos, se tiene un plan para poderlos cumplir? 26 ¿En caso de no poderse cumplir un plazo o un tiempo, qué ocurriría? 27 ¿El sistema requiere que se tengan disponibles diferentes recursos (periféricos, dispositivos) para que la información se represente y afecte el entorno? 28 ¿El sistema que se desarrolle como solución requiere de especificaciones de tiempos y el manejo apropiado de valores temporales para funcionar y actuar?

CommonKADS-RT – Anexo 1

241

29 ¿Hay algún tipo de restricción que se deba tener en cuenta cuando se plantee la solución? 30 ¿Una solución que se vea valiosa actualmente permanecerá vigente durante los próximos años? 31 ¿La solución del problema está enmarcada en un dominio de aplicación específico del conocimiento? 32 ¿El área de pericia del humano es crítica y difícil de asimilar? 33 ¿El sistema requiere de conocimientos teóricos para poder solucionar el problema? 34 ¿El sistema requiere de conocimientos prácticos, experiencia en problemas similares para poder solucionar la situación actual?

Criterios relacionados con los recursos requeridos 35 ¿Está dispuesta la organización en proporcionar todos los recursos, tiempo – dinero – personas, que se requieren para hacer un análisis completo de la situación actual y poder así establecer una especificación adecuada? 36 ¿Está dispuesta la organización en proporcionar los recursos, tanto del hardware como el software y de las personas que se requiere para desarrollar el sistema basado en el conocimiento de tiempo real? 37 ¿La organización cuenta con personal que puede asumir el papel y la responsabilidad que se han definido como necesarias para poder llevar a cabo un proyecto de este tipo? 38 ¿Las personas pueden formar un equipo de trabajo? 39 ¿Hay dentro de la empresa una persona reconocida que posea una gran influencia o experiencia en el desarrollo de la tarea? 40 ¿Podría la empresa contratar personas externas que sean idóneas para que participen en el proyecto? 41 ¿Están las personas disponibles e interesadas en participar en el desarrollo del sistema basado en el conocimiento de tiempo real? 42 ¿Si no se dispone de un experto en el dominio, se puede solucionar el problema entre varias de las personas que están involucradas con esa situación? 43 ¿El experto está dispuesto a proporcionar todo el conocimiento para que el sistema haga su simulación? 44 ¿Tiene el experto facilidad para expresar dichos conocimientos?