A Textual Domain Specific Languagefor User Interface Modelling

Mart Karu

Abstract User interface development is one of the hardest parts of the softwareapplication development. It could be made more efficient by introducing model-driven development approaches and user interface modelling. This paper intro-duces a textual domain specific language and a corresponding meta-model fordescribing user interaction using abstract UI patterns that can be transformed intomore platform specific UI patterns during application generation. The languagealso follows use case description format and provides possibilities to add free-formdocumenting context to the formal constructs used in the language, making themodels described in the language suitable both for model driven engineering andrequirements elicitation.

1 Introduction

User interface (UI) development is one of the hardest parts of a software devel-opment, especially in a world where the success of a software application can beattributed to the quality and consistency of its UI. Targeting UI development withmodel driven development (MDD) methods can:

• reduce the effort needed to implement and maintain reoccurring UI patterns ingeneral purpose languages, by abstracting out the patterns to the meta-modeland to the corresponding modeling language.

M. Karu (&)Department of Informatics,Tallinn University of Technology, Raja 15,12618 Tallinn, Estoniae-mail: karu@metal.ee

T. Sobh and K. Elleithy (eds.), Emerging Trends in Computing, Informatics,Systems Sciences, and Engineering, Lecture Notes in Electrical Engineering 151,DOI: 10.1007/978-1-4614-3558-7_84, � Springer Science+Business Media New York 2013

985

• raise the quality and consistency of the application UI, by applying codegeneration techniques that will always produce similar implementations of thepatterns across the target application.

The goal of this paper is to introduce an additional language and a corre-sponding meta-model to the existing user interface modelling languages and meta-models, that could raise the quality of the viewpoint taken on a model and on thegeneral domain of UI modelling and model driven UI development.

This paper is organised into six sections. Section 2 explains the other relatedworks in this field and motivation behind the work. Section 3 describes theproposed language and the concept space the language covers. Section 4 will givean exemplifying overview of the language usage. Section 5 discusses the results ofthe work and the final section will conclude the work.

2 Related Work and Motivations

Current modelling languages used in MDD-specific UI modelling can be dividedinto three categories based on the modelling approach:

• UML-based languages and UML Profiles• Graphical Domain Specific modelling languages• Textual Domain Specific modelling languages

The UML-based approaches rely on using standard UML concepts like classand interaction diagrams [1] or specific UML profiles [2] that further restrict thegeneric UML language by applying domain specific constraints. While theapproaches do manage to capture the most essential parts of the UI and there ismature tool support available, the complexity of the UML meta-models and theinflexibility of the standard diagram formats to be tailored to match the domainmake them not the most optimal choice for the MDD in general [3].

Non-UML based graphical languages have the freedom to use the most suitablelanguage representation for UI modelling and there are several works [4–6] thatutilise graphical modelling languages or visual toolsets. While the graphicallanguages are prevailing approaches to the UI modelling and there are clearbenefits of using graphical languages, there are also disadvantages when comparedto textual languages [7].

On the existing textual languages side, there are domain specific languages(DSL) for developing web-based user interfaces like WebDSL [8] attempts todescribe the UI domain using functional languages [9]. Also the UsiXMLapproach [10] can be considered to be based on the textual XML language,although in practice the XML is being generated from the graphical modelling toolfront-ends [11].

Concept-space wise, many model driven approaches employ meta-models thatinclude concepts that are based directly on a specific technical target platform or

986 M. Karu

UI style. For example, in the WebDSL approach the UI aspects are describe byusing idioms and UI elements widely known in the web-based UIs. There areworks that express the importance of using more abstract ways of marking UIconcepts and using intelligent transformations [12, 13] or abstract UI modelling ingeneral [10].

Based on the previous works and the benefits [3] of MDD, it would bereasonable to construct a domain specific textual language that would satisfy thefollowing goals:

• The language needs to present a model as a first class artefact for capturingrequirements of all of the aspects of the user interaction.

• The model described by the language needs to be formal enough to be used inuser interface generation using MDD approaches.

• The language (and the meta-model) should have extension points for integratingthe target model with models that represent other software application domains

• The language should present the user interaction patterns in the abstract form, tofacilitate independence from the user interface technology and the interactionparadigm

• The language should be textual because of the many practical benefits of thetextual languages, like efficient creation and maintenance, efficient usage ofvisual space, language integration possibilities, fast formatting, version controland mature tool support [7].

3 Overview of the Language

The UI description language and the corresponding meta-model described in thispaper operates with the concepts that have a variable nature in the UI domainspace. The language and the meta-model consist of two distinct parts. The first partdescribes the aspects and the granularity of the interaction elements provided tothe system user during each interaction step. The second part of the languagedescribes all of the possible interactions provided by the UI.

The meta-model allows inclusion of other UI model instances by using speciallanguage construct ‘include’ and a corresponding meta-model element Include.

3.1 View-Sets and Interaction Elements

The limitations of human perception require the user interfaces to quantify theamount of information and interaction possibilities that are expressed to the userinterface user. The first goal of the UI description language is to capture the sets orpartitions of the user interface elements that are made available to the system userduring each interaction step.

A Textual Domain Specific Language 987

The interaction elements that are referenced in the language are expressed asabstract patterns that will be transformed into more precise patterns during modeltransformations towards executable software application.

The following list of the most basic abstract patterns is incorporated into thelanguage as an example for this paper:

• Data entry—an ability to enter simple stream of data to the system.• Secure data entry—an ability to securely enter data to the system.• List of selectable items—a list of items where one of the items can be selected

and the corresponding event to be generated.• Event firing—an ability to produce events to be processed by the system.

When an interaction element is placed into the model, the abstract UI pattern itreferences will be instantiated with the provided parameters that will configure thevariable parts of the pattern. For example, adding the keyword ‘‘secure’’ to theregular input element will denote that the inputs presentations in lower abstractionlevels must follow a platform-specific pattern that would guarantee secure entrywhile inputting the data.

The interaction elements are grouped into viewsets by using the keyword‘‘viewset.’’ The Viewset definition and each element can be named and can alsohave two descriptive strings placed after the definition. The first string denotes atitle of the element or the Viewset and the second one gives a description of theobject.

Both strings are useful during transformations—the title string can show thepurpose of the element in the graphical UIs and the description string can betransformed to context-specific help messages accompanying the element.

3.2 Navigation and Interaction

To retain the most common appearance of the requirement artefact, the startingpoint in design of the interaction description part of the UI language has been theclassic use case description format [14]. The use case scenarios are presented asseparated interactions with a reference to a viewset that is being used to carry outthe interaction. The Interactions are contained inside the UseCase container togroup logically related interactions. Each Interaction contains:

• optional freeform textual description or documentation of the interaction• markings inside the freeform text to connect events described in the viewsets

and the next interactions to be initiated after the events.

The references to the viewset’s events are prefixed with the character ‘‘:’’ andreferences to following interactions or usecases with the character ‘‘ [ .’’ Togetherthose markings form an event-to-reaction navigation pair that can be used toconstruct the interaction graph. This syntax enables to describe the navigational

988 M. Karu

graph state-machine in textual form and also provides documentation context tothe use case description. If Interaction names and use case names are chosenappropriately, a clear, readable and yet formal enough textual description of theuser interaction can be specified.

In the meta-model, both UseCase and NavigationRule elements are defined asspecial cases of AbstractInteraction element. It allows the NavigationRuleelements (defined by the event-to-reaction syntax) to reference either otherinteractions or use cases. This allows the navigation targets to be either large scaleuse cases or interactions inside a specific use case. NavigationRules are defined inthe Interaction and the Interaction elements are placed in the UseCase elements.The NavigationRule element also references the EventElement that initiates anavigational change in the UI.

To be usable as a general requirement specification artefact, the other elementsof the use case description format can be added to the language. Although only thesimplest way of marking the use case interactions is presented in this paper, theother conditions and markings available in use case descriptions could be evolvedto be more formal and more tightly integrated with other domain areas, like role-based security or other business domain areas.

3.3 Integration with Other Domains

The UI aspects are rarely isolated from the other aspect models that define asoftware application. The integration with the core business domain models isimplemented by referencing the name of the business domain service to beinvoked as a response to the event. The returned data of the service can be storedin the named slots and can be used in the viewsets that are displayed after theevent. The named slots are stored in the model as the meta-model Mappingelements. The parameters given to the business service can be resolved duringsource code generation by passing the interaction context (the interaction and thecorresponding viewset) object as a parameter.

3.4 Formal Definition of the Language

Based on the examples and features described above, a grammar (displayed inFig. 2) and a corresponding meta-model (displayed in Fig. 1) can be expressed tosupport the language. The grammar definition is expressed using the grammardefinition DSL of the Xtext programming language framework [15]. The meta-model is expressed as an instance of the Ecore meta-meta-model [16].

A Textual Domain Specific Language 989

3.5 Integrating with Model Driven Methodologies

The abstraction level of the language and of the corresponding meta-modelenables platform independence from the user interface technology and interactionparadigm. The model can be transformed into both graphical UIs and conversa-tional UIs, like voice based or command-line interfaces. Since the communica-tional UIs are based on few simple interface patterns like detecting or parsingspeech or text and responding with speech or text, the abstract patterns defined inthe UI model can be implemented by combining the simple UI patterns supportedby the conversational UI platform.

The model described by the language can be used in custom-made transfor-mations or can be applied to other user interface transformation approaches. Touse the model with other approaches, a model-to-model transformation is neededto transform the model concepts into the concept space of the target meta-model.

Since the model relies on abstract patterns, the abstract patterns must betransformed into platform specific patterns during model transformations. TheFig. 3 shows some possible transformation paths from the UI model to morereified platform specific models.

4 Example Usage

One of the most widely used large scale UI patterns is a simple resourcemanagement pattern that includes showing a list of items of interest and means toedit, remove and delete the items. The example displayed in the Fig. 4 shows a

Fig. 1 Meta-model supported by the language

990 M. Karu

implementation of the pattern in the form of a basic phonebook application. Theexample displays:

• Two use cases (MainMenu and ManagePhonebook) that contain interactiondescriptions.

• Descriptions of three viewsets (MainMenu, PhoneBook and EditPhoneBook-Entry) and the interaction patterns (inputs, events) used in the viewset.

Fig. 2 Language grammardefinition

A Textual Domain Specific Language 991

The textual descriptions of the interactions contain event-to-reaction pairs. Forexample, the :open_phonebook event initiates a business service getpersons andstores the result in the slot named people.

Figure 5 displays a fully functional web-based application UI that was trans-formed from the model described in the example.

5 Disussion

The language and the corresponding meta-model are the results of the iterativeprototyping work using the Xtext language development framework [15]. The pro-totyping work also included a development of model-to-model and model-to-codetransformation rules that were used to generate working implementations of the UIson different technological and UI platforms. The target implementations used in theprototype were:

• Graphical web-based UI implemented in the Ruby language [17] and on theRuby on Rails framework [18].

• Graphical desktop-based UI implemented on the Java Swing framework [19].• Text-based conversational UI implemented in the Python language [20].• Voice-based conversational UI implemented in the C# language [21] using the

Microsoft Speech voice recognition and synthesis API [22].

The generated target implementations were used as a feedback for verifying theusability and suitability of the language and the meta-model. It also helped to unifythe concepts of target platforms as the abstract concepts in the meta-model.

The iterative process of improving the work results has proved the meta-modeland the language to be sufficient enough for the narrow context of supporting the

User Interface Model

Graphical User Interface Model

Conversational User Interface

Model

Web-Based UI Model

Desktop UI Model

UsiXML Abstract UI Model

transformation transformation

transformation transformation

WebDSL Model

trasnformation

transformation

Fig. 3 Model transformationpaths

992 M. Karu

Fig. 4 Example usage of theUI DSL language

A Textual Domain Specific Language 993

code generation of the selected target platform UIs. More thorough assessment ofthe quality and usability of the language must be measured, based on either of thecomparison of other similar languages or the fundamental principles and bestpractices of language design.

Based on the principles described in [23], the language and the meta-modeldescribed in this paper can be evaluated using the following quality aspects:

• Simplicity: The proposed UI language and the meta-model provide narrowlyfocused and minimal concepts for describing UIs. Accidental complexity byadding confusing language elements has been avoided.

• Uniqueness: The meta-model consists of unique elements that do not overlapconceptually.

• Consistency: The proposed language lets to connect the meta-model conceptinstances and the instantiated models contain the formal description of the UIs.All the language elements support the initial language development goals.

• Seamlessness: The abstractions provided by the language can be used repeat-edly throughout the development process and the resulting models can be usedto generate working software implementations.

• Reversibility: Reverse-engineering the generated models or the source codeback to the UI models is orthogonal to the language and meta-model describedin this paper. Any reverse-engineering tool capable of detecting the requiredabstractions could output the collected knowledge as a textual UI model, usingthe proposed textual language.

• Scalability: The language can be used to describe both large and small systems,by separating the model descriptions into different text files.

• Supportability: The proposed language can be used both as the requirementartefact for human use and as a model for generating UI implementations.

Fig. 5 Web-basedapplication generated fromthe example model

994 M. Karu

• Reliability: The language facilitates pattern-based software generation, that willalways produce similar (and tested) source code footprints for a specific patternor a model concept.

• Space economy: Using the language without textual interaction descriptioncontexts could result in very concise textual representations. As the amount ofthe textual documentation included in the descriptions increases, the spaceneeded to visualise the model also increases.

6 Conclusion

A textual domain specific language has been described in this paper that can beused to define aspects of human-computer interaction. The resulting models andtheir presentations could be used as generic artefacts for documenting softwarerequirements and also as formal models for UI generation. The concept space ofUI aspects used in the meta-model consist of the abstract UI patterns that can beinstantiated and configured in the UI models. The described models can be used asinputs to various MDD scenarios and approaches that transform the abstractpatterns into more platform specific UI patterns in intermediate models and later inthe process into working UI implementations.

The example UI patterns in this paper cover only the most basic UI patterns anddomain integration possibilities. Also having a language defined based on the usecase format is just one possibility to expose the UI interaction model in a domainspecific language. The goals for the further work are the following:

• Improving the language to support more complex integration scenarios byproviding more integration extension points to the language.

• Mapping patterns and pattern transformations on various platforms so that moreabstract patterns could be expressed in the language

• Provide a formalisation approach of similar text-based state-machine descrip-tions in agile user stories and scenarios, especially in the test automation toolsthat support Behaviour Driven Development [24].

• Provide more through language quality evaluation based on the good modellinglanguage principles and evaluation approaches.

• Compare the proposed language with other languages expressing similarconcepts.

• Test the language and the meta-model in real-life development scenarios.

Acknowledgments This research was supported by the Estonian Doctoral School in Informationand Communication Technology.

A Textual Domain Specific Language 995

References

1. da Silva PP, Paton NW (2000) User interface modelling with UML. In: Informationmodelling and knowledge bases, vol XII. IOS Press, Amsterdam, pp 203–217

2. Koch N, Kraus A (2002) The expressive power of UML-based web engineering. In Secondinternational workshop on web-oriented software technology (IWWOST02), CYTED,pp105–119

3. Kelly S, Tolvanen JP (2008) Domain-specific modeling: enabling full code generation.Wiley, New Jersey

4. Trætteberg H (2001) Model-based user interface design. PhD thesis, Norwegian University ofScience and Technology, Trondheim, Norway

5. Ceri S, Fraternali P, Bongio A (2000) Web modeling language (webML): a modelinglanguage for designing web sites. In: Proceedings of the 9th international World Wide Webconference. Elsevier, Amsterdam, pp137–157

6. Goderis S, Deridder D (2004) A declarative DSL approach to UI specification—making UI’sprogramming language independent

7. Grönniger H, Krahn H, Rumpe B, Schindler M, Völkel S (2007) Textbased modeling. In:Proceedings of the 4th international workshop on software language engineering

8. Visser E, Benaissa ZEA, Tolmach A (1998) Building program optimizers with rewritingstrategies. In: Proceedings of the 3rd ACM SIGPLAN international conference on functionalprogramming (ICFP’98), 13–26. ACM Press, September 1998

9. Plasmeijer R, Jansen JM, Koopman P, Achten P (2009) Using a functional language asembedding modeling language for web-based workflow applications. In: Tenth symposiumon trends in functional programming, 2009

10. Limbourg Q, Vanderdonckt J (2004) UsiXML: a user interface description languagesupporting multiple levels of independence. In: Engineering advanced web applications, 2004

11. Vanderdonckt J (2005) A MDA-compliant environment for developing user interfaces ofinformation systems. In: Proceedings of 17th conference on advanced information systemsengineering CAiSE’05. Lecturer notes in computer science, vol 3520. Springer, Berlin, pp13–17

12. Borchers JO (2000) A pattern approach to interaction design. In: Proceedings of theconference on designing interactive systems (DIS ’00). ACM, New York, pp 369–378

13. Ahmed S, Ashraf G (2007) Model-based user interface engineering with design patterns.J Syst Softw 80:1408–1422

14. Cockburn A (2010) Basic use case template. http://ac.cockburn.us/1617. Accessed 21 April2010

15. Efftinge S, Völter M (2006) oAW xText: a framework for textual DSLs. Workshop onmodelling symposium at Eclipsecon Summit Europe, 2006

16. Eclipse modeling project. http://www.eclipse.org/home/categories/index.php?category=modeling. Accessed 20 April 2010

17. Ruby programming language. http://www.ruby-lang.org/. Accessed 20 Novemb 201018. Ruby on rails. http://rubyonrails.org/. Accessed 20 Novemb 201019. javax.swing (java 2 platform). http://download.oracle.com/javase/1.4.2/docs/api/javax/swing/

package-summary.html. Accessed 20 Novemb 201020. Python programming language—official website. http://www.python.org. Accessed 20

Novemb 201021. C# language specification. http://msdn.microsoft.com/en-us/library/aa645596(VS.71).aspx.

Accessed 20 Novemb 201022. Microsoft speech api. http://msdn.microsoft.com/en-us/library/ms723627(VS.85).aspx.

Accessed 20 Novemb 201023. Paige RF, Ostroff JS, Brooke PJ (2000) Principles for modeling language design. Inf Softw

Technol 42(10):665–67524. Astels D (2005) A new look at test driven development. http://blog.daveastels.com/2005/07/

05/a-new-look-at-test-driven-development. Accessed 20 April 2010

996 M. Karu