DeepTelos Φ Download Φ License Φ Forum Φ Team Φ Home

Metamodeling with ConceptBase

ConceptBase supports any OMG UML Infrastructure abstraction level (M0=data level, M1=model or schema level, M2=notation level, M3=notation definition level, and so forth) and uses a single data structure called P-facts to represent all factual information regardless of the abstraction level. However, ConceptBase does not share OMG's postulate that only instantiation links are allowed between abstraction levels. You design modeling languages (M2-level) based on your own M3-level, use the modeling languages to create example models (M1-level), and even represent example data/traces at the M0-level. In the example on the right, a screendump is shown with the definition of an extended entity-relationship diagramming language. The top in this example is the M3-level:

Concept with
 attribute
    singleDef: Concept;
    necessaryDef: Concept
end

The object Concept is defining two attribute categories singleDef and necessaryDef that are used to capture the cardinality of some modeling constructs at the M2-level. The M2-level defines the symbols of the entity-relationship diagramming language:

Concept EntityType with
  attribute
    attr: Domain;
    key: Domain;
    superType: EntityType
end

Concept RelationshipType with
  attribute
    role: EntityType;
    "1..n": EntityType;
    "2..n": EntityType;
    "1..1": EntityType;
    "0..1": EntityType;
    "0..2": EntityType;
    "0..n": EntityType;
    "n..m": EntityType
end

The Datalog-based constraint language of ConceptBase allows to capture the semantics of (some of) the notational symbols of the M2-level. In this case, the cardinality symbol "0..1" is defined to allow at most one filler for a relationship role link A.

Class RelationshipType with
  constraint
    ic_max1: $ forall A/RelationshipType!"0..1" a1,a2,r/Proposition
                   (a1 in A) and From(a1,r) and
                   (a2 in A) and From(a2,r)
                ==> (a1 = a2) $
end

The M1-level (see below) is used to represent some example entity-relationship diagram. The definitions below use the same frame-like textual representation. This is the format accepted by the ConceptBase server at its programming interface. Dedicated client programs can generate the frames from user input to a graphical interface optimized for the respective notation.

EntityType Staff with
  attr
    name: String;
    hired: Date;
    salary: Integer
  attr,key
   staffno: Integer
end

RelationshipType employs with
  role, "0..n"
    employee: Staff
  role, "1..1"
    employer: University
end
...

Finally, the M0-level is used to validate the example diagram with some data. Note that some definitions at the M2-level can only be checked at the data level. For example, vardinalities of relationship types refer to properties of actual data, not to properties of a diagram!

employs emp3 with
  employee
    who: kurt
  employer
    where: RWTH
end

The solid green lines are explicit instantiations. The broken green lines are denote derived instantiations. In this, case petra is a derived instance of Staff, because petra is a instance of Faculty and Faculty has the super type Staff, which is derived by a deductive rules of IsaType:

IsaType with
  rule
    makeBinaryRel: $ forall I/IsaType E1,E2/EntityType
                        (I sub E1) and (I super E2)  ==> (E1 superType E2) $;
    membershipRule: $ forall e/VAR E,D/EntityType
                       (e in D) and (D superType E) ==> (e in E) $
end

While other systems can also represent all OMG abstraction level for metamodeling, ConceptBase allows you to specify rules, constraints, and queries at any abstraction level and to link objects regardless of their abstraction level. The query language of ConceptBase makes no difference at all about the abstraction level of the objects it refers to. The assignment of objects to abstraction levels is relative: an object can be defined as an instance of another object called its class (see green links in the screendump), that class can be instance of a third object called the metaclass of the original object. Hence, PC has the metaclass EntityType. At the same time, Person has the metaclass Concept. The data model of ConceptBase also allows to link objects from different abstraction level:

Concept with
  ...
  attribute
    created: "1-Jan-2004: 12:03"   {* from M3 to M0 *}
end
Person in EntityType with
  attr
    name: String
end
PC in Person with
  name
    pcname: "Peter Chen"
  attribute
    proposed: EntityType {* from M0 to M2 *}
end

The two links that cross abstraction levels are labelled 'created' and 'proposed', respectively. They are instantiated from the link 'attribute' defined as the so-called omega-class 'Proposition', which has all objects of a database as instances. The class 'proposition' thus allows us to define links between any pair of objects. This feature distinguishes Telos from other metamodeling frameworks that demand a strict stratification of objects and classes into a finite number of abstraction levels. More information on managing multiple abstraction levels in ConceptBase is available in the user manual the section on Multi-level modeling with ConceptBase.

Models like ERD models can be excerpted from ConceptBase in various output formats. You can for example translate ERD models to graph representations for the Graphviz package and have it layed out automatically. See here for more details. The complete Telos source files are available from the CB-Forum.

http://conceptbase.cc -- Contact: M. Jeusfeld, University of Skövde, Box 408, S-54128 Skövde, Sweden
2018-07-05/M.Jeusfeld