CSSE2002 / CSSE7023 Semester 1, 2015 Assignment 1
Goal: The goal of this assignment is to gain practical experience with data abstraction, unit testing and using the Java class libraries (the Java 8 SE API).
Due date: The assignment is due at 4:00pm on Friday 17 April. Late assignments will lose 20% of the total mark immediately, and a further 20% of the total mark for each day late. Only extensions on Medical Grounds or Exceptional Circumstances will be considered, and in those cases students need to submit an application for extension of progressive assessment form (http://www.uq.edu.au/myadvisor/forms/exams/progressive-assessment-extension.pdf) to the lecturer (email is acceptable) or the ITEE Enquiries desk on Level 4 of GPSouth Building prior to the assignment deadline.
Problem Overview: In this assignment, and the following two assignments in this course, you will develop the component classes of a program for helping festival-goers to plan their day at a music festival.
A music festival is held over the course of a day at a number of different venues. The day is broken up into consecutive sessions, and events can be scheduled for a given venue in a given session. The venues are physically disparate, and so shuttle services are scheduled to take people from one venue to another at the end of each session.
Task Overview: In this assignment, you will be writing data types for an Event, a Service, a ShuttleTimetable and a LineUp. If you are a CSSE7023 student you will also be required to write a JUnit4 test suite for the Event class in the EventTest class.
Task Details:
Skeletons for the classes Event, Service, ShuttleTimetable and LineUp are provided in the zip file in the festival package. These skeletons include Javadoc
specifications of the constructors and methods that you need to complete. You must complete these class skeletons according to their specifications in the files. You will need also to declare variables, add import clauses, and add comments and javadocs as required.
If you are a CSSE7023 student, you will also need to complete systematic and understandable JUnit4 test suite for the Event class in the skeleton of the EventTest class from the festival.test package. You may write your unit tests assuming that the classes that Event depends on (e.g. the Venue class and any of the Java SE API libraries) are implemented and functioning correctly. That is, you don’t need to create test stubs for these classes.
Copy or rename the skeleton files before you start. (Don’t forget that the package and class names inside the files must correspond to the file and the directory names … otherwise you’ll have difficulty compiling and running it.)
You must implement these classes as if other programmers were, at the same time, implementing the code that instantiate them and call their methods. Hence:
- Don’t change the class names, specifications, or alter the method names, parameter types, return types, exceptions thrown or the packages to which the files belong.
- Don’t add any new methods or variables to the classes unless they are private (that would be changing their specification by adding new features accessible from outside the class).
- You are encouraged to use Java 8 SE API classes, but no third party libraries should be used. (It is not necessary, and makes marking hard.)
- Don’t write any code that is operating-system specific (e.g. by hard-coding in newline characters etc.), since we will batch test your code on a Unix machine.
- Your source files should be written using ASCII characters only.
Implement the classes as if other programmers are going to be using and maintaining them.Hence:
- Your code should follow accepted Java naming conventions, be consistently indented, readable, and use embedded whitespace consistently.
- Your code should use private methods and private instance variables and other means to hide implementation details and protect invariants.
- Your methods, fields and local variables (except for-loop variables) should have appropriate Javadoc comments or normal comments.
- Comments should be used to document your code’s invariants, and to describe any particularly tricky sections. (You must provide an implementation invariant for each of the Event, Service, ShuttleTimetable and LineUp classes). However, you should also strive to make your code understandable without reference to comments; e.g. by choosing sensible method and variable names, and by coding in a straightforward way.
- The checkInvariant() method of each class (other than the test suite) should check that the implementation invariant you have specified in your comments is satisfied.
- Your code should not be overly complex and hard to understand.
The Zip file for the assignment also includes some other code that you will need to compileyour classes as well as some junit4 test classes to help you get started with testing your code.
Do not modify any of the files in package festival other than Event, Service, ShuttleTimetable and LineUp, since we will test your code using our original versions of these other files. Do not add any new files that your code for these classes depends upon, since you won’t submit them and we won’t be testing your code using them.
The junit4 test classes as provided in the package festival.test are not intended to be an exhaustive test for your code. Part of your task will be to expand on these tests to ensure that your code behaves as required by the javadoc comments. (Only if you are a CSSE7023 student will you be required to submit your test file EventTest.java.) We will test your code using our own extensive suite of junit test cases. (Once again, this is intended to mirror what happens in real life. You write your code according to the “spec”, and test it, and then hand it over to other people … who test and / or use it in ways that you may not have thought of.)
If you think there are things that are unclear about the problem, ask on the piazza forum, ask a tutor, or email the course coordinator to clarify the requirements. Real software projects have requirements that aren’t entirely clear, too!
If necessary, there may be some small changes to the files that are provided, up to 1 week before the deadline, in order to make the requirements clearer, or to tweak test cases. These
updates will be clearly announced on the Announcements page of Blackboard, and during the lectures.
Hints:
- It will be easier to implement the Service class first, followed by Event and then ShuttleTimetable and LineUp. The tests you may wish to write before you start coding these classes.
- Read the specification comments carefully. They have details that affect how you need to implement and test your solution.
Submission: SubmityourfilesEvent.java,Service.java, ShuttleTimetable.java, LineUp.java (and EventTest.java if you are a CSSE7023 student) electronically using Blackboard according to the exact instructions on the Blackboard website:
https://learn.uq.edu.au/
You can submit your assignment multiple times before the assignment deadline but only the last submission will be saved by the system and marked. Only submit the source (i.e. .java) files listed above.
You are responsible for ensuring that you have submitted the files that you intended to submit in the way that we have requested them. You will be marked on the files that you submitted and not on those that you intended to submit. Only files that are submitted according to the instructions on Blackboard will be marked.
Evaluation:
If you are a CSSE2002 student, your assignment will be given a mark out of 10, and if you are a CSSE7023 student, your assignment will be given a mark out of 12, according to the following marking criteria. (Overall the assignment is worth 10% for students from both courses.)
Testing (5 marks)
- All of our tests pass
- At least 3/4 of our tests pass
- At least 1/2 of our tests pass
- At least 1/4 of our tests pass
- Work with little or no academic merit
5 marks 4 marks 2 marks 1 mark 0 marks
Note: code submitted with compilation errors will result in zero marks in this section. A Java 8 compiler will be used to test code. Each of your classes will be tested in isolation with our own valid implementations of the others.
Code quality (5 marks)
- Code that is clearly written and commented, and satisfies all specifications, style rules and rules of data abstraction
- Minor problems, e.g., lack of commenting or private methods
- Major problems, e.g., code that does not satisfy the specification or rules of data abstraction, or is too complex, or is too difficult to read or understand
5 marks 3-4 marks
1-2 marks
• Work with little or no academic merit 0 marks
Note: you will lose marks for code quality for:
- breaking java naming conventions or not choosing sensible names for variables;
- inconsistent indentation and / or embedded white-space or laying your code out in a way that makes it hard to read;
- having lines which are excessively long (lines over 80 characters long are not supported by some printers, and are problematic on small screens);
- not using private methods and private instance variables and other means to hide implementation details and protect implementation invariants;
- not having appropriate comments for methods, fields and local variables (except for- loop variables), or tricky sections of code;
- not having meaningful implementation invariants commented and implemented for each of the classes; or
- incomplete, incorrect or overly complex code, or code that is hard to understand. JUnit4 test – CSSE7023 ONLY (2 marks)
We will try to use your test suite EventTest to test an implementation of Event that contains some errors in an environment in which the other classes Event.java depends on exist and are correctly implemented.
Marks for the JUnit4 test suite in EventTest.java will be allocated as follows:
- Clear and systematic tests that can easily be used to detect most of the (valid) errors in a sample implementation and does not erroneously find (invalid) errors in that implementation.
2 marks
- Some problems, e.g., Can only be used easily to detect some of the (valid) errors in a sample implementation, or falsely detects some (invalid) errors in that implementation, or is somewhat hard to read and understand.
1 marks
- Work with little or no academic merit or major problems, e.g., cannot be used easily to detect (valid) errors in a sample implementation, or falsely detects many (invalid) errors in that implementation, or is too difficult to read or understand.
0 marks
Note: code submitted with compilation errors will result in zero marks in this section. A Java 8 compiler will be used to test code.
School Policy on Student Misconduct: You are required to read and understand the School Statement on Misconduct, available on the School’s website at:
http://ppl.app.uq.edu.au/content/3.60.04-student-integrity-and-misconduct
This is an individual assignment. If you are found guilty of misconduct (plagiarism or collusion) then penalties will be applied.
If you are under pressure to meet the assignment deadline, contact the course coordinator as soon as possible.