Lecture 9: Live Sequence Charts 2017-06-19 Prof. Dr. Andreas - - PowerPoint PPT Presentation

– 9 – 2017-06-19 – main –

Softwaretechnik / Software-Engineering

Lecture 9: Live Sequence Charts

2017-06-19

• Prof. Dr. Andreas Podelski, Dr. Bernd Westphal

Albert-Ludwigs-Universität Freiburg, Germany

Topic Area Requirements Engineering: Content

– 9 – 2017-06-19 – Sblockcontent –

2/54

• Introduction
• Requirements Specification
• Desired Properties
• Kinds of Requirements
• Analysis Techniques
• Documents
• Dictionary, Specification
• Specification Languages
• Natural Language
• Decision Tables
• Syntax, Semantics
• Completeness, Consistency, ...
• Scenarios
• User Stories, Use Cases
• Live Sequence Charts
• Syntax, Semantics
• Working Definition: Software
• Discussion

VL 6 . . . VL 7 . . . VL 8 . . . VL 9 . . .

– 9 – 2017-06-19 – main –

3/54

Content

– 9 – 2017-06-19 – Scontent –

4/54

• Formal Methods in Requirements Engineering
• Software & Software Specification, formally
• Requirements Engineering, formally
• Examples:
• Decision Tables
• Use Cases
• Live Sequence Charts
• LSC Semantics:
• Full LSC syntax
• Activation, Pre-Chart, Chart Mode
• Automaton Construction
• Loop / Progress / Exit Conditions
• LSCs vs. Software
• Excursion: Symbolic Büchi Automata
• Methodology
• Requirements Engineering with scenarios
• Strengthening scenarions into requirements
• Requirements Engineering Wrap-Up

Formal Methods in Requirements Engineering

– 9 – 2017-06-19 – Sformalre –

5/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

• We would like to precisely and objectively

specify the allowed softwares that make the customer happy.

Formal Methods in Requirements Engineering

– 9 – 2017-06-19 – Sformalre –

5/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

• We would like to precisely and objectively

specify the allowed softwares that make the customer happy.

• In other words, we want to formally define a satisfies relation

between softwares and software specifications. That is, given a software S and a software specification S , we want to define when (and only when) software S satisfies software specification S , denoted by S | = S .

Formal Methods in Requirements Engineering

– 9 – 2017-06-19 – Sformalre –

5/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

• We would like to precisely and objectively

specify the allowed softwares that make the customer happy.

• In other words, we want to formally define a satisfies relation

between softwares and software specifications. That is, given a software S and a software specification S , we want to define when (and only when) software S satisfies software specification S , denoted by S | = S .

• Once again:
• S |

= S : specification is satisfied, S is one “allowed” design, should be accepted.

• S |

= S : specification is not satisfied, S may not satisfy customer’s needs.

Software and Software Specification, formally

– 9 – 2017-06-19 – Sformalre –

6/54

• Definition. Software is a finite description S of a (possibly infinite)

set S of (finite or infinite) computation paths of the form σ0

α1

− − → σ1

α2

− − → σ2 · · · where

• σi ∈ Σ, i ∈ N0, is called state (or configuration), and
• αi ∈ A, i ∈ N0, is called action (or event).

The (possibly partial) function · : S → S is called interpretation of S.

Software and Software Specification, formally

– 9 – 2017-06-19 – Sformalre –

6/54

• Definition. Software is a finite description S of a (possibly infinite)

set S of (finite or infinite) computation paths of the form σ0

α1

− − → σ1

α2

− − → σ2 · · · where

• σi ∈ Σ, i ∈ N0, is called state (or configuration), and
• αi ∈ A, i ∈ N0, is called action (or event).

The (possibly partial) function · : S → S is called interpretation of S.

• Definition. A software specification is a finite description S
• f a (possibly infinite) set S of softwares, i.e.

S = {(S1, · 1), (S2, · 2), . . . }. The (possibly partial) function · : S → S is called interpretation of S .

Software Satisfies Software Specification

– 9 – 2017-06-19 – Sformalre –

7/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

• Definition. Software (S, · ) satisfies software specification S , denoted

by S | = S , if and only if (S, · ) ∈ S .

Software Satisfies Software Specification: Example

– 9 – 2017-06-19 – Sformalre –

8/54

Software Specification S :

T: room ventilation r1 r2 r3 b button pressed? × × −

• ff

ventilation off? × − ∗

• n

ventilation on? − × ∗ go start ventilation × − − stop stop ventilation − × −

Define: (S, · ) ∈ S if and only if for all σ0

α1

− − → σ1

α2

− − → σ2 · · · ∈ S and for all i ∈ N0, ∃ r ∈ T • σi | = F(r).

Software Satisfies Software Specification: Example

– 9 – 2017-06-19 – Sformalre –

8/54

Software Specification S :

T: room ventilation r1 r2 r3 b button pressed? × × −

• ff

ventilation off? × − ∗

• n

ventilation on? − × ∗ go start ventilation × − − stop stop ventilation − × −

Define: (S, · ) ∈ S if and only if for all σ0

α1

− − → σ1

α2

− − → σ2 · · · ∈ S and for all i ∈ N0, ∃ r ∈ T • σi | = F(r).

Software

• Assume we have a program S for the room

ventilation controller.

• Assume we can observe at well-defined

points in time the conditions b, off , on, go, stop when the software runs.

• Then the behaviour S of S can be viewed as

computation paths of the form σ0

τ

− → σ1

τ

− → σ2 · · · where each σi is a valuation of b, off , on, go, stop, i.e. σi : {b, off , on, go, stop} → B.

Software Satisfies Software Specification: Example

– 9 – 2017-06-19 – Sformalre –

8/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

Software Specification S :

T: room ventilation r1 r2 r3 b button pressed? × × −

• ff

ventilation off? × − ∗

• n

ventilation on? − × ∗ go start ventilation × − − stop stop ventilation − × −

Define: (S, · ) ∈ S if and only if for all σ0

α1

− − → σ1

α2

− − → σ2 · · · ∈ S and for all i ∈ N0, ∃ r ∈ T • σi | = F(r).

Software

• Assume we have a program S for the room

ventilation controller.

• Assume we can observe at well-defined

points in time the conditions b, off , on, go, stop when the software runs.

• Then the behaviour S of S can be viewed as

computation paths of the form σ0

τ

− → σ1

τ

− → σ2 · · · where each σi is a valuation of b, off , on, go, stop, i.e. σi : {b, off , on, go, stop} → B.

Software Satisfies Software Specification: Example

– 9 – 2017-06-19 – Sformalre –

8/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

Software Specification S :

T: room ventilation r1 r2 r3 b button pressed? × × −

• ff

ventilation off? × − ∗

• n

ventilation on? − × ∗ go start ventilation × − − stop stop ventilation − × −

Define: (S, · ) ∈ S if and only if for all σ0

α1

− − → σ1

α2

− − → σ2 · · · ∈ S and for all i ∈ N0, ∃ r ∈ T • σi | = F(r).

Software

• Assume we have a program S for the room

ventilation controller.

• Assume we can observe at well-defined

points in time the conditions b, off , on, go, stop when the software runs.

• Then the behaviour S of S can be viewed as

computation paths of the form σ0

τ

− → σ1

τ

− → σ2 · · · where each σi is a valuation of b, off , on, go, stop, i.e. σi : {b, off , on, go, stop} → B.

• Assume there is σ0

τ

− → σ1 · · · ∈ S with

σ1 = {b → 0, off → 1, on → 0, go → 1, stop → 0}.

Software Specification vs. Software

– 9 – 2017-06-19 – Sformalre –

9/54

σ0 α0

1

− − → σ0

1

α0

2

− − → σ0

2 · · ·

S = {(S0, · 0)}

Software Specification vs. Software

– 9 – 2017-06-19 – Sformalre –

9/54

σ0 α0

1

− − → σ0

1

α0

2

− − → σ0

2 · · ·

S = {(S0, · 0)}

σ1 α1

1

− − → σ1

1

α1

2

− − → σ1

2 · · ·

(S1, · 1)}

Software Specification vs. Software

– 9 – 2017-06-19 – Sformalre –

9/54

σ0 α0

1

− − → σ0

1

α0

2

− − → σ0

2 · · ·

S = {(S0, · 0)}

σ1 α1

1

− − → σ1

1

α1

2

− − → σ1

2 · · ·

(S1, · 1)} I M

S1 implements S via I and M

Software Specification vs. Software

– 9 – 2017-06-19 – Sformalre –

9/54

σ0 α0

1

− − → σ0

1

α0

2

− − → σ0

2 · · ·

S = {(S0, · 0)}

σ1 α1

1

− − → σ1

1

α1

2

− − → σ1

2 · · ·

(S1, · 1)}

σ2 α2

1

− − → σ2

1

α2

2

− − → σ2

2 · · ·

(S2, · 2)} I M

S1 implements S via I and M

I′ M ′

S2 implements S via I and M

Software Satisfies Software Specification: Another Example

– 9 – 2017-06-19 – Sformalre –

10/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

Software Specification

S :

• Example positive scenarios
• Example negative scenarios
• Use Cases with pre-condition

Define: (S, · ) ∈ S if and only if

• for each positive scenario, there is a

corresponding σ0

α1

− − → σ1

α2

− − → σ2 · · · ∈ S,

• for each negative scenario, there is no

corresponding σ0

α1

− − → σ1

α2

− − → σ2 · · · ∈ S,

• for each use case with pre-condition,

if some σi satisfies the pre-condition, then σi

αi+1

− − − − → σi+1

αi+2

− − − − → · · · corresponds to the use case.

Software Satisfies Software Specification: Another Example

– 9 – 2017-06-19 – Sformalre –

10/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

Software Specification

S :

• Example positive scenarios
• Example negative scenarios
• Use Cases with pre-condition

Define: (S, · ) ∈ S if and only if

• for each positive scenario, there is a

corresponding σ0

α1

− − → σ1

α2

− − → σ2 · · · ∈ S,

• for each negative scenario, there is no

corresponding σ0

α1

− − → σ1

α2

− − → σ2 · · · ∈ S,

• for each use case with pre-condition,

if some σi satisfies the pre-condition, then σi

αi+1

− − − − → σi+1

αi+2

− − − − → · · · corresponds to the use case.

Software

• Assume we can observe at well-defined

points in time the observables relevant for the use cases when the software S runs.

• Then the behaviour S of S can be viewed

as computation paths where each state σi is a valuation of the use case’s observables.

• And then we can relate S to S .

Software Satisfies Software Specification: Another Example

– 9 – 2017-06-19 – Sformalre –

11/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

Software Specification

S :

LSC: buy water AC: true AM: invariant I: strict User CoinValidator ChoicePanel Dispenser C50 p W A T E R water_in_stock dWATER OK

Define: (S, · ) ∈ S if and only if

• tja... (in a minute)

Software Satisfies Software Specification: Another Example

– 9 – 2017-06-19 – Sformalre –

11/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

Software Specification

S :

LSC: buy water AC: true AM: invariant I: strict User CoinValidator ChoicePanel Dispenser C50 p W A T E R water_in_stock dWATER OK

Define: (S, · ) ∈ S if and only if

• tja... (in a minute)

Software

• Assume we can observe at well-defined

points in time the observables relevant for the LSC (conditions and messages) when the soft- ware S runs.

• Then the behaviour S of S can be viewed

as computation paths over the LSC’s observ- ables.

• And then we can relate S to S .

Content

– 9 – 2017-06-19 – Scontent –

12/54

• Formal Methods in Requirements Engineering
• Software & Software Specification, formally
• Requirements Engineering, formally
• Examples:
• Decision Tables
• Use Cases
• Live Sequence Charts
• LSC Semantics:
• Full LSC syntax
• Activation, Pre-Chart, Chart Mode
• Automaton Construction
• Loop / Progress / Exit Conditions
• LSCs vs. Software
• Excursion: Symbolic Büchi Automata
• Methodology
• Requirements Engineering with scenarios
• Strengthening scenarions into requirements
• Requirements Engineering Wrap-Up

LSC Semantics

– 9 – 2017-06-19 – main –

13/54

Full LSC Syntax

– 9 – 2017-06-19 – Sprechart –

14/54

LSC: buy water AC: true AM: invariant I: strict

User CoinValidator ChoicePanel Dispenser C50 p W A T E R water_in_stock d W A T E R O K

A full LSC L = (PC, MC, ac0, am, ΘL ) actually consist of

• pre-chart PC = ((LP , P , ∼P ), IP , MsgP , CondP , LocInvP , ΘP ) (possibly empty),
• main-chart MC = ((LM, M, ∼M), IM, MsgM, CondM, LocInvM, ΘM) (non-empty),
• activation condition ac0 ∈ Φ(C),
• strictness flag strict (if false, L is permissive)
• activation mode am ∈ {initial, invariant},
• chart mode existential (ΘL = cold) or universal (ΘL = hot).

– 9 – 2017-06-19 – Sprechart –

15/54

From Concrete to Abstract Syntax

– 8 – 2017-06-01 – Slscsyn –

32/46

• locations L,
• L × L,

L × L

• I = {I1, . . . , In},
• Msg L × E × L,
• Cond (2L \ ) × (C)
• LocInv L × {, •} × (C) × L × {, •},
• : L Msg Cond LocInv {hot, cold}.

I1 I2 c1 I3 A B C D E c2 c3 c4 l1,0 l1,1 l1,2 l1,3 l1,4 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1 l3,2 l3,3

• L = {l1,0, l1,1, l1,2, l1,3, l1,2, l1,4, l2,0, l2,1, l2,2, l2,3, l3,0, l3,1, l3,2, l3,3}
• l1,0 l1,1 l1,2 l1,3,

l1,2 l1,4, l2,0 l2,1 l2,2 l2,3, l3,0 l3,1 l3,2 l3,3, l1,1 l2,1, l2,2 l1,2, l2,3 l1,3, l3,2 l1,4, l2,1 l3,1, l2,2 l3,2,

• I = {{l1,0, l1,1, l1,2, l1,3, l1,4}, {l2,0, l2,1, l2,2, l2,3}, {l3,0, l3,1, l3,2}},
• Msg = {(l1,1, A, l2,1), (l2,2, B, l1,2), (l2,2, C, l3,2), (l2,3, D, l1,3), (l3,3, E, l1,4)}
• Cond = {({l2,1, l3,1}, c4), ({l2,2}, c2 c3)},
• LocInv = {(l1,1, , c1, l1,2, •)}

LSC Semantics

– 9 – 2017-06-19 – Sprechart –

16/54

ΘL am = initial am = invariant cold

∃ w ∈ W ∃ m ∈ N0 • w0 | = ac ∧ w0 | = ψCond

hot (∅, CP 0 )

∧ w/1, . . . , w/m ∈ Lang(B(PC)) ∧ wm+1 | = ψCond

hot (∅, CM 0 )

∧ w/m + 1 ∈ Lang(B(MC)) ∃ w ∈ W ∃ k < m ∈ N0 • wk | = ac ∧ wk | = ψCond

hot (∅, CP 0 )

∧ w/k + 1, . . . , w/m ∈ Lang(B(PC)) ∧ wm+1 | = ψCond

hot (∅, CM 0 )

∧ w/m + 1 ∈ Lang(B(MC))

hot

∀ w ∈ W • w0 | = ac ∧ w0 | = ψCond

hot (∅, CP 0 )

∧ w/1, . . . , w/m ∈ Lang(B(PC)) ∧ wm+1 | = ψCond

cold (∅, CM 0 )

= ⇒ wm+1 | = ψCond

cold (∅, CM 0 )

∧ w/m + 1 ∈ Lang(B(MC)) ∀ w ∈ W ∀ k ≤ m ∈ N0 • wk | = ac ∧ wk | = ψCond

hot (∅, CP 0 )

∧ w/k + 1, . . . , w/m ∈ Lang(B(PC)) ∧ wm+1 | = ψCond

cold (∅, CM 0 )

= ⇒ wm+1 | = ψCond

cold (∅, CM 0 )

∧ w/m + 1 ∈ Lang(B(MC))

• Here, W is a set of words (for the moment, think of computation paths, like S).
• w ∈ W is a word (for the moment, think of a computation path, like σ0

α1

− − → σ1

α2

− − → σ2 · · · ∈ S).

Example: Vending Machine

– 9 – 2017-06-19 – Sprechart –

17/54

• Positive scenario: Buy a Softdrink

(i) Insert one 1 euro coin. (ii) Press the ‘softdrink’ button. (iii) Get a softdrink.

• Positive scenario: Get Change

(i) Insert one 50 cent and one 1 euro coin. (ii) Press the ‘softdrink’ button. (iii) Get a softdrink. (iv) Get 50 cent change.

• Negative scenario: A Drink for Free

(i) Insert one 1 euro coin. (ii) Press the ‘softdrink’ button. (iii) Do not insert any more money. (iv) Get two softdrinks.

LSC Semantics

– 9 – 2017-06-19 – Sprechart –

18/54

LSC: buy softdrink AC: true AM: invariant I: permissive

User

• Vend. Ma.

E1 pSOFT SOFT

ΘL am = initial am = invariant cold

∃ w ∈ W ∃ m ∈ N0 • w0 | = ac ∧ w0 | = ψCond

hot (∅, CP 0 )

∧ w/1, . . . , w/m ∈ Lang(B(PC)) ∧ wm+1 | = ψCond

hot (∅, CM 0 )

∧ w/m + 1 ∈ Lang(B(MC)) ∃ w ∈ W ∃ k < m ∈ N0 • wk | = ac ∧ wk | = ψCond

hot (∅, CP 0 )

∧ w/k + 1, . . . , w/m ∈ Lang(B(PC)) ∧ wm+1 | = ψCond

hot (∅, CM 0 )

∧ w/m + 1 ∈ Lang(B(MC))

hot

∀ w ∈ W • w0 | = ac ∧ w0 | = ψCond

hot (∅, CP 0 )

∧ w/1, . . . , w/m ∈ Lang(B(PC)) ∧ wm+1 | = ψCond

cold (∅, CM 0 )

= ⇒ wm+1 | = ψCond

cold (∅, CM 0 )

∧ w/m + 1 ∈ Lang(B(MC)) ∀ w ∈ W ∀ k ≤ m ∈ N0 • wk | = ac ∧ wk | = ψCond

hot (∅, CP 0 )

∧ w/k + 1, . . . , w/m ∈ Lang(B(PC)) ∧ wm+1 | = ψCond

cold (∅, CM 0 )

= ⇒ wm+1 | = ψCond

cold (∅, CM 0 )

∧ w/m + 1 ∈ Lang(B(MC))

LSC Semantics

– 9 – 2017-06-19 – Sprechart –

19/54

LSC: get change AC: true AM: invariant I: permissive

User

• Vend. Ma.

C50 E1 pSOFT SOFT chg-C50

ΘL am = initial am = invariant cold

∃ w ∈ W ∃ m ∈ N0 • w0 | = ac ∧ w0 | = ψCond

hot (∅, CP 0 )

∧ w/1, . . . , w/m ∈ Lang(B(PC)) ∧ wm+1 | = ψCond

hot (∅, CM 0 )

∧ w/m + 1 ∈ Lang(B(MC)) ∃ w ∈ W ∃ k < m ∈ N0 • wk | = ac ∧ wk | = ψCond

hot (∅, CP 0 )

∧ w/k + 1, . . . , w/m ∈ Lang(B(PC)) ∧ wm+1 | = ψCond

hot (∅, CM 0 )

∧ w/m + 1 ∈ Lang(B(MC))

hot

∀ w ∈ W • w0 | = ac ∧ w0 | = ψCond

hot (∅, CP 0 )

∧ w/1, . . . , w/m ∈ Lang(B(PC)) ∧ wm+1 | = ψCond

cold (∅, CM 0 )

= ⇒ wm+1 | = ψCond

cold (∅, CM 0 )

∧ w/m + 1 ∈ Lang(B(MC)) ∀ w ∈ W ∀ k ≤ m ∈ N0 • wk | = ac ∧ wk | = ψCond

hot (∅, CP 0 )

∧ w/k + 1, . . . , w/m ∈ Lang(B(PC)) ∧ wm+1 | = ψCond

cold (∅, CM 0 )

= ⇒ wm+1 | = ψCond

cold (∅, CM 0 )

∧ w/m + 1 ∈ Lang(B(MC))

LSC Semantics

– 9 – 2017-06-19 – Sprechart –

20/54

LSC: buy water AC: true AM: invariant I: strict

User CoinValidator ChoicePanel Dispenser C50 p W A T E R water_in_stock dWATER OK

ΘL am = initial am = invariant cold

∃ w ∈ W ∃ m ∈ N0 • w0 | = ac ∧ w0 | = ψCond

hot (∅, CP 0 )

∧ w/1, . . . , w/m ∈ Lang(B(PC)) ∧ wm+1 | = ψCond

hot (∅, CM 0 )

∧ w/m + 1 ∈ Lang(B(MC)) ∃ w ∈ W ∃ k < m ∈ N0 • wk | = ac ∧ wk | = ψCond

hot (∅, CP 0 )

∧ w/k + 1, . . . , w/m ∈ Lang(B(PC)) ∧ wm+1 | = ψCond

hot (∅, CM 0 )

∧ w/m + 1 ∈ Lang(B(MC))

hot

∀ w ∈ W • w0 | = ac ∧ w0 | = ψCond

hot (∅, CP 0 )

∧ w/1, . . . , w/m ∈ Lang(B(PC)) ∧ wm+1 | = ψCond

cold (∅, CM 0 )

= ⇒ wm+1 | = ψCond

cold (∅, CM 0 )

∧ w/m + 1 ∈ Lang(B(MC)) ∀ w ∈ W ∀ k ≤ m ∈ N0 • wk | = ac ∧ wk | = ψCond

hot (∅, CP 0 )

∧ w/k + 1, . . . , w/m ∈ Lang(B(PC)) ∧ wm+1 | = ψCond

cold (∅, CM 0 )

= ⇒ wm+1 | = ψCond

cold (∅, CM 0 )

∧ w/m + 1 ∈ Lang(B(MC))

Example: Vending Machine

– 9 – 2017-06-19 – Sprechart –

21/54

• Positive scenario: Buy a Softdrink

(i) Insert one 1 euro coin. (ii) Press the ‘softdrink’ button. (iii) Get a softdrink.

• Positive scenario: Get Change

(i) Insert one 50 cent and one 1 euro coin. (ii) Press the ‘softdrink’ button. (iii) Get a softdrink. (iv) Get 50 cent change.

• Negative scenario: A Drink for Free

(i) Insert one 1 euro coin. (ii) Press the ‘softdrink’ button. (iii) Do not insert any more money. (iv) Get two softdrinks.

LSC Semantics

– 9 – 2017-06-19 – Sprechart –

22/54

LSC:

• nly one drink

AC: true AM: invariant I: permissive

User

• Vend. Ma.

E1 pSOFT SOFT SOFT ¬C50! ∧ ¬E1! false

ΘL am = initial am = invariant cold

∃ w ∈ W ∃ m ∈ N0 • w0 | = ac ∧ w0 | = ψCond

hot (∅, CP 0 )

∧ w/1, . . . , w/m ∈ Lang(B(PC)) ∧ wm+1 | = ψCond

hot (∅, CM 0 )

∧ w/m + 1 ∈ Lang(B(MC)) ∃ w ∈ W ∃ k < m ∈ N0 • wk | = ac ∧ wk | = ψCond

hot (∅, CP 0 )

∧ w/k + 1, . . . , w/m ∈ Lang(B(PC)) ∧ wm+1 | = ψCond

hot (∅, CM 0 )

∧ w/m + 1 ∈ Lang(B(MC))

hot

∀ w ∈ W • w0 | = ac ∧ w0 | = ψCond

hot (∅, CP 0 )

∧ w/1, . . . , w/m ∈ Lang(B(PC)) ∧ wm+1 | = ψCond

cold (∅, CM 0 )

= ⇒ wm+1 | = ψCond

cold (∅, CM 0 )

∧ w/m + 1 ∈ Lang(B(MC)) ∀ w ∈ W ∀ k ≤ m ∈ N0 • wk | = ac ∧ wk | = ψCond

hot (∅, CP 0 )

∧ w/k + 1, . . . , w/m ∈ Lang(B(PC)) ∧ wm+1 | = ψCond

cold (∅, CM 0 )

= ⇒ wm+1 | = ψCond

cold (∅, CM 0 )

∧ w/m + 1 ∈ Lang(B(MC))

LSC Semantics: TBA Construction

– 9 – 2017-06-19 – main –

23/54

The Plan: A Formal Semantics for a Visual Formalism

– 9 – 2017-06-19 – Slsc –

24/54

I1 I2

φ

I3

E F G

concrete syntax

(diagram)

((L, , ∼), I, Msg, Cond, LocInv, Θ) abstract syntax

q1 q2 q3 q4 q5 q6 q7 true

semantics

(Büchi automaton)

– 9 – 2017-06-19 – main –

25/54

TBA Construction Principle

– 9 – 2017-06-19 – Slscsem –

26/54 “Only” construct the transitions’ labels:

→= {(q, ψloop(q), q) | q ∈ Q} ∪ {(q, ψprog(q, q′), q′) | q F q′} ∪ {(q, ψexit(q), L) | q ∈ Q}

q q1 ... qn

ψloop(q) =

=:ψhot loop (q)

• ψMsg(q) ∧ ψLocInv

hot

(q) ∧ψLocInv

cold

(q) ψexit(q) =

• ψhot

loop(q) ∧ ¬ψLocInv cold

(q)

• ∨

1≤i≤n

• ψhot

prog(q, qi)

∧

• ¬ψLocInv,•

cold

(q, qi)∨¬ψCond

cold (q, qi)

• ψprog(q, qn) =

=:ψhot prog (q,qn)

• ψMsg(q, qn) ∧ ψCond

hot (q, qn) ∧ ψLocInv,• hot

(q, qn) ∧ ψCond

cold (q, qn) ∧ ψLocInv,• cold

(q, qn) true

I1 I2 c1 I3 A B C D E c2 ∧ c3

Loop Condition

– 9 – 2017-06-19 – Slscsem –

27/54

ψloop(q) = ψMsg(q) ∧ ψLocInv

hot

(q) ∧ ψLocInv

cold

(q)

• ψMsg(q) = ¬

1≤i≤n ψMsg(q, qi) ∧

• strict =

⇒

• ψ∈E!?∩Msg(L)

¬ψ

• =:ψstrict(q)
• ψLocInv

θ

(q) =

ℓ=(l,ι,φ,l′,ι′)∈LocInv, Θ(ℓ)=θ, ℓ active at q φ

A location l is called front location of cut C if and only if ∄ l′ ∈ L • l ≺ l′. Local invariant (lo, ι0, φ, l1, ι1) is active at cut (!) q if and only if l0 l ≺ l1 for some front location l of cut q or l = l1 ∧ ι1 = •.

• Msg(F) = {E! | (l, E, l′) ∈ Msg, l ∈ F} ∪ {E? | (l, E, l′) ∈ Msg, l′ ∈ F}
• Msg(F1, . . . , Fn) =

1≤i≤n Msg(Fi) I1 I2 c1 I3 A B C D E c2 ∧ c3

Progress Condition

– 9 – 2017-06-19 – Slscsem –

28/54

ψhot

prog(q, qi) = ψMsg(q, qn) ∧ ψCond hot (q, qn) ∧ ψLocInv,• hot

(qn)

• ψMsg(q, qi) =

ψ∈Msg(qi\q) ψ ∧ j=i

• ψ∈(Msg(qj\q)\Msg(qi\q)) ¬ψ

∧

• strict =

⇒

• ψ∈(E!?∩Msg(L))\Msg(Fi)

¬ψ

• =:ψstrict(q,qi)
• ψCond

θ

(q, qi) =

γ=(L,φ)∈Cond, Θ(γ)=θ, L∩(qi\q)=∅ φ

• ψLocInv,•

θ

(q, qi) =

λ=(l,ι,φ,l′,ι′)∈LocInv, Θ(λ)=θ, λ •-active at qi φ

Local invariant (l0, ι0, φ, l1, ι1) is •-active at q if and only if

• l0 ≺ l ≺ l1, or
• l = l0 ∧ ι0 = •, or
• l = l1 ∧ ι1 = •

for some front location l of cut (!) q.

I1 I2 c1 I3 A B C D E c2 ∧ c3

Example

– 9 – 2017-06-19 – Slscsem –

29/54

I1 I2

φ

I3

E F G

l1,0 l1,1 l1,2 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1

q1 q2 q3 q4 q5 q6 q7

true

Content

– 9 – 2017-06-19 – Scontent –

30/54

• Formal Methods in Requirements Engineering
• Software & Software Specification, formally
• Requirements Engineering, formally
• Examples:
• Decision Tables
• Use Cases
• Live Sequence Charts
• LSC Semantics:
• Full LSC syntax
• Activation, Pre-Chart, Chart Mode
• Automaton Construction
• Loop / Progress / Exit Conditions
• LSCs vs. Software
• Excursion: Symbolic Büchi Automata
• Methodology
• Requirements Engineering with scenarios
• Strengthening scenarions into requirements
• Requirements Engineering Wrap-Up

Tell Them What You’ve Told Them. . .

– 9 – 2017-06-19 – Sttwytt –

31/54

• Live Sequence Charts (if well-formed)
• have an abstract syntax.
• From an abstract syntax, mechanically construct its TBA.
• A universal LSC is satisfied by a software S if and only if
• all words induced by the computation paths of S
• are accepted by the LSC’s TBA.
• An existential LSC is satisfied by a software S if and only if
• there is a word induced by a computation path of S
• which is accepted by the LSC’s TBA.
• Pre-charts allow us to specify
• anti-scenarios (“this must not happen”),
• activation interactions.

Excursion: Symbolic Büchi Automata

– 9 – 2017-06-19 – main –

32/54

From Finite Automata to Symbolic Büchi Automata

– 9 – 2017-06-19 – Stba –

33/54

q1 q2 1 A: Σ = {0, 1} q1 q2 1 B: Σ = {0, 1} q1 q2 1 1 B′: Σ = {0, 1} q1 q2 even(x)

• dd(x)

Asym: Σ = ({x} → N) q1 q2 even(x)

• dd(x)

Bsym: Σ = ({x} → N)

Büchi infinite words symbolic symbolic Büchi infinite words

Symbolic Büchi Automata

– 9 – 2017-06-19 – Stba –

34/54

• Definition. A Symbolic Büchi Automaton (TBA) is a tuple

B = (CB, Q, qini, →, QF ) where

• CB is a set of atomic propositions,
• Q is a finite set of states,
• qini ∈ Q is the initial state,
• → ⊆ Q × Φ(CB) × Q is the finite transition relation.

Each transitions (q, ψ, q′) ∈ → from state q to state q′ is labelled with a formula ψ ∈ Φ(CB).

• QF ⊆ Q is the set of fair (or accepting) states.

Run of TBA

– 9 – 2017-06-19 – Stba –

35/54

• Definition. Let B = (CB, Q, qini, →, QF ) be a TBA and

w = σ1, σ2, σ3, · · · ∈ (Φ(CB) → B)ω an infinite word, each letter is a valuation of Φ(CB). An infinite sequence ̺ = q0, q1, q2, . . . ∈ Qω

• f states is called run of B over w if and only if
• q0 = qini,
• for each i ∈ N0 there is a transition (qi, ψi, qi+1) ∈→ s.t. σi |

= ψi. Example:

q1 q2 even(x)

• dd(x)

Bsym: Σ = ({x} → N)

The Language of a TBA

– 9 – 2017-06-19 – Stba –

36/54

Definition. We say TBA B = (CB, Q, qini, →, QF ) accepts the word w = (σi)i∈N0 ∈ (Φ(CB) → B)ω if and only if B has a run ̺ = (qi)i∈N0

• ver w such that

fair (or accepting) states are visited infinitely often by ̺, i.e., such that ∀ i ∈ N0 ∃ j > i : qj ∈ QF . We call the set Lang(B) ⊆ (Φ(CB) → B)ω of words that are accepted by B the language of B. Example:

q1 q2 even(x)

• dd(x)

Bsym: Σ = ({x} → N)

LSCs vs. Software

– 9 – 2017-06-19 – main –

37/54

LSCs as Software Specification

– 9 – 2017-06-19 – Stestplay –

38/54

A software S is called compatible with LSC L over C and E is if and only if

• Σ = (C → B), i.e. the states are valuations of the conditions in C,
• A ⊆ E!?, i.e. the events are of the form E!, E? (viewed as a valuation of E!, E?).

LSCs as Software Specification

– 9 – 2017-06-19 – Stestplay –

38/54

A software S is called compatible with LSC L over C and E is if and only if

• Σ = (C → B), i.e. the states are valuations of the conditions in C,
• A ⊆ E!?, i.e. the events are of the form E!, E? (viewed as a valuation of E!, E?).

A computation path π = σ0

α1

− − → σ1

α2

− − → σ2 · · · ∈ S of software S induces the word w(π) = (σ0 ∪ α1), (σ1 ∪ α2), (σ2 ∪ α3), . . . , we use WS to denote the set of words induced by S.

LSCs as Software Specification

– 9 – 2017-06-19 – Stestplay –

38/54

A software S is called compatible with LSC L over C and E is if and only if

• Σ = (C → B), i.e. the states are valuations of the conditions in C,
• A ⊆ E!?, i.e. the events are of the form E!, E? (viewed as a valuation of E!, E?).

A computation path π = σ0

α1

− − → σ1

α2

− − → σ2 · · · ∈ S of software S induces the word w(π) = (σ0 ∪ α1), (σ1 ∪ α2), (σ2 ∪ α3), . . . , we use WS to denote the set of words induced by S.

We say software S satisfies LSC L (without pre-chart), denoted by S | = L , if and only if

LSCs as Software Specification

– 9 – 2017-06-19 – Stestplay –

38/54

A software S is called compatible with LSC L over C and E is if and only if

• Σ = (C → B), i.e. the states are valuations of the conditions in C,
• A ⊆ E!?, i.e. the events are of the form E!, E? (viewed as a valuation of E!, E?).

A computation path π = σ0

α1

− − → σ1

α2

− − → σ2 · · · ∈ S of software S induces the word w(π) = (σ0 ∪ α1), (σ1 ∪ α2), (σ2 ∪ α3), . . . , we use WS to denote the set of words induced by S.

We say software S satisfies LSC L (without pre-chart), denoted by S | = L , if and only if

ΘL am = initial am = invariant cold

∃ w ∈ WS • w0 | = ac ∧ ¬ψexit(C0) ∧ w0 | = ψprog(∅, C0) ∧ w/1 ∈ Lang(B(L )) ∃ w ∈ WS ∃ k ∈ N0 • wk | = ac ∧ ¬ψexit(C0) ∧ wk | = ψprog(∅, C0) ∧ w/k + 1 ∈ Lang(B(L ))

hot

∀ w ∈ WS • w0 | = ac ∧ ¬ψexit(C0) = ⇒ w0 | = ψprog(∅, C0) ∧ w/1 ∈ Lang(B(L )) ∀ w ∈ WS ∀ k ∈ N0 • wk | = ac ∧ ¬ψexit(C0) = ⇒ wk | = ψCond

hot (∅, C0)∧w/k+1 ∈ Lang(B(L ))

LSCs as Software Specification

– 9 – 2017-06-19 – Stestplay –

38/54

A software S is called compatible with LSC L over C and E is if and only if

• Σ = (C → B), i.e. the states are valuations of the conditions in C,
• A ⊆ E!?, i.e. the events are of the form E!, E? (viewed as a valuation of E!, E?).

A computation path π = σ0

α1

− − → σ1

α2

− − → σ2 · · · ∈ S of software S induces the word w(π) = (σ0 ∪ α1), (σ1 ∪ α2), (σ2 ∪ α3), . . . , we use WS to denote the set of words induced by S.

We say software S satisfies LSC L (without pre-chart), denoted by S | = L , if and only if

ΘL am = initial am = invariant cold

∃ w ∈ WS • w0 | = ac ∧ ¬ψexit(C0) ∧ w0 | = ψprog(∅, C0) ∧ w/1 ∈ Lang(B(L )) ∃ w ∈ WS ∃ k ∈ N0 • wk | = ac ∧ ¬ψexit(C0) ∧ wk | = ψprog(∅, C0) ∧ w/k + 1 ∈ Lang(B(L ))

hot

∀ w ∈ WS • w0 | = ac ∧ ¬ψexit(C0) = ⇒ w0 | = ψprog(∅, C0) ∧ w/1 ∈ Lang(B(L )) ∀ w ∈ WS ∀ k ∈ N0 • wk | = ac ∧ ¬ψexit(C0) = ⇒ wk | = ψCond

hot (∅, C0)∧w/k+1 ∈ Lang(B(L ))

Software S satisfies a set of LSCs L1, . . . , Ln if and only if S | = Li for all 1 ≤ i ≤ n.

How to Prove that a Software Satisfies an LSC?

– 9 – 2017-06-19 – Stestplay –

39/54

LSC: buy softdrink AC: true AM: invariant I: permissive User

• Vend. Ma.

E1 pSOFT SOFT LSC: get change AC: true AM: invariant I: permissive User

• Vend. Ma.

C50 E1 pSOFT SOFT chg-C50

How to Prove that a Software Satisfies an LSC?

– 9 – 2017-06-19 – Stestplay –

39/54

LSC: buy softdrink AC: true AM: invariant I: permissive User

• Vend. Ma.

E1 pSOFT SOFT LSC: get change AC: true AM: invariant I: permissive User

• Vend. Ma.

C50 E1 pSOFT SOFT chg-C50

• Software S satisfies existential LSC L if there exists π ∈ S

such that L accepts w(π). Prove S | = L by demonstrating π.

• Note: Existential LSCs∗ may hint at test-cases for the acceptance test!

(∗: as well as (positive) scenarios in general, like use-cases)

How to Prove that a Software Satisfies an LSC?

– 9 – 2017-06-19 – Stestplay –

39/54

LSC: buy softdrink AC: true AM: invariant I: permissive User

• Vend. Ma.

E1 pSOFT SOFT LSC: get change AC: true AM: invariant I: permissive User

• Vend. Ma.

C50 E1 pSOFT SOFT chg-C50

• Software S satisfies existential LSC L if there exists π ∈ S

such that L accepts w(π). Prove S | = L by demonstrating π.

• Note: Existential LSCs∗ may hint at test-cases for the acceptance test!

(∗: as well as (positive) scenarios in general, like use-cases)

requirements fixed requirements fixed acceptance acceptance system specified system specified system delivered system delivered architecture designed architecture designed system integrated system integrated modules designed modules designed system realised system realised verification & validation

How to Prove that a Software Satisfies an LSC?

– 9 – 2017-06-19 – Stestplay –

39/54

LSC: buy softdrink AC: true AM: invariant I: permissive User

• Vend. Ma.

E1 pSOFT SOFT LSC: get change AC: true AM: invariant I: permissive User

• Vend. Ma.

C50 E1 pSOFT SOFT chg-C50

• Software S satisfies existential LSC L if there exists π ∈ S

such that L accepts w(π). Prove S | = L by demonstrating π.

• Note: Existential LSCs∗ may hint at test-cases for the acceptance test!

(∗: as well as (positive) scenarios in general, like use-cases)

requirements fixed requirements fixed acceptance acceptance system specified system specified system delivered system delivered architecture designed architecture designed system integrated system integrated modules designed modules designed system realised system realised verification & validation

How to Prove that a Software Satisfies an LSC?

– 9 – 2017-06-19 – Stestplay –

39/54

LSC: buy softdrink AC: true AM: invariant I: permissive User

• Vend. Ma.

E1 pSOFT SOFT LSC: get change AC: true AM: invariant I: permissive User

• Vend. Ma.

C50 E1 pSOFT SOFT chg-C50

• Software S satisfies existential LSC L if there exists π ∈ S

such that L accepts w(π). Prove S | = L by demonstrating π.

• Note: Existential LSCs∗ may hint at test-cases for the acceptance test!

(∗: as well as (positive) scenarios in general, like use-cases)

requirements fixed requirements fixed acceptance acceptance system specified system specified system delivered system delivered architecture designed architecture designed system integrated system integrated modules designed modules designed system realised system realised verification & validation

LSC:

• nly one drink

AC: true AM: invariant I: permissive User

• Vend. Ma.

E1 pSOFT SOFT SOFT ¬C50! ∧ ¬E1! false LSC: buy water AC: true AM: invariant I: strict User CoinValidator ChoicePanel Dispenser C50 pWATER

¬(C50! ∨ E1! ∨ pSOFT! ∨ pTEA! ∨ pFILLUP!)

water_in_stock dWATER OK

¬(dSoft! ∨ dTEA!)

How to Prove that a Software Satisfies an LSC?

– 9 – 2017-06-19 – Stestplay –

39/54

LSC: buy softdrink AC: true AM: invariant I: permissive User

• Vend. Ma.

E1 pSOFT SOFT LSC: get change AC: true AM: invariant I: permissive User

• Vend. Ma.

C50 E1 pSOFT SOFT chg-C50

• Software S satisfies existential LSC L if there exists π ∈ S

such that L accepts w(π). Prove S | = L by demonstrating π.

• Note: Existential LSCs∗ may hint at test-cases for the acceptance test!

(∗: as well as (positive) scenarios in general, like use-cases)

requirements fixed requirements fixed acceptance acceptance system specified system specified system delivered system delivered architecture designed architecture designed system integrated system integrated modules designed modules designed system realised system realised verification & validation

LSC:

• nly one drink

AC: true AM: invariant I: permissive User

• Vend. Ma.

E1 pSOFT SOFT SOFT ¬C50! ∧ ¬E1! false LSC: buy water AC: true AM: invariant I: strict User CoinValidator ChoicePanel Dispenser C50 pWATER

¬(C50! ∨ E1! ∨ pSOFT! ∨ pTEA! ∨ pFILLUP!)

water_in_stock dWATER OK

¬(dSoft! ∨ dTEA!)

• Universal LSCs (and negative/anti-scenarios!) in general need an exhaustive analysis!

How to Prove that a Software Satisfies an LSC?

– 9 – 2017-06-19 – Stestplay –

39/54

LSC: buy softdrink AC: true AM: invariant I: permissive User

• Vend. Ma.

E1 pSOFT SOFT LSC: get change AC: true AM: invariant I: permissive User

• Vend. Ma.

C50 E1 pSOFT SOFT chg-C50

• Software S satisfies existential LSC L if there exists π ∈ S

such that L accepts w(π). Prove S | = L by demonstrating π.

• Note: Existential LSCs∗ may hint at test-cases for the acceptance test!

(∗: as well as (positive) scenarios in general, like use-cases)

requirements fixed requirements fixed acceptance acceptance system specified system specified system delivered system delivered architecture designed architecture designed system integrated system integrated modules designed modules designed system realised system realised verification & validation

LSC:

• nly one drink

AC: true AM: invariant I: permissive User

• Vend. Ma.

E1 pSOFT SOFT SOFT ¬C50! ∧ ¬E1! false LSC: buy water AC: true AM: invariant I: strict User CoinValidator ChoicePanel Dispenser C50 pWATER

¬(C50! ∨ E1! ∨ pSOFT! ∨ pTEA! ∨ pFILLUP!)

water_in_stock dWATER OK

¬(dSoft! ∨ dTEA!)

• Universal LSCs (and negative/anti-scenarios!) in general need an exhaustive analysis!

(Because they require that the software never ever exhibits the unwanted behaviour.)

Prove S | = L by demonstrating one π such that w(π) is not accepted by L .

Pushing It Even Further

– 9 – 2017-06-19 – Stestplay –

40/54

(Harel and Marelly, 2003)

Requirements Engineering with Scenarios

– 9 – 2017-06-19 – main –

41/54

Requirements Engineering with Scenarios

– 9 – 2017-06-19 – Sstrengthen –

42/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

Requirements Engineering with Scenarios

– 9 – 2017-06-19 – Sstrengthen –

42/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

One quite effective approach: (i) Approximate the software requirements: ask for positive / negative existential scenarios. (ii) Refine result into universal scenarios (and validate them with customer).

Requirements Engineering with Scenarios

– 9 – 2017-06-19 – Sstrengthen –

42/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

One quite effective approach: (i) Approximate the software requirements: ask for positive / negative existential scenarios. (ii) Refine result into universal scenarios (and validate them with customer).

That is:

Requirements Engineering with Scenarios

– 9 – 2017-06-19 – Sstrengthen –

42/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

One quite effective approach: (i) Approximate the software requirements: ask for positive / negative existential scenarios. (ii) Refine result into universal scenarios (and validate them with customer).

That is:

• Ask the customer to describe example usages of the desired system.

In the sense of: “If the system is not at all able to do this, then it’s not what I want.” (→ positive use-cases, existential LSC)

Requirements Engineering with Scenarios

– 9 – 2017-06-19 – Sstrengthen –

42/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

One quite effective approach: (i) Approximate the software requirements: ask for positive / negative existential scenarios. (ii) Refine result into universal scenarios (and validate them with customer).

That is:

• Ask the customer to describe example usages of the desired system.

In the sense of: “If the system is not at all able to do this, then it’s not what I want.” (→ positive use-cases, existential LSC)

• Ask the customer to describe behaviour that must not happen in the desired system.

In the sense of: “If the system does this, then it’s not what I want.” (→ negative use-cases, LSC with pre-chart and hot-false)

Requirements Engineering with Scenarios

– 9 – 2017-06-19 – Sstrengthen –

42/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

One quite effective approach: (i) Approximate the software requirements: ask for positive / negative existential scenarios. (ii) Refine result into universal scenarios (and validate them with customer).

That is:

• Ask the customer to describe example usages of the desired system.

In the sense of: “If the system is not at all able to do this, then it’s not what I want.” (→ positive use-cases, existential LSC)

• Ask the customer to describe behaviour that must not happen in the desired system.

In the sense of: “If the system does this, then it’s not what I want.” (→ negative use-cases, LSC with pre-chart and hot-false)

• Investigate preconditions, side-conditions, exceptional cases and corner-cases.

(→ extend use-cases, refine LSCs with conditions or local invariants)

Requirements Engineering with Scenarios

– 9 – 2017-06-19 – Sstrengthen –

42/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

One quite effective approach: (i) Approximate the software requirements: ask for positive / negative existential scenarios. (ii) Refine result into universal scenarios (and validate them with customer).

That is:

• Ask the customer to describe example usages of the desired system.

In the sense of: “If the system is not at all able to do this, then it’s not what I want.” (→ positive use-cases, existential LSC)

• Ask the customer to describe behaviour that must not happen in the desired system.

In the sense of: “If the system does this, then it’s not what I want.” (→ negative use-cases, LSC with pre-chart and hot-false)

• Investigate preconditions, side-conditions, exceptional cases and corner-cases.

(→ extend use-cases, refine LSCs with conditions or local invariants)

• Generalise into universal requirements, e.g., universal LSCs.

Requirements Engineering with Scenarios

– 9 – 2017-06-19 – Sstrengthen –

42/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

One quite effective approach: (i) Approximate the software requirements: ask for positive / negative existential scenarios. (ii) Refine result into universal scenarios (and validate them with customer).

That is:

• Ask the customer to describe example usages of the desired system.

In the sense of: “If the system is not at all able to do this, then it’s not what I want.” (→ positive use-cases, existential LSC)

• Ask the customer to describe behaviour that must not happen in the desired system.

In the sense of: “If the system does this, then it’s not what I want.” (→ negative use-cases, LSC with pre-chart and hot-false)

• Investigate preconditions, side-conditions, exceptional cases and corner-cases.

(→ extend use-cases, refine LSCs with conditions or local invariants)

• Generalise into universal requirements, e.g., universal LSCs.
• Validate with customer using new positive / negative scenarios.

https://en.wikipedia.org/wiki/Mercedes-Benz_S-Class_%28W221%29#/media/File:Mercedes_W221_driver%27s_door_controls.JPG – Guido Gybels - CC BY-SA 3.0

Strengthening Scenarios Into Requirements

– 9 – 2017-06-19 – Sstrengthen –

43/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

Strengthening Scenarios Into Requirements

– 9 – 2017-06-19 – Sstrengthen –

43/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

• Ask customer for (pos./neg.) scenarios, note down as existential LSCs:

Button Controller position = bottom Motor Sensor down pressed move down bottom reached stop Button Controller position = bottom Motor Sensor down pressed down released move down stop Button Controller position = bottom Motor Sensor down pressed move down false position = bottom

Strengthening Scenarios Into Requirements

– 9 – 2017-06-19 – Sstrengthen –

43/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

• Ask customer for (pos./neg.) scenarios, note down as existential LSCs:

Button Controller position = bottom Motor Sensor down pressed move down bottom reached stop Button Controller position = bottom Motor Sensor down pressed down released move down stop Button Controller position = bottom Motor Sensor down pressed move down false position = bottom

Strengthening Scenarios Into Requirements

– 9 – 2017-06-19 – Sstrengthen –

43/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

• Ask customer for (pos./neg.) scenarios, note down as existential LSCs:

Button Controller position = bottom Motor Sensor down pressed move down bottom reached stop Button Controller position = bottom Motor Sensor down pressed down released move down stop Button Controller position = bottom Motor Sensor down pressed move down false position = bottom

• Strengthen into requirements, note down as universal LSCs:

LSC: move down 1 AM: invariant I: strict Button Controller position = bottom Motor Sensor down pressed move down bottom reached stop ¬down_released LSC: move down 2 AM: invariant I: strict Button Controller position = bottom Motor down pressed down released move down stop ¬bottom_reached LSC: don’t move AM: invariant I: strict Button Controller position = bottom down pressed down released ¬move_down

Strengthening Scenarios Into Requirements

– 9 – 2017-06-19 – Sstrengthen –

43/54

Needs!

Solution! Customer Developer

announcement

(Lastenheft)

→

...e

• prop. 1
• prop. 2

Customer Developer

• ffer

(Pflichtenheft)

→

§

...e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Needs! Developer Customer

software delivery

• Ask customer for (pos./neg.) scenarios, note down as existential LSCs:

Button Controller position = bottom Motor Sensor down pressed move down bottom reached stop Button Controller position = bottom Motor Sensor down pressed down released move down stop Button Controller position = bottom Motor Sensor down pressed move down false position = bottom

• Strengthen into requirements, note down as universal LSCs:

LSC: move down 1 AM: invariant I: strict Button Controller position = bottom Motor Sensor down pressed move down bottom reached stop ¬down_released LSC: move down 2 AM: invariant I: strict Button Controller position = bottom Motor down pressed down released move down stop ¬bottom_reached LSC: don’t move AM: invariant I: strict Button Controller position = bottom down pressed down released ¬move_down

• Re-Discuss with customer using example words of the LSCs’ language.

Analysing LSC Requiremnts

– 9 – 2017-06-19 – Sstrengthen –

44/54 Requirements on Requirements Specications

13/41

A requirements specification should be

• correct

— it correctly represents the wishes/needs of the customer,

• complete

— all requirements (existing in somebody’s head, or a document, or ...) should be present,

• relevant

— things which are not relevant to the project should not be constrained,

• consistent, free of contradictions

— each requirement is compatible with all other requirements; otherwise the requirements are not realisable,

• neutral, abstract

— a requirements specification does not constrain the realisation more than necessary,

• traceable, comprehensible

— the sources of requirements are documented, requirements are uniquely identifiable,

• testable, objective

— the final product can objectively be checked for satisfying a requirement.

• Correctness and completeness are defined relative to something

which is usually only in the customer’s head. is is difficult to be sure of correctness and completeness.

• “Dear customer, please tell me what is in your head!” is in almost all cases not a solution!

It’s not unusual that even the customer does not precisely know...!

For example, the customer may not be aware of contradictions due to technical limitations.

• Definition. [LSC Consistency] A set of LSCs {L1, . . . , Ln} is called consistent

if and only if there exists a set of words W such that n

i=1 W |

= Li.

Content

– 9 – 2017-06-19 – Scontent –

45/54

• Formal Methods in Requirements Engineering
• Software & Software Specification, formally
• Requirements Engineering, formally
• Examples:
• Decision Tables
• Use Cases
• Live Sequence Charts
• LSC Semantics:
• Full LSC syntax
• Activation, Pre-Chart, Chart Mode
• Automaton Construction
• Loop / Progress / Exit Conditions
• LSCs vs. Software
• Excursion: Symbolic Büchi Automata
• Methodology
• Requirements Engineering with scenarios
• Strengthening scenarions into requirements
• Requirements Engineering Wrap-Up

Requirements Engineering Wrap-Up

– 9 – 2017-06-19 – main –

46/54

Topic Area Requirements Engineering: Content

– 9 – 2017-06-19 – Sblockcontent –

47/54

• Introduction
• Requirements Specification
• Desired Properties
• Kinds of Requirements
• Analysis Techniques
• Documents
• Dictionary, Specification
• Specification Languages
• Natural Language
• Decision Tables
• Syntax, Semantics
• Completeness, Consistency, ...
• Scenarios
• User Stories, Use Cases
• Live Sequence Charts
• Syntax, Semantics
• Working Definition: Software
• Discussion

VL 6 . . . VL 7 . . . VL 8 . . . VL 9 . . .

Example: Software Specification

– 9 – 2017-06-19 – Swrapup –

48/54

http://commons.wikimedia.org (CC-by-sa 4.0, Dirk Ingo Franke)

Alphabet:

• M

– dispense cash only,

• C

– return card only,

• M

C

– dispense cash and return card.

• Customer 1: “don’t care”

S1 =

• M.C
• C.M
• M

C

ω

• Customer 2: “you choose, but be consistent”

S2 = (M.C)ω or (C.M)ω

• Customer 3: “consider human errors”

S3 = (C.M)ω

Formal Methods in the Software Development Process

– 9 – 2017-06-19 – Swrapup –

49/54

Customer 2 Mmmh, Software!

Requirements S1 = {(M.C, · 1), (C.M, · 1)}

validate analyse

Formal Methods in the Software Development Process

– 9 – 2017-06-19 – Swrapup –

49/54

Customer 2 Mmmh, Software!

Requirements S1 = {(M.C, · 1), (C.M, · 1)} Design S2 = {(M.TM.C, · 1), (C.TC.M, · 1)}

validate analyse verify analyse

Formal Methods in the Software Development Process

– 9 – 2017-06-19 – Swrapup –

49/54

Customer 2 Mmmh, Software!

Requirements S1 = {(M.C, · 1), (C.M, · 1)} Design S2 = {(M.TM.C, · 1), (C.TC.M, · 1)} Implementation S = {σ0

α1

− − → σ1

α2

− − → σ2 · · · , . . . }

validate analyse verify analyse verify analyse

Formal Methods in the Software Development Process

– 9 – 2017-06-19 – Swrapup –

49/54

Customer 2 Mmmh, Software!

Requirements S1 = {(M.C, · 1), (C.M, · 1)} Design S2 = {(M.TM.C, · 1), (C.TC.M, · 1)} Implementation S = {σ0

α1

− − → σ1

α2

− − → σ2 · · · , . . . } Development Process/ Project Management

validate analyse verify analyse verify analyse

Tell Them What You’ve Told Them. . .

– 9 – 2017-06-19 – Swrapup –

50/54

• A Requirements Specification should be
• correct, complete, relevant, consistent,

neutral, traceable, objective.

• Requirements Representations should be
• easily understandable, precise,

easily maintainable, easily usable.

• Languages / Notations for Requirements Representations:
• Natural Language Patterns
• Decision Tables
• User Stories
• Use Cases
• Live Sequence Charts
• Formal representations
• can be very precise, objective, testable,
• can be analysed for, e.g., completeness, consistency
• can be verified against a formal design description.

(Formal) inconsistency of, e.g., a decision table hints at inconsistencies in the requirements.

Requirements Analysis in a Nutshell

– 9 – 2017-06-19 – Swrapup –

51/54

Requirements Analysis in a Nutshell

– 9 – 2017-06-19 – Swrapup –

51/54

• Customers may not know what they want.
• That’s in general not their “fault”!
• Care for tacit requirements.
• Care for non-functional requirements / constraints.

Requirements Analysis in a Nutshell

– 9 – 2017-06-19 – Swrapup –

51/54

• Customers may not know what they want.
• That’s in general not their “fault”!
• Care for tacit requirements.
• Care for non-functional requirements / constraints.
• For requirements elicitation, consider starting with
• scenarios (“positive use case”) and anti-scenarios (“negative use case”)

and elaborate corner cases.

Thus, use cases can be very useful — use case diagrams not so much.

Requirements Analysis in a Nutshell

– 9 – 2017-06-19 – Swrapup –

51/54

• Customers may not know what they want.
• That’s in general not their “fault”!
• Care for tacit requirements.
• Care for non-functional requirements / constraints.
• For requirements elicitation, consider starting with
• scenarios (“positive use case”) and anti-scenarios (“negative use case”)

and elaborate corner cases.

Thus, use cases can be very useful — use case diagrams not so much.

• Maintain a dictionary and high-quality descriptions.

Requirements Analysis in a Nutshell

– 9 – 2017-06-19 – Swrapup –

51/54

• Customers may not know what they want.
• That’s in general not their “fault”!
• Care for tacit requirements.
• Care for non-functional requirements / constraints.
• For requirements elicitation, consider starting with
• scenarios (“positive use case”) and anti-scenarios (“negative use case”)

and elaborate corner cases.

Thus, use cases can be very useful — use case diagrams not so much.

• Maintain a dictionary and high-quality descriptions.
• Care for objectiveness / testability early on.

Ask for each requirements: what is the acceptance test?

Requirements Analysis in a Nutshell

– 9 – 2017-06-19 – Swrapup –

51/54

• Customers may not know what they want.
• That’s in general not their “fault”!
• Care for tacit requirements.
• Care for non-functional requirements / constraints.
• For requirements elicitation, consider starting with
• scenarios (“positive use case”) and anti-scenarios (“negative use case”)

and elaborate corner cases.

Thus, use cases can be very useful — use case diagrams not so much.

• Maintain a dictionary and high-quality descriptions.
• Care for objectiveness / testability early on.

Ask for each requirements: what is the acceptance test?

• Use formal notations
• to fully understand requirements (precision),
• for requirements analysis (completeness, etc.),
• to communicate with your developers.

Requirements Analysis in a Nutshell

– 9 – 2017-06-19 – Swrapup –

51/54

• Customers may not know what they want.
• That’s in general not their “fault”!
• Care for tacit requirements.
• Care for non-functional requirements / constraints.
• For requirements elicitation, consider starting with
• scenarios (“positive use case”) and anti-scenarios (“negative use case”)

and elaborate corner cases.

Thus, use cases can be very useful — use case diagrams not so much.

• Maintain a dictionary and high-quality descriptions.
• Care for objectiveness / testability early on.

Ask for each requirements: what is the acceptance test?

• Use formal notations
• to fully understand requirements (precision),
• for requirements analysis (completeness, etc.),
• to communicate with your developers.
• If in doubt, complement (formal) diagrams with text

(as safety precaution, e.g., in lawsuits).

Literature Recommendation

– 9 – 2017-06-19 – Swrapup –

52/54

(Rupp and die SOPHISTen, 2014)

References

– 9 – 2017-06-19 – main –

53/54

References

– 9 – 2017-06-19 – main –

54/54 Harel, D. and Marelly, R. (2003). Come, Let’s Play: Scenario-Based Programming Using LSCs and the Play-Engine. Springer-Verlag. Ludewig, J. and Lichter, H. (2013). Software Engineering. dpunkt.verlag, 3. edition. Rupp, C. and die SOPHISTen (2014). Requirements-Engineering und -Management. Hanser, 6th edition.