-
Universidad Politécnica de Madrid
Facultad de InformáticaDepartamento de Lenguajes, Sistemas
Informáticos e Ingeniería del
Software
ESPECIFICACIÓN DE UN MODELO DE
INTERACCIÓN APLICABLE A PROCESOS DE
DESARROLLO Y OPERACIÓN DE SISTEMAS CON
SOFTWARE
TESIS DOCTORAL
Autor: Pedro Pablo Alarcón CaveroIngeniero en Informática
Director: Juan Garbajosa SopeñaDoctor en Informática
Enero 2008
-
Tribunal nombrado por el Mgfco. Y Excmo. Sr. Rector de la
Universidad Politécnica
de Madrid, el día de de 2008.
Presidente D.
Vocal D.
Vocal D.
Vocal D.
Secretario D.
Realizado el acto de defensa y lectura de la Tesis el día de de
2008.
En Madrid:
Calificación:
EL PRESIDENTE LOS VOCALES
EL SECRETARIO
-
A mis padres, inicio de este trabajo hace unos cuantos años, os
quiero.
A mis hijos, Jesús, 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, están grabadas en mi
corazón.
-
AGRADECIMIENTOS
Gracias a todos los que han participado en mi vida hasta
completar mi formación
académica 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 también
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 están aquí... todos de
una forma u otra han aportado
granitos de arena hasta formar esta montaña.
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 García,
Carlos Cuvillo, Eugenio
Santos, Héctor García, Javier Gil, Jéssica Díaz, Jorge Tejedor,
LuisFer, Manuel Bollaín,
Miguel Angel Díaz, 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 más sincero agradecimiento a
las siguientes personas
que me han prestado su inestimable ayuda durante la realización
de esta tesis:
Juan Garbajosa — director de esta tesis, por embarcarme hace
unos cuantos años en
esta aventura y brindarme la oportunidad de trabajar juntos
realizando este trabajo de
investigación.
Agustín Yagüe — siempre ha estado ahí cuando le he necesitado;
más que un com-
pañero, un amigo.
-
Jennifer Pérez — por aparecer como el séptimo de caballería
cuando más 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 aplicación o
aplicaciones externas que posibiliten dicha interacción entre
ambos. Esta interacción con-
templa las operaciones admitidas por el sistema, expresadas por
el envío de entradas al
sistema y la recepción 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 implícita y
lateral junto con el resto de
aspectos que sí reciben atención 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
interacción de un sistema con el exterior. El objetivo principal
de este trabajo de inves-
tigación es el de especificar un modelo de interacción con el
operador del sistema, al que
denominamos “modelo de operaciones de un sistema”, que permita
ser utilizado como base
en el desarrollo y operación/monitorización de sistemas
intensivos software.
Este trabajo realiza una aportación en el campo del modelado y
especificación de sis-
temas complejos, contribuyendo con nuevas definiciones para
“sistema operable” y “mode-
lo de operaciones de un sistema”, y proponiendo además, 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 operación y validación de sistemas, y tomando
como base estas propuestas
-
de representación del modelo de operaciones de un sistema, se
aporta una aproximación al
modelado del frontend de operaciones de un sistema. Esta
aproximación incluye un meta-
modelo, una arquitectura conceptual y un conjunto de operaciones
básicas del sistema. Por
último, y en el campo del modelado y gestión 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 utilización, 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 ACRÓNIMOS Y ABREVIATURAS . . . . . . . . . . . . . . .
. . .
I. INTRODUCCIÓN . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 1
1.1. Planteamiento de la tesis doctoral . . . . . . . . . . . .
. . . . . . . . . . 2
1.2. Motivación y objetivos . . . . . . . . . . . . . . . . . .
. . . . . . . . . . 7
1.3. Metodología de investigación de la tesis . . . . . . . . .
. . . . . . . . . 10
1.4. Marco de desarrollo de la tesis . . . . . . . . . . . . . .
. . . . . . . . . 12
1.5. Presentación de la tesis . . . . . . . . . . . . . . . . .
. . . . . . . . . . 17
1.6. Resumen del capítulo . . . . . . . . . . . . . . . . . . .
. . . . . . . . . 18
II. ESTADO DEL ARTE . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 21
2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . 22
2.2. Sistemas desde el punto de vista de interacción . . . . . .
. . . . . . . . . 22
2.2.1. Visión filosófica de Bunge . . . . . . . . . . . . . . .
. . . . . . 23
2.2.2. Jackson: el mundo y la máquina . . . . . . . . . . . . .
. . . . . 24
2.2.3. Sistemas definidos como autómatas . . . . . . . . . . . .
. . . . 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. Visión de Wang . . . . . . . . . . . . . . . . . . . . .
. . . . . . 34
2.2.6. Modelo de cuatro variables de Parnas . . . . . . . . . .
. . . . . . 36
-
2.3. Paradigmas en el modelado de la interacción 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 Interacción Hombre-Computador (HCI) .
. . 48
2.3.6. Paradigma basado en operaciones . . . . . . . . . . . . .
. . . . 49
2.4. Concepto de operación de sistemas en estándares de
ingeniería de sis-temas y software . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 52
2.4.1. Visión de documento de operaciones . . . . . . . . . . .
. . . . . 53
2.4.2. Lenguajes procedurales de operación 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 capítulo . . . . . . . . . . . .
. . . . . . . . 65
III. CONCEPTUALIZACIÓN DE SISTEMA OPERABLE . . . . . . . . . . .
. 75
3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . 76
3.2. Los sistemas con componentes inter-relacionados . . . . . .
. . . . . . . 76
3.2.1. Sistema como autómata . . . . . . . . . . . . . . . . . .
. . . . . 76
3.2.2. Relación 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 operación . . . . . . . . . . . . . . . . .
. . 88
3.2.4. Estructura de un sistema . . . . . . . . . . . . . . . .
. . . . . . 88
3.2.4.1. Visión estructural intra-elementos . . . . . . . . . .
. . 89
3.2.4.2. Visión estructural inter-elementos . . . . . . . . . .
. . 94
3.3. Los Sistemas con componentes inter-relacionados como
sistemas de in-teracción . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 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. Interacción Sistema-Entorno . . . . . . . . . . . . . .
. 106
3.3.3.2. Interacción Operador-Frontend de operaciones . . . . .
106
3.3.3.3. Interacción Sistema-Frontend de Operaciones del
Sistema106
3.4. Resumen y conclusiones del capítulo . . . . . . . . . . . .
. . . . . . . . 109
IV. MODELO DE OPERACIONES DE UN SISTEMA . . . . . . . . . . . .
. . 111
4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . 112
4.2. Definición de modelo de operaciones de un sistema . . . . .
. . . . . . . 113
4.3. Ámbito de aplicación del modelo de operaciones de un
sistema . . . . . . 118
4.4. Modelo de operaciones y requisitos de un sistema . . . . .
. . . . . . . . 121
4.4.1. Estándar ECSS-E10Part6A . . . . . . . . . . . . . . . . .
. . . . 121
4.4.2. Estándar 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 operación . . . . . . . . . . . . . . . . .
. . . . . . 129
4.6. Recomendaciones para especificar el modelo de operaciones
de un sistema 131
4.7. Resumen y conclusiones del capítulo . . . . . . . . . . . .
. . . . . . . . 134
V. PROPUESTADEREPRESENTACIÓNDELMODELODEOPERACIONESDE 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. Enumeración ElementStatus . . . . . . . . . . . . . . .
148
5.2.1.5. Enumeración PropertyType . . . . . . . . . . . . . . .
148
5.2.1.6. Tipo de datos PropertyValue . . . . . . . . . . . . . .
. 149
-
5.2.2. Vista de interacción . . . . . . . . . . . . . . . . . .
. . . . . . . 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. Definición de un perfil UML 2 de operaciones (U2OP) . . . .
. . . . . . . 155
5.3.1. Descripción . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 155
5.3.2. Prerrequisitos . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 157
5.3.3. Nuevos tipos de datos . . . . . . . . . . . . . . . . . .
. . . . . . 157
5.3.3.1. Enumeración 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 capítulo . . . . . . . . . . . .
. . . . . . . . 167
VI. APLICACIÓN DEL MODELO DE OPERACIONES DEL SISTEMA CO-MO
SOPORTE PARA EL MODELADO DEL FRONTEND DE OPERA-CIONES . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
169
6.1. Introducción . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . 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 operación . . . . . . . . . . . . . . . . .
. . . . . . 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: Interacción operador-sistema . . . . . . . . . .
. . . . . 187
6.3.2. Nivel 2: Interacción SOF-Sistema . . . . . . . . . . . .
. . . . . 188
6.3.3. Nivel 3: Comunicación 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 básicos de operación de un sistema . . . . . . . .
. . . . . . . 194
-
6.4.1. Sintaxis general . . . . . . . . . . . . . . . . . . . .
. . . . . . . 195
6.4.2. Clasificación de comandos básicos de operación . . . . .
. . . . . 197
6.4.3. Operaciones de administración o configuración . . . . . .
. . . . 198
6.4.3.1. CreateSE . . . . . . . . . . . . . . . . . . . . . . .
. . 199
6.4.3.2. DeleteSE . . . . . . . . . . . . . . . . . . . . . . .
. . 200
6.4.4. Operaciones de Interacción . . . . . . . . . . . . . . .
. . . . . . 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 capítulo . . . . . . . . . . . .
. . . . . . . . 206
VII. APLICACIÓN DELMODELO DE OPERACIONES A UN CASO PRÁCTI-CO . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . 209
7.1. Introducción . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . 210
7.2. Descripción del caso . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . 211
7.2.1. Concepto de sistema . . . . . . . . . . . . . . . . . . .
. . . . . 211
7.2.2. Requisitos para la certificación de máquinas
interconectadas . . . 213
7.2.3. Descripción del problema a resolver . . . . . . . . . . .
. . . . . 216
7.2.4. Descripción de la solución . . . . . . . . . . . . . . .
. . . . . . 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. Aplicación 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 capítulo . . . . . . . . . . . .
. . . . . . . . 249
VIII.APLICACIÓN DEL MODELO DE OPERACIONES EN PROCESOS
DEDESARROLLO Y OPERACIÓN DE SISTEMAS . . . . . . . . . . . . . . .
251
8.1. Utilización del modelo de operaciones en procesos de
desarrollo de sistemas252
8.2. El modelo de operaciones como soporte en la generación de
herramientasde validación y operación de sistemas . . . . . . . . .
. . . . . . . . . . . 255
8.3. Enriquecimiento del proceso de desarrollo de sistemas . . .
. . . . . . . . 261
-
8.3.1. Desarrollo incremental del sistema . . . . . . . . . . .
. . . . . . 264
8.3.2. Validación del sistema . . . . . . . . . . . . . . . . .
. . . . . . . 265
8.4. Resumen y conclusiones del capítulo . . . . . . . . . . . .
. . . . . . . . 266
IX. CONCLUSIONES . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 267
9.1. Análisis del logro de objetivos . . . . . . . . . . . . . .
. . . . . . . . . . 268
9.2. Aportaciones a la investigación . . . . . . . . . . . . . .
. . . . . . . . . 271
9.3. Contraste de resultados . . . . . . . . . . . . . . . . . .
. . . . . . . . . 273
9.4. Líneas de investigación 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 genéricas . . . . . . . . . . . . . .
. . . . . . . . 198
-
Índice de figuras
1. Ciclo de actividades del método Investigación en Acción . . .
. . . . . . . 11
2. Marco de proyectos Investigación en Acción en esta tesis . .
. . . . . . . . 12
3. Relación 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. Relación 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 interacción . . . . . . . . . . . . . . . .
. . . . . . . . . . 86
12. Segundo nivel de interacción . . . . . . . . . . . . . . . .
. . . . . . . . . 87
13. Correspondencia entre entradas y propiedades perceptibles .
. . . . . . . . 93
14. Correspondencia entre salidas y propiedades perceptibles . .
. . . . . . . . 94
15. Representación 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. Relación entre Sistema y Frontend de Operaciones del Sistema
. . . . . . . 105
20. Interacción 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. Interacción operador-sistema . . . . . . . . . . .
. . . . . . . . . 187
28. Nivel 2. Interacción 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 máquinas de juego de azar interconectadas . . . .
. . . . . . . . 213
33. Diagrama de casos de uso de una máquina acumulador . . . . .
. . . . . . 222
34. “Workflow"de una máquina de juego . . . . . . . . . . . . .
. . . . . . . . 223
35. Diagrama de clases . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . 226
36. Diagrama de actividades . . . . . . . . . . . . . . . . . .
. . . . . . . . . 235
37. Diagrama de secuencia . . . . . . . . . . . . . . . . . . .
. . . . . . . . . 236
38. Diagrama de estados de una máquina acumulador . . . . . . .
. . . . . . . 239
39. Diagrama de clases decorado con el perfil U2OP . . . . . . .
. . . . . . . 243
40. Frontend de operaciones en procesos de validación y
operación . . . . . . . 259
41. Proceso de desarrollo enriquecido por el MOS . . . . . . . .
. . . . . . . . 262
-
Lista de Acrónimos y Abreviaturas
AF Autómata Finito
AFD Autómata Finito Determinista
AFND Autómata 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 Politécnica de Madrid
WSDL Web Service Description Language
-
Capítulo I
INTRODUCCIÓN
“No dejes apagar el entusiasmo,
virtud tan valiosa como necesaria;
trabaja, aspira, tiende siempre hacia la altura.”
Rubén Darío
1
-
1.1. Planteamiento de la tesis doctoral
En el contexto de este trabajo, los sistemas se entenderán de
manera general, como
sistemas intensivos en software. Este tipo de sistemas
representan típicamente sistemas
heterogéneos que incluyen componentes software junto con otro
tipo de dispositivos, que
les permiten interaccionar con su entorno [60]. Esta interacción
se produce típicamente
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 investigación, soportada por nuevas competencias
técnicas, que incluyan una
buena comprensión del modelado de sistemas, el uso efectivo de
modelos, y una teoría 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 aplicación o aplicaciones externas que
posibilitan las operaciones del
sistema.
Así pues, la especificación y modelado de requisitos de
operación 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 utilizarán el
sistema. De ahí que ciertos
estándares incluyan el concepto de operación, y pautas para
expresar un documento de
operaciones del sistema que recoja los requisitos de operación
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-
plícita y lateral junto con el resto de aspectos o puntos de
vista del sistema que sí reciben
atención 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 estándar IEEE 1471 - IEEE
Recommended Practice Archi-
tectural Description of Software-Intensive Systems [78], define
punto de vista como una
especificación de reglas para construir una vista del sistema
que comprenda una serie de
aspectos de stakeholders 1. Sería por tanto interesante enfocar
el desarrollo de un sistema
incluyendo el punto de vista de operaciones, al objeto de
separar el interés (concern) de
operaciones del sistema de una manera nítida 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 crítico ya que una vez la nave espacial
está en el espacio puede ser
muy difícil o imposible determinar un problema. Para sistemas de
espacio, es recomendable
e incluso forzoso producir modelos de operación 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 especificación del modelo de operación. Los sistemas de
espacio utilizan a menudo co-
mo línea base telemetría y telecomandos. Esto es, el sistema de
tierra envía un telecomando
a la nave espacial y ésta responde con una telemetría. Esta
aproximación es un esquema
muy simple y eficiente para modelar la interacción del sistema.
Como justifican Garbajosa
et al. en [62], este esquema se puede transportar fácilmente, en
términos orientados a obje-
tos, una operación, el telecomando, y un objeto, la nave
espacial, que devuelve un valor, la
telemetría. Obviamente es posible refinar este esquema para una
carga de pago (payload)
basada en objetos y operaciones asociadas.
El enfoque de modelo de operación en sistemas de espacio puede
utilizarse en otros
tipos de sistemas, aunque pueda necesitarse una metodología
propia y una infraestructura
1conjunto de personas implicadas en el desarrollo y operación
del sistema
3
-
de herramientas. Este trabajo persigue proporcionar una
aproximación en la que los mo-
delos de operaciones del sistema sean una piedra angular para el
desarrollo, validación y
operación de sistemas.
Esta tesis doctoral se enmarca dentro de la línea de
investigación “Modelado y especi-
ficación de sistemas complejos”. El modelado de sistemas
complejos, y de sistemas en
general, constituye un pilar fundamental tanto en el desarrollo
como en la evolución de és-
tos. Los modelos aportan conocimiento del sistema al conjunto de
stakeholders implicados
(ya sean pasados, presentes o futuros) facilitando el
entendimiento y comprensión 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
interacción 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
interacción entre sistema y operador, el modelado de sistemas no
refleja de manera explícita
los aspectos de operaciones [4]. Sin embargo, varios estándares
y guías de ingeniería de
sistemas y software publicados hace ya varios años, 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 común para describir el ciclo de vida de
sistemas, incluyendo el
proceso de utilización u operación del sistema.
“ISO/IEC 12207, Standard for Information Technology - Software
Lifecycle Pro-
cesses” [82], en línea 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
definición de un
documento de operaciones ConOps como parte de la especificación
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 definición del concepto de operaciones del sistema previa a
la especificación 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 guía para preparar documentos con el
concepto opera-
cional.
El item DI-IPSC-81430 del estándar militar de Estados Unidos
“MIL-STD-498 Soft-
ware Development and Documentation” [123], en la misma línea que
el anterior.
Tanto es así que estos estándares proporcionan guías y
plantillas específicas para con-
feccionar documentos que describan los requisitos de operación
del sistema. Pero aun así,
nos encontramos que la formalización existente para modelar las
operaciones del sistema
es escasa.
Esta tesis doctoral plantea una solución para formalizar la
interacción entre sistema y
operador, especificando el modelado de la interacción de un
sistema con el exterior. Dicho
modelado comprende el sistema observable externamente, dónde 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
interacción entre ambos.
El modelado de esta interacción permitirá:
1. Incorporar las operaciones en el modelado de sistemas, dando
forma a las recomen-
daciones de estándares como los citados anteriormente.
5
-
2. Enriquecer el proceso de desarrollo de un sistema,
incorporando el modelado de la
interacción del sistema tempranamente en el desarrollo de un
sistema.
3. Facilitar la validación y operación de sistemas, por medio de
una aplicación externa
al sistema que facilite la interacción con el sistema.
Por otra parte, la solución propuesta para modelar la
interacción entre sistema y opera-
dor podrá aplicarse en:
1. El proceso de desarrollo de sistemas de nueva creación. 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 guíe el desarro-
llo del sistema.
2. La validación y operación de sistemas ya existentes. El
modelo de operaciones del
sistema puede utilizarse en el desarrollo de herramientas de
validación de sistemas y
de operación/monitorización 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 número 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 función de sus entradas y
salidas, por lo que se hará
una abstracción de la problemática 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 operación
del mismo. Se centrará
en determinar cómo interactuar con el sistema, definiendo un
modelo de interacción del
sistema.
6
-
1.2. Motivación y objetivos
Desde hace varios años el grupo de investigación SYST (System
and Software Tech-
nologies) de la Universidad Politécnica de Madrid (UPM) viene
trabajando en el desarrollo
de herramientas software orientadas a la validación y operación
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 validación
y operación propio,
en cuya evolución y diseminación 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 operación de sistemas complejos
que permite re-
alizar pruebas de aceptación y operaciones en sistemas que
dispongan de una interfaz soft-
ware de interacción con el sistema. Una descripción de las
funcionalidades de TOPEN se
puede encontrar en [62] [10], y una descripción de la
arquitectura que se desarrolló para
TOPEN se encuentra en [64]. También se ha llevado a cabo una
tesis doctoral [114] que de-
fine una arquitectura genérica y una línea de producto para
herramientas de validación de
sistemas, planteando una arquitectura lo suficientemente general
para soportar diferentes
dominios de aplicación sin cambios esenciales en el producto
para realizar la validación.
En el área de validación de sistemas existe un vacío de
herramientas software que per-
mitan comprobación y operación de dispositivos y sistemas
industriales complejos [114].
Estos sistemas tienen la característica común de poder ser
operados a través de una serie
de comandos, descritos como procedimientos en un lenguaje de
programación conven-
cional [62]. También estos sistemas responden a estímulos
externos y por eso no siempre
es posible la automatización completa de la generación de los
procedimientos de prueba
[43], siendo indispensable la participación directa del
ingeniero de pruebas. De esto últi-
mo, deriva la idea de la definición 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 información de los procedimientos de prueba y el
resultado de sus ejecuciones. En
TOPEN, la definición 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 aplicación. Un TP está compuesto de una serie de comandos de
operación, 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 gramática
previamente definida
para el dominio de aplicación 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
evaluación 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, más tarde se adaptó a dos
dominios de aplicación dife-
rentes, uno de los cuales fue un sistema de máquinas de juego
interconectadas en red, en
colaboración con el centro tecnológico Labein de la agrupación
Tecnalia, dentro del con-
texto del proyecto europeo METSES (IST-2000-28583). Una de las
metas del grupo es
conseguir la generación de entornos de validación basados en
pruebas de aceptación a par-
tir de los requisitos del sistema que se quiere probar. En esta
línea 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 están orientados
al modelado de los requisitos necesarios para la generación del
entorno de validación 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 validación 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 demás el autor de este trabajo ha
formado o forma parte
8
-
del equipo de investigadores del proyecto.
La búsqueda de soluciones arquitectónicas y de operaciones
aplicables a diferentes do-
minios de aplicación para TOPEN, permitió detectar una serie de
problemas a la hora de
modelar y representar la interacción 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 realización de esta tesis fuese el siguiente:
Existe un vacío en el modelado de sistemas ya que no se refleja
de manera
explícita el conocimiento de las operaciones del sistema. Los
estándares de
ingeniería de sistemas y software resaltan la importancia de las
operaciones
del sistema, incluso proporcionan plantillas para confeccionar
documentos de
operaciones en el contexto de ingeniería de requisitos y
especificación. Pero sin
embargo, no proporcionan guías específicas para el modelado de
operaciones.
El objetivo principal de esta tesis, planteado en el
anteproyecto de la misma, es el si-
guiente:
É ́ ,
,
́ , ́
́ ́.
Basados en este objetivo principal, se han marcado un conjunto
de objetivos parciales:
1. Identificar y formalizar los conceptos conducentes a la
especificación del modelo de
interacción 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 representación 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 hipótesis de partida de
este trabajo es la si-
guiente:
V -
́ , ́
́ .
1.3. Metodología de investigación de la tesis
La metodología de investigación utilizada para alcanzar los
objetivos marcados en esta
tesis doctoral ha sido la de “Investigación en Acción” [15] [17]
[145]. En los últimos años
los métodos de investigación cualitativos y en especial
Investigación en Acción, están sien-
do aceptados en la comunidad investigadora de sistemas de
información e ingeniería del
software. Davidson apunta que este hecho se aprecia en el
aumento de artículos publicados
sobre Investigación en Acción en el dominio de sistemas de
información [45].
El método de investigación en acción se fundamenta en la idea de
que la teoría y la
práctica pueden integrarse estrechamente, aprendiendo de los
resultados de las actuaciones
planificadas tras un análisis cuidadoso del contexto del
problema.
La figura 1 muestra el ciclo de actividades del proceso de
Investigación en Acción,
consistente en las siguientes fases:
1. Planificación. En esta fase se identifican cuestiones
relevantes que permitan guiar la
investigación. El trabajo de investigación se realimenta, con el
proyecto de inves-
tigación en curso o mediante nuevos proyectos de investigación
que proporcionen
10
-
Figura 1: Ciclo de actividades del método Investigación en
Acción
el marco para estos nuevos aspectos o problemas a investigar. En
esta tesis, la in-
vestigación se ha ido realimentando principalmente por medio de
los proyectos de
investigación del grupo de investigación Syst.
2. Acción. Consiste en una variación de la práctica mediante una
simulación o prueba de
la solución. En esta fase, el investigador en acción trabaja en
los intereses temáticos
del grupo de trabajo participando en las fases de planificación,
actuación, observación
y reflexión del núcleo de proyectos investigación-acción 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 núcleo. La figura 2 muestra el
marco de proyectos
relacionado con esta tesis, del grupo de investigación Syst, en
los que el autor de esta
tesis ha participado aplicando el método de investigación en
acción, realimentando
la acción investigadora que ha propiciado la realización de esta
tesis doctoral. Dicho
marco de proyectos será descrito en el siguiente apartado.
3. Observación. El objetivo de esta fase es recoger información,
tomar datos y docu-
mentar lo que ocurre. Durante esta fase de observación en la
investigación en acción
de la tesis, se ha descrito tanto la investigación como el
procedimiento seguido. Así,
11
-
Figura 2:Marco de proyectos Investigación en Acción en esta
tesis
se ha ido realizando un análisis y evaluación de los resultados
de las acciones reali-
zadas en la etapa anterior, teniendo en cuenta la literatura
relacionada.
4. Reflexión. 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 investigación en
acción (fase de planifi-
cación). Por otro lado, se han ido refinando las soluciones
encontradas, publicando
artículos en conferencias relacionadas con la investigación, e
incorporándolas 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 investigación realizados en el seno
del grupo de investigación
Syst de la UPM, representados en la figura 2.
1. ARCO: “Arquitectura de Sistemas y Comprobación de Operación”
(1998-2001).
12
-
Este proyecto fue financiado por el Ministerio de Ciencia y
Tecnología (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 dinámico 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 ejecución remota de pruebas
con una arquitectura
cliente-servidor y, por tanto, puede ser utilizado por equipos
distribuidos geográfica-
mente coordinando la realización de las pruebas. Soporta la
descripción 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
Especificación de Pruebas
de Validación de Sistemas Software” (2002-2004). Este proyecto
ha sido financiado
por el Ministerio de Ciencia y Tecnología (Ref. TIC 2001-3450).
El objetivo básico
del proyecto consistió en especificar un modelo de proceso para
pruebas de valida-
ción de sistemas intensivos en software. Los esfuerzos se
orientaron a la generación
de una herramienta para automatizar la especificación y
ejecución de pruebas de
aceptación, partiendo del trabajo realizado previamente con
TOPEN. Se definieron
nuevos escenarios basados en aplicaciones industriales para
utilizar como entradas
13
-
en la especificación del modelo de proceso, en conjunción con el
proyecto METSES
que transcurrió en paralelo. Se consiguió mejorar el proceso de
construcción de la
herramienta TOPEN, disminuyendo su coste de adaptación a nuevos
dominios de
aplicación. Este resultado se consiguió a través de una mayor
generalidad de los pa-
trones de diseño y de datos. Por otra parte también se avanzó en
la generación de
uno de los componentes de la herramienta, el generador de
código, a partir de un
modelo de datos y de interacción utilizando tecnología XML y
Java. Este resultado
tuvo un gran valor dentro de la estrategia del grupo de
investigación, ya que permitió
reorientar la manera de construir TOPEN, acercándolo mucho más a
las necesidades
de la industria.
4. XNetMod: “XML Based Modelling Language for Simulation of
Technical Net-
works”. Este proyecto fue financiado por la Comisión Europea
(Ref. IST-2001-52057).
El proyecto tuvo como objetivo principal el desarrollo de una
tecnología 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
evolución y adaptación de herramientas XML para la verificación,
transformación
y procesamiento de este tipo de modelos de sistema. Los
resultados técnicos se al-
canzaron aplicando la tecnología desarrollada al modelado y
simulación de sistemas
representables como redes para dominios de aplicación
diferentes, como un workflow
de datos bancarios y la gestión de recursos en una oficina de
extinción 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 ingeniería
del software integrado,
14
-
Software Engineering Environment (SEE), que contemplase por
completo el están-
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 descripción basado
en XML.
El SEE ha supuesto un valioso experimento para obtener una capa
ligera de inge-
niería del software utilizando tecnologías asequibles,
facilitando al mismo tiempo la
integración con herramientas CASE existentes. El entorno
desarrollado se ha basado
en los lenguajes CASEML y Tcl/Tk.
Se realizó una extensión de este proyecto, DOBERTSEE CCN-1,
consistente en in-
tegrar un entorno de pruebas, en concreto TOPEN, con el entorno
de ingeniería SEE
desarrollado. La integración se basó en la incorporación en
documentos CASEML de
especificaciones de pruebas de aceptación y de resultados de sus
ejecuciones medi-
ante TOPEN. De esta manera se consiguió lanzar pruebas de
aceptación, compuestas
de operaciones sobre el sistema, directamente desde el SEE y
almacenar los resul-
tados de dichas pruebas automáticamente en documentos CASEML.
Otro logro de
este proyecto fue establecer un esquema completo de trazabilidad
desde requisitos a
pruebas.
6. AGMOD: “Generación Automática de Herramientas basadas en
Modelos de Sis-
temas y Procesos” (2003-2006). Este proyecto ha sido financiado
por el Ministerio
de Educación y Ciencia (Ref. TIC 2003-08503). El objetivo de
este proyecto fue
realizar una aproximación al desarrollo de productos software,
centrada en los requi-
sitos de operación y en las pruebas de validación como piezas
clave del desarrollo de
sistemas. Se fundamenta en la definición de proceso y la
integración de un conjunto
de herramientas existentes compartiendo una filosofía común
subyacente al proce-
so definido. Los requisitos de operación y las pruebas de
validación constituyen las
bases para el diseño de sistemas permitiendo un ciclo de vida
flexible e incremental,
15
-
pero rigurosamente desarrollado y facilitando la ingeniería
colaborativa centrada en
las necesidades del usuario. El proceso obtenido se enmarca
dentro de estándares
aceptados de ingeniería 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
Operación y Pruebas de
Validación”. Este proyecto está siendo financiado por el
Ministerio de Educación y
Ciencia (Ref. TIC 2006-14840). Pretende producir una nueva
aproximación al desa-
rrollo de productos. Esta aproximación se centra en los
requisitos de operación y en
las pruebas de validación como las piezas clave del desarrollo
de sistemas, lleván-
dose a cabo en términos de definición de proceso y un conjunto
de herramientas.
El conjunto de herramientas se basará en un número de
herramientas existentes que
compartirán una filosofía común subyacente al proceso propuesto.
Los requisitos de
operación y las pruebas de validación serán las bases para el
diseño de sistemas per-
mitiendo un ciclo de vida flexible e incremental, pero
rigurosamente desarrollado y
facilitando la ingeniería colaborativa utilizando una
aproximación basada en el acer-
camiento a las necesidades del usuario. El proceso obtenido se
enmarcará dentro de
estándares de ingeniería de software y sistemas ampliamente
aceptados. La introduc-
ción de estándares facilitará que los resultados del proyecto
encajen con las prácti-
cas de ingeniería bien establecidas. La aproximación considerará
el uso de líneas de
producto para soportar la arquitectura del producto. Aunque
otras prácticas arquitec-
tónicas podrían tenerse en consideración, é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-
imación flexible, rápida 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. Presentación de la tesis
La memoria de la tesis se ha estructurado en una serie de
capítulos. El primer capítulo
que corresponde al actual, conforma la introducción del trabajo
y contiene una descrip-
ción del planteamiento general de esta tesis, de la motivación y
objetivos perseguidos con
la realización de ésta, del marco de desarrollo de la tesis, y
de la metodología de investi-
gación seguida. El segundo capítulo presenta el estado del arte
que ha sido analizado por su
relación con los aspectos conducentes a la especificación del
modelo de interacción entre
sistema y operador.
El tercer capítulo incluye la definición del concepto de sistema
operable; esta defini-
ción es un requisito para la especificación de un modelo de
operaciones de un sistema. La
definición realizada incluye tanto la visión intra-elementos
como la visión 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 capítulo se define el concepto de modelo de
operaciones de un sistema, el
ámbito de aplicación del mismo, y se identifican el subconjunto
de requisitos de un sistema
necesarios para la especificación de un modelo de
operaciones.
El quinto capítulo presenta una propuesta de representación del
modelo de operaciones
17
-
de un sistema. Esta propuesta incluye la descripción 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 capítulo se plantea la utilización 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
interacción entre el frontend
de operaciones y el sistema, tomando como base el metamodelo de
operaciones definido
en el capítulo anterior. Por otra parte, se describe una
arquitectura conceptual del frontend
de operaciones empleando los diferentes niveles de abstracción
existentes en la interacción
entre operador y sistema. Y por último se plantea un conjunto de
comandos básicos de
operación del sistema aplicable a diferentes dominios de
aplicación.
El capítulo séptimo presenta como caso de estudio un sistema de
máquinas de juego
interconectadas. Se describe el modelo del sistema por medio de
diagramas UML, y a
continuación se define el modelo de operaciones de este sistema
utilizando el perfil U2OP
descrito en el quinto capítulo.
En el octavo capítulo se analiza la utilización del modelo de
operaciones de un sistema
en procesos de desarrollo software y se propone una aproximación
a un modelo de proceso
software dirigido por el modelo de operaciones.
Y finalmente, en el noveno y último capítulo 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 líneas de investigación a las que puede dar
lugar.
1.6. Resumen del capítulo
Este capítulo comprende una introducción a la tesis doctoral, en
el que se ha explica-
do la razón de su planteamiento, y se ha presentado el área de
investigación en la que se
enmarca: modelado y especificación de sistemas complejos.
También se incluyen la moti-
vación y objetivos tenidos en cuenta para la realización de esta
tesis doctoral, estableciendo
18
-
el objetivo principal y objetivos específicos a conseguir, así
como la hipótesis de partida.
Además, se ha indicado el marco de proyectos de investigación en
los que se ha desarro-
llado esta tesis, y la metodología de investigación seguida para
su desarrollo: Investigación
en Acción.
19
-
20
-
Capítulo II
ESTADO DEL ARTE
“En los momentos de crisis, sólo la imaginación
es más importante que el conocimiento.”
Albert Einstein
21
-
2.1. Introducción
En este capítulo se presenta el estado del arte que se ha
analizado en relación con este
trabajo. En primer lugar, se presentan una serie de definiciones
y visiones del concepto de
sistema desde el punto de vista de interacción realizadas por
diferentes autores. En segundo
lugar, se analiza un conjunto de paradigmas que permiten
representar dicha interacción
entre sistema y operador.
En tercer lugar, se analizan ciertos estándares de ingeniería
del software y sistemas que
tratan esta interacción entre sistema y operador por medio del
concepto de operación den-
tro del desarrollo de sistemas. También se incluyen otros
estándares que definen lenguajes
procedimentales orientados a la operación y la validación de
sistemas. Se incluye la valida-
ción de sistemas ya que está estrechamente relacionada con la
operación de sistemas, dado
que para realizar ciertas pruebas, especialmente las de
aceptación, se hace necesario llevar
a cabo operaciones sobre el sistema.
En cuarto lugar, se analiza la relación entre el modelo de
interacción del sistema que
se define en esta tesis y el enfoque de desarrollo de sistemas
dirigido por modelo (MDD),
dado que dicho modelo de interacción puede utilizarse como base
para dirigir el desarrollo
de un sistema. Esta revisión se centra en la ingeniería dirigida
por modelo, Model Driven
Engineering (MDE), como filosofía y no tanto en técnicas o
procesos que permitan su
aplicación.
Por último dentro de este capítulo, se presenta una sección de
resumen y conclusiones
sobre el estado del arte analizado y su relación con esta
tesis.
2.2. Sistemas desde el punto de vista de interacción
En esta sección se presenta sistema desde el punto de vista de
interacción con su en-
torno. Tal y como plantea Wang, los sistemas son las entidades y
fenómenos más com-
plicados de abordar en el mundo físico, de la información y
social a través de todas las
disciplinas de la ciencia y de la ingeniería [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 sección, se incluyen algunas
de las visiones de sistema
analizadas.
2.2.1. Visión filosófica de Bunge
Como parte de un tratado de filosofía básica, Bunge [32] define
un sistema Σ como una
terna ordenada compuesta por los siguientes elementos:
[C(Σ), E(Σ), S (Σ)] (1)
en la que:
C(Σ)
Composición de Σ, representa el conjunto de partes de Σ.
E(Σ)
Entorno de Σ, es el conjunto de aquellos elementos que, sin
pertenecer a C(Σ), actúan
sobre sus componentes o están sometidos a su influencia.
S(Σ)
Estructura de Σ, es el conjunto de relaciones y vínculos de los
elementos de C(Σ)
entre sí o bien con los miembros del entorno E(Σ).
La definición 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
interactúa. Esta definición aunque proveniente del campo de la
filosofía y aún siendo muy
general ya que no describe en qué consisten las relaciones y
vínculos entre los componentes
de un sistema y entre éstos y el entorno, por ejemplo en
términos de estímulos y respuestas,
o de entradas y salidas, se ha incluido por dos razones. Primero
porque coincide con la
visión que se va a adoptar en este trabajo de la estructura de
un sistema como elementos
23
-
interconectados, y que será tratada en el capítulo siguiente. Y
en segundo lugar porque se
ha pretendido dejar patente que el concepto de sistema va más
allá del campo de la inge-
niería, abarcando prácticamente todo lo que rodea al ser humano
(su mundo) e incluso su
propia composición física y psíquica (naturaleza y
metafísica).
2.2.2. Jackson: el mundo y la máquina
Jackson en su artículo “The World and the Machine” en el que
llama máquina al sis-
tema y mundo a su entorno, plantea que un software se construye
para conseguir, mediante
dispositivos físicos, atender propósitos prácticos en el mundo
[87]. Así, el software es una
descripción de una máquina. Construimos la máquina
describiéndola y presentándola en
un ordenador de propósito general que toma los atributos y
comportamientos que hemos
descrito. La máquina 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 evalúa y
juzga examinando su
estructura de software o código, sino por la calidad de los
documentos que produce y la
facilidad y satisfacción de los operadores que lo utilizan.
Los requisitos, que constituyen el problema a resolver, se
encuentran en el mundo;
la máquina constituye la solución que se quiere construir.
Aunque esto es algo obvio y
conocido, Jackson indica que conviene tenerlo muy en cuenta,
para entender la relación
entre mundo y máquina.
Jackson plantea que la relación entre el mundo y la máquina no
es sencilla, y que
abarca varias facetas. Reconoce al menos cuatro facetas en esta
relación entre el mundo y
la máquina:
Faceta de modelado, donde la máquina simula al mundo;
Faceta de interfaz, donde el mundo toma contacto con la
máquina;
Faceta de ingeniería, donde la máquina actúa 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 máquina y de la solución.
En palabras de Jackson, la máquina permite aportar soluciones a
los problemas del
mundo, si existe una interacción y una interfaz definidos entre
el mundo y la máquina. Por
“interacción” entiende la compartición de un fenómeno, es decir,
la participación 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 autómatas
Un sistema puede entenderse como un autómata definido por una
serie de estados y un
conjunto de transiciones entre estados, distinguiendo entre
autómatas de estados finitos o no
finitos, y deterministas o no deterministas respecto a su
comportamiento. Además desde el
punto de vista de interacción, se puede representar un sistema
como un autómata 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 extensión de los
autómatas, se utilizan
las máquinas de estados finitos y diagramas de estados
(statecharts) para representar el
comportamiento de los sistemas [111] [105] [68] [147] [85], y
más recientemente [50].
Un Autómata Finito (AF) es un grafo con un número finito de
vértices, llamados es-
tados. Los ejes de un diagrama de estados finitos se llaman
transiciones y se denotan con
símbolos tomados del dominio del discurso representado por un
alfabeto,∑. Además uno
de los estados debe ser el estado inicial, y de 0 a n
representan los estados finales.
Un AF es determinista, Autómata Finito Determinista (AFD), si NS
(S,q) es único,
donde NS representa la función siguiente-estado para un estado S
del autómata, 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 Autómata Finito No Determinista (AFND) es un AF parcial o
completamente es-
pecificado en el que, para algún estado S y para algún símbolo
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 situación 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 computación o ejecución como respuesta a un
escenario de entrada
con origen en∑∗ (siendo
∑el mismo dominio que define al AFD). La computación 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, también llamada string). En
el caso de los AFND, puesto
que puede existir más de un estado destino para una misma
transición, la respuesta a un
escenario de entrada corresponde a un árbol de computación,
partiendo del estado inicial.
Para que el AF acepte el escenario de entrada el resultado de la
computación tiene que ser
un estado final en el caso de un AFD, y el árbol de computación
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 aceptación/rechazo (valor 1 ó 0) como secuencia de salida.
Una máquina 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 símbolos tomados de un
dominio del discurso
finito (alfabeto) y las transiciones en FSMs se anotan con
símbolos 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
condición 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 definición de un sistema como máquina de estados
finitos permite estable-
cer la interacción de un sistema en función de sus entradas y
salidas. Si bien su repre-
sentación puede verse limitada cuando existe un gran número de
estados en el sistema.
2.2.4. Broy: sistemas reactivos e interactivos
Broy es uno de los autores que más trabajos ha realizado
relativos a la descripción
de sistemas. Ha publicado numerosos trabajos orientados a la
descripción y formalización
tanto de sistemas reactivos como de sistemas interactivos, entre
ellos [24] [31] [25] [27]
[30] [26] [28]. En este apartado se presentan algunas
características de ambos tipos de
sistemas desde el punto de vista de la relación entre un sistema
y su entorno.
2.2.4.1. Sistemas reactivos
Los sistemas reactivos producen respuestas al recibir estímulos
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 términos 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 definición 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
estímulos de entrada realizados
desde éste”.
27
-
Para la descripción de sistemas reactivos mediante trazas, Broy
asume que éstos son
asíncronos [24]. En una interacción síncrona el emisor y el
receptor deben estar preparados
para establecer la comunicación, sin embargo en una interacción
asíncrona cada acción se
realiza exclusivamente por uno de los componentes, sin tener en
cuenta si el receptor está
o no preparado para la comunicación.
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 relación entre
entorno y sistema queda reflejada
en la figura 3 adaptada de una figura que utiliza Broy para
representar esquemáticamente
un sistema reactivo [24].
Broy entiende que los conjuntos de trazas que describen las
interfaces están compuestos
por acciones de entrada y acciones de salida, y que la
interacción entre el sistema reactivo
y el entorno es asíncrona por lo que las acciones de entrada
pueden ocurrir en cualquier
momento (en cualquier posición de la traza) [24]. Denomina
sistemas-I/O a los sistemas
reactivos asíncronos, 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 ejecución
(representada por una traza finita) el
sistema-I/O selecciona la siguiente acción de salida basándose
solamente en la información
contenida en la traza finita de acciones de entrada y salida
sucedidas anteriormente. Sin
embargo, plantea que dicha selección puede hacerse de forma no
determinista.
Una estrategia del sistema determina qué acción 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: Relación entre el sistema y su entorno (adaptada de
Broy [24])
una correspondencia entre los sistemas-I/O y las máquinas de
estado o autómatas. 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 también realizable por un conjunto de
estrategias deterministas.
Los sistemas reactivos pueden describirse mediante autómatas 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 línea, Broy presen-
ta una formalización matemática [24], definiendo un sistema
reactivo como un autómata
determinista con entradas y salidas, formado por la siguiente
quintupla:
(I,O,Σ, σ0,R, F) (2)
dónde:
29
-
I: es un conjunto de acciones de entrada, que no contiene la
acción silenciosa {τ}.
Broy llama acción silenciosa (silent action) a aquellas acciones
que no tienen efecto
sobre el sistema desde el punto de vista de relación con el
exterior, su entorno.
O: es un conjunto de acciones de salida, disjunto de I y que no
contiene la acción
silenciosa {τ}.
Σ: es un conjunto de estados.
σ0: es el estado inicial del autómata.
R: es un subconjunto de σ x (I ∪ O ∪ σ0) x Σ, llamado el
conjunto de transiciones
etiquetadas.
F: representa una colección finita de conjuntos imparciales en
la que cada conjunto
imparcial (fairness) es un subconjunto de R.
Broy utiliza σ→a σ′ para denotar una transición etiquetada en R,
donde σ, σ’ ∈ Σ y a
∈ (I ∪ O ∪ {τ}). Para Broy, un autómata-I/O representa la tupla
(I,O,Σ, σ0,R, F) que tiene
las siguientes propiedades:
1. Para cada estado σ ∈ Σ y acción de entrada i ∈ I, hay un
estado σ’ ∈ Σ tal que σ→i σ’
∈ R.
2. Ningún conjunto imparcial F ∈ F puede contener una transición
σ→i σ’ con i ∈ I.
3. Cada transición σ →a σ’ ∈ R en la que a ∈ O ∪ {τ} es miembro
de algún conjunto
imparcial perteneciente a F.
Estas propiedades tienen el siguiente significado:
Estados en los que el autómata puede aceptar acciones de
entrada.
Los conjuntos imparciales no deben restringir la entrada, p.e.,
solo las decisiones
internas del autómata pueden verse influidas por consideraciones
imparciales.
30
-
Expresan que el autómata es equitativo con respecto a todas las
transiciones silen-
ciosas y de salida.
Para esta definición de sistema, Broy se apoya en el
comportamiento interno del sis-
tema, caracterizado por estados y sus transiciones.
Descripciones en esta misma línea, en
la que se definen un sistema en función de sus estados pueden
encontrarse en [168], [47],
[48]. Wieringa caracteriza las respuestas de un sistema reactivo
en función de su estado
actual y de los eventos externos a los que responde, en
contraposición a lo que llama sis-
temas transformacionales en los que el estado del sistema no
depende de entidades externas
[175]. Por otro lado, también Jonsson, como Broy, utiliza el
concepto de acción silenciosa,
y lo aplica a transiciones silenciosas (silent transitions)
correspondientes a etapas internas
de un autómata para modelar la composición del autómata
[91].
2.2.4.2. Sistemas interactivos
Como se ha indicado anteriormente, Broy también entiende los
sistemas como interac-
tivos. Plantea que los sistemas interactivos consisten en un
conjunto de componentes que
cooperan e intercambian información por medio de interacciones
[31] [28]. Ejemplos de
sistemas interactivos, en claro crecimiento, son los sistemas
compuestos de componentes y
dispositivos electrónicos en la industria del automóvil y de la
aviónica [26] [30] [106]. Los
sistemas software con interfaces definidos, y en especial los
servicios software, también
comprenden ejemplos de sistemas interactivos.
Broy y Stolen en [31] dentro del contexto de especificación de
sistemas interactivos
definen sistema como una “estructura técnica o sociológica
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 están
estructurados jerárquicamente en subsistemas”.
Además indican que uno de los aspectos más 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 cooperación tácito entre los elementos que intervienen en la
interacción, incluido el
entorno, y de un intercambio en muchas ocasiones de información
entre ellos. Así, para
estos autores, la descripción de un sistema interactivo se
realiza en términos 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 también 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
interacción de mensajes de
entrada y salida. Esta descripción de sistema interactivo
mediante trazas es análoga a la
descripción de sistemas reactivos que ha sido descrita en el
apartado anterior.
Los componentes de un sistema suelen verse como cajas negras
observando exclusiva-