Levels of learning 70

Inicio S′ :={s|f ∈label(s)} SCC :={C|C es un SCC de S′ } T :=S_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 est´a etiquetado con EG f. Terminar cuando no haya ning´un cambio.

Puede verse gr´aficamente la ejecuci´on 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 f´ormula se les remueve la etiqueta, en este caso s2.

2.4. CHEQUEO DE MODELOS Y L ´OGICAS TEMPORALES 45

Figura 2.14: Representaci´on gr´afica 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 est´an etiquetados con AG f. Terminar cuando no haya ning´un cambio.

Puede verse que para el operadorAG la f´ormula f debe ser verdadera en todos los estados del modelo.

2.5.

C´alculo

ρ

arq

El c´alculoρarq, un lenguaje de descripci´on arquitectural con notaci´on formal para especificar

los aspectos estructurales y din´amicos de arquitecturas de software basadas en componentes [4]. Posee una sem´antica operacional que le permite representar el cambio de estado de una arquitectura pasando de una configuraci´on est´atica a una nueva configuraci´on a trav´es de las reglas definidas por el lenguaje. De igual forma, posee una notaci´on gr´afica basada en UML 2.x a trav´es de una extensi´on estereotipada que puede ser traducida al c´alculo. Basado en el c´alculo ρ, es especificado a trav´es de tres elementos: expresiones, congruencia estructural y reducci´on. En la actualidad se ha desarrollado una aplicaci´on que permite visualizar la ejecuci´on de una arquitectura especificada a trav´es del c´alculo. La aplicaci´on desarrollada recibe un conjunto de f´ormulas especificadas en el c´alculo y se encarga de la visualizaci´on de cada una de las etapas de la ejecuci´on [21].

2.5.1.

Sintaxis

El lenguaje se compone de un conjunto de s´ımbolos y expresiones basadas en las entidades del c´alculo ρ original y adaptando algunas al contexto de las arquitecturas de software [22].

Figura 2.15:Sintaxis del c´alculo ρarq

2.5. C ´ALCULO ρ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 v´alidas en el contexto deE 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 invocaci´on externa.

Las expresiones son elementos definidos por el c´alculo 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 acci´on.

Composici´on(E∧F): expresa composici´on concurrente entre dos componentes.

Parte interna de E (Eint_{): representa la parte interna de E, permite establecer la dife-}

rencia entreE el cual puede conectarse con otros componentes a trav´es de sus interfaces y Eint _{que ayuda a determinar si su parte interna fue ejecutada con ´exito.}

Combinador de selecci´on condicionada (if(C1)...(Cn)else G): es la generalizaci´on de una

expresi´on condicional en donde cada elemento (Ck) tiene una condici´on de guarda re-

presentada por Ck = ∃x(φkthen E¯ k), si la cl´ausula se cumple, se libera el cuerpo de

expresi´on definida porEk, si por el contrario ninguna de las cl´ausulas se cumple, se libe-

raG, que puede ser usado en el c´alculo para el manejo de fallas. Esta expresi´on introduce no-determinismo si m´as de una cl´ausula es cierta y se libera m´as de una expresi´on. Abstracci´on (x :: ¯y/E): se lee, el componente E con entrada ¯y a lo largo de x. Su interpretaci´on establece que el componente recibe una variable x, que reemplaza a ¯y en el componente. Esto es posible solo six, es libre en E.

Aplicaci´on (x¯y/E): se lee, enviar ¯y a lo largo de x y continuar con la ejecuci´on 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).

Reacci´on interna (τ /E): Se lee como la reacci´on interna deE cuyo estado observable no es de inter´es y permite reducir el n´umero de estados a analizar en la ejecuci´on de una configuraci´on.

Declaraci´on (∃wE): se lee, se introduce una referenciaw con alcance E.

Replicaci´on de abstracci´on (x : ¯y/E): se lee, se genera una nueva abstracci´on lista para reaccionar y se queda listo para replicar. Esta expresi´on permite representar la ejemplificaci´on de los componentes. Puede ser expresada tambi´en de la siguiente forma x: ¯y/E ≡x:: ¯y/E ∧ x: ¯y/E.

Ejecuci´on exitosa / fallida del componente (E⊤ , E⊥

): representan respectivamente la ejecuci´on exitosa o fallida del componente E.

Observaci´on de ejecuci´on (OSO(E)do F else G): representa la observaci´on sobre la eje- cuci´on del componente E, si su ejecuci´on es exitosa se libera F de lo contrario se libera G.

2.5.2.

Especificaci´on formal de una arquitectura

La especificaci´on formal de cada componente se realiza a trav´es de la descripci´on de cada una de sus interfaces. Se especificar´a el componente E ilustrado en la Figura 2.16. Esta repre- sentaci´on se basa en dos fuentes, por un lado, la notaci´on visual del lenguaje de configuraci´on Darwin al c´alculoπ y por otro, la notaci´on gr´afica de componentes propuesta por UML 2.0. Un componente se representa por un rect´angulo con el estereotipo <<component>> y el nombre del componente en el centro. Si se desea puede agregarse el ´ıcono de componente en la margen superior derecha. Los puertos p´ublicos, son representados a trav´es de cuadrados que sobresa- len del componente; estos tienen un nombre que usualmente contiene una referencia al tipo de servicio que ofrece y un sub´ındice al componente al que pertenece (p, representa que provee, y r, que requiere).

Las interfaces, se representan con una l´ınea continua saliendo de un puerto, las que son de salida tienen un circulo cerrado no relleno, se denomina de provisi´on de servicio. Este servicio tiene un nombre identificado con la letra (s) y un sub´ındice asociado al componente al que pertenece, su especificaci´on formal en el c´alculo es:

P ROVE(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 ubicaci´on

lE que espera recibir un valor que pueda reemplazar el par´ametro iE en el componente. Su

especificaci´on 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 p´ublicas de salida y entrada que lo configuran actuando de forma concurrente, su especificaci´on es:

2.5. C ´ALCULO ρARQ 49

Figura 2.16: Representaci´on gr´afica de un componente

Fuente: [4]

De esta forma, se especifica y representa gr´aficamente un componente y una configuraci´on arquitectural.

2.5.3.

Sem´antica Operacional y Ejecuci´on de una arquitectura

El c´alculo permite modelar el comportamiento de arquitecturas basadas en componentes a trav´es de su sem´antica operacional. Por un lado, se utiliza la congruencia estructural (≡) del c´alculoρ, que corresponde a la menor congruencia (menor relaci´on l´ogica de equivalencia) de los axiomas del c´alculo y reglas de reducci´on que representan esta sem´antica. Por otro lado, utiliza los sistemas de transici´on rotulados para representar la evoluci´on en la ejecuci´on de la arquitectura a trav´es de sem´antica operacional definida para este fin.

Con respecto a los axiomas que se muestran en la Figura 2.17, se encuentran: Replicaci´on de observaci´on, que permite hacer vistas sucesivas de la ejecuci´on de un componente y, ´Exi- to/Fracaso Observacional que permite realizar reemplazos en las entradas de un componente y ejecutarlo. Una ejecuci´on exitosa o no-exitosa puede representarse con (E⊤

, E⊥

) respectiva- mente.

Figura 2.17:Axiomas del c´alculo ρarq

Del conjunto de reglas de reducci´on, que se muestran en la Figura 2.18, se encuentran: Aρarq(aplicaci´on), que ejecuta una combinaci´on de forma concurrente de una abstrac-

ci´on con una replicaci´on que ejemplifica una aplicaci´on. Esta regla modela llamadas de procedimientos pasando par´ametros dentro de un componente.

Cρarq(combinaci´on de restricciones), permite combinar restricciones con el prop´osito de

ampliar o simplificar el conjunto de estas restricciones del repositorio.

Comb ρarq , dispara la ejecuci´on de unEk si la restricci´on de contexto es suficientemente

fuerte y permite deducir desdeφ la guardaψk del condicional respectivo. Esta regla per-

mite escoger un componenteEk dentro de un grupo, siempre y cuando cumpla la guarda

definida. De otro lado, si la restricci´on de contexto arquitectural no es lo suficientemente fuerte para deducir desde ´esta alguna de las guardas de las cl´ausulas, se generar´ıa el comportamiento alterno del componente F, que podr´ıa corresponder al manejo de fallas o errores en el sistema.

Ejecτ, esta regla permite establecer la ejecuci´on de ´exito o fracaso observacional de un

componente. Esto se realiza con el prop´osito de representar un componente como una caja negra, en donde lo relevante es el comportamiento final de su ejecuci´on y no el procesamiento interno del mismo, que no es visible para un observador externo.

Estas reglas, permiten especificar formalmente el avance de la ejecuci´on de una arquitectura.

Figura 2.18: Reglas de reducci´on del ρArq

Fuente: [4]

Una vez se realiza la especificaci´on de los componentes de una arquitectura, puede esta- blecerse una interacci´on entre los mismos, esta interacci´on se realiza a trav´es del ensamblaje de las interfaces de entrada y de salida en donde puede ocurrir una ejecuci´on, un ejemplo de este ensamblaje puede observarse en la Figura 2.19 y cuya especificaci´on en el c´alculo es la siguiente:

2.5. C ´ALCULO ρARQ 51

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

F def= (pF :z/zsF)

El ensamblaje se realiza a trav´es de un conector, este conector se denomina C y est´a identificado por los componentes que ensambla, es decir:

CEF def

= rEpF

Figura 2.19:Notaci´on gr´afica del ensamble de componentes

Fuente: [4]

La ejecuci´on concurrente de los componentes con el conector hace que se inicie la ejecuci´on de 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 especificaci´on junto con las reglas de transici´on y el repositorio de restricciones per- miten que la configuraci´on de la arquitectura avance hacia una nueva configuraci´on en donde sus componentes interact´uan mostrando su evoluci´on.

Este comportamiento viene especificado por: S1

Aρarq

=⇒ (pE :x/xsE) ∧ [sF/iE]E(int))

La representaci´on gr´afica de la ejecuci´on es simbolizada por untoken (punto negro en la Figura 2.19).

2.5.4.

Sistemas de Transici´on Rotulados Condicionados

Otro de los conceptos utilizados en el c´alculo, son sistemas de transici´on rotulados, que se usan para representar la evoluci´on comportamental del sistema especificado. Este concepto permite verificar la propiedad de correcci´on entre una especificaci´on de un conjunto de arqui- tecturas comunes de comportamiento (modelo de referencia) y una arquitectura de referencia particular. El c´alculo permite la utilizaci´on de variables l´ogicas en las restricciones de las ar- quitecturas basadas en componentes, esto permite incorporar un modelo de computaci´on por restricciones que posee un repositorio (store) que son utilizadas para controlar el flujo de eje- cuci´on de la arquitectura. Este esquema permite establecer un sistema de transici´on rotulado condicionado con el fin de representar la evoluci´on en el comportamiento de la arquitectura. Las reglas previamente definidas son las que determinan el momento en el que una nueva configuraci´on evoluciona hacia una siguiente configuraci´on.

El sistema de transici´on rotulado (STR), establece un elemento b´asico denominadoacci´on, el cual permite fluir de un estado a otro. Un STR sobre un conjunto de acciones Act, es un par (Q,T ) se define de la siguiente forma[4]:

Conjunto de estados (Q)

Relaci´on de Transici´on: relaci´on ternaria T ⊆(Q ×Act× Q)

De igual forma, un STR Condicionado es aquel en el que una acci´on α ∈ Act, puede ser una restricci´on o guarda booleano y acciones que no sean restricciones pueden estar condicionadas a estos mismo elementos.

Adicionalmente, el c´alculo establece varias definiciones sobre la relaci´on entre el c´alculo ρArq y los STR Condicionados con el fin de estructurar el modelo que representar´a la evoluci´on

en la configuraci´on de la arquitectura a trav´es de las reglas. Esta correspondencia se define a trav´es de los estados en el sistema, en donde estos estados son expresiones arquitecturales que se reducen de manera concurrente. De esta manera, cuando las expresiones se reducen, la arquitectura pasa de una configuraci´on a otra a trav´es de las acciones observables y no observables. La regla Ejecτ permite modelar en los casos de ´exito o fracaso observacional en la

ejecuci´on de un componente. De igual forma, la expresi´on OSO (On Success Of) en composici´on con un componente que se ejecuta de forma exitosa se reduce a una expresi´on arquitectural F o G que representan los caso de ´exito o fracaso respectivamente; a trav´es de este esquema, se especifica formalmente el avance en la ejecuci´on de la arquitectura.

Las reglas de transici´on del c´alculo se definen en la Figura 2.20, estas reglas determinan las acciones posibles en una configuraci´on, representan el env´ıo o recepci´on de mensajes, activar

2.5. C ´ALCULO ρARQ 53

un conjunto de componentes de acuerdo a las restricciones, ejecuci´on de los componentes y observabilidad de la misma de acuerdo a la granularidad necesaria.

Figura 2.20: Reglas de transici´on del ρArq

Fuente: [4]

Adicionalmente, el c´alculoρArq, define tambi´en un modelo de congruencia estructural y bi-

similaridad con el cual se puede realizar chequeo de correcci´on. Este modelo permite establecer si una arquitectura de referencia es “correcta” con respecto a su especificaci´on de alto nivel definida por un modelo de referencia.

2.6.

Lenguajes de Descripci´on Arquitectural y L´ogicas

Temporales

Con el prop´osito de desarrollar grandes sistemas de software que necesita la sociedad ac- tual, se han establecido tambi´en diversos modelos, t´ecnicas, metodolog´ıas y tecnolog´ıas, que procuren desarrollar software complejo y de calidad. Dentro de estas posibilidades se encuentra el desarrollo de software basado en componentes y por supuesto la concepci´on de arquitecturas de software basadas en este paradigma[23]. Igualmente, se han desarrollado metodolog´ıas para arquitecturas basadas en componentes que buscan la reutilizaci´on de software previamente construido o que pueda servir para este prop´osito y por lo tanto, reducir el tiempo y/o costos de implementaci´on de un nuevo sistema, estas metodolog´ıas buscan incorporar de la forma mas elegante, software previamente desarrollado con el que est´a por construirse[24]. Es por estas razones que se busca contribuir en el desarrollo de software basado en componentes que pueda ser confiable desde el punto de vista formal incluyendo modelos y mecanismos que permitan establecer y evaluar propiedades que mejoren la calidad de software que se desarrolla.

Las arquitecturas de software emergieron con el prop´osito de establecer un mecanismo para entender y caracterizar los sistemas de software a gran escala; de esta forma, se establec´ıa un dise˜no de alto nivel del sistema que pod´ıa ser utilizado como base para la implementaci´on y posterior mantenimiento del sistema, as´ı como un elemento para la reutilizaci´on del software a grandes niveles[25]. En este sentido, se han desarrollado diferentes t´ecnicas para describir una arquitectura de software en diferentes niveles y con diferentes caracter´ısticas, pero en el presente trabajo se analizar´an aquellas que permitan no solo una descripci´on sino tambi´en permitan especificar y chequear propiedades temporales.

Los lenguajes de descripci´on arquitectural (ADL) utilizan diversos mecanismos para espe- cificar propiedades temporales dentro de los que se identifican LTL (Lineal Temporal Logic), CTL (Computation Tree Logic) y CTL* (Computation Tree Logic star), los lenguajes que per- miten especificar propiedades a trav´es de LTL son: SAM, CBabel, Æmilia, CHARMY, Bose, Arcade, LfP, Garlan y AutoFOCUS [25].

Uno de estos m´etodos es Modelo de Arquitectura de Software (Software Architecture Model (SAM)) definido como un marco de trabajo para visualizar, especificar y analizar arquitecturas de software. Este m´etodo permite modelar una arquitectura de forma jer´arquica con lo que permite modularizar el an´alisis, esta jerarqu´ıa se conforma de componentes y conectores en donde estos pueden estar constituidos a su vez de otros componentes y conectores, creando de esta forma subarquitecturas, la ejecuci´on de sus partes se representa a trav´es de una red de Petri. De otro lado, se establecen las restricciones que debe satisfacer la arquitectura, estas restricciones se definen b´asicamente a trav´es de la l´ogica proposicional y si es necesario utiliza la l´ogica temporal para complementarse. Estas restricciones deben ser consistentes en cada uno de los niveles que constituye la arquitectura y subarquitecturas. Adicionalmente, cada uno

2.6. LENGUAJES DE DESCRIPCI ´ON ARQUITECTURAL Y L ´OGICAS TEMPORALES55

de los componentes se puede especificar a trav´es de una f´ormula temporal que describe su comportamiento interno, de esta forma, la l´ogica no solo se utiliza para las propiedades que debe cumplir el sistema sino tambi´en para representar el comportamiento de un componente o conector [26, 27]. A trav´es de este ADL, se especifican los componentes y los conectores de manera independiente y se permite especificar el comportamiento de cada uno a trav´es de f´ormulas. La Figura 2.21 muestra la estructura de un sistema Productor-Consumidor y su especificaci´on.

../../2015II/Tesis_I/SAMArquitectura.png

Figura 2.21: Representaci´on gr´afica de un Sistema Productor-Consumidor en SAM Fuente: [28]

El componente Productor se especifica de la siguiente forma: AG(¬ready−to−produce ∨ AF produced)

El componente Consumidor se especifica de la siguiente forma: AG(¬ready−to−consume ∨ AF consumed)

El conector (tipo Buffer) se especifica de la siguiente manera: AG((empty ∨ f ull)∧(¬(empty ∧ f ull))

AG(¬produced ∨ AF ready−to−consume) Adicionalmente, se especifican restricciones globales AG(¬ready−to−produce ∨ AF consumed)

Primero se verifica cada uno de los componentes y por ´ultimo la configuraci´on completa [28].

Por otro lado CBabel es un ADL que provee las primitivas arquitecturales b´asicas como componentes y puertos , adicionalmente provee el concepto de contratos como elementos prin- cipales. Otro aspecto constitutivo de este lenguaje es la l´ogica de reescritura, que es un marco de trabajo que permite la reescritura o reducci´on de t´erminos dentro de una f´ormula para

reducir la complejidad en su ejecuci´on. De manera general, los componentes son representados por clases, las ejemplificaciones de componentes por objetos, las declaraciones de puertos por mensajes y el est´ımulo entre puestos por paso de mensajes entre los objetos. Un componente

In document Learning in governance: the role of policy entrepreneurs in European climate policy integration (Page 71-75)