Development of dynamically evolving and self-adaptive software. 1. Background

Development of dynamically evolving and self-adaptive software

1. Background

LASER 2013

Isola d’Elba, September 2013

Carlo Ghezzi Politecnico di Milano Deep-SE Group @ DEIB

Requirements

• Functional requirements refer to services that the system shall provide

• Non-functional requirements constrain how such services shall be provided

Non-Functional Requirement

Quality of Service Compliance Architectural Constraint Development Constraint

ConfidentialityIntegrityAvailability

Distribution Installation

Safety Security ReliabilityPerformance Cost Maintainability

Time Space

DeadlineVariability Software

interoperability Interface

User interaction

Device interaction Subclass link

Accuracy

Cost

Models

• During software development, software engineers

often build abstractions of the system in the form of models

•  [noun]

A system or thing used as an example to follow or imitate

•  a simplified description, esp. a

mathematical one, of a system or process, to assist calculations or predictions

Oxford American Dictionaries

Why do we use models?

•

To communicate

-

They embody a shared lexicon

✓E.g., state, transition

•

To simplify descriptions and help focus, ignoring details that distract from the essence of the problem

•

To reason about the modeled system

-

Mathematics makes reasoning formal

-

Through models we can predict properties of the real system before it exists

What makes a good model?

•

A model is good if it carries the right amount of information you need

-

It is at the right level of abstraction

•

A model abstracts from details

-

Make sure that they are details, not the essence

-

Be aware of the approximations

•

A model serves a purpose

-

Different models for different purposes (views)

•

Expert judgment always needed!!!

From model(s) to implementation

•

Model driven development tries to support a development process that goes through correctness-preserving

transformations

•

Ideally, once correct models are developed, implementation is correct by construction

•

Reality still far from the ideal world....

•

However, focus on models and verification important to achieve better quality products

Models

• Perhaps the most used (and useful) models are finite- state models given as Labelled Transition Systems of some kind

0 1

OFF ON

Labeled Transition System (Kripke Structure)

x

y

z

k

~p

~p

~p

p

h h ~p State labels represent

predicates true in the state Transitions

represent execution steps

Definition

•

An LTS is a tuple ⟨S, I, R, AP, L⟩ where

-

S is a set of states;

-

I ⊆ S is the set of initial states;

-

R ⊆ S×S is the set of transitions;

-

AP is a set of atomic propositions;

-

^{L : S → 2AP} is a labelling function.

A (maximal) path from a state s0 is either a finite sequence of states that ends in a terminal state or an infinite sequence of states

-

^{π = s0, s1, s2,...}

such that (si, si+1) ∈ R, for all i ≥ 0.

An example

•

Two process mutual exclusion with shared semaphore

•

Each process has three states

-

Non-critical (N)

-

Trying (T)

-

Critical (C)

•

Semaphore can be available (S0) or taken (S1)

•

Initially both processes are in N and the semaphore is available --- N1 N2 S0

N₁ → T₁

T₁ ∧ S₀ → C₁ ∧ S₁ C₁ → N₁ ∧ S₀

N₂ → T₂

T₂ ∧ S₀ → C₂ ∧ S₁ C₂ → N₂ ∧ S₀

||

Consider the following model

N₁N₂S₀

C₁N₂S₁ T₁T₂S₀

N₁T₂S₀ T₁N₂S₀

N₁C₂S₁

T₁C₂S₁ C₁T₂S₁

Does a system behaving like this LTS satisfy our expectations in terms of mutual exclusion:

Never a state where both C1 and C2 hold can be reached

How can requirements be specified?

•

For example, we need to formalize statements like:

-

No matter where you are, there is always a way to get to the initial state

•

Temporal logic to formally express properties

-

In classical logic, formulae are evaluated within a single fixed world

✓For example, a proposition such as “it is raining” must be either true or false

✓Propositions are then combined using operators such as ∧, ¬, etc.

-

In temporal logic, evaluation takes place within a set of “worlds”, corresponding to time instants

✓“it is raining” may be satisfied in some worlds, but not in others

-

The set of worlds correspond to moments in time

Temporal logic

•

Linear Time

-

Every moment has a unique successor

-

Infinite sequences (words)

-

Linear Time Temporal Logic (LTL)

•

Branching Time

-

Every moment has several successors

-

Infinite tree

-

Computation Tree Logic (CTL)

LTL: syntax and semantics

φ ::= true | a | φ1 ∧ φ2 | ¬φ | oφ | φ1 U φ2

oφ also written Xφ

true U φ also written Fφ and also ◊♢φ

¬^F¬φ also written Gφ and also

o

^φ

An LTL property stands for a property of a path

For a state s, a formula ^φ is satisfied if all paths exiting s satisfy the formula

Model checking

Given an LTS and a formula, verify that initial states satisfy it

Mutual exclusion

N₁N₂S₀

C₁N₂S₁ T₁T₂S₀

N₁T₂S₀ T₁N₂S₀

N₁C₂S₁

T₁C₂S₁ C₁T₂S₁

(not C1 not C2)

Always at least one process is not in the critical section

CTL

•

State formulae:

ϕ ::= true | a | ϕ1 ∧ ϕ2 | ¬ϕ |

∃

^{φ | ∀φ}

•

Path formulae:

φ ::= o ϕ | ϕ1 U ϕ2

X (

o),

F (♢) and G (

o

) can be introduced as for LTL

∃,

∀ often also written as E, A

Mutual exclusion in CTL: ∀G(¬C1 ∨ ¬C2)

Note: CTL and LTL have incomparable expressiveness

Quantitative modelling

•

LTSs support qualitative modelling

•

Often we need to model quantitative aspects, such as the cost of a certain action or the probability that a certain event

occurs

•

Here we review Markov models, an important and useful extension of LTSs

Discrete-time Markov Chains

A DTMC is defioned by a tuple (S, s0, P, AP, L) where

•

S is a finite set of states

•

^s0 ∈ S is the initial state

•

P: S×S→[0;1] is a stochastic matrix

•

AP is a set of atomic propositions

•

^{L: S→2AP} is a labelling function.

•

The modelled process must satisfy the Markov property, i.e., the

probability distribution of future states does not depend on past states; the process is memoryless

An#example#

!A simple communication protocol operating with a channel!

delivered try lost

start

1

0.9

1

1 0.1

S D T L S 0 0 1 0 D 1 0 0 0 T 0 0.9 0 0.1 L 0 0 1 0

matrix representation

Note: sum of probabilities for transitions leaving a given state equals 1

Discrete Time Markov Reward Models

•

Like a DTMC, plus

-

labelling states with a state reward

-

labelling transitions with a transition reward (we just use state rewards)

•

Rewards can be any real-valued, additive, non negative measure; we use non-negative real functions

Usage in modelling:

rewards represent energy consumption, average execution time, outsourcing costs, pay per use cost, CPU time

Reward DTMC

•

A R-DTMC is a tuple (S, s0, P, AP, L, µ), where S, s0, P, L are defined as for a DTMC, while µ is defined as follows:

-

^{µ : S→R≥0} is a state reward function assigning a non-negative real number to each state

✓... at step 0 the system enters the initial state s0. At step 1, the system gains the reward µ(s0) associated with the state and moves to a new state...

Which model(s) should we use?

• Different models provide different viewpoints from which a system can be analyzed

• Focus on non-functional properties leads to models where we can deal with uncertainty and specify quantitative

aspects

• Examples

– DTMCs for reliability

– CTMCs for performance

– Reward DTMCs for energy/cost/performance

Quantitative requirements specification

•

Specification can be qualitative (“the system shall do ...”) or

quantitative (“average response time shall be less than xxx”)

•

LTL, CTL temporal logic are typical examples of qualitative specification languages

•

Non-functional requirements ask for quantitative specification

•

Quantitative specs then require quantitative verification

PCTL

•

Probabilistic extension of CTL

•

In a state, instead of existential and universal quantifiers over paths we can predicate on the probability for the set of

paths (leaving the state) that satisfy property

•

In addition, path formulas also include step-bounded until

•

ϕ1 U≤k ϕ2

•

An example of a reachability property

-

^P>0.8 [◊(system state = success)]

::= | | | ¬ | P ( )

::= | |

absorbing state

1

R-PCTL

•

Reward-Probabilistic CTL for R-DTMC

::= | | | ¬ | P ( )

::= | |

| R ( )

::=

⁼

| |

R (

⁼

) R ( ) R ( )

Example

“The expected cost gained after exactly 10 time steps is less than 5”

R

^<

(

⁼

)

R (

⁼

)

Expected state reward to be gained in the state entered at step k along the paths originating in the given state

Example

R ( )

T

Expected cumulated reward within k time steps

_ext

“The expected energy consumption within the first 50 time units of

Text

operation is less than 6 kwh”

R

^<

( )

Example R ( )

Text

Expected cumulated reward until a state satisfying is reached

“The average execution time until a user session is complete is

Text

lower than 150 s”

R

^<

( )

A bit of theory

• Probability for a finite path to be traversed is 1 if otherwise

• A state s

j

is reachable from state s

i

if a finite path exists leading to s

j

from s

i

• The probability of moving from s

i

to s

j

in exactly 2 steps is which is the entry of

• The probability of moving from s

i

to s

j

in exactly k steps is the entry of

Q

_{|⇡| 2}

k=0

P (s

_k

, s

_k+1

)

|⇡| = 1

⇡ = s

₀

, s

₁

, s

₂

, . . .

P

s_x2S

p

_ix

· p

^xj

(i, j) P

²

(i, j) P

^k

A bit of theory

• A state is recurrent if the probability that it will be eventually visited again after being reached is 1; it is otherwise transient (a non-zero probability that it will never be visited again)

• A recurrent state s

k

where p

k,k

= 1 is called absorbing

• Here we assume DTMCs to be well-formed, i.e.

- every recurrent state is absorbing

- all states are reachable from initial state

- from every transient state it is possible to reach an

absorbing state

An example ₀

B B

@

0 1 0 0

0.2 0 0.5 0.3

0 0 1 0

0 0 0 1

1 C C A

0 1

2

3 1

0.2

0.5

0.3

Probability of reaching an absorbing state (e.g., 2)

2 can be reached by reaching 1 in 0, 1, 2,...∞ steps and then 2 with prob .5 (1+0.2+0.2²+0.2³+ ... ) x 0.5 = ( ∑ 0.2ⁿ) x 0.5 = (1/(1-0.2)) x 0.5 = 0.625 Similarly, for state 3, (1/(1-0.2)) x 0.3 = 0.375

Notice that an absorbing state is reached with prob 1

A bit of theory

• Consider a DTMC with r absorbing and t transient states

• Its matrix can be restructured as

- Q is a nonzero t × t matrix - R is a t × r matrix

- 0 is a r × t matrix

- I is a r × r identity matrix

• Theorem

- In a well-formed Markov chain, the probability of the process to be eventually absorbed is 1

P =

✓ Q R 0 I

◆

(1)

Q

^k

! 0 as k ! 1

Focus on reachability properties

• A reachability property has the following form

states that the probability of reaching a state where holds matches the constraint

• Typically, they refer to reaching an absorbing state (denoting success/failure for reliability analysis)

• It is a flat formula (i.e. no subformula contains )

• These properties are the most commonly found

P

^./p

( ⌃ )

./ p

P

^./p

( ·)

A bit of theory

Consider again

n

i,k

expected # of visits of transient state s

k

from s

i

, i.e., the sum of the probablities of visiting it 0, 1, 2, ...times

Theorem: The geometric series converges to

Consider . The probability of reaching absorbing state s

k

from s

i

is

P =

✓ Q R 0 I

◆

(1) N = I + Q

¹

+ Q

²

+ Q

³

+ · · · =

X

1

k=0

Q

^k

(I Q)

¹

B = N ⇥ R

b

_ik

= X

k=0..t 1

n

_ij

· r

^jk

Proving reachability properties

)

Pr( ◊ s = End ⁼ ∑ ^⋅

j

End j

j

r n

_{0, ,}

n

0,j

is the sum of the probabilities to reach state j

Model checking tools

•

SPIN (Holzmann) analyzes LTL properties for LTSs expressed in Promela

•

(Nu)SMV (Clarke et al, Cimatti et al.) can also analyze CTL properties and uses a symbolic representation of visited states (BDDs) to address the “state explosion problem”

•

PRISM (Kwiatkowska et al.) and MRMC (Katoen et al.) support Markov models and perform probabilistic model checking

Question

• How do modelling notations and verification fit software evolution?

- A modification to an existing system viewed as a new system

- No support to reasoning on the changes

and their effects