Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

LSC Revisited - From Scenarios to Distributed Components

713 views

Published on

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.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

LSC Revisited - From Scenarios to Distributed Components

  1. 1. Dirk Fahland Amir Kantor David Lo Shahar Maoz Robert Pruefer LSC RevisitedFrom Scenarios to Distributed Components
  2. 2. Setting: design a system distributed into several components 1
  3. 3. Create a model for each component model describes how the component works: behavior + interface model model model of the system 2
  4. 4. distributed componentsare hard to design…. 3
  5. 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. 6. The research problem synthesize X Z specification: system model:a set of scenarios components satisfies exhibits system behavior 6
  7. 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. 8. Live Sequence Charts life line of a component event prechart message main chartsemantics: if (and when) the prechart occurs, then also the mainchart occurs. 8
  9. 9. LSC have linear-time semantics for every runpreA if (and when) the prechart occurs, then also the mainchart occurs. A if preA preB thenpreB mainA B mainB 9
  10. 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. 11. CrossFTP: download command 11
  12. 12. CrossFTP: delete command 12
  13. 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. 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. 15. Propose: Branching-Time Interpretation for every run if (and when) the prechart occurs, there exists a continuation with the main chartDownload Delete 15
  16. 16. Branching Time vs. Disjunction if then delete or download 16
  17. 17. Branching Time vs. Disjunction 17
  18. 18. Branching Time vs. Disjunction 18
  19. 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 cases9 LSC linear (and branching)  show main invariants 19
  20. 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. 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. 22. LSC and distributed components A B Ctrace: 22
  23. 23. LSC and distributed components A a B Ctrace: a 23
  24. 24. LSC and distributed components A a b B Ctrace: a b 24
  25. 25. LSC and distributed components A a b B C ctrace: a b c 25
  26. 26. LSC and distributed components A a a b B C c atrace: a b c a is forbidden to occur while chart still not complete  abort chart (allowed because of cold events) 26
  27. 27. LSC and distributed components abort: A do not a a execute ‘d’ b B C c atrace: a b c a is forbidden to occur while chart still not complete  abort chart 27
  28. 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 systemtrace: 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. 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. 30. Solving the synthesis problem synthesize X Z specification: system model:a set of scenarios components satisfies exhibits system behavior 30
  31. 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. 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. 33. dLSC – Specification L1 R0E.ready E.ready M.readyE.ready E.alert initial run L2 L3E.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. 34. dLSC-Semantics: enabled charts L1 pre-chart of L1 occursE.ready E.ready M.ready at the end of the run L1 is enabledE.ready E.alert L2/L3 are not enabled L2 L3E.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. 35. dLSC-Semantics: append main chart L1E.ready E.ready M.ready L1 is enabled append main chart at enabling locationE.ready E.alert E.ready E.alert L2 L3E.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. 36. dLSC-Semantics: enabled charts L1 L1 is enabledE.ready E.ready M.ready L2/L3 are enabled at the same locationE.ready E.alert E.ready E.alert L2 L3E.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. 37. dLSC-Semantics: append main chart L1 L2/L3 are enabledE.ready E.ready M.ready at the same location alternativeE.ready E.alert E.ready E.alert continuations alternative runs L2 L3 M.goE.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. 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. 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. 40. Outline synthesize X Zspecification: system model:a set of dLSC Token History Net satisfies exhibits system behavior 40
  41. 41. Petri nets place token on place ‘a’ atransition  V b c W X d e Y f a Petri net N 41
  42. 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. 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. 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. 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. 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. 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. 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. 49. Token Histories [Hee et al. 2008] token history: a silent a Vtransition 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. 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. 51. Token History Nets: Guards a a aguard: 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. 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 enabledguard: d e b c V Y W X W X f d e Y not enabled a Token History Net 52
  53. 53. Outline synthesize X Zspecification: system model:a set of dLSC Token History Net satisfies exhibits system behavior 53
  54. 54. dLSC main-chart  subnet of THNE.alert M.ready M.go M.go M.treatA M.treatA M.ready M.ready M.ready 54
  55. 55. dLSC prechart  activation transition E.alert M.ready guard = pre-chart  E.alert M.readyE.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. 56. “Shared” places at start and end E.alert M.ready guard = pre-chart  E.alert M.readyE.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. 57. dLSC Specification  merge shared placesE.ready E.alert M.ready   E.ready E.alert M.goE.ready E.alert M.treatA M.ready M.ready 57
  58. 58. Merge shared places E.ready E.alert M.ready   E.ready E.alert M.go M.treatA M.ready 58
  59. 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. 60. The research problem synthesize X Z specification: system model:a set of scenarios components satisfies exhibits system behavior 60
  61. 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. 62. Preserve InteractionsdLSC event due to activation transitionTHN 62
  63. 63. Preserve InteractionsdLSCTHN changes interaction preserves interaction  forbidden  allowed 63
  64. 64. Preserve InteractionsdLSCTHN changes interaction preserves interaction  forbidden  allowed 64
  65. 65. …assign  to components (where possible) E.ready E.alert M.ready   E.ready E.alert M.go M.treatA M.ready 65
  66. 66. …assign  to components (where possible) E.ready E.alert M.ready   E.ready E.alert M.go M.treatA M.ready 66
  67. 67. …assign  to components (where possible) E.ready E.alert M.ready   E.ready E.alert M.go M.treatA M.ready 67
  68. 68. Tool Supportwww.win.tue.nl/~dfahland/tools/sam/ 68
  69. 69. Tool Supportwww.win.tue.nl/~dfahland/tools/sam/ 69
  70. 70. Tool Supportwww.win.tue.nl/~dfahland/tools/sam/ 70
  71. 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. 72. about.me/dirk.fahland @dfahland LSC RevisitedFrom Scenarios to Distributed Components

×