The document discusses the limitations of UML and traditional software modeling tools, highlighting the complexity and inefficiency they introduce. It advocates for using Domain-Specific Languages (DSLs) as a flexible and precise alternative that improves code generation, collaboration, and project communication. The author emphasizes the importance of choosing the right abstractions to enhance software development and avoid creating 'shelfware'.

1. Overcoming the
Impedance Mismatch
Between Source Code
and Architecture
Peter Friese, itemis
@peterfriese
@xtext
(c) 2009 Peter Friese. Distributed under the EDL V1.0 - http://www.eclipse.org/org/documents/edl-v10.php
More info: http://www.peterfriese.de / http://www.itemis.com

2. Stop drawing useless
diagrams
and writing boring code
Peter Friese, itemis
@peterfriese
@xtext
(c) 2009 Peter Friese. Distributed under the EDL V1.0 - http://www.eclipse.org/org/documents/edl-v10.php
More info: http://www.peterfriese.de / http://www.itemis.com

3. UML - One Language To Rule Them All
http://en.wikipedia.org/wiki/File:UML_Diagrams.jpg

4. UML doesn’t cut it!

6. Increasing Gap

7. od els
M
Code
Increasing Gap

8. (UML) Models = Shelfware
http://www.flickr.com/photos/misterdna/49841409/

9. Solution:
Two-Way Tools

10. Result: Bloated Diagrams No-one can understand
Person SomeOtherMeaninglessClass
User Author Administrator Librarian SomeOtherMeaninglessClass
SomeOtherMeaninglessClass
Library Fee
Book Page
SomeOtherMeaninglessClass
Shelf Folder
SomeOtherMeaninglessClass
SomeOtherMeaninglessClass SomeOtherMeaninglessClass SomeOtherMeaninglessClass

11. Solution: Semantic Diagrams
<<EntityBean>>
Book
title: String
isbn: String

12. Instead of being a
solution...

13. ... two-way tools
have proven to be
a dead-end
http://www.flickr.com/photos/cgommel/561929101/

14. ... two-way tools
have proven to be
a dead-end
http://www.flickr.com/photos/cgommel/561929101/

15. Let’s step back

16. What are the real problems?

17. Boring code

18. Accidental complexity

19. Wrong level of abstraction

20. Anatomy of Modern Software
Software artifact

21. Anatomy of Modern Software
manually written code Frameworks
Libraries

22. Anatomy of Modern Software
manually written
code
Frameworks
schematic code (manually written)
Libraries

23. (Rote) coding doesn’t cut it either!

25. Problems

26. Problems
Can we solve them with models?

27. Yes, we can!

28. Code Generation Helps
Model
manually written
code
Generator
Frameworks
schematic code (generated)
Libraries

29. MDSD
Metamodel
<<instanceof>>
generated manually written
Model Model
code code
Generator
Platform

30. MDSD with UML
Metamodel
<<instanceof>>
generated manually written
Model Model
code code
Generator
UML Platform

31. UML and MDSD

32. A Marriage Made in Heaven?

33. Not.

34. UML and MDSD
⊕ Existing tools
⊕ Good overview
⊕ Graphical - managers / clients like that
⊖ complex meta model
⊖ teamwork challenging at best
⊖ model evolution problematic
⊖ UML is too generic, it’s not a DSL
⊖ UML profiles don’t help either
⊖ tools not integrated in IDE
⊖ long round trips
⊖ developers don’t like diagrams that much

35. UML doesn’t cut it!

37. Looking at the drawbacks...

38. UML and MDSD
⊖ complex meta model
⊖ teamwork challenging at best
⊖ model evolution problematic
⊖ UML is too generic, it’s not a DSL
⊖ UML profiles don’t help either
⊖ tools not integrated in IDE
⊖ long round trips
⊖ developers don’t like diagrams that much

39. ... these are promises of DSLs!

40. What are DSLs?

41. Suppose...

42. You’d want to core an apple...

43. ... for your kids.

44. ?
Right tool for the job?

45. Your trusty swiss army knife!

46. You can use it for other stuff, too.
E.g., opening a bottle of wine.

47. Suppose...

48. You’d want to core a few more apples...

49. ... for an apple cake.

50. Still the best tool for the job?

51. Better use this one.

52. and this one:

53. BUT
avoid the unitasker!

54. BUT
avoid the unitasker!

55. A DSL is...

56. A specific tool
for a specific job

57. A specific tool
for a specific job

58. DSL Samples

59. select name, salary
from employees
where salary > 2000
order by salary

60. <project name="MyProject" default="dist" basedir=".">
<property name="src" location="src"/>
<property name="build" location="build"/>
<property name="dist" location="dist"/>
<target name="init">
<mkdir dir="${build}"/>
</target>
<target name="compile" depends="init">
<javac srcdir="${src}" destdir="${build}"/>
</target>
<target name="dist" depends="compile">
<mkdir dir="${dist}/lib"/>
<jar jarfile="${dist}/lib/MyProject.jar"
basedir="${build}"/>
</target>
<target name="clean">
<delete dir="${build}"/>
<delete dir="${dist}"/>
</target>
</project>

61. <project name="MyProject" default="dist" basedir=".">
<property name="src" location="src"/>
<property name="build" location="build"/>
<property name="dist" location="dist"/>
<target name="init">
<mkdir dir="${build}"/>
</target>
<target name="compile" depends="init">
<javac srcdir="${src}" destdir="${build}"/>
</target>
<target name="dist" depends="compile">
<mkdir dir="${dist}/lib"/>
<jar jarfile="${dist}/lib/MyProject.jar"
basedir="${build}"/>
</target>
<target name="clean">
<delete dir="${build}"/>
<delete dir="${dist}"/>
</target>
</project>

62. DSL Advantages
⊕ Focussed
⊕ Precise metamodel, perfect fit
⊕ No misuse / mismodeling (thanks to
constrained meta model)
⊕ diff / merge possible
⊕ teamwork possible
⊕ developers like text
⊖ need to build your own tools

63. DSL Disadvantages
⊕ Focussed
⊕ Precise metamodel, perfect fit
⊕ No misuse / mismodeling (thanks to
constrained meta model)
⊕ diff / merge possible
⊕ teamwork possible
⊕ developers like text
⊖ need to build your own tools

64. 1)Create ANTLR grammar
2)Generate lexer / parser
3)Parser will create parse tree
4)Transform parse tree to semantic model
5)Iterate model
6)Pass model element(s) to template

65. DSLs are...

66. Flexible

67. Adaptable

68. Complicated

69. Expensive

70. - A DSL for Writing DSLs

71. Underlying Technology

72. ar
Model
m
m
ra
G
Generator
Runtime
Superclass
Subclass Class
LL(*) Parser ECore meta model Editor

73. Grammar (similar to EBNF)
grammar org.xtext.example.Entity with org.eclipse.xtext.common.Terminals
generate entity "http://www.xtext.org/example/Entity"
Model:
(types+=Type)*;
Type:
TypeDef | Entity;
TypeDef:
"typedef" name=ID ("mapsto" mappedType=JAVAID)?;
JAVAID:
name=ID("." ID)*;
Entity:
"entity" name=ID ("extends" superEntity=[Entity])?
"{"
(attributes+=Attribute)*
"}";
Attribute:
type=[Type] (many?="*")? name=ID;

74. grammar org.xtext.example.Entity
with org.eclipse.xtext.common.Terminals Meta model inference
generate entity
"http://www.xtext.org/example/Entity"
entity
Model:
(types+=Type)*;
Model
Type:
TypeDef | Entity;
types
TypeDef: *
Type
"typedef" name=ID
name: EString
("mapsto" mappedType=JAVAID)?;
superEntity
JAVAID:
name=ID("." ID)*; TypeDef Entity
Entity: mappedType attributes
"entity" name=ID
Attribute
("extends" superEntity=[Entity])? JAVAID
name: EString
"{" name: EString
many: EBoolean
(attributes+=Attribute)*
"}"; type
Attribute:
type=[Type] (many?="*")? name=ID;

75. grammar org.xtext.example.Entity
with org.eclipse.xtext.common.Terminals Meta model inference
generate entity
"http://www.xtext.org/example/Entity"
entity Rules -> Classes
Model:
(types+=Type)*;
Model
Type:
TypeDef | Entity;
types
TypeDef: *
Type
"typedef" name=ID
name: EString
("mapsto" mappedType=JAVAID)?;
superEntity
JAVAID:
name=ID("." ID)*; TypeDef Entity
Entity: mappedType attributes
"entity" name=ID
Attribute
("extends" superEntity=[Entity])? JAVAID
name: EString
"{" name: EString
many: EBoolean
(attributes+=Attribute)*
"}"; type
Attribute:
type=[Type] (many?="*")? name=ID;

76. grammar org.xtext.example.Entity
with org.eclipse.xtext.common.Terminals Meta model inference
generate entity
"http://www.xtext.org/example/Entity"
entity Alternatives -> Hierarchy
Model:
(types+=Type)*;
Model
Type:
TypeDef | Entity;
types
TypeDef: *
Type
"typedef" name=ID
name: EString
("mapsto" mappedType=JAVAID)?;
superEntity
JAVAID:
name=ID("." ID)*; TypeDef Entity
Entity: mappedType attributes
"entity" name=ID
Attribute
("extends" superEntity=[Entity])? JAVAID
name: EString
"{" name: EString
many: EBoolean
(attributes+=Attribute)*
"}"; type
Attribute:
type=[Type] (many?="*")? name=ID;

77. grammar org.xtext.example.Entity
with org.eclipse.xtext.common.Terminals Meta model inference
generate entity
"http://www.xtext.org/example/Entity"
entity Assignment -> Feature
Model:
(types+=Type)*;
Model
Type:
TypeDef | Entity;
types
TypeDef: *
Type
"typedef" name=ID
name: EString
("mapsto" mappedType=JAVAID)?;
superEntity
JAVAID:
name=ID("." ID)*; TypeDef Entity
Entity: mappedType attributes
"entity" name=ID
Attribute
("extends" superEntity=[Entity])? JAVAID
name: EString
"{" name: EString
many: EBoolean
(attributes+=Attribute)*
"}"; type
Attribute:
type=[Type] (many?="*")? name=ID;

78. Demo

80. Do DSLs cut it?

82. Yes, they do

83. Yes, they do

84. Yes, they do

85. Yes, they do

86. Concentrate on
Essentials

87. Higher Efficiency

88. Better Maintainability

89. No More Boring Code

90. A New Babylonic
Plethora of Languages?

91. DSLs will improve
communication in projects

92. Four Things To Take Home
Beware of the shelfware trap
Stop writing boring code
Choose appropriate abstractions
Better understand your stakeholders