Planning-Based Approach for Automating Sequence Diagram Generation

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.

Transcript

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