Overall Methodology –
from Engineering RT Systems
through TIMe;
to RAM.
Covering the full development cycle
Supporting the whole company
FDT
Foil no 1
The implementation oriented approach
( the traditional)
• It may be OK for:
•simple data handling
•algorithmic problems
•prototyping
Dev eloper
•super-humans
Communicate
needs
construct
validate
Owner
FDT
Foil no 2
User
software
• Mostly it is trying to do too much
in one step:
•errorprone,
•risky,
•uncontrolled,
•expensive in the long run
• In any case there is a
comunication problem!
Modelling
- the foundation of all ENGINEERING disciplines!
Models improve communication and
understanding about:
• why the system is needed;
• what its functionality should be;
• how it should be implemented.
Requirements
Functional
requirements
Non-functional
requirements
Design
Functional
design
Expresses needs
Implementation
design
Implementation
hardware
software
Fulfils needs
User
FDT
Foil no 3
Owner
Objects and properties
Descriptions
Objects
Properties
Services …
Performance …
Dependability
….
mechanics
FDT
Foil no 4
electronics
software
Tests…
Measurements
Functionality
(Structure Behaviour)
Implementation
Design; Deployment
Realisation
Coverage of the ITU-T languages and UML
ITU-T
Objects Properties
UMLsdl,
MSC,
SDL,
ASN.1
ODL
TTCN,
MSC
CHILL,
ASN.1
TTCN,
MSC
FDT
Foil no 5
UML
Objects
Properties
Collaboration
Class,
Sequence
StateOCL
Machines
Activity
Activity
Deployment
Component
Class
Sequence,
Collaboration
OCL
Sequence,
Collaboration
OCL
Functionality
Implementation design;
Deployment
Realisation
Simple MSC in a nutshell
diagram frame
msc User_accepted
heading
condition
output event
message
AC System
User
instance
Idle
Code
input event
OK
Card out
Door unlocked
Unlock
message to
environment
instance end
FDT
Foil no 6
Features of MSC
• Inline expressions – for alternatives, loops, exceptions and options
• MSC references – such that MSCs may be referenced within other MSCs
• MSC expressions – combining MSCs to express alternatives, parallel
merge and loops
• Gates – flexible connection points between references/expressions and their
surroundings
• HMSC – High level MSC for better better overview of MSC documents
• Substitution – generalizing MSCs wrt. message, instance and MSC names
• General ordering – when neither strict order nor no order is the
situation
• MSC Document – declaring a collection of MSC and their data
FDT
Foil no 7
SDL system
USE AccessControlLib;
SYSTEM TYPE AccessControl
<SYNONYM na, no INTEGER>
user
usr
u
ap(na):
v
AccessPoint
val
a
o
operator
FDT
Foil no 8
op
o
Op(no):
Operation
Point
db
v
Validation
ap(100):
Access
Point
A block type
op:
Operation
Point
1(2)
BLOCK TYPE AccessPoint
[(Pout)] [(Pin)]
[(Pout)] [(Pin)]
p
panel
p
ps(1,2): u
PanelServer
[Accept, Reject,Ready]
user
[U serCode]
User
Server
[(Resp)]
[(Req)]
[(Req)] [(Resp)]
Val
[Admitted]
[(Din)] [(Dout)]
[(Dout)]
d
[(Din)]
door
d
ds:Door
Server
access
a
[Admit]
S IGNA L Ad mi t, Ad mitte d,
A ccep t, Rej ect, Ready,
UserCod e (Integer, Intege r);
FDT
Foil no 9
Access
Control
Unit
Door
S erve r
P anel
S erve r
v
MSC Normal_Accepted
msc Normal_Accepted
Card
UserServer
ds_1
ps_1
UserCode
Validate
Accepted
Pass
Accept
Open
DoorPassed
EnterCard
FDT
Foil no 10
Ready
Admit
Admitted
A process type 1(2)
PROCESS TYPE DoorServer
ps(1,2):
PanelServer
1(2)
User
Server
ds:Door
Server
Initialise
Initialise
Closed
[Open,
Close]
[Door
Passed]
d
[Admit] [Admitted]
Admi t
fr om
User Ser ver
Open
VIA d
SET( NOW+ 5,
Door Ti meout)
Open
FDT
Foil no 11
DCL Door Ti meout Timer;
a
A process type 2(2)
2(2)
PROCESS TYPE DoorServer
Open
f rom
door
DoorPassed
DoorTimeou t
RESET
(DoorTimeo ut)
Close
VIA d
Admitted
Closed
FDT
Foil no 12
ps(1,2):
PanelServer
VIA a
ds:Door
Server
User
Server
The User Server 1(2)
PROC ESS UserSer ver
1(2)
UIni ti al ise
Er ror
UIni ti al ise
Idl e
fr om
Panel Server
DCL Pin Integ er ;
/* the personal i dentifi cation*/
DCL CardNo Integ er ; /* the car d identificati on*/
DCL Curr entPS Pid; /* the cur r ent panel server instance*/
UserC ode
( CardNo, Pin)
Cur rentPS:=
SENDER
Vali date
( CardNo, Pin)
Vali dation
FDT
Foil no 13
VIA Val
The User Server 2(2)
2(2)
PROCESS User Server
Vali dation
Accepted
TO
Cur rentPS
TO
ds
Accept
fr om
Access
Contr ol
TO
Cur rentPS
Rej ected
fr om
Access
Contr ol
UserCode
Rej ect
Admit
Idle
UserPassing
*
fr om
ds
TO
Cur rentPS
Admitted
*
Ready
Idle
FDT
Foil no 14
UserCode
Error
SDL uses Extended FSM (EFSM)
• A process is an EFSM having his own local (data) attributes and timers
• Processes interact by means of asynchronous "signals” (messages)
• Signals are queued (FIFO) in the input port until consumed by the FSM
input signal
input port
timeout
output signal
FSM
timer op
data op
timer
save queue
save
data
FDT
Foil no 15
reveal/view
Inheritance: virtual to enable changes
«block»
AccessPoint
«block»
BlockingAccessPoint
«block»
LoggingAccessPoint
«process»
controller
{virtual}
FDT
Foil no 16
«process»
Controller
«process»
Controller
{redefined}
{finalised}
SDL-2000 = SDL-96 + UML + UML:
Class diagrams
State Machines
Collaborations
Sequence diagrams
Deployment
...
SDL UML profile:
stereotypes,...
SDL 2000:
Type references
Composite states
Actors
...
MSC 2000:
New ITU-T SG10 recommendations, due November 1999:
• SDL-2000 (Z.100)
• SDL combined with UML (SDL UML Profile - Z.109)
• MSC-2000 (Z.120)
Rolv Bræk; NTNU, SINTEF
SDL-2000 Foil no 17 1999-10-25
Birger Møller-Pedersen; Ericsson
UML
VerifyCard
acceptCard(account)
State
chart
ReadAmount
abort
SelectAmount
OutOfService
Amount
outOfService (amount)
ReleaseCard
otherAmount
abort
EnterAmount
ok
rejectTransaction
VerifyTransaction
Rolv Bræk; NTNU, SINTEF
SDL-2000 Foil no 18 1999-10-25
Birger Møller-Pedersen; Ericsson
process type ATM
SDL
Composite
States
by means of
state references
VerifyCard
acceptCard
( account)
dcl account Account,
amount Integer;
ReadAmount
outOfService
aborted
transaction
(account,amount)
Verify
Transaction
ejectCard
OutOfService
ReleaseCard
Reject
Transaction
display
('Limit exceeded')
ReadAmount
via reenter
Rolv Bræk; NTNU, SINTEF
SDL-2000 Foil no 19 1999-10-25
Birger Møller-Pedersen; Ericsson
state ReadAmount
and
dcl nbr Integer;
Separate
State
Diagrams
*
Display
('Select amount')
abort
SelectAmount
amount(amount)
with
entry/exit points
aborted
otherAmount
reenter
Display
('Enter amount')
amount := 0
reenter
EnterAmount
aborted
• scalability
• encapsulation
ok
digit(nbr)
amount :=
amount * 10 + nbr
Rolv Bræk; NTNU, SINTEF
SDL-2000 Foil no 20 1999-10-25
Birger Møller-Pedersen; Ericsson
Agents
(inp)
e
(outp)
AccessPoint
Agents:
•the main objects of SDL-2000
•unifies system, block, process, service
•has either behaviour
•or agent structure
•or both
Specified from the outside by means of
interfaces and gates
d
isOpen,
isClosed
(validity)
c
Rolv Bræk; NTNU, SINTEF
SDL-2000 Foil no 21 1999-10-25
unlock,
lock
code
Birger Møller-Pedersen; Ericsson
AccessPoint
signal opened,closed;
signal open, close;
(inp)
e
d
Panel
Door
(outp)
(validity)
opened,
closed
code
unlock,
lock
open,
close
isOpen,
isClosed
(validity)
AccessPoint
C
Rolv Bræk; NTNU, SINTEF
SDL-2000 Foil no 22 1999-10-25
code
Birger Møller-Pedersen; Ericsson
Verification and Validation in TIMe
verify
domain
verify
specification
Developers
Application design
Framework design
Architecture design
implementatio
n
Validate
Market
and
users
Rolv Bræk; NTNU, SINTEF
needs
verify
instanc
e
config.
needs
needs
validate
SDL-2000 Foil no 23 1999-10-25
system
Birger Møller-Pedersen; Ericsson
Deployment mapping
1(2)
SYSTEM AccessControl
[(P out)]
[(P in )]
P anel
[(Dout)] [(Din )]
Door
[(T out)]
app
app
Middleware
OS
HW
FDT
Foil no 24
d
ap(100):
Acces s
Point
v
[(Resp )]
[(Req)]
V alida tion
Acces s
Control
Unit
[(T in )]
Terminal
legacy
p
i/o
t
op:
Operation
Point
[(A ck)]
o
[(Modi fy)]
Operation
legacy
app
app
i/o
Key design issues:
Middleware
OS 1.
Communication
HW 2. Process behaviour
Signals as messages
Legend:
sender
Send
S:gs
wait
Receiver
software process
message
message
procedure
wait
Send
F:gs
data
buffer
FDT
Foil no 25
buffer
pointer
Action oriented program
NEWMODE CONTROL_STATES =
SET(State-1, State-2, State-3, ...);
DCL State CONTROL_STATES;
State-1
signal-a
signal-b
*
Action-1
Action-2
Action-1
Action-3
Action-1
DO FOR EVER
Input:= Wait(Inport,Indefinetely);
State-3
CASE State OF
State-1:
CASE Input OF
(Signal-a):Action-1; State:= State-3;
(Signal-b):Action-2; State:= State-5;
ELSE:
Action-3; State:= State-1;
ESAC;
State-2:
CASE Input OF
(Signal-c): ...
....
ESAC;
OD;
State-5
State-1
What if there are many instances now?
FDT
Foil no 26
Are there any problems here?
[Aa]
A
[Gb,Sa,Qa]
Foil no 27
[Rb,Eb]
[Ga, Sb,Qb]
[Ra,Ea]
FDT
B
[Ab]
A
B
1
1
Ra
Sa
Rb
Sb
Sb
Ga
Sa
Gb
3
8
3
8
Gb
Qa
Ga
Qb
Aa
1
Ab
1
5
5
Ea
Eb
Qb
Qa
1
1
Step 2: Generate reachability graph
-,1/-,1
!Ra
!Rb
Ra,1 /-,1
?Ra
-,1/Rb ,1
!Rb
-,2/-,1
!Rb
-,3/Sb ,1
?Ra
!Sb
!Sb
-,3/Rb ,7
Foil no 28
Sa,1 /-,3
!Sa
?Sa
!Ra
Ra.Sa ,1/-,3
Sa.Ra ,1/-,3
!Sa
?Ra
Sa,2 /-,3
-,3/Sb ,2
!Sa
FDT
?Ra
-,2/-,2
?Rb
!Sa
!Ra
Ra,1 /-,2
?Rb
-,3/Rb .Sb,1
-3/Sb .Rb,1
?Sb
Find all possible
behaviours
considering that a
signal transfer
takes two steps:
• send
• consume
?Rb
-,2/Rb ,1
!Rb
-,3/-,7
-,1/-,2
Ra,1 /Rb,1
!Sb
?Sb
?Rb
!Ra
-,7/-,3
?Sa
Ra,7 /-,3
!Sb
!Ga
Sa,3 /Sb,3
?Sb
Unspecified
reception
?Sa
?Ra
Sa,3 /-,3
-,3/Sb ,3
-8/Ga,3
?Sa
?Sb
-,3/-,3
Deadl ock
Ra,8 /Ga,3
?Ga
-,8/-,4
Role behaviour and input consistent roles
Deriving a role behaviour:
• Replace invisible inputs by “none” (or
just make a mental note)
• Remove invisible outputs (or just ignore
them)
The result is a process graph with only
visible inputs and outputs. (or just a
mental view on the original graph)
Input consistency:
• An invisible transition is a transition with
a none input.
• An invisible transition is input consistent
iff the next-state explicitly accepts all
the visible inputs of the (present) state.
• The role is input consistent iff every
invisible transition in the role is input
consistent.
FDT
Foil no 29
A
1
invisible transitions
1 and 3 are not
input consistent
because 3 does
not accept Sa
none
Sa
Sb
Ga
3
8
Gb
Qa
1
5
5 and 1 are
input consistent
because 1 accepts
more than 5
none
Qb
1
Role substitution examples
FDT
Foil no 30
• Basic a-roles provide safety properties
• Progress labels provide (some) liveness
Compatibility in collaboration occurrences
Class_B1
Class_A1
S-roleA
1
B1
A1
1
2
2
A
a
service-a
b
B
Class_B2
Class_A2
S-roleA
1
B2
A2
1
2
2
S-roleB
S-roleB
Assume a collaboration with dual roles A and B. For each potential participant class:
1. Derive a-role
2. Ensure s-role consistency
3. Compare a-roles, select Ai, Bj such that:
• Ai ~> A and Bj ~> B and if restriction has been applied that Ai-Bj satisfies obligation and
collaboration goals.
• Subtyping can be checked once for each participant type.
• Goal reachability can be checked once for each pair Ai, Bj of participant types.
• Need not be repeated for each instance.
• Note that the collaboration will be restricted only if the subtypes are restricted.
Rolv Bræk, April 2005
31
NTNU
Norwegian University of
Science and Technology
Towards the expansion theorem
t = a t1 + b
t2
a
t1
b
u = a’ u1
a’
t2
u1
t|u=
a (t1 | u) + b (t2 | u) + a’ (t | u1 ) + t (t1 | u1)
a
t1|u
b
t2|u
t
a’
t|u1
• only one transition at the time (interleaving semantics)
• include all possible transitions
FDT
Foil no 32
t1|u1
Model organization in TIMe
objects
context
properties
r2
specification
r1
r3
•••
content
r2
r1
r3
•••
•••
FDT
Foil no 33
component types
(follow same pattern)
•••
design
The systems engineering cycle/spiral
has needs
Domain
Model
Domain
descriptions
Install
System
Develop
Manufacture
System
descriptions
quality =
satisfaction of needs
FDT
Foil no 34
Macro Methodology
Domain
Model Domain
Install System
system
FDT
Foil no 35
Domain
description
Develop System
Produce System
System
description
Develop system
FDT
Foil no 36
Specify
functionality
Design
functionality
Specify
deployment
Design
deployment
Specify
realisation
and tests
Realise and
test
First: consider the Domain
An abstraction that helps to:
• understand the problem better
• communicate better
• plan better products
• facilitate reuse
Domain descriptions
Statement
Object
models
Property
models
Dictionary
Consider the enterprise - to find the real needs (why)
Identify: stake holders; helpers; services; subjects and transactions
FDT
Foil no 37
Make Domain object models
Active objects
Operator
User
Authenticator
Card
Passive objects
group
1..*
legal user
FDT
Foil no 38
1
Authorizer
has
access to
1..*
Door
consist of
zone
door
1..*
1..*
Make Domain property models
Service User Access
User access roles
User
Authenticator
User access:
– A user enters his
personal code, PIN
– The authenticator
checks the card id and
the PIN
– The authorizer checks
the access right of the
user
– If OK the door is
opened
– If NOK no action
Card
Foil no 39
Door
MSC UserAccessGranted
User
Authenticator
Authorizer
Door
Card id
Enter PIN
Givepin [PIN]
Authorize[userid]
Enter
FDT
Authorizer
Open_Lock
Model organization
Property Models
Service-A
Object Models
r2
Type
MSC
Service-A
r1
r3
Plays role of
Text
Service-B
r2
MSC
Service-B
r1
Plays role of
r3
Text
...
FDT
Foil no 40
Collaboration
diagrams
A collaboration with two roles:
•may define a semantic connector
Session
roleX:TypeX
A collaboration with three roles and
three collaboration uses:
• may define a service structure
roleY:TypeY
Service
•TypeA must be compatible with
(the semantic interface) TypeX
•Compatibility means that the role
behaviours must be contained in
the total behaviour of the actor
– how is a semantic variation point
in UML2
roleA:TypeA
Foil no 41
session1:
Session
roleX
roleB:TypeB
roleY
session2:
Session
session3:
Session
roleY
FDT
roleY
roleX
roleC:TypeC
roleX
Behaviour can be in three places:
• The collaboration itself
• The roles
• The context (scope) of the collaboration:
1
3
Service
sd
sd
roleA:typeA
roleX
1
3
FDT
Foil no 42
roleX
2
session3:
Session
roleY
session1:
Session
roleY
roleB:typeB
roleY
session2:
Session
roleC:typeC
roleX
2
Application System
Service needing
Environment
Known
entities
Service providing
System
Controlled
processes
Other
systems
Users
Interface
given
System
given
Domain
given
• An abstraction where behaviour can be understood and analyzed.
• Where service oriented application development takes place.
• A firm foundation for designing an optimal implementation.
FDT
Foil no 43
The AC system: Context with domain given objects
Access Control System
Subject
Human user
Card
User
Subject
Access
Zone
Authenticator
Controlled process
Door
Human user
Operator
FDT
Foil no 44
Authorizer
… adding interface given objects
Domain given
Subject
Domain given
Human user
Card
User
Domain given Domain given
Subject
Controlled process
Access
Zone
FDT
Foil no 45
Door
Access Control System
Interface given
Panel
Domain given
Authenticator
Interface given
Door
Controller
Domain given
Human user
Interface given
Operator
Operator
Terminal
Domain given
Authorizer
… and possibly agents mirroring the environment
Domain given
Subject
Domain given
Human user
Card
User
Domain given Domain given
Subject
Controlled process
Access
Zone
Door
Domain given
Human user
Operator
FDT
Foil no 46
Access Control System
Interface given
Panel
System given
Domain given
User
Agent
Authenticator
System given
Domain given
Operator
Agent
Authorizer
Interface given
Door
Controller
Interface given
Operator
Terminal
These are all very generic and stable
Role behaviours and Semantic Interfaces
A-rule: Role behaviour
Define the interface behaviour of each role in the system and in the environment.
Use the roles as basis for behaviour synthesis and validation.
A-rule: Semantic Interfaces (new)
Use collaborations to structure and define semantic interfaces.
PanelInterface
start
! Insert your car d
u:User
?Inser t
! Take card, open door
! Take card, access denied
! Enter per sonal code
?Remove
?Remove
?PIN
start
?Push door
! Take card, open door
! Take card, access denied
start
?Remove
?Remove
start
FDT
Foil no 47
?Push door
start
p:Panel
Service behaviour
A-rule: Service separation (new)
Use layering to separate service behaviour from interface given
behaviour
A-rule: Service Collaborations (new)
Use collaborations to structure service definitions.
User Access
u:User
ua:UserAgent
d:Door
a:Authenticator
b:Authorizer
•The system structure help to identify service roles
•Services may need roles provided by additional system objects
– to be determined during design
FDT
Foil no 48
Binding collaboration roles
Access Control System
Panel
Interface
Card
User
u
p
User
Agent
Panel
u
Access
Zone
Door
Authenticator
ua
Door
d
Controller
User
Access
design objects shall be compatible with the roles
cf the role-play principle
Operator
FDT
Foil no 49
a
b
Operator
Terminal
Operator
Agent
Authorizer
Fourth principle:
support the cross-cutting nature of services
•
•
•
•
a service is a collaboration between roles performed by agents
a role is the part an agent (or actor) plays in a service
agents may be involved in several services
horizontal and vertical role composition
Vertical composition (within an agent)
Service 1
Service 2
Service 3
Agent 1
NTNU
Norwegian University of
Science and Technology
Agent 2
Agent 3
Agent 4
Agent 5
Horizontal
composition
(within a service)
Rolv Bræk, September 2005
... with platform adaptors and edges
AmigosFramework
Mp1:
MeetingPlace
t1:
TermAgent
Kari:
UserAgent
tlogon
ulogon
t2:
TermAgent
Ola:
UserAgent
Mp2:
MeetingPlace
tchat
uchat
mpcall
tcall
ucall
mpchat
Platform
indenpendent
Edge
OSA FW
Computing
Platform
Specific
NTNU
Norwegian University of
Science and Technology
OSA CallC
call
Service
Platform
Specific
Edge
Rolv Bræk, September 2005