1) The document discusses models used in software development including functional requirements, non-functional requirements, labeled transition systems (LTS), discrete-time Markov chains (DTMC), and discrete time Markov reward models. 2) Temporal logics like LTL and CTL are discussed for formally specifying properties of models. PCTL is presented as a probabilistic extension of CTL for specifying properties of DTMCs. 3) Quantitative modeling is covered including using DTMCs and discrete time Markov reward models to model aspects like costs, probabilities, and rewards. Formulas of reward-PCTL are provided for quantitatively evaluating properties.

1. 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
1
Tuesday, September 10, 13

2. 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
Accuracy
Safety Security Reliability Performance Interface
Installation Distribution Cost
Deadline Variability
Cost
ConfidentialityIntegrity Availability Time Space
Maintainability
User
Device
Software
interaction interaction interoperability
Subclass link
Usability Convenience
van Lamsweerde, Requirements Engineering, J. Wiley & Sons 2009
2
Tuesday, September 10, 13

3. 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
3
Tuesday, September 10, 13

4. Why do we use models?
•
To communicate
-
-
•
•
They embody a shared lexicon
Mathematics makes reasoning formal
Through models we can predict properties of the real system
before it exists
✓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
4
Tuesday, September 10, 13

5. What makes a good model?
•
•
A model is good if it carries the right amount of information
you need
-
A model abstracts from details
-
•
•
It is at the right level of abstraction
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!!!
5
Tuesday, September 10, 13

6. 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
6
Tuesday, September 10, 13

7. Models
• Perhaps the most used (and useful) models are finitestate models given as Labelled Transition Systems of
some kind
OFF
0
1
ON
7
Tuesday, September 10, 13

8. Labeled Transition System (Kripke Structure)
x ~p
k p
Transitions
represent execution
steps
y ~p
h ~p
h
State labels represent
predicates true in the state
z ~p
8
Tuesday, September 10, 13

9. 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.
9
Tuesday, September 10, 13

10. 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
N1
→ T1
T1 ∧ S0 → C1 ∧ S1
C1
→ N 1 ∧ S0
||
N2
→ T2
T2 ∧ S0 → C2 ∧ S1
C2
→ N 2 ∧ S0
10
Tuesday, September 10, 13

11. Consider the following model
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
N1N2S0
T1N2S0
N1T2S0
T1T2S0
C1N2S1
C1T2S1
N1C2S1
T1C2S1
11
Tuesday, September 10, 13

12. 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
12
Tuesday, September 10, 13

13. 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)
13
Tuesday, September 10, 13

14. 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
14
Tuesday, September 10, 13

15. Mutual exclusion
Always at least one process is not in the critical section
N1N2S0
T1N2S0
N1T2S0
T1T2S0
C1N2S1
C1T2S1
(not C1
N1C2S1
T1C2S1
not C2)
15
Tuesday, September 10, 13

16. 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
16
Tuesday, September 10, 13

17. 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
17
Tuesday, September 10, 13

18. 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
•
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
P: S×S→[0;1] is a stochastic matrix
AP is a set of atomic propositions
L: S→2AP is a labelling function.
18
Tuesday, September 10, 13

19. An#example#
!A simple communication protocol operating with a channel!
start
S
D
T
L
1
1
delivered
0.9
0.1
try
lost
S
0
1
0
0
D
0
0
0.9
0
T
1
0
0
1
L
0
0
0.1
0
matrix representation
1
Note: sum of probabilities for transitions leaving a given state equals 1
C. Baier, JP Katoen, “Principles of model checking” MIT Press, 2008
19
Tuesday, September 10, 13

20. 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
20
Tuesday, September 10, 13

21. 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...
21
Tuesday, September 10, 13

22. 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
22
Tuesday, September 10, 13

23. 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
23
Tuesday, September 10, 13

24. 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
::=
::=
•
|
|
|
|
|¬
|P
An example of a reachability property
- P>0.8 [◊(system state = success)]
( )
1
absorbing state
24
Tuesday, September 10, 13

25. R-PCTL
•
Reward-Probabilistic CTL for R-DTMC
|
::=
|
::=
::=
R (
=
)
=
|
|
|
|¬
|P
( ) |R
( )
|
R (
)
R (
)
25
Tuesday, September 10, 13

26. Example
R (
=
)
Expected state reward to be gained in the state entered at step k
along the paths originating in the given state
“The expected cost gained after exactly 10 time steps is
less than 5”
R< (
=
)
26
Tuesday, September 10, 13

27. Example
R (
)
T Expected cumulated reward within k time steps ext
Text
“The expected energy consumption within the first 50 time units of
operation is less than 6 kwh”
R< (
)
27
Tuesday, September 10, 13

28. Example
R (
)
Expected cumulated reward until a state satisfying is reached
Text
Text
“The average execution time until a user session is complete is
lower than 150 s”
R<
(
)
28
Tuesday, September 10, 13

29. A bit of theory
• Probability for a finite path ⇡ = s0 , s1 , s2 , . . . to be
Q|⇡| 2
traversed is 1 if |⇡| = 1 otherwise
k=0 P (sk , sk+1 )
• A state sj is reachable from state si if a finite path exists
leading to sj from si
• The probability of moving from si to sj in exactly 2 steps
P
pix · pxj which is the entry (i, j) of P 2
is sx 2S
• The probability of moving from si to sj in exactly k steps
is the entry (i, j) of P k
29
Tuesday, September 10, 13

30. 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 sk where pk,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
30
Tuesday, September 10, 13

31. An example
0.5
1
2
1
0
0.2
0.3
3
0
0 1
B 0.2 0
B
@ 0 0
0 0
0
0.5
1
0
1
0
0.3 C
C
0 A
1
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.22+0.23+ ... ) x 0.5 = ( ∑ 0.2n) 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
31
Tuesday, September 10, 13

32. A bit of theory
• Consider a DTMC with r absorbing and t transient states
• Its matrix can be restructured as
✓
◆
Q R
P =
(1)
0 I
- 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
Qk ! 0 as k ! 1
• Theorem
- In a well-formed Markov chain, the probability of the process
to be eventually absorbed is 1
32
Tuesday, September 10, 13

33. Focus on reachability properties
• A reachability property has the following form
P./p (⌃ )
states that the probability of reaching a state where
holds matches the constraint ./ p
• Typically, they refer to reaching an absorbing state
(denoting success/failure for reliability analysis)
• It is a flat formula (i.e. no subformula contains P./p (·))
• These properties are the most commonly found
33
Tuesday, September 10, 13

34. A bit of theory
Consider again ◆
✓
Q R
P =
0 I
1
X
1
2
3
k
N = I + Q + Q + Q + ··· =
Q
(1)
k=0
ni,k expected # of visits of transient state sk from si, i.e.,
the sum of the probablities of visiting it 0, 1, 2, ...times
1
Theorem: The geometric series converges to (I Q)
Consider B = N ⇥ R . The probability of reaching
X
absorbing state sk from si is bik =
nij · rjk
k=0..t 1
34
Tuesday, September 10, 13

35. Proving reachability properties
Pr(◊ s = End ) =
∑n
0, j
⋅ rj , End
j
n0,j is the sum of the probabilities to reach state j
in 1, 2, 3, ... ∞ steps
35
Tuesday, September 10, 13

36. 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
36
Tuesday, September 10, 13

37. 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
37
Tuesday, September 10, 13