Hit The Order Button To Order A **Custom Paper**

>> CLICK HERE TO ORDER 100% ORIGINAL PAPERS FROM AustralianExpertWriters.com <<

29 Aug
2019

ITECH2309 – Software Engineering Assignment1, | Good Grade Guarantee!

School of Engineering and Information Technology
ITECH2309 – Software Engineering Assignment1, 2019/17
CRICOS Provider No. 00103D ITECH2309_A1_S9_2019_201917_Refactoring Page 1 of 9
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.
School of Engineering and Information Technology
ITECH2309 – Software Engineering Assignment1, 2019/17
CRICOS Provider No. 00103D ITECH2309_A1_S9_2019_201917_Refactoring Page 2 of 9
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,
School of Engineering and Information Technology
ITECH2309 – Software Engineering Assignment1, 2019/17
CRICOS Provider No. 00103D ITECH2309_A1_S9_2019_201917_Refactoring Page 3 of 9
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.”
School of Engineering and Information Technology
ITECH2309 – Software Engineering Assignment1, 2019/17
CRICOS Provider No. 00103D ITECH2309_A1_S9_2019_201917_Refactoring Page 4 of 9
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
School of Engineering and Information Technology
ITECH2309 – Software Engineering Assignment1, 2019/17
CRICOS Provider No. 00103D ITECH2309_A1_S9_2019_201917_Refactoring Page 5 of 9
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
School of Engineering and Information Technology
ITECH2309 – Software Engineering Assignment1, 2019/17
CRICOS Provider No. 00103D ITECH2309_A1_S9_2019_201917_Refactoring Page 6 of 9
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.
School of Engineering and Information Technology
ITECH2309 – Software Engineering Assignment1, 2019/17
CRICOS Provider No. 00103D ITECH2309_A1_S9_2019_201917_Refactoring Page 7 of 9
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
School of Engineering and Information Technology
ITECH2309 – Software Engineering Assignment1, 2019/17
CRICOS Provider No. 00103D ITECH2309_A1_S9_2019_201917_Refactoring Page 8 of 9
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)
School of Engineering and Information Technology
ITECH2309 – Software Engineering Assignment1, 2019/17
CRICOS Provider No. 00103D ITECH2309_A1_S9_2019_201917_Refactoring Page 9 of 9
Comments
Marked by
Date

QUALITY: 100% ORIGINAL – NO PLAGIARISM.

  • **REMEMBER TO PRECISE PAGE NUMBER**
  • Hit The Order Button To Order A **Custom Paper**

>> 100% ORIGINAL PAPERS FROM AustralianExpertWriters.com <<