Académique Documents
Professionnel Documents
Culture Documents
Prácticas de Laboratorio
Confeccionado por:
Salvador Alcaraz
Katja Gilly
9 de mayo de 2019
Índice general
Prácticas Página
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
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
● Un taza de té cuesta 5.
(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.
(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
2. El escritorio (Desktop ).
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.
● 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 ).
8 LABORATORIO 1. UML COFFEE MACHINE
Escritorio (Desktop )
Área donde se abren los diagramas y documentos. Es el espacio donde trabajamos con los modelos y se
visualizan los diferentes diagramas.
Vamos a crear un espacio de trabajo para el desarrollo del modelo Coee Machine :
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.
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.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 :
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).
10 LABORATORIO 1. UML COFFEE MACHINE
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
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 : ).
MakeCoffee
:Customer
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.
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.
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 .
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.
12 LABORATORIO 1. UML COFFEE MACHINE
CoffeeMachine Customer
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.
Una clase active se muestra mediante el diagrama con líneas de borde verticales dobles (Figura 1.6).
CoffeeMachine <<informal>>
Customer
C) También lo denimos activo, por lo tanto, clic-derecho en el símbolo de clase Customer ↦ Active.
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.
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.
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.
14 LABORATORIO 1. UML COFFEE MACHINE
C) Habrá aparecido el icono del diagrama en la vista Model y el diagrama estará abierto en el Escritorio
↦ renombra el nuevo diagrama ControlComponents .
G) Graba el trabajo.
Controller Hardware
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.
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:
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.
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.
● FromUser
● ToUser
● 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.
<<interface>> <<interface>>
FromUser ToUser
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.
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).
CoffeMachine <<informal>>
Customer
<<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.
18 LABORATORIO 1. UML COFFEE MACHINE
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.
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
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
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.
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
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 ).
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.
H) Graba el trabajo.
20 LABORATORIO 1. UML COFFEE MACHINE
<<informal>>
: Controller : Hardware
: Customer
FromUser::Coin(10)
FromUser::Coffee()
FillWater()
WaterOK()
FillCoffee()
CoffeeOK()
HeatWater()
Warm()
ToUser::CupOfCoffee()
A) Abre el diagrama de casos de uso en la colaboración UserDrinks ↦ crea un nuevo caso de uso ↦
renombra a MakeTea .
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.
CoffeeMachine
MakeCoffee <<informal>>
:Customer
MakeTea
<<include>>
TeaMaking
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.
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.
E) Guarda el trabajo.
<<informal>>
: CoffeeMachine
: Customer
Coin(5)
Tea()
ref TeaMaking
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.
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.
● 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.
<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.
HeatWater()/^Warm();
Idle
FillWater()/^WaterOK();
Water
● 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.
Ahora podemos utilizar la sintaxis orientada a transición para describir el comportamiento en un estado
compuesto.
D) Graba el trabajo.
WaitFill
FillCoffee()
CoffeeOK()
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.
24 LABORATORIO 1. UML COFFEE MACHINE
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é.
Para insertar los símbolos Decision Answer , es necesario que esté seleccionado el símbolo Decision .
Idle
Coin(Value)
NbrOfCoffee=0; Integer NbrOfCoffee;
NbrOfTea=0; Integer NbrOfTea;
Value
Integer Value;
Idle
5 10 else
PaidFive PaidTen
PaidFive PaidTen Idle
MakingTea
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.
H) Guarda el proyecto.
LABORATORIO 1. UML COFFEE MACHINE 25
WaterForCoffee WaterForTea
CoffeeAndWater NbrOfTea=NbrOfTea+1;
CoffeeAndWater
Idle
Warm()
CupOfCoffee()
NbrOfCoffee=NbrOfCoffee+1;
Idle
Ahora vamos a instanciar las clases y describir la comunicación entre Customer, Controller y Hardware
mediante un diagrama de estructura compuesto (composite ).
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
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.
Puertos
Ahora vamos añadir algunos puertos ( ports) adicionales al modelo para habilitar la comunicación, empezando
por el puerto representante de Customer :
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.
CoeeOK
WaterOK
Warm
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.
D) Graba el trabajo.
Ctrl:Controller
CoffeeOK,WaterOK, Warm
P3 CtrlBiHw
P4
FillCoffee,FillWater,HeatWater
Hw:Hardware
Puertos e interfaces
Ahora vamos añadir los puertos a las clases en el diagrama de componentes.
FillCoffee,FillWater,HeatWater FillCoffee,FillWater,HeatWater
Controller Hardware
P3 P4
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.
C) Añade una composición de la misma forma entre las clases CoeeMachine y Hardware.
D) Graba el trabajo.
Podemos visualizar/ocultar los diferentes atributos (2º compartimento) y métodos (3er. compartimento) de las clases
seleccioando la clase ↦ clic-derecho.
28 LABORATORIO 1. UML COFFEE MACHINE
P1
FromUser ToUser
<<interface>>
ToUser FromUser ToUser
initialize ()
initialize ()
timer Heater ()
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
LABORATORIO 1. UML COFFEE MACHINE 29
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.
● En algunos tipos de error, mediante doble clic, el problema que causa el error se muestra en el
Escritorio.
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.
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)!!.
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.
32 LABORATORIO 1. UML COFFEE MACHINE
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:
Para congurar una señal de la matriz de mensajes hacer doble clic en el primer campo.
34 LABORATORIO 1. UML COFFEE MACHINE
● 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 .
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.
LABORATORIO 1. UML COFFEE MACHINE 35
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.
Idle
Idle
Coin(10)
Coffee()
PaidTen
FillWater()
MakingCoffee
WaterOK()
WaitFill
FillCoffee()
WaterForCoffee
CoffeeOK()
WaitFill
HeatWater()
CoffeeAndWater
Warm()
Idle
CupOfCoffee()
Idle
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:
F) Ahora que estamos familiarizados con la traza de diagrama de secuencias, volvemos a la ejecución del
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
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
.
38 LABORATORIO 1. UML COFFEE MACHINE
CoffeeMachine
Idle
Idle
Coin(10)
Tea()
PaidTen
ReturnChange()
FillWater()
MakingTea
WaterOK()
WaitFill
HeatWater()
WaterForTea
Warm()
Idle
CupOfWater()
Idle
Idle
Idle
Coin(5)
Coffee()
PaidFive
ReturnChange()
Idle
Idle
Idle
Coin(5)
Tea()
PaidFive
FillWater()
MakingTea
WaterOK()
WaitFill
HeatWater()
WaterForTea
Warm()
Idle
CupOfWater()
Idle
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.
<<informal>>
: Controller : Hardware
: Customer
FillWater ()
MakingTea
WaterOK ()
Water::WaitFill
HeatWater ()
WaterForTea
Warm ()
Idle
CupOfWater ()
Idle
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.
FillCoffee,FillWater,HeatWater FillCoffee,FillWater,HeatWater
Controller Hardware
P3 P4
initialize ()
initialize ()
timer Heater ()
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()
Heater()/^Warm();
Idle
FillWater()/^WaterOK();
Water
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).
WaitFill
FillCoffee() HeatWater()
CoffeeOK() set(Heater(),now+1);
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.
42 LABORATORIO 1. UML COFFEE MACHINE
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
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).
LABORATORIO 1. UML COFFEE MACHINE 43
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):
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.
LABORATORIO 1. UML COFFEE MACHINE 45
<<interface>> <<interface>>
FromUser ToUser Additives
+Milk:Boolean
+Sugar:Integer
signal CupOfCoffee (part Additives)
signal Coin ( Integer)
signal CupOfWater ()
signal Tea ()
signal ReturnChange ()
Idle
5 10 else
PaidFive PaidTen
MakingTea
<<informal>>
: Controller : Hardware
: Customer
Coin(10)
Coffee (Additives(.Milk=true,Sugar=3.))
FillWater ()
WaterOK ()
FillCoffee ()
CoffeeOK ()
HeatWater ()
Warm ()
ToUser::CupOfCoffee ()
Coin(10)
Idle
Idle
PaidTen
FillWater()
MakingCoffee
WaterOK()
WaitFill
FillCoffee()
WaterForCoffee
CoffeeOK()
WaitFill
HeatWater()
CoffeeAndWater
Heater() = 1.0000
WaitFill
Heater()
Warm()
Idle
Idle
Figura 1.42: Traza del diagrama de secuencia utilizando parámetros del tipo Additives.
48 LABORATORIO 1. UML COFFEE MACHINE
(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.
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 .
Duración: 2 sesiones
● Es un entorno de comunicaciones punto a punto (canal ) formado por dos estaciones: Emisor (E) y
Receptor (R).
● 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.
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.
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).
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.
52 LABORATORIO 2. ESPECIFICACIÓN, VERIFICACIÓN Y VALIDACIÓN DE ABP CON SDL
MSC TrazaCompleta
Environment ULSenderP SenderP DataMedium AckMedium ReceiverP ULReceiverP
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
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
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)
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
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.
54 LABORATORIO 2. ESPECIFICACIÓN, VERIFICACIÓN Y VALIDACIÓN DE ABP CON SDL
data_loss_signal
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
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.
Wait
Sender_Ready
Send
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.
Wait
Receiver_Ready
Receive
Wait_1
Deliver
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.
Send_0 Send_1
Wait_0 Wait_1
reset(Timer1) reset(Timer1)
Sender_Ready Sender_Ready
Idle_0 Idle_1
Send_1 Send_0
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.
Idle_0
Wait_0 Wait_1
Idle_1 Idle_0
Receiver_Ready Receiver_Ready
Wait_1 Wait_0
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.
Empty1
DataS_0 DataS_1
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.
Empty1
AckR_0 AckR_1
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
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
+ 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
D) Posicionando el cursor en el error y pulsando nos dirigirá a símbolo detectado erróneo ↦ cambiamos
por Deliver.
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 .
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:
Process List: Visualizar información relativa a los procesos del modelo: número de instancias, estado, se-
ñales y cola.
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.
Una vez realizada una simulación, debemos de resetear el simulador ↦ Files ↦ Restart, para volver al estado inicial del
simulador.
62 LABORATORIO 2. ESPECIFICACIÓN, VERIFICACIÓN Y VALIDACIÓN DE ABP CON SDL
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
2.6. Validación
Posteriormente a la simulación, realizaremos la validación5 del modelo en busca de errores de diseño.
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:
● Recorrido aleatorio
● Recorrido en árbol
● Búsqueda exhaustiva
● Máximo de niveles del árbol de comportamiento que ha sido alcanzado durante la exploración.
● 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:
Una vez realizada una exploración del modelo, debemos de resetear el validador ↦ Files ↦ Restart.
● Porcentaje de símbolos que han sido ejecutados por lo menos una vez.
La validación del modelo ABP con el método random walk proporciona el siguiente resultado:
● Ejecuta una secuencia de búsquedas en árbol, con incrementos de profundidad e iniciando la búsqueda
desde diferentes estados del grafo de alcanzabilidad.
● 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:
● Algoritmo de búsqueda en profundidad similar a la búsqueda por bit de estado, pero sin colisiones.
● Máximo de niveles del árbol de comportamiento que ha sido alcanzado durante la exploración.
● Porcentaje de símbolos que han sido ejecutados por lo menos una vez.
La validación del modelo ABP con el método exhaustivo proporciona el siguiente resultado:
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).
Command : Verify - MSC C :\ Trabajo \ Docencia \ IP \ Tools \ TelelogicSDL \ Modelos \ ABP \ Venkataram \ Requeriments . msc
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:
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.
68 LABORATORIO 2. ESPECIFICACIÓN, VERIFICACIÓN Y VALIDACIÓN DE ABP CON SDL
MSC Requeriments
Environment ULSenderP SenderP DataMedium AckMedium ReceiverP ULReceiverP
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).
LABORATORIO 2. ESPECIFICACIÓN, VERIFICACIÓN Y VALIDACIÓN DE ABP CON SDL 69
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
2.6.6. Navigator
En relación a la herramienta Navigator:
● Es una herramienta que se utiliza para navegar por el árbol de comportamiento.
● 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
Cuestión 3
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.
2.8. 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.
(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
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.
Duración: 3 sesiones
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:
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:
Cuestión 3
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
74 LABORATORIO 3. INTRODUCCIÓN AL LENGUAJE PROMELA Y SPIN
Cuestión 5
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.
LABORATORIO 3. INTRODUCCIÓN AL LENGUAJE PROMELA Y SPIN 75
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:
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
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:
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.
LABORATORIO 3. INTRODUCCIÓN AL LENGUAJE PROMELA Y SPIN 77
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
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:
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.
78 LABORATORIO 3. INTRODUCCIÓN AL LENGUAJE PROMELA Y SPIN
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:
(0,0)
a1 b1
0 0 (1,0) (0,1)
a2 b1 a1 b2
a1 b1
(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).
LABORATORIO 3. INTRODUCCIÓN AL LENGUAJE PROMELA Y SPIN 79
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.
80 LABORATORIO 3. INTRODUCCIÓN AL LENGUAJE PROMELA Y SPIN
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).
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:
Ahora vamos a realizar una simulación controlada de los primeros 1000 transiciones, con visualización de
todas las sentencias y variables globales:
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
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.
LABORATORIO 3. INTRODUCCIÓN AL LENGUAJE PROMELA Y SPIN 81
Cuestión 15
Para comprobar el carácter no determinista, realiza una serie de 10 experimentos, con parámetro
-u1000. Completa la siguiente tabla:
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:
14: proc 1 ( Dec :1) atomic . pml :21 ( state 2) [(( x >0) ) ]
15: proc 0 ( Inc :1) atomic . pml :13 ( state 3) [x = (x +1) ]
16: proc 0 ( Inc :1) atomic . pml :11 ( state 1) [(1) ]
17: proc 2 ( Reset :1) atomic . pml :30 ( state 2) [(( x ==2) )]
18: proc 2 ( Reset :1) atomic . pml :31 ( state 3) [x = 0]
19: proc 2 ( Reset :1) atomic . pml :29 ( state 1) [(1) ]
20: proc 1 ( Dec :1) atomic . pml :22 ( state 3) [x = (x -1) ]
21: proc 1 ( Dec :1) atomic . pml :20 ( state 1) [(1) ]
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:
● Sentencia ejecutable: x = x + 1.
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):
LABORATORIO 3. INTRODUCCIÓN AL LENGUAJE PROMELA Y SPIN 83
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.
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:
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:
[...]
Cuestión 16
Cuestión 17
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.
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 }
LABORATORIO 3. INTRODUCCIÓN AL LENGUAJE PROMELA Y SPIN 87
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 >
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
12798: proc 0 (: init ::1) complejidad1 . pml :11 ( state 3) [.( goto )]
spin : complejidad1 . pml :9 , Error : value (256 - >0 (8) ) truncated in assignment
12799: proc 0 (: init ::1) complejidad1 . pml :8 ( state 2) [i = (i +1) ]
: init :(0) : i = 0
12800: proc 0 (: init ::1) complejidad1 . pml :11 ( state 3) [.( goto )]
12801: proc 0 (: init ::1) complejidad1 . pml :8 ( state 2) [i = (i +1) ]
: init :(0) : i = 1
12802: proc 0 (: init ::1) complejidad1 . pml :11 ( state 3) [.( goto )]
12803: proc 0 (: init ::1) complejidad1 . pml :8 ( state 2) [i = (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?
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:
hint : this search is more efficient if pan . c is compiled - DSAFETY
error : max search depth too small
Tipo Estados generados Vector estado (bytes) Memoria utilizada para estados ¾Error? Caso error, explica el motivo
bool
byte
short
int
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.
$ ./ pan - m1000000
Cuestión 25
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
90 LABORATORIO 3. INTRODUCCIÓN AL LENGUAJE PROMELA Y SPIN
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]
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:
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.
LABORATORIO 3. INTRODUCCIÓN AL LENGUAJE PROMELA Y SPIN 91
0 1 2 3
··· 2w-2 2w-1
vector
de estado 4,12,0,1
conflicto:
lista enlazada
2,10,1,1 (acceso secuencial-lento)
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)
w H T S G V E M conictos
24 128 ≈0 15 31 21 - 315 0
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:
unreached in init
complejidad2 . pml :8 , state 6, " -end -"
(1 of 6 states )
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.
LABORATORIO 3. INTRODUCCIÓN AL LENGUAJE PROMELA Y SPIN 93
Cuestión 30
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:
[...]
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.
94 LABORATORIO 3. INTRODUCCIÓN AL LENGUAJE PROMELA Y SPIN
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á:
[...]
Para exploraciones en espacios de estados extremadamente grandes, Spin proporciona datos parciales por cada millón de
estados visitados.
Cuestión 32
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:
Cuestión 33
Cuestión 34
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.
3.6. 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.
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 .
Sender Receiver
Lower layer
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.
● 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.
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
Lower Layer
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:
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
100 LABORATORIO 4. ESPECIFICACIÓN Y VALIDACIÓN DE ABP EN PROMELA
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
toR!data,d,b toS!ack,b
toR!error,0,0
S4 fromR?ack,b S9
2
La FSM del proceso Lower_Layer está especicada en la Figura 4.3.
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
2 Las FSM han sido obtenidos mediante la herramienta Graphviz a partir de la exportación a formato .dot de los modelos en
Spin .
LABORATORIO 4. ESPECIFICACIÓN Y VALIDACIÓN DE ABP EN PROMELA 101
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
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
}
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
init {
atomic {
run Sender ( toS , fromS );
run Receiver ( toR , fromR );
run Lower_Layer ( fromS , toS , fromR , toR )
}
}
LABORATORIO 4. ESPECIFICACIÓN Y VALIDACIÓN DE ABP EN PROMELA 103
init S4
(run Sender(toS,fromS))
S2
(run Receiver(toR,fromR))
S3
(run Lower_Layer(fromS,toS,fromR,toR))
S5
-end-
S0
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 */
53 FETCH ; /* get a new message */
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 */
67 bit ar ; /* alternation bit received */
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.
LABORATORIO 4. ESPECIFICACIÓN Y VALIDACIÓN DE ABP EN PROMELA 105
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.
106 LABORATORIO 4. ESPECIFICACIÓN Y VALIDACIÓN DE ABP EN PROMELA
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:
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:
108 LABORATORIO 4. ESPECIFICACIÓN Y VALIDACIÓN DE ABP EN PROMELA
62: proc 3 ( Lower_Layer :1) abp . pml :18 Recv ack ,1 <- queue 3 ( fromR )
66: proc 1 ( Sender :1) abp . pml :44 Recv error ,0 <- queue 4 ( cin )
ACCEPT 2
spin : abp . pml :64 , Error : assertion violated
spin : text of failed assertion : assert (( mr ==(( last_mr +1) %8)))
# processes : 4
69: proc 3 ( Lower_Layer :1) abp . pml :24 ( state 12)
69: proc 2 ( Receiver :1) abp . pml :64 ( state 9)
69: proc 1 ( Sender :1) abp . pml :47 ( state 15)
69: proc 0 (: init ::1) abp . pml :82 ( state 5) < valid end state >
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:
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?
do
:: in ? error(mr,ar) ->
out ! ack(last_ar);
:: in ? data(mr,ar) ->
...
}
do
:: in ? error(mr,ar) ->
out ! ack(last_ar);
:: in ? data(mr,ar) ->
...
}
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).
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
hint : this search is more efficient if pan .c is compiled - DSAFETY
pan :1: too few parameters in send stmnt ( at depth 86)
pan : wrote abp . pml . trail
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:
1 . . . fromS ? data ,1 ,0
2 . . . toR ! error ,0 ,0
87: warning : missing params in send
spin : trail ends after 87 steps
-------------
final state :
-------------
# processes : 4
87: proc 3 ( Lower_Layer :1) abp . pml :12 ( state 11)
87: proc 2 ( Receiver :1) abp . pml :55 ( state 14)
87: proc 1 ( Sender :1) abp . pml :34 ( state 14)
87: proc 0 (: init ::1) abp . pml :82 ( state 5) < valid end state >
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
}
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
hint : this search is more efficient if pan . c is compiled - DSAFETY
1. Cada mensaje es recibido una sóla vez (ya ha sido vericado mediante el assert del modelo).
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)
pan : wrote abp . pml . trail
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
spin : trail ends after 174 steps
# processes : 4
174: proc 3 ( Lower_Layer :1) abp . pml :12 ( state 11)
174: proc 2 ( Receiver :1) abp . pml :59 ( state 4)
174: proc 1 ( Sender :1) abp . pml :34 ( state 14)
174: proc 0 (: init ::1) abp . pml :82 ( state 5) < valid end state >
4 processes created
116 LABORATORIO 4. ESPECIFICACIÓN Y VALIDACIÓN DE ABP EN PROMELA
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 */
progress : ACCEPT ; /* correct message */
last_ar = ar ; /* store alternating bit */
last_mr = mr /* save last message */
fi
od
}
Pero, si volvemos a generar el vericador, comprobamos que volvemos a detectar otro ciclo:
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:
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
}
[...]
118 LABORATORIO 4. ESPECIFICACIÓN Y VALIDACIÓN DE ABP EN PROMELA
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:
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 */
dup : skip /* ... don 't accept */
:: ( ar != last_ar ) -> /* bit is alternating */
progress : ACCEPT ; /* correct message */
last_ar = ar ; /* store alternating bit */
last_mr = mr /* save last message */
fi
od
}
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:
[...]
LABORATORIO 4. ESPECIFICACIÓN Y VALIDACIÓN DE ABP EN PROMELA 119
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.
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.
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:
[...]
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 .
LABORATORIO 4. ESPECIFICACIÓN Y VALIDACIÓN DE ABP EN PROMELA 121
sd ABP
Sender Receiver
FETCH data(a,1)
err ACCEPT
data(a,1)
ack(1) ACCEPT
FETCH data(b,0)
ack(0) ACCEPT
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:
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):
122 LABORATORIO 4. ESPECIFICACIÓN Y VALIDACIÓN DE ABP EN PROMELA
ds data(a,1)
error
ack(0)
ack(0) ó error
data(a,1)
data(a,1)
dr
ds data(a,1)
error ciclo
ack(0)
ack(0)
data(a,1)
error
err
ds data(a,1)
No mensajes de datos
con otro contenido
data(a,1)
dr
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:
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):
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)
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 */
57 bit ar ; /* alternation bit received */
58
59 FETCH ; /* get a new message */
60 fromS ! data (mt , at ); /* ... and send it */
61
62 do
63 :: toS ? ack ( ar ) -> /* await response */
64 if
65 :: ( ar == at ) -> /* successful transmission */
66 FETCH ; /* get a new message */
LABORATORIO 4. ESPECIFICACIÓN Y VALIDACIÓN DE ABP EN PROMELA 125
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
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 )
... comprobando que no hay error, por tanto, se cumple la proclamación LTL denida.
LABORATORIO 4. ESPECIFICACIÓN Y VALIDACIÓN DE ABP EN PROMELA 127
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
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.
4.7. 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.