UML-B & U2B

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


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


(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)


(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


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


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


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


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)


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)


Introduction to

UML-B and

U2B

Introduction to

UML-B and

U2B


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


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)


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


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


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


Associations

Associations

ACCOUNT


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


Operations (Events)

Operations (Events)

ACCOUNT


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


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


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


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} ...


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


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)


Invariants

Invariants

ACCOUNT_invariant == (

!(thisACCOUNT).(thisACCOUNT:ACCOUNT => (( thisACCOUNT : exceeded => (

Balance(thisACCOUNT)<-Overdraft(thisACCOUNT))) )) &

!(thisACCOUNT).(thisACCOUNT:ACCOUNT => (( thisACCOUNT : ok => (

Balance(thisACCOUNT)>=-Overdraft(thisACCOUNT))) ))

)


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


‘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


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 !!


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




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}




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




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




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}


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


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


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


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

UML-B & U2B

Documents

Transcript of UML-B & U2B