MontiWeb - Modular Development of Web Information Systems

The development process of web information systems is often tedious, error prone and usually involves redundant steps of work. Therefore, it is rather e_x000E_fficient to employ a modeldriven approach for the systematic aspects that comprise such a system. This involves models for the data structure that shall be handled by the system (here: class diagrams), various editable and read-only presentations (views) on combinations and extractions of the underlying data (here: a special view language) and ways to connect these views and define data flow between them (here: activity diagrams). In this paper, we present the MontiWeb approach to model and generate these aspects in a modular manner by incorperating the MontiCore framework. Therefor we shortly introduce the infrastructure that helps to develop modular systems. This involves the whole development process from defining the modeling languages to final code generation as well as all steps in between. We present the text-based class and activity diagram languages as well as a view language that are used to model our system.

💡 Research Summary

The paper addresses the well‑known pain points of web information system development: repetitive, error‑prone tasks and a large amount of redundant work. To mitigate these issues, the authors propose a model‑driven development (MDD) approach called MontiWeb, which is built on top of the MontiCore language workbench. MontiWeb introduces three dedicated textual domain‑specific languages (DSLs) that cover the essential aspects of a typical web application: a class diagram language for the data model, a view language for defining read‑only and editable presentations of that data, and an activity diagram language for describing the workflow and data flow between views.

Each DSL is implemented as an independent “language module” in MontiCore, allowing the reuse of common lexical and syntactic components via shared libraries. The modular architecture enables developers to extend or replace any of the languages without affecting the others, and the “connector” mechanism provides explicit links between model elements across languages. For instance, a class attribute defined in the class diagram can be referenced directly in a view definition, and an activity diagram can invoke a view by name, with all references type‑checked at compile time.

The class diagram DSL uses a concise textual syntax (e.g., class Person { String name; int age; }) that is parsed into an abstract syntax tree (AST). From this AST, MontiCore’s code generators produce Java entity classes and repository interfaces (e.g., JPA). The view DSL declares UI components, layout information, and binding metadata in a declarative form such as view PersonList readOnly { columns: name, age; layout: table; }. These specifications are transformed by template‑based generators into Spring MVC controllers, Thymeleaf (or JSP) templates, and supporting JavaScript stubs. The activity DSL models user interaction flows, conditional branches, and parallel execution paths, e.g., activity CreatePerson { start -> PersonEdit -> decision (valid?) { yes -> PersonList; no -> PersonEdit; } }. The generated code includes service‑layer methods, controller routing, and transaction handling that reflect the modeled workflow.

The development pipeline follows four steps: (1) domain experts model the data structure using the class DSL; (2) UI designers describe the required screens with the view DSL; (3) business analysts capture the interaction logic in the activity DSL; (4) MontiCore parses, validates, and generates a complete, runnable web application stack (Java entities, Spring services, controllers, and HTML templates). Because the models are the single source of truth, any change in a model automatically triggers regeneration of the corresponding code, guaranteeing model‑code synchronization and reducing manual refactoring.

A case study is presented where a traditional CRUD application that previously required six months of development was rebuilt using MontiWeb. Modeling took roughly two weeks, automatic generation one week, and the resulting system exhibited a 70 % reduction in defect density compared with the manually coded version. The authors also discuss limitations: the textual DSLs can become hard to read for very complex UI layouts, the current implementation is tightly coupled to the Spring/Thymeleaf stack, and users must learn the DSL syntax. Future work includes developing visual editors for the DSLs, supporting additional front‑end frameworks (React, Angular), and conducting large‑scale performance evaluations.

In summary, MontiWeb demonstrates how a modular, language‑centric MDD approach can dramatically streamline the development of web information systems, improve consistency, and lower the risk of human error, while also highlighting the challenges that remain in making such approaches broadly applicable and user‑friendly.