1 Supporting the Reconciliation of Models of Object Behaviour 1 GEORGE SPANOUDAKIS AND HYOSEOB KIM 2 Department of Computing, City University, Northampton Square, London EC1V 0HB, UK E–mail: gespan@soi.city.ac.uk 1 This article is an extended version of the article "Reconciliation of Object Interaction Models" that appeared in the proceedings of the 7 th International Conference on Object Oriented Information Systems. 2 This article reports on research that was carried out while the second author was affiliated with the Department of Computing of City University. Abstract: This paper presents Reconciliation+, a method which identifies overlaps between models of software systems behaviour expressed as UML object interaction diagrams (i.e., sequence and/or collaboration diagrams), checks whether the overlapping elements of these models satisfy specific consistency rules and, in cases where they violate these rules, guides software designers in handling the detected inconsistencies. The method detects overlaps between object interaction diagrams by using a probabilistic message matching algorithm that has been developed for this purpose. The guidance to software designers on when to check for inconsistencies and how to deal with them is delivered by enacting a built-in process model that specifies the consistency rules that can be checked against overlapping models and different ways of handling violations of these rules. Reconciliation+ is supported by a toolkit. It has also been evaluated in a case study. This case study has produced positive results which are discussed in the paper. Keywords: consistency management, software design models, object interaction diagrams 1 Introduction The specification of software system behaviour using multiple object interaction diagrams (i.e., sequence and/or collaboration diagrams) creates the potential of conflicting specifications of messages, objects and operations in these models. This is because different object interaction diagrams may, by virtue of the exchanges of messages that they specify and other elements in the specifications of these messages, imply different behaviours for the same objects and operations. Consider, for example, an object model for a library system that includes the object interaction diagrams I 1 and I 2 of Figure 1 and the class diagram of Figure 2. The diagrams I 1 and I 2 specify interactions, which occur when the library system is used to search for items in the library either by keywords which refer to the author of an item (I 1 ) or by keywords which refer to the title of an item (I 2 ). The class diagram of Figure