Suggestions Facilitating Development of the Project - mn-mikke/Model-driven-Pretty-Printer-for-Xtext-Framework GitHub Wiki

The following text contains proposals extending capabilities of the Xtext framework and other related tools.

Debugger for the Xtend2 Language

The Xtend2 language has been used in order to realize steps discussed in the [Relization](https://github.com/mn-mikke/Model-driven-Pretty-Printer-for-Xtext-Framework/wiki/HeurLang-(Language-for-Defining-Heuristics-of-the-Initial-Box-Model\)) section and the Starting Generation of the Initial Box Model section. Code written in this language is being transformed into Java code. It is very often that a developer makes mistakes in his code. In these days, a debugger for the Xtend2 language does not exist. Thus, when a developer wants to debug code written in the Xtend2 language, he has to use a debugger for Java, look for errors over generated code and fix them in original code. Since generated code is confusing and a human resolves with difficulties which code segment corresponds to a command of original, it should be created a debugger for the Xtend2 language. A one possible solution could be that the debugger for the Xtend2 language would exploit a debugger for Java as its kernel.

Actions Affecting a Meta-Model Generation from a Grammar

The figure on this page depicts that it has to exist a grammar and a meta-model in order to be possible to generate a model from code. Further, it has been mentioned in the Domain of Use section that a meta-model can be generate from a grammar. But when a developer has requirements on the structure of the meta-model, he has to create the meta-model from scratch and reference it inside the grammar because any possibility does not exist how to affect a meta-model generation. Of course, a possibility to post-process the meta-model exists but it is dedicated to trivial changes such as defining default values of variables and adding method prototypes. Although, the Xtext's grammar contains actions (see the Defining Elements of the Parser Rule) influencing model element creation, they allows a developer to not much change structure of the meta-model and also a generated model. Thus it should be added more actions allowing for changing relations contained in the meta-model such as inheritance, aggregation, etc.

Meta-Model Generation Bounded to Design Patterns

The meta-model is only a structure of interdependent classes without behavioral specification. Further, there are generated factories and helpers working with elements of the meta-model. When a developer wants to add behavior to elements of the meta-model, he has to create new classes extending or encapsulating original classes because modification of original elements would be lost after meta-model regeneration. Moreover, it has to be manually written supportive classes. Although, this problem is known and an effort exists to solve it, the [EMF]{http://www.eclipse.org/modeling/emf/} does not contain any feature allowing a user to automatically interconnect a meta-model with a behavioral specification on the base of the chosen design pattern (the original element extended by a new class, the original element encapsulated by a new class, the new methods injected into the original element).

Code Generation Based on a Grammar

When a developer creates a nontrivial grammar, he has no concrete idea about a domain of code matching the grammar. Moreover, he has to write code examples when he wants to test concepts (see the Workflow section) of the Xtext framework dedicated for the developed language. Thus the next proposal is to create a generator that would generate code capturing all features of a grammar.