Modelling Language Implementation

This page provides an overview of how a modelling language can be implemented with the ADOxx platform. It also provides some relevant information to keep in mind towards the end of the page. Details on the different parts relevant for implementing a modelling language are addressed on other sub-pages.

Modelling Languages and ADOxx

A modelling language specifies the types of concepts and rules to create models. For the purpose of this documentation a modelling language is considered to be described by three main parts:

1. Syntax: the specification of modelling constructs.
2. Notation: the (graphical) representation of modelling constructs.
3. Semantic: the definition of the meaning for modelling constructs.

Modelling methods and modelling languages

For details about the theoretical background, please see the Generic Modelling Method Framework ("Metamodelling Concepts") from:

• Karagiannis, Dimitris & Kühn, Harald. (2002). Metamodelling Platforms. In Bauknecht, Kurt, Min Tjoa, A & Quirchmayer, Gerald (Eds.): Proceedings of the Third International Conference EC-Web 2002 – Dexa 2002, Aix-en-Provence, France, September 2002, LNCS 2455, Springer, Berlin/Heidelberg, p. 182 ff. DOI:10.1007/3-540-45705-4_19. Access Online
• Kühn, Harald. (2004). Methodenintegration im Business Engineering. PhD Thesis, University of Vienna. Access Online

A modelling language is implemented with ADOxx through a meta-modelling approach: the language is realized in ADOxx by specifying a meta-model. In this sense the parts introduced above can be mapped to the following parts of the ADOxx platform:

1. Syntax: through the definition of modelling constructs as models, classes and attributes arranged in a hierarchy.
2. Notation: through the specification of a modelling construct's representation using GraphRep or AttrRep.
3. (formal) Semantic: through special configuration attributes of a modelling construct and the use of AdoScript.

Meta-model Concepts in ADOxx

The meta-model is specified through the configuration of an Application Library in ADOxx following a meta-modelling approach. To allow for this flexibility of the ADOxx platform itself utilizes an internal meta²-model (meta-meta-model) according to which the meta-model is then created. The following image describes a part of the meta²-model:

• Class: These specify the main types of modelling constructs that can be instantiated. ADOxx provides different types of classes which have an influence on their behavior:
  • (modelling) Class: For objects that are used as "normal" nodes in a model. These are typically just called Class in the ADOxx user interface, but throughout this documentation they will be called (modelling) class to better differentiate them from the the general concept of a class.
  • Relation class: For connectors that are used to relate (connect) other objects in a model.
  • Record class: For the structure of rows that are part of a record / table attribute.
  • Attribute Profile class: For objects that exist outside of a model.
• Model type: Specifies what types of models can be created, which attributes they have and what classes can be used in them.
• Attribute: These specify properties that the various concepts can have a value for.
  • (instance) Attribute: These attributes are used on instance level, meaning that the value belongs to a specific instance, object, connector, row etc.
  • Class attribute: These attributes are used on type level, meaning that the value belongs to a specific class. The same value is also applied to each instance of that class. Class attributes are typically used as special configuration attributes to configure some aspects of a class in the ADOxx platform.
  • Attribute facet: Further describes an attribute, like their name, type or restrictions for their value. The attribute facets available are handled internally by the ADOxx platform.

ADOxx utilizes special attributes that it recognizes to deal with different aspects of a meta-model and its models.

Meta-modelling in ADOxx

The common approach of realizing a modelling language in ADOxx through a meta-model is through the use of the Library management component of the Development Toolkit. The modelling constructs belong to a specific Application Library and are created and configured using various dialogs available through the Development Toolkit.

The following pages cover the details of configuring the library and present the various configuration options available. For an example showing only some of the simple options available please refer to the Hello World example.

Alternative: writing ALL code

An alternative approach for configuring a library is through writing ALL code and then transforming it into ABL (ADOxx Binary Language) and importing it. The details of this approach are not covered in this documentation.

Transient Meta-model State in ADOxx

The ADOxx platform uses a database to store all the relevant information about the Application Library, the meta-model and its models. However, both the Development Toolkit and Modelling Toolkit store a transient state of the meta-model in memory. This can lead to a difference between the state of the meta-model stored in the database and the transient state in the toolkits.

Considering this is relevant when changing the meta-model in the Development Toolkit while it is also used in the Modelling Toolkit, as they can both work on different states of the meta-model.

Hint

When changing something through the Development Toolkit: first save the library to store any changes to the database and then reload / restart the Modelling Toolkit.

At any time each toolkit has at most one Application Library loaded, which is the active library. The state between a toolkit and the database is updated at the following points:

• In the Modelling Toolkit:
  • Starting the Modelling Toolkit loads from the database.
  • Reloading the Modelling Toolkit loads from the database.
  • Saving a library stores to the database.
• In the Development Toolkit:
  • Changing the active Application library loads from the database. This happens for example when:
    • Opening the class-hierarchy of a library that is not the current active library.
    • Accessing the library attribute of a library that is not the current active library.
  • Saving a library stores to the database.