Applying Tropos to Socio-Technical System Design and Runtime Configuration

1. Applying Tropos to Socio-Technical System Designand Runtime Configuration Fabiano Dalpiaz, Raian Ali, Yudistira Asnar, Volha Bryl, Paolo Giorgini Dipartimento di Ingegneria e Scienza dell’Informazione University of Trento, Italy

2. Outline • Socio-Technical Systems • Research question • Overview of Tropos • Design time techniques • Location in STSs • Risk analysis • Automating the design • Runtime support: self-reconfiguration • Conclusions and future work

3. Socio-technical systems • Socio-technical system (STS) • is opposed to traditional technical computer-based system • includes human agents as an integral part its structure • includes the knowledge of how it should be used to achieve the organizational objectives • is normally constrained by internal organizational rules, external laws and regulations • operates in continuously changing environment. • An STS • has to evolve dynamically in response to the environmental changes • has to be highly adaptable and reconfigurable.

4. Research question How to support the design and runtime reconfiguration of socio-technical systems?

5. Crisis Management as a STS

6. Tropos • An Agent-Oriented Software Engineering (AOSE) Methodology • Supports four phases • Early requirements • Late requirements • Architectural design • Detailed design • Adopts a requirements-driven development process • Derives from Eric Yu’s i* framework

7. Tropos - concepts Softgoal Actor Goal Task

8. Tropos - relations Means-end Or-decomposition Contribution Dependency And-decomposition

9. Tropos for STSs • Design time • The role of changing location is STSs • Risk analysis • Automating the design • Runtime • Tropos modeling can drive reconfiguration • Centralized vs decentralized reconfiguration

10. Location-based variability • Goal models provide: • High-level goals decomposition to discover alternatives. • Good modeling of the problem domain • Higher level of abstraction justifies why software is needed. • … but: • Goal models do not specify where an alternative is: • Applicable • Recommended • to solve this problem: • We propose Location-based goal model

11. Location-based goal modeling • Location-based (LB) goal models contain variation points annotated with location properties: • LB Or-Decomposition: the basic variability construct to express alternative goal decompositions • LB contribution: contributions to softgoals is location-based L2: low noise and system is trained on user voice L1: working sensing system and user’s PDA can connect to it. L3: high noise or system is not trained on user voice L1 L3 L2

12. Location-based goal modeling • LB dependency: the actor may depend on other actors in certain locations. • LB Goal-Activation: location changes the triggering (activate, stop) of goals. L5: analysis of sensing system signal indicates potential danger L4: a fireman that is not busy, skilled, close to and can reach the victim L4 L5

13. Location-based goal modeling • LB And-Decomposition: not all and-decomposition sub-goals are needed in every location. L6: kind of crisis requires special equipement or victim lack some skills required to face the crisis L6

14. Location-based reasoning • Location-based Goal Satisfiability (LGS) • Is a goal satisfiable in a certain location instance? • Location Property Satisfability (LPS) • What a Location lacks for satisfying a Goal • Preference Analysis (PA): Preferences can be specified over softgoals to choose when: • There is more than one alternative to satisfy a Goal in one location. • More than one Location modification is possible to make a goal satisfiable. • Formalization in Datalog

15. Modeling Uncertainty in STS • STS is captured: • Dependency network of Actors • Asset Layer • Objectives to achieve  Goals • Capability to achieve the objectives  Task • Event Layer • Uncertainty that can affect the asset layer  Event • Treatment Layer • Capability to mitigate negative events (i.e., risks)  Task

16. Relationship among constructs • Impact An event can affect positively/negatively to the asset layer • Two ways of mitigation: • Reduce Likelihood of an event • Reducing the negative impact of an event

17. Reasoning over the Model • Forward Reasoning compute the risk level in a STS for a given setting (e.g., value of goals, likelihood, treatments) • Backward Reasoning elicit the possible solutions: • strategy to achieve the goals • necessary treatments to mitigate the risks for a given set of constraints (e.g., tolerable risk level) • Note: • Risks propagate across actors in a STS • Trust - as subjective belief - is important to deduce the perception of an actor about risks

18. Automating the design • Design-time alternatives Alternative models: Alternatives differ in terms of cost, risk, various non-functional properties Initial organizational setting: Actors A and B, A wants to satisfy G, A can ask B for help, G can be refined into simpler subgoals

19. Automating the design • General planning-based schema • Exploring alternatives: AI planning techniques • Evaluating alternatives: global and local perspectives • Designer remains in the loop constraints on the input Input: actors, goals, and their properties Planner Evaluator Output: (sub) optimal design design alternative Input: evaluation criteria

20. Automating the design • Exploring alternative configurations in an STS can be framed as a planning problem • selecting a suitable configuration corresponds to constructing a plan that satisfies the goals of system actors • Planning problem is defined by • domain description: predicates, actions, axioms • predicates: wants, can_satisfy, can_depend_on, and_subgoal, … • actions: Satisfies, Delegates, Decomposes • problem description: initial and desired state

21. Runtime support to STSs • Design-time support to STSs is not enough • Not all violations can be prevented at design-time • E.g., runtime requirements violation is a well known issue • A runtime infrastructure for STSs should support • Interaction with humans • Continuous evolution of location • System self-reconfiguration • Compensation of failures • BDI agents are a good candidate to provide these properties • Our approach: link Tropos to BDI architectures

22. Self-reconfiguration • We propose two approaches • Centralized • Decentralized • The approaches are complementary • An STS such as a scientific institution can work properly only if a centralized knowledge of the agents is available • In crisis management scenarios, it’s often impossible to get complete information about all agents (the communication links are likely to fail); therefore, decentralized reconfiguration is more effective

23. Planning-based reconfiguration • Why and when to re-plan, 4 types of triggering events • New actor joins the system: load should be re-distributed • Existing actor leaves: his goals should be distributed among others • New goal is introduced: an assignment should be made • Goal is achieved: actor that satisfied the goal should not stay idle • Notification about the change is obtained either from system actors or from the environment • Continuous re-planning is avoided • Triggering events initiate re-planning only if the time passed since the last re-planning is greater than predefined time slot φ • Reconfiguration algorithm follows minimal change principle • The existing assignments are not changed whenever possible

24. Decentralized reconfiguration • Each agent performs a monitor-diagnose-compensate cycle • Monitor • Internal state (new goals, goal/plan fulfillment and failure) • Changes in the location • Interaction with other agents (enactment of Tropos dependencies) • Diagnose • Monitored events are linked to the agent’s goal model • Diagnosis outputs the cause of failures • Compensate • Compensation plan to “undo” the effects • Reconfiguration to choose another strategy • Implementation in Jason

25. Conclusions and future work • We presented a number of applications of Tropos for STSs • Design-time (location, risk, automated planning) • Runtime (reconfiguration) • Future work • Further elaborate the single techniques • Better integration of the techniques • Implement a CASE tool