{"id":8335,"date":"2023-01-17T06:58:54","date_gmt":"2023-01-17T06:58:54","guid":{"rendered":"https:\/\/modeling-languages.com\/?p=8335"},"modified":"2023-01-17T06:58:54","modified_gmt":"2023-01-17T06:58:54","slug":"conceptbase-database-system-metamodeling","status":"publish","type":"post","link":"https:\/\/modeling-languages.com\/conceptbase-database-system-metamodeling\/","title":{"rendered":"ConceptBase – a Database System for Metamodeling"},"content":{"rendered":"

ConceptBase<\/strong> 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<\/strong> conceptual modeling language for the requirements and specifications, Taxis<\/strong> 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).<\/p>\n

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:<\/p>\n

    \n
  1. A graph-based data model<\/strong> 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.<\/li>\n
  2. A Datalog-based rule and constraint language<\/strong> to detect flaws in models and to trace model elements across modeling language boundaries.<\/li>\n
  3. A query language<\/strong> to extract views on models.<\/li>\n
  4. A graphical user interface<\/strong> to visualize views.<\/li>\n
  5. An active rule language<\/strong> to represent Turing-complete calculations<\/li>\n<\/ol>\n

    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.<\/p>\n

    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<\/strong>. It is defined by just five deductive rules and one constraint<\/a> to allow specifying highly re-usable properties of objects.<\/p>\n

    (Meta)Modeling Core concepts and Examples<\/h2>\n

    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:<\/p>\n

    EntityType with\r\n  attribute\r\n    attr: Domain\r\n    superType: EntityType\r\nend\r\n<\/pre>\n
    In Telos, the predefined category ‘attribute<\/em>‘ 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:<\/p>\n
    Staff in EntityType with\r\n  attr\r\n    hired: Date;\r\n    salary: Integer;\r\n    staffno: Integer\r\n  superType\r\n   s1: Person\r\nend\r\n<\/pre>\n
    The semantics of the ‘superType<\/em>‘ 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<\/strong>. For example, the object ‘Staff’ can be instantiated for example by an object ‘bill’:<\/p>\n
    bill in Staff with\r\n  hired when: \u201d2022-10-14\u201d\r\n  salary earns: 25000\r\n  staffno no: 123321\r\nend\r\n<\/pre>\n
    A particular role in ConceptBase plays the pre-defined object ‘Proposition<\/em>‘. 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<\/strong> and is a major extension for ConceptBase.<\/p>\n
    The server part of ConceptBase<\/strong> 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.<\/p>\n
    The figure below shows how objects from 3 instantiation levels are all managed in the same ConceptBase database<\/a>. 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.<\/p>\n
    \"\"<\/p>\n
    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’.<\/p>\n
    RequirementsAnalysis in BPMN_Activity with\r\n  next n1 : andgw1\r\n  produces\r\n    artifact1 : RequirementsSpecification\r\nend\r\n\r\nreqanalysis1 in RequirementsAnalysis with\r\n   artifact1 redoc : reqdoc1\r\nend\r\n\r\nCodingInCobol in BPMN_Activity isA Coding with\r\n   constraint\r\n    useCobol : $ forall cic\/CodingInCobol (cic useslanguage Cobol) $\r\n  produces\r\n    artifact1 : CobolCode\r\nend\r\n<\/pre>\n
    Specializations in the figure are blue links, see object ‘CodinginCobol’. Constraints can be defined in a first-order logic syntax at any instantiation level.<\/strong> In the above example, the fillers to the ‘useslanguage’ property are constrained. Constraints as well as rules are compiled to Datalog by ConceptBase<\/strong>. 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.<\/p>\n
    designdoc1 in DesignDocument with\r\n  content\r\n    element1 : Customer;\r\n    element2 : Product;\r\n    element3 : Order\r\nend\r\n\r\nreqdoc1 in RequirementsSpecification with\r\n  content\r\n    r1 : \"The ACME system shall allow to enter\/edit\/delete customer data at any time.\";\r\n    r2 : \"The ACME system shall be implemented as a web service.\";\r\n    r3 : \"Response times must be less than 2 seconds for data entry and simple retrieval.\"\r\nend\r\n\r\nCustomer in EntityType with\r\n   attr\r\n    custid: String;\r\n    loyaltylevel: Integer\r\n   dependsOn\r\n    o1 : reqdoc1!r1\r\nend\r\n<\/pre>\n
    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.<\/p>\n
    Comparing ConceptBase with other systems<\/h2>\n
    A closely related system is ADOxx<\/a>, 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.<\/p>\n
    Another related system is MetaEdit+<\/a>, 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.<\/p>\n
    In 2005, the WoMM workshop<\/a> 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.<\/p>\n
    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.\u00a0 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.<\/p>\n
    Summary<\/h2>\n
    ConceptBase is a database system for storing interdependent models at any abstraction level<\/strong>. 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<\/strong> 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<\/strong> and then seamlessly use them via instantiation in a true multi-level modeling style.<\/span><\/p>\n
    Future plans<\/h2>\n
    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<\/a> and is now being extended and marketed by Norgald AB. ConceptBase is free software and available via ConceptBase.cc<\/a>. The website contains links to many examples as well as further documentation.<\/p>\n
    Acknowledgements<\/h2>\n
    Contributions to the source code of ConceptBase were made by: Masoud Asady, Lutz Bauer, Markus Baumeister, Ulrich Bonn, Stefan Eherer, Rainer Gallersd\u00f6rfer, Michael Gebhardt, Dagmar Genenger, Michael Gocek, Rainer Hermanns, Manfred Jeusfeld (lead developer), David Kensche, Andr\u00e9 Klemann, Eva Kr\u00fcger, Rainer Langohr, Farshad Lashgari, Tobias Latzke, Xiang Li, Yong Li, Thomas List, Andreas Miethsam, Hans Nissen, Martin P\u00f6schmann, Christoph Quix, Christoph Radig, Achim Schlosser, Tobias Sch\u00f6neberg, Ren\u00e9 Soiron, Martin Staudt, Kai von Thadden, Hua Wang, Claudia Welter, Thomas Wenig, and others. ConceptBase is free software distributed under a FreeBSD-style license.<\/p>\n
    References<\/h2>\n
    Manfred Jeusfeld, Matthias Jarke, and John Mylopoulos: Metamodeling for Method Engineering. Cambridge, MA, 2009. The MIT Press. (2021 open-access version available here<\/a>).<\/p>\n<\/span>","protected":false},"excerpt":{"rendered":"
    Discover ConceptBase, a database system for storing interdependent models at any abstraction level with a logic-based language to express as well their intended semantics.<\/p>\n","protected":false},"author":119,"featured_media":8337,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[20,24],"tags":[876,571,877],"hashtags":[],"_links":{"self":[{"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/posts\/8335"}],"collection":[{"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/users\/119"}],"replies":[{"embeddable":true,"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/comments?post=8335"}],"version-history":[{"count":0,"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/posts\/8335\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/media\/8337"}],"wp:attachment":[{"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/media?parent=8335"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/categories?post=8335"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/tags?post=8335"},{"taxonomy":"hashtags","embeddable":true,"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/hashtags?post=8335"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}