http://cfs uml-b & u2b colin snook & michael butler university of southampton colin snook...
Post on 19-Dec-2015
214 views
TRANSCRIPT
http://www.ecs.soton.ac.uk/~cfs
UML-B
&
U2B
UML-B
&
U2B
Colin Snook & Michael ButlerUniversity of Southampton
Colin Snook & Michael ButlerUniversity of Southampton
http://www.ecs.soton.ac.uk/~cfs
Contents
Contents
MotivationBackground: B, event systems & event BProblems translating UML to BIntroduction to UML-B and U2B (in event mode)Decomposition in UML-B (in event mode)Subsystem design to code or circuit synthesisFuture WorkConclusions
MotivationBackground: B, event systems & event BProblems translating UML to BIntroduction to UML-B and U2B (in event mode)Decomposition in UML-B (in event mode)Subsystem design to code or circuit synthesisFuture WorkConclusions
http://www.ecs.soton.ac.uk/~cfs
(Motivation) Formal
methods
(Motivation) Formal
methods
Formal notationswell-defined, preciseverificationvalidation...but unpopular, textual, cumbersome
not difficult to understand Experimental comparison of the comprehensibility of a Z specification and its implementation in Java, Snook & Harrison - IST (2001)
good coherent abstraction - difficultPractitioners’ views on the use of formal methods: an industrial survey by structured interview, Snook & Harrison - IST (2001)
Formal notationswell-defined, preciseverificationvalidation...but unpopular, textual, cumbersome
not difficult to understand Experimental comparison of the comprehensibility of a Z specification and its implementation in Java, Snook & Harrison - IST (2001)
good coherent abstraction - difficultPractitioners’ views on the use of formal methods: an industrial survey by structured interview, Snook & Harrison - IST (2001)
http://www.ecs.soton.ac.uk/~cfs
(Motivation)
(Motivation)
cog dim, uml, diag from paper
UMLpopular, graphical, easy to change...but loose semantics
cog dim, uml, diag from paper
UMLpopular, graphical, easy to change...but loose semantics
http://www.ecs.soton.ac.uk/~cfs
BBmodel of a component with an interfaceSet basedpredicate logicsubstitutions (program like)variables,operations, parameterised i/o = interface = not refineableprove invariant preserved by operationsrefinement - data, algorithms, refinement relation
model of a component with an interfaceSet basedpredicate logicsubstitutions (program like)variables,operations, parameterised i/o = interface = not refineableprove invariant preserved by operationsrefinement - data, algorithms, refinement relation
http://www.ecs.soton.ac.uk/~cfs
B - some syntax
B - some syntax
Machine <name>
SETS <given sets>
CONSTANTS <list of constants>
PROPERTIES <constraints on constants>
VARIABLES <list of variables>
INVARIANT <constraints on variables>
INITIALISATION <initial values for all variables>
OPERATIONS
<opname> (<list of params>) =
PRE param : <paramType> & ... & <other preconditions>
THEN <substitutions define changes to variables>
END;
<other ops>
END
http://www.ecs.soton.ac.uk/~cfs
Event systems
Event systems
Model of an observable system:stateevents (spontaneous)events may only occur in certain statesdeadlocks?no interface, no parameters
refinements may:- add new eventscombine events into onesplit events into manymustn’t increase deadlock
Model of an observable system:stateevents (spontaneous)events may only occur in certain statesdeadlocks?no interface, no parameters
refinements may:- add new eventscombine events into onesplit events into manymustn’t increase deadlock
http://www.ecs.soton.ac.uk/~cfs
Event
B
Event
B
Events instead of operationsno parameters,no pre-conditions,block when guard is false
Additional Proof obligations:New events in a refinement do not alter the abstraction’s variables(I.e. refine skip)
New events must eventually relinquish control(I.e each new event must decrease a ‘variant’ expression’)
Relative deadlockfreeness is preserved(I.e. I(x) & G(x,y) & OR(abstraction guards) => OR(refinement guards))
Modalities are refined(I.e. if a condition is eventually reached by a sequence of events in the abstraction, it is also reached in the refinement, albeit, possibly being postponed by new events)
Events instead of operationsno parameters,no pre-conditions,block when guard is false
Additional Proof obligations:New events in a refinement do not alter the abstraction’s variables(I.e. refine skip)
New events must eventually relinquish control(I.e each new event must decrease a ‘variant’ expression’)
Relative deadlockfreeness is preserved(I.e. I(x) & G(x,y) & OR(abstraction guards) => OR(refinement guards))
Modalities are refined(I.e. if a condition is eventually reached by a sequence of events in the abstraction, it is also reached in the refinement, albeit, possibly being postponed by new events)
http://www.ecs.soton.ac.uk/~cfs
Problems translating
UML to
B
Problems translating
UML to
B
1) B is not object oriented - no ‘promotion’, no instancesso...
have to model instances explicitly
2) Restrictions to ensure B components can be independently proved - no write sharing of machinesso...
if class --> machinethen only hierarchical associations
so...class diag. --> machinebut then no operation calling(ok for abstract systems - poss. future work)
1) B is not object oriented - no ‘promotion’, no instancesso...
have to model instances explicitly
2) Restrictions to ensure B components can be independently proved - no write sharing of machinesso...
if class --> machinethen only hierarchical associations
so...class diag. --> machinebut then no operation calling(ok for abstract systems - poss. future work)
http://www.ecs.soton.ac.uk/~cfs
Introduction to
UML-B and
U2B
Introduction to
UML-B and
U2B
http://www.ecs.soton.ac.uk/~cfs
LENDER
assets : NATURALcapital
make offer(tr : TRANSACTION)withdraw offer()
INSURER
make quote()withdraw quote()
LOAN
amount : NATURAL10..n
+lender
1
+loans
0..n
POLICY
0..n
1
0..n
+insurer1
LOCATION
0..n
0..n
+valid
0..n
0..n
BROKER
TRANSACTION
priceincome
new_TRANSACTION(price, location, income)inviteInsurer(ins : INSURER)inviteLender(len : LENDER)choose(offer : LOAN, quote : POLICY)
0..n
0..n
+invitedLenders0..n
0..n
0..n0..n
+invitedInsurers
0..n0..n
0..n
0..1
+offers
0..n
+transactionLn
0..1
0..n
0..1
+quotes0..n
+transactionPl0..1
1
0..n
+location
1
0..n
1
0..n
1
0..n
USERACCOUNT
logged_in : BOOLEAN = FALSE
login()logout()
0..1
0..n
+borrower
0..1
+myLoans
0..n
1
0..n
+user
1
0..n
0..n+myPolicies 0..n+holder
What are
UML-B and
U2B?
What are
UML-B and
U2B?
UML-B is a profile of the UMLClass diagrams and State chartsSpecialisations using stereotypes and tagged values
e.g <<machine>>, <<refinement>>,<<constant>>UML-B clausese.g. INSTANCES {trout,tench,roach}uB - integrated constraint & action languagee.g.SELECT waiting=true & other.colour=redTHEN colour:=greenEND
UML-B is a profile of the UMLClass diagrams and State chartsSpecialisations using stereotypes and tagged values
e.g <<machine>>, <<refinement>>,<<constant>>UML-B clausese.g. INSTANCES {trout,tench,roach}uB - integrated constraint & action languagee.g.SELECT waiting=true & other.colour=redTHEN colour:=greenEND
http://www.ecs.soton.ac.uk/~cfs
MACHINE broker /*" U2B3.6.4 generated this component from Package broker "*/CONSTANTS
POLICY, LOCATION, LOAN, LENDER, INSURER,
TRANSACTION, BROKER, USERACCOUNTPROPERTIES
POLICY = 1..n & LOCATION = 1..n & LOAN = 1..n &
LENDER = 1..n & INSURER = 1..n & TRANSACTION = 1..n
VARIABLEamount, assets, capital, price, income, logged_in
INVARIANTamount : LOAN --> NATURAL &
(borrower=null) or (transactionLn=null) &
assets : LENDER --> NATURAL &
INITIALISATION
amount :: LOAN --> NATURAL ||
assets :: LENDER --> NATURAL ||
logged_in :: USERACCOUNT --> {FALSE}
OPERATIONS
choose (thisTRANSACTION,offer,quote) =
PRE thisTRANSACTION : TRANSACTION & offer:LOAN & quote:POLICY
THEN
SELECT
offer:offers &
quote:quotes &
logged_in(user)=true
THEN
offer.borrower:=user ||
quote.holder:=user ||
delete(thisTRANSACTION)
END
END
;
What is
U2B ?
What is
U2B ?
U2B translates UML-B models into B
HistoryPhD work [‘99]
MATISSE [‘00] (Åbo Akademi, ClearSy, Qinetiq, Siemens, Gemplus, U.Marseille)
PUSSEE [‘01] (Nokia, Volvo, Intracom, ClearSy, KeesDa, U.Paderborn)
U2B translates UML-B models into B
HistoryPhD work [‘99]
MATISSE [‘00] (Åbo Akademi, ClearSy, Qinetiq, Siemens, Gemplus, U.Marseille)
PUSSEE [‘01] (Nokia, Volvo, Intracom, ClearSy, KeesDa, U.Paderborn)
http://www.ecs.soton.ac.uk/~cfs
UML-B flavours
UML-B flavours
Model style: Event OR Action OR Conventional Procedural
Instance modelling options:Variable,
Fixed (deferred, enumerated, numbered), Single object,
None (implicit or class utility)
Machine per:Class OR Package (class diagram)
State chart semantics options:State variable OR Petri style
Model style: Event OR Action OR Conventional Procedural
Instance modelling options:Variable,
Fixed (deferred, enumerated, numbered), Single object,
None (implicit or class utility)
Machine per:Class OR Package (class diagram)
State chart semantics options:State variable OR Petri style
http://www.ecs.soton.ac.uk/~cfs
UML-B
Benefits
UML-B
Benefits
Visualise abstractions
Exploratory design tool
Automates B infrastructure
Quick to change model
Increases visibility of important details
Easier to review work within team
Accessible to others
Visualise abstractions
Exploratory design tool
Automates B infrastructure
Quick to change model
Increases visibility of important details
Easier to review work within team
Accessible to others
http://www.ecs.soton.ac.uk/~cfs
Classes and
Attributes
Classes and
Attributes
ACCOUNT
Balance : NAT = 0Overdraft : NAT = 500
SYSTEM Bank /*" U2B3.7.7 generated this component from Package Bank "*/SETS ACCOUNTDEFINITIONS
type_invariant == (Balance : ACCOUNT --> NAT &Overdraft : ACCOUNT --> NAT ) ;
invariant = type_invariantVARIABLES Balance, OverdraftINVARIANT invariantINITIALISATION
Balance, Overdraft :(invariant & Balance = ACCOUNT * {0} & Overdraft = ACCOUNT * {500} )
END
http://www.ecs.soton.ac.uk/~cfs
Associations
Associations
ACCOUNT
Balance : NAT = 0Overdraft : NAT = 500
CUSTOMER
Name : NAME
1
0..*
+owner 1
0..*
SYSTEM Bank /*" U2B3.7.2 generated this component from Package Bank "*/SETS ACCOUNT; CUSTOMERDEFINITIONStype_invariant == (
Balance : ACCOUNT --> NAT &Overdraft : ACCOUNT --> NAT &owner : ACCOUNT --> CUSTOMER &Name : CUSTOMER --> NAME
) VARIABLES
Balance, Overdraft, owner, NameINVARIANT
type_invariantINITIALISATION
Balance, Overdraft, owner, Name :(invariant & Balance = ACCOUNT * {0} & Overdraft = ACCOUNT * {500} )
END
http://www.ecs.soton.ac.uk/~cfs
Operations (Events)
Operations (Events)
ACCOUNT
Balance : NAT = 0Overdraft : NAT = 500
deposit(cc : CUSTOMER, nn : NAT)withdraw(cc : CUSTOMER, nn : NAT)
CUSTOMER
Name : NAME
1
0..*
+owner 1
0..*
Operations are referred to as « events » in EventB terminology
EVENTS deposit =ANY thisACCOUNT,cc,nn WHERE
thisACCOUNT:ACCOUNT &cc:CUSTOMER &nn:NAT
THENskip
END; withdraw =ANY thisACCOUNT,cc,nn WHERE
thisACCOUNT:ACCOUNT &cc:CUSTOMER &nn:NAT
THENskip
END
http://www.ecs.soton.ac.uk/~cfs
State
Charts
State
Charts
exceeded
ok
deposit
deposit
withdraw
withdraw
depositDEFINITIONStype_invariant == (
exceeded : POW(ACCOUNT) &ok : POW(ACCOUNT) &Balance : ACCOUNT --> NAT &Overdraft : ACCOUNT --> NAT &owner : ACCOUNT --> CUSTOMER &Name : CUSTOMER --> NAME
) ;....VARIABLES
exceeded, ok, ....INITIALISATION
exceeded, ok, ... :(invariant &exceeded = {} & ok = ACCOUNT &
....END
http://www.ecs.soton.ac.uk/~cfs
State
Charts in EventB
State
Charts in EventB
EVENTS deposit =ANY thisACCOUNT,cc,nn WHERE thisACCOUNT:ACCOUNT & cc:CUSTOMER & nn:NATTHEN SELECT thisACCOUNT : exceeded THEN skip WHEN thisACCOUNT : exceeded THEN exceeded:=exceeded-{thisACCOUNT} || ok:=ok\/{thisACCOUNT} WHEN thisACCOUNT : ok THEN skip ENDEND
exceeded
ok
deposit
deposit
withdraw
withdraw
deposit
http://www.ecs.soton.ac.uk/~cfs
Transition
Guards
Transition
Guards
exceeded
ok
deposit[ nn+Balance<-Overdraft ]
deposit[ nn+Balance>=-Overdraft ]withdraw[ Balance-nn<-Overdraft ]
withdraw[ Balance-nn>=-Overdraft ]
deposit
SELECT thisACCOUNT : exceeded & nn+Balance(thisACCOUNT)< -Overdraft(thisACCOUNT)THEN skipWHEN thisACCOUNT : exceeded &
nn+Balance(thisACCOUNT)>= -Overdraft(thisACCOUNT)THEN
exceeded:=exceeded-{thisACCOUNT}|| ok:=ok\/{thisACCOUNT} ...
http://www.ecs.soton.ac.uk/~cfs
Operation
Guards and
Semantics
Operation
Guards and
Semantics
withdraw = [cc=owner] ==>Balance:=Balance-nn
withdraw =...
SELECTcc=owner(thisACCOUNT)
THEN<select from state chart>||Balance(thisACCOUNT):=Balance(thisACCOUNT)-nn
ENDEND
http://www.ecs.soton.ac.uk/~cfs
Invariants
Invariants
exceeded
ok
deposit[ nn+Balance<-Overdraft ]
deposit[ nn+Balance>=-Overdraft ]withdraw[ Balance-nn<-Overdraft ]
withdraw[ Balance-nn>=-Overdraft ]
depositINVARIANTBalance>=-Overdraft
INVARIANTBalance<-Overdraft
Invariants can be associated with states (as well as with classes)
http://www.ecs.soton.ac.uk/~cfs
Invariants
Invariants
ACCOUNT_invariant == (
!(thisACCOUNT).(thisACCOUNT:ACCOUNT => (( thisACCOUNT : exceeded => (
Balance(thisACCOUNT)<-Overdraft(thisACCOUNT))) )) &
!(thisACCOUNT).(thisACCOUNT:ACCOUNT => (( thisACCOUNT : ok => (
Balance(thisACCOUNT)>=-Overdraft(thisACCOUNT))) ))
)
http://www.ecs.soton.ac.uk/~cfs
Changing a
UML-B
Model
Changing a
UML-B
Model
exceeded
okreduceLimitincreaseLimit
increaseLimit[ Balance>=-ol ]
increaseLimit[ Balance<-ol ]
e.g. add new events to make changes to the overdraft limit
increaseLimit = [ol>Overdraft] ==> overdraft:=ol
reduceLimit = [ol<Overdraft] ==> overdraft:=ol
increaseLimit =ANY thisACCOUNT,ol WHERE
thisACCOUNT:ACCOUNT &ol:NAT
THENSELECT
ol>Overdraft(thisACCOUNT)THEN
SELECT thisACCOUNT : exceeded & Balance(thisACCOUNT)>=-olTHEN exceeded:=exceeded-{thisACCOUNT} ||
ok:=ok\/{thisACCOUNT}WHEN thisACCOUNT : exceeded & Balance(thisACCOUNT)<-olTHEN skipWHEN thisACCOUNT : okTHEN skipEND ||Overdraft(thisACCOUNT):=ol
ENDEND
http://www.ecs.soton.ac.uk/~cfs
‘Advanced’ Instance
Modelling
‘Advanced’ Instance
Modelling
CARDINALITY clause n => fixed (deferred or enumerated), SETS CC 3..3 => fixed numbered CONSTANTS C = 0..3 0..n => varying VARIABLES C : POW(possibleC) = {} constructors and destructors <<create>>, <<destroy>>
INSTANCES clause {lille,paris,nantes} SETS CC = {lille,paris,nantes}
Association classes
CONSTANTS CC : POW(BB*AA)
Inheritance CONSTANTS CC : POW1(SUPERC)
CARDINALITY clause n => fixed (deferred or enumerated), SETS CC 3..3 => fixed numbered CONSTANTS C = 0..3 0..n => varying VARIABLES C : POW(possibleC) = {} constructors and destructors <<create>>, <<destroy>>
INSTANCES clause {lille,paris,nantes} SETS CC = {lille,paris,nantes}
Association classes
CONSTANTS CC : POW(BB*AA)
Inheritance CONSTANTS CC : POW1(SUPERC)
CC
AA BB
SUPERC CC
http://www.ecs.soton.ac.uk/~cfs
Decomposition of Event systems
Decomposition of Event systems
As refinement adds detail systems get bigger...need to decompose into subsystems to cope Event systems have no I/O...so subsystems cannot communicate
Instead, abstract away all details of events in other subsystems and model inputs as nondeterministic changes
...but must not refine variables representing the interfaces !!
As refinement adds detail systems get bigger...need to decompose into subsystems to cope Event systems have no I/O...so subsystems cannot communicate
Instead, abstract away all details of events in other subsystems and model inputs as nondeterministic changes
...but must not refine variables representing the interfaces !!
http://www.ecs.soton.ac.uk/~cfs
Architecture
Architecture
Packages represent modelsi.e. systems and their
refinements,
and after decompositionsubsystems and their
refinements
Each package is translated into a separate B component
Some subsystems may be implemented in hardware and some in software
Packages represent modelsi.e. systems and their
refinements,
and after decompositionsubsystems and their
refinements
Each package is translated into a separate B component
Some subsystems may be implemented in hardware and some in software
AbstractSystem<<machine>>
Refinement1<<refinement>>
Refinement2<<refinement>>
Subsystem1<<machine>>
Subsystem2<<machine>>
Sub1Ref 1<<refinement>>
Sub2Ref 1<<refinement>>
<---- refines
http://www.ecs.soton.ac.uk/~cfs
Decomposition of Event systems
Decomposition of Event systems
allocate events to subsystems to minimise shared data (data coupling)..
e.g. addCopy in one subsystem, registerUser,loan,return in another
allocate events to subsystems to minimise shared data (data coupling)..
e.g. addCopy in one subsystem, registerUser,loan,return in another
LIBRARY
registerUser(uu : USER)addCopy(bb : BOOK)
USER
0..n
0..n+registered
0..n
0..n
BOOK
loan(uu : USER, ll : LIBRARY)return(uu : USER)
0..n
0..1
+collection0..n
0..1
0..n
0..1
+borrows
0..n
0..1
TITLE
0..n
0..n
+catalog
0..n
0..n
0..n
1
0..n
+title
1
<<constant>>
registerUser = [uu/:registered] ==>registered:=registered\/{uu}
addCopy =[bb/:UNION(ll).(ll:LIBRARY | ll.collection)] ==>collection:=collection \/ {bb} ||IF bb.title /: catalog THEN catalog:=catalog\/{bb.title}END
loan = [uu:ll.registered & self:ll.collection &self/:UNION(uu).(uu:USER | uu.borrows)]==>uu.borrows:=uu.borrows \/ {self}
return = [self:uu.borrows] ==> uu.borrows:=uu.borrows-{self}
http://www.ecs.soton.ac.uk/~cfs
Decomposition of Event systems
Decomposition of Event systems
Maintenance subsystem is derived as follows:
1) Identify data accessed by events of subsystem
2) Remove unused data
3) for each event not in subsystem,
a) add <<static>> stereotype,
b) delete any parameters,
c) delete any guards,
d) abstract away semantics by replacing any writes to variables of this subsystem with v1,v2,...vn:(invariant) OR if there are none, replace with skip.
Maintenance subsystem is derived as follows:
1) Identify data accessed by events of subsystem
2) Remove unused data
3) for each event not in subsystem,
a) add <<static>> stereotype,
b) delete any parameters,
c) delete any guards,
d) abstract away semantics by replacing any writes to variables of this subsystem with v1,v2,...vn:(invariant) OR if there are none, replace with skip.
1) addCopy refers to associations, collection, title and catalog and classes LIBRARY and BOOK. It also needs to know about the class TITLE in order to obtain the type for title and catalog.
2) the USER class and its associations can be deleted.
3) registerUser, loan and return all become skip
http://www.ecs.soton.ac.uk/~cfs
Decomposition of Event systems
Decomposition of Event systems
LIBRARY
<<static>> registerUser()addCopy(bb : BOOK)
BOOK
<<static>> loan()<<static>> return()
0..n
0..1
+collection0..n
0..1
TITLE
0..n
0..n
+catalog
0..n
0..n
0..n
1
0..n
+title
1
<<constant>>
registerUser = skip
addCopy =[bb/:UNION(ll).(ll:LIBRARY | ll.collection)]==>collection:=collection \/ {bb} ||IF bb.title /: catalog THEN catalog:=catalog\/{bb.title}END
loan = skip
return = skip
http://www.ecs.soton.ac.uk/~cfs
Decomposition of Event systems
Decomposition of Event systems
USER
LIBRARY
registerUser(uu : USER)<<static>> addCopy()
0..n
0..n
+registered
0..n
0..n
BOOK
loan(uu : USER, ll : LIBRARY)return(uu : USER)
0..n
0..1
+collection0..n
0..1
0..n
0..1
+borrows
0..n
0..1
registerUser = [uu/:registered] ==>registered:=registered\/{uu}
addCopy =$collection:(invariant)
loan = [uu:ll.registered & self:ll.collection &self/:UNION(uu).(uu:USER | uu.borrows)] ==>uu.borrows:=uu.borrows \/ {self}
return = [self:uu.borrows] ==>uu.borrows:=uu.borrows-{self}
http://www.ecs.soton.ac.uk/~cfs
UML 2.0
Components
UML 2.0
Components
UML1.x had no decomposition mechanism
Currently UML-B has no way of modelling the interface between subsystems
UML 2 components may provide an answer
Ports and channels will define the abstraction of ‘other subsystems’ events and/or shared interface variables
UML1.x had no decomposition mechanism
Currently UML-B has no way of modelling the interface between subsystems
UML 2 components may provide an answer
Ports and channels will define the abstraction of ‘other subsystems’ events and/or shared interface variables
Subsystem1 Subsystem2
http://www.ecs.soton.ac.uk/~cfs
Subsystem
design to code
Subsystem
design to code
recompose events into a single event
use imports to decompose into B modules
specify single event in terms of calls to operations in the imported modules
recompose events into a single event
use imports to decompose into B modules
specify single event in terms of calls to operations in the imported modules
http://www.ecs.soton.ac.uk/~cfs
Subsystem
design to circuit
Subsystem
design to circuit
design circuit in event Badd refinements to describe circuit eventswhen sufficient detail
use BHDL to VHDL converter
design circuit in event Badd refinements to describe circuit eventswhen sufficient detail
use BHDL to VHDL converter
http://www.ecs.soton.ac.uk/~cfs
Future
plans
Future
plans
RODINEC IST Strep project Starts 1st June 2004 (3 years)Nokia, Praxis, VTEngControl, ClearSy,U.Newcastle, U.Zurich, Åbo Akademi
Develop UML-B features (inheritance, Components, other UML notations?)
Integrate U2B withB# - new language - improved genericity
featuresClick’nProve - new proof tools ProB - B model checkerProTest - model based test
Open source tool set running under Elipse
RODINEC IST Strep project Starts 1st June 2004 (3 years)Nokia, Praxis, VTEngControl, ClearSy,U.Newcastle, U.Zurich, Åbo Akademi
Develop UML-B features (inheritance, Components, other UML notations?)
Integrate U2B withB# - new language - improved genericity
featuresClick’nProve - new proof tools ProB - B model checkerProTest - model based test
Open source tool set running under Elipse
http://www.ecs.soton.ac.uk/~cfs