Managing a 4-Layer Architecture for Conceptual Modelling

Primary Issues Discussed

Four-Layer Architecture (or 4-Layer Architecture) is used for things like the Object Management Group’s (OMG’s) Meta-Object Facility or MOF.

In its simplest form, the 4-Layer Architecture of the MOF is drawn as below:

MOF 4-Layer Architecture. Image courtesy copyright free from Wiki Commons and Wikipedia.

Along with the OMG’s XML Metadata Interchange (XMI) that allows metamodels and their data to be expressed in XML (Extensible Markup Language), 4-Layer Architecture has found its way into many conceptual modelling pieces of software, at least as a token gesture (in supporting XMI for model interchange), or as central to the software itself, such as in FactEngine’s Boston software.

That is, it is conceivable that conceptual modelling software stores models (as data) along with their metamodel outside a central M3 meta-metamodel, but still uses the XMI to exchange models.

When a 4-Layer Architecture has been implemented in full, with all data (models, metamodels and M0 objects) stored within an M3 meta-metamodel, we can achieve remarkable things, such as morphing between 5 different types of conceptual modelling language:

Five (5) Languages Stored within one Meta-Metamodel (M3 Layer of a 4-Layer Architecture). Image by author.

In the Boston conceptual modelling software, the implementation of a 4-Layer Architecture is called the Richmond Architecture, that I write about [here].

The Richmond Architecture uses the metamodel of Object-Role Modeling to store MetaModels, Models and Instances/Data within that one meta-metamodel:

The Richmond Architecture. Image by author.

As you can imagine, that is a lot going on within one data structure.

The Problems with Managing a 4-Layer Architecture

The problems with managing a 4-Layer Architecture can be most easily seen by first looking at the advantage of using a 4-Layer Architecture.

A significant advantage of using a central 4-Layer Architecture within conceptual modelling software is that different conceptual modelling languages can use/re-use the same metamodel to store models.

While not easily seen to most people professing to be experts on graph databases, the Property Graph Schema of graph databases share a metamodel homomorphic approaching isomorphic with the metamodel of Entity Relationship Diagrams. I.e. They are, for all purposes, and in practice, the same thing.

The following animated gif shows jumping from the M1 (model) layer of an Entity Relationship Diagram, to its M2 metamodel…changing the language of interpretation to “Property Graph Schema” and then reopening the model to be viewed as a Property Graph Schema:

Click to enlarge. Software playing an Ehrenfeucht Fraisse Game. Image by author.

I write about how that is achieved, [here].

This isn’t problematic for conceptual modelling languages sharing the same metamodel, what is problematic is managing changes to M2 layer metamodels.

The M3 meta-metamodel layer always stays the same. For instance, within the Boston conceptual modelling software the meta-metamodel has remained relatively static for 15 years and more-or-less fixed in its form since the commercial release of Boston in 2015 (10 years).

What does this mean?

Version control of models out-in-the-wild (models in files with customers and on customer computers) is the central problem with managing a 4-Layer Architecture for conceptual modelling software.

Not only do models stored in files (say XMI files) need to be versioned, as to the version of the metamodel they adhere to, but also on the odd chance that the M3 meta-metamodel structure changes, that must also be managed too.

Version control of software is a well-known problem, and version control of database structure for software (with accompanying upgrades) is also well known. But what happens when the models of conceptual modelling software are stored in files?

In this case, if the software reading those files is upgrade, and requires a later version of the M3 or M2 layer metamodels, then the software will be out of sync with the files that store the models that go into the M2 layer.

So, the software must either support multiple versions of M2 metamodels, or upgrade the files to match the new M2 metamodels at some future/current state in time.

But why is this a problem?

Upgrading schema, as discussed, is a well-known problem, however how the schema and data is upgraded is the real problem.

For instance, theoretical considerations of model transformation are well-known, and include using the theory of relational algebra etc, but putting that into practice is quite difficult. Just ask any database vendor!

Languages like SQL and Cypher offer model transformation capabilities, and if the M3 and M2 layers of a 4-Layer Architecture are within a relational database, for instance, then SQL can be used to manipulate schema/data once it is in memory and within a database, however files are not within a database, and if the database has changed via a software upgrade therein lies a real problem.

For instance, a file may comply to a certain M3 layer structure, however the M2 layer model within the file may not match the current version of the M2 layer metamodel.

So, either all of the M2 layer metamodel version numbers match the version number of the M3 layer metamodel, or versioning of the M2 layer metamodel must also be done.

In short, this is a very complex problem. FactEngine, within the Boston software, has managed this problem by settling on versioning the M3 layer metamodel, and it representing a timestamp of all the versions of the M2 layer metamodels it contains.

Synopsis

This article might not benefit anyone not intimately aware of the problems associated with managing a 4-Layer Architecture. As an article, I could go into fine detail about what is in each layer of the architecture, and more details about metamodels.

For that, I will leave links to other Medium articles I have written on the topic, and if you are interested in 4-Layer Architectures, if you read them, you will gain insight into the complexities of a 4-Layer Architecture and its management:

1. The Richmond Architecture
2. The Importance of the Object-Role Modeling Metamodel
3. Applied Use of Ehrenfeucht Fraisse Games
4. The Secret of the Boston Meta(Meta)Model
5. Morphing Conceptual Models
6. Two-Stage Interpretation in Formal Logic
7. The Importance of Conceptual Modelling in Data Management
8. What is a Graph Database?
9. State Transition Diagrams and Object-Role Modeling
10. A Call for a Property Graph Schema Standard
11. The Boston Object-Role Modeling Metamodel Pt.1 — Concepts
12. The Boston Object-Role Modeling Metamodel Pt.2 — Value Types
13. The Boston Object-Role Modeling Metamodel Pt.3 — Entity Types
14. The Atoms of Knowledge
15. What is Formal Logic?
16. All of Logic is a Game

================End===============