CodeBreaker

1. CodeBreaker Decentralized, cooperative and flexible support for extreme programming software development Nelson BaloianRoberto KonowFrancisco ClaudeCristian Tala

2. The Problem Pedro Juanita

3. * Extreme Programming? *

4. * Extreme Programming * • Program as fast as you can • Simple Designs • Pair Programming • Small Releases • Beta testing • Team Communication

5. 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

6. “Breaking” The code A.java Method z Method y String s int d

7. “Breaking” The code A.java Method z Method y String s int d B.java Method H Method v

8. “Breaking” The code

9. 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.

10. 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

11. Coordination Rules • The Coordination Rules are necessary to maintain the development in order. • Two kind of Files: • Accepted Java FilesThe “final” and revised java files. • Temporary Java FilesFiles being changed by another users.

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

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

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

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

16. * 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 Emulated 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.

17. * 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.

18. Synchronization XML FILE Peer to peer JXTA/email/pen drive Peer to peer XML FILE

19. class Test { // fields... // methods... } <Class> <field>...</field> <method>.... </method> </Class> 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.

20. <Class> <field>...</field> <method>.... </method> </Class> <Class> <field>...</field> <method>.... </method> </Class> XML File 1 XML File 2 Compare <Transfer> <difference type=”modification”> <class> ..... </class> </difference> </difference type=”deletemethod”> <class> <method> .... </method> </class> </difference> </Transfer> XML Transfer File

21. XML Transfer File • 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

22. Scenarios of usage Development of Extreme Programming Projects with small teams. Development of small Spontaneous Ideas outside the working area. (i.e: Coffee Shop) Development of medium-sized projects without having a fixed development team and a fixed physical work area. Support for development teams where members are constantly changing roles. Teaching resource, for introductory courses of Java.(Using the Pair Programming capabilty)

23. CodeBreaker is: Synchronized/Asynchronized development tool FineGrained 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)

24. Thank You Q&A