3° workshop nazionale del gruppo di interesse in ingegneria del software genova, 2-3 ottobre 2006...

3° Workshop Nazionale del Gruppo di Interesse in Ingegneria del Software

Genova, 2-3 ottobre 2006CASE – Libera Università

di Bolzano-BozenRCOST – Università

del Sannio

Dynamic Software Architectures for Global

ComputingAntonio BucchiaroneAntonio Bucchiarone

PhD Student – IMT Graduate School PhD Student – IMT Graduate School Via S. Micheletto, 55100 Lucca (Italy)Via S. Micheletto, 55100 Lucca (Italy)

Collaboration with

Stefania Gnesi and Antonia BertolinoISTI-CNR of PisaISTI-CNR of Pisa

2 3° Workshop Nazionale del Gruppo di Interesse in Ingegneria del Software

Genova, 2-3 ottobre 2006

Agenda Global Computing Systems From SA to DSA

SA view Dynamic Systems What is DSA? Why DSA? Open Issues

My initial idea Future Work



Global Computing Systems Autonomous computational entities where activity is not centrally

controlled (global services) Global control is impossible or impractical The entities are created or controlled by different owners

The system is open to the introduction of new computational entities, the behavior may vary over time (dynamic systems)

The offer is expected to evolve from relatively simple (customer) services to global complex (business) solutions (service-oriented computing).

Evolving systems (dynamicity and adaptability)



SW Architecture View High level system description in terms of subsystems

(components) and the way they interact (connectors) Static description (Topology) Dynamic description (Behavior) Service composition domain overlaps with SE in the

assembly of applications from components It provides a coarse-grained view separated from

implementation details whereas concentrates more on composition requirements Non-functional properties (QoS) Composition constraints



An Example: OS Layer SA

OS_RS_A ALS

OS_TT

Optical Link Manager

SDH SystemOS Layer

OS_CIOS_TT_MI

OS_RS_A_MI

ASL_MI

OS_AI

Application

Termination

Adaptation

S0

?cLOFon?cLOFoff

?cLOSon?cLOSoff

?setALSenable?setALSdisable

?alsManualRestart

S0

!dLOFoff

!dLOFon

!dLOSon

!dLOSoff

S1

?aTSFoff

S0

?dLOFoff?aTSFon?dLOFoff

?aTSFoff

?aTSFon

S3

?aTSFon?dLOFon

?dLOFon?dLOFoff

S2 S4

S6

?aTSFoff?dLOFon

S7

S5

?dLOFon

!cLOFon ?dLOFoff

!cLOFoff

?aTSFoff

!cLOFon

?aTSFon !cLOFoff

S0

S5

S4

S3

S2

S1

!cLOSoff

?dLOSoff

?dLOSon

!aTSFon

!aTSFoff

?dLOSoff

?dLOSon

!cLOSon

S6

S7

!clear_LOS

!set_LOS

?100s

S2

S0 S1

S5

S8

S6

S4

S3

S7

?setALSdisable?alsManualRestart

?setALSdisable

?setALSenable

?clear_LOS

?set_LOS!laserOFF

!laserON?alsManualRestart

?2s

?90s

?se

tALS

dis

ab

le

?setALS

ena

ble

!laserON



Dynamic Systems To support execution during runtime (SOA) for adapting to changes

Changing Requirements Request for new functions May require to integrate new components (statically or at run-time)

Changing Environments Faulty communication channels Mobility leading to a reduced bandwidth May require to replace unreachable components

Key Requirement: “a dynamic system should keep the application in the same state after a change”

Dynamic Reconfiguration



Support for Self-Management

• All dynamic architectural changes have four steps

• Self-Managing architecture: the entire change process occurs internally



What is DSA? DSA models a system that reacts to certain events at runtime by supporting

reconfiguration of the system’s architecture (Garlan ’98)

Support runtime management and reconfiguration of the systems without human interference (Self-adaptive Systems) Monitoring, analyzing, implementing and validating systems changes Internally or externally to the application

Reconfiguration operations Adding interfaces or components Removing interfaces or components Updating interfaces or components Changing the architecture topology by adding or removing connections between

interfaces



Why DSA? SOA is an example WSs are independent Services that are distributed in the

internet Services availability or performance is difficult to be

guaranteed (dynamic environments) The changeful requirements of SOA clients Stakeholders would like to extend their business models

Incorporate fresh available services Replace inefficient or inconvenient services

To evaluate non-functional properties (self-adaptation)} On-line

updating



Open Issues Modeling of DSA

It requires support for expressing “when” and “why” the Architecture should reconfigure

Currently this has limited support in existing modeling languages (ADL, UML, etc..)

We have need more expressive notations Analysis

Conformance of the DSA to the requirements Consistency of a DSA and an architectural style

To show that the style and the application are consistent from both static and dynamic point of view

Tools and Languages ArchJava, Java/A, Artemis-ARC, AGG, Fujaba, etc..



My initial idea A SA is represented by a typed graph G where nodes

stands for components and arcs for connectors A SA is dynamic if G may evolve to G’≠G The evolution of a DSA is a graph rewriting system Associated to each G there are associated

R(G): set of reachable configurations : set of desirable configurations

Example: “Programmed Dynamism” The change is triggered by the system and changes are

defined prior to run-time. In this case D(G) = R(G)

)()( GRGD



Future Work Modeling of DSA

Graph-based approach Validation and Verification

Reachability analysis by graph parsing Verify properties by Model-Checking Conformance of the DSA to the requirements Consistency of a DSA and an architectural style

Testing To derive test cases from graph transformation systems

Tools and Languages ArchJava, Java/A, Artemis-ARC, … A new tool?



Questions?

[email protected]

3° workshop nazionale del gruppo di interesse in ingegneria del software genova, 2-3 ottobre 2006...

Documents

software genova

workshop nazionale

dsa sa view dynamic

time dynamic systems

dynamic environments

pisa slide

adaptability slide

dynamic architectural