There exist many methods to describe an application domain. Each approach is based on its own categorization of phenomena in the real world. Such a categorization system is referred to as the metamodel of that approach. However, the various modeling approaches have many things in common. The meta-metamodel describes the concepts and their relations that metamodel approaches have in common. In this section, we present the different models considered in our approach. Subsequently, we specify how these models are build by the modeling method NMDC
4.1.1
The meta-metamodel
A meta-metamodel is used to define the syntax and semantics of metamodels of concrete modeling techniques. A meta-metamodel usually is described in term of a generic and reflexive language, i.e., a language that can define itself. Reflexivity helps to avoid multiple abstraction levels and makes a language easily extensible to define new concepts from different areas. The MetaObject Facility Specification1 (Meta-Object Facility (MOF))is the
foundation responsible for an industry-standard environment for modeling techniques, leading to a high level of reusability of models. MOF has been adopted and standardized by the Object Management Group (Object Management Group (OMG)) as a universal meta-language that can describe languages like UML and other relational models. MOF
1http://www.omg.org/mof/
is an object oriented meta-modeling language based on notions of class, association, inheritance, data types, exception, constants, and constraints (See Figure 4.1) Azaiez (2008).
Figure 4.1: Simplified MOF formalism
However MOF may have limitations when we want to represent or design agents because, contrary to software objects, they have a high level of abstraction. This limit will encourage the use of formal language for expressing meta-models. Formal languages permit the expression and verification of properties, because they are defined both by a formal syntax and a formal semantics. The syntax of a formal language is often expressed in two steps: (1) The structure of the constructs is usually described in Backus-Naur Form (Backus-Naur Form (BNF)). (2) The second step describes the restrictions on those constructs by what in modeling languages usually is referred to as constraints. Programming languages most often use operational semantics, denotational semantics or axiomatic semantics to reduce derivation trees that can be generated during the interpretation of an expression language.
In this work we express our meta-model using ORM (Figure 4.2) to better represent the conceptual schema of the application domain enabling domain experts and to better validate the information structures and business rules Cuyler (2005). Object-Role Model- ing (ORM) is a method for conceptualizing and explicitly representing data, processes and rules in an application domain. The philosophy behind ORM is that it tries to describe this domain by reflecting the communication between its members as a semi-natural language. An ORM scheme basically is a grammar describing that communication. This grammar is also referred to as information grammar. For an overview on expressivity in conceptual data modeling, based on Hofstede et al. (1993), (see Figure 4.3). For a full explanation of notations (See Halpin (2012))
In Figure 4.2, an object type is either an entity type (non-lexical) or a value type (lexical), and is displayed as a named ellipse (dotted ellipse if value type). If an entity type has a simple reference scheme, this may be abbreviated by a reference mode in
4.1. THE USED MODELS 41
Figure 4.2: Main types in ORM metamodel Cuyler (2005)
parentheses. A role is a part in a relationship type (association), and is depicted as a box. The arity of an association is its number of roles. An association may be unary, binary, or longer. An association is composed of a logical predicate (open proposition with placeholders for objects) together with the object types that play the roles. Predicates are displayed as sequences of role boxes, and have one or more readings depending on the order in which the roles are traversed. NestedEntityType is a subtype of both EntityType and FactType equivalent to association in the UML metamodel. SubtypeConnection is inherited from Generalization in the Unified Modelling Language (UML) metamodel. Derived predicates show how SubtypeConnection can also be modeled in terms of co- referencing (alternative to nesting). Role is inherited from UML’s StructuralFeature, and derived predicates relate it to the usual ORM view.
Associations in Figure 4.2 may have multiple readings. Forward and reverse readings are shown for some binaries we have already met. In general, an n-ary predicate has n! ways of traversing its roles, and for each of these ways one or more readings may be given. For any given object type, names of its far roles must be unique in order to support unambiguous role path navigation using attribute-style notation.
Figure 4.3: Overview of ORM Concepts
4.1.2
The metamodel
The meta-model represents a description of the modeling language we will use. It will define the syntax rules that will allow to write our model while giving the meaning of each concept present in the language. We’ll distinguished in our case two meta-model: the source meta-model and the target meta-model.
1. The source meta-model: it represents the meta-model of domain which will aim to describe the concepts used in the domain application. It defines the domain entities and the interrelations between them to proposed the architecture of domain area. In our case this is represented by the AiC framework, which will enable us to describe the concepts of domain such as actors, options, motivations and interrelations between them