1. On the Use of an Internal DSL
for Enriching EMF Models
Filip Křikava Philippe Collet
Université Nice Sophia Antipolis
I3S - CNRS UMR 7271
France
2012 Workshop on OCL and Textual Modeling (OCL 2012), MODELS’12
September, 30th, 2012 - Innsbruck/AUSTRIA

2. The Journey
2

3. The Journey
- applying MDE into Self-Adaptive Software
Systems
Meta-modeling with EMF
2

4. The Journey
- applying MDE into Self-Adaptive Software
Systems
Meta-modeling with EMF
- limited expressiveness of structural constraints
Enriching EMF with OCL
2

5. The Journey
- applying MDE into Self-Adaptive Software
Systems
Meta-modeling with EMF
- limited expressiveness of structural constraints
constraints Enriching EMF with OCL
operation contracts
implementation of
operation bodies
implementation of
derived features
2

6. The Journey
- applying MDE into Self-Adaptive Software
Systems
Meta-modeling with EMF
- limited expressiveness of structural constraints
constraints Enriching EMF with OCL
operation contracts - encountered number of shortcomings
- since our work is based on Scala
implementation of
operation bodies
Enriching EMF with Scala
implementation of
derived features
2

7. The Journey
- applying MDE into Self-Adaptive Software
Systems
Meta-modeling with EMF
- limited expressiveness of structural constraints
constraints Enriching EMF with OCL
operation contracts - encountered number of shortcomings
- since our work is based on Scala
implementation of
operation bodies
Enriching EMF with Scala
implementation of - internal DSL in Scala to enrich EMF
derived features - similar OCL features
- full advantage of the host language
- state-of-the-art tool support
+
2

8. Outline
• Some Shortcomings of OCL
• Internal DSL Approach
• Implementation
• Conclusion
3

9. Some Shortcomings of OCL
• Based solely on our experience
• different usage of OCL - different pros/cons
• concerned by practicality rather than formality
• not a complete study nor first one (well known issues)
4

10. Some Shortcomings of OCL
Expressions
Constraints Capturing
OCL Expressions Tool Support
Constructs
• Poor support for user
feedback
• Complex expressions are • No support for warning / • Scalability and stability
hard to write and critiques problems with larger
maintain models
• No support for
• Limited extensibility and dependent constraints • Limited developer
reuse feedback
• Limited flexibility in
• Side-effect free context definition • Insufficient debugging
expressions capability
• No support for repairing
• Inconsistency/Confusing inconsistencies
issues • No support for invariant
reuse across different
models
D. Kolovos, et al. On the Evolution of OCL for
Capturing Structural Constraints, In Rigorous
Methods for Software Construction and
Analysis, 2009. 5

11. Internal DSL Approach - Overview
• The shortcomings are related to scalability
• OCL language
• performance, stability and features of OCL tools
• when used in the large (many invariants, complex
expressions)
• similar problems are in other external DSLs (EOL/EVL)
6

12. Internal DSL Approach - Overview
• External DSL like OCL raises the level of abstraction:
7

13. Internal DSL Approach - Overview
• External DSL like OCL raises the level of abstraction:
parent.types
->select(name <> '')
->forAll(e | e <> self implies e.name <> self.name)
7

14. Internal DSL Approach - Overview
• External DSL like OCL raises the level of abstraction:
parent.types
->select(name <> '')
->forAll(e | e <> self implies e.name <> self.name)
• The same could be expressed in plain Java, but ... no
7

15. Internal DSL Approach - Overview
• External DSL like OCL raises the level of abstraction:
parent.types
->select(name <> '')
->forAll(e | e <> self implies e.name <> self.name)
• The same could be expressed in plain Java, but ... no
• Having a language that has a more powerful and
flexible constructs and state-of-the-art tool support
7

16. Internal DSL Approach - Overview
• External DSL like OCL raises the level of abstraction:
parent.types
->select(name <> '')
->forAll(e | e <> self implies e.name <> self.name)
• The same could be expressed in plain Java, but ... no
• Having a language that has a more powerful and
flexible constructs and state-of-the-art tool support
self.parent.types
.filter(name != '')
.forall(e => e != self implies e.name != self.name)
7

17. Internal DSL Approach - Why Scala?
• Modern general purpose language
• Runs on top of JVM
• Well designed for building internal DSLs
• Statically typed using type inference
• Well supported by major tool vendor
8

18. Internal DSL Approach - Basics
• Enriching constructs represented as Scala object
methods
9

19. Internal DSL Approach - Basics
• Enriching constructs represented as Scala object
methods Customer
- printedName : String [1..1]
- getTransactions(until: Date, from: Date) : Transactions [0..*]
9

20. Internal DSL Approach - Basics
• Enriching constructs represented as Scala object
methods Customer
- printedName : String [1..1]
• Derived property: - getTransactions(until: Date, from: Date) : Transactions [0..*]
def getPrintedName (self: Customer): String =
self.owner.title + " " + self.owner.name
9

21. Internal DSL Approach - Basics
• Enriching constructs represented as Scala object
methods Customer
- printedName : String [1..1]
• Derived property: - getTransactions(until: Date, from: Date) : Transactions [0..*]
def getPrintedName (self: Customer): String =
self.owner.title + " " + self.owner.name
9

22. Internal DSL Approach - Basics
• Enriching constructs represented as Scala object
methods Customer
- printedName : String [1..1]
• Derived property: - getTransactions(until: Date, from: Date) : Transactions [0..*]
def getPrintedName (self: Customer): String =
self.owner.title + " " + self.owner.name
9

23. Internal DSL Approach - Basics
• Enriching constructs represented as Scala object
methods Customer
- printedName : String [1..1]
• Derived property: - getTransactions(until: Date, from: Date) : Transactions [0..*]
def getPrintedName (self: Customer): String =
self.owner.title + " " + self.owner.name
9

24. Internal DSL Approach - Basics
• Enriching constructs represented as Scala object
methods Customer
- printedName : String [1..1]
• Derived property: - getTransactions(until: Date, from: Date) : Transactions [0..*]
def getPrintedName (self: Customer): String =
self.owner.title + " " + self.owner.name
• Operation body:
def invokeGetTransactions(self: Customer,
until: Date, from: Date): Set[Transaction] =
self.transactions filter ( t =>
t.date.isAfter(from) && t.date.isBefore(until) )
10

25. Internal DSL Approach - Basics
• Enriching constructs represented as Scala object
methods Customer
- printedName : String [1..1]
• Derived property: - getTransactions(until: Date, from: Date) : Transactions [0..*]
def getPrintedName (self: Customer): String =
self.owner.title + " " + self.owner.name
• Operation body:
def invokeGetTransactions(self: Customer,
until: Date, from: Date): Set[Transaction] =
self.transactions filter ( t =>
t.date.isAfter(from) && t.date.isBefore(until) )
10

26. Internal DSL Approach - Basics
• Enriching constructs represented as Scala object
methods Customer
- printedName : String [1..1]
• Derived property: - getTransactions(until: Date, from: Date) : Transactions [0..*]
def getPrintedName (self: Customer): String =
self.owner.title + " " + self.owner.name
• Operation body:
def invokeGetTransactions(self: Customer,
until: Date, from: Date): Set[Transaction] =
self.transactions filter ( t =>
t.date.isAfter(from) && t.date.isBefore(until) )
10

27. Internal DSL Approach - Basics
• Enriching constructs represented as Scala object
methods Customer
- printedName : String [1..1]
• Derived property: - getTransactions(until: Date, from: Date) : Transactions [0..*]
def getPrintedName (self: Customer): String =
self.owner.title + " " + self.owner.name
• Operation body:
def invokeGetTransactions(self: Customer,
until: Date, from: Date): Set[Transaction] =
self.transactions filter ( t =>
t.date.isAfter(from) && t.date.isBefore(until) )
10

28. Internal DSL Approach - Basics
• Enriching constructs represented as Scala object
methods Customer
- printedName : String [1..1]
• Derived property: - getTransactions(until: Date, from: Date) : Transactions [0..*]
def getPrintedName (self: Customer): String =
self.owner.title + " " + self.owner.name
• Operation body:
def invokeGetTransactions(self: Customer,
until: Date, from: Date): Set[Transaction] =
self.transactions filter ( t =>
t.date.isAfter(from) && t.date.isBefore(until) )
10

29. Internal DSL Approach - Basics
• Constraints
11

30. Internal DSL Approach - Basics
• Constraints
def validateOfAge(self: Customer): Boolean = self.age >= 18
11

31. Internal DSL Approach - Basics
• Constraints
def validateOfAge(self: Customer): Boolean = self.age >= 18
11

32. Internal DSL Approach - Basics
• Constraints
def validateOfAge(self: Customer): Boolean = self.age >= 18
11

33. Internal DSL Approach - Basics
• Constraints
def validateOfAge(self: Customer): Boolean = self.age >= 18
11

34. Internal DSL Approach - Basics
• Constraints
def validateOfAge(self: Customer): Boolean = self.age >= 18
def validateOfAge(self: Customer): Option[String] =
if (self.age >= 18) {
None
else {
Some("The person %s is under age" format self.name)
}
11

35. Internal DSL Approach - Basics
• Constraints
def validateOfAge(self: Customer): Boolean = self.age >= 18
def validateOfAge(self: Customer): Option[String] =
if (self.age >= 18) {
None
else {
Some("The person %s is under age" format self.name)
}
11

36. Internal DSL Approach - Basics
• Constraints
• a constraint that check whether a UML class contains
getInstance method
12

37. Internal DSL Approach - Basics
• Constraints
• a constraint that check whether a UML class contains
getInstance method
def validateDefinesGetInstance(self: UMLClazz) = {
}
13

38. Internal DSL Approach - Basics
• Constraints
• a constraint that check whether a UML class contains
getInstance method
def validateDefinesGetInstance(self: UMLClazz) = {
self.features.find(_.name == "getInstance") match {
}}
14

39. Internal DSL Approach - Basics
• Constraints
• a constraint that check whether a UML class contains
getInstance method
def validateDefinesGetInstance(self: UMLClazz) = {
self.features.find(_.name == "getInstance") match {
case Some(_) => Success
}}
15

40. Internal DSL Approach - Basics
• Constraints
• a constraint that check whether a UML class contains
getInstance method
def validateDefinesGetInstance(self: UMLClazz) = {
self.features.find(_.name == "getInstance") match {
case Some(_) => Success
case None => Error("Missing getInstance"
)}}
16

41. Internal DSL Approach - Basics
• Constraints
• a constraint that check whether a UML class contains
getInstance method
def validateDefinesGetInstance(self: UMLClazz) = {
self.features.find(_.name == "getInstance") match {
case Some(_) => Success
case None => Error("Missing getInstance",
QuickFix("Add a getInstance operation", {
}
))}}
17

42. Internal DSL Approach - Basics
• Constraints
• a constraint that check whether a UML class contains
getInstance method
def validateDefinesGetInstance(self: UMLClazz) = {
self.features.find(_.name == "getInstance") match {
case Some(_) => Success
case None => Error("Missing getInstance",
QuickFix("Add a getInstance operation", {
clazz: UMLClazz =>
clazz.features += create[UMLFeature] { op =>
op.setName("getInstance")
// ...
}
}
))}}
18

43. Internal DSL Approach - Basics
• Constraints dependency
def validateDefinesGetInstance(self: UMLClazz)
@satisfies(“DefinesGetInstance”)
def validateDefinesGetIsStatic(self: UMLClazz)
• Using proxy to ensure each invariant is called at most
once for a specific instance
• Referencing by strings is not very practical
• Looking into Scala 2.10 macros
19

44. Internal DSL Approach - Basics
• Constraints dependency
def validateDefinesGetInstance(self: UMLClazz)
@satisfies(“DefinesGetInstance”)
def validateDefinesGetIsStatic(self: UMLClazz)
• Using proxy to ensure each invariant is called at most
once for a specific instance
• Referencing by strings is not very practical
• Looking into Scala 2.10 macros
19

45. Internal DSL Approach - Extensibility
• Scala is extensible language
• For example, there is no implies operation in Scala
self.parent.types
.forall(e => e != self implies e.name != self.name)
20

46. Internal DSL Approach - Extensibility
• Scala is extensible language
• For example, there is no implies operation in Scala
self.parent.types
.forall(e => e != self implies e.name != self.name)
• Possibility to extend existing types
class ExtBoolean(a: Boolean) {
def implies(b: => Boolean) = !a || b
}
implicit def extBoolean(a: Boolean) = new ExtBoolean(a)
20

47. Internal DSL Approach - Extensibility
• Scala is extensible language
• For example, there is no implies operation in Scala
self.parent.types
.forall(e => e != self implies e.name != self.name)
• Possibility to extend existing types
class ExtBoolean(a: Boolean) {
def implies(b: => Boolean) = !a || b
}
implicit def extBoolean(a: Boolean) = new ExtBoolean(a)
• This way we can add missing OCL operations (closure) 20

48. Internal DSL Approach - Reusability
• Breaking expression into smaller pieces
• Organizing them as functions in objects and libraries
• Shared across project
21

49. Internal DSL Approach - Reusability
• Breaking expression into smaller pieces
• Organizing them as functions in objects and libraries
• Shared across project
• Push further using structural typing - reused across
models
def validateNonEmptyName(self: { def name: String } ) =
!self.name.isEmpty
21

50. Internal DSL Approach - Undefined
and Invalid Values
interface Person {
Person
public String getFirstName();
- firstName : String [0..1]
- lastName : String [1..1]
public String getLastName();
}
• Using the NonEmptyName constraint might lead to NPE
!self.firstName.isEmpty
22

51. Internal DSL Approach - Undefined
and Invalid Values
interface Person {
Person
public String getFirstName();
- firstName : String [0..1]
- lastName : String [1..1]
public String getLastName();
}
• Using the NonEmptyName constraint might lead to NPE
!self.firstName.isEmpty
self.firstName != null implies !self.firstName.isEmpty
22

52. Internal DSL Approach - Undefined
and Invalid Values
interface Person {
Person
public String getFirstName();
- firstName : String [0..1]
- lastName : String [1..1]
public String getLastName();
}
• Using the NonEmptyName constraint might lead to NPE
!self.firstName.isEmpty
self.firstName != null implies !self.firstName.isEmpty
22

53. Internal DSL Approach - Undefined
and Invalid Values
interface Person {
Person public scala.Option<String>
- firstName : String [0..1] getFirstName();
- lastName : String [1..1] public String getLastName();
}
Option<T>
- get() : T
- isDefined : Boolean
… … ...
Some None
23

54. Internal DSL Approach - Undefined
and Invalid Values
interface Person {
Person public scala.Option<String>
- firstName : String [0..1] getFirstName();
- lastName : String [1..1] public String getLastName();
}
Option<T>
- get() : T
- isDefined : Boolean
… … ...
Some None
23

55. Internal DSL Approach - Type Casts
• OCL
if self.oclIsKindOf(Customer) then
self.oclAsType(Customer).someAction()
else
// something else
endif
• Scala
self match {
case c: Customer => c.someAction()
case _ => // something else
}
24

56. Internal DSL Approach - Drawbacks
• Expressions can contain arbitrary code
• difficult to ensure side-effect free expressions
• possibility to use external checker like IGJ
• @ReadOnly parameter annotation
• Loss of formal reasoning and analysis
• No constructs related to postconditions
25

57. Implementation - Sigma Framework
• Simple API for enriching EMF models using
Java class methods - delegate computation
• Small layer on top of EMF and EValidator
• Target language agnostic (Xtend, Kotlin, ...)
• Ecore
EMF
• EValidator
Sigma Core
Sigma Scala
Codegen Dynamic • generate direct calls
EMF Delegates Templates
• reduce the runtime
overhead caused by
reflection
• simplifies
debugging,
code orientation
26

58. Conclusion
• Improve the EMF integration and solid tools to
the community
• Specify the deviations from OCL and its
consequences
• Specify the trade-offs between standardized
OCL and flexibility of the DSL approach
• Looking beyond traditional usage of OCL
27

59. The Journey further on
... ... ...
+
Model to Text Model to Model Model Testing
transformation transformation
28

60. Thank you!
http://nyx.unice.fr/projects/sigma
Filip Křikava
filip.krikava@i3s.unice.fr
The work reported in this paper is partly funded by the ANR SALTY project
under contract ANR-09-SEGI-012.
29

61. Related Work
• There is a plenty of work addressing OCL
shortcomings - popular research subject
• OCLLib, OCLUnit, OCLDoc, ...
• Epsilon project
• JS4EMF
• Xcore
• “C# 3.0 makes OCL redundant”
30

62. Some Shortcomings of OCL
Expressions
• Side-effect free expressions
• by default, expressions are side-effect
• no assignment semantics
• all data-types are immutable
• useful for constraints
• impossible to implement state changing operations
• no support for generic class type parameters
• while having generic collections
31

63. Some Shortcomings of OCL
Expressions
• Some inconsistency, confusions
• ‘.’ and ‘->’ operators
• implicit oclAsSet
• implicit collection flattening in collect
• logical operation with undefined values
• different OCL meta-models
• no support for generic class type parameters
• while having generic collections
32

64. Internal DSL Approach - Principles
• EMF codegen translates model concepts into Java
• model classifier -> Java class
• structural / behavioral feature -> method
33

65. Internal DSL Approach - Principles
• EMF codegen translates model concepts into Java
• model classifier -> Java class
• structural / behavioral feature -> method
• Scala allow to omit parenthesis in zero arg methods
self.getMembership.getParticipant.getDateOfBirth
33

66. Internal DSL Approach - Principles
• EMF codegen translates model concepts into Java
• model classifier -> Java class
• structural / behavioral feature -> method
• Scala allow to omit parenthesis in zero arg methods
self.getMembership.getParticipant.getDateOfBirth
• Remove get noise using codegen dynamic templates
self.membership.participant.dateOfBirth
33

67. Internal DSL Approach - Principles
• EMF codegen translates model concepts into Java
• model classifier -> Java class
• structural / behavioral feature -> method
• Scala allow to omit parenthesis in zero arg methods
self.getMembership.getParticipant.getDateOfBirth
• Remove get noise using codegen dynamic templates
self.membership.participant.dateOfBirth
• Scala supports lambda expressions
• Large number of collection operations
33

68. Some Shortcomings of OCL
Expressions
• Complex expressions are hard to write and maintain
• linearity of the OCL expression
• Limited extensibility and reuse
• difficult to add new operations (i.e. support for regular expressions)
• Side-effect free expressions
• by default side-effect free expressions; no instantiation
• Inconsistency/Confusing issues
• implicit flattening, logic with undefined values, missing generics class
type parameters, etc.
34

69. Some Shortcomings of Tool Support
• Impressive number of academic OCL tools
• lack of commercial tools
• Eclipse OCL project
• Set of OCL editors (e.g. OCLInEcore)
• Based on EMF delegates
• Scalability and stability problems with larger models
• Limited developer feedback
• Insufficient debugging capability
35

70. Some Shortcomings of OCL
Expressions
“... Second, it is compact, yet powerful. You
can write short and to the point expressions
that do a lot.”
- Anders Ivner, foreword to the 2nd edition of The Object Constraint Language
36

71. Some Shortcomings of OCL
Expressions
“... Second, it is compact, yet powerful. You
can write short and to the point expressions
that do a lot.”
- Anders Ivner, foreword to the 2nd edition of The Object Constraint Language
• true for short, straight-forward expressions
• not so true for complex ones
• hard for new users when they move from tutorial
like expressions into real word ones
36

72. The problem with OCL expressions
• OCL in form of expressions that can be chained together
parent.types
->select(name <> '')
->forAll(e | e <> self implies e.name <> self.name)
37

73. The problem with OCL expressions
• The linearity of the expression chaining often leads to long
and complex expressions
self.allContents
->forAll (p | (p.oclIsKindOf(ClassifierRole) implies
p.name = '' implies self.allContents
->forAll (q | q.oclIsKindOf(ClassifierRole) implies
(p.oclAsType(ClassifierRole).base =
q.oclAsType(ClassifierRole).base imples p = q) ) )
and
(p.oclIsKindOf(AssociationRole) implies p.name = '' imples
self.allContents
->forAll ( q | q.oclIsKindOf(AssociationRole) implies
(p.oclAsType(AssociationRole).base =
q.oclAsType(AssociationRole).base imples
p = q) ) )
38

74. The problem with OCL expressions
• The linearity of the expression chaining often leads to long
and complex expressions
self.allContents
->forAll (p | (p.oclIsKindOf(ClassifierRole) implies
p.name = '' implies self.allContents
->forAll (q | q.oclIsKindOf(ClassifierRole) implies
(p.oclAsType(ClassifierRole).base =
q.oclAsType(ClassifierRole).base imples p = q) ) )
and
(p.oclIsKindOf(AssociationRole) implies p.name = '' imples
self.allContents
->forAll ( q | q.oclIsKindOf(AssociationRole) implies
(p.oclAsType(AssociationRole).base =
q.oclAsType(AssociationRole).base imples
p = q) ) )
• This combined with poor tool support
39