1. FDT Foil no 1 Overall Methodology – from Engineering RT Systems through TIMe; to RAM. Covering the full development cycle Supporting the whole company Covering the full development cycle Supporting the whole company

2. FDT Foil 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!

3. FDT Foil 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.

4. FDT Foil no 4 Objects and properties

5. FDT Foil no 5 Coverage of the ITU-T languages and UML

6. FDT Foil 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

7. FDT Foil 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

8. FDT Foil no 8 SDL system SYSTEM TYPE AccessControl ap(na): AccessPoint Op(no): Operation Point Validation USE AccessControlLib; usr val op db u o o a v v operator user

9. FDT Foil no 9 A block type

10. FDT Foil no 10 MSC Normal_Accepted ps_1 UserServer ds_1 Card UserCode Validate Accepted Accept Pass Admit Open DoorPassed Admitted Ready EnterCard msc Normal_Accepted

11. FDT Foil no 11 A process type 1(2)

12. FDT Foil no 12 A process type 2(2)

13. FDT Foil no 13 The User Server 1(2)

14. FDT Foil no 14 The User Server 2(2)

15. FDT Foil 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 opdata op

16. FDT Foil no 16 «block» AccessPoint «block» BlockingAccessPoint «block» LoggingAccessPoint Inheritance: virtual to enable changes «process» controller {virtual} «process» Controller {redefined} «process» Controller {finalised}

17. SDL-2000 Foil no 17 1999-10-25 Rolv 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:

18. SDL-2000 Foil no 18 1999-10-25 Rolv Bræk; NTNU, SINTEF Birger Møller-Pedersen; Ericsson OutOfServiceReleaseCard VerifyTransaction ReadAmount VerifyCard EnterAmount SelectAmount acceptCard(account) Amount (amount) otherAmount ok abort outOfService abort rejectTransaction UML State chart

19. SDL-2000 Foil no 19 1999-10-25 Rolv Bræk; NTNU, SINTEF Birger Møller-Pedersen; Ericsson process type ATM dcl account Account, amount Integer; ReadAmount via reenter display ('Limit exceeded') Reject Transaction VerifyCard acceptCard (account) transaction (account,amount) Verify Transaction ejectCard ReleaseCard outOfService OutOfService aborted ReadAmount SDL Composite States by means of state references

20. SDL-2000 Foil no 20 1999-10-25 Rolv Bræk; NTNU, SINTEF Birger Møller-Pedersen; Ericsson and Separate State Diagrams with entry/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

21. SDL-2000 Foil no 21 1999-10-25 Rolv Bræk; NTNU, SINTEF Birger Møller-Pedersen; Ericsson 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

22. SDL-2000 Foil no 22 1999-10-25 Rolv Bræk; NTNU, SINTEF Birger Møller-Pedersen; Ericsson e signal opened,closed; signal open, close; C d unlock, lock isOpen, isClosed (validity) code (outp) (inp) open, close opened, closed code (validity) AccessPoint Door Panel AccessPoint

23. SDL-2000 Foil no 23 1999-10-25 Rolv Bræk; NTNU, SINTEF Birger Møller-Pedersen; Ericsson Verification and Validation in TIMe imple- mentatio n instanc e system domain config. speci- fication Application design Framework design Architecture design needs Developers Validate validate Market and users verify

24. FDT Foil no 24 Deployment mapping HW OS Middleware legacy app i/o Key design issues: 1.Communication 2.Process behaviour

25. FDT Foil no 25 Signals as messages

26. FDT Foil 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-5 State-3 signal-a signal-b * Action-1 Action-2 Action-1 Action-3 What if there are many instances now?

27. FDT Foil no 27 Are there any problems here?

28. FDT Foil no 28 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

29. FDT Foil 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 not input consistent because 3 does not accept Sa 5 and 1 are input consistent because 1 accepts more than 5

30. FDT Foil 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

31. Science and Technology Norwegian University of NTNU 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-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. Class_A1 S-roleA Class_B2 S-roleB service-a B A a Class_A2 S-roleA Class_B1 S-roleB b 1 2 1 2 1 2 1 2 A2 A1 B1 B2 3 3 3 3

32. FDT Foil 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’ u 1 t | u = a (t 1 | u) + b (t 2 | u) + a’ (t | u 1 ) +  (t 1 | u 1 ) a’ a t 1 |u a’ t 2 |u t 1 |u 1  ab t = a t 1 + b t 2 t1t1 t2t2 u1u1 b t|u 1

33. FDT Foil no 33 Model organization in TIMe objects properties context content component types (follow same pattern) r2 r3 r1 r2 r3 r1 design specification

34. FDT Foil no 34 The systems engineering cycle/spiral Domain System descriptions Develop Install System Manufacture Domain descriptions Model has needs quality = satisfaction of needs

35. FDT Foil no 35 Macro Methodology

36. FDT Foil no 36 Develop system

37. FDT Foil 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

38. FDT Foil no 38 Make Domain object models zonedoor Passive objects group legal user member of has access to consist of 1..* 1 Authenticator Authorizer User Card Operator Door Active objects

39. FDT Foil 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 AuthorizerAuthenticatorDoor Card id Enter PIN Givepin [PIN] Authorize[userid] Open_Lock Enter Authenticator Authorizer User Card Door User access roles

40. FDT Foil no 40 Model organization Object Models Type Service-A MSC Text Service-A Plays role of Property Models... Service-B MSC Text Service-B Plays role of r2 r3 r1 r2 r3 r1

41. FDT Foil no 41 Collaboration diagrams Service roleA:TypeA roleC:TypeC roleB:TypeB session1: 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

42. FDT Foil 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:typeB session1: Session session2: Session session3: Session roleXroleY roleX roleY roleX roleY sd 1 3 2 1 3 2

43. FDT Foil 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. Interface given System given Domain given Users Other systems Controlled processes Known entities Environment System Service providing Service needing

44. FDT Foil no 44 Subject Access Control System The AC system: Context with domain given objects Authorizer Authenticator User Operator Door Card Access Zone Controlled process Human user Subject

45. FDT Foil no 45 Subject Interface given Access Control System … adding interface given objects Authorizer Authenticator User Operator Door Panel Operator Terminal Card Access Zone Controlled process Human user Subject Domain given Interface given Domain given Door Controller Interface given

46. FDT Foil no 46 Subject Interface given Access Control System … and possibly agents mirroring the environment Authorizer Authenticator User Operator Door Panel Operator Terminal Card Access Zone Controlled process Human user Subject Domain given Interface given Domain given Door Controller Interface given User Agent Operator Agent System given These are all very generic and stable

47. FDT Foil no 47 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. 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. p:Panel u:User PanelInterface

48. FDT Foil 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

49. FDT Foil no 49 Panel Interface Access Control System Binding collaboration roles Authorizer Authenticator User Operator Door Panel Operator Terminal Card Access Zone 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

50. Science and Technology Norwegian University of NTNU 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 1 Agent 2 Agent 3 Agent 4 Agent 5 Service 3 Service 2 Vertical composition (within an agent) Horizontal composition (within a service)

51. Science and Technology Norwegian University of NTNU Rolv Bræk, September 2005... with platform adaptors and edges AmigosFramework Kari: UserAgent Ola: UserAgent Mp1: MeetingPlace t1: TermAgent t2: TermAgent Mp2: MeetingPlace tlogonulogontchat mpcalluchat mpchat tcall ucall OSA FW OSA CallC call Service Platform Specific Computing Platform Specific Platform indenpendent Edge