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

2. 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. 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 4 How to support the design and runtime reconfiguration of socio-technical systems?

5. 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 6

7. 7 Tropos - concepts ActorGoalTask Softgoal

8. 8 Tropos - relations DependencyAnd-decomposition Or-decomposition Means-end Contribution

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

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

13. 13 Location-based goal modeling 5. 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. 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. 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. 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. 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. 18 Automating the design Design-time alternatives 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 Alternative models: Alternatives differ in terms of cost, risk, various non-functional properties

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

20. 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. 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 22

23. 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 24

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 25