Pedro Pablo

Universidad Politcnica de Madrid
Facultad de Informtica
Departamento 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 Cavero

Ingeniero en Informtica
Director: Juan Garbajosa Sopea
Doctor 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
En Madrid:
Calificacin:
EL PRESIDENTE
LOS VOCALES
EL SECRETARIO
de 2008.
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 compaero, 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 contempla 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 operaciones 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 investigacin 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 sistemas complejos, contribuyendo con nuevas definiciones para sistema operable y modelo 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 metamodelo, 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 responses, 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 environment. 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 being 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 metamodel 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 approach 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 contributes 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. Planteamiento de la tesis doctoral . . . . . . . . . . . . . . . . . . . . . .
1.2. Motivacin y objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 sistemas 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 interaccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

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
V.
PROPUESTA DE REPRESENTACIN DEL MODELO DE OPERACIONES

DE 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

VI. APLICACIN DEL MODELO DE OPERACIONES DEL SISTEMA COMO SOPORTE PARA EL MODELADO DEL FRONTEND DE OPERACIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

VII. APLICACIN DEL MODELO DE OPERACIONES A UN CASO PRCTICO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
VIII.APLICACIN DEL MODELO DE OPERACIONES EN PROCESOS DE
DESARROLLO 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 herramientas
de 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
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. 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 conocimiento incluye, al menos, el comportamiento del sistema observable externamente, es
decir, el conocimiento de las interacciones que pueden darse entre el sistema y el operador, 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 conocimiento 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
proceso de desarrollo. Los aspectos de operaciones del sistema se abordan de manera implcita 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 Architectural 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 convierten 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 como 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 objetos, 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
1
conjunto de personas implicadas en el desarrollo y operacin del sistema
de herramientas. Este trabajo persigue proporcionar una aproximacin en la que los modelos 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 especificacin 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 stos. 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 establece 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 Processes [82], en lnea con el anterior.
IEEE 1362 Guide for Concept of Operations Document [76], que define el concepto 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 Departament 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 Transportation Systems).
ANSI/AIAA G-043-1992 Guide for the Preparation of Operational Concept Documents [12], que define una gua para preparar documentos con el concepto operacional.
El item DI-IPSC-81430 del estndar militar de Estados Unidos MIL-STD-498 Software Development and Documentation [123], en la misma lnea que el anterior.
Tanto es as que estos estndares proporcionan guas y plantillas especficas para confeccionar 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 recomendaciones de estndares como los citados anteriormente.
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 operador 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 tempranas del proceso de desarrollo, para que en la medida de lo posible gue el desarrollo 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 funcionamiento 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 comportamiento de los sistemas. As pues, este trabajo no trata de profundizar en el comportamiento interno de un sistema o de elementos individuales de ste, si no en las interacciones 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 Technologies) de la Universidad Politcnica de Madrid (UPM) viene trabajando en el desarrollo
de herramientas software orientadas a la validacin y operacin de sistemas. Como resultado 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 realizar pruebas de aceptacin y operaciones en sistemas que dispongan de una interfaz software 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 define 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 permitan 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 convencional [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 ltimo, 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
ejecutar procedimientos de prueba, Test Procedure (TP), sobre el sistema a validar y almacenar 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 resultados 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 realizadas, 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 diferentes, 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 contexto 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 partir 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 encontrar 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
del equipo de investigadores del proyecto.

La bsqueda de soluciones arquitectnicas y de operaciones aplicables a diferentes dominios 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 siguiente:

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 proceso de modelado de sistemas, y de su desarrollo en general.
4. Enriquecer el proceso de desarrollo de sistemas, incorporando el modelo de operaciones en etapas iniciales del desarrollo de sistemas.
Considerando los objetivos expuestos, la hiptesis de partida de este trabajo es la siguiente:
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 siendo 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 investigacin 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 investigacin 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 llamado 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 documentar 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 realizadas 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 relevantes, comenzando un nuevo ciclo en la investigacin en accin (fase de planificacin). 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-0782R98612501).

2. METSES: Multiple-site Environment for testing Systems with Embedded Software (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 suficiente probar cada elemento independientemente. El objetivo de este proyecto fue
desarrollar un entorno de pruebas para sistemas complejos con componentes interrelacionados, 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 geogrficamente coordinando la realizacin de las pruebas. Soporta la descripcin de pruebas
descritas en un lenguaje de alto nivel, con una sintaxis orientada a dominio. METSES, 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 validacin 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 patrones 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 Networks. Este proyecto fue financiado por la Comisin Europea (Ref. IST-2001-52057).
El proyecto tuvo como objetivo principal el desarrollo de una tecnologa de modelado basada en lenguajes XML para sistemas con estructura de red, esto es, compuestos 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 alcanzaron 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 objetivo de este proyecto fue producir un entorno de ingeniera del software integrado,
14
Software Engineering Environment (SEE), que contemplase por completo el estndar 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 ingeniera 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 integrar 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 mediante TOPEN. De esta manera se consigui lanzar pruebas de aceptacin, compuestas
de operaciones sobre el sistema, directamente desde el SEE y almacenar los resultados 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 Sistemas 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 requisitos 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 proceso 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 Concept 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 desarrollo 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, llevndose 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 permitiendo un ciclo de vida flexible e incremental, pero rigurosamente desarrollado y
facilitando la ingeniera colaborativa utilizando una aproximacin basada en el acercamiento a las necesidades del usuario. El proceso obtenido se enmarcar dentro de
estndares de ingeniera de software y sistemas ampliamente aceptados. La introduccin de estndares facilitar que los resultados del proyecto encajen con las prcticas de ingeniera bien establecidas. La aproximacin considerar el uso de lneas de
producto para soportar la arquitectura del producto. Aunque otras prcticas arquitectnicas 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. FIT340005-2007-37, ITEA2 6022). El objetivo de este proyecto es mejorar la competitividad de la industria europea de software intensivo, proporcionando una aproximacin 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 descripcin 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 investigacin 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 definicin 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 explicado 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 motivacin 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 desarrollado 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 dentro 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 validacin 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 entorno. Tal y como plantea Wang, los sistemas son las entidades y fenmenos ms complicados 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 elementos 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 ingeniera, 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 sistema 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 estados. Los ejes de un diagrama de estados finitos se llaman transiciones y se denotan con
P
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 especificado 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 transiciones 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 especificados, 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
P
P
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 establecer la interaccin de un sistema en funcin de sus entradas y salidas. Si bien su representacin 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 relacionado 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, enviadas 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 conjunto 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 siguiente, 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 conjuntos 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, autmatasI/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 presenta 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)
dnde:
29
(2)
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 0 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 silenciosas y de salida.
Para esta definicin de sistema, Broy se apoya en el comportamiento interno del sistema, 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 sistemas 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 interactivos. 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 interdependientemente 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 exclusivamente 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 salida. 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, transparente 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 generalmente 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 conectados 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 entienden 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 datos en el stream de entrada, y el nmero de mensajes en el stream de salida
es igual al nmero de seales de peticin en el stream de entrada. Esta ltima propiedad
deja patente que los autores representan el comportamiento de lo sistemas como determinista, ya que un sistema con comportamiento no determinista puede ofrecer varias historias
de salida para una misma historia de entrada.
2.2.5. Visin de Wang
Yingxu Wang en el artculo On Abstract Systems and System Algebra [171] presenta
una demostracin de cmo los sistemas se pueden tratar rigurosamente como entidades
matemticas, e introduce el concepto de sistema abstracto y sus modelos matemticos.
Introduce un algebra de sistemas para expresar reglas de composicin y operaciones de
sistemas, tales como conjuncin, diferencia, composicin y descomposicin de sistemas.
Define sistema abstracto como una coleccin de entidades coherentes e interactivas que
tienen funciones estables y lmites claros con el entorno externo, y los clasifica en sistemas
cerrados y sistemas abiertos.
Wang define un sistema cerrado S como una tupla de cuatro elementos:
S = (C, R, B, )
(3)
dnde:
R es un conjunto no vaco de relaciones entre parejas de componentes en el sistema,
R = {r1 , r2 , ..., rn }, R C C.
B es un conjunto de comportamientos (o funciones) del sistema, B = {b1 , b2 , ..., bn }.
Aunque Wang no expresa explcitamente si este comportamiento es determinista o
34
no determinista, al equipararlo con funciones del sistema entendemos que lo trata

como determinista.
es un conjunto de restricciones en los componentes derivadas de la existencia de
condiciones de relacin entre componentes y del alcance de sus comportamientos,
= {1 , 2 , ..., n }.
Las relaciones R de un sistema cerrado se definen dentro del producto cartesiano de los
componentes internos. Sin embargo, en un sistema abierto, que tiene interacciones con su
entorno, se hace necesario extender el conjunto de relaciones R incluyendo las relaciones
internas Rc y las relaciones externas Ri y Ro que corresponden a las entradas y salidas del
sistema:
R = Rc Ri Ro
A partir de aqu, define un sistema abierto como una tupla de siete elementos:
S = (C, R, B, , ) = (C, Rc , Ri , Ro , B, , )
(4)
dnde:
es el entorno del sistema S con un conjunto no vaco de componentes C externos
a C.
Rc C C, es un conjunto de relaciones internas.
Ri C C, es un conjunto de relaciones externas de entrada.
Ro C C , es un conjunto de relaciones externas de salida.
La figura 5 muestra la representacin grfica de un sistema abierto, realizada por Wang
[171].
35
Figura 5: Modelo de sistema abierto (Wang [171])

2.2.6. Modelo de cuatro variables de Parnas
Parnas en [135] indica que el modelo tradicional de un sistema hardware/software, llamado de dos-variables, se basa en dos premisas:
El sistema tiene entradas y salidas con el exterior.
Las salidas del sistema corresponden a funciones matemticas de las entradas.
En este modelo, las entradas del sistema hardware/software corresponden a las entradas
fsicas reales provenientes del exterior del sistema. Segn Parnas las funciones matemticas
que transforman las entradas en salidas, suelen ser bastante complejas y complicadas de
formular.
Los autores Parnas y Madey presentaron un modelo ms avanzado al que se conoce
como modelo de sistema de cuatro variables [136] [137]. Para ellos, en el exterior del
sistema, su entorno, hay variables fsicas, algunas monitorizadas, otras controladas, y otras,
36
ambas cosas. Estas variables corresponden a ciertos fenmenos o cosas percibidas en el entorno. El sistema est compuesto por cierto tipo de hardware y/o software y una serie de
dispositivos o componentes que establecen las relaciones de entrada y salida con el entorno
del sistema. Ciertos dispositivos fsicos incluidos en el sistema convierten los valores de las
variables monitorizadas en entradas al sistema. Del mismo modo, estos dispositivos transforman las salidas del sistema en acciones o valores que modifican las variables controladas
en el entorno del sistema.
El modelo de sistema hardware/software de cuatro variables propuesto por Parnas se
muestra grficamente en la figura 6, adaptada de Heitmeyer [71]. El modelo de cuatro
variables se basa en los siguientes conjuntos de variables y de relaciones:
1. Cuatro conjuntos de variables:
a) Monitorizadas (MON). Variables correspondientes a fenmenos o elementos
situados fuera del sistema (entorno) que son monitorizadas u observadas por el
sistema. Por ejemplo, temperatura del agua en un depsito, presin del aire en
una rueda, velocidad de un vehculo, nmero de plazas libres en un aparcamiento, nmero de accesos a una base de datos, etc. El conjunto de las variables
monitorizadas por un sistema viene determinado por el siguiente vector:
(m1 , m2 , ..., mn ).
b) Controladas (CON). Variables del entorno, que estn fuera del sistema, que son
controladas por el sistema, modificando su estado o valor. Por ejemplo: temperatura del agua de un depsito (al provocar su cambio mediante calentadores),
aceleracin de un vehculo, informacin visualizada en la pantalla de un ordenador, etc. El conjunto de las variables monitorizadas por un sistema viene
determinado por el siguiente vector: (c1 , c2 , ..., c p ).
c) Entrada (INPUT). Variables de entrada a travs de las cuales el sistema (software) percibe las variables monitorizadas. El sistema percibe estas variables de
37
Figura 6: Modelo de cuatro variables (adaptada de Heitmeyer [71])

entrada por medio de dispositivos de entrada. El conjunto de las variables de
entrada viene determinado por el siguiente vector: (i1 , i2 , ..., iq ).
d) Salida (OUTPUT). Variables de salida mediante las cuales el sistema modifica
el valor de las variables controladas. Los dispositivos de salida leen las salidas
del sistema y actan sobre las variables controladas. El conjunto de las variables
de salida viene determinado por el siguiente vector: (o1 , o2 , ..., or ).
Cada uno de los valores de estas variables pueden expresarse como una funcin del
tiempo. Para una variable v, su funcin del tiempo se denota como vt . Y se denota como mt al vector funcin del tiempo (mt1 , mt2 , ..., mtn ) en el que cada elemento
corresponde a una de las variables monitorizadas. Anlogamente ct denota el vector de variables controladas (ct1 , ct2 , ..., ctp ), it denota el vector de variables de entrada
(it1 , it2 , ..., itq ), y ot denota el vector de variables de salida (ot1 , ot2 , ..., otr ).
2. Cuatro relaciones entre las variables definidas:
a) Naturaleza (NAT). Define las restricciones naturales impuestas por las leyes
fsicas y el entorno del sistema para los valores de las cantidades del entorno.
Por ejemplo: la temperatura del agua en un depsito estar comprendida dentro
38
de un rango de valores de temperatura, la aceleracin mxima de 0 a 100 km/h

de un coche es de 10 segundos, el nmero de plazas libres en un aparcamiento
ser 0 <= numerodeplazaslibres <= numerototaldeplazas. NAT establece una
relacin entre las restricciones para las variables monitorizadas y controladas,
definida de la siguiente manera:
(mt , ct ) NAT si y solo si la naturaleza permite ese comportamiento, es
decir, si las restricciones del entorno permiten a las variables controladas
tomar los valores ct , cuando las variables monitorizadas toman los valores
mt .
b) Requisitos (REQ). Define los requisitos del sistema, especificando cmo las
variables controladas cambian en respuesta a los cambios producidos en las
variables monitorizadas:
(mt , ct ) NAT si y solo si el sistema debe permitir ese comportamiento, es
decir, si el sistema permitir a las variables controladas tomar los valores
ct , cuando las variables monitorizadas tomen los valores mt .
c) IN, define la relacin entre las variables monitorizadas (MON) y las variables de
entrada (INPUT). Esta relacin describe el comportamiento de los dispositivos
de entrada:
(mt , it ) IN si y solo si el dispositivo de entrada permite ese comportamiento, es decir, si it describe los valores de entrada que son posibles
cuando las variables monitorizadas toman los valores descritos por mt .
d) OUT, define la relacin entre las variables controladas (CON) y las variables de
salida (OUTPUT). La relacin OUT describe el comportamiento de los dispositivos de salida:
(ot , ct ) OUT si y solo si el dispositivo de salida permite ese comportamiento, es decir, si ct describe los valores de las variables controladas
39
Figura 7: Modelo de cuatro variables

que son posibles al tomar las variables de salida los valores ot cuando los
dispositivos de salida funciona correctamente.
3. Por ltimo, Parnas expresa una quinta relacin, llamada SOFT, que establece la
relacin entre el comportamiento de entrada/salida proporcionado por el software
que comprende el sistema:
(it , ot ) S OF si y solo si el software puede producir los valores descritos por
ot cuando los valores de entrada son los descritos por it .
La relacin NAT describe cmo se comporta el entorno (las variables monitorizadas
y controladas) en ausencia del sistema a construir, mientras que REQ describe como el
sistema restringe al entorno (las variables controladas). Parnas concluye que la relacin
SOFT constituir en s una funcin siempre y cuando el software sea determinista.
Borger [23] plantea que en este modelo de cuatro variables el problema de sincronizacin
consiste en sincronizar el programa de control con los dispositivos de entrada/salida de
40
forma que garantice para el sistema software, que necesita estados estables para leer sus
entradas y enviar sus salidas, un comportamiento reactivo correcto con respecto al entorno
fsico. El dispositivo de entrada transforma cantidades fsicas continuas, por ejemplo las
medidas tomadas por sensores, en valores discretos de entrada para el software mientras
que el dispositivo de salida transforma valores discretos de salida generados por el software en valores continuos para los actuadores que manipulan procesos fsicos. La figura
7 muestra el modelo de cuatro variables de Parnas y la relacin entre entradas y salidas
(variables monitorizadas y controladas del sistema).
Miller y Tribble [124] propusieron una extensin del modelo original de cuatro variables presentado por Parnas y Madey [136], que intenta clarificar cmo pueden ubicarse los
requisitos del sistema entre el hardware y el software.
En la lnea de Parnas, Sateesh presenta una aproximacin y un lenguaje para modelar
los requisitos de sistemas de tiempo real [146]. Indica que los sistemas de tiempo real se
caracterizan por la existencia de interfaces no triviales entre computadores y su entorno.
Un sistema de tiempo real evoluciona reaccionando a las peticiones que recibe desde el
entorno. Est compuesto por un conjunto de elementos computacionales (que son reactivos por s mismos) junto con varios dispositivos que son monitorizados y controlados.
Considera que un sistema puede ser modelado por medio de secuencias del tipo sensorcontrolador-actuador-operador. La figura 8 representa el modelo de sistema definido por
Sateesh, donde los cambios que ocurren en el entorno se monitorizan por medio de sensores. Estos sensores obtienen informacin de inters para el sistema, como temperatura,
velocidad, presin, etc. La informacin obtenida se procesa mediante controladores para
determinar las acciones a realizar. Y estas acciones se envan a los actuadores que revierten
en el entorno. El operador suele supervisar estas funciones del sistema, y tiene posibilidad
de variar el funcionamiento del sistema.
41
Figura 8: Modelo de sistema (adaptada de Sateesh [146])
2.3. Paradigmas en el modelado de la interaccin de un sistema

Los modelos representan un aspecto fundamental para el desarrollo de sistemas. El
modelo de interaccin entre un sistema y su entorno siempre se ha tenido como uno de
los factores ms importantes para conseguir implementaciones funcionalmente adecuadas
y confiables. Como se indica en [43] el modelado puede llegar a ser asequible en tanto en
cuanto el modelo de comportamiento no necesite detallar secuencias de operaciones en las
que operaciones posteriores en el tiempo dependan de acciones tomadas en operaciones
anteriores. Pero las operaciones en sistemas reales no siempre se pueden simplificar de
esta manera. Realmente una excesiva simplificacin puede conllevar ignorar caractersticas
esenciales y, como resultado, la funcionalidad y confiabilidad del sistema pueden quedar
por debajo del mnimo requerido. Por lo tanto las aproximaciones al modelo son necesarias
para poder abordar la complejidad existente.
42
Predecir la relacin entre estmulos, entradas al sistema, y respuestas, salidas del sistema, de un sistema requiere definir el comportamiento del sistema. En la seccin anterior
de este captulo se ha dejado patente que el comportamiento de los sistemas puede ser determinista o no determinista. En el primer caso, predecir el comportamiento del sistema en
funcin de sus entradas es factible; pero en el segundo caso no es posible definir, ni predecir
el comportamiento del sistema.
Los investigadores perciben el modelo de interaccin de un sistema desde diferentes
puntos de vista, cada uno con caractersticas especficas, pero complementarias.
2.3.1. Paradigma basado en estados
Las aproximaciones basadas en estados como mquinas de estados, diagramas de estados o autmatas I/O permiten representar las interacciones de un sistema con el exterior. En
este sentido, Campos plantea la interaccin entre sistema y operador en trminos de mquinas de estados [36], incluso en [37] describe una aplicacin basada en este planteamiento
orientada a verificar el comportamiento de la interfaz de usuario. Otros autores entienden
los sistemas complejos como una composicin de autmatas I/O que representan las entradas y salidas con el exterior [112] [97] [91] [39].
Estas aproximaciones basadas en estados se centran en identificar el vocabulario completo de eventos que pueden afectar al objeto, produzcan o no un cambio de estado, y construir una mquina de estados que describa las posibles secuencias de eventos que puedan
producirse en el objeto [105]. As pues, se puede modelar la interaccin del sistema con el
exterior representando los estados y eventos perceptibles desde el exterior.
Sin embargo, estas representaciones no reflejan con claridad el conjunto de operaciones
aceptadas por el sistema, sobre todo cuando el nmero de estados es elevado. Por otro
parte, la aplicacin de tcnicas de verificacin como la comprobacin del modelo (model
checking) conlleva una explosin combinatoria, que tambin limita su uso [19] [144].
43
2.3.2. Paradigma basado en escenarios

Las notaciones basadas en escenarios permiten describir las secuencias de interacciones
que se producen entre los diferentes elementos implicados en las operaciones de sistemas:
componentes software y hardware del sistema, aplicaciones externas y usuarios, tal como
plantea Uchitel [162]. Los diagramas de secuencias de mensajes MSC (Message Sequence
Charts), definidos por el ITU (International Telecommunications Union) [84], y sus homlogos en el lenguaje unificado de modelado UML (Unified Modelling Language) [133], los
diagramas de secuencia, representan las notaciones grficas ms extendidas para documentar escenarios. Estos escenarios que describen interacciones pueden obtenerse directamente
a partir de los casos de uso definidos en las primeras etapas de la fase de anlisis, simplificando an ms su especificacin. En este sentido, Daz et al. presentan una aproximacin
que define patrones para transformar modelos de casos de uso en modelos de interaccin
[46].
Las especificaciones basadas en escenarios se utilizan cada vez ms como parte de la
especificacin de requisitos debido a su simplicidad y representacin grfica intuitiva [163].
Uchitel y Kramer proporcionan unas bases para soportar varias aproximaciones de especificacin de escenarios mediante Message Sequence Charts (MSC)s en el anlisis y sntesis
del modelo de comportamiento de un sistema [163] [165]. Tambin en [164] plantean la
validacin de escenarios, compuestos por diagramas MSC y diagramas de secuencia de
Unified Modelling Language (UML), y de metas ("goals") relacionadas mediante animaciones grficas. Uno de los objetivos que persiguen Uchitel y Kramer con este planteamiento es la validacin de requisitos de los stakeholders a partir de escenarios que describen las
interacciones con el sistema.
Sin embargo, uno de los inconvenientes de los escenarios es que no permiten describir
las propiedades del sistema. Si bien, la estructura y propiedades de un sistema se pueden
44
especificar por ejemplo con diagramas de clases de UML, complementando as a los escenarios. Otro de los inconvenientes de los escenarios es que la especificacin del comportamiento se debe sintetizar generalmente desde un nmero alto de escenarios, y los
escenarios individuales deben cubrir todas las posibilidades; esto puede llevar a un gran
nmero de escenarios en aplicaciones complejas, lo que representa una gran dificultad para
sintetizarlos. Algunas aproximaciones como la de Whittle [174] plantean la generacin automtica de diagramas de estados desde los diagramas de secuencia, para generar cdigo a
partir de los diagramas de estados .
En otro orden de cosas, Letier et al. plantean la utilizacin de escenarios de entradasalida, como tcnica para el anlisis temprano de requisitos [108]. Estos escenarios de
entrada-salida se basan en la identificacin de eventos monitorizados y controlados en los
lenguajes de modelado de requisitos [137] [86]. Letier et al. indican que si bien los escenarios permiten reflejar la interaccin del sistema con el exterior, la distincin entre eventos
monitorizados y controlados no es explcita, siendo necesario interpretar la direccin de las
flechas en los diagramas [108].
En definitiva, los escenarios permiten reflejar la interaccin de un sistema con el exterior, pero no permiten reflejar adecuadamente las propiedades monitorizadas y controladas
del sistema involucradas en la interaccin, ni la clasificacin en eventos de monitorizacin y de control. La aproximacin al modelado de las operaciones de un sistema que se
presenta en este trabajo pretende avanzar en esta lnea, reflejando de forma explcita y concisa en el modelo del sistema estos eventos de entrada y salida, as como las propiedades
involucradas.
2.3.3. Paradigma basado en contratos
Las metodologas de diseo basadas en contrato consideran que las interacciones entre
entidades software se basan en ciertas reglas u obligaciones entre ellas a las que denominan
contratos [122]. En el nivel de mtodo o procedimiento, un contrato define las entradas
45
aceptadas y los valores de retorno o salidas. Adems, la definicin de pre-condiciones,

post-condiciones e invariantes en el contrato garantiza su cumplimiento.
La combinacin de UML y OCL permite modelar el comportamiento de un sistema
con los llamados modelos basados en contrato [117]. Este tipo de modelos tienen sus orgenes en las ideas de diseo por contrato presentadas por Bertrand Meyer [121]. Esta
aproximacin se clasifica como centrada en estructura (structure centric) porque el comportamiento del sistema se especifica adornando el modelo de clases (estructura) mediante pre y post condiciones en las operaciones de cada clase, y no se utiliza ningn modelo
de comportamiento especfico tal como diagramas de interaccin o de mquinas de estado.
Algunos trabajos como el de Queralt y Teniente amplan el concepto de contrato incluyendo dentro de las pre y post-condiciones verificaciones de restricciones de integridad del
modelo de clases [142].
Como indican Warner y Kleppe, las operaciones se pueden identificar como parte del
modelo de clases de UML y las pre y post-condiciones se especifican por medio del lenguaje de restricciones OCL [99] [173]. Esta forma de expresar el comportamiento mediante pre
y post condiciones, representa un contrato en el sentido de que si la pre-condicin se satisface, la implementacin debe asegurar que la post-condicin tambin se satisface [117].
Algunos autores han realizado trabajos en esta lnea, representando operaciones del sistema mediante contratos. Cabot y Gmez plantean derivar los contratos de operacin a partir de los diagramas de clases UML expresando las pre y post-condiciones mediante OCL
[34]. Para ellos una operacin del sistema consiste en un conjunto de modificaciones bsicas sobre el estado del sistema que son percibidas por el usuario del sistema de informacin
como un cambio sencillo en el dominio. Plantean inicialmente el concepto de operacin
como acciones de creacin, eliminacin y modificacin de objetos en las clases del diagrama de clases. Para las operaciones ms complejas plantean trabajos futuros que generen
(semi)automticamante las operaciones complejas a partir de diagramas adicionales como
casos de uso en lnea con los trabajos de Sendall [152]. Por tanto, si bien tratan el aspecto
46
de operaciones del sistema lo hacen enfocado a las operaciones sobre clases UML, y no del
sistema en s desde el punto de vista del operador del sistema.
Para Kleppe et al. la definicin de contratos, especialmente con clases UML y expresiones OCL, presenta ciertas limitaciones para especificar por completo el comportamiento de un sistema [99]. Indican que por un lado esta tcnica origina cierto grado de fragmentacin de la descripcin del comportamiento hacindolo ms difcil de entender y mantener que con una descripcin equivalente del comportamiento mediante diagramas. Y que
por otro lado, se refieren a la limitacin para expresar diferentes niveles de abstraccin con
el que se definen los contratos expresados por medio de pre y post-condiciones.
2.3.4. Paradigma basado en servicios
La ingeniera de servicios est creando un nuevo camino de aproximacin entre la ingeniera del software y de sistemas tal y como se presenta en [101]. La computacin orientada a servicios [134] y el desarrollo basado en componentes Component-Based Development (CBD) permiten plantear la interaccin de un sistema en trminos de servicios. Un
modelo orientado a servicios se basa en la idea de representar un sistema como un conjunto de componentes software distribuidos, de manera que las entradas y salidas del sistema
pueden establecerse como servicios provistos y requeridos respectivamente por los componentes que integran el sistema. El modelo de operaciones del sistema propuesto en este
trabajo est en lnea con el planteamiento de servicios en los que se expresan las entradas
y salidas de los diferentes componentes del sistema a modo de operaciones.
La computacin orientada a servicios se est aplicando a una gran variedad de dominios
ya que las nuevas tecnologas favorecen el uso de este nuevo enfoque de desarrollo. Dos
claros ejemplos de aplicacin de la computacin orientada a servicios son los servicios
web [161] [74] y las arquitecturas software orientadas a servicios, Service-Oriented Architectures (SOA) [115] [57] [100]. Los servicios web permiten expresar la interaccin entre
47
componentes por medio de interfaces descritos en Web Service Description Language (WSDL) (www.w3.org/TR/wsdl) a travs de mensajes SOAP (www.w3.org/TR/soap). En SOA
la interaccin del sistema se establece por medio de puertos, que representan servicios,
entre los diferentes componentes que intervienen en la operacin del sistema.
En modelos orientados a objetos donde los componentes se representan como objetos,
para un componente concreto los servicios ofrecidos corresponden a mtodos del objeto,
pero los servicios requeridos por el componente no se pueden representar directamente en
el objeto [103], siendo necesaria la utilizacin de interfaces para identificarlos. En UML
la utilizacin de interfaces asociados a las clases de objetos permite definir tanto los servicios provistos por los objetos (interfaces implementadas) como los requeridos (interfaces
usadas). En modelos de componentes actuales en los que los componentes corresponden a
unidades arquitectnicas, los servicios se representan como puertos (ports). Puertos de
diferentes componentes se pueden unir mediante conectores, representando los servicios
provistos y tambin los requeridos de cada componente. En algunos modelos como UML
y CCM (Corba Component Model) [131] se hace una distincin entre puertos para indicar
servicios provistos y puertos para indicar servicios requeridos [103].
Si bien, estas representaciones de los servicios mediante interfaces y puertos en componentes software permiten expresar el modelo de interaccin del sistema, sin embargo al
definir los servicios se suele incluir no solo los aspectos de interaccin con el exterior, sino
tambin los aspectos de interaccin interna entre los diferentes elementos que componen el
sistema. Uno de los objetivos de este trabajo es precisamente que el modelo de operaciones
de un sistema proporcione ms semntica en la definicin de las interfaces y aporte mayor
claridad al conjunto de stakeholders implicados en la construccin y operacin de sistemas.
2.3.5. Paradigma basado en Interaccin Hombre-Computador (HCI)
Otro de los paradigmas en el modelado de la interaccin de un sistema se basa en el
diseo de la interaccin entre hombre y computador. La interaccin hombre-computador
48
(HCI) ha sido definida por el grupo SIGCHI (Special Interest Group on Computer-Human
Interaction) de ACM (Association for Computing Machinery) como una disciplina interesada en el diseo, evaluacin e implementacin de sistemas informticos interactivos que
utilizan las personas, as como en el estudio de los fenmenos que los rodean [73]. Esta
disciplina combina teora y prctica de un gran nmero de campos incluyendo entre otros
ingeniera industrial, ingeniera del software, psicologa cognitiva y del comportamiento,
antropologa sociologa y ergonoma [153] [172] [66]. Como indica Sutcliffe una misin
fundamental de HCI es la de acercar la psicologa y otras ciencias tales como la sociologa
al diseo de la interaccin con los sistemas [157]. Algunos trabajos se han orientado a
definir modelos de diseo de interaccin que permitan colaborar tanto a diseadores como
a ingenieros HCI [180]. Obrenovic y Starcevic definen una extensin UML para modelar
interacciones hombre-computador multimodales [127]. Esta extensin, compuesta por un
metamodelo y un perfil UML, tiene una orientacin similar a la propuesta en este trabajo,
si bien, se centra en modelar la interaccin en el lado de la interfaz de usuario y no del
sistema.
En definitiva, HCI describe la interaccin entre hombre y computador desde la perspectiva de la utilizacin de las interfaces entre sistema y usuario que posibilitan dicha interaccin. En realidad es una aproximacin complementaria a la nuestra, ya que nuestro
trabajo se centra en describir la interaccin del sistema con el exterior desde el punto de
vista del sistema; y HCI se encarga de describir la interaccin de la persona u operador con
el sistema. Existe un punto de interseccin claro entre ambas aproximaciones, relativa al
frontend de operaciones entre operador y sistema que se plantea en este trabajo, y que
permitir abrir nuevas lneas de actuacin en trabajos futuros.
2.3.6. Paradigma basado en operaciones
La especificacin de las operaciones del sistema es la ltima de las aproximaciones
incluidas como paradigma del modelado de la interaccin de un sistema, y la lnea a seguir
49
en esta tesis.
En el contexto de este trabajo se entiende por operaciones de un sistema al conjunto de
interacciones que se producen entre un operador y el sistema en trminos de entradas y salidas del sistema. Este concepto de operaciones se encuentra en lnea con el planteamiento
de requisito de operacin que figura en el estndar IEEE 610-1990 [75], en el que se entiende que dicho requisito especifica una funcin que el sistema o componentes del sistema
han de ofrecer al exterior.
Algunos autores estudian las operaciones de sistemas desde el punto de vista algebraico,
definiendo operaciones que permiten operar con sistemas de manera abstracta. Wang, por
ejemplo, define un algebra de sistemas que incluye operaciones como conjuncin, diferencia, composicin y descomposicin de sistemas. Tambin Kaynar y Lynch [97] definen
operaciones para autmatas I/O basadas en tiempo, orientadas a la construccin de sistemas
complejos, tal como composicin de autmatas. Este tipo de estudios quedan alejados de
nuestro inters ya que el concepto de operaciones sobre el que se fundamenta este trabajo
es el de la relacin de entradas y salidas entre un operador y el sistema, y no en operaciones
algebraicas sobre sistemas o sobre su esquema.
Otros autores tratan el aspecto de operaciones del sistema en diagramas de clases, pero
lo hacen enfocado a las operaciones sobre las clases UML, tratando operaciones bsicas
sobre el esquema como insercin, borrado y modificacin de objetos [34] [142] [152].
Estos trabajos tambin se alejan de nuestro inters ya que no enfocan las operaciones del
sistema desde el punto de vista del operador del sistema.
Vaishnavi et al. definen una aproximacin que permite el modelado, diseo y desarrollo
de sistemas de soporte a operaciones, sistemas que proporcionan soporte interactivo para
entornos de operaciones complejos [167]. Para ello definen unos tipos de objetos basados en la combinacin de modelos de diseo orientados a objetos y de representacin del
conocimiento, modelos de datos y en general modelos conceptuales. Si bien, manejan el
concepto de operacin, no lo aplican en la misma lnea que en este trabajo, ya que lo hacen
50
para sistemas que facilitan la operacin de entornos complejos, desde un punto de vista
de ingeniera del conocimiento e inteligencia artificial, para determinar dinmicamente el
comportamiento de las operaciones.
El enfoque seguido para especificar las operaciones en sistemas de espacio es cercano al
nuestro en el sentido de que en estos sistemas se hace necesario disponer de un modelo de
operaciones en etapas tempranas del desarrollo [160], dado que una vez en rbita un satlite
no es posible realizar ajustes posteriores. La interaccin se produce entre la estacin de
tierra que enva telecomandos y la nave espacial que enva telemetras a la estacin terrestre.
Esta interaccin se puede modelar en trminos de orientacin a objetos tal y como justifican
Garbajosa et al. en [62]. Por otra parte, resultan interesantes los planteamientos de algunos
autores que plantean que el hardware y software utilizado en sistemas de espacio para
la fase de comprobacin y la de operacin pueden integrarse en el desarrollo del sistema,
compartiendo herramientas comunes [102] [56] [109]. En este sentido, este trabajo presenta
una aproximacin de frontend de operaciones del sistema que sea aplicable tanto en la fase
de validacin como en la de operacin del sistema.
La especificacin del modelo de operaciones del sistema en el que se centra este trabajo,
no busca modelar el comportamiento del sistema, pero s especificar un nivel de interaccin,
expresado mediante una especie de API (Application Program Interface), que permita a los
diferentes stakeholders involucrados operar el sistema, es decir, interactuar con el sistema.
Existe obviamente una relacin entre esta interfaz y el comportamiento. El comportamiento
es el resultado de operar el sistema utilizando esta interfaz. En cierta forma esto est en lnea
con la aproximacin basada en contrato como se presenta en [117]. La aproximacin basada
en operaciones es ligeramente diferente a las explicadas anteriormente, aunque pueden ser
utilizadas en cooperacin.
51
2.4. Concepto de operacin de sistemas en estndares de ingeniera de sistemas y software

En la seccin anterior se ha dejado patente que la aproximacin que se seguir en este
trabajo para abordar el modelado de la interaccin de un sistema ser el modelado de las
operaciones del sistema. Esta seccin analizar el conjunto de estndares definidos en el
rea de la ingeniera del software que tratan de manera especfica las operaciones de un
sistema.
Las operaciones de un sistema suelen ofrecerse a las aplicaciones externas al sistema
por medio de interfaces. La utilizacin de interfaces de programa de aplicacin, Application
Program Interface (API) se ha hecho popular en ingeniera del software para aspectos tales
como la especificacin de interfaces de componentes, sin embargo no se ha utilizado ampliamente en sistemas en general; en algunos dominios de aplicacin, tales como sistemas
de espacio, la descripcin de operaciones del sistema se contempla como una actividad a
realizar en etapas muy tempranas en el desarrollo del sistema, pero que en la prctica no
siempre llega a cumplirse.
Parece conveniente por tanto, que la especificacin de requisitos de operacin del sistema ocupe un lugar destacado dentro del ciclo de vida del software, de manera que permita
conocer al conjunto de los desarrolladores desde un principio las necesidades y expectativas de los usuarios que utilizarn el sistema. De ah que ciertos estndares incluyan el
concepto de operacin, y pautas para expresar un documento de operaciones del sistema.
La operacin de un sistema se define como un proceso en s mismo dentro del ciclo
de vida en la ingeniera de sistemas y software. El estndar ISO/IEC 15288, Systems engineering - System life cycle processes [83], lo llama proceso de operacin (Operation
Process) dentro de los procesos tcnicos (Technical Processes) del ciclo de vida, y lo define como la utilizacin del sistema ya creado y sus servicios conforme a la especificacin
de requisitos de stakeholders. La norma ISO/IEC 12207, Standard for Information Technology - Software Lifecycle Processes [82], lo llama proceso de operacin del software
52
(Software Operation Process), y es una especializacin del proceso de la norma 15288. El

INCOSE System Engineering Handbook [79], define la etapa de utilizacin (Utilization
Stage) como en la que se opera con el producto, para proporcionar servicios dentro de los
entornos requeridos y asegurar una efectividad operacional continuada.
Estos estndares y guas definen el concepto de operador como una entidad individual u
organizacin que realiza la operacin del sistema; y el concepto de operacin como el proceso a realizar una vez construido el sistema. Los requisitos de operacin han de definirse
en las primeras etapas del ciclo de vida mediante los procesos de definicin de requisitos
de stakeholders y anlisis de requisitos.
Dada la importancia de los requisitos de operacin del sistema se han publicado algunos
estndares relacionados con la operacin de sistemas, como IEEE 1362 [76], donde se
define el concepto de documento de operaciones (ConOps) y ESA ECSS-E-70-32A [55],
que identifica los requisitos que debe cumplir cualquier lenguaje utilizado para la definicin
de procedimientos de prueba y de operacin en sistemas de espacio, y define el lenguaje de
operaciones PLUTO.
En esta seccin se presentan algunas de las caractersticas definidas en estndares que
incluyen el concepto de operacin de sistemas y su documentacin desde la perspectiva
de la ingeniera del software, y de lenguajes procedimentales para expresar la operacin y
pruebas de sistemas.
2.4.1. Visin de documento de operaciones
El concepto de operaciones (concept of operations) debe estar disponible en un documento y ser relevante a todos los stakeholders con independencia del papel que jueguen en
el sistema [79] [35] [126]. Segn se indica en [126] [61] [159] los estndares que tratan
especficamente el concepto de operaciones de un sistema, son los siguientes:
1. IEEE 1362 Guide for Concept of Operations Document
Dada la importancia de la especificacin de requisitos de operacin del sistema, IEEE
53
defini el formato y contenidos de un concepto de documento de operaciones, llamado ConOps (Concept of Operations), para la definicin de un sistema en la gua
IEEE 1362 Guide for Concept of Operations Document para tecnologa de la informacin [76]. Esta gua proporciona recomendaciones para producir un documento
de operaciones del sistema. Un documento ConOps describe cmo se deben especificar las operaciones, pero no describe las operaciones en s. El documento ConOps
es un documento que describe las caractersticas del sistema desde el punto de vista
de operacin de los usuarios y permite el entendimiento entre el conjunto de los
stakeholders.
Este tipo de documento debe incluir una visin general del sistema y especificar el
conjunto de stakeholders involucrados. De especial inters, es la identificacin de
los usuarios del sistema que interactuarn con el sistema: usuarios operacionales, de
entrada de datos, operadores del sistema, personal de soporte operacional, de mantenimiento del software y formadores. ConOps incluye escenarios operacionales, que
juegan un papel importante para conocer cmo los usuarios pueden operar e interactuar con el sistema. En este sentido el INCOSE System Engineering Handbook
[79], que describe las actividades de los procesos clave a realizar por los ingenieros
de sistemas, propone documentar el concepto de operacin (ConOps) en el proceso
de definicin de requisitos. Tambin la gua Systems Engineering Guidebook for
ITS [35] publicada por el California Departament 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 Transportation Systems). En esta gua el concepto
de operaciones representa la definicin inicial del sistema
2. ANSI/AIAA G-043-1992 Guide for the Preparation of Operational Concept Documents
54
ANSI public en 1992 la gua ANSI/AIAA para la preparacin de documentos operacionales [12] que describe un proceso debidamente probado para el desarrollo del
concepto operacional. Recomienda cmo recopilar toda la informacin obtenida durante el desarrollo del concepto operacional en uno o ms Operational Concept Documents (OCDs) para ser utilizados durante la definicin, desarrollo, validacin, implementacin, operacin y soporte del sistema.
3. MIL-STD-498
El estndar militar de Estados Unidos MIL-STD-498 Software Development and
Documentation aprobado en diciembre de 1994 contiene el item DI-IPSC-81430
[123] dedicado a describir una serie de instrucciones para preparar el contenido y
formato de documentos de operaciones del sistema, a los que llama OCD (Operational Concept Document). El objetivo de un OCD es servir de consenso a los diferentes stakeholders implicados en el sistema propuesto, describiendo en trminos de
las necesidades del usuario, las relaciones con otros sistemas o procedimientos existentes, y las formas en las que ser usado. En 1998 el DoD (Departament of Defense)
de Estados Unidos adopt el IEEE/EIA 12207 Software Life Cycle Processes en
lugar del estndar MIL-STD-498.
Un ejemplo de documento describiendo el concepto de operaciones para un sistema
concreto del mbito de la avinica se encuentra en [44]. Este documento se realiz conforme a la gua NASAs AvSSP Products CONOPS Guide, que fue desarrollada por la
NASA teniendo en cuenta una variedad de documentos de concepto de operacin publicados por organizaciones estandarizadoras y entidades comerciales. En concreto la gua
sigui principalmente el estndar IEEE 1362 Guide for Concept of Operations Document
[76] con algunas modificaciones para asegurar la aplicabilidad en el desarrollo de productos de aviacin en contraste con el desarrollo de productos software; y en menor medida el
estndar AIAA Guide for the Preparation of Operational Concept Documents [12]. Otro
55
ejemplo de utilizacin del concepto de operaciones aplicado a la gestin de sistemas de

transporte se encuentra en [154].
Revisando los tres estndares enumerados anteriormente se observa que la documentacin relativa a operaciones comprende bien el Concepto de Operaciones (ConOps) tal
como lo hace el estndar 1362 de IEEE, o bien el Concepto Operacional (OCD) como hace
el resto. Tal y como plantea Gabb ambos trminos suelen tomarse como intercambiables
[61]. El mismo autor, describe cul debe ser el propsito y contenido de un Operational
Concept Document (OCD) basndose en los tres estndares que han sido descritos anteriormente. Gabb plantea que el objetivo de un OCD es completar y no reemplazar a los
documentos tradicionales de requisitos, ya que un OCD es menos formal y ms centrado
en las operaciones que en el caso de los documentos de requisitos, por lo que ha de ser
ledo y comprendido por una mayor audiencia.
En [156], Strengers plantea que la mejor forma de comenzar un proyecto es analizando
las necesidades de los clientes y usuarios, y documentando esas necesidades por medio
de OCDs. Tambin presenta una gua para analizar los conceptos operacionales y preparar
los OCDs, para los que recomienda cualquiera de los tres estndares que se han descrito
anteriormente en este apartado.
Los tres estndares de ingeniera de sistemas y software analizados resaltan la importancia de las operaciones del sistema, incluso proporcionan guas y plantillas para definir
un documento de operaciones en el contexto de ingeniera y especificacin de requisitos.
Sin embargo se centran en el contenido y forma que debe tener el documento para especificar los aspectos de las operaciones del sistema de una forma comprensible a los usuarios
del sistema, y no proporcionan asistencia para expresar el concepto de operaciones [159].
An as, en el contexto de este trabajo se considera de gran importancia la existencia
de un documento ConOps o de un documento similar OCD, ya que puede utilizarse para
especificar el conjunto de operaciones que posibiliten la interaccin con el sistema. De
manera que este tipo de documentos puede utilizarse, junto con documentos de requisitos
56
del sistema, como entrada para abordar el modelado de las operaciones del sistema.
2.4.2. Lenguajes procedurales de operacin y pruebas
Otro de los aspectos relacionados con las operaciones de un sistema en el mbito de la
ingeniera del software y de sistemas es la relativa a la existencia de lenguajes procedurales
que permitan llevar a cabo las operaciones y pruebas del sistema. En este sentido, dos de los
lenguajes ms representativos, y utilizados como estndares, son PLUTO [55] desarrollado
por European Cooperation for Space Standardization (ECSS) y TTCN-3 [53] desarrollado
por el European Telecommunications Standards Institute (ETSI).
Mullet et al. sealan la conveniencia de definir un lenguaje de operaciones que simplifique las interacciones de los ingenieros de operaciones con el sistema, y plantean una sintaxis comn para interactuar en el entorno de los satlites meteorolgicos europeos [125].
Al analizar los lenguajes de operaciones del sistema tambin se han de incluir aspectos de validacin del sistema, ya que la validacin de sistemas est estrechamente relacionada con la operacin de los mismos. Las pruebas de validacin, especialmente las de
aceptacin, suelen comprender la operacin del sistema en escenarios sobre el sistema real
o sobre simulaciones de ste. En sistemas de espacio por ejemplo, como en el desarrollo de
Galileo realizado por la European Space Agency (ESA), la simulacin y la experimentacin
juegan un papel crtico [181].
A continuacin se presenta por una parte el estndar PLUTO como lenguaje de procedimiento de operaciones y pruebas, y por otra parte el estndar TTCN-3 como lenguaje
orientado al diseo y especificacin de pruebas y de sistemas de pruebas.
2.4.2.1.
PLUTO como lenguaje de operaciones
En 2006 se public el estndar ECSS-E-70-32A: Space engineering - Test and operations procedure language [55], que identifica los requisitos que debe cumplir cualquier
57
lenguaje utilizado para la definicin de procedimientos de prueba y de operacin en sistemas de espacio. Este estndar tambin define un lenguaje de referencia llamado PLUTO (Procedure Language for Users in Test and Operations) que satisface completamente
estos requisitos. ECSS es un esfuerzo cooperativo de la Agencia Espacial Europea, ESA, de
agencias de espacio nacionales y de asociaciones de la industria europea, con el propsito
de desarrollar y mantener estndares comunes.
El procedimiento es el principal mecanismo empleado por los usuarios finales para
controlar un sistema de espacio primeramente durante la validacin funcional anterior al
lanzamiento y posteriormente, durante la operacin cuando ste ya est en rbita. En el
lenguaje Procedure Language for Users in Test and Operations (PLUTO), la estructura de
un procedimiento comprende las siguientes partes:
Declaracin. Es opcional, y declara los eventos locales que pueden ser lanzados desde
dentro del procedimiento.
Precondiciones. Es opcional, y asegura que el procedimiento se ejecuta si y solo si,
se cumplen las precondiciones.
Cuerpo principal. Es obligatorio y define las metas del procedimiento, y puede componerse a su vez de submetas mediante actividades y etapas. Una actividad es una
funcin que controla y monitoriza el sistema de espacio. La estructura de una etapa
es idntica a la de un procedimiento, salvo que define una submeta y est contenida
en un procedimiento.
Controlador de excepciones (watchdog). Es opcional, y gestiona las contingencias o
excepciones que se produzcan durante la ejecucin del procedimiento.
Confirmacin. Es opcional, y evala si los objetivos del procedimientos se han alcanzado o no.
58
La estructura de los procedimientos definidos en este lenguaje puede ser de utilidad

para orientar la definicin de un lenguaje de operaciones de un sistema que comprenda
tanto la validacin del sistema como las operaciones en s mismas.
2.4.2.2.
TTCN-3 como lenguaje orientado a pruebas
La complejidad creciente de los sistemas actuales intensivos en software requiere de

tcnicas que permitan aumentar la efectividad del proceso de pruebas. La validacin basada en pruebas de aceptacin se centra en la comprobacin de los interfaces de operaciones
y la funcionalidad. Las pruebas manuales y automatizadas pueden complementarse produciendo una mejora global en el proceso de validacin [107]. Existen diferentes lneas
de investigacin relacionadas con pruebas de aceptacin, una de ellas est orientada al
desarrollo de lenguajes aplicable a mltiples dominios de aplicacin, como es el caso de
TTCN-3 (Testing and Test Control Notation) [53] para telecomunicaciones o PLUTO [55]
para misiones espaciales. Ambos lenguajes se encuentran ms cerca de los lenguajes de
programacin tradicionales alejndose del usuario final.
Uno de los lenguajes ms extendidos para realizar pruebas y sistemas de pruebas es
TTCN-3. El lenguaje Testing and Test Control Notation (TTCN-3) se ha consensuado internacionalmente para definir escenarios de pruebas de sistemas y sus implementaciones. El
Instituto Europeo para Normalizacin de las Telecomunicaciones, ETSI (European Telecommunications Standards Institute) estandariz el lenguaje TTCN-3 (Testing and Test Control
Notation, tercera versin) [53] con objeto de normalizar la infraestructura de pruebas en el
campo de las telecomunicaciones. Este lenguaje est en proceso de aceptacin por la industria del sector para validar un gran nmero de sistemas. TTCN-3 es un lenguaje de pruebas
que permite especificar, ejecutar y automatizar casos de prueba, para pruebas de caja negra de sistemas distribuidos. Es modular y tiene una apariencia similar a la de un lenguaje
de programacin tradicional. En realidad TTCN-3 no es un estndar sino un conjunto de
59
estndares [53]: Core Lenguaje, Tabular Presentation Format, Graphical Presentation Format, Operacional Semantics, TTCN3 Runtime Interface (TRI) y TTCN-3 Control Interface
(TCI).
TTCN-3 mantiene una correspondencia casi completa con UML 2 Testing Profile (U2TP)
definido por Object Management Group (OMG) [130]. El perfil U2TP extiende UML 2.0
proporcionando conceptos orientados a sistematizar el desarrollo de especificaciones y modelos de test para pruebas de caja negra [16]. En particular, el perfil introduce conceptos que
cubren: arquitectura de test, comportamiento de test, datos de test y tiempo. Junto con estos
conceptos define un lenguaje de modelado para visualizar, especificar, analizar, construir y
documentar los artefactos de sistemas de test.
Tanto U2TP como TTCN-3 se utilizan para especificar sistemas de test, sin embargo U2TP se aplica en un nivel de abstraccin ms alto que TTCN-3. Los metamodelos
de U2TP y de TTCN-3 se definen como modelos Meta-Object Facility (MOF) [128] de
OMG, lo que facilita la transformacin de modelos U2TP a modelos TTCN-3. Todas las
especificaciones U2TP, con pequeas excepciones, pueden ser representadas y ejecutadas
en plataformas de test TTCN-3 [16]. De esta forma, pueden generarse pruebas automticamente desde modelos U2TP. Sin embargo, esta generacin es semi-automtica porque las
especificaciones U2TP pueden llegar a ser demasiado abstractas [42].
Prcticamente todas las especificaciones de este perfil U2TP, con pequeas excepciones, pueden ser representadas por mdulos TTCN-3 y ejecutados en plataformas de
pruebas definidas a partir de TTCN-3 [178]. Esta correspondencia permite avanzar en la
generacin automtica de soluciones TTCN-3 para pruebas a partir de especificaciones
UML.
El lenguaje TTCN-3 tiene cierta relacin con el trabajo desarrollado en esta tesis, ya
que permite expresar operaciones a realizar sobre el sistema al definir el sistema de pruebas
[7] [8].
60
2.5.
Desarrollo de sistemas dirigido por modelos
En este apartado se analiza el enfoque de ingeniera dirigida por modelos (MDE), ya

que el modelo de operaciones del sistema que se plantea en esta tesis puede utilizarse en el
desarrollo de sistemas dirigidos por modelos.
Los enfoques asociados al desarrollo software estn avanzado en la lnea de aplicacin
de modelos y transformaciones de stos, dando lugar al surgimiento del enfoque de ingeniera dirigida por modelo, Model Driven Engineering (MDE) [148]. Han ido apareciendo
diferentes enfoques enmarcados dentro de la ingeniera dirigida por modelo como Model Driven Development (MDD) [14], Model Driven Architecture (MDA) [129] [33] [118]
[117], Model Integrated Computing (MIC) [158] [155], Model Driven Testing (MDT) [140]
[41], etc. La caracterstica comn a todas ellas es que constituyen un enfoque basado en
el desarrollo software dirigido por modelos. La utilizacin de modelos y la aplicacin de
transformaciones entre modelos [151] [149] [58] [118] permiten el desarrollo del software,
reduciendo la dependencia de las plataformas y lenguajes finales.
El enfoque MDE combina lenguajes de modelado de dominio especfico, DomainSpecific Modelling Language (DSML), y generadores y motores de transformacin de
modelos [148]. Los primeros se describen por medio de metamodelos que definen las
relaciones entre los conceptos de un dominio y especifican con exactitud la semntica y
restricciones asociadas con esos conceptos del dominio. As, las herramientas MDE imponen restricciones de dominio especfico, utilizando lenguajes de modelado de dominio
especfico, y realizan model checking permitiendo detectar y prevenir tempranamente
muchos errores en el ciclo de vida.
Los lenguajes de modelado y los metamodelos centrados en la descripcin de las operaciones del sistema para dominios especficos, como los que se presentan en este trabajo,
aportan a MDE el punto de vista de las operaciones del sistema en las etapas tempranas del
desarrollo mediante modelos de dominio especficos independientes de plataforma.
Por ejemplo, el modelo de operaciones del sistema es vlido para el enfoque de MDA
61
propuesto por OMG. Este enfoque parte de un nico modelo inicial para un proyecto, a
partir del cual, y mediante procesos automatizados en su mayor parte, es posible obtener
cdigo especfico para cada plataforma. Por lo que, desde el punto de vista de MDA las
operaciones del sistema se podran identificar y modelar en el modelo independiente de la
plataforma, Platform-Independent Model (PIM), como parte del modelo de clases de UML.
Las ventajas derivadas de la utilizacin del desarrollo de sistemas dirigido por modelos
han sido expuestas por muchos autores. Schmidt indica que el enfoque MDE proporciona
un marco adecuado para tratar la complejidad creciente de los sistemas y plataformas actuales, permitiendo expresar conceptos de dominio de manera eficiente, y solventando as
las carencias de los lenguajes de tercera generacin [148]. Mellor por su parte plantea que
la aplicacin correcta del desarrollo dirigido por modelos consigue una mejora sustancial
en la productividad y calidad del software [120]. Tambin Selic indica que la ingeniera
del software puede beneficiarse de la utilizacin de modelos y tcnicas de modelado en el
desarrollo de sistemas complejos [150].
Los proponentes del desarrollo dirigido por modelos ven el desarrollo software como
una serie de etapas de modelado, donde cada etapa refina el modelo de la etapa anterior
[99]. Aunque eso s, la transicin desde el anlisis, al diseo de alto nivel, diseo de bajo
nivel, y despus al cdigo tiene que ser soportada por herramientas que faciliten y automaticen gran parte del trabajo. El modelo de operaciones del sistema propuesto en este
trabajo puede utilizarse como conductor del desarrollo de un sistema, especialmente en las
primeras etapas de desarrollo, convirtindose en candidato para ser aplicado en el desarrollo dirigido por modelo. El modelo de operaciones del sistema tambin puede utilizarse
para identificar puntos de vista e intereses (concerns). La identificacin de intereses en modelos de ingeniera de requisitos orientados a aspectos, permite la separacin de intereses
en etapas tempranas del desarrollo, mejorando el proceso de desarrollo globalmente [143].
Esta separacin de aspectos tambin puede tenerse en cuenta en las fases de diseo por
medio de metamodelos y extensiones UML [38] [179].
62
El modelo de operaciones propuesto incorpora un metamodelo y un perfil UML que

facilita la transformacin entre modelos y la integracin con otras herramientas, dado que
UML es el estndar de facto en el modelado de sistemas software. Resulta habitual utilizar el lenguaje de modelado UML en el desarrollo dirigido por modelo. En este sentido,
Arisholm plantea, en base a resultados experimentales, que la utilizacin de UML en el
desarrollo dirigido por modelos, permite ahorrar tiempos y mejorar la efectividad de los
cambios en el mantenimiento de las aplicaciones [13]. Como inconveniente apunta que el
equipo encargado del mantenimiento debe tener unos slidos conocimientos en UML, y
que las herramientas actuales que soportan UML deben mejorar para permitir cambios en
los modelos y comprobacin de la consistencia de stos.
Sin embargo, en ingeniera de sistemas no ha llegado a popularizarse la utilizacin de
UML, y con el objetivo de acercar el modelado en ingeniera del software al de ingeniera
de sistemas OMG defini el lenguaje SysML (System Modelling Language) [132]. Este
lenguaje reutiliza un subconjunto de UML 2.0 y aporta extensiones para el modelado de
sistemas, mediante estereotipos, extensiones de diagramas y libreras del modelo. Por tanto,
el metamodelo y perfil definidos para representar las operaciones de un sistema son vlidos
tambin para SysML.
Uno de los principios de diseo fundamentales de System Modelling Language (SysML)
es la interoperabilidad. Por un lado, hereda la capacidad de intercambio XMI desde UML, y
por otro lado, para soportar la interoperabilidad entre diferentes herramientas de ingeniera
utiliza el estndar de intercambio de datos AP233 - Systems Engineering Application Protocol [89] [90] que forma parte de ISO 10303 STEP [80] [116].
La integracin de modelos y de herramientas constituye otra lnea en la ingeniera dirigida por modelos. En [49] Denno et al., presentan una integracin basada en modelos,
a partir de los modelos ya creados con anterioridad. Vienen a decir que la integracin
tradicional no suele utilizar los modelos que se han ido creando para desarrollar cada sistema, que en su momento supusieron un gran coste, y que poseen una valiosa informacin.
63
Plantean que estos modelos pueden ser actualizados y reutilizados para el mantenimiento
y para realizar una integracin de proyectos ms sencilla, permitiendo automatizacin de
tareas que de otra manera habra que realizar manualmente.
Algunos trabajos tratan la integracin de herramientas mediante la transformacin de
los modelos que se utilizan en el desarrollo del sistema [95] [94] [93] [96]. Ledeczi et al.
plantean que cada una de las herramientas participantes en la integracin disponga de un
modelo del sistema o un aspecto del mismo que permita la participacin y colaboracin de
cada una de ellas en el desarrollo del sistema final [104]. En este sentido, la existencia de
un perfil UML para el modelado de las operaciones del sistema facilitar la integracin del
modelo de operaciones con otros modelos y entre herramientas.
La operacin y la validacin de un sistema estn ntimamente relacionadas en el sentido
de que ambas se fundamentan en el modelo de interaccin del sistema. Y en el caso de
pruebas de aceptacin del sistema se hace necesario el diseo e implementacin previos
del modelo de operaciones del sistema.
En este sentido otro enfoque asociado a MDE, es el relativo a la validacin basada en
modelos, Model-based testing (MTB), que se centra en la utilizacin de modelos de comportamiento para generar automticamente casos de prueba con las secuencias de entradas
y las de salidas esperadas [166] [141] [67]. Si los casos de prueba se generan manualmente,
existe el riesgo de olvidar un caso de prueba importante. La generacin automtica de casos
de prueba basada en modelo, permite reducir este riesgo. Pero para ello se debe disponer
de herramientas que generen de forma automtica casos de prueba a partir del modelo del
sistema a validar System Under Test (SUT) [70].
Cunning y Rozenblit presentan en [40] una aproximacin para la generacin automtica
de casos de prueba partiendo de los requisitos del sistema. Tambin Hahn et al. plantean la
utilizacin de pruebas basadas en modelo, y lo aplican a sistemas reactivos en el mbito del
sector automovilstico [67]. Mantienen que los modelos de comportamiento de un sistema
en desarrollo se pueden ir construyendo incrementalmente, como prototipos, de manera
64
que el modelo resultante sirva como especificacin y al tiempo como base para generar
automticamente los casos de prueba. Este planteamiento est parcialmente en lnea con la
base de nuestro trabajo, dado que la generacin automtica de pruebas de aceptacin del
sistema puede apoyarse en el modelo de operaciones del sistema.
2.6.
Resumen y conclusiones del captulo
Este trabajo se centra en sistemas software o sistemas que incorporen algn tipo de
software. Y en concreto, se consideran nicamente sistemas abiertos, ya que desde el punto de vista de interaccin un sistema cerrado no se relaciona con el exterior [171]. As, se
entiende que el sistema se relaciona con su propio entorno y adems, permite interacciones
desde el exterior del sistema. Por otra parte, el sistema se observar como una caja negra,
siendo visibles nicamente el conjunto de acciones de entrada que admita y el conjunto de
salidas que genere. Esta visin viene determinada porque desde el punto de vista de operacin no se analizar cmo se produce el comportamiento sino cules son sus efectos. De
esta manera se puede definir el comportamiento de un sistema en funcin de las interfaces
con el exterior, servicios que ofrece y servicios que demanda.
Una clasificacin tradicional de sistemas es la que se basa en el tipo de comportamiento
que siguen al relacionarse con su entorno, distinguiendo en sistemas reactivos y sistemas
interactivos. Un sistema puede entenderse como reactivo [24] [139] [69] [168] ya que el
sistema responde o reacciona ante ciertos estmulos que le llegan desde el entorno (peticiones o cambios producidos) mientras que el entorno observa los resultados o respuestas
que genera el sistema ante esos estmulos. Y al mismo tiempo, tambin puede entenderse
como interactivo, ya que se producen interacciones entre el sistema y su entorno [31] [1]
[171].
Los sistemas deben satisfacer el conjunto de requisitos para los que son diseados y
construidos. Los requisitos tienen que reflejar la estructura y comportamiento esperados
del sistema, as como la interfaz que permita la interaccin con el exterior. La interfaz
65
comprende el conjunto de entradas y salidas aceptadas por el sistema. El conocimiento

de la historia de acciones de entrada y salidas producidas en un sistema en respuesta a
las entradas, permite conocer si el comportamiento de un sistema satisface el conjunto de
requisitos para el que fue diseado o incluso si el comportamiento es determinista o no
determinista.
Existe un gran nmero de concepciones y definiciones de sistema basadas en la interaccin con el entorno en forma de entradas y salidas.
Una de las aproximaciones ms utilizadas para especificar un sistema consiste en
utilizar mquinas de estados finitos permitiendo especificar un sistema en trminos de
entradas y salidas. Las mquinas de estados finitos observan el comportamiento del
sistema precisamente como una vista de caja negra, generando acciones de salida en
respuesta a las acciones de entrada [50]. As pues, las mquinas de estados permiten
especificar un sistema en trminos de entradas y salidas, en funcin de los estados
posibles que pueda tener el sistema.
Una segunda aproximacin que describe un sistema en trminos de acciones de entrada y de salida es la realizada por Broy. En [24], Broy describe un sistema reactivo
en trminos de acciones de entrada y de salida caracterizando el comportamiento de
los sistemas reactivos por medio de conjuntos de trazas (secuencias) de acciones de
entrada y de salida. 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.
En [31], Broy plantea que los interfaces de los sistemas interactivos tambin se
pueden describir caracterizando sus historias o trazas de interaccin de mensajes,
y asume que cada stream (secuencia de mensajes) de salida corresponde a un stream
de entrada determinado, definindolo como propiedad de los sistemas interactivos.
66
Este planteamiento realizado por Broy ms bien parece una simplificacin para hacer viable el modelado de estos sistemas, limitando la complejidad del modelo. En
este trabajo se considera que es extremadamente restrictiva, ya que impide modelar
el comportamiento en situaciones en la que ciertos streams de salida no correspondan directamente a un stream de entrada concreto. Por ejemplo, algunas respuestas
del sistema sern funcin de un nico estmulo (entrada) a un elemento del sistema,
pero otras sern funcin de varios estmulos a uno o varios elementos del sistema a lo
largo del tiempo, y de las diferentes reacciones o comportamientos que pueda tener
el sistema. En lnea con los planteamientos de Dalal [43], se entender que el comportamiento interno del sistema puede determinar la generacin y envo de streams
de salida que no obedezcan a un entrada particular, sino a un conjunto de entradas a
lo largo del tiempo. As, el nivel de complejidad del modelo crecer con el nmero
de variables involucradas, como es el caso del nmero de entradas al sistema.
Otra aproximacin basada en las entradas y salidas del sistema es la aportada por
Wang [171]. Esta definicin contempla los sistemas como interactivos en los que
se producen conjuntos de relaciones internas entre los componentes del sistema, y
conjuntos de relaciones de entrada y salida entre los componentes y el entorno. Esta
definicin matemtica de Wang se ha tomado como punto de partida para enunciar la
definicin de sistema que se presenta en este trabajo. Se toma como base la existencia
de un conjunto de elementos interconectados relacionados con el entorno mediante
entradas y salidas, y se excluyen las relaciones internas entre los elementos no observables desde el exterior. Esta definicin de Wang incluye todas las relaciones entre los componentes del sistema, incluidas las relaciones internas entre ellos, cuando
desde el punto de vista de operacin, sern de inters nicamente aquellas relaciones
que sean observables desde el exterior del sistema. El comportamiento de los elementos que tambin incluye esta definicin no es de inters en el planteamiento de
este trabajo.
67
Finalmente, el modelo de sistema propuesto por Parnas llamado de cuatro variables

tambin se basa en un enfoque de entradas y salidas del sistema, mediante las variables que denomina monitorizadas y controladas [136]. Para Parnas un sistema fsico
est compuesto por un conjunto de elementos computacionales junto con varios dispositivos que monitorizan y actan sobre variables del entorno. Los elementos computacionales reaccionan ante cambios producidos sobre las variables supervisadas o
monitorizadas en el entorno. Una de las principales ventajas del modelo de Parnas es
que define explcitamente los lmites del sistema a travs de la identificacin de las
variables monitorizadas y controladas. Parnas asume que las relaciones que define
entre las variables del sistema, especialmente la relacin SOF (comportamiento de
entrada/salida), corresponden a funciones deterministas, sin embargo en este trabajo
consideraremos que el comportamiento de los sistemas puede ser no determinista.
Conviene resaltar que la aproximacin de puntos de funcin para sistemas de tiempo
real tal y como se define en [81] comparte parcialmente el planteamiento de modelo de sistema de cuatro variables en el que se identifican las entradas y salidas del
sistema por medio de variables monitorizadas y controladas.
Las operaciones aceptadas por un sistema determinan el conjunto de interacciones posibles entre el sistema y una aplicacin exterior u operador del sistema. Estas interacciones
pueden expresarse como el conjunto de entradas y salidas aceptadas por cada uno de los
componentes del sistema involucrados en la interaccin. Todas las definiciones de sistema
incluidas en este captulo describen el sistema en funcin de sus entradas y salidas, con algunas caractersticas especficas. Por ejemplo, la definicin de sistema interactivo realizada
por Wang [171] se centra en los componentes del sistema y del entorno, y de las relaciones
entre ellos como entradas y salidas. Broy, sin embargo, describe un sistema en trminos de
acciones de entradas y salidas, caracterizando el comportamiento de los sistemas por medio
de conjuntos de trazas de entradas y salidas [24] [31]. Y el modelo de sistema de cuatro
variables establece las entradas y salidas como resultado de la monitorizacin y control de
68
variables del entorno [137] [124].

Por otro lado, si se asume que el comportamiento de un sistema es determinista son
vlidos los modelos de sistema analizados en este captulo, pero si se toma el sistema como
no determinista no valen estos modelos, ya que no se puede predecir el comportamiento
del sistema en funcin de sus entradas, por eso en este trabajo consideramos como punto
de partida esencial, aislar las entradas y salidas de un sistema.
Respecto a la estructura de un sistema, ste puede estar compuesto a su vez de subsistemas con algn tipo de relacin entre ellos. Ghezzi describe un sistema software como una
composicin de mdulos con relaciones binarias entre ellos, y define el cierre transitivo de
una relacin para determinar si la relacin entre dos mdulos es jerrquica o no [65]. As,
plantea que las relaciones entre mdulos pueden representarse mediante un grafo, y en el
caso de las jerarquas, mediante un grafo acclico dirigido. Por tanto, de manera general
el conjunto de subsistemas que compone un sistema, o mdulos en el caso de un sistema
software, junto con las relaciones existentes entre ellos, permite representar un sistema
compuesto de elementos interrelacionados como una red o grafo de elementos. Yage et
al. presentan en [177] [11] un trabajo en esta direccin, en el que definen un lenguaje basado en XML, para el modelado de redes aplicables a sistemas compuestos de elementos
interconectados. Tambin Jorgensen, aunque con un enfoque de validacin de sistemas, representa un sistema software como una red de objetos, en los que se producen eventos de
entrada y de salida, gestionados por los mtodos de los objetos [92].
Los modelos representan un aspecto fundamental para el desarrollo de sistemas. El
modelo de interaccin entre un sistema y su entorno siempre se ha tenido como uno de
los factores ms importantes para conseguir implementaciones funcionalmente adecuadas
y confiables. Como se indica en [43] el modelado puede llegar a ser asequible en tanto en
cuanto el modelo de comportamiento no necesite detallar secuencias de operaciones en las
que operaciones posteriores en el tiempo dependan de acciones tomadas en operaciones
anteriores. Pero las operaciones en sistemas reales no siempre se pueden simplificar de
69
esta manera. Realmente una excesiva simplificacin puede conllevar ignorar caractersticas
esenciales y, como resultado, la funcionalidad y confiabilidad del sistema pueden quedar
por debajo del mnimo requerido. Por lo tanto las aproximaciones al modelo son necesarias
para poder abordar la complejidad existente.
Predecir la relacin entre estmulos (entradas al sistema) y respuestas (salidas del sistema) de un sistema requiere definir el comportamiento del sistema. En este captulo se ha
dejado patente que el comportamiento de los sistemas puede ser determinista o no determinista. En el primer caso, predecir el comportamiento del sistema en funcin de sus entradas
es factible; pero en el segundo caso no es posible definir, ni predecir el comportamiento del
sistema.
El funcionamiento real de muchos sistemas lleva a situaciones no deterministas, porque
an 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 comportamiento de los sistemas. As pues, como ya se ha dicho, este trabajo no tiene
como objetivo profundizar en el comportamiento interno de un sistema o de elementos
individuales de ste, si no en las interacciones 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.
Los investigadores perciben el modelo de interaccin desde diferentes puntos de vista,
cada uno con caractersticas especficas, pero complementarias. Se ha hecho a aquellos
paradigmas algunos de ellos:
La interaccin del sistema con el exterior puede modelarse en forma de estados del
sistema, por ejemplo con mquinas de estados o diagramas de estados [36] [37]. Se
identifican los estados posibles del sistema y las posibles secuencias de eventos que
70
originan un cambio de estado. Si bien permiten expresar la interaccin del sistema,

no reflejan con claridad las entradas y salidas del sistema sobre todo cuando existe
un gran nmero de estados. Adems, la comprobacin del modelo (model checking)
conlleva una explosin combinatoria, que tambin limita su uso [19] [144].
Una segunda aproximacin se basa en modelar escenarios para describir las interacciones del sistema con el exterior. Esta aproximacin es adecuada para representar
las operaciones del sistema en forma de entradas y salidas. Sin embargo, presentan
algunos inconvenientes: no permiten representar las propiedades del sistema, en especial las monitorizadas y controladas; las entradas y salidas del sistema se deben
identificar interpretando la direccin de las flechas que representan las interacciones;
y por ltimo, el nmero de escenarios puede llegar a ser elevado dificultando su sntesis.
Otro paradigma de interaccin es el basado en contratos. Un contrato define mediante
reglas u obligaciones, las entradas aceptadas y salidas producibles por las entidades
software que intervienen en una interaccin [122]. En el nivel de diseo, se utilizan
diagramas de clases UML y expresiones OCL para expresar los contratos entre entidades software. Consideramos que esta aproximacin es cercana a nuestra propuesta,
si bien tal y como se indica en [99] la representacin de contratos es ms complicada de entender y de mantener que una descripcin equivalente realizada solo con
diagramas.
La interaccin de un sistema tambin puede plantearse en trminos de servicios, proporcionados por un lado por el sistema para recibir entradas y por otor lado, por las
aplicaciones externas para recibir las salidas producidas por el sistema. Esta representacin est muy prxima a la nuestra, si bien la diferenciacin de propiedades
monitorizadas y controladas, as como de las entradas y salidas en el conjunto global
71
de operaciones del sistema, aporta mayor claridad y semntica al modelo de operaciones del sistema.
La interaccin hombre-computador (HCI) plantea la interaccin desde el punto de
vista de la persona o usuario. Esta aproximacin se centra en las interfaces que posibilitan la interaccin con el sistema contemplando varias disciplinas que tienen que
ver con aspectos del comportamiento del ser humano al utilizar las mquinas. El nfasis se pone en las interfaces que manejan las personas y no tanto en los sistemas en
s. En este sentido, no se centra en la interaccin del sistema hacia el exterior, sino
del operador hacia el sistema, y ms concretamente en el manejo de las interfaces de
los sistemas.
La especificacin del modelo de operaciones del sistema es la ltima de las aproximaciones planteadas, y la lnea a seguir en el trabajo. La especificacin del modelo
de operaciones del sistema no busca modelar este comportamiento, pero s especificar un nivel de interaccin, mediante una especie de API (Application Program
Interface) que permita a los stakeholders operar el sistema, es decir, interactuar con
el sistema; hay obviamente una relacin entre esta interfaz y el comportamiento. El
comportamiento es el resultado de operar el sistema utilizando esta interfaz. En cierta
forma esto est en lnea con el concepto basado en contrato (contract-based) como
se presenta en [117]. La aproximacin basada en el modelo de operaciones es ligeramente diferente a las explicadas anteriormente, aunque todas ellas pueden utilizarse
en cooperacin.
La especificacin de requisitos de operacin del sistema juega un papel muy importante
dentro del ciclo de vida software. Se han analizado una serie de estndares publicados
en el rea de la ingeniera del software que tratan especficamente las operaciones de un
sistema, bien proporcionando guas y plantillas para definir documentos de operaciones,
bien definiendo lenguajes procedimentales para la operacin y validacin de sistemas.
72
Desde el punto de vista de documentacin de operaciones, los estndares IEEE Std

1362-1998 [76], ANSI/AIAA G-043-1992 [12] y MIL Std 498 DI-IPSC-81430 [123] y
las guas INCOSE System Engineering Handbook [79] y Systems Engineering Guidebook for ITS [35], persiguen mejorar la comunicacin entre desarrolladores y usuarios
o clientes, introduciendo el concepto de documento de operaciones (ConOps u OCD) que
rene las necesidades de los usuarios en el sistema a desarrollar. La existencia de un documento de operaciones sirve de entrada a la hora de abordar el modelado de operaciones del
sistema.
Desde el punto de vista de las operaciones del sistema en s, cabe mencionar dos estndares que guardan cierta relacin. El primero de ellos es el lenguaje denominado PLUTO
recogido en el estndar de la ESA ECSS-E-70-32A [55] para la definicin de procedimientos de prueba y de operacin en sistemas de espacio. El segundo de ellos es el lenguaje
TTCN-3 [53] estandarizado por el ETSI, y orientado a especificar pruebas y sistemas de
pruebas. Ambos lenguajes, presentan ciertas caractersticas interesantes para tenerlas en
cuenta a la hora de especificar un lenguaje de operaciones derivado del modelo de operaciones de un sistema.
El enfoque de ingeniera dirigida por modelos MDE se fundamenta en el desarrollo
software dirigido por modelos, mediante la aplicacin y transformacin de modelos del
sistema. Otro enfoque enmarcado dentro de la ingeniera dirigida por modelo puede ser
la aplicacin del modelo de operaciones de un sistema, que se define en este trabajo, en
etapas tempranas del desarrollo. De esta manera, el proceso de desarrollo podra ir dirigido
por el modelo de operaciones de un sistema. Aplicando las transformaciones de modelos
[151] [149] [58] [118] se puedan generar los productos software de una forma semiautomtica, adems de asistida por herramientas que dirigen el proceso de transformacin.
En esta lnea es fundamental la definicin de modelos independientes de las plataformas
que posteriormente sern transformados hasta llegar, en algunos casos, a la generacin de
cdigo.
73
La definicin del modelo de operaciones de un sistema posibilitar a su vez la definicin

de una interfaz de operacin del sistema. Aunque queda fuera del alcance de este trabajo,
dicho interfaz podra generarse automtica o semi-automticamente aplicando transformaciones al modelo de operaciones y a los modelos que definen el sistema. La existencia de
una interfaz de operacin facilita la especificacin y ejecucin de pruebas de aceptacin del
sistema en etapas tempranas del desarrollo y permite la integracin con modelos orientados a pruebas como U2TP [130] y TTCN-3 [53]. El modelo de operaciones tambin puede
aplicarse en la generacin de un front end de operaciones del sistema, externo a ste. En
cualquier caso, la existencia de la interfaz de operacin aporta escalabilidad e integracin
con entornos y sistemas nuevos o existentes.
74
Captulo III
CONCEPTUALIZACIN DE SISTEMA OPERABLE
La falta de humanidad de la computadora consiste en que una vez se la

programa y trabaja adecuadamente su honradez es intachable.
Isaac Asimov
75
3.1. Introduccin
El objetivo de este captulo es presentar los sistemas operables como sistemas que interaccionan por un lado con su propio entorno, y por otro lado con sistemas o aplicaciones
externas a las que denominaremos frontend de operaciones de un sistema. El contenido de
este captulo incluye una serie de definiciones que permiten abordar el concepto y especificacin de un modelo de interaccin entre sistema y operador.
Para proporcionar una definicin de sistema acorde con el objetivo de esta tesis de
especificar las operaciones entre operador y sistema, se han combinado algunas caractersticas de las definiciones de sistema analizadas en el captulo anterior.
As, para definir nuestro propio concepto de sistema se han tomado como entradas caractersticas de las definiciones de sistema realizadas por Broy, Wang y Parnas entre otras.
A partir de estas entradas se ha ido aplicando nuestro propio proceso de conceptualizacin,
elaborando una serie de definiciones propias. En la primera parte del captulo se presentan
una serie de definiciones relativas a sistema y entorno, incluyendo las interacciones que
se producen entre ambos, elemento de un sistema y sistema como conjunto de elementos interconectados. En la segunda parte se introduce el concepto de sistema operable y
de frontend de operaciones de un sistema, definiendo as mismo las interacciones que se
producen entre ambos.
3.2. Los sistemas con componentes inter-relacionados

3.2.1. Sistema como autmata
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.
Del mismo modo y como una extensin de los autmatas, se utilizan las mquinas de
76
estados finitos y diagramas de estados (statecharts) para representar el comportamiento de

los sistemas.
As, se puede expresar el comportamiento de un sistema que interacta con su exterior,
como un autmata de estados finitos, por medio de la siguiente tupla de seis elementos:
(I, S , B, S o , A, O)
(5)
dnde:
I: representa el conjunto de entradas al sistema.
S : corresponde al conjunto de todos los posibles estados que pueda alcanzar el sistema. Consideramos que el sistema tiene propiedades perceptibles desde el exterior
del sistema P p , y propiedades o variables imperceptibles desde el exterior, V i . El conjunto de estados del sistema vendr dado por todos los posibles valores que puedan
tomar tanto las propiedades perceptibles del sistema P p , como las propiedades imperceptibles V i .
As expresamos S como:
S = Pp V i
B: representa la funcin de transicin de estados o comportamiento del sistema, B :
S (I {}) P(S ). El comportamiento B = B p Bi comprende:
1. El comportamiento perceptible B p desde el exterior del sistema, que afecta a las
propiedades perceptibles P p del sistema.
2. Y el comportamiento imperceptible Bi que afecta a variables V i del sistema, no
perceptibles desde el exterior.
La complejidad del sistema aumenta cuanto mayor sea el nmero de variables V i no
perceptibles desde el exterior, dado que tambin aumenta la parte del comportamiento del sistema no perceptible. Si V i = nos encontramos con un caso ideal, ya que el
77
comportamiento del sistema es completamente perceptible desde el exterior, B = B p ,

siendo ms sencilla la formalizacin del comportamiento del sistema.
S o S : es el estado inicial del sistema.
A S : representa el conjunto de estados de aceptacin, esto es, el conjunto de estados en los que puede encontrarse el elemento del sistema.
O: representa el conjunto de salidas generadas por el sistema.
Con independencia de la forma en la que se exprese el comportamiento del sistema,
ste experimentar una serie de cambios de estado como consecuencia de recibir una serie
de entradas. A su vez, ciertos cambios de estado en el sistema se proyectarn al entorno en
forma de salidas. Este trabajo se centra precisamente en la relacin entre entradas y salidas. Parnas [136] plantea que si el comportamiento del sistema es determinista las salidas
generadas por el sistema pueden expresarse en funcin de las entradas recibidas.
Sin embargo en sistemas complejos el comportamiento del sistema no siempre es fcil
de modelar o determinar. En lnea con planteamientos de Dalal [43], entendemos que el
comportamiento interno del sistema puede determinar cambios de estados, y por tanto la
generacin y envo de salidas, que no obedezcan a un entrada particular, sino a un conjunto
de entradas a lo largo del tiempo. As, se puede expresar el estado de un sistema en un
instante t, en funcin del estado anterior y de las entradas recibidas en un intervalo de
tiempo:
S t+1 = f (S t , {it1 , it2 , ..., itn }), S t = P p V i , ti 5 t

Pero modelar el siguiente estado S t+1 de un sistema puede ser complicado por las siguientes razones:
1. El nmero de variables del sistema, especialmente las variables no perceptibles V i ,
78
puede llegar a ser muy grande, y en consecuencia el nmero de estados posibles del
sistema.
2. El nmero n de entradas al sistema que participan en la transicin de estados en el
sistema puede llegar a ser muy grande. Adems, el sistema no ejerce control sobre el
nmero ni el momento en el que le llegan las entradas desde el entorno.
Dada la complejidad inherente al comportamiento de los sistemas complejos, y que por
otra parte centraremos el modelo de interaccin de un sistema en sus entradas y salidas, de
un elemento del sistema nos interesar:
a) el conjunto de entradas que pueda recibir y aceptar,
b) el conjunto de salidas que pueda generar,
c) las variables perceptibles en el sistema.
As, veremos un sistema como una caja negra, de manera que sean conocidas sus posibles entradas y salidas, no siendo de inters su comportamiento interno.
3.2.2. Relacin entre sistema y entorno
Se consideran las dos siguientes hiptesis relativas a un sistema:
Hiptesis 1 El sistema tiene capacidad de comunicarse con su exterior. En este sentido consideraremos que el sistema es abierto, en lnea con la definicin de sistema
abierto dada por Wang [171]. Al considerar que un sistema es abierto, sern relevantes tanto el sistema en s mismo, como el entorno con el que interacta.
Hiptesis 2 El sistema puede estar compuesto a su vez de subsistemas o elementos
inter-relacionados entre s.
En la seccin 2.2 del captulo anterior correspondiente al Estado del Arte se han analizado diferentes definiciones y percepciones de sistema, concluyendo con la existencia de una
79
serie de caractersticas comunes a todas ellas. De acuerdo con las definiciones de sistema
analizadas dadas por Wang [171], Bunge [32], Jackson [87], Parnas [136], Ghezzi [65],
Broy [24] y Drusinsky[50], en el contexto de este trabajo entenderemos que un sistema
satisface al menos las siguientes caractersticas:
1. El sistema estar compuesto por uno o ms componentes o subsistemas que podrn
estar inter-relacionados entre s.
2. El sistema ser accesible mediante algn tipo de interfaz, normalmente de tipo software, que acepte ciertas entradas y genere cierto tipo de salidas.
3. Finalidad del conjunto, todo sistema cumple una funcin concreta.
Tomando como punto de partida las caractersticas enunciadas, realizamos una primera
definicin de sistema:
Definicin 1 (Definicin inicial de Sistema)
Definimos Sistema como un conjunto de elementos inter-relacionados e interconectados,
que tienen una funcionalidad como conjunto que estar perfectamente identificada, y que
actan como un todo, y abierto en el sentido de comunicarse con el exterior. Un sistema
puede estar compuesto a su vez de otros sistemas o subsistemas.
La definicin anterior incluye la capacidad de un sistema de comunicarse con el exterior. La figura 9 muestra esta capacidad de interaccin, en la que se han ubicado sensores
y actuadores como medios para establecer la comunicacin entre el sistema y su exterior,
al que denominaremos entorno del sistema. Los sensores captan las entradas, denominadas
inputses , provenientes del entorno y los actuadores envan al entorno las salidas, denominadas outputs se , generadas por el sistema.
Definiremos a continuacin entorno de un sistema, basndonos en definiciones realizadas por Jackson [87], Parnas [136] y Staeesh [146] .
80
Figura 9: Relacin entre un sistema y su entorno

Definicin 2 (Entorno de un Sistema)
Entendemos por Entorno de un Sistema S, a todo aquello externo a S que tenga capacidad
de comunicarse con l. Esta comunicacin implica la existencia de variables en el entorno
monitorizadas y/o controladas por S.
El concepto de variable monitorizada y variable controlada se ha tomado del modelo
de sistema de cuatro variables definido por Parnas [137] [124]. En dicho modelo, que ha
sido descrito en el apartado 2.2.6 en la pgina 36, estas variables corresponden a ciertas
variables fsicas percibidas por el sistema en su entorno, algunas monitorizadas, otras controladas, y otras, ambas cosas. Las variables monitorizadas son fenmenos o cosas que se
encuentran en el entorno del sistema cuyos valores son observados por el sistema. Por ejemplo: temperatura externa, nmero de usuarios accediendo a un sistema software, opciones
seleccionadas por un usuario en una aplicacin software, etc. Las variables controladas son
fenmenos o cosas que se encuentran en el entorno del sistema cuyos valores son controlados o modificados por el sistema. Por ejemplo: temperatura en el interior de un vehculo,
contenido visualizado en la pantalla de un ordenador, etc.
Nosotros adoptamos el modelo de sistema hardware/software de cuatro variables propuesto por Parnas, mostrado grficamente en la figura 10, como una adaptacin de representaciones realizadas por Heitmeyer [72] y Sateesh [146]. Esta figura representa de forma
ms detallada que en la figura 9 la relacin entre el sistema y el entorno, identificando
los cuatro tipos de variables definidas en el modelo: monitorizadas, controladas, entrada y
81
Figura 10: Modelo de sistema de cuatro variables (basado en Heitmeyer [72] y Sateesh
[146])
82
salida. Nosotros las denominaremos respectivamente como:

variables monitorizadas: V m
variables controladas: V c
propiedades monitorizadas: Pm
propiedades controladas: Pc
El sistema est compuesto por cierto tipo de hardware y/o software y una serie de
dispositivos o componentes de entrada/salida, como sensores y actuadores, o interfaces en
general. El sistema a partir de estos dispositivos de entrada/salida monitoriza y controla
variables fsicas del entorno:
El dispositivo de entrada obtiene valores de variables fsicas del entorno (V m ) que
estn siendo monitorizadas por el sistema y los enva al sistema en forma de valores discretos. Estos valores discretos conforman las variables de entrada al sistema
provenientes del entorno (Pm ).
De forma anloga, el dispositivo de salida recibe valores discretos del sistema, provenientes de propiedades controladas (Pc ), con los que modifica el valor de variables
fsicas del entorno que estn siendo controladas por el sistema (V c ). Estos valores
discretos conforman las variables de salida del sistema hacia el entorno.
Definicin 3 (Interaccin Sistema-Entorno)
Entendemos por Interaccin entre un sistema y su entorno a cualquier intercambio de
informacin, previamente definida, con origen en uno cualquiera de ellos y que produce
un efecto determinado en el otro. La interaccin supone la comparticin entre ambos de
eventos y estados comunes, derivada de la existencia de variables monitorizadas y/o controladas en el entorno.
83
Identificaremos los siguientes elementos en la interaccin sistema-entorno, tal y como

se muestran en la figura 9:
1. El sistema, con el hardware/software que lo compone.
2. El entorno del sistema, con el que interacta.
3. Dispositivos fsicos o lgicos incluidos en el sistema. Estos dispositivos son los que
toman contacto directo con el entorno estableciendo la relacin de entrada/salida
entre un sistema y su entorno, posibilitando la interaccin entre ambos. Pueden ser:
Dispositivos de entrada o sensores, que monitorizan cambios de estado en variables del entorno monitorizadas por el sistema, y actualizan el valor de las
propiedades correspondientes del sistema.
Dispositivos de salida o actuadores, que modifican el estado de variables del
entorno controladas por el sistema, a partir de las propiedades del sistema correspondientes.
4. Las entradas y salidas del sistema:
a) inputses : entradas al sistema desde el entorno, capturadas por sensores y derivadas de cambios de estado en las variables monitorizadas. Se expresan por
medio de una lnea en forma de flecha con origen el entorno y destino los sensores del sistema.
b) outputs se : salidas desde el sistema al entorno, enviadas por medio de actuadores y derivadas de cambios realizados por el sistema en variables del entorno
que controla. Se expresan por medio de una lnea en forma de flecha con origen
los actuadores y destino el entorno del sistema.
Se produce una interaccin entre el sistema y su entorno, cuando sucede una de las dos
circunstancias siguientes:
84
El sensor asociado a una variable del entorno que est siendo monitorizada por el
sistema detecta un cambio de estado en la variable, o bien captura su valor actual. Con
el valor de entrada obtenido del entorno el sensor genera la entrada correspondiente
al sistema, actualizando el valor de la propiedad monitorizada correspondiente en el
sistema.
El comportamiento del sistema determina el cambio de estado de una propiedad del
sistema correspondiente a una variable del entorno que est siendo controlada por
el sistema, y mediante el dispositivo de salida correspondiente propaga el cambio al
entorno.
3.2.3. Punto de vista de las operaciones
El proceso de operacin de un sistema constituye la etapa del ciclo de vida de un sistema
en la que usuarios u operadores del sistema lo utilizan conforme a los requisitos para los
que fue construido. Las operaciones del sistema constituyen una parte esencial del conocimiento relacionado con un sistema. El estndar IEEE 1471 - IEEE Recommended Practice
Architectural 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. Consideramos por tanto interesante enfocar la definicin de
un sistema incluyendo el punto de vista de operaciones del mismo.
Estndares en ingeniera de software y sistemas como ISO/IEC 15288, Systems engineering - System life cycle processes. [83] e ISO/IEC 12207, Standard for Information
Technology - Software Lifecycle Processes [82] definen operador como una entidad (individuo u organizacin) que realiza la operacin del sistema. Para estos estndares el rol
de operador y el rol de usuario pueden ser asumidos, simultneamente o secuencialmente
por el mismo individuo u organizacin. En el contexto de este trabajo nos centraremos en
el rol de operador tal como se define a continuacin.
85
3.2.3.1.
Operador
Definicin 4 (Operador)
Llamaremos Operador a cualquier persona, dispositivo fsico o programa software con
capacidad de interaccin con un sistema. Para un sistema dado, pueden existir diferentes
roles de operador: entrada de datos, operacin del sistema, pruebas, etc.
Figura 11: Primer nivel de interaccin

Los sistemas creados por los seres humanos requieren generalmente de cierta interaccin con el hombre [87]. La figura 11 muestra el nivel de abstraccin ms alto relativo a
los aspectos de operaciones de un sistema. Las operaciones del sistema se reducen a las
interacciones dadas entre un operador y el sistema en trminos de entradas y salidas del
sistema. Este planteamiento coincide con la visin de sistema dada por Broy y Stolen en
[31]. Estos autores plantean la descripcin de un sistema en trminos de entradas y salidas,
abstrayndose de la estructura interna de los componentes del sistema, y proporcionando
nicamente descripciones de interface o caja negra.
86
El operador no suele interactuar directamente con el sistema. Normalmente utilizar

como intermediario a una aplicacin, con algn tipo de interfaz de usuario, que sea la que
establezca la interconexin fsica con el sistema. Para ello, el sistema tiene que disponer de
una interfaz que posibilite la interaccin con el operador. La figura 12 muestra este segundo
nivel de abstraccin de los aspectos de operaciones de un sistema. El operador interacta
con una aplicacin externa, a la que denominamos frontend de operaciones, y sta a su vez
lo hace con el sistema.
Los sistemas objeto de estudio en este trabajo son sistemas que disponen de interfaces
software que posibilitan la interaccin con ellos desde el exterior. A continuacin se definir
el concepto de interfaz de operacin.
Figura 12: Segundo nivel de interaccin
87
3.2.3.2.
Interfaz de operacin
Definicin 5 (Interfaz de operacin)

En sentido amplio, definiremos Interfaz de Operacin como el conjunto de comandos u
operaciones que permiten la interaccin de un sistema con otros sistemas facilitando el
intercambio de datos o informacin entre ellos.
El conocimiento del comportamiento o funcionamiento interno de un sistema es determinante en las etapas del ciclo de vida relativas al desarrollo y mantenimiento del sistema.
Sin embargo no es determinante en otros aspectos del ciclo de vida, como los de operacin
y validacin del sistema. Un operador no necesita conocer el comportamiento interno de un
sistema para interactuar con l, pero s necesita conocer los elementos que lo componen,
las entradas que admiten y las salidas que pueden generar.
Teniendo en cuenta la interaccin entre operador y sistema, daremos una nueva definicin de sistema basada en la existencia de un medio externo al sistema que permita al
operador interactuar con el sistema. En algunos casos este medio en s mismo constituir
un sistema compuesto de hardware y software, es decir, un sistema de operacin. Para
evitar confusiones con lo que estamos definiendo como sistema llamaremos a este medio,
frontend de operaciones de un sistema.
3.2.4. Estructura de un sistema
En los sistemas compuestos por varios elementos o subsistemas, existir algn tipo de
relacin entre ellos que les permita tener una funcionalidad definida como conjunto. En
caso de que el sistema tenga un nico elemento, tendramos una simplificacin del caso
anterior.
En este apartado presentamos dos enfoques o vistas diferentes relativas a la estructura
de un sistema compuesto por elementos inter-relacionados:
1. Vista estructural intra-elementos
88
2. Vista estructural inter-elementos

Para definir cada una de estas vistas se ha realizado una revisin de las definiciones
de sistema realizadas por Wang [171], Broy [24] y Parnas [136] detalladas en el captulo
de Estado del Arte en las secciones 2.2.5, 2.2.4 y 2.2.6 respectivamente. La definicin de
Wang se centra en los componentes del sistema y del entorno, y en las relaciones entre
ellos. Broy, sin embargo, define el sistema como un autmata con un conjunto de estados y
de transiciones entre ellos. Por ltimo, Parnas define el sistema basado en cuatro variables
relacionadas con los componentes o partes del entorno del sistema que son monitorizadas
y controladas por el sistema.
Realizaremos nuevas definiciones de sistema que integren los diferentes enfoques de
las definiciones de sistema anteriormente analizadas, desde el punto de vista de interaccin. Teniendo en cuenta la vista estructural intra-elementos de un sistema, definiremos
primeramente lo que entendemos por elemento de un sistema, de manera que ms adelante
al describir la vista estructural inter-elementos definiremos sistema como una composicin
de elementos del sistema inter-relacionados. En estas nuevas definiciones de sistema, indicaremos las partes basadas en definiciones de otros autores, las variaciones realizadas y los
nuevos elementos que se han incorporado.
3.2.4.1.
Visin estructural intra-elementos
Centraremos la vista intra-elementos de un sistema en cada elemento del sistema de

forma individual, con independencia del resto de elementos del sistema. Se obvian por
tanto las relaciones existentes entre los diferentes elementos del sistema, que sern tratadas
en el siguiente apartado al presentar la vista estructural inter-elementos.
Las definiciones enunciadas en este trabajo relativas a un sistema estn basadas en el
modelo Object-Attribute-Relation (OAR) utilizado por Wang [170]. El modelo OAR permite expresar la arquitectura de un objeto del sistema OS , mediante un conjunto de atributos
A y un conjunto de relaciones binarias R entre atributos:
89
OS = (A, R)
dnde:
Objeto: es una abstraccin de una entidad externa y/o un concepto interno.
Atributo: es un sub-objeto utilizado para denotar propiedades y caractersticas de un
objeto.
Relacin: es una conexin o inter-relacin entre cualquier pareja objeto-objeto, objetoatributo y atributo-atributo.
Siguiendo los aspectos tanto de arquitectura como de comportamiento de un sistema
[171], definiremos formalmente elemento de un sistema como sigue:
Definicin 6 (Elemento de un Sistema)
Definimos elemento de un sistema, denotado por E, como la siguiente tupla formada por
cinco elementos:
E = (, Pe , BE , I e , Oe )
(6)
dnde:
: entorno del sistema, con un conjunto no vaco de componentes C externos al
sistema, en los que se encuentran las variables monitorizadas y/o controladas por el
elemento del sistema. De acuerdo al modelo de sistema de cuatro variables [136]
clasificamos estas variables en tres conjuntos disjuntos entre s:
V m : conjunto de variables fsicas del entorno monitorizadas por el elemento del
sistema, V m = {vm1 , vm2 , ..., vmn }.
90
V c : conjunto de variables fsicas del entorno controladas por el elemento del

sistema, V c = {vc1 , vc2 , ..., vcn }.
V mc : conjunto de variables fsicas del entorno que son a la vez monitorizadas y
mc
mc
controladas por el elemento del sistema: V mc = {vmc
1 , v2 , ..., vn }
Pe : conjunto de atributos o propiedades del elemento del sistema, perceptibles desde

el exterior, que participan en la interaccin con su entorno. De acuerdo al modelo
de sistema de cuatro variables [136] clasificamos estas propiedades en tres conjuntos
disjuntos entre s:
Pm : conjunto de propiedades correspondientes a las variables del entorno monitorizadas por el elemento del sistema, Pm = {pm1 , pm2 , ..., pmn }.
Pc : conjunto de propiedades correspondientes a las variables del entorno controladas por el elemento del sistema, Pc = {pc1 , pc2 , ..., pcn }.
Pmc : conjunto de propiedades correspondientes a las variables del entorno que
son a la vez monitorizadas y controladas por el elemento del sistema,
mc
mc
Pmc = {pmc
1 , p2 , ..., pn }
Tales que:
a. (Pm Pc Pmc ) =
b. Pe = (Pm Pc Pmc ) ,
BE : comportamiento del elemento del sistema. Distinguiremos dos tipos de comportamiento:
BEp : comportamiento del elemento del sistema que es perceptible desde el exterior. Este tipo de comportamiento conlleva cambios en variables (propiedades)
que son monitorizadas por el elemento del sistema y por tanto observables por
el operador.
91
BiE : comportamiento interno, imperceptible desde el exterior del elemento del

sistema. Este tipo de comportamiento no es observable por un operador dado
que no afecta directamente al estado de las variables que son monitorizadas por
el elemento del sistema.
De tal forma que:
1. BE = BEp BiE
2. BiE = BE BEp
I e : conjunto de entradas, con origen en el entorno y destino el elemento del sistema,
es
es
Ie = inputses = {ies
1 , i2 , ..., in }. Proporcionan al elemento del sistema el valor de
variables del entorno que estn siendo monitorizadas por el elemento del sistema. Las
entradas al elemento del sistema pueden estar relacionadas nicamente con variables
del entorno monitorizadas o bien monitorizadas/controladas, esto es:
m
mc
(ies
j , pk ), pk {P P }
La figura 13 representa la correspondencia entre entradas y propiedades perceptibles

del elemento del sistema.
Oe : conjunto de salidas, con origen en el elemento del sistema y destino el entorno,
Oe = outputs se = {o1se , o2se , ..., onse }. Las salidas del elemento del sistema proporcionan valores a variables del entorno que estn siendo controladas por el sistema.
Una salida del elemento del sistema al entorno puede estar relacionada nicamente
con variables del entorno de tipo controlada o bien monitorizada/controlada, esto es:
c
mc
(o se
j , pk ), pk {P P }
La figura 14 representa la correspondencia entre entradas y propiedades perceptibles

92
Figura 13: Correspondencia entre entradas y propiedades perceptibles

En esta definicin de elemento del sistema se han seguido y combinado partes de las
definiciones de sistema dadas por otros autores:
Los elementos y BE se tomaron inicialmente de los que figuran en la definicin
de Wang [171]. Si bien en nuestro caso por un lado, se relaciona el entorno con las
variables monitorizadas y/o controladas por el elemento del sistema; y por otro lado
el comportamiento BE , se ha especializado en dos tipos diferentes: comportamiento
perceptible y comportamiento interno.
El conjunto de propiedades Pe puede entenderse como una representacin conceptual
de las variables de entrada y salida en el modelo de cuatro variables de Parnas [136].
Los conjuntos I e y Oe son equivalentes, por un lado en la definicin de Wang [171],
con los conjuntos Ri de relaciones externas de entrada y Ro de relaciones externas de
salida. Y por otro lado, en la definicin de sistema de Broy [24] con los conjuntos I
de entrada y O de salida. Aunque nosotros adems, hemos asociado estas entradas y
salidas con las propiedades monitorizadas y/o controladas por el sistema.
93
Figura 14: Correspondencia entre salidas y propiedades perceptibles

3.2.4.2.
Visin estructural inter-elementos
Planteamos la vista inter-elementos de un sistema como un subesquema del sistema

que comprende los elementos del sistema y las relaciones o conexiones entre ellos, que
son necesarias para llevar a cabo la interaccin desde el exterior del sistema por parte de
un operador del sistema 1 . No consideramos necesario que esta vista incluya las relaciones
internas entre los elementos del sistema que no sean relevantes en la interaccin del sistema
desde el exterior.
Representaremos un sistema compuesto de elementos interrelacionados que permita
interaccin desde el exterior por medio de una caja traslcida. La figura 15b muestra el
sistema como una caja traslcida en forma de valo con lneas oblicuas, conteniendo el
conjunto de elementos inter-relacionados en su interior. Los elementos del sistema, tienen
capacidad propia de interaccin con el exterior, y se han representado como una caja negra
(figura 15a) en forma de crculos opacos. La vista de caja traslcida, se apoya en el concepto
de vista de caja de cristal dado por Broy en [31]. Ambos tipos de vista, caja de cristal y caja
translcida, permiten visualizar los elementos del sistema como cajas negras, as como
1
un operador puede ser una persona u otro sistema software
94
Figura 15: Representacin de un sistema

las relaciones entre ellos. Pero, a diferencia de la primera, una caja traslcida muestra
nicamente aquellas relaciones entre los elementos del sistema, que son observables desde
el exterior del sistema, y oculta las relaciones entre elementos internas al sistema.
Teniendo en cuenta la vista de estructura inter-elementos de un sistema realizaremos
una nueva definicin de sistema. Esta nueva definicin incorpora tanto el conjunto de elementos del sistema con capacidad de interaccin desde el exterior como el conjunto de relaciones o conexiones entre ellos de inters en dicha interaccin. Esta definicin se apoya, en
la definicin 6 de elemento de un sistema E vista anteriormente en la pgina 90, y en las
definiciones de sistema realizadas por Wang [171], Broy [24] y Parnas [136].
Definicin 7 (Sistema compuesto de elementos inter-conectados)
Un sistema, denotado por S, se define por medio de una tupla formada por los siguientes
elementos:
95
S = (, S E, RE , PR , I e , Oe , , BS )
(7)
dnde:
: entorno del sistema con un conjunto no vaco de componentes C externos al
sistema, en los que se encuentran las variables monitorizadas y/o controladas por el
sistema: V m , V c , V mc .
SE: conjunto no vaco de elementos que componen el sistema SE = {E1 , E2 ,..., En } ,
. La definicin 6 (pgina 90) de elemento de un sistema E, comprende el conjunto
de las propiedades de un elemento del sistema Ei perceptibles desde el exterior:
PeEi = {PmEi PcEi Pmc
Ei } ,
El conjunto de propiedades del sistema perceptibles desde el exterior PeS , comprende
las propiedades perceptibles de los n elementos que componen el sistema:
PeS = {PmS PcS Pmc
S } ,
dnde:
1. PmS =
Sn
PmEi
2. PcS =
Sn
PcEi
i=1
3. Pmc
S =
i=1
Sn
i=1
Pmc
Ei
RE : subconjunto del cierre transitivo de relaciones entre elementos del sistema, en

el que nicamente se consideran las relaciones observables desde el exterior del sistema:
RE = {rE1 , rE2 , ..., rEn }, RE E E
96
(8)
El concepto de cierre transitivo de relaciones entre componentes de un sistema fue

definido por Ghezzi como el conjunto de mdulos relacionables o alcanzables partiendo de un componente concreto [65]. Grficamente RE corresponde con las relaciones definidas en la vista translcida del sistema (figura 15b). El conjunto RE estar
vaco en el caso de que el sistema est compuesto por un nico elemento.
PR : conjunto de propiedades de relacin inter-elementos de los elementos del sistema, PR = {PRE1 , PRE2 , ..., PREn }. Estas propiedades son utilizadas nicamente para
establecer las relaciones o conexiones entre los diferentes elementos que componen
el sistema, PeS PR = .
I e : conjunto de entradas al sistema provenientes de cambios de estado en las variables
monitorizadas en el entorno, I e = {IEe 1 , IEe 2 , ..., IEe n }.
Oe : conjunto de salidas desde el sistema al entorno, Oe = {OeE1 , OeE2 , ..., OeEn }.
: conjunto de restricciones en los elementos del sistema derivadas de la existencia
de relaciones entre ellos, = {1 , 2 , ..., n }.
BS : comportamiento del sistema como conjunto de elementos interconectados. Incluye los comportamientos individuales de cada elemento del sistema y los comportamientos derivados del funcionamiento como conjunto.
El comportamiento del sistema se compone, al igual que en el caso de un elemento
del sistema, del comportamiento perceptible desde el exterior y del imperceptible:
BS = BSp BiS
Cada uno de estos comportamientos del sistema, perceptible e imperceptible, comprenden los comportamientos perceptibles e imperceptibles respectivamente de los
n elementos que componen el sistema:
1. BSp =
Sn
i=1
BEp i
97
2. BiS =
Sn
i=1
BiEi
Como se ha indicado en el apartado anterior este trabajo no trata de modelar el comportamiento de los elementos del sistema, sino de poder expresar las interacciones
de un sistema por medio de sus entradas y salidas. El razonamiento expuesto sobre
el comportamiento de un elemento de un sistema BE respecto al determinismo o no
determinismo y la complejidad de predecir los cambios de estado, tambin es aplicable a un sistema con elementos interconectados. De hecho en este tipo de sistemas
en los que existen varios elementos interactuando al mismo tiempo entre ellos y con
el entorno, aumenta la dificultad para predecir el estado del sistema, dado que el siguiente estado del sistema ser funcin de los estados anteriores de cada uno de los
elementos que componen el sistema y de las entradas que reciban del entorno. El estado t + 1 de un sistema compuesto de n elementos puede expresarse de la siguiente
manera:
E
S t+1 = f ({S tE1 , S tE2 , ..., S tEn }, {iet1 , iet2 , ietm }), , S ti j = PeE j VEi j , ti 5 t
(9)
Por lo que el nmero de entradas y variables que conforman el estado del sistema
puede llegar a ser muy elevado, incluso del orden de millones de entradas y valores,
para modelar el siguiente estado del sistema.
Esta definicin de sistema, aade a la definicin de elemento del sistema E enunciada
anteriormente, los conjuntos: SE, RE , PR y . Los conjuntos RE y se han adaptado de
la definicin de sistema de Wang [171]. Adems, en esta definicin los conjuntos I e , Oe
y BS no afectan a cada elemento del sistema individualmente, sino que afectan al sistema
en su conjunto. Por otra parte, el conjunto PR define las propiedades de cada elemento que
posibilitan la relacin inter-elementos.
Teniendo en cuenta la definicin anterior, la figura 16 representa un metamodelo basado
en UML, correspondiente a la parte de un sistema compuesto de elementos inter-relacionados
que percibe un operador o usuario del sistema. La clase E define un elemento del sistema
98
Figura 16: Modelo de sistema perceptible por un operador

inter-relacionado con otros elementos por medio de la asociacin RE . Por simplicidad en
la representacin, las propiedades y operaciones de la clase E aparecen como conjuntos
de las propiedades perceptibles por el operador y de las entradas aceptadas por el sistema
desde el exterior respectivamente.
3.3.
Los Sistemas con componentes inter-relacionados como sistemas de interaccin
3.3.1. Concepto de sistema operable

En la seccin anterior se han tratado los sistemas desde el punto de vista de interaccin
con su entorno. A partir de ahora, consideraremos una de las caractersticas de los sistemas
intensivos software, como es la capacidad de interaccionar con ellos desde el exterior del
sistema, y por tanto, de la existencia de acciones u operaciones llevadas a cabo por un
usuario u operador del sistema.
99
Definicin 8 (Sistema operable)

Definimos un sistema operable, y lo denotamos por S o , como la siguiente tupla:
S o = (S , I f , O f )
dnde:
S: sistema compuesto de elementos inter-relacionados, conforme a la expresin 7 ya
vista en la pgina 96. Cada elemento del sistema dispone de una interfaz que permite
interacciones con medios externos al sistema.
I f : conjunto de entradas I f = {IEf 1 , IEf 2 , ..., IEf n } aceptadas por los elementos del sistema, enviadas por el operador desde un medio externo al sistema. Dnde:
IEf j = {i1f , i2f , ..., inf }, ikf = (ikf , PeE j )

siendo una funcin que relaciona la entrada k-sima con una propiedad del entorno
monitorizada y/o controlada por el elemento del sistema j-simo.
O f : representa el conjunto de salidas generadas desde los diferentes elementos del
sistema, O f = {OEf 1 , OEf 2 , ..., OEf n }. Las salidas son observadas por el operador del sistema a travs del medio externo desde el que interacta con el sistema. Estas salidas
pueden ser:
1. Respuestas a una entrada concreta.
2. Informacin relativa a eventos y cambios de estado producidos en las propiedades
que monitorizan/controlan los elementos del sistema.
Los tres elementos que definen un sistema S o permiten expresar la interaccin entre un
sistema y un operador. Basaremos esta interaccin en la existencia de un medio externo al
que llamaremos frontend de operaciones del sistema.
100
3.3.2. Concepto de frontend de operaciones de un sistema

En este apartado definiremos qu entendemos por frontend de operaciones de un sistema y su relacin con el operador de un sistema.
Definicin 9 (Frontend de Operaciones de un Sistema)
Definimos Frontend de Operaciones de un Sistema (S OF) a cualquier medio compuesto
de hardware y software que permita a un operador interactuar con un sistema, envindole
operaciones y observando/monitorizando los estados de las propiedades que el sistema
monitoriza y/o controla en su entorno. La interaccin entre frontend y sistema se fundamenta en la existencia de una interfaz de operacin en cada uno de ellos.
S OF = (S o , I o , Oo )
dnde:
1. S o : sistema con elementos inter-relacionados sobre el que interacta SOF, aceptando
entradas u operaciones y generando salidas.
2. I o : conjunto de entradas I o = {Ieo1 , Ieo2 , ..., Ieon }, con origen el operador que son aceptadas por el frontend de operaciones para interactuar con el sistema. El frontend de
operaciones a partir de una entrada ioj enva una entrada i fj al sistema.
3. Oo : conjunto de salidas Oo = {Ooe1 , Ooe2 , ..., Ooen } generadas por el frontend de operaciones para ser presentadas al operador. El frontend de operaciones a partir de una
salida o fj recibida del sistema, genera una salida ooj al operador.
Para un sistema dado, pueden coexistir diferentes aplicaciones operacionales o frontends, e incluso diferentes roles de operacin, por ejemplo rol de operador bsico, de operador administrador y de ingeniero de pruebas, con capacidades de operacin y puntos de
vista del sistema diferentes.
Un frontend de operaciones de un sistema resulta de utilidad en los dos casos siguientes:
101
Figura 17: Sistema operable con un Frontend de Operaciones

1. Sistemas intensivos software de nueva creacin que no dispongan de un medio de
operacin propio, para los que el frontend de operaciones represente el medio de
interaccin con los operadores del sistema. La figura 17 representa esta situacin
con la existencia del frontend de operaciones como medio externo al sistema que
posibilita la operacin y monitorizacin del mismo.
2. Sistemas ya existentes o de nueva creacin que dispongan de una interfaz de control
incorporado mediante el cual el operador pueda controlar u operar el sistema, por
ejemplo un panel de control del sistema. La figura 18 representa este tipo de sistemas,
para los que un frontend de operaciones puede representar una forma ms sencilla y
completa de operar y monitorizar el sistema, que los medios de control existentes en
el sistema.
El operador de un sistema mediante un frontend de operaciones, puede conocer en cada
momento el estado en el que se encuentran los elementos que componen el sistema y las
102
Figura 18: Sistema operable con un panel de control

relaciones o conexiones existentes entre ellos. El sistema acepta operaciones que permiten
obtener el estado de un elemento concreto en un instante dado. El cambio en el estado de
un elemento del sistema ser observable desde el frontend de operaciones, cuando:
El operador solicite al sistema el valor de alguna propiedad del elemento (correspondiente a una variable del entorno monitorizada por el elemento) por medio de una
operacin de entrada aceptada por el elemento.
El elemento del sistema genere informacin de salida al producirse un evento asociado al cambio de estado en alguna de sus propiedades Pm .
Se ha indicado que la interaccin entre operador y sistema se puede establecer mediante
un frontend de operaciones que permita la comunicacin entre ambos. Este frontend de
operaciones permitir:
a. Identificar cada uno de los elementos que componen un sistema para poder operar
con ellos y/o monitorizar su funcionamiento.
b. Mostrar las relaciones o conexiones entre los elementos que sean interesantes desde
el punto de vista de la operacin, visualizando el conjunto de elementos interconectados que compongan el sistema.
c. Conocer el estado en el que se encuentra cada elemento en un instante dado.
103
d. Enviar operaciones a los elementos del sistema y recibir las respuestas producidas.
e. Recibir informacin sobre ciertos eventos asociados a cambios de estado en los elementos del sistema.
El frontend de operaciones proporcionar al operador:
1. Por una parte, una representacin lgica del sistema en la que queden claramente
identificados el conjunto de los elementos que componen el sistema y de las relaciones existentes entre ellos. Ambos conjuntos corresponden con los componentes
SE y RE respectivamente, que figuran en la definicin 7 (pgina 96) de sistema con
elementos inter-relacionados
2. Y por otra parte, tiene que implementar el mecanismo necesario para el envo de
operaciones al sistema y la recepcin de respuestas a stas, as como, el conocimiento
de los eventos internos que se produzcan en los elementos y sean de inters desde el
punto de vista de operacin. Esto es, el conocimiento de las entradas I o y salidas Oo
que permiten la operacin del sistema mediante el frontend de operaciones.
3.3.3. Interacciones de un sistema desde el punto de vista de operaciones
El punto de vista de operaciones de un sistema incluye por tanto la interaccin del
sistema con su entorno, y la interaccin entre el sistema y el frontend de operaciones.
Adems, existe tambin una interaccin entre el operador y el frontend de operaciones.
As, tal y como se muestra en la figura 19, identificamos las siguientes interacciones desde
el punto de vista de operaciones del sistema:
1. Interaccin entre un sistema y su entorno.
2. Interaccin entre el operador y el frontend de operaciones.
3. Interaccin entre el sistema y un frontend de operaciones del sistema.
104
Figura 19: Relacin entre Sistema y Frontend de Operaciones del Sistema

El modelo de sistema representado en la figura 19 representa estas tres interacciones
diferenciando los siguientes tipos de entradas y salidas:
a. inputso f : entradas desde el operador al frontend de operaciones
b. inputs f s : entradas desde el frontend de operaciones al sistema
c. inputses : entradas desde el entorno del sistema al sistema
d. outputs se : salidas desde el sistema al entorno del sistema
e. outputs s f : salidas desde el sistema al frontend de operaciones
f. outputs f o : salidas desde el frontend de operaciones al operador
Es en la segunda y quinta de las interacciones indicadas, entre frontend de operaciones
y sistema, en las que se centra este trabajo. Por tanto, profundizaremos en las entradas y
salidas que se establecen entre ambos: inputs f s y outputs s f
105
3.3.3.1.
Interaccin Sistema-Entorno
La interaccin entre un sistema y su entorno ya ha sido analizada en la seccin 3.2 de

este captulo, habindose identificado:
1. inputses : entradas desde el entorno del sistema al sistema. Representan interacciones
con origen en el entorno del sistema, producidas al variar el estado de alguna variable
que est siendo monitorizada por el sistema.
2. outputs se : salidas desde el sistema al entorno, producidas al variar el sistema el
estado de variables del entorno controladas por l.
3.3.3.2. Interaccin Operador-Frontend de operaciones
El frontend de operaciones incluye una interfaz de usuario, normalmente de tipo grfica,
para interactuar con el operador. A travs de dicha interfaz, se establece la interaccin entre
ambos, formada por:
1. inputso f : entradas desde el operador al frontend de operaciones.
2. outputs f o : salidas desde el frontend de operaciones al operador.
El operador se sirve del frontend de operaciones como intermediario para interactuar
con el sistema, por lo que existe una correspondencia directa entre las entradas y salidas
producidas entre operador, frontend de operaciones y sistema. En consecuencia:
De las entradas inputso f se derivan las entradas inputs f s .
De las salidas outputs s f se derivan las salidas outputs f o
3.3.3.3.
Interaccin Sistema-Frontend de Operaciones del Sistema
Las interacciones entre frontend de operaciones y sistema vienen representadas por:
106
1. inputs f s : interaccin con origen en el frontend de operaciones y destino el sistema,

vendr dada por un conjunto de operaciones aceptadas por cada elemento del sistema,
y que conformarn el conjunto de entradas permitidas. Este conjunto corresponde al
conjunto I f de la definicin de sistema operable S o .
2. outputs s f : interaccin en el otro sentido, origen en el sistema y destino el frontend
de operaciones, y que corresponde al conjunto O f de la definicin de sistema operable S o . El conjunto outputs s f incluir dos subconjuntos que conformarn la salida
del sistema hacia el frontend de operaciones:
a) El primer subconjunto de la salida, lo formarn las respuestas vlidas a las
operaciones recibidas por el sistema.
b) El segundo subconjunto, corresponde a informacin relativa a eventos que normalmente conlleven cambios en el estado del sistema o en las propiedades monitorizadas de los elementos que conformen el sistema.
El comportamiento del sistema relativo a la interaccin con el frontend de operaciones
permite establecer una relacin entre las entradas inputs f s y las salidas outputs s f . Se
ha dejado patente en el captulo de Estado del Arte que el comportamiento de los sistemas
puede ser determinista o no determinista. En el primer caso, predecir el comportamiento del
sistema en funcin de sus entradas es factible; pero en el segundo caso no es posible definir,
ni predecir el comportamiento del sistema. Nosotros, simplificamos el comportamiento de
un sistema en funcin de sus entradas y salidas, por lo que nos abstraemos de la problemtica asociada al determinismo o no determinismo del comportamiento de los sistemas. Sin
embargo hacemos notar que el funcionamiento real de muchos sistemas lleva a situaciones
no deterministas bien porque aun con sistemas dirigidos por modelos deterministas no es
posible modelar el comportamiento para un nmero de entradas muy elevado (millones) y
en un orden desconocido a priori (conocemos la historia pero no se puede predecir a priori). As pues, este trabajo no trata el comportamiento interno de un sistema o de elementos
107
individuales de ste, sino las interacciones posibles entre un sistema y un frontend de operaciones del mismo. Nos centraremos en determinar cmo interactuar con el sistema desde
el frontend de operaciones, definiendo un modelo concreto al que llamaremos modelo de
operaciones y que ser definido en el captulo siguiente.
La interaccin entre un frontend de operaciones y el sistema ser factible siempre y
cuando se den las circunstancias siguientes:
1. Cada elemento del sistema implemente una interfaz con las operaciones de entrada
admitidas. El frontend de operaciones har uso de dicha interfaz para enviar operaciones al elemento del sistema.
2. El frontend de operaciones implemente una interfaz que acepte operaciones desde el
frontend de operaciones. El sistema har uso de dicha interfaz para enviar las salidas
que genere al frontend de operaciones.
3. Exista algn tipo de conexin o lnea de comunicacin entre el frontend de operaciones y cada uno de los elementos del sistema que posibilite la interaccin entre
ellos.
Llamaremos interfaz de operaciones al interfaz implementado por el sistema, e interfaz del frontend al interfaz implementado por el frontend de operaciones. Ambos tipos de
interfaces tendrn una funcionalidad similar a la de una API (Application Programming
Interface). La figura 20 representa la relacin entre el frontend de operaciones y el sistema,
por medio de sus interfaces. En el frontend de operaciones se han representado a modo de
ejemplo dos tipos de operadores diferentes operando con el sistema, operador e ingeniero
de pruebas.
Consideramos que un frontend de operaciones puede establecer distinciones de roles:
operador, ingeniero de pruebas, administrador, etc. De esta manera el comportamiento del
entorno ser diferente por ejemplo para un usuario con rol de operador que para un usuario
con rol de ingeniero de pruebas. Esta diferenciacin del comportamiento del frontend de
108
Figura 20: Interaccin entre Sistema y Frontend de Operaciones

operaciones en funcin del tipo de rol que interacta con el sistema, implicar la existencia
de subconjuntos de operaciones de entrada y de salidas del sistema diferentes.
3.4.
Este captulo plantea una conceptualizacin de sistema operable que permite centrar
la propuesta de modelo de operaciones del sistema presentada en esta tesis. Un sistema se
entiende como abierto en el sentido de permitir interaccin con el exterior, y compuesto
de elementos que inter-relacionan entre s. Se han realizado una serie de definiciones conducentes a la conceptualizacin de sistema operable: sistema, entorno de un sistema, interaccin sistema-entorno, operador, interfaz de operacin, elemento de un sistema, sistema
compuesto de elementos inter-conectados, y finalmente sistema operable y frontend de operaciones. Estas dos ltimas definiciones proporcionan el marco adecuado para plantear el
modelo de operaciones de un sistema.
Entre el sistema, sistema operable, y el frontend de operaciones se han definido una
109
serie de interacciones. Entre ellas, la interaccin de un sistema con su entorno planteada

en trminos de variables monitorizadas y/o controladas por el sistema; la interaccin entre
el sistema y el frontend de operaciones planteada en trminos de entradas y salidas del
sistema; y por ltimo, la interaccin entre operador y frontend de operaciones que hace
factible la interaccin entre operador y sistema.
110
Captulo IV
MODELO DE OPERACIONES DE UN SISTEMA
Despus de escalar una montaa muy alta, descubrimos

que hay muchas otras montaas por escalar.
Nelson Mndela
111
4.1. Introduccin
La utilizacin de modelos es una de las prcticas ms habituales para realizar el anlisis
y desarrollo de sistemas. El modelado se considera de gran ayuda a los ingenieros que
deben afrontar desarrollos de software cada vez ms complejos, permitindoles trabajar en
altos niveles de abstraccin [99].
La interaccin entre sistema y frontend de operaciones se puede modelar. El modelo
de operaciones de un sistema permitir definir el conjunto de interacciones entre sistema y
operador. Esta interaccin incluir las entradas al sistema enviadas por un operador desde
el frontend de operaciones, y las salidas producidas por el sistema y enviadas al frontend
de operaciones. El modelo de operaciones de un sistema aportar informacin respecto
de las operaciones de un sistema, y podr ser utilizado como elemento destacado en el
proceso de desarrollo. Adems como valor aadido, tambin facilitar informacin til para
especificar e implementar un frontend de operaciones de dominio especfico que permita a
los operadores interactuar con el sistema.
Basndonos en las definiciones realizadas en el captulo anterior, nuestro enfoque considera que el punto de vista de operaciones de un sistema contempla la siguiente informacin del sistema:
1. Conjunto perceptible de elementos interconectados que componen el sistema, con
capacidad de interaccin externa al sistema, definido por el conjunto SE.
2. Lista de propiedades perceptibles de cada elemento, definidas por el conjunto Pe .
3. Relaciones perceptibles entre el conjunto de elementos interconectados que componen el sistema, definidas por el conjunto RE .
4. Conjunto de entradas I f que puede aceptar el sistema, enviadas por el operador desde
el frontend de operaciones, as como las respuestas que pueda retornar el sistema al
frontend. Estas entradas incluirn las operaciones realizables sobre las propiedades
112
monitorizadas y/o controladas de los elementos del sistema.

5. Conjunto de salidas O f que pueda generar el sistema como consecuencia de cambios
de estado producidos en las propiedades del sistema perceptibles por el operador del
sistema.
4.2. Definicin de modelo de operaciones de un sistema

El modelo de operaciones refleja todos los tipos de interacciones posibles entre el sistema y el frontend de operaciones del sistema. Estas interacciones comprenden las entradas
al sistema provenientes del frontend de operaciones, inputs f s , y las salidas del sistema con
destino el frontend de operaciones, outputs s f .
Definimos ahora qu entendemos por entradas y salidas del sistema:
Definicin 10 (Entrada)
Una entrada, recibida por el sistema desde el frontend de operaciones, propicia el inicio
de una actividad en el sistema de la que resulta un cambio de estado en el sistema o la
obtencin de informacin sobre el estado del mismo. El sistema implementa la interfaz de
operaciones con las entradas que admite, a las que llamaremos habitualmente operaciones
o bien comandos de operacin del sistema.
Una entrada al sistema u operacin comprende:
1. Nombre de la operacin,
2. Elemento del sistema sobre el que acta,
3. Informacin asociada a la operacin, como parmetros de entrada.
Definicin 11 (Salida)
Una salida, enviada desde el sistema al frontend de operaciones, contiene informacin generada por el sistema relativa al resultado obtenido para una entrada determinada o bien
113
de cambios de estado producidos en el sistema. El frontend de operaciones implementar

una interfaz que permita la recepcin de las salidas enviadas por el sistema.
A continuacin enunciamos una definicin de modelo de operaciones del sistema en
funcin de las entradas y salidas del sistema definidas previamente:
Definicin 12 (Modelo de Operaciones de un Sistema)
Definimos modelo de operaciones de un sistema (MOS) como el conjunto de entradas I y
de salidas O que permiten la interaccin entre un sistema S y un frontend de operaciones
F. El modelo de operaciones del sistema viene dado por la unin de dichos conjuntos de
entradas y salidas (expresada mediante el operador ):
MOS = (I O)
(10)
Las entradas y salidas del sistema en la interaccin con el frontend de operaciones han
sido definidas en el captulo anterior como I f y O f respectivamente (pgina 100 ), por lo
que:
MOS = (I O) = (I f O f )
Las entradas estn compuestas a su vez de comandos de operacin C y de entradas no
aceptadas U:
I = (C U)
Y las salidas se componen de respuestas R, notificaciones N y alarmas A:
O = (R N A)
Cuando el sistema reciba un comando concreto desde el frontend de operaciones, salvo error, responder con una respuesta concreta a ese comando. En ocasiones el sistema
114
enviar informacin al frontend de operaciones que no corresponda a la respuesta de un

comando concreto. Estos envos obedecen a reacciones del sistema ante no uno, sino varios
comandos enviados desde el frontend de operaciones a lo largo del tiempo.
El modelo de operaciones expresado en funcin de estos componentes de las entradas
y salidas, queda de la siguiente manera:
MOS = (C R N A)
(11)
El conjunto de entradas U, no forma parte del modelo de operaciones dado que son
entradas no reconocidas por el sistema, como se ver seguidamente.
A continuacin se describen cada una de las entradas y salidas que figuran en la definicin anterior de modelo de operaciones de un sistema:
1. Comandos de operacin, C = {c1 , c2 , ...cn }
Entradas correspondientes a comandos de operacin establecidos previamente entre
el sistema y el frontend de operaciones por medio de algn tipo de lenguaje y protocolo. Esto es, el sistema implementa una interfaz de operacin con los comandos
que admite para interactuar con el frontend de operaciones. Un operador desde el
frontend de operaciones enviar una operacin al sistema y el sistema devolver la
respuesta correspondiente despus de llevar a cabo la operacin. La respuesta remitida por el sistema al frontend de operaciones corresponde a uno de los tipos de salidas
del sistema pertenecientes al conjunto R.
2. Entradas no aceptadas (unaccepted), U = {u1 , u2 , ...un }
Existe otro conjunto de entradas al sistema correspondiente a entradas no aceptadas o
no reconocidas por el sistema. Una entrada no aceptada es un comando de operacin
no contemplado en la interfaz de operaciones del sistema o bien que contiene algn
tipo de error. Estas entradas no aportan nada en el modelado de operaciones del
sistema por lo que no sern tenidas en cuenta.
115
3. Respuestas, R = {r1 , r2 , ...rn }.

Salidas del sistema producidas como respuesta a la ejecucin de los comandos de
operacin llegados desde el frontend de operaciones. Cada comando de operacin
aceptado por el sistema generar una respuesta. Nosotros consideramos que un comando de operacin llegado al sistema afectar a un nico elemento del sistema, y
por tanto, una respuesta corresponder tambin a un nico elemento y comando.
4. Notificaciones, N = {n1 , n2 , ...nn }.
Una notificacin es una informacin que enva el sistema al frontend de operaciones,
relativa al cambio de estado producido en una propiedad monitorizada. Una notificacin no se corresponde con una respuesta a un comando concreto, sino que se
produce en el transcurso del funcionamiento del sistema, como resultado de una
situacin de cambio de estado del sistema o de alguna de las variables del entorno
que monitoriza.
Las notificaciones siguen un comportamiento diferente al de las respuestas, ya que
pueden no ser predecibles. Dado que la aproximacin al modelo de operaciones de
un sistema descrita en este trabajo se centra en el conocimiento de entradas y salidas
del sistema y no en su comportamiento, este modelo es aplicable tanto a sistemas con
comportamiento determinista como a sistemas que sigan modelos de comportamiento no deterministas.
5. Alarmas, A = {a1 , a2 , ...an }.
Un tipo especial de notificaciones lo constituyen las alarmas producidas en el sistema. Pueden suceder durante un funcionamiento normal del sistema o bien por fallos detectados por ste. Una alarma es una notificacin con prioridad establecida,
y representa una situacin crtica o de mxima atencin en el sistema por parte del
operador.
La figura 21 representa el modelo de operaciones de un sistema, mostrando los tipos de
116
Figura 21: Modelo de operaciones de un sistema

entradas y salidas desde/hacia el exterior. Adems de las entradas C y las salidas R, N y A,
en la figura se distinguen los dos componentes que intervienen en la interaccin asociada a
las operaciones de un sistema:
Sistema
El sistema monitoriza variables del entorno por medio de sensores y controla variables del entorno por medio de actuadores. El sistema posibilita la interaccin con
aplicaciones externas, a las que hemos denominado de forma genrica frontend de
operaciones, por medio de una interfaz software que implementa el modelo de operaciones del sistema. El sistema o elementos de un sistema responden ante acciones
de entrada concretas, a las que llamamos operaciones. Adems, producen salidas, informando cuando se producen determinados eventos en el sistema que son de inters
para el contexto de operaciones definido. En la figura 21 el sistema se ha representado por una caja traslcida, que muestra nicamente la parte del sistema perceptible
117
por un operador. Esta parte incluye, las propiedades perceptibles, las entradas y las
salidas de los elementos del sistema perceptibles por el operador, as como las relaciones perceptibles entre estos elementos. La vista de caja traslcida de un sistema
se ha definido en el captulo anterior, pgina 94.
Frontend de operaciones
Representa al conjunto de las aplicaciones externas que permiten la operacin del
sistema. Los operadores interactan con el sistema enviando acciones de entrada
y recibiendo acciones de salida de ste. El frontend de operaciones normalmente
diferenciar varios tipos de operadores o roles, a la hora de operar el sistema, por
ejemplo el tipo operador y el tipo ingeniero de pruebas. Estos dos tipos de operadores
utilizarn el frontend de operaciones, el primero durante las fases de desarrollo y
operacin del sistema, y el segundo durante la fase de validacin del mismo. Cada
rol puede tener asociado una vista del sistema y un conjunto de entradas y salidas
determinados.
4.3. mbito de aplicacin del modelo de operaciones de un

sistema
El modelo de operaciones de un sistema determina el conjunto de tipos de interacciones
posibles que pueden ocurrir entre un sistema (que disponga de una interfaz software) y su
exterior, entendiendo por el exterior de un sistema, un frontend de operaciones del mismo.
Por tanto, la especificacin del modelo de operaciones de un sistema tiene que proporcionar
la informacin necesaria para poder construir un medio desde el cual interactuar con el
sistema desde el exterior de ste.
Para que exista entendimiento entre un sistema y su exterior es necesaria la existencia
del modelo de operaciones que determine las pautas de la interaccin entre ambos. Por
tanto, la especificacin del modelo de operaciones de un sistema ser bsica para:
1. Construir un frontend de operaciones de un sistema o cualquier tipo de aplicacin
118
que permita a un operador interactuar con el sistema.

2. Adems, en los casos en los que el sistema no permita inicialmente la interaccin con
el exterior, o sta sea limitada, el modelo de operaciones del sistema especificar las
entradas y salidas de la interfaz software que tendr que tener el sistema para permitir
la interaccin con el exterior.
Figura 22: Tipos de sistemas ya creados

Desde el punto de vista de proceso, la especificacin del modelo de operaciones de un
sistema, es de utilidad en los siguientes casos:
1. Sistemas intensivos software ya existentes compuestos de elementos fsicos con software embebido, o bien de componentes o servicios software, que dispongan de interfaces para la interaccin software con el exterior. El modelo de operaciones ha
119
de basarse necesariamente en las interfaces de interaccin existentes. La figura 22a

muestra este tipo de sistemas.
2. Sistemas ya existentes que carezcan de mecanismos de interaccin software desde
el exterior. El modelo de operaciones debe definirse de acuerdo a las posibilidades
de interaccin reales de los componentes del sistema. Tiene que crearse una interfaz
software en cada elemento del sistema que realice la interaccin con el exterior. La
figura 22b muestra este tipo de sistemas, que disponen de un subsistema de control
como un panel con botones de accin y dems artilugios, como medio de operar el
sistema.
3. Sistemas intensivos software de nueva creacin, ideados para interactuar desde el
exterior. El modelo de operaciones puede definirse en etapas tempranas facilitando un desarrollo incremental del sistema, apoyndose en la validacin del sistema
a travs de un frontend de operaciones. La especificacin temprana del modelo de
operaciones posibilitar la creacin de un frontend de operaciones antes incluso de
comenzar con el desarrollo del sistema. De esta manera, el frontend de operaciones
permitir validar el sistema conforme se vaya desarrollando.
En cualquiera de los tres casos expuestos, la existencia de un frontend de operaciones
basado en la especificacin del modelo de operaciones permite realizar los siguientes procesos:
Operacin/monitorizacin del sistema
Un operador mediante el frontend de operaciones de un sistema enva comandos de
operacin al sistema y observa las respuestas a los comandos enviados y las notificaciones producidas por el sistema.
Validacin del sistema
120
Por medio del frontend de operaciones del sistema un ingeniero de pruebas puede validar un sistema ejecutando pruebas de aceptacin compuestas de comandos de operacin sobre el sistema y observando/analizando los resultados obtenidos. Adems,
el frontend de operaciones podra almacenar los resultados de ejecucin de las pruebas, de manera que una evaluacin posterior de los mismos, permitiese determinar el
cumplimiento o no de los requisitos del sistema.
4.4.
Modelo de operaciones y requisitos de un sistema
Para determinar qu tipo de requisitos contienen la informacin necesaria para definir

el modelo de operaciones de un sistema, analizaremos dos de los estndares existentes
orientados a la especificacin de los requisitos de un sistema:
1. ESA ECSS-E10 Part6A: Space engineering. System engineering - Part 6: Functional
and technical specifications de la ESA [54].
2. IEEE Std 830: IEEE Recommended Practice for Software Requirements Specifications de Institute of Electrical and Electronics Engineers (IEEE) [77].
4.4.1. Estndar ECSS-E10Part6A
El estndar ECSS-E10Part6A [54] definido por la Agencia Espacial Europea (ESA)
introduce la estrategia para establecer y posicionar la Especificacin Funcional, FS (Functional Specification), y la Especificacin Tcnica, TS (Technical Specification), en el proceso de desarrollo de un proyecto para mejorar la efectividad de su gestin en trminos de
rendimiento, coste, planificacin y riesgos. El documento FS es un documento mediante
el cul el cliente establece el propsito deseado del producto, su entorno y restricciones
asociadas, las caractersticas de rendimiento y operacionales, y la flexibilidad permitida.
Mientras que el documento TS, define el conjunto de especificaciones que expresan los
121
requisitos tcnicos para el diseo y desarrollo de la solucin a ser implementada. El documento FS contiene una primera aproximacin al conjunto de requisitos tcnicos del producto, y el documento TS es la referencia tcnica para la aceptacin del producto final.
Los diferentes tipos de requisitos tcnicos que incluye el estndar ECSS en el documento FS y en el TS son los siguientes:
Requisitos funcionales. Definen funciones que debe realizar el producto, para conformar las necesidades y requisitos del usuario.
Requisitos de la misin. Requisitos relacionados con una tarea, una funcin o una
accin realizada por el producto.
Requisitos de interfaz. Requisitos relacionados con las caractersticas de interconexin o relaciones entre el producto y otros elementos.
Requisitos de entorno. Requisitos relacionados con un producto o el entorno del sistema durante su ciclo de vida. Esto incluye los entornos naturales (en sistemas de espacio, por ejemplo, interacciones de planetas, espacio libre) y los entornos inducidos
(en espacio, por ejemplo, radiacin, electromagnetismo, calor, vibracin y contaminacin).
Requisitos fsicos. Establecen las condiciones lmite para asegurar compatibilidad
fsica, y que no estn definidas por los requisitos de interface, requisitos de diseo y
construccin, o figuras referenciadas.
Requisitos operacionales. Requisitos relativos a la operatividad del sistema. Esto incluye perfiles operacionales, el entorno de utilizacin y eventos a los que debe responder (autonoma, control y contingencia) para cada perfil operacional. Por ejemplo: el producto debe ser diseado para aceptar control de la funcin de visin desde
el segmento de tierra.
122
Requisitos de factor humano. Relacionados con un producto o proceso adaptado a las

capacidades humanas considerando las caractersticas humanas bsicas. Estas caractersticas incluyen: capacidad de decisin, fuerza muscular, coordinacin y destreza,
dimensiones corporales, percepcin y juicio, carga de trabajo, comodidad y libertad
ante el estrs ambiental. Por ejemplo: el producto deber visualizar la informacin
con no ms de dos ventanas en la pantalla al mismo tiempo.
Requisitos de soporte logstico. Relacionados con las consideraciones logsticas que
aseguren el soporte efectivo y econmico de un sistema durante su ciclo de vida. Por
ejemplo, el producto deber ser diseado para ser instalado en el sitio del cliente en
dos das.
Requisitos de seguridad. Requisitos relativos a las actividades relevantes cubiertas
por el aseguramiento del producto (product assurance). Esto puede incluir: fiabilidad (reliability), disponibilidad (availability), mantenibilidad (maintainability), seguridad (safety), y aseguramiento de la calidad (quality assurance).
Requisitos de configuracin. Relacionados con la composicin del producto o su
organizacin. Por ejemplo: el producto deber tener 7 mdulos de potencia por motor.
Requisitos de diseo. Requisitos relacionados con los estndares impuestos de diseo
y de construccin tales como estndares del diseo, lista de la seleccin de componentes o materiales, capacidad de intercambio, seguridad o mrgenes.
4.4.2. Estndar IEEE Std 830
Por otra parte, el estndar IEEE Std 830 [77] aunque no plantea la clasificacin anterior
en especificacin funcional y tcnica, s que enumera y detalla los requisitos especficos
que debe cubrir un documento de especificacin de requisitos software. Establece que los
requisitos deben incluir una descripcin mnima de cada entrada en el sistema, cada salida
123
del sistema, y todas las funciones realizadas por el sistema en respuesta a una entrada o
como soporte a una salida. Organiza los requisitos especficos en los siguientes grupos:
Interfaces externos. Proporcionan una descripcin detallada de todas las entradas y
salidas del sistema.
Funciones. Los requisitos funcionales definen las acciones que deben tener lugar en
el sistema para aceptar y procesar las entradas y para procesar y generar las salidas.
Requisitos de rendimiento. Especifican los requisitos numricos estticos y dinmicos en el software o en la interaccin humana con el software.
Requisitos lgicos de base de datos. Requisitos lgicos de toda la informacin a
almacenar en la base de datos.
Restricciones de diseo. Especifican restricciones de diseo impuestas por otros estndares, limitaciones hardware, etc.
Conformidad con estndares.
Atributos del sistema software: fiabilidad, disponibilidad, seguridad, mantenibilidad
y portabilidad.
Este estndar tambin establece diferentes formas de organizar (expresadas en forma de
plantillas de documento) los requisitos especficos anteriores en funcin de: modo de operacin del sistema (por ejemplo: funcionamiento normal, funcionamiento en modo pruebas,
etc.), tipos de usuario diferentes (con distintas funciones), etc.
4.5. Subconjunto de requisitos del sistema relacionados con

el MOS
La especificacin de requisitos de operacin del sistema juega un papel muy importante
dentro del ciclo de vida software, ya que permite conocer al conjunto de los desarrolladores
124
desde un principio las necesidades y expectativas de los usuarios que utilizarn el sistema.
Esto llev a IEEE a definir el estndar 1362 [76] como gua que ayudase a definir un documento de operaciones, al que llam ConOps (Concept of Operations). Otros estndares
como ANSI/AIAA G-043-1992 [12] y MIL-STD-498 [123] tambin proponen la definicin de documentos de operacin equivalentes, al que llaman OCD (Operational Concept
Document).
Un documento ConOps describe cmo especificar las operaciones, pero no las operaciones en s. El documento debe incluir una visin general del sistema y especificar
el conjunto de stakeholders involucrados. De especial inters, es la identificacin de los
usuarios del sistema que interactuarn con el sistema: usuarios operacionales, de entrada
de datos, operadores del sistema, personal de soporte operacional, de mantenimiento del
software y formador. Un documento ConOps no ha de incluir especificaciones de diseo,
pero s ha de incluir escenarios operacionales, que juegan un papel importante para conocer
cmo los usuarios pueden operar e interactuar con el sistema. El INCOSE System Engineering Handbook [79] propone la definicin de un documento de operaciones ConOps
como parte de la especificacin de requisitos del sistema; y la gua Systems Engineering
Guidebook for ITS [35] plantea la definicin del concepto de operaciones como actividad
previa a la especificacin de requisitos del sistema, proporcionando una defincin inicial
del sistema.
El documento de requisitos del sistema tiene que contener toda la informacin necesaria
para poder especificar el modelo de operaciones del sistema. La existencia de un documento
de operaciones facilitar por tanto, especificar dicho modelo.
El conjunto de requisitos relacionados con la especificacin del modelo de operaciones
del sistema es un subconjunto de los requisitos del sistema:
Requisitos(MOS ) Requisitos(S istema)
(12)
Este subconjunto de requisitos del sistema debe contemplar requisitos funcionales y

125
requisitos de operacin. De los requisitos funcionales interesan aquellos que permitan establecer el tipo de elementos que componen el sistema, sus propiedades perceptibles y
las interrelaciones entre ellos observables desde el exterior. Los requisitos de operacin
incluirn la definicin de entradas aceptables y salidas factibles para cada elemento del
sistema.
A continuacin presentamos una correspondencia entre los requisitos funcionales y de
operacin indicados anteriormente y los estndares de requisitos ECSS-E10 Part6A [54] e
IEEE Std830 [77] respectivamente:
1. Requisitos funcionales.
En el estndar ECSS-E10 Part6A estn incluidos en los grupos de Requisitos
Funcionales y de Requisitos de Misin.
En el estndar IEEE Std830 estn incluidos en el grupo de requisitos denominado Funciones.
2. Requisitos de operacin.
En el estndar ECSS-E10 Part6A corresponden por un lado con los Requisitos de Interfaz, que describen caractersticas de interconexin o relacin del
producto con otros elementos, entendiendo que incluyen la descripcin de las
entradas y salidas del sistema. Y por otro lado, con los Requisitos Operacionales que contemplan los perfiles operacionales, el entorno de utilizacin y los
eventos asociados a cada perfil operacional.
En el estndar IEEE Std830 corresponden con el grupo de Interfaces Externos
que describe las entradas y salidas del sistema.
Los requisitos funcionales y de operacin incluidos en los requisitos del sistema, permitirn especificar cada uno de los componentes que conforman la definicin que se ha
realizado de sistema operable en el captulo anterior (pgina 100):
126
S o = (S , I f , O f )
Dnde:
S, se ha definido como sistema compuesto de elementos interconectados (pgina 96):
S = (, S E, RE , PR , I e , Oe , , BS )
I f , como conjunto de entradas aceptadas por los elementos del sistema y enviadas
por el operador desde el frontend de operaciones del sistema.
O f , como conjunto de salidas generadas desde los diferentes elementos del sistema
y observadas por el operador a travs del frontend de operaciones del sistema.
La tabla 1 muestra de forma esquemtica el conjunto de requisitos funcionales y de
operacin que permiten definir el modelo de operaciones de un sistema. Se ha incluido
tambin una columna que expresa el componente que cubre de la definicin indicada de
sistema operable.
4.5.1. Requisitos funcionales
El conjunto de requisitos funcionales del sistema contempla en principio toda la informacin necesaria para especificar el punto de vista del sistema incluida en la definicin
del Modelo de Operaciones del Sistema (MOS). Este punto de vista permite identificar los
elementos del sistema, sus propiedades perceptibles y las relaciones o conexiones entre el
conjunto de elementos interconectados que componen el sistema.
Los requisitos que permiten definir la vista del sistema comprenden:
1. Identificacin de los elementos o subsistemas que componen el sistema.
2. Lista de variables del entorno monitorizadas, controladas y monitorizadas/controladas por cada elemento, incluyendo el dominio de cada variable.
127
Requisitos Funcionales
Sistema Operable
Variables del entorno monitorizadas
Vm
Variables del entorno controladas
Vc
Variables del entorno monitorizadas y controladas
V mc
Elementos del sistema
SE
Interconexiones elementos
RE , PR ,
Requisitos de Operacin
Sistema Operable
Propiedades monitorizadas
Pm
E SE j
Propiedades controladas
PcE SE j
Propiedades monitorizadas y controladas
Pmc
E SE j
Estados y eventos de cada elemento
SE
Entradas de cada elemento
If
Salidas de cada elemento
Of
Tabla 1: Requisitos para definir un MOS
128
3. Relaciones o inter-conexiones (visibles desde el exterior) entre el conjunto de elementos interconectados que componen el sistema.
4.5.2. Requisitos de operacin
Los requisitos de operacin deben contemplar todas las interacciones permitidas u ofrecidas por el sistema hacia/desde un frontend de operaciones del sistema. Si el sistema est
compuesto de elementos o subsistemas es necesario definir el conjunto de interacciones
posibles para cada uno de los elementos.
El conjunto de requisitos de operacin tiene que permitir identificar para cada elemento
del sistema:
1. Las propiedades del elemento perceptibles por el operador:
monitorizadas: pm1 , pm2 , ..., pmn
controladas: pc1 , pc2 , ..., pcn
mc
mc
monitorizadas/controladas: pmc
1 , p2 , ..., pn
Para cada una de estas propiedades se especificar nombre, dominio y restricciones

asociadas.
2. Las entradas que acepta el elemento del sistema y que constituyen el conjunto de comandos de operacin, C = {c1 , c2 , ..., cn }. Por ejemplo: encender una mquina, apagarla, etc. Podemos clasificar estas acciones u operaciones de entrada del siguiente
modo:
Monitorizacin: acciones que obtienen el valor de variables monitorizadas.
Control: acciones que establecen o modifican el valor de variables controladas.
Cambio: acciones que no actan directamente sobre variables monitorizadas y
controladas, sino que producen un cambio en el comportamiento del elemento.
Como consecuencia, en algunos casos, se producir un cambio de estado en
129
el elemento (de estado encendido a apagado, desconectado a conectado, etc.)

representado por alguna de las propiedades perceptibles del sistema.
3. El conjunto de salidas que genera el sistema hacia el exterior como resultado de las
entradas recibidas a lo largo del tiempo. Estas salidas se clasifican en dos tipos:
Salidas que puede producir el elemento del sistema como respuesta a un comando de operacin concreto recibido, esto es, el conjunto R = {r1 , r2 , ..., rn }.
El conjunto de eventos, asociados a cambios de estado del elemento o cambios
en las variables monitorizadas/controladas por el elemento. Este conjunto comprende a su vez, el conjunto de notificaciones, N = {n1 , n2 , ..., nn }, que puede
producir el elemento, y a su vez, como caso especfico, el conjunto de alarmas,
A = {a1 , a2 , ..., an }, con la prioridad de atencin preestablecida.
Adems, los requisitos de operacin en algunos casos incluirn la informacin relativa
a los diferentes perfiles o roles de operacin existentes: operador, ingeniero de pruebas,
administrador, etc. Cada rol de operacin vendr definido por:
Elementos con los que puede interactuar, esto es, la vista del sistema perceptible
por el operador. Por ejemplo en sistemas distribuidos, pueden establecerse diferentes
vistas del sistema.
Entradas que puede enviar a cada elemento del sistema (las respuestas se derivan de
las entradas). Por ejemplo el conjunto de comandos disponibles para un operador
determinado no tiene por qu coincidir con el de un ingeniero de pruebas.
Conjunto de notificaciones que le son de aplicacin. Por ejemplo cierto tipo de alarmas pueden ser notificados a un perfil de operacin determinado y a otros no.
130
4.6.
Recomendaciones para especificar el modelo de operaciones de un sistema
Los requisitos funcionales y de operacin del sistema analizados en la seccin anterior,

aportan respectivamente la visin del sistema y la de interaccin del sistema perceptibles
por el operador. A partir de la especificacin de estos requisitos relacionados con las operaciones de un sistema, se puede especificar su modelo de operaciones basado en ambas
visiones perceptibles por el operador, utilizando por ejemplo tcnicas de orientacin a objetos.
Emplearemos el lenguaje UML para indicar cmo especificar el modelo de operaciones
de un sistema, dado que UML es uno de los lenguajes ms ampliamente utilizados en la
especificacin y desarrollo de sistemas.
1. Visin del sistema perceptible por el operador
La vista del sistema en el modelo de operaciones, puede representarse por medio de
diagramas de clases UML. Estos diagramas de clases son fundamentales para conocer los tipos de elementos que componen un sistema, las propiedades que los definen
(relacionadas con la monitorizacin y control de variables del entorno) y las relaciones que existen entre ellos. El frontend de operaciones accede al sistema a travs
de la interfaz de operacin que ofrece el sistema, conociendo las operaciones de cada
elemento que sean accesibles desde el exterior, no siendo de inters las operaciones
o mtodos internos de cada elemento.
Utilizando un diagrama de clases de UML, un elemento del sistema vendr definido
por una clase con un conjunto de atributos que reflejen todas las propiedades que
relacionen al elemento con su entorno:
propiedades monitorizadas
propiedades controladas
propiedades monitorizadas y controladas
131
Adems, el diagrama de clases reflejar las inter-relaciones entre elementos del sistema, que sean perceptibles por el operador del sistema.
2. Visin de interaccin del sistema perceptible por el operador
A partir de la especificacin de los requisitos necesarios para definir un MOS, se
puede obtener el modelo del comportamiento del sistema desde el punto de vista
de interaccin. En UML se puede modelar esta interaccin mediante los siguientes
diagramas:
Casos de uso.
Los diagramas de casos de uso permiten expresar la interaccin de los usuarios
con el sistema, en nuestro caso operadores del sistema. Adems permiten distinguir entre los diferentes tipos de operadores que interaccionan con el sistema.
La distincin de roles o perfiles para operar con el sistema permite determinar
el subconjunto posible de operaciones a realizar por cada tipo de operador del
sistema, as como la visin del sistema que tendrn y la posible informacin
recibida desde el sistema (notificaciones y alarmas generadas por el sistema).
As, la vista del sistema y el modo de interactuar con el sistema, podrn ser
diferentes para un perfil de ingeniero de pruebas que para un perfil de operador
especfico.
Diagrama de clases.
La funcionalidad incorporada a las clases por medio de mtodos, permite reflejar la capacidad de interaccin de un elemento del sistema (objeto de la clase)
con el exterior (frontend de operaciones o similar):
Comandos de operacin. Mtodos con visibilidad pblica, puesto que pueden
ser invocados desde el exterior.
Notificaciones, incluyendo las alarmas. Mtodos con visibilidad privada,
ya que no pueden ser invocados desde el exterior porque tienen su origen
132
en el elemento.
No obstante, habitualmente se utiliza la definicin de interfaces para expresar
la capacidad de interaccin del sistema. Una interfaz describe las operaciones
o mtodos visibles externamente de una clase u otra entidad que no especifica
la estructura interna. La definicin de una interfaz incluye nicamente las operaciones que admite y carece de atributos, asociaciones o estados. Una clase o
entidad UML puede admitir varias interfaces, disjuntas o solapadas. El diagrama de clases incluir:
Las interfaces que implemente cada elemento del sistema, incluyendo el
conjunto de operaciones del elemento accesibles desde el exterior. Cada
operacin corresponde a lo que se ha llamado comando de operacin. Una
operacin se define por un nombre, parmetros de entrada y un valor de
retorno que coincidir con la respuesta a un comando de operacin recibido
por el elemento del sistema.
Las interfaces usadas por cada elemento del sistema, e implementadas por
el frontend de operaciones. Estas interfaces son utilizadas por el sistema
para enviar al frontend de operaciones las notificaciones y alarmas que
genere. Las interfaces usadas en las interacciones entre elementos del sistema no son de inters en el modelado de las operaciones, ya que no son
visibles desde el exterior del sistema.
Secuencia.
Los diagramas de secuencia permiten establecer la secuencia de acciones y flujo
de informacin desde el operador hacia el sistema (operaciones o comandos)
y viceversa (respuestas, notificaciones y alarmas). Para definir un modelo de
operaciones nos basaremos en los diagramas que reflejen la interaccin entre
los actores o usuarios del sistema y el propio sistema. Sin embargo, dado que
el modelo de operaciones oculta el comportamiento interno del sistema, estos
133
diagramas de secuencia no han de reflejar el comportamiento interno de cada

elemento. El modelado de operaciones del sistema se centrar en diagramas que
reflejen las entradas y salidas del sistema.
Estado.
Los diagramas de estados reflejan los diferentes estados en los que puede encontrarse un elemento del sistema reflejando los eventos y condiciones que producen los cambios de estado. De igual modo que en el caso anterior, para el modelo de operaciones de un sistema no es de inters el comportamiento interno
La representacin de un sistema con diagramas UML permite reflejar el modelo de operaciones del sistema. Sera interesante disponer de una extensin de UML como un perfil,
que facilite representar y visualizar de una forma clara y concisa el modelo de operaciones
del sistema. En el siguiente captulo se propone partiendo de un metamodelo, un perfil de
UML para definir el modelo de operaciones de un sistema.
4.7. Resumen y conclusiones del captulo

Este captulo define el modelo de operaciones de un sistema en funcin de las entradas,
entendidas como operaciones, y las salidas, entendidas como respuestas a las operaciones
y notificaciones producidas en el sistema, dadas entre sistema y operador por medio de un
frontend de operaciones.
Por otra parte, se ha identificado el mbito de aplicacin del modelo de operaciones,
tanto en sistemas ya existentes como en sistemas de nueva creacin. Adems, el modelo
de operaciones del sistema puede utilizarse en la creacin de una interfaz de operacin
del sistema y del frontend de operaciones del sistema, aplicable tanto en la operacin y
monitorizacin del sistema como en la validacin del mismo.
134
Tambin se identifica el subconjunto de requisitos del sistema relacionados con la especificacin del modelo de operaciones de un sistema, distinguiendo entre requisitos funcionales y de operacin. Y por ltimo, se plantea cmo especificar el modelo de operaciones de un sistema mediante el lenguaje de modelado UML.
135
136
Captulo V
PROPUESTA DE REPRESENTACIN DEL MODELO
DE OPERACIONES DE UN SISTEMA
Una sonrisa es una semilla

que crece en el corazn y florece en los labios.
Martha Stevenson
137
5.1. Planteamiento inicial

Este captulo presenta una representacin mediante UML del modelo de operaciones de
un sistema. Se define un metamodelo del modelo de operaciones de un sistema, y basndose
en ste un perfil UML para representar modelos de operaciones.
En el captulo anterior se ha propuesto la utilizacin del lenguaje UML [133] para
especificar el modelo de operaciones de un sistema. La eleccin de UML viene determinada
por ser un lenguaje de modelado de propsito general y de aspecto grfico que permite
modelar sistemas. Adems el lenguaje UML es el lenguaje de modelado ms extendido hoy
en da para sistemas software, y se ha convertido en el estndar de facto utilizado y aceptado
por la industria para modelar sistemas. Como lenguaje de modelado de propsito general
en principio permite modelar cualquier sistema, pero no puede cubrir ciertos detalles de
representacin y semnticos, especficos de cada dominio de aplicacin.
Para poder adaptar los diagramas UML a dominios de aplicacin concretos, extendiendo su sintaxis y semntica, el grupo OMG (Object Management Group) defini dos mecanismos de extensin de UML: perfiles y extensiones del metamodelo [133]. Los perfiles
UML permiten una ampliacin de UML ms ligera que la que permiten las extensiones. Un
perfil contiene un conjunto predefinido de estereotipos, valores etiquetados, restricciones e
iconos que extienden UML para un dominio de aplicacin concreto.
En la tabla 2 figuran los perfiles UML definidos hasta la fecha por OMG. Otros ejemplos
de aplicacin de perfiles UML no definidos por OMG se encuentran en [59] [169] [119].
Dado que UML es un lenguaje de propsito general, se pueden definir aspectos de
operaciones al modelar un sistema. Sin embargo, es complicado realizar una separacin
de los aspectos de operaciones del resto de aspectos del modelo del sistema. Por ejemplo,
una clase define el conjunto de propiedades de los objetos que representa, entre las que
se incluyen las propiedades internas, las propiedades del entorno, y las propiedades de
relacin o interconexin con el resto de clases. Algo similar sucede con la definicin de
mtodos de una clase, si se incluyen mtodos internos y mtodos visibles desde otras clases;
138
Perfil
UML Profile for CORBA
UML Profile for CORBA Component Model (CCM)
UML Profile for Enterprise Application Integration (EAI)
UML Profile for Enterprise

Distributed Object Computing
(EDOC)
UML Profile for QoS and Fault

Tolerance
UML Profile for Schedulability,

Performance, and Time
UML Testing Profile (U2TP)
Descripcin
Proporciona un medio estndar para expresar la semntica de Corba IDL utilizando notacin UML, y soporte para expresar esta
semntica con herramientas UML.
Esta especificacin proporciona un medio estndar para expresar aplicaciones basadas en
CCM utilizando notacin UML y soportar
transformaciones de modelo MDA (Model
Driven Architecture) tales como PIM a PSM y
PSM a PIM. Tambin est diseado para trabajar con repositorios MOF.
El objetivo es simplificar la integracin de
aplicaciones proporcionando un estndar de
intercambio de metadatos para informacin
relativa al acceso a interfaces de aplicacin.
La idea del perfil EDOC es simplificar el desarrollo de componentes basados en sistemas
EDOC por medio de un marco de modelado,
basado en UML y conforme al OMG Model
Driven Architecture.
Esta especificacin define un conjunto de extensiones UML para representar conceptos de
calidad de servicio (Quality of Service) y tolerancia a fallos.
Especifica un perfil UML que define paradigmas de uso estndar para el modelado de aspectos de tiempo, schedulability, y rendimiento en sistemas de tiempo real.
Define un lenguaje para disear, visualizar,
especificar, analizar, construir y documentar los artefactos de sistemas de test. Es un
lenguaje de modelado de test que puede ser
utilizado con las principales tecnologas de
objetos y componentes, y aplicado a sistemas
de test en varios dominios de aplicacin.
Tabla 2: Perfiles UML definidos por OMG
139
aunque en este caso, la definicin de interfaces permite separar los aspectos internos y de
interaccin de las clases.
Se considera interesante disponer de un lenguaje de modelado que permita definir el
modelo de operaciones de un sistema de manera concisa. Se podra definir un nuevo lenguaje utilizando MOF, pero dado que UML incluye mecanismos de extensin propios para
definir nuevos lenguajes de modelado basados en l, se definir una extensin, un perfil
UML, que contemple las necesidades concretas de la operacin de sistemas planteadas en
el captulo anterior al definir el MOS.
Tal y como indican Fuentes y Vallecillo en [59], UML 2.0 plantea una serie de razones
para extender y adaptar un metamodelo ya existente, incluido el propio UML, y son vlidas
para el perfil de operaciones que se plantea:
1. Disponer de una terminologa y vocabulario propios del dominio de aplicacin relativos a las operaciones de sistemas.
2. Definir una nueva notacin para smbolos ya existentes, orientada al domino de aplicacin concreto, esto es, al modelado de las operaciones de un sistema.
3. Incorporar cierta semntica que no es posible expresar o se expresa vagamente con
UML.
4. Permitir aadir nuevas restricciones. Por ejemplo, una propiedad monitorizada no
puede tener asociada una operacin que implique cambio de valor en ella.
5. Incluir cierto tipo de informacin a un modelo que facilite o permita aplicar transformaciones a otros modelos.
Por todo lo anterior, se considera que la existencia de un perfil UML orientado a la
operacin de sistemas contribuir notablemente a la definicin de forma completa y uniforme del modelo de operaciones de un sistema. En la elaboracin del perfil de operaciones
140
de sistemas propuesto en este captulo se han seguido las recomendaciones propuestas por
Fuentes y Vallecillo [59] para la elaboracin de perfiles UML:
1. Disponer de la definicin del metamodelo relativo al dominio de aplicacin a modelar
con un perfil. En este caso, un metamodelo que incluye los aspectos del modelo de
operaciones del sistema definido.
2. Definir el perfil a partir del metamodelo anterior, incluyendo un estereotipo por cada
elemento del metamodelo que vaya a formar parte del perfil, y aadiendo los valores
etiquetados y restricciones correspondientes a atributos y restricciones en el metamodelo.
De esta forma, se define en primer lugar un metamodelo, descrito en el apartado 5.2, que
recoge el modelo de operaciones de un sistema. En segundo lugar, se ha definido un perfil
de operaciones de sistemas, descrito en el apartado 5.3, a partir del metamodelo anterior.
5.2.
Metamodelo de operaciones de un sistema
Una vez definido el modelo de operaciones de un sistema en el captulo anterior, se

presenta en este apartado un metamodelo UML para representarlo. Este metamodelo pretende servir de referencia para el modelado de las operaciones de sistemas en general. La
figura 23 muestra el metamodelo al que hemos denominado SystemOperation Metamodel.
El metamodelo incluye:
1. La representacin del sistema formado por elementos interconectados.
2. Propiedades monitorizadas y/o controladas por los elementos del sistema.
3. Entradas aceptadas por el sistema con origen en aplicaciones externas.
4. Salidas del sistema, clasificadas en los tres tipos definidos en el modelo de operaciones: respuestas, notificaciones y alarmas.
141
En el captulo anterior se ha definido modelo de operaciones de un sistema como el

conjunto de entradas I f y el de salidas O f entre un sistema operable S o y un frontend
de operaciones SOF. Las entradas se han definido como comandos de operacin C, y las
salidas como respuestas R, notificaciones N y alarmas A.
El metamodelo que se presenta recoge la informacin necesaria para definir el modelo
de operaciones del sistema, e incluye clases, relaciones de herencia, asociaciones, tipos de
datos y enumeraciones, que incluyen los componentes de la definicin dada de modelo de
operaciones del sistema. El metamodelo propuesto refleja la siguiente informacin:
Los diferentes tipos de elementos, con capacidad de interaccin con el exterior, que
componen un sistema (SystemElement). Corresponden al conjunto SE de la definicin
de sistema operable.
Las propiedades monitorizadas y/o controladas por los elementos del sistema (SeProperty). Corresponden al conjunto Pe de los elementos del sistema.
Las relaciones visibles desde el exterior del sistema que pueden establecerse entre
los diferentes elementos del sistema (visibleRelation). Incluye los conjuntos RE , PR
y de la definicion de sistema operable.
El conjunto de entradas (comandos de entrada u operaciones) aceptadas por cada
elemento (InputCmd). Corresponde al conjunto de comandos de operacin C.
El conjunto de salidas producidas por los elementos del sistema en respuesta a los
comandos de entrada aceptados (Response). Corresponde al conjunto de respuestas
R.
Notificaciones producidas por los elementos del sistema como consecuencia de cambios de estado producidos en las variables que monitoriza (Notification). Corresponde
al conjunto de notificaciones N.
142
Figura 23: Metamodelo de operaciones del sistema (System Operations Metamodel)

143
Alarmas producidas por los elementos del sistema como consecuencia de cambios de
estado, de especial atencin o prioritarios, producidos en las variables que monitoriza
(Alarm). Corresponde al conjunto de alarmas A.
A continuacin se describen cada uno de los tipos de elementos que definen este metamodelo, agrupados respecto al sistema en s mismo y al conjunto de interacciones permitidas.
5.2.1. Vista del sistema
Como caractersticas bsicas de la definicin de sistema con elementos interrelacionados (pgina 96) tenemos las siguientes:
Pueden existir diferentes tipos de elementos y diferentes tipos de relaciones entre
elementos.
Un tipo de elemento viene definido por una serie de propiedades o atributos que
corresponden a variables de entrada (monitorizadas), de salida (controladas) o de
ambos tipos.
Un tipo de elemento determina el conjunto de tipos de relacin vlidos con los que
poder relacionar un elemento de un tipo con elementos de otro o del mismo tipo.
Un tipo de relacin determina el tipo de elementos que pueden ser relacionados, y
otros aspectos como cardinalidades mnimas y mximas.
El sistema puede disponer de un conjunto de reglas para los elementos y relaciones
que determinen la validez del modelo.
La vista del sistema, que determina los elementos del sistema y las propiedades que les
relacionan con su entorno, se ha representado por medio de las siguientes clases:
SystemElement
144
SeProperty
y de los siguientes tipos de datos:
ElementStatus
AccessPort
PropertyType
A continuacin se describe cada una de estos elementos.
5.2.1.1.
Clase SystemElement
Descripcin
Representa a los diferentes tipos de elementos, perceptibles por el operador, que componen un sistema.
Asociaciones
source: SystemElement[0..*]
Elementos del sistema con los que est relacionado un elemento como destino de la
relacin.
target: SystemElement[0..*]
Elementos del sistema con los que est relacionado un elemento como origen de la
relacin.
properties: SeProperty[1..*]
Propiedades del elemento que son perceptibles por el operador del sistema.
implements: InputInterface[1]
Interfaz de entrada que implementa el elemento del sistema para recibir entradas
desde el frontend de operaciones.
145
uses: OutputInterface[1]
Interface de salida que usa el elemento del sistema para enviar las salidas que produce
al frontend de operaciones del sistema, y que lgicamente debe ser implementado por
ste.
Atributos
id: Identifier
Identificador nico de cada elemento del sistema.
access: AccessPort
Informacin del elemento con la que establecer la interaccin desde el frontend de
operaciones.
status: ElementStatus
Estado del elemento en un momento dado desde el punto de vista de interaccin,
representado por la enumeracin ElementStatus (con valores activo o inactivo).
Restricciones
Un elemento del sistema no puede estar conectado consigo mismo.
5.2.1.2. Clase SeProperty
Descripcin
Esta clase representa las propiedades del sistema perceptibles por el operador del sistema. Una propiedad corresponde con una de las variables del entorno monitorizadas y/o
controladas por el elemento del sistema.
Asociaciones
146
inputs: InputOperation[0..*]
Entradas al elemento del sistema relacionadas con una propiedad concreta del elemento.
outputs: OutputOperation[0..*]
Salidas del elemento del sistema relacionadas con una propiedad concreta del elemento.
systemelement: SystemElement[1]
Esta clase participa en una relacin de composicin con la clase SystemElement.
Atributos
propertyname: String
Nombre de la propiedad perceptible del elemento del sistema que corresponde a una
variable monitorizada y/o controlada en el entorno.
datatype: DataType
Tipo de datos de la propiedad.
propertytype: PropertyType
Tipo de propiedad respecto a la interaccin con el entorno del sistema representado
por la enumeracin PropertyType, que incluye los tipos: Monitored, Controlled y
MonitoredAndControlled.
value: PropertyValue
Valor que tomar la propiedad en un instante dado respecto a la interaccin con el
entorno del sistema representado por la enumeracin PropertyValue.
Restricciones
Una propiedad de tipo Controlled correspondiente a una variable controlada, no
puede tener asociada operaciones de salida de tipo Notification o Alarm.
147
Una notificacin o alarma es aplicable nicamente a propiedades monitorizadas (tipo

Monitored o MonitoredAndControlled).
5.2.1.3.
Tipo de datos AccessPort
Refleja de forma abstracta el tipo de datos con el que se define la informacin necesaria para establecer una interaccin desde el frontend de operaciones con un elemento del
sistema.
5.2.1.4.
Enumeracin ElementStatus
La enumeracin ElementStatus contiene los posibles estados en los que puede estar un
elemento del sistema desde el punto de vista de operaciones del sistema.
Valores:
active
Indica que el elemento del sistema est activo u operativo.
innactive
Indica que el elemento del sistema est inactivo.
5.2.1.5. Enumeracin PropertyType
La enumeracin PropertyType contiene el tipo de propiedad de un elemento.
Valores:
Monitored
Indica la correspondencia con una variable monitorizada en el entorno.
Controlled
Indica la correspondencia con una variable del entorno controlada por el elemento
del sistema.
148
MonitoredAndControlled
Indica la correspondencia con una variable del entorno que es a la vez monitorizada
y controlada por el elemento del sistema.
5.2.1.6.
Tipo de datos PropertyValue
Refleja de forma abstracta el valor que tomar una propiedad del sistema en cada instante dado, y que corresponder al tipo PropertyType sobre el que est definida la propiedad.
5.2.2. Vista de interaccin
La vista de interaccin se ha representado por medio de las siguientes clases y tipos de
datos:
InputInterface
InputOperation
InputCmd
OutputInterface
OutputOperation
Response
Notification
Alarm
Tipo de datos PriorityType
A continuacin describimos cada uno de estos elementos.
149
5.2.2.1.
Clase InputInterface
Descripcin
Esta clase representa las interfaces de entrada que implementan los elementos del sistema. Una interfaz de entrada define las operaciones de entrada (clase InputOperation) que
un elemento del sistema ofrece al frontend de operaciones.
Asociaciones
implemented by: SystemElement[1]
Elemento del sistema que implementa la interfaz.
inputoperations[1..*]
Operaciones de entrada al sistema que incluye la interfaz.
Atributos
No se definen atributos.
Restricciones
No se definen restricciones.
5.2.2.2. Clase InputOperation
Descripcin
Esta clase determina las operaciones de entrada incluidas en la interfaz de entrada que
implementa un elemento del sistema. Se han considerado nicamente como operaciones de
entrada, comandos de operacin que se definen por medio de la clase InputCmd.
Asociaciones
Propiedades perceptibles del elemento del sistema que implementa la interfaz a la
que pertenece la operacin.
150
Atributos
Restricciones
5.2.2.3.
Clase InputCmd
Descripcin
Esta clase representa los tipos de comandos de operacin que acepta un elemento del
sistema determinado, definidos en la interfaz de entrada que implementa el elemento. El
comando de entrada puede afectar a una o varias propiedades del elemento, o a ninguna.
Cuando el elemento del sistema ejecute un comando de entrada recibido podr generar una
respuesta si la especificacin del comando incluye un valor de retorno.
Asociaciones
response: Response[0..1]
Respuesta que puede ir asociada a un tipo de comando de entrada.
Atributos
Restricciones
5.2.2.4.
Clase OutputInterface
Descripcin
Esta clase representa las interfaces de salida que usan los elementos del sistema. Una
interfaz de salida define las operaciones de salida (clase OutputOperation) que el frontend
de operaciones ofrece al elemento del sistema.
151
Asociaciones
used by: SystemElement[1]
Elemento del sistema que usa la interfaz.
outputoperations: OutputOperation[1..*]
Operaciones de salida incluidas en la interfaz.
Atributos
Restricciones
5.2.2.5. Clase OutputOperation
Descripcin
Representa las salidas generadas desde los elementos del sistema. Recoge las respuestas
a comandos de entradas, las notificaciones y las alarmas.
Asociaciones
Propiedades del elemento del sistema que figuran en la operacin de salida que implementa el frontend de operaciones y usa el elemento del sistema.
Atributos
Restricciones
152
5.2.2.6.
Clase Response
Descripcin
Subclase de la clase OutputOperation que define las respuestas generadas por el sistema
al ejecutar los comandos de entrada. Una respuesta tiene siempre su origen en un nico
comando.
Asociaciones
command: InputCmd[1]
Comando de entrada al que corresponde la respuesta.
Atributos
Restricciones
Toda respuesta tiene que tener asociado un comando de entrada.
5.2.2.7.
Clase Notification
Descripcin
Subclase de la clase OutputOperation que representa las notificaciones que pueden producirse en los elementos del sistema como consecuencia de cambios de estado producidos
en las variables que monitoriza, y que no obedecen a la ejecucin de un comando de entrada
concreto.
Asociaciones
No se definen asociaciones.
Atributos
153
Restricciones
1. Una notificacin no puede ir asociada a una propiedad controlada (tipoControlled).
2. Una notificacin puede ir asociada a propiedades monitorizadas (tipo Monitored) o
bien monitorizadas y controladas (tipo MonitoredAndCrontrolled).
5.2.2.8. Clase Alarm
Descripcin
Subclase de la clase OutputOperation que define las alarmas que pueden producirse
desde los elementos del sistema como consecuencia de cambios de estado, de especial
atencin o prioritarios, producidos en las variables que monitoriza.
Asociaciones
No se definen asociaciones.
Atributos
priority: PrioritytType
Valor que expresa la prioridad de una alarma con respecto al resto de alarmas que se
definan.
Restricciones
5.2.2.9. Tipo de datos PriorityType
Refleja el tipo de datos con el que se definir la prioridad de una salida de tipo alarma
en un dominio de aplicacin especfico.
154
5.3.
Definicin de un perfil UML 2 de operaciones (U2OP)
El objetivo de esta seccin, es formalizar una nueva extensin de UML 2 por medio
de un perfil que permita definir de forma explcita, completa y uniforme los aspectos de
operaciones en el modelado de sistemas. Este nuevo perfil al que llamaremos U2OP (UML
2 Operations Profile) se define a partir del metamodelo de operaciones del sistema definido
anteriormente, y se muestra grficamente en la figura 24.
El perfil U2OP se define dentro de un paquete UML estereotipado como profile, y
viene determinado por los siguientes tres tipos de elementos:
1. Estereotipos (stereotypes) que definen nuevos elementos de construccin.
2. Valores etiquetados o propiedades (tagged values) que definen nuevas propiedades.
3. Restricciones (constraints) que definen nuevas semnticas.
Este perfil de UML se definir siguiendo parcialmente la propuesta de Villarroel [169]
de utilizar para la definicin de una extensin UML, un esquema compuesto por los siguientes elementos:
Descripcin
Prerrequisitos de la extensin
Nuevos tipos de datos
Estereotipos / valores etiquetados
5.3.1.
Descripcin
Esta extensin de UML define un conjunto de tipos de datos, estereotipos, valores etiquetados y restricciones que nos permiten modelar de una misma manera los aspectos de
operaciones de un sistema. El objetivo del perfil definido es poder modelar sistemas con
155
Figura 24: Perfil de operaciones del sistema (U2OP)
156
elementos interconectados que acepten algn tipo de interaccin desde el exterior. La modelizacin del sistema es esencial para poder crear un frontend de operaciones de acuerdo a
las lneas bsicas expuestas en esta tesis.
El perfil permite definir las caractersticas comunes de los sistemas para los que se defina un frontend de operaciones. El perfil incluye: un nuevo tipo de datos, dos estereotipos
que representan los elementos del sistema y las conexiones entre ellos, valores etiquetados para los dos estereotipos y un conjunto de restricciones que definen la semntica del
modelo.
La figura 25 muestra el perfil de operaciones del sistema, equivalente al de la figura 24,
pero en el que se han incluido adems las restricciones definidas para cada elemento del
perfil.
5.3.2. Prerrequisitos
La definicin del perfil de sistema no tiene prerrequisitos, salvo los implcitos derivados de la existencia del propio lenguaje de modelado UML 2, y que debe contemplar el
metamodelo SystemOperations definido en la seccin anterior.
5.3.3. Nuevos tipos de datos
El perfil aade tres nuevos tipos de datos que son utilizados en la definicin de valores
etiquetados de los estereotipos. Estos tipos corresponden a enumeraciones relativas al estado de los elementos del sistema, informacin de conexin y prioridad en las alarmas. Los
tres tipos definidos son:
ElementStatus
AccessPort
PriorityType
157
Figura 25: Perfil de operaciones del sistema (U2OP) con restricciones

158
5.3.3.1.
Enumeracin ElementStatus
Este nuevo tipo de datos corresponde a una enumeracin (clase base Enumeration) que
asociado a un elemento del sistema, indica el estado de interaccin en el que se encuentra.
Este estado, puede tomar uno de los siguientes valores:
active
El elemento est activo y listo para recibir operaciones y enviar notificaciones.
innactive
El elemento no est activo, no admite operaciones y tampoco puede enviar notificaciones.
noresponse
El elemento est en estado activo pero no responde al envo de operaciones.
locked
El elemento est activo pero bloqueado por un intervalo de tiempo que determina el
propio funcionamiento del sistema.
5.3.3.2.
Tipo de datos AccessPort
Este tipo de datos con clase base dataType representa la especificacin de los puertos
o interfaces fsicos que disponga un elemento de un sistema para establecer comunicacin
(sncrona y/o asncrona) con otros elementos o con el frontend de operaciones del sistema.
5.3.3.3.
Tipo de datos PriorityType
El tercer tipo de datos, definido tambin sobre la clase base dataType, representa la
forma de especificar las prioridades de las alarmas del sistema.
5.3.4. Estereotipos
Se han definido los siguientes estereotipos dentro del perfil U2OP:
159
1. U2OP_SystemElement
2. U2OP_VisibleRelation
3. U2OP_Monitored
4. U2OP_Controlled
5. U2OP_MonitoredAndControlled
6. U2OP_Input
7. U2OP_Output
8. U2OP_InputCmd
9. U2OP_Response
10. U2OP_Notification
11. U2OP_Alarm
5.3.4.1. Estereotipo U2OP_S ystemElement
Descripcin
Definido sobre la metaclase Class, representa un elemento del sistema con capacidad de
interaccin desde el frontend de operaciones.
Valores etiquetados
Para este estereotipo se han definido los siguientes valores etiquetados:
status: StatusElement[1]
Este valor etiquetado, definido con el tipo enumerado ElementStatus, permitir saber
en que estado de comunicacin se encuentra un elemento del sistema en un momento
dado.
160
access: AccessPort[0..*]
Definido como tipo de datos AccessPort, representa los puertos o interfaces de comunicacin que permiten la interaccin del elemento desde el exterior. La cardinalidad
mnima 0 indica sistemas en los que no sea necesario establecer una comunicacin
con el frontend de operaciones, por ejemplo, sistemas software con acceso desde el
frontend en modo local. La cardinalidad mxima * indica la existencia de diferentes
interfaces de comunicacin hacia el exterior del sistema.
Restricciones
Se han definido las siguientes restricciones:
Un elemento estereotipado SystemElement no puede implementar interfaces estereotipadas U2OP_Output.
5.3.4.2.
Estereotipo U2OP_VisibleRelation
Descripcin
Este estereotipo permite representar interconexiones entre los diferentes elementos que
compongan un sistema.
Valores Etiquetados
Para este estereotipo no se han definido valores etiquetados.
Restricciones
Una asociacin estereotipada visible:
Asocia nicamente elementos del sistema estereotipados U2OP_SystemElement.
No puede asociar un elemento consigo mismo.
161
Para conectar dos elementos entre s, el estado de ambos debe ser activo. Aunque en
realidad no es de aplicacin desde el punto de vista topolgico o de estructura sino
desde el punto de vista de operacin.
5.3.4.3. Estereotipo U2OP_Monitored
Descripcin
Representa una propiedad monitorizada por un elemento del sistema, es decir, de la que
se pueda obtener el valor que tenga en un instante dado pero no modificar su estado.
Valores Etiquetados
Se han definido los siguientes valores etiquetados:
input: U2OP_InputCmd[0..*]
Comandos de entrada asociados a la propiedad.
output: U2OP_Notification[1..*]
Notificaciones que reflejan cambios en los valores de las propiedades monitorizadas.
Restricciones
Una propiedad estereotipada Monitored:
No puede tener asociada una operacin estereotipada Input que modifique su estado.
Pertenece obligatoriamente a un elemento estereotipado SystemElement.
5.3.4.4.
Estereotipo U2OP_Controlled
Descripcin
Representa una propiedad controlada por un elemento del sistema, es decir, sobre la que
se pueda modificar su estado.
162
Valores Etiquetados
Se ha definido el siguiente valor etiquetado:
Comandos de entrada asociados a la propiedad, al menos debe haber uno, ya que es
una propiedad controlada por el sistema.
Restricciones
Una propiedad estereotipada Controlled:
No puede tener asociada una operacin de salida estereotipada Notification o Alarm.
5.3.4.5.
Estereotipo U2OP_MonitoredAndControlled
Descripcin
Representa una propiedad que sea al mismo tiempo monitorizada y controlada por un
elemento del sistema, es decir, de la que pueda obtener el valor que tenga en un instante
dado y tambin modificar su estado.
Valores Etiquetados
Las propiedades definidas con este estereotipo incluyen los siguientes valores etiquetados:
Comandos de entrada asociados a la propiedad.
output: U2OP_Notification[1..*]
Notificaciones que reflejan cambios en los valores de las propiedades monitorizadas
y/o controladas.
163
Restricciones
Una propiedad estereotipada MonitoredAndControlled:
5.3.4.6.
Estereotipo U2OP_Input
Descripcin
Representa una interfaz implementada por un elemento del sistema, e incluir el conjunto
de operaciones admitidas por el elemento.
Valores Etiquetados
No se han definido valores etiquetados para este estereotipo.
Restricciones
Una interfaz estereotipada U2OP_Input no puede ser implementada por un elemento que
no est estereotipado como SystemElement.
5.3.4.7.
Estereotipo U2OP_Output
Descripcin
Representa una interfaz utilizada por el sistema para enviar las salidas hacia el frontend de operaciones, siendo el frontend de operaciones el encargado de implementar las
operaciones que pueda contener.
Valores Etiquetados
Restricciones
Una interfaz estereotipada U2OP_Output :
No puede ser implementada por un elemento estereotipado SystemElement, existiendo nicamente una relacin de uso.
164
5.3.4.8.
Estereotipo U2OP_InputCmd
Descripcin
Representa una de las operaciones de entrada incluidas en la interfaz de entrada implementada por un elemento del sistema.
Valores Etiquetados
output: U2OP_Response
Respuesta asociada a una operacin InputCmd de entrada al sistema.
Restricciones
Una operacin estereotipada U2OP_InputCmd:
Solo puede pertenecer a una interfaz estereotipada U2OP_Input.
Incluir como parmetro una propiedad estereotipada U2OP_Monitored o bien estereotipada U2OP_Controlled o U2OP_MonitoredAndCrontolled, que pertenecer al
elemento que implemente la interfaz a la que pertenezca la operacin.
5.3.4.9. Estereotipo U2OP_Response
Descripcin
Representa la respuesta devuelta por el sistema al ejecutar una operacin de entrada
U2OP_InputCmd.
Valores Etiquetados
input: U2OP_InputCmd[1]
Comando de entrada al sistema asociado a la respuesta.
165
Restricciones
Una operacin estereotipada U2OP_Response:
Solo puede pertenecer a una interfaz estereotipada U2OP_Output.
5.3.4.10.
Estereotipo U2OP_Noti f ication
Descripcin
Representa una notificacin enviada por el sistema como consecuencia del cambio de
estado producido en una propiedad monitorizada por el elemento.
Valores Etiquetados
Restricciones
Una operacin estereotipada U2OP_Notification:
Incluir como parmetro una propiedad estereotipada como U2OP_Monitored o bien U2OP_MonitoredAndCrontolled, que pertenecer al elemento que implemente la
interfaz a la que pertenezca la operacin.
5.3.4.11.
Estereotipo U2OP_Alarm
Descripcin
Representa una notificacin especial o alarma enviada por el sistema como consecuencia
del cambio de estado producido en una propiedad monitorizada por el elemento.
Valores Etiquetados
Se han definido los siguientes valores etiquetados:
priority: PriorityType
Prioridad que se asigna a la alarma.
166
Restricciones
Una operacin estereotipada U2OP_Alarm:
Incluir como parmetro una propiedad estereotipada como U2OP_Monitored o bien U2OP_MonitoredAndCrontolled, que pertenecer al elemento que implemente la
interfaz a la que pertenezca la operacin.

Este captulo presenta una propuesta de representacin del modelo de operaciones de
un sistema. Se ha definido un metamodelo que conceptualiza el modelo de operaciones de
un sistema basado en la definicin de sistema operable.
El metamodelo de operaciones del sistema, SystemOperationsMetamodel, se ha definido
utilizando el lenguaje UML. Tomando como base este metamodelo se ha definido una extensin de UML en forma de perfil que permite incorporar las operaciones en el modelado
de un sistema, al que se ha llamado UML 2 Operations Profile, U2OP.
167
168
Captulo VI
APLICACIN DEL MODELO DE OPERACIONES DEL
SISTEMA COMO SOPORTE PARA EL MODELADO
DEL FRONTEND DE OPERACIONES
Un profesor trabaja para la eternidad:

nadie puede decir dnde acaba su influencia.
Henry Brooks Adams
169
6.1. Introduccin
En el captulo anterior se han definido un metamodelo y un perfil UML 2 que facilitan la
representacin del modelo de operaciones definido en esta Tesis. Tomando como base estas
propuestas de representacin del modelo de operaciones de un sistema, en este captulo
se plantea el modelado de un frontend de operaciones que posibilite la interaccin entre
operador y sistema.
Primeramente se presenta un metamodelo UML 2 orientado al modelado de la interaccin entre un frontend de operaciones y el sistema, basado en el modelo de operaciones
definido. A continuacin, se propone una arquitectura del frontend de operaciones basada en una serie de niveles de abstraccin en la interaccin entre operador y sistema. Y
por ltimo, se incluye una propuesta de comandos bsicos de operacin del sistema que
implementados por un frontend de operaciones faciliten la interaccin con el sistema.
6.2. Metamodelo de frontend de operaciones del sistema

El perfil U2OP definido en el captulo anterior facilita la representacin del modelo de
operaciones de un sistema mediante el lenguaje UML. Este perfil permite decorar el diagrama de clases de un sistema, estereotipando los elementos que lo componen, las propiedades
perceptibles desde el exterior, y las operaciones de entrada y de salida definidas en las interfaces con el frontend de operaciones. El perfil U2OP no incluye ninguna referencia al
frontend de operaciones salvo la relativa a las operaciones que definen las interfaces entre
sistema y frontend de operaciones. Esto es as, porque para un sistema podran definirse
diferentes aplicaciones externas o frontend de aplicaciones.
Se ha definido un metamodelo UML 2, OperationsFrontend Metamodel, representado
en la figura 26 basndose en el metamodelo SystemOperationsMetamodel definido en el
captulo anterior. Este nuevo metamodelo pretende servir de apoyo al modelado del frontend de operaciones aplicado a dominios de sistemas especficos. Este metamodelo al que
se ha llamado OperationsFrontend refleja:
170
Figura 26: Metamodelo de frontend de operaciones (OperationsFrontend Metamodel)

171
El frontend de operaciones que facilita la interaccin entre el operador y el sistema.

El sistema bajo operacin.
Las interfaces definidas en el sistema y en el frontend de operaciones que hacen
posible la interaccin entre ambos.
A continuacin describiremos las clases que componen cada uno de estos componentes que
comprenden el metamodelo.
1. El frontend de operaciones del sistema, se ha representado con las siguientes clases:
Operator. Operadores del frontend de operaciones caracterizados con los diferentes roles de interaccin con el sistema.
SOF. El frontend de operaciones en s.
SystemView. Vista o vistas del sistema ofrecidas por el frontend. Si existen diferentes roles de operador, stos pueden utilizar diferentes vistas del sistema.
SystemElement. Representacin de los elementos que componen el sistema.
Procedure. Procedimientos compuestos por una serie de comandos de entrada
al sistema. Se considera que el operador interactuar con el sistema mediante
el lanzamiento o ejecucin de procedimientos de operaciones que contemplen
una funcin concreta como conjunto.
ProcedureExecution. Informacin relativa a la ejecucin de un procedimiento
concreto compuesto de comandos de entrada al sistema.
CommandExecution. Comandos de entrada enviados a un elemento del sistema.
2. El sistema bajo operacin o sistema operable, al que abreviadamente llamaremos
SUO (System Under Operation) se ha representado por la clase:
SystemElement. Conjunto de elementos que comprenden el sistema bajo operacin.
172
En este metamodelo el SUO se representa nicamente con esta clase puesto que
pertenece al metamodelo SystemOperationsMetamodel descrito en el captulo anterior.
3. Las interfaces asociadas a la interaccin entre frontend de operaciones y sistema:
InputInterface. Interfaces de entrada que implementan los elementos del sistema para recibir entradas desde el frontend de operaciones.
OutputInterface. Interface de salida que usan los elementos del sistema para
enviar las salidas que produce al frontend de operaciones del sistema, y que
debe ser implementado por ste.
Adems, se han definido los siguientes tipos de datos:
Tipo de datos Identifier. Representa un tipo de datos que identifique de forma nica
los objetos de una clase.
Enumeracin ExecutionResult. Valores que indican si un comando de operacin se
ha llevado con xito o no por parte del sistema.
A continuacin se describen cada una de estas clases y tipos de datos, de forma anloga
a como se ha definido el metamodelo de operaciones del sistema en el captulo anterior, y
que coincide con el mtodo utilizado por OMG para definir el perfil U2TP [130]. En este
caso adems se ha incluido la descripcin de mtodos de las clases:
Descripcin
Asociaciones
Atributos
Mtodos
Restricciones
173
6.2.1. Frontend de operaciones

Representa las clases que corresponden a los componentes que intervienen en la interaccin entre operador y sistema por medio del frontend de operaciones. Comprende las
siguientes clases:
6.2.1.1. Clase SOF
Descripcin
Esta clase representa la interfaz software mediante la cual los operadores interactan
con el SUO. Dispondr de algn tipo de interfaz de usuario, normalmente grfica, que
permita a diferentes operadores interactuar con el sistema. SOF presentar al operador una
vista del sistema con la que est interactuando. Esta vista podr incluir todos los elementos
que componen el sistema o un subconjunto de ste, en funcin de las caractersticas de
los roles de operacin definidos. Consideramos que un SOF pueda tener dos modos de
funcionamiento distintos: modo operacin y modo test. El primero permitir la operacin
y monitorizacin del sistema, y el segundo servir de apoyo en la validacin del sistema.
Asociaciones
operators: Operator[0..*]
Operadores que utilizan el SOF para interactuar con el sistema, incluyendo diferentes
roles o tipos de operacin: operador, administrador, ingeniero de pruebas, etc.
views: SystemView[1..*]
Vistas del sistema bajo operacin que visualizar el frontend de operaciones para
cada rol y/u operador del SOF. Una vista del sistema incluir al menos un elemento
del mismo.
iinterfaces: SystemOperationsMetamodel::InputInterface[1..*]
Interfaz o interfaces que usa SOF y que implementa el sistema o sus elementos para
174
recibir comandos de entrada enviados desde el SOF. La interfaz incluir todas las
operaciones que correspondan a las entradas aceptadas por el sistema o elementos de
este.
ointerfaces: SystemOperationsMetamodel::OutputInterface[1..*]
Interfaz o interfaces implementadas por SOF y que usan los elementos del sistema
para enviarle las salidas que producen. La interfaz incluir todos los mtodos u operaciones que correspondan a las salidas de los elementos del sistema.
procedures: OperationsProcedure[0..*]
Procedimientos de operacin creados para ser ejecutados sobre el SUO, y que son
registrados junto con los resultados de sus ejecuciones en el repositorio del SOF.
Atributos
name: String
Nombre dado al frontend de operaciones.
description: String
Descripcin del frontend de operaciones.
mode: String
Modo en el que el frontend de operaciones acta con el sistema (modo test o modo
operacin).
accessport: SystemOperationsMetamodel:AccessPort
Informacin de acceso al SOF con la que establecer la comunicacin desde el sistema. Esta propiedad est definida sobre el tipo de datos AccessPort incluido en el
metamodelo SystemOperationsMetamodel.
175
Mtodos
Si bien en la definicin de un metamodelo no es habitual incluir mtodos en las clases
que lo definen, en este caso, se han incluidos algunos mtodos de la clase SOF, para orientar
cul sera la funcionalidad mnima que debera tener.
setMode (mode: String)
Activa el modo de funcionamiento del frontend de operaciones con el sistema, en
modo operacin o en modo test.
createProcedure (proc: OperationsProcedure)
Creacin de un procedimiento con comandos de operacin del sistema.
compileProcedure (proc: OperationsProcedure)
Compilar un procedimiento de comandos, conforme a la gramtica definida para el
dominio de aplicacin concreto del sistema bajo operacin.
executeProcedure (proc: OperationsProcedure)
Ejecutar un procedimiento de comandos sobre el SUO.
executeCommand (cmd: CommandExecution)
Enviar (ejecutar) un comando de operacin sobre el SUO.
updateSystemView()
Actualizar la vista de interaccin a partir de la informacin recibida desde el SUO
(cambios de estado en los elementos del sistema).
updateRepository()
Actualizar el repositorio del SOF a partir de la informacin recibida desde el SUO
(respuestas a comandos de operacin y/o notificaciones enviadas).
configureSUO()
Configurar la vista de elementos del sistema visible/accesible a un operador o rol
concreto.
176
Restricciones
Si modo = test, la interaccin con el SUO podr ser nicamente de validacin. Si
modo = operacion, la interaccin podr ser operacin y/o monitorizacin del SUO.
SOF puede interactuar con diferentes sistemas bajo operacin, por ejemplo un simulador del sistema o el sistema real, pero solo puede interactuar con uno al mismo
tiempo. As pues, en tiempo de ejecucin, estar asociado con un solo SUO. Por el
contrario, s puede haber ms de un operador trabajando con una misma instancia del
SOF.
6.2.1.2.
Clase Operator
Descripcin
El frontend de operaciones representa un medio mediante el cul un operador puede
interactuar con un sistema. Definimos esta clase para que quede clara la participacin de
un operador en el proceso de interaccin con un sistema.
Asociaciones
sof: SOF[1..*]
Frontend de operaciones, uno o varios, utilizados por un operador.
Atributos
name: String
Nombre del operador.
role: String
Rol del operacin, por ejemplo: operador, probador, administrador, etc.
Mtodos
No se han definido mtodos.
177
Restricciones
Se ha identificado una nica restriccin:
Un operador puede interactuar con el sistema en modo operacin y en modo validacin, pero no puede trabajar al mismo tiempo en los dos modos.
6.2.1.3. Clase SystemView
Descripcin
Vista o vistas del SUO ofrecidas por el frontend a los operadores. Si existen diferentes
roles de operacin en el SOF, stos pueden utilizar diferentes vistas del sistema. Una vista
del sistema incluir al menos un elemento del sistema.
Asociaciones
sof: SOF[1]
Objeto de la clase SOF a la que corresponde un objeto de la clase SystemView.
elements: SystemOperationsMetamodel:SystemElement[1..*]
Elementos del sistema que componen la vista de operador.
Atributos
id: Identifier
Identificador nico de la vista del sistema.
operator: Operator[0..*]
Operadores al que el SOF presenta la vista del sistema.
Mtodos
178
Restricciones
No se han definido restricciones.
6.2.1.4.
Clase OperationsProcedure
Descripcin
Esta clase describe el contenido de un procedimiento de operaciones, creado por un
operador concreto. Un mismo procedimiento puede ejecutarse varias veces.
Asociaciones
executions: ProcedureExecution [0..*]
Conjunto de ejecuciones realizadas sobre el sistema, correspondientes a un mismo
procedimiento.
sof: SOF[1]
Frontend de operaciones desde el que se crea el procedimiento de operaciones del
sistema.
Atributos
id: Identifier
Identificador dado a cada procedimiento de operacin, que debe ser nico.
creator: Operator
Operador que crea el procedimiento.
creationdate: date
Fecha y hora de creacin del procedimiento.
content: SystemOperationsMetamodel:: InputOperation[1..*]
Secuencia de operaciones de entrada al SUO incluidas en el procedimiento de operaciones. Corresponde a un conjunto de objetos de la clase InputOperation definida
179
previamente en el metamodelo SystemOperations.

Mtodos
Restricciones
No se han definido restricciones.
6.2.1.5. Clase ProcedureExecution
Descripcin
Esta clase representa las diferentes ejecuciones de los procedimientos de operaciones
creados. Un mismo procedimiento puede ejecutarse varias veces.
Asociaciones
procedure: OperationsProcedure[1]
Procedimiento al que corresponde la ejecucin.
commands: CommandExecution[1..*]
Conjunto de comandos del procedimiento.
Atributos
operador: Operator
Operador que realiza la ejecucin del procedimiento.
executiondate: date
Instante en el que se lanza la ejecucin del procedimiento.
result: SystemOperationsMetamodel::OutputOperation[0..*]
Conjunto de resultados obtenidos al ejecutar el procedimiento. Corresponde a un conjunto de objetos de la clase OutputOperation definida previamente en el metamodelo
180
SystemOperations.
Mtodos
Restricciones
Una ejecucin de un procedimiento ser nica, y corresponder a un nico procedimiento de operacin.
Se considera que no existe concurrencia en la ejecucin de procedimientos. Al mismo
tiempo, solo puede estar un procedimiento en ejecucin.
6.2.1.6.
Clase CommandExecution
Descripcin
Comandos de operacin enviados al sistema desde el frontend de operaciones.
Asociaciones
element: Element[1]
Elemento del sistema sobre el que se ejecuta el comando.
procedure: ExecutionProcedure[0..1]
Procedimiento del que procede el comando ejecutado.
Atributos
commandexecutionid: Identifier
Identificador nico por comando ejecutado.
command: SystemOperationsMetamodel::InputCmd
El comando de entrada al elemento del sistema.
181
executiondate: date
Instante de tiempo en el que se ejecuta el comando en el sistema.
executionresult: ExecutionResult
Tipo de resultado al ejecutar el comando. El conjunto de valores posibles de este
atributo viene definido por el conjunto enumerado ExecutionResult: ok, nook, noresponse.
response: SystemOperationsMetamodel::Response
Respuesta enviada por el sistema como consecuencia de ejecutar el comando de entrada. Corresponde a un objeto de la clase Response definida previamente en el metamodelo SystemOperations.
Mtodos
Restricciones
Un comando de operacin enviado al sistema proceder de un procedimiento concreto.
El resultado producido al ejecutar un comando de operacin debe corresponder a uno
de los valores definidos en el conjunto enumerado ExecutionResult.
6.2.2. Sistema bajo operacin
El frontend de operaciones presentar una vista del SUO que muestre al operador la
composicin del sistema, as como las propiedades e inter-relaciones perceptibles de cada
elemento del sistema. Una vista del sistema puede comprender el sistema completo con
todos sus elementos o bien un subconjunto de ste. El SOF determinar la composicin de
la vista del sistema y de las operaciones que pueda realizar, en funcin de cada uno de los
roles de operacin definidos. SOF podra gestionar diferentes vistas del sistema al mismo
182
tiempo, permitiendo que varios operadores puedan estar monitorizando el sistema o incluso
realizando operaciones compatibles sobre l.
6.2.2.1.
Clase SystemElement
Descripcin
Con esta clase se ha representado el sistema bajo operacin (SUO) de forma completa,
abstrayndonos del resto de informacin, ya que se importa la clase SystemElement del
metamodelo SystemOperationsMetamodel definido previamente en el captulo anterior.
Asociaciones
iinterfaces: SystemOperationsMetamodel::InputInterface[1..*]
Interfaces implementados por los elementos del sistema y que usa el frontend de
operaciones para enviarles comandos de entrada. Estas interfaces incluirn todas las
operaciones relativas a las entradas aceptadas por los elementos del sistema. Corresponden a un conjunto de objetos de la clase InputInterface definida previamente en
el metamodelo SystemOperations.
ointerfaces: SystemOperationsMetamodel::OutputInterface[1..*]
Interfaces que usa el sistema y que implementa el SOF para recibir las salidas generadas por el sistema. Incluirn todas las operaciones que correspondan a las salidas
de los elementos del sistema, y se definen como un conjunto de objetos de la clase
OutputInterface definida previamente en el metamodelo SystemOperations.
views: SystemView[0..*]
Vistas del sistema definidas en el frontend de operaciones que incluyen los elementos
del sistema.
Atributos
183
id: SystemOperationsMetamodel::Identifier
Identificador nico del sistema.
access: SystemOperationsMetamodel::AccessPort[1..*]
Informacin de acceso al sistema con la que establecer la interaccin desde el frontend de operaciones. Cada elemento del sistema definir el conjunto de puertos de
acceso que le permitan establecer la comunicacin con el frontend de operaciones.
status: SystemOperationsMetamodel::ElementStatus
Estado del elemento en un momento dado desde el punto de vista de interaccin,
representado por la enumeracin ElementStatus.
Mtodos
Restricciones
No se han definido.
6.2.3. Operaciones sobre el sistema
Comprende las interfaces que permiten la interaccin entre el sistema y el frontend de
operaciones, y que ya han sido definidas en el metamodelo SystemOperationsMetamodel.
6.2.3.1.
Interfaz InputInterface
Descripcin
Interfaz que usa SOF y que implementa el sistema para recibir comandos de entrada
enviados desde SOF. La interfaz incluir todas las operaciones que correspondan a las
entradas aceptadas por el sistema.
Asociaciones
184
elements: SystemOperationsMetamodel::SystemElement[1..*]
Elementos del sistema que implementan la interfaz.
sof: SOF[0..*]
Aplicaciones externas, como el frontend de operaciones, que utilizan la interfaz.
Atributos
La definicin de una interfaz no incluye atributos.
Mtodos
Ser en la implementacin de un dominio de sistema especfico, donde figuren las operaciones que acepte el sistema.
Restricciones
No se han definido.
6.2.3.2.
Interfaz OutputInterface
Descripcin
Interfaces implementadas por aplicaciones externas al sistema, como el frontend de operaciones, y que usa el sistema para enviarles las salidas que produce. La interfaz incluir
todas las operaciones que correspondan a las salidas de los elementos del sistema.
Asociaciones
elements: SystemOperationsMetamodel::SystemElement[0..*]
El sistema usa las interfaces implementadas por las aplicaciones externas para enviarles las salidas que genera.
sof: SOF[1..*]
Las aplicaciones externas al sistema, que implementan las interfaces de salida de los
elementos del sistema.
185
Atributos
La definicin de una interfaz no incluye atributos.
Mtodos
Ser en la implementacin del frontend de operaciones para un dominio de sistema especfico, donde figuren las operaciones que acepte el frontend de operaciones.
Restricciones
No se han definido.
6.2.4. Tipos de Datos
6.2.4.1. Tipo de datos Identifier
Tipo de datos que indica la identificacin de forma nica de los objetos de una clase.
6.2.4.2. Tipo de datos ExecutionResult
Enumeracin con los valores que representan si un comando se ha llevado con xito por
parte del sistema:
ok
nook
noresponse
6.3. Arquitectura conceptual de un frontend de operaciones

del sistema
En la seccin anterior hemos definido un metamodelo UML para representar un frontend de operaciones basado en el modelo de operaciones del sistema. Describiremos ahora,
la arquitectura conceptual del frontend de operaciones de un sistema. Para ello utilizaremos
cinco niveles de abstraccin:
186
1. Interaccin operador-sistema
2. Interaccin SOF-sistema
3. Comunicacin SOF-sistema
4. GUI orientado al operador del sistema
5. Ncleo del SOF
Figura 27: Nivel 1. Interaccin operador-sistema
6.3.1. Nivel 1: Interaccin operador-sistema

En el nivel ms alto de abstraccin tenemos la interaccin entre el operador de un
sistema y el sistema, planteada en trminos de entradas y salidas. El operador enva una
serie de entradas o estmulos al sistema y ste retorna al operador una serie de respuestas o
salidas en funcin de las entradas recibidas. La figura 27 muestra esta interaccin entre un
operador y el sistema.
El planteamiento del modelo de operaciones de un sistema realizado en esta tesis se
fundamenta precisamente en esta simplificacin de la interaccin entre operador y sistema.
El sistema recibe una serie de entradas y genera una serie de salidas. Por tanto, el modelo
de operaciones en este nivel de abstraccin describir el conjunto de operaciones aceptadas
por el sistema y el conjunto de respuestas y notificaciones generadas por ste.
187
6.3.2. Nivel 2: Interaccin SOF-Sistema

El siguiente nivel de abstraccin en la interaccin operador-sistema nos conduce a la
existencia de algn medio externo al sistema que acte como interfaz con el operador,
facilitando la interaccin entre el operador y el sistema. Distinguiremos varios casos en
funcin de cmo se produce la interaccin entre un operador y el sistema:
1. El sistema dispone de algn tipo de interfaz fsica de control que permite establecer
la interaccin con el operador, como puede ser un panel de control. Por ejemplo un
telfono mvil incluye en el propio dispositivo fsico la interfaz con el operador.
2. El sistema dispone de alguna interfaz de control incorporada que permita al operador
interactuar directamente con el sistema, y adems dispone de algn tipo de interfaz
software que permita una operacin remota. Por ejemplo, un sistema software que
disponga de su propia interfaz grfica de usuario para interaccionar con el operador,
y que tambin disponga de una interfaz software que admita interaccin con otros sistemas. Un gestor de bases de datos se enmarcara dentro de este tipo de sistemas, ya
que dispone de interfaces grficas de usuario para su manejo u operacin, y al tiempo
acepta peticiones de sistemas externos por medio de una interfaz de tipo software.
3. El sistema no dispone de ningn tipo de interfaz de control que permita una interaccin directa con el operador. Por ejemplo, un satlite en rbita no dispone de ninguna
interfaz de tipo fsica que permita la interaccin con un operador. La interfaz es
necesariamente software y orientada a comandos. Los comandos son enviados desde
la plataforma terrestre y en sta se recibe el conjunto de mensajes enviados por el
satlite. Ambos sistemas, el satlite y la plataforma terrestre, disponen de interfaces
software que se encargan de llevar a cabo la interaccin entre ambos.
En este segundo nivel de abstraccin en la interaccin operador-sistema incluimos un
frontend de operaciones del sistema como medio externo al sistema, tal y como se muestra en la figura 28. El frontend de operaciones acta como interfaz entre el operador y el
188
Figura 28: Nivel 2. Interaccin SOF-sistema

sistema, facilitando la interaccin entre ambos. Esta interaccin se basa en la existencia de
dos componentes:
1. Frontend de operaciones del sistema (SOF). En el apartado 3.3.2 ubicado en la pgina 101, hemos definido el frontend de operaciones de un sistema como un medio
compuesto de hardware y software que posibilita la interaccin entre el operador y
el sistema, facilitando al operador la operacin y monitorizacin de ste.
2. Interfaz de operacin incluida en el sistema, Operation Interfaz (OI). El sistema ha
de disponer de una interfaz software que permita la interaccin con el exterior. La
interfaz de operacin de un sistema, definida en el apartado 3.2.3.2 (pgina 88) representa el conjunto de comandos u operaciones que permite la interaccin de un
sistema con un frontend de operaciones.
La utilizacin del modelo de operaciones en el proceso de desarrollo de un sistema, por
un lado facilitar la creacin de la interfaz de operacin del mismo, y por otro lado ser de
gran ayuda para construir el frontend de operaciones del sistema.
6.3.3. Nivel 3: Comunicacin SOF-Sistema
El tercer nivel de abstraccin contempla la comunicacin entre el sistema y el frontend
de operaciones, mostrada en la figura 29. Para que sea posible la comunicacin entre el
frontend de operaciones y el sistema, hemos ubicado un componente en el frontend de
189
Figura 29: Nivel 3. Gateway

operaciones que haga de intermediario en la comunicacin entre ambos, al que llamamos
Gateway. As pues, este componente facilitar la comunicacin entre los dos niveles de
abstraccin existentes entre el operador y el sistema. El Gateway, relacionndose con el
Interfaz de Operacin del sistema, servir de puerta de entrada al sistema, y tambin de
puerta de salida, tal y como se muestra en la figura 29.
El protocolo, medio y forma de comunicacin entre Gateway y sistema, depender de
la implementacin de cada dominio de aplicacin en particular. No obstante, de manera
genrica se pueden establecer dos tipos de comunicacin entre ambos:
Sncrona. El envo de un comando de operacin desde el frontend de operaciones al
sistema, requiere de cierta sincrona entre ambos, de manera que el frontend de operaciones pueda identificar claramente la respuesta enviada por el sistema al comando
enviado.
Asncrona. Las salidas de tipo notificacin o alarma generadas por el sistema vendrn marcadas por una comunicacin asncrona con origen en el sistema y destino el
6.3.4. Nivel 4: GUI orientado al operador del sistema
El cuarto nivel de la arquitectura de un frontend de operaciones, representado en la
figura 30, separa la interfaz de usuario del ncleo del frontend de operaciones. Consideraremos que la interfaz de usuario ser generalmente de tipo grfica, si bien podra tenerse
una interfaz de usuario de otro tipo.
190
Figura 30: Nivel 4. GUI orientado al operador del sistema

La interfaz grfica de usuario (GUI) del frontend de operaciones tendr un nivel de
representacin del sistema lo suficientemente completo para que cualquier tipo de operador
pueda operar e interpretar el estado del sistema:
1. Presentar al operador una vista del sistema, en la que se reconozcan fcilmente los
elementos, las propiedades y las relaciones perceptibles que compongan el sistema,
y el estado en el que se encuentren en un momento dado.
2. Adems, el operador necesitar un lenguaje de interaccin que le permita operar y
monitorizar el sistema de la forma ms simple posible. Dicho lenguaje incorporar
un conjunto de comandos que soporten las operaciones aceptadas por el sistema.
La existencia de estos dos aspectos, vista y lenguaje, en la relacin entre el frontend
de operaciones y el sistema facilitar enormemente la operacin y monitorizacin de un
sistema.
El componente que aparece en la figura 30 como kernel representa el ncleo del frontend de operaciones del sistema, y ser descrito a continuacin.
6.3.5. Nivel 5: Componentes del SOF
Este es el ltimo nivel de representacin de la arquitectura de un SOF. La arquitectura
propuesta del frontend de operaciones, representada en la parte central de la figura 31,
comprende los siguientes componentes:
191
Figura 31: Nivel 5. Componentes del SOF

GUI, constituye la interfaz grfica de usuario mediante la cual el operador del sistema visualiza el estado del SUO en cada momento (bien mediante notificaciones
llegadas desde el sistema o bien como respuesta a comandos de operacin enviados
al sistema). Adems soporta el envo de comandos de operacin al sistema.
Frontend Engine, es el ncleo del SOF, encargado de la compilacin y generacin
de comandos de operacin a enviar al sistema a travs del Gateway. Soporta por
tanto, el control de ejecucin de las operaciones sobre el sistema, e interacciona
con el operador a travs de la GUI y con el sistema a travs del Gateway. Accede
y actualiza la informacin del repositorio de datos relativa a las operaciones y a la
monitorizacin del sistema
Data Manager, gestor del repositorio de datos, contiene los datos y las reglas de
negocio definidas para gestionar los datos de las operaciones y monitorizaciones realizadas sobre el sistema.
Gateway, que se encarga de la comunicacin entre SUO y SOF.
192
La arquitectura del SOF planteada es independiente del sistema con el que vaya a interactuar el frontend de operaciones en un dominio de aplicacin especfico. Esta independencia del dominio del sistema permitir una adaptacin del frontend de operaciones
a diferentes sistemas con un esfuerzo reducido. Por otra parte la arquitectura presentada
permite que los cuatro componentes identificados puedan estar distribuidos en diferentes
mquinas, facilitando la tele-operacin/ tele-monitorizacin del sistema.
6.3.6. Esquema de funcionamiento del SOF
En el metamodelo que refleja la interaccin entre el frontend de operaciones y el sistema, se ha definido la clase Procedure con un atributo content: Commands[..*]. Se
ha considerado que el operador enva las operaciones al sistema mediante procedimientos
compuestos de varios comandos de operacin, al menos uno. Siendo necesaria la existencia
de un lenguaje de operaciones especfico que defina el conjunto de operaciones que el operador pueda utilizar para interactuar con un sistema concreto. En principio, este lenguaje
ser dependiente del dominio de aplicacin, es decir, del sistema bajo operacin.
Los comandos de operacin incluidos en un procedimiento deben ser consistentes con
la gramtica del lenguaje de operaciones definido para interactuar con el sistema. Los comandos para obtener y asignar valores de propiedades de los elementos de un sistema
genrico podran seguir el siguiente patrn:
Obtener el estado o valor de propiedades monitorizadas de los elementos del sistema:
Sintaxis: GET <elementId><property>
Semntica: property tiene que corresponder a una propiedad monitorizada de
un elemento elementID existente en el sistema.
Asignar valores a variables controladas de los elementos del sistema:
Sintaxis: SET <elementId><property><value>
193
Semntica: property tiene que corresponder a una propiedad controlada de un

elemento elementID existente en el sistema, y value debe ser un valor perteneciente
al dominio de valores definido para property.
El operador, utilizando la GUI del frontend de operaciones, crear, compilar, ejecutar
los procedimientos de operacin y observar los resultados y notificaciones producidas en
el sistema. El componente Engine ser el encargado de compilar, lanzar y controlar la
ejecucin de los comandos de operacin por medio del Gateway, recibir las notificaciones
enviadas desde el sistema a travs del Gateway, y de almacenar los datos en el repositorio.
El componente Engine ejecutar una a una las operaciones incluidas en el procedimiento en el sistema por medio del componente Gateway. El Gateway enviar al sistema
el comando y devolver al Engine la respuesta de la ejecucin recibida del sistema. Esta
respuesta se almacenar en la base de datos, y se enviar a la GUI para que muestre al
operador los resultados. El sistema puede generar notificaciones y alarmas no dependientes
de un comando concreto, que sern enviadas tambin al Engine por medio del Gateway,
para almacenarlas en la base de datos y a la GUI para su visualizacin en la interfaz grfica de usuario. As, todos los resultados (respuestas a comandos y notificaciones enviadas
por el sistema) que se produzcan en el sistema durante la ejecucin de las operaciones se
almacenarn en el repositorio.
6.4. Comandos bsicos de operacin de un sistema

El metamodelo y la arquitectura presentadas en las secciones anteriores, basados en el
modelo de operaciones del sistema definido en este trabajo, incluyen la relacin existente
de entradas y salidas entre el sistema y el frontend de operaciones. Las entradas al sistema
se han representado en forma de procedimientos de operaciones y comandos de operacin,
y las salidas del sistema como respuestas a los comandos de operacin y notificaciones
generadas en el sistema.
194
En este apartado se propone un conjunto de comandos bsicos de operacin que permite el entendimiento entre el frontend de operaciones y el sistema. La descripcin de este
conjunto ser lo suficientemente genrica para que pueda ser de aplicacin en diferentes
sistemas.
6.4.1. Sintaxis general
Cada accin de entrada y de salida definida en el modelo de operaciones del sistema
requerir de una especificacin gramatical que permita por medio de comandos o procedimientos de operacin definidos en el SOF, la interaccin con el sistema.
De acuerdo al metamodelo de SOF definido en este captulo, la gramtica incluir la
especificacin relativa a:
Comandos de entrada (Clase InputCmd).
Respuestas (Clase Response)
Notificaciones simples (Clase Notification).
Notificaciones de alarma (Clase Alarm).
Los cuatro tipos de acciones que intervienen en la interaccin entre el frontend de operaciones y el sistema, pueden expresarse gramaticalmente de la siguiente forma:
1. Comando de entrada
Un comando de operacin tiene como origen el frontend de operaciones y como
destino un elemento del sistema. Un comando de entrada tpico estar definido por:
Nombre del comando
Elemento del sistema al que afecta
Propiedad implicada del elemento y valor en su caso.
195
Sintaxis genrica:
<nombre_comando><elemento_sistema>[<propiedad>[<valor>]]
2. Respuesta
El sistema enva una respuesta al frontend de operaciones despus de ejecutar un
comando recibido desde ste. Una respuesta a un comando deber incluir una de las
siguientes opciones:
Confirmacin de la ejecucin correcta del comando, y adems, un valor concreto si el comando solicita el valor de alguna propiedad del elemento. El tipo
de datos correspondiente a dicho valor vendr definido por el dominio de aplicacin concreto.
Indicacin de ejecucin de comando errnea, y si el sistema lo permite, el tipo
de error producido mediante un cdigo preestablecido de error o bien mediante
una descripcin textual de ste.
Sintaxis genrica:
ejecucion_Ok [<valor>] | ejecucin_NoOk <error>
3. Notificacin simple
Una notificacin simple obedece a un evento producido en el sistema que afecta
por lo general al cambio de estado en un elemento concreto, o en alguna de sus
propiedades. Por ejemplo, el encendido o apagado de una mquina, o la variacin
de la temperatura monitorizada por una mquina. Una notificacin tiene por tanto el
196
origen en el sistema y el destino en la interfaz de operacin. Una notificacin estar

definida por:
Nombre de la notificacin
Nombre o identificador del elemento del sistema al que afecta
Nombre de la propiedad del elemento y valor en su caso
Sintaxis genrica:
<nombre_notificacion><elemento_sistema>[<propiedad><valor>]
4. Notificacin de alarma
Una notificacin de alarma es en todo similar a una notificacin simple, a excepcin
de que al tratarse de una situacin excepcional producida en el sistema debe tener un
tratamiento diferente y urgente por parte del operador del sistema.
Por tanto la sintaxis de una notificacin de alarma es similar a la de notificacin simple:
<nombre_alarma><elemento_sistema>[<propiedad><valor>]
6.4.2. Clasificacin de comandos bsicos de operacin

Distinguimos tres tipos de comandos bsicos de operacin para interactuar con el sistema desde un frontend de operaciones:
operaciones de administracin o configuracin
operaciones de interaccin
197
Operacin
CreateSe
DeleteSe
Set
Get
Start
Finish
Wait
Timer
For
Repeat
Tipo
administracin
administracin
interaccin
interaccin
interaccin
interaccin
procedimiento
procedimiento
procedimiento
procedimiento
Tabla 3: Conjunto de operaciones genricas

operaciones de composicin de procedimientos
Para cada uno de estos tipos se han incluido una serie de operaciones o comandos
habituales en los dominios de aplicacin analizados para realizar este trabajo.
La tabla 3 muestra las operaciones propuestas clasificadas en los tres grupos. Para cada
una de estas operaciones se presenta una sintaxis genrica, de manera que la sintaxis de
algunas operaciones puede ser adaptada al dominio de aplicacin concreto.
6.4.3.
Operaciones de administracin o configuracin
El frontend de operaciones tiene que mostrar al operador una representacin, normalmente grfica, del sistema (elementos que lo componen e interconexiones entre ellos) sobre
el que est operando. Esta representacin del sistema conforma una vista lgica del mismo.
La definicin de esta vista lgica requiere de la existencia de operaciones (lgicas) que
permitan configurarla, por medio de comandos de agregacin y eliminacin de elementos
del sistema. Las operaciones de administracin deben permitir al operador o administrador
del frontend de operaciones representar una vista del sistema real.
Estas operaciones podran estar embebidas en las opciones de configuracin del frontend de operaciones, y configurar o administrar el sistema sin utilizar comandos del lenguaje
de operacin.
198
6.4.3.1.
CreateSE
Descripcin:
Los elementos del sistema existen por si mismos con independencia de la existencia o no
de un frontend de operaciones. El frontend de operaciones requiere de una representacin
de los elementos que componen el sistema para que el operador pueda visualizar su composicin y estado en cada momento.
Esta operacin permite definir un elemento del sistema en la vista que observa un operador. En realidad define una correspondencia entre un elemento en la vista del frontend de
operaciones y un elemento fsico del sistema. La creacin de un elemento en la vista lgica del sistema, debera conllevar el intento de conexin o contacto con el elemento fsico
asociado, para comprobar si el elemento fsico indicado existe y es accesible.
Sintaxis:
CreateSE <elemento_sistema><tipoelemento><Id-fisico>[<puerto>]
dnde:
elemento_sistema: identificador del elemento del sistema al que va dirigido el comando.
tipoelemento: tipo del elemento a definir del sistema perceptible por el operador.
id-fisico: identificacin fsica del elemento para que el Gateway pueda establecer
comunicacin con l. Por ejemplo, direccin IP en comunicaciones TCP-IP.
puerto: puerto de comunicacin con el elemento del sistema, en caso de ser necesario.
Valor de retorno:
El elemento del sistema, tras ejecutar el comando debe retornar una respuesta de comando ejecutado correctamente, o el cdigo de error producido.
199
6.4.3.2.
DeleteSE
Descripcin:
Esta operacin tiene una funcionalidad opuesta a la anterior, eliminando un elemento de
la vista lgica del sistema que percibe un operador desde el frontend de operaciones.
Sintaxis:
DeleteSe <elemento_sistema>
dnde:
elemento_sistema: identificador del elemento del sistema al que va dirigido el comando
Valor de retorno:
6.4.4. Operaciones de Interaccin
Las operaciones de interaccin incluyen las operaciones o comandos bsicos que acepta
el sistema para interactuar con l, y que pueden ser comunes a muchos de los sistemas con
posibilidad de interaccin:
Set
Get
Start
Finish
Los comandos Set y Get deben permitir respectivamente asignar y obtener valores de las
propiedades perceptibles de los elementos del sistema. Los comandos Start y Finish deben
200
permitir respectivamente que un elemento del sistema se ponga en ejecucin o finalice

sta. En algunos sistemas los dos primeros comandos mencionados pueden aplicarse a los
elementos del sistemas independientemente de que stos estn o no en ejecucin.
As, un esquema de funcionamiento habitual, puede ser asignar valores a los atributos
de un elemento del sistema, ponerlo en ejecucin, finalizar su ejecucin posteriormente, y
obtener despus ciertos valores de los atributos del elemento.
6.4.4.1.
Set
Descripcin:
El objetivo del comando Set es asignar valores a los atributos o propiedades de los elementos del sistema.
Sintaxis:
SET <elemento_sistema><atributo><valor>
dnde:
atributo: nombre del atributo objeto de la asignacin.
valor: valor a asignar.
Valor de retorno:
201
6.4.4.2.
Get
Descripcin:
Este comando debe permitir obtener el valor de los atributos o propiedades de los elementos del sistema.
Sintaxis:
GET <elemento_sistema><atributo>
dnde:
atributo: nombre del atributo del que se quiere obtener el valor.
Valor de retorno:
El elemento del sistema, tras ejecutar el comando debe retornar una respuesta de comando ejecutado correctamente con el valor de la propiedad solicitada, o el cdigo de error
producido.
6.4.4.3. Start
Descripcin:
Este comando debe activar el elemento del sistema correspondiente para que se ponga
en funcionamiento.
Sintaxis:
START <elemento_sistema>
dnde:
202

Valor de retorno:
6.4.4.4.
Finish
Descripcin:
El comando Finish debe permitir finalizar el funcionamiento del elemento del sistema
especificado en el comando.
Sintaxis:
FINISH <elemento_sistema>
dnde:
Valor de retorno:
6.4.5. Operaciones de procedimiento
Adems de las operaciones de interaccin, el operador que utilice el frontend de operaciones necesita otras operaciones a las que llamamos operaciones de procedimiento. Estas
operaciones permiten disponer de comandos que controlen de alguna manera la interaccin con el sistema, como bucles, condiciones de espera, etc. La siguiente lista contiene las
operaciones de procedimiento definidas:
203
Repeat
For
Wait
Timer
6.4.5.1. For
Descripcin:
Establece un bucle que ejecuta una serie de comandos un nmero determinado de veces.
Sintaxis:
For <times>
<Statements>
endFor
dnde:
times: numero entero mayor que cero, que indica el nmero de veces que se ha de
ejecutar el bloque de sentencias que incluye el comando.
statements: bloque formado por una o ms operaciones.
Valor de retorno:
En s este comando no tiene valor de retorno ya que no se ejecuta directamente en el
sistema. Es el frontend de operaciones el encargado de implementar el bucle.
6.4.5.2. Repeat
Descripcin:
Establece un bucle que ejecuta una serie de comandos un nmero determinado de veces,
mientras o hasta que se cumpla una condicin determinada.
204
Sintaxis:
Repeat {until | while} <condition>

<Statements>
endRepeat
dnde:
condition: condicin del bucle.
statements: bloque formado por uno o ms comandos.
Valor de retorno:
sistema. Es el frontend de operaciones el encargado de implementar el bucle.
6.4.5.3.
Wait
Descripcin:
El objetivo de esta operacin es el de esperar hasta que se cumpla una determinada
condicin. Para ello los elementos del sistema implicados en la operacin deben estar en
ejecucin, y producir en algn momento una notificacin que satisfaga la condicin, y por
tanto finalizar la espera.
Sintaxis:
Wait <condition>
dnde:
condition: condicin de espera.
205
Valor de retorno:
sistema. Es el frontend de operaciones el encargado de implementar la espera.
6.4.5.4. Timer
Descripcin:
El comando Timer representa temporizadores asociados a elementos del sistema o al sistema completo. Este comando realizar una espera en el frontend de operaciones hasta que
se cumpla el tiempo establecido como parmetro. Durante dicha espera, el frontend de operaciones no podr enviar nuevos comandos al sistema, pero si podr recibir notificaciones
enviadas desde l.
Para definir un comando de tipo Timer, podra utilizarse la especificacin de temporizadores definida en TTCN-3 [53] y U2TP [130].
Sintaxis:
Timer <time>
dnde:
time: tiempo total durante el cul estar activo el temporizador. Mediante un valor de
tipo decimal indica el tiempo en segundos.
Valor de retorno:
sistema. Es el frontend de operaciones el encargado de implementar el temporizador.

En este captulo se plantea la utilizacin del modelo de operaciones de un sistema como
soporte en el modelado de un frontend de operaciones. El metamodelo de operaciones
206
del sistema definido en el captulo anterior, permite incorporar la informacin del modelo
de operaciones al modelo del sistema, pero no incluye ninguna referencia al frontend de
operaciones.
Al objeto de aplicar el metamodelo de operaciones ya definido, como soporte en el
modelado de un frontend de operaciones de dominio especfico, se define en este captulo
una propuesta de metamodelo UML que refleja la interaccin entre el frontend de operaciones y el sistema, tomando como base el metamodelo de modelo de operaciones de un
sistema definido en el captulo anterior. Este nuevo metamodelo refleja el sistema bajo operacin, el frontend de operaciones y las interfaces definidas entre ambos que posibilitan la
interaccin.
Por otra parte se describe una arquitectura conceptual del frontend de operaciones
definiendo los diferentes niveles de abstraccin existentes en la interaccin entre operador y sistema: interaccin operador-sistema, interaccin frontend-sistema, comunicacin
frontend-sistema, interfaz grfica de usuario orientada al operador del sistema, y ncleo del
Finalmente, se plantea un conjunto de comandos bsicos de operacin del sistema que
sea aplicable a diferentes dominios de aplicacin, compuesto por operaciones de administracin o configuracin, de interaccin y de procedimiento.
207
208
Captulo VII
APLICACIN DEL MODELO DE OPERACIONES A
UN CASO PRCTICO
Slo cuando se haya cortado el ltimo rbol,

slo cuando el ltimo ro haya muerto envenenado,
slo cuando se haya pescado el ltimo pez,
slo entonces vers que el dinero no se puede comer.
Profeca india
209
7.1. Introduccin
En este captulo se presenta una aplicacin del modelo de operaciones de un sistema en
un caso prctico, en base a las aportaciones realizadas en este trabajo. El sistema elegido
para el caso prctico que se presenta corresponde al software que opera y monitoriza un
conjunto de mquinas de juego de azar interconectadas. Este tipo de sistemas tienen que
cumplir la normativa legal existente, y superar un proceso de certificacin por el organismo
oficial correspondiente para poder ser utilizados por el pblico autorizado (personas con
mayora de edad) en salas de juego.
Si bien las mquinas en su funcionamiento habitual interactan directamente con los
jugadores mediante dispositivos fsicos (botones, palancas, seales visuales y acsticas,
etc.) existen casos en los que dicha interaccin puede requerir de la existencia de un sistema
software. Uno de estos casos est relacionado con la validacin del sistema en procesos de
fabricacin, certificacin y revisiones peridicas. La validacin del sistema puede apoyarse
en la existencia de un modelo de operaciones que facilite la operacin de las mquinas
desde sistemas software, y que no requieran de personas y monedas fsicas para la llevar a
cabo la evolucin del juego.
Otro caso, es el de habilitar el juego de forma remota, de forma que la existencia de un
modelo de operaciones que permita establecer la interaccin con el sistema de juego sea
fundamental. Por ejemplo, jugadores que jueguen en diferentes sistemas fsicos al mismo
tiempo (de una misma sala o de varias salas diferentes) conectados por lneas de comunicacin. Incluso sistemas de mquinas de juego interconectadas con interaccin Web.
Por ltimo, destacar que el modelo de operaciones propuesto en este trabajo es aplicable a sistemas intensivos software que dispongan de una interfaz software que permita
interaccin con/desde el exterior. Este caso prctico representa un ejemplo de cmo aplicar
el modelo de operaciones propuesto en el proceso de desarrollo de sistemas con software,
sirviendo de gua para su aplicacin a sistemas con software en general.
210
En este captulo se presenta en primer lugar una descripcin del sistema objeto de estudio. En segundo lugar se describe el modelo del sistema y posteriormente, se ampla dicho
modelo para incluir los aspectos de operaciones del sistema. Y por ltimo, se analiza la
aportacin del enfoque basado en el modelo de operaciones en los procesos de desarrollo y
operaciones de sistemas.
7.2.
Descripcin del caso
7.2.1. Concepto de sistema

El caso de estudio que se presenta corresponde a un sistema industrial con software
embebido compuesto de mquinas de juego de azar interconectadas. Para la descripcin
de este sistema se ha tomado como base la normativa legal espaola de aplicacin a este
tipo de mquinas [20] [21] y resultados del proyecto europeo IST-2000-28583 de acrnimo
METSES [113] [6] y del proyecto nacional MEC-CICYT TIC2003-08503 de acrnimo
AGMOD.
Las mquinas de juego de azar (tambin llamadas comnmente en Espaa mquinas
tragaperras) que pueden encontrarse en cualquier sala de juego, a cambio del precio
de la partida conceden al jugador tiempo de juego. El juego consiste en la obtencin de
forma aleatoria de una combinacin de varios elementos representados habitualmente por
figuras, de forma que ciertas combinaciones, conocidas de antemano, conceden al jugador
premios que dependen exclusivamente del azar. Esto es, la combinacin de cada jugada no
depende de las combinaciones de las jugadas anteriores o posteriores, y las combinaciones
con premio asociado estn fijadas al fabricarse la mquina y no pueden ser modificadas
con posterioridad. Tanto el precio de la partida como los premios concedidos consisten en
dinero, en forma de monedas generalmente.
Las mquinas de juego operan independientemente unas de otras, pero pueden interconectarse entre s proporcionando un premio especial o acumulado. Este premio especial
211
acumulado se concede individualmente por cada mquina (no existe un control en la concesin del premio por el hecho de estar interconectadas). Sin embargo la cantidad del premio
se calcula como un porcentaje del total del dinero ingresado en el conjunto de las mquinas
interconectadas.
As, como conjunto interconectado, el sistema estar compuesto por una serie de mquinas de juego de azar, a las que llamaremos Acumuladores, interconectadas a una mquina
o dispositivo central, a la que llamaremos Master. Ambos tipos de mquinas dispondrn de
tarjetas de entrada y salida con el software necesario para interactuar entre ellas. La figura
32 muestra la composicin del sistema para tres mquinas de tipo acumulador y una de tipo
master.
Las mquinas de tipo acumulador disponen de un contador de crditos y producen dos
tipos de premios:
Premio interno que proporciona la mquina individualmente.
Premio especial acumulado o jackpot acumulado, cuya cantidad viene determinada
por la mquina de tipo master, como un porcentaje de las cantidades ingresadas en
todas las mquinas interconectadas.
La mquina de tipo master no es una mquina de juego en s misma sino que acta como
controladora del premio especial acumulado, recibiendo de cada mquina acumulador los
crditos o cantidades que van ingresando y gestionando dicho valor de acumulado. Con
el total de crditos recibidos en todas las mquinas, el master calcula un porcentaje de
la cantidad total acumulada que ser la cantidad asociada al premio de tipo jackpot. El
algoritmo o mecanismo que otorga el premio jackpot a una mquina determinada no lo
facilita el fabricante, ya que es informacin confidencial. Cuando una mquina proporciona
el premio Jackpot, la mquina central master enva una seal de bloqueo a cada mquina
de juego. Posteriormente, la persona que haga las funciones de jefe de sala entregar el
premio, normalmente un cheque bancario, al jugador que lo consigui, e iniciar a travs
212
Figura 32: Sistema de mquinas de juego de azar interconectadas

del master la accin de desbloqueo de las mquinas de juego.
7.2.2.
Requisitos para la certificacin de mquinas interconectadas
Las administraciones pblicas exigen la certificacin de este tipo de mquinas previa

a su explotacin en salas de juego, bingos, casinos, etc. La certificacin de una mquina
garantiza el cumplimiento de la normativa aplicable respecto a las cantidades que otorgan
los premios y la periodicidad de stos. En este caso de estudio, es necesaria la certificacin
tanto de cada mquina individualmente como del sistema en su conjunto con las mquinas interconectadas. La normativa legal que se ha tenido en cuenta para determinar los
213
requisitos del sistema es la normativa estatal aplicable en Espaa:

1. Real Decreto 2110/1998: Reglamento de Mquinas Recreativas y de Azar [20].
2. Orden de 26 de febrero de 2001 por la que se actualizan los precios y los premios
mximos de las mquinas recreativas de tipo B que figuran en el RD 2110/1998 [21].
Los requisitos establecidos para el sistema de mquinas recreativas interconectadas extrados de la normativa indicada anteriormente, son los siguientes:
R1. Cada mquina (tipo B) individualmente devolver en cada ciclo de 20.000 partidas consecutivas, un porcentaje de premios >75 % del valor de las partidas jugadas.
En cada 5.000 partidas de una serie, el porcentaje de premios ser >40 % del valor
de las partidas jugadas [RD 2110: Artculo 5(4)]. Se entiende por ciclo, el conjunto de partidas consecutivas que el programa de juego debe establecer para pagar el
porcentaje de devolucin en premios.
R2. La interconexin de mquinas de tipo B permitir otorgar un premio acumulado cuya cuanta no sea inferior a 600 veces, ni superior a 2.000 veces el precio
mximo de la partida simple y sin que dicho precio acumulado suponga una disminucin del porcentaje de devolucin de cada una de las mquinas interconectadas
[Orden de 26 de febrero de 2001, artculo 7(h)].
R3. El nmero de mquinas recreativas de tipo B interconectadas no puede ser
inferior a tres [RD 2110: Artculo 7(h)].
R4. El premio individual de mayor valor de una mquina (tipo C) ser de 2.000 veces
el valor de la apuesta, pudiendo dar jackpots o premios especiales como acumulacin
de un porcentaje de lo apostado [RD 2110: Artculo 10(b)].
R5. La mquina devolver en forma de premios un porcentaje no inferior al 80 % de
214
las apuestas efectuadas. En el caso de que est proyectada para acumular un porcentaje de lo apostado para constituir jackpots o premios especiales, esta acumulacin ser
adicional al porcentaje previsto en el prrafo anterior [RD 2110: Artculo 10(d)].
R6. Si el volumen de monedas del premio excediese de la capacidad del depsito
de reserva de pagos, los premios podrn ser pagados manualmente al jugador por
un empleado de la sala, en cuyo caso debern disponer de un avisador luminoso
y/o acstico que se active de manera automtica cuando el jugador obtenga dicho
premio. Dispondrn, adems, de un mecanismo de bloqueo que, en el caso previsto
anteriormente, impida a cualquier jugador seguir utilizando la mquina hasta que el
premio haya sido pagado y la mquina desbloqueada, por el personal al servicio de
la sala [RD 2110: Artculo 11(2)].
R7. El importe mximo del premio que pueda conseguirse por todos los conceptos a
travs de las mquinas interconectadas no podr ser superior a la suma de los premios
mximos del total de las mquinas interconectadas [RD 2110: Artculo 12(2)].
R8. Las mquinas de tipo B y C debern incorporar contadores que cumplan los
requisitos siguientes [RD 2110: Artculo 13(1)]:
1. Identifiquen la mquina en que se encuentran instalados.
2. Almacenen los datos correspondientes al nmero de partidas realizadas y premios obtenidos, de forma permanente y acumulada desde su primera instalacin.
La instalacin de los contadores no ser preceptiva para las mquinas de tipo C, si
el establecimiento, en que estn instaladas dispone de un sistema informtico central
autorizado previamente y conectado a las mquinas en el que queden registradas, al
menos, las mismas operaciones que los contadores individuales de las mquinas [RD
2110: Artculo 13(3)].
215
R9. Todos los modelos de mquinas de tipo B y C debern ser sometidos, con
anterioridad a su homologacin, a ensayo en entidad autorizada por la Comisin
Nacional del Juego [RD 2110: Artculo 18(1)].
R10. En la disposicin adicional primera del RD 2110/1998 se incluye la siguiente
terminologa:
1. Apuesta: cantidad de dinero, que el jugador arriesga a cambio de la posibilidad
de obtener un premio o ganancia.
2. Partida: todo conjunto de acciones o jugadas, que realiza el jugador entre la
introduccin del precio de la partida y su prdida o cobro del premio en su
caso.
3. Jugada: cada una de las intervenciones del jugador o cada uno de los lances que
se realizan en el transcurso de una partida.
7.2.3. Descripcin del problema a resolver
Todo sistema compuesto de mquinas de juego interconectadas tiene que ser certificado
antes de su utilizacin. Esta certificacin comprende la validacin del sistema respecto de
los requisitos enunciados anteriormente. La validacin del sistema se fundamenta en la
operacin del mismo. Esto es, para comprobar el cumplimiento de requisitos es necesario
tener el sistema en funcionamiento y realizar las acciones u operaciones pertinentes.
La interconexin de mquinas requiere una mutua comunicacin entre el dispositivo
central y las mquinas de juego participantes en la interconexin. Para ello:
1. El dispositivo central al que hemos llamado Master tiene que:
a) Almacenar el porcentaje de acumulado correspondiente al premio especial jackpot y actualizarlo continuamente recibiendo de cada mquina interconectada las
cantidades ingresadas.
216
b) Recibir el aviso de premio especial jackpot ocurrido en la mquina de juego

correspondiente.
c) Avisar que se ha producido el premio jackpot a todas las mquinas de juego
para que stas queden bloqueadas.
d) Actualizar el valor del acumulado a un valor inicial prefijado cuando se conceda
un premio especial jackpot.
2. Las mquinas de juego interconectadas a su vez tienen que:
a) Enviar al dispositivo central las cantidades ingresadas en cada momento.
b) Comunicar al dispositivo central la concesin de un premio especial jackpot.
c) Bloquearse impidiendo el juego cuando se produzca un premio jackpot.
d) Desbloquearse cuando el premio haya sido entregado al jugador premiado.
7.2.4.
Descripcin de la solucin
La certificacin de un sistema de mquinas de juego interconectadas requerir de una

fase de validacin de los requisitos por ejemplo mediante pruebas de aceptacin. Esta validacin de un sistema de mquinas de juego interconectadas podra realizarse de una de las
dos formas siguientes:
Validacin manual. La validacin podra realizarse de forma manual con tantas personas o jugadores como mquinas estuvieran interconectadas. Cada jugador y mquina
deberan estar jugando el tiempo que fuese necesario para poder realizar la validacin de los requisitos establecidos para las mquinas de juego interconectadas. Esta
forma de validacin aunque posible es tediosa y sujeta a errores humanos en la contabilizacin de las partidas jugadas en cada mquina, premios otorgados, etc.
Validacin automtica o semi-automtica. Este tipo de validacin contemplara la
217
ejecucin de las pruebas de forma asistida mediante algn sistema software que permita interaccin con el sistema de mquinas de juego desde el exterior de las mismas. Esto evitara la necesidad de utilizar las interfaces fsicas de la mquina con
el jugador como botones, palancas, seales visuales y acsticas, etc. El software externo que posibilite la interaccin con el sistema constituira en s un frontend de
operaciones del sistema.
Esta solucin requiere de la existencia de algn tipo de interfaz en el sistema que
permita la interaccin con el sistema software externo al mismo. Para ello es preciso disponer de una interfaz software en cada una de las mquinas interconectadas
(incluido el Master) que acepte comandos de operacin desde el exterior y retorne
respuestas y notificaciones al frontend de operaciones.
La solucin que se ha descrito para la certificacin del sistema por medio de la validacin automtica o semi-automtica, est en lnea con la existencia de un frontend de operaciones que soporte la interaccin entre sistema y operadores que representen jugadores.
Un frontend de operaciones sera de aplicacin asimismo en el caso de que la solucin
buscada en lugar de ser la validacin del sistema fuese una forma de juego remota, donde
los jugadores no actuasen directamente sobre las mquinas sino que utilizasen el frontend
de operaciones para interactuar con ellas.
7.3. Requisitos del sistema

El conjunto de requisitos especficos definido para el sistema de mquinas de juego
inter-conectadas es el siguiente:
Basados en la normativa legal aplicable:
Req1. El sistema estar compuesto por un mnimo de tres mquinas de juego interconectadas a una unidad central. Las mquinas de juego recibirn el nombre de
acumuladores y la unidad central de master.
218
Req2. Es preciso insertar monedas en los acumuladores para poder jugar con ellos.
El coste de una partida en la mquina se denomina crdito. El jugador puede insertar
tantos crditos como desee en un acumulador.
Req3. El acumulador se pone a jugar cuando recibe la orden de inicio por parte
del jugador (por ejemplo, pulsando un botn, accionando una palanca o enviando la
orden correspondiente).
Req4. Una vez iniciado el juego en un acumulador, ste estar jugando hasta que
agote los crditos, o bien hasta que reciba la orden de finalizar el juego por parte del
jugador.
Req5. Los acumuladores proporcionan premios consistentes en dinero como resultado del juego realizado con ellos. Existen dos tipos de premios:
1. Premio al que llamaremos normal, obtenido como consecuencia del funcionamiento individual de la mquina.
2. Premio especial o jackpot, producido en un acumulador concreto como consecuencia de la interconexin de las mquinas de juego. Este premio corresponde a un porcentaje de las cantidades jugadas en todas las mquinas interconectadas.
Req 6. Si el volumen de monedas del premio excediese de la capacidad del depsito
de reserva de pagos, los premios podrn ser pagados manualmente al jugador por
un empleado de la sala, en cuyo caso debern disponer de un avisador luminoso
y/o acstico que se active de manera automtica cuando el jugador obtenga dicho
premio. Dispondrn, adems, de un mecanismo de bloqueo que, en el caso previsto
anteriormente, impida a cualquier jugador seguir utilizando la mquina hasta que el
premio haya sido pagado y la mquina desbloqueada, por el personal al servicio de
la sala [RD 2110: Artculo 11(2)].
219
Req7. El importe mximo del premio que pueda conseguirse por todos los conceptos
a travs de las mquinas interconectadas no podr ser superior a la suma de los premios mximos del total de las mquinas interconectadas [RD 2110: Artculo 12(2)].
Req8. Las mquinas de tipo acumulador incorporarn contadores que:
1. Identifiquen la mquina en la que se encuentran instalados.
2. Almacenen los datos correspondientes al nmero de partidas realizadas y premios obtenidos, de forma permanente y acumulada desde su primera instalacin.
7.4. Modelo del sistema

Esta seccin se centrar en las dos primeras fases de una iteracin en la metodologa
RUP: comienzo (inception) y elaboracin (elaboration). Las fases de construccin (construction) y transicin (transition) que comprenden la construccin del software y la puesta
en marcha de la solucin a la comunidad de usuarios destinatarios, no se detallan aqu
puesto que quedan fuera del alcance del modelado de la interaccin de un sistema.
Los diagramas UML incluidos en esta especificacin del sistema comprenden los siguientes diagramas relativos a los requisitos, la estructura esttica y el comportamiento
dinmico del sistema:
a. Requisitos
diagrama de casos de uso
b. Estructura esttica
diagrama de clases
c. Comportamiento dinmico
diagrama de estados
220
diagrama de actividad
diagrama de secuencia
7.4.1. Diagrama de casos de uso
Como punto de partida en el modelado del sistema de mquinas de juego interconectadas se utiliza un modelo de casos de uso que define los requisitos generales del juego.
Este modelo de casos de uso plantea las interacciones de un jugador con el sistema, y en
particular con la mquina de juego, llamado acumulador. Los distintos actores y casos de
uso de dicho modelo se muestran en el diagrama de casos de uso de la figura 33.
El diagrama de casos de uso define los requisitos desde el punto de vista del juego para
una mquina de tipo acumulador, por lo que la mquina master se representa como un actor.
En concreto en dicho diagrama, se han representado los siguientes actores:
Player. Representa a la persona que juega con la mquina de juego. Fsicamente, un
jugador introduce monedas en la mquina, e interacciona con la mquina accionando
los botones o dispositivos de juego y obteniendo resultados visibles del juego, y en
caso de premio, el importe de ste en monedas. Si el premio obtenido es un premio
especial jackpot el responsable de la sala de juego le entrega la cantidad premiada
personalmente.
Master. Este actor representa a la mquina o dispositivo central en la interconexin
de las mquinas de juego.
Machines Responsible. Este actor representa a la persona encargada de la sala de
juegos y entre sus funciones se encuentra la de entregar personalmente la cantidad
del premio jackpot al jugador de la mquina de juego premiada. Y una vez hecha la
entrega, el responsable debe accionar el desbloqueo de las mquinas de juego para
que contine el juego.
221
Figura 33: Diagrama de casos de uso de una mquina acumulador

El actor player tiene una multiplicidad mayor que uno, y el resto de actores estn representando una nica ocurrencia. Esto es as puesto que el sistema tiene varias mquinas de
juego interconectadas y por tanto es posible tener varios jugadores jugando al mismo tiempo. Sin embargo el sistema tiene un nico actor relativo al dispositivo central del sistema,
mquina master, y un nico actor relativo a la persona que ejerce la responsabilidad de la
sala de juego, a la que hemos llamado machines responsibile.
Respecto a los casos de uso definidos, indicar que se podan haber sintetizado en un
solo caso de uso que representase el juego en s, una partida. No obstante se han reflejado
como casos de uso todas aquellos casos que suponen una accin con inicio o destino en el
jugador de una partida:
a. Play_No Prize
b. Play_Normal Prize
c. Play_Jackpot Prize
La figura 34 muestra un workflow de alto nivel del sistema, en forma de diagrama de
actividades, que comprende los tres casos de uso definidos:
222
Figura 34: Workflow"de una mquina de juego
223
1. El jugador inserta n crditos en la mquina (actividad Increase n Credits). En mquinas fsicas normalmente los crditos equivalen a monedas, por lo que el jugador
inserta monedas en la mquina que se traducen en crditos para jugar.
2. El jugador acciona los botones o dispositivos indicados para iniciar una jugada en la
mquina y siempre que el nmero de crditos sea suficiente la mquina iniciar la
jugada (actividad Play).
3. La mquina de juego comprueba el resultado de la jugada producindose una de las
siguientes situaciones:
a) El juego realizado por el jugador en la mquina no obtiene ningn tipo de premio como resultado.
b) El juego realizado por el jugador en la mquina obtiene un premio de la mquina
de juego (representado por la actividad NormalPrize). Este es un premio que
concede la mquina de forma independiente, es decir, no asociado a la interconexin de las mquinas de juego.
c) El juego realizado por el jugador en la mquina obtiene un premio que corresponde al premio especial jackpot (representado por la actividad Jackpot Prize).
Este es el premio especial asociado a la interconexin de las mquinas de juego,
calculado como un porcentaje del total del dinero ingresado en las mquinas de
juego. Este tipo de premio produce un bloqueo de todas las mquinas de juego
interconectadas, hasta que el responsable de la sala de juegos haga entrega personal de la cantidad de dicho premio al jugador agraciado.
4. Si quedan crditos suficientes en la mquina el jugador puede seguir jugando si lo
desea, en caso contrario finaliza la partida.
224
7.4.2. Diagrama de clases

Los objetos que conforman la estructura esttica del sistema estn representados en el
diagrama de clases que se muestra en la figura 35. Las clases definidas para el sistema de
mquinas de juego interconectadas son las siguientes:
7.4.2.1. Tipos de datos
Se han definido los siguientes tipos de datos para representar el diagrama de clases del
sistema:
1. Identifier. Tipo de datos que indica la identificacin de forma nica de los objetos de
una clase.
2. Money. Representa un tipo de datos que caracteriza el dinero que se ingresa en las
mquinas de juego para poder jugar.
3. Combination. Este tipo de datos representa las combinaciones que puede obtener una
mquina de juego.
4. AccumulatorStatus. Enumeracin que representa los estados en los que puede encontrarse una mquina de tipo acumulador.
7.4.2.2. Clase Master
Descripcin
Representa el dispositivo central que realiza el control de la cantidad asignada al premio
especial jackpot ofrecido por las mquinas de juego interconectadas. No interviene en la
concesin del premio, sino en la cantidad que se destina a ste, as como, en el bloqueo
y desbloqueo de las mquinas de juego interconectadas al objeto de realizar la entrega del
premio al jugador correspondiente.
225
Figura 35: Diagrama de clases

226
Asociaciones
accumulators: Accumulator [3..*]
Mquinas de juego interconectadas a travs de la mquina master. Existe una restriccin en la cardinalidad mnima, dado que el mnimo nmero de mquinas necesarias
para un sistema de mquinas de juego interconectadas es de tres segn marca la normativa legal en la que se han basado los requisitos del sistema.
accumulatorWiner: Accumulator [0..1]
Esta asociacin permite conocer al master qu mquina acumulador es la que ha
concedido el premio especial jackpot. La cardinalidad mnima es 0 puesto que el
premio jackpot no se concede de forma continuada; y mxima 1, puesto que en un
instante dado a lo sumo una mquina concede este tipo de premio.
Atributos
masterID: Identifier
Identificador de la mquina master.
accumulatedJackpot: Money
Cantidad de dinero acumulado para el premio especial jackpot.
jackpotState: boolean
Estado de juego respecto al premio jackpot.
Interfaces
La clase Master implementa la interfaz MasterBasicFunctionallity y adems usa la interfaz AccumulatorControl de cada una de las mquinas acumuladoras interconectadas.
MasterBasicFunctionallity
Interfaz implementada por la clase Master y que contiene las operaciones que ofrece
a la clase Accumulator.
227
AccumulatorControl
Interfaz que usa la clase Master para enviar operaciones a los acumuladores que
tenga conectados.
Mtodos
7.4.2.3. Clase Accumulator
Descripcin
Representa el tipo de mquina de juego o acumulador, que interacta con el jugador.
Asociaciones
master: Master [1]
Dispositivo central al que est conectada la mquina acumulador.
masterJackpot: Master [0..1]
Establece la relacin con la mquina master para determinar la mquina acumulador
que ha obtenido el premio jackpot en un momento dado.
allGames: Game [0..*]
Representa todas las jugadas realizadas por la mquina de juego.
currenteGane: Game [0..1]
Jugada actual, es decir la que se est jugando en un momento dado. La cardinalidad
mnima 0 indica que una mquina puede no estar jugando en una instante dado.
Atributos
accumulatorID: Identifier
Identificador de la mquina de juego o acumulador.
228
maxPrize: Money
Valor mximo de dinero que puede conceder la mquina en un premio.
creditCounter: Money
Contador de crditos disponibles para jugar en cada instante.
playCounter: int
Nmero de jugadas realizadas en la mquina de juego desde su instalacin.
accumulatedDelivery: Money
Cantidad total de dinero en premios entregada por la mquina de juego desde su
instalacin.
state: AccumulatorState
Estado en el que se encuentra el acumulador: jugando, bloqueado, desbloqueado o
parado.
accumulatedJackpot: Money
Cantidad total de dinero destinada al premio especial jackpot en cada momento.
Mtodos
Interfaces
La clase Accumulator implementa las interfaces AccumulatorControl y Play mediante
las cuales recibe entradas desde la mquina master y desde el exterior respectivamente. Y
usa la interfaz MasterBasicFunctionallity para enviar entradas a la clase Master.
AccumulatorControl
Interfaz implementada por la clase Accumulator para recibir entradas desde la clase
Master.
229
Play
Interfaz implementada por la clase Accumulator para recibir entradas desde el operador de la mquina, esto es, el jugador.
MasterBasicFunctionallity
Interfaz que usa la clase Accumulator para enviar entradas al master.
7.4.2.4.
Clase Game
Descripcin
Representa las jugadas realizadas en cada una de las mquinas de juego interconectadas.
Asociaciones
accumulator: Accumulator [1]
Mquina de juego a la que corresponde la jugada que representa el objeto de la clase
Play.
prize: Prize [0..1]
Premio obtenido en una jugada, en caso de haberlo. La cardinalidad mnima 0 expresa
la no consecucin del premio.
Atributos
combination: Combination
Combinacin de elementos o figuras obtenidas en la jugada, y que determinan la
consecucin o no de premio.
Mtodos
230
7.4.2.5.
Clase Prize
Descripcin
Representa los premios obtenidos en las jugadas realizadas en cada una de las mquinas de juego interconectadas. El premio se especializa en dos subclases: premio normal
producido en la mquina con independencia de la interconexin con otras, o bien premio
jackpot que corresponde al premio especial derivado de la interconexin de las mquinas
de juego.
Asociaciones
play: Game [1]
Jugada en la que se ha obtenido el premio.
Atributos
amount: Money
Cantidad de dinero otorgada al premio.
Mtodos
7.4.2.6.
Clase NormalPrize
Descripcin
Subclase de la clase Prize, que corresponde a un premio producido en la mquina independientemente de la interconexin con otras mquinas.
Asociaciones
No se han definido.
231
Atributos
No se han definido.
Mtodos
No se han definido.
7.4.2.7. Clase JackpotPrize
Descripcin
Subclase de la clase Prize, que corresponde a un premio especial producido en la mquina
de juego, asociado a la interconexin con otras mquinas. La cantidad de dinero correspondiente a este premio lo determina la mquina master como un porcentaje del total de dinero
ingresado en las mquinas de juego.
Asociaciones
No se han definido.
Atributos
No se han definido.
Mtodos
No se han definido.
7.4.2.8.
Interfaz MasterBasicFunctionallity
Descripcin
La clase Master implementa esta interfaz para que las mquinas de juego puedan interactuar con ella.
Operaciones
Las operaciones que ofrece el master a las mquinas de juego mediante esta interfaz son
232
las siguientes:
increaseJackpotAccum ( amnt: Money ) : void
Una mquina acumulador invoca esta operacin del master cuando recibe nuevos
crditos por parte del jugador. Tiene como parmetro de entrada la cantidad de dinero
ingresada en el acumulador y no tiene valor de retorno.
generalJackpot ( id : Identifier ) : void
Una mquina acumulador invoca esta operacin del master cuando concede el premio
especial jackpot. Con esta operacin el acumulador que ha dado el premio jackpot se
lo comunica al master, indicndole su identificador de mquina.
7.4.2.9.
Interfaz AccumulatorControl
Descripcin
La clase Accumulator implementa esta interfaz para que el master pueda enviar entradas
a los acumuladores.
Operaciones
Las operaciones que ofrece el master a las mquinas de juego mediante esta interfaz son
las siguientes:
updateJackpotAccum ( amnt : Money ) : void
La mquina acumulador que recibe esta entrada, actualiza el valor de su atributo
accumulatedJackpot al valor recibido en el parmetro amnt.
lock ( ) : void
La mquina acumulador que recibe esta entrada desde el master, se queda en estado
bloqueado hasta recibir una entrada de desbloqueo por medio de la operacin unlock.
unlock ( ) : void
233
La mquina acumulador que recibe esta entrada desde el master, pasa a estado desbloqueado o activo.
7.4.2.10.
Interfaz Play
Descripcin
Esta interfaz la implementa la clase Accumulator para que desde el exterior un operador,
haciendo las veces de jugador, pueda enviarle entradas.
Operaciones
Las operaciones que ofrece el acumulador a un jugador mediante esta interfaz son las
siguientes:
increaseCredits ( in amnt : Money ) : void
Cuando un acumulador recibe esta operacin modifica el valor de su contador de
crditos disponibles (atributo creditCounter) sumndole la cantidad dada por el parmetro de entrada amnt.
play ( in amnt : Money ) : Game
Esta operacin iniciada por un jugador pone a la mquina que la recibe en modo
juego. Recibe como parmetro la cantidad de crditos a jugar y devuelve el objeto de
la clase Game obtenido.
finish ( ) : Money
Al recibir esta operacin una mquina acumulador deja de jugar si estuviera jugando.
7.4.3. Diagrama de actividades
La figura 36 muestra un segundo diagrama de actividades del sistema, con mayor nivel de detalle que el presentado anteriormente en la figura 34 al describir el workflow del
sistema de juego.
234
Figura 36: Diagrama de actividades
235
Figura 37: Diagrama de secuencia
236
Este diagrama de actividades define el workflow que se produce entre un jugador y una
mquina de juego o acumulador:
1. El jugador introduce monedas en la mquina de juego o acumulador aumentando el
contador de crditos de la misma.
2. El jugador presiona el botn, palanca o dispositivo de comienzo de juego existente
en la mquina.
3. La mquina de juego decrementa el nmero de crditos correspondiente al coste de
la partida.
4. La mquina de juego comunica al master el comienzo de la jugada, para que ste
incremente el valor acumulado del premio jackpot general a todas las mquinas interconectadas. El valor de este acumulado equivale a un porcentaje de las cantidades
jugadas en todas las mquinas interconectadas para cada ciclo de premio jackpot.
5. El master enva a cada una de las mquinas interconectadas el nuevo valor del acumulado del premio jackpot comn.
6. La mquina acumulador genera de forma aleatoria la combinacin asociada a la jugada realizada.
7. La mquina acumulador comprueba la existencia de premio en la jugada producida.
8. Si la jugada no obtiene premio, la mquina pasa a comprobar el estado del contador
de crditos (paso 12).
9. Si la jugada obtenida corresponde con alguno de los premios programados, la mquina
notifica al jugador el premio y cantidad obtenida. Por otra parte, actualiza el valor del
contador de premios entregados por la mquina.
237
10. Si el premio corresponde a uno de los premios particulares de la mquina (premio

"normal prize") concede el premio al jugador en la cantidad de dinero correspondiente.
11. Si el premio obtenido corresponde al premio especial acumulado de tipo jackpot:
La mquina notifica al master la concesin del premio especial jackpot.
El master bloquea todas las mquinas acumulador para que interrumpan el
juego.
La persona encargada de la sala de juego entrega personalmente el premio especial al jugador afortunado.
El responsable de la sala inicia el desbloqueo de las mquinas por medio del
master.
El master modifica (resetea) el valor del contador del acumulado del premio
Jackpot de todas las mquinas acumulador a un valor inicial predeterminado.
12. Si el contador de crditos de la mquina acumulador tiene un valor en crditos inferior al coste de una partida, la mquina finaliza el juego (paso 14).
13. Si el contador de crditos de la mquina acumulador tiene un valor igual o superior al
coste de la partida, el jugador puede seguir jugando (paso 2) o bien finalizar el juego
(paso 14).
14. La mquina finaliza el juego quedando a la espera de poder efectuar nuevas partidas.
7.4.4. Diagrama de secuencia
La figura 37 muestra el diagrama de secuencia del sistema, compuesto por una mquina
de tipo master y tres mquinas de tipo acumulador.
238
Figura 38: Diagrama de estados de una mquina acumulador

7.4.5. Diagrama de estados
La figura 38 muestra el diagrama de estados para una mquina de tipo acumulador. Los
posibles estados definidos para una mquina de tipo acumulador son los siguientes:
1. ready. La mquina est preparada para jugar y acepta la insercin de crditos por
parte del jugador. Pasa a estado inplay cuando el jugador acciona el botn de inicio
del juego, y siempre que la mquina disponga de crditos suficientes. Pasa a estado
finished cuando el jugador finaliza explcitamente la partida. Si se produce un premio jackpot en otra mquina acumulador, quedar primeramente bloqueada, estado
locked, y posteriormente desbloqueada, estado unlocked, pasando finalmente de
nuevo al estado anterior, esto es, el estado ready.
2. in play. La mquina est realizando el juego. Pasa a estado ready si la combinacin
239
obtenida en la jugada no tiene premio o tiene un premio de tipo normal. Por contra
si la combinacin corresponde a un premio especial jackpot pasa a estado jackpot.
Tambin podr pasar a estado locked en el caso de que alguna otra de las mquinas
acumulador conceda el premio jackpot.
3. jackpot. En estado jackpot manda un aviso a la mquina master indicndole la consecucin de este tipo de premio, y cuando la mquina master se lo indique pasar a
estado locked.
4. locked. La mquina est bloqueada impidiendo el juego. Pasa a estado unlocked
cuando se lo indique la mquina master.
5. unlocked. La mquina se encuentra en estado desbloqueado reanudando la posibilidad de juego con ella. Si la mquina acumulador fue la que concedi el premio
jackpot pasa a estado ready. En caso contrario, pasar a estado ready o estado
play en funcin del estado en el que se encontrase antes del bloqueo.
6. finished. La mquina finaliza la partida de juego. Si el jugador introduce monedas
comienza un nuevo ciclo de juego.
7.5. Aplicacin del perfil U2OP al modelado del sistema

El modelo de sistema definido anteriormente no refleja con claridad los aspectos relativos a las operaciones o interacciones desde el exterior del sistema. Esta es una prctica
habitual en el modelado de sistemas, se modela el sistema centrndose en su comportamiento pero relegando los aspectos de operaciones a un segundo plano. Dichos aspectos quedan
reflejados en la definicin de las interfaces que son implementadas y usadas por el sistema. La definicin del modelo de operaciones de un sistema implica que se especifiquen
explcitamente la informacin relacionada con la interaccin del sistema desde el exterior.
Esta informacin incluye las propiedades monitorizadas y/o controladas y las acciones de
entrada y salida de cada uno de los elementos que componen el sistema.
240
Esta seccin incluye la especificacin del modelo de operaciones para el sistema caso de
estudio, tomando como punto de partida la definicin de modelo de operaciones del sistema
realizada en el captulo 4. El modelo de operaciones del caso prctico se ha especificado
aplicando el perfil U2OP de operaciones del sistema, definido en el captulo 5. Se obtiene
como resultado un diagrama de clases decorado con los estereotipos definidos en el perfil
U2OP.
El modelo de operaciones del sistema caso de estudio se ha reflejado en el diagrama
de clases incluido en el modelo de sistema definido con anterioridad, figura 35. El modelo
de operaciones se incluye decorando el diagrama de clases por medio de los estereotipos y
tipos de datos incluidos en el perfil U2OP, tal y como muestra la figura 39.
Los cambios que se han aplicado al modelo de clases al ser decorado con los mecanismos de extensin definidos en el perfil U2OP, permiten identificar de forma clara en el
modelo:
1. Los diferentes elementos que componen el sistema por medio del estereotipo definido
como U2OP_SystemElement, y sus propiedades perceptibles que corresponden
con variables monitorizadas y/o controladas en el modelo de operaciones, por medio
de los estereotipos:
a) U2OP_Monitored
b) U2OP_Controlled
c) U2OP_MonitoredAndControlled
2. Las relaciones o conexiones existentes entre los diferentes elementos que componen
el sistema y que son visibles desde el exterior del sistema, por medio del estereotipo
U2OP_VisibleRelation.
3. Las interfaces implementadas por cada elemento del sistema con las entradas que
acepta, por medio del estereotipo U2OP_Input. Cada una de estas entradas corresponde con un comando de entrada estereotipado como U2OP_InputCmd.
241
4. Las salidas generadas por cada elemento del sistema con destino el frontend de operaciones, representadas por las interfaces que usa el elemento, por medio del estereotipo U2OP_Output. En estas interfaces se emplea por un lado el estereotipo
U2OP_Notification para las notificaciones y por otro, el estereotipo U2OP_Alarm
para las alarmas.
A continuacin se describen cada uno de los elementos del modelo del sistema que han
sido estereotipados con los estereotipos que define el perfil U2OP.
7.5.1. SystemElement
Con este estereotipo se han decorado las clases que representan los elementos que componen un sistema de mquinas de juego interconectadas, con capacidad de interaccin desde el exterior:
1. Mquina master
2. Mquina acumulador
7.5.2. VisibleRelation
Este estereotipo se aplica a aquellas relaciones entre los elementos que componen el
sistema que son perceptibles por el operador desde el exterior del sistema, esto es, desde el
frontend de operaciones. Se ha estereotipado nicamente como U2OP_VisibleRelation
la asociacin entre las clases Master y Accumulator que representa la conexin entre las
mquinas de tipo master y de tipo acumulador. La otra asociacin existente entre las clases
Master y Accumulator que representa la mquina acumuladora que ha conseguido el premio jackpot en un instante dado, no se ha identificado con este estereotipo puesto que es
interna al sistema, y no es de inters para el operador.
242
Figura 39: Diagrama de clases

243decorado con el perfil U2OP
7.5.3. Monitored
Las propiedades del sistema que se han identificado como U2OP_Monitored para
cada uno de los tipos de elementos del sistema son las siguientes:
Clase Master
Para la clase Master se estereotipan como monitorizadas las siguientes propiedades:
accumulatedJackpot. El operador puede obtener la cantidad de dinero asignada en
cada momento por la mquina master al premio especial jackpot que conceden las
mquinas de juego.
jackpotState. El estado del master respecto a la concesin o no de premio especial
jackpot en alguna de las mquinas de juego interconectadas, puede ser consultado en
cualquier momento por el operador.
Clase Accumulator
De la clase Accumulator se tendr una monitorizacin de propiedades similar a la de la
mquina master:
state. El estado en el que se encuentra una mquina de tipo acumulador en cada
instante, con un dominio de valores que vendr definido en cada sistema en particular
por el tipo de datos AccumulatorState.
accumulatedJackpot. Valor del premio acumulado jackpot que proporcionar una
mquina de tipo acumulador al conceder el premio jackpot en un instante dado. Este
valor vara continuamente en funcin de los crditos jugados entre todas las mquinas
de tipo acumulador.
7.5.4. MonitoredAndControlled
Las propiedades del sistema identificadas como U2OP_MonitoredAndControlled son
las siguientes:
244
Clase Master
El elemento master no tiene ninguna propiedad controlada externamente por el operador.
Clase Accumulator
Una mquina de tipo acumulador tendr una nica propiedad controlada externamente
por el operador:
creditCounter. El operador modifica externamente la cantidad de crditos de una
mquina de tipo acumulador, incrementando el contador de crditos, y monitoriza
a su vez el valor del contador de crditos.
7.5.5. Input
Las interfaces estereotipadas como U2OP_Input se han aadido al diagrama de clases
como parte del modelo de operaciones del sistema. En el diagrama de clases inicial, antes
de ser decorado con el perfil U2OP, no figuran ya que representan la interaccin de entrada
con un frontend de operaciones del sistema.
Clase Master
Se ha estereotipado la interfaz Master_InputOperation implementada por la clase Master
como U2OP_Input. Esta interfaz define las operaciones de entrada que acepta dicha clase
desde el exterior.
Clase Accumulator
La interfaz Master_InputOperation que implementa la clase Accumulator se ha estereotipado como U2OP_Input porque contiene las operaciones de entrada que acepta desde el
exterior.
7.5.6. Output
Las interfaces estereotipadas como U2OP_Output, al igual que sucede con las estereotipadas como U2OP_Input, no figuran en el diagrama de clases inicial del modelo
245
del sistema, figura 35, ya que se incorporan al definir el modelo de operaciones del sistema, como forma de representar la interaccin de salida con un frontend de operaciones
del sistema.
Clase Master
Se ha estereotipado como U2OP_Output la interfaz Master_OutputOperation que usa
la clase Master para enviar al exterior las salidas que genera durante la operacin del sistema.
Clase Accumulator
Tambin se ha estereotipado como U2OP_Output la interfaz Accum_OutputOperation
que usa la clase Accumulator para enviar sus salidas al exterior.
7.5.7. CmdInput
Con el estereotipo U2OP_CmdInput se estereotipan las operaciones de entrada de
cada elemento del sistema, incluidas en las interfaces hacia el exterior que implementan.
Para cada uno de los dos tipos de elementos del sistema se han estereotipado las siguientes
operaciones de entrada.
Clase Master
Los comandos de operacin que acepta una mquina de tipo master son los siguientes:
Master_GetAccumulatedJackpot() : Money
Operacin que permite al operador conocer en un instante dado la cantidad de dinero
calculada por la mquina master para el premio especial jackpot que conceden las
mquinas de tipo acumulador.
Master_GetJackpotState() : boolean
Esta operacin permite conocer si el sistema se encuentra o no en un estado de concesin de premio jackpot por parte de alguna de las mquinas de juego.
246
Clase Accumulator
Los comandos de operacin que acepta una mquina de tipo acumulador son los siguientes:
Accum_GetCreditCounter() : Money
Por medio de esta operacin una mquina de tipo acumulador retorna el valor actual
de su contador de crditos.
Accum_SetCreditCounter( mon : Money ) : void
Con esta operacin la mquina acumulador acepta una nueva cantidad, pasada como
parmetro, en su contador de crditos.
Accum_GetJackpot() : Money
Esta operacin proporciona la cantidad de dinero que dar la mquina acumulador
en un instante dado al proporcionar un premio especial jackpot.
Accum_Start() : void
La mquina acumulador se pone a jugar siempre y cuando disponga de crditos, esto
es, si el valor del contador de crditos es igual o superior a la unidad.
Accum_Finish() : void
Con esta operacin una mquina acumulador finaliza el juego, an quedando crditos
en su contador de crditos.
7.5.8. Notification
Clase Master
La clase Master proporciona una nica salida hacia el frontend de operaciones en forma
de notificacin:
Master_Notif_Jackpot() : JackpotResult
247
La mquina master por medio de esta notificacin comunica al frontend de operaciones el resultado de un premio jackpot ocurrido en las mquinas de juego interconectadas. Dicho resultado, representado por un objeto de la clase JackpotResult
contiene el identificador de la mquina acumulador donde se ha producido el premio
y la cantidad de dinero correspondiente al premio.
Clase Accumulator
Los objetos de la clase Accumulator proporcionan las siguientes salidas hacia el frontend
de operaciones en forma de notificaciones:
Notif_Locked() : void
Esta notificacin avisa que la mquina acumulador pasa a estado bloqueado, impidiendo el juego.
Notif_Unlocked() : void
Esta notificacin avisa que la mquina acumulador pasa a estado desbloqueado, reanudando de nuevo el juego o quedando en disposicin de iniciar una nueva partida.
Notif_Jackpot() : Money
Comunica al frontend de operaciones que se ha producido un premio especial jackpot
en la mquina acumulador.
Notif_Credit() : Money
La mquina acumulador genera esta salida cada vez que vara el valor de su contador
de crditos.
7.5.9. Alarm
Clase Master
La clase master no tiene salidas de tipo alarma hacia el exterior.
248
Clase Accumulator
Se ha definido un nica salida de tipo alarma para la clase Accumulator:
Alarm_Credit0() : void
Esta alarma se produce cuando una mquina de tipo acumulador que est jugando se
queda sin crditos suficientes para continuar jugando.
7.6.
Se ha presentado un caso prctico en el que se aplica el modelo de operaciones del

sistema mediante el perfil UML definido en el captulo 5 de este trabajo. El caso prctico
corresponde a un sistema compuesto de mquinas de juego de azar interconectadas. Este
sistema rene las caractersticas del tipo de sistemas operables definidos en el captulo
3, esto es, compuesto de elementos inter-relacionados que permiten interaccin desde el
exterior.
Se presenta una descripcin del caso que incluye los requisitos que han de cumplir este
tipo de sistemas para su certificacin y puesta a disposicin del pblico en funcin de la
normativa vigente en Espaa. Se incluye as mismo una descripcin del problema a resolver
y la solucin propuesta.
Una vez planteado el problema se identifican los requisitos que ha de satisfacer el sistema de mquinas de azar interconectadas para ser operadas desde un frontend de operaciones. A partir de dichos requisitos se ha modelado el sistema mediante el lenguaje UML,
incorporando diagramas de casos de uso, de clases, de actividades, de secuencia y de estados.
Partiendo del modelo de sistema anterior, se ha aplicado el perfil de operaciones U2OP
al diagrama de clases, decorndolo mediante los estereotipos y tipos de datos definidos en
el perfil U2OP. La aplicacin del perfil de operaciones ha permitido identificar de forma
explcita y clara en el modelo del sistema:
249
1. Los elementos que componen el sistema y sus propiedades perceptibles desde el

exterior, por un operador del sistema.
2. Las relaciones entre los diferentes elementos que componen el sistema y que son
perceptibles por un operador del sistema.
3. Las interfaces implementadas por cada elemento del sistema y que identifican las
entradas u operaciones que aceptan.
4. Las interfaces que usa cada elemento del sistema y que identifican las salidas que
pueden generar hacia el exterior, esto es, el frontend de operaciones del sistema.
Por ltimo, destacar que el modelo de operaciones propuesto en este trabajo es aplicable a cualquier sistema que disponga de una interfaz software que permita interaccin
con/desde el exterior. Este caso prctico representa un ejemplo de cmo aplicar el modelo
de operaciones propuesto en el proceso de desarrollo de sistemas con software, sirviendo
de gua para su aplicacin a sistemas con software en general.
250
Captulo VIII
APLICACIN DEL MODELO DE OPERACIONES EN
PROCESOS DE DESARROLLO Y OPERACIN DE
SISTEMAS
Lo poco que he aprendido carece de valor,

comparado con lo que ignoro y no desespero en aprender.
Ren Descartes
251
8.1. Utilizacin del modelo de operaciones en procesos de

desarrollo de sistemas
En la seccin 7.4 del captulo anterior se ha presentado el modelo de sistema para las
mquinas de juego interconectadas. A partir de dicho modelo se puede abordar la construccin de los componentes software del sistema o de simuladores de ste.
El modelo del sistema planteado para el caso prctico se centra en aspectos de estructura
y comportamiento del sistema. Esta orientacin suele ser la habitual en el modelado de
sistemas. An cuando el modelado incluya aspectos de interaccin como diagramas de
secuencia y diagramas de colaboracin, stos no expresan con claridad la informacin de
las operaciones del sistema que define el modelo de operaciones. Se destacan como causas
de ello las siguientes:
1. El diagrama de clases incluye la composicin de los objetos y relaciones entre ellos.
Una clase describe el conjunto de propiedades que definen los objetos representados por la clase. En el caso de clases que representan los elementos perceptibles
de un sistema, el conjunto de propiedades definidas para el elemento comprenden
tanto las propiedades vinculadas directamente con las operaciones desde el exterior
(propiedades monitorizadas y/o controladas) como el resto de propiedades que definen la clase internamente, as como las que se derivan de las relaciones con otros
elementos del sistema. La existencia de propiedades con diferentes finalidades en la
definicin de las clases conlleva una prdida de claridad a la hora de identificar los
diferentes aspectos incluidos en la definicin. Uno de estos aspectos est asociado
con el comportamiento interno de los elementos que componen el sistema. Otro de
ellos concierne al comportamiento perceptible del sistema: propiedades, entradas y
salidas perceptibles desde el punto de vista de interaccin entre operador y sistema,
que constituye el eje central de esta tesis.
2. Una situacin similar se produce con las operaciones o mtodos definidos en las
252
clases. La definicin de una clase, en las etapas de diseo, incluye normalmente

mtodos con diferentes orientaciones: mtodos internos a la clase, mtodos que relacionan diferentes objetos entre ellos y mtodos accesibles desde el exterior del sistema que definen la interaccin u operacin del sistema. La existencia de un conjunto
de mtodos heterogneos en la definicin de clases no permite observar con claridad
las acciones de entrada y salida de un sistema respecto de las operaciones del mismo.
Si bien, la definicin de interfaces permite identificar las operaciones perceptibles externamente, stas pueden corresponder a operaciones relacionadas con la interaccin
con el operador, o bien, a operaciones entre elementos del sistema no perceptibles
por el operador.
3. El modelo de interaccin del sistema, expresado por ejemplo en UML mediante diagramas de secuencia y de colaboracin, permite definir ciertos detalles de la interaccin entre un sistema y un frontend de operaciones del mismo. Estos diagramas
estn orientados a describir interacciones partiendo de los casos de uso definidos
previamente. Los diagramas de secuencia reflejan la relacin temporal en la interaccin, mientras que los de colaboracin acentan las relaciones entre roles. Ambos
describen la interaccin entre objetos mediante transmisin de mensajes entre objetos o subsistemas. El nombre de un mensaje puede indicar el nombre de una operacin del objeto invocado o de una interfaz provista por el objeto [88]. La presencia
de operaciones internas y externas en un mismo diagrama no permite discernir con
claridad las interacciones del sistema con el exterior. No obstante, se pueden definir
diagramas de interaccin que traten exclusivamente la interaccin del sistema con el
exterior especficamente.
4. En sentido amplio, una interfaz representa el conjunto de comandos y mtodos que
permiten la intercomunicacin de un elemento del sistema con cualquier otro elemento interno o externo. La definicin de interfaces como parte de la estructura del
253
sistema aporta mayor claridad al modelo de operaciones del sistema, ya que refleja
el conjunto de comandos accesibles desde el exterior y el conjunto de salidas que el
sistema puede enviar al exterior. Sin embargo sigue existiendo cierta dispersin, ya
que la definicin de interfaces suele incluir no solo los aspectos de interaccin con
el exterior, sino que incluye tambin los aspectos de interaccin interna con otros
elementos del sistema. La definicin explcita del modelo de operaciones mediante
el perfil U2OP proporciona ms semntica en la definicin de las interfaces y aporta
mayor claridad al conjunto de stakeholders.
En resumen, el modelado de sistemas habitualmente no contempla una definicin explcita de las operaciones del sistema, producindose una dispersin de la informacin de
las operaciones del sistema entre el conjunto de diagramas definidos, lo que dificulta su
comprensin.
Adems, al no ser el modelo de operaciones de un sistema un objetivo en s mismo, los
aspectos de operaciones del sistema se relegan a un segundo plano, ya que:
1. Los diagramas utilizados en la fase de anlisis no suelen incluir mtodos (operaciones) en las clases.
2. Hasta que no se llega al diseo hay muchos aspectos del modelo de operaciones que
no afloran.
Este trabajo plantea la definicin explcita del modelo de operaciones del sistema en
el proceso de desarrollo de sistemas. El modelo de operaciones complementa al modelo
del sistema aportando una definicin clara y concisa de la interaccin entre un sistema y un
frontend de operaciones de ste.
La especificacin del modelo de operaciones en las etapas iniciales del proceso de desarrollo permitir agilizar el desarrollo del sistema. Dicha especificacin proporciona la
base para disponer en etapas tempranas de una interfaz del sistema con el exterior y de un
254
frontend de operaciones del sistema. La existencia de ambos posibilita un desarrollo incremental del sistema, creando los componentes del sistema gradualmente, e integrndolos
con otros componentes ya creados o simulados.
La informacin incluida en el modelo de operaciones permite definir la interfaz software del sistema basado en sus entradas y salidas. Tambin sirve como soporte para crear
o adaptar el frontend de operaciones proporcionando:
1. La estructura de elementos y propiedades perceptibles del sistema.
2. La base para definir el lenguaje de operaciones para interactuar con el sistema.
Adems como valor aadido, la utilizacin del perfil UML de operaciones U2OP permite guiar la definicin del modelo de operaciones del sistema, aportando:
Una terminologa y vocabulario propios orientados a la operacin del sistema.
Ms semntica al modelo que la que permite el modelo o metamodelo del sistema.
Informacin de utilidad en la transformacin de modelos.
Por otra parte, consideramos que la utilizacin de un modelo de operaciones del sistema puede ser de aplicacin en diferentes metodologas de desarrollo de sistemas tanto
convencionales como giles.
8.2.
El modelo de operaciones como soporte en la generacin

de herramientas de validacin y operacin de sistemas
Los sistemas intensivos en software son cada da ms complejos, por lo que la industria
requiere de otros enfoques, prcticas y facilidades para probar y operar dichos sistemas. El
proceso de validacin y de forma relacionada las herramientas de validacin, ocupan una
posicin cada vez ms relevante en el contexto del conjunto de procesos del ciclo de vida,
ya que son muy cercanos a las salidas que el usuario final espera. La ejecucin sistemtica
255
de estas pruebas constituye un aspecto importante para conseguir aumentar la satisfaccin

del cliente y, probablemente, reducir el coste total del proyecto.
Sin embargo no se presta la atencin requerida al proceso de validacin, en algunos
casos las pruebas se desarrollan de forma manual, haciendo que el proceso de validacin
se convierta en tedioso, difcil de gestionar y propenso a errores, lo que puede llevar a
no dar suficiente importancia a las pruebas con tal de conseguir cumplir la planificacin
temporal del proyecto. En otros casos, los equipos de desarrollo producen herramientas
de pruebas especficas para sus sistemas o productos, que no son aplicables a otros productos y adems suelen tener asociado un alto grado de mantenimiento. Por otro lado las
herramientas genricas de validacin, no son siempre fciles de adaptar a dominios de
aplicacin concretos. Estas carencias cada vez son ms significativas por el tipo de sistemas que se construyen actualmente, sistemas compuestos de diferentes componentes,
distribuidos en muchos casos, y con configuraciones y comportamientos que pueden variar
dinmicamente.
Las herramientas de validacin y las de operacin/monitorizacin de sistemas tienen
caractersticas comunes, dado que la ejecucin de una prueba conlleva la operacin del
sistema con unas condiciones iniciales concretas. El concepto de frontend de operaciones
definido en esta tesis, es aplicable tanto al proceso de pruebas del sistema como al de
operacin/monitorizacin del sistema mediante herramientas software.
En el captulo 6 se ha aplicado el modelo de operaciones de un sistema como soporte
en el modelado de la interaccin entre sistema y frontend de operaciones. Se ha definido
un metamodelo de frontend de operaciones, OperationsFrontend Metamodel, a partir del
metamodelo de operaciones, SystemOperations Metamodel, definido en el captulo 5. El
metamodelo de frontend de operaciones definido contempla la representacin de la vista
del sistema perceptible por el operador en el frontend de operaciones, la interaccin entre
operador y sistema por medio de la creacin, compilacin y ejecucin de procedimientos
compuestos de comandos de operacin del sistema, as como la recepcin de respuestas y
256
notificaciones producidas en el sistema. Estos procedimientos representarn procedimientos de prueba en el caso de aplicar el frontend al proceso de pruebas del sistema, y representarn procedimientos de operacin en el caso de aplicarse a la operacin/monitorizacin
del sistema.
El frontend de operaciones representa en s una herramienta de operacin y/o pruebas
del sistema. La arquitectura conceptual del frontend definida en la seccin 6.3 (pgina
186) mediante cinco niveles de abstraccin, identifica cuatro componentes principales en
el frontend de operaciones: GUI, Frontend Engine, Repository Manager y Gateway. Esta
arquitectura es independiente del dominio del sistema bajo operacin, no as la herramienta
software que representa el frontend de operaciones. An as, la especificacin del modelo
de operaciones del sistema contribuir a reducir esfuerzos en la generacin o adaptacin
del frontend de operaciones para un sistema concreto, dado que:
Facilita la creacin de las interfaces software de operacin, llamadas OI (Operation
Interface) en la arquitectura conceptual del frontend de operaciones, para cada elemento del sistema, identificando las entradas y salidas para cada uno de ellos.
Sirve como base para definir la gramtica y lenguaje de operaciones del sistema,
proporcionando soporte en la generacin de los componentes Gateway y Frontend
Engine que tratan las entradas y salidas con el sistema.
Facilita la generacin de la GUI, identificando la vista del sistema perceptible por
el operador, esto es, elementos del sistema y sus propiedades perceptibles, as como
sus entradas y salidas representadas por comandos de operacin, respuestas, notificaciones y alarmas.
Independiza la parte del modelo de datos relativa a la interaccin entre sistema y
frontend de operaciones del dominio de aplicacin concreto, disendolo en base al
modelo de operaciones del sistema definido en esta tesis.
257
El frontend de operaciones representa una herramienta de validacin del sistema con la

que realizar pruebas de aceptacin, caja negra, a sistemas que posean una interfaz de operacin del sistema. As, el frontend proporciona a los ingenieros de pruebas un marco para
definir, compilar y ejecutar procedimientos de prueba sobre el sistema bajo prueba, y almacenar la informacin de los procedimientos de prueba y el resultado de sus ejecuciones.
La definicin de los procedimientos de prueba, se puede realizar mediante un lenguaje de
alto nivel, cercano al ingeniero de pruebas, descrito con una sintaxis orientada al dominio
de aplicacin. Un procedimiento de prueba estar compuesto de una serie de comandos de
operacin, que incluya comandos para especificar los valores de entrada, el procesamiento
de la prueba y los resultados esperados. El almacenamiento de los datos relativos a los resultados de las ejecuciones de los procedimientos de prueba en la base de datos del frontend
permite obtener el veredicto de las pruebas realizadas, e incluso validar algunos requisitos
que requieren la evaluacin del resultado de varias ejecuciones de un mismo procedimiento, o del resultado de un conjunto de procedimientos. Esta informacin tambin facilita la
realizacin de pruebas de regresin.
Utilizaremos el caso prctico visto en el captulo anterior para ilustrar la utilizacin del
frontend de operaciones como herramienta de pruebas y como herramienta de operacin.
La figura 40 muestra la interaccin con el sistema de mquinas de juego interconectadas,
por un lado con jugadores y por otro lado con operadores del sistema a travs del frontend
de operaciones.
1. Frontend de Operaciones como herramienta de validacin del sistema
El frontend de operaciones actuando como herramienta de validacin permite a un
ingeniero de pruebas realizar pruebas de aceptacin del sistema de mquinas de juego
interconectadas.
La validacin manual del sistema supone disponer de tantos jugadores (personas)
como mquinas interconectadas tenga el sistema. Si por ejemplo se quiere probar
258
Figura 40: Frontend de operaciones en procesos de validacin y operacin
259
el cumplimiento del requisito R2 (pgina 218) que indica que el premio acumulado jackpot debe estar comprendido entre 600 y 2000 veces el premio de la partida
simple, cada jugador ha de introducir monedas en la mquina acumulador que est
probando, observar los resultados del juego y registrarlos de alguna manera para su
posterior tratamiento. El nmero de jugadas a realizar en cada mquina ser elevado,
ya que habr que esperar a que se produzca un nmero n de premios jackpot.
La validacin asistida por la herramienta de validacin, esto es, el frontend de operaciones, reduce notablemente el esfuerzo de realizacin de las pruebas, siendo necesario eso s, que los elementos del sistema (mquinas) dispongan de una interfaz
software de operacin que posibilite la interaccin con el frontend de operaciones.
En este caso ser necesaria una nica persona, un ingeniero de pruebas, que confeccione el procedimiento de pruebas incluyendo entre otros los comandos de operacin
como asignacin de crditos y de espera condicionada a la consecucin de premio especial jackpot por parte de un acumulador. Los resultados de la prueba, respuestas a
los comandos de operacin y notificaciones enviadas por el sistema se presentan en la
GUI del frontend al ingeniero de pruebas y se almacenan en la base de datos para su
posterior tratamiento. El ingeniero de pruebas puede lanzar la prueba un nmero n
de veces para ser ejecutada de forma automtica por el frontend sin requerir ninguna
accin suya. Adems, el almacenamiento de datos de las pruebas y sus resultados
posibilita la realizacin de pruebas de regresin.
2. Frontend de Operaciones como herramienta de operacin/monitorizacin del sistema
El frontend de operaciones como herramienta de operacin/monitorizacin permite
que los jugadores puedan jugar de forma remota, y que el responsable de las mquinas pueda monitorizar el sistema. Al igual que en el caso anterior, los elementos del
sistema han de proporcionar una interfaz software de operacin. El funcionamiento
260
es anlogo al caso anterior, el operador (jugador) por medio del frontend de operaciones enva comandos de operacin al sistema y recibe las respuestas y notificaciones del sistema, lo que le permite monitorizar el juego.
8.3.
Enriquecimiento del proceso de desarrollo de sistemas
Uno de los objetivos de esta tesis es el enriquecimiento del proceso de desarrollo de

sistemas, mediante la incorporacin a dicho proceso del modelo de operaciones definido.
La lnea conductora para conseguir este enriquecimiento es la concepcin del desarrollo
de un sistema como una vista unificada para procesos que se centran en el sistema desde
diferentes perspectivas pero con un nivel similar de abstraccin del sistema. Este es el caso
del proceso de anlisis de requisitos y del proceso de validacin del sistema.
El estndar ISO-15288 [83] indica que el propsito del proceso de anlisis de requisitos es transformar la vista dirigida por los requisitos de los servicios deseados por los
stakeholders, en una vista tcnica del producto requerido que proporcione esos servicios.
Por otra parte, el proceso de validacin persigue obtener una evidencia objetiva de que los
servicios que proporciona un sistema cuando est en funcionamiento cumplen con los requisitos de los stakeholders. La validacin permite realizar una evaluacin comparativa y
confirmar que los requisitos de los stakeholders estn definidos correctamente.
El enriquecimiento del modelo de proceso que se propone se basa en una fuerte integracin entre el anlisis de requisitos y la validacin como hilo conductor en el desarrollo
de un sistema. Esta integracin se fundamenta en una slida trazabilidad entre los requisitos de los stakeholders y las pruebas de validacin del sistema. Se plantea que la validacin
del sistema se realice desde las etapas tempranas del desarrollo, definiendo el modelo de
operaciones del sistema que facilita, por un lado la generacin de una herramienta de validacin del sistema, y por otro lado, la definicin de las interfaces de operacin de cada uno
de los elementos que componen el sistema.
El proceso de desarrollo enriquecido por la especificacin del modelo de operaciones
261
Figura 41: Proceso de desarrollo enriquecido por el MOS
262
del sistema, se muestra en la figura 41, en el que se identifican las siguientes etapas:
1. Definir el concepto de sistema a desarrollar.
2. Identificar los requisitos de los stakeholders.
3. Definir el conjunto de pruebas de validacin.
4. Especificar los requisitos del sistema.
5. Definir el modelo de operaciones del sistema.
6. Definir la interfaz de operacin para cada elemento del sistema que sea perceptible
por el operador, a partir del modelo de operaciones del sistema.
7. Generar el frontend de operaciones o herramienta de validacin del sistema, a partir
del modelo de operaciones del sistema.
8. Construccin y/o simulacin de los componentes del sistema.
9. Ejecucin de las pruebas de validacin de los elementos del sistema a travs del
frontend de operaciones y pruebas definidas. Una vez implementada la interfaz de
operacin de un componente del sistema puede definirse un simulador del mismo y
participar en la pruebas aunque todava no se haya implementado completamente el
sistema.
10. Y como actividad paralela a los pasos anteriores se establece la trazabilidad correspondiente desde requisitos a componentes de diseo, incluyendo pruebas de validacin.
El enriquecimiento del proceso de desarrollo propuesto se basa en dos aspectos principales en el desarrollo del sistema, directamente relacionados con el modelo de operaciones
del sistema definido en esta tesis:
263
Desarrollo incremental del sistema, soportado por la definicin del modelo de operaciones del sistema
Validacin del sistema, soportada por la generacin de una herramienta de validacin
basada en el modelo de operaciones.
8.3.1. Desarrollo incremental del sistema
En esta tesis concebimos un sistema software como un conjunto de componentes interrelacionados. La base para un desarrollo incremental es alcanzar una adecuada trazabilidad
entre requisitos de stakeholders, requisitos del sistema y el resto de componentes arquitectnicos y unidades de cdigo [51] [10].
Los componentes se desarrollan e integran con otros componentes ya desarrollados o
con componentes simulados para los cuales se tenga definida una interfaz de operacin.
As, las pruebas de validacin se pueden ejecutar, aunque algunos componentes todava no
se hayan desarrollado, realizando una simulacin de stos y especialmente de sus interfaces
de interaccin. Esto permite que el equipo de desarrollo pueda centrarse en los requisitos
de los stakeholders, y pueda detectar tempranamente errores.
El proceso de validacin se centra en la existencia de un frontend de operaciones que
permita describir operaciones y resultados. La existencia de este frontend de operaciones,
junto con la trazabilidad desde requisitos a pruebas de validacin, permite un desarrollo
incremental del sistema [3] [11] [10] [5].
Las interfaces de operacin de cada uno de los elementos que componen el sistema se
definen a partir del modelo de operaciones, que se obtiene de los requisitos del sistema.
Una vez definida la interfaz de operacin del sistema, se crea, genera o adapta el frontend de operaciones desde el cul se pueda operar con el sistema. Desde este frontend de
operaciones se llevan a cabo las pruebas de validacin al sistema.
El modelo de operaciones del sistema dirige la construccin del sistema, facilitando
la creacin de la interfaz de operacin del sistema. As, el equipo de desarrollo puede ir
264
implementando los componentes del sistema, utilizando sus interfaces de operacin para ir
validndolos. Para esto, es preciso que el conjunto de pruebas de validacin se definan lo
antes posible. De esta manera el desarrollo del sistema va dirigido por la propia validacin
de sistema, y soportado por la especificacin del modelo de operaciones del sistema como
elemento clave en el desarrollo, que facilita la creacin de la interfaz de operacin del
sistema y de la herramienta de validacin del sistema, esto es, del frontend de operaciones.
8.3.2. Validacin del sistema
Uno de los aspectos fundamentales en los que se basa el modelo de proceso que se
propone es en la existencia del frontend de operaciones como herramienta de validacin
y operacin del sistema. El frontend de operaciones orientado a validacin debe permitir
definir, almacenar y ejecutar pruebas de validacin sobre el sistema, obtener los resultados
producidos por el sistema, y mostrar y almacenar dichos resultados.
El proceso de validacin del sistema debe determinar si el sistema desarrollado satisface
o no los requisitos. En el modelo de desarrollo incremental propuesto, se produce una
iteracin entre los pasos 8 y 9 hasta alcanzar una validacin exitosa del sistema.
Para validar el sistema se necesita tener un entorno que permita ejecutar las pruebas de
validacin sobre el sistema. Las pruebas de validacin estn compuestas de operaciones que
se especifican siguiendo el lenguaje del modelo de operaciones. El frontend de operaciones
debe implementar una interfaz que le permita interactuar con el sistema, reflejada en el
modelo de operaciones. Pero no basta con la ejecucin de las pruebas de validacin, es
preciso registrar los resultados, para poder determinar el cumplimiento de los requisitos.
Una vez definido el modelo de operaciones, la validacin del sistema comprende las
siguientes etapas:
1. Definicin del conjunto de pruebas de validacin para validar los requisitos de operacin.
2. Establecimiento de trazas entre requisitos y pruebas de validacin, que permitan
265
comprobar el cumplimiento de stos.

3. Aplicacin de las pruebas de validacin sobre el sistema y generacin de los informes
de validacin correspondientes.

En este captulo se ha analizado la utilizacin del modelo de operaciones de un sistema en procesos de desarrollo software y como soporte en la generacin de herramientas
de validacin y operacin de sistemas. Esta generacin de herramientas se basa en la especificacin del modelo de operaciones para particularizar la herramienta al dominio de
aplicacin concreto del sistema, y en la arquitectura conceptual definida anteriormente del
frontend de operaciones. Por ltimo se plantea un enriquecimiento del proceso de desarrollo de sistemas centrado en la especificacin del modelo de operaciones del sistema, en la
validacin de requisitos por medio del frontend de operaciones, y en la trazabilidad entre
requisitos y componentes del sistema a travs de las pruebas de validacin.
266
Captulo IX
CONCLUSIONES
Muchos de nuestros sueos parecen al principio imposibles,

despus pueden parecer improbables, y luego,
cuando nos comprometemos firmemente, se vuelven inevitables.
Christopher Reeve
267
Es este captulo se analiza cmo se han cumplido los objetivos indicados en el primer
captulo de la tesis, se mencionan las principales aportaciones del trabajo de investigacin
y se exponen las lneas que permanecen abiertas para futuros trabajos.
9.1. Anlisis del logro de objetivos

Al comienzo de este documento en la seccin 1.2 se ha presentado el conjunto de objetivos perseguidos con este trabajo, los cuales nos han permitido alcanzar el principal
objetivo marcado:
E ,
,
,
.
A continuacin se va a analizar el grado de cumplimiento de cada uno de los objetivos

parciales buscados:
1. Identificar y formalizar los conceptos conducentes a la especificacin del modelo
de interaccin de un sistema y de los elementos que lo forman. En el captulo 3
se ha definido una serie de conceptos relativos a entorno del sistema, operador del
sistema, interfaz de operacin, y sistema, como elemento individual y como conjunto de elementos interconectados. Estos conceptos han permitido realizar una nueva
definicin de sistema, a la que hemos llamado sistema operable, y de frontend de
operaciones, entendido ste como la interfaz que utiliza el operador para interactuar
con el sistema. A partir de stas dos definiciones, se han identificado varios tipos de
interaccin entre sistema y operador.
268
2. Definir el concepto de modelo de operaciones de un sistema, de forma que permita la incorporacin del conocimiento de las operaciones de manera explcita
en el modelado del sistema. Se ha definido el concepto de modelo de operaciones
de un sistema (MOS) en el captulo 4. Dicho modelo se ha expresado en funcin de
las entradas y salidas del sistema respecto de la interaccin con el operador. Estas
entradas se han definido a su vez como comandos de operacin, y las salidas como
respuestas a comandos y notificaciones producidas internamente en el sistema.
Adems, se han identificado los posibles mbitos de aplicacin del modelo de operaciones de un sistema. Se indica cul debe ser el subconjunto de requisitos de un
sistema necesario para definir el modelo de operaciones concreto, y cmo han de
reflejarse en el modelado de un sistema por medio del lenguaje UML.
3. Proponer metamodelos que faciliten la representacin de las operaciones en el
proceso de modelado de sistemas, y de su desarrollo en general. Este objetivo
se ha alcanzado en tres etapas. Primeramente, en el captulo 5 se ha definido un
metamodelo para representar el modelo de operaciones de un sistema en UML, al
que hemos llamado SystemOperationsMetamodel. A partir de este metamodelo se ha
definido un perfil UML al que hemos llamado U2OP (UML 2 Operations Profile)
aplicable en el modelado de sistemas.
En segundo lugar, y ya en el captulo 6, se han marcado las pautas para la especificacin de un frontend de operaciones genrico; dicho frontend representa la interfaz
mediante la cual el operador interacta con el sistema. Para ello, por un lado se ha
aplicado el metamodelo de operaciones definido anteriormente, en la especificacin
de un frontend de operaciones genrico. De esta manera se ha conseguido definir
un metamodelo de frontend de operaciones del sistema, que refleja la interaccin
entre el operador y el sistema. Por otro lado, se ha realizado una aproximacin, en
varios niveles de abstraccin, orientada a describir la arquitectura genrica de un
269
frontend de operaciones. Y para completar la especificacin de dicho frontend, se ha

planteado un conjunto de comandos bsicos de operacin del sistema que posibilita
el entendimiento entre frontend de operaciones y sistema. Este conjunto ser aplicable tanto al proceso de operacin/monitorizacin de un sistema, como al proceso de
validacin del mismo.
En tercer lugar, en el captulo 7 se ha aplicado el modelo de operaciones definido en
este trabajo a un caso prctico correspondiente a un sistema compuesto de mquinas de juego de azar interconectadas. Ha quedado patente la utilidad del perfil U2OP
definido al aplicarlo al modelado del sistema. El diagrama de clases decorado con
dicho perfil identifica explcitamente y de forma clara la parte del sistema perceptible por el operador del sistema, as como las entradas y salidas definidas para cada
elemento del sistema.
4. Enriquecer el proceso de desarrollo de sistemas, incorporando el modelo de operaciones en etapas iniciales del desarrollo de sistemas. En el captulo 8 se ha analizado en primer lugar la utilizacin del modelo de operaciones de un sistema en
procesos de desarrollo software, a partir de la aplicacin del perfil U2OP al caso
prctico descrito en el captulo 7. En segundo lugar, se analiza el modelo de operaciones del sistema como soporte en la generacin de herramientas de validacin y
operacin de sistemas. En tercer lugar se propone el enriquecimiento del modelo de
proceso de desarrollo software basado en la aplicacin del modelo de operaciones
del sistema en etapas tempranas del desarrollo, junto con una fuerte integracin entre
el anlisis de requisitos y la validacin como hilo conductor en el desarrollo de un
sistema. Esta integracin se fundamenta por un lado, en la especificacin del modelo
de operaciones del sistema en etapas tempranas del desarrollo y por otro lado, en una
slida trazabilidad entre los requisitos de los stakeholders y las pruebas de validacin
del sistema.
270
Consideramos que estos objetivos parciales se han alcanzado con el trabajo realizado,
por lo que el objetivo principal marcado se ha conseguido. Del mismo modo, podemos
concluir que la hiptesis de partida ha sido probada y por tanto afirmamos que:
E , .
9.2.
Aportaciones a la investigacin
Entre las aportaciones ms interesantes obtenidas tras las investigaciones realizadas en

esta tesis se pueden destacar las siguientes:
1. Aportaciones tericas y de investigacin de base:
a) Formalizacin de una serie de conceptos conducentes a la especificacin del
modelo de operaciones de un sistema intensivo software y de los elementos que
lo forman. As, se han definido entre otros los siguientes conceptos: sistema,
entorno de un sistema, elemento de un sistema, interfaz de operacin, sistema
operable, frontend de operaciones de un sistema y el conjunto de interacciones
existentes entre sistema y operador.
b) Definicin del concepto de modelo de operaciones de un sistema que permite
incorporar de manera explcita en el modelo de un sistema, la informacin relativa a las operaciones del mismo. Adems, se ha identificado el subconjunto de
los requisitos de un sistema que incluye la informacin necesaria para definir
un modelo de operaciones.
c) Propuesta de representacin del modelo de operaciones de un sistema, consistente en la especificacin UML del metamodelo SystemOperations y del perfil
271
U2OP. El perfil es una extensin de UML que facilita la representacin del

conocimiento de las operaciones de un sistema en el modelado de sistemas.
d) Propuesta de representacin del frontend de operaciones de un sistema, basada
en el modelo de operaciones definido anteriormente, consistente en un metamodelo UML y en una arquitectura conceptual genrica, que incluyen la relacin
de entradas y salidas entre el sistema y el frontend de operaciones. Las entradas
al sistema se han representado en forma de procedimientos de operaciones y
comandos de operacin, y las salidas del sistema como respuestas a los comandos de operacin y notificaciones generadas en el sistema. La arquitectura
conceptual genrica del frontend de operaciones de un sistema se basa en cinco niveles de abstraccin en la interaccin entre sistema y operador. Adems
se plantean una serie de comandos de operacin bsicos aplicables a diferentes
dominios de aplicacin de sistemas operables, que permiten el entendimiento
entre el frontend de operaciones y el sistema.
2. Aportaciones metodolgicas:
a) Este trabajo plantea la definicin explcita del modelo de operaciones en el
proceso de desarrollo de sistemas. El modelo de operaciones complementa al
modelo del sistema aportando una definicin clara y concisa de la interaccin
entre un sistema y un frontend de operaciones de ste.
b) Se propone un enriquecimiento del modelo de proceso software basado en el
modelo de operaciones de un sistema. La especificacin del modelo de operaciones en las etapas iniciales del proceso de desarrollo permitir agilizar el
desarrollo del sistema. Dicha especificacin proporciona la base para disponer
en etapas tempranas de una interfaz del sistema con el exterior y de un frontend de operaciones del sistema (herramienta software) proporcionando un marco adecuado para realizar las pruebas de validacin del sistema en desarrollo.
272
La existencia de dicho marco posibilita un desarrollo incremental, creando los

componentes del sistema gradualmente, e integrndolos con otros componentes
ya creados o simulados. Adems, el enriquecimiento propuesto se basa en una
fuerte integracin entre el anlisis de requisitos y la validacin como hilo conductor en el desarrollo de un sistema. Esta integracin se fundamenta en una
slida trazabilidad entre los requisitos de los stakeholders y las pruebas de validacin del sistema.
3. Aportaciones prcticas:
Como caso de aplicacin del perfil UML de operaciones del sistema, se ha incluido en el captulo 7 un caso de estudio relativo a un sistema de mquinas de juego
interconectadas.
9.3. Contraste de resultados

Las ideas originales desarrolladas en esta tesis y los resultados obtenidos se han publicado en diferentes foros que han permitido evaluar la calidad del trabajo realizado y las
conclusiones tomadas.
Las publicaciones que se relatan a continuacin tuvieron su inicio principalmente en
herramientas para la automatizacin de pruebas de aceptacin en el desarrollo de sistemas,
en concreto en el entorno de operacin y de pruebas TOPEN (Test and Operation Environment) [62]. La validacin de sistemas con la herramienta TOPEN mediante pruebas
de aceptacin nos proporcion una visin del sistema a probar basada en los elementos y
propiedades perceptibles del sistema y en sus entradas y salidas.
A partir de aqu, se realizaron trabajos en lnea con la integracin de herramientas, buscando la integracin de un entorno de pruebas y de un entorno de ingeniera del software,
en concreto de TOPEN y SEE (System/Software Engineering Environment) [22]. Esta integracin relaciona los requisitos del sistema con las pruebas de aceptacin de stos por
medio de esquemas de trazabilidad incorporados en los propios documentos [51]; y dota
273
al desarrollador de un frontend de operaciones del sistema integrado en su propio entorno

de desarrollo, facilitando y simplificando las tareas de validacin del sistema. Se disearon
esquemas de documentos en el SEE que permitieron la integracin de los datos de pruebas
con los datos de desarrollo del sistema. Y se defini una interfaz de operacin, similar a la
del sistema a operar/probar, en el frontend de operaciones, accesible desde el SEE.
Otro de los aspectos abordados lo constituye el modelado de la interaccin entre operador y sistema, y el enriquecimiento del modelo de proceso de desarrollo de sistemas
basado en dicho modelado y en la utilizacin de herramientas de validacin y de ingeniera
de software.
A continuacin se relacionan los trabajos publicados hasta la fecha relacionados con
esta tesis doctoral, incluyendo un resumen de los mismos y la relacin con los contenidos
de la misma.
1. Deployment of an Acceptance Testing Environment Prototype: an Architectural View [6].
Pedro P. Alarcn, Jos M. Lzaro, Juan Garbajosa, Jose Maseda.
First Workshop on Systems Validation (SV02), in conjunction with the 15th International Conference on Software and Systems Engineering and their Applications
(ICSSEA02).
December 2002. Paris, France.
Resumen: En este primer artculo se plantea la importancia que tienen las pruebas de aceptacin en el desarrollo de sistemas complejos, y cmo las herramientas
pueden contribuir a automatizar el proceso de pruebas de aceptacin. Se detalla la
arquitectura del entorno de operacin y validacin TOPEN, que es distribuida e independiente del dominio de aplicacin, facilitando el tele-testing y la adaptacin a
diferentes sistemas. Se describe la interaccin de TOPEN con el sistema a probar
en trminos de una gramtica que incluye comandos de operacin, notificaciones y
alarmas.
274
Relacin con la Tesis: TOPEN constituy en s la primera aproximacin a lo que se

ha definido en esta Tesis como frontend de operaciones del sistema. Por otra parte,
la descripcin de la interaccin entre TOPEN y el sistema se tom como una de las
ideas centrales a la hora de intentar modelizar las operaciones de un sistema.
2. Deployment and Future Development of TOPEN, a Low-Cost Tele-Testing Validation Environment [2].
Pedro P. Alarcn, Juan Garbajosa.
2nd ESA Space Systems Design, Verification and AIT Workshop.
April 2003. ESTEC, Noordwijk, The Netherlands.
Resumen: En este artculo se presentan una serie de lneas a seguir en el desarrollo futuro de TOPEN hacia un entorno de validacin de bajo coste que facilite la
automatizacin de pruebas en sistemas. Se plantea una idea inicial de desarrollo
de sistemas incremental basado en modelo, en el que el modelo de las operaciones
del sistema sea un aspecto central. Partiendo de dicho modelo de operaciones se
propone que las pruebas de validacin estn disponibles en etapas tempranas del
desarrollo, de manera que puedan llevarse a cabo las pruebas de validacin tempranamente sobre los componentes desarrollos o simulados. La estrategia de automatizacin propuesta incluye un entorno de ingeniera del software (SEE) centrado
en documento, que facilite la trazabilidad entre requisitos y pruebas.
Relacin con la Tesis: En este artculo se proponen las lneas bsicas de una estrategia de desarrollo centrada en el modelo de operaciones del sistema, integrando un
entorno de ingeniera del software y un entorno de operacin/pruebas que facilite la
relacin y trazabilidad entre requisitos y pruebas en etapas tempranas del desarrollo.
3. Nuevos Enfoques para la Utilizacin del Concepto de Documento como Mecanismo de Integracin de Procesos y Herramientas.
Pedro P. Alarcn.
275
Trabajo de investigacin de doctorado. Tutor: Juan Jos Navarro y Juan Garbajosa.

Octubre 2003. Facultad de Informtica, UPM.
Resumen: El trabajo se centr en la integracin de herramientas internas y externas
dentro de un entorno de ingeniera del software basada en el concepto de documento
(utilizando el formato XML). Se defini un tipo de esquema de documento que contemplaba estructura, plantilla y funcionalidad (operaciones asociadas a los tipos de
tag) para los documentos basados en el esquema. Se disearon esquemas y documentos para un modelo de proceso de desarrollo concreto basado en las normas
ECSS de la ESA.
Relacin con la Tesis: Se disearon los esquemas de documentos en el entorno de
ingeniera del software SEE, orientados a permitir la integracin con otras herramientas verticales. Uno de los objetivos de este trabajo se bas precisamente en explorar
las posibilidades de integracin del entorno de operacin TOPEN con el SEE, para
conseguir la definicin, ejecucin y registro de datos de pruebas desde el SEE, facilitando la documentacin y trazabilidad de pruebas con requisitos.
4. Use of System Models to Automate the Integration Requirements and Validation Tests [3].
Pedro P. Alarcn, Juan Garbajosa, Manuel Bollain y Beln Magro.
2nd Workshop on Systems Testing and Validation (STV03), in conjunction with the
IEEE Software Technology and Practice Workshop, STEP2003.
September 2003, Amsterdam, The Netherlands.
Resumen: Se plantea una primera aproximacin de un modelo de desarrollo incremental basado en la integracin de los requisitos del sistema y las pruebas de
aceptacin. Este modelo se centra, por un lado en la generacin de herramientas de
operacin y validacin del sistema a partir del modelo del sistema. Y por otro lado,
en la integracin de estas herramientas con entornos de ingeniera del software que
276
ofrezcan un marco para la integracin de requisitos del sistema con las pruebas de
aceptacin.
Relacin con la Tesis: La generacin de herramientas de operacin y validacin a
partir del modelo del sistema, plante la necesidad de aadir algn tipo de informacin y semntica adicional al modelo del sistema. Esto nos condujo a la idea de
modelar las interacciones entre un sistema y una herramienta software externa, como
inicio del modelo de operaciones de un sistema presentado en esta tesis.
5. Modeling Language Interpretation for Validation [11].
Pedro P. Alarcn, Juan Garbajosa, Agustn Yage, Alexei Lisounkin, G. Schreck
11th Annual International Workshop on Software Technology and Practice.
ISBN: 0-7695-2218-1
September 2003, Amsterdam, The Netherlands.
Resumen: Este artculo presenta una aproximacin a un lenguaje de modelado que
soporte la verificacin de modelos de sistemas, y la construccin de simuladores que
simulen el comportamiento del sistema. El lenguaje, llamado XNetMod, est basado
en XML y permite describir sistemas como conjuntos de elementos interconectados.
La verificacin de modelos se realiza con un algebra definida al efecto, y los simuladores se generan a partir de la definicin del modelo del sistema con el lenguaje
XNetMod.
Relacin con la Tesis: Al igual que en el artculo anterior, con este trabajo nos
planteamos sistemas compuestos por elementos interconectados, y avanzamos en la
construccin de simuladores a partir de modelos del sistema que nos permitieran
interaccionar con el sistema.
6. Construction of Verified Models for Systems Represented as Networks [177].
Agustn Yage, Pedro P. Alarcn, Juan Garbajosa, Alexei Lisounkin, Gerhard Schreck
277
The 2nd International Workshop on Verification and Validation of Enterprise Information Systems (VVEIS-2004).
ISBN: 972-8865-02-3
April 2004, Porto, Portugal.
Resumen: Este artculo presenta un lenguaje y un proceso para producir modelos
verificados para sistemas con elementos interconectados. Los modelos de sistemas
se especifican por medio de un lenguaje basado en XML, llamado XNetMod. Los
esquemas XML se derivan de modelos de sistema expresados en UML. El objetivo
principal del lenguaje XNetMod es el de soportar la simulacin del comportamiento
de sistemas por medio de esquemas verificados con en este lenguaje. El lenguaje y el
mtodo de construccin de modelo se han aplicado satisfactoriamente a diferentes
dominios de aplicacin, descritos en trminos de sistemas con elementos interconectados.
Relacin con la Tesis: Este trabajo plantea la representacin de sistemas como conjunto de elementos interconectados, definiendo un lenguaje para representarlos. Este
trabajo avanz en la lnea de considerar y modelar los sistemas como conjuntos de
elementos interconectados.
7. Automated Integrated Support for Requirements-Area and Validation Processes Related to System Development [10].
Pedro P. Alarcn, Juan Garbajosa, Alberto Crespo, Beln Magro.
Proceedings of the 2nd IEEE International Conference on Industrial Informatics (INDIN04).
ISBN-0-7803-8513-6
IEEE Press 2004. June 2004, Berlin, Germany.
278
Resumen: En lnea con trabajos anteriores, este artculo describe un modelo de procesos que plantea la mejora en la automatizacin del desarrollo de sistemas mediante la integracin de los procesos de anlisis de requisitos y pruebas de validacin
del sistema. Para ello, se plantea la integracin de herramientas externas de validacin, en un entorno de ingeniera de software orientado a documentos llamado
SEE. Esta integracin posibilita la definicin y ejecucin de procedimientos de prueba compuestos de comandos de operacin en el SUT (System Under Test) a travs
de TOPEN. En combinacin con la utilizacin de simuladores del SUT, esta aproximacin proporciona un buen soporte en procesos de desarrollo de sistemas.
Relacin con la Tesis: Se presenta cono aspecto clave en el desarrollo de sistemas,
el concepto de operaciones del sistema como soporte en el proceso de validacin.
La disponibilidad de un frontend de operaciones del sistema en las etapas iniciales
del desarrollo requiere que ste pueda generarse o adaptarse a partir de los modelos
iniciales del sistema. Para ello es fundamental que dicho modelo incluya los aspectos de operaciones del sistema y que el frontend de operaciones disponga de una
arquitectura independiente del dominio de aplicacin.
8. Automated Support for Requirements and Validation Test as Development Drivers
[5].
Pedro P. Alarcn, Juan Garbajosa, Alberto Crespo, Beln Magro.
Proceedings of the third Workshop on Systems Testing and Validation (SV04), in
conjunction with the 17th International Conference on Software and Systems Engineering and their Applications (ICSSEA04).
ISBN: 3-8167-6677-3
Proceedings Published by Fraunhofer IRB Verlag, Germany.
December 2004, Paris, France.
279
Resumen:En este artculo se presenta una aproximacin en la que la automatizacin de las pruebas de validacin constituye la lnea conductora en el desarrollo de
sistemas/software. El desarrollador o ingeniero de pruebas interacta con el sistema
a probar (SUT) desde un entorno de ingeniera del software (SEE) que integra el
entorno TOPEN. Las pruebas de aceptacin se asocian a los requisitos que validan,
en forma de procedimientos de comandos del lenguaje de operaciones del sistema
definido en TOPEN. Los procedimientos de prueba y los resultados de sus ejecuciones sobre el SUT se integran en los propios documentos del SEE. Se plantean
ciertos esquemas de documentos del SEE que permiten la integracin de los datos
de pruebas con los datos de desarrollo del sistema. La trazabilidad entre requisitos,
componentes desarrollados y pruebas de aceptacin juega un papel esencial en esta
integracin.
Relacin con la Tesis: La automatizacin de las pruebas de validacin se plantea
en trminos de existencia de un frontend de operaciones del sistema. Este frontend
de operaciones interacta directamente con el sistema por medio de un lenguaje de
operaciones definido entre ambos. El frontend puede integrarse en el propio entorno
de ingeniera del software utilizado por desarrolladores del sistema. Esta integracin
relaciona los requisitos del sistema con las pruebas de aceptacin de stos por medio
de esquemas de trazabilidad incorporados en los propios documentos.
9. Deploying Validation Tests in Systems Development [63].
Juan Garbajosa, Pedro P. Alarcn
3rd International Industrial Simulation Conference (ISC2005).
ISBN: 90-77381-18-X
June 2005, Berlin, Germany.
Resumen: En lnea con la aproximacin de automatizacin, descrita en anteriores
artculos, basada en la integracin de requisitos y pruebas de aceptacin se plantea
280
la utilizacin de simuladores del sistema en desarrollo, para conseguir un desarrollo

incremental del sistema dirigido por las pruebas. Se detallan los diferentes modos
propuestos para integrar los entornos TOPEN y SEE, y la propuesta de integracin
de los datos de prueba, procedimientos y resultados de ejecucin, en los documentos
del proyecto gestionados por SEE.
Relacin con la Tesis: La especificacin del modelo de operaciones de un sistema en
las etapas tempranas del desarrollo posibilita un desarrollo incremental del sistema,
basado en la existencia de simuladores. El modelo de operaciones proporciona la
informacin necesaria para generar simuladores del sistema a desarrollar, en los que
son fundamentales las interfaces de operacin que posibilitarn la interaccin con el
sistema.
10. TOPEN Data Model and Analysis for System Validation [9].
Pedro P. Alarcn, Agustn Yage, Juan Garbajosa, Jessica Daz.
Proceedings of the Forth Workshop on Systems Testing and Validation (STV06), in
conjunction with the 13th Anual IEEE International Conference and Workshop on
the Engineering of Computer Based Systems (ECBS 2006).
ISBN: 3-8167-7072-X
Proceedings Published by Fraunhofer IRB Verlag, Germany.
March 2006, Potsdam, Germany.
Resumen: Este artculo describe un modelo de datos para la operacin / monitorizacin y validacin de sistemas, que toma como punto de partida el modelo de datos
del repositorio incluido en TOPEN. El modelo de datos se ha diseado pensando en
trminos de independencia del dominio de aplicacin y para sistemas compuestos de
elementos inter-relacionados. Un repositorio basado en este modelo de datos permite evaluar de forma automtica el cumplimiento de las pruebas de aceptacin del
sistema.
281
Relacin con la Tesis: El modelo de datos presentado en este artculo cubre la informacin aportada por el modelo de operaciones de un sistema. Este modelo define
datos para representar el sistema bajo operacin/prueba, para especificar y ejecutar
procedimientos de prueba u operaciones y para la evaluacin del resultado de los
datos obtenidos al ejecutar estos procedimientos sobre el sistema.
11. Analyzing and Systematizing Current Traceability Schemas [52].
Angelina Espinoza, Pedro P. Alarcn, Juan Garbajosa.
30th Annual NASA/IEEE Software Engineering Workshop.
ISSN: 1550-6215
April 2006, Columbia, USA.
Resumen: Este trabajo presenta un modelo de trazabilidad al objeto de utilizar de
forma destacada informacin de trazabilidad en procesos y tareas, tales como verificacin y validacin, y gestin de la configuracin. Este artculo analiza varias de
las aproximaciones de trazabilidad actuales para obtener sus caractersticas ms
relevantes, obtener solapamientos e inconsistencias entre ellas, y as intentar seleccionar las mejores prcticas de trazabilidad. Se identifican varios aspectos que
dificultan la adopcin de actividades de trazabilidad a gran escala, en la prctica
de la ingeniera de software/sistemas, tales como, la inexistencia de una definicin
de trazabilidad comnmente aceptada, una forma estndar de especificar la trazabilidad entre artefactos, y una clasificacin del tipo de trazabilidad. Finalmente se
proporciona una aproximacin para realizar una especificacin de esquema de trazabilidad e implementarla en el entorno de ingeniera del software SEE.
Relacin con la Tesis: Este artculo profundiza en la definicin de un esquema de
trazabilidad que incluya requisitos, pruebas y gestin de configuracin, y su incorporacin al entorno de ingeniera del software SEE. Este trabajo persegua profundizar
en un modelo de desarrollo dirigido por las pruebas de validacin integradas con los
282
requisitos que validan, por medio de trazas. La utilizacin de un frontend de operaciones, como TOPEN, para llevar a cabo la operacin y pruebas sobre el sistema a
probar, contina siendo una de las lneas conductoras en la investigacin que produjo
como resultado este artculo.
12. Analyzing and Systematizing Current Traceability Schemas [51].
Angelina Espinoza, Pedro P. Alarcn, Juan Garbajosa.
Proceedings of the 30th Annual NASA/IEEE Software Engineering Workshop.
ISBN: 0-7695-2624-1
IEEE Computer Society
2006, Washington, USA.
Resumen: El anterior artculo fue seleccionado para ser publicado por IEEE Computer Society, por lo que esta publicacin coincide con la anterior salvo algunos
cambios mnimos.
Relacin con la Tesis: La misma que la publicacin anterior.
13. TOPEN como Soporte para la Automatizacin de Especificaciones en TTCN3 [7].
Taller sobre Pruebas en Ingeniera del Software PRIS 200, en conjuncin con las XI
Jornadas de Ingeniera del Software y Bases de Datos, JISBD06.
October 2006, Sitges, Spain.
Resumen: La complejidad creciente de los sistemas actuales intensivos en software
requiere de tcnicas que permitan aumentar la efectividad del proceso de pruebas.
TTCN-3 es un lenguaje de pruebas consensuado internacionalmente para definir
escenarios de pruebas de sistemas y sus implementaciones. TOPEN es un entorno
de validacin y operacin, diseado para facilitar el proceso de definicin y ejecucin de pruebas y procedimientos en sistemas complejos. Este artculo presenta
283
una propuesta para automatizar la generacin de un entorno de pruebas a partir de

una especificacin TTCN-3, tomando como base la arquitectura y funcionalidad de
TOPEN.
Relacin con la Tesis: El objetivo de este artculo fue demostrar que la arquitectura y
funcionalidades definidas para un frontend de operaciones, representado por TOPEN,
y el modelo de operaciones que subyace en la interaccin entre el frontend de operaciones y el sistema, son vlidos para generar de forma automtica el frontend de
operaciones a partir de especificaciones en lenguajes utilizados por la industria como
TTCN-3.
14. TOPEN como Soporte para la Automatizacin de Especificaciones en TTCN3 [8].
Revista Espaola de Innovacin, Calidad e Ingeniera del Software, Volume 2, Number 2. Revista electrnica publicada por la Asociacin de Tcnicos en Informtica
(ATI). ISSN: 1885-4486
October 2006.
Resumen: El anterior artculo fue seleccionado para ser publicado en la revista
REICIS, por lo que esta publicacin coincide con la anterior salvo algunos cambios
mnimos.
Relacin con la Tesis: La misma que la publicacin anterior.
15. Identifying Application Key Knowledge through System Operations Modeling [4].
Pedro P. Alarcn, Juan Garbajosa.
6th IEEE International Conference on Cognitive Informatics (ICCI 2007).
ISBN: 978-1-4244-1328-7
August 2007, Lake Tahoe, California.
284
Resumen: Uno de los problemas asociados con la ingeniera de sistemas complejos

es identificar el conocimiento que sea relevante de un sistema para poder construirlo. Este trabajo destaca la importancia de los modelos de operaciones del sistema, y
justifica por qu representan una parte clave del conocimiento del sistema para describir un sistema en el contexto de ingeniera de sistemas complejos. Los estndares
de ingeniera de sistemas y software resaltan la importancia de las operaciones del
sistema; hay disponibles plantillas para un concepto de documento de operaciones
en diferentes cuerpos de estndares en el contexto de ingeniera de requisitos y especificacin. Sin embargo, no suelen proporcionar guas especficas para el modelado de operaciones. Este artculo introduce una aproximacin para modelar de forma
sistemtica las operaciones de un sistema. Primeramente se define modelo de operaciones de un sistema, y basado en esta definicin se propone un metamodelo UML
para realizar el modelado de las operaciones de un sistema. El modelo de operaciones se define en trminos de comandos de entrada al sistema, y diferentes clases
de salidas del sistema clasificadas en respuestas, notificaciones y alarmas. El modelo de operaciones que se presenta en este artculo comprende una parte esencial
en el conocimiento de un sistema desde un punto de vista funcional, pero reducido
en tamao comparado con la especificacin completa del sistema. En esta lnea, se
plantea la utilizacin del modelo de operaciones, desde las etapas tempranas del
ciclo de vida, como conductor en el desarrollo y validacin de sistemas.
Relacin con la Tesis: En este artculo se presenta una definicin del modelo de
operaciones de un sistema y un metamodelo UML para representarlo. Adems se
presenta una aproximacin para el desarrollo de sistemas complejos basada en el
modelo de operaciones del sistema.
285
9.4. Lneas de investigacin futuras

Una vez realizadas las tareas de investigacin de la tesis, se proponen posibles ampliaciones y lneas de investigacin futuras relacionadas con el tema:
1. Extensin del modelo de operaciones del sistema, incorporando nuevos conceptos
tales como roles de operador que permitan contemplar las operaciones que pueda
utilizar cada tipo de operador y las notificaciones que pueda recibir, as como los
elementos del sistema que le sean accesibles. Esta ampliacin afectara tambin al
metamodelo y perfil UML de operaciones del sistema definidos, y al metamodelo del
frontend de operaciones del sistema.
2. Formalizacin de las restricciones de los metamodelos definidos, incorporando SDL
(Specification and Description Language) para representar el sistema y OCL (Object
Constraint Language) para representar las restricciones del modelo, facilitando la
transformacin entre modelos.
3. Incorporacin de iconografa grfica al perfil U2OP definido.
4. Generacin automtica o semiautomtica del frontend de operaciones del sistema
basada en el desarrollo dirigido por modelos, a partir de la especificacin del modelo
de operaciones del sistema, y por medio de transformaciones de modelos.
5. Incorporacin del modelo de operaciones del sistema como elemento clave en el
desarrollo de sistemas dirigidos por modelos.
6. El modelo de operaciones tambin puede aplicarse en la Computacin Autonmica
(Autonomic Computing). Lin plantea que uno de los objetivos de la computacin autonmica es la de crear sistemas que puedan auto-gestionarse y que puedan ocultar
a los usuarios finales la complejidad del propio sistema [110]. El trabajo de Kephart
[98] tambin describe el Autonomic Computing (AC) y los sistemas autonmicos
286
como sistemas que son capaces de gestionarse por s mismos. De forma que los
elementos que los constituyen ofrecen funcionalidades de monitorizacin, anlisis,
planificacin y ejecucin de operaciones de control para la gestin de recursos. Existen cuatro caractersticas distintivas de un sistema autonmico: auto-configurable,
auto-reparable, auto-optimizable, auto-protegible [18]. La definicin del modelo de
operaciones de un sistema que se propone en este trabajo coincide con este objetivo
ya que busca definir las entradas y salidas del sistema respecto a sus operadores y
ocultando su comportamiento y por tanto la complejidad del sistema.
7. Aplicacin del modelo de operaciones en procesos de validacin de sistemas intensivos software de nueva creacin o con componentes ya existentes, buscando la
generacin de herramientas de validacin basadas en dicho modelo e independientes
de las plataformas de los componentes que integren un sistema.
9.5.
Conclusiones finales
Esta tesis doctoral introduce una aproximacin para modelar de forma sistemtica las
operaciones en sistemas intensivos software. Se realiza una definicin conceptual de modelo de operaciones de un sistema, y basado en esta definicin se proponen un metamodelo
y un perfil UML para incorporar el modelado de las operaciones en el modelo de un sistema. Previamente a la definicin de modelo de operaciones se realizan una serie de definiciones sobre las que se apoya, entre las que destacan las de sistema operable y frontend de
operaciones. El modelo de operaciones se define en trminos de comandos de entrada al
sistema, y diferentes tipos de salidas del sistema clasificadas en respuestas, notificaciones
y alarmas. El modelo de operaciones que se presenta en este trabajo comprende una parte
esencial en el conocimiento de un sistema desde un punto de vista funcional, pero reducido
en tamao comparado con la especificacin completa del sistema. En esta lnea, se plantea
la utilizacin del modelo de operaciones del sistema y de herramientas basadas en este modelo, desde las etapas tempranas del ciclo de vida, como forma de enriquecer el proceso de
287
desarrollo y validacin de sistemas.
288
REFERENCIAS
[1] A, G. D. and D, A. J., Integrating status and event phenomena in formal specifications of interactive systems, in Proceedings of the 2nd ACM SIGSOFT symposium on Foundations of software engineering (SIGSOFT 94), pp. 4452, ACM
Press, 1994. 2.6
[2] A, P. P. and G, J., Deployment and future development of topen,
a low-cost tele-testing validation environment, in 2nd ESA Space System Design,
Verification and AIT Workshop, (Noordwijk, The Netherlands), April 2003. 1.2, 2
[3] A, P. P. and G, J., Use of system models to automate the integration
requirements and validation tests, in 2nd Workshop on Systems Testing and Validation (STV03), in conjunction with the IEEE Software Technology and Practice
Workshop, STEP03, (Amsterdam, The Netherlands), September 2003. 1.2, 8.3.1, 4
[4] A, P. P. and G, J., Identifying application key knowledge through
system operations modeling, in Proceedings of the 6th IEEE International Conference on Cognitive Informatics (ICCI07), (Lake Tahoe, California), pp. 246254,
IEEE CS Press, August 2007. 1.1, 1.2, 15
[5] A, P. P., G, J., C, A., and M, B., Automated support for
requirements and validation test as development drivers, in Proceedings of the third
Workshop on Systems Testing and Validation (SV04), in conjunction with the 17th
International Conference on Software and Systems Engineering and their Applications (ICSSEA04), (Paris, France), December 2004. 1.2, 8.3.1, 8
[6] A, P. P., L, J. M., G, J., and M, J., Deployment of an
acceptance testing environment prototype: an architectural view, in First Workshop
on Systems Validation (SV02) in conjunction with the 15th International Conference
on Software and Systems Engineering and their Applications (ICSSEA02), (Paris,
France), December 2002. 1.2, 7.2.1, 1
[7] A, P. P., Y, A., G, J., and D, J., Topen como soporte para la
automatizacin de especificaciones en ttcn-3, in Taller sobre Pruebas en Ingeniera
del Software (PRIS 2006) dentro de JISBD06, (Sitges, Spain), October 2006. 1.2,
2.4.2.2, 13
[8] A, P. P., Y, A., G, J., and D, J., Topen como soporte para la
automatizacin de especificaciones en ttcn-3, REICIS: Revista Espaola de Innovacin, Calidad e Ingeniera del Software. http://www.ati.es, vol. 2, pp. 617, October 2006. 1.2, 2.4.2.2, 14
289
[9] A, P. P., Y, A., G, J., and D, J., Topen data model and analysis for system validation, in Proceedings of the Forth Workshop on Systems Testing
and Validation (STV06), in conjunction with the 13th Anual IEEE International
Conference and Workshop on the Engineering of Computer Based Systems (ECBS
2006), (Potsdam, Germany), March 2006. 1.2, 10
[10] A, P. P., G, J., C, A., and M, B., Automated integrated
support for requirements-area and validation processes related to system development, in Proceedings of the 2nd IEEE International Conference on Industrial Informatics (INDIN04), (Berlin, Germany), pp. 287292, IEEE Computer Society,
June 2004. 1.2, 8.3.1, 7
[11] A, P. P., G, J., Y, A., L, A., S, G., and E, J. L., Modeling language interpretation for validation, in Proceedings of the
Eleventh Annual International Workshop on Software Technology and Engineering
Practice: STEP03, pp. 247256, IEEE Computer Society, 2003. 2.6, 8.3.1, 5
[12] American Institute of Aeronautics and Astronomics (AIAA), ANSI/AIAA G-0431992 Version 1.50. Guide for the Preparation of Operational Concept Documents,
January 1993. 1.1, 2, 2.4.1, 2.6, 4.5
[13] A, E., B, L. C., H, S. E., and L, Y., The impact of uml documentation on software maintenance: An experimental evaluation, IEEE Transactions on Software Engineering, vol. 32, pp. 365381, June 2006. 2.5
[14] A, C. and K, T., Model-driven development: A metamodeling foundation, IEEE Software, vol. 20, no. 5, pp. 3641, 2003. 2.5
[15] A, D., L, F., M, M., and N, P., Action research, Communications
of the ACM, vol. 427, pp. 9497, 1999. 1.3
[16] B, P., D, Z. R., G, J., H, O., S, E., S,
I., and W, C. E., The UML 2.0 Testing Profile, in Proceedings of the 8th
Conference on Quality Engineering in Software Technology (CONQUEST 2004) in
Nuremberg (Germany), pp. 181189, ASQF e.V., Erlangen, September 2004. 2.4.2.2
[17] B, R. and P-H, J., Grounded action research: a method for understanding it in practice, Accounting, Management and Information Technology,
vol. 9, pp. 123, 1999. 1.3
[18] B, J., Understand the autonomic manager concept, IBM White paper, Feb 2004.
6
[19] B, J., A, M. S., R, S., and W, L.-C., A survey of hybrid techniques
for functional verification, IEEE Design & Test of Computers, pp. 112122, 2007.
2.3.1, 2.6
290
[20] BOE, Real decreto 2110/1998, de 2 de octubre, por el que se aprueba el reglamento
de mquinas recreativas y de azar, No. 248, pp. 3422734244, Boletn Oficial del
Estado de Espaa, Octubre 1998. 7.2.1, 1
[21] BOE, Orden de 26 de febrero de 2001 por la que se actualiza el precio de la partida y los premios mximos en las mquinas recreativas y se dictan las previsiones
necesarias para su adaptacin al euro, No. 53, pp. 78327833, Boletn Oficial del
Estado de Espaa, Marzo 2001. 7.2.1, 2
[22] B, M., A, P. P., G, J., and A, J., A low-cost documentcentric software/system engineering environment, in Proceeding of the International Conference on Software and Systems Engineering and their Applications (ICSSEA03), (Paris, France), December 2003. 9.3
[23] B, E. and S, R., Abstract State Machines. A Method for High-Level System
Design and Analysis. Springer, 2003. 2.2.6
[24] B, M., Characterizing the behavior of reactive systems by trace sets, Tech. Rep.
TUM-I9102, Technische Universitat Munchen, 1995. I, 2.2.3, 2.2.4, 2.2.4.1, 2.2.4.1,
3, 2.6, 3.2.2, 3.2.4, 3.2.4.1, 3.2.4.2
[25] B, M., A Logical Basis for Modular Software and Systems Engineering. Lecture
Notes of Computer Science 1521. Springer, 1998. 2.2.4
[26] B, M., Automotive software engineering, in Proceedings of the 25th International Conference on Software Engineering (ICSE03), (Portland, Oregon, USA),
pp. 719720, 2003. 2.2.4, 2.2.4.2
[27] B, M., Hierarchies of Models for Embedded Systems, in First ACM and IEEE
Conference on Formal Methods and Models for Co-Design, pp. 183190, IEEE
Computer Society, 2003. 2.2.4
[28] B, M., Architecture driven modeling in software development, Proceedings of
Ninth IEEE International Conference on Engineering Complex Computer Systems
(ICECCS04), pp. 312, 2004. 2.2.4, 2.2.4.2, 2.2.4.2
[29] B, M., The grand challenge in informatics: Engineering software-intensive
systems, IEEE Computer, vol. 39, no. 10, pp. 7280, 2006. 1.1
[30] B, M. and S, P., Systems engineering needs a formal basis, in Proceedings
of the 17th Digital Avionics Systems Conference (DASC98), vol. 1, (Bellevue, WA,
USA), pp. B14/1B14/8, Oct 1998. 2.2.4, 2.2.4.2
[31] B, M. and S, K., Specification and Development of Interactive Systems:
Focus on Streams, Interfaces, and Refinement. Springer, 2001. I, 2.2.3, 2.2.4, 2.2.4.2,
4, 2.2.4.2, 2.6, 3.2.3.1, 3.2.4.2
291
[32] B, M., Ontology i: The furniture of the world, vol. 3 of treatise on basic philosophy, reidel, dordrecht and boston, Reidel, Dordrecht, Boston, 1977. 2.2.1, 2.2.1,
3.2.2
[33] B, J., H, S., L, D., and J, F., Applying mda approach for
web service platform, in Proceedings of the IEEE Enterprise Distributed Object
Computing Conference (EDOC), (Monterey, CA, USA), pp. 5870, IEEE Computer
Society, 2004. 2.5
[34] C, J. and G, C., Deriving operation contracts from uml class diagrams, in
10th International Conference MoDELS 2007, vol. 4735 of Lecture Notes in Computer Science, pp. 196210, Springer, 2007. 2.3.3, 2.3.6
[35] C D T D R I,
Systems Engineering Guidebook For ITS. Prepared by ASE Consulting LLC, Knowledge Systems Design (KSD) and Siemens ITS; in association with R.C. Ice and Associate MetroStar Systems Inc., J and J Project Consultant and Jacoby Consulting,
January 2007. 1.1, 2.4.1, 1, 2.6, 4.5
[36] C, J. and H, M. D., Model checking interactor specifications, Automated Software Engineering, vol. 8, pp. 275310, 2001. 2.3.1, 2.6
[37] C, J., H, M. D., and L, K., Verifying user interface behaviour with
model checking, in Proceedings of the 2nd International Workshop on Verification
and Validation of Enterprise Information Systems (VVEIS04), pp. 8796, INSTICC
Press, 2004. 2.3.1, 2.6
[38] C, S. and W, R. J., Composition patterns: An approach to designing
reusable aspects, in Proceedings of the International Conference on Software Engineering (ICSE01), (Washington, DC, USA), pp. 514, IEEE Computer Society,
2001. 2.5
[39] C, C., J, T., M, H., and R, V., Integrating formal verification and conformance testing for reactive systems, IEEE Transactions on Software
Engineering, vol. 33, pp. 558574, August 2007. 2.3.1
[40] C, S. and R, J., Automatic test case generation from requirements
specifications for real-time embedded systems, in Proceedings of the IEEE International Conference on Systems, Man, and Cybernetics (SMC 99), vol. 5, pp. 784
789, IEEE Computer Society, October 1999. 2.5
[41] D, Z., Model-driven testing with uml 2.0, in Proceedings of the 2nd European
Workshop on Model Driven Architecture, 2004. 2.5
[42] D, Z. R., Analysis of the methods and processes for UML test profiles (Deliverable
D2.4.2). TTMEDAL Consorcium. http://www.tt-medal.org. 2.4.2.2
292
[43] D, S. R., J, A., K, N., L, J. M., L, C. M., P, G. C.,

and H, B. M., Model-based testing in practice, in Proceedings of the 21st
International Conference on Software Engineering (ICSE 99), (Los Alamitos, CA,
USA), pp. 285294, IEEE Computer Society Press, 1999. 1.2, 2.3, 2.6, 3.2.1
[44] D, S., Nasa aviation safety & security program (avssp) concept of operation
(conops) for health monitoring and maintenance systems products, Tech. Rep. NIA
Report No. 2006-04, National Institute of Aerospace - USA, September 2005. 2.4.1
[45] D, R. M., M, M. G., and K, N., Principles of canonical action
research, Information Systems, pp. 6586, 2004. 1.3
[46] D, I., P, O., and M, A., Modeling interactions using role-driven patterns, in Proceedings of the 13th International Conference on Requirements Engineering (RE05), pp. 209220, IEEE Computer Society, 2005. 2.3.2
[47] A, L., Game models for open systems., in Verification: Theory and Practice, pp. 269289, Springer, 2003. 2.2.4.1
[48] A, L. and H, T. A., Interface automata, in Proceedings of the
8th European software engineering conference (ESEC/FSE-9:) held jointly with 9th
ACM SIGSOFT international symposium on Foundations of software engineering,
(New York, NY, USA), pp. 109120, ACM Press, 2001. 2.2.4.1
[49] D, P., S, M. P., L, D., and B, E. J., Model-driven integration
using existing models, IEEE Software, vol. 20, no. 5, pp. 5963, 2003. 2.5
[50] D, D., Modeling and Verification Using UML Statecharts. Elsevier Inc.
editor, 2006. 2.2.3, 2.6, 3.2.2
[51] E, A., A, P. P., and G, J., Analyzing and systematizing current traceability schemas, in Proceedings of the 30th Annual IEEE/NASA Software
Engineering Workshop (SW06), (Washington, DC, USA), pp. 2132, IEEE Computer Society, 2006. 8.3.1, 9.3, 12
[52] E, A., A, P. P., and G, J., Analyzing and systematizing current traceability schemas, in 30th Annual IEEE/NASA Software Engineering Workshop (SW06), vol. 0, (Los Alamitos, CA, USA), pp. 2132, IEEE Computer Society,
April 2006. 11
[53] ETSI, ETSI 201 873-1 version 2.2.1 (2003-02): The Testing and Test Control Notation version 3 (TTCN-3); Part1: TTCN-3 Core Language. ETSI European Standard,
2003. 2.4.2, 2.4.2.2, 2.6, 6.4.5.4
[54] E C S S, ECSS, System engineering - Part
6: Functional and technical specifications. European Space Agency, October 2005.
1, 4.4.1, 4.5
293
[55] E C S S, ECSS, Space engineering - Test

and operations procedure language. European Space Agency, April 2006. 1.1, 2.4,
2.4.2, 2.4.2.1, 2.4.2.2, 2.6
[56] F, P., S, E., N, M., and N, J., Towards a common check-out
and control system for rosetta, ESA Bulletin, vol. 94, May 1998. 2.3.6
[57] F, J. L., L, A., and B, L., A formal approach to service component architecture., in WS-FM (B, M., N , M., and Z, G., eds.),
vol. 4184 of Lecture Notes in Computer Science, pp. 193213, Springer, 2006. 2.3.4
[58] F, R., G, S., S, E., and K, D.-K., A metamodeling approach to
pattern-based model refactoring, IEEE Software, vol. 20, no. 5, pp. 5258, 2003.
2.5, 2.6
[59] F, L. and V, A., Una introduccin a los perfiles uml, Novatica,
vol. 168, March 2004. 5.1, 5.1, 5.1
[60] F, C. A., R, M., and M, D., Modeling the environment in softwareintensive systems, in MISE 07: Proceedings of the International Workshop on Modeling in Software Engineering, (Washington, DC, USA), p. 11, IEEE Computer
Society, 2007. 1.1
[61] G, A. P., Operational concepts - some variations, in Proceedings of the Systems
Engineering, Test and Evaluation Conference (SETE02), October 2002. 2.4.1, 2.4.1
[62] G, J., A, M., M, M.-A., and P, M., Assisting the definition and execution of test suites for complex systems, in Proceeding of the 7th
IEEE International Symposium on Engineering of Computer-Based Systems (ECBS
2000), (Los Alamitos, CA, USA), pp. 327333, IEEE Computer Society, 2000. 1.1,
1.2, 2.3.6, 9.3
[63] G, J. and A, P. P., Deploying validation tests in systems development, in Proceedings of the 3nd International Industrial Simulation Conference
(ISC2005), (Berlin, Germany), June 2005. 1.2, 9
[64] G, J., G, H., A, M., M, M.-A., G, A., and M, B.,
An architectural-framework for a testing environment for geographically distributed
teams, New Technologies in Computer Control 2001: A Proceedings Volume from
the Ifac Conference, 2002. 1.2
[65] G, C., J, M., and M, D., Fundamentals of Software Engineering.
Upper Saddle River, NJ, USA: Prentice Hall, 2nd ed., 2003. 2.6, 3.2.2, 3.2.4.2
[66] G, J., Three faces of human-computer interaction, IEEE Annals of the History
of Computing, vol. 27, no. 4, pp. 4662, 2005. 2.3.5
294
[67] H, G., P, J., P, A., and S, T., Prototype-based tests for

hybrid reactive systems, in Proceedings of the 14th IEEE International Workshop
on Rapid System Prototyping (RSP03), (Washington, DC, USA), IEEE Computer
Society, 2003. 2.5
[68] H, D., Statecharts: A visual approach to complex systems, Science of Computer Programming, vol. 8, pp. 231274, 1987. 2.2.3
[69] H, D. and P, A., On the development of reactive systems, Logic and
Models of Concurrent Systems, Springer, 1985. 2.2.4.1, 2.6
[70] H, A., Model based test generation tools, tech. rep., AGEDIS project
Downloads http://www.agedis.de/documents/, 2002. 2.5
[71] H, C., Requirements specifications for hybrid systems, in Proceedings
of the DIMACS/SYCON workshop on Hybrid systems III : verification and control,
(Secaucus, NJ, USA), pp. 304314, Springer-Verlag New York, Inc., 1996. I, 2.2.6,
6
[72] H, C. L., J, R. D., and L, B. G., Automated consistency checking of requirements specifications, ACM Transactions on Software Engineering and
Methodology, vol. 5, no. 3, pp. 231261, 1996. I, 3.2.2, 10
[73] H, T., B, R., C, S., C, T., G, J., M, M., P, G.,
S, G., and V, W., Acm sigchi curricula for human-computer interaction. Association for Computing Machinery, May 2007. 2.3.5
[74] H, R., Web services composition: A story of models, automata, and logics,
in Proceedings of the 2005 IEEE International Conference on Services Computing
(SCC 05), vol. 1, (Washington, DC, USA), pp. 3031, IEEE Computer Society, July
2005. 2.3.4
[75] IEEE, IEEE Std 610.12-1990. Standard Glossary of Software Engineering Terminology. IEEE Press, New York, 1990. 2.3.6
[76] IEEE, IEEE Std 1362-1998. Guide for Information Technology - System Definition
- Concept of Operations (ConOps) Document. New York, March 1998. 1.1, 2.4, 1,
2.4.1, 2.6, 4.5
[77] IEEE, IEEE Std 830-1998. Recommended Practice for Software Requirements Specifications. IEEE Press, New York, June 1998. 2, 4.4.2, 4.5
[78] IEEE, IEEE Std 1471-2000. Recommended Practice for Architectural Description
of Software-Intensive Systems. IEEE Press, New York, October 2000. 1.1, 3.2.3
[79] INCOSE, INCOSE Systems Engineering Handbook, version 3.1. International
Council on Systems Engineering, August 2007. http://www.incose8.com. 1.1, 2.4,
2.4.1, 1, 2.6, 4.5
295
[80] ISO, ISO Std 10303 - STEP - AP 233. Application Protocol: System Engineering.
Requirements for a Data Exchange Facility. International Standardization Organization, Nov 2002. 2.5
[81] ISO, ISO /IEC 19761, Software Engineering - COSMIC-FFP - A Functional Size
Measurement Method, International Standardization Organization, 2003. 2.6
[82] ISO/IEC, ISO/IEC 12207:2002, Standard for Information Technology - Software
Lifecycle Processes. International Standards Organization, 2002. 1.1, 2.4, 3.2.3
[83] ISO/IEC, ISO/IEC 15288-2007 Systems engineering - System life cycle processes.
ISO, July 2007. http://www.15288.com. 1.1, 2.4, 3.2.3, 8.3
[84] ITU, Message Sequence Charts. International Telecommunications Union. Telecommunication Standardization Sector Recommendation Z.120, 2000. 2.3.2
[85] J, M., Jackson development methods: Jsp and jsd, Encyclopaedia of Software Engineering. John J Marciniak (ed.) John Wiley & Sons, vol. 1, 1994. 2.2.3
[86] J, M., Software Requirements and Specifications - A Lexicon of Practice,
Principles and Prejudices. Addison-Wesley, 1995. 2.3.2
[87] J, M., The world and the machine, in Proceedings of the 17th international
Conference on Software Engineering (ICSE 95), pp. 283292, ACM Press, 1995.
2.2.2, 3.2.2, 3.2.2, 3.2.3.1
[88] J, I., B, G., and R, J., The unified software development process.
Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1999. 3
[89] J, J., H, E., B, S., and G, M., The maturing systems engineering data exchange standard ap-233 and your role, in Proceedings of the 10th
Annual International Symposium of the International Council on Systems Engineering, INCOSE, pp. 823830, 2000. 2.5
[90] J, J., N, B., L, F., T, A., L, J.-L., C, L., I,
M., and H, D., The future systems engineering data exchange standard step
ap-233: Sharing the results of the sedres project, in Proceedings of the 10th Annual International Symposium of the International Council on Systems Engineering
(INCOSE 99), vol. 1, pp. 923931, June 1999. 2.5
[91] J, B., Compositional Verification of Distributed Systems. Ph.d. thesis Department of Computer Systems, Uppsala University, Uppsala, Sweden, 1987. 2.2.3,
2.2.4.1, 2.2.4.1, 2.3.1
[92] J, P. and E, C., Object-oriented integration testing, Communications of the ACM, vol. 37, no. 9, pp. 3038, 1994. 2.6
296
[93] K, G., Design tool integration: an exercise in semantic interoperability, in

Proceeding of the 7th IEEE International Symposium on Engineering of ComputerBased Systems (ECBS2000), (Edinburgh, UK), pp. 272 278, IEEE Computer Society, March 2000. 2.5
[94] K, G. and G, J., Component generation technology for semantic tool integration, in Aerospace Conference Proceedings, 2000 IEEE, vol. 4, pp. 491499,
IEEE Computer Society, March 2000. 2.5
[95] K, G., L, and M, M., On generators for embedded information systems, in Proceedings of the 18th IEEE Instrumentation and Measurement
Technology Conference (IMTC 2001), vol. 3, pp. 1474 1478, IEEE Computer Society, May 2001. 2.5
[96] K, G., L, A., and N, S., Tool integration patterns, in Workshop on
Tool Integration in System Development (ESEC/FSE), (Helsinki, Finland), pp. 33
38, 2003. 2.5
[97] K, D. K., L, N., S, R., and V, F., The Theory of Timed I/O
Automata (Synthesis Lectures on Computer Science). Morgan & Claypool Publishers, 2006. 2.2.3, 2.3.1, 2.3.6
[98] K, J. O. and C, D. M., The vision of autonomic computing, Computer,
vol. 36, no. 1, pp. 4150, 2003. 6
[99] K, A., W, J., and B, W., Mda explained - the model driven architecture: Practice and promise, Addison Wesley, 2003. 2.3.3, 2.5, 2.6, 4.1
[100] K, D., B, K., and S, D., Enterprise SOA : Service-Oriented Architecture Best Practices (The Coad Series). Prentice Hall PTR, November 2004. 2.3.4
[101] K, B. J., P, M. P., and C, F., 05462 abstracts collection service oriented computing (soc), in Service Oriented Computing (SOC) (C, F., K, B. J., and P, M. P., eds.),
no. 05462 in Dagstuhl Seminar Proceedings, Internationales Begegnungs- und
Forschungszentrum fuer Informatik (IBFI), Schloss Dagstuhl, Germany, 2006.
<http://drops.dagstuhl.de/opus/volltexte/2006/579>. 2.3.4
[102] L, B. and K, H., Efficient approaches to satellite operations, in
Space Mission Operations and Ground Data Systems - SpaceOps 96, Proceedings
of the Fourth International Symposium held 16-20 September 1996 in Munich, Germany. Edited by T.-D. Guyenne. ESA SP-394. Paris: European Space Agency, 1996.
2.3.6
[103] L, K.-K. and W, Z., Software component models, IEEE Transactions on
Software Engineering, vol. 33, pp. 709724, October 2007. 2.3.4
297
[104] L, A., B, A., M, M., V, P., N, G., S, J., and

K, G., Composing domain-specific design environments, IEEE Computer,
vol. 34, pp. 4451, Nov 2001. 2.5
[105] L, B. and L, E. A., Interaction of finite state machines and concurrency models, Signals, Systems and Computers, 1998. Conference Record of the ThirtySecond Asilomar Conference on, vol. 2, pp. 17151719, November 1998. 2.2.3,
2.3.1
[106] L, G. and H, D., Expanding automotive electronic systems, IEEE
Computer, vol. 35, no. 1, pp. 8893, 2002. 2.2.4.2
[107] L, A., C, I., M, B., and H, M., Reconciling manual and automated testing: The autotest experience, in Proceedings of the 40th Annual Hawaii
International Conference on System Sciences (HICSS 07), (Washington, DC, USA),
p. 261a, IEEE Computer Society, 2007. 2.4.2.2
[108] L, E., K, J., M, J., and U, S., Monitoring and control in
scenario-based requirements analysis, in Proceedings of the 27th IEEE/ACM International Conference on Software Engineering (ICSE05), 2005. 2.3.2
[109] L, J., F, J., and D, R., Cost-effective mission control systems for
small satellites, in Space Mission Operations and Ground Data Systems - SpaceOps
96, Proceedings of the Fourth International Symposium held 16-20 September 1996
in Munich, Germany. Edited by T.-D. Guyenne. ESA SP-394. Paris: European Space
Agency, 1996. 2.3.6
[110] L, P., MA, A., and L, J., Defining autonomic computing: A software
engineering perspective, in Proceedings of the 2005 Australian Software Engineering Conference (ASWEC05), IEEE Press, 2005. 6
[111] L, P., An introduction to formal languages and automata. Jones and Bartlett
publishers, 4th ed., 2006. 2.2.3
[112] L, N. and S, E. W., A proof of the kahn principle for input/output automata, Information and Computation, vol. 82, no. 1, pp. 8192, 1989. 2.2.3, 2.2.4.1,
2.3.1
[113] L, J., P, F., M, M., and G, A., Testing of interconnected
machines, in Proceedings of the First Workshop on Systems Validation (SV02) in
conjunction with the 15th International Conference on Software and Systems Engineering and their Applications (ICSSEA02), (Paris, France), December 2002. 7.2.1
[114] M, B., Arquitectura de Referencia para Entornos de Validacin de Sistemas
(Referente Architecture for System Validation Environments). Ph.d. thesis Departamento de Lenguajes y Sistemas Informticos e Ingeniera del Software, Facultad de
Informtica, Universidad Politcnica de Madrid, Madrid, Spain, June 2005. 1.2
298
[115] M, E. and B, M., Service-Oriented Architecture (SOA): A Planning and Implementation Guide for Business and Technology. John Wiley & Sons, June 2006.
2.3.4
[116] M, H., Iso 10303 step. a key standard for the global market, ISO Bulletin,
pp. 913, April 2002. 2.5
[117] MN, A. and S, N., Methods of behaviour modelling. a commentary on
behaviour modelling techniques for mda. white paper (draft), Metamaxim Ltd.,
2004. 2.3.3, 2.3.6, 2.5, 2.6
[118] MN, A., Mda: The vision with
http://www.metamaxim.com, 2003. 2.5, 2.6
the
hole?,
Metamaxim
Ltd.
[119] M, S., G, J., S, J. L., and M, J., Un perfil uml para la definicin
de un lenguaje grfico de transformaciones basado en qvt, Actas de las XI Jornadas
de Ingeniera del Software y Bases de Datos, pp. 433442, 2006. 5.1
[120] M, S. J., C, A., and F, T., Guest editors introduction: Modeldriven development, IEEE Software, vol. 20, no. 5, pp. 1418, 2003. 2.5
[121] M, B., Applying design by contract, Computer, vol. 25, no. 10, pp. 4051,
1992. 2.3.3
[122] M, B., Object-oriented software construction (2nd ed.). Upper Saddle River,
NJ, USA: Prentice-Hall, Inc., 1997. 2.3.3, 2.6
[123] MIL-STD-498, MIL-STD-498 Software Development and Documentation - Operational Concept Description. United States Military Standard, December 1994. 1.1,
3, 2.6, 4.5
[124] M, S. P. and T, A. C., Extending the four-variable model to bridge the
system-software gap, in Proceedings of the 20th Digital Avionics Systems Conference (DASC01), vol. 1, pp. 1418, October 2001. 2.2.6, 2.6, 3.2.2
[125] M, B., T, R., S, E., and C, M., Meteosat second generation (msg) ground segment: the central facility concept, in Space Mission Operations and Ground Data Systems - SpaceOps 96, Proceedings of the Fourth International Symposium held 16-20 September 1996 in Munich, Germany. Edited by T.-D.
Guyenne. ESA SP-394. Paris: European Space Agency, 1996. 2.4.2
[126] NRO, NRO Concept of Operations Outline. Virginia Department of Transportation:
Northern Region Operations, June 2007. 2.4.1
[127] O, Z. and S, D., Modeling multimodal human-computer interaction, Computer, vol. 37, pp. 6572, September 2004. 2.3.5
[128] OMG, Meta Object Facility (MOF), version 1.4 specification. Document
formal/2002-04-03. Object Management Group, 2002. 2.4.2.2
299
[129] OMG, Model Driven Architecture Guide Version 1.0.1, Document omg/2003-06-01).
Object Management Group, June 2003. 2.5
[130] OMG, UML 2.0 Testing Profile, v1.0, Document formal/2005-07-07. Object Management Group, 2005. 2.4.2.2, 2.6, 6.2, 6.4.5.4
[131] OMG, Corba Component Model, V4.0, Document formal/2006-04-01. Object Management Group, 2006. 2.3.4
[132] OMG, Systems Modeling Language. Final Adopted Specification /06-05-04. Object
Management Group, May 2006. 2.5
[133] OMG, Unified Modeling Language: Superstructure, version 2.1.1. Object Management Group, February 2007. 2.3.2, 5.1
[134] P, M. P., T, P., D, S., and L, F., Service-oriented
computing: State of the art and research challenges, Computer, vol. 40, pp. 3845,
November 2007. 2.3.4
[135] P, D., Requirements documentation: A systematic approach. University of
Limerick, Department of Computer Science and Information Systems, February
2003. 2.2.6
[136] P, D. and M, J., Functional documentation for computer systems engineering, Technical Report CRL 237, vol. 2, September 1991. 2.2.6, 2.2.6, 2.6, 3.2.1,
3.2.2, 3.2.2, 3.2.4, 3.2.4.1, 3.2.4.1, 3.2.4.2
[137] P, D. and M, J., Functional documents for computer systems, Science
of Computer Programming, vol. 25, no. 1, pp. 4161, 1995. 2.2.6, 2.3.2, 2.6, 3.2.2
[138] P, C. and Z-S, O., Action research in graduate management programs, in World Congress on Action Research and Process Management - Conference Proceedings, pp. 6783, 1991. 2
[139] P, A. and R, R., On the synthesis of an asynchronous reactive module.,
in ICALP, vol. 372 of Lecture Notes in Computer Science, pp. 652671, Springer,
1989. 2.6
[140] P, A., Model-based testing, in Proceedings of the 27th International
Conference on Software Engineering (ICSE05), pp. 722723, May 2005. 2.5
[141] P, A., Model-based testing in practice, in Formal Methods, vol. 3582 of
Lecture Notes in Computer Science, pp. 537541, Springer Berlin, 2005. 2.5
[142] Q, A. and T, E., Specifying the semantics of operation contracts in
conceptual modeling, in Journal on Data Semantics VII, vol. 4244 of Lecture Notes
in Computer Science, pp. 3356, Springer, 2006. 2.3.3, 2.3.6
300
[143] R, A., S, P., M, A., and A, J., Early aspects: a model for
aspect-oriented requirements engineering, in Proceedings of the IEEE Joint International Conference on Requirements Engineering (RE02), IEEE Press, 2002. 2.5
[144] R, S. and S, R., Combining theorem proving with model checking through
predicate abstraction, IEEE Design and Test of Computers, vol. 24, pp. 112122,
April 2007. 2.3.1, 2.6
[145] S, S., Methodology for an organisational action research thesis, Action
research international, October 2001. 1.3
[146] S, T. K., Conceptual model of real-time systems: a perspective., in Proceedings of the 1995 ACM symposium on Applied computing (SAC95), (New York, NY,
USA), pp. 206209, ACM Press, 1995. I, 2.2.6, 8, 3.2.2, 3.2.2, 10
[147] S, S. and M, S., Object life cycles - modeling the world in states,
Yourdon Press/Prentice Hall, 1992. 2.2.3
[148] S, D. C., Guest editors introduction: Model-driven engineering, Computer,
vol. 39, no. 2, pp. 2531, 2006. 2.5
[149] S, E., What models mean, IEEE Software, vol. 20, no. 5, pp. 2632, 2003.
2.5, 2.6
[150] S, B., The pragmatics of model-driven development, IEEE Software, vol. 20,
no. 5, pp. 1925, 2003. 2.5
[151] S, S. and K, W., Model transformation: The heart and soul of
model-driven software development, IEEE Software, vol. 20, no. 5, pp. 4245,
2003. 2.5, 2.6
[152] S, S. and S, A., From use cases to system operation specifications,
in UML 2000 - The Unified Modeling Language. Advancing the Standard: Third
International Conference, vol. 1939 of Lecture Notes in Computer Science, pp. 1
15, Springer, October 2000. 2.3.3, 2.3.6
[153] S, H., R, Y., and P, J., Interaction Design beyond human-computer
interaction. 2nd Edition. John Wiley Sons Ltd., March 2007. 2.3.5
[154] S, B. L., E, M. H., and W, D. W., Part 3: Regional transportation
systems management: Investigation of the development and use of a concept of operations in traffic management systems, Transportation Research Record, vol. 1925,
pp. 236244, 2005. 2.4.1
[155] S, J., Model-integrated computing, IEEE Potentials, vol. 23, pp. 2830,
February 2004. 2.5
[156] S, G., Development of Operational Concept Descriptions (Analysing what
the customer needs). Tenix Defence Systems, Melbourne, Australia, 2001. 2.4.1
301
[157] S, A., On the effective use and reuse of hci knowledge, ACM Transactions
on Computer-Human Interaction, vol. 7, pp. 1971221, June 2000. 2.3.5
[158] S, J., Model integrated computing: foundations and applications, in
Proceedings of the 12th IEEE International Conference and Workshops on the Engineering of Computer-Based Systems (ECBS05), April 2005. 2.5
[159] T, C., D, A. M., and S, L., A storyboard tool to assist concept of operations development, Proceedings of the 2007 IEEE Aerospace
Conference, pp. 18, March 2007. 2.4.1, 2.4.1
[160] T, L., Z, T., O, B., C, A., and B, M., From
simulations to operations: Developments in test and verification equipment for
spacecraft. Data Systems In Aerospace (DASIA), NLR-TP-2001-323, France, June
2001. 1.1, 2.3.6
[161] T, V. and P, B., On comprehensive contractual descriptions of web services, in Proceedings of the 2005 IEEE International Conference on e-Technology,
e-Commerce and e-Service (EEE05) on e-Technology, e-Commerce and e-Service,
(Washington, DC, USA), pp. 444449, IEEE Computer Society, March 2005. 2.3.4
[162] U, S., C, R., K, J., and M, J., Goal and scenario validation:
a fluent combination, in Requirements Eng, pp. 123137, Springer-Verlag, 2006.
2.3.2
[163] U, S. and K, J., A workbench for synthesising behaviour models from
scenarios, in Proceedings of the 23rd International Conference on Software Engineering (ICSE01), (Washington, DC, USA), pp. 188197, IEEE Computer Society,
2001. 2.3.2
[164] U, S., C, R., K, J., and M, J., Fluent-based animation: Exploiting the relation between goals and scenarios for requirements validation., in
Proceedings of the IEEE International Conference on Requirements Engineering
Conference, pp. 208217, IEEE Computer Society, 2004. 2.3.2
[165] U, S., K, J., and M, J., Synthesis of behavioral models from scenarios., IEEE Transactions on Software Engineering, vol. 29, no. 2, pp. 99115,
2003. 2.3.2
[166] U, M., Position paper: Model-based testing, in Verified Software: Theories,
Tools, Experiments (VSTTE) conference, October 2005. 2.5
[167] V, V. K., B, G. C., and K, W. L., A data/knowledge
paradigm for the modeling and design of operations support systems, IEEE Transactions on Knowledge Data Engineering, vol. 9, no. 2, pp. 275291, 1997. 2.3.6
[168] V, M., C, C., S, W., and K, P., On-the-fly testing of reactive systems, tech. rep., Technical Report MSR-TR-2005-03, Microsoft Research,
January 2005. 2.2.4.1, 2.6
302
[169] V, R., F-M, E., T, J., and P, M., Towards a

uml 2.0/ocl extension for designing secure data warehouses., in Proceedings of the
3rd International Workshop on Security in Information Systems WOSIS05, In conjunction with ICEIS2005, pp. 217228, May 2005. 5.1, 5.3
[170] W, Y., The oar model for knowledge representation, in Proceedings of the 2006
IEEE Canadian Conference on Electrical and Computer Engineering (CCECE06),
pp. 16961699, IEEE CS Press, May 2006. 3.2.4.1
[171] W, Y., On abstract systems and system algebra, in Proceedings of the 5th IEEE
International Conference on Cognitive Informatics (ICCI06), pp. 332343, IEEE
CS Press, July 2006. I, 2.2, 2.2.5, 2.2.5, 5, 2.6, 1, 3.2.2, 3.2.4, 3.2.4.1, 3.2.4.1,
3.2.4.2, 3.2.4.2
[172] W, C. E., A, M. E., and MC, K. W., How do design and evaluation interrelate in hci research?, in Proceedings of the 6th ACM Conference on Designing
Interactive Systems (DIS06), pp. 9098, ACM Press, 2006. 2.3.5
[173] W, J. and K, A., The object constraint language: Getting your models
ready for mda, Addison Wesley, 2003. 2.3.3
[174] W, J., S, J., and K, R., From scenarios to code: an air traffic control
case study, in Proceedings of the 25th International Conference on Software Engineering (ICSE03), vol. 4, (Washington, DC, USA), pp. 7193, IEEE Computer
Society, 2003. 2.3.2
[175] W, R. J., Design Methods for Reactive Systems: Yourdon, Statemate and Uml.
Morgan Kaufmann Publishers, 2003. 2.2.4.1
[176] Y, A. and G, J., Applying the knowledge stored in systems models
to derive validation tools and environments, in Proceedings of the 6th IEEE International Conference on Cognitive Informatics (ICCI07), (LakeTahoe, California),
IEEE CS Press, August 2007. 1.2
[177] Y, A., A, P. P., G, J., L, A., and S, G., Construction of verified models for systems represented as networks, in The 2nd International Workshop on Verification and Validation of Enterprise Information Systems
(VVEIS-2004), pp. 4449, April 2004. 2.6, 6
[178] Z, J., D, Z., S, I., and D, G., From u2tp models to executable
tests with ttcn-3. an approach to model driven testing, in Proceedings of the IFIP
17th International Conference on Testing Communicating Systems - TestCom 2005,
March 2005. 2.4.2.2
[179] Z, G., Towards aspect-oriented class diagrams, in Proceedings of the 12th
Asia-Pacific Software Engineering Conference (APSEC05), IEEE Press, 2005. 2.5
303
[180] Z, J., F, J., and E, S., Research through design as a method

for interaction design research in hci, in Proceedings of the SIGCHI Conference on
Human Factors in Computing Systems (CHI07), (New York, NY, USA), pp. 493
502, ACM Press, May 2007. 2.3.5
[181] Z, F., H, T., and H, C., Galileo system simulation facility, in Proceedings of 8th ESA Internatonal Workshop on Simulation for European Space Programmes (SESP04), (ESTEC), October 2004. 2.4.2
304

Pedro Pablo

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Pedro Pablo

Diunggah oleh

Hak Cipta:

Format Tersedia

Universidad Politcnica de Madrid

Autor: Pedro Pablo Alarcn Cavero

Tribunal nombrado por el Mgfco. Y Excmo. Sr. Rector de la Universidad Politcnica

Realizado el acto de defensa y lectura de la Tesis el da

Y en especial, quiero mostrar mi ms sincero agradecimiento a las siguientes personas

Los operadores de un sistema han de tener un buen conocimiento del funcionamiento

de representacin del modelo de operaciones de un sistema, se aporta una aproximacin al

1.1. Planteamiento de la tesis doctoral . . . . . . . . . . . . . . . . . . . . . .

1.2. Motivacin y objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3. Metodologa de investigacin de la tesis . . . . . . . . . . . . . . . . . . 10

2.2.4. Broy: sistemas reactivos e interactivos . . . . . . . . . . . . . . . 27

2.2.5. Visin de Wang . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.3. Paradigmas en el modelado de la interaccin de un sistema . . . . . . . . 42

PLUTO como lenguaje de operaciones . . . . . . . . . 57

TTCN-3 como lenguaje orientado a pruebas . . . . . . . 59

2.5. Desarrollo de sistemas dirigido por modelos . . . . . . . . . . . . . . . . 61

3.2.4. Estructura de un sistema . . . . . . . . . . . . . . . . . . . . . . 88

Visin estructural intra-elementos . . . . . . . . . . . . 89

Visin estructural inter-elementos . . . . . . . . . . . . 94

3.3. Los Sistemas con componentes inter-relacionados como sistemas de interaccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

3.3.2. Concepto de frontend de operaciones de un sistema . . . . . . . . 101

Interaccin Sistema-Entorno . . . . . . . . . . . . . . . 106

Interaccin Operador-Frontend de operaciones . . . . . 106

Interaccin Sistema-Frontend de Operaciones del Sistema106

3.4. Resumen y conclusiones del captulo . . . . . . . . . . . . . . . . . . . . 109

PROPUESTA DE REPRESENTACIN DEL MODELO DE OPERACIONES

Clase SystemElement . . . . . . . . . . . . . . . . . . 145

Clase SeProperty . . . . . . . . . . . . . . . . . . . . . 146

Tipo de datos AccessPort . . . . . . . . . . . . . . . . 148

Enumeracin ElementStatus . . . . . . . . . . . . . . . 148

Enumeracin PropertyType . . . . . . . . . . . . . . . 148

Tipo de datos PropertyValue . . . . . . . . . . . . . . . 149

5.2.2. Vista de interaccin . . . . . . . . . . . . . . . . . . . . . . . . . 149

Clase InputInterface . . . . . . . . . . . . . . . . . . . 150

Clase InputOperation . . . . . . . . . . . . . . . . . . . 150

Clase InputCmd . . . . . . . . . . . . . . . . . . . . . 151

Clase OutputInterface . . . . . . . . . . . . . . . . . . 151

Clase OutputOperation . . . . . . . . . . . . . . . . . . 152

Clase Response . . . . . . . . . . . . . . . . . . . . . . 153

Clase Notification . . . . . . . . . . . . . . . . . . . . 153

Clase Alarm . . . . . . . . . . . . . . . . . . . . . . . 154

Tipo de datos PriorityType . . . . . . . . . . . . . . . . 154

5.3. Definicin de un perfil UML 2 de operaciones (U2OP) . . . . . . . . . . . 155

Enumeracin ElementStatus . . . . . . . . . . . . . . . 159

Tipo de datos AccessPort . . . . . . . . . . . . . . . . . 159

Tipo de datos PriorityType . . . . . . . . . . . . . . . . 159

5.3.4. Estereotipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Estereotipo  U2OP_S ystemElement  . . . . . . . . 160

Estereotipo  U2OP_VisibleRelation  . . . . . . . . 161

Estereotipo  U2OP_Monitored  . . . . . . . . . . 162

Estereotipo  U2OP_Controlled  . . . . . . . . . . 162

Estereotipo  U2OP_MonitoredAndControlled  . . 163

Estereotipo  U2OP_Input  . . . . . . . . . . . . . 164

Estereotipo  U2OP_Output  . . . . . . . . . . . . 164

Estereotipo  U2OP_InputCmd  . . . . . . . . . . . 165

Estereotipo  U2OP_Response  . . . . . . . . . . . 165

5.3.4.10. Estereotipo  U2OP_Noti f ication  . . . . . . . . . 166

5.4. Resumen y conclusiones del captulo . . . . . . . . . . . . . . . . . . . . 167

Clase SOF . . . . . . . . . . . . . . . . . . . . . . . . 174

Clase Operator . . . . . . . . . . . . . . . . . . . . . . 177

Clase SystemView . . . . . . . . . . . . . . . . . . . . 178

Clase OperationsProcedure . . . . . . . . . . . . . . . 179

Clase ProcedureExecution . . . . . . . . . . . . . . . . 180

Clase CommandExecution . . . . . . . . . . . . . . . . 181

Estereotipo U2OP_S ystemElement . . . . . . . . 160

Estereotipo U2OP_VisibleRelation . . . . . . . . 161

Estereotipo U2OP_Monitored . . . . . . . . . . 162

Estereotipo U2OP_Controlled . . . . . . . . . . 162

Estereotipo U2OP_MonitoredAndControlled . . 163

Estereotipo U2OP_Input . . . . . . . . . . . . . 164

Estereotipo U2OP_Output . . . . . . . . . . . . 164

Estereotipo U2OP_InputCmd . . . . . . . . . . . 165

Estereotipo U2OP_Response . . . . . . . . . . . 165

5.3.4.10. Estereotipo U2OP_Noti f ication . . . . . . . . . 166