Home › Project 2013: Evolving ChEOPSJ: from a...

Project 2013: Evolving ChEOPSJ: from a prototype to a tool

Context

ChEOPSJ is an eclipse plugin for helping software developers in different programming tasks. It is based on change-oriented programming (ChOP), a style of programming that sees changes as the main development entities. This means that changes are first class entities that can be stored, analyzed and manipulated.

In ChEOPSJ, a software system is represented by the sequence of changes that have been applied to create it. This sequence of changes also represents the entire evolution of the system. The tool runs in the background of Eclipse. It silently records the source-code edits and stores them as change objects while the developer is programming.

On top of this change-logging infrastructure, different functionalities can be implemented for helping developers. In the current version of the tool, ChEOPSJ provides a test selection feature. It can tell the developers which tests are related to the latest changes in the source code so, they do not have to re-run all the tests again but only these relevant tests.

In some cases, the changes might have not been recorded from the editor, for example, when the developer has just installed the plugin for an existing project. For these situations, ChEOPSJ can also extract the sequence of changes from SVN repositories (although with a lesser level of detail).

ChEOPSJ is written in Java and it is deployed as an Eclipse plugin. It was born as a prototype so, in order to improve it, to add more features to it, and to turn it into a useful tool, it should be reengineered.

Assignment

As a reengineering team, you are asked to restructure the ChEOPSJ so it can accommodate one of the following improvements:

  1. In its current implementation, ChEOPSJ supports storing and managing changes related to packages, classes, methods, fields and method invocations. In next versions, it should record changes with a more fine-grained level of detail. The tool should be reengineered so it can easily include support for local variables, full method signatures (parameters, types), and accesses of fields, local variables or parameters.
  2. During run-time, the source code changes are now stored and manipulated just as objects in memory. Using only memory for run-time is highly inefficient and does not scale to big projects. Between sessions, the changes are stored by serialising them from the tool's run-time memory, into a file. This format is specific to ChEOPSJ and thus, the stored changes can not be distributed or shared. The change storaging should be improved. In run-time, a light-weight database should be used to store and manipulate the source code changes. The file format currently used to store the changes between sessions, which is specific to ChEOPSJ, should be changed to a platform-independent format that could be shared with other tools.
  3. ChEOSPJ is currently only able to extract changes from an SVN source code repository. In order for the tool to work with even more real world cases, the tool should support extracting and logging changes from other version repositories, such as Git, CVS or Mercurial.

Deadline: Thursday June 20th, 11h59 pm.   Send Project Report in PDF by e-mail to Javier Perez, Alessandor Murgia, Quinten Soetens and Serge Demeyer

You will have to choose one of these features for your reengineering project.

You can find the code on github here: https://github.com/qsoetens/Evolving_ChEOPSJ

In order to work on this, you will need to create an account on github (if you not already have one) and then fork the project to create your own copy to work on. (https://help.github.com/articles/fork-a-repo)

You will also need to send an e-mail to Serge Demeyer, Javier Perez, Alessandro Murgia and Quinten Soetens stating three things:

  • Who is your group composed of? (it is encouraged to work out the assignment in a group (2-3 people))
  • What is the feature you will be reengineering the project for. Unless you chose to work on a project of your own choosing, then you will also need to motivate why this project would allow you to demonstrate your reengineering skills.
  • Lastly, we also need you to share the url of the github fork you will be working on.
 
Then, more specifically, we ask you to perform the following activities, and report about these in your project report:

 

[Design recovery]

  1. Describe the current design of the implementation of the selected feature in CheOPSJ. Clearly indicate how this design is located in the architecture of the project.

[Design]


  1.  

    Compose a generic design that describes how the new functionality / feature should be integrated and how the design handles the interaction with the rest of the system. It should be clear that, in a) the types of changes recorded can be easily extended; in b) the choice for a specific storage format is merely an implementation detail; in c) the types of repositories supported can be easily extended.

    It will be necessary to redesign the test suite in such a way that it can cope with the new feature and design.

     

[Management]


    1. Estimate the effort required for (i) refactoring towards the new requirements; and (ii) changing/extending the tests.

[Refactoring]


    1. Refactor the current implementation of ChEOPSJ such that it can handle one of the new features.

    2. Adjust/extend the tests of the project to preserve their effectiveness and coverage during and after refactoring.

You will be required to perform a number of techniques presented during the lab sessions. These are:

  • Analyse:
    • Duplicated Code Analysis
    • Metrics and visualization
  • Restructuring:
    • Testing
    • Refactoring

This project emphasizes the sound, systematic analysis of the presented problem, the associated solution space and the chosen solution(s). The software reengineering sessions are composed in such a way as to prepare you for such a project. We stimulate you to assess the benefits and drawbacks of the techniques presented in the lab sessions, and ask you to exploit the analysis techniques wisely. You are free to use alternative analysis techniques.

What concerns the refactoring-part, we emphasize the use of tests. Our minimum requirements are:

  • Determine the extent to which the current tests provide feedback on your future refactoring-steps. Quantify this.
  • Compose an argument discussing why the tests are (in)adequate for your chosen refactoring scenario, and adjust the tests in case this is required. Be efficient with regard to the time invested in testing.

Result

To show that you have passed the assignment, you will have to demonstrate the following:

  • You have made a selection of analysis techniques (e.g., duplicated code analysis, mining software repositories, metric and visualization as seen in the lab sessions, but others are allowed as well), and have applied these techniques in a sound, systematic manner. You have indicated clearly (using screenshots, results of the interpretation of the output of the techniques) how you have used the results of these analysis techniques.

  • You have performed the above 5 activities (decomposed into (i) Design Recovery; (ii) Design; (iii) Management; and (iv) Refactoring) and discussed them in your project report.

  • The restructurings you have applied are behavior preserving.

    • You can demonstrate the mapping between each of the classes from the original structure with the new structure.
    • The compilation process succeeds flawlessly.
    • The tests run without flaws, and demonstrate clearly that the new userinterface is implemented correctly.

  • The introduction of the new design clearly indicates the project is ready to be released in a language of choice. You are not supposed to carry out the refactoring process completely. Select and execute a set of refactorings that sufficently illustrate your proposed solution.

Report

Aspects that we typically like to see addressed in the report are:

  • Context: Briefly discuss the context in which you are running your project.
  • Problem at hand: Clarify the problem at the base of the project, and indicate its intrinsic difficulties.
  • Project management:Demonstrate how you have organized the work, and how you are controlling it (instead of the work controlling you!)
    • Scope: What are the boundaries of your project? What is not included in the project?
    • Risks: Which risks were envisioned, and which have been mitigated? What is the priority of the risks that still need to be migitated? E.g., which external dependencies might have an affect on your outcome? Which alternatives have you prepared in case this risk instantiates?
  • Software reengineering:
    • Tests: How can you verify that you satisfy the requirements? Which testing strategy have you selected, and what are the arguments for this selection? How confident are you that your solution satisfies the requirements?
    • Quality assurance: What are the non-functional requirements? E.g., how do you differentiate between a good and a bad solution?

 

Note: similar to previous years, it is once again possible to submit your own project proposals. These proposals will be approved in case they provide a well-structured exercise on the reengineering techniques presented in the lab sessions. E.g., you can always propose to reengineer another software system, for instance the software system used in your thesis, or written for another case.