IP Labs PDF

Ingeniería de Protocolos
Prácticas de Laboratorio
Grado en Ingeniería de Tecnologías de la Telecomunicación

Escuela Politécnica Superior de Elche
Confeccionado por:
Salvador Alcaraz
Katja Gilly
Area de Arquitectura y Tecnología de Computadores

Dpto. de Física y Arquitectura de Computadores
9 de mayo de 2019
Índice general
Prácticas Página
1. UML Coee Machine 3

1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Comportamiento de la Coee Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Modelos y diagramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1. Eliminando entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Interface de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Espacio de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6. Proyectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7. Diagramas de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.8. Diagramas de clase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.8.1. Clases activas o pasivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.8.2. Clase informal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.8.3. Descomposición de una clase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.9. Diagrama de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.10. Señales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.10.1. Denición de señales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.10.2. Denición de interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.10.3. Relaciones entre interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.10.4. Puertos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.11. Diagramas de secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.12. Casos de uso y límites de tema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.13. Diagrama de secuencia referenciado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.14. Diagramas de máquinas de estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.14.1. Máquina de estados para la clase Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.14.2. Máquina de estados para clase Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.15. Diagramas de estructura compuestos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.16. Relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.17. Chequeo del modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.17.1. Autocheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.17.2. Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.18. Espacio de trabajo del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.19. Artefactos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.20. Vericación del modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.20.1. Matriz de mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.20.2. Inspección de parámetros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1
2 ÍNDICE GENERAL
1.20.3. Trazado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.20.4. Vericación de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.21. Diagrama de secuencia referenciado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
1.22. Interacciones y adiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
1.22.1. Temporizadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
1.22.2. Datos estructurados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.23. Modicación del modelo Coee Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
1.24. Informe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2. Especicación, vericación y validación de ABP con SDL 47

2.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.2. Especicación del modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.3. Especicación en IBM Telelogic SDL and TTCN Suite . . . . . . . . . . . . . . . . . . . . . . . . 48
2.3.1. Especicación de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.3.2. Especicación de la arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.3.3. Especicación del comportamiento del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.4. Análisis sintáctico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.5. Simulación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.6. Validación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.6.1. Exploración por bit de estado (bit-state ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.6.2. Exploración aleatoria (random walk ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
2.6.3. Recorrido en árbol (tree walk ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
2.6.4. Exploración exhaustiva (exhaustive exploration ) . . . . . . . . . . . . . . . . . . . . . . . . 64
2.6.5. Vericación MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
2.6.6. Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.7. Cuestiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.8. Informe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3. Introducción al lenguaje Promela y Spin 69

3.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.2. Hola Mundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.3. Acceso a sección crítica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.4. Instrucciones atómicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.4.1. Simulación del modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.4.2. Validación del modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.4.3. Corrección del modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.4.4. Validación del modelo con LTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.5. Evaluación de la complejidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.5.1. Vector de estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.5.2. Tamaño del árbol de estados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.6. Informe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4. Especicación y validación de ABP en Promela 95

4.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.2. Especicación del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.3. Especicación de procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.3.1. Lower Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.3.2. Proceso Sender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.3.3. Proceso Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.3.4. Proceso init . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
ÍNDICE GENERAL 3
4.3.5. Modelo ABP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

4.4. Manejo de modelos Promela . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.5. Vericación del modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.5.1. Ciclos no progresivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.5.2. Proclamaciones never . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.6. Validación con LTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.6.1. Denición de LTL en Promela . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
4.6.2. Otras fórmulas proposicionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
4.7. Informe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
4 ÍNDICE GENERAL
Laboratorio 1
UML Coee Machine

CoffeMachine
5
6 LABORATORIO 1. UML COFFEE MACHINE
1.1. Objetivos
1
Implementar un modelo sencillo en UML (Unied Modeling Language ) utilizando la herramienta IBM Ra-
tional Tau , así como su posterior validación mediante simulación.
Duración: 3 sesiones
1.2. Comportamiento de la Coee Machine

Vamos a modelar una máquina de café que proporciona al usuario una taza de café o taza de agua caliente
(para el té), una vez que el cliente ha insertado la cantidad de monedas necesaria. La máquina de café puede
manejar monedas de 5 y 10:
● Un taza de té cuesta 5.
● Una taza de café cuesta 10.
Debe realizar el siguiente comportamiento:
(1) Si inserta una moneda de 10 y presiona botón de café, el cliente recibe una taza de café.
(2) Si inserta una moneda de 10 y presiona botón de té, el cliente recibe una taza de agua caliente además
del cambio restante.
(3) Si inserta una moneda de 5 y presiona botón de café, devuelve el dinero.
(4) Si inserta una moneda de 5 y presiona botón té, el cliente recibe una taza de agua caliente.
Coffee
Tea 5 10
return
1.3. Modelos y diagramas

Un diagrama es una vista de un modelo UML que muestra un conjunto de elementos y sus relaciones. En
esta práctica utilizaremos las prestaciones de la herramienta para analizar directamente el modelo mediante
diagramas. Cada uno de los tipos de diagramas presenta un determinado punto de vista del modelo. Cuando
insertamos una nueva entidad, por ejemplo, una clase, la representamos mediante un diagrama, que será parte
de un modelo. Para representar diferentes vistas, la misma clase puede ser representada contra el mismo o
1 Extraído del documento Telelogic Tau UML Coee Machine Tutorial.

LABORATORIO 1. UML COFFEE MACHINE 7
en diferentes diagramas. La información almacenada en el modelo es la suma de todas las descripciones

realizadas de una entidad.
1.3.1. Eliminando entidades

La diferencia entre modelo y diagramas debemos tenerla presente cuando estamos diseñando en IBM Rational
Tau . Como hemos dicho anteriormente, por ejemplo, una clase, se incluye en el modelo en el momento que
es añadido a un diagrama.½Borrar una clase de un diagrama no necesariamente signica que
haya sido eliminada del modelo!. La razón es porque la misma clase puede haber sido utilizada en otros
diagramas. No obstante, es posible eliminar una entidad del modelo, para ello, clic-derecho y aparecerá un
menú sensible al contexto ↦ Delete from Model, en lugar de Delete.
1.4. Interface de usuario

Las diferentes areas de la interface de usuario en IBM Rational Tau son (Figura 1.1):
1. La ventana del espacio de trabajo (Workspace ).
2. El escritorio (Desktop ).
3. La ventana de salida (Output ).
Figura 1.1: Interface de IBM Rational Tau
En esta práctica algunas veces tendremos otras areas activas, por ejemplo, ventanas de visualización durante
la fase de testeo. Podemos arrastrar una area para modicar su posición dentro de la ventana e incluso
posicionarla fuera de la ventana principial de la interface de usuario.
Espacio de trabajo (Workspace )

Visualiza las entidades contenidas en el modelo. Permite diferentes vistas para visualizar diferentes tipos de
información:
● La vista File muestra todos los elementos que son representados como cheros.
● La vista Model contiene todos los elementos UML. Es la vista seleccionada cuando estamos añadiendo
diagramas o trabajando directamente en el modelo.
● Además hay otra vista, denominada Instances, que sólamente está activa cuando simulamos el sistema
mediante el Vericador de modelos (Model Verier ).
Escritorio (Desktop )
Área donde se abren los diagramas y documentos. Es el espacio donde trabajamos con los modelos y se
visualizan los diferentes diagramas.
Barra de atajos (Shortcut bar )

Es opcional, proporciona la posibilidad de poner alguna barra de tareas que utilicemos frecuentemente en
alguna zona especial, o crear alguna barra especíca para scripts.
Ventana de salida (Output window )

Se utiliza para el registro de eventos y visualización de errores, mensajes y avisos.
Menú de atajos (Shortcut menú )

Se puede acceder desde cualquier entidad a este menú mediante clic-derecho.Normalmente, contiene comandos
sensibles al contexto.
1.5. Espacio de trabajo

El espacio de trabajo es la zona personal de trabajo, donde podemos trabajar sobre diferentes proyectos e
incluir cheros que no sólamente estén relacionados con un determinado proyecto. Es posible denir más de
un área de trabajo, pero sólamente podemos seleccionar uno en cada momento. La información contenida en
el espacio de trabajo se guarda en un chero de texto con extensión *.ttw.
En un mismo espacio de trabajo podremos implementar diferentes modelos UML.
Vamos a crear un espacio de trabajo para el desarrollo del modelo Coee Machine :
A) Iniciar IBM Rational Tau .
B) En el menú File ↦ New.... El diálogo que aparece contiene cuatro pestañas: File, Project, Template y
Workspace ↦ seleccionar la pestaña Workspace.
2
C) Para el nombre del espacio de trabajo, utiliza las siglas de tu nombre y selecciona el lugar donde
almacenar el chero, por ejemplo, PML ↦ OK. El espacio de trabajo aparece en File View del
espacio de trabajo.
D) La siguiente tarea será añadir un proyecto.
A tener en cuenta
En tus de modelos debes de indicar siempre tus iniciales ya que posteriormente, aparecerán en las
grácas generadas y serán utilizadas en la posterior corrección de prácticas. ½½ no lo olvides !!
2 Por ejemplo, Pepito Martínez López, utilizaría PML.

1.6. Proyectos
El uso de proyectos es la forma de agrupar contenidos en una misma área de trabajo. Por ejemplo, el área
de trabajo PML puede contener diferentes ejemplos de modelos, siendo uno de ellos la Coee Machine ,
utilizando un proyecto para cada ejemplo. Los diagramas y documentos se pueden mover entre proyectos.
Un proyecto puede ser compartido entre usuarios. La información contenida en un proyecto se almacena en
un chero de texto con extensión *.ttp.
En primer lugar, vamos a crear un proyecto para el ejemplo Coee Machine :
A) En el menú File ↦ New... ↦ selecciona la pestaña Project.

B) Aparecerá un diálogo con varias opciones para crear diferentes tipos de aplicación ↦ selecciona UML
for Model Verication.
C) Nombra el proyecto CMdesign y selecciona la ubicación donde será guardado ↦ Add to current
workspace ↦ OK.
D) Aparecerá un segundo diálogo con la sugerencia de un nombre para el chero representando el modelo
y la ubicación del chero. Asegúrese que selecciona Project with one le and one package ↦
Siguiente.
E) Aparecerá un tercer diálogo, representando el nombre del proyecto y del chero que representa el modelo
↦ Finalizar. El proyecto recién creado aparecerá en el área de trabajo.
Un signo (+) a la izquierda de un icono en el area de trabajo indica que ese icono está agrupado, y por lo tanto, se puede
visualizar más información. Para expandir la estructura de ese icono, clic en el signo (+). Una estructura entera puede ser
expandida seleccioando el icono agrupado en el área de trabajo y pulsando (∗) en el teclado numérico. Para comprimir una
subestructura pulsar (−) en el icono raíz.
F) Expandir las tres vistas de la pantalla.
G) La vista File muestra los cheros creados (Figura 1.2).
Figura 1.2: Vista File
H) La vista Model muestra un paquete vacío, denominado CMdesign, además podemos encontrar informa-
ción sobre las estructuras internas de la representación de UML en IBM Rational Tau . Esta información
podemos encontrarla en los paquetes denominados Library y Predened (Figura 1.3).
Figura 1.3: Vista Model
1.7. Diagramas de casos de uso

Los diagramas de casos de uso (use case diagrams ) describen las relaciones entre los casos de uso y los actores
de un sistema. En un diagrama de casos de uso es posible agrupar varios casos de uso mediante un marco.
A continuación vamos a crear el diagrama de casos de uso para el ejemplo Coee Machine . Estos casos fueron
descritos anteriormente (ver apartado 1.2):
Model.
A) Asegúrate que el área de trabajo muestra la vista
B) En la vista Model, selecciona el paquete CMdesign ↦ clic-derecho ↦ New Model Element ↦

Collaboration ↦ asigna el nombre UserDrinks.
Para renombrar las entidades del modelo, selecciona la entidad y pulsa F2, o selecciona el elemento y clic una vez sobre el
nombre. Permitirá la edición del nombre de la entidad.
Utilizaremos una colaboración en el modelo para encapsular el diagrama de casos de uso, y posteriormente,
los casos de uso representados como diagramas de secuencia.
C) Selecciona la colaboración anterior ↦ clic-derecho ↦ New Diagram ↦ Use Case Diagram para
insertar un diagrama de caso de uso.
Aparecerá el icono del diagrama de caso de uso en la vista Model. Ahora el diagrama está abierto en
el Escritorio ↦ clic sobre el diagrama para activarlo.
Los símbolos disponibles aparecerán como resaltados en la barra de tareas. A medida que pasamos el
puntero del ratón por encima de cada icono, aparecerá una descripción emergente indicando el nombre
del símbolo.
D) Para insertar un símbolo en el diagrama clic sobre el botón correspondiente del símbolo, y posterior-
mente, clic en el diagrama del Escritorio.
Pulsar para insertar un actor en el diagrama ↦ asigna al actor la clase Customer (para ello, el
nombre de la clase debe de ir precedida de : ).
Es posible asignar un nombre al actor, pero no es necesario.

collaboration UserDrinks Use case diagram1 {1/1}
MakeCoffee
:Customer
Figura 1.4: Caso de uso y actor.
En esta fase del diseño, la clase Customer todavía no está denida, y lo podemos observar de dos
formas:
● El nombre del tipo está subrayado con una línea sinusoidal roja (Figura 1.4) indicando un error
de enlace de nombre.
● Habrá algún error en la ventana Output (pestaña Autocheck ).
E) Clic en el símbolo de caso de uso ↦ colócalo en el diagrama ↦ renombra el caso de uso con
MakeCoee ↦ selecciona el caso de uso y crea una línea de asociación con el actor, arrastra el
manejador de línea más a la izquierda ( Association line) desde el símbolo de caso de uso hasta el
actor (Figura 1.4).
F) Graba el proyecto.
Ya hemos completado un diagrama de caso de uso que contiene uno de los posibles casos de uso del sistema.
Más tarde añadiremos más casos de uso al diagrama cuando trabajemos con diagramas de secuencia.
1.8. Diagramas de clase
Los diagramas de clase describen los tipos de los objetos que forman parte del sistema y la relación entre
ellos. También muestran los atributos y operadores de las clases. A continuación, utilizamos los diagramas
de clase para modelar el ejemplo de Coee Machine .
A) Asegúrate que en la ventana del espacio de trabajo se visualiza la vista Model.

B) Selecciona el paquete CMdesign en la vista Model ↦ clic-derecho ↦ New Diagram ↦ Class Dia-
gram.
C) Habrá aparecido en la vista Model un icono para el diagrama de clase creado. El diagrama está abierto
en el Escritorio. Renombra el diagrama con DomainModel .
D) Utiliza el botón del símbolo clase y añade dos clases ↦ renombra (pulsando F2 sobre el icono
de la clase) las clases CoeMachine y Customer , que representan la máquina de café y un posible
cliente (Figura 1.5).
Cuando creemos la clase Customer se resolverán los errores del tipo actor en el autocheck.
package CMdesign DomainModel {1/3}
CoffeeMachine Customer
Figura 1.5: Las clases CoeMachine y Customer.
1.8.1. Clases activas o pasivas

Una clase puede ser:
● Activa: contiene comportamiento.

● Pasiva: sólo contiene deniciones.
Un ejemplo de clase pasiva es un tipo de datos. Nuestra clase CoeeMachine contendrá comportamiento, por
lo tanto, debe ser, activa:
A) Clic-derecho en el símbolo de la clase CoeeMachine.
B) En el menú contextual que aparece ↦ clic en Properties ↦ se abre el diálogo de propiedades para la
clase CoeeMachine ↦ en Filter selecciona Class.
C) Selecciona Active en el check box. Puedes dejar el diálogo abierto.
El diálogo de propiedades se puede abrir mediante ALT+Enter.
Una clase active se muestra mediante el diagrama con líneas de borde verticales dobles (Figura 1.6).
CoffeeMachine <<informal>>
Customer
Figura 1.6: Clases activas y externas (informal ).

1.8.2. Clase informal

La clase Customer es una entidad que no es parte del diseño de la máquina de café en sí mismo, por lo que
hay que indicarlo con el estereotipo informal. Mediante la aplicación del estereotipo informal no se genera
código para esta clase en la fase de simulación del modelo:
A) Clic-derecho en la clase Customer Stereotypes....

↦
B) Selecciona el check box TTDPredenedStereotypes:informal (Figura 1.7). El estereotipo se activa
en el momento de cerrar el diálogo.
C) También lo denimos activo, por lo tanto, clic-derecho en el símbolo de clase Customer ↦ Active.
Figura 1.7: Declaración de Estereotipo Informal ).
En UML, se conoce como estereotipo a un elemento de texto que al ser aplicado a otro elemento dene su categoría. Es
uno de los mecanismos de extensión del lenguaje toda vez que permite cambiar o complementar la semántica de cualquier
elemento.
1.8.3. Descomposición de una clase

Ahora vamos a renar el modelo añadiendo dos nuevas clases que representan el controlador y el hardware
de la Coee Machine . Controller contendrá la lógica para el sistema mientras que Hardware simulará el
comportamiento del hardware.
Para añadir estas clases, podemos seguir diferentes métodos. Añadiremos la clase directamente al modelo y,
posteriormente, modelaremos las características en el editor:
CMdesign ↦ clic-derecho en
A) En la vista modelo de la ventana espacio de trabajo, localiza el paquete
el paquete CMdesign ↦ New Model Element ↦ Class ↦ un icono de clase aparecerá en la vista
Model.
B) Renombra la clase a Controller .
CMdesign.
C) En la vista modelo, vuelve a seleccionar el paquete
D) Clic-derecho en el paquete CMdesign ↦ New Model Element ↦ Class ↦ un icono de clase aparecerá
en la vista Model.
E) Renombra la clase a Hardware .
1.9. Diagrama de componentes

Los diagramas de componentes están directamente relacionados y se pueden considerar un subtipo de los
diagramas de clase. Los diagramas de componentes describen los componentes identicables (y posiblemente
reemplazables) de un sistema. Igual que el diagrama de clase, el diagrama de componentes puede mostrar
puertos e interfaces de las clases. Vamos a utilizar un diagrama de componentes para avanzar en el modelado
de la Coee Machine :
A) Asegúrate que la ventana del espacio de trabajo está la vista Model.

Controller ↦ selecciona la pestaña New Symbol ↦ clic en la la
B) Doble clic en el icono de la clase
New Component Diagram ↦ OK (Figura 1.8).
Figura 1.8: Añadir diagrama de componentes.
C) Habrá aparecido el icono del diagrama en la vista Model y el diagrama estará abierto en el Escritorio
↦ renombra el nuevo diagrama ControlComponents .
Hardware desde la vista Model hasta el diagrama de componentes abierto

D) Arrastra el icono de la clase
(ControlComponents) en el Escritorio.
E) Declara Controller y Hardware activos.
F) Asegúrate que el diagrama de componentes es igual a la Figura 1.9.
G) Graba el trabajo.
package CMdesign Component diagram1 {2/2}
Controller Hardware
Figura 1.9: Componentes de CoeeMachine.

1.10. Señales
UML dispone de un símbolo de clase especíco para denición de señales. Este símbolo es uno de los estereo-
tipos denidos e indicado mediante signal en la cabecera. Todas las señales utilizadas en el modelo UML
deben ser denidas. Una señal denida en un cierto nivel, puede ser visualizada y utilizada por el resto de
entidades en niveles inferiores.
1.10.1. Denición de señales

Necesitamos denir todas las señales necesarias en la implementación del comportamiento de la Coee Ma-
chine . Utilizaremos un diagrama de clase para la denición de señales.
CMdesign en la vista Model ↦ añade un diagrama de clase mediante clic-derecho

A) Seleciona el paquete
↦ New Diagram ↦ Class Diagram ↦ el diagrama aparecerá en la vista Model del espacio de trabajo.
B) Renombra el diagrama a Signals . El diagrama está ahora abierto en el Escritorio.
C) A partir de la barra de tareas ↦ selecciona el símbolo señal e inserta en el diagrama.
D) Repite el proceso hasta denir todas las señales, según la siguiente tabla (un símbolo para cada señal),
que representan el total de señales utilizadas en el modelo, y que serán utilizadas posteriormente:
Hacia Customer Desde Customer Hacia Hardware Desde Hardware

CupOfCoee Coee FillWater WaterOK
CupOfWater Tea FillCoee CoeeOK
ReturnChange Coin(Integer) HeatWater Warm
E) La señal Coin transportará una señal dato del tipo entero. Esta señal contendrá el valor de la(s)
moneda(s) insertadas ↦ añade el tipo Integer en el compartimento intermedio del símbolo de la señal
Coin.
F) La denición de todas las clases de señal del sistema vienen reejadas en la Figura 1.10.
G) Graba el trabajo.
package CMdesign Signals {3/3}
<<signal>> <<signal>> <<signal>> <<signal>>

CupOfCoffee Coffee FillWater WaterOK

CupOfWater Tea FillCoffee CoffeeOK

ReturnChange Coin HeatWater Warm
Integer
Figura 1.10: Denición de señales.
El coloreado de una entidad, por ejemplo, de un nombre de una señal o tipo, indica que Tau ha encontrado la denición. Se
denomina resolución de nombres y aparece en todos los niveles cuando estamos diseñando en IBM Rational Tau. Integer
es uno de los tipos predenidos en UML. Si no encuentra la denición mostrará el nombre subrayado en rojo.
1.10.2. Denición de interfaces

Ahora vamos a denir las interfaces que denen la interacción con el entorno.
A) Abre el diagrama de clases Signals.

B) A partir de la barra de herramientas, mediante el símbolo de interface dene las siguientes
interfaces:
● FromUser
● ToUser
C) Vamos a colocar las señales en sus interfaces correspondientes,
● Coin, Coee y Tea deben ir a la interface FromUser.

● ReturnChange, CupOfCoee y CupOfWater deben ir a la interface ToUser.
D) Para ello, a partir de la vista Model, arrastra los iconos de señal hasta los iconos de interfaces, como se
detalla a continuación:
● Arrastra los iconos de las señalesCoin, Coee y Tea hasta la parte inferior de interface FromUser.
● Arrastra los iconos de las señales ReturnChange, CupOfCoee y CupOfWater hasta la parte
inferior de interface ToUser.
E) Una vez realizada la asignación, el diagrama de clases Signal quedará como en la Figura 1.11.
F) Graba el trabajo.
package CMdesign Signals {3/3}

ToUser::CupOfCoffee() FromUser::Coffee() FillWater WaterOK

ToUser::CupOfWater() FromUser::Tea() FillCoffee CoffeeOK

ToUser::ReturnChange() FromUser::Coin(Predefined::Integer) HeatWater Warm
Integer
<<interface>> <<interface>>
FromUser ToUser
signal Coin ( Integer) signal CupOfCoffee ()

signal Tea () signal CupOfWater ()
signal Coffee () signal ReturnChange ()
Figura 1.11: Denición de interfaces y asignación de señales a interfaces.
1.10.3. Relaciones entre interfaces

Ahora las interfaces están preparadas para ser utilizadas. Vamos a crear una relación de asociación entre
dos interfaces y una dependencia de ToUser a Customer.
A) Selecciona el símbolo de interface ToUser ↦ arrastra la línea de Association desde ToUser hasta
FromUser. Esta relación implica que cada vez que una interface sea utilizada, la otra debe estar
disponible.
B) Elimina la navegabilidad de la asociación ↦ clic-derecho en la linea junto a la conexión a la interface

↦ Target ↦ en el sub-menu elimina Navigable (Figura 1.12).
C) Idem con la otra interface ↦ clic-derecho en la línea cerca de la conexión a la otra interface ↦ Source
↦ elimina Navigable (ya debería de estar des-seleccionado).
Figura 1.12: Opción de navegabilidad en target.
D) Arrastra la interface ToUser desde la vista Model al diagrama de clases DomainModel.
E) Selecciona el símbolo de clase Customer ↦ arrastra el manejador de la línea Dependency hasta el

símbolo de interface ToUser. La clase Customer no va a ser implementada, por lo que esta operación
no tendrá ningún impacto sobre el código generado.
CoffeMachine <<informal>>
Customer
<<interface>>
ToUser
Figura 1.13: Relación de dependencia entre clase Customer y interface ToUser.
La navegabilidad indica en qué orden uyen los datos en el diagrama se indica por medio de una echa que se pone al nal
de una linea de asociación apuntando hacia la clase que recibe los datos en la gura representa la navegabilidad que existe
entre la clase pedido y la de cliente, ésta representa una asociación unidireccional también hay otra que es la bidireccional,
indicando que existe navegabilidad en ambas direcciones.
1.10.4. Puertos
Las señales viajan entre instancias de clases a través de puertos. Puertos separados pueden ser utilizados por
cada entidad con la que quiere comunicar. Vamos añadir los puertos a las clases para habilitar la comunicación,
empezando por la comunicación externa.
A) En el diagrama de clases DomainModel ↦ selecciona la clase CoeeMachine ↦ presiona SHIFT ↦ en
la barra de tareas selecciona el símbolo Port ↦ aparecerá un puerto en el borde. Este puerto
representa la comunicación desde y hacia la clase P1. ↦ renombra el puerto a
B) Asegura que el puerto P1 está seleccionado ↦ añade un realized interface a P1 mediante el símbolo
↦ nombra el interface como FromUser .
C) Con P1 seleccionado, presiona ALT+Enter para abrir el diálogo de propiedades ↦ debe estar seleccionado
Port en el campo Filter ↦ FromUser) está en el campo
comprueba que el nombre del interface (
Realizes ↦ añade el nombre de interface ToUser en el campo Requires.
D) Vuelve al diagrama DomainModel ↦ selecciona el puerto P1 ↦ clic en el botón de Required interface
de la barra de tareas ↦ comprobar que el nombre es automáticamente insertado en el símbolo de

interface.
No es necesario añadir el interface required debido a la relación de asociación entre interfaces. Sólo lo hacemos por motivos
de expresividad.
E) Arrastra el icono de la clase Controller de la vista Model al diagrama de clases abierto DomainModel
en el Escritorio.
F) Selecciona la clase Controller ↦ añade el puerto P2 ↦ añade interfaces required y realized a P2 en el

mismo sentido que P1.
Observa que debe existir una correspondencia entre las señales asignadas a los puertos required y realized.
G) El diagrama de clases del modelo debería contener los interfaces y puertos (Figura 1.14).
H) Guarda el trabajo
<<informal>>
P2 P1 Customer
ToUser FromUser
Controller CoffeeMachine
FromUser ToUser
<<interface>>
ToUser
Hardware
Figura 1.14: Interfaces y puertos.

1.11. Diagramas de secuencia

Un diagrama de secuencias describe el comportamiento de los casos de uso. Normalmente, un diagrama de
secuencia se construye con instancias de clases activas del sistema y mensajes (instancias de señales) entre
ellas. Un diagrama de secuencias se puede añadir de forma manual u obtener durante la simulación en la
vericación de modelos (lo veremos más adelante). Vamos a incorporar un diagrama de secuencia para el
caso de uso MakeCoee. Asegúrate que en el área de trabajo se visualiza la vista Model.
UserDrinks en la vista Model

A) Localiza la colaboración ↦ clic-derecho en el caso de uso MakeCoee
↦ New Diagram ↦ Sequence Diagram.
Ahora el tipo actor está ligado a la claseCustomer . En el diagrama de caso de uso, podemos comprobar que el
nombre de la clase ya no está subrayado en rojo, ahora está coloreado en verde. Es un ejemplo del trabajo que hace
IBM Rational Tau en modo background analizando, detectando cambios en el modelo y actualizando la presentación
de los diferentes elementos y entidades con el n de mantener siempre consistente el modelo.
B) Ahora el diagrama está abierto y ha aparecido un icono de diagrama de secuencia en la colaboración

en la vista Model. El diagrama de secuencia está contenido en una Interaction que puede contener
uno o más diagramas que describen el caso de uso.
C) Localiza la clase Customer en la vista Model y arrastra hasta el diagrama de secuencia ↦ la clase
aparecerá como una línea de vida (lifeline ).
D) Repite la operación anterior con Controller.

E) Repite la operación anterior con Hardware.
F) En los siguientes pasos, vamos a utilizar tres formas diferentes de creación de mensajes en los diagramas
de secuencia. Para cada uno de ellas, presta especial atención a la vinculación de los nombres de señales
en el modelo. El botón de Message line en la barra de tareas es el punto de inicio común para
las tres formas:
(1) Dibuja un mensaje de Customer a Controller ↦ arrastra la señal Coin hasta la linea de mensaje ↦
el nombre de la señal aparecerá con la lista de parámetros conteniendo los tipos de los parámetros,
en este caso, un parámetro integer ↦ sustituye el parámetro información de tipo ( integer) por el
valor entero 10.
(2) Selecciona Message Line en la barra de herramientas ↦ clic en Customer y entonces, clic-
derecho donde queremos posicionar el evento de recepción en Controller ↦ selecciona Reference
existing ↦ Coee.
Reference existing se puede utilizar en clases con puertos e interfaces que denen un conjunto de señales
realized.
(3) Inserta un mensaje de Controller a Hardware ↦ escribe el nombre de la señal FillWater dentro
de la línea de mensaje.
CTRL+Space es un atajo para completar nombres. Si empezamos a escribir un nombre, puede ser completado (si sólo hay una
opción) o mostrará una lista de opciones con las entidades permitidas en ese nivel.
G) Continúa añadiendo las secuencias representadas en la Figura 1.15.
H) Graba el trabajo.
interaction MakeCoffee Sequence diagram1 {1/1}
<<informal>>
: Controller : Hardware
: Customer
FromUser::Coin(10)
FromUser::Coffee()
FillWater()
WaterOK()
FillCoffee()
CoffeeOK()
HeatWater()
Warm()
ToUser::CupOfCoffee()
Figura 1.15: Diagrama de secuencia para el caso de uso MakeCoee.
1.12. Casos de uso y límites de tema
A) Abre el diagrama de casos de uso en la colaboración UserDrinks ↦ crea un nuevo caso de uso ↦
renombra a MakeTea .
B) Crea un nuevo caso de uso ↦ renombra a TeaMaking .
C) Dibuja una línea de dependencia de MakeTea a TeaMaking ↦ crea una línea de asociación entre el
actor y MakeTea.
MakeTea debería ser uno de los casos de uso principales para describir un escenario completo del sistema
que modele hacer una taza de café caliente. El caso de uso TeaMaking es un sub-escenario que describe el
llenado de la taza y calentado de agua.
D) Crea un tema (subject ) alrededor de los casos de uso mediante el símbolo subject . Después de
seleccionar el símbolo en la barra de herramientas, arrastra y encierra los símbolos de caso de uso con
el símbolo de tema ↦ nombre e identica el marco para pertenecer a la clase CoeeMachine (Figura
1.16).
E) Graba el trabajo.
collaboration UserDrinks Use case diagram1 {1/1}
CoffeeMachine
MakeCoffee <<informal>>
:Customer
MakeTea
<<include>>
TeaMaking
Figura 1.16: Casos de uso en un sub-escenario.

El sub-escenario (o marco de tema) es opcional, pero encapsula los casos de uso para pertenecer a una
determinada clase en el modelo, permitiendo construir diagramas de casos de uso complejos con actores
comunes a uno o más sistemas.
1.13. Diagrama de secuencia referenciado

UserDrinks en la vista Model ↦ clic-derecho en el caso de uso MakeTea ↦
A) Localiza la colaboración
New Diagram ↦ Sequence Diagram ↦ el diagrama ahora estará abierto y un icono de diagrama
de secuencia habrá aparecido dentro de la colaboración en la vista Model.
B) Localiza la clase Customer en la vista Model ↦ arrástrala hasta el diagrama de secuencia ↦ la clase
aparece como una línea de vida ↦ arrastra la clase CoeeMachine hasta el diagrama de secuencia.
C) Añade un mensaje desde Customer hasta CoeeMachine ↦ escribe el nombre de la señal Coin con
parámetro 5 en el mensaje ↦ añade un nuevo mensaje de Customer a CoeeMachine ↦ escribe el
nombre de la señal Tea en el mensaje.
D) Coloca un símbolo de reference debajo de las señales ↦ renombra el símbolo de referencia

TeaMaking (Figura 1.17).
E) Guarda el trabajo.
interaction MakeTea Sequence diagram1 {1/1}
<<informal>>
: CoffeeMachine
: Customer
Coin(5)
Tea()
ref TeaMaking
Figura 1.17: Diagrama de secuencia referenciado.
Podemos utilizar un símbolo de referencia como un bloque para crear diagramas de secuencia más grandes y
complejos a partir de un conjunto de secuencias comunes simples.
1.14. Diagramas de máquinas de estado

Un diagrama de máquina de estados describe el comportamiento de una clase activa. Una máquina de estados
tiene uno o más posibles estados y un cambio de estado se desencadena por la recepción de una señal. En
UML, el concepto de máquina de estado ha sido extendido mediante manejo de datos, signicado de señales
de datos y la declaración de otras variables que pueden ser declaradas y manejadas. Soporta las siguientes
notaciones:
● Sintaxis orientada a transición.

● Sintaxis orientada a estado.
Ambas sintaxis pueden utilizarse para la descripción del comportamiento de una máquina de estado, pero la
sintaxis orientada a estado es más apropiada para obtener ua visión general en diseños grandes, mientras
que, lasintaxis orientada a transición es más apropiada para el diseño de detalles.
1.14.1. Máquina de estados para la clase Hardware

Sintaxis orientada a estado
Cuando utilizamos la sintaxis orientada a estado debemos de contemplar los siguientes aspectos:
● Cuando conectamos estados ↦ selecciona el primer estado ↦ aparecen dos tiradores ↦ coge el tirador
representado por un círculo relleno ↦ arrastra la línea hasta el segundo estado ↦ clic en el símbolo.
● Para cambiar la forma de la línea de conexión ↦ clic en la línea ↦ aparece un tirador cuadrado ↦
arrastra el tirador hasta conseguir la forma deseada.
● Para dibujar una línea de vuelta hacia el mismo estado ↦ a patir del tirador circular ↦ arrastra la línea
fuera del estado ↦ clic para cambiar de dirección ↦ arrastra la línea de vuelta al estado ↦ clic en el
símbolo.
● La notación utilizada en las líneas de transición es:
<entrada>/<sentencia de transición>;
donde <input>/<sentencia de transicion> puede ser, por ejemplo: ^<nombre de señal>.
Las señales sin parámetros deben de ir seguidas de un conjunto vacío entre paréntesis. Pueden haber
varias sentencias en una transición, separadas por comas.
Estados compuestos
En una máquina de estados UML se pueden denir estados compuestos (composite ). Es la forma de
denir un sub-estado con una máquina de estados propia.
Un estado compuesto se puede utilizar, por ejemplo, cuando un conjunto de acciones tienden a alcanzar de
vuelta a un determinado estado. En el ejemplo Coee Machine , se puede identicar con el estado Hardware.
Cuando se produce té o café, el intercambio de señales entre Controller y Hardware es muy similar pero hay
un intercambio de señal adicional cuando el usuario pide una taza de café. Este intercambio de señales se
puede poner en un estado compuesto.
Para empezar con la sintaxis orientada a estado, vamos a describir el comportamiento de la clase Hardware
en la máquina de estados:
A) Para añadir una máquina de estados a la clase Hardware ↦ clic-derecho en el icono Hardware de la
vista Model↦ New Diagram ↦ State Machine Diagram ↦ renombre la nueva máquina de estados
HandlingWater ↦ la máquina de estados está contenida en una state machine implementation,
que por defecto se llama initialize.
B) Implementa el comportamiento mostrado en la Figura 1.18.
C) Graba el trabajo.
Sintaxis orientada a transición

Cuando utilizamos la sintaxis orientada a transición debemos de contemplar los siguientes aspectos:
statemachine Hardware :: initialize HandlingWater {1/1}
HeatWater()/^Warm();
Idle
FillWater()/^WaterOK();
Water
Figura 1.18: Diagrama de máquina de estados HandlingWater.
● Para añadir un símbolo, clic en el correspondiente botón de la barra de herramientas, y luego, clic en
el Escritorio.
● Para conectar dos símbolos, selecciona el primer símbolo ↦ aparecen dos tiradores ↦ coge el tirador
representado por un cuadrado ↦ arrastra la línea hasta el segundo símbolo ↦ clic en el símbolo.
● Autoow : selecciona un símbolo y presiona SHIFT ↦ clic en un símbolo de la barra de herramientas. El

símbolo nuevo se conecta, automáticamente, al símbolo seleccionado.
Ahora podemos utilizar la sintaxis orientada a transición para describir el comportamiento en un estado
compuesto.
A) Abre la máquina de estados HandlingWater en la clase Hardware.

B) Doble clic en el estado Water ↦ se abre el Model Navigator ↦ en la pestaña New Diagram ↦ State
Machine Diagram ↦ un diagrama nuevo se abre en el escritorio.
C) Añade la denición del sub-estado mostrado en la Figura 1.19. El estado History implica retorno al
estado WaitFill.
D) Graba el trabajo.
state Water State machine diagram1 {1/1}
WaitFill
FillCoffee()
CoffeeOK()
Figura 1.19: Estado compuesto.
1.14.2. Máquina de estados para clase Controller

Vamos a describir el comportamiento de la clase Controller en una máquina de estados, utilizando la sintaxis
orientada a transición:
A) En la vista Model de la ventana del área de trabajo ↦ selecciona el icono representando la clase
Controller ↦ crea un nuevo diagrama de máquina de estados para Controller.
B) Renombra el diagrama a NewOrder para indicar que es un diagrama que describirá el comportamiento
cuando se recibe un pedido nuevo de café o té.
C) Implementa el comportamiento descrito (Figura 1.20).
Para insertar los símbolos Decision Answer , es necesario que esté seleccionado el símbolo Decision .
statemachine Controller :: initialize NewOrder {1/2}
Idle
Coin(Value)
NbrOfCoffee=0; Integer NbrOfCoffee;
NbrOfTea=0; Integer NbrOfTea;
Value
Integer Value;
Idle
5 10 else
PaidFive PaidTen
PaidFive PaidTen Idle
Tea() Tea() Coffee()

Coffee()
FillWater() ReturnChange() ReturnChange() FillWater()
MakingTea Idle FillWater() MakingCoffee
MakingTea
Figura 1.20: Diagrama de máquina de estados NewOrder.
La máquina de estados describe la recepción de una moneda, la recepción de una orden de café o té y el inicio
de la comunicación con hardware. Se utilizan dos variables para contar el número de tazas de café o té que
han sido servidas. Otra variable es necesaria para almacenar el valor de la moneda.
D) Para obtener más espacio, podemos añadir una nuevo diagrama de máquina de estado para el resto
del comportamiento de la clase Controller ↦ en la vista Model, selecciona el icono StateMachineIm-
plementation of initialize() y crea otra máquina de estados para Controller ↦ clic-derecho ↦ New
Diagram ↦ State Machine Diagram.
E) Renombra la nueva máquina MakingBeverage .
F) Implementa el resto del comportamiento (Figura 1.21).
G) Los diagramas de máquinas de estados están ahora completos.
H) Guarda el proyecto.
statemachine Controller :: initialize MakingBeverage {2/2}
MakingCoffee MakingTea WaterForCoffee WaterForTea
WaterOK() WaterOK() CoffeeOK()

Warm()
FillCoffee() HeatWater() HeatWater()

CupOfWater()
WaterForCoffee WaterForTea
CoffeeAndWater NbrOfTea=NbrOfTea+1;
CoffeeAndWater
Idle
Warm()
CupOfCoffee()
NbrOfCoffee=NbrOfCoffee+1;
Idle
Figura 1.21: Diagrama de máquina de estados MakingBeverage.
1.15. Diagramas de estructura compuestos

El siguiente paso es añadir un diagrama de estructura compuesto. Un diagrama de estructura compuesto
muestra instancias de una clases activas y la comunicación entre ellas. Es un diagrama utilizado para mostrar
cómo deberían ser instanciados y construidos conjuntamente para conformar el sistema. Las instancias se
denominan partes u objetos. Una parte comunica con otras partes o con el entorno a través de ports. Los
interfaces o connectors.
puertos se conectan a través de
Ahora vamos a instanciar las clases y describir la comunicación entre Customer, Controller y Hardware
mediante un diagrama de estructura compuesto (composite ).
A) En la vista Model ↦ selecciona el icono de la clase CoeeMachine.
B) Clic-derecho en la clase CoeeMachine ↦ New Diagram ↦ Composite structure diagram.

C) El diagrama de estructura compuesto aparecerá en la vista Model ↦ renombra el diagrama Commu-
nication .
Partes
Una Parte ( part) es una instancia de una clase activa.
A) Asegúrate que el diagrama Communication está abierto en el Escritorio ↦ a partir de la barra de
herramientas, selecciona el símbolo part ↦ colócalo en el diagrama.
B) Clic dentro del área para activar el área de texto ↦ renombra la instancia Ctrl:Controller , donde Ctrl
es el nombre de la instancia y Controller es el nombre de la clase que ha sido instanciada.
C) Añade una instancia de la clase Hardware ↦ renombra la instancia Hw:Hardware.

Puertos
Ahora vamos añadir algunos puertos ( ports) adicionales al modelo para habilitar la comunicación, empezando
por el puerto representante de Customer :
A) Selecciona la instancia Ctrl ↦ presiona SHIFT ↦ en la barra de herramientas, selecciona el símbolo
Port ↦ un puerto aparecerá en el borde ↦ renombra el puerto P3 ↦ este puerto representa la

comunicación con la instancia Hw.
B) Selecciona la instancia Hw ↦ añade un puerto y renómbralo con P4 ↦ este puerto representa la

comunicación con la instancia Ctrl.
C) Añade las señales required y realized en los puertos P3 y P4 ↦ observar que las señales en los puertos
deben de corresponder con la dirección en la línea de conexión.
● Las señales que pueden ser recibidas por Ctrl son:
CoeeOK
WaterOK
Warm
● Las señales que pueden ser recibidas por Hw son:
HeatWater
FillWater
FillCoee
Conectores
Un conector ( Connector) es una ruta de señal que puede ser bidireccional o unidireccional. Los conectores
conectan puertos en un diagrama de estructura compuesto:
A) Añade un conector entre los puertos P3 y P4, para ello, selecciona un puerto y arrastra el tirador hacia
el otro ↦ aparecen tres campos de texto ↦ renombra el conector CtrlBiHw .
B) Clic-derecho en la línea de conector y selecciona Show all signals ↦ para cada uno de los conec-
tores rellenamos las señales correspondientes a las propiedades Realizes y Requires ↦ el diagrama de
estructura debería se ahora como en la Figura 1.22.
C) El diagrama de estructura compuesto está ahora completo. Los puertos y partes han sido añadidos al
modelo.
active class CoffeeMachine Communication {1/1}
Ctrl:Controller
CoffeeOK,WaterOK, Warm
P3 CtrlBiHw
P4
FillCoffee,FillWater,HeatWater
Hw:Hardware
Figura 1.22: Diagrama de estructura compuesto.

Puertos e interfaces
Ahora vamos añadir los puertos a las clases en el diagrama de componentes.
A) Abre el diagrama de componentes ControlComponents.
B) Arrastra y suelta el puerto P3 en Controller.
C) Arrastra y suelta el puerto P4 en Hardware.
D) La lista de interfaces y señales la podemos observar en la Figura 1.23.
package CMdesign ControlComponents {2/3}
FillCoffee,FillWater,HeatWater FillCoffee,FillWater,HeatWater
Controller Hardware
P3 P4
CoffeeOK,WaterOK,Warm CoffeeOK, WaterOK, Warm
Figura 1.23: Diagrama de estructura compuesto con puertos e interfaces.
1.16. Relaciones
El siguiente paso es añadir relaciones entre clases. Las relaciones entre clases en un modelo se ilustran mejor
en un diagrama de clases.
Asociación
Una asociación representa una relación entre objetos. Cada asociación tiene dos roles, representados por las
direcciones de la asociación. Antes hemos creado una asociación entre las interfaces ToUser y FromUser en
el modelo.
Composición
Controller y Hardware viven y mueren con la clase CoeeMachine, lo que indica que su relación con la
clase CoeeMachine es una composición.
A) En el diagrama DomainModel, selecciona la clase CoeeMachine ↦ aparecen tres tiradores debajo del
símbolo.
B) Con el tirador cuadrado (Association/Aggregation/Composition line ), arrastra la línea hasta la clase

Controller ↦ y antes de asociar la relación con la clase destino ↦ clic-derecho en el símbolo de la clase
↦ Reference Existing ↦ la caja desplegable contendrá la parte Ctrl (Figura 1.24).
selecciona
C) Añade una composición de la misma forma entre las clases CoeeMachine y Hardware.
E) El diagrama de clases debería aparecer ahora como en la Figura 1.25.
Podemos visualizar/ocultar los diferentes atributos (2º compartimento) y métodos (3er. compartimento) de las clases
seleccioando la clase ↦ clic-derecho.
Figura 1.24: Conguración de una relación con una referencia existente.

CoffeeMachine
part Ctrl : Controller <<informal>>
part Hw : Hardware Customer
P1
FromUser ToUser
<<interface>>
ToUser FromUser ToUser
P2 Ctrl Hw signal CupOfCoffee ()

Controller Hardware signal CupOfWater ()
signal ReturnChange ()
initialize ()
initialize ()
timer Heater ()
Figura 1.25: Composiciones en DomainModel.
1.17. Chequeo del modelo
IBM Rational Tau dispone de una funcionalidad de chequeo incorporada, cuyo propósito es encontrar los
errores tan pronto como sea posible. Hay dos tipos de chequeo: Autocheck y Check.
1.17.1. Autocheck
El Autocheck está constantemente en ejecución, chequeando el ámbito de trabajo en el que estamos actual-
mente trabajando y modicando. El ámbito viene determinado por el diagrama abierto en el Escritorio.
Todos los errores encontrados se muestran en la ventana Output. Como el chequeo está contantemente en
ejecución, un mensaje de error desaparece tan pronto como el error es corregido.
1.17.2. Check
Check All o Check Selection. Con
Iniciamos el chequeo mediante alguno de los botones de chequeo,
Check All chequeamos el modelo entero, mientras que con Check Selection sólo chequeamos la entidad
seleccionada en la vista Model y sus entidades a asociadas. Todos los errores encontrados se muestran en la
ventana Output. Los errores permanecen en la lista hasta que se inicie un nuevo chequeo.
A) Clic en Check All .
B) Si un mensaje de error aparece en la venta Output, trata de entenderlo y corregirlo.
● En algunos tipos de error, mediante doble clic, el problema que causa el error se muestra en el
Escritorio.
● Otra forma de hacerlo es clic-derecho en el mensaje de error ↦ Locate.
1.18. Espacio de trabajo del proyecto

En esta sección aparecen detallados los elementos más importantes del proyecto denido hasta este punto.
Nos ayudará a detectar posibles errores o disfunciones en nuestro proyecto.
Figura 1.26: Relación de componentes del proyecto.

1.19. Artefactos
Un artefacto (artifact ) es una representación de nuestro modelo como un subconjunto del mismo. Un
artefacto es un elemento en el modelo UML, con propiedades dedicadas a la construcción de procesos.
Cuando trabajamos con artefactos, se utilizan una serie de cheros que representan código fuente del kernel
para traducir el modelo UML a un programa ejecutable. Existen diferentes kernels para aplicaciones y debug.
Para obtener el artefacto se requiere una conguración apropiada de los complementos para la generación
de código del Model Verier. Principalmente se controla cuando creamos el chero de proyecto, aunque
↦ Customize. Abriendo este diálogo, en la pestaña Add-
podemos cambiarlo desde la opción Tools del menu
ins debemos comprobar que el módulo Model Verier está activo. Vamos a crear un artefacto representando
el modelo. El artefacto será ejecutado posteriormente.
A) Clic-derecho en el paquete CMdesign ↦ Model Verier ↦ New Artifact ↦ en la vista Model

aparecerá un icono para el artefacto creado ↦ renombra el artefacto artifact_cm .
B) Establece la raíz para el artefacto. Esta operación establece qué parte del modelo queremos que sea
representado en el artefacto que vamos a generar. El artefacto generado representará la entidad que
establezcamos como raiz y siguientes sub-arboles ↦ clic-derecho en artifact_cm en la vista Model ↦
Select Build Root... ↦ establece la raíz en la clase CoeeMachine ↦ OK.
C) Clic-derecho en el icono del artefacto en la vista Model ↦ Build (Model Verier) ↦ Launch.
Para construir con el Model Verier , debemos tener un compilador C instalado. En nuestro caso, utilizamos Microsoft
Studio, por lo que debemos ajustar las propiedades del artefacto ↦ clic-derecho en artifact_cm ↦ Properties ↦ en el
menú Filter selecciona el estereotipo ModelVerier ↦ establece Target Kind a Win32 (½½ cuidado sin gcc)!!.
D) El resultado de la construcción se muestra en la ventana Output. Cuando se obtiene la construcción,

se visualizan un conjunto de mensajes de estado, nalizando con un contador de mensajes de error y
avisos.
1.20. Vericación del modelo

La vericación del modelo nos proporciona un test del comportamiento del diseño. Las respuestas a las
señales recibidas pueden ser evaluadas. IBM Rational Tau proporciona tres tipos diferentes de traza: traza
textual textual, traza gráca UML y traza de diagrama de secuencia. Vamos a realizar una vericación del
comportamiento de la Coee Machine que hemos diseñado:
A) Clic-derecho en el artefacto, que hemos denominado, artifact_cm. En la vista Model ↦ Build (Model
Verier) ↦ Launch.
B) Visualizamos el área de trabajo con la opción de menú View ↦ Workspace ↦ se abrirá una pestaña
nueva, Instances, en el área de trabajo.
C) Expande la información en la pestaña Instances seleccionando CMdesign.ttp y pulsando (*) del
teclado numérico ↦ se visualizarán una serie de parámetros seguidos en Ctrl, Hw y environment.
Figura 1.27: Ventana instances del área de trabajo.

1.20.1. Matriz de mensajes

Podemos crear una lista de posibles señales, denominada matriz de mensajes, de forma sencilla para
depuración del sistema. A partir del menu View ↦ Model Verier Windows ↦ Messages.
Para chequear todos los casos de uso, necesitamos las siguientes señales de entorno (environment ):
Señal Valor Descripción

Coin 10 Insertar una moneda con valor 10
Coin 5 Insertar una moneda con valor 5
Coee Pulsar botón Coee
Tea Pulsar botón Tea
Para añadir la señal Coin conteniendo valor 10 en la matriz de mensajes:
A) Doble clic en la parte superior izquierda de la matriz de mensaje, que contiene ... ↦ se activará la
primera la, e introduce los valores en las columnas que se indican a continuación:
● Sender, clic unspecied ↦ selecciona env[1].

● Signal, clic unspecied ↦ selecciona ::CMdesign::Coin.
● Channel, mantener el valor actual, unspecied.
● Receiver, clic unspecied ↦ selecciona CoeeMachine.Ctrl[1].
● Parameter, unspecied ↦ introduce 10 ↦ Enter ↦ la señal será incluida en la matriz de
mensajes.
B) Añade el resto de señales (según la Figura 1.28).
Figura 1.28: Matriz de mensajes.
Para congurar una señal de la matriz de mensajes hacer doble clic en el primer campo.
1.20.2. Inspección de parámetros

Se visualizan los estados en curso de env, Ctrl y Hw. Al iniciar la vericación, todos los estados están
congurados para iniciar, referidos al símbolo Start, lo que signica que las máquinas de estado todavía
no han alcanzado su primer estado. Podemos seleccionar qué otros parámetros deberían ser inspeccionados
durante la depuración.
En la vista Instances, clic-derecho en los parámetros indicados debajo ↦ Watch.

Ctrl :
● NbrOfCoee
● NbrOfTea
● Queue
Hw :
● Queue
env :
● Queue
1.20.3. Trazado
Podemos utilizar diferentes métodos para el trazado de la depuración. Por defecto, se inicia el trazado textual.
Podemos ver la traza textual en la esquina inferior derecha del interface de usuario. Por defecto, también se
ejecuta el seguimiento, lo que signica que el símbolo UML que actualmente están en ejecución se resaltará en
la máquina de estado en el Escritorio. Opcionalmente, también podemos utilizar una secuencia de diagrama
de secuencia. Para iniciar la depuración:
A) En el primer caso de uso sólo vamos a utilizar la traza de diagrama de secuencia. Salimos de la ejecución
de seguimiento mediante .
B) Inicia la traza mediante ↦ aparecerá un diagrama de secuencia en el Escritorio. El diagrama de

secuencia contiene las instancias que representan el entorno (env ), Ctrl y Hw.
C) Clic en dos veces ↦ Ctrl y Hw alcanzarán sus estados Idle.
1.20.4. Vericación de casos de uso

Es momento de insertar una moneda en la Coee Machine . El primera caso de uso que vamos a depurar es
el caso donde insertamos una moneda de valor 10 y el usuario selecciona Coee. La máquina debería retornar
una taza de café.
A) En la matriz de mensajes, doble clic en el campo más a la izquierda de la primera línea, que representa
una señal Coin con valor 10 (o clic-derecho ↦ Send) ↦ en la traza de diagrama de secuencia, se
mostrará el envío de la señal Coin ↦ la señal se coloca en la cola de entrada de Ctrl, que lo podemos
observar en el parámetro Queue de Ctrl.
B) Clic en Next Transition . Ahora, se consume la señal Coin por Ctrl y la cola de Ctrl debería
estar vacía. Comprobamos que el estado de Ctrl ha cambiado a PaidTen.
C) Selecciona Coee enviando la tercera señal de la matriz de mensajes ↦ el diagrama de secuencia

mostrará el envío de la señal.
D) Clic ↦ la señal Coee se consume y la señal FillWater se enviará de Ctrl a Hw.
E) Clic el número de veces necesario para que la señal CupOfCoee aparezca, indicando que el caso
de uso ha sido completado. Observamos que el parámetro NbrOfCoee de Ctrl ha sido incrementado
en 1.
interaction DebugTrace1 Trace {1/1}

//
Sequence diagram
trace
<<actor>> generated for Ctrl[1] Hw[1]
env[1] CoffeeMachine
Idle
Idle
Coin(10)
Coffee()
PaidTen
FillWater()
MakingCoffee
WaterOK()
WaitFill
FillCoffee()
WaterForCoffee
CoffeeOK()
WaitFill
HeatWater()
CoffeeAndWater
Warm()
Idle
CupOfCoffee()
Idle
Figura 1.29: Traza del comportamiento (1).

Tanto Ctrl como Hw han completado sus tareas y retornado al estado Idle, preparados para manejar un
nuevo pedido. La traza completa obtenida debe ser igual a la Figura 1.29, y la misma traza, en formato
texto, visualizada en la pesataña Model Verier, debe ser:
*** TRANSITION START

* Inst : Ctrl :1
* State : start
* Now : 0.0000
* ASSIGN N b r O f C o f f e e :=
* ASSIGN NbrOfTea :=
*** NEXTSTATE Idle

* Inst : Hw: 1
* State : start
* Now : 0.0000
*** NEXTSTATE Idle

* Inst : Ctrl :1
* State : Idle
* T r i g g e r : Coin ( I n t e g e r )
* Sender : env : 1
* Now : 0.0000
* DECISION V a l u e : 10
*** NEXTSTATE PaidTen
S i g n a l C o f f e e ( ) was s e n t t o C t r l : 1 from env : 1
* Inst : Ctrl :1
* State : PaidTen
* Trigger : Coffee ()
* Sender : env : 1
* Now : 0.0000
* OUTPUT o f F i l l W a t e r ( ) t o Hw: 1
*** NEXTSTATE MakingCoffee

* Inst : Hw: 1
* State : Idle
* Trigger : FillWater ()
* Sender : Ctrl :1
* Now : 0.0000
* OUTPUT o f WaterOK ( ) t o C t r l : 1
*** NEXTSTATE WaitFill

* Inst : Ctrl :1
* State : MakingCoffee
* T r i g g e r : WaterOK ( )
* Sender : Hw: 1
* Now : 0.0000
* OUTPUT o f F i l l C o f f e e ( ) t o Hw: 1
*** NEXTSTATE WaterForCoffee

* Inst : Hw: 1
* State : WaitFill
* Trigger : F i l l C o f f e e ()
* Sender : Ctrl :1
* Now : 0.0000
* OUTPUT o f CoffeeOK ( ) t o C t r l : 1
*** NEXTSTATE WaitFill

* Inst : Ctrl :1
* State : WaterForCoffee
* T r i g g e r : CoffeeOK ( )
* Sender : Hw: 1
* Now : 0.0000
* OUTPUT o f HeatWater ( ) t o Hw: 1
*** NEXTSTATE CoffeeAndWater

* Inst : Hw: 1
* State : WaitFill
* T r i g g e r : HeatWater ( )
* Sender : Ctrl :1
* Now : 0.0000
* OUTPUT o f Warm( ) t o C t r l : 1
*** NEXTSTATE Idle

* Inst : Ctrl :1
* State : CoffeeAndWater
* T r i g g e r : Warm( )
* Sender : Hw: 1
* Now : 0.0000
* OUTPUT o f C u p O f C o f f e e ( ) t o env : 1
* ASSIGN N b r O f C o f f e e :=
*** NEXTSTATE Idle
F) Ahora que estamos familiarizados con la traza de diagrama de secuencias, volvemos a la ejecución del
seguimiento mediante ↦ el símbolo UML ejecutado estará ahora resaltado.
G) Vamos a grabar este test para, posiblemente, reproducirlo más adelante ↦ pulsamos Replaying Mode
↦ colocará al vericador de modelos en modo Replay proporcionando los pasos a través del test
desde el inicio de la sesión.
H) Pulsar Restart ↦ Next Transition , repetidas veces y observamos que el mismo test será
ejecutado otra vez.
I) Vamos a grabar este escenario de test ↦ a partir del menú File ↦ Save Scenario ↦ guarda este test
como Coee10.tdscn. Si más adelante modicamos nuestro sistema, siempre podremos reproducir este
escenario cuando ejecutemos el Vericador de modelos.
J) De la misma forma que hemos hecho anteriormente, ejecuta el resto de casos de uso descritos en el
Apartado 1.2 Comportamiento de la Coee Machine . Antes de cada escenario deberíamos iniciar
una traza de diagrama de secuencia y al nal de cada escenario, deberíamos parar la traza, lo que
producirá un nuevo caso de uso para cada escenario. Los casos de uso generados de las trazas serán
visibles en la vista Model en un paquete separado denominado DebugTrace.
K) La Figura 1.30 muestra la traza del comportamiento (2): solicitar té y pagar con 10.
L) La Figura 1.31 muestra la traza del comportamiento (3): solicitar café y pagar con 5.
M) La Figura 1.32 muestra la traza del comportamiento (4): solicitar té y pagar con 5.
Los estados de incio de las máquinas de estados sólo se mostrarán en las trazas si hemos ejecutado un Reseteo
completo de la sesión del vericador de modelos.
N) Cuando todos los escenarios hayan sido completados, podemos nalizar la sesión del Vericador de
modelos mediante Stop Model Verier .
El paquete DebugTrace no se graba por defecto en el chero de modelo actual. Si queremos conservar estos diagramos,
deberíamos guardarlos en un chero nuevo o moverlos al chero .u2en curso ↦ a partir del submenú Model View Filters
↦ Show Files
↦ selecciona y arrastra el paquete hasta el chero.u2que se encuentra en la sección Files
.
interaction DebugTrace2 Trace (2) {1/1}

//
Sequence diagram
trace
<<actor>>
env[1] generated for Ctrl[1] Hw[1]
CoffeeMachine
Idle
Idle
Coin(10)
Tea()
PaidTen
ReturnChange()
FillWater()
MakingTea
WaterOK()
WaitFill
HeatWater()
WaterForTea
Warm()
Idle
CupOfWater()
Idle

//
Sequence diagram
trace
<<actor>> generated for
Ctrl[1] Hw[1]
env[1] CoffeeMachine
Idle
Idle
Coin(5)
Coffee()
PaidFive
ReturnChange()
Idle


//
Sequence diagram
trace
<<actor>>
Ctrl[1] Hw[1]
env[1] generated for
CoffeeMachine
Idle
Idle
Coin(5)
Tea()
PaidFive
FillWater()
MakingTea
WaterOK()
WaitFill
HeatWater()
WaterForTea
Warm()
Idle
CupOfWater()
Idle

1.21. Diagrama de secuencia referenciado
Vamos a utilizar la traza del diagrama de secuencia obtenida con el Vericador de modelos para crear el
diagrama de secuencia referenciado TeaMaking :
A) Localiza un diagrama de secuencia de las secuencias trazadas donde la bebida seleccionada sea Tea ↦
doble click en interaction (o en cualquier punto de la cabecera del diagrama) ↦ localizará el caso de
uso en el paquete DebugTrace en la vista Model.
B) Arrastra el nodo Interaction del primer caso de uso hasta el caso de uso de TeaMaking.
C) Edita el diagrama de secuencia hasta que sea igual a la Figura 1.33 ↦ arrastra las clases apropiadas de
la vista Model del paquete CMDesign a las cabeceras de las líneas de vida correspondientes ↦ elimina
las señales Coin y Tea (ya están especicadas en el escenario MakeTea, Figura 1.17).
D) Chequea que todos los estados y señales encajen en el modelo (indicado en Autocheck ).
E) Graba el trabajo.
interaction TeaMaking Trace (2) {1/1}
<<informal>>
: Customer
FillWater ()
MakingTea
WaterOK ()
Water::WaitFill
HeatWater ()
WaterForTea
Warm ()
Idle
CupOfWater ()
Idle
Figura 1.33: Diagrama de secuencia TeaMaking.
1.22. Interacciones y adiciones
Vamos a añadir algunas propiedades al modelo así como mostrar características adicionales de UML.
1.22.1. Temporizadores
Vamos a introducir un temporizador en la Coee Machine . El temporizador debe expirar en 10 unidades de
tiempo y debe ser establecido en conjunción con la actividad de calentamiento de agua.
A) En la clase Hardware, en la vista Model ↦ añadir un temporizador denominado Heater a la clase.

Clic-derecho en la clase Hardware ↦ New Model Element ↦ Timer (Figura 1.34).
package CMdesign ControlComponents {2/3}
FillCoffee,FillWater,HeatWater FillCoffee,FillWater,HeatWater
Controller Hardware
P3 P4
initialize ()
initialize ()
timer Heater ()
CoffeeOK,WaterOK,Warm CoffeeOK, WaterOK, Warm
Figura 1.34: Declaración del temporizador Heater en la clase Hardware .
B) En la máquina de estados de Hardware ↦ la señal del temporizador debería ser recibida de forma que
active el envío de la señal Warm ↦ sustituye la señal HeatWater por Heater en la transición del
estado Water al estado Idle (Figura 1.35).
¡¡ atención !!
hemos sustituido
HeatWater() por Heater()
statemachine Hardware :: initialize HandlingWater {1/1}
Heater()/^Warm();
Idle
FillWater()/^WaterOK();
Water
Figura 1.35: Temporizador Heater en el estado combinado HandlingWater .
C) En el diagrama de estado compuesto Water ↦ añade la señal HeatWater en paralelo con la señal FillCof-
fee. Esta transición debe contener la sentencia set del temporizador Heater, set(Heater(),now+10);
(Figura 1.36).
state Water State machine diagram1 {1/1}
WaitFill
FillCoffee() HeatWater()
CoffeeOK() set(Heater(),now+1);
Figura 1.36: Temporizador Heater en la máquina de estados Water .
El comportamiento que hemos añadido consiste en hacer más realístico el calentamiento del agua, de forma que,
desde que llega la señal de calentar agua, modelada por HeatWater(), tardará un tiempo en calentar el agua, el
establecido con el temporizador Heater().
D) Guarda el trabajo.
E) Ahora podemos construir y ejecutar el Vericador de modelos para chequear que el temporizador
que hemos incorporado funciona correctamente. Para ello, vamos a realizar la traza del escenario en un
diagrama de secuencia, lo que mostrará la representación del temporizador en un diagrama de secuencia.
Utilizaremos el escenario Coee10.ttdscn, grabado previamente, para ejecutar el test. Cuando el test
alcance el evento timer no continuará el proceso porque el sistema ha cambiado ↦ detenga el modo
replay del test y ejecute el resto del escenario de forma manual. La traza para el caso de uso (1),
utilizando temporizador, debe de ser igual al de la Figura 1.37.
F) Cuando todos los escenarios hayan sido completados, detenemos el Vericador de Modelos mediante
Stop Model Verier .
1.22.2. Datos estructurados

Ahora vamos a introducir una nueva clase representando una conjunto de datos estructurados en el modelo
Coee Machine . Los contenidos de este modelo de datos serán leche y azúcar para poner junto al café .
Esta operación requiere varios pasos para ser ejecutada y afectará al envío y recepción de señales así como al
comportamiento interno. Resultará un escenario más complejo cuando ejecutemos el Vericador de Modelos.
A) Abre el diagrama de clase Signals ↦ añade una clase en el diagrama ↦ el nombre de la clase es
Additives .
B) Añade dos atributos a la clase, Milk del tipo Boolean y Sugar del tipo Integer ↦ declara los
atributos como públicos.
Para establecer la visibilidad a pública, escribe el signo + delante del nombre de atributo en la interface del símbolo
(clase).
C) La señal Coee, que debe estar en el interface FromUser, declárala como una parte de Additives (en
el apartado de parámetros).
D) La señal CupOfCoee, que debe estar en el interface ToUser, declárala como una parte de Additives
(en el apartado de parámetros) (ambas señales tienen que quedar declaradas como en la Figura 1.38).
E) Abre el diagrama de estados NewOrder de la clase Controller ↦ declara una variable Add del tipo
Additives ↦ declara la variable como una parte (Figura 1.39).
Declarando un parámetro o variable como una parte afecta a la forma en la que se tratará durante la generación de código,
y además, afectará a cómo se envía los valores a través del interface del Vericador de Modelos. Por defecto, una clase
será representada por un puntero a un modelo de datos estructurados, las variables declaradas partes serán, posiblemente,
referenciadas por valor.
F) Declara una variable NoAdd del tipo Additives. No declares esta variable como parte.
G) Utiliza la variable Add para recibir peticiones de leche y azúcar cada vez que se recibe la señal Coee
(una posible solución en la Figura 1.39).
H) Utiliza el valor de la variable Add como parámetros cuando enviamos CupOfCoee al entorno.
I) Graba el trabajo.
J) Ahora deberíamos de construir y ejecutar el Vericador de Modelos para comprobar que la declaración
de parámetros que hemos realizado funciona correctamente. Utiliza la funcionalidad Watch en el
Vericador de Modelos, por ejemplo, visualizando y comprobando cómo se presentan Add y NoAdd.
K) Además, debemos de actualizar los diagramas de secuencia para permitir el parámetro nuevo (Figura
1.40).
Importante : el clasicador de tipo antes del parámetro. Debemos de aportar la clase completa con el
clasicador de tipo en el campo parámetros de la ventana de mensajes (Figura 1.41):
(Additives (.Milk=true, Sugar=3.))

Podemos copiar y pegar la clase con parámetros desde una ventana Watch ↦ clic-dercho ↦ Deep
Copy ↦ pegarlo en el campo Parameters con CRTL+V. En la Figura 1.41 visualizamos la ventana
Mensajes, con los mensajes modicados.
L) Una vez ejecutado el Vericador de Modelos, comprobamos el correcto funcionamiento del parámetro
Additives (Figura 1.42).

//
Sequence diagram
trace
generated for
CoffeeMachine
<<actor>>
Ctrl[1] Hw[1]
env[1]
Idle
Idle
Coin(10)
Coffee()
PaidTen
FillWater()
MakingCoffee
WaterOK()
WaitFill
FillCoffee()
WaterForCoffee
CoffeeOK()
WaitFill
HeatWater()
CoffeeAndWater
Heater() = 1.0000
WaitFill
Heater()
Warm()
Idle
CupOfCoffee()
Idle
Figura 1.37: Diagrama de secuencia del test case (1) con temporizador.
<<interface>> <<interface>>
FromUser ToUser Additives
+Milk:Boolean
+Sugar:Integer
signal CupOfCoffee (part Additives)
signal Coin ( Integer)
signal CupOfWater ()
signal Tea ()
signal ReturnChange ()
Figura 1.38: Clase Additives.
statemachine Controller :: initialize NewOrder {1/2}
Idle Integer NbrOfCoffee;

Integer NbrOfTea;
NbrOfCoffee = 0; Integer Value;
NbrOfTea=0; Coin(Value) part Additives Add;
Add.Milk=true; Additives NoAdd;
Add.Sugar=1;
NoAdd=Add; Value
Idle
5 10 else
PaidFive PaidTen Idle
PaidFive PaidTen
Tea() Coffee(Add) Tea() Coffee(Add)
FillWater() ReturnChange() ReturnChange() FillWater()
MakingTea Idle FillWater() MakingCoffee
MakingTea
Figura 1.39: Máquina de estados para Controller con Additives.

interaction MakeCoffee Sequence Diagram {1/1}
<<informal>>
: Customer
Coin(10)
Coffee (Additives(.Milk=true,Sugar=3.))
FillWater ()
WaterOK ()
FillCoffee ()
CoffeeOK ()
HeatWater ()
Warm ()
ToUser::CupOfCoffee ()
Figura 1.40: Diagrama de secuencia con el parámetro del tipo Additives.
Figura 1.41: Ventana Mensajes con el parámetros del tipo Additives.

interaction 'DebugTrace-Additives' Trace (2) {1/1}

//
Sequence diagram
trace
generated for
CoffeeMachine
<<actor>>
Ctrl[1] Hw[1]
env[1]
Coin(10)
Coffee(Additives (.Milk = true, Sugar = 3.))
Idle
Idle
PaidTen
FillWater()
MakingCoffee
WaterOK()
WaitFill
FillCoffee()
WaterForCoffee
CoffeeOK()
WaitFill
HeatWater()
CoffeeAndWater
Heater() = 1.0000
WaitFill
Heater()
Warm()
Idle
CupOfCoffee(Additives (.Milk = true, Sugar = 3.))
Idle
Figura 1.42: Traza del diagrama de secuencia utilizando parámetros del tipo Additives.
1.23. Modicación del modelo Coee Machine

Vamos a añadir los siguientes comportamientos:
(5) Añadir un pulsador Eject de devolución de moneda en caso de no haber pulsado ninguna opción de
bebida.
(6) Después de introducir la moneda, si no ha pulsado ninguna opción de bebida, pasado un tiempo,
devolverá la moneda.
Cuestión 1
Aporta las modicaciones realizadas en el modelo Coee Machine para incorporar los comportamientos
denidos en (5) (6).
Cuestión 2
Aporta un diagrama de secuencia para vericar el correcto funcionamiento del comportamiento (5).
Cuestión 3
Aporta un diagrama de secuencia para vericar el correcto funcionamiento del comportamiento (6).
Cuestión 4
Proporciona una valoración global de la práctica realizada, indicando qué conocimientos, habilidades
y conceptos has adquirido así como sugerencias de posibles cambios o errores detectados.
1.24. Informe
Redacta un informe atendiendo a las cuestiones planteadas.
Debido a que las herramientas PragmaDev Studio , Spin y Telelogic Tau SDL proporcionan la salida
AT X
gráca en formato eps (encapsulated postscript ), se recomienda y valorará positivamente, el uso de L E
para la confección de las memorias.
El formato nal de la memoria debe ser pdf.

Laboratorio 2
Especicación, vericación y
validación de ABP con SDL
SDT rw C:\Trabajo\Docencia\IP\Tools\TelelogicSDL\Modelos\ABP\Venkataram\abp.sdt
rw C:\Trabajo\Docencia\IP\Tools\TelelogicSDL\Modelos\ABP\Venkataram\
ABP 3 rw ABP.ssy
Requeriments 4 rw Requeriments.msc
ABP 6 rw ABP_block.sbk
DataMedium 7 rw DataMedium.spr
AckMedium 8 rw AckMedium.spr
ReceiverP 9 rw ReceiverP.spr
SenderP 10 rw SenderP.spr
ULSenderP 11 rw ULSenderP.spr
ULReceiverP 12 rw ULReceiverP.spr
49
50 LABORATORIO 2. ESPECIFICACIÓN, VERIFICACIÓN Y VALIDACIÓN DE ABP CON SDL
2.1. Objetivos
1
Utilizando la herramienta IBM Telelogic SDL and TTCN Suite realizaremos la especicación, simulación
2
y validación del Alternating Bit Protocol .
2.2. Especicación del modelo

El protocolo de bit alternante es un protocolo punto a punto que opera a nivel de enlace de datos sobre un
medio de transmisión no conable. Las especicaciones del protocolo son las siguientes:
● Es un entorno de comunicaciones punto a punto (canal ) formado por dos estaciones: Emisor (E) y
Receptor (R).
● El dispositivo Emisor transmite tramas de datos numeradas 0 y 1, alternativamente.
● El dispositivo Receptor conrma la recepción de tramas de datos mediante el envío de tramas ack : ack
0 conrma la recepción correcta de la trama de datos 0, ack 1 conrma la recepción correcta de la
trama de datos 1.
● El medio puede perder tanto tramas de datos como ack.
● Las trama que alcanzan el destino están libres de error.
● En el Emisor, el nivel superior solicitará el envío de un mensaje, y el nivel inferior será el encargado de
la transmisión y repetición hasta lograr la entrega efectiva de los datos.
● Los datos serán entregados al nivel superior del Receptor, siendo el nivel inferior el encargado de enviar
las tramas ack.
2.3. Especicación en IBM Telelogic SDL and TTCN Suite

La aplicación IBM Telelogic SDL and TTCN Suite debemos tenerla perfectamente instalada en la estación,
3
así como un compilador Microsoft Visual Studio . Para la especicación del modelo, seguiremos los siguientes
pasos:
A) Inicia IBM Telelogic SDL and TTCN Suite ↦ pulsa Continue para cerrar la ventana de bienvenida.
B) Creamos un proyecto nuevo ↦ File ↦ New ↦ Start with an empty system ↦ OK.
C) Vamos a grabar el proyecto ↦ Save as ↦ nombra el proyecto como tus iniciales seguido de ABP, por
ejemplo: SAC_ABP.
A tener en cuenta
En tus de modelos debes de indicar siempre tus iniciales ya que posteriormente, aparecerán en las
grácas generadas y serán utilizadas en la posterior corrección de prácticas. ½½ no lo olvides !!
1 La herramienta IBM Telelogic SDL and TTCN Suite fué desarrollada por la compañía sueca Telelogic, y posteriormente
adqurida por IBM. Actualmente, IBM la comercializa como IBM Rational, pero nosotros seguiremos utilizando la original por
adaptarse mejor a nuestras necesidades.
2 Extraído de Venkataram, P., Communication Protocol Engineering, 2nd ed., PHI Learning, 2014.
3 Utilizamos Visual Studio 6. Ver incompatibilidades con otras versiones de compilador.
LABORATORIO 2. ESPECIFICACIÓN, VERIFICACIÓN Y VALIDACIÓN DE ABP CON SDL 51
Debes de tener en cuenta a la hora de nombrar los cheros y carpetas utilizados por IBM Telelogic SDL and TTCN Suite
que no pueden aparecer espacios en la ruta de cheros.
2.3.1. Especicación de requisitos
Figura 2.1: Añadir especión de requisitos en MSC
Vamos a realizar una especicación de requisitos del protocolo ABP mediante un diagrama MSC.
A) En el menú principal ↦ Edit ↦ Add New ↦ selecciona MSC ↦ en las opciones, selecciona el diagrama
MSC ↦ nómbralo Requirements.msc ↦ OK (Figura 2.1).
B) En el diagrama MSC desplegado, realiza la especicación de requisitos de ABP (Figura 2.2).
C) Guarda el diagrama.
A tener en cuenta
De forma deliberada, hemos introducido un error en la especicación de requisitos, que utilizaremos
posteriormente en la fase de validación del modelo.
MSC TrazaCompleta
Environment ULSenderP SenderP DataMedium AckMedium ReceiverP ULReceiverP
Wait Empty1 Empty1 Idle_0 Wait
sender_ready
Idle_1
send
dataS_0 dataR_0
Timer1
ackr_0
receiver_ready
Wait
Wait_0
Wait_0
acks_0
sender_ready receive
Empty1 Empty1
Wait_1
Idle_0
deliver
send
dataS_1
Timer1 Idle_1 Wait
dataR_1
ackr_1
Wait_1 receiver_ready
Wait acks_1
Wait_1
sender_ready
receive
Idle_1
send
Wait_1
deliver
Figura 2.2: Especicación de requisitos.

2.3.2. Especicación de la arquitectura del sistema
system ABP 1(1)
data_loss_signal
Venkataram, P.,
Sunilkumar, S.M.
Babu, B.S. Lose_Data
Communication Protocol Engineering,
2nd ed. PHI Learning, 2014
ABP
SIGNAL
Lose_Ack,Lose_Data, Lose_Ack
Send, Sender_Ready, Receiver_Ready,
Receive, Deliver,
DataR_0, DataR_1, DataS_0, DataS_1,
AckS_0, AckS_1, AckR_0, AckR_1; ack_loss_signal
Figura 2.3: Añadir elemento system.
Ahora vamos a especicar la arquitectura del sistema:
A) En primer lugar debemos de añadir el system al proyecto ↦ Edit ↦ Add New ↦ selecciona SDL ↦
mantenemos la opción System ↦ nombra al documento con ABP (Figura 2.3) ↦ OK.
B) Abre el módulo system ↦ inserta bloque ABP, así como las señales del entorno utilizadas para modelar
la pérdida de tramas y ack, respectivamente (Figura 2.4)
system ABP 1(1)
data_loss_signal
Venkataram, P.,
Sunilkumar, S.M.
Babu, B.S. Lose_Data
Communication Protocol Engineering,
2nd ed. PHI Learning, 2014
ABP
SIGNAL
Lose_Ack,Lose_Data, Lose_Ack
Send, Sender_Ready, Receiver_Ready,
Receive, Deliver,
DataR_0, DataR_1, DataS_0, DataS_1,
AckS_0, AckS_1, AckR_0, AckR_1; ack_loss_signal
Figura 2.4: Especicación del sistema.
C) Doble click en el bloque ABP ↦ OK ↦ OK.
D) En este punto, estaremos visualizando el bloque ABP vacío, en el que vamos a insertar todos los
elementos que denen la arquitectura estática del protocolo ABP.
E) Inserta todas referencias a proceso, canales y señales (Figura 2.5).
data_loss_signal
block ABP 1(1)

R10
ULSenderP ULReceiverP
Lose_Data
Sender_Ready Receiver_Ready,
Deliver
R1 R4 R2
R3
DataMedium
DataS_0, DataS_1
Send DataR_0,DataR_1 Receive
SenderP ReceiverP
R6 R5
AckMedium
AckS_0, AckS_1 AckR_0, AckR_1
Lose_Ack
R11
ack_loss_signal
Figura 2.5: Especicación del bloque ABP.

2.3.3. Especicación del comportamiento del sistema

Una vez denidas las referencias a proceso, así como los diferentes canales y señales, tenemos que especicar
el comportamiento del sistema mediante los diferentes procesos.
Para cada uno de las referencias a proceso ↦ doble click ↦ OK ↦ OK, y se abrirá el diagrama de proceso
correspondiente.
Proceso ULSenderP
El proceso ULSenderP modela el nivel superior (Upper Layer) del dispositivo emisor. Su comportamiento
viene denido por el diagrama de proceso de la Figura 2.6.
process ULSenderP 1(1)
Wait
Sender_Ready
Send
Figura 2.6: Especicación del proceso ULSenderP.
Proceso ULReceiverP
El proceso ULReceiverP modela el nivel superior (Upper Layer) del dispositivo receptor. Su comportamiento
viene denido por el diagrama de proceso de la Figura 2.7.
process ULReceiverP 1(1)
Wait
Receiver_Ready
Receive
Wait_1
Deliver
Figura 2.7: Especicación del proceso ULReceiverP.

Proceso SenderP
El proceso SenderP modela el nivel de enlace del dispositivo emisor. Su comportamiento viene denido por
el diagrama de proceso de la Figura 2.8.
process SenderP 1(1)

Timer Timer1;
Send_0 Send_1
Sender_Ready DataS_0 DataS_1
Idle_1 set(now+5,Timer1) set(now+5,Timer1)
Wait_0 Wait_1
AckS_1 AckS_0 Timer1 AckS_0 AckS_1 Timer1
reset(Timer1) reset(Timer1)
Sender_Ready Sender_Ready
Idle_0 Idle_1
Send ackS_0 Send ackS_1
Send_1 Send_0
Figura 2.8: Especicación del proceso SenderP.

Proceso ReceiverP
El proceso ReceiverP modela el nivel de enlace del dispositivo receptor. Su comportamiento viene denido
por el diagrama de proceso de la Figura 2.9.
process ReceiverP 1(1)
Idle_0
Wait_0 Wait_1
DataR_1 Receive DataR_0 DataR_0 Receive DataR_1
Deliver AckR_0 Deliver AckR_1
Idle_1 Idle_0
DataR_0 DataR_1 DataR_1 DataR_0
AckR_0 AckR_1 AckR_1 AckR_0
Receiver_Ready Receiver_Ready
Wait_1 Wait_0
Figura 2.9: Especicación del proceso ReceiverP.

Proceso DataMedium
El proceso DataMedium modela la transmisión de tramas de datos en el medio. Su comportamiento viene
denido por el diagrama de proceso de la Figura 2.10.
process DataMedium 1(1)
Empty1
DataS_0 Lose_Data DataS_1
DataR_0 Lose DataR_1
DataS_0 DataS_1
Figura 2.10: Especicación del proceso DataMedium.
Proceso AckMedium
El proceso AckMedium modela la transmisión de tramas ack en el medio. Su comportamiento viene denido
por el diagrama de proceso de la Figura 2.11.
process AckMedium 1(1)
Empty1
AckR_0 Lose_Ack AckR_1
AckS_0 Lose AckS_1
AckR_0 AckR_1
Figura 2.11: Especicación del proceso AckMedium.

2.4. Análisis sintáctico

Una vez hemos introducido todos los módulos en el sistema ABP, el aspecto nal de Organizer debe ser como
en la Figura 2.12.
SDT rw C:\Trabajo\Docencia\IP\Tools\TelelogicSDL\Modelos\ABP\Venkataram\abp.sdt
rw C:\Trabajo\Docencia\IP\Tools\TelelogicSDL\Modelos\ABP\Venkataram\
Requirements rw Requeriments.msc
ABP 3 rw ABP.ssy
ABP_block 4 rw ABP_block.sbk
DataMedium 5 rw DataMedium.spr
AckMedium 6 rw AckMedium.spr
ReceiverP 7 rw ReceiverP.spr
SenderP 8 rw SenderP.spr
ULSenderP 9 rw ULSenderP.spr
ULReceiverP 10 rw ULReceiverP.spr
Figura 2.12: Aspecto nal de Organizer.
Antes de obtener el simulador y/o validador es conveniente realizar un análisis sintáctico del modelo, donde
podremos encontrar errores de sintaxis.
A) Si estamos editando algún bloque del sistema, para volver a la pantalla Organizer mediante el botón
↦ seleccionamos el bloque ABP system.
B) Para efectuar el análisis sintáctico del modelo ↦ clic en .
C) De forma deliverada, habíamos introducido un error en un proceso, concretamente, la señal Delivery es

incorrecto, la forma correcta es Deliver. Podemos observar el error en la ventana que se ha desplegado:
+ Analysis started
Conversion of SDL to PR started
Conversion to PR completed
Syntactic analysis started
Syntactic analysis completed
Semantic analysis started
# SDTREF ( SDL ,C :\ Trabajo \ Docencia \ IP \ Tools \ TelelogicSDL \ Modelos \ ABP \ Venkataram \ ReceiverP . spr (1)
,143(40 ,80) ,1 ,1)
1: ERROR 104 Undefined signal , timer , signallist , remote procedure or remote variable
output ? Delivery
Semantic analysis completed
--------------------------------------------------
Number of errors : 1
2: INFO 278 Analyzer command could not be fully performed

+ Analysis completed
D) Posicionando el cursor en el error y pulsando nos dirigirá a símbolo detectado erróneo ↦ cambiamos
por Deliver.
E) Mediante volvemos a la pantalla Organizer ↦ volvemos a realizar el análisis sintáctico ↦ el sistema

debe estár libre de errores y avisos.
2.5. Simulación
En el proceso de vericación de protocolos, uno de las primeras tareas a realizar es la simulación del modelo.
A partir del modelo SDL propuesto, la herramienta IBM Telelogic SDL and TTCN Suite convierte el código
4
SDL a código C, y posteriormente, a código máquina mediante el compilador correspondiente .
Figura 2.13: Generación del simulador.
Para construir el simulador:

A) A partir de la pantalla Organizer ↦ selecciona el bloque system ↦ en las opciones de menú, selecciona
Generate ↦ Make ↦ seleccionar Microsoft Simulation ↦ FullMake (Figura 2.13).
De forma alternativa, disponemos del botón en la barra de herramientas.
B) En caso de haber generado algún error de compilación, revisar el modelo y volver a recompilar. El
simulador obtenido a partir del modelo SDL es un chero ejecutable (EXE) al que podemos acceder
desde el intérprete de comandos e interactuar con él mediante una serie de instrucciones o desde la
interface de IBM Telelogic SDL and TTCN Suite .
C) Para ejecutar el simulador ↦ a partir del menú principal ↦ Tools ↦ SDL ↦ Simulator UI.
D) Una vez accedemos a la Herramienta del simulador, necesitamos cargar el simulador previamente ge-
nerado ↦ File ↦ Open ↦ ABP_smc ↦ OK (Figura 2.14)
Una vez que el simulador ha sido cargado, disponemos de las siguientes opciones de ejecución:
Symbol: La ejecución avanza un símbolo de los denidos en el modelo.

Transition: Produce un avance de simulación hasta el siguiente estado.
Until Timer: Avanza hasta el siguiente temporizador.
Go: Produce una simulación continua. En el caso de no depender de señales del entorno, y si el modelo lo
permite, producirá una simulación innita.
4 En nuestro caso utilizamos el compilador Microsoft Visual Studio 6.

Figura 2.14: Acceso al simulador.
Break: Abortar la simulación.
Disponemos de instrucciones para el envío de señales:
Send To: Enviar señal a un proceso.

Send Via: Enviar señal a un canal.
Send None: Enviar señal de transmisión espontánea a un proceso.
Disponemos de opciones de inspección de datos:
Process List: Visualizar información relativa a los procesos del modelo: número de instancias, estado, se-
ñales y cola.
Variable: Visualización de variables de proceso.

Var in Scope:
Y las opciones de visualización son las siguientes:
MSC: Visualización de la simulación mediante MSC. Muy útil ya que nos permite grabar el diagrama MSC
e incorporarlo al modelo para posteriores validaciones.
SDL: Muestra la evolución de la simulación mediante diagramas SDL.

TEXT: Muestra la evolución de la simulación en formato texto en el interface de usuario.
La Figura 2.15 contiene la traza MSC de un fragmento de la simulación del envío y pérdida de trama de
datos 0.
Una vez realizada una simulación, debemos de resetear el simulador ↦ Files ↦ Restart, para volver al estado inicial del
simulador.
MSC SimulatorTrace
Simulation trace
generated by
SDL Simulator
process process process process process process
ULSenderP ULReceiverP DataMedium SenderP ReceiverP AckMedium
env_0 ULSenderP_1_1 ULReceiverP_1_2DataMedium_1_3 SenderP_1_4 ReceiverP_1_5 AckMedium_1_6
Wait
Wait
Empty1
Sender_Ready
Idle_1
Lose_Data
Idle_0
Empty1
Send
Wait
Lose
DataS_0
Timer1(5.0000)
Wait_0
Empty1
DataS_0
Timer1(5.0000)
Wait_0
DataR_0
/* Not yet consumed by */ ReceiverP_1_5
Empty1
Figura 2.15: Simulación del modelo.

2.6. Validación
Posteriormente a la simulación, realizaremos la validación5 del modelo en busca de errores de diseño.
Figura 2.16: Generación del validador.
Para generar el validador:

A) A partir de la pantalla Organizer ↦ selecciona el bloque system ↦ en las opciones de menú, selecciona
Generate ↦ Make ↦ seleccionar Microsoft Validation ↦ FullMake (Figura 2.16).
De forma alternativa, disponemos del botón en la barra de herramientas.
B) En caso de haber generado algún error de compilación, revisar el modelo y volver a recompilar. El
validador obtenido a partir del modelo SDL es un chero ejecutable (EXE) al que podemos acceder
desde el intérprete de comandos e interactuar con él mediante una serie de instrucciones o desde la
interface de IBM Telelogic SDL and TTCN Suite .
C) Para ejecutar el validador ↦ a partir del menú principal ↦ Tools ↦ SDL ↦ Explorer UI.
D) Una vez accedemos a la Herramienta del validador, necesitamos cargar el validador previamente gene-
rado ↦ File ↦ Open ↦ ABP_vmc ↦ OK (Figura 2.17)
El mecanismo de validación de IBM Telelogic SDL and TTCN Suite está basado en la generación y exploración
del espacio de estados. Proporciona diferentes mecanismos de búsqueda en el espacio de estados:
● Exploración por bit de estado
● Recorrido aleatorio
● Recorrido en árbol
● Búsqueda exhaustiva
● Vericación con MSC (Message Sequence Chart)
5 El término validación también hace referencia a la Exploración del árbol de estados.

Figura 2.17: Acceso al validador.
2.6.1. Exploración por bit de estado (bit-state )

La exploración por bit de estado (bit-state) realiza una búsqueda en el árbol de estados, proporcionando
la siguiente información:
● Riesgo de colisión en la ubicación de estados en la tabla hash.
● Máximo de niveles del árbol de comportamiento que ha sido alcanzado durante la exploración.
● Nivel actual del árbol de comportamiento alcanzado cuando la exploración se detuvo.
● Tamaño mínimo del vector de estado en la tabla hash.
● Tamaño máximo del vector de estado en la tabla hash.
● Porcentaje de símbolos que han sido ejecutados por lo menos una vez.
La validación del modelo ABP con el método bit-state proporciona el siguiente resultado:
Command : Bit - State - Exploration
** Starting bit state exploration **

Search depth : 100
Hash table size : 1000000 bytes
** Bit state exploration statistics **

No of reports : 1.
Generated states : 31.
Truncated paths : 0.
Unique system states : 30.
Size of hash table : 8000000 (1000000 bytes )
No of bits set in hash table : 60
Collision risk : 0 %
Max depth : 30
Current depth : -1
Min state size : 176
Max state size : 316
Symbol coverage : 67.06
Una vez realizada una exploración del modelo, debemos de resetear el validador ↦ Files ↦ Restart.
2.6.2. Exploración aleatoria (random walk )

La exploración aleatoria (random walk ) realiza exploraciones en profundidad, eligiendo caminos de
forma aleatoria repetidamente. Apropiado para modelos grandes.
● Número de reports generados.
● Total de estados del sistema generados.
● Valor máximo de niveles alcanzado durante la exploración.
● Valor mínimo de niveles alcanzado durante la exploración.
La validación del modelo ABP con el método random walk proporciona el siguiente resultado:
Command : Random - Walk
** Starting random walk **

Depth : 100
Repetitions : 100
** Random walk statistics **

No of reports : 1
Gen states : 3000
Max depth : 29
Min depth : 29
2.6.3. Recorrido en árbol (tree walk )

El recorrido en árbol (tree walk ) ejecuta una exploración del espacio de estados, con las siguientes
características:
● Ejecuta una búsqueda automática desde el estado del sistema actual.
● Ejecuta una secuencia de búsquedas en árbol, con incrementos de profundidad e iniciando la búsqueda
desde diferentes estados del grafo de alcanzabilidad.
● Utiliza una heurística de cobertura de símbolos.
● Es apropiado para la generación automática de test de casos.
Este mecanismo necesita los datos de entrada:
● Tiempo de computación (en minutos).
● Porcentaje de símbolos que debe de ser ejecutado por lo menos una vez.
La validación del modelo ABP con el método Tree-Walk proporciona el siguiente resultado:
Command : Tree - Walk 10 10

Tree Walk will stop after 10 minutes or after reaching 10 % symbol coverage .
Reports and symbol coverage table cleared .
States : 250. Reports : 0. Tree walk reports : 0 (+250) . Coverage : 67.06 %. Time : 000:00:00
Target symbol coverage is reached .

Tree Walk is stopped .
Test report #1 of length 250 added .
2.6.4. Exploración exhaustiva (exhaustive exploration )

La exploración exhaustiva (exhaustive exploration ) tiene las siguientes características:
● Indicado para systemas SDL pequeños con elevadas necesidades de corrección.
● Algoritmo de búsqueda en profundidad similar a la búsqueda por bit de estado, pero sin colisiones.
● El inconveniente es que utiliza más recursos de memoria.
La exploración exhaustiva proporciona las siguientes estadísticas:
● Número de reports generados.
● Total de estados del sistema generados.
● Veces que ha alcanzado la máxima profundidad.
● Estados generados que no son duplicados.
● Tamaño tabla hash en bit y bytes.
● Máximo de niveles del árbol de comportamiento que ha sido alcanzado durante la exploración.
● Nivel actual del árbol de comportamiento alcanzado al nalizar la exploración.
● Tamaños mínimo y máximo del vector de estado en la tabla hash.
La validación del modelo ABP con el método exhaustivo proporciona el siguiente resultado:
Command : Exhaustive - Exploration
** Starting exhaustive exploration **

Search depth : 100
** Exhaustive exploration statistics **

No of reports : 2
Generated states : 31
Current depth : -1
Max depth : 29
2.6.5. Vericación MSC

La vericación MSC realiza una exploración bit-state con las siguientes características:
● Necesita un escenario MSC que se utiliza para guiar la búsqueda.
● La búsqueda en profundidad es diferente a la habitual en exploración por bit de estado.
● La búsqueda se aborta tan pronto como el MSC ha sido vericado.

A partir de la especicación de requisitos en un diagrama MSC (Figura 2.2) vamos a realizar la validación
del modelo especicado en SDL, es decir, el validador nos informará si el modelo construído (SDL) coincide
con la especicación (MSC).
A) Resetea el validador ↦ File ↦ Restart.
B) Carga la traza MSC ↦ mediante Verify MSC ↦ Requeriments ↦ OK.
El resultado de la validación es el siguiente:
Command : Verify - MSC C :\ Trabajo \ Docencia \ IP \ Tools \ TelelogicSDL \ Modelos \ ABP \ Venkataram \ Requeriments . msc
MSC Requeriments loaded .

Root of behaviour tree set to current system state
Reports cleared
Bit state exploration started .

No of reports : 1.
Max depth : 17
Current depth : -1
** MSC Requeriments NOT VERIFIED **
Además, se despliega un report donde nos muestra la traza generada hasta el error, y muestra (en modo
texto) información detallada en el entorno del error:
Command : Goto - Report 1

*** Transition START
* PId : SenderP :1
* State : Idle_0
* Input : Send
* Sender : ULSenderP :1
* OUTPUT of DataS_1 . Receiver : DataMedium :1
* Signal DataS_1 received by DataMedium :1
* SET on timer Timer1 at 5.0000
*** NEXTSTATE Wait_1
MSC Requeriments violated

Event : *** Transition START
* PId : SenderP :1
* State : Idle_0
* Input : Send
* Sender : ULSenderP :1
Con la información proporcionada por el validador, y analizando el modelo SDL, debemos de llegar a la con-
clusión que el error está en el proceso SenderP : en el diagrama MSC de requisitos, en el primer temporizador
hay un error, al especicar el reset del temporizador después de enviar sender_ready, y la especicación
correcta sería antes de enviar la señal sender_ready.
MSC Requeriments
Environment ULSenderP SenderP DataMedium AckMedium ReceiverP ULReceiverP
Wait Empty1 Empty1 Idle_0 Wait
sender_ready
Idle_1
send
dataS_0 dataR_0
Timer1
ackr_0
receiver_ready
Wait
Wait_0
Wait_0
acks_0
receive
sender_ready
Empty1 Empty1
Wait_1
Idle_0
deliver
send
dataS_1
Timer1 Idle_1 Wait
dataR_1
ackr_1
Wait_1 receiver_ready
Wait acks_1
Wait_1
sender_ready
receive
Idle_1
send
Wait_1
deliver
Figura 2.18: Especicación de requisitos revisado (en rojo, las señales involucradas en el error).
Realizamos las correcciones oportunas en la especicación de requisitos (Figura 2.18) y volvemos a validar
(recuerda resetear el validador), obteniendo una vericación OK del modelo:
Command : C :\ Trabajo \ Docencia \ IP \ Tools \ TelelogicSDL \ Modelos \ ABP \ Venkataram \ Requeriments . msc
MSC Requeriments loaded .

Root of behaviour tree set to current system state
Reports cleared
Bit state exploration started .

No of reports : 1.
Max depth : 26
Current depth : -1
** MSC Requeriments verified **
Current state is MSC verification state .
2.6.6. Navigator
En relación a la herramienta Navigator:
● Es una herramienta que se utiliza para navegar por el árbol de comportamiento.
● La ventana del navegador dispone de un área de árbol y de una barra de herramientas.
● En el área de árbol se muestra la estructura del árbol alrededor del estado actual.
2.7. Cuestiones
Cuestión 1
Aporta una traza MSC, en formato gráco, de una simulación completa del modelo. Comenta el resul-
tado.
Cuestión 2
A partir de la descripción MSC de la Figura 2.2, genera e incorpora un comportamiento, mediante un

diagrama MSC, donde se produzca una pérdida de trama ACK. Valida dicho comportamiento con el
modelo ABP, demostrando que, incluso con pérdida de ACK, el modelo se comporta correctamente.
Cuestión 3
A partir de la descripción MSC de la Figura 2.2, genera e incorpora un comportamiento, mediante

un diagrama MSC, donde se produzca el envío de dos tramas de datos consecutivas con el mismo
bit. Valida dicho comportamiento con el modelo ABP, demostrando que, NO es posible que el sistema
entregue en el destino dos tramas de datos con el mismo bit.
Cuestión 4
2.8. Informe
AT X

Laboratorio 3
Introducción al lenguaje Promela y

Spin
(X)SPIN Architectures
deadlocks random
safety properties spin command guided
liveness properties line tool interactive
φ LTL
Translater
Simulator
ispin
Promela jspin
model M spin
xspin Verifier
··· Generator
editing window C program pan.*

simulation options
verification options
MSC simulation window counter false
example checker pan.exe
71
72 LABORATORIO 3. INTRODUCCIÓN AL LENGUAJE PROMELA Y SPIN
3.1. Objetivos
El objetivo de este laboratorio consiste en un primer acercamiento al lenguaje de modelización Promela y
la herramienta de Model checking Spin, para ello, abordaremos varios problemas típicos en la modelización
de sistemas tales como sección crítica, entrelazado de estados y tratamiento de la explosión de estados.
3.2. Hola Mundo

A partir de un modelo Promela sencillo, realizaremos los pasos de simulación, así como la obtención, compi-
lación y ejecución del vericador (pan). Realizaremos la edición y ejecución del entorno disponible en labo-
ratorio (Windows/Linux), teniendo en cuenta que todos los códigos son compatibles, independientemente de
la plataforma de trabajo.
El software Spin y toda la información disponible en http://spinroot.com/spin/whatispin.html
A partir de ahora, para trabajar con modelos Promela lo haremos a partir de una cuenta Linux y realizando un
acceso mediante terminal Telnet/SSH. Una vez hemos accedido a nuestro terminal, lo primero es comprobar
que Spin está correctamente instalado, además de comprobar la versión de software instalado:
$ spin -V
Spin Version 6.4.6 -- 2 December 2016
Los modelos Promela se codican en un chero con extensión .pml. Escribe y guarda el siguiente modelo
Hola Mundo y guárdalo en un chero nombre TusIniciales-Mundo.pml, por ejemplo, SAC-Mundo.pml.
Para la edición de cheros de texto disponemos de varias herramientas instaladas en el servidor: vi, vim, nano, emacs, etc.
1 /* --------------------------------------- */
2 /* mundo . pml */
3 /* --------------------------------------- */
4 /* Breve ejemplo de modelo en Promela */
5 /* --------------------------------------- */
6 active [3] proctype Hola () {
7 printf (" proceso Hola () , mi pid es : %d\n " , _pid );
8 }
9
10 init {
11 int ultimo_pid ;
12 printf ( " proceso init () , mi pid es : %d \n" , _pid );
13 ultimo_pid = run Hola () ;
14 printf ( " el ultimo pid fue : %d \n" , ultimo_pid );
15 }
Cuestión 1
Trata de explicar, de una forma concisa, qué hará la ejecución del modelo, cuántos procesos hay, de
qué tipo, etc.
LABORATORIO 3. INTRODUCCIÓN AL LENGUAJE PROMELA Y SPIN 73
Mediante la instrucción:
$ spin --
podremos comprobar multitud de opciones disponibles para el tratamiento, análisis y vericación de modelos
Promela. A la hora de abordar la validación de un modelo, el primer paso es ejecutar una simulación, que
consiste en un posible comportamiento del modelo. En este punto, genera varias simulaciones de mundo.pml,
comprobando que la salida de cada una de las simulaciones es diferente:
$ spin mundo . pml
Cuestión 2
A partir de las simulaciones anteriores, ¾qué conclusiones obtienes en cuanto a la generación y ejecución
de los diferentes procesos?, ¾por qué la salida proporcionada en las diferentes simulaciones es diferente?
Probablemente nos interese realizar una simulación interactiva del modelo, que como su nombre indica,
realizamos una interacción con el comportamiento de forma que nos permite tomar decisiones en cuanto a
las posibles transiciones del espacio de estados. Realiza una simulación interactiva mediante:
$ spin -i mundo . pml
Cuestión 3
Realiza una salida interactiva de 5 pasos. Aporta la salida del simulador.
Para evitar el no-determinismo, se utiliza el concepto de semilla de generador de números pseudo-aleatorios,

de forma que podemos repetir el mismo experimento utilizando la misma semilla, y por lo tanto, obtenemos
el mismo comportamiento del modelo.
Cuestión 4
Consigue realizar simulaciones exáctamente iguales, para ello deberás de aportar la semilla al simulador.
Nota : utiliza las opciones de simulador -h y -n.
La visualización gráca es muy útil para observar la evolución del modelo. La herramienta Spin permite
exportar la traza MSC a un chero gráco con formato TCL/TK (extensión .tcl). En la Figura 3.1 se
ilustra varias trazas de simulación del modelo en formato gráco.
Para obtener la salida gráca de la simulación del modelo en formato MSC, debemos utilizar la siguiente
instrucción, comprobando que se ha generado un chero gráco, denominado mundo.pml.tcl:
$spin -M mundo . pml
Figura 3.1: Varias trazas generadas en formato MSC.
Cuestión 5
Incorpora una traza MSC en formato gráco.
Figura 3.2: Traza MSC para 9 procesos Hola().
Cuestión 6
Modica el modelo de forma que se creen 9 procesos 'Hola()'. Genera y aporta la traza MSC del
modelo, que deberá ser, aleatoriamente similar, a la Figura 3.2.
Figura 3.3: MSC obtenida mediante los parámetros -n10 -u8.
En ocasiones es necesario obtener el comportamiento de un subconjunto de estados de simulación, de forma

que, con la opción −uN , provoca que el simulador se detenga después de N pasos de simulación.
Cuestión 7
Repite la simulación anterior con $spin -u8 -n10 -M mundo.pml. ¾Has obtenido el mismo resultado
que la Figura 3.3?
Hasta este momento, sólamente hemos simulado el modelo. Ahora, procederemos a la generación, compilación
y ejecución del vericador, para ello:
$ spin -a mundo . pml

$ gcc -o pan pan . c
$ ./ pan
( Spin Version 6.4.6 -- 2 December 2016)
+ Partial Order Reduction
Full statespace search for :

never claim - ( none specified )
assertion violations +
acceptance cycles - ( not selected )
invalid end states +
State - vector 92 byte , depth reached 22 , errors : 0

23 states , stored
0 states , matched
23 transitions (= stored + matched )
0 atomic steps
hash conflicts : 0 ( resolved )
Stats on memory usage ( in Megabytes ):

0.003 equivalent memory usage for states ( stored *( State - vector + overhead ))
0.292 actual memory usage for states
128.000 memory used for hash table (- w24 )
0.534 memory used for DFS stack ( - m10000 )
128.730 total actual memory usage
unreached in proctype Hola

(0 of 2 states )
unreached in init
(0 of 4 states )
pan : elapsed time 0.01 seconds

Cuestión 8
Habrás obtenido un resultado similar. Explica qué hemos hecho en cada uno de los pasos anteriores y
el resultado de cada instrucción
3.3. Acceso a sección crítica

En esta sección manejaremos los mecanismos de acceso a sección crítica con exclusión mutua mediante el uso
de semáforos y su implementación en Promela.
Una solución al problema de la exclusión mutua (mutex) fue publicado en 1966 por H. Hyman en Commu-
nications of ACM. A continuación, se muestra el código en pseudo Algol:
1 Boolean array b (0;1) integer k , i ,

2 comment process I , with I either 0 or 1 , and k = 1 -I;
3 C0 : b(i ) := false ;
4 C1 : if k != I then begin ;
5 C2 : if not b (1 - i) then goto C2 ;
6 else k := i; goto C1 end ;
7 else critical section ;
8 b(i ) := true ;
9 remainder of program ;
10 goto C0 ;
11 end
La solución propuesta por Dekker, es para dos procesos, numerados 0 y 1. A primera vista, la solución de
Hyman garantiza el acceso con exclusión mutua a la sección crítica. Para validar el modelo, construiremos el
siguiente modelo Promela de la solución de Dekker:
1 /* ------------------------------------ */
2 /* mutex . pml */
3 /* ------------------------------------ */
4 bool want [2]; /* bool array b */
5 bool turn ; /* integer k */
6 proctype P ( bool i ) {
7 want [ i] = 1;
8 do
9 :: ( turn != i) -> (! want [1 - i ]) ;
10 turn = i
11 :: ( turn == i ) -> break
12 od ;
13 skip ; /* start critical section */
14 skip ; /* critical section */
15 skip ; /* end critical section */
16 want [ i] = 0
17 }
18 init { run P (0) ; run P (1) }
Necesitamos demostrar la validez de la exclusión mutua a sección crítica (mutex), garantizando que sólo un
proceso tendrá acceso simultáneo a la sección crítica, en este caso, mediante el uso de semáforos.
La instrucción assert() se utiliza para la denición de invariantes, tanto local como global. Un invariante
local es cuando la comprobación se realiza de forma local de un proceso. En el caso de comprobación de
variables con invariante local, las variables pueden estar denidas sólamente en ámbito local, y por tanto,
reduciremos el número de estados.
Cuestión 9
Dene y valida la propiedad mutex mediante un invariante local. Deberás denir la propiedad a com-
probar dentro de la sección crítica. Aporta el código y la salida del vericador.
Cuestión 10
Si en el modelo anterior se ha violado la condición, se habrá generado un chero de traza (.trail).

Realizar una simulación guiada (parámetro -t) y utilizar la opción de visualización de sentencias (-p).
Aporta la salida y explica por qué se produce el error.
En la comprobación de propiedades mediante invariante global, se realiza la comprobación de la propiedad

en todo el espacio de estados, mediante un proceso 'monitor' entrelazado con el resto de proceso. Hay que
tener en cuenta que las variables a comprobar deben de ser de ámbito global.
Cuestión 11
Verica el modelo pero utilizando un invariante global. Aporta el modelo y la salida del vericador.
Finalmente, abordaremos la validación del modelo mediante LTL. Para la deninición de fórmulas LTL hay
que tener en cuenta las siguientes consideraciones:
1. La variable proposicional debe de estar denida de forma global en el modelo Promela.
2. La denición de la fórmula proposicional se realiza al principio del modelo, mediante un #define.

3. A partir de la versión 6, podemos incluir la LTL en el propio modelo, mediante la instrucción LTL (ver
apuntes de clase).
Cuestión 12
Dene la fórmula proposicional p=Acceso excluyente a sección crítica . Prueba la validez de ◻p y ◇p.
Razona los resultados.
La herraminta Spin , una vez efectuada la validación del modelo, proporciona una información relacionada
con el consumo de recursos (estados, memoria, tiempo) que nos da una idea del coste computacional necesario,
de forma que, en algunas ocasiones, hay que aplicar ciertos mecanismos de validación por la disponibilidad
limitada de recursos.
Cuestión 13
En relación al uso de recursos consumidos por cada uno de los métodos de validación utilizados,
completa la siguiente tabla:
Método Estados Transiciones Memoria

Invariante local
Invariante global
LTL
3.4. Instrucciones atómicas

En esta sección manejaremos los conceptos de entrelazado semántico e interacción entre procesos, así como
el uso de las instrucciones atomic{}.
Estados locales Estados globales: A ×B
(0,0)
a1 b1
0 0 (1,0) (0,1)
a2 b1 a1 b2
a1 b1
1 1 (2,0) (1,1) (0,2)

a3 b1 a2 b2 a1 b3
a2 b2
2 2 (3,0) (2,1) (1,2) (0,3)

b1 a3 b2 a2 b3 a1
a3 b3
3 3 (3,1) (2,2) (1,3)

b2 a3 b3 a2
(3,2) (2,3)
b3 a3
(3,3)
A partir de un modelo Promela sencillo, realizaremos los pasos de simulación, así como la obtención, compi-
lación y ejecución del vericador (pan). La ejecución del entorno se realizará sobre Linux, no obstante, todos
los fuentes e instrucciones son compatibles para la versión Windows (jSpin, xSpin o iSpin).
El código fuente que se aporta modela el comportamiento de 3 procesos asíncronos que realizan operaciones
aritméticas (sumas y restas) sobre una variable global x, de forma que debe cumplirse que 0 ≤ x ≤ 2:
1 /* -------------------------------------------- */
2 /* atomic . pml
3 /* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
4 /* Modelo Promela para comprobar si el valor */
5 /* la condicion 0 <= x <= 2 */
6 /* -------------------------------------------- */
7 int x = 0;
8
9 active proctype Inc () {
10 do
11 :: true -> if
12 :: x <2 ->
13 x=x +1
14 fi
15 od
16 }
17
18 active proctype Dec () {
19 do
20 :: true -> if
21 :: x >0 ->
22 x=x -1
23 fi
24 od
25 }
26
27 active proctype Reset () {
28 do
29 :: true -> if
30 :: x ==2 ->
31 x =0
32 fi
33 od
34 }
35
36 /* active proctype MiMonitor () { assert ( x >=0 && x <=2 ) } */
Fíjate que la línea #36 del modelo está comentada, por lo tanto, no tiene efecto alguno en el modelo.
Cuestión 14
A la vista del modelo, ¾crees que el valor de x estará siempre comprendido entre 0 y 2? Razona la
respuesta.
3.4.1. Simulación del modelo

1
En un primer acercamiento al modelo, realizaremos la simulación :
$ spin atomic . pml
Para cancelar un proceso, puedes utilizar CTRL-Z, aunque es más conveniente el uso de la instrucción kill <pid>.
Ahora vamos a utilizar algunos parámetros de Spin así como instrucciones de bash para inspeccionar la
simulación. Si queremos obtener una salida formateada por pantalla, así como el valor de las variables
globales (x es una variable global), pero al tratarse de bucles innitos, una vez más, el proceso no terminará
(realmente está procesando, pero no produce ninguna salida por pantalla).
$ spin -p -g atomic . pml
Para obtener la salida del simulador en formato paginado por pantalla debemos redirigir la salida por pantalla
a la instrucción less, que permitirá el avance/retroceso del terminal mediante los cursores:
$ spin -p -g atomic . pml | less
Ahora vamos a realizar una simulación controlada de los primeros 1000 transiciones, con visualización de
todas las sentencias y variables globales:
$ spin -p -g - u1000 atomic . pml
y nalmente, es muy útil la búsqueda de patrones con el comando grep, ejemplo, en el caso que necesitamos
buscar las ocurrencias x = −1:
$ spin -p -g - u1000 -h atomic . pml | grep " x = -1"
x = -1
x = -1
x = -1
x = -1
x = -1
x = -1
e incluso, podemos numerar las líneas de salida:
$ spin -p -g - u1000 -h atomic . pml | grep " x = -1" | nl

1 x = -1
2 x = -1
3 x = -1
4 x = -1
5 x = -1
6 x = -1
1 Hay que tener en cuenta que, aparentemente, el modelo no hace nada, y que continuará en ese estado indenidamente, ya
que es un modelo cíclico donde no hemos indicado ningún tipo de visualización.
Cuestión 15
Para comprobar el carácter no determinista, realiza una serie de 10 experimentos, con parámetro
-u1000. Completa la siguiente tabla:
Experimento Valor nal x nº veces x = −1

1
···
10
3.4.2. Validación del modelo

Para la validación del modelo vamos a incorporar el proceso MiMonitor() que contiene el invariante global,
eliminando el comentario de la línea 36, para la validación de la propiedad 0 ≤ x ≤ 2. A continuación,
generamos el validador:
$ spin -a atomic . pml

$ ./ pan
pan :1: assertion violated ((x >=0) &&( x <=2) ) ( at depth 21)
pan : wrote atomic . pml . trail
( Spin Version 6.4.6 -- 2 December 2016)

Warning : Search not completed


97 states , stored
96 states , matched
0 atomic steps
[...]
A la vista del resultado del validador comprobamos que se ha producido un error en la propiedad de validación
introducida en el modelo mediante un invariante. Cuando Spin encuentra un error de validación, genera
un chero traza con nombre <fichero>.pml.trail y que es utilizado en la simulación del tipo guided,
visualizando la secuencia de pasos desde el inicio hasta el paso de validación donde se ha generado el error.
Por lo tanto, realizamos una simulación guiada mediante:
$ spin - tatomic . pml . trail -p atomic . pml

using statement merging
1: proc 2 ( Reset :1) atomic . pml :29 ( state 1) [(1) ]
2: proc 1 ( Dec :1) atomic . pml :20 ( state 1) [(1) ]
3: proc 0 ( Inc :1) atomic . pml :11 ( state 1) [(1) ]
4: proc 0 ( Inc :1) atomic . pml :12 ( state 2) [(( x <2) )]
5: proc 0 ( Inc :1) atomic . pml :13 ( state 3) [x = (x +1) ]
7: proc 1 ( Dec :1) atomic . pml :21 ( state 2) [(( x >0) )]
8: proc 1 ( Dec :1) atomic . pml :22 ( state 3) [x = (x -1) ]
10: proc 0 ( Inc :1) atomic . pml :13 ( state 3) [ x = (x +1) ]
14: proc 1 ( Dec :1) atomic . pml :21 ( state 2) [(( x >0) ) ]
17: proc 2 ( Reset :1) atomic . pml :30 ( state 2) [(( x ==2) )]
18: proc 2 ( Reset :1) atomic . pml :31 ( state 3) [x = 0]
spin : atomic . pml :36 , Error : assertion violated
spin : text of failed assertion : assert ((( x >=0) &&( x <=2) ) )
22: proc 3 ( MiMonitor :1) atomic . pml :36 ( state 1) [ assert ((( x >=0) &&( x <=2) ))]
spin : trail ends after 22 steps
# processes : 4
x = -1
22: proc 3 ( MiMonitor :1) atomic . pml :36 ( state 2) < valid end state >
22: proc 2 ( Reset :1) atomic . pml :29 ( state 4)
22: proc 1 ( Dec :1) atomic . pml :20 ( state 4)
22: proc 0 ( Inc :1) atomic . pml :11 ( state 4)
4 processes created
El resultado de la traza nos muestra que la exploración del modelo ha alcanzado una profundidad total 22
pasos de validación (21 pasos en ejecución y 1 paso para mostrar el error). La información contenida en cada
paso de ejecución del validador es relativa a las instrucciones en estado ejecutable. Por ejemplo, en la Figura
3.4 se muestra un paso de ejecución de la traza obtenida, donde cada campo tiene el siguiente signicado:
● Paso de validación 10.
● El pid del proceso es 0.
● El nombre del procedimiento es Inc, y corresponde a la instancia 1.
● Corresponde a la línea 13 del modelo atomic.pml.

● Estado 3 de la FSM del proceso (Figura 3.5).
● Sentencia ejecutable: x = x + 1.
línea ejecutada sentencia

pid en el modelo ejecutada
10: proc 0 (Inc:1) atomic.pml:13 (state 3) [x = (x+1)]
paso de nombre de nº de estado

validación procedimiento
e instancia
Figura 3.4: Información contenida en cada paso de ejecución.
A la vista de la traza, podemos denir las FSMs de los procesos Inc(), Dec(), Reset() (Figura 3.5):
Si denimos ⟨Ix , Dx , Rx , Mx ⟩, donde Ix , Dx , Rx y Mx son los estados x en los procesos Inc(), Dec(), Reset()
y MiMonitor(), respectivamente, entonces podemos construir la tabla de transiciones del modelo, así como
el valor de x en cada estado (ver tabla 3.1):
Inc(): Dec(): Reset():
#11 ∶ I1 #20 ∶ D1 #29 ∶ R1

start true(1)
start true(1)
start true(1)
#12 ∶ I2 #21 ∶ D2 #30 ∶ R2

x<2 x>0 x == 2
#13 ∶ I3 #22 ∶ D3 #31 ∶ R3

x=x+1 x=x−1 x=0
Figura 3.5: FSM de los procesos Inc, Dec y Reset.
Paso Proceso Estado Global ⟨Ix , Dx , Rx , Mx ⟩ x

1 Reset() ⟨−, −, R1 , −⟩ 0
2 Dec() ⟨−, D1 , R1 , −⟩ 0
3 Inc() ⟨I1 , D1 , R1 , −⟩ 0
4 Inc() ⟨I2 , D1 , R1 , −⟩ 0
5 Inc() ⟨I3 , D1 , R1 , −⟩ 1
6 Inc() ⟨I1 , D1 , R1 , −⟩ 1
7 Dec() ⟨I1 , D2 , R1 , −⟩ 1
8 Dec() ⟨I1 , D3 , R1 , −⟩ 0
9 Inc() ⟨I2 , D3 , R1 , −⟩ 0
10 Inc() ⟨I3 , D3 , R1 , −⟩ 1
11 Inc() ⟨I1 , D3 , R1 , −⟩ 1
12 Inc() ⟨I2 , D3 , R1 , −⟩ 1
13 Dec() ⟨I2 , D1 , R1 , −⟩ 1
14 Dec() ⟨I2 , D2 , R1 , −⟩ 1
15 Inc() ⟨I3 , D2 , R1 , −⟩ 2
16 Inc() ⟨I1 , D2 , R1 , −⟩ 2
17 Reset() ⟨I1 , D2 , R2 , −⟩ 2
18 Reset() ⟨I1 , D2 , R3 , −⟩ 0
19 Reset() ⟨I1 , D2 , R1 , −⟩ 0
20 Dec() ⟨I1 , D3 , R1 , −⟩ -1
21 Dec() ⟨I1 , D1 , R1 , −⟩ -1
22 Dec() ⟨I1 , D1 , R1 , M1 ⟩ -1
Tabla 3.1: Tabla de transiciones del modelo.

Analizando la traza de error obtenido por el validador y la tabla resumen de los diferentes pasos de validador
(Tabla 3.1), llegamos a la conclusión del motivo del error:
... el procesoDec() ha evaluado la condición (#14 ∶ D2 , x > 0), pero antes de realizar la
Reset(), ha realizado las transiciones (#17 ∶ R2 , x == 2) y (#18 ∶ R3 , x = 0).
transición, el proceso
A continuación, Dec() realiza la transición (#20 ∶ D3 , x = x − 1), pero como Reset() hizo x = 0,
entonces tenemos que x = −1, violando la aserción denida en MiMonitor().
En la exploración de estados, al encontrar un error, detiene la exploracion. Por lo tanto, dependiendo del itinerario de
búsqueda, podría haber encontrado otro camino diferente.
3.4.3. Corrección del modelo

A la vista del resultado anterior, llegamos a la conclusión que el origen del problema reside en el denominado
entrelazado semántico de procesos. Las operaciones de guarda (evaluación de condición) y ejecución de
la acción no son atómicas, y por tanto, están entrelazadas con el resto de procesos del modelo.
Concretamente, en la traza anterior (con error), observamos el entrelazado de los procesos en los siguientes
pasos:
● 12 − 13: Evaluación de guarda (12) por parte de Inc() y transición (13) de Dec().
● 14 − 15: Evaluación de guarda (14) por parte de Dec() y transición (15) de Inc().
La corrección del modelo consiste en evitar el entrelazado mediante la atomicidad de instrucciones. Modica
el modelo, haciendo las operaciones de guarda y acción atómicas, por ejemplo, en los procesos Inc(), Dec()
y Reset(). Por ejemplo, en el caso del proceso Inc(), deberás hacer atómica la sentencia:
x<2 -> x=x+1

Si ahora simulamos el modelo:
$ spin -p - u30 atomic . pml

0: proc - (: root :) creates proc 0 ( Inc )
0: proc - (: root :) creates proc 1 ( Dec )
0: proc - (: root :) creates proc 2 ( Reset )
0: proc - (: root :) creates proc 3 ( MiMonitor )
1: proc 3 ( MiMonitor :1) atomic . pml :36 ( state 1) [ assert ((( x >=0) &&( x <=2) )) ]
5: proc 3 ( MiMonitor :1) terminates
9: proc 0 ( Inc :1) atomic . pml :15 ( state 5) [.( goto )]
10: proc 1 ( Dec :1) atomic . pml :24 ( state 5) [.( goto ) ]
11: proc 0 ( Inc :1) atomic . pml :16 ( state 7) [.( goto ) ]
14: proc 0 ( Inc :1) atomic . pml :12 ( state 2) [(( x <2) ) ]
19: proc 1 ( Dec :1) atomic . pml :21 ( state 2) [(( x >0) ) ]
23: proc 0 ( Inc :1) atomic . pml :12 ( state 2) [(( x <2) ) ]

28: proc 1 ( Dec :1) atomic . pml :22 ( state 3) [ x = (x -1) ]
29: proc 1 ( Dec :1) atomic . pml :24 ( state 5) [.( goto )]
30: proc 1 ( Dec :1) atomic . pml :25 ( state 7) [.( goto )]
-------------
depth - limit ( - u30 steps ) reached
# processes : 3
x = 0
30: proc 2 ( Reset :1) atomic . pml :29 ( state 4)
30: proc 1 ( Dec :1) atomic . pml :19 ( state 6)
30: proc 0 ( Inc :1) atomic . pml :15 ( state 5)
4 processes created
Donde observamos que se cumple la atomicidad de los procesos que hemos declarado en el modelo, es decir,
la evaluación de la guarda y la ejecución de la acción se realizan de forma atómica, sin permitir el entrelazado
con otros procesos. Los podemos observar en los pasos (columna de la izquierda): 3-4, 9-10, 11-12, 17-18,
24-25 y 28-29.
Para comprobar que el modelo es correcto en todo el espacio de estados, debemos de realizar la validación,
comprobando que el modelo ahora está libre de errores:
$ spin -a atomic . pml

$ ./ pan
hint : this search is more efficient if pan .c is compiled - DSAFETY
( Spin Version 6.2.7 -- 2 March 2014)



49 states , stored
65 states , matched
0 atomic steps
[...]
Cuestión 16
Valida el modelo incorrecto (sin instrucciones atómicas). Aporta la salida.
Cuestión 17
Valida el modelo correcto (con instrucciones atómicas). Aporta la salida.

3.4.4. Validación del modelo con LTL

Otra herramienta para la comprobación de propiedades de corrección es el uso de Lógica Lineal Temporal
(LTL), que permite la denición de fórmulas proposicionales en el vericador y su comprobación con alguna
de las operaciones temporales disponibles.
Cuestión 18
Mediante las instrucciones correspondientes Promela, dene e inserta en el modelo la proposición: P=x
está comprendido entre 0 y 2. Aporta el modelo.
Cada una de las propiedades de corrección se comprueba de forma independiente, es decir, sólo introduciremos el código
Promela corrrespondiente a cada propiedad, eliminando el código correspondiente a las otras propiedades. En este caso
caso, deberás haber eliminado del modelo las sentencias assert.
Cuestión 19
A partir del modelo incorrecto (sin instrucciones atomic), comprueba la validez de las fórmulas: ◻P
y ◇P . Aporta la denición de las fórmulas y la salida del vericador.
Cuestión 20
A partir del modelo correcto (con instrucciones atómicas), comprueba la validez de las fórmulas: ◻P
y ◇P . Aporta la denición de las fórmulas y la salida del vericador.
3.5. Evaluación de la complejidad

La validación de los modelos Promela se basa en la denominada búsqueda exhaustiva a partir del espacio de
estados generado. La herramienta Spin construye el espacio de estados del modelo, y realiza una búsqueda
detallada a lo largo de todo el espacio de estados. El tamaño del espacio de estados generado puede estar
limitado por los recursos computacionales utilizados (RAM), es por ello, que Spin proporciona diversas
opciones de optimización de búsqueda.
Como ya se ha visto anteriormente, a partir de las diferentes sentencias declaradas en un modelo Promela,
la herramienta Spin construye el espacio de estados para posteriormente realizar una búsqueda exhaustiva.
Utilizando algún editor de textos, crea el chero complejidad1.pml, con el siguiente código Promela:
1 /* ------------------------ */
2 /* complejidad1 . pml */
3 /* ------------------------- */
4 init {
5 byte i =0;
6
7 do
8 :: i ++
9 od
10 }
y ejecuta la simulación del modelo mediante la siguiente instrucción, comprobando que se produce una salida
innita, provocada por el bucle do..od:
$ spin -p -l complejidad1 . pml
Como no tenemos control del proceso hay que eliminarlo. Para ello, abre otra consola de linux, busca el
proceso que se está ejecutando y elimínalo mediante:
$ps -a
$kill -9 <pid >
Ahora vamos a realizar otra simulación, pero haciendo paginación a la salida:
$ spin -p -l complejidad1 . pml | less
entonces, ahora la salida proporcionada por el simulador tendrá el siguiente aspecto:
12796: proc 0 (: init ::1) complejidad1 . pml :11 ( state 3) [.( goto )]
12797: proc 0 (: init ::1) complejidad1 . pml :8 ( state 2) [i = (i +1) ]
: init :(0) : i = 255
spin : complejidad1 . pml :9 , Error : value (256 - >0 (8) ) truncated in assignment
: init :(0) : i = 0
: init :(0) : i = 1
: init :(0) : i = 2
Cuestión 21
A partir de la declaración de tipos del modelo y la salida del simulador, razona a qué es debido el error
producido.
Cuestión 22
A la vista de la información anterior, ¾cuántos estados crees que generará el vericador? ¾Qué relación
guarda el nº de estados y la denición de tipos, en el modelo anterior? ¾Cuántos estados deberá
inspeccionar la búsqueda exhaustiva? ¾Es un número nito o innito?
Nota: con confundir estado con sentencia.

Tipo Valor Tamaño (bits)

bit, bool 0, 1, false, true 1
byte 0, ⋯, 255 8
short −32768, ⋯, 32767 16
int −231 , ⋯, 231 − 1 32
unsigned 0, ⋯, 2n − 1 ≤ 32
Tabla 3.2: Tipos de datos Promela
Ahora vamos a realizar una vericación del modelo:

$ spin -a complejidad1 . pml
$ gcc -o pan pan .c
$ ./ pan
hint : this search is more efficient if pan . c is compiled - DSAFETY



256 states , stored
1 states , matched
0 atomic steps
[...]
Cuestión 23
A la vista de la salida del vericador y en relación al nº de estados stored, comenta el origen de estos
estados.
En este punto ya debemos de tener constancia que los estados generados están relacionados con la decla-
ración de tipos y el rango de representación en Promela (Tabla 3.2). Para analizar el efecto del rango de
representación sobre el conjunto de estados generados, cambia el tipo de dato de la variable i por short.
Vuelve a ejecutar el vericador, y en la salida debes de jarte en el mensaje de error que ha generado:
error : max search depth too small



10000 states , stored
1 states , matched
0 atomic steps
[...]
Tipo Estados generados Vector estado (bytes) Memoria utilizada para estados ¾Error? Caso error, explica el motivo
bool
byte
short
int
Tabla 3.3: Análisis tipos de datos básicos.
Cuestión 24
Trata de explicar el motivo del mensaje error: max search depth too small y su relación con el
nº de estados generado.
A la vista de lo anterior, ampliaremos la profundidad de búsqueda del vericador a una profundidad de 1

millón de estados mediante parámetro -m del vericador:
$ ./ pan - m1000000
Cuestión 25
Trata de explicar, brevemente, qué ha sucedido en el último vericador.
Como ya hemos detectado que el espacio de estados generado está directamente relacionado con el tipo de
datos utilizado, vamos a realizar una comparación entre los diferentes tipos básicos disponibles, y algunos
parámetros dle vericador.
Cuestión 26
A partir del modelo complejidad1.pml, genera y ejecuta el vericador para cada uno de los tipos básicos
disponibles, y completa la Tabla 3.3
S1 S3 S1 , []
!b
a b
!a
S2 , [a] S3 , [b]
a b b a
S2
S2 , [a, a] S3 , [a, b] S3 , [b, b] S2 , [b, a]
Figura 3.6: Máquina de estados y árbol de alcanzabilidad para N =2
3.5.1. Vector de estado

Ahora vamos a crear el chero complejidad2.pml con el siguiente código Promela:
1 /* ------------------------ */
2 /* complejidad2 . pml */
3 /* ------------------------- */
4 # define N 2
5 mtype ={a ,b}
6
7 init {
8 chan dummy =[ N] of { mtype }
9 do
10 :: dummy ! a
11 :: dummy ! b
12 od
13 }
En la Figura 3.6 vemos el Diagrama de estados y el Árbol alcanzabilidad del modelo complejidad2.pml. La
máquina de estados muestra las transiciones dependiendo de los mensajes enviados al canal, y en el árbol de
alcanzabilidad se muestran, para N = 2, todos los posibles estados alcanzables, y el contenido del canal. El
árbol de alcanzabilidad debe de coincidir con el vericador del modelo. Para realizar la vericación:
$ spin -m -a complejidad2 . pml # use -m to ignore buffer overflow

$ ./ pan
Se ha utilizado la opción -m, lose msgs sent to full queues, para evitar errores de vericador por cola llena.
Cuestión 27
A partir de la máquina de estados, árbol de alcanzabilidad (Figura 3.6) y la salida proporcionada por
el vericador, en relación al nº de estados generados (stored ), explica, brevemente, el origen de los
estados generados.
La tabla Hash (Figura 3.7) es una estructura de datos (tipo conjunto ) utilizada por Spin para el manejo en
memoria del diagrama de estados generado por el modelo, y por tanto, depende del modelo y de los recursos
físicos (memoria). El parámetro -wX del vericador establece el tamaño de tabla hash, que determina un
tamaño de 2X posiciones. Por defecto, Spin establece un determinado tamaño de tabla Hash.
Hash (acceso indexado-rápido) w bits

00···000 00···001 00···010 00···011 11···110 11···111
0 1 2 3
··· 2w-2 2w-1
5,12,1,1 5,11,1,0 6,7,0,0
vector
de estado 4,12,0,1
conflicto:
lista enlazada
2,10,1,1 (acceso secuencial-lento)
Figura 3.7: Tabla hash.
Cuestión 28
A partir del último resultado del vericador, ¾cuál es tamaño de tabla Hash establecido por defecto
por Spin?
A partir del modelo anterior (complejidad2.pml ), vamos a buscar una expresión que nos relacione el números
de estados generados (S) en función del nº de elementos permitidos en el canal (N ). Para ello genera
vericadores para N = 2, 3, 4, ⋯. Puedes comprobar que con la expresión buscada corresponde a :
S = 2N +1 − 1 (3.1)
Parámetro Unidades Descripción

T seg Tiempo de vericación
S estados Nº de estados stored
G estados Nº total de estados generados y analizados
V bytes Tamaño del vector de estado (cantidad de memoria para almacenar un estado)
E estados/seg Tasa de procesamiento de estados
H bytes Tamaño de la tabla Hash
M bytes Cantidad de memoria requerida (M ) para almacenar el espacio de estados sin
utilizar compresión, y denida por M =S∗V
Tabla 3.4: Parámetros de rendimiento.

w H T S G V E M conictos
24 128 ≈0 15 31 21 - 315 0
Tabla 3.5: Resumen datos rendimiento para w = 24.
Con el objeto de analizar los parámetros de rendimiento en la vericación y su relación con la complejidad de
los modelos, vamos a considerar los parámetros denidos en la Tabla 3.4. Estableciendo en el modelo anterior
N =3 y ejecutando el vericador con las instrucciones, obtenemos, de forma resumida, los datos de la Tabla
3.5:
$ spin -m -a complejidad2 . pml # use -m to ignore buffer overflow

$ gcc -o pan pan .c
$ ./ pan

State - vector 21 byte , depth reached 3, errors : 0

15 states , stored
16 states , matched
0 atomic steps
16 lost messages

unreached in init
complejidad2 . pml :8 , state 6, " -end -"
(1 of 6 states )
pan : elapsed time 0 seconds
Cuestión 29
Utilizando en el modelo anterior, con N = 14, genera y ejecuta los vericadores para diferentes tamaños
de tabla hash wi ∈ {15, 20, 24, 26, 28}, completando un cuadro resumen similar a la Tabla 3.5. Comenta
los resultados.
3.5.2. Tamaño del árbol de estados

Vamos a poner de maniesto las limitaciones físicas (RAM) en la búsqueda en espacios de estados muy
extensos.
Cuestión 30
Estableciendo N = 20, y considerando que la cantidad de estados alcanzables y el vector de estado se

incrementan con N , suponiendo que para N = 20, tenemos un vector de estado (V ) de 30 bytes, y
suponiendo una memoria RAM de 8 Megabytes, ¾calcula qué fracción máxima de espacio de estados
se podrá analizar?
En el caso de limitación de memoria que impide realizar una vericación completa (exhaustiva) se utiliza la
opción de supertraza con el parámetro DBITSTATE. La vericación por supertraza explora todos los estados
posibles sin realizar paginación.
La paginación provoca el swaping de memoria RAM lo que conlleva una caída del rendimiento y posiblemente la imposibilidad
de su vericación.
Establece N = 20 en el modelo y realiza la vericación con las opciones DBITSTATE y -w23, obteniendo el
siguiente resultado:
$ spin -m -a complejidad2 . pml

$ gcc - DBITSTATE -o pan pan . c
$ ./ pan - w23
Depth = 20 States = 1e +06 Transitions =2 e +06 Memory =1.730 t= 1.6 R= 6e +05

Bit statespace search for :


1254646 states , matched
0 atomic steps
1.23684 e +06 lost messages
hash factor : 6.68604 ( best if > 100.)
bits set per state : 3 (- k3 )
[...]
Si has realizado el cálculo teórico de estados alcanzables a partir de la expresión 3.1 debes de haber obtenido
que son necesarios 2097151 estados alcanzables para N = 20.
La memoria total consumida incluye el vector de estados, pila, tabla hash y otras estructuras de datos.
Cuestión 31
¾Qué porcentaje de estados visitados sobre el total de generados has obtenido con la vericación anterior
utilizando -DBITSTATE? ¾Cuánta memoria se ha utilizado?
Realiza otra vericación del modelo anterior, con máxima cobertura (sin bitstate ) y tamaño de tabla hash de
221 bits. El resultado será:

Depth = 20 States = 1e +06 Transitions = 2e +06 Memory = 70.147 t= 1.79 R =6 e +05



0 atomic steps
[...]
Para exploraciones en espacios de estados extremadamente grandes, Spin proporciona datos parciales por cada millón de
estados visitados.
Cuestión 32
Comenta y compara los resultados de las dos últimas vericaciones.
En el modo bit-state, se establece por defecto -w27, es decir, 227 bits ≈ 16 MBytes. Repite la simulación con
una cantidad diferente de memoria para conseguir diferentes coberturas de estados. Comprueba el porcentaje
de estados alcanzado, para una memoria de 8 Megabytes y una memoria utilizada de 226 bits (-w26). Con
estas opciones se debe de utilizar entorno al 99 % de cobertura. Para ello, utiliza las siguientes instrucciones,
obteniendo la salida:
$ spin -m -a complejidad2 . pml

$ gcc - DBITSTATE -o pan pan . c
$ ./ pan - w26


Bit statespace search for :



0 atomic steps
hash factor : 32.0582 ( best if > 100.)
bits set per state : 3 (- k3 )

[...]
Cuestión 33
Comenta el resultado de la última vericación: estados recorridos, porcentaje de estados necesarios,

memoria utilizada, profundidad búsqueda, tamaño tabla hash, vector de estado, etc.
Cuestión 34
3.6. Informe
AT X

Laboratorio 4
Especicación y validación de ABP en

Promela
SPIN
Errores de
sintaxis .pml.trail
Analizador contra-ejemplo
.pml Simulación
Promela
Modelo de cc Verificador
Generar
validación pan.c
verificador Ejecutable
Analizador
LTL
97
98 LABORATORIO 4. ESPECIFICACIÓN Y VALIDACIÓN DE ABP EN PROMELA
4.1. Objetivos
Realizar la especicación de ABP (Alternating Bit Protocol ) en Promela y validación con la herramienta
Spin .
4.2. Especicación del sistema
Sender Receiver
Lower layer
Figura 4.1: Procesos en ABP.
1
Suponemos la siguiente especicación de ABP (Figura 4.1):
● Formado por los procesos Sender y Receiver conectados a través de un medio de transmisión (proceso
Lower_Layer ).
● El medio de transmisión se supone no conable: los mensajes pueden ser alterados (distorsionados),
pero nunca desordenados ni perdidos.
● Si un mensaje alcanza el destino de forma satisfactoria, el dispositivo receptor conrma la recepción

del mensaje.
● Por el contrario, si un mensaje llega erróneo o con el bit de control incorrecto, el receptor responde con
la conrmación del último mensaje aceptado.
● Si el emisor recibe una conrmación satisfactoria, alterna el bit y envía el siguiente mensaje.
El protocolo debe asegurar la entrega correcta de mensajes, reenviando mensajes errónesos y

asegurando que no se aceptan mensajes duplicados.
1 [G. J. Holzmann: " Design and validation of protocols: a tutorial ", Computer Networks and ISDN Systems, 25(9), 1993.]
LABORATORIO 4. ESPECIFICACIÓN Y VALIDACIÓN DE ABP EN PROMELA 99
4.3. Especicación de procesos

En primer lugar, vamos a especicar los procesos que intervienen en el modelo, así como los canales de
comunicación.
4.3.1. Lower Layer

El proceso Lower_Layer modela el intercambio de mensajes entre emisor y receptor mediante un medio no
conable, donde los mensajes pueden ser alterados, pero nunca perdidos ni desordenados. El intercambio de
mensajes se realizará mediante los canales denidos fromS, toS, fromR y toR (Figura 4.2).
fromS toS fromR toR
Lower Layer
Figura 4.2: Canales en ABP.
La especicación de canal viene dado en el siguiente código Promela :
mtype = { data , ack }
proctype Lower_Layer ( chan fromS , toS , fromR , toR )

{ byte d;
bit b;
do
:: fromS ? data (d ,b) -> toR ! data (d ,b )
:: fromR ? ack (b ) -> toS ! ack (b)
od
}
Y la denición de canales:
# define N 1
chan fromS = [N] of { mtype , byte , bit }
chan toR = [N] of { mtype , byte , bit }
chan fromR = [N] of { mtype , bit }
chan toS = [N] of { mtype , bit }
Añadiendo la no conabilidad
Para incorporar la característica de no conabilidad, el proceso Lower_Layer debe ser denido de la siguiente
forma:
mtype = { data , ack , error }

{ byte d;
bit b;
do
:: fromS ? data (d ,b) ->
if
:: toR ! data (d , b) /* correct */
:: toR ! error /* corrupted */
fi
:: fromR ? ack (b ) ->
if
:: toS ! ack (b) /* correct */
:: toS ! error /* corrupted */
fi
od
}
donde hemos añadido aleatoriedad en la retransmisión de mensajes por parte del canal en ambos sentidos:
puede retransmitir el mensaje que ha recibido o puede, de forma no-determinista, enviar un mensaje error.
Nota: al incluir un tipo nuevo en los canales, hemos añadido a error a la denición de tipos de canal.
Lower_Layer
fromS?data,d,b S11 toS!error,0
toR!data,d,b toS!ack,b
toR!error,0,0
S4 fromR?ack,b S9
Figura 4.3: Proceso Lower_Layer.
2
La FSM del proceso Lower_Layer está especicada en la Figura 4.3.
4.3.2. Proceso Sender

El código Promela que modela el proceso Sender viene especicado en:
proctype Sender ( chan cin , cout )

{ byte mt ; /* message data */
bit at ; /* alternation bit transmitted */
bit ar ; /* alternation bit received */
FETCH ; /* get a new message */

cout ! data (mt , at ); /* ... and send it */
do
:: cin ? ack ( ar ) -> /* await response */
if
:: ( ar == at ) -> /* successful transmission */
FETCH ; /* get a new message */
at =1 - at /* toggle alternating bit */
:: else -> /* there was a send error */
skip /* don 't fetch a new msg . */
fi ;
cout ! data (mt , at )
:: cin ? error ( ar ) -> /* receive error */
cout ! data (mt , at ) /* simply send again */
od
}
donde suponemos que la sentencia FETCH modela el envío de datos mediante una secuencia de enteros módulo
MAX para limitar el tamaño del campo.
# define MAX 8
# define FETCH mt = ( mt +1) % MAX
La FSM del proceso Sender está especicada en la Figura 4.4.
2 Las FSM han sido obtenidos mediante la herramienta Graphviz a partir de la exportación a formato .dot de los modelos en
Spin .
Sender S1
mt = ((mt+1)%8)
S2
cout!data,mt,at
cin?ack,ar S14
cin?error,ar
cout!data,mt,at
S9 S13
else
((ar==at)) S8
(1) cout!data,mt,at
S11
Figura 4.4: Proceso Sender.

4.3.3. Proceso Receiver

El código Promela que modela el proceso Receiver viene especicado en:
proctype Receiver ( chan cin , cout )

{ byte mr ; /* message data received */
byte last_mr ; /* mr of last error - free msg */
bit last_ar ; /* ar of last error - free msg */
do
:: cin ? error (mr , ar ) -> /* receive error */
cout ! ack ( last_ar ); /* send ack with old bit */
:: cin ? data (mr , ar ) ->
cout ! ack ( ar ); /* send response */
if
:: ( ar == last_ar ) -> /* bit is not alternating */
skip /* ... don 't accept */
:: ( ar != last_ar ) -> /* bit is alternating */
ACCEPT ; /* correct message */
last_ar = ar ; /* store alternating bit */
last_mr = mr /* save last message */
fi
od
}
Siendo necesario denir:
# define ACCEPT assert ( mr == ( last_mr +1) % MAX )
Receiver S14
cin?error,mr,ar
cin?data,mr,ar
cout!ack,last_ar
S2 S4 ((ar!=last_ar))
(1)
cout!ack,ar
S12
((ar==last_ar))
S6
Figura 4.5: Proceso Receiver.
La FSM del proceso Receiver está especicada en la Figura 4.5.
4.3.4. Proceso init

En proceso init queda denido de la siguiente forma:
init {
atomic {
run Sender ( toS , fromS );
run Receiver ( toR , fromR );
run Lower_Layer ( fromS , toS , fromR , toR )
}
}
init S4
(run Sender(toS,fromS))
S2
(run Receiver(toR,fromR))
S3
(run Lower_Layer(fromS,toS,fromR,toR))
S5
-end-
S0
Figura 4.6: Proceso Init.
La FSM del proceso Init está especicada en la Figura 4.6.

4.3.5. Modelo ABP

El código Promela que modela ABP quedaría nalmente :
3
1 /* --------------------------------------------------------- */
2 /* - ABP ( Alternating Bit Protocol ) - */
3 /* --------------------------------------------------------- */
4 /* Ingenieria de Protocolos */
5 /* Grado en Ingenieria de Tecnologias de la Telecomunicacion */
6 /* UMH */
7 /* --------------------------------------------------------- */
8 /* Holzmann G., Design and Validation of Computer Protocols */
9 /* Prentice - Hall , 1991 */
10 /* --------------------------------------------------------- */
11 /* Correccion de ciclos progresivos e invariante */
12 /* --------------------------------------------------------- */
13 /* abp . pml */
14 /* --------------------------------------------------------- */
15
16 # define N 1
17 # define MAX 8
18 # define FETCH mt = ( mt +1) % MAX
19 # define ACCEPT assert ( mr == ( last_mr +1) % MAX )
20
21 mtype = { data , ack , error }
22
23 proctype Lower_Layer ( chan fromS , toS , fromR , toR )
24 { byte d;
25 bit b;
26
27 do
28 :: fromS ? data (d ,b ) ->
29 if
30 :: toR ! data (d ,b) /* correct */
31 :: toR ! error /* corrupted */
32 fi
33 :: fromR ? ack ( b) ->
34 if
35 :: toS ! ack (b ) /* correct */
36 :: toS ! error /* corrupted */
37 fi
38 od
39 }
40
41 proctype Sender ( chan cin , cout )
42 { byte mt ; /* message data */
43 bit at ; /* alternation bit transmitted */
44 bit ar ; /* alternation bit received */
45
46 FETCH ; /* get a new message */
47 cout ! data ( mt , at ); /* ... and send it */
48
49 do
50 :: cin ? ack ( ar ) -> /* await response */
51 if
52 :: ( ar == at ) -> /* successful transmission */
54 at =1 - at /* toggle alternating bit */
55 :: else -> /* there was a send error */
56 skip /* don 't fetch a new msg . */
57 fi ;
58 cout ! data (mt , at )
59 :: cin ? error ( ar ) -> /* receive error */
60 cout ! data (mt , at ) /* simply send again */
61 od
62 }
63
64 proctype Receiver ( chan cin , cout )
65 { byte mr ; /* message data received */
66 byte last_mr ; /* mr of last error - free msg */
68 bit last_ar ; /* ar of last error - free msg */
3A partir de este punto, suponemos que el chero abp.pml contiene el modelo Promela para ABP.
69
70 do
71 :: cin ? error ( mr , ar ) -> /* receive error */
72 cout ! ack ( last_ar ); /* send ack with old bit */
73 :: cin ? data (mr , ar ) ->
74 cout ! ack ( ar ); /* send response */
75 if
76 :: ( ar == last_ar ) -> /* bit is not alternating */
77 skip /* ... don ' t accept */
78 :: ( ar != last_ar ) -> /* bit is alternating */
79 ACCEPT ; /* correct message */
80 last_ar = ar ; /* store alternating bit */
81 last_mr = mr /* save last message */
82 fi
83 od
84 }
85
86 init {
87 chan fromS = [N ] of { mtype , byte , bit }
88 chan toR = [N ] of { mtype , byte , bit }
89 chan fromR = [N ] of { mtype , bit }
90 chan toS = [N ] of { mtype , bit }
91
92 atomic {
93 run Sender ( toS , fromS );
94 run Receiver ( toR , fromR ) ;
95 run Lower_Layer ( fromS , toS , fromR , toR )
96 }
97 }
Cuestión 1
Explica el modelo ABP anterior. Ayúdate de los números de línea para la descripción del modelo.
4.4. Manejo de modelos Promela

A partir de un modelo especicado en Promela , mediante la herramienta Spin realizamos las tareas de
simulación, vericación y validación. Para visualizar las diferentes opciones de Spin :
spin --
use : spin [ - option ] ... [- option ] file
Note : file must always be the last argument
-A apply slicing algorithm
-a generate a verifier in pan .c
-B no final state details in simulations
-b don 't execute printfs in simulation
-C print channel access info ( combine with -g etc .)
-c columnated -s -r simulation output
-d produce symbol - table information
- Dyyy pass - Dyyy to the preprocessor
- Eyyy pass yyy to the preprocessor
-e compute synchronous product of multiple never claims ( modified by -L)
-f ".. formula .." translate LTL into never claim
-F file like -f , but with the LTL formula stored in a 1- line file
-g print all global variables
-h at end of run , print value of seed for random nr generator used
-i interactive ( random simulation )
-I show result of inlining and preprocessing
-J reverse eval order of nested unlesses
-jN skip the first N steps in simulation trail
-k fname use the trailfile stored in file fname , see also -t
-L when using -e , use strict language intersection
-l print all local variables
-M generate msc - flow in tcl / tk format
-m lose msgs sent to full queues
-N fname use never claim stored in file fname
-nN seed for random nr generator
-O use old scope rules ( pre 5.3.0)
-o1 turn off dataflow - optimizations in verifier
-o2 don 't hide write - only variables in verifier
-o3 turn off statement merging in verifier
-o4 turn on rendezvous optiomizations in verifier
-o5 turn on case caching ( reduces size of pan .m , but affects reachability reports )
-o6 revert to the old rules for interpreting priority tags ( pre version 6.2)
-o7 revert to the old rules for semi - colon usage ( pre version 6.3)
- Pxxx use xxx for preprocessing
-p print all statements
-pp pretty - print ( reformat ) stdin , write stdout
-qN suppress io for queue N in printouts
-r print receive events
- replay replay an error trail - file found earlier
if the model contains embedded c - code , the ./ pan executable is used
otherwise spin itself is used to replay the trailfile
note that pan recognizes different runtime options than spin itself
- search ( or - run ) generate a verifier , and compile and run it
options before - search are interpreted by spin to parse the input
options following a - search are used to compile and run the verifier pan
valid options that can follow a - search argument include :
- bfs perform a breadth - first search
- bfspar perform a parallel breadth - first search
- bcs use the bounded - context - switching algorithm
- bitstate or -bit , use bitstate storage
- biterate use bitstate with iterative search refinement (- w18 .. - w35 )
- swarmN ,M like - biterate , but running all iterations in parallel
perform N parallel runs and increment -w every M runs
default value for N is 10 , default for M is 1
- link file .c link executable pan to file . c
- collapse use collapse state compression
-hc use hash - compact storage
- noclaim ignore all ltl and never claims
- p_permute use process scheduling order random permutation
- p_rotateN use process scheduling order rotation by N
- p_reverse use process scheduling order reversal
- ltl p verify the ltl property named p
- safety compile for safety properties only
-i use the dfs iterative shortening algorithm
-a search for acceptance cycles
-l search for non - progress cycles

similarly , a -D ... parameter can be specified to modify the compilation
and any valid runtime pan argument can be specified for the verification
-S1 and - S2 separate pan source for claim and model
-s print send events
-T do not indent printf output
-t[N] follow [ Nth ] simulation trail , see also -k
- Uyyy pass - Uyyy to the preprocessor
-uN stop a simulation run after N steps
-v verbose , more warnings
-w very verbose ( when combined with -l or -g)
-[ XYZ ] reserved for use by xspin interface
-V print version number and exit
En primer lugar, realizaremos un análisis sintáctico del modelo. Una vez detectados y subsanados todos los
errores sintácticos, el resultado debe ser similar a:
$ spin abp . pml

spin : abp . pml :79 , Error : assertion violated
spin : text of failed assertion : assert (( mr ==(( last_mr +1) %8)))
# processes : 4
61: proc 3 ( Lower_Layer :1) abp . pml :34 ( state 9)
61: proc 2 ( Receiver :1) abp . pml :79 ( state 8)
61: proc 1 ( Sender :1) abp . pml :49 ( state 14)
61: proc 0 (: init ::1) abp . pml :97 ( state 5) < valid end state >
4 processes created
y si realizamos diferentes ejecuciones, obtendremos resultados distintos, por ejemplo:
$ spin abp . pml

# processes : 4
4 processes created
$ spin abp . pml

# processes : 4
4 processes created
Cuestión 2
Aparte del error obtenido, que más adelante lo trataremos, se están obteniendo diferentes resultados
en la simulación, ¾a qué crees que es debido?
Antes de continuar con el análisis y para mejorar salida del simulador, vamos a imprimir el contenido del
mensaje de forma que facilita la visualización, para ello, sustituye la línea 19 por el siguiente segmento de
código:
1 # define ACCEPT printf (" ACCEPT \ %d \n" , mr ); assert ( mr == ( last_mr +1) % MAX )
Para reproducir experimentos y obtener la misma secuencia de mensajes, es necesario establecer un valor de
semilla, mediante el parámetro -n del simulador. Por ejemplo, estableciendo un valor de semilla 3 y opción
de visualización (-c) para texto columnado:
$ spin -n3 -c abp . pml

proc 0 = : init :
proc 1 = Sender
proc 2 = Receiver
proc 3 = Lower_Layer
q\ p 0 1 2 3
1 . cout ! data ,1 ,0
1 . . . fromS ? data ,1 ,0
2 . . . toR ! error ,0 ,0
8: warning : missing params in send
2 . . cin ? error ,0 ,0
3 . . cout ! ack ,0
3 . . . fromR ? ack ,0
4 . . . toS ! error ,0
4 . cin ? error ,0
1 . cout ! data ,1 ,0
1 . . . fromS ? data ,1 ,0
2 . . . toR ! error ,0 ,0
2 . . cin ? error ,0 ,0
3 . . cout ! ack ,0
3 . . . fromR ? ack ,0
4 . . . toS ! ack ,0
4 . cin ? ack ,0
1 . cout ! data ,2 ,1
1 . . . fromS ? data ,2 ,1
2 . . . toR ! error ,0 ,0
2 . . cin ? error ,0 ,0
3 . . cout ! ack ,0
3 . . . fromR ? ack ,0
4 . . . toS ! ack ,0
4 . cin ? ack ,0
1 . cout ! data ,2 ,1
1 . . . fromS ? data ,2 ,1
2 . . . toR ! data ,2 ,1
2 . . cin ? data ,2 ,1
3 . . cout ! ack ,1
3 . . . fromR ? ack ,1
4 . . . toS ! error ,0
4 . cin ? error ,0
1 . cout ! data ,2 ,1
ACCEPT 2
-------------
final state :
-------------
# processes : 4
4 processes created
Y podemos focalizar la simulación en la actividad de los canales mediante la opción -r:

$ spin -n3 -r abp . pml
6: proc 3 ( Lower_Layer :1) abp . pml :13 Recv data ,1 ,0 <- queue 1 ( fromS )
9: proc 2 ( Receiver :1) abp . pml :56 Recv error ,0 ,0 <- queue 2 ( cin )
14: proc 3 ( Lower_Layer :1) abp . pml :18 Recv ack ,0 <- queue 3 ( fromR )
18: proc 1 ( Sender :1) abp . pml :44 Recv error ,0 <- queue 4 ( cin )
29: proc 1 ( Sender :1) abp . pml :35 Recv ack ,0 <- queue 4 ( cin )
48: proc 1 ( Sender :1) abp . pml :35 Recv ack ,0 <- queue 4 ( cin )
60: proc 2 ( Receiver :1) abp . pml :58 Recv data ,2 ,1 <- queue 2 ( cin )
66: proc 1 ( Sender :1) abp . pml :44 Recv error ,0 <- queue 4 ( cin )
ACCEPT 2
# processes : 4
4 processes created
Y otra opción útil es la generación de un traza MSC en formato TCL/TK, mediante la opción -M, obteniendo
la imagen de la Figura 4.7:
$ spin -n3 -M abp . pml

spin : wrote 1 pages into ' abp . pml . ps '
Ahora nos vamos a ocupar del error detectado por el simulador. En primer lugar, observamos que el primer
mensaje aceptado es el 2, por lo tanto, debemos de plantear la siguiente cuestión: ¾dónde está el mensaje nº
1?
El problema está en la inicialización: last_ar == ar en la primera ejecución. Si esperamos recibir un msg

con bit 0, y por lo tanto, debemos conrmar con un ack 0, el último mensaje libre de error tenía que haber
sido bit 1 (Figura 4.8). Por lo tanto, es necesario inicialiar last_ar=1 (Figura 4.9).
Figura 4.7: Traza MSC en formato TCL/TK.

proctype Receiver(chan cin, cout)

{ byte mr; /* message data received */
byte last_mr; /* mr of last error-free msg */
bit ar; /* alternation bit received */
bit last_ar; /* ar of last error-free msg */
do
:: in ? error(mr,ar) ->
out ! ack(last_ar);
:: in ? data(mr,ar) ->
...
}
Figura 4.8: Inicialización incorrecta.
proctype Receiver(chan cin, cout)

{ byte mr; /* message data received */
byte last_mr; /* mr of last error-free msg */
bit ar; /* alternation bit received */
bit last_ar=1; /* ar of last error-free msg */
do
:: in ? error(mr,ar) ->
out ! ack(last_ar);
:: in ? data(mr,ar) ->
...
}
Figura 4.9: Inicialización correcta.

Una vez realizadas las modicaciones oportunas, se obtiene una traza correcta y la aserción no se viola, como
podemos observar en la traza en formato texto (a continuación) y en la traza en formato MSC (Figura 4.10).
$ spin - n11 - u55 -c abp . pml 1 . . . fromS ? data ,2 ,1

proc 0 = : init : 2 . . . toR ! data ,2 ,1
proc 1 = Sender 2 . . cin ? data ,2 ,1
proc 2 = Receiver 3 . . cout ! ack ,1
proc 3 = Lower_Layer 3 . . . fromR ? ack ,1
q\p 0 1 2 3 ACCEPT 2
1 . cout ! data ,1 ,0 4 . . . toS ! error ,0
1 . . . fromS ? data ,1 ,0 40: warning : missing params in send
2 . . . toR ! data ,1 ,0 4 . cin ? error ,0
2 . . cin ? data ,1 ,0 1 . cout ! data ,2 ,1
3 . . cout ! ack ,0 1 . . . fromS ? data ,2 ,1
ACCEPT 1 2 . . . toR ! error ,0 ,0
3 . . . fromR ? ack ,0 52: warning : missing params in send
4 . . . toS ! ack ,0 2 . . cin ? error ,2 ,1
4 . cin ? ack ,0 [...]
1 . cout ! data ,2 ,1
Figura 4.10: Simulación correcta.

4.5. Vericación del modelo

Hasta ahora hemos realizado simulaciones. Por la propia denición del modelo, se trata de simulaciones
aleatorias, y por lo tanto, no tenemos certeza de haber explorado todo el espacio de estados del sistema, es
decir, no tenemos la certeza de que han sido recorridos todos los posibles comportamientos.
Para generar del vericador a partir del modelo utilizamos la opción -a:
$ spin -a abp . pml
que en el caso que el código fuente esté libre de errores, habrá construído un vericador en lenguaje C,
denominado pan.c. A partir del código C, debemos de compilar para obtener el vericador ejecutable:
$ cc -o pan pan .c
de forma que habremos obtenido un ejecutable pan. Ya estamos en condiciones de ejecutar el vericador y
obtener el resultado de la vericación:
$ ./ pan
pan :1: too few parameters in send stmnt ( at depth 86)
pan : wrote abp . pml . trail



86 states , stored
1 states , matched
2 atomic steps

pan : elapsed time 0.01 seconds
El resultado del vericador nos muestra que se ha producido un error de vericación, y por defecto, genera
una traza del modelo hasta el error (depth 86 ) y, en este caso, lo ha guardado en el archivo abp.pml.trail.
Para inspeccionar el error, podemos realizar una simulación de la traza errónea en el entorno de error, por
ejemplo, podría ser útil saltar los primeros estados de simulación para visualizar el estado donde el error ha
sido generado, por ejemplo, si saltamos los 80 primeros pasos con el parámetro -k, tenemos:
$ spin -c - j80 -k abp . pml . trail abp . pml

proc 0 = : init :
proc 1 = Sender
proc 2 = Receiver
proc 3 = Lower_Layer
ACCEPT 0
q\p 0 1 2 3
3 . . . fromR ? ack ,1
4 . . . toS ! ack ,1
4 . cin ? ack ,1
1 . cout ! data ,1 ,0
1 . . . fromS ? data ,1 ,0
2 . . . toR ! error ,0 ,0
-------------
final state :
-------------
# processes : 4
4 processes created
y comprobamos que el error está en la sentencia de enviar a canal, concretamente, hay un error al faltar los
parámetros en la instrucción. Por denición, cuando un mensaje erróneo alcanza un dispositivo (emisor o
receptor), independientemente de los parámetros, se retransmite lo anterior. En este caso, no es un error de
modelo, pero si es dectectado por el vericador (realmente, en la fase de simulación también se reconocido
como warning ). La solución que adoptamos es poner los parámetros a 0 (Figura 4.11).
ABP
proctype lower_layer(chan fromS, toS, fromR, toR)
{ byte d; bit b;
do
:: fromS?data(d,b) ->
if
:: toR ! data(d,b) /* correct */
:: toR ! error(0,0) /* corrupted */
fi
::fromR?ack(b) ->
if
:: toS ! ack(b) /* correct */
:: toS ! error(0) /* corrupted */
fi
od
}
Figura 4.11: Parámetros en mensaje error.
Una vez realizadas las modicaciones, volvemos a obtener el vericador comprobando que el modelo está
libre de error:
$ spin -a abp . pml
$ cc -o pan pan . c
$ ./ pan


510 states , stored
2 atomic steps
[...]
4.5.1. Ciclos no progresivos

Las propiedades de corrección que queremos validar son:
1. Cada mensaje es recibido una sóla vez (ya ha sido vericado mediante el assert del modelo).
2. Cada mensaje es aceptado como máximo una vez.
Pero, en primer lugar, vamos a realizar una búsqueda de ciclos, para ello, es necesario compilar con la opción
-DNP y ejecutar con opción -l:
$ spin -a abp . pml
$ cc - DNP -o pan pan .c
$ ./ pan -l
pan :1: non - progress cycle ( at depth 14)


never claim + (: np_ :)
assertion violations + ( if within scope of claim )
non - progress cycles + ( fairness disabled )
invalid end states - ( disabled by never claim )

86 states , stored
0 states , matched
2 atomic steps
[...]
Al visualizar la traza errónea comprobamos que se produce un ciclo en la aceptación de mensajes. Por la
especicación del modelo ABP, la aceptación (cíclica) de mensajes es un comportamiento correcto, por lo
tanto, debemos marcar el estado como un ciclo correcto, es decir, un ciclo progresivo mediante una etiqueta
progress:
$ spin -k abp . pml . trail abp . pml
spin : couldn 't find claim 4 ( ignored )
<<<<< START OF CYCLE >>>> >
ACCEPT 1
ACCEPT 2
ACCEPT 3
ACCEPT 4
ACCEPT 5
ACCEPT 6
ACCEPT 7
ACCEPT 0
# processes : 4
4 processes created
Insertamos la etiqueta correspondiente para identicar un ciclo progresivo:

bit last_ar =1; /* ar of last error - free msg */
do
if
skip /* ... don 't accept */
progress : ACCEPT ; /* correct message */
fi
od
}
Pero, si volvemos a generar el vericador, comprobamos que volvemos a detectar otro ciclo:
$ spin -a abp . pml

$ spin -t -p abp . pml
starting claim 4
spin : couldn 't find claim 4 ( ignored )
Starting Sender with pid 2
2: proc 0 (: init ::1) abp . pml :78 ( state 1) [( run Sender ( toS , fromS ))]
Starting Receiver with pid 3
3: proc 0 (: init ::1) abp . pml :79 ( state 2) [( run Receiver ( toR , fromR ) )]
Starting Lower_Layer with pid 4
4: proc 0 (: init ::1) abp . pml :80 ( state 3) [( run Lower_Layer ( fromS , toS , fromR , toR ))]
6: proc 1 ( Sender :1) abp . pml :31 ( state 1) [ mt = (( mt +1) %8)]
8: proc 1 ( Sender :1) abp . pml :32 ( state 2) [ cout ! data ,mt , at ]
10: proc 3 ( Lower_Layer :1) abp . pml :13 ( state 1) [ fromS ? data ,d ,b ]
12: proc 3 ( Lower_Layer :1) abp . pml :16 ( state 3) [ toR ! error ,0 ,0]
14: proc 2 ( Receiver :1) abp . pml :56 ( state 1) [ cin ? error ,mr , ar ]
16: proc 2 ( Receiver :1) abp . pml :57 ( state 2) [ cout ! ack , last_ar ]
18: proc 3 ( Lower_Layer :1) abp . pml :18 ( state 6) [ fromR ? ack , b]
20: proc 3 ( Lower_Layer :1) abp . pml :20 ( state 7) [ toS ! ack ,b]
22: proc 1 ( Sender :1) abp . pml :35 ( state 3) [ cin ? ack , ar ]
24: proc 1 ( Sender :1) abp . pml :40 ( state 7) [ else ]
26: proc 1 ( Sender :1) abp . pml :41 ( state 8) [(1) ]
# processes : 4
4 processes created
donde comprobamos que el ciclo se produce por la distorsión de mensajes en el medio, es decir, se podría
producir una situación de ciclo innito donde los mensajes fueran distorsionados y retransmitidos de forma
innita. Por lo tanto, también debemos marcarlos como ciclo progresivo:

{ byte d;
bit b;
do
:: fromS ? data (d ,b) ->
progress0 : if
:: toR ! data (d , b) /* correct */
:: toR ! error (0 ,0) /* corrupted */
fi
:: fromR ? ack (b ) ->
progress1 : if
:: toS ! ack (b) /* correct */
:: toS ! error (0) /* corrupted */
fi
od
}
Finalmente, volvemos a generar el vericador, comprobando que está libre de ciclos:
$ spin -a abp . pml

$ ./ pan -l


never claim + (: np_ :)
non - progress cycles + ( fairness disabled )

1796 states , stored (2454 visited )
4086 transitions (= visited + matched )
4 atomic steps
[...]
4.5.2. Proclamaciones never

Propiedad I
Debe de cumplirse el siguiente comportamiento: no hay una secuencia innita de mensajes duplicados a
menos que sean mensajes distorsionados. Por lo tanto, la siguiente proclamación nunca debe suceder:
El receptor alcanza un estado de detección de duplicado y visita ese estado repetidamente (ciclo)
sin haber aceptado un mensaje válido.
Si se produjera el ciclo anterior, el receptor no tendría posibilidad de recibir un mensaje válido a continuación.
Para la validación de la propiedad, añadiremos la etiqueta dup al código del receptor:

bit last_ar =1; /* ar of last error - free msg */
do
if
dup : skip /* ... don 't accept */
progress : ACCEPT ; /* correct message */
fi
od
}
Y especicamos la siguiente proclamación never:

El receptor alcanza un estado de detección de duplicado y visita este estado repetidamente sin
haber aceptado un mensaje válido.
que traducido a Promela sería:
never {
accept : do
:: do
:: ! Receiver@dup && ! Receiver@progress
:: Receiver@dup -> break
od ;
:: do
:: Receiver@dup
:: ! Receiver@dup && ! Receiver@progress -> break
od
od
}
Suponiendo que la proclamación never está guardada en el archivo never1.pml, la validación del propiedad
anterior en el modelo abp.pml sería:
$ spin -a -N never1 . pml abp . pml

$ cc -o pan pan . c - DNOREDUCE
$ ./ pan -a
pan :1: acceptance cycle ( at depth 22)
[...]
a la vista de los resultados del vericador, comprobamos que se ha producido un error en la proclamación
never, es decir, la sentencia never se ha cumplido, por lo tanto:
no es cierto que nunca entre en un ciclo innito de mensajes distorsionados sin recibir un mensaje
correcto en el destino.
o dicho de otro modo:
ha encontrado un ciclo innito de mensajes distorsionados y no recibe ningún mensaje correcto

en el destino.
Lo podemos comprobar fácilmente inspeccionando la traza generada:
]$ spin -N never1 . pml -t -p abp . pml

starting claim 4
Never claim moves to line 9 [((!(( Receiver . _p == dup ) ) &&!(( Receiver . _p == progress ) )))]
Starting Sender with pid 2
2: proc 0 (: init ::1) abp . pml :78 ( state 1) [( run Sender ( toS , fromS ))]
Starting Receiver with pid 3
3: proc 0 (: init ::1) abp . pml :79 ( state 2) [( run Receiver ( toR , fromR ) )]
Starting Lower_Layer with pid 4
4: proc 0 (: init ::1) abp . pml :80 ( state 3) [( run Lower_Layer ( fromS , toS , fromR , toR ))]
6: proc 1 ( Sender :1) abp . pml :31 ( state 1) [ mt = (( mt +1) %8)]
24: proc 1 ( Sender :1) abp . pml :40 ( state 7) [ else ]
26: proc 1 ( Sender :1) abp . pml :41 ( state 8) [(1) ]
# processes : 4
42: proc - ( never_0 :1) never1 . pml :2 ( state 13)
4 processes created
Propiedad II
La proclamación never siguiente:
El receptor alcanza un estado de detección de duplicado y visita este estado repetidamente sin
haber aceptado un mensaje válido .... a menos que sea un error.
el modelo Promela corresponde al siguiente código:
never {
accept : do
:: do
:: ! Receiver@dup && ! Receiver@progress && ! Lower_Layer@progress0
:: Receiver@dup -> break
od ;
:: do
:: Receiver@dup
:: ! Receiver@dup && ! Receiver@progress && ! Lower_Layer@progress0 -> break
od
od
}
ejecutamos el validador y comprobamos que la sentencia never nunca se cumple, por tanto, su comporta-
miento denido es imposible, y por tanto, la propiedad es correcta:
$ spin -a -N never2 . pml abp . pml

$ cc -o pan pan . c - DNOREDUCE
$ ./ pan -a

never claim + ( never_0 )
acceptance cycles + ( fairness disabled )

9 states , matched
8 atomic steps
[...]
Cuestión 3
A partir del modelo original abp.pml, renombralo con tus iniciales, por ejemplo, abp-JPR.pml, y realiza
todo el proceso anterior: validación de aserción (invariante global), detección de ciclos progresivos y
proclamaciones never. Anota las modicaciones realizadas así como la salida proporcionada por Spin .
4.6. Validación con LTL

En ABP queremos proclamar la propiedad que dene el correcto funcionamiento de ABP (Figura 4.12): un
mensaje de datos es nalmente recibido (a menos que se produzca un error cíclico).
sd ABP
Sender Receiver
FETCH data(a,1)
err ACCEPT
data(a,1)
ack(1) ACCEPT
FETCH data(b,0)
ack(0) ACCEPT
Figura 4.12: Funcionamiento correcto de ABP.
Y precisando un poco más: después de que un mensaje ha sido enviado, pueden producirse errores y retrans-
misiones hasta que es nalmente recibido en el receptor, o sucede un error innitamente a menudo.
Utilizaremos la Lógical Lineal Temporal (LTL) para la validación de la anterior proclamación. Para ello
denimos las siguientes variables proposicionales:
● ds: dato enviado.

● dr: dato recibido.
● xd: otro dato enviado (con otro contenido).
● err: mensaje erróneo recibido.
podemos describir con más detalle el comportamiento deseado, identicando las siguientes propiedades:
1. Cada mensaje de datos enviado es nalmente recibido por el receptor (Figura 4.13):
2. Puede producirse una situación de error cíclico debido a la distorsión sucesiva de mensajes en Low_Layer
(Figura 4.14):
3. Además, entre el envío y recepción de un mensaje de datos, no hay ningón otro mensaje transmitido
(Figura 4.12):
Sender lower layer Receiver
ds data(a,1)
error
ack(0)
ack(0) ó error
data(a,1)
data(a,1)
dr
Figura 4.13: ABP: mensaje recibido.
ds data(a,1)
error ciclo
ack(0)
ack(0)
data(a,1)
error
err
Figura 4.14: ABP: comportamiento cíclico.
ds data(a,1)
No mensajes de datos
con otro contenido
data(a,1)
dr
Figura 4.15: ABP: ningún otro mensaje enviado.

Por lo tanto, podemos establecer la siguiente proclamación:

Después de que un mensaje x ha sido enviado, pueden producirse errores y retransmisiones (pero
ningún otro dato es enviado) hasta que x es recibido o sucede un error innitamente a menudo.
donde una descripción un poco más formal sería:
Siempre después de ds no hay ningún xd hasta que (dr o err)

y expresado en LTL:
◻ (ds → ¬xd U (dr ∨ err)) (4.1)
Siempre que se cumple ds implica (entonces) no se cumple xd hasta que se cumplen (dr ó err)
4.6.1. Denición de LTL en Promela
La proclamación LTL, denida en (4.1), expresada en Spin , sería:
[](ds− > (!xd) U (dr ∣∣ err))
Las variables contenidas en fórmulas LTL deben de ser de ámbito global. En el modelo anterior, abp.pml, la denición de
canales ha sido de ámbito local y paso mediante parámetros a los diferentes procesos. En la versión abp-ltl.pml, necesitamos
declarar los canales de ámbito global.
La dención de las variables proposicionales utilizadas en las LTL han sido denidas, principalmente, mediante
operaciones de sondeo [...] sobre canal (Figura 4.16):
ninguna suposición mensaje de dato con contenido

del bit alternante x llega a lower_layer
byte x,y ABP

recepción correcta
#define ds ( toR ? [data(x,_)] )
#define dr ( fromS ? [data(x,_)] )
#define od ( fromS ? [data(y,_)] && y != x ) el receptor recibe mensaje
de datos con contenido
#define err ( fromS ? [error(_,_)] || fromR ? [_,_] ) incorrrecto
el receptor recibe un
mensaje distorsionado esto es para cubrir eventos de recepción
arbitrarios por el emisor (errores o acks
con bit alternante erróneo)
Figura 4.16: Denición de variables proposicionales.

Para la especicación y posterior vericación de propiedades LTL en modelos Promela debemos seguir los
siguientes pasos:
1. A partir del modelo abp.pml, crear el chero abp-ltl.pml donde deniremos las fórmulas proposi-
cionales necesarias para la posterior evaluación de la fórmula LTL. Importante : hemos cambiado la
declaración de canales a ámbito global:
1 /* --------------------------------------------------------- */
2 /* - ABP ( Alternating Bit Protocol ) -ltl - - */
3 /* --------------------------------------------------------- */
4 /* Ingenieria de Protocolos */
5 /* Grado en Ingenieria de Tecnologias de la Telecomunicacion */
6 /* UMH */
7 /* --------------------------------------------------------- */
8 /* Holzmann G., Design and Validation of Computer Protocols */
9 /* Prentice - Hall , 1991 */
10 /* --------------------------------------------------------- */
11 /* Correccion de propiedadades mediante LTL */
12 /* --------------------------------------------------------- */
13 /* abp - ltl . pml */
14 /* --------------------------------------------------------- */
15
16 # define N 1
17 # define MAX 8
18 # define FETCH mt = ( mt +1) % MAX
19 # define ACCEPT printf (" ACCEPT %d\n " , mr ); assert ( mr == ( last_mr +1) % MAX )
20
21 mtype = { data , ack , error }
22
23 chan fromS = [ N] of { mtype , byte , bit }
24 chan toR = [N] of { mtype , byte , bit }
25 chan fromR = [ N] of { mtype , bit }
26 chan toS = [N] of { mtype , bit }
27
28 /* Logica proposicional */
29 byte x , y;
30
31 # define ds ( toR ? [ data (x ,_) ] )
32 # define dr ( fromS ? [ data (x ,_)] )
33 # define xd ( fromS ? [ data (y ,_)] && (y != x) )
34 # define err ( fromS ? [ error (_ ,_) ] || fromR ? [_ ,_] )
35
36 proctype Lower_Layer ()
37 { byte d;
38 bit b;
39
40 do
41 :: fromS ? data (d ,b ) ->
42 if
43 :: toR ! data (d ,b) /* correct */
44 :: toR ! error (0 ,0) /* corrupted */
45 fi
46 :: fromR ? ack ( b) ->
47 if
48 :: toS ! ack (b ) /* correct */
49 :: toS ! error (0) /* corrupted */
50 fi
51 od
52 }
53
54 proctype Sender ()
55 { byte mt ; /* message data */
56 bit at ; /* alternation bit transmitted */
58
60 fromS ! data (mt , at ); /* ... and send it */
61
62 do
63 :: toS ? ack ( ar ) -> /* await response */
64 if
65 :: ( ar == at ) -> /* successful transmission */
67 at =1 - at /* toggle alternating bit */

68 :: else -> /* there was a send error */
69 skip /* don 't fetch a new msg . */
70 fi ;
71 fromS ! data (mt , at )
72 :: toS ? error ( ar ) -> /* receive error */
73 fromS ! data (mt , at ) /* simply send again */
74 od
75 }
76
77 proctype Receiver ()
78 { byte mr ; /* message data received */
79 byte last_mr ; /* mr of last error - free msg */
81 bit last_ar =1; /* ar of last error - free msg */
82
83 do
84 :: toR ? error ( mr , ar ) -> /* receive error */
85 fromR ! ack ( last_ar ) ; /* send ack with old bit */
86 :: toR ? data (mr , ar ) ->
87 fromR ! ack ( ar ); /* send response */
88 if
89 :: ( ar == last_ar ) -> /* bit is not alternating */
90 skip /* ... don ' t accept */
91 :: ( ar != last_ar ) -> /* bit is alternating */
92 ACCEPT ; /* correct message */
93 last_ar = ar ; /* store alternating bit */
94 last_mr = mr /* save last message */
95 fi
96 od
97 }
98
99 init {
100 atomic {
101 run Sender () ;
102 run Receiver () ;
103 run Lower_Layer ()
104 }
105 }
2. Generar una claúsula never a partir de la sentencia LTL negada. Guardar el resultado el chero
abp.ltl.
$ spin -f ' ![]( ds - >(! xd ) U ( dr || err )) ' > abp . ltl
El contenido del chero abp.ltl será:
never { /* ![]( ds - >(! xd ) U ( dr || err )) */

T0_init :
do
:: (! (( dr || err )) && ( ds )) -> goto accept_S4
:: atomic { (! ((! xd )) && ! (( dr || err ) ) && ( ds )) -> assert (!(! ((! xd )) && ! (( dr || err )) && ( ds ))) }
:: (1) -> goto T0_init
od ;
accept_S4 :
do
:: (! (( dr || err ))) -> goto accept_S4
:: atomic { (! ((! xd )) && ! (( dr || err ) )) -> assert (!(! ((! xd )) && ! (( dr || err )))) }
od ;
accept_all :
skip
}
3. Generar, compilar y ejecutar el vericador a partir del modelo abp.pml y el la proclamación never
generada a partir de la LTL y contenida en el chero abp.ltl:
$ spin -a -N abp . ltl abp - ltl . pml
$ cc -o pan pan .c
$ ./ pan -a
warning : for p.o. reduction to be valid the never claim must be stutter - invariant
( never claims generated from LTL formulae are stutter - invariant )



2 atomic steps
[...]
... comprobando que no hay error, por tanto, se cumple la proclamación LTL denida.
4.6.2. Otras fórmulas proposicionales

Utilizando los diferentes operadores proporcionados por LTL, podemos chequear la validez de diferentes
fórmulas proposicionales:
1. Siempre que se envía un datos llega erróneo.
Podemos comprobar que es FALSO.

$ spin -f ' !([]( ds -> err )) ' > abp . ltl
$ cc -o pan pan . c
$ ./ pan -a
( never claims generated from LTL formulae are stutter - invariant )
pan :1: assertion violated !(( !((( q_len ( fromS ) > 0 && qrecv ( fromS , 0, 0, 0) == 1) ||( q_len ( fromR ) >
0) )) &&( q_len ( toR ) > 0 && qrecv ( toR , 0, 0, 0) == 3) )) ( at depth 12)
pan : wrote abp - ltl . pml . trail



6 states , stored
0 states , matched
2 atomic steps
[...]
2. Siempre que se envía un dato ALGUNA VEZ llega erróneo.
Podemos comprobar que es CIERTO.

$ spin -f ' !([]( ds ->< > err )) ' > abp . ltl
$ cc -o pan pan . c
$ ./ pan -a
( neve claims generated from LTL formulae are stutter - invariant )



2 atomic steps
[...]
Cuestión 4
A partir de abp-ltl.pml, renómbralo con tus iniciales, por ejemplo, abp-ltl-JPR.pml, y realiza la
vericación de la propiedad:
◻(ds → ¬xd U (dr ∣∣ err))
Cuestión 5
Aporta una traza MSC, en formato gráco, de una simulación completa del modelo. Comenta el resul-
tado.
Cuestión 6
4.7. Informe
AT X

IP Labs PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IP Labs PDF

Uploaded by

Copyright:

Available Formats

Ingeniería de Protocolos

Grado en Ingeniería de Tecnologías de la Telecomunicación

Area de Arquitectura y Tecnología de Computadores

1. UML Coee Machine 3

2. Especicación, vericación y validación de ABP con SDL 47

3. Introducción al lenguaje Promela y Spin 69

4. Especicación y validación de ABP en Promela 95

4.3.5. Modelo ABP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

UML Coee Machine

1.2. Comportamiento de la Coee Machine

● Una taza de café cuesta 10.

Debe realizar el siguiente comportamiento:

(3) Si inserta una moneda de 5 y presiona botón de café, devuelve el dinero.

1.3. Modelos y diagramas

1 Extraído del documento Telelogic Tau UML Coee Machine Tutorial.

en diferentes diagramas. La información almacenada en el modelo es la suma de todas las descripciones

1.3.1. Eliminando entidades

1.4. Interface de usuario

1. La ventana del espacio de trabajo (Workspace ).

3. La ventana de salida (Output ).

Figura 1.1: Interface de IBM Rational Tau

Espacio de trabajo (Workspace )

Barra de atajos (Shortcut bar )

Ventana de salida (Output window )

Menú de atajos (Shortcut menú )

1.5. Espacio de trabajo

En un mismo espacio de trabajo podremos implementar diferentes modelos UML.

A) Iniciar IBM Rational Tau .

D) La siguiente tarea será añadir un proyecto.

2 Por ejemplo, Pepito Martínez López, utilizaría  PML.

A) En el menú File ↦ New... ↦ selecciona la pestaña Project.

F) Expandir las tres vistas de la pantalla.

G) La vista File muestra los cheros creados (Figura 1.2).

Figura 1.2: Vista File

Figura 1.3: Vista Model

1.7. Diagramas de casos de uso

B) En la vista Model, selecciona el paquete CMdesign ↦ clic-derecho ↦ New Model Element ↦

Es posible asignar un nombre al actor, pero no es necesario.

collaboration UserDrinks Use case diagram1 {1/1}

Figura 1.4: Caso de uso y actor.

● Habrá algún error en la ventana Output (pestaña Autocheck ).

1.8. Diagramas de clase

A) Asegúrate que en la ventana del espacio de trabajo se visualiza la vista Model.

package CMdesign DomainModel {1/3}

Figura 1.5: Las clases CoeMachine y Customer.

1.8.1. Clases activas o pasivas

● Activa: contiene comportamiento.

El diálogo de propiedades se puede abrir mediante ALT+Enter.

package CMdesign DomainModel {1/3}

Figura 1.6: Clases activas y externas (informal ).

1.8.2. Clase informal

A) Clic-derecho en la clase Customer Stereotypes....

Figura 1.7: Declaración de Estereotipo Informal ).

1.8.3. Descomposición de una clase

B) Renombra la clase a  Controller .

E) Renombra la clase a  Hardware .

1.9. Diagrama de componentes

A) Asegúrate que la ventana del espacio de trabajo está la vista Model.

Figura 1.8: Añadir diagrama de componentes.

Hardware desde la vista Model hasta el diagrama de componentes abierto

F) Asegúrate que el diagrama de componentes es igual a la Figura 1.9.

package CMdesign Component diagram1 {2/2}

Figura 1.9: Componentes de CoeeMachine.

1. UML Coee Machine 3

2. Especicación, vericación y validación de ABP con SDL 47

4. Especicación y validación de ABP en Promela 95

UML Coee Machine

1.2. Comportamiento de la Coee Machine

1 Extraído del documento Telelogic Tau UML Coee Machine Tutorial.

2 Por ejemplo, Pepito Martínez López, utilizaría PML.

G) La vista File muestra los cheros creados (Figura 1.2).

Figura 1.5: Las clases CoeMachine y Customer.

B) Renombra la clase a Controller .

E) Renombra la clase a Hardware .

Figura 1.9: Componentes de CoeeMachine.

1.10.1. Denición de señales

Figura 1.10: Denición de señales.

1.10.2. Denición de interfaces

● Coin, Coee y Tea deben ir a la interface FromUser.

Figura 1.11: Denición de interfaces y asignación de señales a interfaces.

A) En el diagrama de clases DomainModel ↦ selecciona la clase CoeeMachine ↦ presiona SHIFT ↦ en

↦ nombra el interface como FromUser .

Figura 1.15: Diagrama de secuencia para el caso de uso MakeCoee.

B) Crea un nuevo caso de uso ↦ renombra a TeaMaking .

● Autoow : selecciona un símbolo y presiona SHIFT ↦ clic en un símbolo de la barra de herramientas. El

E) Renombra la nueva máquina MakingBeverage .