Reference no: EM131321749

Tennis Score Board

You will write a GUI that can be used to keep track of the score during a lawn tennis match at Wimbledon. You will be using MVC (Model View Controller) so you will submit the Model and then the View and Controller together.

This coursework will assess the following learning outcomes.

• Create a software artifact by applying the methodologies of advanced object- oriented programming to a requirements speciation
• Select and apply a design pattern from one of the major design patterns to solve a given problem
• Consult on-line code libraries to find the classes and methods most appropriate for solving a particular problem
• Create appropriate documentation that clearly communicates the intend behavior of a program

Description of the GUI

As you can see, the GUI is composed of two buttons, to be pressed each time a player wins a point, plus the scoreboard itself, which is divided into three portions. The central portion records the names of the two players. Each match is played as the best of five sets, so it continues until one player has won three. The left portion, initially blank, shows the results of the previous sets.

Each set is made up of a series of games, and each of these is made up of a series of points. The right portion shows the number of sets won and the state of the current set. You will need to implement both tie-breaks and deuce-advantage play. (https://en.wikipedia.org/wiki/Tennis_score has full details of the scoring system.)

Part 1

Implementing, for the highest marks, all the required functionality with an interface designed to be convenient for the Controller, View and JUnit class to use with no superfluous public methods. It should have no references to those two classes and contain no GUI code. It should be programmed according to the principles of good object-orientation; such as encapsulation, inheritance and polymorphism. It will likely have many classes and therefore it should have an explanatory class diagram.

Specification of Model in JML or Spec# or asserts, including invariants for the class as well as pre and post conditions for each method. This will be marked according to how many of the relevant conditions are included and the correctness of the JML / Spec# / asserts. Partial credit will be available for describing them in English. Some statements may be un-provable due to the limitations of JML / Spec# even when specified correctly.

10% Unit testing of the Model in JUnit. There should be three tests, significantly different from each other. You should explain in comments the particular situation you are testing for. You should use write (and then call) methods for the Model that set it into the state desired for the test. It should be easy to see what state the Model is being set to by reading the code for the unit tests.

Part 2

Controller, which must forward only valid requests to the Model, querying the Model if necessary to and out if the request is valid, and must also enable / disable buttons as appropriate. In particular, when the match has finished, it should disable the buttons and cause the View to change all the yellow writing to grey, except for the winner's name, which will be in red. It must have no GUI code, though it may send messages to the View. It will be marked with respect to these requirements.

View, which will be multiplied by a number between 0 and 1, indicating the code quality/commenting/formatting as described above for the Model. For example, there should be no "magic numbers" i.e. all calculations of (x,y)-coordinates should be based on predefined constants.

Another copy of View, translated to the JavaFX framework, instead of Swing. It will also be scaled in the same way.