Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

A Model-Driven Approach to Generate External DSLs from Object-Oriented APIs


Published on

Developers in modern general-purpose programming languages create reusable code libraries by encapsulating them in Applications Programming Interfaces (APIs). Domain-specific languages (DSLs) can be developed as an alternative method for code abstraction and distribution, sometimes preferable to APIs because of their expressivity and tailored development environment. However
the cost of implementing a fully functional development environment for a DSL is generally higher. In this paper we propose DSLit, a prototype-tool that, given an existing API, reduces the cost of developing a corresponding DSL by
analyzing the API, automatically generating a semantically equivalent DSL with
its complete development environment, and allowing for user customization. To build this bridge between the API and DSL technical spaces we make use of existing
Model-Driven Engineering (MDE) techniques, further promoting the vision of MDE as a unifying technical space.

Published in: Software
  • Be the first to comment

  • Be the first to like this

A Model-Driven Approach to Generate External DSLs from Object-Oriented APIs

  1. 1. Valerio Cosentino Massimo Tisi Javier Luis Canovas Izquierdo SOFSEM, 2015, Pec pod Sněžkou, Czech Republic A Model-Driven Approach to Generate External DSLs from Object-Oriented APIs 1© AtlanMod -
  2. 2. Outline  Introduction  Model Driven Engineering  From API to DSL  Conclusion and Future work 2© AtlanMod -
  3. 3. Introduction  Code abstraction and reuse allow the use of existing software knowledge (i.e., code libraries) to build new software by reducing: – Time – Resources – Redundancy  Code libraries can be accessed via: – APIs using mechanisms (function call, class inheritance, etc.) provided by the General- purpose Programming Language (GPL) – DSLs (Domain Specific Languages) 3© AtlanMod -
  4. 4. Introduction  API vs DSL: 4© AtlanMod -
  5. 5. Introduction  Are DSLs better than APIs?[1] – Pros:  DSLs can be more expressive, maintainable, concise and readable  Static validation, syntax highlighting, etc.  Interpretation/compilation optimized for the DSL code execution – Cons:  DSLs requires a higher development cost [1] Kelly, S., Tolvanen, J.P.: Domain-Specific Modeling: Enabling Full Code Generation. Wiley IEEE Computer (2008) 5© AtlanMod -
  6. 6. Introduction  How to reduce the development cost when building a DSL? – Model Driven Engineering (MDE)  Automatic generation of DSL components: – compiler, validator, development environment 6© AtlanMod -
  7. 7. Model Driven Engineering  What is MDE? – Models: first class entities in MDE (abstract representation of the knowledge for a given domain) – Model transformations: operaration for model handling  Injectors/extractors to move between technical spaces [2] [2] Kurtev, I., Bezivin, J., Aksit, M.: Technological Spaces : an Initial Appraisal. In: DOA. (2002) 1–6 7© AtlanMod -
  8. 8. From API to DSL 8© AtlanMod -
  9. 9. From API to DSL 9© AtlanMod -
  10. 10. From API to DSL 10© AtlanMod -
  11. 11. API classes to API metamodel  Mapping[3] – API class definitions  metamodel elements – Java classes  metaclasses  Attributes  metaclass attributes  Methods  operations  Customization: – Some APIs can generate very large metamodels  Selection of a subset of API elements – Tunable API metamodel  Manual modifications [3] Canovas Izquierdo, J.L., Jouault, F., Cabot, J., Garcıa Molina, J.: API2MoL: Automating the building of bridges between APIs and Model- Driven Engineering. Inform. Software Tech. 54(0) (2012) 257–273 11© AtlanMod -
  12. 12. From API to DSL 12© AtlanMod -
  13. 13. API metamodel to DSL metamodel  Domain-specific concepts extracted from the API metamodel  Domain-independent API structure – Templates 13© AtlanMod -
  14. 14. Templates  Plain Old Data (POD) – For simple APIs to create and maintain a data structure – API classes composed by getters, setters and constructors 14© AtlanMod -
  15. 15. Templates  Fluent – For APIs that rely on chaining method calls – The return values of the method calls (keywords) are used to structure the DSL 15© AtlanMod -
  16. 16. Templates  SimpleJava – For APIs that do not fit in the previous categories – Java sub-set(statements, declarations, etc.) 16© AtlanMod -
  17. 17. From API to DSL 17© AtlanMod -
  18. 18. DSL metamodel to DSL tooling  Bridge between the Model TS and the Grammar TS – Mapping of metamodel elements into the grammar rules – Development environment  The generation process is parameterized by: – The DSL metamodel (concepts, attributes, references, cardinalities, etc.) – The template chosen (the grammar structure, the development environment and compiler) – Particularized for Xtext[4] [4] Eysholdt, M., Behrens, H.: Xtext: implement your language faster than the quick and dirty way. In: SPLASH. (2010) 307–309 18© AtlanMod -
  19. 19. From API to DSL 19© AtlanMod -
  20. 20. Compiler generation  Since the semantics of the DSL template is known, a DSL instance can be transformed into its equivalent in Java – SimpleJava  DSL concepts have a one-to-one correspondence with Java constructs  DSL model to Java model (MoDisco[5])  Java model to Java readable file (Acceleo[6]) [5] |6] 20© AtlanMod -
  21. 21. Conclusion and Future work  MDE approach to connect API, Model and Grammar technical spaces  Template mechanism to generate the resulting DSL  Proof of concept  Future work: – Identify more templates to cover other types of DSLs (API characterization) – Study how our method could cope with more complex APIs (event-driven, concurrent, etc.) – Explore how distinct APIs used in the same GPL can be combined at DSL-level (interleaving DSLs) 21© AtlanMod -