Lehrstuhl Systemanalyse

"How does TEF work"-FAQ

Templates describing a textual notation, how do they look like?

Templates define how model elements, their attributes, and the values of attributes are represented. Templates also define all the semantic aspects that are necessary to create a semantic-rich editor. This means templates describe which items of the text will be highlighted, what proposals appear in a code completion (code assist) , which parts can be folded, or how are the text indented. Templates are nested in each other to create a complete notation.

There are different classes of templates. The most important are element templates, attribute templates, and value templates. Templates are always nested in that order: element templates contain attribute templates, and these contain value templates. Some templates are predefined; some have to be written by the notation's designer. The notation designer defines an element template for each model element (e.g. meta-model class). Within these element templates, he uses predefined attribute templates to define how the attributes of this model element are represented: there are predefined templates for sets, sequences, or single values. For each attribute template a value template has to be given to determine the representation for single attribute values. This can be predefined value templates, for example for primitive values like strings or integers. Element templates are also value templates and can be used to define either element containment or element references. These templates can be mixed with different classes of other templates for white spaces, indentations, keywords, separators, braces, etc.

What does separation of view from model really mean?

A model is just an abstraction. In general we cannot see or touch a model; it exists only in our minds or in a computer. What we actually draw on a piece of paper or see on a computer display is a representation of a model, a view onto the model. Separating view from model means to stop identifying the view with the model. As a result it is easy to accept that there can be more than one view for a model or that their can be views that represent only parts of a model.

Separation of view and model allows a different practice for working with models: models can be used and changed by different users at the same time, you can use different notations for different views, and you can use different editors for one model. It also means that you can configure a view: show or suppress interesting or irrelevant model information. You can mix different kinds of notations. For example combine graphical and textual model editors. Textual model editing also allows you to use read-only views as visualisations for computer generated models.

Textual editing is fine, but I want to type my models. Is TEF still right for me?

TEF-Editors allow to add elements via code assist: you select an element kind from a list and a whole code-snippet appears. This is very appealing for things like meta-model editors, where you deal with classes and attributes. But, imagine expressions: you don't want to create something like ln((a+20)*5) solely based on code completion, because you virtually have to select each character from a menu. So what is the solution?

We are using something that we like to call live parsing. Like in normal context free parsers, we use a stack automaton to analyse text. But instead of analysing a whole file, we do our analysis in the moment you type the text. The analysis breaks down to a sequence of shift and reduce actions. You simply type symbols and as long as it is unclear which model element you want to type the symbols are shifted on the stack. In the moment a sequence of symbols on the stack is recognised and reduces to the representation of a model element the stack is cleared and the actual model element is created. This way the model-view-controller style editing is preserved and you can use TEF editors like normal text editors and type your text.

TEF only provides a textual representation for every thing in a model. What about things that aren't in a model, like white spaces and indentations?

Since TEF-Editors create indented texts from models without any knowledge about white spaces between elements, some information is missing. This "layout"-information is taken from the notation's templates. Templates define how the code is indented: where are white spaces and where not. To ease the definition of code-layout, TEF uses different layout manager. This works like the layout manager in gui-design, which decides over the arrangement of widgets within a widget container. There are different manager for different kinds of layouts. Examples for layouts could be the c/java-like coding with indented blocks, or tabulars like in ancient assembler.

A layout manager defines different roles for the elements in a template. An opening brace in java has the role of a block-opener. After that brace, everything is indented deeper then before. A closing brace functions as a block closer, the indentation is reduced. The layout manager also controls all white spaces and how they appear. The white space between two parameter in a java method declaration is normally a space. But when there are too many parameters the method declaration becomes too long. In this case, the layout manager assigns a new appearance to one of the white spaces between parameters. Instead of a space it becomes a line break followed by a proper indentation. We call this mechanism intelligent white spaces, because the spaces change appearances intellegently based on the context.

Slightly different templates for the same meta-model can be easily used to realise editors with different coding conventions for the same notation. It is up to the user how the model looks like. This way, coding conventions aren't limited to white spaces anymore: keywords, the order of elements, almost everything can be adapted to the user's needs.

A TEF notation and the used meta-model have do be very similar by structure, haven't they? They can't be things in the notations that aren't in the meta-model, can they?

That's true. All model editors have this problem: data needs to be stored that doesn't belong to the actual model. What geometric information is to graphical editing might be comments or empty lines in text based modelling. These are things that the user should be able to put into the text, but that don't belong in the model.

There can't be a solution. You have to clutter your meta-model with additional attributes for single empty lines, comments, or whatever else you want the user to put into the text. But textual notations are, at least, simple enough to create any of this information for the case there wasn't a user who created it before. Auto-layout in graphical editors is a huge problem. In textual modelling, code can be formatted reasonably. Actually, you want to have most of the layout controlled by the editor and not the user.