The Richmond Architecture
4-Layer Architecture for Conceptual Modelling — Based on Object-Role Modeling
The Richmond Architecture is 4-Layer Architecture for Conceptual Modelling — Based on Object-Role Modeling.
At the abstract level it resembles the 4-Layer Architecture of the Object Management Group’s Meta-Object Facility, excepting that the M3 (topmost) layer is the metamodel of Object-Role Modeling.
Within the M3 layer is injected the metamodel of various conceptual modelling languages, and any conceptual modelling language that can be defined in terms of a first-order logic. The metamodels represent a M2 layer, instances of the metamodels, as actual conceptual models are the M1 layer, and the M0 layer is simply the objects (real-word or digital) that are instances of the entities defined in the M1 (metamodel) layer.
So we have a classic, meta-metamodel (M3), metamodel (M2), model (M1) and object (M0) layered architecture.
The Boston conceptual modelling software by FactEngine is an implementation of the Richmond Architecture.
The Richmond Architecture is depicted pictorially at the top of this article, and that of the Meta-Object Facility below:
What can you do with the Richmond 4-Layer Architecture?
Anything that can be achieved by the Meta-Object Facility architecture can be achieved by the Richmond Architecture, including import and export of XMI (XML Metadata Interchange) schema/documents if one wanted to.
The full UML (Unified Modeling Language) could be stored within the Richmond Architecture. BPMN (Business Process Modelling Notation) can be stored in the Richmond Architecture, and Object-Role Modeling, Entity-Relationship Diagrams, Property Graph Schema can be stored within the Richmond Architecture. Any conceptual modelling language the metamodel of which is reducible to theorems of a first-order logic can be stored within a Richmond Architecture and presented in compatible software.
How is the Richmond Architecture Used?
The Boston conceptual modelling software by FactEngine uses the Richmond Architecture to store and present Object-Role Models, Entity-Relationship Diagrams, Property Graph Schema, Use Case Diagrams and State Transition Diagrams at this stage.
The metamodel of Object-Role Modeling was used for the meta-metamodel/metamodel layer of the Richmond Architecture, because Object-Role Modeling is among the most expressive conceptual modelling languages in existence, and if Boston going to present Object-Role Models then a natural fit is the metamodel of Object-Role Modeling for the M3/M2 layers.
Why a combined M3/M2 Layer?
The reason why there is a combined M3/M2 Layer (at the conceptual level) is because the way that the architecture is viewed, depends on how the architecture is used.
When simply using the Richmond Architecture for Object-Role Models, there is actually only three (3) conceptual layers, as below. But when using the same database (the metamodel of Object-Role Modeling) to store M2 metamodels of other conceptual modelling languages, the same architecture, database or XML/JSON stores those M2 metamodels as instances of Object-Role Models within the ORM Metamodel.
On the left-hand side of the image above, the Object-Role Model (effectively stored at the M2 layer) is simply an standard-run-of-the-mill Object-Role Model stored within the M3 metamodel.
But when a M1 State Transition Diagram (right-hand side of the image above) is stored within the same architecture, it is stored as instance data within an Object-Role Model that is the metamodel of a State Transition Diagram (M2 layer), which is stored within the metamodel of Object-Role Modeling, that metamodel now operating as a M3 meta-metamodel.
So it depends on how the 4-Layer Richmond Architecture is used.
Conceptually, this relies on the combination of Game Theory, Communication Theory and Logic.
This may be better represented in our architecture as:
The intersection of Communication Theory, Game Theory and Logic is where the action is when using a 4-Layer/Richmond Architecture.
It is a unification, because the actual interpretation of a conceptual model is up to the interpreter (human or machine) and is not a function of drawings or theorems of a theory of logic expressed on a piece of paper or a computer screen. This may be presented as below, where two people are both looking at an Object-Role Model, but each person forms their own interpretation of the model, which may be based on a shared understanding of the theory under which the model was expressed in the first place. In this instance the theory and rules of inference of Object-Role Modeling (and as somewhat prefixed by the 1989 PhD Thesis of Terry Halpin, effectively formalising NIAM, the precursor of ORM):
Because Object-Role Modeling ostensibly sits under finite-model theory, and so too does the metamodel of Object-Role Modeling, itself expressible as an Object-Role Model, Ehrenfeucht Fraisse Games (EFGs) can be played over theorems (as data within the database/metamodel) stored within the metamodel.
It is up to the user of the software implementing the Richmond Architecture how the models are interpreted, and if there is an isomorphic mapping between the various interpretations, then we have a clear communication in what I call a Coherent Cooperative Game.
Which is to say, if I interpret an ORM diagram as an ORM diagram and as per the inference rules of ORM, and you do too, and we converse about the model for a period of time with no differing interpretation (moves in an EF Game) then we have the same interpretation, a Coherent Cooperative Game, and we have unified Game Theory, Communication Theory and Formal Logic.
In the same token, because first-order logics may be interpreted as higher-order logics, we can also have the basis of a Game Theoretic Approach to Formal Logic. I.e. We treat logic as a game in itself, with the tokens passed between players as the theorems written on a piece of paper, or as they appear within data stored (as effective theorems of first-order logic under finite model theory say) within a database, XML/JSON file or other storage-and-retrieval or data transmission mechanism. The exchange of tokens then being a communication, linking Game Theory, Communication Theory and Formal Logic and the process of engaging in formal logic a game played by one person or by multiple players.
The Boston conceptual modelling software exploits this to have multiple languages stored within one-metamodel, the metamodel of ORM, and the Boston software itself a player, variously interpretting different conceptual modelling languages that are in effect ORM diagrams expressible as theorems of a theory of first-order logic under finite model theory. Effectively adopting a principal that all databases are multi-model depending on how they are interpreted.
In laymans terms, we get this:
…or this:
In laymans terms again…the whole purpose of conceptual modelling is to form a shared understanding of a model:
This is also the domain of what I call the Model Exchange Problem:
That is, if you want a single exchange metamodel that can handle various conceptual modelling languages, or any language/syntax/objects reducible to theorems (as data) of a first-order theory, and (to some factor) under ostensible Finite Model Theory, then a 4-Layer Architecture such as the employed as the Richmond Architecture metamodel is the most compact method of defining that exchange metamodel, because it has at the M3 layer one-single metamodel, in itself a model, that can store and be used to transmit/exchange any conceptual model or language/syntax/object reducible to theorems (as data) stored within that model.
Object-Role Modeling, and its metamodel can do this because Object-Role Modeling has provision for data (sample populations) to be stored right along side the Object-Role Model itself (whether at the M3 layer or the M2 layer), as below:
This means that one can get lost focusing solely on first-order logic, when an interpreter can variably interpret theorems under a FOL as under higher-order logic. This is not a problem if the sender and receiver of a message (model exchange) have the same interpretation and where data is apprpropriately flagged as to the language of its interpretation:
That is…we simply flag each M2 Metamodel with the language of its intended interpretation:
For instance, the Boston software, various pages (models) as under various languages, are all stored as ORM models, but they are flagged as to the language of their intended interpretation, so one may be an ORM diagram, another an ER Diagram, another a Property Graph Schema, another again a State Transition Diagram or a UML Use Case Diagram. So long as the intended language of interpretation is flagged at the M2 Metamodel Layer, of the actual data of the model (M1 within the M2 layer) we can have a clear communication between players.
What that means is, that any M1 model, can be viewed as the data within its M2 metamodel. If two languages share the same metamodel (as do Entity Relationship Diagrams and Property Graph Schema in Boston), and are homomorphic, approaching isomorphic, then we can simply change the intended interpretation language and view the same Page (m1 model) as two different languages. The software, or interpretter, playing the duplicator in an Ehrenfeucht Fraisse Game, as below:
What does all this mean?
As above, and in the same way that a Relational Database, such as ORACLE, can be used to store an infinite variety of different database schema (as models), the metamodel of Object-Role Modeling can store an infinite array of different conceptual modelling languages if and only if those individual languages can be reduced to theorems of first-order logic, and in ORM ostensibly under Finite-Model Theory.
I call this the Infinity Fountain:
What is represented by the Infinity Fountain is that theorems of first-order logic go in…and the interpreter of those theorems can interpret them the exact same was as the person/computer stored and intended for their interpretation, but that there may be (over the range of possible sets of theorems) an infinite variety of interpretations.
For our purposes, a 4-Layer Richmond Architecture does not deal with the infinite. We only need store theorems of models of as many languages as we intend to use for our purposes, be that within a piece of software like Boston, or for model interchange/exchange.
Proof of Requirement-for/Utility-of of a 4-Layer Architecture
Effectively the Richmond Architecture is proof that a 4-Layer Architecture, as per the OMG’s Meta-Object Facility, is required to implement multiple-language interpretation from a single superstructure/architecture.
This is exploitable for conceptual modelling, data/schema interchange and software that processes data under a 4-layer architecture that does both.
And that is the Richmond Architecture.
Thank you for reading. As time permits, I will write more on Object-Role Modeling, Ehrenfeucht Fraisse Games, the unification of Game Theory, Communication Theory and Logic, Entity-Relationship Diagrams, Property Graph Schema and various other languages, all relating to the Richmond Architecture.
=======================End======================
