1. 1 Integrating Models with Domain-Specific Modeling Languages 18 October 2010 Steven Kelly & Juha-Pekka Tolvanen

2. © 2010 MetaCase 2 Contents Integration paradigms Single language, multiple views Integrating languages

3. © 2010 MetaCase 3 Integration Paradigms: 1. String matching in files Strings are 1-dimensional character arrays Look for same sequence, “E”, “m”, “p” etc. –Or UUID, unique identifier in XML Inefficient, hard to see, fragile –but familiar! class Employee...classMa nagerextends Employee... Developerexte ndsEmployee class Employee...classMa nagerextends Employee... Developerexte ndsEmployee

4. © 2010 MetaCase 4 Integration Paradigms: 2. Direct references in repository Works like objects in memory Efficient: Direct pointer Visible: See referrers Robust: Change once –But less familiar! Employee Manager Developer class Employee...classMa nagerextends Employee... Developerexte ndsEmployee

5. © 2010 MetaCase 5 Integration Paradigms: Tool support for direct references Concrete syntax: view UI: edit Cross-model references: link Disk representation: load vieweditlinkload XText EMF/GMF DSL Tools MPS MetaEdit+

6. © 2010 MetaCase 6 Integration Paradigms: Summary We need both! –But text and graphical tools often only offer strings Use direct references whenever possible –Make most important references visible Use string matching if you need indirection –Deliberate breaking up into exchangeable modules

7. © 2010 MetaCase 7 Contents Integration paradigms Single language, multiple views Integrating languages Summary

8. © 2010 MetaCase 8 Single language: Example model Mobile apps UI display Control flow

9. © 2010 MetaCase 9 Single language: Different notations (4.3) Metamodeler offers choice of concrete notation –Two sets of symbols –Conditional symbols No extra work for modeler E.g. simple and detailed views –Different user roles

10. © 2010 MetaCase 10 Single language: Different tool behavior (4.2) View & edit only what is relevant –Different user roles –E.g. user interaction designer vs. developer Generally UI for one user is subset of another –Extra work only for metamodeler

11. © 2010 MetaCase 11 Single language: Different representations (4.1) Tool supports multiple editors on same underlying model –Aspects, avoid information overload No extra work for metamodeler –With good tools Modeler adds layout for representation

12. © 2010 MetaCase 12 Contents Integration paradigms Single language, multiple views Integrating languages Summary

13. © 2010 MetaCase 13 Integrating languages: Best integration = no integration General purpose languages need broad coverage –Too many concepts for one diagram type –Have to split into diagram type per aspect –Each diagram type has broad coverage for that aspect Reintegration of aspects across models is hard –For tool and modeler DSM languages need only support needed subset –Can often fit several aspects in one diagram type –Save reintegration costs

14. © 2010 MetaCase 14 Integrating languages: Relationships between models Diagram element links to new subdiagram –Allows modularization, scaling Metamodeler decides what is legal –Can one element link to several subdiagrams? –Can a subdiagram be reused by several elements? The world is not a tree! –Is subdiagram type same as parent diagram? –Can an element have a different link when reused? Direct link or string indirection? Interface? Don’t show subdiagram in parent diagram! –Defeats the whole point of modularization

15. © 2010 MetaCase 15 Integrating languages: Sharing language concepts Reusing a concept in metamodels A and B –Allows reusing instances in models of type A & B Define different aspects for same element –Relationships with other elements in models Define and use a reusable element –Only exists once, not copies –Better than patterns or wizards Use directly in models or as element property

16. © 2010 MetaCase 16 Integrating languages: Create a metamodel from a model Some kinds of reuse are really instantiation –Define function => call function –Define class => create instance –Define configurable component => use & configure First model says what fields need filling in –And what the types of the content are But that’s just like a metamodel! Three levels of people –Metamodeler + Component definers + Modelers base metamodel component metamodel how components extend base metamodel

17. © 2010 MetaCase 17 Summary and recommendations Direct object references make integration easy –Building on top of XML or text will always be painful Good tools offer low effort integration –Easy for metamodeler and/or modeler –No nasty surprises when scaling to real project Avoid splitting data where possible –Integrate multiple aspects into one language Avoid large models –Split into multiple models of same type Look at users and use process –Most important factor in integration choices

18. © 2010 MetaCase 18 Europe: MetaCase Ylistönmäentie 31 FI-40500 Jyväskylä, Finland Phone +358 14 641 000 Fax +358 420 648 606 USA: MetaCase 5605 North MacArthur Blvd. 11th Floor, Irving, Texas 75038 Phone (972) 819-2039 Fax (480) 247-5501 info@metacase.com www.metacase.com Thank you! Questions?

19. © 2010 MetaCase 19 Summary Doing integration right is major factor in DSM –5-10x faster –50% fewer errors MetaCase supports you in moving to DSM Introductory package for expert developer –Book and tool: 200€ "Very practical and highly recommended" Computing Reviews "Excellent", Amazon review