Informatics 2 - Software Engineering - 2016/17

Coursework 3

To get started, you will need Additional information important for completing the project will be posted below. When changes are made the Change Log entry below will be updated and an email sent out to the class.

Change Log


Expected behaviour of ItemReady use case

A few of questions have come up on the Discussion Forum concerning some details of how exactly this use case should execute.

Selecting phases for marking

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 test execution

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.

  1. The method setupTestEnvAndSystem() in TestBasis is first run, because it has a JUnit @Before annotation. This does some internal setup of the test framework and then calls the setupSystem() method that you complete in the SystemTest class.
  2. The test method with the JUnit @Test annotation is run. This uses input and expect methods inherited from testBasis to add events to the inputEvents and expectedOutputEvents fields of the SystemTest object.
  3. A call is made to runAndCheck() at the end of the test method. The remaining steps below detail what happens when this call executes.
  4. The inputEvents are loaded into the event distributor.
  5. The events in the event distributor are sent into your system and resulting output events are gathered by the event collector.
  6. The collected output events are stored in the actualOutputEvents field of the SystemTest object.
  7. Information on the similarity of the expected and actual output events is output as a logging message, and the expected and actual output events are then compared using an assertEquals() call.

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.

Printing receipts

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.

Documenting use case preconditions

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.

AddToMenu use case scenarios

This use case starts with the sending into your system of a message of form addToMenu(menuID, description, price). No information is given in any of the handouts on what to do if already there is a menu entry using this menuID. Do not consider this situation an error; rather consider it as an alternative main success scenario which results in the entry in the menu for menuID being updated with the provided description and price.

Time-stamps and the current test time

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.

Ordering of entries in the menu, tickets and the rack

Entries in the display of the menu, tickets and the rack must be ordered as follows:

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.

Using Eclipse or some other IDE

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:

  1. As in Section 4.2 of the handout, download the "roms-demo.zip" file and unzip it in some temporary location in your file-space to create a directory tree with top-level directory "ROMSDemo".
  2. Start up Eclipse. These instructions have been tried out using Eclipse Mars.1 (4.5.1). Very likely something similar works with earlier versions.
  3. In Eclipse, create a new Java project using File > New > Java Project. This opens up the first page of the new project wizard.
  4. Choose a "Project name" for your project, ideally without spaces. Here will assume the name is "ROMS".
  5. Choose JRE JavaSE-1.8 for the execution environment.
  6. Select "Create separate folders for sources and class files". Click "Configure default..." to check the source folder is "src" and the output folder name "bin". Click OK on this "Preferences (Filtered)" page.
  7. Click "Finish" to create an ROMS project folder in your Package Explorer view with a "src" subfolder.
  8. Select File > Import. In "Import" pop-up window, select General > FileSystem. Click "Next".
  9. In the "File system" box use the "Browse" button to select the ROMSDemo directory created from the unzip. In the white box below, tick the box by "ROMSDemo". The "Into folder" should be set to "ROMS". Click "Finish". You should now see in the Package Explorer the full "src", "data", and "lib" directory trees. Assuming you have autobuilding enabled, the source files will not compile properly because JUnit library information is missing. The next step is to provide this information.
  10. Select your ROMS project directory in the Package explorer and open a Properties window for the project using Project > Properties. Select the "Java Build Path" property, select the "Libraries" tab and click "Add JARs...". Select both the JUnit and the Hamcrest ".jar" files in the "ROMS/lib" directory and click OK. Click OK again in the Properties window.
  11. The Java source files should now all compile fine, and you should be able to both run individual JUnit tests and the AllTests class as a Java application.

Tabs, indents and line lengths in Java code

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.

Version control

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.


Home : Teaching : Courses : Inf2c-se : Coursework 

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