pedro pablo
DESCRIPTION
MomentaneoTRANSCRIPT
-
Universidad Politcnica de Madrid
Facultad de InformticaDepartamento de Lenguajes, Sistemas Informticos e Ingeniera del
Software
ESPECIFICACIN DE UN MODELO DE
INTERACCIN APLICABLE A PROCESOS DE
DESARROLLO Y OPERACIN DE SISTEMAS CON
SOFTWARE
TESIS DOCTORAL
Autor: Pedro Pablo Alarcn CaveroIngeniero en Informtica
Director: Juan Garbajosa SopeaDoctor en Informtica
Enero 2008
-
Tribunal nombrado por el Mgfco. Y Excmo. Sr. Rector de la Universidad Politcnica
de Madrid, el da de de 2008.
Presidente D.
Vocal D.
Vocal D.
Vocal D.
Secretario D.
Realizado el acto de defensa y lectura de la Tesis el da de de 2008.
En Madrid:
Calificacin:
EL PRESIDENTE LOS VOCALES
EL SECRETARIO
-
A mis padres, inicio de este trabajo hace unos cuantos aos, os quiero.
A mis hijos, Jess, Pedro Pablo y Jorge, las estrellas que me han guiado hasta terminarlo.
A mi mujer, Mari ngeles, ya sabes... este trabajo es de los dos, las palabras que t
has escrito no figuran en este libro, estn grabadas en mi corazn.
-
AGRADECIMIENTOS
Gracias a todos los que han participado en mi vida hasta completar mi formacin
acadmica con esta tesis doctoral; a los que me dieron palabras de nimo, a los que me
regalaron una sonrisa, a los que me regalaron mil, a los que no me regalaron ni una, a los
que me ayudaron, a los que no me ayudaron porque de ello tambin aprend, a los que se
alegraron, a los que no se alegraron pero se alegran hoy, a mi familia, a mis amigos del
presente y del pasado, a los que ya no estn aqu... todos de una forma u otra han aportado
granitos de arena hasta formar esta montaa.
Agradezco a todos los que se han interesado por la marcha de este trabajo y me han
dado palabras de nimo durante todo este tiempo: ngel Garca, Carlos Cuvillo, Eugenio
Santos, Hctor Garca, Javier Gil, Jssica Daz, Jorge Tejedor, LuisFer, Manuel Bollan,
Miguel Angel Daz, Nicos, Octavio, Paco Sanchis, Pepi, Pilar Rodriguez, Santiago Alonso,
y otros muchos que no figuran por no hacer esta lista interminable, y a los que dar las
gracias personalmente.
Y en especial, quiero mostrar mi ms sincero agradecimiento a las siguientes personas
que me han prestado su inestimable ayuda durante la realizacin de esta tesis:
Juan Garbajosa director de esta tesis, por embarcarme hace unos cuantos aos en
esta aventura y brindarme la oportunidad de trabajar juntos realizando este trabajo de
investigacin.
Agustn Yage siempre ha estado ah cuando le he necesitado; ms que un com-
paero, un amigo.
-
Jennifer Prez por aparecer como el sptimo de caballera cuando ms bajo estaba
de nimo.
Antonio Vallecillo por la mano amiga que me ha tendido y los nimos que en todo
momento me ha dado.
-
RESUMEN
Los operadores de un sistema han de tener un buen conocimiento del funcionamiento
del sistema para que el rendimiento de ste sea el adecuado. Este conocimiento incluye las
interacciones que puedan darse entre el sistema y el operador, por medio de la aplicacin o
aplicaciones externas que posibiliten dicha interaccin entre ambos. Esta interaccin con-
templa las operaciones admitidas por el sistema, expresadas por el envo de entradas al
sistema y la recepcin de las salidas generadas por el sistema. Las operaciones del sistema
por tanto constituyen una parte esencial del conocimiento relacionado con un sistema. Sin
embargo, el desarrollo de sistemas a menudo, no contempla el conocimiento de las ope-
raciones del sistema como un elemento clave en el proceso de desarrollo. Los aspectos
de operaciones del sistema se abordan de manera implcita y lateral junto con el resto de
aspectos que s reciben atencin preferente.
Esta tesis profundiza en un aspecto fundamental en los sistemas intensivos en software,
ideados para ser operados por personas o por otros sistemas, como es el modelado de la
interaccin de un sistema con el exterior. El objetivo principal de este trabajo de inves-
tigacin es el de especificar un modelo de interaccin con el operador del sistema, al que
denominamos modelo de operaciones de un sistema, que permita ser utilizado como base
en el desarrollo y operacin/monitorizacin de sistemas intensivos software.
Este trabajo realiza una aportacin en el campo del modelado y especificacin de sis-
temas complejos, contribuyendo con nuevas definiciones para sistema operable y mode-
lo de operaciones de un sistema, y proponiendo adems, un metamodelo y un perfil UML
para incorporar el modelado de las operaciones en el modelo de un sistema. En el campo de
herramientas de operacin y validacin de sistemas, y tomando como base estas propuestas
-
de representacin del modelo de operaciones de un sistema, se aporta una aproximacin al
modelado del frontend de operaciones de un sistema. Esta aproximacin incluye un meta-
modelo, una arquitectura conceptual y un conjunto de operaciones bsicas del sistema. Por
ltimo, y en el campo del modelado y gestin de procesos, se analiza la potencialidad del
modelo de operaciones definido en el proceso de desarrollo de sistemas, y se plantea el
enriquecimiento del proceso de desarrollo de sistemas mediante la utilizacin, en etapas
tempranas del desarrollo, del modelo de operaciones del sistema.
ABSTRACT
A key issue in system engineering is the modelling of the knowledge of the system
interactions. These interactions include system operations such as commands acting on
systems: inputs to the system and different kinds of outputs, which are classified into re-
sponses, notifications and alarms. Therefore, system operations are an essential part of the
knowledge of the system. However, systems engineering does not often take into account
the system operations as a key element. They usually consider system operations in an
implicit and lateral way.
This Thesis is focused on the modelling of the interaction between a software-intensive
system -which were devised to be operated by people or other systems- and its environ-
ment. The main objective of this research work is to specify an interaction model between
an operator and the system, which is called system operations model, that allows for be-
ing the base of the development and operation/monitoring processes of software-intensive
systems.
This work contributes in the modelling and specification of complex systems making
-
new definitions for operable system and system operations model. In addition, a meta-
model and a profile UML to incorporate the operations modelling in the model of a system
are proposed. Another relevant contribution of this Thesis is the definition of a new appro-
ach to model the system operations front-end that is based on the system operations model.
Specifically, this approach includes an UML metamodel, a conceptual architecture of the
front-end, and a subset of basic operations for a generic system.
Finally, the system operations model can be applied in early development phases of
software-intensive systems. The consequence is that operations issues can effectively be
used as a driver in the complex systems engineering activities such as development and
validation. Thus, the use of the system operations model in early development stages con-
tributes to a significant enrichment of the systems development process.
-
ndice general
PARTE I
DEDICATORIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AGRADECIMIENTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RESUMEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LISTA DE TABLAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LISTA DE ACRNIMOS Y ABREVIATURAS . . . . . . . . . . . . . . . . . .
I. INTRODUCCIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1. Planteamiento de la tesis doctoral . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Motivacin y objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Metodologa de investigacin de la tesis . . . . . . . . . . . . . . . . . . 10
1.4. Marco de desarrollo de la tesis . . . . . . . . . . . . . . . . . . . . . . . 12
1.5. Presentacin de la tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.6. Resumen del captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
II. ESTADO DEL ARTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2. Sistemas desde el punto de vista de interaccin . . . . . . . . . . . . . . . 22
2.2.1. Visin filosfica de Bunge . . . . . . . . . . . . . . . . . . . . . 23
2.2.2. Jackson: el mundo y la mquina . . . . . . . . . . . . . . . . . . 24
2.2.3. Sistemas definidos como autmatas . . . . . . . . . . . . . . . . 25
2.2.4. Broy: sistemas reactivos e interactivos . . . . . . . . . . . . . . . 27
2.2.4.1. Sistemas reactivos . . . . . . . . . . . . . . . . . . . . 27
2.2.4.2. Sistemas interactivos . . . . . . . . . . . . . . . . . . . 31
2.2.5. Visin de Wang . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.2.6. Modelo de cuatro variables de Parnas . . . . . . . . . . . . . . . . 36
-
2.3. Paradigmas en el modelado de la interaccin de un sistema . . . . . . . . 42
2.3.1. Paradigma basado en estados . . . . . . . . . . . . . . . . . . . . 43
2.3.2. Paradigma basado en escenarios . . . . . . . . . . . . . . . . . . 44
2.3.3. Paradigma basado en contratos . . . . . . . . . . . . . . . . . . . 45
2.3.4. Paradigma basado en servicios . . . . . . . . . . . . . . . . . . . 47
2.3.5. Paradigma basado en Interaccin Hombre-Computador (HCI) . . . 48
2.3.6. Paradigma basado en operaciones . . . . . . . . . . . . . . . . . 49
2.4. Concepto de operacin de sistemas en estndares de ingeniera de sis-temas y software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.4.1. Visin de documento de operaciones . . . . . . . . . . . . . . . . 53
2.4.2. Lenguajes procedurales de operacin y pruebas . . . . . . . . . . 57
2.4.2.1. PLUTO como lenguaje de operaciones . . . . . . . . . 57
2.4.2.2. TTCN-3 como lenguaje orientado a pruebas . . . . . . . 59
2.5. Desarrollo de sistemas dirigido por modelos . . . . . . . . . . . . . . . . 61
2.6. Resumen y conclusiones del captulo . . . . . . . . . . . . . . . . . . . . 65
III. CONCEPTUALIZACIN DE SISTEMA OPERABLE . . . . . . . . . . . . 75
3.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.2. Los sistemas con componentes inter-relacionados . . . . . . . . . . . . . 76
3.2.1. Sistema como autmata . . . . . . . . . . . . . . . . . . . . . . . 76
3.2.2. Relacin entre sistema y entorno . . . . . . . . . . . . . . . . . . 79
3.2.3. Punto de vista de las operaciones . . . . . . . . . . . . . . . . . . 85
3.2.3.1. Operador . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.2.3.2. Interfaz de operacin . . . . . . . . . . . . . . . . . . . 88
3.2.4. Estructura de un sistema . . . . . . . . . . . . . . . . . . . . . . 88
3.2.4.1. Visin estructural intra-elementos . . . . . . . . . . . . 89
3.2.4.2. Visin estructural inter-elementos . . . . . . . . . . . . 94
3.3. Los Sistemas con componentes inter-relacionados como sistemas de in-teraccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
3.3.1. Concepto de sistema operable . . . . . . . . . . . . . . . . . . . . 99
-
3.3.2. Concepto de frontend de operaciones de un sistema . . . . . . . . 101
3.3.3. Interacciones de un sistema desde el punto de vista de operaciones 104
3.3.3.1. Interaccin Sistema-Entorno . . . . . . . . . . . . . . . 106
3.3.3.2. Interaccin Operador-Frontend de operaciones . . . . . 106
3.3.3.3. Interaccin Sistema-Frontend de Operaciones del Sistema106
3.4. Resumen y conclusiones del captulo . . . . . . . . . . . . . . . . . . . . 109
IV. MODELO DE OPERACIONES DE UN SISTEMA . . . . . . . . . . . . . . 111
4.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.2. Definicin de modelo de operaciones de un sistema . . . . . . . . . . . . 113
4.3. mbito de aplicacin del modelo de operaciones de un sistema . . . . . . 118
4.4. Modelo de operaciones y requisitos de un sistema . . . . . . . . . . . . . 121
4.4.1. Estndar ECSS-E10Part6A . . . . . . . . . . . . . . . . . . . . . 121
4.4.2. Estndar IEEE Std 830 . . . . . . . . . . . . . . . . . . . . . . . 123
4.5. Subconjunto de requisitos del sistema relacionados con el MOS . . . . . . 124
4.5.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . 127
4.5.2. Requisitos de operacin . . . . . . . . . . . . . . . . . . . . . . . 129
4.6. Recomendaciones para especificar el modelo de operaciones de un sistema 131
4.7. Resumen y conclusiones del captulo . . . . . . . . . . . . . . . . . . . . 134
V. PROPUESTADEREPRESENTACINDELMODELODEOPERACIONESDE UN SISTEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.1. Planteamiento inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
5.2. Metamodelo de operaciones de un sistema . . . . . . . . . . . . . . . . . 141
5.2.1. Vista del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 144
5.2.1.1. Clase SystemElement . . . . . . . . . . . . . . . . . . 145
5.2.1.2. Clase SeProperty . . . . . . . . . . . . . . . . . . . . . 146
5.2.1.3. Tipo de datos AccessPort . . . . . . . . . . . . . . . . 148
5.2.1.4. Enumeracin ElementStatus . . . . . . . . . . . . . . . 148
5.2.1.5. Enumeracin PropertyType . . . . . . . . . . . . . . . 148
5.2.1.6. Tipo de datos PropertyValue . . . . . . . . . . . . . . . 149
-
5.2.2. Vista de interaccin . . . . . . . . . . . . . . . . . . . . . . . . . 149
5.2.2.1. Clase InputInterface . . . . . . . . . . . . . . . . . . . 150
5.2.2.2. Clase InputOperation . . . . . . . . . . . . . . . . . . . 150
5.2.2.3. Clase InputCmd . . . . . . . . . . . . . . . . . . . . . 151
5.2.2.4. Clase OutputInterface . . . . . . . . . . . . . . . . . . 151
5.2.2.5. Clase OutputOperation . . . . . . . . . . . . . . . . . . 152
5.2.2.6. Clase Response . . . . . . . . . . . . . . . . . . . . . . 153
5.2.2.7. Clase Notification . . . . . . . . . . . . . . . . . . . . 153
5.2.2.8. Clase Alarm . . . . . . . . . . . . . . . . . . . . . . . 154
5.2.2.9. Tipo de datos PriorityType . . . . . . . . . . . . . . . . 154
5.3. Definicin de un perfil UML 2 de operaciones (U2OP) . . . . . . . . . . . 155
5.3.1. Descripcin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
5.3.2. Prerrequisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
5.3.3. Nuevos tipos de datos . . . . . . . . . . . . . . . . . . . . . . . . 157
5.3.3.1. Enumeracin ElementStatus . . . . . . . . . . . . . . . 159
5.3.3.2. Tipo de datos AccessPort . . . . . . . . . . . . . . . . . 159
5.3.3.3. Tipo de datos PriorityType . . . . . . . . . . . . . . . . 159
5.3.4. Estereotipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
5.3.4.1. Estereotipo U2OP_S ystemElement . . . . . . . . 160
5.3.4.2. Estereotipo U2OP_VisibleRelation . . . . . . . . 161
5.3.4.3. Estereotipo U2OP_Monitored . . . . . . . . . . 162
5.3.4.4. Estereotipo U2OP_Controlled . . . . . . . . . . 162
5.3.4.5. Estereotipo U2OP_MonitoredAndControlled . . 163
5.3.4.6. Estereotipo U2OP_Input . . . . . . . . . . . . . 164
5.3.4.7. Estereotipo U2OP_Output . . . . . . . . . . . . 164
5.3.4.8. Estereotipo U2OP_InputCmd . . . . . . . . . . . 165
5.3.4.9. Estereotipo U2OP_Response . . . . . . . . . . . 165
5.3.4.10. Estereotipo U2OP_Noti f ication . . . . . . . . . 166
5.3.4.11. Estereotipo U2OP_Alarm . . . . . . . . . . . . . 166
-
5.4. Resumen y conclusiones del captulo . . . . . . . . . . . . . . . . . . . . 167
VI. APLICACIN DEL MODELO DE OPERACIONES DEL SISTEMA CO-MO SOPORTE PARA EL MODELADO DEL FRONTEND DE OPERA-CIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
6.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
6.2. Metamodelo de frontend de operaciones del sistema . . . . . . . . . . . . 170
6.2.1. Frontend de operaciones . . . . . . . . . . . . . . . . . . . . . . 174
6.2.1.1. Clase SOF . . . . . . . . . . . . . . . . . . . . . . . . 174
6.2.1.2. Clase Operator . . . . . . . . . . . . . . . . . . . . . . 177
6.2.1.3. Clase SystemView . . . . . . . . . . . . . . . . . . . . 178
6.2.1.4. Clase OperationsProcedure . . . . . . . . . . . . . . . 179
6.2.1.5. Clase ProcedureExecution . . . . . . . . . . . . . . . . 180
6.2.1.6. Clase CommandExecution . . . . . . . . . . . . . . . . 181
6.2.2. Sistema bajo operacin . . . . . . . . . . . . . . . . . . . . . . . 182
6.2.2.1. Clase SystemElement . . . . . . . . . . . . . . . . . . 183
6.2.3. Operaciones sobre el sistema . . . . . . . . . . . . . . . . . . . . 184
6.2.3.1. Interfaz InputInterface . . . . . . . . . . . . . . . . . . 184
6.2.3.2. Interfaz OutputInterface . . . . . . . . . . . . . . . . . 185
6.2.4. Tipos de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
6.2.4.1. Tipo de datos Identifier . . . . . . . . . . . . . . . . . . 186
6.2.4.2. Tipo de datos ExecutionResult . . . . . . . . . . . . . . 186
6.3. Arquitectura conceptual de un frontend de operaciones del sistema . . . . 186
6.3.1. Nivel 1: Interaccin operador-sistema . . . . . . . . . . . . . . . 187
6.3.2. Nivel 2: Interaccin SOF-Sistema . . . . . . . . . . . . . . . . . 188
6.3.3. Nivel 3: Comunicacin SOF-Sistema . . . . . . . . . . . . . . . . 189
6.3.4. Nivel 4: GUI orientado al operador del sistema . . . . . . . . . . 190
6.3.5. Nivel 5: Componentes del SOF . . . . . . . . . . . . . . . . . . . 191
6.3.6. Esquema de funcionamiento del SOF . . . . . . . . . . . . . . . . 193
6.4. Comandos bsicos de operacin de un sistema . . . . . . . . . . . . . . . 194
-
6.4.1. Sintaxis general . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
6.4.2. Clasificacin de comandos bsicos de operacin . . . . . . . . . . 197
6.4.3. Operaciones de administracin o configuracin . . . . . . . . . . 198
6.4.3.1. CreateSE . . . . . . . . . . . . . . . . . . . . . . . . . 199
6.4.3.2. DeleteSE . . . . . . . . . . . . . . . . . . . . . . . . . 200
6.4.4. Operaciones de Interaccin . . . . . . . . . . . . . . . . . . . . . 200
6.4.4.1. Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
6.4.4.2. Get . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
6.4.4.3. Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
6.4.4.4. Finish . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
6.4.5. Operaciones de procedimiento . . . . . . . . . . . . . . . . . . . 203
6.4.5.1. For . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
6.4.5.2. Repeat . . . . . . . . . . . . . . . . . . . . . . . . . . 204
6.4.5.3. Wait . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
6.4.5.4. Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
6.5. Resumen y conclusiones del captulo . . . . . . . . . . . . . . . . . . . . 206
VII. APLICACIN DELMODELO DE OPERACIONES A UN CASO PRCTI-CO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
7.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
7.2. Descripcin del caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
7.2.1. Concepto de sistema . . . . . . . . . . . . . . . . . . . . . . . . 211
7.2.2. Requisitos para la certificacin de mquinas interconectadas . . . 213
7.2.3. Descripcin del problema a resolver . . . . . . . . . . . . . . . . 216
7.2.4. Descripcin de la solucin . . . . . . . . . . . . . . . . . . . . . 217
7.3. Requisitos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
7.4. Modelo del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
7.4.1. Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . 221
7.4.2. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . 225
7.4.2.1. Tipos de datos . . . . . . . . . . . . . . . . . . . . . . 225
-
7.4.2.2. Clase Master . . . . . . . . . . . . . . . . . . . . . . . 225
7.4.2.3. Clase Accumulator . . . . . . . . . . . . . . . . . . . . 228
7.4.2.4. Clase Game . . . . . . . . . . . . . . . . . . . . . . . . 230
7.4.2.5. Clase Prize . . . . . . . . . . . . . . . . . . . . . . . . 231
7.4.2.6. Clase NormalPrize . . . . . . . . . . . . . . . . . . . . 231
7.4.2.7. Clase JackpotPrize . . . . . . . . . . . . . . . . . . . . 232
7.4.2.8. Interfaz MasterBasicFunctionallity . . . . . . . . . . . 232
7.4.2.9. Interfaz AccumulatorControl . . . . . . . . . . . . . . . 233
7.4.2.10. Interfaz Play . . . . . . . . . . . . . . . . . . . . . . . 234
7.4.3. Diagrama de actividades . . . . . . . . . . . . . . . . . . . . . . 234
7.4.4. Diagrama de secuencia . . . . . . . . . . . . . . . . . . . . . . . 238
7.4.5. Diagrama de estados . . . . . . . . . . . . . . . . . . . . . . . . 239
7.5. Aplicacin del perfil U2OP al modelado del sistema . . . . . . . . . . . . 240
7.5.1. SystemElement . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
7.5.2. VisibleRelation . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
7.5.3. Monitored . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
7.5.4. MonitoredAndControlled . . . . . . . . . . . . . . . . . . . . . . 244
7.5.5. Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
7.5.6. Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
7.5.7. CmdInput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
7.5.8. Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
7.5.9. Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
7.6. Resumen y conclusiones del captulo . . . . . . . . . . . . . . . . . . . . 249
VIII.APLICACIN DEL MODELO DE OPERACIONES EN PROCESOS DEDESARROLLO Y OPERACIN DE SISTEMAS . . . . . . . . . . . . . . . 251
8.1. Utilizacin del modelo de operaciones en procesos de desarrollo de sistemas252
8.2. El modelo de operaciones como soporte en la generacin de herramientasde validacin y operacin de sistemas . . . . . . . . . . . . . . . . . . . . 255
8.3. Enriquecimiento del proceso de desarrollo de sistemas . . . . . . . . . . . 261
-
8.3.1. Desarrollo incremental del sistema . . . . . . . . . . . . . . . . . 264
8.3.2. Validacin del sistema . . . . . . . . . . . . . . . . . . . . . . . . 265
8.4. Resumen y conclusiones del captulo . . . . . . . . . . . . . . . . . . . . 266
IX. CONCLUSIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
9.1. Anlisis del logro de objetivos . . . . . . . . . . . . . . . . . . . . . . . . 268
9.2. Aportaciones a la investigacin . . . . . . . . . . . . . . . . . . . . . . . 271
9.3. Contraste de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
9.4. Lneas de investigacin futuras . . . . . . . . . . . . . . . . . . . . . . . 286
9.5. Conclusiones finales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
REFERENCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
-
ndice de cuadros
1. Requisitos para definir un MOS . . . . . . . . . . . . . . . . . . . . . . . 128
2. Perfiles UML definidos por OMG . . . . . . . . . . . . . . . . . . . . . . 139
3. Conjunto de operaciones genricas . . . . . . . . . . . . . . . . . . . . . . 198
-
ndice de figuras
1. Ciclo de actividades del mtodo Investigacin en Accin . . . . . . . . . . 11
2. Marco de proyectos Investigacin en Accin en esta tesis . . . . . . . . . . 12
3. Relacin entre el sistema y su entorno (adaptada de Broy [24]) . . . . . . . 29
4. Caja negra y de cristal (adaptada de Broy [31]) . . . . . . . . . . . . . . . 33
5. Modelo de sistema abierto (Wang [171]) . . . . . . . . . . . . . . . . . . . 36
6. Modelo de cuatro variables (adaptada de Heitmeyer [71]) . . . . . . . . . . 38
7. Modelo de cuatro variables . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8. Modelo de sistema (adaptada de Sateesh [146]) . . . . . . . . . . . . . . . 42
9. Relacin entre un sistema y su entorno . . . . . . . . . . . . . . . . . . . . 81
10. Modelo de sistema de cuatro variables (basado en Heitmeyer [72] y Sateesh[146]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
11. Primer nivel de interaccin . . . . . . . . . . . . . . . . . . . . . . . . . . 86
12. Segundo nivel de interaccin . . . . . . . . . . . . . . . . . . . . . . . . . 87
13. Correspondencia entre entradas y propiedades perceptibles . . . . . . . . . 93
14. Correspondencia entre salidas y propiedades perceptibles . . . . . . . . . . 94
15. Representacin de un sistema . . . . . . . . . . . . . . . . . . . . . . . . . 95
16. Modelo de sistema perceptible por un operador . . . . . . . . . . . . . . . 99
17. Sistema operable con un Frontend de Operaciones . . . . . . . . . . . . . . 102
18. Sistema operable con un panel de control . . . . . . . . . . . . . . . . . . 103
19. Relacin entre Sistema y Frontend de Operaciones del Sistema . . . . . . . 105
20. Interaccin entre Sistema y Frontend de Operaciones . . . . . . . . . . . . 109
21. Modelo de operaciones de un sistema . . . . . . . . . . . . . . . . . . . . 117
22. Tipos de sistemas ya creados . . . . . . . . . . . . . . . . . . . . . . . . . 119
23. Metamodelo de operaciones del sistema (System Operations Metamodel) . 143
24. Perfil de operaciones del sistema (U2OP) . . . . . . . . . . . . . . . . . . 156
25. Perfil de operaciones del sistema (U2OP) con restricciones . . . . . . . . . 158
26. Metamodelo de frontend de operaciones (OperationsFrontend Metamodel) . 171
-
27. Nivel 1. Interaccin operador-sistema . . . . . . . . . . . . . . . . . . . . 187
28. Nivel 2. Interaccin SOF-sistema . . . . . . . . . . . . . . . . . . . . . . . 189
29. Nivel 3. Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
30. Nivel 4. GUI orientado al operador del sistema . . . . . . . . . . . . . . . 191
31. Nivel 5. Componentes del SOF . . . . . . . . . . . . . . . . . . . . . . . . 192
32. Sistema de mquinas de juego de azar interconectadas . . . . . . . . . . . . 213
33. Diagrama de casos de uso de una mquina acumulador . . . . . . . . . . . 222
34. Workflow"de una mquina de juego . . . . . . . . . . . . . . . . . . . . . 223
35. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
36. Diagrama de actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
37. Diagrama de secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
38. Diagrama de estados de una mquina acumulador . . . . . . . . . . . . . . 239
39. Diagrama de clases decorado con el perfil U2OP . . . . . . . . . . . . . . 243
40. Frontend de operaciones en procesos de validacin y operacin . . . . . . . 259
41. Proceso de desarrollo enriquecido por el MOS . . . . . . . . . . . . . . . . 262
-
Lista de Acrnimos y Abreviaturas
AF Autmata Finito
AFD Autmata Finito Determinista
AFND Autmata Finito No Determinista
AIAA American Institute of Aeronautics and Astronautics
ANSI American National Standards Institute
API Application Program Interface
CON Variables Controladas
ConOps Concept of Operations
CBD Component-Based Development
DSML Domain-Specific Modelling Language
ECSS European Cooperation for Space Standardization
ESA European Space Agency
ETSI European Telecommunications Standards Institute
FS Functional Specification
FSM Finite State Machine
GUI Graphical User Interface
ICD Interface Control Documentation
ITS Intelligent Transportation Systems
-
IEEE Institute of Electrical and Electronics Engineers
I/O Input/Output
ITU International Telecommunications Union
LSC Live Sequence Charts
MDA Model Driven Architecture
MDD Model Driven Development
MDE Model Driven Engineering
MOF Meta-Object Facility
MON Variables Monitorizadas
MOS Modelo de Operaciones del Sistema
MSC Message Sequence Charts
NA No Aplicable
NAT Naturaleza
OAR Object-Attribute-Relation
OCL Object Constraint Language
OI Operation Interface
OMG Object Management Group
PIM Platform-Independent Model
PLUTO Procedure Language for Users in Test and Operations
REQ Requisitos
-
RUP Rational Unified Process
SDL Specification and Description Language
SE System Element
SOA Service-Oriented Architectures
SOF System Operations Frontend
SUO System Under Operation
SUT System Under Test
SysML System Modelling Language
SYST System and Software Technologies
SW Software
TOPEN Test and Operation Environment
TP Test Procedure
TS Technical Specification
TTCN-3 Testing and Test Control Notation
U2OP UML 2 Operations Profile
U2TP UML 2 Testing Profile
UML Unified Modelling Language
UPM Universidad Politcnica de Madrid
WSDL Web Service Description Language
-
Captulo I
INTRODUCCIN
No dejes apagar el entusiasmo,
virtud tan valiosa como necesaria;
trabaja, aspira, tiende siempre hacia la altura.
Rubn Daro
1
-
1.1. Planteamiento de la tesis doctoral
En el contexto de este trabajo, los sistemas se entendern de manera general, como
sistemas intensivos en software. Este tipo de sistemas representan tpicamente sistemas
heterogneos que incluyen componentes software junto con otro tipo de dispositivos, que
les permiten interaccionar con su entorno [60]. Esta interaccin se produce tpicamente
mediante sensores y actuadores integrados en el sistema o mediante servicios software.
Broy plantea que el desarrollo de sistemas intensivos en software requiere de una amplia
corriente de investigacin, soportada por nuevas competencias tcnicas, que incluyan una
buena comprensin del modelado de sistemas, el uso efectivo de modelos, y una teora de
modelado de sistemas de eventos discretos [29].
Un factor clave en el rendimiento efectivo de este tipo de sistemas radica en el grado
de conocimiento que tengan los operadores del funcionamiento del sistema [4]. Este co-
nocimiento incluye, al menos, el comportamiento del sistema observable externamente, es
decir, el conocimiento de las interacciones que pueden darse entre el sistema y el opera-
dor, por medio de la aplicacin o aplicaciones externas que posibilitan las operaciones del
sistema.
As pues, la especificacin y modelado de requisitos de operacin del sistema juega un
papel muy importante dentro del ciclo de vida de los sistemas intensivos en software, ya
que permite conocer al conjunto de los desarrolladores desde un principio las necesidades
y expectativas de los usuarios u operadores que utilizarn el sistema. De ah que ciertos
estndares incluyan el concepto de operacin, y pautas para expresar un documento de
operaciones del sistema que recoja los requisitos de operacin del sistema [83] [82] [79]
[55] [76] [12] [123].
Las operaciones del sistema por tanto constituyen una parte esencial del conocimien-
to relacionado con cualquier sistema. Sin embargo, el desarrollo de sistemas a menudo,
no contempla el punto de vista de operaciones del sistema como un elemento clave en el
2
-
proceso de desarrollo. Los aspectos de operaciones del sistema se abordan de manera im-
plcita y lateral junto con el resto de aspectos o puntos de vista del sistema que s reciben
atencin preferente. As, los aspectos de operaciones del sistema figuran como intereses
cruzados (crosscutting concern) en el conjunto global de los artefactos producidos durante
el desarrollo del sistema. El estndar IEEE 1471 - IEEE Recommended Practice Archi-
tectural Description of Software-Intensive Systems [78], define punto de vista como una
especificacin de reglas para construir una vista del sistema que comprenda una serie de
aspectos de stakeholders 1. Sera por tanto interesante enfocar el desarrollo de un sistema
incluyendo el punto de vista de operaciones, al objeto de separar el inters (concern) de
operaciones del sistema de una manera ntida a lo largo del ciclo de vida del sistema.
En sistemas de espacio por ejemplo, las operaciones de carga de pago (payload) se con-
vierten en un aspecto crtico ya que una vez la nave espacial est en el espacio puede ser
muy difcil o imposible determinar un problema. Para sistemas de espacio, es recomendable
e incluso forzoso producir modelos de operacin en etapas tempranas del desarrollo. Las
pruebas de carga de pago (payload) son exhaustivas, y para ello Timmermans sostiene que
debe estar disponible un modelo de operaciones [160]. Las pruebas se definen utilizando
esta especificacin del modelo de operacin. Los sistemas de espacio utilizan a menudo co-
mo lnea base telemetra y telecomandos. Esto es, el sistema de tierra enva un telecomando
a la nave espacial y sta responde con una telemetra. Esta aproximacin es un esquema
muy simple y eficiente para modelar la interaccin del sistema. Como justifican Garbajosa
et al. en [62], este esquema se puede transportar fcilmente, en trminos orientados a obje-
tos, una operacin, el telecomando, y un objeto, la nave espacial, que devuelve un valor, la
telemetra. Obviamente es posible refinar este esquema para una carga de pago (payload)
basada en objetos y operaciones asociadas.
El enfoque de modelo de operacin en sistemas de espacio puede utilizarse en otros
tipos de sistemas, aunque pueda necesitarse una metodologa propia y una infraestructura
1conjunto de personas implicadas en el desarrollo y operacin del sistema
3
-
de herramientas. Este trabajo persigue proporcionar una aproximacin en la que los mo-
delos de operaciones del sistema sean una piedra angular para el desarrollo, validacin y
operacin de sistemas.
Esta tesis doctoral se enmarca dentro de la lnea de investigacin Modelado y especi-
ficacin de sistemas complejos. El modelado de sistemas complejos, y de sistemas en
general, constituye un pilar fundamental tanto en el desarrollo como en la evolucin de s-
tos. Los modelos aportan conocimiento del sistema al conjunto de stakeholders implicados
(ya sean pasados, presentes o futuros) facilitando el entendimiento y comprensin global
del mismo.
Habitualmente el modelado de sistemas y software se centra en el comportamiento
interno del sistema, identificando las operaciones e interacciones que tienen lugar entre los
diferentes componentes que integran un sistema. El enfoque de esta tesis, se centra en la
interaccin entre sistema y operador, esto es en las operaciones que le llegan al sistema
desde el exterior.
Dado que no se suele tener en cuenta el punto de vista de operaciones, que incluye esta
interaccin entre sistema y operador, el modelado de sistemas no refleja de manera explcita
los aspectos de operaciones [4]. Sin embargo, varios estndares y guas de ingeniera de
sistemas y software publicados hace ya varios aos, s que resaltan la importancia de tener
en cuenta las operaciones del sistema en el proceso de desarrollo:
ISO/IEC 15288, Systems engineering - System life cycle processes [83], que es-
tablece un marco comn para describir el ciclo de vida de sistemas, incluyendo el
proceso de utilizacin u operacin del sistema.
ISO/IEC 12207, Standard for Information Technology - Software Lifecycle Pro-
cesses [82], en lnea con el anterior.
IEEE 1362 Guide for Concept of Operations Document [76], que define el concep-
to de documento de operaciones llamado ConOps.
4
-
INCOSE System Engineering Handbook [79], que propone la definicin de un
documento de operaciones ConOps como parte de la especificacin de requisitos del
sistema.
El Systems Engineering Guidebook for ITS [35] publicado por el California De-
partament of Transportation Division of Research and Innovation incluye la etapa
de definicin del concepto de operaciones del sistema previa a la especificacin de
requisitos del sistema, dentro del ciclo de vida de un proyecto ITS (Intelligent Trans-
portation Systems).
ANSI/AIAA G-043-1992 Guide for the Preparation of Operational Concept Docu-
ments [12], que define una gua para preparar documentos con el concepto opera-
cional.
El item DI-IPSC-81430 del estndar militar de Estados Unidos MIL-STD-498 Soft-
ware Development and Documentation [123], en la misma lnea que el anterior.
Tanto es as que estos estndares proporcionan guas y plantillas especficas para con-
feccionar documentos que describan los requisitos de operacin del sistema. Pero aun as,
nos encontramos que la formalizacin existente para modelar las operaciones del sistema
es escasa.
Esta tesis doctoral plantea una solucin para formalizar la interaccin entre sistema y
operador, especificando el modelado de la interaccin de un sistema con el exterior. Dicho
modelado comprende el sistema observable externamente, dnde el operador percibe un
sistema como un conjunto de elementos interconectados. Nuestro enfoque se centra en la
parte del sistema perceptible por el operador y en la interaccin entre ambos.
El modelado de esta interaccin permitir:
1. Incorporar las operaciones en el modelado de sistemas, dando forma a las recomen-
daciones de estndares como los citados anteriormente.
5
-
2. Enriquecer el proceso de desarrollo de un sistema, incorporando el modelado de la
interaccin del sistema tempranamente en el desarrollo de un sistema.
3. Facilitar la validacin y operacin de sistemas, por medio de una aplicacin externa
al sistema que facilite la interaccin con el sistema.
Por otra parte, la solucin propuesta para modelar la interaccin entre sistema y opera-
dor podr aplicarse en:
1. El proceso de desarrollo de sistemas de nueva creacin. En este sentido, esta tesis
plantea la conveniencia de realizar el modelado de las operaciones en etapas tem-
pranas del proceso de desarrollo, para que en la medida de lo posible gue el desarro-
llo del sistema.
2. La validacin y operacin de sistemas ya existentes. El modelo de operaciones del
sistema puede utilizarse en el desarrollo de herramientas de validacin de sistemas y
de operacin/monitorizacin de sistemas.
Por otra parte, respecto al comportamiento de un sistema, nos encontramos que el fun-
cionamiento real de muchos sistemas lleva a situaciones no deterministas porque aun con
sistemas basados en modelos deterministas no es posible modelar el comportamiento para
un nmero de entradas muy elevado (millones) y en un orden desconocido a priori (se
conoce la historia pero no se puede predecir a priori). En este trabajo se simplificar el
comportamiento de un sistema en funcin de sus entradas y salidas, por lo que se har
una abstraccin de la problemtica asociada al determinismo o no determinismo del com-
portamiento de los sistemas. As pues, este trabajo no trata de profundizar en el compor-
tamiento interno de un sistema o de elementos individuales de ste, si no en las interac-
ciones posibles entre un sistema y un medio externo de operacin del mismo. Se centrar
en determinar cmo interactuar con el sistema, definiendo un modelo de interaccin del
sistema.
6
-
1.2. Motivacin y objetivos
Desde hace varios aos el grupo de investigacin SYST (System and Software Tech-
nologies) de la Universidad Politcnica de Madrid (UPM) viene trabajando en el desarrollo
de herramientas software orientadas a la validacin y operacin de sistemas. Como re-
sultado de una amplia actividad en proyectos europeos y nacionales se ha desarrollado
TOPEN (Test and Operation Environment), un entorno de validacin y operacin propio,
en cuya evolucin y diseminacin de resultados, ha participado en parte el autor de este
trabajo [2] [3] [5] [6] [7] [8] [9] [10] [63].
TOPEN es un entorno de pruebas y operacin de sistemas complejos que permite re-
alizar pruebas de aceptacin y operaciones en sistemas que dispongan de una interfaz soft-
ware de interaccin con el sistema. Una descripcin de las funcionalidades de TOPEN se
puede encontrar en [62] [10], y una descripcin de la arquitectura que se desarroll para
TOPEN se encuentra en [64]. Tambin se ha llevado a cabo una tesis doctoral [114] que de-
fine una arquitectura genrica y una lnea de producto para herramientas de validacin de
sistemas, planteando una arquitectura lo suficientemente general para soportar diferentes
dominios de aplicacin sin cambios esenciales en el producto para realizar la validacin.
En el rea de validacin de sistemas existe un vaco de herramientas software que per-
mitan comprobacin y operacin de dispositivos y sistemas industriales complejos [114].
Estos sistemas tienen la caracterstica comn de poder ser operados a travs de una serie
de comandos, descritos como procedimientos en un lenguaje de programacin conven-
cional [62]. Tambin estos sistemas responden a estmulos externos y por eso no siempre
es posible la automatizacin completa de la generacin de los procedimientos de prueba
[43], siendo indispensable la participacin directa del ingeniero de pruebas. De esto lti-
mo, deriva la idea de la definicin de procedimientos de prueba asistida, proporcionando
soporte al ingeniero de pruebas.
TOPEN proporciona a los ingenieros de pruebas un marco para definir, compilar y
7
-
ejecutar procedimientos de prueba, Test Procedure (TP), sobre el sistema a validar y alma-
cenar la informacin de los procedimientos de prueba y el resultado de sus ejecuciones. En
TOPEN, la definicin de un procedimiento de prueba, TP, se realiza mediante un lenguaje
de alto nivel, cercano al ingeniero de pruebas, descrito con una sintaxis orientada al dominio
de aplicacin. Un TP est compuesto de una serie de comandos de operacin, que incluye
comandos para especificar los valores de entrada, el procesamiento de la prueba y los resul-
tados esperados. Los comandos de un TP deben seguir la gramtica previamente definida
para el dominio de aplicacin del sistema a validar. Los datos almacenados relativos a los
resultados de las ejecuciones de los TP permiten obtener el veredicto de las pruebas rea-
lizadas, e incluso validar algunos requisitos que requieren la evaluacin del resultado de
varias ejecuciones de un mismo TP, o del resultado de un conjunto de procedimientos.
El entorno TOPEN comenz a desarrollarse dentro del proyecto ARCO (TIC98-0782),
y mejorado dentro del proyecto MOVASS (TIC2001-3450). Inicialmente ideado para un
sistema de telecomunicaciones, ms tarde se adapt a dos dominios de aplicacin dife-
rentes, uno de los cuales fue un sistema de mquinas de juego interconectadas en red, en
colaboracin con el centro tecnolgico Labein de la agrupacin Tecnalia, dentro del con-
texto del proyecto europeo METSES (IST-2000-28583). Una de las metas del grupo es
conseguir la generacin de entornos de validacin basados en pruebas de aceptacin a par-
tir de los requisitos del sistema que se quiere probar. En esta lnea se ha desarrollado el
proyecto AGMOD (TIC2003-08503). Algunos resultados de estos proyectos se pueden en-
contrar en [5], [8] y [9]. Los ltimos trabajos del grupo en este mbito estn orientados
al modelado de los requisitos necesarios para la generacin del entorno de validacin y se
han publicado ya algunos resultados en [4] y [176]. Otra de las metas se orienta a definir
un modelo de proceso centrado en los requisitos de operaciones y pruebas de validacin de
los sistemas a desarrollar, objetivos que se cubren en los proyectos en desarrollo OVAL/PM
(TIN2006-14840) y FLEXI (FIT-340005-2007-37). Salvo en el primero de los proyectos
de nombre ARCO, en todos los dems el autor de este trabajo ha formado o forma parte
8
-
del equipo de investigadores del proyecto.
La bsqueda de soluciones arquitectnicas y de operaciones aplicables a diferentes do-
minios de aplicacin para TOPEN, permiti detectar una serie de problemas a la hora de
modelar y representar la interaccin entre el operador y el sistema, a partir de los requisitos
del sistema. De ah, que el motivo marcado al comenzar los trabajos que han conducido a
la realizacin de esta tesis fuese el siguiente:
Existe un vaco en el modelado de sistemas ya que no se refleja de manera
explcita el conocimiento de las operaciones del sistema. Los estndares de
ingeniera de sistemas y software resaltan la importancia de las operaciones
del sistema, incluso proporcionan plantillas para confeccionar documentos de
operaciones en el contexto de ingeniera de requisitos y especificacin. Pero sin
embargo, no proporcionan guas especficas para el modelado de operaciones.
El objetivo principal de esta tesis, planteado en el anteproyecto de la misma, es el si-
guiente:
E ,
,
,
.
Basados en este objetivo principal, se han marcado un conjunto de objetivos parciales:
1. Identificar y formalizar los conceptos conducentes a la especificacin del modelo de
interaccin de un sistema y de los elementos que lo forman.
2. Definir el concepto de modelo de operaciones de un sistema (MOS).
9
-
3. Proponer metamodelos que faciliten la representacin de las operaciones en el pro-
ceso de modelado de sistemas, y de su desarrollo en general.
4. Enriquecer el proceso de desarrollo de sistemas, incorporando el modelo de opera-
ciones en etapas iniciales del desarrollo de sistemas.
Considerando los objetivos expuestos, la hiptesis de partida de este trabajo es la si-
guiente:
V -
,
.
1.3. Metodologa de investigacin de la tesis
La metodologa de investigacin utilizada para alcanzar los objetivos marcados en esta
tesis doctoral ha sido la de Investigacin en Accin [15] [17] [145]. En los ltimos aos
los mtodos de investigacin cualitativos y en especial Investigacin en Accin, estn sien-
do aceptados en la comunidad investigadora de sistemas de informacin e ingeniera del
software. Davidson apunta que este hecho se aprecia en el aumento de artculos publicados
sobre Investigacin en Accin en el dominio de sistemas de informacin [45].
El mtodo de investigacin en accin se fundamenta en la idea de que la teora y la
prctica pueden integrarse estrechamente, aprendiendo de los resultados de las actuaciones
planificadas tras un anlisis cuidadoso del contexto del problema.
La figura 1 muestra el ciclo de actividades del proceso de Investigacin en Accin,
consistente en las siguientes fases:
1. Planificacin. En esta fase se identifican cuestiones relevantes que permitan guiar la
investigacin. El trabajo de investigacin se realimenta, con el proyecto de inves-
tigacin en curso o mediante nuevos proyectos de investigacin que proporcionen
10
-
Figura 1: Ciclo de actividades del mtodo Investigacin en Accin
el marco para estos nuevos aspectos o problemas a investigar. En esta tesis, la in-
vestigacin se ha ido realimentando principalmente por medio de los proyectos de
investigacin del grupo de investigacin Syst.
2. Accin. Consiste en una variacin de la prctica mediante una simulacin o prueba de
la solucin. En esta fase, el investigador en accin trabaja en los intereses temticos
del grupo de trabajo participando en las fases de planificacin, actuacin, observacin
y reflexin del ncleo de proyectos investigacin-accin del grupo (definidos como
core action research por Perry y Zuber-Skerritt [138]). En nuestro caso, se ha lla-
mado marco de proyectos a dicho ncleo. La figura 2 muestra el marco de proyectos
relacionado con esta tesis, del grupo de investigacin Syst, en los que el autor de esta
tesis ha participado aplicando el mtodo de investigacin en accin, realimentando
la accin investigadora que ha propiciado la realizacin de esta tesis doctoral. Dicho
marco de proyectos ser descrito en el siguiente apartado.
3. Observacin. El objetivo de esta fase es recoger informacin, tomar datos y docu-
mentar lo que ocurre. Durante esta fase de observacin en la investigacin en accin
de la tesis, se ha descrito tanto la investigacin como el procedimiento seguido. As,
11
-
Figura 2:Marco de proyectos Investigacin en Accin en esta tesis
se ha ido realizando un anlisis y evaluacin de los resultados de las acciones reali-
zadas en la etapa anterior, teniendo en cuenta la literatura relacionada.
4. Reflexin. Esta cuarta fase tiene como objetivo analizar y compartir los resultados
obtenidos en la etapa anterior. Por un lado, se han planteado nuevas cuestiones re-
levantes, comenzando un nuevo ciclo en la investigacin en accin (fase de planifi-
cacin). Por otro lado, se han ido refinando las soluciones encontradas, publicando
artculos en conferencias relacionadas con la investigacin, e incorporndolas a la
memoria de la tesis doctoral.
1.4. Marco de desarrollo de la tesis
El marco de proyectos relacionados con el desarrollo de esta tesis, est compuesto por
un conjunto de proyectos de investigacin realizados en el seno del grupo de investigacin
Syst de la UPM, representados en la figura 2.
1. ARCO: Arquitectura de Sistemas y Comprobacin de Operacin (1998-2001).
12
-
Este proyecto fue financiado por el Ministerio de Ciencia y Tecnologa (TIC98-0782-
R98612501).
2. METSES: Multiple-site Environment for testing Systems with Embedded Soft-
ware (2000-2002). Este proyecto fue financiado por la UE dentro del V Programa
Marco-IST (Ref. IST-2000-28583). La actividad de prueba en sistemas compuestos
por elementos inter-conectados con software embebido es compleja y sofisticada.
Es necesario probar el comportamiento dinmico del sistema completo, no es sufi-
ciente probar cada elemento independientemente. El objetivo de este proyecto fue
desarrollar un entorno de pruebas para sistemas complejos con componentes inter-
relacionados, que pudiera ser adaptado a diferentes sistemas industriales con poco
esfuerzo. Este proyecto soporta la ejecucin remota de pruebas con una arquitectura
cliente-servidor y, por tanto, puede ser utilizado por equipos distribuidos geogrfica-
mente coordinando la realizacin de las pruebas. Soporta la descripcin de pruebas
descritas en un lenguaje de alto nivel, con una sintaxis orientada a dominio. MET-
SES, basado en el entorno TOPEN (Test and Operation Environment) desarrollado
dentro del proyecto ARCO, permite al ingeniero de pruebas definir pruebas a nivel de
usuario, descritas en una sintaxis orientada a dominio, as como compilar y ejecutar
procedimientos de pruebas en el sistema a probar.
3. MOVASS: Modelo y Herramienta para el Proceso de Especificacin de Pruebas
de Validacin de Sistemas Software (2002-2004). Este proyecto ha sido financiado
por el Ministerio de Ciencia y Tecnologa (Ref. TIC 2001-3450). El objetivo bsico
del proyecto consisti en especificar un modelo de proceso para pruebas de valida-
cin de sistemas intensivos en software. Los esfuerzos se orientaron a la generacin
de una herramienta para automatizar la especificacin y ejecucin de pruebas de
aceptacin, partiendo del trabajo realizado previamente con TOPEN. Se definieron
nuevos escenarios basados en aplicaciones industriales para utilizar como entradas
13
-
en la especificacin del modelo de proceso, en conjuncin con el proyecto METSES
que transcurri en paralelo. Se consigui mejorar el proceso de construccin de la
herramienta TOPEN, disminuyendo su coste de adaptacin a nuevos dominios de
aplicacin. Este resultado se consigui a travs de una mayor generalidad de los pa-
trones de diseo y de datos. Por otra parte tambin se avanz en la generacin de
uno de los componentes de la herramienta, el generador de cdigo, a partir de un
modelo de datos y de interaccin utilizando tecnologa XML y Java. Este resultado
tuvo un gran valor dentro de la estrategia del grupo de investigacin, ya que permiti
reorientar la manera de construir TOPEN, acercndolo mucho ms a las necesidades
de la industria.
4. XNetMod: XML Based Modelling Language for Simulation of Technical Net-
works. Este proyecto fue financiado por la Comisin Europea (Ref. IST-2001-52057).
El proyecto tuvo como objetivo principal el desarrollo de una tecnologa de mode-
lado basada en lenguajes XML para sistemas con estructura de red, esto es, com-
puestos por elementos interconectados. Otro objetivo derivado del anterior, fue la
evolucin y adaptacin de herramientas XML para la verificacin, transformacin
y procesamiento de este tipo de modelos de sistema. Los resultados tcnicos se al-
canzaron aplicando la tecnologa desarrollada al modelado y simulacin de sistemas
representables como redes para dominios de aplicacin diferentes, como un workflow
de datos bancarios y la gestin de recursos en una oficina de extincin de incendios
forestales.
5. DOBERTSEE: Dependant On-Board Embedded Real-Time Software Engineering
Environment /Low-Cost On-Board Software Development Toolkit. Este proyecto
fue financiado por ESA/ESTEC (Ref. Contrato 15133/01/NL/ND). El principal ob-
jetivo de este proyecto fue producir un entorno de ingeniera del software integrado,
14
-
Software Engineering Environment (SEE), que contemplase por completo el estn-
dar de modelo de proceso ECSS-E40 para el desarrollo de software embarcable de
tiempo real, Dependable On-Board Real Time software (DOBERT). El modelo de
proceso DOBERTSEE est centrado en documento. Cada documento se expresa en
CASEML (CASE Markup Language), un lenguaje de descripcin basado en XML.
El SEE ha supuesto un valioso experimento para obtener una capa ligera de inge-
niera del software utilizando tecnologas asequibles, facilitando al mismo tiempo la
integracin con herramientas CASE existentes. El entorno desarrollado se ha basado
en los lenguajes CASEML y Tcl/Tk.
Se realiz una extensin de este proyecto, DOBERTSEE CCN-1, consistente en in-
tegrar un entorno de pruebas, en concreto TOPEN, con el entorno de ingeniera SEE
desarrollado. La integracin se bas en la incorporacin en documentos CASEML de
especificaciones de pruebas de aceptacin y de resultados de sus ejecuciones medi-
ante TOPEN. De esta manera se consigui lanzar pruebas de aceptacin, compuestas
de operaciones sobre el sistema, directamente desde el SEE y almacenar los resul-
tados de dichas pruebas automticamente en documentos CASEML. Otro logro de
este proyecto fue establecer un esquema completo de trazabilidad desde requisitos a
pruebas.
6. AGMOD: Generacin Automtica de Herramientas basadas en Modelos de Sis-
temas y Procesos (2003-2006). Este proyecto ha sido financiado por el Ministerio
de Educacin y Ciencia (Ref. TIC 2003-08503). El objetivo de este proyecto fue
realizar una aproximacin al desarrollo de productos software, centrada en los requi-
sitos de operacin y en las pruebas de validacin como piezas clave del desarrollo de
sistemas. Se fundamenta en la definicin de proceso y la integracin de un conjunto
de herramientas existentes compartiendo una filosofa comn subyacente al proce-
so definido. Los requisitos de operacin y las pruebas de validacin constituyen las
bases para el diseo de sistemas permitiendo un ciclo de vida flexible e incremental,
15
-
pero rigurosamente desarrollado y facilitando la ingeniera colaborativa centrada en
las necesidades del usuario. El proceso obtenido se enmarca dentro de estndares
aceptados de ingeniera de software y sistemas tales como IEEE Std 1362-1998 Con-
cept of Operation (ConOps), ISO 12207, Software lifecycle processes e ISO 15288
System lifecycle processes.
7. OVAL/PM: Modelo de Proceso Centrado en Requisitos de Operacin y Pruebas de
Validacin. Este proyecto est siendo financiado por el Ministerio de Educacin y
Ciencia (Ref. TIC 2006-14840). Pretende producir una nueva aproximacin al desa-
rrollo de productos. Esta aproximacin se centra en los requisitos de operacin y en
las pruebas de validacin como las piezas clave del desarrollo de sistemas, llevn-
dose a cabo en trminos de definicin de proceso y un conjunto de herramientas.
El conjunto de herramientas se basar en un nmero de herramientas existentes que
compartirn una filosofa comn subyacente al proceso propuesto. Los requisitos de
operacin y las pruebas de validacin sern las bases para el diseo de sistemas per-
mitiendo un ciclo de vida flexible e incremental, pero rigurosamente desarrollado y
facilitando la ingeniera colaborativa utilizando una aproximacin basada en el acer-
camiento a las necesidades del usuario. El proceso obtenido se enmarcar dentro de
estndares de ingeniera de software y sistemas ampliamente aceptados. La introduc-
cin de estndares facilitar que los resultados del proyecto encajen con las prcti-
cas de ingeniera bien establecidas. La aproximacin considerar el uso de lneas de
producto para soportar la arquitectura del producto. Aunque otras prcticas arquitec-
tnicas podran tenerse en consideracin, sta facilitar que el resultado del proyecto
se centre en un campo de probado xito, facilitando su aplicabilidad.
8. FLEXI: Flexible Integration in Global Product Development. Este proyecto est
16
-
siendo financiado por el Ministerio de Industria, Turismo y Comercio (Ref. FIT-
340005-2007-37, ITEA2 6022). El objetivo de este proyecto es mejorar la compet-
itividad de la industria europea de software intensivo, proporcionando una aprox-
imacin flexible, rpida y gil al desarrollo de productos software que asegure un
desarrollo eficiente de sistemas embebidos y servicios confiables y seguros en un
contexto de desarrollo global. La finalidad de FLEXI es ofrecer medios para obtener
altos rendimientos de negocio: Desde la idea al producto en seis meses de tiempo.
Una de las tareas de este proyecto consistir en aplicar el modelo de operaciones del
sistema definido en esta Tesis, a modelos de proceso de desarrollo giles.
1.5. Presentacin de la tesis
La memoria de la tesis se ha estructurado en una serie de captulos. El primer captulo
que corresponde al actual, conforma la introduccin del trabajo y contiene una descrip-
cin del planteamiento general de esta tesis, de la motivacin y objetivos perseguidos con
la realizacin de sta, del marco de desarrollo de la tesis, y de la metodologa de investi-
gacin seguida. El segundo captulo presenta el estado del arte que ha sido analizado por su
relacin con los aspectos conducentes a la especificacin del modelo de interaccin entre
sistema y operador.
El tercer captulo incluye la definicin del concepto de sistema operable; esta defini-
cin es un requisito para la especificacin de un modelo de operaciones de un sistema. La
definicin realizada incluye tanto la visin intra-elementos como la visin inter-elementos
de un sistema. A partir de sta, se ha definido el concepto de frontend de operaciones de un
sistema, que proporciona el marco adecuado para utilizar el modelo de operaciones.
En el cuarto captulo se define el concepto de modelo de operaciones de un sistema, el
mbito de aplicacin del mismo, y se identifican el subconjunto de requisitos de un sistema
necesarios para la especificacin de un modelo de operaciones.
El quinto captulo presenta una propuesta de representacin del modelo de operaciones
17
-
de un sistema. Esta propuesta incluye la descripcin de un metamodelo del modelo de
operaciones de un sistema, y basado en ste, un perfil UML para representar modelos de
operaciones, al que llamaremos UML 2 Operations Profile (U2OP).
En el sexto captulo se plantea la utilizacin del modelo de operaciones de un sistema
como soporte en el modelado de un frontend de operaciones. En concreto se presenta, por
una parte, una propuesta de metamodelo UML que refleja la interaccin entre el frontend
de operaciones y el sistema, tomando como base el metamodelo de operaciones definido
en el captulo anterior. Por otra parte, se describe una arquitectura conceptual del frontend
de operaciones empleando los diferentes niveles de abstraccin existentes en la interaccin
entre operador y sistema. Y por ltimo se plantea un conjunto de comandos bsicos de
operacin del sistema aplicable a diferentes dominios de aplicacin.
El captulo sptimo presenta como caso de estudio un sistema de mquinas de juego
interconectadas. Se describe el modelo del sistema por medio de diagramas UML, y a
continuacin se define el modelo de operaciones de este sistema utilizando el perfil U2OP
descrito en el quinto captulo.
En el octavo captulo se analiza la utilizacin del modelo de operaciones de un sistema
en procesos de desarrollo software y se propone una aproximacin a un modelo de proceso
software dirigido por el modelo de operaciones.
Y finalmente, en el noveno y ltimo captulo se presentan las conclusiones de la tesis, a
modo de resumen de los logros alcanzados, de los resultados contrastados en diversos foros
y de las posibles lneas de investigacin a las que puede dar lugar.
1.6. Resumen del captulo
Este captulo comprende una introduccin a la tesis doctoral, en el que se ha explica-
do la razn de su planteamiento, y se ha presentado el rea de investigacin en la que se
enmarca: modelado y especificacin de sistemas complejos. Tambin se incluyen la moti-
vacin y objetivos tenidos en cuenta para la realizacin de esta tesis doctoral, estableciendo
18
-
el objetivo principal y objetivos especficos a conseguir, as como la hiptesis de partida.
Adems, se ha indicado el marco de proyectos de investigacin en los que se ha desarro-
llado esta tesis, y la metodologa de investigacin seguida para su desarrollo: Investigacin
en Accin.
19
-
20
-
Captulo II
ESTADO DEL ARTE
En los momentos de crisis, slo la imaginacin
es ms importante que el conocimiento.
Albert Einstein
21
-
2.1. Introduccin
En este captulo se presenta el estado del arte que se ha analizado en relacin con este
trabajo. En primer lugar, se presentan una serie de definiciones y visiones del concepto de
sistema desde el punto de vista de interaccin realizadas por diferentes autores. En segundo
lugar, se analiza un conjunto de paradigmas que permiten representar dicha interaccin
entre sistema y operador.
En tercer lugar, se analizan ciertos estndares de ingeniera del software y sistemas que
tratan esta interaccin entre sistema y operador por medio del concepto de operacin den-
tro del desarrollo de sistemas. Tambin se incluyen otros estndares que definen lenguajes
procedimentales orientados a la operacin y la validacin de sistemas. Se incluye la valida-
cin de sistemas ya que est estrechamente relacionada con la operacin de sistemas, dado
que para realizar ciertas pruebas, especialmente las de aceptacin, se hace necesario llevar
a cabo operaciones sobre el sistema.
En cuarto lugar, se analiza la relacin entre el modelo de interaccin del sistema que
se define en esta tesis y el enfoque de desarrollo de sistemas dirigido por modelo (MDD),
dado que dicho modelo de interaccin puede utilizarse como base para dirigir el desarrollo
de un sistema. Esta revisin se centra en la ingeniera dirigida por modelo, Model Driven
Engineering (MDE), como filosofa y no tanto en tcnicas o procesos que permitan su
aplicacin.
Por ltimo dentro de este captulo, se presenta una seccin de resumen y conclusiones
sobre el estado del arte analizado y su relacin con esta tesis.
2.2. Sistemas desde el punto de vista de interaccin
En esta seccin se presenta sistema desde el punto de vista de interaccin con su en-
torno. Tal y como plantea Wang, los sistemas son las entidades y fenmenos ms com-
plicados de abordar en el mundo fsico, de la informacin y social a travs de todas las
disciplinas de la ciencia y de la ingeniera [171]. Una de las primeras tareas marcadas al
22
-
emprender este trabajo, consisti en analizar diferentes visiones o concepciones de sistema
presentadas por distintos autores, y que posteriormente nos permitiese expresar nuestro
propio concepto de sistema. En esta seccin, se incluyen algunas de las visiones de sistema
analizadas.
2.2.1. Visin filosfica de Bunge
Como parte de un tratado de filosofa bsica, Bunge [32] define un sistema como una
terna ordenada compuesta por los siguientes elementos:
[C(), E(), S ()] (1)
en la que:
C()
Composicin de , representa el conjunto de partes de .
E()
Entorno de , es el conjunto de aquellos elementos que, sin pertenecer a C(), actan
sobre sus componentes o estn sometidos a su influencia.
S()
Estructura de , es el conjunto de relaciones y vnculos de los elementos de C()
entre s o bien con los miembros del entorno E().
La definicin de sistema enunciada por Bunge [32] incluye los componentes o elemen-
tos que componen un sistema, las relaciones entre ellos y por ltimo, el entorno con el que
interacta. Esta definicin aunque proveniente del campo de la filosofa y an siendo muy
general ya que no describe en qu consisten las relaciones y vnculos entre los componentes
de un sistema y entre stos y el entorno, por ejemplo en trminos de estmulos y respuestas,
o de entradas y salidas, se ha incluido por dos razones. Primero porque coincide con la
visin que se va a adoptar en este trabajo de la estructura de un sistema como elementos
23
-
interconectados, y que ser tratada en el captulo siguiente. Y en segundo lugar porque se
ha pretendido dejar patente que el concepto de sistema va ms all del campo de la inge-
niera, abarcando prcticamente todo lo que rodea al ser humano (su mundo) e incluso su
propia composicin fsica y psquica (naturaleza y metafsica).
2.2.2. Jackson: el mundo y la mquina
Jackson en su artculo The World and the Machine en el que llama mquina al sis-
tema y mundo a su entorno, plantea que un software se construye para conseguir, mediante
dispositivos fsicos, atender propsitos prcticos en el mundo [87]. As, el software es una
descripcin de una mquina. Construimos la mquina describindola y presentndola en
un ordenador de propsito general que toma los atributos y comportamientos que hemos
descrito. La mquina tiene sentido en el mundo en el que se instala y utiliza. Por ejemplo,
el valor de un sistema de procesamiento de textos no se evala y juzga examinando su
estructura de software o cdigo, sino por la calidad de los documentos que produce y la
facilidad y satisfaccin de los operadores que lo utilizan.
Los requisitos, que constituyen el problema a resolver, se encuentran en el mundo;
la mquina constituye la solucin que se quiere construir. Aunque esto es algo obvio y
conocido, Jackson indica que conviene tenerlo muy en cuenta, para entender la relacin
entre mundo y mquina.
Jackson plantea que la relacin entre el mundo y la mquina no es sencilla, y que
abarca varias facetas. Reconoce al menos cuatro facetas en esta relacin entre el mundo y
la mquina:
Faceta de modelado, donde la mquina simula al mundo;
Faceta de interfaz, donde el mundo toma contacto con la mquina;
Faceta de ingeniera, donde la mquina acta como un motor de control sobre el
comportamiento del mundo; y
24
-
Faceta del problema, donde la forma del mundo y del problema influyen en la forma
de la mquina y de la solucin.
En palabras de Jackson, la mquina permite aportar soluciones a los problemas del
mundo, si existe una interaccin y una interfaz definidos entre el mundo y la mquina. Por
interaccin entiende la comparticin de un fenmeno, es decir, la participacin directa
en eventos y estados comunes. Afirma que una parte puede tener la potencia de iniciar
un evento, y la otra parte puede tener o no la capacidad de inhibirlo. De igual manera, se
comparten estados; una parte puede tener la capacidad de cambiar el valor de un estado, y
ambos pueden tener la capacidad de percibirlo.
2.2.3. Sistemas definidos como autmatas
Un sistema puede entenderse como un autmata definido por una serie de estados y un
conjunto de transiciones entre estados, distinguiendo entre autmatas de estados finitos o no
finitos, y deterministas o no deterministas respecto a su comportamiento. Adems desde el
punto de vista de interaccin, se puede representar un sistema como un autmata que recibe
una serie de entradas y genera una serie de salidas a partir de las entradas recibidas [91]
[112] [97] [24] [31]. Del mismo modo y como una extensin de los autmatas, se utilizan
las mquinas de estados finitos y diagramas de estados (statecharts) para representar el
comportamiento de los sistemas [111] [105] [68] [147] [85], y ms recientemente [50].
Un Autmata Finito (AF) es un grafo con un nmero finito de vrtices, llamados es-
tados. Los ejes de un diagrama de estados finitos se llaman transiciones y se denotan con
smbolos tomados del dominio del discurso representado por un alfabeto,. Adems uno
de los estados debe ser el estado inicial, y de 0 a n representan los estados finales.
Un AF es determinista, Autmata Finito Determinista (AFD), si NS (S,q) es nico,
donde NS representa la funcin siguiente-estado para un estado S del autmata, y una
entrada q estando en el estado S. Un AFD est completamente especificado si NS(S,q) est
siempre definida y parcialmente especificado en caso contrario.
25
-
Un Autmata Finito No Determinista (AFND) es un AF parcial o completamente es-
pecificado en el que, para algn estado S y para algn smbolo de entrada p, se tiene que
NS(S,p) no es necesariamente nico. Es decir, puede existir un estado S con dos transi-
ciones iguales (misma etiqueta) pero distinto estado destino. A esta situacin se le suele
llamar conflicto en siguiente-estado. Un AFD es un caso particular de un AFND en el que
no existen conflictos de siguiente-estado. Al igual que para un AFD, los requisitos especi-
ficados, descritos o capturados por un AFND corresponden al conjunto de escenarios que
el AFND acepta. Un requisito que puede ser descrito por un AFD se le llama requisito
regular.
Un AFD realiza una computacin o ejecucin como respuesta a un escenario de entrada
con origen en (siendo
el mismo dominio que define al AFD). La computacin de un
AFD viene definida por la secuencia de estados por los que el AFD pasa, partiendo del
estado inicial, como consecuencia de la lectura de las entradas que componen el escenario
de entrada (secuencia de entradas, tambin llamada string). En el caso de los AFND, puesto
que puede existir ms de un estado destino para una misma transicin, la respuesta a un
escenario de entrada corresponde a un rbol de computacin, partiendo del estado inicial.
Para que el AF acepte el escenario de entrada el resultado de la computacin tiene que ser
un estado final en el caso de un AFD, y el rbol de computacin debe tener alguna hoja que
representa un estado final en el caso de un AFND.
Un AF puede verse como una caja negra que genera una secuencia de valores booleanos
de aceptacin/rechazo (valor 1 0) como secuencia de salida. Una mquina de estados
finitos, Finite State Machine (FSM), es similar a un AF, pero en lugar de responder si
acepta o rechaza escenarios de entrada, genera como salida una secuencia de acciones en
respuesta a las entradas.
Las transiciones de un AF se anotan con smbolos tomados de un dominio del discurso
finito (alfabeto) y las transiciones en FSMs se anotan con smbolos de entrada y salida
tomados de alfabetos de entrada y salida respectivamente. Por otra parte, las transiciones
26
-
en diagramas de estados se anotan con eventos, condiciones y acciones, de la forma:
Evento[condicion]/accion
El evento suele proceder de una entidad externa mientras que una condicin suele estar
definida en el sistema. Las acciones que genera el sistema pueden ser enviadas, incluyendo
datos o no, a entidades externas.
As pues, la definicin de un sistema como mquina de estados finitos permite estable-
cer la interaccin de un sistema en funcin de sus entradas y salidas. Si bien su repre-
sentacin puede verse limitada cuando existe un gran nmero de estados en el sistema.
2.2.4. Broy: sistemas reactivos e interactivos
Broy es uno de los autores que ms trabajos ha realizado relativos a la descripcin
de sistemas. Ha publicado numerosos trabajos orientados a la descripcin y formalizacin
tanto de sistemas reactivos como de sistemas interactivos, entre ellos [24] [31] [25] [27]
[30] [26] [28]. En este apartado se presentan algunas caractersticas de ambos tipos de
sistemas desde el punto de vista de la relacin entre un sistema y su entorno.
2.2.4.1. Sistemas reactivos
Los sistemas reactivos producen respuestas al recibir estmulos de entrada. Muchas
de las propuestas realizadas para representar el comportamiento de sistemas reactivos se
han basado en el concepto de traza. Una traza describe una secuencia finita o infinita de
acciones de entrada y de salida en un sistema reactivo.
En [24], Broy describe un sistema reactivo en trminos de acciones de entrada y de
salida y caracteriza el comportamiento de los sistemas reactivos por medio de conjuntos de
trazas, secuencias de acciones de entrada y de salida. Broy utiliza la definicin de sistema
reactivo de Harel y Pnueli [69]: un sistema reactivo es un sistema abierto que est rela-
cionado con su entorno de tal manera que reacciona ante los estmulos de entrada realizados
desde ste.
27
-
Para la descripcin de sistemas reactivos mediante trazas, Broy asume que stos son
asncronos [24]. En una interaccin sncrona el emisor y el receptor deben estar preparados
para establecer la comunicacin, sin embargo en una interaccin asncrona cada accin se
realiza exclusivamente por uno de los componentes, sin tener en cuenta si el receptor est
o no preparado para la comunicacin.
La interfaz entre el entorno y el sistema reactivo se reduce a acciones de entrada, envi-
adas desde el entorno al sistema, y de salida, enviadas desde el sistema al entorno. Por tanto,
la interfaz de un sistema reactivo con el entorno se describe nicamente por medio del con-
junto de acciones de entrada aceptadas por el sistema y el conjunto de acciones de salida
que puede generar ste. Las acciones de entrada son producidas por el entorno y observadas
por el sistema reactivo que reacciona ante ellas, y las salidas son generadas por el sistema
reactivo y observadas por el entorno. Esta relacin entre entorno y sistema queda reflejada
en la figura 3 adaptada de una figura que utiliza Broy para representar esquemticamente
un sistema reactivo [24].
Broy entiende que los conjuntos de trazas que describen las interfaces estn compuestos
por acciones de entrada y acciones de salida, y que la interaccin entre el sistema reactivo
y el entorno es asncrona por lo que las acciones de entrada pueden ocurrir en cualquier
momento (en cualquier posicin de la traza) [24]. Denomina sistemas-I/O a los sistemas
reactivos asncronos, con I como acciones de entrada y O como acciones de salida. Asume
que: 1) un sistema-I/O no puede influir en qu acciones de entrada se producen, ni cuando;
2) y que en cada punto de una historia de ejecucin (representada por una traza finita) el
sistema-I/O selecciona la siguiente accin de salida basndose solamente en la informacin
contenida en la traza finita de acciones de entrada y salida sucedidas anteriormente. Sin
embargo, plantea que dicha seleccin puede hacerse de forma no determinista.
Una estrategia del sistema determina qu accin de salida, si la hay, debe ser la si-
guiente, dependiendo nicamente de la historia previa, garantizando que las decisiones del
sistema no tienen en cuenta las futuras acciones de entrada. De esta manera, Broy establece
28
-
Figura 3: Relacin entre el sistema y su entorno (adaptada de Broy [24])
una correspondencia entre los sistemas-I/O y las mquinas de estado o autmatas. Dado
que los sistemas reactivos con frecuencia presentan un comportamiento no determinista,
plantea modelar el no determinismo mediante estrategias deterministas basadas en con-
juntos de trazas, y argumenta que cualquier conjunto de trazas realizable por una estrategia
no determinista es tambin realizable por un conjunto de estrategias deterministas.
Los sistemas reactivos pueden describirse mediante autmatas de entrada/salida, aut-
matasI/O, ya que se consideran un mecanismo formal para definir conjuntos de trazas,
equivalentes a los conjuntos de palabras aceptadas [91] [112]. En esta lnea, Broy presen-
ta una formalizacin matemtica [24], definiendo un sistema reactivo como un autmata
determinista con entradas y salidas, formado por la siguiente quintupla:
(I,O,, 0,R, F) (2)
dnde:
29
-
I: es un conjunto de acciones de entrada, que no contiene la accin silenciosa {}.
Broy llama accin silenciosa (silent action) a aquellas acciones que no tienen efecto
sobre el sistema desde el punto de vista de relacin con el exterior, su entorno.
O: es un conjunto de acciones de salida, disjunto de I y que no contiene la accin
silenciosa {}.
: es un conjunto de estados.
0: es el estado inicial del autmata.
R: es un subconjunto de x (I O 0) x , llamado el conjunto de transiciones
etiquetadas.
F: representa una coleccin finita de conjuntos imparciales en la que cada conjunto
imparcial (fairness) es un subconjunto de R.
Broy utiliza a para denotar una transicin etiquetada en R, donde , y a
(I O {}). Para Broy, un autmata-I/O representa la tupla (I,O,, 0,R, F) que tiene
las siguientes propiedades:
1. Para cada estado y accin de entrada i I, hay un estado tal que i
R.
2. Ningn conjunto imparcial F F puede contener una transicin i con i I.
3. Cada transicin a R en la que a O {} es miembro de algn conjunto
imparcial perteneciente a F.
Estas propiedades tienen el siguiente significado:
Estados en los que el autmata puede aceptar acciones de entrada.
Los conjuntos imparciales no deben restringir la entrada, p.e., solo las decisiones
internas del autmata pueden verse influidas por consideraciones imparciales.
30
-
Expresan que el autmata es equitativo con respecto a todas las transiciones silen-
ciosas y de salida.
Para esta definicin de sistema, Broy se apoya en el comportamiento interno del sis-
tema, caracterizado por estados y sus transiciones. Descripciones en esta misma lnea, en
la que se definen un sistema en funcin de sus estados pueden encontrarse en [168], [47],
[48]. Wieringa caracteriza las respuestas de un sistema reactivo en funcin de su estado
actual y de los eventos externos a los que responde, en contraposicin a lo que llama sis-
temas transformacionales en los que el estado del sistema no depende de entidades externas
[175]. Por otro lado, tambin Jonsson, como Broy, utiliza el concepto de accin silenciosa,
y lo aplica a transiciones silenciosas (silent transitions) correspondientes a etapas internas
de un autmata para modelar la composicin del autmata [91].
2.2.4.2. Sistemas interactivos
Como se ha indicado anteriormente, Broy tambin entiende los sistemas como interac-
tivos. Plantea que los sistemas interactivos consisten en un conjunto de componentes que
cooperan e intercambian informacin por medio de interacciones [31] [28]. Ejemplos de
sistemas interactivos, en claro crecimiento, son los sistemas compuestos de componentes y
dispositivos electrnicos en la industria del automvil y de la avinica [26] [30] [106]. Los
sistemas software con interfaces definidos, y en especial los servicios software, tambin
comprenden ejemplos de sistemas interactivos.
Broy y Stolen en [31] dentro del contexto de especificacin de sistemas interactivos
definen sistema como una estructura tcnica o sociolgica compuesta de un grupo de
entidades combinadas para formar un todo y trabajar, funcionar o moverse interdependien-
temente y armoniosamente; las partes que componen un sistema se llaman componentes o
subsistemas, y pueden ser entendidas como sistemas en s mismos, as, los sistemas estn
estructurados jerrquicamente en subsistemas.
Adems indican que uno de los aspectos ms importantes en el modelado de sistemas
31
-
consiste en representar con exactitud el conjunto de interacciones que se puedan producir
entre un sistema y su entorno, as como las que se puedan producir internamente entre
los elementos que componen el sistema [31]. Estas interacciones requieren de un acuerdo
de cooperacin tcito entre los elementos que intervienen en la interaccin, incluido el
entorno, y de un intercambio en muchas ocasiones de informacin entre ellos. As, para
estos autores, la descripcin de un sistema interactivo se realiza en trminos de entradas y
salidas, de manera que se abstraen de la estructura interna de los componentes del sistema,
y proporcionan lo que llaman descripciones de interface o caja negra.
Para describir los sistemas interactivos Broy tambin se basa en las trazas de acciones
de sistemas I/O. La idea que presenta es que los interfaces de los sistemas interactivos
pueden ser descritos caracterizando sus historias o trazas de interaccin de mensajes de
entrada y salida. Esta descripcin de sistema interactivo mediante trazas es anloga a la
descripcin de sistemas reactivos que ha sido descrita en el apartado anterior.
Los componentes de un sistema suelen verse como cajas negras observando exclusiva-
mente el comportamiento externo de sus entradas y salidas, y ocultando lo que sucede entre
la recepcin de un mensaje de entrada y la generacin del correspondiente mensaje de sa-
lida. Sin embargo, Broy plantea que en ocasiones puede ser interesante imponer o registrar
restricciones en la estructura interna o comportamiento del sistema, dando lugar a lo que
llama vistas de caja de cristal. Broy define este tipo de vistas entendiendo que se permite
mirar dentro de la caja como si sus lados estuvieran hechos de cristal transparente. De este
modo para representar un sistema plantea una vista del sistema como caja de cristal, trans-
parente respecto a los elementos que lo componen y las conexiones entre ellos, pero opaco
(vista de caja negra) para cada elemento en particular. As, el comportamiento interno de
cada componente no es observable, siendo de inters solamente las entradas y salidas que
intervienen en las interacciones con otros componentes o con el entorno.
Broy y Stolen plantean que en etapas tempranas del desarrollo de un sistema general-
mente se suele utilizar una vista de caja negra, y que segn se va avanzando en el desarrollo
32
-
Figura 4: Caja negra y de cristal (adaptada de Broy [31])
del sistema se utilizan vistas o especificaciones de caja de cristal que permiten especificar
aspectos de la organizacin interna de los componentes del sistema. La figura 4 representa
la vista de un componente del sistema como caja negra y como caja de cristal.
En [28] Broy introduce un modelo matemtico para sistemas compuestos de elementos
que interactan entre ellos, as como las vistas y relaciones necesarias en el proceso de
desarrollo. Tambin en [31], Broy y Stolen proporcionan unas bases matemticas y lgicas
para la especificacin formal y desarrollo de sistemas interactivos, de forma individual y
como componentes interactivos. Asumen que los componentes del sistema estn conec-
tados por lneas de comunicacin, sncronas o asncronas, a las que llama canales, que
permiten el intercambio de informacin en trminos de mensajes. Los mensajes viajan por
el canal de uno en uno, y se entregan en el mismo orden en el que fueron enviados. Puesto
que las propiedades dinmicas de estos sistemas pueden ser muy complejas, los describe
en trminos de comportamiento de entrada/salida. Utilizan los streams, secuencias finitas o
infinitas de mensajes, para modelar las historias de comunicacin de canales dirigidos, que
33
-
transmiten en una nica direccin. La relacin input/output representa la relacin entre los
streams de entrada y los de salida. Por una historia input/output de un componente entien-
den cualquier pareja de streams input/output en sus relaciones de entrada y salida. A partir
de aqu, expresan la propiedad de que un stream de salida es un prefijo del substream de
elementos de d