FEL: Katalogen existerar inte

This describes the task for the third workshop, perform all the steps in order. Be sure to document all assumptions and changes you are making. Also, be sure to specify who participated in the work and be prepared to answer any questions about your model. You must be a course participant and logged in to see the information below.

Please use English in your models and documents. You may get international students as reviewers.

All files should be zipped into an archive and be in one of the following formats. plain text (i.e. different source code files), pdf or common image formats (e.g. jpg, gif, png). Do not use word documents etc.

Introduction

In this workshop, you will continue the implementation and documentation of a Black Jack game. The design is similar to what we have done on the lectures but it is not exactly the same. The focus is not on usability or a nice user interface but to have a robust and well-documented design that can handle change. In the provided code, you find a started but not a playable version of the game in C# or Java. As there are many different variants of the rules one of the aims is to create a flexible design that supports different combinations of rules. There is also a class diagram that describes the packages, classes and the main relations in the implementation (note that there are dependencies in the implementation that are not shown in the diagram for readability purposes, e.g. there are many dependencies to the Card class). There is also a sequence diagram for one, not implemented, part of the game.

Read more about Black Jack on Wikipedia

Diagrams and Code

C# Black Jack Code GitHub repository (Fork or download)
Java Black Jack Code GitHub repository (Fork or download)

Grade 2 Requirements

• Download, compile and run the game in your development environment (it should run, but it’s not playable).
• Study the class diagram and the source code to understand the design of the game.
• Implement the operation Game::Stand using the sequence diagram Game_Stand. The game should now be playable.
• Remove the bad, hidden, dependency between the controller and view (new game, hit, stand)
• Design and implement a new rule variant for when the dealer should take one more card. The new variant is “Soft 17″, use the same design pattern already present for Hit. Soft 17 means that the dealer has 17 but in a combination of Ace and 6 (for example Ace, two, two, two). This means that the Dealer can get another card valued at 10 but still have 17 as the value of the ace is reduced to 1. Using the soft 17 rule the dealer should take another card (compared to the original rule when the dealer only takes cards on a score of 16 or lower).
• Design and implement a variable rule for who wins the game. This variation could, for example, change who wins on an equal score (in one implementation the Dealer wins, in the other the Player). The design should make it easy to add other variants without changing the Dealer. Use the same design pattern as used in the Soft 17 design.
• The code for getting a card from the deck, show the card and give it to a player is duplicated in a number of places. Make a refactoring to remove this duplication and that supports low coupling/high cohesion (i.e. check how you can evaluate different solutions to the problem and select the one that gives the best result according to low coupling/high cohesion). The code that is duplicated is similar to this:

  Card c = deck.GetCard();
c.Show(true/false)
player.DealCard(c);

• Use the Observer-pattern to send an event to the user interface that a player (human or dealer) has got a new card in his hand. When the event is handled the user interface should be redrawn to show the new hand (with the new card) and the game should be briefly paused, to make the game a bit more exciting, the pausing code should be in the user interface (view or controller) and not in the model. You should design and implement the observer structure yourself and not use any library classes like java.util.observer etc. The pause should be when any player (dealer or human) gets a card.

  For example, when starting the game the following “pattern” of pauses should present in the user interface:

  Dealer:
  Player: c1 (player gets the first card)
  *pause*
  Dealer: c1 (dealer gets the first card)
  Player: c1
  *pause*
  Dealer: c1
  Player: c1, c2 (player gets the second card)
  *pause*
  Dealer: c1, c2 (dealer gets the second card)
  Player: c1, c2

  In this example video, of a graphical user interface to the black jack game, these pauses are used to animate the cards and play a sound.

• Update the class diagram to reflect the changes you make (it is not necessary to recreate the whole diagram only the parts that have been affected by your changes).

You should submit the following and all parts should match

• Easily executable version alt. instructions on how to execute.
• Source code for the entire application
• An updated class diagram
• optional readme.txt with any assumptions/instructions and group information (name, username)

Requirements for Grade 3

• Perform the requirements for grade 3
• Expand the design and implementation with:
• Use the design pattern Abstract Factory to offer some “finished” rule factories for different rule combinations. Parameterize the Game class in the constructor with the factory to use.
• Use the design pattern Visitor to enable the view to print what rules are used at the start of the game. The model classes shoul not have any form of “type”-attribute (string, enum, int etc) or use some form of reflexion (i.e. print the class name).
• Hand in the assignment before the deadline.

Requirements for Grade 4

• Perform the requirements for grade 3
• Perform the requirements for grade 4
• Expand the design and implementation with:
  • Design and implement a new (not console based) user interface (view/controller) to the game, for example using Swing, WPF, OpenGL, XNA or a web-based variant (you are free to convert it to another language than C#/Java if you want). Use as much of the present design as possible but change it if it is needed. The following video shows an XNA version of the game:
  • Write a short report on the conversion, what went well, what needed to be changed, why and how was the change made.
• Hand in the assignment before the deadline.