“Metamodel” and “schema” are terms that get thrown around when we talk about systems and modeling of systems. But what do they really mean?
“Meta” comes from the Greek and literally means “above” or “beyond,” but has also come to mean “about” or “of,” so a metamodel is a model of other models. The term “schema” has its origins in psychology, and describes the organizational patterns of thought. A schema identifies categories of information and the relationships between them. In the sense in which we use these terms, the metamodel (model of models) can be thought of as the framework in which models are conceived, while a schema is that framework instantiated in a database ready to receive the constructed model.
It is interesting to note how similar the definition of a schema is to the definition of a system. A system is also defined as a set of objects and their relationships. So by applying some variable substitution, we see that a schema is essentially a system in its own right. In the world of information science, a schema is defined as an organizational model for databases.
Schemas are domain-specific. Schemas can be developed for various domains: business, education, and organizational. Schema, informal or formal, that deal with the same domain, differ in their respective semantic strengths, or the scope and depth of the objects and relationships they identify. In our context, we are thinking in the systems domain, or better yet, our systems engineering domain.
As for model-based systems engineering, or MBSE, the goal is to use a model to guide the development of a system. To build system models consistently across a community of systems engineers, we need another over-arching model. We call a model that can describe the set of system models, a systems metamodel. A metamodel is not an aggregated or less detailed view of other models; rather, a metamodel is a model at a higher level of abstraction, but without specific information or content. As we said above, the metamodel becomes a schema which, instantiated in the database, provides the framework in which to build the development model of our system.
At Vitech, our approach for a systems metamodel is an entity-relationship-attribute model that describes the systems engineering domain which allows us to conduct systems engineering in a disciplined, formal manner. A formalized systems metamodel helps to ensure that everyone uses the entities, relationships, and attributes in a consistent way when describing systems and systems engineering efforts.
Another benefit of such a metamodel is that it allows for a system model to be checked for syntactic correctness using automated algorithms that implement the rules and constraints defined by the metamodel. The metamodel/schema also helps tools automatically render diagrams to help us visualize our system model according to a notation set or modeling language. In addition, metamodels ease the burden of exchanging data between tools or with developing application interfaces.
To summarize, a systems metamodel is composed of objects or entities, relationships, and attributes organized as notionally depicted in the following figure. (Note: attributes describe the other two elements of the model.)
In the next figure, the systems metamodel is instantiated into a database repository as a schema. Users enter data in form of class entities, relationships between entities, and attributes. The data and the database repository form a single system model. Ultimately, it is the system model that we use as systems engineers to guide the development of our system.
As depicted in the following figure, the system model is the source for diagrams that are used to visualize the system model and for reports that document the systems engineering journey. The schema used for the system model also allows a systems engineering tool to implement the systems model and interpret the data in the repository by automatically rendering diagrams according to a defined notation or modeling language.
A systems metamodel should be structured to define the essential nature of the systems engineering domain without unnecessary ideas or relationships. Through the semantic strength of the systems model we gain the power to build our case for effective development of our system. It provides a natural language with which humans can communicate consistently, which can be followed by automated algorithms, and used to connect engineering tools in a digital engineering environment. Finally, the systems metamodel powers MBSE and provides us a means to move beyond document and diagram-based engineering.