Mergig graph-like object structures Albert Züdorf Techical Uiversity of Brauschweig Istitute for Software Gaussstr. 11 38023 Brauschweig Germay zuedorf@ips.cs.tu-bs.de Keywords Versio Maagemet, Object Orietatio, Delta Computatio, Optimistic Lockig, Merge Algorithms, Log Trasactios 1 INTRODUCTION This paper addresses the problem of coordiatig a team of software developers cocurretly workig o a commo software system. The stadard approach to coordiate cocurret activities o a commo set of data is lockig. Ay part of data used by oe perso is locked agaist cocurret use by aother perso. The secod perso has to wait util the first perso has fiished his or her task ad releases the lock. I databases, sophisticated lockig ad trasactio cocepts miimize the waitig times for cocurret users by offerig differet lock graularities ad differet lockig levels (e.g. multiple read locks vs. sigle write locks). However, these lockig strategies assume that locks are hold for relatively short times (some secods), oly. I software developmet, versio cotrol systems like RCS [Tic85] or SCCS [Roc75] employig a pessimistic lockig cocept o a per file, per class, or per method basis are used. However, chages to source code may require some days or weeks. We call such chages log-trasactios. Such log trasactios lock certai source code parts for a log time. For example, oe perso may wat to do a bug fix i a file which is locked by a secod perso. The first perso may have to wait several days util he or she ca proceed or he or she may egotiate with the lock ower. This requires extra efforts. I large developmet teams these extra coordiatio efforts may become a severe productivity problem. To overcome these problems, optimistic lockig cocepts have prove very successful for software developmet i larger teams. CVS [Ced93, CVS] is a well kow cofiguratio ad versio maagemet system that supports optimistic lockig. Optimistic lockig cocepts allow multiple persos to chage the same file, class, or method, cocurretly. The maagemet system just keeps track, which perso works o which versio of a give piece of software. Whe a cocurret chage to the same piece of software happes, the maagemet system computes a delta Jörg P. Wadsack, Igo Rockel Departmet of Mathematics ad Computer Sciece Uiversity of Paderbor Warburger Str. 100 33098 Paderbor Germay [maroc iro]@ui-paderbor.de comprisig the chages of oe perso ad this delta is the applied to the versio of the other perso. If the chages do ot actually coflict, the differet versios are combied, automatically. I case of actual coflicts, maual itervetios become ecessary. Based o our experieces with a fairly big software project, the Fujaba (From UML to Java Ad Back Agai) project, ad a umber of idustrial projects, actual coflicts occur seldom (1 out of 1000 chages to a file withi a 380 000 LOC project with about 500 classes ad a team of about 15 developers results i a merge coflict). Thus, optimistic lockig ad mergig mechaisms seem to provide a solutio to the log trasactio problem. I large projects, a software system may ot oly cosist of source code but also of various other documets like class diagrams, use case diagrams, project plas, ad other desig documets. Most of these desig documets are stored i special biary formats. Ufortuately, most versio maagemet systems work with text files, oly. They are based o diff ad patch mechaisms that compute chages betwee two text files ad that are able to apply such chages to a differet versio of that file, if that versio has ot chaged too much. Thus, optimistic lockig is usually ot supported for desig documets. As desig documets become larger ad more importat, this becomes a severe problem for large projects. Cosequetly, it is absolutely critical to have also object structure based delta ad mergig mechaism to support optimistic lockig cocepts for desig documets. We will first discuss a mergig mechaism for object structures. This mergig mechaism baks o a textual represetatio of the object structure. This do ot solve all emergig problems thus, secod we will outlie our advaced mechaism workig o graph like object structures. 2 TEXTUAL REPRESENTATION BASED OBJECT STRUCTURE MERGING A basic requiremet for a textual persistece mechaism that shall serve as a basis for a mergig mechaism is that readig a textual descriptio ad dumpig it agai without ay modificatios should result i exactly the same text. If the text differs, the textual mergig mechaism will create textual deltas although o modificatio has happeed. This creates a high likelihood that uecessary merge coflicts are created. Naive implemetatio of a textual persistece cocept may chage the textual represetatio of a object structure e.g.
due to differet visitig sequeces of the cotaied objects. Let us for example assume, that a object stores a set of refereces to eighbors withi a hash table or tree based cotaier that uses the address or hash code of the stored object as access key. Typically, the readig mechaism of a textual persistece cocept has o or little ifluece o the address or hash code of re-created objects. Thus, the addresses or hash codes of re-created objects may differ from the addresses or hash codes that have bee used durig storig the object structure. Accordigly, the order i which a re-created cotaier retrieves the same set of object differs from the origial order used to store the objects the first time. If the order of the objects chages i the textual represetatio of the object structure dramatically, the textual mergig mechaism is screwed. Similarly, the chage of object idetities (ids) durig the recreatio of a object structure from its textual represetatio creates a problem for the uchaged represetatio of refereces to eighbors. If this represetatio is based o the object id provided by the rutime system, all object ids may have chaged o dumpig the object structure, agai. This screws the textual mergig mechaism, too. To solve these problems, the textual cosistecy cocept should employ its ow persistet object ids that must ot chage o multiple dumps ad readigs of a object structure. I additio, these persistet object ids should be used as sortig ad hashig criterias for cotaiers storig sets of refereces to eighbor objects i order to achieve a stable visitig order durig the textual dumpig. However, usig persistet object ids may ot suffice to guaratee a certai visitig order for cotaiers of refereces. Hash based cotaiers may reorgaize themselves o the isertio or deletio of objects. Thus, isertig oe ew object to such a cotaier may chage the textual represetatio of the whole object structure, dramatically. This may be avoided by sortig the object based o their persistet keys durig the dumpig process. Aother group of problems is related to idepedet additios of objects to a object structure by differet users. Usually, we would expect that the mergig mechaism should merge these idepedet chages without problems. However, aive text dump mechaisms ted to apped ew objects at the ed of the object structure. This may for example happe if persistet object ids are created i cosecutive order ad if these ids are used as sortig criterias for the textual dump. If this happes, cocurretly created ew objects will both be iserted at the ed of the correspodig text dump. Thus, a text based mergig mechaism will have a merge-coflict due to cocurret chages at the same text positio, although the chages do ot actually iterfere. Similarly, a severe problem is created if differet users create differet objects cocurretly ad if these objects get the same persistet object ids, by accidet. If the textual represetatio of these differet objects are placed at differet positios i the dumped text, the mergig algorithm may merge these chages without ay problems. However, this may create a textual represetatio that uses the same persistet object id, twice. This creates severe problems for the re-creatio of the object structure. To solve these problems, separated ame spaces for persistet object ids created i cocurret sessios should be employed. A simple way to achieve this is to employ a uique sessio id which is used as a basis (prefix) for the persistet object ids created i that sessio. If oe user has at most oe sessio at a time, we could use permaet user ids as ame space prefixes. This would also address the problem of fidig idepedet isertio positios for ew objects. If we preped the user id to the persistet object id ad if we use lexical order based o the persistet object id, each user id gets its ow isertio compartmet. Objects created by differet users (i differet sessios) would be iserted ito the text dump at differet positios, thus avoidig uecessary textual merge coflicts. However, they still have to take care that cocurretly created ew user compartmets are iserted at differet text positios. Dumpig ad readig the object structure Due to the discussio above, built-i serializatio mechaisms provided by moder programmig laguages are usually ot appropriate as a basis for textual mergig mechaisms. Thus, a ew textual persistece mechaism has to be build. A stadard way to implemet such a textual persistecy cocept is to employ a base class that provides appropriate read ad write methods for all attributes of that class. All classes that shall become persistet iherit from this base class ad exted the read ad write methods i order to cover the attributes itroduced i that class. The persistet base class should itroduce a attribute for the persistet object id of the objects ad perhaps static attributes to store the sessio id ad a couter used to create ew uique persistet object ids. Dumpig a object structure just starts with a root object. Referece attributes are dumped usig the persistet object id of the target object ad later o the target object is visited recursively. Some kid of marker or a object table may be used to avoid multiple dumps of a sigle object. The read procedure eeds the type of the persistet objects i order to create ew istaces of the correct class. The, the read method is used to restore the attribute values. I case of referece attributes, a look-up table is employed to tur the persistet object id ito a referece to the correspodig object. Due to our experieces the read/write method approach creates serious maiteace problems. Each time a ew attribute is iserted ito a persistet class, it has be exteded to the correspodig read ad write methods, accordigly. This is easily forgotte. Aother problem are library classes like Color or Poit. It is ot allowed to modify such library classes i order to make them persistet. I Java, the additioal problem that multiple iheritace is restricted to iterface classes is faced. Thus the iheritace of persistecy properties may become complicate. We overcome these problems by usig a geeric, table drive persistecy mechaism. Implemetig i Java allows us to exploit Java rutime type iformatio to ispect istaces of persistet classes ad to store ad recover their attributes.
The classes are marked as persistet either by iheritig from a certai base class or by addig it to a persistet class table. The latter mechaism allows to cover library classes, too. To exclude certai attributes from the persistecy mechaism, the Java keyword trasiet may be used. Similar iformatio may be provided by the persistecy table. This geeric persistecy mechaism is easily adapted for ew programs. I additio, the mechaism solves the maiteace problem caused by the itroductio of ew attributes. Remaiig merge coflict problems The persistecy ad mergig mechaism described so far works already fie for may situatios. However, some priciple problems remai. Cosider for example a cutout of the abstract sytax graph of a UML CASE tool. The base versio may just cosist of a a empty class diagram. User maroc may ow eter a class Customer ad user zuedorf a class Car. These idepedet chages should ot create a merge coflict. If we have prepared differet text compartmets for differet users, the additio of the ew UMLClass objects to the text dump will ot create a problem. However, i our meta model the class diagram holds a set of refereces to all cotaied classes i its attribute items, cf. Figure 1. The additio of a UMLDiagram items classes Figure 1 UML meta model (cut out) UMLClass class to a class diagram adds a referece to the items attribute, too. Thus, after the additio of oe class to the class diagram, the textual dump of the class diagram object will cotai oe lie for the items attribute describig the referece to the added class. Ufortuately, for both users this lie is added at exactly the same positio i the text dump, cf. lies 3 to 5 i Figure 2. Thus, a textual mergig mechaism will report a merge-coflict, which actually does ot exist. 1) /* text dump from user maroc */ 2)... // i class UMLDiagram 3) <attribute> <id>2.3</id> <type>attr</type> 4) <ame>items</ame> <value>customer</value> 5) </attribute>... 1) /* text dump from user zuedorf */ 2)... // i class UMLDiagram 3) <attribute> <id>1.3</id> <type>attr</type> 4) <ame>items</ame> <value>car</value> 5) </attribute> Figure 2 Positio coflict Let us ow assume, that we are able to overcome this problem by some reorgaizatio of the text dump. Thus, user zuedorf ad user maroc may have successfully merged their two classes Car ad Customer. They both take this commo versio ad cocurretly add a class Cotract. If we are able to work aroud the isertio problem to the items attribute of the UMLDiagram object, a textual mergig mechaism would probably merge these cocurret chages without ay problems. However, this would create the problem that the merged class diagram cotais two idepedetly created classes with the same ame. I Figure 3 the merged class diagram is show as (XML-) text dump, i lies 5-7 ad 11-13 a class Cotract is declared. I our meta model (cf. Figure 1), class UMLDiagram employs a qualified associatio items to hold the cotaied classes. The correspodig cardiality costrait guaratees uique qualifiers. This meas, our data model does ot allow to store two classes with the same ame withi oe class diagram. Thus, i our example the reader would have a problem to restore a object structure where a successful textual merge has added two classes with the same ame. This is show i Figure 4 for classes Cotract. 1)... // i class UMLDiagram 2) <attribute> <id>2.3</id> <type>attr</type> 3) <ame>items</ame> <value>customer</value> 4) </attribute> 5) <attribute> <id>2.14</id> <type>attr</type> 6) <ame>items</ame> <value>cotract</value> 7) </attribute> 8) <attribute> <id>1.3</id> <type>attr</type> 9) <ame>items</ame> <value>car</value> 10) </attribute> 11) <attribute> <id>1.16</id> <type>attr</type> 12) <ame>items</ame> <value>cotract</value> 13) </attribute> Figure 3 Merged class diagram Customer Car To summarize, a text based mergig mechaism has o kowledge about the sematic costraits itroduced by the meta model of our object structure. Thus, the textual mergig mechaisms is ot able to deal with a umber of merge problems related to such costraits. Cosequetly, we have developed a object structure based mergig mechaism, described i the ext chapter. 3 OBJECT STRUCTURE BASED MERGING Our object structure based mergig mechaism is based o a simple meta model providig objects, labeled liks, ad Object id: strig type: strig ame: strig value: strig liks sigs belogs_to attributes, cf. Figure 5. The elemetary chage operatios of this meta model are create / delete a object create / delete a lik chage a attribute value Cotract Cotract Figure 4 Namig coflict attrs Figure 5 Text dumpig meta model Lik id: strig type: strig ame: strig label: strig Attributes amig coflict id: strig type: strig ame: strig value: strig
algorithm delta(a, B) 1) iput A,B : set of object structures 2) output D : delta of the object structures 3) local variables OA, OB, ON, OD: object 4) local variables LA, LB, LN, LD: lik 5) begi 6) for all (OA,OB) = pairwithsameid (A,B) 7) if OA.attrs OB.attrs 8) the D.addChageAttributeEtries (OA,OB) 9) fi 10) for all LB = (OB.lik - OA.lik) 11) D.addCreateLikEtry(LB) 12) for all LA = (OA.lik - OB.lik) 13) D.addRemoveLikEtry (LA) 14) for all ON = (B - A) 15) D.addCreateObjectEtry (ON) 16) D.addChageAttributeEtry (ON.attrs) 17) for all LN = (ON.lik) 18) D.addCreateLikEtry (LN) 19) for all OD = (A - B) 20) D.addDeleteObjectEtry (OD) 21) D.addChageAttributeEtry (OD.attrs) 22) for all LD = (OD.lik) 23) D.addRemoveLikEtry (LD) 24) ed Figure 6 The delta algorithm Computig Object Structure Deltas We first describe a algorithm computig a delta betwee two object structures i terms of these elemetary chage operatios, cf. algorithm delta i Figure 6. The delta algorithm employs two sets of kow objects for object structures A (old) ad B (ew) that are to be compared. Our algorithm iterates through the sets of kow objects of the two object structures ad retrieves pairs of objects with the same persistet object ids. For each such pair of objects OA ad OB we compare the set of basic attributes, cf. lie 7. If the attribute values differ we add a appropriate chageattribute (lie 8) etry to the computed delta. The we cosider all liks attached to the objects (lies 10 to 13). Two liks with the same label are cosidered equal if they target objects with the same persistet object id. If object OB has a lik with label L targetig ad object OX ad OA does ot have such a lik, the a appropriate createlik etry is added to the delta (lie 18). If a lik is removed we add a removelik etry to the delta (lie 13). Oce all pairs of objects with the same persistet object id have bee cosidered, our algorithm cosiders the remaiig objects (lie 14 to 18). Each object ON existig i object structure B but ot i object structure A has bee added to object structure B. Thus we create correspodig createobject ad chageattribute etries to the delta (lies 15 & 16). I additio, we add all liks attached to ON to our delta (lies 17 to 18). Objects cotaied i object structure A but ot i object structure B have bee removed i object structure B. For such objects OD we add deleteobject etries to the delta. I our approach we add chageattribute etries for deleted objects to the delta, too (lies 20 & 21). Although, this iformatio may ot be ecessary for the merge process, it allows to use the delta as a reverse delta, if required. This meas, the delta ca be used to recostruct object structure A from its successor object structure B. Accordigly, we add deleted liks attached to deleted objects to the delta (lie 22 & 23). zv deltabz bv deltabm mv apply deltabm cv Figure 7 Computig commo versio by applyig deltabm to zv 3-Way Mergig / Applyig a Object Structure Delta Let us assume, we have a base versio bv of a object structure ad users zuedorf ad maroc create two successor versios zv ad mv, cocurretly. We would ow like to merge these chages ito a commo versio cv, cf. Figure 7. Basically, the commo versio cv may be computed by applyig deltabm to versio zv. A delta is applied to a object structure by just executig the correspodig create/delete object, create/delete lik, ad chage attribute etries of the delta. Agai we eed a lookup table to tur persistet object ids from the delta ito refereces to actual objects. We use sessio or user id prefixes to the persistet object ids i order to avoid cocurretly created objects with equal persistet ids as described for textual mergig mechaisms. If o coflicts occur, this algorithm works straight forward ad creates a object structure cv that cotais the chages of both users. Most of the problems discussed for textual merge mechaisms do ot occur. For example addig a class created by user maroc to the class diagram does ot create a merge coflict, sice the items set has o dedicated isertio positio where a coflict could occur. However, there are still coflicts possible. Coflicts o object structure based mergig The simplest coflict occurs if both users have modified the same basic attribute, e.g. both users chage the ame of a existig class i differet ways. Similarly, createlik operatios may coflict if the correspodig associatio has cardiality to-oe. It may eve be cosidered as a coflict if oe user deletes a to-oe lik ad aother user replaces that lik by a lik to aother target. I additio, oe user may have deleted a object while the other user chages a attribute of that object or adds a lik to that object. A object structure based mergig mechaism must detect such situatios ad deal with them, somehow. A simple approach is to always prioritize the chages of oe of the users. Aother idea is to compute a kid of merged result. For strig based attributes oe could just cocateate the coflictig ames. I our CASE tool example this would result i a class with a cocateated ame. The user could idetify this problem withi the CASE tool ad resolve the coflict maually. Geerally, this is a very dagerous approach. Probably, a special table of attributes that shall be hadled this way should be used. However, coflicts related to to-oe liks ad coflicts related to deleted ad cocurretly modified objects ca ot be solved this way. I geeral, such merge coflicts require a user decisio. Ufortuately, our object structure based mergig mechaism may report merge coflicts o a object structure
level, oly. The user of a CASE tool may have some difficulties to resolve a coflict sayig coflictig assigmets to attribute age of object 2.33 of type XYZ. The user would probably like to deal with such coflicts via the GUI of his or her CASE tool. 4 CONCLUSIONS AND FUTURE WORK There have bee a umber of approaches tryig to improve merge mechaisms for software documets, [Wes91b, YHR92, LvO92, BHR95]. Most of these approaches tried to exploit higher level sematic kowledge i order to deal with merge coflicts more sophisticatedly. Like our approach, may of these approaches create a object structure based represetatio of the software documets i order to aalyse the chages more thoroughly. Our approach has bee heavily iflueced by the work of [Wes91a]. [Wes91a] itroduced the idea of uique persistet object ids as a basis for object structure based mergig. Somehow, we follow the idea of operatio based mergig of [LvO92]. However, [LvO92] requires the recordig of chage operatios while we employ a delta algorithm. We assume that explicit operatio recordig is hard to implemet. We thik that our approach improves the object structure mergig problem by itroducig a very geeric cocept that will be easily adapted to ew object structures ad tools. We pla to develop tool support, that allows to reverse egieer existig object structures ad to geerate a merge mechaism for such structures. We pla to deal with the merge coflict problem usig a table drive approach. A cofigurable coflict resolutio table shall allow to defie differet coflict hadlig strategies for differet kids of coflicts o differet types of objects, liks, ad attributes. Oe coflict hadlig method could be to add appropriate coflict marker objects to the object structure. The, the CASE tool could be exteded by a dialog presetig the merge coflicts i a appropriate way ad allowig the user to eter merge decisios o a logical level. I this way, a geeric merge mechaism may be itegrated with differet tools. We have implemeted the object structure based mergig mechaism i our Fujaba CASE tool. This implemetatio was ot as simple as described. First of all, our approach assumes a graph-like object structure. This meas, it must be possible to delete some object ad to determie all other objects referecig to this object ad to reset all these obsolete refereces i order to avoid daglig refereces. I our implemetatio, all refereces are implemeted as pairs of forward/backward poiters. This allows to determie all eighbors of a deleted object, easily. Secod, we assume that each object has a uique persistet umber eve across sessio boudaries. Especially, this does ot allow to compare idepedetly created object structures. Basically, this idea stems from [Wes91b] Third, we assume that some addig or deletig of objects or liks ad some attribute modificatios tur a valid object structure ito aother valid object structure. Theoretically, this holds, sice the resultig object structure respects all costraits imposed by the correspodig meta model. For example, o coordiately costraits of associatios are violated. However, usually tools impose other hidde cosistecy costraits o object structures. For example a explicit attribute, coutig the umber of existig classes may be employed. Addig ad removig class objects should chage this couter, too. This is ot kow to our merge mechaism. Due to our experieces, tools that are able to read a text based represetatio of their object structure are usually well prepared to deal with object structures that ca be represeted by such a textual descriptio. Thus, we pla to apply our mechaism to XML based object structure represetatios. We have miimized such costraits i our Fujaba eviromet. We have bee successful for class diagrams, but there are still some problems with some behavior diagrams. Similarly, we have a prelimiary versio of a merge dialog, oly. We would like to apply this approach to other tools that have a log trasactios problem, i order to validate its feasibility ad its geericity. For the Fujaba eviromet see http://www.ui-paderbor.de/cs/fujaba/ REFERENCES [BHR95] D. Bikley, S. Horwitz, ad T. Reps. Program itegratio for laguages with procedure calls. ACM Trasactios o Software Egieerig ad Methodology, 4(1):3 35, Jauary 1995. [Ced93] P. Cederqvist. CVS Maual: Versio Maagemet with CVS. Sigum Support, 1993. [CVS] CVS. Cocurret Versios System - The ope stadard for versio cotrol. http://www.cvshome.org/. [LvO92] E. Lippe ad N. va Oosterom. Operatio-based Mergig. I Proc. of the 5th Symposium o Software Developmet Eviromets (SDE5), volume 17(5), pages 78 87, Tyso s Corer, Virgiia, December 1992. ACM SIGSOFT Software Egieerig Notes. [Roc75] M.J. Rochkid. The source code cotrol system. IEEE Trasactios o Software Egieerig, 1(4):364 370, 1975. [Tic85] W.F. Tichy. RCS - a system for versio cotrol. Software Practice ad Experiece, 15(7):637 654, July 1985. [Wes91a] B. Westfechtel. Revisio Cotrol i a Itegrated Software Developmet Eviromet. PhD thesis, Aache Uiversity of Techology, Aache, Germay, 1991. [Wes91b] B. Westfechtel. Structure-Orieted Mergig of Revisios of Software Documets. I P.H. Feiler, editor, Proc. of the 3rd Iteratioal Workshop o Software Cofiguratio Maagemet, Trodheim, Norway, Jue 1991. ACM Press. [YHR92] W. Yag, S. Horwitz, ad T. Reps. A program itegratio algorithm that accommodates sematics-preservig trasformatios. ACM Trasactios o Software Egieerig ad Methodology, 1(3):310 354, July 1992.