RBDC uses the ArgoUML API to extract elements of the UML model that Argo encodes. Since our objective is to merge pairs of class diagrams into one, which relies on the assumption that the elements in two diagrams with the same name actually refer to the same abstract concept, we rename the extracted elements so that this assumption is satisfied in the models. E.g., if two class diagrams have a class named Recipe, we map the extracted class elements to account for this requirement and thus the UML class ID’s of such two classes extracted through Argo will have the same ID in the translated models. This process is shown in Figure 3. In the following sections of the paper, references to a UML Model will be interpreted as references to the Renamed UML Model shown in this figure. The two mappings—Argo API and Rename—are one-to-one; they establish an equivalence relation between a UML model and the Argo model that includes the visual representation of a diagram. In the rest of the paper, we use the terms “diagram” and “model” interchageably.

A UML model is an “instance” of the UML meta model. The UML meta model is an example of an M2-model of the Meta-Object Facility (MOF) [9]. It is the model that describes the UML itself. Also, the UML meta model can be seen as a UML diagram whose instantiations are all possible UML diagrams. The meta model includes Meta- Classes, Datatypes, Attributes, Associations and Constraints. We use a simplified version of the meta model (we refer to it as the minimal UML meta model) that includes Class, Association, Property, DataType, Generalization, Element, Type and Classifier metaclasses. It is based on the meta models from [10] [11]. This version of the meta model is shown in Figure 4.

The following definition of UML model is based on [12] [13] [14]. It includes most of the elements from each of these references and adds some more.

Definition 1. A UML model of a class diagram is defined as M = ( C , A , P , G E N , A T T R , D T , R e l ) , where C is a set of class symbols, A is a set of association symbols, P is a set of association end symbols, GEN is a set of generalization symbols, ATTR is a set of symbols denoting class attributes, and DT is a set of data type symbols.

Rel is a set of the mappings (listed below) of the elements of model M to either

other elements of M or to natural numbers ℕ (and −1, indicating the “*” cardinality).

· a s s o c i a t i o n : P → A

· t y p e : A T T R ∪ P → D T ∪ C , for a t t r ∈ A T T R and p ∈ P , t y p e ( a t t r ) ∈ D T and t y p e ( p ) ∈ C respectfully

· o w n e d A t t r i b u t e : C → 2 A T T R ∪ P

· c l a s s : N P ∪ A T T R → C , where N P = { p | p ∈ P , ∃ ! c ∈ C , p ∈ o w n e d A t t r i b u t e ( c ) }

· m e m b e r E n d : A → 2 P

· o w n e d E n d : A → 2 P

· g e n e r a l : G E N → C

· s p e c i f i c : G E N → C

· l o w e r : P ∪ A T T R → ℕ

· u p p e r : P ∪ A T T R → ℕ ∪ { − 1 }

M must satisfy the following constraints that are applicable to the minimal meta model that we are using:

· ∀ p ∈ P ∪ A T T R • u p p e r ( p ) ≠ − 1 ∧ l o w e r ( p ) ≤ u p p e r ( p )

· ∀ a ∈ A • | m e m b e r E n d ( a ) | = 2

· A T T R ∩ P = ∅

· ∀ a ∈ A   ∀ p ∈ P • p ∈ m e m b e r E n d ( a ) ⇔ a s s o c i a t i o n ( p ) = a

· ∀ g ∈ G E N   ∀ c 1 , c 2 ∈ C • g e n e r a l ( g ) = c 1 ∧ s p e c i f i c ( g ) = c 2 ⇒ c 1 ≠ c 2

· ∀ p ∈ P   ∀ a ∈ A • p ∈ m e m b e r E n d ( a ) ⇒ ( p ∈ o w n e d E n d ( a ) ∧ ¬ ∃ c ∈ C • p ∈ o w n e d A t t r i b u t e ( c ) ) ∨ ( p ∉ o w n e d E n d ( a ) ∧ ∃ c ∈ C • p ∈ o w n e d A t t r i b u t e ( c ) )

· ∀ p 1 , p 2 ∈ P   ∀ a ∈ A   ∀ c ∈ C • o w n e d E n d ( a ) = { p 2 } ∧ { p 1 , p 2 } = m e m b e r E n d ( a ) ∧ p 1 ∈ o w n e d A t t r i b u t e ( c ) ⇒ t y p e ( p 2 ) = c

· ∀ p 1 , p 2 ∈ N P   ∀ a ∈ A   ∀ c 1 , c 2 ∈ C • { p 1 , p 2 } = m e m b e r E n d ( a ) ∧ p 1 ∈ o w n e d A t t r i b u t e ( c 1 ) ∧ p 2 ∈ o w n e d A t t r i b u t e ( c 2 ) ⇒ t y p e ( p 1 ) = c 2 ∧ t y p e ( p 2 ) = c 1

The Rename mapping in Figure 3 denoted here as r, is shown in Definition 2. The definition uses the function name that is implemented using the ArgoUML API. It maps every element of the model to its name. The result of the invocation of r on a UML model is a renamed model used in the processing steps that follow.

Definition 2. The renaming function r is defined in the following way:

1) ∀ c ∈ C • r ( c ) = n a m e ( c ) .

2) ∀ d t ∈ D T • r ( d t ) = n a m e ( d t ) .

3) ∀ a t t r ∈ A T T R • r ( a t t r ) = n a m e ( a t t r ) . n a m e ( c l a s s ( a t t r ) ) . n a m e ( t y p e ( a t t r ) ) .

4) ∀ g ∈ G E N • r ( g ) = n a m e ( g e n e r a l ( g ) ) . n a m e ( s p e c i f i c ( g ) )

5) ∀ p 1 , p 2 ∈ P ,   p 1 , p 2 ∈ m e m b e r E n d ( a s s o c i a t i o n ( p 1 ) ) ,   p 2 ≠ p 1 • r ( a s s o c i a t i o n ( p 1 ) ) . = n a m e ( a s s o c i a t i o n ( p 1 ) ) . n a m e ( p 1 ) . n a m e ( t y p e ( p 1 ) ) . l o w e r ( p 1 ) . u p p e r ( p 1 ) . ( p 1 ∈ N P ) . n a m e ( p 2 ) . n a m e ( t y p e ( p 2 ) ) . l o w e r ( p 2 ) . u p p e r ( p 2 ) . ( p 2 ∈ N P )

6) ∀ p 1 , p 2 ∈ P ,   p 2 ∈ e n d s ( a s s o c i a t i o n ( p 1 ) ) ,   p 2 ≠ p 1 • r ( p 1 ) = n a m e ( p 1 ) . n a m e ( t y p e ( p 1 ) ) . l o w e r ( p 1 ) . u p p e r ( p 1 ) . ( p 1 ∈ N P ) . n a m e ( a s s o c i a t i o n ( p 1 ) ) . n a m e ( p 2 ) . n a m e ( t y p e ( p 2 ) ) . l o w e r ( p 2 ) . u p p e r ( p 2 ) . ( p 2 ∈ N P ) .

A subdiagram of a given model M is a diagram that includes subsets of the sets, functions that are restrictions of the functions, and constraints on M, as provided in Definition 1. This is formally captured by the following Definition 3.

Definition 3. A subdiagram of model M is defined as M ′ = ( C ′ , A ′ , P ′ , G E N ′ , A T T R ′ , D T ′ , R e l ′ ) , where C ′ ⊆ C , A ′ ⊆ A , G E N ′ ⊆ G E N , A T T R ′ ⊆ A T T R and D T ′ ⊆ D T , R e l ′ is collection of restrictions of all functions from R e l on C ′ , A ′ , P ′ , G E N ′ , A T T R ′ and D T ′ (based on [15]). Also, M ′ must satisfy constraints on C ′ , A ′ , P ′ , G E N ′ , A T T R ′ and D T ′ defined in the same way as constraints in Definition 1 by using functions from R e l ′ .

Since many subdiagrams that satisfy Definition 3 will lead to the composing diagrams unacceptable to the user or duplicate composed diagrams, our algorithm generates subdiagrams that (1) do not include disconnected classes and (2) include all the attributes of the classes.

The algorithm for finding subdiagrams is based on partitioning of A ∪ G E N into blocks, R, as shown in Definition 6. Generalizations are partitioned by identifying maximum connected generalization subgraphs. We do not want to break inheritance hierarchies into subdiagrams, since composition of parts of inheritance hierarchies may lead to paradoxical diagrams. The algorithm for finding inheritance hierarchies is not shown in this paper. The definitions of an inheritance hierarchy as well as sets of inheritance hierarchies of the given model are shown in Definitions 4 and 5.

Definition 4. An inheritance hierarchy in model M is I H = ( C i h , G E N i h ) , where C i h ⊆ C , G E N i h ⊆ G E N and for all pairs of classes s , t ∈ C i h there exists a sequence of classes s = c 0 , c 1 , ⋯ , c k = t and ∃ g ∈ G E N i h such that g e n e r a l ( g ) = c i − 1 and s p e c i f i c ( g ) = c i or g e n e r a l ( g ) = c i and s p e c i f i c ( g ) = c i − 1 for all 1 ≤ i ≤ k . Also, for all c ′ ∈ C i h there does not exist g ′ ∈ G E N \ G E N i h such that g e n e r a l ( g ′ ) = c ′ or s p e c i f i c ( g ′ ) = c ′ . I H M is the set of all such IH for M.

Definition 5. The set of all inheritance hierarchies of model M is defined as I H M = { ( C i h , i , G E N i h , i ) | i ∈ { 1, ⋯ , N } } , where ( C i h , i , G E N i h , i ) is an inheritance hierarchy of model M based on Definition 4 and ∪ i = 1 | N |     G E N i h , i = G E N . For all pairs ( C i h , i , G E N i h , i ) , ( C i h , j , G E N i h , j ) ∈ I H M the following must be satisfied: G E N i h , i ∩ G E N i h , j = ∅ .

Definition 6. A partition of A ∪ G E N is defined as R = X ∪ ˙ Y , where X = { A i ⊂ A } and Y = { G E N i h , i ⊂ G E N } , G E N i h , i includes generalizations of an inheritance hierarchy I H i ∈ I M M , and for all pairs A i , A j ∈ X where i ≠ j the following must be satisfied: A i ∩ A j = ∅ and ∪ A i ∈ X   A i = A .

The set X used in Definition 6 is constructed in the following way. For a given integer s < | A | , if | A |   m o d   s = 0 , then A is divided into equal subsets of size s, otherwise there is also one more subset of size | A |   m o d   s . The size of the blocks of the associations s is given by the user based on a desired quality of the optimal composed diagram and performance requirements. A low value of s promotes a more fine grained mix of associations from the input diagrams in the optimal composed diagram. The order in which associations are added to each A i is determined by order of associations in the implementation of A. We chose to partition associations into blocks of equal size with or without remainder.

The algorithm for finding all subdiagrams with the above properties is shown in Algorithm 1. It takes as input a model M, a partition R of A ∪ G E N , and outputs a set of subdiagrams, S. The following are the steps of the algorithm.

1) Find all possible subsets of blocks of R.

2) For each subset of blocks.

a) Find all classes connected by associations and generalizations from the subset.

b) For each identified class, find all attributes from ATTR along with datatypes from DT.

c) Create subdiagrams using associations and generalization from the subsets and identified classes, class attributes and datatypes.

The time complexity of this algorithm is O ( 2 m / n ) , where m = | A ∪ G E N | , and n is the average number of associations and generalizations per block in R. The time complexity of RBDC is discussed in Section 4.4.

Now we provide a formalization of the graphs that will be used to represent class diagrams. The formalization uses category theory; it is based on the work of Ehrig [3] ¹. We introduce some of the definitions to make the paper self-contained. However, some of the details are omitted. Our ultimate objective is to construct an ATGI-graph (Definition 11)—an inheritance respecting typed attributed graph, from an ArgoUML model. ATGI-graph allows to capture UML class diagram elements (e.g., classes, associations and generalizations), relations between these elements, and their properties. In addition, ATGI-graph captures types pertaining to UML class diagrams. A UML class diagram is represented using an E-graph (Definition 7). The types pertaining to the UML class diagrams come from the UML meta model which is represented as an attributed type graph with inheritance (ATGI) described in Definition 9. Considering types is important for insuring that the RBDC output—the composition of two diagrams—is a UML class diagram. The integration of an E-graph representing a UML class diagram with an ATGI representing the UML meta model is provided by a ATGI-clan morphism (Definition 10), resulting in a ATGI-graph (Definition 11).

Definition 7. (E-graph) The tuple G = ( V G , V D , E G , E A , ( s j , t j ) j ∈ { G , A } ) is an E-graph in which V G , V D are graph and data vertices; E G , E A are graph edges and node attribute edges; s j , t j source and target functions for graph and node attribute edges.

E-graphs will be used for representing UML models and meta-classes, meta-associations, meta-attributes and meta-datatypes of the UML meta model.

Definition 8. (UML model converted to E-graph) The graph G M is a representation of a UML model, M, as an E-graph:

G M = ( V G , V D , E G , E A , ( s j , t j ) j ∈ { G , A } ) where:

V G = C ∪ D T ∪ G E N ∪ A T T R ∪ P ∪ A

E G = { ( g , c ) | c ∈ C , g ∈ G E N , g e n e r a l ( g ) = c }                 ∪ ˙ { ( g , c ) | c ∈ C , g ∈ G E N , s p e c i f i c ( g ) = c }                 ∪ ˙ { ( c , a t t r ) | c ∈ C , a t t r ∈ A T T R , a t t r ∈ o w n e d A t t r i b u t e ( c ) }                 ∪ ˙ { ( a t t r , c ) | c ∈ C , a t t r ∈ A T T R , c l a s s ( c ) = a t t r }

∪ ˙ { ( a t t r , d t ) | d t ∈ D T , a t t r ∈ A T T R , t y p e ( a t t r ) = d t } ∪ ˙ { ( p , a ) | p ∈ P , a ∈ A , a s s o c i a t i o n ( p ) = a } ∪ ˙ { ( a , p ) | p ∈ P , a ∈ A , p ∈ m e m b e r E n d ( a ) } ∪ ˙ { ( a , p ) | p ∈ P , a ∈ A , p ∈ o w n e d E n d ( a ) }

∪ ˙ { ( p , c ) | p ∈ P , c ∈ C , t y p e ( p ) = c } ∪ ˙ { ( c , p ) | p ∈ P , c ∈ C , p ∈ o w n e d A t t r i b u t e ( c ) } ∪ ˙ { ( p , c ) | p ∈ N P , c ∈ C , c l a s s ( p ) = c }

V D = { d | ∃ p ∈ P ∪ A T T R , d = l o w e r ( p ) } ∪ { d | ∃ p ∈ P ∪ A T T R , d = u p p e r ( p ) }

E A = { ( p , d ) | p ∈ P ∪ A T T R , d ∈ ℕ , d = l o w e r ( p ) }                   ∪ ˙ { ( p , d ) | p ∈ P ∪ A T T R , d ∈ ℕ ∪ { − 1 } , d = u p p e r ( p ) }

s G : E G → V G ≡ s G ( ( s , t ) ) = s

t G : E G → V G ≡ t G ( ( s , t ) ) = t

s A : E A → V G ≡ s A ( ( s , t ) ) = s

t A : E A → V D ≡ t A ( ( s , t ) ) = t

To represent inheritance in the UML meta model, we add the concept of attributed type graph with inheritance (ATGI).

Definition 9. An attributed type graph with inheritance is defined as A T G I = ( T G , I , A ) where:

1) TG is an E-graph T G = ( T G V G , T G V D , T G E G , T G E A , ( s i , t i ) i ∈ { G , A } ) that represents the meta-classes, meta-associations, meta-attributes and meta-datatypes of the UML meta model.

2) Inheritance graph I = ( I V , I E , s , t ) representing the inheritance structure of the meta model, with I V = T G V G , I E —the inheritance edges, and the source and target functions s , t : I E → I V

3) A set A ⊆ I V representing the abstract nodes that are involved in the inheritance relation

4) For each node n ∈ I V the inheritance clan is defined as c l a n I ( n ) ) = { n ′ ∈ I V | ∃ path from n ′ to n in I } ⊆ I V with n ∈ c l a n I ( n ) .

The graphs representing the UML meta model and a model are combined via the mapping that is defined by an ATGI-clan morphism.

Definition 10. (ATGI-clan morphism) An ATGI clan morphism, t y p e G , is defined as the mapping between G M representing a UML model, M, and ATGI representing the UML meta model:

t y p e G : G M → A T G I with t y p e G = ( t y p e V G , t y p e V D , t y p e E G , t y p e E A ) , where:

1. t y p e V G : V G → T G V G

2. t y p e V D : V D → T G V D

3. t y p e E G : E G → T G E G

4. t y p e E A : E A → T G E A

and t y p e G commutes with sources and targets of G M as well as sources, targets and inheritance clan of ATGI as detailed in [3].

t y p e V G , t y p e V D , t y p e E G , t y p e E A are defined follows:

1. t y p e V G ( v ) = C l a s s , where v ∈ C .

2. t y p e V G ( v ) = P r o p e r t y , where v ∈ P ∪ A T T R .

3. t y p e V G ( v ) = A s s o c i a t i o n , where v ∈ A .

4. t y p e V G ( v ) = G e n e r a l i z a t i o n , where v ∈ G E N .

5. t y p e V G ( v ) = D a t a t y p e , where v ∈ D T .

6. t y p e E G ( ( g , c ) ) = g e n e r a l , where g ∈ G E N , c ∈ C and g e n e r a l ( g ) = c .

7. t y p e E G ( ( g , c ) ) = s p e c i f i c , where g ∈ G E N , c ∈ C and s p e c i f i c ( g ) = c .

8. t y p e E G ( ( c , a t t r ) ) = o w n e d A t t r i b u t e , where c ∈ C , a t t r ∈ A T T R and a t t r ∈ o w n e d A t t r i b u t e ( c ) .

9. t y p e E G ( ( a t t r , c ) ) = c l a s s , where c ∈ C , a t t r ∈ A T T R and c l a s s ( c ) = a t t r .

10. t y p e E G ( ( a t t r , d t ) ) = t y p e , where d t ∈ D T , a t t r ∈ A T T R and t y p e ( a t t r ) = d t .

11. t y p e E G ( ( p , a ) ) = a s s o c i a t i o n , where p ∈ P , a ∈ A and a s s o c i a t i o n ( p ) = a .

12. t y p e E G ( ( a , p ) ) = m e m b e r E n d , where p ∈ P , a ∈ A and p ∈ m e m b e r E n d ( a ) .

13. t y p e E G ( ( a , p ) ) = o w n e d E n d , where p ∈ P , a ∈ A and p ∈ o w n e d E n d ( a ) .

14. t y p e E G ( ( p , c ) ) = t y p e , where p ∈ P , c ∈ C and t y p e ( p ) = c .

15. t y p e E G ( ( c , p ) ) = o w n e d A t t r i b u t e , where p ∈ P , c ∈ C and p ∈ o w n e d A t t r i b u t e ( c ) .

16. t y p e E G ( ( p , c ) ) = c l a s s , where p ∈ N P , c ∈ C and c l a s s ( p ) = c .

17. t y p e V D ( d ) = I n t e g e r , where ∃ p ∈ P ∪ A T T R • d = l o w e r ( p ) ∨ d = u p p e r ( p ) .

18. t y p e E A ( ( p , d ) ) = l o w e r , where p ∈ P ∪ A T T R , d ∈ ℕ and d = l o w e r ( p ) .

19. t y p e E A ( ( p , d ) ) = u p p e r , where p ∈ P ∪ A T T R , d ∈ ℕ ∪ { − 1 } and d = u p p e r ( p ) .

Definition 11. (ATGI-graph) Given an E-graph G representing a UML class diagram, an attributed type graph ATGI with inheritance that represents the UML meta model, and an ATGI-clan morphism t y p e G : G → A T G I representing the typing of the class diagram by the meta model; then G I = ( G , t y p e G ) is an inheritance respecting typed attributed graph (ATGI-graph).

Figure 5 shows a graphical representation of the ATGI that captures the meta model shown in Figure 4. TG and I of the meta model ATGI are merged into one graph, where the edges of I are shown using hollow arrows. This notation was borrowed from [3].

Figure 6 shows an example of a correspondence between an ATGI-graph and a UML class diagram using a graphical representation used by Ehrig in [3] in

which the class diagram is shown at the bottom and an ATGI-graph at the top. The boxes of the ATGI-graph are elements of V G , the arrows between the boxes are elements of E G . The data nodes (elements of V D ) of the E-graph are shown as values of attributes in the boxes (e.g., upper: −1 represents an E A ). The types of the graph vertices, V G , are shown using the UML-like notation for classes (e.g., p1: Property). For the graph edges, E G , and node attribute edges, E A , only the types are shown. For the data vertices, V D , types are omitted.

The blue arrows show (partially) mapping from the elements of the class diagram to the nodes of the ATGI-graph. Meta-associations between elements of the class diagram are mapped to the associations. Meta-attributes of the class diagram elements are mapped to the elements of E A and values of meta-attributes are mapped to elements of V D , e.g., the upper bound of the multiplicity [*] goes to upper: −1.

The names of the elements of E G are computed by concatenating the names of the sources and targets, and their types. The names of the elements of E A are computed by concatenating the names of the sources, values of the targets, and their types.

The process of computing a shared union is depicted in Figure 7. The input to the process is a pair of ATGI-graphs G 1 I = ( G 1 , t y p e G 1 ) and G 2 I = ( G 2 , t y p e G 2 ) , where G i = ( G i , V G , G i , V D , G i , E G , G i , E A , ( s G i , j , t G i , j ) j ∈ { G , A } ) and t y p e G i : G i → A T G I for i = 1 , 2 . ATGI is defined in Definition 9; it represents a UML meta model

shown in Figure 5. The output is an ATGI-graph G 3 I = ( G 3 , t y p e G 3 ) representing a shared union of G 1 I and G 2 I , where t y p e G 3 : G 3 → A T G I . The following are the steps of the process.

1. Step 1: Construct the disjoint unions of the components ( V G , E G , V D , E A ) of G 1 and G 2 listed in Definition 8.

2. Step 2: Define equivalence relations on the disjoint unions from the previous step and insert elements of the disjoint unions to G 3 where equivalent elements are glued together.

3. Step 3: Construct injective E-graph morphisms f : G 1 → G 3 , g : G 2 → G 3 using the equivalence relations defined in the previous step.

4. Step 4: Compute an E-graph G 4 (the largest common subgraph of G 1 and G 2 ) and E-graph morphisms f ′ : G 4 → G 1 , g ′ : G 4 → G 2 as pullback using G 1 , G 2 , G 3 , f and g.

5. Step 5: Compute G 3 I = ( G 3 , t y p e G 3 ) using t y p e G 1 , t y p e G 2 and pushout ( G 3 , f , g ) .

Below, we present descriptions of the steps, starting with Step 2.

Step 2: Equivalence relations on disjoint unions of components of G 1 and G 2 are computed on the assumption of uniqueness of names, i.e., elements that have the same names are glued into one equivalence class in G 3 .

1. [ v ] = { v ′ ∈ G 1, V G ∪ ˙ G 2, V G | v ′ = v } .

2. [ e ] = { e ′ ∈ G 1, E G ∪ ˙ G 2, E G | e ′ = e ∧ s G ( e ′ ) = s G ( e ) ∧ t G ( e ′ ) = t G ( e ) } .

3. [ d ] = { d ′ ∈ G 1 , V D ∪ ˙ G 2 , V D | d ′ = d } .

4. [ a ] = { a ′ ∈ G 1 , E A ∪ ˙ G 2 , E A | a ′ = a ∧ s A ( a ′ ) = s A ( a ) ∧ t A ( a ′ ) = t A ( a ) } .

5. s G 3, G : G 3, E G → G 3, V G ≡ s G 3, G ( [ e ] ) = [ s G ( e ) ] .

6. t G 3 , G : G 3 , E G → G 3 , V G ≡ t G 3 , G ( [ e ] ) = [ t G ( e ) ] .

7. s G 3 , A : G 3 , E A → G 3 , V G ≡ s G 3 , A ( [ a ] ) = [ s A ( a ) ] .

8. t G 3 , A : G 3 , E A → G 3 , V D ≡ t G 3 , A ( [ a ] ) = [ t A ( a ) ] .

Step 3: The morphisms f : G 1 → G 3 , g : G 2 → G 3 are computed component-wise: f = ( f V G , f E G , f V D , f E A ) , g = ( g V G , g E G , g V D , g E A ) .

1. f V G ( v ) = [ v ] ,   g V G ( v ) = [ v ] .

2. f E G ( e ) = [ e ] ,   g E G ( e ) = [ e ] .

3. f V D ( d ) = [ d ] ,   g V D ( d ) = [ d ] .

4. f E A ( a ) = [ a ] ,   g E A ( a ) = [ a ] .

Step 4: G 4 and morphisms f ′ : G 4 → G 1 , g ′ : G 4 → G 2 are computed component-wise using the algorithm for the pullback for attributed graphs [17].

1. G 4 , V G = { ( v 1 , v 2 ) ∈ G 1 , V G × G 2 , V G | f V G ( v 1 ) = g V G ( v 2 ) } .

2. G 4 , E G = { ( e 1 , e 2 ) ∈ G 1 , E G × G 2 , E G | f E G ( e 1 ) = g E G ( e 2 ) } .

3. G 4 , V D = { ( d 1 , d 2 ) ∈ G 1 , V D × G 2 , V D | f V D ( d 1 ) = g V D ( d 2 ) } .

4. G 4 , E A = { ( a 1 , a 2 ) ∈ G 1 , E A × G 2 , E A | f E A ( a 1 ) = g E A ( a 2 ) } .

Source and target functions for G 4 are determined in the following way.

1. s G 4 , G : G 4 , E G → G 4 , V G ≡ s G 4 , G ( ( e 1 , e 2 ) ) = ( s G 1 , G ( e 1 ) , s G 2 , G ( e 2 ) ) .

2. t G 4 , G : G 4 , E G → G 4 , V G ≡ t G 4 , G ( ( e 1 , e 2 ) ) = ( t G 1 , G ( e 1 ) , t G 2 , G ( e 2 ) ) .

3. s G 4 , A : G 4 , E A → G 4 , V G ≡ s G 4 , A ( ( a 1 , a 2 ) ) = ( s G 1 , A ( a 1 ) , s G 2 , A ( a 2 ) ) .

4. t G 4 , A : G 4 , E A → G 4 , V D ≡ t G 4 , A ( ( a 1 , a 2 ) ) = ( t G 1 , A ( a 1 ) , t G 2 , A ( a 2 ) ) .

The morphisms f ′ , g ′ are computed component-wise as shown below. It is easy to show that the morphisms commute: f ∘ f ′ = g ∘ g ′ , as required by the definition of pullback.

1. f ′ V G ( ( v 1 , v 2 ) ) = v 1 , g ′ V G ( ( v 1 , v 2 ) ) = v 2 .

2. f ′ E G ( ( e 1 , e 2 ) ) = e 1 , g ′ E G ( ( e 1 , e 2 ) ) = e 2 .

3. f ′ V D ( ( d 1 , d 2 ) ) = d 1 , g ′ V D ( ( d 1 , d 2 ) ) = d 2 .

4. f ′ E A ( ( a 1 , a 2 ) ) = a 1 , g ′ E A ( ( a 1 , a 2 ) ) = a 2 .

Step 5: To complete the construction of G 3 I , the morphism t y p e G 3 : G 3 → A T G I is computed using t y p e G 1 : G 1 → A T G I , t y p e G 2 : G 2 → A T G I and pushout ( G 3 , f , g ) based on pushout property of ATGI-clan morphisms from [17], where t y p e G 3 ∘ f = t y p e G 1 and t y p e G 3 ∘ g = t y p e G 2 . ( G 3 , f , g ) is pushout according to relationship between pushout and pullback described in [17], since ( G 4 , f ′ , g ′ ) is pullback. The morphism t y p e G 3 is computed component-wise: t y p e G 3 = ( t y p e G 3 , V G , t y p e G 3 , E G , t y p e G 3 , V D , t y p e G 3 , E A ) .

1. t y p e G 3 , V G ( f V G ( v ) ) = t y p e G 1 , V G ( v ) , t y p e G 3 , V G ( g V G ( v ) ) = t y p e G 2 , V G ( v ) .

2. t y p e G 3 , E G ( f E G ( e ) ) = t y p e G 1 , E G ( e ) , t y p e G 3 , E G ( g E G ( e ) ) = t y p e G 2 , E G ( e ) .

3. t y p e G 3 , V D ( f V D ( d ) ) = t y p e G 1 , V D ( d ) , t y p e G 3 , V D ( g V D ( d ) ) = t y p e G 2 , V D ( d ) .

4. t y p e G 3 , E A ( f E A ( a ) ) = t y p e G 1 , E A ( a ) , t y p e G 3 , E A ( g E A ( a ) ) = t y p e G 2 , E A ( a ) .

The time complexity of the algorithm for constructing shared unions of pairs of diagrams is as follows. Assume that D 1 and D 2 are two input diagrams, A 1 and G E N 1 are associations and generalizations of D 1 , and A 2 and G E N 2 are associations and generalizations of D 2 . The time complexity of the algorithm is O ( 2 ( m 1 + m 2 ) / n ) , where m 1 = | A 1 ∪ G E N 1 | and m 2 = | A 2 ∪ G E N 2 | .

In fact, this represents the time complexity of RBDC. Also, the time complexity of RBDC is further reduced by generating shared unions that are connected graphs. The performance of RBDC is in Section 5.3 describing the results of our evaluation.

The composed UML model resulting from the algorithms described above may contain some redundancies, e.g., the same attribute appearing in both sub and superclasses. The redundancies addressed in our algorithms are captured in the following definition.

Definition 12. Class c s u p e r ∈ C is a superclass class of class c ∈ C if s s u p e r ≠ c and there exists a sequence of classes c s u p e r = c 0 , c 1 , ⋯ , c k = c and ∃ g ∈ G E N such that g e n e r a l ( g ) = c i − 1 and s p e c i f i c ( g ) = c i for all 1 ≤ i ≤ k .

The algorithm does the following. If the class c ∈ C of model M has an attribute a t t r ∈ A T T R (along with datatype d t ∈ D T ), and there is a superclass of c that has attribute a t t r ′ ∈ A T T R (along with datatype d t ′ ∈ D T ), where n a m e ( a t t r ′ ) = n a m e ( a t t r ) and d t ′ = d t , then remove attr from ATTR, 〈 c , a t t r 〉 from owned Attribute, 〈 a t t r , d t 〉 from type and 〈 a t t r , c 〉 from class.

The conversion of UML class diagrams to OWL is based on the Ontology Definition Meta model (ODM) specification [18] that describes the mapping between UML elements and OWL entities. The mapping is achieved using an existing tool—UML2OWL, by Leinhos—described in [19]. The original tool supports reading class diagrams in XMI 1.2 format implemented by Poseidon 4.1. We modified the tool to allow support of class diagrams in XMI 1.2 format implemented by ArgoUML. Also, we added support of property qualified cardinality restrictions.

Some of the assertions that are needed to infer that the external constraints are satisfied may not be explicit in the diagram ontology initially but can be inferred based on class diagram elements that are explicit. Examples of such implicit assertions supported by RBDC are statements about derived associations (including those that are based on inherited association ends), chains of generalizations, and inherited class attributes.

Derived associations based on inherited association ends, chains of generalizations and inherited class attributes are inferred using the axiom of the transitivity of the subClassOf property. The axiom is executed by BaseVISor (OWL2 RL) reasoner [20].

The inference of other kinds of derived associations are not supported by the rules obtained through the ODM mapping of UML to OWL. Therefore, we had to extend the mapping using SPARQL Update query [21] axioms. The SPARQL Update query axioms are based on the rules of class diagram abstraction studied in the thesis [22]. The following is a representation of the axioms in UML terms.

In this notation, A, B, and C represent classes, hollow arrows represent generalizations, lines represent bidirectional associations, regular arrows represent directed associations. Labels on the lines and arrows represent multiplicities. The left hand side of each axiom corresponds to the query’s WHERE clause—a conjunction of the triples for matching the representations of the corresponding class diagram elements in the diagram’s ontology. The right hand side of each axiom corresponds to the query’s INSERT clause—a conjunction of the triples specifying inferred and asserted object properties and property restrictions representing derived associations.

The objective function for the optimization is based on the following software metrics of the composed diagrams: 1) the number of classes (NC), 2) the number of associations (NA), 3) the number of inheritance hierarchies (NIH), 4) attribute inheritance factor (AIF)—this is the ratio of the number of inherited attributes to the total number of attributes in a diagram, 5) average number of ancestors (ANA), 6) the number of generalizations (NG). These metrics impact the design quality attributes studied in [23] that are related to the class diagram concepts supported by RBDC. Specifically, they impact the following design quality attributes: reusability, understandability, functionality, effectiveness, extendibity, and design simplicity. Following [23] [24] [25] and [26], an increase of the metric increases (↑) or decreases (↓) the quality attributes, as shown in Table 1.

Our problem is a Multi-Objective Optimization Problem (MOOP). Our implementation of the solution relies on the global criterion method described in [27] and is classified as a no-preference method. We considered six objective functions that measure specific design qualities. In the cases where more than one metric influences the quality attribute, the contributing metrics are added together using the same weights. This choice is totally arbitrary; however the designers who might want to use RBDC could set their own preferred weights.

1. Reusability: f 1 = 1 2 ( N C + A I F ) .

2. Understandability: f 2 = − 1 3 ( N C + A I F + A N A ) .

3. Functionality: f 3 = 1 2 ( N I H + N C ) .

4. Effectiveness: f 4 = A N A .

5. Extedibility: f 5 = A N A .

6. Simplicity: f 6 = − 1 4 ( N A + A I F + N I H + N G ) .

The MOOP objective function is f = [ f 1 , f 2 , f 3 , f 4 , f 5 , f 6 ] T . Since this was a minimization problem, the inverses of all the objective functions were minimized. The ideal point, z i d e a l , is obtained by finding the minimum value for each objective function separately: z i i d e a l = min ( f i ) . The best solution, x * , is defined as the one for which the Euclidean distance between f ( x * ) and z i d e a l is minimal:

d = min x ∑ i = 1 6 ( f i ( x ) − z i i d e a l ) 2 (4)

Since we did not find any large public datasets that could be used to evaluate RBDC experimentally, we developed algorithms for generation of constraints and class diagrams that include the constraints.

A concept map related to the generation of external constraints is shown in Figure 8. Types of external constraints are formalized as SPARQL query templates (Appendix A). The templates include concepts from an ontology, variables, and parameters. SPARQL ASK queries are instantiations of the templates.

The queries are verified against the ontological formalizations of class diagrams. The class diagrams are first mapped to ontology and then an inference engine is run. The inference is based on both OWL and ODM extension rules.

Class diagrams include UML representable constraints. RBDC supports the following types of constraints from [28] in accordance with supported class diagram concepts: 1) cardinality constraints on associations, with or without qualifiers, 2) class hierarchy constraints, and 3) cardinality constraints on attributes. For cardinality constraints on attributes, only cardinality of 1 was considered.

For the evaluation to be meaningful, it is necessary that the generated constraints cover a wide variety of constraints. Like in software testing, it is necessary to cover both the basic and the “corner cases”. The corner cases of multiplicities on association ends are shown in Table 2. The left column shows the generic patterns of constraints. The right column shows examples (instances) of the generic patterns.

There are 8 examples in the table. Since the cardinality constraints on associations are applied to both ends of an association, there are 8 × 8 = 64 corner cases of constraints on associations based on all pairs of multiplicity corner cases. Altogether, there are 68 corner cases of constraints, including generalization and attribute with multiplicity of 1.

Our data generation procedure randomly generates class diagrams that include both the base and the corner cases of the constraints. Also, for each generated diagram, D, the procedure generates all the queries (instances of the query templates) such that each query is entailed by O * ( D ) .

The procedure guarantees that 1) all query templates are covered by the generated class diagrams and 2) for each corner case constraint x, there is a class diagram D s.t. D includes x. The inference engine verifies whether O * ( D ) entails representation of x, i.e., whether O * ( D ) ⊢ O ( x ) .

The query templates are described in Appendix A. They are used to generate random sets of external constraints, expressed as queries, Q = { Q 1 , Q 2 , ⋯ , Q n } . The sets of the size up to 11 were used, which we believe is sufficient from the practical point of view. To ensure that only connected class diagrams can be generated using these sets of queries, it is necessary for the queries in Q to be interconnected using class names. The algorithm ensures that this requirement is satisfied.

The next step is to generate sets of class diagrams satisfying a given set of external constraints described above. For a given set of queries Q , the algorithm generates a set of diagrams D = { D 1 , D 2 , ⋯ , D n } , such that ∀ D i ∈ D   ∀ Q ∈ Q • O * ( D i ) ⊢ Q . The algorithm for generating diagrams in D ensures that all general OWL axioms and ODM extension rules from Section 4.7 are covered.

To show that RBDC is applicable to a wide variety of class diagrams, at least partially, the set of the diagrams used for testing was generated in such a way that each diagram had a different mixture of the number of classes, associations, generalizations and attributes. First, 600,000 sets of 7 queries each were randomly generated from the templates, and then a pair of diagrams were generated for each set. The numbers of UML elements in the generated “quantitative mixture” sets of diagrams have the following maximum values: classes: 22; associations: 9; generalizations: 9, attributes: 6.

Figure 9 shows the distribution of the number of different quantitative mixtures of diagrams vs. the total number of generated diagrams. The maximum number of quantitatively different mixtures was 741. The saturation of the curve indicates that generation of more diagrams does not contribute much to the increase of the quantitative variety of the mixtures.

The experiments were conducted on a cluster [29] with node speeds ranging from 1.8 to 2.8 GHz.

We conducted performance evaluation experiments of optimized diagram composition with different sizes of random sets of queries. We had 643 experiments for random query sets of size 7, where pairs of diagrams cover all quantitative mixtures from Section 5.1. Also, we had 600 experiments for random sets of 5, 9 and 11 queries (200 experiments for each set size). During the process of finding subdiagrams, associations were partitioned on blocks of 12 with or without remainder. Properties of random diagrams generated for different sizes of random sets of queries are shown in Table 3. For each set of experiments with a given size of a random set of queries, we calculated the arithmetic mean and standard deviation of execution time. This is shown in Figure 11.

We obtained a reasonable average execution time for experiments for random

sets of 11 queries (generated random diagrams had up to 33 classes, up to 13 associations, up to 13 generalizations and up to 10 attributes). According to standard deviation result for these experiments, the execution time in the majority of cases is also reasonable. In order to handle larger diagrams it is necessary to partition associations on larger blocks of equal size with or without remainder while finding subdiagrams.

Since we did not find any public datasets that could be used to perform a comparison of RBDC with existing methods of merging/composing class models, therefore we developed a set of characteristics of the existing methods, as described below, and used them for comparisons. The values of the characteristics are defined as 1—supported, 0—not supported, and in some cases 0.5—partially supported. Partially supported means the characteristics are either maintained manually or automatically detected but resolved manually.

· Preservation of the structure of diagrams in the composed diagram.

· Avoidance of redundant attributes.

· Avoidance of cycles in inheritance.

· Avoidance of redundant inheritance.

· Avoidance of redundant associations.

· Formally proven compliance with meta model.

· Inference of indirect relations.

· Support of optimization.

· External constraints satisfaction.

Table 4 shows a comparison of RBDC with other existing methods in terms of these characteristics. The algebraic merge operator [33] is the most competitive with respect to RBDC. The advantages of RDBC are the following. 1) It supports automatic checking of external constraints satisfaction by the composed diagram. 2) The mapping between elements of the source models is created automatically, while in the algebraic merge operator it is created manually. 3) It covers more class diagram concepts. 4) It supports inference of indirect relations in the composed diagram.