Modelling method design: a model-driven approach

The importance of Modelling Method Engineering is equally rising with the importance of Domain Specific Languages and individual modelling approaches. In order to capture the most relevant semantic primitives that address domain specifics needs, it is necessary to involve both, the method engineers as well as domain experts. Based on practical experience in business, more than twenty EU projects and other research initiatives, this paper analyses current approaches in domain specific modelling method specification and introduces a model-driven approach to support the design of a modelling method. The realized modelling tool is introduced and evaluated by two projects in the context of e-Learning, and Business and IT-Cloud Alignment. The paper discusses the evaluation results and derived outlooks.


INTRODUCTION
Concept models are commodity in IT and computer science, hence a growing number of groups around the world design their individual modeling methods, in addition to existing standard ones for a variety of application domains. Models are therefore not only used for schema or software generation but enable information value creation. Hence modeling methods need to provide the necessary concepts and functionality to perform value creation within a particular application domain. The construction of such applicable modeling methods -also titled as conceptualization process -is complex, especially when considering the mapping of the entire spectrum from language artifacts and corresponding functionality to concrete implementable and deployable software-platform capabilities. Today, different approaches, guidelines and practices for the development of modeling tools are available that do not consider the full spectrum of a modelling method design, which unavoidably leads to limitations in the conceptualization. There are branching knowledge domains into more refined and specialized subdomains, where each domain needs to be characterised by its own abstraction and refinement of concepts from reality [27].
ADOxx is a meta modelling platform that has been used (a) in business from the consulting company BOC [2] in realizing their products ADONIS ® , ADOscore ® , ADOlog ® , ADOit ® as well as PROfit ® , PROMOTE ® and ADVISOR ® ; (b) in over thirty University Research and Research Institute collaboration through the Open Models community at OMiLAB as well as (c) in over twenty European Research projects. Although the ADOxx.org [2] community is focusing on the technical realization of modelling tools, it is often also involved in the conceptual specifications of model-based approaches in the context of European Research projects. Based on the experience that has been collected during the realization of model-based approaches in more than twenty European Projects since 2000; a Modelling Method Design Environment is proposed that enables the specification, implementation support and documentation of modelling methods. In order to specify the relevant concepts that are satisfying domain specific needs, it is necessary to involve both, method engineers as well as domain experts in the process of modelling method design [15]. Hence, in order to establish communication, collaboration among actors and support knowledge-externalization an appropriate modelling method design framework, is crucial. This modelling method design is based on the overall Agile Modelling Method Engineering approach [12].
To this end, following the introduction, in Section 2 we analyze current approaches in domain specific modelling method design. In Section 3 we introduce our "Modelling Method Design Environment" that we introduce as an approach for model-driven design of domain specific modelling methods. The theoretical basis is provided by the Generic Modelling Method Specification Framework introduced in [16], [11], and the modelling method conceptualization process introduced by [24], [15] and extended in [17]. In Section 4 we present cases from two different EU funded projects, where we evaluated the Modelling Method Design Environment compared to previous modelling method developments. In Section 5 we share and discuss the evaluation results. Finally in Section 6, we conclude this work with providing an outlook on future work and share our open research questions.

CURRENT APPROACHES IN MODELING METHOD DESIGN
The aim of this work is to provide a modelling method and its corresponding modelling tool to support one of the most important phases during modelling method engineering; the Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. modelling method design. The work follows the meta-modelling approach for definition of the modelling language concepts and their relationships. In this respect, we investigate existing wellknown meta-modelling approaches and then we select and analyze modelling standards from five well-known standardization organizations, which provide intensively used industry modelling standards in last decade; (1) OASIS, (2) OMG, (3) Open Group, (4) W3C and (5) WfMC. It is highly possible that each organization follows same or similar approach and technologies to specify standards within the organization. Therefore, we assume that, it would be enough selecting control samples from each standardization organization in order to understand, which approach they are following, which tools they are using. As the control samples we select UBL [30], ebXML BPSS [9] and WS-BPEL [37] from OASIS; BPMN [20], CMMN [22] and DMN [21] from OMG; ArchiMate® [29] from Open Group; OWL [32], SPARQL [35] and WSDL [31] from W3C, finally XPDL [38] from WfMC.
We investigate, how the modelling language of modelling standards has been specified. We focus on four aspects (1) abstract syntax-, (2) semantic-and (3) notation (concrete syntax)specification of the modelling languages as well as (4) samples provided to ease to understand modelling language specification.
The results of the analysis are presented in Figure 1 In respect of abstract syntax specification organization used (1) graphical approaches and/or, (2) formal textual approaches and/or textual informal approaches. All of organizations utilize UML-Class Diagram [19] to specify abstract syntax of most of their modelling languages. In addition to UML-Class Diagram all standardization institute use natural language to specify the abstract syntax. Additionally in order to ensure interoperability between systems using the given modelling standard and collaboration among parties utilizing the standard, most of the organizations attach importance to formal textual specification of abstract syntax either using with BNF [41] or XSD [42].
It seems that, regarding to specification of semantics there is no standard/approach used commonly by all organization. W3C uses formal languages such as RDF [43], Z Notation [44][14] and standard mathematical notation. However, most of the organizations utilize semi-formal keywords defined in RFC-2119 [45] in order to define requirement level and constraints. Additions to these, all organizations use natural language to specify semantics of all modelling standards. Regarding to specification of notation (concrete syntax), obviously the modelling standards, which have been developed preferentially in the first place for human interpretation, precise has concrete syntax that is illustrated with images and described with natural language. On the other side, the standards, which have been developed for machine interpretation, have concrete syntax specified with formal textual approaches. Mostly, XSD is According to analysis results, for the specification of selected modelling standards, the UML (UML Class Diagram) has been mostly utilized to specify the meta-model of the modelling language.

UML as a Modelling Method Design Approach
As aforementioned, we suggest a conceptualization process for development of domain specific modelling methods, introduced in [15] for create and design phases within this conceptualization process.
As UML is utilized for specification of most of modelling standards in our control sample, we extend our literature research to analyze UML as a prominent modelling method, which is used during create and design phases of the conceptualization process. The pragmatic objective of this analysis is to understand if UMLin context of modelling method design-covers all requirements for the create and design phases, and if there is any shortcomings that we have to consider during the development of our approach.
Glinz evaluates UML in [10] as a requirement specification language. He states that definition of requirements with UML Use Case Diagrams is possible but Use-Case-Diagrams alone are not sufficient. Definitions of concrete functional and non-functional requirements as well as definition of relation between the concepts in domain specific modelling method and requirements are not possible. The authors of [26] indicate the same problem and propose again a UML-based solution to define non-functional requirements and relation between the components in system by combining constructs from UML Class Diagram and UML Component Diagram. Hence the first shortcoming needs to be considered in our approach is; 1. Definition of functional and non-functional requirements and their relation between the concepts in modelling methods.
According to Selic [27] the domain specific modelling languages specify different viewpoints of a complex system. Hence, the complex system should be represented from different viewpoints and some features will be presented in several viewpoints. Moreover the language, presumably, will support multiple viewpoints for different sub-domains, which means language should allow use of different abstract and concrete syntax. With UML Class Diagrams the whole meta-model (abstract syntax) of language can be fragmented. But depicting all alternatives of abstract syntax together can make the class diagram easily very complex and hard to read. To the best of our knowledge the UML does not offer definitions of different concrete syntax for same concept of modelling language. Hence the next shortcomings are 2. Fragmenting whole meta-model into individual metamodels composing concepts for different sub-domains and still be able to define link between concepts in different individual meta-models 3. Having another abstraction layer to represent modules and layers of modelling language as well as relation among them without representing complexity of abstract and concrete syntax 4. Assigning different concrete syntax to the concepts in modelling language.
According to authors of [1], nowadays, models are used to elaborate design decisions, sort out different concepts and exchange the ideas in mainstream software development. They state the importance of traceability during the transformation of information, communication of decisions etc. from design into implementation and vice versa. They indicate that in order to establish the traceability the support of modelling environment is as essential as the approach itself. To the best of our knowledge UML itself does not support such traceability. Then the next shortcoming is:

5.
Traceability of information (e.g design decisions, changes, suggestions etc.) during the knowledge exchange among experts within design phase and also from design to implementation vice versa.
Hence besides the modelling language of domain specific modelling method, we have to consider also designing modeling procedure and mechanisms & algorithms during the design of a modelling method. The design of modelling procedure and mechanisms & algorithms can be possible with using UML (e.g UML Activity diagram for design of the modelling procedure and if we consider description of mechanism and algorithms as sequence of object interactions and message exchange, the UML Sequence diagram can be used for description of mechanism and algorithms). Hence we would not see any shortcoming in UML for this issue. But in order to emphasize requirement of ability to design modelling procedure and mechanisms & algorithms besides the modelling language of a domain specific modelling method and requirement, and requirement of having corresponding supportive modelling environment, we would list this issue here rather as a general requirement than shortcoming of UML that we have to consider in our approach. Hence last but not least; 6. Possibility to design modelling procedure and mechanisms & algorithms of a domain specific modelling language.

THE MODELLING METHOD DESIGN ENVIRONMENT
We mentioned that, we propose the Genetic Modelling Method Specification Framework by Karagiannis and Kühn [16][11] for specification of domain specific modelling methods and a modelling method conceptualization process based on OMILAB LifeCycle [24] and extended in a EU-Project Learn PAd [17]. We introduce both very briefly before we present our approach socalled "Modelling Method Design Environment".

The Generic Modelling Method Specification Framework
The Generic Modelling Method Specification Framework (GMMF), which is introduced by Karagiannis and Kühn in [16][11] guides the modelling method engineers during the development of domain specific modelling languages and mapping appropriate functionalities.
Due to the fact that, the GMMSF has been successfully applied within more than 20 EU Framework Program projects, more than 30 various research projects and in development of different commercial model-driven-management tools (e.g. ADONIS ® , ADOlog ® , ADOit ® , ADOscore ® , PROMOTE ® , ADVISOR ® , etc.), we also propose the GMMSF as an approach to be utilized during the development of domain specific modelling methods and their corresponding modelling tools.
According to the GMMSF, the building blocks of a modelling method are: (1) the modelling language introducing modelling concepts, their semantic, their syntax and their graphical notation, (2) the modelling procedure which defines the stepwise usage of the modelling language, which may not always be available and (3) generic and domain specific mechanisms and algorithms enabling the computer-based processing of models. The GMMF provides a template for the Conceptualization Process of modelling methods [15].

Modelling Method Conceptualization Process
Based on the conceptualisation approach of modelling methods [40], this section introduces the Modelling Method Conceptualization Process, which is depicted in Figure 2, based on the OMILAB Lifecycle [24]. The Conceptualization Process has been extended during a series of meta-modelling workshops within the EU-project Learn Pad, as a process to conceptualize modelling methods. Originally, the OMILAB Lifecycle consists of five phases; (1) Create Phase, where the system under study, application scenarios and their requirements are investigated, (2) Design Phase, where the modelling language with its syntax, semantic and notation (concrete syntax) is specified, mechanisms and algorithms are specified, (3) Formalization Phase, where the specification of modelling language is well-formalized to ensure a possible implementation into a software. (4) Development Phase, where the specified modelling method is implemented on a metamodelling environment, (5) Deployment phase, where the implementation is packaged in the form of standalone application and offered to use of end-users. Having stakeholders with varying knowledge backgrounds and perspectives involved in the conceptualization of a modelling method, and on the other hand stakeholders as end-users with different objectives, the feedback channels are not enough to enable continuous improvement. Therefore, the OMILAB Lifecycle is adapted(as depicted in Figure 2) by adding feedback channels between create and design, in order to prove, if the designed modelling language covers identified application scenarios and considers the identified requirements, between design and formalize to ensure formal approval of modelling language, as well as between design and development phases in order to improve modelling language in earlier stages before it is released and deployed.
The abstraction of domain context specific reality and design of the "system" in a correct way have most significant impact on rest of the Conceptualization Process. Hence we concentrate in this work on development of an appropriate modelling method for modelling method design supporting these two phases.
The work by Karagiannis and et all [15] identifies the actions to investigate application scenarios and requirements of a domain as well as to design that domain specific modelling method (for detailed descriptions of actions please refer to [15]).

Modelling Method Design Environment
Following the model-driven approach, we propose a modelling method, the so-called "Modelling Method Design Environment (MMDE)", to support the design of other modelling methods. During the development of MMDE, a subset of UML has been taken and extended with new concepts based on lessons learned from state-of the art analysis.
Having in mind that the MMDE itself is a modelling method which aims to cover requirements of Create and Design Phases during the Conceptualization Process, , it also has a Modelling Language, Mechanism & Algorithms and a Modelling Procedure,.
In the following sections, (1) we specify, first of all, the concepts in the Modelling Language of MMDE categorizing them as support for Create or Design Phases and then (2) we specify functionalities of MMDE, which are -with another words-its mechanisms and algorithms.

Design Environment
As aforementioned, the Modelling Method Design Environment (MMDE) aims to support the Create and Design Phase (Based on the lessons learned in state-of the art analysis and based on the expertise of authors of this work, who have been involved in several (one of them 5, the other more than 30) modelling method development projects for varying domains, (1) UML has been identified as best possible starting point. And we took a subset of UML and extend the modelling language with required concepts and model types in order to meet shortcomings listed in section 2. , (2) developed a modelling method so-called "Modelling Method Design Environment" and (3) implemented a corresponding fullyfledged modelling editor so-called "Modelling Method Design Environment Modelling Toolkit" available free to download with sample models in [3]. In the following sections we specify the MMDE with introducing its modelling constructs as solutions for the Create and Design Phases. On the other hand, we emphasize our proposals as solutions for shortcoming that we have identified during the state-of-the-art analysis.

Solutions to Support Create Phase.
First of all, to be able to describe and trace the requirements we specify a model type called "Requirements Model Type" The Requirements Model Type (as depicted in Figure 3.  As depicted in Figure 4. , depending on the status of those constructs (if they are considered, reviewed or dismissed), the status of the requirements will be updated accordingly. It is enough, if the user clicks of menu item "Update Requirements Status", the design environment will check if the requirement has been considered in any constructs within the designed modelling method, by checking referenced requirements in all modelling objects in models designed for given modelling method. The MMDE will update the status of requirement accordingly and list of constructs will be updated and presented in the notebook of the given requirement indicating where the requirement has been considered. The MMDE differentiates the status of requirement with colour codes; Grey, if the requirement is not considered yet, Red if the requirement is not considered and dismissed, Yellow, if the requirement is in consideration and Green if the requirement is considered and reviewed.

Solutions to Support Design Phase
As we discussed before, the Design Phase is the most crucial and effort intensive phase of modelling method engineering. Moreover, since the Design Phase is where the specification of concrete modelling language, procedure and mechanisms & algorithms are being made and where the more intensive collaboration and knowledge exchange is needed. The following solutions are offered by the MMDE for the Design Phase.
First of all, to ease the readability and navigation we specified a new model type "Modelling Stack" Modelling Stack Model Type (as depicted in Figure 5) We discussed before that domain specific modelling methods usually specify different fragments of complex systems The different fragments of the system are represented by different model types with merging relevant information. [15]. The modularization and layering of modelling language is essential to avoid complexity during the design of domain specific modelling methods. Hence, we proposed a model type so-called "Modelling Stack Model Type" that allows method engineers differentiate meta-models considering them as different model type that targets different fragments of system. This model type allows the description of hierarchy and dependencies among meta-models on a higherlevel, without giving details about each meta-model   Figure 6). In this model type, the MMDE allows -semantic mapping (as depicted in Figure 7) using existing ontologies defined in RDF or OWL format with utilizing one of the sematic lifting scenarios proposed in [13].. Moreover this model type provides a specific relation called "Pointer" in order enable weaving or specify relation among constructs in different model types (representing different fragments of a system).
Having notation of Class Diagrams from UML suggested by OMG as the initial notation in mind for this model type, we evaluate the graphical notation via multi user tests in several iterations and we suggested some adaptations such as differentiating representation of abstract classes, classes and relation classes from each other, as well as dynamic representation of Pointer construct depending on which weaving type it is representing in order to make this model type more intuitive and easy to read. In order to specify a proper graphical representation (concrete syntax) of each concept in a meta-model, we specify another model type called "Graphical Notation Model Type" Graphical Notation Model Type (as depicted in Figure 8) allows definition of concrete syntax of model types with specifying graphical representations for each constructs in meta-models considering non-functional requirements identified during the Create Phase. This model type allows the description of graphical representations with the assignment of concrete images.

Figure 8. Graphical Notation Model Type Sample
In order to define the applied modelling technique by defining the steps and the results we specified a model type called "Modelling Procedure Modelling Type" Modelling Procedure Model Type (as depicted inFigure 9) allows method engineers define the steps with their required inputs and produced outputs and the sequence of steps based input -output relationship in order to introduce case specific proper usage of their modelling method.

Figure 9 Modelling Procedure Model Type Sample
The version of MMDE is being evaluated in this paper does supports design of Mechanisms and Algorithms of other modelling methods with standard UML 2.0 Sequence and Component Diagrams with exact same syntax and semantic..

3.3.2
Method Design Environment

Transformation
Export and Import Models: The actors involved in the Conceptualization Process should be able to exchange their design, their feedback or open questions created in their own MMDE instance with other actor. Therefore MMDE offers model set import and export in formats ADL and XML.
Image Generation: All actors should not necessarily be users of MMDE, but still they should be able to give their feedback on designs. Therefore, we provide the generation of images models, so that actors can also discuss based on images in formats BMP, PCX, JPG, EMF as well as SVG and give their feedback.
HTML Generation: Just as the idea behind the generation of images of models, all actors are not necessarily users of MMDE. But instead of distribution of images to individual persons, it should be possible to deploy models on the web, make it accessible over the internet and enable discussion on the central knowledge resource. Therefore the MMDE enables transformation of specification and images of models in HTML to be deployed on the web.

Modelling Method Specification Report:
Besides HTML Generation, the MMDE offers transformation of specification and images into reports in PDF format with a pre-defined report template.

Transformation into RDF:
In order to enable validation of metamodels with using semantic web technologies as well as to enable smooth transfer of Design Phase results into the Formalization Phase, the MMDE can transform the models in RDF format.

Analysis
Validation: For implementation of validation logic in the MMDE, two possible technologies are foreseen; (1) using ADOxx specific query language or (2) using semantic technologies (e.g reasoners). At the moment, MMDE validates meta-models based on the following constraint; (a) Each model type must have a unique name, (b) Each model type must contain either at least one class, (c) Each model type must be assigned to one modelling stack (d) Each class must have a unique name. (e) Each relation class must have a unique name, (f) Each relation class must have at least one source endpoint and at least one target endpoint, (g) For each relation class endpoint cardinality must be defined, (h) Each attribute must have a unique name, (i) Each attribute must have an attribute type, (j) Each requirement must be assigned to object in a model within modelling method design. The validation logic based on AQL has already been implemented. The logic based on semantic technologies is under evaluation.

EVALUATION CASES
We applied the MMDE in two different cases so far within two different EU-Projects being in different domains and having consortiums with partners having highly varying profile. In following sub-section we introduce these cases and their requirements shortly.

Design of a Modelling Method for E-Learning in Public Administration
Nowadays public administrators are struggling while adapting rapid changes in their working environment (e.g. changes in regulations, law, society and evolution of technology). The most promising solution for that challenge is probably the transformation of public administration organizations into learning organizations [7] where they can create and use their knowledge assets through the collaborative intelligence [28]. For this transformation, the EU project Learn PAd [17] proposes a process-driven-knowledge management approach based on conceptual and semantic models. In this scenario following challenges are identified; • Modelling method has to consider the following aspects; (a) business processes, (b) motivation, (c) organizational structure and roles, (d) knowledge resources, (e) learning goals, (f) performance measurements.

•
Existing technologies that can realize the solution need to be considered in order to enable a flexible deployment into the legacy Application. (e.g ADOxx®, XWiki®) • The modelling language shall be flexible enough to be implemented on different platforms hence the consortium focuses on a new way of defining the meta-model. Three different abstraction layer are considered (a) Conceptual Meta-model (CMM) specifies formal semantics of concepts that are the abstraction of aspects relevant for e-Learning within Public Administration, (b) Platform Independent Meta-model (PIMM) )) that elaborates the aspects with considering application scenarios, requirements in manner of functional, non-functional requirements, but without considering any specific meta-modelling platform or technology, (c) Platform Specific Meta-model (PSMM) elaborates -addition to PIMM-the technology that is utilized to implement meta-model, hence it considers platform specific concepts and design constraints.

•
Beside abovementioned challenges, another challenge is caused by collaboration for development of the modelling method. Given that the multiple experts from different domains (from software engineering and modelling, business process modelling and analysis, knowledge and learning management, and public administrations shall collaborate to develop the modelling method), the development approach should be appropriate to varying background of those experts.

Design of Modelling Method for Business and IT-Alignment
Cloud Computing is a current trend, which offers flexible IT solitons and which has the potential to massively influence current use of IT and IT investment. Although large enterprises may benefit from this technology by educating their IT departments, SMEs are dramatically falling behind in cloud usage and hence lose the ability to efficiently adapt their IT to their business needs. The H2020 project Cloud Socket [8] introduces the idea of Business Processes as a Service, where concept models and semantics are applied to align business processes with Cloud deployed workflows [39].
The CloudSocket consortium requires defining Business Process at three level; (1) Business Process at Design Level: They should be domain specific business processes that describe the business activities of a worker assigned to that process, They are not executable, neither by a workflow engine within or outside the cloud.
(2) Workflows: They should be executable business processes. They are represented as workflows that orchestrate the interaction between software applications. Cloud Deployment Level: They are workflow bundles, which are deployable on cloud. Those bundles packaged include all relevant deployment configurations, so that it can be deployed on demand.
The requirement mentioned above brings the challenge of consideration of meta-meta-models for environments on those three levels. Hence collaboration among stakeholders with varying background, such as domain experts, business process management experts, workflow management system expert, cloud infrastructure(hardware and software) experts and as well as brokers between business clients and cloud service providers.

EVALUATION RESULTS
At the very beginning of the projects, the MMDE has been introduced to representative of partners, who were contributing into conceptualization of the modelling methods. In case of Learn Pad the first version of its modelling method has been specified on MMDE with representatives of corresponding partners in physical workshop settings. In case of CloudSocket the first version of its modelling method specification has been prepared by a partner, which has modelling method engineering expertise. After having first specification of modelling methods, an installation package of stand-alone version of MMDE has been prepared and it has been circulated with the first versions of modelling method specification report that was exported from MMDE to the corresponding partner representatives, and they circulated them to their teams. They have continued with further conceptualization as well as with the implementation of corresponding modelling tools. The individual works has been consolidated periodically through video conferences (the current version of those modelling tools, which are implemented based on specification prepared on MMDE can be found for Learn PAd [6] and for CloudSocket [4] Having a modelling method and its corresponding toolkit, which are following idea of Model-driven engineering approach , has been proofed to be effective in transferring knowledge from the analysis of requirement up to the development of solutions ( implemented early domain specific solutions (modelling method and corresponding modelling tool) based on created modelling method designs on MMDE can be found for case 1 in [6] and for case 2 in [4]).
The involved actors agreed on that, that the approach presented in this paper has accelerated establishing communication and collaboration, and eased knowledge exchange between actors with different backgrounds, as well as enabled tracing consideration of requirements within the solutions. Evaluation of the MMDE in two concrete cases within complex IT-Projects with multidiscipline and cultural consortiums gave us the occasion to detect further non-functional and functional requirements and required improvements on existing features of the MMDE.

CONCLUSION AND OUTLOOK
We analysed state-of the art in domain specific modelling method design concentrating on small number of, but in industry very intensively used modelling standards. We shortly reviewed the well-known GMMSF by Karagiannis and Kühn, the Conceptualization Process and subsequently we introduce our proposal so-called MMDE aiming to answer requirement found out during the state-of the art analysis We evaluated the MMDE in two complex IT-Projects and determine that our approach has accelerated establishing communication and collaboration, eased knowledge exchange between actors with different backgrounds as well as tracing consideration of requirements within the solutions. However, evaluation results from two evaluation cases point out very concrete shortcomings of the MMDE and existing features that need to be improved. Development of new version of MMDE based on those evaluation results, and its evaluation in another application case(s) are currently ongoing works. Moreover, during the evaluation of t the MMDE, we encountered two essential requirements regarding to traceability and transformation of information, which have not been sufficiently considered in our approach yet; (1) seamless flow from Design to Formalization Phase, and from Formalization Phase to Development Phase without losing any knowledge coming from previous phase and, (2) tracing knowledge created or changed in any phase during any phase. To cover these requirements, first of all we need find answers for following research questions; (1) How to transform meta-models specified as graphical models into formal models automatically (or semi-automatically), (2) what is the appropriate formalisms and formal format to transform into (3) how to allow to change (e.g. improvement, extension of metamodels etc.) meta-models also during Formalization and Development Phase? (4) How to reflect these changes backwards and forwards automatically? (5)How to validated meta-models before deployment and reflect the feedbacks backwards to phases? (6) Which is the appropriate technology to realize solutions for those questions? Having these questions as basis and motivation, we start with extending of our approach covering not just Create and Design Phases but whole Conceptualization Process and begin with development of so-called "Modelling Method Development Framework", which we hope to introduce and evaluate in up-coming publications.

ACKNOWLEDGMENTS
This work has been partly supported by the European Commission co-funded projects Learn PAd (www.learnpad.eu) under contract FP7-619583 and CloudSocket (www.cloudsocket.eu), under contract H2020-ICT 644690