Domain Model in DSML-Based Development
- Domain Model is the conceptual backbone in DSMLs, clearly separating domain concepts from technical implementation to encapsulate project-specific knowledge.
- MontiCore formalizes the domain model by generating parsers and metamodels, ensuring a consistent mapping from DSML definitions to executable artifacts.
- Agile DSML-based development assigns explicit roles to language, tool, library, and product developers, enhancing collaboration and maintaining a clear separation of concerns.
Searching arXiv for the primary paper and closely related context on DSML/agile modeling. "Roles in Software Development using Domain Specific Modeling Languages" examines how domain-specific modelling languages (DSMLs) can organize software development around a strict separation between the conceptual description of a solution and its technical realization, and how this separation can be operationalized through explicit development roles in an agile process (Krahn et al., 2014). In this setting, the domain model is not presented as a standalone textbook artifact, but as the conceptual backbone embodied in DSML definitions, their abstract syntax and semantics, and the project-specific models written by product developers. Using the MontiCore framework, the paper describes how DSMLs, generators, libraries, and role-specific responsibilities combine to turn domain concepts into executable systems, illustrated with automotive HMI software (Krahn et al., 2014).
1. Domain-specific modelling languages as the conceptual backbone
The central premise is that DSMLs "successfully separate the conceptual and technical design of a software system by modelling requirements in the DSML and adding technical elements by appropriate generator technology" (Krahn et al., 2014). Within that separation, the conceptual side consists of domain concepts and their relationships, while the technical side consists of implementation artifacts such as code, libraries, and generators. This yields a development organization in which models express project-specific knowledge or problem descriptions, and generators map those models to a running solution (Krahn et al., 2014).
In this usage, the domain model is present in the vocabulary, structure, constraints, and semantics of the DSMLs. It is captured in language definitions, instantiated by models written for a concrete product, and realized through generator and library technology. The paper therefore treats the domain model as a first-class development artifact, but not primarily as a separate diagrammatic deliverable; rather, it is embodied in the modelling languages themselves and in the project-specific models derived from them (Krahn et al., 2014).
The paper emphasizes that the main benefit of the described process is the "strict separation of the description of a solution on a conceptual level and its technical realisation" (Krahn et al., 2014). This separation is also the basis for dividing work among roles with different competencies, allowing contributors with domain expertise, language-engineering expertise, tooling expertise, and library expertise to collaborate without collapsing all concerns into source code.
2. MontiCore and the formalization of the domain model
MontiCore is used to define DSMLs by specifying their concrete syntax as a context-free grammar (Krahn et al., 2014). From this definition, MontiCore generates a lexer/parser pair via ANTLR and also generates the internal representation of the language—its abstract syntax or metamodel—in the form of Java classes (Krahn et al., 2014). The language developer then adds further constraints and semantics.
This means that the domain model is encoded at several levels. The grammar specifies what domain concepts exist and how they may be composed; the generated abstract syntax or metamodel provides the structured representation of those concepts; and the additional semantic work determines what those concepts mean beyond mere syntactic recognition (Krahn et al., 2014). The paper explicitly notes that "it is important that the semantics of a language is not only defined by describing how the generator handles it" (Krahn et al., 2014).
A plausible implication is that the abstract syntax functions as a domain-specific type system. Each nonterminal in the grammar induces a corresponding structural concept in the metamodel, and relations in the grammar induce relations in the generated representation. In the automotive HMI setting discussed in the paper, this applies to concepts such as menus, dialogs, status boxes, user inputs, and feature configurations (Krahn et al., 2014).
The process differs from a multi-level Model Driven Architecture workflow in which models are repeatedly transformed through several abstraction levels and generated artifacts may require manual edits. Instead, the paper advocates using models and code "at the same level of abstraction" and treating them as descriptions of orthogonal parts of the system (Krahn et al., 2014). This reduces the need for round-tripping and preserves regeneration as a routine operation.
3. Development roles and their responsibilities
The paper's primary contribution is the explicit identification of roles in an agile DSML-based development process (Krahn et al., 2014). These roles partition responsibility along the conceptual/technical boundary and clarify how domain knowledge is captured, formalized, and executed.
| Role | Main responsibility | Typical artifacts |
|---|---|---|
| Language developer | Defines DSMLs and their semantics | Grammars, constraints, manuals |
| Tool developer | Builds generators and tool chains | Code generators, analysis tools |
| Library developer | Encapsulates reusable domain knowledge | Domain-specific libraries |
| Product developer | Creates project-specific models | Feature models, menu models, tests |
The language developer formalizes domain knowledge into DSMLs. In the HMI example, after discussions with product developers, a language developer designs a DSML definition for Menu Diagrams using concepts such as "menus, dialogs, status boxes and user inputs" that correspond directly to the manufacturer's terminology (Krahn et al., 2014). The same role also introduces Feature Diagrams, which model common and variable features and the interdependencies between them (Krahn et al., 2014). This role therefore shapes the conceptual domain model itself.
The tool developer realizes the mapping from models to executable artifacts. Using MontiCore-generated language processors and the DSLTool framework, the tool developer integrates processors for the Feature DSML and Menu DSML and adds a manually written generator that transforms these models into HMI software (Krahn et al., 2014). This role operationalizes the semantics of the DSMLs through code generation, model analysis, and overall tool-chain assembly.
The library developer provides reusable domain-specific functionality that simplifies code generation. The paper states that "one aim of a library is to encapsulate detailed domain knowledge and provide a simplified interface that is sufficient for the needs of the code generation" (Krahn et al., 2014). In the automotive case, an HMI library contains reusable code parts, allowing the generator to configure the library rather than synthesizing all behavior from scratch (Krahn et al., 2014).
The product developer instantiates the domain model for concrete products. The paper distinguishes subroles such as the feature modeller, who describes feature sets specifying possible configurations of a type series, and the HMI-developer, who designs a menu structure for certain type series of cars (Krahn et al., 2014). These modelers express domain knowledge directly in DSMLs rather than in general-purpose programming languages.
4. Process structure and combination of models with source code
The process begins with domain analysis and DSML definition. Language developers, together with product developers or domain experts, identify relevant concepts and define DSMLs such as Feature Diagrams and Menu Diagrams in MontiCore (Krahn et al., 2014). MontiCore then generates language infrastructure, including parser components and abstract syntax representations, after which tool developers integrate the processing components into an executable tool chain (Krahn et al., 2014).
Product developers use these tools to create project-specific models. Code generators consume the models, configure domain libraries, and produce code. Handwritten code remains part of the system, but it covers concerns outside the DSML scope rather than serving as an editable target of model transformations (Krahn et al., 2014). The paper states that developers "do not round-trip engineer and switch views between code and models, but use models and handwritten code as descriptions of orthogonal parts" and that they "do not look at or modify any form of generated code" (Krahn et al., 2014).
This organization yields clear generation boundaries. Domain models remain free of technical boilerplate, while generators and libraries absorb technical detail. The generator configures reusable libraries according to the models, and handwritten code integrates at defined extension points (Krahn et al., 2014). In the HMI case, the paper describes this explicitly: the HMI library contains reusable code parts, and the generator "simply configures the HMI library to form a specific HMI software" (Krahn et al., 2014).
The paper also contrasts this with MDA-style multi-level transformations that complicate regeneration when intermediate artifacts are manually edited. By keeping models and code at the same abstraction level and assigning them orthogonal responsibilities, the proposed process supports repeated generation without compromising maintainability (Krahn et al., 2014).
5. Agile development and iterative evolution of DSMLs
The described method is explicitly framed as agile. It adopts concepts associated with Extreme Programming, including "on-site customer, test-first, early feedback" while centering development on executable models used for production and test code generation (Krahn et al., 2014). Product developers play a role analogous to on-site domain experts, because they work directly with the DSMLs and can evaluate generated systems early.
A key mechanism is immediate feedback from generated running systems. The paper notes that the running system produced by the generator allows the product developer to gain insights into system behavior and provides "immediate feedback" (Krahn et al., 2014). This supports iterative refinement: product developers revise models, language developers adapt the DSML where necessary, and tool and library developers update the technical realization.
Continuous integration is also integral to the method. MontiCore and project-specific tools can be rebuilt automatically after changes, and automated tests run at different granularities (Krahn et al., 2014). The paper further notes that all roles are expected to use test-first techniques and that tests may themselves be expressed as DSML models (Krahn et al., 2014).
A plausible implication is that the domain model and the DSML cease to be fixed design-time assets and instead become living artifacts. This distinguishes the approach from processes that assume relatively stable metamodels and transformation chains. Here, language definitions, models, generators, and libraries co-evolve under frequent regeneration and testing (Krahn et al., 2014).
6. Automotive HMI case study and its implications
The automotive HMI case study illustrates how the process distributes domain knowledge across languages, tools, libraries, and models. The domain includes menu structure, dialogs, status boxes, user inputs, and feature variability, including features such as navigation system, organizer, communication adapter, ventilation, and air conditioning (Krahn et al., 2014). Two DSMLs are used: Menu Diagrams for HMI structure and behavior, and Feature Diagrams for product-line variability (Krahn et al., 2014).
The Menu Diagrams DSML captures the concepts used by the manufacturer for HMI design, while Feature Diagrams model common and variable features and their dependencies (Krahn et al., 2014). Feature diagrams are described as essentially trees of features whose edges encode mandatory or optional inclusion, with alternative decorations denoting constrained choices (Krahn et al., 2014). The project also uses a textual notation for feature diagrams to integrate easily with tools (Krahn et al., 2014).
The case study makes the role interaction concrete. Language developers define the DSMLs; tool developers assemble processors and generators; library developers provide the HMI library; product developers author feature and menu models and can generate and simulate HMI software "without further help of IT experts" (Krahn et al., 2014). This demonstrates how a diverse group of developers with different skills can collaborate through a shared domain-specific formalization (Krahn et al., 2014).
The benefits claimed in the paper follow directly from this arrangement. They include separation of concerns, improved collaboration across roles, higher productivity and reuse through reusable DSMLs and generators, maintainability through non-editable generated code, and executable domain models that support early feedback (Krahn et al., 2014). The paper also implies several limitations: DSML and generator evolution requires coordinated changes, DSML design is difficult, organizations may need to integrate tool and language developers more closely into agile teams, and the semantics are not formalized explicitly within the paper itself (Krahn et al., 2014).
Taken together, the paper presents DSML-based development not merely as a notational choice but as an organizational and technical process in which the domain model is progressively transformed into languages, tools, libraries, and running systems. The central claim is that this transformation is most effective when conceptual and technical concerns are separated rigorously and when responsibilities for each are assigned explicitly to specialized roles within an agile workflow (Krahn et al., 2014).