Reference Models and Conformance: Definition and Example

Why Reference Models?

In many discussions and publications, we recognize the use of the term “reference model”. There are “technical reference models”, “business reference models”, the “ISO/OSE 7 layer communication reference model”, “enterprise architecture reference models”, “performance reference models”, and many more. Occasionally even meta-models seem to be used as reference models.

In [GR21d], we have raised the question of whether it is possible to leverage this notion of a reference model. In particular:

How can the notion of a reference model, explicitly denoted in a given modeling language, be formalized together with a precisely defined and tool-assisted notion of a conformance relation that would enable concrete realizations of the reference model?

And here would like to give some comments on this discussion.

Reference Model in the Common Literature

The definition from [Wikipedia] is (as of Sept. 2022): “A reference model—in systems, enterprise, and software engineering—is an abstract framework or domain-specific ontology consisting of an interlinked set of clearly defined concepts produced by an expert or body of experts to encourage clear communication. A reference model can represent the component parts of any consistent idea, from business functions to system components, as long as it represents a complete set. This frame of reference can then be used to communicate ideas clearly among members of the same community.”

Critics on the above Definition of Reference Model

In full consideration, we are not completely satisfied with this definition. Firstly, even a reference model is a “model.” According to our understanding of the general definition of “model” (which is based on Stachowiak [Sta73],

• (1) there should be an original, real system/entity that is being modeled,
• (2) the model should be an abstraction of the original, and
• (3) the model has something to do with the original system.

Secondly, in the definition, the term “reference model” shares a lot of similarities to “conceptual model” and “ontology”, which should probably be distinguishable. Third, the reference model “represents a complete set”, without clarifying what representation or completeness in this context is.

We draw the following consequences:

• (C1) A model can be used as a substitution for the real system: The Principle of Substitution then applies to reference models as well. It states that a useful subset of questions about the original can be answered by querying the model. This seems to fit the definition of a reference model because such a model should be a reference for many (similar) systems, even though there is typically a concretization development step between the definition of the reference model and the finalization of the system.

• (C2) A model is usually defined explicitly in an appropriate modeling language. For example, if we design a reference model for some data standard, we can use class diagrams as a language for its expression.

• (C3) It is often feasible to use a similar or the same language for both reference and concrete models, even though sometimes specific language constructs may only be used in the reference model, respectively, the concrete model. – This may be a restriction for the general notion of the reference model because, in principle, it might be possible to actually use different modeling languages for reference models and their concrete realizations, but we ignore this possibility for now.

• (C4) As a consequence, it is often not easy to recognize a reference model from the concrete realizations that are possible. It may be that the same model may serve as concrete model or as reference model in different contexts.

• (C5) Given a concrete model that is used for realization within a concrete system, it must be clearly decidable whether and how far the concrete model actually conforms to the reference model. A somewhat unclear conformance relation is not necessarily a problem when the reference model serves education, communication, or an otherwise informal purpose. However, when there is tool assistance available or needed, the question of whether a concrete model conforms to its reference becomes more critical. When the reference model is defined from a legal or standard context, the conformance question also becomes relevant for certification.

While the word “reference model” is used quite frequently, to our understanding, many domains and their communities have different and mostly informal understandings of the significance of a reference model and, consequently, different approaches to using reference models in a particular domain.

We posit that a more concise and formal understanding of the concept of a reference model is needed that improves the tool-assisted relationship between a general “reference model” and the set of concrete realizations that conform to that reference model.

Our Definition of Reference Model

Rationale for this Definition of a Reference Model

To some extent, we have given the rationale already in the motivation above. Here are additional arguments.

The main difference between a reference model and a concrete model is not purely a syntactical issue but based on the purpose of the model. Or to be more precise on the multiple purposes in the various activities of a development process. We identify these main purposes for reference models, where not all purposes must be addressed with each model:

• (P1) The introduction of domain concepts (which itself could be regarded as a fuzzy term). We assume that a domain concept has a name and potentially a number of properties that, together, can somehow be represented in our modeling language. These domain concepts are (and this is again somewhat informal) of general interest and, thus, typically also can be regarded as elements of a glossary or an ontology of a certain domain.
• (P2) Domain-specific relations connect these domain concepts. These relations are also described in the reference model.
• (P3) The reference model itself usually also has a name and, thus, allows us to talk about the overall system structure.
• (P4) There is additional information or methodical development advice available that fits the domain concepts and, thus, can be manually reused in a development process.
• (P5) There is a predefined implementation available that fits the domain concepts and, thus, can be automatically reused directly or mapped to the concrete model and its implementation via smart tooling.

(P1) and (P2) are usually the case in data models describing the application data of a domain, such as Person or Account, and their relation, like owns. (P3) is, e.g., the case in the ISO/OSE 7 Layer Communication model or in various Design Patterns. Another example is a traffic light model with two states, green and red, and the according transitions between those states as a reference model probably serves all three purposes (P1-3), if refinable, e.g., to traffic lights with third state yellow.

Using reference models, however, becomes really interesting if (P4) or even (P5) can be leveraged. In adequate tooling, for example, the concept User may be equipped with possibilities for a user to administrate her own setting, acquire roles, receive rights to read/write data, etc.

It all depends on the conformance relation and the tooling that (a) checks conformance and (b) has smart ideas on how to transfer predefined functionality from the reference model to the concrete model, respectively, its implementation.

Definition of the Conformance Relation

Rationale for this Definition of the Conformance Relation

The conformance relation is defined as a binary relation because, in practice, we only need to look at the reference model describing relevant concepts and its implementation, respectively, the concrete system model describing the implementation.

• (CR1) The conformance relation generally relates more abstract models with more concrete models.
• (CR2) Because the reference model and concrete model belong to the same language, we may accept that a reference model can also be a concrete implementation, which means conformance is reflexive. Transitivity is probably not an important property for the conformance relation, but (in the tradition of mathematical properties), we find it a pretty clean approach when conformance can be applied transitively. It, however, is also relatively clear that the conformance relation is not symmetric but relates the more abstract to the more concrete models. But it may be that it is not fully asymmetric either.
• (CR3) As a consequence, the sets of reference models and concrete models of language are not disjoint but may have a large overlap. However, they don’t necessarily have to be identical, i.e., there may be models that only can be used as reference models (e.g., because certain abstract concepts (e.g., abstract classes) in the models do not have concretizations yet).

In a development project that uses a reference model, the conformance relation is potentially a development artifact on its own. It may even be that it is necessary to explicitly write down a mapping to connect abstract domain concepts of the reference model with concrete realization concepts in the concrete model. These kinds of mappings may be of complex forms, and it could well be that there is no generalized form for all purposes. However, we expect at least the following property to hold

• (CR4) The conformance relation between abstract and concrete models can be effectively checked by an algorithm. This must hold in both cases, (CR4.1), where the mapping can be constructed automatically from two given models, and (CR4.2), where the mapping is explicitly given as some kind of parameter of the conformance relation.

Please note that we do not enforce that a reference model describes a structure, such as a data structure or a communication infrastructure. We can perfectly understand that people use Statecharts, BPMN models, Petri Nets, or activity diagrams as reference models. Furthermore, it may well be that a domain-specific language created for a specific purpose also comes along with the construct of reference models within the language.

However, we assume that the construction of reference models and, in particular, the conformance relation needed is highly driven by the semantics of the particular language and, thus, a general, purely syntax-based conformance relation will not be sufficient. As a consequence, conformance relations need to be defined for modeling languages individually.

Reference Models for Data (using the Class Diagram Language)

Let us explain a possible conformance relation for class diagrams as known from the UML [Rum17] using an example. As usual, a class diagram has classes, interfaces, enumerations, attributes, methods, constants, and binary associations and compositions of various forms. Consider the following class diagram in textual form, i.e., a model of MontiCore’s CD4A language, which we regard as a reference model:

// reference model                              as CD4A model
classdiagram AccessRights {
  class User;
  class Role;
  class Permission;
  class Create extends Permission;
  class Update extends Permission;
  association userroles User -> Role [*];
  association Role -> Permission [*];
}

A realization could be:

// concrete model                              as CD4A model
classdiagram Flensburg {
  class Person;
  class Admin;
  class CarOwner;
  association Person -> Admin [0..1];
  association myCars   Person -> CarOwnerRole [*];
  class Permission;
  class CreateCar extends Permission;
  class UpdateCar extends Permission;
  association allowed  [1] CarOwnerRole <-> Permission [1..3];
}

For clarification, we talk about concrete classes C and concrete associations A when referring to the concrete model and reference classes R, reference association S, etc. when referring to the reference model. We regard concrete elements as incarnated reference elements.

It is worthwhile to clarify that the term “incarnation” shares some characteristics of “instantiation”, but there are also substantial differences: (1) Incarnation relates models elements of the same kind, here classes with classes and associations with associations, while instantiation normally relates different kinds, e.g., objects with classes. (2) Incarnation is transitive and reflexive on the model elements (similar to the conformance relation on models itself), while instantiation is not.

A conformation relation between the above models can (informally) be defined as:

// list of incarnations for model elements                     (informal)
  Person                                       ===>  User
  Admin, CarOwner                              ===>  Role
  Permission, CreateCar, UpdateCar             ===>  Permission
  (Person -> Admin), (Person -> CarOwnerRole)  ===>  userroles
  allowed                                      ===>  (Role -> Permission)

Requirements on Conformance Relations

We can argue that the above model Flensburg is a conforming implementation of AccessRights when using the incarnation mapping given here. It does have a number of specialities, which are worthwhile discussing:

• (R1) A concrete class C incarnates (at most) one reference class R (e.g., Person incarnates User). In general, it is also possible that additional new classes exist in the concrete model.
• (R2) The same reference class R may be incarnated by many concrete classes (e.g., Role by Admin, CarOwner).
• (R3) Subclassing relations are preserved, i.e., the concrete class C2 extends C1 exactly if their reference classes R2 extends R1. Class C2need not necessarily be a direct subclass but can be found in the subclassing hierarchy of C1.
• (R4) A concrete association A incarnates (at most) one reference association S (e.g., allowed incarnates (Role -> Permission)). Again it is possible that additional associations exist in the concrete model.
• (R5) In analogy to classes, the same reference association S may be incarnated by many concrete associations. (e.g., userroles has two independent incarnations).
• (R6) Reference associations are preserved. That means given concrete classes C1 and C2, their reference classes R1 and R2, and a reference association S: R1 -> R2, then there must also be a concrete association A: C1 -> C2, such that A incarnates S (in our example all concrete classes have respective concrete associations attached except the Admin, which violates this condition. We could argue that admin doesn’t need explicit permissions because, in our application, she has all permissions anyway, but it does violate the conformance rule).

The above example is only an abstract example. The really interesting part is the transfer of an also existing standard implementation for AccessRights, either in the form of a methodological approach, a framework, or even a generator that adds all the technical details, such as rights management, database storage, etc., for such a reference model. The applicable conformance relation normally depends on the available standard implementation or, respectively, the generator functionality. Or in other words: even if a general conformance relation is available, it may be that concrete usage has to restrict the conformance relation according to specific needs or may relax it with certain respects.

[[NRSS22], [MRR11b] provides semantic differencing as an advanced analysis technique to understand the differences between two class diagrams on the basis of the actual object structures that are allowed in one but not the other model. This kind of semantic difference uses identical class, attribute, and association names to identify comparable classes. Semantic differencing, however, can be extended to reference models and their incarnations to understand the differences between the concrete realization and the original reference model when incorporating the conformance relation into the semantic difference calculation.

Variants of Conformance Relations

Let us give several examples:

• The reference model uses attribute long ident as an internal identification mechanism. It may be allowed to incarnate that attribute by String ident, because strings also have a linear order or by int id because we know that the reduced range is sufficient. In case a framework implementation, however, already relies on data type long, such a change would be illegal.
• The reference model uses a certain cardinality for association S: C1 -> C2 [card]. Cardinality can, in principle, be restricted because we know from the domain that certain restrictions are okay or extended, e.g., from [1] to [*], because that is needed in the domain. It may be that both changes are okay, or neither of them.
• The reference model has a direct subclass relationship between classes R1 and subclass R2. In the concrete model, there may be many incarnations of R2 arranged in a deep hierarchy.
• Furthermore, it may be that adding additional attributes or associations is restricted because there are predefined implementations (or predefined generative techniques) of certain reference classes.

Potentially there are many more details to be handled, such as freely choosable independent names or attribute types, how to deal with enumerations, what are valid or necessary incarnations of interfaces and abstract classes, etc. Ane specifically interesting question is, for example, whether a reference attribute X or a reference association S can be incarnated in the concrete model by a derived attribute or a composed association. In both cases, the realization is hidden in the combination of data structure and algorithmic functionality, such as getters with calculation bodies for derived attributes or an OCL-like logic formula describing how to derive a composed association from basic ones.

To summarize, we would argue that there is no such thing as one single conformance relation even for class diagrams, but there may be a core, as shown in the requirements (R1) to (R6), plus a number of additional or optional relaxations, who are, however, dependent on the actually available tooling behind the reference model and therefore need to be defined together with the reference model.

When looking at other kinds of languages, for example, Statecharts, the very same observations apply. There we have to map states, transitions, nesting of states, preconditions, entry and exit actions, etc. Preconditions may, for example, be relaxed or strengthened, or alternative transitions in nondeterministic Statecharts may be removed. A simulation relation for Statecharts or, more precisely, a refinement calculus like in [Rum96] or [PR94] could be applied here. Especially challenging is the question of whether a reference transition may be realized by a sequence of concrete transitions and what happens if the sequence can be interrupted in the middle.

Representations of the Conformance Relation Mapping

An interesting question is what an explicit representation for a conformance relation looks like if needed. Above, we have given an informal list to describe this mapping. The list contains explicitly given names for classes and associations but also maps unnamed associations by using the (C1 -> C2) notation.

We actually see several options for dealing with such mappings:

• (O1) An explicit mapping language similar to the above shown informal artifact can be used.
• (O2) The mapping can be extracted from the two models by using naming conventions.
• (O3) The concrete model explicitly refers to the reference model by using the domain concepts introduced in the reference model as stereotypes, labels, or flags.
• (O4) The concrete model is actually an extension of the reference model, which means that all model elements (here, classes and associations) defined in the reference model are explicitly included and therefore used in the concrete model.

Conformance Relation when using a Framework

Option (O4) is quite common, especially if the reference model has a framework implementation, where the classes of the reference model are already and explicitly implemented under the very same names. Using different names is then not a possibility. The concrete model then would then have to be:

// concrete model as extension                          as CD4A model
classdiagram Flensburg extends AccessRights {
  class Person extends User;
  class Admin extends Role;
  class CarOwner extends Role;
  class CreateCar extends Permission;
  class UpdateCar extends Permission;
}

This model is relatively compact because associations need not be mentioned explicitly again but are inherited from AccessRights. However, this approach does neither allow for adapting cardinalities of associations nor building multiple incarnations of associations.

A similar approach could be to develop the concrete model independently at first and then apply a generalized merge algorithm, similar to the one provided by MontiCore’s CD4A language, and merge the framework classes, associations, and, thus, infrastructure into the concrete model.

Conformance Relation when using a flexible Generator

If a generator is available (O3), then a feasible and, therefore, also quite common alternative would be to label the concrete model elements like in the following example:

// concrete model using stereotypes                      as CD4A model 
classdiagram <<labels:"AccessRights">> Flensburg { 
  class <<User>> Person;
  class <<Role>> Admin;
  class <<Role>> CarOwner;
  association <<userroles>> Person -> Admin [0..1];
  association <<userroles>> myCars   Person -> CarOwnerRole [*];
  class Permission;
  class <<Create>> CreateCar extends Permission;
  class <<Update>> UpdateCar extends Permission;
  association allowed  [1] CarOwnerRole <-> Permission [1..3];
} 

Here a lot of stereotypes pollute the otherwise clean analysis model. Using a number of conventions, it may be that certain labels have not been defined explicitly but can be reconstructed. This is regularly the case for a concrete association when both its concrete classes have been stereotyped.

Another possibility is to combine the explicit labeling with the implicit use of naming conventions, as described in Option (O2), such as (1) same name (see Permission), or (2) a shared prefix (see UpdateCar) or analogously a shared postfix (like StopState). This, of course, shares the problem of unwanted, coincidental matches but largely reduces the amount of labeling necessary. This is a common approach when applying design patterns, which we also regard as a special form of reference models denoted as class diagrams, e.g., in [GHJV95], where often the roles of the individually participating classes are used as parts of the actual class names.

To prevent potential pollution with stereotypes from various technological spaces, we have in [GLRR15] explored the possibility of using an extra tagging language that allows labeling model elements without invasively changing the original model stored in extra artifacts. Tagging models can be applied in various domains [DJK+19a], [MRRW16].

Reference Model as Ontology

Let us take a slightly different look at reference models: A reference model defines a number of domain concepts, usually with explicit names, which actually constitute an ontology (e.g., including a set of terms and their relations) within the modeling language. This viewpoint enables an interesting connection between modeling languages and ontologies, where the modeling language acts as a carrier for the ontology. The language provides the modeling elements, and the ontology provides a library of terms and relations. This is completely compatible with the way how natural languages are defined through the grammar for the syntactic structure and the dictionary for the wording.

Such a connection is obvious for class diagrams, and, thus, we give
different examples:

• Encoding a reference model for the behavior of smartphone apps using a Statechart and realizing specific apps using a refined number of states in a concrete Statechart,
• providing a reference model for production and billing processes using BPMN within a car manufacturer with country-specific incarnations, and even
• building a (physical or simulated digital) reference model for a factory of a manufacturer with the possibility to incarnate this reference model in various concrete factories around the world.

Wikipedia mentions several uses of reference models, such as: (1) Creating standards, (2) education, (3) improving communication between stakeholders, and (4) facilitating comparison. A tool-based approach, however, with a clear relationship between reference and concrete realization model is not (yet) included in the Wikipedia definition but should be added when we are able to provide appropriate tool-assisted cases for reference models.

We are aware that there is already much scientific work on this topic, but using reference models is by far not where it should be.

This essay is partially adapted from SoSyM editorial [GR21d], which is published under the Creative Commons license.

Further links

• Essays, Comments, Definitions around Modeling
• Publications
• Topic sorted list of most interesting publications
• Books
• Website of the SE