toronto_2008 - WordPress.com

internalchildlikeInternet and Web Development

Nov 12, 2013 (3 years and 11 months ago)

122 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


Key challenges


Towards goal
-
based self
-
reconfiguration


Required subsystems


BDI and Jason


Towards self
-
reconfiguration in Jason

F. Dalpiaz

2

Autonomic Computing

F. Dalpiaz

3

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

4

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

5

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

6

Software Engineering and
Autonomic Computing

F. Dalpiaz

7

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 at

EASe

and
SEAMS
@ICSE workshops


Why not using a goal
-
driven approach?

F. Dalpiaz

8

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

9

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

10

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

11

Towards goal
-
based self
-
reconfiguration

F. Dalpiaz

12

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

13

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

14

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

15

The MAPE cycle in Jason

F. Dalpiaz

16


Jason Reasoning Cycle


an extension of the BDI
loop


carried out by each agent


Monitor

1.
Perceive the environment


Detect what changed in the environment

2.
Update the belief base


Decide which changes become beliefs


By default, all changes are recorded as beliefs

3.
Receive communication from other agents


Agents check the mailbox, one message for each
cycle

The MAPE cycle in Jason

F. Dalpiaz

17


Analyze

4.
Select “socially acceptable” messages


Enables the filtering of unwanted messages

5.
Select an event


Each cycle requires the selection of only one event

6.
Retrieve all relevant plans


The plan library is searched for plans to handle the
event

7.
Determine all applicable plans


Verify whether the precondition holds


This step filters the relevant plans


The MAPE cycle in Jason

F. Dalpiaz

18


Plan

8.
Select one applicable plan


Meta
-
reasoning can be applied to select the plan

9.
Select an Intention


Among the several concurrent intentions, choose one
for the current reasoning cycle


Execute

10.
Execute one step of the intention


One action is performed

Customization in Jason


F. Dalpiaz

19

Monitor
:

Perceive the environment (
perceive
)

Belief Update Function (
BUF
)

Check incoming messages (
checkMail
)

Analyze
:

Determine socially acceptable messages (
SocAcc
)

Belief Revision Function (
BRF
)

Select event (
S
E
)

Select plan among the applicable ones (
S
O
)

Plan
:

Select intention (
S
I
)

Execute:

Perform an action (
act
)

Send a message (
sendMsg
)

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)).


F. Dalpiaz

20

Plan

Precondition

Test goal

Achievement

goal

Plan body

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

21

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

22

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

23

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

24

Selecting the best alternative (1)

Plan node

F. Dalpiaz

25

Selecting the best alternative (2)

Xor
-
decomposition

F. Dalpiaz

26

Selecting the best alternative (3)

And
-
decomposition

F. Dalpiaz

27

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

28

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

29

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

30

References (3)


[Ali08] Ali, R., Dalpiaz, F., Giorgini, P.:
L
ocation
-
based Variability
for Mobile Information Systems.
To appear in CAiSE’08.


[Mor08]
Morandini, M., Penserini, L., Perini, A.:
T
owards Goal
-
Oriented Development of Self
-
Adaptive Systems
. To appear in
SEAMS’08 workshop @ICSE.

F. Dalpiaz

31