[SOLVED] School of Computer Science – Coursework Issue Sheet

Session

15-16

Semester

Autumn

Module Name

Software Application Development

Code

G52SAD

Module Convenor(s) (CW Convenor in Bold)

Andrew French, Peer-Olaf Siebers

Coursework Name

Working with repository code

Weight

50%

Deliverable

(a brief description of what is to be handed-in; e.g. ‘software’, ‘report’, ‘presentation’, etc.)

Source code check-in AND Moodle drop box (zipped up project folder)

Format

(summary of the technical format of deliverable, e.g.
“C source code as zip file”, “pdf file, 2000 word max”, “ppt file, 10 slides max”, etc.)

Java and associated source files, and comments in the Git repository

Issue Date

Issued w/b 9th November (lecture 7)

Submission Date

Thursday 10th December 2015, 4pm

Submission Mechanism

Via repository for the code, and Moodle dropbox

Late Policy

(University of Nottingham default will apply, if blank)

Standard policy

Feedback Date

w/b 21st December

Feedback Mechanism

Individual comments via grading system on Moodle.

Instructions

The aim of this coursework is to demonstrate you can work effectively on larger software projects, by adding to a fairly complex existing software system, and that you understand the mechanics of the tools involved as well the real-world application of some object oriented principles.

You will be supplied with some existing Java code in a folder on Moodle (CW2 src.zip).

1 ) Your first task is to get this code set up in a new private project on the CS Gitlab server (http://git.cs.nott.ac.uk/). Organise the repository as appropriate. *

Name your git project “G52SAD-[yourISusername]” – e.g. G52SAD-sbzapf

Once you have a local version of the code talking to the Git repository, you are ready to make some changes to this code.

2) Add an appropriate open source licence file to the project, and push it to the Gitlab server, in a ‘licence’ folder. In the Git comments for this file, give your reasons for choosing this licence. I will leave it up to you to justify the licencing – as long as your reasons match the licence specification that is fine.

3) Refactoring changes:

In addNewAppliance in the Room class, you will see there is a case statement which switches between appliance IDs, setting power levels appropriately. This is simulating different kinds of appliances. The Boss has decided a better way to do this is with separate Appliance classes, representing individual appliances (e.g. Toaster, TV etc.)

Using your knowledge of object oriented design, refactor the code to make it possible to have different types of appliances (the five listed at the top of the Room class), with the appropriate power values stored internally in the classes. Don’t forget to demonstrate good coding practice, and be sure to add Javadocs to your code changes to explain them.

4) Adding a GUI:

We are going to want a visual way to set up and view the state of the Appliances in rooms. The GUI should perform two functions:

a) Allow the user to select a room, and view the appliances in it, and the current states (power etc.) of the devices

b) Allow the user to add, delete and change parameters for the devices.

5) You must comment any changes you make in the code with appropriate Javadoc comments. In your submitted source folder, there should be a subfolder called Docs, where you should render the Javadocs to HTML before submitting. Javadoc comments should include text describing what you are trying to do, and justifying your choice of implementation. WE WILL NOT MARK UNCOMMENTED CODE.

Notes:

•   * Your G52SEM lectures included a section of video and some notes under lecture 7 which walk you through setting up a Git repository for your code.
•   Running: If you want to run the code, you will need to set up or mock out the database (schema to follow on Moodle) and CSV config files (we will provide examples of these). Running all the code isn’t strictly necessary yet, BUT we would expect your new code to compile when merged into a full system .
•   GUI: details of developing GUIs will be taught to you throughout the coursework period. Therefore, it may be sensible to leave the GUI development until towards the end of the coursework period. Some tips for developing the GUI will be provided in Lecture 9, the first GUI lecture.

  Submission:

  1) You must push your changes back into your private remote CS Gitlab repository to submit. You should be using your repository anyway during

development, with appropriate comments to check in code. We will check for this. The marking team will need to be given access to your project – details will be provided nearer the time.

2) IN ADDITION, to confirm the submission time, you must zip up your source project folder and submit via the Moodle dropbox.

Assessment Criteria

Assessment will be both by examination of the submitted code, and by brief viva. Viva’s will be individual and will occur before the end of term. The purpose of the viva is to ensure you completed the work on your own, and you understand some fundamental concepts.

To achieve high marks:

You will need to have appropriately refactored the Appliance class and any affected sections in the other classes, using useful and well formatted Javadoc comments, and appropriate coding conventions. Your use of Git should be demonstrated (we will look at your repository, including looking for comments, number of check ins, licence file, and appropriate organisation of the source code tree.)

The GUI should be attractive, should function well (be responsive, etc.) and it should be easy to see and edit values as required. Both a) and b) components of the GUI should be developed in their entirety.

There should be evidence of relevant design patterns. A good mark:

As for ‘high marks’ but with minor unfinished or unworking sections. Javadocs should illustrate the correct approach, even if all the code is not quite working. An excellent source code with poor javadocs and poor repository use will not get excellent marks.

A pass mark:

To at least pass, you must show you have attempted to implement the required changes sufficiently using sensible approaches, though the resulting code may not work fully or be completely finished. A GUI should still display and demonstrate some functionality. If the code is a mess and we cannot work out what you changed or why, we cannot mark your code!