D - Lucretius: Foundations for Software Evolution

Complementing goal models
for adaptive systems
João Pimentel
{ [email protected]}
REQUIREMENTS ENGINEERING LAB
João Pimentel


3rd year Ph.D – UFPE/Brazil
In trento for 1 year


From September 2012
www.cin.ufpe.br/~jhcp
MsC and PhD with Jaelson
10-months
2010-2011
12-months
2012-2013
Agenda




Adaptation metrics
Futurology
Failure policy
From req to arch
4
I.
ADAPTATION
1
METRICS
Comparing different alternatives
Inform the TV
movies schedule
Movies
For Me
Discover the TV
movies schedule
Discover the movies
of Channel A
Display the TV
movies schedule
Discover the movies
of Channel B
List movies on
website
Inform the TV
Parse Channel
movies schedule
A website
Movies
For Me
Discover the movies
of Channel A
Group movies by
day
Display
themovies
TV
Get
movies description
schedule
Discover the TV
movies schedule
Discover the movies
of Channel B
Group movies by
channel
Parse Channel
B website
Get movies date
and time
List movies on
Get
movies
website
picture
Parse Channel
A website
Group movies by
day
Get movies
description
Get movies date
and time
Group movies by
channel
Parse Channel
B website
Get movies
picture
models
components
Criteria:
Reusability, reliability, performance,
maintainability...
decisions
adaptability,
6
how to measure
adaptability?
7
We build on previous work by Submaranian & Chung:
Architecture Adaptability Index (AAI) =
Sum of the Adaptability Index (EAI) of all
architectural elements
Total number of elements of the architecture model
8
…and…
Software Adaptability Index (SAI) =
Sum of the AAI of all architecture models
of the software
Total number of architecture models for that
software
9
But the problem remains: how to define
the adaptability index (EAI) of a
particular element?
10
We propose to
map the metrics to i* (iStar) models
and
use its richer expressiveness to
define EAI
In order to perform the mapping of architectural metrics onto
i*, we use the
i* Metrics Definition Framework method
iMDFM
12
i* Metrics Definition Framework
iMDF
Catalog of
patterns
i* metrics in OCL
Method
13
Catalog of
patterns
i* metrics in OCL
Method
Modeling tool
14
i* Metrics Formulation
Based on the original metrics, the architecture  i* mapping and the iMDF
catalogue of patterns:
Architecture Adaptability Index (AAI) =
AAI ::= self.allActors().eai()->sum()+self.allDependencies().eai()->sum() /
self.allActors()->size() + self.allDependencies()->size()
Software Adaptability Index (SAI) =
SAI ::= allModels().aai()->sum() / allModels()->size()
15
EAI of individual components (SR)
The SR decomposition may help:
Compon
ent A
Compon
ent B
Goal 1
Compon
ent C
Adaptability
M
ak
e
Task 3
Task 1
Task 2
Means-end decomposition
Adaptability
Task 4
Contribution to softgoal
Softgoal-to-task decomposition
16
EAI of individual components: (SD)
Dependencies may identify adaptability too:
(a)
Compon
ent A
Depender
(b)
Goal
dependum
D
D
Compon
ent B
(Soft)goal dependum
Compon
ent C
Dependee
Compon
ent D
Goal 2
D
Task 1
Task 2
Task 3
Resource
Dependum
D
(Soft)goal dependers
17
EAI of individual components (extensions)
Approach
Base
notation
Extension towards
adaptability
Architecture
Lapouchnian
Tropos
Context annotations
Not defined
Ali
Tropos
Context annotations
Not defined
Dalpiaz
Tropos
Context annotations
Recovery activities
Self-reconfiguring
component
Morandini
Tropos
Context annotations
Recovery activities
Fault modeling
Multi-agent
Jian
i*
Context annotations
Runtime adaptation
Not defined
Qureshi
Techne
Runtime adaptation
Service-based
Bencomo
KAOS
Runtime adaptation
Flexibility language
Not defined
Baresi
KAOS
Recovery activities
Service-based
II.
ANTICIPATING
CHANGES WITH
2,3
FUTUROLOGY
Motivation
Adaptation and evolution is great
20
Motivation
However, it is very hard to develop systems that

Adapt to any scenario

Evolve in any way
21
Motivation
If we could see the future...
(sort of)
22
Reduce the gap
Studies of the
Future
Requirements
Engineering
23
Reduce the gap
Studies of the
Future
Requirements
Engineering
24
Definitions



Future event: a future event is an occurrence
that is expected to take place in the future.
Representation of the future: a representation
of the future is a model that describes a set of
future events.
Foresight method: a foresight method is a
means of creating a representation of the future.
25
Classification of foresight methods
Category
Collect judgments from
Experts
Forecast time series and other
quantitative measures
Understand the linkages
between events, trends and
actions
Portray alternative plausible
futures
Method
Delphi
Futures Wheel
Participatory methods
Econometrics forecast
Regression Analysis
Trend Impact Analysis
Structural Analysis
System Dynamics
Agent Modeling
Trend Impact Analysis
Cross Impact Analysis
Relevance Trees
Futures Wheel
Simulation Modeling
Multiple perspectives
Causal Layered Analysis
Field Anomaly Relaxation
Scenarios
Futures Wheel
Simulation and Gaming
Agent Modeling
26
Our proposal

Futures wheel




Provides a clear picture of the future events that
may impact the system;
Easy to be understood and used by stakeholders
Low effort required
i*


Widespread goal modeling language
Provides a suitable mechanism to represent
alternative behaviors of a system
27
Futures wheel
B
X
A
C
Event or trend
Primary
consequences
Y
Secondary
consequences
28
Futures wheel extension
P
B
X
Q
A
C
Y
Z
W
S
29
Integrating futures wheel and goal models

Build extended futures wheel models



Build futures wheel model
For each consequence, analyze how it affects the
system
Adapt goal model


For each direct consequence in the futures wheel
model, analyze how the system can be altered in
order to deal with the consequence
Change the goal model accordingly
30
Process
Futures Wheel
Document Template
(organizational)
Futures Wheel
Document
Template
(project)
Plan Futures
Wheel
Futures Wheel
Document
Perform
Futures Wheel
Futures Wheel
Document
(Updated)
Futures Wheel
Document (Updated)
Define Direct
Consequences
Analyze Direct
Consequences
Futures Wheel
Plan Template
Futures Wheel
Plan
Requirements
Document
31
Case study – original goal model
Inform the TV
movies schedule
Movies
For Me
Display the TV
movies schedule
Discover the TV
movies schedule
Discover the movies
of Channel A
Discover the movies
of Channel B
List movies on
website
Parse Channel
A website
Group movies by
day
Get movies
description
Get movies date
and time
Group movies by
channel
Parse Channel
B website
Get movies
picture
Goal
Task
Actor
Meansends link
Decomposition
link
Legend
32
Case study – futures wheel
More TV
channels
available
Successful
adoption of
Digital
Terrestrial TV
EPG
broadcast
High
Definition
People more
likely to watch
movies on TV
TV
available
in mobile
devices
The system will
need to gather
data from
channels that
don’t exist yet
More people will try
to see the movies
schedule through
mobile devices
People will have
easy access to
information about
the TV schedule
People will
search more for
services that
inform the TV
movies schedule
33
Case study – modified goal model
Inform the TV
movies schedule
Movies
For Me
me
Display the TV
movies schedule
(B)
So m e
+
+
Use sponsored
links
Hu
Use good
keywords
Discover the movies
of Channel A
rt
List movies on
website
Discover the movies
of Channel B
Parse Channel
A website
So
Discover the TV
movies schedule
Be searchengine friendly
Low cost
Portability
Add support for a
new channel
Some +
(A)(F)
Get movies
description
Parse Channel
B website
Get movies date
and time
Get movies
picture
Website for
desktops and
notebooks
Group movies by
channel
So
(C)
me
+
Website for
television devices
Website for
mobile devices
Group movies
by day
Get teaser /
trailer
(E)
label
Goal
Task
Softgoal
Actor
Meansends link
Decomposition
link
Contribution
link
Legend
34
III.
FAILURE POLICY –
THE FAST
4,5
APPROACH
MDC Cycle
Monitor
Compensate
Diagnose
36
MDC Cycle
Monitor
Compensate
Diagnose
failure
37
Different faults, different reactions
“Some faults lead to the unusability of a device or
even to catastrophes; some faults can be ignored
or are actually never discovered.”
Bernhard Rinner - Detecting and Diagnosing Faults (2002)
38
39
A failure is...
... the unsuccessfull execution of ...
a task
a service operation
a method
a use case
a goal
...
40
FAST

This framework allows the user to define
conditions on which failures may be ignored


i.e., it won’t trigger a compensation
The conditions are based on the context and on
the number of failures occurrence
41
Policies

Unlike requirements, which are



Somewhat static
Defined at design time
This failure handling specification is


User / installation dependent
Defined at deployment time
42
Failure policy


Context-based

failuresSet isAllowedToFailIf contextExpression

Ex: failureX isAllowedToFailIf
calendar.day=Sunday
Limit of consecutive failures


failuresSet isAllowedToFailAtMost limit
Ex: failureX: failureY isAllowedToFailAtMost 4
43
Fabiano’s component
44
IV.
FROM REQ TO ARCH
(ADAPTIVE
6
SYSTEMS)
STREAM-A (Adaptive)
STREAM
Dalpiaz’
selfadaptation
component
Ali’s
contextual
reasoning
46
STREAM

An approach based on model transformations
that generates architectural models from
requirements models


Source language: i*
Target language: Acme
47
D
D
D
D
D
D
D
D
D
D
D
Modular
Requirements
Models
D
Requirements
Models
Prepare
Requirements
Models
Refined
Architectural
Solution
Select
Architectural
Solution
Generate
Architectural
Solutions
Architectural
Models
Refine
Architecture
Architectural
Solution
Legend:
Work Definition
Decision
Control Flow
Artifact Flow
Start
End
D
D
D
D
D
D
Requirements
Model
Document
Architecture
Model
Guidance
48
BTW: system-to-be
49
50
51
52
Architectural style
53
But what about adaptation?
54
Fabiano’s component (again)
55
STREAM-Adaptive
Original
goal model
Requirements
Refactoring
Modular
goal model
Context
Annotation and
Analysis
Annotated
goal model
Identification of
Sensors and
Actuators
Goal model with adaptiverelated actors
Generate
Architectural
Model
Architectural
model
Refine
Architectural
Model
Architectural model with
sub-components
Include the SelfAdaptation
Component
Final
architectural
model
56
C6: The temperature at the room is
hotter than what would be pleasant for
the people within it, the temperature
outside is colder than the temperature
inside the smart-home and the
windows are closed.
Adaptabil
ity
He
lp
lp
He
He
Hurt
Control
windows
C6
lp
Energy
spent wisely
He
Smart
home
system
Reliability
C1
Temperature
be managed
Control air
ventilator
lp
Hu
Help
Prevent
failures
Hel
p
Control
Heating Device
rt
C22
He
lp
Select best
behaviour according
to the environment
C9
C10 C22
Lighting be
C11
Turn
off
air
managed
Close
Turn on air
Turn on
ventilator
Turn off
windows
ventilator
heating device
Manage
heating device
He
Control
lighting
lp
Safety
s valves
Manage fire
C4
Select
Occupancy
incident
C15
lighting policy
Help
Control
simulation
Close gas
lights
14
Control
Lighting
by
valves
C12
Control
alarm
gas
occupancy
Turn on
doors lock
C13
Control power
es
C20
lights
C21
C16 C17
outlets
Activate
Turn off
Deactivate
C18
alarm
lights
C19
Lock
Entertain
Unlock
alarm
doors
C7
C8
Help
Open
windows
Hel
p
57
Play music
Turn on
lights
D
Environment
monitored
D
D
D D D
D
Direct sound
only to occupied
rooms
Customiz
ation
D
D
Turn off
lights
D
Turn on
heating device
D
Preferen
ce
manager
D
Communi
cation
D
D
D
D
Get musical
preferences
Turn off
heating device
D
D
D
Notify fire
department
D
Get
preferences
Notify
tenants
D
Store food
consumption data
Get food
stock status
Get food
stock status
D
D
D
D
D
Lock
doors
D
D
Unlock
doors
D
Activate
power outlets
Invite friend
Request
restaurant meal
D
D
Deactivate
power outlets
D
D
Open
windows
D D D D D D D
Close
windows
Fast
response
D
Open gas
valves
D
D
Close gas
valves
D
D
D
D
D
D
D
Turn off air
ventilator
Smart
home
system
D
Turn on air
ventilator
D
Actuator
D
D
D
D D D D D D D
Monitor
Store medicine
consumption data
Data
storage
request meal
from restaurant
get food
stock status
get food
stock status
Data storage
get
preferences
invite
friend
Communication
fast
response
store food
consumption data
Smart home
system
store medicine
consumption data
notify fire
department
notify
tenants
get musical
preferences
environment
monitored
Preference
manager
customization
actuations
Monitor
Indoor air
temperature
sensor
Actuator
Internet
connection
verifier
Magnetic door
locks sensor
RFID stock
supply detector
Ionization-based
smoke sensor
Magnetic
windows sensor
Passive infrared
presence detector
Photosensor
Semiconductor
gas leak detector
Clock
Windows
actuator
Lights
actuator
Alarm
actuator
Heating
actuator
Music
actuator
Air ventilator
actuator
Gas valves
actuator
Power outlets
actuator
Doors
actuator
59
request meal
from restaurant
get food
stock status
get food
stock status
Data storage
Smart home
system
system
pushes
Communication
notify fire
department
Self-adaptation
actuations
Actuator
Windows
actuator
Diagnoser
environment
monitored
actuations
Compensator
Monitor
Preference
manager
customization
Monitor
Indoor air
temperature
sensor
notify
tenants
get musical
preferences
log
environment
monitored
invite
friend
fast
response
store food
consumption data
store medicine
consumption data
get
preferences
Lights
actuator
Alarm
actuator
Heating
actuator
Music
actuator
Air ventilator
actuator
Gas valves
actuator
Power outlets
actuator
Doors
actuator
Internet
connection
verifier
MDC cycle


Magnetic door
locks sensor
RFID stock
supply detector
Ionization-based
smoke sensor
Magnetic
windows sensor
Passive infrared
presence detector
Photosensor
Provided port
Clock
Required port
Semiconductor
gas leak detector


Monitor
Diagnose
Compesate
60
Thanks!
References
1.
2.
3.
4.
5.
6.
Pimentel, J., Franch, X., Castro, J. Measuring Architectural Adaptability in i* Models.
CIbSE 2011
Pimentel, J., Santos, E. Castro, J., Franch, X. Anticipating Requirements Changes - Using
Futurology in Requirements Elicitation. International Journal of Information System
Modeling and Design
Pimentel, J., Castro, J., Perrelli, H., Santos, E., Franch, X. Towards Anticipating
Requirements Changes through Studies of the Future. RCIS 2011
Pimentel, J., Castro, J., Franch, X. Specification of Failure-Handling Requirements as
Policy Rules on Self-Adaptive Systems. WER 2011
Pimentel, J., Santos, E., Castro, J. Conditions for ignoring failures based on a
requirements model. SEKE 2010
Pimentel, J., Lucena, M, Castro, J., Silva, C., Alencar, F., Santos, E.Deriving Adaptable
Software Architectures from Requirements Models: The STREAM-A approach.
Requirements Engineering Journal