The document discusses challenges in mapping from concrete syntax (CS) to abstract syntax (AS) for OCL expressions and proposes solutions using an OCL-based domain-specific language for CS to AS mappings. It addresses issues like CS to AS mappings, name resolution across the CS and AS models using environments, and disambiguation of syntactically ambiguous CS elements. The solutions involve defining the mappings and resolution/disambiguation rules using OCL. This provides a formal and automatically verifiable approach compared to informal specifications. Ongoing work includes generating executable model-to-model transformations from the OCL-based CS to AS specifications.
4. Motivation: CS to AS
CollectionLiteralPartCS:
OclExpressionCS | CollectionRangeCS
CollectionRangeCS:
OclExpressionCS ’..’ OclExpressionCS
CS2AS
4
5. Motivation: CS to AS
5
OMG
AS
Meta-model
CS
Grammar
CS
Metamodel
CS2AS
Bridge
6. Motivation: CS to AS in OCL
● Attribute grammars
○ Synthesized attributes
○ Inherited attributes
● OCL Expressions
6
7. Motivation: CS to AS in OCL
CollectionRangeCS.ast
Another way of AS
mapping description?
.oclAsType(CollectionItem).item
7
8. Problem: CS to AS in OCL
● It’s not really formal
● Typos and inconsistencies
● It is not checked/validated
○ No tool can understand the semi-formal descriptions
● Implementors can’t benefit from automation
We need models to formalize
CS2AS 8
9. Solution: OCL-based DSL
● OCL-based internal DSL
○ Complete OCL documents
● CS2AS bridge:
○ CS2AS mappings
○ Name resolution
○ CS Disambiguation
● Existing OCL tools can be used
● Implementors can exploit CS2AS bridges
9
13. Name Resolution: Roles
Environment
(named elements)
Producer
Consumer
Named Elements
Name Named Elements
nestedEnvironment
● Nested Environments (lookup scopes)
● Namespaces & qualified names
● Name visibility rules
13
14. Name Resolution:Environment
Er
= env::Environment{} -- Empty Environment
NE C
NP P
R
Ep
= ErEnp
= Er
Ene
= Ep Ec
= Ep
including NE
R Root node
NP Non-producer node
P Producer node
NE Named-element node
C Consumer node 14
16. Solution: Producers
context LetExp
def : childEnv(child : OclAny) : env::Environment =
if child = variable
then -- the owned let variable
env
else -- the owned in expression
env.nestedEnv().addElement(variable)
endif
16
17. Solution: Consumers
context OclAny
def : lookupVariable(varName : String) : Variable =
env.namedElements->selectOfKind(Variable)
->select(v | v.name = varName)->first()
context VariableExpCS
def : ast () : ocl::VariableExp =
let referredVar = ast().lookupVariable(varName)
in ocl::VariableExp {
name = varName,
referredVariable = referredVar ,
type = if referredVar = null then null else referredVar.type endif }
17
18. Challenge: CS Disambiguation
let … in x.y
● y is a PropertyCallExp
● x ?
○ VariableExp-if x is a let variable, or operation param
○ PropertyCallExp i.e. self.x.y
18
19. Challenge: CS Disambiguation
“Some of the production rules are syntactically
ambiguous. For such productions disambiguating
rules have been defined. Using these rules, each
production and thus the complete grammar
becomes non-ambiguous."
19
20. Solution: CS Disambiguation
NameExpCS:
simpleName isMarkedPre?
● Disambiguation rules:
○ should NameExpCS produce a VariableExp
○ should NameExpCS produce a PropertyCallExp
○ should NameExpCS produce …
● In a CS2AS activity
○ Syntactic information from CS meta-model
○ Semantic information from AS meta-model 20
Unified NameExpCS
21. Solution: CS Disambiguation
context NameExpCS
def : ast() : ocl::OclExpression =
if isAVariableExp()
then let variable = ast().lookupVariable(name)
in ocl::VariableExp {
name = name,
referredVariable = variable,
type = if variable = null then null else variable.type endif }
else
…
endif
21
22. Solution: CS Disambiguation
context NameExpCS
-- Disambiguation rule from NameExpCS to VariableExp
def : isAVariableExp() : Boolean =
let variable = ast().lookupVariable(name)
in variable <> null
-- Disambiguation rule from NameExpCS to PropertyCallExp
def : isAPropertyCallExp() : Boolean =
let property = ast().lookupProperty(name)
in property <> null
22
23. Ongoing & Future work
● Executable CS2AS transformation generation
23
CS AS
OCL-based
CS2AS
AS
Model
OCL OCL
CS’ AS’
CS
Model
M2M tx’
OCL-based
CS2AS’
M2M tx
CS
Model’
AS
Model’
QVT QVT
24. High Quality
IDE
Ongoing & Future work
● Xtext integration
Xtext
Grammar
CS
OCL-based
CS2AS AS
AS-based
Outline
Name Reso-
based
Content
Assistant 24
25. Ongoing & Future work
● External CS2AS DSL
25
Now OCL-based
Internal DSL
Future
OCL-embedded
External DSL
26. Thank you very much !!!
26
asbh500@york.ac.uk / adolfosbh@gmail.com
@adolfosbh
27. Yet another M2M tx language
27
● Yes, it’s another M2M tx language, but …
● It’s a Domain Specific Transformation
Language
○ e.g (Name resolution)...
● One input model, one output model
○ We don’t need support to more
● Suitable for OMG specifications
○ OCL is more widespread than QVT
28. Just for textual CS
28
● Not researched, but …
● As long the CS is represented by an Ecore
metamodel, it sounds feasible:
○ Eg: A square is mapped to a concept ‘X’ in the AS
○ Disambiguation rules to disambiguate a CS element (e.g.
a blue-coloured square is ‘X’ and a red one is ‘Y’)
29. ● We can’t have a well-designed AS with a
concise grammar (unless the language is
simple)
● If the language is not simple:
○ Either we don’t care about a well designed AS
○ or, we don’t care about how big is the grammar*
Why do we need a CS mm ?
29
Language
Capabilities
CS Grammar
Conciseness
Good AS
design