Dialectic System Development
Bringing Marxism to modern computers when Marx
is getting obsolete in politics?
Øystein Haugen, Ericsson NorARC, Ifi Uio
Dialectic System Development 981027/ 1
Development of Languages
Hoare-logic
Hoare
CSP
Milner
CCS
FORTRAN
COBOL
Algol Pascal
Jones
VDM
SIMULA
Xerox PARC
SmallTalk
SDL-88
LOTOS (ISO)
ER-model
C
OODB
SQL
Bell Labs
C++
Microsoft
Windows
Apple
MacIntosh
OOA(Yourdon)
SDL-92 (ITU)
MSC (ITU)
Dialectic System Development 981027/ 2
Objectory
(Jacobsson)
OMT
(Rumbaugh)
Booch
UML (Rational / OMG)
Sun
JAVA
Øystein Haugen, Ericsson NorARC, Ifi Uio
Access Control System
Øystein Haugen, Ericsson NorARC, Ifi Uio
Dialectic System Development 981027/ 3
TIMe Distillery
abstraction
level
precision
distill
details
prove refinement
details
precision
time
Dialectic System Development 981027/ 4
Øystein Haugen, Ericsson NorARC, Ifi Uio
UML – why
l We have a need for an informal notation with tool support to
describe the object model in the very early domain modelling
phases
l We want a notation where the decisions about whether entities
are dynamic objects, processes, variables or signals have
been deferred to later
l UML is invented by Rational, who is very active in the objectoriented analysis marketplace. UML is supported by OMG as
standardization body.
Øystein Haugen, Ericsson NorARC, Ifi Uio
Dialectic System Development 981027/ 5
Improve Precision: Object orientation
Area of concern
Domain statement
Access control has to do with controlling the access of users to
access zones. Only a user with known identity and correct
access right shall be allowed to enter into anaccess zone. Other
users shall be denied access.
Object model
Stak eholders
Users of the system, those responsible for the security of the
access zones.
Services
AccessZone
*
r
te
en
The authentication of a user shall be established by some
means for secret personal identi¼
cation (code).The authorisation is based upon the user identity and access rights associated
with the user.
ay
m
The user will enter an access zone through an access point.
1
bounded by
A supervisor will have the ability to insert new users in the
system.
Users shall be able to change their secret code.
*
Helpers
We assume some central means to establish access rights
automatically.
*
AccessPoint
may enter
through
1
1
User
Domain Statement V1
Dialectic System Development 981027/ 6
Øystein Haugen, Ericsson NorARC, Ifi Uio
Service: Change PIN
l Informal specification:
– ”Users shall be able to change their secret code”
Dialectic System Development 981027/ 7
Øystein Haugen, Ericsson NorARC, Ifi Uio
Make 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
Dialectic System Development 981027/ 8
Øystein Haugen, Ericsson NorARC, Ifi Uio
Improve Precision: Service and Role orientation
MSC PIN_Change_OK
User
formalizing
PINChanging
ChangePIN
EnterOldPIN
OldPIN
EnterNewPIN
NewPIN
OK
Consistent?
narrowing
service PIN Change
• Users shall be able to change their
personal identification
• The User shall be able to choose his new
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.
supplementing
Øystein Haugen, Ericsson NorARC, Ifi Uio
Dialectic System Development 981027/ 9
Supplementing
MSC-96
msc PIN_Change
User
PIN Changing
ChangePIN
MSC reference
ValidateOldPIN
exception expression
exc
OldPIN_NOK
OldPINOK
condition
GiveNewPIN
substitution
ValidateOldPIN
subst GiveOldPINby GiveNewPIN
exc
NewPIN_NOK
Idle
Dialectic System Development 981027/ 10
Øystein Haugen, Ericsson NorARC, Ifi Uio
MSC - Why
l MSC is used to
– improve the individual understanding of an interaction
problem,
– document protocol situations,
– illustrate behavior situations,
– verify interaction properties relative to a specification,
– describe test cases,
– document simulation traces.
Øystein Haugen, Ericsson NorARC, Ifi Uio
Dialectic System Development 981027/ 11
Casting
Supervisor
Which object plays each role?
control
who?
plays
Authorizer
PINChanging
AccessGranting
User
plays
User
New User
Dialectic System Development 981027/ 12
Øystein Haugen, Ericsson NorARC, Ifi Uio
Harmonizing
ge
en
te
r
fig
ay
1
bounded by
Authorizer
1c
on
*
AccessZone
*
m
ed
wl
n o ut
k
s o
h a ab
1
*
ure
s
*
1
may enter through
*
1 User
AccessPoint
Øystein Haugen, Ericsson NorARC, Ifi Uio
Dialectic System Development 981027/ 13
System orientation
may enter
*
AccessZone
*
controls access to
1
1
User
* may accept 1
1 may use
0..1
AC-System
Operator
1
owns
Door
sk
n
ed
ge
ab
ou
t
1
accessed through
en
te
1
Authorizer
1..*
r
co 1
nf
igu
*
AccessZone
*
ay
ha
l
ow
m
0..1
Card
Door
1
res
*
1
controls
AccessPoint
*
may enter 1
through
1
User
1 owner
owns
0..1
Card
Dialectic System Development 981027/ 14
Øystein Haugen, Ericsson NorARC, Ifi Uio
Making more Detailed: Mirroring
use SignalLib
system AccessControl
User
[(outp)]
[(inp)]
e
ap(100):
AccessPoint
d
[(outp)]
[(inp)]
operator
C
[isOpen,
[(validity)]
[(validity)]
isClosed]
Door
cons(5):
Console
[unlock,
[code]
[code]
Authorizer
lock]
AccessPoint
Console
Panel
Dialectic System Development 981027/ 15
Øystein Haugen, Ericsson NorARC, Ifi Uio
SDL - Why?
l
Suitability. SDL is well suited for describing reactive systems involving
asynchronous signal exchange;
l
History. SDL has been used in a number of successful projects, esp. in telecom;
l
Tools. There is adequate tool support for SDL and there are more than one
vendor;
l
Precision. SDL is a formal language. The formal definition is given in MetaIV (a
variant of VDM). This implies that the SDL description can be used for
–
understanding the system independently of the implementation;
–
communication between professionals in different organisations;
–
analysis and simulation;
–
derivation of implementation;
l
Standard. SDL is internationally standardised by ITU in Z.100;
l
Graphics. SDL is a graphical language (and a textual language);
l
Object orientation. SDL has full object orientation with inheritance and virtuality;
l
Competence. There is sufficient SDL competence available;
l
Implementability. Using SDL supported by automatic code generation implies a
shift in development paradigm from being implementation oriented to design
oriented.
Dialectic System Development 981027/ 16
Øystein Haugen, Ericsson NorARC, Ifi Uio
The language maturity staircase
SDL development timescale
1994
SDL
Automatic semantics: machine-oriented
1988
MSC
Formal Semantics: mathematical notation
1984
UML
Semantics: explained understanding
1980
SEQD
Syntax: given syntax with illustrative add-ons
1976
Doc. figs.
Illustrations: one notation for each picture, natural language resemblence critical
Øystein Haugen, Ericsson NorARC, Ifi Uio
Dialectic System Development 981027/ 17
Making 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
PIN Changing
User
ChangePIN
EstablishAccess
subst msg(txt) by msg(“Illegal PIN”)
OldPIN_NOK
opt
OldPINOK
GiveNewPIN
NewPIN_NOK
Idle
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
msc PIN_Change
User
GivePIN /*new PIN again*/
exc
“Wrong PIN”
CardOut
Idle
Dialectic System Development 981027/ 18
Øystein Haugen, Ericsson NorARC, Ifi Uio
System services
AC System
decomposed as
msc NewUser
New User
Supervisor
AC System
decomposed as
msc UserAccess
User
AC_NewUser
AC_UserAccess
Idle
Idle
EstablishAccess
EstablishAccess
subst User by Supervisor
subst msg(txt)by msg(“Not Supervisor”)
subst msg(txt)by msg(“Illegal PIN”)
alt
opt
Idle
PIN OK
“Sorry”
“Please enter”
OpenDoor
PIN OK
CardId
Idle
GivePIN /*new PIN*/
subst User by Supervisor
Card(Cid,PIN)
Idle
Similarities
go to system diagram
Øystein Haugen, Ericsson NorARC, Ifi Uio
Dialectic System Development 981027/ 19
Need for generalization: Entry
ACSystem
decomposed as
msc EstablishAccess
User
AC_EstablishAccess
msc AC_EstablishAccess
Entry
decomposed by
Entry_EstablishAccess
Authorizer
Idle
CardId
CardId
AC_GivePIN
GivePIN
loop
<0,3>
loop<0,3>
GivePIN
“TryAgain”
CardOut
alt
Code(Cid,PIN)
“TryAgain”
AC_GivePIN
Code(Cid,PIN)
msg(txt)
Idle
PIN OK
AccLevel(m)
CardOut
alt
msg(txt)
AccLevel(n)
Not acceptable
access level
Idle
PIN OK
Dialectic System Development 981027/ 20
Øystein Haugen, Ericsson NorARC, Ifi Uio
Harmonizing
use SignalLib
system AccessControl
e
[(outp)]
[(inp)]
d
[isOpen,
lock]
e
[(outp)]
use SignalLib
[(inp)]
C
C
isClosed]
[unlock,
cons(5):
Console
ap(100):
AccessPoint
[code]
system AccessControl
[(validity)]
[(validity)]
e
[(outp)]
[(inp)]
[code]
ap(100):
AccessPoint
d
Authorizer
[isOpen,
[(validity)]
isClosed]
generalizing
[unlock,
[(inp)]
[code]
[(validity)]
[code]
Authorizer
lock]
Entry
[(outp)]
cons(5):
Console
C
AccessPoint
Console
Panel
AccessPoint
Console
go to old system diagram
Øystein Haugen, Ericsson NorARC, Ifi Uio
Dialectic System Development 981027/ 21
process ACSystem
Behavior induced by the MSCs
Idle
Code
CardOut
any
OK
NOK
set
(door)
Door unlocked
door
Opened
Lock
reset (door)
Idle
set (door)
Idle
DoorOpen
door
Alarm,Error
closed
reset (door)
Lock
Idle
Dialectic System Development 981027/ 22
Idle
Øystein Haugen, Ericsson NorARC, Ifi Uio
Property orientation and commutative decomposition
msc PIN_Change
ACsystem decomposed
as AC_PIN_Change
msc EstablishAccess
reference
ACsystem decomposed
as AC_EstablishAccess
EstablishAccess
GivePIN
decomposition
msc AC_PIN_Change
C
B
msc AC_EstablishAccess
B
C
AC_EstablishAccess
AC_GivePIN
Øystein Haugen, Ericsson NorARC, Ifi Uio
Dialectic System Development 981027/ 23
Change PIN
AC System
decomposed as
msc PIN_Change
User
Console
msc AC_PIN_Change
decomposed by
AccessPoint Authorizer Console_PINChange
AC_PIN_Change
Idle
AC_EstablishAccess
Idle
subst Entry by Console
subst msg(txt) by msg(“Illegal PIN”)
EstablishAccess
subst msg(txt)by msg(“Illegal PIN”)
opt
opt
PIN OK
“Give new PIN”
PIN OK
AC_GivePIN
subst Entry by Console
/*new PIN*/
“Give new PIN”
GivePIN /*new PIN*/
“Give PIN again”
“Give PIN again”
AC_GivePIN
subst Entry by Console
/*new PIN again*/
GivePIN /*new PIN again*/
exc
“Wrong PIN”
Idle
alt
“Wrong PIN”
NewCode(Cid,PIN)
Idle
Dialectic System Development 981027/ 24
Øystein Haugen, Ericsson NorARC, Ifi Uio
Commutative Decomposition
msc AC_EstablishAccess
msc EstablishAccess
User
ACSystem
decomposed as
Entry
decomposed by
AC_EstablishAccess
Entry_EstablishAccess
CardId
Idle
AC_GivePIN
CardId
Code(Cid,PIN)
GivePIN
loop
<0,3>
loop<0,3>
“TryAgain”
AccLevel(m)
“TryAgain”
AC_GivePIN
GivePIN
Code(Cid,PIN)
AccLevel(n)
CardOut
alt
Authorizer
CardOut
msg(txt)
alt
msg(txt)
Idle
Not acceptable
access level
PIN OK
Idle
PIN OK
Øystein Haugen, Ericsson NorARC, Ifi Uio
Dialectic System Development 981027/ 25
State Orientation
1(1)
process type Panel
GivePIN
recognizable
states
Dialectic System Development 981027/ 26
NoCard
OneCard
cardid
(cid)
GivePIN
GivePIN
GivePIN
Code
(cid,pin)
Code
(cid,pin)
OneCard
—
dcl cid,pin
integer;
*
CardOut
msg(t)
CardOut
“t”
NoCard
—
Øystein Haugen, Ericsson NorARC, Ifi Uio
Verification 1: Model checking PIN Change in Panel
msc Console_PINChange
msc Entry_EstablishAccess
Panel
Controller
Panel
Idle
Controller
CardId
Entry_EstablishAccess
Entry_GivePIN
subst msg(txt) by msg(“Illegal PIN”)
Code(Cid,PIN) Code(Cid,PIN)
opt
loop<0,3>
PIN OK
“Give new PIN”
msg(“Give new PIN”)
GivePIN
“TryAgain”
msg(“Try again”) AccLevel(n)
GivePIN
Entry_GivePIN
Entry_GivePIN
/*new PIN*/
Code(Cid,PIN)
Code(Cid,PIN)
msg(“Give PIN again”)
GivePIN
CardOut
alt
msg(txt)
“Give PIN again”
CardOut
Code(Cid,PIN)
AccLevel(n)
msg(txt)
Entry_GivePIN
/*new PIN again*/
Idle
Code(Cid,PIN)
PIN OK
alt
msg(“Wrong PIN”)“Wrong PIN”
NewCode(Cid,PIN)
When EstablishAccess has elapsed, Panel
is in state NoCard, but it receives GivePIN!
Idle
Øystein Haugen, Ericsson NorARC, Ifi Uio
Dialectic System Development 981027/ 27
Harmonizing
AC System
decomposed as
msc PIN_Change
User
AC_PIN_Change
Idle
EstablishAccess
subst msg(txt) by msg(“Illegal PIN”)
opt
We decide to move CardOut from
PIN OK
“Give new PIN”
GivePIN /*new PIN*/
EstablishAccess to the end of
“Give PIN again”
PIN_Change
GivePIN /*new PIN again*/
exc
“Wrong PIN”
CardOut
Idle
Dialectic System Development 981027/ 28
Øystein Haugen, Ericsson NorARC, Ifi Uio
MSC -> SDL skeletons (Console’s Controller)
procedure skeleton
msc Entry_EstablishAccess
Panel
Code
Controller
(loop cont)
U
CardId
Entry_GivePIN
Code(Cid,PIN) Code(Cid,PIN)
Input transferred to
process by rule
loop<0,3>
W
AccLevel
AccLevel
msg (“Try
again”)
msg(“Try again”) AccLevel(n)
“TryAgain”
GivePIN
Code
msg
(“parm”)
GivePIN
Entry_GivePIN
Code(Cid,PIN)
Code(Cid,PIN)
procedure
start transition
AccLevel(n)
alt
msg(txt)
Controller /* EstablishAccessmsc */
msg(txt)
Not acceptable access
level
Idle
PIN OK
loop where loop
control is not
properly
placed.This
part checks
card/PIN
correspondence
Code
Procedure
termination.
Distinguishes
the different
cases
W
AccLevel
Øystein Haugen, Ericsson NorARC, Ifi Uio
Dialectic System Development 981027/ 29
Manually adjusted
V
Code
procedur e EstablishAccLev
fpar in/out acclev integer;
in cid integer;
in/out pin integer;
dcl cnt integer = 0;
Code
(cid,pin)
Validate
AccLevel
(acclev)
cnt:=cnt+1
acclev>0
or cnt>3
(false)
msg (“Try
again”)
(true)
GivePIN
WaitCode
Code
(cid,pin)
Code
(cid,pin)
Validate
Dialectic System Development 981027/ 30
Øystein Haugen, Ericsson NorARC, Ifi Uio
Verification 2: AccessPoint’s Controller
process type <<block type AccessPoint>> Controller
inherits <<block type Entry>> Controller
/* See also necessary modi¼
cations inVersion 2 of this*/
msc AP_UserAccess
Panel
Controller
Door
Idle
dcl cid,pin inte
ger;
dcl acclev integer;
timer door;
Idle
Code
(cid,pin)
Entry_EstablishAccess
subst msg(txt)by msg(“NoEntry”)
EstablishAccLev
(acclev,cid,pin)
CardOut
CardOut
CardOut
opt
PIN OK
acclev
“Please enter”msg(“PleaseEnter”)
(<=0)
(>0)
msg
(“Please enter”)
AP_OpenDoor
Idle
msg
(“No Entry”)
unlock
Idle
set(now+10, door)
Opening
MSC: User Access vs SDL: Controller = OK!
Closing
opened
closed
door
Are we then certain that AccessPoint’s
Controller is perfect?
lock
reset(door)
set(now+30,
door)
The User opens the door exactly when the
timer expires. door+opened in input port
alarm
lock
Idle
Closing
door
Idle
Idle
Øystein Haugen, Ericsson NorARC, Ifi Uio
Dialectic System Development 981027/ 31
Verification 3: SDL: detecting default transitions
process type <<block type AccessPoint>> Controller
inherits <<block type Entry>> Controller
• MSC is not suited to
uncover all possible
variants of interaction
• SDL supported by
automatic techniques can
find unwanted signalling
combinations
Idle
dcl cid,pin inte
ger;
dcl acclev integer;
timer door;
Code
(cid,pin)
EstablishAccLev
(acclev,cid,pin)
CardOut
acclev
• TIMe has several
techniques to evaluate
projections of processes to
uncover the complexity of
the software
(<=0)
(>0)
msg
(“Please enter”)
msg
(“No Entry”)
unlock
Idle
set(now+10, door)
Opening
opened
Closing
door
ask_closed
set(now+30,
door)
Closing
Dialectic System Development 981027/ 32
closed
reset(door)
door
opened
alarm
lock
Closing
Idle
Closing
Closding
Øystein Haugen, Ericsson NorARC, Ifi Uio
Levels of system validation
1. Test-oriented
(Testing is the most important means to establish the correctness of the
system. Testing is on the implementation of the system)
2. Inspection-oriented
(Inspections involve human readers who control the quality of the
descriptions)
3. Animation-oriented
(Animation and simulation are executions of the system based on
descriptions on higher abstraction levels than implementation)
4. Analysis-oriented
(Formal analysis is used in order to prove statements about the system, or
to disclose hidden aspects with a system)
5. Synthesis-oriented
(When the implementation can be synthesized from a description of the
requirements)
Dialectic System Development 981027/ 33
Øystein Haugen, Ericsson NorARC, Ifi Uio
Testing and Proving
What should I test now?
The system
is consistent!
l Proving cannot replace the whole testing activity
l Proofs require formal description of both system and requirements,
specification and implementation
l Testing may take advantage of the techniques of proof theory such that
testing becomes more effective in selecting what to test and how much
to test.
l Proof theory seldom gives an answer to whether the market will buy the
product
Dialectic System Development 981027/ 34
Øystein Haugen, Ericsson NorARC, Ifi Uio
The intrinsic problems of testing
l A non-deterministic implementation (which possibly should have been
deterministic) cannot be considered correct just because it gives the
right answer once.
l A pure black-box testing without knowledge of the inner structure of
the system have no information to find the holes of the implementation
l The ones with knowledge of the inner structure of the system, are
those who made it. They may have more difficulty in finding the error
situations because otherwise they would have corrected the errors
already.
l Testing is expensive; therefore somebody will make the customers do
the testing. Others are probably out of business if they get serious
errors.
l It is in general impossible to test all possibilities of a big system
Øystein Haugen, Ericsson NorARC, Ifi Uio
Dialectic System Development 981027/ 35
Reaping the benefits of formal approaches
Proofs
Verification: Is the imperative definition according to the spec
Compositionality
Reuse: use the already produced proof results
Conditional proofs
Checking: Introduce assumptions and runtime tests
Complexity
Metric: formally defined measurements
Method
Dialectic System Development 981027/ 36
Design rules: formally motivated design
Øystein Haugen, Ericsson NorARC, Ifi Uio