ITECH2309 – Software Engineering Assignment1, 2019/17
Assignment 1 – Refactoring
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.
Timelines and Expectations
Marks: Assignment will be assessed based on a mark out of 30
Percentage Value of Task: 15% of the course marks
Due: Friday, Week 7 at 11:55pm
Minimum time expectation: 15 hours
This is an individual assignment. There is an expectation that no two submissions will be the same.
Learning Outcomes Assessed
The following course learning outcomes are assessed by completing this assessment:
• S1. Apply software engineering principles to design and implement software applications.
• S2. Operate CASE software to develop appropriate models of software systems.
• S3. Develop comprehensive unit test suites.
• A1. Write integrated reports, using appropriate models, providing detailed analysis of given textual scenarios.
• A2. Implement software applications, using appropriate software engineering techniques, from a given textual scenario.
CRICOS Provider No. 00103D

Assessment Details
Background
Refactoring
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:
a. Enter the GitHub classroom https://classroom.github.com/a/2m2yPb9_ to create your individual repository in GitHub;
b. If you haven’t used GitHub before you will need to create an account using the link on the signin 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.
c. 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.
d. 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 you’ve 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.
Submission
Your response should be presented in a business or management style report format according to the Federation University General Guide to Writing and Study Skills.
Any in text citations and your accompanying reference list should comply with the APA style (see Federation University's General Guide to Referencing).
Please submit an electronic copy of your assignment only via Moodle. Your submission should be in one zipped or equivalent file. The file should contain:
• Your report in MS-Word or PDF format. The report should include:
o Appropriate presentation features such as Title page, Table of Contents, References (if used); o Identification of smells in original code. You must name these according to the Fowler (2000) list and describe how it occurs in the code;
o Your Refactoring response to the smells. This should include for each smell:
? the name of the chosen refactoring/s; and
? a description of the changes required to implement these refactoring/s;
o Images of class diagrams – before and after refactoring - from EA
• Your GitHub repository link;
• Your code after refactoring should be submitted in a zipped file containing the Eclipse project;
• Your EA class diagrams
Name the submission file according to the following: ‘itech2309_your_name_yourStudentID_assign1.file_ext’
Please refer to the Course Description for information regarding late assignments, extensions, special consideration, and plagiarism. All academic regulations can be accessed via the university’s website, see: http://federation.edu.au/staff/governance/legal/feduni-legislation/feduni-statutes-and-regulations
Plagiarism
Plagiarism is the presentation of the expressed thought or work of another person as though it is one's own without properly acknowledging that person. Students must not allow other students to copy their work and they must take care to safeguard against this happening. More information about the plagiarism policy and procedure for the university can be found at http://federation.edu.au/students/learning-and-study/online-help-with/plagiarism.
Marking Criteria/Rubric
Your work will be assessed according to the rubric at the end of this document.
Feedback
Feedback usually occurs through Moodle within two weeks of the submission date. Partner students please check with your course lecturer for further information.
References:
Fowler, M. (2000). Refactoring: Improving the design of existing code. Reading, Mass.: AddisonWesley.
Suryanarayana, G., Samarthyam, G. and Sharma, T. (2015). Refactoring for Software Design Smells: Managing Technical Debt. Amsterdam; Boston: Elsevier, Morgan Kaufmann


Assessment Feedback
Student
Refactoring
Task Criteria Range Marks
Report detailing “code smells”
Max Mark = 7 • Up to seven code smells accurately identified
• Description of appropriate refactoring to address these smells
• Description of how these refactorings will be implemented
• Has both class diagrams 5 - 7
• Five or less code smells identified
• Some refactorings not appropriate or not explained clearly
• One or both class diagrams are missing 2 - 5
• Not many codes smells identified
• Explanations not clear
• Appropriate refactorings not identified or explained
• No class diagram included 0 - 2
Implement Refactorings
Max Mark = 14
NB: There must be evidence of multiple pushes and commits to a student’s GitHub repository. It is recommended this is done after each refactoring. Students will be penalised up to five marks if there is insufficient evidence of this. • Refactoring of seven smells implemented correctly
• Coding standards adhered to
• No syntax errors
• Produce the same output as before 11 - 14
• Some refactorings implemented correctly
• Minor misconceptions or errors
• No syntax errors
• Produce the same output as before 6 - 11
• Few refactorings implemented correctly
• Syntax errors present
• Programming standards not adhered to
• Does not produce the same output as before 0 - 6
Class diagrams
(for each class diagram)
Max Mark = 6 • All classes represented
• Operations and attributes present
• Correct aspect specifications
• Appropriate connections between classes 2 - 3 (each)
• Not all classes represented
• Some operations and attributes missing
• Other errors 0 – 2
(each)
Presentation
Max Mark = 3 • Title Page
• Table of Contents
• General Presentation 0 - 3
Total (/30)
Assignment Course Mark (/15)
Comments
Marked by
Date