INTEGRACIÓN DE LÓGICA LINEAL TEMPORAL A MODELOS...

INTEGRACIÓN DE LÓGICA LINEAL TEMPORAL A

MODELOS DE ARQUITECTURAS DE SOFTWARE

BASADAS EN COMPONENTES ESPECIFICADAS A

TRAVÉS DEL CÁLCULO ρarq

OSCAR JAVIER PUENTES PUENTES

INTEGRACIÓN DE LÓGICA LINEAL TEMPORAL SOBRE MODELOS DEARQUITECTURAS DE SOFTWARE BASADAS EN COMPONENTES ESPECIFICADAS

A TRAVÉS DEL CÁLCULO ρarq


UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDASFACULTAD DE INGENIERÍA

MAESTRÍA EN CIENCIAS DE LA INFORMACIÓN Y LAS COMUNICACIONESBOGOTÁ D.C.

2017

INTEGRACIÓN DE LÓGICA LINEAL TEMPORAL A MODELOS DEARQUITECTURAS DE SOFTWARE BASADAS EN COMPONENTES ESPECIFICADAS

A TRAVÉS DEL CÁLCULO ρarq


PROYECTO DE GRADO

MAESTRÍA EN CIENCIAS DE LA INFORMACIÓN Y LAS COMUNICACIONES

Director:Ing. Ph.D. HENRY ALBERTO DIOSA

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDASFACULTAD DE INGENIERÍA

MAESTRÍA EN CIENCIAS DE LA INFORMACIÓN Y LAS COMUNICACIONESBOGOTÁ D. C.

2017

CONTENIDO

1. DESCRIPCIÓN Y PLANTEAMIENTO DEL PROYECTO 101.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2. Formulación del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3.2. Espećıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.4. Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.5. Metodoloǵıa utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2. MARCO REFERENCIAL Y ESTADO DEL ARTE 152.1. Modelos y métodos formales en la Ingenieŕıa de Software . . . . . . . . . . . . 15

2.1.1. Chequeo de modelos de software . . . . . . . . . . . . . . . . . . . . . 162.1.2. Verificación de sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2. Chequeo de modelos y arquitecturas de software . . . . . . . . . . . . . . . . . 182.2.1. Chequeo de arquitecturas de software . . . . . . . . . . . . . . . . . . 182.2.2. Arquitecturas de software y Lenguaje de Modelado Unificado (UML) . 18

2.3. Lógicas Temporales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3.1. Modelado de sistemas y lógicas temporales . . . . . . . . . . . . . . . . 202.3.2. Generalidades de las lógicas temporales . . . . . . . . . . . . . . . . . . 212.3.3. Clasificación de las lógicas temporales . . . . . . . . . . . . . . . . . . . 212.3.4. Lógica de Árboles de Cómputo Cerradura (CTL*) . . . . . . . . . . . . 232.3.5. Lógica de Árboles de Cómputo Simple (CTL) . . . . . . . . . . . . . . 272.3.6. Lógica Lineal Temporal (LTL) . . . . . . . . . . . . . . . . . . . . . . . 29

2.4. Chequeo de modelos y lógicas temporales . . . . . . . . . . . . . . . . . . . . . 322.4.1. Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.4.2. Chequeo de modelos CTL . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.5. Cálculo ρarq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462.5.1. Sintaxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462.5.2. Especificación formal de una arquitectura . . . . . . . . . . . . . . . . . 482.5.3. Semántica Operacional y Ejecución de una arquitectura . . . . . . . . . 492.5.4. Sistemas de Transición Rotulados Condicionados . . . . . . . . . . . . 52

2.6. Lenguajes de Descripción Arquitectural y Lógicas Temporales . . . . . . . . . 542.7. Tecnoloǵıas para el chequeo de modelos . . . . . . . . . . . . . . . . . . . . . . 58

2.7.1. SPIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4

CONTENIDO 5

3. DESARROLLO DE LA SOLUCIÓN 633.1. Sintaxis y semántica de los operadores temporales . . . . . . . . . . . . . . . . 63

3.1.1. Reglas de equivalencia lógica . . . . . . . . . . . . . . . . . . . . . . . . 643.1.2. Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.1.3. Reglas de verificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3.2. Especificación de una propiedad temporal . . . . . . . . . . . . . . . . . . . . 673.3. Verificación de una propiedad temporal . . . . . . . . . . . . . . . . . . . . . . 763.4. Implementación del mecanismo en PintArq . . . . . . . . . . . . . . . . . . . . 81

3.4.1. Modelo funcional de PintArq extendido . . . . . . . . . . . . . . . . . . 813.4.2. Arquitectura prescriptiva extendida . . . . . . . . . . . . . . . . . . . . 893.4.3. Breve descripción de interfaz gráfica de usuario . . . . . . . . . . . . . 963.4.4. Aspecto tecnológico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

4. CONCLUSIONES Y TRABAJO FUTURO 1144.1. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

A. Manual de usuario 116A.1. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116A.2. Operación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

A.2.1. Cargar una especificación de arquitectura . . . . . . . . . . . . . . . . . 117A.2.2. Verificar una propiedad temporal . . . . . . . . . . . . . . . . . . . . . 118

B. Manual de instalación 121B.1. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121B.2. Instalación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

B.2.1. Wildfly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121B.2.2. Graphviz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122B.2.3. Spin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122B.2.4. PintArq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

BIBLIOGRAFIA 123

INDICE DE FIGURAS

1.1. Actividades relevantes para el desarrollo del proyecto . . . . . . . . . . . . . . 14

2.1. Ciclo de vida del software y costos asociados a los errores . . . . . . . . . . . . 172.2. Las cuatro capas de la Arquitectura de Metamodelamiento de UML . . . . . . 192.3. Relación entre las lógicas temporales . . . . . . . . . . . . . . . . . . . . . . . 272.4. Representación gráfica de algunos operadores CTL . . . . . . . . . . . . . . . . 292.5. Representación gráfica de los operadores LTL . . . . . . . . . . . . . . . . . . 302.6. Ejemplo función de etiquetado EX f . Estado inicial del sistema. Parte 1 de 2 . 372.7. Ejemplo función de etiquetado EX f . Estado final del sistema. Parte 2 de 2 . . 382.8. Algoritmo EX f. Desarrollo del árbol del sistema. . . . . . . . . . . . . . . . . 382.9. Ejemplo para la función de etiquetado AF f . . . . . . . . . . . . . . . . . . . 402.10. Ejemplo función de etiquetado E(f1 U f2). Estado inicial del sistema. Parte 1 de 4 412.11. Ejemplo función de etiquetado E(f1 U f2). Estado intermedio 1. Parte 2 de 4 . 422.12. Ejemplo función de etiquetado E(f1 U f2). Estado intermedio 2. Parte 3 de 4 . 422.13. Ejemplo función de etiquetado E(f1 U f2). Estado final del sistema. Parte 4 de 4 432.14. Representación gráfica del algoritmo para EG alternativo . . . . . . . . . . . 452.15. Sintaxis del cálculo ρarq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462.16. Representación gráfica de un componente . . . . . . . . . . . . . . . . . . . . . 492.17. Axiomas del cálculo ρarq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492.18. Reglas de reducción del ρArq . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502.19. Notación gráfica del ensamble de componentes . . . . . . . . . . . . . . . . . 512.20. Reglas de transición del ρArq . . . . . . . . . . . . . . . . . . . . . . . . . . . 532.21. Representación gráfica de un Sistema Productor-Consumidor en SAM . . . . . 552.22. Representación gráfica de un Sistema Productor-Consumidor en CBabel . . . . 562.23. Descripción textual de una arquitectura en Æmilia . . . . . . . . . . . . . . . 572.24. Transformación de diagrama de estados CHARMY a especificación en Promela 572.25. Estructura de una simulación y verificación en SPIN . . . . . . . . . . . . . . 592.26. Ejemplo de la especificación de un modelo a través del lenguaje Promela . . . 602.27. Construcción gramática de una fórmula en LLT en Promela para SPIN. . . . . 62

3.1. Ensamble complejo de componentes . . . . . . . . . . . . . . . . . . . . . . . 683.2. Vista parcial del STR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.3. STPA del Ensamble complejo de componentes . . . . . . . . . . . . . . . . . . 713.4. Ejemplo de representación de la ejecución de un componente en el STPA . . . 723.5. Ejemplo de representación del STPA completo . . . . . . . . . . . . . . . . . 73

6

INDICE DE FIGURAS 7

3.6. Configuración con componentes alternativos para proveer servicios . . . . . . 743.7. STPA para una Configuración con componentes alternativos . . . . . . . . . . 753.8. Relación entre Traces(TS) y Words(ϕ) . . . . . . . . . . . . . . . . . . . . . 783.9. Modelo funcional de PintArq extendido. . . . . . . . . . . . . . . . . . . . . . 823.10. Casos de uso Crear STPA y Graficar STPA. . . . . . . . . . . . . . . . . . . . 833.11. Fragmento - Diagrama de secuencia caso de uso Crear STPA. . . . . . . . . . . 843.12. Fragmento - Diagrama de secuencia caso de uso Graficar STPA. . . . . . . . . 853.13. Casos de uso Verificar propiedad y Mostrar contraejemplo . . . . . . . . . . . 863.14. Fragmento - Diagrama de secuencia caso de uso Verificar propiedad. . . . . . . 873.15. Fragmento - Diagrama de secuencia caso de uso Mostrar contraejemplo. . . . . 883.16. Arquitectura prescriptiva con los componentes adicionales. . . . . . . . . . . . 903.17. Modelo estructural para el Generador STPA. . . . . . . . . . . . . . . . . . . . 923.18. Ejemplo de representación de la ejecución de un componente en el STPA . . . 933.19. Modelo estructural para el Visor de chequeo del modelo . . . . . . . . . . . . 943.20. Ejemplo de un grafo generado para un STPA a través del graficador . . . . . 953.21. Modelo estructural para el Verificador de propiedad . . . . . . . . . . . . . . . 963.22. Prototipo de Interfaz Gráfica de Usuario. . . . . . . . . . . . . . . . . . . . . . 973.23. Fragmento Documento LaTeX con reglas de observación OSO . . . . . . . . . 983.24. Visualización de la configuración arquitectural y el STPA en la extensión . . . 993.25. Verificación de una propiedad temporal. El modelo satisface la propiedad . . . 1003.26. Verificación de una propiedad temporal. El modelo no satisface la propiedad . 1023.27. Ejemplo del lenguaje DOT y su representación gráfica . . . . . . . . . . . . . 1033.28. Representación de un STPA en lenguaje DOT . . . . . . . . . . . . . . . . . . 1043.29. Representación gráfica de un STPA posterior a la transformación del lenguaje DOT 1053.30. Ejemplo de un programa y una propiedad escritos en Promela . . . . . . . . . 1063.31. Representación en Promela de un STPA. Parte 1 de 4 . . . . . . . . . . . . . . 1083.32. Representación en Promela de un STPA. Parte 2 de 4 . . . . . . . . . . . . . . 1093.33. Representación en Promela de un STPA. Parte 3 de 4 . . . . . . . . . . . . . . 1103.34. Representación en Promela de un STPA. Parte 4 de 4 . . . . . . . . . . . . . . 111

A.1. Pantalla inicial PintArq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117A.2. Representación gráfica de la Arquitectura y el STPA en el aplicativo . . . . . 117A.3. Verificación de la propiedad con resultado satisfactorio . . . . . . . . . . . . . 119A.4. Verificación de la propiedad con resultado no satisfactorio . . . . . . . . . . . 120

Algoritmos

2.1. Algoritmo sat(f) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.2. Algoritmo satEX(f) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.3. Algoritmo satAF (f) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.4. Algoritmo satEU(f1 , f2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.5. Algoritmo alterno para el operador EG . . . . . . . . . . . . . . . . . . . . . . 44

8

RESUMEN

El presente trabajo de investigación establece un mecanismo para incorporar lógica linealtemporal a una configuración arquitectural especificada a través del cálculo ρarq. Este proceso serealiza interpretando los componentes y la definición del sistema (estructura y comportamiento)de una configuración arquitectural y la generación de un procedimiento para construir unSistema de Transición de Proposiciones Atómicas (STPA) sobre el cual se realiza la verificaciónde propiedades temporales. La visualización de este proceso se realiza a través de una extensiónde la aplicación PintArq.

9

Caṕıtulo 1

DESCRIPCIÓN YPLANTEAMIENTO DELPROBLEMA

1.1. Introducción

La construcción y evolución de los sistemas de software tiene grandes retos en la actualidad.El tamaño de estos retos es proporcional con la cantidad de información que se produce yconsume diariamente. Dicha información puede estar distribuida geográficamente, puede serconsultada de forma concurrente y las operaciones sobre esta información pueden ser simples ocomplejas de acuerdo al dominio en el que se desarrolla. Para hacer frente a los problemas queesto conlleva, se deben diseñar y construir grandes sistemas de información, que no solo brindenla información correcta sino también de forma oportuna, eficiente y segura, entre otros muchosatributos de calidad. Hay desaf́ıos que exigen este tipo de sistemas en los que su desarrollo yoperación tienen gran complejidad, no solo por la cantidad de elementos, sino por las relacionese interacción que existe entre ellos.

Durante un tiempo, la Ingenieŕıa de Software no contó con herramientas matemáticas quele permitieran desarrollarse con más seguridad y alcance a pesar de los grandes desarrollosteóricos y tecnológicos, no solo por su reciente aparición sino también porque dichas herra-mientas fueron consideradas muy complejas de aprender y como ejercicios teóricos. A ráız deesto, y en la búsqueda de un desarrollo mucho más riguroso y fuerte en términos matemáticos,se ha investigado sobre herramientas que contribuyan a su desarrollo formal. Siguiendo estaĺınea, dentro del tema de arquitecturas de software se busca definir herramientas matemáticasque permitan chequear las propiedades y aspectos de calidad deben satisfacer; se busca de-finir métodos formales que permitan evaluar los modelos de manera precisa y confiable. Lospropósitos de los métodos formales en la Ingenieŕıa de Software son entre otros, sistematizar

10

1.2. FORMULACIÓN DEL PROBLEMA 11

todas las fases del proceso y hacer mas riguroso su desarrollo[1].

Como antecedentes importantes, cabe destacar el desarrollo de métodos para especificarprocesos y sus interacciones como el cálculo λ para procesos secuenciales, el cálculo π paraprocesos concurrentes y más recientemente, el cálculo ρ para paradigmas orientados a objetos[2]. El cálculo ρ ha proporcionado un excelente fundamento para modelar soluciones recientes,debido a la gran extensión del paradigma orientado a objetos y el uso del Lenguaje de ModeladoUnificado (UML). Con base en éstos, se han desarrollado varias herramientas que se podŕıandenominar mixtas, debido a que UML no es un lenguaje formal estricto. El cálculo ρarq espropuesto para especificar aspectos estructurales y dinámicos de las arquitecturas de softwarebasadas en componentes; aśı como también una herramienta para evaluar las propiedadesdeseables de arquitecturas como la corrección [3, 4].

Adicionalmente, dentro de los métodos formales que han entrado a ser parte de la Inge-nieŕıa de Software se encuentran las lógicas temporales, que se utilizan para describir sistemasconcurrentes y reactivos. Es utilizada para especificar propiedades y verificar qué modelos desoftware las satisfacen[5]. Su utilización usualmente se incorpora en la ejecución de programasconcurrentes y tienen una sintaxis y semántica espećıficas [6].

En el contexto de sistemas reactivos y concurrentes se encuentran las arquitecturas desoftware basadas en componentes y el chequeo de modelos conformes a este estilo arquitectónicoes una necesidad evidente en la actualidad.

Es por estas razones que se busca contribuir en la aplicación de técnicas formales al desa-rrollo de software basado en componentes con el objeto de que desde el punto de vista formalpueda ser más confiable.

1.2. Formulación del problema

El cálculo ρarq es una notación formal para especificar arquitecturas de software basadasen componentes desde el punto de vista estructural y dinámico [3]. Su definición se estructuraen las álgebras de procesos, las cuales permiten modelar sistemas de software concurrentes,que proveen el mecanismo para describir interacciones, comunicación y sincronización de suselementos a alto nivel. Una de sus principales caracteŕısticas es que permite realizar razona-miento formal sobre su estructura y comportamiento. Adicionalmente, la posibilidad de utilizarUML como Lenguaje de Descripción Arquitectural que permitiŕıa no solo la formalidad de laespecificación sino también la posibilidad de ser usado no solo en el ámbito académico sino enel ambiente industrial.

Actualmente con el cálculo ρarq no es posible especificar propiedades temporales, relaciona-das con el orden lógico de ejecución de una arquitectura; es decir, determinar en un momentodado si una arquitectura llega a cierto estado deseado que depende de la ejecución correcta y

12 CAPÍTULO 1. DESCRIPCIÓN Y PLANTEAMIENTO DEL PROYECTO

en cierto orden de sus componentes. Seŕıa útil establecer los mecanismos que permitieran espe-cificar y validar estas propiedades. En este sentido, se propone integrarlo con la Lógica LinealTemporal para determinar y especificar un mecanismo mediante el cual se pueda modelar laejecución de una arquitectura de software especificada en cálculo ρarq con esta lógica modal.

El problema planteado en el presente trabajo es el siguiente ¿Qué caracteŕısticas debecontener un mecanismo que permita especificar y verificar propiedades temporales para modelosde arquitecturas de software basadas en componentes modelados a través del cálculo ρarq?

1.3. Objetivos

1.3.1. General

Establecer el mecanismo para incorporar Lógica Lineal Temporal sobre arquitecturas desoftware basadas en componentes modeladas a través del cálculo ρarq.

1.3.2. Espećıficos

Establecer la sintaxis y semántica de los operadores temporales.

Determinar los pasos para especificar una propiedad temporal para arquitecturas desoftware basada en componentes especificadas a través del cálculo.

Aplicar y validar la propiedad de vivacidad en un modelo arquitectónico basado en com-ponentes especificado a través del cálculo.

Implementar el mecanismo de integración de análisis de propiedades usando Lógica LinealTemporal a la herramienta PintArq.

1.4. Justificación

El desarrollo del presente proyecto pretende contribuir en el área de la Ingenieŕıa de Softwareen la medida que se pueda aplicar y extender el paradigma del desarrollo de software basado encomponentes, especialmente en el campo de la Arquitectura de Software. De igual forma aportaren la utilización de métodos formales sobre los productos de software, para que esto puedaayudar a mejorar la calidad de los mismos, aśı como reducir riesgos inherentes al desarrollo desoftware en donde ciertos aspectos son todav́ıa subjetivos y algunos de los métodos formalesutilizados no han tenido la expansión suficiente.

1.5. METODOLOGÍA UTILIZADA 13

Desde el punto de vista académico, se propende por la investigación de temas que contribu-yan al desarrollo de una Ingenieŕıa de Software mucho mas estable y con bases formales muchomas fuertes.

1.5. Metodoloǵıa utilizada

Como primera parte del desarrollo del proyecto se investigaron los procedimientos me-diante los cuales se especifican las propiedades temporales en otros sistemas concurrentes,posteriormente se estableció la sintaxis y semántica de los elementos que fueron utilizados pa-ra especificar los estados y propiedades para un modelo arquitectónico basado en componentesen el cálculo ρarq. Con los elementos propuestos se procedió a definir la propiedad que seŕıaverificada. El proceso se documentó en cada etapa, paso por paso para permitir que sea repro-ducido posteriormente para verificar una nueva propiedad. La metodoloǵıa se presenta en laFigura 1.1. Se desarrolló un mecanismo que incorporó la Lógica Lineal Temporal para especi-ficar propiedades temporales a modelos de arquitecturas de software basadas en componentesespecificadas a través del cálculo ρarq y se integró a la herramienta PintArq.

14 CAPÍTULO 1. DESCRIPCIÓN Y PLANTEAMIENTO DEL PROYECTO

Figura 1.1: Actividades relevantes para el desarrollo del proyecto

Caṕıtulo 2

MARCO REFERENCIAL Y ESTADODEL ARTE

2.1. Modelos y métodos formales en la Ingenieŕıa de

Software

El término “método formal” es ampliamente usado sin existir una definición única. Usual-mente es utilizado para hacer referencia a la utilización de un lenguaje de especificación formalpero no se describe el alcance que éste tiene. En lineas generales entre más abstracto sea ellenguaje en el que se describa un sistema, este lenguaje se denomina formal. En muchas oca-siones no existe un único lenguaje para describir un sistema y se pueden utilizar lenguajes endiferentes grados de formalidad para describir diferentes partes del sistema; sin embargo, unlenguaje con fundamentación matemática es considerado un lenguaje completamente formal[7]. Algunos de los enfoques desarrollados alrededor de estos lenguajes son:

Álgebras de procesos : Son métodos utilizados para modelar concurrencia y comunicaciónentre procesos. Unos de los métodos mas conocidos son CSP (Communication Sequential Pro-cesses) de Hoare[8] y CCS (Calculus of Communicating Systems) de Milner [9].

Técnicas algebraicas: Son métodos basados en el álgebra, como por ejemplo el uso deEspecificación Algebraica para Tipos Abstractos de Datos en donde el comportamiento de lasoperaciones sobre los Tipos Abstractos de Datos se expresan a través de ecuaciones.

15

16 CAPÍTULO 2. MARCO REFERENCIAL Y ESTADO DEL ARTE

2.1.1. Chequeo de modelos de software

El chequeo de modelos es una técnica de verificación formal para la evaluación de propie-dades formales de sistemas de información y comunicación. El chequeo de modelos requiere unmodelo del sistema que se va a analizar, una propiedad deseada y un método para verificarsistemáticamente si el modelo satisface o no la propiedad (por ejemplo, si es libre de inter-bloqueos, invariabilidad o propiedades de solicitud-respuesta). El chequeo de modelos es unatécnica automatizada para verificar la ausencia de errores y considerada como una técnica dedepuración efectiva e inteligente. Sus fundamentos formales se encuentran en la lógica propo-sicional, teoŕıa de autómatas, lenguajes formales, estructuras de datos y algoritmos de grafos.[10, 5]

2.1.2. Verificación de sistemas

La verificación de sistemas es utilizada para establecer que el diseño o producto a consi-deración posee ciertas propiedades. Las propiedades a ser verificadas pueden ser elementalescomo que un sistema nunca debe caer en un estado de interbloqueo, esto puede obtenerse dela especificación del sistema, la cual establece lo que el sistema tiene o no tiene que hacer, locual es la base para la actividad de la verificación. De esta forma, si el sistema no cumple conuna propiedad que ha sido especificada se ha encontrado un defecto, asimismo si un sistemacumple con todas las propiedades es considerado correcto. [10, 11]

En la actualidad, las técnicas para realizar verificación a sistemas de información y comu-nicaciones se realizan de una forma más confiable pero no de forma completa. Para realizarla verificación del software usualmente se utilizan dos técnicas que pueden combinarse paraobtener mejores resultados, una corresponde a la revisión por pares y la otra consiste en laspruebas de software. En la primera el código es analizado antes de su compilación y ejecuciónpor una persona diferente a quien lo codificó pero conoce el objetivo del software; sin embargo,y a pesar de los grandes esfuerzos, sus resultados obtienen en promedio el 60% de los errores [5,pág. 4]. Por otro lado, las pruebas de software se realizan a través de la ejecución del software,en donde se compara la salida del software frente al valor esperado de la especificación. Laspruebas de software consumen entre el 30 y 50% de los costos de un proyecto y sin embargo nodan confiabilidad de que el software no tenga errores [5, pág. 4]. Asimismo, la importancia deencontrar errores en las etapas iniciales del ciclo de desarrollo de software es imperativa puesel costo de corregirlos es considerablemente menor, la Figura 2.1 ilustra este comportamiento.

La verificación formal significa la creación de un modelo matemático de un sistema, usandoun lenguaje para especificar las propiedades deseadas en una forma concisa y sin ambigüedad,y usando un método de prueba para verificar las propiedades que satisfacen el modelo. Cuandoel método de prueba es llevado a cabo por una máquina se denomina verificación automática.Dentro de las técnicas utilizadas para realizar esta verificación encontramos la demostraciónde teoremas y el chequeo de modelos. En el primero, se toma el sistema y las propiedades

2.1. MODELOS Y MÉTODOS FORMALES EN LA INGENIERÍA DE SOFTWARE 17

deseadas y se expresan como fórmulas a través de alguna lógica matemática, el sistema satisfacela propiedad si una prueba puede ser construida con ésta lógica. Sin embargo, a pesar de lapotencialidad de esta técnica, puede tomar demasiado tiempo para adquirir la experticia yestablecer todo el sistema de prueba [12, Pág. 11].

Figura 2.1: Ciclo de vida del software y costos asociados a los erroresFuente [5]

De otro lado, en el chequeo de modelos se construye un modelo finito de un sistema y esverificado contra un conjunto de propiedades deseadas, puede ser más limitado que la demos-tración de teoremas pero es mucho mas rápido y puede ser completamente automatizado. Enesencia un modelo es una máquina de estados finita, que puede ser representada en un lenguajede alto nivel que permita su especificación precisa. Sus propiedades pueden ser especificadas enalguna lógica temporal o en términos de un autómata. Desafortunadamente, el modelamientode sistemas complejos como máquinas de estado finito puede acarrear una gran desventajaconocida como la explosión de estados, en donde el número de estados en el modelo, crece con-siderablemente con respecto al número de componentes con los cuales se construye el modelo ypor lo tanto su manipulación puede llegar a ser ineficiente. Por lo tanto, el desaf́ıo principal esencontrar métodos y estructuras de datos que permitan manejar grandes espacios de estados.


2.2. Chequeo de modelos y arquitecturas de software

2.2.1. Chequeo de arquitecturas de software

Con el objetivo de encontrar errores en el software en las etapas iniciales del ciclo de vidadel software, y con el fin de que los costos de su reparación tiendan a disminuir, se establecenherramientas para realizar verificación de software en la etapa de diseño, espećıficamente en laespecificación de una arquitectura. Uno de los enfoques para realizar pruebas de software en laetapa de diseño es denominado Pruebas basadas en Arquitecturas de Software [13], en dondese utilizan la parte dinámica de la arquitectura para identificar esquemas útiles de interacciónentre los componentes de software y realizar una selección de clases de prueba que correspondana comportamientos relevantes de la arquitectura.

Este enfoque recae entonces en la utilización de métodos formales para la descripción dela arquitectura, entre ellos encontramos los Sistemas de Transición Rotulados que menciona-remos más adelante [10]. De manera general, un Sistema de Transición Rotulado provee unadescripción global y monoĺıtica del conjunto de todos los posibles comportamientos del sistema,aunque muchas veces este modelo genera demasiada información que no puede ser analizada,pues la cantidad de estados del sistema puede crecer considerablemente.

Muchos de los enfoques utilizados para describir y realizar pruebas de software basadas enarquitecturas hacen uso del Lenguaje de Modelado Unificado. Esto debido a la gran versatilidaddel lenguaje, a su amplia y extendida utilización en la industria; por lo tanto, muchos de losmecanismos analizados se soportan sobre esta base [5].

2.2.2. Arquitecturas de software y Lenguaje de Modelado Unificado(UML)

Para realizar el modelamiento de arquitecturas de software, es necesario establecer lenguajescon los cuales se pueda describir la parte estática y dinámica de una arquitectura. Con estepropósito se han creado varios Lenguajes de Descripción Arquitecturales para proveer estetipo de abstracciones para sistemas grandes y complejos; sin embargo, se han desarrolladobastantes tipos de lenguajes y no se ve muy claro un horizonte de convergencia. Para resolveresto, varias propuestas se han dado a la tarea de basarse en uno de los lenguajes mayormenteutilizados en la industria; es decir, el Lenguaje de Modelado Unificado (UML por sus siglas eninglés, www.uml.org) , al ser un lenguaje semiformal, debe ser utilizado con otras herramientasformales que le permitan desarrollar una semántica completa.

Existen en esencia tres enfoques que utilizan UML para realizar el modelamiento de Ar-quitecturas de Software: 1. El lenguaje en śı, 2. El lenguaje junto con restricciones a través demecanismos de extensión (como estereotipos) y 3. Extender el metamodelo UML para soportar

2.2. CHEQUEO DE MODELOS Y ARQUITECTURAS DE SOFTWARE 19

directamente los conceptos arquitecturales necesarios [14]; este esquema puede visualizarse enla Figura 2.2.

La primera opción presentada presenta como una de sus mayores ventajas la posibilidad demanipulación rápida y fácil de los modelos a través de las variadas herramientas existentes; sinembargo, no provee los mecanismos para representar caracteŕısticas y relaciones intŕınsecamen-te arquitecturales, dejando por fuera aspectos importantes de una arquitectura de software.

La segunda opción aprovecha uno de los conceptos fundamentales inherentes a UML queconsiste en la posibilidad de incorporar nuevas capacidades y conceptos sin cambiar el sentidode la semántica o sintaxis original del lenguaje. Esto se realiza utilizando Restricciones, Este-reotipos, Valores etiquetados y Perfiles. Una de las desventajas importantes es que no permitela definición clara de las fronteras del espacio de modelado.

La tercera opción, la cual consiste en aumentar el metamodelo, podŕıa incorporar todos losconceptos que el diseño de una arquitectura de software pueda necesitar prestando el soportesuficiente. A pesar de esto, no está considerada como una de las estrategias mas fuertes puessu estandarización para este propósito seŕıa bastante engorrosa abriendo la posibilidad de queno cumpla con la notación original y no llegue a ser compatible con el desarrollo actual dellenguaje y sus herramientas.

En algunos casos, como se presenta en el caso del cálculo ρarq [3], se utiliza el segundoenfoque complementándolo con herramientas formales que brinden una herramienta completapara el modelamiento y chequeo de las propiedades de una arquitectura.

Figura 2.2: Las cuatro capas de la Arquitectura de Metamodelamiento de UMLTomado de: [14]. Página 7


2.3. Lógicas Temporales

2.3.1. Modelado de sistemas y lógicas temporales

La corrección funcional es la propiedad de un sistema de cómputo que permite determinarsi éste hace aquello para lo cual ha sido desarrollado.

Para realizar chequeo de corrección funcional de un sistema, es necesario en primer lu-gar, establecer las propiedades que debeŕıa tener o aquellas consideradas importantes para elanálisis. Posteriormente se debe construir un modelo formal que lo represente y que capturelas propiedades que se desean verificar. De igual forma, se debe establecer un nivel adecuadode abstracción que permita identificar y modelar estas caracteŕısticas sin necesidad de incluirdetalles que no sean relevantes para el análisis. Por ejemplo, si se desea modelar un circuitodigital, puede que no sea necesario pensarlo en términos de voltajes y corrientes sino por el con-trario usar compuertas lógicas booleanas. Usualmente los sistemas pueden ser modelados comosistemas transformacionales o sistemas reactivos, pero los procesos concurrentes se modelan através de los sistemas reactivos [15].

Conceptualmente los sistemas de cómputo o programas se dividen en dos, los sistemastransformacionales, que son los mas comunes, cuyo objetivo principal es producir una salidacon su ejecución y finalmente terminar. De esta forma, estos sistemas pueden verse comofunciones que reciben parámetros, los transforman y ofrecen una salida, es decir, tienen unestado inicial y un estado final [12, Pág. 47]. Usualmente se describen a través de lógica deprimer orden. Por otro lado, los sistemas reactivos, no presentan necesariamente un resultadofinal sino que por el contrario, mantienen una interacción constante con su entorno y algunos deellos podŕıan no terminar su ejecución. No se definen en términos de estados iniciales y finales,sino en términos de la evolución del sistema a través de diferentes estados, usualmente se usaun modelo basado en lógica lineal temporal para describir y especificar su comportamiento[16].

Una de las caracteŕısticas que se desea capturar de un sistema reactivo, es el estado actual,que es una “instantánea” de los valores de las variables en un momento determinado. De igualforma, cuando se ejecuta una acción que hace evolucionar el sistema de un estado a otro, sepuede definir una transición, esta transición se puede describir como el par de estados quedescriben al sistema antes y después de la acción. Otra caracteŕıstica que se define es unacomputación, que corresponde a una secuencia infinita de estados que describe la evolución delsistema de un estado a otro a través de varias transiciones.

Asimismo, pueden identificarse los sistemas concurrentes, los cuales se conforman de unconjunto de componentes que pueden ejecutarse juntos y tienen algún mecanismo para co-municarse. Estos mecanismos pueden variar de un sistema a otro pero se pueden considerarprincipalmente dos mecanismos de ejecución:

Aśıncrono o intercalado: Dos o mas componentes ejecutan un paso en un momento de-

2.3. LÓGICAS TEMPORALES 21

terminado.

Sincrónico: Solamente un componente ejecuta un paso en un momento determinado.

De igual forma, existen dos mecanismos de comunicación [15, Pág. 17]:

Estado compartido: los componentes se comunican intercambiando valores a través devariables compartidas.

Intercambio de mensajes: los componentes usan una cola de mensajes o algún tipo deprotocolo de sincronización (handshaking).

2.3.2. Generalidades de las lógicas temporales

Las lógicas temporales se extienden de la lógica proposicional y de predicados a travésde modos que hacen referencia al comportamiento infinito de un sistema reactivo, es unaespecialización de las lógicas modales que incluyen términos y caracteŕısticas para identificary especificar propiedades relacionadas con estados de un sistema en diferentes instantes detiempo. Es un método formal utilizado para describir secuencias de transiciones entre estadosde un sistema reactivo en el sentido de la descripción del comportamiento deseado u operacióndel sistema, mientras evita mencionar detalles de implementación. El calificativo de temporal,no hace alusión a “tiempo real” sino a una abstracción del tiempo que permite la especificaciónde un relativo orden de eventos, se puede decir que se trata de una interpretación discreta deltiempo. Una transición corresponde al avance de una unidad de tiempo simple, el sistema esobservable en los puntos 0,1,2,..., etc. La aplicación de este modelo a sistemas computacionalescomplejos es propuesto inicialmente por Pnueli en los años 70 del siglo veinte[17].

2.3.3. Clasificación de las lógicas temporales

Las lógicas lineales temporales pueden dividirse en: proposicionales o de primer orden, glo-bales o composicionales, lineales o ramificadas, basadas en puntos en el tiempo o en intervalosy en tiempo pasado o futuro. A continuación se describen de manera general cada uno de estosaspectos [18].

2.3.3.1. Proposicional / De primer orden

Proposicional hace referencia a lógica clásica, la cual se construye a partir de proposicio-nes atómicas, las cuales expresan hechos subyacentes al estado del sistema, usa también los


conectores lógicos clásicos y adicionalmente los temporales. Sobre estos conceptos se construyela lógica de primer orden que incluye variables, constantes, funciones, predicados y cuanti-ficadores. Se pueden distinguir también variables locales que pueden tener diferentes valoresen diferentes estados o globales que mantienen su valor independiente del estado en el que seencuentren. Pueden imponerse también ciertas restricciones sintácticas sobre los operadorestemporales o los cuantificadores.

2.3.3.2. Global / Composicional

Usar una lógica global hace referencia cuando se puede razonar sobre un programa porcompleto, es decir, se puede ver el sistema como un único programa, también denominadocomo endógeno. Si por el contrario, los operadores plantean el análisis sobre distintas partes deun programa, de tal forma que este se puede descomponer y estudiar en partes independientespero posteriormente se puede sacar conclusiones del sistema completo, se dice que es una lógicacomposicional o exógena.

2.3.3.3. Lineal / Ramificada

Estas dos visiones consideran la naturaleza del tiempo. Por un lado, lineal quiere decir queen un momento espećıfico solo existe un único momento futuro posible y por lo tanto describeneventos a lo largo de un solo camino y, por otro lado, en la ramificada se entiende que enun momento dado, el tiempo puede dividirse en varios caminos alternativos que representandiferentes posibles futuros.

2.3.3.4. Basadas en puntos en el tiempo / Intervalos

Esta caracteŕıstica hace referencia a que pueden analizarse en un momento espećıfico deltiempo o por el contrario se pueden determinar espacios de tiempo sobre los cuales se puederazonar un programa.

2.3.3.5. Discreta / Continua

El concepto de discreto hace referencia al momento presente que corresponde al estadoactual del sistema y el momento futuro al estado sucesor inmediato. De otro lado, el términocontinuo, describe una estructura de tiempo real en donde algunos sistemas tienen requeri-mientos más estrictos de rendimiento.


2.3.3.6. De tiempo pasado / De tiempo futuro

Esta caracteŕıstica está definida por los operadores que la lógica, en su mayoŕıa se utilizanen tiempo futuro en donde se establece un punto inicial y se evalúa el comportamiento haciaadelante y la inclusión de operadores en tiempo pasado no agregan ningún valor adicional; sinembargo, cualquiera de los dos tipos de operadores puede ser utilizado.

La mayoŕıa de las investigaciones se centran en la utilización de lógicas, en tiempo futu-ro, discretas, basadas en puntos y combinan la lógica de primer orden que incluye la lógicaproposicional.

2.3.4. Lógica de Árboles de Cómputo Cerradura (CTL*)

Lógica de Arboles de Cómputo Cerradura (del inglés Computation Tree Logic * - CTL*)es una lógica temporal que describe el comportamiento de un sistema a través de árboles decomputaciones (o cómputo). La estructura subyacente es un árbol ramificado infinito, el cualdetermina, que un momento espećıfico (o nodo dentro del árbol) puede tener varios momentossucesores y un cada uno debe tener al menos un predecesor. Para representar estos sistemasse utilizan estructuras Kripke [15, Pág. 27]. Una estructura Kripke se puede definir como unmodelo formal que representa el comportamiento de un sistema de cómputo a través de unconjunto de estados, un conjunto de transiciones entre los estados y una función que etiqueta acada estado con un conjunto de propiedades que son ciertas en ese estado. Las rutas o caminosen una estructura modelan una computación o camino de estados. El modelo tiene la suficientesimpleza para no agregar complejidades innecesarias y la suficiente expresividad para capturaraspectos relacionados con el tiempo, con lo cual, permite razonar sobre los sistemas reactivos.

2.3.4.1. Sintaxis y Semántica

Una fórmula es un representación formal a través de proposiciones y śımbolos definidos porel lenguaje. Las fórmulas en está lógica pueden clasificarse en dos:

Formulas de estado: aquellas que son ciertas en un estado o momento espećıfico y abrenvarios caminos posibles.

Formulas de ruta: aquellas que son ciertas a lo largo de una única ruta o camino de estados.

Los elementos sintácticos básicos de una formula son:

AP : conjunto de proposiciones atómicas. (a ∈ AP )


∧,∨,¬: conectores booleanos. (AND, OR, NOT)

©,⋃: modalidades temporales básicas. (NEXT, UNTIL)

∃, ∀: cuantificadores.

Las proposiciones atómicas son afirmaciones sobre valores de variables de control o valoresde variables de programa. Los conectores lógicos son usados de la misma forma que en lalógica proposicional y pueden derivar conectores mas complejos a través de la definición deestos primeros, tales como la implicación o la doble implicación.

Una fórmula se representa con la letra ϕ y se define aśı:

ϕ ::= true | a | ϕ1 ∧ ϕ2 | ¬ϕ | ©ϕ | ϕ1⋃ϕ2

donde (a ∈ AP )

De otro lado, las modalidades temporales básicas se describen intuitivamente de la siguienteforma:

©: es un operador prefijo unario que requiere una fórmula como argumento, en donde©ϕes cierta si ϕ es cierta en el siguiente momento. Puede leerse como “siguiente” del inglés “next”,el śımbolo X también puede ser usado para representarlo (Xϕ).

⋃: es un operador infijo binario que requiere dos formulas como argumentos. ϕ1

⋃ϕ2 es

cierta en este momento si existe un paso en el futuro en el que ϕ2 sea cierta y ϕ1 sea cierta entodos los momentos desde el presente hasta que llegue éste último. Puede leerse como “hasta”del inglés “until”, el śımbolo U también puede ser usado para representarlo (ϕ1Uϕ2).

A partir de las modalidades temporales básicas pueden derivarse las siguientes modalidadesmas complejas:

♦ϕdef= true

⋃ϕ

♦: Es un operador prefijo unario que requiere una fórmula como argumento, en donde♦ϕ es cierta si existe un momento en el futuro en el que ϕ sea cierta. Puede leerse como“eventualmente”, “en el futuro” o “es posible que”, del inglés “eventually” y también se puedeusar el śımbolo F para representarlo (Fϕ).

�ϕdef= ¬♦¬ϕ

�: Es un operador prefijo unario que requiere una fórmula como argumento, en donde �ϕes cierta si ϕ es cierta en este y todos los momentos futuros. Puede leerse como “siempre”,


“globalmente” o “es necesario que” del inglés “globally” y también se puede usar el śımbolo Gpara representarlo (Gϕ).

Adicionalmente, existe el operador R denominado “hasta que libera” del inglés “release” yse considera como el dual del operador

⋃.

R: es un operador infijo binario que requiere dos formulas como argumentos. ϕ1Rϕ2escierta si ϕ2 es cierta en el presente y hasta que ϕ1 sea cierta junto con ϕ2. Si ϕ1no llega a serverdadera, quiere decir que ϕ2 será siempre verdadera y la fórmula también será cierta.

A través de la combinación de los operadores ♦ y �, “eventualmente” y “globalmente”respectivamente, se generan los siguiente operadores compuestos:

�♦ϕ: “infinitamente con frecuencia”, describe la existencia de un momento j en el cual enun momento i > j, la fórmula ϕ es cierta y esto ocurre periódicamente en el futuro.

♦�ϕ: “eventualmente y para siempre”, desde un momento j la fórmula ϕ será cierta desdeese momento en adelante.

Los cuantificadores son utilizados en estados determinados para especificar que las rutasque inician en ese estado, tienen una formula que es cierta.

∃: se lee “para algunas” o “existe al menos una” ruta. Puede usarse también el śımbolo E.

∀: se lee “para todas” las rutas. Puede usarse también el śımbolo A.

La sintaxis de las fórmulas está determinada por las siguientes reglas:

Si p ∈ AP entonces p es una fórmula de estado.

Si f y g son fórmulas de estado, entonces ¬f , f ∧ g, f ∨ g son fórmulas de estado.

Si f es una fórmula de ruta, entonces E f y Af son fórmulas de ruta.

Si f es una fórmula de estado, entonces f es una fórmula de ruta.

Si f y g son fórmulas de ruta, entonces ¬f , f ∧ g, f ∨ g, X f , F f , Gf , f⋃g y f R g

son fórmulas de ruta.

2.3.4.2. Estructuras Kripke

Una estructura Kripke se define de la siguiente manera:


Se tiene AP como el conjunto de proposiciones atómicas. Una estructura Kripke M sobreAP es una tupla de 4 elementos

M = (S, S0, R, L)

donde:

S: es el conjunto de estados finitos

S0 : es el conjunto de estados iniciales. S0 ⊆ S

R: es una relación de transiciones entre estados que debe ser total. Esto quiere decir quepara cada estado s ∈ S hay un estado s′ ∈ S, tal que R(s, s′) y R ⊆ S × S.

L: es una función que etiqueta cada estado con el conjunto de proposiciones atómicasverdaderas en ese estado S → 2AP .

Una ruta en M desde un estado s, es una secuencia infinita de estados π = s0s1s2... tal quepara cada i ≥ 0 existe un (si, si+1) ∈ R.

Se usa la notación πi para denotar que el camino π inicia en el estado si.

Si f es una fórmula de estado, la notaciónM, s |= f significa que f es cierta en el estados en la estructura M .

Si f es una fórmula de ruta, la notación M,π |= f es cierta a lo largo del camino π enla estructura M .

Asumiendo que f1, f2 son fórmulas de estado y, g1, g2 son fórmulas de ruta:

• M, s |= p ⇐⇒ p ∈ L(s)

• M, s |= ¬f1 ⇐⇒ M, s 2 f1

• M, s |= f1 ∨ f2 ⇐⇒ M, s |= f1 o M, s |= f2

• M, s |= f1 ∧ f2 ⇐⇒ M, s |= f1 y M, s |= f2

• M, s |= E g1 ⇐⇒ hay una ruta π desde s tal que M,π |= g1

• M, s |= Ag1 ⇐⇒ para cada ruta π desde s tal que M,π |= g1

• M,π |= f1 ⇐⇒ s es el primer estado de π y M,π |= f1

• M,π |= ¬g1 ⇐⇒ M,π 2 g1

• M,π |= g1 ∨ g2 ⇐⇒ M,π |= g1o M,π |= g2

• M,π |= g1 ∧ g2 ⇐⇒ M,π |= g1y M,π |= g2


• M,π |= X g1 ⇐⇒ M,π1 |= g1

• M,π |= F g1 ⇐⇒ existe un k ≥ 0 tal que M,πk |= g1

• M,π |= Gg1 ⇐⇒ para todos los i ≥ 0 tal que M,πi |= g1

• M,π |= g1⋃

g2 ⇐⇒ existe un k ≥ 0 tal que M,πk |= g2 y para todos los

0 ≤ j ≤ k tal queM,πj |= g2

• M,π |= g1Rg2 ⇐⇒ para todos los j ≥ 0, si para cada i < j , M,πi2 g1

entonces M,πj |= g2

La Lógica de Árboles de Cómputo * (CTL*) se divide a su vez en Lógica de Árboles deCómputo simple (Computation Tree Logic - CTL) y Lógica Lineal Temporal (Lineal TemporalLogic - LTL), a continuación se describen las caracteŕısticas de cada una.

Las relaciones entre las diferentes lógicas se pueden ver clasificadas en el esquema de laFigura 2.3.

Figura 2.3: Relación entre las lógicas temporalesTomado de [19]

2.3.5. Lógica de Árboles de Cómputo Simple (CTL)

Está lógica es un subconjunto de CTL* con la restricción de que sus fórmulas deben utili-zar siempre los cuantificadores. Utiliza únicamente fórmulas de ruta. Existen diez operadoresbásicos:

AX y EX

AF y EF

AG y EG


A⋃

y E⋃

AR y ER

Cada uno de estos operadores puede ser expresado en términos de tres operadores solamente,EX , EG y E

⋃:

AX f = ¬EX(¬f)

EF f = E(True⋃f)

AGf = ¬EF (¬f)

AF f = ¬EG(¬f)

A(f⋃g) ≡ ¬E[¬g

⋃(¬f ∧ ¬g)] ∧ ¬EG¬g

A(f R g) ≡ ¬E(¬f⋃

¬g)]

E(f R g) ≡ ¬A(¬f⋃

¬g)]

Una representación gráfica de algunos de los operadores puede verse en la Figura 2.4. Cadauna de los árboles tiene como nodo inicial el estado s0 .

De igual forma cabe recordar que los operadores lógicos implicación (→) y doble implicación(↔) se pueden representar a través de composición de los otros operadores más básicos y losoperadores (and) y (or) pueden expresarse en sus opuestos:

p ∧ q = ¬(¬p ∨ ¬q)

p ∨ q = ¬(¬p ∧ ¬q)

p→ q = ¬p ∨ q

p↔ q = (p→ q) ∧ (q → p)


Figura 2.4: Representación gráfica de algunos operadores CTLTomado de [15]

2.3.6. Lógica Lineal Temporal (LTL)

La Lógica Lineal Temporal se construye a partir de la sintaxis y semántica descritas enCTL* con la restricción que no utiliza cuantificadores, por lo tanto, sus fórmulas son únicamentede ruta, su representación no genera una estructura de árbol sino un único camino. Desde estepunto de vista, un momento en el tiempo tiene un único sucesor y un único predecesor.

Esta lógica, es utilizada para modelar sistemas sincrónicos en los cuales cada componenteactúa en un paso a la vez. Esto quiere decir que una transición corresponde con el avance deuna unidad de tiempo, haciendo referencia a la naturaleza discreta del tiempo; el momentopresente se define como el estado actual y el momento siguiente como al estado sucesor. Sepuede decir que el sistema es observable en los momentos 0,1,2...

Una representación gráfica de algunos estos operadores de la Lógica Lineal Temporal sepueden apreciar en la Figura 2.5.


Figura 2.5: Representación gráfica de los operadores LTLAdaptada de [15] y [5]

2.3.6.1. Ejemplo: Para ilustrar como se construyen las fórmulas para una Lógica LinealTemporal, se presenta un ejemplo que muestra como se representan algunas propie-dades para un problema de exclusión mutua entre procesos:

Se consideran dos procesos concurrentes P1 y P2. Cada proceso Pi puede estar en una detres fases:

1. En su sección no cŕıtica.

2. En espera de entrar a su sección cŕıtica.

3. En su sección cŕıtica.


Primero se definen las proposiciones atómicas que representan las fases de estar o no en lasección cŕıtica y estar en estado de espera: criti (proceso i que ejecuta su sección cŕıtica) seutilizará para las fases 1 y 3 y waiti(proceso i que espera para la ejecución de su sección cŕıtica)para la fase 2.

Posteriormente se definen cuales son las condiciones que se deben cumplir para que se cum-pla que existe exclusión mutua entre los procesos. Para esto se definen las siguientes propiedadesy se expresan a través de fórmulas:

Certeza: Describe que ninguno de los dos procesos entrará en su sección cŕıtica.

�[¬crit1 ∨ ¬crit2] = �[¬(crit1 ∧ crit2)]

La fórmula asegura que “siempre”, al menos uno de sus procesos no está en la seccióncŕıtica, o lo que es lo mismo, que “siempre” ambos procesos no estarán en su sección cŕıtica.

Vivacidad: Describe que cada uno de los procesos debe entrar en algún momento y confrecuencia en su sección cŕıtica.

�♦(crit1) ∧ �♦(crit2)

En este caso la fórmula, determina que es obligatorio que cada uno de los procesos ejecutesu sección cŕıtica siempre y con cierta regularidad.

Libre de inanición: Describe que si un proceso entra en su fase de espera en algún momentoposterior debe entrar a su sección cŕıtica.

(�♦wait1 → �♦crit1) ∧ (�♦wait2 → �♦crit2)

También se podŕıa usar una variable adicional (variable del programa) que represente unsemáforo para describir la exclusión mutua:

�((y = 0) → crit1 ∨ crit2)

La fórmula indicaŕıa que si el semáforo y tiene el valor 0, uno de los procesos entrará en susección cŕıtica.


2.4. Chequeo de modelos y lógicas temporales

2.4.1. Generalidades

Es una técnica de verificación de sistemas concurrentes, en el que teniendo un modelodel sistema y la especificación de una propiedad determinada, se desea evaluar exhaustiva yautomáticamente si el modelo cumple con la propiedad bajo verificación. El proceso del chequeode modelos se compone de los siguientes elementos[20]:

Modelo: Corresponde al modelo del sistema, es una abstracción de la estructura y com-portamiento de éste.

Especificación: Corresponde a la caracterización formal de la propiedad que se ha de-terminado que debe satisfacer el sistema.

Método de verificación: Corresponde a un algoritmo que define los pasos mediante loscuales se va a establecer si la especificación de la propiedad es satisfecha por el modelodel sistema.

Estos elementos deben estar representados a través de un lenguaje o método formal que permitacumplir el objetivo.

El problema del chequeo de modelos puede describirse formalmente de la siguiente manera[15]:

Se tienen dos elementos, una estructura KripkeM = (S, R, L) (en algunos casos los estadosiniciales no son de particular interés y pueden ser omitidos de la definición) que representa elsistema concurrente de estados finitos y una fórmula en lógica temporal f que especifica ciertapropiedad. A partir de estos, se establece que debe encontrarse el conjunto de estados en Sque satisface f , esto se representa de la siguiente forma:

{s ∈ S |M, s |= f}

Los primeros algoritmos para resolver problemas de chequeo de modelos usaban represen-tación expĺıcita del modelo a través de un grafo dirigido en donde los nodos corresponden alos estados en S, los arcos están dados por la relación R y las etiquetas asociadas a los nodoscorresponden a la función L. Esta representación es útil para entender el problema pero puedellegar a ser compleja de manejar para modelos grandes. Por lo tanto, se han establecido otrosmecanismos para llevar a cabo la verificación.

2.4. CHEQUEO DE MODELOS Y LÓGICAS TEMPORALES 33

2.4.2. Chequeo de modelos CTL

Para realizar el chequeo de modelos de un sistema representado a través de la lógica CTL,se parte de una estructura Kriple M = (S,R, L) y se desea determinar los estados en S quesatisfacen la fórmula CTL f .

El algoritmo para realizar el chequeo tiene en cuenta lo siguiente:

Se etiqueta cada estado s con el conjunto label(s) de subfórmulas de f que son ciertas ens. Las subfórmulas de f son todas aquellas en las que se puede descomponer, por ejemplo: sif = ¬(EF (p ∧EG¬q)) el conjunto completo de las subfórmulas de f son {p, q,¬q, EG¬q, p ∧EG¬q, EF (p∧EG¬q),¬(EF (p∧EG¬q))}, que como puede notarse incluye a f misma; cuandoel conjunto contiene todas las subfórmulas de f , esto se conoce como el conjunto potencia.

Inicialmente label(s) y L(s) son iguales (contienen las subfórmulas atómicas que son ciertasen el estado) y el proceso ocurre a través de varias etapas, en las que se van agregando lassubfórmulas al conjunto label(s).

La etapa i = 0, consiste en etiquetar cada estado con las subfórmulas atómicas que sonciertas en cada estado. En cada i-ésima etapa, se procesan los operadores de la subfórmula dela etapa i− 1. Si esta subfórmula es verdadera en el estado se agrega al conjunto label(s) delestado.

Cuando el algoritmo termina, se tiene que M, s |= f si y solo sif ∈ label(s).

Previamente se mostró que cualquier formula CTL puede expresarse en términos de ¬, ∨y los tres operadores temporales EX, EU y EG, por lo tanto, para cada etapa intermedia soloes necesario manejar seis casos dependiendo si la subfórmula es atómica o tiene una de lassiguientes formas: ¬f1, f1 ∨ f2,EXf1,E[f1Uf2] o EGf1.

2.4.2.1. Algoritmos para Chequeo de modelos

Como se puede ver, el modelo está representado por el grafo dirigido o según la estructu-ra Kripke M , la especificación está representada por la fórmula CTL f y el algoritmo paradeterminar si el modelo satisface la especificación se puede describir de la siguiente forma, lacual es adaptada de[20]. Se tiene S, el conjunto de estados del modelo M y f la propiedad quedebe ser satisfecha, entonces sat(f) es la función que determina el conjunto de estados de Mque satisfacen f . Este algoritmo etiqueta cada estado iterativamente hasta encontrar todoslos estados que satisfacen la fórmula. Se cuenta también con L(s) que corresponde al conjuntode subfórmulas que son verdaderas en el estado s (esto es llamado también la etiqueta de s).Los pasos del algoritmo se pueden ver en el Algoritmo 2.1:

El algoritmo 2.1 describe todos los posibles casos que pueden presentarse en un sistema.


Algoritmo 2.1 Algoritmo sat(f)

Función sat(f)

Inicio Según sea 1. g es true: retornar S

2. g es false: retornar Ø

3. g es atómica: retornar {s ∈ S | g ∈ L(s)}

4. g es ¬f1 : retornar S − sat(f1)

5. g es f1 ∧ f2 : retornar sat(f1) ∩ sat(f2)

6. g es f1 ∨ f2 : retornar sat(f1) ∪ sat(f2)

7. g es f1 → f2 : retornar sat(¬f1 ∨ f2)

8. g es AX f1 : retornar sat(¬EX ¬f1)

9. g es EX f1 : retornar satEX(f1)

10. g es A(f1 U f2) : retornar sat(¬(E [f2 U (¬f1 ∧ ¬f2)] ∨ EG¬f2))

11. g es E(f1 U f2) : retornar satEU(f1 , f2)

12. g es EF f1 : retornar sat(E (trueU f1))

13. g es EGf1 : retornar sat(¬AF ¬f1))

14. g es AF f1 : retornar satAF (f1)

15. g es AGf1 : retornar sat(¬EF ¬f1)

Fin Segun sea

FinFuente: Adaptado de [20]

Debido que algunas de las verificaciones son más complejas, se establecen tres funcionesadicionales que se presentan para los operadores EX, EU y AF que corresponden a satEX(f1),satEU(f1 , f2) y satAF (f1) respectivamente, cada uno de estos algoritmos se describe más ade-lante y se muestran ejemplos para cada uno de ellos.

Para el proceso de etiquetado, se establece que si la fórmula f es cierta en el estado s, dichafórmula es agregada al conjunto de etiquetas representado por label(s). Para algunos casos sedefine un esquema particular para realizar el etiquetado:

Para el caso 3, g es atómica, se etiqueta el estado con cada una de las fórmulas que seanciertas en dicho estado.

Para el caso 5, g es f1 ∧ f2, se etiqueta el estado con f1 ∧ f2, si f1 y f2 ya están dentrodel conjunto, de igual forma con el caso 6 el estado es etiquetado con f1 ∨ f2 si cualquiera delos dos estados se encuentra en el conjunto.

Para el caso 9, g es EX f1 algoritmo 2.2, se etiquetan los estados con la fórmula si uno desus sucesores esta etiquetado con f1; de igual forma para el caso 8, AX f1, se etiquetan losestados con la fórmula, si todos los sucesores están etiquetados con f1.


Algoritmo 2.2 Algoritmo satEX(f)

Función satEX(f)

local var X , Y

Inicio X := sat(f)

Y := {s ∈ S | s → s′ para algún s′ ∈ X}

retornar Y


Algoritmo 2.3 Algoritmo satAF (f)

Función satAF (f)

local var X,Y

Inicio X := S

Y := sat(f)

Repetir hasta X = Y

X := Y

Y := Y ∪ {s | para todos los s′ con s→ s′ }

Fin Repetir hasta

retornar Y


Para el caso 14, g es AF f1 algoritmo 2.3, el proceso de etiquetado consiste en dos grandespasos:

1. Si cualquier estado s está etiquetado con f1, entonces etiquetar el estado también conAF f1.

2. Repetir: etiquetar cada estado s con AF f1si todos sus sucesores están etiquetados conAF f1hasta que ya no haya ningún cambio.

Este procedimiento proviene de la siguiente regla:

AF f1 ≡ f1 ∨ AX AFf1

Para el caso 11, E(f1 U f2) algoritmo 2.4, el proceso de etiquetado también es compuesto


Algoritmo 2.4 Algoritmo satEU(f1 , f2)

Función satEU(f1 , f2)

local var W, X, Y

Inicio W := sat(f1)

X := S

Y := sat(f2)

Repetir hasta X = Y

X := Y

Y := Y ∪ [W ∩ {s | existe s′ tal que s→ s′ y s′ ∈ Y }]

Fin Repetir hasta

retornar Y

Fin

Fuente: Adaptado de [20]

de la siguiente forma:

1. Si cualquier estado s está etiquetado con f2 entonces etiquetarlo también con E(f1 U f2).

2. Repetir: etiquetar cada estado s con E(f1 U f2) si el estado esta etiquetado con f1 y almenos uno de sus sucesores está etiquetado con E(f1 U f2). Realizar esto hasta que nohayan más cambios.

Este procedimiento proviene de la siguiente regla:

E(f1 U f2) ≡ f2 ∨ (f1 ∧ EX E(f1 U f2))

Los algoritmos para etiquetar los demás pueden establecerse a partir de los anteriormenteexplicados, pues se componen de elementos ya mencionados.

Después de realizar el etiquetado para todas las subfórmulas de g, incluyendo g misma,tenemos como salida los estados en los cuales g se satisface.

La complejidad del algoritmo es lineal y esta dada por:

O(|f |.(|S|+ |R|))

en donde:


|f |: es el número de conectores en la fórmula.

|S|: es el número de estados del modelo

|R|: es el número de transiciones del modelo

2.4.2.1.1. Ejecución aplicada de los algoritmos Un ejemplo del procedimiento para lafórmula EX f se puede ver en las Figura 2.6 y 2.7. En el estado inicial se establece arbitraria-mente que la fórmula f es verdadera en s2 y s3. Por definición, los conjuntos label(s) y L(s)son iguales. Posteriormente a la ejecución del procedimiento de etiquetado, el conjunto label(s)contiene las fórmulas que son verdaderas en cada estado. Para este ejemplo, los estados quesatisfacen la fórmula EX f (que corresponde a la que deseamos evaluar), son s0 y s1, es decir,que en estos estados f es cierta en alguno de sus sucesores. También puede verse el desarrollodel árbol que se despliega a partir del estado inicial del sistema en la Figura 2.8.

Figura 2.6: Ejemplo función de etiquetado EX f . Estado inicial del sistema. Parte 1 de 2Fuente: El autor.


Figura 2.7: Ejemplo función de etiquetado EX f . Estado final del sistema. Parte 2 de 2Fuente: El autor.

Figura 2.8: Algoritmo EX f. Desarrollo del árbol del sistema.Fuente: El autor.


El ejemplo del procedimiento para la fórmula AF f , se representa a través de la Figura2.9. Nuevamente, en el estado inicial se establecen arbitrariamente los estados en los que lafórmula f es verdadera: s4 y s5. En el estado intermedio, según el algoritmo, se etiquetan conAF f , los estados que tienen f , es decir, s4 y s5 inicialmente. Por último, se evalúa en cadauno de los predecesores de estos estados si todos sus sucesores contienen la etiqueta AF f sies cierto, se etiquetan con ésta; los nuevos estados que cumplen con la fórmula son s1 y s2.Después de esta iteración, no hay mas predecesores en donde todos sus sucesores contengan laetiqueta AF f , pues en el estado s0 no es posible afirmar esto ya que s3 no está etiquetado yel algoritmo termina. Finalmente, los estados que satisfacen la fórmula AF f desde el estados0, son s1,s2,s4,s5, lo cual quiere decir que para todos esos estados en todos los caminos que sedesprenden desde s0, eventualmente f es verdadera.


Figura 2.9: Ejemplo para la función de etiquetado AF fSup-Izq: El estado inicial del sistema. Sup-Der: Estado intermedio. Inf: Estado final del

sistema.Fuente: El autor.


El ejemplo del procedimiento para la fórmula E(f1 U f2) se puede ver representado en laFiguras 2.10, 2.11, 2.12 y 2.13. Inicialmente se ha establecido que la fórmula f1 es verdaderaen s1, s2, s3, s4, s5 y s6. De igual forma, la fórmula f2 es verdadera en s7. De acuerdo con elalgoritmo, si un estado es etiquetado con f2, debe etiquetarse con E(f1 U f2), por lo tanto elestado s7 es etiquetado con esta fórmula como puede verse en el paso intermedio 1. Posterior-mente, se inicia un ciclo en el que se indica que si un estado está etiquetado con f1 y al menosuno de sus sucesores con E(f1 U f2), dicho estado debe etiquetarse con la misma fórmula; en elpaso intermedio 2 puede verse este proceso, en donde, los estados s4 y s5 son etiquetados, esteproceso continúa hasta que ya no se cumpla la condición. En este ejemplo, el proceso terminacuando se llega a los estados s1y s2 que son los últimos estados que pueden ser etiquetados.Finalmente, los estados que satisfacen la fórmula E(f1 U f2) son s1, s2, s4, s5 y s7. La fórmulaindica que f1 será cierta a través de las rutas que inician en s1 y s2 y hasta que f2 sea ciertaen s7.

Figura 2.10: Ejemplo función de etiquetado E(f1 U f2). Estado inicial del sistema. Parte 1 de4

Fuente: El autor.


Figura 2.11: Ejemplo función de etiquetado E(f1 U f2). Estado intermedio 1. Parte 2 de 4Fuente: El autor.

Figura 2.12: Ejemplo función de etiquetado E(f1 U f2). Estado intermedio 2. Parte 3 de 4Fuente: El autor.


Figura 2.13: Ejemplo función de etiquetado E(f1 U f2). Estado final del sistema. Parte 4 de 4Fuente: El autor.

2.4.2.2. Algoritmos alternos para Chequeo de modelos

Los algoritmos alternos para el chequeo de modelos hacen referencia a opciones alterna-tivas para resolver la cuestión de satisfactibilidad de la propiedad en el modelo para algunosoperadores, tales como EG y AG.

Operador EG - Algoritmo alterno 1

En el algoritmo 2.5 aparece un nuevo concepto relacionado con los grafos: ComponenteFuertemente Conectado no trivial (non-trivial Strongly Connected Component (SCC)), estoscomponentes son subgrafos en los cuales desde cualquiera de los nodos que lo componen sepuede llegar a cualquiera de los demás nodos que hacen parte del subgrafo (esencialmentegeneran un ciclo entre ellos mismos), un grafo C es no trivial si y solo si tiene más de un nodoo contiene un nodo con una transición a si mismo. Se tiene que S ′, es el conjunto de estadosque están etiquetados con f , se seleccionan los nodos que hacen parte de los SCC del modeloy se almacenan en T . El procedimiento de etiquetado consiste en marcar los nodos de los SCCya que están conectados, y por lo tanto existirá al menos un camino en el que se podrá llegara otro de los estados con la fórmula EGf . Después, se irá recorriendo desde cada uno de losnodos de S ′ revisando si tiene como sucesores a alguno de los estados que pertenecen a T (losnodos conectados). Al final se tendrán etiquetados los estados que satisfacen la fórmula EGf .


Algoritmo 2.5 Algoritmo alterno para el operador EG

Procedimiento checkEG(f)

Inicio S ′ := {s | f ∈ label(s)}

SCC := {C |C es un SCC de S ′}

T :=⋃

C∈SCC{s | s ∈ C}

Para todo s ∈ T hacer label(s) ∪ {EGf}

Mientras T 6= Ø hacer

seleccionar s ∈ T

T := T − {s}

Para todo t ∈ S ′ y R(t, s) hacer

Si EGf /∈ label(t) entonces

label(t) := label(t) ∪ {EGf}

T := T ∪ {t}

Fin Si

Fin Para

Fin Mientras

Fin Para

Fin

Fuente: Adaptado de [15]

Operador EG - Algoritmo alterno 2

Otra alternativa para el operador EG , es la siguiente:

1. Etiquetar todos los estados con EGf en donde f sea verdadera.

2. Repetir: En los nodos restantes, borrar la etiqueta si ninguno de los sucesores de unestado está etiquetado con EGf . Terminar cuando no haya ningún cambio.

Puede verse gráficamente la ejecución de un ejemplo en la Figura 2.14. En el estado inicialdel sistema, los estados en los que f es verdadera son s1, s2, s4, s6, s7 y s8. En el siguientepaso, a los nodos que no tienen al menos un sucesor etiquetado con la fórmula se les remuevela etiqueta, en este caso s2.


Figura 2.14: Representación gráfica del algoritmo para EG alternativoIzq: El estado inicial del sistema. Der: Estado final del sistema.

Fuente: El autor.

Operador AG - Algoritmo alterno 1

Otra alternativa para el operador AG , es la siguiente:

1. Etiquetar todos los estados con AGf en donde f sea verdadera.

2. Repetir: En los nodos restantes, borrar la etiqueta si todos los sucesores de un estado noestán etiquetados con AGf . Terminar cuando no haya ningún cambio.

Puede verse que para el operador AG la fórmula f debe ser verdadera en todos los estados delmodelo.


2.5. Cálculo ρarq

El cálculoρarq , un lenguaje de descripción arquitectural con notación formal para especificarlos aspectos estructurales y dinámicos de arquitecturas de software basadas en componentes[4]. Posee una semántica operacional que le permite representar el cambio de estado de unaarquitectura pasando de una configuración estática a una nueva configuración a través de lasreglas definidas por el lenguaje. De igual forma, posee una notación gráfica basada en UML 2.xa través de una extensión estereotipada que puede ser traducida al cálculo. Basado en el cálculoρ, es especificado a través de tres elementos: expresiones, congruencia estructural y reducción.En la actualidad se ha desarrollado una aplicación que permite visualizar la ejecución de unaarquitectura especificada a través del cálculo. La aplicación desarrollada recibe un conjunto defórmulas especificadas en el cálculo y se encarga de la visualización de cada una de las etapasde la ejecución [21].

2.5.1. Sintaxis

El lenguaje se compone de un conjunto de śımbolos y expresiones basadas en las entidadesdel cálculo ρ original y adaptando algunas al contexto de las arquitecturas de software [22].

Figura 2.15: Sintaxis del cálculo ρarqFuente: [4]

2.5. CÁLCULO ρARQ 47

Śımbolos y Expresiones

El lenguaje define como śımbolos a las referencias, estas pueden ser variables o nombres.Los nombres (a, b, c) son elementos que pueden ser cargados dentro de las variables (x, y, z). Elśımbolo x̄ define una secuencia de finita de variables (x1, x2, ..., xn). Las variables ligadas deE se representan por BV(E) y las variables libres FV(E). Las primeras representan aquellasvariables que son solo válidas en el contexto de E y no pueden ser reemplazadas (o que ya hansido reemplazadas en su contexto y no pueden ser de nuevo reemplazadas), por el contrario laslibres pueden ser sustituidas desde una invocación externa.

Las expresiones son elementos definidos por el cálculo que representan componentes y con-figuraciones arquitecturales que a su vez pueden ser consideradas componentes en si mismas.Se describen algunas de ellas:

Nulo(⊤): es un componente nulo que no ejecuta ninguna acción.

Composición(E ∧ F ): expresa composición concurrente entre dos componentes.

Parte interna de E (Eint): representa la parte interna de E, permite establecer la dife-rencia entre E el cual puede conectarse con otros componentes a través de sus interfacesy Eint que ayuda a determinar si su parte interna fue ejecutada con éxito.

Combinador de selección condicionada (if (C1)...(Cn) elseG): es la generalización de unaexpresión condicional en donde cada elemento (Ck) tiene una condición de guarda re-presentada por Ck = ∃ ¯x(φk thenEk), si la cláusula se cumple, se libera el cuerpo deexpresión definida por Ek, si por el contrario ninguna de las cláusulas se cumple, se libe-ra G, que puede ser usado en el cálculo para el manejo de fallas. Esta expresión introduceno-determinismo si más de una cláusula es cierta y se libera más de una expresión.

Abstracción (x :: ȳ/E): se lee, el componente E con entrada ȳ a lo largo de x. Suinterpretación establece que el componente recibe una variable x, que reemplaza a ȳ enel componente. Esto es posible solo si x, es libre en E.

Aplicación (xȳ/E): se lee, enviar ȳ a lo largo de x y continuar con la ejecución de E. Seasocia con el env́ıo de un mensaje a lo largo de un canal asociado a un componente, enel caso que el componente sea nulo (x̄y/⊤), se puede abreviar con (x̄y).

Reacción interna (τ/E): Se lee como la reacción interna de E cuyo estado observable noes de interés y permite reducir el número de estados a analizar en la ejecución de unaconfiguración.

Declaración (∃wE): se lee, se introduce una referencia w con alcance E.

Replicación de abstracción (x : ȳ/E): se lee, se genera una nueva abstracción listapara reaccionar y se queda listo para replicar. Esta expresión permite representar laejemplificación de los componentes. Puede ser expresada también de la siguiente formax : ȳ/E ≡ x :: ȳ/E ∧ x : ȳ/E.


Ejecución exitosa / fallida del componente (E⊤, E⊥): representan respectivamente laejecución exitosa o fallida del componente E.

Observación de ejecución (OSO(E) do F elseG): representa la observación sobre la eje-cución del componente E, si su ejecución es exitosa se libera F de lo contrario se liberaG.

2.5.2. Especificación formal de una arquitectura

La especificación formal de cada componente se realiza a través de la descripción de cadauna de sus interfaces. Se especificará el componente E ilustrado en la Figura 2.16. Esta repre-sentación se basa en dos fuentes, por un lado, la notación visual del lenguaje de configuraciónDarwin al cálculo π y por otro, la notación gráfica de componentes propuesta por UML 2.0. Uncomponente se representa por un rectángulo con el estereotipo y el nombredel componente en el centro. Si se desea puede agregarse el ı́cono de componente en la margensuperior derecha. Los puertos públicos, son representados a través de cuadrados que sobresa-len del componente; estos tienen un nombre que usualmente contiene una referencia al tipo deservicio que ofrece y un sub́ındice al componente al que pertenece (p, representa que provee, yr, que requiere).

Las interfaces, se representan con una ĺınea continua saliendo de un puerto, las que son desalida tienen un circulo cerrado no relleno, se denomina de provisión de servicio. Este serviciotiene un nombre identificado con la letra (s) y un sub́ındice asociado al componente al quepertenece, su especificación formal en el cálculo es:

PROVE(p, s)def= pE : x/xsE ≡ pE :: x/xsE ∧ pE : x/xsE

Las interfaces de entrada terminan en un semićırculo abierto y se denominan lugar requi-sitor de servicio o de entrada, en donde la pareja (lE , iE) se interpreta como una ubicaciónlE que espera recibir un valor que pueda reemplazar el parámetro iE en el componente. Suespecificación formal es:

REQE(r, l, i)def= ∃lE [(rE :: y/ylE ∧ lE :: iE/E

(int))]

De esta forma, un componente es representado por las interfaces públicas de salida y entradaque lo configuran actuando de forma concurrente, su especificación es:

Edef= PROVE(p, s) ∧ REQE(r, l, i)


Figura 2.16: Representación gráfica de un componenteFuente: [4]

De esta forma, se especifica y representa gráficamente un componente y una configuraciónarquitectural.

2.5.3. Semántica Operacional y Ejecución de una arquitectura

El cálculo permite modelar el comportamiento de arquitecturas basadas en componentes através de su semántica operacional. Por un lado, se utiliza la congruencia estructural (≡) delcálculo ρ, que corresponde a la menor congruencia (menor relación lógica de equivalencia) delos axiomas del cálculo y reglas de reducción que representan esta semántica. Por otro lado,utiliza los sistemas de transición rotulados para representar la evolución en la ejecución de laarquitectura a través de semántica operacional definida para este fin.

Con respecto a los axiomas que se muestran en la Figura 2.17, se encuentran: Replicaciónde observación, que permite hacer vistas sucesivas de la ejecución de un componente y, Éxi-to/Fracaso Observacional que permite realizar reemplazos en las entradas de un componentey ejecutarlo. Una ejecución exitosa o no-exitosa puede representarse con (E⊤, E⊥) respectiva-mente.

Figura 2.17: Axiomas del cálculo ρarqFuente: [4]


Del conjunto de reglas de reducción, que se muestran en la Figura 2.18, se encuentran:

Aρarq(aplicación), que ejecuta una combinación de forma concurrente de una abstrac-ción con una replicación que ejemplifica una aplicación. Esta regla modela llamadas deprocedimientos pasando parámetros dentro de un componente.

Cρarq(combinación de restricciones), permite combinar restricciones con el propósito deampliar o simplificar el conjunto de estas restricciones del repositorio.

Comb ρarq , dispara la ejecución de un Ek si la restricción de contexto es suficientementefuerte y permite deducir desde φ la guarda ψk del condicional respectivo. Esta regla per-mite escoger un componente Ek dentro de un grupo, siempre y cuando cumpla la guardadefinida. De otro lado, si la restricción de contexto arquitectural no es lo suficientementefuerte para deducir desde ésta alguna de las guardas de las cláusulas, se generaŕıa elcomportamiento alterno del componente F , que podŕıa corresponder al manejo de fallaso errores en el sistema.

Ejecτ , esta regla permite establecer la ejecución de éxito o fracaso observacional de uncomponente. Esto se realiza con el propósito de representar un componente como unacaja negra, en donde lo relevante es el comportamiento final de su ejecución y no elprocesamiento interno del mismo, que no es visible para un observador externo.

Estas reglas, permiten especificar formalmente el avance de la ejecución de una arquitectura.

Figura 2.18: Reglas de reducción del ρArqFuente: [4]

Una vez se realiza la especificación de los componentes de una arquitectura, puede esta-blecerse una interacción entre los mismos, esta interacción se realiza a través del ensamblajede las interfaces de entrada y de salida en donde puede ocurrir una ejecución, un ejemplo deeste ensamblaje puede observarse en la Figura 2.19 y cuya especificación en el cálculo es lasiguiente:


Edef= [(pE : x/xsE)] ∧ ∃lE [(rE :: y/ylE) ∧ (lE :: iE/E

(int))]

Fdef= (pF : z/zsF )

El ensamblaje se realiza a través de un conector, este conector se denomina C y estáidentificado por los componentes que ensambla, es decir:

CEFdef= rEpF

Figura 2.19: Notación gráfica del ensamble de componentesFuente: [4]

La ejecución concurrente de los componentes con el conector hace que se inicie la ejecuciónde la arquitectura y queda especificada de la siguiente forma:

S1 = E ∧ F ∧ CEF = {(pE : x/xsE)] ∧ ∃lE [(rE :: y/ylE) ∧ (lE :: iE/E(int))} ∧ {pF :

z/zsF } ∧ {rEpF}

Esta especificación junto con las reglas de transición y el repositorio de restricciones per-miten que la configuración de la arquitectura avance hacia una nueva configuración en dondesus componentes interactúan mostrando su evolución.

Este comportamiento viene especificado por:

S1Aρarq=⇒ (pE : x/xsE) ∧ [sF/iE ]E

(int))

En donde se indica que la ejecución que lleva el servicio sF a la ubicación lE que le requiere.


La representación gráfica de la ejecución es simbolizada por un token (punto negro en la Figura2.19).

2.5.4. Sistemas de Transición Rotulados Condicionados

Otro de los conceptos utilizados en el cálculo, son sistemas de transición rotulados, quese usan para representar la evolución comportamental del sistema especificado. Este conceptopermite verificar la propiedad de corrección entre una especificación de un conjunto de arqui-tecturas comunes de comportamiento (modelo de referencia) y una arquitectura de referenciaparticular. El cálculo permite la utilización de variables lógicas en las restricciones de las ar-quitecturas basadas en componentes, esto permite incorporar un modelo de computación porrestricciones que posee un repositorio (store) que son utilizadas para controlar el flujo de eje-cución de la arquitectura. Este esquema permite establecer un sistema de transición rotuladocondicionado con el fin de representar la evolución en el comportamiento de la arquitectura.Las reglas previamente definidas son las que determinan el momento en el que una nuevaconfiguración evoluciona hacia una siguiente configuración.

El sistema de transición rotulado (STR), establece un elemento básico denominado acción,el cual permite fluir de un estado a otro. Un STR sobre un conjunto de acciones Act, es unpar (Q, T ) se define de la siguiente forma[4]:

Conjunto de estados (Q)

Relación de Transición: relación ternaria T ⊆ (Q × Act×Q)

De igual forma, un STR Condicionado es aquel en el que una acción α ∈ Act, puede ser unarestricción o guarda booleano y acciones que no sean restricciones pueden estar condicionadasa estos mismo elementos.

Adicionalmente, el cálculo establece varias definiciones sobre la relación entre el cálculoρArq y los STR Condicionados con el fin de estructurar el modelo que representará la evoluciónen la configuración de la arquitectura a través de las reglas. Esta correspondencia se definea través de los estados en el sistema, en donde estos estados son expresiones arquitecturalesque se reducen de manera concurrente. De esta manera, cuando las expresiones se reducen,la arquitectura pasa de una configuración a otra a través de las acciones observables y noobservables. La regla Ejecτ permite modelar en los casos de éxito o fracaso observacional en laejecución de un componente. De igual forma, la expresión OSO (On Success Of) en composicióncon un componente que se ejecuta de forma exitosa se reduce a una expresión arquitectural Fo G que representan los caso de éxito o fracaso respectivamente; a través de este esquema, seespecifica formalmente el avance en la ejecución de la arquitectura.

Las reglas de transición del cálculo se definen en la Figura 2.20, estas reglas determinan lasacciones posibles en una configuración, representan el env́ıo o recepción de mensajes, activar


un conjunto de componentes de acuerdo a las restricciones, ejecución de los componentes yobservabilidad de la misma de acuerdo a la granularidad necesaria.

Figura 2.20: Reglas de transición del ρArqFuente: [4]

Adicionalmente, el cálculo ρArq, define también un modelo de congruencia estructural y bi-similaridad con el cual se puede realizar chequeo de corrección. Este modelo permite establecersi una arquitectura de referencia es “correcta” con respecto a su especificación de alto niveldefinida por un modelo de referencia.


2.6. Lenguajes de Descripción Arquitectural y Lógicas

Temporales

Con el propósito de desarrollar grandes sistemas de software que necesita la sociedad ac-tual, se han establecido también diversos modelos, técnicas, metodoloǵıas y tecnoloǵıas, queprocuren desarrollar software complejo y de calidad. Dentro de estas posibilidades se encuentrael desarrollo de software basado en componentes y por supuesto la concepción de arquitecturasde software basadas en este paradigma[23]. Igualmente, se han desarrollado metodoloǵıas paraarquitecturas basadas en componentes que buscan la reutilización de software previamenteconstruido o que pueda servir para este propósito y por lo tanto, reducir el tiempo y/o costosde implementación de un nuevo sistema, estas metodoloǵıas buscan incorporar de la forma maselegante, software previamente desarrollado con el que está por construirse[24]. Es por estasrazones que se busca contribuir en el desarrollo de software basado en componentes que puedaser confiable desde el punto de vista formal incluyendo modelos y mecanismos que permitanestablecer y evaluar propiedades que mejoren la calidad de software que se desarrolla.

Las arquitecturas de software emergieron con el propósito de establecer un mecanismo paraentender y caracterizar los sistemas de software a gran escala; de esta forma, se establećıa undiseño de alto nivel del sistema que pod́ıa ser utilizado como base para la implementación yposterior mantenimiento del sistema, aśı como un elemento para la reutilización del softwarea grandes niveles[25]. En este sentido, se han desarrollado diferentes técnicas para describiruna arquitectura de software en diferentes niveles

INTEGRACIÓN DE LÓGICA LINEAL TEMPORAL A MODELOS...

Documents

Transcript of INTEGRACIÓN DE LÓGICA LINEAL TEMPORAL A MODELOS...

Linear Temporal Logic - Rich Model Toolkit

Programació Lineal

Álgebra Lineal

Chapter 5 Linear Temporal Logic (LTL) - CS CSU …france/CS614/Slides/Ch5-Summary.pdfRehab Ashari Sahar Habib 1 CONTENT Temporal Logic & Linear Temporal Logic (LTL) Syntax Semantics

Torsion No Lineal en Barras Circulares

Modelos atómicos

Reinforcement Learning Lecture Temporal Difference Learning

Temporal Network Optimization Subject to Connectivity ...

Modelos de Costo Total Lineal, Cuadratico y Cubico

Modelo de Regresión Lineal - Supuestos del modelo...hallagos y conclusiones obtenidas, dependen de lo razonable de las simpliﬁcaciones asociadas con los modelos usados, es decir,

MODELOS DE CRECIMIENTO ENDGENO

ALGEBRA LINEAL. Escuela Polit ecnica Superior Examen ...

Trabajo Modelos

Modelos Log–Lineales - UBA · 2008. 7. 13. · Cuando interesa estudi-ar algunas variables como independientes y otras como dependientes es m´as adecuado un modelo lineal generalizado,

Thermal Expansivity and Temporal Stability Measurements … · Thermal Expansivity and Temporal Stability ... Gohman also developed a thermal cycling schedule to assure Zerodur ...

Modelos de Física - farlei.net

ESCUELA POLITÉCNICA NACIONAL ÁLGEBRA LINEAL HOJA …

ALGEBRA LINEAL MATRICES VECTORES

Combinación Lineal y Capsula

Propositional Projection Temporal Logic, B¨ Automata and ω ...