Planning-Based Approach for Automating Sequence Diagram Generation

1,347 views

Published on

The slideshow I used to defend my Computer Science M.S. Thesis, which at the time of the defense had a terrible title that was later officially changed to Planning-Based Approach for Automating Sequence Diagram Generation.

Published in: Technology
1 Comment
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total views
1,347
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
15
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide

Planning-Based Approach for Automating Sequence Diagram Generation

  1. 1. Planning Messages in Sequence Diagrams and Analyzing the Consistency of Use Cases andClass Diagrams Automatically using Design by Contract MS Thesis Defense Yaser Sulaiman Advisor Dr. Moataz Ahmed December 29, 2012
  2. 2. title“I made this [letter] very long, because I did not have theleisure to make it shorter.” —Blaise Pascal 2 Photo by y.caradec
  3. 3. Under the right conditions,sequence diagram generation is a planning problem 3
  4. 4. 4Photo by roeyahram
  5. 5. Background Sequence Diagram Generation as a Planning Problem Literature Review Research QuestionsCommuniqué: A Library for Planning Messages in Sequence Diagrams Experiments Conclusions 5Photo by Kitty Terwolbeck
  6. 6. Background 6Photo by nickwheeleroz
  7. 7. Function SystemStructure Behavior 7
  8. 8. Use CasesSequenceDiagrams System State Class TransitionDiagrams Diagrams 8
  9. 9. Class SequenceUse Case Diagram Diagram vs. Use Case Sequence Diagram Class Diagram 9
  10. 10. Design by Contract (DbC) 10
  11. 11. 11Photo by my brother Maher
  12. 12. The C in DbC Contracts (preconditions + postconditions) semantically specifythe relation between routines & callers 12
  13. 13. DbC (Eiffel) in Action-- A pop routine of a limited-capacity-- stack.pop(): T require not empty do .. ensure not full count = old count - 1 end 13
  14. 14. Object Constraint Language (OCL) UML DbC OCL 14
  15. 15. OCL in Action-- Assuming Stack has Boolean-- isEmpty() & isFull() methods &-- integer count attribute.context Stack::pop(): T pre: not self.isEmpty() post: not self.isFull() and self.count = self.count@pre - 1 15
  16. 16. Automated Plannings0 a1 s1 a2 s2 a3 … ag sg Σ = (𝑆, 𝐴, 𝛾) 16
  17. 17. s0 a1 s1 a2 s2 a3 … ag sg 17
  18. 18. Forward State-Space Search s0 … sg 18
  19. 19. Backward State-Space Search s0 … sg 19
  20. 20. Languages Design by Contract Automated Planning Stanford Research Institute Problem Solver Eiffel Action Description LanguageObject Constraint Language Planning Domain Definition Language 20
  21. 21. PDDL in Action(:action pop :parameters (?s Stack) :precondition (> (count ?s) 0) :effect (decrease (count ?s) 1)) 21
  22. 22. Sequence Diagram Generation as a Planning Problem 22Photo by miuenski
  23. 23. Correspondence between Planning and DbC Automated Planning Design by Contract Initial State Use Case Preconditions Goal Use Case Postconditions Actions Methods Action Preconditions Method Preconditions Action Effects Method Postconditions 23
  24. 24. States as Object Diagrams 24
  25. 25. s0 a1 s1 a2 s2 a3 … ag sg 25
  26. 26. Literature Review 26Photo by cj&erson
  27. 27. Paper Focus Main Idea A parser to translate a manually normalized use case to Liwu Li (2000) Model Generation message recordsKöster, Six & Winter Using refined activity diagrams to couple use cases & class Consistency Analysis (2001) models Using set theory & first-order logic to check consistencyLi, Liu & He (2005) Consistency Analysis between the use case model & the conceptual class model Using a queue & BFS to detect inconsistencies between well- Long et al. (2005) Consistency Analysis formed class & sequence diagrams A context-free grammar for use case, activity & classChanda et al. (2009) Consistency Analysis diagrams Yue, Briand & A systematic review focusing on transforming textual Model Generation Labiche (2010) requirements to analysis models in the context of MDD Yue, Briand & A technique to automatically derive analysis models from Model Generation Labiche (2010) use cases while maintaining traceability links Ghezzi, Mocci & Using symbolic model checking to cross-validate algebraic Consistency Analysis Salvaneschi (2010) specifications against intensional behavior models Using the B method to automatically analyze the consistencyde Sousa et al. (2010) Consistency Analysis of requirements RE & AutomatedVaquero et al. (2011) itSIMPLE: an IDE for automated planning applications Planning Sulaiman & Ahmed RE & Automated Using itSIMPLE to demonstrate treating sequence diagram (2012) Planning generation as a planning problem 27
  28. 28. Vaquero et al.Requirements & Automated Knowledge Planning Engineering Sulaiman & Ahmed 28
  29. 29. Message Receiver Parameter0: (LOGIN PROFILE) [1]1: (ACTIVATE ACCOUNT PROFILE) [1]2: (WITHDRAW ACCOUNT PROFILE AMOUNT) [1]3: (LOGOUT PROFILE) [1] But what about the Sender? 29
  30. 30. Research Questions 30Photo by Oberazzi
  31. 31. Q1: How can sequence diagrams be automaticallygenerated from DbC’ed use cases and class diagrams? Q2: How can that process be used to analyze the consistency between use cases and class diagrams?Q3: Which contract language should be used to enable those processes? Q4: How do the automatically-generated sequence diagrams compare to the manually-generated ones? 31
  32. 32. Communiqué: A Library for Planning Messages in Sequence Diagrams 32
  33. 33. Available on Githubhttp://git.io/communiqueImplemented in Ruby Logo by Yukihiro Matsumoto 33
  34. 34. Use Case Sequence Communiqué DiagramClass Diagram Instance 34
  35. 35. 35
  36. 36. Forward-search(s0, g) n ← [s0, the empty plan] Enqueue(n, f(n)) until queue is empty s, π ← Dequeue-min() if s satisfies g then return π applicable ← {m | precond(m) is true in s} if applicable = ϕ then next for each m ϵ applicable n ← [γ(s, m), π.m] Enqueue(n, f(n)) return failure 36
  37. 37. s0 … …… …… … … sg 37
  38. 38. The Evaluation (or Objective) FunctionCost so far; depth of n; # of previous message passes −& 𝑔 𝑛 , &&&&&&&&&&&&DFS 𝑓 𝑛 = &𝑔 𝑛 , &&&&&&&&&&&&BFS &𝑔 𝑛 + ℎ 𝑛 , A∗ Estimated cost to goal; estimated # of remaining message passes 38
  39. 39. h(n) = # objects not satisfying their goals 39
  40. 40. h(n) is not admissible: it mayoverestimate the cost of reaching the goal 40
  41. 41. h(n) non-admissibility ⇒ planner non-optimality 41
  42. 42. To determine the sender of a message, Communiqué uses thelinks between the objects along with some rules of thumb 42
  43. 43. Sender-Selection Assumptions The Actor initiates the use case Boundary objects interact with the ActorDependent objects are responsible for the objects they create A sender must already be active A sender must have a link to the receiver 43
  44. 44. OCL-Like Ruby Expressions for Pre- & Postconditionscontext Stack::pop(): T pre: not self.isEmpty() post: not self.isFull() and self.count = self.count@pre - 1pop = DbcMethod.new(:pop)pop.precondition = Proc.new { self.is_empty? }pop.postcondition = Proc.new { @count -= 1 } 44
  45. 45. Experiments 45Photo by kanonn
  46. 46. The original models were notDbC’ed; I added what I believed to be commonsense contracts 46
  47. 47. Experiment #1Simple Sequence Diagrams 47
  48. 48. Properties Management System* – Class Diagram * Aman et al. Senior Project 48
  49. 49. Add Property Modify PropertySelect Featured Property Delete Property Modify Announcement 49
  50. 50. Experiment #2More Complex Sequence Diagrams 50
  51. 51. Weather Station System* – Class Diagram * Ian Sommerville. Software Engineering 51
  52. 52. Weather Station System – Sequence DiagramTextbook’s Diagram Communiqué’s Output 52
  53. 53. 2Bwatch* – Class Diagram * Bruegge and Dutoit. OOSE using UML, Patterns & Java 53
  54. 54. 2Bwatch – Sequence Diagram 54
  55. 55. Did you notice something wrong? 55
  56. 56. 56
  57. 57. I didn’t*.. until I saw Communiqué’s output * After all, I’m not a software engineer 57
  58. 58. Textbook’s Diagram Communiqué’s Output 58
  59. 59. There is no association to support sending refresh() as it appears in the book’s sequence diagram 59
  60. 60. Now, what would Communiqué do? 60
  61. 61. Textbook’s Diagram Communiqué’s New Output 61
  62. 62. “You’re doing it wrong!” 62Photo by philomythus
  63. 63. Textbook’s Diagram Communiqué’s New Output 63
  64. 64. “Success!” 64Photo used with permission from Laney G
  65. 65. Experiment #3Effects of Noise “Irrelevant” methods 65
  66. 66. Always applicable Does nothing 66
  67. 67. These methods has an effect similar to that of a large class diagram 67
  68. 68. MeetingsMate* – Class Diagram * Al Akel et al. Senior Project 68
  69. 69. MeetingsMate – Sequence Diagram 69
  70. 70. 70
  71. 71. 71
  72. 72. 72
  73. 73. # of noise methodsDFS explored 𝑂(𝑚) states, but the solution was of length 𝑂(𝑚) BFS found the optimal solution, but it explored 𝑂(𝑐 𝑚 ) states Best-first search explored 𝑂(𝑚) and found the optimal solution 73
  74. 74. Experiment #4Non-Optimality of Communiqué’s Best-First Search 74
  75. 75. h(n) non-admissibility ⇒ planner non-optimality 75
  76. 76. 76
  77. 77. Optimal Diagram Communiqué’s Output 77
  78. 78. f(n) = g(n) + h(n) s0 0+3prepare_to_satisfy_all_objects_at_once() satisfy_objects_1_and_2() 1+3 s1 s2 1+1satisfy_all_objects_at_once() prepare_to_satisfy_object_3() 2+0 sg1 s3 2+1 satisfy_object_3() sg2 3+0 78
  79. 79. f(n) = g(n) + h(n) s0 0+3prepare_to_satisfy_all_objects_at_once() satisfy_objects_1_and_2() 1+3 s1 s2 1+1satisfy_all_objects_at_once() prepare_to_satisfy_object_3() 2+0 sg1 s3 2+1 satisfy_object_3() sg2 3+0 79
  80. 80. Experiment #5Object Instantiation 80
  81. 81. Oh how meta! 81
  82. 82. 82
  83. 83. Experiment #6Failure Handling 83
  84. 84. If Communiqué fails to find asolution, it points to possible sources of inconsistencies 84
  85. 85. 85
  86. 86. 86
  87. 87. Conclusions 87Photo by Peter Zoon
  88. 88. Action Planners Message-Passing Communiqué Action Planners Planner Typically, predefinedState Representation A set of objects state variables Specification OCL-like OCL-like Ruby STRIPS, ADL, or PDDL Language expressions Preconditions plus Constraints Preconditions only semantic class relationshipsCreation of New State Typically, not supported Object instantiations* Components 88
  89. 89. Limitations** “It’s not a bug; it’s a feature.” 89
  90. 90. Instantaneous State Transitions 90
  91. 91. Sender-Selection InaccuraciesTextbook’s Diagram Communiqué’s Output 91
  92. 92. Other LimitationsNon-Optimality of Communiqué’s Best-First Search Limited Message Types Limited Actor Support No Support for Combined Fragments Not Comparing States for Equality Possible Bias in Experiments Using Ruby for Inputs and Raw Outputs 92
  93. 93. Future Work Handle Time Explicitly Design a Better HeuristicTry Other Planning Algorithms & ApproachesUse XMI for Inputs and Outputs 93
  94. 94. …</presentation> <questions>… 94
  95. 95. Sender-Selection Rules1. If the message is the 1st in the sequence of message passes, select the Actor.2. If the receiver of the message is a boundary object, select the Actor.3. If the receiver of the message is a dependency object, select the object’s creator.4. If the message has more than one candidate sender, select the most recently activated candidate sender.5. If the message does not have any candidate sender, select the Actor. 95

×