Lecture 14: UML State Machines & Software Quality Assurance - - PowerPoint PPT Presentation
Softwaretechnik / Software-Engineering Lecture 14: UML State Machines & Software Quality Assurance 2017-07-10 Prof. Dr. Andreas Podelski, Dr. Bernd Westphal Albert-Ludwigs-Universitt Freiburg, Germany 14 2017-07-10 main
– 14 – 2017-07-10 – main –
2017-07-10
Albert-Ludwigs-Universität Freiburg, Germany
– 14 – 2017-07-10 – Sblockcontent –
2/61
(i) views and viewpoints, the 4+1 view (ii) model-driven/-based software engineering (iii) Modelling structure a) (simplified) class diagrams b) (simplified) object diagrams c) (simplified) object constraint logic (OCL) d) Unified Modelling Language (UML)
(i) modularity, separation of concerns (ii) information hiding and data encapsulation (iii) abstract data types, object orientation (iv) Design Patterns
(i) Modelling behaviour a) communicating finite automata b) Uppaal query language c) basic state-machines d) an outlook on hierarchical state-machines
VL 10 . . . VL 11 . . . VL 12 . . . VL 13 . . . VL 14 . . .
– 14 – 2017-07-10 – Scontent –
3/61
– 14 – 2017-07-10 – Srecall –
4/61
Example
– 13 – 2017-07-06 – Scfa –27/55
half_idle request_sent tea_selected soft_selected water_selected idle DOK? OK! water_enabled := false, soft_enabled := false, tea_enabled := false DTEA! DWATER! DSOFT! tea_enabled TEA? soft_enabled SOFT? water_enabled WATER? C50! E1! TEA! SOFT! WATER!
l
ChoicePanel:
(simplified)
User:
Satisfaction of Uppaal Queries by Congurations
– 13 – 2017-07-06 – Suppaal –37/55 Exists finally:
0, 0i | = term iff path of N starting in h~ 0, 0i i N0 • i | = term “some configuration satisfying term is reachable” Example: h~ 0, 0i | =
. . . . . . . . . . . . h~ 0, 0i ¬ ¬ ¬ ¬ ¬ ¬ ¬ 1 2 1,1 2,1 2,2 2,2,1 2,2,2 h~ , i
49/55
and water in stock, that the “water” button is enabled?
NVM | = (CoinValidator.have_c50 or CoinValidator.have_c100 or CoinValidator.have_c150) imply water_enabled.
drink_ready have_c150 have_e1 have_c100 have_c50 idle OK? OK? OK? OK? E1? tea_enabled := (t > 0) C50? water_enabled := (w > 0), tea_enabled := (t > 0) C50? tea_enabled := (t > 0) E1? soft_enabled := (s > 0) C50? soft_enabled := (s > 0) C50? water_enabled := (w>0) – 14 – 2017-07-10 – main –
5/61
– 14 – 2017-07-10 – Scfasw –
6/61
set S of (finite or infinite) computation paths of the form σ0
α1
− → σ1
α2
− → σ2 · · · where
The (possibly partial) function · : S → S is called interpreta- tion of S.
ℓ0, ν0
λ1
− − → ℓ1, ν1
λ2
− − → ℓ2, ν2
λ3
− − → · · · | π is a computation path of C}.
– 14 – 2017-07-10 – Scfasw –
7/61
Customer 2 Mmmh, Software!
Requirements S1 = {(M.C, · 1), (C.M, · 1)} Design S2 = {(M.TM.C, · 1), (C.TC.M, · 1)} S1 = {σ1
α1
1
− − → σ1
1 α1
2
− − → σ1
2 · · · , . . . }
Implementation S2 = {σ2
α2
1
− − → σ2
1 α2
2
− − → σ2
2 · · · , . . . }
Development Process/ Project Management
– 14 – 2017-07-10 – Scontent –
8/61
– 14 – 2017-07-10 – main –
9/61
– 14 – 2017-07-10 – Simpl –
10/61
we would like to have executable software — an implementation of the model.
(i) implement each CFA Ai in the model by module SAi, (ii) implement the communication in the network by module SC.
(This has, by now, been provided implicitly by the Uppaal simulator and verifier.)
SC A1 A2 ... An
calls
– 14 – 2017-07-10 – Simpl –
11/61
∪ Binternal, where Binput are dedicated input channels, i.e. there is no edge with action a! and a ∈ Binput.
SetAct R1 := R1,ini, ..., Rn := Rn,ini ; / / initially enabled actions void main() { do true : (α, snd, rcv) := select(R1, . . . , Rn); / / choose synchronisation / / (rcv = 0 if α = τ, / / blocks on deadlock) for (k =1 to n) if snd = k : Rk := take_actionk(α) / / sender rcv = k : Rk := take_actionk(¯ α) / / receiver fi / / snapshot
}
– 14 – 2017-07-10 – Simpl –
12/61
W0 dispense Wi FILLUP? w := 3 FILLUP? w := 3 w == 0 DOK! w > 0 DOK! DWATER? w := w - 1
int w := 3; typedef {Wi, dispense, W0} st_T; st_T st := Wi; SetAct take_action( Act α ) { SetAct R := ∅; if st = Wi : if α = DWATER? : w := w − 1; st := dispense; if (w = 0) R := R ∪ {DOK!}; if (w > 0) R := R ∪ {DOK!}; α = FILLUP? : w := 3; st := Wi; R := R ∪ {FILLUP?, DWATER?}; fi; st = dispense : if α = DOK! ∧ w = 0 : st := W0; R := R ∪ {FILLUP?}; α = DOK! ∧ w > 0 : st := Wi; R := R ∪ {FILLUP?}; fi; st = W0 : if α = FILLUP? : w := 3; st := Wi; R := R ∪ {FILLUP?, DWATER?}; fi; fi; return R; }
– 14 – 2017-07-10 – Simpl –
13/61 ... for A = ({ℓ1, . . . , ℓm}, B, {v1, . . . , vk}, E, ℓini) with
E = {(ℓ1, α1,1, ϕ1,1, r1,1, ℓ′
1,1), . . . , (ℓ1, α1,n1, ϕ1,n1,
r1,n1, ℓ′
1,n1),
. . . (ℓm, αm,1, ϕm,1, rm,1, ℓ′
m,1), . . . , (ℓm, αm,nm, ϕm,nm,
rm,nm, ℓ′
m,nm)} :
T1 v1 := v1,ini; ...Tk vk := vk,ini; typedef {ℓ1 , . . . , ℓm} st_T; st_T st := ℓini; SetAct take_action( Act α ) { SetAct R := ∅; if . . . st = ℓi : if . . . α = αi,j ∧ ϕi,j : ri,j; st := ℓ′
i,j;
if (ℓ′
i,j = ℓ1 ∧ ϕ1,1) R := R ∪ {α1,1};
. . . if (ℓ′
i,j = ℓm ∧ ϕm,nm) R := R ∪ {αm,nm};
. . . fi; . . . fi; return R; }
– 14 – 2017-07-10 – Simpl –
14/61
and only if each reachable configuration has at most one successor configuration, i.e. if ∀ c ∈ Conf (C) reachable ∀ λ ∈ B!? ∪ {τ} ∀ c1, c2 ∈ Conf (C) • c
λ
− → c1 ∧ c
λ
− → c2 = ⇒ c1 = c2.
– 14 – 2017-07-10 – Simpl –
15/61
α1
− − → σ1
α2
− − → σ2 · · · such that σi has the values at ‘snapshot’ at the i-th iteration and αi is the i-th action.
FILLUP! C50! WATER!
half_idle water_selected have_c50 idle DWATER! DOK? WATER? C50? W0 dispense Wi FILLUP? w := 3 FILLUP? w := 3 w == 0 DOK! w > 0 DOK! DWATER? w := w - 1
– 14 – 2017-07-10 – Simpl –
15/61
α1
− − → σ1
α2
− − → σ2 · · · such that σi has the values at ‘snapshot’ at the i-th iteration and αi is the i-th action.
FILLUP! C50! WATER!
half_idle water_selected have_c50 idle DWATER! DOK? WATER? C50? W0 dispense Wi FILLUP? w := 3 FILLUP? w := 3 w == 0 DOK! w > 0 DOK! DWATER? w := w - 1
= ∃♦ w = 0 holds, then w = 0 (should be) reachable in SNVM.
= ∀ tea_enabled imply CoinValidator.have_c150 holds, then SNVM (should be) correspondingly safe.
then there is an issue with the model, or the requirement (or the checking tool) to be investigated.
– 14 – 2017-07-10 – Smdse –
16/61
Idea Structure Declarative Behaviour
Behaviour′
Constructive Behaviour
Constructive Behaviour′
elicit refine refine refine refine
requirements model requirements/ constraints design system model | =? | =?
generate/ program
– 14 – 2017-07-10 – Scontent –
17/61
– 14 – 2017-07-10 – main –
18/61
– 14 – 2017-07-10 – Scfawfas –
19/61
(Arenis et al., 2014) Components
Jammer Switcher gBlockedChannel gOffSensor / gOffRepeater
Media . . . Master
Frame Window
Timers
SlotTimer RX Channels TX Channels FrameTimer
. . .
errorDetected channel ChanRot channelLZ, ...
!%
&
$! '!"$ !"'!"$ ' ("!'!"$ % !"!#$ !) $*! !' !"!#$ !"!
* ",-. + !"! + + !) * ",-. + !"! * ",-. +% !"!
(R1) The loss of the ability of the system to transmit a signal from a component to the central unit is detected in less than 300 seconds [...].
⇒ ℓ ≤ 300s)
(R2) A single alarm event is displayed at the central unit within 10 seconds.
⇒ (⌈ALARMi ∧ ¬DISPi⌉ = ⇒ ℓ ≤ 10s) ,
– 14 – 2017-07-10 – Scfawfas –
20/61
Monitoring Templates Instances Total Locations Clocks Sensors as slaves 9 137 1040 6 Repeaters as slaves 9 21 82 6 Sensors as slaves, N = 126. Repeaters as slaves, N = 10. Query seconds MB States explored seconds MB States explored Q1 Detection possible 10,205.13 557.00 26,445,788 38.21 55.67 1,250,596
E<> switcher.DETECTION
Q2 No message collision 12,895.17 2,343.00 68,022,052 368.58 250.91 9,600,062
A[] not deadlock
Q3 DetectT 36,070.78 3,419.00 190,582,600 231.84 230.59 6,009,120
A[] (switcher.DETECTION imply switcher.timer <= 300*Second)
Q4 NoSpurT 97.44 44.29 640,943 3.94 10.14 144,613
A[] !center.ERROR
Verification of the final design (Opteron 6174 2.2Ghz, 64GB, Uppaal 4.1.3 (64-bit), options -s -t0 -u).
Model sequential Model
Model test scenario Measured Avg. First Alarm 3.26s 2.14s 3.31s 2.79s ± 0.53s All 10 Alarms 29.03s 27.08s 29.81s 29.65s ± 3.26s Predicted alarm transmission times vs. Measurements on real hardware.
– 14 – 2017-07-10 – Scfawfas –
21/61
– 14 – 2017-07-10 – Scfawfas –
22/61
– 14 – 2017-07-10 – Scontent –
23/61
– 14 – 2017-07-10 – main –
24/61
– 14 – 2017-07-10 – Sumlstm –
25/61
C D
x : Int = 27 itsD 0..1 itsC 0..1
s1 s2
E/itsD ! F G
s1 s2
F[x > 0]
s3
/itsC ! G /x := 0 annot ::=
[ [ guard ] ] [ / action]
(optional)
(default: true, assumed to be in ExprS )
(default: skip, assumed to be in ActS )
– 14 – 2017-07-10 – Sumlstm –
26/61 s1 s2
E/itsD ! F G
s1 s2
F[x > 0]
s3
/itsC ! G /x := 0
u1 : C
state : {s1, s2} stable : Bool
u2 : D x = 27
state : {s1, s2, s3} stable : Bool
itsD itsC
u1 u2 step state stable x state stable event pool s1 1 27 s1 1 E ready for u1
– 14 – 2017-07-10 – Sumlstm –
26/61 s1 s2
E/itsD ! F G
s1 s2
F[x > 0]
s3
/itsC ! G /x := 0
u1 : C
state : {s1, s2} stable : Bool
u2 : D x = 27
state : {s1, s2, s3} stable : Bool
itsD itsC
u1 u2 step state stable x state stable event pool s1 1 27 s1 1 E ready for u1 1 s2 1 27 s1 1 F ready for u2
– 14 – 2017-07-10 – Sumlstm –
26/61 s1 s2
E/itsD ! F G
s1 s2
F[x > 0]
s3
/itsC ! G /x := 0
u1 : C
state : {s1, s2} stable : Bool
u2 : D x = 27
state : {s1, s2, s3} stable : Bool
itsD itsC
u1 u2 step state stable x state stable event pool s1 1 27 s1 1 E ready for u1 1 s2 1 27 s1 1 F ready for u2 2 s2 1 27 s2
– 14 – 2017-07-10 – Sumlstm –
26/61 s1 s2
E/itsD ! F G
s1 s2
F[x > 0]
s3
/itsC ! G /x := 0
u1 : C
state : {s1, s2} stable : Bool
u2 : D x = 27
state : {s1, s2, s3} stable : Bool
itsD itsC
u1 u2 step state stable x state stable event pool s1 1 27 s1 1 E ready for u1 1 s2 1 27 s1 1 F ready for u2 2 s2 1 27 s2 3 s2 1 27 s3 G ready for u1
– 14 – 2017-07-10 – Sumlstm –
26/61 s1 s2
E/itsD ! F G
s1 s2
F[x > 0]
s3
/itsC ! G /x := 0
u1 : C
state : {s1, s2} stable : Bool
u2 : D x = 27
state : {s1, s2, s3} stable : Bool
itsD itsC
u1 u2 step state stable x state stable event pool s1 1 27 s1 1 E ready for u1 1 s2 1 27 s1 1 F ready for u2 2 s2 1 27 s2 3 s2 1 27 s3 G ready for u1 4.a s2 1 s1 1 G ready for u1
– 14 – 2017-07-10 – Sumlstm –
26/61 s1 s2
E/itsD ! F G
s1 s2
F[x > 0]
s3
/itsC ! G /x := 0
u1 : C
state : {s1, s2} stable : Bool
u2 : D x = 27
state : {s1, s2, s3} stable : Bool
itsD itsC
u1 u2 step state stable x state stable event pool s1 1 27 s1 1 E ready for u1 1 s2 1 27 s1 1 F ready for u2 2 s2 1 27 s2 3 s2 1 27 s3 G ready for u1 4.a s2 1 s1 1 G ready for u1 5.a s1 1 s1 1
– 14 – 2017-07-10 – Sumlstm –
26/61 s1 s2
E/itsD ! F G
s1 s2
F[x > 0]
s3
/itsC ! G /x := 0
u1 : C
state : {s1, s2} stable : Bool
u2 : D x = 27
state : {s1, s2, s3} stable : Bool
itsD itsC
u1 u2 step state stable x state stable event pool s1 1 27 s1 1 E ready for u1 1 s2 1 27 s1 1 F ready for u2 2 s2 1 27 s2 3 s2 1 27 s3 G ready for u1 4.a s2 1 s1 1 G ready for u1 5.a s1 1 s1 1 4.b s1 1 27 s3
– 14 – 2017-07-10 – Sumlstm –
26/61 s1 s2
E/itsD ! F G
s1 s2
F[x > 0]
s3
/itsC ! G /x := 0
u1 : C
state : {s1, s2} stable : Bool
u2 : D x = 27
state : {s1, s2, s3} stable : Bool
itsD itsC
u1 u2 step state stable x state stable event pool s1 1 27 s1 1 E ready for u1 1 s2 1 27 s1 1 F ready for u2 2 s2 1 27 s2 3 s2 1 27 s3 G ready for u1 4.a s2 1 s1 1 G ready for u1 5.a s1 1 s1 1 4.b s1 1 27 s3 5.b s1 1 s1 1
– 14 – 2017-07-10 – Sumlstm –
27/61
– 14 – 2017-07-10 – Sumlstm –
27/61
C.h D.h C.cpp D.cpp MainDefaultComponent.cpp
DfltCmp.exe
generate build / make (compiler) run E! go
“D just stepped from s1 to s2 by transition t”
– 14 – 2017-07-10 – Sumlstm –
28/61
n
e s resigned X/ X/ X/ X/
e s resigned X/ n fastN
fastW e fastE s fastS F/ F/
e s
fast F/ F/
– 14 – 2017-07-10 – Sumlstm –
29/61
Idle waitOK have_c100_or_e1> have_c100 have_e1 have_c150> have_c50> drinkReady Idle waitOK have_c100_or_e1> have_c100 have_e1 have_c150> have_c50> drinkReady E1/itsChanger
C50/itsChoicePanel
E1/ itsChanger
C50 C50/ itsChanger
C50 E1/itsChoicePanel->enableSoft(); E1 C50 OK Entry Action: itsChoicePanel
Entry Action: itsChoicePanel
Entry Action: itsChoicePanel
Tea_selected Inactive Soft_selected Water_selected Request_sent Tea_selected Inactive Soft_selected Water_selected Request_sent TEA[Tea_enabled] /itsDrinkDispenser
/itsDrinkDispenser
if (itsCoinValidator
itsChanger->giveback_50(); WATER[Water_enabled] /disable_all(); SOFT[Soft_enabled] /itsDrinkDispenser
if (itsCoinValidator->IS_IN(have_c150)) itsChanger->giveback_100(); else if (itsCoinValidator->IS_IN(have_c100)) itsChanger->giveback_50();
T2 Tea_out T1 T3 S2 Soft_out S1 S3 W2 Water_out W1 W3 FillingUp
T2 Tea_out T1 T3 S2 Soft_out S1 S3 W2 Water_out W1 W3 FillingUp DTEA/ Prepare_Tea(); itsCoinValidator
DTEA/ Prepare_Tea(); itsCoinValidator
DTEA/ Prepare_Tea(); itsCoinValidator
DSOFT/ Prepare_Soft(); itsCoinValidator
DSOFT/ Prepare_Soft(); itsCoinValidator
DSOFT/ Prepare_Soft(); itsCoinValidator
DWATER/ Prepare_Water(); itsCoinValidator
DWATER/ Prepare_Water(); itsCoinValidator
DWATER/ Prepare_Water(); itsCoinValidator
FILLUP/itsCoinValidator
– 14 – 2017-07-10 – Sumlstm –
30/61
s2
s8 s4
s6
E/ F/ F/ E/ G/
s7 [true]/ F/ → “Software Design, Modelling, and Analysis with UML” in some winter semesters.
– 14 – 2017-07-10 – Scontent –
31/61
– 14 – 2017-07-10 – Sumloutlook –
32/61
— Idea: learn from engineering disciplines to handle growing complexity.
Modelling languages: Flowcharts, Nassi-Shneiderman, Entity-Relation Diagrams
— Inflation of notations and methods, most prominent:
– 14 – 2017-07-10 – Sumloutlook –
32/61
— Idea: learn from engineering disciplines to handle growing complexity.
Modelling languages: Flowcharts, Nassi-Shneiderman, Entity-Relation Diagrams
— Inflation of notations and methods, most prominent:
(Rumbaugh et al., 1990)
http://wikimedia.org (CC nc-sa 3.0, User:AutumnSnow) http://wikimedia.org (CC nc-sa 3.0, User:AutumnSnow)
– 14 – 2017-07-10 – Sumloutlook –
32/61
— Idea: learn from engineering disciplines to handle growing complexity.
Modelling languages: Flowcharts, Nassi-Shneiderman, Entity-Relation Diagrams
— Inflation of notations and methods, most prominent:
(Rumbaugh et al., 1990)
(Booch, 1993)
http://wikimedia.org (Public domain, Johannes Fasolt)
– 14 – 2017-07-10 – Sumloutlook –
32/61
— Idea: learn from engineering disciplines to handle growing complexity.
Modelling languages: Flowcharts, Nassi-Shneiderman, Entity-Relation Diagrams
— Inflation of notations and methods, most prominent:
(Rumbaugh et al., 1990)
(Booch, 1993)
(Jacobson et al., 1992)
use case model domain object model analysis model design model
class...
implementation model
...
testing model
may be expressed in terms of structured by realized by implemented by tested in
Each “persuasion” selling books, tools, seminars...
– 14 – 2017-07-10 – Sumloutlook –
32/61
— Idea: learn from engineering disciplines to handle growing complexity.
Modelling languages: Flowcharts, Nassi-Shneiderman, Entity-Relation Diagrams
— Inflation of notations and methods, most prominent:
(Rumbaugh et al., 1990)
(Booch, 1993)
(Jacobson et al., 1992) Each “persuasion” selling books, tools, seminars...
Standards published by Object Management Group (OMG), “international, open membership, not-for-profit computer industry consortium”. Much criticised for lack of formality.
– 14 – 2017-07-10 – Sumloutlook –
33/61
Figure A.5 - The taxonomy of structure and behavior diagram
Diagram Structure Diagram Behavior Diagram Interaction Diagram Use Case Diagram Activity Diagram Composite Structure Diagram Class Diagram Component Diagram Deployment Diagram Sequence Diagram Interaction Overview Diagram Object Diagram State Machine Diagram Package Diagram Communication Diagram Timing Diagram
OCL
Dobing and Parsons (2006)
– 14 – 2017-07-10 – main –
34/61
– 14 – 2017-07-10 – Sumlmode –
35/61
Recall: definition “model” (Glinz, 2008, 425): (iii) the pragmatic attribute, i.e. the model is built in a specific context for a specific purpose. Examples for context/purpose: Floorplan as sketch: Floorplan as blueprint: Floorplan as program: +
wiringplan
+
windows
+
...
– 14 – 2017-07-10 – Sumlmode –
36/61
The last slide is inspired by Martin Fowler, who puts it like this: “[...] people differ about what should be in the UML because there are differing fundamental views about what the UML should be. I came up with three primary classifications for thinking about the UML: UmlAsSketch, UmlAsBlueprint, and UmlAsProgrammingLanguage. ([...] S. Mellor independently came up with the same classifications.) So when someone else’s view of the UML seems rather different to yours, it may be because they use a different UmlMode to you.” Claim:
– 14 – 2017-07-10 – Sumlmode –
36/61
The last slide is inspired by Martin Fowler, who puts it like this: “[...] people differ about what should be in the UML because there are differing fundamental views about what the UML should be. I came up with three primary classifications for thinking about the UML: UmlAsSketch, UmlAsBlueprint, and UmlAsProgrammingLanguage. ([...] S. Mellor independently came up with the same classifications.) So when someone else’s view of the UML seems rather different to yours, it may be because they use a different UmlMode to you.” Claim:
Sketch In this UmlMode developers use the UML to help communicate some aspects of a system. [...] Sketches are also useful in documents, in which case the focus is communication ra- ther than completeness. [...] The tools used for sketching are lightweight drawing tools and
particular about keeping to every strict rule of the UML. Most UML diagrams shown in books, such as mine, are sketches. Their emphasis is on selective communication rather than complete specification. Hence my sound-bite “compre- hensiveness is the enemy of comprehensibility” Blueprint [...] In forward engineering the idea is that blueprints are developed by a designer whose job is to build a detailed design for a programmer to code up. That design should be sufficiently complete that all design decisions are laid out and the programming should follow as a pretty straightforward activity that requires little thought. [...] Blueprints require much more sophisticated tools than sketches in order to handle the details required for the task. [...] Forward engineering tools sup- port diagram drawing and back it up with a repository to hold the
ProgrammingLanguage If you can detail the UML enough, and provide semantics for everything you need in software, you can make the UML be your programming language. Tools can take the UML diagrams you draw and compile them into executable code. The promise of this is that UML is a higher level language and thus more productive than current programming languages. The question, of course, is whether this promise is true. I don’t believe that graphical programming will succeed just because it’s graphical. [...]
– 14 – 2017-07-10 – Sumlmode –
37/61
Goal:
Yet we tried to be consistent with the (informal semantics) from the standard documents OMG (2007a,b) as far as possible.
Plus:
Knowing “the real thing” should make it easier to (i) “see” which blueprint(s) the sketch is supposed to denote, and (ii) to ask meaningful questions to resolve ambiguities.
– 14 – 2017-07-10 – Sttwytt –
38/61
verify code against model.
yet provide more convenient syntax.
in contrast to CFA.
(We could define the same for CFA, but then the Uppaal simulator would not be useful any more.)
– 14 – 2017-07-10 – main –
39/61
– 14 – 2017-07-10 – Sblockcontent2 –
40/61
in a larger scope.
VL 14 . . . VL 15 . . . VL 16 . . . VL 17 . . .
– 14 – 2017-07-10 – Scontent2 –
41/61
– 14 – 2017-07-10 – main –
42/61
– 14 – 2017-07-10 – Stestquotes –
43/61 “Testing is the execution of a program with the goal to discover errors.”
(G. J. Myers, 1979)
“Testing is the demonstration of a program or system with the goal to show that it does what it is supposed to do.”
(W. Hetzel, 1984)
“Software testing can be used to show the presence of bugs, but never to show their absence!”
(E. W. Dijkstra, 1970)
Rule-of-thumb: (fairly systematic) tests discover half of all errors.
(Ludewig and Lichter, 2013)
– 14 – 2017-07-10 – Stestintro –
44/61
Recall:
infinite) computation paths of the form σ0
α1
− − → σ1
α2
− − → σ2 · · · where
The (possibly partial) function · : S → S is called interpretation of S.
there are Σin and Σout such that Σ = Σin × Σout.
π = σi σo
− − → σi
1
σo
1
− − → · · ·
α1
− − → σi
1 α2
− − → · · · , i.e. the projection of π onto Σin.
– 14 – 2017-07-10 – Stestintro –
45/61
and an interpretation · of these descriptions:
Soll ⊆ (Σ × A)∗ ∪ (Σ × A)ω
Examples:
T = (s = "abc", r = 3) s = "abc" = {σi
τ
− → σi
1 | σ0(s) = "abc"},
r = 3 = {σ0
τ
− → σ1 | σ1(r) = 3}, Shorthand notation: T = ("abc", 3).
– 14 – 2017-07-10 – Stestintro –
45/61
and an interpretation · of these descriptions:
Soll ⊆ (Σ × A)∗ ∪ (Σ × A)ω
Examples:
T = (C50, WATER; DWATER) C50, WATER = {σi
C50
− − → σi
1 τ
− → · · ·
τ
− → σi
j−1 WATER
− − − − − → σi
j},
DWATER = {σ0
α1
− − → · · ·
αk
− − → σk−1
DWATER
− − − − − − → σk | k ≤ 10},
– 14 – 2017-07-10 – Stestintro –
45/61
and an interpretation · of these descriptions:
Soll ⊆ (Σ × A)∗ ∪ (Σ × A)ω
Note:
– 14 – 2017-07-10 – Stestintro –
46/61
π = σi σo
− − → σi
1
σo
1
− − → · · · from S is called execution of test case (In, Soll ) if and only if
α1
− − → . . .
αn
− − → σn ↓ Σin ∈ In.
(“A prefix of π corresponds to an input sequence”).
Execution π of test case T is called
∈ Soll.
– 14 – 2017-07-10 – Stestintro –
47/61
T = ("", 0) for procedure strlen.
(“Empty string has length 0.”)
π = {s → NULL, r → 0}
τ
− → program-abortion
– 14 – 2017-07-10 – Stestintro –
48/61
and “complain” if operated outside of specification, e.g.
Not: “garbage in, garbage out”
– 14 – 2017-07-10 – Stestintro –
49/61
such that there is at least one execution for each test case.
if and only if at least one test case execution is positive. Otherwise, it is called negative.
– 14 – 2017-07-10 – Sttwytt2 –
59/61
– 14 – 2017-07-10 – main –
60/61
– 14 – 2017-07-10 – main –
61/61 Arenis, S. F., Westphal, B., Dietsch, D., Muñiz, M., and Andisha, A. S. (2014). The wireless fire alarm system: Ensuring conformance to industrial standards through formal verification. In Jones, C. B., Pihlajasaari, P., and Sun, J., editors, FM 2014: Formal Methods - 19th International Symposium, Singapore, May 12-16, 2014. Proceedings, volume 8442 of LNCS, pages 658–672. Springer. Arenis, S. F., Westphal, B., Dietsch, D., Muñiz, M., Andisha, A. S., and Podelski, A. (2016). Ready for testing: ensuring conformance to industrial standards through formal verification. Formal Asp. Comput., 28(3):499–527. Booch, G. (1993). Object-oriented Analysis and Design with Applications. Prentice-Hall. Dobing, B. and Parsons, J. (2006). How UML is used. Communications of the ACM, 49(5):109–114. Glinz, M. (2008). Modellierung in der Lehre an Hochschulen: Thesen und Erfahrungen. Informatik Spektrum, 31(5):425–434. Harel, D. (1987). Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8(3):231–274. Harel, D., Lachover, H., et al. (1990). Statemate: A working environment for the development of complex reactive systems. IEEE Transactions on Software Engineering, 16(4):403–414. Jacobson, I., Christerson, M., and Jonsson, P. (1992). Object-Oriented Software Engineering - A Use Case Driven
Ludewig, J. and Lichter, H. (2013). Software Engineering. dpunkt.verlag, 3. edition. OMG (2007a). Unified modeling language: Infrastructure, version 2.1.2. Technical Report formal/07-11-04. OMG (2007b). Unified modeling language: Superstructure, version 2.1.2. Technical Report formal/07-11-02.