# ConceptBase

Developer(s) All 4 MOF levels for Entity-Relationship Diagrams displayed in the ConceptBase Graph Editor Team at University of Skövde (HIS) and University of Aachen (RWTH) {{#property:P1324}} FreeBSD-style license [1] conceptbase.sourceforge.net

ConceptBase is a deductive and object-oriented database management system developed at University of Aachen and Tilburg University. It is mainly used for conceptual modeling and metamodeling in the domain of software engineering and related domains.

## General

ConceptBase.cc is a multi-user deductive database system with an object-centered data model. Its ability to represent information at any abstraction level (data, class, metaclass, meta-metaclass, etc.) makes it a powerful tool for metamodeling and engineering of customized modeling languages. The system is accompanied by a highly configurable graphical user interface that builds upon the logic-based features of the ConceptBase.cc server.

Unlimited metaclass hierarchies. ConceptBase.cc can represent information at the data level (example data, traces of process executions etc.), the class level (schemas, process definitions etc.), the metaclass level (constructs of modeling languages), the meta-metaclass level (constructs for defining modeling languages), and so forth.

Uniform object representation. All objects are represented in a uniform quadruple data structure called P-facts pioneered by the developers of the Telos language. Objects, their attributes, specializations, and instantiations are all represented as P-facts. By this, for example, attributes of objects can have attributes and are instances of other attributes. Even specialization between attributes is fully supported.

Logical expressions. Rules, constraints, and queries are expressed in first-order logic formulas. Internally, the system transforms them into Horn clauses interpreted by a Datalog-based evaluation machine. Logical expressions in ConceptBase.cc can range over any object regardless of its type (node vs. link) and its abstraction level. Datalog is known for being the most robust computational system for evaluating logical expressions.

Active rules. Active rules update the database or call external routines as a reaction to events. The execution follows the Event-Condition-Action scheme (ECA). Updates to the database are formulated via Tell/Untell/Retell commands. External routines (e.g. for invoking a script to send an email) can be incrementally added to the database using a simple Prolog-based programming interface.

Functional expressions. ConceptBase.cc supports functional and arithmetic expressions to define computation within models. Functions can be recursively defined much like in Functional Programming. For example, the length of the shortest path between two nodes is defined as the minimum of the lengths of the shortest path between the successors of the start node and the end node. Functional expressions are particularily useful for defining complex metrics on models. Aggregation functions such as SUM and AVG are predefined.

ConceptBase.cc is developed by the ConceptBase Team at University of Skövde (HIS) and University of Aachen (RWTH)[2]. ConceptBase.cc is available for Linux, Windows, and Mac OS X. There is also a pre-configured virtual appliance that contains the executable system plus its sources plus the tools to compile them. The system is distributed under a FreeBSD-style license. If you need further assistance, you are welcome to contact us. A FAQ section is provided via the CB-Forum.

## 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
All levels

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.

M1
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

Cite error: Invalid <references> tag; parameter "group" is allowed only.
Use <references />, or <references group="..." />