Custom written essays, Online classes handling, Proctored exams, Dissertation projects

Part 1: Using JDeodorant to refactor design flaws

Description:

In the previous assignments, you were able to locate several design flaws using InFusion, in this assignment, were interested in fixing some of them. You will choose at least 2 design flaws instances, from 3 different design flaws types (6 in total). You will use JDeodorant to come up with potential refactoring operations to fix them. Since JDeodorant sometimes gives you many recommendations on how to fix the same flaw, based on your understanding of the symptoms of design problems, choose the necessary refactorings that might solve these problems. Finally, you will check that the problems have been actually solved or not using InFusion.

Task:

For this exercise you will need to use JDeodorant. You will have JDeodorant analyze one version of a JAVA software of your choice (you can use your previous assignment project if it is feasible). You will then be asked to make some refactoring decisions and report them and their impact. Follow these steps:

• Install the Eclipse plug-in for JDeodorant
• Run JDeodorant on a project of your choice and select 2 instances of each of the following flaws types:
  • God Class
  • Feature Envy
  • Long Method
• Now, you can look at the refactoring recommendations by JDeodorant, choose which ones to be executed, keep refactoring until you process all your chosen instances. 
• Now use InFusion. Input your refactored project and double check if the instances that you have just refactored are seen as infected with the flaws.
• Report your findings: Chosen flaw instances, chosen refactoring operations, refactoring results. (Provide screenshots as well).
• Add to the report a concise comment about your experience with JDeodorant (positives, negatives and other comments).

Note: getters and toString() methods are only intended to be tested to get the desired coverage. One test method per each getter/toString() is sufficient.

Note: Methods are not the same as asserts. Each method should, ideally, have one assert.

Grading:

Part1. 

Fixing 6 design flaw instances from 3 different types – 30%

Part2. 

Choosing a commit – 5%

Reporting refactorings and their impact on CK metrics- 15%

Part3. 

Coverage per class:

• 100%  10%
• 80%-99%  5%
• <80%    0%

Errors (20%):

Submission:

Submit 1 pdf file containing your report for all 3 parts. For part 1, submit your corrected defects and your comments about the tool. You also need to provide a link or name to the source code of the project you studied. Submit a screenshot of your coverages in the pdf as well. Attach your project source code after adding the test cases. The following figure explains how your submission should be structured: