Dynamic Software Architectures
for Global Computing
Antonio Bucchiarone
PhD Student – IMT Graduate School
Via S. Micheletto, 55100 Lucca (Italy)
Collaboration with
Stefania Gnesi and Antonia Bertolino
ISTI-CNR of Pisa
3° Workshop Nazionale del Gruppo di
Interesse in Ingegneria del Software
Genova, 2-3 ottobre 2006
CASE – Libera Università
di Bolzano-Bozen
RCOST – Università
del Sannio
Agenda


Global Computing Systems
From SA to DSA
 SA view
 Dynamic
Systems
 What is DSA?
 Why DSA?
 Open Issues


My initial idea
Future Work
3° Workshop Nazionale del Gruppo di Interesse in Ingegneria del Software
Genova, 2-3 ottobre 2006
2
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)
3° Workshop Nazionale del Gruppo di Interesse in Ingegneria del Software
Genova, 2-3 ottobre 2006
3
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
3° Workshop Nazionale del Gruppo di Interesse in Ingegneria del Software
Genova, 2-3 ottobre 2006
4
An Example: OS Layer SA
?aTSFon
Adaptation
S1
?aTSFoff
?dLOFon
!cLOFoff
Application
?dLOFoff
OS_RS_A
?dLOFon
S4
S2
S6
?dLOFon
?aTSFoff
OS_AI
?aTSFoff
S7
S3
?aTSFon
?dLOFon
?aTSFon
?a l s
OS_RS_A_MI
S4
!la
s
Termination
OS_CI
OS_TT_MI
Ma n
ual
tar
Res
e rO
FF
S2
?90s
S8
S1
t
?clear_LOS
ASL_MI
OS_TT
!cLOFoff
S5
?2s
?100s
?dLOFoff
!la
N
se r O
?setALSdisable
?als
Ma n
ualR
esta
rt
S3
ALS
!cLOFon S5
!cLOFon
S6
?setALSenable
SDH System
OS Layer
?setALSdisable
?setALSenable
S0
S0
?setALSdisable
?dLOFoff
?aTSFon
?aTSFoff
?dLOFoff
s
!la
N
e rO
?set_LOS
S7
?dLOSoff
!clear_LOS
S0
S6
?dLOSon
Optical
Link
S1
!cLOSoff
!aTSFon
S5
S2
!dLOFoff
!cLOSon
!aTSFoff
S7
S4
?dLOSoff
?dLOSon
Manager
S3
S0
?cLOFoff
?cLOFon
S0
!set_LOS
!dLOFon
!dLOSoff
!dLOSon
?setALSenable
?setALSdisable
?cLOSoff ?alsManualRestart
?cLOSon
3° Workshop Nazionale del Gruppo di Interesse in Ingegneria del Software
Genova, 2-3 ottobre 2006
5
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
3° Workshop Nazionale del Gruppo di Interesse in Ingegneria del Software
Genova, 2-3 ottobre 2006
6
Support for Self-Management
• All dynamic architectural changes have four steps
• Self-Managing architecture: the entire change process
occurs internally
3° Workshop Nazionale del Gruppo di Interesse in Ingegneria del Software
Genova, 2-3 ottobre 2006
7
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
3° Workshop Nazionale del Gruppo di Interesse in Ingegneria del Software
Genova, 2-3 ottobre 2006
8
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
}
On-line
updating
To evaluate non-functional properties (self-adaptation)
3° Workshop Nazionale del Gruppo di Interesse in Ingegneria del Software
Genova, 2-3 ottobre 2006
9
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..
3° Workshop Nazionale del Gruppo di Interesse in Ingegneria del Software
Genova, 2-3 ottobre 2006
10
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
 D(G)  R(G) : 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)
3° Workshop Nazionale del Gruppo di Interesse in Ingegneria del Software
Genova, 2-3 ottobre 2006
11
Future Work

Modeling of DSA


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


Graph-based approach
To derive test cases from graph transformation systems
Tools and Languages


ArchJava, Java/A, Artemis-ARC, …
A new tool?
3° Workshop Nazionale del Gruppo di Interesse in Ingegneria del Software
Genova, 2-3 ottobre 2006
12
Questions? 
[email protected]
3° Workshop Nazionale del Gruppo di Interesse in Ingegneria del Software
Genova, 2-3 ottobre 2006
13