Universidad Politécnica de Madrid

Facultad de InformáticaDepartamento de Lenguajes, Sistemas Informáticos e Ingeniería del

Software

ESPECIFICACIÓN DE UN MODELO DE

INTERACCIÓN APLICABLE A PROCESOS DE

DESARROLLO Y OPERACIÓN DE SISTEMAS CON

SOFTWARE

TESIS DOCTORAL

Autor: Pedro Pablo Alarcón CaveroIngeniero en Informática

Director: Juan Garbajosa SopeñaDoctor en Informática

Enero 2008

Tribunal nombrado por el Mgfco. Y Excmo. Sr. Rector de la Universidad Politécnica

de Madrid, el día de de 2008.

Presidente D.

Vocal D.

Vocal D.

Vocal D.

Secretario D.

Realizado el acto de defensa y lectura de la Tesis el día de de 2008.

En Madrid:

Calificación:

EL PRESIDENTE LOS VOCALES

EL SECRETARIO

A mis padres, inicio de este trabajo hace unos cuantos años, os quiero.

A mis hijos, Jesús, Pedro Pablo y Jorge, las estrellas que me han guiado hasta terminarlo.

A mi mujer, Mari Ángeles, ya sabes... este trabajo es de los dos, las palabras que tú

has escrito no figuran en este libro, están grabadas en mi corazón.

AGRADECIMIENTOS

Gracias a todos los que han participado en mi vida hasta completar mi formación

académica con esta tesis doctoral; a los que me dieron palabras de ánimo, a los que me

regalaron una sonrisa, a los que me regalaron mil, a los que no me regalaron ni una, a los

que me ayudaron, a los que no me ayudaron porque de ello también aprendí, a los que se

alegraron, a los que no se alegraron pero se alegran hoy, a mi familia, a mis amigos del

presente y del pasado, a los que ya no están aquí... todos de una forma u otra han aportado

granitos de arena hasta formar esta montaña.

Agradezco a todos los que se han interesado por la marcha de este trabajo y me han

dado palabras de ánimo durante todo este tiempo: Ángel García, Carlos Cuvillo, Eugenio

Santos, Héctor García, Javier Gil, Jéssica Díaz, Jorge Tejedor, LuisFer, Manuel Bollaín,

Miguel Angel Díaz, Nicos, Octavio, Paco Sanchis, Pepi, Pilar Rodriguez, Santiago Alonso,

y otros muchos que no figuran por no hacer esta lista interminable, y a los que daré las

gracias personalmente.

Y en especial, quiero mostrar mi más sincero agradecimiento a las siguientes personas

que me han prestado su inestimable ayuda durante la realización de esta tesis:

Juan Garbajosa — director de esta tesis, por embarcarme hace unos cuantos años en

esta aventura y brindarme la oportunidad de trabajar juntos realizando este trabajo de

investigación.

Agustín Yagüe — siempre ha estado ahí cuando le he necesitado; más que un com-

pañero, un amigo.

Jennifer Pérez — por aparecer como el séptimo de caballería cuando más bajo estaba

de ánimo.

Antonio Vallecillo – por la mano amiga que me ha tendido y los ánimos que en todo

momento me ha dado.

RESUMEN

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

del sistema para que el rendimiento de éste sea el adecuado. Este conocimiento incluye las

interacciones que puedan darse entre el sistema y el operador, por medio de la aplicación o

aplicaciones externas que posibiliten dicha interacción entre ambos. Esta interacción con-

templa las operaciones admitidas por el sistema, expresadas por el envío de entradas al

sistema y la recepción de las salidas generadas por el sistema. Las operaciones del sistema

por tanto constituyen una parte esencial del conocimiento relacionado con un sistema. Sin

embargo, el desarrollo de sistemas a menudo, no contempla el conocimiento de las ope-

raciones del sistema como un elemento clave en el proceso de desarrollo. Los aspectos

de operaciones del sistema se abordan de manera implícita y lateral junto con el resto de

aspectos que sí reciben atención preferente.

Esta tesis profundiza en un aspecto fundamental en los sistemas intensivos en software,

ideados para ser operados por personas o por otros sistemas, como es el modelado de la

interacción de un sistema con el exterior. El objetivo principal de este trabajo de inves-

tigación es el de especificar un modelo de interacción con el operador del sistema, al que

denominamos “modelo de operaciones de un sistema”, que permita ser utilizado como base

en el desarrollo y operación/monitorización de sistemas intensivos software.

Este trabajo realiza una aportación en el campo del modelado y especificación de sis-

temas complejos, contribuyendo con nuevas definiciones para “sistema operable” y “mode-

lo de operaciones de un sistema”, y proponiendo además, un metamodelo y un perfil UML

para incorporar el modelado de las operaciones en el modelo de un sistema. En el campo de

herramientas de operación y validación de sistemas, y tomando como base estas propuestas

de representación del modelo de operaciones de un sistema, se aporta una aproximación al

modelado del frontend de operaciones de un sistema. Esta aproximación incluye un meta-

modelo, una arquitectura conceptual y un conjunto de operaciones básicas del sistema. Por

último, y en el campo del modelado y gestión de procesos, se analiza la potencialidad del

modelo de operaciones definido en el proceso de desarrollo de sistemas, y se plantea el

enriquecimiento del proceso de desarrollo de sistemas mediante la utilización, en etapas

tempranas del desarrollo, del modelo de operaciones del sistema.

ABSTRACT

A key issue in system engineering is the modelling of the knowledge of the system

interactions. These interactions include system operations such as commands acting on

systems: inputs to the system and different kinds of outputs, which are classified into re-

sponses, notifications and alarms. Therefore, system operations are an essential part of the

knowledge of the system. However, systems engineering does not often take into account

the system operations as a key element. They usually consider system operations in an

implicit and lateral way.

This Thesis is focused on the modelling of the interaction between a software-intensive

system -which were devised to be operated by people or other systems- and its environ-

ment. The main objective of this research work is to specify an interaction model between

an operator and the system, which is called “system operations model”, that allows for be-

ing the base of the development and operation/monitoring processes of software-intensive

systems.

This work contributes in the modelling and specification of complex systems making

new definitions for “operable system” and “system operations model”. In addition, a meta-

model and a profile UML to incorporate the operations modelling in the model of a system

are proposed. Another relevant contribution of this Thesis is the definition of a new appro-

ach to model the system operations front-end that is based on the system operations model.

Specifically, this approach includes an UML metamodel, a conceptual architecture of the

front-end, and a subset of basic operations for a generic system.

Finally, the system operations model can be applied in early development phases of

software-intensive systems. The consequence is that operations issues can effectively be

used as a driver in the complex systems engineering activities such as development and

validation. Thus, the use of the system operations model in early development stages con-

tributes to a significant enrichment of the systems development process.

Índice general

PARTE I

DEDICATORIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

AGRADECIMIENTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

RESUMEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

LISTA DE TABLAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

LISTA DE ACRÓNIMOS Y ABREVIATURAS . . . . . . . . . . . . . . . . . .

I. INTRODUCCIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

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

1.2. Motivación y objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3. Metodología de investigación de la tesis . . . . . . . . . . . . . . . . . . 10

1.4. Marco de desarrollo de la tesis . . . . . . . . . . . . . . . . . . . . . . . 12

1.5. Presentación de la tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.6. Resumen del capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

II. ESTADO DEL ARTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2. Sistemas desde el punto de vista de interacción . . . . . . . . . . . . . . . 22

2.2.1. Visión filosófica de Bunge . . . . . . . . . . . . . . . . . . . . . 23

2.2.2. Jackson: el mundo y la máquina . . . . . . . . . . . . . . . . . . 24

2.2.3. Sistemas definidos como autómatas . . . . . . . . . . . . . . . . 25

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

2.2.4.1. Sistemas reactivos . . . . . . . . . . . . . . . . . . . . 27

2.2.4.2. Sistemas interactivos . . . . . . . . . . . . . . . . . . . 31

2.2.5. Visión de Wang . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.2.6. Modelo de cuatro variables de Parnas . . . . . . . . . . . . . . . . 36

2.3. Paradigmas en el modelado de la interacción de un sistema . . . . . . . . 42

2.3.1. Paradigma basado en estados . . . . . . . . . . . . . . . . . . . . 43

2.3.2. Paradigma basado en escenarios . . . . . . . . . . . . . . . . . . 44

2.3.3. Paradigma basado en contratos . . . . . . . . . . . . . . . . . . . 45

2.3.4. Paradigma basado en servicios . . . . . . . . . . . . . . . . . . . 47

2.3.5. Paradigma basado en Interacción Hombre-Computador (HCI) . . . 48

2.3.6. Paradigma basado en operaciones . . . . . . . . . . . . . . . . . 49

2.4. Concepto de operación de sistemas en estándares de ingeniería de sis-temas y software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

2.4.1. Visión de documento de operaciones . . . . . . . . . . . . . . . . 53

2.4.2. Lenguajes procedurales de operación y pruebas . . . . . . . . . . 57

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

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

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

2.6. Resumen y conclusiones del capítulo . . . . . . . . . . . . . . . . . . . . 65

III. CONCEPTUALIZACIÓN DE SISTEMA OPERABLE . . . . . . . . . . . . 75

3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

3.2. Los sistemas con componentes inter-relacionados . . . . . . . . . . . . . 76

3.2.1. Sistema como autómata . . . . . . . . . . . . . . . . . . . . . . . 76

3.2.2. Relación entre sistema y entorno . . . . . . . . . . . . . . . . . . 79

3.2.3. Punto de vista de las operaciones . . . . . . . . . . . . . . . . . . 85

3.2.3.1. Operador . . . . . . . . . . . . . . . . . . . . . . . . . 86

3.2.3.2. Interfaz de operación . . . . . . . . . . . . . . . . . . . 88

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

3.2.4.1. Visión estructural intra-elementos . . . . . . . . . . . . 89

3.2.4.2. Visión estructural inter-elementos . . . . . . . . . . . . 94

3.3. Los Sistemas con componentes inter-relacionados como sistemas de in-teracción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

3.3.1. Concepto de sistema operable . . . . . . . . . . . . . . . . . . . . 99

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

3.3.3. Interacciones de un sistema desde el punto de vista de operaciones 104

3.3.3.1. Interacción Sistema-Entorno . . . . . . . . . . . . . . . 106

3.3.3.2. Interacción Operador-Frontend de operaciones . . . . . 106

3.3.3.3. Interacción Sistema-Frontend de Operaciones del Sistema106

3.4. Resumen y conclusiones del capítulo . . . . . . . . . . . . . . . . . . . . 109

IV. MODELO DE OPERACIONES DE UN SISTEMA . . . . . . . . . . . . . . 111

4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

4.2. Definición de modelo de operaciones de un sistema . . . . . . . . . . . . 113

4.3. Ámbito de aplicación del modelo de operaciones de un sistema . . . . . . 118

4.4. Modelo de operaciones y requisitos de un sistema . . . . . . . . . . . . . 121

4.4.1. Estándar ECSS-E10Part6A . . . . . . . . . . . . . . . . . . . . . 121

4.4.2. Estándar IEEE Std 830 . . . . . . . . . . . . . . . . . . . . . . . 123

4.5. Subconjunto de requisitos del sistema relacionados con el MOS . . . . . . 124

4.5.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . 127

4.5.2. Requisitos de operación . . . . . . . . . . . . . . . . . . . . . . . 129

4.6. Recomendaciones para especificar el modelo de operaciones de un sistema 131

4.7. Resumen y conclusiones del capítulo . . . . . . . . . . . . . . . . . . . . 134

V. PROPUESTADEREPRESENTACIÓNDELMODELODEOPERACIONESDE UN SISTEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

5.1. Planteamiento inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

5.2. Metamodelo de operaciones de un sistema . . . . . . . . . . . . . . . . . 141

5.2.1. Vista del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 144

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

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

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

5.2.1.4. Enumeración ElementStatus . . . . . . . . . . . . . . . 148

5.2.1.5. Enumeración PropertyType . . . . . . . . . . . . . . . 148

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

5.2.2. Vista de interacción . . . . . . . . . . . . . . . . . . . . . . . . . 149

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

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

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

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

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

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

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

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

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

5.3. Definición de un perfil UML 2 de operaciones (U2OP) . . . . . . . . . . . 155

5.3.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

5.3.2. Prerrequisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

5.3.3. Nuevos tipos de datos . . . . . . . . . . . . . . . . . . . . . . . . 157

5.3.3.1. Enumeración ElementStatus . . . . . . . . . . . . . . . 159

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

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

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

5.3.4.1. Estereotipo� U2OP_S ystemElement � . . . . . . . . 160

5.3.4.2. Estereotipo� U2OP_VisibleRelation � . . . . . . . . 161

5.3.4.3. Estereotipo� U2OP_Monitored � . . . . . . . . . . 162

5.3.4.4. Estereotipo� U2OP_Controlled � . . . . . . . . . . 162

5.3.4.5. Estereotipo� U2OP_MonitoredAndControlled � . . 163

5.3.4.6. Estereotipo� U2OP_Input � . . . . . . . . . . . . . 164

5.3.4.7. Estereotipo� U2OP_Output � . . . . . . . . . . . . 164

5.3.4.8. Estereotipo� U2OP_InputCmd � . . . . . . . . . . . 165

5.3.4.9. Estereotipo� U2OP_Response � . . . . . . . . . . . 165

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

5.3.4.11. Estereotipo� U2OP_Alarm � . . . . . . . . . . . . . 166

5.4. Resumen y conclusiones del capítulo . . . . . . . . . . . . . . . . . . . . 167

VI. APLICACIÓN DEL MODELO DE OPERACIONES DEL SISTEMA CO-MO SOPORTE PARA EL MODELADO DEL FRONTEND DE OPERA-CIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

6.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

6.2. Metamodelo de frontend de operaciones del sistema . . . . . . . . . . . . 170

6.2.1. Frontend de operaciones . . . . . . . . . . . . . . . . . . . . . . 174

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

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

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

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

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

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

6.2.2. Sistema bajo operación . . . . . . . . . . . . . . . . . . . . . . . 182

6.2.2.1. Clase SystemElement . . . . . . . . . . . . . . . . . . 183

6.2.3. Operaciones sobre el sistema . . . . . . . . . . . . . . . . . . . . 184

6.2.3.1. Interfaz InputInterface . . . . . . . . . . . . . . . . . . 184

6.2.3.2. Interfaz OutputInterface . . . . . . . . . . . . . . . . . 185

6.2.4. Tipos de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

6.2.4.1. Tipo de datos Identifier . . . . . . . . . . . . . . . . . . 186

6.2.4.2. Tipo de datos ExecutionResult . . . . . . . . . . . . . . 186

6.3. Arquitectura conceptual de un frontend de operaciones del sistema . . . . 186

6.3.1. Nivel 1: Interacción operador-sistema . . . . . . . . . . . . . . . 187

6.3.2. Nivel 2: Interacción SOF-Sistema . . . . . . . . . . . . . . . . . 188

6.3.3. Nivel 3: Comunicación SOF-Sistema . . . . . . . . . . . . . . . . 189

6.3.4. Nivel 4: GUI orientado al operador del sistema . . . . . . . . . . 190

6.3.5. Nivel 5: Componentes del SOF . . . . . . . . . . . . . . . . . . . 191

6.3.6. Esquema de funcionamiento del SOF . . . . . . . . . . . . . . . . 193

6.4. Comandos básicos de operación de un sistema . . . . . . . . . . . . . . . 194

6.4.1. Sintaxis general . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

6.4.2. Clasificación de comandos básicos de operación . . . . . . . . . . 197

6.4.3. Operaciones de administración o configuración . . . . . . . . . . 198

6.4.3.1. CreateSE . . . . . . . . . . . . . . . . . . . . . . . . . 199

6.4.3.2. DeleteSE . . . . . . . . . . . . . . . . . . . . . . . . . 200

6.4.4. Operaciones de Interacción . . . . . . . . . . . . . . . . . . . . . 200

6.4.4.1. Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

6.4.4.2. Get . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

6.4.4.3. Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

6.4.4.4. Finish . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

6.4.5. Operaciones de procedimiento . . . . . . . . . . . . . . . . . . . 203

6.4.5.1. For . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

6.4.5.2. Repeat . . . . . . . . . . . . . . . . . . . . . . . . . . 204

6.4.5.3. Wait . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

6.4.5.4. Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

6.5. Resumen y conclusiones del capítulo . . . . . . . . . . . . . . . . . . . . 206

VII. APLICACIÓN DELMODELO DE OPERACIONES A UN CASO PRÁCTI-CO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

7.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

7.2. Descripción del caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

7.2.1. Concepto de sistema . . . . . . . . . . . . . . . . . . . . . . . . 211

7.2.2. Requisitos para la certificación de máquinas interconectadas . . . 213

7.2.3. Descripción del problema a resolver . . . . . . . . . . . . . . . . 216

7.2.4. Descripción de la solución . . . . . . . . . . . . . . . . . . . . . 217

7.3. Requisitos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

7.4. Modelo del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

7.4.1. Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . 221

7.4.2. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . 225

7.4.2.1. Tipos de datos . . . . . . . . . . . . . . . . . . . . . . 225

7.4.2.2. Clase Master . . . . . . . . . . . . . . . . . . . . . . . 225

7.4.2.3. Clase Accumulator . . . . . . . . . . . . . . . . . . . . 228

7.4.2.4. Clase Game . . . . . . . . . . . . . . . . . . . . . . . . 230

7.4.2.5. Clase Prize . . . . . . . . . . . . . . . . . . . . . . . . 231

7.4.2.6. Clase NormalPrize . . . . . . . . . . . . . . . . . . . . 231

7.4.2.7. Clase JackpotPrize . . . . . . . . . . . . . . . . . . . . 232

7.4.2.8. Interfaz MasterBasicFunctionallity . . . . . . . . . . . 232

7.4.2.9. Interfaz AccumulatorControl . . . . . . . . . . . . . . . 233

7.4.2.10. Interfaz Play . . . . . . . . . . . . . . . . . . . . . . . 234

7.4.3. Diagrama de actividades . . . . . . . . . . . . . . . . . . . . . . 234

7.4.4. Diagrama de secuencia . . . . . . . . . . . . . . . . . . . . . . . 238

7.4.5. Diagrama de estados . . . . . . . . . . . . . . . . . . . . . . . . 239

7.5. Aplicación del perfil U2OP al modelado del sistema . . . . . . . . . . . . 240

7.5.1. SystemElement . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

7.5.2. VisibleRelation . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

7.5.3. Monitored . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

7.5.4. MonitoredAndControlled . . . . . . . . . . . . . . . . . . . . . . 244

7.5.5. Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

7.5.6. Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

7.5.7. CmdInput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

7.5.8. Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

7.5.9. Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

7.6. Resumen y conclusiones del capítulo . . . . . . . . . . . . . . . . . . . . 249

VIII.APLICACIÓN DEL MODELO DE OPERACIONES EN PROCESOS DEDESARROLLO Y OPERACIÓN DE SISTEMAS . . . . . . . . . . . . . . . 251

8.1. Utilización del modelo de operaciones en procesos de desarrollo de sistemas252

8.2. El modelo de operaciones como soporte en la generación de herramientasde validación y operación de sistemas . . . . . . . . . . . . . . . . . . . . 255

8.3. Enriquecimiento del proceso de desarrollo de sistemas . . . . . . . . . . . 261

8.3.1. Desarrollo incremental del sistema . . . . . . . . . . . . . . . . . 264

8.3.2. Validación del sistema . . . . . . . . . . . . . . . . . . . . . . . . 265

8.4. Resumen y conclusiones del capítulo . . . . . . . . . . . . . . . . . . . . 266

IX. CONCLUSIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

9.1. Análisis del logro de objetivos . . . . . . . . . . . . . . . . . . . . . . . . 268

9.2. Aportaciones a la investigación . . . . . . . . . . . . . . . . . . . . . . . 271

9.3. Contraste de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

9.4. Líneas de investigación futuras . . . . . . . . . . . . . . . . . . . . . . . 286

9.5. Conclusiones finales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

REFERENCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

Índice de cuadros

1. Requisitos para definir un MOS . . . . . . . . . . . . . . . . . . . . . . . 128

2. Perfiles UML definidos por OMG . . . . . . . . . . . . . . . . . . . . . . 139

3. Conjunto de operaciones genéricas . . . . . . . . . . . . . . . . . . . . . . 198

Índice de figuras

1. Ciclo de actividades del método Investigación en Acción . . . . . . . . . . 11

2. Marco de proyectos Investigación en Acción en esta tesis . . . . . . . . . . 12

3. Relación entre el sistema y su entorno (adaptada de Broy [24]) . . . . . . . 29

4. Caja negra y de cristal (adaptada de Broy [31]) . . . . . . . . . . . . . . . 33

5. Modelo de sistema abierto (Wang [171]) . . . . . . . . . . . . . . . . . . . 36

6. Modelo de cuatro variables (adaptada de Heitmeyer [71]) . . . . . . . . . . 38

7. Modelo de cuatro variables . . . . . . . . . . . . . . . . . . . . . . . . . . 40

8. Modelo de sistema (adaptada de Sateesh [146]) . . . . . . . . . . . . . . . 42

9. Relación entre un sistema y su entorno . . . . . . . . . . . . . . . . . . . . 81

10. Modelo de sistema de cuatro variables (basado en Heitmeyer [72] y Sateesh[146]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

11. Primer nivel de interacción . . . . . . . . . . . . . . . . . . . . . . . . . . 86

12. Segundo nivel de interacción . . . . . . . . . . . . . . . . . . . . . . . . . 87

13. Correspondencia entre entradas y propiedades perceptibles . . . . . . . . . 93

14. Correspondencia entre salidas y propiedades perceptibles . . . . . . . . . . 94

15. Representación de un sistema . . . . . . . . . . . . . . . . . . . . . . . . . 95

16. Modelo de sistema perceptible por un operador . . . . . . . . . . . . . . . 99

17. Sistema operable con un Frontend de Operaciones . . . . . . . . . . . . . . 102

18. Sistema operable con un panel de control . . . . . . . . . . . . . . . . . . 103

19. Relación entre Sistema y Frontend de Operaciones del Sistema . . . . . . . 105

20. Interacción entre Sistema y Frontend de Operaciones . . . . . . . . . . . . 109

21. Modelo de operaciones de un sistema . . . . . . . . . . . . . . . . . . . . 117

22. Tipos de sistemas ya creados . . . . . . . . . . . . . . . . . . . . . . . . . 119

23. Metamodelo de operaciones del sistema (System Operations Metamodel) . 143

24. Perfil de operaciones del sistema (U2OP) . . . . . . . . . . . . . . . . . . 156

25. Perfil de operaciones del sistema (U2OP) con restricciones . . . . . . . . . 158

26. Metamodelo de frontend de operaciones (OperationsFrontend Metamodel) . 171

27. Nivel 1. Interacción operador-sistema . . . . . . . . . . . . . . . . . . . . 187

28. Nivel 2. Interacción SOF-sistema . . . . . . . . . . . . . . . . . . . . . . . 189

29. Nivel 3. Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

30. Nivel 4. GUI orientado al operador del sistema . . . . . . . . . . . . . . . 191

31. Nivel 5. Componentes del SOF . . . . . . . . . . . . . . . . . . . . . . . . 192

32. Sistema de máquinas de juego de azar interconectadas . . . . . . . . . . . . 213

33. Diagrama de casos de uso de una máquina acumulador . . . . . . . . . . . 222

34. “Workflow"de una máquina de juego . . . . . . . . . . . . . . . . . . . . . 223

35. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

36. Diagrama de actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

37. Diagrama de secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

38. Diagrama de estados de una máquina acumulador . . . . . . . . . . . . . . 239

39. Diagrama de clases decorado con el perfil U2OP . . . . . . . . . . . . . . 243

40. Frontend de operaciones en procesos de validación y operación . . . . . . . 259

41. Proceso de desarrollo enriquecido por el MOS . . . . . . . . . . . . . . . . 262

Lista de Acrónimos y Abreviaturas

AF Autómata Finito

AFD Autómata Finito Determinista

AFND Autómata Finito No Determinista

AIAA American Institute of Aeronautics and Astronautics

ANSI American National Standards Institute

API Application Program Interface

CON Variables Controladas

ConOps Concept of Operations

CBD Component-Based Development

DSML Domain-Specific Modelling Language

ECSS European Cooperation for Space Standardization

ESA European Space Agency

ETSI European Telecommunications Standards Institute

FS Functional Specification

FSM Finite State Machine

GUI Graphical User Interface

ICD Interface Control Documentation

ITS Intelligent Transportation Systems

IEEE Institute of Electrical and Electronics Engineers

I/O Input/Output

ITU International Telecommunications Union

LSC Live Sequence Charts

MDA Model Driven Architecture

MDD Model Driven Development

MDE Model Driven Engineering

MOF Meta-Object Facility

MON Variables Monitorizadas

MOS Modelo de Operaciones del Sistema

MSC Message Sequence Charts

NA No Aplicable

NAT Naturaleza

OAR Object-Attribute-Relation

OCL Object Constraint Language

OI Operation Interface

OMG Object Management Group

PIM Platform-Independent Model

PLUTO Procedure Language for Users in Test and Operations

REQ Requisitos

RUP Rational Unified Process

SDL Specification and Description Language

SE System Element

SOA Service-Oriented Architectures

SOF System Operations Frontend

SUO System Under Operation

SUT System Under Test

SysML System Modelling Language

SYST System and Software Technologies

SW Software

TOPEN Test and Operation Environment

TP Test Procedure

TS Technical Specification

TTCN-3 Testing and Test Control Notation

U2OP UML 2 Operations Profile

U2TP UML 2 Testing Profile

UML Unified Modelling Language

UPM Universidad Politécnica de Madrid

WSDL Web Service Description Language

Capítulo I

INTRODUCCIÓN

“No dejes apagar el entusiasmo,

virtud tan valiosa como necesaria;

trabaja, aspira, tiende siempre hacia la altura.”

Rubén Darío

1

1.1. Planteamiento de la tesis doctoral

En el contexto de este trabajo, los sistemas se entenderán de manera general, como

sistemas intensivos en software. Este tipo de sistemas representan típicamente sistemas

heterogéneos que incluyen componentes software junto con otro tipo de dispositivos, que

les permiten interaccionar con su entorno [60]. Esta interacción se produce típicamente

mediante sensores y actuadores integrados en el sistema o mediante servicios software.

Broy plantea que el desarrollo de sistemas intensivos en software requiere de una amplia

corriente de investigación, soportada por nuevas competencias técnicas, que incluyan una

buena comprensión del modelado de sistemas, el uso efectivo de modelos, y una teoría de

modelado de sistemas de eventos discretos [29].

Un factor clave en el rendimiento efectivo de este tipo de sistemas radica en el grado

de conocimiento que tengan los operadores del funcionamiento del sistema [4]. Este co-

nocimiento incluye, al menos, el comportamiento del sistema observable externamente, es

decir, el conocimiento de las interacciones que pueden darse entre el sistema y el opera-

dor, por medio de la aplicación o aplicaciones externas que posibilitan las operaciones del

sistema.

Así pues, la especificación y modelado de requisitos de operación del sistema juega un

papel muy importante dentro del ciclo de vida de los sistemas intensivos en software, ya

que permite conocer al conjunto de los desarrolladores desde un principio las necesidades

y expectativas de los usuarios u operadores que utilizarán el sistema. De ahí que ciertos

estándares incluyan el concepto de operación, y pautas para expresar un documento de

operaciones del sistema que recoja los requisitos de operación del sistema [83] [82] [79]

[55] [76] [12] [123].

Las operaciones del sistema por tanto constituyen una parte esencial del conocimien-

to relacionado con cualquier sistema. Sin embargo, el desarrollo de sistemas a menudo,

no contempla el punto de vista de operaciones del sistema como un elemento clave en el

2

proceso de desarrollo. Los aspectos de operaciones del sistema se abordan de manera im-

plícita y lateral junto con el resto de aspectos o puntos de vista del sistema que sí reciben

atención preferente. Así, los aspectos de operaciones del sistema figuran como intereses

cruzados (crosscutting concern) en el conjunto global de los artefactos producidos durante

el desarrollo del sistema. El estándar IEEE 1471 - IEEE Recommended Practice Archi-

tectural Description of Software-Intensive Systems [78], define punto de vista como una

especificación de reglas para construir una vista del sistema que comprenda una serie de

aspectos de stakeholders 1. Sería por tanto interesante enfocar el desarrollo de un sistema

incluyendo el punto de vista de operaciones, al objeto de separar el interés (concern) de

operaciones del sistema de una manera nítida a lo largo del ciclo de vida del sistema.

En sistemas de espacio por ejemplo, las operaciones de carga de pago (payload) se con-

vierten en un aspecto crítico ya que una vez la nave espacial está en el espacio puede ser

muy difícil o imposible determinar un problema. Para sistemas de espacio, es recomendable

e incluso forzoso producir modelos de operación en etapas tempranas del desarrollo. Las

pruebas de carga de pago (payload) son exhaustivas, y para ello Timmermans sostiene que

debe estar disponible un modelo de operaciones [160]. Las pruebas se definen utilizando

esta especificación del modelo de operación. Los sistemas de espacio utilizan a menudo co-

mo línea base telemetría y telecomandos. Esto es, el sistema de tierra envía un telecomando

a la nave espacial y ésta responde con una telemetría. Esta aproximación es un esquema

muy simple y eficiente para modelar la interacción del sistema. Como justifican Garbajosa

et al. en [62], este esquema se puede transportar fácilmente, en términos orientados a obje-

tos, una operación, el telecomando, y un objeto, la nave espacial, que devuelve un valor, la

telemetría. Obviamente es posible refinar este esquema para una carga de pago (payload)

basada en objetos y operaciones asociadas.

El enfoque de modelo de operación en sistemas de espacio puede utilizarse en otros

tipos de sistemas, aunque pueda necesitarse una metodología propia y una infraestructura

1conjunto de personas implicadas en el desarrollo y operación del sistema

3

de herramientas. Este trabajo persigue proporcionar una aproximación en la que los mo-

delos de operaciones del sistema sean una piedra angular para el desarrollo, validación y

operación de sistemas.

Esta tesis doctoral se enmarca dentro de la línea de investigación “Modelado y especi-

ficación de sistemas complejos”. El modelado de sistemas complejos, y de sistemas en

general, constituye un pilar fundamental tanto en el desarrollo como en la evolución de és-

tos. Los modelos aportan conocimiento del sistema al conjunto de stakeholders implicados

(ya sean pasados, presentes o futuros) facilitando el entendimiento y comprensión global

del mismo.

Habitualmente el modelado de sistemas y software se centra en el comportamiento

interno del sistema, identificando las operaciones e interacciones que tienen lugar entre los

diferentes componentes que integran un sistema. El enfoque de esta tesis, se centra en la

interacción entre sistema y operador, esto es en las operaciones que le llegan al sistema

desde el exterior.

Dado que no se suele tener en cuenta el punto de vista de operaciones, que incluye esta

interacción entre sistema y operador, el modelado de sistemas no refleja de manera explícita

los aspectos de operaciones [4]. Sin embargo, varios estándares y guías de ingeniería de

sistemas y software publicados hace ya varios años, sí que resaltan la importancia de tener

en cuenta las operaciones del sistema en el proceso de desarrollo:

“ISO/IEC 15288, Systems engineering - System life cycle processes” [83], que es-

tablece un marco común para describir el ciclo de vida de sistemas, incluyendo el

proceso de utilización u operación del sistema.

“ISO/IEC 12207, Standard for Information Technology - Software Lifecycle Pro-

cesses” [82], en línea con el anterior.

“IEEE 1362 Guide for Concept of Operations Document” [76], que define el concep-

to de documento de operaciones llamado ConOps.

4

“INCOSE System Engineering Handbook” [79], que propone la definición de un

documento de operaciones ConOps como parte de la especificación de requisitos del

sistema.

El “Systems Engineering Guidebook for ITS” [35] publicado por el “California De-

partament of Transportation Division of Research and Innovation” incluye la etapa

de definición del concepto de operaciones del sistema previa a la especificación de

requisitos del sistema, dentro del ciclo de vida de un proyecto ITS (Intelligent Trans-

portation Systems).

“ANSI/AIAA G-043-1992 Guide for the Preparation of Operational Concept Docu-

ments” [12], que define una guía para preparar documentos con el concepto opera-

cional.

El item DI-IPSC-81430 del estándar militar de Estados Unidos “MIL-STD-498 Soft-

ware Development and Documentation” [123], en la misma línea que el anterior.

Tanto es así que estos estándares proporcionan guías y plantillas específicas para con-

feccionar documentos que describan los requisitos de operación del sistema. Pero aun así,

nos encontramos que la formalización existente para modelar las operaciones del sistema

es escasa.

Esta tesis doctoral plantea una solución para formalizar la interacción entre sistema y

operador, especificando el modelado de la interacción de un sistema con el exterior. Dicho

modelado comprende el sistema observable externamente, dónde el operador percibe un

sistema como un conjunto de elementos interconectados. Nuestro enfoque se centra en la

parte del sistema perceptible por el operador y en la interacción entre ambos.

El modelado de esta interacción permitirá:

1. Incorporar las operaciones en el modelado de sistemas, dando forma a las recomen-

daciones de estándares como los citados anteriormente.

5

2. Enriquecer el proceso de desarrollo de un sistema, incorporando el modelado de la

interacción del sistema tempranamente en el desarrollo de un sistema.

3. Facilitar la validación y operación de sistemas, por medio de una aplicación externa

al sistema que facilite la interacción con el sistema.

Por otra parte, la solución propuesta para modelar la interacción entre sistema y opera-

dor podrá aplicarse en:

1. El proceso de desarrollo de sistemas de nueva creación. En este sentido, esta tesis

plantea la conveniencia de realizar el modelado de las operaciones en etapas tem-

pranas del proceso de desarrollo, para que en la medida de lo posible guíe el desarro-

llo del sistema.

2. La validación y operación de sistemas ya existentes. El modelo de operaciones del

sistema puede utilizarse en el desarrollo de herramientas de validación de sistemas y

de operación/monitorización de sistemas.

Por otra parte, respecto al comportamiento de un sistema, nos encontramos que el fun-

cionamiento real de muchos sistemas lleva a situaciones no deterministas porque aun con

sistemas basados en modelos deterministas no es posible modelar el comportamiento para

un número de entradas muy elevado (millones) y en un orden desconocido a priori (se

conoce la historia pero no se puede predecir a priori). En este trabajo se simplificará el

comportamiento de un sistema en función de sus entradas y salidas, por lo que se hará

una abstracción de la problemática asociada al determinismo o no determinismo del com-

portamiento de los sistemas. Así pues, este trabajo no trata de profundizar en el compor-

tamiento interno de un sistema o de elementos individuales de éste, si no en las interac-

ciones posibles entre un sistema y un medio externo de operación del mismo. Se centrará

en determinar cómo interactuar con el sistema, definiendo un modelo de interacción del

sistema.

6

1.2. Motivación y objetivos

Desde hace varios años el grupo de investigación SYST (System and Software Tech-

nologies) de la Universidad Politécnica de Madrid (UPM) viene trabajando en el desarrollo

de herramientas software orientadas a la validación y operación de sistemas. Como re-

sultado de una amplia actividad en proyectos europeos y nacionales se ha desarrollado

TOPEN (Test and Operation Environment), un entorno de validación y operación propio,

en cuya evolución y diseminación de resultados, ha participado en parte el autor de este

trabajo [2] [3] [5] [6] [7] [8] [9] [10] [63].

TOPEN es un entorno de pruebas y operación de sistemas complejos que permite re-

alizar pruebas de aceptación y operaciones en sistemas que dispongan de una interfaz soft-

ware de interacción con el sistema. Una descripción de las funcionalidades de TOPEN se

puede encontrar en [62] [10], y una descripción de la arquitectura que se desarrolló para

TOPEN se encuentra en [64]. También se ha llevado a cabo una tesis doctoral [114] que de-

fine una arquitectura genérica y una línea de producto para herramientas de validación de

sistemas, planteando una arquitectura lo suficientemente general para soportar diferentes

dominios de aplicación sin cambios esenciales en el producto para realizar la validación.

En el área de validación de sistemas existe un vacío de herramientas software que per-

mitan comprobación y operación de dispositivos y sistemas industriales complejos [114].

Estos sistemas tienen la característica común de poder ser operados a través de una serie

de comandos, descritos como procedimientos en un lenguaje de programación conven-

cional [62]. También estos sistemas responden a estímulos externos y por eso no siempre

es posible la automatización completa de la generación de los procedimientos de prueba

[43], siendo indispensable la participación directa del ingeniero de pruebas. De esto últi-

mo, deriva la idea de la definición de procedimientos de prueba asistida, proporcionando

soporte al ingeniero de pruebas.

TOPEN proporciona a los ingenieros de pruebas un marco para definir, compilar y

7

ejecutar procedimientos de prueba, Test Procedure (TP), sobre el sistema a validar y alma-

cenar la información de los procedimientos de prueba y el resultado de sus ejecuciones. En

TOPEN, la definición de un procedimiento de prueba, TP, se realiza mediante un lenguaje

de alto nivel, cercano al ingeniero de pruebas, descrito con una sintaxis orientada al dominio

de aplicación. Un TP está compuesto de una serie de comandos de operación, que incluye

comandos para especificar los valores de entrada, el procesamiento de la prueba y los resul-

tados esperados. Los comandos de un TP deben seguir la gramática previamente definida

para el dominio de aplicación del sistema a validar. Los datos almacenados relativos a los

resultados de las ejecuciones de los TP permiten obtener el veredicto de las pruebas rea-

lizadas, e incluso validar algunos requisitos que requieren la evaluación del resultado de

varias ejecuciones de un mismo TP, o del resultado de un conjunto de procedimientos.

El entorno TOPEN comenzó a desarrollarse dentro del proyecto ARCO (TIC98-0782),

y mejorado dentro del proyecto MOVASS (TIC2001-3450). Inicialmente ideado para un

sistema de telecomunicaciones, más tarde se adaptó a dos dominios de aplicación dife-

rentes, uno de los cuales fue un sistema de máquinas de juego interconectadas en red, en

colaboración con el centro tecnológico Labein de la agrupación Tecnalia, dentro del con-

texto del proyecto europeo METSES (IST-2000-28583). Una de las metas del grupo es

conseguir la generación de entornos de validación basados en pruebas de aceptación a par-

tir de los requisitos del sistema que se quiere probar. En esta línea se ha desarrollado el

proyecto AGMOD (TIC2003-08503). Algunos resultados de estos proyectos se pueden en-

contrar en [5], [8] y [9]. Los últimos trabajos del grupo en este ámbito están orientados

al modelado de los requisitos necesarios para la generación del entorno de validación y se

han publicado ya algunos resultados en [4] y [176]. Otra de las metas se orienta a definir

un modelo de proceso centrado en los requisitos de operaciones y pruebas de validación de

los sistemas a desarrollar, objetivos que se cubren en los proyectos en desarrollo OVAL/PM

(TIN2006-14840) y FLEXI (FIT-340005-2007-37). Salvo en el primero de los proyectos

de nombre ARCO, en todos los demás el autor de este trabajo ha formado o forma parte

8

del equipo de investigadores del proyecto.

La búsqueda de soluciones arquitectónicas y de operaciones aplicables a diferentes do-

minios de aplicación para TOPEN, permitió detectar una serie de problemas a la hora de

modelar y representar la interacción entre el operador y el sistema, a partir de los requisitos

del sistema. De ahí, que el motivo marcado al comenzar los trabajos que han conducido a

la realización de esta tesis fuese el siguiente:

Existe un vacío en el modelado de sistemas ya que no se refleja de manera

explícita el conocimiento de las operaciones del sistema. Los estándares de

ingeniería de sistemas y software resaltan la importancia de las operaciones

del sistema, incluso proporcionan plantillas para confeccionar documentos de

operaciones en el contexto de ingeniería de requisitos y especificación. Pero sin

embargo, no proporcionan guías específicas para el modelado de operaciones.

El objetivo principal de esta tesis, planteado en el anteproyecto de la misma, es el si-

guiente:

É ́ ,

,

́ , ́

́ ́.

Basados en este objetivo principal, se han marcado un conjunto de objetivos parciales:

1. Identificar y formalizar los conceptos conducentes a la especificación del modelo de

interacción de un sistema y de los elementos que lo forman.

2. Definir el concepto de modelo de operaciones de un sistema (MOS).

9

3. Proponer metamodelos que faciliten la representación de las operaciones en el pro-

ceso de modelado de sistemas, y de su desarrollo en general.

4. Enriquecer el proceso de desarrollo de sistemas, incorporando el modelo de opera-

ciones en etapas iniciales del desarrollo de sistemas.

Considerando los objetivos expuestos, la hipótesis de partida de este trabajo es la si-

guiente:

V -

́ , ́

́ .

1.3. Metodología de investigación de la tesis

La metodología de investigación utilizada para alcanzar los objetivos marcados en esta

tesis doctoral ha sido la de “Investigación en Acción” [15] [17] [145]. En los últimos años

los métodos de investigación cualitativos y en especial Investigación en Acción, están sien-

do aceptados en la comunidad investigadora de sistemas de información e ingeniería del

software. Davidson apunta que este hecho se aprecia en el aumento de artículos publicados

sobre Investigación en Acción en el dominio de sistemas de información [45].

El método de investigación en acción se fundamenta en la idea de que la teoría y la

práctica pueden integrarse estrechamente, aprendiendo de los resultados de las actuaciones

planificadas tras un análisis cuidadoso del contexto del problema.

La figura 1 muestra el ciclo de actividades del proceso de Investigación en Acción,

consistente en las siguientes fases:

1. Planificación. En esta fase se identifican cuestiones relevantes que permitan guiar la

investigación. El trabajo de investigación se realimenta, con el proyecto de inves-

tigación en curso o mediante nuevos proyectos de investigación que proporcionen

10

Figura 1: Ciclo de actividades del método Investigación en Acción

el marco para estos nuevos aspectos o problemas a investigar. En esta tesis, la in-

vestigación se ha ido realimentando principalmente por medio de los proyectos de

investigación del grupo de investigación Syst.

2. Acción. Consiste en una variación de la práctica mediante una simulación o prueba de

la solución. En esta fase, el investigador en acción trabaja en los intereses temáticos

del grupo de trabajo participando en las fases de planificación, actuación, observación

y reflexión del núcleo de proyectos investigación-acción del grupo (definidos como

“core action research” por Perry y Zuber-Skerritt [138]). En nuestro caso, se ha lla-

mado marco de proyectos a dicho núcleo. La figura 2 muestra el marco de proyectos

relacionado con esta tesis, del grupo de investigación Syst, en los que el autor de esta

tesis ha participado aplicando el método de investigación en acción, realimentando

la acción investigadora que ha propiciado la realización de esta tesis doctoral. Dicho

marco de proyectos será descrito en el siguiente apartado.

3. Observación. El objetivo de esta fase es recoger información, tomar datos y docu-

mentar lo que ocurre. Durante esta fase de observación en la investigación en acción

de la tesis, se ha descrito tanto la investigación como el procedimiento seguido. Así,

11

Figura 2:Marco de proyectos Investigación en Acción en esta tesis

se ha ido realizando un análisis y evaluación de los resultados de las acciones reali-

zadas en la etapa anterior, teniendo en cuenta la literatura relacionada.

4. Reflexión. Esta cuarta fase tiene como objetivo analizar y compartir los resultados

obtenidos en la etapa anterior. Por un lado, se han planteado nuevas cuestiones re-

levantes, comenzando un nuevo ciclo en la investigación en acción (fase de planifi-

cación). Por otro lado, se han ido refinando las soluciones encontradas, publicando

artículos en conferencias relacionadas con la investigación, e incorporándolas a la

memoria de la tesis doctoral.

1.4. Marco de desarrollo de la tesis

El marco de proyectos relacionados con el desarrollo de esta tesis, está compuesto por

un conjunto de proyectos de investigación realizados en el seno del grupo de investigación

Syst de la UPM, representados en la figura 2.

1. ARCO: “Arquitectura de Sistemas y Comprobación de Operación” (1998-2001).

12

Este proyecto fue financiado por el Ministerio de Ciencia y Tecnología (TIC98-0782-

R98612501).

2. METSES: “Multiple-site Environment for testing Systems with Embedded Soft-

ware” (2000-2002). Este proyecto fue financiado por la UE dentro del V Programa

Marco-IST (Ref. IST-2000-28583). La actividad de prueba en sistemas compuestos

por elementos inter-conectados con software embebido es compleja y sofisticada.

Es necesario probar el comportamiento dinámico del sistema completo, no es sufi-

ciente probar cada elemento independientemente. El objetivo de este proyecto fue

desarrollar un entorno de pruebas para sistemas complejos con componentes inter-

relacionados, que pudiera ser adaptado a diferentes sistemas industriales con poco

esfuerzo. Este proyecto soporta la ejecución remota de pruebas con una arquitectura

cliente-servidor y, por tanto, puede ser utilizado por equipos distribuidos geográfica-

mente coordinando la realización de las pruebas. Soporta la descripción de pruebas

descritas en un lenguaje de alto nivel, con una sintaxis orientada a dominio. MET-

SES, basado en el entorno TOPEN (Test and Operation Environment) desarrollado

dentro del proyecto ARCO, permite al ingeniero de pruebas definir pruebas a nivel de

usuario, descritas en una sintaxis orientada a dominio, así como compilar y ejecutar

procedimientos de pruebas en el sistema a probar.

3. MOVASS: “Modelo y Herramienta para el Proceso de Especificación de Pruebas

de Validación de Sistemas Software” (2002-2004). Este proyecto ha sido financiado

por el Ministerio de Ciencia y Tecnología (Ref. TIC 2001-3450). El objetivo básico

del proyecto consistió en especificar un modelo de proceso para pruebas de valida-

ción de sistemas intensivos en software. Los esfuerzos se orientaron a la generación

de una herramienta para automatizar la especificación y ejecución de pruebas de

aceptación, partiendo del trabajo realizado previamente con TOPEN. Se definieron

nuevos escenarios basados en aplicaciones industriales para utilizar como entradas

13

en la especificación del modelo de proceso, en conjunción con el proyecto METSES

que transcurrió en paralelo. Se consiguió mejorar el proceso de construcción de la

herramienta TOPEN, disminuyendo su coste de adaptación a nuevos dominios de

aplicación. Este resultado se consiguió a través de una mayor generalidad de los pa-

trones de diseño y de datos. Por otra parte también se avanzó en la generación de

uno de los componentes de la herramienta, el generador de código, a partir de un

modelo de datos y de interacción utilizando tecnología XML y Java. Este resultado

tuvo un gran valor dentro de la estrategia del grupo de investigación, ya que permitió

reorientar la manera de construir TOPEN, acercándolo mucho más a las necesidades

de la industria.

4. XNetMod: “XML Based Modelling Language for Simulation of Technical Net-

works”. Este proyecto fue financiado por la Comisión Europea (Ref. IST-2001-52057).

El proyecto tuvo como objetivo principal el desarrollo de una tecnología de mode-

lado basada en lenguajes XML para sistemas con estructura de red, esto es, com-

puestos por elementos interconectados. Otro objetivo derivado del anterior, fue la

evolución y adaptación de herramientas XML para la verificación, transformación

y procesamiento de este tipo de modelos de sistema. Los resultados técnicos se al-

canzaron aplicando la tecnología desarrollada al modelado y simulación de sistemas

representables como redes para dominios de aplicación diferentes, como un workflow

de datos bancarios y la gestión de recursos en una oficina de extinción de incendios

forestales.

5. DOBERTSEE: “Dependant On-Board Embedded Real-Time Software Engineering

Environment /Low-Cost On-Board Software Development Toolkit”. Este proyecto

fue financiado por ESA/ESTEC (Ref. Contrato 15133/01/NL/ND). El principal ob-

jetivo de este proyecto fue producir un entorno de ingeniería del software integrado,

14

Software Engineering Environment (SEE), que contemplase por completo el están-

dar de modelo de proceso ECSS-E40 para el desarrollo de software embarcable de

tiempo real, Dependable On-Board Real Time software (DOBERT). El modelo de

proceso DOBERTSEE está centrado en documento. Cada documento se expresa en

CASEML (CASE Markup Language), un lenguaje de descripción basado en XML.

El SEE ha supuesto un valioso experimento para obtener una capa ligera de inge-

niería del software utilizando tecnologías asequibles, facilitando al mismo tiempo la

integración con herramientas CASE existentes. El entorno desarrollado se ha basado

en los lenguajes CASEML y Tcl/Tk.

Se realizó una extensión de este proyecto, DOBERTSEE CCN-1, consistente en in-

tegrar un entorno de pruebas, en concreto TOPEN, con el entorno de ingeniería SEE

desarrollado. La integración se basó en la incorporación en documentos CASEML de

especificaciones de pruebas de aceptación y de resultados de sus ejecuciones medi-

ante TOPEN. De esta manera se consiguió lanzar pruebas de aceptación, compuestas

de operaciones sobre el sistema, directamente desde el SEE y almacenar los resul-

tados de dichas pruebas automáticamente en documentos CASEML. Otro logro de

este proyecto fue establecer un esquema completo de trazabilidad desde requisitos a

pruebas.

6. AGMOD: “Generación Automática de Herramientas basadas en Modelos de Sis-

temas y Procesos” (2003-2006). Este proyecto ha sido financiado por el Ministerio

de Educación y Ciencia (Ref. TIC 2003-08503). El objetivo de este proyecto fue

realizar una aproximación al desarrollo de productos software, centrada en los requi-

sitos de operación y en las pruebas de validación como piezas clave del desarrollo de

sistemas. Se fundamenta en la definición de proceso y la integración de un conjunto

de herramientas existentes compartiendo una filosofía común subyacente al proce-

so definido. Los requisitos de operación y las pruebas de validación constituyen las

bases para el diseño de sistemas permitiendo un ciclo de vida flexible e incremental,

15

pero rigurosamente desarrollado y facilitando la ingeniería colaborativa centrada en

las necesidades del usuario. El proceso obtenido se enmarca dentro de estándares

aceptados de ingeniería de software y sistemas tales como IEEE Std 1362-1998 Con-

cept of Operation (ConOps), ISO 12207, Software lifecycle processes e ISO 15288

System lifecycle processes.

7. OVAL/PM: “Modelo de Proceso Centrado en Requisitos de Operación y Pruebas de

Validación”. Este proyecto está siendo financiado por el Ministerio de Educación y

Ciencia (Ref. TIC 2006-14840). Pretende producir una nueva aproximación al desa-

rrollo de productos. Esta aproximación se centra en los requisitos de operación y en

las pruebas de validación como las piezas clave del desarrollo de sistemas, lleván-

dose a cabo en términos de definición de proceso y un conjunto de herramientas.

El conjunto de herramientas se basará en un número de herramientas existentes que

compartirán una filosofía común subyacente al proceso propuesto. Los requisitos de

operación y las pruebas de validación serán las bases para el diseño de sistemas per-

mitiendo un ciclo de vida flexible e incremental, pero rigurosamente desarrollado y

facilitando la ingeniería colaborativa utilizando una aproximación basada en el acer-

camiento a las necesidades del usuario. El proceso obtenido se enmarcará dentro de

estándares de ingeniería de software y sistemas ampliamente aceptados. La introduc-

ción de estándares facilitará que los resultados del proyecto encajen con las prácti-

cas de ingeniería bien establecidas. La aproximación considerará el uso de líneas de

producto para soportar la arquitectura del producto. Aunque otras prácticas arquitec-

tónicas podrían tenerse en consideración, ésta facilitará que el resultado del proyecto

se centre en un campo de probado éxito, facilitando su aplicabilidad.

8. FLEXI: “Flexible Integration in Global Product Development”. Este proyecto está

16

siendo financiado por el Ministerio de Industria, Turismo y Comercio (Ref. FIT-

340005-2007-37, ITEA2 6022). El objetivo de este proyecto es mejorar la compet-

itividad de la industria europea de software intensivo, proporcionando una aprox-

imación flexible, rápida y ágil al desarrollo de productos software que asegure un

desarrollo eficiente de sistemas embebidos y servicios confiables y seguros en un

contexto de desarrollo global. La finalidad de FLEXI es ofrecer medios para obtener

altos rendimientos de negocio: “Desde la idea al producto en seis meses de tiempo”.

Una de las tareas de este proyecto consistirá en aplicar el modelo de operaciones del

sistema definido en esta Tesis, a modelos de proceso de desarrollo ágiles.

1.5. Presentación de la tesis

La memoria de la tesis se ha estructurado en una serie de capítulos. El primer capítulo

que corresponde al actual, conforma la introducción del trabajo y contiene una descrip-

ción del planteamiento general de esta tesis, de la motivación y objetivos perseguidos con

la realización de ésta, del marco de desarrollo de la tesis, y de la metodología de investi-

gación seguida. El segundo capítulo presenta el estado del arte que ha sido analizado por su

relación con los aspectos conducentes a la especificación del modelo de interacción entre

sistema y operador.

El tercer capítulo incluye la definición del concepto de sistema operable; esta defini-

ción es un requisito para la especificación de un modelo de operaciones de un sistema. La

definición realizada incluye tanto la visión intra-elementos como la visión inter-elementos

de un sistema. A partir de ésta, se ha definido el concepto de frontend de operaciones de un

sistema, que proporciona el marco adecuado para utilizar el modelo de operaciones.

En el cuarto capítulo se define el concepto de modelo de operaciones de un sistema, el

ámbito de aplicación del mismo, y se identifican el subconjunto de requisitos de un sistema

necesarios para la especificación de un modelo de operaciones.

El quinto capítulo presenta una propuesta de representación del modelo de operaciones

17

de un sistema. Esta propuesta incluye la descripción de un metamodelo del modelo de

operaciones de un sistema, y basado en éste, un perfil UML para representar modelos de

operaciones, al que llamaremos UML 2 Operations Profile (U2OP).

En el sexto capítulo se plantea la utilización del modelo de operaciones de un sistema

como soporte en el modelado de un frontend de operaciones. En concreto se presenta, por

una parte, una propuesta de metamodelo UML que refleja la interacción entre el frontend

de operaciones y el sistema, tomando como base el metamodelo de operaciones definido

en el capítulo anterior. Por otra parte, se describe una arquitectura conceptual del frontend

de operaciones empleando los diferentes niveles de abstracción existentes en la interacción

entre operador y sistema. Y por último se plantea un conjunto de comandos básicos de

operación del sistema aplicable a diferentes dominios de aplicación.

El capítulo séptimo presenta como caso de estudio un sistema de máquinas de juego

interconectadas. Se describe el modelo del sistema por medio de diagramas UML, y a

continuación se define el modelo de operaciones de este sistema utilizando el perfil U2OP

descrito en el quinto capítulo.

En el octavo capítulo se analiza la utilización del modelo de operaciones de un sistema

en procesos de desarrollo software y se propone una aproximación a un modelo de proceso

software dirigido por el modelo de operaciones.

Y finalmente, en el noveno y último capítulo se presentan las conclusiones de la tesis, a

modo de resumen de los logros alcanzados, de los resultados contrastados en diversos foros

y de las posibles líneas de investigación a las que puede dar lugar.

1.6. Resumen del capítulo

Este capítulo comprende una introducción a la tesis doctoral, en el que se ha explica-

do la razón de su planteamiento, y se ha presentado el área de investigación en la que se

enmarca: modelado y especificación de sistemas complejos. También se incluyen la moti-

vación y objetivos tenidos en cuenta para la realización de esta tesis doctoral, estableciendo

18

el objetivo principal y objetivos específicos a conseguir, así como la hipótesis de partida.

Además, se ha indicado el marco de proyectos de investigación en los que se ha desarro-

llado esta tesis, y la metodología de investigación seguida para su desarrollo: Investigación

en Acción.

19

20

Capítulo II

ESTADO DEL ARTE

“En los momentos de crisis, sólo la imaginación

es más importante que el conocimiento.”

Albert Einstein

21

2.1. Introducción

En este capítulo se presenta el estado del arte que se ha analizado en relación con este

trabajo. En primer lugar, se presentan una serie de definiciones y visiones del concepto de

sistema desde el punto de vista de interacción realizadas por diferentes autores. En segundo

lugar, se analiza un conjunto de paradigmas que permiten representar dicha interacción

entre sistema y operador.

En tercer lugar, se analizan ciertos estándares de ingeniería del software y sistemas que

tratan esta interacción entre sistema y operador por medio del concepto de operación den-

tro del desarrollo de sistemas. También se incluyen otros estándares que definen lenguajes

procedimentales orientados a la operación y la validación de sistemas. Se incluye la valida-

ción de sistemas ya que está estrechamente relacionada con la operación de sistemas, dado

que para realizar ciertas pruebas, especialmente las de aceptación, se hace necesario llevar

a cabo operaciones sobre el sistema.

En cuarto lugar, se analiza la relación entre el modelo de interacción del sistema que

se define en esta tesis y el enfoque de desarrollo de sistemas dirigido por modelo (MDD),

dado que dicho modelo de interacción puede utilizarse como base para dirigir el desarrollo

de un sistema. Esta revisión se centra en la ingeniería dirigida por modelo, Model Driven

Engineering (MDE), como filosofía y no tanto en técnicas o procesos que permitan su

aplicación.

Por último dentro de este capítulo, se presenta una sección de resumen y conclusiones

sobre el estado del arte analizado y su relación con esta tesis.

2.2. Sistemas desde el punto de vista de interacción

En esta sección se presenta sistema desde el punto de vista de interacción con su en-

torno. Tal y como plantea Wang, los sistemas son las entidades y fenómenos más com-

plicados de abordar en el mundo físico, de la información y social a través de todas las

disciplinas de la ciencia y de la ingeniería [171]. Una de las primeras tareas marcadas al

22

emprender este trabajo, consistió en analizar diferentes visiones o concepciones de sistema

presentadas por distintos autores, y que posteriormente nos permitiese expresar nuestro

propio concepto de sistema. En esta sección, se incluyen algunas de las visiones de sistema

analizadas.

2.2.1. Visión filosófica de Bunge

Como parte de un tratado de filosofía básica, Bunge [32] define un sistema Σ como una

terna ordenada compuesta por los siguientes elementos:

[C(Σ), E(Σ), S (Σ)] (1)

en la que:

C(Σ)

Composición de Σ, representa el conjunto de partes de Σ.

E(Σ)

Entorno de Σ, es el conjunto de aquellos elementos que, sin pertenecer a C(Σ), actúan

sobre sus componentes o están sometidos a su influencia.

S(Σ)

Estructura de Σ, es el conjunto de relaciones y vínculos de los elementos de C(Σ)

entre sí o bien con los miembros del entorno E(Σ).

La definición de sistema enunciada por Bunge [32] incluye los componentes o elemen-

tos que componen un sistema, las relaciones entre ellos y por último, el entorno con el que

interactúa. Esta definición aunque proveniente del campo de la filosofía y aún siendo muy

general ya que no describe en qué consisten las relaciones y vínculos entre los componentes

de un sistema y entre éstos y el entorno, por ejemplo en términos de estímulos y respuestas,

o de entradas y salidas, se ha incluido por dos razones. Primero porque coincide con la

visión que se va a adoptar en este trabajo de la estructura de un sistema como elementos

23

interconectados, y que será tratada en el capítulo siguiente. Y en segundo lugar porque se

ha pretendido dejar patente que el concepto de sistema va más allá del campo de la inge-

niería, abarcando prácticamente todo lo que rodea al ser humano (su mundo) e incluso su

propia composición física y psíquica (naturaleza y metafísica).

2.2.2. Jackson: el mundo y la máquina

Jackson en su artículo “The World and the Machine” en el que llama máquina al sis-

tema y mundo a su entorno, plantea que un software se construye para conseguir, mediante

dispositivos físicos, atender propósitos prácticos en el mundo [87]. Así, el software es una

descripción de una máquina. Construimos la máquina describiéndola y presentándola en

un ordenador de propósito general que toma los atributos y comportamientos que hemos

descrito. La máquina tiene sentido en el mundo en el que se instala y utiliza. Por ejemplo,

el valor de un sistema de procesamiento de textos no se evalúa y juzga examinando su

estructura de software o código, sino por la calidad de los documentos que produce y la

facilidad y satisfacción de los operadores que lo utilizan.

Los requisitos, que constituyen el problema a resolver, se encuentran en el mundo;

la máquina constituye la solución que se quiere construir. Aunque esto es algo obvio y

conocido, Jackson indica que conviene tenerlo muy en cuenta, para entender la relación

entre mundo y máquina.

Jackson plantea que la relación entre el mundo y la máquina no es sencilla, y que

abarca varias facetas. Reconoce al menos cuatro facetas en esta relación entre el mundo y

la máquina:

Faceta de modelado, donde la máquina simula al mundo;

Faceta de interfaz, donde el mundo toma contacto con la máquina;

Faceta de ingeniería, donde la máquina actúa como un motor de control sobre el

comportamiento del mundo; y

24

Faceta del problema, donde la forma del mundo y del problema influyen en la forma

de la máquina y de la solución.

En palabras de Jackson, la máquina permite aportar soluciones a los problemas del

mundo, si existe una interacción y una interfaz definidos entre el mundo y la máquina. Por

“interacción” entiende la compartición de un fenómeno, es decir, la participación directa

en eventos y estados comunes. Afirma que una parte puede tener la potencia de iniciar

un evento, y la otra parte puede tener o no la capacidad de inhibirlo. De igual manera, se

comparten estados; una parte puede tener la capacidad de cambiar el valor de un estado, y

ambos pueden tener la capacidad de percibirlo.

2.2.3. Sistemas definidos como autómatas

Un sistema puede entenderse como un autómata definido por una serie de estados y un

conjunto de transiciones entre estados, distinguiendo entre autómatas de estados finitos o no

finitos, y deterministas o no deterministas respecto a su comportamiento. Además desde el

punto de vista de interacción, se puede representar un sistema como un autómata que recibe

una serie de entradas y genera una serie de salidas a partir de las entradas recibidas [91]

[112] [97] [24] [31]. Del mismo modo y como una extensión de los autómatas, se utilizan

las máquinas de estados finitos y diagramas de estados (statecharts) para representar el

comportamiento de los sistemas [111] [105] [68] [147] [85], y más recientemente [50].

Un Autómata Finito (AF) es un grafo con un número finito de vértices, llamados es-

tados. Los ejes de un diagrama de estados finitos se llaman transiciones y se denotan con

símbolos tomados del dominio del discurso representado por un alfabeto,∑. Además uno

de los estados debe ser el estado inicial, y de 0 a n representan los estados finales.

Un AF es determinista, Autómata Finito Determinista (AFD), si NS (S,q) es único,

donde NS representa la función siguiente-estado para un estado S del autómata, y una

entrada q estando en el estado S. Un AFD está completamente especificado si NS(S,q) está

siempre definida y parcialmente especificado en caso contrario.

25

Un Autómata Finito No Determinista (AFND) es un AF parcial o completamente es-

pecificado en el que, para algún estado S y para algún símbolo de entrada p, se tiene que

NS(S,p) no es necesariamente único. Es decir, puede existir un estado S con dos transi-

ciones iguales (misma etiqueta) pero distinto estado destino. A esta situación se le suele

llamar conflicto en siguiente-estado. Un AFD es un caso particular de un AFND en el que

no existen conflictos de siguiente-estado. Al igual que para un AFD, los requisitos especi-

ficados, descritos o capturados por un AFND corresponden al conjunto de escenarios que

el AFND acepta. Un requisito que puede ser descrito por un AFD se le llama requisito

regular.

Un AFD realiza una computación o ejecución como respuesta a un escenario de entrada

con origen en∑∗ (siendo

∑el mismo dominio que define al AFD). La computación de un

AFD viene definida por la secuencia de estados por los que el AFD pasa, partiendo del

estado inicial, como consecuencia de la lectura de las entradas que componen el escenario

de entrada (secuencia de entradas, también llamada string). En el caso de los AFND, puesto

que puede existir más de un estado destino para una misma transición, la respuesta a un

escenario de entrada corresponde a un árbol de computación, partiendo del estado inicial.

Para que el AF acepte el escenario de entrada el resultado de la computación tiene que ser

un estado final en el caso de un AFD, y el árbol de computación debe tener alguna hoja que

representa un estado final en el caso de un AFND.

Un AF puede verse como una caja negra que genera una secuencia de valores booleanos

de aceptación/rechazo (valor 1 ó 0) como secuencia de salida. Una máquina de estados

finitos, Finite State Machine (FSM), es similar a un AF, pero en lugar de responder si

acepta o rechaza escenarios de entrada, genera como salida una secuencia de acciones en

respuesta a las entradas.

Las transiciones de un AF se anotan con símbolos tomados de un dominio del discurso

finito (alfabeto) y las transiciones en FSMs se anotan con símbolos de entrada y salida

tomados de alfabetos de entrada y salida respectivamente. Por otra parte, las transiciones

26

en diagramas de estados se anotan con eventos, condiciones y acciones, de la forma:

Evento[condicion]/accion

El evento suele proceder de una entidad externa mientras que una condición suele estar

definida en el sistema. Las acciones que genera el sistema pueden ser enviadas, incluyendo

datos o no, a entidades externas.

Así pues, la definición de un sistema como máquina de estados finitos permite estable-

cer la interacción de un sistema en función de sus entradas y salidas. Si bien su repre-

sentación puede verse limitada cuando existe un gran número de estados en el sistema.

2.2.4. Broy: sistemas reactivos e interactivos

Broy es uno de los autores que más trabajos ha realizado relativos a la descripción

de sistemas. Ha publicado numerosos trabajos orientados a la descripción y formalización

tanto de sistemas reactivos como de sistemas interactivos, entre ellos [24] [31] [25] [27]

[30] [26] [28]. En este apartado se presentan algunas características de ambos tipos de

sistemas desde el punto de vista de la relación entre un sistema y su entorno.

2.2.4.1. Sistemas reactivos

Los sistemas reactivos producen respuestas al recibir estímulos de entrada. Muchas

de las propuestas realizadas para representar el comportamiento de sistemas reactivos se

han basado en el concepto de traza. Una traza describe una secuencia finita o infinita de

acciones de entrada y de salida en un sistema reactivo.

En [24], Broy describe un sistema reactivo en términos de acciones de entrada y de

salida y caracteriza el comportamiento de los sistemas reactivos por medio de conjuntos de

trazas, secuencias de acciones de entrada y de salida. Broy utiliza la definición de sistema

reactivo de Harel y Pnueli [69]: “un sistema reactivo es un sistema abierto que está rela-

cionado con su entorno de tal manera que reacciona ante los estímulos de entrada realizados

desde éste”.

27

Para la descripción de sistemas reactivos mediante trazas, Broy asume que éstos son

asíncronos [24]. En una interacción síncrona el emisor y el receptor deben estar preparados

para establecer la comunicación, sin embargo en una interacción asíncrona cada acción se

realiza exclusivamente por uno de los componentes, sin tener en cuenta si el receptor está

o no preparado para la comunicación.

La interfaz entre el entorno y el sistema reactivo se reduce a acciones de entrada, envi-

adas desde el entorno al sistema, y de salida, enviadas desde el sistema al entorno. Por tanto,

la interfaz de un sistema reactivo con el entorno se describe únicamente por medio del con-

junto de acciones de entrada aceptadas por el sistema y el conjunto de acciones de salida

que puede generar éste. Las acciones de entrada son producidas por el entorno y observadas

por el sistema reactivo que reacciona ante ellas, y las salidas son generadas por el sistema

reactivo y observadas por el entorno. Esta relación entre entorno y sistema queda reflejada

en la figura 3 adaptada de una figura que utiliza Broy para representar esquemáticamente

un sistema reactivo [24].

Broy entiende que los conjuntos de trazas que describen las interfaces están compuestos

por acciones de entrada y acciones de salida, y que la interacción entre el sistema reactivo

y el entorno es asíncrona por lo que las acciones de entrada pueden ocurrir en cualquier

momento (en cualquier posición de la traza) [24]. Denomina sistemas-I/O a los sistemas

reactivos asíncronos, con I como acciones de entrada y O como acciones de salida. Asume

que: 1) un sistema-I/O no puede influir en qué acciones de entrada se producen, ni cuando;

2) y que en cada punto de una historia de ejecución (representada por una traza finita) el

sistema-I/O selecciona la siguiente acción de salida basándose solamente en la información

contenida en la traza finita de acciones de entrada y salida sucedidas anteriormente. Sin

embargo, plantea que dicha selección puede hacerse de forma no determinista.

Una estrategia del sistema determina qué acción de salida, si la hay, debe ser la si-

guiente, dependiendo únicamente de la historia previa, garantizando que las decisiones del

sistema no tienen en cuenta las futuras acciones de entrada. De esta manera, Broy establece

28

Figura 3: Relación entre el sistema y su entorno (adaptada de Broy [24])

una correspondencia entre los sistemas-I/O y las máquinas de estado o autómatas. Dado

que los sistemas reactivos con frecuencia presentan un comportamiento no determinista,

plantea modelar el “no determinismo” mediante estrategias deterministas basadas en con-

juntos de trazas, y argumenta que cualquier conjunto de trazas realizable por una estrategia

no determinista es también realizable por un conjunto de estrategias deterministas.

Los sistemas reactivos pueden describirse mediante autómatas de entrada/salida, autó-

matasI/O, ya que se consideran un mecanismo formal para definir conjuntos de trazas,

equivalentes a los conjuntos de palabras aceptadas [91] [112]. En esta línea, Broy presen-

ta una formalización matemática [24], definiendo un sistema reactivo como un autómata

determinista con entradas y salidas, formado por la siguiente quintupla:

(I,O,Σ, σ0,R, F) (2)

dónde:

29

I: es un conjunto de acciones de entrada, que no contiene la acción silenciosa {τ}.

Broy llama acción silenciosa (silent action) a aquellas acciones que no tienen efecto

sobre el sistema desde el punto de vista de relación con el exterior, su entorno.

O: es un conjunto de acciones de salida, disjunto de I y que no contiene la acción

silenciosa {τ}.

Σ: es un conjunto de estados.

σ0: es el estado inicial del autómata.

R: es un subconjunto de σ x (I ∪ O ∪ σ0) x Σ, llamado el conjunto de transiciones

etiquetadas.

F: representa una colección finita de conjuntos imparciales en la que cada conjunto

imparcial (fairness) es un subconjunto de R.

Broy utiliza σ→a σ′ para denotar una transición etiquetada en R, donde σ, σ’ ∈ Σ y a

∈ (I ∪ O ∪ {τ}). Para Broy, un autómata-I/O representa la tupla (I,O,Σ, σ0,R, F) que tiene

las siguientes propiedades:

1. Para cada estado σ ∈ Σ y acción de entrada i ∈ I, hay un estado σ’ ∈ Σ tal que σ→i σ’

∈ R.

2. Ningún conjunto imparcial F ∈ F puede contener una transición σ→i σ’ con i ∈ I.

3. Cada transición σ →a σ’ ∈ R en la que a ∈ O ∪ {τ} es miembro de algún conjunto

imparcial perteneciente a F.

Estas propiedades tienen el siguiente significado:

Estados en los que el autómata puede aceptar acciones de entrada.

Los conjuntos imparciales no deben restringir la entrada, p.e., solo las decisiones

internas del autómata pueden verse influidas por consideraciones imparciales.

30

Expresan que el autómata es equitativo con respecto a todas las transiciones silen-

ciosas y de salida.

Para esta definición de sistema, Broy se apoya en el comportamiento interno del sis-

tema, caracterizado por estados y sus transiciones. Descripciones en esta misma línea, en

la que se definen un sistema en función de sus estados pueden encontrarse en [168], [47],

[48]. Wieringa caracteriza las respuestas de un sistema reactivo en función de su estado

actual y de los eventos externos a los que responde, en contraposición a lo que llama sis-

temas transformacionales en los que el estado del sistema no depende de entidades externas

[175]. Por otro lado, también Jonsson, como Broy, utiliza el concepto de acción silenciosa,

y lo aplica a transiciones silenciosas (silent transitions) correspondientes a etapas internas

de un autómata para modelar la composición del autómata [91].

2.2.4.2. Sistemas interactivos

Como se ha indicado anteriormente, Broy también entiende los sistemas como interac-

tivos. Plantea que los sistemas interactivos consisten en un conjunto de componentes que

cooperan e intercambian información por medio de interacciones [31] [28]. Ejemplos de

sistemas interactivos, en claro crecimiento, son los sistemas compuestos de componentes y

dispositivos electrónicos en la industria del automóvil y de la aviónica [26] [30] [106]. Los

sistemas software con interfaces definidos, y en especial los servicios software, también

comprenden ejemplos de sistemas interactivos.

Broy y Stolen en [31] dentro del contexto de especificación de sistemas interactivos

definen sistema como una “estructura técnica o sociológica compuesta de un grupo de

entidades combinadas para formar un todo y trabajar, funcionar o moverse interdependien-

temente y armoniosamente; las partes que componen un sistema se llaman componentes o

subsistemas, y pueden ser entendidas como sistemas en sí mismos, así, los sistemas están

estructurados jerárquicamente en subsistemas”.

Además indican que uno de los aspectos más importantes en el modelado de sistemas

31

consiste en representar con exactitud el conjunto de interacciones que se puedan producir

entre un sistema y su entorno, así como las que se puedan producir internamente entre

los elementos que componen el sistema [31]. Estas interacciones requieren de un acuerdo

de cooperación tácito entre los elementos que intervienen en la interacción, incluido el

entorno, y de un intercambio en muchas ocasiones de información entre ellos. Así, para

estos autores, la descripción de un sistema interactivo se realiza en términos de entradas y

salidas, de manera que se abstraen de la estructura interna de los componentes del sistema,

y proporcionan lo que llaman descripciones de interface o caja negra.

Para describir los sistemas interactivos Broy también se basa en las trazas de acciones

de sistemas I/O. La idea que presenta es que los interfaces de los sistemas interactivos

pueden ser descritos caracterizando sus historias o trazas de interacción de mensajes de

entrada y salida. Esta descripción de sistema interactivo mediante trazas es análoga a la

descripción de sistemas reactivos que ha sido descrita en el apartado anterior.

Los componentes de un sistema suelen verse como cajas negras observando exclusiva-