Week 3: Behind the scenes – the internal structure of a DSML
Session goal
Today, we look behind the scenes of DSML development
Copyright By PowCoder代写 加微信 powcoder
– Learn about metamodels and how they are used to represent the structure of languages and models
– Use the metamodel of our turtles language to add additional cool stuff
Style of learning
– Active work: I will introduce a topic, you will try it out on your machines
– Pair work: Two students to share a computer during the active-work sessions
– Prepared work: building on the work you have done in preparation for the session
31/01/2020 (c) King’s College London 2
What are the three key parts of a language’s definition?
In your own words…
31/01/2020 (c) King’s College London 3
What technique is used for defining abstract syntax
31/01/2020 (c) King’s College London 4
Behind the scenes of our language
The metamodel
Let’s look at what Xtext has generated for us
31/01/2020 (c) King’s College London 6
The metamodel
Let’s look at what Xtext has generated for us
– Need to go to modelling perspective
31/01/2020 (c) King’s College London 6
The metamodel
Let’s look at what Xtext has generated for us
– Need to go to modelling perspective
– Open the language project and navigate to the
‘model/generated’ folder
31/01/2020 (c) King’s College London 6
The metamodel
Let’s look at what Xtext has generated for us
– Need to go to modelling perspective
– Open the language project and navigate to the
‘model/generated’ folder
– Right click on the .ecore file and select ‘New/Other…’,
then choose ‘Representations File’
– In the next steps, make sure you initialise from a
‘semantic resource’ and that the ecore file is selected
31/01/2020 (c) King’s College London 6
The metamodel
Let’s look at what Xtext has generated for us
– Need to go to modelling perspective
– Open the language project and navigate to the
‘model/generated’ folder
– Right click on the .ecore file and select ‘New/Other…’,
then choose ‘Representations File’
– In the next steps, make sure you initialise from a
‘semantic resource’ and that the ecore file is selected – Choose the ‘Design’ view point
31/01/2020 (c) King’s College London 6
The metamodel
Let’s look at what Xtext has generated for us
– Need to go to modelling perspective
– Open the language project and navigate to the
‘model/generated’ folder
– Right click on the .ecore file and select ‘New/Other…’,
then choose ‘Representations File’
– In the next steps, make sure you initialise from a
‘semantic resource’ and that the ecore file is selected – Choose the ‘Design’ view point
– You’ll now see two items with the name of the .ecore file. Open the one inside the .aird file we have just created and right click on the package that appears.
– Select ‘ /…class diagram’ and confirm the suggested name
31/01/2020 (c) King’s College London 6
The metamodel
Let’s look at what Xtext has generated for us
– Need to go to modelling perspective
– Open the language project and navigate to the
‘model/generated’ folder
– Right click on the .ecore file and select ‘New/Other…’,
then choose ‘Representations File’
– In the next steps, make sure you initialise from a
‘semantic resource’ and that the ecore file is selected – Choose the ‘Design’ view point
– You’ll now see two items with the name of the .ecore file. Open the one inside the .aird file we have just created and right click on the package that appears.
– Select ‘ /…class diagram’ and confirm the suggested name
– Explore the diagram
31/01/2020 (c) King’s College London 6
The metamodel
Let’s look at what Xtext has generated for us
– Need to go to modelling perspective
– Open the language project and navigate to the
‘model/generated’ folder
– Right click on the .ecore file and select ‘New/Other…’,
then choose ‘Representations File’
– In the next steps, make sure you initialise from a
‘semantic resource’ and that the ecore file is selected – Choose the ‘Design’ view point
– You’ll now see two items with the name of the .ecore file. Open the one inside the .aird file we have just created and right click on the package that appears.
– Select ‘ /…class diagram’ and confirm the suggested name
– Explore the diagram
31/01/2020 (c) King’s College London 6
In your pairs
– Open Eclipse
– Open your turtles language
– Explore the generated model
You have 5 minutes
Download last step as tag DSML_v4_scope_tests from the Turtle DSML repository linked from KEATS
31/01/2020 (c) King’s College London 7
Comparing diagram and grammar
Diagram shows the language metamodel
– The key concepts in the language and their relationships
– Without worrying about how they are represented in text
– Information in any model in our language can be captured as an instance of these classes
Generated from Xtext grammar
– Loosely: every rule becomes a class
– Variable names in rule become attributes / references in the metamodel
– Or-rules become inheritance hierarchies – Mapping can be controlled
– Metamodel (abstract syntax) doesn’t need to be structured the same way as concrete syntax – See more later
31/01/2020 (c) King’s College London 8
Demo: comparing the metamodel and the grammar
Metamodels
A metamodel is a description of a modelling language
– A model of models
– Defines all concepts that can be used within a language
– A model is constructed using the syntax defined by a metamodel
You know a range of metamodels:
UML class diagrams
UML state machine diagrams Relational data model diagrams …
31/01/2020 (c) King’s College London 10
Metamodelling
Process of describing new modelling languages
Use meta-models to define modelling languages
Requires meta-language, a language for defining meta-models
– Xtext grammars (a variant of extended Backus–Naur form, EBNF)
– MOF, the OMG meta-object facility
– Essential MOF, EMOF, a more compact form of MOF underlying most of the meta-modelling
languages actually used
– Ecore, the Eclipse Modelling Framework’s variant of EMOF – what we will mostly be using in this
31/01/2020 (c) King’s College London 11
Models, languages and metalanguages
<
<
<
<
<
<
Juice:string Meal:string
<
CustomerID:int
<
CustomerID:int
DSML (Metamodel)
Meta- Language
is written in
<
<
Juice:string Meal:string
is written in
31/01/2020
(c) King’s College London
<
RoomNumber:int
<
CustomerID:int
The Meta-Object Facility (MOF)
OMG standard for defining modelling languages
– OMG = Object Management Group
– A model of meta-models (a meta-metamodel)
– UML, the OCL, relational database models, specializations of UML can all be represented in the
– Eclipse Modelling Framework (EMF) uses a variant of MOF, called Ecore
An object-oriented approach to defining modelling languages
– Modelling concepts defined as “meta-classes”
– Meta-classes themselves are instances of MOF classes
4 layered architecture to define the modelling / meta-modelling process
– Layers M0 to M3
31/01/2020 (c) King’s College London 13
Layers M0 and M1
We already know these
Layer M0 is the actual running system
• Instances of executing system elements
• E.g., turtles
• E.g., customer objects, representing actual customers accessing an ecommerce system Layer M1 is a system model
• Defines the types of entities and relationships that make up a system
• E.g., turtle specifications
• E.g., a UML class model, defining a Customer class that specifies that customer objects are
system entities
Every element of M0 is an instance of an element from M1
31/01/2020 (c) King’s College London 14
Layers M0 and M1
M0: System
title = “Mr” name = “Hyde”
title = “Dr” name = “Jekyll”
31/01/2020 (c) King’s College London 15
Layers M0 and M1
title : String name : String
M1: Model of a System M0: System
title = “Mr” name = “Hyde”
title = “Dr” name = “Jekyll”
31/01/2020 (c) King’s College London 15
Layers M0 and M1
title : String name : String
M1: Model of a System M0: System
<
<
title = “Mr” name = “Hyde”
31/01/2020 (c) King’s College London
title = “Dr” name = “Jekyll”
Layers M0 and M1
title = “Mr” name = “Hyde”
title = “Dr” name = “Jekyll”
‘:’ and underscore to indicate objects →This is an object diagram
31/01/2020 (c) King’s College London 15
Layers M0 and M1
No ‘:’ nor underscore to indicate class →This is a class diagram
title : String name : String
31/01/2020 (c) King’s College London 15
For a modelling tool, all elements of a model are objects
They are on ‘M0’
Their classes are things like ‘Class’, ‘Attribute’, ‘Association’, or ‘MoveCommand’
A meta-model (M2 model) reflects this:
Meta-classes on M2 are instantiated by model elements on M1
31/01/2020 (c) King’s College London 16
title : String name : String
M1: Model of a System M0: System
<
<
title = “Mr” name = “Hyde”
31/01/2020 (c) King’s College London
title = “Dr” name = “Jekyll”
M1: Model of a System
title : String name : String
31/01/2020 (c) King’s College London 17
M1: Model of a System
:UML Attribute
name = “title” type = “String”
:UML Class
name = “Customer”
:UML Attribute
name = “name” type = “String”
31/01/2020 (c) King’s College London 18
M2: Meta-model of UML M1: Model of a System
name : String
UML Attribute
*name : String type : String
:UML Attribute
name = “title” type = “String”
:UML Class
name = “Customer”
31/01/2020 (c) King’s College London
Side note: The actual UML meta-model is more complex 18 and uses different names for the meta-classes.
:UML Attribute
name = “name” type = “String”
<
<
UML Attribute
*name : String type : String
name : String
M2: Meta-model of UML M1: Model of a System
:UML Class
name = “Customer”
:UML Attribute
name = “title” type = “String”
31/01/2020
(c) King’s College London
Side note: The actual UML meta-model is more complex 18 and uses different names for the meta-classes.
:UML Attribute
name = “name” type = “String”
Instantiation of associations by links. This happens between M1 and M0, too.
<
<
UML Attribute
*name : String type : String
M2: Meta-model of UML M1: Model of a System
31/01/2020
(c) King’s College London
Side note: The actual UML meta-model is more complex 18 and uses different names for the meta-classes.
name : String
:UML Attribute
name = “title” type = “String”
:UML Class
name = “Customer”
:UML Attribute
name = “name” type = “String”
M1: Model of a System
31/01/2020 (c) note: The actual UML meta-model is more complex 18 and uses different names for the meta-classes.
:UML Attribute
name = “title” type = “String”
:UML Class
name = “Customer”
:UML Attribute
name = “name” type = “String”
‘:’ and underscore to indicate objects g’s→Coll an object diagram
We use the same trick again
We get a language for defining meta-models A meta-meta-language
• Defines key concepts of meta-models
• Meta-classes and associations of M2 are instances of meta-meta-classes of M3 The MOF / Ecore are really languages for M3 models
31/01/2020 (c) King’s College London 19
<
<
UML Attribute
*name : String type : String
name : String
M2: Meta-model of UML M1: Model of a System
:UML Attribute
name = “title” type = “String”
:UML Class
name = “Customer”
31/01/2020
(c) King’s College London
:UML Attribute
name = “name” type = “String”
M2: Meta-model of UML
UML Attribute
*name : String type : String
31/01/2020 (c) King’s College London
name : String
M2: Meta-model of UML
:EClass src name = “UML Class”
name = “UML Attribute” tgt
:EReference
31/01/2020
(c) King’s College London
name : String
EReference
M3: Ecore Meta-meta-model M2: Meta-model of UML
:EClass src name = “UML Class”
name = “UML Attribute” tgt
:EReference
31/01/2020
(c) King’s College London
name : String
EReference
<
<
M3: Ecore Meta-meta-model M2: Meta-model of UML
:EClass src name = “UML Class”
name = “UML Attribute” tgt
:EReference
31/01/2020
(c) King’s College London
Putting It All Together
31/01/2020 (c) King’s College London
M3: Ecore Meta-meta-model
name : String
EReference
Putting It All Together
name : String
EReference
M3: Ecore Meta-meta-model
M2: Meta-model of UML
name = “UML Class”
:EReference
name = “UML Attribute”
31/01/2020 (c) King’s College London
Putting It All Together
name : String
EReference
M3: Ecore Meta-meta-model
M2: Meta-model of UML
name = “UML Class”
:EReference
name = “UML Attribute”
M2: Meta-model of UML
M1: Model of a System
:UML Class
:UML Attribute
name = “title” type = “String”
name = “Customer”
:UML Attribute
name = “name” type = “String”
31/01/2020
(c) King’s College London
Putting It All Together
M3: Ecore Meta-meta-model
M2: Meta-model of UML
name = “UML Class”
:EReference
name = “UML Attribute”
M2: Meta-model of UML
M1: Model of a System
M1: Model of a System
name : String
EReference
:UML Class
:UML Attribute
name = “title” type = “String”
name = “Customer”
:UML Attribute
name = “name” type = “String”
M0: System
title = “Dr” name = “Jekyll”
title = “Mr” name = “Hyde”
31/01/2020
(c) King’s College London
Putting It All Together (2)
M3: Ecore Meta-meta-model
M1: Model of a System
M2: Meta-model of UML
M0: System
31/01/2020 (c) King’s College London
Different kinds of syntax
Abstract syntax Concrete syntax
31/01/2020 (c) King’s College London
Different kinds of syntax Abstract syntax
– What can be talked about in the language
Concrete syntax
– How things are said in the language – What words / pictures
– In what spatial arrangement
31/01/2020 (c) King’s College London
Different kinds of syntax Abstract syntax
– What can be talked about in the language – Captured in the metamodel
Concrete syntax
– How things are said in the language – What words / pictures
– In what spatial arrangement
– Captured in grammar
31/01/2020 (c) King’s College London
Different kinds of syntax Abstract syntax
– What can be talked about in the language – Captured in the metamodel
– One per language
Concrete syntax
– How things are said in the language – What words / pictures
– In what spatial arrangement
– Captured in grammar
– Language can have multiple concrete syntaxes
31/01/2020 (c) King’s College London
Different kinds of syntax Abstract syntax
– What can be talked about in the language
– Captured in the metamodel
– One per language
– Basis for manipulating models
programmatically (see later)
Concrete syntax
– How things are said in the language – What words / pictures
– In what spatial arrangement
– Captured in grammar
– Language can have multiple concrete syntaxes – Basis for editors, file storage, user interaction
31/01/2020 (c) King’s College London
Controlling the shape of the abstract syntax
Controlling the type of attributes and references
Assignment operators in Xtext grammar control what kind of attribute / reference is generated:
Operator Explanation
+= Create variable / reference of type list of right-hand side definition
Can hold multiple instances
statements += Statement+ creates a list of statements in a reference called statement
= Create variable / reference of type of name = ID creates a String-typed attribute name right-hand side definition
Can hold at most one instance
?= Create Boolean attribute public ?= ‘public’ creates a flag that’s true if the Will be true if expression on right hand developer writes the word public
side was matched, false otherwise
31/01/2020 (c) King’s College London
Using return statements to control the metamodel
Grammar rules can return a type
– Determines the type of thing generated into the metamodel
– Useful to restructure the metamodel to something more useful
– Pre-process values
– Remove intermediary unnecessary nodes
31/01/2020 (c) King’s College London 27
Preprocessing values
Imagine a rule for defining the syntax of real values:
31/01/2020 (c) King’s College London 28
Preprocessing values
Imagine a rule for defining the syntax of real values:
Instructs Xtext not to ignore any text
→No comments half-way through a REAL value
31/01/2020 (c) King’s College London 28
Preprocessing values
Imagine a rule for defining the syntax of real values:
This will generate a string attribute in the metamodel
– Every time we access it, we need to parse the value – not efficient
Instructs Xtext not to ignore any text
→No comments half-way through a REAL value
31/01/2020 (c) King’s College London 28
Preprocessing values
Imagine a rule for defining the syntax of real values:
This will generate a string attribute in the metamodel
– Every time we access it, we need to parse the value – not efficient We can ask Xtext to generate a float attribute instead:
Instructs Xtext not to ignore any text
→No comments half-way through a REAL value
31/01/2020 (c) King’s College London 28
Preprocessing values
Imagine a rule for defining the syntax of real values:
This will generate a string attribute in the metamodel
– Every time we access it, we need to parse the value – not efficient We can ask Xtext to generate a float attribute instead:
Instructs Xtext not to ignore any text
→No comments half-way through a REAL value
Asks Xtext to use the ecore::EFloat type every time a REAL is used
Text is automatically parsed into a float value.
31/01/2020 (c) King’s College London 28
Preprocessing values
Imagine a rule for defining the syntax of real values:
Instructs Xtext not to ignore any text
→No comments half-way through a REAL value
This will generate a string attribute in the metamodel
– Every time we access it, we need to parse the value – not efficient We can ask Xtext to generate a float attribute instead:
For this to work, we must import the ecore metamodel, so we can use its definition of EFloat:
31/01/2020 (c) King’s College London 28
Asks Xtext to use the ecore::EFloat type every time a REAL is used
Text is automatically parsed into a float value.
Preprocessing values
Imagine a rule for defining the syntax of real values:
Instructs Xtext not to ignore any text
→No comments half-way through a REAL value
This will generate a string attribute in the metamodel
– Every time we access it, we need to parse the value – not efficient We can ask Xtext to generate a float attribute instead:
For this to work, we must import the ecore metamodel, so we can use its definition of EFloat:
31/01/2020 (c) King’s College London 28
Asks Xtext to use the ecore::EFloat type every time a REAL is used
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com