Embed Size (px)
Citation preview
DEPARTMENT OF INFORMATICSTECHNISCHE UNIVERSITÄT MÜNCHEN
Master’s Thesis in Informatics
A Model-Driven JSON Editor
Lucas Daniel Köhler
DEPARTMENT OF INFORMATICSTECHNISCHE UNIVERSITÄT MÜNCHEN
Master’s Thesis in Informatics
A Model-Driven JSON Editor
Ein Modell-basierter JSON Editor
Author: Lucas Daniel KöhlerSupervisor: Prof. Dr. Florian MatthesAdvisors: Adrian Hernandez-Mendez, Dr. Jonas HelmingSubmission Date: 15.10.2017
I confirm that this master’s thesis is my own work and I have documented all sourcesand material used.
Munich, 15.10.2017 Lucas Daniel Köhler
Acknowledgments
I want to thank my advisors Adrian Hernandez-Mendez and Dr. Jonas Helming fortheir ongoing support and advice during the whole process of writing my master’sthesis.I also want to thank Prof. Dr. Florian Matthes for the opportunity to write this thesis athis chair Software Engineering for Business Information Systems (SEBIS).I want to thank Eugen Neufeld for his guidance during the implementation phase ofthis thesis.Lastly I want to thank my family and all my friends who always supported me.
Abstract
Many engineering domains require the input and modification of structured data (alsoknown as models). This structured data is usually defined by a meta-model (e.g. inJSON Schema). To modify instances of structured data, users require proper tooling. Themanual implementation of suitable tooling is costly, leads to re-implementing commonfeatures, and causes additional development effort whenever the meta-model changes.
In this thesis, we develop a model-driven framework to semi-automatically createan editor for a given meta-model. This editor allows the creation and modification ofstructured data as specified by the meta-model. The goal is to minimize the manualwork required to create and maintain such an editor.
As a preparation, we conduct an extensive analysis of the requirements of structureddata tools. First, we conduct a literature review on multilevel modeling tool requirements.Second, we complement the results with requirements gathered by a tool analysis ofnine data editors. Based on this, we design and implement the model-driven editorframework. Thereby, we focus on allowing to create an editor with minimal effort whilesimultaneously providing extensive options to customize and extend the generatededitors.
We evaluate our framework by configuring and creating three editors for the existingmeta-models Ecore, JSON Schema, and UI Schema. Finally, we successfully evaluate theusability of editors created by our framework by conducting a System Usability Scaletest for the UI Schema Editor. It achieves a score of 79.5 out of 100 points.
vii
Zusammenfassung
Viele Bereiche der Ingenieurswissenschaften erfordern die Eingabe und Modifikationvon strukturierten Daten (auch bekannt als Modelle). Strukturierte Daten sind meistensdurch ein Meta-Modell definiert (z.B. ein JSON Schema). Um Instanzen dieser strukturi-erten Daten zu bearbeiten, benötigen Anwender geeignete Werkzeuge. Die manuelleImplementierung dieser Werkzeuge verursacht hohe Kosten, führt zur Wiederentwick-lung gemeinsamer Funktionalität und verursacht zusätzlichen Entwicklungsaufwandbei jeder Änderung des Meta-Modells.
In dieser Arbeit entwickeln wir ein modell-basiertes Framework zur halbautoma-tischen Erzeugung eines Editors für ein gegebenes Meta-Modell. Dieser Editor er-möglicht die Erzeugung und Bearbeitung von strukturierten Daten, die durch dasMeta-Modell spezifiziert sind. Das Ziel ist die Minimierung des manuellen Aufwandes,der zur Erzeugung und Wartung eines solchen Editors benötigt wird.
Als Vorbereitung führen wir eine umfangreiche Anforderungsanalyse von Program-men für strukturierte Daten durch. Zuerst führen wir eine Literaturrecherche zuAnforderungen von Multilevel Modellierungsprogrammen durch. Wir ergänzen dieErgebnisse mit Anforderungen, die wir durch eine Analyse von neun Dateneditorenermitteln. Auf dieser Basis entwerfen und implementieren wir das modell-basierteEditor-Framework. Hierbei achten wir besonders darauf, dass Editoren mit minimalemAufwand erzeugt werden können und trotzdem umfangreiche Möglichkeiten zur An-passung und Erweiterung bieten.
Wir evaluieren unser Framework, indem wir drei Editoren für die existierenden Meta-Modelle Ecore, JSON Schema und UI Schema erzeugen und konfigurieren. Abschließendevaluieren wir erfolgreich die Benutzerfreundlichkeit von Editoren, die mit unseremFramework erzeugt wurden, indem wir einen System Usability Scale Test mit dem UISchema Editor durchführen. Er erzielt ein Ergebnis von 79,5 von 100 Punkten.
ix
Contents
Acknowledgments v
Abstract vii
Zusammenfassung ix
1. Introduction 1
2. State of the Art 52.1. Editor Generation Framework Approach . . . . . . . . . . . . . . . . . . . 52.2. Literature Review on Requirements of Multilevel Modeling Tools . . . . . 5
2.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.2. Scope and Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.3. Search Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.4. Literature Analysis and Synthesis . . . . . . . . . . . . . . . . . . . 15
2.3. Tool Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3.1. Analyzed Editors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3.2. Tool Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3. Requirements 353.1. Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2. Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.1. Must Have . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.2.2. Desirable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.2.3. Nice To Have . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3. Implementation Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.4. Quality Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4. Implementation 434.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2. Editor Renderer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.3. Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.4. JsonForms 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4.1. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.4.2. Rendering Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.5. Tree Renderer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.5.1. Drag and Drop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
xi
Contents
4.6. Detail Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.7. Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.7.1. Retrieve Containment Properties . . . . . . . . . . . . . . . . . . . . 584.7.2. Self Contain a Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 624.7.3. Reference Resolving in Schemata . . . . . . . . . . . . . . . . . . . . 63
4.8. Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.9. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.9.1. Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.9.2. Resource Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.9.3. ID-based References . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.9.4. Path-based References . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.10. Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.10.1. Image Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.10.2. Label Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.10.3. Model Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.10.4. UI Schemata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.10.5. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.10.6. Configuration Object . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.11. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5. Evaluation 815.1. Evaluation Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.1.1. Ecore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.1.2. Json Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.1.3. UI Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.2. Editor Customization Process . . . . . . . . . . . . . . . . . . . . . . . . . . 825.2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.2.2. Ecore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.2.3. UI Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.2.4. JSON Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.3. Advantages and Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.3.1. Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.3.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.4. Usability Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905.4.1. Evaluation Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 905.4.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.5. Comparison to a Specific Editor . . . . . . . . . . . . . . . . . . . . . . . . . 93
6. Conclusion and Future Work 95
List of Figures 99
List of Listings 101
xii
Contents
List of Tables 103
Bibliography 105
Appendix A. Literature Review 113A.1. Search Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
A.1.1. Deep Meta-Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . 113A.1.2. Domain-Specific Modelling Language . . . . . . . . . . . . . . . . . 114A.1.3. Language Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . 114A.1.4. Multi-Level Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . 115
A.2. Excluded Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116A.2.1. Deep Meta-Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . 116A.2.2. Domain-Specific Modelling . . . . . . . . . . . . . . . . . . . . . . . 116A.2.3. Language Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . 116A.2.4. Multi-Level Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Appendix B. Evaluation of the UI Schema Editor 119B.1. Evaluation Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119B.2. System Usability Scale Items . . . . . . . . . . . . . . . . . . . . . . . . . . 119B.3. UI Schema Editor Missing Features . . . . . . . . . . . . . . . . . . . . . . 120B.4. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
B.4.1. Which Editor Did You Prefer and Why? . . . . . . . . . . . . . . . 121B.4.2. What Are the Advantages of the Json Forms Editor? . . . . . . . . 121B.4.3. What Are the Advantages of the UI Schema Editor? . . . . . . . . 121
Appendix C. Repositories 123
xiii
1. Introduction
Many engineering domains require the input, creation, modification, and export ofstructured data. Prevalent examples in the software engineering domain are UMLand the Package JSON for Node modules1. Another example from the engineeringdomain is the automotive standard AUTOSAR2. Structured data is usually defined bya meta-model. Well-known examples for such meta-models are JSON Schema3, theseveral schemata languages to define XML schemata4, and the Ecore language of theEclipse Modeling Framework5.
Manually creating and modifying structured data by hand is error-prone, cumbersomeand lacks validation of the defined data. For instance, when defining a reference betweentwo elements, the user cannot know whether it specifies a valid target. Also, looking atdata with cascaded hierarchies without proper tooling gets confusing rather quickly. Asa consequence, specific tooling for modifying structured data is needed. We observethree main types of editors, depending on the use case: text-based editors (e.g. Xtext6),graphical editors (e.g. Enterprise Architect7 for UML), and form-based editors (e.g.Ecore tooling in EMF8). In this thesis, we focus on form-based editors.
The manual implementation of such an editor for every meta-model has severaldrawbacks. (1) Developing a professional editor has high development costs. (2) Changesto the meta-model cause additional costs because the editor has to be adapted manually.(3) Having multiple editors leads to code duplication for common functionality. Forinstance, functionality such as import and export, data validation, type-sensitive editing,or data binding between view and data is needed in most editors.
Consequently, there are frameworks to generate editors for a given meta-model. Thoseare based on desktop technologies, e.g. EMF and EMF Forms9. However, to the best ofour knowledge, no comparable framework exists for a form-based editor based on webtechnologies.
Therefore, it is desirable to have such an editor generation framework for usage inweb applications. In present times, a multitude of devices and operating systems areused to access data. For instance, personal computers operating Windows, Mac OS,
1https://docs.npmjs.com/files/package.json2https://www.autosar.org/3http://json-schema.org/4https://www.w3.org/standards/xml/schema5https://eclipse.org/modeling/emf/6https://www.eclipse.org/Xtext/7http://www.sparxsystems.com/products/ea/8https://eclipse.org/modeling/emf/9https://www.eclipse.org/ecp/emfforms/
1
1. Introduction
or Linux. Phones and tablets mostly operating iOS or Android are widespread, too.Implementing software as a web application allows it to potentially run on all thesedevices as it simply runs in a web browser. Compared to developing multiple nativeapplications, this saves time and developing costs. Especially in the context of mobileapplications, this prevents needing various native technologies [14, 57] and offers “fastdevelopment, simple maintenance, and full application portability” [57]. Thereby, mobileweb apps do not have major drawbacks compared to native apps as long as no nativehardware (e.g. GPS) of the device is used [40]. Another advantage of having such aneditor framework implemented in web technologies is the increased development ofweb-based IDEs like Eclipse CHE10 and Theia11 or the Electron-based Atom12. Usingcompatible technologies, the editor framework can then be integrated into these IDEsfor software engineering use cases.
As we can see, there is a need for the generation of web-based editors for structureddata. Therefore, we propose the development of a model-driven editor frameworkwhich allows editing of structured data based on a given meta-model. The frameworkmust be applicable to very different meta-models in order to allow creating editorsfor the various use cases involving structured data. Therefore, the framework shouldprovide extensive configuration and extension possibilities to allow using it for varioususe cases. At the same time, the configuration effort to get the editor running for agiven meta-model should be as low as possible. Due to JSON’s popularity [7, 66] andefficiency [52, 65] we base our framework on JSON Schema13 which allows specifyingJSON data.
To address these challenges and ensure developing a well-founded and relevantframework, we need a scientifically proven design process. Therefore, we base ourapproach on the three cycles of design science research [36]. Figure 1.1 shows theadaption of the approach to this thesis. Thereby, the information exchange betweenEnvironment and Design Science Research is the Relevance Cycle. Correspondingly, theRigor Cycle connects the Design Science Research and the Knowledge Base. The DesignCycle is the feedback and refinement loop inside the Design Science Research.
Before we can design and build the editor framework in the Design Cycle, we mustdetermine what exactly we want to build. From this follows the first research question:
RQ–1: What are the requirements of the model-driven JSON editor?
We analyze the editor’s requirements from two angles: Rigor and Relevance. Toinvestigate the existing scientific knowledge base in adherence to the Rigor Cycle, weconduct an extensive literature review in section 2.2. This provides us with a widearray of concepts and requirements determined in past research. As a first part of theRelevance Cycle, we analyze nine tools for the creation of structured data in section 2.3.This provides us with concrete requirements from the application domain. Together, the
10https://www.eclipse.org/che/11https://github.com/theia-ide/theia12https://atom.io/13http://json-schema.org/
2
Application Domain
- Industry Experts in Structured Data- Modeling Experts- Developers Creating Data Editors - Existing Structured Data Tools
Build & Design
- JSON Editor Framework
Concepts /Foundations
- Deep Meta-Modeling- DSMLs- Language Workbench - Multi-Level Modeling
Evaluate
- Instantiate Editors- Usability Test
Environment Knowledge BaseDesign Science Research
Requirements
IndustryNeeds
Requirements
ConceptsRefineFeedback
Thesis ResultsSoftware Artifacts
Figure 1.1.: The Design Science Approach of this Thesis. Source: Own diagram createdafter [36].
two analysis give us a broad base of potential requirements for the editor framework.Based on these results, we answer the second research question:
RQ–2: What are the editor’s architecture and design?
This includes selecting the relevant requirements, defining the architecture and design,and implementing the framework. As a second step in the Relevance Cycle, we determineand prioritize our editor framework’s requirements by conducting an interview withindustry experts in the application domain of structured data. The results are describedin chapter 3. Based on these, we can define the framework’s architecture, design, andimplementation details as the first part of the Design Cycle in chapter 4. As a secondpart of the Design Cycle, we need to evaluate our implementation. This leads us to thefinal research question:
RQ–3: What are the limitations of the editor to generate modern web forms?
Therefore, we evaluate our implemented editor framework in two ways. First, weinstantiate editors for meta-models defining Ecore, JSON Schema, and UI Schema.Second, we conduct a usability test of the created UI Schema editor. Both is described inchapter 5.
As a final step of the Rigor Cycle, the created artifacts and gained experience iscontributed back to the scientific knowledge base in form of this thesis. Furthermore, theimplemented software is contributed back to the environment as open-source software.Finally, a conclusion of the achieved results, as well as starting points for further research,are presented in chapter 6.
3
2. State of the Art
In this chapter, we analyze the current state of the art in modeling tools. Therefore, wefirst give a short introduction to the approach of an editor generation framework insection 2.1. Subsequently, we gather a comprehensive collection of requirements. Thiscollection will be the foundation for the prioritization of the model-driven JSON editor’srequirements. Therefore, we analyze the existing requirements from two perspectives:academically and industry focused. To get a well-founded overview over the past andcurrent views in academia, we conduct an extensive literature review in section 2.2. Asrequirements and concepts in literature are often described on a more abstract level, wealso analyze the implemented requirements of nine model editors in section 2.3. Byrelating the practical requirements to the ones found in the literature review, we getmore concrete implementation requirements for part of the concepts determined in theliterature review.
2.1. Editor Generation Framework Approach
In this section, we introduce the concept of a model-driven editor generation framework.Such a framework allows to semi-automatically generate an editor for a given data modelby additionally providing a view model which defines the editor’s user interface. Thisapproach is illustrated in Figure 2.1. The data model defines the legal data which will becreatable with the generated editor. Thereby, the data model defines the data’s structureas well as the properties that the created data objects may contain. The view modeldefines how data objects of a corresponding data model are rendered. For instance, thiscan include editable properties or the definition of labels or icons for objects. Thereby,the view model references the elements of the data model which it configures. As aconsequence, the view model is only valid for its corresponding data model.
2.2. Literature Review on Requirements of MultilevelModeling Tools
In this section, we describe the conducted process and the results of our literature reviewabout the requirements of multilevel modeling tools.
5
2. State of the Art
EditorGenerationFramework
DataModel
ViewModel
Editor
Figure 2.1.: The Editor Generation Approach.
2.2.1. Introduction
To implement a model-driven editor framework that allows the semi-automatic creationof an editor, we need to determine the requirements of a model-driven editor.
In this context, model-driven means that the concepts instantiable in an editor createdwith the framework are defined by its underlying model. Hence, this model is themeta-model defining the modeling language supported by the editor [3]. As a modelgenerally abstracts the concepts of a domain [30, p. 4] and a domain-specific modelinglanguage (DSML) is described by a meta-model [45, p. 1], the editor allows to createinstances of a DSML. Furthermore, the editor could be used to define new DSMLs bychoosing a metameta-model whose concepts are instantiable to a new meta-model [3].This suggests searching for requirements of a DSML tool.
As pointed out in [45, 48], one typical meta-modeling standard is the Meta-ObjectFacility (MOF)14. The Object Management Group suggests it as the meta-modelingtechnique for Model-Driven Architecture [58]. Furthermore, it is implemented by thewell-known Eclipse Modeling Framework15. These two approaches are limited to twoneighboring meta-modeling levels where the higher level is the meta-model and thelower one the instance [45, 48]. This results in the problem that language designersoften have to express multi-layer concepts in one meta-model [48, p. 2], e.g. by defining“type-instance relations in the metamodel” [45, p. 2].
Furthermore, there exists a fundamental design conflict when defining DSMLs in onemeta-layer. On the one hand, the more specific a DSML is tailored to a domain, thebetter the support for suitable use cases. But on the other hand, less specific DSMLsprovide better reusability. This makes it hard to determine the appropriate level ofspecificness for a DSML [28, pp. 2-3].
The aforementioned problems can be solved by allowing an arbitrary number of meta-modeling levels. Thereby, every model is automatically a meta-model for the next lowerlevel [28, 45, 48]. This approach is called multilevel modeling [28]. Further advantagesof multilevel modeling include lower model complexity, easier to use DSMLs, improved
14http://www.omg.org/spec/MOF/2.0/15https://eclipse.org/modeling/emf/
6
2.2. Literature Review on Requirements of Multilevel Modeling Tools
integration [28], improved separation of concerns, and simplified administration ofstandards [38].
This leads us to set the topic of this literature review to the analysis of requirements ofmultilevel modeling tools. Our contribution will be an overview over the requirementsand features of multilevel modeling tools.
To get comprehensible and reproducible results, our research process takes its bearingon the processes defined by Webster and Watson in [88] and vom Brocke et al. in [11].An overview over our resulting approach is shown in Figure 2.2. First, we determinethe search concepts and the scope of the search in subsection 2.2.2. Subsequently, weuse this as the starting point for our iteratively conducted, database-driven processof searching for relevant references in subsection 2.2.3. Afterwards, we analyze theresulting literature to extract 104 requirements and aggregate them into 16 categories insubsection 2.2.4.
2.2.2. Scope and Concepts
In this section, we describe the scope of our research, explain which concepts areincluded in the search, and elaborate why these concepts are relevant in our scope.
The scope of our review is the investigation of requirements for multilevel modelingtools. Because not all relevant literature explicitly talks about multilevel modeling tools,we need to define synonyms and related terms. This is divided into two parts. First, wedetermine the concepts related to multilevel modeling. Second, we establish synonymterms for “tool” in our research context.
2.2.2.1. Research of Related Concepts
From our research experience, we know that Frank [28] provides a relevant definitionof multilevel modeling and describes requirements for multilevel modeling tools. Fur-thermore, we investigate Fowler’s essential article [26] providing the basis for today’sunderstanding of language workbenches. The concept of language workbenches isrelevant to our research because both multilevel modeling tools and language work-benches are about efficiently defining and using domain-specific languages [26, 28].Because Frank [28] introduces multilevel modeling as an improved technique for thedevelopment and usage of DSMLs, we also consider this concept in our initial researchto get an overview of relevant concepts.
The iterative usage of Google, Google Scholar, and the analysis of backward referencesin researched literature led to the relevant search concepts described in the followingsection.
2.2.2.2. Relevant Search Concepts
Multilevel modeling. Multilevel modeling is an approach for the specification ofDSMLs which allows any number of modeling levels and every model can be used as a
7
2. State of the Art
SearchConcepts
ScopusIterative Search
Scope
requirement extraction
requirement categorization
identification of relevant articles
16 relevant articles
104 requirements
16 categories
Figure 2.2.: Overview over the Literature Review’s Research Process
8
2.2. Literature Review on Requirements of Multilevel Modeling Tools
meta-model for the next lower level [28, 45].
Deep meta-modeling. Deep meta-modeling is used as a name for the same conceptsas the aforementioned multilevel modeling [45, 48] and even declared as a synonym [38,69]. Consequently, we need to search for literature about deep meta-modeling to notmiss it in case it does not label itself as multilevel modeling, too.
Language workbench. The term language workbench was coined by Martin Fowler[26] in 2005. It allows users to define new domain-specific languages (DSLs) and integratethem with each other. Thereby, a DSL is defined as a trio of editor(s), generator(s),and a schema [26]. Lamo et al. [45] describe this as “an IDE-like environment forcreating DSML/DSLs” [45, p. 2] which is used to develop DSMLs and correspondingtools as well as working with the created DSMLs. Thus, we need to consider languageworkbenches in our research.
Domain-specific modeling language (DSML). The aforementioned concepts all havein common that they are used to define and use DSMLs. The editor for designing onelayer of a multilevel DSML in a tool is comparable to the editor for designing a DSMLin a two-layer architecture. Multileveled-ness can then be achieved by re-instantiatingthe editor for the next lower level with the designed DSML as its meta-model [28].Consequently, we consider the requirements of DSML tools in our research.
Relevant synonyms of “tool” in our context. Literature uses multiple different wordsto essentially describe tools for the aforementioned concepts. The relevant synonymswe discovered are “editor” [21, 44], “framework” [48, 59], “ide” [17, 45, 80], and “tool”[21, 25, 28, 44, 45].
2.2.3. Search Process
In this section, we describe the search process to get relevant literature for our review.All searches are conducted with Elsevier’s Scopus16, the self-proclaimed “largest abstractand citation database of peer-reviewed literature”.
Figure 2.3 shows the conducted search process. First, we define query limitationswhich apply to the searches of all four search concepts in section 2.2.3.1. Next, weperform separate searches for every search concept. Thereby, we iteratively limit thequeries and filter the resulting references by analyzing their abstracts and keywordsin section 2.2.2.2. The result is four sets of references related to our topic. We mergethese sets into one by removing duplicates, add one more reference, and determine therelevant references by reading them in section 2.2.3.3.
16https://www.elsevier.com/solutions/scopus
9
2. State of the Art
DeepMeta-
Modelling
Iterative Search
DSML
Iterative Search
LanguageWorkbench
Iterative Search
Multi-LevelModelling
Iterative Search
Concept IndependentQuery Limitations
Merge
filter by abstractand keywords
read references and determine relevant ones
17 relevant references
additionalreference
Figure 2.3.: Literature Review Search Process.
10
2.2. Literature Review on Requirements of Multilevel Modeling Tools
2.2.3.1. Concept Independent Query Limitations
This section describes properties of all queries used with Scopus to find relevantliterature. In the description of the concept-specific queries, these parts are automaticallypart of every query without being mentioned again.
Modeling spelling. In our context, modeling can either be spelled with two ‘l’, e.g.in [2, 30, 38, 48], or one ‘l’, like in e.g. [28, 59]. Therefore, both spellings have to beconsidered when querying databases for literature. This is done by substituting eitherspelling with an OR combination of both spellings.
Keyword Search Fields. All required or excluded phrases are searched for in theabstract title, the abstract, the author keywords, or index keywords of the searchedliterature.
Tool Synonyms. Every query requires one or more of the four tool synonyms (editor,framework, ide, tool) to be present.
Limitations. All queries are limited to literature from the subject area “ComputerScience” and article language English.
Search period. All searches were conducted between the 25.05.2017 and 30.05.2017.Consequently, literature added to Scopus after the 30.05.2017 is not considered in ourreview.
2.2.3.2. Query Limitation Process
In this section, we describe the queries and their limitation processes for the fourconcepts determined in section 2.2.2.2. Thereby, every query extends the foregoingone. This means all restrictions of the foregoing query also apply. The restrictionsdescribed in section 2.2.3.1 are implicitly applied to every query. An overview of thequery limitation process is shown in Table 2.1. The table shows the number of resultingreferences for every iteration and links to the corresponding query respectively theexcluded areas for the last iteration of every search concept. The details of the processare described below.
Deep Meta-Modeling
All deep meta-modeling queries use four alternative spellings of meta-modeling: meta-modelling, meta-modeling, metamodelling, and metamodeling.
The first query (see the query in Listing A.1) requires the keywords deep and one ofthe meta-modeling spellings. This results in 27 hits.
11
2. State of the Art
Table 2.1.: Summary of the Query Limitation Process
Iteration Hits Query / Areas Comment
Deep Meta-Modelling1 27 Listing A.1 Initial query2 24 Listing A.2 Exclude conference proceedings3 20 Listing A.3 Exclude keywords4 14 Appendix A.2.1 Exclude irrelevant areas
Domain-Specific Modelling Language1 217 Listing A.4 Initial query2 195 Listing A.5 Exclude conference proceedings3 137 Listing A.6 Exclude keywords4 54 Listing A.7 Stricter query matching5 27 Appendix A.2.2 Exclude irrelevant areas
Language Workbench1 34 Listing A.8 Initial query2 21 Listing A.9 Exclude older than 20053 13 Appendix A.2.3 Exclude irrelevant areas
Multi-Level Modelling1 75 Listing A.10 Initial query2 66 Listing A.11 Exclude older than 20013 55 Listing A.12 Exclude conference proceedings4 42 Listing A.13 Exclude keywords5 14 Appendix A.2.4 Exclude irrelevant areas
12
2.2. Literature Review on Requirements of Multilevel Modeling Tools
Next (see the query in Listing A.2), we filter out all conference proceedings, or inScopus called conference review, because they do not contain a single paper but simplyare the collection of all papers of a conference. This results in 24 hits.
Next (see the query in Listing A.3), we filter out all results matching one or more ofthe following keywords as these indicate that the literature is not related to our topic:"deep drawing", "analog circuits", biosensors, "neural network". This results in 20 hits.
Next, we analyze the abstract, author keywords, and index keywords to filter outliterature which focuses on another area than our research. This leaves us with 14 hits.The excluded areas are listed in appendix A.2.1.
Domain-Specific Modeling Language
The initial query (see the query in Listing A.4) requires the keywords domain-specific,modeling, and language. This results in 217 hits.
Next (see the query in Listing A.5), we filter out all conference proceedings, or inScopus called conference review, because they do not contain a single paper but simplyare the collection of all papers of a conference. This leaves us with 195 hits.
Next (see the query in Listing A.6), we filter out all results matching one or more ofthe following keywords as these indicate that the literature is not related to our topic:internet of things, medicine, medical, "assisted living", VHDL, "artificial intelligence",multi-agent, multiagent, autocrud, "cyber-physical systems", "embedded systems". Thisresults in 137 hits.
In the next query (see the query in Listing A.7), we make the keyword matching morestrict. The keyword “domain-specific” now has to precede the keyword “modeling”within two words. Furthermore, we also allow the keyword “languages” in additionto “language” in case literature only talks in plural about domain-specific modelinglanguages. Instead of only matching the query-part for domain-specific modelinglanguage, we allow matching the shortcuts DSML and DSMLs instead. This results in54 hits.
Next, we analyze the abstract, author keywords, and index keywords to filter outliterature which focuses on another area than our research. This leaves us with 27 hits.The excluded areas are listed in appendix A.2.2.
Language Workbenches
The initial query (see the query in Listing A.8) requires the keyword language workbenchand the keyword requirements. This results in 34 hits.
In the next query (see the query in Listing A.9), we limited the query to results fromthe year 2005 or newer because the term language workbench was only defined byFowler [26] in 2005. Consequently, articles older than that do not adhere to our definitionof language workbenches. This results in 21 hits.
Next, we analyze the abstract, author keywords, and index keywords to filter outliterature which focuses on another area than our research. This leaves us with 13 hits.
13
2. State of the Art
The excluded areas are listed in appendix A.2.3.
Multilevel Modeling
All multilevel modeling queries used two alternative spellings of multilevel: “multilevel”(like used in [28]) and “multi-level” (like in [45]). One of the spellings is required byevery query.
The first query (see Listing A.10) additionally requires the keywords of modeling andrequirements. This results in 75 hits.
In the next query (see Listing A.11) we require all results to be from the year 2001or newer. This is justified because the oldest foundational article [4] about multilevelmodeling known to us and the wiki17 of the International Workshop on multilevelModelling18 was published in 2001. This leaves us with 66 hits.
Next (see the query in Listing A.12), we filter out all conference proceedings, or inScopus called conference review, because they do not contain a single paper but simplyare the collection of all papers of a conference. This leaves us with 55 hits.
Next (see the query in Listing A.13), we filter out all results matching one or more ofthe following keywords as these indicate that the literature is not related to our topic:"internet of things", cellular, music, hospital, "financial audits", antennas, HLPSL, "IPcores".
Next, we analyze the abstract, author keywords, and index keywords to filter outliterature which focuses on another area than our research. This leaves us with 14 hits.The excluded areas are listed in appendix A.2.4.
2.2.3.3. Selection of Relevant Literature
Taking all hits after the last iteration of the query limitation for all four search conceptsgives us 61 unique hits. After removing [51] because we could not get access to it, thisleaves us with the following 60 articles: [1–3, 8–10, 13, 15, 16, 18–20, 22, 24, 27–29, 31, 32,34, 35, 37–39, 41–43, 46–50, 53–56, 61–64, 67–72, 74–79, 81–87, 89].
In order to get the literature relevant to our research, we read these 60 articles toselect the ones that talk about requirements of tools for at least one of the four searchconcepts. Thereby, requirements can be described in two ways. The first one is to definethem explicitly by stating requirements directly. An example for this from the relevantliterature is: “a meta-modeling environment should allow the generation of a modeleditor to a wide extent from a metamodel of a DSML” [28, p. 6]. The second alternativeis describing them indirectly by explaining the features of a tool developed or analyzedin the article. An example for this from the relevant literature is: “The XLM does notonly allow the user to perform typical modifications like adding and removing elementsfrom the model, but it also supports changes of the types of model elements at runtime”[20, p. 3]. Applying this filter criterion results in 16 relevant articles.
17http://homepages.ecs.vuw.ac.nz/Groups/MultiLevelModeling/18https://www.wi-inf.uni-duisburg-essen.de/MULTI2017/
14
2.2. Literature Review on Requirements of Multilevel Modeling Tools
We add Fowler’s article about language workbenches [26] to the set of relevantliterature because it founded the research in language workbenches by defining the termand provides requirements for them. Furthermore, the article could not be found withScopus, as it was not published in a journal. This results in the final set of 17 relevantarticles to analyze: [8, 18, 20, 26, 28, 29, 35, 46–48, 56, 61, 62, 76, 79, 81, 85]
2.2.4. Literature Analysis and Synthesis
In this subsection, we analyze the requirements discussed in the 17 relevant referencesresulting from the literature search. All these references were published between 2005and 2017. Thereby, 14 of the references are from 2010 or newer. Seven references areeven from 2014 or newer. This indicates a steady interest in the topic from 2010 onwards.
We analyze the content of the references to extract requirements and aggregate themto categories. Thereby, we first extract 104 requirements. Subsequently, we aggregatethem to 16 categories by using inductive reasoning.
The result of this analysis is shown in Table 2.2. In order to provide traceability forthe extracted requirements, we provide the references for each one. Below, we describethe determined categories in context of their contained requirements.
Table 2.2.: Requirements for Multi-Level Modelling ToolsCategory Requirement References
Model Representation
Define DSMLs with UML-like notation [28]
Immediately show class extensions in lower level classes [28]
Represent language architectures [28]
Integration of multiple DSMLs into one editor [28]
Navigation through modelling levels [28]
Visualize model elements with types and relations [56]
Modelling tasks executed in a visual representation [20]
Separate diagrams for different modelling levels and their relations [20]
Separate diagrams for instantiations between modelling levels [20]
Represent model in multiple ways with different projections [85]
Separation of editable and storage representation [26]
Edit a DSL’s abstract representations through a projectional editor [26, 85]
Graphical editor to design models [76]
Editor allows to switch between multiple views: diagram, matrix, table [76]
Creation of multi-language diagrams [29]
Definition of graphical representations for language elements [81]
Provide mapping between abstract syntax and graphical representation [81]
Template-based syntax definition for models [18]
DSL’s abstract representation can handle errors and ambiguities [26]
continued on next page
15
2. State of the Art
Model Creation
Define generic model templates that can be instantiated to models [47]
Limit element instance extension with new attributes [18]
Extend element instances with new attributes [48]
Define instantiation modelling level of model elements with intrinsic features [28]
Define instantiation meta-level of models and model elements with potency [18, 48, 79]
Define languages that are integrated with each other [26]
Define DSL as a metamodel including the domain concepts and rules [76]
Extend languages with inheritance and concept extension [85]
Classes of different modelling levels in the same model [28]
Explicit modelling level definition for classes [28]
Definition of language elements and their legal configurations [8, 85]
Add elements to model [8, 20]
Create instances for any ontological type independent of its definition level [56]
Editor for model creation [29]
Definition of intrinsic attributes [29]
Use model as meta-model for next lower modelling level [20, 56]
Arbitrary number of modelling levels [28, 48, 56]
Model Update
Define which language elements may be extended [18]
Editor for model modification [29]
Change types of instances at runtime [20]
Syntax-directed editing that ensures legal models [8]
Modify models [8, 18, 28, 29, 35, 48,56, 76, 85]
Adding an intrinsic feature to a model element is automatically propagated to instances [28]
Model Deletion Remove elements from models [8, 20, 28]
References
References with their concrete type defined at lower level by using potency [46]
References to elements in other languages [85]
References between model elements [18, 20, 46–48]
CompatibilityCompatibility to existing meta-modelling languages [28]
Compatibility to load EMF models [56]
Import & Export
Provide default serialization for abstract representation [26]
Store data as file [85]
Load and store models in a human-readable textual notation [48]
Instance serialization as XMI [56]
Validation
Define model-wide constraints [46–48]
Define reusable constraints [48]
Define constraints with Epsilon Object Language [18, 47, 48]
Define constraints with Java [18, 48]
Define a constraint’s evaluation meta-level with potency [46, 48]
Automatic model consistency check on model change [20]
Define constraint templates [20]
Define constraints for types [20]
Support model validation and checking [61]
Check for semantic errors [85]
DSML implementations support validation [62]
Define constraints with Object Constraint Language [56]
Tool GenerationAutomatic editor generation for defined DSML [28, 29, 62]
Automatically derive syntax highlighting for created DSLs [85]
Code Generation& Templates
Definition template-based code generators with Epsilon Generation Language [18, 46, 47]
Definition type-generic code generators with Epsilon Generation Language [47]
Generate code following the JMI specification [48]
Definition of code generators [26, 76, 85]
Automatically execute code generation on save [85]
continued on next page
16
2.2. Literature Review on Requirements of Multilevel Modeling Tools
Transformation
Define type-generic behavior with Epsilon Object Language [47]
Define model transformations with the Epsilon Transformation Language [18, 47, 48]
Define model transformations with ATLAS Transformation Language [56]
Instantiate models with Epsilon Object Language [48]
Define model behavior with Epsilon Object Language [47, 48]
Define model behavior with Java [47]
Allow definition of transformations between arbitrary languages [85]
Allow definition of refactorings [85]
Transform language defined with XSD to metamodel [62]
Define and execute complex model modifications [8]
Versioning
Database for all kinds of modelling artifacts [79]
Support for popular version control systems [85]
Repository for metamodels [76, 81]
Repository for models (instances) [8, 81]
Provide diff and merge of abstract representation [26]
Migration
Migrate legacy models to new version of language definition [8]
Automatically propagate changes on metamodel in repository to models [76, 81]
Automatically propagate changes on metamodel in repository to code generators [76]
Definition of migration rules [8]
Manual or automatic application of migration rules on model repository [8]
Automatically adapt derived constraints to changes of elements in its scope [20]
Evolve a DSL and any code built in it together [26]
Modification of a model must be propagated to all affected models on lower levels [28]
Utility Undo and redo for all API calls [48]
Quality Attributes
Extensibility [81]
Flexibility [61]
Interoperability [61, 81]
Scalability [61, 81]
User-friendly interface [61]
API
API for tool extension and modification [81]
API for CRUD operations on modelling artefacts [79]
API for validation [79]
API for model creation [48]
2.2.4.1. Model Representation
Model representation is about making the abstract in-memory version of a modelavailable to the user by rendering it to a viewable format. One way to edit a language’sabstract representation is using a projectional editor [26, 85]. Thereby, the editableabstract representation should be separated from the stored serialization. Furthermore,a language’s abstract representation must be able to tolerate errors and ambiguities [26].Projectional editing can be used to represent the same model in multiple ways by usingdifferent projections [85]. For instance, an editor can allow switching between multipleviews of one model such as a diagram, matrix, or table [76].
Another option for model design is using a graphical editor [76]. Therefore, an“UML-like notation” [28] can be used. Similarly, references propose to execute modelingtasks in a visual representation [20] and visualize model elements with their typesand relations [56]. Congruently, modeling tools should supply a mapping betweena model’s abstract- and graphical representation for graphical modeling languages
17
2. State of the Art
[81]. Furthermore, such tools should provide the capability to define custom graphicalrepresentations for language elements [81].
In a multilevel context, additional requirements exist [28]. The tool needs to be ableto represent a language’s architecture including classes on different levels. One mustbe able to navigate through the modeling levels. Also, extensions of a class should bedirectly shown in affected classes on lower levels. Lastly, it is desirable to be able to theintegrate of multiple DSMLs into one editor [28]. For instance, this could be done bycreating “multi-language diagrams” [29]. An approach for the visualization of multilevelhierarchies is using separate diagrams for each modeling level and then having furtherdiagrams which define the instantiation relationships between two levels [20].
In the context of textual languages, the syntax of models can be defined based ontemplates [18].
2.2.4.2. Model Creation
This category defines requirements related to the creation of models. Basic requirementsare an editor for model creation [29] and the possibility to add elements to a model [8,20].
One way to define a new DSL is defining it as a meta-model which includes thedomain concepts and rules [76]. Congruently, two further references [8, 85] requirethe capability to define language elements and their legal configurations. To go onestep further, Fowler [26] requires to define languages which can be integrated withone another. Also, languages could be created by inheriting from a base language andextending its concepts [85].
To allow multilevel modeling, support for an arbitrary number of modeling levelsis required [28, 48, 56]. Thereby, models should be usable as meta-models for thenext lower modeling levels [20, 56]. Because technical descriptions sometimes containconcepts from different modeling levels, classes of different levels must be allowed inthe same model. Consequently, it is required that the modeling level of a class can bedefined explicitly [28].
To not only allow instantiation of model elements at the next lower modeling level,potency can be used [18, 48, 79]. Potency allows to define in a meta-model how manytimes a model element (e.g. a class or attribute) has to be instantiated in lower levelsbefore a value has to be assigned [48]. Another similar concept is called intrinsic feature.Model elements can be marked as intrinsic and an instantiation level assigned. Such afeature can only be instantiated on the specified level [28].
For higher modeling flexibility in a multilevel context, instances of a type should beextensible with additional attributes which then can be used in lower modeling levels[48]. But because extension should not always be allowed, it must be possible to limitthe extension for specified model elements [18].
18
2.2. Literature Review on Requirements of Multilevel Modeling Tools
2.2.4.3. Model Update
The Model Update category is defined by requirements defining the capabilities toedit models after they have been created. In general, it is necessary to be able to editmodels [8, 18, 28, 29, 35, 48, 56, 76, 85]. For this, an editor should be provided [29].Further improvements in this regard are ensuring that every editing step results in alegal model by providing syntax-directed editing [8] and providing support to changemodel elements’ types at runtime [20].
In the context of their multileveling framework metaDepth which allows to extendlanguage elements in lower levels, DeLara et al. [18] argue that it is necessary thatlanguage designers can restrict which language elements may be extended (e.g. withnew fields). Also in a multileveling context, intrinsic features that are added to a modelelement, need to be automatically added to its instances as well. Thereby, an intrinsicfeature can only be instantiated on the instantiation level specified in the feature (e.g. anattribute or association) [28].
2.2.4.4. Model Deletion
Requirements relating to the deletion of models or their elements are not discussedextensively in the analyzed references. Only [8, 20, 28] explicitly require the capabilityto remove elements from models.
2.2.4.5. References
To reuse an element defined in a model in other parts of a model (e.g. as type of a field),the element needs to be referenced. Therefore, it should be possible to define referencesbetween model elements [18, 20, 46–48]. To compose languages from several domains,elements from other languages should also be referenceable [85].
In combination with multilevel modeling, assigning potency to the type of a referenceallows defining the reference’s concrete type at a lower level. This has the advantage,that the concrete instantiated type of the reference does not need to be known whendefining the reference [46].
2.2.4.6. Compatibility
When designing a multilevel modeling framework, it should be possible to importexisting DSMLs without restrictive effort. The reason for this is a high number ofexisting DSMLs in enterprise modeling [28]. For instance, this could be done byproviding compatibility with EMF models [56].
2.2.4.7. Import & Export
In general, the import and export of model data is not discussed very detailed inthe analyzed literature. Generally, it should be possible to store models as files [85].
19
2. State of the Art
For model instances, one possibility is using the XML Metadata Interchange (XMI)[56]. Another possibility is using a human-readable textual notation to load and storemodels [48]. As a more abstract challenge, Fowler [26] describes the need to provide aserialization that allows to store and load the abstract in-memory representation of aDSL.
2.2.4.8. Validation
This category covers requirements related to the validation of models. Accordingly,tools should provide capabilities for checking and validation of models [61], checkingfor semantic errors [85], and supporting validation for DSML implementations [62].Another requirement might be the automatic check of model consistency whenever themodel is changed [20].
Constraints can be used to define valid models, for instance by defining type con-straints which need to be fulfilled by all instances of a type [20]. Different technologiesfor defining constraints are suggested: Java [18, 48], the Epsilon Object Language (EOL)[18, 47, 48], or the Object Constraint Language (OCL) [56].
More specific challenges related to the definition of constraints are also defined.Demuth et al. [20] define constraint templates which allow to define generic constraints.These can be instantiated to concrete constraints for all elements with compatible types[20]. Another way of reusing constraints, is the definition of model-wide constraints[46–48]. Reusability is achieved by defining them once and then assigning them tomultiple model elements [48]. To add flexibility in the evaluation of constraints bydefining the evaluation meta-level of a constraint, potency can be assigned to constraints[46, 48]. For instance, this allows to define constraints that only have to be fulfilled twolevels below their definition instead of the next lower level in the standard case.
2.2.4.9. Tool Generation
Meta modeling tools should provide automatic editor generation for DSMLs definedwith the tool [28, 29, 62]. The first reason for this is that a DSML needs an editor to beused effectively [28, 29]. Consequently, the creation or modification of DSMLs is onlypractical if the editor creation has reasonable cost [29]. Secondly, it is not feasible toexpect domain experts that design local DSMLs to be able to implement an editor fortheir DSML [28]. Another tool generation aspect is the automatic derivation of syntaxhighlighting for text-based languages [85].
2.2.4.10. Code Generation & Templates
Code generation is used to transform the abstract representation of a language to atarget language (e.g. C# or Java) to get an executable or compilable representation ofthe language [26, 85]. One example for this is using code generation that results in Java
20
2.2. Literature Review on Requirements of Multilevel Modeling Tools
code compatible to the Java Metadata Interface (JMI) [48]. Thereby, the generation couldbe automatically executed when language changes are saved [85].
Three references [26, 76, 85] require definition of code generator(s) as part of alanguage definition. One way to define code generation is based on templates that arefilled with concrete values from the model that the code is generated for [46, 47]. Forinstance, this can be done with the Epsilon Generation Language (EGL) [18, 46, 47]. Amore advanced approach of this is the definition of type-generic code generators in EGL.They allow code generation for all types adhering to the generic templates prerequisites[47].
2.2.4.11. Transformation
Völter and Visser [85] describe transformations as mappings between different models. Inthis context, they introduce the tool capability to allow the definition of transformationsbetween any desired languages. More specifically, refactorings can be defined for alanguage [85]. Similarly, Braatz and Brandt [8] require the definition and executionof complex model modifications. Concrete proposed technologies for the definition ofmodel transformations are the Epsilon Transformation Language (ETL) [18, 47, 48] andthe ATLAS Transformation language (ATL) [56].
A subset of model transformations is the definition of model behavior or “in-placetransformations” [47, p. 5] which basically allow to execute a model [47]. To definemodel behavior, our references suggest the Epsilon Object Language (EOL) [47, 48] orJava [47]. To get reusable model behavior, EOL can also be used to define type-genericbehavior [47]. This can be executed on all models adhering to the behavior’s expectedconcepts. Furthermore, EOL can be used to populate models with instances [48].
A more specific usage of model transformations is creating meta-models by trans-forming a language defined with XML Schema Definition (XSD) [62].
2.2.4.12. Versioning
For software developers versioning of code is a is a day-to-day practice. This involvesthe safe storage of code artifacts and tracking of their editing history. Therefore, theyoften use version control systems (e.g. Git). Correspondingly, versioning could beused in language tools by integrating standard version control systems [85]. Otherreferences simply suggest that there should be a repository for meta-models [76, 81] andinstance models [8, 81]. Similarly, Van Mirlo et al. [79] talk about a repository for thestorage of all modeling artifacts in their tool. To provide proper version control for DSLs,implementation of diff and merge should be implemented directly on a language’sabstract representation [26].
21
2. State of the Art
2.2.4.13. Migration
Migration is necessary for the evolution of languages [8]. Therefore, tools should be ableto migrate models defined in a legacy version of a language to the language’s currentdefinition [8]. In this regard, Fowler [26] states the importance of a tool’s capability to“evolve a DSL and any code built in the DSL together” [26].
One approach for the definition of migrations is the usage of migration rules. Theserules can then be executed manually or automatically on a repository to migratecontained legacy models [8]. To take it one step further, changes on a meta-model in arepository should automatically be propagated to models [76, 81] and code generators[76] in the same repository. Similarly, in a multilevel modeling environment, themodification of a model must be propagated to all affected models on lower levels [28].A more specific feature is suggested by Demuth et al. [20]: Derived constraints areautomatically adapted to changes of model elements in its scope.
2.2.4.14. Utility
Utility requirements describe functionality that is not necessarily needed but are practicalfor the user. Only one [48] of the analyzed references mentions utility functionality.They provide undo and redo for all API calls against their multileveling framework.
2.2.4.15. Quality Attributes
Although not many references describe any quality attributes, we could extract five.Tools should support easy modification and extension [81]. Appropriately enough, toolsshould provide flexibility to facilitate fast adaption to new abstractions [61]. Furthermore,a tool should support interoperation with other tools and support standard protocols[61, 81]. To support possible increasing complexity in the future, scalability is necessary[61, 81]. Lastly, a tool’s interface should be user-friendly [61].
2.2.4.16. API
An application programming interface (API) allows a developer to access exposedfunctionality of a tool programmatically. Consequently, this can be any functionalityof the tool as long as it is made available publicly. Such an API can be useful to allowextending and modifying a tool without having access to the source code [81]. Morerelated to modeling itself, Van Mierlo et al. [79] offer an API for CRUD operations onmodeling artifacts as well as an API for validating them. Similarly, but less extensive,deLara et al [48] offer a Java API for model creation.
22
2.3. Tool Analysis
2.3. Tool Analysis
In this section, we analyze the implemented functionality of nine editors and derivefunctional requirements out of it. The literature review in section 2.2 focused ona rigorous analysis of the academic knowledge base to gather a wide collection ofrequirements. In addition to this, the tool analysis provides us with further requirementsand an indication of practical relevance. Furthermore, the analysis of industry toolscontributes more concrete requirements to enrich and specify the often more abstractrequirements gathered from the literature review. This will help us to select andprioritize the requirements for our implementation in chapter 3.
To get worthwhile results we follow a structured approach. First, we introduce theanalyzed editors in subsection 2.3.1. Then, we demonstrate the requirements’ significanceby relating them to the categories determined in the rigorous literature review. Finally,we give a precise definition for each of the requirements in subsection 2.3.2.
2.3.1. Analyzed Editors
In this subsection, we introduce the editors whose behavior and functionality weanalyzed. Thereby, we selected editors for structured data because JSON is a data formatfor storing structured data as well. To get a better collection of generic requirements, wechose editors from different vendors and for multiple data formats. The editor selectionwas conducted in close cooperation with our industry partner. They have fundamentalexperience in the development of structured data editors as desktop as well as webapplications. Furthermore, this allows us to consider more concrete requirements inagreement with their implementation goals in comparison to the unbiased requirementscollection from the literature review.
2.3.1.1. EMF Editors
The editors in this section are part of the Eclipse Modeling Framework (EMF) [73]. EMFis an open-source meta-modeling framework developed by the Eclipse Foundation19.It provides an editor to develop models for structured data based on its base meta-model Ecore. Ecore itself is also an instance of Ecore. Hence, it is its own meta-model.EMF allows automatic generation of Java code and instance editors for created models.Instances created with EMF cannot be used as meta-classes for further modeling. Hence,EMF supports meta-modeling with two levels. For every meta-model, a generationmodel (genmodel) can be defined to customize generation parameters for code andeditors, e.g. the Java packages generated classes are placed in [73]. The editors reviewedby us are part of version 2.12.0 (Release: 22.06.2016). EMF is actively maintained. Itscurrent version is 2.13.0 (Release 28.06.2017)20.
19https://eclipse.org/20https://projects.eclipse.org/projects/modeling.emf.emf/governance
23
2. State of the Art
EMF Model Editor (E–1). This editor allows the creation and editing of structuredmodels based on the Ecore language [73].
EMF Genmodel Editor (E–2). This editor allows to edit the generation model for amodel. The generation model specifies code generation parameters such as copyrightnotice, packages, class naming, labels, etc [73].
EMF Instance Editor (E–3). An instance editor is generated by the EMF frameworkfrom a model and a generation model. This editor allows to create and edit instances ofits model [73].
2.3.1.2. EMF Forms Editors
The editors in this section are part of the open-source framework EMF Forms21 whichitself is a subcomponent of the open-source framework EMF Client Platform22. EMFForms provides generation of CRUD UIs based on an EMF model and an UI description(called view model). By using different renderers, the framework allows generationfor the technology stacks JavaFX, Swing, SWT, and Web. EMF Forms is still activelydeveloped. The editors reviewed by us are part of version 1.12.0.
EMF Forms Generic Editor (E–4). This editor allows to open and edit instances ofarbitrary EMF models. It analyzes the instance’s corresponding meta-model and usesthe rendering engine of EMF Forms to create CRUD user interfaces for created objectsin the instance model.
EMF Forms Ecore Editor (E–5). This editor, like the EMF Model Editor, allows tocreate and edit structured meta-models based on the Ecore language. It is based on thepreviously introduced generic editor and adapted for instances of the Ecore Model.
2.3.1.3. XML Spy
The editors in this section are part of the tool XML Spy 201723 which is a commercialtool developed by Altova. According to Altova it “is the industry’s best-selling XMLeditor for modeling, editing, transforming, and debugging XML-related technologies”such as XML Schema, DTD, XSLT, XPath, or XQuery. Furthermore, it also containstools for similar technologies such as JSON Schema, JSON, HTML, CSS, and more. Foranalyzes we used the free evaluation version24 of the tool which is not restricted in itsfeatures besides being limited to 30 days of use.
21https://www.eclipse.org/ecp/emfforms/22https://www.eclipse.org/ecp/23https://www.altova.com/xmlspy.html24https://www.altova.com/download-trial.html
24
2.3. Tool Analysis
XML Spy - XSD Editor (E–6). This editor is a graphical editor for the creation andediting of XML Schemata25 in the XSD format. XML Schemata define the valid elementsin XML files. Consequently, they can be used to validate an XML file’s structure orsuggest valid elements during their creation.
XML Spy - JSON Schema Editor (E–7). This editor is a graphical editor for the creationof JSON Schemata.
2.3.1.4. JSON Schema Editor (E–8)
The JSON Schema Editor26 is a tree-based open-source editor based on AngularJS thatallows to create and edit JSON objects defined by a hard-coded JSON Schema. Theeditor’s repository is owned by EclipseSource27. The editor is not developed at themoment (latest commit: 14.02.2017, last checked: 13.10.2017).
2.3.1.5. JSON Forms Editor (E–9)
The JSON Forms Editor28 is owned by EclipseSource. The editor runs as a web appli-cation and allows to create UI schemata for JSON Forms based on a JSON Schema.Thereby, the JSON Schema can be created or modified simultaneously to editing theUI schema. A UI Schema defines a form generated from a JSON Schema by the JSONForms framework. For our requirements collection, we used the online test instance29
hosted by EclipseSource.
2.3.2. Tool Requirements
In this section we describe the functional requirements derived from the editors ofsubsection 2.3.1. Thereby, we mapped the requirements to the requirement categoriesdetermined in the literature review (see subsection 2.2.4). Table 2.3 shows an overviewover the analyzed tool requirements. The table shows to which requirement category therequirements belong and by how many editors a requirement is fulfilled. Furthermore,it is shown which of the editors described in subsection 2.3.1 satisfies which requirement.Below, we describe every one of the defined requirements.
2.3.2.1. Model Representation
These requirements describe functionality related to displaying the editor’s currentlyloaded model to the user. They map to the requirement category described in subsection2.2.4.1.25https://www.w3.org/standards/xml/schema26https://github.com/eclipsesource/json-schema-editor27https://eclipsesource.com/28http://jsonforms.io/#/docs/jsonformseditor29http://jsonforms-editor.eclipsesource.com/
25
2. State of the Art
Table 2.3.: The Analyzed Tool Requirements Mapped to the Requirement CategoriesDetermined in the Literature Review
Count E–1 E–2 E–3 E–4 E–5 E–6 E–7 E–8 E–9Model RepresentationElement Containment Tree 9 X X X X X X X X XElement Grid 2 X XElement Hierarchy Hints 1 XElement Hierarchy Information 5 X X X X XMultiple Synchronized Views 2 X XProperty Grouping 1 XRoot Elements Overview 3 X X XTextual Model Representation 2 X XModel CreationAdd Elements in Properties View 1 XContextual Element Creation 9 X X X X X X X X XDynamic Inst. Creation of Defined Types 2 X XModel UpdateContextual Drag and Drop 9 X X X X X X X X XEdit Element Properties 9 X X X X X X X X XElement Name Refactoring 1 XModify Related Schema 1 XTyped Property Editing 6 X X X X X XModel DeletionElement Deletion 9 X X X X X X X X XReferencesElement Extraction and Reference 1 XReferences Between Elements 6 X X X X X XShow Element References 5 X X X X XImport & ExportExport Model as Text 1 XLoad and Edit Further Models 6 X X X X X XLoad Data Schema from Github 1 XLoad Data Schema by Upload 1 XLoad Data Schema from URL 3 X X XLoad Model from File 7 X X X X X X XPersist Edited Model as File 7 X X X X X X XValidationAutomatic Validation 3 X X XProperty Validation 5 X X X X XProperty Validation Shown in Tree 1 X PStructural Instance Validation 4 X X X XUtilityCopy, Cut, and Paste 6 X X X X X XUndo and Redo 7 X X X X X X XAPITrigger External Operations on Model 3 X X X
26
2.3. Tool Analysis
TR–1: Element Containment Tree
The editor shows a containment tree with a tree element for every data object definedin the current model. This tree shows the elements’ containment hierarchy: The usercan recognize which element contains which other elements in the model simply bylooking at the tree (e.g. by indent and/or connecting lines). Furthermore, the treeallows to collapse and expand elements. If an element is collapsed, none of its containedelements are shown. If it is expanded, all of them are shown. Every element displays anidentifying label of its associated data object. The concrete label displayed depends onthe available information about the element, both from its properties and its definitionin the meta-model.
TR–2: Element Grid
The editor shows an interactive grid with an element for every data object and forevery property defined in the current model. Thereby, the contained children of anelement as well as its properties are displayed as a sub-grid of their parent. A gridelement can either be collapsed or expanded. When an element is collapsed, it onlyoccupies one cell of the grid and at least the element’s type is displayed. No propertiesor contained elements are shown. When an element is expanded from its collapsedstate, the element’s grid-cell expands and a new sub-grid is shown inside the cell. Thissub-grid then contains the expanded element’s properties and contained elements. Thissub-grid itself again works like the previously described element grid.
TR–3: Element Hierarchy Hints
The editor explicitly shows the element hierarchy. For every element in the currentmodel, the editor displays indicators that show which types of elements are legalcontained children of the annotated element.
TR–4: Element Hierarchy Information
The editor is able to show an element type’s inheritance hierarchy. Thereby, the inheri-tance hierarchy for all supertypes is shown, too. Furthermore, for every property of theanalyzed type, the editor shows which type in the hierarchy defines the property.
TR–5: Multiple Synchronized Views
The editor supports multiple representations of the same model (e.g. element contain-ment tree and textual representation). When the model is changed in one of the views,all other views are updated automatically to correctly represent the new data.
27
2. State of the Art
TR–6: Property Grouping
When displaying an element’s properties, the editor groups them in basic and advancedproperties. The grouping is visualized by placing properties of the same group adjacentto each other and dividing the groups from each other (e.g. by a border).
TR–7: Root Elements Overview
The editor displays an element for every data object at the highest level of the model.For every element, at least its type is shown.
TR–8: Textual Model Representation
The editor shows an editable textual representation of all data contained in the model.The editor allows to edit all data objects as well as their properties. Additionally, themodel is serialized in such a way that the data objects’ containment hierarchy can beconcluded unambiguously.
2.3.2.2. Model Creation
These requirements describe functionality related to the creation of new models andmodel elements by the user. They map to the requirement category described insubsection 2.2.4.2.
TR–9: Add Elements in Properties View
The editor allows to add new contained children inside the rendered properties viewof the currently selected data object. Thereby, the created child can only be of a typeallowed by the schema for the selected parent object. After its creation, the child isadded to the model and an appropriate element is created and added to the model’srepresentation.
TR–10: Contextual Element Creation
The editor allows to create new data objects as children of other data objects or theroot object. Thereby, these objects can only be created at legal positions in the model asdefined by the meta-model. Created data objects are automatically added to the model’srepresentation.
TR–11: Dynamic Instance Creation of Defined Types
This requirement assumes that the current model defines some kind of data types (e.g.classes). If the selected type is instantiable, the editor allows to create a new instance ofthis type in a separate model. The separate model’s data schema is the model definingthe instantiated type.
28
2.3. Tool Analysis
2.3.2.3. Model Update
These requirements describe the editor’s capabilities to modify existing data objects inthe model. They map to the requirement category described in subsection 2.2.4.3.
TR–12: Contextual Drag and Drop
The drag and drop functionality works on the elements displayed in the model’srepresentation. The editor allows to drag elements and drop them only at other validpositions in the model. Thereby, the schema defines which positions are valid: Elementscan only be dropped, if the new parent element can contain it as a child. When anelement is moved, all its contained children are moved, too. The element’s associateddata object is moved to the new position in the model.
TR–13: Edit Element Properties
The editor allows to edit the properties’ values of all elements in the model.
TR–14: Element Name Refactoring
The editor allows to rename an element and automatically adapt all references to thiselement in the current model.
TR–15: Modify Related Schema
The editor allows to modify the current model’s data schema. Thereby, elements can beadded to and removed from the schema.
TR–16: Typed Property Editing
When editing the properties of an element, the editable representation of a propertyis adapted to its data type. Depending on the data type, this prevents the user fromentering incorrect data. Example: A property of type date could set with a data picker.As a result, the chosen date automatically has the correct format.
2.3.2.4. Model Deletion
This requirement describes functionality related to removing data from the model andmaps to the requirement category described in subsection 2.2.4.4.
TR–17: Element Deletion
The editor allows to delete elements from the model’s representation. Thereby, theelement and all its contained children are deleted from the representation and the modelitself.
29
2. State of the Art
2.3.2.5. References
These requirements describe functionality related to defining references between dif-ferent model elements. They map to the requirement category described in subsection2.2.4.5.
TR–18: Element Extraction and Reference
The editor allows to extract suitable model elements to their own model and thenreferences it from the original model. The newly created model uses the same schemaas the model the element has been extracted from.
TR–19: References Between Elements
The editor allows to create references between elements. This means that an elementproperty can link another existing model element instead of containing the value directly.The elements can be from different loaded models. When creating a reference, the editoronly allows to link elements whose type is compatible to the referencing property’s type.
TR–20: Show Element References
The editor is able to show where a selected element is referenced in the current modelor another (implicitly) loaded schema or model.
2.3.2.6. Import & Export
These requirements describe functionality related to the loading and saving of dataschemata and models from various sources. They map to the requirement categorydescribed in subsection 2.2.4.7.
TR–21: Export Model as Text
The editor allows to serialize the current model to text and make the serializationavailable to the user.
TR–22: Load and Edit Further Models
In addition to the current model, the editor allows to load further models. Theseadditional models can be edited in the editor as if they were the originally openedmodel. Furthermore, all loaded models, including the original one, can referenceelements from the other models.
30
2.3. Tool Analysis
TR–23: Load Data Schema from Github
The editor allows to import a data schema from a public or private Github repository. Toallow the loading from a private repository, the user can log in with her Github accountand grant the corresponding permissions to the editor.
TR–24: Load Data Schema by Upload
Assuming that the editor runs as a web application, the editor allows to upload a schemafrom the user’s device which she uses to access it.
TR–25: Load Data Schema from URL
The editor allows to import a data schema from an URL provided by the user.
TR–26: Load Model from File
The editor allows to load a model from a file saved on the user’s device executing theeditor.
TR–27: Persist Edited Model as File
The editor allows to serialize the current model and save it in a file on the user’s device.
2.3.2.7. Validation
These requirements describe functionality related to validating that a model adheres toits specification. They map to the requirement category described in subsection 2.2.4.8.
TR–28: Automatic Validation
Whenever a model element is changed, the editor automatically re-validates the modelcontaining the modified element.
TR–29: Property Validation
The editor validates the non-containment properties of all model elements against themeta-model. Thereby, the editor checks for every property if its restrictions (e.g. that astring is not empty) defined in the schema are fulfilled. Validation errors are marked onthe validated property’s visual representation.
TR–30: Property Validation Shown in Tree
When the validation of a property results in an error, the editor visually marks theelement, which contains the property, in the model’s element containment tree. This
31
2. State of the Art
requirement assumes that the editor fulfills the Element Containment Tree requirement(see TR–1).
TR–31: Structural Instance Validation
The editor validates the structure of the current model against the meta-model. Thereby,the editor checks whether elements adhere to containment constraints and whetherrequired references are set. Containment constraints define the multiplicity and the typeof a type’s containment property. If the validation finds any errors, they are reportedand the invalid elements are marked in the model’s representation.
2.3.2.8. Utility
These requirements describe utility functions that improve the editor’s general usageexperience. They map to the requirement category described in subsection 2.2.4.14.
TR–32: Copy, Cut, and Paste
The editor allows to copy, cut, and paste model elements. Whenever, an element iscopied or cut, the element is copied to the clipboard with all its properties and containedchild elements. If the element was cut, it and all its children are removed from themodel. When an element is pasted from the clipboard, it is added to the model as achild of the element that it has been pasted on. Thereby, the pasted element’s containedchildren.
TR–33: Undo and Redo
The editor is able to undo any user action that changed the current model. This meansthe model is reverted to the state it was in before the action was executed. For instance,the user deletes an element A from the model. If the user then uses the undo function,the element A is part of the model again as it was never deleted. Furthermore, the editoris able to redo undone actions. Concretely, any action that has been undone by the user,can also be redone. After the redo functionality was executed, the model is in the state,as if the redo was never executed. For instance, if the redo function is used after theundo action in the example above, element A is removed from the model again.
2.3.2.9. API
This requirement describes functionality related to accessing and using an interfaceto the editor’s status and data. They map to the requirement category described insubsection 2.2.4.16.
32
2.3. Tool Analysis
TR–34: Trigger External Operations on Model
The editor allows to use the model as a parameter for external operations. Thereby, theoperations can be executed directly from within the editor without the need to explicitlystart the called programs. These operation can simply read the model’s content, e.g. forcode generation, or transform the model itself.
33
3. Requirements
In this chapter, we determine the requirements for our implementation of the model-driven JSON editor. The whole set of requirements consists of the editor’s functionalrequirements (FRs), implementation constraints (ICs), and quality attributes (QAs). Toselect the relevant requirements and implementation constraints, we conduct an expertinterview in cooperation with our industry partner EclipseSource München GmbH30.We interview the company’s senior software architects. In the expert interview, we selectthe functional requirements based on our analysis of the state of the art in chapter 2 andassign one of the three priorities described in section 3.1. Furthermore, we link them totheir source requirements in chapter 2 and describe the differences to their sources. Theresulting functional requirements are categorized by priority and described in section 3.2.The implementation constraints are not directly related to existing requirements fromthe state of the art. They are described in section 3.3.
3.1. Priorities
In this section, we describe the three priorities which we use to define the importance ofthe functional requirements
1 � Must Have Requirements with this priority are essential for the proper usage andfunctioning of the model-driven editor. The editor is not considered finished untilthey are implemented.
2 � Desirable Requirements with this priority represent functionality that greatly im-proves the editor’s quality and its applicability to different contexts. However,in comparison to requirements of priority 1, the editor still provides acceptableresults without implementing any of them.
3 � Nice To Have Requirements with this priority improve the editor’s overall qualityand applicability while not being necessary for satisfying results. Implementationof these requirements is anticipated if there is leftover time, the implementationtakes little effort, or comes with little additional time investment when implement-ing a requirement of the priorities 1 or 2.
30https://eclipsesource.com/about/company/eclipsesource-munich/
35
3. Requirements
3.2. Functional Requirements
In this section, we describe the selected functional requirements for the editor dividedinto their priorities. Thereby, we explain on which requirements from chapter 2 they arebased and with which requirements they are associated.
3.2.1. Must Have
This subsection describes the editor’s “must-have” requirements sorted alphabetically.
FR–1: Contextual Drag and Drop
This requirement takes its content from tool requirement 12 of the same name. Addi-tionally, the drag and drop is only needed inside the editor’s element containment tree(see FR–4). This requirement is associated with the literature review’s category “ModelUpdate” (see 2.2.4.3) and contributes to fulfilling its requirements “Modify models” and“Editor for model modification”.
FR–2: Contextual Element Creation
This requirement is equal to tool requirement 10 of the same name. It is associated withthe literature review’s category “Model Creation” (see 2.2.4.2) and its requirement “Addelements to model”.
FR–3: Edit Element Properties
This requirement is equal to tool requirement 13 of the same name. It is associated withthe literature review’s category “Model Update” (see 2.2.4.3) and contributes to fulfillingits requirements “Modify models” and “Editor for model modification”.
FR–4: Element Containment Tree
This requirement is based on tool requirement 1 of the same name. In distinctionto the basis, we do not require capabilities for the expansion and collapsing of treeelements. Furthermore, while the tree must be capable of displaying labels and icons,their origin is not specified in this requirement but in FRs 14 and 15. This requirement isassociated with the literature review’s category “Model Representation” (see 2.2.4.1) andits requirement “Edit a DSL’s abstract representations through a projectional editor”.The latter is the case because a model’s in-memory containment hierarchy is projectedas a tree.
FR–5: Export Model as JSON-encoded Text
This requirement is based on tool requirement 21 “Export Model as Text”. Additionally,
36
3.2. Functional Requirements
we require that the exported text is encoded in JSON format. This requirement isassociated with the literature review’s category “Import & Export” (see 2.2.4.7). It fulfillsits requirements “Provide default serialization for abstract representation” and the storepart of “Load and store models in a human-readable textual notation”.
FR–6: External Interface to Model
Similarly to tool requirement 34 “Trigger External Operations on Model”, the editorprovides a public interface to the currently edited model. This allows to read and setthe model. This requirement is associated with the literature review’s category “API”(see 2.2.4.16).
FR–7: Load Model from JSON File
This requirement is based on tool requirement 26 “Load Model from File”. Additionally,we specify that the loaded data must be in JSON format. This requirement is associatedwith the literature review’s category “Import & Export” (see 2.2.4.7). It fulfills the loadpart of the requirement “Load and store models in a human-readable textual notation”.Furthermore, it is associated with the requirement “Provide default serialization forabstract representation” as it allows using the default serialization again.
FR–8: Property Validation
This requirement is equal to tool requirement 29 of the same name. It is associated withthe literature review’s category “Validation” (see 2.2.4.8) and its requirements “Supportmodel validation and checking” and “Check for semantic errors”.
FR–9: References Between Elements
This requirement is equal to tool requirement 19 of the same name. It is associated withthe literature review’s category “References” (see 2.2.4.5) and fulfills its requirement“References between model elements”.
FR–10: Remove Elements from Model
This requirement is the same as tool requirement 17 of the same name. It is associatedwith the literature review’s category “Model Deletion” and fulfills its requirement“Remove elements from models”.
FR–11: Save Edited Model as JSON File
This requirement is based on tool requirement 27 “Persist Edited Model as File”. Addi-tionally, we specify that the file’s data is encoded as JSON. This requirement is associated
37
3. Requirements
with the literature review’s category “Import & Export” (see 2.2.4.7). It fulfills its re-quirements “Provide default serialization for abstract representation” and the store partof “Load and store models in a human-readable textual notation”.
FR–12: Typed Property Editing
This requirement is equal to tool requirement 16 of the same name. It extends thecapabilities described in FR–3. It is associated with the literature review’s category“Model Update” (see 2.2.4.3) and contributes to fulfilling its requirements “Modifymodels”, “Editor for model modification”, and “Syntax-directed editing that ensureslegal models”. The latter is facilitated by limiting the input of property values to legalchoices. For instance, rendering a boolean property as a checkbox naturally only allowsto select true or false as its value.
3.2.2. Desirable
This subsection describes the editor’s desirable requirements sorted alphabetically.
FR–13: Automatic Property Validation
This requirement is equal to tool requirement 28 of the same name. It is associated withthe literature review’s category “Validation” (see 2.2.4.8) and its requirement “Automaticmodel consistency check on model change”.
FR–14: Definition of an Element Type’s Label Property
The editor allows configuring for every data type which of its properties is used as itslabel. Thereby, this label is displayed in the element containment tree (FR–4) as part ofthe tree node representing an instance of the data type. Whenever, the configured labelproperty changes, the label is automatically updated (see FR–18). This requirement isassociated with the literature review’s category “Model Representation” (see 2.2.4.1)
FR–15: Definition of Icons for Element Types
The editor allows to configure icons for data types. These icons are displayed in theelement containment tree (FR–4) next to the tree node representing an instance of thedata type. This requirement is associated with the literature review’s category “ModelRepresentation” (see 2.2.4.1) and its requirement “Definition of graphical representationfor language elements”.
FR–16: Duplicate Elements
The editor allows to duplicate an element and inserts the duplicate as a sibling of theoriginal element. Thereby, the editor only allows the duplication if the insertion is legal.
38
3.2. Functional Requirements
This means the original element must fulfill one of the following conditions. It is part ofa multi containment property. Or it is a root element and multiple root elements areallowed in the model. There is no directly equivalent tool requirement. However, it isrelated to tool requirement 32 “Copy, Cut, and Paste” because a duplication is essentiallycopy and immediate paste at the copy location. Therefore, this requirement is associatedwith the literature review’s categories “Model Creation” (see 2.2.4.2) and “Utility” (see2.2.4.14).
FR–17: Property Validation Shown in Tree
This requirement is the same as tool requirement 30 of the same name. It is associatedwith the literature review’s category “Validation” (see 2.2.4.8).
FR–18: Synchronize Element Containment Tree with Detail View
If relevant, the editor automatically synchronizes changes made to an element in itsdetail representation with the element containment tree. For instance, the detail viewcould allow adding an element to a containment property. Then the added elementshould automatically be represented in the tree. This requirement is associated with theliterature review’s category “Model Representation” (see 2.2.4.1).
3.2.3. Nice To Have
This subsection describes the editor’s “nice to have” requirements sorted alphabetically.
FR–19: Copy and Paste Elements
This requirement is based on tool requirement 32 “Copy, Cut, and Paste”. The differenceto the basis is that this requirement does not require the capability of cutting elements.It is associated with the literature review’s category “Utility” (see 2.2.4.14).
FR–20: Cut and Paste Elements
This requirement is based on tool requirement 32 “Copy, Cut, and Paste”. The differenceto the basis is that this requirement does not require the capability of copying elements.It is associated with the literature review’s category “Utility” (see 2.2.4.14).
FR–21: Structural Instance Validation
This requirement is equal to tool requirement 31 of the same name. It is associated withthe literature review’s category “Validation” (see 2.2.4.8) and contributes to fulfillingits requirements “Support model validation and checking” and “Check for semanticerrors”.
39
3. Requirements
FR–22: Undo and Redo
This requirement is equal to tool requirement 33 of the same name. It is associated withthe literature review’s category “Utility” (see 2.2.4.14) and is related to its requirement“Undo and Redo for all API calls”. While our requirement is not specific to API calls,both are about undoing and redoing changes to the model.
3.3. Implementation Constraints
In this section, we define the editor framework’s implementation constraints. As theyall are mandatory to follow, no priorities are assigned.
IC–1: Implementation in Typescript
The implementation of the editor framework is done in Typescript which “is a typedsuperset of JavaScript that compiles to plain JavaScript” [60].
Modern web applications are usually implemented in JavaScript. However, JavaScripthas the disadvantage of being a completely dynamically typed language. Consequently,static type checking is not possible in JavaScript. The problem with this is that manymodern software development tools do not work properly without static type checking.For instance, static type checking allows code navigation to types of variables, statementcompletion for variable and method names, and safe refactorings. Furthermore, typeerrors can only be known at runtime without static type checking [33]. Typescript solvesthis by offering the optional declaration of types and intelligent type interference [33,60].
The second advantage of using TypeScript over JavaScript lies in its transpilation31
process. This process allows transforming the typed TypeScript code to plain JavaScriptcode which can run anywhere where JavaScript is executable, e.g. web browsers orNode.JS. This allows using features of new ECMAScript (ES)32 specifications duringdevelopment (e.g. like classes or maps) and transpile the code to JavaScript compatiblewith older ES versions. The advantage of this is that the “feature gap” between thecurrent specification and the actual support in browsers and other tools can be mitigated[33]. Furthermore, the compatibility level of the generated JavaScript code can simplybe specified in the TypeScript configuration. This approach is visualized in Figure 3.1.
IC–2: JSON as Model Serialization Format
In conformity with the functional requirements FR–5, FR–7, and FR–11, models editedin the editor are serialized and deserialized in the JSON format. JSON is a wide-spread,
31Transpilation is defined as source-to-source compilation. This means source code of one language iscompiled to source code of another language.
32ECMAScript is the standard defining the JavaScript language. It is managed by Ecma International.
40
3.3. Implementation Constraints
TSCode
TSConfig
TypeScriptCompiler
ES5
ES3
ES6
Figure 3.1.: TypesScript Transpilation Overview. Depending on the configuration, theTypeScript compiler compiles the TypeScript source code to JavaScript com-patible to different versions of ECMAScript (ES).
platform independent and human-readable data interchange format. Additionally, itintegrates smoothly with JavaScript and thereby Typescript (see IC–1).
IC–3: JSON Schema to Define Data Models
JSON Schema33 is used to define the meta-models for our editor framework. JSONSchema is an internet draft that allows defining how a JSON document is supposed tolook like. Concretely, it defines which elements may exist, which hierarchy they mayhave, and which properties they can contain. Furthermore, additional constraints onthe data can be defined. For instance, mandatory properties, the minimum value of anumber property, or a regex pattern that a string property must satisfy [23].
Thereby, JSON Schemata are defined in the JSON format themselves. Furthermore,JSON Schema is its own meta-model and consequently defined in terms of itself. Thisoffers a crucial conceptional advantage. Because the meta-model defining JSON Schemais a JSON Schema itself and JSON Schemata are defined in JSON, the editor frameworkcan create an editor based on the meta-model that allows creating new JSON Schemata.These schemata can then be used with the same framework to create an editor for thejust defined data. In conclusion, using JSON Schema to define the editor’s meta-modelsallows us to define new meta-models which can then again be used to generate a neweditor.
33http://json-schema.org/
41
3. Requirements
3.4. Quality Attributes
In this section, we describe the quality attributes that we want to realize in the editorframework’s architecture, design, and implementation.
QA–1: Configurability
The editor framework should provide extensive options to configure generated editors.The reason for this is that the framework allows editor generation for all kinds of data.Different meta-models have different requirements for the display and editing of theirinstances. Possible configuration options include labels (see FR–14), icons (see FR–15),and the rendering of element properties. Related to the latter, desirable configurationsinclude, for instance, which properties are shown or whether they are read-only.
QA–2: Extensibility
The editor framework should be easily extensible with new functionality. This especiallyconsiders two aspects. “Internal” extensibility: It should be easy to add or changefunctionality related to the element containment tree (FR–4) or editing the elements’properties. “External” extensibility: It should be easy adding functionality related tothe editor framework’s and the generated editor’s external interfaces. This includesextending configuration options as well as the loading and saving of models fromrespectively to different sources (e.g. load model from URL).
QA–3: Integratability
The editor framework, as well as generated editors, should be easily integratable in otherapplications using compatible technologies. In conformity with QA–1, this especiallyrequires that the framework provides simple access to the configuration options in anintegration scenario.
42
4. Implementation
In this chapter, we describe the architecture, design, and implementation of the editorframework. We start with the architecture in section 4.1. Thereby, we introduce thedifferent components of the editor framework. In the following sections we describethe design and implementation of the framework’s components in sections 4.2, 4.3, 4.4,4.5, 4.6, 4.7, and 4.8. We justify our design decisions with the requirements establishedin chapter 3. In section 4.9, we give a detailed explanation of the reference mechanismwhich allows to reference data in- and outside the data of a generated editor. Finally, wespecify the customization options for an editor and illustrate their usage in section 4.10.
4.1. Architecture
In this section, we describe the conceptional architecture of the editor framework.Thereby, we first give an overview over all components in this section and then de-scribe every component in a separate section. Figure 4.1 shows the architecture as aUML component diagram. The entry point of the framework is the EditorRenderer
component. It provides three interfaces to configure the rendered editor. The schemainterface allows to set and read the JSON Schema defining the generated editor’s data.The data interface allows to set and read the data currently displayed in the editor. Theconfiguration interface allows customizing additional properties of the editor, such asicons and labels shown in the containment tree. All customization options are describedin detail in section 4.10. These interfaces can be accessed by Services to extend theeditor’s behavior with additional functionality. Thereby, the Services component in thediagram represents an arbitrary number of services which can each use one or more ofthe provided interfaces. Because these interfaces are publicly available, a service can beadded without any need to edit the editor framework’s source code. Consequently, thisgreatly contributes to satisfying the extensibility quality attribute (see QA–2).
In order to render the editor, the EditorRenderer requires two interfaces. The firstone is rawSchema. This is used to provide the JSON Schema defining the data editablein the editor. The second one is renderContainmentTree. This is used to render theelement containment tree (see FR–4) of the data currently edited in the editor. Bothinterfaces are provided by subcomponents of the JsonForms2 component. The Parser
takes a plain JSON Schema, analyzes it for defined types and properties, organizesthe gained information in a practical data structure and makes the results availablefor other components via its analyzedSchema interface. The TreeRenderer offers therenderContainmentTree interface. It renders an element containment tree for data defined
43
4. Implementation
Figure4.1.:U
ML
Com
ponentD
iagram:The
EditorFram
ework’s
ConceptionalA
rchitecture
44
4.2. Editor Renderer
by a schema. To achieve this, it consumes the analyzedSchema to get the necessaryinformation to render the tree. In order to render the properties of an element selectedin the tree, the TreeRenderer consumes the renderObjectProperties interface of theDetailRendering component. To validate the values of a rendered element’s properties,it uses the validateProperties interface of the Validation component. This componentuses constraint information from the JSON Schema to determine which propertiescontain legal values.
4.2. Editor Renderer
The EditorRenderer component is the entry point for creating an editor for a JSONSchema. It is implemented by one class with the name JsonEditor. This class createsand configures a JsonFormsElement (see subsection 4.4.1) to render the elementcontainment tree according to the configured JSON Schema. The JsonEditor classprovides all methods needed to configure and customize an editor:
con�gure This method allows to configure all possible customizations with a singleconfiguration object. For more details see subsection 4.10.6.
data This property allows to read and set the data currently visualized in the editor.Setting it triggers a re-rendering of the containment tree.
schema This property allows to read and set the JSON Schema describing the editor’sdata. Setting it triggers a re-rendering of the containment tree.
setImageMapping This method allows to set a mapping that configures an icon that isshown for all data elements of a type in the containment tree. For more details seesubsection 4.10.1.
setLabelMapping This method allows to set a mapping that configures which propertyof a data element is used as its label in the containment tree. For more details seesubsection 4.10.2.
setModelMapping This method allows to set a mapping that enables inferring a dataelement’s type from one of its properties. For more details see subsection 4.10.3.
registerDetailSchema This method allows to register a UI Schema (see subsection 4.10.4)for an element type. This UI Schema defines the rendered form of applicable dataelements when they are selected in the containment tree.
registerResource This method allows to register a resource to the editor’s resource set.Registered resources can be used to reference data outside the editor’s data (seesection 4.9).
The JsonEditor manages the correct configuration of these settings in JSONForms2. Consequently, a user of the editor framework does not need to worry how to
45
4. Implementation
do these configurations himself. This leads to an increased usability of the system.Furthermore, providing these customizations contributes to fulfilling the configurabilityquality attribute (QA–1).
Custom Element The JsonEditor is implemented as a HTML Custom Element34. Asthe name suggests, this technology allows to define new HTML elements identified by aunique name. This is done by extending the class HTMLElement of JavaScript’s DOMAPI and registering the class with the element’s name as a custom element. This hasmultiple advantages. A custom element is usable like a normal HTML element. It canaccess the whole DOM API and you can register any type of event listener (e.g. a clicklistener). Furthermore, the custom element can react to lifecycle events, like being addedor removed to respectively from a document. Also, a custom element can be created bysimply creating a HTML tag with the specified name [6].
In our case, this allows to insert a JsonEditor in a web application by simply addinga <json-editor> tag at the desired position. Consequently, the editor framework canbe embedded in other web applications with little effort. This greatly increases theintegratability of our framework and thereby allows us to fulfill quality attribute QA–3.
4.3. Services
The Services component stands for an arbitrary number of services that extend theeditor framework’s functionality. To achieve this, services can use all provided methodsof the editor framework introduced in section 4.2. This allows for flexible addition andremoval of functionality from generated editors, even during their runtime. We selectedthis approach in order to increase the extensibility of our system as required by qualityattribute QA–2.
We provide the following three services ourselves which can optionally be used whenusing a generated editor.
Export Data Dialog This service can be instantiated for any HTMLElement. When theelement is clicked, the service opens a dialog that displays a multi-line text area.This text area contains the editor’s current data as JSON. Furthermore, the dialogcontains a button that allows to copy the serialized data to the user’s clipboard.This service satisfies functional requirement FR–5.
Load Data File This service can be instantiated for any HTMLElement. When theelement is clicked, the service opens a native file open dialog that allows to opena file. Then, the service reads in the file and validates whether it contains validJSON. If yes, the service validates the JSON against the editor’s JSON schema. Ifthe validation is successful, the loaded data is set as the editor’s data. This satisfiesfunctional requirement FR–7.
34https://www.w3.org/TR/2016/WD-custom-elements-20161013/
46
4.4. JsonForms 2
Save Data File This service can be instantiated for any HTMLElement. When theelement is clicked, the service opens a native file save dialog that allows to save theeditor’s current data as a JSON file. This satisfies functional requirement FR–11.
4.4. JsonForms 2
In this section, we describe the JsonForms2 component. It is implemented by the open-source framework JSONForms 235 which is licensed under the MIT license. In order tonot re-invent the wheel and write a property and object rendering framework ourselves,we decided to base the editor generation on JSONForms 2. As already indicated insection 4.1, we use the framework for rendering the element containment tree (see FR–4).Furthermore, JSONForms 2 allows rendering properties of an element. As JSONForms 2did not provide all the functionality we need to fulfill our requirements, we extended itand committed the added functionality to the framework. Consequently, our developedfunctionality also is available as open source software.
To use JSONForms 2 for our framework, we had to make sure that it matches with ourimplementation constraints. JSONForms 2 uses JSON Schema to define the propertiesof rendered elements as well as validation constraints of these properties. Consequently,it is compatible with IC–3 that requires JSON Schema to be used as the data models’definition format. As a consequence, JSONForms 2 is well-suited to edit data in the JSONformat. While it does not offer functionality to import or export JSON per se, it makesthe currently edited data available as a JavaScript object based on the defining JSONSchema. This allows us to simply read the edited data and serialize it to JSON in theEditorRenderer component. Analogous, we can set the edited data after de-serializingit from JSON. As a consequence, we are able to adhere to implementation constraintIC–2 that requires using JSON as the editor’s data input and output format. Finally,JSONForms 2 is implemented in TypeScript. This allows us to contribute our extensionsin TypeScript and access the framework’s methods in a typed way when using it in theEditorRenderer. Therefore, we can fully adhere to implementation constraint IC–1which mandates the editor framework’s implementation using TypeScript.
JSONForms 2 provides two main entries for providing additional functionality withoutediting its source code. First, services can be registered to the framework that interactwith its current state. And second, additional renderers can be added that allowrendering properties of certain types in a custom way. For instance, one could providean email address renderer that allows sending an email by clicking on the address.These mechanisms match well with quality attribute QA–2 “Extensibility”. Furthermore,JSONForms 2 allows registering UI Schemata (see subsection 4.10.4) which define howa data object is rendered. Making this mechanism available in our EditorRenderer
contributes to satisfying quality attribute QA–1 “Configurability”.
35https://github.com/eclipsesource/jsonforms/tree/jsonforms2
47
4. Implementation
4.4.1. Design
In this subsection, we explain the design of JSONForms 2. It is shown as a UML classdiagram in Figure 4.2. The entry point for rendering a data object with JSONForms 2 isthe JsonFormsElement class. It contains the dataObject to render and the dataSchemadefining it.
The JsonFormsElement has an arbitrary number of JsonFormsServices. Theseprovide various functionality that is not related to the rendering process. However,they interact with the rendered form. Currently, JSONForms 2 implements two of theseservices. The ValidationService validates the rendered dataObject’s properties againstthe dataSchema and, if possible, shows the validation status on the rendered controlsof the affected properties. The RuleService evaluates and applies rules defined forrendered controls. Rules are defined in the UI Schema and may be attached to any UISchema element (for a detailed description see subsection 4.10.4). For instance, a rulecould define if a control is shown or hidden based on the value of a specified property.
To access services needed for the actual rendering of its dataObject, the JsonFormsE-lement uses the JsonForms class. It contains static references to these services. TheUISchemaRegistry knows all UI Schemata registered to the JSONForms 2 instance. Itprovides functionality to get the best fitting UI Schema for a given data schema anddata object. Furthermore, if there is no suitable UI Schema registered, it can generate adefault one. The SchemaService fulfills the role of the schema parser. It processes aJSON Schema and makes the results available (see the detailed description in section 4.7).The RendererService knows all different renderers registered to JSON Forms 2. Ac-cordingly, it offers a public method to get the most applicable Renderer for a given UISchema Element describing how to render the data defined by the given JSON Schema.Additionally, the JsonForms class provides access to the resources registered to thesystem via a ResourceSet. This is used for referencing external data (see section 4.9).
The abstract Renderer is the base class for all renderer implementations. Mainly,there exist two types of renderers in JSONForms 2. First, LayoutRenderers do notdirectly display any property but contain further child elements which are renderedaccording to the layout implemented by the renderer. For instance, the simplest of thelayouts is the vertical layout renderer. It renders all contained properties beneath oneanother. Another example is the group layout. It behaves like the vertical layout butadditionally displays a label and a border around the contained elements. The secondmajor type of renderers are PropertyRenderers. A PropertyRenderer usually createsa control with a label for a property of a certain type. The rendered control allowsediting the property’s value in conformity with its type. For instance, JSONForms 2provides a renderer for boolean values that displays them as a checkbox.
Finally, a special Renderer is the TreeMasterDetailRenderer. It renders a hierar-chical containment tree of the data objects contained in the given root data object. Ituses the JsonFormsElement to render the properties of the currently selected element.Furthermore, the SchemaService is used to get the needed information of the rootdata’s structure to render the tree. A more detailed description is given in section 4.5.
48
4.4. JsonForms 2
Figu
re4.
2.:U
ML
Cla
ssD
iagr
am:J
SON
Form
s2
Des
ign
49
4. Implementation
4.4.2. Rendering Process
In this subsection, we describe in more detail how JSONForms 2 renders a data objectdefined by a schema. This is visualized in Figure 4.3. The rendering process is initiatedby a User wanting to render a data object whose structure is defined by a JSON Schema.Thereby, the User can be any system that can execute JavaScript. As a first step, itcreates a new JsonFormsElement and sets its schema and data object in steps two andthree. The latter triggers the rendering process by calling the JsonFormsElement’srender method in step four.
In order to render the data object, the JsonFormsElement needs a UI Schemadescribing the form to render. To get the UI Schema best suited for the JSON Schemadefining the data, the JsonFormsElement calls the findMostApplicableUiSchema methodon the UISchemaRegistry in step five. The UISchemaRegistry then matches the mostapplicable schema. If none can be found, a default UI Schema is generated and returnedin step six.
Next, the JsonFormsElement needs the appropriate renderer for the UI Schema. Tofind the renderer, in step seven, the JsonFormsElement calls the RendererService’sfindMostApplicableRenderer method. It is called for the UI Schema and the configuredJSON Schema and data object from steps two and three. The RendererService deter-mines the best suited renderer. In step eight, it creates a new instance of the rendererand configures it with the parameters gotten in step seven. In this example case, thecreated renderer is a VerticalRenderer which renders a vertical layout. After theVerticalRenderer has been returned back to the JsonFormsElement, the renderer’srender method is called in step nine. After the rendering of the VerticalRenderer isfinished, the rendering process is complete and the form is shown.
The detailed rendering loop of the VerticalRenderer is visualized in Figure 4.4.In essence, this rendering loop is the basis of every layout renderer. To render allelements defined in the UI Schema rendered by the VerticalRenderer, it loops overall sub-elements of the UI Schema. These sub-elements are UI Schemata themselves.Consequently, the rendering process is recursive. In step one, the VerticalRenderer
wants to get the most applicable renderer for the current UI Schema element. Therefore,it calls the RendererService’s findMostApplicableRenderer method. Like before, theRendererService determines the best renderer and creates a new instance in step two.Subsequently, it configures the created Renderer instance with the current UI Schemaelement, the data object, and the JSON Schema in step three. Afterwards, the rendereris returned to the VerticalRenderer which then calls the render method in step four.Finally, the loop restarts with the next UI Schema element as long as another one ispresent.
50
4.4. JsonForms 2
Figu
re4.
3.:U
ML
Sequ
ence
Dia
gram
:Jso
nFo
rms
2R
ende
ring
Proc
ess
51
4. Implementation
Figure 4.4.: UML Sequence Diagram: Rendering Loop
52
4.5. Tree Renderer
4.5. Tree Renderer
The TreeRenderer component is responsible for rendering the element containmenttree of the data elements present in the editor’s data. It is implemented by the TreeMas-terDetailRenderer class and an additional module which provides drag and dropfunctionality (see subsection 4.5.1). The rendering of the tree is conducted by expandingthe editor’s data recursively by executing the following steps starting at the root dataobject.
1. Create a new list element for the current data object. Set its icon and label basedon the editor’s configured image- and label mappings (see 4.10.1 and 4.10.2).
2. Retrieve all ContainmentProperties (see 4.7.1) from the SchemaService basedon the schema describing the current data object.
3. Create the corresponding child lists based on these properties and configure anadd a button which allows to add new data objects. The createable elements aredefined by the current object’s containment properties.
4. Create a delete button that allows to remove the current list item and its associateddata object from the containment tree respectively the containing data object.When the current element is removed, all its child elements are deleted, too.
5. Render the current data object’s child objects in their corresponding list. This isdone by recursively executing this algorithm for every one of the child objects withtheir corresponding parent list as a parameter.
6. Add the created list element to the given parent list.
As indicated above, the add button of a tree element only allows to create new childelements which are specified by the tree element’s containment properties. Consequently,the editor only allows to create new elements which are legal children of the parentelement. This fulfills the functional requirement FR–2. The delete button fulfillsthe functional requirement FR–10. When a tree element is selected by the user, theTreeMasterDetailRenderer creates a new JsonFormsElement to create a detail viewwith the element’s properties.
The tree was implemented in plain HTML5 without additional frameworks for bindingthe tree elements to the data objects or creating the tree itself. This was done to keep thetree independent of the development of other frameworks. The reason for this is thatthe tree is intended as a component with a long life cycle. Therefore, the dependencyon the development of foreign frameworks should be as low as possible. Furthermore,this allows extending the tree’s functionality without being limited by the APIs of usedframeworks. This concurs with our extensibility quality attribute QA–2.
53
4. Implementation
4.5.1. Drag and Drop
The goal of implementing drag and drop in the tree is to allow moving elements of thecontainment tree to new valid locations. This includes three aspects. First, the orderof elements inside one containment list can be rearranged. Second, a tree element canbe moved to a new parent. Thereby, it must be guaranteed that the new containmentcan contain the moved element. Third, when a tree element is moved successfully, theeditor’s data must be adapted to match the tree’s structure. Implementing this behaviorallows us to fulfill functional requirement FR–1.
The main challenge to implement the aforementioned functionality is to determinewhether a dragged tree element can be dropped at the current target location. AsJavaScript is a dynamically typed language, the type of a tree element’s data objectcannot be inferred easily during runtime. However, a tree node needs to know the typeof its data to determine where it can be dropped in the containment tree. To achieve this,we keep a map in the TreeRenderer that maps from a tree element to an informationobject which contains the tree element’s represented data, the schema describing thisdata, and a function to delete the data from the model. Keeping this mapping for everyelement contained in the tree allows us to access a dragged element’s data and type. Thesecond part of identifying whether a containment list is a valid target is to determinewhether the list is compatible with the tree element data’s type. To achieve this, weannotate every list with the schema ids which identify the types of possible containeddata objects. When a tree element is dropped at a containment list, the element’s schemais retrieved from the map and matched with the list’s allowed ids. If the drop is allowed,the element is added to the list and the corresponding data object is moved.
To not re-invent the wheel, we use the open-source framework Sortable36. Theframework is actively maintained, is built with HTML5’s native drag and drop API,and provides many customization options including registering custom handlers forvarious drag and drop events. Furthermore, the framework integrates well with ourimplementation of the containment tree. The framework works list-based and dragand drop is configured for a list which activates drag and drop for all of its children.Furthermore, the framework allows exchanging elements between multiple lists thatwere configured with the framework. Consequently, we can provide drag and drop forthe whole tree by configuring it for every containment list in the tree. Additionally, weconfigure custom handlers which react to the dragging and dropping of tree elements.Thereby, these handlers validate that a tree element can only be dropped at a legal targetwith the mechanism described in the previous paragraph. When a legal drop occurs,the framework handles moving the tree element to the new list. The custom handlersthen add the tree element’s associated data to the containment represented by the newlist and use the delete function to remove the data from its old parent. In conclusion,Sortable provides the drag and drop functionality itself while we handle that elementscan only be dropped at legal locations as well as moving the underlying model data.
36https://github.com/RubaXa/Sortable
54
4.6. Detail Rendering
4.6. Detail Rendering
The DetailRendering component is responsible for rendering data elements which areselected in the element containment tree. The component is implemented by recursivelyusing the JsonFormsElement class (see Figure 4.2). Thereby, the JsonFormsElement isconfigured with the data element currently selected in the tree and the JSON Schemadescribing the element’s type. When rendering a data element, the JsonFormsElement
uses a registered UI Schema fitting for the schema defining the data. Therefore, therendered properties view can be configured. As already indicated in subsection 4.4.1,JSONForms 2 provides various renderers to render properties according to their type.Examples are a boolean renderer that displays boolean values as a checkbox, an enumrenderer which provides a combo box with the possible values, or a text rendererwhich shows a text field. Consequently, the implementation of the DetailRendering
component allows to edit properties in controls suitable to their types. As a result, itsatisfies the functional requirements FR–3 and FR–12.
Limitations While there is no conceptual limitation in JSONForms 2 which features ofJSON Schema could be rendered, not every case is covered by a sophisticated renderer.There is a basic renderer that can render any property in a simple text field if a Controlspecifies the property in the UI Schema. However, this does not allow proper editing ofnon-string properties. Therefore, we do not count this as providing proper rendering.The following JSON Schema features are not properly rendered:
• Any property definition using the keywords anyOf, allOf, not, or oneOf
• Properties whose type is provided as an array instead of a single type.
• Enums whose enumerated values are of multiple different types
• Enums with non-primitive values
• Arrays whose items are tuples
• Arrays of primitive values
4.7. Parser
The Parser component is responsible for providing functionality related to analyzingJSON Schemata. Thereby, the Parser must provide the following functionality:
• Get contained data objects of the analyzed type
• Get references of the analyzed type
• Get self-contained sub-schemata types defined in the editor’s root schema
55
4. Implementation
Figure 4.5.: UML Class Diagram: Schema Service and Properties
This functionality must be easily accessible for all data types defined in the editor’sroot schema. Additionally, the functionality should be accessible independent of eachother and return easily usable results that do not need traversing big data structures.Furthermore, the Parser component should provide good testability and extensibility.The latter is important because additional information might need extraction in thefuture.
Based on these design decisions, we implement the Parser component as a lightweightSchemaService which is globally accessible. The class diagram in Figure 4.5 showsthe design of the SchemaService and its associated classes. We explain them and theiroffered functionality in the following paragraphs.
SchemaService. The SchemaService is the central class providing the functionalityof the Parser component. It is initialized with the editor’s root data schema. Thisschema is needed to create self-contained schemata by resolving local references in sub-schemata against the root schema. The detailed algorithm is described in subsection 4.7.2.Schemata that have been self-contained are cached in selfContainedSchemas. Thereby, themap’s keys are schema IDs and the values the schemata.
The SchemaService’s three property-related methods are used to analyze a givenschema. Thereby, only the needed information is extracted. This allows requestingproperties for single data types defined in the root schema on-demand. The result istailored to the given data type instead of the editor’s complete schema. This provides
56
4.7. Parser
simple results without a need to traverse them for the needed information. Furthermore,clear separation of the different properties allows testing each function separately. Thisvastly improves the SchemaService’s testability compared to an approach that analyzesthe whole schema at once and returns one data structure with all properties. Anotheradvantage of the modular approach for different properties is increased extensibility. Ifthe need for extracting further properties arises, we can simply add another method tothe SchemaService without needing to change the existing code.
The getContainmentProperties method returns an array of all ContainmentProperties
directly contained in the type defined by the given schema. Correspondingly, thehasContainmentProperties returns whether the type has any ContainmentProperties.A detailed explanation how these properties are collected is given in subsection 4.7.1.The getReferenceProperties method returns an array of all ReferenceProperties directlycontained in the type defined by the given schema. Therefore, the given schema’s linksblock (see 4.9.1) is analyzed. If it is present, a ReferenceProperty is created for everyentry. If an entry fulfills the requirements for ID-based referencing (see 4.9.3), the createdReferenceProperty uses this reference technique. Otherwise path-based referencing isused (see 4.9.4).
Property. Property defines the basic attributes of a data type’s property. The label is aname describing the Property. The property attribute defines the key that contains theProperty’s content in an instance. The schema is the JSON Schema defining the datawhich the Property may contain. A property described by an instance of Property orone of its subclasses is independent of an actual data object containing the property.Therefore, to execute methods based on a Property, the affected data object has to beprovided.
ContainmentProperty. A ContainmentProperty describes a property that containsan array of non-primitive data objects. Concretely, this means that a schema describ-ing one data object contained in a ContainmentProperty must be of type “object”.The schema property of an instantiated ContainmentProperty contains the schemadescribing one data object contained in the containment. For all three methods definedby the ContainmentProperty, the data parameter is the data object which contains thecontainment defined by the ContainmentProperty. The addToData method allows toadd the given valueToAdd to the containment. The deleteFromData method removes thegiven valueToDelete from the containment. The getData method returns all data containedin the containment.
ReferenceProperty. A ReferenceProperty describes a property whose value refer-ences another data object. Thereby, the data object is not contained in the property butthe property only saves a value that allows to resolve this data object. The implementedreference mechanism and its two implementations are described in section 4.9. Similarlyto the ContainmentProperty, the data parameter is the data object which contains the
57
4. Implementation
ReferenceProperty. The getData method returns a map with the reference values askeys and the resolved data objects as values. The addToData method adds valueToAddto the property. In case of path-based referencing (see 4.9.4) this must be a path. ForID-based referencing (see 4.9.3), this is the referenced data object itself. Whether theproperty uses ID- or path-based referencing is returned by isIdBased. The findReferenc-eTargets method returns a map which contains all data objects that can be referencedby this ReferenceProperty. Thereby, the map’s keys are the reference values (IDs orpaths) and the values the actual data objects.
4.7.1. Retrieve Containment Properties
To retrieve the ContainmentProperties of a given schema, a recursive algorithm isused. The pseudocode describing this algorithm is shown in Listing 4.1. First wedescribe the parameters of the getContainment method:
key The key that contains the contents of the ContainmentProperty. This is the sameas the property of the same name of the Property class.
name The name of the ContainmentProperty
schema The schema currently analyzed for ContainmentProperties. Because thealgorithm works recursively, a differentiation between the current schema and thealgorithm’s root schema is needed.
rootSchema The root schema whose ContainmentProperties are retrieved. This is thesame schema that a client provides to the public getContainmentProperties method.Note: This is not the same as the rootSchema attribute of the SchemaService.
isInContainment A boolean value stating whether the current schema is describing thetype of a containment.
addFunction A function that allows to add a data object to a containment described bythe ContainmentProperty.
deleteFunction A function that allows to remove a data object from a containmentdescribed by the created ContainmentProperty.
getFunction A function that allows to get the contents of a containment described bythe created ContainmentProperty.
internal A boolean value stating whether the current function call analyzes a schemainside the properties definition ot the analyzed root schema. If this is the case, theproperties of the current schema are not resolved because we only want Contain-mentProperties directly contained in the analyzed root schema. Furthermore,this check is necessary to avoid running into an endless loop in case cascadedproperties definitions reference the root schema.
58
4.7. Parser
1 ContainmentProperty[] getContainmentProperties(schema) {2 return getContainment(’root’, ’root’, schema, schema, false, null, null, null, false);3 }4
5 ContainmentProperty[] getContainment(key, name, schema, rootSchema, isInContainment,addFunction, deleteFunction, getFunction, internal) {
6 if schema.$ref exists7 resolvedSchema = getSelfContainedSchema(rootSchema, schema.$ref)8 name = last segment of schema.$ref9 return getContainment(key, name, resolvedSchema, rootSchema, isInContainment, addFunction,
deleteFunction, getFunction, internal)10
11 if schema is of type ’object’12 if isInContainment is true13 property = create new ContainmentProperty configured with key, name, and the given
functions14 return [property]15 if internal is true16 return []17
18 result = []19 for propKey in schema.properties.keys20 childSchema = schema.properties[key]21 properties = getContainment(propKey, propKey, childSchema, rootSchema, false,
addFunction, deleteFunction, getFunction, true)22 append properties to result23 return result24
25 if schema is of type ’array’ and schema.items is not of type ’array’26 add = getAddToArrayFunction(key)27 delete = getDeleteFromArrayFunction(key)28 get = getArray(key)29 return getContainment(key, name, schema.items, rootSchema, true, add, delete, get, internal)30
31 if schema.anyOf exists32 result = []33 for childSchema in schema.anyOf34 prop = getContainment(key, undefined, childSchema, rootSchema, isInContainment,
addFunction, deleteFunction, getFunction, internal)35 append prop to result36 return result37
38 return []39 }
Listing 4.1: Algorithm to Collect Reference Properties
59
4. Implementation
We chose the approach of providing the functions to a created ContainmentProperty
to achieve increased extensibility (see QA-2). With this approach, when adding anadditional schema structure that results in a ContainmentProperty, we only need toadd another IF-case to the recursive function and configure the needed functions. Con-sequently, we would not need to change the ContainmentProperty’s implementation.In the following paragraphs we explain how the algorithms works by describing how ithandles different types of schemata.
If the current schema is a reference, the reference is resolved and self-containedby using the SchemaService’s getSelfContainedSchema method (line 7). The potentialcontainment property name is set as the last segment of the reference (line 8). Finally,the ContainmentProperties for the resolved schema are retrieved (line 9).
If the schema describes an object, it might describe the content of a Containment-Property (line 11). If the current schema is part of a containment, create a newContainmentProperty configured with the algorithm’s parameters (lines 12 to 13).Return the created property encapsulated in an array (line 14). If internal is true but weare not in a containment, we are in a loop. Return an empty array to avoid an endlessloop (lines 15 to 16). Otherwise, create a new empty result array and iterate over allproperties of the schema. For every property, get the schema describing its content (line20) and recursively retrieve its ContainmentProperties. Thereby, set internal to true.Append the returned properties to the result array (line 22). Finally, return the resultarray (line 23).
If the schema describes an array and the array’s contents are not tuples, the schemamight describe a containment (line 25). Therefore, the functions are configured to add,delete, and get data from an array (lines 26 to 28). The ContainmentProperties arerecursively resolved for the schema describing the array’s items. Thereby, the configuredfunctions are passed as a parameter and isInContainment is set to true (line 29).
If the schema contains the anyOf keyword, it describes that the possible containmentcan contain any of its child schemata (line 31). Therefore, the ContainmentProperties
are recursively retrieved for each child schemata on its own (lines 33 to 34). The resultsare merged and returned (lines 32, 35, and 36).
If none of the above cases match, schema neither describes nor could contain anyContainmentProperties. For instance, this is the case if schema defines a primitivetype (e.g. number or string). In this case, an empty array is returned (line 38).
Limitations The algorithm currently cannot handle the JSON Schema keywords oneOf,allOf, or not. Furthermore, references whose root is not the given rootSchema cannot beresolved. However, non-circular remote references should already be resolved when theirreference properties are requested (see 4.7.3). Another limitation is that containmentarrays whose item type is a tuple, are not supported.
60
4.7. Parser
1 void selfContainSchema(schema, outerSchema, outerRef, includedDefs) {2 allInnerRefs = find all references in schema3 for innerRef in allInnerRefs4 resolvedSchema = resolve innerRef in rootSchema5 if innerRef is equal outerRef or resolvedSchema.id is equal schema.id6 set innerRef to ’#’7
8 if includedDefs contains innerRef9 continue
10
11 if resolvedSchema.anyOf exists12 for innerSchema in resolved.anyOf13 copyAndResolveInner(innerSchema, innerRef, outerSchema, outerRef, includedDefs)14 else15 copyAndResolveInner(resolvedSchema, innerRef, outerSchema, outerRef, includedDefs)16 }17
18 void copyAndResolveInner(resolvedSchema, innerRef, outerSchema, outerRef, includedDefs) {19 definition = deepCopy resolvedSchema20 defName = last path segment in innerRef21 outerSchema.definitions[defName] = definition22 add innerRef to includedDefs23 selfContainSchema(definition, outerSchema, outerRef, includedDefs)24 }
Listing 4.2: Algorithm to Self Contain a Schema
61
4. Implementation
4.7.2. Self Contain a Schema
When a schema defining a data type contains circular references to other type definitions,they cannot be resolved by the mechanism explained in subsection 4.7.3. If the schema isneeded on its own, outside of the root schema, these references need to stay resolvable.Therefore, the referenced definitions (which are schemata themselves) must be copied tothe schema’s definitions block. Thereby, the references in these copied schemata mustbe resolvable, too.
When the getSelfContainedSchema method of the SchemaService is called, first theschema is resolved from the given parentSchema with the given refPath. If the resultingschema has already been self contained before, it is returned from the SchemaService’sselfContainedSchemas map. Otherwise, we need to self-contain the schema. This is doneby calling the selfContainSchema method shown as pseudocode in Listing 4.2.
First, we introduce the parameters of the selfContainSchema method. schema is theschema whose references we process in the current function call. outerSchema is theschema that will be self-contained in the end. We add needed definitions to this schema.outerRef is the reference which is considered to be a self-reference in the self-containedouterSchema. includedDefs is the list of definitions already added to the outerSchema. Bydefault this is initialized with ’#’ which means the root of a schema. When we firstcall selfContainSchema from getSelfContainedSchema, we initialize schema and outerSchemaboth with the schema we want to self-contain. outerRef is initialized with pathRef andincludedDefs with the default value.
The algorithm works in the following way. First, get all references inside the currentschema (line 2). Iterate over all inner references and execute the following steps forevery reference. First, get the referenced schema by resolving the innerRef against theSchemaService’s rootSchema (line 4). If the innerRef references the outerSchema, replaceit with the self reference (lines 5 and 6). If the included definitions already include theinnerRef, we do not need to execute additional steps because we already added it to theouterSchema’s definitions. We continue with the next reference (lines 8 and 9). Otherwise,we need to replace self-references and add required definitions of the referenced schemabefore adding it to the outerSchema’s definitions. In case the referenced schema containsthe anyOf keyword, all of its child schemata are processed separately (lines 11 to 13).Otherwise, the referenced schema can be processed directly (lines 14 to 15).
To process a schema, the copyAndResolveInner is called. First, it copies the schema andextracts the schema’s name from the innerRef that references it (lines 19 and 20). Now,the copied schema is added to the outerSchema’s definitions block and the innerRefadded to the included definitions. Finally, the selfContainSchema method is recursivelycalled with the definition as the current schema (line 24). This is necessary to addrequired definitions referenced in the current definition to the outer schema we want toself-contain.
Limitation The self-contain algorithm can only handle local references defined inJSON Pointer format. Thereby, the root of the pointers before the self-containment must
62
4.8. Validation
be the SchemaService’s rootSchema. After the self-containing process is finished, theroot of the references is the self-contained schema.
4.7.3. Reference Resolving in Schemata
In order to allow to define data using multiple schemata as well as reusing datadefinitions inside a schema, we support referencing inside and outside a schema.Therefore, we resolve the schema’s JSON References37 and JSON Pointers38 beforesetting it as the SchemaService’s root schema. To reference another schema, the $refproperty is used instead of defining the schema inline. To load a remote schema, a URIusing the HTTP protocol can be used. For local references, JSON Pointers are used.Thereby, the path is specified starting from the root of the local schema.
To not re-invent the wheel, we use the open-source library json-refs39 to resolve thereferences. When a reference is resolved, the target schema is copied and replaces thereference in the in-memory version of the loaded schema. This adheres to the JSONReference draft and allows simpler processing of the schema later on because resolvedreferences do not need to be loaded again.
Limitations Our approach cannot resolve circular references. In case of a circularreference, the reference is not resolved and left in the schema unchanged. For localreferences, this does not pose any limitation as they can be resolved on-demand whencreating containment properties or reference properties, or self-containing a schema.However, this is not the case for unresolved remote references. Therefore, schematawith circular remote references are not supported. This includes references to a remoteschema which only has circles inside the remote schema.
4.8. Validation
The Validation component is responsible for validating the properties of a data el-ement against the schema defining the data. The component is implemented by theValidationService class in JSONForms 2. This service was already implemented inJSONForms 2. It is used to fulfill the two functional requirements demanding propertyvalidation (FR–8) and the automatic execution thereof (FR–13).
To validate the properties and display the errors, the ValidationService is instanti-ated with the UI Schema defining the form and the JSON Schema defining valid data.Such a UI Schema is always available even if none was registered by the user. This is thecase because one is generated in case non is available (see subsection 4.4.2). Wheneverthe data of the form changes, the validation is executed in the following three steps.
37https://tools.ietf.org/html/draft-pbryan-zyp-json-ref-0338https://tools.ietf.org/html/rfc690139https://github.com/whitlockjc/json-refs
63
4. Implementation
1. The data element is validated against the schema. Thereby, the data element’sproperties are validated against restrictions defined in the schema for correspond-ing properties. For instance, this validates whether required properties are set,numbers adhere to specified minimum and maximum values, or a string propertyadheres to a required regular expression.
2. Detected errors are recorded and mapped to the UI Schema elements whichrepresent the erroneous properties.
3. Affected UI Schema elements are notified about their errors in order to display asuitable error message at the control rendering the affected property.
4.9. References
Defining references between data objects is an important part of creating data. Thisis the case because data rarely exists in a vacuum. Instead, it often is distributed overmultiple models. A simple example for this is having a model containing studentsand one containing lectures. We want to associate every student with the lectures heis interested in. To achieve this, for every student we reference these lectures. Withoutreferences, we would need to copy every lecture definition to every student that isinterested in it. This would lead to a lot of code duplication. And even if the the studentand lecture data was part of a single model, we still needed references to avoid copyinglecture data to multiple students interested in the same lecture. Consequently, referencesto other data inside and outside a model are an integral part of defining data models.
When defining a reference mechanism for the editor framework, we identified thefollowing aspects we must address.
(1) How to specify valid reference targets?
We define the valid reference targets in the JSON Schema which describes the datamodeled in the editor. Therefore, we introduce a new property for JSON Schemata insubsection 4.9.1. This definition is resolved depending on the used reference technique.
(2) How to serialize and resolve a reference?
For this, mainly two possibilities exist: Saving the reference as a unique ID that identifiesthe referenced data or saving a path to the referenced data object. We explore bothpossibilities in subsections 4.9.3 and 4.9.4.
(3) How to guarantee that a user may only reference valid targets?
This is solved by providing renderers that limit the selection to valid reference targets.For instance by presenting them in a combo box.
(4) How to validate that an existing reference resolves to a valid target?
As this depends on the implemented reference technique, this is explained in thecorresponding subsections 4.9.3 and 4.9.4.
64
4.9. References
4.9.1. Links
We use a links definition block to define references in a JSON Schema. This links blockis specified based on the links property and the Link Description Objects of the JSONHyper-Schema internet draft40. The links block consists of an arbitrary number of LinkDefinition Objects. For the Link Definition Objects we use two properties defined in theHyper-Schema: href and targetSchema.
href The href property contains a URI template. We limit it to the following format:<path-to-ref-targets>{<reference-property>}. <reference-property> is the nameof the property which contains the serialized reference value. <path-to-ref-targets>describes how to find the root data that contains possible reference targets. Currently,we support two kinds of locations: Local data in the current model and data registeredin a resource set. In the first case, the path can be empty to select the whole currentmodel including the root itself or start with a “#”. To reference data contained ina registered resource we defined a new protocol. It follows the following format:rs://<resource-name>/<local-path-in-resource>. Thereby, <resource-name> is thename under which the resource was registered to the editor. <local-path-in-resource>is an optional JSON Pointer that defines the reference target root inside the resource.If <local-path-in-resource> is empty, the whole resource itself is the reference targetroot.
targetSchema The targetSchema property contains a JSON Schema that restricts whichdata objects found in the reference target root are valid reference targets. Additionallyto specifying the schema inline or referencing it with a JSON Reference, we allow toload it from a registered resource, too. To accomplish this, we introduced the resourceproperty. If the targetSchema contains this property, the property’s value is interpreted asa resource name. The resource is loaded and used in place of the targetSchema.
Example In order to illustrate the usage of the specification above, Listing 4.3 shows aJSON Schema with two reference definitions. Lines 3 to 6 show the property definitionsfor the object described by the schema. Lines 7 to 18 shows a links block with tworeference definitions. The href property in line 9 defines two things. First, the referencetargets are contained in the root of the instance’s current data. Second, the reference’sserialization is stored in the localRef property defined in line 4. The targetSchema propertyin line 10 contains an inline schema definition. It states that valid reference targets mustbe of type string.The second reference definition uses resources. The href property in line 13 defines thatthe reference targets are contained in a registered resource of name “data”. This includesthe root data object itself. The serialized reference value is stored in the resourceRef
40http://json-schema.org/latest/json-schema-hypermedia.html
65
4. Implementation
1 {2 "type": "object",3 "properties": {4 "localRef": { "type": "string" },5 "resourceRef": { "type": "string" }6 },7 "links": [8 {9 "href": "#/{localRef}",
10 "targetSchema": { "type": "string" }11 },12 {13 "href": "rs://data/{resourceRef}",14 "targetSchema": {15 "resource": "personSchema"16 }17 }18 ]19 }
Listing 4.3: JSON Schema with Example Declaration of a Links Block with TwoReference Definitions
Figure 4.6.: UML Class Diagram: Resource Set Interface
property defined in line 5. The targetSchema references a schema in the registeredresource of name “personSchema” by using our newly introduced resource keyword.
Limitations The first limitation of the current implementation is the possible referencetargets. Currently, only local and resource-based referencing is possible. Anothercommon resource location are web-based targets specified via the HTTP protocol. Thiswould allow loading static resources as well as requesting data from a web service byusing the reference property as a parameter. The second limitation lies in the possibletarget Schemata. They must be fully resolvable. This means, they cannot contain anycircular references.
4.9.2. Resource Set
To allow registering resources to the editor, we implemented a resource set mechanismin JSON Forms. Thereby, the JsonForms class contains one resource set as a static
66
4.9. References
variable. A resource can be any data object. The resource set’s interface is shown inFigure 4.6. It provides methods to check whether a registered resource exists, to get aresource by providing its name, and to register a resource for a given name. By settingthe resolveReferences parameter of the registerResource method to true, the ResourceSet
is instructed to resolve JSON references inside the resource. Our implementation of theResourceSet simply stores the registered resources in a map that maps from a resource’sname to its content. Future implementations could be extended by a mechanism toregister resources by providing a URI instead of the data itself. This would allow toaccess a multitude of different data sources using a unified interface. Furthermore, thiscould be used to load the data on demand. In case of big data objects, this decreases theeditor’s memory consumption.
4.9.3. ID-based References
The first of our two implemented referencing techniques is ID-based referencing. Themain idea is to identify a referenced data object by a unique id. This ID is stored inthe reference property and allows to later resolve the referenced data object. UsingIDs has two main challenges. First, we need to know which property of potentialreference targets contains the id. For this, two possible solutions exist. Either providingthe identifying property in a reference definition alongside the href and targetSchemaproperties or configuring it externally. We decided on the latter for the following reasons.First, the links standard introduced in subsection 4.9.1 does not define such a property.Second, to guarantee unique ids, often a property independent of the rest of the dataobject is used. This property typically contains a generated id. Third, using a globallyconfigured identifying property simplifies generating unique ids for data objects createdin the editor.
The second challenge is that a reference target must contain a unique ID to allowreferencing it. One aspect of this is that JSON objects do not have any type information.Type information is only available by associating them with a schema. To ensure thatreference targets have an ID, the targetSchema of an ID-based reference must define theconfigured identifying property as one of its properties. In order to reliably get uniqueIDs for data objects created in the editor, we provide an ID generation mechanism. Whena global identifying property is configured, the editor generates a new ID for everycreated data object. To get unique IDs (with near certainty) we generate universallyunique identifiers (UUIDs). Consequently, when referencing data created in the editor,the presence of unique IDs does not pose a problem.
To resolve a reference serialized as an ID, two steps are executed. First, all possiblereference targets are retrieved by resolving all data objects at the target location specifiedin the href property (see subsection 4.9.1). Second, the data object containing theserialized ID in the identifying property is the reference target. Validating whether areference is valid can be determined in the same way. First, try to resolve the reference.If no data object is returned, no valid reference target with the provided ID exists andthe reference is invalid. Otherwise, it is valid.
67
4. Implementation
Limitations Our prototypical implementation of ID-based referencing has the fol-lowing limitations. As indicated above, data objects need to contain a unique ID toallow referencing them. On-the-fly generation of IDs for otherwise valid targets is notprovided. However, this could be introduced retroactively. The second limitation isrelated to the search for possible reference targets. The current implementation onlyevaluates targets at the exact location specified in the href property. No recursive searchof elements deeper in the containment hierarchy is done. Finally, a targetSchema used todefine an ID-based reference must adhere to the following limitations. It must have anid identifying the type represented by the schema. It must not use any of the followingJSON Schema keywords: anyOf, allOf, oneOf, not.
To use ID-based referencing, a custom renderer must be provided to render thereference property. We implemented an abstract base control providing the referencefunctionality. When implementing a concrete renderer based on the abstract base, onlyone method needs to be overwritten which returns the name of a label property forreference targets offered by the control. The label property’s content of a reference targetis used as its name when displaying it in the control.
4.9.4. Path-based References
The second reference technique we implemented is path-based referencing. The ideais to reference a data object by storing its location as a path relative to the root of thereference targets. This path is stored in the reference property. To resolve a referencetarget, two steps are executed. First, the root of the reference targets is resolved byresolving the URI given in the reference configuration’s href property like described insubsection 4.9.1. In the second step, the stored path is resolved against this root data. Ifthe path is resolvable, the referenced data is returned.
The main challenge for this approach is collecting all possible reference targets. Theresult is collected as a map. The result map contains the reference paths as keys and thecorresponding target data as values. To do this, we first resolve the reference target root.Starting from there, we recursively search all contained properties and array entries. Therecursive search algorithm is shown as pseudocode in Listing 4.4. We record the currentpath relative to the target root in every step. To determine if the currently analyzed dataobject is a valid reference target, we validate it against the targetSchema. If the validationsucceeds, a new entry is added to the result map. Afterwards, we check if the currentdata is an array or a map. In both cases, we iterate over the children and recursively callthe search algorithm for them. The results of these calls are merged into the result map.Finally, the result map is returned.
To validate whether a reference property contains a valid path, the map of all referencetargets can be gathered. If this map contains the reference path as a key, a valid target isreferenced.
Limitations One important drawback of path-based referencing is that references arenot robust when the reference goes over an array. Because the reference path must
68
4.10. Customization
1 Map<string, any> collectionHelperMap(currentPath, data, targetSchema) {2 result = new Map<string, any>()3 if data validates against targetSchema4 result[currentPath] = data5
6 if data is an array7 for (i = 0; i <= data.length; i++)8 childPath = currentPath is empty ? key : currentPath + ’/’ + i9 childResult = collectionHelperMap(childPath, data[i], targetSchema)
10 result = merge childResult into result11 else if data is a Map and not empty12 for key in data.keys13 childPath = currentPath is empty ? key : currentPath + ’/’ + key14 childResult = collectionHelperMap(childPath, data[key], targetSchema)15 result = merge childResult into result16
17 return result18 }
Listing 4.4: Algorithm to Collect Reference Targets from a Given Root Data
contain a specific index to reference the content of an array, the resolution might deliveran unexpected result when the sorting of the array changes. This is the case becausethe data object at the referenced index might be swapped with another one. As long asthe new data object is a valid reference target according to the targetSchema, this changecannot be detected.
The second limitation applies to the reference target root. It should not contain anyunresolved JSON References because the current implementation of the search algorithm(see Listing 4.4) does not resolve them. If the target data is contained in a resource,non-circular references can be resolved when adding the data to the resource set (seesubsection 4.9.2).
To use path-based referencing, a UI Schema must be provided for the type of thedata object containing the reference property. Thereby, a ControlElement must beconfigured for the reference property. To mark the property to be rendered as a path-based reference, an option must be added to the ControlElement. The key of theoption is reference-control and the value path. This allows our path renderer to recognizethe property as a reference.
69
4. Implementation
EditorRenderer
TreeRenderer
DetailRendering
ParserJSON
Schema
Services
ModelMapping
ImageMapping
LabelMapping
UISchemata
Editor Generation FrameworkConfiguration & Customizations
configures usesLegend:
Figure 4.7.: Overview over the Editor Framework’s Configurations and Customizations
70
4.10. Customization
4.10. Customization
In this section, we describe the customization options of the editor framework in detail.An overview over the relationship between the editor framework’s customizations andconfigurations is shown in Figure 4.7. As already discussed in previous sections, theJSON Schema configures the data editable in the editor and is analyzed by the Parser(see section 4.7). Likewise, services customize the editor’s behavior by accessing theeditor renderer (see section 4.3). As these configurations have already been discussed indetail, we will not elaborate on them any further in this section. The image mapping,label mapping, and model mapping customize the containment tree created by theTreeRenderer component (see section 4.5). Multiple UI Schemata are used to configurethe rendering of data elements which are selected in the containment tree. Thereby, theform for every data type is defined in a separate UI Schema.
In order to explain the configuration options and concretely show how an editor canbe configured with them, we define a small sample schema in Listing 4.5. Based onthis, we define suitable example mappings and UI Schemata in the following sections inaddition to their general descriptions.
4.10.1. Image Mapping
The image mapping allows to define a CSS class for every type definition in the editor’sJSON Schema. The CSS class of a type is used by the TreeRenderer to display an iconfor the type’s instances in the element containment tree. Therefore, the icons have tobe linked in the configured CSS classes. Thereby, the type is specified as the id of the(sub-)schema defining it.
An image mapping for the example schema in Listing 4.5 is defined in lines 1 to 5 ofListing 4.6. The listing associates a CSS class to each of the schema’s data types in lines2 to 4. In lines 8 to 10, we specify the corresponding CSS classes and load a local imagein each one. As these classes will be used by the TreeRenderer, the loaded icons areshown for instances of the types.
1 {2 "#mammal": "mammal",3 "#insect": "insect",4 "#petperson": "person"5 }6
7 // CSS8 .mammal { background−image: url(’./Mammal.gif’); }9 .insect { background−image: url(’./Insect.gif’); }
10 .person { background−image: url(’./Person.gif’); }
Listing 4.6: Sample Image Mapping
71
4. Implementation
1 {2 "definitions": {3 "mammal": {4 "id": "#mammal",5 "properties": {6 "name": { "type": "string" },7 "species": { "type": "string", "enum": ["cat", "dog"] },8 "sex": { "type": "string", "enum": ["male", "female"] },9 "pregnant": { "type": "boolean", "default": false }
10 }11 },12 "insect": {13 "id": "#insect",14 "properties": {15 "name": { "type": "string" },16 "species": { "type": "string", "enum": ["praying mantis", "spider"]}17 }18 }19 },20 "id": "#petperson",21 "properties": {22 "fullName": { "type": "string" },23 "pets": {24 "type": "object",25 "items": {26 "anyOf": [27 { "$ref": "#/definitions/mammal" },28 { "$ref": "#/definitions/insect" }29 ]30 }31 }32 }33 }
Listing 4.5: Customization Example JSON Schema
72
4.10. Customization
4.10.2. Label Mapping
The label mapping allows to define an eponymous property for every type definition inthe editor’s JSON Schema. The content of this property is used by the TreeRenderer todetermine the label shown for a data element in the element containment tree. Thereby,the type is specified as the id of the (sub-)schema defining it.
Listing 4.7 configures a label mapping for the JSON Schema shown in Listing 4.5. Formammals and insects, the content of their name property will be used as their labels inthe containment tree. For pet-persons, the fullName property is used.
1 {2 "#mammal": "name",3 "#insect": "name",4 "#petperson": "fullName"5 }
Listing 4.7: Sample Label Mapping
Improvements. Future improvements of this mapping could allow to specify a functionthat assembles a data element’s label. This would allow to use more than one property,define static parts of the label, and define default labels in case the required propertiesare not set.
4.10.3. Model Mapping
The model mapping is used to determine the type of a data element that is part of acontainment property (see 4.7.1) which can contain multiple different types by usingJSON Schema’s anyOf keyword. This is necessary because of two characteristics ofJSON coming together when using anyOf to allow multiple types in a property. First,JSON data is not typed in itself. Consequently, the associated type definition can not beinferred unambiguously from a JSON data object. Normally, this is not a problem forthe editor because it can infer the type based on the property that the data is containedin. However, when this fact is combined with allowing multiple types in a property, thetype identification is not possible anymore.
As a consequence, we need a mechanism to infer the type from the data through othermeans. We use the model mapping that infers the type based on a property in the data.The model mapping specifies the name of a property that contains a value identifyingthe type of a data object. Additionally, it contains a mapping that maps from valuescontained in this property to the type defining the data. Thereby, the type is specified asthe id of the (sub-)schema defining it.
Listing 4.8 configures a model mapping for the sample schema shown in Listing 4.5.We configure the identifying property as “species” in line 2. In lines 3 and 4 we specifythat an object whose species property has the value “cat” or “dog” is of type with id“#mammal”. Correspondingly, we associate the values “praying mantins” and “spider”with the type that has the id “#insect”.
73
4. Implementation
1 {2 "attribute": "species",3 "mapping": {4 "cat": "#mammal",5 "dog": "#mammal",6 "praying mantis": "#insect",7 "spider": "#insect"8 }9 }
Listing 4.8: Sample Model Mapping
Improvements. Further improvements of this mapping should address two of itsweaknesses. First, the property used to gather the identifying data is the same for allmappings. This is a problem for JSON Schemata containing definitions whose affectedtypes do not share a property of the same name. Second, the keys of the mapping arehard-coded values at the moment. More flexibility can be achieved by using a predicatefunction which is evaluated on the checked data. The function then returns whetherthe data is an instance of the mapped type. A more advanced approach could usea function returning a numerical value. The type is then associated with the highestnumber. This would allow to chose the most likely type in case it can not be determinedunambiguously. However, using functions would most likely lead to an increased effortwhen defining the mapping.
4.10.4. UI Schemata
A UI Schema is used by JSON Forms to render a form for a data object of a typespecified by a data schema. In our editor framework, one UI Schema can be registeredfor every data type whose instances can be created in the element containment tree. Ifno UI Schema is registered for a data type, a default one is generated when an instanceof the type is rendered (see subsection 4.4.2). Thereby, a UI Schema is a view modelwhich defines how the data is rendered as a form. The UI schema specifies whichproperties are rendered, which layouts are used for this, and under which circumstancesthe properties are editable or shown. A UI Schema is built as a containment hierarchywith exactly one UISchemaElement as its root.
4.10.4.1. Elements of a UI Schema
In this section, we introduce all elements that are used to define UI Schemata. Figure 4.8shows the inheritance hierarchy of the elements as well as their properties. Figure 4.9shows all layouts and Figure 4.10 shows all elements needed to configure different rules.Thereby, in JSON Form’s implementation, all these elements are defined as interfaces.In favor of better readability, we omitted the stereotypes in the UML diagram. TheUISchemaElement’s property type fulfills a special role. It defines which type an
74
4.10. Customization
Figure 4.8.: UML Class Diagram: UI Schema – Element Hierarchy
instance of UISchemaElement or one of its children has. Thereby, every type that is adirect or indirect child of UISchemaElement requires the type property to be set to afixed string identifying it. For instance, the ControlElement type defines that all of itsinstances’ type properties are set to “Control”. For the GroupLayout it is set to “Group”and for LabelElement to “Label”. All other element types use their interface name. Inthe following, we introduce all elements and explain their purpose.
UISchemaElement
The UISchemaElement is the base of the UI Schema. A UI Schema consists of exactlyone UISchemaElement at the root level. It defines the basic properties that everyelement UI Schema must provide. The options property can contain any kind of data.This allows to annotate a UISchemaElement with additional information that mightbe needed by a renderer. The runtime property is a reference to a context object whichencapsulates an element’s runtime state, e.g. whether it is visible or is associated withany validation errors. Additionally, every element may configure one Rule (see below).
75
4. Implementation
Figure 4.9.: UML Class Diagram: UI Schema – Layouts Hierarchy
Figure 4.10.: UML Class Diagram: UI Schema – Rule Hierarchy
76
4.10. Customization
ControlElement
A ControlElement configures one property that is rendered in a form. In additionto the UISchemaElement, the ControlElement extends Scopable. The $ref propertyof the inherited scope property contains the path to the rendered property in the dataschema. Thereby, this path is specified as a JSON Pointer relative to the root of thereferenced data schema. The label property’s type Label is a placeholder representing achoice between the types boolean, string, and a label object. In case of boolean, the labelproperty defines whether a label is shown. In case of a string, a label with the property’scontent is shown. In the label object, both options can be specified: a text and whether itis displayed.
MasterDetailLayout
The MasterDetailLayout configures a tree master detail layout for the data referencedby its scope. Thereby, the scope and label properties work the same as for the Con-trolElement. A tree master detail layout consists of a dynamic containment tree anda detail view showing the properties of the element currently selected in the tree. Thetree’s elements represent the containment hierarchy of the rendered data. It is renderedby the TreeRenderer component (see section 4.5).
LabelElement
A LabelElement renders a label with the text specified in its text property.
Layouts
A Layout contains one or more UISchemaElements in their elements property. Alayout renders all of its child elements in an arrangement depending on its type. Thereare three universal layouts and the Category which is only used in the context ofCategorizations (see below). The HorizontalLayout renders all contained elementsside by side. The VerticalLayout and the GroupLayout render contained elementsone beneath each other. Additionally, the GroupLayout shows an optional label andhighlights the elements’ grouping, for instance by enclosing them with a border.
Categorization
Similarly to the TreeMasterLayout, a Categorization also renders a master and adetail view. In contrast to the TreeMasterLayout, the Categorization’s master viewdoes not contain a tree of data elements. Instead, it contains a tree of the Categoriza-tions and Categories of its elements property. A Category is a Layout with a label.The label is the name of the category displayed in the containing categorization’s tree.The contained elements of the category are rendered in the categorization’s detail viewwhen the category is selected. In conclusion, a Categorization behaves similar to a
77
4. Implementation
tree master detail but uses a pre-configured, static tree structure instead of a dynamicone defined by the rendered data.
Rules
Generally speaking, a Rule triggers a configured effect on its parent element when therule’s condition evaluates to true. The possible effects are defined in the RuleEffect
enumeration. For instance, a rule with effect HIDE makes its target invisible when itscondition is true. Currently there is only one type of Condition: the LeafCondition. Itreferences a property of the rendered data with its scope property. This works the sameas for ControlElements. When the property’s content matches the value configured inexpectedValue, the rule evaluates to true.
At the moment, only simple conditions can be configured because a Rule may onlycontain one Condition and the LeafCondition only allows to reference one property.This heavily limits the configuration possibilities. One way to deal with this, wouldbe the introduction of conditions that contain further conditions and aggregate theirevaluation results. For instance, an AndCondition would connect the evaluation resultsof its children with a logical AND. Congruently, an OrCondition would do the samewith a logical OR. As these conditions could be cascaded, arbitrarily complex conditionscould be created.
4.10.4.2. Example UI Schema
Listing 4.9 shows an example for a UI Schema for the type with id “#mammal” definedin lines 3 to 11 of Listing 4.5. In line 2, we define the root UISchemaElement as aVerticalLayout. This contains four Controls specifying the properties to render.In line 14, we explicitly define to show the label “Gender” instead of automaticallyinferring it from the property’s name. In lines 20 to 26, we configure a rule for thepregnant property. We only render the property, if the sex property of the mammal is setto “female”. This is done by specifying in line 21 that the Control is shown when thecondition is met. In line 23, we define that the condition evaluates to true if the targetproperty has the value “female”. In line 24, we reference the pregnant property as thetarget property to evaluate.
4.10.5. Resources
Resources can be used to register data to the editor that is not part of the data editedin the editor. Thereby, a resource can be any data provided as a JavaScript Object. Aresource is registered under a unique name. This name can then be used to referencedata in the resource or use a resource as a target schema for a reference definition. Formore details regarding references and the resource set holding registered resources seesection 4.9.
78
4.10. Customization
1 {2 "type": "VerticalLayout",3 "elements": [4 {5 "type": "Control",6 "scope": { "$ref": "#/properties/name" }7 },8 {9 "type": "Control",
10 "scope": { "$ref": "#/properties/species" }11 },12 {13 "type": "Control",14 "label": "Gender",15 "scope": { "$ref": "#/properties/sex" }16 },17 {18 "type": "Control",19 "scope": { "$ref": "#/properties/pregnant" },20 "rule": {21 "effect": "SHOW",22 "condition": {23 "expectedValue": "female",24 "scope": { "$ref": "#/properties/pregnant" }25 }26 }27 }28 ]29 }
Listing 4.9: Sample UI Schema for the Mammal Type of Listing 4.5
79
4. Implementation
Figure 4.11.: UML Class Diagram: Editor Configuration Object
4.10.6. Configuration Object
The configuration object contains all configurations necessary to specify an editor.It can be set as a single object to the editor. In principle, this allows to read thewhole configuration from one JSON file. A configuration object is defined by theEditorConfiguration type shown in Figure 4.11. When defining such a configurationobject, only the dataSchema attribute is mandatory. The attributes are defined as describedin the foregoing subsections.
4.11. Testing
To make sure a developed system works as intended, extensive testing is needed. Besidestesting generated editors by hand, we implemented automated unit tests. These allowautomatic testing of sub-parts of the system. This allows for easy regression testingwhen the system is changed. As unit tests often aim to test a single functionality of asystem, they are especially suitable to test algorithms like the retrieving of containmentproperties or the resolution of references.
To provide unit tests for the system, we use the open-source framework AVA41. AVAallows to run unit tests fully automatic with serial and parallel execution. Furthermore,it allows testing asynchronous functions and callbacks. It provides functionality toconfigure common test behavior for multiple tests, provides various assertion tools, andis well documented.
41https://github.com/avajs/ava
80
5. Evaluation
In this chapter, we evaluate our implementation of the model-driven JSON editorframework. Therefore, we chose three languages for which we each generate an editorwith our framework. These languages are introduced in section 5.1. We describe theprocess of creating the editors in section 5.2. Based on this, we collect the advantagesand limitations of using the editor framework in section 5.3 To judge the usability ofeditors generated with our framework, we conduct a usability test in cooperation withour industry partner in section 5.4. Finally, we conduct an anecdotal comparison of aneditor generated with our framework to a specific implementation in section 5.5.
5.1. Evaluation Languages
In this section, we describe the languages for which we each customized and generatedan editor.
5.1.1. Ecore
Ecore42 is the meta-model of the Eclipse Modeling Framework43. Ecore is a languagethat allows specifying structured data through the definition of classes, attributesreferences, enumerations, custom data types, and more. Thereby, every class can have anarbitrary number of supertypes and every element can be annotated by an annotationobject. A specification defined in the Ecore language can then be used to generate thecorresponding code with the Eclipse Modeling Framework.
5.1.2. Json Schema
Json Schema44 is used to define JSON data. It describes which properties a JSON objectmay contain and of which types these objects can be. Thereby, the type can be a primitivetype or another JSON Schema. In general, every time a new type is defined in JSONSchema, this type definition is a JSON Schema itself. Consequently, JSON Schema ishighly recursive in itself.
JSON Schema provides various validation keywords which further define the legalcontents of an object. However, the contents of a valid JSON Schema are highly variable.
42http://download.eclipse.org/modeling/emf/emf/javadoc/2.11/org/eclipse/emf/ecore/
package-summary.html43https://www.eclipse.org/modeling/emf/44https://tools.ietf.org/html/draft-zyp-json-schema-04
81
5. Evaluation
As a result, only a few of the available properties of a schema are used at the same time.Many are even mutually exclusive.
5.1.3. UI Schema
UI Schemata are used to define how data objects are rendered in JSONForms and inour editor framework. A detailed description of the language’s elements is given insubsection 4.10.4.
5.2. Editor Customization Process
In this section, we describe the customizations that we conducted for every one of ourevaluation languages. Thereby, we focused on the Ecore and the UI Schema editor dueto the JSON Schema editor’s full configuration being out of the scope of this thesis.However, JSON Schema’s complexity gives us valuable insights into the limitations ofour framework.
5.2.1. General
For all editors, we create a basic index web page which loads the editor frameworkand the provided libraries and style sheets. Subsequently, we create the new editorelement. Furthermore, we configure the buttons in the index page to allow loading,exporting, and downloading the editor’s data. Thereby, we do not need to implementthese services ourselves but simply load them from the editor framework.
5.2.2. Ecore
To configure the Ecore Editor we conducted the following steps:
1. Add unique IDs to type definitions missing them. This is necessary to allowconfiguring labels, images and the model mapping for these types.
2. Create a label mapping containing an entry for every type
3. Create the model mapping with attribute “eClass”: Every element type that is partof a containment property whose schema uses anyOf needs to be mapped. Theseare the types with the following types: EEnum, EClass, EDataType, EReference,EAttribute.
4. Create an image mapping with an entry for every type. Link a unique CSS classfor each type.
5. Create a CSS file that loads the corresponding icon for every type and load it inthe index web page.
82
5.2. Editor Customization Process
6. Configure link definitions for the eType properties of the types EReference andEAttribute to allow referencing their type.
7. Implement two custom reference controls for ID-based referencing for the refer-ences configured in the previous step. For EReference, only a simple method needsto be overwritten. For EAttribute, the implementation needs more effort. Ecore’sbasic attribute types (e.g. EInt) need to be shown when selecting an attribute type.Furthermore, not all attribute type options can be shown because attribute typescan be EEnums or EDataTypes and ID-based referencing does not support anyOfin their target schema.
8. Create a UI Schema for every type. This is necessary to hide the _id an eClassproperties which are not meant for the user to be seen or edited. Furthermore, forthe EAttribute and EReference types, we need to declare that their eType propertyshould be rendered as a reference.
9. Create a configuration object containing the previously created configurations andload it with the editor framework.
Figure 5.1 shows the generated Ecore editor containing a simple model.
5.2.3. UI Schema
To configure the UI Schema Editor we conducted the following steps:
1. Add unique IDs to type definitions missing them. This is necessary to allowconfiguring labels, images and the model mapping for these types.
2. Create a label mapping containing an entry for every type
3. Create the model mapping with attribute “type”: Every element type of the UISchema is identified by its type property (see 4.10.4).
4. Create an image mapping with an entry for every type. Link a unique CSS classfor each type.
5. Create a CSS file that loads the corresponding icon for every type and load it inthe index web page.
6. Extend the export and download services to filter out empty rule objects beforeserializing the editor’s data. This is needed because the editor creates an emptydata object when rendering a Rule’s properties as part of a detail view of a typecontaining a Rule.
7. Configure a link definition for every used $ref property of the Scope type inthe JSON Schema. Thereby, configure the reference targets to be in a resourcenamed dataSchema. Configure the target schema to be loaded from a resource.
83
5. Evaluation
Figure 5.1.: Screenshot Showing the Created Ecore Editor
84
5.2. Editor Customization Process
Figure 5.2.: Screenshot Showing the Created UI Schema Editor
Use a modified version of JSON Schema Draft 445 that does not allow additionalproperties.
8. Create a UI Schema for every type. This is necessary for two reasons. First,we need to declare for the $ref properties that they should be rendered as areference. Second, without UI Schemata the forms of most types are confusing:Some properties of the rule objects contained in every type use the same names astheir parents.
9. Create a configuration object containing the previously created configurations andload it with the editor framework.
Figure 5.2 shows the generated UI Schema editor containing a simple model.
5.2.4. JSON Schema
To configure the UI Schema Editor we conducted the following steps:
1. Remove the usage of the allOf keyword from the schema.
2. Replace the schema’s id as it is not the original JSON Schema 04 anymore.
3. Removed the type property’s possibility to be either an array or a single value.Now it can only be a single value.
45Available at: http://json-schema.org/draft-04/schema
85
5. Evaluation
4. Define a label mapping containing an entry for the JsonSchema type.
5. Create a UI Schema for the JSON Schema type.
5.3. Advantages and Limitations
In this section, we present the aggregated advantages and limitations we observed whilecreating the three editors in section 5.2.
5.3.1. Advantages
In this section, we describe editor framework’s the advantages detected when creatingthe editors in section 5.2. Thereby, we group the advantages into categories.
5.3.1.1. Containment Tree
We observe four advantages related to the provided containment tree. First, the editorshows a containment hierarchy of the contained data elements without needing addi-tional configuration. This tree offers the addition of new elements at suitable positionsin the tree and the deletion of elements existing in the tree. Second, the tree offersdrag and drop for contained elements. Thereby, legal drop zones of a dragged elementare shown and it is guaranteed that an element can only be dropped at a valid targetlocation. Third, the tree shows configured icons for contained elements. And fourth, thetree shows labels based on a configured property for contained elements. Thereby, thelabel is automatically adapted whenever the corresponding property’s value changes.
5.3.1.2. Configuration & Customization
Generated editors allow easy customization for multiple reasons. First, the icons andlabels of the containment tree’s elements can each be configured in a simple map.Second, the usage of UI Schemata allows extensive customization of the tree elements’detail views. Thereby, no code has to be written but only the corresponding UI schemataneed to be provided. Third, the above mentioned customizations as well as the editorsJSON Schema, initial data, model mapping, and resources can be provided in a singleconfiguration object. This allows to load the whole configuration from a single JSONfile.
Addition of functionality to generated editors is facilitated by the following twofeatures. First, every generated editor provides access to its current data and allowsmodification of this data through external code. This allows for simple addition of addi-tional functionality like, for instance, a custom data export. Second, custom rendering ofproperties can be provided by simply implementing a renderer and loading it. Thereby,the renderer can be used only for specific properties or all properties of a certain type.
86
5.3. Advantages and Limitations
5.3.1.3. Referencing
The framework provides flexible referencing by providing two different reference tech-niques: path- and ID-based referencing. This allows choosing the better fitting onedepending on the use cases of the editor’s JSON Schema. For additional flexibility,both mechanisms can be used in the same editor. Thereby, properties containing thereference values as well as valid references can simply be configured in the editor’sJSON schema. Furthermore, the reference mechanism allows referencing external dataelements contained in a resource registered to the editor. For path-based referencing, arenderer is provided which provides all this functionality out-of-the-box.
5.3.1.4. Detail Rendering
The detail rendering provides automatic support for simple evolutions of the JSONschema defining the editor. Extensions to a schema are available by simply reloading theeditor. For instance, if an option is added to an enumeration property, the new option isimmediately available after a re-load without needing any further adaptations.
The efficient editing of properties is facilitated by two features. First, the generatededitors provide typed editing for many data types. For instance, boolean values arerendered as a checkbox and enumerations are rendered as a combo box that only allowsthe selection of defined values. Second, a tree element’s properties are automaticallyvalidated against the schema defining them and the validation result is displayed. Thisincludes a message that states the reason for a failed validation. Both features help usersof the editor to create correct data.
5.3.1.5. Other
This section contains two additional advantages which don’t fit in any of the previouscategories. First, the editor framework provides a standard styling based on Materialize46
which allows properly styled standalone editors without needing to provide an extensivestyle sheet. And second, generated editors can be easily integrated into any webapplication. Because the editor framework is implemented based on HTML Customelements, generated editors can be created and integrated like a normal HTML element.
5.3.2. Limitations
In this section, we present the limitations in the implementation of the editor frameworkthat we observed when creating the editors in section 5.2. Thereby, we group thelimitations into categories.
46http://materializecss.com/
87
5. Evaluation
5.3.2.1. Referencing
We observed limitations in the reference mechanism related to two aspects. The firstaspect is two limitations related to the required effort when using the reference mecha-nism. First, in order to render a property as a reference, a UI Schema must be configuredthat contains a Control which explicitly specifies the used referencing technique. Thisis necessary because otherwise, the corresponding renderers cannot know that theproperty is a reference and which mechanism is used. Second, in case of ID-basedreferencing, an abstract renderer must be implemented to render a reference. However,doing this only requires to overwrite one simple method and to provide a simple tester.The renderer instantiation can then be re-used for multiple similar reference properties.
The second aspect is missing functionality. So far, there is no renderer provided formulti-references. A multi-reference is a reference which may contain more than onereferenced value. However, the reference mechanism itself does support multi-references.ID-based referencing does not support specifying multiple allowed types in a targetschema. Consequently, valid reference targets for one reference property can only beof a single. This is the case because the parser currently does not resolve the anyOf
keyword in target schemata. In case of path-based referencing this limitation does notapply because the target schema does not need to be analyzed. Possible reference targetsare simply validated against the whole schema using a validation framework.
5.3.2.2. Detail Rendering
In this section, we list limitations related to the detail rendering of elements selectedin the tree. These limitations mainly origin from limitations of the typed editingof rendered properties. The main reason for this is missing renderers of the DetailRendering component.
There is no renderer that supports properties which allow multiple types. Thisincludes properties of multiple primitive types, e.g. a property that allows boolean andstring values, as well as properties that define multiple allowed complex types by usingthe anyOf keyword. Furthermore, there is no renderer for arrays of primitive types(e.g. string, boolean or number). Another limitation occurs when using JSON Schema’sconcept of additional properties. These can only be configured if there is an explicitschema defining their content. Consequently, arbitrary data extension is not supported.Even if no renderer is available, every property, independent of its type, can be renderedas a simple text field. However, this does not constitute proper typed editing.
The last limitation of the detail rendering occurs when the currently rendered dataobject contains properties with nested data objects. The nested object is created empty,even if none of its properties are set. Instead, the whole nested object should beundefined until it is needed because one of its properties is set.
88
5.3. Advantages and Limitations
5.3.2.3. Configuration
The first observed configuration limitation is the UI Schema’s rule mechanism. Every UISchema element can only be configured with one rule which is limited to one condition.Currently, there is only one type of rule condition that is evaluated to trigger a rule.This leaf condition only allows specifying one property whose value is evaluated. Thespecification of child rules or conditions is not possible. Consequently, more complexconditions depending on the values of two or more properties are not possible.
The second configuration limitation is the fixed property name in the model mapping.This prevents a successful usage of the model mapping if there is no common type-identifying property in all types that require mapping. This can constitute a problembecause every type that is used in a containment property that uses anyOf shouldbe configured in the model mapping. Otherwise, instances of this type that are partof such a containment property do not support drag and drop. Furthermore, if thecontainment is the target of an ID-based reference, instances of the unmapped typemight be incorrectly recognized as valid reference targets.
5.3.2.4. JSON Schema
Here, we observe limitations in regard to the contents of the JSON Schema defining theeditor. Thereby, limitations related to the detail rendering of data elements are omittedas they are already described in 5.3.1.4.
The JSON Schema keywords allOf, not, and oneOf are not supported (except for intarget schemata of path-based references). This leads to the following limitation whendefining JSON Schemata which are intended to be used with the editor framework. Notsupporting allOf prevents defining common properties in a kind of supertype. Forinstance, in the Ecore schema, all types have the properties eClass and _id. With supportfor allOf, these could have been extracted to a common supertype.
For every data type defined in an editor’s JSON Schema, the data type’s subschemashould define a valid id property starting with ’#’. Without such an ID, instances of thetype are not eligible for drag and drop and cannot be referenced by ID-based referencing.
5.3.2.5. Tree
A limitation of the tree renderer occurs when a type has multiple containment propertiesof the same type. In this case, the add dialog for creating new child elements does notindicate for which one of the containment properties an element of the type is created.Consequently, the user cannot know to which one of the properties the created elementis added.
5.3.2.6. Browser Compatibility
Due to the usage of Custom Elements, editors created with the framework cannot beused in every browser, yet. We have extensively tested the framework with Google
89
5. Evaluation
Chrome. According to the MDN Web Docs47, they should also be supported in Operaand Safari. For Firefox an open development bug48 exists.
5.4. Usability Test
In this section, we conduct a usability test of the generated UI Schema editor in co-operation with our industry partner. The test was conducted with five participants.Two of these describe their role in the company as software architects, two as softwareengineers, and one as both.
To measure the usability, we use the System Usability Scale (SUS) [12]. SUS is aten-item questionnaire that measures the subjective perception of usability. Thereby,the questions are not tailored to any special kind of system. They consider differentusability facets of a system “such as the need for support, training, and complexity”[12]. The participants answer each question on a 5 point scale from 1 to 5. Thereby, 1represents strong disagreement and 5 strong agreement [12]. The SUS questionnaireitems are listed in appendix B.2. In addition to these questions, the participants wereasked whether they could complete the evaluation scenario and which features, in theiropinion, the editor is missing.
5.4.1. Evaluation Scenario
In this section, we specify the evaluation scenario that was carried out by every par-ticipant. The participants were instructed to build a UI Schema that defines a formfor a given data schema (see Listing B.1). Thereby, they knew the concepts of the UISchema itself but were not trained in using the editor. The referenced data schema waspre-configured as a resource in the editor. Additionally, the data schema was madeavailable to the participants. The editor was made available to the participants as arunning online instance. The browser to use is set to Google Chrome. The followinginstructions were given to the participants.
1. Open the UI Schema editor. The data schema is pre-loaded in the editor.
2. Build a UI Schema resembling the evaluation layout shown in Figure 5.3. Boxeswith labels above them (e.g Primary) are groups. Boxes with text inside them arecontrols.
3. Configure a rule on the Address group that only shows it if the alive property istrue.
4. Test the editor’s phone compatibility. Go to the mobile view of the web page:Press F12, then press CTRL + SHIFT + M. Select IPhone 6 Plus in the showingmenu and select widescreen mode. Delete the “firstName” control.
47https://developer.mozilla.org/en-US/docs/Web/Web_Components/Custom_Elements#Browser_
compatibility48https://bugzilla.mozilla.org/show_bug.cgi?id=889230
90
5.4. Usability Test
Primary Secondary
Address
firstName
lastName
dateOfBirth
timeOfRegistration
gender
alive
street street-number
city
Figure 5.3.: Target Evaluation Layout
5. Exit the phone view by pressing CTRL + SHIFT + M again.
6. Download the created UI Schema to your hard drive
7. Answer the questionnaire.
5.4.2. Results
In this section, we analyze the results of the usability test. Therefore, we first analyzethe SUS score in 5.4.2.1 and then the qualitative answers in 5.4.2.2.
5.4.2.1. SUS
We determine the SUS score in the range of 0 to 100 by using the scoring methodspecified by Brooke in [12]:
“To calculate the SUS score, first sum the score contributions from each item.Each item’s score contribution will range from 0 to 4. For items 1,3,5,7,and 9the score contribution is the scale position minus 1. For items 2,4,6,8 and 10,the contribution is 5 minus the scale position. Multiply the sum of the scoresby 2.5 to obtain the overall value of SU.” [12]
The scores for each answer as well as calculated SUS scores are shown in Table 5.1.The averaged SUS-score of all participants is 79.5. In order to judge the meaning ofour achieved score, we use the adjective rating scale determined by Bangor et al. [5].
91
5. Evaluation
Table 5.1.: Usability Test – Calculated SUS Result Scores. Items 1 to 10 are stated in B.2
Average P1 P2 P3 P4 P5
Item 1 2.8 3 3 4 1 3Item 2 3 3 4 4 1 3Item 3 3 3 4 4 1 3Item 4 3.8 4 4 4 4 3Item 5 2.8 3 4 4 0 3Item 6 3.6 3 4 4 3 4Item 7 3.2 3 4 4 1 4Item 8 2.6 3 3 4 0 3Item 9 3.2 4 3 4 1 4
Item 10 3.8 4 4 4 3 4
SUS-Score 79.5 82.5 92.5 100 37.5 85
They related SUS scores to seven adjective ratings ranging from Worst Imaginable to BestImaginable49. This was done by adding an eleventh question to over 900 SUS surveysthat asked the participant to rate the user-friendliness of the tested system. Using theresulting scale to judge the result of the UI Schema editor places its usability betweenGood and Excellent. Thereby, the mean score for systems rated as Good was 71.4 and 85.5for systems rated as Excellent [5].
5.4.2.2. Qualitative Answers
The first qualitative question was whether the participants could successfully completethe evaluation scenario. All of them answered this question with a “Yes”. The secondquestion was “In your opinion, which features is the editor missing?”. The verbatimanswers to this question are listed in appendix B.3. In the following, we aggregate theanswers and differentiate between domain-specific and generic features. This allows usto determine which of these features are potentially missing in the editor frameworkbecause the domain-specific features do not belong into a generic framework.
Missing Domain-Specific Features
There were various UI Schema-specific features the test participants were missing: Fourmissed the automatic generation of Control elements. Three missed a preview of themodeled UI Schema. One participant each missed the following features: Auto-completefor the expectedValue property when configuring a rule condition, more intuitive icons,automatic naming of Control elements based on the selected reference in case no explicit
49The seven ratings from worst to best are: Worst Imaginable, Awful, Poor, OK, Good, Excellent, BestImaginable [5]
92
5.5. Comparison to a Specific Editor
name has been provided for the Control. All of these features can be implementedand provided to UI Schema editor by using its service interface or providing customrenderers.
Missing Editor Features
There were two generic features reported as missing in the editor. The first one is amissing confirmation dialog before deleting an element from the containment hierarchy.This can be fixed by a simple adaption in the tree renderer. The second one is themissing propagation of validation results from the detail view to the tree. This means ifa validation error occurs in the properties of a tree element, this should be visualized atthe tree element, for instance by showing an overlay over the element’s icon. Interestinglyenough, this feature was also determined as a functional requirement (FR–17) of mediumpriority. Due to its implementation being quite complicated, the implementation wasconsidered out of scope for this thesis. However, a concrete demand suggests animplementation during further development of the editor framework.
5.5. Comparison to a Specific Editor
In this section, we compare the created UI Schema Editor to an existing, domain-specific editor for the creation of UI Schemata. This editor is the JSON Forms Editor50.While not being scientifically relevant, the goal of this comparison was, to get a firstimpression whether an editor created with our framework can keep up with a specifictool. Therefore, the evaluation scenario described in subsection 5.4.1 was also executedfor the JSON Forms Editor. To allow for a comparison, this was done by the sameparticipants as in the usability test. Subsequently, the participants were asked to statethe advantages of each editor. Furthermore, they were asked which editor they preferredand what are the reasons. The verbatim questions and answers of the participants canbe found in appendix B.4. In the following, we summarize the results of the comparison.
The participants stated the automatic generation of Controls for the loaded evaluationschema as the only main advantage of the specific editor. Besides being highly domain-specific, this feature could easily be implemented in the UI Schema editor by using itsprovided service interfaces.
Four of the five participants liked our generated UI Schema Editor better to solvethe evaluation scenario. Stated reasons are better stability, better feature completeness,the tree giving a better overview, better rule support, and better support when scopingthe controls. The scoping corresponds to referencing the configured property of theevaluation schema (see Listing B.1). Interestingly enough, the UI Schema editor wasbetter in handling several domain-specific use cases than the JSON Forms Editor. Thiswas especially the case for configuring references in the control as well as configuringrules.50http://jsonforms-editor.eclipsesource.com/
93
5. Evaluation
These results indicate several advantages of our framework. First, the customizationoptions are extensive enough to configure an editor suitable for domain-specific needs.Second, providing solid implementations of generic features provides a proper basisto solve domain-specific solutions. In this case, our reference mechanism provided asuperior selection of Controls’ scopes. And finally, the generation of the editor fromthe JSON Schema allows to keep up with adaptions to the language. While the JSONForms Editor was still limited to only one hard-coded rule effect, the UI Schema Editorautomatically provided all four from the JSON Schema defining UI Schemata.
In conclusion, while this comparison cannot claim to adhere to scientific standards,it indicates the feasibility of our framework to generate editors that can keep up withdomain-specific implementations. Furthermore, it shows the advantages of havingfundamental features provided by a well-tested framework. For instance, in this case,this led to a higher stability compared to the specific editor.
94
6. Conclusion and Future Work
In this thesis, we developed a framework for the semi-automatic, model-driven gener-ation of editors for structured JSON data defined by a JSON Schema. To identify themulti-faceted features needed in a generic editor framework, we conducted an extensiverequirements analysis. In a literature review on the requirements of multilevel modelingtools, we analyzed 17 articles and determined 104 requirements grouped into 16 cate-gories. Subsequently, we performed an analysis of nine industry tools and related the34 gathered requirements to the results from the literature review. This gave us a broadbase of well-founded requirements. Based on these, we conducted an expert interviewwith our industry partner to select and prioritize the framework’s requirements. Theresult was 22 functional requirements divided up into three priorities. Additionally, wedetermined three quality attributes and three implementation constraints.
Based on the requirements, we developed the framework’s architecture, design, andimplementation. The framework generates editors based on a two-column master-detaillayout. The master contains a tree showing the containment hierarchy of the data objectsedited in the editor. It allows to create new elements at legal positions, delete existingelements, and move them via drag and drop. The detail view shows a form containingthe properties of the currently selected tree element. Thereby, the editor providestype-sensitive editing of the properties. For instance, a boolean value is rendered as acheckbox and an enumeration as a combo box which only allows the selection of legalvalues. Furthermore, property values are automatically validated against their definitionin the JSON Schema.
The framework is designed for generating editors for any type of JSON Schema. Toallow for specific customization, we provide extensive configuration options for thegenerated editors. The tree elements’ labels and icons can be customized with simplemappings. The elements’ detail views can be extensively customized by providing UISchemata for the data types rendered in the editor. Furthermore, every generated editoroffers a clearly defined public interface that allows to extend it with custom propertyrenderers and services.
Generated editors allow referencing between elements of the data instance. This isprovided by a reference mechanism which allows specifying a reference property aswell as valid reference targets. Both are specified within a simple definition in the JSONSchema used to generate the editor. Thereby, we implemented two different referenceapproaches: ID- and path-based referencing. The editor also supports references betweendifferent data instances by registering external resources to the editor.
95
6. Conclusion and Future Work
To demonstrate the feasibility of our approach and to determine its limitations, weevaluated it in two steps. The first part of the evaluation was the generation of threeconcrete editors for the example languages Ecore, UI Schema, and JSON Schema.Thereby, we determined four main limitations. First, the containment tree does notsupport multiple containments of the same type. Second, there are no proper renderersfor properties of more advanced type definitions such as multiple allowed types orarbitrary additional properties. Third, advanced features of JSON Schema such as thekeywords allOf, not, and oneOf are not supported by our framework. Fourth, the rulemechanism of UI Schema only allows configuring rules which evaluate exactly onetarget property.
Besides these limitations, the creation of the editors was possible. We successfullydemonstrated the framework’s feasibility by generating functional editors for Ecoreand UI Schema from their JSON Schemata. Thereby, the customization effort was lowand icons and labels could be configured easily with one simple mapping each. Eventhe different needs in referencing between data elements were no problem due to theframework’s provision of ID- and path-based referencing. Solely, the JSON Schemaeditor was restricted by the framework’s limitations. However, the framework’s highextensibility allows providing the missing features in the future.
The second part of the evaluation was conducting a usability test. The test was donewith the created UI Schema editor. Therefore, we specified an evaluation scenariowhich defined a target layout that the users should replicate for a given data model.Afterwards, the users stated whether they could successfully complete the scenario andrated the usability on the System Usability Scale (SUS). All five participants successfullycompleted the scenario and the editor achieved a SUS-score of 79.5 out of 100. Thisdemonstrates the usability of editors generated by our framework.
Finally, we give suggestions for further development of features for the editor frameworkthat were out of scope for this thesis.
The first feature is the propagation of validation errors to the containment tree.Currently, the properties of a selected tree element are already validated and the errorsdisplayed in the detail view. However, occurring errors are not indicated in the tree.Consequently, a user of the editor can only detect validation errors after selecting a treeelement. We believe that showing the errors in the tree would be a vast improvement inusability.
The second suggestion is more advanced reference renderers. Currently, referencescan be selected and the reference target is shown as a label. However, the renderedreferences are not navigable. Adding navigation to reference targets would improve theediting workflow when dealing with highly interconnected data. Another improvementto reference rendering is the provision of a multi-reference renderer that allows interact-ing with a reference property that contains multiple reference targets. Currently, theprovided renderers only provide references with exactly one target.
The third suggestion is the extension of the UI Schema’s rule configuration options.
96
Currently, every rule can only be evaluated against the value of one referenced property.The implementation of aggregating rule conditions such as AND or OR-conditionswould allow configuration of arbitrarily complex rules. In complex schema’s such as theJSON Schema, this allows to only show properties that are needed at the moment.
The fourth suggestion is implementing support for more advanced JSON Schemakeywords such as allOf, not, or oneOf. This extension improves the genericity of theframework by increasing the number of JSON Schemata that are supported withoutadjustments. Furthermore, supporting allOf allows for more compact JSON Schemataby refactoring data types’ common properties in a supertype that will be required in anallOf block.
To summarize, our framework provides highly customizable generation of tree-basededitors for JSON data defined by JSON Schemata. Thereby, fundamental functionalitysuch as typed property editing, property validation, drag and drop, and contextualelement creation is provided out of the box. The usage of JSON Schema’s moreadvanced features such as the allOf keyword or properties of multiple types requiresfurther development of our prototype. However, further development is encouraged bythe framework’s extensible design.
97
List of Figures
1.1. The Design Science Approach of this Thesis . . . . . . . . . . . . . . . . . 3
2.1. The Editor Generation Approach. . . . . . . . . . . . . . . . . . . . . . . . 62.2. Overview over the Literature Review’s Research Process . . . . . . . . . . 82.3. Literature Review Search Process. . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. TypeScript Transpilation Overview . . . . . . . . . . . . . . . . . . . . . . . 41
4.1. UML Component Diagram: The Editor Framework’s Conceptional Archi-tecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2. UML Class Diagram: JSONForms 2 Design . . . . . . . . . . . . . . . . . . 494.3. UML Sequence Diagram: Json Forms 2 Rendering Process . . . . . . . . . 514.4. UML Sequence Diagram: Rendering Loop . . . . . . . . . . . . . . . . . . 524.5. UML Class Diagram: Schema Service and Properties . . . . . . . . . . . . 564.6. UML Class Diagram: Resource Set Interface . . . . . . . . . . . . . . . . . 664.7. Overview over the Editor Framework’s Configurations and Customizations 704.8. UML Class Diagram: UI Schema – Element Hierarchy . . . . . . . . . . . 754.9. UML Class Diagram: UI Schema – Layouts Hierarchy . . . . . . . . . . . 764.10. UML Class Diagram: UI Schema – Rule Hierarchy . . . . . . . . . . . . . 764.11. UML Class Diagram: Editor Configuration Object . . . . . . . . . . . . . . 80
5.1. Screenshot Showing the Created Ecore Editor . . . . . . . . . . . . . . . . 845.2. Screenshot Showing the Created UI Schema Editor . . . . . . . . . . . . . 855.3. Target Evaluation Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
99
List of Listings
4.1. Algorithm to Collect Reference Properties . . . . . . . . . . . . . . . . . . . 594.2. Algorithm to Self Contain a Schema . . . . . . . . . . . . . . . . . . . . . . 614.3. JSON Schema with Example Declaration of a Links Block with Two
Reference Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.4. Algorithm to Collect Reference Targets from a Given Root Data . . . . . . 694.6. Sample Image Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.5. Customization Example JSON Schema . . . . . . . . . . . . . . . . . . . . . 724.7. Sample Label Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.8. Sample Model Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.9. Sample UI Schema for the Mammal Type of Listing 4.5 . . . . . . . . . . . 79
A.1. Deep Meta-Modelling Scopus Query 1 . . . . . . . . . . . . . . . . . . . . . 113A.2. Deep Meta-Modelling Scopus Query 2 . . . . . . . . . . . . . . . . . . . . . 113A.3. Deep Meta-Modelling Scopus Query 3 . . . . . . . . . . . . . . . . . . . . . 113A.4. Domain-Specific Modelling Language Scopus Query 1 . . . . . . . . . . . 114A.5. Domain-Specific Modelling Language Scopus Query 2 . . . . . . . . . . . 114A.6. Domain-Specific Modelling Language Scopus Query 3 . . . . . . . . . . . 114A.7. Domain-Specific Modelling Language Scopus Query 4 . . . . . . . . . . . 114A.8. Language Workbench Scopus Query 1 . . . . . . . . . . . . . . . . . . . . . 114A.9. Language Workbench Scopus Query 2 . . . . . . . . . . . . . . . . . . . . . 115A.10.Multi-Level Modelling Scopus Query 1 . . . . . . . . . . . . . . . . . . . . 115A.11.Multi-Level Modelling Scopus Query 2 . . . . . . . . . . . . . . . . . . . . 115A.12.Multi-Level Modelling Scopus Query 3 . . . . . . . . . . . . . . . . . . . . 115A.13.Multi-Level Modelling Scopus Query 4 . . . . . . . . . . . . . . . . . . . . 116
B.1. Json Schema for Which a UI Schema Was Created in the Usability Test . . 119
101
List of Tables
2.1. Summary of the Query Limitation Process . . . . . . . . . . . . . . . . . . 122.2. Requirements for Multi-Level Modelling Tools . . . . . . . . . . . . . . . . 152.3. Tool Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. Usability Test – Calculated SUS Result Scores . . . . . . . . . . . . . . . . 92
103
Bibliography
[1] D. Amyot, H. Farah, and J.-F. Roy. “Evaluation of Development Tools for Domain-Specific Modeling Languages.” In: Lecture Notes in Computer Science (includingsubseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)4320 LNCS (2006), pp. 183–197. doi: 10.1007/11951148_12.
[2] T. Asikainen and T. Männistö. “Nivel: a metamodelling language with a formalsemantics.” In: Software & Systems Modeling 8.4 (Sept. 2009), pp. 521–549. issn:1619-1366. doi: 10.1007/s10270-008-0103-2.
[3] U. Aßmann, S. Zschaler, and G. Wagner. Ontologies, Meta-models, and the Model-Driven Paradigm. Springer Berlin Heidelberg, 2006, pp. 249–273. doi: 10.1007/3-540-34518-3_9.
[4] C. Atkinson and T. Kühne. “The essence of multilevel metamodeling.” In: In-ternational Conference on the Unified Modeling Language. Springer. 2001, pp. 19–33.
[5] A. Bangor, P. Kortum, and J. Miller. “Determining What Individual SUS ScoresMean: Adding an Adjective Rating Scale.” In: Journal of Usability Studies 4.3 (2009),pp. 114–123.
[6] E. Bidelman. Custom Elements v1: Reusable Web Components. 2017. url: https://developers.google.com/web/fundamentals/architecture/building-components/
customelements (visited on 2017-10-13).
[7] P. Bourhis, J. L. Reutter, F. Suárez, and D. Vrgoc. “JSON: data model, querylanguages and schema specification.” In: Proceedings of the 36th ACM SIGMOD-SIGACT-SIGAI Symposium on Principles of Database Systems - PODS ’17. New York,New York, USA: ACM Press, 2017, pp. 123–135. isbn: 9781450341981. doi: 10.1145/3034786.3056120. arXiv: 1701.02221.
[8] B. Braatz and C. Brandt. “Domain-specific modelling languages with algebraicgraph transformations on RDF.” In: Lecture Notes in Computer Science (includingsubseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)6563 LNCS (2011), pp. 82–101. doi: 10.1007/978-3-642-19440-5_6.
[9] B. Braatz and C. Brandt. “A framework for families of domain-specific modellinglanguages.” In: Software & Systems Modeling 13.1 (Feb. 2014), pp. 109–132. issn:1619-1366. doi: 10.1007/s10270-012-0271-y.
105
Bibliography
[10] S. Brahe and K. Østerbye. “Business Process Modeling: Defining Domain SpecificModeling Languages by Use of UML Profiles.” In: Lecture Notes in ComputerScience (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes inBioinformatics) 4066 LNCS (2006), pp. 241–255. doi: 10.1007/11787044_19.
[11] J. vom Brocke, A. Simons, B. Niehaves, B. Niehaves, K. Reimer, R. Plattfaut, and A.Cleven. “Reconstructing the Giant: On the Importance of Rigour in Documentingthe Literature Search Process.” In: ECIS 2009 Proceedings (2009), pp. 2206–2217.issn: 0960-0035. doi: 10.1108/09600031211269721. arXiv: ECIS2009-0566.R1.
[12] J. Brooke et al. “SUS-A quick and dirty usability scale.” In: Usability evaluation inindustry 189.194 (1996), pp. 4–7.
[13] F. R. Burton, R. F. Paige, L. M. Rose, D. S. Kolovos, S. Poulding, and S. Smith.“Solving acquisition problems using model-driven engineering.” In: Lecture Notesin Computer Science (including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) 7349 LNCS (2012), pp. 428–443. doi: 10.1007/978-3-642-31491-9_32.
[14] A. Charland and B. Leroux. “Mobile application development.” In: Communicationsof the ACM 54.5 (May 2011), pp. 49–53. issn: 00010782. doi: 10.1145/1941487.1941504.
[15] H. Cho, J. Gray, and E. Syriani. “Creating visual domain-specific modeling lan-guages from end-user demonstration.” In: 2012 4th International Workshop onModeling in Software Engineering, MiSE 2012 - Proceedings. 2012, pp. 22–28. doi:10.1109/MISE.2012.6226010.
[16] A. Cicchetti. “Towards a deep metamodelling based formalization of componentmodels.” In: CEUR Workshop Proceedings. Vol. 1463. 2015, pp. 12–17.
[17] S. Cook and S. Kent. “The Domain-Specific IDE.” In: UPGRADE IX.2 (2008), pp. 17–21.
[18] J. De Lara and E. Guerra. “Domain-specific textual meta-modelling languages formodel driven engineering.” In: Lecture Notes in Computer Science (including subseriesLecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics) 7349 LNCS(2012), pp. 259–274. doi: 10.1007/978-3-642-31491-9_20.
[19] J. De Lara, E. Guerra, and J. Sánchez-Cuadrado. “Abstracting modelling languages:A reutilization approach.” In: Lecture Notes in Computer Science (including subseriesLecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics) 7328 LNCS(2012), pp. 127–143. doi: 10.1007/978-3-642-31095-9_9.
[20] A. Demuth, R. E. Lopez-Herrejon, and A. Egyed. “Cross-layer modeler - A toolfor flexible multilevel modeling with consistency checking.” In: SIGSOFT/FSE2011 - Proceedings of the 19th ACM SIGSOFT Symposium on Foundations of SoftwareEngineering. 2011, pp. 452–455. doi: 10.1145/2025113.2025189.
106
Bibliography
[21] H.-A. Dietrich, D. Breuker, M. Steinhorst, P. Delfmann, and J. Becker. “DevelopingGraphical Model Editors for Meta-Modelling Tools - Requirements, Conceptuali-sation, and Implementation.” In: Enterprise Modelling and Information Systems Archi-tectures 8.2 (Jan. 2013), pp. 42–78. issn: 1866-3621. doi: 10.18417/emisa.8.2.3.
[22] Z. Drey and C. Teodorov. “Object-oriented design pattern for DSL programmonitoring.” In: SLE 2016 - Proceedings of the 2016 ACM SIGPLAN InternationalConference on Software Language Engineering, co-located with SPLASH 2016. 2016,pp. 70–83. doi: 10.1145/2997364.2997373.
[23] M. Droettboom. Understanding JSON Schema. 2016. url: https://spacetelescope.github.io/understanding-json-schema/ (visited on 2017-10-13).
[24] J. Eichler, A. Fuchs, and N. Lincke. “Supporting security engineering at designtime with adequate tooling.” In: Proceedings - 15th IEEE International Conference onComputational Science and Engineering, CSE 2012 and 10th IEEE/IFIP InternationalConference on Embedded and Ubiquitous Computing, EUC 2012. 2012, pp. 194–201.doi: 10.1109/ICCSE.2012.34.
[25] M. Fowler. Language Workbenches and Model Driven Architecture. 2005.
[26] M. Fowler. Language Workbenches: The Killer-App for Domain Specific Languages?2005.
[27] U. Frank. “Designing models and systems to support it management: A case formultilevel modeling.” In: CEUR Workshop Proceedings. Vol. 1722. 2016, pp. 3–24.
[28] U. Frank. “Multilevel Modeling.” In: Business & Information Systems Engineering 6.6(Dec. 2014), pp. 319–337. issn: 2363-7005. doi: 10.1007/s12599-014-0350-4.
[29] U. Frank. “Multi-perspective enterprise modeling: foundational concepts, prospectsand future research challenges.” In: Software & Systems Modeling 13.3 (July 2014),pp. 941–962. issn: 1619-1366. doi: 10.1007/s10270-012-0273-9.
[30] U. Frank. Multi-perspective enterprise modelling: Background and terminological founda-tion. Tech. rep. ICB-Research Report, 2011.
[31] M. A. Gamboa and E. Syriani. “Automating activities in MDE tools.” In: MOD-ELSWARD 2016 - Proceedings of the 4th International Conference on Model-DrivenEngineering and Software Development. 2016, pp. 123–133.
[32] I. García-Magariño and R. Fuentes-Fernández. “A Technique for Defining Meta-model Translations.” In: IEICE Transactions on Information and Systems E92-D.10(2009), pp. 2043–2052. issn: 0916-8532. doi: 10.1587/transinf.E92.D.2043.
[33] A. Hejlsberg. “What’s new in TypeScript?” Technical presentation at MicrosoftBuild 2017, Seattle, WA, USA. https://channel9.msdn.com/Events/Build/2017/B8088.
107
Bibliography
[34] M. Herrmannsdoerfer. “COPE - A workbench for the coupled evolution of meta-models and models.” In: Lecture Notes in Computer Science (including subseriesLecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics) 6563 LNCS(2011), pp. 286–295. doi: 10.1007/978-3-642-19440-5_18.
[35] A. Hessellund. “SmartEMF: Guidance in Modeling Tools.” In: Companion to the22nd ACM SIGPLAN conference on Object oriented programming systems and appli-cations companion - OOPSLA ’07. New York, New York, USA: ACM Press, 2007,pp. 945–946. isbn: 9781595938657. doi: 10.1145/1297846.1297958.
[36] A. R. Hevner. “A Three Cycle View of Design Science Research.” In: ScandinavianJournal of Information Systems 19.2 (2007), pp. 87–92. issn: 09050167.
[37] B. Hoisl, S. Sobernig, and M. Strembeck. “Natural-language scenario descrip-tions for testing core language models of domain-specific languages.” In: MOD-ELSWARD 2014 - Proceedings of the 2nd International Conference on Model-DrivenEngineering and Software Development. 2014, pp. 356–367.
[38] M. Igamberdiev, G. Grossmann, and M. Stumptner. “An implementation of multi-level modelling in F-Logic.” In: CEUR Workshop Proceedings. Vol. 1286. 2014, pp. 33–42.
[39] S. Jablonski, B. Volz, and S. Dornstauder. “Evolution of business process modelsand languages.” In: Lecture Notes in Informatics (LNI), Proceedings - Series of theGesellschaft fur Informatik (GI). 2009, pp. 46–59.
[40] W. Jobe. “Native Apps vs. Mobile Web Apps.” In: International Journal of InteractiveMobile Technologies 7.4 (2013), pp. 27–32. doi: 10.3991/ijim.v7i4.3226.
[41] G. Kainz, C. Buckl, and A. Knoll. “Automated model-to-metamodel transforma-tions based on the concepts of deep instantiation.” In: Lecture Notes in ComputerScience (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes inBioinformatics) 6981 LNCS (2011), pp. 17–31. doi: 10.1007/978-3-642-24485-8_3.
[42] D. Koznov. “Process Model of DSM Solution Development and Evolution forSmall and Medium-Sized Software Companies.” In: 2011 IEEE 15th InternationalEnterprise Distributed Object Computing Conference Workshops. IEEE, Aug. 2011,pp. 85–92. isbn: 978-1-4577-0869-5. doi: 10.1109/EDOCW.2011.58.
[43] T. Kühne. “Understanding metamodeling.” In: Proceedings - 27th InternationalConference on Software Engineering, ICSE05. 2005, pp. 716–717.
[44] Y. Lamo, X. Wang, F. Mantz, Ø. Bech, and A. Rutle. “DPF Editor: A Multi-LayerDiagrammatic (Meta)Modelling Environment.” In: SPLST 2011. Ed. by J. Penjamin.Tallin: TUT Press, 2011, pp. 55–65.
[45] Y. Lamo, X. Wang, F. Mantz, Ø. Bech, A. Sandven, and A. Rutle. “DPF Workbench:a multi-level language workbench for MDE.” In: Proceedings of the Estonian Academyof Sciences 62.1 (2013), pp. 3–15. doi: 10.3176/proc.2013.1.02.
108
Bibliography
[46] J. de Lara, E. Guerra, R. Cobos, and J. Moreno-Llorena. “Extending Deep Meta-Modelling for Practical Model-Driven Engineering.” In: The Computer Journal 57.1(Jan. 2014), pp. 36–58. issn: 0010-4620. doi: 10.1093/comjnl/bxs144.
[47] J. b. de Lara and E. Guerra. “From types to type requirements: Genericity formodel-driven engineering.” In: Software and Systems Modeling 12.3 (2013), pp. 453–474. doi: 10.1007/s10270-011-0221-0.
[48] J. de Lara and E. Guerra. “Deep Meta-modelling with MetaDepth.” In: Objects,Models, Components, Patterns: 48th International Conference, TOOLS 2010, M{á}laga,Spain, June 28–July 2, 2010. Proceedings. Ed. by J. Vitek. Berlin, Heidelberg: SpringerBerlin Heidelberg, 2010, pp. 1–20. isbn: 978-3-642-13953-6. doi: 10.1007/978-3-642-13953-6_1.
[49] J. de Lara and E. Guerra. “Generic Meta-modelling with Concepts, Templatesand Mixin Layers.” In: Lecture Notes in Computer Science (including subseries LectureNotes in Artificial Intelligence and Lecture Notes in Bioinformatics) 6394 LNCS.PART 1(2010), pp. 16–30. doi: 10.1007/978-3-642-16145-2_2.
[50] T. Levendovszky, D. Balasubramanian, A. Narayanan, F. Shi, C. van Buskirk, andG. Karsai. “A semi-formal description of migrating domain-specific models withevolving domains.” In: Software and Systems Modeling 13.2 (2014), pp. 807–823. doi:10.1007/s10270-012-0313-5.
[51] X. Li, T. Liao, W. Wang, Z. Shu, N. Zhu, and Y. Lei. “An Ontology Based Domain-Specific Composable Modeling Method for Complex Simulation Systems.” In:Communications in Computer and Information Science 643 (2016), pp. 316–324. doi:10.1007/978-981-10-2663-8_34.
[52] B. Lin, Y. Chen, X. Chen, and Y. Yu. “Comparison between JSON and XML inApplications Based on AJAX.” In: 2012 International Conference on Computer Scienceand Service System. IEEE, Aug. 2012, pp. 1174–1177. isbn: 978-0-7695-4719-0. doi:10.1109/CSSS.2012.297.
[53] J. J. López-Fernández, E. Guerra, and J. De Lara. “Meta-model validation andverification with metabest.” In: ASE 2014 - Proceedings of the 29th ACM/IEEEInternational Conference on Automated Software Engineering. 2014, pp. 831–834. doi:10.1145/2642937.2648617.
[54] J. J. López-Fernández, E. Guerra, and J. de Lara. “Combining unit and specification-based testing for meta-model validation and verification.” In: Information Systems62 (2016), pp. 104–135. doi: 10.1016/j.is.2016.06.008.
[55] L. Lúcio, S. Weißleder, F. Fondement, and H. Cichos. “MoDeVVa 2011 WorkshopSummary.” In: Lecture Notes in Computer Science (including subseries Lecture Notes inArtificial Intelligence and Lecture Notes in Bioinformatics) 7167 LNCS (2012), pp. 183–186. doi: 10.1007/978-3-642-29645-1_19.
109
Bibliography
[56] F. b. Macías, A. Rutle, and V. b. Stolz. “MultEcore: Combining the best of fixed-level and multilevel metamodelling.” In: CEUR Workshop Proceedings. Vol. 1722.2016, pp. 66–75.
[57] I. Malavolta. “Beyond native apps: web technologies to the rescue! (keynote).” In:Proceedings of the 1st International Workshop on Mobile Development - Mobile! 2016.New York, New York, USA: ACM Press, Oct. 2016, pp. 1–2. isbn: 9781450346436.doi: 10.1145/3001854.3001863.
[58] S. J. Mellor, S. Kendall, A. Uhl, and D. Weise. MDA Distilled. Redwood City, CA,USA: Addison Wesley Longman Publishing Co., Inc., 2004. isbn: 0201788918.
[59] T. Mészáros, G. Mezei, and T. Levendovszky. “A flexible, declarative presentationframework for domain-specific modeling.” In: Proceedings of the working conferenceon Advanced visual interfaces - AVI ’08. New York, New York, USA: ACM Press,2008, pp. 309–312. isbn: 9781605581415. doi: 10.1145/1385569.1385620.
[60] Microsoft. TypeScript - JavaScript that scales. url: https://www.typescriptlang.org/ (visited on 2017-10-13).
[61] P. Mohagheghi and Ø. Haugen. “Evaluating Domain-Specific Modelling Solu-tions.” In: Lecture Notes in Computer Science (including subseries Lecture Notes inArtificial Intelligence and Lecture Notes in Bioinformatics) 6413 LNCS (2010), pp. 212–221. doi: 10.1007/978-3-642-16385-2_27.
[62] P. Neubauer, R. Bill, and M. Wimmer. “Modernizing domain-specific languageswith XMLText and IntellEdit.” In: SANER 2017 - 24th IEEE International Conferenceon Software Analysis, Evolution, and Reengineering. 2017, pp. 565–566. doi: 10.1109/SANER.2017.7884679.
[63] B. Neumayr and M. Schrefl. “Multi-level Conceptual Modeling and OWL.” In:Lecture Notes in Computer Science (including subseries Lecture Notes in ArtificialIntelligence and Lecture Notes in Bioinformatics) 5833 LNCS (2009), pp. 189–199. doi:10.1007/978-3-642-04947-7_23.
[64] C. Nunes, J. Araujo, V. Amaral, and C. Silva. “A domain specific language forthe I* framework.” In: Proceedings of the 11th International Conference on EnterpriseInformation Systems - Volume 1: ICEIS. SciTePress - Science, 2009, pp. 158–163. isbn:978-989-8111-84-5. doi: 10.5220/0001995301580163.
[65] N. Nurseitov, M. Paulson, R. Reynolds, and C. Izurieta. “Comparison of JSONand XML Data Interchange Formats: A Case Study.” In: CAINE. 2009.
[66] F. Pezoa, J. L. Reutter, F. Suarez, M. Ugarte, and D. Vrgoc. “Foundations ofJSON Schema.” In: Proceedings of the 25th International Conference on World WideWeb - WWW ’16. 2016, pp. 263–273. isbn: 9781450341431. doi: 10.1145/2872427.2883029.
[67] L. Quesada, F. Berzal, and J.-C. Cubero. “ModelCC — A Pragmatic Parser Genera-tor.” In: International Journal of Software Engineering and Knowledge Engineering 24.08(Oct. 2014), pp. 1177–1195. issn: 0218-1940. doi: 10.1142/S0218194014500375.
110
Bibliography
[68] A. Rossini, J. de Lara, E. Guerra, A. Rutle, and Y. Lamo. “A Graph Transformation-Based Semantics for Deep Metamodelling.” In: Lecture Notes in Computer Science(including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinfor-matics) 7233 LNCS (2012), pp. 19–34. doi: 10.1007/978-3-642-34176-2_4.
[69] A. Rossini, J. de Lara, E. Guerra, A. Rutle, and U. Wolter. “A formalisation of deepmetamodelling.” In: Formal Aspects of Computing 26.6 (Nov. 2014), pp. 1115–1152.issn: 0934-5043. doi: 10.1007/s00165-014-0307-x.
[70] H. D. S. Saraiva and A. R. Da Silva. “The projectIT-studio UMLmodeler: A toolfor the design and transformation of UML models.” In: Iberian Conference onInformation Systems and Technologies, CISTI. 2008, SAAFS05.
[71] M. Selway, M. Stumptner, W. Mayer, A. Jordan, G. Grossmann, and M. Schrefl.“Multilevel Mapping of Ecosystem Descriptions.” In: Lecture Notes in ComputerScience (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes inBioinformatics) 9415 (2015), pp. 257–266. doi: 10.1007/978-3-319-26148-5_15.
[72] C. Sonnenberg, C. Huemer, B. Hofreiter, D. Mayrhofer, and A. Braccini. “The REA-DSL: A Domain Specific Modeling Language for Business Models.” In: LectureNotes in Computer Science (including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) 6741 LNCS (2011), pp. 252–266. doi: 10.1007/978-3-642-21640-4_20.
[73] D. Steinberg, F. Budinsky, M. Paternostro, and E. Merks. EMF : Eclipse ModelingFramework 2.0. 2nd ed. Addison-Wesley, 2009, p. 704. isbn: 0321331885.
[74] S. Tambe, A. Dabholkar, A. Gokhale, and A. Kavimandan. “Towards a QoSModeling and Modularization Framework for Component-based Systems.” In:2008 12th Enterprise Distributed Object Computing Conference Workshops. IEEE, Sept.2008, pp. 43–49. isbn: 978-1-4244-4485-4. doi: 10.1109/EDOCW.2008.60.
[75] J.-P. Tolvanen. “MetaEdit+: domain-specific modeling for full code generationdemonstrated [GPCE].” In: Companion to the 19th annual ACM SIGPLAN conferenceon Object-oriented programming systems, languages, and applications - OOPSLA ’04.New York, New York, USA: ACM Press, 2004, pp. 39–40. isbn: 1581138334. doi:10.1145/1028664.1028686.
[76] J.-P. Tolvanen. “MetaEdit+: Integrated modeling and metamodeling environmentfor domain-specific languages.” In: Companion to the 21st ACM SIGPLAN confer-ence on Object-oriented programming systems, languages, and applications - OOPSLA’06. Vol. 2006. New York, New York, USA: ACM Press, 2006, pp. 690–691. isbn:159593491X. doi: 10.1145/1176617.1176676.
[77] B. Trask and A. Roman. “Leveraging model driven engineering in software productline architectures.” In: ACM International Conference Proceeding Series. Vol. 20-24-July. 2015, p. 392. doi: 10.1145/2791060.2791081.
111
Bibliography
[78] B. Trask and A. Roman. Leveraging model driven engineering in software product linearchitectures. Vol. 1. New York, New York, USA: ACM Press, 2014, pp. 360–361.isbn: 9781450327404. doi: 10.1145/2648511.2648558.
[79] S. Van Mierlo, B. Barroca, H. b. Vangheluwe, E. Syriani, and T. Kühne. “Multi-levelmodelling in the Modelverse.” In: CEUR Workshop Proceedings. Vol. 1286. 2014,pp. 83–92.
[80] S. Vaupel, D. Strüber, F. Rieger, and G. Taentzer. “Agile bottom-up development ofdomain-specific IDEs for model-driven development.” In: Proceedings of FlexMDE2015: Workshop on Flexible Model-Driven Engineering 1470 (2015), pp. 12–21.
[81] N. Visic, H.-G. Fill, R. A. Buchmann, and D. Karagiannis. “A domain-specificlanguage for modeling method definition: From requirements to grammar.” In:2015 IEEE 9th International Conference on Research Challenges in Information Science(RCIS). Vol. 2015-June. June. IEEE, May 2015, pp. 286–297. isbn: 978-1-4673-6630-4.doi: 10.1109/RCIS.2015.7128889.
[82] M. Voelter. “Integrating prose as first-class citizens with models and code.” In:CEUR Workshop Proceedings. Vol. 1112. 2013, pp. 17–26.
[83] M. Voelter, D. Ratiu, B. Kolb, and B. Schaetz. “Mbeddr: Instantiating a languageworkbench in the embedded software domain.” In: Automated Software Engineering20.3 (2013), pp. 339–390. doi: 10.1007/s10515-013-0120-4.
[84] M. Voelter, J. Warmer, and B. Kolb. “Projecting a Modular Future.” In: IEEESoftware 32.5 (2015), pp. 46–52. doi: 10.1109/MS.2014.103.
[85] M. Völter and E. Visser. “Language extension and composition with languageworkbenches.” In: Proceedings of the ACM international conference companion on Objectoriented programming systems languages and applications companion - SPLASH ’10.New York, New York, USA: ACM Press, 2010, pp. 301–304. isbn: 9781450302401.doi: 10.1145/1869542.1869623.
[86] B. Volz. “A meta model for representing arbitrary meta model hierarchies.” In:Proceedings of the 2010 ACM Symposium on Applied Computing - SAC ’10. NewYork, New York, USA: ACM Press, 2010, pp. 2371–2772. isbn: 9781605586397. doi:10.1145/1774088.1774579.
[87] Z. Wang, Q. Dong, H. He, and F. Fu. “Imprecise domain-specific modeling forC4ISR capability requirements analysis.” In: 2011 International Conference on Infor-mation Science and Technology, ICIST 2011. 2011, pp. 33–38. doi: 10.1109/ICIST.2011.5765205.
[88] J. Webster and R. T. Watson. “Analyzing the Past to Prepare for the Future: Writinga Literature Review.” In: Source: MIS Quarterly 26.2 (2002), pp. 13–23.
[89] A. Yrjönen and J. Merilinna. “Extending the NFR framework with measurablenonfunctional requirements.” In: CEUR Workshop Proceedings. Vol. 553. 2009.
112
A. Literature Review
This appendix contains further details related to the literature review conducted insection 2.2. Section A.1 shows the exact Scopus queries used during the literature search.Section A.2 lists excluded keywords which were determined by analyzing the references’abstracts and keywords to filter out irrelevant references.
A.1. Search Queries
A.1.1. Deep Meta-Modelling
TITLE-ABS-KEY(deep AND (meta-modelling OR meta-modeling OR metamodelling
OR metamodeling) AND (tool OR ide OR framework OR editor)) AND (LIMIT-
TO (SUBJAREA,"COMP ")) AND (LIMIT-TO (LANGUAGE,"English"))
Listing A.1: Deep Meta-Modelling Scopus Query 1
TITLE-ABS-KEY(deep AND (meta-modelling OR meta-modeling OR metamodelling
OR metamodeling) AND (tool OR ide OR framework OR editor)) AND (LIMIT-
TO (SUBJAREA,"COMP ")) AND (LIMIT-TO (LANGUAGE,"English")) AND (EXCLUDE
(DOCTYPE,"cr"))
Listing A.2: Deep Meta-Modelling Scopus Query 2
TITLE-ABS-KEY(deep AND (meta-modelling OR meta-modeling OR metamodelling
OR metamodeling) AND (tool OR ide OR framework OR editor) AND NOT ("
deep drawing" OR "analog circuits" OR biosensors OR "neural network"))
AND (LIMIT-TO (SUBJAREA,"COMP ")) AND (LIMIT-TO (LANGUAGE,"English"))
AND (EXCLUDE (DOCTYPE,"cr "))
Listing A.3: Deep Meta-Modelling Scopus Query 3
113
A. Literature Review
A.1.2. Domain-Specific Modelling Language
TITLE-ABS-KEY((domain-specific AND (modelling OR modeling) AND language)
AND (tool OR ide OR framework OR editor) AND requirements) AND (LIMIT-
TO (SUBJAREA,"COMP")) AND (LIMIT-TO (LANGUAGE,"English"))
Listing A.4: Domain-Specific Modelling Language Scopus Query 1
TITLE-ABS-KEY((domain-specific AND (modelling OR modeling) AND language)
AND (tool OR ide OR framework OR editor) AND requirements) AND (LIMIT-
TO (SUBJAREA,"COMP ")) AND (LIMIT-TO (LANGUAGE,"English ")) AND (
EXCLUDE (DOCTYPE,"cr"))
Listing A.5: Domain-Specific Modelling Language Scopus Query 2
TITLE-ABS-KEY((domain-specific AND (modelling OR modeling) AND language)
AND (tool OR ide OR framework OR editor) AND requirements AND NOT ("
internet of things" OR medicine OR medical OR "assisted living" OR vhdl
OR "artificial intelligence" OR multiagent OR "multi-agent" OR
autocrud OR "cyber-physical systems" OR "embedded systems")) AND (LIMIT
-TO (SUBJAREA,"COMP ")) AND (EXCLUDE (DOCTYPE,"cr ")) AND (LIMIT-TO (
LANGUAGE,"English "))
Listing A.6: Domain-Specific Modelling Language Scopus Query 3
TITLE-ABS-KEY((("domain-specific" PRE/2 (modelling OR modeling) AND (
language OR languages)) OR DSML OR DSMLs) AND (tool OR ide OR framework
OR editor) AND requirements AND NOT ("internet of things" OR medicine
OR medical OR "assisted living" OR vhdl OR "artificial intelligence" OR
multiagent OR "multi-agent" OR autocrud OR "cyber-physical systems" OR
"embedded systems")) AND (LIMIT-TO (SUBJAREA,"COMP ")) AND (EXCLUDE (
DOCTYPE,"cr ")) AND (LIMIT-TO (LANGUAGE,"English "))
Listing A.7: Domain-Specific Modelling Language Scopus Query 4
A.1.3. Language Workbench
TITLE-ABS-KEY(language workbench AND (tool OR ide OR framework OR editor)
AND requirements) AND (LIMIT-TO (SUBJAREA,"COMP")) AND (LIMIT-TO (
LANGUAGE,"English"))
114
A.1. Search Queries
Listing A.8: Language Workbench Scopus Query 1
TITLE-ABS-KEY(language workbench AND (tool OR ide OR framework OR editor)
AND requirements) AND (LIMIT-TO (SUBJAREA,"COMP ")) AND (LIMIT-TO (
PUBYEAR,2017) OR LIMIT-TO (PUBYEAR,2016) OR LIMIT-TO (PUBYEAR,2015) OR
LIMIT-TO (PUBYEAR,2014) OR LIMIT-TO (PUBYEAR,2013) OR LIMIT-TO (PUBYEAR
,2012) OR LIMIT-TO (PUBYEAR,2011) OR LIMIT-TO (PUBYEAR,2010) OR LIMIT-
TO (PUBYEAR,2009) OR LIMIT-TO (PUBYEAR,2008) OR LIMIT-TO (PUBYEAR,2007)
OR LIMIT-TO (PUBYEAR,2006) OR LIMIT-TO (PUBYEAR,2005)) AND (LIMIT-TO (
LANGUAGE,"English "))
Listing A.9: Language Workbench Scopus Query 2
A.1.4. Multi-Level Modelling
TITLE-ABS-KEY(((multilevel OR multi-level) AND (modeling OR modelling))
AND (tool OR ide OR framework OR editor) AND requirements) AND (LIMIT-
TO (SUBJAREA,"COMP ")) AND (LIMIT-TO (LANGUAGE,"English "))
Listing A.10: Multi-Level Modelling Scopus Query 1
TITLE-ABS-KEY(((multilevel OR multi-level) AND (modeling OR modelling))
AND (tool OR ide OR framework OR editor) AND requirements) AND (LIMIT-
TO (SUBJAREA,"COMP")) AND (LIMIT-TO (LANGUAGE,"English")) AND (EXCLUDE
(PUBYEAR,1998) OR EXCLUDE (PUBYEAR,1997) OR EXCLUDE (PUBYEAR,1996) OR
EXCLUDE (PUBYEAR,1995) OR EXCLUDE (PUBYEAR,1992) OR EXCLUDE (PUBYEAR
,1991) OR EXCLUDE (PUBYEAR,1990))
Listing A.11: Multi-Level Modelling Scopus Query 2
TITLE-ABS-KEY(((multilevel OR multi-level) AND (modeling OR modelling))
AND (tool OR ide OR framework OR editor) AND requirements) AND (LIMIT-
TO (SUBJAREA,"COMP ")) AND (EXCLUDE (PUBYEAR,1998) OR EXCLUDE (PUBYEAR
,1997) OR EXCLUDE (PUBYEAR,1996) OR EXCLUDE (PUBYEAR,1995) OR EXCLUDE (
PUBYEAR,1992) OR EXCLUDE (PUBYEAR,1991) OR EXCLUDE (PUBYEAR,1990)) AND
(LIMIT-TO (LANGUAGE,"English ")) AND (EXCLUDE (DOCTYPE,"cr"))
Listing A.12: Multi-Level Modelling Scopus Query 3
115
A. Literature Review
TITLE-ABS-KEY(((multilevel OR multi-level) AND (modeling OR modelling))
AND (tool OR ide OR framework OR editor) AND requirements AND NOT ("
internet of things" OR music OR hospital OR cellular OR "financial
audits" OR antennas OR HLPSL OR "IP cores")) AND (LIMIT-TO (SUBJAREA,"
COMP ")) AND (EXCLUDE (DOCTYPE,"cr ")) AND (EXCLUDE (PUBYEAR,1998) OR
EXCLUDE (PUBYEAR,1997) OR EXCLUDE (PUBYEAR,1996) OR EXCLUDE (PUBYEAR
,1995) OR EXCLUDE (PUBYEAR,1992) OR EXCLUDE (PUBYEAR,1991) OR EXCLUDE (
PUBYEAR,1990)) AND (LIMIT-TO (LANGUAGE,"English "))
Listing A.13: Multi-Level Modelling Scopus Query 4
A.2. Excluded Areas
A.2.1. Deep Meta-Modelling
metamodel-driven measurement (M2DM), OCL integration, automated wizard genera-tion, formal semantics, UML infrastructure, drawbacks of UML and OML
A.2.2. Domain-Specific Modelling
E-Voting, RESTful web services, model-based systems engineering solution (MBSE),business process modeling language selection, Digital to analog conversion, architec-tural requirements modeling, Automotive embedded E/E-systems, Situation theory,Capacity planning, Serious games, ETL workflow specification, Requirements trace-ability, Service-Based Applications, syntax map, System and software engineering lifecycle, requirements modeling, traceability links, quality of service modeling, automatedwizard generation, Aspect-Oriented Modeling, Autonomic Computing (or AutonomicManagement), middleware provisioning, smart oilfields, Object-oriented patterns, highintegrity systems, Digital Libraries, Reverse engineering
A.2.3. Language Workbench
measuring of developer effectiveness, unit test generation, robot application program-ming, quality analysis of software engineering method models, Rich Service DescriptionLanguage (RSDL), implementation of a requirements specification language, CASE toolfor requirements specification,
A.2.4. Multi-Level Modelling
Microgrid, Power modeling, Clinical Decision Support Systems, Geometrical productspecification, Multi-level inverters, Knowledge Service, Software adaptation, Digitallibraries, Distributed software architecture, Information visualization, Data Warehousing,
116
A.2. Excluded Areas
secure workstation for special applications (SWSA), Transaction level modelling, Productredesign, Disaster recovery, photonics modeling, dynamic load balancing, Risk analysisand management, Requirement modeling, Action recognition [Computer Vision], Neuralsubsystems, E-Government, Micro robotics, Simulation models, Tactical planning models,Collaborative systems, Monitoring techniques, Artificial intelligence, Multilevel parallelprogramming, NC machining, Analysis of variance, C4ISR,
117
B. Evaluation of the UI Schema Editor
B.1. Evaluation Schema
1 {2 "type": "object",3 "properties": {4 "firstName": { "type": "string" },5 "lastName": { "type": "string"},6 "email": { "type": "string", "format": "email" },7 "dateOfBirth": {8 "type": "string",9 "format": "date"
10 },11 "timeOfRegistration": {12 "type": "string",13 "format": "date−time"14 },15 "gender": { "type" : "string", "enum": ["Male", "Female"] },16 "nationality": {17 "type": "string",18 "enum": ["UK", "US", "German", "French", "Russian"]19 },20 "alive": { "type": "boolean" },21 "address": {22 "properties": {23 "street": { "type": "string" },24 "street−number": { "type": "integer" },25 "city": { "type": "string"}26 }27 }28 },29 "required": ["lastName", "email"]30 }
Listing B.1: Json Schema for Which a UI Schema Was Created in the Usability Test
B.2. System Usability Scale Items
The following items were used in the questionnaire to determine the SUS score. Theyare directly taken from [12]:
1. I think that I would like to use this system frequently
119
B. Evaluation of the UI Schema Editor
2. I found the system unnecessarily complex
3. I thought the system was easy to use
4. I think that I would need the support of a technical person to be able to use thissystem
5. I found the various functions in this system were well integrated
6. I thought there was too much inconsistency in this system
7. I would imagine that most people would learn to use this system very quickly
8. I found the system very cumbersome to use
9. I felt very confident using the system
10. I needed to learn a lot of things before I could get going with this system
B.3. UI Schema Editor Missing Features
In this section, we list the answers given to the question “In your opinion, which featuresis the editor missing?” which was answered by the participants after finishing theusability test with the generated UI Schema Editor. The following answers were given:
1. Auto create controls based on schema 2. Auto add the initial root element (verticalcontrol) 3. Preview
Preview of the UI schema, support for control generation.
Generate Controls, AutoCompletion on expected Value
No confirmation for item deletion, no clear children option. Icons are not intuitive.Order of controls not ideal. Feels more like building a tree of items than building a UI.
validation propagation on tree, auto name controls based on selected refs in case noname when ref is selected, generate control function similar to EMF Forms, Preview, refselection dialog will become difficult to use for large schemas
B.4. Comparison
In this section, we list the questions and answers for the comparison between the createdUI Schema Editor and the existing JSON Forms Editor. Thereby, the subsection titles arethe posed questions. Empty lines separate the answers of differen participants.
120
B.4. Comparison
B.4.1. Which Editor Did You Prefer and Why?
UI Schema Editor, feels more stable and feature complete
The UI Schema Editor was better:- the tree gives a better overview over the UI schema than the first one- the support in scoping the controls is very helpful- better rule support
The UI Schema Editor (The second one)
JSON Forms Editor for usability & design, UI Schema Editor for feature set.
UI Schema Editor
B.4.2. What Are the Advantages of the Json Forms Editor?
The creation of controls (auto create from the schema)
- Users have an overview over all controls and UI elements that can be added to theschema
Controls are generated, so no path selection needed expect for not working cases
UI layout is logically structured, structuring the view is the (visually) central part of theeditor, which makes sense because it is also the users’ goal.
Controls are easier to add
B.4.3. What Are the Advantages of the UI Schema Editor?
Reference widget, icons, feels more stable and complete
Controls and rules are easier to configure, the layout is less crowded and more intuitive.
better usability, Responsive UI, more stable
Feature set seems to be more complete in terms of schema property support. Responsivedesign allows for mobile use.
Structure is visualized more clearly, easier to use, more stable, better selection of refs,support for properties in nested objects
121
C. Repositories
The public repository of the model-driven JSON editor component is located at: https://github.com/eclipsesource/jsoneditor
It also includes a runnable standalone demo of an Ecore editor. The following tableshows the dependencies of the JSON Editor Framework:
Name Version License URL
Dependenciesajv ^5.2.2 MIT https://github.com/epoberezkin/ajv
bootstrap ^3.3.7 MIT https://github.com/twbs/bootstrap
jquery ^3.2.1 MIT https://github.com/jquery/jquery
jsonforms next MIT https://github.com/eclipsesource/jsonforms
lodash ^4.17.4 MIT https://github.com/lodash/lodash
materialize-css ^0.100.1 MIT https://github.com/Dogfalo/materialize
Development Dependenciesawesome-typescript-loader ^3.1.3 MIT https://github.com/s-panferov/awesome-typescript-loader
copy-webpack-plugin ^4.0.1 MIT https://github.com/webpack-contrib/copy-webpack-plugin
lite-server ^2.3.0 MIT https://github.com/johnpapa/lite-server
ncp ^2.0.0 MIT https://github.com/AvianFlu/ncp
source-map-loader ^0.1.6 MIT https://github.com/webpack/source-map-loader
tslint ^5.6.0 Apache-2.0 https://github.com/palantir/tslint
typescript ^2.4.0 Apache-2.0 https://github.com/Microsoft/TypeScript
webpack ^2.4.1 MIT https://github.com/webpack/webpack
webpack-dev-server ^2.7.1 MIT https://github.com/webpack/webpack-dev-server
As described in section 4.4, missing functionality was directly contributed to JSONForms 2. In fact, due to architectural advantages, the majority of the implementationwas directly contributed to JSON Forms 2, not to the JsonEditor repository. JSON Forms2 is located in the JSON Forms repository at the branch jsonforms2. This can be foundhere: https://github.com/eclipsesource/jsonforms/tree/jsonforms2Note: Due to release cycles of the industry partner, not all code developed in this thesisis merged at the moment of turning in this thesis. However, it is available in the publicpull requests of the repository.
123
