Source: {"pile_set_name": "USPTO Backgrounds"}

A “model” generally describes one or more complex application artifacts (e.g., business processes, data structures, structure and behavior of software systems or other technical and/or business components, etc.) in a formalized fashion. A model can use modeling primitives and/or conventions of a well-defined “abstract language,” which oftentimes is referred to as a metamodel. Some common metamodels are the UML family of modeling languages (e.g., UML class diagrams, UML collaboration diagrams, etc.), the BPMN metamodel, the ARTS family of modeling languages (EPC, VAC, FAD, etc.), the entity-relationship (meta)model (ERM), the relational (meta)model, etc. A metamodel, being an abstract language, may be thought of as a collection of modeling elements that can be used or “instantiated” to describe the actual models. For instance, in a UML class diagram, modeling elements include classes, associations, properties, etc., whereas the model elements in the relational model include relations and their attributes. These modeling elements can be arranged in a variety of well-defined ways to build formal models representing potentially complex business and/or technical processing or other flows.
A metamodel is in principle independent of a concrete notation and therefore may be thought of as an “abstract language,” as indicated above. For instance, a metamodel may define only the language concepts and the rules for their use to form a valid model for the metamodel itself. To do actual modeling with a metamodel, however, a concrete notation is required. Notations of metamodel elements include, for example, boxes with three “compartments” that represent UML classes, labeled rectangles and diamonds used to represent entities and relationships in the ERM, etc.
A common trait of many metamodels is that corresponding models can be represented as a graph including nodes and edges, which collectively can be referred to as the graph's “elements.” Computer systems handling different “kinds” of models (e.g., so-called model management systems) often use some kind of graph model as internal representation for all kinds of models.
Model merging involves creating a single merged result model C, from two models A and B (where A, B, and C can be expressed in the same metamodel), that possibly describe the same or overlapping sets of application artifacts (e.g., the same software system, the same business process, etc.), but describe these artifacts differently. For example, A and B could be two versions of the same original model that were modified independently. As another example, A and B might describe different aspects of an application domain that share some overlap.
It would be desirable to run a merge function to deliver a merged model C that does not contain redundancies. That is, it would be desirable to help ensure that all model elements that appear in both A and B appear at most once in the merged model C. Depending on the exact purpose of C, it oftentimes is desirable to preserve all elements that are either in A or B. Doing so may help to reduce the likelihood of information being lost from the input models. However, this is not a general requirement for merging. It also would be desirable to have the merged model C be consistent and well formed, e.g., so that it meets the constraints of its respective metamodel.
With models being some kind of graphs, model merging is a different challenge than the more common (and usually line-wise) merging of text files as it is done, e.g., in version control systems. Text-based merging of models is theoretically possible if there is a textual (e.g., XML-based) notation for their respective metamodel. However, text-based merge tools are not natural tools for handling the merging of models. For example, most textual representations are ill-suited for direct use by humans and are only meant as storage formats or for model interchange. In particular, the structure of the (linear) textual representations usually differs considerably from the non-linear, graph-like structure of the model itself, making it difficult and cumbersome to work directly with these representations. Second, even small changes of a model can lead to significant changes of its textual representation, making it hard to differentiate between the actual changes on the model level and purely “syntactical” changes implicated by the textual representation. Text-based tools therefore are not really appropriate for model merging.
When designing a merge system for merging two models A and B, a function may be provided for identifying pairs of elements ai and bj from A and B, respectively, that are considered identical (or at least elements that after a successful merge operation should appear only once in the resulting merged model C). “Identical” element pairs are discussed herein as a mapping relation mapAB: A×B.
It will be appreciated that mapAB, being a relation, need neither be injective nor surjective nor a function. In general, model elements from A need not have counterparts in B, and vice versa, and an element ai from A could possibly have several “identical” elements bi1, . . . , Bin in B and vice versa. In literature, techniques for producing such a mapAB from two models A and B are called schema or model matching techniques. In other scenarios, such a mapAB can also result from the process that created models A and B.
Based on the content of mapAB, it is possible to distinguish different categories of (pairs of, groups of, individual, etc.) objects from A and B:                If two objects aiεA and bjεB are identified as identical by mapAB (e.g., (ai,bj)εmapAB), and if no other entries involving ai or bj exist in mapAB a (∃ax s.t. (ax,bj)εmapAB∃by s.t. (ai,by)εmapAB) and if ai and bj agree on all properties that are relevant for the merge method (e.g., certain attributes, etc.), then ai and bj can be called equal. If ai and bj differ in some of their merge-relevant properties, these objects can be referred to as having been changed.        Objects aiεA (bjεB, respectively) for which there exists no object bjεB (aiεA, respectively) such that (ai,bj)εmapAB (∃bjεB s.t. (ai,bj)εmapAB) (∃ai s.t. (ai,bj)εmapAB, resp.) may be called added in A (added in B, respectively).        If two objects aiεA and bjεB are identified as identical by mapAB (e.g., (ai,bj)εmapAB), and if other entries involving ai or bj exist in mapAB ((ax s.t. (ax,bj)εmapAB)(by s.t. (ai,by)εmapAB)), these objects may be referred to as being conflicting.        
With this information, a merge method may create a consistent result model C. While the handling of objects that are equal is seemingly straightforward, it may be the case that decisions have to be made for all other kinds of objects if and how to accept them into the result model C. These decisions may depend on, for example, the intended purpose of C, the details of the conflicts, the context in which A and B where created, etc. These difficulties demonstrate that model merging currently is inevitably a manual task of which only certain trivial tasks can be safely automated. This also implies that, in general, a human has to decide which elements and which properties to take from A and which from B, for inclusion into the result C.
The ARIS model transformation component, provided by the assignee of the instant invention, allows users to declaratively describe how models of one type can be transformed into a semantically related model of a different (or sometimes also the same) model type. An example for such a transformation is shown in FIG. 1. In FIG. 1, a business process modeled using the event-process chain (EPC) metamodel is transformed into an equivalent process in the “business process model and notation” (BPMN) metamodel. This transformation can be referred to as an EPC-2-BPMN transformation. Although the EPC metamodel may be meant to be used by business-oriented users to capture business processes as they are (or should be) handled in an organization, BPMN is a metamodel and notation that also covers more technical aspects. Using the EPC-2-BPMN transformation, a BPMN can be created from an EPC to be used as starting point for enriching the business view of a process with technical details to ultimately make the process executable by a suitable runtime environment like a workflow management system (WfMS). However, the present invention is not limited to the modeling of business processes, but may well be used in other scenarios such as, for example, the systems engineering of complex technical products. For example, the development process of a vehicle is nowadays largely model based. In this scenario, the various vehicle components are typically modeled on a system-wide level defining the main mechanical components such as the chassis, engine and power train, as well as electric/electronic components such as rain sensors, speed-limiters, embedded processors and the related software. Further, the individual vehicle components are themselves defined by more and more concrete technical model as the development process continues, ultimately leading to a variety of technical component models on different levels of abstraction, but yet strongly interrelated.
The description of the transformation is given by so-called transformation patterns or rules, which specify how individual or groups of elements of the source model type are translated into corresponding elements of the target model type. The ARIS model transformation,