π-AAL

ACM SIGSOFT Software Engineering Notes March 2006 Volume 31 Number 2

1

π-AAL: An Architecture Analysis Language for Formally Specifying and Verifying Structural and Behavioural Properties of Software Architectures

Radu Mateescu INRIA Rhône-Alpes – VASY Group

ENS Lyon – LIP – PLUME 46, allée d’Italie – 69364 Lyon Cedex 07 – France

[email protected]

Flavio Oquendo University of South Brittany

VALORIA – Formal Software Architecture Group B.P. 573 – 56017 Vannes Cedex – France

[email protected]

Abstract A key aspect of the design of any software system is its architec-ture. An architecture description, from a runtime perspective, pro-vides a formal representation of the architecture in terms of its components and connectors, their ports and behaviours, and how they are composed together. In the past decade, several Architec-ture Description Languages (ADLs) have been defined for repre-senting the structure and behaviour of software architectures. However, describing the structure and behaviour of an architecture in terms of a configuration of components and connectors is needed, but it is not enough. Indeed, in addition to representing software architectures, we need to rigorously specify their required and desired architectural properties, in particular related to com-pleteness, consistency and correctness. This article presents π-AAL, a novel Architecture Analysis Language (AAL) that has been designed in the ArchWare European Project to address for-mal analysis of software architectures. It is a formal, well-founded theoretically language based on the modal µ-calculus designed to enable the specification of structural and behavioural properties and their verification using an analytical toolset based on theorem proving and model checking techniques.

Keywords: Architecture Analysis Languages, Property Specifica-tion, Property Verification, Software Architectures, Formal De-velopment Techniques

1. Introduction Software architecture has emerged as an important subdiscipline of software engineering. Key aspects of the formal development of any software system are the description, analysis, and refinement of its architecture, i.e., the fundamental organisation of the system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evo-lution [24].

From a runtime perspective, an architecture description provides a formal representation of the architecture in terms of its structure and behaviour.

The structure may be specified in terms of:

• components (units of computation of a system), • connectors (interconnections among components for support-

ing their interactions), • configurations of components and connectors.

The behaviour may be specified in terms of:

• actions a system executes or participates in, • relations among actions to specify behaviours, • behaviours of components and connectors, and how they in-

teract.

In the past decade, several Architecture Description Languages (ADLs) have been defined for representing the structure and be-haviour of software architectures. However, describing the struc-ture and behaviour of an architecture in terms of a configuration of components and connectors is needed, but it is not enough. In-deed, in addition to representing software architectures, we need to rigorously specify their required and desired architectural prop-erties, in particular related to completeness, consistency and cor-rectness.

Therefore, an Architecture Analysis Language (AAL) must com-plement (or be part of) an ADL in order to specify and support verification of architecture-related semantic properties. A major challenge for an AAL is to provide sufficient expressive power to specify both structural and behavioural properties, including prop-erties that can interleave both structural and behavioural aspects, and to be well-suited for machine-automated processing for verifi-cation, at a time.

Architecture-centric formal development encompasses the descrip-tion, analysis, and refinement of software architectures.

application architect

refine & analyse

architecture description

refinement of

describe & analyse

generated from

application

architectural properties

Figure 1. Architecture-centric Formal Development

Figure 1 depicts the overall approach of architecture-centric for-mal development. For instance, with respect to analysis, once a software architect has described a software architecture s/he would

mailto:[email protected]


2

like to check if it is complete, consistent and correct with respect to architectural properties that could be specific to an application, a family of applications, or an architectural style. Moreover, once an architecture description is refined, the refined architecture must preserve and thereby satisfy the required properties.

This article describes the π-Architecture Analysis Language (π-AAL) [4] that provides a uniform framework for specifying rele-vant properties of software architectures. These properties have different natures: they can be structural (e.g., cardinality of archi-tectural elements, interconnection topology) or behavioural (e.g., safety, liveness, and fairness defined on actions of the system). π-AAL complements π-ADL [41][44] with features allowing archi-tects to express and verify properties of software architectures and styles in a natural way. Analysis is intended to be performed ac-cording to two approaches: model checking and theorem proving.

The remainder of this article is organised as follows. Section 2 introduces π-AAL design principles and section 3 the architecture description concepts underlying π-ADL. Section 4 presents π-AAL concepts and notation. Section 5 illustrates through a case study how π-AAL can be used for specifying structural and behav-ioural properties. In section 6, we compare π-AAL with related work. To conclude we summarise, in section 7, the main contribu-tions of this article and briefly outline the π-AAL toolset for sup-porting architecture specification and verification.

2. Design Principles π-ADL [41][43][44], π-AAL and π-ARL [42][40] are companion languages for architecture description, analysis and refinement, respectively. With π-ADL, architectures are described, expressing their components, connectors, and their interconnections. With π-ARL, architecture descriptions can be transformed while enforcing refinement. π-AAL provides the language to specify proof obliga-tions to guarantee the completeness, consistency and correctness of the architecture descriptions and their refinements. It provides the core constructs for specifying structural and behavioural analyses of software architectures, including static and dynamic ones.

The following principles guided the design of π-AAL:

• π-AAL is a formal language: it provides a formal system (at the mathematical sense) for specifying properties and reason-ing about them;

• π-AAL is defined in a layered approach, with a core canonical abstract syntax and formal semantics, to be well-suited for machine-automated processing for verification;

• π-AAL offers a user-friendly enhanced concrete syntax to be easily used by software architects.

The π-AAL is a formal property expression language designed to support automated verification. Thereby, one can mechanically check whether an architecture described in π-ADL satisfies a property expressed in π-AAL.

The π-AAL has as formal foundation the modal µ-calculus [28], a calculus for expressing properties of labelled transition systems by using least and greatest fixed point operators. π-AAL is itself a

formal language defined as an extension of the µ-calculus: it is a well-formed extension for defining a calculus for expressing struc-tural and behavioural properties of communicating and mobile architectural elements.

The π-AAL takes its roots in previous work concerning the exten-sion of modal operators with data-handling constructs [33], the use of regular expressions as specification formalism for value-passing process algebras [17], and the extension of fixed point operators with typed parameters [22].

Indeed, a natural candidate for “pure” behavioural properties would be the modal µ-calculus, which is a very expressive fixed point-based formalism subsuming virtually all temporal logics defined so far in the literature [49]. However, since π-AAL must also provide features for expressing structural properties of archi-tectures [5], the modal µ-calculus is not sufficient. Therefore, a formalism encompassing both the predicate calculus and the mo-dal µ-calculus is needed. The π-AAL is, thereby, this encompass-ing formalism, defined as a domain-specific extension of the µ-calculus.

The π-AAL combines predicate logic with temporal logic in order to allow the specification of both structural and behavioural prop-erties. It enables automated verification of property satisfaction by model checking (through on-the-fly model checking) and theorem proving (through deductive verification).

3. Architecture Description with π-ADL Software architectures can be described with π-ADL that is a for-mal, well-founded theoretically language based on the higher-order typed π-calculus [36][48].

In π-ADL, an architecture is described in terms of components, connectors, and their composition. Figure 2 depicts its main con-stituents.

value passing

component

connection

connector

behaviour port

Figure 2. Architectural concepts in π-ADL

Components are described in terms of external ports and an inter-nal behaviour. Their architectural role is to specify computational elements of a software system. The focus is on computation to deliver system functionalities.

Ports are described in terms of connections between a component and its environment. Their architectural role is to put together con-nections providing an interface between the component and its environment. Protocols may be enforced by ports and among ports.


3

Connections are basic interaction points. Their architectural role is to provide communication channels between two architectural elements.

A component can send or receive values via connections. They can be declared as output connections (values can only be sent), input connections (values can only be received), or input-output connections (values can be sent or received).

Connectors are special-purpose components. They are described as components in terms of external ports and an internal behav-iour. However, their architectural role is to connect together com-ponents. They specify interactions among components.

Therefore, components provide the locus of computation, while connectors manage interaction among components. A component cannot be directly connected to another component. In order to have actual communication between two components, there must be a connector between them.

Both components and connectors comprise ports and behaviour. In order to attach a port of a component to a port of a connector, at least a connection of the former port must be attached with a con-nection of the later port. A connection provided by a port of a component is attached to a connection provided by a port of a con-nector by unification or value passing. Thereby, attached connec-tions can transport values (that can be data, connections, or even architectural elements).

Components and connectors can be composed to construct com-posite elements (see Figure 3), which may themselves be compo-nents or connectors.

composite

Figure 3. Architectural composition in π-ADL

Architectures are composite elements representing systems. An architecture can itself be a composite component in another archi-tecture, i.e., a sub-architecture.

4. Property Specification with π-AAL π-AAL supports analysis of software architectures, described with π-ADL, from structural and behavioural perspectives. In π-AAL, an architectural property is specified in terms of logical formulas comprising: predicate formulas, action formulas, regular formulas, state formulas, and connection formulas. When evaluated, a for-mula is checked against the architecture description, that provides the interpretation domain.

4.1 Semantic Model The formal foundation of π-AAL is the modal µ-calculus extended

with the predicate calculus. π-AAL is itself a formal language de-fined as an extended calculus subsuming the modal µ-calculus and the predicate calculus for expressing properties on architectures.

Formulas in π-AAL are formally interpreted relative to a predi-cate-extended labelled transition system.

Formally, a predicate-extended labelled transition system (pLTS) is of the form pLTS = (StateSet, ActionSet, TransitionRelationSet, PredicateSetLabelling, state0), where:

• StateSet is a non-empty set of states, • ActionSet is a set of actions (actions that label transitions), • TransitionRelationSet is a set of transition relations, such that

each transition relation transition ∈ TransitionRelationSet, is of the form transition ⊆ StateSet × ActionSet × StateSet,

• PredicateSetLabelling : StateSet → 2PredicateSet is a function that labels each state with the set of atomic predicates true in that state (where PredicateSet is the set of atomic predicates and 2PredicateSet the powerset of PredicateSet),

• state0 ∈ StateSet is the initial state.

All states of StateSet are assumed to be reachable from the initial state via sequences of (zero or more) transitions of the Transition-RelationSet.

The actions action of ActionSet are defined as:

action ::= via connection send value1,…, valuen

| via connection receive value1,…, valuen

where connection is a connection and value1,…, valuen are data values (base values or constructed values).

In addition to communication actions, actions can be internal to a component or connector:

• the action unobservable, where unobservable ∉ ActionSet, is used to model an internal “unobservable” action of a compo-nent or connector behaviour,

• the match action if, is used to express conditional behaviours of components or connectors.

The predicates predicate of PredicateSet are defined either as built-in predicates related to the architectural structure, or as user defined predicates.

Finally we can define BehaviourStateSet as the set of states of a behaviour in an architectural element (e.g., component or connec-tor). Therefore for all s ∈ BehaviourStateSet, PredicateSet con-tains all predicates related to types and data declared in an architectural element expressed with π-ADL.

For a complete definition of the π-AAL semantic model see [4].

4.2 Abstract Syntax Notation The basis for defining the π-AAL semantics is its abstract syntax, which is defined using the following notation for the abstract pro-duction rules:

• keywords are written with bold; • non-terminals are written without bold;


4

• a sequence of zero, one or more elements is written: Ele-mentmin, …, Elementmax, where the value of min specifies the minimum number of elements (0 specifies possibly no ele-ments, 1 specifies at least one element) and the value of max specifies the maximum number of elements (Elementn speci-fies any number of elements);

• alternative choices are written separated by |.

4.3 Types π-AAL is a typed language. π-AAL shares all base types and type constructors provided in π-ADL and π-ARL, equipped with their corresponding operators.

The abstract syntax of types is defined as follows.

Abstract syntax of types

syntax of types

ValueType ::= BaseType

| ConstructedType

syntax of type environments

∆ ::= ∆, name : ValueType

| ∅

Figure 4. Abstract syntax of value types

As shown in Figure 4, all types are value types. Value types are base types or constructed types. Type environments are expressed through declarations. A value can be declared as being of a base type or a constructed type. The abstract syntax of base types and of constructed types are defined in Figure 5 and Figure 6, respec-tively.

Abstract syntax of base types

BaseType ::= Any

| Natural

| Integer

| Real

| Boolean

| String

| Behaviour

Figure 5. Abstract syntax of base types

Abstract syntax of constructed types

ConstructedType ::= tuple [ ValueType1, …, ValueTypen ]

| view [ label1 : ValueType1, …, labeln : ValueTypen ]

| union [ ValueType1, …, ValueTypen ]

| quote [ name ]

| variant [ label1 : ValueType1, …, labeln : ValueTypen ]

| location [ ValueType ]

| sequence [ ValueType ]

| set [ ValueType ]

| bag [ ValueType ]

| inout [ ValueType ] | in [ ValueType ] | out [ ValueType ]

| ValueType0, …, ValueTypen → Behaviour

Figure 6. Abstract syntax of constructed types

4.4 Kinds of Formulas π-AAL provides the formula constructs for specifying structural and behavioural properties to be satisfied by static or dynamic software architectures.

The definition of π-AAL is structured in terms of kinds of formula constructs:

• predicate formula constructs for writing data predicate formu-las over a set of data values using data variables, data opera-tors and predicate operators,

• action formula constructs for writing action predicate formu-las over a set of connection and data values,

• regular formula constructs for writing regular expressions (i.e., regular formulas) defined over action formulas using regular operators,

• state formula constructs for writing modal formulas defined over regular formulas and value variables using predicate, modal, and parameterised fixed point operators,

• connection formula constructs for writing formula on connec-tions as first-class elements, taking into account connection mobility among architectural elements, i.e., components and connectors.

Thereby, a formula is a data predicate formula, an action formula, a regular formula or a state formula as shown in Figure 7.

Abstract syntax of formulas

Formula ::= predicateFormula

| actionFormula

| regularFormula

| stateFormula

Figure 7. π-AAL kinds of formulas


5

In the sequel, each one of these kinds of formula will be further presented, using the abstract syntax, and illustrated with the fol-lowing example, which specifies a simplified version of a pipe-and-filter architecture, shown in Figure 8. This architecture con-sists of two components (that are filters) which exchange data through a connector (that is a pipe).

F1 F2Po1 i2i1 o2

A very simple pipe-and-filter architecture(a pipeline)

Figure 8. A very simple pipe-and-filter architecture

The filters F1 and F2 receive data on their input connections i1 and i2, transform it, and then emit it on their output connections o1 and o2. The pipe P has the role of transmitting data between the filters. In this example, the pipe is assumed to be unreliable, i.e., it can nondeterministically choose either to transmit data cor-rectly, or to lose it. For the sake of simplicity, we do not model the ports attached to architectural elements.

4.5 Predicate Formulas The predicate formula constructs enable to write data predicate formulas over a set of data values using data variables, data opera-tors and predicate operators.

Data expressions are defined by the following abstract syntax.

Abstract syntax of data expressions

value ::= variable | function (value1, …, valuen)

where function(value1, …, valuen) can be any in-line data expression

Figure 9. Abstract syntax of data expressions

In data expressions, in order to apply a function to all elements of a collection (i.e., a sequence, a set, or a bag) the dot operator ‘.’ is used. To apply a function to the collection as a whole, the ‘−>’ operator is used.

The abstract syntax for navigational application is as follows.

Abstraction syntax of navigational application

value ::= collectionValue . function (value1,…,value2)

| collectionValue −> function (value1,…,value2)

where collectionValue is a sequence, set, or bag

Figure 10. Abstract syntax of navigational application

Data value expressions are used in predicate formulas, action for-mulas, state formulas, and connection formulas.

Predicate formulas are formulas of the first-order predicate calcu-lus built using data value expressions as terms.

Predicate formulas are defined by the following abstract syntax.

Abstract syntax of predicate formulas

predicateFormula ::= value

| false

| not predicateFormula

| predicateFormula1 or predicateFormula 2

| exists variable : Type . predicateFormula

where value is of boolean type and boolean literals are false and true

Figure 11. Abstract syntax of predicate formulas

The semantics of a predicate formula PredicateFormula in a data context ε (which must assign values to all variables present in Pre-dicateFormula), noted [[ PredicateFormula ]] ε ∈ Boolean, is defined inductively (as detailed in [4]). The formal semantics of predicate formulas is defined in terms of interpretation functions, defined themselves in terms of classical truth tables.

Derived predicate operators are defined as usual, as follows.

Derived predicate operators

true = not false

predicateFormula1 and predicateFormula2 = not (not predicateFormula 1 or not predicateFormula 2)

predicateFormula1 xor predicateFormula2 (predicateFormula1 or predicateFormula2) and not (predicateFormula1 and predicateFormula2)

predicateFormula1 implies predicateFormula 2 = not predicateFormula1 or predicateFormula2

predicateFormula1 equivalent predicateFormula2 = (predicateFormula1 implies predicateFormula2) and (predicateFormula2 implies predicateFormula1)

Figure 12. Derived predicate operators


6

The universal quantifier is defined as follows.

Universal predicate quantifier

forall variable : Type . predicateFormula = not exists variable : Type . not predicateFormula

Figure 13. Universal predicate quantifier

Let us illustrate predicate formulas using the pipe-and-filter exam-ple introduced so far.

Predicate formulas are useful for expressing structural properties concerning e.g., the connectivity between architectural elements. An example of connectivity property is specified by the following formula:

forall f1, f2 : Filter . forall c1, c2 : Connection . ((f1.connections −> includes c1) and (f2.connections −> includes c2)) implies not connect (c1, c2)

This predicate formula states that a filter of the architecture cannot be connected directly to another filter. Here, connections is an operator calculating the set of connections attached to an architec-tural element f; the predicate connect(c1, c2) expresses that two connections c1 and c2 are connected; and the operator includes checks the membership of a connection to a set.

Another example of connectivity property is given by the follow-ing formula:

forall f : Filter . exists c1, c2 : Connection . exists p : Pipe . ((f.connections −> includes c1) and (p.connections −> includes c2)) and connect (c1, c2)

This predicate formula states that each filter of the architecture is directly connected to at least one pipe.

4.6 Action Formulas The action formula constructs enable to write action predicate formulas over a set of connection and data values.

Action formulas are defined according to the following abstract syntax.

Abstract syntax of action formulas

actionFormula ::= action

| actionWithWildcard

| unobservable

| false

| not actionFormula

| actionFormula1 or actionFormula2

| exists variable : Type . actionFormula

action ::= via name send value1,…, valuen

| via name receive value1,…, valuen

actionWithWildcard ::= via name send any

| via name receive any

Figure 14. Abstract syntax of action formulas

Derived boolean operators are defined as usual, as follows.

Derived action operators

true = not false

actionFormula1 and actionFormula2 = not (not actionFormula 1 or not actionFormula 2)

actionFormula1 xor actionFormula2 (actionFormula1 or actionFormula2) and not (actionFormula1 and actionFormula2)

actionFormula1 implies actionFormula 2 = not actionFormula1 or actionFormula2

actionFormula1 equivalent actionFormula2 = (actionFormula1 implies actionFormula2) and (actionFormula2 implies actionFormula1)

Figure 15. Derived action operators


Universal action quantifier

forall variable : Type . actionFormula = not exists variable : Type . not actionFormula

Figure 16. Universal action quantifier

The action predicate via name send e1, ..., en or via name receive e1, ..., en denotes all actions of the corresponding form via name send v1, ..., vn or via name receive v1, ..., vn where v1, ..., vn are data values that must be pairwise equal to the expressions e1, ..., en


7

(evaluated in a given data context). The predicate with wildcard any denotes all actions of the corresponding form regardless of the data values v1, ..., vn.

The boolean connectives and the quantifiers have the usual mean-ing.

The semantics of an action formula actionFormula in a context ε (which must assign values to all variables present in actionFor-mula), noted [[ actionFormula ]] ε ⊆ ActionSet, is defined induc-tively (as detailed in [4]).

In the presence of quantifiers, the sets of free variables fv(actionFormula) and bound variables bv(actionFormula) in an actionFormula are defined in the usual way. An actionFormula is said closed iff fv(actionFormula) = ∅ and is said in normal form iff fv(actionFormula) ∩ bv(actionFormula) = ∅.

Let us consider again the simplified pipe-and-filter architecture introduced so far. The pLTS model of this architecture is shown in the figure below. It is sufficiently simple to be inspected visually, and sufficiently complex to allow the illustration of interesting properties.

i1

i1

i1

i1

i1 i2i2

o1

o1 o1

o1o2

o2

o2

o2

pLTS model of the simplified pipe-and-filter architecture(9 states, 15 transitions)

Figure 17. pLTS model of the simple pipe-and-filter architecture

Action formulas are useful for characterizing subsets of ActionSet that will be used later in order to illustrate more complex temporal formulas. The simplest way of characterizing a set of actions is to use a disjunction predicate having a disjunct for every action in the set. For instance, the following formula:

(via i1 send any) or (via i2 send any)

denotes the set of actions { i1, i2 } ⊆ ActionSet.

Action sets can be characterized in a more elaborated manner by combining action formulas and other boolean operators. For in-stance, the following formula:

((via i1 send any) or (via i2 send any) or (via o1 receive any))

and ((via o1 receive any) or (via o2 receive any))

denotes the set { o1 } ⊆ ActionSet.

The empty action set ∅ is characterized by formula false, and the full set ActionSet is characterized by formula true.

4.7 Regular Formulas The regular formula constructs enable to write regular expressions (i.e., regular formulas) defined over action formulas using regular operators.

Indeed, a useful extension of temporal logics consists of introduc-ing regular constructs, which provide a more user-friendly way of specifying properties than fixed point operators. A number of such proposals exist in the literature, going from the early extensions of LTL with regular grammars [53] to extensions of the modal µ-calculus with regular modalities [34] similar to the operators of PDL [14] and PDL-∆ [51].

For defining regular formulas in π-AAL, the latter approach is adopted. The regular formulas of the language are defined accord-ing to the following abstract syntax.

Abstract syntax of regular formulas

regularFormula ::= actionFormula

| regularFormula1 . regularFormula2

| regularFormula1 | regularFormula 2

| regularFormula*

Figure 18. Abstract syntax of regular formulas

Intuitively, a regular formula regularFormula denotes a sequence of transitions in the pLTS. Regular formulas are built upon action predicates (one-step sequences) by using the standard regular op-erators: ‘.’ (concatenation), ‘|’ (choice), and ‘*’ (transitive reflex-ive closure).

Derived regular operators can be defined as usual, as follows.

Empty sequence operator

nil = false*

Transitive closure operator

regularFormula + = regularFormula . regularFormula *

Figure 19. Derived regular operators

The notions of free and bound data variables are defined for regu-lar formulas by extending the corresponding notions defined for action formulas. A regular formula regularFormula is said closed if fv(regularFormula) = ∅.

The semantics of a regular formula regularFormula in a data con-


8

text ε (which must initialise all free data variables of regularFor-mula), noted || regularFormula || ε ⊆ StateSet × StateSet, is de-fined inductively (as detailed in [4]).

When specifying regular formulas, there are a number of useful algebraic properties, inherited from regular language theory, which allow to simplify formulas. The figure below shows a (non exhaustive) list of these properties.

(R1 . R2) . R3 = R1 . (R2 . R3) associativity of concatenationnil . R = R . nil = R neutral element for concatenation

(R1 | R2) . R3 = R1 | (R2 | R3) associativity of choiceR1 | R2 = R2 | R1 commutativity of choicetrue* | R = R | true* = true* absorbing element for choice

R1 . R2 | R1 . R3 = R1 . (R2 | R3) distributivity of concatenationR1 . R3 | R2 . R3 = (R1 | R2) . R3 over choice

nil | R* = R* absorption of empty sequenceR1* . R2 = R2 | R1 . R1* . R2 Arden’s rule

Figure 20. Useful algebraic properties

Regular formulas are natural extensions of PDL regular expres-sions with data variables and quantifiers. From a theoretical point of view, regular formulas do not increase the expressiveness of the language (because they can be translated in modal µ-calculus us-ing fixed point operators), but from a practical point of view they allow a much more concise and readable specification of proper-ties than plain modal µ-calculus.

Let us consider again the pLTS model of the simplified pipe-and-filter architecture introduced so far. In order to illustrate the inter-pretations of regular formulas, we identified each state by a natural number (the initial state is numbered 0).

pLTS model of the simplified pipe-and-filter architecture(with numbered states)

2

7

8

54 63

1

0

i1

i1

i1

i1

i1 i2i2

o1

o1 o1

o1o2

o2

o2

o2

Figure 21. pLTS model of the simple pipe-and-filter architecture

Simple execution sequences consisting of one action can be speci-fied using atomic regular formulas (i.e., action formulas). For in-stance, the following regular formula:

(via i1 send any) or (via o1 receive any)

denotes the relation { (s0, s1), (s1, s4), (s2, s5), (s3, s1), (s4, s7), (s5, s2), (s6, s2), (s7, s4), (s8, s6) }, i.e., all pairs of states which are source and target of a transition labelled by action i1 or by action o1.

Sequences consisting of several transitions can be characterized using the concatenation operator. For instance, the regular formula below:

(via i2 send any) . (not (via o2 receive any)) . (via i1 send any)

denotes the relation { (s7, s5) } containing the pair of states which are source and target of the sequence s7 →i2 s6 →o1 s2 →i1 s5.

Sets of sequences can be obtained using the choice operator, which is analogous to the union of regular languages. For instance, the following formula:

(via i1 send any) . (via i2 send any) | (via o1 receive any) . (via o2 receive any)

denotes the relation { (s4, s6), (s5, s4), (s6, s4) } containing all pairs of states which are source and target of two-step transition sequences consisting of two consecutive input actions or two con-secutive output actions performed by filters F1 and F2.

Sequences of finite but unbounded length can be characterized using the transitive-reflexive closure operator, which expresses the repetition of a sequence zero or more times. The following for-mula:


9

(via i1 send any) . (not ((via i2 send any) or (via o2 receive any)))* . (via i1 send any)

denotes the relation { (s0, s7), (s2, s2), (s3, s7), (s4, s4), (s8, s5) } containing the pairs of states which are source and target of transi-tion sequences consisting of two i1 actions separated by any num-ber of actions different from i2 and o2.

The empty sequence operator is useful in conjunction with the choice operator for reducing the complexity of certain regular for-mulas by factorisation of common subformulas. For instance, the regular formula below:

(not (via i1 send any))*. (via o1 receive any) | true*. (via o1 receive any) . (not (via i1 send any))*. (via o1 receive any)

which denotes the relation { (s1, s4), (s5, s2), (s5, s4), (s6, s2), (s6, s4), (s7, s4) }, can be rewritten in a more concise form:

(nil | true*. (via o1 receive any)) . (not (via i1 send any))*. (via o1 receive any)

where the suffix (not (via i1 send any))*. (via o1 receive any) has been factorised by using the distributivity of concatenation over choice and the fact that the empty sequence operator is neu-tral element for concatenation.

4.8 State Formulas The state formula constructs enable to write modal formulas de-fined over regular formulas and value variables using predicate, modal, and fixed point operators.

Let ParameterisedVariableSet be a set of (parameterised) proposi-tional variables. Each propositional variable Variable ∈ Parame-terisedVariableSet denotes a mapping from a data domain ValueSet denoted by its Type to the powerset of the state set State-Set, 2StateSet. The state formulas of the language (noted stateFor-mula) are defined according to the following abstract syntax.

Abstract syntax of state formulas

stateFormula ::= predicateFormula

| not stateFormula

| stateFormula1 or stateFormula2

| exists variable : Type . stateFormula

| ⟨ regularFormula ⟩ stateFormula

| Variable (value)

| (minimal fixpoint Variable (parameter : Type) . stateFormula) (value)

Figure 22. Abstract syntax of state formulas

The derived boolean connectives and the universal quantifier are defined as usual, as follows.

Derived state operators

true = not false

stateFormula1 and stateFormula2 = not (not stateFormula 1 or not stateFormula 2)

stateFormula1 xor stateFormula2 (stateFormula1 or stateFormula2) and not (stateFormula1 and stateFormula2)

stateFormula1 implies stateFormula 2 = not stateFormula1 or stateFormula2

stateFormula1 equivalent stateFormula2 = (stateFormula1 implies stateFormula2) and (stateFormula2 implies stateFormula1)

Figure 23. Derived state operators


Universal state quantifier

forall variable : Type . stateFormula = not exists variable : Type . not stateFormula

Figure 24. Universal state quantifier

The necessity operator ‘[ ]’is defined as the dual of the possibility operator denoted by angular brackets ‘⟨⟩’ as follows.

Necessity operator

[ regularFormula ] stateFormula = not ⟨ regularFormula ⟩ not stateFormula

Figure 25. Necessity operator

The maximal fixed point operator (usually noted ν) is defined as the dual of the minimal fixed point operator (usually noted µ) as follows.

Maximal fixpoint operator

(maximal fixpoint Variable (parameter : Type) . stateFormula) (value) = (not minimal fixpoint Variable (parameter : Type) . not stateFormula [not Variable / Variable]) (value)

Figure 26. Maximal fixpoint operator

where the notation stateFormula [not Variable / Variable] stands for the syntactic substitution of all free occurrences of Variable in stateFormula by not Variable.

Let us use σ to denote either µ or ν, i.e., the minimal fixed point or the maximal fixed point operators. In order to ensure a proper definition of the semantics of fixed point formulas, we require that state formulas are syntactically monotonic [28], i.e., for every


10

fixed point formula σ Variable (parameter : Type) . stateFormula, all free occurrences of Variable in stateFormula fall in the scope of an even number of negations.

In order to define the semantics of state formulas, we introduce propositional contexts ρ : ParameterisedVariableSet → (ValueSet of Type → 2StateSet), which are partial functions mapping proposi-tional variables to functions from data parameters to state sets. The notation ρ[g/Variable] stands for a propositional context identical to ρ except for variable Variable, which is assigned the function g : ValueSet of Type → 2StateSet (where ValueSet of Type is the type of Variable's parameter). The semantics of a state formula state-Formula in a propositional context ρ and a data context ε (which must assign functions and values to all free propositional variables and data variables of stateFormula, respectively), noted [[ state-Formula ]] ρε ⊆ StateSet, is defined inductively (as detailed in [4]).

The semantics of minimal fixed point operators is defined in a way similar to recursive functions in a functional language (i.e., as the minimal fixed point of a monotonic functional defined on a com-plete lattice). For closed state formulas stateFormula (i.e., formu-las without free data variables or propositional variables), their semantics is denoted by [[ stateFormula ]] because it does not depend upon any data context or propositional context.

Note that for expressing the satisfaction of a stateFormula in every state of a pLTS, the architect must use the formula [ true* ] stateFormula, which (when verified using a local model checker) ensures that all states reachable from the initial state via sequences of zero or more transitions satisfy stateFormula.

Let us illustrate now the interpretation of state formulas on the pLTS model of the simplified pipe-and-filter architecture intro-duced so far.

Modal operators allow to express simple formulas involving states and their outgoing transitions. For instance, the simple modal property below:

⟨ via o2 receive any ⟩ true

characterizes the states { s2, s5, s6, s8 }, which have an outgoing transition labelled by an output action of filter F2.

More complex modal properties can be obtained by using regular operators inside modalities. For instance, the following property:

⟨ (via i1 send any) . (via i2 send any) | (via o1 receive any) . (via o2 receive any) ⟩ true

denotes the state subset { s4, s5, s6 } containing all states which are origin of a two-step transition sequence of consecutive input actions or output actions.

Box modalities followed by false are useful for expressing the absence of certain undesirable transition sequences (safety proper-ties). For instance, the following property:

[ (nil | true*. via o1 receive any) . (not (via i1 send any))*. (via o1 receive any) ] false

denotes the states { s1, s5, s6, s7 } from which it is impossible to reach an output action of filter F1 (either from the current state, or from a future state following another output action) without exe-cuting an input action of the same filter. This characterizes the fact that filters can process only one data item at a time, i.e., from the communication point of view, they behave like one-slot buffers. Since the initial state does not satisfy this formula, the erroneous execution sequence above cannot appear in the behaviour of the system, and therefore the filter F1 indeed behaves like a one-slot buffer.

More complex branching-time properties, such as inevitable reachability of a certain property, can be expressed using fixed point operators. The formula below:

minimal fixpoint X . ⟨ true ⟩ true and [ not (via o1 receive any) ] X

characterizes the states starting at which all outgoing transition sequences lead, after a finite number of steps, to an output action of filter F1. It can be interpreted intuitively as follows: the current state (i.e.,, the state on which the propositional variable X is evalu-ated) has at least one successor, and all its successor transitions not labelled by an o1 action lead to states satisfying X. Since X is a minimal fixed point, after a finite number of steps a state having only o1-successors (i.e., a state satisfying the subformula ⟨ true ⟩ true and [ not (via o1 receive any) ] false) will be reached. This formula is satisfied by all states of the pLTS shown in Figure 17, which means that filter F1 can always eventually output a data, and therefore it does never block.

Maximal fixed point operators are useful for invariant properties (many of which can be expressed using regular modalities), but also for describing infinite execution sequences that violate some fairness property. For instance, the following formula:

maximal fixpoint Y . ⟨ not (via i2 send any) ⟩ Y

characterizes the states from which there exists an infinite se-quence not containing an input action of filter F2. Intuitively, it expresses that the current state must have at least one outgoing transition labelled by an action other than i2 and leading to a state from which this is possible again an infinite number of times (since Y is a maximal fixed point variable). All states of the above pLTS satisfy this formula, which means filter F2 may never get an input data (livelock). This starving situation arises because we assumed that pipe P is unreliable, i.e., it may lose forever data emitted by filter F1.

4.9 Connection Formulas The connection formula constructs enable to write formula on connections as first-class elements, taking into account connection mobility among architectural elements, i.e., components and con-nectors.


11

Indeed, in dynamic software architectures, interconnection topol-ogy may dynamically change. Furthermore, in mobile environ-ments, mobility of connections can be achieved by communication of connection names (built using the predefined type constructor connection) among components. Thus, a component is allowed to send (resp. receive) data only along the connections that it is cur-rently aware of.

The operational semantics of the π-ADL takes care of this aspect, by ensuring that all transitions in the underlying pLTS of the sys-tem are labelled only by actions a = c v1,…, vn, where the connec-tion c is known by the architectural elements participating to the communication.

The dynamic evolution of the interconnection topology can be taken into account in the temporal properties by adding to fixed point variables two new parameters cIn and cOut, representing the sets of sending and receiving connections associated to a particular architectural element, respectively. When expressing a property of an architectural element, these sets will be initialised with the con-nections known by that architectural element at the beginning of the verification, and must be updated with the new connections received by the architectural element from the other architectural elements of the system. For example, the fact that a certain archi-tectural element of the system communicates with the external world only through its sending and receiving connections (initially contained in the sets cIn0 and cOut0) can be expressed by the fol-lowing formula:

(maximal fixpoint Y (cIn, cOut : Set[Connection]) . forall c, c1 : Connection . forall d : Data . [ via c receive d ] (cIn −> includes c and Y (cIn, cOut)) and [ via c send d ] (cOut −> includes c and Y (cIn, cOut)) and [ via c receive c1 ] (cIn −> includes c and ((receiving (c1) and Y (cIn −> including c1, cOut)) or (sending (c1) and Y (cIn −> including c1, cOut)) ) and [ unobservable ] Y (cIn, cOut) ) (cIn0, cOut0)

where the operator includes tests the membership of a connection to a set, the operator cSet −> including c computes the set obtained by adding c to the connection set cSet, and the predicates receiving (c) and sending (c) indicate whether a connection c is dedicated for receiving or sending information, respectively.

4.10 User-defined Properties Definition is the construct for expressing named properties. Definitions are applied to data values in order to verify the corresponding formulas.

The abstract syntax for property definition and application is defined as follows.

Abstract syntax of property definition and application

syntax of property definition

PropertyDefinition ::= with { name : Abstraction }

name is property (x1,…,xn) { Formula }

syntax of property application

PropertyApplication ::= using { abstractionValue }

verify { Formula }

Figure 27. Abstract syntax of property definition

4.11 Further Examples of Properties In order to further illustrate the use of π-AAL for specifying properties, let us express some useful behavioural properties.

In fact, π-AAL subsumes the modal µ-calculus, and therefore al-lows to express safety, liveness, and fairness properties in a natu-ral way. For instance, the deadlock freedom property (which is a desirable property of most concurrent systems) can be stated by the formula below, which ensures that all states reachable from the initial state of the pLTS have at least one successor:

[ true* ] ⟨ true ⟩ true

Using regular expressions, relatively complex safety properties can be expressed in a concise manner. For example, a desirable property of communication protocols is the strict alternation be-tween emissions and receptions of messages, starting with an emission. This can be expressed by the following formula, which is the conjunction of three properties (no reception before an emis-sion initially, no two consecutive emissions without a reception in between, and no two consecutive receptions without an emission in between):

[ (not (via s send any))* . (via r receive any) ] false and [ true* . (via s send any) . (not (via r receive any))* . (via s send any) ] false and [ true* . (via r receive any) . (not (via s send any))* . (via r receive any) ] false

This formula can be transformed in a more concise form by col-lapsing it into a single box modality (by applying modal logic and regular expression identities):

[ ((nil | true* . (via r receive any)) . (not (via s send any))* . (via r receive any) ) | (true* . (via s send any) . (not (via r receive any))* . (via s send any) ) ] false


12

Regular modalities also allow to express some fairness properties, such as fair reachability of an action (i.e., the reachability of the action by assuming that all circuits in the pLTS are exited after a finite number of steps – which could be ensured by a fair sched-uler). For instance, the following property states that after request-ing a resource, under the fairness condition above, a process will get the access to the resource after a finite number of steps:

[ true* . (via request send any) ] ⟨ true* . (via grant receive any) ⟩ true

Stronger reachability properties must be expressed using fixed point operators. For example, the inevitable reachability of a grant after a request (i.e., the reachability of the grant on all execution sequences going out from a state) can be expressed by the follow-ing formula:

[ true* . (via request send any) ] minimal fixpoint Y . ⟨ true ⟩ true and [ not (via grant receive any) ] Y

Note that none of the formulas above contains data variables. However, to express useful properties of value-passing languages, data variables and quantification are needed. Using these con-structs, we can easily express e.g., data transmission properties, which are typical for communication protocols. For instance, the property below states that every message sent will be eventually received after a finite number of steps:

forall m : Message . [ true* . (via s send m) ] minimal fixpoint Y . ⟨ true ⟩ true and [ not (via r receive m) ] Y

Regular modalities used together with quantification and data predicates allow to express safety properties concerning param-eterised processes. For instance, the property below states the ac-cess in mutual exclusion of two concurrent processes to some shared resource (the communication connections open and close denote the beginning and release of the critical sections, respec-tively):

forall p1, p2 : Behaviour . [ true* . (via open send p1) . (not (via close send p1))* . (via open send p2) ] (p1 ≠ p2)

Quantifiers and parameterised action predicates do not always suffice to express properties that involve counting of actions or evolution of data during the execution of a program. To achieve this, parameterised fixed point operators are needed. For example, the following property states that a computation can deliver a re-sult only after 10 inputs have been read:

[ true* ] (maximal fixpoint Y (k:Nat) . [ via input receive any ] Y (k - 1) and [ via result send any ] (k = 0) and [ not ((via input receive any) or (via result send any)) ] Y (k) ) (10)

The propositional variable Y is parameterised by a counter k which is equal to 10 minus the number of input actions encoun-tered along the path from the initial state to the current state.

An example of characterizing the evolution of data during the exe-cution of a program is given below. The formula describes the safety property of a FIFO (i.e., first-in/first-out) data buffer, i.e., the fact that elements must be delivered by the buffer in the same order in which they have been inserted:

(maximal fixpoint Y (b : Buffer) . forall d : Data . [ via get receive d ] Y (append (b, d)) and [ via put send d ] ((d = head (b)) and Y (out(b))) and [ unobservable ] Y (b) ) (empty)

The actions get and put represent the insertion and delivery of an element into and from the buffer; we assume that these are the only visible actions of the system. The function empty() returns a buffer containing no elements; append(b, d) returns the buffer b at the end of which the element d has been inserted; head (b) returns the element in the front of the buffer b; and out (b) returns the buffer b without its front element.

As illustrated by the examples above, the presence of quantifiers over data variables and the parameterisation of fixed point opera-tors provide a very expressive temporal logic.

4.12 Relating Properties to Architectures Architectural properties are related to architecture descriptions. Thereby, architectural properties specify their completeness, con-sistency and correctness.

The abstract syntax for relating architectural properties to architec-ture descriptions is defined as follows.

Relating Properties to Architectures

architecture { architectureDescription } assuming { architecturalProperties }

Figure 28. Relating properties to architectures

5. Case Study In order to illustrate the use of π-AAL, we present hereafter the description of a classical pipe-and-filter architecture including different kinds of architectural properties that must be analysed in order to guarantee its completeness, consistency and correctness.


13

Classical pipe-and-filter architectures, e.g., pipelines, are used when a sequence of transformations is applied to a stream of data by a sequence of filters, producing a final output. Hence, pipelines are pipe-and-filter architectures composed of a single chain of pipes and filters. A pipe transmits output of one filter to input of another filter. A filter transforms data received from its input and sends the transformed data to its output. Filters do not share state, i.e., they do not know about upstream or downstream filters.

5.1 Architecture Description In a pipeline architecture:

• the architecture is composed of filters and pipes; • filters are components; • a filter has a set of input and output connections and uses a

function to transform data; • pipes are connectors; • a pipe has a set of input and output connections and transmits

data from input to output as they are; • a pipe connects two filters, it transmits an output of a filter to

an input of another filter.

Using π-ADL, the Filter component abstraction can be formally described as follows.

component Filter is abstraction() { type Data is Any. port is { connection input is in(Data). connection output is out(Data) } assuming { protocol is { ( via input receive any. true*. via output send any )* } }. behaviour is { transform is function(d : Data) : Data { unobservable }. via input receive d : Data. via output send transform(d). behaviour() } }

The Pipe connector abstraction can be formally described as fol-lows.

connector Pipe is abstraction() { type Data is Any. port is { connection input is in(Data). connection output is out(Data) } assuming { protocol is { (via input receive d : Data. via output send d)* } }. behaviour is { via input receive d : Data. via output send d. behaviour() } }

Let us describe a pipe that is unreliable, i.e., it can nondeterminis-

tically choose either to transmit data correctly, or to lose it.

connector UnreliablePipe is abstraction() { type Data is Any. port is { connection input is in(Data). connection output is out(Data) } assuming { protocol is { (via input receive d : Data. (via output send d | nil))* } }. behaviour is { via input receive d : Data. choose { via output send d. behaviour() or unobservable. behaviour() } }

A very simple pipeline architecture, like the one introduced in the previous section to illustrate π-AAL constructs, shown in Figure 8, can be formally described as follows. It uses an unreliable pipe.

architecture OnePipeTwoFilters is abstraction() { behaviour is compose { F1 is Filter() and P is UnreliablePipe() and F2 is Filter() } where { F1::input as i1 and P::input unifies F1::output as o1 and P::output unifies F2::input as i2 and F2::output as o2 } }

A general pipeline architecture, with at least one pipe and two filters, but with as many reliable pipes and filters as needed, can be formally described as follows.

architecture Pipeline is abstraction(n : Natural) { behaviour is compose { F is sequence for i = 1 to n using Filter() and P is sequence for i = 1 to n using Pipe() } where { iterate sequence(1..n) by i do { P::i::input unifies F::i::output and P::i::output unifies F::(i+1)::input } } } assuming { parameter is { n >= 1 } and F −> size >= 2 and P −> size >= 1 ... }

Having formally defined the components and connectors of the architecture and how they are composed together is not enough to guarantee its completeness, consistency and correctness.

5.2 Property Specification Let us now specify different kinds of architectural properties that


14

must be analysed in order to guarantee the completeness, consis-tency and correctness of the architecture.

Architectural completeness means that the architecture description does not lack components, connectors, connections or their parts or interrelationships with respect to architecture-specific, archi-tect-defined, properties.

For instance, a pipeline architecture could be considered to be complete if all pipes have their input and output connections con-nected to filters and all filters, but the first and last one, have their input and output connections connected to pipes. Of course, input connections must be unified to output connections.

Regarding architectural consistency, it means that the architecture description makes sense; that different parts of the description do not contradict each other. For instance, protocols of ports of uni-fied connections must be compatible.

Regarding correctness, it is defined with respect to the correctness of the system functionalities, i.e., the conformity with correctness requirements. For instance, all filter transformations must be ap-plied to all data.

Thereby, completeness, consistency and correctness are semantic properties, and as so are defined with respect to analysis of archi-tecture-specific, architect-defined, properties.

For instance, an architect could specify architectural properties for verifying that:

• protocols of ports are projections of behaviours of components or connectors,

• protocols of unified ports are compatible, with corresponding send-receive actions, and deadlock-free,

• components, connectors, and the architecture are deadlock-free,

• ports of components and connectors in the configuration are connected accordingly,

• configuration of components and connectors conform to the architectural style constraints.

More specifically, for the described pipeline architecture, an archi-tect could specify and verify if:

• there is a safe alternation of send and receive actions in com-ponents, i.e., in filters,

• there is a safe alternation of send and receive actions in con-nectors, i.e., in pipes,

• there is the right connectivity, in terms of the pipeline style, among pipes,

• there is the right connectivity, in terms of the pipeline style, among filters,

• there is the right connectivity, in terms of the pipeline style, among pipes and filters,

• the pipeline is deadlock free, • there is a fair reachability of the transform function in the pipe-

line, • there is an inevitable reachability of the transform function

after receive actions in the pipeline, • all data received in components and connectors are transmitted.

Using π-AAL, these architectural properties can be easily speci-fied.

Let us use the pipeline architecture and its components and con-nectors described so far to show how these properties could be expressed using π-AAL.

The behavioural property “there is a safe alternation of send and receive actions in filters” can be formally specified as follows. It expresses that there is no send before a receive initially, no two consecutive receives without a send in between, and no two con-secutive sends without a receive in between.

with { c : Filter } safetyAlternationInComponent is property() { -- no send before a receive initially -- no two consecutive receives without a send in between -- no two consecutive sends without a receive in between c.ports.inputPrefixes −> forall { r | c.ports.outputPrefixes −> forall { s | every sequence { (not via r receive any)* . via s send any } leads to state { false } and every sequence { true* . via r receive any . (not via s send any)* . via r receive any } leads to state { false } and every sequence { true* . via s send any . (not via r receive any)* . via s send any } leads to state { false } } } } -- [ (not via r receive any)* . via s send any ] false -- and -- [ true* . via r receive any . (not via s send any)* . -- via r receive any ] false -- and -- [ true* . via s send any . (not via r receive any)* . -- via s send any ] false

Once a property is specified, it can be applied for verification pur-pose as follows. In that case, it is verified for every filter compo-nent, independent of the context of any architecture.

using { F is Filter() } verify { F.safetyAlternationInComponent() }

In the following case, it is verified for every filter component of the pipeline architecture.

using { PL is Pipeline() } verify { PL.components −> forall { c | c.safetyAlternationInComponent() } }

Another way of expressing the safety alternation property speci-


15

fied above is by collapsing it into a single box modality by apply-ing modal logic and regular expression identities, as follows.

with { c : Filter } safetyAlternationInComponentBis is property() { -- another way of expressing the formula: -- by collapsing it into a single box modality by applying modal -- logic and regular expression identities c.ports.inputPrefixes −> forall { r | to c.ports.outputPrefixes −> forall { s | every sequence { (nil | true* . via s send any) . (not via r receive any)* . via s send any) | (true* . via r receive any . (not via s send any)* . via r receive any) } leads to state { false } } } } -- [ (nil | true* . via s send any) . (not via r receive any)* . -- via s send any) | (true* . via r receive any . -- (not via s send any)* . via r receive any) ] false

The safety alternation property was specified above for filter com-ponents. It can be formally specified for pipe connectors as fol-lows.

with { c : Pipe } safetyAlternationInConnector is property() { -- no send before a receive initially -- no two consecutive receives without a send in between -- no two consecutive sends without a receive in between c.ports.inputPrefixes −> forall { r | to c.ports.outputPrefixes −> forall { s | every sequence { (nil | true*. via s send any) . (not via r receive any)* . via s send any) | (true* . via r receive any . (not via s send any)*. via r receive any) } leads to state { false } } } } -- [ (nil | true* . via s send any) . (not via r receive any)* . -- via s send any) | (true* . via r receive any . -- (not via s send any)* . via r receive any) ] false

Once specified, this property can be applied for verification pur-pose as follows. In that case, it is verified for every pipe connec-tor, independent of the context of any architecture.

using { P is Pipe() } verify { P.safetyAlternationInConnector }

In the following case, in a similar way as for components, it is verified for every pipe connector of the pipeline architecture.

using { PL is Pipeline() } verify { PL.connectors −> forall { c | c.safetyAlternationInConnector } }

The structural property “there is the right connectivity, in terms of the pipeline style, among pipes and filters” can be formally speci-fied as follows. It expresses that every pipe input port is connected to a filter output port and every pipe output port is connected to a filter input port in a pipeline architecture.

with { pl : Pipeline } connectivityBetweenPipesAndFilters is property() { -- every pipe input port is connected to a filter output port and -- every pipe output port is connected to a filter input port pl.connectors −> forall { p | p.ports.connections −> forall { inp,outp | pl.components −> exists { fi, fo | (fi.ports.connections union fo.ports.connections) −> forall { infi, outfo | (p.ports.connections −> includes inp) and (inp.type = input) and (p.ports.connections −> includes outp) and (outp.type = output) and (fi.ports.connections −> includes infi) and (infi.type = input) and (fo.ports.connections −> includes outfo) and (outfo.type = output) and (inp unifies outfo) and (outp unifies infi) } } } } }

The structural property “there is the right connectivity, in terms of the pipeline style, among pipes” can be formally specified as fol-lows. It expresses that a pipe port cannot be connected to another pipe port in a pipeline architecture.

with { pl : Pipeline } connectivityBetweenPipes is property() { -- a pipe port cannot be connected to another pipe port pl.connectors −> forall { p1, p2 | p1.ports.connections −> forall { cp1 | p2.ports.connections −> forall { cp2 | not (cp1 unifies cp2) } } } }

The structural property “there is the right connectivity, in terms of the pipeline style, among filters” can be formally specified as fol-lows. It expresses that a filter port cannot be connected to another filter port in a pipeline architecture.

with { pl : Pipeline } connectivityBetweenFilters is property() {


16

-- a filter port cannot be connected to another filter port pl.components −> forall { f1, f2 | f1.ports.connections −> forall { cf1 | f2.ports.connections −> forall { cf2 | not (cf1 unifies cf2) } } } }

The property “there is the right connectivity, in terms of the pipe-line style, for boundary connections” can be formally specified as follows. It expresses that ports of a pipeline architecture (that is a composite component) must be relayed to filters, never to pipes.

with { pl : Pipeline } connectivityOfPipeFilter is property() { -- ports of the architecture must be connected to filters, -- never to pipes pl.instances −> forall { pf | (pf.components.ports.connections union pf.connectors.ports.connections) −> forall { ip, op | pf.components −> exists { fi, fo | (fi.ports.connections union fo.ports.connections) −> exists { infi, outfo | (fi.ports.connections −> includes infi) and (infi.type = input) and (fo.ports.connections −> includes outfo) and (outfo.type = output) and (ip relays infi) and (op relays outfo) } } } } }

The behavioural property “the pipeline architecture is deadlock free” can be formally specified as follows. It expresses that at any moment, the pipeline system can execute an action. Thereby, it is never deadlocked.

with { pl : Pipeline } deadlockFreedom is property() { -- at any moment, the system can execute an action -- (runtime/architecture) pl.instances −> every sequence { true* } leads to state { some sequence { true } leads to state { true } } } -- [ true* ] ⟨ true ⟩ true

The behavioural property “there is a fair reachability of the trans-form function in a pipeline architecture” can be formally specified as follows. It expresses that after a receive action in a filter, under the fairness condition, the function transform data will be carried out after a finite number of steps.

with { pl : Pipeline } fairReachabilityOfTransformData is property() { -- after a filter receive, under the fairness condition, -- the function transform data -- will be carried out after a finite number of steps pl −>.components forall { f | f.functions −> forall { transf | .name =transf transform implies { f.ports.inputPrefixes −> exists { r | every sequence { true* . via r receive any . (not via transf send any)* } leads to state { some sequence { true* . via transf send any } leads to state { true } } } } } } -- [ true* . via r receive any . (not via transf send any)* ] -- ⟨ true* . via transf send any ⟩ true

The behavioural property “there an inevitable r is eachability of the transform data function after receive actions in a pipeline architec-ture” can be formally specified as follows. It expresses that after a receive action in a filter, the function transform data will always be carried out after a finite number of steps.

with { pl : Pipeline } inevitableReachabilityOfTransformAfterReceive is property() { -- the inevitable reachability of a function transform data after -- a receive pl.components −> forall { f | f.functions −> forall { transf | transf.name = transform implies { f.ports.inputPrefixes −> exists { r | every sequence { true* . via r receive any } leads to state { finite tree Y given by { some sequence { true } leads to state { true } and every sequence { not via transf send any } leads to state { Y } } } } } } } -- [ true* . via r receive any ] minimal fixpoint Y . ⟨ true ⟩ true -- and [ not via transf send any ] Y

The property “in a pipeline architecture, all data received in com-ponents and connectors are transmitted” can be formally specified as follows. It expresses that every data that is received will be eventually sent after a finite number of steps.


17

with { pl : Pipeline } dataTransmission is property() { -- every data that is received will be eventually sent -- after a finite number of steps pl −>.components forall { f | f.ports.inputPrefixes −> forall { r | f.ports.outputPrefixes −> exists { s | r.data −> d forall { | every sequence { true* . via r receive d } leads to state { finite tree givY en by { some sequence { true } leads to state { true } and every sequence {not via s send d } leads to state { Y } } } } } } } -- forall d . [ true* . via r receive d ] -- minimal fixpoint Y . ⟨ true ⟩ true and [ not via s send d ] Y

Now let us attach the architectural properties defined above to the pipeline architecture described so far.

architecture Pipeline is abstraction(n : Natural) { behaviour is compose { F is sequence for i = 1 to n using Filter() and P is sequence for i = 1 to n using Pipe() } where { iterate sequence( .. ) by do { 1 n i P::i::input unifies F::i::output and P::i::output unifies F::(i+1)::input } } } assuming { (components −> forall { c | c.safetyAlternationInComponent()) and (connectors −> forall { c | c.safetyAlternationInConnector()) and ilters() connectivityBetweenPipesAndF and connectivityBetweenPipes() and connectivityBetweenFilters() and () connectivityOfPipeFilter and deadlockFreedom() and fairReachabilityOfTransformData() and yOfTransformAfterReceiveinevitableReachabilit () and dataTransmission() }

It is worth noting that an architect can also define architectural

Several Architecture Description Languages (ADLs) have been proposed in the literature [35], including: ACME/Dynamic-ACME

9], AML [52], ARMANI [37], CHAM-ADL

ture

erning architecture descriptions obtained by

nsion of µ-calculus modalities with

3], various architectural

styles using π-ADL together with π-AAL by defining component and connector abstractions and constraints on how they must (or should) be used to define specific architectures.

6. Related Work

[20][21], AESOP [1[25][26], DARWIN [32], META-H [8], PADL [6][7], RAPIDE [46][31], SADL [38][39], σπ-SPACE [9][10][29], UNICON-2 [12], and WRIGHT/Dynamic-WRIGHT [2][3]. Most of these ADLs integrate a language for architecture analysis, i.e., an Archi-tecture Analysis Language (AAL), e.g., ACME, ARMANI, CHAM-ADL, DARWIN, RAPIDE, SADL, and WRIGHT.

Most of those approaches propose a less or more sophisticated AAL for specifying architectural properties.

The main limitation of most of these approaches is that they ad-dress either structural or behavioural properties, but not both.

Indeed, π-AAL provides a novel language that on the one side has been specifically designed for architectural analysis taking into account the need to express and verify properties on both strucand behaviour from an architectural perspective and on the other side is highly expressive.

π-AAL provides the notation to express properties of architectures described in π-ADL.

π-AAL combines predicate logic with temporal logic in order to allow the specification of both structural properties and behav-ioural properties concinstantiating a given style.

Regarding behavioural properties, the choice of modal µ-calculus as the underlying formalism provides a significant expressive power. Moreover, the extehigher level constructs such as regular formulas inspired from early dynamic logics like PDL [14] facilitates the specification task of the practitioners, by allowing a more natural and concise description of properties involving complex sequences of actions. The extension of fixed point operators with data parameters also provides a significant increase of the practical expressive power, and is naturally adapted for specifying behavioural properties of value-passing languages such as π-ADL.

In the context of software architectures, several attempts at using classical process algebras and generic model checking technology have been reported in the literature. In [2styles (e.g., repository, pipe-and-filter, and event-action) are de-scribed in LOTOS, by using specific communication patterns and constraints on the form of components, and verified using the CADP toolbox [13][18]. In [47], several variants of the pipe-and-filter style are described in LOTOS and analysed using CADP. In [27], the transformation of software architectures specified in LOTOS and their verification using the XTL model checker [33] of CADP are presented. Finally, an approach for checking dead-lock freedom of software architectures described using a variant of CCS is described in [7]. All these works provide rather ad-hoc solutions for a class of software architectures limited to static communication between architectural elements, and can be sub-sumed by the more general framework provided by π-AAL (with π-ADL) and its verification tools.

A more detailed positioning of π-AAL (as well as π-ADL and π-ARL) w.r.t. the state-of-art is given in [16][30][40].


18

ding verifica-tion) of both structural and behavioural properties. This is a key

e in order to support seman-

tware tools. The usefulness of an AAL is thereby

includes π-cture re-

e f obliga-

Engineering Ingegneria Informatica (Italy) in the

the following

are systems,

• riented architectures for enterprise application inte-

in t expressiveness, to describe, analyse, and refine dy-

[1] Abrial J.-R.: The B-Book: Assigning Programs to Meanings. Cam-ersity Press, 1996.

amental Approaches to Soft-

[4]

[5] ses using ZETA Component-based Architecture Description

[6] ort UBLCS-2001-7, July 2001.

[8]

[9]

[10]g Software Systems.

[11]

[13]

[14]nal of Computer and System Sciences Vol. 18, 1979.

[16]

7. Conclusion and Future Work π-AAL supports formal specification (and correspon

factor in the architectural design phastic correctness.

A major impetus behind developing formal languages for architec-ture analysis is that their formality renders them suitable to be ma-nipulated by sofdirectly related to the kinds of tools it provides to support auto-mated verification. Indeed, π-AAL is supported by a comprehen-sive analytical toolset composed of:

• a model checking tool based on CADP [18][33], • a theorem proving tool implemented in XSB Prolog.

π-AAL is part of the ArchWare languages, which alsoADL for architecture description and π-ARL for architefin ment. π-AAL provides the language to express prootions to guarantee the correctness of the descriptions and their refinements.

π-AAL (jointly with π-ADL and π-ARL) has been applied in sev-eral realistic case studies and industrial business cases at Thésame (France) and framework of the ArchWare European Project. In the pilot project at Thésame, an agile integrated industrial process system was ar-chitected, analysed, and refined. In the pilot project at Engineering Ingegneria Informatica, a federated knowledge management sys-tem was architected, analysed, and refined. π-AAL (with π-ADL and π-ARL) has also been used by the CERN (Switzerland) for architecting, analysing, and refining human computer interface software for monitoring particle accelerator restart.

In addition to these industrial applications carried out in the ArchWare European Project and at the CERN, π-AAL, and its related languages and tools, have been applied inapplication domains:

• component-based software systems for sensor-actuator net-works,

• mobile agent softw• service-oriented architectures for grid computing systems,

service-ogration.

All these domains are characterised by the need of architecturedescription, analysis, and refinement languages powerful enough,

erms of namic architectures, including support for analysing their qualities.

The different applications of π-AAL, and its related languages and tools are broad and general enough to demonstrate their adequacy and relevance for addressing innovative industrial problems. Fur-thermore, the π-ArchWare software environment itself is a valida-tion of π-ADL, π-AAL, and π-ARL since it has been completely specified and developed using these languages themselves.

Ongoing work is mainly related with the formal development of an architecture-centric formal method. This formal method, called

the π-Method, like formal methods such as B [1], FOCUS [50][45], VDM [15], and Z [11], aims to provide full support for formal description and development. Unlike these formal methods that do not provide any architectural support, the π-Method has been built from scratch to support architecture-centric formal software engineering.

References

bridge Univ[2] Allen R.: A Formal Approach to Software Architectures. PhD The-

sis, Carnegie Mellon University, 1997. [3] Allen R., Douence R., Garlan D.: Specifying and Analyzing Dy-

namic Software Architectures. In Fundware Engineering, LNCS 1382, Springer Verlag, 1998.

Alloui I., Garavel H., Mateescu R., Oquendo F.: The ArchWare Ar-chitecture Analysis Language: Syntax and Semantics. DeliverableD3.1b, ArchWare European RTD Project, IST-2001-32360, January 2003. Alloui I., Oquendo F.: Supporting Decentralised Software-intensive ProcesLanguage. Enterprise Information Systems, Joaquim Filipe (Ed.), Kluwer Academic Publishers, 2002. Bernardo M., Ciancarini P., Donatiello L.: Architecting Systems with Process Algebras. Technical Rep

[7] Bernardo M., Ciancarini P., Donatiello L.: Detecting Architectural Mismatches in Process Algebraic Descriptions of Software Systems, Proceedings of the 2nd Working IEEE/IFIP Conference on Software Architecture, Amsterdam, IEEE-CS Press, August 2001. Binns P., Engelhart M., Jackson M., Vestal S.: Domain-Specific Software Architectures for Guidance, Navigation, and Control. In-ternational Journal of Software Engineering and Knowledge Engi-neering. 1996. Chaudet C., Greenwood M., Oquendo F., Warboys B.: Architecture-Driven Software Engineering: Specifying, Generating, and Evolving Component-Based Software Systems. IEE Journal: Software Engi-neering, Vol. 147, No. 6, UK, December 2000.

Chaudet C., Oquendo F.: A Formal Architecture Description Lan-guage Based on Process Algebra for EvolvinProceedings of the 15th IEEE International Conference on Auto-mated Software Engineering (ASE’00). IEEE Computer Society, Grenoble, September 2000.

Davies J., Woodcock J.: Using Z: Specification, Refinement and Proof. Prentice Hall International Series in Computer Science, 1996.

[12] DeLine R.: Toward User-Defined Element Types and Architectural Styles. Proceedings of the 2nd International Software ArchitectureWorkshop, San Francisco, 1996.

Fernandez J-C., Garavel H., Kerbrat A., Mateescu R., Mounier L., Sighireanu M.: CADP (CAESAR/ALDEBARAN Development Package) – A Protocol Validation and Verification Toolbox, Pro-ceedings of the 8th International Conference on Computer-Aided Verification, New Brunswick, USA, LNCS 1102, Springer Verlag, August 1996.

Fischer M.J., Ladner R.E.: Propositional Dynamic Logic of Regular Programs. Jour

[15] Fitzgerald J., Larsen P.: Modelling Systems: Practical Tools and Techniques for Software Development, Cambridge University Press,1998.

Gallo F. (Ed.): Annual Report: Project Achievements in 2002. Ap-pendix B: Survey of State-of-the-Art and Typical Usage Scenario for ArchWare ADL and AAL. Deliverable D0.4.1, ArchWare Euro-pean RTD Project, IST-2001-32360, February 2003.


19

[17]le), November

[18]cience and Technology

[19]of the ACM SIGSOFT

[20]ange Language. Proceedings of CASCON'97, Toronto, No-

[21]-Based Systems. Foundations of Component-Based

[22]roceedings of the 7th International

[23]l Conference on The-

[24]Software-Intensive Systems, October 2000.

el. IEEE

[26]-

[27]ctures. Proceedings of the ZB2002 International Workshop

[28]-354, 1983.

en compte des styles architec-

[30]ison des langages de de-

[31]nalysis of System Architecture Using

[32]itectures. Proceedings of the 5th European Software

[33]t Interna-

[34]ee Mu-Calculus. Science of Computer

Programming Journal, Elsevier, 2002.

[37] tware Architecture Design Expertise with

ratory, SRI International, Technical Report SRI-

[40]

ctures. ACM Software Engineering Notes,

[42]

eering Notes, Vol. 29, No. 5, September

[43]

, No. 1, January 2006.

Ware European RTD Project, IST-

[45]

[46] to the RAPIDE 1.0. Language Refer-

[47] ur le Style Architectural

FADL'00), Grenoble,

[48]

[50] K., Broy M.: Specification and Development of Interactive

[51] positional Dynamic Logic of Looping and Converse.

[52] Meta Language. Proceedings of the

9.

Garavel H.: Compilation et Vérification de Programmes LOTOS. Thèse de Doctorat, Univ. Joseph Fourier (Grenob1989. Chapter 9: Vérification (In French).

Garavel H., Lang F., Mateescu R.: An Overview of CADP 2001. European Association for Software S(EASST) Newsletter, Vol. 4, August 2002.

Garlan D., Allen R., Ockerbloom J.: Exploiting Style in Architec-tural Design Environments. Proceedings Symposium on Foundations of Software Engineering, New Orleans, 1994.

Garlan D., Monroe R., Wile D.: ACME: An Architecture Description Interchvember 1997.

Garlan D., Monroe, R., Wile D.: ACME: Architectural Description of ComponentSystems, Leavens G.T, and Sitaraman M. (Eds.), Cambridge Univer-sity Press, 2000.

Groote J. F., Mateescu R.: Verification of Temporal Properties of Processes in a Setting with Data. PConference on Algebraic Methodology and Software Technology, Amazonia, Brazil, LNCS 1548, January 1999.

Heisel M., Levy N.: Using LOTOS Patterns to Characterize Archi-tectural Styles, Proceedings of the Internationaory and Practice of Software Development, LNCS 1214, Springer Verlag, 1997.

IEEE Std 1471-2000: IEEE Recommended Practice for Architectural Description of

[25] Inverardi P., Wolf A.: Formal Specification an Analysis of Software Architectures using the Chemical Abstract Machine ModTransactions on Software Engineering, Vol. 21, No. 4, April 1995.

Inverardi P., Wolf A., Yankelevich D.: Static Checking of System Behaviors using Derived Component Assumptions. ACM Transactions on Software Engineering and Methodology, Vol. 9, No. 3, July 2000.

Kerschbaumer A.: Non-Refinement Transformation of Software Architeon Refinement of Critical Systems: Methods, Tools and Experience, Grenoble, Janvier 2002.

Kozen D.: Results on the Propositional µ-Calculus. Theoretical Computer Science 27:333

[29] Leymonerie F., Cimpan S., Oquendo F. : Extension d'un langage de description architecturale pour la priseturaux : application à J2EE. Proceedings of the 14th International Conference on Software and Systems Engineering and their Applica-tions. Paris, December 2001 (In French).

Leymonerie F., Cimpan S., Oquendo F., "État de l'art sur les styles architecturaux : classification et comparascription d'architectures logicielles", Revue Génie Logiciel, No. 62, September 2002 (In French).

Luckham D.C., Kenney J.J., Augustin L.M., Vera J., Bryan D., Mann W.: Specification and ARAPIDE. IEEE Transactions on Software Engineering, Vol. 21, No. 4, April 1995.

Magee J., Dulay N., Eisenbach S., Kramer J.: Specifying Distributed Software ArchEngineering Conference, Sitges, Spain, September 1995.

Mateescu R., Garavel H.: XTL: A Meta-Language and Tool for Temporal Logic Model Checking. Proceedings of the 1stional Workshop on Software Tools for Technology Transfer, Aal-borg, Denmark, July 1998.

Mateescu R., Sighireanu M.: Efficient On-the-Fly Model Checking for Regular Alternation-Fr

[35] Medvidovic N., Taylor R.: A Classification and Comparison Frame-work for Architecture Description Languages. ACM TOSEM, Vol. 26, No. 1, January 2000.

[36] Milner R.: Communicating and Mobile Systems: The Pi-Calculus. Cambridge University Press, 1999.

Monroe R.: Capturing SofARMANI. Technical Report CMU-CS-98-163, Carnegie Mellon University, January 2001.

[38] Moriconi M., Qian X., Riemenschneider R.A.: Correct Architecture Refinement. IEEE Transactions on Software Engineering, Vol. 21, No. 4, April 1995.

[39] Moriconi M., Riemenschneider R.A.: Introduction to SADL 1.0: A Language for Specifying Software Architecture Hierarchies. Com-puter Science LaboCSL-97-01, March 1997.

Oquendo F.: The ArchWare Architecture Refinement Language. Deliverable D6.1b, ArchWare European RTD Project, IST-2001-32360, December 2003.

[41] Oquendo F.: π-ADL: An Architecture Description Language based on the Higher Order Typed π-Calculus for Specifying Dynamic and Mobile Software ArchiteVol. 29, No. 3, May 2004.

Oquendo F.: π-ARL: An Architecture Refinement Language for Formally Modelling the Stepwise Refinement of Software Architec-tures. ACM Software Engin2004.

Oquendo F.: Formally Modelling Software Architectures with the UML 2.0 Profile for π-ADL. ACM Software Engineering Notes, Vol. 31

[44] Oquendo F., Alloui I., Cimpan S., Verjus H.: The ArchWare Archi-tecture Description Language: Abstract Syntax and Formal Seman-tics. Deliverable D1.1b, Arch2001-32360, December 2002.

Philipps J., Rumpe B.: Refinement of Pipe and Filter Architectures. Proceedings of FM’99, LNCS 1708, 1999.

RAPIDE Design Team: Guide ence Manuals, Stanford University, July 1997.

Rongviriyapanish S., Levy N.: Variations sPipe and Filter. Actes du Colloque sur les Approches Formelles dans l'Assistance au Développement de Logiciels (AFrance, January 2000 (In French).

Sangiorgi, D., Expressing Mobility in Process Algebras: First-Order and Higher-Order Paradigms. PhD Thesis, University of Edinburgh, 1992.

[49] Stirling C.: Modal and Temporal Properties of Processes. Springer Verlag, 2001.

Stolen Systems. Springer Verlag, 2001.

Streett R.: ProInformation and Control Journal, 1982.

Wile D.: AML: An Architecture 14th International Conference on Automated Software Engineering, pp. 183-190. Cocoa Beach. October 199

[53] Wolper P.: Temporal Logic Can Be More Expressive. Information and Control Journal, 1983.

π-AAL

Documents

Transcript of π-AAL