310 likes | 512 Views
A software engineering approach to software runtime self-reconfiguration. Fabiano Dalpiaz. Talk outline. Autonomic Computing (AC) Motivation Self-* properties MAPE cycle Software engineering and AC The need of a software engineering approach Goal models to drive self-reconfiguration
E N D
A software engineering approach to software runtime self-reconfiguration Fabiano Dalpiaz
F. Dalpiaz Talk outline • Autonomic Computing (AC) • Motivation • Self-* properties • MAPE cycle • Software engineering and AC • The need of a software engineering approach • Goal models to drive self-reconfiguration • Key challenges • Towards goal-based self-reconfiguration • Required subsystems • BDI and Jason • Towards self-reconfiguration in Jason
F. Dalpiaz Autonomic Computing
F. Dalpiaz Why Autonomic Computing? • Current and future software exhibits • Inherent complexity • Computational distribution • A set of different strategies/behaviors (variability) • Interaction among different “components” • Software • Hardware (in general, sensors and effectors) • Humans • Run-time adaptivity to unpredicted circumstances Autonomic Computing
F. Dalpiaz Autonomic Computing and self-* properties • Autonomic Computing: computing systems that can manage themselves given high-level objectives from administrators [Hor01] • Self-* properties • Self-(re)configuration • Self-healing • Self-optimization • Self-protection • Self-reconfiguration and self-* • Is self-reconfiguration the mechanism to enact the other self-* properties?
F. Dalpiaz The Monitor-Analyze-Plan-Execute cycle • Autonomic Computing systems are made up of several autonomic elements [Kep03] • MAPE cycle • Monitor • What changed/happened? • Analyze • How to face the change • Plan • Define the actions to perform • Execute • Perform actions in response to the change • Self-reconfiguration is tightly linked to MAPE
F. Dalpiaz Software Engineering and Autonomic Computing
F. Dalpiaz The need of a Software Engineering approach • Many current approaches are poorly engineered • Ad-hoc • Focused on a single self-* property • Related to a particular case study (resource allocation, very often) • Abstract • Architectures makes sense if applied to real code • Lack of a “standard” infrastructure • Some engineering approaches exist • Look atEASe and SEAMS@ICSE workshops • Why not using a goal-driven approach?
F. Dalpiaz i*/Tropos to drive self-reconfiguration • Basic ingredients • Goals are functional requirements to be achieved • Plans are sequences of actions; plans are performed to achieve goals • Soft-goals are qualities that can be evaluated to select the best behavior • Variability constructs (OR-decomposition is the main one) enable different behaviors • Dependencies enable social interaction between different agents/actors
F. Dalpiaz Autonomic Computing and goal models: related work • Existing work on goal models and AC • Requirements-driven design of autonomic application software [Lap06] • Exploring and evaluating alternatives in socio-technical systems [Bry06] • Design of high-variability software agents [Pen07] • Reverse Engineering Goal Models from Legacy Code [Yu05] • The focus is mainly on design-time or offline • A run-time and online solution is missing
F. Dalpiaz Key ingredients to engineer autonomic software • Architecture • (Web)-Services or Agents to support distribution • Adapt established infrastructures • Guarantee reuse, extensibility, and scalability • Algorithms and reconfiguration mechanisms • The following questions should be answered: • When reconfiguring? • Why reconfiguring? • Which behavior should be selected? • How to enact compensation if something fails? • Integration with a SW development methodology
F. Dalpiaz Towards goal-based self-reconfiguration
F. Dalpiaz Supporting self-reconfiguration: subsystems • Monitor • Goals/Plans – check what went wrong • Environment – react to changes • Communication • Agents (or autonomic elements) need an infrastructure enabling interaction • Analyze/Reasoning • Decide if events should be handled • Choose the best strategy when variability exists • Planning • Define the course of actions to be carried out • Execution • Support both simulated and real environments
F. Dalpiaz BDI basics • Belief-Desire-Intention architecture • An agent-based architecture • Suitable to drive self-reconfiguring software • Beliefs represent the informational state of the agent • Desires (or goals) represent the motivational state of the agent • Intentions represent the deliberative state of the agent • Plans are sequences of actions that an agent can perform to achieve one or more of its intentions
F. Dalpiaz Jason: an AgentSpeak interpreter • Jason [Bor07] is interpreter for an extended version of AgentSpeak • AgentSpeak[Rao96] is a logic-based BDI language • The non-logical coding of agents exploits Java • Jason can be run centralized or decentralized (using JADE [Bel99] or SACI [Hub03]) • The framework is highly extensible and customizable • Goals are events, which are handled by plans • A shared environment exists, affected by actions
F. Dalpiaz The MAPE cycle in Jason • Jason Reasoning Cycle – an extension of the BDI loop – carried out by each agent • Monitor • Perceive the environment • Detect what changed in the environment • Update the belief base • Decide which changes become beliefs • By default, all changes are recorded as beliefs • Receive communication from other agents • Agents check the mailbox, one message for each cycle
F. Dalpiaz The MAPE cycle in Jason • Analyze • Select “socially acceptable” messages • Enables the filtering of unwanted messages • Select an event • Each cycle requires the selection of only one event • Retrieve all relevant plans • The plan library is searched for plans to handle the event • Determine all applicable plans • Verify whether the precondition holds • This step filters the relevant plans
F. Dalpiaz The MAPE cycle in Jason • Plan • Select one applicable plan • Meta-reasoning can be applied to select the plan • Select an Intention • Among the several concurrent intentions, choose one for the current reasoning cycle • Execute • Execute one step of the intention • One action is performed
Analyze: Determine socially acceptable messages (SocAcc) Belief Revision Function (BRF) Select event (SE) Select plan among the applicable ones (SO) F. Dalpiaz Customization in Jason Execute: Perform an action (act) Send a message (sendMsg) Plan: Select intention (SI) Monitor: Perceive the environment (perceive) Belief Update Function (BUF) Check incoming messages (checkMail)
F. Dalpiaz On the notion of goal: Jason vs. i*/Tropos • Goals in Jason • Goals are not declarative by their own nature • A declarative goal ensures that the expected state of the world is reached, after a plan is carried out • A plan executed to handle the achievement goal !drink(Beer) doesn’t assure the agent will believe drink(Beer) to be true • Goals can be made declarative using test goals +!drink(Beer) : drink(Beer) <- true. +!drink(Beer) : handles(Beer) <- open(Beer); empty(Beer); ?drink(Beer). +drink(Beer) : true <- .succeed_goal(drink(Beer)). Test goal Plan Achievement goal Precondition Plan body
F. Dalpiaz On the notion of goal: Jason vs. i*/Tropos • Goals in i*/Tropos • OR/AND goal Decomposition • Difficult to elegantly implement in Jason • What’s the purpose of internal goals? • internal = not leaf & not root • Are they part of the strategy (hence, plans) or of the requirements (hence, goals)? • They can be seen a way of organizing plans • Plans are code (have a body) • Goals enable variability and plans composition
F. Dalpiaz Adding self-reconfiguration to Jason: on the way • Take Jason as starting point • Extend Jason using its customization points • Integrate goal-model reasoning (i*/Tropos) • Two-levels reconfiguration • In the small (locally) • Every agent chooses the best option • In the large (globally) • Optimize the social structure (dependencies) • Use metrics to define what is optimal • Contracting vs. Enforcing dependencies • Organizational hierarchy to drive dependencies
F. Dalpiaz Adding self-reconfiguration to Jason: on the way • Goal reasoning vs. plan reasoning • Plans treated as atomic entities in the goal model • Plans “are” the leaf-level nodes of goal models • Plans can be refined in another layer
F. Dalpiaz An algorithm to select the best alternative • Selecting the best alternative (locally) • Plans pre-conditions checked against the environment • If false, the plan cannot be applied • Quantitative soft-goal contribution • Post-order visit (leafs first) • Bottom-up propagation: from plans to the root level goal • Soft-goals have a weight (their sum is 1.0) • Xor-decomposition select the best option • And-decomposition average
F. Dalpiaz Selecting the best alternative (1)Plan node
F. Dalpiaz Selecting the best alternative (2)Xor-decomposition
F. Dalpiaz Selecting the best alternative (3)And-decomposition
F. Dalpiaz Next steps • Evaluate and select the best approach for • Monitoring – guarantee scalability • Environment representation • Use of an ontology? • In-progress work for location-based software [Ali08] • Global reconfiguration • Compensation of plan failure • Case study identification • An industrial case study would be very effective • Design tool-support • Integrate with existing AOSE methodology • Tropos is being extended in this direction [Mor08]
F. Dalpiaz References (1) • [Hor01] Horn, P.: Autonomic Computing: IBM’s Perspective on the State of Information Technology. Keynote address at National Academy of Engineers at Harvard University. March 2001. • [Kep03] Kephart, J., Chess, D.: The Vision of Autonomic Computing. Computer 36(1) (Jan 2003) 41–50. • [Lap06] Lapouchnian, A., Yu, Y., Liaskos, S., Mylopoulos, J.: Requirements-driven design of autonomic application software. Proceedings of CASCON 2006 (2006). • [Bry06] Bryl, V., Giorgini, P., Mylopoulos, J.: Designing cooperative is: Exploring and evaluating alternatives. CoopIS 6 (2006) 533–550. • [Pen07] Penserini, L., Perini, A., Mylopoulos, J.: High Variability Design for Software Agents: Extending Tropos. ACM TAAS Journal 2(4) (2006).
F. Dalpiaz References (2) • [Yu05] Yu, Y., Wang, Y., Mylopoulos, J., Liaskos, S., Lapouchnian, A., do Prado Leite, J.C.S.: Reverse engineering goal models from legacy code. In Proceedings of International Conference on Requirements Engineering, pages 363–372, 2005. • [Bor07] Bordini, R.H., Wooldridge, M., Hubner, J.F.: Programming Multi-Agent Systems in AgentSpeak using Jason (Wiley Series in Agent Technology). John Wiley & Sons (2007). • [Rao96] Rao, A.S.: AgentSpeak (L): BDI Agents Speak Out in a Logical Computable Language. In Proceedings of MAAMAW’96, 1996. • [Bel99] Bellifemine, F., Poggi, A., Rimassa, G.: JADE – A FIPA-compliant agent framework. In Proceedings of PAAM, 1999. • [Hub03] Hubner, J.F., Sichman, J.S.: SACI Programming Guide.
F. Dalpiaz References (3) • [Ali08] Ali, R., Dalpiaz, F., Giorgini, P.: Location-based Variability for Mobile Information Systems. To appear in CAiSE’08. • [Mor08] Morandini, M., Penserini, L., Perini, A.: Towards Goal-Oriented Development of Self-Adaptive Systems. To appear in SEAMS’08 workshop @ICSE.