A number of techniques and tools for differencing and merging C&C views have been ... leading to the loss of information when elements are moved or renamed. ...... 25. 121. 402. 232% 0.484. 125. 3%. 16.735. 34. 125. 3%. 15.843. 32. 320.
Differencing and Merging of Architectural Views Marwan Abi-Antoun Jonathan Aldrich Nagi Nahas Bradley Schmerl David Garlan August 2005 CMU-ISRI-05-128R This corrects an earlier technical report CMU-ISRI-05-128
Institute for Software Research International School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213-3890
Abstract As architecture-based techniques become more widely adopted, software architects face the problem of reconciling different versions of architectural models. However, existing approaches to differencing and merging architectural views are based on restrictive assumptions, such as requiring view elements to have unique identifiers or explicitly log changes between versions. To overcome some of the above limitations, we propose differencing and merging architectural views based on structural information. To that effect, we generalize a published polynomial-time tree-to-tree correction algorithm (that detects inserts, renames and deletes) into a novel algorithm to additionally detect restricted moves and support forcing and preventing matches between view elements. We implement a set of tools to compare and merge component-and-connector (C&C) architectural views, incorporating the algorithm. Finally, we provide an empirical evaluation of the algorithm and the tools on case studies with real software, illustrating the practicality of the approach to find and reconcile interesting divergences between architectural views.
This work was supported in part by NASA cooperative agreements NCC-2-1298 and NNA05CS30A, NSF grant CCR0204047, a 2004 IBM Eclipse Innovation Grant, the Army Research Office grant number DAAD19-02-1-0389 entitled “Perpetually Available and Secure Information Systems”, and was performed as a joint research project in Strategic Partnership between Carnegie Mellon University and Jet Propulsion Laboratory.
Keywords: View differencing, view merging, view synchronization, tree-to-tree correction, unordered labeled trees.
2
1. INTRODUCTION The software architecture of a system defines its high-level organization as a collection of runtime components, connectors and constraints on their interaction, along with their additional properties defining the expected behavior, commonly referred to as a component-and-connector (C&C) view. Over the past decade, numerous architecture description languages (ADLs) have been developed and applied to real-world systems. As architecture-based techniques become more widely adopted, software architects face the problem of reconciling different versions of architectural models, including differencing and sometimes merging architectural views— i.e., using the difference information from two versions to produce a new version that includes changes from both earlier versions. For instance, during analysis, a software architect may want to reconcile two C&C views representing two variants in a product line architecture [CCG+03]. Once the system is implemented, an architect may want to compare a high-level conceptual C&C view with a C&C view retrieved from the implementation (using a variety of architectural recovery techniques): the architect might be interested in implementation-level violations of the architectural styles or other intent [AAG05], or in a change impact analysis [KPS+99]. At runtime, the difference information could be used to perform architectural repair [DHT02]. Finally, during evolution, the architect may use the difference information to better focus regression testing efforts [MDR05]. A number of techniques and tools for differencing and merging C&C views have been proposed. Some of these techniques detect only a small number of differences. For instance, ArchDiff [CCG+03] only detects insertions and deletions, possibly leading to the loss of information when elements are moved or renamed. Many of these techniques are also limited in their ability to detect differences based purely on structural information; they assume that elements have unique identifiers (every time an element is changed, even when only its type changes, it gets a new unique identifier [AP03][OWK03]), or only match two elements if both their labels and their types match [CCG+03]. Other approaches (e.g., Mae [RHM+04]) rely on the environment tracking all changes using fine-grained element-level versioning. Although such environments may provide the ability to infer high-level operations such as merges, splits or clones, in addition to the low-level operations such as inserts and deletes, they require a heavy upfront investment in tool building and integration, and have not become widely adopted. Similarly, one can maintain a record of the structural changes introduced to a view and replay it against another view [Jim05]. In this paper, we propose an approach that overcomes some of the above limitations. Our main contributions are: •
An approach for differencing and merging two architectural views based on structural information, using tree-to-tree correction algorithms to identify matches and classify the changes between the two views. Optional type information can prevent matches between incompatible view elements, speeding execution and improving the quality of the output.
•
A generalization of a recently published tree-to-tree correction algorithm for unordered labeled trees [THP05] (that detects renames, inserts and deletes) into a novel polynomial-time tree-to-tree correction algorithm that additionally detects restricted moves and supports forcing and preventing matches between view elements.
•
A set of tools incorporating such algorithms for the semi-automated synchronization of C&C views.
•
An empirical evaluation of the algorithms and the associated tools on realistic case studies.
The paper is organized as follows. Section 2 describes the challenges in differencing and merging structural views, the underlying assumptions and the limitations of our approach. Section 3 describes our novel tree-to-tree correction algorithm. Section 4 describes tools that incorporate tree-to-tree correction algorithms to synchronize C&C views. Sections 5 and 6 present two case studies on real systems. Finally, we discuss related work and conclude.
2. CHALLENGES A view can generally be described as a graph. View differencing and merging can then be cast as a problem in graph matching. Hierarchical architectural views have aspects of both graphs and trees—i.e., they have a tree-like hierarchy but there are cross-links that form a general graph. In this section, we consider the benefits of both graph and tree differencing
3
approaches, with graph algorithms being more general, but tree algorithms more scalable. Having chosen trees for scalability, we describe a new algorithm in the next section that meets our requirements. 2.1 Differencing and Merging Graph matching, in the general case, is NP-complete [CFS+04]. However, certain classes of graphs do not suffer from the exponential complexity. For instance, graphs characterized by the existence of unique node labels can be processed efficiently [DBB+04]. In addition, efficient algorithms have been proposed for trees. A widely used measure of the similarity between two graphs is the notion of graph edit distance [CFS+04]. The approach relies on using a set of edit operations that model inconsistencies by transforming one graph into another. Typical graph edit operations include the deletion, insertion and substitution of nodes and edges. Often a cost is assigned to each edit operation. The costs are application dependent and used to model the likelihood of the corresponding inconsistencies (typically, the more likely a certain inconsistency is to occur, the lower is its cost). If a cost is assigned to each edit operation, then the edit distance of two graphs g1 and g2 is found by searching for the sequence of edit operations with the minimum cost that transform g1 into g2. A similar problem formulation can be used for trees; however, tree edit distance differs from graph edit distance in that operations are carried out only on nodes and never directly on edges. In Section 3, we describe a novel algorithm based on tree edit distance that meets the requirements of the problem domain. 2.2 Assumptions Before we do that, we discuss some of the assumptions in our approach and how they generalize those of existing approaches. No Unique Identifiers. For maximum generality, we match elements based on their structure and do not require elements to have unique identifiers, as in ArchDiff. In many applications, such unique identifiers do not exist. Adding this assumption gives the problem of graph edit distance a polynomial-time complexity, as recently shown in [DBB+04]. As an optimization, persistent unique identifiers could be assigned to view elements to quickly match them between invocations. No Ordering. In the general case, an architectural view has no inherent ordering among its elements. Assuming an architectural view is represented as a tree, this suggests that an unordered tree-to-tree correction algorithm might perform better than one for ordered trees. Ordered labeled trees (i.e., rooted trees in which the children of each node are ordered) have been studied extensively with many efficient algorithms available (e.g., [SZ97]). However, tree-to-tree correction for unordered trees is MAX SNP-hard [ZJ94]. Some algorithms for unordered trees achieve polynomial-time complexity, either through heuristic methods (e.g., [WDC03][CG97]) or through an exact solution under additional assumptions (e.g., [THP05]). Support Disconnected/Stateless Operation. For maximum generality, we assume a disconnected and stateless operation, i.e., no monitoring of structural changes is taking place while the user is modifying a given view (e.g., Mae [RHM+04]) and no trace is kept of the set of changes made to a view (e.g., [Jim05]). Detect Renames. For maximum generality, we do not require labels to match exactly. Names are often modified during software development and maintenance: a name may turn out to be inappropriate or misleading due to either careless initial choice or name conflicts from separately developed sub-systems [AC94]. In some application domains, some view elements may not have persistent names or may be assigned automatically generated names. This suggests that the algorithms should be able to handle sparse or incomplete labels and handle renames. A number of existing algorithms detect renames, but either assume that a strong majority of nodes will have exactly matching semantic information (labels and types) or have only been tested under such a condition: e.g., at least 80% of nodes have exactly matching semantic information in [CG97], and at least 99% of nodes have exactly matching semantic information in [RRL+04]. Detect Hierarchical Moves. Architects often use hierarchy to control complexity, and many views are hierarchical: e.g., in C&C views, the hierarchy corresponds to the system’s decomposition. However, architects differ in their use of hierarchy: components expressed at the top level in one view could be nested within another component in some other view. A hierarchical move shifts a node up or down N levels in the tree, changing its parent. The ability to detect hierarchical moves is one of the main features which distinguish our proposed algorithm from the algorithm described in [THP05].
4
Allow Manual Overrides. Since having a correct mapping between view elements is critical for the merge operation, user control over the structural matching process is important: in particular, the user should be able to force a match between elements that cannot be structurally matched, as well as prevent matches between elements that, although structurally similar, are in fact incompatible. Note that manual overrides must be taken into account by the algorithm itself, and cannot happen as a post-processing step since there are dependencies in the mapping (e.g., two view elements a1 and a2 in View A may not both map to the same element b1 in view B, even if a1 is forced to match b1). This feature also distinguishes our algorithm from existing ones. Type Information for Optimization Only. Unlike other approaches (e.g., ArchDiff), matching the type information is not critical to the operation of the algorithm; it should be able to deal with views containing untyped elements, as well as views at different levels of abstraction with possibly different type systems. The algorithm should be able to recover a correct mapping from structure alone if necessary, or structure and type information if type information is available. However, the algorithm can take advantage of the type information (when available) to prune the search tree, significantly speed convergence towards the optimal solution and improve the quality of the matching. If the view elements are represented as typed nodes, at the very least, the algorithm should not match nodes of incompatible types (e.g., do not match connector x to component y). In some cases, additional architectural type information may be available and could be used for similar purposes (e.g., do not match a component of type Filter from a Pipe-and-Filter style to a component representing a Repository from a Shared Data style). In order to remain tractable, our approach makes the following restricting assumptions: Hierarchical Views. In the general case, the differencing and merging of non-hierarchical views corresponds to errorcorrecting or inexact subgraph isomorphism [CFS+04], a problem proved to be NP Complete. The most ambitious optimal algorithms (i.e., if a global minimum of the matching cost exists, it will be found) can handle at most a few dozen nodes. We take advantage of the tree hierarchy in architectural views and recast the problem into one that is more tractable, using trees instead of graphs. In C&C views, hierarchy corresponds to nested sub-architectures or decomposition. Other architectural views, such as module views [CBB+03], have similar characteristics. Similar and Comparable Views. The two views being compared and merged have to be somewhat structurally similar. When comparing two completely different views, the algorithm could produce a trivial edit script that deletes all elements of one view and then inserts all the elements in the other view. In addition, the two views being compared and merged must be of the same type, i.e., comparable without any view transformation. This also allows the approach to be more applicable than just C&C views, at least in principle. Merging/Splitting Not Supported. Our approach does not currently detect the merging or splitting of view elements.
3. TREE-TO-TREE CORRECTION In this section, we describe in detail a novel tree-to-tree correction algorithm for unordered labeled trees. The reader only interested in its applications can skim this section. Our TreeMDIR (Tree Move-Delete-Insert-Rename) algorithm generalizes a recently published algorithm [THP05], denoted as THP. We also implemented THP for experimental comparison with our implementation of TreeMDIR. 3.1 Problem Definition Let us first give an unambiguous definition of the problem, adapted from [SZ97]. We denote the ith node of a labeled tree T in the postorder node ordering of T by T[i]. |T| denotes the number of elements of T. We define a triple ( , T1, T2) to be a mapping from T1 to T2, where is any set of pairs of integers (i,j) satisfying: 1) 1
