A Pragmatic Approach to Model-driven Code Generation from Coloured Petri Nets Simulation Models

Transcription

1 A Pragmatic Approach to Model-driven Code Generation from Coloured Petri Nets Simulation Models Lars M. Kristensen Department of Computing Bergen University College, NORWAY / WWW:.hib.no/ansatte/lmkr SIMUTools 14-1

2 Concurrent Systems The vast majority of IT systems today can be characterised as concurrent softare systems: Structured as a collection of concurrently executing softare components and applications (parallelism). Operation relies on communication, synchronisation, and resource sharing. Internet and Web-based applications, protocols Multi-core platforms and multi-threaded softare Embedded systems and netorked control systems SIMUTools 14-3

3 Concurrent Systems Most softare development projects are concerned ith concurrent softare systems. The engineering of concurrent systems is challenging due to their complex behaviour: Concurrently executing and independently scheduled softare components. Non-deterministic and asynchronous behaviour (e.g., timeouts, message loss, external events, ). Almost impossible for softare developers to have a complete understanding of the system behaviour. Reproducing errors is often difficult. Techniques to support the engineering of reliable concurrent systems are important. SIMUTools 14-4

4 Coloured Petri Nets (CPNs) General-purpose graphical modelling language for the engineering of concurrent systems. Combines Petri Nets and a programming language: Petri Nets: [C.A. Petri 62] 1 1`rk(1) In 1 1`(rk(2),Yes) Out Votes xvote In Decision xdecision (,vote) (,decision) Idle Receive Waiting Decision Receive Decision.all () if vote = Yes then 1` else empty 1 1`rk(1) if vote = No then 1` else empty 1 1`rk(2) graphical notation concurrency communication synchronisation resource sharing CPN ML (Standard ML): data manipulation compact modelling High-Level Petri Net Out Acknoledge parameterisable models SIMUTools 14-5

5 CPN Tools [.cpntools.org ] Practical use of CPNs is supported by CPN Tools: Editing and syntax check. Interactive- and automatic simulation. Application domain visualisation. Verification based on state space exploration. Simulation-based performance analysis. SIMUTools 14-6

6 Application Areas Communication protocols and data netorks. Distributed algorithms and softare systems. Embedded systems and control softare. Business processes and orkflo modelling. Manufacturing systems. [ ] 1 2 SIMUTools 14-7

7 Examples of CPN Tools users North America Asia Europe Boeing Alcatel Austria Helett-Packard Siemens Austria Samsung Information Bang & Olufsen, Denmark Systems Nokia, Finland National Semiconductor Corp. Alcatel Business Systems, France Fujitsu Computer Products Peugeot-Citroën, France Honeyell Inc. Dornier Satellitensysteme, MITRE Corp., Germany Scalable Server Division SAP AG, Germany E.I. DuPont de Nemours Inc. Volksagen AG, Germany Federal Reserve System Alcatel Telecom, Netherlands Bell Canada Rank Xerox, Netherlands Nortel Technologies, Canada Sydkraft Konsult, Seden Central Bank of Russia Siemens Sitzerland Goldman Sachs, UK Mitsubishi Electric Corp., Japan Toshiba Corp., Japan SHARP Corp., Japan Nippon Steel Corp., Japan Hongkong Telecom Interactive Multimedia System 1 SIMUTools 14-8

8 Most Recent CPN Book K. Jensen and L.M. Kristensen. Coloured Petri Nets: Modelling and Validation of Concurrent Systems, Springer, hib.no/ansatte/lmkr/cpnbook/ K. Jensen, L.M. Kristensen, L. Wells: Coloured Petri Nets and CPN Tools for Modelling and Validation of Concurrent Systems. Intl. Journal on Softare Tools for Technology Transfer, Vol. 9, pp , Springer, SIMUTools 14-9

9 Outline of this Talk Part I: Coloured Petri Nets and CPN Tools Example: To-phase commit transaction protocol Basic concepts of Coloured Petri Nets (CPNs) Short demonstration(s) of CPN Tools Part II: Automated Code Generation Case study: The IETF WebSocket Protocol Pragmatic-annotated CPN models Template-based code generation for protocol softare SIMUTools 14-10

10 Part I: The Coloured Petri Nets Modelling Language and CPN Tools Based on: Kurt Jensen (Aarhus University, Denmark) and Lars M. Kristensen: Coloured Petri Nets - A Graphical Modelling Language for Formal Modelling and Validation of Concurrent Systems. Submitted to Communications of the ACM, February SIMUTools 14-11

11 Quick Recap: Petri Net Concepts State modelling: Places (ellipses) that may hold tokens. Marking (state): distribution of tokens on the places. Initial marking: initial state. Event (action) modelling: Transitions (rectangles) Directed arcs: connecting places and transitions. Arc eights: specifying tokens to be added/removed. Execution (token game): Current marking Transition enabling Transition ocurrence SIMUTools 14-12

12 Example: To-phase Commit Transaction Protocol A concurrent system consisting of a coordinator process and a number of orker processes: Coordinator? {Yes,No} Votes xvote {Commit,Abort} Decision xdecision Acknoledge Acknoledge s Phase 1 Phase 2 Coordinator s SIMUTools 14-13

13 CPN Model: Top-level Module The CPN model is comprised of four modules hierarchically organised in three levels. Place (ellipse) Votes Colour set / type Substitution transition (double-lined border) Coordinator xvote s Decision Coordinator xdecision Acknoledge s Name of submodule associated ith substitution transition SIMUTools 14-14

14 Colour Sets and Tokens The colour set (or type) of a place determines the kinds of tokens that may reside on a place: Colour set definitions val W = 2; colset = index rk ith 1..W; colset Vote = ith Yes No; colset xvote = product * Vote; colset Decision = ith Abort Commit; colset xdecision = product * Decision; Example values rk(1), rk(2) Votes Yes, No xvote (rk(1),yes) Decision Abort, Commit xdecision (rk(1),commit) Acknoledge Colour sets are defined using the Standard ML based programming language CPN ML. SIMUTools 14-15

15 Markings and Multi-sets A marking (state) is a distribution of tokens on the places of the model. Each place may hold a multi-set of tokens over the colour set of the place: Coordinator 1 1`rk(1) Votes xvote Decision 2 1`(rk(1),No)++ 1`(rk(2),Yes) s Multi-set notation coefficient («of») token colour (value) 2`rk(1) ++ 1`rk(2) xdecision 3 2`rk(1)++ 1`rk(2) Acknoledge union («and») Coordinator s SIMUTools 14-16

16 Coordinator Module 1`() Initial marking: determines tokens in the initial state Idle () UNIT UNIT: colour set ith a single value () «unit» Send.all () Out () Waiting Votes UNIT Votes In Port places: used for exchanging tokens ith the upper-level module. CollectVotes CollectVotes xvote Decision Out Send and ReceiveAcknoledgement are ordinary transitions. Waiting Acknoledgements Receive Acknoledgements Coordinatorxs (c,orkers) () orkers xdecision Acknoledge In Arc expressions: determine the tokens added and removed by occurrences of enabled transitions. SIMUTools 14-17

17 Initial Marking The initial marking (state) is obtained by evaluating the initial marking expressions: Idle () 1`() UNIT 1`() Idle () 1`() UNIT 1 1`() Coordinator is initially Idle Send.all () Out Send.all () Out () () Waiting Votes Waiting Votes UNIT Votes In UNIT Votes In CollectVotes xvote CollectVotes xvote CollectVotes CollectVotes Decision Out Decision Out Waiting Acknoledgements xdecision Waiting Acknoledgements xdecision Coordinatorxs Coordinatorxs (c,orkers) (c,orkers) Receive Acknoledgements orkers Acknoledge In Receive Acknoledgements orkers Acknoledge In () () SIMUTools 14-18

18 Transition Enabling A transition is enabled is there are sufficient tokens on each input place: Idle () 1`() UNIT 1 1`() 1`().all () Send Out The required tokens are determined by evaluating the input arc expressions. () Waiting Votes UNIT Enabling condition: the multi-set of tokens obtained must be contained in the multi-set of tokens present on the corresponding input place. SIMUTools 14-19

19 1`() Transition Occurrence An enabled transition may occur changing the current marking (state) of its connected places: Idle 1`() UNIT () 1`rk(1)++ 1`rk(2) 2.all () Send Out 1`() () 1`rk(1) ++ Waiting Votes UNIT 1 1`() 1`rk(2) 1 1`() Tokens removed from input places: determined by evaluating the input arc expressions. A message to each orker asking hether they. Tokens added to output places: determined by evaluating the output arc expressions. Coordinator is no Waiting for Votes SIMUTools 14-20

20 Port and Socket Places Tokens added (removed) on a port place are added (removed) on the associated socket place: Coordinator module Top-level module Idle 1`() 2 1`rk(1)++ 1`rk(2) UNIT () 1`rk(1)++ 1`rk(2) 2.all () Send Out () Votes Waiting Votes 1 1`() Coordinator xvote s UNIT Associated port and socket places constitute a compound place. Coordinator Decision xdecision Acknoledge s SIMUTools 14-21

21 s Module Top-level module s module 2 1`rk(1)++ 1`rk(2) Coordinator Coordinator Votes xvote Decision xdecision Acknoledge s s The s module models the behaviour of all orkers. In Out In Out 2 Votes xvote Decision xdecision Acknoledge 1`rk(1)++ 1`rk(2) (,vote) (,decision) Idle Receive Waiting Decision if vote = Yes then 1` else empty Receive Decision.all () 2 1`rk(1)++ 1`rk(2) if vote = No then 1` else empty SIMUTools 14-22

22 Transition Variables The arc expressions on the arcs of a transition may contain free variables: Variable declarations In 2 1`rk(1)++ 1`rk(2) Idle Receive.all () 2 1`rk(1)++ 1`rk(2) if vote = No then 1` else empty val W = 2; colset = index rk ith 1..W; var : ; colset Vote = ith Yes No; var vote : Vote; Out Votes xvote (,vote) Waiting Decision if vote = Yes then 1` else empty if-then-else expressions ith free variables vote and. Transition Receive has to free variables: vote and. SIMUTools 14-23

23 Transition Bindings Variables must be bound to values for a transition to be enabled and occur: In Out 2 Votes xvote 1`rk(1)++ 1`rk(2) (,vote) Idle Receive Waiting Decision.all () if vote = Yes then 1` else empty 2 1`rk(1)++ 1`rk(2) if vote = No then 1` else empty val W = 2; colset = index rk ith 1..W; var : ; colset Vote = ith Yes No; var vote : Vote; Possible bindings b 1Y = < = rk(1),vote = Yes > b 1N = < = rk(1),vote = No > b 2Y = < = rk(2),vote = Yes > b 2Y = < = rk(2),vote = No > The bindings correspond to possible enabling and occurrence modes of the transition. SIMUTools 14-24

24 Enabling: Transition Bindings A transition binding is enabled if there are sufficient tokens on each input place: In 2 1`rk(1) 1`rk(1)++ 1`rk(2) Idle Receive.all () 2 1`rk(1)++ 1`rk(2) if vote = No then 1` else empty Tokens required on input places are determined by evaluating the input arc expressions in the binding under consideration. Enabling condition: the multiset of tokens obtained must be contained in the multi-set of tokens present on the corresponding input place. Out Votes xvote (,vote) if vote = Yes then 1` else empty 1`rk(1) Waiting Decision b 1Y = < = rk(1),vote = Yes > SIMUTools 14-25

25 Occurrence: Transition Bindings An enabled transition binding may occur changing the current marking (state): 1`rk(1) 1`rk(1) `rk(2) In In 1 1`(rk(1),Yes) Out Out Votes (,vote) xvote 1`(rk(1),Yes) 1`rk(1) Idle Receive Waiting Decision.all () if vote = Yes then 1` else empty 21 1`rk(1)++ 1`rk(2) 1`rk(2) if vote = No then 1` else empty 1 1`rk(1) empty 1`rk(1) Tokens removed from input places: determined by evaluating the input arc expression in the binding. Tokens added to output places: determined by evaluating the output arc expressions in the binding. b 1Y = < = rk(1),vote = Yes > SIMUTools 14-26

26 Occurrence: Transition Bindings A transition may have several enabled bindings:.all ().all () In Out 2 Votes xvote 1`rk(1)++ 1`rk(2) (,vote) Idle Receive Waiting Decision if vote = Yes then 1` else empty 2 1`rk(1)++ 1`rk(2) if vote = No then 1` else empty b 1Y b 1N 1 1`rk(2) In 1 1`(rk(1),Yes) Out Votes (,vote) xvote Idle Receive Waiting Decision if vote = Yes then 1` else empty 1 1`rk(2) if vote = No then 1` else empty 1 1`rk(1) Bindings b 1Y = < = rk(1),vote = Yes > b 1N = < = rk(1),vote = No > b 2Y = < = rk(2),vote = Yes > b 2Y = < = rk(2),vote = No > In Out Idle 1 1`rk(2) 2 Votes xvote 1 1`(rk(1),No) (,vote) Receive Waiting Decision.all () if vote = Yes then 1` else empty 1`rk(1)++ 1`rk(2) if vote = No then 1` else empty SIMUTools 14-27

27 CPN Tools: Demo Simulation (Editing) SIMUTools 14-28

28 Verification and Model Checking Formal verification of CPN models can be conducted using explicit state space exploration: 5 1:2 7 2:1 11 1:1 Receive(1,No) Receive(2,Yes) Receive(2,No) CollectVotes ReceiveAcknoledgements Receive (2,No) 3 1:2 Receive (2,No) 9 2:1 CollectVotes 13 1:1 ReceiveDecision(2,abort) 16 1:1 ReceiveAcknoledgements 1 4:1 Send 2 1:4 Receive(1,Yes) 6 1:2 Receive(2,No) Receive(1,Yes) 8 2:1 CollectVotes Receive (2,Yes) 12 1:1 ReceiveDecision(1,abort) 15 1:1 ReceiveAcknoledgements Receive(1,No) Receive(2,Yes) ReceiveDecision(2,commit) 17 1:1 ReceiveDecision(2,commit) 4 1:2 Receive(1,Yes) 10 2:1 CollectVotes 14 1:2 19 2:1 ReceiveDecision(1,commit) 18 1:1 ReceiveAcknoledgements ReceiveDecision(2,commit) A state space represents all possible executions of the CPN model. Standard behavioural properties can be investigated using the state space report. Model-specific properties can be verified using queries and temporal logic model checking. Several advanced techniques available to alleviate the inherent state explosion problem. SIMUTools 14-29

29 Performance Analysis CPNs include a concept of time that can be used to model the timed taken by activities: Idle Send Waiting Votes 1 1 () 1 1`()@7 2 1`rk(1)@7+++ 1`rk(2)@7 Out A global clock representing the current model time. Tokens carry time stamps describing the earliest possible model time at hich they can be removed. Time inscriptions on transitions and arcs are used to give time stamps to the tokens produced on output places. Random distribution functions can be used in arc expressions (delays, packet loss, ). Data collection monitors and batch simulations can be used to compute performance figures. SIMUTools 14-30

30 SIMUTools 14-31

31 Perspectives on CPNs Modelling language combining Petri Nets ith a programming language. The development has been driven by an applicationoriented research agenda: Key characteristics: Education Tools and softare technology Fe but still poerful and expressive modelling constructs. Practical applications Theory Implicit concurrency inherited from Petri nets: everything is concurrent unless explicit synchronised. Verification and performance analysis supported by the same modelling language. SIMUTools 14-32

32 Part II: Automated Code Generation from CPN Simulation Models Based on: Kent I.F. Simonsen and Lars M. Kristensen: Implementing the WebSocket Protocol based on Formal Modelling and Automated Code Generation. To appear in Proc. of 14th Intl. Conference on Distributed Applications and Interoperable Systems, Springer, SIMUTools 14-33

33 Motivation and Background CPNs have been idely used for modelling and validation of communication protocols*: Application Layer Protocols: IOTP, SIP, WAP, Transport Layer Protocols: TCP, DCCP, SCTP, Routing Layer Protocols: DYMO, AODV, ERDP, It ould be desirable to use CPN models more directly for implementation of protocol softare. Limited ork on automatic code generation. This part of the talk: A nely developed approach to structurebased code generation from CPN models. Application to the IETF WebSocket Protocol. SIMUTools 14-34

34 Automated Code Generation It is difficult (in general) to recognize programming language constructs in CPNs: Votes 2 In 1`rk(1)++ 1`rk(2) Idle Receive s 2 1`rk(1)++ 1`rk(2) if vote = No then 1` else empty Coordinator xvote s Votes Out xvote (,vote) if vote = Yes then 1` else empty Decision xdecision Decision In xdecision (,decision) Waiting Coordinator Acknoledge s Acknoledge Out Receive Decision Conclusion: some additional syntactical constraints and/or annotations are required. SIMUTools 14-35

35 Requirements 1. Platform independence: Enable code generation for multiple languages / platforms. 2. Integratebility of the generated code: Upards integration: the generated code must expose an explicit interface for service invocation. Donards integration: ability for the generated code to call and rely on underlying libraries. 3. Model checking and property verification: Code generation capability should not introduce complexity problems for the verification of the model. 4. Readability of the generated code: Enable code revie of the automatically generated code. Enable performance enhancements (if required). SIMUTools 14-36

36 Overvie of Approach Modelling structure requiring the CPN model to be organised into three levels: 1. Protocol system level specifying the protocol principals and the communication channels beteen them. 2. Principal level reflecting the life-cycle and services provided by each principal in the protocol system. 3. Service level specifying the behaviour of the services provided by each principal. Annotate the CPN model elements ith code generation pragmatics to direct code generation. A template-based model-to-text transformation for generating the protocol softare. SIMUTools 14-37

37 Code Generation Pragmatics Syntactical annotations (name and attributes) that can be associated ith CPN model elements: Structural pragmatics designating principals and services. Control-flo pragmatics identifying control-flo elements and control-flo constructs. Operation pragmatics identifying data manipulation. Template binding descriptors associating the pragmatics and code generation templates: Bridges the gap beteen the platform independent CPN simulation model and the target platform considered. Code can be generated for different platforms (Groovy, Clojure, Java, Python) by changing the template binding descriptors. SIMUTools 14-38

38 The IETF WebSocket Protocol Provides a bi-directional and message-oriented service on top of the HTTP protocol: client HTTP TCP open server client WebSocket TCP open server HTTP request HTTP response TCP close message message HTTP upgrade-req HTTP response data/ping/pong TCP close message message Three main phases: connection establishment, data transfer, and connection close. SIMUTools 14-39

39 WebSocket: Protocol System The complete CPN model consists of 19 modules, 136 places, and 84 transitions: ClientToServer Send ClientToServer Receive Client <<principal>> EndPoint Channel <<channel>> EndPoint Server <<principal>> ServerToClient Receive ServerToClient Send Client EndPoint Channel EndPoint Server The <<principal>> pragmatic is used on substitution transitions to designate principals. The <<channel>> pragmatic is used to designate channels connecting the principals. SIMUTools 14-40

40 Client: Principal Level Makes explicit the services provided and their alloed order of invocation (API life-cycle): () READY 1 1`() <<LCV>> OpenConnection <<service(uri)>> ClientEstablishWebSocketConnection <<service>> specifies services that can be invoked externally. getmessage <<service()>> DataBuffer <<state>> ClientGetMessage 1 1`[] 1 1`[] [] Frames RecievePingPong <<service()>> ClientRecievePingPong PingPongBuffer <<state>> Frames OPEN <<LCV>> ClientSendMessage <<service(msg)>> ClientSendMessage SendPingPong <<service(ping)>> ClientSendPingPong <<internal>> specifies services that are invoked internally in the principal. MessageBroker MessageBroker <<internal>> 1`[] closebuffer <<state>> 1 Frames ServerClose <<internal()>> 1 1`() Close ClientClose <<service>> ClientInitiated <<LCV>> specifies lifecycle variables for services. <<state>> specifies state variables of the principal. ServerInitiated In/Out ServerToClient EndPoint CLOSED <<LCV>> ClientToServer In/Out EndPoint SIMUTools 14-41

41 Client: MessageBroker Service 1 1`() startrecieve OPEN In/Out Receive DataFrame <<rnternal()>> [true] Internal service started hen the client is in the OPEN state. (TCP, (WSFRAME frame) ::content) ServerToClient In/Out (TCP,content) EndPoint ait receive <<Id>> receive <<recieve(ch, message)>> <<mergemessages(message, fragments,clientclose)>> <<getopcode(message, opcode)>> <<validatemsg(message, fragments,clientclose)>> if(islastframe(frame)) then [] else frames frames fragments <<state>> [] 1 1`[] Frames Service entry point <<internal>> [IsPingFrame(frame) orelse IsPongFrame(frame)] dispatch <<Id(cond: '(data data) (pingpong pingpong) (close close) (nonfinal nonfinal)')>> frame frame frame [IsCloseFrame frame] frame Frame frame [frame]^^ frames [IsDataFrame frame] nonfinal <<dist(fragments)>> [IsNonFinal(frame)] frames Service-local state is specified using <<state>> frames^^[frame] pingpong <<dist(pingpongbuffer)>> <<callinternal(recievepingpong)>> PingPongBuffer <<state>> Frames frames 1 1`[] Out close <<dist(closebuffer)>> <<callinternal(serverclose)>> frames closebuffer <<state>> Frames frames^^[frame] 1 1`[] Out data <<dist(inbuffer)>> frames inbuffer <<state>> frames^^[frame] 1 1`[] Out Control-flo locations is made explicit using <<ID>> pragmatic on places. continue <<Id>> Frames next end dispatch end <<Id(cond: '(istrue OPEN)>> return <<return>> terminated <<Id>> Service exit point <<return>> SIMUTools 14-42

42 WebSocket Verification State space exploration prior to code generation used to model check basic connection properties: P1 All terminal states correspond to states in hich the WebSocket connection has been properly closed. fun isproperclosed : state -> bool List.all isproperclosed (ListTerminalStates ()) P2 From any reachable state, it is alays possible to reach a state in hich the WebSocket connection has been properly closed. HomeSpace (PredAllNodes isproperclosed) ClientM ServerM #Nodes #Arcs Time (secs) #Terminal states + - 2,747 9, ,867 9, , , SIMUTools 14-43

43 Automated Code Generation Template-based code generation consisting of three main steps: Step 1 Step 2 Step 3 OPEN In/Out [true] 1 1`() startrecieve Receive DataFrame <<rnternal()>> ait receive <<Id>> (TCP, (WSFRAME frame) ::content) ServerToClient In/Out (TCP,content) EndPoint receive <<recieve(ch, message)>> <<mergemessages(message, fragments,clientclose)>> <<getopcode(message, opcode)>> <<validatemsg(message, fragments,clientclose)>> if(islastframe(frame)) then [] else frames frames fragments <<state>> [] 1 1`[] Frames frame [frame]^^ frames frames [IsPingFrame(frame) orelse IsPongFrame(frame)] dispatch frame nonfinal <<Id(cond: '(data data) (pingpong pingpong) (close close) (nonfinal nonfinal)')>> <<dist(fragments)>> Frame [IsNonFinal(frame)] frame frame frame [IsCloseFrame frame] [IsDataFrame frame] pingpong <<dist(pingpongbuffer)>> <<callinternal(recievepingpong)>> close <<dist(closebuffer)>> <<callinternal(serverclose)>> data <<dist(inbuffer)>> frames^^[frame] frames 1 1`[] PingPongBuffer Out <<state>> Frames frames frames^^[frame] 1 1`[] closebuffer Out <<state>> Frames continue <<Id>> frames frames^^[frame] 1 1`[] inbuffer Out <<state>> Frames next end dispatch end <<Id(cond: '(istrue OPEN)>> return <<return>> terminated <<Id>> Computing Derived Pragmatics Abstract Template Tree (ATT) Construction Pragmatics binding and emitting code SIMUTools 14-44

44 PetriCode [.petricode.org] Command-line tool reading pragmatic-annotated CPN models created ith CPN Tools: Pragmatic module: parses CPN models and computes derived pragmatics. ATT construction module: performs block decomposition and constructs the ATT. Code generation module: binds templates to pragmatics and generates source code via ATT traversal. Implemented in Groovy and uses the Groovy template engine for code generation. 1 SIMUTools 14-45

45 Step 1: Derived Pragmatics Derived pragmatics computed for control-flo constructs and for data (state) manipulation. next [IsPingFrame(frame) orelse orelse IsPongFrame(frame)] PingPongBuffer <<state>> Frames startrecieve startrecieve (TCP, (WSFRAME frame) ::content) ServerToClient In/Out (TCP,content) EndPoint frames^^[frame] Out 1 1`() () pingpong <<dist(pingpongbuffer)>> <<callinternal(recievepingpong)>> frames 1 1`[] OPEN OPEN In/Out In/Out Receive DataFrame Receive <<rnternal()>> DataFrame <<rnternal()>> ait receive ait <<Id>> receive <<Id>> dispatch dispatch <<Id(cond: <<Id(cond: '(data '(data data) data) (pingpong (pingpong pingpong) pingpong) (close (close close) close) (nonfinal (nonfinal nonfinal)')>> nonfinal)')>> frame frame <<merge>> <<endloop>> continue <<Id>> closebuffer <<state>> Frames end <<Id(cond: '(istrue OPEN)>> [true] [true] receive receive <<recieve(ch, message)>> <<recieve(ch, message)>> <<mergemessages(message, fragments,clientclose)>> <<mergemessages(message, fragments,clientclose)>> <<getopcode(message, opcode)>> <<getopcode(message, opcode)>> <<validatemsg(message, fragments,clientclose)>> <<validatemsg(message, fragments,clientclose)>> frame frame frame frame [IsCloseFrame frame] frame] close close <<dist(closebuffer)>> <<callinternal(serverclose)>> frames end dispatch frames^^[frame] <<atomic>> block <<startloop> 1 1`[] Out if(islastframe(frame)) then [] else frames frames <<branch>> frame frame Frame Frame data data <<dist(inbuffer)>> return <<return>> [IsDataFrame [IsDataFrame frame] frame] frames frame Frames [frame]^^ frames fragments <<state>> [] nonfinal <<dist(fragments)>> [IsNonFinal(frame)] frames^^[frame] frames 1 <<loop>> block 1`[] inbuffer Out <<state>> <<atomic>> block terminated <<Id>> <<Id>> 1 1`[] Frames A DSL is used for specifying pragmatic descriptors. principal(origin: explicit, constraints: [levels: protocol, connectedtypes: SubstitutionTransition]) endloop(origin: derived, derviationrules: [ne PNPattern(pragmatics: [Id], minoutedges: 2, backlinks: 1)], constraints: [levels: service, connectedtypes:place]) <<sequence>> control block SIMUTools 14-46

46 Step 2: Abstract Template Tree An intermediate syntax tree representation of the pragmatic-annotated CPN model: Client <<principal>> Protocol System messagebroker<<internal>> <<internal>> <<sequence>> <<return>> <<atomic>> <<loop>> <<atomic>> <<startloop>> <<endloop>> Server <<principal>> A DSL for template bindings and linkage to the target platform. classtemplate( pragmatic: principal, template:./groovy/mainclass.tmpl, iscontainer: true) endloop( pragmatic: endloop, template:./groovy/endloop.tmpl ) <%import static org.k1s.petricode.generation.codegenerator.removeprags%>class ${name} { <% if(binding.variables.containskey('lcvs')){ for(lcv in lcvs){ %>def ${removeprags(lcv.name.text)} ${lcv.initialmarking.asstring() == '()'? '= true' : ''}\n<% } } if(binding.variables.containskey('fields')){ for(field in fields){ %>def ${removeprags(field.name.text)}<% } } %> %%yield%% } SIMUTools 14-47

47 Step 3: Emitting Code Traversal of the ATT, invocation of code generation templates, and code stitching: <%import static org.k1s.petricode.generation.codegenerator.removeprags%>class ${name} { <% if(binding.variables.containskey('lcvs')){ for(lcv in lcvs){ %>def ${removeprags(lcv.name.text)} ${lcv.initialmarking.asstring() == '()'? '= true' : ''}\n<% } } if(binding.variables.containskey('fields')){ for(field in fields){ %>def ${removeprags(field.name.text)}<% } } %> %%yield%% } SIMUTools 14-48

48 SIMUTools 14-49

49 Chat Application* WebSocket tutorial example provided ith the Java EE 7 GlassFish Application Server: Chat Server [CPN WebSocket model] Web-based Chat Client [WebSocket Broser] Chat Client [CPN WebSocket model] SIMUTools 14-50

50 Autobahn Testsuite [autobahn.s/testsuite/] Test-suite used by several industrial WebSocket implementation projects (Google Chrome, Apache Tomcat,..). Errors encountered ith the generated code: One global logical error related to the handling of fragmented messages (CPN model change). Several local errors in the code-generation templates ere encountered (template change). SIMUTools 14-51

51 Conclusions An approach alloing CPN simulation and verification models to be used for code generation: Pragmatic annotations and enforcing modelling structure. Binding pragmatics to code generation templates. Implemented in the PetriCode tool to allo for practical applications and initial evaluation. The approach has been evaluated via application to the IETF WebSocket Protocol: State space verification as feasible for verifying some basic connection properties prior to code generation. The implementation as tested for interoperability against a comprehensive benchmark test-suite ith promising results. A proof-of-concept on the scalability and feasibility of the approach for the implementation of real protocols. SIMUTools 14-52

52 SIMUTools 14-53