The most powerful weapon we have to fight ever-increasing complexity of software and supporting hardware architecture is abstraction. Although powerful, used abstractions are usually computer-, i.e. solution space-oriented, as opposed to being application domain-, i.e. problem space-oriented [15]. Developers still need to perform the mental mapping of concepts found in the solution domain to concepts found in the problem domain and to apply these mappings manually during the course of implementation [7]. By leveraging abstraction and providing adequate Domain-Specific Languages (DSLs), we strive to reduce the semantic gap between these two domains and eliminate the need for mapping between them as the ultimate goal.
DSLs in use today are mostly based on textual or graphical notatation or the mixture of those two (e.g. visual language with OCL2 constraints). One type of concrete syntax is usually supported for the same DSL. In this paper we present some initial observation on the differences between graphical and textual syntaxes and their impact on version control based on our experience in developing both notations for DOMMLite DSL. DOMMLite is a declarative language whose aim is the description of statical properties of database-oriented software applications [3]. It has been designed and implemented using Model-Driven Engineering (MDE). DOMMLite builds on the concepts of other ER-like languages such as UML Class Diagrams [13], Meta-Object Facility (MOF) [12], ECore [4], and concepts expressed in Domain-Driven Design [5].
Textual notation and textual editor for DOMMLite language has been fully developed [3] using openArchitectureware framework 3 . Although both visual notation and visual editor for DOMMLite language are in the early phase of development, we will give some initial findings, based on anecdotal evidence, in favor and against both textual and visual syntaxes and supporting tools.
-Model structure is easier to comprehend. It is a popular belief that the graphical notation is better than the textual. However, it has been reported that in some circumstances graphical notation does not perform better, or even that it performs worse than textual [6,14]. This is usually reported for the languages used for modeling of control or data flow and for languages where "secondary notation" [14](see section 4) has a major impact on model understandability. Nevertheless, for declarative DOMMLite language which is used to express statical properties of the system, based on anecdotal evidence, we are inclined to think that visual notation perform better at comprehension of element relationships and the overall model structure. -Easier model navigation. Using ubiquitous operations pertinent to modern visual editors (like zooming, panning etc.), every part of a DOMMLite model can be visited quickly and with a minimum of effort. -Visual languages are easier to learn. Arguably, this depends on the experience and background of the modeler and the choice of visual and textual representations of language concepts. However, we argue that the learning curve is steeper for visual notations. Presented with the palette of modeling elements, the modeler can almost immediately start placing them on the drawing canvas and connecting them and learn by the means of trial and error. Conversely, with textual syntax, the modeler is presented with an empty file and it is hard to do anything without learning some elements of the language first (i.e. keywords, syntax and semantic rules etc.).
-Hard to develop and maintain. Although building graphical editors is much easier now with the advent of sophisticated tools like GMP4 , DEViL5 Tiger6 and VLDesk7 , the amount of work to develop and maintain a fullfledged graphical editor is still considerable, especially in the environment of evolving languages.
-Serialization format is different from the presentation format. It can be problematic if the need arises to drill down to the serialized representation, which still is the case with current version control systems (see section 3).
-Existing tools can be used as a fall-back option. A plain-text editor can be used to visualize and edit models based on textual notations.
-Existing text-based version control systems can be used. See section 3.
-Programmers are used to textual syntaxes. Most programmers are used to textual syntaxes, so it is easier to introduce text-based modeling to current software development processes and practices.
Arguments against textual notations and editors -Notation verbosity. Textual notation, despite all precaution, can become quite verbose. No part of model can be hidden and visualized at the will of a modeler (with the sole exception of code folding support). -The structure of the model is harder to comprehend. The modeler needs to provide substantial effort to build a mental model of relationships among model elements. In DOMMLite, for example, references to other entities and inheritance hierarchy are not easy to convey from textual notation. -Navigation is not as intuitive as is the case with visual editors. Navigation can be performed by scrolling sequentially through the text, searching for text patterns, listing and jumping to all usages of certain model element (i.e. all references) etc. For DOMMLite generated editor, the only overview is presented in the form of a tree-like code outline which conveys only languagelevel containment structure.
The issue of paramount importance when it comes to team development is version control, i.e. identification, preservation, visualization and merging of model differences. Although there are well established tools and techniques for version control of plain textual artifacts (i.e. source code) [16,9], the version control in the field of model-driven engineering with emphasis on model syntax and semantics is an active field of research [1,2,10].
Traditional text-based systems for version control works at file level and considers content of files as an array of lines of text without trying to utilize language syntax or semantics. Using these tools for version control of models can be troublesome. Even if model are serialized in textual XMI format, it is still unwieldy for a modeler to drop down to the verbose and hardly readable XMI format when trying to do the merge of concurrent changes. Modeling tools are rich in visual hierarchy and graphical representation, which are not found in the linear text files of source code representation [8].
Although models can be serialized to textual (e.g. XML) formats, it is hard to visualize differences and resolve conflicts using this form of representation.
We argue that a carefully crafted textual notation has a positive side-effect of the possibility to utilize existing text-based version control systems until the appropriate model-based tools become available.
For example, figure 1 shows the three-way compare of concurrent changes when a model is serialized using XMI format. The same changes, using DOMM-Lite textual notation are presented in figure 2. It is evident that verbosity of XMI syntax decreases readability of the model and makes conflict resolution of concurrent changes harder in comparison to the DOMMLite textual notation.
Work related to the topics discussed in this paper includes development of a DSL with various notations and research on the impact of using different language notation on performance of the developers and existing tools utilization.
In [3] DOMMLite language is introduced with it's textual syntax, text-based editor and source code generator.
In [14] the author investigates a so called "secondary notation" (lay-outing, clustering, white-spaces, colors) which is a way that practitioners of visual languages use the non-formal features and techniques to specify information and give hints to the reader.
In [6] authors report comparisons between the comprehensibility of textual and visual programs and paradoxically come to a conclusion that the comprehensibility of the graphical notation is worse than textual.
Visual language and environment for specification of attributed grammars (AG) is presented in [11]. The authors conclude that, by using a visual language, the mental gap between the required text-based AG specification imposed by several compiler generator tools and the habitual way of sketching AGs in the form of a decorated tree has been shortened.
Difficulties and problems related to text-based version control of models are presented in [8,1].
Native model-based version control approaches are presented in [1, 2, 10]
There is no definite answer whether textual or graphical syntax is better. There are papers that support either point of view. It is a popular belief that visual languages are easier to understand but, for certain language constructs, it has been empirically proved that comprehensibility can be worse than for textual languages [6]. The graphical notation is also more prone to the "secondary notation" which is not part of the formal system and thus it is left to developers to freely create their own style and ways of encoding additional information and hints. One way to remedy this would be to make elements of "secondary notation" a part of the formal specification.
We have outlined trade-offs between textual and visual notations on the basis of our experience in development of the DOMMLite DSL. If development and maintenance of both syntaxes is not an issue, we suggest using graphical syntax for model overview, navigation and structural changes (e.g. editing relationships) and textual syntax for defining non-structural properties of the model (e.g. for DOMMLite it would be the definition of attribute names and types, constraints etc.). Also, we find that using textual syntax as the canonical serialization format enables utilization of existing, industry proven, text-based version control systems until native model based version control systems mature.
Further research and development will be focused on platforms and tools for supporting development, version control and co-evolution of languages and different concrete syntaxes.