Title is Arial Bold 14 centered - CiteSeerX

7 downloads 0 Views 560KB Size Report
Mar 2, 2006 - Chaudet C., Greenwood M., Oquendo F., Warboys B.: Architecture-. Driven Software Engineering: Specifying, Generating, and Evolving.
ACM SIGSOFT Software Engineering Notes

Page 1

March 2006

Volume 31

Number 2

π-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

Flavio Oquendo University of South Brittany VALORIA – Formal Software Architecture Group B.P. 573 – 56017 Vannes Cedex – France

[email protected]

[email protected]

• • •

Abstract A key aspect of the design of any software system is its architecture. An architecture description, from a runtime perspective, provides 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 Architecture Description Languages (ADLs) have been defined for representing 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 completeness, consistency and correctness. This article presents πAAL, a novel Architecture Analysis Language (AAL) that has been designed in the ArchWare European Project to address formal 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.

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

In the past decade, several Architecture Description Languages (ADLs) have been defined for representing 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 completeness, consistency and correctness. Therefore, an Architecture Analysis Language (AAL) must complement (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 properties that can interleave both structural and behavioural aspects, and to be well-suited for machine-automated processing for verification, at a time.

Keywords: Architecture Analysis Languages, Property Specification, Property Verification, Software Architectures, Formal De- Architecture-centric formal development encompasses the description, analysis, and refinement of software architectures. 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 evolution [24].

describe & analyse application architect

architecture description

generated from

The structure may be specified in terms of:



refinement of

refine & analyse

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

architectural properties

application

components (units of computation of a system), connectors (interconnections among components for supporting their interactions), configurations of components and connectors.

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

The behaviour may be specified in terms of: 1

ACM SIGSOFT Software Engineering Notes

Page 2

March 2006

Volume 31

Number 2

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

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.

The π-AAL takes its roots in previous work concerning the extension 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].

This article describes the π-Architecture Analysis Language (πAAL) [4] that provides a uniform framework for specifying relevant properties of software architectures. These properties have different natures: they can be structural (e.g., cardinality of architectural 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 architects to express and verify properties of software architectures and styles in a natural way. Analysis is intended to be performed according to two approaches: model checking and theorem proving.

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 architectures [5], the modal µ-calculus is not sufficient. Therefore, a formalism encompassing both the predicate calculus and the modal µ-calculus is needed. The π-AAL is, thereby, this encompassing formalism, defined as a domain-specific extension of the µcalculus.

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 behavioural properties. In section 6, we compare π-AAL with related work. To conclude we summarise, in section 7, the main contributions of this article and briefly outline the π-AAL toolset for supporting architecture specification and verification.

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

2. Design Principles

3. Architecture Description with π-ADL

π-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 obligations 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.

Software architectures can be described with π-ADL that is a formal, well-founded theoretically language based on the higherorder typed π-calculus [36][48]. In π-ADL, an architecture is described in terms of components, connectors, and their composition. Figure 2 depicts its main constituents. component

connector

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 reasonvalue connection behaviour port ing about them; passing • π-AAL is defined in a layered approach, with a core canonical abstract syntax and formal semantics, to be well-suited for Figure 2. Architectural concepts in π-ADL machine-automated processing for verification; • π-AAL offers a user-friendly enhanced concrete syntax to be Components are described in terms of external ports and an intereasily used by software architects. nal behaviour. Their architectural role is to specify computational The π-AAL is a formal property expression language designed to elements of a software system. The focus is on computation to support automated verification. Thereby, one can mechanically deliver system functionalities. check whether an architecture described in π-ADL satisfies a Ports are described in terms of connections between a component and its environment. Their architectural role is to put together conproperty expressed in π-AAL. nections providing an interface between the component and its The π-AAL has as formal foundation the modal µ-calculus [28], a environment. Protocols may be enforced by ports and among calculus for expressing properties of labelled transition systems by ports. using least and greatest fixed point operators. π-AAL is itself a 2

ACM SIGSOFT Software Engineering Notes

Page 3

March 2006

Volume 31

Number 2

Connections are basic interaction points. Their architectural role is with the predicate calculus. π-AAL is itself a formal language deto provide communication channels between two architectural fined as an extended calculus subsuming the modal µ-calculus and elements. the predicate calculus for expressing properties on architectures. A component can send or receive values via connections. They Formulas in π-AAL are formally interpreted relative to a predican be declared as output connections (values can only be sent), cate-extended labelled transition system. input connections (values can only be received), or input-output Formally, a predicate-extended labelled transition system (pLTS) connections (values can be sent or received). is of the form pLTS = (StateSet, ActionSet, TransitionRelationSet, Connectors are special-purpose components. They are described PredicateSetLabelling, state0), where: as components in terms of external ports and an internal behaviour. However, their architectural role is to connect together com- • StateSet is a non-empty set of states, • ActionSet is a set of actions (actions that label transitions), ponents. They specify interactions among components. • TransitionRelationSet is a set of transition relations, such that Therefore, components provide the locus of computation, while each transition relation transition ∈ TransitionRelationSet, is connectors manage interaction among components. A component of the form transition ⊆ StateSet × ActionSet × StateSet, cannot be directly connected to another component. In order to • PredicateSetLabelling : StateSet → 2PredicateSet is a function have actual communication between two components, there must that labels each state with the set of atomic predicates true in be a connector between them. that state (where PredicateSet is the set of atomic predicates and 2PredicateSet the powerset of PredicateSet), Both components and connectors comprise ports and behaviour. In order to attach a port of a component to a port of a connector, at • state0 ∈ StateSet is the initial state. least a connection of the former port must be attached with a conAll states of StateSet are assumed to be reachable from the initial nection of the later port. A connection provided by a port of a state via sequences of (zero or more) transitions of the Transitioncomponent is attached to a connection provided by a port of a conRelationSet. nector by unification or value passing. Thereby, attached connections can transport values (that can be data, connections, or even The actions action of ActionSet are defined as: architectural elements). action ::= via connection send value1,…, valuen Components and connectors can be composed to construct com| via connection receive value1,…, valuen posite elements (see Figure 3), which may themselves be components or connectors. 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: • •

composite

the action unobservable, where unobservable ∉ ActionSet, is used to model an internal “unobservable” action of a component 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 Architectures are composite elements representing systems. An defined predicates. architecture can itself be a composite component in another archiFinally we can define BehaviourStateSet as the set of states of a tecture, i.e., a sub-architecture. behaviour in an architectural element (e.g., component or connector). Therefore for all s ∈ BehaviourStateSet, PredicateSet con4. Property Specification with π-AAL tains all predicates related to types and data declared in an π-AAL supports analysis of software architectures, described with architectural element expressed with π-ADL. π-ADL, from structural and behavioural perspectives. In π-AAL, an architectural property is specified in terms of logical formulas For a complete definition of the π-AAL semantic model see [4]. comprising: predicate formulas, action formulas, regular formulas, state formulas, and connection formulas. When evaluated, a for- 4.2 Abstract Syntax Notation mula is checked against the architecture description, that provides The basis for defining the π-AAL semantics is its abstract syntax, the interpretation domain. which is defined using the following notation for the abstract production rules: 4.1 Semantic Model • keywords are written with bold; The formal foundation of π-AAL is the modal µ-calculus extended • non-terminals are written without bold; Figure 3. Architectural composition in π-ADL

3

ACM SIGSOFT Software Engineering Notes •



Page 4

a sequence of zero, one or more elements is written: Elementmin, …, Elementmax, where the value of min specifies the minimum number of elements (0 specifies possibly no elements, 1 specifies at least one element) and the value of max specifies the maximum number of elements (Elementn specifies any number of elements); alternative choices are written separated by |.

March 2006

Volume 31

Number 2

Abstract syntax of constructed types ConstructedType ::= tuple [ ValueType1, …, ValueTypen ]

4.3 Types

|

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

|

union [ ValueType1, …, ValueTypen ]

|

quote [ name ]

|

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

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

|

location [ ValueType ]

|

sequence [ ValueType ]

The abstract syntax of types is defined as follows.

|

set [ ValueType ]

|

bag [ ValueType ]

|

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

|

ValueType0, …, ValueTypen → Behaviour

Abstract syntax of types syntax of types ValueType

::=

BaseType

|

ConstructedType

Figure 6. Abstract syntax of constructed types

syntax of type environments ∆

::=

∆, name : ValueType

|



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.

Figure 4. Abstract syntax of value types

The definition of π-AAL is structured in terms of kinds of formula As shown in Figure 4, all types are value types. Value types are constructs: base types or constructed types. Type environments are expressed through declarations. A value can be declared as being of a base • predicate formula constructs for writing data predicate formulas over a set of data values using data variables, data operatype or a constructed type. The abstract syntax of base types and tors and predicate operators, of constructed types are defined in Figure 5 and Figure 6, respec• action formula constructs for writing action predicate formutively. las over a set of connection and data values, • regular formula constructs for writing regular expressions Abstract syntax of base types (i.e., regular formulas) defined over action formulas using regular operators, BaseType ::= Any • state formula constructs for writing modal formulas defined | Natural over regular formulas and value variables using predicate, modal, and parameterised fixed point operators, | Integer • connection formula constructs for writing formula on connec| Real tions as first-class elements, taking into account connection mobility among architectural elements, i.e., components and | Boolean connectors. |

String

|

Behaviour

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

Figure 5. Abstract syntax of base types

Abstract syntax of formulas Formula

::=

predicateFormula

|

actionFormula

|

regularFormula

|

stateFormula

Figure 7. π-AAL kinds of formulas 4

ACM SIGSOFT Software Engineering Notes

Page 5

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

March 2006

Volume 31

Number 2

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 i1

o1 F1

i2 P

F2

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

o2

Predicate formulas are formulas of the first-order predicate calculus built using data value expressions as terms. A very simple pipe-and-filter architecture (a pipeline)

Predicate formulas are defined by the following abstract syntax. Abstract syntax of predicate formulas predicateFormula

::=

value

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

|

false

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 correctly, or to lose it. For the sake of simplicity, we do not model the ports attached to architectural elements.

|

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 PredicateFormula), 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.

4.5 Predicate Formulas The predicate formula constructs enable to write data predicate formulas over a set of data values using data variables, data operators and predicate operators. Data expressions are defined by the following abstract syntax.

Derived predicate operators are defined as usual, as follows. Abstract syntax of data expressions value

::=

Derived predicate operators

variable | function (value1, …, valuen) true = not false

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

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

Figure 9. Abstract syntax of data expressions

predicateFormula1 xor predicateFormula2

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.

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

The abstract syntax for navigational application is as follows.

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

Figure 12. Derived predicate operators

5

ACM SIGSOFT Software Engineering Notes

Page 6

March 2006

Volume 31

Number 2

The universal quantifier is defined as follows. Abstract syntax of action formulas Universal predicate quantifier

actionFormula ::=

forall variable : Type . predicateFormula =

action |

actionWithWildcard

|

unobservable

Figure 13. Universal predicate quantifier

|

false

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

|

not actionFormula

|

actionFormula1 or actionFormula2

|

exists variable : Type . actionFormula

::=

via name send value1,…, valuen

|

via name receive value1,…, valuen

::=

via name send any

|

via name receive any

not exists variable : Type . not predicateFormula

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:

action

actionWithWildcard

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

Figure 14. Abstract syntax of action formulas This predicate formula states that a filter of the architecture cannot be connected directly to another filter. Here, connections is an Derived boolean operators are defined as usual, as follows. operator calculating the set of connections attached to an architectural element f; the predicate connect(c1, c2) expresses that two Derived action operators connections c1 and c2 are connected; and the operator includes true = not false checks the membership of a connection to a set. actionFormula1 and actionFormula2 =

Another example of connectivity property is given by the following formula:

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

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

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

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

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

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

Figure 15. Derived action operators

Action formulas are defined according to the following abstract syntax. The universal quantifier is defined as follows. 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 6

ACM SIGSOFT Software Engineering Notes

Page 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.

March 2006

Volume 31

Number 2

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

denotes the set { o1 } ⊆ ActionSet. The boolean connectives and the quantifiers have the usual meanThe empty action set ∅ is characterized by formula false, and the ing. full set ActionSet is characterized by formula true. The semantics of an action formula actionFormula in a context ε (which must assign values to all variables present in actionFor- 4.7 Regular Formulas mula), noted [[ actionFormula ]] ε ⊆ ActionSet, is defined induc- The regular formula constructs enable to write regular expressions tively (as detailed in [4]). (i.e., regular formulas) defined over action formulas using regular In the presence of quantifiers, the sets of free variables operators. fv(actionFormula) and bound variables bv(actionFormula) in an Indeed, a useful extension of temporal logics consists of introducactionFormula are defined in the usual way. An actionFormula is ing regular constructs, which provide a more user-friendly way of said closed iff fv(actionFormula) = ∅ and is said in normal form specifying properties than fixed point operators. A number of such iff fv(actionFormula) ∩ bv(actionFormula) = ∅. 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].

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.

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

i1

o2 i2 i1

regularFormula

i2

o2

o1 o1 o2 i1

i1

o1

o1 o2

::=

actionFormula

|

regularFormula1 . regularFormula2

|

regularFormula1 | regularFormula 2

|

regularFormula*

Figure 18. Abstract syntax of regular formulas

i1

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 operators: ‘.’ (concatenation), ‘|’ (choice), and ‘*’ (transitive reflexive closure).

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

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

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

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:

Empty sequence operator nil = false* Transitive closure operator +

regularFormula = regularFormula . regularFormula *

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

Figure 19. Derived regular operators

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

The notions of free and bound data variables are defined for reguAction sets can be characterized in a more elaborated manner by lar formulas by extending the corresponding notions defined for combining action formulas and other boolean operators. For inaction formulas. A regular formula regularFormula is said closed stance, the following formula: if fv(regularFormula) = ∅. The semantics of a regular formula regularFormula in a data con-

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

7

ACM SIGSOFT Software Engineering Notes

Page 8

March 2006

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

Volume 31

Number 2

8

o2 i2

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.

i1 7

i1 3

o2 o1 o1

4

o2 i1

i2

o1

5

i1 2

6

o1 o2

1

i1 (R1 . R2) . R3 = R1 . (R2 . R3) nil . R = R . nil = R

associativity of concatenation neutral element for concatenation

(R1 | R2) . R3 = R1 | (R2 | R3) R1 | R2 = R2 | R1 true* | R = R | true* = true*

associativity of choice commutativity of choice absorbing element for choice

R1 . R2 | R1 . R3 = R1 . (R2 | R3) R1 . R3 | R2 . R3 = (R1 | R2) . R3

distributivity of concatenation over choice

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

nil | R* = R* R1* . R2 = R2 | R1 . R1* . R2

absorption of empty sequence Arden’s rule

Simple execution sequences consisting of one action can be specified using atomic regular formulas (i.e., action formulas). For instance, the following regular formula:

0

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

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

Figure 20. Useful algebraic properties

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.

Regular formulas are natural extensions of PDL regular expressions 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 using fixed point operators), but from a practical point of view they allow a much more concise and readable specification of properties than plain modal µ-calculus.

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

Let us consider again the pLTS model of the simplified pipe-and(via i2 send any) . (not (via o2 receive any)) . (via i1 send any) filter architecture introduced so far. In order to illustrate the interpretations of regular formulas, we identified each state by a natural denotes the relation { (s7, s5) } containing the pair of states which number (the initial state is numbered 0). 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 consecutive 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 formula: 8

ACM SIGSOFT Software Engineering Notes

Page 9

March 2006

Volume 31

Number 2

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

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

Derived state operators

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

true = not false stateFormula1 and stateFormula2 = not (not stateFormula 1 or not stateFormula 2) stateFormula1 xor stateFormula2

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

(stateFormula1 or stateFormula2) and not (stateFormula1 and stateFormula2) stateFormula1 implies stateFormula 2 = not stateFormula1 or stateFormula2 stateFormula1 equivalent stateFormula2 =

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

(stateFormula1 implies stateFormula2) and (stateFormula2 implies stateFormula1)

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

Figure 23. Derived state operators The universal quantifier is defined as follows.

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

Universal state quantifier forall variable : Type . stateFormula =

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 neutral element for concatenation.

not exists variable : Type . not stateFormula

Figure 24. Universal state quantifier

The necessity operator ‘[ ]’is defined as the dual of the possibility 4.8 State Formulas operator denoted by angular brackets ‘〈〉’ as follows. The state formula constructs enable to write modal formulas defined over regular formulas and value variables using predicate, Necessity operator modal, and fixed point operators. [ regularFormula ] stateFormula = not 〈 regularFormula 〉 not stateFormula Let ParameterisedVariableSet be a set of (parameterised) propositional variables. Each propositional variable Variable ∈ ParameFigure 25. Necessity operator terisedVariableSet denotes a mapping from a data domain ValueSet denoted by its Type to the powerset of the state set StateThe maximal fixed point operator (usually noted ν) is defined as Set, 2StateSet. The state formulas of the language (noted stateForthe dual of the minimal fixed point operator (usually noted µ) as mula) are defined according to the following abstract syntax. follows.

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

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

stateFormula) (value)

Figure 22. Abstract syntax of state formulas 9

ACM SIGSOFT Software Engineering Notes

Page 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 propositional 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 stateFormula 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 [[ stateFormula ]] ρε ⊆ StateSet, is defined inductively (as detailed in [4]).

March 2006

Volume 31

Number 2

[ (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 executing 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:

The semantics of minimal fixed point operators is defined in a way minimal fixpoint X . 〈 true 〉 true and similar to recursive functions in a functional language (i.e., as the [ not (via o1 receive any) ] X minimal fixed point of a monotonic functional defined on a complete lattice). For closed state formulas stateFormula (i.e., formulas without free data variables or propositional variables), their characterizes the states starting at which all outgoing transition semantics is denoted by [[ stateFormula ]] because it does not sequences lead, after a finite number of steps, to an output action of filter F1. It can be interpreted intuitively as follows: the current depend upon any data context or propositional context. state (i.e.,, the state on which the propositional variable X is evaluNote that for expressing the satisfaction of a stateFormula in ated) has at least one successor, and all its successor transitions every state of a pLTS, the architect must use the formula [ true* ] not labelled by an o1 action lead to states satisfying X. Since X is a stateFormula, which (when verified using a local model checker) minimal fixed point, after a finite number of steps a state having ensures that all states reachable from the initial state via sequences only o1-successors (i.e., a state satisfying the subformula 〈 true 〉 of zero or more transitions satisfy stateFormula. true and [ not (via o1 receive any) ] false) will be reached. This Let us illustrate now the interpretation of state formulas on the formula is satisfied by all states of the pLTS shown in Figure 17, pLTS model of the simplified pipe-and-filter architecture intro- which means that filter F1 can always eventually output a data, and therefore it does never block. duced so far. Modal operators allow to express simple formulas involving states Maximal fixed point operators are useful for invariant properties and their outgoing transitions. For instance, the simple modal (many of which can be expressed using regular modalities), but also for describing infinite execution sequences that violate some property below: fairness property. For instance, the following formula: 〈 via o2 receive any 〉 true

maximal fixpoint Y . 〈 not (via i2 send any) 〉 Y

characterizes the states { s2, s5, s6, s8 }, which have an outgoing characterizes the states from which there exists an infinite setransition labelled by an output action of filter F2. quence not containing an input action of filter F2. Intuitively, it More complex modal properties can be obtained by using regular expresses that the current state must have at least one outgoing operators inside modalities. For instance, the following property: transition labelled by an action other than i2 and leading to a state from which this is possible again an infinite number of times 〈 (via i1 send any) . (via i2 send any) | (since Y is a maximal fixed point variable). All states of the above (via o1 receive any) . (via o2 receive any) 〉 true pLTS satisfy this formula, which means filter F2 may never get an input data (livelock). This starving situation arises because we denotes the state subset { s4, s5, s6 } containing all states which assumed that pipe P is unreliable, i.e., it may lose forever data are origin of a two-step transition sequence of consecutive input emitted by filter F1. actions or output actions. Box modalities followed by false are useful for expressing the 4.9 Connection Formulas absence of certain undesirable transition sequences (safety proper- The connection formula constructs enable to write formula on connections as first-class elements, taking into account connection ties). For instance, the following property: mobility among architectural elements, i.e., components and connectors. 10

ACM SIGSOFT Software Engineering Notes

Page 11

March 2006

Indeed, in dynamic software architectures, interconnection topology may dynamically change. Furthermore, in mobile environments, 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 currently aware of.

syntax of property definition

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

syntax of property application

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 connections 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 architectural 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 following formula:

Volume 31

Number 2

Abstract syntax of property definition and application

PropertyDefinition ::=

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

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 allows to express safety, liveness, and fairness properties in a natural 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:

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

[ 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 between 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 emission initially, no two consecutive emissions without a reception in between, and no two consecutive receptions without an emission where the operator includes tests the membership of a connection in between): to a set, the operator cSet −> including c computes the set obtained by adding c to the connection set cSet, and the predicates receiving [ (not (via s send any))* . (via r receive any) ] false and (c) and sending (c) indicate whether a connection c is dedicated [ true* . (via s send any) . (not (via r receive any))* . 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.

(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 colThe abstract syntax for property definition and application is lapsing it into a single box modality (by applying modal logic and regular expression identities): defined as follows. [ ((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

11

ACM SIGSOFT Software Engineering Notes

Page 12

March 2006

Volume 31

Number 2

Regular modalities also allow to express some fairness properties, [ true* ] (maximal fixpoint Y (k:Nat) . such as fair reachability of an action (i.e., the reachability of the [ via input receive any ] Y (k - 1) and action by assuming that all circuits in the pLTS are exited after a [ via result send any ] (k = 0) and finite number of steps – which could be ensured by a fair sched[ not ((via input receive any) or (via result send any)) ] Y (k) uler). For instance, the following property states that after request) (10) ing a resource, under the fairness condition above, a process will get the access to the resource after a finite number of steps: The propositional variable Y is parameterised by a counter k which is equal to 10 minus the number of input actions encoun[ true* . (via request send any) ] tered along the path from the initial state to the current state. 〈 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 following formula:

An example of characterizing the evolution of data during the execution 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)

[ 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 constructs, 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

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 operaRegular modalities used together with quantification and data tors provide a very expressive temporal logic. predicates allow to express safety properties concerning parameterised processes. For instance, the property below states the ac- 4.12 Relating Properties to Architectures cess in mutual exclusion of two concurrent processes to some Architectural properties are related to architecture descriptions. shared resource (the communication connections open and close Thereby, architectural properties specify their completeness, condenote the beginning and release of the critical sections, respec- sistency and correctness. tively): The abstract syntax for relating architectural properties to architecture descriptions is defined as follows. forall p1, p2 : Behaviour . [ true* . (via open send p1) . (not (via close send p1))* . (via open send p2) ] (p1 ≠ p2)

Relating Properties to Architectures architecture {

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 result only after 10 inputs have been read:

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. 12

ACM SIGSOFT Software Engineering Notes

Page 13

March 2006

Volume 31

Number 2

Classical pipe-and-filter architectures, e.g., pipelines, are used tically choose either to transmit data correctly, or to lose it. when a sequence of transformations is applied to a stream of data by a sequence of filters, producing a final output. Hence, pipelines connector UnreliablePipe is abstraction() { type Data is Any. are pipe-and-filter architectures composed of a single chain of port is { pipes and filters. A pipe transmits output of one filter to input of connection input is in(Data). another filter. A filter transforms data received from its input and connection output is out(Data) sends the transformed data to its output. Filters do not share state, } assuming { i.e., they do not know about upstream or downstream filters. 5.1 Architecture Description In a pipeline architecture:

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() }

• 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 A very simple pipeline architecture, like the one introduced in the data from input to output as they are; • a pipe connects two filters, it transmits an output of a filter to previous section to illustrate π-AAL constructs, shown in Figure 8, can be formally described as follows. It uses an unreliable pipe. 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 follows. 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() } }

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 describe a pipe that is unreliable, i.e., it can nondeterminis- Let us now specify different kinds of architectural properties that 13

ACM SIGSOFT Software Engineering Notes

Page 14

March 2006

Volume 31

Number 2

must be analysed in order to guarantee the completeness, consis- Using π-AAL, these architectural properties can be easily specitency and correctness of the architecture. fied. Architectural completeness means that the architecture description Let us use the pipeline architecture and its components and condoes not lack components, connectors, connections or their parts nectors described so far to show how these properties could be or interrelationships with respect to architecture-specific, archi- expressed using π-AAL. tect-defined, properties. The behavioural property “there is a safe alternation of send and For instance, a pipeline architecture could be considered to be receive actions in filters” can be formally specified as follows. It complete if all pipes have their input and output connections con- expresses that there is no send before a receive initially, no two nected to filters and all filters, but the first and last one, have their consecutive receives without a send in between, and no two coninput and output connections connected to pipes. Of course, input secutive sends without a receive in between. connections must be unified to output connections. 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

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 unified 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 applied to all data. Thereby, completeness, consistency and correctness are semantic properties, and as so are defined with respect to analysis of architecture-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 deadlockfree, • 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 architect could specify and verify if: • there is a safe alternation of send and receive actions in components, i.e., in filters, • there is a safe alternation of send and receive actions in connectors, 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 pipeline, • there is an inevitable reachability of the transform function after receive actions in the pipeline, • all data received in components and connectors are transmitted.

Once a property is specified, it can be applied for verification purpose as follows. In that case, it is verified for every filter component, 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-

14

ACM SIGSOFT Software Engineering Notes

Page 15

fied above is by collapsing it into a single box modality by applying 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

March 2006

Volume 31

Number 2

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 specified 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 safety alternation property was specified above for filter components. It can be formally specified for pipe connectors as follows. 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

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

Once specified, this property can be applied for verification purpose as follows. In that case, it is verified for every pipe connector, independent of the context of any 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 follows. It expresses that a filter port cannot be connected to another In the following case, in a similar way as for components, it is filter port in a pipeline architecture. verified for every pipe connector of the pipeline architecture. using { P is Pipe() } verify { P.safetyAlternationInConnector }

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

15

ACM SIGSOFT Software Engineering Notes

Page 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) } } } }

Volume 31

Number 2

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 | transf.name = 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 property “there is the right connectivity, in terms of the pipeline 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) } } } } }

March 2006

The behavioural property “there is an inevitable reachability of the transform data function after receive actions in a pipeline architecture” 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 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 transform 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.

The property “in a pipeline architecture, all data received in components 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.

16

ACM SIGSOFT Software Engineering Notes

Page 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 −> forall { d | every sequence { true* . via r receive d } leads to state { finite tree Y given 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

March 2006

Volume 31

Number 2

[20][21], AESOP [19], AML [52], ARMANI [37], CHAM-ADL [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 Architecture 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 address 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 structure and 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 behavioural properties concerning architecture descriptions obtained by instantiating a given style.

Now let us attach the architectural properties defined above to the Regarding behavioural properties, the choice of modal µ-calculus pipeline architecture described so far. as the underlying formalism provides a significant expressive power. Moreover, the extension of µ-calculus modalities with architecture Pipeline is abstraction(n : Natural) { higher level constructs such as regular formulas inspired from behaviour is compose { early dynamic logics like PDL [14] facilitates the specification F is sequence for i = 1 to n using Filter() task of the practitioners, by allowing a more natural and concise and P is sequence for i = 1 to n using Pipe() description of properties involving complex sequences of actions. } where { iterate sequence(1..n) by i do { P::i::input unifies F::i::output The extension of fixed point operators with data parameters also and P::i::output unifies F::(i+1)::input } provides a significant increase of the practical expressive power, } and is naturally adapted for specifying behavioural properties of } assuming { value-passing languages such as π-ADL. (components −> forall { c | c.safetyAlternationInComponent()) and (connectors −> forall { c | c.safetyAlternationInConnector()) and connectivityBetweenPipesAndFilters() and connectivityBetweenPipes() and connectivityBetweenFilters() and connectivityOfPipeFilter() and deadlockFreedom() and fairReachabilityOfTransformData() and inevitableReachabilityOfTransformAfterReceive() and dataTransmission()

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 [23], various architectural styles (e.g., repository, pipe-and-filter, and event-action) are described 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-andfilter 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 It is worth noting that an architect can also define architectural CCS is described in [7]. All these works provide rather ad-hoc styles using π-ADL together with π-AAL by defining component solutions for a class of software architectures limited to static and connector abstractions and constraints on how they must (or communication between architectural elements, and can be subsumed by the more general framework provided by π-AAL (with should) be used to define specific architectures. π-ADL) and its verification tools. 6. Related Work A more detailed positioning of π-AAL (as well as π-ADL and πSeveral Architecture Description Languages (ADLs) have been ARL) w.r.t. the state-of-art is given in [16][30][40]. proposed in the literature [35], including: ACME/Dynamic-ACME 17

ACM SIGSOFT Software Engineering Notes

Page 18

March 2006

Volume 31

Number 2

the π-Method, like formal methods such as B [1], FOCUS [50][45], VDM [15], and Z [11], aims to provide full support for π-AAL supports formal specification (and corresponding verificaformal description and development. Unlike these formal methods tion) of both structural and behavioural properties. This is a key that do not provide any architectural support, the π-Method has factor in the architectural design phase in order to support semanbeen built from scratch to support architecture-centric formal tic correctness. software engineering. A major impetus behind developing formal languages for architecture analysis is that their formality renders them suitable to be ma- References nipulated by software tools. The usefulness of an AAL is thereby [1] Abrial J.-R.: The B-Book: Assigning Programs to Meanings. Camdirectly related to the kinds of tools it provides to support autobridge University Press, 1996. mated verification. Indeed, π-AAL is supported by a comprehen- [2] Allen R.: A Formal Approach to Software Architectures. PhD Thesive analytical toolset composed of: sis, Carnegie Mellon University, 1997. 7. Conclusion and Future Work

• •

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 also includes πADL for architecture description and π-ARL for architecture refinement. π-AAL provides the language to express proof obligations to guarantee the correctness of the descriptions and their refinements. π-AAL (jointly with π-ADL and π-ARL) has been applied in several realistic case studies and industrial business cases at Thésame (France) and Engineering Ingegneria Informatica (Italy) in the framework of the ArchWare European Project. In the pilot project at Thésame, an agile integrated industrial process system was architected, analysed, and refined. In the pilot project at Engineering Ingegneria Informatica, a federated knowledge management system 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 in the following application domains: • component-based software systems for sensor-actuator networks, • mobile agent software systems, • service-oriented architectures for grid computing systems, • service-oriented architectures for enterprise application integration. All these domains are characterised by the need of architecture description, analysis, and refinement languages powerful enough, in terms of expressiveness, to describe, analyse, and refine dynamic 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. Furthermore, the π-ArchWare software environment itself is a validation 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

[3] Allen R., Douence R., Garlan D.: Specifying and Analyzing Dynamic Software Architectures. In Fundamental Approaches to Software Engineering, LNCS 1382, Springer Verlag, 1998. [4] Alloui I., Garavel H., Mateescu R., Oquendo F.: The ArchWare Architecture Analysis Language: Syntax and Semantics. Deliverable D3.1b, ArchWare European RTD Project, IST-2001-32360, January 2003. [5] Alloui I., Oquendo F.: Supporting Decentralised Software-intensive Processes using ZETA Component-based Architecture Description Language. Enterprise Information Systems, Joaquim Filipe (Ed.), Kluwer Academic Publishers, 2002. [6] Bernardo M., Ciancarini P., Donatiello L.: Architecting Systems with Process Algebras. Technical Report UBLCS-2001-7, July 2001. [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. [8] Binns P., Engelhart M., Jackson M., Vestal S.: Domain-Specific Software Architectures for Guidance, Navigation, and Control. International Journal of Software Engineering and Knowledge Engineering. 1996. [9] Chaudet C., Greenwood M., Oquendo F., Warboys B.: ArchitectureDriven Software Engineering: Specifying, Generating, and Evolving Component-Based Software Systems. IEE Journal: Software Engineering, Vol. 147, No. 6, UK, December 2000. [10] Chaudet C., Oquendo F.: A Formal Architecture Description Language Based on Process Algebra for Evolving Software Systems. Proceedings of the 15th IEEE International Conference on Automated Software Engineering (ASE’00). IEEE Computer Society, Grenoble, September 2000. [11] 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 Architecture Workshop, San Francisco, 1996. [13] Fernandez J-C., Garavel H., Kerbrat A., Mateescu R., Mounier L., Sighireanu M.: CADP (CAESAR/ALDEBARAN Development Package) – A Protocol Validation and Verification Toolbox, Proceedings of the 8th International Conference on Computer-Aided Verification, New Brunswick, USA, LNCS 1102, Springer Verlag, August 1996. [14] Fischer M.J., Ladner R.E.: Propositional Dynamic Logic of Regular Programs. Journal of Computer and System Sciences Vol. 18, 1979. [15] Fitzgerald J., Larsen P.: Modelling Systems: Practical Tools and Techniques for Software Development, Cambridge University Press, 1998. [16] Gallo F. (Ed.): Annual Report: Project Achievements in 2002. Appendix B: Survey of State-of-the-Art and Typical Usage Scenario for ArchWare ADL and AAL. Deliverable D0.4.1, ArchWare European RTD Project, IST-2001-32360, February 2003.

18

ACM SIGSOFT Software Engineering Notes

Page 19

[17] Garavel H.: Compilation et Vérification de Programmes LOTOS. Thèse de Doctorat, Univ. Joseph Fourier (Grenoble), November 1989. Chapter 9: Vérification (In French). [18] Garavel H., Lang F., Mateescu R.: An Overview of CADP 2001. European Association for Software Science and Technology (EASST) Newsletter, Vol. 4, August 2002. [19] Garlan D., Allen R., Ockerbloom J.: Exploiting Style in Architectural Design Environments. Proceedings of the ACM SIGSOFT Symposium on Foundations of Software Engineering, New Orleans, 1994. [20] Garlan D., Monroe R., Wile D.: ACME: An Architecture Description Interchange Language. Proceedings of CASCON'97, Toronto, November 1997. [21] Garlan D., Monroe, R., Wile D.: ACME: Architectural Description of Component-Based Systems. Foundations of Component-Based Systems, Leavens G.T, and Sitaraman M. (Eds.), Cambridge University Press, 2000. [22] Groote J. F., Mateescu R.: Verification of Temporal Properties of Processes in a Setting with Data. Proceedings of the 7th International Conference on Algebraic Methodology and Software Technology, Amazonia, Brazil, LNCS 1548, January 1999. [23] Heisel M., Levy N.: Using LOTOS Patterns to Characterize Architectural Styles, Proceedings of the International Conference on Theory and Practice of Software Development, LNCS 1214, Springer Verlag, 1997. [24] IEEE Std 1471-2000: IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, October 2000. [25] Inverardi P., Wolf A.: Formal Specification an Analysis of Software Architectures using the Chemical Abstract Machine Model. IEEE Transactions on Software Engineering, Vol. 21, No. 4, April 1995. [26] 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. [27] Kerschbaumer A.: Non-Refinement Transformation of Software Architectures. Proceedings of the ZB2002 International Workshop on Refinement of Critical Systems: Methods, Tools and Experience, Grenoble, Janvier 2002. [28] Kozen D.: Results on the Propositional µ-Calculus. Theoretical Computer Science 27:333-354, 1983. [29] Leymonerie F., Cimpan S., Oquendo F. : Extension d'un langage de description architecturale pour la prise en compte des styles architecturaux : application à J2EE. Proceedings of the 14th International Conference on Software and Systems Engineering and their Applications. Paris, December 2001 (In French). [30] Leymonerie F., Cimpan S., Oquendo F., "État de l'art sur les styles architecturaux : classification et comparaison des langages de description d'architectures logicielles", Revue Génie Logiciel, No. 62, September 2002 (In French). [31] Luckham D.C., Kenney J.J., Augustin L.M., Vera J., Bryan D., Mann W.: Specification and Analysis of System Architecture Using RAPIDE. IEEE Transactions on Software Engineering, Vol. 21, No. 4, April 1995. [32] Magee J., Dulay N., Eisenbach S., Kramer J.: Specifying Distributed Software Architectures. Proceedings of the 5th European Software Engineering Conference, Sitges, Spain, September 1995. [33] Mateescu R., Garavel H.: XTL: A Meta-Language and Tool for Temporal Logic Model Checking. Proceedings of the 1st International Workshop on Software Tools for Technology Transfer, Aalborg, Denmark, July 1998. [34] Mateescu R., Sighireanu M.: Efficient On-the-Fly Model Checking for Regular Alternation-Free Mu-Calculus. Science of Computer Programming Journal, Elsevier, 2002.

March 2006

Volume 31

Number 2

[35] Medvidovic N., Taylor R.: A Classification and Comparison Framework 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. [37] Monroe R.: Capturing Software Architecture Design Expertise with ARMANI. 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. Computer Science Laboratory, SRI International, Technical Report SRICSL-97-01, March 1997. [40] Oquendo F.: The ArchWare Architecture Refinement Language. Deliverable D6.1b, ArchWare European RTD Project, IST-200132360, December 2003. [41] Oquendo F.: π-ADL: An Architecture Description Language based on the Higher Order Typed π-Calculus for Specifying Dynamic and Mobile Software Architectures. ACM Software Engineering Notes, Vol. 29, No. 3, May 2004. [42] Oquendo F.: π-ARL: An Architecture Refinement Language for Formally Modelling the Stepwise Refinement of Software Architectures. ACM Software Engineering Notes, Vol. 29, No. 5, September 2004. [43] Oquendo F.: Formally Modelling Software Architectures with the UML 2.0 Profile for π-ADL. ACM Software Engineering Notes, Vol. 31, No. 1, January 2006. [44] Oquendo F., Alloui I., Cimpan S., Verjus H.: The ArchWare Architecture Description Language: Abstract Syntax and Formal Semantics. Deliverable D1.1b, ArchWare European RTD Project, IST2001-32360, December 2002. [45] Philipps J., Rumpe B.: Refinement of Pipe and Filter Architectures. Proceedings of FM’99, LNCS 1708, 1999. [46] RAPIDE Design Team: Guide to the RAPIDE 1.0. Language Reference Manuals, Stanford University, July 1997. [47] Rongviriyapanish S., Levy N.: Variations sur le Style Architectural Pipe and Filter. Actes du Colloque sur les Approches Formelles dans l'Assistance au Développement de Logiciels (AFADL'00), Grenoble, France, January 2000 (In French). [48] 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. [50] Stolen K., Broy M.: Specification and Development of Interactive Systems. Springer Verlag, 2001. [51] Streett R.: Propositional Dynamic Logic of Looping and Converse. Information and Control Journal, 1982. [52] Wile D.: AML: An Architecture Meta Language. Proceedings of the 14th International Conference on Automated Software Engineering, pp. 183-190. Cocoa Beach. October 1999. [53] Wolper P.: Temporal Logic Can Be More Expressive. Information and Control Journal, 1983.

19