Dialectic System Development
Version 021122
INF-UIT 2002 / Dialectic System Development / Slide 1
Øystein Haugen
Ketil Stølen
Access Control System
INF-UIT 2002 / Dialectic System Development / Slide 2
Øystein Haugen
Ketil Stølen
Domain Statement
l Area of concern
– 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 an access zone. Other users shall be denied
access.
l Stakeholders
– Users of the system, those responsible for the security of the access
zones.
l Services
– The user will enter an access zone through an access point.
– A supervisor will have the ability to insert new users in the system.
– Users shall be able to change their secret code.
lThe authentication of a user shall be established by some means for
secret personal identification (code). The authorisation is based
upon the user identity and access rights associated with the user.
INF-UIT 2002 / Dialectic System Development / Slide 3
Øystein Haugen
Ketil Stølen
Software Distillery
abstraction
level
precision
distill
details
prove refinement
details
precision
time
INF-UIT 2002 / Dialectic System Development / Slide 4
Øystein Haugen
Ketil Stølen
Service: Change PIN
lInformal specification:
–”Users shall be able to change their
secret code”
ChangePIN
aUser
INF-UIT 2002 / Dialectic System Development / Slide 5
Øystein Haugen
Ketil Stølen
Make More Precise
l formalize
– move the description to a more formal language
l narrow
– add more properties to make it less ambiguous
l supplement
– add new aspects, consider supplementary scenarios
INF-UIT 2002 / Dialectic System Development / Slide 6
Øystein Haugen
Ketil Stølen
Improve Precision: Service and Role orientation
formalizing
sd PIN_Change_OK
narrowing
Consistent?
User
PINChanging
ChangePIN()
EnterOldPIN()
OldPIN()
service PIN Change
• Users shall be able to change their
personal identification
EnterNewPIN()
NewPIN()
OK()
• 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
INF-UIT 2002 / Dialectic System Development / Slide 7
Øystein Haugen
Ketil Stølen
Supplementing
sd PIN_Change
User
PINChanging
Interaction occurrence
exception expression
ref
ChangePINinvoc
ref
ValidatePIN
exc
OldPIN_NOK()
ref
GiveNewPIN
ref
ValidatePIN
exc
NewPIN_NOK()
Idle
state/label
(non standard notation)
INF-UIT 2002 / Dialectic System Development / Slide 8
Øystein Haugen
Ketil Stølen
UserAccess
The user will enter an access zone through an access point
sd UserAccess
ref
ref
User_Accepted
User_not_accepted
sd User_not_accepted
sd User_Accepted
User
User
AccessGranting
AccessGranting
PIN()
PIN()
OK()
NOK()
Øystein Haugen
INF-UIT 2002 / Dialectic System Development / Slide 9
Ketil Stølen
New User
A supervisor will have the ability to insert new users in the system
sd New_User
NewUser
Supervisor
requestPIN()
Authorizer
givePIN()
PIN()
INF-UIT 2002 / Dialectic System Development / Slide 10
Øystein Haugen
Ketil Stølen
Improve Precision: (Domain) Object Models
AccessZone
*
1
+boundary 1..n
AccessPoint
Name
Number
AccessKey
INF-UIT 2002 / Dialectic System Development / Slide 11
*
*
Øystein Haugen
*
User
Ketil Stølen
Casting
Supervisor
Which object plays each role?
who?
plays
Authorizer
AccessGranting
User
plays
PINchanging
User
NewUser
INF-UIT 2002 / Dialectic System Development / Slide 12
Øystein Haugen
Ketil Stølen
Harmonizing with object model (UML)
+controlledZone
AccessZone
*
*
1
1
Authorizer
+boundary 1..n
1
*
+configurator
INF-UIT 2002 / Dialectic System Development / Slide 13
*
User
AccessPoint
*
Øystein Haugen
*
Ketil Stølen
System orientation
AccessZone
(from DomainModel)
+controlledZone
User
(from DomainModel)
*
1
ACsystem
Operator
AccessZone
+controlledZone
(from DomainModel) *
*
Card
Door
1
Authorizer
(from DomainModel)
1
+accessVia
Door
1
+configurator
*
+controlledDoor
User
(from DomainModel)
+boundary 1..n
*
INF-UIT 2002 / Dialectic System Development / Slide 14
Øystein Haugen
AccessPoint
(from DomainModel)
Ketil Stølen
*
*
Card
Internal Structure in UML 2.0 (notation uncertain)
ACsystem
100
User
5
ap: AccessPoint
c: Console
Operator
a :Authorizer
Øystein Haugen
INF-UIT 2002 / Dialectic System Development / Slide 15
Ketil Stølen
The language maturity staircase
SDL
MSC
UML
Visio
Doc. figs.
Automatic semantics: machine-oriented
Formal Semantics: mathematical notation
Semantics: explained understanding
Syntax: given syntax with illustrative add-ons
Illustrations: one notation for each picture, natural language resemblence critical
INF-UIT 2002 / Dialectic System Development / Slide 16
Øystein Haugen
Ketil Stølen
System services
sd New_User
sd UserAccess
NewUser
Supervisor
___ACSystem___
ref AC_UserAccess
NewUser
___ACSystem___
ref AC_NewUser
Idle
Idle
ref
ref
EstablishAccess
("NotSupervisor")
EstablishAccess ("Illegal PIN")
opt
alt
[Wrong PIN]
[PIN OK]
"Please Enter!"()
"Sorry"()
[PIN OK]
ref
ref
CardId()
OpenDoor
GivePIN
Idle
Card(Cid, PIN)()
Similarities
Idle
Øystein Haugen
INF-UIT 2002 / Dialectic System Development / Slide 17
Ketil Stølen
The Access Control Context as UML Class
context name
ACContext
sd
sd
UserAccess
PINChange
sd
sd
NewUser
sd
OpenDoor
sd
EstablishAccess
ACSystem
defining interactions
NewUser
utility interactions
User
Supervisor
INF-UIT 2002 / Dialectic System Development / Slide 18
internal instances
NewUser
Øystein Haugen
Ketil Stølen
Need for generalization: Entry
sd AC_EstablishAccess(String txt)
sd EstablishAccess(String txt, inst User)
User
___________Entry___________
ref Entry_EstablishAccess(txt)
_______ACSystem_______
ref AC_EstablishAccess(txt)
Authorizer
Idle
CardId()
Idle
Digit()
CardId()
ref
AC_GivePIN
Code(Cid, PIN)()
ref
GivePIN
loop<0,3>
loop<0,3>
"Try Again"()
Digit()
ref
AccLevel(m)()
"Try Again"()
GivePIN
ref
AC_GivePIN
Code(Cid, PIN)()
CardOut()
CardOut()
alt
AccLevel(n)()
alt
msg(txt)()
msg(txt)()
Idle
Idle
PIN OK
PIN OK
Øystein Haugen
INF-UIT 2002 / Dialectic System Development / Slide 19
Ketil Stølen
Harmonizing: Entry, AccessPoint and Console
use AccessLib
system type AccessControl
[(inp)]
e
[(outp)]
isOpen,
isClosed
[(inp)]
ap(100):
ap(100):
AccessPoint
d
v
c(5):
e
Console
[(outp)]
v
[(validity)]
[(validity)]
package AccessLib
unlock,
lock
[Code]
Authorizer
[Code]
«block»
Entry
« block»
AccessPoint
INF-UIT 2002 / Dialectic System Development / Slide 20
Øystein Haugen
Ketil Stølen
«block»
Console
Decomposition and UML Classes
ACContext
Entry
-ACSystem : Lifeline
-User : Lifeline
-Supervisor : Lifeline
-NewUser : Lifeline
+UserAccess() : sd
+PINChange() : sd
+NewUser() : sd
#EstablishAccess() : sd
#OpenDoor() : sd
#GivePIN() : sd
-Panel : Lifeline
-Controller : Lifeline
+Entry_EstablishAccess() : sd
#Entry_GivePIN() : sd
-
1
*
-
-
AccessPoint
-Door : Lifeline
ACSystem
-
-AccessPoint : Lifeline
-Console : Lifeline
-Authorizer : Lifeline
+AC_UserAccess() : sd
+AC_PINChange() : sd
+AC_NewUser() : sd
#AC_EstablishAccess() : sd
#AC_OpenDoor() : sd
#AC_GivePIN() : sd
*
+AP_UserAccess() : sd
11
INF-UIT 2002 / Dialectic System Development / Slide 22
-
Console
*
+Console_NewUser() : sd
+Console_PINChange() : sd
Øystein Haugen
Ketil Stølen
Property orientation and 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
INF-UIT 2002 / Dialectic System Development / Slide 23
Øystein Haugen
Ketil Stølen
Change PIN
sd AC_PINChange
sd PINChange
User
AccessPoint
___ACSystem___
ref AC_PINChange
Authorizer
_______Console_______
ref Console_PINChange
Idle
Idle
ref
ref
EstablishAccess ("Illegal PIN")
opt
Cardid,Digit, "Try again", msg()
AC_EstablishAccess("Illegal PIN")
[PIN OK]
[PIN OK]"Give new PIN"()
opt
"Give new PIN"()
ref
ref
GivePIN
Digit()
AC_GivePIN
"Give PIN again"()
"Give PIN again"()
ref
ref
GivePIN
[wrong PIN]
opt
Digit()
AC_GivePIN
[wrong PIN]"Wrong PIN"()
alt
"Wrong PIN"()
[else]
NewCode(Cid,PIN)()
Idle
Idle
INF-UIT 2002 / Dialectic System Development / Slide 24
Øystein Haugen
Ketil Stølen
Commutative Decomposition
sd AC_EstablishAccess(String txt)
sd EstablishAccess(String txt, inst User)
User
___________Entry___________
ref Entry_EstablishAccess(txt)
_______ACSystem_______
ref AC_EstablishAccess(txt)
Authorizer
Idle
CardId()
Idle
Digit()
ref
AC_GivePIN
CardId()
Code(Cid, PIN)()
ref
loop<0,3>
GivePIN
loop<0,3>
"Try Again"()
Digit()
ref
AccLevel(m)()
"Try Again"()
GivePIN
ref
AC_GivePIN
Code(Cid, PIN)()
CardOut()
CardOut()
alt
AccLevel(n)()
msg(txt)()
alt
Idle
msg(txt)()
Idle
PIN OK
PIN OK
INF-UIT 2002 / Dialectic System Development / Slide 25
Øystein Haugen
Ketil Stølen
The general Entry - with local Panel
Entry
sd
sd
Entry_EstablishAccess
Controller
Entry_GivePIN
p:Panel
c:Controller
Øystein Haugen
INF-UIT 2002 / Dialectic System Development / Slide 26
Ketil Stølen
AccessPoint inheriting and adding
AccessPoint /* inherits Entry */
sd
AP_UserAccess
c:Controller
INF-UIT 2002 / Dialectic System Development / Slide 27
<<redefined>>
Controller
d:Door
Øystein Haugen
Ketil Stølen
Panel
Console inheriting and redefining
Console /*inherits Entry */
sd
sd
Console_NewUser
INF-UIT 2002 / Dialectic System Development / Slide 28
Console_PINChange
Øystein Haugen
<<redefined>>
Controller
Ketil Stølen
Panel: UML Statechart With GivePIN as a method
AllPanel
NoCard
recognizable
states
cardid( cid ) / GivePIN ^code(cid,pin)
OneCard
CardOut
givePIN / GivePIN ^code(cid,pin)
msg( t ) / display(t)
INF-UIT 2002 / Dialectic System Development / Slide 29
Øystein Haugen
Ketil Stølen
Panel: With GivePIN as a composite state
AllPanel
NoCard
cardid
GivePIN
^code(cid,pin)
OneCard
GivePIN
CardOut
msg( t ) / display(t)
INF-UIT 2002 / Dialectic System Development / Slide 30
Øystein Haugen
Ketil Stølen
GivePIN with substates
cancel / resetPIN
enterDigit
notOK / resetPIN
done
Verify
PIN
ok
digit / calculatePIN
INF-UIT 2002 / Dialectic System Development / Slide 31
Øystein Haugen
Ketil Stølen
Verification 1: Model checking PIN Change in Panel
sd Entry_EstablishAccess(String txt)
sd Console_PINChange
Controller
Panel
Panel
Controller
Idle
Idle
CardId()
ref
Digit()
ref
Cardid,Digit, "Try again", msg()
Entry_EstablishAccess("Illegal PIN")
Entry_GivePIN
Code(Cid, PIN)()
Code(Cid, PIN)()
msg("Try Again")()
AccLevel(m)()
loop<0,3>
opt
[PIN OK] msg("Give new PIN")()
"Give new PIN"()
"Try Again"()
GivePIN()
ref
GivePIN()
Digit()
Digit()
Entry_GivePIN
ref
msg("Give PIN again")()
Code(Cid,PIN)()
CardOut()
CardOut()
AccLevel(n)()
msg(txt)()
msg(txt)()
"Give PIN again"()
GivePIN()
ref
Entry_GivePIN
Digit()
alt
Code(Cid, PIN)()
[wrong PIN]
alt
Entry_GivePIN
Code(Cid, PIN)()
Code(Cid, PIN)()
msg("Wrong PIN")()
Idle
"Wrong PIN"()
NewCode(Cid,PIN)()
PIN OK
Idle
INF-UIT 2002 / Dialectic System Development / Slide 32
Øystein Haugen
Ketil Stølen
Model checking continued....
sd Entry_EstablishAccess(String txt)
Panel
Controller
AllPanel
Idle
CardId()
Digit()
ref
NoCard
Entry_GivePIN
Code(Cid, PIN)()
Code(Cid, PIN)()
msg("Try Again")()
AccLevel(m)()
cardid( cid ) / GivePIN ^code(cid,pin)
loop<0,3>
"Try Again"()
GivePIN()
Digit()
ref
OneCard
Entry_GivePIN
Code(Cid, PIN)()
Code(Cid,PIN)()
CardOut()
CardOut()
AccLevel(n)()
msg(txt)()
msg(txt)()
CardOut
givePIN / GivePIN ^code(cid,pin)
msg( t ) / display(t)
alt
Idle
PIN OK
INF-UIT 2002 / Dialectic System Development / Slide 33
Øystein Haugen
Ketil Stølen
Model checking continued.... ....
sd Console_PINChange
Controller
Panel
AllPanel
Idle
ref
CardOut/
^CardOut
Cardid,Digit, "Try again", msg()
Entry_EstablishAccess("Illegal PIN")
opt
[PIN OK] msg("Give new PIN")()
NoCard
"Give new PIN"()
cardid( cid ) / GivePIN ^code(cid,pin)
GivePIN()
ref
Digit()
Entry_GivePIN
OneCard
Code(Cid, PIN)()
msg("Give PIN again")()
"Give PIN again"()
GivePIN()
ref
Entry_GivePIN
alt
[wrong PIN]
msg("Wrong PIN")()
givePIN / GivePIN ^code(cid,pin)
Digit()
msg( t ) / display(t)
Code(Cid, PIN)()
"Wrong PIN"()
NewCode(Cid,PIN)()
When EstablishAccess has elapsed,
Panel is in state NoCard, but it receives
GivePIN!
Idle
INF-UIT 2002 / Dialectic System Development / Slide 35
Øystein Haugen
Ketil Stølen
Harmonizing
sd PINChange
User
___ACSystem___
ref AC_PINChange
Idle
ref
EstablishAccess ("Illegal PIN")
[PIN OK]
opt
We decide to move CardOut from
EstablishAccess to the end of
"Give new PIN"()
ref
PIN_Change
GivePIN
"Give PIN again"()
ref
GivePIN
[wrong PIN]
opt
"Wrong PIN"()
CardOut()
Idle
INF-UIT 2002 / Dialectic System Development / Slide 37
Øystein Haugen
Ketil Stølen
Verification 2: AccessPoint’s Controller
sm Controller
sd AP_UserAccess
User
Controller
Door
Idle
Idle
CardId, Digit()
ref
"try again", msg()
EstablishAccess ("Illegal
PIN")
Code / EstablishAccLev(...),CardOut
[acclev<=0] / msg("No Entry")
Code()
AccLev()
after: door/ Lock
CardOut()
[acclev>0] / msg("Please Enter"),Unlock,StartTimer(door, now+10)
Closed / StopTimer(door),Lock
after: door/ Alarm
[PIN OK]
opt
"Please Enter!"()msg("Please Enter")()
Open()
ref
Opening
AP_OpenDoor
Opened / StartTimer(door, now+30)
Idle
Closing
sd: User Access vs sm: Controller = OK!
Are we then certain that AccessPoint’s
Controller is perfect?
The User opens the door exactly when the timer
expires. door+opened in input port
INF-UIT 2002 / Dialectic System Development / Slide 38
Øystein Haugen
Ketil Stølen
Verification 3: SDL: detecting default transitions
sm Controller
• Sequence Diagrams are not
suited to uncover all possible
variants of interaction
• State Machines (JavaFrame or
UML 2) supported by
automatic techniques can find
unwanted signaling
combinations
• TIMe has several techniques to
evaluate projections of
processes to uncover the
complexity of the software
Idle
Code / EstablishAccLev(...),CardOut
[acclev<=0] / msg("No Entry")
[acclev>0] / StartTimer(door, now+10),msg("Please Enter"),Unlock
Closed / StopTimer(door),Lock
Opened
Opening
after: door/ Alarm
after: door/ ask_closed
Opened / StartTimer(door, now+30)
Closing
INF-UIT 2002 / Dialectic System Development / Slide 39
Øystein Haugen
Ketil Stølen
Formal Methods — The Buzzword of the Nineties?
The Techniques:
The Problems:
The successes
Advanced (formal)
Critical (small&complicated&important)
SDL/MSC
The theorists
Advanced (big&complex)
The practitioners
Trivial (informal)
INF-UIT 2002 / Dialectic System Development / Slide 40
Trivial (small&simple)
•
Scaling
•
Tutoring
•
Transparency
•
Automating
Øystein Haugen
Ketil Stølen
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)
INF-UIT 2002 / Dialectic System Development / Slide 41
Øystein Haugen
Ketil Stølen
The Paradox of Automatic Verification
The Verification
The Designers
The Software
process type
1(1)
Panel
GivePIN
•limited capacity
•creativity
•error prone
NoCard
OneCard
cardid
(cid)
GivePIN
GivePIN
GivePIN
Code
(cid,pin)
Code
(cid,pin)
OneCard
—
dcl cid,pin
integer;
*
CardOut
CardOut
NoCard
msg(t)
“t”
—
mismatch between the
complexity of the
verification and the
capacity of the designers
INF-UIT 2002 / Dialectic System Development / Slide 42
Øystein Haugen
•state explosion
•millions of states
•10130
Ketil Stølen
Basic model
l concurrent Active Objects (B1,B2,B3)
– finite state machines
– composites
l connectors (c1,c2,c3,c4,c5)
l external input (e1,e2)
– may come at any time
l internal signals (i1,i2)
l external output (e3)
l atomic transitions
l interleaving semantics
INF-UIT 2002 / Dialectic System Development / Slide 43
Øystein Haugen
Ketil Stølen
Atomic transitions
l A JavaFrame transition cannot be interrupted
– this means that no other transition from the same State Machine can be
started while this transition is running
– transitions from other processes may run freely in parallel!
lthis is why a State Machine should use only its own variables!
l What if a State Machine has multiple incoming connectors?
– then messages from different connectors may merge in any order just
maintaining the order on each connector
– therefore to keep the idea of atomic transitions we need to have multiple
(logical) input buffers for each component!
process B2
process B1
i2
i1
i1
Øystein Haugen
INF-UIT 2002 / Dialectic System Development / Slide 44
Ketil Stølen
Exhaustive Simulation, the simple example
system DiningPhilosophers
[Right,AskLeft]
[Left]
A
B
[Right]
[Left,AskRight]
sm A
sm B
Right
AskLeft / Left
Idle
Left / AskRight
Idle
Right / Eat,Right
Right / AskLeft
AskLeft
Error
Left / Eat,Left
AskRight
WaitR
WaitL
Left / SAVE
INF-UIT 2002 / Dialectic System Development / Slide 45
Left
AskRight / Right
Error
Right / SAVE
Øystein Haugen
Ketil Stølen
Exhaustive Simulation, the execution tree
(Idle[], Idle[])
Right
Left
(WaitR[], Idle[AskRight])
AskRight
(WaitR[Right], Idle[])
“same”
Right
(WaitR[AskLeft], WaitL[AskRight])
AskLeft
Right
(Idle[], Idle[Right])
(Idle[AskLeft], WaitL[])
(symmetrical to left side)
Right
AskRight
(WaitR[], WaitL[AskRight])
(WaitR[AskLeft], WaitL[])
AskRight
AskLeft
(WaitR[], WaitL[])
INF-UIT 2002 / Dialectic System Development / Slide 46
Øystein Haugen
Ketil Stølen
Random Exploration
l To explore some of the total state space, but not all
l Guided exploration
– traversal order
ldepth first: always explore new signals from a node
lbreadth first: explore new signals of the parent node
– other criteria
lpure probability
l Supertrace
INF-UIT 2002 / Dialectic System Development / Slide 47
Øystein Haugen
Ketil Stølen
Supertrace in a (very small) nutshell (1/2)
l Biggest practical problem with state exploration is the number of
states that must be recognized
l Second problem is the speed of the symbolic execution
l “Supertrace” is an algorithm invented by Gerard Holzmann to
overcome both these major problems
INF-UIT 2002 / Dialectic System Development / Slide 48
Øystein Haugen
Ketil Stølen
Supertrace (2/2)
l Problem: given a system state S during an execution, to know
quickly whether the execution has covered this state before
– Hash state S onto a numerical range implemented as an address space
A. The result can be called a.
– Look at the bit corresponding to the address a. If the bit in a is on, this
means that the state has been explored before!
l Solution “deficiency”
– The bit(a) is true even when the state has not been explored
– the probability for deficiency is bigger the smaller the A
l Solution improval
– Use another independent hash space and require both bits true
l Solution Coverage of significant state space
– can reach very close to 100% with only 1% of memory space needed for
traditional exhaustive search
INF-UIT 2002 / Dialectic System Development / Slide 49
Øystein Haugen
Ketil Stølen
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
INF-UIT 2002 / Dialectic System Development / Slide 50
Design rules: formally motivated design
Øystein Haugen
Ketil Stølen
Dialectic Software Development
l Software Development is a process of learning
– once you have totally understood the system you are building, it is done
l Learning is best achieved through conflict, not harmony
– discussions reveal problematic points
– silence hides critical errors
l By applying different perspectives to the system to be designed
– inconsistencies may appear
– and they must be harmonized
l Inconsistencies are not always errors!
–
–
–
–
difference of opinion
difference of understanding
misunderstanding each other
a result of partial knowledge
l Reliable systems are those that have already met challenges
INF-UIT 2002 / Dialectic System Development / Slide 51
Øystein Haugen
Ketil Stølen