Metadiff - a mode comparison framework

xiaoxiao2021-03-05  24

Metadiff-a mode comparison framework

(Translational draft, waiting for the school)

Translator Note: This is a master's thesis from computer and system sciences in Shergo University, written by Mark Kofman, and mentor is Erik Perjons. The Chinese translator of this paper is Zhou Xiang, a School of Computer Science and Technology, Shandong University. The directory part of the original text is omitted in Chinese translation.

Summary

In software development, the increasing importance of development model has produced many new attention and challenges. This thesis mainly discusses problems in the mode in the environment in which mode-driven development. The purpose of this thesis is to describe the demand analysis of the mode comparison framework called Metadiff, and how to design and implement it. This framework is based on the existing meta Object facility, MOF standard basis. The authors hopes that this framework can be used in the following related experimental research in the step management, realizing a particular mode comparison tool and algorithm assembly.

Chapter 1 Introduction

1.1 background

People have produced more and more interested in pattern drivers, and give more support in applications. These mode driver methods include mode drive software development (Model Driven Software Development) [6], Object Management Mathematical Mode Drive ArchTeratory (OMG Model Driven Architecture) [24], Language Driven Development [8], and more. Some open source projects, such as Eclipse Generative Model Transformer (GMT) [13], NetBeans Metadata Repository (MDR) [22], Eclipse Modeling Framework (EMF) [9], AndroMDA [3] and Various Case Tool manufacturers The work implements a variety of different components for mode-driven development. Modeling can provide a better basis for the development and maintenance of the entire system, and then the code-centric development and maintenance [19] - these methods are based on this idea. Under the guidance of these methods, the mode no longer develops the affiliated product, but constructs a critical component of the software application. However, the importance of increasing development model has produced many new concerns and challenges. One type of problem is closely related to the correct management of modeling tools.

1.2 problem

If you look at the normal code-centric development environment, you will find some features that include the version controls of the environment, different versions of merger, and comparison, and more convenient to make the team development more convenient. tool. Most of these tools are for a single text file and is only applicable to the development process based on conventional programming languages. It is not easy to convert these complex functions to mode drive tools, because there are some problems in this area that requires experts and researchers to point out.

According to reference [17], mode is compared to mode-driven development practice is a key challenge. When processing this problem, there is a few aspects of the following aspects:

l In some object-oriented languages, you can divide them into some classes in logically and physically demands. However, modeling languages ​​lack this standard method that is physically decomposed. This often leads to a large amount of information in a module unit.

l The modules use different symbols to represent that these symbols are usually graphical. However, these symbols do not active role when distinguishing the logic of each module.

l The different visual effects is also a factor that needs to be attached to the use of the pattern chart processing problem. The current text-based comparison tool typically uses two windows to display the text of the comparison. However, this method uses this method to indicate the difference between the mode.

The organization of the L mode is not as sequential like text. Instead, it is made of a tree or a pattern of a tree or a pattern [17]. Therefore, other techniques must be used to study the differences in these modes. Problem Description: In order to solve these problems, researchers and engineering staff need to conduct extensive tests. For this reason, they need a suitable infrastructure solution. This infrastructure enables them to study according to their interests, and observe how other aspects affect and involve other aspects. In addition, this base architecture can generate new ideas and results by integrating components from all parties.

1.3 purpose and intent

The purpose of this paper is to introduce such an infrastructure. This architecture can be used to describe demand, design, and implementation of a common, semi-automated mode comparison solution. General, in a sense, it can be used to compare the mode based on various different meta-models. Semi-automation, in a sense, comparison is operated by a computer, but this algorithm requires a caller to provide additional information and guidance.

In order to achieve such a goal, you need to achieve the following result (purpose):

l The present papers do not work to solve all the problems mentioned above. However, as the result of discussion, these results need to be prototypeed to become a valuable tool for researchers interested in these issues. It means that continuing research on new effective comparisons and merge algorithms include general and metamodial identification algorithms. We can do experiments on the visibility of different charts and study related issues in this field.

l The current framework is also applicable during practical practice. Different tool manufacturers can achieve their respective comparisons and merging tools based on existing frameworks. The comparisons and merge tools built on the basis of the existing framework can be used to improve the processing of the mode.

1.4 method

The author will inject and interpret the method in this paper. The mode comparison framework requires the data provided below:

l Requires research on different modes of different modes in other fields. For general text files, XML files, XML format files need to be completed, and to extract appropriate demand reports for a mode comparison framework.

l The brainstorming meeting of experts in the field, including IT university, and expertise, experts, experts.

The Early prototype of the pattern comparison framework is used for demand optimization.

Further analysis and design framework is further analyzed on the basis of collected needs.

Next, use the Rational Unified Process [15] when developing prototyping frameworks. Use UML language when modeling [26].

In the early stage of research, prototype is widely used in practice to ensure the availability of theoretical concepts. The frame prototype is assessed by examples of the real world.

Since the operation results are evaluated, the system framework is released as part of the open source project, which is conducive to obtaining more user feedback and modification.

1.5 limitations

The frame prototype can be achieved with two sets of MOF standard Java open source systems (Eclipse EMF [9] and NetBeans MDR [22]). This means that the framework can only provide support for the moderate resource coordination of these systems. This limitation can be solved by integrating other MOF standards. Implementing prototypes with other object-oriented languages ​​can also enhance the applicability of the framework itself.

Due to the time relationship, the user feedback assessment of the open source version of the frame will not be discussed in this paper.

1.6 papers structure

This thesis structure is as follows. In the second chapter we give introduction, ideas, and related research results, which will be widely used in the chapters of the papers. In Chapter 3, we define the need for development frameworks. In Chapter 4, we focus on the design and implementation of the framework, and in Chapter 5, we give specific application examples. Chapter 6 is a summary.

This thesis structure is as follows. In the second chapter we give introduction, ideas, and related research results, which will be widely used in the chapters of the papers. In Chapter 3, we define the need for development frameworks. In Chapter 4, we focus on the design and implementation of the framework, and in Chapter 5, we give specific application examples. Chapter 6 is a summary.

This thesis structure is as follows. In the second chapter we give introduction, ideas, and related research results, which will be widely used in the chapters of the papers. In Chapter 3, we define the need for development frameworks. In Chapter 4, we focus on the design and implementation of the framework, and in Chapter 5, we give specific application examples. Chapter 6 is a summary.

Chapter II Concept and related work

Chapter II Concept and related work

2.1 Concepts and Basic Definitions

This section will briefly introduce the basic concepts in this article.

2.1.1 Mode Drive Development

In recent years, many different mode driving methods have been produced. The most famous is the MODEL Driven Architecture from Omg (Model Driven Software Development) [6], and Software Factories [14]. All mode-driven development theories emphasize the importance of the model as the basic unit during development. During modeling, model conversion is the primary operation, used to transfer information from one mode to another mode. This concept of software life cycle is considered a model conversion chain.

2.1.2 mode and chart

When defining patterns and charts, this article uses the concept of a unified modeling language of the object management organization (OMG's Unified Modeling Language) [26]. The chart is another view of the pattern or another perspective. The chart is usually represented by graphic symbols.

2.1.2 mode and chart

When defining patterns and charts, this article uses the concept of a unified modeling language of the object management organization (OMG's Unified Modeling Language) [26]. The chart is another view of the pattern or another perspective. The chart is usually represented by graphic symbols.

2.1.3 Meta-Object Facility (MOF)

2.1.3 Meta-Object Facility (MOF)

The Meta-object tool (MOF) [25] provides a modal warehouse for the specification of the pattern and can be managed by it. MOF can be seen as a tool for designing and implementing a new model language.

2.1.4 Meta-modl layer

2.1.4 Meta-modl layer

In MOF, the concept of modeling is primarily a classifier and an instance, or class (Class) and objects (Object), and will go to its classifier (meta-object, meta-object). ability. This important concept of "meta-mode layer" is sometimes used to organize the modeling layer to convert it to a higher metalayer. Each of the first level is composed of a classifier of the next level. MOF standards ensure that many levels can be defined as needed. However, in most cases, only 4 levels are defined.

The traditional architecture is based on the 4 layer structure below:

The traditional architecture is based on the 4 layer structure below:

The L M0 layer contains application data (e.g., some rows of an instance generated by an object-oriented system, or some rows in the table of the relevant database).

The L M1 layer contains an application; including the definition of the table for the object-oriented system, the definition of the table of related databases. Applications can be modeled in this layer (also known as types or mode levels). L M2 layers, including metemaler in summary:, for example, UML elements such as classes, attributes, operations, and more. The tool functions in this layer (also known as a meta mode or architecture layer).

The L M3 layer is a meta-mode layer of metamodes, which gives the properties of the metamodes that can be obtained in all meta-mode layers (M2 layers). This layer defines the mode of modeling, used to provide various tools to communicate with each other.

2.2 related work

2.2 related work

Although there is very little work, some authors have begun to set up questions discussed in this regard. Similar problems have been raised in the context of formatted forms and database synthesis. According to my thoughts, I gave a few important issues in this paper to summarize the content I do. The work of related research is the main way to get the demand of the model comparison framework.

2.2.1 Mode Management

2.2.1 Mode Management

Mode Management The goal is to make a unified infrastructure for the developer of the mode-driven application. This mode management base framework must be the primary content between the relationship between the pattern, metallogram, and mappings and provide various ways to operate them. .

Other mode management issues will be given in related literature [4]:

Other mode management issues will be given in related literature [4]:

l There are a variety of different ways to characterize mode and mapping: the relevant format table in the database, the property map in the scientific community, the UML model in the software engineering, etc., this too unified definition of the infrastructure is considered to be mode Severe problem in management.

l There will be similar trouble in definitions related to these structures.

l Development of related tools can simplify mode management to be considered and automated.

Microsoft Research Institute [5] has made some research in the field of common mode management in recent years. They have established a collection of algebraic operators. These operators are:

Microsoft Research Institute [5] has made some research in the field of common mode management in recent years. They have established a collection of algebraic operators. These operators are:

l Matching (Match) operator - Two modes as inputs and returns mapping between the two. This mapping can identify a consortium in the input mode medium or similar object, depending on the equivalent or similar standard definition of the system outside the system.

l Composite Operators - Input Mode A to Map of Map B to Map of Mode C, return mode A to mode C mapping.

The L Difference (DIFF) operator - input mode A and mapping from A to Mode B, returns that part of the subset element that does not participate in the mapping relationship.

l Mode Generation (Model Gen) Operator - Input Mode A. Returns a mapping between A and B-generated modes B and a A and B.

l Combined (MERGE) operator - input mode A and mode B, and mapping between them, returns the combination C between A and B, and mapping between C and A, C, and B.

This thesis will tell the urgent needs of model management tasks automation and simplifying tools, and such tools can be seen in a small part of the general mode management infrastructure that has been discussed above.

2.2.2 Comparison Algorithm

Different problems in the symbol sequence have been widely studied (see References [29], [18], [21]). Therefore, algorithms and solutions for text comparison tools have emerged. These achievements have made it possible to develop the actual text mode comparison tool (such as GNU DIFF and some of the other tools). As the study, the comparison algorithm for comparing structured objects occurred. In recent years, many authors have been mentioned in the articles of the tree (see References [28], [7]). This creates a practical application technology that uses these algorithms, which has developed many comparison algorithms for some structured documents such as XML and HTML.

Although the difference analysis algorithm application of the tree is not very wide, the study of this algorithm is applied to modeling tools has begun. In document [2], the authors describe the differential analysis algorithms provided for MOF-based mode, which reflects in this paper to achieve prototyping.

Some algorithms related to matching techniques are described in Reference [27]. Different format matching methods are distinguished: Schema-Level and instance-level matching and language-level-level matching and language (Language- Based and the matching of constrained-based) based on constrained-based. The goal of the framework described herein is to manage these different matching methods.

2.2.3 Database format synthesis

Similar problems discussed here have been introduced in the context of the format form and the literature in database synthesis (such as [16], [27], [1]). Database format integration is a process of integrating the format of the existing database to operate, in which a unified format is used. This is a vast engineering in this field, in which this paper is working in this paper to complete [16] in the IT University's DSV Department [16]. These work pointed out the format integration issues in the joint system.

2.2.4 Visuality of Differences

Mode usually uses graphical symbols to represent, such as UML charts. Reference [23] pointed out the importance of chart difference visualization, which also suggested that different colors identify the difference in the chart, in addition to the difference in language, the author also pointed out that the design needs to be improved, such as moving the class chart.

The development of the development should be able to provide different methods for display differences.

2.2.5 Case Tool

It is worth mentioning that some CASE tool manufacturers want to obtain some meta-mode detail mode comparisons and mergers through this paper. This solution will be a significant progress in this field, however, this does not mean that this paper will provide a complete solution for solving problems.

The author first determines some of the tools developed by the team:

l Omondo Eclipseuml

l Rational Rose Tool Family

l

Enterprise Architect

Due to the limitation of the license, the author cannot be carried out for the assessment of these tools. This list is not complete, and it is not guaranteed to provide a good solution.

Chapter III Demand Analysis

This chapter describes the demand analysis of the Metadiff framework in the form of a usage example. The use case mode is a mode that describes the functionality required for the system and the mode of action (or role) exhibited by each function. The use case model is necessary to systematically analyze and design activities. Figure 3.1 is an example of UML use.

Figure 3.1 Example diagram

3.1 General Description

3.1 General Description

The Metadiff framework is a scaway for an extensible mode for modeling tools. The core of the frame is a set of interfaces or called it as an extensible template. Such an extensible template is mainly implemented to ensure that new mode comparison algorithms can be easily added based on the framework. The main user of this framework is the tool manufacturer and researchers in this field, they can use this framework to develop their own specific components. 3.2 Role Directory (Actor Catalog)

The role directory describes different roles related to the framework and briefly describes the needs of each role in the frame. Figure 3.2 is the role in UML.

Figure 3.2 Role

The framework caller uses the framework function by calling the method. The simulated system is a software framework that does not provide any user interface. This indicates that the frame caller is not a role that the man is playing, although it uses the system to provide API, and it can see it as a software component or other tool for calling the framework method. Frame calhers can operate independently in a particular case, such as the framework extender cannot change the way the frame caller uses the framework.

Frame The Framework Extender is a role that extends the functionality of the frame and applies it to its own environment. This is the role of people, which typically uses the mode comparison frame as a component to develop large-scale system.

Tool Developers (Tool Developer belong to the frame extension, and he develops modeling tools for providing mode comparison functions. Tool developers typically hold specific meta mode. The role of this role is mainly extended framework function to make the modeling tool more suitable for future module integration.

Researcher is another frame extension. His job is to try new research ideas. The goal of this role is to expand the framework for the study of the next step, which is usually done by establishing a different prototype by the top floor of the frame.

3.3 use case mode

3.3.1 Use case: match mode

Mode matching can be viewed as a function, which uses two modes as input, returns mapping between two modes as output. Each mapping element in the matching result refutes a logic correspondence between a particular element in one mode to another in another mode (see References [27]).

This use occurs when the frame caller wants to find two modes of mapping. First, the frame caller specifies the algorithm used by the pattern; then call the mode match function. The frame performs the selected algorithm and returns the mapping result. This mapping is most likely to use in the comparison mode examples mentioned in Section 3.3.2 below. However, such a mapping operation can also be performed independently of the frame caller in this example.

In a particular case, pattern matching will become a problem. In some cases, it involves problems in the language understanding of different people (16]. Therefore, some algorithms require a call to provide critical help to complete work. The design of the frame should be extended for this type of matching algorithm.

3.3.2 Use case: comparison mode

In this case, the frame caller can compare two modes. First, the frame caller specifies an algorithm for mode comparison. Then call the mode comparison function. You can also selectively specify mappings between two modes for the frame caller, which can be used to compare algorithms. Finally, the caller can obtain the resulting result based on the selected algorithm, and the results indicate that the differences in the two modes. This operational result can also be seen as a differential offset (Comparison Delta).

In general, the mode used to compare must be two instances on the same element level (Meta-Level). However, in order to avoid the trouble of encounter mode conversion during comparison, the comparison operation can act as two instances of different meta-models. The frame should not be restricted in this regard, but for comparative algorithms, the input mode and the metammogram need to meet the requirements of the algorithm and can be accepted by the algorithm. Similar to matching algorithms, some comparative algorithms depends on the help of caller and related personnel. The frame design should be scalable to apply to such comparison algorithms.

3.3.3 Use case: implement a new mode matching algorithm

The frame extension should match the mode to the pattern to implement its own algorithm based on the available element mode. The algorithm must be suitable for the characteristics of the meta, and a specific type of mode is input. The algorithm should also be common, to some extent, these algorithms use only the information of the MOF layer.

3.3.4 Use case: implement a new mode comparison algorithm

The frame extension should be able to implement its own algorithm for the mode, if necessary, if necessary, the algorithm is based on the metallogram, formatted comparison offset, and matching algorithms. The algorithm must be suitable for the characteristics of the meta, and a specific type of mode is input. The algorithm should also be common, to some extent, these algorithms use only the information of the MOF layer.

3.3.5 Use case: establish a new comparison offset format

There is currently no strict way to represent the results of the mode comparison. A variety of comparison offset formats have an important role in the comparison of the representation mode. Therefore, the frame expansion should be able to define its own compare offset format as needed.

3.3.6 Use case: Load new metallogram

The frame extension should be able to load new metallic mode as needed. This activity is specified for loading metamodes when implementing the MOF standard. It is worth noting that the definition of the new meta mode is not fully automatic, it requires the relevant personnel to write code and integrate the code inside the frame.

3.4 Program Manual: Building a Comparison Tool

Tool developers use one of the characters to support the development of the mode drive tool by using the Metadiff framework. We may wish to establish a plan manual to describe the process of the tool developer successfully completed the task. Figure 3.3 is an active diagram of this plan manual.

Figure 3.3: Schedule Manual: Build a process of comparing tools

The entire process consists of several steps:

l Evaluate implementation of the MOF standard. Under normal circumstances, the best choice is to use an existing implementation. If you don't fit your purpose, you can implement your own MOF solution.

l Evaluate existing meta mode. You must ensure that the framework can handle your mode resources. This means that the meta mode you use should be loaded in advance. You can also use existing MOF-based solutions to define new metals.

l Evaluate existing pattern matching and comparison algorithms. You may reuse some of the existing algorithms or algorithms. Then implement its own algorithm.

l Finally, you can use this framework in the mode comparison tool.

Chapter 4 Design and Implementation

In this chapter, we propose a design plan for the MetAdiff mode comparison framework.

4.1 architecture

Figure 4.1: Architecture of Metadiff

As shown in Figure 4.1, in higher levels, the Metadiff framework can be divided into three components:

l Extension Template - a collection of interfaces for various expansion of the framework;

l Infrastructure - is a function of loading different mode resources in the MOF standard and the integrated architecture on various metamodes definitions;

l Extensions - Distributed general and dedicated extensions based on Metadiff frameworks. Extended the top floor of the base frame and enables the interface of the extension template. The Metadiff framework is implemented by Java language and has established the following code library (Packages):

Figure 4.2 Dependencies between Java Package

l Org.metadiff - the most basic code base in the frame.

l org.metadiff.Template - The primary interface in the framework is included in the frame.

l Org.metadiff.infra - The code library contains class and sub-code libraries related to the frame of the frame.

l org.metadiff.infra.ecore - The code library contains classes and interfaces related to the use of Eclipse EMF.

l org.metadiff.infra.mdr - The code library contains classes and interfaces related to the use of the NetBeans MDR MOF system.

l Org.metadiff.ext - The code library contains extended code for the frame. Includes that part of the framework that has been implemented.

l org.metadiff.ext.Generic - Collection of universal extensions.

L org.metadiff.ext.Tucs - Implementation code of the comparative algorithm discussed in References [2].

l org.metadiff.ext.delTaxml - Comparative algorithm implemented on the basis of commercial XML comparison tool DelTaxml.

4.1.1 extension template design

The extension template provides a convenient way to add new match comparison algorithms and compare offsets. The extension template consists of a set of interfaces and is provided to the frame caller, which is expressed in the use case mode. Figure 4.3 Class view of the extension template.

Figure 4.3: Class view of the extension template

The current foundation framework is based on two Java-implemented solutions in accordance with the MOF standard. One of the solutions is Eclipse EMF [9], the other is NetBeans MDR [22]. Both allow users to define their own metallogram and provide reflection API (REFLECTIVE API) to access mode data. These APIs can be used to implement matching and comparison algorithms. The Metadiff framework now does not provide a general mode access interface, but this is one of the goals of its efforts.

4.1.3 expansion

The Metadiff framework provides a collection of different extensions. The author believes that the most important thing is TUCSDIFFFINDER, DELTAXMLDIFFINDER and IdBaseDmappingFinder.

L TucsdiffRence expands ModelDIFFDINFER by implementing the comparative algorithms illustrated in Reference [2]. This extension is based on ECORE metallic mode (translation: ECORE metallogram is meta mode of ecore identifier in the UML class).

l DeltaxmldifFinder is implemented based on commercial XML comparison tool DelTaxml, which can be saved in XML mode.

l IdBasedMappingFinder is the extension class of ModelMappingFinder. It uses the ID of the object to match the two modes. This form of mapping is very suitable for the difference between two versions of a model.

We have found that the extension below is also useful:

l Specific meta mode algorithms use information about the quality and efficiency of algorithms in metamodes, such as UML comparison algorithms.

l ModelMapingFinder different extensions. Reference [27] gives a detailed classification of the mode comparison algorithm.

l ModelComparisondelta is extended to an element set, where the element provides a collection of addable or deleted elements. l ModelComparisondelta extension is a mode. It sees the offset (Delta) as a mode, which allows the user to make the mode conversion operation on the offset. This also needs to be specially processed in the comparison algorithm to ensure that the offset can be a Well-Formed mode [5].

4.2 Implementation of the case

In this section, I will tell how the extensions and various extensions are implemented in the needs described in Chapter 3.

4.2.1 Matching mode

l Suppose the frame caller is an object of the FrameworkCaller class;

l FrameworkCaller defines a matching algorithm by implementing the ModelMappingFinder interface;

l If you need a callback (Callback), you can use your own specific logic to implement the mappingCallback interface;

l FrameworkCaller has loaded two modes, which uses MOF-implemented specific loading features, such as org.metadiff.infra.ecore.util.modelloaderutil or Org.Metadiff.Infra.mdr.util.modelloaderutil;

l FrameworkCaller Call the MatchModels method in the ModelMappingFinder class object;

l ModelMapping returns the result, and the result contains the mapping relationship between two modes.

4.2.2 Comparison mode

Assume that the frame caller is an object of the FrameworkCaller class;

l FrameworkCaller defines a comparison algorithm by implementing the ModelDiffFinder interface;

l If the mapping is used in the algorithm, instantiate the ModelMappingFinder interface;

l If you need a callback, you can use your own specific logic to implement the DiffCallback interface;

l FrameworkCaller has loaded two modes, which uses MOF-implemented specific loading features, such as org.metadiff.infra.ecore.util.modelloaderutil or Org.Metadiff.Infra.mdr.util.modelloaderutil;

l FrameworkCaller calls the FindDiff method in the ModelDiffFinder class object;

l ModelComparisondelta returns the result, and the differences include differences between two modes.

4.2.3 Implementing a new mode matching algorithm

It is worth noting that the new mode matching algorithm is defined is a framework extension activity. It is not able to automatically complete the writing code and integrate the code with the framework, but it needs to be helped by people. Make the activity more convenient and direct the target of the frame.

l You can implement the ModelMappingFinder interface or extend an extension.

l Extension modelmapping or any of its extensions if needed.

l Build your extension class.

L Now, you can use the extension created in the first few steps to identify mapping between the mode.

4.2.4 Implementing a new mode comparison algorithm

It is worth noting that the new mode comparison algorithm is a frame extension activity. It is not able to automatically complete the writing code and integrate the code with the framework, but it needs to be helped by people. Make the activity more convenient and direct the target of the frame. l You can implement the ModelDiffFinder interface or extend an extension.

l Extension ModelComparisondelta or any of its extensions if needed.

l Build your extension class.

l Now, you can use the extension created in the previous step to identify the difference between the mode.

4.2.5 Implement a new mode comparison of offset format

It is worth noting that the format of the new comparison offset is a frame extension activity. It is not able to automatically complete the writing code and integrate the code with the framework, but it needs to be helped by people. Make the activity more convenient and direct the target of the frame.

l You can implement the ModelComparisondelta interface or extend an extension.

l Build your extension class.

l Now, you can use the extensions created in the previous step to represent the difference between the mode.

4.2.6 Loading a new metallogram

On the basis of the infrastructure of the frame, new meta mode can be loaded. This activity is specific for each MOF solution.

Eclipse EMF's document [9] describes a method of establishing an ECORE element mode. Simple, the frame extension needs to complete the following activities:

l Use the function of Eclipse EMF to implement meta mode, and the details of this activity are discussed in the documentation of EMF;

l To ensure your meta mode, you must provide the specific code base they need;

l If you like, you can use the help class in Org.Metadiff.Ir.ecore.UTIL.Modelloaderutil by extending Ecoreresource.

l Now, you can use ecoreresource or extended to identify your dollar-based resource in the first few steps.

The method of establishing an MDR mode is described in detail in the documentation [9] of NetBeans MDR. Simple, the frame extension needs to complete the following activities:

l Establish your metallogram using UML or MOF modeling tools that support XMI export features;

l Establish interfaces and classes for JMI Java, which are used to access data in metallogram instances;

l Integrate the generated code and the code library required in the Metadiff framework;

l If you like, you can use the help classes in Org.Metadiff.mdr.Util.Modelloaderutil by extending MDRRRESource;

l Now, you can use MDRRRRRESOURCE or extended to the previous steps to identify your dollar-based resource.

Chapter 5 Example

We develop two application examples of the metadiff framework. There are two examples of the complete source code in the reference [20].

5.1 UML Mode Matching Tool

Suppose we develop a command line-based pattern matching tool for UML 1.4 [26]. The matching tool is characterized by automatically identifying mappings, but it can ask people a mapping relationship between each mode element.

We developed according to the planning manual of the establishment of the model, but it should be noted that our tools only have the functionality of pattern matching.

l There is a UML 1.4 yuan mode defined with NetBeans MDR for us to use.

l We use the CallbackMatchingFnder extension to provide a function of interacting with others. At the same time we have implemented a specific mappingCallback interface. For each callback, our implementation will make the caller use the command line to select an element for match. l We implemented the Frameuses to access the Metadiff's feature through the Java class library.

5.2 establishing a DIFF tool for Swallow mode

Suppose we develop a command line-based pattern matching tool for Swallow mode. Swallow is a simple element model developed by the Eclipse GMT open source project, which can be seen as an instance of the mode-driven software development [6] method, which is described in detail in Reference [10]. You can see the EMF class diagram of this metallogram in Figure 5.1.

Figure 5.1: Swallow metallogram

We develop according to the planning manual of the establishment of the model compare tool:

l Swallow meta mode is defined using EMF ECORE and is supported by the current framework base framework.

l Now, we load SWALLOW meta mode by adding JAR files to the class directory. All required code libraries can be available from the Eclipse GMT project.

l We decided to use the frameworks provided in References [2] to implement our algorithm, so we don't have to build new algorithms themselves.

l We use Java classes to implement frameworks to access metadiff's feature.

In order to test this tool, we introduced the Simple Guest Book Application Model, which is mentioned in [10]. On the Swallow meta mode, we define the first version of the user manual mode and modified it accordingly to apply to that mode. In Figure 5.2, you can see the tree model (translator Note: guest book mode, and modified mode), we have made the following modifications for the original Guest book mode:

l Remove "Guestbook" to "GB"

l Add new attributes for the "GuestBook" class

l Delete the "Text" property in the "Guestentry" class

Figure 5.2: Guest book Application mode version

Established tools will have some different operations at runtime:

l Estably set an element of an Attribute type

l Set the name value of the element of the new Attribute type of the new Attribute, is set to "NAME"

l Set the "text" to "null" by "text" of "Text".

l Change the NAME value of the package by "GuestBook" to "GB"

l Delete the Class element named "Guestentry" to the element named "NULL"

l Insert a link between attribute and name "name" in the Class element inserted between Attribute and Attribute named "Name"

l Delete it by change Attribute to "NULL"

Chapter VI summary

6.1 achievement

The main contribution of this thesis is to develop Metadiff-an extensible mode comparison framework. This framework provides an extension template - a collection of interfaces that make up a good condition for these interfaces. Infrastructure enables integrated solutions, metamodes and extensions that meet MOF standards, which proves the value of the extension template. Our current work has achieved the following results:

l On the basis of the Metadiff framework, the next research work is relatively simple. The next step will only create a prototype. Testing through frame expansion is an important progress against researchers.

l Metadiff extensions can be extended to provide broad mode management capabilities, and can process more abstract theoretical issues.

l The framework established also has practical value. Developers of domain specific language (DSL) can use this framework to implement mode comparison solutions in their respective fields. And we present this feature to everyone through a simple example of the Swallow meta mode of Eclipse GMT.

6.2 after work

We will list the work to be completed in this paper.

6.2.1 Improved Expansion Modules

It is very important to continue to achieve this goal. Existing different frameworks are extended to the upgrade of the extension template provides guiding ideas. Some universal abstract classes can be added to the extension in the extension in the partial portion to promote the improvement of the expansion function.

6.2.2 Establishing a new frame extension

As different expansion components increase, the framework will be more and more value. Below we believe that the most important further improvement method for templates:

L Not expanded on the object recognizer to ensure that the framework can be used in wider cases;

l Comparative algorithm for realization of popular metamodes;

l Establish a well-structured hierarchy for ModelComparisondelta, which improves the framework application and compare offset visual effects;

l The extension of ModelDiffFinder and ModelMatchFinder can make mode comparisons and matches.

6.2.3 Contains other mode management functions

It is very important to expand the functionality of the framework when the user uses the frame. The authors believe that the functionality of the framework can be extended by implementing all mode management functions.

6.2.4 Research on Team Development Problems

In the process of pattern-driven development, there are some team development issues, the author believes that the development of the development can help indicate these issues:

l The problem of comparing graphical representation of offset. In particular, the graphic symbols in the modeling language of industrialization are considered, clear and meaningful representation pattern differences are a very important goal. The establishment of prototypes on the current framework can provide ideas for research.

l The measurable research of the framework is very necessary for the model, which is particularly important in the real world.

references

[1] Alacig, S., Bernstein, P.a. (2001): a Model THEORY for Generic Schema Management, Proc DBPL, Springer Verlag LNCs.

[2] Alanen, M. and Porres,

I. (2003): DIFCERENCE AND

Union of models. Tucs

Turku Center for Computer Science, Department of Computer Science,

Åbo

Akademi

University.

[3] AndroMDa Code Generator Framework (2004) [Computer Software] [Online]. Accessed OctECEMBER 1, 2004 AT URL: http://www.andromda.org/.

[4] Bernstein, P.a., Shapiro, L. (2003): Summary of NSF IDMworkshop Breakout Session NSF IDM Workshop.

[5] Bernstein, P.a. (2003): Applying Model Management To Classical

Meta Data Problems. Proceedings of the Cidr Conference.

[6] Bettin, J. (2004): Introduction to Model-Driven Software Development. Business Procches Trends, MDA Journal, Aprill 2004.

[7] CHAWATHE, S. AND GARCIA-MOLINA, H. (1997): Meaningful Change Detection in Structured Data. In Proceedings of The ACM Sigmod International Conference ON Management Of Data, Pages 26-37,

Tuscon,

ARIZONA.

[8] Clark, T., Evans, A., Sammut, P., Willans, J. (2004) [On-line]: Applied Metamodelling - A Foundation for Language Driven Development, Version 0.1. Accessed On

December 1, 2004 AT URL: http://www.xactium.com/.

[9] Eclipse Modeling Framework (2004) [COMPUTER Software] [on-line]. Accessed On

December 1, 2004 AT URL: http://www.eclipse.org/emf.

[10] EMDE BOAS, G. Van (2004): Template Programming for Model-Driven Code Generation Oopsla / GPCE: BEST PRACTICES for Model-Driven Software Developments.

[11] Fowler, M. (1999): UML Distilled: a brief guide to the standard Object Modeling Language, (2nd Ed.).

[12] Fowler, M. (2003): UML Distilled: a brief guide to the standard Object Modeling Language, (3rd Ed.) PP 79-83.

[13] Eclipse Generative Model Transformer (2004) [Computer Software] [Online]. Accessed On

December 1, 2004 AT URL: http://www.eclipse.org/gmt.

[14]

Greenfield, J. And Short, K. (2004): Software Factories: Assembling Applications with Patterns, Frameworks, Models & Tools. John Wiley & Sons.

[15] IBM Rational: Rational Unified Proccess HomePage (2004) [Online]. Accessed OctECEMBER 1, 2004 AT URL: http://www306.ibm.com/software/awdtools/rup/.

[16] Johannesson, P. (1993): Schema Integration, Schema Translation, And Interoperability On Federated Information Systems. Doctor Thesis, Department of Computer & System Sciences,

Stockholm

University, PP 1-25.

[17] Lin, Y., Zhang, J., Grey, J. (2004): Model Comparison: A Key Challenge for Transformation Testing and Version Control in Model Driven Software Development OOPSLA / GPCE:. Best Practices for Model-Driven Software Developments.

[18] Lowrance, R. And Wagner, R. A. (1975): An extension to the string-to-string correction proBLEM. J. ACM, 22, (2), 177-183.

[19] Mellor, S.J., Scott, K., UHL, A., Weise, D. (2004): MDA Destilled. Principles of Model-Driven Architecture, Addisson-Wesley.

[20] Metadiff Model Comparison Framework (2004) [COMPUTER Software] [Online]. Accessed On

December 1, 2004 AT URL: http://www.dsv.su.se/ Emismak / metadiff / index.html.

[21] MYERS, E. W. (1986): AN O (ND) Difference Algorithm and ITS Variations. Algorithmica, 1: 251-256.

[22] NetBeans: Metadata Repository (2004) [COMPUTER Software] [On-line]. Accessed On

December 1, 2004 AT URL: http://mdr.netbeans.org/.

[23] OHST, D., Welle, M., Kelter, U. (2003): Differences Between Versions of Uml Diagrams. EUROPEAN SOFTWARE ENGINEERING AND ACM SIGSOFT SYMPOSIUM ON The Foundations of Software Engineering.

[24] OMG: Model Driven Architecture Home [on-line], Accessed On

December 1, 2004 AT URL: http://www.omg.org/mda.

[25] OMG (2003):

Meta Object Facility (MOF) 2.0 Core Specification.

[26] OMG (2003): Unified Modeling Language, Version 1.4.

[27] RAHM, E., Bernstein, Pa (2001): a survey of approaches to automatic schema mathing. The VLDB Journal 10: PP 334-350. [28] SHASHA, D., WANG, J., Zhang, K . (1994): Exact and approximate algorithms for unordered Tree Matching. IEEE Transactions on Systems, Man, And Cybernetics, 24 (4): 668-678.

[29] SELLERS, P. H. (1974): An algorithm for the distance between two finite sequences; j. Combinatorial Theory, Series A, 16, 253-258.

(The full text was completed on March 12, 2005)

转载请注明原文地址:https://www.9cbs.com/read-39180.html

New Post(0)