Model Transformation Using Description Logics Formalisation English Language Essay

Published:

Introduction

Model driven development (MDD) is widely known as a methodology of software engineering that concern on models, code generation as well as automation [1]. The basic idea of MDD is to use a model to generate the specific platform i.e. program code. Currently, model driven architecture (MDA) is become a prominent approach in MDD that was standardized by object management group (OMG) [2]. In implementation, MDA is a suitable approach in specifying specification to separate the platform independent model (PIM) and platform specific model (PSM).

In MDA, model and model transformation is a central artefact in software development. By using model, a complex system can be expressed at high level of abstraction. A model can be transformed into another model through transformation process. Model transformation is divided into two main kinds namely model-to-code and model-to-model transformation. Model-to-model transformation (M2MT) is believed as one of the key approach to develop software system [2, 3]. The basic idea of M2MT is to construct a model as domain and then transform it into another model that is defined as a specific platform.

Lady using a tablet
Lady using a tablet

Professional

Essay Writers

Lady Using Tablet

Get your grade
or your money back

using our Essay Writing Service!

Essay Writing Service

In software development process, MDD (or MDA) is still in infancy phase which requires the appropriate mechanism i.e. formalisations, techniques and supported tools. Many works have proposed various mechanisms in M2MT, but, most of these mechanisms are either not sufficiently formalized or complicated. The recent mechanisms make writing formal specification becomes difficult and has errors prone. To remedy this problem, this paper describes the basic formalization based on the mathematical foundation to construct M2MT which is closely to human interpretations i.e. Description Logics (DL).

The structure of this paper is as follows. Section II presents the research background i.e. the overview of M2MT and the related existing approaches. Section III describes the proposed approach. Section IV presents the related work. Finally, conclusion and future work are presented in section V.

Background

Model-to-Model Transformation (M2MT)

Most of the existing approaches aimed to support model-to-code transformation, there are limited approaches for M2MT. M2MT is defined as a transformation process that transforms one model into other such as source model into target model and vice versa. M2MT can be produced from the same or different metamodels. M2MT has a function to bridge the available gab in the abstraction level between PIM and PSM by generating the intermediate models [4]. Furthermore, M2MT is useful to compute the different views of a model and synchronising them. The other characteristic of M2MT is the ability to be transferred to different languages; it can be used to analyse and to refine a model during transformation process. The most important characteristic of M2MT has the ability to execute the transformation in either directions (i.e. forward and backward transformation) or bidirectional.

The Related Existing Approaches

There are two prominent approaches to define the M2MT namely triple graph grammars and query view transformation relation. The brief overviews of those approaches are:

Triple Graph Grammars (TGGs)

TGG is a promising approach for model transformation which was firstly introduced by Andi Schurr in [5]. TGGs specify a transformation in a declarative manner and execute a transformation in two directions known as bidirectional (i.e. forward and backward transformation). The basic idea of TGGs is to connect two graphs using correspondence graph. Based on Figure 1, a model should compliant with its metamodels. Transformations between model A and model B are an instance of their correspondence metamodels. TGGs provide triple graph grammar rules which are used to describe how all the models changed simultaneously [6] and it is responsible for transformation process among the involved models through correspondence analysis. TGGs rules can be defined by graphical syntax. However, most proposed approaches are insufficient and informally in forward and backward transformation formalisation [7].

Overview of TGG [8]

Query View Transformation Relational (QVT-R)

QVT-R is as a standard language proposed by Object Management Group (OMG). Currently, QVT-R can be utilised as a language for modelling M2MT in Model Driven Architecture (MDA) where M2MT is constructed by a relationship with one or more domain. Relationship in QVT is represented by using when and where clauses as a guidance to execute the operational mechanism in declarative way [9]. Many efforts have been investigated to increase the ability of QVT-R. However, the existing tools that support M2MT are still limited [10]. This make its application seldom implemented in industrial application.

Lady using a tablet
Lady using a tablet

Comprehensive

Writing Services

Lady Using Tablet

Plagiarism-free
Always on Time

Marked to Standard

Order Now

In implementation, actually both QVT-R and TGGs have a several similarities concepts. One of the examples is they specify the relation between two models in declarative way. By the relation definition, a transformation can be executed from both directions and the changed model can also be propagated into another model.

The Proposed Approach

DL is proposed as an approach to solve the state problem i.e. formalization for developing M2MT.

Description Logics (DL)

DL [11] is a family of knowledge representation formalisms that has the ability to define the structure knowledge of an application domain by defining the relevant concepts or its terminology and specify the world description such as. properties of objects and individual in a domain. The selection of DL is based on the following reasons,

DL is the logic-based knowledge which is able to formalise a complex system.

DL defines the static structure of software application by using a representation language that has been established.

DLs are easy to understand and well-studied because it is closed to human interpretation as well as it has formal semantics.

The community of DL is well-organised and its important feature is its reasoning ability.

Traditionally, a DL knowledge base (KB) is comprised three main parts:

Terminology or schema called TBox that defines the vocabulary of an application domain.

Assertion (world description) called ABox which presents assertion of individuals named in term of this vocabulary. The vocabulary comprises concepts (set of individual) and roles (binary relation between individual).

Description language that specify term and operator in building expressions. The expressiveness of DL depends on its description language.

DL's Formalisation

In this paper, the syntax and semantic of DLs formalism language is presented based on a common description language i.e. (Attribute Language) [11]. The basic descriptions of are comprised as follow:

Suppose and be disjoint and define infinite set of concepts and role names, then each concept name is a concept

Let are concepts and then , are concepts.

The basic inference is subsumption, which is denoted as . Subsumption checks whether the first concept always denotes a subset of the set denoted by the second one.

Every formula will be expressed by applying 1, 2 and 3 rules. Table I presents a set of abstract syntax and semantics of DLs.

Syntax and Semantics of DLs

Constructors

Syntax

Semantics

Concept name

Universal concept

⊤

Bottom

Ø

Negation

Conjunction

Disjunction

Universal quant.



Existential quant.





Unqualified Number

│ { 

Restriction

│ { 

Qualified Number

│ { 

Restriction

│ { 

Func. number restriction

│ { 

Role name

Role conjunction

Role Hierarchi

Inverse Roles

The above notation uses several expressions as follow: interpretation is denoted 𝕿 that comprises of a non-empty set as the domain of interpretation and interpretation function. are atomic concept, while are concept description. Two concepts are called equivalent if for all interpretation 𝕿 and denoted as .

The knowledge base (KB) of DLs is comprised a pair ∑where T is TBox or terminology and is ABox or assertion. TBox is used to define a set of assertion of concepts. ABox is used to define a set of assertion of individuals and , where x and y are individual names, C is a concept, and R is a role. The concept satisfiability in DLs KB can be defined as follow:

, it means that interpretation 𝕿 satisfies to , if and , if it is satisfiable with every assertion in TBox or T.

, if  if and , if it is satisfiable with assertion in A.

, if it is satisfiable to T and A. It means that interpretation satisfies to KB .

DL Metamodel

In model driven development (MDD), metamodel is one of the key concepts to describe a system under study. If a valid metamodel can be produced well, then it can automatically define a certain modelling language. A metamodel is an appropriate approach to specify well-formed models.

In order to able to perform in MDD, DL knowledge base metamodel is defined based on the ontology definition metamodel (ODM) core that proposed by OMG [12] as shown in Figure 2.

Lady using a tablet
Lady using a tablet

This Essay is

a Student's Work

Lady Using Tablet

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Examples of our work

Figure 2. DL metamodel of KB (i.e. TBox and ABox)

Based on Figure 3, at the top level defines meta-classes of both DLTBox and DLABox that communicate with TBox and ABox of DL KB. DLTBox meta-class composes of a set of DLTerm meta-classes and its specialisation. DLABox consists of a set of DLInstances. DLTerm defines an abstract class that has specialisations DLExpression that conform to the DL metamodels description language and DLElement conform to concepts and roles.

Figure 3. The specialization of TBox elements (left) and ABox instance (right) of DL metamodel

Figure 3 sketches that the specialisation of DLInstance in ABox which relates to each element of TBox. DLAssertion specifies DLrole. DLIndividuals define the member of DLConcept. Two specilization of DLConcept is specified by DLDatatype with DLLiteral as instance. Both DLCollection and DLExtent are as instance. DLExpression consists of DLTerm using DlConstructor as shown in Figure 4.

Figure 4. The DL metamodel for Description language expression

The Basic Concept of Model Transformation

Model transformation is defined by Sendall et al. in [13] as a mapping process between element models where a mapping defines the correspondence between them. Figure 5 illustrates the basic concept of model transformation. Transformation from a model M into a model N is bridged by mapping process where each model conform to their metamodel and then it satisfies to DL metamodel. Mapping process is used to correspond between models using a set of roles. There are a set of role can be defined in DL. One of them is an inverse roles which can be used to create M2MT in bidirectional way. For instance, the role become. The Expression of the form true, if only if . The forming of a role name , is the inverse of role name as defined in Table I.

Figure 5. The basic concept of model transformation

To illustrate model transformation based on Figure 5, we view UML class diagram as a model M (as Figure 6) and Entity-Relationship (ER) schema as a model N (as Figure 7).

Figure 6. UML class diagram as a Model M

In this paper, definition of elements static structures (i.e. attribute and association ends) of UML class diagram does not include the dynamic aspect (i.e. operation). Class diagram is the structure diagram that well-established to describe the information in term of object-oriented by classes and relationship among them. Metaclasses are defined similar to classes with add constraint, this means that classes are the instance of metaclass.

Classes of the form depict a set of objects or their instances of the object belong. The properties of classes such attributes is used to define the state of an object denoted with type Usually, attributes are associated with multiplicity that defines how many instance of the attribute may be associated to other class instance. The cardinality constraint states that association to each instances of , at least and at most instance denoted of the form [i..j] for i, j = 0...n. A relationship between two or more classes or a class to itself denoted is stated by an association which is combined with role name following the cardinality of role names . Note that a UML diagram provides association in term of both binary and n-ary relationship. Generalisation in UML depict one class is identified as super-class and other as subclass. Each instance of subclass is instance of super-class. Generalisation may be in the form incomplete or complete and overlooping or disjoint.

Figure 7. ER Schema as Model N

ER schema is used as formalism for database schema design in semantics data models. In semantic data model [11], classes can be used to represent a set of object with their attributes and the relationship to other objects, and subtype/supertype relationship are used to specify the inheritance of properties. ER schema has a set of elements i.e. entities (as boxes), relationship (as diamonds), and attributes (as cycle attached to the entity) which is used to depict the interest domain. Entity defines a set of objects (its instances), with common basic properties which is represented by attributes whose values belong to domain. In ER schema, a relationship is used to define association between instances of the entities which play a part in the relationship. An entity participant in a relationship is known as ER-role (a set of ER-role is called arity) and it must be unique name. Cardinality constraint on ER-role is used to restrict at least and at most an instance of an entity may contribute in the relationship instance. Generalisations are uniquely specified by the combination of the superclass entity name and the generalisation denoted as label constrain which is associated with the generalization,

Based on above description, we can depict the mapping process between UML class diagram and ER schema as shown in Figure 8.

Figure 8. Mapping between UML class diagram and ER schema

A set of role that is used in mapping, we formalise using DL of the form  and  . For example: mapping between association of class to relationship of entity ( be { │ and for forward transformation, whilst } for backward transformation.

The basic concepts of mapping or transformation between them are:

Each class in the model can be transformed into an entity class in model with the same name in ER schema. The map uses its primary key to specify the class instances.

A set of attributes of whether is a primary key (PK) and is also foreign key (FK) for another relation (or as PK in this relation), can be transformed into ER schema as a partial hierarchy of generalization with another relation as the superclass of .

A set of attributes of are not PK but it is FK to another relation (or PK in another relation), can be transformed into ER schema as a relation between and another relation.

Any attributes of are not FK, can be transformed into ER schema as an attribute.

A set of conditions will be associated with these transformations to ensure whether the transformation is successful. For instance, if a model M can be transformed to a model N or vice versa through a set of rules then M and N are equivalent denoted where

Related Work

Recently, a lot of works proposed formalism concept to specify model transformation that involved graph-based transformation and relational approaches. Graph-based transformation manipulates a graph model by a set of rules [14]. Commonly, graph-based is represented using UML diagram that is manipulated with a set of rules. This approach is known as the graph rewriting and a set of rules of transformation are called productions. Some existing languages and framework used graph rewriting in their model transformation namely AGG, PROGRES, AToM3, VIATRA and VMTS. Most of them informally define model transformation and they are either insufficient formalised or complicated.

Subsequently, the relational approaches are well-developed to model transformation. The object management group (OMG) was recognized as a standard to support moving models automatically from one model at an abstraction level into another model at other level. Several examples of standards are OMG's CWM (common Warehouse metamodel specification), XMI (XML Metadata Interchange), QVT (Query-View-Transformation), and M2T (Model-to-Text) [2].

Both relational approaches and Graph-based transformation (or graph rewriting) are the existing formalisms of model transformation. Their model transformations are influenced by model and metamodel concept [4, 15] and rule-based while the rules are defined in different way.

Conclusion and Future Work

The paper presents the architecture of M2MT involved the description logic based on the OMG's DL metamodel. The architecture is used as foundation to formalise the specification of M2MT. The basic notation of DL was presented in this paper to construct M2MT is still general. This study realises that this formalisation still needs to be completed in order to be well-suited in specification of M2MT.

In the future work, the formalization will be extended to specify the bidirectional M2MT (BM2MT) be a challenging task. To visualise the proposed approach, the combination of DL formalization and graph-based approach need to be rigorously explored to be an appropriate approach in BM2MT.

Acknowledgment

The authors would like to thank Universiti Teknologi Malaysia and Malaysian Ministry of Higher Education (MOHE) for their financial support under the Fundamental Research Grant Scheme (FRGS) Vot 78601.