Background for the header
To the home page of the University of Antwerp

 

 

Project 2011: Prepare Robocode for the implementation of a mines dropping feature.

Context

Robocode is a programming game where the goal is to code a robot to compete against other robots in a battle arena. The player is the programmer of the robot, who will have no direct influence on the game. Instead, the player must write the AI of the robot telling it how to behave and react on events occurring in the battle arena. So the name Robocode is a short for "Robot code". The game is designed to help you learn Java, and have fun doing it. Robots are written in the JavaTM Programming Language, and the Robocode game can run on any operating system supported by the Java Platform, which includes all common operative systems like Windows, Mac OS X, Linux etc. Robocode's battles take place in a battlefield, where small automated 6-wheeled robots fight it out until only one is left. Please notice that Robocode contains no gore, no blood, no people, and no politics. The battles are simply for the excitement of competition that we love so much. There are explosions, however, but these can be turned off if they are offending.[source:http://robowiki.net/wiki/Robocode]

Assignment

As a reengineering team, you are asked to restructure the architecture and implementation of Robocode such that Robocode can be easily released with a new feature enabling tanks to drop mines.

A robot in robocode can move on the battle field, fire with its turret and scan with its radar. But users are waiting for new weapons. A first one that is often present in tank games is mines. The programmers community answer positively to this request and are ready to start with the implementation. But as this feature was not taking to account during the original design of robocode, they ask you, as reegineering experts, to prepare robocode for this new feature. Open questions are still in outstanding: should a mine be detected by the radar, should it have a lifetime, ... As a reengineering team, you have to come up with possible designs, influenced by answer to previous questions, discuss them and select the one you find the most appropriate.

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 Robocode. Clearly indicate how this design is located in the architecture of the project.


[Design]


  1. Suggest several designs that allows robot of Robocode to be elegantly extended with the ability of dropping mines

  2. Pick the most appropriate solution based on design quality and effort estimations (see next section).

[Management]


  1. Estimate the effort required for (i) refactoring towards a design easy to extend with mines dropping; and (ii) changing/extending the tests.

[Refactoring]


  1. Refactor the current implementation of Robocode such that it is easy to add mines dropping feature.

  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
    • Mining Software Repositories
    • 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 have been 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 4 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 functionality is implemented correctly.

  • The introduction of the new design clearly indicates the project is ready to be extended with the dropping mines feature.

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.

Questions & answers

  • Q:Is a previous mail, you wrote that the exam remains scheduled on wednesday may 29th and that the project report is expected one week earlier: june 22nd. The exam is on June 29th I suppose ?
    A:Yes, it is a mistake. The exam is on wednesday June 29th and the project report is expected on June 22nd.

  • Q:The tool I use to extract the class diagram of the Robocode application, runs out of memory or does not work with the subproject structure of the Robocode application. How should I proceed?
    A:You are free to use whatever tools you like, but you should deal with the scale issue by yourself. That is part of the project. Perhaps manually drawing the diagram would be a better option. If you reverse engineer the design, you should demonstrate that you identified the essential parts of the design, that is something a tool can't do. It is important to discuss the problems you encountered and how you solve them in your report !

 

Valid HTML 4.01! Valid CSS!

 Lab On REengineering - Antwerpen, last modified 14:33:36 12 May 2011