Scenario-based techniques such as Message Sequence Charts (MSC) and Live Sequence Charts (LSC) are a technique to specify behavior of complex, distributed systems in an intuitive manner, particularly at early stages of system design. Despite its intuitive nature, the technique poses some challenges. The most prominent is to automatically synthesize an operational system model (a statechart or a Petri net) from a given specification; the model can then serve as a blue print for implementation in hard- and software. While MSC are essentially too weak to specify complex systems, LSCs are too strong: synthesis of components of a distributed system fails. In my talk, I will reconsider the semantics of LSC-style scenarios regarding expressive power, ability to specify distributed behaviors and solving the synthesis problem. I will show that by changing the interpretation of LSC from linear time to simple branching time semantics, one obtains a simple, yet very expressive and intuitive scenario-based specification language. By choosing partial orders instead of sequential runs as semantic domain, one can faithfully specify the behaviors of a distributed system. We call this notation distributed LSC (dLSC). As the main result, I will present a complete technique for synthesizing Petri net components from any given dLSC specification, in polynomial time. Remote seminar talk held in the Advanced Software Tools Research Seminar of S. Maoz and A. Yehudai at Tel Aviv University, January 7, 2013.

1. Dirk Fahland
Amir Kantor
David Lo
Shahar Maoz
Robert Pruefer
LSC Revisited
From Scenarios to Distributed Components

2. Setting: design a system
distributed into
several components
1

3. Create a model for each component
model
describes how the component
works: behavior + interface
model model
model of the system
2

4. distributed components
are hard to design….
3

5. Better: describe component interactions
X Z a scenario
X  describes behavior that
is relevant to a user
 as a course of actions
Y Z
specification of the system
4

6. The research problem
synthesize
X Z
specification: system model:
a set of scenarios components
satisfies exhibits
system
behavior
6

7. First: semantics of scenarios
1. how to describe all
system behaviors?
2. how to describe
X Z distributed behaviors
specification: system model:
a set of scenarios components
satisfies exhibits
system
behavior
7

8. Live Sequence Charts
life line of a component
event
prechart
message main chart
semantics: if (and when) the prechart occurs,
then also the mainchart occurs.
8

9. LSC have linear-time semantics
for every run
preA
if (and when) the prechart occurs,
then also the mainchart occurs.
A if preA
preB
then
preB mainA
B mainB
9

10. Example: FTP server
pre
Login for every run
Login if (and when) the prechart occurs,
then also the mainchart occurs.
2 alternative runs of the FTP server
10

11. CrossFTP: download command
11

12. CrossFTP: delete command
12

13. Example: FTP server
pre
Download for every run
main if (and when) the prechart occurs,
Download
then also the main chart occurs.
2 alternative runs of the FTP server
13

14. Example: FTP server
pre
Delete for every run
main if (and when) the prechart occurs,
Delete then also the main chart occurs.
2 alternative runs of the FTP server
14

15. Propose: Branching-Time Interpretation
for every run
if (and when) the prechart
occurs,
there exists a continuation
with the main chart
Download
Delete
15

16. Branching Time vs. Disjunction
if
then
delete
or
download
16

17. Branching Time vs. Disjunction
17

18. Branching Time vs. Disjunction
18

19. Branching vs Linear : CrossFTP
[Fahland, Lo, Maoz]
execution tree: width = 51 (alternative executions)
18 LSC strictly branching, incl. the 6 main FTP commands
 show different alternative use cases
9 LSC linear (and branching)
 show main invariants
19

20. Semantics of Scenarios
 LSC-style scenarios
• prechart  main chart
 complete system specification needs
• important invariants (linear time), and
• all possible use cases (branching time)
20

21. First: semantics of scenarios
1. how to describe all system
behaviors?
2. how to describe
X Z distributed behaviors
specification: system model:
a set of scenarios components
satisfies exhibits
system
behavior
21

22. LSC and distributed components
A
B C
trace:
22

23. LSC and distributed components
A
a
B C
trace: a
23

24. LSC and distributed components
A
a
b
B C
trace: a b
24

25. LSC and distributed components
A
a
b
B C
c
trace: a b c
25

26. LSC and distributed components
A
a a
b
B C
c
a
trace: a b c a
is forbidden to occur while chart still not complete
 abort chart (allowed because of cold events)
26

27. LSC and distributed components
abort:
A do not
a a execute ‘d’
b
B C
c
a
trace: a b c a
is forbidden to occur while chart still not complete
 abort chart
27

28. Problems
abort:
A do not
a a execute ‘d’
b
B C
c
a
• abort message not specified in chart,
but needed in the system
trace: a b c a • how does A know d did not happen yet?
 more messages needed
• C is independent: how can A prevent d when
abort arrives “too late”
28

29. Sequential runs vs. distributed runs
abort:
A do not
a a execute ‘d’
b
B C
c
a
 this works only in presence of a global state
 but: each component has a local state, independent of others
 distributed runs (partial orders) instead of sequential runs
29

30. Solving the synthesis problem
synthesize
X Z
specification: system model:
a set of scenarios components
satisfies exhibits
system
behavior
30

31. distributed LSC – Syntax
 an abstraction of LSC to its “core” elements
(Fahland & Kantor 2012)
b
prechart = labeled partial order
a c
+ complete synchronization
d e
main chart = labeled partial order
f d
dLSC
31

32. distributed LSC – Syntax
 an abstraction of LSC to its “core” elements
A.a
A.b
B.c
C.d
classical LSC dLSC
32

33. dLSC – Specification
L1 R0
E.ready E.ready M.ready
E.ready E.alert initial run
L2 L3
E.alert M.ready E.alert M.ready
set of dLSCs
M.go M.go
M.treatA M.transp M.treatB
M.ready C.enroll M.ready
33

34. dLSC-Semantics: enabled charts
L1
pre-chart of L1 occurs
E.ready E.ready M.ready
at the end of the run
L1 is enabled
E.ready E.alert
L2/L3 are not enabled
L2 L3
E.alert M.ready E.alert M.ready
M.go M.go
M.treatA M.transp M.treatB
M.ready C.enroll M.ready
34

35. dLSC-Semantics: append main chart
L1
E.ready E.ready M.ready
L1 is enabled
append main chart
at enabling location
E.ready E.alert E.ready E.alert
L2 L3
E.alert M.ready E.alert M.ready
M.go M.go
M.treatA M.transp M.treatB
M.ready C.enroll M.ready
35

36. dLSC-Semantics: enabled charts
L1
L1 is enabled
E.ready E.ready M.ready
L2/L3 are enabled
at the same location
E.ready E.alert E.ready E.alert
L2 L3
E.alert M.ready E.alert M.ready
M.go M.go
M.treatA M.transp M.treatB
M.ready C.enroll M.ready
36

37. dLSC-Semantics: append main chart
L1
L2/L3 are enabled
E.ready E.ready M.ready
at the same location
alternative
E.ready E.alert E.ready E.alert continuations
alternative runs
L2 L3
M.go
E.alert M.ready L1 still enabled E.alert M.ready
(concurrent to L2/L3) M.treatA
M.go M.go
M.ready
M.treatA M.transp M.treatB
M.ready C.enroll M.ready
37

38. dLSC semantics – complex pre-charts
L7 is enabled iff its prechart occurs as a dense set
at the end of the run
38

39. Semantics of a dLSC specification
 all runs that are
• built from appending main charts of enabled dLSCs
• maximal (cannot be extended)
 Expressive Power
for each transition t
p1 … pn
Petri nets t
q1 … qm
dLSC
specifications
39

40. Outline
synthesize
X Z
specification: system model:
a set of dLSC Token History Net
satisfies exhibits
system
behavior
40

41. Petri nets
place token on place ‘a’
a
transition
 V
b c
W X
d e
Y
f
a Petri net N
41

42. Distributed runs of a Petri net
a
a
 V condition = a token on ‘a’
enabled transition
b c
W X
d e
Y
f
a Petri net N a run of N
42

43. Distributed runs of a Petri net
a
a event =
occurrence of V V
 V b c
b c
conditions = tokens on ‘b’ and ‘c’
W X
d e
Y
f
a Petri net N a run of N
43

44. Distributed runs of a Petri net
a
a
V
 V b c
b c 
a
W X
d e
Y
f
a Petri net N a run of N
44

45. Distributed runs of a Petri net
a
a
V
 V b c
b c 
a
W X
V
d e b c
Y
f
a Petri net N a run of N
45

46. Distributed runs of a Petri net
a
a
V
 V b c
b c  X
a e
W X concurrent
V
events
d e b c
Y
f
a Petri net N a run of N
46

47. Distributed runs of a Petri net
a
a
V
 V b c
b c  X
a e
W X
V
d e b c
Y W
d
f
a Petri net N a run of N
47

48. Distributed runs of a Petri net
a
a
V
 V b c
b c  X
a e
W X
V
d e b c
Y W
d
f
Y
a Petri net N a run of N
f 48

49. Token Histories [Hee et al. 2008]
token history: a
silent a
V
transition V V
 V b c
X
b c  X
a e
W X V
V
V V
d e b c
V X
Y V W
d W
f V
Y Y
a Petri net N W a run of N
f 49

50. Token History Net
token history: a
a
V
V V
 V b c
X
b c  X
a e
W X V
V
V V
d e b c
V X
Y V W
d W
f V
Y Y
a Token History net N W a run of N
f 50

51. Token History Nets: Guards
a a a
guard:
V V
V
 V
b c b c
V b c

W X  is enabled a
W not enabled
V
d e
b c
Y
f  and W are enabled
a Token History Net
51

52. Guards match past events
a a a
V V
 V
b c b c
b c
 W X
W X a d e
V Y is enabled
guard:
d e
b c
V Y
W X
W X f d e
Y not enabled
a Token History Net
52

53. Outline
synthesize
X Z
specification: system model:
a set of dLSC Token History Net
satisfies exhibits
system
behavior
53

54. dLSC main-chart  subnet of THN
E.alert M.ready
M.go
M.go
M.treatA
M.treatA
M.ready
M.ready
M.ready
54

55. dLSC prechart  activation transition
E.alert M.ready
guard = pre-chart
 E.alert M.ready
E.alert M.ready guard = local history
M.go E.alert M.ready
M.go
guard = local history
M.treatA E.alert M.ready
M.treatA
M.go
M.ready
guard:
M.ready …
M.ready
55

56. “Shared” places at start and end
E.alert M.ready
guard = pre-chart
 E.alert M.ready
E.alert M.ready guard = local history
M.go E.alert M.ready
M.go
guard = local history
M.treatA E.alert M.ready
M.treatA
M.go
M.ready
guard:
M.ready …
M.ready
56

57. dLSC Specification  merge shared places
E.ready E.alert M.ready
 
E.ready E.alert M.go
E.ready E.alert
M.treatA
M.ready
M.ready
57

58. Merge shared places
E.ready
E.alert M.ready
 
E.ready E.alert M.go
M.treatA
M.ready
58

59. Synthesis procedure
 main chart  net structure
• maximal places (same label as preceding event)
are “shared”
 prechart  activation transition + history guard
• consume from shared places
 initial run (same as main chart)
 merge shared places
Theorem: resulting Token History net has same runs as
specification (up to  events)
polynomial time complexity
59

60. The research problem
synthesize
X Z
specification: system model:
a set of scenarios components
satisfies exhibits
system
behavior
60

61. Distribute THN into components
E.ready
E.alert M.ready
 
E.ready E.alert M.go
M.treatA
 assumption: event name indicates
component
group transitions to components
M.ready
where to put  transitions?
61

62. Preserve Interactions
dLSC
event due to
activation transition
THN
62

63. Preserve Interactions
dLSC
THN
changes interaction preserves interaction
 forbidden  allowed
63

64. Preserve Interactions
dLSC
THN
changes interaction preserves interaction
 forbidden  allowed
64

65. …assign  to components (where possible)
E.ready
E.alert M.ready
 
E.ready E.alert M.go
M.treatA
M.ready
65

66. …assign  to components (where possible)
E.ready
E.alert M.ready
 
E.ready E.alert M.go
M.treatA
M.ready
66

67. …assign  to components (where possible)
E.ready
E.alert M.ready
 
E.ready E.alert M.go
M.treatA
M.ready
67

68. Tool Support
www.win.tue.nl/~dfahland/tools/sam/
68

69. Tool Support
www.win.tue.nl/~dfahland/tools/sam/
69

70. Tool Support
www.win.tue.nl/~dfahland/tools/sam/
70

71. Conclusion
 distributed LSCs
• interpret LSC on partial orders,
• using simple branching time semantics
 synthesis to Token History nets
• polynomial time
• complete (also for unbounded systems)
 see also: oclets (Fahland & Pruefer 2012)
• similar to dLSC, support data & abstraction
 future work
• generate software code (process partition Petri nets)
• include data perspective
• … 71

72. about.me/dirk.fahland
@dfahland
LSC Revisited
From Scenarios to Distributed Components