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.
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
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.
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:
- 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?
- 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.
- 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?
- 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.
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.
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.
本网站支持淘宝 支付宝 微信支付 paypal等等交易。如果不放心可以用淘宝交易！
E-mail: firstname.lastname@example.org 微信:itcsdx