Transformations of Models Containing Uncertainty
•Transferir como PPTX, PDF•
1 gostou•1,362 visualizações
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.
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (6)
Semelhante a Transformations of Models Containing Uncertainty
Semelhante a Transformations of Models Containing Uncertainty (20)
Último
Último (20)
Transformations of Models Containing Uncertainty
- 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 This is Natalie. Natalie is a modeler. Natalie faces uncertainty in her everyday work.
- 3. Alternative Designs 3 Hmm, I don’t know which one, yet.
- 4. Conflicting Stakeholder Opinions 4 What do I do until they decide?
- 5. Incomplete Information 5 I don’t know everything about this, yet.
- 6. Uncertainty in software development 6 Uncertainty about the content of the model. Many design alternatives Conflicting stakeholder opinionsIncomplete information
- 7. Transformations 7 Like every good MBE practitioner, Natalie uses a variety of MTs
- 8. Transformations 8 The transformations assume inputs that don’t contain uncertainty Like every good MBE practitioner, Natalie uses a variety of MTs
- 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. Transforming Models with Uncertainty 10 Natalie should be able to use model transformations
- 11. Transforming Models with Uncertainty 11 Natalie should be able to use model transformations
- 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. 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. Outline 14 Representing Uncertainty with Partial Models Transforming Partial Models Tool Support Empirical Evaluation Reminder: Model Transformations
- 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. Example Input Model 16 Solver SolverException + effect : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC
- 17. Example Input Model 17 Solver SolverException + effect : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC Match
- 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. Example Input Model 2 19 SolverException + effect : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC
- 20. Example Input Model 2 20 SolverException + effect : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC Match
- 21. Example Input Model 2 21 SolverException + effect : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC Delete
- 22. Example Input Model 2 22 SolverException effect : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC
- 23. Example Input Model 2 23 SolverException - effect : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC Add
- 24. Example Input Model 2 24 SolverException - effect : String + getEffect() : String class1 + attribute : type class1 - attribute : type + getAttribute() :type class1 class2 RHSLHSNAC Add
- 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.
- 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. 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. 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. 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. 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
- 33. Transforming Models With Uncertainty 33 Natalie wants to apply the rule to an input with uncertainty
- 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Technique 44 class1 + attribute : type class1 - attribute : type + getAttribute():type class1 class2 RHSLHSNAC Solver SolverException + effect : String X Y X v Y
- 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. 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. 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. 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. 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. 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. 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
- 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. 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. 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. 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. 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. 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
- 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
Notas do Editor
- 1)Make a bigger point about the fact that we reuse EXISTING transformations without users needing to change anything“We can use all the nice things that you guys developed”Square to triangle transformation, what if you give it a squiggly squares? You should get squiggly triangles. Or transformation that cuts stuff in half, so squiggly total becomes squiggly halfSquiggly red to squiggly yellow.(think keynote yellow)TALK about “lifting” early: it is preservation of squigglyness
- Begin without may formula; add complexityStart with may elementsegattrs is or notBUT this is too general, I need to constraint so bring in the may formula
- Begin without may formula; add complexityStart with may elementsegattrs is or notBUT this is too general, I need to constraint so bring in the may formula
- Begin without may formula; add complexityStart with may elementsegattrs is or notBUT this is too general, I need to constraint so bring in the may formula
- Begin without may formula; add complexityStart with may elementsegattrs is or notBUT this is too general, I need to constraint so bring in the may formula
- Begin without may formula; add complexityStart with may elementsegattrs is or notBUT this is too general, I need to constraint so bring in the may formula