|
The marking scheme explained in Section 7 of the handout has a scaling factor that depends on the coursework phases you tackle. To make application of this scheme straightforward, please indicate at the start of the Work completed section of your report which phases you would like to have contribute to your coursework mark: Phase I, Phases I & II or Phases I,II & III.
Your phase selection will govern which auto-marking test results are used to derive the auto-marking scale factor and will affect what markers look for when deriving marks for the first 4 items in the marking scheme. Markers will base their marks on the material associated with the phases you choose for marking. If you wish, you can also include code, tests and report material on further phases. Markers will give you feedback on this further work, but will not consider this further work when deciding your marks.
If you tackle multiple phases, do not divide the report into sections for each phase. Just divide it into the sections suggested in Section 3.7 of the handout.
Choose the phases you wish marked carefully. Asking for more to be marked might result in your mark dropping, not increasing. For example, a group might have perfect implementation, tests and report for Phase I, but have poor or incorrect material for Phase II and its code might pass only half of the Phase II tests.
System-level tests are defined by methods in the SystemTest class that have the JUnit @Test annotation. Execution of one of these tests depends on a number of methods defined in the parent class TestBasis. The main flow of control during such an execution is as follows.
The setupTestEnvAndSystem() method is an simple example application of the Template Method design pattern. Indeed, the whole JUnit test approach, using annotations such as @Before, @Test and @After is a realisation of this pattern.
The Coursework 1 and 2 handouts both suggest that receipt printing should be optional. In Coursework 3, for simplicity, your implementation should not support the additional interactions with the customer that are needed for this. Your implementation should just always print a receipt after the card authorisation is received from the bank card payment processing centre via the BankClient object.
At the start of Appendix B is the statement that only main success scenarios need to be realised. As you implement the requested use cases, you are going to need to make decisions about what exactly is and is not a such a scenario. In some use cases, there might be more than one scenario (execution path) that could sensibly be considered a main success scenario. For example, in the IndicateItemReady use case, it is sensible to include scenarios where the order ticket is and is not printed and the ready-up light is or is not switched on.
Document your decisions here by describing in the design description section of your report use case preconditions that characterise the scenarios you handle. For example, you might decide that trying to add a menu item to the menu identical to one already there is not a main success scenario; nothing is achieved in this situation and maybe at a later stage you might want to add some warning message display. You would then note that a precondition of the AddToMenu use case is that the new menu item added is distinct in some way from any existing items on the menu. Such a note is a prompt to relevant stakeholders to discuss whether and how scenarios violating the precondition should be handled. And it is a prompt to developers that maybe further code is needed.
See discussion forum post 168 titled "When to use assertions" for further discussion.
As remarked in Section 2.4 of the handout, all input and output events have time-stamps. If you look in any of the event files in the data directory or at the sample test in SystemTest.java, you will see that time-stamps are printed using an integer for the day and hours and minutes for the time. For example, "1 19:15". Time stamps are formatted in this way rather than say "2016-11-17 19:15" because the format is less verbose, but still sufficient for testing.
For Phases I & II, you just write time-stamps in this format for the input and expected events you set up for your test. You don't work any further with these time-stamps.
In Phase III, the rack display needs to show the number of minutes since submission of each order. The simplest way to get these numbers is to have each of your tickets store the time it is submitted to the kitchen, and to use the minutesBetween() static method in the Clock class to compute the differences between submission times and the current time. An alternative is have tickets directly remember the number of minutes since submission, and to have this updated suitably on tick() input events. Please do not take this approach, as the auto-marking tests are not guaranteed to send in tick() events every minute.
Times are represented using objects from the java.util.Date class. The current test time is held in a field of the clock object. As each input event is sent into your system, this current test time is updated to the input event's time-stamp. Whenever an output event is sent out of your system, its time-stamp is taken from this current test time.
See Section 4.7 of the handout and the Clock class code for further details.
These further ordering requirements are imposed for a few reasons: they simplify identifying problems when expected and actual outputs of your system don't match. They also simplify the auto-marker. And they are desirable from an application domain point of view. Using an ordering along with some conventions on how menu IDs are chosen provides a simple way to ensure that menu items of the same kind (e.g. drinks, starters, main courses, desserts) are grouped together.
For examples of displays of entries, see the expected output files in the data subdirectory of the provided file bundle.
To ensure these orderings in the displays of entries, it is probably simplest to ensure the entries themselves are kept in order in the menu, ticket and rack data structures. However there is nothing stopping you having the data structures being unordered, and just sorting entries in the toStrings() methods used for generating the displays. You may have good reasons for wanting to take such an approach.
It is strongly recommended that you use Eclipse or some other IDE for developing your code. Useful features include refactoring support to keep your code clean, JUnit support, automatic recompilation, and an integrated debugger where setting breakpoints and checking program state is quick and simple.
If you use Eclipse you can get started as follows:
The handout recommends you follow standard coding guidelines such as those from Google or Oracle/Sun. A common recommendation is that you never use tab characters for indentation and you restrict line lengths to 80 or 100 characters. You are strongly recommended to adopt both these recommendations, both because it is good practice and, particularly, in order to ensure maximum legibility of your code to the markers. I recommend using an indent step of 4 spaces as in the Sun guidelines rather than the 2 in the Google guidelines, for consistency with the supplied code.
The default in Eclipse is to use tab characters for indents. To change this, open the Preferences pop-up and navigate to the Java > Code Style > Formatter preference. Edit the existing Profile to create a new Profile that only uses spaces. Say name the new profile "Eclipse no-tabs".
In Eclipse, you can check the right margin setting and turn on a right margin indicator line by visiting the General > Editors > Text Editors preference.
You might well want to take this opportunity to try using version control for your project. If nothing else, this will back up your code and make it easy to work on shared code. There are a number of free repository hosting services available on the web. If you are new to version control, you might find it easier to start with subversion rather than git or mercurial.
If you do use a repository hosting service, it is vital that you choose one where your code is private to your coursework group, not open for anyone to read. See the School's advice on good scholarly conduct. Note that many free hosting services are geared towards supporting open-source projects and do not provide the option of making your repository private. For example, normal free github repositories are not suitable, as they are world readable. One popular provider of free git-based private repositories is bitbucket.
There is no coursework requirement that you use any version control system and no extra marks will be given if you do.
|
Informatics Forum, 10 Crichton Street, Edinburgh, EH8 9AB, Scotland, UK
Tel: +44 131 651 5661, Fax: +44 131 651 1426, E-mail: school-office@inf.ed.ac.uk Please contact our webadmin with any comments or corrections. Logging and Cookies Unless explicitly stated otherwise, all material is copyright © The University of Edinburgh |
