Integración de lógica lineal temporal a modelos de arquitecturas de software basadas en componentes especificadas a través del cálculo rho arq

Texto completo

(1)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.

(2) INTEGRACIÓN DE LÓGICA LINEAL TEMPORAL SOBRE MODELOS DE ARQUITECTURAS DE SOFTWARE BASADAS EN COMPONENTES ESPECIFICADAS A TRAVÉS DEL CÁLCULO ρarq. OSCAR JAVIER PUENTES PUENTES. UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA MAESTRÍA EN CIENCIAS DE LA INFORMACIÓN Y LAS COMUNICACIONES BOGOTÁ D.C. 2017.

(3) 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. 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 CALDAS FACULTAD DE INGENIERÍA MAESTRÍA EN CIENCIAS DE LA INFORMACIÓN Y LAS COMUNICACIONES BOGOTÁ D. C. 2017.

(4) CONTENIDO 1. DESCRIPCIÓN Y PLANTEAMIENTO 1.1. Introducción . . . . . . . . . . . . . . . . 1.2. Formulación del problema . . . . . . . . 1.3. Objetivos . . . . . . . . . . . . . . . . . 1.3.1. General . . . . . . . . . . . . . . 1.3.2. Especı́ficos . . . . . . . . . . . . . 1.4. Justificación . . . . . . . . . . . . . . . . 1.5. Metodologı́a utilizada . . . . . . . . . . .. DEL PROYECTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . . . . . . .. 2. MARCO REFERENCIAL Y ESTADO DEL ARTE 2.1. Modelos y métodos formales en la Ingenierı́a de Software . . . . . . 2.1.1. Chequeo de modelos de software . . . . . . . . . . . . . . . 2.1.2. Verificación de sistemas . . . . . . . . . . . . . . . . . . . . 2.2. Chequeo de modelos y arquitecturas de software . . . . . . . . . . . 2.2.1. Chequeo de arquitecturas de software . . . . . . . . . . . . 2.2.2. Arquitecturas de software y Lenguaje de Modelado Unificado 2.3. Lógicas Temporales . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1. Modelado de sistemas y lógicas temporales . . . . . . . . . . 2.3.2. Generalidades de las lógicas temporales . . . . . . . . . . . . 2.3.3. Clasificación de las lógicas temporales . . . . . . . . . . . . . 2.3.4. Lógica de Árboles de Cómputo Cerradura (CTL*) . . . . . . 2.3.5. Lógica de Árboles de Cómputo Simple (CTL) . . . . . . . . 2.3.6. Lógica Lineal Temporal (LTL) . . . . . . . . . . . . . . . . . 2.4. Chequeo de modelos y lógicas temporales . . . . . . . . . . . . . . . 2.4.1. Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2. Chequeo de modelos CTL . . . . . . . . . . . . . . . . . . . 2.5. Cálculo ρarq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1. Sintaxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.2. Especificación formal de una arquitectura . . . . . . . . . . . 2.5.3. Semántica Operacional y Ejecución de una arquitectura . . . 2.5.4. Sistemas de Transición Rotulados Condicionados . . . . . . 2.6. Lenguajes de Descripción Arquitectural y Lógicas Temporales . . . 2.7. Tecnologı́as para el chequeo de modelos . . . . . . . . . . . . . . . . 2.7.1. SPIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . (UML) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. 10 10 11 12 12 12 12 13. . . . . . . . . . . . . . . . . . . . . . . . .. 15 15 16 16 18 18 18 20 20 21 21 23 27 29 32 32 33 46 46 48 49 52 54 58 58.

(5) 5. CONTENIDO 3. DESARROLLO DE LA SOLUCIÓN 3.1. Sintaxis y semántica de los operadores temporales . . . 3.1.1. Reglas de equivalencia lógica . . . . . . . . . . . 3.1.2. Definiciones . . . . . . . . . . . . . . . . . . . . 3.1.3. Reglas de verificación . . . . . . . . . . . . . . . 3.2. Especificación de una propiedad temporal . . . . . . . 3.3. Verificación de una propiedad temporal . . . . . . . . . 3.4. Implementación del mecanismo en PintArq . . . . . . . 3.4.1. Modelo funcional de PintArq extendido . . . . . 3.4.2. Arquitectura prescriptiva extendida . . . . . . . 3.4.3. Breve descripción de interfaz gráfica de usuario 3.4.4. Aspecto tecnológico . . . . . . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. 63 63 64 64 65 67 76 81 81 89 96 103. 4. CONCLUSIONES Y TRABAJO FUTURO 114 4.1. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 A. Manual de usuario A.1. Requerimientos . . . . . . . . . . . . . . . . . . A.2. Operación . . . . . . . . . . . . . . . . . . . . . A.2.1. Cargar una especificación de arquitectura A.2.2. Verificar una propiedad temporal . . . . B. Manual de instalación B.1. Requerimientos . . B.2. Instalación . . . . . B.2.1. Wildfly . . . B.2.2. Graphviz . . B.2.3. Spin . . . . B.2.4. PintArq . . BIBLIOGRAFIA. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . .. 116 116 116 117 118. . . . . . .. 121 121 121 121 122 122 122 123.

(6) 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 . . . . . . . . . . . . 17 2.2. Las cuatro capas de la Arquitectura de Metamodelamiento de UML . . . . . . 19 2.3. Relación entre las lógicas temporales . . . . . . . . . . . . . . . . . . . . . . . 27 2.4. Representación gráfica de algunos operadores CTL . . . . . . . . . . . . . . . . 29 2.5. Representación gráfica de los operadores LTL . . . . . . . . . . . . . . . . . . 30 2.6. Ejemplo función de etiquetado EX f . Estado inicial del sistema. Parte 1 de 2 . 37 2.7. Ejemplo función de etiquetado EX f . Estado final del sistema. Parte 2 de 2 . . 38 2.8. Algoritmo EX f. Desarrollo del árbol del sistema. . . . . . . . . . . . . . . . . 38 2.9. Ejemplo para la función de etiquetado AF f . . . . . . . . . . . . . . . . . . . 40 2.10. Ejemplo función de etiquetado E(f1 U f2 ). Estado inicial del sistema. Parte 1 de 4 41 2.11. Ejemplo función de etiquetado E(f1 U f2 ). Estado intermedio 1. Parte 2 de 4 . 42 2.12. Ejemplo función de etiquetado E(f1 U f2 ). Estado intermedio 2. Parte 3 de 4 . 42 2.13. Ejemplo función de etiquetado E(f1 U f2 ). Estado final del sistema. Parte 4 de 4 43 2.14. Representación gráfica del algoritmo para EG alternativo . . . . . . . . . . . 45 2.15. Sintaxis del cálculo ρarq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.16. Representación gráfica de un componente . . . . . . . . . . . . . . . . . . . . . 49 2.17. Axiomas del cálculo ρarq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 2.18. Reglas de reducción del ρArq . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 2.19. Notación gráfica del ensamble de componentes . . . . . . . . . . . . . . . . . 51 2.20. Reglas de transición del ρArq . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 2.21. Representación gráfica de un Sistema Productor-Consumidor en SAM . . . . . 55 2.22. Representación gráfica de un Sistema Productor-Consumidor en CBabel . . . . 56 2.23. Descripción textual de una arquitectura en Æmilia . . . . . . . . . . . . . . . 57 2.24. Transformación de diagrama de estados CHARMY a especificación en Promela 57 2.25. Estructura de una simulación y verificación en SPIN . . . . . . . . . . . . . . 59 2.26. Ejemplo de la especificación de un modelo a través del lenguaje Promela . . . 60 2.27. Construcción gramática de una fórmula en LLT en Promela para SPIN. . . . . 62 3.1. 3.2. 3.3. 3.4. 3.5.. Ensamble complejo de componentes . . . . . . . . . . . . . . . . . . . . Vista parcial del STR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . STPA del Ensamble complejo de componentes . . . . . . . . . . . . . . . Ejemplo de representación de la ejecución de un componente en el STPA Ejemplo de representación del STPA completo . . . . . . . . . . . . . . 6. . . . . .. . . . . .. . . . . .. 68 69 71 72 73.

(7) 7. INDICE DE FIGURAS. 3.6. Configuración con componentes alternativos para proveer servicios . . . . . . 74 3.7. STPA para una Configuración con componentes alternativos . . . . . . . . . . 75 3.8. Relación entre T races(T S) y W ords(ϕ) . . . . . . . . . . . . . . . . . . . . . 78 3.9. Modelo funcional de PintArq extendido. . . . . . . . . . . . . . . . . . . . . . 82 3.10. Casos de uso Crear STPA y Graficar STPA. . . . . . . . . . . . . . . . . . . . 83 3.11. Fragmento - Diagrama de secuencia caso de uso Crear STPA. . . . . . . . . . . 84 3.12. Fragmento - Diagrama de secuencia caso de uso Graficar STPA. . . . . . . . . 85 3.13. Casos de uso Verificar propiedad y Mostrar contraejemplo . . . . . . . . . . . 86 3.14. Fragmento - Diagrama de secuencia caso de uso Verificar propiedad. . . . . . . 87 3.15. Fragmento - Diagrama de secuencia caso de uso Mostrar contraejemplo. . . . . 88 3.16. Arquitectura prescriptiva con los componentes adicionales. . . . . . . . . . . . 90 3.17. Modelo estructural para el Generador STPA. . . . . . . . . . . . . . . . . . . . 92 3.18. Ejemplo de representación de la ejecución de un componente en el STPA . . . 93 3.19. Modelo estructural para el Visor de chequeo del modelo . . . . . . . . . . . . 94 3.20. Ejemplo de un grafo generado para un STPA a través del graficador . . . . . 95 3.21. Modelo estructural para el Verificador de propiedad . . . . . . . . . . . . . . . 96 3.22. Prototipo de Interfaz Gráfica de Usuario. . . . . . . . . . . . . . . . . . . . . . 97 3.23. Fragmento Documento LaTeX con reglas de observación OSO . . . . . . . . . 98 3.24. Visualización de la configuración arquitectural y el STPA en la extensión . . . 99 3.25. Verificación de una propiedad temporal. El modelo satisface la propiedad . . . 100 3.26. Verificación de una propiedad temporal. El modelo no satisface la propiedad . 102 3.27. Ejemplo del lenguaje DOT y su representación gráfica . . . . . . . . . . . . . 103 3.28. Representación de un STPA en lenguaje DOT . . . . . . . . . . . . . . . . . . 104 3.29. Representación gráfica de un STPA posterior a la transformación del lenguaje DOT 105 3.30. Ejemplo de un programa y una propiedad escritos en Promela . . . . . . . . . 106 3.31. Representación en Promela de un STPA. Parte 1 de 4 . . . . . . . . . . . . . . 108 3.32. Representación en Promela de un STPA. Parte 2 de 4 . . . . . . . . . . . . . . 109 3.33. Representación en Promela de un STPA. Parte 3 de 4 . . . . . . . . . . . . . . 110 3.34. Representación en Promela de un STPA. Parte 4 de 4 . . . . . . . . . . . . . . 111 A.1. A.2. A.3. A.4.. Pantalla inicial PintArq . . . . . . . . . . . . . . . . . . . . . . . . . . . . Representación gráfica de la Arquitectura y el STPA en el aplicativo . . . Verificación de la propiedad con resultado satisfactorio . . . . . . . . . . . Verificación de la propiedad con resultado no satisfactorio . . . . . . . . .. . . . .. . . . .. 117 117 119 120.

(8) Algoritmos 2.1. 2.2. 2.3. 2.4. 2.5.. Algoritmo Algoritmo Algoritmo Algoritmo Algoritmo. sat(f ) . . . . satEX (f ) . . . satAF (f ) . . . satEU (f1 , f2 ) alterno para el. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . operador EG. 8. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 34 35 35 36 44.

(9) RESUMEN. El presente trabajo de investigación establece un mecanismo para incorporar lógica lineal temporal a una configuración arquitectural especificada a través del cálculo ρarq . Este proceso se realiza 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 un Sistema de Transición de Proposiciones Atómicas (STPA) sobre el cual se realiza la verificación de propiedades temporales. La visualización de este proceso se realiza a través de una extensión de la aplicación PintArq.. 9.

(10) Capı́tulo 1 DESCRIPCIÓN Y PLANTEAMIENTO DEL PROBLEMA 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 y consume diariamente. Dicha información puede estar distribuida geográficamente, puede ser consultada de forma concurrente y las operaciones sobre esta información pueden ser simples o complejas de acuerdo al dominio en el que se desarrolla. Para hacer frente a los problemas que esto conlleva, se deben diseñar y construir grandes sistemas de información, que no solo brinden la información correcta sino también de forma oportuna, eficiente y segura, entre otros muchos atributos de calidad. Hay desafı́os que exigen este tipo de sistemas en los que su desarrollo y operación tienen gran complejidad, no solo por la cantidad de elementos, sino por las relaciones e interacción que existe entre ellos. Durante un tiempo, la Ingenierı́a de Software no contó con herramientas matemáticas que le permitieran desarrollarse con más seguridad y alcance a pesar de los grandes desarrollos teóricos y tecnológicos, no solo por su reciente aparición sino también porque dichas herramientas fueron consideradas muy complejas de aprender y como ejercicios teóricos. A raı́z de esto, 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 esta lı́nea, dentro del tema de arquitecturas de software se busca definir herramientas matemáticas que permitan chequear las propiedades y aspectos de calidad deben satisfacer; se busca definir métodos formales que permitan evaluar los modelos de manera precisa y confiable. Los propósitos de los métodos formales en la Ingenierı́a de Software son entre otros, sistematizar 10.

(11) 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 especificar procesos y sus interacciones como el cálculo λ para procesos secuenciales, el cálculo π para procesos 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 Modelado Unificado (UML). Con base en éstos, se han desarrollado varias herramientas que se podrı́an denominar mixtas, debido a que UML no es un lenguaje formal estricto. El cálculo ρarq es propuesto para especificar aspectos estructurales y dinámicos de las arquitecturas de software basadas en componentes; ası́ como también una herramienta para evaluar las propiedades deseables de arquitecturas como la corrección [3, 4]. Adicionalmente, dentro de los métodos formales que han entrado a ser parte de la Ingenierı́a de Software se encuentran las lógicas temporales, que se utilizan para describir sistemas concurrentes y reactivos. Es utilizada para especificar propiedades y verificar qué modelos de software las satisfacen[5]. Su utilización usualmente se incorpora en la ejecución de programas concurrentes y tienen una sintaxis y semántica especı́ficas [6]. En el contexto de sistemas reactivos y concurrentes se encuentran las arquitecturas de software basadas en componentes y el chequeo de modelos conformes a este estilo arquitectónico es una necesidad evidente en la actualidad. Es por estas razones que se busca contribuir en la aplicación de técnicas formales al desarrollo de software basado en componentes con el objeto de que desde el punto de vista formal pueda ser más confiable.. 1.2.. Formulación del problema. El cálculo ρarq es una notación formal para especificar arquitecturas de software basadas en componentes desde el punto de vista estructural y dinámico [3]. Su definición se estructura en 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 sus elementos a alto nivel. Una de sus principales caracterı́sticas es que permite realizar razonamiento formal sobre su estructura y comportamiento. Adicionalmente, la posibilidad de utilizar UML como Lenguaje de Descripción Arquitectural que permitirı́a no solo la formalidad de la especificación sino también la posibilidad de ser usado no solo en el ámbito académico sino en el ambiente industrial. Actualmente con el cálculo ρarq no es posible especificar propiedades temporales, relacionadas con el orden lógico de ejecución de una arquitectura; es decir, determinar en un momento dado si una arquitectura llega a cierto estado deseado que depende de la ejecución correcta y.

(12) 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 especificar y validar estas propiedades. En este sentido, se propone integrarlo con la Lógica Lineal Temporal para determinar y especificar un mecanismo mediante el cual se pueda modelar la ejecució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 debe contener un mecanismo que permita especificar y verificar propiedades temporales para modelos de arquitecturas de software basadas en componentes modelados a través del cálculo ρarq ?. 1.3. 1.3.1.. Objetivos General. Establecer el mecanismo para incorporar Lógica Lineal Temporal sobre arquitecturas de software 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 de software basada en componentes especificadas a través del cálculo. Aplicar y validar la propiedad de vivacidad en un modelo arquitectónico basado en componentes especificado a través del cálculo. Implementar el mecanismo de integración de análisis de propiedades usando Lógica Lineal Temporal a la herramienta PintArq.. 1.4.. Justificación. El desarrollo del presente proyecto pretende contribuir en el área de la Ingenierı́a de Software en la medida que se pueda aplicar y extender el paradigma del desarrollo de software basado en componentes, especialmente en el campo de la Arquitectura de Software. De igual forma aportar en la utilización de métodos formales sobre los productos de software, para que esto pueda ayudar a mejorar la calidad de los mismos, ası́ como reducir riesgos inherentes al desarrollo de software en donde ciertos aspectos son todavı́a subjetivos y algunos de los métodos formales utilizados no han tenido la expansión suficiente..

(13) 1.5. METODOLOGÍA UTILIZADA. 13. Desde el punto de vista académico, se propende por la investigación de temas que contribuyan al desarrollo de una Ingenierı́a de Software mucho mas estable y con bases formales mucho mas fuertes.. 1.5.. Metodologı́a utilizada. Como primera parte del desarrollo del proyecto se investigaron los procedimientos mediante 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 para especificar los estados y propiedades para un modelo arquitectónico basado en componentes en el cálculo ρarq . Con los elementos propuestos se procedió a definir la propiedad que serı́a verificada. El proceso se documentó en cada etapa, paso por paso para permitir que sea reproducido posteriormente para verificar una nueva propiedad. La metodologı́a se presenta en la Figura 1.1. Se desarrolló un mecanismo que incorporó la Lógica Lineal Temporal para especificar propiedades temporales a modelos de arquitecturas de software basadas en componentes especificadas a través del cálculo ρarq y se integró a la herramienta PintArq..

(14) 14. CAPÍTULO 1. DESCRIPCIÓN Y PLANTEAMIENTO DEL PROYECTO. Figura 1.1: Actividades relevantes para el desarrollo del proyecto.

(15) Capı́tulo 2 MARCO REFERENCIAL Y ESTADO DEL 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. Usualmente es utilizado para hacer referencia a la utilización de un lenguaje de especificación formal pero no se describe el alcance que éste tiene. En lineas generales entre más abstracto sea el lenguaje en el que se describa un sistema, este lenguaje se denomina formal. En muchas ocasiones no existe un único lenguaje para describir un sistema y se pueden utilizar lenguajes en diferentes grados de formalidad para describir diferentes partes del sistema; sin embargo, un lenguaje 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́n entre procesos. Unos de los métodos mas conocidos son CSP (Communication Sequential Processes) 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 de Especificación Algebraica para Tipos Abstractos de Datos en donde el comportamiento de las operaciones sobre los Tipos Abstractos de Datos se expresan a través de ecuaciones.. 15.

(16) 16. 2.1.1.. CAPÍTULO 2. MARCO REFERENCIAL Y ESTADO DEL ARTE. Chequeo de modelos de software. El chequeo de modelos es una técnica de verificación formal para la evaluación de propiedades formales de sistemas de información y comunicación. El chequeo de modelos requiere un modelo del sistema que se va a analizar, una propiedad deseada y un método para verificar sistemáticamente si el modelo satisface o no la propiedad (por ejemplo, si es libre de interbloqueos, invariabilidad o propiedades de solicitud-respuesta). El chequeo de modelos es una técnica automatizada para verificar la ausencia de errores y considerada como una técnica de depuración efectiva e inteligente. Sus fundamentos formales se encuentran en la lógica proposicional, 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 consideración posee ciertas propiedades. Las propiedades a ser verificadas pueden ser elementales como que un sistema nunca debe caer en un estado de interbloqueo, esto puede obtenerse de la especificación del sistema, la cual establece lo que el sistema tiene o no tiene que hacer, lo cual es la base para la actividad de la verificación. De esta forma, si el sistema no cumple con una propiedad que ha sido especificada se ha encontrado un defecto, asimismo si un sistema cumple 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 comunicaciones se realizan de una forma más confiable pero no de forma completa. Para realizar la verificación del software usualmente se utilizan dos técnicas que pueden combinarse para obtener mejores resultados, una corresponde a la revisión por pares y la otra consiste en las pruebas de software. En la primera el código es analizado antes de su compilación y ejecución por 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. Las pruebas de software consumen entre el 30 y 50 % de los costos de un proyecto y sin embargo no dan confiabilidad de que el software no tenga errores [5, pág. 4]. Asimismo, la importancia de encontrar errores en las etapas iniciales del ciclo de desarrollo de software es imperativa pues el 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, usando un 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. Cuando el 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́n de teoremas y el chequeo de modelos. En el primero, se toma el sistema y las propiedades.

(17) 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 satisface la propiedad si una prueba puede ser construida con ésta lógica. Sin embargo, a pesar de la potencialidad de esta técnica, puede tomar demasiado tiempo para adquirir la experticia y establecer todo el sistema de prueba [12, Pág. 11].. Figura 2.1: Ciclo de vida del software y costos asociados a los errores Fuente [5] De otro lado, en el chequeo de modelos se construye un modelo finito de un sistema y es verificado contra un conjunto de propiedades deseadas, puede ser más limitado que la demostración de teoremas pero es mucho mas rápido y puede ser completamente automatizado. En esencia un modelo es una máquina de estados finita, que puede ser representada en un lenguaje de alto nivel que permita su especificación precisa. Sus propiedades pueden ser especificadas en alguna lógica temporal o en términos de un autómata. Desafortunadamente, el modelamiento de sistemas complejos como máquinas de estado finito puede acarrear una gran desventaja conocida como la explosión de estados, en donde el número de estados en el modelo, crece considerablemente con respecto al número de componentes con los cuales se construye el modelo y por lo tanto su manipulación puede llegar a ser ineficiente. Por lo tanto, el desafı́o principal es encontrar métodos y estructuras de datos que permitan manejar grandes espacios de estados..

(18) 18. 2.2. 2.2.1.. CAPÍTULO 2. MARCO REFERENCIAL Y ESTADO DEL ARTE. Chequeo de modelos y arquitecturas de software Chequeo de arquitecturas de software. Con el objetivo de encontrar errores en el software en las etapas iniciales del ciclo de vida del software, y con el fin de que los costos de su reparación tiendan a disminuir, se establecen herramientas para realizar verificación de software en la etapa de diseño, especı́ficamente en la especificación de una arquitectura. Uno de los enfoques para realizar pruebas de software en la etapa de diseño es denominado Pruebas basadas en Arquitecturas de Software [13], en donde se utilizan la parte dinámica de la arquitectura para identificar esquemas útiles de interacción entre los componentes de software y realizar una selección de clases de prueba que correspondan a comportamientos relevantes de la arquitectura. Este enfoque recae entonces en la utilización de métodos formales para la descripción de la arquitectura, entre ellos encontramos los Sistemas de Transición Rotulados que mencionaremos más adelante [10]. De manera general, un Sistema de Transición Rotulado provee una descripció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 en arquitecturas hacen uso del Lenguaje de Modelado Unificado. Esto debido a la gran versatilidad del lenguaje, a su amplia y extendida utilización en la industria; por lo tanto, muchos de los mecanismos 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 lenguajes con los cuales se pueda describir la parte estática y dinámica de una arquitectura. Con este propósito se han creado varios Lenguajes de Descripción Arquitecturales para proveer este tipo de abstracciones para sistemas grandes y complejos; sin embargo, se han desarrollado bastantes tipos de lenguajes y no se ve muy claro un horizonte de convergencia. Para resolver esto, varias propuestas se han dado a la tarea de basarse en uno de los lenguajes mayormente utilizados en la industria; es decir, el Lenguaje de Modelado Unificado (UML por sus siglas en inglés, www.uml.org) , al ser un lenguaje semiformal, debe ser utilizado con otras herramientas formales que le permitan desarrollar una semántica completa. Existen en esencia tres enfoques que utilizan UML para realizar el modelamiento de Arquitecturas de Software: 1. El lenguaje en sı́, 2. El lenguaje junto con restricciones a través de mecanismos de extensión (como estereotipos) y 3. Extender el metamodelo UML para soportar.

(19) 2.2. CHEQUEO DE MODELOS Y ARQUITECTURAS DE SOFTWARE. 19. directamente los conceptos arquitecturales necesarios [14]; este esquema puede visualizarse en la Figura 2.2. La primera opción presentada presenta como una de sus mayores ventajas la posibilidad de manipulación rápida y fácil de los modelos a través de las variadas herramientas existentes; sin embargo, no provee los mecanismos para representar caracterı́sticas y relaciones intrı́nsecamente arquitecturales, dejando por fuera aspectos importantes de una arquitectura de software. La segunda opción aprovecha uno de los conceptos fundamentales inherentes a UML que consiste en la posibilidad de incorporar nuevas capacidades y conceptos sin cambiar el sentido de la semántica o sintaxis original del lenguaje. Esto se realiza utilizando Restricciones, Estereotipos, Valores etiquetados y Perfiles. Una de las desventajas importantes es que no permite la 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 los conceptos que el diseño de una arquitectura de software pueda necesitar prestando el soporte suficiente. A pesar de esto, no está considerada como una de las estrategias mas fuertes pues su estandarización para este propósito serı́a bastante engorrosa abriendo la posibilidad de que no cumpla con la notación original y no llegue a ser compatible con el desarrollo actual del lenguaje y sus herramientas. En algunos casos, como se presenta en el caso del cálculo ρarq [3], se utiliza el segundo enfoque complementándolo con herramientas formales que brinden una herramienta completa para el modelamiento y chequeo de las propiedades de una arquitectura.. Figura 2.2: Las cuatro capas de la Arquitectura de Metamodelamiento de UML Tomado de: [14]. Página 7.

(20) 20. CAPÍTULO 2. MARCO REFERENCIAL Y ESTADO DEL ARTE. 2.3. 2.3.1.. Lógicas Temporales Modelado de sistemas y lógicas temporales. La corrección funcional es la propiedad de un sistema de cómputo que permite determinar si éste hace aquello para lo cual ha sido desarrollado. Para realizar chequeo de corrección funcional de un sistema, es necesario en primer lugar, establecer las propiedades que deberı́a tener o aquellas consideradas importantes para el análisis. Posteriormente se debe construir un modelo formal que lo represente y que capture las propiedades que se desean verificar. De igual forma, se debe establecer un nivel adecuado de abstracción que permita identificar y modelar estas caracterı́sticas sin necesidad de incluir detalles que no sean relevantes para el análisis. Por ejemplo, si se desea modelar un circuito digital, puede que no sea necesario pensarlo en términos de voltajes y corrientes sino por el contrario usar compuertas lógicas booleanas. Usualmente los sistemas pueden ser modelados como sistemas transformacionales o sistemas reactivos, pero los procesos concurrentes se modelan a través de los sistemas reactivos [15]. Conceptualmente los sistemas de cómputo o programas se dividen en dos, los sistemas transformacionales, que son los mas comunes, cuyo objetivo principal es producir una salida con su ejecución y finalmente terminar. De esta forma, estos sistemas pueden verse como funciones que reciben parámetros, los transforman y ofrecen una salida, es decir, tienen un estado inicial y un estado final [12, Pág. 47]. Usualmente se describen a través de lógica de primer orden. Por otro lado, los sistemas reactivos, no presentan necesariamente un resultado final sino que por el contrario, mantienen una interacción constante con su entorno y algunos de ellos 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 usa un 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 igual forma, cuando se ejecuta una acción que hace evolucionar el sistema de un estado a otro, se puede definir una transición, esta transición se puede describir como el par de estados que describen al sistema antes y después de la acción. Otra caracterı́stica que se define es una computación, que corresponde a una secuencia infinita de estados que describe la evolución del sistema de un estado a otro a través de varias transiciones. Asimismo, pueden identificarse los sistemas concurrentes, los cuales se conforman de un conjunto de componentes que pueden ejecutarse juntos y tienen algún mecanismo para comunicarse. Estos mecanismos pueden variar de un sistema a otro pero se pueden considerar principalmente dos mecanismos de ejecución: Ası́ncrono o intercalado: Dos o mas componentes ejecutan un paso en un momento de-.

(21) 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 de variables compartidas. Intercambio de mensajes: los componentes usan una cola de mensajes o algún tipo de protocolo 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́s de modos que hacen referencia al comportamiento infinito de un sistema reactivo, es una especialización de las lógicas modales que incluyen términos y caracterı́sticas para identificar y especificar propiedades relacionadas con estados de un sistema en diferentes instantes de tiempo. Es un método formal utilizado para describir secuencias de transiciones entre estados de un sistema reactivo en el sentido de la descripción del comportamiento deseado u operación del 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́n de un relativo orden de eventos, se puede decir que se trata de una interpretación discreta del tiempo. Una transición corresponde al avance de una unidad de tiempo simple, el sistema es observable en los puntos 0,1,2,..., etc. La aplicación de este modelo a sistemas computacionales complejos 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, globales o composicionales, lineales o ramificadas, basadas en puntos en el tiempo o en intervalos y en tiempo pasado o futuro. A continuación se describen de manera general cada uno de estos aspectos [18].. 2.3.3.1.. Proposicional / De primer orden. Proposicional hace referencia a lógica clásica, la cual se construye a partir de proposiciones atómicas, las cuales expresan hechos subyacentes al estado del sistema, usa también los.

(22) 22. CAPÍTULO 2. MARCO REFERENCIAL Y ESTADO DEL ARTE. conectores lógicos clásicos y adicionalmente los temporales. Sobre estos conceptos se construye la lógica de primer orden que incluye variables, constantes, funciones, predicados y cuantificadores. Se pueden distinguir también variables locales que pueden tener diferentes valores en diferentes estados o globales que mantienen su valor independiente del estado en el que se encuentren. Pueden imponerse también ciertas restricciones sintácticas sobre los operadores temporales o los cuantificadores.. 2.3.3.2.. Global / Composicional. Usar una lógica global hace referencia cuando se puede razonar sobre un programa por completo, es decir, se puede ver el sistema como un único programa, también denominado como endógeno. Si por el contrario, los operadores plantean el análisis sobre distintas partes de un programa, de tal forma que este se puede descomponer y estudiar en partes independientes pero posteriormente se puede sacar conclusiones del sistema completo, se dice que es una lógica composicional o exógena.. 2.3.3.3.. Lineal / Ramificada. Estas dos visiones consideran la naturaleza del tiempo. Por un lado, lineal quiere decir que en un momento especı́fico solo existe un único momento futuro posible y por lo tanto describen eventos a lo largo de un solo camino y, por otro lado, en la ramificada se entiende que en un momento dado, el tiempo puede dividirse en varios caminos alternativos que representan diferentes 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 del tiempo o por el contrario se pueden determinar espacios de tiempo sobre los cuales se puede razonar un programa.. 2.3.3.5.. Discreta / Continua. El concepto de discreto hace referencia al momento presente que corresponde al estado actual del sistema y el momento futuro al estado sucesor inmediato. De otro lado, el término continuo, describe una estructura de tiempo real en donde algunos sistemas tienen requerimientos más estrictos de rendimiento..

(23) 2.3. LÓGICAS TEMPORALES 2.3.3.6.. 23. De tiempo pasado / De tiempo futuro. Esta caracterı́stica está definida por los operadores que la lógica, en su mayorı́a se utilizan en tiempo futuro en donde se establece un punto inicial y se evalúa el comportamiento hacia adelante y la inclusión de operadores en tiempo pasado no agregan ningún valor adicional; sin embargo, 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 futuro, discretas, basadas en puntos y combinan la lógica de primer orden que incluye la lógica proposicional.. 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 de computaciones (o cómputo). La estructura subyacente es un árbol ramificado infinito, el cual determina, que un momento especı́fico (o nodo dentro del árbol) puede tener varios momentos sucesores y un cada uno debe tener al menos un predecesor. Para representar estos sistemas se utilizan estructuras Kripke [15, Pág. 27]. Una estructura Kripke se puede definir como un modelo formal que representa el comportamiento de un sistema de cómputo a través de un conjunto de estados, un conjunto de transiciones entre los estados y una función que etiqueta a cada estado con un conjunto de propiedades que son ciertas en ese estado. Las rutas o caminos en una estructura modelan una computación o camino de estados. El modelo tiene la suficiente simpleza para no agregar complejidades innecesarias y la suficiente expresividad para capturar aspectos 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 por el 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 abren varios 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 ).

(24) 24. CAPÍTULO 2. MARCO REFERENCIAL Y ESTADO DEL ARTE ∧, ∨, ¬: conectores booleanos. (AND, OR, NOT) S , : modalidades temporales básicas. (NEXT, UNTIL) ∃, ∀: cuantificadores.. Las proposiciones atómicas son afirmaciones sobre valores de variables de control o valores de variables de programa. Los conectores lógicos son usados de la misma forma que en la lógica proposicional y pueden derivar conectores mas complejos a través de la definición de estos 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. S. ϕ2. donde (a ∈ AP ) De otro lado, las modalidades temporales básicas se describen intuitivamente de la siguiente forma: : 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ϕ). S. S : 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 en todos 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 (ϕ1 Uϕ2 ). A partir de las modalidades temporales básicas pueden derivarse las siguientes modalidades mas complejas: def. ♦ϕ = true. S. ϕ. ♦: 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 puede usar 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”,.

(25) 25. 2.3. LÓGICAS TEMPORALES. “globalmente” o “es necesario que” del inglés “globally” y también se puede usar el sı́mbolo G para representarlo (Gϕ). Adicionalmente, existe el operador RSdenominado “hasta que libera” del inglés “release” y se considera como el dual del operador . R: es un operador infijo binario que requiere dos formulas como argumentos. ϕ1 Rϕ2 es cierta si ϕ2 es cierta en el presente y hasta que ϕ1 sea cierta junto con ϕ2 . Si ϕ1 no llega a ser verdadera, 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 en un 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 desde ese momento en adelante. Los cuantificadores son utilizados en estados determinados para especificar que las rutas que 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 A f 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 , G f , f son fórmulas de ruta.. 2.3.4.2.. Estructuras Kripke. Una estructura Kripke se define de la siguiente manera:. S. g y f Rg.

(26) 26. CAPÍTULO 2. MARCO REFERENCIAL Y ESTADO DEL ARTE. Se tiene AP como el conjunto de proposiciones atómicas. Una estructura Kripke M sobre AP 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 que para 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́micas verdaderas en ese estado S → 2AP . Una ruta en M desde un estado s, es una secuencia infinita de estados π = s0 s1 s2 ... tal que para 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́n M, s |= f significa que f es cierta en el estado s en la estructura M . Si f es una fórmula de ruta, la notación M, π |= f es cierta a lo largo del camino π en la estructura M. Asumiendo que f1 , f2 son fórmulas de estado y, g1 , g2 son fórmulas de ruta: • M, s |= p. ⇐⇒. • M, s |= ¬f1. p ∈ L(s). ⇐⇒. 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 |= A g1. ⇐⇒. para cada ruta π desde s tal que M, π |= g1. • M, π |= f1. ⇐⇒. • M, π |= ¬g1. s es el primer estado de π y M, π |= f1. ⇐⇒. M, π 2 g1. • M, π |= g1 ∨ g2. ⇐⇒. M, π |= g1 o M, π |= g2. • M, π |= g1 ∧ g2. ⇐⇒. M, π |= g1 y M, π |= g2.

(27) 27. 2.3. LÓGICAS TEMPORALES • M, π |= X g1. ⇐⇒. M, π 1 |= g1. • M, π |= F g1. ⇐⇒. existe un k ≥ 0 tal que M, π k |= g1. • M, π |= G g1 ⇐⇒ para todos los i ≥ 0 tal que M, π i |= g1 S ⇐⇒ existe un k ≥ 0 tal que M, π k |= g2 y para todos los • M, π |= g1 g2 0 ≤ j ≤ k tal queM, π j |= g2 • M, π |= g1 Rg2 ⇐⇒ j entonces M, π |= g2. para todos los j ≥ 0, si para cada i < j , M, π i 2 g1. La Lógica de Árboles de Cómputo * (CTL*) se divide a su vez en Lógica de Árboles de Cómputo simple (Computation Tree Logic - CTL) y Lógica Lineal Temporal (Lineal Temporal Logic - 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 la Figura 2.3.. Figura 2.3: Relación entre las lógicas temporales Tomado 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 utilizar siempre los cuantificadores. Utiliza únicamente fórmulas de ruta. Existen diez operadores básicos: AX y EX AF y EF AG y EG.

(28) 28. CAPÍTULO 2. MARCO REFERENCIAL Y ESTADO DEL ARTE A. S. yE. S. AR y ER Cada uno de estos S operadores puede ser expresado en términos de tres operadores solamente, EX, EG y E : AX f = ¬EX(¬f ) S EF f = E(T rue f ) AG f = ¬EF (¬f ) AF f = ¬EG(¬f ) S S A(f g) ≡ ¬E[¬g (¬f ∧ ¬g)] ∧ ¬EG¬g S A(f R g) ≡ ¬E(¬f ¬g)] S E(f R g) ≡ ¬A(¬f ¬g)] Una representación gráfica de algunos de los operadores puede verse en la Figura 2.4. Cada una 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 los operadores (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).

(29) 2.3. LÓGICAS TEMPORALES. 29. Figura 2.4: Representación gráfica de algunos operadores CTL Tomado 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 en CTL* con la restricción que no utiliza cuantificadores, por lo tanto, sus fórmulas son únicamente de ruta, su representación no genera una estructura de árbol sino un único camino. Desde este punto 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 componente actúa en un paso a la vez. Esto quiere decir que una transición corresponde con el avance de una unidad de tiempo, haciendo referencia a la naturaleza discreta del tiempo; el momento presente se define como el estado actual y el momento siguiente como al estado sucesor. Se puede 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 se pueden apreciar en la Figura 2.5..

(30) 30. CAPÍTULO 2. MARCO REFERENCIAL Y ESTADO DEL ARTE. Figura 2.5: Representación gráfica de los operadores LTL Adaptada de [15] y [5]. 2.3.6.1.. Ejemplo: Para ilustrar como se construyen las fórmulas para una Lógica Lineal Temporal, se presenta un ejemplo que muestra como se representan algunas propiedades para un problema de exclusión mutua entre procesos:. Se consideran dos procesos concurrentes P1 y P2 . Cada proceso Pi puede estar en una de tres 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..

(31) 31. 2.3. LÓGICAS TEMPORALES. Primero se definen las proposiciones atómicas que representan las fases de estar o no en la sección crı́tica y estar en estado de espera: criti (proceso i que ejecuta su sección crı́tica) se utilizará 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 cumpla que existe exclusión mutua entre los procesos. Para esto se definen las siguientes propiedades y 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́n crı́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 con frecuencia en su sección crı́tica. ♦(crit1 ) ∧ ♦(crit2 ) En este caso la fórmula, determina que es obligatorio que cada uno de los procesos ejecute su 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 momento posterior 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 un semá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 su sección crı́tica..

(32) 32. CAPÍTULO 2. MARCO REFERENCIAL Y ESTADO DEL ARTE. 2.4. 2.4.1.. Chequeo de modelos y lógicas temporales Generalidades. Es una técnica de verificación de sistemas concurrentes, en el que teniendo un modelo del sistema y la especificación de una propiedad determinada, se desea evaluar exhaustiva y automáticamente si el modelo cumple con la propiedad bajo verificación. El proceso del chequeo de modelos se compone de los siguientes elementos[20]: Modelo: Corresponde al modelo del sistema, es una abstracción de la estructura y comportamiento de éste. Especificación: Corresponde a la caracterización formal de la propiedad que se ha determinado que debe satisfacer el sistema. Método de verificación: Corresponde a un algoritmo que define los pasos mediante los cuales se va a establecer si la especificación de la propiedad es satisfecha por el modelo del sistema. Estos elementos deben estar representados a través de un lenguaje o método formal que permita cumplir el objetivo. El problema del chequeo de modelos puede describirse formalmente de la siguiente manera[15]: Se tienen dos elementos, una estructura Kripke M = (S, R, L) (en algunos casos los estados iniciales no son de particular interés y pueden ser omitidos de la definición) que representa el sistema concurrente de estados finitos y una fórmula en lógica temporal f que especifica cierta propiedad. A partir de estos, se establece que debe encontrarse el conjunto de estados en S que 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 representación explı́cita del modelo a través de un grafo dirigido en donde los nodos corresponden a los estados en S, los arcos están dados por la relación R y las etiquetas asociadas a los nodos corresponden a la función L. Esta representación es útil para entender el problema pero puede llegar a ser compleja de manejar para modelos grandes. Por lo tanto, se han establecido otros mecanismos para llevar a cabo la verificación..

(33) 2.4. CHEQUEO DE MODELOS Y LÓGICAS TEMPORALES. 2.4.2.. 33. 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 que satisfacen 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 en s. Las subfórmulas de f son todas aquellas en las que se puede descomponer, por ejemplo: si f = ¬(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; cuando el 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 ciertas en el estado) y el proceso ocurre a través de varias etapas, en las que se van agregando las subfórmulas al conjunto label(s). La etapa i = 0, consiste en etiquetar cada estado con las subfórmulas atómicas que son ciertas en cada estado. En cada i-ésima etapa, se procesan los operadores de la subfórmula de la etapa i − 1. Si esta subfórmula es verdadera en el estado se agrega al conjunto label(s) del estado. 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 solo es necesario manejar seis casos dependiendo si la subfórmula es atómica o tiene una de las siguientes formas: ¬f1 , f1 ∨ f2 ,EXf1 ,E[f1 Uf2 ] 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 estructura Kripke M, la especificación está representada por la fórmula CTL f y el algoritmo para determinar si el modelo satisface la especificación se puede describir de la siguiente forma, la cual es adaptada de[20]. Se tiene S, el conjunto de estados del modelo M y f la propiedad que debe ser satisfecha, entonces sat(f ) es la función que determina el conjunto de estados de M que satisfacen f . Este algoritmo etiqueta cada estado iterativamente hasta encontrar todos los estados que satisfacen la fórmula. Se cuenta también con L(s) que corresponde al conjunto de 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..

(34) 34. CAPÍTULO 2. MARCO REFERENCIAL Y ESTADO DEL ARTE. Algoritmo 2.1 Algoritmo sat(f ) Función sat(f ) Inicio. Según sea. 1. g es true: retornar S 2. g es f alse: 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 (true U f1 )) 13. g es EG f1 : retornar sat(¬AF ¬f1 )) 14. g es AF f1 : retornar satAF (f1 ) 15. g es AG f1 : retornar sat(¬EF ¬f1 ). Fin Segun sea Fin Fuente: Adaptado de [20] Debido que algunas de las verificaciones son más complejas, se establecen tres funciones adicionales 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 adelante 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, dicha fórmula es agregada al conjunto de etiquetas representado por label(s). Para algunos casos se define 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 sean ciertas 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 dentro del conjunto, de igual forma con el caso 6 el estado es etiquetado con f1 ∨ f2 si cualquiera de los 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 de sus sucesores esta etiquetado con f1 ; de igual forma para el caso 8, AX f1 , se etiquetan los estados con la fórmula, si todos los sucesores están etiquetados con f1 ..

(35) 2.4. CHEQUEO DE MODELOS Y LÓGICAS TEMPORALES. 35. 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. Fin Fuente: Adaptado de [20] 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. Fin Fuente: Adaptado de [20] Para el caso 14, g es AF f1 algoritmo 2.3, el proceso de etiquetado consiste en dos grandes pasos: 1. Si cualquier estado s está etiquetado con f1 , entonces etiquetar el estado también con AF f1 . 2. Repetir: etiquetar cada estado s con AF f1 si todos sus sucesores están etiquetados con AF f1 hasta que ya no haya ningún cambio. Este procedimiento proviene de la siguiente regla: AF f1 ≡ f1 ∨ AX AF f1 Para el caso 11, E(f1 U f2 ) algoritmo 2.4, el proceso de etiquetado también es compuesto.

(36) 36. CAPÍTULO 2. MARCO REFERENCIAL Y ESTADO DEL ARTE. 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 al menos uno de sus sucesores está etiquetado con E(f1 U f2 ). Realizar esto hasta que no hayan 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 anteriormente explicados, 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:.

(37) 2.4. CHEQUEO DE MODELOS Y LÓGICAS TEMPORALES. 37. |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 la fórmula EX f se puede ver en las Figura 2.6 y 2.7. En el estado inicial se establece arbitrariamente 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 que satisfacen 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 desarrollo del 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 2 Fuente: El autor..

(38) 38. CAPÍTULO 2. MARCO REFERENCIAL Y ESTADO DEL ARTE. Figura 2.7: Ejemplo función de etiquetado EX f . Estado final del sistema. Parte 2 de 2 Fuente: El autor.. Figura 2.8: Algoritmo EX f. Desarrollo del árbol del sistema. Fuente: El autor..

(39) 2.4. CHEQUEO DE MODELOS Y LÓGICAS TEMPORALES. 39. El ejemplo del procedimiento para la fórmula AF f , se representa a través de la Figura 2.9. Nuevamente, en el estado inicial se establecen arbitrariamente los estados en los que la fórmula f es verdadera: s4 y s5 . En el estado intermedio, según el algoritmo, se etiquetan con AF f , los estados que tienen f , es decir, s4 y s5 inicialmente. Por último, se evalúa en cada uno de los predecesores de estos estados si todos sus sucesores contienen la etiqueta AF f si es 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 la etiqueta AF f , pues en el estado s0 no es posible afirmar esto ya que s3 no está etiquetado y el algoritmo termina. Finalmente, los estados que satisfacen la fórmula AF f desde el estado s0 , son s1 ,s2 ,s4 ,s5 , lo cual quiere decir que para todos esos estados en todos los caminos que se desprenden desde s0 , eventualmente f es verdadera..

(40) 40. CAPÍTULO 2. MARCO REFERENCIAL Y ESTADO DEL ARTE. Figura 2.9: Ejemplo para la función de etiquetado AF f Sup-Izq: El estado inicial del sistema. Sup-Der: Estado intermedio. Inf: Estado final del sistema. Fuente: El autor..

(41) 2.4. CHEQUEO DE MODELOS Y LÓGICAS TEMPORALES. 41. El ejemplo del procedimiento para la fórmula E(f1 U f2 ) se puede ver representado en la Figuras 2.10, 2.11, 2.12 y 2.13. Inicialmente se ha establecido que la fórmula f1 es verdadera en s1 , s2 , s3 , s4 , s5 y s6 . De igual forma, la fórmula f2 es verdadera en s7 . De acuerdo con el algoritmo, si un estado es etiquetado con f2 , debe etiquetarse con E(f1 U f2 ), por lo tanto el estado s7 es etiquetado con esta fórmula como puede verse en el paso intermedio 1. Posteriormente, se inicia un ciclo en el que se indica que si un estado está etiquetado con f1 y al menos uno de sus sucesores con E(f1 U f2 ), dicho estado debe etiquetarse con la misma fórmula; en el paso intermedio 2 puede verse este proceso, en donde, los estados s4 y s5 son etiquetados, este proceso continúa hasta que ya no se cumpla la condición. En este ejemplo, el proceso termina cuando se llega a los estados s1 y 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́rmula indica que f1 será cierta a través de las rutas que inician en s1 y s2 y hasta que f2 sea cierta en s7 .. Figura 2.10: Ejemplo función de etiquetado E(f1 U f2 ). Estado inicial del sistema. Parte 1 de 4 Fuente: El autor..

(42) 42. CAPÍTULO 2. MARCO REFERENCIAL Y ESTADO DEL ARTE. Figura 2.11: Ejemplo función de etiquetado E(f1 U f2 ). Estado intermedio 1. Parte 2 de 4 Fuente: El autor.. Figura 2.12: Ejemplo función de etiquetado E(f1 U f2 ). Estado intermedio 2. Parte 3 de 4 Fuente: El autor..

(43) 2.4. CHEQUEO DE MODELOS Y LÓGICAS TEMPORALES. 43. Figura 2.13: Ejemplo función de etiquetado E(f1 U f2 ). Estado final del sistema. Parte 4 de 4 Fuente: El autor.. 2.4.2.2.. Algoritmos alternos para Chequeo de modelos. Los algoritmos alternos para el chequeo de modelos hacen referencia a opciones alternativas para resolver la cuestión de satisfactibilidad de la propiedad en el modelo para algunos operadores, tales como EG y AG. Operador EG - Algoritmo alterno 1 En el algoritmo 2.5 aparece un nuevo concepto relacionado con los grafos: Componente Fuertemente Conectado no trivial (non-trivial Strongly Connected Component (SCC)), estos componentes son subgrafos en los cuales desde cualquiera de los nodos que lo componen se puede llegar a cualquiera de los demás nodos que hacen parte del subgrafo (esencialmente generan un ciclo entre ellos mismos), un grafo C es no trivial si y solo si tiene más de un nodo o contiene un nodo con una transición a si mismo. Se tiene que S ′ , es el conjunto de estados que están etiquetados con f , se seleccionan los nodos que hacen parte de los SCC del modelo y se almacenan en T . El procedimiento de etiquetado consiste en marcar los nodos de los SCC ya que están conectados, y por lo tanto existirá al menos un camino en el que se podrá llegar a otro de los estados con la fórmula EG f . Después, se irá recorriendo desde cada uno de los nodos de S ′ revisando si tiene como sucesores a alguno de los estados que pertenecen a T (los nodos conectados). Al final se tendrán etiquetados los estados que satisfacen la fórmula EG f ..

(44) 44. CAPÍTULO 2. MARCO REFERENCIAL Y ESTADO DEL ARTE. 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 ′ } S T := C∈SCC {s | s ∈ C} Para todo s ∈ T hacer label(s) ∪ {EG f } Mientras T 6= Ø hacer seleccionar s ∈ T T := T − {s} Para todo t ∈ S ′ y R(t, s) hacer Si. EG f ∈ / label(t) entonces label(t) := label(t) ∪ {EG f } 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 EG f en donde f sea verdadera. 2. Repetir: En los nodos restantes, borrar la etiqueta si ninguno de los sucesores de un estado está etiquetado con EG f . 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 inicial del sistema, los estados en los que f es verdadera son s1 , s2 , s4 , s6 , s7 y s8 . En el siguiente paso, a los nodos que no tienen al menos un sucesor etiquetado con la fórmula se les remueve la etiqueta, en este caso s2 ..

(45) 2.4. CHEQUEO DE MODELOS Y LÓGICAS TEMPORALES. 45. Figura 2.14: Representación gráfica del algoritmo para EG alternativo Izq: 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 AG f en donde f sea verdadera. 2. Repetir: En los nodos restantes, borrar la etiqueta si todos los sucesores de un estado no están etiquetados con AG f . 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 del modelo..

(46) 46. 2.5.. CAPÍTULO 2. MARCO REFERENCIAL Y ESTADO DEL ARTE. Cálculo ρarq. El cálculoρarq , un lenguaje de descripción arquitectural con notación formal para especificar los 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 una arquitectura pasando de una configuración estática a una nueva configuración a través de las reglas definidas por el lenguaje. De igual forma, posee una notación gráfica basada en UML 2.x a 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 una arquitectura especificada a través del cálculo. La aplicación desarrollada recibe un conjunto de fórmulas especificadas en el cálculo y se encarga de la visualización de cada una de las etapas de la ejecución [21].. 2.5.1.. Sintaxis. El lenguaje se compone de un conjunto de sı́mbolos y expresiones basadas en las entidades del cálculo ρ original y adaptando algunas al contexto de las arquitecturas de software [22].. Figura 2.15: Sintaxis del cálculo ρarq Fuente: [4].

(47) 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). El sı́mbolo x̄ define una secuencia de finita de variables (x1 , x2 , ..., xn ). Las variables ligadas de E se representan por BV(E) y las variables libres F V(E). Las primeras representan aquellas variables que son solo válidas en el contexto de E y no pueden ser reemplazadas (o que ya han sido reemplazadas en su contexto y no pueden ser de nuevo reemplazadas), por el contrario las libres pueden ser sustituidas desde una invocación externa. Las expresiones son elementos definidos por el cálculo que representan componentes y configuraciones 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 (E int ): representa la parte interna de E, permite establecer la diferencia entre E el cual puede conectarse con otros componentes a través de sus interfaces y E int que ayuda a determinar si su parte interna fue ejecutada con éxito. Combinador de selección condicionada (if (C1 )...(Cn ) else G): es la generalización de una expresión condicional en donde cada elemento (Ck ) tiene una condición de guarda re¯ Ek ), si la cláusula se cumple, se libera el cuerpo de presentada por Ck = ∃x(φk then expresión definida por Ek , si por el contrario ninguna de las cláusulas se cumple, se libera G, que puede ser usado en el cálculo para el manejo de fallas. Esta expresión introduce no-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. Su interpretación establece que el componente recibe una variable x, que reemplaza a ȳ en el 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. Se asocia con el envı́o de un mensaje a lo largo de un canal asociado a un componente, en el caso que el componente sea nulo (xy/⊤), ¯ se puede abreviar con (xy). ¯ Reacción interna (τ /E): Se lee como la reacción interna de E cuyo estado observable no es de interés y permite reducir el número de estados a analizar en la ejecución de una configuració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 lista para reaccionar y se queda listo para replicar. Esta expresión permite representar la ejemplificación de los componentes. Puede ser expresada también de la siguiente forma x : ȳ/E ≡ x :: ȳ/E ∧ x : ȳ/E..