Models Often Become Too Large

Contrary to what is common in the world of Domain Specific Languages (DSLs) we believe that a model is often too large to handle. When dealing with source code, the times have long gone that a complete application was written in a single file. Since the 1980s every self-respecting programming language has supported some kind of modularization. It is our strong conviction that this approach should also be taken when dealing with models.

Introducing Model Units

Similar to how the source code for a single application is split into classes and/or modules, every model in Freon is split into model units. Each model may contain units of multiple types, either an array of units, or a single unit. The next example shows how to define model units. Here, an InsuranceModel consists of a list of Parts and a list of Products.

// docu-project/defs/language-main.ast#L7-L20

model InsuranceModel {
    parts: Part[];              // units that hold partial definitions of insurance products
    products: Product[];        // units that hold sellable insurance products
}

modelunit Part {
    part: BaseProduct;          // one collection of partial insurance products
    file-extension = "base";    // the file extension used by the parser
}

modelunit Product {
    product: InsuranceProduct;  // one collection of sellable insurance products
    file-extension = "prod";    // the file extension used by the parser
}

The notion of model units has been around for some time. Actually, we have published a number of papers on the topic.

• At Eclipse Summit 2008 Modeling Symposium model units were introduced in Big Models an Alternative Approach.
• Earlier, model units were described under the term ‘Partial Models’ at the ECMDA-FA 2007 conference in a paper called Building a Flexible Software Factory Using Partial Domain Specific Models.
• More recently model units have been used within the Mendix meta-model to allow for working with large models in their web based modeling tools. This work was presented at Splash 2016 in _Making Mendix Meta Model Driven_.

Model Unit Interfaces

Another essential idea that we borrow from programming is information hiding. Every model unit in Freon defines an interface. The interface determines which elements from the model unit are visible (i.e. can be referred to) in other units in the same model.

In a Freon definition of the language structure (the .ast file) concepts and properties can be defined to be private. Whereas other parts of a model unit can be referenced from another model unit,i.e. the public parts, private parts can only be referenced from the same model unit. The default scoper (the one from the default level) already takes the difference between public and private concepts and properties into account when resolving references.