The Commonalities Language

The Commonalities Language

The Commonalities language is a domain-specific language (DSL) for defining consistency relations between two or more metamodels. It is based on the idea that a consistency relation between two metamodels exist because they share common concepts they describe in different ways. Thus, in contrast to the Reactions language, which describes consistency by means of a transformation between two metamodels, the Commonalities language describes consistency by defining the common concepts and how they manifest in the different metamodels. These common concepts are called commonalities. For example, for describing consistency between UML and Java classes, the commonality of a class with its properties is defined along with how these properties manifest in UML and Java. From such a specification, transformations (in the Reactions language) that preserve consistency according to these relations are generated. Multiple commonalities shared by two or more metamodels are encapsulated into a concept, such as UML and Java sharing an ObjectOrientedDesign concept.

Language Elements

Concepts

A concept defines what is conceptually shared between two or more metamodels. This can, for example, be the idea of object-oriented design for UML and Java, or the idea of component-based engineering for component models and Java beans. It consists of one or more commonalities. Technically, a concept can be considered a metamodel with the specific role of not having instances that are used by a developer but only by means of consistency preservation.

Commonalities

A commonality defines a specific common concept of two or more metamodels. This can, for example, be a class or a method within the object-oriented design concept. A commonality consists of participations, which are the metaclasses of metamodels that participate in this commonality, and properties, which define the elements shared between the participations. Technically, a commonality can be considered a metaclass.

Participations

A participation defines a set of metaclasses with properties on them that have to be fulfilled by instances of these metaclasses in a model to be considered an instance of the commonality. In case model elements fulfill the conditions of a participations, it means that there is a realization of the common concept defined by the commonality within the model, i.e., a commonality has to be instantiated and all other participations must exist or must be created as well. Participations can consist of commonalities again, such that there may be a hierarchy of commonalities and concepts. For example, a component-based systems concept may have a component model as well as the object-oriented design concept as participations. Thus, whenever a participation is matched in a model, an instance of the commonality is created and instances of the other participations in other models are created. Technically, this is achieved by instantiation of the commonality metaclass and execution of generated transformations, more precisely reactions, between the commonality instance and the participation instances.

Properties

A property defines any information about a commonality that is shared between the participations. This can be values, such as the name of a class, or references, such as the reference to another class being the super class of the given one. In addition, a property defines how this information is mapped to the participations. This can be simple one-to-one-mappings, such as the class name being equivalently represented in UML, Java and their commonality, but there can, for example, be different units used in different metamodels, such that unit conversions have to be performed, or even more complex relations. Technically, properties can be realized as features of the metaclass that realizes a commonality. In the Commonalities language, the mappings to participations are realized as operators.

Operators

An operator defines how a value of commonality is propagated to a participation and vice versa. It allows to encapsulate reusable functionality for both propagation directions at one place. In addition, it allows to have no plain code blocks in the Commmonalities language but only propagate information via those operators. Operators can be defined ad hoc and then used within a commonalities specification, such they the do not need to exist a priori.

Syntax

The syntax of the Commonalities language allows the specification of one commonality per file. It then contains a list of participations and properties. An extract of an exemplary class commonality is given in the following:

import "http://www.eclipse.org/uml2/5.0.0/UML" as uml
import "http://www.emftext.org/java" as java

concept ObjectOrientedDesign

commonality Class {
	// UML participation
	with uml:(Class, single Model, Resource)
	whereat {
		Class in Model,
		Model in Resource,
		-> Model.name = "model",
		-> Resource.path = "model/",
		-> Resource.name = "model",
		Resource.fileExtension = "uml"
	}

	// Java participation
	with java:(Class, CompilationUnit, Resource)
	whereat {
		Class in CompilationUnit.classifiers,
		CompilationUnit in Resource,
		-> Resource.path = "src/",
		Resource.fileExtension = "java"
	}

	// Value property
	has name {
		= uml:Class.name

		= java:Class.name
		// CompilationUnit name schema: '<dot-separated-namespaces>.<name>.java'
		-> javaCompilationUnitName(java:CompilationUnit.name, java:CompilationUnit)
		-> java:Resource.name
	}

	// Reference property
	has superClass {
		= umlSingleGeneralization(uml:Class.generalization, "ObjectOrientedDesign")

		= javaTypeReferenceOrNull(java:Class.^extends, "ObjectOrientedDesign")
	}
}

A with statement defines a participation with its metaclasses. The keyword single indicates a singleton instance of a metaclass, such as a UML model that may only exist once. In the whereat block, conditions for a participation are defined. For example, a UML class has to be contained in a UML model (the keyword in checks the containment relations of the elements). A magic element of commonalities is the Resource, which provides EMF resource handling. The symbols -> and = define whether an operator is executed in both or only in one direction upon changes on either the commonality or the participation. Examples for operators are javaCompilationUnitName or umlSingleGeneralization.

Further information

There is much more to know about the Commonalities language.

Compact information can be found in a conference paper.

Detailed information can be found in a Bachelor's thesis and in Chapter 11 and 12 of the supervisor's dissertation.