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.

1. An OCL-based bridge
from concrete to abstract
syntax
Adolfo Sánchez-Barbudo Herrera, Edward D. Willink
and Richard F. Paige

2. Agenda
● Motivation & Problem
● Challenges & Proposed Solutions
○ CS2AS Mappings
○ Name Resolution
○ CS Disambiguation
● On going and future work
2

3. Motivation: Example
● Sequence {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}
● Sequence {1, 1+1, 3..9+1}
3

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

10. Solution: CS2AS mappings
context CollectionLiteralPartCS
def : ast() : ocl::CollectionLiteralPart =
ocl::CollectionItem {
item = first.ast(),
type = first.ast().type }
10

11. Solution: CS2AS mappings
context CollectionRangeCS
def : ast() : ocl::CollectionRange =
ocl::CollectionRange {
first = first.ast(),
last = last.ast(),
type = first.ast().type.commonType(last.ast().type) }
11

12. Challenge: Name Resolution
let var : String = 'something' in var
Name resolution
based cross-reference
12

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

15. Solution: Environment def
context OclAny
def : env : env::Environment =
if oclContainer() <> null
then oclContainer().childEnv(self)
else env::Environment{} -- empty environment
endif
def : childEnv(child : OclAny) : env::Environment =
env
NP NP
NP NP
R
15

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