CodeBreaker Decentralized, cooperative and flexible support for extreme programming software development Nelson Baloian Roberto Konow Francisco Claude Mitsuji Matsumoto

The Problem Juanita Pedro

* Extreme Programming *

Program as fast as you can Simple Designs Pair Programming Small Releases Beta testing Team Communication

Available Technologies Version Control Systems  CVS  Subversion  Etc... Collaborative Environments  IBM Rational ClearCase  TUKAN File Level permissions Central Repository Synchronous/Asynchronous Central/Distributed Repository Expensive Many Developers

“Breaking” The code A.java String sint d Method zMethod y

“Breaking” The code A.java String sint d B.java Method zMethod y Method HMethod v

Logical Locking Every File, Class, Method or Logical Object must have an owner. Every Logical Object is locked to everyone except the owner. The locking is done over a name of a class or interface, a method inside a class or a class variable. (Fine Grained Locking) Automatically locking the inherited classes of a locked class. (Extended classes, Implementation of Interfaces, etc) It is possible to lock code which still not exists

“Breaking” The code

Coordination Rules The Coordination Rules are necessary to maintain the development in order.  Code ownership can be transferred with or without permit to transfer to a third  New members can be created with or without right or limited number to invite others,  This can implement a kind of “administrator role” Two kind of Files:  Accepted Java Files The “final” and revised java files.  Temporary Java Files Files being changed by another users.

Exceptions to the rules What happens when the hard disk of a code- owner crushes forever ?  Change ownership by voting  Define creator of the project as administrator What if a user start not cooperating ?  Does not confirm code change ownership  Starts distributing code which does not owns Introduce public and private keys

Coordination Rules Participant “Pedro” is not available. Participant “Juanita” Needs to modify something in the definition file of Object E.

Coordination Rules “Juanita” Changes part of the code in object E. A Temporary Java File is created.

Coordination Rules “Pedro” goes online and receives the changes made by “juanita”. “Pedro” can Accept or Reject the changes made.

Coordination Rules “Pedro” accepts the changes and the modified java file is now an “accepted java file”.

Requirements Work on a peer-to-peer architecture without having a central repository. Allow synchronous and asynchronous collaborative working (including synchronization of the code). Allow the inclusion of new unforeseen participants. Allow fine grained and logical oriented locking of code.

* File System Architecture * Accepted Java Files : This layer contains the Java files with that where accepted by their owner. It is used to create distributions of the software, giving an alternative to build a patched version also, including code that has not been accepted yet. The files are stored as normal java files of a NetBeans project. Temporary Files : Those are the copy made for every java file containing modifications which are still not approved by the owner of the code XML Files : There is an XML for every Java file containing the information about the owner, permissions and information needed for the merging phase. The Simulated File System: Is the logical layer that manages the logical access to the physical files and presents the information about which part of the code is owned by which user and whether the local code has been approved or released by the owner. For this, it uses the information stored in the XML files. It also implements a transparent file system for the user merging the temporary files with the accepted ones when corresponds.

* The XML File * name : The name of the entity. owner : user that owns this object. rev : the version of this object, incrementing in one for every modification made or accepted by the owner. modified : a boolean variable that allows to know if a certain object has been modified by a user that has not the rights. umod : user that modified the file without permission. uver : the version created by the user that is making the modifications without owning the object itself. srcid : a description of the object that allows to distinguish for example two methods with the same name but different arguments. type : if the object is a variable, method, class, etc.

class Test { // fields... // methods... } Java File XML File Transform... The Variables owner, srcid, user modification and user version are assigned in the xml file, including all the java source file information.

Synchronization JXTA/ /pen drive XML FILE

XML File XML File 1 Compare XML Transfer File PRODUCEPRODUCE

Types of Differences: Modification: Changes in the source code or the owner. DeleteClass: Deletes a Class DeleteMethod: Deletes a Method Delete Field: Deletes a Field NewMethod: Creates a new Method NewField: Creates a new Field NewClass Creates a new Class XML Transfer File

Scenarios of usage Development of Extreme Programming Projects with small teams. Development of small Spontaneous Ideas outside the working area. (i.e: Coffee Break) Development of medium-sized projects without having a fixed development team and a fixed physical work area. (small student-owned software developing enterprises) Support for development teams where members are constantly changing roles. Collaborative learning tool for Java courses.

Conclusions CodeBreaker is: Synchronized/Asynchronized development tool Fine-grained and logical blocking of the code Support for Extreme Programming teams Support for Pair-Programming. Controlled permissions of the code for the developers with flexibility for special cases. Peer-to-peer Network Easy to install and use (Netbeans plugin)