Individual Project Investigating and Critiquing Joda Time

1.   Overview

Joda-Time is a long-standing Java framework to support work with times and dates. Before Java 8, it was the de-facto library (and was largely absorbed into what is now the Java JDK date and time library.

It is a genuine piece of legacy code - it’s 20 years old and still going strong. It is still built into many current software applications that have not migrated over to the built-in Java time library.

Your job  is  to  investigate  and  to  critique  its  design,  and  to  identify  potential  reengineering opportunities.

This assessment is to be carried out on an individual basis. You must not discuss your solutions or findings with group members.

2.  Setup

For students who have already forked their projects, you can either opt to start afresh (starting from the next step), or there are some instructions on the next page that will help you to retain the work you have already done.

Log in to GitLab, and create a new project, called “Individual Project” .

Make sure that the project visibility level is set to “private” .

Once you have created the project, initialise it by cloning the Individual Project base directory from here. You can achieve this by:

git clone https://stugitlab.dcs.shef.ac.uk/courses/com3523/2021-22/individual-project.git cd individual-project/

git remote remove origin

git remote add origin https://stugitlab.dcs.shef.ac.uk/UNI_USERNAME/REPO_NAME.git git push -u origin master

It is vital that we are able to access your repository, so please make sure that you give the following people (and only the following people)“maintainer”access as soon as you initiate the project:

•    Neil Walkinshaw (@ac1nw)

• Islam Elgendy (@ac1ie)

• Richard Somers (@acs21rs)

• Andy Clark (@acp19agc)

You can find the “add members” section in the “Members” portion of your newly created project in

GitLab.

If you have already “forked” your project according to the previous instructions, you can skip the first two steps in the above commands. At the command line, navigate to the directory representing

the forked project, and execute the commands starting from “git remote remove origin”. Once you have done this, please remove your forked project from GitLab.

The base repo contains three directories: A clone of Joda-Time, a clone of the Reengineering Toolkit, and an almost empty directory called “submission” .

Joda-Time and Reengineering Toolkit have been stripped of their specific git metadata, to avoid any confusion.

You  must  only  use  tools  that  are  available  in  the  Reengineering  toolkit,  or  refinements  / enhancements of these tools, which are to be committed as part of your submission. You must not resort to third-party tools - e.g. plugins to IntelliJ.

Finally, the  submission  directory  is where you will  include your written  submission,  and  any additional data or figures that you’d like to include.

3.  Instructions

For this assignment, the goal is to put all of the skills that we have covered so far into practice. The main assessed part of the work will be a write-up, but figures and committed code will be required as well. The report needs to adopt the following structure:

1.   Initial analysis

Analyse all of the non-testing .java files in the joda-time package. Analyse the distribution of LOC. Analyse the number of times that they have featured in version repository commits.

Since we have stripped out the Git meta-data so that it would not conflict with the Git data for the assignment as a whole, for the repository analysis you will need to clone the original repository directly from GitHub into a separate directory. For this you should run:

git clone https://github.com/JodaOrg/joda-time.git

git checkout d5efcf6

You should capture the results in some graphical format such as a bar-plot, or some other appropriate visualisation.

Write up briefly what these results indicate about the system. Are there any features that     stand out? Are there potential areas of concern? Are these substantiated by a brief informal analysis of the source code?

2.  Static analysis

Reverse engineer a class diagram that provides some insight into one or more of the classes highlighted in the superficial analysis. Again, exclude JUnit test classes here. Given the          number of classes in the module, this may require you to focus on a particular package or    sub-package.

Change the visualisation of the class diagram, so that either the LOC, or the number of times

a file has been changed, is reflected in the class diagram.

Present the resulting class diagram and briefly discuss any particular highlights.

3.  Dynamic analysis

Identify an aspect of functionality that you believe should exercise code that features in the results that you have collected so far. Identify or manually construct a JUnit test case that  exercises this function.

Apply software reconnaissance to accurately identify the set of code units that are specifically relevant to this feature.

Discuss your findings. Are the (possibly) problematic classes identified previously specific to the functionality that you have investigated? Or are they classes that appear to be more        general (e.g. utility classes)?

For COM6523 students only (not undergraduate COM3523 students):

Write your dynamic analysis to record the amount of clock-time that is spent executing each method. When a method calls another method, then the amount of time spent on the callee should also be counted as clock time for the method that calls it.

For the same traces as are used for the software reconnaissance (recorded with your     enhanced analysis), calculate (e.g. in Excel) the total amount of time spent executing each method.

Can you derive any additional insights from this analysis? For example, is there any                correlation between the amount of time spent executing a class and the size of its methods?

4.  Code clone detection

Calculate the Jaccard score for every pair of non-testing classes. Compare a few of the pairs with the top scores (provided that these are of a reasonable size and complexity).

Visualise the code clones for one pair of classes as a dot-plot, and describe any clones therein.

5.  Metrics

Create a CSV file where each row contains a class (excluding test classes). For each class, you should compute:

• The Fan-in for the class.

• The Fan-out for the class.

• The number of methods in that class.

• The number of data-members of that class.

For the first two (Fan-in and Fan-out), you will need to compute the call graph. For the       second two you will need Reflection. Use the approaches covered in the Static Analysis lab to compute this.

6.   Critique

Referring back to the evidence that you have collected in the previous topics, along with any additional metrics you have computed where appropriate, identify your three top design

problems with the system.

This must draw upon the material covered in lectures - offering some useful justification on the basis of the various forms of information collected, as well as knowledge about good     design principles.

Approximate word-length for COM3523: 1000-1500 words.

Approximate word-length for COM6523: 1500-2000 words.