<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Reasoning about Consistency in Model Merging</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Mehrdad Sabetzadeh</string-name>
          <email>mehrdad@simula.no</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Shiva Nejati</string-name>
          <email>shiva@simula.no</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Marsha Chechik</string-name>
          <email>chechik@cs.toronto.edu</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Steve Easterbrook</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Design</institution>
          ,
          <addr-line>Verification</addr-line>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Simula Research Laboratory Oslo</institution>
          ,
          <country country="NO">Norway</country>
        </aff>
        <aff id="aff2">
          <label>2</label>
          <institution>University of Toronto Toronto</institution>
          ,
          <country country="CA">Canada</country>
        </aff>
      </contrib-group>
      <fpage>32</fpage>
      <lpage>38</lpage>
      <abstract>
        <p>Models undergo a variety of transformations throughout development. One of the key transformations is merge, used when developers need to combine a set of models with respect to the overlaps between them. A major question about model transformations in general, and merge in particular, is what consistency properties are preserved across the transformations and what consistency properties may need to be re-checked (and if necessary, re-established) over the result. In previous work [18], we developed a technique based on category-theoretic colimits for merging sets of inter-related models. The use of category theory leads to the preservation of the algebraic structure of the source models in the merge; however, this does not directly provide a characterization of the (in)consistency properties that carry over from the source models to the result, because consistency properties are predominantly expressed as logical formulas. Hence, an investigation of the connections between the “algebraic” and “logical” properties of model merging became necessary. In this paper, we undertake such an investigation and use techniques from finite model theory [9] to show that the use of colimits indeed leads to the preservation of certain logical properties. Our results have implications beyond the merge framework in [18] and are potentially useful for the broad range of techniques in the graph transformation and algebraic specification literature that use colimits as the basis for model manipulations.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Categories and Subject Descriptors</title>
      <p>D.2.1 [Software Engineering]: Requirements/Specifications
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. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.</p>
      <p>Copyright 200X ACM X-XXXXX-XX-X/XX/XX ...$5.00.</p>
    </sec>
    <sec id="sec-2">
      <title>1. INTRODUCTION</title>
      <p>
        In the past several years, we have been studying the
problem of model integration, particularly in situations where the
models are originating from distributed sources of
information. Many activities in model-based development fall under
the umbrella of integration. These include (1) merging, used
to build a global view of a set of overlapping perspectives
(e.g., [
        <xref ref-type="bibr" rid="ref10 ref18 ref20 ref23">23, 20, 18, 10</xref>
        ]); (2) composition, used to assemble a
set of autonomous but interacting components that run
sequentially or in parallel (e.g., [
        <xref ref-type="bibr" rid="ref2 ref5 ref6">2, 5, 6</xref>
        ]); and (3) weaving, used
in aspect-oriented development to incorporate cross-cutting
concerns into a base system (e.g., [
        <xref ref-type="bibr" rid="ref22">22</xref>
        ]).
      </p>
      <p>
        Our position towards the integration problem has been
that the integration operators (e.g., merge, compose, weave)
must tolerate inconsistency. That is, the operators must
work for any given set of models, even when the models are
inconsistent. This position is motivated by two well-known
observations: First, immediate resolution of inconsistency
can be disruptive in projects where ambiguities and conflicts
tend to occur frequently [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ]. Second, maintaining
consistency at all times can be counter-productive because it may
lead to premature commitment to design decisions that have
not yet been sufficiently analyzed [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ].
      </p>
      <p>In light of our position, it is important to understand how
different consistency properties are affected by the
integration operations. Specifically:
• If all the source models are consistent with respect to
a given consistency property, will the integrated model
be consistent with respect to that property as well?
• If there is an inconsistency in the source models, will
the inconsistency necessarily carry over to the
integrated model?</p>
      <p>Answering the first question is interesting to enable
compositional reasoning about consistency. Answering the
second question is useful for understanding the nature of an
inconsistency. In particular, inconsistencies that are due to
incomplete information in the individual source models can
be automatically resolved in the integrated models when the
source models are complementary and address each other’s
areas of incompleteness. For example, an abstract class with
no descendants in a UML class diagram might be seen as
inconsistent. But this class might be inherited from in other
models and hence the overall view might still be consistent.
In contrast, cyclic inheritance in a UML class diagram
cannot be resolved in the integrated model (unless the
integrated model omits information from the source models).
M4
Merge</p>
      <p>D
R3</p>
      <p>A
B</p>
      <p>E
M1</p>
      <p>R4
D
B
E</p>
      <p>A
B
E</p>
      <p>Since consistency rules are often described in logical
languages (e.g., first order logic), we are interested in
studying how different integration operators preserve the logical
properties of models. In general, property preservation is
a powerful tool for reasoning about model transformations.
The main question that property preservation tackles is the
following: If a property (formula) ϕ in some logic holds over
a model M , will ϕ also hold over a model M 0 derived from
M via some transformation?</p>
      <p>
        In this paper, we discuss the logical property preservation
characteristics of our merge operator in [
        <xref ref-type="bibr" rid="ref18">18</xref>
        ]. The merge
operator is based on category theory which has been widely
used as a theoretical basis for characterizing model
merging. In a categorical setting, merge is typically performed
by computing a colimit – an algebraic construct for
combining a set of objects interrelated by a set of mappings. While
colimits provide an effective and mathematically precise way
for merge, their pure algebraic characterization is not
directly applicable for reasoning about the logical properties
of model merging. Specifically, given a property ϕ expressed
in a particular logic, one cannot readily determine from the
definition of colimit whether ϕ is preserved from the source
models to the merged model.
      </p>
      <p>
        We use techniques from finite model theory [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ] to show
that colimits indeed preserve a certain class of logical
properties. The logical language we use as the basis for our
work is first order logic extended with least fixpoints.
Extension with fixpoints is important, because standard first
order logic cannot express properties that require the
computation of reachability. For example, acyclic inheritance
for UML class diagrams is not expressible in standard first
order logic. Our results have implications beyond our merge
framework in [
        <xref ref-type="bibr" rid="ref18">18</xref>
        ] and are potentially useful for the broad
range of techniques in the graph transformation [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ] and
algebraic specification [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ] communities that use colimits as the
basis for model manipulations.
      </p>
      <p>The remainder of this paper is structured as follows: In
Section 2, we provide background information on our merge
algorithm and present the logical preliminaries for our work.
In Section 3, we describe our general logical preservation
results for colimits; and in Section 4, we use these general
results to reason about the preservation of some logical
expressions that are frequently used in consistency rules. We
conclude in Section 5 with a summary and directions for
future work.</p>
    </sec>
    <sec id="sec-3">
      <title>BACKGROUND</title>
    </sec>
    <sec id="sec-4">
      <title>Structural Model Merging</title>
      <p>
        We first briefly review our merge operator. For more
information, see [
        <xref ref-type="bibr" rid="ref18">18</xref>
        ]. The operator hinges on three
abstractions: models, mappings, and interconnection diagrams.
Each model is described as a graph, and each mapping – as
a binary relation over two models equating their
corresponding elements. Mappings preserve type information, i.e., they
do not equate elements that have different types. Further,
they preserve structure, i.e., if a mapping R maps an edge
e to an edge e0, it must also map the source and target of e
to the source and target of e0, respectively.
      </p>
      <p>The third abstraction, the interconnection diagram,
captures a set of models and a set of known or hypothesized
mappings between them. An example interconnection
diagram is shown in Figure 1. In this example, M1, . . . , M4
An equivalence class</p>
      <p>C</p>
      <p>B
C</p>
      <p>E
R1 M2</p>
      <p>R2</p>
      <p>M3
are simple UML class diagrams with their overlapping parts
specified through four mappings, R1, . . . , R4 (depicted
using directed dashed lines). A simpler example with just
two models, M1, M2, and one mapping, R, is shown in
Figure 3(a). A third example is given in Figure 4(a), where the
shared parts of two models, M2, M3, are captured by a third
model M1 and two mappings R1, R2.</p>
      <p>The input to the merge algorithm is an interconnection
diagram D = hM1, . . . , Mi, R1, . . . , Rji. The algorithm works
by unifying elements in M1, . . . , Mi that fall into the same
equivalence class induced by R1, . . . , Rj. As an example,
we have delineated by thin dashed lines one of the several
equivalence classes in Figure 1. Note that each unmapped
element in the input models falls into a distinct equivalence
class of its own.</p>
      <p>For convenience, in the example shown in Figure 1, we
used a consistent vocabulary for naming the elements of
M1, . . . , M4, hence defining R1, . . . , R4 based on name
equalities. In general, models may not have a common
vocabulary, and mappings are not necessarily based on vocabulary
similarities (e.g., see the examples in Figures 3(a) and 4(a)).</p>
      <p>The merged model has exactly one element corresponding
to each equivalence class. Since mappings denote equality
of mapped element pairs and hence are symmetric, the
directionality of mappings is ignored in the computation of
equivalence classes.</p>
      <p>Figure 2 shows the resulting merge for the
interconnection diagram of Figure 1. The merge provides interesting
insights about how consistency properties can be broken
across merge. For example, we may have consistency rules
that check for multiple or cyclic inheritance in UML class
diagrams. Obviously, these rules are satisfied over the
individual source models in Figure 1, but the global view of
the system (i.e., the merge) is inconsistent. In particular,
in Figure 2: B has two parents; and B, C, E form a cycle.
In Section 4, we provide a systematic explanation of what
properties of the source models carry over to the merge and
what properties do not.
2.2</p>
    </sec>
    <sec id="sec-5">
      <title>Logical Background</title>
      <p>
        First Order (FO) logic is one of the most commonly used
logical languages for expressing consistency rules [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ] and
is used as the basis for our work here. FO by itself is not
expressive enough to describe properties that involve
reachability or cycles. To address this limitation, one can add
to FO a least fixpoint operator, obtaining the least fixpoint
logic (LFP) [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ]. Below, we first formally define the notion
of relational structure and FO. We then define the concept
of least fixpoint and show how FO can be extended into
LFP. Our exposition follows the standard approach in finite
model theory (e.g., see [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ]).
      </p>
      <p>Definition 2.1 (relational structure) A (relational)
structure is an object A = (A, R1, . . . , Rm), where A is a nonempty
set, m is a natural number, R1, . . . , Rm are abstract relation
symbols with associated arities k1, . . . , km (nonnegative
integers), and each Ri is a ki-ary relation on A.</p>
      <p>The set A is called the universe of A. The sequence of
relation symbols R1, . . . , Rm together with corresponding arities
k1, . . . , km comprise the vocabulary of A. We usually denote
a vocabulary by σ. Relation RiA is called the interpretation
of a relation symbol Ri in A.</p>
      <p>FO formulas in a vocabulary σ are built up from atomic
formulas using negation, conjunction, disjunction, and
existential and universal quantification:
ϕ
::=
x = y | R(x1, . . . , xn) | ¬ϕ | ϕ1 ∧ ϕ2 | ϕ1 ∨ ϕ2 |</p>
      <p>∃xϕ(x) | ∀xϕ(x)</p>
      <p>In the above, x, y and x1 . . . , xn are variables, R is an
n-ary relation symbol in σ, and ϕ1 and ϕ2 are formulas.</p>
      <p>Given a set U , let P(U ) denote its powerset. A set X ⊆ U
is said to be a fixpoint of a mapping F : P(U ) → P(U ) if
F (X) = X. A set X ⊆ U is a least fixpoint of F if it is
a fixpoint, and for every other fixpoint Y of F , we have
X ⊆ Y . The least fixpoint of F is denoted by lfp(F ). Least
fixpoints are guaranteed to exist only if F is monotone. That
is,</p>
      <p>X ⊆ Y implies F (X) ⊆ F (Y ).</p>
      <p>We now add a least fixpoint operator to FO. Suppose
we have a vocabulary σ, and an additional relation symbol
R 6∈ σ of arity k. Let ϕ(R, x1, . . . , xk) be a formula with
vocabulary σ ∪ {R}. For a structure A with vocabulary σ,
the formula ϕ(R, ~x) yields a mapping Fϕ : P(Ak) → P(Ak)
defined as follows:</p>
      <p>Fϕ(X) = {~a | A |= ϕ(X/R, ~a)}</p>
      <p>The notation ϕ(X/R, ~a) means that X is substituted for R
in ϕ. More precisely, if A0 is a (σ ∪{R})-structure expanding
A, in which R is interpreted as X, then A0 |= ϕ(~a).</p>
      <p>To ensure that Fϕ is monotone, we impose certain
restrictions. Given a formula ϕ that may contain a relation symbol
R, we say that an occurrence of R is negative if it is under
the scope of an odd number of negations, and positive,
otherwise. We say that a formula is positive in R if there are no
negative occurrences of R in it, i.e., either all occurrences of
R are positive, or there are none at all.</p>
      <p>
        Lemma 2.2 [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ] If ϕ(R, ~x) is positive in R, then Fϕ is
monotone.
      </p>
      <p>
        Definition 2.3 (least fixpoint logic) [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ] The least fixpoint
logic (LFP) extends FO with the following formula building
rule:
• if ϕ(R, ~x) is a formula positive in R, where R is k-ary,
and ~t is a tuple of terms, where |~x| = |~t| = k, then
[lfpR,~xϕ(R, ~x)](~t)
is a formula, whose free variables are those of ~t.
      </p>
      <sec id="sec-5-1">
        <title>The semantics is defined as follows:</title>
        <p>A |= [lfpR,~xϕ(R, ~x)](~a)
iff
~a ∈ lfp(Fϕ).</p>
        <p>Example 2.4 (reachability) Consider graphs whose edge
relation is E, and let</p>
        <p>ϕ(R, x, y) = E(x, y) ∨ ∃z (E(x, z) ∧ R(y, z)) .</p>
        <p>Reachability, i.e., the transitive closure of E, is characterized
by the formula</p>
        <p>ψ(x, y) = [lfpR,x,yϕ(R, x, y)](x, y).</p>
        <p>That is, ψ(a, b) holds over a graph G iff there is a path from
a to b in G.
2.3</p>
      </sec>
    </sec>
    <sec id="sec-6">
      <title>Homomorphisms and Preservation of</title>
    </sec>
    <sec id="sec-7">
      <title>Logical Properties</title>
      <p>Our merge framework embeds each source model into the
merge through a homomorphism. The existence of these
homomorphisms leads to the preservation of certain
consistency properties. Below, we review the theoretical results
underlying our discussion of property preservation in
Section 3. We begin with a definition of homomorphism:
Definition 2.5 (homomorphism) Let A = (A, R1A, . . . , RmA)
and B = (B, R1B, . . . , RmB) be structures in the same
vocabulary. A homomorphism from A to B is a function h : A → B
such that h(RiA) ⊆ RiB, i.e., if (a1, . . . , aki ) ∈ RiA then
(h(a1), . . . , h(aki )) ∈ RiB for every 1 ≤ i ≤ m.</p>
      <p>
        The first result about property preservation under
homomorphisms, dating back to the 1950’s, is the
Los-TarskiLyndon Theorem:
Theorem 2.6 (homomorphism preservation theorem)
(e.g., see [
        <xref ref-type="bibr" rid="ref14 ref15">14, 15</xref>
        ]) A first order formula is preserved under
homomorphisms on all structures (finite and infinite) if and
only if it is equivalent to an existential positive formula, i.e.,
a formula without negation and universal quantification.
      </p>
      <p>
        The existential positive fragment of FO is denoted ∃FO+.
For our purposes, we are interested in finite structures only,
and like many classical mathematical logic results that fail
in the finite case (e.g., compactness), there is the danger
that the above result may fail as well when restricted to
finite structures. Fortunately, this is not the case.
Theorem 2.7 (h. p. t. in the finite) [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ] A first order
formula is preserved under homomorphisms on finite
structures if and only if it is equivalent to an ∃FO+ formula.
      </p>
      <p>The forward direction of the if-and-only-if (i.e., sufficiency)
in the above result can be extended to the existential
positive fragment of LFP, denoted ∃LFP+.</p>
      <p>Lemma 2.8 Every ∃LFP+ formula is preserved under
homomorphisms on finite structures.</p>
      <p>A proof of the above lemma is provided in the appendix.
The lemma is the basis for the results we present in
Section 3.</p>
    </sec>
    <sec id="sec-8">
      <title>GENERAL PRESERVATION RESULTS</title>
      <p>
        Our merge framework offers three key features [
        <xref ref-type="bibr" rid="ref18">18</xref>
        ]:
F1 Merge yields a family of mappings, in our case graph
homomorphisms, one from each source model onto the
merged model. This feature ensures that the merge
does not loose information, i.e., it represents all the
source models completely.
      </p>
      <p>F2 The merged model does not contain any unmapped
elements, i.e., every element in the merged model is
the image of some element in the source models. This
feature ensures minimality, i.e., the merge does not
introduce information that is not present in or implied
by the source models.</p>
      <p>F3 Merge respects the mappings in the source system, i.e.,
the image of each element in the merged model remains
the same, no matter which path through the mappings
in the source system one follows. This feature ensures
non-reduandancy. More precisely, if a concept appears
in more than one source model, only one copy of it
appears in the merged model.</p>
      <p>From F1 and Lemma 2.8 (in Section 2.3), it follows that
the result of our merge procedure preserves the existential
positive fragment of LFP.</p>
      <p>Theorem 3.1 If an existential positive LFP formula ϕ is
satisfied by some source model M , any merge in which M
participates satisfies ϕ as well.</p>
      <p>By F2 and the above theorem, we obtain the following
result regarding preservation of universal properties.
Theorem 3.2 Let ϕ(x) be an existential positive LFP
formula with a free variable x. If the formula ψ = ∀x ϕ(x) is
satisfied by all the source models, ψ is satisfied by any merge
of the models as well.</p>
      <p>Notice that Theorem 3.2 allows the introduction of only
one universal quantifier. To gain intuition on what happens
when additional universal quantifiers are introduced,
consider the system in Figure 3(a) and let the relation E(x, y)
denote the graph edge relation. Both models in Figure 3(a)
are complete graphs and hence satisfy the property
∀x ∀y Node(x) ∧ Node(y) ⇒ E(x, y) 1. However, the
property is violated over the resulting merge shown in Figure 3(b),
1The property uses implication and hence has negation. But
the negation can be resolved, because every element in the
universe that is not a node is an edge. Therefore, the
property is equivalent to ∀x ∀y Edge(x) ∨ Edge(y) ∨ E(x, y).
because there is no edge from node a to node d and vice
versa. The general observation here is that, when there is
more than one universal quantifier, universally quantified
variables can be assigned values from non-shared parts of
different source models. In such a case, property
satisfaction over the individual source models may not extend to
the merge.</p>
      <p>Currently, we do not know whether F3 leads to further
property preservation results. This is an issue that we plan
to investigate in future work.
4.</p>
    </sec>
    <sec id="sec-9">
      <title>PRESERVATION OF (IN)CONSISTENCY</title>
      <p>
        In previous work [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ], we identified three general types of
expressions commonly used in structural consistency
properties. These are:
• Compatibility expressions, used for ensuring
compatibility of the type of an edge with the types of its
endpoints.
• Multiplicity expressions, used for defining a minimum
and a maximum number for edges of a given type
incident to a node.
• Reachability expressions, used for checking existence of
paths of edges of a given type between two nodes.
      </p>
      <p>Below, we use results of Section 3 to reason about the
preservation of these expressions.</p>
      <p>Compatibility Properties. Preservation of compatibility
properties can be established directly through algebraic means,
but it is interesting to see if the same can be done through
logical means. For example, in a class diagram, an edge of
type “implements” must relate a class to an interface;
otherwise, the diagram would not be well-formed. This property
can be formalized as follows:</p>
      <p>C1 =
∀e (Edge(e) ∧ Type(e, “implements”) ⇒</p>
      <p>Compatibleclass,interface(e))
where Edge is the set of edges of the graph representing
a class diagram, Type is a binary relation between the set
of edges and different types of relations between classes,
and Compatibleclass,interface(e) is a constraint that verifies
whether the source and target nodes of edge e are of type
class and interface, respectively. The general form of this
constraint can be formalized using an existential positive
formula as follows:</p>
      <p>Compatibleα,β(e) = ∃n (∃m (Source(e, n) ∧ Target(e, m) ⇒</p>
      <p>Type(n, α) ∧ Type(m, β)))
where Source and Target are binary relations, respectively
giving the source and target node for a given edge.</p>
      <p>The sub-formula Type(e, “implements”) of C1 appears in
negated form, but the negation can be resolved, knowing
that (1) the set of types is fixed and, (2) every element has
a type. More precisely, if the set of types is {t1, . . . , tn}, the
formula ¬Type(e, t`) can be replaced with Wi6=` Type(e, ti).
Hence, by Theorem 3.2, C1 is preserved.</p>
      <p>Multiplicity Properties. One can show through simple
counterexamples that none of the following lift from the source
models to the merge:
M1
u
M2
b</p>
      <p>c
R
(a)
a
M1
b
c</p>
      <p>d
(a)
v</p>
      <p>w
R1
x
y
d
M2
R2
z
M3
d
Merge
(b)</p>
      <p>b,c
a,b,u,x,y</p>
      <p>c,d,v,w,z
Merge
(b)
• There exists at least c elements satisfying ϕ.
• There exists exactly c elements satisfying ϕ.
• There exists at most c elements satisfying ϕ.</p>
      <p>
        It is easy to see why the “exactly” and “at most” cases
do not get preserved, noting that merge normally has more
information than any of the source models. To understand
why the “at least” case is not preserved, note that
homomorphisms (and functions as well) are not necessarily
oneto-one, and can therefore shrink the number of elements
satisfying a property. For example, consider the system of
models in Figure 4(a) and its merge in Figure 4(b). For
simplicity, the models are discrete graphs, i.e., sets, and their
mappings are functions. Although M1, M2, M3 all satisfy
the property “there exists at least three (distinct) nodes”,
the merge has only two nodes, hence violating the property.
It is important to mention that the flexibility to fuse
together multiple elements of the same source model is not an
undesirable feature and is indeed valuable when one needs
to perform an abstraction during merge [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ].
      </p>
      <p>Reachability Properties. An interesting consequence of
Theorem 3.1 is the preservation of paths in the merge. Recall
that we gave a formalization for the reachability property
in Example 2.4. To see how this can be used for reasoning
about consistency, consider the following consistency rule
over class diagrams: “Every abstract class must have a
concrete implementation”. This rule is formally expressed as
follows:</p>
      <p>C2 =
∀c ((Type(c, “class”) ∧ Abstract(c)) ⇒</p>
      <p>∃c0(Concrete(c0) ∧ Reachableextends(c0, c)))
where Reachableextends(x, y) holds iff a path from x to y
made up of edges of type “extends” exists. Using the
argument we gave when discussing preservation of compatibility
properties, we know that the negation of Type(c1, ”class”)
can be resolved. Further, ¬Abstract(c1) can be replaced with
a positive property, say, Concrete(c1). It now follows from
Theorem 3.2 that C2 is preserved.</p>
      <p>Note that our results can be used for reasoning about
preservation of inconsistency as well. For example, consider
the following rule:</p>
      <p>C3 =</p>
      <p>∃c ((Type(c, “class”) ∧ Reachableextends(c, c)))</p>
      <p>This rule holds over a class diagram M when the
inheritance hierarchy in M is cyclic, i.e., M is inconsistent. By
Theorem 3.1, we can conclude that any merged model that
has M as a source model satisfies C3 as well, and hence is
also inconsistent.
5.</p>
    </sec>
    <sec id="sec-10">
      <title>CONCLUSION</title>
      <p>In this paper, we showed that the use of algebraic colimits
for model merging leads to the preservation of certain logical
properties. We used our results to formally reason about the
preservation of consistency properties across merge.</p>
      <p>
        Based on our recent survey of existing model merging
techniques [
        <xref ref-type="bibr" rid="ref17">17</xref>
        ], algebraic theories, including category
theory, lattice theory, and formal concept analysis, are
increasingly being used for characterizing model integration
problems. What makes these theories particularly attractive is
the level of abstraction to which they lead, allowing the
merge process to be described in a flexible and highly generic
way. At the same time, one must account for the fact that
merge is often an intermediate step for activities such as
behavioural synthesis [
        <xref ref-type="bibr" rid="ref21 ref23">23, 21</xref>
        ], reasoning over global behaviours
of systems [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ], and data integration and exchange [
        <xref ref-type="bibr" rid="ref13 ref8">8, 13</xref>
        ].
To facilitate these activities, it is crucial to be able to
reason about the preservation of semantic properties (including
consistency properties) of the source models in merge.
Doing so requires establishing proper connections between the
algebraic techniques used in model integration and the
logical techniques used in the activities named above. This is
a non-trivial task but is an essential step toward making
model integration more effective in practice.
      </p>
      <p>For future work, we would like to provide a full logical
characterization of colimits. In particular, the logical
implications of F 3, described in Section 3, is unknown to us
at the moment and need to be revisited in the future.
Further, it may be possible to trade off development flexibility
in favour of a broader class of preserved properties, e.g., by
using more constrained mappings for relating models, or by
placing restrictions on the patterns used for
interconnecting the models. We leave an elaboration of these topics to
future investigation. Lastly, we would like to explore the
application of our results for checking the consistency of model
manipulations in graph transformation and algebraic
specification approaches that are based on colimits.
6.</p>
    </sec>
    <sec id="sec-11">
      <title>A. PROOF FOR LEMMA 2.8</title>
      <p>Let A = (A, R1A, . . . , RmA) and B = (B, R1B, . . . , RmB) be a
pair of relational structures over vocabulary σ = (R1, . . . , Rm).
Let h : A → B be a homomorphism. We show that for every
ϕ ∈ ∃LF P + and for every ~a ∈ Ak</p>
      <p>A |= ϕ(~a) ⇒ B |= ϕ(h(~a))
where h(~a) = (h(a1), . . . , h(ak)).</p>
      <p>The proof for ϕ ∈ ∃F O+ ∩ ∃LF P + follows from
Theorem 2.7. Below, we provide a proof for least fixpoint
formulas.</p>
      <p>Let ϕ(~x) = [lfpR,y~α(R, ~y)](~x). By the definition of lfp,
for every structure A, the formula ϕ yields a mapping Fα,A :
P(Ak) → P(Ak) defined as follows:</p>
      <p>Fα,A(X) = {~a | A |= α(X/R, ~a)}
By Definition 2.3 and Knaster-Tarski’s fixpoint theorem, for
every ~a ∈ Ak we have:</p>
      <p>∞
~a ∈ [ Fαi ,A(∅) ⇔ A |= [lfpR,y~α(R, ~y)](~a)</p>
      <p>i=0
We first prove by induction that h(Fαi ,A(∅)) ⊆ Fαi ,B(∅).
Base case: Let ~a ∈ Fα,A(∅). Then, A |= α(∅, ~a). Since A is
a substructure of B by h and since h(∅) = ∅, we have
B |= α(∅, h(~a)). Thus, h(~a) ∈ Fα,B(∅).</p>
      <p>Inductive step: Let ~a ∈ Fαi ,A(∅). Then, A |= α(Fαi −,A1(∅), ~a).</p>
      <p>Since A is a substructure of B by h, we have B |=
α(h(Fαi −,A1(∅)), h(~a)). Thus, h(~a) ∈ Fα,B(h(Fαi −,A1(∅))).
By the inductive hypothesis and since Fα,B is
monotone, h(~a) ∈ Fαi ,B(∅).</p>
      <sec id="sec-11-1">
        <title>Thus,</title>
        <p>h(Si∞=0 Fαi ,A(∅)) ⊆ Si∞=0 Fαi ,B(∅)</p>
      </sec>
      <sec id="sec-11-2">
        <title>Therefore,</title>
        <p>A |= ϕ(~a)
(By assumption ϕ(~a) = [lfpR,y~α(R, ~y)](~a))
A |= [lfpR,y~α(R, ~y)](~a)
(By Definition 2.3 and Knaster-Tarski’s Theorem)
~a ∈ Si∞=0 Fαi ,A(∅)
(Since h is homomorphism)
h(~a) ∈ h(Si∞=0 Fαi ,A(∅))
(By (1))
h(~a) ∈ S∞</p>
        <p>i=0 Fαi ,B(∅)
(By Definition 2.3 and Knaster-Tarski’s Theorem)
B |= [lfpR,y~α(R, ~y)](h(~a))
(By definition of lfp)
B |= ϕ(h(~a))
(1)
⇔
⇔
⇔
⇒
⇔</p>
      </sec>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <given-names>E.</given-names>
            <surname>Astesiano</surname>
          </string-name>
          ,
          <string-name>
            <given-names>H.</given-names>
            <surname>Kreowski</surname>
          </string-name>
          , and B. Krieg-Brueckner, editors.
          <source>Algebraic Foundations of Systems Specification</source>
          . Springer-Verlag, Secaucus, NJ, USA,
          <year>1999</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <given-names>E.</given-names>
            <surname>Clarke</surname>
          </string-name>
          ,
          <string-name>
            <given-names>O.</given-names>
            <surname>Grumberg</surname>
          </string-name>
          , and
          <string-name>
            <given-names>D.</given-names>
            <surname>Peled</surname>
          </string-name>
          . Model Checking. MIT Press,
          <year>1999</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <given-names>B.</given-names>
            <surname>Davey</surname>
          </string-name>
          and
          <string-name>
            <given-names>H.</given-names>
            <surname>Priestly</surname>
          </string-name>
          . Introduction to Lattices and Order. Cambridge University Press,
          <year>1990</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4]
          <string-name>
            <given-names>S.</given-names>
            <surname>Easterbrook</surname>
          </string-name>
          and
          <string-name>
            <given-names>M.</given-names>
            <surname>Chechik</surname>
          </string-name>
          .
          <article-title>A framework for multi-valued reasoning over inconsistent viewpoints</article-title>
          .
          <source>In Proceedings of the 23rd International Conference on Software Engineering</source>
          , pages
          <fpage>411</fpage>
          -
          <lpage>420</lpage>
          ,
          <year>2001</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [5]
          <string-name>
            <given-names>J.</given-names>
            <surname>Hay</surname>
          </string-name>
          and
          <string-name>
            <given-names>J.</given-names>
            <surname>Atlee</surname>
          </string-name>
          . “
          <article-title>Composing Features and Resolving Interactions”</article-title>
          .
          <source>In SIGSOFT '00/FSE-8: Proceedings of the 8th ACM SIGSOFT International Symposium on Foundations of Software Engineering</source>
          , pages
          <fpage>110</fpage>
          -
          <lpage>119</lpage>
          ,
          <year>2000</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [6]
          <string-name>
            <given-names>M.</given-names>
            <surname>Jackson</surname>
          </string-name>
          and
          <string-name>
            <given-names>P.</given-names>
            <surname>Zave</surname>
          </string-name>
          . “
          <article-title>Distributed Feature Composition: a Virtual Architecture for Telecommunications Services”</article-title>
          .
          <source>IEEE Transactions on Software Engineering</source>
          ,
          <volume>24</volume>
          (
          <issue>10</issue>
          ):
          <fpage>831</fpage>
          -
          <lpage>847</lpage>
          ,
          <year>1998</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [7]
          <string-name>
            <given-names>Y.</given-names>
            <surname>Kalfoglou</surname>
          </string-name>
          and
          <string-name>
            <given-names>M.</given-names>
            <surname>Schorlemmer</surname>
          </string-name>
          .
          <article-title>Ontology mapping: The state of the art</article-title>
          . In Y. Kalfoglou,
          <string-name>
            <given-names>M.</given-names>
            <surname>Schorlemmer</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Sheth</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            <surname>Staab</surname>
          </string-name>
          , and M. Uschold, editors,
          <source>Semantic Interoperability and Integration, number 04391 in Dagstuhl Seminar Proceedings. IBFI</source>
          ,
          <year>2005</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          [8]
          <string-name>
            <given-names>M.</given-names>
            <surname>Lenzerini</surname>
          </string-name>
          .
          <article-title>Data integration: A theoretical perspective</article-title>
          .
          <source>In Proceedings of the 21st Symposium on Principles of Database Systems</source>
          , pages
          <fpage>233</fpage>
          -
          <lpage>246</lpage>
          ,
          <year>2002</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          [9]
          <string-name>
            <given-names>L.</given-names>
            <surname>Libkin</surname>
          </string-name>
          .
          <source>Elements Of Finite Model Theory. Texts in Theoretical Computer Science. An EATCS Series</source>
          . Springer,
          <year>2004</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          [10]
          <string-name>
            <given-names>S.</given-names>
            <surname>Nejati</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Sabetzadeh</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Chechik</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            <surname>Easterbrook</surname>
          </string-name>
          , and
          <string-name>
            <given-names>P.</given-names>
            <surname>Zave</surname>
          </string-name>
          . “
          <article-title>Matching and Merging of Statecharts Specifications”</article-title>
          .
          <source>In ICSE '07: Proceedings of the 29th International Conference on Software Engineering</source>
          , pages
          <fpage>54</fpage>
          -
          <lpage>64</lpage>
          ,
          <year>2007</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          [11]
          <string-name>
            <given-names>C.</given-names>
            <surname>Nentwich</surname>
          </string-name>
          ,
          <string-name>
            <given-names>W.</given-names>
            <surname>Emmerich</surname>
          </string-name>
          ,
          <article-title>and</article-title>
          <string-name>
            <given-names>A.</given-names>
            <surname>Finkelstein</surname>
          </string-name>
          . “
          <article-title>Consistency Management with Repair Actions”</article-title>
          .
          <source>In ICSE '03: Proceedings of the 25 International Conference on Software Engineering</source>
          , pages
          <fpage>455</fpage>
          -
          <lpage>464</lpage>
          ,
          <year>2003</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          [12]
          <string-name>
            <given-names>B.</given-names>
            <surname>Nuseibeh</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            <surname>Easterbrook</surname>
          </string-name>
          ,
          <article-title>and</article-title>
          <string-name>
            <given-names>A.</given-names>
            <surname>Russo</surname>
          </string-name>
          . “
          <article-title>Making Inconsistency Respectable in Software Development”</article-title>
          .
          <source>The Journal of Systems and Software</source>
          ,
          <volume>58</volume>
          (
          <issue>2</issue>
          ):
          <fpage>171</fpage>
          -
          <lpage>180</lpage>
          ,
          <year>2001</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          [13]
          <string-name>
            <given-names>L.</given-names>
            <surname>Popa</surname>
          </string-name>
          ,
          <string-name>
            <given-names>Y.</given-names>
            <surname>Velegrakis</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R.</given-names>
            <surname>Miller</surname>
          </string-name>
          ,
          <string-name>
            <surname>M.</surname>
          </string-name>
          <article-title>Hern´andez, and</article-title>
          <string-name>
            <given-names>R.</given-names>
            <surname>Fagin</surname>
          </string-name>
          .
          <article-title>Translating web data</article-title>
          .
          <source>In Proceedings of 28th International Conference on Very Large Data Bases</source>
          , pages
          <fpage>598</fpage>
          -
          <lpage>609</lpage>
          ,
          <year>2002</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          [14]
          <string-name>
            <surname>E. Rosen.</surname>
          </string-name>
          <article-title>Some aspects of model theory and finite structures</article-title>
          .
          <source>The Bulletin of Symbolic Logic</source>
          ,
          <volume>8</volume>
          (
          <issue>3</issue>
          ):
          <fpage>380</fpage>
          -
          <lpage>403</lpage>
          ,
          <year>2002</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          [15]
          <string-name>
            <given-names>B.</given-names>
            <surname>Rossman</surname>
          </string-name>
          .
          <article-title>Existential positive types and preservation under homomorphisisms</article-title>
          .
          <source>In Proceedings of the 20th Annual IEEE Symposium on Logic in Computer Science</source>
          , pages
          <fpage>467</fpage>
          -
          <lpage>476</lpage>
          ,
          <year>2005</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          [16] G. Rozenberg, editor.
          <source>Handbook of graph grammars and computing by graph transformation: Foundations</source>
          , volume
          <volume>1</volume>
          . World Scientific, River Edge, NJ, USA,
          <year>1997</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          [17]
          <string-name>
            <given-names>M.</given-names>
            <surname>Sabetzadeh</surname>
          </string-name>
          .
          <article-title>Merging and Consistency Checking of Distributed Models</article-title>
          .
          <source>PhD thesis</source>
          , University of Toronto,
          <year>2008</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          [18]
          <string-name>
            <given-names>M.</given-names>
            <surname>Sabetzadeh</surname>
          </string-name>
          and
          <string-name>
            <given-names>S.</given-names>
            <surname>Easterbrook</surname>
          </string-name>
          .
          <article-title>View merging in the presence of incompleteness and inconsistency</article-title>
          .
          <source>Requirements Engineering Journal</source>
          ,
          <volume>11</volume>
          (
          <issue>3</issue>
          ):
          <fpage>174</fpage>
          -
          <lpage>193</lpage>
          ,
          <year>2006</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          [19]
          <string-name>
            <given-names>M.</given-names>
            <surname>Sabetzadeh</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            <surname>Nejati</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            <surname>Liaskos</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            <surname>Easterbrook</surname>
          </string-name>
          , and
          <string-name>
            <given-names>M.</given-names>
            <surname>Chechik</surname>
          </string-name>
          . “
          <article-title>Consistency Checking of Conceptual Models via Model Merging”</article-title>
          .
          <source>In RE '07: Proceedings of 15th IEEE International Requirements Engineering Conference</source>
          , pages
          <fpage>221</fpage>
          -
          <lpage>230</lpage>
          ,
          <year>2007</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref20">
        <mixed-citation>
          [20]
          <string-name>
            <given-names>S.</given-names>
            <surname>Uchitel</surname>
          </string-name>
          and
          <string-name>
            <given-names>M.</given-names>
            <surname>Chechik</surname>
          </string-name>
          . “
          <article-title>Merging Partial Behavioural Models”</article-title>
          .
          <source>In SIGSOFT '04/FSE-12: Proceedings of the 12th ACM SIGSOFT International Symposium on Foundations of Software Engineering</source>
          , pages
          <fpage>43</fpage>
          -
          <lpage>52</lpage>
          ,
          <year>2004</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref21">
        <mixed-citation>
          [21]
          <string-name>
            <given-names>S.</given-names>
            <surname>Uchitel</surname>
          </string-name>
          and
          <string-name>
            <given-names>J.</given-names>
            <surname>Kramer</surname>
          </string-name>
          .
          <article-title>A workbench for synthesising behaviour models from scenarios</article-title>
          .
          <source>In Proceedings of the 23rd International Conference on Software Engineering</source>
          , pages
          <fpage>188</fpage>
          -
          <lpage>197</lpage>
          ,
          <year>2001</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref22">
        <mixed-citation>
          [22]
          <string-name>
            <given-names>J.</given-names>
            <surname>Whittle</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Moreira</surname>
          </string-name>
          , J. Arau´jo,
          <string-name>
            <given-names>P.</given-names>
            <surname>Jayaraman</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Elkhodary</surname>
          </string-name>
          , and
          <string-name>
            <given-names>R.</given-names>
            <surname>Rabbi</surname>
          </string-name>
          . “
          <article-title>An Expressive Aspect Composition Language for UML State Diagrams”</article-title>
          .
          <source>In MoDELS '07: Proceedings of the 10th International Conference on Model Driven Engineering Languages and Systems</source>
          , pages
          <fpage>514</fpage>
          -
          <lpage>528</lpage>
          ,
          <year>2007</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref23">
        <mixed-citation>
          [23]
          <string-name>
            <given-names>J.</given-names>
            <surname>Whittle</surname>
          </string-name>
          and
          <string-name>
            <given-names>J.</given-names>
            <surname>Schumann</surname>
          </string-name>
          . “
          <article-title>Generating Statechart Designs from Scenarios”</article-title>
          .
          <source>In ICSE '00: Proceedings of 22nd International Conference on Software Engineering</source>
          , pages
          <fpage>314</fpage>
          -
          <lpage>323</lpage>
          . ACM Press, May
          <year>2000</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>