Laser 2-change

Development of dynamically evolving and
self-adaptive software
2. Understanding and managing change
LASER 2013
Isola d’Elba, September 2013

Carlo Ghezzi
Politecnico di Milano
Deep-SE Group @ DEIB

1
Tuesday, September 10, 13

The global picture:

the machine and the world (Jackson/Zave)

P, Zave, M. Jackson, Four dark corners of requirements engineering, TOSEM 1997
2

The global picture:

World (the environment)
Machine

2

The global picture:

Machine

Goals
Requirements
2

The global picture:

Machine

Shared
phenomena
Goals
Requirements
2

The global picture:

Machine

Shared
phenomena
Goals
Requirements

Speciﬁcation

2

The global picture:

Machine
Domain
properties,
assumptions

Shared
phenomena
Goals
Requirements

Speciﬁcation

2

Domain properties and assumptions

• Domain property
-

statement about problem world phenomena
often it holds regardless of any software-to-be; e.g.
physics’ laws
avgTrainAcceleration (t1, t2) > 0 implies
trainSpeed (t2) > trainSpeed (t1)

• Assumption
-

statement about problem world phenomena, constraints
may be violated
‣“humans behave as instructed by the machine”
‣“temperature is in the range -40..+40 Celsius”
‣“device generates a measure every 2 ms.”
3


Domain assumptions
May concern
• usage proﬁles
• users’ responsiveness
• remote servers response time
• network latency
• sensors/actuators behaviors
• ...
“Domain assumptions bridge the
gap between requirements and
speciﬁcations”
(M. Jackson & P. Zave)

4

Dependability arguments
• Assume you have a formal representation for
– R = requirements
– S = speciﬁcation
– D = Dp + Da domain properties and assumptions

if S and D are both satisﬁed and consistent, it is
necessary to prove
– S, D |= R

5

Change

• Requirements change
• Environment changes
• Change is often a manifestation of uncertainty
• Change asks for evolution (of the machine)

6

Changes may cause evolution
• Changes are exogenous phenomena
that may concern
- R
- D (actually, Da)
• Changes likely break the dependability argument
• Evolution (of the machine) is a consequence of change
‣ we need to change S (and hence the implementation)
to continue to satisfy the dependability argument

S, D |= R

7

Evolution (1970s) = software maintenance
•
•

Traditionally, changes to software (the machine, S) in response
to changes in D, R are performed manually (by software
engineers) and applied off-line, after delivery
Maintenance (Lientz and Swanson) classified as

-

Corrective maintenance

-

Adaptive maintenance

✓Modification to correct discovered problems.
✓Modification to keep it usable in a changed or changing
environment.

-

Perfective maintenance

-

Preventive maintenance.

✓Modification to improve it functionally/non-functionally.
✓Anticipate any of the above.
Lientz B., Swanson E., Software Maintenance Management. Addison Wesley, 1980
8


Early studies on software evolution
• Software evolution recognized as a crucial problem since the 1970’s (work
by M. Lehman and L. Belady)
• Three categories of software
- S-programs
- written according to an exact speciﬁcation of what the program can do
- P-programs
- written to implement certain procedures that completely determine
what the program can do (e.g., a program to play chess)
- E-programs
- written to perform some real-world activity
- how they should behave is linked to the environment in which they run
- need to adapt to varying requirements and circumstances in that
environment
Lehman, M. , Programs, Life Cycles, and Laws of Software Evolution, Proc. IEEE, 1980
9

Lehman’s “laws” of software evolution (1)
•
•
•
•

Continuing Change — E-type systems must be continually
adapted or they become progressively less satisfactory.
Increasing Complexity — As an E-type system evolves its
complexity increases unless work is done to maintain or
reduce it.
Self Regulation — E-type system evolution process is selfregulating with distribution of product and process
measures close to normal.
Conservation of Organizational Stability (invariant work rate)
— The average effective global activity rate in an evolving Etype system is invariant over product lifetime.

10

Lehman’s “laws” of software evolution (2)
•
•
•
•

Conservation of Familiarity — Over the lifetime of a system,
the incremental change in each release is approximately
constant.
Continuing Growth — The functional content of E-type
systems must be continually increased to maintain user
satisfaction over their lifetime.
Declining Quality — The quality of E-type systems will appear
to be declining unless they are rigorously maintained and
adapted to operational environment changes.
Feedback System — E-type evolution processes constitute
multi-level, multi-loop, multi-agent feedback systems and
must be treated as such to achieve signiﬁcant improvement
over any reasonable base.

11

Software evolution (2000): agility

• Common to all variants:
- Incorporate feedback in an iterative

development that supports progressive
calibration of objectives and adjustment
of requirements

12

Software evolution (late 2010s)

• Run-time evolution
• Self-managing evolution

13

Evolution and adaptation
Adaptation is a special case of evolution due to
changes in domain assumptions, Da
• an increasingly relevant phenomenon, often due to
uncertainty
‣ cyber-physical systems
- interaction with the physical environment
‣ user-intensive systems
- changes in usage proﬁle
‣ cloud/service infrastructure
- platform/software volatility
14

On-line evolution and self-adaptive systems
• More and more often systems are required to be
continuously running
• This asks for on-line evolution, i.e. applying changes to
the machine as the system is running and providing
service
• The special case of self-adaptive systems
- on-line adaptation is self-managed

15

Self-adaptive system (SaS)
• D decomposed into Df and Dc
– Df is the ﬁxed/stable part
– Dc is the changeable part

S, D |= R

• A SaS should
- detect changes to Dc
- modify itself (the machine --- S, and the
implementation) to keep satisfying the dependability
argument, if necessary

16

Paradigm shift
• SaSs ask for a paradigm shift, which involves both
development time (DT) and run time (RT)
• The boundary between DT and RT fades
• Reasoning and reacting capabilities must enrich the RT
environment
- detect change
- reason about the consequences of change
- react to change

17

Models+verification@runtime
• To detect change, we need to monitor the
environment
• The changes must be retrofitted to models of the
machine+environment that support reasoning about the
dependability argument (a learning step)
• The updated models must be verified to check for
violations to the dependability argument
• In case of a violation, a self-adaptation must be
triggered

18

Lifecycle of self-adaptive systems

19

Reqs

19

Reqs

Env
19

Reqs

0

Speciﬁcation

1

E

Speciﬁcation

Env
19

Reqs

0

Speciﬁcation

1

E

Implementation
Speciﬁcation

Env
19

Reqs

0

Speciﬁcation

1

E

Implementation
Development time

Speciﬁcation

Env
19

Reqs

0

Speciﬁcation

1

E

Implementation
Development time

Speciﬁcation

Run time
Env
19

Reqs

0

Speciﬁcation

1

E

Implementation
Development time
Run time

Speciﬁcation
Execution
Env
19


Reqs

0

Speciﬁcation

1

E

Monitoring

Implementation
Development time
Run time

Speciﬁcation
Execution
Env
19


Reqs

0

Speciﬁcation

1

E

Reasoning

Monitoring

Implementation
Development time
Run time

Speciﬁcation
Execution
Env
19


Reqs

0

Speciﬁcation

Implementation
Development time
Run time

1

E

Reasoning

Self-adaptation

Monitoring

Speciﬁcation
Execution
Env
19


Autonomic computing

20

Autonomic computing

co
m ic
no

ting
u
mp

d

20

Zooming in
• I. Epifani, C. Ghezzi, R. Mirandola, G. Tamburrelli, "Model Evolution by Run-Time Parameter
Adaptation”, ICSE 2009
• C. Ghezzi, G. Tamburrelli, "Reasoning on Non Functional Requirements for Integrated Services”,
RE 2009
• I. Epifani, C. Ghezzi, G. Tamburrelli, "Change-Point Detection for Black-Box Services”, FSE 2010
• A. Filieri, C. Ghezzi, G. Tamburrelli, " A formal approach to adaptive software: continuous
assurance of non-functional requirements", Formal Aspects of Computing, 24, 2, March 2012.
21

Problem setting
• Focus on non-functional requirements
– reliability, performance, energy consumption, cost, …

• Quantitatively stated in probabilistic terms
• Dc decomposed into Du , Ds
– Du = usage proﬁle
– Ds = S1 ∧ .... ∧ Sn Si assumption on i-th service
Integrated Service

?
User

Workﬂow
W

?<uses>
Service
S1

<uses>

?

Service
S2

?

<uses>
....

Service
Sn

22

An example
NrmShipping
Login

[normal]
CheckOut

Search

[express]
[proceed]

Buy

ExpShipping

Logout

[buy more]

23

An example
NrmShipping
Login

[normal]
CheckOut

Search

[express]
[proceed]

Buy

ExpShipping

Returning customers
vs
new customers

Logout

[buy more]

23

An example
NrmShipping
Login

[normal]
CheckOut

Search

[express]
[proceed]

Buy

ExpShipping

Returning customers
vs
new customers

Logout

[buy more]

3 probabilistic requirements:
R1: “Probability of success is > 0.8”
R2: “Probability of a ExpShipping failure for a user recognized as

ReturningCustomer < 0.035”
R3: “Probability of an authentication failure is less then < 0.06”
23

Assumptions
User proﬁle domain knowledge
RC
RC
NC
RC
NC

External service assumptions (reliability)

24

DTMC model
Returning

1

Search

Buy

ExpShipping

FailedExpSh

10

13

1
1

4

7

0.5

0.05

1

0.2
0.3

0.35
Login

0

Logged
0.97

FailedLg

2

5

CheckOut

FailedChk
1

8

0.95

Logout

1
0.1

11

14

0.9

Success
0.97

16

1

0.03
0.65

3

0.25

5

0.03

0.95

1

1

6

9

0.6

12

0.05

15

1

0.15

NewCustomer Search

Buy

NrmShipping

FailedNrmSh

25

DTMC model
Returning

1

Search

Buy

ExpShipping

FailedExpSh

10

13

1
1

4

7

0.5

0.05

1

0.2
0.3

0.35
Login

0

Logged
0.97

FailedLg

2

5

CheckOut

FailedChk
1

8

0.95

Logout

1
0.1

11

14

0.9

Success
0.97

16

1

0.03
0.65

3

0.25

5

0.03

0.95

1

1

6

9

0.6

12

0.05

15

1

0.15

NewCustomer Search

Buy

NrmShipping

FailedNrmSh

Property check via model checking
R1: “Probability of success is > 0.8”


25

DTMC model
Returning

1

Search

Buy

ExpShipping

FailedExpSh

10

13

1
1

4

7

0.5

0.05

1

0.2
0.3

0.35
Login

0

Logged
0.97

FailedLg

2

5

CheckOut

FailedChk
1

8

0.95

Logout

1
0.1

11

14

0.9

Success
0.97

16

1

0.03
0.65

3

0.25

5

0.03

0.95

1

1

6

9

0.6

12

0.05

15

1

0.15

NewCustomer Search

Buy

NrmShipping

FailedNrmSh

R1: “Probability of success is > 0.8” 0.84


25

DTMC model
Returning

1

Search

Buy

ExpShipping

FailedExpSh

10

13

1
1

4

7

0.5

0.05

1

0.2
0.3

0.35
Login

0

Logged
0.97

FailedLg

2

5

CheckOut

FailedChk
1

8

0.95

Logout

1
0.1

11

14

0.9

Success
0.97

16

1

0.03
0.65

3

0.25

5

0.03

0.95

1

1

6

9

0.6

12

0.05

15

1

0.15

NewCustomer Search

Buy

NrmShipping

FailedNrmSh

0.031


25

DTMC model
Returning

1

Search

Buy

ExpShipping

FailedExpSh

10

13

1
1

4

7

0.5

0.05

1

0.2
0.3

0.35
Login

0

Logged
0.97

FailedLg

2

5

CheckOut

FailedChk
1

8

0.95

Logout

1
0.1

11

14

0.9

Success
0.97

16

1

0.03
0.65

3

0.25

5

0.03

0.95

1

1

6

9

0.6

12

0.05

15

1

0.15

NewCustomer Search

Buy

NrmShipping

FailedNrmSh

0.031


0.056
25


What happens at run time?
• Actual environment behavior is monitored
• Model updated
• e.g., by using a Bayesian approach to estimate DTMC matrix
(posterior) given run time traces and prior transitions
• Boils down to the following updating rule

26

• Model updated

A-priori Knowledge
26

• Model updated

A-priori Knowledge

A-posteriori Knowledge
26


In our example

27

In our example

R2: “Probability of an ExpShipping failure for a user recognized as

BigSpender < 0.035”
27

In our example
0.633


27

In our example
0.633

Requirement
violated!


27

Model update and failure prediction
• Model checking applied to after each update
• Model checking may predict requirements violations
• ... and trigger self-adaptations before violations manifest
themselves

28

In our example
Returning

1

Search

Buy

ExpShipping

FailedExpSh

10

13

1
1

4

7

0.5

0.05

1

0.2
0.3

0.35
Login

0

Logged
0.97

FailedLg

2

5

CheckOut

FailedChk
1

8

0.95

Logout

1
0.1

11

14

0.9

Success
0.97

16

1

0.03
0.65

3

0.25

0.03

0.95

1

1

6

9

0.6

12

0.05

15

1

0.15

NewCustomer Search

Buy

NrmShipping

FailedNrmSh

29

In our example
Returning

1

Search

Buy

ExpShipping

FailedExpSh

10

13

1
1

4

7

0.5

0.05

1

0.2
0.3

0.35
Login

0

Logged
0.97

FailedLg

2

5

CheckOut

FailedChk
1

8

0.95

Logout

1
0.1

11

14

0.9

Success
0.97

16

1

0.03
0.65

3

0.25

0.03

0.95

1

1

6

9

0.6

12

0.05

15

1

0.15

NewCustomer Search

Buy

NrmShipping

FailedNrmSh



29

In our example
Returning

1

Search

0.067

Buy

ExpShipping

FailedExpSh

10

13

1
1

4

7

0.5

0.05

1

0.2
0.3

0.35
Login

0

Logged
0.97

FailedLg

2

5

CheckOut

FailedChk
1

8

0.95

Logout

1
0.1

11

14

0.9

Success
0.97

16

1

0.03
0.65

3

0.25

0.03

0.95

1

1

6

9

0.6

12

0.05

15

1

0.15

NewCustomer Search

Buy

NrmShipping

FailedNrmSh



29

In our example
Returning

1

Search

0.067

Buy

ExpShipping

FailedExpSh

10

13

1
1

4

7

0.5

0.05

1

0.2
0.3

0.35
Login

0

Logged
0.97

FailedLg

2

5

0.03
0.65

3

CheckOut

FailedChk

1

0.95

Logout

8

0.1

0.25

11

14

0.9

0.97

6

9

0.6

12

16

1

0.03

0.95

1

1

Success

Requirement
violated!
1

0.05

15

1

0.15

NewCustomer Search

Buy

NrmShipping

FailedNrmSh



29

In our example
Returning

1

Search

0.067

Buy

ExpShipping

FailedExpSh

10

13

1
1

4

7

0.5

0.05

1

0.2
0.3

0.35
Login

0

Logged

FailedLg

2

5

0.95

CheckOut

FailedChk

Logout

Success

Requirement
violated!
Even if no returning
customers have been
R2: “Probability of an ExpShippingobserved
failure for a user recognized as

0.97

1

8

1

0.1

11

14

0.9

0.97

16

1

0.03

0.65

3

0.25

0.03

0.95

1

1

6

9

0.6

12

0.05

15

1

0.15

NewCustomer Search

Buy

NrmShipping

FailedNrmSh

29

Another example
Discrete Time Markov Reward Model (D-MRM)
NrmShipping

20
Login

Search

Buy

2

8

16
0.2

0.3

Logout

0.56
CheckOut

6

End

1

0

0.14
50
ExpShipping

Units:

$

60.625
30

Another example
NrmShipping

20
Login

Search

Buy

2

8

16
0.2

0.3

Logout

0.56
CheckOut

6

End

1

0

0.14
50
ExpShipping

What’s the average cost
of a session?

Units:

$

60.625
30

Another example
NrmShipping

20
Login

Search

Buy

2

8

16
0.2

0.3

Logout

0.56
CheckOut

6

End

1

0

0.14
50
ExpShipping

What’s the average cost
of a session?

Units:

$

= 60.625
.
30

Laser 2-change

Recommended

Recommended

More Related Content

Similar to Laser 2-change

Similar to Laser 2-change (20)

Recently uploaded

Recently uploaded (20)

Laser 2-change