Bigraphical Modelling of Architectural Patterns

Abstract

Archery is a language for behavioural modelling of architectural patterns, supporting hierarchical composition and a type discipline. This paper extends Archery to cope with the patterns' structural dimension through a set of (re-)conguration combinators and constraints that all instances of a pattern must obey. Both types and instances of architectural patterns are semantically represented as bigraphical reactive systems and operations upon them as reaction rules. Such a bigraphical semantics provides a rigorous model for Archery patterns and reduces constraint verication in architectures to a type-checking problem.

On the verification of architectural reconfigurations

“…First, it is shown that the initial conguration satises the nested structural constraint enoughNurses (see listing 4). The result of translating the Archery specication of the initial conguration into an interpretation model is shown in gure 11.…”

“…Reconguration scripts are executed by a conguration manager when conditions, specied as constraints, hold. The language semantics is given by a translation into a process algebra [3], for the behavioural part, and by an encoding into bigraphical reactive systems [4], for the structural part. Constraints are translated into a modal logic and are veried against models derived from architectural specications [6,7,8].…”

“…Design principles are specied as formulas in a modal logic, and then are veried against models of recongurations. For this, we extend an architectural description language (ADL) [2] called Archery [3,4], which is a domain specic language [5] used to animate, analyse and verify system's architectures. It is organized as a core and a number of modules.…”

Painless Support for Static and Runtime Verification of Component-Based Applications

“…Apart from the Seq and Done constructors, the remaining operation constructors are handled analogously. Seq is composed by two operations (line 11), the leftmost operation is fully evaluated, and the resulting state is used for evaluating the rightmost operation (lines [12][13][14][15]. Done means that the end of the operation was reached, and it simply returns the current state (line 16).…”

“…This definition should be seen as a template, as its instances are the ones dynamically added/removed. Next, we define the Light Collector component (lines 21-23) and its two interfaces (lines [13][14][15][16][17][18][19]. The first interface is parametrized by its path as we shall use it later when specifying the Lights Control component (see Listing 1.11).…”