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 Dynamic Software Architectures for Global Computing Antonio Bucchiarone PhD Student – IMT Graduate School Via S. Micheletto, 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 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 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 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 An Example: OS Layer SA

3° Workshop Nazionale del Gruppo di Interesse in Ingegneria del Software Genova, 2-3 ottobre 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 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 What is DSA? DSA models a system that reacts to certain events at runtime by supporting reconfiguration of the systems 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 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

3° Workshop Nazionale del Gruppo di Interesse in Ingegneria del Software Genova, 2-3 ottobre 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 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 GG 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)

3° Workshop Nazionale del Gruppo di Interesse in Ingegneria del Software Genova, 2-3 ottobre 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?

3° Workshop Nazionale del Gruppo di Interesse in Ingegneria del Software Genova, 2-3 ottobre Questions?