Labsheet 4 (for week 5)

This lab provides practice using the ArrayList collections class. The original author was Rachel Cardell-Oliver.

Create a folder Marks analyser, and download these three files.

• Student.java
• MarksAnalyser.java
• MarksAnalyserTest.java

The MarksAnalyserTest and Student classes are complete, so you will not have to modify these. However, the MarksAnalyser class needs additional code, which you will have to write, in order to work properly.

1. Examine the code for the Student class. Try creating some Student objects in BlueJ and calling their methods.

2. Examine the code for the MarksAnalyser class. All the methods have comments explanining what they should do. However, the methods are currently incomplete, and do not satisfy the requirements set out in the comments. (Incomplete methods like this are sometimes called “stub” methods – they compile correctly, but do not yet contain working code.)

3. Right-click on the MarksAnalyserTest class, and select “test all”. The tests in the class should run, and should (nearly all) fail. That’s okay! This is what we expect: the tests check to see whether MarksAnalyser behaves the way it is supposed to; but currently, it does not, since we haven’t written code for the incomplete methods.

4. Go through the MarksAnalyser class, and start filling in the methods. It will probably be easiest to tackle them simply in the order they’re listed in within the class.

   If you’re unsure of how to tackle a particular bit of code, it can be helpful to ask yourself:

   • What does the comment say the code should do? Is this a constructor? Is it an accessor method? A mutator? Or something else?
     Then you can refer to the textbook, or the lecture notes, and look at example code of the sort you are after.
   • Do I need to break the problem down into smaller parts?
     Sometimes, you may not know how to write all of the code required – but if you break the problem into smaller sub-problems, you may discover you do know how to do some of those.

   It is a good idea to compile your code after every change you make; if it doesn’t compile, you need to fix the problem, rather than continue on. If you are unable to fix it yourself, show a lab facilitator your code, and explain what you have already tried, and they should be able to suggest ways of working out exactly what is wrong.

   It is also a good idea to run the tests after every few changes you make. Each test examines a small bit of functionality in the MarksAnalyser class. Sometimes, you may need to complete more than one method before you can expect a change in the test results. For instance, if you have successfully completed the joinClass method (which changes the state of the MarksAnalyser class), the testNumberOfStudents test won’t reflect this until you have also completed the numberOfStudents method. (Why? Because numberOfStudents is an accessor method, which provides the tests with information they need to know about a MarksAnalyser object. Until it is complete, your joinClass method may well be working correctly, but there is no way for the tests to tell.)

CHALLENGE (optional): The current test cases do not check for sensible responses when the MarksAnalyser object is null or contains no values. Decide what you think appropriate actions would be, write test cases in MarksAnalyserTest to check for the correct behaviour, and update your MarksAnalyser methods to allow for the cases.

If you create a good set of tests, email your updated version of MarksAnalyserTest.java to [email protected]. There will be a prize* for the best submission, with ties broken by date of submission if necessary.

* All prizes are awarded or not solely at Arran’s discretion.