fdt foil no 1 overall methodology – from engineering rt systems through time; to ram. covering the...

FDTFoil no 1

Overall Methodology – from Engineering RT Systemsthrough TIMe;to RAM.

Covering the full development cycle

Supporting the whole company

Covering the full development cycle

Supporting the whole company

FDTFoil no 2

The implementation oriented approach ( the traditional)

• It may be OK for:•simple data handling •algorithmic problems•prototyping•super-humans

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

• It may be OK for:•simple data handling •algorithmic problems•prototyping•super-humans

• 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!Owner User

software

Developer

construct

validate

Communicate needs

FDTFoil no 3

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.

Models improve communication and understanding about:

• why the system is needed;

• what its functionality should be;

• how it should be implemented.

Owner User

Non-functional requirements

Functional requirements

Requirements

hardware

software

Implementation

Functional design

Implementation design

Design

Expresses needs

Fulfils needs

FDTFoil no 4

Objects and properties

Realisation sof tware electronics mechanics

I mplementation Design; Deployment

Functionality (Structure Behaviour)

Descriptions

Performance … Dependability ….

Objects Properties

Tests… Measurements

Services …

FDTFoil no 5

Coverage of the ITU-T languages and UML

Class, State- Machines Activity

Collaboration Sequence OCL Activity

Deployment Component Class

Sequence, Collaboration OCL

Sequence, Collaboration OCL

Objects Properties

Realisation

I mplementa-tion design; Deployment

Functionality

UMLsdl, SDL, ASN.1 ODL

MSC,

TTCN, MSC

CHILL, ASN.1

TTCN, MSC

Objects Properties

I TU-T UML

FDTFoil no 6

Simple MSC in a nutshell

User AC System

msc User_accepted

Code

Door unlocked

Idle

OK

Card out

diagram frame

heading

condition

output event input event

instance

Unlock

message

message to environment

instance end

FDTFoil no 7

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

• 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

FDTFoil no 8

SDL system

SYSTEM TYPE AccessControl<SYNONYM na, no INTEGER>

ap(na):

AccessPoint

Op(no):

OperationPoint

Validation

USE AccessControlLib;

usrval

op db

u

o

oa

v

v

operator

user

FDTFoil no 9

Access

ap(100):Access

op:OperationPoint

Point

UnitControl

A block type

BLOCK TYPE AccessPoint 1(2)

[(Pin)][(Pout)]

p

v

d

[(Dout)] [(Din)]

[(Req)][(Resp)]

ps(1,2):PanelServer

ds:DoorServer

UserServer

Val

[(Req)][(Resp)]

[(Pin)][(Pout)]

[(Dout)] [(Din)]

panel

door

[Accept, Reject, Ready]

[UserCode]

[Admit]

[Admitted]

user

access

DoorServer PanelServer

SIGNAL Admit, Admitted, Accept, Reject, Ready, UserCode (Integer, Integer);

p u

d a

FDTFoil no 10

MSC Normal_Accepted

ps_1 UserServerds_1

CardUserCode Validate

AcceptedAccept

PassAdmit

Open

DoorPassedAdmitted

ReadyEnterCard

msc Normal_Accepted

FDTFoil no 11

A process type 1(2)

DCL DoorTimeout Timer;

Initialise

PROCESS TYPE DoorServer 1(2)

Open VIA d

SET(NOW+ 5, DoorTimeout)

Closed

from UserServer

Admit

Open

Initialise

a

[Admit] [Admitted][Open, Close]

d

[Door Passed]

ps(1,2):PanelServer

ds:DoorServer

UserServer

FDTFoil no 12

A process type 2(2)

Closed

DoorTimeout

Close VIA d

Admitted VIA a

RESET (DoorTimeout)

DoorPassedfrom door

Open

PROCESS TYPE DoorServer 2(2)

ps(1,2):PanelServer

ds:DoorServer

UserServer

FDTFoil no 13

The User Server 1(2)1(2)PROCESS UserServer

UInitialise

UInitialise

Idle

Validation

Error

Validate (CardNo, Pin) VIA Val

DCL Pin Integer ; /* the personal identification*/ DCL CardNo Integer; /* the card identification*/ DCL CurrentPS Pid; /* the current panel server instance*/

CurrentPS:= SENDER

from PanelServer

UserCode (CardNo, Pin)

FDTFoil no 14

The User Server 2(2)

Validation

UserPassing

Idle

TO ds Admit

Accept TO CurrentPS

UserCode

ReadyTO CurrentPS

Idle

*

Error

*

Acceptedfrom Access Control

Rejectedfrom Access Control

RejectTO CurrentPS

UserCodefrom ds

Admitted

2(2)PROCESS UserServer

FDTFoil no 15

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

• 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 port FSM

timer

data

output signalinput signal

reveal/view

save queue save

timeout timer op data op

FDTFoil no 16

«block»AccessPoint

«block» BlockingAccessPoint

«block» LoggingAccessPoint

Inheritance: virtual to enable changes

«process»controller{virtual}

«process» Controller

{redefined}

«process» Controller{finalised}

SDL-2000 Foil no 17 1999-10-25Rolv Bræk; NTNU, SINTEF Birger Møller-Pedersen; Ericsson

SDL-2000 = SDL-96 + UML + -

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)

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)

UML:

Class diagrams

State Machines

Collaborations

Sequence diagrams

Deployment

...

SDL UML profile:

stereotypes,...SDL 2000:

Type references

Composite states

Actors

...

MSC 2000:


OutOfService ReleaseCard

VerifyTransaction

ReadAmount

VerifyCard

EnterAmount

SelectAmount

acceptCard(account)

Amount(amount)

otherAmount

ok

abort

outOfServiceabort

rejectTransaction

UML

Statechart


process type ATM

dcl account Account, amount Integer;

ReadAmountvia reenter

display('Limit exceeded')

RejectTransaction

VerifyCard

acceptCard( account)

transaction(account,amount)

VerifyTransaction

ejectCard

ReleaseCard

outOfService

OutOfService

aborted

ReadAmount

SDL

CompositeStates

by means ofstate references


and

SeparateStateDiagrams

withentry/exit points

• scalability• encapsulation

aborted

reenter

state ReadAmount

dcl nbr Integer;

Display('Select amount')

SelectAmount

amount(amount) otherAmount

Display('Enter amount')

EnterAmount

digit(nbr)

amount :=amount * 10 + nbr

-

ok

*

abort

reenter

amount := 0

aborted


AccessPoint

d

unlock,lock

isOpen,isClosed

c

(validity)

code

e

(outp)

(inp)

Agents

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


e

signal opened,closed;signal open, close;

C

d

unlock,lock

isOpen,isClosed

(validity)

code

(outp)

(inp)

open,closeopened,

closedcode

(validity)

AccessPoint

DoorPanel

AccessPoint


Verification and Validation in TIMe

imple-mentatio

n

instance

system

domain

config.

speci-fication

Application design

Framework design

Architecture design

needs needs

needs

Developers

Validate

validate

Market

and

users

verify

verify

verify

FDTFoil no 24

SYSTEM AccessControl 1(2)

Access

Validation

[(Pin)][(Pout)]

[(Resp)] [(Req)]ap(100):p

vAccessPanel

Doord

Operation

[(Tin)][(Tout)] [(Ack)] [(Modify)]op:

t oOperationTerminal Point

Point [(Dout)]

UnitControl

[(Din)]

Deployment mapping

HWHW

OSOS

MiddlewareMiddleware

legacylegacy app appapp app i/oi/o

Key design issues:

1. Communication

2. Process behaviour

FDTFoil no 25

ReceiverSend S:gs

message

F:gs

buffer

Send

wait

wait

sender

buffer

message

Legend:

software process

procedure

data

pointer

Signals as messages

FDTFoil no 26

Action oriented program

NEWMODE CONTROL_STATES =SET(State-1, State-2, State-3, ...);

DCL State CONTROL_STATES;

DO FOR EVER Input:= Wait(Inport,Indefinetely); 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-1

State-1State-5State-3

signal-a signal-b *

Action-1Action-1 Action-1Action-2 Action-1Action-3

What if there are many instances now?

FDTFoil no 27

Are there any problems here?

[Gb,Sa,Qa]

[Ga, Sb,Qb]B

[Aa]

[Ra,Ea]

A[Rb,Eb]

[Ab]

1

Ra

Sb

3

Gb

Aa

5

Ea

Qb

1

Sa

Ga

8

Qa

1

1

Rb

Sa

3

Ga

Ab

5

Eb

Qa

1

1

Qb

8

Gb

Sb

A B

FDTFoil no 28

-,1/-,1

Ra,1/-,1

-,2/-,1

-,3/Sb,1 -,2/Rb,1

-,1/Rb,1

-,1/-,2

Sa,1/-,3

Ra,1/Rb,1

-,2/-,2

Ra,1/-,2

!Ra !Rb

!Rb !Ra ?Rb

!Ra !Sa

?Ra

!Sb

-,3/Rb.Sb,1 -3/Sb.Rb,1

Ra.Sa,1/-,3 Sa.Ra,1/-,3

?Ra

!Rb

?Rb

?Ra ?Rb

!Sa !Ra!Sb!Rb

?Sb ?Rb

-,3/Rb,7 -,3/Sb,2

?Sa?Ra

Ra,7/-,3Sa,2/-,3

?Sb ?Sa

-,3/-,7 -,7/-,3

Sa,3/Sb,3

-,3/Sb,3

Ra,8/Ga,3

!Sa !Ga!Sb

!Sb !Sa

Sa,3/-,3

-,3/-,3

?Sa?Sb

?Sb?Sa

?Ra

-8/Ga,3

-,8/-,4

?GaUnspecified reception

Deadlock

Step 2: Generate reachability graph

Find all possible behaviours considering that a signal transfer takes two steps:

•send

•consume

Find all possible behaviours considering that a signal transfer takes two steps:

•send

•consume

FDTFoil no 29

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.

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.

1

none

Sb

3

Gb

5

none

Qb

1

Sa

Ga

8

Qa

1

A

invisible transitions

1 and 3 are notinput consistentbecause 3 does not accept Sa

5 and 1 areinput consistentbecause 1 accepts more than 5

FDTFoil no 30

Role substitution examples

• Basic a-roles provide safety properties

• Progress labels provide (some) liveness

• Basic a-roles provide safety properties

• Progress labels provide (some) liveness

Science and TechnologyNorwegian University ofNTNU

Rolv Bræk, April 2005 31

Compatibility in collaboration occurrences

Assume a collaboration with dual roles A and B. For each potential participant class:1. Derive a-role2. Ensure s-role consistency3. 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.

Class_A1

S-roleA

Class_B2

S-roleB

service-a BAa

Class_A2

S-roleA

Class_B1

S-roleB

b

1

2

1

2

1

2

1

2A2

A1 B1

B2

3

3

3

3

FDTFoil no 32

Towards the expansion theorem

• only one transition at the time (interleaving semantics)

• include all possible transitions

• only one transition at the time (interleaving semantics)

• include all possible transitions

u = a’ u1

t | u = a (t1 | u) + b (t2 | u) + a’ (t | u1 ) + (t1 | u1)

a’ a

t1|u

a’

t2|u t1|u1

a b

t = a t1 + b t2

t1 t2 u1

b

t|u1

FDTFoil no 33

Model organization in TIMe

objects properties

context

content

•••component types

(follow same pattern)

•••

•••

•••

r2

r3

r1

r2

r3

r1 design

specification

FDTFoil no 34

The systems engineering cycle/spiral

Domain

Systemdescriptions

DevelopInstall

SystemManufacture

Domaindescriptions

Model

has needs

quality =

satisfaction of needs

FDTFoil no 35

Macro Methodology

Develop System

Model Domain

Produce System

Install System

Domain

system

Domaindescription

Systemdescription

FDTFoil no 36

Develop system

Specify functionality

Design deployment

Specify realisation and tests

Design functionality

Specify deployment

Realise and test

FDTFoil no 37

First: consider the Domain

Consider the enterprise - to find the real needs (why)

Identify: stake holders; helpers; services; subjects and transactions

Consider the enterprise - to find the real needs (why)

Identify: stake holders; helpers; services; subjects and transactions

Object

models

Property

models Dictionary

Statement

Domain descriptions

An abstraction that helps to:

• understand the problem better

• communicate better

• plan better products

• facilitate reuse

An abstraction that helps to:

• understand the problem better

• communicate better

• plan better products

• facilitate reuse

FDTFoil no 38

Make Domain object models

zone door

Passive objects

group

legal user

member of

has access to consist of

1..*1

1..* 1..* 1..*

Authenticator

Authorizer

User

Card

Operator

Door

Active objects

FDTFoil no 39

Service User Access

Make Domain property models

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

MSC UserAccessGranted

User AuthorizerAuthenticator Door

Card id

Enter PIN

Givepin [PIN]Authorize[userid]

Open_LockEnter

Authenticator

Authorizer

User

Card Door

User access roles

FDTFoil no 40

Model organization

Object Models

Type

Service-A

MSC

Text

Service-APlays role of

Property Models

...

Service-B

MSC

Text

Service-BPlays role of

r2

r3

r1

r2

r3

r1

FDTFoil no 41

Collaboration diagrams

Service

roleA:TypeA

roleC:TypeC

roleB:TypeBsession1:Session

session2: Session

session3: Session

roleX roleY

roleX

roleY roleX

roleY

A collaboration with three roles and three collaboration uses:

• may define a service structure

A collaboration with three roles and three collaboration uses:

• may define a service structure

Session

roleX:TypeX roleY:TypeY

A collaboration with two roles:•may define a semantic connector

•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

FDTFoil no 42

Behaviour can be in three places:

•The collaboration itself

•The roles

•The context (scope) of the collaboration:

•The collaboration itself

•The roles

•The context (scope) of the collaboration:

Service

roleA:typeA

roleC:typeC

roleB:typeBsession1:Session

session2: Session

session3: Session

roleX roleY

roleX

roleYroleX

roleY

sd

1

3 2

sd

1

3 2

FDTFoil no 43

Application System

• An abstraction where behaviour can be understood and analyzed.

• Where service oriented application development takes place.

• A firm foundation for designing an optimal implementation.

• An abstraction where behaviour can be understood and analyzed.

• Where service oriented application development takes place.

• A firm foundation for designing an optimal implementation.

Interfacegiven

Systemgiven

Domain given

Users

Other systems

Controlled processes

Known entities

Environment SystemSystem

Service providingService needing

FDTFoil no 44

SubjectAccess Control System

The AC system: Context with domain given objects

Authorizer

AuthenticatorUser

Operator

Door

Card

AccessZone

Controlled process

Human user

Human user

Subject

FDTFoil no 45

Subject

Interface given

Access Control System

… adding interface given objects

Authorizer

AuthenticatorUser

Operator

Door

Panel

Operator

Terminal

Card

AccessZone

Controlled process

Human user

Human user

Subject

Domain given

Interface given

Domain given

Domain given

Domain given

Domain givenDomain given

Domain given

Door

Controller

Interface given

FDTFoil no 46

Subject

Interface given


… and possibly agents mirroring the environment

Authorizer

AuthenticatorUser

Operator

Door

Panel

Operator

Terminal

Card

AccessZone

Controlled process

Human user

Human user

Subject

Domain given

Interface given

Domain given

Domain given

Domain given

Domain givenDomain given

Domain given

Door

Controller

Interface given

User

Agent

Operator

Agent

System given

System given

These are all very generic and stable

FDTFoil no 47

Role behaviours and Semantic InterfacesA-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.

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.

!Insert your card

?Insert

!Take card, open door

?Remove

?Push door

!Take card, access denied

?Remove

!Take card, open door

?Remove

?Push door

!Enter personal code

?PIN

start

!Take card, access denied

?Remove

start

start

start

start

p:Panelu:User

PanelInterface

FDTFoil no 48

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.

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.

a:Authenticator

b:Authorizer

u:User

d:Door

User Access

ua:UserAgent

•The system structure help to identify service roles•Services may need roles provided by additional system objects – to be determined during design

FDTFoil no 49

Panel

Interface


Binding collaboration roles

Authorizer

AuthenticatorUser

Operator

Door

Panel

Operator

Terminal

Card

AccessZone

Door

Controller

User

Agent

Operator

Agent

User

Access

u p

u ua a

b

d

design objects shall be compatible with the roles

cf the role-play principle


Rolv Bræk, September 2005

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

Service 1

Agent 1Agent 2

Agent 3Agent 4

Agent 5

Service 3

Service 2

Vertical composition (within an agent)

Horizontal composition(within a service)


Rolv Bræk, September 2005

... with platform adaptors and edgesAmigosFramework

Kari:UserAgent

Ola:UserAgent

Mp1:MeetingPlace

t1:TermAgent

t2:TermAgent

Mp2:MeetingPlace

tlogon ulogon

tchat mpcalluchat

mpchat

tcall ucall

OSA FW OSA CallC

call

Service Platform SpecificComputing

Platform Specific

Platformindenpendent

Edge

Edge

fdt foil no 1 overall methodology – from engineering rt systems through time; to ram. covering the...

Documents