Overview

The aim of this assignment is to provide students with the opportunity to apply knowledge and skills related to the improvement in the design of code. They do this by documenting, refactoring and testing an existing application provided with the assignment.

Background

Refactoring is said to be "the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs". (Fowler, 2000, p. xvi). However it is not just a process for cleaning up code. Your lecture slides point out that whilst refactoring does not cure all ills and can find bugs, it can also improve the design of software, make it easier to understand and help you program faster.

The concept of 'smells' has been introduced to help identify where refactoring should occur. Smells (problems) can be identified and classified in a number of ways including at the code level such as the ones identified by Beck and Fowler (Fowler, 2000) or at a higher level such as those identified by Suryanarayana and others (2015). They associate smells with the notion of technical debt - the debt that accrues when non-optimal or incorrect decisions are made either knowingly or unknowingly. From their perspective, smells can be classified into architectural, design or implementation types and any of these can either be structural or behavioural in nature. In any case, the refactoring that is performed may be in a general sense to follow good practices or more specifically to follow other modelled solutions such as design patterns. As you are just starting your journey, you are expected in this assignment to follow the refactoring practices outlined in Fowler (2000). You need to examine some code and identify the smells catalogued by him and choose appropriate refactoring/s from his suggestions for the smell and implement them. You should also follow good practices including appropriate variable naming, code indentation and commenting.

Clinic Management System

You have been provided with access to a GitHub repository with some code in it.

The code provided is part of a larger system, the Clinic Management System that is under development. The system is built with the purpose of managing a veterinary practice that may have multiple clinics. At this stage, the classes provided to you are for the class: Veterinarian, Animal and Clinic. There is a simple driver class that is used mainly for demonstrating these 3 provided classes. The larger system is menu driven and will enable an employee at the clinic to allocate animals who register to a particular veterinarian. After the allocations, the animals' owners will be able to make an appointment with their allocated veterinarian using an online web portal.

At the current stage of development, a junior software developer has been working on the classes Animal, Veterinarian and Clinic. However, at a recent code review meeting, a more experienced software engineer has made the comments provided below. It is your job to read the comments and help the junior software developer to identify some bad smells and indicate where refactoring might be performed to improve the code. After identifying the potential changes, you should demonstrate the refactoring of the code so that the design is improved. At this stage, you do not need to add functionality to these classes. The aim now is to improve the design. Rewrite the code according to each refactoring and commit it to your individual GitHub repository.

Comments made by the experienced software engineer:

"Hmm, I think there are some things that need reviewing in these classes. I feel there are some bad smells in the design. I suggest you examine the code to identify any obvious smells and then perform some refactoring to improve the design. Smells are not the only thing to focus upon. You should also follow good coding conventions including for example appropriate and meaningful variable naming. Ultimately, you need to think about how you can refactor your code to improve it. The goal is to perform some refactoring and improve on the code without changing the functionality it provides. You might think about the purpose of each class and what methods belong in each. It might help to create a UML class diagram in order to have a high level view of these classes.

As you are reviewing the code, I wonder if the following issues might be considered:

1. There are quite a few situations where code is duplicated and/or very similar code appears;

2. What is the purpose of the Clinic.java class? I am wondering if there should be some methods on the clinic to manage the attributes associated with a clinic such as the veterinarians and the animals. This class is confusing, what is it responsible for? There is a long method which seems to be doing a lot. I feel that there is unnecessary coupling between the Clinic and the Animal class.

3. Is the Animal object really responsible for allocation of a Veterinarian? Perhaps that allocation is done elsewhere and then a message sent to the Animal to inform it who has been allocated?

4. Have a look at refactoring collections. I always think that is a good idea. In fact, encapsulation of both fields and collections are basic good design decisions in my opinion.

5. One last thing, switch statements indicate a bad smell in the code, but there are similarities with use of selection statements and type codes. I think there could be a similar smell 'Type codes used with selection'. There are clearly two animal types - InsuredAnimals and UninsuredAnimals. Each of these are associated with different behaviours in terms of allocations of veterinarians amongst other things."

Assessable Tasks/Requirements

The application code is badly in need of refactoring. Many examples of the "code smells" discussed in Fowler's (2000) book should be evident.

You are to complete the steps outlined below and submit a report and associated code solution. You need to use a number of software tools in this assignment. Access and documentation links to these tools are included in your Moodle shell.

1. Step 1 - Access the code

a) Complete the following to steps to setup your GitHub repository and download your starting code:

  • Enter the GitHub classroom https://classroom.github.com/a/2m2yPb9_ to create your individual repository in GitHub;
  • If you haven't used GitHub before you will need to create an account using the link on the sign- in screen. Create a GitHub account by following the instructions in the handout (Registering for and using a GitHub repository and the GitHub Classroom) available in the Study Resources section of your Moodle shell.
  • Follow the separate handout (Using Eclipse IDE to interface with GitHub repository v2) available in the Study Resources section of your Moodle shell. Start at page 7 to page 11 to download and import the provided starter code from the GitHub classroom and load it into a new local repository in Eclipse.
  • Now you have imported the starter code into a project repository in Eclipse.

b) Run the system. You will find that it has created a file called "MyOutput.txt" in the working directory. If you wish to use a different folder you will need to update the output file in MainDriverClass.java. The output of the program will be displayed on the console and written on the output file.

2. Step 2 - Begin a report document

Open up a new document in Word (or equivalent), start jotting down any code smells you identify in the code in point form (you might want to cut and paste the code into Word to illustrate the problems). This will form a report that you will need to include in your assignment submission.

3. Step 3 - Create a class diagram of the initial code

Create a class diagram of the given code in Enterprise Architecture (EA). For help with this you can read the document Using Enterprise Architect in the Study Resources section of your Moodle shell. This class diagram should be included in your final submission. The image of the diagram should be in your report as well.

4. Step 4 - Start refactoring and testing your changes

a) At the start of each work session, pull the most recent version of code from your remote repository into your local repository before you start work.

b) Begin refactoring in Eclipse.

c) If you have what you think is a smell, note it down in your document if you have not already done so.

d) Identify the refactoring/s you will use and update your code.

e) Each time you think you have completed a refactoring, run the program and then test if the program output is the same as the output before refactoring. You can rename the output file so that you can check them. You can write a simple Java program to check if two output files are the same or not so that you do not have to manually inspect them. If the two outputs files (before and after refactoring) are different, it is because the output has been changed. Refactoring should not change the output so you will need to look at the code you have already written before you move on.

f) When you have completed each refactoring, commit and push your new code from your local Eclipse repository to save it in your own online GitHub repository. It may be necessary to add files to the index before committing.

g) Update your report document with what you have done for the refactoring.

5. Step 5 - When you have finished refactoring

If you haven't updated your UML class diagram as youve refactored, create a second class diagram in EA of the final refactored code. This should be included in your final submission. You can drag and drop the pdf of your UML and the EA project file into your repository using a web browser. An image of your diagram should be in your report as well.

Academic Honesty!
It is not our intention to break the school's academic policy. Posted solutions are meant to be used as a reference and should not be submitted as is. We are not held liable for any misuse of the solutions. Please see the frequently asked questions page for further questions and inquiries.
Kindly complete the form. Please provide a valid email address and we will get back to you within 24 hours. Payment is through PayPal, Buy me a Coffee or Cryptocurrency. We are a nonprofit organization however we need funds to keep this organization operating and to be able to complete our research and development projects.