On the Specification of Constraints for Dynamic Architectures
aa r X i v : . [ c s . S E ] M a r Under consideration for publication in Formal Aspects of Computing
On the Specification of Constraintsfor Dynamic Architectures
Diego Marmsoler
Technische Universität München, Germany
Abstract.
In dynamic architectures, component activation and connections between components may varyover time. With the emergence of mobile computing such architectures became increasingly important andseveral techniques emerged to support in their specification. These techniques usually allow for the spec-ification of concrete architecture instances. Sometimes, however, it is desired to focus on the specificationof constraints, rather than concrete architectures. Especially specifications of architecture patterns usuallyfocus on a few, important constraints, leaving out the details of the concrete architecture implementing thepattern. With this article we introduce an approach to specify such constraints for dynamic architectures.To this end, we introduce the notion of configuration traces as an abstract model for dynamic architec-tures. Then, we introduce the notion of configuration trace assertions as a formal language based on lineartemporal logic to specify constraints for such architectures. In addition, we also introduce the notion of configuration diagrams to specify interfaces and certain common activation and connection constraints inone single, graphical notation. The approach is well-suited to specify patterns for dynamic architectures andverify them by means of formal analyses. This is demonstrated by applying the approach to specify andverify the Blackboard pattern for dynamic architectures.
Keywords:
Dynamic Architectures; Algebraic Specifications; Architecture Constraints
1. Introduction
A systems architecture describes the components of a system as well as connections between those compo-nents.
Dynamic architectures are architectures in which component activation as well as connections canchange over time [35]. Specifying such architectures remains an active topic of research [15, 8] and over thelast years, several approaches emerged to support in this endeavor [22, 3, 14, 8]. These approaches usuallyfocus on the specification of concrete architecture instances characterized by the following properties: • Concrete model of execution : Component behavior is either specified using some notion of state-machine [2], guarded commands [35], or even stream-processing functions [8].
Correspondence and offprint requests to : Diego Marmsoler, Boltzmannstr. 3, 85748 Garching bei München, GER. e-mail:[email protected] D. Marmsoler • Concrete model of component interaction : Interaction between components is either message-synchronous(for approaches based on CSP [18]), time-synchronous [8], or also action-synchronous [35]. • Concrete model of component activation/deactivation : Component activation/deactivation is either spec-ified by arbitrary components [22] or by a designated component [2]. • Concrete model of reconfiguration : Similarly, connection changes are either implemented by each singlecomponent [22] or again by a designated component [2].While these aspects are important when specifying concrete architecture instances, they play only a sec-ondary role when specifying architectural constraints as it is the case when specifying architectural patterns,for example.Consider, for example, the specification of the Blackboard architecture pattern. In this pattern, a set ofexperts (aka. Knowledge-sources) collaborate through a so-called Blackboard component to collaborativelysolve a complex problem [10, 31, 33]. The pattern requires that for each problem provided by a Blackboardcomponent, eventually an expert exists which is able to handle this problem. In turn, the pattern guaranteesthat a complex problem can be collaboratively solved, even if no single expert exists which can solve theproblem on its own.If we look at this specification, several observations can be made: (i) The specification does not prescribehow a component is implemented as long as it satisfies certain behavioral constraints. (ii) Neither does itconstrain how components communicate as long as they do. (iii) Moreover, it is not specified who createsa component as long as it is created somehow. (iv) Finally, it is not specified how the connections wereestablished as long as they are. Thus, we argue, that traditional architecture specification techniques meetits limits when it comes to the specification of such constraints and that new, more abstract techniques arerequired.To address this problem, we introduce an abstract model of dynamic architectures. Thereby, an architec-ture is modeled as a set of so-called configuration traces which are sequences over architecture configurations.An architecture configuration, on the other hand, consists of a set of active components, connections betweencomponent ports and (important) a valuation of the component ports with messages.Based on this model, we provide a model-theoretic approach to formally specify properties of dynamicarchitectures by means of architecture constraints: (i) First, abstract datatypes are specified by meansof algebraic specifications. (ii) Then, interfaces and component types are specified over these datatypesby means of interface specifications. (iii) Finally, properties can be specified over the interfaces by meansof configuration trace assertions. To facilitate the specification process we also introduce the notion ofconfiguration diagrams as a graphical means to specify interfaces as well as certain common activation andconnection constraints.The approach allows to specify properties of dynamic architectures by means of architecture constraintsand is thus well suited for the specification of patterns for this kind of architectures. To demonstrate this, weevaluate the approach by specifying and verifying the
Blackboard pattern [10, 31, 33] for dynamic architec-tures. Thereby, we identify and formalize the patterns key architecture constraints as a set of configurationtrace assertions and prove its guarantee from the specification.
Fig. 1 provides an overview of our approach to specify properties of dynamic architectures. As a first step, asuitable signature is specified to introduce symbols for sets, functions, and predicates. These symbols formthe primitive entities of the whole specification process: datatype specifications and interface specificationsas well as architecture constraint specifications are based on these symbols.Then, datatypes are specified over the signature. Therefore, so-called datatype assertions are build overdatatype terms to assert the datatypes characteristic properties and provide meaning for the symbols intro-duced in the signature.Interfaces are also directly specified over the signature. Therefore, a set of ports is typed by sorts of thecorresponding signature. Then, an interface is specified by assigning an interface identifier with three sets ofports: local, input, and output ports. Finally, a set of interface assertions is associated with each interfaceidentifier to specify component types, i.e., interfaces with associated global invariants.Finally, architecture constraints can be specified by means of configuration trace assertions over the inter- n the Specification of Constraints for Dynamic Architectures 3
Signature:Sorts, Function, and Predicate SymbolsDatatypeSpecification InterfaceSpecificationArchitectureConstraintsSpecificationFigure 1. Approach to specify properties of dynamic architectures.faces. Configuration trace assertions are a special kind of linear-temporal formulas build over configurationassertions, i.e., assertions over an architecture configuration.
In the following we introduce the Blackboard architecture pattern. It is used as a running example throughoutthe text to illustrate the main concepts and ideas.The Blackboard pattern (as described, for example, by Shaw and Garlan [31], Buschmann et al. [10],and Taylor et al. [33]), is a pattern for dynamic architectures used for collaborative problem solving. In aBlackboard architecture, several experts (aka. Knowledge-sources) collaborate through a central component(aka. Blackboard) to solve a complex problem consisting of several sub-problems.Although the pattern is not too complex (consisting of only two types of components), it incorporatesseveral aspects of dynamic architectures: (i) Knowledge-source components can be activated and deactivatedover time, (ii) connections between the various Knowledge-sources and the Blackboard component can alsochange over time.
The remainder of this article is structured as follows: In Sect. 2 we discuss our model of dynamic architectures.Then, the different modeling techniques to specify datatypes (Sect. 3), interfaces (Sect. 4), and configurationtraces (Sect. 5) are introduced. For each technique we provide a formal description of its syntax as wellas its semantics in terms of the model introduced in Sect. 2. While these techniques already suffice tospecify all kinds of architecture properties, in Sect. 6 we introduce the notion of configuration diagrams as agraphical notation to support in the specification of interfaces and certain common activation and connectionconstraints. In Sect. 7 we demonstrate how a specification in our language can be used to formally reasonabout the specification. To this end, we verify the Blackboard architecture pattern by proving one of itscharacteristic properties from its specification. Finally, we discuss our approach and possible limitationsthereof in Sect. 8. In Sect. 9 we provide related work and conclude with a brief summary in Sect. 10.To not lose track of the various concepts and notations, Sect. 2 − Sect. 6 conclude with a tabular overviewof all the new concepts and notations introduced in the corresponding section.Sect. 12 provides our notation for some general, mathematical concepts. If at any time during the readinga symbol was used but not properly introduced, its definition can be found in this section.
2. A Model of Dynamic Architectures
In the following, we describe our model of dynamic architectures introduced in [25]. It is based on Broy’s
Focus theory [7] and an adaptation of its dynamic extension [8]. An architecture property is thereby modeled
D. Marmsoler as a set of configuration traces which are sequences of architecture configurations that, in turn, consist of aset of active components, valuations of their ports with messages, and connections between their ports.
In our model, components communicate by exchanging messages over ports. Thus, we assume the existenceof sets M and P containing all messages and ports, respectively. Components communicate by sending and receiving messages through ports. This is achieved through thenotion of port-valuation. Roughly speaking, a valuation for a set of ports is an assignment of messages toeach port.
Definition 1 (Port-valuation).
For a set of ports P ⊆ P , we denote by P the set of all possible port-valuations , formally: P def = ( P → ℘ ( M )) . Note that in our model, ports can be valuated by a set of messages, meaning that a component cansend/receive no message, a single message, or multiple messages at each point in time.
In our model, the basic unit of computation is a component. It consists of an identifier, a set of ports and avaluation of ports with messages. Indeed it is rather a snapshot of a component at a certain point in timewith concrete messages on its ports.Thus, we assume the existence of set C id containing all component identifiers. Definition 2 (Component). A component is a 5-tuple ( d, L, I, O, µ ) consisting of: • a component identifier d ∈ C id ; • disjoint sets of local ports L ⊆ P , input ports I ⊆ P , and output ports O ⊆ P ; and • a valuation of its ports µ ∈ L ∪ I ∪ O .The set of all components is denoted by C .For a set of components C ⊆ C , we denote by: • loc ( C ) def = S ( d,L,I,O,µ ) ∈ C ( { d } × L ) the set of component local ports , • in ( C ) def = S ( d,L,I,O,µ ) ∈ C ( { d } × I ) the set of component input ports , • out ( C ) def = S ( d,L,I,O,µ ) ∈ C ( { d } × O ) the set of component output ports , • port ( C ) def = loc ( C ) ∪ in ( C ) ∪ out ( C ) the set of all component ports , and • id ( C ) def = S ( d,L,I,O,µ ) ∈ C ( { d } ) the set of all component identifiers .A set of components C ⊆ C is called healthy if for each ( d, L, I, O, µ ) , ( d ′ , L ′ , I ′ , O ′ , µ ′ ) ∈ C the followingconditions are fulfilled: • a component’s interface is determined by its identifier: d = d ′ = ⇒ L = L ′ ∧ I = I ′ ∧ O = O ′ , (1) • the valuation of the local ports is also determined by a component’s identifier: d = d ′ = ⇒ ∀ p ∈ L : µ ( p ) = µ ′ ( p ) . (2) Note 1 (Well-definedness of Eq. (2) ). Due to Eq. (1) L = L ′ which is why Eq. (2) is indeed well-defined. n the Specification of Constraints for Dynamic Architectures 5 c l = { } l = { C } i = { Z } o = { } i = { A } i = { } Figure 2. Conceptual representation of a component with identifier c , local ports l , l , input ports i , i , i ,output ports o , and corresponding valuations { } , { C } , { Z } , { A } , { } , { } .A healthy set of components C ⊆ C induces mappings to assigning local, input, output, and all ports tocomponent identifier d ∈ id ( C ) : • loc C ( d ) = O ⇐⇒ ∃ I, O ⊆ P : ( d, L, I, O ) ∈ C , • in C ( d ) = I ⇐⇒ ∃ O, L ⊆ P : ( d, L, I, O ) ∈ C , • out C ( d ) = O ⇐⇒ ∃ I, L ⊆ P : ( d, L, I, O ) ∈ C , and • port C ( d ) def = loc C ( d ) ∪ in C ( d ) ∪ out C ( d ) .Moreover, it induces a mapping lV C to access the valuation of a component’s local ports: lV C ( d )( p ) = M ⇐⇒ ∃ I, O, L ⊆ P , µ ∈ L ∪ I ∪ O :( d, L, I, O, µ ) ∈ C ∧ µ ( p ) = M . (3)
Note 2 (Well-definedness of loc C , in C , out C and lV C ( d ) ). While Eq. (1) guarantees that loc C , in C , and out C are well-defined, Eq. (2) guarantees that lV C ( d ) is well-defined.Note that a healthy set of components does restrict only the interface of components and the port-valuations of its local ports. However, there may be several components with the same identifier but differentvaluations of its input and output ports. Thus, it is indeed possible to have two different components ( d, L, I, O, µ ) , ( d, L, I, O, µ ′ ) in a healthy set of components, as long as there exists a port p ∈ I ∪ O , suchthat µ ( p ) = µ ′ ( p ) .An important property of healthy is, that it is preserved under the subset relation. Property 1 (Subset preserves healthiness).
For a healthy set of components C , each subset C ′ ⊆ C isagain healthy. Proof.
Assume C is healthy and let C ′ ⊆ C . Moreover, let c = ( d, L, I, O, µ ) , c ′ = ( d ′ , L ′ , I ′ , O ′ , µ ′ ) ∈ C ′ . Wefirst show d = d ′ = ⇒ L = L ′ ∧ I = I ′ ∧ O = O ′ . Thus, assume d = d ′ and have L = L ′ ∧ I = I ′ ∧ O = O ′ by Eq. (1), since c, c ′ ∈ C . Now we show d = d ′ = ⇒ ∀ p ∈ L : µ ( p ) = µ ′ ( p ) . Thus, assume d = d ′ , let p ∈ L and have µ ( p ) = µ ′ ( p ) by Eq. (2), since c, c ′ ∈ C . Example 1 (Component).
Assuming M consists of all characters and numbers, c ∈ C id , and l , l , i , i , i , o ∈ P . Figure 2 shows a conceptual representation of a component ( d, L, I, O, µ ) , with: • identifier: d = c , • local ports: L = { l , l } , • input ports: I = { i , i , i } , • output ports: O = { o } , and • valuation µ defined as follows: – µ ( l ) = { } and µ ( l ) = { C } , – µ ( i ) = { Z } , µ ( i ) = { A } , and µ ( i ) = { } ; and – µ ( o ) = { } . Architecture properties are modeled as sets of configuration traces which are sequences over architectureconfigurations . D. Marmsoler c l = { A } o = { } i = { } o = { A } o = { } c l = { } l = { C } i = { Z } o = { } i = { A } i = { } c l = { F } i = { X } o = { } i = { } o = { } Figure 3. Architecture configuration consisting of 3 components and a connection between ports ( c , i ) and ( c , o ) , ( c , i ) and ( c , o ) , and ( c , i ) and ( c , o ) . In our model, an architecture configuration connects ports of active components.
Definition 3 (Architecture configuration). An architecture configuration over a healthy set of compo-nents C ⊆ C is a pair ( C ′ , N ) , consisting of: • a set of active components C ′ ⊆ C and • a connection of their ports N : in ( C ′ ) → ℘ ( out ( C ′ )) .We require the valuation of active components of an architecture configuration to be determined by acomponent’s identifier: ∀ ( d, L, I, O, µ ) , ( d ′ , L ′ , I ′ , O ′ , µ ′ ) ∈ C ′ : d = d ′ = ⇒ µ = µ ′ . (4)Thus, we can define a function to obtain the valuation for a component in an architecture configuration bymeans of its identifier, characterized by the following equation: val ( C ′ ,N ) ( d )= µ ⇐⇒ ∃ L,I,O ⊆ P : ( d,L,I,O,µ ) ∈ C ′ . (5) Note 3 (Well-definedness of function val ( C ′ ,N ) ). Function val ( C ′ ,N ) is well-defined by Eq. (5), due toEq. (4).For an architecture configuration k = ( C ′ , N ) , we denote by: in o ( k ) def = (cid:8) p ∈ in ( C ′ ) | N ( p ) = ∅ (cid:9) , (6)the set of open input ports .Moreover, we require connected ports to be consistent in their valuation, that is, if a component providesmessages at its output ports, these messages are transferred to the corresponding, connected input ports: ∀ ( d i , p i ) ∈ in o (( C ′ , N )) : (7) val ( C ′ ,N ) ( d i )( p i ) = [ ( d o ,p o ) ∈ N ( d i ,p i ) val ( C ′ ,N ) ( d o )( p o ) . The set of all possible architecture configurations over a healthy set of components C ⊆ C is denoted by K ( C ) .Note that a connection is modeled as a set-valued function from component input ports to component outputports, meaning that input/output ports can be connected to several output/input ports, respectively, andnot every input/output port needs to be connected to an output/input port. n the Specification of Constraints for Dynamic Architectures 7 c l = { A } o = { } i = { } o = { A } o = { } c l = { } l = { C } i = { Z } o = { } i = { A } i = { } c l = { F } i = { X } o = { } i = { } o = { } k , c l = { A } o = { } i = { } o = { G } o = { } c l = { } l = { C } i = { G } o = { } i = { F } i = { } k , c l = { A } o = { } i = { } o = { K } o = { } c l = { } l = { C } i = { R } o = { } i = { W } i = { } c l = { } i = { T } o = { } i = { } o = { B } k , Figure 4. First three architecture configurations k , k , and k , of a configuration trace. Example 2 (Architecture configuration).
Assuming M consists of all characters and numbers, c , c , c ∈ C id , and l , l , i , i , i , o , o , o ∈ P . Figure 3 shows an architecture configuration ( C ′ , N ) , with: • active components C ′ = { C , C , C } , where C , for example, is shown in Ex. 1, and • connection N defined as follows: – N (( c , i )) = { ( c , o ) } , – N (( c , i )) = { ( c , o ) } , – N (( c , i )) = { ( c , o ) } , and – N (( c , i )) = N (( c , o )) = N (( c , i )) = N (( c , o )) = N (( c , i )) = N (( c , o )) = ∅ .Moreover, due to the healthiness condition, an active component within an architecture configuration isfully determined by its identifier. Property 2.
For a healthy set of components C ⊆ C , we have ∀ ( C ′ , N ) ∈ K ( C ) , ∀ c, c ′ ∈ C ′ : [ c ] = [ c ′ ] = ⇒ c = c ′ . (8) Proof.
Assume c = ( d, L, I, O, µ ) and c = ( d ′ , L ′ , I ′ , O ′ , µ ′ ) and d = d ′ . Then, by Eq. (1), we have that L = L ′ , I = I ′ , and O = O ′ . Moreover, by Eq. (4), we have µ = µ ′ . Thus, we can conclude c = c ′ . A configuration trace consists of a series of configuration snapshots of an architecture during system execu-tion.
Definition 4 (Configuration trace). A configuration trace over a healthy set of components C ⊆ C is amapping N → K ( C ) . The set of all configuration traces over C is denoted by R ( C ) . Example 3 (Configuration trace).
Figure 4 shows a conceptual representation of a configuration trace t ∈ R ( C ) with corresponding architecture configurations t (0) = k , t (1) = k , and t (2) = k . Architectureconfiguration t , e.g., is shown in Ex. 2.Note that an architecture property is modeled as a set of configuration traces rather than just one singletrace. This is due to the fact that input to an architecture is usually nondeterministic and the appearanceand disappearance of components, as well as the reconfiguration of an architecture, may indeed depend onthe input provided to it.Moreover, note that our notion of architecture is dynamic in the following sense: (i) components mayappear and disappear over time and (ii) connections may change over time. Table 1 provides a brief overview of the main concepts introduced in this section. For each concept it providesa brief description thereof and related notation.
D. Marmsoler
Table 1. Overview of concepts for dynamic architectures.
Concept
Description Related Notation message atomic data entity M port means to exchange messages P port-valuation assignment of messages to set of ports P P component identifier identifier for components C id component identifier, local/input/output ports, and port-valuations C local, input, output, all ports of components C loc ( C ) , in ( C ) , out ( C ) , port ( C ) identifiers of components C id ( C ) healthy set of components set of components with interface and valuations of lo-cal ports determined by component identifiers local, input, output, and all ports of component withidentifier d of healthy set C loc C ( d ) , in C ( d ) , out C ( d ) , port C ( d ) valuation of local ports of component with identifier d of healthy set C lV C ( d ) architecture configuration set of active components and connections betweentheir ports over a healthy set of components C K ( C ) valuation of component with identifier d of architec-ture configuration k val k ( d ) configuration trace sequence of architecture configurations over a set ofhealthy components C R ( C )
3. Datatype Specifications
Datatypes are specified by means of algebraic specifications [6, 36].Thus, a datatype specification is expressed over a signature by means of a set of so-called datatypeassertions, i.e., predicate-logic formulas over datatype terms. Meaning is provided in terms of a correspondingalgebra, i.e., concrete mathematical structures for the sorts and functions of the corresponding signature.
A signature determines the symbols used throughout the specification. Sorts are symbols representing certainsets of messages while function symbols and predicate symbols, represent functions, and predicates over thosesets.
Definition 5 (Signature). A signature is a triple Σ = (
S, F, B ) , consisting of: • a set of sorts S , • a set of function symbols F and predicate symbols B with corresponding assignments sort : F → S n and sort : B → S n , with: – F n / B n denoting the set of function/predicate symbols with arity n ∈ N , – sort n ( f ) / sort n ( b ) denoting the sort of the n -th parameter (with n ∈ N + ) of function symbol f ∈ F /predicate symbol b ∈ B , and – sort ( f ) denoting the sort of the return value of function symbol f ∈ F . The meaning of the symbols introduced by a signature is determined by an algebra. An algebra consists ofconcrete sets for each sort-symbol and corresponding functions and predicates for the function-symbols andpredicate-symbols, respectively. Moreover, mappings associate each symbol with the corresponding interpre-tation. n the Specification of Constraints for Dynamic Architectures 9
Datatype terms: syntax v ∈ d V s = ⇒ v ∈ sd T (Σ , d V ) ,f ∈ F = ⇒ f ∈ sd T (Σ , d V ) [for sort ( f ) = s ] ,f ∈ F n +1 ∧ t ∈ s d T (Σ , d V ) , · · · , t n +1 ∈ s n +1 d T (Σ , d V ) = ⇒ f ( t , · · · , t n +1 ) ∈ sd T (Σ , d V ) [for n ∈ N , sort ( f ) = s ,and sort ( f ) = s , · · · , sort n + ( f ) = s n +1 ] . Figure 5. Inductive definition of datatype terms sd T (Σ , d V ) of sort s ∈ S over signature Σ = (
S, F, B ) anddatatype variables d V = ( d V s ) s ∈ S .Datatype terms: semantics J v K ιA def = ι s ( v ) [for v ∈ d V s ] , J f K ιA def = β ( f ) [for function symbol f ∈ F ] , J f ( t , · · · , t n ) K ιA def = β ( f )( J t K ιA , · · · , J t n K ιA ) [for function symbol f ∈ F n +1 ] . Figure 6. Recursive definition of datatype semantic function for datatype terms sd T (Σ , d V ) of sort s ∈ S with signature Σ = (
S, F, B ) , algebra A = ( S ′ , F ′ , B ′ , α, β, γ ) ∈ A (Σ) , and datatype variable assignment ι = ( ι s ) s ∈ S . Definition 6 (Algebra). An algebra for a signature ( S, F, B ) is a -tuple ( S ′ , F ′ , B ′ , α, β, γ ) , consisting of: • a set of non-empty sets of messages S ′ ⊆ ℘ ( M ) ; • a set of functions F ′ and predicates B ′ for symbols F and B , respectively; and • interpretations α : S → S ′ , β : F → F ′ , and γ : B → B ′ .The set of all possible algebras over signature Σ is denoted by A (Σ) . Terms of datatype specifications are build over a given signature and corresponding datatype variables (afamily of disjoint sets of variables d V = ( d V s ) s ∈ S with d V s denoting a set of variables of sort s ∈ S ). Definition 7 (Datatype term).
The set of all datatype terms of sort s ∈ S over a signature Σ = (
S, F, B ) and datatype variables d V is the smallest set sd T (Σ , d V ) , satisfying the equations in Fig. 5. The set ofall datatype terms (of all sorts) over a signature Σ = (
S, F, B ) and datatype variables d V is denoted by d T (Σ , d V ) .Roughly speaking, a datatype term is the application of function symbols of a signature to other functionsymbols or variables. Thereby, the sorts of the parameters have to be consistent with the sorts of thecorresponding function symbol.The semantics of datatype terms is defined over an algebra A = ( S ′ , F ′ , B ′ , α, β, γ ) and corresponding datatype variable assignment (a family of mappings ι = ( ι s ) s ∈ S with ι s : d V s → α ( s ) for each sort s ∈ S ).In the following we denote with I d V A the set of all datatype variable assignments for datatype variables d V in algebra A . Definition 8 (Datatype semantic function).
The datatype semantic function for datatype terms d T (Σ , d V ) with signature Σ = (
S, F, B ) and datatype variables d V , over algebra A ∈ A (Σ) and datatypevariable assignment ι ∈ I d V A is the mapping J _ K ιA : sd T (Σ , d V ) → α ( s ) (for each sort s ∈ S ), characterized bythe equations in Fig. 6. Datatype assertions: syntax b ∈ B = ⇒ b ∈ d Γ(Σ , d V ) ,b ∈ B n +1 ∧ t ∈ s d T (Σ , d V ) , · · · , t n +1 ∈ s n +1 d T (Σ , d V ) = ⇒ b ( t , · · · , t n +1 ) ∈ d Γ(Σ , d V ) [for n ∈ N and sort ( b ) = s , · · · , sort n + ( b ) = s n +1 ] ,t, t ′ ∈ sd T (Σ , d V ) = ⇒ t = t ′ ∈ d Γ(Σ , d V ) ,E ∈ d Γ(Σ , d V ) = ⇒ ¬ E ∈ d Γ(Σ , d V ) ,E, E ′ ∈ d Γ(Σ , d V ) = ⇒ E ∧ E ′ , E ∨ E ′ , E = ⇒ E ′ , E ⇐⇒ E ′ ∈ d Γ(Σ , d V ) ,E ∈ d Γ(Σ , d V ) ∧ x ∈ d V s = ⇒ ∀ x. E ∈ d Γ(Σ , d V ) ∧∃ x. E ∈ d Γ(Σ , d V ) [for some s ∈ S ] . Figure 7. Inductive definition of datatype assertions d Γ(Σ , d V ) over signature Σ = (
S, F, B ) and datatypevariables d V = ( d V s ) s ∈ S .Datatype assertions: semantics A, ι | = b ⇐⇒ γ ( b ) [for b ∈ B ] ,A, ι | = b ( t , · · · , t n ) ⇐⇒ γ ( b )( J t K ιA , · · · , J t n K ιA ) [for b ∈ B n +1 ] ,A, ι | = t = t ′ ⇐⇒ J t K ιA = J t ′ K ιA ,A, ι | = E ∧ E ′ ⇐⇒ A, ι | = E ∧ A, ι | = E ′ ,A, ι | = E ∨ E ′ ⇐⇒ A, ι | = E ∨ A, ι | = E ′ ,A, ι | = E = ⇒ E ′ ⇐⇒ A, ι | = E = ⇒ A, ι | = E ′ ,A, ι | = E ⇐⇒ E ′ ⇐⇒ A, ι | = E ⇐⇒ A, ι | = E ′ ,A, ι | = ∃ x. E ⇐⇒ ∃ x ′ ∈ α ( s ): A, ι [ s : x x ′ ] | = E [for s ∈ S and x ∈ d V s ] ,A, ι | = ∀ x. E ⇐⇒ ∀ x ′ ∈ α ( s ): A, ι [ s : x x ′ ] | = E [for s ∈ S and x ∈ d V s ] . Figure 8. Recursive definition of models relation for datatype assertions d Γ(Σ , d V ) with signature Σ =(
S, F, B ) , algebra A = ( S ′ , F ′ , B ′ , α, β, γ ) ∈ A (Σ) , and datatype variable assignment ι = ( ι s ) s ∈ S .Thus, the semantics of a datatype term is given by a function assigning a value of the correspondingalgebra to each term. Datatype assertions are build over datatype terms by the common logical operators.
Definition 9 (Datatype assertion).
The set of all datatype assertions over a signature Σ and datatypevariables d V is the smallest set d Γ(Σ , d V ) satisfying the equations in Fig. 7.Thus, a datatype assertion is obtained by applying the common logical operators to datatype terms orpredicate symbols. The semantics of datatype assertions is defined over an algebra. Definition 10 (Datatype models relation).
The datatype models relation for datatype assertions d Γ(Σ , d V ) with signature Σ , datatype variables d V , and algebra A ∈ A (Σ) is the relation A, _ | = _ ⊆I d V A × d Γ(Σ , d V ) characterized by the equations in Fig. 8. A datatype assertion ϕ ∈ d Γ(Σ , d V ) is valid for analgebra A ∈ A (Σ) iff there exists a datatype variable assignment ι ∈ I d V A , such that A, ι | = ϕ . An algebra A ∈ A (Σ) is a model for datatype assertion ϕ ∈ d Γ(Σ , d V ) , written A | = ϕ iff A, ι | = ϕ for each ι ∈ I d V A . Analgebra A ∈ A (Σ) is a model for a set of datatype assertions Φ ⊆ d Γ(Σ , d V ) , written A | = Φ iff A | = ϕ foreach ϕ ∈ Φ . n the Specification of Constraints for Dynamic Architectures 11 DTSpec
Name import dtSpec sort
Sort1 , Sort2 symbol1 : Sort1 symbol2 : Sort1 → Sort2 var var1 , var2 : Sort1 var3 : Sort2 assertion1 ( symbol1 , var1 , var2 , var4 ) assertion2 ( symbol1 , symbol2 , var1 , var4 ) Figure 9. Datatype specification template with corresponding sorts, datatype variables, symbols for functionsand predicates, and datatype assertions.Thus, the semantics is given by a relation over datatype assertions and algebras with a correspondingdatatype variable assignment satisfying the assertions.
Signatures introduce the basic symbols used throughout the whole specification process and datatype spec-ifications provide meaning to these symbols.
Definition 11 (Datatype specification).
A datatype specification over a signature
Σ = (
S, F, B ) and afamily of datatype variables d V = ( d V s ) s ∈ S is a set of datatype assertions Φ ⊆ d Γ(Σ , d V ) .Signatures and corresponding datatype specifications can be expressed by means of datatype specificationtemplates (Fig. 9). Each template has a name and can import other datatype specification templates bymeans of their name. Sorts are introduced by a list of names at the beginning of the template. Then, alist of variables for the different sorts are defined and function/predicate symbols are introduced with thecorresponding types. Finally, a list of datatype assertions is specified to describe the characteristic propertiesof a datatype. Blackboard architectures work with problems and solutions for these problems. Figure 10 provides thecorresponding datatype specification template. We denote with
PROB the set of all problems and with
SOL the set of all solutions. Complex problems consist of subproblems which can be complex themselves. Tosolve a problem, its subproblems have to be solved first. Therefore, we assume the existence of a subproblemrelation ≺ ⊆
PROB × PROB . For complex problems, this relation may not be known in advance. Indeed, one ofthe benefits of a Blackboard architecture is that a problem can be solved also without knowing this relationin advance. However, the subproblem relation has to be well-founded (Eq. (9)) for a problem to be solvable.In particular, we do not allow cycles in the transitive closure of ≺ . While there may be different approachesto solve a certain problem (i.e. several ways to split a problem into subproblems), we assume (without lossof generality) that the final solution for a problem is always unique. Thus, we assume the existence of afunction solve : PROB → SOL which assigns the correct solution to each problem. Note, however, that thisfunction is not known in advance and it is one of the reasons of using this pattern to calculate this function. A partial order is well-founded iff it does not contain any infinite decreasing chains. A detailed definition can be found e.g.in [19].2 D. Marmsoler
DTSpec
ProbSol import
SET sort
PROB , SOL ≺ : PROB × PROB solve : PROB → SOL well − founded ( ≺ ) (9)Figure 10. Blackboard datatype specification template introducing sorts, function symbols, and predicatesymbols for Blackboard architectures.Table 2. Overview of concepts for datatype specifications. Concept
Description Related Notation signature sorts, function/predicate symbols Σ n -ary function/predicate symbols F n / B n sort of n -th parameter of function symbol f / predicate symbol b sort n ( f ) / sort n ( b ) sort of return value of function symbol f sort ( f ) algebra sets, functions, predicates, and corresponding mappings for asignature Σ A (Σ) datatype variable variable for datatype elements of sort s d V s datatype variable assignment assignment of elements of an algebra A to a set of datatypevariables d V I d V A datatype term term over a signature Σ and datatype variables d V sd T (Σ , d V ) , d T (Σ , d V ) datatype semantic function assigns elements of an algebra A to datatype terms under acertain datatype variable assignment ι J _ K ιA datatype assertion formula over datatype terms with corresponding signature Σ and datatype variables d V d Γ(Σ , d V ) datatype models relation relates datatype assertions with algebras and correspondingdatatype variable assignment ι _ , ι | = _ / _ | = _datatype specification set of datatype assertions Φ datatype specification template structured technique to specify datatypes graphical To conclude, Tab. 2 provides a brief overview of the main concepts introduced in this section. For eachconcept it provides a brief description and related notation.
4. Interface Specifications
Interfaces are specified over a given signature and declare a set of local, input, and output ports for a set ofinterface identifiers. Moreover, an interface specification allows to specify valuations of local ports by meansof interface assertions formulated over interface terms.Thus, in the following, we postulate the existence of the set of all port identifiers P id . Ports are specified by means of port specifications which declare a set of port identifiers and a correspondingtyping.
Definition 12 (Port specification). A port specification over signature Σ = (
S, F, B ) is a pair ( P, t p ) ,consisting of: n the Specification of Constraints for Dynamic Architectures 13 Interface terms: syntax v ∈ d V s = ⇒ v ∈ si T d V (Σ , Q ) ,f ∈ F = ⇒ f ∈ si T d V (Σ , Q ) [for sort ( f ) = s ] ,f ∈ F n +1 ∧ t ∈ s i T d V (Σ , Q ) , · · · , t n +1 ∈ s n +1 i T d V (Σ , Q ) = ⇒ f ( t , · · · , t n +1 ) ∈ si T d V (Σ , F ) [for n ∈ N , sort ( f ) = s ,and sort ( f ) = s , · · · , sort n + ( f ) = s n +1 ] ,p ∈ [ Q ] ∪ [ Q ] ∪ [ Q ] = ⇒ p ∈ si T d V (Σ , Q ) [ if t p ( p ) = s ] . Figure 11. Inductive definition of interface terms si T d V (Σ , Q ) of sort s ∈ S over signature Σ = (
S, F, B ) ,interface Q , and datatype variables d V . • a set of port identifiers P ⊆ P id and • a mapping t p : P → S assigning a sort to each port identifier.The set of all port specifications over signature Σ is denoted by S p (Σ) .Interfaces are build over a given port specification. They consist of a set of local, input, and output portidentifiers. Definition 13 (Interface). An interface over port specification ( P, t p ) ∈ S p (Σ) is a triple ( L i , I i , O i ) ,consisting of disjoint sets for: • local port identifiers L i ⊆ P , • input port identifiers I i ⊆ P , and • output port identifiers O i ⊆ P .The set of all interfaces over port specification S p is denoted by I ( S p ) .An interface can be interpreted by a component, relating port identifiers of the interface with concreteports of the component. Definition 14 (Interface interpretation). An interface interpretation for an interface ( L i , I i , O i ) ∈ I ( S p ) over port specification S p = ( P, t p ) ∈ S p (Σ) with signature Σ in an algebra A = ( S ′ , F ′ , B ′ , α, β, γ ) is a 4-tuple ( c, δ l , δ i , δ o ) , consisting of: • a component c = ( d, L, I, O, µ ) ∈ C , and • port interpretations δ l : L ↔ L i , δ i : I ↔ I i , and δ o : O ↔ O i , for local, input, and output ports,respectively.Thereby, we require that the valuations of the component ports satisfy the typing constraints induced bythe corresponding port specification: ∀ p ∈ L : µ ( p ) ∈ α ( t p ( δ l ( p ))) , ∀ p ∈ I : µ ( p ) ∈ α ( t p ( δ i ( p ))) , and ∀ p ∈ O : µ ( p ) ∈ α ( t p ( δ o ( p ))) . (10)The set of all interface interpretations of interface Q under algebra A is denoted by Q ( Q, A ) . Interface terms are build over a given interface, corresponding signature, and datatype variables.
Definition 15 (Interface term).
The set of all interface terms of sort s ∈ S of signature Σ = (
S, F, B ) over an interface Q ∈ I ( S p ) with S p ∈ S p (Σ) and datatype variables d V is the smallest set si T d V (Σ , Q ) satisfying the equations of Fig. 11. The set of all interface terms of all sorts is denoted by i T d V (Σ , Q ) . Interface terms: semantics J v K j ( A,ι ) def = ι s ( v ) [for v ∈ d V s ] , J f K j ( A,ι ) def = β ( f ) [for function symbol f ∈ F ] , J f ( t , · · · , t n ) K j ( A,ι ) def = β ( f )( J t K ιA , · · · , J t n K ιA ) [for function symbol f ∈ F n +1 ] , J p K j ( A,ι ) def = µ (( δ i ) − ( p )) [for p ∈ I i ] , J p K j ( A,ι ) def = µ (( δ o ) − ( p )) [for p ∈ O i ] . Figure 12. Recursive definition of interface semantic function for interface terms si T d V (Σ , Q ) of sort s ∈ S with signature Σ = (
S, F, B ) , interface Q = ( L i , I i , O i ) , datatype variables d V , algebra A =( S ′ , F ′ , B ′ , α, β, γ ) ∈ A (Σ) and corresponding datatype variable assignments ι ∈ I d V A , and interface in-terpretation j = ( c, δ l , δ i , δ o ) ∈ Q ( Q, A ) .Interface assertions: syntax b ∈ B = ⇒ b ∈ i Γ d V (Σ , Q ) ,b ∈ B n +1 ∧ t ∈ s i T d V (Σ , Q ) , · · · , t n +1 ∈ s n +1 i T d V (Σ , Q ) = ⇒ b ( t , · · · , t n +1 ) ∈ i Γ d V (Σ , Q ) [for n ∈ N and sort ( b ) = s , · · · , sort n + ( b ) = s n +1 ] ,t, t ′ ∈ c T c V d V (Σ , S i ) = ⇒ t = t ′ ∈ i Γ d V (Σ , Q ) ,E ∈ i Γ d V (Σ , Q ) = ⇒ ¬ E ∈ i Γ d V (Σ , Q ) ,E, E ′ ∈ i Γ d V (Σ , Q ) = ⇒ E ∧ E ′ , E ∨ E ′ , E = ⇒ E ′ , E ⇐⇒ E ′ ∈ i Γ d V (Σ , Q ) ,E ∈ i Γ d V (Σ , Q ) ∧ x ∈ d V s = ⇒ ∀ x. E ∈ i Γ d V (Σ , Q ) ∧∃ x. E ∈ i Γ d V (Σ , Q ) [for some s ∈ S ] . Figure 13. Inductive definition of interface assertions i Γ d V (Σ , Q ) over signature Σ = (
S, F, B ) , interface Q ,and datatype variables d V .The semantics of interface terms is defined over a given algebra, corresponding datatype variable assign-ment, and interface interpretation. It is given in terms of a function assigning a value of the correspondingalgebra to each interface term. Definition 16.
Interface semantic function The interface semantic function for interface terms i T d V (Σ , Q ) over signature Σ = (
S, F, B ) and interface Q in algebra A = ( S ′ , F ′ , B ′ , α, β, γ ) ∈ A (Σ) with correspondingdatatype variable assignment ι ∈ I d V A , and interface interpretation j = ( c, δ l , δ i , δ o ) ∈ Q ( Q, A ) is the function J _ K j ( A,ι ) : si T d V (Σ , Q ) → α ( s ) (for each sort s ∈ S ), characterized by the equations in Fig. 12. Interface assertions are build by the common logical operators over interface terms. They are formulatedover a given interface and datatype variables.
Definition 17 (Interface assertion).
The set of all interface assertions over a signature Σ , interface Q ,and datatype variables d V is the smallest set i Γ d V (Σ , Q ) satisfying the equations in Fig. 13.The semantics of interface assertions is given by relating interface assertions with corresponding interfaceinterpretations satisfying the assertions. n the Specification of Constraints for Dynamic Architectures 15 Interface assertions: semantics j | = ιA b ⇐⇒ γ ( b ) [for b ∈ B ] ,j | = ιA b ( t , · · · , t n ) ⇐⇒ γ ( b )( J t K ιA , · · · , J t n K ιA ) [for b ∈ B n +1 ] ,j | = ιA t = t ′ ⇐⇒ J t K ιA = J t ′ K ιA ,j | = ιA E ∧ E ′ ⇐⇒ j | = ιA E ∧ j | = ιA E ′ ,j | = ιA E ∨ E ′ ⇐⇒ j | = ιA E ∨ j | = ιA E ′ ,j | = ιA E = ⇒ E ′ ⇐⇒ j | = ιA E = ⇒ j | = ιA E ′ ,j | = ιA E ⇐⇒ E ′ ⇐⇒ j | = ιA E ⇐⇒ j | = ιA E ′ ,j | = ιA ∃ x. E ⇐⇒ ∃ x ′ ∈ α ( s ): j | = ι [ s : x x ′ ] A E [for s ∈ S and x ∈ d V s ] ,j | = ιA ∀ x. E ⇐⇒ ∀ x ′ ∈ α ( s ): j | = ι [ s : x x ′ ] A E [for s ∈ S and x ∈ d V s ] . Figure 14. Recursive definition of models relation for interface assertions i Γ d V (Σ , Q ) over signature Σ =(
S, F, B ) , interface Q , and datatype variables d V over algebra A ∈ A (Σ) with corresponding datatypevariable assignment ι = ( ι s ) s ∈ S . Definition 18 (Interface models relation).
The interface models relation for interface assertions i Γ d V (Σ , Q ) over signature Σ , datatype variables d V , and interface Q ∈ I ( S p ) with S p ∈ S p (Σ) in al-gebra A ∈ A (Σ) with corresponding datatype variable assignment ι ∈ I d V A is the relation _ | = ιA _ ⊆Q ( Q, A ) × i Γ d V (Σ , Q ) characterized by the equations in Fig. 14. An interface assertion γ ∈ i Γ d V (Σ , Q ) is valid for algebra A ∈ A (Σ) and interface interpretation j ∈ J ( Q, A ) iff there exists a correspondingdatatype variable assignment ι ∈ I d V A , such that j | = ιA γ . Interface interpretation j ∈ J ( Q, A ) is a model for γ ∈ i Γ d V (Σ , Q ) , written j | = A γ iff for each corresponding datatype variable assignment ι ∈ I d V A we have j | = ιA γ . Interface interpretation j ∈ J ( Q, A ) is a model for a set of interface assertions Γ ⊆ i Γ d V (Σ , Q ) ,written j | = A Γ iff j | = A γ for each γ ∈ Γ . Interfaces are specified by providing a set of interface identifiers. Then, each identifier is associated with aninterface (i.e., sets of local, input and output ports). Finally, a sets of interface assertions is specified for eachinterface identifier.Thus, in the following, we postulate the existence of the set of all interface identifiers I id . Definition 19 (Interface specification). An interface specification over port specification S p ∈ S p (Σ) with signature Σ is a pair ( N, Q ) , consisting of: • a set of interface identifiers N ⊆ I id , • a family of corresponding interfaces ( Q i ) i ∈ N with interface Q i ∈ I ( S p ) for each interface identifier i ∈ N .The set of all interface specifications over port specification S p ∈ S p (Σ) is denoted by S i ( S p ) .For an interface specification S i = ( N, Q ) , we denote by: • loc ( S i ) def = S i ∈ N ( i × [ Q i ] ) the set of interface local ports , • in ( S i ) def = S i ∈ N ( i × [ Q i ] ) the set of interface input ports , • out ( S i ) def = S i ∈ N ( i × [ Q i ] ) the set of interface output ports , and • port ( S i ) def = loc ( S i ) ∪ in ( S i ) ∪ out ( S i ) the set of all interface ports .Note that an interface specification actually specifies a set of interfaces, rather than just one single interface.Moreover, it allows for reuse of ports through several interfaces. Thus, if a port is specified once, it can beused to specify several, different interfaces. PSpec
Name uses dtSpec p : Sort1 q : Sort2 c : Sort3
Figure 15. Port specification template defining three ports and corresponding sorts.Interface specifications can be interpreted by a set of components with corresponding interfaces.
Definition 20 (Interface specification interpretation). An interface specification interpretation foran interface specification ( N, Q ) ∈ S i ( S p ) over port specification S p ∈ S p (Σ) under an algebra A =( S ′ , F ′ , B ′ , α, β, γ ) ∈ A (Σ) is a family J = ( J i ) i ∈ N , with J i ⊆ Q ( Q i , A ) being the biggest set of interfaceinterpretations for interface identifier i ∈ N , such that • components with the same identifier belong only to one interface: (cid:16) \ i ∈ N [ ( c,δ l ,δ i ,δ o ) ∈ J i { [ c ] } (cid:17) = ∅ . (11) • the set of all components S i ∈ N S ( c,δ l ,δ i ,δ o ) ∈ J i { c } is a healthy set of components.We introduce a function to return the set of all components for a certain interface identifier: cmp i ( J ) = [ ( c,δ l ,δ i ,δ o ) ∈ J i { c } . (12)With cmp ( J ) = S i ∈ N cmp i ( J ) we denote the set of all components of all interface identifiers.Note that cmp ( J ) is a healthy set of component which allows us to apply all the functions for healthy setsof components introduced in Def. 2 to cmp ( J ) . The set of all possible interface specification interpretationsfor interface specification S i over algebra A is denoted by J ( S i , A ) . Remember the healthiness condition (Eq. (2)) requiring local port valuations not to change for components.Once fixed, those ports do not change their value during the execution of an architecture and are thus away to parametrize components. The annotated interfaces become component types since they enrich aninterface with certain semantic constraints.The parametrization step is done during interface specification since interface assertions are the only wayto determine/use local port valuations. It is demonstrated in the running example for Knowledge-sourcecomponents which are parametrized by a set of problems they are able to solve.
Component types can be specified by means of port specification templates and interface specification tem-plates. Fig. 15, for example, shows a port specification templates declaring 3 ports and corresponding sorts.Fig. 16 shows a corresponding interface specification template. Each specification has a name with corre-sponding input, output, and local ports and may use some datatype specifications. Then, a list of variablesand corresponding sorts is specified. Finally, a list of interface assertions can be specified over the ports andvariables.Sometimes it is convenient to combine a port and interface specification into a single interface specificationtemplate. Fig. 16, e.g., declares an additional port p and corresponding sort. A Blackboard architecture consists of a Blackboard component and several Knowledge-source components. n the Specification of Constraints for Dynamic Architectures 17
ISpec
Name based on pSpec uses dtSpec loc : c in : p out : qp : Sort1 var aVar : Sort4 someAxiom ( p, q, c , aVar ) Figure 16. Interface specification template consisting of a port specification and definitions for variables aswell as interface assertions.
PSpec
Blackboard uses
ProbSol r p : PROB × ℘ ( PROB ) n s : PROB × SOL o p : PROP c s : PROB × SOL
Figure 17. Blackboard port specification.
A Blackboard (BB) component is used to capture the current state on the way to a solution of the originalproblem. Its state consists of all currently open subproblems and solutions for already solved subproblems.A BB expects two types of input: 1. a problem p ∈ PROB which a Knowledge-source is able to solve,together with a set of subproblems P ⊆ PROB the Knowledge-source requires to be solved before solving theoriginal problem p , 2. a problem p ∈ PROB solved by a Knowledge-source, together with the correspondingsolution s ∈ SOL . A BB returns two types of output: 1. a set P ⊆ PROB which contains all the problems tobe solved, 2. a set of pairs PS ⊆ PROB × SOL containing solved problems and the corresponding solutions.
A Knowledge-source (KS) component is a domain expert able to solve problems in that domain. It may lackexpertise of other domains. Moreover, it can recognize problems which it is able to solve and subproblemswhich have to be solved first by other KSs.A KS expects two types of input: 1. a set P ⊆ PROB which contains all the problems to be solved, 2. a setof pairs PS ⊆ PROB × SOL containing solutions for already solved problems. A KS returns one of two types ofoutput: 1. a problem p ∈ PROB which it is able to solve together with a set of subproblems P ⊆ PROB whichit requires to be solved before solving the original problem, 2. a problem p ∈ PROB which it was able to solvetogether with the corresponding solution s ∈ SOL .Figure 17 shows a port specification template of the Blackboard pattern.Based on the induced port specification, Fig. 18 shows the corresponding interface specification for thepattern.A KS can only solve certain types of problems which is why we assume the existence of a local port prob for each knowledge source which is typed by the set of problems a certain KS can solve. In Eq. (13) werequire for each KS that it only solves problems given by this mapping.
ISpec BB based on Blackboard loc : in : r p , n s out : o p c s Figure 18. Blackboard interface specification.
ISpec KS based on Blackboard uses
ProbSol loc : prob in : o p , c s out : r p , n s prob : ℘ ( PROB ) var p : PROP P : ℘ ( PROP ) r p = ( p, P ) = ⇒ p ∈ prob (13)Figure 19. Knowledge source interface specification.Table 3. Overview of concepts for interface specifications. Concept
Description Related Notation port identifier identifier for ports P id port specification port identifiers and corresponding typing w.r.t. a signature Σ S p (Σ) interface set of local, input, and output port identifiers of a portspecification P I ( P ) interface interpretation components and corresponding port interpretations for aninterface F Q ( F, )port interpretation bijection between port identifiers and ports of a compo-nent δ l , δ i , δ o interface term term over the ports of a certain interface F , signature Σ ,and datatype variables d V i T d V (Σ , F ) interface semantic function assigns elements of an algebra A to interface terms underdatatype variable assignment ι and interface interpreta-tion J J _ K J ( A,ι ) interface assertion formula over interface terms with signature Σ , interface F ,and datatype variables d V i Γ d V (Σ , F ) interface models relation relates interface assertions ϕ with interface interpretation J under algebra A and datatype variable assignment ι J | = ιA ϕ / J | = A ϕ interface identifier identifier for interfaces I id interface specification interface-identifiers and corresponding interfaces over sig-nature Σ S i (Σ) local, input, output, and all ports of interface spec S i loc ( S i ) , in ( S i ) , out ( S i ) , port ( S i ) interface specification interpretation set of interface interpretations for interfaces of an interfacespecification S i under algebra A J ( S i , A ) port specification template structured technique to specify ports graphicalinterface specification template structured technique to specify component types graphical To conclude this section, Tab. 3 provides a brief overview of the main concepts introduced in this section.For each concept it provides a brief description and related notation. n the Specification of Constraints for Dynamic Architectures 19
Configuration terms: syntax v ∈ d V s = ⇒ v ∈ sc T c V d V (Σ , S i ) ,f ∈ F = ⇒ f ∈ sc T c V d V (Σ , S i ) [for sort ( f ) = s ] ,f ∈ F n +1 ∧ t ∈ s c T c V d V (Σ , S i ) , · · · , t n +1 ∈ s n +1 c T c V d V (Σ , S i ) = ⇒ f ( t , · · · , t n +1 ) ∈ sc T c V d V (Σ , S i ) [for n ∈ N , sort ( f ) = s ,and sort ( f ) = s , · · · , sort n + ( f ) = s n +1 ] ,v ∈ c V i ∧ p ∈ [ Q i ] ∪ [ Q i ] = ⇒ v.p ∈ sc T c V d V (Σ , S i ) [ for i ∈ N and t p ( p ) = s ] . Figure 20. Inductive definition of configuration terms sc T c V d V (Σ , S i ) of sort s ∈ S over signature Σ = (
S, F, B ) ,interface specification S i = ( N, Q ) , datatype variables d V , and component variables c V = ( c V i ) i ∈ N .
5. Architecture Constraint Specification
Architecture constraints are specified as temporal logic formulas over architecture configurations. Thus, wefirst introduce the notion of configuration assertion to specify architecture configurations. Then, we introduce configuration trace assertions as an extension of configuration assertions to specify configuration traces.
Architecture configurations can be specified by so-called configuration assertions formulated over configura-tion terms.
Terms of configuration assertions are build over an interface specification, corresponding signature, datatypevariables and component variables (a family of disjoint sets of variables c V = ( c V i ) i ∈ N with c V i denoting aset of variables for interface identifier i ∈ N ). Definition 21 (Configuration term).
The set of all configuration terms of sort s ∈ S over a signature Σ = (
S, F, B ) , interface specification S i ∈ S i ( S p ) over port specification S p ∈ S p (Σ) , datatype variables d V ,and component variables c V is the smallest set sc T c V d V (Σ , S i ) satisfying the equations of Fig. 20. The set of allconfiguration terms of all sorts is denoted by c T c V d V (Σ , S i ) .Note the use of function symbols of the corresponding datatype specification to build configuration terms.This allows one to reuse these function symbols when specifying architecture configurations. Moreover,note the use of port identifiers in the specification of configuration terms to denote the valuation of thecorresponding port in an architecture configuration. For example, with c.p we denote the current valuationof port p of a component c .The semantics of configuration terms is defined over an algebra and corresponding datatype variableassignments, an interface specification interpretation and corresponding component variable assignments (afamily of mappings ι ′ = ( ι ′ i ) i ∈ N with ι ′ i : c V i → id ( cmp i ( J )) for each interface identifier i ∈ N , where J isthe corresponding interface specification interpretation), and an architecture configuration. In the followingwe denote with I ′ c V J the set of all component variable assignments for component variables and interfacespecification interpretation J . Definition 22 (Configuration semantic function).
The configuration semantic function for configura-tion terms sc T c V d V (Σ , S i ) over algebra A ∈ A (Σ) with corresponding datatype variable assignment ι ∈ I d V A ,interface specification interpretation J ∈ J ( S i , A ) with corresponding component variable assignment ι ′ ∈I ′ c V J , and architecture configuration k ∈ K ( cmp ( J )) is the function J _ K ( J,ι ′ )( A,ι ) ( k ) : sc T c V d V (Σ , S i ) → α ( s ) char-acterized by the equations in Fig. 21. Configuration terms: semantics J v K ( J,ι ′ )( A,ι ) ( k ) def = ι s ( v ) [for v ∈ d V s ] , J f K ( J,ι ′ )( A,ι ) ( k ) def = β ( f ) [for function symbol f ∈ F ] , J f ( t , · · · , t n ) K ( J,ι ′ )( A,ι ) ( k ) def = β ( f )( J t K ιA , · · · , J t n K ιA ) [for function symbol f ∈ F n +1 ] , J v.p K ( J,ι ′ )( A,ι ) ( k ) def = val k ( ι ′ i ( v ))( p ) [for i ∈ N and v ∈ c V i ] . Figure 21. Recursive definition of semantic function for configuration terms sc T c V d V (Σ , S i ) with signature Σ ,interface specification S i = ( N, Q ) ∈ S i ( S p ) over port specification S p ∈ S p (Σ) , datatype variables d V ,component variables c V = ( c V i ) i ∈ N , algebra A ∈ A (Σ) and corresponding datatype variable assignment ι ∈I d V A , interface specification interpretation J ∈ J ( S i , A ) and corresponding component variable assignment ι ′ = ( ι ′ i ) i ∈ N ∈ I ′ c V J , and architecture configuration k = ( C ′ , N ) ∈ K ( cmp ( J )) .Again, the semantics of a term is given by a function assigning a value of a corresponding set of the underlyingalgebra to each term. Assertions for architecture configurations are built over the corresponding configuration terms by the commonlogical operators and some dedicated predicates for the specification of so-called activation and connectionconstraints.
Definition 23 (Configuration assertion).
The set of all configuration assertions over a signature Σ ,interface specification S i ∈ S i ( S p ) over port specification S p ∈ S p (Σ) , datatype variables d V , and componentvariables c V is the smallest set c Γ c V d V (Σ , S i ) satisfying the equations in Fig. 22.Note that the following predicates can be used for the specification of configuration assertions: • Activation contstraints can be used to denote activation and deactivation of components. With k c k , e.g.,we denote the activation of component c . With | i | n , | i | n we denote the constraint that at least n or atmost n components with interface i are active at each point in time. • Connection constraints can be used to denote constraints over the connection between components. With c.p → c ′ .p ′ , e.g., we denote a constraint that port p of component c has to be connected to port p ′ ofcomponent c ′ . Finally, with i.p → j.p ′ we denote that port p of every component with interface i isconnected to port p ′ of every component with interface j .The semantics of configuration assertions is defined over an algebra with corresponding datatype variableassignment and an interface interpretation with corresponding component variable assignment. Definition 24 (Configuration models relation).
The configuration models relation for configurationassertions c Γ c V d V (Σ , S i ) over algebra A ∈ A (Σ) with corresponding datatype variable assignment ι ∈ I d V A ,interface interpretation J ∈ J ( S i , A ) with corresponding component variable assignments ι ′ ∈ I ′ c V J is therelation ι, ι ′ , _ | = JA _ ⊆ K ( cmp ( J )) × c Γ c V d V (Σ , S i ) characterized by the equations in Fig. 23. A configurationassertion γ is valid for architecture configuration k ∈ K ( cmp ( J )) under algebra A ∈ A (Σ) and interfaceinterpretation J ∈ J ( S i , A ) iff there exists corresponding datatype variable assignment ι ∈ I d V A and compo-nent variable assignment ι ′ ∈ I ′ c V J , such that ι, ι ′ , k | = JA γ . Configuration k is a model of γ , written k | = JA γ iff for each corresponding datatype variable assignment ι and component variable assignment ι ′ we have ι, ι ′ , k | = JA γ . Configuration k is a model of a set of configuration assertions Γ , written k | = JA Γ iff k | = JA γ foreach γ ∈ Γ .Note that the semantics of configuration assertions is given in terms of a relation, parametrized by an n the Specification of Constraints for Dynamic Architectures 21 Configuration assertions: syntax b ∈ B = ⇒ b ∈ c Γ c V d V (Σ , S i ) ,b ∈ B n +1 ∧ t ∈ s c T c V d V (Σ , S i ) , · · · , t n +1 ∈ s n +1 c T c V d V (Σ , S i ) = ⇒ b ( t , · · · , t n +1 ) ∈ c Γ c V d V (Σ , S i ) [for n ∈ N and sort ( b ) = s , · · · , sort n + ( b ) = s n +1 ] ,t, t ′ ∈ c T c V d V (Σ , S i ) = ⇒ t = t ′ ∈ c Γ c V d V (Σ , S i ) ,E ∈ c Γ c V d V (Σ , S i ) = ⇒ ¬ E ∈ c Γ c V d V (Σ , S i ) ,E, E ′ ∈ c Γ c V d V (Σ , S i ) = ⇒ E ∧ E ′ , E ∨ E ′ , E = ⇒ E ′ , E ⇐⇒ E ′ ∈ c Γ c V d V (Σ , S i ) ,E ∈ c Γ c V d V (Σ , S i ) ∧ x ∈ d V s = ⇒ ∀ x. E ∈ c Γ c V d V (Σ , S i ) ∧∃ x. E ∈ c Γ c V d V (Σ , S i ) [for s ∈ S ] ,E ∈ c Γ c V d V (Σ , S i ) ∧ x ∈ c V i = ⇒ ∀ x. E ∈ c Γ c V d V (Σ , S i ) ∧∃ x. E ∈ c Γ c V d V (Σ , S i ) [for i ∈ N ] ,n, m ∈ N ∧ n ≤ m = ⇒ | i | n ∈ c Γ c V d V (Σ , S i ) ∧ | i | m ∈ c Γ c V d V (Σ , S i ) ∧| i | mn ∈ c Γ c V d V (Σ , S i ) [ for some i ∈ N ] ,v ∈ c V i = ⇒ k v k ∈ c Γ c V d V (Σ , S i ) [ for some i ∈ N ] ,v ∈ c V i ∧ v ′ ∈ c V j ∧ p ∈ [ Q i ] ∧ p ′ ∈ [ Q j ] = ⇒ v.p → v ′ .p ′ ∈ c Γ c V d V (Σ , S i ) [ for some i, j ∈ N ] ,p ∈ [ Q i ] ∧ p ′ ∈ [ Q j ] = ⇒ i.p → j.p ′ ∈ c Γ c V d V (Σ , S i ) [ for some i, j ∈ N ] . Figure 22. Inductive definition of configuration assertions c Γ c V d V (Σ , S i ) over signature Σ , interface specification S i = ( N, Q ) , datatype variables d V , and component variables c V = ( c V i ) i ∈ N .interface interpretation. It determines all valid architecture configurations (over the components providedby the interface interpretation) for a given configuration assertion. Configuration trace assertions are a means to directly specify sets of configuration traces. They are formulatedas temporal logic formulas over configuration assertions and consist of the common temporal operators andso-called rigid variables for datatypes and components. Compared to “normal” variables, which are newlyinterpreted at each point in time, these variables are interpreted only once for the whole execution trace.Thus, we assume the existence of a set of rigid datatype variables (a family of disjoint sets of variables rd V = ( rd V s ) s ∈ S with rd V s denoting a set of variables for each sort s ∈ S ) and rigid component variables (afamily of disjoint sets of variables rc V = ( rc V i ) i ∈ N with rc V i denoting a set of variables for each interfaceidentifier i ∈ N ). Definition 25 (Configuration trace assertion).
The set of all configuration trace assertions over signa-ture Σ , interface specification S i ∈ S i ( S p ) over port specification S p , datatype variables d V , rigid datatypevariables rd V , component variables c V , and rigid component variables rc V is the smallest set t Γ ( d V , c V )( rd V , rc V ) (Σ , S i ) satisfying the equations in Fig. 24.The semantics of configuration trace assertions is given according to [24]. It is defined over an algebra,an interface interpretation, rigid datatype variable assignments (a family of mappings κ = ( κ s ) s ∈ S with κ s : d V s → α ( s ) for each sort s ∈ S ) and rigid component variable assignments (a family of mappings κ ′ = ( κ ′ i ) i ∈ N with κ ′ i : rc V i → id ( cmp i ( J )) for each interface identifier i ∈ N , where J is the corresponding Configuration assertions: semantics ι, ι ′ , k | = JA b ⇐⇒ γ ( b ) [for b ∈ B ] ,ι, ι ′ , k | = JA b ( t , · · · , t n ) ⇐⇒ γ ( b )( J t K ιA , · · · , J t n K ιA ) [for b ∈ B n +1 ] ,ι, ι ′ , k | = JA t = t ′ ⇐⇒ J t K ιA = J t ′ K ιA ,ι, ι ′ , k | = JA E ∧ E ′ ⇐⇒ ι, ι ′ , k | = JA E ∧ ι, ι ′ , k | = JA E ′ ,ι, ι ′ , k | = JA E ∨ E ′ ⇐⇒ ι, ι ′ , k | = JA E ∨ ι, ι ′ , k | = JA E ′ ,ι, ι ′ , k | = JA E = ⇒ E ′ ⇐⇒ ι, ι ′ , k | = JA E = ⇒ ι, ι ′ , k | = JA E ′ ,ι, ι ′ , k | = JA E ⇐⇒ E ′ ⇐⇒ ι, ι ′ , k | = JA E ⇐⇒ ι, ι ′ , k | = JA E ′ ,ι, ι ′ , k | = JA ∃ x. E ⇐⇒ ∃ x ′ ∈ α ( s ): ι [ s : x x ′ ] , ι ′ , k | = JA E [for s ∈ S and x ∈ d V s ] ,ι, ι ′ , k | = JA ∀ x. E ⇐⇒ ∀ x ′ ∈ α ( s ): ι [ s : x x ′ ] , ι ′ , k | = JA E [for s ∈ S and x ∈ d V s ] ,ι, ι ′ , k | = JA ∃ x. E ⇐⇒ ∃ x ′ ∈ id ( cmp i ( J )): ι, ι ′ [ i : x x ′ ] , k | = JA E [for i ∈ N and x ∈ c V i ] ,ι, ι ′ , k | = JA ∀ x. E ⇐⇒ ∀ x ′ ∈ id ( cmp i ( J )): ι, ι ′ [ i : x x ′ ] , k | = JA E [for i ∈ N and x ∈ c V i ] ,ι, ι ′ , k | = JA | i | n ⇐⇒ | cmp i ( J ) ∩ C ′ | ≥ n [for k = ( C ′ , N ) and i ∈ N ] ,ι, ι ′ , k | = JA | i | m ⇐⇒ | cmp i ( J ) ∩ C ′ | ≤ m [for k = ( C ′ , N ) and i ∈ N ] ,ι, ι ′ , k | = JA | i | mn ⇐⇒ ι, ι ′ , k | = JA | i | n ∧ ι, ι ′ , k | = JA | i | m ,ι, ι ′ , k | = JA k v k ⇐⇒ ι ′ i ( v ) ∈ id ( C ′ ) [for k = ( C ′ , N ) , i ∈ N , and v ∈ c V i ] ,ι, ι ′ , k | = JA v.p → v ′ .p ′ ⇐⇒ ( ι ′ ( v ′ ) , p ′ ) ∈ N ( ι ′ ( v ) , p ) [for k = ( C ′ , N ) ] ,ι, ι ′ , k | = JA i.p → j.p ′ ⇐⇒ ι, ι ′ , k | = JA ∀ v, v ′ . (cid:0) k v k ∧ k v ′ k = ⇒ v.p → v ′ .p ′ (cid:1) [for v ∈ c V i , v ′ ∈ c V j ] . Figure 23. Recursive definition of models relation for configuration assertions c Γ S i Σ ( d V , c V ) with interfacespecification S i = ( N, Q ) , algebra A ∈ A (Σ) with corresponding datatype variable assignments ι = ( ι s ) s ∈ S ,and interface specification interpretation J ∈ J ( S i , A ) with corresponding component variable assignment ι ′ = ( ι ′ i ) i ∈ N .Configuration trace assertions: syntax φ ∈ c Γ c V∪ rc V d V∪ rd V (Σ , S i ) = ⇒ φ ∈ t Γ ( d V , c V )( rd V , rc V ) (Σ , S i ) ,γ ∈ t Γ ( d V , c V )( rd V , rc V ) (Σ , S i ) = ⇒ (cid:13) γ, ♦ γ, (cid:3) γ ∈ t Γ ( d V , c V )( rd V , rc V ) (Σ , S i ) ,γ, γ ′ ∈ t Γ ( d V , c V )( rd V , rc V ) (Σ , S i ) = ⇒ (cid:0) γ U γ ′ (cid:1) , (cid:0) γ W γ ′ (cid:1) ∈ t Γ ( d V , c V )( rd V , rc V ) (Σ , S i ) ,x ∈ rd V s ∧ γ ∈ t Γ ( d V , c V )( rd V , rc V ) (Σ , S i ) = ⇒ ∀ x. γ ∈ t Γ ( d V , c V )( rd V , rc V ) (Σ , S i ) ∧∃ x. γ ∈ t Γ ( d V , c V )( rd V , rc V ) (Σ , S i ) [for s ∈ S ] ,x ∈ rc V i ∧ γ ∈ t Γ ( d V , c V )( rd V , rc V ) (Σ , S i ) = ⇒ ∀ x. γ ∈ t Γ ( d V , c V )( rd V , rc V ) (Σ , S i ) ∧∃ x. γ ∈ t Γ ( d V , c V )( rd V , rc V ) (Σ , S i ) [for i ∈ N ] . Figure 24. Inductive definition of configuration trace assertions t Γ ( d V , c V )( rd V , rc V ) (Σ , S i ) over signature Σ = (
S, F, B ) ,interface specification S i = ( N, Q ) , datatype variables d V = ( d V s ) s ∈ S , component variables c V = ( c V i ) i ∈ N ,rigid datatype variables rd V = ( rd V s ) s ∈ S , and rigid component variables rc V = ( rc V i ) i ∈ N . n the Specification of Constraints for Dynamic Architectures 23 Configuration trace assertions: semantics κ, κ ′ , ( t, n ) | = JA φ ⇐⇒ ∃ ι ∈ I d V A , ι ′ ∈ I ′ c V J : ι ∪ κ, ι ′ ∪ κ ′ , t ( n ) | = JA φ ,κ, κ ′ , ( t, n ) | = JA (cid:13) γ ⇐⇒ κ, κ ′ , ( t, n + 1) | = JA γ ,κ, κ ′ , ( t, n ) | = JA ♦ γ ⇐⇒ ∃ n ′ ≥ n : κ, κ ′ , ( t, n ′ ) | = JA γ ,κ, κ ′ , ( t, n ) | = JA (cid:3) γ ⇐⇒ ∀ n ′ ≥ n : κ, κ ′ , ( t, n ′ ) | = JA γ ,κ, κ ′ , ( t, n ) | = JA (cid:0) γ U γ ′ (cid:1) ⇐⇒ ∃ n ′ ≥ n : κ, κ ′ , ( t, n ′ ) | = JA γ ′ ∧ ∀ n ≤ m < n ′ : κ, κ ′ , ( t, m ) | = JA γ ,κ, κ ′ , ( t, n ) | = JA (cid:0) γ W γ ′ (cid:1) ⇐⇒ κ, κ ′ , ( t, n ) | = JA (cid:0) γ U γ ′ (cid:1) ∨ κ, κ ′ , ( t, n ) | = JA (cid:3) γ ,κ, κ ′ , ( t, n ) | = JA ∃ x. γ ⇐⇒ ∃ x ′ ∈ α ( X ): κ [ X : x x ′ ] , κ ′ , ( t, n ) | = JA γ [for X ∈ S ] ,κ, κ ′ , ( t, n ) | = JA ∀ x. γ ⇐⇒ ∀ x ′ ∈ α ( X ): κ [ X : x x ′ ] , κ ′ , ( t, n ) | = JA γ [for X ∈ S ] ,κ, κ ′ , ( t, n ) | = JA ∃ x. γ ⇐⇒ ∃ x ′ ∈ J − ( X ): κ, κ ′ [ X : x x ′ ] , ( t, n ) | = JA γ [for X ∈ N ] ,κ, κ ′ , ( t, n ) | = JA ∀ x. γ ⇐⇒ ∀ x ′ ∈ J − ( X ): κ, κ ′ [ X : x x ′ ] , ( t, n ) | = JA γ [for X ∈ N ] . Figure 25. Recursive definition of models relation for configuration trace assertions t Γ ( d V , c V )( rd V , rc V ) (Σ , S i ) over sig-nature Σ = (
S, F, B ) , interface specification S i = ( N, Q ) , algebra A = ( S ′ , F ′ , B ′ , α, β, γ ) with correspondingrigid datatype variable assignment κ = ( κ s ) s ∈ S , and interface specification interpretation J = J ∈ J ( S i , Q ) with corresponding rigid component variable assignment κ ′ = ( κ ′ i ) i ∈ N .interface specification interpretation). It relates each configuration trace assertion with a configuration traceand point in time such that the trace satisfies the assertion at the corresponding time point. Definition 26 (Configuration trace models relation).
The configuration trace models relation for con-figuration trace assertions t Γ ( d V , c V )( rd V , rc V ) (Σ , S i ) over algebra A ∈ A (Σ) with corresponding datatype variable as-signment ι ∈ I d V A and rigid datatype variable assignment κ ∈ K d V A , interface interpretation J ∈ J ( S i , A ) , withcorresponding component variable assignment ι ′ ∈ I ′ c V J and rigid component variable assignment κ ′ ∈ K ′ c V J is the relation κ, κ ′ , _ | = JA _ ⊆ ( K ( cmp ( J )) × N ) × t Γ ( d V , c V )( rd V , rc V ) (Σ , S i ) characterized by the equations in Fig. 25.A configuration trace assertion γ is valid for configuration trace t ∈ R ( cmp ( J )) under algebra A ∈A (Σ) and interface interpretation J = J ∈ J ( S i , A ) iff there exists corresponding rigid datatype variableassignment κ ∈ K d V A and rigid component variable assignment κ ′ ∈ K ′ c V J , such that κ, κ ′ , ( t, | = JA γ . Trace t is a model of γ , written t | = JA γ iff for each corresponding rigid datatype variable assignment κ and rigidcomponent variable assignment κ ′ we have κ, κ ′ , ( t, | = JA γ . Trace t is a model of a set of configuration traceassertions Γ , written t | = JA Γ iff t | = JA γ for each γ ∈ Γ .Note the existential quantification for datatype variable assignments and component variable assignmentsmeaning that these variables are interpreted at each point in time, compared to the rigid once. Configuration trace assertions can be specified by means of configuration trace specification templates(Fig. 26). Each template has a name and can import interface specification templates by means of theirname. Then, a list of variables for the different sorts/interfaces are defined. Finally, a list of configurationtrace assertions are formulated over the variables and interfaces specified by the corresponding interfacespecifications.
Spec
Name uses ifSpec var var1, var2 : Sort1 var3 : Sort2 assertion1 (var1 , var2 , var3) assertion2 (var1 , var2 , var3) Figure 26. Configuration trace specification template
Spec
Blackboard_Behavior uses
Blackboard var bb : BB p, p ′ : PROB P : PROB SET s : SOL (cid:3) (cid:16) ( p, s ) ∈ bb .n s = ⇒ ♦ (cid:0) ( p, s ) ∈ bb .c s (cid:1)(cid:17) (14) (cid:3) (cid:16) ( p, P ) ∈ bb .r p = ⇒ (cid:0) ∀ p ′ ∈ P. ( ♦ p ′ ∈ bb .o p ) (cid:1)(cid:17) (15) (cid:3) (cid:16) p ∈ bb .o p = ⇒ (cid:0) p ∈ bb .o p W ( p, solve ( p )) ∈ bb .n s (cid:1)(cid:17) (16)Figure 27. Architecture constraint specification: BB behavior. In the following we provide an architecture constraint specification for Blackboard architectures. First, wespecify constraints regarding the behavior of BBs and KSs, respectively. Then, we provide activation andconnection constraints for such architectures by means of configuration trace specification templates.
A BB provides the current state towards solving the original problem and forwards problems and solutionsfrom KSs. Fig. 27 provides a specification of the BBs behavior in terms of a configuration trace specificationtemplate consisting of three configuration trace assertions: • if a solution to a subproblem is received on its input, then it is eventually provided at its output (Eq. 14). • if solving a problem requires a set of subproblems to be solved first, those problems are eventually providedat its output (Eq. (15)). • a problem is provided as long as it is not solved (Eq. (16)). A KS receives open problems via o p and solutions for other problems via c s . It might contribute to thesolution of the original problem by solving subproblems. Fig. 28 provides a specification of the KSs behaviorin terms of a configuration trace specification template consisting of three configuration trace assertions: • if a KS gets correct solutions for all the required subproblems, then it solves the problem eventually(Eq. (17)). • in order to solve a problem, a KS requires solutions only for smaller problems (Eq. (18)). • if a KS is able to solve a problem it will eventually communicate this (Eq. (19)). n the Specification of Constraints for Dynamic Architectures 25 Spec
Knowledgesource_Behavior uses
Blackboard var ks : KS p, q : PROB P : PROB SET (cid:3) (cid:16) ∀ ( p, P ) ∈ ks .r p . (cid:0) ( ∀ q ∈ P. ♦ ( q, solve ( q )) ∈ ks .c s ) = ⇒ ♦ ( p, solve ( p )) ∈ ks .n s (cid:1)(cid:17) (17) (cid:3) (cid:16) ∀ ( p, P ) ∈ ks .r p . ∀ q ∈ P. q ≺ p (cid:17) (18) (cid:3) (cid:16) p ∈ ks . prob ∧ p ∈ ks .o p = ⇒ ♦ ( ∃ P. ( p, P ) ∈ ks .r p ) (cid:17) (19)Figure 28. Architecture constraint specification: KS behavior. Spec
Blackboard_Activation uses
Blackboard var bb , bb ′ : BB p, q : PROB P : PROB SET (cid:3) ( k bb k ∧ ∀ bb ′ . bb ′ = bb ) (20) (cid:3) (cid:16) ∀ ( p, P ) ∈ ks .r p . (cid:0) ∀ q ∈ P. ( ♦ ( q, solve ( q )) ∈ bb .c s ) = ⇒ ♦ (( q, solve ( q )) ∈ bb .c s ∧ k ks k ) (cid:1)(cid:17) (21)Figure 29. Architecture constraint specification: activation specification. Activation constraints for the Blackboard pattern are described by two configuration trace assertions providedin the configuration trace specification template in Fig. 29: • Eq. (20) denotes the conditions that there is a unique BB component which is always activated (incontrast to KSs components which can be activated and deactivated arbitrarily). • Eq. (21) requires that whenever a KS component offers to solve some problem, it is always activatedwhen solutions to the required subproblems are provided.
Connection constraints are also specified by a configuration trace specification template provided in Fig. 30.It consists of two configuration trace assertions: Eq. (22) describes the required connections for all executionswhile Eq. (23) describes all connections which are not allowed. Roughly speaking the specification requiresthat for each point in time, input port o p of a KS is connected (only) to output port o p of the BB component,input port c s of a KS is connected (only) to output port c s of the BB component, output port r p of a KS isconnected (only) to input port r p of the BB component, and output port n s of a KS is connected (only) toinput port n s of the BB component. As stated in the introduction of this section, architecture constraints are specified in three steps by specifyingdatatypes, interfaces and configuration traces.
Definition 27 (Architecture constraint specification). An architecture constraint specification overdatatype variables d V , d V ′ and component variables c V , rigid datatype variables rd V and rigid componentvariables rc V is a 6-tuple (Σ , Φ , S p , S i , Ω , Γ) , consisting of: • a signature Σ , Spec
Connection uses
Blackboard var bb : BB ks : KS (cid:3) (cid:16) ks .o p → bb .o p ∧ ks .c s → bb .c s ∧ bb .r p → ks .r p ∧ bb .n s → ks .n s (cid:17) (22) (cid:3) (cid:16) ¬ (cid:0) ks .o p → bb .c s (cid:1) ∧ ¬ (cid:0) ks .c s → bb .o p (cid:1) ∧ ¬ (cid:0) bb .r p → ks .n s (cid:1) ∧ ¬ (cid:0) bb .n s → ks .r p (cid:1)(cid:17) (23)Figure 30. Architecture constraint specification: connection specification. • a datatype specification Φ ⊆ d Γ(Σ , d V ′ ) , • a port specification S p ∈ S p (Σ) , • an interface specifications S i = ( N, Q ) ∈ S i ( S p ) , • interface specifications (Ω i ) i ∈ N , where Ω i ⊆ i Γ d V (Σ , Q i ) for each interface identifier i ∈ N , and • a set of configuration trace assertions Γ ⊆ t Γ ( d V , c V )( rd V , rc V ) (Σ , S i ) .The semantics of an architecture constraint specification is given in terms of a set of configuration traces.Algorithm 1 describes how to systematically derive the semantics of an architecture constraint specification. Algorithm 1
Calculate semantics of Architecture constraint specification
Input: architecture constraint specification S with: • signature Σ , • datatype specification Φ ⊆ d Γ(Σ , d V ′ ) , • port specification S p ∈ S p (Σ) , • interface specifications S i = ( N, Q ) ∈ S i ( S p ) , • interface specifications (Ω i ) i ∈ N , where Ω i ⊆ i Γ d V (Σ , Q i ) for each interface identifier i ∈ N , and • set of configuration trace assertions Γ ⊆ t Γ ( d V , c V )( rd V , rc V ) (Σ , S i ) . Output: a set of configuration traces T satisfying SA ⇐ A (Σ) , such that A | = Φ J ⇐ J ( S i , A ) , such that ∀ i ∈ N, j ∈ J i : j | = A Ω i T ⇐ t ∈ R ( cmp ( J )) , such that t | = JA Γ return T A set of configuration traces T ⊆ R ( cmp ( J )) fulfills an architecture constraint specification (Σ , Φ , S p , S i , Ω , Γ) over datatype variables d V , d V ′ and component variables c V , rigid datatype variables rd V and rigid component variables iff there exists an algebra A ⊆ A (Σ) and interface specification interpretation J , such that: • A is a model of the datatype specification: A | = Φ , • J i satisfies the corresponding interface assertion: j | = A Ω i , • each trace t ∈ T is a model of Γ : t | = JA Γ .Fig. 5.4 depicts the relationship of the syntactic and semantic concepts to specify architecture properties.First, a datatype specification determines an algebra with corresponding sets of messages and operations onthose sets. Later on, an interface specification determines a set of components valuated by messages from thecorresponding algebra. Finally, the set of configuration trace assertions determine a set of configuration traceover those components. Note that configuration trace assertions may use certain operations specified in thecorresponding datatype specification which is why configuration traces depend on the concrete interpretationof those operations. n the Specification of Constraints for Dynamic Architectures 27 Semantic Domains Syntactic DomainsAlgebraSets ofMessagesOperations ComponentsConfiguration Traces DatatypeSpecificationInterfaceSpecificationConfigurationTraceAssertionsFigure 31. Relationship between syntactic and semantic concepts to specify architecture constraints.
Table 4 provides an overview of the concepts introduced in this section. For each concept it provides a briefdescription and related notation.
6. Configuration Diagrams
Configuration trace assertions are actually sufficient to specify each property of dynamic architectures.However, sometimes, certain common constraints are better expressed by a so-called configuration diagram.Configuration diagrams complement configuration trace assertions and are well-suited to specify interfacesand introduce certain common connection and activation constraints in one graphical notation.
In its simplest form, a configuration diagram is just a graphical representation of an interface specification.It consists of boxes and small circles, representing an interface identifier and corresponding local, input, andoutput ports. Thereby, transparent circles inside a component represent local ports, while white and blackcircles on the border of a component represent input and output ports, respectively. In addition, the portsare annotated with their name. The diagram is surrounded by a box which adds a name to the specification,a reference to imported port specifications, and a set of interface assertions.Fig. 32 shows a graphical representation of a configuration diagram
Name corresponding to an interfacespecification S i = ( N, Q ) and family of interface assertions Ω , with: • interface identifiers N = { If1 , If2 } , • interfaces Q If1 = ( { i } , { o } ) and Q If2 = ( ∅ , { o } ) , and • interface assertions Ω If1 = { InterfaceAssertion } .As for interface specifications a configuration diagram may include also a corresponding port specification.Fig. 32, e.g., includes a port specification declaring ports l , i , o , o and corresponding types t p ( i ) = t p ( o ) = Sort1 and t p ( o ) = t p ( l ) = Sort2 . Table 4. Overview of concepts to specify architecture constraints.
Concept
Description Related Notation component variable variable for component identifiers c V configuration term term over signature Σ , interface specification S i ,datatype variables d V , and component variables c V c T c V d V (Σ , S i ) activation constraint constraint on activation and deactivation of compo-nentsconnection constraint constraint on the connection between components component variable assignment assignment of component identifiers of interface spec-ification interpretation J to component variables c V I ′ c V J configuration semantic function assigns elements of an algebra A to configuration termsunder a certain datatype variable assignment ι , inter-face specification interpretation J and correspondingcomponent variable assignment ι ′ , and architectureconfiguration k J _ K ( J,ι ′ )( A,ι ) ( k ) configuration assertion formula over configuration terms with correspondingsignature Σ , interface specification S i , datatype vari-ables d V , and component variables c V c Γ c V d V (Σ , S i ) configuration models relation relates configuration assertions with architecture con-figurations under an algebra A and correspondingdatatype variable assignment ι , and interface specifi-cation interpretation J and corresponding componentvariable assignment ι ′ ι, ι ′ , _ | = JA _rigid datatype variable datatype variable with fixed assignment for the wholeexecution rd V rigid component variable component variable with fixed assignment for thewhole execution rc V configuration trace assertion formula over configuration assertions with correspond-ing signature Σ , interface specification S i , datatypevariables d V , component variables c V , rigid datatypevariables rd V , and rigid component variables rc V t Γ ( d V , c V )( rd V , rc V ) (Σ , S i ) rigid datatype variable assignment assignment of elements of an algebra A to a set of rigiddatatype variables d V , K rd V A rigid component variable assignment assignment of component identifiers of interface spec-ification interpretation J to rigid component variables c V K ′ rc V J configuration trace models relation relates configuration trace assertions with configura-tion traces under an algebra A and corresponding rigiddatatype variable assignment κ , and interface specifi-cation interpretation J and corresponding rigid com-ponent variable assignment κ ′ κ, κ ′ , _ | = JA _configuration trace specification template structured technique to specify configuration traces graphicalarchitecture constraint specification a signature Σ , Φ , interface specification S i , and a setof configuration trace assertions Γ (Σ , Φ , S p , S i , Ω , Γ) Sometimes, it is convenient to annotate configuration diagrams by certain activation and connection con-straints. These annotations are actually graphical synonyms for certain configuration trace assertions andthey can be separated into activation and connection annotations. n the Specification of Constraints for Dynamic Architectures 29
Diagram
Name based on
PSpec uses
DTSpec i , o : Sort o , l : Sort If1 l = { A } i o If2 o var v : Sort1 v : Sort2 If1InterfaceAssertion ( If1 .i , If1 .o , If1 .l , If2 .o ) Figure 32. Simple configuration diagram as a graphical means to specify component types. If [ n..m ] i o Figure 33. Min-max annotation requiring at least n but at most m active components of type If at eachpoint in time. Activation annotations enhance a configuration diagram by constraints regarding the activation and deacti-vation of certain components. Thus, they are modeled by predicates or mappings over interface identifiers.
Min-max annotations restrict the number of active components of a certain type.
Definition 28 (Min-max annotation). A min-max annotation for an interface specification ( N, Q ) is apair of mappings ( A min , A max ) , with A min , A max : N N .Note that not every interface needs to be annotated.A min-max annotation can be easily specified by adding the two numbers to an interface identifier in aconfiguration diagram. Fig. 33, for example, depicts a constraint that at least n but at most m componentsof type If are active at each point in time.The semantics of min-max annotations is given by means of corresponding configuration trace assertions. Definition 29 (Min-max annotation semantics).
The semantics of a min-max annotation ( A min , A max ) ,for interface specification ( N, Q ) is given by the following configuration trace assertion: (cid:3) (cid:16) ^ i ∈ dom( A min ) | i | A min ( i ) ∧ ^ i ∈ dom( A max ) | i | A max ( i ) (cid:17) . (24)Note that if A min ( i ) = A max ( i ) , then one number can be omitted and only one is to be annotated in thecorresponding configuration diagram. A min-max annotation does only constrain the number of components for a certain interface at a certainpoint in time. It does not say anything about which components these are. Assume, for example, we wantto specify that a unique component of type i is active at each point in time. If we put a min-max constraint c , c : If i o Figure 34. Rigid annotation requiring that only components c and c are activated throughout systemexecution. If1 i If2 o Figure 35. Required connection annotation requiring components of type
If1 to be always connected to acomponent of type
If2 through ports i and o , respectively.of for interface i , than this means that exactly one component of type i is active at each point in time.However, it can be that at some point only component c is active while at another time c is active.To specify that at each point in time the same components have to be activated we can use so-calledrigid annotations. Definition 30 (Rigid annotation). A rigid annotation for an interface specifications ( N, Q ) and rigidcomponent variables rc V = ( rc V i ) i ∈ N is a mapping A r : N → ℘ ( rc V ) , such that ∀ i ∈ N : A r ( i ) ⊆ rc V i .A rigid annotation is specified by a list of variables for each interface. Note, however, that we require theuse of rigid component variables here.Fig. 34 depicts a constraint that only components c and c are activated throughout system execution.The semantics of rigid annotations is given by means of configuration trace assertions. Definition 31 (Rigid annotation semantics).
The semantics of a rigid annotation A r for interface spec-ification ( N, Q ) is given by the following configuration trace assertion: (cid:3) (cid:16) ^ i ∈ N (cid:0) ∀ v : _ c ∈ A r ( i ) ( c = v ) (cid:1)(cid:17) , (25)where v ∈ c V is a (non-rigid) component variable. Connection annotations enhance a configuration diagram by constraints regarding the connection of certaincomponents. Thus, they are modeled by predicates or mappings over relations over interface ports.
Definition 32 (Required connection annotation). A required connection annotation for an interfacespecification S i is a relation A c : in ( S i ) out ( S i ) .A required connection annotation is expressed by solid connections between the corresponding ports.Figure 35 denotes a constraint that a component of type If1 is always connected to a component of type
If2 through ports i and o , respectively. Definition 33 (Required connection annotation semantics).
The semantics of a required connectionannotation A c for interface specification S i ∈ I ( S p ) over port specification S p ∈ S p (Σ) is given by thefollowing configuration trace assertion: (cid:3) (cid:16) ^ (( j,i ) , ( k,o )) ∈ A c j.i → k.o ∧ ^ (( j,i ) , ( k,o )) ∈ rest ( A c ) ¬ (cid:0) j.i → k.o (cid:1)(cid:17) , (26)where rest ( A c ) = in ( S i ) × out ( S i ) \ A c .Note that a required connection annotation induces a full homomorphism (a homomorphism preservingnon-edge) between a configuration diagram and corresponding architecture configuration. n the Specification of Constraints for Dynamic Architectures 31 Property 3 (Required connection induces full homomorphism).
Let A c be a required connectionannotation for interface specification S i = ( N, Q ) with induced configuration trace assertion ϕ . More-over, let J ∈ J ( S i , A ) be a corresponding interface specification interpretation under an algebra A =( S ′ , F ′ , B ′ , α, β, γ ) ∈ A (Σ) . Finally, let δ : id ( cmp ( J )) → N denote the interface for each component iden-tifier and δ i = ( δ id ) d ∈ id ( cmp ( J )) and δ o = ( δ od ) d ∈ id ( cmp ( J )) denoting the corresponding input and output portinterpretations for component identifier c .Then, ( δ i , δ o ) form a homomorphism from each architecture configuration of each trace t ∈ R ( cmp ( δ )) satisfying ϕ (for each point in time) to the corresponding possible connection annotation: ∀ t ∈ (cid:8) t ∈ R ( cmp ( J )) | t | = JA ϕ (cid:9) , n ∈ N , c ∈ [ t ( n )] ,c ′ ∈ [ t ( n )] , d = [ c ] , d ′ = [ c ′ ] , p ∈ [ c ] , p ′ ∈ [ c ] :(( d, p ) , ( d ′ , p ′ )) ∈ [ t ( n )] ⇐⇒ (cid:16) ( δ ( d ) , δ iδ ( d ) ( p )) , ( δ ( d ′ ) , δ oδ ( d ′ ) ( p ′ )) (cid:17) ∈ A c . (27) Proof.
Let t ∈ (cid:8) t ∈ R ( cmp ( J )) | t | = JA ϕ (cid:9) , n ∈ N , c ∈ [ t ( n )] , c ′ ∈ [ t ( n )] , d = [ c ] , d ′ = [ c ′ ] , p ∈ [ c ] , and p ′ ∈ [ c ] .( = ⇒ ): Assume (( d, p ) , ( d ′ , p ′ )) ∈ [ t ( n )] and show (cid:16) ( δ ( d ) , δ iδ ( d ) ( p )) , ( δ ( d ′ ) , δ oδ ( d ′ ) ( p ′ )) (cid:17) ∈ A c by contra-diction. Thus, assume ¬ (cid:16) ( δ ( d ) , δ iδ ( d ) ( p )) , ( δ ( d ′ ) , δ oδ ( d ′ ) ( p ′ )) (cid:17) ∈ A c . The, from Def. 33, have that ϕ containsconjunction ¬ (cid:0) j.i → k.o (cid:1) . Thus, since t | = JA ϕ , have (( d, p ) , ( d ′ , p ′ )) / ∈ [ t ( n )] by Def. 24 which is in contra-diction with the assumption.( ⇐ = ): Assume (cid:16) ( δ ( d ) , δ iδ ( d ) ( p )) , ( δ ( d ′ ) , δ oδ ( d ′ ) ( p ′ )) (cid:17) ∈ A c . Thus, from Def. 33, have that ϕ containsconjunction j.i → k.o . Thus, since t | = JA ϕ , have (( d, p ) , ( d ′ , p ′ )) ∈ [ t ( n )] by Def. 24. The interface specification of the Blackboard pattern as well as the activation and connection constraints ofEq. (20) and Eq. (22), respectively, could have been also expressed by the configuration diagram in Fig. 36: • The interface specification is given by the two interfaces KK and BB , respectively. • Eq. (20) is addressed by adding variable bb and the corresponding min-max annotation. • Eq. (22) is addressed by the solid connections between the ports.
Configuration diagrams are well-suited to specify interfaces and certain common activation and connectionconstraints.However, not all constraints can be specified only by means of configuration diagrams which is whyconfiguration diagrams are usually refined by adding further constraints by means of configuration traceassertions.
Table 5 provides an overview of the concepts introduced in this section. For each concept a brief descriptionas well as related notation is provided.
7. Verifying a Specification
As demonstrated by the example, the approach allows for formal specification of patterns of dynamic ar-chitectures. Such a specification is useful, for example, to check pattern conformance of an architecture,
Diagram
Blackboard based on
Blackboard uses
ProbSol prob : ℘ ( PROB ) KS prob o p c s r p n s bb : BB [1] o p c s r p n s var p : PROP P ℘ ( PROP ) bb r p = ( p, P ) = ⇒ p ∈ prob Figure 36. Configuration diagram for Blackboard architectures.Table 5. Overview of concepts for configuration diagrams.
Concept
Description Related Notation configuration diagram graphical notation to specify interfaces as well as commonactivation and connection constraints graphicalactivation annotations annotations to constraint the activation/deactivation ofcomponents min-max annotation specifies the minimal( min )/maximal( max ) number ofcomponents of a certain type [ min .. max ] rigid annotation set of rigid component variables denoting the set of allpossible active components of an interface If c , c : If connection annotations annotations to constrain the connection between compo-nents required connection annotation specification of required port-connection i.e., whether a concrete architecture implements a certain pattern. On the other hand, having a formalspecification of a pattern allows to formally analyze the specification.This section demonstrates how a specification can be used to formally reason about it. Therefore, wespecify a characteristic guarantee of Blackboard architectures by means of configuration trace assertions andprove it from the specification developed so far. First, a property is specified over the architecture. The property can be formally specified by applying thetechniques presented so far. As stated in the introduction of this article, one characteristic property of aBlackboard architecture is its ability to (collaboratively) solve a complex problem even if no single KS existswhich is able to solve the problem on its own.
Theorem 1.
Assuming that KSs are active when required: (cid:3) (cid:16) ∀ p ∈ bb .o p . ♦ (cid:0) ∃ ks . p ∈ ks . prob (cid:1)(cid:17) , (28) n the Specification of Constraints for Dynamic Architectures 33 a Blackboard architecture guarantees to solve the original problem: (cid:3) (cid:16) p ∈ bb .r p = ⇒ ♦ ( p, solve ( p )) ∈ bb .c s (cid:17) . (29) Then, the specification is verified w.r.t. the identified property by proving it from the specification. Therefore,the constraints introduced in the specification of the pattern serve as the major arguments throughout theproof. In the following we prove Thm. 1 by applying the different constraints specified for the pattern.
Proof.
The proof is by well-founded induction over the problem relation ≺ : First, by Eq. (20) or Fig. 36there exists a unique blackboard component bb which is always activated. Then, by Eq. (28), we are surethat for each problem eventually a KnowledgeSource ks exists which is capable to solve the problem. ByEq. (19) the ks will eventually communicate the subproblems p ′ it requires to solve the original problem p onits port r p and this information is then transferred to port r p of bb by the connection constraints imposed byEq. (22) or Fig. 36. By Eq. (15), bb will provide these subproblems p ′ eventually on its output port o p andpublish it as long as it is not solved (as required by Eq. (16)). Since the subproblems p ′ provided to bb arestrictly less than the original problem p (due to Eq. (18)), they will eventually be solved and its solutions s ′ provided on port c s of bb by the induction hypothesis. ks will eventually be activated for each solution s ′ (Eq. (21)) and due to Eq. (22) or Fig. 36 the solutions s ′ are transferred to the corresponding port c s of ks .Thus, ks eventually has all solutions s ′ to its subproblems p ′ and will then solve the original problem p byEq. (17) and publish the solution s on its port n s . Solution s is received eventually by bb on its port n s dueto Eq. (22) or Fig. 36 and is finally provided by bb on its port c s due to Eq. (14).
8. Discussion
The approach presented in this article is characterized by the following properties: • Formal : The approach is based on a formal foundation with a formal semantics for each specificationtechnique. • Uniform : Each specification technique is based on a uniform model for dynamic architectures. • Abstract : The approach is based on a rather abstract notion of architecture. • Model-theoretic semantics : The semantics of each technique is given in terms of models which satisfy acorresponding specification.These properties induce several benefits as well as some drawbacks which we will briefly discuss in thefollowing.
Due to its formal nature, specifications can be interpreted as mathematical models. As demonstrated inSect. 7, this enables formal analyses and verifications of the specifications.
Since the semantics of each technique is given in terms of a uniform model, inconsistencies can be detectedmore easily since the impact of different specification assertions can be directly related to each other.
Due to the abstract nature of the underlying model, the approach is very general. Its specifications andcorresponding verification results can be interpreted for different, concrete architecture instances.
Since the semantics is given in terms of model-theory, this makes the approach easily extensible. Newconstructs can be easily integrated by describing its impact of the underlying model.
Another implication of the model-theoretic semantics is the possibility for stepwise refinement of specifica-tions. After specifying a set of interfaces we can add more and more constraints. Thus, gradually lessen thespace of possible architectures satisfying the specification.
Of course, the approach imposes some limitations which we will briefly discuss in the following.
While generality is listed as a benefit of the approach, it can also be seen as a drawback. Due to the abstractnature of the approach, it omits several details regarding component instantiation and communication be-tween components. Thus, the approach is not well-suited in situations in which it is important to reasonabout these, more detailed aspects.
Although the approach is based on a uniform model of architectures, this does not ensure consistency ofspecifications developed with the approach. Constraints are expressed in temporal logic formulas which canbe complex and induce inconsistencies of specifications.
In this article we provided the theoretical foundations of our approach and demonstrated the concepts bymeans of a small example. To demonstrate the power of the approach it should be applied to more real worldspecifications.
9. Related Work
In this article we described an approach to specify constraints for dynamic architectures. Thus, relatedwork can be found in three different areas. (i) specification of dynamic architectures, (ii) specification ofarchitectural constraints, and (iii) specification of dynamic reconfiguration. In the following we briefly discusseach of them in more detail.
Over the last decades, several so-called Architecture Description Languages (ADLs) emerged to support inthe formal specification of architectures. Some of them also support the specification of dynamic aspects [20,22, 23, 3, 2, 29, 13, 16].While ADLs support in the formal specification of (dynamic) architectures, they were developed with theaim to specify individual architecture instances, rather than architecture constraints which requires moreabstract specification techniques.By providing a language to specify such constraints, we actually complement these approaches. Ourlanguage can be used to specify architectural constraints and verify them against the concrete architecturesspecified in one of those languages. n the Specification of Constraints for Dynamic Architectures 35
Attempts to formalize architectural styles and patterns required more abstract specification techniques andfocused on the specification of architectural constraints, rather than concrete architectures.Such constraints are either specified by a general specification language such as Z [32] (as, for example,by Abowd et al. [1]), algebraic specifications (as, for example, by Moriconi et al. [28] and Penix et al. [30]),graph grammars (as, for example, by Le MÃľtayer [21]) or by the use of process algebras (as, for example, byBernardo et al. [5]) or directly from architectural primitives (as, for example, by Mehta and Medvidovic [27]).While these approaches focus on the specification of architectural constraints rather than architectures,they do usually not allow for the specification of dynamic architectural constraints which is the focus of thiswork.
Recently, some attempts were made to model dynamic reconfigurations in an abstract, language independentmanner.
The first approaches in this area focused on plain structural evolution. Examples include the work of Le Mé-tayer [21], Hirsch and Montanari [17], and Mavridou et al. [26]. While these approaches focus on the specifi-cation of constraints for dynamic architectures, similar as for ADLs, the relation of behavioral and structuralaspects is not considered.
More recent approaches focus on the interrelation of behavior and configuration and are probably mostclosely related to our work.One prominent example here is the work of Wermelinger et al. [35, 34]. The authors introduce a graphbased architecture reconfiguration language based on the unity language [12]. The authors recognize thatthe interplay between topology and run-time behavior is important and so their language also allows for thespecification of reconfiguration constraints formulated over run-time behavior.Bruni et al. [9] provide a graph-based approach to dynamic reconfiguration. Reconfigurations are modeledas typed graph grammars. Also here, the authors provide a mechanism to express architectural constraints.Another approach in this area is the one of Batista et al. [4] where reconfiguration is specified as a set ofreconfiguration rules. In a reconfiguration rule, a predicate is specified to trigger a reconfiguration and theresult of a reconfiguration is specified in terms of attach and detach operations.While these works actually recognize the relationship of behavior and state in the specification of dy-namic reconfigurations, they usually focus on the specification of concrete architecture instances, rather thanarchitecture constraints. The specification of constraints is only of secondary rule which is why they usuallyfocus on the specification of static architecture constraints rather than dynamic once.
Work in this area focus on the specification of dynamic reconfiguration constraints and is most closely relatedto our work. However, to the best of our knowledge there exist only three approaches in this area. In thefollowing we are going to discuss each of them in more detail.One of the first approaches in this area is from Dormoy et al. [14] who provide a temporal logic for dynamicreconfiguration called FTPL. FTPL allows for the specification of component architecture evolution whichis modeled by a transition system over architecture configurations and so-called evolution operations. WhileFTPL is very promising, it focuses on the temporal aspect. Thus, we complement their work by providingexplicit specification techniques for data-types, interfaces and architecture configurations as well.Castro et al. [11] provides a categorical approach to model dynamic architecture reconfigurations interms of institutions. While the approach provides fundamental insights into the specification of dynamic architecture properties, their model remains implicitly in the categorical constructions. Thus, we complementtheir work by providing an explicit model of dynamic architecture properties.Another example is the one of Fiadeiro and Lopes [15] who provide an approach similar to ours. Intheir approach they use a rather abstract notion of state and configuration. While this makes the approachwidely applicable, it has to be specialized for different domains. Indeed, our work can actually be seen asa specialization of their model by providing a concrete notion of state (as ports valuated by messages) andconfiguration (as connection of component ports).
10. Conclusion
With this article we provide a formal approach for the specification of properties for dynamic architecturesby means of architecture constraints.To this end, we first introduce an abstract model for dynamic architectures (Sect. 2). Thereby, an archi-tecture is modeled as a set of configuration traces which are sequences over architecture configurations. Anarchitecture configuration, on the other hand, is a set of active components and connections between theirports. A component consists of input, output, and local ports and a valuation of its ports with messages.Components are not allowed to change their interface over time, nor are they allowed to change the valuationof their local ports over time (since they act as a kind of configuration parameter).In Sect. 3-Sect. 6 we then describe the details of our approach to specify constraints for dynamic archi-tectures: • First, a signature is specified defining the basic sorts, function, and predicate symbols. • Then, datatypes are specified in terms of algebraic specification techniques over the signature (Sect. 3). • Also interfaces are specified over the signature. An interface specification defines a set of interfaces whichconsist of an identifier and corresponding ports. An interface specification allows for the specification ofcomponent types by associating interfaces with invariants formulated as over its ports (Sect. 4). • Finally, architecture constraints are formulated over the interface specification by means of configura-tion assertions, i.e., linear temporal formulas over the interfaces (Sect. 6). To this end, activation andconnection predicates are introduced to express activation and connection constraints, respectively.For each specification technique a formal description of its syntax as well as its semantics in terms of ourmodel introduced in Sect. 2 was provided.To support in the specification process the notion of configuration diagram was introduced in Sect. 6 asa graphical notation to specify interfaces and certain common activation and connection constraints. To thisend, the notion of activation and connection annotations was introduced to easily express certain commonactivation and connection constraints.The approach allows to specify constraints for dynamic architectures. Therefore, it is well-suited for thespecification of patterns for such architectures and enables formal analyses of such patterns as discussedin Sect. 7. This is demonstrated by a running example in which we specify the Blackboard architecturepattern and verify one of its key characteristic properties. Therefore, with our work we complement exist-ing approaches for the specification of dynamic architectures which focus on the specification of concretearchitecture instances rather than properties.Future work arises in three major directions: (i) To support in the verification of specifications we arecurrently implementing of our approach for the interactive theorem prover Isabelle/HOL. (ii) On the the-oretic side we are interested in a calculus of dynamic architectures to support the reasoning of dynamicarchitectures. (iii) Finally, we are working on an integration of our approach into current ADLs to supportthe specification of architecture constraints for those ADLs.
11. Acknowledgements
We would like to thank Veronika Bauer, Mario Gleirscher, Vasileios Koutsoumpas, Xiuna Zhu, and all theanonymous reviewers for their comments and helpful suggestions on earlier versions of the paper. n the Specification of Constraints for Dynamic Architectures 37
References [1] Gregory D Abowd, Robert Allen, and David Garlan. Formalizing style to understand descriptions of softwarearchitecture.
ACM Transactions on Software Engineering and Methodology (TOSEM) , 4(4):319–364, 1995.[2] Robert Allen, Remi Douence, and David Garlan. Specifying and analyzing dynamic software architectures. In
Fundamental Approaches to Software Engineering , pages 21–37. Springer, 1998.[3] Robert J Allen. A formal approach to software architecture. Technical report, DTIC Document, 1997.[4] Thais Batista, Ackbar Joolia, and Geoff Coulson. Managing dynamic reconfiguration in component-based sys-tems. In
Proceedings of the 2Nd European Conference on Software Architecture , EWSA’05, pages 1–17, Berlin,Heidelberg, 2005. Springer-Verlag.[5] Marco Bernardo, Paolo Ciancarini, and Lorenzo Donatiello. On the formalization of architectural types withprocess algebras. In
ACM SIGSOFT Software Engineering Notes , volume 25, pages 140–148. ACM, 2000.[6] Manfred Broy. Algebraic specification of reactive systems. In
International Conference on Algebraic Methodologyand Software Technology , pages 487–503. Springer, 1996.[7] Manfred Broy. A logical basis for component-oriented software and systems engineering.
The Computer Journal ,53(10):1758–1782, 2010.[8] Manfred Broy. A model of dynamic systems. In Saddek Bensalem, Yassine Lakhneck, and Axel Legay, editors,
From Programs to Systems. The Systems perspective in Computing , volume 8415 of
Lecture Notes in ComputerScience , pages 39–53. Springer Berlin Heidelberg, 2014.[9] Roberto Bruni, Antonio Bucchiarone, Stefania Gnesi, Dan Hirsch, and Alberto Lluch Lafuente. Graph-based designand analysis of dynamic software architectures. In
Concurrency, Graphs and Models , pages 37–56. Springer, 2008.[10] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal. A system of patterns:Pattern-oriented software architecture. 1996.[11] Pablo F Castro, Nazareno M Aguirre, Carlos Gustavo López Pombo, and Thomas SE Maibaum. Towards managingdynamic reconfiguration of software systems in a categorical setting. In
Theoretical Aspects of Computing–ICTAC2010 , pages 306–321. Springer, 2010.[12] K Mani Chandy.
Parallel program design . Springer, 1989.[13] Eric M Dashofy, André Van der Hoek, and Richard N Taylor. A highly-extensible, xml-based architecture descrip-tion language. In
Software Architecture, 2001. Proceedings. Working IEEE/IFIP Conference on , pages 103–112.IEEE, 2001.[14] Julien Dormoy, Olga Kouchnarenko, and Arnaud Lanoix. Using temporal logic for dynamic reconfigurations ofcomponents. In
Formal Aspects of Component Software , pages 200–217. Springer, 2010.[15] José Luiz Fiadeiro and Antónia Lopes. A model for dynamic reconfiguration in service-oriented architectures.
Software & Systems Modeling , 12(2):349–367, 2013.[16] David Garlan. Formal modeling and analysis of software architecture: Components, connectors, and events. In
Formal Methods for Software Architectures , pages 1–24. Springer, 2003.[17] Dan Hirsch and Ugo Montanari. Two graph-based techniques for software architecture reconfiguration.
ElectronicNotes in Theoretical Computer Science , 51:177–190, 2002.[18] Charles Antony Richard Hoare. Communicating sequential processes.
Communications of the ACM , 21(8):666–677,1978.[19] Thomas Hungerford.
Abstract algebra: an introduction . Cengage Learning, 2012.[20] Paola Inverardi and Alexander L Wolf. Formal specification and analysis of software architectures using thechemical abstract machine model.
Software Engineering, IEEE Transactions on , 21(4):373–386, 1995.[21] Daniel Le Métayer. Describing software architecture styles using graph grammars.
Software Engineering, IEEETransactions on , 24(7):521–533, 1998.[22] David C Luckham, John J Kenney, Larry M Augustin, James Vera, Doug Bryan, and Walter Mann. Specificationand analysis of system architecture using rapide.
Software Engineering, IEEE Transactions on , 21(4):336–354,1995.[23] Jeff Magee and Jeff Kramer. Dynamic structure in software architectures.
ACM SIGSOFT Software EngineeringNotes , 21(6):3–14, 1996.[24] Zohar Manna and Amir Pnueli.
The temporal logic of reactive and concurrent systems: Specification . SpringerScience & Business Media, 2012.[25] Diego Marmsoler and Mario Gleirscher. Specifying properties of dynamic architectures using configuration traces.In
Theoretical Aspects of Computing–ICTAC 2016 . Springer, 2016.[26] Anastasia Mavridou, Eduard Baranov, Simon Bliudze, and Joseph Sifakis. Configuration logics: Modelling archi-tecture styles. In Christiano Braga and Peter Csaba Ölveczky, editors,
Formal Aspects of Component Software -12th International Conference, FACS 2015, Niterói, Brazil, October 14-16, 2015, Revised Selected Papers , volume9539 of
Lecture Notes in Computer Science , pages 256–274. Springer, 2015.[27] Nikunj R Mehta and Nenad Medvidovic. Composing architectural styles from architectural primitives. In
ACMSIGSOFT Software Engineering Notes , volume 28, pages 347–350. ACM, 2003.[28] Mark Moriconi, Xiaolei Qian, and Robert A Riemenschneider. Correct architecture refinement.
Software Engi-neering, IEEE Transactions on , 21(4):356–372, 1995.[29] Flavio Oquendo. π -adl: an architecture description language based on the higher-order typed π -calculus for speci-fying dynamic and mobile software architectures. ACM SIGSOFT Software Engineering Notes , 29(3):1–14, 2004.[30] John Penix, Perry Alexander, and Klaus Havelund. Declarative specification of software architectures. In
AutomatedSoftware Engineering, 1997. Proceedings., 12th IEEE International Conference , pages 201–208. IEEE, 1997.8 D. Marmsoler[31] Mary Shaw and David Garlan.
Software architecture: perspectives on an emerging discipline , volume 1. PrenticeHall Englewood Cliffs, 1996.[32] J Michael Spivey and JR Abrial.
The Z notation . Prentice Hall Hemel Hempstead, 1992.[33] Richard N Taylor, Nenad Medvidovic, and Eric M Dashofy.
Software architecture: foundations, theory, and practice .Wiley Publishing, 2009.[34] Michel Wermelinger and José Luiz Fiadeiro. A graph transformation approach to software architecture recon-figuration.
Science of Computer Programming , 44(2):133 – 155, 2002. Special Issue on Applications of GraphTransformations (GRATRA 2000).[35] Michel Wermelinger, Antónia Lopes, and José Luiz Fiadeiro. A graph based architectural (re) configurationlanguage. In
ACM SIGSOFT Software Engineering Notes , volume 26, pages 21–32. ACM, 2001.[36] Martin Wirsing.
Algebraic specification . MIT Press, 1991.
12. Appendix A: Conventions
In the following we introduce some conventions used throughout the paper.
Definition 34 (Inverse function).
For a function f : A → B , we denote by f − : B → ℘ ( A ) , the inverse function of f . Definition 35 (Bijective function).
With A ↔ B we denote a bijective function from A to B . Definition 36 (Projection).
For an n-tuple C = ( c , . . . , c n ) , we denote by [ c ] i = c i with ≤ i ≤ n the projection to the i -th component of C . Definition 37 (Partial function).
We denote by X Y , the set of partial functions from a set X to aset Y : X Y def = { f ⊆ X × Y | ∀ x ∈ X, y , y ∈ Y :(( x, y ) ∈ f ∧ ( x, y ) ∈ f ) = ⇒ y = y } . For a partial function f : X Y , we denote by: • dom ( f ) = { x ∈ X | ∃ y ∈ Y : f ( x ) = y } , the set of elements for which f is defined, and with • ran ( f ) = { y ∈ Y | ∃ x ∈ X : f ( x ) = y } , the set of elements returned by f . • By f | X ′ : X ′ Y , such that ∀ x ∈ X ′ : f | X ′ ( x ) = f ( x ) , the restriction of f to the set X ′ ⊆ X . Definition 38 (Cartesian power).
For a set S and number n ∈ N we denote with S n the cartesian power of S to n : S n = { ( s , . . . , s n ) | s i ∈ S for all i = 1 , . . . , n } . (30) Definition 39 (Function update).
For a function f : D → R and elements d ∈ D and r ∈ R , we denotewith f [ d r ] : D → R a function which is equal to f but maps d to r : f [ d r ]( x ) def = (cid:26) r if x = d ,f ( x ) else . (31)For a family of functions F = ( F i ) i ∈ I with index set I , index j ∈ I , function F j : D → R , elements d ∈ D and r ∈ R , we denote by F [ j : d r ] a family where function F j is updated to F j [ d r ] . F [ j : d r ] i def = (cid:26) F i [ d r ] if i = j ,F i else . (32) Definition 40 (Function merge).
Given functions f : D f → R f and g : D g → R g , with disjoint D s and R s, we denote with f ∪ g : ( D f ∪ D g ) → ( R f ∪ R g ) the merge of the two functions: ( f ∪ g )( x ) def = (cid:26) f ( x ) if x ∈ D f ,g ( x ))