DevBooststLogotudLogorewerseLogo modelplexLogo
The fastest way to refinable, durable and evolution-resistant textual syntaxes for EMF models!

5 reasons why to create a textual syntax for your models

  • Readability: A custom text syntax is much easier to read than XML/XMI. Custom text syntax can use symbols (e.g., special characters) to express the meaning of model elements.
  • Diff/Merge/VCS: Comparing and diffing XML (the default representation for EMF models) often produces useless results. Even small changes made to a model result in large diffs that are hard to understand by developers. When models need to be version controlled effective diffing and merging is crucial. Using custom text syntax for model can support this central development activity.
  • Evolution: Whenever metamodels change, existing model instances may not be readable anymore. Text syntax allows to extend the file format for models and to preserve backward compatibility. Even if the syntax for a new version of the metamodel is incompatible, existing models can be fixed using a text editor. Fixing an XML file is usually much harder.
  • Tool autonomy: Text can be edited on every OS with a simple text editor. More complex formats (e.g., XML or binary) are hard to edit without sophisticated tools. If those tools cannot read existing files users are doomed. Text can always be edited.
  • Quick model instantiation: The default HUTN syntax that can be fully automatically be generated by EMFText from a given metamodel instantly allows to create model instances. In contrast to the existing generic model editor - the EMF default tree editor - text can be created very fast (at least faster than creating a model tree). Model instances can thus be obtained quickly.

5 reasons why to create models from text

  • Tool reuse: There are many tools that operate on models and in particular on Ecore models. Deriving a model from text allows to use these tools. One can transform documents (e.g., using ATL) or analyze them (e.g., with OCL). Even graphical editors can be generated for artifacts that were represented as text before, which allows alternative editing.
  • Know-how reuse: The aforementioned tools employ different languages to operate on models. Treating text documents as models allows to apply these languages to all kinds of documents. The know-how of developers can be applied to a much broader field. For example, once a developer knows OCL, she can query all kinds of model-based documents. There is no difference anymore between querying source code, UML diagrams or a requirements document. The same applies to transformation languages.
  • Explicit representation of text document structure: When text is transformed to models a metamodel that specifies the elements contained in the text is needed. Creating such a metamodel explicitly describes the elements and the structure of text documents. The meta information about the documents is not longer hidden in parsers (or other source code) that works on the documents. Thus, it is easier to mantain document formats and evolve them.
  • Tracing software artifacts: Most artifacts involved in software development are text-based. To trace requirements from initial documents down to the running code, links between artifacts must be established. One can do so by persisting information about linked parts of artifacts using line and column numbers. However, such a mapping is very fragile. Creating models from text allows to trace semantic units (model elements) instead of single characters. Text (e.g., program code) can be changed without loosing track of the trace relations between artifacts.
  • Graphs instead of strings: Plain text is basically a sequence of characters (i.e., a one-dimensional structure). But, most text documents are used to express hierarchies (i.e., tree structures) or even graphs. Tools that operate on such text documents are much easier to build if the document can be accessed as tree/graph rather than a sequence of characters. Traditionally, parser generators are used to create trees for text, but still the graph-structured documents are not supported. Creating models from text allows to easily obtain the graph contained in the document and perform operations on it.

Convinced? Go and get it!