The following assignment replaces the workshops that during the course have been the base of the examination. If you have already a passing grade in any of these it will be considered when you hand in the assignment. For example, if you missed only WS1 you need only to hand in a domain model. If you missed WS2 and/or WS3 you need to hand in a full design and working application adapted to correspond to the respective workshops.

In short, the assignment is to create an application that plays the dice game Yahtzee. My suggestion is that you work with the domain model first to understand the problem and then you iteratively design, implement, test and evaluate. The game does not need to be graphically attractive (a console application is good enough). The focus should be a good and solid design and a stable implementation. The following are the requirements (note that these should be adapted to the workshop(s) you have failed:

1. You should be able to play the game Yahtzee using the original rules and at least one variant of the game, for example Maxi-Yahtzee
2. You should be able to select the number of players (1-5)
   • A player has a name
   • A player could be a human player or a computer player
3. During a non finished game you should be able to save, quit the game and then resume the game
4. The game result should be saved when it is over
5. Two different lists for saved games should be available:
   • A compact list that shows the date, players and the total score for each player.
   • A full list that shows the date and the full scoring-sheet.
6. Model-View-Controller architecture
7. Good quality of code (for example naming, standards, duplication)
8. An object oriented design and implementation. This includes but is not limited to:
   • Objects are connected using associations and not with keys/ids.
   • Classes have high cohesion and are not too large or have too much responsibility.
   • Classes have low coupling and are not too connected to other entities.
   • Avoid the use of static variables or operations as well as global variables.
   • Avoid hidden dependencies.
   • Information should be encapsulated.
   • Use a natural design, the domain model should inspire the design.
   • Use design patterns, GRASP and GoF, to solve design problems where appropriate.
9. Tested – the application should work and not behave strangely during normal operations.
10. Delivered with class diagram (domain and design model)and interaction diagram(s) for important parts, class diagram (design model that corresponds to the implementation), source code, executable version.