1© Nokia Siemens Networks Antonio Bucchiarone Marie Curie Host Fellowships for the Transfer of Knowledge (TOK) Modelling Dynamic Software Architectures

1 © Nokia Siemens Networks Antonio Bucchiarone Marie Curie Host Fellowships for the Transfer of Knowledge (TOK)

Modelling Dynamic Software Architecturesusing Typed Graph Grammars

Antonio Bucchiarone

Co-authors:

Stefania Gnesi (ISTI-CNR of Pisa)

Hernan Melgratti (IMT of Lucca)

Roberto Bruni ( UniPi)

2 © Nokia Siemens Networks GT-VC07 – Lisbon / Antonio Bucchiarone / 03-09-2007 Marie Curie Host Fellowships for the Transfer of Knowledge (TOK)

Outline of the talk

• Introduction

• Related Work

• Formalization of Dynamicity

• Characterisation of Dynamism – Programmed

– Ad-hoc

– Constructible

– Reparing

• Case Study : Automotive Software System

• Constrained and Self dynamism

• Final Remarks and Future Works


Introduction


Introduction - I

• Computer Systems– From isolated “static” devices to highly interconnected machines

– Cooperative and coordinated execution

– Global Computing Systems (GCS) or network-aware computers

• Software Architectural models– Structure of a system in terms of computational components

– Interaction

– Composition patterns

– Abstract level without implementation details

• SA for GCS – Changes at design-time, pre-execution-time or run-time

– Dynamic Software Architectures (DSAs)


Introduction - II

• A variety of definitions of Dynamicity for SA in the literature

• Programmed– Changes are triggered by the system

– Changes are defined at design-time

• Self-Reparing– Changes are initiated and assessed internally

– The system is monitored to determine whether a change is needed

– A reconfiguration is automatically performed

• Ad-hoc– Modifications are initiated by the user as part of a SW maintenance task

– They are defined at run-time and are not known at design-time

• Constructible– It is a kind of ad-hoc mechanism

– There is a modification language for describing architectural changes


Objectives

• To understand the main notions of DSA by abstracting from particular languages and notations

• To give a uniform formal presentation that is abstract enough

• We select graph grammars as formal framework

– Formal basis and graph representation

– Natural way of describing styles and configurations

– Largely used for specifying architectures


Related Work

• Describing SA by using Graph Grammar– Our representation of DSA is borrowed from the Le Métayer approach [’98]– Hirsch et al [’98]

▪ Hyperdges are components and nodes are ports of communication▪ The reconfiguration is given as context-free productions together with a contraint solving

mechanism– Baresi et al [’04]

▪ They use graph transformation systems to model programmed architectural styles at different levels of abstractions.

– Other formalisms▪ Wermerlinger explores the ability of tha CHAM to express the dynamics of SAs [’98]

• Description of Dynamicity– Self-Repairing

▪ R. Allen et al. [’98], D. Garlan et al. [’02], I. Georgiadis et al. [’02]– Ad-hoc and Constructible

▪ M. Endler [’94] and P. Oreizy [’96]▪ As a programming language that allows for runtime modification of SAs

• Previous works aimed at providing real specification/programming/languages• We give an abstract characterization of such kind of mechanisms• We are interested in understanding how each dynamism is reflected into a graph

grammar


Formalization of Dynamicity


Introduction

• Components and Connectors as hyperedges

• Ports to which they are attached are nodes

• We show the ordering of tentacles by labeling the corresponding arrows with natural numbers


Hypergraph = SA

}{)(

}{)(

},{

},{

211

21

21

portportportconnector

portportcomponent

connectorcomponentE

portportN

H

H

H

H

A (hyper)graph is a triple H = (NH , EH , ΦH), where

• NH is the set of nodes

• EH is the set of (hyper)edges, and

• ΦH : EH NH+ describes the connections of the graphs


Typed Hypergraph = Configuration

GG |,|• Style: an hypergraph T

• Configuration: a pair where:– |G| is the underlying graph, and

– is a total hypergraph morphismTGG |:|Style:

• there is one unique type component of components exposing two ports of differents types( port1 and port2)

• one connector attached to two ports of type port1 and one port of type port2

Configuration


Total Hypergraph Morphism

': GGf

':,': EEfNNff EN

G (configuration) G’ (Style)

22

11

22

11

)(

)(

)(

)(

portportf

portportf

portportf

portportf

BN

BN

AN

AN

connectorconnectorf

componentcomponentf

componentcomponentf

E

BE

AE

)(

)(

)(

1


Rewriting = Reconfiguration

• A set of rewriting productions• A production is a partial, injective morphism of T-typed graphs

p: L→R • L and R areT-typed hypergraphs that are called left-hand and

right-hand side of the production• Given a T-typed graph G and a production p, a rewriting of G

using p can be informally described as follow:– Find a (type preserving) match of the left-hand side L in G, identify a

subgraph of G that corresponds with L,– Remove from the graph G all the items corresponding to the left-hand

side that are not in the right-hand side,– Add all the items of the right-hand side that are not in the left-hand

side– The elements that are both in L and R are preserved by the rewriting

step


Example of Productions

• Remove an existing connector and add a new connector that is attached to the original ports in a specular way with respect to the original one

• Productions with Negative Application Conditions

• The new connector can be added to the configuration if and only if no other connector of type connector is already attached in a specular way


Typed Graph Grammar = SA

• An Architecture will be described by a T-typed graph grammar – G = <T, Gin, P> where:

▪ Gin is the initial (T-typed) graph

▪ T defines the style

▪ P is a set of productions

• G →*G’ to denote that there exists a possible empty sequence of derivation step from G to G’ using the productions in P


Characterisation of Dynamism

• Characterization of different forms of dynamism in SA in terms of graph grammars

– Programmed

– Repairing

– Ad-hoc

– Constructible

• Given a grammar G = <T, Gin, P> we define:– The set R(G) of reachable configurations

▪ All configurations to which the initial configuration Gin can evolve

▪

– The set Dp(G) of desirable configurations▪ The set of all T-typed configurations that satisfies a desired property P

▪

}|{)( * GGGGR in

}Gin holds P graph typed-T a is |{)( GGGDP


Programmed dynamism - Modeling

• All architectural changes are identified at design-time and triggered by the system itself

• A programmed DSA A is associated with a grammar GA=<T,Gin,P>

– T stands for the style of the architecture– Gin is the initial configuration– P is a set of productions gives the evolution of the architecture

• The grammar fixes the types of all elements in the architecture, and their possible connections

• The productions state the possible way in which a configuration may change

• Programmed Dynanism provides an implicit definition of desirable configurations

DP(G) = R(G)


Programmed dynamism - Verification

• Consider the set of desirable configuration DP(G), it should be possible to know whether:

– The specification is correct, in the sense that any reachable configuration is desirable. This reduces to prove that

– The specification is complete, in the sense that any desirable configuration can be reached. This correspond to prove that

– Programmed dynamism provides an implicit definition of desirable configurations.

Gin holds :)( PGRG

)( holds P GRGthenGinif

)()(DP GRG


Repairing dynamism - Modeling

• Repairing systems are equipped with a mechanism that monitors the system behavior.

• If a deviation exists, the system itself is in charge of adapting the configuration

• GA=<T,Gin,P>

• P = Ppgm U Penv U Prpr

• Ppgm describe the normal, ideal behavior of the architecture– G’A=<T,Gin,Ppgm> is a programmed DSA

• Penv model the environment – “ the communication among components may be lost”– “ a non authorized connector become attached to a particular component”

• Prpr indicate the way in which an undesirable configuration can be repaired in order to become a valid one


Repairing dynamism - Verification

– The specification is correct. This reduces to prove that

– The specification is complete. This correspond to prove that

– In addition : “..whether the set of repairing rules assures that for any “..whether the set of repairing rules assures that for any configuration that is reachable but not desirable there exists a sequence of configuration that is reachable but not desirable there exists a sequence of reparing rules that move the configuration to a desirable one”reparing rules that move the configuration to a desirable one”

)':)('()R(GG)( ,A GGGRGPqGDG qArprAP

)()':)(',()( APqArprA GDGGGGRGPqGRG

rprnAPnqqq

qArprA

PqqGDGGG

then

GGGRGPqGRGif

n

,, and )(

)':)(',()(

01 10


Ad-hoc and Constructible dynamism

• Ad-hoc– The architecture evolves freely by adding and removing components

and connectors

– Typed grammar with an infinite number of hyperarcs (components and connectors)

– The set of Production is infinite, it must allow▪ adding/removing any kind of components and connectors

• Constructible– The rewriting productions are not free combination of basic primitives

▪ Full-fledged programs written in some specific language


Automotive Case Study


Overview

• R&D in vehicle production = Automotive Software

• Vehicles equipedd with a multitude of sensors and actuators

• Mobile technology– Connection to the telephone and internet infrastructure

• Communication– Inside a vehicle (intra-vehicle)

– To vehicles in the vicinity (inter-vehicle)

– With the environment through an Internet Gateway (vehicle-env)


Car Assistance Scenario - I

Components:• Vehicle (V): responsible for transmitting messages destined to the assistant server.• Accident Assistant Server (S): handles help requests

Connectors:• (V/V) : used for mediating the communication between two vehicles (V1/V2)• (V/S) : used for supporting the interaction between a vehicle and a server (V1/S)

SV1 V2

V1/S

V1/V2


Car Assistance Scenario –II

Architectural Style

A configuration


Programmed Dynamism

Architectural Style P1: New vehicle connected to the server

P2: Vehicles approximation

Initial configuration

•The set of desirable configurations consists of all configurations in which– Each vehicle has a unique, acyclic communication path with the unique server

– Each vehicle port has attached at most one connector


Repairing Dynamism

• The communication between vehicles is not reliable and can be lost

• The architecture should repair itself in order to provide unconnected components with a link to a server

• GA=<T,Gin,P>

• P = Ppgm U Penv U Prpr

– Ppgm contains the same productions ad defined in Programmed Dynamism

• Penv: a unique production which models the loss of connectivity between vehicles

• Prpr: when a vehicle is without outcoming connections, it is connected directly to the server


Constrained and Self Dynamism

• Whether the application of a transformation rule can take place

– At any moment or not?

– Constrained vs Unconstrained

• Whether changes are fired internally (self) by the system or activated externally (external)


Final Remarks


Conclusions

• We have characterized different aspects of dynamic reconfiguration– Programmed, Repairing, Ad-Hoc, Constructible– Graph rewriting systems– Completeness and correctness of the architectural specification

• Programmed– Correctness : P holds in every reachable configuration– Completness: any configuration satisfying P is reachable

• Repairing– Some reachable configurations may be non desirable– Those configurations should be transformed into a desirable one by using

repairing rules.• Ad-hoc and Constructible

– More limits, every configuration is potentially reachable– Infinite configurations (self-dynamism)– External Dynamism

▪ Ex: if a particular transformation or configuration program selected by a programmer produces a desirable configuration.


Future Work - I

• Verification of Properties for each dynamicity– Programmed and Reparing

– Non-Functional Properties▪ System Realiability and Availability

– Telecommunication Case Study ▪ SWARCES: Software Architecture for Embedded Systems

▪ Multi Service Access Network Element System (MSAN)

• DSAM&A– Eclipse-based framework to model and verify DSA

– Integrated with▪ Alloy by D. Jackson et al. (MIT) or

▪ DynAlloy by Marcelo F. Frias et al. (Universidad de Buenos Aires)


Future Work - II

Initial Software ArchitectureInitial Software Architecture

K1

CWE

DSS

K2

IUI1 DBOt b

b

t

t

b

b

t

t

b

Reconfiguration ProductionsReconfiguration Productions

K1

b

b

t

t

IUI1t

K1

b

b

tIUI1

t

IUI2t t

K1

b

b

tIUI1

t

IUI2t t

K1

b

b

t

t

P1

P2

Property DefinitionProperty Definition

pred Prop (tg: TG) { all e: tg.g.he| e in component

=> #(tg.g.conn[e])=2

}

Architectural StyleArchitectural Style

e1 e2

t

b

CounterExample CounterExample

The Property is valid for each Configuration


Questions!

Documents

1© Nokia Siemens Networks Antonio Bucchiarone Marie Curie Host Fellowships for the Transfer of Knowledge (TOK) Modelling Dynamic Software Architectures