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

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.

Research question

4

How to support the design and runtime reconfiguration of socio-technical systems?

5

Crisis Management as a STS

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

Tropos - concepts

ActorGoal

Task

Softgoal

8

Tropos - relations

Dependency

And-decomposition

Or-decomposition

Means-end

Contribution

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: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

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

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

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 Reasoningelicit the possible solutions: strategy to achieve the goals necessary treatments to mitigate the risksfor 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

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

Automating the design

General planning-based schema Exploring alternatives: AI planning techniques Evaluating alternatives: global and local perspectives Designer remains in the loop

Planner Evaluator

Input:actors, goals, and their properties

Output:(sub) optimal design

designalternative

constraints on the input

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

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

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

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

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