Comparison of graphical DSL editors Philip De Smedt 20061649 - - PowerPoint PPT Presentation

▶
comparison of graphical dsl editors
SMART_READER_LITE
LIVE PREVIEW

Comparison of graphical DSL editors Philip De Smedt 20061649 - - PowerPoint PPT Presentation

Nov 04, 2022 271 likes •669 views

Comparison of graphical DSL editors Philip De Smedt 20061649 Overview Introduction Problem Statement Discussion - AToM3 - MetaEdit+ - Poseidon Results Demo 2 Introduction (1) Modern Software Design - Complex - How do

slide-1
SLIDE 1

Comparison of graphical DSL editors

Philip De Smedt – 20061649

slide-2
SLIDE 2

2

Overview

  • Introduction
  • Problem Statement
  • Discussion
  • AToM3
  • MetaEdit+
  • Poseidon
  • Results
  • Demo
slide-3
SLIDE 3

3

Introduction (1)

  • Modern Software Design
  • Complex
  • How do we ensure correctness?
  • Problem specific solutions required
  • Solution: Modeling & Simulation!
slide-4
SLIDE 4

4

Introduction (2)

Modeling Formalism (like Statecharts, PetriNet, Causal Block Diagram, …)

  • Syntax
  • Form and structure of valid models
  • Concrete Syntax (CS) & Abstract Syntax (AS)
slide-5
SLIDE 5

5

Introduction (2)

Modeling Formalism (like Statecharts, PetriNet, Causal Block Diagram, …)

  • Semantics
  • Meaning of the formalism
  • Operational (explicit) & Denotational (rule based)
  • Correctness with constraints
slide-6
SLIDE 6

6

Problem Statement

  • Traffic Formalism
  • AToM3
  • MetaEdit+
  • Poseidon for DSLs
  • Basic building blocks
  • Road, Fork, Join
  • Traffic Light
  • Capacity
  • Garage, Sink
slide-7
SLIDE 7

7

Discussion: AToM3 (1)

  • Meta-modeling and model-transforming
  • Python
slide-8
SLIDE 8

8

Discussion: AToM3 (1)

  • Meta-modeling and model-transforming
  • Python
  • API
  • Access the graph grammar
  • Iterate through ASG
slide-9
SLIDE 9

9

Discussion: AToM3 (2)

Abstract Syntax

  • How the language components may be connected
  • Metamodels
  • Formalism CD_ClassDiagramV3
  • Classes and Associations
  • Stored as Abstract Syntax Graphs (ASG)
  • Nodes and links in the ASG are typed
  • Relationships are subject to constraints
slide-10
SLIDE 10

10

slide-11
SLIDE 11

11

Discussion: AToM3 (3)

Concrete Syntax

  • How the language components may appear
  • No generic symbols
  • Strong binding between AS and CS
  • No implicit representation
  • One graphical representation per concept
  • Concrete Syntax may contain values extracted from their AS
  • bjects
slide-12
SLIDE 12

12

Discussion: AToM3 (4)

Correctness: constraints

  • Freedom!
  • Specified in Python
  • Name
  • Action (CREATE/EDIT/…)
  • When to check (PRE or POST condition?)
  • Constraint code
slide-13
SLIDE 13

13

Discussion: MetaEdit+ (1)

  • Repository-Based Modeling tool
slide-14
SLIDE 14

14

Discussion: MetaEdit+ (1)

  • Repository-Based Modeling tool
  • Java API
  • SOAP to communicate with models inside

MetaEdit+

  • Set up SOAP server in MetaEdit+
  • Generated Java Stubs form the bridge between

simulation code and MetaEdit+

slide-15
SLIDE 15

15

Discussion: MetaEdit+ (2)

Abstract Syntax

  • How the language components may be connected
  • Metamodels
  • Formalism GOPPRR
  • Graph – Object - Property – Port – Role – Relationship
slide-16
SLIDE 16

16

Discussion: MetaEdit+ (2)

Abstract Syntax

  • How the language components may be connected
  • Metamodels
  • Formalism GOPPRR
  • Graph – Object - Property – Port – Role – Relationship
slide-17
SLIDE 17

17

slide-18
SLIDE 18

18

Discussion: MetaEdit+ (3)

Concrete Syntax

  • How the language components may appear
  • Generic Symbol for each object
  • Custom Symbols possible
  • May contain text/property values from AS objects
  • Symbols may be shown based on a condition
  • Multiple representations/symbols per concept
slide-19
SLIDE 19

19

Discussion: MetaEdit+ (4)

Correctness: constraints

  • Limited expressibility
  • Specified in MetaEdit+ constraint tool
  • Object connectivity in a relationship
  • Object in a binding for # times (car to one road)
  • Object occurrence in a model
  • Maximum # occurences (max 5. cars)
  • Uniqueness of a property
  • (only 1 car named Volkswagen)
slide-20
SLIDE 20

20

Discussion: Poseidon (1)

  • Modeling tool integrated within Eclipse
slide-21
SLIDE 21

21

Discussion: Poseidon (1)

  • Modeling tool integrated within Eclipse
  • Poseidon for ECore
  • Graphical editor for metamodel creation
  • Poseidon
  • Graphical editor for model creation, based on a

loaded metamodel

  • Metamodels in Poseidon for ECore: synthesized

to Java code (XText)

slide-22
SLIDE 22

22

Discussion: Poseidon (2)

Abstract Syntax

  • How the language components may be connected
  • Metamodels
  • Create ECore models that can be used as metamodels
  • Three basic objects
  • PoseidonCoreNamedElement: a simple node
  • PoseidonCoreNamespace: nodes that are capable of

containing other nodes

  • PoseidonCoreDirectedRelationship: an edge (relationship)
slide-23
SLIDE 23

23

Discussion: Poseidon (3)

Concrete Syntax

  • How the language components may appear
  • Need to define all nodes/tools described in the

metamodel!

  • Rules to modify graphical representation:
  • node Sink {

metamodel_element: Sink icon: “end-state” shape: ROUNDED_RECTANGLE

}

slide-24
SLIDE 24

24

Discussion: Poseidon (4)

Correctness: constraints

  • Rules for all PoseidonCoreDirectedRelationship

elements

  • rules_for GarageToOutput {

From Garage create Output

}

slide-25
SLIDE 25

25

Example Poseidon

  • 1. Create and export your Ecore meta-model in

Poseidon for Ecore

slide-26
SLIDE 26

26

slide-27
SLIDE 27

27

slide-28
SLIDE 28

28

Example Poseidon

  • 1. Create and export your Ecore meta-model in

Poseidon for Ecore

  • 2. Generate model code and build meta-models

(Eclipse)

  • Generates Java implementations
slide-29
SLIDE 29

29

Example Poseidon

  • 1. Create and export your Ecore meta-model in

Poseidon for Ecore

  • 2. Generate model code and build meta-models

(Eclipse)

  • Generates Java implementations
  • 3. Modify default implementations
  • Diagram elements, Poseidon tools, Edge rules
slide-30
SLIDE 30

30

Example Poseidon

  • 1. Create and export your Ecore meta-model in

Poseidon for Ecore

  • 2. Generate model code and build meta-models

(Eclipse)

  • Generates Java implementations
  • 3. Modify default implementations
  • Diagram elements, Poseidon tools, Edge rules
  • 4. Generate Poseidon code
slide-31
SLIDE 31

31

slide-32
SLIDE 32

32

slide-33
SLIDE 33

33

Example Poseidon

  • 1. Create and export your Ecore meta-model in

Poseidon for Ecore

  • 2. Generate model code and build meta-models

(Eclipse)

  • Generates Java implementations
  • 3. Modify default implementations
  • Diagram elements, Poseidon tools, Edge rules
  • 4. Generate Poseidon code
  • 5. Create custom models
slide-34
SLIDE 34

34

Example Poseidon

  • 1. Create and export your Ecore meta-model in

Poseidon for Ecore

  • 2. Generate model code and build meta-models

(Eclipse)

  • Generates Java implementations
  • 3. Modify default implementations
  • Diagram elements, Poseidon tools, Edge rules
  • 4. Generate Poseidon code
  • 5. Create custom models
  • 6. Export models for simulation purposes
  • Not possible in evaluation version
slide-35
SLIDE 35

35

slide-36
SLIDE 36

36

Results

AToM3 MetaEdit+ Poseidon Repository No Yes No Transformation Tool Yes Yes No API Yes (Python) Yes (Java) Limited (Java) Abstract Syntax Class Diagram GOPPRR ECore Concrete Syntax Vector Tool Vector Tool Textual DSL Binding AS & CS Hard Soft Soft Constraints User-defined Limited No License Free Commercial Commercial

slide-37
SLIDE 37

37

Conclusion

  • Subjective
  • Stable?
  • MetaEdit+
  • Poseidon
  • Experimental/Research?
  • AToM3
slide-38
SLIDE 38

38

Demo

  • Time for some action.
  • Wanna know more? Feel free to read my

paper J