Property Modelling with MSC
What are properties?
How can properties be described?
What is a good technique to describe properties?
Why should we use MSC?
IN-RTIMe: Property modelling with MSC / Slide 1
Øystein Haugen, Ericsson NorARC, Ifi UiO
Definition
A “property” is “a characteristic trait or quality”
(American Heritage Dictionary)
Moustache
Woman
IN-RTIMe: Property modelling with MSC / Slide 2
Øystein Haugen, Ericsson NorARC, Ifi UiO
Properties of properties
l Property descriptions cover
specific aspects;
l Property descriptions may overlap
and underlap;
l Property descriptions are often
declarative rather than imperative;
l Property descriptions supplement
object descriptions;
Properties
Object model
IN-RTIMe: Property modelling with MSC / Slide 3
Øystein Haugen, Ericsson NorARC, Ifi UiO
Specific aspects
l liveness properties: something good will
eventually happen;
l safety properties: something bad will never
happen;
l possibility properties: this might happen;
l overview of functionality (functions and
function lists, functional roles);
l focus on interaction (use cases, MSC
diagrams);
l capacity and timing constraints;
l physical constraints: temperature, humidity,
power consumption, concrete interfaces,
l other not so easily formalized properties:
modifiability, security, error handling
IN-RTIMe: Property modelling with MSC / Slide 4
Øystein Haugen, Ericsson NorARC, Ifi UiO
Overlap and underlap
l Overlap implies a chance to perform consistency checks
l Underlap implies that the complete picture is not covered
Øystein Haugen, Ericsson NorARC, Ifi UiO
IN-RTIMe: Property modelling with MSC / Slide 5
Declarative vs Imperative
I hereby declare
• Declarative
• Descriptive
• Suggestive
• Imperative
• Prescriptive
• Normative
Property model
Object model
msc Unlocked_unclosed
User
AC System
DoorOpen
Door unlocked
Push door
door
door
Opened
Alarm,Error
door
Error
Idle
IN-RTIMe: Property modelling with MSC / Slide 6
Alarm
Idle
Øystein Haugen, Ericsson NorARC, Ifi UiO
Supplementing object model
prop.
mod
obj.
mod.
prop.
mod
interleaving
{x+4=8}
x := x + 4;
obj.
mod.
mapping
msc Unlocked_unclosed
User
AC System
pre-condition
program text
DoorOpen
Door unlocked
Push door
{x=8}
door
door
post-condition
Opened
door
Alarm,Error
Error
Alarm
Idle
Idle
Øystein Haugen, Ericsson NorARC, Ifi UiO
IN-RTIMe: Property modelling with MSC / Slide 7
Evaluating Property Languages
transparency
The World
expressiveness
Property Language
verifiability
Formal base
IN-RTIMe: Property modelling with MSC / Slide 8
Øystein Haugen, Ericsson NorARC, Ifi UiO
Comparison between Property Languages
Property
Prose
MSC
Focus
SDL
liveness, safety
fair
fair
good
fair
overview
good
good
fair
good
interaction
poor
good
fair
fair
time req.
fair
poor
good
poor
capacity
fair
poor
fair
poor
transparency
good
good
poor
good
expressiveness
fair
fair
good
good
formalization
poor
good
good
good
IN-RTIMe: Property modelling with MSC / Slide 9
Øystein Haugen, Ericsson NorARC, Ifi UiO
MSC-92 Methodology
Even though MSC is simple and may be read and produced by engineers
without much formal training, it is possible to:
••
••
make
makebeautiful
beautifulmscs
mscswhich
whichsay
saynothing,
nothing,
make
makemessy
messymscs
mscswhich
whichare
aremeant
meantto
toconvey
conveycritical
criticalinformation,
information,
••
make
maketerrible
terriblemscs
mscsininan
anearly
earlyphase
phasewhich
whichmakes
makesititimpossible
impossibleto
to
design
designaasensible
sensiblesystem
systemininaalater
laterphase.
phase.
use
useextensions
extensionsto
toMSC-92
MSC-92which
whichare
arenot
notstandard
standardand
andwhich
whichmay
may
prevent
preventyou
youfrom
fromusing
using(more
(morethan
thanone)
one)tools.
tools.
••
The methodology aims at bridging the gap between the notation and the
development process using it.
IN-RTIMe: Property modelling with MSC / Slide 10
Øystein Haugen, Ericsson NorARC, Ifi UiO
MSC classification: case evaluation
••
••
••
••
Normal
Normalbehavior
behaviorisisthe
thebehavior
behaviorwhich
whichwe
weexpect
expect
Exceptional
cases
are
those
which
may
happen,
Exceptional cases are those which may happen,and
andwhich
whichwe
weshould
should
prepare
preparefor,
for,but
butwhich
whichwe
wedo
donot
notconsider
considernormal.
normal.
The
Theerroneous
erroneousbehavior
behaviorisisbehavior
behaviorwhich
whichwe
wetry
tryto
toavoid,
avoid,but
butwhich
which
should
not
destroy
our
system.
should not destroy our system.
Impossible
Impossiblebehavior
behaviorisisbehavior
behaviorthat
thatcannot
cannothappen
happen
Impossible behavior
Possible behavior
Normal behavior
Exceptional behavior
Critical behavior
Erroneous behavior
Øystein Haugen, Ericsson NorARC, Ifi UiO
IN-RTIMe: Property modelling with MSC / Slide 11
MSC classification: descriptive goal
Descriptive
Descriptivegoal
goal
historical
historical
Life
Lifespan
span
temporary
temporary
documentary
documentary
Target
Targetaudience
audience
project
members,
project members,managers,
managers,
potential
potentialcustomers
customers
managers,
managers,customers
customers
requirements
requirements
customers,
customers,project
projectteam
team
product
productspan
span
design
design
test
test
project
projectteam
team
testers,
testers,customers
customers
project
project
product
productspan
span
IN-RTIMe: Property modelling with MSC / Slide 12
negotiations
negotiationsor
or
product
productspan
span
Øystein Haugen, Ericsson NorARC, Ifi UiO
Step 0: Make explicit the company MSC strategy
••
••
••
••
Tools:
Tools:What
Whattools
toolswill
willbe
beused
usedto
toproduce
produceand
andmaintain
maintainthe
themscs?
mscs?
Coverage
Profile:
How
do
the
MSC
documents
cover
the
universe
Coverage Profile: How do the MSC documents cover the universe
of
ofMSCs?
MSCs?
Document
DocumentProfile:
Profile:Which
WhichMSC
MSCdocuments
documentsare
areto
tobe
beproduced?
produced?
The
TheInexpressible:
Inexpressible:How
Howisisinformation
informationnot
notexpressible
expressibleininMSC
MSC
attached?
attached?
IN-RTIMe: Property modelling with MSC / Slide 13
Øystein Haugen, Ericsson NorARC, Ifi UiO
Step 1a: the first MSCs
••
••
••
••
••
Our
Ourmetaphor
metaphorfor
forbuilding
buildingour
ourMSC
MSCdocument
documentisisaanews
newsphotographer
photographer
covering
coveringaamajor
majorevent.
event.
Firstly
Firstlyhe
hewill
willmake
makesure
sureto
totake
takepictures
picturesof
ofthe
themain
maincharacters
characters––the
the
normal
normalcases.
cases.
Then
Thenhe
hewill
willlook
lookfor
forsome
someexceptional
exceptionalsituation
situationwhich
whichmight
mightsell
sellbetter
betterto
to
the
thepublic
publicand
andwhich
whichmay
maycapture
captureunexpected
unexpectedproblems
problemslike
likethe
thepolice
police
horse
horsegalloping.
galloping.
Then
he
Then hedigs
digsfor
forerrors
errorslike
likethe
thepossible
possibleassassin
assassinininthe
thebushes.
bushes.
Finally
Finallyhe
hecould
couldillustrate
illustratethe
theimpossible
impossibleby
bymanipulating
manipulatingaapicture
picturelike
like
placing
placingForrest
ForrestGump
Gumpwith
withPresident
PresidentNixon.
Nixon.
IN-RTIMe: Property modelling with MSC / Slide 14
Øystein Haugen, Ericsson NorARC, Ifi UiO
Step 1b: Establish the interplay with non-developers
••
••
••
••
Require
Requireresponsibility
responsibilityand
andapproval
approvalfrom
fromthe
thenon-developers;
non-developers;
Involve
the
non-developers
in
making
additional
Involve the non-developers in making additionalMSCs
MSCsmaking
making
sure
surethat
thatthey
theyunderstand
understandMSC
MSCand
andthat
thatthey
theyunderstand
understandthat
thatthey
they
understand
understandMSC;
MSC;
Associate
Associateconcrete
concreteinput/output
input/outputwith
withthe
theuser
userinterface.
interface.
Encourage
Encouragethe
thenon-developers
non-developersto
touse
usetheir
theirMSC
MSCknowledge
knowledge
during
duringthe
thedesign
designand
andmodel
modelchecking
checkingphases
phases
Øystein Haugen, Ericsson NorARC, Ifi UiO
IN-RTIMe: Property modelling with MSC / Slide 15
Summary MSC-92 strategy
Step 0 : company strategy
what tools
what coverage
what MSC documents
How to attach informal text
Step 1a : the first mscs
Step 1b : interplay with non-developers
require responsibility
active involvement
be concrete
encourage further use of MSC
normal
exceptional
erroneous
impossible
critical
Step 2a : Variants and similarity
global conditions
road map
MSC document table
Step 2b : Refinement
message hierarchy
instance hierarchy
Step 2c : Inexpressibles
dependency
capacity and duration
Step 3 : Support the design
alignment table
checking existence
checking full coverage
Step 4 : Test mscs
isolate IUT
project existing mscs
IN-RTIMe: Property modelling with MSC / Slide 16
Øystein Haugen, Ericsson NorARC, Ifi UiO
The MSC-96 Distillery
l Distillation =
– the process of purifying a liquid
lby successive
– evaporation and
– condensation
l MSC-96 Distillation =
– the process of purifying an MSC-96 description
lby successfully making it
– more detailed
– more precise
Øystein Haugen, Ericsson NorARC, Ifi UiO
IN-RTIMe: Property modelling with MSC / Slide 17
How to make wine from water
abstraction
level
precision
distill
details
prove refinement
details
precision
time
IN-RTIMe: Property modelling with MSC / Slide 18
Øystein Haugen, Ericsson NorARC, Ifi UiO
Making more precise
l formalize
– move the description to a more formal language
l narrow
– add more properties to make it less underspecified
l supplement
– add new aspects
IN-RTIMe: Property modelling with MSC / Slide 19
Øystein Haugen, Ericsson NorARC, Ifi UiO
Make more detailed
l decompose
– divide the instances / actors /objects
l break down
– divide the means of communication
l reveal
– find new items not “visible” when objects were bigger
IN-RTIMe: Property modelling with MSC / Slide 20
Øystein Haugen, Ericsson NorARC, Ifi UiO
Service: Changing PIN code
l Informal specification:
– ”Users shall be able to change their secret code”
Øystein Haugen, Ericsson NorARC, Ifi UiO
IN-RTIMe: Property modelling with MSC / Slide 21
Make more precise – formalize
l ”Users shall be able to change their secret code”
MSC PIN_Change_OK
User
PINChanging
ChangePIN
EnterOldPIN
OldPIN
EnterNewPIN
NewPIN
OK
IN-RTIMe: Property modelling with MSC / Slide 22
Øystein Haugen, Ericsson NorARC, Ifi UiO
Make more precise – narrow
l ”Users shall be able to change their secret code”
– Users shall be able to choose their new secret code (PIN).
– The Card shall be validated by the old PIN before a new PIN can be
given. The new PIN shall subsequently also be validated.
l Is the formalization consistent with the narrowing?
– No! The formalization describes no validation of the new PIN
Øystein Haugen, Ericsson NorARC, Ifi UiO
IN-RTIMe: Property modelling with MSC / Slide 23
Make more precise – supplement
msc PIN_Change
l ”Users shall be able to
change their secret code”
User
PIN Changing
ChangePIN
– what happens if they do not
perform this properly?
ValidateOldPIN
exc
OldPIN_NOK
OldPINOK
GiveNewPIN
ValidateOldPIN
subst GiveOldPIN by GiveNewPIN
exc
NewPIN_NOK
Idle
IN-RTIMe: Property modelling with MSC / Slide 24
Øystein Haugen, Ericsson NorARC, Ifi UiO
Make more detailed – MSC document layers
l ”Users shall be able to change their secret code”
– domain level: roles and coarse messages
– design level: objects and concrete messages
msc PIN_Change
User
User
ChangePIN
EstablishAccess
subst msg(txt) by msg(“Illegal PIN”)
OldPIN_NOK
opt
OldPINOK
GiveNewPIN
PIN OK
“Give new PIN”
inspires
GivePIN /*new PIN*/
“Give PIN again”
ValidateOldPIN
subst GiveOldPIN by GiveNewPIN
exc
AC_PIN_Change
Idle
ValidateOldPIN
exc
AC System
decomposed as
msc PIN_Change
PIN Changing
GivePIN /*new PIN again*/
exc
NewPIN_NOK
“Wrong PIN”
CardOut
Idle
Idle
Øystein Haugen, Ericsson NorARC, Ifi UiO
IN-RTIMe: Property modelling with MSC / Slide 25
Make more detailed – decompose
Console
msc AC_PIN_Change
decomposed by
Authorizer Console_PINChange
AccessPoint
l ”Users shall be able
to change their
secret code”
AC System
decomposed as
msc PIN_Change
User
Idle
AC_EstablishAccess
subst Entry by Console
subst msg(txt) by msg(“Illegal PIN”)
opt
PIN OK
AC_PIN_Change
“Give new PIN”
Idle
AC_GivePIN
subst Entry by Console
/*new PIN*/
EstablishAccess
subst msg(txt) by msg(“Illegal PIN”)
“Give PIN again”
opt
AC_GivePIN
subst Entry by Console
/*new PIN again*/
PIN OK
“Give new PIN”
GivePIN /*new PIN*/
“Give PIN again”
alt
“Wrong PIN”
GivePIN /*new PIN again*/
exc
“Wrong PIN”
CardOut
NewCode(Cid,PIN)
Idle
Idle
AC_PIN_Change V1
IN-RTIMe: Property modelling with MSC / Slide 26
Øystein Haugen, Ericsson NorARC, Ifi UiO
Commutative Decomposition
msc PIN_Change
ACsystem decomposed
as AC_PIN_Change
msc EstablishAccess
ACsystem decomposed
as AC_EstablishAccess
reference
EstablishAccess
GivePIN
decomposition
msc AC_PIN_Change
C
B
msc AC_EstablishAccess
B
C
AC_EstablishAccess
AC_GivePIN
Øystein Haugen, Ericsson NorARC, Ifi UiO
IN-RTIMe: Property modelling with MSC / Slide 27
Make more detailed – break down
l ”Users shall be able to change their secret code”
AC System
decomposed as
msc PIN_Change
User
User
EstablishAccess
EstablishAccess
subst msg(txt) by msg(“Illegal PIN”)
subst msg(txt) by msg(“Illegal PIN”)
opt
PIN OK
PIN OK
“Give new PIN”
“Give new PIN”
GivePIN /*new PIN*/
PIN
“Give PIN again”
“Give PIN again”
break down
PIN
exc
AC_PIN_Change
Idle
Idle
opt
AC System
decomposed as
msc PIN_Change
AC_PIN_Change
“Wrong PIN”
CardOut
Idle
IN-RTIMe: Property modelling with MSC / Slide 28
GivePIN /*new PIN again*/
exc
“Wrong PIN”
CardOut
Idle
Øystein Haugen, Ericsson NorARC, Ifi UiO
Make more detailed – reveal
l ”Users shall be able to change their secret code”
– The card is not significant on the domain level, but becomes
visible on the design level
lwhat prompts the entering of the card?
lcan the card reader keep the card if it is found to be invalid?
ldoes the service write something back onto the card?
Øystein Haugen, Ericsson NorARC, Ifi UiO
IN-RTIMe: Property modelling with MSC / Slide 29
MSC-96 Distillery
msc PIN_Change
Idle
Enter card
ChangePIN
ValidateOldPIN
Old_PIN_incorrect_card_kept”
Idle
OldPINOK
GiveNewPIN
ValidateOldPIN
subst GiveOldPIN by GiveNewPIN
New_PIN_incorrect_old_PIN_valid
Release card
Idle
IN-RTIMe: Property modelling with MSC / Slide 30
Øystein Haugen, Ericsson NorARC, Ifi UiO