refinement – formal design withformal design with sequence ... · 9/24/2010 · refinement –...
TRANSCRIPT
Refinement formal design withRefinement – formal design with sequence diagrams
Ketil Stølen SINTEF & University of Oslo
September 24, 2010
ICT
OverviewOverview
Obligatory Exercise No 1Obligatory Exercise No. 1 Motivation
How can we incrementally develop UML specificationsHow can we incrementally develop UML specifications
Requirements to STAIRSWhat should we require from a stepwise method for developingWhat should we require from a stepwise method for developing UML specifications
Explanation through an exampleA Dinner Restaurant
RefinementComparison with traditional pre-post paradigm
ICT
Obligatory Exercise No 1Obligatory Exercise No. 1
Should be solved individually by each studentShould be solved individually by each studentRefinement exam from last year
The deadline is October 4, 10.00 AMYou should send your individual solutions by email toYou should send your individual solutions by email to [email protected] as an attachment in pdf-format
October 6: We will walk through the obligatory exercise and return the individual solutions in the group session October 6individual solutions in the group session October 6Some selected individuals will have to explain their solutions orally
ICT
MotivationMotivation
Exploit classical theory of refinement in a practical UMLExploit classical theory of refinement in a practical UML setting
From theory to practice and not the other way aroundFrom theory to practice, and not the other way around
Briefly summarized: we aim to explain how classical theory of refinement can be applied to refine specifications y pp pexpressed with the help of sequence diagrams Sequence diagrams can be used to capture the meaning of other UML description techniques for behaviorBy defining refinement for sequence diagrams we therefore implicitly define refinement for UML
ICT
Requirements to STAIRSRequirements to STAIRS
Should allow specification of potential behaviorShould allow specification of potential behaviorSupport for under-specification
Should allow specification of mandatory behaviorShould allow specification of mandatory behaviorSupport for information hiding (inherent non-determinism, unpredictability)
Should allow specification of negative behavior in addition to positive behavior
Support for threat modeling
Should capture the notion of refinementShould formalize incremental developmentShould support compositional analysis, verification and t ti
ICT
testing
Sequence diagramSequence diagrammessage
instance-li component
d S
line p
sd SL1 L2
x
output event
input event
ICT
!x ?x
Weak sequencingWeak sequencing
sd Wsd WL1 L2
x
y
<!x,?x,!y,?y><!x,!y,?x,?y>
ICT
!x,!y,?x,?y
TracesTraces
Traces are used to capture executions (behaviors) semanticallyTraces are used to capture executions (behaviors) semanticallyWithin the field of formal methods there are many variants of tracesIn STAIRS traces are sequences of events
<e1, e2, e3, e4, e4, e1, e2, e5, ……………>
A t t ith th t i i ti fAn event represent either the transmission or reception of messages?m - reception of message m!m - transmission of message m
E t i t tEvents are instantaneousA trace may be finite
termination, deadlock, infinite waiting, crashA l b i fi iA trace may also be infinite
infinite loop, intended non termination
ICT
Examplesd Ex
Example
A B Cab
cd
This sequence diagram has six traces:
<!a, ?a, !b, ?b, !c, ?c, !d, ?d> <!a, ?a, !b, ?b, !c, !d, ?c, ?d> <!a, ?a, !b, ?b, !d, !c, ?c, ?d>!a, ?a, !b, ?b, !d, !c, ?c, ?d <!a, ?a, !b, !c, ?b, ?c, !d, ?d> <!a, ?a, !b, !c, ?b, !d, ?c, ?d> <!a ?a !b !c ?c ?b !d ?d>
ICT
<!a, ?a, !b, !c, ?c, ?b, !d, ?d>
AlternativeAlternative
sd AL1 L2
xalty
ICT
Parallel executionParallel execution
sd Psd PL1 L2
xpary
ICT
Interaction overview diagramInteraction overview diagramsd IOD
ref S
ref IO ref W
S seq (IO par W) seq (IO alt W)
ref IO ref W
ref IO ref W
ICT
DinnerDinnersd Dinner
a Salad as a starter
ref Saladthen a main course
consisting of an Entree
sd Entree sd SideOrder
and SideOrder in parallel
choicesh i
ref Vegetarian
ref Beef
ref Baked Potato
ref Rice
choices
Beef
ref Pork
Rice
ref Frites
ICT
Some potential positive traces of Beef
sd BeefCook Stove Refrigerator
main dish please
turn on heat
fetch_meat()
f t h t() i l i
heat is adequate
fetch_meat():sirloin
put on grill (sirloin)
fetch_meat()
fetch_meat():sirloinmain dish:sirloin
ICT
STAIRS semantics: simple caseSTAIRS semantics: simple case
Each positive execution is represented by a traceEach positive execution is represented by a traceEach negative execution is represented by a traceTh ti f di i i f t fThe semantics of a sequence diagram is a pair of sets of traces (Positive, Negative)
Positive
Inconclusive
Negative
Inconclusive
All other traces over the actual alphabet of events are inconclusive
ICT
inconclusive
Potential negative Beef experiencesPotential negative Beef experiencessd Beef
Cook Stove RefrigeratorCook Stove Refrigeratormain dish please
turn on heat
fetch_meat()
fetch_meat():sirloin
heat is adequate
negative traces put on grill (sirloin)
neg smell of burned meat
Beef with French fries
Turkey entree
Positive traces
fetch_meat()
fetch_meat():sirloinmain dish:sirloin
Turkey entree
Forgotten Sirloin
Inconclusive traces
ICT
Burned SirloinNegative traces
Pre-post specificationsPre post specificationsPre-post specifications are based on the assumption-guarantee paradigm
Integer division
var dividend divisor quotient rest : Natvar dividend, divisor, quotient, rest : Nat
A ti b t th t t t thpre divisor≠ 0Assumption about the state at the moment the execution is initiated
Guarantee with respect to the state at the moment oftermination
post ( dividend = (quotient’ * divisor) + rest’ ) &
rest’ < divisor
ICT
Semantics of pre-post specificationsSemantics of pre post specificationsLegal
pre false initially
pre true initially
systembehavior
y y
no constraints
post true at terminationconstraints
on state at termination
post false atpost false at termination
IllegalLegal, Illegalsystem
behavior
but arbitrarybehavior
ICT
Comparing STAIRS with pre-postComparing STAIRS with pre post
pre=false pre=truepre=false pre true assumption
guarantee
post=true positive
inconclusive
post=false negative
ICT
Refinement in pre-postRefinement in pre postStrengthening postWeakening preWeakening pre
pre false initially
pre true initially
pre sann i
no constraint
post true at termination
pre sann i starttilstand
post sann i det øyeblikk operasjonen terminerer
on state at termination post false at
terminationoperasjonen terminerertermination
ICT
STAIRS: supplementingSTAIRS: supplementing
Supplementing involves reducing the set of inconclusiveSupplementing involves reducing the set of inconclusive traces by redefining inconclusive traces as either positive or negativeor negativePositive trace remains positiveNegative trace remains negativeNegative trace remains negative
Beef with French friesPositive tracesBeef with FF
Turkey entree
Inconclusive traces
Turkey entreesupplementing
Burned Sirloin
Forgotten Sirloin
Negative traces
Forgotten SirloinBurned Sirloin
ICT
Supplementing in pre-postSupplementing in pre postweakening the assumption
pre=false pre=truepre=false pre true assumption
guarantee
post=true positive
inconclusive
post=false negative
ICT
STAIRS: narrowingSTAIRS: narrowing
Narrowing involves reducing the set of positive traces byNarrowing involves reducing the set of positive traces by redefining them as negativeInconclusive traces remain inconclusiveInconclusive traces remain inconclusiveNegative traces remain negative
Indian Restaurant
Positive tracesin sets of traces
VegetarianBeef
Inconclusive traces
narrowingVegetarian
Pork Vegetarian Pork
Negative traces
Inconclusive traces
Beef
ICT
Narrowing in pre-postNarrowing in pre post
pre=false pre=truepre=false pre true assumption
post=true positivepost=true positive
inconclusivestrengthening theguarantee
guaranteepost=false negative
ICT
Indirect definition: Refinement in STAIRSIndirect definition: Refinement in STAIRS
A sequence diagram B is a general refinement of aA sequence diagram B is a general refinement of a sequence diagram A if
A and B are semantically identicalB can be obtained from A by supplementingy pp gB can be obtained from A by narrowingB can be obtained from A by a finite number of steps
A -> C1 -> C2 -> …. ->Cn->Beach of which is either a supplementing or a narrowing
ICT
Is B a refinement of A?
S T
sd A
S T
sd B
e
bc
e
bcc c
ICT
Is B a refinement of A?
S T
sd A
S T
sd B
e
bc
e
cbc b
ICT
Is B a refinement of A?Is B a refinement of A?
S T
sd A
S T
sd B
e
bc
e
b
alt
cc
d
k
f
ICT
Is B a refinement A?Is B a refinement A?
S T
sd A
S T
sd B
e
bc
e
bcc
d
k
f
ICT
Is B a refinement of A?Is B a refinement of A?
S T
sd A
S T
sd B
e
bc
e
bc
ICT
DIRECT DEFINITION: Refinement in STAIRS
A sequence diagram B is a refinement of a sequenceA sequence diagram B is a refinement of a sequence diagram A if
every trace classified as negative by A is also classified as negative by Bevery trace classified as positive by A is classified as either positive or negative by B
ICT
Refinement in STAIRSRefinement in STAIRS
PositivePositive
InconclusiveSupplementing Narrowing
Negative
An interaction obligation o'=(p',n') is a refinement of an interaction obligation o=(p n) iffobligation o=(p,n) iff
n n'p p'Un'⊆⊆
ICT
Underspecification and non-determinismUnderspecification and non determinism
Underspecification: Several alternative behaviours areUnderspecification: Several alternative behaviours are considered equivalent (serve the same purpose).Inherent non determinism: Alternative behaviours thatInherent non-determinism: Alternative behaviours that must all be possible for the implementation.
These two should be described differently!
ICT
The need for both alt and xaltThe need for both alt and xalt
Potential non-determinism captured by alt allows abstraction and inessential non determinismabstraction and inessential non-determinism
Under-specificationNon-critical design decisions may be postponedg y p p
Mandatory non-determinism captured by xalt characterizes non-determinism that must be reflected in every correct implementation
M k it ibl t ifMakes it possible to specify gamesImportant in relation to securityAlso helpful as a means of abstraction
ICT
Also helpful as a means of abstraction
Restaurant example with both alt and xalt
Entree menus must have the choice of Vegetarian or Meat
sd Dinner-2 ref Salad
Vegetarian or Meat
sd Entree sd SideOrderxalt alt
ref Vegetarian
ref B f ref P k
ref Baked Potato
ref Rice
alt
ref Beef ref Pork Rice
ref Frites
Meat may be either Beef or Pork but menus need not have
ICT
Pork, but menus need not have both choices
STAIRSSTAIRSPositive
P iti
N ti
InconclusivePositive
InconclusivePositive
NegativeNegative
Negative
Inconclusive
P iti
g
xalt
Positive
Positive
Inconclusive
Positive
Inconclusive
Negative
InconclusiveNegative Negative
Inconclusive
ICT
Negative
alt vs xaltalt vs xalt
AssumeAssume[[ d1 ]] = {(p1,n1)} [[ d2 ]] = {(p2,n2)}
alt specifies potential behaviour:alt specifies potential behaviour:[[ d1 alt d2 ]]= [[ d1 ]] + [[ d2 ]] P1 U P2[[ ]] [[ ]]= {(p1 U p2, n1 U n2)}
xalt specifies mandatory behaviour: N1 U N2
I
[[ d1 xalt d2 ]]= [[ d1 ]] U [[ d2 ]]
{(p1 n1)} U {(p2 n2)} P1 P2= {(p1,n1)} U {(p2,n2)}I1 I2
ICT
N1 N2
Example: Network communicationExample: Network communication
cs C
A :sen d er S :n etw o rk B :rece iver
cs SN 1:N
G :N
N 2:N
N 3:NG :N
N 4:N
ICT
alt vs xalt S:networkalt vs xalt S:networksd S_Comm
N1:N N2:N N3:N N4:NG:NA:sender B:receiverm
mmxalt
m
m
malt
m m
A->G->N1->B A->G->N2->N3->BA->G->N2->N4->B
Everything else
A->G->N2->N4->B
Everything else
ICT
Mandatory requirements STAIRSMandatory requirements STAIRS
Haugen Husa Runde Stølen: STAIRS towards formalHaugen, Husa, Runde, Stølen: STAIRS towards formal design with sequence diagrams, 2005. SoSyM, Springer.Runde Haugen Stølen: The Pragmatics of STAIRSRunde, Haugen, Stølen: The Pragmatics of STAIRS, 2006. Springer-Verlag. LNCS 4111.
NOTE:N F id R fi IIINext Friday: Refinement III
ICT