Transformations of Models Containing Uncertainty

1,103 views

Published on

Abstract. Model transformation techniques typically operate under the
assumption that models do not contain uncertainty. In the presence of
uncertainty, this forces modelers to either postpone working or to arti-
ficially remove it, with negative impacts on software cost and quality.
Instead, we propose a technique to adapt existing model transforma-
tions so that they can be applied to models even if they contain un-
certainty, thus enabling the use of transformations earlier. Building on
earlier work, we show how to adapt graph rewrite-based model transfor-
mations to correctly operate on May uncertainty, a technique that allows
explicit uncertainty to be expressed in any modeling language. We eval-
uate our approach on the classic Object-Relational Mapping use case,
experimenting with models of varying levels of uncertainty.

Published in: Technology, Lifestyle, Business
  • Be the first to comment

  • Be the first to like this

Transformations of Models Containing Uncertainty

  1. 1. Michalis Famelis, Rick Salay, Alessio Di Sandro, Marsha Chechik University of Toronto MODELS 2013, Miami Beach, FL Transformation of Models Containing Uncertainty
  2. 2. 2 This is Natalie. Natalie is a modeler. Natalie faces uncertainty in her everyday work.
  3. 3. Alternative Designs 3 Hmm, I don’t know which one, yet.
  4. 4. Conflicting Stakeholder Opinions 4 What do I do until they decide?
  5. 5. Incomplete Information 5 I don’t know everything about this, yet.
  6. 6. Uncertainty in software development 6 Uncertainty about the content of the model. Many design alternatives Conflicting stakeholder opinionsIncomplete information
  7. 7. Transformations 7 Like every good MBE practitioner, Natalie uses a variety of MTs
  8. 8. Transformations 8 The transformations assume inputs that don’t contain uncertainty Like every good MBE practitioner, Natalie uses a variety of MTs
  9. 9. Transformations 9 But only too often, Natalie’s models contain uncertainty: The transformations assume inputs that don’t contain uncertainty Like every good MBE practitioner, Natalie uses a variety of MTs
  10. 10. Transforming Models with Uncertainty 10 Natalie should be able to use model transformations
  11. 11. Transforming Models with Uncertainty 11 Natalie should be able to use model transformations
  12. 12. Transforming Models with Uncertainty 12 Natalie should be able to use model transformations Existing transformation techniques do not support this! To apply MTs, Natalie is forced to artificially remove uncertainty
  13. 13. Transforming Models with Uncertainty 13 We need to lift Natalie’s transformations so that they can apply to models with uncertainty Existing transformation techniques do not support this! Natalie should be able to use model transformations
  14. 14. Outline 14 Representing Uncertainty with Partial Models Transforming Partial Models Tool Support Empirical Evaluation Reminder: Model Transformations
  15. 15. Model Transformations With Graph Rewriting 15 class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 Negative Application Condition Left Hand Side Right Hand Side EncapsulateVariable refactoring: Make fields private and add getter methods unless they belong to some inner class Example rule:
  16. 16. Example Input Model 16 Solver SolverException + effect : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC
  17. 17. Example Input Model 17 Solver SolverException + effect : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC Match
  18. 18. Example Input Model 18 Solver SolverException + effect : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC NAC also matches! ABORT !
  19. 19. Example Input Model 2 19 SolverException + effect : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC
  20. 20. Example Input Model 2 20 SolverException + effect : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC Match
  21. 21. Example Input Model 2 21 SolverException + effect : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC Delete
  22. 22. Example Input Model 2 22 SolverException effect : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC
  23. 23. Example Input Model 2 23 SolverException - effect : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC Add
  24. 24. Example Input Model 2 24 SolverException - effect : String + getEffect() : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC Add
  25. 25. Example Input Model 2 25 SolverException - effect : String + getEffect() : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC No more LHS matches. Stop.
  26. 26. Outline 26 Representing Uncertainty with Partial Models
  27. 27. Representing Uncertainty Partial Models [ICSE12] • Points of uncertainty (“May elements”) explicated using syntactic annotations 27 Solver SolverException + effect : String Unsure if it should be an inner class. Unsure if we need this field.
  28. 28. Representing Uncertainty Partial Models [ICSE12] • Points of uncertainty (“May elements”) explicated using syntactic annotations Propositional variables: “the element exists” 28 Solver SolverException + effect : String X Y
  29. 29. Representing Uncertainty 29 Solver SolverException + effect : String X Y Solver SolverException Solver SolverException Solver SolverException + effect : String Solver SolverException + effect : String x=F, y=F x=T, y=F x=F, y=T x=T, y=T 4 concretizations: 4 ways to resolve uncertainty.
  30. 30. Representing Uncertainty Partial Models [ICSE12] • Points of uncertainty (“May elements”) explicated using syntactic annotations • Restrictions to the set of concretizations can be captured in the “May formula” 30 Solver SolverException + effect : String X Y X v Y
  31. 31. Representing Uncertainty 31 Solver SolverException + effect : String X Y Solver SolverException Solver SolverException Solver SolverException + effect : String Solver SolverException + effect : String x=F, y=F x=T, y=F x=F, y=T x=T, y=T X v Y
  32. 32. Outline 32 Transforming Partial Models
  33. 33. Transforming Models With Uncertainty 33 Natalie wants to apply the rule to an input with uncertainty
  34. 34. Why Is It Hard? 34 Solver SolverException + effect : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC X Y X v Y
  35. 35. Why Is It Hard? 35 Solver SolverException + effect : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC Match??? X Y X v Y
  36. 36. Why Is It Hard? 36 Solver SolverException + effect : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC Match??? X Y X v Y
  37. 37. Why Is It Hard? 37 Solver SolverException + effect : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC Should we delete? Should we add? X Y X v Y
  38. 38. Why Is It Hard? 38 Solver SolverException + effect : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC Existing transformation techniques cannot be used. X Y X v Y
  39. 39. Intuition 39 class1 + attribute : type class1 - attribute : type + getAttribute():type class1 class2 RHSLHSNAC Solver SolverException + effect : String X Y X v Y ? (And definition of correctness)
  40. 40. Intuition 40 class1 + attribute : type class1 - attribute : type + getAttribute():type class1 class2 RHSLHSNAC Solver SolverException + effect : String Solver SolverException + effect : String Solver SolverException ? (And definition of correctness)
  41. 41. Intuition 41 class1 + attribute : type class1 - attribute : type + getAttribute():type class1 class2 RHSLHSNAC Solver SolverException + effect : String Solver SolverException + effect : String Solver SolverException Solver SolverException -effect : String +getEffect() : String Solver SolverException + effect : String Solver SolverException (And definition of correctness)
  42. 42. Intuition 42 class1 + attribute : type class1 - attribute : type + getAttribute():type class1 class2 RHSLHSNAC Solver SolverException + effect : String Solver SolverException + effect : String Solver SolverException ( X∧ ¬Y ∧ ¬a ∧ ¬b) v (¬X∧ Y ∧ ¬a ∧ b) v ( X∧ Y ∧ a ∧ ¬b) Solver SolverException + - effect : String +getEffect() : String X Ya b (And definition of correctness)
  43. 43. Intuition 43 class1 + attribute : type class1 - attribute : type + getAttribute():type class1 class2 RHSLHSNAC Solver SolverException + effect : String X Y X v Y ( X∧ ¬Y ∧ ¬a ∧ ¬b) v (¬X∧ Y ∧ ¬a ∧ b) v ( X∧ Y ∧ a ∧ ¬b) Solver SolverException + - effect : String +getEffect() : String X Ya b (And definition of correctness)
  44. 44. Technique 44 class1 + attribute : type class1 - attribute : type + getAttribute():type class1 class2 RHSLHSNAC Solver SolverException + effect : String X Y X v Y
  45. 45. Technique 45 class1 + attribute : type class1 - attribute : type + getAttribute():type class1 class2 RHSLHSNAC Solver SolverException + effect : String X Y X v Y (a) Find Match Step 1: Determine applicability
  46. 46. Technique 46 class1 + attribute : type class1 - attribute : type + getAttribute():type class1 class2 RHSLHSNAC Solver SolverException + effect : String X Y X v Y (a) Find Match (b) Make sure the rule applies to at least one concretization (requires solving a SAT problem) Step 1: Determine applicability
  47. 47. Technique 47 class1 + attribute : type class1 - attribute : type + getAttribute():type class1 class2 RHSLHSNAC Solver SolverException + effect : String X Y X v Y Solver X Step 1: Determine applicability Step 2: Transform graph SolverException + effect : String Y (a) Copy over unchanged parts
  48. 48. Technique 48 class1 + attribute : type class1 - attribute : type + getAttribute():type class1 class2 RHSLHSNAC Solver SolverException + effect : String X Y X v Y Solver SolverException + - effect : String +getEffect() : String X Ya b Step 1: Determine applicability Step 2: Transform graph (a) Copy over unchanged parts (b) Perform additions and deletions Added and deleted elements become Maybe
  49. 49. Technique 49 class1 + attribute : type class1 - attribute : type + getAttribute():type class1 class2 RHSLHSNAC Solver SolverException + effect : String X Y X v Y Step 1: Determine applicability Step 2: Transform graph Step 3: Transform formula ( X∧ ¬Y ∧ ¬a ∧ ¬b) v (¬X∧ Y ∧ ¬a ∧ b) v ( X∧ Y ∧ a ∧ ¬b) Solver SolverException + - effect : String +getEffect() : String X Ya b Constrain Maybe elements to ensure each that concretization is correctly affected.
  50. 50. Overview 50 class1 + attribute : type class1 - attribute : type + getAttribute():type class1 class2 RHSLHSNAC Solver SolverException + effect : String X Y X v Y ( X∧ ¬Y ∧ ¬a ∧ ¬b) v (¬X∧ Y ∧ ¬a ∧ b) v ( X∧ Y ∧ a ∧ ¬b) Solver SolverException + - effect : String +getEffect() : String X Ya b Step 1: Determine applicability Step 2: Transform graph Step 3: Transform formula
  51. 51. Analysis In the paper: • Proof of correctness • The lifting algorithm implements our intuition • Proofs of preservation of properties: 1. Confluence The result of applying a set of rules to a model is the same regardless of the order of application or the order of matching sites. 2. Termination Repeated applications will reach a point where the rule will no longer be applicable. 51
  52. 52. Outline 52 Tool Support Empirical Evaluation
  53. 53. Tool Support • Reuse partial model implementation in MMTF (Eclipse / EMF) • Algorithm implementation 1. Determine rule applicability • Henshin and the Z3 SMT solver 2. Transform the graph • Henshin 3. Transform the formula • Java (Z3 input strings) 53 MMTF
  54. 54. Case Study • Object–relational mapping (ORM) • “Translate a class diagram to a relational database schema.” • Classic benchmark for model transformation research • Triple graph grammar with 5 layered graph rules [Varro06] 54 (Image from [Varro06])
  55. 55. Case Study • Input model: the Ecore metamodel • ORM for Ecore is important: cf. CDO and Teneo • Manually flattened inheritance hierarchy and adapted to the metamodel in [Varro06] • Resulting model had 65 model elements: • 17 classes, 17 associations, 6 generalization links, 25 attributes • Manually injected points of uncertainty to create partial models with increasing numbers of concretizations 55
  56. 56. Setup And Results • RQ: How does lifting scale with increasing uncertainty? • Varied: number of concretizations of input • Measured: time to complete the ORM transformation • Ran on Intel Core i7-2600 3.40GHz×4core, 8GB RAM, Ubuntu-64 12.10. • Runtime does not increase dramatically. Approach scales. 56 # concretizations 1 24 48 108 144 192 256 Time (seconds) 32.6 32.8 32.7 32.9 32.6 33.0 48.4
  57. 57. Summary 57 Decision deferral in the presence of uncertainty Existing techniques cannot handle uncertainty Explicit uncertainty modeling with Partial Models Syntactic annotations and May formula Transform Partial Models 1. Determine applicability 2. Transform graph 3. Transform formula Approach scales for increasing levels of uncertainty Tool Support Empirical Evaluation Case Study: Object-relational mapping for the Ecore metamodel
  58. 58. Next Steps • Implement lifted semantics as a higher-order transformation (HOT) • Given a graph rewrite rule, produce a grammar that implements the lifted semantics • Benefit: out of the box reuse of existing graph transformation tools (Henshin, AGG, etc.) • Expand lifting for other types of model uncertainty, based on the rich MAVO framework [FASE12] 58
  59. 59. Questions? icons by:
  60. 60. Bibliography [ICSE12] M. Famelis, M. Chechik, and R. Salay. “Partial Models: Towards Modeling and Reasoning with Uncertainty”. In Proc. of ICSE’12, 2012. [Varro06] D. Varro, S. Varro-Gyapay, H. Ehrig, U. Prange, and G. Taentzer. “Termination Analysis of Model Transformations by Petri Nets”. In Proc. of ICGT’06, pages 260–274, 2006. [FASE12] R. Salay, M. Famelis, and M. Chechik. “Language Independent Refinement using Partial Modeling”. In Proc. of FASE’12, 2012. 60

×