falluto: un model checker para la veriﬁcación de sistemas...

Facultad de Matemática, Astronomía y FísicaUniversidad Nacional de Córdoba

Falluto: Un model checker para laverificación de sistemas tolerantes a fallas

Edgardo E. HamesDirector: Dr. Pedro R. D’Argenio

Córdoba, 14 de diciembre de 2009

Analisis de Refinamientos entre Sistemas deTransiciones Modales basado en SAT

Carolina Ines DaniaDirector: Dr. Nazareno Aguirre

16 de diciembre de 2008

Resumen

Desde tiempos previos a la llamada crisis del software se ha reconocido que la com-plejidad y el tamano de los sistemas de software demanda metodologıas sistematicasde desarrollo. El objetivo de estas es permitir crear, disenar y mantener (exitosamente)software de calidad y de gran escala (y en los tiempos estipulados). En busca de proveergarantıas del correcto funcionamiento del software, surgieron una variedad de tecnicasy metodologıas de desarrollo con solidas bases matematicas y logicas.Los sistemas de transicion de estados (LTS), y la amplia mayorıa de sus variantesconstituyen un formalismo adecuado para la caracterizacion del comportamiento op-eracional de sistemas, incluyendo sistemas reactivos, concurrentes y distribuidos. Enparticular, los sistemas de transiciones modales (MTS) permiten descripciones par-ciales de sistemas, las cuales son utiles en etapas tempranas del desarrollo de software.Las relaciones de refinamiento entre MTS son centrales a esta idea. Estas permitenidentificar las especificaciones que mas se acercan a la implementacion del sistema.El objetivo de este trabajo es equipar a los MTS con herramientas de analisis au-tomatico o semi-automatico para poder estudiar a estos objetos y a las relaciones derefinamiento entre ellos.

Classificacion: D.2.4 Software/Program Verification, F.3.2 Semantics of Program-ming Languages.

Palabras Claves: LTS, MTS, Bisimulaciones, Refinamientos, Implementaciones,SAT solver, Alloy, MTSA.

La vida es mucho mejor desde que se es licenciado.Lic. Matıas Bordese

Agradecimientos

A mi vieja, mi viejo, Marcos y Flor por ser quienes siempre me apoyaron.A mis abuelas, tios y primos por estar en cada momento que los necesite.A Pedro por estar siempre en cada instante de mi vida.Al Naza, no solo por ser mi director sino por ser un amigo.A mis amigos J, el flaco, Juli, Mati, Nati, Caro, Waldo, Lau, el recientemente Dr. King,Rafa, Santi, Ale, Fran, Carlos, German, Diego, Joshep y Cesar K.A mis otros amigos que estan lejos, Matthi, Ceci y Xavi que no van a poder hacermeningun dano.A mis companeros de laburo y a mis jefes.A Pichu por los tips sobre uso de memoria y a Fernando por prestarme a Shiva.Y a todos los que no estoy nombrando y que seguramente me lo reprocharan luego.

Indice general

1. Introduccion 11

2. Conceptos preliminares 152.1. Sistemas de Transiciones Etiquetadas . . . . . . . . . . . . . . . . . 152.2. Simulaciones y Bisimulaciones . . . . . . . . . . . . . . . . . . . . . 162.3. Sistemas de Transiciones Modales . . . . . . . . . . . . . . . . . . . 202.4. Refinamientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.5. Implementaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3. Modelado de MTS y LTS en Alloy 273.1. Definicion de Universos . . . . . . . . . . . . . . . . . . . . . . . . . 273.2. Transiciones y funciones auxiliares . . . . . . . . . . . . . . . . . . . 293.3. Relaciones entre LTS y MTS . . . . . . . . . . . . . . . . . . . . . . 31

3.3.1. Simulaciones y Bisimulaciones . . . . . . . . . . . . . . . . 313.3.2. Refinamientos . . . . . . . . . . . . . . . . . . . . . . . . . 323.3.3. Implementaciones . . . . . . . . . . . . . . . . . . . . . . . 32

3.4. Analisis de algunas propiedades elementales . . . . . . . . . . . . . . 333.5. Algunas mejoras al modelado . . . . . . . . . . . . . . . . . . . . . . 35

3.5.1. Simulaciones y Bisimulaciones . . . . . . . . . . . . . . . . 363.5.2. Refinamientos . . . . . . . . . . . . . . . . . . . . . . . . . 373.5.3. Implementaciones . . . . . . . . . . . . . . . . . . . . . . . 37

3.6. Comparacion de diversas herramientas en el ana-lisis de bisimulacionesy refinamientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.7. Ejemplos de otros analisis con Alloy Analyzer . . . . . . . . . . . . . 41

4. Predicados de Alto Orden sobre MTS y LTS 474.1. Preservacion de implementaciones en Alloy . . . . . . . . . . . . . . 48

4.1.1. Analisis de propiedades con cuantificacion de Alto Orden . . 514.1.2. Limitaciones en el Analisis mediante Alloy Analyzer . . . . . 51

4.2. Mınimo conjunto de Relaciones . . . . . . . . . . . . . . . . . . . . 524.2.1. En busca de relaciones representantes . . . . . . . . . . . . . 524.2.2. Minimizando relaciones con Alloy Analyzer . . . . . . . . . 53

4.3. Generacion de LTS/MTS . . . . . . . . . . . . . . . . . . . . . . . . 554.4. Metodologıa de Analisis . . . . . . . . . . . . . . . . . . . . . . . . 564.5. Algunos Ejemplos de contraejemplos . . . . . . . . . . . . . . . . . 58

9

10

4.6. Estimacion de tiempo de analisis . . . . . . . . . . . . . . . . . . . . 594.7. Mejora al tiempo de analisis . . . . . . . . . . . . . . . . . . . . . . 594.8. Una alternativa utilizando DynAlloy . . . . . . . . . . . . . . . . . . 59

4.8.1. Analisis de la propiedad mediante DynAlloy . . . . . . . . . 60

5. Conclusiones y trabajo futuro 615.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.2. Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

A. La herramienta MTSA 63A.1. LTSA - Labeled Transition System Analyzer . . . . . . . . . . . . . . 63A.2. MTSA - Modal Transition System Analyzer . . . . . . . . . . . . . . 64A.3. MTSChecker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

B. Las herramientas Alloy y DynAlloy 67B.1. Alloy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

B.1.1. Gramatica y semantica de Alloy . . . . . . . . . . . . . . . . 67B.1.2. Signaturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68B.1.3. Formulas y declaraciones . . . . . . . . . . . . . . . . . . . . 68B.1.4. Funciones, hechos, aserciones y predicados . . . . . . . . . . 69B.1.5. Corridas y chequeos . . . . . . . . . . . . . . . . . . . . . . 70B.1.6. Skolemizacion de Relaciones . . . . . . . . . . . . . . . . . 70

B.2. DynAlloy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71B.2.1. Gramatica y semantica de DynAlloy . . . . . . . . . . . . . . 71B.2.2. Predicados . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

B.3. KodKod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71B.3.1. Sintaxis abstracta de KodKod . . . . . . . . . . . . . . . . . 72

B.4. Cotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

C. Ejemplos 75C.1. MTSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75C.2. MTSChecker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77C.3. Alloy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79C.4. KodKod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

D. Mınimo conjunto de Relaciones en Alloy 87

E. Codigo 95E.1. Disco Ram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95E.2. Script de generacion de MTS y analisis de nuestra propiedad . . . . . 96

E.2.1. Es conexo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100E.2.2. Antecendente de la propiedad . . . . . . . . . . . . . . . . . 101E.2.3. Consecuente de la propiedad . . . . . . . . . . . . . . . . . . 101

E.3. KodKod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102E.3.1. Clase Transition . . . . . . . . . . . . . . . . . . . . . . . . 102E.3.2. Clase LTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107E.3.3. Clase MTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 109E.3.4. Clase Rel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111E.3.5. Ejemplos de (bi)simulaciones . . . . . . . . . . . . . . . . . 112E.3.6. Ejemplos de refinamientos . . . . . . . . . . . . . . . . . . . 116E.3.7. Ejemplos de implementaciones . . . . . . . . . . . . . . . . . 120

1 Introduccion

Desde tiempos previos a la llamada crisis del software se ha reconocido que lacomplejidad y el tamano de los sistemas de software, cuyo campo de aplicacion hacrecido significativamente respecto de sus aplicaciones en calculo numerico de los ini-cios de la computacion, demanda metodologıas sistematicas de desarrollo [GJM02].Por supuesto, el objetivo de estas es permitir crear, disenar y mantener (exitosamente)software de calidad y de gran escala (y en los tiempos estipulados) [Som00]. Uno delos problemas mas importantes asociados con la construccion de software es la correc-cion del mismo, es decir, en que medida el software construido satisface los requisitos(funcionales o no) establecidos durante las etapas tempranas del desarrollo. En buscade proveer garantıas del correcto funcionamiento del software, surgieron una variedadde tecnicas y metodologıas de desarrollo con solidas bases matematicas y logicas cono-cidas como metodos formales [Dil94][Win90]. Debido a su naturaleza, la aplicacion demetodos formales requiere gran experiencia y conocimientos, sobre todo en lo con-cerniente a matematica y logica, por lo cual su aplicacion resulta costosa en la practica.Esto ha provocado que su principal aplicacion se limite a sistemas crıticos [Sto96] (esdecir, sistemas de software/hardware cuyo mal funcionamiento o falla puede causardanos de magnitud, como la perdida de vidas humanas, etc), aunque claramente losbeneficios que sus tecnicas proveen son relevantes a todo tipo de software. Por estemotivo, las metodologıas de desarrollo mas utilizadas en la actualidad son informales,en el sentido de que las notaciones y procesos utilizados no cuentan con semantica for-mal o precisamente descripta en algun formalismo matematico (por ejemplo, la ampliamayorıa de las notaciones abarcadas por UML [BRJ98], o las notaciones asociadas ametodologıas mas antiguas como las reportadas en [Ing87]). Mas aun, el testing, clara-mente una tecnica informal, sigue siendo en la actualidad la tecnica para la garantıa decorreccion (funcional) del software mas ampliamente utilizada en la practica.

Otra de las razones por las cuales se dificulta la adopcion de metodos formales enla practica es que, en varios casos, las notaciones utilizadas en los ambitos formal einformal son de distinta naturaleza. Un ejemplo claro de esto es el hecho de que, ennotaciones informales como UML, las descripciones suelen interpretarse como par-ciales (que se completaran sucesivamente a medida que se gane conocimiento sobreel sistema a desarrollar), mientras que en notaciones formales las descripciones suelenser totales, es decir, requieren contar con la informacion completa sobre el compor-tamiento del sistema para su formalizacion. Este es el caso particular de los sistemasde transicion de estados (LTS), y la amplia mayorıa de sus variantes. Los LTS consti-tuyen un formalismo adecuado para la caracterizacion del comportamiento operacional

11

12 1. Introduccion

de sistemas, incluyendo sistemas reactivos, concurrentes y distribuidos (mas aun, exis-ten extensiones a la nocion clasica de sistema de transicion de estados que incorporanelementos probabilistas o de tiempo real, para poder describir sistemas con este tipode componentes). Si bien los LTS constituyen un formalismo adecuado para describirel comportamiento de sistemas, estos requieren contar con informacion total sobre elcomportamiento de un sistema. Como resultado de esta observacion, y ante la necesi-dad de poder describir parcialmente el comportamiento de un sistema, para ası poderacercar la naturaleza de estas descripciones formales a la naturaleza mas ampliamentedifundida en descripciones informales, y para, por ejemplo, dar lugar a posibles im-plementaciones posteriores o para describir familias de productos [FUB06], surgieronen los ultimos anos variantes de los LTS que admiten parcialidad en la descripcion[LT88, LX90, Fis06]. Una de estas variantes, los sistemas de transicion modales, hasido equipada con nociones de refinamiento e implementacion, e incluso poseen her-ramientas de soporte.

Ultimamente se ha reconocido que contar con herramientas de analisis automaticoo semi-automatico es un elemento de gran importancia para contribuir a la utilizacionde metodos formales en la practica. Es el objetivo de este trabajo precisamente este,equipar a los MTS, como formalismo de descripcion parcial de sistemas, con una her-ramienta de analisis potente. Existe actualmente una herramienta de este tipo, MTSA[DFCU08]; esta herramienta permite, dados un par de MTS, chequear si estos sonbisimilares bajo alguna de varias nociones diferentes de bisimulacion [Mil89, vGW96].La implementacion de estos chequeos en MTSA se basa en variantes de los algoritmostradicionales para chequeo de bisimilitud [DPP01, GV90]. Nuestro enfoque sera dife-rente al empleado por el MTSA. Proponemos en este trabajo lo siguiente:

la utilizacion de SAT solver 1 para el chequeo de existencia de relaciones derefinamiento/implementacion entre MTS,

el aprovechamiento de mecanismos avanzados de analisis basado en SAT, comola explotacion de informacion parcial de modelos, para acelerar el proceso deanalisis,

el chequeo de cierto tipo de “meta propiedades” de MTS y las relaciones derefinamiento asociadas.

Por supuesto, debido a que pretendemos utilizar SAT para el analisis de relaciones derefinamiento e implementacion entre MTS, la opcion mas directa serıa la utilizacion dela logica proposicional como lenguaje para la codificacion de LTS/MTS, y la directautilizacion de alguno de los muchos SAT solvers disponibles (por ejemplo, Berkmin[GN07], Minisat [ES03], Zcha! [MFM04], etc). Por el contrario, nuestra propuesta seenfoca en la utilizacion de un lenguaje de especificaciones de mas alto nivel, llama-do Alloy [Jac03], como lenguaje intermedio para la aplicacion de SAT. Este lenguajeposee varias caracterısticas que lo hacen adecuado para esta tarea, tales como:

el lenguaje Alloy, fuertemente basado en la nocion de relacion, permite describirMTS, LTS y las relaciones entre ellos de manera declarativa y clara,

algunas tecnicas importantes de aceleracion en el analisis basado en SAT se en-cuentran disponibles solo a traves de Alloy, y no son soportadas directamentepor SAT solvers (por ejemplo, el aprovechamiento de informacion sobre cotasde relaciones y la aceleracion mediante la eliminacion de modelos isomorfos),

1Un SAT solver es una herramienta que permite responder automaticamente si una formula proposicionales satisfactible

13

el Alloy Analyzer ofrece una traduccion de conceptos necesarios en la descrip-cion de maquinas de estados (LTS, MTS) que maximiza el aprovechamiento delos SAT solvers como herramientas de analisis.

Como mostraremos en este trabajo, el analisis basado en SAT es una opcion vi-able y de gran utilidad para el estudio de MTS. Si bien en los estudios comparativosrealizados la alternativa provista por el MTSA resulto ser mas eficiente, el analisisrealizado utilizando SAT solving se mantuvo en general en el orden de unos pocossegundos. Ademas, debido a la declaratividad del lenguaje de especificaciones utiliza-do, la herramienta resulta ser mas versatil que MTSA, pues puede utilizarse no solopara el chequeo de refinamientos, sino tambien para tareas relacionadas tales como lacomparacion de diferentes alternativas en relaciones de refinamiento/simulacion (porejemplo, en el estudio de adaptaciones de definiciones de estos conceptos, o en la gen-eracion de casos que satisfagan simultaneamente las condiciones de diferentes relacio-nes de simulacion/refinamiento), etc.

A continuacion presentamos algunos conceptos preliminares que seran necesariosen el desarrollo de la tesis. El resto de este trabajo esta organizado de la siguientemanera. En el capıtulo 3, presentamos una caracterizacion de MTS/LTS y relacionesde refinamiento e implementacion en Alloy. Mostramos tambien algunos ejemplos,comparacion de tiempos con otras herramientas, y algunas limitaciones del mecanismode analisis asociado a Alloy con respecto al chequeo de propiedades de MTS/LTS.

En el capıtulo 4 nos embarcamos en un intento de analisis de propiedades de altoorden de MTS, motivados por una propiedad particular: la completitud de refinamientofuerte con respecto a implementaciones. Observaremos en este capıtulo algunas lim-itaciones intrınsecas a la propiedad, que es expresable en Alloy pero no analizable porAlloy Analyzer. Discutiremos varias variantes de expresion de esta propiedad, y unasimplificacion al problema para la generacion de candidatos a contraejemplos de lapropiedad. Tambien veremos como una extension al lenguaje Alloy, llamada DynAl-loy, contribuye en esta tarea de analisis.

Finalmente, en el capıtulo 5 expondremos nuestras conclusiones sobre el trabajo, yen el capıtulo 6 describiremos algunas lıneas de trabajo futuro.

14 1. Introduccion

2 Conceptos preliminares

En este capıtulo proveemos las definiciones de algunos conceptos necesarios enel desarrollo de este trabajo. Comenzaremos reproduciendo las definiciones de lasmaquinas de estados utilizadas, como ası tambien de las diferentes relaciones entreestas que estudiaremos, y analizaremos, en esta tesis.

2.1 Sistemas de Transiciones Etiquetadas

Definicion 2.1.1. Un sistema de transiciones etiquetadas (LTS - labelled transitionsystems) es una estructura P = (S , L,!!", s0) donde S es un conjunto finito de estados,L es un conjunto finito de etiquetas observables mas una etiqueta no observable (osilenciosa) llamada !, !!"# (S $ L $ S ) es una relacion de transicion entre estados, ys0 % S es el estado inicial.

s0

s1

s2 s3

a

cb

Figura 2.1: Ejemplo de un sistema de transiciones etiquetadas

Un sistema de transiciones etiquetadas P = (S , L,!!", s0) permite modelar el com-portamiento de un sistema de la siguiente manera:

el conjunto S representa el espacio de todos los estados posibles que el sistemapuede asumir. El estado inicial s0 % S representa el estado a partir del cual seinicia la ejecucion en el sistema.

las etiquetas en L representan las acciones que el sistema puede ejecutar, o loseventos a los que este puede responder (el evento ! es simplemente utilizadopara modelar acciones privadas del sistema, para las cuales no se quiere asociareventos observables).

15

16 2. Conceptos preliminares

las transiciones en !!" representan el flujo de ejecucion del sistema, es decircomo se progresa de un estado a otro en el sistema a traves de la ejecucion deacciones, o la ocurrencia de eventos. Notemos que, dado que !!" es una relacion,estos modelos admiten naturalmente el no determinismo.

Para clarificar la definicion anterior, consideremos el LTS que se muestra grafi-camente en la Figura 2.1. Podemos ver el conjunto de estados S = {s0, s1, s2, s3}, elde acciones L = {a, b, c} y el conjunto de transiciones permitidas. El estado inicial,s0, esta marcado mediante un arco entrante al nodo, sin origen. Asi, por ejemplo, siestamos en el estado s0 podemos movernos al estado s1 realizando la accion a.

Dados un LTS P = (S , L,!!", s0) y s, s& % S , denotamos mediante sl!!" s&, el

hecho de que s transiciona por l a s& en P, si y solo si (s, l, s&) %!!". De igual manera,

escribimos sl!!" s& para denotar que s

l!!" s& o, l = ! y s = s&. Usamos s

l==' s&

para denotar s(!!!!")(

l!!" (

!!!!")(s&. Por ultimo, utilizamos s

l==' s& para describir

s(!!!!")(

l!!" (

!!!!")(s& o, l = ! y s = s&.

Ademas dado un LTS P = (S , L,!!", s0), denotamos mediante Reach(P) al conjuntode todos los estados de S que son alcanzables (en cero o mas pasos) a partir del estados0 mediante !!".

2.2 Simulaciones y BisimulacionesUna manera de describir a los sistemas es a traves del comportamiento. Quizas la

manera mas simple de dar semantica a LTS es mediante las ejecuciones que estos ad-miten, que es justamente la semantica de trazas (debido a que las ejecuciones puedenrepresentarse mediante trazas (secuencias) de etiquetas). La semantica formal de LTSmediante conjunto de trazas permite realizar numerosas tareas de analisis, entre las quepodemos destacar la comparacion de comportamientos de diferentes LTS. Esto permiteintentar dar respuesta a preguntas tales como ¿son estas descripciones equivalentes?,o ¿es esta descripcion mas fina que esta otra?, o ¿admite este LTS todas las ejecu-ciones de esta otra? Responder este tipo de preguntas tiene infinidad de aplicacionespracticas, tales como reduccion de LTS (minimizacion), o la definicion de relacionesde refinamiento.

Veamos cuando dos sistemas son equivalentes en la semantica de trazas. Segunla semantica de trazas, dos sistemas son equivalentes si permiten el mismo conjuntode observaciones, donde una observacion consiste simplemente en una secuencia deacciones realizadas por el sistema consecutivamente. Diremos que " = a1a2 . . . an esuna traza generada por un LTS P = (S , L,!!", s0), si existen estados s1, s2, . . . , sn % Stal que s0

a1!!!" s1

a2!!!" s2

a3!!!" . . .

an!1!!!!!" sn!1

an!!!" sn. Denotamos tr(P) al conjunto

de trazas generadas por P.Sean P y Q sistemas. Consideremos el conjunto de trazas generado por cada uno

de ellos. El sistema Q es mas expresivo que el sistema P si el conjunto de trazas de Pesta incluido en el conjunto de trazas de Q, esto es tr(P) # tr(Q).

Consideremos por ejemplo los sistemas P y P’ de la figura 2.2, el conjunto detrazas generado por el sistema P es tr(P) = {#, a, ab, ac}, mientras que el generado porel sistema P’ es tr(P’) = {#, a, ab, ac, ad}. Luego, tr(P) # tr(P’).

Si observamos detenidamente la figura 2.2, si realizamos la accion a en el siste-ma P, podemos luego elegir realizar la accion b o c. En el sistema P’, en cambio,dependiendo de que accion a realicemos, quedaremos en una situacion en la que solo

2.2. Simulaciones y Bisimulaciones 17

P s0

s1

s2 s3

a

b c

P& s0

s1 s2

s3 s4 s5

a a

b c d

Figura 2.2: LTS P y P’, donde P’ tiene mayor expresividad que P.

podemos realizar la accion b, o en su defecto en la que solo podemos realizar la accionc. En otras palabras, el sistema P’ tiene menos expresividad respecto del sistema P.Esta diferencia no es detectada a nivel de trazas, lo cual nos lleva a buscar otra formade describir las posibles ejecuciones de un sistema. El instrumento fundamental paracomparar comporamiento de LTS es la nocion de simulacion, y sus derivados, comola bisimulacion. La idea bajo el concepto de simulacion es que dado que P decide re-alizar una accion, entonces el sistema P’ puede imitarlo realizando la misma accion. Siel sistema P’ puede imitar toda accion realizada por P, entonces diremos que P’ simulaa P o que P es simulado por P’.

La nocion de simulacion no es mas que una relacion particular sobre el conjunto deestados de los sistemas involucrados.

Definicion 2.2.1. Una simulacion fuerte (strong simulation) es una relacion r % S $S & entre dos LTS, P = (S , L,!!", s0) y P& = (S &, L&,!!"&, s&0), donde se cumple que(s0, s&0) % r y para todo s1, s2 % Reach(P), s

&1 % Reach(P

&) y l % S ,

s1l!!" s2 y (s1, s&1) % r implica,

s&1l!!"&s&2 y (s2, s

&2) % r, para algun s

&2 % Reach(P’).

Estamos interesados ademas en la equivalencia de sistemas. A nivel de trazas, pode-mos observarlo mediante el conjunto de trazas que cada sistema genera. Si ambos sis-temas generan el mismo, podemos decir que son equivalentes. Pero, al igual que en elcaso anterior, estamos interesados en poder diferenciar la expresividad de los sistemasen cuanto a la libertad de eleccion de eventos a realizar, y es por eso que un metodoobservacional no nos alcanza. Debemos tener en cuenta la estructura de los sistemas.El concepto de bisimulacion nos ayudara con esta descripcion. La idea se basa en quedados dos sistemas P y P’, queremos que, cada vez que uno realice una accion, el otropueda imitarlo. En este caso, el rol de que sistema realiza o imita la accion cambiadurante la ejecucion.

En la siguiente definicion, usaremos )r para denotar la conversa, o transpuesta, deuna relacion binaria r.

Definicion 2.2.2. Una bisimulacion fuerte (strong bisimulation) es una relacion r %S $ S & entre dos LTS, P = (S , L,!!", s0) y P& = (S &, L&,!!"&, s&0), tal que cumple que res una simulacion fuerte entre P y P& y )r es una simulacion fuerte entre P& y P.

Consideremos los ejemplos de la figuras 2.3 y 2.4. Veamos un caso donde se da unabisimulacion fuerte entre los sistemas y uno en el que no.

Hasta ahora, la accion ! no ha recibido un tratamiento diferenciado del resto delas acciones en las definiciones de simulacion y bisimulacion. En otras palabras, !


P1 s0

s1 s2a

b a

b

Q1s0 s1

s2 s3

b

a ab

a

Figura 2.3: Existe una bisimu-lacion fuerte entre P1 y Q1. Estoes, hay al menos una relaciontal que satisface nuestra defini-cion. Una posible relacion es, r ={(s0, s0), (s0, s3), (s1, s1), (s1, s2), (s2, s2)}.

P2 s0

s1

s2 s3

s4 s5

a

b b

c d

Q2 s0

s1 s2

s3 s4

s5 s6

a a

b b

c d

Figura 2.4: No existe una bisimulacionfuerte entre P2 y Q2. Tenemos que(s0, s&0) % r, Q2 decide hacer a, P2 loimita con la unica accion a disponible.Luego (s1, s&1) % r. Ahora P2 deciderealizar b y luego d, cosa que Q2 nopuede imitar.

ha recibido el mismo tratamiento que cualquier otra accion observable en nuestrossistemas. ¿Cual es el rol de las acciones no observables en la (bi)simulacion? Nosinteresa modelar una nocion de bisimulacion teniendo en cuenta que ! es una accionno observable o silenciosa. Esto significa que si un sistema realiza una accion !, el otrosistema no ve este comportamiento y viceversa. Una forma natural de observarlo esmediante las ya definidas funciones ==' y !!". La idea es utilizar ==' en lugar de !!"en nuestras definiciones anteriores. Esto nos va a permitir modelar la accion visible ennuestro sistema cuando ocurra una secuencia de acciones silenciosas y en medio deestas, la accion visible en el otro sistema. Un ejemplo es el de la figura 2.5, en el cualpodemos observar que cuando la accion b ocurra en el sistema P, el sistema P’ la va aimitar realizando las acciones ! y b.

P s0

s1

s2

a

b

P’ s0

s1

s2

s3

a

!

b

Figura 2.5: LTS P y P’, donde P’ imita a P con la ayuda de acciones no observables.

Definicion 2.2.3. Una simulacion debil (weak simulation) es una relacion r % S $ S &

2.2. Simulaciones y Bisimulaciones 19

entre dos LTS, P = (S , L,!!", s0) y P& = (S &, L&,!!"&, s&0) donde se cumple que (s0, s&0) %

r y para todo s1, s2 % Reach(P), s&1 % Reach(P&) y l % S ,

s1l!!" s2 y (s1, s&1) % r implica

s&1l=='&s&2 y (s2, s


&2 % Reach(P

&).

Definicion 2.2.4. Una bisimulacion debil (weak bisimulation) es una relacion r % S$S &entre dos LTS, P = (S , L,!!", s0) y P& = (S &, L&,!!"&, s&0), tal que cumple que r es unasimulacion debil entre P y P& y )r es una simulacion debil entre P& y P.

P3 s0

s1

s2 s3

s4

a

b !

c

Q3 s0

s1

s2 s3

s4

a

b !

c

a

Figura 2.6: Existe una bisimulaciondebil entre P3 y Q3. Esto es, hayal menos una relacion tal que satis-face nuestra definicion. Una posiblerelacion es,r = {(s0, s0), (s1, s1), (s2, s2),(s3, s3), (s4, s4)}.

P4 s0

s1 s2a

b a

b

Q4s0 s1

s2 s3

a

! !a

b

Figura 2.7: No existe una bisimulaciondebil entre P4 y Q4, ya que P4 decidehacer a, luego Q4 lo imita con a, porlo tanto (s1, s3) % r. Ahora Q4 realiza!, por lo que (s1, s3) % r ya que P4 noobserva esta accion. Luego, Q4 decidehacer a, y P4 no puede imitarlo.

Consideremos la figura 2.7, vemos un ejemplo donde dos LTS no son bisimilar-mente debiles, pero en la figura 2.6, estos LTS son bisimilarmente debiles. Con laintencion de diferenciar el comportamiento de sistemas desde un punto de vista mas es-tructural, introducimos la nocion de (bi)simulacion ramificada. Intuitivamente, la ideaes que dos sistemas sean bisimilares bajo esta nueva relacion de bisimulacion “ramifi-cada” si y solo si estos poseen la misma ramificacion.

Definicion 2.2.5. Una simulacion ramificada (branching simulation) es una relacionr % S $ S & entre dos LTS, P = (S , L,!!", s0) y P& = (S &, L&,!!"&, s&0) donde se cumpleque (s0, s&0) % r y para todo s1, s2 % Reach(P), s

&1 % Reach(P

&) y l % S ,

s1l!!" s2 y (s1, s&1) % r implica

s&1!==='&s&2

l!!"&s&3 y (s1, s

&2), (s2, s


&2, s&3 % Reach(P

&).


Definicion 2.2.6. Una bisimulacion ramificada (branching bisimulation) es una relacionr % S $S & entre dos LTS, P = (S , L,!!", s0) y P& = (S &, L&,!!"&, s&0), tal que cumple quer es una simulacion ramificada entre P y P& y )r es una simulacion ramificada entre P&y P.

P5s0 s1

a

b

Q5s0 s1

s2 s3

b

! !

a

Figura 2.8: Existe al menos unarelacion de bisimulacion ramificadaentre P5 y Q5. Una posible relacion esr = {(s0, s0), (s0, s2), (s1, s1), (s1, s3)}.

P6

s0 s1

s2

c

b

a!

Q6s0 s1

s2

c

b

aa!

Figura 2.9: No existe una bisimu-lacion ramificada entre P6 y Q6 ya quesupongamos que P6 realiza b, luegoQ6lo imita con b, luego P6 hace a y Q6lo imita nuevamente. Ahora los rolescambian yQ6 decide hacer c, yP6 no lopuede imitar ya que se encuentra en elestado s0 y dicha acciones no esta ha-bilitada.

Notemos que una relacion que es (bi)simulacion fuerte tambien es (bi)simulacionramificada, y similarmente una (bi)simulacion ramificada es una (bi)simulacion debil.Sin embargo las recıprocas no son ciertas. Consideremos el ejemplo dado de la figu-ra 2.8 entre estos LTS se satisface la bisimulacion ramificada, pero no se satisface labisimulacion fuerte. Por otro lado, en el ejemplo dado por la figura 2.6 tenemos que sesatisface la bisimulacion debil, pero no la bisimulacion branching.

2.3 Sistemas de Transiciones Modales

Los LTS son adecuados como interpretacion del comportamiento de sistemas cuan-do uno cuenta con informacion total sobre los mismos. Por el contrario, cuando unosolo tiene informacion parcial sobre el comportamiento de un sistema, la version tradi-cional de LTS deja de ser adecuada. Existen numerosas razones por las cuales es im-portante poder modelar sistemas parciales. Entre estas esta el hecho de que, en etapastempranas del proceso de desarrollo, es usual conocer solo parcialmente el compor-tamiento del sistema a desarrollar. Contar con modelos formales en estas situacionesnos permite razonar sobre varios aspectos ligados a estos modelos parciales, tales co-mo la correcta correspondencia de implementaciones (modelos totales especificados,por ejemplo, mediante LTS) con respecto a un modelo parcial, o las formas validasde incorporacion de detalles (complementacion de un modelo parcial con informacion

2.4. Refinamientos 21

adicional sobre su comportamiento) en un modelo parcial, es decir, relaciones de refi-namiento entre estas.

Una de las variantes de LTS que incorpora cierta nocion de incertidumbre, nece-saria para modelar sistemas parciales, son los MTS, que describimos formalmente acontinuacion. El lector interesado en mas detalles al respecto, puede consultar [LT88].

Definicion 2.3.1. Un sistema de transiciones modales (MTS - modal transition sys-tems) es una estructura P = (S , L,!!"r,!!"p, s0) donde !!"r#!!"p, P = (S , L,!!"r, s0) esun LTS representado por transiciones requeridas del sistema y P = (S , L,!!"p, s0) esun LTS representado por transiciones posibles (pero no necesariamente requeridas) delsistema.

s0 s1

s2

s3

s4

!?b

ab?

Figura 2.10: Ejemplo de un sistema de transiciones modales

Un sistema de transiciones modales P = (S , L,!!"r,!!"p, s0) permite modelar elcomportamiento de un sistema de la siguiente manera:

el conjunto S representa, al igual que para LTS, el espacio de todos los estadosposibles que el sistema puede asumir. De igual manera, el estado inicial s0 % Srepresenta el estado a partir del cual se inicia la ejecucion en el sistema.

las etiquetas en L representan las acciones que el sistema puede ejecutar, o loseventos a los que este puede responder (el evento ! es simplemente utilizadopara modelar acciones privadas del sistema, para las cuales no se quiere asociareventos observables, al igual que en LTS).

las transiciones en !!"r representan el flujo de ejecucion del sistema que es re-querido, es decir que toda realizacion de P debe admitir. Nuevamente, el hechode que !!"r es una relacion indica que !!"r puede codificar no determinismo.

las transiciones en !!"p representan el flujo de ejecucion del sistema que es pro-bable, es decir que cada realizacion de P tiene la libertad de admitir o no. Encierto sentido, las transiciones probables limitan el grado de libertad con que elmodelo parcial asociado a P puede completarse.

En la Figura 2.10 podemos ver el conjunto de estados S = {s0, s1, s2, s3, s4}, elde acciones L = {!, a, b} y el conjunto de transiciones permitidas. Las transicionesprobables estan indicadas con un signo de interrogacion. Asi, por ejemplo, si estamosen el estado s0 podemos movernos al estado s1 realizando la accion !?, que es unaaccion probable en nuestro sistema.

2.4 RefinamientosHemos visto que la nocion de traza, o ejecucion, no es suficiente como elemen-

to para dar semantica a LTS. Como consecuencia de esto, han surgido diferentes no-ciones de (bi)simulacion, algunas de las cuales hemos reproducido. Ası como existen


buenas razones practicas para contar con mecanismos para comparar LTS respecto desu semantica, estas mismas razones se aplican al caso de especificaciones parciales atraves de MTS. En otras palabras, es importante contar con nociones similares a las de(bi)simulacion vistas, pero que tengan en cuenta la parcialidad de MTS. La nocion queintroduciremos a continuacion es la que permite incorporar detalle a un MTS, esen-cialmente a traves de la “transformacion” de transiciones probables en requeridas, o laeliminacion de transiciones probables.

Dado que un MTS cuenta con dos relaciones de transicion sobrecargamos la no-tacion definida y denotamos por Reach(P) el conjunto de estados alcanzables en P =(S , L,!!"r,!!"p, s0) a partir de s0 mediante (!!"r * !!"p).

Definicion 2.4.1. Un refinamiento fuerte (strong refinement) es una relacion r % S $S &entre dos MTS, P = (S , L,!!"r,!!"p, s0) y P& = (S &, L&,!!"&r,!!"&p, s&0) donde se cumpleque:

(s0, s&0) % r y para todo s1, s2 % Reach(P), s&1 % Reach(P

&) y l % L,

(s1, s&1) % r y s1l!!"r s2 implica

s&1l!!"&r s&2 y (s2, s


&2 % Reach(P)

& y

para todo s&1, s&2 % Reach(P

&), s1 % Reach(P) y l % L&,

(s&1, s1) %)r y s&1

l!!"&ps&2 implica

s1l!!"p s2 y (s&2, s2) %

)r, para algun s2 % Reach(P).

P7

s0

s1s2

a

b

b?c?c?

Q7

s0

s1s2

a

b

b?c

Figura 2.11: Existe un refinamientofuerte entre P7 y Q7. La relacion esr = {(s0, s0), (s1, s1), (s2, s2)}.Pero no existe un refinamiento fuerteentre Q7 y P7. Veamos que Q7 realiza,a, b y c. Luego, P7 lo imita con a, by no puede realizar c ya que no es unatransicion requerida.

En la figura 2.11 podemos observar como P7 es un refinamiento de Q7, y Q7 no esun refinamiento de P7.

Al igual que cuando introducimos bisimulacion fuerte en LTS, no hemos dichonada hasta ahora de las acciones ! en MTS. Estamos interesados, en considerar estasacciones como no observables. Introducimos la nocion de refinamiento debil para poderdescribir este comportamiento.

Definicion 2.4.2. Un refinamiento debil (weak refinement) es una relacion r % S $ S &entre dos MTS, P = (S , L,!!"r,!!"p, s0) y P& = (S &, L&,!!"&r,!!"&p, s&0) se cumple que:

(s0, s&0) % r y para todo s1, s2 % Reach(P), s&1 % Reach(P

&) y l % S ,

2.5. Implementaciones 23

(s1, s&1) % r y s1l!!"r s2 implica

s&1l=='&r s&2 y (s2, s


&2 % Reach(P

&) y


&), s1 % Reach(P) y l % S &,

(s&1, s1) %)r y s&1

l!!"&r s&2 implica

s1l=='r s2 y (s&2, s2) %

)r, para algun s2 % Reach(P).

Analicemos las figuras 2.12 y 2.13; veamos dos ejemplos los cuales en uno sesatisface la propiedad de refinamiento debil, mientras que en el otro no.

P8s0

s1 s2

s3 s4

a !?

b b?

Q8 s0

s1 s2

s3

s4

a b?

!

b

Figura 2.12: Existe un refina-miento debil entre P8 y Q8.Una relacion que satiface es, r ={(s0, s0), (s1, s1), (s1, s3), (s3, s4), (s4, s2)}.

P9s0

s1s2

a

!?

b

c?

Q9s0

s1s2

a

!

b?

c?

Figura 2.13: No existe un refinamien-to debil entre P9 y Q9, notemos que P9realiza a, entonces Q9 la imita con a,luego si P9 realiza !, Q9 se queda qui-eta, porque si hace ! entonces habilita bque como es requerida, Q9 no la puedeimitar. Ahora siQ9 decide hacer c?, en-tonces P9 la tiene que imitar con ! y c,lo cual la habilita para hacer b y Q9 nola puede imitar porque b es probable enQ9

2.5 ImplementacionesHemos descripto dos tipos de sistemas; los LTS que permiten descripciones totales

y los MTS que permiten descripciones parciales de los sistemas. Ahora estamos in-teresados en relacionar ambas descripciones. Por ejemplo queremos poder corroborarsi una descripcion total de un sistema es una representacion de una descripcion parcialdel mismo, o poder corroborar que forma puede tener mi sistema total, a partir de solouna descripcion parcial. En otras palabras queremos ver si dada una especificacion deun sistema, hemos llegado a su correcta implementacion o si dada una implementaciondel sistema, esta es posible a partir de dicha especificacion. Donde la especificacion esuna descripcion parcial. Basandonos en los conceptos anteriores, tomaremos una de-scripcion parcial, esto es un MTS y una descripcion total, un LTS; y verificaremos sientre estos existe alguna relacion de implementacion.


Comenzamos con la definicion de implementacion fuerte.

Definicion 2.5.1. Una implementacion fuerte (strong implementation) es una relacionr % S $ S & entre un MTS P = (S , L,!!"r,!!"p, s0) y un LTS P& = (S &, L&,!!", s&0) el cuales un caso particular de refinamiento fuerte en el cual extendemos el LTS P& a un MTSP& = (S &, L&,!!",!!", s&0).

P10

s0

s1s2

a

b

b?c?c?

Q10s0

s1s2

a

b

Figura 2.14: Existe una im-plementacion fuerte entreP10 y Q10. La relacion esr = {(s0, s0), (s1, s1), (s2, s2)}.

P11s0

s1s2

a

!?

b?

Q11 s0 s1a

b

Figura 2.15: No existe una imple-mentacion fuerte entre P11 y Q11. Laaccion ! es una accion observable parala implementacion fuerte.

Al igual que en los casos anteriores mostramos un caso donde se da una imple-mentacion fuerte entre un MTS y un LTS, y uno en el que no. Notemos que, por elmomento no hemos dicho nada de la accion !. Ahora estamos interesados nuevamenteen considerar a las acciones ! como acciones sileciosas, por tal motivo introducimos lanocion de implementacion debil.

Definicion 2.5.2. Una implementacion debil (weak implementation) es una relacionr % S $ S & entre un MTS P = (S , L,!!"r,!!"p, s0) y un LTS P& = (S &, L&,!!", s&0) el cuales un caso particular de refinamiento fuerte en el cual extendemos el LTS P& a un MTSP& = (S &, L&,!!",!!", s&0).

P12 s0

s1 s2

s3 s4 s5

!? a

a? b !

Q12 s0

s1

s2 s3

a

b !

aFigura 2.16: Existe una imple-mentacion debil entre P12 y Q12. Larelacion de implementacion debil es,r = {(s0, s0), (s2, s1), (s4, s2), (s5, s3)}.

Vemos en la figura 2.16 y la figura 2.17 un caso en el que se da la implementacionweak y un caso en el que no. Por ultimo introducimos la nocion de implementacionramificada dada por Fishbein en [Fis06]. La idea es ademas de considerar a ! como ac-ciones no observables o silenciosas, poder observar el comportamiento desde un puntode vista mas estructural.

2.5. Implementaciones 25

P13 s0

s1 s2

s3 s4 s5

!? a

a? b c

Q13 s0

s1 s2

s3 s4

a a

b c

Figura 2.17: No existe una imple-mentacion debil entre P13 yQ13 debidoa que, supongamos que P13 decide hac-er a, luego Q13 decide imitarlo y hacea llegando al estado s2. P13 ahora haceb y Q13 no puede imitarlo, ya que notiene habilitada dicha accion.

Definicion 2.5.3. Una implementacion ramificada (branching implementation) es unarelacion r % S $S & entre un MTS P = (S , L,!!"r,!!"p, s0) y un LTS P’ = (S &, L&,!!", s&0)tal que,

(s0, s&0) % r y para todo s1, s2 % Reach(P), s&1 % Reach(P’) y l % S ,

(s&1, s1) % r, s1l!!"r s2 implica s&i

!!!!" s&i+1 y (s1, s

&i+1) % r, 1 + i + 1 <

n + 1 y s&nl!!" s&n+1 y (s1, s

&n+1) % r, para algun s

&2, . . . , s

&n+1 %

Reach(P’).


&) y s1 % Reach(P) y l % S &,

(s1, s&1) %)r y s&1

l!!" s&2 implica si

!!!!"p si+1 y (s&1, si+1) %

)r, 1 + i+1 < n+1

y snl!!"p sn+1 y (s&1, sn+1) %

)r, para algn s2, . . . , sn+1 % Reach(P).

P14s0 s1

s2 s3

a

c? b

!?

c

Q14s0 s1

s2 s3

a

c !

b

Figura 2.18: Existe una imple-mentacion ramificada entre P14 yQ14. Una relacion que satisface esr = {(s0, s0), (s2, s1), (s4, s2), (s5, s3)}

P12 s0

s1 s2

s3 s4 s5

!? a

a? b !

Q12 s0

s1

s2 s3

a

b !

aFigura 2.19: No existe una imple-mentacion ramificada entre P12 y Q12.Ya que como podemos observar son di-ferentes estructuras.

3 Modelado de MTS y LTSen Alloy

Como describimos anteriormente, la intencion de este trabajo es utilizar SAT sol-ving para el analisis de relaciones de refinamiento e implementacion entre LTS y MTS.Utilizaremos para esto, como lenguaje de modelado intermedio, el lenguaje de especi-ficaciones Alloy, que nos brinda construcciones al nivel de abstraccion adecuado paramodelar estos formalismos y las relaciones entre ellos.

Modelar LTS yMTS en Alloy nos permite ademas aprovechar algunos mecanismosde mejora al analisis basado en SAT, tales como la eliminacion de modelos isomorfos[JJD98] y el aprovechamiento de informacion sobre cotas en la generacion de formulasproposicionales para analizar mediante SAT solver.

La razon por la cual consideramos a Alloy en el nivel de abstraccion adecuado parala especificacion de LTS y MTS es que este lenguaje da a la nocion de relacion, fun-damental en las definiciones de LTS y MTS, un rol central. Es tambien importante quela clausura transitiva, crucial en la definicion de relaciones de simulacion/refinamiento,es directamente soportada en Alloy. Las caracterizaciones que daremos a continuacionson lo suficientemente claras como para que incluso el lector no familiarizado conAlloy las pueda comprender. Referimos sin embargo al Apendice B para mas detallessobre el lenguaje.

3.1 Definicion de UniversosComenzaremos con la definicion de los universos necesarios para LTS y MTS.

Claramente necesitamos la definicion de dominios para estados y etiquetas. Mas aun,debemos exigir la existencia de !, la accion “silenciosa”, como etiqueta valida. Paradeclarar dominios en Alloy, se utilizan signaturas:

ab s t r a c t s i g S t a t e { }s i g CSta t e ex tends S t a t e { }

ab s t r a c t s i g Act ion { }s i g CAction ex tends Act ion { }one s i g Tau ex tends Act ion { }

En las definiciones anteriores, cada signatura define un dominio, y signaturas di-ferentes definen, en principio, dominios disjuntos. La excepcion a esta regla la consti-tuyen las signaturas relacionadas por extension (en el modulo anterior, las signaturasCState y State, por ejemplo). Cuando una signatura extiende a otra, la primera define

27

28 3. Modelado de MTS y LTS en Alloy

un subdominio de la segunda. Ademas, los subdominios distintos de una signatura sondisjuntos. Notemos la declaracion de ! a traves de la signatura Tau. Esto puede con-fundir al lector no familizarizado con Alloy, pues estamos utilizando signaturas paradeclarar tanto dominios como elementos (constantes) de los mismos. La razon de estoes que Alloy no permite definir constantes en los modelos: las constantes son parte delas interpretaciones de los modelos, y no de los modelos. Luego, cuando es necesarioreferirse a elementos particulares, estos se modelan a traves de signaturas unitarias, enlas que se fuerza la existencia de exactamente un elemento mediante el modificador“one”.

Finalmente, notemos el uso del modificador “abstract” en la declaracion de algunassignaturas. Este modificador indica que la signatura no tiene elementos “propios”, sinoque su dominio asociado estara compuesto exclusivamente por la union de los dominiosde sus subsignaturas. El lector familiarizado con orientacion a objetos seguramenteobservara una relacion entre signaturas abstractas y extension con las nociones de claseabstracta y herencia, repectivamente.

Con las signaturas definidas mas arriba, los universos de LTS y MTS pueden ca-racterizarse directamente, nuevamente mediante signaturas, de la siguiente manera:

/ ( s i g n a t u r e LTS : d e f i n i t i o n o f l a b e l l e d t r a n s i t i o n s y s t em . ( /

/ ( Ac t i o n s and s t a t e s o f t h e LTS are i m p l i c i t l y ( /

/ ( t h o s e men t ioned i n i n i t and t r a n s . ( /

/ ( An LTS i s t h en s imp l y an i n i t i a l s t a t e p l u s a ( /

/ ( t r a n s i t i o n r e l a t i o n . ( /

ab s t r a c t s i g LTS {i n i t : one S t a t e ,t r a n s : ( Ac t i on !> S t a t e ) !> S t a t e

}

/ ( s i g n a t u r e MTS: d e f i n i t i o n o f modal t r a n s i t i o n s y s t em . A c t i o n s ( /

/ ( and s t a t e s o f t h e MTS are i m p l i c i t l y t h o s e ( /

/ ( men t ioned i n i n i t and t . ( /

/ ( An MTS i s s imp l y an LTS i n which some o f t h e ( /

/ ( t r a n s i t i o n s are marked as r e q u i r e d ( /

ab s t r a c t s i g MTS {i n i t : one S t a t e ,t r a n s : ( Ac t i on !> S t a t e ) !> S t a t e ,r eq : ( Ac t i on !> S t a t e ) !> S t a t e

}

{

r eq in t r a n s}

Notemos que, al no considerar el conjunto de estados como parte de un LTS oMTS, algunos LTS o MTS no pueden ser representados. Consideremos por ejemplo elsiguiente LTS:

s0

s1s2s3a

!?b?

Figura 3.1: Ejemplo de un sistema de transiciones modales no conexo

3.2. Transiciones y funciones auxiliares 29

Como el nodo s3 no es inicial y no esta involucrado en la relacion de transicion, no lopodrıamos representar en nuestro modelo de LTS anterior. Sin embargo, esta perdidano nos afecta para lo que estamos interesados en representar y analizar, y evitamostener que definir un atributo extra en nuestros LTS y MTS.

En la definicion de LTS y MTS tambien hemos utilizado signaturas, esta vez conatributos asociados. Estas signaturas, ademas de definir dominios declaran relacionespara cada uno de los distintos campos definidos, del perfil y aridad declaradas. Asi,por ejemplo, req es una relacion con perfil MTS $ Action $ State $ State, total yfuncional en el primer argumento. La restriccion “las transiciones requeridas son partedel conjunto global de transiciones” se fuerza mediante un hecho (fact) ligado a lasignatura MTS.

Notemos que, en estas definiciones, las etiquetas son ubicadas al comienzo en lasrelaciones de transicion, ya sean requeridas o probables. La razon de esto es simple-mente para poder “proyectar”facilmente la relacion entre estados, es decir, hacerlasindependientes de las etiquetas, mediante la composicion relacional, uno de los oper-adores relacionales disponibles en Alloy.

3.2 Transiciones y funciones auxiliares

Con los LTS yMTS definidos, podemos intentar definir las nociones de simulacion,bisimulacion, refinamiento e implementacion. Para simplificar la lectura de especifi-caciones, introducimos varias definiciones auxiliares que representan varios tipos de“transiciones”. Estas definiciones son encapsuladas en predicados Alloy. Un predicadoAlloy es simplemente una formula parametrizada (es decir, con variables libres), al es-tilo de los esquemas en Z [Dil94]. Los tipos de transiciones y funciones auxiliares sonlos siguientes:

s1a!!!" s2

/ ( s imp l e arrow : s i n g l e t r a n s i t i o n be tween s t a t e s ( /

pred ar row( t : ( Ac t i on !> S t a t e ) !> S t a t e , s1 , s2 : S t a t e , a : Ac t i on ) {

a !> s1 !> s2 in t}

s1a!!!" s2

/ ( s imp l e ” r oo f e d ” arrow : s i n g l e t r a n s i t i o n or s i l e n t s t e p ( /

pred arrowT( t : ( Ac t i on !> S t a t e ) !> S t a t e , s1 , s2 : S t a t e , a : Ac t i on ) {

a !> s1 !> s2 in t or ( a = Tau and s1 = s2 )}

s1a===' s2

/ ( Double Arrow ( /

/ ( s i n g l e t r a n s i t i o n preceded and succeded by p o t e n t i a l l y many ( /

/ ( s i l e n t s t e p s ( /

pred clTArrowClT( t : ( Ac t i on !> S t a t e ) !> S t a t e , s1 , s2 : S t a t e , a : Ac t i on ) {

s1 !> s2 in ( ( ( ( t [ Tau ] ) ) . ( t [ a ] ) . ( ( ( t [ Tau ] ) ) )}


s1a===' s2

/ ( Double arrow ( /

/ ( S i n g l e t r a n s i t i o n or s i l e n t s t ep , p receded and succeded by ( /

/ ( p o t e n t i a l l y many s i l e n t s t e p s ( /pred clTArrowTClT

( t : ( Ac t i on !> S t a t e ) !> S t a t e , s1 , s2 : S t a t e , a : Ac t i on ) {s1 !> s2 in ( ( ( ( t [ Tau ] ) ) . ( t [ a ] ) . ( ( ( t [ Tau ] ) ) )or ( a = Tau and s1 = s2 )

}

la siguiente funcion toma un conjunto de transiciones y lo complementa con todaslas transiciones ! posibles. Sera utilizado para modelar el predicado de simulaciondebil.

/ ( augTauT ran s i t i o n : ”augments” a s e t o f t r a n s i t i o n s w i t h a l l ( /

/ ( p o s s i b l e t au t r a n s i t i o n s ( /

fun a u gTauT r a n s i t i o n( t : ( Ac t i on !> S t a t e ) !> S t a t e ) : ( Ac t i on !> S t a t e ) !> s e t S t a t e {

t + ( Tau !> ( iden & ( S t a t e !> S t a t e ) ) )}

la siguiente funcion toma un conjunto de transiciones y un conjunto de estados, ycalcula la preimagen del conjunto de estados tomados respecto de la clausura reflexo-transitiva de las transiciones, complementadas con !:

/ ( preImageClTau : Computes t h e pre image o f ˜ s e t o f s t a t e s C , ( /

/ ( wi t h r e s p e c t t o t h e r e f l e x i v e ! t r a n s i t i v e c l o s u r e ( // ( o f a s e t o f t r a n s i t i o n s complemented w i t h s i l e n t ( // ( s t e p s ( /fun preImageClTau( t : ( Ac t i on !> S t a t e ) !> S t a t e , C : s e t S t a t e ) : s e t ( S t a t e !> S t a t e ) {

( ( ( t [ Tau ] ) & ( S t a t e !> C) )}

En las definiciones anteriores hicimos uso de varios elementos sintacticos de Alloy,que explicaremos a continuacion. Utilizando las variables y constantes relacionalesdeclaradas como signaturas, campos de signaturas y parametros de predicados, pode-mos formar terminos relacionales. Podemos hacerlo usando el producto (->), union(+), interseccion (&), composicion (·), conversa ()), clausura transitiva (ˆ) y clausurareflexo-transitiva ((). Con estos podemos construir formulas atomicas mediante in-clusion relacional (in) e igualdad relacional (=). Los conectivos (! es la negacion, andla conjuncion, or la dijuncion) y los cuantificadores (all y some son los cuantificadoresuniversal y existencial, respectivamente) nos permiten formar formulas compuestas.Es importante mencionar que todos los terminos en Alloy denotan relaciones; por esto,los elementos se representan mediante singletones, es decir, relaciones unarias de car-dinal uno (ası, la inclusion relacional “in” puede usarse para representar pertenencia).Recomendamos al lector consultar el Apendice B para mas detalle sobre la sintaxis ysemantica de Alloy, o referirse a [Jac06].

Notese la importancia de la clausura reflexo-transitiva en la definicion de variasde las transiciones definidas. Es importante hacer notar que, sin el operador relacionalde clausura, nos serıa imposible definir varias de estas transiciones dado que Alloy esesencialmente un lenguaje de primer orden.

3.3. Relaciones entre LTS y MTS 31

3.3 Relaciones entre LTS y MTS

Definidos los LTS, MTS y funciones auxiliares, estamos en condiciones de modelarlas definiciones de bisimulacion, refinamiento e implementacion introducidas anterior-mente. La manera de modelarlas en Alloy es mediante predicados, de la misma formaque utilizamos estos para definir los tipos de transiciones.

3.3.1 Simulaciones y BisimulacionesSimulacion Fuerte/ ( S t a t e s t h a t r i s a s t r o n g s im u l a t i o n be tween LTS l 1 and LTS l 2 . ( /pred S t r o n gS imu l a t i o n ( r : S t a t e !> S t a t e , l1 , l 2 : LTS ) {

a l l a : Ac t i on | ( ˜ r ) . ( l 1 . t r a n s [ a ] ) in ( l 2 . t r a n s [ a ] ) . ( ˜ r )}

Bisimulacion Fuerte/ ( S t a t e s t h a t r i s a s t r o n g b i s i m u l a t i o n be tween LTS l 1 and l 2 ( /

pred S t r o n gB i s imu l a t i o n ( r : S t a t e !> S t a t e , l1 , l 2 : LTS ) {S t r o n gS imu l a t i o n [ r , l1 , l 2 ] andS t r o n gS imu l a t i o n [ ˜ r , l2 , l 1 ]

}

Simulacion Ramificada/ ( S t a t e s t h a t r i s a b ranch ing s im u l a t i o n be tween LTS l 1 and l 2 . ( /

pred Br an ch i n gS imu l a t i o n ( r : S t a t e !> S t a t e , l1 , l 2 : LTS ) {a l l s1 , s2 , s3 : S t a t e | a l l a : Ac t i on |

( a r row [ l 1 . t r a n s , s1 , s2 , a ] and s1 !> s3 in r )imp l i e s( some s4 , s5 : S t a t e |

s3 !> s4 in ( preImageClTau [ l 2 . t r a n s , s1 . r ] ) andarrowT [ l 2 . t r a n s , s4 , s5 , a ] ands1 !> s4 + s2 !> s5 in r

)}

Bisimulacion Ramificada/ ( S t a t e s t h a t r i s a b ranch ing b i s i m u l a t i o n be tween LTS l 1 and l 2 . ( /pred Br a n c h i n gB i s imu l a t i o n ( r : S t a t e !> S t a t e , l1 , l 2 : LTS ) {

Br an ch i n gS imu l a t i o n [ r , l1 , l 2 ] andBr an ch i n gS imu l a t i o n [ ˜ r , l2 , l 1 ]

}

Simulacion Debil/ ( S t a t e s t h a t r i s a weak s im u l a t i o n be tween LTS l 1 and LTS l 2 . ( /

pred WeakSimula t ion ( r : S t a t e !> S t a t e , l1 , l 2 : LTS ) {a l l a : Ac t i on | ( ˜ r ) . ( l 1 . t r a n s [ a ] ) in

( ( ( ( l 2 . t r a n s [ Tau ] ) ) . ( ( a u gTauT r a n s i t i o n [ l 2 . t r a n s ] ) [ a ] ) .( ( ( l 2 . t r a n s [ Tau ] ) ) ) . ( ˜ r )

}

Bisimulacion Debil


/ ( S t a t e s t h a t r i s a weak b i s i m u l a t i o n be tween LTS l 1 and LTS l 2 . ( /pred WeakBis imu la t i on ( r : S t a t e !> S t a t e , l1 , l 2 : LTS ) {

WeakSimula t ion [ r , l1 , l 2 ] andWeakSimula t ion [ ˜ r , l2 , l 1 ]

}

3.3.2 RefinamientosRefinamiento Fuerte/ ( S t a t e s t h a t r i s a s t r o n g r e f i n em e n t be tween MTS m1 and MTS m2 . ( /pred S t r ongRe f i n emen t ( r : S t a t e !> S t a t e , m1 , m2 : MTS) {

a l l a : Ac t i on | ( ˜ ( r ) ) . ( m1 . r eq [ a ] ) in m2 . r eq [ a ] . ( ˜ ( r ) )a l l a : Ac t i on | ( ˜ ( r ) ) . ( m2 . t r a n s [ a ] ) in m1 . t r a n s [ a ] . ( ˜ ( r ) )

}

Refinamiento Debil/ ( S t a t e s t h a t r i s a weak r e f i n em e n t be tween MTS m1 and MTS m2 . ( /

pred WeakRefinement ( r : S t a t e !> S t a t e , m1 , m2 : MTS) {a l l a : Ac t i on | ( ˜ r ) . ( m1 . r eq [ a ] ) in

( ( ( (m2 . r eq [ Tau ] ) ) . ( ( a u gTauT r a n s i t i o n [m2 . r eq ] ) [ a ] ) .( ( (m2 . r eq [ Tau ] ) ) ) . ( ˜ r )

a l l a : Ac t i on | ( ˜ r ) . ( m2 . t r a n s [ a ] ) in( ( ( (m1 . t r a n s [ Tau ] ) ) . ( ( a u gTauT r a n s i t i o n [m1 . t r a n s ] ) [ a ] ) .

( ( (m1 . t r a n s [ Tau ] ) ) ) . ( ˜ r )}

3.3.3 ImplementacionesImplementacion Fuerte/ ( S t a t e s t h a t r i s a s t r o n g imp l emen t a t i o n be tween MTS m and l ( /

pred S t r o ng Imp l emen t a t i o n ( r : S t a t e !> S t a t e , m: MTS, l : LTS ) {a l l a : Ac t i on | ( ˜ ( r ) ) . (m. r eq [ a ] ) in l . t r a n s [ a ] . ( ˜ ( r ) )a l l a : Ac t i on | ( ˜ ( r ) ) . ( l . t r a n s [ a ] ) in m. t r a n s [ a ] . ( ˜ ( r ) )

}

Implementacion Debil/ ( S t a t e s t h a t r i s a weak imp l emen t a t i o n be tween MTS m and LTS l . ( /pred WeakImplementa t ion ( r : S t a t e !> S t a t e , m: MTS, l : LTS ) {

a l l a : Ac t i on | ( ˜ r ) . (m. r eq [ a ] ) in( ( ( ( l . t r a n s [ Tau ] ) ) . ( ( a u gTauT r a n s i t i o n [ l . t r a n s ] ) [ a ] ) .

( ( ( l . t r a n s [ Tau ] ) ) ) . ( ˜ r )a l l a : Ac t i on | ( ˜ r ) . ( l . t r a n s [ a ] ) in

( ( ( (m. t r a n s [ Tau ] ) ) . ( ( a u gTauT r a n s i t i o n [m. t r a n s ] ) [ a ] ) .( ( (m. t r a n s [ Tau ] ) ) ) . ( ˜ r )

}

Implementacion Ramificada/ ( S t a t e s t h a t r i s a b ranch ing imp l emen t a t i o n be tween MTS m and l . ( /pred Branch i ng Imp l emen t a t i o n ( r : S t a t e !> S t a t e , m: MTS, l : LTS ) {

a l l s1 , s2 : S t a t e | a l l a : Ac t i on | a l l s3 : S t a t e |ar row [m. req , s1 , s2 , a ] and s1 !> s3 in rimp l i e s( some s4 , s5 : S t a t e |

s3 !> s4 in ( preImageClTau [ l . t r a n s , s1 . r ] ) and

3.4. Analisis de algunas propiedades elementales 33

arrowT [ l . t r a n s , s4 , s5 , a ] and s2 !> s5 in r)

a l l s1 , s2 : S t a t e | a l l a : Ac t i on | a l l s3 : S t a t e |ar row [ l . t r a n s , s1 , s2 , a ] and s1 !> s3 in ˜ rimp l i e s( some s4 , s5 : S t a t e |

s3 !> s4 in ( preImageClTau [m. t r a n s , s1 . ( ˜ r ) ] ) andarrowT [m. t r a n s , s4 , s5 , a ] and s2 !> s5 in ˜ r

)}

3.4 Analisis de algunas propiedades elementalesUna de las caracterısticas mas importantes de Alloy es que, ademas de poseer

una sintaxis y semantica simple y precisa, provee un mecanismo de analisis comple-tamente automatico. Esto evita que el desarrollador necesite manipular expresionesmatematicas en las tareas de analisis (aunque claramente necesitara manipularlas aldescribir formalmente sus modelos en el lenguaje). El mecanismo de analisis de Alloyse basa en SAT solving, y su facilidad de aplicacion (brindada por su completa autom-atizacion) tiene un costo importante en el alcance de las respuestas que nos brindan.El mecanismo funciona, basicamente, de la siguiente manera: dada una especificacionSpec, el analizador acepta formulas de la siguiente naturaleza:

corridas (runs), que se interpreta como escenarios o casos particulares de Spec.

aserciones (assertions), que se interpretan como potenciales consecuencias de Spec.

En el caso de las corridas, el analizador intenta construir modelos de

Spec and run

(donde run es la corrida provista), mientras que en el caso de las aserciones el anali-zador busca construir modelos de

Spec and (not assert)

(donde assert es la asercion provista).Para realizar esta busqueda de modelos de manera automatica, se requiere con-

tar con un procedimiento de decision para la logica relacional (la logica subyacente aAlloy). Sin embargo, la logica relacional es una extension de la logica de primer orden,y por lo tanto, no existen algoritmos de decision para la misma. Por este motivo, elanalizador requiere que el usuario provea cotas para los dominios. El analizador nosdara una respuesta positiva si encuentra un modelo de la formula correspondiente den-tro de las cotas dadas; el analizador dara una respuesta negativa en el caso en el cual laformula sea insatisfactible dentro de las cotas provistas. Por supuesto, que una formulano tenga modelos dentro de las cotas provistas no garantiza su insatisfactibilidad gene-ral, pues podrıa tener modelos si ampliamos las cotas. El Alloy Analyzer, la herramien-ta de analisis de Alloy, entra entonces en la categorıa de model finders (como MACE[McC03] y PARADOX [Cla03]). La forma en la cual realiza la busqueda es medianteuna traduccion de las formulas Alloy (con las correspondientes cotas) a una formulaproposicional, y el uso de SAT solver para comprobar su satisfactibilidad. La utilidadde este mecanismo es justificada por la llamada hipotesis del alcance pequeno (smallscope hypothesis), que dice basicamente que en la practica, cuando nuestras formulas


corresponden a especificaciones de software, si una propiedad tiene contraejemplos, engeneral los tiene de tamano pequeno [Jac06].

El lector puede encontrar mas detalles al respecto en el Apendice B.Con nuestra especificacion de LTS y MTS, y las definiciones de las diferentes re-

laciones de refinamiento y simulacion, ya estamos en condiciones de realizar algunastareas de analisis sobre algunas propiedades elementales.

Por ejemplo, podemos preguntarnos si existe algun tipo de relacion particular entreun par de LTS particulares. Es decir, dadosP1 yQ1, preguntarnos, por ejemplo, ¿son P1y Q1 bisimilares? Esta pregunta se reduce por supuesto a la existencia de una relacionentre los estados de P1 y Q1, que los haga bisimilares.

Para analizar esto necesitamos representar a P1 y Q1 en Alloy, complementandonuestra especificacion de LTS, MTS y relaciones de simulacion/refinamiento. Esto in-cluye:

1. Definicion de los universos particulares de estados y acciones (los usados por P1y Q1).

2. Caracterizacion de las estructuras de P1 y Q1 (mediante signaturas).

3. Generacion de un predicado asociado a la propiedad a analizar.

Por ejemplo, sean P1 y Q1 los vistos en 2.3, y supongamos que la propiedad a co-rroborar es bisimulacion fuerte. Por lo tanto en Alloy esto nos queda de la siguientemanera:

module BisSopen l i b r a r y

one s i g S0 , S1 , S2 , S3 ex tends S t a t e { }one s i g A, B ex tends Act ion { }

one s i g P1 ex tends LTS { } {i n i t = S0t r a n s = A !> S0 !> S1 + B !> S1 !> S0 + A !> S0 !> S2

+ B !> S2 !> S0}

one s i g Q1 ex tends LTS { } {i n i t = S0t r a n s = A !> S0 !> S2 + B !> S2 !> S3 + A !> S3 !> S2

+ A !> S3 !> S1 + B !> S1 !> S0}

pred BisS ( r : S t a t e !> S t a t e ) {P1 . i n i t !> Q1 . i n i t in r

and S t r o n gB i s imu l a t i o n [ r , P1 . t r a n s , Q1 . t r a n s ]}

run BisS f o r 5

Este predicado sera analizado mediante una corrida, lo cual lo hacemos mediante elcomando run. Obtenemos en este caso una instancia de r que hace al predicado valido.Suponiendo que no exista una r que haga valido el predicado, entonces obtendremoscomo respuesta que no existe una instancia tal que satisfaga dicho predicado.

Notese que, en este caso, la respuesta del analizador es absoluta, en el sentido quesi P1 y Q1 son bisimilares, el analizador encontrara una bisimulacion (y viceversa). En

3.5. Algunas mejoras al modelado 35

otras palabras, la cota 5 es suficiente para realizar un analisis completo: si no existenmodelos de la propiedad dentro de esa cota no existen de ningun tamano posible. Porsupuesto esto es una excepcion y no corresponde al caso general en el uso de Alloy ysu analizador.

Otro ejemplo de propiedades que podemos analizar mediante el analizador de Alloyes la siguiente. Supongamos que tenemos una relacion entre LTS o MTS, y queremoscorroborar si existen instancias de MTS o LTS que no satisfagan las condiciones de estarelacion. Siguiendo con el mismo ejemplo de antes, queremos saber si existe un P1 y unQ1, tal que no esten relacionados por la relacion de interes definida. La forma de mod-elar este tipo de problemas es mediante aserciones; en otras palabras, queremos unainstancia de P1 y Q1 tal que no satisfagan los requisitos para estar relacionados. Esto locorroboramos sobre una asercion, utilizando el comando assert. Podemos ver este tipode asercion, para el caso particular en el que la relacion de interes es la bisimulacionfuerte.

module BisSopen l i b r a r y

one s i g S0 , S1 , S2 , S3 ex tends S t a t e { }one s i g A, B ex tends Act ion { }

one s i g P1 ex tends LTS { }one s i g Q1 ex tends LTS { }

a s s e r t BisS {a l l r : S t a t e !> S t a t e | P1 . i n i t !> Q1 . i n i t in r

imp l i e s ! S t r o n gB i s imu l a t i o n [ r , P1 . t r a n s , Q1 . t r a n s ]}

check BisS f o r 5

Si obtenemos una instancia de P1, Q1 y r, entonces estamos delante de un ejemploen el cual P1 no es un refinamieno de Q1. En caso que no obtengamos una instancia,es porque para todas las instancias de LTS, es valida dicha asercion, dentro de las cotasprovistas.

Es importante notar que otras herramientas como elMTSA [DFCU08] yMTSCheck-er [Fis06] no pueden analizar este tipo de propiedades; en estas herramientas solo esposible analizar la existencia de relaciones de simulacion/refinamiento para MTS/LTSdados.

3.5 Algunas mejoras al modeladoEn el capıtulo anterior hemos visto como a partir de las definiciones de simula-

ciones definimos las bisimulaciones y refinamientos, y de la misma manera, como apartir de las nociones de refinamientos introducimos las definiciones de implementa-ciones. Como hemos modelado hasta el momento las propiedades, es imposible definir-las en funcion de las otras, ya que en algunos casos trabajamos con LTS y en otros conMTS. La idea en esta optimizacion de modelado es trabajar los predicados a nivel detransiciones y olvidarnos que estos estan sumergidos en el contexto de un LTS o MTS.De esta manera logramos trabajar directamente con las transiciones siendo mas con-creto y mas claro en las definiciones y a partir de esto, los predicados mas complejosdefinirlos en funcion de los mas simples. Asi reutilizamos definiciones y las mismas


quedan estructuralmente definidas, esto es, las bisimulaciones y refinamientos en fun-cion de las simulaciones, y las implementaciones en funcion de los refinamientos.

3.5.1 Simulaciones y BisimulacionesSimulacion Fuerte/ ( S t a t e s t h a t r i s a s t r o n g s im u l a t i o n be tween t r a n s i t i o n s ( /

/ ( t 1 and t 2 ( /

pred S t r o n gS imu l a t i o n( r : S t a t e !> S t a t e , t1 , t 2 : ( Ac t i on !> S t a t e ) !> S t a t e ) {

a l l a : Ac t i on | ( ˜ ( r ) ) . ( t 1 [ a ] ) in t 2 [ a ] . ( ˜ ( r ) )}

Bisimulacion Fuerte/ ( S t a t e s t h a t r i s a s t r o n g b i s i m u l a t i o n be tween t r a n s i t i o n s ( /

/ ( t 1 and t 2 ( /

pred S t r o n gB i s imu l a t i o n( r : S t a t e !> S t a t e , t1 , t 2 : ( Ac t i on !> S t a t e ) !> S t a t e ) {

S t r o n gS imu l a t i o n [ r , t1 , t 2 ] andS t r o n gS imu l a t i o n [ ˜ r , t2 , t 1 ]

}

Simulacion Ramificada/ ( S t a t e s t h a t r i s a b ranch ing s im u l a t i o n be tween t r a n s i t i o n s ( /

/ ( t 1 and t 2 ( /

pred Br an ch i n gS imu l a t i o n( r : S t a t e !> S t a t e , t1 , t 2 : ( Ac t i on !> S t a t e ) !> S t a t e ) {a l l s1 , s2 , s3 : S t a t e | a l l a : Ac t i on |( a r row [ t1 , s1 , s2 , a ] and s1 !> s3 in r )imp l i e s( some s4 , s5 : S t a t e |s3 !> s4 in ( preImageClTau [ t2 , s1 . r ] ) andarrowT [ t2 , s4 , s5 , a ] and s1 !> s4 + s2 !> s5 in r

)}

Bisimulacion Ramificada/ ( S t a t e s t h a t r i s a b ranch ing b i s i m u l a t i o n be tween t r a n s i t i o n s ( /

/ ( t 1 and t 2 ( /

pred Br a n c h i n gB i s imu l a t i o n( r : S t a t e !> S t a t e , t1 , t 2 : ( Ac t i on !> S t a t e ) !> S t a t e ) {

Br an ch i n gS imu l a t i o n [ r , t1 , t 2 ] andBr an ch i n gS imu l a t i o n [ ˜ r , t2 , t 1 ]

}

Simulacion Debil/ ( S t a t e s t h a t r i s a weak s im u l a t i o n be tween t r a n s i t i o n s ( /

/ ( t 1 and t 2 ( /

pred WeakSimula t ion( r : S t a t e !> S t a t e , t1 , t 2 : ( Ac t i on !> S t a t e ) !> S t a t e ) {

a l l a : Ac t i on | ( ˜ r ) . ( t 1 [ a ] ) in( ( ( ( t 2 [ Tau ] ) ) . ( ( a u gTauT r a n s i t i o n [ t 2 ] ) [ a ] ) . ( ( ( t 2 [ Tau ] ) ) ) . ( ˜ r )

}

3.5. Algunas mejoras al modelado 37

Bisimulacion Debil/ ( S t a t e s t h a t r i s a weak b i s i m u l a t i o n be tween t r a n s i t i o n s ( /

/ ( t 1 and t 2 ( /

pred WeakBis imu la t i on( r : S t a t e !> S t a t e , t1 , t 2 : ( Ac t i on !> S t a t e ) !> S t a t e ) {

WeakSimula t ion [ r , t1 , t 2 ] andWeakSimula t ion [ ˜ r , t2 , t 1 ]

}

3.5.2 RefinamientosRefinamiento Fuerte/ ( S t a t e s t h a t r i s a s t r o n g r e f i n em e n t be tween t r a n s i t i o n s t 1 ( /

/ ( ( r e q u i r e d and maybe ) and t 2 ( r e q u i r e d and maybe ) . ( /

pred S t r ongRe f i n emen t( r : S t a t e !> S t a t e , t1p , t 1 r , t2p , t 2 r : ( Ac t i on !> S t a t e ) !> S t a t e ) {

S t r o n gS imu l a t i o n [ r , t 1 r , t 2 r ] andS t r o n gS imu l a t i o n [ ˜ r , t2p , t 1p ]

}

Refinamiento Debil/ ( S t a t e s t h a t r i s a weak r e f i n em e n t be tween t r a n s i t i o n s t 1 ( /

/ ( ( r e q u i r e d and maybe ) and t 2 ( r e q u i r e d and maybe ) . ( /

pred WeakRefinement( r : S t a t e !> S t a t e , t1p , t 1 r , t2p , t 2 r : ( Ac t i on !> S t a t e ) !> S t a t e ) {

WeakSimula t ion [ r , t 1 r , t 2 r ] andWeakSimula t ion [ ˜ r , t2p , t 1p ]

}

3.5.3 ImplementacionesImplementacion Fuerte/ ( S t a t e s t h a t r i s a s t r o n g imp l emen t a t i o n be tween t r a n s i t i o n s t 1 ( /

/ ( ( r e q u i r e d and maybe ) and t 2 . ( /

pred S t r o ng Imp l emen t a t i o n( r : S t a t e !> S t a t e , t1p , t 1 r , t 2 : ( Ac t i on !> S t a t e ) !> S t a t e ) {

S t r ongRe f i n emen t [ r , t1p , t 1 r , t2 , t 2 ]}

Implementacion Debil/ ( S t a t e s t h a t r i s a weak imp l emen t a t i o n be tween t r a n s i t i o n s t 1 ( /

/ ( ( r e q u i r e d and maybe ) and t 2 . ( /

pred WeakImplementa t ion( r : S t a t e !> S t a t e , t1p , t 1 r , t 2 : ( Ac t i on !> S t a t e ) !> S t a t e ) {

WeakRefinement [ r , t1p , t 1 r , t2 , t 2 ]}

Implementacion Ramificada/ ( S t a t e s t h a t r i s a b ranch ing imp l emen t a t i o n be tween t r a n s i t i o n s ( // ( t 1 ( r e q u i r e d and maybe ) and t 2 . ( /

pred Branch i ng Imp l emen t a t i o n( r : S t a t e !> S t a t e , t1p , t 1 r , t 2 : ( Ac t i on !> S t a t e ) !> S t a t e ) {

( a l l s1 , s2 : S t a t e | a l l a : Ac t i on | a l l s3 : S t a t e |ar row [ t 1 r , s1 , s2 , a ] and s1 !> s3 in r


imp l i e s( some s4 , s5 : S t a t e |

s3 !> s4 in ( preImageClTau [ t2 , s1 . r ] ) andarrowT [ t2 , s4 , s5 , a ] and s2 !> s5 in r

) )( a l l s1 , s2 : S t a t e | a l l a : Ac t i on | a l l s3 : S t a t e |

ar row [ t2 , s1 , s2 , a ] and s1 !> s3 in ˜ rimp l i e s( some s4 , s5 : S t a t e |

s3 !> s4 in ( preImageClTau [ t1p , s1 . ( ˜ r ) ] ) andarrowT [ t1p , s4 , s5 , a ] and s2 !> s5 in ˜ r

) )}

3.6 Comparacion de diversas herramientas en el ana-lisis de bisimulaciones y refinamientos

En esta seccion realizamos una primera comparacion entre el uso de SAT sol-ving para analizar la existencia de refinamientos entre LTS/MTS y otras herramientas,basadas con algoritmos de chequeo de (bi)simulacion. Las herramientas a compararcon nuestro enfoque son MTSChecker [Fis06, FUB06], desarrollada por D. Fischbein,y MTSA [DFFU07, FGPA05], una extension de LTSA que maneja sistemas de transi-ciones modales desarrollada por D. Fischbein, Nicolas D’Ippolito y Sebastian Uchitel.Estas herramientas analizan la existencia de relaciones de bisimulacion o refinamiento(varias variantes de estas relaciones) mediante algoritmos especıficos para estas tareas;nuestro enfoque, en cambio, realiza una tecnica basada en constraint solving, que enteorıa analiza todas las posibilidades (fuerza bruta). Es de esperar entonces que tantoMTSA como MTSChecker funcionen mas eficientemente.

Esto puede hacer pensar al lector que la comparacion que realizamos es inutil (eincluso que utilizar constraint solving para el analisis de existencia de relaciones debisimulacion/refinamiento, contando con algoritmos para el analisis de estas relacio-nes, es inutil). Sin embargo, como explicamos anteriormente, existen buenas razonespara hacer esto. Por un lado, realizar la comparacion nos permitira analizar la factibili-dad del enfoque (i.e. aun cuando los tiempos sean superiores a los obtenidos utilizandoalgoritmos para chequeo de bisimulacion/refinamiento, son los tiempos obtenidos us-ando SAT solving razonables?). Por otra parte, el uso de Alloy para esta tarea nos brin-da una herramienta mas versatil, que podemos consultar de manera que los algoritmosespecıficos para bisimulacion y refinamiento no soportan.

La comparacion fue realizada para varios pares de LTS y MTS, analizando bisim-ulacion y refinamiento de distinta naturaleza. Se utilizo para el analisis una Intel Core2 Duo CPU T5250 1.50GHz, con 2Gb de RAM. Los resultados obtenidos se resumenen la siguiente tabla. Las ultimas cuatro columnas indican las respuestas obtenidas porlas diferentes herramientas (V en caso de ser bisimilares o existe la relacion de refina-miento o implementacion, F en otro caso) y el tiempo demandado por correspondientea cada una de estas, en milisegundos.

La tabla incluye, como el lector puede apreciar, una columna con tiempos de unaherramienta que no mencionamos hasta el momento: KodKod [TJ07]. KodKod es elmotor de analisis detras de Alloy (a partir de su version 4); toda especificacion Alloyes parseada y traducida a KodKod, para luego ser analizada mediante SAT solving.En los tiempos de KodKod (versus los de Alloy) nos ahorramos entonces el tiemposde parsing y generacion del modelo KodKod resultante. Es importante notar que el

3.6. Comparacion de diversas herramientas en el ana-lisis de bisimulaciones yrefinamientos 39

analisis de especificaciones KodKod sigue siendo mediante constraint solving, es decir,esencialmente mediante el analisis de todas las posibles instancias acotadas por ciertovalor provisto por el usuario (en otras palabras, el analisis sigue siendo por fuerzabruta).

MTSChecker

MTSA

Alloy

KodKod

BisimulacionFuerte

P1 s0

s1 s2a

b a

b

Q1s0 s1

s2 s3

b

a ab

a

V 12 V 8 V 60 V 6

P2 s0

s1

s2 s3

s4 s5

a

b b

c d

Q2 s0

s1 s2

s3 s4

s5 s6

a a

b b

c d

F 3 F 5 F 64 F 4

BisimulacionDebil

P3 s0

s1

s2 s3

s4

a

b !

c

Q3 s0

s1

s2 s3

s4

a

b !

c

a V 4 V 8 V 144 V 4

P4 s0

s1 s2a

b a

b

Q4s0 s1

s2 s3

a

! !a

b

F 4 F 4 F 60 F 8

Bis.ramificada

P5s0 s1

a

b

Q5s0 s1

s2 s3

b

! !

a

V 2 V 5 V 140 V 4

P6

s0 s1

s2

c

b

a!Q6

s0 s1

s2

c

b

aa! F 2 F 4 F 80 F 4


MTSChecker

MTSA

Alloy

KodKod

Refinamientofuerte

P7

s0

s1s2

a

b

b?c?c?

Q7

s0

s1s2

a

b

b?c

V 1 V 2 V 92 V 3

Q7

s0

s1s2

a

b

b?c

P7

s0

s1s2

a

b

b?c?c?

F 1 F 2 F 48 F 4

Refinamientodebil

P8s0

s1 s2

s3 s4

a !?

b b?

Q8 s0

s1 s2

s3

s4

a b?

!

b

V 2 V 4 V 184 V 2

P9s0

s1s2

a

!?

b

c?

Q9s0

s1s2

a

!

b?

c?

F 1 F 3 F 64 F 1

Implem.fuerte

P10

s0

s1s2

a

b

b?c?c? Q10

s0

s1s2

a

b

V 1 V 2 V 56 V 1

P11s0

s1s2

a

!?

b? Q11 s0 s1a

bF 1 F 1 F 52 F 2

Implementaciondebil

P12 s0

s1 s2

s3 s4 s5

!? a

a? b !

Q12 s0

s1

s2 s3

a

b !

aV 1 V 2 V 100 V 3

P13 s0

s1 s2

s3 s4 s5

!? a

a? b c

Q13 s0

s1 s2

s3 s4

a a

b c

F 1 F 2 F 76 F 3

3.7. Ejemplos de otros analisis con Alloy Analyzer 41

MTSChecker

MTSA

Alloy

KodKod

Implementacionramificada

P14s0 s1

s2 s3

a

c? b

!?

c Q14s0 s1

s2 s3

a

c !

b

V 1 V 2 V 161 V 3

P12 s0

s1 s2

s3 s4 s5

!? a

a? b !

Q12 s0

s1

s2 s3

a

b !

aF 1 F 1 F 66 F 6

Como podemos observar en la tabla, los tiempos utilizando Alloy son en algunoscasos bastante peores que los de MTSChecker y MTSA. Sin embargo, en todos loscasos obtenemos una respuesta en unos pocos segundos mostrando que el analisis us-ando Alloy es factible. Mas aun, cambiando el uso de Alloy por el uso directo deKodKod, los tiempos de analisis bajan significativamente, acercandose a los tiemposde MTSChecker y MTSA.

Notese ademas que para este tipo de chequeo, tanto Alloy como KodKod nos danrespuestas certeras, en el sentido que, dada que las relaciones posibles entre LTS yMTS estan acotadas, la exploracion de relaciones posibles es exhaustiva. Por lo tanto, siexiste una relacion de refinamiento/bisimulacion, esta garantizado que Alloy/KodKodla encontrara.

Por ultimo nuestra modelizacion tiene una utilidad adicional de nuestro modelo deMTS/LTS en Alloy: depuracion de algoritmos para el analisis de relaciones de refina-miento, bisimulacion o implementacion. En efecto, la declaratividad brindada por ellenguaje Alloy hace que las especificaciones de este tipo de relaciones sea directa (dehecho, la especificacion no es otra cosa que la expresion de las definiciones de estasrelaciones en la sintaxis de Alloy), permitiendonos contrastar los resultados obtenidosde los algoritmos para chequeo de bisimulacion, refinamiento, etc, con las definicionesformales de estas relaciones.

3.7 Ejemplos de otros analisis con Alloy Analyzer

Ya hemos visto como podemos utilizar Alloy Analyzer para comprobar si, dadosdos MTS, existe una relacion de refinamiento de cierto tipo entre ellos.

Veremos ahora algunos ejemplos de la versatilidad de Alloy, con otro tipo de con-sultas que podemos hacer a nuestra caracterizacion de MTS y refinamientos. Estas con-sultas, que son directas en Alloy, no pueden realizarse en las herramientas MTSCheckery MTSA.

Mostraremos tambien ejemplos de consultas expresadas con facilidad, pero que,debido a caracterısticas del mecanismo de analisis subyacente a Alloy Analyzer, nopueden ser analizadas.

Todo refinamiento fuerte, es tambien un refinamiento debil. Mas precisamente para


toda relacion r, si esta satisface las condiciones para ser un refinamiento fuerte entredos MTS cualquiera, entonces la misma satisface las condiciones para ser un refina-miento debil para estos mismos MTS. Caracterizamos esta propiedad en Alloy de lasiguiente manera:module SRefImpliesWRefopen l i b r a r y

one s i g A, B ex tends Act ion { }one s i g S0 , S1 , S2 , S3 ex tends S t a t e { }

one s i g m1 ex tends MTS { }one s i g m2 ex tends MTS { }

a s s e r t SRefImpliesWRef {a l l r : S t a t e !> S t a t e |

S t r ongRe f i n emen t [ r , m1 . t r a n s , m1 . req , m2 . t r a n s , m2 . r eq ]imp l i e sWeakRefinement [ r , m1 . t r a n s , m1 . req , m2 . t r a n s , m2 . r eq ]

}

check SRefImpliesWRef f o r 4

Esta propiedad es valida, con lo cual Alloy Analyzer no encontrara contraejemplosde la misma, de tamano acotado por 4 (porque no existen contraejemplos de ninguntamano).

Es importante notar que esta propiedad esta cuantificada universalmente sobre losLTS m1 y m2, que son variables libres en la especificacion. Por otro lado, estamosacotando el numero de estados y acciones de nuestro universo. Evidentemente, estapropiedad no puede analizarse en MTSA y MTSChecker. Alloy Analyzer realizaeste analisis con relativa eficiencia, como se muestra en la tabla a continuacion.

Cotas Tiempos4 2.14s5 3.59s10 3m14s

Todo refinamiento debil es tambien un refinamiento fuerte. Esta propiedad, la recıpro-ca de la anterior, se expresa de la siguiente manera:module WRefImpliesSRefopen l i b r a r y

one s i g A, B ex tends Act ion { }one s i g S0 , S1 , S2 ex tends S t a t e { }


a s s e r t WRefImpliesSRef {a l l r : S t a t e !> S t a t e |

WeakRefinement [ r , m1 . t r a n s , m1 . req , m2 . t r a n s , m2 . r eq ]imp l i e sS t r ongRe f i n emen t [ r , m1 . t r a n s , m1 . req , m2 . t r a n s , m2 . r eq ]

}

check WRefImpliesSRef f o r 4


A diferencia de la propiedad anterior, esta no es valida, Alloy Analyzer rapidamenteencuentra un contraejemplo de la misma, con 4 como cota para los tamanos de losdominios. El contraejemplo encontrado por Alloy consta de los siguientes MTS m1y m2:

m1 s0

s1 s2

a? a?tau?

tau?

m2

s0 s1tau?

Claramente una de las relaciones que hace valido el refinamiento debil entre m1 ym2, pero que no hace valido el refinamiento fuerte es la siguiente:

r = {(s0, s0), (s1, s2), (s2, s1)}

Nuevamente, y solo para poder apreciar cuan eficientemente se puede realizar esteanalisis, proveemos la siguiente tabla en tiempos de analisis de la propiedad:

Cotas Tiempos4 3,07s5 7,84s10 1m16s20 2m23s

La relacion de refinamiento fuerte es transitiva sobre LTS. En otras palabras, paratoda terna de LTS l1, l2 y l3, si existen refinamientos fuertes entre l1 y l2, y entre l2y l3, entonces existe un refinamiento fuerte entre l1 y l3. Esto lo podemos expresarde la siguiente manera:module S t r ongT r an sopen l i b r a r y


one s i g l 1 ex tends LTS { }one s i g l 2 ex tends LTS { }one s i g l 3 ex tends LTS { }

a s s e r t S t r ongT r an s {a l l r12 , r23 : S t a t e !> S t a t e |

( l 1 . i n i t !> l 2 . i n i t in r12 andS t r o n gB i s imu l a t i o n [ r12 , l 1 . t r a n s , l 2 . t r a n s ] andl 2 . i n i t !> l 3 . i n i t in r23 andS t r o n gB i s imu l a t i o n [ r23 , l 2 . t r a n s , l 3 . t r a n s ] )

imp l i e s( some r : S t a t e !> S t a t e |l 1 . i n i t !> l 3 . i n i t in r andS t r o n gB i s imu l a t i o n [ r , l 1 . t r a n s , l 3 . t r a n s ] )

}

check S t r ongT r an s f o r 10

Alloy Analyzer no puede analizar esta propiedad debido a que no puede skolemi-zar relaciones de alto orden. Por el momento asumiremos que esta propiedad no esanalizable por Alloy Analyzer, y veremos mas adelante como atacar este tipo deproblemas.


Otra propiedad interesante para analizar es el refinamiento observacional comun, in-troducido en [BCU06]. Este concepto es crucial para la descripcion de la mezcla (omerge) de MTS [BCU06]. Podemos describir al refinamiento observacional comunde la siguiente manera. En el contexto de lenguajes de especificaciones que admitenparcialidad, es usual encontrarse con el caso en el cual uno cuenta con dos o masdescripciones parciales de diferentes partes de un mismo sistema. El refinamentoobservacional comun nos permite encontrar una unica descripcion parcial que abar-que a estas otras descripciones.

Para poder definir refinamiento observacional comun, necesitamos introducir la no-cion de interfaz, que identifica las acciones observables asociadas a unMTS (y ocultael resto).

Definicion 3.7.1. Una interfaz de un MTS M = (S , L,!!"r,!!"p, s0) respecto de unconjunto de acciones X # Actions, es un nuevo MTS M’ = (S , X,!!"r& ,!!"p& , s&0),donde las acciones que no pertenecen a X estan ocultas, es decir las acciones queno pertenecen a X son renombradas por Tau en las transiciones. Denotaremos M’ =M@L

Definicion 3.7.2. Un Refinamiento observacional comun (COR - Common Observa-tional Refinement) entre dosMTSM = (S , L,!!"r,!!"p, s0) yN = (S &, L&,!!"r& ,!!"p& , s&0),es un MTS P = (T,O,!!"r&& ,!!"p&& , t0), tal que se cumple que 0 # (L * L&), M ! P@Ly N ! P@L&.

Veamos como describimos las funciones interface, COR y una funcion auxiliarActs (que devuelve el conjunto de acciones de un MTS) en Alloy:

fun i n t e r f a c e( t : ( Ac t i on !> S t a t e ) !> S t a t e , X: s e t Act ion ) :

( Ac t i on !> S t a t e ) !> s e t S t a t e {t ! ( ( ( Act ion !Tau)!X) !> S t a t e !> S t a t e ) +( Tau !> ( ( Act ion !Tau)!X) . t )

}

fun a c t s ( t : ( Ac t i on !> S t a t e ) !> S t a t e ) : Ac t i on {( t . S t a t e ) . S t a t e

}

pred COR( r1 : S t a t e !> S t a t e , r2 : S t a t e !> S t a t e , m1 : MTS, m2 : MTS, m: MTS) {m1 . i n i t !> m. i n i t in r1 andm2 . i n i t !> m. i n i t in r2 andWeakRefinement [ r1 , m1 . t r a n s , m1 . req ,i n t e r f a c e [m. t r a n s , a c t s [m1 . r eq ] ] , i n t e r f a c e [m. req , a c t s [m1 . r eq ] ] ]

andWeakRefinement [ r2 , m2 . t r a n s , m2 . req ,i n t e r f a c e [m. t r a n s , a c t s [m2 . r eq ] ] , i n t e r f a c e [m. req , a c t s [m2 . r eq ] ] ]

}

Utilizaremos ahora un ejemplo de [BCU06], donde se describen dos instancias deun sistema de lectores/escritores. La finalidad sera que, mediante Alloy Analyzer,encontremos un refinamiento observacional comun de este sistema. Detallamos acontinuacion los grafos con las dos descripciones parciales:


D

s0 s1

s2

arl?rrl?

arl

rrl arlrrl F

s0 s1

s2

arl?rrl?

awl

rwlarl?

rrl?

donde arl denota acquireReadLock, rrl denota releaseReadLock, awl denotaacquireWriteLock y rwl denota releaseWriteLock, correspondiendose ası conla nomenclatura utilizada en [BCU06].Solo nos resta encontrar un refinamiento comun entre estos dos MTS. En Alloy estolo podemos lograr mediante el uso de predicados, como se muestra a continuacion.module CORopen l i b r a r y

one s i g ARL, RRL, RWL, AWL ex tends Act ion { }one s i g S0 , S1 , S2 ex tends S t a t e { }

one s i g D ex tends MTS { } {i n i t = S0req = ARL !> S0 !> S1 + ARL !> S1 !> S2 +

RRL !> S2 !> S1 + RRL !> S1 !> S0t r a n s = r eq + ARL !> S2 !> S2 + RRL !> S2 !> S2

}

one s i g F ex tends MTS { } {i n i t = S0req = AWL !> S0 !> S1 + RWL !> S1 !> S0t r a n s = r eq + RRL !> S2 !> S0 + ARL !> S0 !> S2 +

RRL !> S2 !> S2 + ARL !> S2 !> S2}

one s i g M ex tends MTS { }

pred RefCommon ( r1 : S t a t e !> S t a t e , r2 : S t a t e !> S t a t e ) {COR[ r1 , r2 , D, F , M]

}

run RefCommon f o r 20

El resultado obtenido de analisis usando Alloy Analyzer es el siguiente MTSM:

M s0 s1 s2s3awl

rwl

arl

rrl

arl

rrl

Notemos que el ejemplo anterior constituye un caso de estudio mas concreto, y masrepresentativo del tipo de especificaciones mediante MTS que normalmente se en-contrarıan en la practica. Mostramos la siguiente tabla con los tiempos de analisis deesta propiedad, para dar al lector informacion sobre el tiempo requerido de analisis.

Cotas Tiempos4 102ms5 114ms10 133ms20 154ms

4 Predicados de AltoOrden sobre MTS y LTS

En el capıtulo anterior mostramos algunos tipos de chequeos que podemos realizarutilizando la caracterizacion de LTS/MTS, (bi)simulaciones y refinamientos. Vimosalgunas propiedades que con Alloy no podemos chequear, y tambien algunos ejemp-los que podemos chequear con Alloy pero no con otras herramientas, como MTSA yMTSChecker, y destacamos la versatibilidad de Alloy para estas tareas.

Esta versatibilidad de la cual hablamos sugiere utilizar nuestra caracterizacion deLTS y MTS para algunas otras tareas. Por ejemplo, durante la investigacion de for-mas adecuadas de caracterizar refinamientos entre MTS se han propuesto varias defini-ciones, y se han conjeturado propiedades de estas. Un ejemplo de esto es la recıprocade la preservacion de implementaciones por parte de refinamiento fuerte, es decir, lasiguiente propiedad:

I[M] # I[N]' N , M

donde I[M] e I[N] denotan los conjuntos de implementaciones de los MTS M y Nrespectivamente y N , M significa que N refina a M o que M es un refinamiento de N.

Esta propiedad, durante un tiempo se creyo verdadera e incluso se demostro (erronea-mente) un teorema que asegura que refinamiento es completo para implementacion[Hut05]. Esta propiedad es en realidad falsa. Los contraejemplos que se conocen de lamisma son relativamente pequenos [Fis], algunos de ellos son:

N1 s0s1 s2

s3

a?

a?

bM1 s0 s1 s2a? b?

N2

s0

s1 s2

s3

s4 s5

aa

a a?

a

M2

s0

s1 s2

s3

aa

a

47

48 4. Predicados de Alto Orden sobre MTS y LTS

donde el conjunto de implementaciones de M1 y N1, y M2 y N2 son los mismos, perosin embargo N1 ! M1 y N2 ! M2.

La pregunta que podemos hacernos ahora es: ¿podremos utilizar Alloy para “testear”este tipo de propiedades? La utilidad de hacer esto es evidente, ya que nos permitirıaanalizar la validez, en modelos acotados, de propiedades de este tipo, y en caso deencontrar contraejemplos comprender las causas por las cuales falla.

Desafortunadamente, como veremos mas adelante, este tipo de propiedad no sepuede analizar directamente con Alloy. La razon de esto es que el antecedente de lapropiedad tiene, implicitamente una cuantificacion sobre todas las implementacionesdel MTS M. Este conjunto de implementaciones obviamente depende de M, e inclusopara MTS pequenos puede ser infinito.

Consideremos el caso del siguiente MTS:

s0a?

Este tiene infinitas implementaciones. En particular, la siguiente familia de LTS sontodas implementaciones del MTS anterior.

I0 s0

I1 s0 s1a

I2 s0 s1 s2a a

......

......

...

In = ({si}n, {a}, {si " si+1 | 0 + i + n}, s0)

Observemos que cada una de las implementaciones es distinta de la otra modulo bisim-ulacion.

La exploracion de contraejemplos de las propiedad busca pares de MTSM y N talesque I[M] # I[N] y N ! M (i.e., que hacen falsa la implicacion). Pero para poder buscarestos contraejemplos necesitamos poder cuantificar MTSM y N tales que I[M] # I[N],lo cual requiere, como vimos, chequear un numero infinito de implementaciones, en al-gunos casos. Esta limitacion solo nos permitira utilizar Alloy Analyzer para buscar po-tenciales contraejemplos, como veremos mas adelante. Por cuestiones de presentacionnos convendra trabajar con la contrarecıproca de la propiedad anterior:

N ! M' I[M] " I[N]

4.1 Preservacion de implementaciones en AlloyLa propiedad mencionada anteriormente puede caracterizarse en Alloy con relati-

va facilidad, mediante las siguientes aserciones: primero debemos conseguir dos can-didatos de MTS tal que no se cumpla que uno es refinamiento del otro, para luegocorroborar la relacion de sus conjuntos de implementaciones.

module Propopen l i b r a r y


4.1. Preservacion de implementaciones en Alloy 49


pred NoRef {! ( some r : S t a t e !> S t a t e | m1 . i n i t !> m2 . i n i t in r and

S t r ongRe f i n emen t [ r , m1 . t r a n s , m1 . req , m2 . t r a n s , m2 . r eq ] )}

run NoRef f o r 5

Una vez que encontremos dos instancias de MTS que satisfagan esta propieada,estaremos en condiciones de analizar la relacion entre sus respectivos conjuntos deimplementaciones.



/ ( Notar que en e s t e pun to debe i n s t a n c i a r s e l o s MTS encon t r ado s ( /

/ ( con e l chequeo a n t e r i o r ( /one s i g m1 ex tends MTS { } {t r a n s = . . .r e q = . . .}

one s i g m2 ex tends MTS { } {t r a n s = . . .r e q = . . .}

one s i g i ex tends LTS { }

pred Prop {some r2 : S t a t e !> S t a t e | m2 . i n i t !> i . i n i t in r2 and

S t r o ng Imp l emen t a t i o n [ r2 , m2 . req , m2 . t r a n s , i . t r a n s ] and! ( some r1 : S t a t e !> S t a t e | m1 . i n i t !> i . i n i t in r1 and

S t r o ng Imp l emen t a t i o n [ r1 , m1 . req , m1 . t r a n s , i . t r a n s ] )}

run Prop f o r 5

Como vemos esta propiedad es claramente expresable en Alloy (como lo demuestralas aserciones anteriores), pero al igual que para algunas propiedades del capıtulo ante-rior, Alloy Analyzer no puede analizarla, debido a que contiene cuantificadores de altoorden no skolemizables (las cuantificaciones sobre relaciones binarias, en este caso).

Una forma de sortear el problema de las cuantificaciones de alto orden, usualmenteutilizada en Alloy, es la introduccion de una signatura para representar el dominio dealto orden, en nuestro caso las relaciones binarias. Esto lo podemos hacer simplementede la siguiente manera:

s i g Re l a t i o n {r e l : S t a t e !> S t a t e

}

La propiedad puede entonces, ser expresada de la siguiente manera:




f a c t {! ( some r : R e l a t i o n | m1 . i n i t !> m2 . i n i t in r . r e l and

S t r ongRe f i n emen t [ r . r e l , m1 , m2 ] )}


pred NoRef {! ( some r : R e l a t i o n | m1 . i n i t !> m2 . i n i t in r . r e l and

S t r ongRe f i n emen t [ r . r e l , m1 . t r a n s , m1 . req , m2 . t r a n s , m2 . r eq ] )}

run NoRef f o r 5

Una vez que encontremos dos instancias de MTS que satisfagan esta especifi-cacion, las representamos (codificamos) en un modelo Alloy y analizamos la siguientepropiedad:



f a c t {! ( some r : R e l a t i o n | m1 . i n i t !> m2 . i n i t in r . r e l and

S t r ongRe f i n emen t [ r . r e l , m1 , m2 ] )}

/ ( Notar que en e s t e pun to debe i n s t a n c i a r s e l o s MTS encon t r ado s ( /

/ ( con e l chequeo a n t e r i o r ( /one s i g m1 ex tends MTS { } {r eq = . . .t r a n s = . . .}

one s i g m2 ex tends MTS { } {r eq = . . .t r a n s = . . .}

one s i g i ex tends LTS { }

pred Prop {some r2 : R e l a t i o n | m2 . i n i t !> i . i n i t in r2 . r e l and

S t r o ng Imp l emen t a t i o n [ r2 . r e l , m2 . req , m2 . t r a n s , i . t r a n s ] and! ( some r1 : R e l a t i o n | m1 . i n i t !> i . i n i t in r1 . r e l and

S t r o ng Imp l emen t a t i o n [ r1 . r e l , m1 . req , m1 . t r a n s , i . t r a n s ] )}

run Prop f o r 5

si el predicado no se satisface entonces, estamos delante de un potencial contraejemplopara nuestra propiedad. Es solo un contraejemplo potencial porque no exploramos todoel universo de implementaciones, sino solo implementaciones acotadas por las cotas

4.1. Preservacion de implementaciones en Alloy 51

provistas por el usuario para los dominios de la especificacion. Si, por el contrario,la propiedad es satisfecha, el par de MTS provistos no nos sirve, por lo que debemosbuscar otro par de MTS para continuar realizando el analisis.

El analisis anterior podrıa en principio expresarse en una unica especificacion Alloy,en lugar de realizarlo en dos etapas (una para buscar instancias que satisfagan el an-tecedente, e intentar que estas falsifiquen el consecuente). Sin embargo, como veremosmas adelante, el analisis de esta propiedad en una sola etapa no produce los resultadosque uno esperarıa, debido a que la semantica de Alloy no fuerza al analizador la gen-eracion de todas las posibles relaciones entre estados. Discutiremos este problema endetalle a continuacion.

4.1.1 Analisis de propiedades con cuantificacion de Alto OrdenLuego de la modificacion anterior, podemos usar Alloy Analyzer para chequear

nuestra propiedad de interes. Sin embargo, estamos en presencia de una especificacionen la cual la signatura (en nuestro caso, Relation) debe representar todos los valoresposibles de una estructura compuesta (en nuestro caso, todas las relaciones binariasposibles de estados). Como se explica en la seccion 5.3 de [Jac06], esto contradice lasemantica de Alloy, segun la cual una signatura representa solo un conjunto de valores.Como se explica en [Jac06], este inconveniente puede ser resuelto forzando, mediantehechos, que la signatura que representa todas las instancias posibles de valores efecti-vamente este “poblada” adecuadamente. Este tipo de axioma, denominado axioma degeneracion, en nuestro caso tiene la siguiente forma:

f a c t g e nRe l a t i o n {some r : R e l a t i o n | no r . r e la l l r : R e l a t i o n , s0 , s1 : S t a t e |

some r ’ : R e l a t i o n | r ’ . r e l = r . r e l + ( s0 !> s1 )}

4.1.2 Limitaciones en el Analisis mediante Alloy AnalyzerSi bien luego de la transformacion, y mediante la inclusion de axiomas de gen-

eracion, podemos analizar la propiedad descripta, existen limitaciones en la cantidadmaxima de elementos que se pueden asociar con cada signatura.

Debido al uso que le damos a la signatura Relation, necesitamos, tener tantos el-ementos asociados a esta signatura como relaciones binarias tengamos entre estados.Este numero depende claramente del numero de estados. Suponiendo que tenemos iestados en nuestros MTS/LTS, y considerando a n el numero de posibles asociacionesentre estados tenemos n = i$ i; la cantidad de relaciones binarias para i estados esta da-da por la siguiente expresion:

n!

i=0

"

ni

#

= 2n

Tomando casos concretos, como por ejemplo 2, 3 y 4 estados, la cantidad de rela-ciones que necesitamos instanciar son 16, 512 y 65536, respectivamente.

Alloy acepta 255 como cota maxima para las signaturas. Esto nos permite realizarel chequeo anterior para a lo sumo 2 estados. Otra alternativa es codificar los elemen-tos de la signatura Relation como signaturas “one” dentro del modelo. Alloy Analyzer


superar un maximo de 480 signaturas, con lo cual seguimos sin poder superar las rela-ciones sobre 2 estados. Recientemente, con la ultima version de Alloy Analyzer (4.1.9,de 27/10/2008), la cantidad maxima de signaturas “one” que se pueden definir se in-cremento a 1000, con lo cual podemos chequear relaciones de hasta 3 estados.

Ademas, no solo es un problema el numero de relaciones, sino tambien lo costosode su generacion, en terminos computacionales. La siguiente tabla resume el costo deanalisis de la propiedad, y muestra una limitacion importante en la escalabilidad delanalisis.

Estados Tiempos1 3ms2 44ms3 1s45ms

Si bien la diferencia entre 2 y 3 estados puede parecer irrelevante, debe tenerse encuenta que estos tiempos corresponden solo al chequeo de si un par de MTS cumplecon que uno es un refinamiento de otro. Este chequeo se realizara para un gran numerode MTS (todas las combinaciones de a pares de MTS que podamos generar). Veremosmas adelante como estos tiempos influyen notoriamente en los tiempos de analisis parala propiedad completa.

4.2 Mınimo conjunto de RelacionesComo hemos visto, las limitaciones de Alloy Analyzer nos impiden chequear la

propiedad en la cual estamos interesados. El problema esta dado por el numero de rela-ciones posibles entre estados, y la relacion entre este numero y la cantidad de elementosde la signatura Relation.

En nuestro caso, las relaciones entre estados tienen una finalidad especıfica: lasqueremos para estudiar potenciales relaciones de refinamiento entre MTS. Podemospreguntarnos entonces si todas las relaciones binarias entre estados son realmente nece-sarias. Si un numero significativo de relaciones son innecesarias, podemos eliminar losmismos y ası incrementar las cotas para el analisis de la propiedad.

La primera simplicacion que realizaremos consiste en jar el estado inicial de losMTS/LTS. El estado inicial para estos sera s0. Esto fuerza que las relaciones, can-didatos a ser renamientos, deben contener el par (s0, s0). Esta simplificacion, que parecetrivial, reduce el numero de relaciones posibles significativamente, como resumiremosen una tabla mas adelante en esta seccion.

La segunda simplicacion es mucho mas sofisticada; la misma consiste en obtener unconjunto (mınimo) de relaciones “canonicas” en algun sentido, tal que a partir de estaspodamos obtener las restantes mediante biyecciones entre los estados. Describiremosesta simplificacion a continuacion.

4.2.1 En busca de relaciones representantesComo describimos anteriormente, la idea de la segunda de nuestras optimizaciones

es encontrar el mınimo conjunto de representantes tal que por medio de biyeccionespoder reconstruir todo el universo de las relaciones. Para ello, en primer instancia debe-mos analizar las posibles biyecciones sobre estos estados.

Consideremos, por ejemplo, las biyecciones sobre 3 estados. Existen 6 posiblesbiyecciones, que enumeramos a continuacion:

4.2. Mınimo conjunto de Relaciones 53

s2

s1

s0

s2

s1

s0

s2

s1

s0

s2

s1

s0

s2

s1

s0

s2

s1

s0

s2

s1

s0

s2

s1

s0

s2

s1

s0

s2

s1

s0

s2

s1

s0

s2

s1

s0

De estas, solo las dos primeras mapean s0 en s0; por lo tanto, estas son las unicasbiyecciones que nos sirven, ya que preservan el mapeo de s0 en s0 (como requerimospara ser un refinamiento).

El conjunto mınimo de relaciones tales que mediante estas biyecciones nos per-miten reconstruir el conjunto de relaciones original no tiene por que generarse a mano.En lugar de esto, utilizaremos Alloy Analyzer, y aprovecharemos su versatilidad, paraencontrar este conjunto mınimo.

Una vez obtenido el conjunto mınimo de relaciones, lo utilizamos para reconstruirel conjunto de relaciones original mediante un simple script, cuya salida son especifi-caciones Alloy.

4.2.2 Minimizando relaciones con Alloy AnalyzerContinuemos con el caso en el cual queremos generar todas las relaciones para tres

estados. En principio ya tenemos el conjunto mınimo de relaciones y sabemos cualesson las biyecciones a partir de las cuales podemos generar todas las relaciones orig-inales. Veamos ahora con que debemos contar para poder analizar nuestra propiedadmediante Alloy Analyzer, ya que debemos quedarnos con un representante de cada unade las relaciones. Para hacerlo debemos modelar lo siguiente:

las instancias de los estados sobre los cuales vamos a trabajar y definir todo el con-junto de estadosab s t r a c t s i g S t a t e { }one s i g S0 , S1 , S2 ex tends S t a t e { }

one s i g S e t S t a t e {c j t o : s e t S t a t e

} {

c j t o = S0 + S1 + S2}

el universo de relaciones, y el dominio e imagen de su relacion binariaab s t r a c t s i g Re l a t i o n {

r e l : S t a t e !> S t a t e} {

r e l in S e t S t a t e . c j t o !> S e t S t a t e . c j t o}

el universo con todas las relaciones entre estados en lenguaje Alloy, es decir, poblarel universo.La idea es obviar el axioma de generacion, por lo que le pasaremos el universode todas las relaciones que al menos contienen el par (s0,s0). Estas instancias lasgeneramos mediante un script simple que podemos observar en Apendice E y en elApendice C el lector puede observar todas las instancias generadas.

las biyecciones que analizamos anteriormente


ab s t r a c t s i g Biyecc i on {r e l : S t a t e !> S t a t e

} {

r e l in S e t S t a t e . c j t o !> S e t S t a t e . c j t o andr e l [ S t a t e ] = S e t S t a t e . c j t o andr e l . S t a t e = S e t S t a t e . c j t o

}

one s i g B0 ex tends Biyecc i on { } {r e l = S0 !> S0 + S1 !> S1 + S2 !> S2

}

one s i g B1 ex tends Biyecc i on { } {r e l = S0 !> S0 + S1 !> S2 + S2 !> S1

}

por ultimo, el predicado de mınimo conjunto de relaciones, a partir del cual nece-sitamos poder generar todo el universo de relaciones que codificamos previamentecomo instancias concretas.pred con jun tosDeRs ( SetR : s e t Re l a t i o n ) {

( a l l r , r ’ : R e l a t i o n | some f , f ’ : B i y e c c i on |( r in SetR and r ’ in SetR andr . r e l = ( f . r e l ) . ( r ’ . r e l ) . ( f ’ . r e l ) imp l i e s r = r ’ ) ) and

( a l l r : R e l a t i o n | S0 !> S0 in r . r e l imp l i e s ( some r ’ : R e l a t i o n |r ’ in SetR andsome f , f ’ : B i y e c c i on | r . r e l = ( f . r e l ) . ( r ’ . r e l ) . ( f ’ . r e l ) ) )

}

Notemos que solo podemos hacer esto para a lo sumo 3 debido a la capacidad limitade instancias que soporta Alloy Analyzer.

Ya estamos en condiciones de realizar el analisis. Alloy Analyzer nos dara comoresultado el mınimo conjunto de relaciones que nos permita generar el resto (en algunsentido, relaciones representantes). Trabajaremos con este conjunto en lugar de trabajarcon el conjunto de relaciones original.

Para poder apreciar el impacto de las simplificaciones propuestas, observemos lasiguiente tabla comparativa.

Cant. Estados (1) (2) (3)1 2 1 12 16 8 83 512 256 84

En esta tabla (1) corresponde a la cantidad original de relaciones entre estados, (2)corresponde a la cantidad de relaciones eliminando las que no tienen el par (s0, s0)y (3) corresponde a la cantidad mınima de relaciones que no contienen (s0, s0) y quepermiten generar las demas a traves de biyecciones.

Podemos apreciar que, eliminando las relaciones que no contienen el par (s0, s0),y reduciendo las relaciones a un conjunto de representantes mınimo, el numero deinstancias de relaciones a chequear se reduce considerablemente.

Hemos logrado reducir el problema, para el caso de relaciones sobre tres estados,con un universo de 84 relaciones, cuando partimos con un total de 512. Mas adelanteaclararemos por que podemos prescindir de las demas relaciones.

Cabe aclarar que Alloy Analyzer cuenta con un mecanismo incorporado en la her-ramienta para eliminacion de relaciones isomorformas [JJD98] similar al mecanismo

4.3. Generacion de LTS/MTS 55

que acabamos de describir, sin embargo en nuestro caso nos hemos visto forzados a in-corporar un modelo Alloy de relaciones (caracterizado por la signatura Relation). Estotrae como consecuencia que a nuestras relaciones no se les aplique tal optimizacion.Por esta razon la desicion de incorporar este mecanismo.

4.3 Generacion de LTS/MTSResumamos lo que hemos hecho hasta el momento. Las cuantificaciones univer-

sales sobre MTS que tenıamos en la formula de nuestra propiedad de interes las redu-jimos mediante la generacion de pares de MTS tales que el primero no es refinamientodel segundo. En este proceso aplicamos optimizaciones en el numero de relaciones achequear para comprobar la existencia de un refinamiento. Una vez que tenemos estepar de MTS, intentamos generar un LTS que sea implementacion del segundo pero nodel primero, y asi haga falsa la propiedad en la cual estamos interesados.

Un problema que surge al aplicar este mecanismo es que Alloy utiliza una formadeterminista de realizar las busquedas de instancias, que tiene como resultado la gen-eracion de siempre el mismo par de MTS. Si bien Alloy Analyzer ofrece la opcion depedir otras instancias, esto nos demanda mucho tiempo, y en principio no se puede au-tomatizar. Estas razones nos llevan a que nosotros generemos (automaticamente perono a traves de SAT solving) los MTS, los tomemos de a pares y se lo pasemos a Alloypara que este analice la propiedad.

Algo que conviene preguntarse en este momento es: ¿como deben ser nuestros MTScandidatos? No tenemos una respuesta precisa para esta pregunta, aunque podemospensar en algunas condiciones que estos MTS deben satisfacer:

Tener como estado inicial al estado s0.

No ser bisimilar al MTS “vacıo”, esto es, al menos contener una transicion probableque tenga por origen al estado s0.

Las transiciones requeridas deben estar incluidas en las probables.

Deben ser conexos. Esto se debe a que podemos prescindir de los MTS no conexos,ya que analizar estos MTS es equivalente a analizar solo la parte conexa de losmismos en la cual se encuentre el estado s0 ; pero este es otro MTS de menor tamano,y por lo tanto ya deberıa haber sido contemplado (la visita a los MTS se realiza demanera creciente de acuerdo a su tamano). La generacion de los MTS candidatos,teniendo en cuenta las consideraciones anteriores, fue automatizada a traves de unscript, que se detalla en el Apendice E.

Para poder apreciar el numero de MTS a considerar, es importante notar que elmismo esta dado por la siguiente formula (notemos que esta no contiene la reduccionde MTS no conexos):

|S |2·L!

i=0

$"

|S |2 · |L|i

#

!

%

|S |2 · |L| ! |S | · |L|i

&'

· 2i

donde,%

kl

&

=

(

)

)

*

)

)

+

,

kl

-

si l + k0 caso contrario


y S representa el numero de estados y L representa el numero de acciones.Donde

,

|S |2·|L|i

-

representa la cantidad de transiciones probables con i tuplas (tuplasde la forma, (Action,State,State)),

.

|S |2·|L|!|S |·|L|i

/

representa la cantidad de transicionesprobables de tamao i que no contienen ninguna tupla que parta del estado s0, y 2icorresponde a la cantidad transiciones requeridas para cada conjunto de transicionesprobables de tamao i.

La formula anterior presenta una cota superior, dado que no contempla la elimi-nacion de los grafos no conexos.

Para eliminar los grafos no conexos utilizamos Alloy Analyzer. Modelamos lapropiedad como sigue:

module I s Conexoopen l i b r a r y

ab s t r a c t s i g T r a n s i t i o n {t r a n s : Ac t i on !> S t a t e !> S t a t e

}

pred i s c o n e x o ( t : T r a n s i t i o n ) {S0 . ( ( t . t r a n s [ Ac t i on ] ) =

( t . t r a n s [ Ac t i on ] [ S t a t e ]+ ( t . t r a n s [ Ac t i on ] ) . S t a t e )}

Tambien, podrıamos eliminar algunas de las simetrıas que se introducen por lasacciones. Consideremos, por ejemplo, los siguientes MTS:

M1

s0 s1aM2

s0 s1b

modulo el nombre de la accion estos MTS podrıan representar el mismo contraejemplopara la propiedad mencionada. De todas maneras se deberıa tener particular cuidadoen hacer el mismo tipo de reduccion de simetrıa en todos los MTS involucrados. Estatecnica no la hemos implementado ya que el lenguaje que consideramos solo contieneuna accion.Resumiendo,

Trabajamos con 3 estados y 1 accion.

La cantidad de MTS es de 18.954, mientras que los utiles son 14.690.

Tenemos solo 215.796.100 pares de MTS vs 387.420.489 que tendrıamos sin lasoptimizaciones.

4.4 Metodologıa de AnalisisHemos generado todos los candidatos de MTS, como asi tambien el mınimo con-

junto de relaciones. Ahora, solo nos resta ver como realizamos nuestro chequeo.La idea es tomar dos MTS N y M, ver si se satisface el refinamiento entre estos dos

MTS N y M, y si esto se cumple chequear si existe una implementacion (i.e. un LTS L)de N, que no lo sea de M. En resumen, el proceso nos queda de la siguiente manera:

4.4. Metodologıa de Analisis 57

tomar 2 MTS del conjunto de MTS generados, como por ejemplo los que se de-scriben en el punto 2.one s i g mts1 ex tends MTS { } {

i n i t = S0req = A!>S0!>S0 + A!>S0!>S1t r a n s = A!>S0!>S0 + A!>S0!>S1

}

one s i g mts2 ex tends MTS { } {i n i t = S0req = A!>S1!>S0t r a n s = A!>S0!>S0 + A!>S1!>S0 + A!>S1!>S2

}

Podemos almacenar esta especificaicon en modulo Alloy, digamos intanciasDeMTS

analizar con Alloy si existe un refinamiento entre estos dos MTS; esto es, analizamossi el antecente de la propiedad de interes verdadera antes de continuar.module Al l oy I n s t a n c eAopen l i b r a r yopen Re l a t i o nM i n ima l 3S t a t eopen I n s t a n c e sM t s

pred a {some b1 , b2 : B iyecc ion , r : R e l a t i o n |

mts1 . i n i t !> mts2 . i n i t in ( b1 . r e l ) . ( r . r e l ) . ( b2 . r e l ) andS t r ongRe f i n emen t [ ( b1 . r e l ) . ( r . r e l ) . ( b2 . r e l ) ,

mts1 . t r a n s , mts1 . req , mts2 . t r a n s , mts2 . r eq ]}

run a f o r 1

Notemos que debemos utilizar las biyecciones, para analizar todo el universo derelaciones.

en caso en que Alloy Analyzer no genere una instancia, el predicado anterior no essatisfactible. Por lo tanto, no existe un refinamiento entre estos dos MTS. Si existeuna accon de refinamiento descartamos los MTS, ya que no constituyen candidatosadecuados para ser contraejemplos de la propiedad.

Si tenemos un par de MTS que hacen verdadero el antecedente de la propiedadde interes, proseguimos a analizar el consecuente de la propiedad de la siguientemanera:module Al l o y I n s t a n c eBopen Re l a t i o nM i n ima l 3S t a t eopen I n s t a n c e sM t s

pred a ( l t s 1 : LTS ) {( some f1 , f2 : B iyecc ion , r : R e l a t i o n |

mts2 . i n i t !> l t s 1 . i n i t in ( f1 . r e l ) . ( r . r e l ) . ( f2 . r e l ) andS t r o ng Imp l emen t a t i o n [ ( f1 . r e l ) . ( r . r e l ) . ( f2 . r e l ) ,

mts2 . t r a n s , mts2 . req , l t s 1 . t r a n s ] ) and! ( some f1 , f2 : B iyecc ion , r : R e l a t i o n |

mts1 . i n i t !> l t s 1 . i n i t in ( f1 . r e l ) . ( r . r e l ) . ( f2 . r e l ) andS t r o ng Imp l emen t a t i o n [ ( f1 . r e l ) . ( r . r e l ) . ( f2 . r e l ) ,

mts1 . t r a n s , mts1 . req , l t s 1 . t r a n s ] )}

run a f o r 1


Si este predicado es satisfactible nuevamente estosMTS no hacen falsa a la propiedad.Deberemos entonces descartarlos y comenzar con otros candidatos. Si en cambioeste predicado resulta insatisfactible estamos en presencia de un candidato a con-traejemplo de la propiedad que podrıa utilizarse para verificar que la propiedad esfalsa.

Este candidato a contraejemplo debera ser chequeado a mano para corroborar si esun contraejemplo real o un contraejemplo espureo.

4.5 Algunos Ejemplos de contraejemplos

Alloy analyzer no ha encontrado contraejemplos de dicha propiedad. A contin-uacion analizaremos algunos:

Este ejemplo, al tener a lo sumo 2 acciones es muy simple para analizarlo. Note-mos que el conjunto de implementaciones no solo es finito, sino que solo tiene 5implementaciones. Con lo cual, su analisis es completo.

N s0 s1 s2a? a

a?

M s0 s1 s2a? a?

Por su simplicidad, vemos que el MTSM acepta todas las implementaciones. Por lotanto, podemos ver que basta con encontrar un N que no sea refinamiento deM, masaun, esto se reduce a encontrar un M que contenga una accion requerida.

N s0 s1s2a?

aa?M s0

a?

Otro contraejemplo que nos encuentra la herramienta es el siguiente. Pero veamosque este, es un contraejemplo espure ya que existe una implementacion. Alloy noes capaz de encontrar este contraejemplo debido a que contiene 5 estados, y Alloysolo tiene capacidad para analizar las implementaciones de hasta 3 estados. Veamosla implementacion que hace a este contraejemplo, un contraejemplo espureo.

N s0 s1s2 a?a?a M s0 s1s2 a

a?

a? a

I s0 s1 s2 s3

s4

a a a

a a

a

4.6. Estimacion de tiempo de analisis 59

4.6 Estimacion de tiempo de analisis

Como habıamos visto, tenemos 18.954 MTS para 3 estados y 1 accion. Si con-sideramos todos los posibles pares de estos MTS, tenemos 359.254.116. Si bien estenumero llama la atencion, debemos tener en cuenta que con las optimizaciones quehemos descripto el chequeo de un par de MTS se puede realizar en unos pocos segun-dos, a lo sumo un segundo. Luego, el tiempo aproximado del chequeo de la propiedaden el peor caso y con un segundo de tiempo de chequeo por cada MTS nos conduce alos siguientes tiempos de analisis en termino de numeros de CPU.

CPU segundos1 3,59 10810 3,59 10750 7,18 106100 3,59 106

Esto es, necesitamos casi 2 meses para analizar esta propiedad si contasemos con100 CPU. La caracterıstica del analisis nos lleva a que el chequeo de cada par de MTSsea independiente, lo cual nos provee un entorno de trabajo altamente paralelizable.Ademas cada chequeo es barato en cuanto a memoria requerida.

4.7 Mejora al tiempo de analisis

Podemos optimizar el tiempo de analisis evitando el acceso de lectura y escrituraa disco. Si observamos detenidamente, una gran parte de nuestro proceso de analisisrequiere lectura y escritura de archivos. Podemos optimizar el tiempo de analisis, si enlugar de escribir en disco, escribimos en memoria. Un truco util para conseguir estoes mediante la creacion de un disco ram que es accedido como un disco comun. En elapendice E, detallamos los pasos para realizarlo. Para mas detalles el lector puede ver[Dis].

Con nuestra optimizacion, hemos podido reducir el tiempo de analisis a un mes, sicontasemos con 100 CPU.

4.8 Una alternativa utilizando DynAlloy

Un inconveniente con el proceso de analisis descripto esta dado por la limitacionen el numero de instancias que Alloy Analyzer soporta. Una alternativa para intentarresolver este problema consiste en la utilizacion de una extension de Alloy llamadaDynAlloy [FPB+05]. DynAlloy permite describir propiedades de sistemas usando ac-ciones. Las acciones nos permiten especificar propiedades dinamicas apropiadamente,en particular, propiedades en lo que respecta a trazas de ejecuciones, en el estilo delogica dinamica. DynAlloy extiende la sintaxis de Alloy con acciones y programas yaserciones de correccion parcial para esto.

Esencialmente la alternativa que describimos consiste en generar a traves de unprograma DynAlloy las relaciones candidatas a refinamiento entre MTS. Esta alterna-tiva nos permite trabajar con relaciones sobre conjuntos de estados mas grandes, perocon un costo de generacion mas alto.


4.8.1 Analisis de la propiedad mediante DynAlloyLa idea descripta anteriormente requiere la especificacion de un programa DynAl-

loy para la generacion de relaciones entre MTS. El modelo DynAlloy que contienedicho programa se detalla a continuacion. El lector puede familiarizarse con DynAlloyviendo el Apendice B.

Notemos como definimos las diferentes propiedades con DynAlloy,/ ( ASERCIONES ( /

pred P r eA s s e r t [ i : LTS , r : S t a t e !> S t a t e ] { no i . t r a n s and no r }

pred p o s tA s s e r t [ i : LTS , r : S t a t e !> S t a t e ] {S t r ongRe f i n emen t [ r , MTS1 . t r a n s , MTS1 . req , i . t r a n s ]

}

pred ex i s t eAux [ i : LTS ] {some r : S t a t e !> S t a t e |

S t r o ng Imp l emen t a t i o n [ r , MTS2 . t r a n s , MTS2 . req , i . t r a n s ]}

a s s e r t C o r r e c t n e s s BInvA [ i : LTS , r : S t a t e !> S t a t e ] {pre = { P r eA s s e r t [ i , r ] }program = { ( AgregarArc [ i ] ) ( ; [ e x i s t eAux [ i ] ] ? ; ( Agrega rPa r [ r ] ) ( }pos t = { p o s tA s s e r t [ i ’ , r ’ ] }

}

/ ( ASERCIONES ( /

pred P r eA s s e r t [ i : LTS , r : S t a t e !> S t a t e ] { no i . t r a n s and no r }

pred p o s tA s s e r t [ i : LTS , r : S t a t e !> S t a t e ] {S t r ongRe f i n emen t [ r , MTS1 . t r a n s , MTS1 . req , MTS2 . t r a n s , MTS2 . r eq ]

}

a s s e r t C o r r e c t n e s s BInvA [ i : LTS , r : S t a t e !> S t a t e ] {pre = { P r eA s s e r t [ i , r ] }program = { ( AgregarArc [ i ] ) ( ; [ e x i s t eAux [ i ] ] ? ; ( Agrega rPa r [ r ] ) ( }pos t = { ! p o s t A s s e r t [ i ’ , r ’ ] }

}

5 Conclusiones y trabajofuturo

5.1 Conclusiones

La finalidad de este trabajo ha sido el estudio de la viabilidad del uso de SATsolving para el analisis de diferentes tipos de propiedades sobre sistemas de transi-ciones etiquetadas, y una variante con soporte de parcialidad, los sistemas de transi-ciones modales. Hemos elegido como lenguaje para la caracterizacion de estos sis-temas a Alloy, un lenguaje formal fuertemente basado en la nocion de relacion. Alloynos brindo interesantes ventajas como lenguaje de especificaciones de LTS y MTS. Enprimer lugar, Alloy ofrece una sintaxis que esta a un nivel de abstraccion adecuadopara la caracterizacion de LTS y MTS, a diferencia del lenguaje aceptado comunmentepor los SAT solvers (formulas proposicionales, o formulas proposicionales en formanormal conjuntiva). En particular, Alloy soporta clausura transitiva como un operadorprovisto para la descripcion de expresiones relacionales, que es indispensable para ladefinicion de varios tipos de relaciones de refinamiento e implementacion entre MTSy LTS. En segundo lugar, la herramienta de analisis asociada a Alloy, Alloy Analyzer,implementa una codificacion de relaciones en formulas proposicionales muy eficiente,ademas de proveer mecanismos de aceleracion en el analisis externos a los SAT solvers,como la eliminacion de instancias isomorfas y el aprovechamiento de cotas de relacio-nes en la traduccion.

El resultado de nuestro estudio muestra que SAT solving es una herramienta vi-able para el analisis de refinamientos entre MTS y LTS, a pesar de ser menos eficienteque los algoritmos especıficos para este tipo de analisis, como era previsible. Esto sedebe a la naturaleza combinatoria del analisis basado en SAT solving, un mecanismosde constraint solving, esencialmente de fuerza bruta en la busqueda de instancias quesatisfagan las formulas en las especificaciones. No solo ha demostrado ser viable, sinoque mediante la utilizacion directa del motor relacional subyacente a Alloy, denomi-nado KodKod, los tiempos de analisis resultan comparables a los de la aplicacion dealgoritmos especıficos para chequeo de refinamientos, como los implementados en lasherramientas MTSA y MTSChecker.

La caracterizacion de MTS, LTS y relaciones de refinamiento en Alloy ofrece algu-nas ventajas que MTSA y MTSChecker no brindan. En primer lugar, las especificacio-nes pueden consultarse de maneras mas variadas que solo preguntar por la existenciade una relacion de refinamiento. Hemos mostrado algunos ejemplos de esto en este tra-bajo. En segundo lugar, la declaratividad natural de nuestra especificacion Alloy, quenos permite expresar directamente las definiciones de las relaciones de refinamiento

61

62 5. Conclusiones y trabajo futuro

(en lugar de implementar algoritmos para su chequeo) permite utilizar nuestra especi-ficacion para contrastar resultados con implementaciones de algoritmos de chequeo derefinamiento; es decir, utilizar la herramienta como un accesorio para la depuracion deimplementaciones de algoritmos de analisis de MTS y LTS.

Buena parte de nuestro trabajo se concentro en el analisis de propiedades de alto or-den deMTS y LTS. La motivacion principal de esto ha sido el estudio de una propiedad,la (supuesta) completitud de refinamiento fuerte con respecto a implementaciones enMTS. Esta propiedad se creyo verdadera durante un tiempo, e incluso se publico unademostracion de la misma. Sin embargo, la propiedad es falsa, y los contraejemplosde la misma son relativamente pequenos. Esto sugiere utilizar Alloy para analizar laverdad de esta propiedad en modelos acotados, o en otras palabras, intentar encontrarcontraejemplos de la propiedad en dominios acotados. Este tipo de analisis resulto sermuy costoso. Simplificamos el problema a la busqueda de potenciales contraejemplos,ya que comprobar si un contraejemplo no es espureo requiere en algunos casos la ex-ploracion de un numero infinito de LTS. Luego de simplificar el problema, y realizaruna variedad de optimizaciones, incluyendo la generacion de un conjunto mınimo derelaciones de representacion a partir de las posibles relaciones de refinamiento entreMTS y el ahorro de accesos a disco para el almacenamiento y lectura de resultadosparciales, logramos reducir los tiempos de analisis significativamente.

5.2 Trabajo FuturoDebido a limitaciones de tiempo, han quedado varias tareas importantes por con-

cluir, que nos ofrecen lıneas para continuar trabajando. En primer lugar, debemos com-pletar el estudio experimental de los mecanismos de analisis desarrollados. Esta tarearequerira considerable tiempo de computo, pero no resulta ser complicada de llevaradelante. Queremos ademas estudiar algunas propiedades ligadas a MTS, de particu-lar interes para la busqueda de instancias acotadas de especificaciones. Una de estaspropiedades, que nos permitirıa saber cual es el tamano maximo de LTS que es nece-sario explorar para el chequeo de completitud de relaciones de refinamiento respectode implementaciones de MTS es la siguiente: Si la propiedad es violada. ¿Existe unacota k para el tamano de la implementacion que hacer violar la propiedad? Es decir,¿Existe k tal que k - min{#i|i % I(M)\I(N)}?

Una de las mejoras al analisis que manejamos en este trabajo consiste en la elimi-nacion (o poda en la busqueda) de MTS que resultan de permutaciones en las etiquetasde las transiciones. Nuevamente debido a limitaciones de tiempo no hemos podido ex-plotar al maximo esta alternativa de mejora. Continuar explotandola forma parte denuestras tareas de trabajo futuro.

A La herramienta MTSA

La herramienta MTSA permite verificar propiedades y analizar modelos parciales(MTS) utilizando model checking. La herramienta Modal Transition System Analyzer(MTSA) que soporta la construccion, elaboracion y analisis de MTS se desarrollo comouna extension del ya existente Labeled Transition System Analyzer (LTSA).

A.1 LTSA - Labeled Transition System Analyzer

LTSA es una herramienta para verificacion y validacion de propiedades para sis-temas concurrentes. En LTSA un sistema se modela como un conjunto de maquinas deestados finitos que interactuan entre sı. Las propiedades que se desean estudiar sobreel sistema, tambien se modelan en maquinas de estados.

LTSA realiza la composicion del modelo del sistema con la propiedad deseada ysobre esta composicion realiza una busqueda exahustiva de posibles estados erroneos.Mas formalmente, cada uno de los componentes de una especificacion se describe co-mo un Sistema de Transicion Etiquetado (LTS), que contiene todos los estados a los queel componente puede llegar y todas las transiciones que puede realizar. Sin embargo,la descripcion explıcita de un LTS en terminos de sus estados, conjunto de etiquetas deaccion y relacion de transicion es complicada para cualquier sistema que no sea muypequeno. En consecuencia, LTSA una notacion al estilo de las algebras de procesospara describir el comportamiento de las componentes. Tal notacion se denomina FSP(por “finite state process”, proceso de estudio finito).

Un proceso se define mediante un listado de definiciones de procesos locales sepa-rados por coma y finalizados por punto. Por ejemplo:

SWITCH = OFF,

OFF = (on -> ON),

ON = (off -> OFF).

describe el comportamiento de un interruptor. ERROR y STOP son procesos primi-tivos.

Prefijos de acciones ->: si x es una accion y P un proceso, entonces (x -> P) de-scribe un proceso que inicialmente realiza la accion x y, a continuacion, se comportaexactamente como se describe por P.

63

64 A. La herramienta MTSA

Eleccion |: Si x e y son acciones entonces (x -> P | y -> Q) describe un proceso queinicialmente responde a cualquiera de las acciones x o y. Despues de haber realizadoesta primera accion, el comportamiento continua segun segun se describe en P o Qde acuerdo a si la primera accion realizada fue x o y respectivamente.

Eleccion con guarda: La eleccion con guarda es posible que las distintas alternativasen una eleccion sean habilitadas o deshabilitadas segun el valor de verdad de unaguarda. Por ejemplo, en el proceso (when x B -> P | y -> Q) representarıa dos op-ciones en la eleccion si la guarda B es verdadera. En caso de que sea falso, solo laeleccion por y puede ser realizada.

Extension +: El alfabeto de un proceso es el conjunto de acciones en las que estepuede participar. P + S extiende el alfabeto del proceso P con las acciones en elconjunto S.

Recursion: El comportamiento de un proceso puede ser definido recursivamente.La recursividad puede ser directamente en terminos del proceso que se define, oindirectamente, en terminos de otro proceso.Un ejemplo de esto, es el interruptorpresentado recientemente.

Tambien existen procesos compuestos, estos se definen mediante la composicin par-alela de uno o mas procesos. La definicion de un proceso compuesto es precedida por||. Veamos algunos operados utiles para la buena modelizacion de estos procesos com-puestos:

Composicion paralela ||: Si P y Q son procesos, entonces (P || Q) representa la ejecu-cion de manera concurrente entre P y Q, donde las acciones comunes son realizadasconjuntamente por ambos procesos en una unica transicion, y las no comunes demanera independiente por cada uno de ellos.

Replicador forall: forall[i:1..N] P(i) corresponde a la composicion paralela de las nreplicaciones del proceso P de la siguiente manera: (P(1) || . . . || P(N))

Existen ademas otros operadores que ayudan a modelar los procesos, entre elloslos que tienen que ver con el renombrado de las acciones. De particular interes paranosotros, son los operadores de ocultamiento e interfaz:

Ocultamiento \ El proceso P\{a1, . . . , ax} se comporta como el proceso P solo que lasacciones a1 . . . ax son renombradas por la accion “silenciosa” tau. La accion tau noes una accion que se comparte entre procesos, por lo tanto no pueden sincronizarsemediante ella.

Interfaz @: Es el dual del operador anterior. P@{a1, . . . , ax} se comporta como elproceso P donde solo las acciones a1 .. ax son visibles y el resto son renombradas atau.

El lector interesado puede encontrar mas informacion en [KM06].

A.2 MTSA - Modal Transition System AnalyzerMTSA es una extension de LTSA que ademas permite verificar automaticamente

diversas relaciones de refinamiento entre MTS. Para poder especificar MTS el lenguajede FSP se extiende de manera de poder especificar acciones probables. Las accionesprobables se describen como cualquier accion solo que se agrega ? al final del nombre.

A.3. MTSChecker 65

A.3 MTSCheckerMTSChecker es una una herramienta stand alone que permite verificar relaciones

de refinamiento entre MTS. MTSChecker es el motor de MTSA.La sintaxis de MTSChecker utiliza una sintaxis semejante a la de FSP. Como MT-

SA, introduce las acciones probables agregando al final del nombre el signo ?. Ademasla accion “silenciosa” tau, puede representarse explıcitamente.

66 A. La herramienta MTSA

B Las herramientas Alloyy DynAlloy

B.1 Alloy

Alloy Analyzer es un SAT solver que provee un lenguaje relacional. Su motor esun nuevo SAT basado en el model finder KodKod.

Un modelo en Alloy esta compuesto por: las signaturas, utilizadas para la construc-cion de nuevos tipos, y una variedad de formulas.

B.1.1 Gramatica y semantica de Alloy

problem ::= decl formdecl ::= var : typexprtypexpr ::= type| type" type| type' typexpr

form ::= expr in expr (subset)| !form (neg)| form && form (conj)| form || form (disj)| all v : type/form (univ)| some v : type/form (exist)

expr ::= expr + expr (union)| expr & expr (intersection)| expr expr (diference)| ) expr (transpose)| expr.expr (navigation)| +expr (transitive closure)| v : t/form (set former)| Var

Var ::= var (variable)| Var[var] (application)

M : form" env" BooleanX : expr" env" valueenv = (var + type)" valuevalue = (atom $ · · · $ atom)+(atom" value)

M [a in b]e = X[a]e # X[b]eM [!F ]e = ¬M [F ]eM [F && G]e =M [F ]e .M [G]eM [F ||G]e =M [F]e /M [G]eM [all v : t/F] =0

M [F](e 0 v"{x})/x % e(t)M[some v : t/F] =1

M [F](e 0 v"{x})/x % e(t)

X[a + b]e = X[a]e * X[b]eX[a & b]e = X[a]e 1 X[b]eX[a b]e = X[a]e \ X[b]eX[) a]e = {2x, y3 : 2y, x3 X[a]e}X[a.b]e = X[a]e;X[b]eX[+a]e = the smallest r such thatr;r # r and X[a]e # rX[{v : t/F}]e ={x e(t)/M [F](e 0 v"x)}X[v]e = e(v)X[a[v]]e = {2y1, ..., yn3 / 4x2x, y1, ..., yn3 % e(a) .2x3 % e(v)}

67

68 B. Las herramientas Alloy y DynAlloy

B.1.2 SignaturasUna signatura introduce un tipo basico y una coleccion de relaciones (que son lla-

mados campos), junto con los tipos de los campos y las restricciones sobre estos val-ores. Por ejemplo,

s i g Obje to { }

Objeto se introduce como un tipo no interpretado (o conjunto de atomos indivisibles).Ademas una signatura puede heredar campos y condiciones de otra signatura. Por ejem-plo,

s i g P r ed i c a do ex tends Obje to {de f : s e t Obje to

}

declara a Predicado como un subconjunto de Objeto, mientras que el campo def declarauna relacion de Predicado a Objeto.

La palabra abstract, permite definir una signatura abstracta por lo que no va a tenerninguna instancia del conjunto de Objeto. En general lo utilizamos cuando queremosdeclarar signaturas concretas a partir de signaturas abstractas. Por ejemplo, las sigu-ientes signaturas se extienden de Objeto:

ab s t r a c t s i g Obje to { }s i g ElemA ex tends Obje to { }s i g ElemB ex tends Obje to { }

ası, obtenemos instancias de Objeto a partir de las instancias de ElemA y ElemB. Porotro lado, podemos especificar si queremos solo una instancia; a esto lo realizamos dela siguiente manera:

ab s t r a c t s i g Obje to { }one s i g ElemA ex tends Obje to { }

B.1.3 Formulas y declaracionesUna formula esta formada por expresiones de Alloy. El valor de cualquier expresion

en Alloy es siempre una relacion -que es una coleccion de tuplas-. Cada elemento de esatupla es atomica y pertenece a algun tipo basico. Una relacion puede tener aridad uno omas. Las relaciones son tipadas. Los conjuntos son vistos como relaciones unarias. Lasrelaciones se puede combinar con una variedad de operadores para formar expresiones.Las expresiones quantificadas transforman una expresion en una formula. La formulano exp es verdadera cuando exp denota una relacion que no contiene tuplas. Del mismomodo, some exp, lone exp, y one exp son ciertas cuando tiene algunas, al menos una,y exactamente una tupla respectivamente. Las formulas tambien pueden construirsemediante comparaciones de operadores relacionales. Alloy provee operadores de logicaestandar:

&& (conjuncion)

|| (disyuncion)

=> (implicacion)

! (negacion)

B.1. Alloy 69

Una declaracion es una formula v op exp que consta de una variable v, un operador decomparacion op, y una expresion arbitraria exp. Las formulas cuantificadas consistende un cuantificador, una lista separada por comas de las declaraciones, y una formula.Ademas del cuantificador universal y existencial (quantificadores all y some), y one(exactamente uno).

Alloy, tambien provee los operadores relacionales basicos; subset (in), igualdad (:o =) y sus negaciones (!:, !in, !=). Ademas provee otros operadores relacionales loscuales explicaremos con mas detalle. Sea p que contiene una relacion con m-tuplas dela forma (p1,...,pm) y sea q una relacion que contenga n-tuplas de la forma (q1,...,qn).

p + q, p & q y p - q: la union, la interseccion y la diferencia combinan dos relacionesdel mismo tipo, vistas como conjuntos de tuplas.(i.e. m=n)

p -> q: el producto relacional de p y q resulta en una nueva relacion r = (p1, ..., pm,q1,..., qn) para cada combinacion de tupla de p y tupla q

p.q: el join de p y q, es la relacion que contiene tuplas de la forma (p1,...,pm!1,q2,...,qn)para cada par de tuplas donde el primero es una tupla de p, y la segunda es una tu-pla de q y el ultimo atomo de la primera tupla coincide con el primer atomo de lasegunda tupla.

p[q]: la relacion union de p y q, es la relacion que contiene tuplas de la forma(q1,...,qn!1,p2,...,pm) para cada par de tuplas donde el primero es una tupla de p,y la segunda es una tupla de q y el primer atomo de la segunda tupla coincide con elultimo atomo de la primer tupla. Alternativamente, p[q] puede ser escrito como q.p

ˆp: la clausura transitiva de p es la menor relacion que contiene a p y es transitiva.Transitivo significa que si p contiene (a, b) y (b, c) entonces, tambien contiene (a, c).Notemos que p es una relacion binaria y que la relacion resultante es tambien unarelacion binaria.

*p: la clausura reflexiva transitiva de p es la menor relacion que contiene p y es a lavez transitiva y reflexiva, lo que significa que todas las tuplas de la forma (a, a) estanpresentes. Una vez mas, p es una relacion binaria y la relacion resultante es tambienuna relacion binaria.

)p: la transpuesta de una relacion r forma una nueva relacion que tiene el ordende los atomos en sus tuplas invertido. Por lo tanto, si p contiene (a, b), entonces pcontendra (b, a)

B.1.4 Funciones, hechos, aserciones y predicadosUna funcion (fun) es una formula parametrizada que vincula sus parametros a las

expresiones cuyos tipos coinciden con el tipo declarado del parametro. De forma pre-determinada, una funcion devuelve un valor booleano, el valor de la formula en sucuerpo, aunque una funcion puede devolver un valor relacional (no booleano) para queesto ocurra hay que declararlo explıcitamente como se puede observar en el siguienteejemplo.

fun i s O b j e c t ( x : Objec t , p : P r e d i c a do ) {x in p . de f

}


Un hecho (fact) es una formula que no tiene argumentos, y no necesita ser invocadoexplıcitamente. Los hechos son propiedades globales de la especificacion que deben sersiempre verdaderas.

f a c t A l lOb j e c t o I n P r e d i c a d o {a l l x : Ob j ec to | some p : P r e d i c a do | x in P r ed i c a do

}

Una asercion (assert) es una formula cuya correccion necesita ser comprobada,asumiendo los hechos en el modelo.

a s s e r t Ob j e c t I n 2P r e d i c a d o {some x : Ob j ec to | some p1 , p2 : P r e d i c a do |

p1 !=p2 and x in p1 . de f and x in p2 . de f}

Un predicado (pred) es una formula que necesita ser corroborado al igual que laasercion, asumiendo los hechos en el modelo.

pred P r e d i c a d oTo t a l ( p : P r e d i c a do ) {a l l x : Ob je to | x in p . de f

}

B.1.5 Corridas y chequeosTanto las aserciones como los predicados, deben ser corroborados. Los predicados

se corroboran mediante corridas (run), mientras que las aserciones se corroborar me-diante chequeos (check). Por lo que a la hora de querer corroborar, debemos tener encuenta las siguientes cuatro posibilidades:

Si run(x) produce un ejemplo, eso significa que x es cierto en virtud de “algunas”circunstancias. Pero no necesariamente en todas las circunstancias.

Si run(x) no produce un ejemplo, x significa que es falso en virtud de todas lasposibles circunstancias.

Si check(x) produce una contraejemplo, x significa que es falsa en virtud de “algu-nas” circunstancias. Pero no necesariamente en todas las circunstancias.

Si check(x) no produce un contraejemplo, eso significa que x es cierta en virtud detodas las posibles circunstancias.

B.1.6 Skolemizacion de RelacionesMuchas veces, las formulas pueden reducirse a formulas equivalentes sin el uso de

quantificadores. Esta reduccion se denomina skolemizacion y se basa en la introduccionde una o mas constantes o funciones que capturan la formula cuantificada mediante susvalores. Consideremos el siguiente ejemplo,s i g A { r : l one B }s i g B { }

f a c t {some x : A | no x .

}

El “some” de la formula puede ser expresado equivalentemente por:x ’ in A && no x ’ . r

B.2. DynAlloy 71

x’ es la relacion skolemizada en este caso. El cuantificador existencial “some” no esnecesario porque el analisis se basa en la busqueda de la existencia de la relacionskolemizada.

B.2 DynAlloyDynAlloy es una extension del lenguaje de especificacion de Alloy para describir

propiedades dinamicas de los sistemas usando acciones. Las acciones nos permiten es-pecificar adecuadamente propiedades dinamicas, en particular, propiedades en relacioncon trazas de ejecucion.

B.2.1 Gramatica y semantica de DynAlloyLa sintaxis de formulas de DynAlloy extiende a la sintaxis de Alloy mediante las

siguientes reglas para construccion de sentencias de correcion parcial (partial correct-ness statements)

formula ::= ... |{formula} program {formula} (partial correctness)

program ::= formula, formula (x) (atomic action)| formula? (test)| program + program (non-deterministic choice)| program;program (sequential composition)| program (iteration)

B.2.2 PredicadosDynAlloy permite describir ejecuciones, vistas desde un punto de vista de trazas.

Por lo tanto, el funcionamiento de DynAlloy consiste en describir el estado inicialdel sistema (supongamos que lo denominamos $). Luego, describir las operacionesque deben ir ocurriendo, esto lo realizamos especificando los pares de estados que sevan relacionando mediante la ejecucion de una traza. Podemos suponer que los oper-adores son Oper 1 y Oper 2. Finalmente debemos especificar el estado final del sistema(llamemosle %). Lo cual nos lleva a que la especificacion pueda ser escrita tan simple yelegante como sigue:

{$}

(Oper 1 + Oper 2)({%}

Para mas detalles, el funcionamiento de DynAlloy es introducido en [FGPA05].

B.3 KodKodAlloy es muy utilizado debido al buen soporte de logica relacional y la plena au-

tomaticacion de sus analisis. Muchas veces se ha querido integrar Alloy con otras her-ramientas y esto ha fallado por diversas razones. Algunas de estas las detallamos acontinuacion,

una API limpia,


apoyo a los casos parciales, y

un mecanismo para compartir subformulas y subexpresiones.

Es por esto que KodKod esta diseado expresamente como un componente plugin,el motor relacional KodKod supera estas limitaciones. A diferencia de los analizadores,KodKod proporciona una interfaz simple para la construccion y el analisis de formulasde Alloy y que emplea un solido regimen compartido para la explotacion de formulasy expresiones.

B.3.1 Sintaxis abstracta de KodKod

problem := univDecl relDecl formula

univDecl := {atom[, atom]}relDecl := relVar :arity [constant, constant]varDecl := quantVar : expr

constant := {tuple}tuple := atom[, atom]

arity := 1 | 2 | 3 | 4 | ...atom := identierrelVar := identierquantVar := identier

formula := expr in expr (subset)| some expr (non-empty)| one expr (singleton)| no expr (empty)| lone expr (empty or singleton)| not formula (negation)| formula and formula (conjunction)| formula or formula (disjunction)| all varDecl | formula (universal)| some varDecl | formula (existential)

expr := expr + expr (union)| expr & expr (intersection)| expr - expr (diference)| expr.expr (join)| expr -> expr (product)| )expr (transpose)| ˆ expr (closure) | {varDecl | formula} (comprehension)| relVar (relation)| quantVar (quantied variable)

B.4. Cotas 73

B.4 CotasLo bueno de KodKod, es que permite el chequeo de propiedades parciales. Para

esto utiliza un sistema de cotas. Este sistema de cotas permite definir los lımites de susuniversos, es decir definir que elementos hay en cada uno de los conjuntos.

Primero generamos todos los atomos que tendra nuestro universo,f i n a l L i s t <S t r i n g > atoms = new L inkedL i s t <S t r i n g > ( ) ;

f o r ( i n t i = 0 ; i < s t a t e s ; i ++) {atoms . add ( ”S” + i ) ;}

f o r ( i n t i = 0 ; i < a c t i o n s ; i ++) {atoms . add ( ” a c t ” + i ) ;}

atoms . add ( ” t a u ” ) ;

Luego, generamos el universo sobre el cual vamos a trabajar,f i n a l Tup l eFa c t o r y f a c t o r y = u n i v e r s e . f a c t o r y ( ) ;f i n a l Bounds b = new Bounds ( u n i v e r s e ) ;f i n a l S t r i n g s t a t eMax = ”S” + ( s t a t e s ! 1 ) ;

mediante, la sentencia boundExactly definimos el conjunto de exactamente todos losatomos que se encuentran en este rango, mientras que si ponemos la sentencia bound,definimos el conjunto que a lo sumo tiene todos los atomos dentro del rango.b . boundExac t l y ( t h i s . s t a t e ,

f a c t o r y . r ange ( f a c t o r y . t u p l e ( ”S0” ) , f a c t o r y . t u p l e ( s t a t eMax ) ) ) ;b . bound ( t h i s . a c t i o n ,

f a c t o r y . r ange ( f a c t o r y . t u p l e ( ” a c t 0 ” ) , f a c t o r y . t u p l e ( ” t a u ” ) ) ) ;b . boundExac t l y ( t h i s . t au ,

f a c t o r y . r ange ( f a c t o r y . t u p l e ( ” t a u ” ) , f a c t o r y . t u p l e ( ” t a u ” ) ) ) ;

ademas podemos crear tuplas, para definir universos de signatuas, como por ejemplo:/ / R e l a t i o n sf i n a l L i s t <Tuple> re lUpperBound = new L inkedL i s t <Tuple > ( ) ;

S t r i n g s t a t e I = ” ” ;S t r i n g s t a t e F = ” ” ;

f o r ( i n t i = 0 ; i < s t a t e s ; i ++) {f o r ( i n t j = 0 ; j < s t a t e s ; j ++) {s t a t e I = ”S”+ j ;s t a t e F = ”S”+ i ;r e lUpperBound . add ( f a c t o r y . t u p l e ( s t a t e I , s t a t e F ) ) ;

}

}

b . bound ( t h i s . r e l . r e l , f a c t o r y . s e tO f ( re lUpperBound ) ) ;

En esta definimos el conjunto de atomos para las relaciones binarias sobre estados.Luego, la relacion rel sera como mınimo la relacion vacıa, y a lo sumo, contendra todoslos pares de estados que definimos en relUpperBound.

C Ejemplos

C.1 MTSAA continuacion se listan los codigos de los ejemplos representados en la Tabla 3.6

en MTSA.P1 = ( a !> b !> P1 | a !> b !> P1 ) .

Q1 = Q10 ,Q10 = ( a !> Q12 ) ,Q12 = ( b !> Q13 ) ,Q13 = ( a !> b !> Q10 | a !> Q12 ) .

P2 = P20 ,P20 = ( a !> P21 ) ,P21 = ( b !> c !> STOP | b !> d !> STOP ) .

Q2 = Q20 ,Q20 = ( a !> b !> c !> STOP | a !> b !> d !> STOP ) .

P3 = P30 ,P30 = ( a !> P31 ) ,P31 = ( b !> STOP | t a u !> c !> STOP ) \ { t a u } .

Q3 = Q30 ,Q30 = ( a !> Q31 | a !> Q33 ) ,Q31 = ( b !> STOP | t a u !> Q33 ) \ { t a u } ,Q33 = ( c !> STOP ) .

P4 = ( a !> b !> P4 | a !> b !> P4 ) .

Q4 = Q40 ,Q40 = ( t a u !> Q42 ) ,Q42 = ( a !> Q43 ) ,Q43 = ( b !> Q42 | t a u !> a !> Q40 ) \ { t a u } .

P5 = ( a !> b !> P5 ) .

Q5 = ( t a u !> a !> t a u !> b !> Q5 ) \ { t a u } .

P6 = P60 ,P60 = ( b !> a !> P61 ) ,P61 = ( c !> P61 | t a u !> P60 ) \ { t a u } .

Q6 = Q60 ,

75

76 C. Ejemplos

Q60 = ( b !> Q61 ) ,Q61 = ( a !> Q60 | a !> Q62 ) ,Q62 = ( c !> Q62 | t a u !> Q60 ) \ { t a u } .

P7 = P70 ,P70 = ( a !> P71 ) ,P71 = ( b !> P72 ) ,P72 = ( b? !> P71 | c ? !> P70 ) .

Q7 = Q70 ,Q70 = ( a !> Q71 ) ,Q71 = ( b !> Q72 ) ,Q72 = ( b? !> Q71 | c !> Q70 ) .

P8 = ( a !> b !> STOP | t a u ? !> b? !> STOP ) \ { t a u ? } .

Q8 = ( a !> t a u !> b !> STOP | b? !> STOP ) \ { t a u ? } .

P9 = P90 ,P90 = ( a !> t a u ? !> P92 ) \ { t a u ? } ,P92 = ( b !> P90 | c ? !> P92 ) .

Q9 = Q90 ,Q90 = ( a !> t a u !> Q92 ) \ { t a u } ,Q92 = ( b? !> Q90 | c ? !> Q92 ) .

P10 = P100 ,P100 = ( a !> P101 ) ,P101 = ( b !> P102 ) ,P102 = ( b? !> P101 | c ? !> P100 ) .

Q10 = ( a !> b !> STOP ) .

P11 = ( a !> t a u ? !> b? !> P11 ) \ { t a u ? } .

Q11 = ( a !> b !> Q11 ) .

P12 = P120 ,P120 = ( t a u ? !> a ? !> STOP | a !> P122 ) \ { t a u ? } ,P122 = ( b !> STOP | t a u !> STOP ) \ { t a u }

Q12 = Q120 ,Q120 = ( a !> Q121 | a !> STOP ) ,Q121 = ( b !> STOP | t a u !> STOP ) \ { t a u } .

P13 = P130 ,P130 = ( t a u ? !> a ? !> STOP | a !> P132 ) \ { t a u ? , a ? } ,P132 = ( b !> STOP | c !> STOP ) .

Q13 = ( a !> b !> STOP | a !> c !> STOP ) .

P14 = P140 ,P140 = ( a !> b !> P143 ) ,P143 = ( c !> P140 | t a u ? !> c ? !> P140 ) \ { t a u ? } .

Q14 = ( a !> t a u !> b !> c !> Q14 ) \ { t a u } .

P20 = P200 ,P200 = ( a !> P201 | b!> P202 ) ,P201 = ( c !> P202 | b !> P204 ) ,P202 = ( b !> P201 | c !> P203 | a !> P204 ) ,P203 = ( d !> P205 | d !> P203 | e !> P205 ) ,

C.2. MTSChecker 77

P204 = ( a !> P203 | d !> P202 | c !> P204 ) ,P205 = ( f !> P201 | d !> P204 | d !> P203 ) .

Q20 = Q200 ,Q200 = ( a !> Q201 | b!> Q202 ) ,Q201 = ( c !> Q202 | b !> Q204 ) ,Q202 = ( b !> Q201 | c !> Q203 | a !> Q203 ) ,Q203 = ( d !> Q205 | d !> Q203 | e !> Q204 ) ,Q204 = ( a !> Q203 | d !> Q202 | c !> Q204 ) ,Q205 = ( f !> Q201 | d !> Q204 | d !> Q203 ) .

C.2 MTSChecker

A continuacion se listan los codigos de los ejemplos representados en la Tabla 3.6en MTShecker.P1 = ( a !> b !> P1 | a !> b !> P1 ) .

Q1 = Q10 ,Q10 = ( a !> Q12 ) ,Q12 = ( b !> Q13 ) ,Q13 = ( a !> b !> Q10 | a !> Q12 ) .

P2 = P20 ,P20 = ( a !> P21 ) ,P21 = ( b !> c !> STOP | b !> d !> STOP ) .

Q2 = Q20 ,Q20 = ( a !> b !> c !> STOP | a !> b !> d !> STOP ) .

P3 = P30 ,P30 = ( a !> P31 ) ,P31 = ( b !> STOP | t a u !> c !> STOP ) .

Q3 = Q30 ,Q30 = ( a !> Q31 | a !> Q33 ) ,Q31 = ( b !> STOP | t a u !> Q33 ) ,Q33 = ( c !> STOP ) .

P4 = ( a !> b !> P4 | a !> b !> P4 ) .

Q4 = Q40 ,Q40 = ( t a u !> Q42 ) ,Q42 = ( a !> Q43 ) ,Q43 = ( b !> Q42 | t a u !> a !> Q40 ) .

P5 = ( a !> b !> P5 ) .

Q5 = ( t a u !> a !> t a u !> b !> Q5 ) .

P6 = P60 ,P60 = ( b !> a !> P61 ) ,P61 = ( c !> P61 | t a u !> P60 ) .

Q6 = Q60 ,Q60 = ( b !> Q61 ) ,Q61 = ( a !> Q60 | a !> Q62 ) ,Q62 = ( c !> Q62 | t a u !> Q60 ) .

P7 = P70 ,

78 C. Ejemplos

P70 = ( a !> P71 ) ,P71 = ( b !> P72 ) ,P72 = ( b? !> P71 | c ? !> P70 ) .

Q7 = Q70 ,Q70 = ( a !> Q71 ) ,Q71 = ( b !> Q72 ) ,Q72 = ( b? !> Q71 | c !> Q70 ) .

P8 = ( a !> b !> STOP | t a u ? !> b? !> STOP ) .

Q8 = ( a !> t a u !> b !> STOP | b? !> STOP ) .

P9 = P90 ,P90 = ( a !> t a u ? !> P92 ) ,P92 = ( b !> P90 | c ? !> P92 ) .

Q9 = Q90 ,Q90 = ( a !> t a u !> Q92 ) ,Q92 = ( b? !> Q90 | c ? !> Q92 ) .

P10 = P100 ,P100 = ( a !> P101 ) ,P101 = ( b !> P102 ) ,P102 = ( b? !> P101 | c ? !> P100 ) .

Q10 = ( a !> b !> STOP ) .

P11 = ( a !> t a u ? !> b? !> P11 ) .

Q11 = ( a !> b !> Q11 ) .

P12 = P120 ,P120 = ( t a u ? !> a ? !> STOP | a !> P122 ) ,P122 = ( b !> STOP | t a u !> STOP ) .

Q12 = Q120 ,Q120 = ( a !> Q121 | a !> STOP ) ,Q121 = ( b !> STOP | t a u !> STOP ) .

P13 = P130 ,P130 = ( t a u ? !> a ? !> STOP | a !> P132 ) ,P132 = ( b !> STOP | c !> STOP ) .

Q13 = ( a !> b !> STOP | a !> c !> STOP ) .

P14 = P140 ,P140 = ( a !> b !> P143 ) ,P143 = ( c !> P140 | t a u ? !> c ? !> P140 ) .

Q14 = ( a !> t a u !> b !> c !> Q14 ) .

P20 = P200 ,P200 = ( a !> P201 | b!> P202 ) ,P201 = ( c !> P202 | b !> P204 ) ,P202 = ( b !> P201 | c !> P203 | a !> P204 ) ,P203 = ( d !> P205 | d !> P203 | e !> P205 ) ,P204 = ( a !> P203 | d !> P202 | c !> P204 ) ,P205 = ( f !> P201 | d !> P204 | d !> P203 ) .

Q20 = Q200 ,Q200 = ( a !> Q201 | b!> Q202 ) ,

C.3. Alloy 79

Q201 = ( c !> Q202 | b !> Q204 ) ,Q202 = ( b !> Q201 | c !> Q203 | a !> Q203 ) ,Q203 = ( d !> Q205 | d !> Q203 | e !> Q204 ) ,Q204 = ( a !> Q203 | d !> Q202 | c !> Q204 ) ,Q205 = ( f !> Q201 | d !> Q204 | d !> Q203 ) .

C.3 Alloy

A continuacion se listan los codigos de los ejemplos representados en la Tabla 3.6en Alloy.


+ B !> S2 !> S0}


+ A !> S3 !> S1 + B !> S1 !> S0}

one s i g P2 ex tends LTS { } {i n i t = S0t r a n s = A !> S0 !> S1 + B !> S1 !> S2 + C !> S2 !> S4

+ B !> S1 !> S3 + D !> S3 !> S5}

one s i g Q2 ex tends LTS { } {i n i t = S0t r a n s = A !> S0 !> S1 + B !> S1 !> S3 + C !> S3 !> S5

+ A !> S0 !> S2 + B !> S2 !> S4 + D !> S4 !> S6}

one s i g P3 ex tends LTS { } {i n i t = S0t r a n s = A !> S0 !> S1 + B !> S1 !> S2 + Tau !> S1 !> S3

+ C !> S3 !> S4}

one s i g Q3 ex tends LTS { } {i n i t = S0t r a n s = A !> S0 !> S1 + A !> S0 !> S3 + B !> S1 !> S2

+ Tau !> S1 !> S3 + C !> S3 !> S4}


+ B !> S2 !> S0}

one s i g Q4 ex tends LTS { } {i n i t = S0t r a n s = Tau !> S0 !> S2 + A !> S2 !> S3 + B !> S3 !> S2

+ Tau !> S3 !> S1 + A !> S1 !> S0}

80 C. Ejemplos

one s i g P5 ex tends LTS { } {i n i t = S0t r a n s = A !> S0 !> S1 + B !> S1 !> S0

}

one s i g Q5 ex tends LTS { } {i n i t = S0t r a n s = Tau !> S0 !> S2 + A !> S2 !> S3 + Tau !> S3 !> S1

+ B !> S1 !> S0}

one s i g P6 ex tends LTS { } {i n i t = S0t r a n s = B !> S0 !> S1 + A !> S1 !> S2 + C !> S2 !> S2

+ Tau !> S2 !> S0}

one s i g Q6 ex tends LTS { } {i n i t = S0t r a n s = B !> S0 !> S1 + A !> S1 !> S0 + A !> S1 !> S2

+ C !> S2 !> S2 + Tau !> S2 !> S0}

one s i g P7 ex tends MTS { } {i n i t = S0req = A !> S0 !> S1 + B !> S1 !> S2t r a n s = r eq + B !> S2 !> S1 + C !> S2 !> S3

}

one s i g Q7 ex tends MTS { } {i n i t = S0req = A !> S0 !> S1 + B !> S1 !> S2 + C !> S2 !> S3t r a n s = r eq + B !> S2 !> S1

}

one s i g P8 ex tends MTS { } {i n i t = S0req = A !> S0 !> S1 + B !> S1 !> S3t r a n s = r eq + Tau !> S0 !> S2 + B !> S2 !> S4

}

one s i g Q8 ex tends MTS { } {i n i t = S0req = A !> S0 !> S1 + Tau !> S1 !> S3 + B !> S3 !> S4t r a n s = r eq + B !> S0 !> S2

}

one s i g P9 ex tends MTS { } {i n i t = S0req = A !> S0 !> S1 + Tau !> S1 !> S2 + B !> S2 !> S0t r a n s = r eq + C !> S1 !> S2

}

one s i g Q9 ex tends MTS { } {i n i t = S0req = A !> S0 !> S1 + Tau !> S1 !> S2t r a n s = r eq + C !> S1 !> S2 + B !> S2 !> S0

}

one s i g P10 ex tends MTS { } {i n i t = S0req = A !> S0 !> S1 + B !> S1 !> S2

C.3. Alloy 81

t r a n s = r eq + B !> S2 !> S1 + C !> S2 !> S0}

one s i g Q10 ex tends LTS { } {i n i t = S0req = A !> S0 !> S1 + B !> S1 !> S2

}

one s i g P11 ex tends MTS { } {i n i t = S0req = A !> S0 !> S1t r a n s = r eq + Tau !> S1 !> S2 + B !> S2 !> S3

}

one s i g Q11 ex tends LTS { } {i n i t = S0t r a n s = A !> S0 !> S1 + B !> S1 !> S0

}

one s i g P12 ex tends MTS { } {i n i t = S0req = A !> S0 !> S2 + B !> S2 !> S4 + Tau !> S2 !> S5t r a n s = r eq + Tau !> S0 !> S1 + A !> S1 !> S3

}

one s i g Q12 ex tends LTS { } {i n i t = S0t r a n s = A !> S0 !> S1 + A !> S0 !> S3 + B !> S1 !> S2

+ Tau !> S1 !> S3}

one s i g P13 ex tends MTS { } {i n i t = S0req = A !> S0 !> S2 + B !> S2 !> S4 + C !> S2 !> S5t r a n s = r eq + Tau !> S0 !> S1 + B !> S1 !> S3

}


+ C !> S2 !> S4}

one s i g P14 ex tends MTS { } {i n i t = S0req = A !> S0 !> S1 + B !> S1 !> S3 + C !> S3 !> S0t r a n s = r eq + Tau !> S3 !> S2 + C !> S2 !> S0

}

one s i g Q14 ex tends LTS { } {i n i t = S0t r a n s = A !> S0 !> S1 + Tau !> S1 !> S3 + B !> S3 !> S2

+ C !> S2 !> S0}

one s i g P15 ex tends MTS { } {i n i t = S0req = A !> S0 !> S1 + B !> S1 !> S3 + C !> S3 !> S0t r a n s = r eq + Tau !> S3 !> S2 + C !> S2 !> S0

}

one s i g Q15 ex tends LTS { } {

82 C. Ejemplos

i n i t = S0t r a n s = A !> S0 !> S1 + Tau !> S1 !> S3 + B !> S3 !> S2

+ C !> S2 !> S0}

C.4 KodKod

A continuacion se listan los codigos de los ejemplos representados en la Tabla 3.6en KodKod./ / P1 y Q1pTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S0” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S2” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S2” , ”S0” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S2” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S2” , ”S3” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S3” , ”S2” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S3” , ”S1” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S0” ) ) ;

/ / P2 y Q2pTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S2” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S3” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 2 ” , ”S2” , ”S4” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 3 ” , ”S3” , ”S5” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S2” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S3” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S2” , ”S4” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 2 ” , ”S3” , ”S5” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 3 ” , ”S4” , ”S6” ) ) ;

/ / P3 y Q3pTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S2” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” t a u ” , ”S1” , ”S3” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 2 ” , ”S3” , ”S4” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S3” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S2” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” t a u ” , ”S1” , ”S3” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 2 ” , ”S3” , ”S4” ) ) ;

/ / P4 y Q4pTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S0” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S2” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S2” , ”S0” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” t a u ” , ”S0” , ”S2” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S2” , ”S3” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S3” , ”S2” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” t a u ” , ”S3” , ”S1” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S1” , ”S0” ) ) ;

/ / P5 y Q5pTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S0” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” t a u ” , ”S0” , ”S2” ) ) ;

C.4. KodKod 83

qTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S2” , ”S3” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” t a u ” , ”S3” , ”S1” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S0” ) ) ;

/ / P6 y Q6pTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S0” , ”S1” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S1” , ”S2” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 2 ” , ”S2” , ”S2” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” t a u ” , ”S2” , ”S0” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S0” , ”S1” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S0” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S1” , ”S2” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 2 ” , ”S2” , ”S2” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” t a u ” , ”S2” , ”S0” ) ) ;

/ / P7 y Q7pTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S2” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S2” , ”S1” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 2 ” , ”S2” , ”S0” ) ) ;pReq . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;pReq . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S2” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S2” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S2” , ”S1” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 2 ” , ”S2” , ”S0” ) ) ;qReq . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;qReq . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S2” ) ) ;qReq . add ( f a c t o r y . t u p l e ( ” a c t 2 ” , ”S2” , ”S0” ) ) ;

/ / P8 y Q8pTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” t a u ” , ”S0” , ”S2” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S3” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S2” , ”S4” ) ) ;pReq . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;pReq . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S3” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S0” , ”S2” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” t a u ” , ”S1” , ”S3” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S3” , ”S4” ) ) ;qReq . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;qReq . add ( f a c t o r y . t u p l e ( ” t a u ” , ”S1” , ”S3” ) ) ;qReq . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S3” , ”S4” ) ) ;

/ / P9 y Q9pTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” t a u ” , ”S1” , ”S2” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 2 ” , ”S2” , ”S2” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S2” , ”S0” ) ) ;pReq . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;pReq . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S2” , ”S0” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” t a u ” , ”S1” , ”S2” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 2 ” , ”S2” , ”S2” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S2” , ”S0” ) ) ;qReq . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;qReq . add ( f a c t o r y . t u p l e ( ” t a u ” , ”S1” , ”S2” ) ) ;

/ / P10 y Q10pTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S2” ) ) ;

84 C. Ejemplos

pTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S2” , ”S1” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 2 ” , ”S2” , ”S0” ) ) ;pReq . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;pReq . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S2” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S2” ) ) ;

/ / P11 y Q11pTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” t a u ” , ”S1” , ”S2” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S2” , ”S0” ) ) ;pReq . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S0” ) ) ;

/ / P12 y Q12pTrans . add ( f a c t o r y . t u p l e ( ” t a u ” , ”S0” , ”S1” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S2” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S1” , ”S3” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S2” , ”S4” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” t a u ” , ”S2” , ”S5” ) ) ;pReq . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S2” ) ) ;pReq . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S2” , ”S4” ) ) ;pReq . add ( f a c t o r y . t u p l e ( ” t a u ” , ”S2” , ”S5” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S3” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S2” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” t a u ” , ”S1” , ”S3” ) ) ;

/ / P13 y Q13pTrans . add ( f a c t o r y . t u p l e ( ” t a u ” , ”S0” , ”S1” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S2” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S1” , ”S3” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S2” , ”S4” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 2 ” , ”S2” , ”S5” ) ) ;pReq . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S1” , ”S3” ) ) ;pReq . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S2” , ”S4” ) ) ;pReq . add ( f a c t o r y . t u p l e ( ” a c t 2 ” , ”S2” , ”S5” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S1” , ”S3” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S2” , ”S4” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 2 ” , ”S2” , ”S5” ) ) ;

/ / P14 y Q14pTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S3” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 2 ” , ”S3” , ”S0” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” t a u ” , ”S3” , ”S2” ) ) ;pTrans . add ( f a c t o r y . t u p l e ( ” a c t 2 ” , ”S2” , ”S0” ) ) ;pReq . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;pReq . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S1” , ”S3” ) ) ;pReq . add ( f a c t o r y . t u p l e ( ” a c t 2 ” , ”S3” , ”S0” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 0 ” , ”S0” , ”S1” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” t a u ” , ”S1” , ”S3” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 1 ” , ”S3” , ”S2” ) ) ;qTrans . add ( f a c t o r y . t u p l e ( ” a c t 2 ” , ”S2” , ”S0” ) ) ;

/ / P1 y Q1f i n a l Formula show = model . p .BB( model . r e l . r e l , model . q ) ;f i n a l So l u t i o n s o l = s o l v e r . s o l v e ( show , model . boundsSystem (4 , 2 ) ) ;/ / P2 y Q2

C.4. KodKod 85

f i n a l Formula show = model . p . SB( model . r e l . r e l , model . q ) ;f i n a l So l u t i o n s o l = s o l v e r . s o l v e ( show , model . boundsSystem (7 , 4 ) ) ;/ / P3 y Q3f i n a l Formula show = model . p .WB( model . r e l . r e l , model . q ) ;f i n a l So l u t i o n s o l = s o l v e r . s o l v e ( show , model . boundsSystem (5 , 3 ) ) ;/ / P4 y Q4f i n a l Formula show = model . p .WB( model . r e l . r e l , model . q ) ;f i n a l So l u t i o n s o l = s o l v e r . s o l v e ( show , model . boundsSystem (4 , 2 ) ) ;/ / P5 y Q5f i n a l Formula show = model . p .BB( model . r e l . r e l , model . q ) ;f i n a l So l u t i o n s o l = s o l v e r . s o l v e ( show , model . boundsSystem (4 , 2 ) ) ;/ / P6 y Q6f i n a l Formula show = model . p .BB( model . r e l . r e l , model . q ) ;f i n a l So l u t i o n s o l = s o l v e r . s o l v e ( show , model . boundsSystem (3 , 3 ) ) ;/ / Q7 y P7f i n a l Formula show = model . q . SR( model . r e l . r e l , model . p ) ;f i n a l So l u t i o n s o l = s o l v e r . s o l v e ( show , model . boundsSystemM (4 , 4 ) ) ;/ / P8 y Q8f i n a l Formula show = model . p .WR( model . r e l . r e l , model . q ) ;f i n a l So l u t i o n s o l = s o l v e r . s o l v e ( show , model . boundsSystemM (5 , 2 ) ) ;/ / P9 y Q9f i n a l Formula show = model . p .WR( model . r e l . r e l , model . q ) ;f i n a l So l u t i o n s o l = s o l v e r . s o l v e ( show , model . boundsSystemM (3 , 3 ) ) ;/ / P10 y Q10f i n a l Formula show = model . p .WI( model . r e l . r e l , model . q ) ;f i n a l So l u t i o n s o l = s o l v e r . s o l v e ( show , model . boundsSystemM (3 , 3 ) ) ;/ / P11 y Q11f i n a l Formula show = model . p . SI ( model . r e l . r e l , model . q ) ;f i n a l So l u t i o n s o l = s o l v e r . s o l v e ( show , model . boundsSystemM (3 , 2 ) ) ;/ / P12 y Q12f i n a l Formula show = model . p .WI( model . r e l . r e l , model . q ) ;f i n a l So l u t i o n s o l = s o l v e r . s o l v e ( show , model . boundsSystemM (6 , 2 ) ) ;/ / P13 y Q13f i n a l Formula show = model . p .WI( model . r e l . r e l , model . q ) ;f i n a l So l u t i o n s o l = s o l v e r . s o l v e ( show , model . boundsSystemM (6 , 3 ) ) ;/ / P14 y Q14f i n a l Formula show = model . p .WI( model . r e l . r e l , model . q ) ;f i n a l So l u t i o n s o l = s o l v e r . s o l v e ( show , model . boundsSystemM (4 , 3 ) ) ;

86 C. Ejemplos

D Mınimo conjunto deRelaciones en Alloy

El siguiente es el conjunto mınimo de relaciones obtenido a partir de en primerinstancia un conjunto de 256 relaciones, las cuales las redujimos a 84 mediante elanalisis de Alloy Analyzer. A partir de estas es posible generar todo el universo de lasrelaciones.

one s i g R0 ex tends Re l a t i o n { } {

r e l = S0 !> S0}


r e l = S0 !> S0 + S0 !> S1}


r e l = S0 !> S0 + S1 !> S0}


r e l = S0 !> S0 + S1 !> S1}


r e l = S0 !> S0 + S0 !> S1 + S0 !> S2}


r e l = S0 !> S0 + S0 !> S1 + S1 !> S0}


r e l = S0 !> S0 + S0 !> S1 + S1 !> S1}


r e l = S0 !> S0 + S0 !> S2 + S1 !> S1}


r e l = S0 !> S0 + S1 !> S0 + S1 !> S1}


r e l = S0 !> S0 + S1 !> S1 + S1 !> S2

87

88 D. Mınimo conjunto de Relaciones en Alloy

}


r e l = S0 !> S0 + S1 !> S0 + S2 !> S0}


r e l = S0 !> S0 + S1 !> S1 + S2 !> S0}


r e l = S0 !> S0 + S1 !> S1 + S2 !> S1}


r e l = S0 !> S0 + S1 !> S2 + S2 !> S1}


r e l = S0 !> S0 + S0 !> S1 + S0 !> S2 + S1 !> S0}


r e l = S0 !> S0 + S0 !> S1 + S0 !> S2 + S1 !> S1}


r e l = S0 !> S0 + S0 !> S1 + S1 !> S0 + S1 !> S1}


r e l = S0 !> S0 + S0 !> S2 + S1 !> S0 + S1 !> S1}


r e l = S0 !> S0 + S0 !> S1 + S1 !> S1 + S1 !> S2}


r e l = S0 !> S0 + S1 !> S0 + S1 !> S1 + S1 !> S2}


r e l = S0 !> S0 + S0 !> S1 + S1 !> S0 + S2 !> S0}


r e l = S0 !> S0 + S0 !> S1 + S1 !> S1 + S2 !> S0}


r e l = S0 !> S0 + S0 !> S2 + S1 !> S1 + S2 !> S0}


r e l = S0 !> S0 + S1 !> S0 + S1 !> S1 + S2 !> S0}


r e l = S0 !> S0 + S1 !> S1 + S1 !> S2 + S2 !> S0}

89


r e l = S0 !> S0 + S0 !> S1 + S1 !> S1 + S2 !> S1}


r e l = S0 !> S0 + S0 !> S2 + S1 !> S1 + S2 !> S1}


r e l = S0 !> S0 + S1 !> S0 + S1 !> S1 + S2 !> S1}


r e l = S0 !> S0 + S0 !> S1 + S1 !> S2 + S2 !> S1}


r e l = S0 !> S0 + S1 !> S0 + S1 !> S2 + S2 !> S1}


r e l = S0 !> S0 + S1 !> S1 + S1 !> S2 + S2 !> S1}


r e l = S0 !> S0 + S0 !> S1 + S0 !> S2 + S1 !> S0 + S1 !> S1}


r e l = S0 !> S0 + S0 !> S1 + S0 !> S2 + S1 !> S1 + S1 !> S2}


r e l = S0 !> S0 + S0 !> S1 + S1 !> S0 + S1 !> S1 + S1 !> S2}


r e l = S0 !> S0 + S0 !> S1 + S0 !> S2 + S1 !> S0 + S2 !> S0}


r e l = S0 !> S0 + S0 !> S1 + S0 !> S2 + S1 !> S1 + S2 !> S0}


r e l = S0 !> S0 + S0 !> S1 + S1 !> S0 + S1 !> S1 + S2 !> S0}


r e l = S0 !> S0 + S0 !> S2 + S1 !> S0 + S1 !> S1 + S2 !> S0}


r e l = S0 !> S0 + S0 !> S1 + S1 !> S1 + S1 !> S2 + S2 !> S0}


r e l = S0 !> S0 + S1 !> S0 + S1 !> S1 + S1 !> S2 + S2 !> S0}


r e l = S0 !> S0 + S0 !> S1 + S0 !> S2 + S1 !> S1 + S2 !> S1


}


r e l = S0 !> S0 + S0 !> S1 + S1 !> S0 + S1 !> S1 + S2 !> S1}


r e l = S0 !> S0 + S0 !> S2 + S1 !> S0 + S1 !> S1 + S2 !> S1}


r e l = S0 !> S0 + S0 !> S1 + S0 !> S2 + S1 !> S2 + S2 !> S1}


r e l = S0 !> S0 + S0 !> S1 + S1 !> S0 + S1 !> S2 + S2 !> S1}


r e l = S0 !> S0 + S0 !> S2 + S1 !> S0 + S1 !> S2 + S2 !> S1}


r e l = S0 !> S0 + S0 !> S1 + S1 !> S1 + S1 !> S2 + S2 !> S1}


r e l = S0 !> S0 + S0 !> S2 + S1 !> S1 + S1 !> S2 + S2 !> S1}


r e l = S0 !> S0 + S1 !> S0 + S1 !> S1 + S1 !> S2 + S2 !> S1}


r e l = S0 !> S0 + S1 !> S0 + S1 !> S1 + S2 !> S0 + S2 !> S1}


r e l = S0 !> S0 + S1 !> S0 + S1 !> S2 + S2 !> S0 + S2 !> S1}


r e l = S0 !> S0 + S1 !> S1 + S1 !> S2 + S2 !> S0 + S2 !> S1}


r e l = S0 !> S0 + S1 !> S1 + S1 !> S2 + S2 !> S1 + S2 !> S2}


r e l = S0 !> S0 + S0 !> S1 + S0 !> S2 + S1 !> S0 + S1 !> S1+ S1 !> S2

}



}


r e l = S0 !> S0 + S0 !> S1 + S0 !> S2 + S1 !> S1 + S1 !> S2

91

+ S2 !> S0}



}



}



}



}



}



}



}



}



}



}



}



}




}



}


r e l = S0 !> S0 + S0 !> S1 + S0 !> S2 + S1 !> S0 + S1 !> S1+ S1 !> S2 + S2 !> S0

}



}



}



}



}



}



}



}



}



}


93

r e l = S0 !> S0 + S0 !> S1 + S0 !> S2 + S1 !> S0 + S1 !> S1+ S1 !> S2 + S2 !> S0 + S2 !> S1

}



}



}


r e l = S0 !> S0 + S0 !> S1 + S0 !> S2 + S1 !> S0 + S1 !> S1+ S1 !> S2 + S2 !> S0 + S2 !> S1 + S2 !> S2

}

2

E Codigo

E.1 Disco RamComo vimos el el ultimo capıtulo, creamos una particion ram para optimizar nue-

stros tiempos de lectura y escritura. Este se puede realizar en linux de la siguientemanera en S.O. Linux:

En el grub modificar lo siguiente:

title Red Hat Linux (2.4.20-20.9)

root (hd0,0)

kernel /vmlinuz-2.4.20-20.9 ro

root=LABEL=/ hdc=ide-scsi \textbf{ramdisk_size=16000}

initrd /initrd-2.4.20-20.9.img

Luego, reiciamos y ejecutamos este script:

# Formats, mounts, and sets permissions on my 16MB ramdisk

/sbin/mke2fs -q -m 0 /dev/ram0

/bin/mount /dev/ram0 /mnt/rd

/bin/chown van:root /mnt/rd

/bin/chmod 0750 /mnt/rd

95

96E.CodigoE.2

Scriptdegeneracion

deMTS

yanalisis

denuestra

propiedad

#!/usr

/bin/perl

useData

::PowerSet

’powerset’;

useAlgorithm

::Permute

;use

Math

::BigR

at;use

Text::ParseW

ords;use

warnings

;

#Datos

paracom

pletarmy$StateM

ax=3;

my$ActionM

ax=1;

my@actions

=(”A

”);

my$stateIn

it=”S0”

;

my@ternas

=(0..$StateM

ax($StateM

ax($A

ctionMax!1);

my@relationsR

eq=(0..19682);

my@relationsT

rans=(0..19682);

my$i=0;

my$j=0;

my$k=0;

my$resul

=0;

my$count

=0;

#Genero

losestados

ylos

guardoen

@states

while

($i<$StateM

ax){

$states

[$i]=”S”

.$i;$i=$i+1;

}$i=0;

#Genero

paresde

estadoscon

accionesy

losguardo

en@ternas

while

($i<$StateM

ax){

E.2.ScriptdegeneraciondeMTSyanalisisdenuestrapropiedad97

$j=0;

while

($j<$StateM

ax){

$k=0;

while

($k<$ActionM

ax){

$ternas[$count]

=$actions

[$k].”!>”.$states

[$i].”!>”.$states

[$j];$k=$k+1;

$count=$count

+1;

}$j=$j+1;

}$i=$i+1;

}#Genero

eluniverso

derelaciones

.Quedan

guardadasen

unarray

dearrays

.Sin

formato

adecuado.

@ternasE

=@ternas;

my$pow

erset=pow

erset(@ternasE

);

#Guardo

endos

arrayslas

relaciones

generadas,las

cualesestn

enun

arrayde

arrays.

#Descarto

losmts

queno

seanconexos

oque

desdeel

estados0

nosalga

ningunaarista

$numRelation

=0;

my$reqA

=””;

my$transA

=””;

$i=0;

formy$p

(@$pow

erset){

$transA=”@$p”

;$transA

=˜s//+/g;

if($transA

=˜m/!>S0!>/&&

isconexo

($transA)){

my$pow

ersetAc=pow

erset($p);

formy$m

(@$pow

ersetAc){

$reqA=”@$m”;

$reqA=˜s//+/g;

$relationsReq[$num

Relation

]=$reqA

;#

prin

t$relationsR

eq[$num

Relation

].”\n”;

$relatio

nsTran

s[$num

Relation

]=$transA

;$num

Relation

=$num

Relation

+1;

}

98E.Codigo}

}prin

t”C

antidadde

MTS

”.$num

Relation

.”\n”

;@tim

eData=localtim

e(tim

e);

prin

tjoin

(’’,

@tim

eData

);prin

t”\n”

;

#fijo

dosMTS,

ychequeo

lasprop

quedeseo

,mediante

lasfunciones

checkImp,y

checkRef.

$k=14627;

$i=14611;

open(EJB

KP,”>ejem

plosbkp”);

$count=0;

while

(0<=$i){

$mts1

=gen

mts($i);

$mts2

=gen

mts($k

);prin

tEJB

KP”Ejem

plode

MTS

i=”.$i.”

k=”.$k

.”\n”

;if

(checkRef($m

ts1,$m

ts2)){

if(checkIm

p($m

ts1,$m

ts2)){

prin

tEJB

KP$m

ts1;

prin

tEJB

KP$m

ts2;

prin

tEJB

KP”Fin

deEjem

plo\n”

;}else

{

prin

tEJB

KP”Im

pfalse

\n”;

}

}else

{

prin

tEJB

KP”Noref\n”

;}$k=$k!1;

if($k

==!1){

$k=$num

Relation

!1;

$i=$i!1;

}

}closeEJB

KP;


#genero

elmts

subgen

mts{

$a=shift

;my$req

=””;

my$trans

=””;

$req=$relationsR

eq[$a

];$trans

=$relatio

nsTran

s[$a

];if

($req=˜m/[A!Z!>0!9]/){

$mts=”

req=”.$req

.”\n

trans=”.$trans

.”\n”

;}else

{

$mts=”

noreq\n

trans=”.$trans

.”\n”

;}$mts=”one

sigmts

extendsMTS{}{\n

init=S0\n”

.$mts.”

\}\n\n”

;retu

rn($m

ts);

}#chequeo

laprop

queno

sonrefinam

ientossub

checkRef{

my$m1=shift

;my$m2=shift

;$m1=˜s/mts/mts1/g;

$m2=˜s/mts/mts2/g;

open(FILE

,”>InstanciesM

ts.als”

);prin

tFIL

E”m

oduleInstanciesM

ts\n”

;prin

tFIL

E”open

RelationM

inimal3S

tate\n\n”

;prin

tFIL

E$m1.”\n”

;prin

tFIL

E$m2.”\n\n”

;close

FILE;

my$r=‘tim

ejava

!Xmx10000m

!cp

alloy4.jar

edu.mit.csail.sdg

.alloy4whole

.Exam

pleUsingT

heCom

pilerallo

yInstanciaA.als

‘;

if($r

=˜/U

nsatisfiab

le/){

return

(1);

}else{

return

(0);

}

100E.Codigo}#chequeo

propiedaden

lacual

existeuna

imp

talque

...sub

checkImp{

my$r=‘java

!Xmx10000m

!cp

alloy4.jar

edu.mit.csail.sdg

.alloy4whole

.Exam

pleUsingT

heCom

pilerallo

yInstan

ciaB.als

‘;if

($r=˜/U

nsatisfiab

le/){

return

(1);

}else

{

return

(0);

}

}#chequeo

siel

grafoes

conexo.

subis

conexo{

my$t=shift

;open

(FILE,”>InstancieC

onexo.als”

);prin

tFIL

E”m

oduleInstancieC

onexo\n”

;prin

tFIL

E”open

libraryAux\n\n”

;prin

tFIL

E”one

sigTextends

Tran

sition{}{\n”

;prin

tFIL

E”

trans=”.$t.”

\n}\n\n”

;close

FILE;

my$r=‘java

!Xmx1500m

!cp

alloy4.jar

edu.mit.csail.sdg

.alloy4whole

.Exam

pleUsingT

heCom

pilerIsC

onexo.als

‘;if

($r=˜/U

nsatisfiab

le/){

return

(0);

}else

{

return

(1);

}

}E.2.1Es

conexo

module

IsConexo

openInstancieC

onexo

predis

con(T:Tran

sition){


isconexo

[T]

}runis

confor

1

E.2.2Antecendente

delapropiedad

module

AlloyInstanceA

openlib

raryopen

RelationM

inimal3S

tateopen

InstanciesMts

preda{

somef1,f2:Bijection

,r:

Relation

|

mts1

.init!>mts2

.init

in(f1

.rel).(

r.rel).(

f2.rel)

andStrongR

efinement[(f1

.rel).(

r.rel).(

f2.rel),

mts1

.trans,mts1

.req,mts2

.trans,mts2

.req]

}runafor

5

E.2.3Consecuente

delapropiedad

module

AlloyInstanceB

openRelationM

inimal3S

tateopen

InstanciesMts

onesig

lts1exten

dsLTS{}{

init=S0

}preda(lts1

:LTS

){

(somef1,f2:Bijection

,r:

Relation

|

mts2

.init!>lts1

.init

in(f1

.rel).(

r.rel).(

f2.rel)

andStrongIm

plementation

[(f1.rel

).(r.rel

).(f2.rel),

mts2

.trans,mts2

.req,lts1

.trans])

and!(som

ef1,f2:Bijection

,r:

Relation

|

mts1

.init!>lts1

.init

in(f1

.rel).(

r.rel).(

f2.rel)

and

102E.CodigoStrongIm

plementation

[(f1.rel

).(r.rel

).(f2.rel),

mts1

.trans,mts1

.req,lts1

.trans])

}runafor

1

E.3KodK

od

E.3.1Clase

Transition

import

kodkod.ast.E

xpression;

import

kodkod.ast.R

elation;

import

kodkod.ast.Form

ula;

import

kodkod.ast.V

ariable;

/((

(@author

Carolina

Dania

&Nazareno

Aguirre

((/

public

classTran

sition{

public

finalRelation

trans;

public

finalRelation

state,action

,tau

;

public

Tran

sition(){

state=Relation

.unary(”State

”);

action=Relation

.unary(”A

ction”);

tau=Relation

.unary(”T

au”);

trans=Relation

.nary(”T

rans”,3);

}public

Formula

arrow(V

ariables1,Variable

s2,Variable

a){

finalForm

ulaarrow

=(a.product(s1

.product(s2))).in

(trans);

return

arrow;

}

E.3.KodKod103

public

Formula

arrowT(V

ariables1,Variable

s2,Variable

a){

finalForm

ulaarrow

T=(arrow

(s1,s2,a)).or((a

.eq(tau

)).and(s1

.eq(s2

)));retu

rnarrow

T;

}public

Formula

clTArrow

ClT(V

ariables1,Variable

s2,Variable

a){

finalExpression

rel=s1.product(s2

);fin

alExpression

clTArrow

=(tau

.join(tran

s)).reflex

iveC

losure();

finalForm

ulaclT

Arrow

Clt=rel.in

((clTArrow

.join(a.jo

in(tran

s))).jo

in(clT

Arrow

));retu

rnclT

Arrow

Clt;

}public

Formula

clTArrow

TClT(V

ariables1,Variable

s2,Variable

a){

finalForm

ulaclT

Arrow

TClT=clT

Arrow

ClT(s1

,s2,a).or((a

.eq(tau

)).and(s1

.eq(s2

)));retu

rnclT

Arrow

TClT;

}public

Expression

augTauT

ransition(){

finalExpression

RelS

tate=state

.product(state);

finalExpression

augTauT

rans=this.tran

s.union

(tau.product((

Relation

.IDEN

).intersectio

n(R

elState

)));retu

rnaugT

auTrans;

}public

Expression

preImageC

lTau(Expression

c){

finalExpression

preImageC

lTau=((tau

.join(tran

s)).in

tersection(state

.product(c))).

reflexiveC

losure();

return

preImageC

lTau;

}public

Formula

altStrongS

imulation

(Expression

r,Tran

sitionother)

{

finalVariable

a=Variable

.unary(”a”

);fin

alVariable

s1=Variable

.unary(”s1

”);

finalVariable

s2=Variable

.unary(”s2

”);

finalVariable

s3=Variable

.unary(”s3

”);

finalVariable

s4=Variable

.unary(”s4

”);

finalForm

ulastrongS

imConsequentB

ody=(s2

.product(s4)).in

(a.jo

in(other

.trans)).and

((s3.product(s4

)).in(r));

104E.Codigofin

alForm

ulastrongS

imConsequent

=strongS

imConsequentB

ody.forSom

e(s4

.oneOf(state

));fin

alForm

ulastrongSim

Body

=((s1

.product(s2)).in

(r)).and

((s1.product(s3

)).in(a.jo

in(th

is.tran

s)));

finalForm

ulastrongS

imAll=strongSim

Body

.implies

(strongSimConsequent);

finalForm

ulastrongSim

A=strongS

imAll.forA

ll(a.oneO

f(action));

finalForm

ulastrongS

imS=strongSim

A.forA

ll(s3.oneO

f(state)).forA

ll(s2.oneO

f(state)).forA

ll(s1.oneO

f(state));

return

strongSimS;

}

public

Formula

altStro

ngBisim

ulatio

n(Expression

r,Tran

sitionother)

{

finalForm

ulaaltS

trongBisI

=this.altS

trongSimulatio

n(r,other

);fin

alForm

ulaaltS

trongBisD

=other

.altStrongS

imulation

(r.transpose(),this);

finalForm

ulaaltS

trongBis=altS

trongBisI

.and(altS

trongBisD

);retu

rnaltS

trongBis;

}public

Formula

strongSimulation

(Expression

r,Tran

sitionother)

{

finalVariable

a=Variable

.unary(”a”

);fin

alForm

ulastrongSim

Body

=((r.transpose

()).join(a.jo

in(th

is.tran

s))).in

(a.jo

in(other

.trans).jo

in(r.transpose

()));fin

alForm

ulastrongS

im=strongSim

Body

.forAll(a

.oneOf(action

));retu

rnstrongS

im;

}public

Formula

strongBisim

ulation(Expression

r,Tran

sitionother)

{

finalForm

ulastrongB

is=this.strongS

imulation

(r,other

).and(other.strongS

imulation

(r.transpose(),this));

return

strongBis;

}public

Formula

branchingSimulation

(Expression

r,Tran

sitionother)

{

finalVariable

a=Variable

.unary(”a”

);fin

alVariable

s1=Variable

.unary(”s1

”);

finalVariable

s2=Variable

.unary(”s2

”);

finalVariable

s3=Variable

.unary(”s3

”);

finalVariable

s4=Variable

.unary(”s4

”);

finalVariable

s5=Variable

.unary(”s5

”);

finalForm

ulabranchSim

BodyI

=(th

is.arrow

(s1,s2,a)).and

((s1.product(s3

)).in(r));

finalForm

ulabranchSim

Body1

=(s3

.product(s4)).in

(other.preImageC

lTau(s1

.join(r)));

E.3.KodKod105

finalForm

ulabranchSim

Body2

=other.arrow

T(s4

,s5,a);

finalForm

ulabranchSim

Body3

=((s1

.product(s4)).union

(s2.product(s5

))).in(r);

finalForm

ulabranchSim

BodyP

=(branchSim

Body1

.and(branchSim

Body2

)).and(branchSim

Body3

);fin

alForm

ulabranchSim

Body

=(branchSim

BodyP

.forSome(s5

.oneOf(state

))).forSome(s4

.oneOf(state

));fin

alForm

ulabranchSim

=(branchSim

BodyI.im

plies(branchSim

Body

)).forAll(a

.oneOf(action

));fin

alForm

ulabranchingS

im=((branchSim

.forAll(s3

.oneOf(state

))).forAll(s2

.oneOf(state

))).forAll(s1

.oneOf(state

));retu

rnbranchingS

im;

}public

Formula

branchingBisim

ulation(Expression

r,Tran

sitionother)

{

finalForm

ulabranchB

is=this.branchingS

imulation

(r,other

).and(other

.branchingSimulation


return

branchBis;

}public

Formula

weakS

imulation

(Expression

r,Tran

sitionother)

{

finalVariable

a=Variable

.unary(”a”

);fin

alExpression

setPart

=(tau

.join(other

.trans)).reflex

iveC

losure();

finalExpression

set=((setP

art.join(a.jo

in(other

.augTauT

ransition()))).jo

in(setP

art)).jo

in(r.transpose

());fin

alForm

ulaweakSim

Body

=((r.transpose

()).join(a.jo

in(th

is.tran

s))).in

(set);fin

alForm

ulaweakSim

=weakSim

Body

.forAll(a

.oneOf(action

));retu

rnweakSim

;}public

Formula

weakB

isimulation

(Expression

r,Tran

sitionother

){

finalForm

ulaWeakB

is=this.weakS

imulation

(r,other

).and(other

.weakS

imulation


return

WeakB

is;}public

Formula

strongRefinem

ent(Expression

r,Tran

sition

thisr

,Tran

sitionother

,Tran

sitionotherr)

{

finalForm

ulastrongR

ef=thisr

.strongSimulation

(r,otherr

).and(other

.strongSimulation


return

strongRef;

}public

Formula

weakR

efinement(E

xpressionr,Tran

sition

thisr

,Tran

sitionother

,Tran

sitionotherr)

{

finalForm

ulaweakR

ef=thisr

.weakS

imulation

(r,otherr

).and(other

.weakS

imulation


return

weakR

ef;

106E.Codigo}public

Formula

strongImplem

entation(Expression

r,Tran

sition

thisr

,Tran

sitionother)

{

finalForm

ulastrongIm

p=this.strongR

efinement(r

,thisr

,other

,other

);retu

rnstrongIm

p;

}public

Formula

weakIm

plementation

(Expression

r,Tran

sition

thisr

,Tran

sitionother)

{

finalForm

ulaweakIm

p=this.weakR

efinement(r

,thisr

,other

,other

);retu

rnweakIm

p;

}public

Formula

branchingImplem

entation(Expression

r,Tran

sition

thisr

,Tran

sitionother)

{

finalVariable

a=Variable

.unary(”a”

);fin

alVariable

s1=Variable

.unary(”s1

”);

finalVariable

s2=Variable

.unary(”s2

”);

finalVariable

s3=Variable

.unary(”s3

”);

finalVariable

s4=Variable

.unary(”s4

”);

finalVariable

s5=Variable

.unary(”s5

”);

finalForm

ulabodyR

1=(thisr

.arrow(s1

,s2,a)).and

((s1.product(s3

)).in(r));

finalForm

ulabodyR

2=((s3

.product(s4)).in

(other.preIm

ageClTau(s1

.join(r)))).and

((s2.product(s5

)).in(r));

finalForm

ulabodyR

3=((bodyR

2.and

(other.arrow

T(s4

,s5,a))).forSom

e(s5

.oneOf(state

))).forSome(s4

.oneOf(state

));fin

alForm

ulabodyR

=((bodyR

1.im

plies(bodyR

3)).forA

ll(s3.oneO

f(state))).forA

ll(a.oneO

f(action));

finalForm

ulabranchIm

pR=(bodyR

.forAll(s2

.oneOf(state

))).forAll(s1

.oneOf(state

));fin

alForm

ulabodyT

1=(other

.arrow(s1

,s2,a)).and

((s1.product(s3

)).in(r.transpose

()));fin

alForm

ulabodyT

2a=((s3

.product(s4)).in

(this.preIm

ageClTau(s1

.join(r.transpose

()))));fin

alForm

ulabodyT

2b=bodyT

2a.and

((s2.product(s5

)).in(r.transpose

()));fin

alForm

ulabodyT

3=((bodyT

2b.and

(this.arrow

T(s4

,s5,a))).forSom

e(s5

.oneOf(state

))).forSome(s4

.oneOf(state

));fin

alForm

ulabodyT

=((bodyT

1.im

plies(bodyT

3)).forA

ll(s3.oneO

f(state))).forA

ll(a.oneO

f(action));

finalForm

ulabranchIm

pT=(bodyT

.forAll(s2

.oneOf(state

))).forAll(s1

.oneOf(state

));fin

alForm

ulabranchingIm

p=branchIm

pR.and

(branchImpT

);retu

rnbranchingIm

p;

}

}

E.3.KodKod107

E.3.2Clase

LTS

import

kodkod.ast.R

elation;

import

kodkod.ast.Form

ula;

import

kodkod.ast.E

xpression;

/((

(@author

Carolina

Dania

&Nazareno

Aguirre

((/

public

class

Lts{

public

finalRelation

init;

public

finalTran

sition

trans;

public

Lts(){

init=Relation

.nary(”Init”

,1);

trans=new

Tran

sition();

}public

Formula

SB(Expression

r,Lts

other){

finalForm

ulaProp

=this.tran

s.strongB

isimulation

(r,other

.trans);

finalForm

ulaPre=(th

is.in

it.product(other.init)).in

(r);fin

alForm

ulaSB=Prop

.and(Pre);

return

SB;

}public

Formula

AltSB

(Expression

r,Lts

other){

finalForm

ulaProp

=this.tran

s.altS

trongBisim

ulatio

n(r,other

.trans);

finalForm

ulaPre=(th

is.in

it.product(other.in

it)).in

(r);fin

alForm

ulaSB=Prop

.and(Pre);

return

SB;

}

108E.Codigopublic

Formula

BS(Expression

r,Lts

other){

finalForm

ulaProp

=this.tran

s.branchingS

imulation

(r,other

.trans);

finalForm

ulaPre=(th

is.in

it.product(other.in

it)).in

(r);fin

alForm

ulaBB=Prop

.and(Pre);

return

BB;

}public

Formula

BB(Expression

r,Lts

other){

finalForm

ulaProp

=this.tran

s.branchingB

isimulation

(r,other

.trans);

finalForm

ulaPre=(th

is.in


(r);fin

alForm

ulaBB=Prop

.and(Pre);

return

BB;

}public

Formula

WS(E

xpressionr,Lts

other){

finalForm

ulaProp

=this.tran

s.weakS

imulation

(r,other.tran

s);

finalForm

ulaPre=(th

is.in


(r);fin

alForm

ulaWB=Prop

.and(Pre);

return

WB;

}public

Formula

WB(E

xpressionr,Lts

other){

finalForm

ulaProp

=this.tran

s.weakB

isimulation

(r,other.tran

s);

finalForm

ulaPre=(th

is.in

it.product(other.in

it)).in

(r);fin

alForm

ulaWB=Prop

.and(Pre);

return

WB;

}

}

E.3.KodKod109

E.3.3Clase

MTS

import

kodkod.ast.Form

ula;

import

kodkod.ast.E

xpression;

/((

(@author

Carolina

Dania

&Nazareno

Aguirre

((/

public

class

Mtsexten

dsLts{

public

finalTran

sitionreq

;

public

Mts()

{

req=new

Tran

sition();

}public

Formula

SR(Rel

r,Mts

other){

finalForm

ulaProp

=this.tran

s.strongR

efinement(r.rel

,this.req

,other

.trans,other

.req);

finalForm

ulaIsR

el=(th

is.in


(r.rel);fin

alForm

ulaSR=Prop

.and(IsR

el);retu

rnSR;

}public

Formula

WR(E

xpressionr,Mts

other){

finalForm

ulaProp

=this.tran

s.weakR

efinement(r

,this.req

,other

.trans,other

.req);

finalForm

ulaIsR

el=(th

is.in

it.product(other.in

it)).in

(r);fin

alForm

ulaWR=Prop

.and(IsR

el);retu

rnWR;

}public

Formula

SI(Expression

r,Lts

other){

finalForm

ulaImp1=this.tran

s.strongIm

plementation

(r,this.req

,other

.trans);

finalForm

ulaIsR

el=(th

is.in

it.product(other.in

it)).in

(r);

110E.Codigofin

alForm

ulaSI=Imp1.and

(IsRel);

return

SI;}public

Formula

WI(E

xpressionr,Lts

other){

finalForm

ulaImp1=this.tran

s.weakIm

plementation

(r,this.req

,other

.trans);

finalForm

ulaIsR

el=(th

is.in

it.product(other.in

it)).in

(r);fin

alForm

ulaWI=Imp1.and

(IsRel);

return

WI;

}public

Formula

BI(E

xpressionr,Lts

other){

finalForm

ulaImp1=this.tran

s.branchingIm

plementation

(r,this.req

,other

.trans);

finalForm

ulaIsR

el=(th

is.in

it.product(other.in

it)).in

(r);fin

alForm

ulaBI=Imp1.and

(IsRel);

return

BI;

}

}

E.3.KodKod111

E.3.4Clase

Rel

import

kodkod.ast.R

elation;

/((

(@author

Carolina

Dania

&Nazareno

Aguirre

((/

public

class

Rel{

public

finalRelation

rel;

public

Rel()

{

rel=Relation

.nary(”R

el”,2);

}

}

112E.CodigoE.3.5

Ejemplos

de(bi)sim

ulaciones

import

java.util

.List;

import

java.util

.LinkedL

ist;

import

kodkod.ast.Form

ula;

import

kodkod.ast.R

elation;

import

kodkod.in

stance.Bounds;

import

kodkod.in

stance.Tuple

;import

kodkod.in

stance.TupleF

actory;

import

kodkod.in

stance.Universe

;import

kodkod.engine

.Solution

;import

kodkod.engine

.Solver;

import

kodkod.engine

.satlab.SA

TFactory

;

/((

(@author

Carolina

Dania

&Nazareno

Aguirre

((/

public

class

Exam

plesLtsT

oLts{

public

finalLts

p,q;

public

finalRel

rel;public

finalRelation

state,action

,tau

;

public

Exam

plesLtsT

oLts(){

state=Relation

.unary(”State

”);

action=Relation

.unary(”A

ction”);

tau=Relation

.unary(”T

au”);

p=new

Lts();

q=new

Lts();

rel=new

Rel();

}

E.3.KodKod113

public

Bounds

boundsSystem(in

tstates

,intactio

ns){

finalList<String

>atom

s=new

LinkedL

ist<String

>();

for(in

ti=0;

i<states

;i++){

atoms.add

(”S”+i);

}for(in

ti=0;

i<actio

ns;i++){

atoms.add

(”act”

+i);

}atoms.add

(”tau

”);

finalUniverse

universe=new

Universe

(atoms);

finalTupleF

actoryfacto

ry=universe

.factory();

finalBounds

b=new

Bounds(universe

);fin

alString

stateMax=”S”

+(states

!1);

b.boundE

xactly(th

is.state

,facto

ry.range

(factory.tu

ple(”S0”

),facto

ry.tuple

(stateMax)));

b.boundE

xactly(th

is.action

,facto

ry.range

(factory.tuple

(”act0

”),

factory.tuple

(”tau

”)));

b.boundE

xactly(th

is.tau

,facto

ry.range

(factory.tuple

(”tau

”),

factory.tuple

(”tau”)));

finalList<Tuple

>pTrans

=new

LinkedL

ist<Tuple

>();

finalList<Tuple

>qTrans

=new

LinkedL

ist<Tuple

>();

//Mts

//P1

yQ1

pTrans

.add(facto

ry.tup

le(”act1

”,”S1”

,”S0”

));pTrans

.add(facto

ry.tup

le(”act0

”,”S0”

,”S1”

));pTrans

.add(facto

ry.tup

le(”act0

”,”S0”

,”S2”

));pTrans

.add(facto

ry.tup

le(”act1

”,”S2”

,”S0”

));qTrans

.add(facto

ry.tup

le(”act0

”,”S0”

,”S2”

));qTrans

.add(facto

ry.tup

le(”act1

”,”S2”

,”S3”

));qTrans

.add(facto

ry.tup

le(”act0

”,”S3”

,”S2”

));qTrans

.add(facto

ry.tup

le(”act0

”,”S3”

,”S1”

));

114E.CodigoqTrans

.add(facto

ry.tu

ple(”act1

”,”S1”

,”S0”

));

b.boundE

xactly(th

is.p.tran

s.state

,facto

ry.range

(factory.tuple

(”S0”),

factory.tuple

(stateMax)));

b.boundE

xactly(th

is.p.tran

s.action

,facto

ry.range

(factory.tuple

(”act0

”),

factory.tuple

(”tau”)));

b.boundE

xactly(th

is.p.tran

s.tau

,facto

ry.range

(factory.tuple

(”tau”),

factory.tuple

(”tau”)));

b.boundE

xactly(th

is.p.tran

s.trans

,facto

ry.setO

f(pTrans

));//

b.bound

(this

.p.trans

.trans,facto

ry.range

(facto

ry.tuple

(”act0

”,”S0”

,”S0

”),

facto

ry.tuple

(”tau

”,stateM

ax,stateM

ax)));

b.boundE

xactly(th

is.p.in

it,facto

ry.range

(factory.tuple

(”S0”),

factory.tuple

(”S0”)));

b.boundE

xactly(th

is.q.tran

s.state

,facto

ry.range

(factory.tuple

(”S0”),

factory.tuple

(stateMax)));

b.boundE

xactly(th

is.q.tran

s.action

,facto

ry.range

(factory.tuple

(”act0

”),

factory.tuple

(”tau”)));

b.boundE

xactly(th

is.q.tran

s.tau

,facto

ry.range

(factory.tuple

(”tau”),

factory.tuple

(”tau”)));

b.boundE

xactly(th

is.q.tran

s.trans

,facto

ry.setO

f(qTrans

));//

b.bound

(this

.q.trans

.trans,facto

ry.range

(facto

ry.tuple

(”act0

”,”S0”

,”S0

”),

facto

ry.tuple

(”tau

”,stateM

ax,stateM

ax)));

b.boundE

xactly(th

is.q.in

it,facto

ry.range

(factory.tuple

(”S0”),

factory.tuple

(”S0”)));

//Relations

finalList<Tuple

>relU

pperBound

=new

LinkedL

ist<Tuple

>();

String

stateI=””;

String

stateF=””;

for(in

ti=0;

i<states

;i++){

for(in

tj=0;

j<states

;j++){

stateI=”S”+j;

stateF=”S”+i;

relUpperB

ound.add

(factory.tuple

(stateI,stateF

));}

}b.bound

(this.rel.rel

,facto

ry.setO

f(relUpperB

ound));

//

b.bound

(this

.rel.rel,facto

ry.range

(facto

ry.tuple

(”S0”

,”S0

”),

facto

ry.tup

le(stateM

ax,stateM

ax)));

return

b;

}

E.3.KodKod115

public

static

voidmain

(String

[]args

){

System.out.p

rintln

(”Hola

mundo”

);//TODO

Auto!generated

method

stubfin

alExam

plesLtsT

oLts

model

=new

Exam

plesLtsT

oLts();

finalSolver

solver=new

Solver

();solver

.options().setS

olver(SA

TFactory

.MiniS

at);//P1

yQ1

finalForm

ulashow

=model.p

.BB(model.rel.rel

,model.q

);fin

alSolution

sol=solver

.solve(show

,model.boundsSystem

(4,2));

System.out.p

rintln

(show);

System.out.p

rintln

(sol);}

}

116E.CodigoE.3.6

Ejemplos

derefinam

ientos

import

java.util

.List;

import

java.util

.LinkedL

ist;

import

kodkod.ast.Form

ula;

import

kodkod.ast.R

elation;

import

kodkod.in

stance.Bounds;

import

kodkod.in

stance.Tuple

;import

kodkod.in

stance.TupleF

actory;

import

kodkod.in

stance.Universe

;import

kodkod.engine

.Solution

;import

kodkod.engine

.Solver;

import

kodkod.engine

.satlab.SA

TFactory

;

/((

(@author

Carolina

Dania

&Nazareno

Aguirre

((/

public

class

Exam

plesMtsT

oLts{

public

finalMtsp;

public

finalLts

q;

public

finalRel

rel;public

finalRelation

state,action

,tau

;

public

Exam

plesMtsT

oLts(){

state=Relation

.unary(”State

”);

action=Relation

.unary(”A

ction”);

tau=Relation

.unary(”T

au”);

p=new

Mts();

q=new

Lts();

rel=new

Rel();

}

E.3.KodKod117

public

Bounds

boundsSystemM(in

tstates

,intactio

ns){

finalList<String

>atom

s=new

LinkedL

ist<String

>();

for(in

ti=0;

i<states

;i++){

atoms.add

(”S”+i);

}for(in

ti=0;

i<actio

ns;i++){

atoms.add

(”act”

+i);

}atoms.add

(”tau”);

finalUniverse

universe=new

Universe

(atoms);

finalTupleF

actoryfacto

ry=universe

.factory();

finalBounds

b=new

Bounds(universe

);fin

alString

stateMax=”S”

+(states

!1);//,actionM

ax=

”act”

+(actions

!1);

b.boundE

xactly(th

is.state

,facto

ry.range

(factory.tu

ple(”S0”

),facto

ry.tuple

(stateMax)));

b.boundE

xactly(th

is.action

,facto

ry.range

(factory.tuple

(”act0

”),

factory.tuple

(”tau

”)));

b.boundE

xactly(th

is.tau

,facto

ry.range

(factory.tuple

(”tau”),

factory.tuple

(”tau”)));

finalList<Tuple

>pTrans

=new

LinkedL

ist<Tuple

>();

finalList<Tuple

>pReq=new

LinkedL

ist<Tuple

>();

finalList<Tuple

>qTrans

=new

LinkedL

ist<Tuple

>();

//P12

yQ12

pTrans

.add(facto

ry.tu

ple(”tau

”,”S0”

,”S1”

));pTrans

.add(facto

ry.tu

ple(”act0

”,”S0”

,”S2”

));pTrans

.add(facto

ry.tu

ple(”act0

”,”S1”

,”S3”

));pTrans

.add(facto

ry.tu

ple(”act1

”,”S2”

,”S4”

));pTrans

.add(facto

ry.tu

ple(”tau

”,”S2”

,”S5”

));pReq.add

(factory.tu

ple(”act0

”,”S0”

,”S2”

));pReq.add

(factory.tu

ple(”act1

”,”S2”

,”S4”

));pReq.add

(factory.tu

ple(”tau

”,”S2”

,”S5”

));

118E.CodigoqTrans

.add(facto

ry.tu

ple(”act0

”,”S0”

,”S1”

));qTrans

.add(facto

ry.tu

ple(”act0

”,”S0”

,”S3”

));qTrans

.add(facto

ry.tu

ple(”act1

”,”S1”

,”S2”

));qTrans

.add(facto

ry.tu

ple(”tau

”,”S1”

,”S3”

));

b.boundE

xactly(th

is.p.tran

s.state

,facto

ry.range

(factory.tuple

(”S0”),

factory.tuple

(stateMax)));

b.boundE

xactly(th

is.p.tran

s.action

,facto

ry.range

(factory.tuple

(”act0

”),

factory.tuple

(”tau”)));

b.boundE

xactly(th

is.p.tran

s.tau

,facto

ry.range

(factory.tuple

(”tau”),

factory.tuple

(”tau”)));

b.boundE

xactly(th

is.p.tran

s.trans

,facto

ry.setO

f(pTrans

));b.boundE

xactly(th

is.p.req

.state,facto

ry.range

(factory.tuple

(”S0”),

factory.tu

ple(stateM

ax)));

b.boundE

xactly(th

is.p.req

.action,facto

ry.range

(factory.tuple

(”act0

”),

factory.tuple

(”tau”)));

b.boundE

xactly(th

is.p.req

.tau,facto

ry.range

(factory.tuple

(”tau”),

factory.tu

ple(”tau

”)));

b.boundE

xactly(th

is.p.req

.trans,facto

ry.setO

f(pReq));

b.boundE

xactly(th

is.p.in

it,facto

ry.range

(factory.tuple

(”S0”),

factory.tuple

(”S0”)));

b.boundE

xactly(th

is.q.tran

s.state

,facto

ry.range

(factory.tuple

(”S0”),

factory.tuple

(stateMax)));

b.boundE

xactly(th

is.q.tran

s.action

,facto

ry.range

(factory.tuple

(”act0

”),

factory.tuple

(”tau”)));

b.boundE

xactly(th

is.q.tran

s.tau

,facto

ry.range

(factory.tuple

(”tau”),

factory.tuple

(”tau”)));

b.boundE

xactly(th

is.q.tran

s.trans

,facto

ry.setO

f(qTrans

));b.boundE

xactly(th

is.q.in

it,facto

ry.range

(factory.tuple

(”S0”),

factory.tuple

(”S0”)));

//Relations

finalList<Tuple

>relU

pperBound

=new

LinkedL

ist<Tuple

>();

String

stateI=””;

String

stateF=””;

for(in

ti=0;

i<states

;i++){

for(in

tj=0;

j<states

;j++){

stateI=”S”+j;

stateF=”S”+i;

relUpperB

ound.add

(factory.tuple

(stateI,stateF

));}

}b.bound

(this.rel.rel

,facto

ry.setO

f(relUpperB

ound));

E.3.KodKod119

return

b;

}public

static

voidmain

(String

[]args

){

System.out.p

rintln

(”Hola

mundo”

);//TODO

Auto!generated

method

stubfin

alExam

plesMtsT

oLts

model

=new

Exam

plesMtsT

oLts();

finalSolver

solver=new

Solver

();solver

.options().setS

olver(SA

TFactory

.MiniS

at);//P12

yQ12

finalForm

ulashow

=model.p

.BI(m

odel.rel.rel,model.q

);fin

alSolution

sol=solver

.solve(show

,model.boundsSystem

M(6,2));

System.out.p

rintln

(show);

System.out.p

rintln

(sol);}

}

120E.CodigoE.3.7

Ejemplos

deimplem

entaciones

import

java.util

.List;

import

java.util

.LinkedL

ist;

import

kodkod.ast.Form

ula;

import

kodkod.ast.R

elation;

import

kodkod.in

stance.Bounds;

import

kodkod.in

stance.Tuple

;import

kodkod.in

stance.TupleF

actory;

import

kodkod.in

stance.Universe

;import

kodkod.engine

.Solution

;import

kodkod.engine

.Solver;

import

kodkod.engine

.satlab.SA

TFactory

;

/((

(@author

Carolina

Dania

&Nazareno

Aguirre

((/

public

class

Exam

plesMtsT

oMts{

public

finalMtsp,q;

public

finalRel

rel;public

finalRelation

state,action

,tau

;

public

Exam

plesMtsT

oMts()

{

state=Relation

.unary(”State

”);

action=Relation

.unary(”A

ction”);

tau=Relation

.unary(”T

au”);

p=new

Mts();

q=new

Mts();

rel=new

Rel();

}

E.3.KodKod121

public

Bounds

boundsSystemM(in

tstates

,intactio

ns){

finalList<String

>atom

s=new

LinkedL

ist<String

>();

for(in

ti=0;

i<states

;i++){

atoms.add

(”S”+i);

}for(in

ti=0;

i<actio

ns;i++){

atoms.add

(”act”

+i);

}atoms.add

(”tau”);

finalUniverse

universe=new

Universe

(atoms);

finalTupleF

actoryfacto

ry=universe

.factory();

finalBounds

b=new

Bounds(universe

);fin

alString

stateMax=”S”

+(states

!1);//,actionM

ax=

”act”

+(actions

!1);

b.boundE

xactly(th

is.state

,facto

ry.range

(factory.tu

ple(”S0”

),facto

ry.tuple

(stateMax)));

b.boundE

xactly(th

is.action

,facto

ry.range

(factory.tuple

(”act0

”),

factory.tuple

(”tau

”)));

b.boundE

xactly(th

is.tau

,facto

ry.range

(factory.tuple

(”tau”),

factory.tuple

(”tau”)));

finalList<Tuple

>pTrans

=new

LinkedL

ist<Tuple

>();

finalList<Tuple

>pReq=new

LinkedL

ist<Tuple

>();

finalList<Tuple

>qTrans

=new

LinkedL

ist<Tuple

>();

finalList<Tuple

>qReq=new

LinkedL

ist<Tuple

>();

//P7

yQ7

pTrans

.add(facto

ry.tup

le(”act0

”,”S0”

,”S1”

));pTrans

.add(facto

ry.tup

le(”act1

”,”S1”

,”S2”

));pTrans

.add(facto

ry.tup

le(”act1

”,”S2”

,”S1”

));pTrans

.add(facto

ry.tup

le(”act2

”,”S2”

,”S0”

));pReq.add

(factory.tu

ple(”act0

”,”S0”

,”S1”

));pReq.add

(factory.tu

ple(”act1

”,”S1”

,”S2”

));qTrans

.add(facto

ry.tup

le(”act0

”,”S0”

,”S1”

));qTrans

.add(facto

ry.tup

le(”act1

”,”S1”

,”S2”

));

122E.CodigoqTrans

.add(facto

ry.tu

ple(”act1

”,”S2”

,”S1”

));qTrans

.add(facto

ry.tu

ple(”act2

”,”S2”

,”S0”

));qReq.add

(factory.tup

le(”act0

”,”S0”

,”S1”

));qReq.add

(factory.tup

le(”act1

”,”S1”

,”S2”

));qReq.add

(factory.tup

le(”act2

”,”S2”

,”S0”

));

b.boundE

xactly(th

is.p.tran

s.state

,facto

ry.range

(factory.tuple

(”S0”),

factory.tuple

(stateMax)));

b.boundE

xactly(th

is.p.tran

s.action

,facto

ry.range

(factory.tuple

(”act0

”),

factory.tuple

(”tau”)));

b.boundE

xactly(th

is.p.tran

s.tau

,facto

ry.range

(factory.tuple

(”tau”),

factory.tuple

(”tau”)));

b.boundE

xactly(th

is.p.tran

s.trans

,facto

ry.setO

f(pTrans

));b.boundE

xactly(th

is.p.req

.state,facto

ry.range

(factory.tuple

(”S0”),

factory.tu

ple(stateM

ax)));

b.boundE

xactly(th

is.p.req

.action,facto

ry.range

(factory.tuple

(”act0

”),

factory.tuple

(”tau”)));

b.boundE

xactly(th

is.p.req

.tau,facto

ry.range

(factory.tuple

(”tau”),

factory.tu

ple(”tau

”)));

b.boundE

xactly(th

is.p.req

.trans,facto

ry.setO

f(pReq));

b.boundE

xactly(th

is.p.in

it,facto

ry.range

(factory.tuple

(”S0”),

factory.tuple

(”S0”)));

b.boundE

xactly(th

is.q.tran

s.state

,facto

ry.range

(factory.tuple

(”S0”),

factory.tuple

(stateMax)));

b.boundE

xactly(th

is.q.tran

s.action

,facto

ry.range

(factory.tuple

(”act0

”),

factory.tuple

(”tau”)));

b.boundE

xactly(th

is.q.tran

s.tau

,facto

ry.range

(factory.tuple

(”tau”),

factory.tuple

(”tau”)));

b.boundE

xactly(th

is.q.tran

s.trans

,facto

ry.setO

f(qTrans

));b.boundE

xactly(th

is.q.req

.state,facto

ry.range

(factory.tuple

(”S0”),

factory.tu

ple(stateM

ax)));

b.boundE

xactly(th

is.q.req

.action,facto

ry.range

(factory.tuple

(”act0

”),

factory.tuple

(”tau

”)));

b.boundE

xactly(th

is.q.req

.tau,facto

ry.range

(factory.tuple

(”tau

”),

factory.tu

ple(”tau

”)));

b.boundE

xactly(th

is.q.req

.trans,facto

ry.setO

f(qReq));

b.boundE

xactly(th

is.q.in

it,facto

ry.range

(factory.tuple

(”S0”),

factory.tuple

(”S0”)));

//Relations

finalList<Tuple

>relU

pperBound

=new

LinkedL

ist<Tuple

>();

String

stateI=””;

String

stateF=””;

for(in

ti=0;

i<states

;i++){

for(in

tj=0;

j<states

;j++){

stateI=”S”+j;

E.3.KodKod123

stateF=”S”+i;

relUpperB

ound.add

(factory.tuple

(stateI,stateF

));}

}b.bound

(this.rel.rel

,facto

ry.setO

f(relUpperB

ound));

return

b;

}public

static

voidmain

(String

[]args

){

System.out.p

rintln

(”Hola

mundo”

);//TODO

Auto!generated

method

stubfin

alExam

plesMtsT

oMts

model

=new

Exam

plesMtsT

oMts();

finalSolver

solver=new

Solver

();solver

.options().setS

olver(SA

TFactory

.MiniS

at);//P7

yQ7

finalForm

ulashow

=model.p

.WR(m

odel.rel.rel,model.q

);fin

alSolution

sol=solver

.solve(show

,model.boundsSystem

M(3,3));

System.out.p

rintln

(show);

System.out.p

rintln

(sol);}

}

124 E. Codigo

Bibliografıa

[BCU06] Greg Brunet, Marsha Chechik, and Sebastian Uchitel. Properties of be-havioural model merging. In Jayadev Misra, Tobias Nipkow, and EmilSekerinski, editors, FM, volume 4085 of Lecture Notes in Computer Sci-ence, pages 98–114. Springer, 2006.

[BRJ98] G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling LanguageUser Guide. AddisonWesley, 1998.

[Cla03] Koen Claessen. New techniques that improve mace-style finite model find-ing. In Proceedings of the CADE-19 Workshop: Model Computation -Principles, Algorithms, Applications, 2003.

[DFCU08] Nicolas D’Ippolito, Dario Fischbein, Marsha Chechik, and Sebastian Uchi-tel. Mtsa: The modal transition system analyser. In ASE, pages 475–476.IEEE, 2008.

[DFFU07] Nicolas D’Ippolito, Dario Fischbein, Howard Foster, and Sebastian Uchi-tel. Mtsa: Eclipse support for modal transition systems construction, anal-ysis and elaboration. In Li-Te Cheng, Alessandro Orso, and Martin P. Ro-billard, editors, ETX, pages 6–10. ACM, 2007.

[Dil94] Antoni Diller. Z: An Introduction to Formal Methods. John Wiley & Sons,Inc., New York, NY, USA, 1994.

[Dis]

[DPP01] Agostino Dovier, Carla Piazza, and Alberto Policriti. A fast bisimulationalgorithm. In Gerard Berry, Hubert Comon, and Alain Finkel, editors,CAV, volume 2102 of Lecture Notes in Computer Science, pages 79–90.Springer, 2001.

[ES03] Niklas Een and Niklas Sorensson. An extensible sat-solver. In EnricoGiunchiglia and Armando Tacchella, editors, SAT, volume 2919 of LectureNotes in Computer Science, pages 502–518. Springer, 2003.

[FGPA05] Marcelo F. Frias, Juan P. Galeotti, Carlos Lopez Pombo, and NazarenoAguirre. Dynalloy: upgrading alloy with actions. In Gruia-Catalin Roman,William G. Griswold, and Bashar Nuseibeh, editors, ICSE, pages 442–451.ACM, 2005.

125

126 BIBLIOGRAFIA

[Fis] Dario Fischbein. On strong refinement outline or on mts strong semantic-s/refinement and merge. Notas no publicadas.

[Fis06] Dario Fischbein. Branching semantics for modal transition systems. Mas-ter’s thesis, Universidad de Buenos Aires, 2006.

[FPB+05] Marcelo F. Frias, Carlos Lopez Pombo, Gabriel A. Baum, NazarenoAguirre, and T. S. E. Maibaum. Reasoning about static and dynamicproperties in alloy: A purely relational approach. ACM Trans. Softw. Eng.Methodol., 14(4):478–526, 2005.

[FUB06] Dario Fischbein, Sebastian Uchitel, and Vıctor A. Braberman. A founda-tion for behavioural conformance in software product line architectures. InRobert M. Hierons and Henry Muccini, editors, ROSATEA, pages 39–48.ACM, 2006.

[GJM02] Carlo Ghezzi, Mehdi Jazayeri, and Dino Mandrioli. Fundamentals of Soft-ware Engineering. Prentice Hall PTR, Upper Saddle River, NJ, USA, 2002.

[GN07] Eugene Goldberg and Yakov Novikov. Berkmin: A fast and robust sat-solver. Discrete Appl. Math., 155(12):1549–1561, 2007.

[GV90] Jan Friso Groote and Frits W. Vaandrager. An e"cient algorithm forbranching bisimulation and stuttering equivalence. In Mike Paterson, edi-tor, ICALP, volume 443 of Lecture Notes in Computer Science, pages 626–638. Springer, 1990.

[Hut05] Michael Huth. Refinement is complete for implementations. Formal Asp.Comput., 17(2):113–137, 2005.

[Ing87] Leif Ingevaldsson. JSP - a Practical Method of Program Design. KriegerPublishing Co., Inc., Melbourne, FL, USA, 1987.

[Jac03] Daniel Jackson. Alloy: A logical modelling language. In Didier Bert,Jonathan P. Bowen, Steve King, and Marina A. Walden, editors, ZB, vol-ume 2651 of Lecture Notes in Computer Science, page 1. Springer, 2003.

[Jac06] Daniel Jackson. Software Abstractions: Logic, Language, and Analysis.The MIT Press, 2006.

[JJD98] Daniel Jackson, Somesh Jha, and Craig Damon. Isomorph-free modelenumeration: A new method for checking relational specifications. ACMTrans. Program. Lang. Syst., 20(2):302–343, 1998.

[KM06] Je! Kramer and Je! Magee. Concurrency: State Models Java Programs,2nd Edition. Worldwide Series in Computer Science. John Wiley Sons,March 2006.

[LT88] Kim Guldstrand Larsen and Bent Thomsen. A modal process logic. InLICS, pages 203–210. IEEE Computer Society, 1988.

[LX90] Kim Guldstrand Larsen and Liu Xinxin. Equation solving using modaltransition systems. In LICS, pages 108–117. IEEE Computer Society,1990.

BIBLIOGRAFIA 127

[McC03] William McCune. Mace4 reference manual and guide. CoRR,cs.SC/0310055, 2003.

[MFM04] Yogesh S. Mahajan, Zhaohui Fu, and Sharad Malik. Zcha!2004: An e"-cient sat solver. In Holger H. Hoos and David G. Mitchell, editors, SAT (Se-lected Papers, volume 3542 of Lecture Notes in Computer Science, pages360–375. Springer, 2004.

[Mil89] R. Milner. Communication and concurrency. Prentice-Hall, Inc., UpperSaddle River, NJ, USA, 1989.

[Som00] I. Sommerville. Software Engineering. Addison Wesley, sexth edition,2000.

[Sto96] Neil R. Storey. Safety Critical Computer Systems. Addison-Wesley Long-man Publishing Co., Inc., Boston, MA, USA, 1996.

[TJ07] Emina Torlak and Daniel Jackson. Kodkod: A relational model finder.pages 632–647. 2007.

[vGW96] Rob J. van Glabbeek and W. P. Weijland. Branching time and abstractionin bisimulation semantics. J. ACM, 43(3):555–600, 1996.

[Win90] Jeannette M. Wing. A specifier’s introduction to formal methods. Com-puter, 23(9):8–23, 1990.

falluto: un model checker para la veriﬁcación de sistemas...

Documents