ConceptBase was originally conceived in the 1980-ties as a repository system maintaining heterogeneous models created during the development of data-intensive applications, i.e. software systems that rely on database systems as one of their components. The development of ConceptBase was initiated by the EU DAIDA project, which used the Telos conceptual modeling language for the requirements and specifications, Taxis as a design language (featuring among others object-orientation and a concept for transactions), B-tool abstract datatypes, and the DBPL (Modula-2-like programming language with constructs for transactions and relations).

The ConceptBase system had to store abstract representations of these models and programming languages and thus had to have certain capabilities to deal with the challenges:

1. A graph-based data model that allows to represent the artifacts of the different supported languages and their inter-relationships. We chose the Telos language for this purpose because its data model is even more generic than graphs by having a single data structure for both nodes and links.
2. A Datalog-based rule and constraint language to detect flaws in models and to trace model elements across modeling language boundaries.
3. A query language to extract views on models.
4. A graphical user interface to visualize views.
5. An active rule language to represent Turing-complete calculations

Initially, ConceptBase was mostly used for specifying domain-specific modeling languages for requirements and software engineering. The specification of the language in ConceptBase was at the same time also an implementation of the modeling language by instantiating the constructs defined in a so-called meta model. Examples include the i* requirements language, whose first version was specified with ConceptBase. Later, the focus shifted more to understand the dependencies between partial models, each covering a certain perspective of the artifact to be modeled.

More recently, we exploited the fact that rules and constraints can span over multiple instantiation levels to implement a flavor of a multi-level modeling language called DeepTelos. It is defined by just five deductive rules and one constraint to allow specifying highly re-usable properties of objects.

(Meta)Modeling Core concepts and Examples

The featured image in the post (above) depicts some of the core concepts available in ConceptBase to create (and store) your languages. Consider the following simple example to define the construct EntityType:

EntityType with
  attribute
    attr: Domain
    superType: EntityType
end

In Telos, the predefined category ‘attribute‘ covers both classical attributes that have values and associations between objects and/or classes. The new construct can then directly be instantiated like in the following example:

Staff in EntityType with
  attr
    hired: Date;
    salary: Integer;
    staffno: Integer
  superType
   s1: Person
end

The semantics of the ‘superType‘ relation can be specified by 2-3 rules and a couple of constraints. While other metamodeling environment just support 2 effective instantiation levels, mostly M2 and M1 in the UML terminology, ConceptBase supports any number of instantiation levels. For example, the object ‘Staff’ can be instantiated for example by an object ‘bill’:

bill in Staff with
  hired when: ”2022-10-14”
  salary earns: 25000
  staffno no: 123321
end

A particular role in ConceptBase plays the pre-defined object ‘Proposition‘. It has all explicit objects, instantiations, specializations, and attributes/associations as instance. Initially, ConceptBase supports just these constructs. But by adding new attributes to ‘Proposition’, one can extend the capabilities of ConceptBase. This is precisely how we implemented DeepTelos. DeepTelos fits on half a page and is a major extension for ConceptBase.

The server part of ConceptBase supports multiple concurrent users and realizes the durability of transactions (=changes) to the content of the ConceptBase database. The proprietary database system for ConceptBase uses a quadruple data structure to store explicit facts. These quadruples are representing the instances of ‘Proposition’, which is an instance of itself.

The figure below shows how objects from 3 instantiation levels are all managed in the same ConceptBase database. The top level defines BPMN constructs. Below is a BPMN model representing a software development process. The lowest level contains the trace of an execution of the process including dependency links. The diagram is directly exported from ConceptBase.

The textual definitions for two of the objects are given below. Note that the green links stand for instantiations, e.g. ‘reqanalysis1’ is an instance of ‘RequirementsAnalysis’.

RequirementsAnalysis in BPMN_Activity with
  next n1 : andgw1
  produces
    artifact1 : RequirementsSpecification
end

reqanalysis1 in RequirementsAnalysis with
   artifact1 redoc : reqdoc1
end

CodingInCobol in BPMN_Activity isA Coding with
   constraint
    useCobol : $ forall cic/CodingInCobol (cic useslanguage Cobol) $
  produces
    artifact1 : CobolCode
end

Specializations in the figure are blue links, see object ‘CodinginCobol’. Constraints can be defined in a first-order logic syntax at any instantiation level. In the above example, the fillers to the ‘useslanguage’ property are constrained. Constraints as well as rules are compiled to Datalog by ConceptBase. Each attribute / link comes with two labels, one for the class level definition of the attribute / link, and one for the object level label. This allows for multiple instantiation of certain attributes / links. For example, a task type like ‘RequirementsAnalysis’ may have more than one produced artifact. An interesting aspect in the figure is the ‘element1’ link between ‘designdoc1’ and ‘Customer’. It shows that individual documents can contain abstract concepts, such has shown in the textual definition of ‘designdoc1’. The design document actually representing a partial database schema. Likewise, the document ‘reqdoc1’ is a container for natural language requirements.

designdoc1 in DesignDocument with
  content
    element1 : Customer;
    element2 : Product;
    element3 : Order
end

reqdoc1 in RequirementsSpecification with
  content
    r1 : "The ACME system shall allow to enter/edit/delete customer data at any time.";
    r2 : "The ACME system shall be implemented as a web service.";
    r3 : "Response times must be less than 2 seconds for data entry and simple retrieval."
end

Customer in EntityType with
   attr
    custid: String;
    loyaltylevel: Integer
   dependsOn
    o1 : reqdoc1!r1
end

The last frame on ‘Customer’ shows that elements of a model can depend on other elements, here the first statement in the requirement document ‘reqdoc1’. Such dependencies are transitive and can be traced both in forward and backward direction in ConceptBase, e.g. finding the requirements on which a particular code line depends upon.

Comparing ConceptBase with other systems

A closely related system is ADOxx, which stores models in a relational database. ADOxx has extensive support for creating the graphical notation. It features a scripting language to detect certain modeling errors. ConceptBase has only minimal support to adapt the graphical visualization of a model to match for example the UML notations. On the other hand, ADOxx currently only supports two abstraction levels (meta model and model). It strictly separates the meta model from the model, while ConceptBase stores all definitions in a single interconnected proprietary database. ConceptBase has a declarative rule and constraint language to analyze models based on Datalog. The scripting language of ADOxx can in principle achieve the same but it is a Turing-complete imperative programming language. Hence, ADOxx scripts could be stuck in infinite loops while the evaluation of ConceptBase rules and constraints will always terminate. There has been a master thesis at the university of Vienna to investigate the use of ConceptBase as a constraint checker for ADOxx.

Another related system is MetaEdit+, arguably the market leader for developing domain specific modeling languages. The particular strength of MetaEdit+ is code generation. ConceptBase has only very limited abilities to generate code. Like ADOxx, MetaEdit+ supports two abstraction levels (meta model and model), while ConceptBase supports any number of abstraction levels.

In 2005, the WoMM workshop presented a modeling challenge for meta modeling tools. Each of the candidate tool had to present a solution to a challenge. Participating tools were ADONIS (BOC, commercial version for ADOxx), ConceptBase, Cubetto (Semture), MetaEdit+ (MetaCase) and Metis (Troux Technologies AS). Not all tools provided a solution to the WoMM challenge. It turned out that ConceptBase was the only tool that could solve a task requiring to calculate the transitive closure of a relation by a simple declarative formula spanning over 2 lines. The other tools had to program the solution in an imperative language. ConceptBase was also the only tool offering an unlimited number of abstraction levels.

Related to meta modeling, the FMMLx system by the University of Duisburg-Essen offers its function on top of the XModeler tool, which itself offers a constraint language extending OCL for multi-level modeling.  FMMLx can specify operations in its OCL dialect and also execute them. It supports 4 abstraction levels. The difference to ConceptBase lies mostly in the proximity of FMMLx to UML and to object-oriented programming. It also forbids links between objects at different abstraction levels. Further, each object must have exactly one class. ConceptBase does supports cross-level links and specifically allows object to have multiple classes.

Summary

ConceptBase is a database system for storing interdependent models at any abstraction level. It is utilizing the object-oriented principles of instantiation, specialization, and attribution/association to represent models. Its logic-based rule and constraint language allows circumscribing the intended semantics of classes, meta classes, meta meta classes as so forth. The flexibility of the logic-based rule and constraint language in addition to the uniform representation of all facts as quadruples allow the use of ConceptBase to define domain-specific languages as meta models and then seamlessly use them via instantiation in a true multi-level modeling style.

Future plans

We currently work on an enterprise modeling language within ConceptBase to cover the assets of critical infrastructure companies. This language was initially developed in the EU project ELVIRA and is now being extended and marketed by Norgald AB. ConceptBase is free software and available via ConceptBase.cc. The website contains links to many examples as well as further documentation.

Acknowledgements

Contributions to the source code of ConceptBase were made by: Masoud Asady, Lutz Bauer, Markus Baumeister, Ulrich Bonn, Stefan Eherer, Rainer Gallersdörfer, Michael Gebhardt, Dagmar Genenger, Michael Gocek, Rainer Hermanns, Manfred Jeusfeld (lead developer), David Kensche, André Klemann, Eva Krüger, Rainer Langohr, Farshad Lashgari, Tobias Latzke, Xiang Li, Yong Li, Thomas List, Andreas Miethsam, Hans Nissen, Martin Pöschmann, Christoph Quix, Christoph Radig, Achim Schlosser, Tobias Schöneberg, René Soiron, Martin Staudt, Kai von Thadden, Hua Wang, Claudia Welter, Thomas Wenig, and others. ConceptBase is free software distributed under a FreeBSD-style license.

References

Manfred Jeusfeld, Matthias Jarke, and John Mylopoulos: Metamodeling for Method Engineering. Cambridge, MA, 2009. The MIT Press. (2021 open-access version available here).