Adaptation and Dependability

1. Paola Inverardi http://www.di.univaq.it/inverard Adaptation and Dependability

2. The Problem/Question/Issue: Softure • Softure: Software in the near ubiquitous future • What are the challenges for software in this new era? • Copying with variability of contexts: Context Awareness • Self-adaptiveness/dynamicity/evolution • Dependability • …. • Are these challenges new in the Software domain?

3. Guess? • A project aiming at implementing a distributed system based on a high bandwidth local network is currently supported …Cnet… • Cnet is a suitable target for functionally distributed applications . … • Distributed embedded applications put special requirements on the programming language, in particular regarding : i) concurrence, ii )internode communication and iii) dynamic reconfiguration .

4. Why dynamic configuration? • Programmin g environments are a good example of embedded ap plications that need reconfi g urability . • In fact they are subject t o continuous evolution, due to tool modification or to new tool de -finition (op en endness) , In addition, a basic feature of an environment relates to the ca -pability of defining and activating an application Prog ram (the prog ram under develo p ment) . • This corres ponds to a tem p orar y reconfi g uration of the whole environment, au gmented with the app1ication pro g ram . • Hence, the environments require a dynamic reconfi g uration mechanism, i .e . reconfi g uration without full recom p ilation and/or r elinkin g . Such a mechanism must be p rovided be the imPlementatio n langua g e, in order to fulfill the inte g ration recujirement . • Ada

5. @article{989973, author = {P. Inverardi and G. Levi and U. Montanari and G. N. Vallario}, title = {A distributed KAPSE architecture},journal = {Ada Lett.}, volume = {III}, number = {2}, year = {1983}, issn = {1094-3641}, pages = {55--61}, doi = {http://doi.acm.org/10.1145/989971.989973},publisher = {ACM}, address = {New York, NY, USA}, }@inproceedings {IMV83, author = {P. Inverardi and U. Montanari and G. N. Vallario}, title = {How to Develop a Programming Environment Almost Completely in a Compiled Language},booktitle = { International Computing Symposium 1983 on Application Systems Development}, year = {1983}, pages = {429-438}, publisher = { Teubner}, }@article{DBLP:journals/spe/InverardiM93,author = {Paola Inverardi and Franco Mazzanti},title = {Experimenting with Dynamic Linking with Ada}, journal = {Softw., Pract. Exper.}, volume = {23}, number = {1}, year = {1993}, pages = {1-14}, bibsource = {DBLP, http://dblp.uni-trier.de}

6. A Software Engineering Perspective The process view: the focus is on the set of activities that characterize the production and the operation of a software service/system Growing Complexity of Software has exacerbated the dichotomydevelopment/static time vs execution/dynamic time  At present the focus is still on development time although the SOA paradigm has undermined it. Does SOA bring something new in this picture?

7. Service Description Service Provider Service Requester Service Registry Service Orientation (2/2) • To support dynamic discovery: • … after binding a service provider, a reference to the “serviceobject” implementing the service functionalities is returned. • Service Providers publish their servicedescription into a service registry … • … one ore more service provider references (if there exist) are returned … • Service Requestors interrogate the registry for a particular service description to discover service providers … discover publish Service Oriented Interaction Pattern bind

8. Softure: Back to the Challenges • Context Awareness : Mobility and Ubiquity  • (Self-)adaptiveness/dynamicity/evolution: define the ability of a system to change in response of external changes • Dependability: It is an orthogonal issue, focuses on QoS attributes (performance and all ---abilities) and … it is the challenge! It impacts all the software life cycle

9. Context Awareness • (Physical) Mobility allows a user to move out of his proper context, traveling across different contexts. • How different? In terms of (Availability of) Resources (connectivity, energy, software, etc.) but not only … • When building a system the context is determined and it is part of the (non-functional) requirements (operational, social, organizational constraints) • If contexts change, requirements change  the system need to change

10. When and How can the system change? • When? Due to contexts changes  while it is operating  at run time • How? Through (Self-)adaptiveness/dynamicity/evolution Different kind of changes at different levels of granularity, from software architecture to code line

11. Dependability: the why and the what • Why dependability for Softure? • My naive anthropological interpretation: “I would like to operate in the unknown world (i.e. out of my cozy home) with the same level of comfort/reliance I have at home” • At home I am in a controlled environment, I have complete knowledge of the system behavior and the context is fixed. • In the unknown world, the knowledge of the system is undermined by the absence of knowledge on contexts • What dependability attributes of interest? • QoS attributes

12. Dependability • the trustworthiness of a computing system which allows reliance to be justifiably placed on the service it delivers ... Dependability includes such attributes as reliability, availability, safety, security. (see IFIP WG 10.4  on DEPENDABLE COMPUTING AND FAULT TOLERANCE http://www.dependability.org/wg10.4/) How do we achieve dependability? All along the software life cycle from requirements to operation to maintenance. By analysing models, testing code, monitor execution

13. Dependability and QoS attributes • analysing models: functional and non-functional, several abstraction levels, not a unique model • testing code: various kind of testing e.g. functional-based, operational-based (still models behavioral and stochastic , respectively) • monitor execution: implies monitoring (yet another … model of) the system at run time, it impacts the middleware • Focus is on models, from behavioral to stochastic

14. Models II • Basis for Specifications ? Not only … • Expressiveness: adequately reflect all the interesting features of the specified system • Provability: should allow for proving interesting properties about the system What is interesting depends on the stakeholder => many models: • QoS (performance, reliability,etc.) Stochastic models • behavioral, automata, graphs, etc. • …

15. WHAT is ADAPTABILITY? • The ability to change a system according to context variations, e.g. driven by QoS requirements • But …Still remaining the same • Adaptability makes sense only if it preserves something …the Invariant

16. Evolving Systems: Adaptation • Systems that change structure and/or behaviour • Change the four Ws: • Why there is the need to change? • What does (not) change ? • When does the change happen? • What/Who How is the change managed?

17. ADAPTABILITY EXAMPLE: 1 CBSE-Synthesis Problem:The ability to establish properties on the assembly code by only assuming a relative knowledge of the single components properties. A software architecture represents the reference skeleton used to compose components and let them interact: interactions among components are represented by the notion of software connector.

18. local views of each component Component 1 Component 3 Component 1 Component 1 Component 3 Component 3 Connector code (assembly code) Connector Behavioral property deadlock-freeness Deadlock-free Connector Failure-free Connector Component 2 Component 2 Component 2 Connector Based Architecture Deadlock-free Connector Based Architecture Failures-free Connector Based Architecture Synthesis ex. 1 … (Tivoli-Inverardi) Connector Free Architecture Component 1 Component 3 Structure changes – equivalent behavior Component 2

19. What are the models and formalisms • An architectural model i.e. constraints on the way components can interact • Behavioural model for components -- LTS • Behavioral equivalence on LTS • Temporal logic – Buchi Automata • Model Checking

20. The four Ws: Synthesis * the four Ws: • Why there is the need to change? • To correct functional behavior. E.G. Avoid deadlock or force P, not due to change of context • What does (not) change ? • The topological structure and the interaction behavior • When does the change happen? • At Assembly time but also … • What/Who how the change is managed? • An external entity: Synthesis

21. Running software application Ex. 2 - PERFORMANCE : system reconfiguration Caporuscio-Di Marco-Inverardi Reconfigure it dynamically We want to … Monitor its performance a framework We reach our aims by means of … Decide its next running configuration Non

23. Interesting Issues • What is the relevant data to collect? And how to use it? • Data collected is more fine-grained than the performance model parameters. • Models have to be modified and evaluated online (fast solution techniques). • Which performance model should we use? • How do we take the decision on the next configuration? • Different aspects should be considered (security, resources availability,…)

24. The four Ws: Performance * the four Ws: • Why there is the need to change? • To correct non- functional behavior. i.e. Adjust Performance, context dependent • What does (not) change ? • The topological structure • When does the change happen? • At run time … • What/Who how the change is managed? • An external entity: the configuration framework

25. Resource-aware adaptation (Mancinelli-Inverardi) ex.3 • Based on generic programming to develop generic (wrt resource consumption) Java code (J2ME) . • Goal is to adapt the generic code to the resource profile of the execution environment • Allows reasoning on correct adaptations, i.e. correct match between adaptability and actual resources • Correctness wrt a Java (non-standard) operational semantics or resources consumption • Inspired by PCC

26. Reference Architecture • Development environment. It is supported by a programming model for defining how the application could be adapted. • Abstract resource analyzer. Provides the characterization in terms of resource demands of the possible adaptations, according to the characteristics of the execution environment defined through resource profiles. • Customizer. Analyzes the resource demands of the possible adaptations in order to choose the best one with respect to the resources supplied by the execution environment and its characteristics.

27. Conclusion • Adaptation at code level • Service customization depending on the device characteristics • Optimized and correct => certificated components

28. The four Ws: Resource AA * the four Ws: • Why there is the need to change? • To correctly utilize the host device resources (non functional??) context dependent. • What does (not) change ? • The service/application core behavior does not change • When does the change happen? • At deployment time …but • What/Who how is the change managed? • The deployment framework

29. Adaptation models Many dimensions to consider Cost/Validation P1 Behavior Pn P2 P1 Structure/constraints

30. Adaptable, Reliable & Performing Software Services for B3G Networks:An overview of the PLASTIC challenges http://www.ist-plastic.org Coordinator: Valerie Issarny – INRIA

31. ... Model1 Model2 ModelN Core Code Self- Evolving/Adaptive Code The Process View (ref. Plastic Deliverable D2.1) PS = Standard Engineering Process PEV = ??? Engineering Process Model1 Model1 ... Model2 Model2 ModelN ModelN PS compiling process PROCESS Frozen System Frozen System PEV Frozen Self- evolving/adaptive Running SYSTEM

32. PLASTIC Process