Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Challenges for advanced domain-specific frameworks

657 views

Published on

Presented in 2006, at the 1st ECOOP workshop on Domain-specific Program Development (http://www.labri.fr/perso/reveille/DSPD/2006/).

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Challenges for advanced domain-specific frameworks

  1. 1. Challenges for advanced gdomain-specific modeling frameworks István Ráth Dániel Varró Department of Measurement and Information Systems Budapest University of Technology and Economics
  2. 2. Aspects of language p g g engineering Concrete Modeling syntax AbstractConstraints syntax Dynamic Trans- Model semantics formations transformation
  3. 3. ViatraDSM Vi t DSM• Integrated modeling and simulation framework – integrated: learn one approach for all aspects – modeling: graphical domain-specific editors domain specific – simulation: editing-time interactive model simulation• B d on VIATRA2 and Eclipse Based d E li – Using the Graphical Editing Framework (GEF)
  4. 4. Challenges Ch ll g• Simplify diagrams – ”association = edge, class = node” arbitrary mapping – declarative mapping specification • minimize manual coding requirements• Integrate dynamic modeling (simulation) – intuitively – fully customizable
  5. 5. Domain integration: gMulti-domain modeling Domain A Domain B <<A>> <<A,B>> <<B>> Multi-domain models
  6. 6. Multi-domain modeling M lti d i d li g• How to do it? DSM Core metamodel – Light-weight approaches • Model-level tagging • M t Metamodel-levell d ll Domain A Domain B stereotyping metamodel metamodel – „Heavyweight” approach „Heavyweight • Model transformation {explicit} Domain A Domain B models models Mapped models Transformation
  7. 7. Multi-domain editors M lti d i dit• How to do it? – Light-weight approaches • Model-level tagging • M t Metamodel-levell d ll stereotyping – „Heavyweight” approach „Heavyweight Show only relevantattributesModel transformation • Problem: differencesin structure Solution: transformations!
  8. 8. Separating abstract and p gconcrete syntax
  9. 9. Separating abstract and p g concrete syntax• What? Abstract Concrete – concrete syntax ≈ di t t diagrams syntax syntax – abstract syntax ≈ logical model• Why? Test : Class Test – reduce complexity (for the user…) ID : Attribute – more possibilities ID: id0 (for the language engineer) “id0” :String
  10. 10. Objectives Obj ti• Arbitrary mapping – abstraction – di diagram-specific elements ifi l t – aggregation – decorators Logical model Diagram h0 p0 : Place :token :token :token 3 t0:Token t1:Token t2:Token
  11. 11. Architecture A hit t Diagram editing Model editing Eclipse/GEF Tree view Plugin g View classes Bi-directionalDiagram model Logical model mapping VIATRA2 modelspace Transformations
  12. 12. Proposal P l• Bi-directional mapping – goal: arbitrary mapping – means: metamodeling + model transformations Logical model Diagram model Diagram :model p0 : Place _p0 : PlaceFigure h0 :token :token :token :property 3 t0:Token t1:Token t2:Token tokenCount :Property
  13. 13. Separating abstract and p g concrete syntax• Implementation – on the model level • the user decides what to show • most tools support it – on the metamodel level • the language engineer defines diagrams – uses a separate modeling layer for graphical representation • new approach!
  14. 14. Demo #1: T k CD #1 TokenCount t
  15. 15. Dynamic modeling: y gsimulation
  16. 16. Integrated I t g t d model simulation d l i l ti• Why? – constructing new languages: no existing tool support – existing languages: insufficient tool support – ”model generate test” see changes instantly • faster development• Wh t to simulate? What t i l t ? – Translator: execute generated code g – Interpreter: direct model manipulation
  17. 17. Integrated I t g t d model simulation d l i l ti• Definition of model simulators – VIATRA2 transformations • Guided (interactive) simulation ( ) • Automatic simulation – declarative semantics: graph patterns – imperative semantics: abstract state machines – VTCL Viatra Textuall Controll Language VTCL: Vi t T t C t L • high abstraction level DSL
  18. 18. Integrated I t g t d model simulation d l i l ti• Graph patterns Definition of model simulators – precondition VIATRA2 transformations • Guided (interactive) simulation ( ) P Tr P P’ • Automatic simulation p postcondition – declarative semantics: graph patterns Tk P Tr P’ – imperative semantics: abstract state machines – VTCL Viatra Textuall Controll Language VTCL: Vi t T t C t L • high abstraction level DSL Tk
  19. 19. Demo: Petri netsD P ti t
  20. 20. Summary• ViatraDSM – integated language engineering environment• Separation of abstract and concrete syntax• Integrated interactive model simulation http://eclipse.org/GMT http://eclipse org/GMT ( (VIATRA2 feature) ea u e)

×