[ocl] CS2ASBridge - first draft
diff --git a/ocl/docs/publications/OCL2015CS2AS/.gitignore b/ocl/docs/publications/OCL2015CS2AS/.gitignore
new file mode 100644
index 0000000..698e515
--- /dev/null
+++ b/ocl/docs/publications/OCL2015CS2AS/.gitignore
@@ -0,0 +1,6 @@
+/ow2015.aux
+/ow2015.bbl
+/ow2015.blg
+/ow2015.log
+/ow2015.pdf
+/ow2015.synctex.gz
diff --git a/ocl/docs/publications/OCL2015CS2AS/images/CollectionLiteralPartCS.PNG b/ocl/docs/publications/OCL2015CS2AS/images/CollectionLiteralPartCS.PNG
index ceb5a6b..23ee7ec 100644
--- a/ocl/docs/publications/OCL2015CS2AS/images/CollectionLiteralPartCS.PNG
+++ b/ocl/docs/publications/OCL2015CS2AS/images/CollectionLiteralPartCS.PNG
Binary files differ
diff --git a/ocl/docs/publications/OCL2015CS2AS/images/NameExpCS.png b/ocl/docs/publications/OCL2015CS2AS/images/NameExpCS.png
new file mode 100644
index 0000000..5719a51
--- /dev/null
+++ b/ocl/docs/publications/OCL2015CS2AS/images/NameExpCS.png
Binary files differ
diff --git a/ocl/docs/publications/OCL2015CS2AS/models/AS.ecore b/ocl/docs/publications/OCL2015CS2AS/models/AS.ecore
index 412da84..49f5332 100644
--- a/ocl/docs/publications/OCL2015CS2AS/models/AS.ecore
+++ b/ocl/docs/publications/OCL2015CS2AS/models/AS.ecore
@@ -10,7 +10,6 @@
<eClassifiers xsi:type="ecore:EClass" name="Variable" eSuperTypes="#//TypedElement">
<eStructuralFeatures xsi:type="ecore:EReference" name="initExpression" eType="#//OclExpression"
containment="true"/>
- <eStructuralFeatures xsi:type="ecore:EReference" name="type" eType="#//Type" containment="true"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="OclExpression" abstract="true" eSuperTypes="#//TypedElement"/>
<eClassifiers xsi:type="ecore:EClass" name="VariableExp" eSuperTypes="#//OclExpression">
@@ -38,4 +37,11 @@
<eClassifiers xsi:type="ecore:EClass" name="TypedElement" abstract="true" eSuperTypes="#//NamedElement">
<eStructuralFeatures xsi:type="ecore:EReference" name="type" lowerBound="1" eType="#//Type"/>
</eClassifiers>
+ <eClassifiers xsi:type="ecore:EClass" name="PropertyCallExp" eSuperTypes="#//OclExpression">
+ <eStructuralFeatures xsi:type="ecore:EReference" name="referredProperty" lowerBound="1"
+ eType="#//Property"/>
+ </eClassifiers>
+ <eClassifiers xsi:type="ecore:EClass" name="Property">
+ <eStructuralFeatures xsi:type="ecore:EAttribute" name="name" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
+ </eClassifiers>
</ecore:EPackage>
diff --git a/ocl/docs/publications/OCL2015CS2AS/models/AS.ecorediag b/ocl/docs/publications/OCL2015CS2AS/models/AS.ecorediag
index fd0f9cd..a86beb5 100644
--- a/ocl/docs/publications/OCL2015CS2AS/models/AS.ecorediag
+++ b/ocl/docs/publications/OCL2015CS2AS/models/AS.ecorediag
@@ -166,6 +166,42 @@
<element xmi:type="ecore:EClass" href="AS.ecore#//TypedElement"/>
<layoutConstraint xmi:type="notation:Bounds" xmi:id="_9fUTYh8dEeWeD_ZDiiOk4g" x="175" y="25" height="33"/>
</children>
+ <children xmi:type="notation:Node" xmi:id="_9tNj8CybEeWJD4Hud2HL8A" type="1001">
+ <children xmi:type="notation:Node" xmi:id="_9tOLACybEeWJD4Hud2HL8A" type="4001"/>
+ <children xmi:type="notation:Node" xmi:id="_9tOLASybEeWJD4Hud2HL8A" type="5001">
+ <styles xmi:type="notation:DrawerStyle" xmi:id="_9tOLAiybEeWJD4Hud2HL8A"/>
+ <styles xmi:type="notation:SortingStyle" xmi:id="_9tOLAyybEeWJD4Hud2HL8A"/>
+ <styles xmi:type="notation:FilteringStyle" xmi:id="_9tOLBCybEeWJD4Hud2HL8A"/>
+ </children>
+ <children xmi:type="notation:Node" xmi:id="_9tOLBSybEeWJD4Hud2HL8A" type="5002">
+ <styles xmi:type="notation:DrawerStyle" xmi:id="_9tOLBiybEeWJD4Hud2HL8A"/>
+ <styles xmi:type="notation:SortingStyle" xmi:id="_9tOLByybEeWJD4Hud2HL8A"/>
+ <styles xmi:type="notation:FilteringStyle" xmi:id="_9tOLCCybEeWJD4Hud2HL8A"/>
+ </children>
+ <styles xmi:type="notation:ShapeStyle" xmi:id="_9tNj8SybEeWJD4Hud2HL8A" fontColor="4210752" fontName="Segoe UI" fontHeight="10" fillColor="13761016" lineColor="8421504"/>
+ <element xmi:type="ecore:EClass" href="AS.ecore#//PropertyCallExp"/>
+ <layoutConstraint xmi:type="notation:Bounds" xmi:id="_9tNj8iybEeWJD4Hud2HL8A" x="365" y="280"/>
+ </children>
+ <children xmi:type="notation:Node" xmi:id="_GuTJ8CycEeWJD4Hud2HL8A" type="1001">
+ <children xmi:type="notation:Node" xmi:id="_GuTJ8yycEeWJD4Hud2HL8A" type="4001"/>
+ <children xmi:type="notation:Node" xmi:id="_GuTJ9CycEeWJD4Hud2HL8A" type="5001">
+ <children xmi:type="notation:Node" xmi:id="_I429ACycEeWJD4Hud2HL8A" type="2001">
+ <element xmi:type="ecore:EAttribute" href="AS.ecore#//Property/name"/>
+ <layoutConstraint xmi:type="notation:Location" xmi:id="_I429ASycEeWJD4Hud2HL8A"/>
+ </children>
+ <styles xmi:type="notation:DrawerStyle" xmi:id="_GuTJ9SycEeWJD4Hud2HL8A"/>
+ <styles xmi:type="notation:SortingStyle" xmi:id="_GuTJ9iycEeWJD4Hud2HL8A"/>
+ <styles xmi:type="notation:FilteringStyle" xmi:id="_GuTJ9yycEeWJD4Hud2HL8A"/>
+ </children>
+ <children xmi:type="notation:Node" xmi:id="_GuTJ-CycEeWJD4Hud2HL8A" type="5002">
+ <styles xmi:type="notation:DrawerStyle" xmi:id="_GuTJ-SycEeWJD4Hud2HL8A"/>
+ <styles xmi:type="notation:SortingStyle" xmi:id="_GuTJ-iycEeWJD4Hud2HL8A"/>
+ <styles xmi:type="notation:FilteringStyle" xmi:id="_GuTJ-yycEeWJD4Hud2HL8A"/>
+ </children>
+ <styles xmi:type="notation:ShapeStyle" xmi:id="_GuTJ8SycEeWJD4Hud2HL8A" fontColor="4210752" fontName="Segoe UI" fontHeight="10" fillColor="13761016" lineColor="8421504"/>
+ <element xmi:type="ecore:EClass" href="AS.ecore#//Property"/>
+ <layoutConstraint xmi:type="notation:Bounds" xmi:id="_GuTJ8iycEeWJD4Hud2HL8A" x="135" y="270"/>
+ </children>
<styles xmi:type="notation:DiagramStyle" xmi:id="_XMMMIB8cEeWeD_ZDiiOk4g"/>
<element xmi:type="ecore:EPackage" href="AS.ecore#/"/>
<edges xmi:type="notation:Edge" xmi:id="_XNyuoB8cEeWeD_ZDiiOk4g" type="3002" source="_XNrZ4B8cEeWeD_ZDiiOk4g" target="_XNudMB8cEeWeD_ZDiiOk4g">
@@ -336,4 +372,22 @@
<sourceAnchor xmi:type="notation:IdentityAnchor" xmi:id="_tIBXAB8sEeWeD_ZDiiOk4g" id="(0.7596153846153846,0.3488372093023256)"/>
<targetAnchor xmi:type="notation:IdentityAnchor" xmi:id="_tIBXAR8sEeWeD_ZDiiOk4g" id="(0.008547008547008548,0.5151515151515151)"/>
</edges>
+ <edges xmi:type="notation:Edge" xmi:id="_LVFH0CycEeWJD4Hud2HL8A" type="3003" source="_9tNj8CybEeWJD4Hud2HL8A" target="_XNudMB8cEeWeD_ZDiiOk4g">
+ <styles xmi:type="notation:ConnectorStyle" xmi:id="_LVFH0SycEeWJD4Hud2HL8A" routing="Rectilinear" lineColor="4210752"/>
+ <styles xmi:type="notation:FontStyle" xmi:id="_LVFH0iycEeWJD4Hud2HL8A" fontName="Segoe UI"/>
+ <element xsi:nil="true"/>
+ <bendpoints xmi:type="notation:RelativeBendpoints" xmi:id="_LVFH0yycEeWJD4Hud2HL8A" points="[-5, -20, 140, 155]$[-5, -105, 140, 70]$[-80, -105, 65, 70]$[-80, -159, 65, 16]"/>
+ </edges>
+ <edges xmi:type="notation:Edge" xmi:id="_OcC4wCycEeWJD4Hud2HL8A" type="3002" source="_9tNj8CybEeWJD4Hud2HL8A" target="_GuTJ8CycEeWJD4Hud2HL8A">
+ <children xmi:type="notation:Node" xmi:id="_OcDf0CycEeWJD4Hud2HL8A" type="4011">
+ <layoutConstraint xmi:type="notation:Location" xmi:id="_OcDf0SycEeWJD4Hud2HL8A" x="-35" y="-14"/>
+ </children>
+ <children xmi:type="notation:Node" xmi:id="_OcDf0iycEeWJD4Hud2HL8A" type="4012">
+ <layoutConstraint xmi:type="notation:Location" xmi:id="_OcDf0yycEeWJD4Hud2HL8A" x="2" y="11"/>
+ </children>
+ <styles xmi:type="notation:ConnectorStyle" xmi:id="_OcC4wSycEeWJD4Hud2HL8A" lineColor="4210752"/>
+ <styles xmi:type="notation:FontStyle" xmi:id="_OcC4wiycEeWJD4Hud2HL8A" fontColor="4210752" fontName="Segoe UI" fontHeight="10"/>
+ <element xmi:type="ecore:EReference" href="AS.ecore#//PropertyCallExp/referredProperty"/>
+ <bendpoints xmi:type="notation:RelativeBendpoints" xmi:id="_OcC4wyycEeWJD4Hud2HL8A" points="[-5, 21, -1, -73]$[-5, 70, -1, -24]"/>
+ </edges>
</notation:Diagram>
diff --git a/ocl/docs/publications/OCL2015CS2AS/models/CS.ecore b/ocl/docs/publications/OCL2015CS2AS/models/CS.ecore
index 30da7b1..bfec107 100644
--- a/ocl/docs/publications/OCL2015CS2AS/models/CS.ecore
+++ b/ocl/docs/publications/OCL2015CS2AS/models/CS.ecore
@@ -18,15 +18,22 @@
<eClassifiers xsi:type="ecore:EClass" name="VariableExpCS">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="varName" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
- <eClassifiers xsi:type="ecore:EClass" name="CollectionLiteralPartCS">
- <eStructuralFeatures xsi:type="ecore:EReference" name="first" lowerBound="1" eType="#//ExpCS.1"
- containment="true"/>
- <eStructuralFeatures xsi:type="ecore:EReference" name="last" eType="#//ExpCS.1"
+ <eClassifiers xsi:type="ecore:EClass" name="CollectionRangeCS" eSuperTypes="#//CollectionLiteralPartCS">
+ <eStructuralFeatures xsi:type="ecore:EReference" name="last" lowerBound="1" eType="#//ExpCS.1"
containment="true"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="CollectionRangeCS"/>
- <eClassifiers xsi:type="ecore:EClass" name="ExpCS" abstract="true"/>
+ <eClassifiers xsi:type="ecore:EClass" name="ExpCS" abstract="true" eSuperTypes="#//CollectionLiteralPartCS"/>
<eClassifiers xsi:type="ecore:EClass" name="TypeCS" eSuperTypes="#//ExpCS">
<eStructuralFeatures xsi:type="ecore:EReference" name="EReference0" eType="#//ExpCS"/>
</eClassifiers>
+ <eClassifiers xsi:type="ecore:EClass" name="CollectionLiteralPartCS">
+ <eStructuralFeatures xsi:type="ecore:EReference" name="first" lowerBound="1" eType="#//ExpCS.1"
+ containment="true"/>
+ </eClassifiers>
+ <eClassifiers xsi:type="ecore:EClass" name="EClass0"/>
+ <eClassifiers xsi:type="ecore:EClass" name="NameExpCS">
+ <eStructuralFeatures xsi:type="ecore:EAttribute" name="name" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
+ <eStructuralFeatures xsi:type="ecore:EAttribute" name="isMarkedAsPre" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EBoolean"/>
+ </eClassifiers>
</ecore:EPackage>
diff --git a/ocl/docs/publications/OCL2015CS2AS/models/CS.ecorediag b/ocl/docs/publications/OCL2015CS2AS/models/CS.ecorediag
index 794e21a..efa53e7 100644
--- a/ocl/docs/publications/OCL2015CS2AS/models/CS.ecorediag
+++ b/ocl/docs/publications/OCL2015CS2AS/models/CS.ecorediag
@@ -87,8 +87,8 @@
<styles xmi:type="notation:FilteringStyle" xmi:id="_LQxYtx58EeW2C-ZNs9FY0A"/>
</children>
<styles xmi:type="notation:ShapeStyle" xmi:id="_LQwxoR58EeW2C-ZNs9FY0A" fontColor="4210752" fontName="Segoe UI" fontHeight="10" fillColor="13761016" lineColor="8421504"/>
- <element xmi:type="ecore:EClass" href="CS.ecore#//CollectionLiteralPartCS"/>
- <layoutConstraint xmi:type="notation:Bounds" xmi:id="_LQwxoh58EeW2C-ZNs9FY0A" x="85" y="275" width="166" height="33"/>
+ <element xmi:type="ecore:EClass" href="CS.ecore#//CollectionRangeCS"/>
+ <layoutConstraint xmi:type="notation:Bounds" xmi:id="_LQwxoh58EeW2C-ZNs9FY0A" x="75" y="320" width="166" height="33"/>
</children>
<children xmi:type="notation:Node" xmi:id="_1C_5gB58EeW2C-ZNs9FY0A" type="1001">
<children xmi:type="notation:Node" xmi:id="_1C_5gx58EeW2C-ZNs9FY0A" type="4001"/>
@@ -104,7 +104,7 @@
</children>
<styles xmi:type="notation:ShapeStyle" xmi:id="_1C_5gR58EeW2C-ZNs9FY0A" fontColor="4210752" fontName="Segoe UI" fontHeight="10" fillColor="13761016" lineColor="8421504"/>
<element xmi:type="ecore:EClass" href="CS.ecore#//ExpCS.1"/>
- <layoutConstraint xmi:type="notation:Bounds" xmi:id="_1C_5gh58EeW2C-ZNs9FY0A" x="305" y="275" height="33"/>
+ <layoutConstraint xmi:type="notation:Bounds" xmi:id="_1C_5gh58EeW2C-ZNs9FY0A" x="295" y="320" height="33"/>
</children>
<children xmi:type="notation:Node" xmi:id="_iQRk4B59EeW2C-ZNs9FY0A" type="1001">
<children xmi:type="notation:Node" xmi:id="_iQRk4x59EeW2C-ZNs9FY0A" type="4001"/>
@@ -122,6 +122,46 @@
<element xmi:type="ecore:EClass" href="CS.ecore#//TypeCS"/>
<layoutConstraint xmi:type="notation:Bounds" xmi:id="_iQRk4h59EeW2C-ZNs9FY0A" x="300" y="125" height="33"/>
</children>
+ <children xmi:type="notation:Node" xmi:id="_WrTsICyPEeWJD4Hud2HL8A" type="1001">
+ <children xmi:type="notation:Node" xmi:id="_WrX9kCyPEeWJD4Hud2HL8A" type="4001"/>
+ <children xmi:type="notation:Node" xmi:id="_WrYkoCyPEeWJD4Hud2HL8A" type="5001">
+ <styles xmi:type="notation:DrawerStyle" xmi:id="_WrYkoSyPEeWJD4Hud2HL8A"/>
+ <styles xmi:type="notation:SortingStyle" xmi:id="_WrYkoiyPEeWJD4Hud2HL8A"/>
+ <styles xmi:type="notation:FilteringStyle" xmi:id="_WrYkoyyPEeWJD4Hud2HL8A"/>
+ </children>
+ <children xmi:type="notation:Node" xmi:id="_WrnOICyPEeWJD4Hud2HL8A" type="5002">
+ <styles xmi:type="notation:DrawerStyle" xmi:id="_Wrn1MCyPEeWJD4Hud2HL8A"/>
+ <styles xmi:type="notation:SortingStyle" xmi:id="_Wrn1MSyPEeWJD4Hud2HL8A"/>
+ <styles xmi:type="notation:FilteringStyle" xmi:id="_Wrn1MiyPEeWJD4Hud2HL8A"/>
+ </children>
+ <styles xmi:type="notation:ShapeStyle" xmi:id="_WrTsISyPEeWJD4Hud2HL8A" fontColor="4210752" fontName="Segoe UI" fontHeight="10" fillColor="13761016" lineColor="8421504"/>
+ <element xmi:type="ecore:EClass" href="CS.ecore#//CollectionLiteralPartCS"/>
+ <layoutConstraint xmi:type="notation:Bounds" xmi:id="_WrTsIiyPEeWJD4Hud2HL8A" x="70" y="255" width="203" height="27"/>
+ </children>
+ <children xmi:type="notation:Node" xmi:id="_PakBYCyaEeWJD4Hud2HL8A" type="1001">
+ <children xmi:type="notation:Node" xmi:id="_PakocCyaEeWJD4Hud2HL8A" type="4001"/>
+ <children xmi:type="notation:Node" xmi:id="_PakocSyaEeWJD4Hud2HL8A" type="5001">
+ <children xmi:type="notation:Node" xmi:id="_jj4DkCybEeWJD4Hud2HL8A" type="2001">
+ <element xmi:type="ecore:EAttribute" href="CS.ecore#//NameExpCS/name"/>
+ <layoutConstraint xmi:type="notation:Location" xmi:id="_jj4DkSybEeWJD4Hud2HL8A"/>
+ </children>
+ <children xmi:type="notation:Node" xmi:id="_3cbAsCyuEeWJD4Hud2HL8A" type="2001">
+ <element xmi:type="ecore:EAttribute" href="CS.ecore#//NameExpCS/isMarkedAsPre"/>
+ <layoutConstraint xmi:type="notation:Location" xmi:id="_3cbAsSyuEeWJD4Hud2HL8A"/>
+ </children>
+ <styles xmi:type="notation:DrawerStyle" xmi:id="_PakociyaEeWJD4Hud2HL8A"/>
+ <styles xmi:type="notation:SortingStyle" xmi:id="_PakocyyaEeWJD4Hud2HL8A"/>
+ <styles xmi:type="notation:FilteringStyle" xmi:id="_PakodCyaEeWJD4Hud2HL8A"/>
+ </children>
+ <children xmi:type="notation:Node" xmi:id="_PalPgCyaEeWJD4Hud2HL8A" type="5002">
+ <styles xmi:type="notation:DrawerStyle" xmi:id="_PalPgSyaEeWJD4Hud2HL8A"/>
+ <styles xmi:type="notation:SortingStyle" xmi:id="_PalPgiyaEeWJD4Hud2HL8A"/>
+ <styles xmi:type="notation:FilteringStyle" xmi:id="_PalPgyyaEeWJD4Hud2HL8A"/>
+ </children>
+ <styles xmi:type="notation:ShapeStyle" xmi:id="_PakBYSyaEeWJD4Hud2HL8A" fontColor="4210752" fontName="Segoe UI" fontHeight="10" fillColor="13761016" lineColor="8421504"/>
+ <element xmi:type="ecore:EClass" href="CS.ecore#//NameExpCS"/>
+ <layoutConstraint xmi:type="notation:Bounds" xmi:id="_PakBYiyaEeWJD4Hud2HL8A" x="445" y="180" width="203" height="68"/>
+ </children>
<styles xmi:type="notation:DiagramStyle" xmi:id="_ThupoR55EeW2C-ZNs9FY0A"/>
<element xmi:type="ecore:EPackage" href="CS.ecore#/"/>
<edges xmi:type="notation:Edge" xmi:id="_szGVUB57EeW2C-ZNs9FY0A" type="3003" source="_UcLfsB55EeW2C-ZNs9FY0A" target="_o2jAMB57EeW2C-ZNs9FY0A">
@@ -157,30 +197,30 @@
<bendpoints xmi:type="notation:RelativeBendpoints" xmi:id="_7fi7ox57EeW2C-ZNs9FY0A" points="[50, 0, -61, 24]$[111, 0, 0, 24]$[111, -21, 0, 3]"/>
<targetAnchor xmi:type="notation:IdentityAnchor" xmi:id="_VZUkgB8VEeWeD_ZDiiOk4g" id="(0.21333333333333335,0.9411764705882353)"/>
</edges>
- <edges xmi:type="notation:Edge" xmi:id="_5amL4B58EeW2C-ZNs9FY0A" type="3002" source="_LQwxoB58EeW2C-ZNs9FY0A" target="_1C_5gB58EeW2C-ZNs9FY0A">
+ <edges xmi:type="notation:Edge" xmi:id="_5amL4B58EeW2C-ZNs9FY0A" type="3002" source="_WrTsICyPEeWJD4Hud2HL8A" target="_1C_5gB58EeW2C-ZNs9FY0A">
<children xmi:type="notation:Node" xmi:id="_5amL5B58EeW2C-ZNs9FY0A" type="4011">
- <layoutConstraint xmi:type="notation:Location" xmi:id="_5amL5R58EeW2C-ZNs9FY0A" x="-15" y="-8"/>
+ <layoutConstraint xmi:type="notation:Location" xmi:id="_5amL5R58EeW2C-ZNs9FY0A" x="2" y="-22"/>
</children>
<children xmi:type="notation:Node" xmi:id="_5amy8B58EeW2C-ZNs9FY0A" type="4012">
- <layoutConstraint xmi:type="notation:Location" xmi:id="_5amy8R58EeW2C-ZNs9FY0A" x="3" y="12"/>
+ <layoutConstraint xmi:type="notation:Location" xmi:id="_5amy8R58EeW2C-ZNs9FY0A" x="2" y="10"/>
</children>
<styles xmi:type="notation:ConnectorStyle" xmi:id="_5amL4R58EeW2C-ZNs9FY0A" lineColor="4210752"/>
<styles xmi:type="notation:FontStyle" xmi:id="_5amL4h58EeW2C-ZNs9FY0A" fontColor="4210752" fontName="Segoe UI" fontHeight="10"/>
<element xmi:type="ecore:EReference" href="CS.ecore#//CollectionLiteralPartCS/first"/>
- <bendpoints xmi:type="notation:RelativeBendpoints" xmi:id="_5amL4x58EeW2C-ZNs9FY0A" points="[18, 6, -79, 1]$[98, -6, 1, -11]"/>
- <sourceAnchor xmi:type="notation:IdentityAnchor" xmi:id="_5anaAB58EeW2C-ZNs9FY0A" id="(0.927710843373494,0.09302325581395349)"/>
- <targetAnchor xmi:type="notation:IdentityAnchor" xmi:id="_5anaAR58EeW2C-ZNs9FY0A" id="(0.0392156862745098,0.27906976744186046)"/>
+ <bendpoints xmi:type="notation:RelativeBendpoints" xmi:id="_5amL4x58EeW2C-ZNs9FY0A" points="[11, 8, -27, -63]$[60, 8, 22, -63]$[41, 63, 3, -8]"/>
+ <sourceAnchor xmi:type="notation:IdentityAnchor" xmi:id="_5anaAB58EeW2C-ZNs9FY0A" id="(0.9458128078817734,0.09375)"/>
+ <targetAnchor xmi:type="notation:IdentityAnchor" xmi:id="_5anaAR58EeW2C-ZNs9FY0A" id="(0.4215686274509804,0.12121212121212122)"/>
</edges>
<edges xmi:type="notation:Edge" xmi:id="_KP5VEB59EeW2C-ZNs9FY0A" type="3002" source="_LQwxoB58EeW2C-ZNs9FY0A" target="_1C_5gB58EeW2C-ZNs9FY0A">
<children xmi:type="notation:Node" xmi:id="_KP58IB59EeW2C-ZNs9FY0A" type="4011">
<layoutConstraint xmi:type="notation:Location" xmi:id="_KP58IR59EeW2C-ZNs9FY0A" y="-12"/>
</children>
<children xmi:type="notation:Node" xmi:id="_KP58Ih59EeW2C-ZNs9FY0A" type="4012">
- <layoutConstraint xmi:type="notation:Location" xmi:id="_KP58Ix59EeW2C-ZNs9FY0A" x="35" y="-12"/>
+ <layoutConstraint xmi:type="notation:Location" xmi:id="_KP58Ix59EeW2C-ZNs9FY0A" x="28" y="-13"/>
</children>
<styles xmi:type="notation:ConnectorStyle" xmi:id="_KP5VER59EeW2C-ZNs9FY0A" lineColor="4210752"/>
<styles xmi:type="notation:FontStyle" xmi:id="_KP5VEh59EeW2C-ZNs9FY0A" fontColor="4210752" fontName="Segoe UI" fontHeight="10"/>
- <element xmi:type="ecore:EReference" href="CS.ecore#//CollectionLiteralPartCS/last"/>
+ <element xmi:type="ecore:EReference" href="CS.ecore#//CollectionRangeCS/last"/>
<bendpoints xmi:type="notation:RelativeBendpoints" xmi:id="_KP5VEx59EeW2C-ZNs9FY0A" points="[0, 8, -187, 2]$[0, 27, -187, 21]$[187, 27, 0, 21]$[187, 8, 0, 2]"/>
<sourceAnchor xmi:type="notation:IdentityAnchor" xmi:id="_KP7KQB59EeW2C-ZNs9FY0A" id="(0.5120481927710844,0.813953488372093)"/>
<targetAnchor xmi:type="notation:IdentityAnchor" xmi:id="_KP7KQR59EeW2C-ZNs9FY0A" id="(0.5,0.9534883720930233)"/>
@@ -220,4 +260,11 @@
<bendpoints xmi:type="notation:RelativeBendpoints" xmi:id="_svc5gx59EeW2C-ZNs9FY0A" points="[-50, 5, 165, 76]$[-230, 5, -15, 76]$[-230, -64, -15, 7]"/>
<targetAnchor xmi:type="notation:IdentityAnchor" xmi:id="_svdgkB59EeW2C-ZNs9FY0A" id="(0.5,0.8372093023255814)"/>
</edges>
+ <edges xmi:type="notation:Edge" xmi:id="_8sGtQCyQEeWJD4Hud2HL8A" type="3003" source="_LQwxoB58EeW2C-ZNs9FY0A" target="_WrTsICyPEeWJD4Hud2HL8A">
+ <styles xmi:type="notation:ConnectorStyle" xmi:id="_8sGtQSyQEeWJD4Hud2HL8A" routing="Rectilinear" lineColor="4210752"/>
+ <styles xmi:type="notation:FontStyle" xmi:id="_8sGtQiyQEeWJD4Hud2HL8A" fontName="Segoe UI"/>
+ <element xsi:nil="true"/>
+ <bendpoints xmi:type="notation:RelativeBendpoints" xmi:id="_8sGtQyyQEeWJD4Hud2HL8A" points="[-1, -7, -15, 50]$[-1, -42, -15, 15]"/>
+ <sourceAnchor xmi:type="notation:IdentityAnchor" xmi:id="_8sH7YCyQEeWJD4Hud2HL8A" id="(0.4939759036144578,0.24242424242424243)"/>
+ </edges>
</notation:Diagram>
diff --git a/ocl/docs/publications/OCL2015CS2AS/models/CS2AS.ocl b/ocl/docs/publications/OCL2015CS2AS/models/CS2AS.ocl
new file mode 100644
index 0000000..14a46da
--- /dev/null
+++ b/ocl/docs/publications/OCL2015CS2AS/models/CS2AS.ocl
@@ -0,0 +1,99 @@
+import 'CS.ecore'
+import 'AS.ecore'
+import 'Lookup.ocl'
+import 'Disambiguation.ocl'
+
+package oclCS
+
+context TypeCS
+def :ast() : oclAS::Type =
+ null
+
+context ExpCS
+def :ast() : oclAS::OclExpression =
+ null
+
+
+context CollectionLiteralPartCS
+def : ast() : oclAS::CollectionLiteralPart =
+ oclAS::CollectionItem {
+ item = first.ast(),
+ type = first.ast().type
+ }
+
+context CollectionRangeCS
+def : ast() : oclAS::CollectionRange =
+ oclAS::CollectionRange {
+ first = first.ast(),
+ last = last.ast(),
+ type = first.ast().type.commonType(last.ast().type)
+ }
+
+context LetExpCS
+def : ast() : oclAS::LetExp =
+ oclAS::LetExp {
+ variable = variable.ast(),
+ _'in' = inExpression.ast(),
+ type = inExpression.ast().type
+}
+
+context VariableDeclarationCS
+def : ast() : oclAS::Variable =
+ oclAS::Variable {
+ name = varName,
+ initExpression = initExp.ast(),
+ type = if varType = null
+ then if initExp = null
+ then null
+ else initExp.ast().type
+ endif
+ else varType.ast().type
+ endif
+}
+
+--context VariableExpCS
+--def : ast() : ocl::VariableExp =
+-- let variable = ast().lookupVariable(varName)
+-- in ocl::VariableExp {
+-- name = varName
+-- referredVariable = variable
+-- type = if variable = null
+-- then null
+-- else variable.type
+-- endif
+-- }
+
+context NameExpCS
+def : ast() : oclAS::OclExpression =
+ if isAVariableExp()
+ then
+ let variable = ast().lookupVariable(self)
+ in oclAS::VariableExp {
+ name = name,
+ referredVariable = variable,
+ type = if variable = null
+ then null
+ else variable.type
+ endif
+ }
+ else
+ let property = ast().lookupProperty(self)
+ in oclAS::PropertyCallExp {
+ name = name,
+ referredProperty = property,
+ type = if property = null
+ then null
+ else property.type
+ endif
+ }
+ endif
+
+endpackage
+
+package oclAS
+
+context Type
+def : commonType(otherType : Type) : Type =
+ null
+
+endpackage
\ No newline at end of file
diff --git a/ocl/docs/publications/OCL2015CS2AS/models/Disambiguation.ocl b/ocl/docs/publications/OCL2015CS2AS/models/Disambiguation.ocl
new file mode 100644
index 0000000..2f50eb4
--- /dev/null
+++ b/ocl/docs/publications/OCL2015CS2AS/models/Disambiguation.ocl
@@ -0,0 +1,12 @@
+import 'CS.ecore'
+import 'AS.ecore'
+import 'Lookup.ocl'
+
+package oclCS
+
+context NameExpCS
+def : isAVariableExp() : Boolean =
+ let variable = ast().lookupVariable(self)
+ in variable <> null
+
+endpackage
diff --git a/ocl/docs/publications/OCL2015CS2AS/models/Lookup.ocl b/ocl/docs/publications/OCL2015CS2AS/models/Lookup.ocl
new file mode 100644
index 0000000..f739e95
--- /dev/null
+++ b/ocl/docs/publications/OCL2015CS2AS/models/Lookup.ocl
@@ -0,0 +1,6 @@
+import 'CS.ecore'
+import 'AS.ecore'
+
+package oclAS
+
+endpackage
\ No newline at end of file
diff --git a/ocl/docs/publications/OCL2015CS2AS/ow2015.tex b/ocl/docs/publications/OCL2015CS2AS/ow2015.tex
index 34da839..c1ed4b4 100644
--- a/ocl/docs/publications/OCL2015CS2AS/ow2015.tex
+++ b/ocl/docs/publications/OCL2015CS2AS/ow2015.tex
@@ -44,8 +44,8 @@
The specifications for textual languages such as OCL and QVT define a textual language and an information model using
\begin{itemize}
-\item an EBNF grammar to define the textual language
-\item a UML metamodel to define the abstract syntax (AS) of the language
+\item an EBNF compliant grammar to define the textual language
+\item a UML compliant metamodel to define the abstract syntax (AS) of the language
\end{itemize}
The textual language is used by humans and for source interchange between compliant tools. The information model facilitates interchange between producing tools such as editors and compilers and consuming tools such as evaluators and program checkers.
@@ -55,12 +55,12 @@
\subsection{The OMG specification problem}
-The OCL \cite{omg2013ocl} and QVT \cite{omg2014qvt} specifications define four languages, OCL, QVTc(Core), QVTo (Operational Mappings), QVTr (Relations)%\footnote{QVTr language has a graphical CS as well.}
-. The specifications all provide fairly detailed EBNF grammars and metamodels of their respective abstract syntaxes.
+The OCL \cite{omg2013ocl} and QVT \cite{omg2014qvt} specifications define four languages, OCL, QVTc(Core), QVTo (Operational Mappings) and QVTr (Relations)%\footnote{QVTr language has a graphical CS as well.}
+. The specifications all provide fairly detailed grammars and metamodels of their respective concrete and abstract syntaxes.
Unfortunately the grammar to abstract syntax conversion is poorly specified.
-In OCL, a Concrete Syntax is provided and the grammar is partitioned into ambiguous productions for each CS element. Semi-formal rules define the grammar to CS correspondence, the CS to AS correspondence, name resolution and disambiguation.
+In OCL, a CS is provided and the grammar is partitioned into ambiguous productions for each CS element. Semi-formal rules define the grammar to CS correspondence, the CS to AS correspondence, name resolution and disambiguation.
QVTr has a single coherent grammar to accompany its CS and similar semi-formal rules.
@@ -74,9 +74,9 @@
\subsection{Our solution}
-The intermediate CS metamodel is close to the grammar and this gap is now bridged quite satisfactorily by modern Annotated EBNF tooling such as Xtext. It is in the CS to AS conversion that greater challenges arise.
+The intermediate CS metamodel is close to the grammar and this gap is now bridged quite satisfactorily by modern Annotated EBNF (FIXME ASBH. Does this term even exist ? reference ?) tooling such as Xtext. It is in the CS to AS conversion that greater challenges arise.
-In this paper, we take inspiration from the substantial semi-formal exposition of the OCL conversions (Clause 9.3 of \cite{omg2013ocl};) and introduce a fully modeled CS2AS bridge. The models can variously be used to check and even auto-generate a consistent specification and also to auto-generate compliant tooling. In addition to conventional CS and AS metamodels, we introduce new CS2AS mapping models, CS name resolution models and CS disambiguation models. We demonstrate in a running example how OCL itself can be used to provide a suitable 'internal' DSL for these new models.
+In this paper, we take inspiration from the substantial semi-formal exposition of the OCL conversions (Clause 9.3 of \cite{omg2013ocl};) and introduce a fully modeled CS2AS bridge. The models can variously be used to check and even auto-generate a consistent specification and also to auto-generate compliant tooling. In addition to conventional CS and AS metamodels, we introduce new CS2AS mapping models, CS name resolution models and CS disambiguation models. We demonstrate in a running example how OCL itself can be used to provide a suitable internal DSL for these new models.
%Whilst OMG specifications usually include an exhaustive\footnote{We do not mean correct and free of errors} definition of language (or languages) abstract syntax (AS), there is substantial variation in how specifications present concrete syntax (CS): whereas we can find a fairly detailed CS for OCL, the same level of detail can't be found across the languages defined in the QVT specification.
@@ -86,7 +86,7 @@
%In this paper we propose means to bridge the textual CS and the corresponding AS of a language, exposing the problem from two specific OMG specifications -- OCL and QVT -- while showing a solution for a running example. The main technical contribution of this paper is thus an OCL-based internal Domain Specific Language (DSL) \cite{fowler2010dsl} to declaratively express those CS2AS bridges which tackle cross-cutting concerns, such as name resolution and concrete syntax disambiguation.
-The paper is structured as follows. Section~\ref{sec:example} presents a small running example. Section~\ref{sec:semi-formal-solution} demonstrates the semi-formal solution adopted by the OCL specification. Section~\ref{sec:solution} explains the proposed solution, i.e. an OCL-based internal DSL. Section~\ref{sec:relatedWork} will describe some related works and Section~\ref{sec:limitations} will talk about the current shortcomings of the approach. Section~\ref{sec:futureWork} will outline some future work, including how tool implementors can benefit from the internal DSL. Finally, Section~\ref{sec:conclusions} will gather the paper conclusions.
+The paper is structured as follows. Section~\ref{sec:example} presents a small running example. Section~\ref{sec:semi-formal-solution} demonstrates the semi-formal solution adopted by the OCL specification. Section~\ref{sec:solution} explains the proposed solution, i.e. an OCL-based internal DSL. Section~\ref{sec:relatedWork} will describe related work and Section~\ref{sec:limitations} will talk about the current shortcomings of the approach. Section~\ref{sec:futureWork} will outline some future work, including how tool implementors can benefit from the internal DSL. Finally, Section~\ref{sec:conclusions} will gather the paper conclusions.
%\section{Challenges with OMG specifications}
%\label{sec:problem}
@@ -131,16 +131,50 @@
\label{fig:exampleAS}
\end{figure}
+\subsection{Collection literal part}
+
+The parts of a collection literal expression in OCL are provided by \textit{collection literal part}s. Listing~\ref{lst:CollectionLiteralExpExample} is an example of a collection literal expression comprising three comma-separated collection literal parts.
+
+\begin{lstlisting}[label=lst:CollectionLiteralExpExample, language=OCL]
+Sequence{1, 1+1, 3..9+1} -- equivalent to Sequence{1,2,3,4,5,6,7,8,9,10}
+\end{lstlisting}
+
+To be more specific, a collection literal part could either be a simple element (i.e comprising one expression) of a collection, or a collection range which represents an integer range between two expressions. The rationale of choosing this particular OCL construct is two fold: it will be used to show why the OMG specification is faulty, thus, motivate the need for a better DSL to declare CS2AS bridges (Section~\ref{sec:semi-formal-solution}); and we can show the essence of the CS2AS mappings description (Subsection~\ref{subsec:mappings}). Figure~\ref{fig:CollectionLiteralPartCS} shows the CS definitions related to a collection literal expression.
+
+\begin{figure}[htbp]
+\centering
+\begin{subfigure}{0.5\textwidth}
+ \centering
+\begin{lstlisting}[language=Xtext]
+CollectionLiteralPartCS:
+ ExpCS | CollectionRangeCS
+
+CollectionRangeCS:
+ ExpCS '..' ExpCS
+\end{lstlisting}
+% \caption{CollectionLiteralPartCS grammar }
+% \label{fig:CollectionLiteralPartCS:a}
+\end{subfigure}%
+\begin{subfigure}{0.5\textwidth}
+ \centering
+ \includegraphics[scale=0.75]{images/CollectionLiteralPartCS.png}
+% \caption{CollectionLiteralPartCS metamodel }
+% \label{fig:CollectionLiteralPartCS:b}
+\end{subfigure}
+\caption{CollectionLiteralPartCS Grammar and partial CS Metamodel}
+\label{fig:CollectionLiteralPartCS}
+\end{figure}
+
\subsection{Let expression}
-A \textit{let expression} is used in OCL in order to declare a variable to be used inside another OCL expression. Listing~\ref{lst:letExpExample} shows an example of the notation:
+A \textit{let expression} is used in OCL in order to declare a variable to be used inside another OCL expression. The following listing shows an example of the notation:
\begin{lstlisting}[label=lst:letExpExample, language=OCL]
let var : String = 'something' in var.oclIsTypeOf(String)
\end{lstlisting}
-This expression is interesting because it's related to one of the main activities of the CS2AS DSL: name resolution. Whilst a let expression declares a new variable, the \emph{'in'} expression contains a variable expression referring to that variable (note the reference from VariableExp to Variable in the AS excerpt depicted by Figure~\ref{fig:exampleAS}). This activity of creating references between elements of the AS based on a name lookup is called name resolution. Figure~\ref{fig:LetExpCS} shows the CS definitions related to a let expression.
+This expression is interesting because it's related to one of the main activities of the CS2AS DSL: name resolution. Whilst a let expression declares a new variable, the \emph{'in'} expression contains a variable expression referring to that variable (note the reference from VariableExp to Variable in the AS excerpt depicted by Figure~\ref{fig:exampleAS}). This activity of creating references between elements of the AS based on a name lookup is called name resolution (Subsection~\ref{subsec:nameReso}). Figure~\ref{fig:LetExpCS} shows the CS definitions related to a let expression.
\begin{figure}[htbp]
\centering
@@ -170,7 +204,9 @@
\subsection{Variable expression}
-A \textit{variable expression} in OCL references a variable defined elsewhere. The reference may explicitly or implictly refer to the \emph{self} context variable or to an iterator variable, or explicitly to a variable defined in an outer let expression or to a parameter of an operation definition. Discovering and prioritizing the candidate definitions is performed by the name resolution activity. The \emph{varName} provided by a \emph{VariableExpCS} in the concrete syntax is used to look up a \emph{Variable} in the AS. Figure~\ref{fig:VariableExpCS} shows the CS definitions related to a variable expression.
+A \textit{variable expression} in OCL references a variable defined elsewhere. The reference may explicitly or implictly refer to the \emph{self} context variable or to an iterator variable, or explicitly to a variable defined in an outer let expression or to a parameter of an operation definition. Discovering and prioritizing the candidate definitions is performed by the name resolution activity. The \emph{varName} provided by a \emph{VariableExpCS} in the concrete syntax is used to look up a \emph{Variable} in the AS.
+
+Likewise, \textit{variable expression} will be also used to introduce the concern of CS disambiguation in Subection\ref{subsec:disamb}. Figure~\ref{fig:VariableExpCS} shows the CS definitions related to a variable expression.
\begin{figure}[htbp]
\centering
@@ -193,41 +229,12 @@
\label{fig:VariableExpCS}
\end{figure}
-\subsection{Collection literal part}
-The parts of a collection literal expression in OCL are provided by \textit{collection literal part}s. Listing~\ref{lst:CollectionLiteralExpExample} is an example of a collection literal expression comprising three comma-separated collection literal parts.
-
-\begin{lstlisting}[label=lst:CollectionLiteralExpExample, language=OCL]
-Sequence{1, 1+1, 3..9+1} -- equivalent to Sequence{1,2,3,4,5,6,7,8,9,10}
-\end{lstlisting}
-
-To be more specific, a collection literal part could either be a simple element (i.e comprising one expression) of a collection, or a collection range which represents an integer range between two expressions. This syntax element in OCL is interesting because it priovides a very simple example of another concern for our CS2AS bridge; CS disambiguation. In this case, a \emph{CollectionLiteralPartCS} can be disambiguated either to a \emph{CollectionItem} or to a \emph{CollectionRange}, depending on how many expressions were used in the collection literal part: one expression disambiguates to a \emph{CollectionItem}; two expressions separated by \emph{..} diamiguate to a \emph{CollectionRange}. Figure~\ref{fig:CollectionLiteralPartCS} shows the CS definition related to a collection literal part.
-
-\begin{figure}[htbp]
-\centering
-\begin{subfigure}{0.5\textwidth}
- \centering
-\begin{lstlisting}[language=Xtext]
-CollectionLiteralPartCS:
- ExpCS ('..' ExpCS)?
-\end{lstlisting}
-% \caption{CollectionLiteralPartCS grammar }
-% \label{fig:CollectionLiteralPartCS:a}
-\end{subfigure}%
-\begin{subfigure}{0.5\textwidth}
- \centering
- \includegraphics[scale=0.75]{images/CollectionLiteralPartCS.png}
-% \caption{CollectionLiteralPartCS metamodel }
-% \label{fig:CollectionLiteralPartCS:b}
-\end{subfigure}
-\caption{CollectionLiteralPartCS Grammar and partial CS Metamodel}
-\label{fig:CollectionLiteralPartCS}
-\end{figure}
\section{Semi-formal solution: OCL Clause 9.3}
\label{sec:semi-formal-solution}
-The OCL specification provides a full attribute grammar in which inherited and synthesized attributes are used to describe how the AS is computed from the CS. Figure~\ref{fig:CollectionLiteralPartOMG} shows an example. The specification uses OCL expressions to express how the different attributes are computed. Attribute grammar are a suitable mechanism to describe a CS2AS bridge; however, they have the following limitations.
+The OCL specification provides a full attribute grammar in which inherited and synthesized attributes are used to describe how the AS is computed from the CS. Figure~\ref{fig:CollectionLiteralPartOMG} shows an example. The specification uses OCL expressions to express how the different attributes are computed. Attribute grammar are a suitable mechanism to describe a CS2AS bridge; however, we will add some critics about it.
\begin{figure}[htbp]
\centering
@@ -243,7 +250,7 @@
The inherited attributes contribute to the name resolution by flowing down an Environment hierachy of all available name-element pairs from parent to child nodes using another special CS property; \emph{env}. In this case all names visible in the parent are passed with out modification to the children.
-The disambiguating rules provide guidance on the resolution of ambiguities. In this simple example, the ambiguity is resolved by the two grammar rules and so no further disambiguation is needed.
+The disambiguating rules provide guidance on the resolution of ambiguities. In this simple example, there is no ambiguity.
\begin{figure}[htbp]
\centering
@@ -251,9 +258,9 @@
\caption{OCL specification for CollectionRangeCS to CollectionRange}
\label{fig:CollectionRangeOMG}
\end{figure}
-The rules for collection rangew follow a single pattern. There is now just one grammar production whose two OclExpressions are distinguished by \verb$[1]$ and \verb$[2]$ suffixes. The synthesized attributes have two properties to populate.
+The rules for collection ranges follow a single pattern. There is now just one grammar production whose two OclExpressions are distinguished by \verb$[1]$ and \verb$[2]$ suffixes. The synthesized attributes have two properties to populate.
-\textbf{Critique} The presentation comes quite close to specifying what is needed, but uses an intuitive mix of five sub-languages without any tool assistance. The typo whereby the final line of the synthesized attributes uses \emph{CollectionItem::OclExpression} rather than \emph{CollectionItem::item} has gone unreported for over 10 years.
+\textbf{Critique} The presentation comes quite close to specifying what is needed, but uses an intuitive mix of five sub-languages without any tool assistance. In Figure~\ref{fig:CollectionLiteralPartOMG}, the typo whereby the final line of the synthesized attributes uses \emph{CollectionItem::OclExpression} rather than \emph{CollectionItem::item} has gone unreported for over 10 years.
The lack of any underlying models makes it impossible for tool vendors to re-use the rules. Tool vendors must transcribe and risk introducing further errors.
@@ -280,7 +287,8 @@
\item Other OMG related languages could be considered (such as one of the QVT languages), however OCL is a well known OMG language and is the basis of many others. A QVT practitioner inherently knows OCL but not vice-versa.
\end{itemize}
-Instances of the internal DSL are take the form of Complete OCL documents and can be maintained using Complete OCL tools \cite{eclipseOclOnline}. Multiple documents can be used to partition the specification into modules for topics such as Messages or States and to separate the distinct mapping, name-resolution, and disambiguation concerns of the CS2AS bridge.
+Instances of the internal DSL take the form of Complete OCL documents and can be maintained using Complete OCL tools \cite{eclipseOclOnline}. Multiple documents can be used to partition the specification into modules %for topics such as Messages or States and
+to separate the distinct mapping, name-resolution, and disambiguation concerns of the CS2AS bridge.
\subsection{Shadow Object Construction}
\label{subsec:ShadowExp}
@@ -290,9 +298,9 @@
\subsection{CS2AS mappings}
\label{subsec:mappings}
-In this subsection we will explain the main CS2AS mappings description language. We start by introducing an instance of the language so that the reader can have an indication of the DSL used to describe the bridge. Listing~\ref{lst:exampleCS2ASdesc} corresponds to the CS2AS description of the OCL constructs introduced in the running example (Section~\ref{sec:example}).
+In this subsection we will explain the main CS2AS mappings description language. We start by introducing an instance of the language so that the reader can have an indication of the DSL used to describe the bridge. Listings ~\ref{lst:exampleCS2ASdescA} and ~\ref{lst:exampleCS2ASdescB} correspond to the CS2AS descriptions of the OCL constructs introduced in the running example (Section~\ref{sec:example}).
-\begin{lstlisting}[caption=CS2AS description for running example, label=lst:exampleCS2ASdesc, language=OCL]
+\begin{lstlisting}[caption=CS2AS description for a collection literal part, label=lst:exampleCS2ASdescA, language=OCL]
context CollectionLiteralPartCS
def : ast() : ocl::CollectionLiteralPart =
ocl::CollectionItem {
@@ -311,7 +319,7 @@
The mapping is performed by invoking the \emph{ast()} operation on a CS element. Polymorphic dispatch ensures that the CS element-specific operation is used unlike the \emph{ast} property of the semi-formal approach. The `abstract syntax mapping' and `synthesized attributes' of the semi-formal approach are modeled by the the shadow construction of the appropriate AS type and initialization of its properties. (The initialiization includes the \emph{type} property omitted by the OCL specification.)
-\begin{lstlisting}[caption=CS2AS description for running example, label=lst:exampleCS2ASdesc, language=OCL]
+\begin{lstlisting}[caption=CS2AS description for let and variable expressions, label=lst:exampleCS2ASdescB, language=OCL]
context LetExpCS
def : ast() : ocl::LetExp =
ocl::LetExp {
@@ -351,7 +359,7 @@
%A more detailed explanation of the whole DSL, as well as the rationale about its design decisions, follows. All the listing and line references below correspond to Listing~\ref{lst:exampleCS2ASdesc}:
-\textbf{Declarativeness:} An important characteristic of the DSL is that it comprises declarative OCL constraints. The OCL constraints specify only true correspondences between AS and CS after a valid conversion. Discovery of a suitable order in which to perform CS to AS conversions requires an implementing tool to analyze the OCL constraints and exploit their inter-dependencies. (This was also the unstated policy of the semi-formal approach.)
+\textbf{Declarativeness:} An important characteristic of the DSL is that it comprises declarative OCL constraints. The OCL constraints specify only true correspondences between AS and CS after a valid conversion (FIXME ASBH. Be careful I think this is not true with the ShadowExp usages. I'd not include this sentence). Discovery of a suitable order in which to perform CS to AS conversions requires an implementing tool to analyze the OCL constraints and exploit their inter-dependencies. (This was also the unstated policy of the semi-formal approach.)
\textbf{Operations:} The CS2AS bridge is described by the means of operation definitions. The underlying rationale is that those definitions on a potentially complex class hierarchy of the CS can be overridden. Due to this overriding mechanism, we are providing some flexibility to cope with special cases such as those involving language extensions, as they occur in the OCL and QVT specifications. The operation name is not relevant, but we propose the name \emph{"ast"} because it is aligned with the name used in the attribute grammar exposed in the OCL specification.
@@ -359,13 +367,14 @@
\textbf{Operation Calls:} To compute properties of any AS element we will normally need to access to other AS elements corresponding to the CS ones. Given that we are using \emph{ast} operations to set a correspondence between CS and AS elements, an \emph{ast} operation call expression (OCE) will be used to denote that we want to obtain the AS element corresponding to the CS element source of that OCE. For example, at line 4, in order to initialize the \emph{LetExp::variable} property, we use the \emph{ast} OCE to obtain the \emph{Variable} corresponding to the \emph{VariableDeclarationCS} belonging to the context \emph{LetExpCS} element (via the \emph{LetExpCS::variable} property).
-\textbf{Self-contained:} With the goal in mind of using the proposed internal DSL to rewrite part of the OMG specifications, the declaration of the CS2AS bridge for a particular CS element will be complete and self-contained. This means that the computations for all the properties of the corresponding AS element are expressed in the shadow type expression, even though those properties belong to any of the AS element supertypes. Admitting that the creation of modularized and reusable declarations is convenient when designing CS2AS bridges, Section~\ref{sec:futureWork} will add additional comments to this topic.
+\textbf{Self-contained:} With the goal in mind of using the proposed internal DSL to rewrite part of the OMG specifications, the declaration of the CS2AS bridge for a particular CS element will be complete and self-contained. This means that the computations for all the properties of the corresponding AS element are expressed in the shadow type expression, even though those properties belong to any of the AS element supertypes. Admitting that the creation of more modularized and reusable declarations is convenient when designing CS2AS bridges, Section~\ref{sec:futureWork} will add additional comments to this topic.
+NB ASBH. Perhaps, including the comments in the limitations section (6).
-\textbf{Reusable computations:} Having OCL as the host language for our internal DSL, we could factor out and define more complex and reusable expressions in new operation definitions. Those operations could be reused, by just introducing operation call expressions, across the different computations of the AS element properties. At line 31, we can spot an OCE named \emph{commonType}, which is a reusable operation\footnote{The body of the operation is not relevant, hence, not described in this paper} in charge of computing the common supertype between the source of the OCE, and the provided operation argument.
+\textbf{Reusable computations:} Having OCL as the host language for our internal DSL, we could factor out and define more complex and reusable expressions in new operation definitions. Those operations could be reused, by just introducing operation call expressions, across the different computations of the AS element properties. At line 31, we can spot an OCE named \emph{commonType}, which is a reusable operation\footnote{The body of the operation is not relevant, hence, not described in this paper} in charge of computing the common supertype between the source of the OCE, and the provided operation call argument.
-\textbf{Names resolution:} As a special case of reusable computation, we want to highlight one which links with Subsection~\ref{subsec:nameReso}: name resolution. It's common a situation in which an AS element refers to a different one based a named-based lookup. In our example, at line 11, we have such scenarios, so that in the context of a \emph{VariableExp} element, there will be a lookup activity triggered by the \emph{lookupVariable} OCE, which aim to find a \emph{Variable} to be referred by that \emph{VariableExp}.
+\textbf{Name resolution:} As a special case of reusable computation, we want to highlight one which links with Subsection~\ref{subsec:nameReso}: name resolution. It's common a situation in which an AS element refers to a different one based a named-based lookup. In our example, at line 11, we have such scenarios, so that in the context of a \emph{VariableExp} element, there will be a lookup activity triggered by the \emph{lookupVariable} OCE, which aim to find a \emph{Variable} to be referred by that \emph{VariableExp}.
-\textbf{Disambiguation:} A CS element doesn't necessarily need to be bridged to just one type of AS element. It's a common situation that preliminary ambiguous CS elements are disambiguated to different AS elements. %We can find varied examples in the OCL specification but \emph{CollectionLiteralPartCS} is an easy to understand one. To describe this scenario in our DSL, we will cascade a set of \emph{IfExp} in the body of the \emph{ast} operation: every condition would comprise a disambiguation rule; the \emph{then} and \emph{else} expressions comprise the shadow type expressions denoting the AS element to which the disambiguation would take place. In our running example, lines 23-33 depicts the mentioned scenario and more details about the called \emph{mapsToCollectionItem} operation will be given in Subsection~\ref{subsec:disamb}: disambiguation.
+\textbf{Disambiguation:} A CS element doesn't necessarily need to be bridged to just one type of AS element. It's a common situation that preliminary ambiguous CS elements are disambiguated to different AS elements. Subsection~\ref{subsec:disamb} will elaborate on this topic. %We can find varied examples in the OCL specification but \emph{CollectionLiteralPartCS} is an easy to understand one. To describe this scenario in our DSL, we will cascade a set of \emph{IfExp} in the body of the \emph{ast} operation: every condition would comprise a disambiguation rule; the \emph{then} and \emph{else} expressions comprise the shadow type expressions denoting the AS element to which the disambiguation would take place. In our running example, lines 23-33 depicts the mentioned scenario and more details about the called \emph{mapsToCollectionItem} operation will be given in Subsection~\ref{subsec:disamb}: disambiguation.
\subsection{Name resolution description}
\label{subsec:nameReso}
@@ -508,23 +517,102 @@
\subsection{Disambiguation}
\label{subsec:disamb}
-To conclude the explanation of the proposed OCL based internal DSL, we briefly discuss the CS disambiguation rules which let us produce different AS elements from the corresponding ambiguous CS element. Disambiguation is a concern different to name resolution, but it is similarly used across the CS2AS mappings definition. The OCL-based descriptions can be defined in their own file and therefore comprise the disambiguation rules for the OMG specification.
+As we commented in the introduction, CS disambiguation is another important concern which needs to be addressed during the CS2AS bridge. To explain the need of disambiguation rules, let's focus on the following simple OCL expression:
-As we saw in subsection~\ref{subsec:mappings}, in our running example we identified the \emph{mapsToCollectionItem} operation call as the condition required to disambiguate a \emph{CollectionLiteralPartCS} towards either a \emph{CollectionItem} or a \emph{CollectionRange}. Now, Listing~\ref{lst:CS2ASdisambiguation} shows the definition of that \emph{mapsToCollectionItem}, exposing how the rule to disambiguate a \emph{CollectionLiteralPartCS} will depend on the presence (or not) of the \emph{last} expression.
-
-\begin{lstlisting}[caption=CS disambiguation rule of the running example, label=lst:CS2ASdisambiguation, language=OCL]
-context CollectionLiteralPartCS
-def : mapsToCollectionItem() : Boolean =
- self.last = null
+\begin{lstlisting}[language=OCL]
+x.y
\end{lstlisting}
-As the reader might note, this disambiguation scenario is a trivial one because very little CS information is required to decide if we disambiguate a \emph{CollectionLiteralPartCS} towards either a \emph{CollectionItem} or a \emph{CollectionRange}. Potentially, a more elaborated grammar definition would allow us to prevent any need of a disambiguation rule in this case. However:
+In a first glance, \emph{'y'} is a property call expression over an \emph{'x'} variable expression. However, whilst \emph{'y'} is certainly a property call expression , \emph{'x'} doesn't necessarily have to be a variable expression. It actually depends on the context in which that OCL expression is used, because \emph{'x'} could also be another property call expression over the implicit variable \emph{self}, i.e. \emph{self.x.y}. As commented in Section X, The OCL specification doesn't help to clarify this situation, because they provide a wrong (ambiguous) grammar. FIXME ASBH, I'm unsure if the problem with the ambiguous grammar (VariableExpCS[A] and PropertyCallExpCS[B] rules) should be explained here or previously
+
+To sort out this situation, we need to make use of unambiguous CS elements, plus additional disambiguation rules. These rules will specify towards which elements of the AS, an ambiguous CS element will be disambiguated.
+
+For this particular OCL example, the specification would need to introduce a concept such as \emph{NameExpCS} which simply comprises a name. Figure~\ref{fig:NameExpCS} shows the CS definitions related to an ambiguous name expression.
+
+\begin{figure}[htbp]
+\centering
+\begin{subfigure}{0.5\textwidth}
+ \centering
+ \begin{lstlisting}[label=lst:NameExpEBNF, language=Xtext]
+ NameExpCS:
+ simpleName isMarkedPreCS?
+ \end{lstlisting}
+% \caption{VariableExpCS grammar excerpt}
+% \label{fig:VariableExpCS:a}
+\end{subfigure}%
+\begin{subfigure}{0.5\textwidth}
+ \centering
+ \includegraphics[scale=0.75]{images/NameExpCS.png}
+% \caption{VariableExp metamodel excerpt}
+% \label{fig:VariableExpCS:b}
+\end{subfigure}
+\caption{NameExpCS Grammar and partial CS Metamodel}
+\label{fig:NameExpCS}
+\end{figure}
+
+Then, additional disambiguation rules can make use of information from the CS and/or AS, in order to discern which AS element is created from that \emph{NameExpCS} i.e a \emph{VariableExp}, otherwise a \emph{PropertyCallExp}. For instance, Listing~\ref{lst:nameExpDisambiguation} shows the definition for the CS2AS mapping of a \emph{NameExpCS}, in which \emph{isAVariableExp()} operation call is introduced at line 3 and the referenced operation will comprise the disambiguation rule. The reader should not that:
\begin{itemize}
-\item The grammar excerpt corresponding to the running example is the one proposed by the specification. Our goal is to provide a flexible DSL that lets us tackle any CS2AS bridging scenario in which we might encounter big CS2AS gaps in favor of more concise grammars (which comprise more ambiguous CS elements when compared with more elaborated grammars).
-\item We can also find more complex disambiguation scenarios in which not only CS (syntactic) information is required, but also AS (semantic) information is needed to disambiguate an ambiguous CS element in a given context. A typical scenario in OCL is when lookups of AS named elements are needed to know if a simple name preceding a \emph{'.'} corresponds to either a variable (hence, VariableExp is the disambiguation result) or to a property of the implicit self variable (hence, PropertyCallExp is the disambiguation result). We can find other related examples in \cite{willink2010oclXtext}.
+\item VariableExpCS and PropertyCallExpCS metaclasses wouldn't be needed any more. The corresponding VariableExp and PropertyCallExp would be obtained from this ambiguous NameExpCS
+\item The ambiguous grammar issue commented before would vanish, since now we have only one grammar rule for NameExpCS. In other words, we have created a CS disambiguation to be resolved in the CS2AS bridge, rather than having an ambiguous grammar.
\end{itemize}
+NB ASBH. Problem with this definition, is that we need to define a lookupProperty. It is incorrect/incomplete , and we might to get into a new mess. Omitting the then/else expression might an alternative, but I don't like it....
+\begin{lstlisting}[caption=CS2AS description for an ambiguous name expression, label=lst:nameExpDisambiguation, language=OCL]
+context NameExpCS
+def : ast() : ocl::OclExpression =
+ if isAVariableExp()
+ then
+ let variable = ast().lookupVariable(self)
+ in oclAS::VariableExp {
+ name = name,
+ referredVariable = variable,
+ type = if variable = null
+ then null
+ else variable.type
+ endif
+ }
+ else
+ let property = ast().lookupProperty(self)
+ in oclAS::PropertyCallExp {
+ name = name,
+ referredProperty = property,
+ type = if property = null
+ then null
+ else property.type
+ endif
+ }
+ endif
+\end{lstlisting}
+
+Disambiguation rules might be simple ones which rely on CS information -- syntactic information --, or more complex ones which also involve AS information -- semantic information --. In the introduced example, we need to rely on AS information to conclude if \emph{'x'} corresponds to a \emph{VariableExp} otherwise a \emph{PropertyCallExp}. Specifically, a lookup using the name comprised by the \emph{NameExpCS} is needed. If we found a \emph{Variable} with that name, we would disambiguate \emph{NameExpCS} towards a \emph{VariableExp}; otherwise towards a \emph{PropertyCallExp}.
+
+Listing~\ref{lst:nameExpDisambiguationRule} shows the definition of the disambiguation rule for an ambiguous CS element such as \emph{NameExpCS}. The reader should note that we don't consider the case where \emph{'x'} is not neither a variable nor a property of the implicit \emph{self} context variable (an element is not found in the lookup process). We want to provide a declarative and clean CS2AS bridge for the OMG specification. A strict interpretation of the proposed CS2AS bridge for \emph{NameExpCS}, would end up with a \emph{PropertyCallExp} with a null value for the referred property.
+
+\begin{lstlisting}[caption=NameExpCS disambigutation rule, label=lst:nameExpDisambiguationRule, language=OCL]
+context NameExpCS
+def : isAVariableExp() : Boolean =
+ let variable = ast().lookupVariable(self),
+ in variable <> null
+\end{lstlisting}
+
+%To conclude the explanation of the proposed OCL based internal DSL, we briefly discuss the CS disambiguation rules which let us produce different AS elements from ambiguous CS element. Disambiguation is a concern different to name resolution, but it is similarly used across the CS2AS mappings definition. The OCL-based descriptions can be defined in their own file and therefore comprise the disambiguation rules for the OMG specification.
+
+%As we saw in subsection~\ref{subsec:mappings}, in our running example we identified the \emph{mapsToCollectionItem} operation call as the condition required to disambiguate a \emph{CollectionLiteralPartCS} towards either a \emph{CollectionItem} or a \emph{CollectionRange}. Now, Listing~\ref{lst:CS2ASdisambiguation} shows the definition of that \emph{mapsToCollectionItem}, exposing how the rule to disambiguate a \emph{CollectionLiteralPartCS} will depend on the presence (or not) of the \emph{last} expression.
+%
+%\begin{lstlisting}[caption=CS disambiguation rule of the running example, label=lst:CS2ASdisambiguation, language=OCL]
+%context CollectionLiteralPartCS
+%def : mapsToCollectionItem() : Boolean =
+% self.last = null
+%\end{lstlisting}
+%
+%As the reader might note, this disambiguation scenario is a trivial one because very little CS information is required to decide if we disambiguate a \emph{CollectionLiteralPartCS} towards either a \emph{CollectionItem} or a \emph{CollectionRange}. Potentially, a more elaborated grammar definition would allow us to prevent any need of a disambiguation rule in this case. However:
+%
+%\begin{itemize}
+%\item The grammar excerpt corresponding to the running example is the one proposed by the specification. Our goal is to provide a flexible DSL that lets us tackle any CS2AS bridging scenario in which we might encounter big CS2AS gaps in favour of more concise grammars (which comprise more ambiguous CS elements when compared with more elaborated grammars).
+%\item We can also find more complex disambiguation scenarios in which not only CS (syntactic) information is required, but also AS (semantic) information is needed to disambiguate an ambiguous CS element in a given context. A typical scenario in OCL is when lookups of AS named elements are needed to know if a simple name preceding a \emph{'.'} corresponds to either a variable (hence, VariableExp is the disambiguation result) or to a property of the implicit self variable (hence, PropertyCallExp is the disambiguation result). We can find other related examples in \cite{willink2010oclXtext}.
+%\end{itemize}
+
\section{Related work}
\label{sec:relatedWork}
